A real application is a stack: a product dictionary, the customer's customisations over it, and the data database that uses them. An agent working on it has to know which layer it is reading, which one a change will land in, and whether it may write at all. This release makes each of those answers explicit at the start of the session instead of something the agent discovers by failing.
Told up front
- Write access stated at connect. The session's opening instructions say, per dictionary, whether the caller is a full writer or read-only, and name the missing permissions if read-only.
- A whole stack from one endpoint. A development endpoint accepts a data database and serves every dictionary it stacks.
- Instructions kept short. The opening instructions are measured in tokens and held under a fixed ceiling, so the context they consume cannot grow unnoticed.
Reading and writing across layers
- Collection reads over every layer. A listing tool may omit the dictionary and read the whole stack in order.
- Edit where found. A change to an existing definition can omit its layer and lands in the layer that holds it; a write that would land on a production dependency is refused, and one on a shared layer must be acknowledged.
- The REST surface. Agents can now read an application's REST contexts and endpoints and, with write permission, create, edit and delete them. A committed endpoint answers on the next request on every database that stacks the dictionary, and every write is a dry run by default.
These are clarifications of reach, not extensions of it: every read and write is still decided by the caller's grants on the dictionary it touches.