@plurnk/plurnk-contracts 3.0.0 → 3.1.0

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

@@ -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,7 +137,7 @@ 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 |
-| `WorkerOwner` | Nonempty address and unique client-tool names | Persist by workspace; inherit through worker creation |
+| `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 |
@@ -164,13 +164,16 @@ 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.
+`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 and the client-tool
-names that recipient implements. Neither contains resource permissions or
+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.
 
@@ -311,15 +314,14 @@ 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, except
-parameterless KILL always takes the remaining answer region ({§terminal-kill}). A fence inside
+again, to the next heading ({§fence-heading-in-body}), or to the end of the turn. 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
+back ({§closer-fallback}). One warning-severity receipt follows a recovered statement —
+`` `NOTE` opened with no fence; the taught form is three backticks. `` One rule for every native
 operation: a naked `WAIT` parks, a naked `NOTE` takes its text, a naked `READ` meets the ordinary
 missing-target refusal. A closer the author wrote anyway is still not body: when the body's last line is
 a bare backtick fence that no other fence line in the body pairs with (an odd count of fence lines), that
-line is the block's closer and leaves the body, so `KILL`, then the answer, then a closing fence delivers
+line is the block's closer and leaves the body, so `SEND`, then the answer, then a closing fence delivers
 the answer alone. An aside-bearing name inside a body is not a closer. An incomplete or repeated
 aside, an operand, or other heading text does not qualify and remains the unfenced form
 ({§unfenced-operation}). Executors are runtimes rather than operations, and reasoning is never
@@ -329,10 +331,9 @@ read this way.
 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. {§fence-pairing} chooses between
-the two; parameterless KILL always holds the remaining input ({§terminal-kill}). Fence lines of
+the two. 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}).
+plus what the host names in `ParseOptions.executors`.
 
 §closer-fallback A block that ends at a heading or at the end of the input has no closer of its
 own; its body is the whole span less one terminating line ending. Where a same-character fence
@@ -443,17 +444,9 @@ 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 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
-text shows, exactly as under {§terminal-kill}: it never ends the block and never runs. A native
+text shows: it never ends the block and never runs. A native
 operation's heading still ends such a block, since a message is often followed by the author's next
 operation. In the distinct recorded benchmark emissions an executor heading ended an unclosed
 `WORK` body 14 times, a `BARE` body 9 times and a `SEND` body twice; every one inspected (qflash
@@ -470,10 +463,6 @@ 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 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.**
 
 | Witness | Result |
@@ -558,9 +547,8 @@ opening fence, OP, parameters, and aside share one line. `` Saying that it ran k
 issuing it again. Inside a body the same lines stay literal. Measured: of 2,308 naked fences in
 12,797 recorded emissions, 51 open that way and 2,238 hold code or quoted output, which is why a
 bare fence alone draws nothing; in the 10,486-emission fence corpus every one of the 12 that open
-that way was an operation the model meant to run. With the answer carried by the final KILL,
-whose body shows and never runs ({§terminal-kill}), an example the model means only to show lives
-in a body.
+that way was an operation the model meant to run. An example the model means only to show
+belongs in a properly nested body ({§balanced-fences}) or a quotation ({§quotation}).
 So a model may show plurnk's own operations in an answer. Two exceptions keep programs whole:
 CommonMark's own rule that a backtick opener's line carries no further backtick, so
 ```` ```READ (x)``` ```` is inline code and quotes nothing after it; and a bare fence directly under
@@ -679,12 +667,12 @@ beside owner metadata, not only a matcher carried inside its `pattern` option.
 by one ASCII space. Target and scope form one resource selection; COPY/MOVE
 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.
+changing ownership or making them distinct canonical forms. Metadata may also
+precede the first target, belonging to that first selection. Between targets it
+belongs to the preceding selection, never the following one. Single-target
+scope-first tolerance remains valid with metadata before or after that scope.
+Each selection has at most one scope; its metadata blocks retain their authored order. A second scope
+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
@@ -714,14 +702,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,
@@ -753,9 +738,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
@@ -764,7 +748,7 @@ routing, timing, or body input. Comments inside a body remain literal except
 for the narrowly owned {§misplaced-aside-advisory}.
 
 §scheme-metadata-modifier A target may carry one single-line `[metadata]`
-block after its scope; executor and SEND fences also admit it without a target.
+block, placed under {§slot-order}; executor and SEND fences also admit it without a target.
 The block belongs to the selected scheme or executor, which owns its shape,
 interpretation, validation and authority. The language assigns no meaning to
 the content and stores each block's exact inner text: balanced brackets inside
@@ -777,7 +761,9 @@ or multiline metadata loses its boundary.
 **House policy, not a language rule:** every first-party scheme and executor
 reads its block through the shared `MetadataOptions` reader, which takes the
 block with its brackets as a JSON array of option objects, merged left to
-right with later keys winning. A third-party owner may read its block any way
+right with later keys winning. Reply SEND additionally owns a numeric completion
+element ({§message-completion}); WAIT owns its numeric duration ({§send-wait-scope}).
+A third-party owner may read its block any way
 it likes — the language guarantees only the exact inner text. Documentation
 for a first-party owner therefore shows the bracketed array form.
 
@@ -788,8 +774,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
@@ -798,10 +784,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:
@@ -838,10 +823,10 @@ governed by {§canonical-statement}; runtime conditions remain explicit below.
 | BARE | optional prompt resource                     | none                            | prompt; optional with a path   |
 | WORK | optional fresh `worker://name`, or a prompt resource ({§worker-spawn-prompt-resource}) | none | prompt; optional with a resource |
 | FORK | optional context-inheriting `worker://name`, or a prompt resource | none            | prompt; optional with a resource |
-| KILL | optional target; absent requests loop completion | optional text region on a target ({§kill-scope}) | literal final answer when parameterless; the distillation of what a `log:///` target retires ({§kill-scope}); none for other targets |
+| KILL | required target | optional text region on a target ({§kill-scope}) | the distillation of what a `log:///` target retires ({§kill-scope}); none for other targets |
 | SEND | optional recipient | recipient-defined; none for workers ({§send-directed-scope}) | message |
 | NOTE | none | none | literal working memory |
-| WAIT | optional label ({§send-wait-scope}) | non-negative seconds | explanation of the wait |
+| WAIT | optional label ({§send-wait-scope}) | none; duration is `[seconds]` metadata | explanation of the wait |
 
 §note-value NOTE retains its literal body as ordinary model-owned working memory.
 It has no target, scope, metadata, or lifecycle effect. Its full body participates
@@ -851,10 +836,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
@@ -883,19 +868,18 @@ The path names a program or tool and is never split. Metadata such as
 
 §turn-disposition WAIT requests parking; its literal body does not control
 scheduling, and its optional target is the label the row keeps, never a join;
-the AST has no independently settable lifecycle status or metadata.
+the AST retains the normalized metadata duration as `seconds`, separate from text coordinates.
 A turn admits any number of WAITs, all deferred until its other operations
 settle and together one park. End-of-program adjudication owns continuation, joining and completion
-under {§wait-obligation-matrix}. Parameterless KILL requests successful completion
-under {§kill-conclusion}; its optional body is the literal final answer.
-SEND delivers messages and NOTE retains memory, neither declaring an outcome.
+under {§wait-obligation-matrix}. SEND carries optional message-completion metadata
+under {§message-completion}. KILL requires a target; NOTE retains memory.
 
-§send-wait-scope WAIT's optional `<seconds>` is a non-negative finite scalar bounding
+§send-wait-scope WAIT's optional `[seconds]` metadata is a non-negative finite scalar bounding
 this park, not the lifetime of its work. Without it, the service supplies its
 configured bound ({§worker-wait-timing}). Repeated duration slots select the
 smallest valid scalar. Zero continues without parking or a diagnostic. Invalid
-duration scopes are ignored with a terse warning; when none is valid, the configured
-bound applies. Metadata remains ignored without diagnostics.
+duration metadata is ignored with a terse warning; when none is valid, the configured
+bound applies. A text scope cannot supply a duration and receives the same warning.
 The optional target is a label, never a selected wake source;
 the body is the wait's explanation. Neither creates a schedule or restricts ordinary
 wake events. Ordinary malformed-header rules still apply. Multiple WAITs request
@@ -903,8 +887,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.
 
@@ -914,7 +897,7 @@ anchored (```` ```KILL (log:///**/READ) <17,-1>``` ```` or
 selects rows or lines (```` ```KILL (log:///**) [{"pattern": "~stale"}]``` ````, {§matcher-option}).
 Each operand becomes an ordinary KILL statement with its own `target`, `lineMarker` and
 `matcher`; no grouped AST reaches execution ({§target-group}).
-The body is retained on parameterless KILL ({§kill-conclusion}) and on a `log:///` target, where
+KILL requires a target. Its body is retained on a `log:///` target, where
 it is the model's distillation of what the KILL retires and lands as its own NOTE row
 ({§log-kill-distillation}); every other targeted KILL has `body: null`, and a body beneath one
 draws the advisory ({§matcher-body-redirect}). Beneath a `log:///` KILL the body is never read as
@@ -923,12 +906,10 @@ 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 is metadata before or after the target, with ownership under {§slot-order};
+its position does not select an executor or change its interpretation.
 
 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,
@@ -985,7 +966,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
@@ -1203,7 +1184,7 @@ The operation column names the canonical AST operation after
 | COPY/MOVE destination | 0/1/2/4 text coordinates after target  | Region replaced or insertion point at the destination                      |
 | KILL                  | 0/1/2 text coordinates                 | Whole target when absent; one physical line or inclusive range when present ({§kill-scope}) |
 | execution             | None                                   | Lifetime uses metadata; observation cadence belongs to the daemon ({§exec-lifetime}) |
-| WAIT                  | Non-negative seconds                   | Maximum park duration ({§send-wait-scope}) |
+| WAIT                  | None                                   | Maximum park duration uses metadata ({§send-wait-scope}) |
 | Directed SEND         | Owner-defined numeric scope           | Carried to the addressed owner; worker actors refuse it ({§send-directed-scope}) |
 
 Text coordinates use the algebra in {§text-scope-semantics}: one integer is a
@@ -1278,27 +1259,26 @@ rule protects code examples in SEND, WORK, FORK, BARE and every other body.
 
 ## 9. Turn dispositions
 
-The runtime adjudicates a nonempty admitted program against actual messages,
+The runtime adjudicates each admitted turn against actual message resolutions,
 results and live obligations ({§wait-obligation-matrix}). A response with no
-operation receives empty-turn recovery, not successful completion ({§empty-turn}).
+operation resolves no message and creates no new observation obligation ({§empty-turn}).
 
 | Intent | Nominal status | Meaning |
 |---|---|---|
 | Unobserved messages or results | 102 | Continue silently |
-| No authored response operations or fresh operation/parser failure, without WAIT | 102 | Recover before automatic parking |
-| WAIT | 202 | Park when a live obligation exists; otherwise continue at 102 |
-| Eligible parameterless KILL ({§kill-conclusion}), live work remains, no fresh failure | 202 | Join the held work without delivering its body |
-| Eligible parameterless KILL, messages and results observed, no held work | 200 | Conclude under {§kill-conclusion}; deliver a nonempty body, or finish silently without inventing or repeating a reply |
-| Other admitted program | 102 | Continue regardless of earlier replies or live work |
+| No operations while messages remain unresolved, or fresh operation/parser failure, without WAIT | 102 | Recover before automatic parking |
+| WAIT with live obligations | 202 | Park with the supplied or configured duration |
+| Resolved messages, observed results, live work remains | 202 | Join the held work; replies remain delivered |
+| Resolved messages, observed results, no held work | 200 or 499 | Settle under {§loop-completion}, retaining the aggregate message outcome |
 | KILL own worker | 499 | Cancel unfinished work in that worker and its descendants |
 | Runtime or infrastructure failure | 5xx | Not a model-authored task status |
 
 ### The terminal contract (waitpid)
 
-The model may supply WAIT or request completion with parameterless KILL. The host, not the grammar, owns
+The model may supply WAIT or complete message obligations with SEND metadata. The host, not the grammar, owns
 turn boundaries and adjudicates the loop's actual obligations. Asking
-the human uses the native `question` executor tool when enabled ({§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
@@ -1309,19 +1289,17 @@ 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});
+  child. With none, it does not park. Its optional duration bounds parking ({§send-wait-scope});
   a future message is scheduled through the schedule family.
 - §lifecycle-only-turn A WAIT-, SEND-, NOTE-, or KILL-only turn is valid.
   NOTE does not request parking or acknowledge messages.
   Ordinary repetition, strike and execution limits still apply.
 
-SEND with no `(path)` answers the open messages. SEND with `(path)` directs the
-message to that recipient. Neither form concludes the loop. Only parameterless KILL
-requests completion under {§kill-conclusion}; dispatch still executes the whole program.
+SEND with no `(path)` replies to open messages. SEND with `(path)` directs the
+message to that recipient. Completion metadata resolves message obligations
+({§message-completion}); dispatch still executes the whole program.
 
 ### §send-body SEND body projection
 
@@ -1394,7 +1372,7 @@ the executor's own spelling. Quoted blocks, offset lines and names inside a sent
 §recorded-emissions **The parser is regressed against emissions models actually produced,
 not fixtures we wrote.** `test/fixtures/recorded-emissions.jsonl` holds one real exemplar
 of every distinct parse shape observed across the live and demo drills — the operations
-authored, whether outside text appeared, how many parameterless KILLs appeared, and
+authored, whether outside text appeared, and
 the status the engine recorded at the time. A fixture encodes what we believe a model
 emits; a recording encodes what one did, so only recordings test the shapes models actually
 produce (#802, #809).
@@ -1562,12 +1540,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 +1570,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
@@ -1630,6 +1615,12 @@ complete RFC 9457 object.
 failure truth, lifecycle, scheduling, or recovery. Sharing a renderer with
 Problems does not merge their semantics.
 
+§notice-directive A Notice's `message` states what happened ({§diagnostic-observation}).
+When the observation concerns the model's own output, the producer may attach one
+`directive`: `YOU MUST`, `YOU MUST NOT`, `YOU MUST ONLY`, `YOU SHOULD` or
+`YOU SHOULD NOT`, then the rule. An observation of the environment carries none.
+Clients display the message; the model packet leads with the directive.
+
 ### §client-display-capabilities 13.7 Client display capabilities
 
 `ClientDisplayCapabilities` is the transport-neutral installed-capability
@@ -1760,21 +1751,25 @@ class PlurnkParseError extends Error {
     readonly source: ErrorSource;
     readonly severity: Severity;
     readonly recovery: string | undefined;
+    readonly operationOmitted: boolean;
 }
 ```
 
+§parse-admission **A diagnostic's severity does not describe whether an operation ran.**
+`operationOmitted` identifies unexecuted unfenced operations, unknown operation-shaped
+tags and unrecovered native calls. A warning about a retained operation or a quoted
+example does not set it. This fact survives serialization when true; consumers do
+not infer it from diagnostic wording. It does not independently prescribe a strike.
+
 §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. 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
@@ -1837,9 +1832,8 @@ diagnostics are:
   refusal ({§matcher-refusal}).
 - §regex-sed-range **A sed line range is named as one.** A regex matcher written as a sed
   address range — `/a/,/b/` or `/a/,+N` — is refused ({§matcher-refusal}) as a range, never as invalid flags: the
-  diagnostic says a matcher selects only the lines it matches, gives the one regex that
-  locates the ends (`/a|b/`, or `/a/`) and the scope that then addresses the span
-  (`<first,last>`, or `<N,M>` with M being N plus the range's count).
+  diagnostic names the range suffix and gives the regex matcher's working form.
+  It does not synthesize a different selector or a workflow ({§diagnostic-observation}).
 - §unclosed-regex **A regex that never closes.** A `/pattern` matcher with no closing
   `/` is read as the whole pattern with no flags, with one warning-severity advisory
   naming the closing slash and the flag position. The reading is deterministic because
@@ -1870,15 +1864,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 +1904,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}).
 - §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,10 +1915,10 @@ 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:
-  parameterless completion and log distillation bodies remain valid. Delivered like
+  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:
+  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;
   nothing else is promoted into a matcher from below the heading. An option block's `pattern`
@@ -1960,33 +1948,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