ci(ci): add the shared knowledge-layer check to pull requests

[azlekov]

Installs the shared knowledge-layer check on pull requests. Found while sweeping the org for repos whose .zavet/ layer was not being enforced anywhere.

14 of the 32 decisions here declare checks:, and none of them have ever run. The local git hooks cover the guard trailers, but only for contributors who installed them and did not pass --no-verify. There has been no floor under that.

Worth saying why this is only landing now: the shared workflow could not have run these checks before today. It invoked .zavet/check.sh, a script the tool has never shipped, and it installed no toolchain for checks that need one. Both were fixed in dodi-smart/.github#13, so the workflow now calls the real runner and accepts a stack.

Hosted runners, deliberately

stack: rust
install: ""
runner-weight: hosted

D-0012 forbids self-hosted on any pull_request workflow in this repo, and this workflow triggers on exactly that. Its reasoning applies here unchanged: this is a public repo, cargo test compiles and runs the contributor's own code, and the self-hosted pool is persistent and inside the network, so one approved pull request buys lateral access that survives into later legitimate runs.

The shared picker would have forced hosted anyway — it refuses self-hosted for public repos and fork PRs with no opt-out — and the org runner group sets allows_public_repositories: false, so a self-hosted selector would have queued until it timed out and read as a hang rather than a refusal. Three independent reasons for the same answer, so the input is set explicitly rather than left to any of them. Please do not "optimise" this to a weight preset later; the comment in the file says so too.

install: "" because Cargo resolves dependencies on demand, so there is no separate install step to run.

Expect some of these to fail on the first run

14 checks, none ever executed in CI, so a fair number may have rotted since they were written. That is the point of turning them on, but the first red run is information, not necessarily a regression. A check that no longer holds means either the code drifted or the decision did, and the fix differs.

Refs: D-0012

🤖 Generated with Claude Code

[github-actions]

Knowledge layer

Check	Result
Decision checks	passed
Guard trailers	passed

Spec currency is reported in the job summary and never fails a build, the same severity the local pre-commit hook uses.

[azlekov]

First run: 38 checks executed, 1 failed. That one is worth looking at, because the invariant is fine and the check is not.

FAIL	D-0021	the exec-staging lock still exists

The check is:

grep -qF 'static EXEC_STAGING: Mutex<()>' cli/dira/tests/update_e2e.rs

The lock still exists. It moved to cli/dira/tests/common/mod.rs:37, and update_e2e.rs now imports it (use common::{… lock_staging …} at line 53) and still takes it at lines 252 and 631. D-0021's other three checks all pass, including no fork bypasses the lock and the full cargo test -p dira --test update_e2e run, which is the strongest evidence the behaviour is intact.

So this is the decision drifting, not the code: the check hard-codes a path that a refactor moved, and nothing noticed because these checks had never run. Pointing it at the new location should be enough:

- the exec-staging lock still exists :: grep -qF 'static EXEC_STAGING: Mutex<()>' cli/dira/tests/common/mod.rs

I have not made that edit. Correcting a decision record is a judgement about the decision, and it is yours rather than mine, especially since you may prefer a check that does not hard-code a path at all.

The other 37 pass, so once this one is settled the workflow is green.

🤖 Addressed by Claude Code