Delegate Is Depth One

A Child Is a Session, Not a Thread

delegate starts a child with its own record, its own leg, and a tool restriction of the parent. Visibility is authority. The child's tools are requested ∩ parent-visible ∩ parent-authorized, resolved against the parent's own surface and policy. An escalating or hidden request is refused loudly, never silently stripped. delegate itself is absent from the child and refused, so depth one is enforced twice. No parent history is inherited. Bounds are the child's own recorded caps.

Until the intersection was the gate, a parent that had denied write could still hand write to a child and apply the change set. Applying a change set is the parent writing. Parent mutation authority is rechecked at apply time as an independent second gate: the parent may apply if it still has write or edit. write:deny plus bash:allow is not enough for parent_not_authorized if edit remains allowed. A bash-holding child does not walk around a write-and-edit deny, because bash is neither. An escalating write request is refused at admit, before apply.

Depth one, twice. Once because the child cannot call delegate. Again because apply is the parent, and the parent is still under its own policy.

Scratch, Then a Typed Set

A write-capable child works in a scratch copy and returns a typed change set with expected-old digests. The parent verifies every pre-image, stages every new body, then applies through a transaction directory with rollback on failure. A digest mismatch rejects before mutation. This is process-level all-or-nothing, not a claim that POSIX can publish many files at once. In-process children share the process and user — this is not a sandbox.

Code

The two gates a child cannot talk past·text

admit child tools = requested ∩ parent-visible ∩ parent-authorized
refuse escalate / hide — do not strip
child.delegate     = absent and refused
apply change set   = parent writes; need write OR edit
write:deny + bash:allow + edit:allow  → apply still allowed
write:deny + edit:deny                → parent_not_authorized
bash ≠ write

Exercise

Write a parent policy that denies write AND edit, and allows bash. Then write the child request that used to launder a mutation through apply. Name the second gate that now stops it, and why write:deny plus bash:allow is not enough if edit stays allowed.

Hint

edit suffices at apply. parent_not_authorized fires only when the parent may neither write nor edit. An escalating write request is refused at admit.

A Child Is a Session, Not a Thread

Scratch, Then a Typed Set

Code

External links

Exercise

Progress

Comments 0