You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Retrospective for the merge of #628 (closed #625, refs #501). Per the repository standard requiring a repair review after each merge. This is a genuinely new merge (not a follow-up of an existing retrospective's action item — #625 follows the taxonomy-tracking issue #501, not a retrospective), so per the repo's retrospective-follow-up convention it gets its own issue.
PR overview
PR #628 added a server-container rail entry to the template Library UI (web/src/components/Library.tsx) and consolidated 15 container-runtime/orchestration templates into (category: "server", subCategory: "コンテナ"): the existing Docker (8) and Podman (2) server sub-categories, plus 4 templates moved in from ai/ops. Merged from a single branch, 5 commits (1 design-doc, 1 plan-doc, 1 data-migration + drift-gate, 1 docs-fix, 1 UI rail entry), +648/-24 across 6 files.
Repairs between PR open and merge
None. CI (Web CI, Test and Build - on pull request, Dependency Review) was already green by the time the PR was opened or finished green with no intervention shortly after; mergeable_state reached clean. Zero review threads. The two automated comments (Vercel preview deployment, Dependency Review) were both informational/passing, requiring no action.
One CI job (Web Vitest (Pyodide keystone)) shows a failure in the branch's history, but on an earlier commit (89588e0, the plan-doc-only commit, pushed before any templates.ts/Library.tsx change existed) — the same job passed on the next push (the PR's actual head, e22f03f) with no code change of mine plausibly explaining the difference. Recorded for transparency; not investigated further since it isn't reproducible at HEAD and predates the functional change. Not classified as a repair.
Repair during implementation (before PR open) — recurrence of #617's finding, not a new one
Manual count error in the design doc's own prose, duplicated into the GitHub issue body. While drafting docs/superpowers/specs/2026-07-31-server-container-consolidation-design.md, I hand-counted ops/ポリシー統制's sibling templates from a grep result (15 matching lines) but transcribed the total as "14" in prose (and correspondingly "13 remaining" after the one migration) — an off-by-one that also propagated into issue #625's body. The migration code itself was unaffected (it only ever moves the one explicitly-named template, opa-kubernetes-admission, regardless of the sibling count), so this was a documentation-only defect, not a functional one.
How it was caught: the Task 1 spec-compliance review subagent (dispatched per subagent-driven-development) independently re-derived the count from git show 534e48b:web/src/lib/templates.ts | grep -c ... rather than trusting the design doc's prose, and flagged the mismatch. Fixed in commit e548ef1 (design doc) plus a direct edit to issue Add a server "コンテナ" rail entry and consolidate Docker/Podman/Kubernetes templates into it #625's body — before the PR was ever opened.
Classification: recurrence of Retrospective: PR #616 (middleware category consolidation) merge review #617's "Repairs during implementation" item 2 (also a hand-tallied count in a design doc's summary, also caught by a subagent recomputing from real data instead of trusting the doc). Retrospective: PR #616 (middleware category consolidation) merge review #617 proposed a durable fix in prose ("any count claim in a spec/plan doc... should be computed by a one-line script and pasted as output, not hand-tallied") but — as far as this session found — never turned that proposal into a tracked, actionable item; it stayed as retrospective narrative. This PR's identical mistake, ~14 hours later, is direct evidence that leaving a durable-fix proposal as retrospective-issue prose does not reliably produce the fix. Filing this as a recurrence per the retrospective-chain-bounding convention (#624's precedent), not re-deriving the finding from scratch.
Escalation: turning the proposal into an actual tracked item
Per the repo standard ("turn that finding into a durable gate rather than a one-off repair"), repeating #617's prose suggestion a third time in some future retrospective would not be a durable fix — it would be the same non-durable pattern. Opened #630 as a small, standalone, actionable issue scoped to implement #617's original proposal (a documented convention requiring count claims in docs/superpowers/specs/*.md to be backed by an inlined command+output, not hand-tallied), so it has a chance to be picked up and closed rather than re-discovered a third time.
Earliest-gate summary
Both this cycle's near-miss and #617's were caught pre-PR by a subagent independently re-verifying a claim against real data rather than trusting prose — the harness's layered-review discipline is working as designed. The residual, now twice-observed gap is upstream: nothing requires (or checks) that a specific count cited in project documentation is backed by the command that produced it. Tracked as its own actionable item in #630 rather than left as narrative here.
Retrospective for the merge of #628 (closed #625, refs #501). Per the repository standard requiring a repair review after each merge. This is a genuinely new merge (not a follow-up of an existing retrospective's action item — #625 follows the taxonomy-tracking issue #501, not a retrospective), so per the repo's retrospective-follow-up convention it gets its own issue.
PR overview
PR #628 added a
server-containerrail entry to the template Library UI (web/src/components/Library.tsx) and consolidated 15 container-runtime/orchestration templates into(category: "server", subCategory: "コンテナ"): the existingDocker(8) andPodman(2)serversub-categories, plus 4 templates moved in fromai/ops. Merged from a single branch, 5 commits (1 design-doc, 1 plan-doc, 1 data-migration + drift-gate, 1 docs-fix, 1 UI rail entry), +648/-24 across 6 files.Repairs between PR open and merge
None. CI (
Web CI,Test and Build - on pull request, Dependency Review) was already green by the time the PR was opened or finished green with no intervention shortly after;mergeable_statereachedclean. Zero review threads. The two automated comments (Vercel preview deployment, Dependency Review) were both informational/passing, requiring no action.One CI job (
Web Vitest (Pyodide keystone)) shows afailurein the branch's history, but on an earlier commit (89588e0, the plan-doc-only commit, pushed before anytemplates.ts/Library.tsxchange existed) — the same job passed on the next push (the PR's actual head,e22f03f) with no code change of mine plausibly explaining the difference. Recorded for transparency; not investigated further since it isn't reproducible at HEAD and predates the functional change. Not classified as a repair.Repair during implementation (before PR open) — recurrence of #617's finding, not a new one
Manual count error in the design doc's own prose, duplicated into the GitHub issue body. While drafting
docs/superpowers/specs/2026-07-31-server-container-consolidation-design.md, I hand-countedops/ポリシー統制's sibling templates from agrepresult (15 matching lines) but transcribed the total as "14" in prose (and correspondingly "13 remaining" after the one migration) — an off-by-one that also propagated into issue #625's body. The migration code itself was unaffected (it only ever moves the one explicitly-named template,opa-kubernetes-admission, regardless of the sibling count), so this was a documentation-only defect, not a functional one.subagent-driven-development) independently re-derived the count fromgit show 534e48b:web/src/lib/templates.ts | grep -c ...rather than trusting the design doc's prose, and flagged the mismatch. Fixed in commite548ef1(design doc) plus a direct edit to issue Add a server "コンテナ" rail entry and consolidate Docker/Podman/Kubernetes templates into it #625's body — before the PR was ever opened.git grep -cis trivial to run but nothing requires a doc's prose count to actually be backed by a pasted command.#624's precedent), not re-deriving the finding from scratch.Escalation: turning the proposal into an actual tracked item
Per the repo standard ("turn that finding into a durable gate rather than a one-off repair"), repeating #617's prose suggestion a third time in some future retrospective would not be a durable fix — it would be the same non-durable pattern. Opened #630 as a small, standalone, actionable issue scoped to implement #617's original proposal (a documented convention requiring count claims in
docs/superpowers/specs/*.mdto be backed by an inlined command+output, not hand-tallied), so it has a chance to be picked up and closed rather than re-discovered a third time.Earliest-gate summary
Both this cycle's near-miss and #617's were caught pre-PR by a subagent independently re-verifying a claim against real data rather than trusting prose — the harness's layered-review discipline is working as designed. The residual, now twice-observed gap is upstream: nothing requires (or checks) that a specific count cited in project documentation is backed by the command that produced it. Tracked as its own actionable item in #630 rather than left as narrative here.
Refs #625, #501, #617, #630.