1. Background Context
Source: git-warp #690. Audited against main 94b40dac64034cd8caab9bb05efe14a0c22bd735. Template: feature; work type: type:feature.
Current scope and disposition: Generate an evidence scaffold from the existing release profile and public tag; publishing tracker changes remains an explicit invocation decision.
Reported context (historical names and counts require the current disposition above):
The new process requires a retrospective immediately after release. The evidence is mostly machine-readable: tag, commit, release URL, workflow run, changelog entry, registry package versions, and diff since previous tag. A scaffold command would make the process faster and less likely to omit evidence.
2. Problem Description
Generate an evidence scaffold from the existing release profile and public tag; publishing tracker changes remains an explicit invocation decision.
Historical source report; the current disposition above supersedes obsolete claims:
Generate a post-release retrospective draft from the release profile and public release evidence.
A future command such as continuum release retro vX.Y.Z or a repo-local script could:
- read
.continuum/release.yml;
- locate the previous public tag;
- collect diff stat, merged PRs, release run URL, and registry visibility;
- create or update the release retrospective issue with standard sections;
- list candidate fallout issues for human approval.
2b. Proposed Solution
Generate an evidence scaffold from the existing release profile and public tag; publishing tracker changes remains an explicit invocation decision.
Historical approach to reconcile:
Current architecture rules take precedence: parsing/encoding stays at adapters, domain concepts are runtime-backed, no trust casts are introduced, and tests run in Docker.
Generate a post-release retrospective draft from the release profile and public release evidence.
A future command such as continuum release retro vX.Y.Z or a repo-local script could:
- read
.continuum/release.yml;
- locate the previous public tag;
- collect diff stat, merged PRs, release run URL, and registry visibility;
- create or update the release retrospective issue with standard sections;
- list candidate fallout issues for human approval.
2c. Alternatives considered and rejected
No additional alternatives are recorded as decided. Reject duplicate ownership, private-import escape hatches and a broken intermediate mainline; retain original alternatives below when present.
2d. Acceptance Criteria
Additional source acceptance:
- A maintainer can generate a complete retrospective scaffold from a tag.
- Generated content is clearly marked as evidence scaffold, not final judgment.
- The command does not mutate GitHub Issues without explicit maintainer approval.
2e. Test Plan
Golden: Validate a packed artifact and the declared release/publication outcome.
Edges: Missing workspace manifest, stale metadata, rerun and runtime/platform differences.
Known failure modes: Deterministic validation failure is not retried as a transport error or reported as publication success.
Fuzz and stress: Repeated clean Docker builds/dry-runs; registry publishing requires the separate release workflow.
All tests and benchmarks execute in COPY-based Docker containers without host repository or Git-directory mounts. This planning audit does not claim those checks were run.
3. Prerequisites
No unsatisfied open-issue prerequisite established by this review. This is not proof that an unresolved design or external readiness condition is satisfied.
4. Scope
In: Generate an evidence scaffold from the existing release profile and public tag; publishing tracker changes remains an explicit invocation decision.
Out: unrelated domain work and any expansion beyond the issue’s stated observable outcome.
Safe intermediate state: the PR builds and passes relevant checks after its listed prerequisites; existing supported behavior remains usable. Any preparatory step must be independently mergeable.
5. Why now
Maintainer ordering: memory correctness first, supported attachments next, then land eligible PRs. Preserve this card’s existing priority unless a separately recorded scope decision changes it.
6. Risks
Main risk: implementing the historical description instead of the current runtime contract. Preserve compatibility, causal/ownership invariants and bounded behavior relevant to release.
7. Definition of Done
The issue-specific acceptance checks pass, relevant validation evidence is attached, and the issue links the coherent PR and resulting mainline integration commit. No open item is hidden in a later repair PR.
8. Stakeholders
James Ross: maintainer, assignee and acceptance owner. Package consumers and release maintainers rely on reproducible published artifacts.
9. Related Issues
No additional downstream blocker is established. Shared domain membership alone is not a prerequisite.
Historical paths, counts, release names and shell examples in source material are evidence to reconcile, not authority to restore retired documentation or run host tests.
1. Background Context
Source: git-warp #690. Audited against main
94b40dac64034cd8caab9bb05efe14a0c22bd735. Template:feature; work type:type:feature.Current scope and disposition: Generate an evidence scaffold from the existing release profile and public tag; publishing tracker changes remains an explicit invocation decision.
Reported context (historical names and counts require the current disposition above):
The new process requires a retrospective immediately after release. The evidence is mostly machine-readable: tag, commit, release URL, workflow run, changelog entry, registry package versions, and diff since previous tag. A scaffold command would make the process faster and less likely to omit evidence.
2. Problem Description
Generate an evidence scaffold from the existing release profile and public tag; publishing tracker changes remains an explicit invocation decision.
Historical source report; the current disposition above supersedes obsolete claims:
Generate a post-release retrospective draft from the release profile and public release evidence.
A future command such as
continuum release retro vX.Y.Zor a repo-local script could:.continuum/release.yml;2b. Proposed Solution
Generate an evidence scaffold from the existing release profile and public tag; publishing tracker changes remains an explicit invocation decision.
Historical approach to reconcile:
Current architecture rules take precedence: parsing/encoding stays at adapters, domain concepts are runtime-backed, no trust casts are introduced, and tests run in Docker.
Generate a post-release retrospective draft from the release profile and public release evidence.
A future command such as
continuum release retro vX.Y.Zor a repo-local script could:.continuum/release.yml;2c. Alternatives considered and rejected
No additional alternatives are recorded as decided. Reject duplicate ownership, private-import escape hatches and a broken intermediate mainline; retain original alternatives below when present.
2d. Acceptance Criteria
Additional source acceptance:
2e. Test Plan
Golden: Validate a packed artifact and the declared release/publication outcome.
Edges: Missing workspace manifest, stale metadata, rerun and runtime/platform differences.
Known failure modes: Deterministic validation failure is not retried as a transport error or reported as publication success.
Fuzz and stress: Repeated clean Docker builds/dry-runs; registry publishing requires the separate release workflow.
All tests and benchmarks execute in COPY-based Docker containers without host repository or Git-directory mounts. This planning audit does not claim those checks were run.
3. Prerequisites
No unsatisfied open-issue prerequisite established by this review. This is not proof that an unresolved design or external readiness condition is satisfied.
4. Scope
In: Generate an evidence scaffold from the existing release profile and public tag; publishing tracker changes remains an explicit invocation decision.
Out: unrelated domain work and any expansion beyond the issue’s stated observable outcome.
Safe intermediate state: the PR builds and passes relevant checks after its listed prerequisites; existing supported behavior remains usable. Any preparatory step must be independently mergeable.
5. Why now
Maintainer ordering: memory correctness first, supported attachments next, then land eligible PRs. Preserve this card’s existing priority unless a separately recorded scope decision changes it.
6. Risks
Main risk: implementing the historical description instead of the current runtime contract. Preserve compatibility, causal/ownership invariants and bounded behavior relevant to release.
7. Definition of Done
The issue-specific acceptance checks pass, relevant validation evidence is attached, and the issue links the coherent PR and resulting mainline integration commit. No open item is hidden in a later repair PR.
8. Stakeholders
James Ross: maintainer, assignee and acceptance owner. Package consumers and release maintainers rely on reproducible published artifacts.
9. Related Issues
No additional downstream blocker is established. Shared domain membership alone is not a prerequisite.
Historical paths, counts, release names and shell examples in source material are evidence to reconcile, not authority to restore retired documentation or run host tests.