351 of 389 @spec anchors dangle — opsx-archive moved the specs and left every annotation behind (the @spec counterpart of #301)

[rubenvdlinde]

Summary

351 of larpingapp's 389 @spec annotations point at a path that does not exist. They were left behind by opsx-archive: archiving moves openspec/changes/<c>/… to openspec/changes/archive/<c>/…, and nothing repoints the annotations that referenced the old location.

Nothing reports this. gate-16 counts the presence of a @spec tag, never whether it resolves — so larpingapp reports perfect spec coverage while ~90% of its tags are dangling.

This is the @spec counterpart of #301, which found the same thing for 20 @e2e tags.

Measured

Resolver over every tracked .php/.ts/.js/.vue, with a positive control built in (it refuses to report unless at least one anchor resolves):

RESOLVING anchors : {'spec': 38, 'e2e': 114}     <- positive control, the matcher works
DANGLING anchors  : 374                          ({'spec': 351, 'e2e': 23})

Top dangling targets:

count	target
235	openspec/changes/retrofit-2026-05-24-annotate-larpingapp/tasks.md
25	openspec/changes/event-checkin-roster/specs/event-checkin-roster/spec.md
19	openspec/changes/skill-requirement-enforcement/specs/skill-requirement-enforcement/spec.md
17	openspec/changes/skill-tree-visualization/specs/skill-tree-visualization/spec.md
15	openspec/changes/retrofit-2026-05-25-larpingapp-frontend/tasks.md
12	openspec/changes/event-runsheet-export/specs/pdf-export/spec.md

Worst files: CharactersController.php 38, CharacterService.php 30, RegisterObjectFetcher.php 29, DeepLinkRegistrationListener.php 23, SettingsController.php 21.

Confirmation that archiving is the cause — for skill-requirement-enforcement:

openspec/changes/skill-requirement-enforcement/specs/…/spec.md          -> does NOT exist  (19 anchors point here)
openspec/changes/archive/skill-requirement-enforcement/specs/…/spec.md  -> exists
openspec/specs/skill-requirement-enforcement/spec.md                    -> exists  (the correct target)

There are 32 archived changes in this repo.

gate-16 measurement, for the record

Re-measured with an explicit base per ConductionNL/.github#361, on 526bbc5f (= origin/development = the headSha of full-scope run 31490125155):

HYDRA_GATE_BASE_REF	# count=
origin/development	0
origin/beta	0
empty tree 4b825dc… (full tree)	0
--mode report (not diff-scoped)	uncovered_count: 0

Proven alive with a committed planted true positive (IdListNormaliser::countProbeIds(), no @spec) → # count=1 at all three bases, naming the plant; reverted. So gate-16's PASS here is honest about tag presence — and that is a different claim from "traceability works".

Suggested resolution

Do not bulk-rewrite changes/ → changes/archive/. The project rule is that @spec targets the canonical openspec/specs/<capability>/spec.md, never a change directory — and the largest block (235) points at a tasks.md#task-N, which is the wrong kind of artifact regardless of the path.

1. Repoint to the canonical openspec/specs/… spec, per file, verifying the target section actually describes what the annotated method does.
2. The 235 retrofit-…/tasks.md#task-N anchors need a decision: they encode "this method was annotated during the retrofit", not a requirement, and arguably should be replaced by a real spec reference or dropped.
3. Worth raising in ConductionNL/.github: opsx-archive should either repoint annotations or refuse to archive while annotations reference the change path. A git mv of a spec tree is a silent mass-dangling event and no gate in the suite reports it.

[rubenvdlinde]

78 of the 351 closed mechanically in #311 — and here is why the other 273 are not a bulk edit

Re-measured with the round-1 resolver (positive control built in: it refuses to
report unless anchors resolve):

	before	after
RESOLVING @spec	38	116
RESOLVING @e2e	114	122
DANGLING total	374	296
DANGLING @spec	351	273

What was fixed

Only the mechanical shape: openspec/changes/<change>/specs/<Y>/spec.md →
openspec/specs/<Y>/spec.md, and only where the canonical target was verified to
exist first. 78 anchors, 21 sites, 19 files, 11 distinct path pairs.

What was deliberately left alone, and why

The 22 @e2e anchors of the same shape stay dangling. All 22 live in
tests/e2e/spec-coverage/spa-ui.spec.ts and all point at the five *-leaf specs
— features that are unbuilt (#184–#188, #302). #301 already establishes that
retargeting their inert tags manufactures a false green: a resolving @e2e is
scored as coverage by gate-19 whether or not the test exercises the scenario, so
repointing them would drop the gate-19 number without one new assertion existing.
The split turned out clean — every one of the 78 moved is @spec, and no file
mixes the two kinds for the same path, so the safe subset needed no judgement
calls at all.

The 273 remaining dangling @spec anchors are not mechanically fixable.

235  openspec/changes/retrofit-2026-05-24-annotate-larpingapp/tasks.md
 15  openspec/changes/retrofit-2026-05-25-larpingapp-frontend/tasks.md
  5  openspec/changes/retrofit-2026-05-26-preferences-api/tasks.md

255 of them target a tasks.md#task-N inside a retrofit change directory. That is
the wrong kind of artifact as well as a dead path — @spec must target
canonical openspec/specs/. There is no path rewrite that produces a correct
target; each needs a per-tag judgement about which requirement it actually
describes. Guessing them in bulk would replace 235 anchors that point at nothing
with 235 that point at the wrong thing, which is strictly worse: a dangling anchor
is at least visibly broken.

Left for a change that can make that judgement.

Verified unchanged by the repoint, same tree

gate-19 42 (no @e2e anchor moved), gate-16 # count=0,
composer check:strict ALL PASSED, 201 tests / 683 assertions.

⚠️ Worth recording for the fleet: gate-16 counts the PRESENCE of a tag and never
checks that it resolves, so # count=0 was compatible with 90% of this app's
@spec tags pointing at a path that does not exist. "0 findings" and
"traceability works" are different claims. No gate in the suite reports a git mv
of a spec tree, which is how these get created 235 at a time.