An id reused for a different concept resolves perfectly, to the wrong thing — and nothing tells an agent to check.
From #114's proving run, finding C. It was proposed in the report and never filed.
What happens
helm anchors a mark to the fence identifier, which is what makes anchors survive a rewrite (#113, measured: 8/8 identifiers held while 7/8 DOM ids moved). But an identifier is only as stable as its meaning. If an agent rewrites a diagram and reuses #bridge for a different node — a rename, a refactor, a diagram that grew a second bridge — the operator's old mark resolves cleanly and silently to the new one.
helm cannot detect this and never could. There is nothing in the DOM, the fence or the sidecar that distinguishes "the same node" from "the same name". This is not a defect in the anchor mechanism; it is the boundary of what an identifier can promise.
Why it is nearly free to fix
The sidecar already carries what is needed. An entry is written as the identifier and the label together:
`#bridge` — "helmCanvas bridge"
So an agent reading a note has both halves and can check that the label still describes the node it is about to act on. That is a complete verification and it costs one comparison.
Nothing anywhere says to do it. Confirmed against .claude/skills/helm-canvas/SKILL.md as of 464a52d: the skill documents the anchor families, the four that carry the fence identifier, and what degrades to a quote — and never tells the reader that the label is there to be checked, or why they would want to.
What to do
A sentence in the helm-canvas skill, in the section that already explains mermaid anchoring. Something to the effect of: the sidecar carries the identifier and the label; if the label no longer matches the node the identifier now names, the mark predates a rewrite that reused the name — ask rather than act.
Deliberately documentation and not code. A code-side check would have to guess at what "the same concept" means, which is exactly the judgement the agent is better placed to make and the operator is best placed to settle.
Acceptance
- The skill tells an agent that a mark carries a label, and what a mismatch means.
- No code change; no new mechanism.
- If the
helm-canvas gate can execute the claim (it extracts and runs snippets today), it should — otherwise say why not.
An id reused for a different concept resolves perfectly, to the wrong thing — and nothing tells an agent to check.
From #114's proving run, finding C. It was proposed in the report and never filed.
What happens
helm anchors a mark to the fence identifier, which is what makes anchors survive a rewrite (#113, measured: 8/8 identifiers held while 7/8 DOM ids moved). But an identifier is only as stable as its meaning. If an agent rewrites a diagram and reuses
#bridgefor a different node — a rename, a refactor, a diagram that grew a second bridge — the operator's old mark resolves cleanly and silently to the new one.helm cannot detect this and never could. There is nothing in the DOM, the fence or the sidecar that distinguishes "the same node" from "the same name". This is not a defect in the anchor mechanism; it is the boundary of what an identifier can promise.
Why it is nearly free to fix
The sidecar already carries what is needed. An entry is written as the identifier and the label together:
So an agent reading a note has both halves and can check that the label still describes the node it is about to act on. That is a complete verification and it costs one comparison.
Nothing anywhere says to do it. Confirmed against
.claude/skills/helm-canvas/SKILL.mdas of464a52d: the skill documents the anchor families, the four that carry the fence identifier, and what degrades to a quote — and never tells the reader that the label is there to be checked, or why they would want to.What to do
A sentence in the
helm-canvasskill, in the section that already explains mermaid anchoring. Something to the effect of: the sidecar carries the identifier and the label; if the label no longer matches the node the identifier now names, the mark predates a rewrite that reused the name — ask rather than act.Deliberately documentation and not code. A code-side check would have to guess at what "the same concept" means, which is exactly the judgement the agent is better placed to make and the operator is best placed to settle.
Acceptance
helm-canvasgate can execute the claim (it extracts and runs snippets today), it should — otherwise say why not.