[FLO-OBS-04] Decide shared observability crate and repository ownership

[szmyty]

Parent: #14
Depends on: FLO-OBS-02 / #16, FLO-OBS-03 / #17

Outcome

Use evidence from the two CLI pilots and OpenTelemetry proof to decide whether shared observability behavior belongs in repository-local adapters, a published crate inside an existing repository, or a new independently released repository.

Record the result as a reviewable architecture decision before creating another cross-suite dependency.

Required evidence

Collect exact measurements and maintenance findings from the pilots:

• common versus product-specific API surface;
• source duplication and drift risk;
• Rust edition and MSRV compatibility;
• default and feature-enabled dependency graphs;
• build time, binary size, cold-start, runtime, allocation, and shutdown overhead;
• tracing and OpenTelemetry version compatibility/churn;
• feature unification and optional exporter behavior;
• global-subscriber versus composable-layer requirements;
• redaction and configuration ownership;
• platform and TLS/runtime differences;
• release, security advisory, SBOM, provenance, and maintenance ownership;
• compatibility and rollback behavior for independently released consumers.

Existing ownership candidate to inspect

Reinspect egohygiene/observatory before proposing a new repository. It currently owns organization visibility, maturity tracking, and platform observability from deterministic repository evidence; determine explicitly whether runtime telemetry support fits that purpose or would create domain confusion. Preserve its offline, evidence-read-model boundary unless an accepted ADR broadens it.

Options to evaluate

Repository-local adapters

One suite specification and conformance kit govern small implementations in each product.

Evaluate independence, duplication, drift, product-specific flexibility, and upgrade cost.

Published crate in an existing repository

A neutral crate is released from an existing workspace while remaining usable independently.

Evaluate whether the repository's purpose, release cycle, permissions, issue ownership, and MSRV make it an honest owner.

New observability/CLI-support repository

A separately versioned crate/repository owns only cross-cutting instrumentation, subscriber construction, redaction, OpenTelemetry bridges, and test support.

Evaluate naming, public scope, release automation, support expectations, dependency policy, and whether this creates a fourth infrastructure product prematurely.

Decision constraints

• No path dependency, mutable Git branch, copied sibling source, or direct sibling-holon dependency.
• A shared artifact must be published, semver-versioned, pin-able, independently testable, and reversible.
• Domain libraries must accept caller-provided layers/subscribers and must not seize global process configuration.
• The package cannot own holon-native diagnostics, run state, validation, provenance, or artifact semantics.
• Default features must remain small, offline, and free of exporter/network behavior.
• OpenTelemetry and sink integrations require explicit features.
• MSRV policy must accommodate actual consumers or document compatible release lines.
• The crate/repository name must be checked for registry, namespace, legal, and collision risk before selection.

Deliverables

• Evidence matrix with exact revisions and measurements.
• Proposed ADR with context, decision, alternatives, trade-offs, consequences, migration, security/privacy/accessibility impact, and review triggers.
• Selected ownership and release model.
• Initial public API sketch and feature matrix if extraction is selected.
• Provider migration and rollback plan.
• Explicit disposition for [FLO-OBS-05 / planned reusable package]: proceed, reshape, or close as not planned.

Acceptance criteria

• The decision is based on two shipped pilots and an OpenTelemetry proof rather than anticipated reuse.
• All three ownership options are evaluated seriously.
• Dependency, MSRV, security, privacy, release, and rollback costs are quantified where practical.
• The selected API keeps domain libraries subscriber-agnostic and CLI initialization fallible.
• The decision preserves polyrepo independence through immutable releases.
• The default feature set performs no network access.
• OpenTelemetry version upgrades cannot silently force all holons to release together.
• A maintainer can reverse the decision without changing domain contracts or losing durable evidence.
• The accepted ADR is linked from [EPIC] Establish suite-wide observability and CLI experience #14 and every affected implementation issue.

Explicit non-goals

• Implementing the package.
• Creating a repository before the decision is accepted.
• Migrating remaining products.
• Choosing a hosted telemetry vendor.
• CLI branding.

Roadmap-Track: FLO-OBS