The two-way pair that marks an issue as promoted (the issue's `related_intents` naming an intent that names it back in `related_issues`) cannot tell an issue the intent delivers from an issue the intent only cites as evidence, so an evidence-only issue reads as promoted and `capture promote` refuses it.

Frontmatter

.abcd/work/issues/open/iss-2610240932493158-related-intents-on-an-issue-carries-two.md
open on GitHub ↗ · commit history ↗

mentions7

• dcn-26092300000000162026-09-23 — itd-4 AC3 built as ruled (B3): the promote join's back-links are `related_issues` on the intent and `related_intents` on the ledger record, and `abcd intent audit --issue-drift` checks them. Seven implementation decisions the ruling left open, taken by the implementing lane. (1) No reader tolerates the retired `promoted_to` / `promoted_from`: the ledger reader refuses and skips a record carrying `promoted_to`, the intent reader ignores `promoted_from`, and a promote write meeting either refuses. The refusal, the record gate's finding and the drift finding each name the successor and the remedy, `abcd capture migrate --apply`, a verb that reports by default, writes only with `--apply`, and is idempotent. It is a verb and not a one-off script because managed repositories hold the same retired names and need the same repair. (2) "Promoted" is the PAIR, an intent in the record's `related_intents` that names the record back in its `related_issues`, because an issue's `related_intents` already carried loose relations before the rename and still does; the double-promote refusal and the record page's next move read the pair. So the migration completes a join an older abcd wrote from one end only (iss-327 and itd-93, iss-2609091642508005 and itd-2609111003026787), or those records would stop reading as promoted. (3) Link mode on the issue route writes both halves; before the rename it stamped the issue alone, which left a hand-filed draft with no edge back. (4) `related_issues` holds `rdi-N` as well as `iss-N`: a reading item lives in the issue ledger's tree and graduates the same way, and one key per side keeps the join one shape. The first entry is the record the intent was promoted from; a later link appends, so `back_edge_kept` still reports the first. (5) The drift check reports an intent naming a record that does not name it back, but not an ISSUE naming an intent that does not name it back, since that is a loose relation; a reading item carries no loose relation, so from its end a one-way stamp is drift. A shipped intent naming an issue in `wontfix/` is drift, like one in `open/`, because the itd-4 scope asks whether the issue "actually moved to resolved/". The check is not wired into preflight or CI; `--strict` is there for whoever wires it. (6) The historical passages in shipped intents, closed specs and adr-0057 carry a `(historical)` marker beside the retired names, the precedent `development/activity` set, so the new `retired-promote-back-links` ban can gate every current record. (7) The impact is `breaking`: itd-4 declares none, and the rename removes `promoted_to` from `capture list --json`, `promoted_from` from the intent JSON and both link keys from the record page, and makes an unmigrated ledger unreadable until the migration runs.
• dcn-26101614282444612026-10-16 — An after-merge audit's owed-check issue reaches a lane through a person's own build, and a drain still hands it back as promoted (facilitator-on-delegation, drain-many-accounts step 4; a new record refining dcn-2610161401449155, since records are append-only): ruling DQ1a, that an undecided fidelity audit reopens the work and sends the feature back to a lane, is subsumed by ruling DQ1c, which says what reopening means for a shipped intent (it stays shipped and flagged, and one issue carries the owed check, dcn-2609300000000027), so DQ1a is met when that issue reaches a lane, and a person's abcd build <iss-N> remains the lane route for it: the eligibility check lets a promoted issue through with a note naming its intent, as dcn-2610161040365515 lets a person's own build through a hand-back, while every other hand-back is still refused. This overrides the resolution of iss-2608290820473197 where it says the captured issue is one "which a drain can take": a drain hands it back, and a person's build or abcd intent audit takes it (grounds: rulings DQ1a and DQ1c, dcn-2610161040365515, dcn-2610161401449155; iss-2610161015370582).
• dcn-26101615190478992026-10-16 — Refines dcn-2610161428244461: a person's own abcd build takes a promoted issue only when no other hand-back would hold it; the rule is asked again with promoted set aside, and an issue that security, category, severity, Waits on, a deferral or a missing remedy still holds is refused with that rule's reason, while the drain still hands every promoted issue back.
• iss-2610140652230444Every review should run as a pair of models from two classes, with the top class only an occasional advisor. The classes are vendor-neutral: top, middle, the class below it, and smallest (the scale itd-2610100704270254 uses). For one vendor today, Anthropic, they are Fable, Opus, Sonnet and Haiku. The rule is stated in classes so it survives model churn and holds for any vendor whose models map onto them.
• itd-2610161733316518One task done across a model matrix, re-runnably
• itd-2610240922461281The review set is a setting, in model classes
• itd-2610240933025076abcd plans unattended and asks only what a person owns