[FLO-OBS-02] Prove the observability profile in two holon CLIs

[szmyty]

Parent: #14
Depends on: FLO-OBS-01 / #15

Outcome

Prove the suite observability profile in two materially different standalone CLIs before extracting a shared package.

Use renderflow as the existing-tracing migration case and aniflow as the long-running, typed-machine-contract case. Keep implementation in each owning repository through separate issues, branches, and pull requests.

Scope

Coordination in flow

• Pin the exact reviewed revisions and current CLI/logging behavior of both products.
• Derive repository-local implementation issues from [FLO-OBS-01] Define the suite observability, privacy, and stream contract #15 without copying suite policy into each repository.
• Define a common conformance fixture and expected signal comparison.
• Record any convention that cannot represent both products honestly.

renderflow pilot

• Replace ad hoc global initialization with an embedding-safe, fallible CLI bootstrap.
• Instrument representative planning, provider/process execution, validation, cache/reuse, cancellation, and terminal outcome spans.
• Preserve progress rendering and existing human behavior intentionally.
• Prove human and structured log sinks never contaminate machine-result stdout.
• Add redaction and bounded-field coverage for representative provider/process failures.

aniflow pilot

• Keep the public library silent and subscriber-agnostic.
• Instrument representative inspect, plan, run, provider resolution/execution, validation, cancellation, resume, and status boundaries without changing durable evidence semantics.
• Keep versioned machine envelopes and typed error exit behavior intact.
• Prove telemetry-only fields never enter Pipeline v3 planning identity or provider locks/fingerprints.

Shared behavior

• Use the established Rust tracing facade and span instrumentation.
• Implement human stderr and JSON Lines stderr/file modes specified by [FLO-OBS-01] Define the suite observability, privacy, and stream contract #15.
• Support deterministic configuration precedence and terminal/color detection.
• Use the common resource/event/field names and cardinality policy.
• Handle repeated initialization and embedding without panic.
• Retain flush guards until CLI shutdown and bound any asynchronous buffering.
• Measure binary size, cold-start, runtime overhead, dependency/MSRV impact, and maintainability.

Acceptance criteria

• Separate owning-repository issues and PRs implement the two pilots.
• Both libraries work when the embedding application supplies its own subscriber.
• Both CLIs produce conforming human and JSON Lines operational logs.
• Versioned command-result stdout remains byte-valid and free of logs, progress, banners, and ANSI escapes.
• Representative spans use common product, command, operation, stage, provider, capability, outcome, and duration semantics.
• Cancellation, process failure, missing output, invalid output, and successful validation remain distinguishable.
• Secret, environment, argv, source-content, and path-redaction fixtures pass.
• Metric-label candidates and field cardinality are recorded from real pilot behavior.
• No telemetry-only state affects deterministic identities, accepted artifacts, checkpoint state, or result status.
• Stable and repository MSRV/platform matrices remain green.
• Pilot findings identify the minimum reusable API and any necessary product-specific extension points.

Explicit non-goals

• A shared crate or new repository.
• OpenTelemetry network export; [FLO-OBS-02] Prove the observability profile in two holon CLIs #16 owns exporter and propagation proof.
• Migrating optiflow or the future flow CLI.
• Making human log text a stable contract.
• Replacing typed diagnostics or durable run evidence.
• Mixing both implementations into one cross-repository PR.
• CLI ASCII branding.

Roadmap-Track: FLO-OBS