Development record
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 planstamps each with a persistent identity. Replace this line with those bullets, or with the exact tokenNone 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.
SOTA
Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the install-update-release SOTA note. The 2026-08-27 pilot note's F-K, F-P and F-Q are the local evidence this builds on.
- The forge's REST surface does everything the title names:
PATCH /repos/{owner}/{repo}/security-advisories/{ghsa_id}takesstate(published,closed,draft),vulnerabilities[]withpackage.ecosystem(goandotheramong the values),vulnerable_version_rangeandpatched_versions, andcredits[]of{login, type}, where "to add a credit, send the wholecreditsarray"; a CVE is requested atPOST .../{ghsa_id}/cve(public repositories only); tokens needrepository_advisories:write. - Credits are opt-in and the fix version must precede publication: the public sees credits "the credited users have accepted"; without a fix version Dependabot alerts users "without offering any safe version to update to"; GitHub reviews a published advisory for its database within "up to 72 hours".
- Publication is one-way: a published advisory is deleted only "by contacting Support". The publish step therefore sits after the human release gate (pilot F-Q), never before it, and shows its exact request bodies first.
- "Not a vulnerability" is a close with a comment first: the maintainer
flow offers "Close security advisory" and advises that "Where possible, you
should add a comment explaining why you don't consider the report a security
risk before you close the advisory"; no close-reason enumeration
exists, the API's
state: closedis the whole of it. - OSV is the interchange shape: the database exports advisories "in the
Open Source Vulnerability (OSV) format"; OSV's
fixedevent "is strongly preferred overlast_affected", SEMVER ranges carry no leadingv, and OpenSSF recommends publishing a JSON entry in the OSV schema as part of its CVE step and calls omitting credit "inappropriate" unless declined. - The ledger has no link to the advisory (pilot F-E): the v0.6.7 cut published its advisories by hand after the release. An automated publish needs the fixing record to carry the GHSA id before the cut.
Path 1 — adopt the forge API as it is, called from launch ship after the
Release is published: for each draft advisory whose linked record shipped,
patched_versions is the derived version and state becomes published,
credits as already recorded on the advisory; for each linked to a won't-fix
record, a comment and state: closed. "The release workflow" in the title is
read here as the launch ship verb, not a CI workflow step, which the note
weighs and rejects (the secret would live in CI and a failed publish be
invisible at the terminal). One record change: the issue record gains an
advisory: field holding the GHSA id, set when the report is accepted as a
draft; that is an issue-schema change, a prerequisite for the record-lint and
schema owners. Over the pinned HTTP client the update package already
has, or gh api; no new Go dependency. The independent fit-challenge runs at
plan time.
Open Questions
- (SOTA 2026-10-23) Which
package.ecosystemdoes a Go binary whose importable packages are allinternal/declare:gowith the module path, so a reviewed advisory reaches anyone who vendors the module, orother? - (SOTA 2026-10-23) Where does the GHSA id live: an
advisory:field on the issue record, the record id in the advisory's description, or both? - (SOTA 2026-10-23) Is the CVE requested at triage (reserved privately, "usually within 72 hours") or at publication, and who decides that a record warrants one?
Audit Notes
Empty. Populated by intent-auditor when intent moves to shipped/.
Frontmatter
| id | itd-2609151658486398 |
|---|---|
| type | intent |
| lifecycle | drafts |
| severity | minor |
.abcd/development/intents/drafts/itd-2609151658486398-a-release-cut-publishes-the-security.md
open on GitHub ↗ · commit history ↗
mentions2
- itd-1Every Intent Has Acceptance Criteria; Every Audit Verifies Them
- itd-149abcd handles inbound security advisories and issues, and cuts the release, for every managed repo. The 2026-08-27 security-advisory pilot proved the loop by hand across two independent operators: advisory and issue intake, recall-dedup triage against the ledger, record-first fixes in isolated worktrees, one integration branch, an independent adversarial gate over the assembled diff, auto-merge armed only after APPROVE, and a derived release cut through the semantic-receipt gates. This intent automates that loop as abcd capability for any managed repo, with findings F-A through F-W of the pilot note as the acceptance-criteria source and F-U (re-run every required pass against the final content commit; never transfer a verdict) and F-Q (the two release gates are human-by-design) load-bearing.