sync re-registers COMPLETED Superpowers plans as untriaged epics (no done-signal for plan files)

[cfdude]

What happened

Ran /pm:sync in a repo with 18 files in docs/superpowers/plans/. All 18 were registered as new untriaged epics:

conductor: synced (18 new epic(s) added as untriaged)

Every one of them is completed, shipped work — some from March. Verified by checking that the code each plan describes exists in the repo today (src/brokers/ for the broker-abstraction plan, src/tasks/reminder_*.py for the reminder-system plan, src/operations/repair_agent.py, src/operations/scheduler.py, check_alternative_criteria_sets for the multi-criteria-gate plan, etc.).

Root cause

The engine has no signal for "this plan is done." OpenSpec has changes/archive/ as the done-marker; Superpowers plans have no equivalent convention — plan files just sit in plans/ forever. So sync re-registers every plan on disk, every time.

Contributing factor: the plans' task checkboxes were never ticked on completion (17 of 18 read 0/N complete), so even a checkbox heuristic wouldn't have saved it here. But the checkbox state is user discipline; the engine treating presence of a file as pending work is the actual defect.

Why it matters

This is the same class as the archive-scan bug fixed in 0.19.0 (sync scanning openspec/changes/archive/ and re-registering completed changes), just on the Superpowers-plan path instead of the OpenSpec-archive path. The 0.19.0 fix filtered the archive dir; the plans path has no dir to filter.

Impact is worse than noise: it buried 5 genuinely-queued P0/P1 epics under 18 phantom untriaged ones, and the briefing's "NEXT UP" became unusable. If a user triages rather than investigates, they'd schedule work that shipped months ago.

Suggested fixes (in rough preference order)

1. A done-marker convention for plans, mirroring OpenSpec's archive: docs/superpowers/plans/archive/ (or a Status: COMPLETE frontmatter key), filtered by sync the same way 0.19.0 filters changes/archive/.
2. Checkbox heuristic as a secondary signal — if a plan is 100% checked, don't register. Weak alone (see above) but a cheap safety net.
3. At minimum, don't silently bulk-add. When sync would add more than a handful at once, list them and ask before writing. synced (18 new epic(s) added as untriaged) gives no chance to catch this before state.json is rewritten.

Workaround

remove-epic each one. remove-epic exists as of 0.19.0, so cleanup is at least scriptable now — it just shouldn't be necessary.

Environment

• pm engine 0.23.1
• Repo has both openspec/ and docs/superpowers/plans/

[cfdude]

Confirming the checkbox half against tasks.md — and pushing back on "user discipline"

Separate repo (cfdude/personal-finance-paper), same engine (0.23.1). I went to verify a
suspicion that the 0/N progress counts in PROJECT.md were a counter bug, and found the
opposite — which sharpens one line in this issue.

The counter is correct. For the one epic that doesn't read 0/N:

$ rg -c '^\s*-\s\[ \]' docs/superpowers/plans/2026-03-31-trading-settings-consolidation.md
97
$ rg -c '^\s*-\s\[x\]' docs/superpowers/plans/2026-03-31-trading-settings-consolidation.md
6

6/103 is arithmetically right. The plan files are stale, not the arithmetic. Full audit of
every plan-backed epic in this repo:

plan-backed epics, all status: done	15
checked boxes	6
unchecked boxes	717
reported progress	6/723 = 0.8%

Fourteen of the fifteen read exactly 0/N.

The work did ship — spot-checked the artifacts each plan describes:

trading_settings rows in DB : 92          (trading-settings-consolidation)
src/operations/scheduler.py : EXISTS      (unified-task-scheduler)
src/tasks/                  : EXISTS, 10 modules  (reminder-system-and-task-worker)
src/operations/repair_agent.py : EXISTS   (autonomous-repair-agent)

So this repo independently reproduces the contributing factor at a larger N (15 plans, 723
boxes), which I think strengthens the case for suggested fix #1.

Where I'd push back: this issue calls the checkbox state "user discipline." I don't think
that holds, because there is no way to exercise that discipline through the tool. The full verb
list in 0.23.1:

init|render|brief|snapshot|commit-nudge|sync|log-detour|honcho-memory|add-epic|add-many|
update-epic|remove-epic|set-active|clear-active|set-tracker|set-lane-routing|suggest-lane|
set-autonomy|record-reconcile|record-gate-review|set-review-mode|set-gate-guard|gate-guard|
plan-hierarchy|verify-worktrees|verify-state|changesets|upgrade|changelog|rules|write-rules

Nothing ticks a checkbox. The plugin derives progress from checkboxes, instructs agents
to keep them truthful (the generated repo rule: "Keep tasks.md checkboxes truthful — they are
the source of truth for story progress"), and provides no mechanism to write them. The only
route is hand-editing markdown, which is precisely the failure mode the pm rules already call
out as having recurred silently across sessions for the done flag.

That reframes it: 717 stale boxes across 15 epics isn't 15 users forgetting, it's a missing
writeback path. Which also means suggested fix #2 (checkbox heuristic as a secondary signal) will
stay unreliable until something can actually set them — a tick/complete-story verb, or having
update-epic --status done offer to check off the plan's boxes, would make the heuristic
trustworthy rather than just better-informed.

Happy to split the missing-verb part into its own issue if you'd rather keep this one scoped to
the sync-re-registration defect.

[cfdude]

Reproduced live on cfdude/pm itself — three times in one /pm:sync, one of them a duplicate of the ACTIVE epic

Ran /pm:sync on this repo today. The engine reported:

conductor: sync skipped plan '2026-07-14-epic-hierarchy-orchestration' — id already exists
conductor: synced (3 new epic(s) added as untriaged)

All three were phantoms — every one of them duplicates work that already has an epic:

Plan file registered as a new epic	The epic that already existed	Its status
2026-07-21-conductor-mjs-module-split	conductor-mjs-module-split	archived
2026-07-26-edd-harness-agent-behavior-testing	edd-harness-agent-behavior-testing	archived
2026-07-29-platform-aware-rules-block	rules-block-hardcodes-claude-slash-commands	active

The third is the sharpest illustration: sync created an untriaged duplicate of the epic that was active at that moment — the one whose plan file had just been written, in the same session, for the epic already being worked. Two archived epics were resurrected as new work.

Why the existing guard misses it. The skipped plan ... id already exists line proves there is a dedup check, but it matches on the plan's filename-derived id. None of these three plan files is named after its epic:

• plan 2026-07-29-platform-aware-rules-block → epic rules-block-hardcodes-claude-slash-commands
• plan 2026-07-26-edd-harness-agent-behavior-testing → epic edd-harness-agent-behavior-testing (same words, but the date prefix defeats an exact-id match)

So the guard only fires when a plan happens to be named exactly like its epic. Any epic whose plan is named differently — which is the normal case, since plan filenames are date-prefixed and epic ids are not — is re-registered on every sync, forever.

This looks like the same root cause as #64, which reports the duplicate-for-already-shipped-plan case. #64 is the "already shipped" symptom and this issue is the "no done-signal" framing; both come from dedup keying on a filename rather than on a link between plan and epic. Worth fixing once and closing both.

Suggested direction, since a done-signal for plan files is the stated gap: rather than inferring completion, make the plan→epic association explicit and check that. An epic already has a plan field; if sync skipped any plan file already claimed by some epic's plan, all three phantoms above would have been suppressed regardless of naming or status. That also sidesteps needing a completion heuristic at all.

Note this interacts with #66: update-epic has no --plan flag, so there is currently no CLI path to attach a plan to an existing epic — which means the plan field can't be populated for the very epics that need it. #66 may need to land first.

Impact for anyone auditing: PROJECT.md's untriaged count and the briefing both inflate on every sync, and the noise is indistinguishable from real new work until you cross-check each id by hand. I removed all three with remove-epic.

Environment: pm 0.23.1, macOS.