Archive Issue

Step 3 — Write the hub page

.wiki/issue-NNN.md (zero-padded to 3 digits). The metadata line is mandatory and must preserve every correlation key, since specs/ is about to be emptied of them:

**Plan task:** #P<X>-<Y> · **Phase:** <X> · **PR(s):** #NN[, #MM…] · **Closed:** YYYY-MM-DD · [GitHub issue #N](url)

• No plan-task ID → **Plan task:** — (unphased), and this issue's index entry goes under ## Unphased in Step 5, not a phase heading.
• No PR (branch-mode review, or no review at all) → **PR(s):** — (branch review) or **PR(s):** — respectively; never omit the field.
• Absorbed another task → note it in the overview paragraph below the metadata line (e.g. "absorbs #P0-5"), not as a second metadata field or a second index entry.

Below the metadata line: a paragraph of what shipped (pull from the issue body's Summary — don't re-derive it), a bullet list linking each sub-page that exists, and a one-line Outcome pulled from the acceptance criteria / review verdict. Follow the shape of the wiki's existing issue-013.md (the worked example referenced in specs/wiki-structure.md) for the overview/Outcome prose style.

Link sub-pages by bare basename, never full path. Write [Label](CODE-REVIEW-PR-63), not [Label](issue-NNN/CODE-REVIEW-PR-63.md) — even though the file lives at issue-NNN/CODE-REVIEW-PR-63.md. GitHub's wiki renders a .md-suffixed link as a raw-file link instead of a wiki-page link, which silently breaks navigation (this regressed for issues #20–#26 before being caught and fixed — see the Rules in specs/wiki-structure.md). Drop both the issue-NNN/ directory prefix and the .md extension in the link text; the directory nesting is only for organizing the wiki's git tree.

Step 4 — Write the sub-pages

Carry the REQ/ARCH/review content over largely as-is — these are already well-formed docs; don't rewrite them, just relocate them into .wiki/issue-NNN/ under their original filenames and drop anything that's now stale (e.g. a REQ doc's "next step: run /plan-architecture" footer no longer applies once archived). The sub-page vocabulary is open — REQ/ARCH/CODE-REVIEW cover the common case, spike findings and ADR/decisions docs (whatever they're actually named) cover the rest — but every one keeps its specs/ filename verbatim. Never invent a placeholder for a document that doesn't exist, and never rename one that does.

Step 5 — Update the index

Both .wiki/Home.md and .wiki/_Sidebar.md use the same phase-grouped structure (specs/wiki-structure.md's "The model" section):

• Determine the group: the phase from Step 1 (## Phase <X> — <name>), or ## Unphased if the issue has no plan-task ID.
• Find or create the heading. If this is the first issue archived into that phase in either index file, create the ## Phase <X> — <name> (or ## Unphased) heading — append new phase headings in phase order, with ## Unphased last. On Home.md, a newly created phase heading gets a ✓/◐ status marker read from that phase's current exit-criteria state in specs/claude-lens-plan.md.
• Insert in issue-number order within the group — find the correct ascending position among that group's existing entries, not just appended at the end.
• Refresh the phase's ✓/◐ marker on Home.md if plan.md's exit criteria for that phase have changed since the marker was last set — this can catch drift beyond just the issue being archived right now (e.g. stale checkboxes elsewhere in plan.md); fix plan.md too if you find it.
• Create .wiki/Home.md / .wiki/_Sidebar.md (with a one-line header, phase-grouped) if this is the first archived issue overall.

Step 6 — Retire the sources from the main repo

Remove the archived files from the main repo (git rm, in the main repo, not .wiki/) — specs/issues/<ID>-<slug>.md, specs/context/<N>.md, whichever of specs/requirements// specs/architecture/ were mirrored, and every matching review report wherever Step 2 found it (specs/reviews/, repo root, specs/review/, or elsewhere) — remove from its actual location, not an assumed one. This is the "leave nothing behind" half of the convention: once an issue is archived, nothing about it should remain anywhere in the main repo — not just specs/. Commit this to the main repo separately from the wiki push in Step 7 — they're two different repos with two different histories.

Step 7 — Commit and push the wiki, with confirmation

Inside .wiki/: git add, commit (batch multiple issues archived in one pass into one commit if convenient), then push to origin. Pushing to the wiki repo is a push to shared external state — confirm with the user before pushing, same as any other push, even though the commit itself is harmless to make locally. Report what moved where (source path → wiki page) so the user can review before/after the push.