Fix ia-candidate marker HTML-comment wrapper loss (kotkan/claude-plugin-inference-arbitrage#23) #27
Reference in New Issue
Block a user
Delete Branch "fix/issue-23-marker-wrapper"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes kotkan/claude-plugin-inference-arbitrage#23.
Root cause.
bin/filing-planandreferences/issue-template.mdalways render theia-candidatemarker HTML-comment-wrapped (<!-- ia-candidate: <id> -->). A directissue_writeprobe against the live Gitea (create + update with a literal<!-- -->in the body, then read it back) confirmed the Gitea MCP write path preserves the wrapper unchanged — so the loss on oleks/claude-plugin-cluster#56 and #57 did not happen infiling-plan's rendering or in the Gitea/MCP write path. It happened on the relay hop:Agent(anxious:issuer-agent)composing the actual Gitea call from a prompt that inlined the rendered body as bare markdown. An HTML comment is invisible when read as markdown, so the relaying agent could describe/retype "what the body says" without ever seeing (and thus reproducing) the marker line.Fixes, both implemented per the issue's ask:
bin/filing-plan:marker_re()/find_existing()now also match the bare, unwrappedia-candidate: <id>line (end-of-line anchored underre.MULTILINE, not\b— candidate ids contain-, and a word-boundary check would false-match a longer id sharing a prefix, e.g.label-derivationinsidelabel-derivation-longer). This is backward compatibility for already-filed issues like cluster#56/#57, not a second accepted format going forward.skills/offload-audit/SKILL.md§5d: theissuer-agentdelegation prompt now embeds the rendered body inside its own fenced code block and explicitly warns that the leading marker is an invisible-by-design HTML comment, not stray syntax to "clean up" — instead of inlining it as bare markdown the relaying agent could read straight through.references/issue-template.md: documents the failure mode and both fixes under "The marker is load-bearing", including the write-path probe evidence.tests/filing.test.sh: new cases — a bare (unwrapped) marker on the tracker is still found and producescomment, not a duplicatefile; a different candidate id that merely shares a prefix with a bare marker still files fresh (guards the\b→end-of-line regex fix against a false-positive regression).Also bumped
plugin.jsonto0.7.1.Verification
exit 0.
Not armed for auto-merge — leaving that to the parent session per standing process.