chore: file the advisory-publication intent and its schema-field issue

.abcd/development/brief/06-delivery/03-out-of-scope.md

@@ -108,6 +108,7 @@ gate. That is what keeps "not hand-counted" true after the day it was written.
 - `itd-175` — The product thinker writes down how this could be wrong, and what would show it (Phase 8; the defeater list an acceptance rests on)
 - `itd-176` — Whatever ships says how hard anyone looked at it (Phase 7)
 - `itd-201` — every question abcd's agents put to a human is asked one at a time, in plain language, in the addressee's register, with options that widen
+- `itd-2609151658486398` — a release cut publishes the security advisories its fixes close, and closes those resolved as won't-fix (the publication step the 2026-08-27 advisory-handling pilot named as its target)
 - `itd-2609091014076309` — Session and agent worktrees live in a machine-scoped store (`~/.abcd/worktrees/<root-sha>/<name>/`) that abcd lists and reclaims, never beside the user's own projects (the rule is adr-2609091248200336; `builds_on` itd-118, whose worktree clause it supplies the store and the reclaim verb for)
 - `itd-2609091416295622` — A session sees the records its sibling worktrees hold before it mints or fixes one: a read-only ledger diff over `git worktree list --porcelain` (open there and absent here; open here and terminal there), a line on the `/abcd` board and on the record dispatch, no claim and no write (split from itd-2609091034175565 on the maintainer's ruling of 2026-09-09; the shippable piece)
 - `itd-2609091416304128` — `capture resolve` and `capture wontfix` refuse a record already terminal at the local `origin/main` ref as last fetched, stating the ref's age and performing no fetch; the same judgement rendered read-only on `abcd <record-id>` (split from itd-2609091034175565 on the same ruling; the third clause of iss-2609020716570699's remedy, RS001's answer moved earlier)

.abcd/development/intents/drafts/itd-2609151658486398-a-release-cut-publishes-the-security-advisories-its-fixes-cl.md

@@ -0,0 +1,43 @@
+---
+id: itd-2609151658486398
+slug: a-release-cut-publishes-the-security-advisories-its-fixes-cl
+spec_id: null
+kind: null
+suggested_kind: null
+reclassification_history: []
+builds_on: []
+severity: minor
+impact: additive
+origin: researcher-authored
+production_mode: dictated-and-formatted
+---
+
+# A release cut publishes the security advisories its fixes close: when the release workflow cuts a version, every draft advisory whose fixing record shipped in that cut is published with the fixed version stamped and its opt-in credits, and an advisory whose record was closed as won't-fix is closed as not a vulnerability, so no fixed advisory sits unpublished after its release and no hand step decides which ones publish
+
+## Press Release
+
+> _Seeded from a quoted-text intent capture. Expand into the full press-release narrative before planning._
+
+## Why This Matters
+
+A release cut publishes the security advisories its fixes close: when the release workflow cuts a version, every draft advisory whose fixing record shipped in that cut is published with the fixed version stamped and its opt-in credits, and an advisory whose record was closed as won't-fix is closed as not a vulnerability, so no fixed advisory sits unpublished after its release and no hand step decides which ones publish
+
+## Mechanism
+
+> _Prompted (the claim-recording gradient): why the authors expect this to work, as a falsifiable "we expect X because Y" — not the outcome restated. Replace this line with the claim, or with the exact token `None stated.` alone on its line to record the claim as considered and declined._
+
+## Scope Conditions
+
+> _Required (the claim-recording gradient): the population, platform, scale, or assumptions this claim holds under, one per top-level bullet — `abcd intent plan` stamps each with a persistent identity. Replace this line with those bullets, or with the exact token `None stated.` alone on its line._
+
+## Acceptance Criteria
+
+> _Required (the itd-1 discipline): add at least one Given-When-Then bullet describing the verifiable bar for "shipped" before this draft can be planned._
+
+## Open Questions
+
+_None recorded yet._
+
+## Audit Notes
+
+_Empty. Populated by intent-auditor when intent moves to shipped/._

.abcd/development/research/notes/2026-08-15-decomposition-calibration.md

@@ -1417,3 +1417,56 @@ Per hand-run, append:
   in the file the rules loader puts before every session. The table caught it
   because verifying "already shipped" meant reading both the code and the rule
   that describes it, and they disagreed.
+
+### 2026-09-15 — interview context shown before every question (hand-run at filing)
+
+- **Proposal:** whenever a user is interviewed, provide the appropriate
+  context: before asking whether acceptance criteria stand, show them; for
+  every interaction during the interview.
+- **Table:**
+
+  | Part | Type | Home |
+  | --- | --- | --- |
+  | The material under decision is shown in full before each question, at every interview step | capability | intent `itd-2609151541116052` |
+  | "Never ask about a text the reader cannot see" as a standing rule | stance | GRILL domain in `.abcd/rules.json`; the bundled default when itd-201 ships |
+  | The `/abcd:intent` interview steps say "summarise back" and "walk every bullet"; make "show it first" explicit | plumbing | `commands/intent.md` |
+
+- **Links:** `refines itd-201` (the draft that governs how a question is asked:
+  one at a time, one sentence of context, an example per option). No reversal.
+- **Verdict:** proposed SPLIT-or-AMEND with four options offered (new intent
+  refining itd-201; amend itd-201's draft; GRILL rule only; decide later); the
+  maintainer chose a NEW INTENT. Routing survived as one of the offered options,
+  not as the table's first line, which had left the choice open.
+- **Notes:** the proposal came from the maintainer's own experience of being
+  asked "does this criterion stand?" with the criterion out of view. The stance
+  and plumbing parts are not filed with the intent; they follow when it is
+  planned, because a rule written before the intent it enforces is the shape
+  itd-201's own filing avoided.
+
+### 2026-09-15 — advisories publish with the release that fixes them (hand-run at filing)
+
+- **Proposal:** a process so that security advisories are captured, resolved,
+  and automatically published once a new release is cut with their fixes;
+  perhaps captured as an intent.
+- **Table:**
+
+  | Part | Type | Home |
+  | --- | --- | --- |
+  | The release cut publishes each draft advisory whose fixing record shipped in the cut, and closes one whose record was closed as won't-fix | capability | intent `itd-2609151658486398` |
+  | A security record names its advisory in a typed field, not only in its slug and prose | plumbing (schema) | issue `iss-2609151703088754` (split out at the routing) |
+  | Publishing needs the forge token; `launch ship` never publishes, so the act belongs to the release workflow | trust rule, already recorded | unchanged; a scope condition on the intent |
+  | An advisory's specifics stay out of the committed record until it publishes | stance, already in the pilot note of 2026-08-27 | unchanged |
+
+- **Links:** `builds_on itd-70` (release retention at ship time); the pilot
+  note of 2026-08-27 names this publication step as its target and is cited by
+  the intent. No reversal.
+- **Verdict:** four options offered (one intent; SPLIT into intent plus schema
+  issue; HOLD for one more hand-run; decide later); the maintainer chose SPLIT,
+  so the typed field can land first on its own. The table had folded the field
+  into the intent's spec; the routing moved it out.
+- **Notes:** the trigger was a concrete gap found the same day: GHSA-gx3m is
+  fixed in v0.8.0 and was still an unpublished draft five days after the tag,
+  published by hand at the maintainer's word during this run. The three
+  advisories triaged today ended in three different states (fixed and released;
+  fix in progress; not a vulnerability, won't-fix), which is the case split the
+  intent's criteria have to cover.

.abcd/work/issues/open/iss-2609151703088754-a-security-record-names-its-advisory-only-in-its-slug-and-pr.md

@@ -0,0 +1,14 @@
+---
+schema_version: 1
+id: "iss-2609151703088754"
+slug: "a-security-record-names-its-advisory-only-in-its-slug-and-pr"
+severity: "minor"
+category: "future-work-seed"
+source: "user-observation"
+found_during: "security-advisory triage 2026-09-15"
+origin: researcher-authored
+production_mode: hand-written
+found_at: "internal/core/issueschema"
+---
+
+A security record names its advisory only in its slug and prose (ghsa-gx3m-..., 'GHSA-gx3m-3224-qqcv (CWE-426...)'), so nothing can match a resolved record to the draft advisory it fixes without reading the text. The publication step the advisory-handling pilot note names as its target (the GHSAs publish after the cut) needs a typed field on the issue record, e.g. advisory: GHSA-xxxx-xxxx-xxxx, admitted by issueschema, written by capture through a flag, carried through resolve and wontfix unchanged, and read by the release workflow to publish or close the advisory. Today GHSA-gx3m-3224-qqcv is fixed in v0.8.0 (record iss-2609012039107700 resolved 2026-09-08) and still an unpublished draft, which is the gap a mechanical match would have closed. Split out of the publication intent at the 2026-09-15 routing so the field can land first on its own.