Repository navigation
release.yml has failed since 2026-09-08: compliance report cannot resolve cross-repo externals #284
Description
release.yml has failed on every run since 2026-09-08 — eight consecutive failures, the most recent 2026-09-30. The failing job is Build compliance report, step Generate compliance report, and there has been no release since v0.11.0 on 2026-08-12.
What rivet reports
[WARN rivet] could not load externals: IO error: external project at ./../kiln
has no rivet.yaml — expected config at ./../kiln/rivet.yaml
ERROR: [DD-8] link 'satisfies' requires at least 1 target, found 0
ERROR: [DD-9] link 'satisfies' requires at least 1 target, found 0
ERROR: [DD-10] link 'satisfies' requires at least 1 target, found 0
ERROR: [DD-11] link 'satisfies' requires at least 1 target, found 0
ERROR: [DD-12] link 'satisfies' requires at least 1 target, found 0
ERROR: [DD-13] link 'satisfies' requires at least 1 target, found 0
ERROR: [DF-13] link 'traces-to' targets 'synth:ARCH-003' which does not exist
ERROR: [DF-13] link 'traces-to' targets 'synth:NFR-002' which does not exist
ERROR: [L-7] link 'traces-to' targets 'synth:L-6' which does not exist
ERROR: [EXTERNALANCHOR-001] unknown artifact type 'external-anchor'
The warning and the errors are the same fact twice. Cross-repo validation expects sibling checkouts at ./../kiln and ./../synth; the externals do not load, so every link into them resolves to zero targets and each one is then reported as a broken link. The traceability is not wrong, it is unresolvable — rivet cannot see the far side.
[EXTERNALANCHOR-001] unknown artifact type 'external-anchor' is separate and may be a version question. compliance.yml pins the rivet binary, and that pin moved 0.35.0 → 0.37.0 on 2026-09-15 and 0.37.0 → 0.39.0 on 2026-09-29. The failures predate both, starting 2026-09-08, so the pin is not the origin — but whether external-anchor is still a type rivet 0.39.0 accepts is worth confirming rather than assuming.
Why this is worth more than a stale report
The other three repos with this problem simply stopped attaching a report. sigil cannot cut a release at all. The compliance job is inside the release path rather than beside it, so a traceability error that would be a finding on its own is a release blocker.
Two things to decide:
- Whether cross-repo validation belongs in the release path. If the answer is yes, the sibling checkouts have to be part of the job rather than assumed; if no, the job wants
continue-on-errorand the finding wants to surface somewhere that does not stop a release. - Whether the kiln and synth checkouts are missing or merely lack
rivet.yaml. The message says./../kilnexists and has no config, which reads as a checkout whose path or ref is wrong rather than one that was never made.
Where this showed up
pulseengine.eu publishes whatever reports exist, so the Reports page has been showing sigil v0.10.0 as current evidence while the layer ships wsc 0.11.0. Found while checking whether the site was publishing correctly — it was.
Three sibling repos stopped for an unrelated reason, filed separately: pulseengine/synth#1453, pulseengine/loom#399, pulseengine/wohl#64. A detector was added at pulseengine.eu#212 and now annotates every deploy with the projects that have gone quiet.
Activity
A rivet project for the gates, and a release spine for the plugin (#216)
fix(ci): clear 9 advisories; stop one unresolvable external voiding a…
fix(ci): unfreeze the rivet binary pin, and give it a watcher
avrabe commentedon Oct 21, 2026
Correcting this issue's root cause. I wrote the original diagnosis by correlating dates — dependabot bumped the compliance action 0.32 → 0.35 on 2026-09-01, release.yml first failed 2026-09-08 — and concluded the stale
rivet-version: v0.3.0meant "a rivet 0.3.0 cannot parse this repo's schemas". The log from the first failing run says otherwise.Run
34174312781, job101900580327:rivet 0.3.0 byte-slices a title to truncate it during HTML export, and
artifacts/dev/features.yaml:669gained an em dash. The step that dies is Export HTML report — not Install Rivet, and not Validate (0.3.0 does not enforce the status enum, so validate printed PASS).So:
Exported 553 pages, exit 0, no panic.kilnexternal (declared at a path that does not exist) is a real defect and does void cross-ref checking for every external — 31 errors → 22 with it removed — but it is not why this job fails, and the 31 → 22 drop only happens where../synthis reachable, which is never true in a single-repo CI checkout.Also correcting the impact claim. This issue says "there is no release". That is wrong:
build-and-releaseneeds onlybuild-native-cli, and nothing inrelease.ymldepends onbuild-compliance. v0.11.0 shipped from a red release run for exactly that reason. What #284 has cost is the compliance evidence, not the artifacts.#307 unfreezes the pin to v0.41.0 and adds a
captures-agreeclaim so the pin cannot silently refreeze (dependabot rewrites only theuses:line — #312 is doing it again right now). After #307 the job is still red, now at Validate:rivet validateexits 1 on 22 mechanical errors (11 off-vocabularyin-progressstatuses, 6 emptysatisfieslinks, 3 undeclaredrelated-tolink types), and 31 in CI because../synthcannot resolve there. Closing those plus a pinned synth clone is the follow-up, and it is a prerequisite for tagging v0.12.0.🤖 Generated with Claude Code
https://claude.ai/code/session_012aR3Md1h46K9wAUWMQiESH
docs(changelog): #305, REQ-31, #284 — and correct a false potency claim
docs(agents): write down the four things this release learned the har…
Merge #313: toolchain 1.96.1 + wasmtime 49.0.4 — retires the 9.3 CRIT…
fix(rivet): `rivet validate` 22 errors -> PASS, and make externals re…