Phase 0 is not complete until this lands. Split out of #702 per the PR 708 review.
#708 delivers ratification and visibility: the seat can tell whether it is running the approved artifact, and the operator sees it. It does not deliver the third limb of R7c — writes to the deploy closure must themselves be gated, refused, and escalatable.
The closure (per PRD R7c: a write that can redirect which binary executes is equivalent to a write to the binary):
- the systemd unit /
ExecStart path
- the deploy scripts
- the staged artifact path
- the ratification manifest itself — a write to it redefines what "ratified" means
Why it is not in #708 — the control demonstrating itself, twice.
-
The closure is enforced by the hestia gate's canonical governance-file list, which lives in the shared gate-core module. That module is itself on the list, so a session under the gate cannot edit it. Intended behaviour for authority-bearing surfaces, and the reason this belongs to a deliberate, separately-reviewed act.
-
Filing this issue was also refused on the first attempt: the gate classifies writes by payload, and the body quoted the protected module's literal filename, so an issue describing the closure read as an edit to it. The literal is elided here for that reason — stated rather than worked around, since routing around it is precisely the behaviour the rule exists to surface.
Work:
- Add the hub deploy-closure filenames to the canonical governance-file tuple, plus each enforcing gate's fail-safe literal (they are mirrored, not imported, precisely so a failed import cannot disarm self-protection — a drift test makes them agree).
- Entries match filenames anywhere, so they must be distinctive enough not to over-match ordinary files.
- Acceptance (PRD criterion 9, second half): a write to any closure element from a gated session is refused and escalatable, asserted by a test that induces the write rather than reading the list.
Related: deploy the manifest root-owned / 0644 so the daemon user cannot write it at all — defence in depth that does not depend on the gate. Documented in hub/docs/MAINTAINER.md.
Phase 0 is not complete until this lands. Split out of #702 per the PR 708 review.
#708 delivers ratification and visibility: the seat can tell whether it is running the approved artifact, and the operator sees it. It does not deliver the third limb of R7c — writes to the deploy closure must themselves be gated, refused, and escalatable.
The closure (per PRD R7c: a write that can redirect which binary executes is equivalent to a write to the binary):
ExecStartpathWhy it is not in #708 — the control demonstrating itself, twice.
The closure is enforced by the hestia gate's canonical governance-file list, which lives in the shared gate-core module. That module is itself on the list, so a session under the gate cannot edit it. Intended behaviour for authority-bearing surfaces, and the reason this belongs to a deliberate, separately-reviewed act.
Filing this issue was also refused on the first attempt: the gate classifies writes by payload, and the body quoted the protected module's literal filename, so an issue describing the closure read as an edit to it. The literal is elided here for that reason — stated rather than worked around, since routing around it is precisely the behaviour the rule exists to surface.
Work:
Related: deploy the manifest root-owned /
0644so the daemon user cannot write it at all — defence in depth that does not depend on the gate. Documented inhub/docs/MAINTAINER.md.