The release path has never been executable since the promotion gate landed

[rldyourmnd]

What

This repository cannot publish a release, and has not been able to since
2026-08-05. Nothing has shipped since 0.13.3 on 2026-08-02 — 237 commits
and a dated ## [0.14.0] heading are waiting on a capability that does not
exist yet.

Evidence

The last release predates the gate. 0.13.3 shipped from run
30772172945,
whose job list is exactly two entries — Resolve version and
publish / Build and publish release bundle. At that tag release.yml was
resolve → publish. release-promotion-gate.yml was added two days later in
1fecb00 ("feat(release): require exact promotion evidence"), which is also
when authorize and the release environment appeared.

No release has run since. gh run list --workflow release.yml ends at
0.13.3. The promotion gate has therefore never executed in a real release —
its ledger entry says so accurately: "no live workflow_call run has occurred".

The tag annotation confirms it. git cat-file -p 0.13.3 is the literal text
ci-workflows 0.13.3 plus an SSH signature. It is not a promotion record. The
gate reads the record out of the signed tag payload, so no existing tag in this
repository could satisfy it.

There is only one release path. release.yml's graph is
resolve → promotion → authorize → publish, and check_release_graph.py
enforces that nothing holding a write scope is reachable without both gates.
release-supply-chain-free.yml is a reusable offered to private-free
consumers; it is not wired into this repository's own release.

The actual blocker

release-promotion-gate.yml requires the signed tag annotation to be a
canonical nddev-release-promotion/v1 record whose evidence array holds
exactly nine roles — current-install, current-lifecycle, module-release,
platform-macos-arm64, platform-macos-x64, platform-ubuntu,
root-actionlint, root-secret-scan, root-zizmor — each result: success,
each naming the same control-plane root commit and this repository's exact
candidate commit, each observed within 168 hours.

scripts/promotion_record.py in the private nddev-harnesses validates a
nddev-promotion-evidence-manifest/v1 manifest and signs a record from it. It
does not produce one, and a search of that repository finds no other producer:
the schema string appears in exactly one file, the validator. evidence.py
states the intent plainly — "promotion.decision is pending until every
required lane has a real execution record; approved is never a default", and
each record must carry workflow/run identity, platform, toolchain, timestamps
and an immutable log digest.

So the missing piece is a producer of the evidence manifest — something that
runs the nine lanes, including two macOS architectures, and emits their real run
identities and log digests. That is a control-plane capability. It cannot be
written here, and it cannot be hand-authored without asserting nine
verifications that were never performed, which is precisely the false green this
repository exists to catch.

Why nothing caught it

check_release_graph.py was written because "release-promotion-gate.yml
existed, was documented, was exercised by its own validator" while no validator
read the graph. It now proves the graph is correctly gated. Nothing proves
the graph is traversable — that every gate's required input has a producer
somewhere. This issue is the next iteration of that same class.

What this repository can do

• VERSION and the 0.14.0 CHANGELOG heading are already merged and correct.
• docs/09 and catalog/runtime-coverage.yml are corrected here to state the
  barrier instead of implying the next release re-proves the supply chain.

What has to happen elsewhere

An evidence-manifest producer in nddev-harnesses, or an explicit decision to
change the gate. Until one exists, 0.14.0 cannot be tagged, and neither can
anything after it.

[rldyourmnd]

Progress, and a correction to the shape of this blocker.

There were two, in sequence, and this issue is the second. release.yml::resolve
ran validate_all.py -- — every tier — in a job with no GH_TOKEN, no tags, and an
egress allow-list omitting both SDK hosts. Four scheduled checks fail closed under
exactly those conditions, so a release stopped in preflight before reaching the
promotion gate, and therefore before the missing evidence manifest this issue is about
was ever consulted.

Nothing had noticed because the graph had never run: at tag 0.13.3 the release was
resolve → publish and resolve did not invoke validate_all at all. The "Full
validation sweep" step landed in 25b2514 on 2026-08-12, ten days after the last
release. Every green historical release run describes a different graph.

Fixed in #178. The advisory tier now splits by what a check reaches for, and a new
--tier release is core plus the calendar checks — so a release still refuses to ship
an expired external fact, without a publishing graph reaching the network to find out.
It passes with no token and no reachable host, which is the point:

$ env -u GH_TOKEN -u GITHUB_TOKEN … --launch validate_all.py -- --tier release
validate_all (release): OK

catalog/validation-tiers.yml plus check_validation_tier_contract.py now hold every
caller of validate_all to the capabilities its tier needs, so this cannot recur
silently in any of the three callers.

This issue is unchanged and still blocking. The promotion gate was not weakened —
no role, signature, freshness or exact-SHA binding was relaxed. The evidence manifest
producer in nddev-harnesses is still absent, and that is now the first thing a
release meets rather than the second.