capture resolve and capture wontfix have no way to set the typed duplicates link, so a record closed as a duplicate carries the relation only in wontfix_reason prose. A machine reader of the ledger sees a wontfix, not a duplicate (found by review-triageMinorC: four duplicate closures in lane triageMinorC, iss-2608290811463906, iss-2609170640135192, iss-277, iss-91). Add a --duplicates <id> flag (issue or intent id) to wontfix, or a duplicate sub-verb, writing the field the ledger already defines.

Frontmatter

.abcd/work/issues/resolved/iss-2609291118049254-capture-resolve-and-capture-wontfix-have.md
open on GitHub ↗ · commit history ↗

mentions4

• iss-91prepare-this-repo Phase 3 describes .abcd/.work.local/ as NEXT.md plus scratch/ plus logs/ only, giving no guidance for pre-existing non-standard members. Manuscripts .work.local/ carries WORKLOG.md, DECISIONS.local.md, and SLICE_START (load-bearing for its own autonomous-run cadence); adoption must preserve them but the skill is silent on how. Concrete instance of the broader onboarding-nonstandard-file-placement-interview seed. Detector: the adopt phase enumerates every pre-existing .work.local member and proposes a disposition. Acceptance: the three Manuscripts members above.
• iss-277Ruleset drift check is unbuilt: the applied branch rulesets are mirrored under .abcd/work/rulesets/ but nothing diffs the live rulesets against the committed JSON, so drift is invisible until a human re-reads the console; itd-92 owns the verb
• iss-2608290811463906Each run should record the model SETTINGS alongside the model id, because the id alone does not determine behaviour and so does not make a run interpretable or reproducible. Whatever the current model exposes belongs in the record: reasoning or thinking depth, temperature and other sampling parameters, a seed where one exists, the context-window variant, and any speed or quality mode the harness offers. Two runs stamped with the same model id can differ substantially on all of these, so a record that names only the id invites a false comparison between them: an audit verdict, a benchmark, or a regression blamed on a code change may in fact be a settings difference. This matters most where a verdict is treated as evidence. The intent-audit verdict already carries a verifier block of id and version, which is the natural place to widen; the per-run transcript store is the natural home for the settings of an ordinary session; and the Assisted-by trailer is NOT the place, since its accepted shape is a vendor and model pair and widening it would break the gate that reads it. The hard constraint is the same one iss-2608290810032799 records: a model cannot reliably introspect the settings it is running under, so the harness has to supply them. That makes this a capability of the dispatching layer rather than something an agent can be instructed to self-report, and any design that asks the agent to state its own settings inherits exactly the truthfulness problem that the attribution gate already has.
• iss-2609170640135192A local branch whose pull request has merged is never pruned, so a checkout accumulates them until somebody sweeps by hand: this checkout held 57 on 2026-09-17, one per landed PR since early September. The sweep cannot be 'git branch --merged', because the repository allows squash and rebase merges and those leave no ancestry, so 20 of the 57 read as unmerged by ancestry and were provably merged only by patch-id or by the forge's PR state; and a branch checked out in a worktree survives the sweep until the worktree is removed. abcd knows the merge state (the resolution gates already read origin/main and the PR), so the install step or a fetch-time pass could list the merged branches and remove them on consent, never one with unmerged patches, never one a worktree holds, and never a name matching a backup pattern.