chore(release): date v0.1.5

[thequantumfalcon]

What this changes

This is an intentional release-metadata transition, not a bug repair. Nothing
was broken before this change; the repository simply had no release date
recorded for 0.1.5.

2026-09-09 is the direct owner-selected intended release date. The version was
already 0.1.5, so this is not a version bump.

• CHANGELOG.md changes its 0.1.5 heading from not yet released to
  2026-09-09.
• CITATION.cff gains date-released: 2026-09-09.
• The current-metadata test is renamed and changed from the unreleased-rejection
  expectation to the selected-date and tag-ready expectation.

No runtime, scanner, hook, workflow, dependency, or protected-control code
changes.

path	mode	added	deleted
CHANGELOG.md	100644	1	1
CITATION.cff	100644	1	0
tests/test_release_controls.py	100644	4	4

Linked issue

No issue is linked. The direct owner selection of the intended release date
prompted this change.

Checklist

• The PR title is a Conventional Commit — feat, fix, docs, test, refactor, or chore. Given the trust core's change bar, feat usually needs an accepted proposal issue first. Everything is merged by squash, so this title becomes the permanent commit subject on main. See CONTRIBUTING.md.
• just test passes.
• just lint passes.
• just deps passes — causal_continuity_engine/ still imports nothing outside the standard library.
• just bench passes — all eleven ContinuityBench scenarios, every metric at target.
• just corpus passes — the reference still agrees with the committed vectors in vectors/.
• just caps passes — every capability claim still resolves to real symbols, files, and tests. If the claims changed, docs/CAPABILITIES.md was regenerated with python -m causal_continuity_engine.capabilities --write rather than hand-edited.
• just build passes if packaging, generated assets, or release machinery changed — both builds match and the clean-installed wheel audits successfully.
• Every commit carries a Signed-off-by trailer (git commit -s). Enforced: the DCO check is a required status on main, so a pull request with any commit missing the trailer cannot merge.
• No gate was weakened, skipped, or made conditional in order to get a test to pass. If a gate had to change, that change is the subject of this PR and is argued for above.
• No AI attribution anywhere in the diff, commit messages, or PR title or body.

The signed commits and canonical gate establish the repository-facing checklist
items above. The PR-title/body portion of the final item is supported
separately: the frozen metadata stream was scanned clean by the pinned content
scanner and by the published-base and new-head attribution-scanner invocations.
Those two attribution invocations used byte-identical scanner programs and are
not independent verdicts.

If this is a bug fix

Not applicable — this is an intentional release-metadata transition, not a
defect repair.

Date correction and superseded intent

2026-09-08 was the prior owner-selected intended release date. It was
superseded by 2026-09-09 before any tagging or release. No release occurred
under 2026-09-08: no tag, no GitHub Release, and no package publication.

The 2026-09-08 records remain preserved as historical evidence. They were
accurate for their transaction and are not failures. The superseded release
checker still reports the 0.1.5 metadata internally consistent and tag-ready
for 2026-09-08 on its own tree; that result is preserved, not relabelled.

The correction is additive. Commit b66580ef02141f07c5d2772fb2d115eeee8472cf
was not amended, rebased, reset, squashed, or replaced. The branch now carries
two signed commits relative to main.

Transition evidence

The base is not defective and is not a pre-fix tree. The evidence below records
a state transition, and the single failure is the intended transition signal
rather than a regression.

• Pristine metadata checker: status 0, reporting 0.1.5 as unreleased.
• Pristine release-mode checker: status 1 with empty stdout and the exact
  diagnostic release mode rejects a not yet released changelog heading.
• The existing base selector passed.
• Corrected-test overlay on the superseded 2026-09-08 metadata: seven cases,
  one intended semantic transition failure, six passes, zero errors and zero
  skips.
• The exact failure was
  assert ('0.1.5', '2026-09-08') == ('0.1.5', '2026-09-09').
• Candidate normal checker:
  release metadata is internally consistent for 0.1.5 (released 2026-09-09).
• Candidate release-mode checker:
  release metadata is tag-ready for v0.1.5 on 2026-09-09.
• Candidate focused selectors: seven of seven passed.

These are evidence summaries bound by the installed run records. The short
installed pytest logs are progress output only and are not self-contained
command transcripts; the exact argv lives in the run records. No new test
invocation was made to write this body.

Candidate identity and verification

• candidate c28f9a497001f375f16b479eb3c629347a589e44
• correction parent b66580ef02141f07c5d2772fb2d115eeee8472cf
• published base 3ec3f79f358a1e410e7b055a0a66e08935d885bf
• tree 9da05379dd23095df4582b2381ab590de79b966a
• cumulative patch against the published base 1,898 bytes, SHA-256
  548d3816ad4e0dd2504024abd0d017092eaf82dd4d182112d4cfe744e796d046
• cumulative stable patch ID b8f774c959b725751dec71bb0ddc333ccb6df16b
• incremental correction 1,602 bytes, SHA-256
  184921ef383521673726f666040de7145cf09de85a79f3782e647ace07e9bcf7
• incremental stable patch ID a0e9a53fb0152eca3231086cd05b809ba5eeed0e
• three paths, all mode 100644, +6/-5 cumulatively and +3/-3 incrementally
• postimage blobs d9d5b9496aad53c6795121c3defbcd72474bd828,
  9d9eed8dc95f0ca9f90ba316e4adfc45ba845bb4, and
  bf4eec11c5ad0e2d7f060bb4254a9915fd8d6a6b
• owner author and committer, exactly one DCO trailer, exactly one SSH signature
• local verification status 0
• Ruff 0.16.1 clean
• staged-index and post-commit content and attribution scanners clean over 200
  blobs
• commit hooks and gitleaks 8.30.1 ran normally

One uninterrupted canonical gate invocation returned status 0 with all fifteen
stages in order. Canonical pytest was 9.1.1. Its test stage emitted 2,340
pass-progress characters and six skips; those are progress characters, not a
count of tests. The gate also confirmed 44 conformance vectors, 23 capability
claims at 18 implemented, 2 out-of-scope and 3 partial, and eleven benchmark
families with six metrics at target.

Local candidate artifacts, built during that rehearsal:

• wheel 777,744 bytes, SHA-256
  f22201a8425bdd02fd958adefdc6d02eaddbe2dc54888c04c4b683e140290cf2
• sdist 1,901,241 bytes, SHA-256
  6f7d170de537c9dcd19d2476e14ad40218dbbfe651b88b1c54d9442c19bd389b

These are new local identities. The superseded 2026-09-08 distribution
identities are neither reused nor preclaimed.

Scope and protected paths

Protected-path intersection: empty. None of CHANGELOG.md, CITATION.cff, or
tests/test_release_controls.py matches any of the advisory's twelve protected
pathspecs. No content-integrity-policy-change label is requested or required.

After one leased, non-forced fast-forward push, the remote branch and PR #91
carry corrected head c28f9a497001f375f16b479eb3c629347a589e44. The
resulting head-update (synchronize) wave completed with all 16 exact-head
checks successful across six new attempt-1 runs. Advisory run 34384015399 was
bound to PR #91, base
3ec3f79f358a1e410e7b055a0a66e08935d885bf, and head
c28f9a497001f375f16b479eb3c629347a589e44; steps 2-7 all succeeded. It
scanned the 200-blob candidate tree, both commits in the base-to-head range, and
the then-hosted v2 pull-request metadata cleanly.

The synchronize action is conclusively deduced from the workflow trigger set
and the observed head update; it was not directly read from an API field. Step
7's empty-protected-diff path is established by mutually exclusive control flow
and the silent successful step, not by a printed diff_status=0. It required no
label, and PR #91 remained zero-labeled.

Immediately before that body-only edit, GitHub still served the earlier v2 body.
That stale body was not treated as semantically current: the green synchronize
wave validated the corrected head and content-policy checks, not the v2 body's
factual currency.

The v4 body's own edited-event checks then ran and succeeded: attribution check
102596071359 from run 34390114752, and advisory check 102596072848 from
run 34390114909, both attempt 1. Pull request #91 subsequently returned to
ready. It was then deliberately returned to draft after the still-open manual
pre-merge requirement below was identified, so that the requirement could be
discharged before any merge is considered.

Release boundary and limits

• 2026-09-09 is owner intent recorded with trusted_time:false. It is not
  "today" and is not independently verified time.
• No release has occurred, under either the previous or the current date.
• tag-ready is only the local checker's result.
• release_ready:false, publishable:false, and release_occurred:false
  remain accurate.
• The candidate is not on main.
• The local canonical rehearsal does not establish the release workflow's
  immutable hosted handoff.
• The manual built-wheel real-client exercise has now been performed once and
  is evidenced. The candidate wheel
  causal_continuity_engine-0.1.5-py3-none-any.whl (777,744 bytes, SHA-256
  f22201a8425bdd02fd958adefdc6d02eaddbe2dc54888c04c4b683e140290cf2) was
  installed alone into a fresh environment and driven by the official MCP
  Python SDK mcp==2.2.0 (mcp-2.2.0-py3-none-any.whl, 365,656 bytes, SHA-256
  bde982589473a060ae145e3406e9a5333fe538c97229ba841f5a7f92be004f81), resolved
  as an isolated verification dependency and installed offline under
  --require-hashes. The project was created with
  <server-venv>/bin/cce-engine --dir <project> init, and the server was
  launched over stdio as <server-venv>/bin/cce-engine --dir <project> mcp
  from a neutral working directory. The negotiated protocol revision was
  2025-11-25. tools/list returned exactly resume_packet,
  list_assumptions, list_invalidations and continuity_check, each with an
  object schema declaring additionalProperties: false. A single
  continuity_check call with {} returned MCP-level isError: false with
  one text block parsing as JSON with name CCE Continuity, list-valued
  open_invalidations, critical, pending_confirmation, failed_proofs,
  verifier_gaps and authority_conflicts, and no continuity_receipt. Its
  parsed application result was conclusion: "failure" with the sole verifier
  gap policy:proof-required-without-required-verifiers. That is the expected
  policy state of a fresh empty project: the exercise proves a successful
  protocol and tool-call round trip, not a successful continuity verdict.
  The recorded state comparison was equality of the canonical SQLite iterdump
  SHA-256 before and after the session, both
  411f0b751ccf40f28e22843fb1a3ebf59ecf85a946cb13fba18258891359372e. That
  establishes equality of that logical serialization only; it is not byte
  identity of the SQLite database file. An earlier operator-harness revision
  raised NoEventLoopError before any transport was constructed, so no child
  process was spawned and no MCP traffic occurred; it is preserved as a
  permanent non-verdict and was never relabelled a pass. The corrected harness
  then completed one transport-bearing exercise, and no transport attempt was
  retried. Evidence: UNIT18-MCP-SDK-2.2.0-c28f9a4.v1.lock.txt
  (2,898 bytes, SHA-256
  168878f28c08b6b2d8fdad8056678d66d9d67d0cae410467ac59469c3debebc2),
  UNIT18-MANUAL-MCP-REAL-CLIENT-c28f9a4.v1.py (2,563 bytes, SHA-256
  64813c459bc4408fd720039284875275a80558d6c94dad1c0a9537ad32ce09f7),
  UNIT18-MANUAL-MCP-REAL-CLIENT-c28f9a4.v1.result.json (3,209 bytes, SHA-256
  db6b75dffa7a4e2f69d13f222832036b7080138cda3cf1f2968781daf190343b) and
  UNIT18-MANUAL-MCP-REAL-CLIENT-c28f9a4.v1.run.json (18,219 bytes, SHA-256
  bbc530e9f2d2d9fec7a43b194e5f44e55c2e4e8683f690950986c35f3ed15e51). This
  proves one macOS, Python 3.14.6, mcp==2.2.0 stdio path against that wheel;
  it does not prove every client, transport, platform or Python version, and it
  does not cover the future squash-built distribution. It does not substitute
  for the mandatory repetition from the dedicated clean main checkout before
  tagging.
• No fresh tag or ruleset release preflight has occurred.
• No signed annotated v0.1.5 tag, release-workflow artifact, GitHub Release, or
  package publication exists.
• The local distribution hashes above are not future release-asset identities.
  The squash commit will have a different identity, so the build stamp can
  change the built bytes.
• Opening or merging a pull request does not authorize tagging or publication.
• A tag, a GitHub Release, and a package publication each require later
  explicit owner authorization.
• If the intended date changes again before tagging, this head, body, tree,
  patch, tests, build evidence, and commits are invalid and require additive
  authority and evidence.