Only the gates service resolves a gate
- Context: a decision waiting on you lived in three places (drafts, plan items, Inbox messages), each with its own state and its own way to be closed, and an agent’s session can call every client route.
- Decision: every decision waiting on you is a gate, and only the gates service closes one: by you, through a client or an agent session you drive; by a rule of a
[gates.approval]table the service’s trusted policy holds now; or by the rulewindow, to its default, once its deadline passed. A resolution by a plugin is refused; a request that carries a session handle resolves as the agent through that session, which the service accepts only when you drive the session and its own turn did not produce the gate’s subject. A gate’s status comes from its intent’s declaration ingates.toml, never from the client, and resolving it applies the one consequence its kind names. No other code callsResolveon a gates store or writesgates.status. Every gate opens through the service too, a gated verb’s and a missing record’s included, so its policy decides it and it takes its unit’s task. A post an agent makes at once is recorded as a gate already approved, which is no resolution. - Consequence: one guard holds every decision, whatever later lanes move onto gates; a lane that closes a gate goes through the service, so no route around the guard can appear unseen.
- Enforced by:
TestOnlyTheGatesServiceResolvesAGate,TestNoUnattendedAgentResolvesAGate,TestGatePathRefusesAnAgentSession,TestAnIntentsStatusComesFromGatesToml,TestRecordSentIsNotAResolution,TestAGatedVerbOpensItsGateThroughTheService. See Gates.