[Hafeok]

Completes: #248

What this changes, and why

Step 3 of the "issues are the work log" session, for #248 as corrected on 2026-11-10. It is stacked on #260, which is stacked on #259, so it lands last. Its own commits are the last four.

• dotnet run eng/release.cs -- --sbom <version>:

  • runs eng/sbom.cs created at the current UTC day;
  • replaces the descriptor's sbom: block with its sbom.txt and sets date: to that day, in one edit;
  • then regenerates CHANGELOG.md.

  Under ADR 0224 point 2 (D3, untouched) the SBOMs are created at date, so the two now move together. Other behaviour:

  • --syft, --binary and --image pass through to eng/sbom.cs, and --out names where it writes;
  • --from <dir> takes SBOMs already written, and refuses them unless every one was created on that day;
  • a tagged version is refused, and so is a descriptor with no sbom: block;
  • --draft points at the command.

• eng/land.cs -- N, at both steps, refuses a descriptor the head adds or changes whose date: is more than three days before the landing day (UTC), or that has no date. It prints the --sbom command.

• docs/releases.md rule 3, amended 2026-11-10: the old text is struck through and kept, and date is now the day the digests were last written. Rule 11's "written, not typed" names --sbom.

• ADR 0102 gets a dated amendment saying the same, because rule 3 restates 0102's line on date. It is add-only and changes no ruling (ADR 0068 point 2).

• AGENTS.md's close-out names the command and the refusal.

• Preview.18 keeps 2026-10-27.

What was measured

• release.cs --sbom-fixtures tests/fixtures/release-sbom: 4 cases, 0 judged wrong.
• land.cs --fixtures tests/fixtures/land: 12 cases, 0 judged wrong. Three are this PR's date cases: four days refused, three passing, no date refused.
• The ci.yml step, run locally. The newest format-2 descriptor, renamed v0.0.0-sbom-rewrite and backdated to 2026-01-01 in a scratch directory, was rewritten with --sbom:

  release: …/v0.0.0-sbom-rewrite.yaml: the sbom: block rewritten, and date: 2026-11-10.
  date: 2026-11-10
       29 "created": "2026-11-10T00:00:00Z"
  ok  …/v0.0.0-sbom-rewrite.yaml's sbom lines match the 29 generated SBOM(s)
  

• The failure path: the same descriptor checked with --created 2026-11-09:

  FAIL: …/v0.0.0-sbom-rewrite.yaml says 'nupkg: Varve.Aspire sha256:8ab6ee41…', generated 'nupkg: Varve.Aspire sha256:61ebbb43…'
  exit 1
  

• eng/ci.cs with only licence-headers, decision-sets, release-sbom-fixtures, land-fixtures, changelog, release, status, release-fixtures, land, issue-refs and dco: all pass.

What was found

• Nothing rewrote the sbom: block before this. The digests were pasted from sbom.txt by hand, so "release.cs sets date: whenever it rewrites the block" needed the rewrite itself.
• The new CI step adds two SBOM generations on the Linux build job. They run without Syft. Locally each took about as long as one of "SBOMs, twice".

What is left

• Issues this touches: Release descriptor date: follow the day the digests were last written, and check it at landing #248 (completed, Closes #248 trailer) and land.cs: list the issues a landing closes, and refuse a PR whose declared issue has no closing trailer #209 (its fixture runner gains the date step).

---

Checklist

• Issue referenced: Refs #248 on each commit, and Closes #248 on the last.
• ADR cited: ADR 0102 amended, add-only; ADR 0224 untouched.
• Specification updated, or n/a: docs/releases.md rules 3 and 11.
• API baseline updated, or n/a: n/a.
• Conformance baseline updated, or n/a: n/a.
• Tests: fixtures on every eng/ci.cs run, and an end-to-end CI step.
• A new gate's failure path was proven by running it: quoted above.
• Signed off: by the commit-msg hook.
• A traceability record exists: docs/traceability/2026-11-10-issue-248-the-descriptor-date-follows-the-digests.md.
• dotnet run eng/ci.cs passes locally: the process gates and fixtures were run; the full test pipeline is left to CI.

---

Generated by Claude Code

[Hafeok]

web ui bundle, attested failed at 11c35945 with MSB1009: Project file does not exist for src/Varve.WebUi.

The run used main's publish.yml, whose web UI job publishes src/Varve.WebUi. The job checks out the pull request's head, and the stack was cut from 81fba3d, before that project landed. Only this PR runs publish.yml, because only it touches eng/release.cs. #259 and #260 don't.

Fix: main was merged into #259's branch, then down the stack: #259 is now at 3b78886d, #260 at c7c27e27, and this PR at a3578a27. Both merges were clean. The ledger and process gates, land-fixtures (12 cases), release-sbom-fixtures (4) and release-fixtures pass on the merged trees.

---

Generated by Claude Code

[Hafeok]

Head for approval: a3578a27262b5a61a0da4ea3d8be9e200fca3b87. All 72 other checks are green or skipped, including the publish dry run and its verify what was published. The one not green is agent review, which waits on the approval. It lands after #259 and #260, in that order.

---

Generated by Claude Code

[Hafeok]

approve 3da8929 (delegate)

[Hafeok]

Pushed to this branch by the landing queue: b5277a1e and 3da8929c. The first merges main (2cad18d5); one file met, docs/adr/README.md, where main's section for ADR 0223 and this stack's for ADR 0241 were added at the same place, and both are kept. The second accepts ADR 0241's ruling at the maintainer's word of 2026-11-11 (Delegated-by, ADR 0239). #259, #260 and this pull request land as one fast-forward of this head once its checks are green. Note for the memory session: #264 also numbers its ADR 0241; whichever lands second renumbers.