S-018a: a script has no recorded identity, so nothing can tell whether the bytes executed are the bytes intended

Part of the deployment privilege containment sequence (docs/deployment-privilege-containment/). The record half of S-018, addressing the execution half of W-5.

The problem

W-5 has two halves. The write path — which paths a component may register — is closed by S-010 and S-017. This is the other half: the bytes actually executed are never checked against anything.

The share is protected by a gated promotion pipeline, so the threat is not that anyone can write a script. It is that anyone who does obtain write access, by any route, gets arbitrary code execution as the deployment account on every deployment that runs that script, with nothing in DOrc that would notice.

Nothing can detect that without a record of what the script is supposed to be. This is that record.

U-14, resolved

The IS blocked this step on U-14 — nothing specified who records the hash or how it is re-recorded when the gated pipeline promotes a new version. Resolved in SPEC-S-018-script-content-verification.md:

DOrc records it on first dispatch — trust on first use. Not an operator by hand: there are hundreds of registered scripts and a control needing hundreds of manual acts is never adopted. Not the promotion pipeline as a precondition: that is the correct end state and this makes it reachable, but requiring pipeline work outside this repository first means the step delivers nothing until that work happens.

Stated plainly: trust on first use does not establish that a script was legitimate when first seen. If the share is already compromised, the compromised bytes become the baseline. What it detects is change after recording — which is the actual attack, and it converts a silent indefinite compromise into a refusal at the next deployment.

Re-recording on promotion is an administrator-gated endpoint the pipeline calls after publishing. Clearing a baseline means "re-record on next execution", not "stop verifying this one" — there is deliberately no per-script opt-out, because a per-script opt-out is a per-script hole.

Three modes defaulting to report — Off, Report, Enforce — the same shape as script path confinement, because the population that would be refused on release day is unknown until something reports it.

What this half changes

Schema column, entity, API model, the hash computation, the mode setting, and the endpoint that sets or clears a baseline. Nothing reads the column, so it changes no behaviour and ships on its own. The verify half carries the lockstep release constraint and follows separately.

Read docs/deployment-privilege-containment/ and SPEC-S-018-script-content-verification.md first. Implement the schema column, entity, API model, hash computation, three-mode setting, and administrator-gated baseline endpoint described there; done means the record can be stored and managed without changing execution behavior.