Epic: v1.6.0 operational clarity and minimum telemetry #1066

Goal

Ship operational clarity and the minimum metadata-only Slack telemetry needed by the future always-on Operator, without turning v1.6 into a broad Slack UX or runtime-infrastructure release.

Work map and dependency order

Operational-clarity PRs may run in parallel:

• v1.6.0: align Board inventory filters, versions, and service guidance #1063 — Board inventory filters, invoking-version parity, stale detection, and service guidance (PR v1.6: align Board inventory and service guidance #1109 merged as 3cfd554ec3e63356d97ea44ea7453531b9b33fbd)
• v1.6.0: reconcile doctor warning taxonomy and hosted-posture scope #1064 — doctor warning taxonomy and hosted-posture scoping
• v1.6.0: make managed Board replacement atomic and truthful #1082 — atomic and truthful managed Board replacement
• v1.6.0: treat unmanaged PR lineage as neutral observer state #1083 — neutral unmanaged-PR lineage semantics
• v1.6.0: provide share-safe adoption diagnostics #1084 — share-safe adoption diagnostics
• v1.6.0: make audit comment ingestion payload-aware #1104 — payload-aware audit comment ingestion and reserved control-marker parsing (PR v1.6.0: harden audit comment ingestion #1107 merged as 166013b017988938d0085a870993ca975b0413dd)

Telemetry is contract-first and paired across repository boundaries:

• v1.6.0: minimum control-surface telemetry contract and OSS emitters #921 — freeze the minimum provider-neutral control-surface summary contract and OSS Board/cloud emitters
• v1.6.0: minimal CodeMower.com Slack telemetry ingestion and aggregates #978 — hosted validation, ingest, retention, aggregate counts, freshness, migration, deployment, and tenant-scoped acceptance complete (CodeMower.com PR v0.9: harden install and upgrade docs #542; production receipt in comment 5770184083)

Release work is serial after every child is merged:

• v1.6.0 release: qualify telemetry, soak, and publish #1105 — immutable candidate qualification, bounded Slack canary, soak, and publication

• Deploy the hosted consumer before enabling production client emission (CodeMower.com PR v0.9: harden install and upgrade docs #542, deployment 6581697672; exact capability accepting).

• Run one bounded Slack canary and reconcile local Board versus authenticated CodeMower.com totals.

• Exercise upgrade, rollback, basic Slack, Graphify, privacy, and public-install rehearsals against one immutable candidate.

• Soak the retained candidate for at least 24 hours and obtain two independent installation passes.

Product boundary

• Basic private Slack lifecycle remains the control surface.
• Cloud emission is limited to compact lifecycle summaries at meaningful state transitions or completion. Local Board may retain richer live state.
• Reuse the existing provider-neutral event envelope with a control-surface discriminator where compatible; do not build a second Slack-only telemetry architecture.
• CodeMower.com adds validation, tenant isolation, export/deletion/retention coverage, aggregate counts, and a freshness marker on an existing authenticated surface.
• Deferred beyond v1.6: Slack-to-Board links, interactive progress cards, rich buttons, per-user/channel analytics, replay, historical backfill, detailed cost allocation, new daemons, queues, or orchestration authority.

Privacy and compatibility

• Metadata only: no task or message prose, answers, source, diffs, prompts, transcripts, response URLs, Slack identities, credentials, private paths, graph/context data, or raw provider output.
• Old clients remain compatible; unknown or disallowed fields fail according to the closed schema.
• Hosted capability/version acceptance must precede production emission.
• OSS and hosted changes remain separate PRs with shared fixtures and independent review.

Code Mower delivery policy

• One issue and one writer per PR.
• Contract-first work merges before dependent consumers.
• Parallel work must not edit the same shared contract or generated template projection.
• Every behavioral change includes focused tests and a canonical doc update.
• Every changed head receives an independent eligible Code Mower audit; resolve all P0/P1/P2 findings.
• Final release, cloud enablement, and publication are serial-release work.