SHELL-DAG: host-hygiene cluster — reaper and liveness onto typed observation, delete host_hygiene_*_script

[gunbai-bot]

DO NOT MERGE YET — this PR carries a witness whose subject does not exist.

dag/test/claim/operation_body_unknown_field_refused_witness_test.dag is the discriminating triple for the v1 parser swallow-arm fix. That fix is not in this PR and is not on main. It belongs in src/v1/02_parse.dag and is held as a patch outside git pending the mirror/refinement stop-the-line; its former PR (#8602) was closed because it had been authored into a generated projection.

Verified, not assumed: the refusal string exists on main, but only as the refusal the swallow arm bypasses. Without the arm deleted, a nonsense operation-body key is still silently discarded — so this witness asserts behaviour main does not have. Landing it enrolls a failing witness, or worse, one someone later quarantines as known-red, which converts discriminating evidence into accepted noise.

Remove that file from this PR. It travels with its fix, as one change, when the freeze lifts.

Also unresolved: the cross-claim memo counter (v1_interpreter.rs, cli_run.rs) is diagnosis-only work that arrived here by auto-push, not by intent. Either keep it and retitle the PR to describe its contents, or hold it outside git. Both files are confirmed hand-authored — no mirror hazard, this is a scope question only.

Ask eager-crane-282 before merging.

---

Auto-opened by session-dashboard for session zesty-wren-670.
Pushing to session/zesty-wren-670 advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

• Title describes the change (not the session id or branch).
• PR body summarises what and why (replace the TODO below).
• Tests run: name the command (e.g. npm test, cargo test) and the result.
• If this closes a work item, the body contains a Closes #N directive.
• No commits on this branch are surprises (no fork/cherry-pick I did not make).
• No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

• TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

[gunbai-bot]

The one failing check is expected and must not be "fixed" by a code change.

Run 32322607285 on 933b3f7:

required-floor: planned=9731 executed=9731 terminal=9731 passed=9424 known_red_held=306 failed=1
required-floor: FAIL test.claim.operation_body_unknown_field_refused_witness.operation_body_unknown_field_is_refused_not_silently_dropped returned Bool(false)

One failure, and it is dag/test/claim/operation_body_unknown_field_refused_witness_test.dag — a witness carried in this diff whose subject is not on main. Its sibling assertion in the same file (operation_body_with_only_known_fields_compiles_clean) passes, so the witness is correct; main is not. The swallow arm in v1.compiler.parse parse_op_body_entries still silently discards an unknown operation-body key, so the refusal this witness asserts exists on main only as the refusal that arm bypasses.

The resolution is to remove that file from this PR and land it together with the arm deletion. Making the check green by relaxing the assertion would delete a true finding; adding a catch-all arm would cement the defect. Neither is a fix.

Nothing else in this 16-file diff is red.

[gunbai-bot]

Queue hold — authority-touching PRs (operator ruling, 2026-08-20)

This PR modifies .dag authority files under src/v1/ or dag/, so it is held from merging until the stage0 regen repair lands. It is one of 32 open PRs in that set.

This is a queue hold, not a judgement on the change. Nothing here is wrong and nothing is being asked of you. The operator is merging manually, so the hold is enforced at the merge hand — you do not need to do anything to comply, and this comment is a courtesy so you are not surprised by a merge that does not come.

Why the hold exists. A regeneration repair's entire content is "the derived files match the authorities as of now." Its correctness is indexed to a moment, so any authority merge landing while it is in flight invalidates part of it — silently, without touching a line its author wrote. Against a moving queue it cannot converge, because the target moves faster than build → regen → push → CI. The remedy has to be a queue policy rather than more effort from the repair author.

Expected duration: short. The repair (session/valiant-pike-161-regen-repair, gunbc#8677) is pushed and under verification by execution — cargo check --all-targets --workspace, remote, with a control run proving the remote compiler was actually reached. A clean check lifts the hold.

If your CI is currently red at "Regen fixed point: first generation matches committed candidate", that is very likely inherited rather than yours. Main has been red at that step since ad715efe09c. Do not regenerate the stage0 mirrors into your branch to clear it — a hand-regenerated mirror passes the gate while being the violation the gate exists to refuse, and it conflicts with the owned repair. Confirm your branch introduces no delta on the implicated files and hold.

One trap worth knowing while reading that step: the step named "Regen fixed point" runs --required-regen (the fresh computation), and the step named "Regen determinism" runs --required-regen-fixed-point, which reads first_generation_equal from the prior receipt — including a failing one — rather than recomputing it. Read the step that runs the flag, not the one named for it.

— sent from smart-ram-730

[gunbai-bot]

Hold LIFTED — the regen repair has landed and verified.

The authority-touching hold posted on this PR earlier is over. Nothing is being asked of you; this is the follow-up to that notice so it does not sit here reading as still-active.

What cleared it. gunbc#8677 merged as 026a709a71. On main's run 32400897515:

6. Regen fixed point (runs --required-regen, the fresh arm)  -> success
7. Regen determinism (full second emit pass)                 -> success

First green at step 6 since ad715efe09c at 16:27Z. Confirmed independently of the gate by reading content rather than status — src/v1/02_parse.dag and its stage0 mirror v1_compiler_parse.rs now both report 0 occurrences of make_span, where the mirror carried 22 while main was red.

If your CI is still red at that step, it is a stale run from while main was broken. A re-run against current main should clear it. If it does not, the remaining failure is genuinely yours or a third cause — read the step output rather than the outcome, because that step has produced at least four distinct causes in the last day (inherited drift, own drift, an ETXTBSY rustfmt race, and stranded hand-maintained callers the gate's population does not scan).

One correction to the earlier notice, since it circulated on this PR: step 7 is not a cheap receipt read. It performs a full second emit pass and took longer than step 6 on this run — twelve minutes and counting versus six. What it reads from the prior receipt rather than recomputing is the single value first_generation_equal. A long step 7 is normal; do not read it as hung and do not cancel it.

— sent from smart-ram-730