@plurnk/plurnk-contracts 1.10.1 → 1.12.0

package/README.md

@@ -49,12 +49,11 @@ The parser entry points deliberately accept different document tiers:
 
 | Entry point                    | Accepted input                                        |
 |--------------------------------|-------------------------------------------------------|
-| `PlurnkParser.parse`           | One PLAN-anchored model turn ending in terminal SEND  |
+| `PlurnkParser.parse`           | One operation-bearing model turn; omitted PLAN/SEND are recovered |
 | `PlurnkParser.parseStatements` | A strict sequence of protocol statements              |
-| `PlurnkParser.parseLog`        | TURN-wrapped multi-turn script or log input           |
+| `PlurnkParser.parseLog`        | Strict consecutive PLAN-through-SEND turns            |
 | `PlurnkParser.parseClient`     | Protocol statements plus client-only LOOK and BUFF    |
 | `parsePath`                    | One path or URI using parser-equivalent decomposition |
-| `parseResourceSelection`       | One COPY/MOVE destination and optional text scope     |
 
 See SPEC {§turn-shape} and {§tier-entrypoints} for the tier boundaries. All
 AST, parse-result, schema-derived, and runtime-neutral wire types are exported

package/SPEC.md

@@ -9,7 +9,7 @@ is the single code API for those contracts.
 | Surface                                                                         | Canonical export or artifact                        |
 | ------------------------------------------------------------------------------- | --------------------------------------------------- |
 | Parser, AST, validators, Problems, results, Notices, text regions and extents   | `@plurnk/plurnk-contracts`                          |
-| Effective loop policy and its default                                           | `LoopFlags`, `DEFAULT_LOOP_FLAGS`                   |
+| Capability and loop policies with their defaults                                | `CapabilityPolicy`, `LoopPolicy`, `DEFAULT_CAPABILITY_POLICY`, `DEFAULT_LOOP_POLICY` |
 | Durable reasoning intent                                                        | `ReasoningPolicy`, `REASONING_POLICIES`             |
 | Model route and catalog discovery                                               | `ModelRoute`, `ModelCatalogQuery`, `ModelCatalogPage`, `ModelReadiness` |
 | Stopped-world client contract                                                   | `ProposalDisposition`, `ProposalProjection`         |
@@ -125,15 +125,45 @@ The schemas own the runtime-neutral shapes; core owns their stateful values.
 
 | Contract                  | Shape invariant                                                                 | Runtime responsibility                                                                 |
 | ------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
-| `LoopFlags`               | Complete effective `mode`, `auto`, `noWeb`, `noInteraction`, and `noProposals`  | Validate/expand persisted partial policy before use                                    |
+| `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 |
 | `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 flags, stale signal, disposition | Derive one validated projection for live delivery and durable reconnect discovery |
+| `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                        |
 | `ProviderCost`            | Exact charged, estimated, or unknown monetary evidence                           | Normalize one monetary disposition for each physical provider request                    |
 | `ProviderRequestAccounting` | Usage and cost evidence for one physical provider request                      | Preserve request order across retries, failover, success, and failure                    |
 | `ProviderAccounting`      | Ordered requests plus deterministic usage and exact-USD projections              | Derive loop, protocol, telemetry, and client reporting without a second authority        |
 
-`DEFAULT_LOOP_FLAGS` is the contracts-owned effective default value. A consumer may persist a partial object as an implementation detail, but it never exposes or acts on that partial representation as though it were the complete contract.
+§capability-policy-matching A selector is an exact conjunction: every field it
+declares must equal the descriptor, while every selected `trait` must occur in
+the descriptor's trait set. `deny` wins within a layer. When `only` is present, at
+least one selector must match. An empty policy admits everything and an empty
+`only` list admits nothing.
+
+§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
+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, OPEN, FOLD, log KILL, 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.
+
+§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
+admission precedes effect classification and proposal settlement.
 
 §reasoning-policy-wire `ReasoningPolicy` is exactly `off | adaptive | low |
 medium | high`. The schema owns this shared wire vocabulary. Providers own the
@@ -167,11 +197,12 @@ facts; core and client interfaces carry only this standard interaction.
 §provider-usage `ProviderUsage` records only known non-negative safe-integer
 quantities. `inputTokens` includes every input category; cache reads and cache
 writes are details within it. `outputTokens` includes reasoning; text and
-reasoning are details within it. `totalTokens` equals input plus output whenever
-all three are present. A detail is no greater than its containing total, and a
-complete detail partition sums to that total. An omitted field is unknown; an
-explicit zero is provider evidence or an exact derivation from complete known
-components. Consumers never estimate a token category from text length.
+reasoning are details within it. Within one physical request, `totalTokens`
+equals input plus output whenever all three are present, a detail is no greater
+than its containing total, and a complete detail partition sums to that total.
+An omitted field is unknown; an explicit zero is provider evidence or an exact
+derivation from complete known components. Consumers never estimate a token
+category from text length.
 
 §provider-cost `ProviderCost` represents one physical provider request's
 monetary disposition. `charged` preserves a provider-reported canonical decimal
@@ -189,11 +220,14 @@ capacity failover; a later response never replaces an earlier request.
 
 §provider-accounting `ProviderAccounting.requests` is the source evidence.
 `usage` and `costUsd` are deterministic projections of that ordered set, not
-independent inputs. Each usage field is present only when every contributing
-request has that field known; the empty set totals to explicit zero. `costUsd`
-is the exact decimal sum only when every request is expressible in USD and is
-`null` otherwise. Consumers do not recompute provider rates or convert
-currencies while reading the projection.
+independent inputs. Each usage field sums the requests that report that exact
+quantity; an unreported quantity is skipped rather than invented as zero or
+allowed to erase known evidence. Detail fields are likewise independent sums,
+so heterogeneous request telemetry never implies a complete aggregate
+partition merely because their reported keys overlap. `costUsd` sums every
+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
 trustworthy statement boundary when possible and sets `unparsedTail` when a
@@ -305,6 +339,7 @@ under {§plan-value}.
 | `delimiter`     | Heading lane, joined directly to PLAN or OP                                |
 | `[signal]`   | Optional operation-specific signal, preceded by one space                  |
 | `(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                                               |
@@ -318,21 +353,25 @@ The following constraints are structural:
   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.
+- 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
-scope, then annotation, with one ASCII space before every present slot. Slot delimiters make
+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 slots admitted by that operation, at most once each. Accepted spacing and
-permutation are not second canonical spellings.
+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 `<`) — is the first body line: `## EXEC0 [crm] (crm_query) {"soql": "…"}` and
+`(`, 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
@@ -348,14 +387,24 @@ 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 → scope order                      |
+| 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 |
-| PLAN modifiers or a non-`0` lane                  | Model canon keeps PLAN slotless and uses lane `0`                   |
+| 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   |
@@ -368,6 +417,7 @@ or safely execute understandable input:
 | `delimiter`    | `[A-Za-z0-9_]*`, adjacent to PLAN or OP                            |
 | `[signal]`  | Operation-specific tags, identifier, branch, or integer            |
 | `(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        |
@@ -383,14 +433,14 @@ governed by {§canonical-statement}; runtime conditions remain explicit below.
 | FIND | optional add log tags         | required target or glob                      | optional result range           | optional matcher               |
 | READ | optional add log tags         | required target                              | optional text region            | empty                          |
 | EDIT | optional add log tags         | required file or entry                       | required for an existing target | literal text                   |
-| COPY | optional add log tags         | required source                              | optional source region          | required destination selection |
-| MOVE | optional add log tags         | required source                              | optional source region          | required destination selection |
+| COPY | optional add log tags         | required source and destination              | optional region after each path | empty                          |
+| MOVE | optional add log tags         | required source and destination              | optional region after each path | empty                          |
 | FOLD | optional filter/change tags   | optional log selection                       | optional log-body line scope    | optional matcher               |
 | OPEN | optional filter/change tags   | optional log selection                       | optional log-body line scope    | optional matcher               |
 | EXEC | optional executor             | optional local working path                  | optional timeout, poll          | optional executor input        |
 | BARE | optional add log tags         | none                                         | none                            | required prompt                |
-| WORK | optional Git branch           | required fresh `worker://name`               | none                            | required prompt                |
-| FORK | optional Git branch           | required context-inheriting `worker://name`  | none                            | required prompt                |
+| WORK | optional Git branch (refused unless the service enables branch delegation) | required fresh `worker://name`               | none                            | required prompt                |
+| FORK | optional Git branch (refused unless the service enables branch delegation) | required context-inheriting `worker://name`  | none                            | required prompt                |
 | KILL | optional target-specific code | required target, including a log item        | none                            | empty                          |
 | SEND | optional target-specific code | optional recipient                           | optional timeout, poll          | message; terminal is nonempty  |
 
@@ -400,10 +450,10 @@ 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 complete Plurnk Plan.** Its entries are the
-model's current working-memory inventory: durable findings are `memory`, finished
-actions are `completed`, open inquiries are `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
+§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
@@ -411,10 +461,11 @@ the canonical bare array: every entry has string `content` and `status` in
 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 completely replaces the current Plan; it never expresses a
-delta. 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
+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.
 
@@ -432,7 +483,7 @@ commit `272bf799f35a258c6a4107a0410ed361e83683d3`.
 
 §exec-tag-signal EXEC's bracket slot names its runtime. A bracket whose first character is
 a sign is a tag signal instead — a runtime never starts with `+` or `-` — so
-`## EXEC0 [+fetch] (.)` and `## EXEC0 [crm] [+schema] (crm_describe)` admit: the tags
+`## EXEC0 [+fetch]` and `## EXEC0 [crm] [+schema] (crm_describe)` admit: the tags
 classify the log row exactly as on FIND or READ, the runtime is the explicit one or the
 default shell, and each slot appears at most once.
 
@@ -498,7 +549,7 @@ Mutation semantics:
 - An empty body deletes the selected text.
 - `<0>` prepends and `<-1>` appends.
 - `<SL,SC,EL,EC>` deletes the exact exclusive-end region and inserts the body at its start.
-- §destination-scope-boundary COPY and MOVE parse the body as a destination `ResourceSelection`: a target plus an optional destination scope. A destination scope is final body content; a scope-shaped suffix followed by residue before the section boundary is rejected rather than reinterpreted as target data. Scope-shaped text elsewhere remains target data, and a URL requiring the reserved terminal spelling percent-encodes its angle brackets. Header target, fragment, and scope independently select the source resource, channel, and region.
+- §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.
 
 ### §operation-observation Per-operation observations
 
@@ -549,7 +600,6 @@ and path globs share the slot; content matchers belong in the body.
 | `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  |
-| Trailing `{key: value}` | Removed before URL parsing and preserved as ordered `headers` pairs | Addressed scheme interprets request metadata         |
 | `?query`                | Preserved as ordered `UrlPath.query`; `null` = absent, `""` = `?`   | Participates in scheme resource identity             |
 
 AstBuilder recognizes a URL with the case-insensitive prefix
@@ -591,15 +641,6 @@ never target content. Glob metacharacters remain legal path data.
 
 Matching and folder-scope semantics remain runtime concerns.
 
-§path-request-metadata A scheme URL may append one or more
-`{key: value}` request-metadata blocks. AstBuilder removes the blocks before
-WHATWG decomposition and preserves them as ordered pairs so order and duplicate
-names survive. Local paths retain braces as ordinary path text. Scheme handlers,
-not the language parser, define the meaning and authorization of the metadata.
-The admitted AST retains exact values for execution; malformed-metadata visitor
-diagnostics identify only the structural fault and source position, never quote
-metadata contents or a native URL parser's input-bearing diagnostic.
-
 §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
@@ -611,26 +652,49 @@ ingestion restriction: the parser decomposes arbitrary URL authorities.
 
 ## §matcher-prefix-claims 6. Bulk pattern matching
 
-FIND, OPEN, FOLD, and authored READ 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
+FIND, authored READ, OPEN, FOLD, 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.
 
+- §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
+  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>)`)
+  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.
+- §tag-slot-tolerance A tag written as a path ahead of the real path (`## READ0 (+diff) (a.ts)`)
+  is read as `[+diff] (a.ts)` — the rewrite keeps the heading's length, so every later position
+  stays true — and the slip is one error-severity diagnostic at the first paren, placed right
+  after its statement, stating the `[+diff]` correction and that it was used. The statement
+  runs with the tag. A heading that already carries a signal is not rewritten: its second path
+  slot is blamed at the first paren and the statement is dropped.
+
 | Prefix    | Dialect  | Canonical body                       | Typed admission                   | Runtime owner       |
 |-----------|----------|--------------------------------------|-----------------------------------|---------------------|
 | `//`      | XPath    | `//selector`                         | XPath 1.0 `xpath.parse()`         | Mimetype projection |
 | `/`       | Regex    | `/pattern/flags`                     | ECMAScript `RegExp` construction  | Mimetype projection |
 | `$`       | JSONPath | RFC 9535 expression                  | `json-p3` compilation             | Mimetype projection |
 | `~`       | Semantic | `~phrase`                            | Any text after the prefix         | Embedding index     |
-| `@`       | Graph    | `@symbol`, `@<symbol`, or `@>symbol` | Direction and symbol preserved    | Symbol index        |
-| none      | Glob     | Shell glob or literal text           | Raw string                        | Mimetype projection |
+| `&`       | 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 and graph matchers require no parse step. Scope carries semantic
+Semantic matchers require no parse step. 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.
 
 AstBuilder validation is compile-only and never evaluates a document. Matcher
@@ -638,11 +702,10 @@ evaluation belongs to the runtime's selected mimetype, embedding, 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 The GBNF rail permits only single-line matcher
-  bodies. A regex that matches a newline uses the two-character `\n` escape.
-  ANTLR preserves the complete section body; the same-lane heading boundary
-  keeps every following statement independently parseable without a matcher-
-  specific implicit close rule.
+- §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.
@@ -665,7 +728,7 @@ 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                      |
 | OPEN / FOLD           | 0/1/2 body-relative line coordinates   | Whole log body when absent; one physical line or inclusive range when present |
-| EXEC                  | `timeout[,poll]`                       | Spawn lifetime bound and poll cadence in seconds                           |
+| EXEC                  | `timeout[,poll]`                       | Spawn lifetime bound and poll cadence in minutes                           |
 | Terminal SEND `[202]` | `timeout[,poll]`                       | Bounded or indefinite wait and optional poll cadence                       |
 
 Text coordinates use the algebra in {§text-scope-semantics}: one integer is a
@@ -775,7 +838,7 @@ disposition. The shape rules ARE structural:
   non-disposition code, targeted or pathless, 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 `[202]` only: `<T>` (wait up to T seconds),
+- §park-202-only The **park** rides `[202]` 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.
@@ -817,6 +880,9 @@ stateDiagram-v2
     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
@@ -826,8 +892,9 @@ stateDiagram-v2
 
 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, and scope openers in any order, followed
-by an optional annotation; the parser grammar enforces at-most-once multiplicity.
+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
@@ -840,7 +907,7 @@ 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 or target produces
+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
@@ -849,9 +916,10 @@ possible. EOF is a valid body boundary. An unfinished signal or target produces
 |-----------------------------|---------------------------------------|-----------------------------------------------------------|
 | 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 header slot     | One ASCII space                       | Zero or more horizontal whitespace characters             |
+| 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 `-->`       |
@@ -878,25 +946,33 @@ 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. H1 PLAN is the
-first operation, a disposition-coded H2 SEND is the terminal operation, and PLAN
-cannot recur mid-turn. Tolerated TEXT may appear only before PLAN; after PLAN,
-nonstructural text is section body content. Missing either anchor or placing a
-same-lane operation after the terminal SEND is an error.
+§turn-shape `PlurnkParser.parse` accepts exactly one model turn containing at
+least one parsed source operation. Canonical generation begins with H1 PLAN,
+ends with a disposition-coded H2 SEND, and never repeats PLAN mid-turn. When no
+valid leading PLAN was parsed, the parser prepends an empty PLAN; when no valid
+terminal SEND was parsed, it appends a bodyless `SEND [102]`. Either default
+carries {§parser-position} `UNKNOWN_POSITION` and one exact hard diagnostic
+stating the observed boundary failure and applied default. The source text
+remains unchanged.
+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 ```` ```plurnk ```` and whose closing line,
 when present, is ```` ``` ````. The fence encloses the complete
-PLAN-through-SEND 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 complete turn. This is document framing, not another statement grammar, and
+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.
 
 §tier-entrypoints Each parser entry point owns one document tier:
 
 | Entry point                    | Accepted document                                              | Result statement type |
 |--------------------------------|----------------------------------------------------------------|-----------------------|
-| `PlurnkParser.parse`           | One PLAN turn: bare with optional TEXT, or outer `plurnk` fence ending at its closer or EOF | `PlurnkStatement`     |
+| `PlurnkParser.parse`           | One operation-bearing model turn, bare with optional TEXT or inside one outer `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`     |
@@ -913,15 +989,16 @@ following supported consumer values. All other root exports are TypeScript types
 |---------------------------------------|---------------------------------------------------------------------|---------------------------------------------|
 | `PlurnkParser`                        | Four document-tier entry points listed above                        | {§parser-architecture}, {§tier-entrypoints} |
 | `PlurnkParseError`                    | JSON-serializable positioned parser diagnostic                      | {§parse-diagnostics}                        |
-| `parsePath`, `parseResourceSelection` | Parser-equivalent target and COPY/MOVE destination admission        | {§path-syntax}, {§tier-entrypoints}         |
+| `parsePath`                           | Parser-equivalent target admission                                   | {§path-syntax}, {§tier-entrypoints}         |
 | `PathSyntax`                          | Target-slot spelling and exact-versus-glob classification           | {§path-parentheses}, {§path-glob}           |
 | `Validator`                           | Validation and assertion against the owning JSON Schemas            | {§wire-entrypoint}                          |
 | `InvalidNoticeError`                  | Typed failure from `Validator.assertNotice`                         | {§notice}                                   |
 | `InvalidProblemDetailsError`          | Typed failure from `Validator.assertProblemDetails`                 | {§problem-details}                          |
+| `InvalidProblemProjectionError`       | Typed failure from `Validator.assertProblemProjection`              | {§problem-projection}                       |
 | `InvalidOperationResultError`         | Typed failure from `Validator.assertOperationResult`                | {§operation-result}                         |
 | `InvalidTextRegionError`              | Typed failure from `Validator.assertTextRegion`                     | {§text-region}                              |
 | `InvalidRangeExtentError`             | Typed failure from `Validator.assertRangeExtent`                    | {§range-extent}                             |
-| `Problems`                            | RFC 9457 Problem construction                                       | {§problem-details}                          |
+| `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}                              |
 | `UNKNOWN_POSITION`                    | Frozen sentinel for an AST statement without retained parsed source | {§parser-position}                          |
@@ -931,7 +1008,7 @@ than alternate consumer entry points:
 
 | Internal component                         | Boundary                                                                                                      |
 |--------------------------------------------|---------------------------------------------------------------------------------------------------------------|
-| `AstBuilder`                               | Consumes generated ANTLR contexts; `PlurnkParser`, `parsePath`, and `parseResourceSelection` own its API      |
+| `AstBuilder`                               | Consumes generated ANTLR contexts; `PlurnkParser` and `parsePath` own its API                                |
 | `PlurnkErrorStrategy`, `RecordingListener` | Assemble parser recovery and diagnostics around `antlr4ng`; consumers receive `PlurnkParseError` values       |
 | `Jsonplurnk` test helper                   | Independently checks the Core-owned {§jsonplurnk} renderer corpus; it is neither shipped code nor a root API  |
 
@@ -1063,6 +1140,20 @@ Internal invariant violations throw and preserve their cause. An external
 protocol may require its own error envelope; its adapter maps that envelope to
 or from the canonical Problem without creating another PLURNK failure contract.
 
+§problem-projection `ProblemProjection` is the sole compact model-packet view of
+an exact `ProblemDetails`. `Problems.project(problem, context)` validates both
+representations and rejects a status that contradicts the enclosing row.
+
+| Projection member | Contract |
+|-------------------|----------|
+| `type`, `detail` | Always retained; together they identify the stable class and occurrence-specific cause |
+| `stage`, `recovery`, `retryable`, extensions | Retained only when present and not exactly duplicated by the enclosing row |
+| `title`, `status`, `instance` | Forbidden; the exact Problem owns stable title and occurrence identity while the enclosing packet row already owns model-facing status and address |
+
+Projection never mutates or replaces the exact Problem. Durable storage,
+external protocols, clients, and forensic artifacts continue to receive the
+complete RFC 9457 object.
+
 ### 13.6 Notices
 
 §notice A `Notice` is a transient, nonterminal observation. It cannot determine durable
@@ -1214,9 +1305,12 @@ and 3.30.2](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html).
 `severity` distinguishes a hard error from a non-fatal advisory. The parser is
 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,
-turn-shape imperatives (begin with `# PLAN0`, end with a terminal
-`## SEND0 [code]`), and these targeted diagnostics:
+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 [102]` was used.``; source with no
+parsed operation yields `no valid Plurnk operation was found.` Targeted
+diagnostics are:
 
 - §signal-scope-redirect **EXEC scope in the signal slot.** When EXEC's
   `[signal]` slot (executor-ident mode) hits a leading `-` or digit —
@@ -1225,17 +1319,21 @@ turn-shape imperatives (begin with `# PLAN0`, end with a terminal
   `## EXEC0 <-1,300>`” instead of a raw `unrecognized character`. The redirect is
   EXEC-scoped because its signal mode is exclusive; SEND/KILL are untouched.
 - §matcher-body-redirect **Matcher body in the slot region.** When the
-  post-target header region begins with `$`, `~`, or `@` with no whitespace
+  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, while a COPY/MOVE destination selection fails at its visitor
-  boundary; neither produces a punctuation cascade.
+  one token at either COPY/MOVE operand; neither produces a punctuation cascade.
 - §misplaced-target-advisory **Mutation target in the signal slot.** When a
   mutating op (EDIT/COPY/MOVE) parses with a null `(target)` and a path-shaped
   `[signal]` element (a `/` or a dotted extension), the message redirects the
@@ -1243,15 +1341,22 @@ turn-shape imperatives (begin with `# PLAN0`, end with a terminal
   \`[…]\` tag slot; a target goes in \`(…)\`. Try \`## EDIT0 (path)\``). It is
   gated on a path-shaped signal so a genuine additive-tag signal is not mis-steered
   toward a path it lacks.
+- §matcher-in-signal-slot **Matcher in the signal slot.** A tag term whose name
+  begins with a matcher prefix (`/`, `$`, `~`, `&`) is never a tag: `## FIND0
+  [/require/] (**.go)` used to apply a folksonomic tag named `/require/` and
+  return unsearched rows. The canonicalizer refuses the term, so the builder
+  raises one heading-positioned error naming the body rule (`` `[/require/]` is not
+  a tag - a matcher belongs in the body beneath the heading; `[+tag]` adds,
+  `[tag]` filters ``); the statement drops and its siblings run. Matcher
+  characters inside a name (`slash/inside`) stay legal.
 - §misplaced-annotation-advisory **Annotation 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
-  with no body, and raises one warning-severity advisory naming what happened
-  and the correct form (`## READ0 (…) <…> <!-- … -->`); 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 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.
 
 §error-shape The diagnostic class determines how much guidance the parser may
 provide: