Module binding 

Fail-closed response validation (A3, #1837).

Pure rules over types this crate already owns — the same shape as plan_presentation, and for the same reason: none of it touches SQLite, a TTY, or a socket, so none of it belongs in a crate that does. Keeping the security-relevant logic in the dependency-minimal layer is what makes it auditable.

Validation is ATOMIC. A response is accepted as a whole or refused as a whole. There is no partial acceptance and no “apply the controls that checked out” path, because a caller handed half an answer would have to decide what the other half meant — which is exactly the per-surface drift this epic exists to end. It is also what keeps the Lean authorize / hidden_action_rejected generalization honest: a hidden or unoffered control cannot ride along beside a valid one.

Actions map only to caller-registered handlers. Nothing in a definition is executable. A definition carries markdown, labels, and option ids authored by — possibly — untrusted markup, and this module never turns any of it into a command, a URL, a tool name, a path, a topic, or a caveat. The accepted outcome names a HandlerId the CALLER registered, and nothing else. A registry owned down here would be a second capability system growing beside the store (epic law 13); authority-minting stays above this layer.

Structs

Accepted

A response that passed every rule, with its actions resolved.

HandlerId

A caller-supplied handler name.

RegisteredAction

One action the CALLER has registered, and who may invoke it.

ResolvedAction

One accepted submission, resolved to the handler the caller registered.

ResponderContext

What the caller brings to a validation: its fence and its handlers.

Enums

Refusal

Why a response was refused. Every variant is a REFUSAL: there is no variant meaning “accepted with reservations”.

Functions

resolve_typed

Check one submission against the control it claims to answer.

validate_response

Validate response against the offer it claims to answer.