Skip to content

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

Description

@jeffhuber

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:

Telemetry is contract-first and paired across repository boundaries:

Release work is serial after every child is merged:

  • Deploy the hosted consumer before enabling production client emission.
  • 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    epicEpic tracking issueserial-releaseSerialize because it changes release, gate, or final adoption posturev1.6Code Mower v1.6 operational clarity and minimum telemetry

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions