Spec slice: Post-ship feedback

[ganesh47]

Parent: #32

Source slice: docs/specs/cstack-post-ship-feedback-slice.md

Post-Ship Feedback Slice

Historical note:

• This document is a future slice spec, not part of the active shipped contract.
• The active shipped contract remains docs/specs/cstack-spec-v0.1.md.
• This slice defines how cstack should grow from shipping readiness into bounded post-ship feedback capture.

Thesis

cstack should extend past ship with a bounded post-ship feedback surface that records deployment-adjacent evidence, follow-up recommendations, and linked remediation work without turning into an operations platform.

Why This Slice Exists

Current ship and deliver workflows can prove readiness and record delivery evidence.

What is still missing is a structured answer to:

• what happened after ship
• whether the shipped outcome triggered follow-up work
• which signals were observed versus inferred
• which new tasks should be created from those signals

Product Decision

This slice adds a bounded post-ship phase or artifact family focused on evidence and follow-up generation.

It does not add:

• deployment orchestration
• incident response automation
• product analytics ownership
• customer support workflows

Scope

This slice owns:

• post-ship artifact schemas
• deployment status references
• release state, check state, and issue-reopen signal capture
• production error or rollback references when available
• follow-up issue or task draft generation
• inspector views for post-ship state

This slice does not own:

• running deployments
• deep observability integrations as a required baseline
• non-engineering post-launch operations

Independent Team Contract

The post-ship feedback team is responsible for:

• bounded evidence collection after ship
• clear observed-versus-inferred recording
• follow-up synthesis artifacts
• post-ship inspector views

The team is explicitly not responsible for:

• GitHub planning lineage
• validation strategy design
• initiative-wide grouping logic

Outcome Model

A post-ship outcome should distinguish:

• observed external evidence
• inferred impact or recommendation
• unresolved follow-up work
• whether new issues or tasks should be created

Recommended statuses:

• stable
• watch
• follow-up-required
• rollback-observed
• signal-unavailable

Artifact Contract

Recommended additions:

• artifacts/post-ship-summary.md
• artifacts/post-ship-evidence.json
• artifacts/follow-up-draft.md
• artifacts/follow-up-lineage.json

Recommended meanings:

• post-ship-summary.md
  • human-readable summary of what happened after ship
• post-ship-evidence.json
  • structured observed evidence references and classification
• follow-up-draft.md
  • draft issue or task text created from post-ship signals
• follow-up-lineage.json
  • linkage from shipped run to newly created or recommended follow-up work

Recommended post-ship-evidence.json shape:

{
  "status": "follow-up-required",
  "observedSignals": [
    {
      "kind": "release-state",
      "summary": "Release published successfully"
    },
    {
      "kind": "issue-reopened",
      "summary": "Linked issue #123 was reopened after release"
    }
  ],
  "inferredRecommendations": [
    "Create a follow-up investigation slice for regression in issue #123"
  ],
  "followUpRequired": true
}

Inspector and Ledger Expectations

inspect should be able to show:

• post-ship status
• evidence references
• follow-up recommendations
• linked follow-up issue or task drafts

runs should be able to surface whether a shipped run later accumulated post-ship follow-up state.

Acceptance Criteria

This slice is complete when:

• a shipped run can record post-ship evidence
• post-ship artifacts distinguish observed signals from inferred recommendations
• follow-up drafts can be generated from post-ship findings
• the slice stops at evidence and follow-up rather than operational execution

Release Boundary

First release for this slice should include:

• post-ship artifact schema
• post-ship summary and evidence capture
• follow-up draft generation
• inspector support for post-ship state

It should not require:

• deployment orchestration
• mandatory observability vendor integrations
• initiative graph support

Non-Goals

This slice should not:

• claim to monitor production continuously
• mutate external systems without explicit operator or policy control
• absorb support, sales, or GTM follow-up into the cstack workflow contract

[ganesh47]

Kickoff note: this issue is now the independent execution thread for the post-ship feedback workstream under #32. A codebase-mapping agent is collecting exact touchpoints, first-slice scope, risks, and test coverage recommendations so implementation can proceed independently.

[ganesh47]

Autonomous team kickoff:

• Parent umbrella: Spec: end-to-end product delivery workstreams beyond gstack #32
• Source slice: use the spec body already attached to this issue as the contract.
• Execution rule: first release must be independently shippable and artifact-driven.
• Evaluation rule: prove product value, operational independence, and inspection quality.
• Deliverables for the first implementation slice:
  • explicit artifact schema
  • inspector or ledger impact
  • tests for the new artifact/reporting surface
  • clear non-goals to keep the slice bounded

[ganesh47]

Kickoff mapping from the current codebase:

First shippable slice:

• add post-ship artifacts for observed release-adjacent evidence and generated follow-up recommendations
• reuse existing ship/deliver GitHub evidence instead of introducing deployment orchestration
• expose post-ship state in inspect

Primary code touchpoints:

• src/ship.ts
• src/deliver.ts
• src/types.ts
• src/github.ts
• src/inspector.ts
• test/ship.test.ts
• test/deliver.test.ts
• test/inspect.test.ts

Constraint:

• separate observed evidence from inferred follow-up recommendations and do not claim continuous monitoring.

[ganesh47]

Autonomous workstream kickoff:

• Parent umbrella: Spec: end-to-end product delivery workstreams beyond gstack #32
• This workstream must ship a first useful release without waiting on the other five slices.
• The first implementation slice must define: artifact schema, inspector impact, tests, and explicit non-goals.
• Keep local artifacts as the durable source of truth.
• Record requested behavior separately from observed behavior.
• Do not expand scope into deployment orchestration, full observability integration, or GTM workflows in the first slice.

Repo tracker: docs/research/cstack-end-to-end-workstream-tracker.md

[ganesh47]

Execution kickoff:

• First shippable slice: add post-ship artifacts from existing ship/deliver evidence without deployment orchestration.
• Primary code touchpoints: src/ship.ts, src/deliver.ts, src/github.ts, src/inspector.ts, src/types.ts.
• First tests: shipped runs emit post-ship summary/evidence/follow-up draft artifacts, and inspector separates observed signals from inferred follow-ups.
• Constraint: no deployment execution, no mandatory observability integration, and no mixing of evidence with recommendations.

Tracker: docs/research/cstack-workstream-execution-tracker.md

[ganesh47]

Implementation kickoff from current codebase shape:

• Primary touchpoints: src/commands/ship.ts, src/ship.ts, src/commands/deliver.ts, src/deliver.ts, src/github.ts, src/inspector.ts, src/types.ts.
• First shippable slice:
  • add post-ship artifact support without adding a new deployment workflow
  • record bounded post-ship evidence and follow-up recommendations from existing ship/deliver context
  • expose a narrow inspector surface for post-ship status and follow-up drafts
• Recommended first artifacts:
  • artifacts/post-ship-summary.md
  • artifacts/post-ship-evidence.json
  • artifacts/follow-up-draft.md
• Keep the first release evidence-only. No deployment execution, no continuous monitoring, no external observability vendor dependency.
• Tests to add:
  • ship or deliver run records post-ship evidence cleanly
  • inspector degrades cleanly when post-ship artifacts are absent
  • follow-up draft generation stays local and artifact-backed

Non-goals for the first release:

• deployment orchestration
• always-on monitoring
• customer-ops or GTM workflows

[ganesh47]

Autonomous kickoff note:

• Local tracker: docs/research/cstack-workstream-kickoff-tracker.md
• First shippable slice: add passive post-ship artifacts (post-ship-summary.md, post-ship-evidence.json, follow-up-draft.md) derived from existing ship/deliver GitHub evidence without deployment orchestration.
• Primary code touchpoints: src/types.ts, src/ship.ts, src/deliver.ts, src/github.ts, src/inspector.ts.
• Initial tests: test/ship.test.ts, test/deliver.test.ts, test/inspect.test.ts.
• Non-goal for v1: no continuous monitoring and no deployment automation.

[ganesh47]

Implementation status update: this workstream is now implemented.

Implemented:

• deliver and ship path now write post-ship artifacts
• artifacts/post-ship-summary.md, artifacts/post-ship-evidence.json, artifacts/follow-up-draft.md, and artifacts/follow-up-lineage.json are generated
• follow-up recommendations are distinguished from observed signals
• inspect includes issue- and run-aware post-ship views

Verification: npm run typecheck and npm test (all suites pass), with targeted coverage in test/deliver.test.ts and test/ship.test.ts.

[ganesh47]

Completed by PR #46, merged into main on March 28, 2026 as commit 8c115d3.