@plurnk/plurnk-contracts 2.0.0 → 3.0.1

package/.env.defaults

@@ -7,5 +7,5 @@ PLURNK_HOST=127.0.0.1
 # The daemon's TCP port, shared by all client interfaces.
 PLURNK_PORT=1066
 # The whole URL a client dials instead: a remote portal, or a daemon bound to an address no
-# client can dial (0.0.0.0). Unset = http://$PLURNK_HOST:$PLURNK_PORT.
+# client can dial (0.0.0.0). Unset = http://$PLURNK_HOST:$PLURNK_PORT/agui.
 # PLURNK_AGUI_URL=

package/README.md

@@ -1,9 +1,8 @@
 # @plurnk/plurnk-contracts
 
 The single authority for PLURNK's model-facing language contract, its AST,
-generated model rail, shared schemas and types, runtime-neutral Problems,
-operation results, Notices, and text coordinates. See SPEC
-{§root-value-api}.
+shared schemas and types, runtime-neutral Problems, operation results,
+Notices, and text coordinates. See SPEC {§root-value-api}.
 
 ## Install
 
@@ -27,8 +26,7 @@ Requires Node.js 26 or newer.
 JSON Schema owns shared wire shapes, generated TypeScript projects those
 shapes, and ANTLR owns accepted model-language syntax. See SPEC
 {§contract-representations}. An operator who wants constrained sampling on a
-llama-server route writes their own GBNF and points `PLURNK_PROVIDERS_GBNF` at
-it; this package ships no grammar profile.
+llama-server route writes their own GBNF and points `PLURNK_PROVIDERS_GBNF` at it.
 
 ## Parser
 

package/SPEC.md

@@ -10,7 +10,7 @@ runtime-neutral wire envelopes; `@plurnk/plurnk-parser` implements the language
 | Surface                                                                         | Canonical export or artifact                        |
 | ------------------------------------------------------------------------------- | --------------------------------------------------- |
 | AST, validators, Problems, results, Notices, text regions and extents          | `@plurnk/plurnk-contracts`                          |
-| Capability and loop policies                                                    | `CapabilityPolicy`, `LoopPolicy`, `LoopPolicyRequest`, `PROPOSAL_POLICIES` |
+| Capability admission and approval ownership | `CapabilityPolicy`, `WorkerOwner`, `ProposalPolicy`, `PROPOSAL_POLICIES` |
 | Durable effort                                                                  | `Effort`, `EFFORTS`             |
 | Model route and catalog discovery                                               | `ModelRoute`, `ModelCatalogQuery`, `ModelCatalogPage`, `ModelReadiness` |
 | Stopped-world client contract                                                   | `ProposalDisposition`, `ProposalProjection`         |
@@ -28,8 +28,8 @@ runtime-neutral wire envelopes; `@plurnk/plurnk-parser` implements the language
 
 §contract-representations JSON Schema is authoritative for shared data shapes. TypeScript types are
 generated from the schemas; ANTLR is authoritative for accepted model-language
-syntax. No generation grammar is generated or shipped; an operator's own GBNF
-is carried verbatim to a llama-server route by the providers package.
+syntax. An operator's own GBNF is carried verbatim to a llama-server route by
+the providers package.
 
 §agui-discovery-contract `AguiDiscovery` is the complete installed AG-UI+
 surface at one instant. `schemaVersion` identifies its discovery shape;
@@ -128,7 +128,7 @@ meaning, including registered scheme resolution, target existence, tag
 selection, text-region bounds, result ordering, full-text ranking, mutation
 effects, and executor behavior.
 
-### §contract-proposal-projection Loop policy and stopped-world projection
+### §contract-proposal-projection Admission policy and stopped-world projection
 
 The schemas own the runtime-neutral shapes; core owns their stateful values.
 
@@ -137,9 +137,10 @@ The schemas own the runtime-neutral shapes; core owns their stateful values.
 | `CapabilityDescriptor`    | One routed operation demand with its operation, access class, resource/runtime/tool coordinates, and declared traits | Derive every demand before dispatch |
 | `CapabilityPolicy`        | Exact `only`/`deny` selectors; omitted `only` is unrestricted and present empty `only` denies all | Intersect service and workspace layers |
 | `CapabilityProjection`    | Exact service, workspace, and normalized effective policies | Expose the resolver's workspace cascade without claiming one layer is effective authority |
-| `LoopPolicy`              | One `review`, `accept`, or `reject` proposal disposition | Snapshot once when the loop is created |
-| `ProposalDisposition`     | Client authority, or the loop's exact automatic accept/reject                   | Compute precedence from effective loop policy, proposal kind, and stale-target truth   |
-| `ProposalProjection`      | Identity, `{ scheme, authority, pathname }` review target, body/attrs, effective policy, stale signal, disposition | Derive one validated projection for live delivery and durable reconnect discovery |
+| `WorkerOwner` | Nonempty address, unique client-tool names, and whether it is interactive | Persist by workspace; inherit through worker creation |
+| `ProposalPolicy` | `review`, `accept`, or `reject` | Read the server's disposition knob at the proposal boundary |
+| `ProposalDisposition` | Review, or automatic accept/reject with optional outcome | Select once for the pending gate |
+| `ProposalProjection` | Identity, review target, body/attrs, owner, stale signal, disposition | One validated projection for live delivery and reconnect |
 | `ProviderUsage`           | Conventional input/output totals with cache and reasoning details                | Preserve observed quantities without replacing absence with zero                        |
 | `ProviderCost`            | Exact charged, estimated, or unknown monetary evidence                           | Normalize one monetary disposition for each physical provider request                    |
 | `ProviderRequestAccounting` | Usage and cost evidence for one physical provider request                      | Preserve request order across retries, failover, success, and failure                    |
@@ -163,19 +164,18 @@ than hidden policy behavior.
 
 §capability-policy-projection A `CapabilityProjection` reports every durable
 workspace layer and their normalized intersection: `service`, `workspace`, and
-`effective`. Only `workspace` is client-mutable. Workers and loops have no
-capability policy or inherited bound; every actor uses the same live workspace
-policy. A client never derives effective authority from the mutable layer alone.
-
-§loop-policy A `LoopPolicy` is complete and immutable after creation:
-`proposals` chooses one downstream settlement posture and `attended` says
-whether anyone can answer, independently of workspace capability policy. An
-unattended loop cannot hold a proposal for review, so the schema refuses that
-pair. A `LoopPolicyRequest` is the part of a policy its creator chose to state.
-Contracts hold no default for the rest: the daemon's panel supplies it
-({§loop-policy-composition}). `PROPOSAL_POLICIES` is the schema-owned
-vocabulary of `proposals`. Capability admission precedes effect
-classification and proposal settlement.
+`effective`. Only `workspace` is client-mutable. Workers and loops store no
+capability policy and inherit no bound; every actor uses the same live workspace
+policy. Core derives one further ring per asking worker from its owner, and it only
+removes interaction runtimes ({§owner-interaction-ring}). A client never derives
+effective authority from the mutable layer alone.
+
+§proposal-policy `ProposalPolicy` names one server disposition; `PROPOSAL_POLICIES`
+is its schema-owned vocabulary. `WorkerOwner` carries an address, the client-tool
+names that recipient implements, and `interactive`: whether a person attends it. Neither
+contains resource permissions or
+message-carried authority. Core owns persistence, inheritance and settlement
+({§worker-ownership}, {§proposal-disposition}); capability admission precedes approval.
 
 §effort-wire `Effort` is exactly `off | adaptive | low |
 medium | high | xhigh | max`. The schema owns this shared wire vocabulary. Providers own the
@@ -314,7 +314,8 @@ column-zero line outside any block containing a native operation's name and at m
 `<!-- aside -->`, with only horizontal whitespace otherwise, opens that operation as if it were
 fenced with the taught three backticks. The aside retains its ordinary meaning: no target or
 modifiers are inferred. Its body runs to a line that is exactly the name
-again, to the next heading ({§fence-heading-in-body}), or to the end of the turn. A fence inside
+again, to the next heading ({§fence-heading-in-body}), or to the end of the turn, except
+parameterless KILL always takes the remaining answer region ({§terminal-kill}). A fence inside
 naming nothing known is body; the block expects no closer, so its body is never cut
 back ({§closer-fallback}). A naked `KILL` alone holds every fence inside it as text ({§naked-kill}). It runs, and one warning-severity receipt follows its statement —
 `` `KILL` opened with no fence; the taught form is three backticks. `` One rule for every native
@@ -330,8 +331,8 @@ read this way.
 §fence-heading-in-body Outside a complete nested block ({§balanced-fences}), a fence
 line of three or more backticks and a name that is a native operation or a known executor
 is a heading. Inside an open block it either ends that block without closing it and opens the
-next statement, or it is a literal example held by the block; the block holds it only while
-the block ends at a real closer, and {§fence-pairing} chooses between the two. Fence lines of
+next statement, or it is a literal example held by the block. {§fence-pairing} chooses between
+the two; parameterless KILL always holds the remaining input ({§terminal-kill}). Fence lines of
 fewer than three backticks are never headings ({§operation-fences}). Known executors are `sh`
 plus what the host names in `ParseOptions.executors`. Inside a parameterless `KILL` a
 heading never ends the block ({§terminal-kill}).
@@ -445,11 +446,13 @@ heading. An operation example quoted in a body of its own width therefore reads
 closing and the example running; the wider outer fence or the tab offset quotes it
 ({§operation-fences}).
 
-§terminal-kill **A KILL body is the deliverable.** Inside a parameterless `KILL`, at any depth, a
-heading is a literal example or text and never ends the block; the block ends at its closer or
-the end of the input. Of 796 recorded parameterless KILLs, 9 were followed by any other
-operation, while 62 of 120 SENDs were, so the rule is KILL's alone. It keeps a final report whole
-and never runs a command the report only shows.
+§terminal-kill **A parameterless KILL starts the final answer region.** Once its heading is
+recognized as an operation, the rest of the input is its literal body. A fence cannot return
+that region to executable operations or outside text. Apparent operations, receipts and malformed
+fences within it are answer text. An actual enclosing closer at the end is framing, not body;
+an earlier fence remains body. Compact and recovered naked spellings obey the same boundary.
+Quoted KILL examples do not open this region; targeted KILL retains ordinary statement framing.
+Earlier operations still execute and completion remains subject to {§kill-conclusion}.
 
 §prose-code-blocks **A message or a prompt shows code.** Inside a `SEND`, `WORK`, `FORK` or `BARE`
 body, at any depth, a heading that names an executor (` ```sh `, ` ```python3 `) is a code block the
@@ -460,8 +463,8 @@ operation. In the distinct recorded benchmark emissions an executor heading ende
 run218, run114 and run118, deepdumb run44) was the child's task, the prompt's code or code quoted in
 a report, and reading it as an operation truncated the task and ran the example in the parent.
 
-§message-run-on **A message runs to the end of the turn.** A parameterless `KILL`, or a `SEND`,
-`WORK`, `FORK` or `BARE`, whose block reaches the end of the input without its closer takes it
+§message-run-on **A message runs to the end of the turn.** A `SEND`, `WORK`, `FORK` or `BARE`
+whose block reaches the end of the input without its closer takes it
 there with no repair: the text after its last inner block is still the deliverable, the message
 or the task, never outside text. The run counts as a supplied closer, so a reading that closes at
 a real fence still wins, and it never costs an operation: when the reading that runs on hides more
@@ -470,11 +473,9 @@ operations the author wrote than the best repaired reading, the repaired reading
 inner fence keep what followed it (the qflash run192, run90 and run210 deliverables regain their last
 sections), one echoed transcript (glm run155) runs one more operation, and none loses one.
 
-§naked-kill **A naked KILL is the whole rest of the turn.** A parameterless `KILL` opened without
-a fence ({§naked-operation}), with or without an aside, is a completion: every fenced
-block inside it, a native operation heading included, is text the deliverable shows, exactly as
-inside a fenced KILL ({§terminal-kill}), and the block ends only at its name alone on a line or at
-the end of the input. No operation the deliverable shows runs.
+§naked-kill **A naked KILL obeys the same answer boundary.** A parameterless `KILL` opened without
+a fence ({§naked-operation}), with or without an aside, takes the remaining input under
+{§terminal-kill}. A repeated name can close it only at the end; it never exposes later operations.
 
 §pairing-witness **Witnesses.**
 
@@ -683,10 +684,7 @@ repeat the complete selection/metadata group per operand. ANTLR accepts
 adjacent slots and scope/metadata permutations within a selection without
 changing ownership or making them distinct canonical forms. Each selection
 has at most one scope; its metadata blocks retain their authored order. A second scope
-is refused, and the recovery reads the pair: a line number followed by its anchor
-(`<91> <@abcde>`, a copied row prefix) recovers to the anchor alone, two other single
-positions to one scope with both ends (`<@abcde> <-1>` to `<@abcde,-1>`), and anything
-else to one operation per selection.
+is refused; the recovery is the scope's working form ({§parse-recovery}).
 
 §lifecycle-slots NOTE accepts no target, scope, or metadata. WAIT retains its
 optional target and duration under {§send-wait-scope}. Their literal bodies begin
@@ -716,14 +714,11 @@ are never split. Each URI inherits its slot's scope and metadata and compiles th
 BARE and NOTE take no scope, and neither does a SEND without a recipient; a `<…>` slot on such a
 heading, in any position, is skipped and the operation runs, with one warning-severity advisory
 naming the operation's slots and the dropped scope — `` `WORK` takes a target only; the scope
-`<1,-1>` was ignored. A scope selects lines in READ, EDIT and KILL. `` (`` `NOTE` takes no target or
+`<1,-1>` was ignored. `` (`` `NOTE` takes no target or
 scope; … ``, `` `SEND` without a recipient takes no scope; … ``). An aside is never a scope, a
 recipient SEND keeps its scope for the recipient ({§send-directed-scope}), and WAIT follows
 {§send-wait-scope}. There is no ambiguity: the operation has one reading with or without
-the slot. Before this, the heading drew the grammar's expected-token diagnostic and the turn was
-dead; in the distinct recorded emissions one heading carried the form (zai run426,
-```` ```WORK (worker://deprecation-implementer) <1,-1> ````), beside two recipient SENDs whose scope
-the recipient refuses at runtime.
+the slot.
 
 §heading-inline-body Nonempty body text belongs below the fence header. Text after the slots
 on the heading line is read by the operation's shape, by the builder that reads that operation,
@@ -755,9 +750,8 @@ written on the heading line — under {§heading-inline-body}. The host names th
 (`ParseOptions.jsonBodyExecutors`). A heading that already carries a block keeps the object as
 inline body. On FIND, READ and KILL the same text is the matcher
 ({§naked-pattern}), because a search for JSON text is legitimate; a bare matcher
-that parses as a JSON object draws one advisory naming the option form ("`{…}`
-was read as the matcher; an option block is `[{…}]`."), so the collision is
-learned in the turn it happens.
+that parses as a JSON object draws one advisory saying so: "`{…}` was read as the
+matcher." ({§diagnostic-observation}).
 
 §operation-aside The final header modifier may be one single-line HTML
 comment. AstBuilder removes its delimiters and surrounding whitespace into
@@ -790,8 +784,8 @@ Worker; the shared reader withholds both from the owner's options.
 
 §matcher-option **`pattern` is the matcher, and it lives in the heading.** On
 FIND, READ, KILL, EDIT, and each COPY/MOVE operand, the option
-`[{"pattern": "<matcher>"}]` carries the matcher string exactly as a body once
-did: the leading prefix claims its dialect under {§matcher-prefix-claims}, and
+`[{"pattern": "<matcher>"}]` carries the matcher string: the leading prefix
+claims its dialect under {§matcher-prefix-claims}, and
 AstBuilder lifts it into the statement's `matcher` (`MatcherBody | null`),
 positioned dialect errors included. A block that carries only `pattern`
 leaves `metadata: null` for the owner; beside other keys the block stays with
@@ -800,10 +794,9 @@ language lifts only from one block that parses as a JSON array of objects;
 anything else lifts nothing and reaches the owner's `400` untouched. A
 `pattern` that is present but not a string is the language's own positioned
 diagnostic, as is a matcher of a claimed dialect that fails admission. FIND,
-READ, and targeted KILL take no body: a body beneath their heading is ignored and
-the operation still runs, with one warning-severity advisory naming the
-heading-line form (`FIND takes no body; the body was ignored. A pattern belongs
-on the opening fence line after the path.`); it is never silently read as a
+READ, and targeted KILL take no body: a body beneath their heading is not used and
+the operation still runs, with one warning-severity advisory naming the lines not
+used (`FIND takes no body; lines 4–6 were not used.`); it is never silently read as a
 matcher, and it never strikes ({§matcher-body-redirect}). The heading line itself
 is the matcher's home ({§naked-pattern}). A body that is only an HTML comment is
 still the aside under {§misplaced-aside-advisory}. EDIT keeps its literal body:
@@ -853,10 +846,10 @@ repetition and strike rules still apply.
 
 §reasoning-operations The shared fence parser admits complete, line-leading NOTE,
 FIND and READ statements from exposed provider reasoning. Admission is part of
-the language, not an optional compatibility mode. Other backtick or tilde
-code blocks are opaque; heading and missing-closer recovery cannot escape them or
-complete an unfinished reasoning operation. Blockquoted and inline examples are
-not headings. Other reasoned operations never execute.
+the language. Other backtick or tilde code blocks are opaque; heading and
+missing-closer recovery cannot escape them or complete an unfinished reasoning
+operation. Blockquoted and inline examples are not headings. Other reasoned
+operations never execute.
 
 Operations are admitted only after the provider response completes; their
 presence never interrupts generation. Selected operations precede the content
@@ -905,8 +898,7 @@ one park with the earliest bound, including the configured bound for each bare W
 
 §send-directed-scope A recipient SEND carries an optional numeric scope after
 its target and metadata through to the addressed owner, which assigns its
-semantics or refuses it; worker actors refuse one (`scope-unsupported`, 400),
-because later and recurring delivery belong to the schedule family. A
+semantics or refuses it; worker actors refuse one (`scope-unsupported`, 400). A
 targetless message takes no scope. A scope never changes the message body or
 disposition.
 
@@ -925,12 +917,11 @@ Without a scope, KILL retires or deletes the whole target; with one, it removes
 that span — of a log body's packet projection or of an entry's content. Core owns the
 one-way semantics: there is no operation that restores a scoped-away log body.
 
-§legacy-bracket-slot Brackets are the metadata modifier, never an executor
-selector: the runtime or MCP service is the fence name, and tool input belongs
-in the body. A bracket block that leads an executor fence or follows a target
-is metadata, so a legacy `[node]` selector reaches its owner as metadata text
-and is refused there; a bracket before the target of a non-executor OP is one
-bounded header diagnostic that selects nothing.
+§bracket-metadata-slot Brackets are the owner's metadata modifier: the runtime
+or MCP service is the fence name, and tool input belongs in the body. A bracket
+block that leads an executor fence or follows a target is metadata for that
+owner; a bracket before the target of a non-executor OP is one bounded header
+diagnostic that selects nothing.
 
 The `<scope>` slot is optional where admitted and its domain is OP-specific. FIND
 scopes ordered results. Executions and SEND scope owner-defined timing. READ, EDIT, COPY,
@@ -987,7 +978,7 @@ same bare spelling the receipt used: a model that appends the channel to the pat
 shown addresses the same entry, and so does one that writes it after the parenthesis,
 `(page.html) #readable`, which {§naked-pattern} reads as the channel. `raw` is therefore always the path alone; a
 bare path never contains a literal `#`, and `PlurnkParser.stringify` renders the channel back.
-Without a `#` the field is absent, so an older `LocalPath` literal stays valid.
+Without a `#` the field is absent.
 
 §read-exact-target READ targets one exact resource (a local path or scheme
 URL, with optional `#channel` fragment or `[metadata]`) and has no body. A
@@ -1299,8 +1290,8 @@ operation receives empty-turn recovery, not successful completion ({§empty-turn
 
 The model may supply WAIT or request completion with parameterless KILL. The host, not the grammar, owns
 turn boundaries and adjudicates the loop's actual obligations. Asking
-the human is the native `question` executor tool ({§question-tool}), not a
-disposition. The shape rules ARE structural:
+the human uses the native `question` executor tool, offered only when a person attends the
+worker's owner ({§owner-interaction-ring}), not a disposition. The shape rules ARE structural:
 
 - §send-mid-reservation WAIT is reserved ({§turn-disposition}).
   A turn admits any number of lifecycle declarations, anywhere among its
@@ -1311,6 +1302,8 @@ disposition. The shape rules ARE structural:
   dispositions until the other admitted operations settle
   ({§op-execution-order}). Nothing is dropped and no diagnostic is raised for
   position. Omission does not synthesize a disposition ({§turn-shape}).
+  This applies to WAIT, not to the literal answer region opened by parameterless KILL
+  ({§terminal-kill}).
 - SEND is communication: an optional recipient path and an optional body.
 - §park-202-only WAIT joins live work: an open stream or a live
   child. With none, it continues. Its optional duration bounds parking ({§send-wait-scope});
@@ -1459,7 +1452,7 @@ among them: the parser is `@plurnk/plurnk-parser`'s ({§parser-consumers}).
 | `TurnDisposition`                                   | The one turn disposition and its recognition                        | {§turn-disposition}                       |
 | `CapabilityAdmission`                               | Admission of a capability descriptor against policy layers          | {§capability-admission}                   |
 | `PLURNK_OPS`, `INTERNAL_ROW_OPS`, `PLURNK_FENCE`    | The closed operation alphabet and the language's fence              | {§canonical-statement}                    |
-| `PROPOSAL_POLICIES`                                 | The vocabulary a loop policy chooses from                           | {§loop-policy}                            |
+| `PROPOSAL_POLICIES` | Server proposal disposition vocabulary | {§proposal-policy} |
 | `WORKER_NAME`                                       | Authority minting predicate                                         | {§worker-name}                            |
 | `UNKNOWN_POSITION`                                  | Frozen sentinel for an AST statement without retained parsed source | {§parser-position}                        |
 
@@ -1562,12 +1555,19 @@ schema, this suffix invariant, and Problem status equality.
 | 100–399 | `problem` is forbidden                    |
 | 400–599 | One RFC 9457 `problem` object is required |
 
-The legacy top-level `error` field is forbidden. Producer-specific success
-fields and Problem Details extension members remain open. A malformed result is
+Producer-specific success fields and Problem Details extension members remain
+open. A malformed result is
 an internal producer contract violation; it is not converted into a second
 model-facing failure envelope.
 
-### 13.5 Problem Details
+### 13.5 Diagnostics and Problem Details
+
+§diagnostic-observation **A diagnostic says what happened, never why.** Every Problem `detail`
+and `recovery`, parse diagnostic and notice names what was read, what was done with it, and
+where, and may show the working form of the construct it read or refused. It never names a cause
+or an intent the input does not establish: no likely mistake, no reconstruction of what the author
+meant, no alternative the producer did not apply, and no form the language no longer has. Each
+sentence presupposes only what the producer itself decided.
 
 §problem-details `ProblemDetails` requires `type`, `title`, `status`, and `detail`;
 `instance` is optional until a durable host can attach the occurrence URI.
@@ -1585,8 +1585,8 @@ model-facing failure envelope.
 | extensions  | Factual producer-known operands or constraints                                                                                          |
 
 `detail` is failure truth; `recovery` is not a second explanation. Producers do
-not infer motives, blame the model, restate status, or expose an implementation
-accident as the cause. General syntax and workflow teaching remain in the model
+not blame the model, restate status, or expose an implementation accident as the
+cause ({§diagnostic-observation}). General syntax and workflow teaching remain in the model
 packet rather than being repeated in every Problem.
 
 `Problems.create(owner, code, status, detail, extensions?, options?)` derives a
@@ -1764,17 +1764,14 @@ class PlurnkParseError extends Error {
 ```
 
 §parse-recovery **Every hard diagnostic carries its working form.** A `severity: "error"`
-diagnostic names, in `recovery`, the form that runs, in the model's terms: a refused heading
-carries the operation's canonical line (`` `READ (path) <L,M>? pattern? <!-- aside -->?` on the
-opening fence line; READ takes no body. ``), a refused matcher the dialect's form with an example,
-and a refused regex the regex that matches the words the model wrote — `` A pattern is a regex:
-write `/url/` to match lines containing url; `*` repeats what precedes it. To select files by
-name, put the glob in the target: `FIND (tests/*url*)`. `` — where the glob suggestion is derived
-from the pattern only when it is glob-shaped, and the regex sentence stands alone otherwise. The
-runtime projects `recovery` as the Problem's `recovery` beside the verbatim `message`; an advisory
-carries none, since its statement ran. A refused matcher carries the same pair into its own
-operation's Problem ({§matcher-refusal}). Before this, a refused regex (`/*url*/`, DeepSeek run429)
-reported `Nothing to repeat` with no way forward and the turn was spent.
+diagnostic names, in `recovery`, the form of the construct it refused, in the model's terms: a
+refused heading carries the operation's canonical line (`` `READ (path) <L,M>? pattern? <!-- aside -->?`
+on the opening fence line; READ takes no body. ``), a refused scope the scope's form, and a refused
+matcher its dialect's form with an example (`` A pattern is a regex written `/pattern/flags`, such
+as `/timeout/i`. ``). The working form is the language's, never a reconstruction of the input
+({§diagnostic-observation}). The runtime projects `recovery` as the Problem's `recovery` beside the
+verbatim `message`; an advisory carries none, since its statement ran. A refused matcher carries
+the same pair into its own operation's Problem ({§matcher-refusal}).
 
 §parser-position Parser source locations are points, not text regions. An AST
 statement's `position` identifies the first backtick of its header; a diagnostic
@@ -1870,15 +1867,9 @@ diagnostics are:
   `FIND (src/parser.ts) [{"pattern": "/\\bparse\\w+\\b/"}]`. `^` claims the regex
   dialect without slashes or flags: the whole text is the pattern, so
   `READ (notes.md) ^Decision:.*` selects lines beginning with `Decision:`.
-  `^` is deliberately absent from `plurnk.md`'s dialect table and belongs here instead
-  (#804). It is carried because `^` meaning "anchor" is among the
-  strongest instincts a model arrives with: it will write `^Decision:.*` whether or not it
-  was taught to, and the engine honours what it will reach for anyway. Teaching it would
-  spend hot-path weight on a line that changes no behaviour. The omission is therefore not
-  drift between the teaching and the engine, and closing it in either direction is a
-  regression: restoring the row pays for nothing, and retiring the prefix makes the
-  pretrained spelling a glob that matches a literal caret — silence in place of the
-  selection the model asked for.
+  `^` is deliberately absent from `plurnk.md`'s dialect table: a model writes the anchor
+  whether or not it is taught, so the engine honours it without spending hot-path teaching
+  on it. The omission is not drift between the teaching and the engine.
 - §trailing-slots **Slots after the matcher peel off the right.** The heading text after
   the matcher is read backwards: a trailing `<!-- aside -->`, a trailing `<scope>` in the
   shapes the lexer admits (result positions on FIND, text coordinates elsewhere) and a
@@ -1916,9 +1907,9 @@ diagnostics are:
 - §bare-target **A target written without its parentheses is refused with the line that runs.**
   A FIND, READ or EDIT heading with no target whose heading text opens with a word that is no
   matcher sigil, `READ a.py <1,4>`, cannot run: the word stands where the target goes, but on FIND it
-  could as well be a pattern. The statement is one hard diagnostic that writes the corrected line —
-  `` `READ` has no target: `a.py` stands where the target goes. Write the target in parentheses:
-  `READ (a.py) <1,4>`. `` A targetless KILL's heading text remains its inline deliverable.
+  could as well be a pattern. The statement is one hard diagnostic,
+  `` `READ` has no target: `a.py` stands where the target goes. ``, whose recovery is the operation's
+  working form ({§parse-recovery}). A targetless KILL's heading text remains its inline deliverable.
 - §bare-anchor-scope **An EDIT's anchor without its angle brackets is its scope.** On an EDIT
   heading, `@abcde` or `@abcde,@fghij` standing alone where the scope goes — nothing but an aside, a
   closer or the line end after it — is the scope `<@abcde>`, with one warning-severity advisory:
@@ -1927,9 +1918,9 @@ diagnostics are:
   marker (14 distinct recorded headings). On READ and KILL the same text stays a literal matcher,
   since `@patch` is a search a model means.
 - §matcher-body-redirect **Unread body text on bodyless operations.** FIND, READ and bodyless
-  KILL keep the statement but discard text the matcher did not consume, with one warning:
-  `READ takes no body; the body was ignored. A pattern belongs on the opening fence line
-  after the path.` KILL's advisory says `This KILL`, limiting the claim to that invocation:
+  KILL keep the statement but do not use text the matcher did not consume, with one warning
+  naming where it stands: `READ takes no body; lines 4–38 were not used.`, or `the text after its
+  heading on line 3` when it shares the heading's line. KILL's advisory says `This KILL`, limiting the claim to that invocation:
   parameterless completion and log distillation bodies remain valid. Delivered like
   {§misplaced-aside-advisory} as a `parse_advisory` notice (a warning, never an error).
   One sigil line beneath a bodyless heading is the bare form written a line low and still lifts;
@@ -1960,33 +1951,33 @@ diagnostics are:
   with any other content is ignored under the same advisory path
   ({§matcher-body-redirect}).
 
-§error-shape The diagnostic class determines how much guidance the parser may
-provide. Advisories belong to one successfully built statement. A rejected
+§error-shape The diagnostic class determines the parts of a message; every class says what
+happened, never why ({§diagnostic-observation}). Advisories belong to one successfully built statement. A rejected
 statement emits its hard diagnostic, not normalization advisories; neither a
 rejection nor an internal exception carries advisories into another statement
 or parser invocation.
 
-| Class                  | Surface               | Message contract                                                                          |
-|------------------------|-----------------------|-------------------------------------------------------------------------------------------|
-| Hard fact              | `severity: "error"`   | One concise observed fact and violated constraint in PLURNK vocabulary.                   |
-| Targeted hard redirect | `severity: "error"`   | One canonical correction only when parser state makes the intended structure unambiguous. |
-| Non-fatal advisory     | `severity: "warning"` | One narrowly gated likely mistake and canonical alternative; input remains admitted.      |
-| Boundary loss          | `unparsedTail`        | Where trust ends, which header slot remains open, and why later input is undefined.        |
+| Class         | Surface               | Message contract                                                                                                  |
+|---------------|-----------------------|-------------------------------------------------------------------------------------------------------------------|
+| Hard fact     | `severity: "error"`   | What was read, where, and the constraint it violates, in PLURNK vocabulary; `recovery` is the construct's working form ({§parse-recovery}). |
+| Advisory      | `severity: "warning"` | What was read and what was done with it, read as a named construct or not used, and where; the statement remains admitted. |
+| Boundary loss | `unparsedTail`        | Where trust ends and which header slot remains open; later input is undefined.                                   |
 
 All messages use PLURNK protocol vocabulary: opening fence, closing fence, target,
 scope, line marker, body, section boundary, or space between slots. They never
 expose ANTLR rule or token names. They refer to a slot or
-feature rather than an implementation rule. Generic tutoring, speculative
-intent, coordinate restatement, and multiple repair strategies are forbidden.
+feature rather than an implementation rule. Generic tutoring, coordinate
+restatement and multiple repair strategies are forbidden, and no message names an
+intent ({§diagnostic-observation}).
 Unexpected top-level text immediately after a closed operation identifies that
 operation's opening line, closing line, and matching backtick count.
 
 Examples of canonical hard facts:
 
 - `unrecognized character '<' in target`
-- `unexpected bracket modifier; the fence name selects the executor`
+- `unrecognized character '[' in the sh header`
 - `unrecognized character 'X' in statement header`
-- `WAIT's body begins below the header`
+- `unrecognized character '[' in the WAIT header`
 - `expected ')'; got ':'`
 
 Each malformed statement produces at most one hard error. The first recorded

package/dist/conformance/agui-v1.json

@@ -70,8 +70,11 @@
                                 "model": null,
                                 "loopId": null,
                                 "packetCount": 0,
+                                "waitUntil": null,
                                 "preparation": [],
-                                "activity": null
+                                "activity": null,
+                                "children": 0,
+                                "descendants": { "requests": 0, "usage": null, "knownUsage": null, "costUsd": null, "knownCostUsd": null }
                             }
                         },
                         "budget": {}

package/dist/schema/ClientInteractionProjection.json

@@ -4,13 +4,14 @@
     "title": "ClientInteractionProjection",
     "description": "The runtime-neutral client-interface projection of one pending client interaction. Live delivery and reconnect discovery expose this same shape.",
     "type": "object",
-    "required": ["interactionId", "workerId", "loopId", "turnId", "request"],
+    "required": ["interactionId", "workerId", "loopId", "turnId", "recipient", "request"],
     "additionalProperties": false,
     "properties": {
         "interactionId": { "type": "integer", "minimum": 1 },
         "workerId": { "type": "integer", "minimum": 1 },
         "loopId": { "type": "integer", "minimum": 1 },
         "turnId": { "type": "integer", "minimum": 1 },
+        "recipient": { "type": "string", "minLength": 1 },
         "request": { "$ref": "https://schemas.plurnk.xyz/v0/ClientInteractionRequest.json" }
     }
 }

package/dist/schema/Notice.json

@@ -15,7 +15,7 @@
         "kind": {
             "type": "string",
             "minLength": 1,
-            "description": "Open discriminator within a source. Examples include `grammar_unenforced`, `search_progress`, and `turn_awaiting_model`."
+            "description": "Open discriminator within a source. Examples include `output_unaccounted`, `search_progress`, and `turn_awaiting_model`."
         },
         "level": {
             "enum": ["error", "warn", "info"],

package/dist/schema/OperationResult.json

@@ -2,7 +2,7 @@
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "https://schemas.plurnk.xyz/v0/OperationResult.json",
     "title": "OperationResult",
-    "description": "Universal PLURNK operation result. Producer-owned metadata is open, but failures always carry one RFC 9457 Problem Details object and never a parallel error field.",
+    "description": "Universal PLURNK operation result. Producer-owned metadata is open, but failures always carry one RFC 9457 Problem Details object.",
     "type": "object",
     "required": ["status"],
     "additionalProperties": true,
@@ -17,8 +17,7 @@
         },
         "range": {
             "$ref": "https://schemas.plurnk.xyz/v0/RangeExtent.json"
-        },
-        "error": false
+        }
     },
     "oneOf": [
         {

package/dist/schema/ProposalDisposition.json

@@ -2,22 +2,21 @@
     "$schema": "https://json-schema.org/draft/2020-12/schema",
     "$id": "https://schemas.plurnk.xyz/v0/ProposalDisposition.json",
     "title": "ProposalDisposition",
-    "description": "The one core-owned settlement decision for a pending proposal. Client-owned proposals require an external resolution; loop-owned proposals carry the exact automatic resolution core applies.",
+    "description": "The one core-owned settlement decision. Review waits for the worker's owner; accept and reject carry the automatic resolution core applies.",
     "oneOf": [
         {
             "type": "object",
-            "required": ["owner"],
+            "required": ["decision"],
             "additionalProperties": false,
             "properties": {
-                "owner": { "const": "client" }
+                "decision": { "const": "review" }
             }
         },
         {
             "type": "object",
-            "required": ["owner", "decision"],
+            "required": ["decision"],
             "additionalProperties": false,
             "properties": {
-                "owner": { "const": "loop" },
                 "decision": { "enum": ["accept", "reject"] },
                 "outcome": { "type": "string", "minLength": 1 }
             }

package/dist/schema/ProposalPolicy.json

@@ -0,0 +1,7 @@
+{
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
+    "$id": "https://schemas.plurnk.xyz/v0/ProposalPolicy.json",
+    "title": "ProposalPolicy",
+    "description": "Server disposition for proposals. Review requires the worker's owner; accept and reject settle within core.",
+    "enum": ["review", "accept", "reject"]
+}

package/dist/schema/ProposalProjection.json

@@ -13,7 +13,7 @@
         "target",
         "body",
         "attrs",
-        "policy",
+        "owner",
         "disposition"
     ],
     "additionalProperties": false,
@@ -42,7 +42,7 @@
         },
         "body": { "type": "string" },
         "attrs": { "type": "object", "additionalProperties": true },
-        "policy": { "$ref": "https://schemas.plurnk.xyz/v0/LoopPolicy.json" },
+        "owner": { "type": "string", "minLength": 1 },
         "disposition": { "$ref": "https://schemas.plurnk.xyz/v0/ProposalDisposition.json" }
     }
 }