@plurnk/plurnk-contracts 1.16.5 → 1.18.0

package/SPEC.md

@@ -3,7 +3,7 @@
 ## 1. Overview
 
 §contract-authority This package is the single authority for PLURNK's language, schemas, generated
-types, parser, model rail, and runtime-neutral wire envelopes. Its package root
+types, parser, and runtime-neutral wire envelopes. Its package root
 is the single code API for those contracts.
 
 | Surface                                                                         | Canonical export or artifact                        |
@@ -23,12 +23,12 @@ is the single code API for those contracts.
 | AG-UI discovery, client accounting, and shared conformance specimens           | `AguiDiscovery`, `AguiClientConformance`, `AguiConformanceKit` |
 | JSON Schemas                                                                    | `@plurnk/plurnk-contracts/schema/*.json`            |
 | Generated JSON result rendering                                                 | `renderJsonResult`                                  |
-| Local-model rails                                                               | `@plurnk/plurnk-contracts/plurnk.{gemma,qwen}.gbnf` |
 | Model language reference                                                        | `plurnk.md` in the package                          |
 
 §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; GBNF remains the bounded generation aid described in §1.2.
+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.
 
 §agui-discovery-contract `AguiDiscovery` is the complete installed AG-UI+
 surface at one instant. `schemaVersion` identifies its discovery shape;
@@ -46,6 +46,10 @@ not satisfy the advertised `inputSchema`, rejects an owner's successful output
 when it does not satisfy `outputSchema`, and validates a known notification
 before projecting it to AG-UI. Schemas are discovery values owned by their
 registrants; validation must not annotate or otherwise mutate them.
+Input Problems retain the structured validation `issues` and name the failing
+instance locations and constraints in `detail`. Parent aggregate errors are
+omitted from that prose when their specific child errors are available; input
+objects are never echoed wholesale or interpreted as intent.
 
 §agui-client-conformance `AguiClientConformance` is a language-neutral JSON
 document accounting for every action and notification in one
@@ -69,30 +73,37 @@ a third protocol implementation: each client feeds the same chunks and events
 through its production parser and projection seam, then verifies the declared
 outcome. Specimen names are unique within their transport or lifecycle family.
 
-§json-result-rendering `renderJsonResult` is the one presentation serializer
-for generated JSON operation results. A top-level array remains one valid,
+§json-result-rendering `renderJsonResult` renders compact aggregate operation
+rows. A top-level array remains one valid,
 compact JSON value but places each item on its own physical line by adding only
 item-boundary newlines; an empty or single-item array and every non-array value
 remain one line. It never rewrites arbitrary stored JSON, whose original lines
 remain source coordinates.
 
+§json-document-presentation Generated JSON documents use two-space indentation.
+Normalized remote JSON text uses `formatJsonDocument`: whitespace-only formatting
+of a complete, strict JSON document, preserving key order, duplicate keys, number
+lexemes, and string escapes. Invalid or incomplete input is declined, not repaired.
+Apply formatting at the representation owner before storage, indexing, scoping,
+and previews; never reformat literal resources, JSONL framing, or wire/evidence
+serialization. Compact aggregate rows ({§json-result-rendering}) and packet
+metadata retain their deliberate layouts.
+
 ## §contract-layers 1.1 Contract layers and admission boundary
 
 PLURNK uses one contract with deliberately different projections. A tolerant
 ingester accepting a spelling does not make that spelling canonical model
-teaching, and a generation rail admitting a sentence does not make its runtime
-semantics valid.
+teaching, and an operator's sampling grammar admitting a sentence does not
+make its runtime semantics valid.
 
 ```mermaid
 flowchart LR
     canon["Canonical model teaching<br/>plurnk.md"]
-    rail["Optional raw generation rail<br/>Gemma or Qwen template profile"]
     free["Other admitted input"]
     syntax["ANTLR lexer + parser<br/>syntax and document tier"]
     ast["AstBuilder<br/>typed, serializable AST"]
     runtime["Runtime owners<br/>stateful semantics and effects"]
-    canon --> rail
-    rail --> syntax
+    canon --> syntax
     canon --> free
     free --> syntax
     syntax --> ast
@@ -103,20 +114,19 @@ flowchart LR
 |--------------------------|-------------------------------------|---------------------------------------------------------------------------------|
 | Stable current law       | `SPEC.md`                           | Owns invariants and boundaries; forge issues retain history                     |
 | Canonical model teaching | `plurnk.md`                         | Teaches the lean spelling and operational model the model should emit           |
-| Constrained generation   | generated `plurnk.*.gbnf`           | Increases likely ANTLR compliance without reproducing all parser/runtime checks |
-| Accepted syntax          | `plurnkLexer.g4`, `plurnkParser.g4` | Recognizes document tiers, heading lanes, slot shape, and section boundaries    |
+| Accepted syntax          | `plurnkLexer.g4`, `plurnkParser.g4` | Recognizes document tiers, operation fences, slot shape, and section boundaries    |
 | Typed admission          | `AstBuilder`                        | Produces JSON-serializable unions and validates deterministic body/path syntax  |
 | Shared wire data         | `schema/*.json`                     | Defines runtime-neutral data shapes projected into generated TypeScript         |
 | Stateful behavior        | consuming runtime                   | Resolves addresses, permissions, selection arithmetic, effects, and lifecycle   |
 
-ANTLR owns statement structure, delimiter matching, slot multiplicity, accepted
+ANTLR owns statement structure, fence matching, slot multiplicity, accepted
 slot permutations, scope-number syntax, and interstatement text recognition.
 AstBuilder owns URL decomposition and deterministic matcher validation through
 WHATWG `URL`, ECMAScript `RegExp`, XPath 1.0, and RFC 9535 JSONPath parsers.
 
 The runtime owner decides facts that require state or operation-specific
 meaning, including registered scheme resolution, target existence, tag
-selection, text-region bounds, result ordering, semantic similarity, mutation
+selection, text-region bounds, result ordering, full-text ranking, mutation
 effects, executor behavior, and numeric operation-code semantics.
 
 ### §contract-proposal-projection Loop policy and stopped-world projection
@@ -126,9 +136,9 @@ The schemas own the runtime-neutral shapes; core owns their stateful values.
 | Contract                  | Shape invariant                                                                 | Runtime responsibility                                                                 |
 | ------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
 | `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, workspace, Worker, and loop layers |
-| `CapabilityProjection`    | Exact service, workspace, immutable Worker bound, mutable Worker, and normalized effective policies | Expose the resolver's Worker-level cascade to clients without claiming one layer is effective authority |
-| `LoopPolicy`              | Complete capability attenuation plus one `review`, `accept`, or `reject` proposal disposition | Snapshot once when the loop is created |
+| `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 |
 | `ProviderUsage`           | Conventional input/output totals with cache and reasoning details                | Preserve observed quantities without replacing absence with zero                        |
@@ -144,25 +154,24 @@ least one selector must match. An empty policy admits everything and an empty
 
 §capability-policy-cascade Capability layers are purely subtractive and
 order-independent: a descriptor is admitted only when every layer admits it.
-No Worker or loop can restore service, workspace, or parent authority. A
+Workspace policy cannot restore authority denied by the service. A
 composed operation is admitted only when every routed demand survives. These
 descriptors govern routed external authority, not every grammar statement:
-log/program control such as PLAN, log KILL, and label or targetless SEND
-creates no capability demand. A known interactive runtime is represented by
+log/program control such as log KILL, the native dispositions, and
+targetless SEND creates no capability demand. A known interactive runtime is represented by
 access class `interact`; scheme and runtime manifests contribute traits rather
 than hidden policy behavior.
 
 §capability-policy-projection A `CapabilityProjection` reports every durable
-Worker-level layer and their normalized intersection. The `worker` field is the
-only client-mutable layer; `effective` is the authority a new unattenuated loop
-would receive. A client never derives effective authority from the mutable
-layer alone. Per-loop attenuation remains an immutable input to that loop and
-is therefore absent from this durable Worker projection.
+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 `DEFAULT_CAPABILITY_POLICY` and `DEFAULT_LOOP_POLICY` are the
 contracts-owned complete defaults. A loop policy is immutable after creation;
-its `capabilities` field only narrows broader authority and its `proposals`
-field chooses one unambiguous downstream settlement posture. Capability
+its `proposals` field chooses one downstream settlement posture, independently
+of workspace capability policy. Capability
 admission precedes effect classification and proposal settlement.
 
 §reasoning-policy-wire `ReasoningPolicy` is exactly `off | adaptive | low |
@@ -178,6 +187,10 @@ physical limits, capabilities, and local `ModelReadiness`. A readiness cause
 contains alternative environment-variable sets—every name within a set is
 required and any set may satisfy the cause. It carries names only, never values,
 and asserts neither credential validity nor endpoint reachability.
+`capabilities.reasoningPolicies` lists the route's admitted members of
+{§reasoning-policy-wire}, including supported activation policies; clients do
+not infer fixed efforts from the `reasoning` capability bit. It is not a
+worker's model/spawn intersection or an alias-specific tuning projection.
 
 ### §client-interaction-wire Client-owned interaction wire
 
@@ -229,195 +242,240 @@ USD-expressible request and is `null` only when none is expressible. The empty
 request set projects explicit zero usage and cost. Consumers do not recompute
 provider rates or convert currencies while reading the projection.
 
-The parser returns ordered statement, error, and text items. It recovers at a
+The parser ignores outside text and returns ordered statement and error items
+under {§whitespace-contract}. It recovers at a
 trustworthy statement boundary when possible and sets `unparsedTail` when a
-boundary-destroying failure makes later input undefined. SEND operation codes
+boundary-destroying failure makes later input undefined. Operation status codes
 and parse diagnostics are separate contracts.
 
-## 1.2 GBNF Generation Rail
-
-§gbnf-rail-purpose ANTLR and AstBuilder define accepted PLURNK input. The generated
-`dist/plurnk.{gemma,qwen}.gbnf` are optional local llama.cpp sampling rails kept lean
-to make useful, ANTLR-compliant turns more likely without reproducing every
-parser or semantic validator. Parse compatibility is a design goal balanced
-against rail size and sampling efficiency, not a language-subset guarantee. A
-rail-legal operation can therefore produce a parser or AstBuilder error; consumers
-apply their ordinary admission and bounded-operation recovery contract.
-The complete package build emits both rails; they are not source-controlled. Source and
-differential tests serialize the owning generator directly, while installation
-coverage verifies the packed export.
-
-The rails share one turn shape but begin at their respective sampled-token
-boundaries:
-
-```ebnf
-root-gemma ::= channel sep framed-turn
-root-qwen  ::= think-body think-close sep framed-turn
-root-qwen-response ::= think-open root-qwen
-framed-turn ::= turn | fence-open turn fence-close
-turn       ::= plan sep tail-0
-```
-
-§gbnf-turn-shape Neither rail admits an empty thought: the `gemma` channel body and the `qwen` think body each begin with at least one character, so a constrained call reasons before it acts. The `gemma` transport root samples one complete
-`<|channel>thought\n … <channel|>` enclosure. A Qwen-style chat template has
-already supplied `<think>\n` when the `qwen` transport root begins, so that root
-samples the body and required `</think>` closer. Each generated artifact declares
-an `@plurnk-response-root`; for `qwen`, that root composes the template opener
-back onto the sampled text so the complete pre-projection response can be graded.
-Either body may be empty and cannot contain its profile's opener or closer.
-`sep` is zero through seven whitespace characters. The projected PLURNK content
-is either bare or enclosed once in a paired `plurnk` Markdown fence; the turn
-begins with `## PLAN0`, and every following operation is a same-lane `## OP0`
-section.
-`tail-0` admits zero through fourteen internal operations followed by exactly
-one terminal SEND under the existing terminal-eligibility rules.
-
-```mermaid
-flowchart LR
-    sampled["Constrained sampled text<br/>profile reasoning bytes · sep · optional fence · PLAN0 turn"]
-    raw["Pre-projection response<br/>one complete reasoning envelope · PLURNK turn"]
-    split["llama.cpp<br/>reasoning_format: auto"]
-    reasoning["reasoning_content<br/>envelope body"]
-    content["content<br/>bare or fenced PLAN through terminal SEND"]
-    parser["ANTLR + AstBuilder<br/>admission and diagnostics"]
-    sampled --> raw
-    raw --> split
-    split --> reasoning
-    split --> content
-    content --> parser
-```
-
-§gbnf-reasoning-boundary GBNF applies from sampled token zero before response
-projection. The declared response root composes any template-provided prefix for
-independent validation of the pre-projection evidence. The two projected fields
-are not separate GBNF languages, and `content` alone is not revalidated as though
-it still contained the required reasoning envelope. Provider and core own the
-projection evidence and rail-verdict boundary; this package owns the sampled and
-response roots plus the parser/AstBuilder result.
-
-§rail-heading-boundaries On the GBNF rail, PLAN and every operation use lane `0`.
-Every reserved PLAN or operation heading stem is structural, regardless of the
-delimiter a model attempts next, so a non-`0` pseudo-heading cannot be swallowed as
-literal body text. Rail bodies therefore cannot quote reserved headings from any
-lane. This makes both the canonical delimiter and section boundary structurally
-available during constrained generation; ANTLR remains the wider language and
-accepts intentional alternate-lane literals during ingestion.
-
-§gbnf-kill-shaping The rail shapes KILL as one required target, an optional
-text-coordinate scope (numeric or anchored), and an optional one-line matcher body,
-without proving that the selection resolves; ANTLR and AstBuilder own the statement's
-shape, and runtime owns target resolution ({§kill-scope}).
-
 ## §canonical-statement 2. Canonical statement form
 
-```text
-## PLANdelimiter
+`````text
+```OP (path)? <scope>? [metadata]? <!-- aside -->?
 body
+```
 
-## OPdelimiter (path)? {metadata}* <scope>? <!-- annotation -->?
-body?
+```OP (path)? <scope>?
 ```
 
-§section-boundary A statement is one Markdown section. PLAN alone uses a level-one
-heading; every other operation uses a level-two heading. Its body is the
-character-perfect section content before the next structural heading or EOF.
-Canonical adjacent sections place the next structural heading on the immediately
-following line. The tolerant ingester also admits one empty separator line; that
-separator is syntax rather than body content, while any additional preceding
-blank lines remain body content.
-
-§empty-section An empty section has no body lines between its heading and the next
-structural heading, tolerated separator, or EOF. Optional operation bodies normalize
-to null; PLAN admission normalizes its required semantic body to `[]`
-under {§plan-value}.
-
-| Element      | Canonical contract                                                        |
-|--------------|---------------------------------------------------------------------------|
-| `## PLAN`     | Required level-one turn anchor                                             |
-| `## OP`      | Level-two protocol operation                                               |
-| `delimiter`     | Heading lane, joined directly to PLAN or OP                                |
-| `(path)`     | Optional target slot, preceded by one space                                |
-| `{metadata}` | Optional repeatable scheme-metadata modifier after a target                |
-| `<scope>`    | Optional numeric scope, preceded by one space                              |
-| `<!-- … -->` | Optional trailing operation annotation, preceded by one space               |
-| line ending  | Ends the single-line heading                                               |
-| `body`       | Zero or more characters of operation-specific, character-perfect content  |
-| blank line   | Canonical section separator; excluded from the preceding body              |
-
-The following constraints are structural:
-
-- §lane-match PLAN establishes one lane for the turn. A heading is structural
-  only when its delimiter character-matches that lane; a different delimiter remains
-  ordinary body text.
-- PLAN is the only H1 operation and every non-PLAN operation is H2.
-- A header occupies one physical line.
-- Each admitted signal, target, and scope slot appears at most once. Metadata
-  blocks may repeat only immediately after the target.
-- §plan-slotless PLAN accepts no signal, target, metadata, or scope modifier;
-  observed modifiers are a bounded hard error naming only the rejected slots.
-- An annotation follows every present modifier and appears at most once.
-- BARE, WORK, FORK, and KILL do not admit a scope slot.
-- An ingested delimiter is `[A-Za-z0-9_]*`; canonical teaching and the GBNF use `0`.
-
-§slot-order Canonical producers and the GBNF rail emit signal, then target, then
-metadata, then scope, then annotation, with one ASCII space before every present modifier. Slot delimiters make
-their boundaries unambiguous, so the tolerant ANTLR ingester accepts zero or
-more horizontal whitespace characters before each slot and any permutation of
-the signal, target-with-metadata, and scope admitted by that operation, at most
-once each. Metadata remains attached immediately after its target. Accepted
-spacing and permutation are not second canonical spellings.
-
-§heading-inline-body Text that follows the last slot on a heading line — after
-horizontal whitespace, beginning with a character that cannot open a slot (not `[`,
-`(`, or `<`, nor `{` after a target) — is the first body line: `### EXEC0 [crm] (crm_query) SELECT Id FROM Case` and
-`### FIND0 (src/**) /createCoder/i` parse as their canonical two-line forms. Nothing is
-lost and the stored statement is canonical; the spelling is tolerated and announced:
-one warning-severity advisory follows the statement, naming the heading and the rule
-(body content goes immediately beneath the OP heading line), so the model learns
-the form from the packet and never from silent acceptance.
-
-§operation-annotation A heading may end with one single-line Markdown HTML
-comment. AstBuilder strips the delimiters and surrounding horizontal whitespace
-into the statement's fixed `annotation: string | null` field. The annotation is
-durable, model- and client-facing descriptive text but semantically inert: it
-does not alter operation identity, signal, target, scope, dispatch, effect,
-authorization, status, or body. An empty comment normalizes to the empty string.
-Text containing a newline or lacking the closing `-->` is not an annotation;
-`<!--` elsewhere remains ordinary body text.
-
-§scheme-metadata-modifier A target may be followed by zero or more
-single-line `{metadata}` blocks. AstBuilder preserves each block's exact inner
-text and order as the statement's `metadata: string[] | null`; nested braces
-remain balanced content. The blocks are not part of the target: braces inside
-`(path)` remain ordinary path and glob syntax, including `{PLAN,READ}`. The
-language assigns metadata no meaning. A runtime admits it only for a scheme
-that declares the capability, and that scheme exclusively owns interpretation,
-validation, and authorization. An unfinished block or a newline before its
-closing brace is a structural failure.
-
-The ingester also accepts several bounded noncanonical forms so it can explain
-or safely execute understandable input:
-
-| Tolerated input                                   | Canonical or runtime disposition                                    |
-|---------------------------------------------------|---------------------------------------------------------------------|
-| Reordered admitted slots                          | Producers retain signal → target → metadata → scope order           |
-| Missing target on a generally targeted operation | AST carries `null`; the runtime rejects when the target is required |
-| A non-`0` PLAN lane                               | Model canon uses lane `0`                                           |
-| KILL annotation body                              | AST preserves it; model teaching leaves the KILL section empty      |
-| Dash-separated or comma-space scope numbers       | Producers use adjacent comma-separated numbers                      |
-| Empty content where semantics require a body      | The empty section normalizes null; the operation owner rejects it   |
+```executor (program-or-tool)?
+input
+```
+`````
+
+§section-boundary Every statement is one backtick block. Its header occupies one
+physical line: a fence of at least three backticks, an optional numeric delimiter
+({§numeric-delimiter}), then the name and its slots. A closer is shown by
+convention and never demanded ({§fence-closer}, {§closer-fallback}). There are no
+operation suffixes or heading levels. Nothing in the language is counted by the
+author: every boundary is an anchored line the parser recognizes by its first
+characters (operator, 2026-09-12: counted pairs failed 52 of 363 turns on
+GLM-5.3-flash; anchored tokens failed none).
+
+§fence-closer A block opened with N backticks and delimiter D (its digits, possibly
+none) closes at the first line at column zero made of at least N backticks,
+exactly D, and nothing else but horizontal whitespace. Count follows CommonMark: a
+shorter fence inside the body is body; an equal or longer bare fence closes a bare
+block. The delimiter compares exactly: a bare fence never closes a delimited block,
+and a delimited fence never closes a bare one. The compact one-line form closes on
+its heading line after the modifiers under the same rule.
+
+§numeric-delimiter Digits between the opening backticks and the name (an opener
+carrying `42EDIT (x)`) identify the block, and only a fence carrying `42` closes it. This is how a
+block nests fences of its own width: with a delimiter, a body may carry bare fences
+and headings of the same count. The delimiter is syntax, never AST or persistence
+state; `PlurnkParser.frame` chooses one when the body it wraps holds a heading line
+of four or more backticks ({§statement-rendering}).
+
+§fence-heading-in-body A fence line of four or more backticks, optional digits, and
+a name that is a native operation or a known executor is a heading wherever it
+stands. Inside an open block it ends that block without closing it
+({§closer-fallback}) and opens the next statement. Fence lines of fewer than four
+backticks are headings only outside any block. Known executors are `sh` plus what
+the host names in `ParseOptions.executors`. Consequences: a closer glued to the next
+opener (eight backticks then `READ`) can never swallow the rest of a turn, and a quoted
+heading of four or more backticks inside a body needs the numeric delimiter to stay body.
+
+§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 cut back to its last bare fence line (any count,
+optional digits), which is the closer the author meant, and one terminating line
+ending goes with it; when no bare fence line exists the body is the whole span less
+one terminating line ending. This carries no diagnostic: a missing closer is never
+an admission failure, and {§unparsed-tail-boundary} is not involved.
+
+§fence-boundary Inside a body, fences are read by count and delimiter, never by
+name, except for the heading rule above:
+
+| Fence encountered inside a body | Meaning |
+|---|---|
+| Fewer backticks than the block's own | Body |
+| At least the block's backticks, bare, block undelimited | The block's closer |
+| At least the block's backticks carrying the block's delimiter | The block's closer |
+| At least the block's backticks with any other delimiter | Body |
+| Four or more backticks naming a native operation or known executor | A heading: ends the block, opens the next statement |
+
+§indented-fences Leading horizontal whitespace before an opener or a closer is
+not part of the fence: an indented fence line is a fence line, on openers,
+closers, headings that end a block, and the closer fallback. A body keeps its own
+lines' indentation. CommonMark allows three spaces; this allows any, because a
+model that indents an emission indents all of it (operator, 2026-09-12: measured
+at five to ten percent of emissions on GLM-5.3-flash).
+
+§inline-chain A closer on a heading line, or on a body's closing line, may be
+followed on that same line by the next opener; the closer still closes, and the
+opener opens. This absorbs the habit of writing several operations in one
+paragraph after prose. Prose after a closer on its line ends the chain; slot-shaped
+text there is the heading's own and is read under {§transparent-inline-closer}.
+
+§transparent-inline-closer **A closer mid-heading is read as if it were not written.** A
+closing fence on a heading line followed by more of that heading — a `<scope>`, an
+`[option block]`, a `<!-- aside -->`, or a naked matcher — does not end the reading: the
+heading keeps taking its slots under {§trailing-slots} and {§naked-pattern}, exactly as though
+the closer were absent, so ```READ (a.md)``` `<1,2>` is the same operation as `READ (a.md) <1,2>`.
+The closer is still a closer: the block ends with that physical line and never reaches down for
+the next operation, which is what a bare heading carrying a matcher would do. A closer followed
+by the next opener is {§inline-chain}, and by nothing is the ordinary {§fence-closer}. There is
+no ambiguity to resolve: a slot begins with `<` or `[` and an opener with a backtick run, so the
+shapes are disjoint (operator, 2026-09-13: "If there is no risk of ambiguity, then we add
+tolerance. Turning model soup into operations instead of errors is a cardinal imperative").
+
+§executor-case **An executor tag in any case.** A fence tag that matches a
+registered executor's name case-insensitively opens that executor (`SH` opens
+`sh`), and the statement's `executor` is the registered spelling, so a lookup
+by that name never misses. Operation names stay uppercase by teaching and were
+never written otherwise in 12,000 fences; one `SH` in 1,300 `sh` fences was
+(2026-09-13 census). An unregistered name in any case is still prose
+({§interstitial-fence}).
+
+§one-line-turn **A whole turn on one line.** The most frequent private rejection
+across the 2026-09-12/13 dumbox runs (five of eleven) was a turn emitted as a
+single line: prose, then heading after heading with no line ending anywhere. Two
+rules absorb it. The next opener on a heading's own line, after the heading's
+slots, ends that heading's block bodyless and opens ({§empty-section}), so
+`````EDIT (a.rs) <60,66> <!-- drop --> ````EDIT (b.rs) <31,38>` is two scoped
+deletions; and a TASK whose inventory rides its heading line as a `[…]` block
+(`````TASK [{"content": "…", "status": "in_progress"}] ````) takes that block as
+its body when nothing sits beneath the heading, with one warning-severity
+advisory naming the body as where the inventory belongs. A block beneath the
+heading still wins.
+
+§anchor-digits In a text scope, `@` followed by one to four digits cannot be a
+hash and is read as that line number, with one warning-severity advisory naming
+the five-character anchor form. Five characters after `@` are always an anchor.
+
+§unclosed-aside A heading whose aside opens with `<!--` and never closes on its
+line takes the rest of the line as the aside, with one warning-severity advisory.
+A closed aside followed by more text is unchanged.
+
+§interstitial-fence A fence line that names no native operation and no known
+executor opens nothing: unlabeled, or tagged like a code block (`ts`, `json`),
+outside a block it is prose and ignored like every other outside line
+({§whitespace-contract}); inside a body it is body. Nothing is promoted into a
+header or recursively parsed. There is no implicit SEND: a reply is an explicit
+`SEND` block. (This replaces the retired unlabeled-fence SEND of the fences
+chapter, whose unlabeled fences turned displaced headings into silent messages.)
+
+§bare-heading-advisory An operation name that opens a line outside any block in the
+shape of a heading (`READ (…)`, `TASK`, …) is prose and runs nothing. The parser
+emits one warning-severity advisory naming the fence form, placed after the parsed
+items, so the loss is never quiet.
+
+§empty-section Both the compact bodyless form and an empty multiline block
+normalize optional bodies to null. TASK normalizes an empty body to `[]`
+under {§plan-value}. Closing fences are conventional, never required
+({§closer-fallback}).
+
+§statement-rendering `PlurnkParser.stringify` renders native OP names and named
+runtime fences from the shared AST, with one blank line between operations.
+Every closing fence occupies its own line, including bodyless operations;
+inline fences remain accepted input, not generated examples.
+It chooses at least four backticks and more than any run within the body, and a
+numeric delimiter whenever the body holds a heading line of four or more backticks
+({§fence-heading-in-body}), preserving body bytes on reparse. Fence length and
+delimiter are syntax, not AST or persistence state. Core-authored programs use
+this serializer and the ordinary admission parser.
+
+| Element | Contract |
+|---|---|
+| Fence name | Reserved native OP, otherwise a registered executor or attached MCP service |
+| `(path)` | Target/program/tool slot; COPY and MOVE each have two resource operands |
+| `[metadata]` | One JSON array of option objects, owner-interpreted; options, never the op's input |
+| `<scope>` | Operation-specific numeric or anchored coordinates |
+| `<!-- … -->` | Optional final, single-line aside |
+| Body | Literal content between framing newlines |
+| Closing fence | The opening backtick count and delimiter, on its own line |
+
+§slot-order Producers put target, scope, metadata, then aside, separated
+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.
+
+§plan-slotless TASK accepts no target or metadata. Its optional scope carries
+waiting timing; its inventory body begins below the header.
+
+§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.
+
+§operation-aside The final header modifier may be one single-line HTML
+comment. AstBuilder removes its delimiters and surrounding whitespace into
+`aside: string | null`. It is durable descriptive text, not authority,
+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; an executor fence also admits it without a target.
+Read with its brackets, the block is a JSON array of option objects, merged
+left to right with later keys winning; the keys belong to the selected scheme
+or executor, which owns interpretation, validation and authority. The language
+assigns no meaning to the content and stores each block's exact inner text:
+balanced brackets inside the block are retained, and double-quoted strings
+protect their brackets. Brackets inside `(path)` remain ordinary path and
+glob characters. A block that is not valid JSON, or a second block on one
+operand, is the owner's `400`, never a parser diagnostic. An unfinished block
+or multiline metadata loses its boundary. Two keys never reach an owner:
+`pattern`, the language's own ({§matcher-option}), and `env`, reserved for the
+service's environment option on the operations that open a process or a
+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
+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
+the owner verbatim, and the owner's reader treats `pattern` as reserved. The
+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 KILL take no body at all: 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
+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:
+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": "…"}]`.
 
 ## 3. Lexical elements
 
-| Element     | Accepted shape or role                                             |
-|-------------|--------------------------------------------------------------------|
-| `OP`        | `FIND READ EDIT COPY MOVE SEND EXEC BARE WORK FORK KILL PLAN`           |
-| `delimiter`    | `[A-Za-z0-9_]*`, adjacent to PLAN or OP                            |
-| `(path)`    | Local path or scheme URL target; detailed in §5                    |
-| `{metadata}` | Repeatable opaque scheme modifier attached after a target          |
-| `<scope>`   | One or more signed integers or decimals; detailed in §7            |
-| annotation  | Optional trailing `<!-- … -->` descriptive text                    |
-| `body`      | Opaque section text before the next same-lane heading or EOF        |
+| Element | Shape or role |
+|---|---|
+| Native OP | `FIND READ EDIT COPY MOVE SEND BARE WORK FORK KILL TASK` |
+| Executor name | Letters, digits, `_`, `.`, `+`, or `-`; reserved OPs win |
+| Fence | Three or more backticks, matched by exact count |
+| `(path)` | Local path, URI, program or tool name; §5 |
+| `[metadata]` | One JSON array of owner-defined option objects |
+| `<scope>` | Numeric or anchored coordinates; §7 |
+| Body | Literal text; never recursively interpreted as operations |
 
 ## §op-shapes 4. Per-operation semantics
 
@@ -426,83 +484,115 @@ governed by {§canonical-statement}; runtime conditions remain explicit below.
 
 | OP   | `(path)`                                     | `<scope>`                       | `body`                         |
 |------|----------------------------------------------|---------------------------------|--------------------------------|
-| PLAN | none                                         | none                            | required Plurnk Plan JSON array |
 | FIND | required target or glob                      | optional result range           | optional matcher               |
 | READ | required target                              | optional text region            | empty                          |
 | EDIT | required file or entry                       | required for an existing target | literal text                   |
 | COPY | required source and destination              | optional region after each path | empty                          |
 | MOVE | required source and destination              | optional region after each path | empty                          |
-| EXEC | optional `[executor]`, optional program path ({§exec-executor-slot}) | optional timeout, poll     | optional program input        |
-| BARE | none                                         | none                            | required prompt                |
-| WORK | required fresh `worker://name`               | none                            | required prompt                |
-| FORK | required context-inheriting `worker://name`  | none                            | required prompt                |
-| KILL | required target, including a log item        | optional text region ({§kill-scope}) | optional matcher          |
-| SEND | a label `(NEXT\|WAIT\|TERM\|FAIL)` or an optional recipient ({§send-label}) | optional timeout, poll on WAIT | message; terminal is nonempty |
-
-§operation-code-polymorphism SEND and KILL share a numeric wire slot, not one universal numeric vocabulary.
-For pathless terminal SEND, the code is the loop disposition defined in §9.
-Directed SEND and KILL delegate any present code to the addressed target's
-operation contract; a live process may interpret a KILL code as a Unix signal,
-but that interpretation does not define KILL generally.
-
-§plan-value **PLAN carries one installment of the model's running work journal.**
-Its entries record newly made working-memory items: durable findings and decisions
-are `memory`, finished actions are `completed`, open work is `pending`, and active
-priorities are `in_progress`. Admission parses the JSON body — one JSON array document in any whitespace layout, including the {§json-result-rendering} spread the log projects — strips unknown
-entry keys (the model-facing Plan carries no priority: struck 2026-08-24 so the
-log echoes only the canonical shape, starving stale-field habits), and validates
-the canonical bare array: every entry has string `content` and `status` in
-`pending | in_progress | completed | memory`. A nonempty plain-text,
-malformed-JSON, or otherwise invalid body becomes one `in_progress`
-entry whose content is the exact authored body; admission performs no partial
-repair or list inference. An empty body becomes the planless `[]`
-value. Each PLAN is the complete semantic value of that journal installment;
-prior installments remain ordinary curatable log items. The exact `turnOps`
-source remains forensic program evidence, while the normalized array is the sole
-semantic value used by AST, persistence, durable log bodies, and model-packet
-materialization. PLAN is public log content—not
-provider reasoning—and Plurnk initially mints no `_meta` values. Dispatch records
-the canonical value and has no other runtime effect.
+| execution | the fence name is the runtime; optional program/tool path ({§exec-executor-slot}) | optional timeout, poll     | optional program input        |
+| 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 | required target, including a log item        | optional text region ({§kill-scope}) | none; the matcher is the `pattern` option |
+| SEND | optional recipient | optional recipient timing | message |
+| TASK | none | optional timeout and poll for waiting intent | Plurnk Plan JSON array |
+
+§operation-code-polymorphism Operation-result statuses and turn dispositions are
+distinct facts. TASK derives lifecycle intent from its inventory;
+SEND and KILL carry no disposition operand.
+
+§plan-value **TASK carries the complete current task inventory.** Admission
+parses one JSON array in any whitespace layout, including
+{§json-result-rendering}, strips unknown entry keys, and validates string
+`content` and native `status`. Opaque `_meta` remains optional. Nonempty plain
+text, malformed JSON, or an invalid array becomes one `in_progress` entry
+containing the exact body, with one factual warning. No partial repair or list
+inference occurs. A blank body becomes `[]`, never inferred completion.
+The normalized array is the sole semantic value in AST, persistence and model
+log; exact authored bytes remain in `turnOps`. Earlier inventories are history,
+not accumulated obligations. Task descriptions are not executable dependencies.
+
+§task-inventory-intent The first matching row determines intent, independently
+of entry order. Actual execution adjudicates intent under {§wait-obligation-matrix}.
+
+| Inventory condition | Intent | Derived lifecycle status |
+|---|---|---|
+| TASK omitted | Continue silently | 102 |
+| Explicit empty inventory | Recover empty inventory | 102 |
+| Any `in_progress` | Continue independent actionable work | 102 |
+| Any `waiting`, no `in_progress` | Await work or an event | 202 |
+| Any `todo`, no actionable or waiting entry | Continue | 102 |
+| All terminal, any `completed` | End successfully | 200 |
+| All `failed`, nonempty | End unsuccessfully | 499 |
+
+`todo` is not started; `in_progress` can be actively advanced;
+`waiting` awaits an ongoing stream, worker or external event. `completed` is
+successful resolution; `failed` is unsuccessful resolution. A failed sibling
+does not terminate independent unfinished work. The engine does not infer a
+dependency graph from task text.
 
 §plan-acp-projection **Only an ACP-facing boundary projects the model-native
 Plan.** It constructs ACP's `{ "entries": [...] }` Plan object from the internal
 array, synthesizes the ACP-required neutral `medium` priority on every entry
-(the model-native Plan carries none), maps each `memory` entry to ACP
-`completed`, and prefixes its content with exact "Memory: " framing without
-duplicating an existing prefix. Every other entry field remains unchanged, and
-the internal value is not mutated.
+(the model-native Plan carries none). The internal value is never mutated.
+Native `todo` maps to ACP `pending`: the same state under ACP's name, so it carries no marker.
+Native `waiting` maps to ACP `in_progress`, with `Waiting:` and a space prepended
+to its display content; native `failed` maps to ACP `completed`, with `Failed:` and a space.
+Both carry their native status in `_meta["plurnk.xyz/status"]`, an edge-owned
+key derived from the native status rather than trusted from authored metadata.
+Other statuses and unrelated metadata remain unchanged. The labels preserve
+meaning even when a generic client ignores extension metadata.
 The projected value validates against the separately owned ACP Plan schema pinned
 to ACP v1
 [`schema-v1.21.0`](https://github.com/agentclientprotocol/agent-client-protocol/tree/schema-v1.21.0)
 commit `272bf799f35a258c6a4107a0410ed361e83683d3`.
 
-§exec-executor-slot An EXEC heading takes an optional `[executor]` slot before its path: `### EXEC0 [python3] (tools/report.py)`. The executor may also trail the path (`### EXEC0 (tools/report.py) [python3]`); either position binds the same AST, since no other slot after a path uses `[...]`. Canonical rendering leads with the executor. Two executors are the one rejected shape. The bracket names the registered executor that runs the program — a tool family, a language runtime, or the shell — and lexes as one `EXECUTOR` token only on an EXEC heading. The path names the program: a registered tool of that family, or a script file or entry. A bare `### EXEC0` is the shell running its body; with a path the body is the program's input. The AST carries `executor` (null for the shell) and `target` separately; the path is never split. Each of the executor, the path, and the `<timeout,poll>` scope appears at most once. Tool teaching, not the grammar, spells the registered executors; a `{cwd=…}` metadata block, interpreted by the executor, names the working directory.
-
-§send-label SEND's path slot carries either a turn label or a recipient. The four
-labels `(NEXT)`, `(WAIT)`, `(TERM)`, and `(FAIL)` lex as one `SEND_LABEL` token
-and make the SEND terminal: the AST `status` is 102, 202, 200, or 499 and `target`
-is null. A label SEND names no recipient; a label beside a recipient path is one
-error at the heading naming that rule. A SEND whose path is a recipient
-(`### SEND0 (worker://recheck)`, `(https://…)`, `(a2a://…)`), or whose path slot is
-empty (the user), is a mid-turn message with `status` null. The GBNF rail spells a
-mid-turn recipient as a URL, so a constrained turn can never place a label mid-turn.
-
-§send-wait-scope A `(WAIT)` SEND keeps its numeric `<scope>` — the park interval
-and poll ({§park-202-only}); the dispatcher owns what it accepts. Every other label
-takes no scope.
+§exec-executor-slot The fence name selects the executor directly: for example,
+`python3 (tools/report.py)` or `gitea (issue_list)` on the opening fence line.
+Reserved native OP names take precedence. Any other name is an executor fence: its
+AST carries the `runtime` tag and no operation keyword, then `target`, metadata, timing and body fields.
+Registration is checked by the runtime, not by the syntax parser. An attached
+MCP service uses that executor path and its owner validates the named tool and
+input-body JSON against its schema. Unknown names do not fall back to a shell.
+There is no runtime-less form: every execution names its runtime, and canonical
+shell examples name `sh` explicitly.
+The path names a program or tool and is never split. Metadata such as
+`[{"cwd": "…"}]` remains interpreted by the selected executor.
+
+§turn-disposition TASK is the sole workflow declaration. `TurnDisposition`
+derives intent from its canonical inventory under {§task-inventory-intent}.
+The AST has no independently settable lifecycle status, target or metadata.
+SEND deliberately messages its recipient, or the user when targetless; it
+neither changes task status nor terminates a run. A program contains one final
+TASK, not last-wins competing inventories. Former lifecycle names are not aliases.
+
+§send-wait-scope TASK accepts `<timeout[,poll]>` in whole minutes. It applies
+only to a waiting intent ({§park-202-only}); the dispatcher validates its bounds.
+Otherwise it is unused, with a factual warning rather than a changed outcome.
+
+§send-directed-scope A recipient SEND preserves an optional numeric scope after
+its target and metadata. The addressed owner assigns its semantics; worker
+actors use `<delay[,interval]>` ({§worker-scheduled-send}). A targetless message
+takes no scope. Scheduling does not change the message body or disposition.
 
 §kill-scope KILL takes an optional text-coordinate scope beside its target, numeric or
-anchored (`### KILL0 (log:///**/READ) <17,-1>`, `### KILL0 (worker:///notes.md)
-<@aB3dE,@0Aa9Z>`), and an optional one-line matcher body that selects rows. The AST
-is `{ op: "KILL", target, lineMarker: TextLineMarker | null, body: MatcherBody | null }`.
+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: null }`.
 Without a scope, KILL retires or deletes the whole target; with one, it removes exactly
 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 The bracket slot carries no signal, tag, code, or status on any heading; EXEC alone takes `[executor]` ({§exec-executor-slot}). A `[` on any other heading is one bounded lexer diagnostic that names that rule and the OP's own `(path)` slot, and after PLAN states that PLAN takes no modifiers. The statement drops and its siblings run.
+§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.
 
 The `<scope>` slot is optional where admitted and its domain is OP-specific. FIND
-scopes ordered results. EXEC and a WAIT SEND scope timing. READ, EDIT, COPY,
+scopes ordered results. Executions and SEND scope owner-defined timing. READ, EDIT, COPY,
 MOVE, and KILL use one universal text algebra independent of mimetype; a log
 KILL admits only its one- and two-line forms for canonical log-body visibility:
 
@@ -525,22 +615,37 @@ four-coordinate region ending after the final code point of `endLine`.
 Producers never emit that form. Other arities and decimal text coordinates are
 runtime 416 failures.
 
-§bare-statement **BARE requests one isolated model inference.** Its required
-body is the complete prompt: no
-target, scope, persistent worker identity, or output-language statement shape
-is represented in the AST. Runtime provider selection, batching, accounting,
-and observation timing belong to the consuming service.
-
-§read-find-normalization An authored READ with a nonempty matcher body or a
-target path classified as a glob normalizes during AST construction to one
-ordinary FIND statement. Target, signals, scope, and matcher are preserved;
-FIND's result pagination and projection contract then applies. The canonical
-AST retains no parallel matcher-READ mode, and the runtime performs no READ
-fan-out.
-
-§read-exact-target After normalization, READ targets one exact resource (a
-local path or scheme URL, with optional `#channel` fragment or
-`{header: value}` metadata) and has no matcher body. A `<scope>` on READ selects
+§bare-statement **BARE requests one isolated model inference.** Its optional
+path names a prompt resource; its body supplies inline prompt text. At least
+one must supply nonempty text at execution. With both, the complete resource
+text precedes the body, separated by two newlines. The target's scheme owns any
+metadata modifier. No scope, persistent worker identity, or output-language
+shape is represented. Provider selection, source admission, batching,
+accounting, and observation timing belong to the consuming service.
+
+§read-find-normalization An authored READ is never rewritten into a FIND. A
+glob target on READ keeps its glob, and the runtime fans it out into one exact
+READ per matching path, with the authored scope and matcher ({§read-fan-out}
+in the core SPEC; operator, 2026-09-13: "give it what it asked for" — a model
+that asks to read every file under a glob gets those files, bounded by the
+FIND page and the preview scope, not a catalog it did not ask for). A matcher
+never changes the operation either: READ with a `pattern` on an exact target
+stays READ and renders the selected lines ({§read-pattern}). The survey of
+paths is FIND, and only FIND.
+
+§local-path-fragment **A bare path takes `#channel` like a URL.** `data/users.html#readable`
+parses as `{ kind: "local", raw: "data/users.html", fragment: "readable" }`: the first `#` ends
+the path and the rest is the channel (a spelling that opens with `#` names no path and stays
+whole), exactly as `worker:///a.html#readable` decomposes, so
+the `#channel` a READ receipt advertises (`channels: {"#readable": N}`) is addressable in the
+same bare spelling the receipt used (2026-09-13 dumbox demo: the model appended it and was
+told no entry existed at `users.html#readable`). `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.
+
+§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
+`<scope>` on READ selects
 a text region from that exact target. Without a scope, READ defaults to
 `<1,16>`; `<1,-1>` explicitly selects all text. Decimal scope components are
 invalid on READ.
@@ -554,7 +659,10 @@ Mutation semantics:
 - `<0>` prepends and `<-1>` appends.
 - §empty-mutation-scope Empty mutation content has one writable position: `<0>`, `<1>`, `<-1>`, and `<1,-1>` all insert the body as its complete value. Other scopes resolve against that same empty value through the ordinary coordinate algebra.
 - `<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 on the heading, source first and destination second, and admit no body. Each operand consists of `(path)`, any following `{metadata}`, and an optional following `<scope>`; modifiers bind only to the immediately preceding path. The two operands independently select their resource, channel, scheme metadata, and text region.
+- §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}.
 
 ### §operation-observation Per-operation observations
 
@@ -566,16 +674,16 @@ Mutation semantics:
 | COPY | Source and destination selections plus ordered destination effects                |
 | MOVE | Source and destination selections plus ordered destination and source effects     |
 | SEND | Status and recipient acknowledgement when applicable                              |
-| EXEC | Spawn acknowledgement; output arrives through named stream channels               |
+| execution | Spawn acknowledgement; output arrives through named stream channels               |
 | BARE | The one-shot model response                                                        |
 | WORK | Spawn acknowledgement; the deliverable arrives through the log                    |
 | FORK | Spawn acknowledgement; the inherited worker's deliverable arrives through the log |
 | KILL | Status of deletion or termination                                                 |
-| PLAN | Status of durable complete-Plan logging                                           |
+| TASK | Current inventory and adjudicated lifecycle outcome                              |
 
 §find-result-unit For FIND, authored target shape fixes the paginated result
 unit. An exact target with a matcher pages flat match locations; a glob or
-folder target, and every body-less FIND, pages resources. Resolving a glob to
+folder target, and every matcher-less FIND, pages resources. Resolving a glob to
 one resource does not make it exact. The same `<N>`, inclusive `<N,M>`,
 markerless `<1,16>`, and explicit-all `<1,-1>` forms apply to either unit.
 
@@ -588,8 +696,8 @@ EDIT. Whole-channel transfers remain bodyless structural effects; runtime
 owners reject binary markers rather than treating a text field as a byte lane.
 
 Every operation returns the runtime-neutral `OperationResult` defined by
-{§operation-result}. Its `status` belongs to the result envelope and is not a
-SEND signal. Durable operation observations are projected into a later packet;
+{§operation-result}. Its `status` belongs to the result envelope; TASK supplies
+the authored lifecycle intent. Durable operation observations are projected into a later packet;
 retrieval never returns inline within the emitting turn.
 
 ## §path-syntax 5. Target and path grammar
@@ -599,7 +707,7 @@ and path globs share the slot; content matchers belong in the body.
 
 | Form                    | Typed admission                                                     | Runtime meaning                                      |
 |-------------------------|---------------------------------------------------------------------|------------------------------------------------------|
-| Bare path               | `LocalPath { kind: "local", raw }`                                  | Resolves through the runtime's file surface          |
+| Bare path               | `LocalPath { kind: "local", raw, fragment? }`                       | Resolves through the runtime's file surface; `#channel` is `fragment` ({§local-path-fragment}) |
 | `scheme://…`            | WHATWG-decomposed `UrlPath`                                         | Resolves only when a runtime scheme owns the address |
 | Path glob               | Preserved in either path kind                                       | Scheme defines collection selection and ordering     |
 | `#channel` fragment     | Preserved as `UrlPath.fragment`                                     | Selects a named channel when the scheme supports it  |
@@ -646,69 +754,69 @@ Matching and folder-scope semantics remain runtime concerns.
 
 §worker-name The exported `WORKER_NAME` contract governs names minted for URI
 authority slots: a lowercase DNS label matching
-`[a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?`. `RESERVED_AUTHORITIES` contains the
-authority-shaped internal worker names `commons` and `plurnk`, which are
-unavailable for minting. `~` is the sole current-worker sigil and falls outside
-the mintable alphabet; every matching unreserved value, including `self`, is an
-ordinary literal worker name. This is a minting and registry invariant, not an
+`[a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?`. There is no reserved-name list: the
+runtime's own actor is named `_plurnk`, a spelling the predicate never admits,
+and `~` is the sole current-worker sigil, likewise outside the mintable
+alphabet. Every matching value, including `self` and `plurnk`, is an ordinary
+literal worker name. This is a minting and registry invariant, not an
 ingestion restriction: the parser decomposes arbitrary URL authorities.
 
 ## §matcher-prefix-claims 6. Bulk pattern matching
 
-FIND, authored READ, KILL, LOOK, and BUFF accept an optional body matcher.
-The lexer preserves the body opaquely; AstBuilder assigns the dialect from its
-leading characters, then normalizes matcher-bearing READ to FIND under
-{§read-find-normalization}.
-A leading prefix claims its dialect. Invalid claimed syntax is a positioned
-visitor error and never falls back to glob matching.
+FIND, READ, KILL, EDIT, and the COPY/MOVE operands accept an optional matcher
+through the `pattern` option ({§matcher-option}); the client-tier LOOK still
+carries its matcher as a body. AstBuilder assigns the dialect from the
+matcher's leading characters. A leading prefix claims its dialect. Invalid
+claimed syntax is a positioned visitor error and never falls back to glob
+matching.
 
 - §heading-boundary-recovery A column-0 heading is the trustworthy boundary. After a
   statement-level error the parser discards the rest of that statement and resumes at the
-  next heading; the turn shape is decided locally (a terminal SEND is recognized by its own
-  disposition signal, never by a whole-turn alternative), so one malformed heading costs one
-  diagnostic and every later statement, the terminal SEND included, stands on its own. Any
+  next heading; the turn shape is decided locally (a turn disposition is recognized by its own
+  token, never by a whole-turn alternative), so one malformed heading costs one
+  diagnostic and every later statement, the turn disposition included, stands on its own. Any
   other second path slot names the one-slot rule.
-- §scope-slot-tolerance A line scope written inside a path slot (`### COPY0 (worker:///src.md<2,3>)`)
+- §scope-slot-tolerance A line scope written inside a path slot (```` ```COPY (worker:///src.md<2,3>) ````)
   is read as `(worker:///src.md) <2,3>` — `<` and `>` are not URI characters, so a `<…>` right
   before a slot's closing paren can only be a scope; every path slot of a statement is repaired
   the same way — and the slip is one warning-severity advisory at the `<`, placed right after its
   statement, stating the `(path) <scope>` form that was used. The statement runs; a warning is
   never a strike. A `<` anywhere else in the slot remains the lexer's refusal.
 - §second-path-slot A second `(path)` on a heading that already closed one is a parser
-  error at the second paren stating the one-slot rule and that a pattern belongs in the body;
-  the statement is dropped and its siblings run.
+  error at the second paren stating the one-slot rule and that a pattern belongs in the
+  `[{"pattern": …}]` option; the statement is dropped and its siblings run.
 
-| Prefix    | Dialect  | Canonical body                       | Typed admission                   | Runtime owner       |
+| Prefix    | Dialect  | Canonical form                       | Typed admission                   | Runtime owner       |
 |-----------|----------|--------------------------------------|-----------------------------------|---------------------|
 | `//`      | XPath    | `//selector`                         | XPath 1.0 `xpath.parse()`         | Mimetype projection |
 | `/`       | Regex    | `/pattern/flags`                     | ECMAScript `RegExp` construction  | Mimetype projection |
+| `^`       | Regex    | `^pattern`, no slashes or flags      | ECMAScript `RegExp` construction  | Mimetype projection |
 | `$`       | JSONPath | RFC 9535 expression                  | `json-p3` compilation             | Mimetype projection |
-| `~`       | Semantic | `~phrase`                            | Any text after the prefix         | Embedding index     |
+| `~`       | Full-text | `~query`                            | Single-line raw string            | SQLite FTS5 index   |
 | `&`       | Graph    | `&symbol`, `&<symbol`, or `&>symbol` | Exact shape validation            | Symbol index        |
 | none      | Glob     | Shell glob or literal text           | Single-line raw string            | Mimetype projection |
 
 XPath is classified before regex because its prefix is two slashes. Regex
 splitting respects escapes and character classes; `\/` represents a literal
 slash. The AST stores regex `pattern` and `flags`, not a compiled object.
-Semantic matchers require no parse step. Graph admission validates its direction
+SQLite validates full-text query expressions at execution. Graph admission validates its direction
 and non-whitespace symbol before runtime. Every other leading character remains
 in the fallback glob/literal dialect; `@(...)` is therefore an extglob group and
 bare `@text` remains literal matcher text. Rendered READ coordinates are
-structural output rows, not a reserved matcher prefix. Scope carries semantic
-threshold and result-range information rather than changing the matcher body.
+structural output rows, not a reserved matcher prefix. FIND scope selects result
+positions without changing the matcher.
 
 AstBuilder validation is compile-only and never evaluates a document. Matcher
-evaluation belongs to the runtime's selected mimetype, embedding, or symbol
+evaluation belongs to the runtime's selected mimetype, FTS5, or symbol
 implementation. A matcher admission error is local to its statement; later
 statements remain recoverable when their boundaries are trustworthy.
 
-- §pattern-body-single-line Every matcher body is one physical line. AstBuilder
-  rejects multiline bodies before dialect classification, while GBNF excludes
-  line terminators. A regex that matches a newline uses the two-character `\n`
-  escape. Non-matcher operation bodies remain multiline.
-- §pattern-body-leading-colon The GBNF rail forbids `:` as the first matcher
-  character. Empty matchers and later colons remain valid; a regex such as
-  `/^:needle/` expresses a pattern beginning with a literal colon.
+- §pattern-body-single-line Every matcher is one physical line. On the protocol
+  operations it is the heading line's text ({§naked-pattern}) or the `pattern` option's
+  JSON string ({§matcher-option}), one line by construction; the client-tier LOOK still carries its matcher as a body, and AstBuilder
+  rejects a multiline one before dialect classification. A regex that matches a
+  newline uses the two-character `\n` escape. Non-matcher operation bodies remain
+  multiline.
 
 ## §scope-slot 7. Scope markers
 
@@ -728,15 +836,15 @@ The operation column names the canonical AST operation after
 | COPY/MOVE source      | 0/1/2/4 text coordinates               | Region copied or moved from the selected source                            |
 | 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}) |
-| EXEC                  | `timeout[,poll]`                       | Spawn lifetime bound and poll cadence in minutes                           |
-| `### SEND0 (WAIT)`     | `timeout[,poll]`                       | Bounded or indefinite wait and optional poll cadence ({§send-wait-scope})  |
+| execution             | `timeout[,poll]`                       | Spawn lifetime bound and poll cadence in minutes                           |
+| ```` ```TASK ````     | `timeout[,poll]`                       | Waiting intent: bounded or indefinite wait and optional poll cadence ({§send-wait-scope}) |
+| Directed SEND         | Owner-defined numeric scope           | Worker actors schedule a task with `delay[,interval]` ({§send-directed-scope}) |
 
 Text coordinates use the algebra in {§text-scope-semantics}: one integer is a
 whole line, two integers are an inclusive whole-line range, and four integers
 are an exact start-inclusive/end-exclusive region. Mutation scopes additionally
-admit `0` as prepend and `-1` as append. A leading decimal on semantic FIND
-is a similarity threshold; any remaining integers select result positions. READ
-does not admit decimal scope components. A log KILL intersects a valid body-relative line
+admit `0` as prepend and `-1` as append. FIND result positions and READ
+text coordinates do not admit decimal scope components. A log KILL intersects a valid body-relative line
 scope with each selected body; an absent line is a successful no-op for that
 body, while unsupported arity is a runtime failure.
 
@@ -765,95 +873,74 @@ reinterpreting them. FIND owns a deterministic result order so the same
 inclusive range selects the same positions from unchanged state. The parser
 does not enforce either condition.
 
-## §delimiter-discipline 8. Delimiter Discipline
-
-The delimiter is a turn-wide heading lane. A heading carrying the active lane
-is structural; an otherwise valid PLURNK heading carrying another lane is body
-text. The lane therefore makes literal or nested PLURNK unambiguous.
+## 8. Literal programs and code blocks
 
-Delimiter rules:
+A producer carrying literal fences uses an outer backtick count absent from
+standalone fence lines in its body ({§fence-boundary}). The serializer chooses
+a count greater than every backtick run in the body; parsed AST values carry
+no framing state.
 
-- `delimiter` is `[A-Za-z0-9_]*`, concatenated to PLAN or OP with no separator.
-- The H1 PLAN establishes the lane; every real H2 operation heading in that
-  turn has the exact same delimiter.
-- An empty delimiter is accepted only by ANTLR ingestion. Canonical teaching and
-  the generated rail use `0` on PLAN and every operation.
-- A body may contain any heading whose delimiter differs from the active lane.
-- To carry a nested turn written with lane `0`, choose another delimiter for the
-  outer turn and repeat it on every outer heading.
-- The GBNF deliberately emits only lane `0`. It cannot emit body content that
-  contains a same-lane structural heading; unconstrained producers use another
-  outer lane when that representation is required.
+`````text
+````EDIT (README.md) <1,-1>
+Run the tests:
 
-Example — a lane-0 turn stored inside a lane-2 EDIT body:
-
-```example
-## PLAN2
-[{"content":"Store the quoted turn.","status":"in_progress"}]
-
-### EDIT2 (worker:///quoted.plurnk)
-## PLAN0
-[{"content":"Answer from memory.","status":"in_progress"}]
-
-### SEND0 (TERM)
-Paris.
-
-### SEND2 (TERM)
-Stored the quoted turn.
+```sh
+npm test
 ```
+````
+`````
 
-The lane-0 headings are ordinary EDIT body text because the outer turn's
-structural lane is `2`. This rule belongs to section framing and applies to
-every operation, not to EDIT semantics.
+The inner shell example is EDIT content, not an execution. The same
+rule protects code examples in SEND, WORK, FORK, BARE and every other body.
 
-## 9. SEND Codes
+## 9. Turn dispositions
 
-Pathless terminal SEND disposition codes align with HTTP semantics so that model training
-transfers directly:
+TASK inventory intent maps to the existing HTTP-shaped lifecycle statuses
+({§task-inventory-intent}). The runtime adjudicates that intent against actual
+results, obligations and timing:
 
-| Class | Terminal meaning                                                | Disposition used by the model |
-|-------|-----------------------------------------------------------------|-------------------------------|
-| `1xx` | Continue after submitted operations                             | `102 Processing`              |
-| `2xx` | Conclude successfully or wait on live obligations               | `200 OK`, `202 Accepted`      |
-| `4xx` | Abandon the loop after a model-side inability                   | `499`                         |
-| `5xx` | Runtime or infrastructure failure; never a model terminal claim | none                          |
+| Intent | Nominal status | Meaning |
+|---|---|---|
+| TASK omitted | 102 | Continue silently, without a receipt or strike for omission |
+| empty, continue, todo | 102 | Continue or recover; an explicit empty inventory is refused with a soft 409 receipt, no strike |
+| wait | 202 | Park when a live obligation or explicit timing exists |
+| complete | 200 | Conclude once execution results permit completion |
+| fail | 499 | End unsuccessfully and cancel unresolved descendant scope |
+| Runtime or infrastructure failure | 5xx | Not a model-authored task status |
 
 ### §waitpid-dispositions The terminal contract (waitpid)
 
-The model signals one intention per turn — **continue (102)**, **done
-(200)**, **wait (202)**, or **give up (499)** — and the engine verifies
-the claim against the loop's live obligations (spawned children, open
-streams, pending retrievals); the grammar polices *shape* only. Asking
-the human is the native `question` EXEC tool ({§question-tool}), not a
+The model may supply one current inventory per turn; its statuses determine
+one intention. Without TASK, an operation-bearing turn continues silently.
+The engine verifies an explicit intention against the loop's actual
+obligations (spawned children, open streams, pending results); the grammar
+polices *shape* only. Asking
+the human is the native `question` executor tool ({§question-tool}), not a
 disposition. The shape rules ARE structural:
 
-- §send-mid-reservation The four labels lex as one `SEND_LABEL` token
-  ({§send-label}), making a label SEND **structurally terminal**: a
-  statement after it is a parse error (the mid-termination rule), and the
-  GBNF spells mid-position SEND recipients as URLs, which no label is.
-  This keeps the grammar's last-SEND model and the dispatcher's
-  first-label model coincident.
-- A **mid** SEND (before the terminal) is comms: a recipient path or
-  none, no label, empty body allowed.
-- §terminal-body-nonempty The GBNF rail requires a non-empty terminal SEND body — a constrained
-  turn cannot end empty-handed. ANTLR remains tolerant during ingestion.
-- §park-202-only The **park** rides `(WAIT)` only: `<T>` (wait up to T minutes),
-  `<T,P>` (adds a poll cadence, mirroring EXEC's slot), `<-1>`
-  (indefinite; the join's own liveness bounds it). See §7 for the
-  GBNF-strict / ANTLR-tolerant split.
-- §no-idle-102 A **zero-statement turn may not conclude `(NEXT)`** — "continue"
-  with nothing submitted is a spin. The GBNF's `tail-0` exits through
-  a terminal trie without the `(NEXT)` tail, so the idle turn (`PLAN`
-  straight into `### SEND0 (NEXT)`) is unemittable; one statement restores
-  the full label set. The other three stay legal bare (a zero-op
-  `(WAIT)` is the engine's obligation check). ANTLR stays tolerant
-  (ingest side). A dispatch-emptied turn — ops emitted but failing
-  downstream validation — survives the rail by nature; the engine's
-  idle-turn 409 backstops that class.
-
-SEND with no `(path)` broadcasts to the default control channel — the
-turn's disposition. SEND with `(path)` directs the message at a
-specific recipient URI (a worker, a stream, a peer).
+- §send-mid-reservation TASK has a reserved token ({§turn-disposition}).
+  A turn admits at most one TASK, anywhere among its operations
+  ({§disposition-anywhere}); the runtime executes it last. A second
+  disposition is a structural error, not a choice between competing outcomes.
+- §disposition-anywhere The disposition may sit anywhere in a model turn
+  (operator, 2026-09-12: models state the plan first; the inventory is a
+  statement about state, not a boundary). `PlurnkParser.parse` admits every
+  operation before and after it in authored order; the runtime defers only the
+  disposition until the other admitted operations settle
+  ({§op-execution-order}). Nothing is dropped and no diagnostic is raised for
+  position. TASK omission does not synthesize a disposition ({§turn-shape}).
+- SEND is communication: an optional recipient path and an optional body.
+- §park-202-only TASK wait intent applies `<T>` (wait up to T minutes),
+  `<T,P>` (adds a poll cadence, mirroring the execution slot), `<-1>`
+  (indefinite; the join's own liveness bounds it). See §7 for the scope
+  slot's shape. Other intents leave timing unapplied
+  with a factual warning; timing does not override the inventory's intent.
+- §inventory-only-turn A TASK-only turn is valid for every inventory intent.
+  Actionable work does not require an invented OP and does not imply parking.
+  Ordinary repetition, strike and execution limits still apply.
+
+SEND with no `(path)` responds to the Active Prompts without ending the turn. SEND with
+`(path)` directs the message to that recipient. Neither changes loop status.
 
 ### §send-body SEND body projection
 
@@ -865,78 +952,42 @@ defines no synthetic scheme or READ-back convention for them.
 
 ## §parser-architecture 10. Parser architecture
 
-`plurnkLexer.g4` owns tokens and modes; `plurnkParser.g4` owns document tiers
-and statement composition; AstBuilder projects parse-tree leaves into the public
-AST. Generated TypeScript targets the `antlr4ng` runtime.
+The implementation this section describes lives in `@plurnk/plurnk-parser`
+({§parser-boundary}); this section remains the contract it implements.
+
+ANTLR owns framing, slots and statement composition; AstBuilder produces the
+schema-owned AST. Registration, effects and authority remain runtime concerns.
 
 ```mermaid
 stateDiagram-v2
     [*] --> DEFAULT
-    DEFAULT --> DEFAULT: whitespace or TEXT
-    DEFAULT --> SLOTS: H1 PLANlane or H2 OPlane
-    SLOTS --> SIGNAL: signal opener
-    SIGNAL --> SLOTS: signal close
-    SLOTS --> TARGET: target opener
-    TARGET --> TARGET: balanced literals / target escapes
-    TARGET --> SLOTS: target close at depth zero
-    SLOTS --> METADATA: metadata opener after target
-    METADATA --> METADATA: balanced inner braces
-    METADATA --> SLOTS: metadata close at depth zero
-    SLOTS --> SLOTS: scope token
-    SLOTS --> SLOTS: trailing annotation
-    SLOTS --> BODY: heading line end
-    BODY --> DEFAULT: same-lane heading boundary
-    BODY --> [*]: end of input
+    DEFAULT --> SLOTS: fenced native OP or executor
+    SLOTS --> TARGET: (
+    TARGET --> SLOTS: )
+    SLOTS --> METADATA: {
+    METADATA --> SLOTS: }
+    SLOTS --> BODY: header newline or tolerated inline body
+    SLOTS --> DEFAULT: matching compact closer
+    BODY --> DEFAULT: matching standalone closer, no nested block
+    BODY --> BODY: nested literal block or other body content
 ```
 
-The first H1 PLAN establishes the turn lane. DEFAULT recognizes only an H1
-PLAN or H2 minted operation carrying that exact lane. SLOTS admits
-operation-appropriate signal, target-with-metadata, and scope openers in any
-order, followed by an optional annotation; the parser grammar enforces
-at-most-once slot multiplicity and keeps repeatable metadata attached to its target.
-Signal submodes select tags, integer,
-or identifier tokens by operation family. TARGET preserves balanced inner
-parentheses and recognized target escapes. BODY emits opaque text until a
-same-lane heading boundary or EOF.
-
-A differently delimited heading stays BODY text. Multi-turn logs are plain
-sequences of independently lane-anchored PLAN turns. Complete native reasoning
-enclosures before PLAN remain one TEXT token so an operation drafted inside
-provider reasoning cannot become the turn anchor.
-
-RecordingListener captures lexer and parser failures; AstBuilder adds visitor
-failures. PlurnkErrorStrategy recovers at structural heading boundaries where
-possible. EOF is a valid body boundary. An unfinished signal, target, or metadata block produces
-`unparsedTail`; no later input is trustworthy.
-
 ## §whitespace-contract 11. Whitespace and interstatement text
 
-| Location                    | Canonical generation                  | Tolerant ANTLR ingestion                                  |
-|-----------------------------|---------------------------------------|-----------------------------------------------------------|
-| Heading marker              | `## PLAN0` or `## OP0` at column zero  | The initial PLAN may directly follow leading TEXT; subsequent headings retain exact depth and column |
-| Between OP and delimiter       | Adjacent                              | Must remain adjacent                                      |
-| Before each modifier        | One ASCII space                       | Zero or more horizontal whitespace characters             |
-| Inside signal               | Adjacent values                       | Horizontal whitespace is ignored; newline is invalid      |
-| Inside target               | Path alias plus target escapes         | Balanced literals tolerated; newline is invalid           |
-| Inside scheme metadata      | Scheme-defined single-line content     | Balanced braces tolerated; newline is invalid              |
-| Inside scope                | Comma-separated numbers               | Dash separator and one post-comma space are also accepted |
-| Before annotation           | One ASCII space                        | Zero or more horizontal whitespace characters             |
-| Inside annotation           | One-line prose padded by one space     | Any single-line text through the first closing `-->`       |
-| Inside body                 | Character-perfect                     | Character-perfect                                         |
-| Between canonical sections  | No empty separator line                | One empty separator line is also admitted                  |
-| Before the first PLAN       | Nothing                               | Whitespace or TEXT may surface as preamble items without requiring a separator before PLAN |
-
-PLURNK never escape-decodes body text: `\n` reaches the owning operation as
-backslash plus `n`. A matcher or executor may interpret those characters under
-its own body dialect. Producers that need a physical newline in literal EDIT
-content emit an actual newline.
-
-`parse` admits TEXT before its PLAN, including without an intervening line
-break, and returns it as ordered text items without assigning semantics. Once
-a heading begins, all nonstructural text belongs to that section body.
-`parseStatements` and `parseClient` admit H2 statements;
-`parseLog` admits consecutive H1 PLAN turns. PLURNK defines no general comment
-syntax; only the trailing heading position gives `<!-- … -->` annotation meaning.
+Body framing removes the header line ending and the single line ending
+immediately before the closing fence. Every other body character is preserved,
+including leading/trailing blank lines, indentation, CRLF and literal
+backslash escapes. A formatter adds its own framing newline even when a body
+already ends in one. Interstatement whitespace belongs to no body.
+
+A header starts at column zero; the first operation may follow provider preamble
+without a separating newline. Text outside operation blocks is ignored in every
+parser tier: before, between, and after operations. It produces no AST item,
+message, receipt, or diagnostic. Exact source remains in `ops:///` under
+{§turn-ops-log-curation}; body bytes and source positions are unchanged. A matching
+closer still ends its body, and no missing closer is inferred. No generic Markdown
+rendering, indentation stripping or recursive code-block extraction occurs.
+Only a header aside has aside semantics.
 
 ## §public-api 12. Public API
 
@@ -945,39 +996,34 @@ and wire types come from generated schemas; the small hand-maintained parser
 types cover ordered parse items and `PlurnkParseError`, which JSON Schema cannot
 express. Consumers never receive ANTLR parse-tree or token types.
 
-§turn-shape `PlurnkParser.parse` accepts exactly one model turn containing at
-least one parsed source operation. Canonical generation may begin with H1 PLAN
-(a SHOULD, never repeated mid-turn) and ends with a label H2 SEND. A turn without
-a PLAN stands as written — no PLAN is synthesized and nothing is diagnosed. When
-no valid terminal SEND was parsed, the parser appends a bodyless `### SEND0 (NEXT)`
-carrying {§parser-position} `UNKNOWN_POSITION` and one exact hard diagnostic
-stating the observed boundary failure and applied default. The source text
-remains unchanged. The GBNF rail takes the same optional PLAN.
-An authored terminal SEND still ends the source turn: a same-lane operation or
-other hard error after it is outside the trustworthy boundary. Tolerated TEXT
-may appear only before the first operation; after that point, nonstructural text
-is section body content. `parseLog` remains strict canonical PLAN-through-SEND
-input, and GBNF remains strict canonical generation.
-
-§document-fence `PlurnkParser.parse` additionally admits one outer Markdown code
-fence whose opening line is exactly ```` ```example ```` (or the earlier ```` ```plurnk ````) and whose closing line,
-when present, is ```` ``` ````. The fence encloses the complete
-model turn and projects neither text nor body content into the AST. Its opener
-commits the document to either that closer or EOF immediately after the turn.
-This is document framing, not another statement grammar, and
-no other parser tier admits it. GBNF continues to shape the paired form.
+§turn-shape `PlurnkParser.parse` accepts one model turn. A turn without any
+operation is reported by one hard diagnostic (`no valid Plurnk operation was
+found.`), which the host may admit as an empty turn rather than reject
+(plurnk-core `§empty-turn`). An explicit disposition may sit anywhere in it
+({§disposition-anywhere}). Omitted TASK
+means silent continuation: no synthesized statement, diagnostic, receipt,
+warning, or strike. The authored operations and source remain unchanged.
+Explicit empty or malformed inventories retain their own handling.
+Unfinished blocks never receive inferred closers.
+Bounded operation errors retain valid siblings. Duplicate dispositions
+and failed document boundaries remain structural failures.
+
+`parseLog` reads consecutive saved turns separated by their dispositions and
+requires their dispositions; a saved turn is stored per turn, so a mid-turn
+disposition never needs splitting. There is no outer Markdown program wrapper;
+the executable blocks themselves are the program.
 
 §tier-entrypoints Each parser entry point owns one document tier:
 
 | Entry point                    | Accepted document                                              | Result statement type |
 |--------------------------------|----------------------------------------------------------------|-----------------------|
-| `PlurnkParser.parse`           | One operation-bearing model turn, bare with optional TEXT or inside one outer `example` (or `plurnk`) fence; omitted PLAN/SEND recover to defaults | `PlurnkStatement`     |
-| `PlurnkParser.parseStatements` | Zero or more protocol statements and hidden whitespace         | `PlurnkStatement`     |
-| `PlurnkParser.parseLog`        | One or more consecutive same-lane PLAN-anchored turns           | `PlurnkStatement`     |
-| `PlurnkParser.parseClient`     | H2 protocol statements plus read-shaped LOOK/BUFF commands      | `ClientStatement`     |
+| `PlurnkParser.parse`           | One operation-bearing model turn; at most one TASK, anywhere | `PlurnkStatement`     |
+| `PlurnkParser.parseStatements` | Zero or more protocol statements                              | `PlurnkStatement`     |
+| `PlurnkParser.parseLog`        | One or more consecutive disposition-ended turns           | `PlurnkStatement`     |
+| `PlurnkParser.parseClient`     | Executable blocks, including the read-shaped LOOK command        | `ClientStatement`     |
 
-Every entry point returns ordered `statement`, `error`, and, where admitted,
-`text` items. When present, {§unparsed-tail-boundary} governs the result's item
+Every entry point ignores outside text under {§whitespace-contract} and returns
+ordered `statement` and `error` items. When present, {§unparsed-tail-boundary} governs the result's item
 extent. The statement `op` field discriminates the generated per-operation
 union.
 
@@ -999,7 +1045,7 @@ following supported consumer values. All other root exports are TypeScript types
 | `InvalidRangeExtentError`             | Typed failure from `Validator.assertRangeExtent`                    | {§range-extent}                             |
 | `Problems`                            | RFC 9457 Problem construction and model projection                  | {§problem-details}, {§problem-projection}   |
 | `PLURNK_OPS`                          | Runtime tuple from which the closed `PlurnkOp` union is derived     | {§canonical-statement}                      |
-| `WORKER_NAME`, `RESERVED_AUTHORITIES` | Authority minting predicate and internal reserved names             | {§worker-name}                              |
+| `WORKER_NAME`                         | Authority minting predicate                                         | {§worker-name}                              |
 | `UNKNOWN_POSITION`                    | Frozen sentinel for an AST statement without retained parsed source | {§parser-position}                          |
 
 §parser-construction-boundary Parser construction components are internal rather
@@ -1242,16 +1288,30 @@ from user-authored prompt content. An adapter may expose no public means to set
 it; Core validates and records it through the same prompt admission path.
 
 §application-worker-observation Worker observation exposes durable identity,
-origin, and immediate parent identity. `readWorker` resolves exactly one id or
-name and returns `null` when absent. `listWorkers` filters collections by origin
-or lineage position; an omitted parent filter means every position and an
-explicit `null` means roots. Singular and plural cardinalities are distinct
-contracts. Observation is not a client binding or permission grant.
+origin, immediate parent identity, minted `kind` (`conversation`; `fork` for a
+child carrying a fork boundary; `work` for any other child), and `lifecycle`,
+the worker's latest work loop projected through {§loop-lifecycle-vocabulary} (`idle`
+when it has none). Maintenance-only loops do not change this projection;
+their ordinary turns and results remain durable history. `readWorker` resolves exactly one id or name and returns
+`null` when absent. `listWorkers` filters collections by origin or lineage
+position; an omitted parent filter means every position and an explicit `null`
+means roots. Singular and plural cardinalities are distinct contracts.
+Observation is not a client binding or permission grant; a client renders kind
+and lifecycle, it never infers them.
+
+§loop-lifecycle-vocabulary One projection maps a loop's durable status onto the
+lifecycle words every client renders, shared by the status gauge and the worker
+directory: no loop `idle`; 100 `queued`; 102 `running`; 202 `parked`; 200
+`completed`; any status of 400 or more `failed` (413 budget, 429 turn ceiling,
+499 cancel, 500 fail, 504 execution timeout, 508 runaway). `lifecycleOfLoopStatus`
+in `@plurnk/plurnk-contracts` is that projection's one owner.
 
 §application-loop-observation Loop observation exposes the durable scheduler
-state, exact terminal `OperationResult`, and exact count of packet-bearing
+state of work loops (excluding maintenance-only administrative loops), exact terminal `OperationResult`, and exact count of packet-bearing
 Turns for one owned Worker. Packetless producer Turns and physical provider
-retries do not contribute to `packetCount`. Exterior
+retries do not contribute to `packetCount`. Scheduled tasks expose `scheduledAt`
+(ISO date), optional `intervalMinutes`, and `recurrenceId` (the original task id).
+Packet notifications carry the same timing; ordinary tasks omit it. Exterior
 adapters consume this projection instead of reconstructing lifecycle from
 events or persistence; events remain the live notification edge.
 
@@ -1270,13 +1330,14 @@ class PlurnkParseError extends Error {
     readonly column: number;
     readonly source: ErrorSource;
     readonly severity: Severity;
+    readonly code?: "invalid-turn-structure";
 }
 ```
 
 §parser-position Parser source locations are points, not text regions. An AST
-statement's `position` identifies the first `#` of its heading; a diagnostic
-identifies the offending or recovery point; a text item and `unparsedTail.from`
-identify the first point at which that item or undefined tail begins. A
+statement's `position` identifies the first backtick of its header; a diagnostic
+identifies the offending or recovery point; `unparsedTail.from` identifies where
+the undefined tail begins. A
 statement constructed without retained parsed source uses `UNKNOWN_POSITION`,
 the unknown sentinel; its dispatch origin remains a separate fact.
 
@@ -1307,46 +1368,86 @@ and 3.30.2](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html).
 the sole and complete owner of syntax-error messaging because it holds the
 parse state, lexer mode, and expected-token set that no consumer has. It
 produces the final diagnostic message, deduplicated expected-token lists, and
-turn-shape diagnostics. No valid leading PLAN yields ``No valid leading PLAN
-was parsed; an empty `## PLAN0` was used.``; no valid terminal SEND yields ``No
-valid terminal SEND was parsed; `### SEND0 (NEXT)` was used.``; source with no
+turn-shape diagnostics ({§turn-shape}). Omitted TASK produces no diagnostic, and
+neither does the position of a present one ({§disposition-anywhere}). A failed
+document boundary carries `code: "invalid-turn-structure"`, which cannot be
+recovered as an individual failed operation. Source with no
 parsed operation yields `no valid Plurnk operation was found.` Targeted
 diagnostics are:
 
-- §matcher-body-redirect **Matcher body in the slot region.** When the
-  post-target modifier region begins with `$`, `~`, or `@` with no whitespace
-  before it, the lexer redirects the unambiguous matcher to body content below the
-  OP heading instead of returning the generic slot list (after whitespace it is
-  already the inline body, {§heading-inline-body}). Slash-led regex and XPath are
-  excluded because `/` can be target data.
-- §bare-target-redirect **A `(target)` on BARE.** BARE takes no `(path)`; a model that
-  writes its prompt, or the prompt's address, into a parenthesized slot (`### BARE0
-  (What day is it?)`, `### BARE0 (prompt:///1/1)`) is told that the prompt is the body
-  line beneath the heading, with the heading's own opener, instead of the generic
-  slot list. Two operator sessions on 2026-08-26 produced exactly these shapes.
-- §combined-anchor-line-redirect **Combined anchor and line number in a scope.**
-  A text-coordinate scope containing `@hash:L` or `@hash L` is one bounded hard
-  error: `a scope position accepts one line coordinate; use the \`@hash\` anchor
-  without its displayed line number`. A malformed header scope is consumed as
-  one token at either COPY/MOVE operand; neither produces a punctuation cascade.
+- §inline-flag-tolerance **PCRE inline modifiers.** A regex whose pattern opens with
+  `(?i)`, `(?m)`, `(?s)` or a combination — the pretrained spelling of a flag, which
+  ECMAScript refuses as an invalid group — is read with those letters lifted into
+  its flags (`/(?i)shutdown|reactor/` is `/shutdown|reactor/i`; `^(?i)note:` is the
+  anchored regex with `i`), with one warning-severity advisory naming the flag
+  position after the closing `/`. Only a leading group of `i`, `m` and `s` lifts;
+  `(?i:…)` scoped modifiers are valid ECMAScript and pass through untouched. From
+  the 2026-09-13 dumbox demo pass, where the model wrote the inline form, was
+  refused, and rewrote it as a trailing flag one turn later.
+- §regex-trailing-text A valid `/pattern/flags` prefix followed by horizontal
+  whitespace and trailing text receives one concise trailing-content
+  diagnostic, with or without flags, without assuming what the extra text was
+  intended to represent. Invalid patterns or flags retain the native
+  regex failure; no branch silently removes or executes trailing content.
+- §naked-pattern **The matcher rides the heading bare.** After the path, and any
+  scope or option block, the rest of a FIND, READ or KILL heading line is the
+  matcher, in whichever dialect its first characters claim
+  ({§matcher-prefix-claims}): `/re/i`, `^anchored`, `//xpath`, `$.json`, `~words`,
+  `&symbol`, or a sigil-less glob or literal such as `TODO` or `*.ts`. Those
+  operations take no body, so heading-line text can mean nothing else. On EDIT only
+  a sigil lifts, because plain heading-line text is the replacement body it always
+  was; the lines beneath the heading are then the replacement, and none deletes each
+  match ({§edit-pattern}). A trailing `<!-- aside -->` on the same line stays the
+  aside. The lift is exactly what `[{"pattern": "…"}]` produces, and that option
+  remains the escape for a matcher the heading cannot hold bare: one opening with
+  `(`, `<`, `[` or a backtick, one containing `<!--`, and every COPY/MOVE operand.
+  `FIND (src/parser.ts) /\bparse\w+\b/` is the same operation as
+  `FIND (src/parser.ts) [{"pattern": "/\\bparse\\w+\\b/"}]`. `^` claims the regex
+  dialect without slashes or flags: the whole text is the pattern, so
+  `READ (reasoning:///1/1) ^NOTE:.*` selects a turn's note lines (operator,
+  2026-09-12: "Recursive Reasoning").
+- §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
+  trailing `[option block]` that parses as an array of objects come off the right end in
+  any order, each taken once and only when the heading did not already carry that slot,
+  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
+  (operator, 2026-09-13: "swallow up anything that passes as legitimate plurnk"; the
+  2026-09-13 dumbox run refused three headings for this in one turn). A matcher that
+  itself ends in one of those shapes takes the option escape.
+- §matcher-body-redirect **A body beneath those headings.** Text below the heading
+  of a FIND, READ or 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.`), delivered like {§misplaced-aside-advisory} as a
+  `parse_advisory` notice (operator, 2026-09-12: a gentle warning, never an error
+  the model must recover from). 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.
+- §combined-anchor-tolerance **Combined anchor and line number in a scope.** A
+  text-coordinate scope position written `@hash:L` or `@hash L` is the displayed
+  `@abcde 42:` prefix copied whole (a koota-entity turn refused nine of them in a
+  row, 2026-09-12): the position is the anchor, the number is dropped, and one
+  warning-severity advisory names the anchor-only form. The scope lexes as one
+  ordinary marker at any text-coordinate operation, either COPY/MOVE operand
+  included; nothing cascades.
 - §invalid-scope-diagnostic **Malformed scope content.** After a properly spaced
   scope opener, report the offending scope (at most 64 code points, ending at
   `>` or the heading's line end) and its operation's constraint: FIND result
-  positions, EXEC/WAIT minutes, text coordinates, or no scope. Do not append advice for
+  positions, execution/TASK minutes, text coordinates, or no scope. Do not append advice for
   other operations or infer why the producer supplied the value. Spacing and
   boundary-loss diagnostics retain their own contracts.
-- §label-recipient-redirect **A label beside a recipient.** `### SEND0 (TERM)
-  (worker://parent)` and `### SEND0 (worker://parent) (TERM)` are one parser error at
-  the heading: `a (NEXT|WAIT|TERM|FAIL) SEND names no recipient; message a recipient
-  with its own SEND first` ({§send-label}).
-- §misplaced-annotation-advisory **Annotation in the body.** A READ or FIND whose
+- §misplaced-aside-advisory **Aside in the body.** A READ or FIND whose
   body is solely an HTML comment (`<!-- … -->`) can never carry a matcher: it is
-  the annotation the model put on the line below the heading. The builder takes
-  the comment as the annotation when the heading has none, builds the operation
+  the aside the model put on the line below the heading. The builder takes
+  the comment as the aside when the heading has none, builds the operation
   with no body, and raises one warning-severity advisory stating that observed
   normalization; the parser places the advisory right after its statement and
   the service delivers it as a `parse_advisory` notice with its position. A body
-  with any other content is a matcher, as before.
+  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:
@@ -1358,18 +1459,20 @@ provide:
 | 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.        |
 
-All messages use PLURNK protocol vocabulary: heading, lane, signal, target,
+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.
+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`
-- `unrecognized character ':' in signal`
+- `unexpected bracket modifier; the fence name selects the executor`
 - `unrecognized character 'X' in statement header`
-- `a turn must begin with \`## PLAN0\``
+- `TASK's body begins below the header`
 - `expected ')'; got ':'`
 
 Each malformed statement produces at most one hard error. The first recorded
@@ -1380,8 +1483,9 @@ Independent malformed statements each retain one hard error. Advisories remain
 separate because they do not represent failed admission.
 
 §unparsed-tail-boundary When the lexer cannot determine where a malformed
-statement ends, the result's `unparsedTail` marks the position from which
-parsing gave up. `ParseResult.items` contains only facts that begin strictly
+statement ends — an unfinished `(target` or `[metadata` slot on a heading line —
+the result's `unparsedTail` marks the position from which parsing gave up. A block
+without a closer is not such a case: it ends under {§closer-fallback}. `ParseResult.items` contains only facts that begin strictly
 before that point; recovered contexts and diagnostics at or beyond it are not
 public results. The tail is one separate boundary fact, not an additional
 malformed-statement diagnostic. Consumers must treat anything from that point
@@ -1404,6 +1508,6 @@ runtime constructs this; the parser provides the fields):
     "column": 12,
     "source": "parser",
     "severity": "error",
-    "message": "target slot of `### READ0` opened at line 1 but never closed - add `)`"
+    "message": "READ block opened at line 1 but was not closed with 3 backticks"
 }
 ```