afx spawn hands builders an unrelated old spec when the issue number collides with a zero-padded filename

[pseudoseed]

What happened

afx spawn 63 --protocol experiment pointed the builder at:

codev/specs/0063-tower-dashboard-improvements.md

That is a real, already-shipped spec about the Tower dashboard, SSH remote and ttyd. The builder's actual assignment was GitHub issue #63, which is a v2 UI dark-palette design task and shares nothing with it.

The builder read the spec, believed it, and spent about an hour producing a competent finding about the wrong subject: "Hypothesis holds: do not implement spec 0063 as written. One-row + Create are additive. SSH remote and ttyd are not."

Root cause

afx spawn <n> derives a spec path by zero-padding the issue number to four digits. This repo has two numbering conventions living side by side:

• Old, zero-padded: codev/specs/0038-consult-pr-mode.md, 0039-codev-cli.md, 0063-tower-dashboard-improvements.md
• Current, unpadded: codev/specs/469-..., 494-..., 52-v2-server-events.md

So any new issue whose number collides with an old zero-padded spec gets handed that spec as its assignment.

This is not the first time

Three builders hit it today:

Spawn	Prompt pointed at	Outcome
afx spawn 38	0038-consult-pr-mode.md (2025 TICK)	Builder noticed and worked the issue
afx spawn 39	0039-codev-cli.md (shipped)	Builder noticed and worked the issue
afx spawn 63	0063-tower-dashboard-improvements.md	Builder did not notice. Wrong work delivered

Two out of three caught it. That is not a safety property — it is luck, and it depends on a builder being suspicious of its own assignment.

The failure is silent and confident: the file exists, it is a real spec, it is well written, and nothing signals that it belongs to different work.

Why it is worse than a wasted hour

A builder that trusts the named spec will produce a coherent, well-argued deliverable for the wrong problem, which is harder to spot in review than an obvious error. The two builders that caught it did so because the subject matter was visibly unrelated. Where an old spec is merely adjacent to the new issue, nobody would catch it at all.

Suggested fix

1. The issue is the source of truth; make the spawn prompt say so. Reference the issue and let the builder resolve artifacts from it, rather than asserting a spec path that may not correspond to anything.
2. Do not conjure a path that was not verified to belong to this work. If codev/specs/<n>-*.md does not exist for the unpadded number, say "no spec exists yet" rather than falling back to a zero-padded match. An absent spec is a fact worth stating; a wrong one is not.
3. If a zero-padded file matches but an unpadded one does not, warn loudly at spawn: this path may belong to unrelated older work.

Point 2 is the same principle already load-bearing elsewhere in this codebase: "I could not tell" must never be spelled the same way as an answer. Right now "no spec for this issue" is spelled identically to "here is your spec."

Cost so far

One builder-hour on issue #63, plus the architect time to detect and redirect. Caught only because the wrong-subject output was obviously wrong.

[pseudoseed]

This is systemic, not incidental

The main architect diagnosed the scale, and it is much larger than this issue assumed.

This fork restarted issue numbering at 1 against a tree carrying legacy artifacts numbered into the 1400s. 116 of the 175 specs here are zero-padded. So every new issue below roughly cluesmith#1470 has a zero-padded twin waiting to be handed to a builder in its place.

That reframes the fix. This is not a rare collision to warn about — it is the default case for every issue we will file for a long time. A warning that fires on nearly every spawn is noise, and will be trained past within a week.

Third occurrence today, across two different code paths:

Where	What happened
Consult (project 13)	0013-document-os-dependencies.md handed to a review consultation. Fixed in #50, merged
afx spawn (issue 63)	0063-tower-dashboard-improvements.md handed to a builder. This issue

Two independent code paths performing the same zero-pad fallback means the fix probably belongs in artifact resolution rather than in each caller.

Handing this to , who owns the consult-side fix and found the pattern.

[pseudoseed]

Reopening — this was closed against the wrong half.

#69 fixed the spawn-side lookup, and the uiv2 architect confirmed by observation that it works: afx spawn 83 resolved codev/specs/83-v2-client-shell.md correctly with 0083-protocol-agnostic-spawn.md sitting right beside it.

The consult lane was still broken. codev/plans/ held only 0083-protocol-agnostic-spawn.md, so 11 consecutive consult --type spec --issue 83 rounds each attached a stale January draft as "the plan" and every reviewer flagged it as unrelated. The artifactHeading warning fired and was correct — it just does not help, because the round is spent either way.

#108 drops a secondary artifact that resolved only by zero-stripping, and says on stderr why. The primary artifact keeps the lenient fallback, since you asked for it by id and genuinely zero-padded legacy projects must still resolve.

Worth recording: this is not a one-file collision. 82 project ids in this repo have only a zero-padded plan. Issue #6 here — an open, unrelated CI bug — resolves to 0006-tutorial-mode today.

On renumbering 0083-protocol-agnostic-spawn.md: it is a reasonable cleanup on its own merits (2026-01-27, Status: Draft, no review, last touched only by the March af→afx rename), but it fixes project 83 and leaves 81 others, so I have not treated it as the fix. Renumbering the whole inherited set is a separate decision.