@plurnk/plurnk-contracts 1.29.0 → 3.0.0

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/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`         |
@@ -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 and unique client-tool names | 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                    |
@@ -167,15 +168,11 @@ workspace layer and their normalized intersection: `service`, `workspace`, and
 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.
+§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
+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 +311,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 +328,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}).
@@ -364,7 +362,9 @@ input at once by {§fence-pairing}:
 
 A whole-input pass, `FencePairing`, decides where every block ends before the lexer reads a
 token; the lexer's semantic predicates consult its decision, and ANTLR keeps framing, slots and
-statement composition ({§parser-architecture}). The pass is a least-cost parse of the fence
+statement composition ({§parser-architecture}). Heading shape comes from the same grammar and
+AST interpretation as normal admission, including recovered operand order and target notation;
+fence pairing does not infer slot ownership from raw text. The pass is a least-cost parse of the fence
 lines as a bracket language, in the manner of Aho and Peterson's least-errors parser
 (SIAM J. Comput. 1(4), 1972): every reading of the fences is a derivation, and the pass returns
 the cheapest.
@@ -409,7 +409,7 @@ repaired reading: a complete nested interpretation takes precedence. Each class
 | Counted | Complete readings | Repaired readings | Why |
 |---|---|---|---|
 | Hidden operations: a heading that will not run, written at its block's width or wider | 1, together with the next row | 1 | Every operation the author wrote should run |
-| Repairs: a supplied closer (except a message's run to the end of the input, {§message-run-on}), a fence read as a stray, a narrower closer accepted, a body under an operation that takes none (FIND, READ, COPY, MOVE, targeted KILL), a body not well-formed in the media type its runtime declares ({§executor-invocation}) | none by definition | 2 | The least-errors distance |
+| Repairs: a supplied closer (except a message's run to the end of the input, {§message-run-on}), a fence read as a stray, a narrower closer accepted, a body under an operation that takes none (FIND, READ, COPY, MOVE, non-log targeted KILL), a body not well-formed in the media type its runtime declares ({§executor-invocation}) | none by definition | 2 | The least-errors distance |
 | Literal by declaration: a heading narrower than its block, or no wider than the labeled block or example holding it, or inside a quotation or a KILL, or an executor heading inside a SEND, WORK, FORK or BARE body ({§prose-code-blocks}); a labeled fence in a body read as text | 1, together with the row above | 3 | Every code block the author declared should stand |
 | Supplied closers | 2 | 4 | A block the author opened should end at a fence the author wrote |
 | Other fences read as text | 3 | 5 | The least departure from the fences as written |
@@ -443,11 +443,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
@@ -458,8 +460,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
@@ -468,11 +470,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.**
 
@@ -654,9 +654,9 @@ normalize optional bodies to null. Closing fences are conventional, never requir
 ({§closer-fallback}).
 
 §statement-rendering `PlurnkParser.stringify` renders native OP names and named
-runtime fences from the shared AST, with one blank line between operations; a
-target group renders every member with its own scope and metadata, then the
-group's naked pattern ({§target-group}).
+runtime fences from the shared AST, with one blank line between operations. A
+target group compiles to ordinary statements, each rendered with its resolved
+selection ({§target-group}).
 Every closing fence occupies its own line, including bodyless operations;
 inline fences remain accepted input, not generated examples.
 It chooses at least three backticks and more than any run within the body
@@ -692,16 +692,24 @@ below the header.
 
 §target-group **READ and KILL take a target group.** A READ or KILL heading may carry several
 `(path)` slots, each binding the scope and metadata that follow it under {§slot-order}; a naked
-pattern on the heading ({§naked-pattern}) is the group's and applies to every member. The AST keeps
-the first slot in `target`, `lineMarker` and `metadata` and, only when the heading carries more than
-one slot, repeats it with the rest as `group: ResourceSelection[]` in authored order, each member's
-`matcher` the one its own metadata carried. The operation runs once per member, in authored order,
-under the core SPEC's {§safe-uri-target-groups}; a distilling body ({§log-kill-distillation}) lands
+pattern on the heading ({§naked-pattern}) supplies the default for each member without its own
+metadata `pattern`. The parser compiles the complete heading into one ordinary statement per
+member, in authored order, each with its own target, scope, metadata and resolved matcher. No
+duplicated first-member or group representation crosses the parser boundary. Every resulting
+statement retains the heading's source position and aside; a heading-level parse error refuses
+all its members, not valid sibling headings. A distilling body ({§log-kill-distillation}) lands
 once, with the first member. COPY and MOVE keep their two operands with their own meaning
 ({§transfer-resource-selections}); every other operation takes one slot, and a second slot on its
 heading is the slot-opener diagnostic. The form is accepted, not taught: it rescues a bulk attempt
 written one path per slot.
 
+§safe-uri-target-groups **An explicit URI list is a target group.** In READ and KILL only,
+one path slot may contain several explicit `scheme://` URIs separated by top-level commas or
+whitespace; braces protect their contents. Every member must independently parse as a URI,
+otherwise the target stays singular and exact. Local filenames containing spaces or commas
+are never split. Each URI inherits its slot's scope and metadata and compiles through
+{§target-group}; COPY/MOVE and other operations do not admit this tolerance.
+
 §scope-on-scopeless **A scope on an operation that takes none is dropped, and named.** WORK, FORK,
 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
@@ -715,21 +723,33 @@ dead; in the distinct recorded emissions one heading carried the form (zai run42
 ```` ```WORK (worker://deprecation-implementer) <1,-1> ````), beside two recipient SENDs whose scope
 the recipient refuses at runtime.
 
-§heading-inline-body Nonempty body text belongs below the fence header.
-The ingester tolerates body text after horizontal whitespace on the header,
-preserves it, and emits one warning stating that normalization. This does not
-change the meaning of a compact empty block or permit unmatched fences.
+§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,
+and that reading is named: no text on the line is dropped silently, and none loses the operation.
+Taken as the body, it is the first body line, with one warning: "`EDIT` body text was on the OP
+line and was taken as the body; body content goes immediately beneath the opening fence line." A
+sigil claims a matcher only on an operation that has one. This does not change the meaning of a
+compact empty block or permit unmatched fences.
+
+| Operation | Text after the slots on the heading line |
+|---|---|
+| FIND, READ, KILL with a non-log target | The matcher ({§naked-pattern}). Beside an option block's `pattern`, ignored ({§matcher-body-redirect}). |
+| KILL on a log target | The matcher. Beside an option block's `pattern`, the first line of the distillation ({§log-kill-distillation}). |
+| EDIT | A sigil-led matcher ({§edit-pattern}), unless an option block carries the `pattern`; otherwise the body. |
+| COPY, MOVE | Ignored ({§transfer-resource-selections}). |
+| SEND, WORK, FORK, BARE, executors | One JSON object is the option block where the heading admits one ({§bare-option-object}); otherwise the body. |
+| NOTE, WAIT, KILL without a target | The body. |
 
 §bare-option-object A bare option object is the option block, where the house option array owns the
 block. On an operation that takes an option block and no bare matcher — SEND, BARE, WORK, FORK and
-every executor fence — heading text after the slots that is exactly one JSON object `{…}` is read
+every executor fence — heading text after the slots that is exactly one JSON object `{…}`, where the
+heading admits a block (BARE, WORK and FORK only after their target), is read
 as `[{…}]`: the AST carries the array form, the written heading renders it, and one
 warning-severity receipt names the indulgence in place of the {§heading-inline-body} advisory:
 "`SEND` took a bare option object; the taught form is `[{…}]`." The option array is a house
 convention, not a language rule ({§scheme-metadata-modifier}): an executor whose declared body is
 JSON ({§executor-invocation}), an MCP tool, reads the object as its body instead — its arguments,
-written on the heading line — with one warning: "`gitea` took its body on the heading line; the
-body belongs on the lines below it." The host names those executors to the parse
+written on the heading line — under {§heading-inline-body}. The host names those executors to the parse
 (`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
@@ -788,7 +808,7 @@ still the aside under {§misplaced-aside-advisory}. EDIT keeps its literal body:
 with a matcher it is the replacement for every selected span ({§edit-pattern}),
 and an absent body deletes them. `PlurnkParser.stringify` writes a lifted matcher
 whose block left no metadata back bare when the bare form reads back identically
-({§naked-pattern}), otherwise as `[{"pattern": "…"}]`.
+and draws no advisory ({§naked-pattern}), otherwise as `[{"pattern": "…"}]`.
 
 ## 3. Lexical elements
 
@@ -892,8 +912,8 @@ disposition.
 anchored (```` ```KILL (log:///**/READ) <17,-1>``` ```` or
 ```` ```KILL (worker:///notes.md) <@aB3dE,@0Aa9Z>``` ````), and an optional matcher option that
 selects rows or lines (```` ```KILL (log:///**) [{"pattern": "~stale"}]``` ````, {§matcher-option}).
-The AST is `{ op: "KILL", target, lineMarker: TextLineMarker | null, matcher: MatcherBody | null, body: string | null }`,
-with `group` beside them when the heading carries more than one slot ({§target-group}).
+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
 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
@@ -985,8 +1005,10 @@ Mutation semantics:
 - `<SL,SC,EL,EC>` deletes the exact exclusive-end region and inserts the body at its start.
 - §transfer-resource-selections COPY and MOVE require two singular
   `ResourceSelection` operands, source first and destination second, and admit
-  no body. Each selection binds its own target, scope, matcher, and metadata
-  under {§slot-order}, {§matcher-option}, and {§scheme-metadata-modifier}.
+  no body: text after the slots on the heading line, or beneath it, is ignored and the
+  operation still runs, with one warning-severity advisory (`MOVE takes no body; the body
+  was ignored.`). Each selection binds its own target, scope, matcher, and metadata under
+  {§slot-order}, {§matcher-option}, and {§scheme-metadata-modifier}.
 
 ### Per-operation observations
 
@@ -1112,7 +1134,8 @@ refusal ({§matcher-refusal}), not a parse error.
   operation, two for COPY and MOVE, any number on READ and KILL ({§target-group}) — is a parser
   error at its opening paren. Report the unexpected slot and the grammar's expected
   alternatives when available, without inferring pattern intent or imposing another
-  operation's operand count. The statement is dropped and its siblings run.
+  operation's operand count. Recovery-only body text is not advertised as a valid body
+  for an operation that takes none. The statement is dropped and its siblings run.
 
 | Prefix    | Dialect  | Canonical form                       | Typed admission                   | Runtime owner       |
 |-----------|----------|--------------------------------------|-----------------------------------|---------------------|
@@ -1274,7 +1297,7 @@ 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
+the human uses the native `question` executor tool when enabled ({§question-tool}), not a
 disposition. The shape rules ARE structural:
 
 - §send-mid-reservation WAIT is reserved ({§turn-disposition}).
@@ -1286,6 +1309,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});
@@ -1356,18 +1381,15 @@ tiers ignore outside text. Core alone owns storing it as the turn's outside sour
 and no-operation strikes ({§empty-turn}); parsing never infers delivery or completion
 intent.
 
-§unfenced-operation **An operation written without its fence did not run, and the parser says
-so.** An outside-text line that opens at column zero with an operation's name and anything else
-— `KILL The answer…`, `READ (a.md)`, `KILL (notes.md)` — draws one warning: `` `KILL` has no
-fence, so it did not run. `` The line is not response text ({§response-text}): it is neither stored
-as outside text nor echoed into the next packet, and the exact emission remains at `ops://`; a name
-with only an optional complete aside opens the operation instead ({§naked-operation}). A registered executor's name followed by an
-operand slot — `gitea (list_issues)`, `sh(build.sh)` — draws the same warning under the executor's
-own spelling; quoted blocks, offset lines and names inside a sentence draw nothing, since `sh`,
-`env` and `members` are ordinary words. The model that wrote it believes it ran: stored as
-outside text ({§outside-text}), an unfenced KILL would sit in the record as an answer never given,
-and only the warning tells the model otherwise. The warning and the exclusion together keep the
-line out of the record.
+§unfenced-operation **The parser identifies ignored unfenced fragments.** An outside-text line
+that opens at column zero with an operation's name and anything else — `KILL The answer…`,
+`READ (a.md)`, `KILL (notes.md)` — draws one warning: `` Unfenced `KILL` ignored. ``
+This describes only that fragment, never a fenced operation elsewhere in the turn or its reasoning.
+The line is not response text ({§response-text}): it is neither stored as outside text nor echoed
+into the next packet, and the exact emission remains at `ops://`. A name with only an optional
+complete aside opens the operation instead ({§naked-operation}). A registered executor's name
+followed by an operand slot — `gitea (list_issues)`, `sh(build.sh)` — draws the same warning under
+the executor's own spelling. Quoted blocks, offset lines and names inside a sentence draw nothing.
 
 §recorded-emissions **The parser is regressed against emissions models actually produced,
 not fixtures we wrote.** `test/fixtures/recorded-emissions.jsonl` holds one real exemplar
@@ -1437,7 +1459,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}                        |
 
@@ -1620,8 +1642,8 @@ discriminated values:
 | `mimetype` | Non-empty `mimetype` media type | `CapabilityDisplay` |
 
 `CapabilityDisplay` is a closed object whose optional `glyph` is a non-empty,
-opaque string. Capability frameworks own and validate their intrinsic
-declarations; Core owns composition of the installed families; interface
+opaque string. Frameworks own and validate their intrinsic
+declarations; Core owns composition of the installed extensions; interface
 modules expose this exact shape; clients own rendering, font support, theme,
 and identity fallback when `glyph` is absent. Empty framework sentinels are
 normalized to absence at composition. Display metadata is client state, never
@@ -1865,7 +1887,9 @@ diagnostics are:
   until what remains is the matcher. `READ (a.rs) /fn resolve_/ <1,-1> <!-- entities -->`
   is the same operation as `READ (a.rs) <1,-1> /fn resolve_/ <!-- entities -->`, with
   one warning-severity advisory naming the canonical order for the scope or block:
-  the grammar swallows up anything that passes as legitimate plurnk. A matcher that
+  recovery requires a single possible path-slot owner. With multiple slots, a trailing scope
+  or metadata block refuses the heading rather than relocating or discarding the slot.
+  A matcher that
   itself ends in one of those shapes takes the option escape.
   `plurnk.md` teaches one order — `OP (path)? <scope|range>? [metadata]? pattern?
   <!-- aside -->?` — and free ordering is not taught. Small departure, small
@@ -1902,15 +1926,15 @@ diagnostics are:
   body instead, the anchor would be written into the file, or the EDIT refused for want of a line
   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 **A body beneath those headings.** Text below the heading
-  of a FIND, READ or targeted KILL is a body, and those operations take none: the builder
-  keeps the statement without it and raises one warning-severity advisory (`READ
-  takes no body; the body was ignored. A pattern belongs on the opening fence line
-  after the path.`). KILL's advisory names `KILL with a target`; it must not
-  prohibit parameterless completion bodies. Delivered like {§misplaced-aside-advisory} as a
-  `parse_advisory` notice (a warning, never an error). One sigil line beneath the heading is the bare form
-  written a line low and still lifts; nothing else is promoted into a matcher from
-  below the heading, and the advisory never echoes the body.
+- §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
+  {§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`
+  prevents that lift, and the advisory never echoes the discarded text.
 - §combined-anchor-tolerance **Combined line number and anchor in a scope.** A
   text-coordinate scope written `L<@hash>` — digits immediately before the opener — is the
   displayed `42<@abcde>` row prefix copied whole: the scope is the anchor, the number is dropped, and one

package/dist/schema/ApplicationOperationEvent.json

@@ -11,7 +11,7 @@
         "loopId": { "type": "integer", "minimum": 1 },
         "turnId": { "type": "integer", "minimum": 1 },
         "sequence": { "type": "integer", "minimum": 1 },
-        "origin": { "enum": ["model", "client", "_plurnk", "plugin"] },
+        "origin": { "enum": ["model", "client", "_plurnk"] },
         "projectRoot": { "type": ["string", "null"] },
         "statement": { "$ref": "https://schemas.plurnk.xyz/v0/PlurnkStatement.json" },
         "phase": { "enum": ["started", "settled"] },

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/PlurnkStatement.json

@@ -186,14 +186,6 @@
                 "target": {
                     "$ref": "#/$defs/PathOrNull"
                 },
-                "group": {
-                    "type": "array",
-                    "minItems": 2,
-                    "items": {
-                        "$ref": "https://schemas.plurnk.xyz/v0/ResourceSelection.json"
-                    },
-                    "description": "The heading's target group ({§target-group}): every `(path)` slot with the scope and metadata that follow it, in authored order, the first repeating `target`, `lineMarker` and `metadata`. Present only when the heading carries more than one slot; absent, as in every statement stored before groups existed, the operation has its one target."
-                },
                 "lineMarker": {
                     "$ref": "#/$defs/TextLineMarkerOrNull"
                 },
@@ -454,14 +446,6 @@
                 "target": {
                     "$ref": "#/$defs/PathOrNull"
                 },
-                "group": {
-                    "type": "array",
-                    "minItems": 2,
-                    "items": {
-                        "$ref": "https://schemas.plurnk.xyz/v0/ResourceSelection.json"
-                    },
-                    "description": "The heading's target group ({§target-group}): every `(path)` slot with the scope and metadata that follow it, in authored order, the first repeating `target`, `lineMarker` and `metadata`. Present only when the heading carries more than one slot; absent, as in every statement stored before groups existed, the operation has its one target."
-                },
                 "lineMarker": {
                     "$ref": "#/$defs/TextLineMarkerOrNull",
                     "description": "Scope of the kill: lines of a log body or of an entry ({§kill-scope}); null kills the whole target."

package/dist/schema/ProblemDetails.json

@@ -31,7 +31,7 @@
         "instance": {
             "type": "string",
             "pattern": "^[a-zA-Z][a-zA-Z0-9+.-]*:",
-            "description": "Absolute URI identifying the failed durable operation, normally its log URI. Core adds it at persistence when a plugin cannot know the durable coordinate."
+            "description": "Absolute URI identifying the failed durable operation, normally its log URI. Core adds it at persistence when an extension cannot know the durable coordinate."
         },
         "stage": {
             "type": "string",

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" }
     }
 }

package/dist/schema/WorkerOwner.json

@@ -0,0 +1,17 @@
+{
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
+    "$id": "https://schemas.plurnk.xyz/v0/WorkerOwner.json",
+    "title": "WorkerOwner",
+    "description": "A workspace-scoped approval owner and the client tools it implements. Capabilities persist while disconnected; a message never changes ownership.",
+    "type": "object",
+    "required": ["address", "tools"],
+    "additionalProperties": false,
+    "properties": {
+        "address": { "type": "string", "minLength": 1 },
+        "tools": {
+            "type": "array",
+            "uniqueItems": true,
+            "items": { "type": "string", "minLength": 1 }
+        }
+    }
+}