Step 7's managed blocks collide with hand-written content in a Consumer that predates /setup

/setup 0.25.0 Step 7 appends a marked block to CLAUDE.md and to each line-based ignore file it finds. In a Consumer that was installed by hand before /setup existed, both targets already carry the same content under no markers — so the first run produces a duplicate rather than a patch.

Measured 2026-08-25 against DXP-DesignSystem on origin/develop, by reading commands/setup.md § Step 7 against the Consumer's two files. Not run: the Consumer is on 0.24.2 and /setup has not been run there yet, so this is a read of what the run will do, not a report of what it did.

Two collisions

• CLAUDE.md. The managed block opens with ## unic-archon-dlc. DXP-DesignSystem/CLAUDE.md already carries a hand-written section under that exact heading — 25 lines naming the two config files, the tracker contract and two Archon defects. Step 7's rule is "absent block in a file that exists → append it", so the run appends a second ## unic-archon-dlc heading. Nothing is lost and the document reads as if it says everything twice.
• The formatter ignore file. The managed block carries .archon/methods/, .archon/workflows/ and *.generated.*. All three already sit in the Consumer's .prettierignore as hand-written entries, two of them under hand-written comments explaining why. The run duplicates all three inside markers. Prettier tolerates a duplicate pattern, so this is noise rather than breakage — but the hand-written comments are the reason a future reader keeps the entries, and a marked block beside them does not say which pair wins.

Why it is worth a ticket rather than a shrug

The install path /setup is designed for is a fresh Consumer, and the Consumer that exists is the other kind. Every Consumer installed before 0.25.0 hits this on its first run, and the map's own bar for a Box is that it runs where it ships.

What a fix might weigh

Stated as options, not a decision — this needs the design call the command's ADRs own.

• Adopt, then patch. Where the run finds content that matches what the block would say, wrap it in the markers rather than appending beside it. Cheapest for the reader, and it is the one option that has to decide what "matches" means.
• Report instead of append. Treat an unmarked collision the way Step 6 treats a tenant file: print the block, say where it collides, change nothing. Consistent with the report treatment already in the command, and it leaves the operator one paste.
• Append and say so. Keep the behaviour, and have Step 8's summary name the collision it just created. Cheapest to build, and it relies on the operator reading the diff — which the map has already recorded failing once (pnpm format rewrote thirteen Methods before anyone noticed).

Found while writing the Consumer's docs/agents/figma.md for #414, whose second deliverable was rewriting the "/setup must not be run here" passage to the truth 0.25.0 made of it.

Read commands/setup.md § Step 7 and Step 8, then inspect the command's ADRs and the Consumer's CLAUDE.md and .prettierignore. Decide how an unmarked block matching managed content should be handled, and verify that the first /setup run does not create duplicate headings or ignore patterns while preserving the existing comments.