bug-hunt run state

[REPPL]

Tracking issue for the autonomous bug-hunt loop over this repository (the abcd Go CLI — cmd/abcd, packages under internal/, record tooling under .abcd/).

Scope: genuine defects only — wrong output, crashes, silent failures, races, resource leaks, incorrect/swallowed error paths, trust-boundary issues, or code that contradicts its own doc comments, invariants, or test intent. Missing features, style preferences, and in-progress feature work (itd-/spc- intents and specs) are out of scope.

A separate autonomous loop may be doing feature/backlog work on the same repo under branch prefix v050/*, on its own schedule. The two loops share no state; this loop always yields to that one on conflict.

Each round posts one comment here recording its outcome (merged / open / struck / stopped / empty / closed / collision), the ledger state, and what's next.

Bug ledger

id	summary	status	strikes
iss-184	guard tokenizer heredoc misparse — $((1<<ident)) bypassed the guard	merged, PR #199	0/3
iss-185	scanner leaves a second back-to-back secret token undetected/unredacted, defeats history's fail-closed re-scan	merged, PR #201	0/3
iss-186	capture transition remove-failure can strand an issue id across two status dirs	merged, PR #203	1/3
iss-187	rules.Merge panics on a nil-Domains base (latent, no live caller reaches it)	merged, PR #205	0/3
iss-188	scanner adjacency-recovery probe missed the junction for open-ended-quantifier patterns	merged, PR #202	1/3
iss-189	adjacency probe's window-edge \b can be satisfied by the probe window boundary instead of real content, a spurious over-redaction	minor; verified, captured, unfixed	0/3
iss-190	scanner adjacency recovery capped by maxAdjacencyProbeWindow (512B): a truncated recovered match's misaligned end breaks the chain, hiding a third abutting token entirely	minor; verified, captured, unfixed	0/3
iss-191	junctionProbe's regex-compile fallback turns stolenJunctions from a bounded candidate walk into a per-byte one — reachable on the real bundled pattern set, not only via a pathological config override; needs re-scoping	minor; verified, captured, unfixed	0/3

[REPPL]

Round 1 — bug iss-184: collision (real conflict against concurrent work, bug still real, deferred to next round).

Multi-angle sweep (correctness, security/trust-boundary, concurrency, resource/error-handling, contract-fidelity — five fresh subagents, blind to each other) surfaced 16 candidates. Verified a priority subset of 4 adversarially (independent fresh subagent per candidate, each trying to refute with a failing test): all 4 confirmed real. Captured to the abcd ledger: iss-184 (critical), iss-185 (critical), iss-186 (minor), iss-187 (minor).

Picked iss-184 (guard tokenizer heredoc misparse: $((1<<shift)) — an identifier-operand arithmetic shift — was misread as a here-document delimiter, silently swallowing every later line of a multi-line command, including a git push --force, with no error and no signal). Fixed on bugfix/iss-184-guard-heredoc-arithmetic-shift-bypass, PR #199. The first fix pass was too narrow (only handled the case with no coincidental terminator line); both the pre-PR correctness review and the pre-PR security review independently caught the gap, and a second commit closed it at actual root cause (a heredoc delimiter can never be immediately adjacent to a bare paren — $((expr<<ident)) always produces that shape). Regression tests reproduce the exact adversarial payload the security review demonstrated.

At the merge gate's step (a), updating the branch against current main came back DIRTY: a real conflict in .abcd/work/DECISIONS.md against #198 (a same-file append from the concurrent v050/* loop, landed after this branch was cut). Per protocol, re-ran the iss-184 reproducing test against a fresh, unmerged checkout of plain main rather than resolving the conflict: the repro still FAILS there (Check(...).Verdict = "allow", want "block") — the bug is real and unfixed on main, not incidentally closed by anything else that landed. Per protocol this is not the fix's fault: the conflict is left unresolved, PR #199 stays open exactly as-is, iss-184 stays open and unstruck in the ledger below.

strikes iss-184: 0/3; ledger: 4 verified bugs waiting unfixed (iss-184 PR open/blocked, iss-185/iss-186/iss-187 unfixed); next: iss-184 (resume PR #199 at the merge gate once main is clear of the DECISIONS.md conflict — HUNT & VERIFY step 3's branch-resume rule applies: the PR stays open, so the next round skips straight to the merge gate rather than re-hunting).

---

Generated by Claude Code

[REPPL]

Round 2 — bug iss-184: collision (real conflict against concurrent work, bug still real, deferred to next round).

PR #199 was still open from round 1, so this round resumed at the MERGE GATE per protocol (no re-hunt). Step (a): attempted to update bugfix/iss-184-guard-heredoc-arithmetic-shift-bypass against current origin/main (5345a2e — unchanged since round 1's check; no new commits landed on main this round). Merge came back DIRTY: the same real conflict in .abcd/work/DECISIONS.md.

Per protocol, re-ran the iss-184 reproducing tests (TestArithmeticShiftByIdentifierIsNotAHeredoc, TestArithmeticShiftCoincidentalDelimiterStillBlocks) against a fresh, unmerged worktree of plain main — no conflict resolution applied. Both still FAIL there for the claimed reason: Check("shift=8\necho $((1<<shift))\ngit push --force origin main").Verdict = "allow", want "block"; the git push --force line never reaches command position. The bug is real and unfixed on main, not incidentally closed by anything else. Per protocol this is not the fix's fault: conflict left unresolved, PR #199 stays open exactly as-is, iss-184 stays open and unstruck.

strikes iss-184: 0/3; ledger: 4 verified bugs waiting unfixed (iss-184 PR open/blocked, iss-185/iss-186/iss-187 unfixed); next: iss-184 (resume PR #199 at the merge gate once main is clear of the DECISIONS.md conflict).

---

Generated by Claude Code

[REPPL]

Tooling note: this session's comment above (and round 1's) carries a "Generated by Claude Code" footer that the loop protocol bans from public artifacts. No comment-edit/PATCH tool is exposed to this session (GitHub MCP server has no update-comment method), so it can't be stripped after posting. Flagging per protocol rather than silently leaving it; no further public artifacts posted this round beyond this note.

---

Generated by Claude Code

[REPPL]

Round 3 — bug iss-188: open (blocked at the merge gate by a correctness-review BLOCK).

HUNT & VERIFY step 1: PR #199 (iss-184) and PR #201 (iss-185) were both already merged (outside this session's visible round history — no round comment covers either merge, but both are confirmed merged on GitHub). With no PR left open from a prior round, checked the abcd ledger (.abcd/work/issues/open/) against the state issue's table: iss-186, iss-187, iss-188, iss-189 were already verified and captured from earlier rounds. Picked iss-188 (critical, highest severity, oldest of the unfixed criticals).

Bug: internal/adapter/scanner's iss-185 adjacency-recovery probe only closes the "two secrets abutting with no separator" gap for FIXED-LENGTH patterns. A pattern with an open-ended quantifier (ghp_[A-Za-z0-9]{36,} and seven other {n,} families) can greedily swallow a following token's leading bytes, hiding the real junction — "ghp_"+36×a+"ghp_"+36×b" reported one over-long finding and the second token's tail survived Redact raw, with the fail-closed residual re-scan reporting the output clean.

Fix, on bugfix/iss-188-scanner-adjacency-greedy-open-ended, two commits: (1) stolenJunctions, a bounded backward search (window maxAdjacencyBacktrack, 512B) for the real junction inside an over-long match, plus junctionProbe, a combined-alternation candidate generator whose hits are always re-verified before being trusted. (2) A fresh pre-PR correctness review AND a fresh pre-PR security review both independently found the same real gap in commit 1 — the backward search's resume logic could still skip the true junction when an unanchored candidate hit spanned it without starting at it; fixed by always resuming one byte past a rejected candidate's start rather than its end. Both reviews' repros are now regression tests, watched failing before and passing after. Captured two follow-ups rather than folding them in: iss-190 (the pre-existing maxAdjacencyProbeWindow truncation, from iss-185, can also break the recovery chain for a third abutting token) and iss-191 (a latent cost-cliff in junctionProbe's compile-failure fallback path).

Opened PR #202. CI green (12 checks). Merge gate step (a): branch was exactly current with main, nothing to update. Step (c), two fresh merge-gate reviews of the full combined diff: security → MERGE (closes the canonical leak across all bundled families and 5,000+ fuzz cases with zero regressions vs main); correctness → BLOCK — the same backward-search mechanism also classifies the network patterns (net:ipv6, SSH-fingerprint-shaped hex) as open-ended, which (a) manufactures duplicate hard_fail findings for a single compressed IPv6 address (reproduced on this repo's own tracked test fixtures: internal/core/memory/memory_test.go, internal/urlguard/urlguard_test.go), and (b) costs 40–330× on ordinary, non-adversarial content shaped like SSH fingerprints or IPv6 logs — a regression the PR's own cost-guard test doesn't exercise. The security reviewer's own independent timing measurements corroborate the same cost regression (up to 330× on hostname-terminated input) as a non-blocking observation.

Per protocol, a BLOCK from either merge-gate reviewer means the PR stays open for a human rather than an autonomous fix-and-retry loop at this stage — recorded as one strike. PR #202 left open exactly as-is, nothing further pushed this round. iss-188 stays open and unstruck in the ledger below.

strikes iss-188: 1/3; ledger: 5 verified bugs waiting unfixed (iss-186, iss-187, iss-189, iss-190, iss-191) plus iss-188 blocked in open PR #202; next: iss-188 (resume PR #202 at the merge gate next round — the fix for the correctness review's findings, e.g. suppressing a same-pattern recovered match contained within its own container's span, is bounded and well-scoped, but landing it is for the next round or a human, not a same-round retry per the merge-gate strike rule).

---

Generated by Claude Code

[REPPL]

Tooling note: the round 3 comment above carries the same "Generated by Claude Code" auto-appended footer flagged in round 2 — still no comment-edit/PATCH tool exposed to this session, so it can't be stripped after posting. The PR #202 description was caught and corrected before this note (create_pull_request auto-appended a footer with a session URL; re-read immediately after creation and edited clean via update_pull_request). The issue body update earlier this round did not pick up a footer. No further public artifacts posted this round beyond this note.

---

Generated by Claude Code

[REPPL]

Round 4 — bug iss-186: open (blocked at the merge gate by two correctness/record-accuracy BLOCKs).

HUNT & VERIFY step 1: no PR was open from a prior round (PR #199, #201, #202 all already merged on GitHub outside this session's visible round history) and no dangling bugfix/* branch existed on origin. The abcd ledger (.abcd/work/issues/open/) cross-referenced against the state issue's table showed iss-186, iss-187, iss-189, iss-190, iss-191 already verified, captured, and unstruck from earlier rounds — skipped straight to FIX with iss-186 (oldest of the tied-minor-severity set), per protocol.

Bug: capture.commitTransition (internal/core/capture/workflow.go) writes the destination file before removing the source. A non-ENOENT os.Remove(src) failure returned that error after dst had already landed, with no rollback — stranding the issue id in two status directories at once, which findIssue then rejects as an unrecoverable ErrDuplicateIssueID (no repair verb; a human had to delete one copy by hand).

Fix, on bugfix/iss-186-capture-transition-remove-rollback, PR #203: commitTransition rolls the destination back (best-effort os.Remove(dst)) whenever the source remove fails non-ENOENT. A test-only seam (removeSourceHook, nil in production, mirroring the existing beforeOrphanRemoveHook pattern) let a regression test force the failure deterministically — no portable filesystem trick exists across this repo's macOS+Linux CI matrix. A fresh pre-PR correctness review caught one real gap in the first draft (the test asserted only err != nil rather than errors.Is(err, injected), which could pass vacuously if an unrelated earlier error fired) — fixed before the PR opened. CI green (12 checks, both platforms).

Merge gate step (a): branch was exactly current with main, nothing to update. Step (c), two fresh independent merge-gate reviews of the full diff — correctness and record/docs-accuracy — both returned BLOCK, converging on the same defect neither the fix author nor the pre-PR reviewer had caught: the rollback is unconditional on the error, not on whether the source file actually still exists. On a mount where the unlink syscall reports a non-ENOENT error after the file was already removed (a FUSE/network-mount reply failure, or EIO surfacing after the dirent was dropped), the rollback then deletes dst too — both correctness reviewers independently demonstrated this destroys the issue record entirely (ErrUnknownIssueID on retry, resolution note and all gone with no trace), a strictly worse outcome than the recoverable two-copy strand the fix exists to close. The record-accuracy reviewer separately flagged that the shipped CHANGELOG/DECISIONS prose overclaims an unconditional "restores the pre-call state" guarantee, and cites a read-only-remount example that cannot actually reach this code path (a read-only mount fails the destination write first, before any remove is attempted).

Per protocol (and consistent with round 3's precedent on PR #202), a BLOCK from a merge-gate reviewer means the PR stays open for a human rather than an autonomous fix-and-retry at this stage. PR #203 left open exactly as-is, nothing further pushed. iss-186 stays open and unstruck in the abcd ledger (the ledger move to resolved/ exists only on the PR branch, not on main); recorded as one strike in the state-issue table above. While updating the ledger table this round, also corrected a stale entry: iss-188 (last round's PR #202) has since been merged directly by the repo owner — updated from "blocked" to "merged, PR #202".

strikes iss-186: 1/3; ledger: 5 verified bugs waiting unfixed (iss-186 PR open/blocked, iss-187/iss-189/iss-190/iss-191 unfixed); next: iss-186 (resume PR #203 at the merge gate next round if a human has pushed a fix bounding the rollback to "only when the source still exists", e.g. an os.Stat(src) check before `os.Remove(dst)"; otherwise HUNT & VERIFY step 1 picks the next-oldest unstruck ledger bug, iss-187).

---

Generated by Claude Code

[REPPL]

Tooling note: the round 4 comment above carries the same "Generated by Claude Code" auto-appended footer flagged in rounds 2 and 3 — still no comment-edit/PATCH tool exposed to this session, so it can't be stripped after posting. The issue body update earlier this round (ledger table) did not pick up a footer, and PR #203's description was caught and corrected before this note (create_pull_request auto-appended a footer with a session URL; re-read immediately after creation and edited clean via update_pull_request). No further public artifacts posted this round beyond this note.

---

Generated by Claude Code

[REPPL]

PR #203 update (interactive, not a scheduled round): the branch went dirty against main after main picked up the v0.4.2 release cut (PR #204). Checked locally rather than resolving blind: git merge origin/main on the branch completes with zero conflict markers — .gitattributes' merge=union driver for CHANGELOG.md/.abcd/work/DECISIONS.md (added for exactly this class of concurrent-append collision, iss-118) resolves it automatically. GitHub's own mergeability check doesn't honour custom merge drivers, which is why it still reported dirty; this is not the "real conflict" the merge-gate protocol's collision path is written for.

The union merge did surface one real defect, though: it's a textual union with no notion of section headers, and it landed the iss-186 CHANGELOG entry inside the now-tagged [0.4.2] section (the release cut renamed [Unreleased] to [0.4.2] concurrently with this branch's own append), mis-attributing an unreleased fix to a release that shipped without it. Moved the entry back under [Unreleased] in a follow-up commit before pushing.

Pushed the merge (7b5e150) plus the CHANGELOG fix (f71f5d7) as new commits — no --amend, no force-push. make preflight green locally on the merged tree; all 12 CI checks green on the pushed commits. mergeable_state is now blocked (no conflict; ordinary branch-protection gating), not dirty.

This does not touch the substantive finding from round 4 — the two merge-gate BLOCKs on the rollback's unconditional-delete risk (deletes dst even when the source unlink actually succeeded but reported a non-ENOENT error) are still unresolved and still need a human decision before this can merge. iss-186 strikes unchanged at 1/3.

---

Generated by Claude Code

[REPPL]

Round 5 — bug iss-187: merged, PR #205.

HUNT & VERIFY step 1: no PR was open from a prior round (PR #203, iss-186, was merged by the repo owner directly between rounds — outside this session's visible round history) and no dangling bugfix/* branch existed on origin. The abcd ledger (.abcd/work/issues/open/) cross-referenced against the state issue's table showed iss-187, iss-189, iss-190, iss-191 already verified, captured, and unstruck from round 1 — skipped straight to FIX with iss-187 (oldest of the tied-minor-severity set, 0/3 strikes), per protocol.

Bug: rules.Merge (internal/core/rules/rules.go) wrote override domain keys straight into out.Domains without ever allocating that map. cloneRuleSet deliberately preserves a nil Domains map when the source has none, so a base such as RuleSet{SchemaVersion: 1} — a Validate-accepted, valid RuleSet — panicked with assignment to entry in nil map the moment the overlay carried a domain key, contradicting Merge's own doc comment ("New domain keys are added"). Not reachable in production today (the sole call site, Load, always merges onto Defaults(), which always has a populated map) — a latent defect in an exported API contract that goes live for the first caller merging onto a non-Defaults() base.

Fix, on bugfix/iss-187-rules-merge-nil-domains-panic, PR #205, one commit: allocate out.Domains before the override loop when it's nil and the overlay has at least one key, matching the idiom the sibling loader guard.Merge already uses for out.Entries. cloneRuleSet left untouched, so its nil-preserving semantics hold for every other caller. Added TestMergeNilBaseDomainsAddsNewKeys, watched failing pre-fix for the claimed reason (panic: assignment to entry in nil map) and passing after. Resolved the ledger entry via abcd capture resolve iss-187.

A fresh pre-PR adversarial correctness review (independent subagent) traced all four base/overlay nil-combinations, reverted the fix locally to confirm the test's failure reason, and checked the sole call site and cloneRuleSet for regressions — verdict MERGE, no findings. Not a trust-boundary change, so no security review was required at either gate. Opened PR #205; caught and stripped an auto-appended session-URL footer from the PR body immediately after creation, per protocol.

Merge gate: step (a) branch was already current with main, nothing to update, no conflict. Step (b) all 12 CI checks green. Step (c), two independent fresh merge-gate reviews of the full diff — correctness and record/docs-accuracy — both returned MERGE, each independently re-running the build/test/race suite in a clean worktree and re-verifying every file:line reference and factual claim in the CHANGELOG/DECISIONS/ledger prose against the actual diff. Both flagged only non-blocking prose nits (a "call site" vs "inside Merge" wording ambiguity in DECISIONS.md). Squash-merged (c133c05); branch auto-deleted on merge.

strikes iss-187: 0/3; ledger: 3 verified bugs waiting unfixed (iss-189, iss-190, iss-191, all minor); next: hunt (no verified-and-unstruck ledger bug remains once iss-187 is closed — the next round runs HUNT & VERIFY step 1, and if the ledger is still empty of unstruck verified bugs, a fresh multi-angle sweep per step 2).

---

Generated by Claude Code

[REPPL]

Correction to the round 5 comment above: the "next" field is wrong. iss-189, iss-190, and iss-191 are all still verified, captured, and unstruck in the ledger — per HUNT & VERIFY step 1, the next round picks the oldest of those (iss-189) straight to FIX, it does not re-hunt. "next: hunt" should have read "next: iss-189".

Tooling note: the round 5 comment also carries the same auto-appended "Generated by Claude Code" footer flagged in rounds 2-4 — still no comment-edit/PATCH tool exposed to this session. PR #205's description was caught and corrected before merge (create_pull_request auto-appended a footer with a session URL; re-read immediately after creation and edited clean via update_pull_request). The issue body update this round did not pick up a footer.

---

Generated by Claude Code