Enforce exact-title and semantic duplicate stop before issue creation #207

Closed
opened 2026-07-05 15:24:46 -05:00 by jcwalker3 · 0 comments
Owner

Problem:
Author agents can create duplicate hardening issues even after claiming they performed a duplicate search. This creates duplicate process walls, splits implementation work, and makes the issue tracker less reliable.

Observed failure:
An agent created Gitea-Tools issue #202:

"Add hard queue-target resolution wall before PR inventory or empty-queue claims"

But a prior run had already created Gitea-Tools issue #201 with the same title and same purpose. Live reconciliation while filing this issue found it is in fact a triple: #200, #201, and #202 all carry the identical title — three parallel author sessions each filed the same wall within minutes, each presumably after its own "duplicate search" against a list fetched before the others' creations landed.

The #202 report claimed duplicate-search compliance, but its duplicate summary did not mention #201 (or #200) at all. It searched/read nearby issues like #194, #196, and PR #195, while missing the exact duplicate: the open-issue list it used was fetched before #200/#201 existed, and no final pre-create title check was performed at mutation time. This is a time-of-check/time-of-use failure — the wall must run immediately before creation, not at selection time.

Required wall:
Before creating any issue, the issue-authoring workflow must perform an exact-title and semantic duplicate check. If an exact title match exists in open or recently closed issues, issue creation must be blocked.

Required behavior:

  • Search exact title string before semantic search.
  • Search both open and recently closed issues.
  • Search by normalized title: lowercase, punctuation-insensitive, whitespace-normalized.
  • If an exact or near-exact duplicate exists, stop and report the existing issue number.
  • Do not create a new issue and do not "layer" a duplicate unless the operator explicitly approves splitting after seeing the duplicate.
  • Duplicate-search summary must include the exact query used and the top matching issue numbers/titles.

Acceptance criteria:

  • Add a test where an issue with the exact same title already exists; expected result: issue creation blocked.
  • Add a test where the title differs only by issue number, punctuation, capitalization, or wording like "hard wall" vs "wall"; expected result: duplicate warning/fail closed.
  • Add a test where duplicate search misses an exact title match; expected result: creation blocked by a final pre-create title check.
  • Add a test where the agent claims "20 open issues searched" but omits the exact duplicate from the summary; expected result: invalid duplicate proof.
  • Add a test where the operator explicitly approves a split after seeing the duplicate; expected result: allowed only with a clear relationship recorded in the new issue body.
  • The create-issue tool should reject creation when the normalized title matches an existing open issue unless an explicit override flag is provided.

Suggested implementation:
Add a pre_create_issue_duplicate_gate that runs immediately before gitea_create_issue. It should be independent of the LLM's written duplicate-search summary and should use exact-title lookup plus semantic duplicate detection. The gate must return duplicate_found, no_duplicate_found, or ambiguous_duplicate_stop. Because the observed failure is TOCTOU (list fetched before a concurrent session's creation), the gate must re-query at create time inside the tool path — an LLM-side check alone cannot close the race. Gate enforcement belongs in gitea_create_issue itself (server-side re-query + normalized-title match + override flag).

Related:

  • Origin evidence: #200 / #201 / #202 (identical triple; #202's cleanup is being handled by its authoring session — duplicates closed in favor of the canonical lowest-numbered issue).
  • #191 — issue-filing report hardening: requires the duplicate-search summary; this issue adds the enforced gate that is independent of that summary.
  • #204 — exact issue lock before branch/commit/push/PR: same lock-before-mutate philosophy at the implementation stage; this issue covers the creation stage.
  • mcp-control-plane #74 — duplicate-issue triage wall for reviewer-only sessions: post-hoc triage side of the same problem.
  • #183 — exact mutation capability proof lineage for author runs.
Problem: Author agents can create duplicate hardening issues even after claiming they performed a duplicate search. This creates duplicate process walls, splits implementation work, and makes the issue tracker less reliable. Observed failure: An agent created Gitea-Tools issue #202: "Add hard queue-target resolution wall before PR inventory or empty-queue claims" But a prior run had already created Gitea-Tools issue #201 with the same title and same purpose. Live reconciliation while filing this issue found it is in fact a **triple**: #200, #201, and #202 all carry the identical title — three parallel author sessions each filed the same wall within minutes, each presumably after its own "duplicate search" against a list fetched before the others' creations landed. The #202 report claimed duplicate-search compliance, but its duplicate summary did not mention #201 (or #200) at all. It searched/read nearby issues like #194, #196, and PR #195, while missing the exact duplicate: the open-issue list it used was fetched before #200/#201 existed, and no final pre-create title check was performed at mutation time. This is a time-of-check/time-of-use failure — the wall must run immediately before creation, not at selection time. Required wall: Before creating any issue, the issue-authoring workflow must perform an exact-title and semantic duplicate check. If an exact title match exists in open or recently closed issues, issue creation must be blocked. Required behavior: * Search exact title string before semantic search. * Search both open and recently closed issues. * Search by normalized title: lowercase, punctuation-insensitive, whitespace-normalized. * If an exact or near-exact duplicate exists, stop and report the existing issue number. * Do not create a new issue and do not "layer" a duplicate unless the operator explicitly approves splitting after seeing the duplicate. * Duplicate-search summary must include the exact query used and the top matching issue numbers/titles. Acceptance criteria: * Add a test where an issue with the exact same title already exists; expected result: issue creation blocked. * Add a test where the title differs only by issue number, punctuation, capitalization, or wording like "hard wall" vs "wall"; expected result: duplicate warning/fail closed. * Add a test where duplicate search misses an exact title match; expected result: creation blocked by a final pre-create title check. * Add a test where the agent claims "20 open issues searched" but omits the exact duplicate from the summary; expected result: invalid duplicate proof. * Add a test where the operator explicitly approves a split after seeing the duplicate; expected result: allowed only with a clear relationship recorded in the new issue body. * The create-issue tool should reject creation when the normalized title matches an existing open issue unless an explicit override flag is provided. Suggested implementation: Add a `pre_create_issue_duplicate_gate` that runs immediately before `gitea_create_issue`. It should be independent of the LLM's written duplicate-search summary and should use exact-title lookup plus semantic duplicate detection. The gate must return `duplicate_found`, `no_duplicate_found`, or `ambiguous_duplicate_stop`. Because the observed failure is TOCTOU (list fetched before a concurrent session's creation), the gate must re-query at create time inside the tool path — an LLM-side check alone cannot close the race. Gate enforcement belongs in `gitea_create_issue` itself (server-side re-query + normalized-title match + override flag). Related: * Origin evidence: #200 / #201 / #202 (identical triple; #202's cleanup is being handled by its authoring session — duplicates closed in favor of the canonical lowest-numbered issue). * #191 — issue-filing report hardening: requires the duplicate-search *summary*; this issue adds the *enforced gate* that is independent of that summary. * #204 — exact issue lock before branch/commit/push/PR: same lock-before-mutate philosophy at the implementation stage; this issue covers the creation stage. * mcp-control-plane #74 — duplicate-issue triage wall for reviewer-only sessions: post-hoc triage side of the same problem. * #183 — exact mutation capability proof lineage for author runs.
jcwalker3 added the status:in-progress label 2026-07-05 16:18:35 -05:00
sysadmin removed the status:in-progress label 2026-07-05 16:34:51 -05:00
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#207