Parent epic #12696 defines v13 as a release epic, not a single release-note ticket. The parent explicitly says exhaustive PR/issue history belongs in generated or reproducible appendices rather than the narrative body. #12695 is the release-note MD spine, #12698 is the war-story mining feed, and #10321 remains parked until the real workflow is known.
This ticket exists because the reset on #12695/#12697 made the gap concrete: the current draft only promises appendices. Prior high-bar release notes include actual changelog material; for v13 scale, the equivalent must be generated or reproducible, not hand-written into the prose.
Pre-creation evidence on 2026-06-07:
Live latest-open sweep: checked the latest 30 open issues with number, title, author, labels, and URL. Found #12696, #12695, #12698, and parked #10321, but no native appendix-generation child.
Exact live sweeps: appendix generation release notes, v13 appendices release notes, and changelog appendix release notes returned only the parent/release-note/war-story tickets, not an appendix leaf.
Exact local sweep across resources/content/issues, resources/content/discussions, resources/content/pulls, .agents/skills, and learn found Discussion #12694's appendix strategy plus related historical release-note infrastructure, but no current v13 appendix-generation ticket.
Semantic KB ticket sweep for ticket v13 release appendices generated changelog appendix release notes exhaustive PR issue list found no specific ticket for v13 release-note appendices or exhaustive v13 PR/issue lists.
Project pre-flight: Project 12 is live as Neo v13 Release; this ticket is attached to Project 12 for release visibility.
The Problem
The v13 release window is too large for the old "drop in every ticket" approach. The live planning surface currently tracks roughly 1,200+ merged PRs and 1,600+ closed tickets since v12.1.0. The narrative release note must stay curated, but without a generated/reproducible appendix surface the final artifact cannot meet the prior release-note bar or provide a verifiable full-history path.
Leaving this as a TODO inside #12695 creates two failure modes:
The final release note ships without an exhaustive-history path, making the curated body look like omission rather than design.
The release-note PR tries to hand-build lists late in the cycle, creating stale counts and unreviewable churn.
The Architectural Reality
Release-note content lives under resources/content/release-notes/ and is indexed by buildScripts/docs/index/release.mjs into apps/portal/resources/data/releases.json. Discussion #12694 resolved the high-level strategy: curated narrative in the body, generated/reproducible appendices for exhaustive scale.
The underlying source data is already local and public:
resources/content/issues/ for ticket bodies and state snapshots.
resources/content/pulls/ for PR metadata and conversations.
GitHub GraphQL search for fresh merged-PR / closed-issue counts at release cut.
git log and origin/main...origin/dev diff queries for commit/path-level summaries.
ADR 0004 is relevant because release notes and GitHub content live in the same regeneratable resources/content/ substrate and use chunked paths. Any implementation must scan recursively and avoid assuming flat folders.
The Fix
Create the v13 release appendix mechanism that #12695 can consume.
Expected output shape:
A generated or reproducible appendix artifact for v13 merged PRs since the v12.1.0 boundary.
A generated or reproducible appendix artifact for v13 closed issues since the v12.1.0 boundary.
A compact grouped summary suitable for linking or embedding from the v13 release note: labels, epics, major areas, and representative anchors.
A refresh command or documented query recipe that can be rerun immediately before release cut.
Clear separation between exhaustive appendix material and curated release-note prose.
If a new .mjs script is introduced to produce the appendices, the implementer must run the structural-pre-flight skill before choosing its path. If existing build scripts can be reused without new files, prefer that lower-scope route.
AC1: A reproducible v13 merged-PR appendix exists, either as a generated artifact or as a documented command/query recipe with output suitable for #12695.
AC2: A reproducible v13 closed-issue appendix exists, either as a generated artifact or as a documented command/query recipe with output suitable for #12695.
AC3: Appendix generation uses the v12.1.0 release boundary and includes a final-refresh step for counts immediately before release cut.
AC4: Output is grouped enough for a reader to navigate: at minimum by area, labels, epic/source bucket, or another documented release-note grouping axis.
AC5: The #12695 release note can link to or summarize the appendices without inlining every PR and issue in the narrative body.
AC6: Implementation or recipe scans chunked resources/content paths recursively and does not assume flat issue, PR, discussion, or release-note folders.
AC7: If a new .mjs script is added, structural-pre-flight is run before path selection and the script has focused verification evidence.
AC8: Public-surface hygiene is checked: no client names, no private strategy, no unverified counts or stale release-window claims.
Out of Scope
Rewriting the v13 release-note narrative body.
Mining and shaping hero war stories; that is #12698.
Authoring the release-notes skill; #10321 remains parked until after the artifact workflow is known.
Publishing the release, bumping versions, or executing publish.mjs.
Finalizing Body/Grid wording before the wrapper-selection-model lane converges.
Avoided Traps
Rejected: inline mega-changelog in the release note. It is unreadable at v13 scale and contradicts #12694/#12696.
Rejected: hand-maintained exhaustive lists. They will stale before release cut.
Rejected: flat-folder assumptions. ADR 0004 makes chunked recursive scans load-bearing.
Rejected: hiding the appendix behind private memory. The release artifact needs public/reproducible evidence.
Rejected: using the future #10321 skill as authority. The skill should be extracted after this workflow proves itself.
Context
Parent epic #12696 defines v13 as a release epic, not a single release-note ticket. The parent explicitly says exhaustive PR/issue history belongs in generated or reproducible appendices rather than the narrative body. #12695 is the release-note MD spine, #12698 is the war-story mining feed, and #10321 remains parked until the real workflow is known.
This ticket exists because the reset on #12695/#12697 made the gap concrete: the current draft only promises appendices. Prior high-bar release notes include actual changelog material; for v13 scale, the equivalent must be generated or reproducible, not hand-written into the prose.
Pre-creation evidence on 2026-06-07:
appendix generation release notes,v13 appendices release notes, andchangelog appendix release notesreturned only the parent/release-note/war-story tickets, not an appendix leaf.resources/content/issues,resources/content/discussions,resources/content/pulls,.agents/skills, andlearnfound Discussion #12694's appendix strategy plus related historical release-note infrastructure, but no current v13 appendix-generation ticket.ticket v13 release appendices generated changelog appendix release notes exhaustive PR issue listfound no specific ticket for v13 release-note appendices or exhaustive v13 PR/issue lists.Neo v13 Release; this ticket is attached to Project 12 for release visibility.The Problem
The v13 release window is too large for the old "drop in every ticket" approach. The live planning surface currently tracks roughly 1,200+ merged PRs and 1,600+ closed tickets since v12.1.0. The narrative release note must stay curated, but without a generated/reproducible appendix surface the final artifact cannot meet the prior release-note bar or provide a verifiable full-history path.
Leaving this as a TODO inside #12695 creates two failure modes:
The Architectural Reality
Release-note content lives under
resources/content/release-notes/and is indexed bybuildScripts/docs/index/release.mjsintoapps/portal/resources/data/releases.json. Discussion #12694 resolved the high-level strategy: curated narrative in the body, generated/reproducible appendices for exhaustive scale.The underlying source data is already local and public:
resources/content/issues/for ticket bodies and state snapshots.resources/content/pulls/for PR metadata and conversations.git logandorigin/main...origin/devdiff queries for commit/path-level summaries.ADR 0004 is relevant because release notes and GitHub content live in the same regeneratable
resources/content/substrate and use chunked paths. Any implementation must scan recursively and avoid assuming flat folders.The Fix
Create the v13 release appendix mechanism that #12695 can consume.
Expected output shape:
If a new
.mjsscript is introduced to produce the appendices, the implementer must run the structural-pre-flight skill before choosing its path. If existing build scripts can be reused without new files, prefer that lower-scope route.Contract Ledger Matrix
resources/content/pullswith a freshness warningresources/content/**/chunk-*paths recursivelyDecision Record impact
Aligned with ADR 0004. This ticket consumes the chunked/regeneratable
resources/content/architecture and must not reintroduce flat-path assumptions.Discussion Criteria Mapping
Acceptance Criteria
resources/contentpaths recursively and does not assume flat issue, PR, discussion, or release-note folders..mjsscript is added, structural-pre-flight is run before path selection and the script has focused verification evidence.Out of Scope
publish.mjs.Avoided Traps
Related
learn/agentos/decisions/0004-github-content-architecture.mdOrigin Session ID: e8f07ef9-ef7e-4815-8ff4-7abe13720621
Retrieval Hint:
v13 release appendices generated changelog merged PR closed issue list release notes appendix ADR 0004 recursive content scan