@plurnk/plurnk-contracts 1.4.0 → 1.6.0

package/SPEC.md

@@ -8,18 +8,26 @@ is the single code API for those contracts.
 
 | Surface                                                                         | Canonical export or artifact                        |
 | ------------------------------------------------------------------------------- | --------------------------------------------------- |
-| Parser, AST, validators, Problems, results, Notices, text regions               | `@plurnk/plurnk-contracts`                          |
+| Parser, AST, validators, Problems, results, Notices, text regions and extents   | `@plurnk/plurnk-contracts`                          |
 | Effective loop policy and its default                                           | `LoopFlags`, `DEFAULT_LOOP_FLAGS`                   |
 | Stopped-world client contract                                                   | `ProposalDisposition`, `ProposalProjection`         |
 | Client capability presentation                                                 | `ClientDisplayCapabilities`                         |
 | JSON Schemas                                                                    | `@plurnk/plurnk-contracts/schema/*.json`            |
-| Local-model rail                                                                | `@plurnk/plurnk-contracts/plurnk.gbnf`              |
+| 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.
 
+§json-result-rendering `renderJsonResult` is the one presentation serializer
+for generated JSON operation results. 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.
+
 ## §contract-layers 1.1 Contract layers and admission boundary
 
 PLURNK uses one contract with deliberately different projections. A tolerant
@@ -30,7 +38,7 @@ semantics valid.
 ```mermaid
 flowchart LR
     canon["Canonical model teaching<br/>plurnk.md"]
-    rail["Optional raw generation rail<br/>plurnk.gbnf"]
+    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"]
@@ -47,8 +55,8 @@ 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, statement shape, slot shape, and body fencing        |
+| 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    |
 | 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   |
@@ -72,17 +80,43 @@ The schemas own the runtime-neutral shapes; core owns their stateful values.
 | `LoopFlags`               | Complete effective `mode`, `auto`, `noWeb`, `noInteraction`, and `noProposals`  | Validate/expand persisted partial policy before use                                    |
 | `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, review target/body/attrs, effective flags, stale signal, disposition  | Derive one validated projection for live delivery and durable reconnect discovery      |
-| `ProviderCost`            | Discriminated authoritative, estimated, free, or unknown monetary evidence      | Acquire evidence, preserve it per attempt, and derive nullable aggregate projections   |
+| `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.
 
-§provider-cost `ProviderCost` represents one provider attempt's monetary truth.
-An authoritative result preserves the provider's canonical decimal amount and
-currency plus its decimal USD equivalent; an estimate carries a decimal USD
-amount; free requires an explicit source; unknown requires a reason. Decimal
-strings preserve evidence without binary floating-point rewriting. Unknown is
-not zero, and no consumer may infer free from absent rates or a legacy numeric
-zero.
+§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.
+
+§provider-cost `ProviderCost` represents one physical provider request's
+monetary disposition. `charged` preserves a provider-reported canonical decimal
+amount and currency, with an optional decimal USD equivalent for a non-USD
+charge. `estimated` preserves a calculated decimal amount and currency.
+`unknown` requires a reason. Zero is an ordinary exact amount under `charged`
+or `estimated`; there is no separate free mechanism. Decimal strings preserve
+evidence without binary floating-point rewriting. Unknown is not zero.
+
+§provider-request-accounting `ProviderRequestAccounting` is the indivisible
+accounting fact for one issued physical request. Its provider, model, outcome,
+optional protocol status, optional {§provider-usage}, and required
+{§provider-cost} travel together. Ordered request records preserve retries and
+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.
 
 The parser returns ordered statement, error, and text items. It recovers at a
 trustworthy statement boundary when possible and sets `unparsedTail` when a
@@ -92,110 +126,152 @@ 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.gbnf` is an optional local llama.cpp sampling rail: it is kept lean
+`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 shipped raw turn has one shape:
+The rails share one turn shape but begin at their respective sampled-token
+boundaries:
 
 ```ebnf
-root-turn ::= channel sep plan sep tail-0
+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 `channel` is exactly one Gemma Harmony enclosure at byte zero, beginning
-`<|channel>thought\n` and ending `<channel|>`. Its body may be empty but cannot
-contain another opener or the closer. `sep` is zero through seven whitespace
-characters. No channel is legal after the leading one. `tail-0` is unchanged
-apart from that removal: zero through fourteen internal statements, separated
-only by `sep`, followed by exactly one terminal SEND under the existing terminal
-eligibility rules.
+§gbnf-turn-shape 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
-    raw["Raw constrained decode<br/>channel · sep · PLAN · sep · tail-0"]
+    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/>channel body"]
-    content["content<br/>PLAN through terminal SEND"]
+    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 to the raw sentence on the left, before projection. The two
-projected fields are not separate GBNF languages and `content` alone is not
-revalidated as though it still contained the required channel. Provider and
-core own the projection evidence and rail-verdict boundary; this package owns
-only the raw language and the parser/AstBuilder result.
-
-§plan-body-no-openers On the GBNF rail, PLAN is unsuffixed and its body excludes
-the literal `<<`. A single `<` remains legal. This prevents an omitted `:PLAN`
-from consuming following operations as intended-goals text; ANTLR remains
-tolerant during ingestion.
+§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
+suffix 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 suffix and section boundary structurally
+available during constrained generation; ANTLR remains the wider language and
+accepts intentional alternate-lane literals during ingestion.
+
+§gbnf-curation-shaping The rail admits OPEN/FOLD curation terms, a canonical
+`log:` target, and a matcher independently. It accepts any ordered mixture of
+unsigned, `+`, and `-` terms without proving that the combination selects a log
+item; ANTLR and AstBuilder own that condition, while runtime owns wider ingested
+target resolution.
 
 ## §canonical-statement 2. Canonical statement form
 
 ```text
-<<OPsuffix[signal]?(path)?<scope>?:body?:OPsuffix
-```
+# PLANsuffix
+body
 
-§body-fence The two colons fence the body. Everything after the opening colon and
-before the matching `:OPsuffix` close is preserved verbatim and is opaque to
-operation keywords, slot characters, and nested PLURNK-looking text. An empty
-body retains both delimiters: `::OPsuffix`.
+## OPsuffix [signal]? (path)? <scope>?
+body?
+```
 
-| Element     | Canonical contract                                                 |
-|-------------|--------------------------------------------------------------------|
-| `<<`        | Required statement opener                                          |
-| `OP`        | One protocol operation                                             |
-| `suffix`    | Optional enclosure suffix, joined directly to `OP`                 |
-| `[signal]`  | Optional operation-specific signal                                 |
-| `(path)`    | Optional syntax slot whose operation contract may require a target |
-| `<scope>`   | Optional operation-specific numeric scope                          |
-| `:`         | Required body opener, even when the body is empty                  |
-| `body`      | Operation-specific, character-perfect content                      |
-| `:OPsuffix` | Required close matching the opener exactly                         |
+§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 have one blank separator line. That final separator
+line is syntax and is not body content; any additional preceding blank lines
+remain body content. The tolerant ingester also admits a structural heading on
+the immediately following line.
+
+§empty-section An empty section has no body lines between its heading and the
+section separator (or EOF) and normalizes to a null body.
+
+| Element      | Canonical contract                                                        |
+|--------------|---------------------------------------------------------------------------|
+| `# PLAN`     | Required level-one turn anchor                                             |
+| `## OP`      | Level-two protocol operation                                               |
+| `suffix`     | 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                                |
+| `<scope>`    | Optional numeric scope, 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:
 
-- §close-tag-match The close `:OPsuffix` must character-match the opening operation and suffix.
+- §lane-match PLAN establishes one lane for the turn. A heading is structural
+  only when its suffix character-matches that lane; a different suffix 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.
-- OPEN, FOLD, WORK, FORK, and KILL do not admit a scope slot.
-- A suffix is `[A-Za-z0-9_]*`; generation canon uses digit suffixes when enclosure is needed.
+- OPEN, FOLD, BARE, WORK, FORK, and KILL do not admit a scope slot.
+- An ingested suffix 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. The tolerant ANTLR ingester accepts any permutation of the slots admitted
-by that operation, at most once each. Accepted permutation is not a second
-canonical spelling.
+scope, with one ASCII space before every present slot. 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 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                      |
+| Tolerated input                                   | Canonical or runtime disposition                                    |
+|---------------------------------------------------|---------------------------------------------------------------------|
+| Reordered admitted slots                          | Producers retain signal → target → scope order                      |
 | Missing target on a generally targeted operation | AST carries `null`; the runtime rejects when the target is required |
-| PLAN modifiers or suffix                         | Model canon keeps PLAN slotless and unsuffixed                      |
-| KILL annotation body                             | AST preserves it; model teaching uses an empty body                 |
-| Dash-separated or comma-space scope numbers      | Producers use adjacent comma-separated numbers                      |
-| One-colon empty body at a statement boundary     | Producers retain the explicit `::OPsuffix` empty body               |
+| PLAN modifiers or a non-`0` lane                  | Model canon keeps PLAN slotless and 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   |
 
 ## 3. Lexical elements
 
 | Element     | Accepted shape or role                                             |
 |-------------|--------------------------------------------------------------------|
-| `OP`        | `FIND READ EDIT COPY MOVE OPEN FOLD SEND EXEC WORK FORK KILL PLAN` |
-| `suffix`    | `[A-Za-z0-9_]*`, adjacent to `OP`                                  |
+| `OP`        | `FIND READ EDIT COPY MOVE OPEN FOLD SEND EXEC BARE WORK FORK KILL PLAN` |
+| `suffix`    | `[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                    |
 | `<scope>`   | One or more signed integers or decimals; detailed in §7            |
-| `body`      | Opaque text between the body opener and matching close             |
-| `:OPsuffix` | Adjacent colon plus the exact opening operation and suffix         |
+| `body`      | Opaque section text before the next same-lane heading or EOF        |
 
 ## §op-shapes 4. Per-operation semantics
 
@@ -205,14 +281,15 @@ governed by {§canonical-statement}; runtime conditions remain explicit below.
 | OP   | `[signal]`                    | `(path)`                                     | `<scope>`                       | `body`                         |
 |------|-------------------------------|----------------------------------------------|---------------------------------|--------------------------------|
 | PLAN | none                          | none                                         | none                            | required intended goals        |
-| FIND | optional filter tags          | required target or glob                      | optional result range           | optional matcher               |
-| READ | optional filter tags          | required target or glob                      | optional text region            | optional matcher               |
-| EDIT | optional apply tags           | required file or entry                       | required for an existing target | literal text                   |
-| COPY | optional apply tags           | required source                              | optional source region          | required destination selection |
-| MOVE | optional apply tags           | required source                              | optional source region          | required destination selection |
-| FOLD | optional apply tags           | required log selection                       | none                            | optional matcher               |
-| OPEN | optional filter tags          | optional log selection when tags are present | none                            | optional matcher               |
+| 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 |
+| FOLD | optional filter/change tags   | optional log selection                       | none                            | optional matcher               |
+| OPEN | optional filter/change tags   | optional log selection                       | none                            | 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                |
 | KILL | optional target-specific code | required target, including a log item        | none                            | empty                          |
@@ -224,15 +301,19 @@ 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-intended-goals **PLAN records intended goals.** The PLAN body is the model's
-concise statement of intended goals. It is public, durable log content—not provider
+§plan-intended-goals **PLAN records working-state deltas.** Its concise body adds
+new material conclusions or unresolved questions and the current turn's priorities;
+it does not restate settled context. PLAN is public, durable log content—not provider
 reasoning. Dispatch records it and has no other runtime effect.
 
-OPEN and FOLD are log-curation operations owned by the core log surface. FOLD
-selects a set, hides its bodies, and applies any signal tags. OPEN filters by its
-signal tags and may omit the target to recall that tagged working set across the
-worker log. FOLD requires a target or matcher; OPEN requires a target, matcher,
-or filter tags. Neither operation exposes a positional scope.
+§log-tag-signal FIND, READ, EDIT, COPY, MOVE, and BARE canonically express additions
+as `+tag`. Because those operations have no tag-selection semantics, ANTLR also
+tolerates unsigned `tag` as an equivalent addition; `-tag` is invalid. Core
+strips any `+`; the signal neither filters nor modifies resources. OPEN and
+FOLD treat every unsigned `tag` as an ALL-tags selector, then add each `+tag`
+and remove each `-tag` from the selected log items. Signed terms never select,
+so either a target, matcher, or unsigned tag is required. Adding and removing
+the same tag conflicts. Neither curation operation exposes a positional scope.
 
 The `<scope>` slot is optional where admitted and its domain is OP-specific. FIND
 scopes ordered results. EXEC and SEND scope timing. READ, EDIT, COPY, and
@@ -248,20 +329,34 @@ MOVE use one universal text algebra independent of mimetype:
 two-integer line selections normalize to the same exclusive-end `TextRegion`
 used by four-coordinate selections. Whole-line replacement deliberately
 accounts for newline separators; it is an ergonomic projection over exact
-replacement, not a different mimetype navigation mode. As an unadvertised
+replacement, not a different mimetype navigation mode. An end bound beyond
+the available content clamps to the final addressable endpoint; the start bound
+must resolve. As an unadvertised
 ingestion tolerance, the runtime accepts three integers as
 `startLine,startColumn,endLine` and immediately normalizes them to the complete
 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.
 
-For READ, a body matcher selects files, entries, or log items against their
-complete readable content. A non-semantic `<scope>` then projects text from each
-selection; it never paginates the match set or limits where the matcher searches.
-Without `<scope>`, READ returns each selection's complete readable content.
-Semantic READ reserves a leading decimal for an optional similarity threshold;
-the remaining one, two, or four integers project text. Without a leading decimal, every
-integer belongs to READ projection and selection uses the configured default.
+§bare-statement **BARE requests one isolated model inference.** Its required
+body is the complete prompt. It admits only optional additive log tags: 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
+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.
 
 Mutation semantics:
 
@@ -271,13 +366,13 @@ 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.
-- COPY and MOVE parse the body as a destination `ResourceSelection`: a target plus an optional destination scope. Header target, fragment, and scope independently select the source resource, channel, and region.
+- §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.
 
 ### §operation-observation Per-operation observations
 
 | OP   | Successful observation                                                            |
 |------|-----------------------------------------------------------------------------------|
-| FIND | Catalog rows plus optional structural locators and text match evidence            |
+| FIND | Resource catalog groups or exact-target match locations                           |
 | READ | Complete or scoped body projections plus optional text match evidence             |
 | EDIT | Status plus a bounded receipt for the effect that landed                          |
 | COPY | Source and destination selections plus ordered destination effects                |
@@ -286,11 +381,18 @@ Mutation semantics:
 | FOLD | Status and matched log-item count                                                 |
 | SEND | Status and recipient acknowledgement when applicable                              |
 | EXEC | 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 intended-goals logging                                          |
 
+§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
+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.
+
 §copy-move-observation COPY and MOVE log projections preserve both admitted operand selections,
 including their independent scopes, whether the result changed state, was a
 304 no-op, or failed after admission. Operands identify the request; `effects`
@@ -346,7 +448,7 @@ pairs such as `\*` retain both characters for glob interpretation. Encoding
 escapes backslashes before parentheses, so every target string round-trips.
 Pathname producers retain the deliberate `%28`/`%29` alias and `%3C` spelling,
 but must use the lexical layer for identity-bearing query and fragment text
-rather than changing their percent-encoded spelling. Newlines and `<<` are
+rather than changing their percent-encoded spelling. Newlines and raw `<` are
 never target content. Glob metacharacters remain legal path data.
 
 §path-glob `PathSyntax` owns exact-path versus path-pattern classification.
@@ -378,8 +480,10 @@ ingestion restriction: the parser decomposes arbitrary URL authorities.
 
 ## §matcher-prefix-claims 6. Bulk pattern matching
 
-FIND, READ, OPEN, and FOLD accept an optional body matcher. The lexer preserves
-the body opaquely; AstBuilder assigns the dialect from its leading characters.
+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
+{§read-find-normalization}.
 A leading prefix claims its dialect. Invalid claimed syntax is a positioned
 visitor error and never falls back to glob matching.
 
@@ -405,7 +509,9 @@ 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 tolerates multiline matcher bodies during ingestion.
+  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-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.
@@ -413,31 +519,47 @@ statements remain recoverable when their boundaries are trustworthy.
 ## §scope-slot 7. Scope markers
 
 The model-facing slot is `<scope>`; the AST field remains the historical
-`lineMarker: { marks: number[] }`. The parser preserves ordered numeric
-components, while the operation owner assigns their roles.
-
-| Operation             | Canonical components                         | Meaning                                                      |
-|-----------------------|----------------------------------------------|--------------------------------------------------------------|
-| FIND                  | optional threshold, then 0–2 positions       | Inclusive positions in a deterministic result order          |
-| READ                  | optional threshold, then 0/1/2/4 coordinates | Text projection from every selected file, entry, or log item |
-| EDIT                  | text coordinates                             | Text replacement, deletion, prepend, or append               |
-| COPY/MOVE source      | text coordinates                             | Region copied or moved from the selected source              |
-| COPY/MOVE destination | text coordinates after destination           | Region replaced or insertion point at the destination        |
-| EXEC                  | `timeout[,poll]`                             | Spawn lifetime bound and poll cadence in seconds             |
-| Terminal SEND `[202]` | `timeout[,poll]`                             | Bounded or indefinite wait and optional poll cadence         |
+`lineMarker`. Numeric scopes preserve ordered components in `LineMarker`;
+text-coordinate operations use `TextLineMarker`, whose line positions may also
+carry rendered anchors. The operation owner assigns every component's role.
+
+The operation column names the canonical AST operation after
+{§read-find-normalization}.
+
+| Operation             | Canonical components                   | Meaning                                                                    |
+|-----------------------|----------------------------------------|----------------------------------------------------------------------------|
+| FIND                  | optional threshold, then 0–2 positions | Inclusive resource or exact-target location positions ({§find-result-unit}; defaults to `<1,16>`) |
+| READ / client LOOK    | 0/1/2/4 text coordinates               | Text projection from one exact selected file, entry, or log item           |
+| EDIT                  | 0/1/2/4 text coordinates               | Text replacement, deletion, prepend, or append                             |
+| 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                      |
+| EXEC                  | `timeout[,poll]`                       | Spawn lifetime bound and poll cadence in seconds                           |
+| 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
 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 or
-READ is a similarity threshold; any remaining integers retain the operation's
-ordinary result or text meaning.
+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.
+
+§text-line-anchor-syntax A text coordinate admits a case-sensitive line anchor
+spelled `@` followed by exactly five Base62 characters (`0-9A-Za-z`) wherever
+its `L`, `SL`, or `EL` position denotes a line. Columns, prepend `0`, and append
+`-1` remain numeric. Exact READ, EDIT, COPY/MOVE source and destination, and
+client LOOK preserve these positions in `TextLineMarker`; core resolves them
+against the addressed current text before operation-specific numeric scope
+semantics run. A matcher-bearing or path-glob READ normalizes to FIND, whose
+result positions remain numeric and reject anchors. Numeric text scopes remain
+canonical and fully supported. Parser acceptance does not imply model-facing
+recommendation.
 
 §scope-marker-forms Canonical producers separate components with commas and no
 spaces. ANTLR tolerates a dash separator and one space after a comma. Each
 component greedily consumes an optional leading minus sign, digits, and an
 optional decimal fraction, so the ingester preserves even noncanonical numeric
-shapes for runtime validation.
+shapes for runtime validation. An anchor-bearing text scope uses commas; ANTLR
+tolerates one space after each comma.
 
 Apart from the unadvertised three-coordinate text-scope tolerance in
 {§text-scope-semantics}, the runtime rejects invalid arity, out-of-range or
@@ -448,45 +570,44 @@ does not enforce either condition.
 
 ## §suffix-discipline 8. Suffix Discipline
 
-The `:body:` fencing handles the vast majority of grammatical-enclosure
-concerns: body content is fully opaque to OP keywords and modifier-like
-characters. The suffix is reserved for the residual edge case where
-body content literally contains the close-tag pattern `:OPkeyword`.
-That happens in two scenarios:
-
-1. **Nesting plurnk statements inside a body** (recording a plurnk
-   transcript, storing examples, etc.). The inner statement's close
-   `:OP` would prematurely terminate the outer's body.
-2. **Body content contains `:OPkeyword` as literal text** (e.g., a
-   stored JSON object with a value mentioning plurnk syntax).
+The suffix 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.
 
 Suffix rules:
 
-- `suffix` is `[A-Za-z0-9_]*`, concatenated to `OP` with no separator, on both open and close.
-- Open `<<OPsuffix` and close `:OPsuffix` must character-match.
-- A non-empty suffix on the outer statement ensures its close tag
-  (`:OPsuffix`) is distinct from any `:OP` substring that may appear in
-  body content (whether as nested plurnk or as literal text).
-- The body of a statement cannot contain its own exact close-tag
-  literal; choose a suffix that does not collide.
-- Empty suffix is the default. Most statements need no suffix.
-- Generation-side canon dictates **digit** suffixes (`<<EDIT1 … :EDIT1`)
-  so the shipped GBNF (`dist/plurnk.gbnf`) can enumerate close tags —
-  the HEREDOC tag match is not context-free. The parser remains
-  permissive: any matching `[A-Za-z0-9_]*` suffix is valid.
-
-Example — a nested operation inside a suffixed outer body:
+- `suffix` 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 suffix.
+- An empty suffix 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 suffix differs from the active lane.
+- To carry a nested turn written with lane `0`, choose another suffix 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.
+
+Example — a lane-0 turn stored inside a lane-2 EDIT body:
 
 ```
-<<SEND1[400]:
-The following is a quoted plurnk operation, preserved verbatim:
-<<SEND[400](worker://reviewer):still working:SEND
-:SEND1
+# PLAN2
+Store the quoted turn.
+
+## EDIT2 (worker:///quoted.plurnk)
+# PLAN0
+Answer from memory.
+
+## SEND0 [200]
+Paris.
+
+## SEND2 [200]
+Stored the quoted turn.
 ```
 
-The inner's `:SEND` close is ordinary body text because the outer close
-is `:SEND1`. This rule belongs to the body fence and applies to every
-operation, not to EDIT semantics.
+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.
 
 ## 9. SEND Codes
 
@@ -528,7 +649,7 @@ structural:
 - §no-idle-102 A **zero-statement turn may not conclude `[102]`** — "continue"
   with nothing submitted is a spin. The GBNF's `tail-0` exits through
   a terminal trie without the `[102]` tail, so the idle turn (`PLAN`
-  straight into `SEND[102]`) is unemittable; one statement restores
+  straight into `## SEND0 [102]`) is unemittable; one statement restores
   the full disposition set. The other four stay legal bare (a zero-op
   `[202]` is the engine's obligation check). ANTLR stays tolerant
   (ingest side). A dispatch-emptied turn — ops emitted but failing
@@ -557,61 +678,60 @@ AST. Generated TypeScript targets the `antlr4ng` runtime.
 stateDiagram-v2
     [*] --> DEFAULT
     DEFAULT --> DEFAULT: whitespace or TEXT
-    DEFAULT --> SLOTS: minted <<OPsuffix
+    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 --> SLOTS: scope token
-    SLOTS --> BODY: body-opening colon
-    BODY --> DEFAULT: matching close tag
+    SLOTS --> BODY: heading line end
+    BODY --> DEFAULT: same-lane heading boundary
+    BODY --> [*]: end of input
 ```
 
-SLOTS admits operation-appropriate signal, target, and scope openers in any
-order; the parser grammar enforces at-most-once multiplicity. 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 the semantic predicate
-recognizes the exact close from the captured opener.
+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; the parser
+grammar enforces at-most-once multiplicity. 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.
 
-TURN is the single exception to opaque-body mode: its opener returns to DEFAULT
-so a complete inner turn parses structurally, and a suffix stack recognizes its
-matching close. The narrow one-colon empty-body tolerance closes directly from
-SLOTS only at a trustworthy statement boundary.
-
-DEFAULT recognizes minted operation openers and otherwise emits non-whitespace
-input as TEXT. A `<<word` whose word is not a minted operation remains TEXT.
-Complete native reasoning enclosures are likewise one TEXT token so an operation
-drafted inside pre-PLAN reasoning cannot become the turn anchor.
+A differently suffixed 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 statement boundaries where possible.
-An unfinished signal, target, body, or TURN leaves the lexer outside DEFAULT and
-therefore produces `unparsedTail`; no later input is trustworthy.
+failures. PlurnkErrorStrategy recovers at structural heading boundaries where
+possible. EOF is a valid body boundary. An unfinished signal or target produces
+`unparsedTail`; no later input is trustworthy.
 
 ## §whitespace-contract 11. Whitespace and interstatement text
 
-| Location                | Canonical generation                 | Tolerant ANTLR ingestion                                    |
-|-------------------------|--------------------------------------|-------------------------------------------------------------|
-| Between header slots    | Adjacent                             | Spaces, tabs, and newlines are ignored                      |
-| Between `OP` and suffix | Adjacent                             | Must remain adjacent                                        |
-| Inside signal           | Adjacent values                      | Horizontal whitespace is ignored; newline is invalid        |
-| Inside target           | Path alias plus target escapes        | Balanced literals tolerated; newline and `<<` are invalid   |
-| Inside scope            | Comma-separated numbers              | Dash separator and one post-comma space are also accepted   |
-| Inside body             | Character-perfect                    | Character-perfect                                           |
-| Inside close tag        | Colon and `OPsuffix` are adjacent    | Must remain adjacent and match the opener                   |
-| Between turn statements | GBNF `sep`: zero to seven whitespace | Whitespace is hidden; non-whitespace may surface as 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 suffix       | Adjacent                              | Must remain adjacent                                      |
+| Before each header slot     | 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 scope                | Comma-separated numbers               | Dash separator and one post-comma space are also accepted |
+| Inside body                 | Character-perfect                     | Character-perfect                                         |
+| Between canonical sections  | One empty separator line              | A directly following structural heading 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` and `parseLog` admit TEXT around their PLAN-anchored operations and
-return it as ordered text items without assigning semantics. `parseStatements`
-and `parseClient` admit statements and hidden whitespace only. PLURNK defines no
-comment syntax; a consumer may treat script-tier text as commentary, but that is
-consumer policy rather than language syntax.
+`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 comment syntax.
 
 ## §public-api 12. Public API
 
@@ -620,20 +740,28 @@ 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. PLAN is the
-first operation, a disposition-coded SEND is the terminal operation, and PLAN
-cannot recur mid-turn. Tolerated TEXT may appear before PLAN, between operations,
-and after SEND; it remains an ordered text item. Missing either anchor or placing
-an operation after the terminal SEND is an error.
+§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.
+
+§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
+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-anchored model turn with optional TEXT                | `PlurnkStatement`     |
+| `PlurnkParser.parse`           | One PLAN turn: bare with optional TEXT, or outer `plurnk` fence ending at its closer or EOF | `PlurnkStatement`     |
 | `PlurnkParser.parseStatements` | Zero or more protocol statements and hidden whitespace         | `PlurnkStatement`     |
-| `PlurnkParser.parseLog`        | One or more TURN-wrapped model turns                           | `PlurnkStatement`     |
-| `PlurnkParser.parseClient`     | Protocol statements plus read-shaped client LOOK/BUFF commands | `ClientStatement`     |
+| `PlurnkParser.parseLog`        | One or more consecutive same-lane PLAN-anchored turns           | `PlurnkStatement`     |
+| `PlurnkParser.parseClient`     | H2 protocol statements plus read-shaped LOOK/BUFF commands      | `ClientStatement`     |
 
 Every entry point returns ordered `statement`, `error`, and, where admitted,
 `text` items. When present, {§unparsed-tail-boundary} governs the result's item
@@ -654,6 +782,7 @@ following supported consumer values. All other root exports are TypeScript types
 | `InvalidProblemDetailsError`          | Typed failure from `Validator.assertProblemDetails`                 | {§problem-details}                          |
 | `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}                          |
 | `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}                              |
@@ -703,7 +832,24 @@ point. A producer supplies all four coordinates or omits the region. It never
 substitutes UTF-16 offsets, readable-row indices, or partial coordinates.
 `Validator.assertTextRegion` rejects an end before its start.
 
-### §entry-read-result 13.2 Client entry reads
+### §range-extent 13.2 Range extents
+
+`RangeExtent` is the compact wire projection of one line or ordered-result
+selection: `{ unit, total, requested: [first,last], returned?: [first,last] }`.
+`requested` preserves the numeric request, including invalid fractional
+evidence on a failed selection; a one-position request therefore repeats its
+endpoint. Successful selection endpoints are integers. `total` is the complete
+available cardinality.
+`returned` names the inclusive positions actually projected and is absent for
+an empty selection or a failed request. Its endpoints are positive, ordered,
+and no greater than `total`.
+
+The transparent coordinates make completion and continuation derivable. The
+shape has no separate `complete`, `next`, or all-results instruction. Exact
+text-coordinate selections use {§text-region} instead. `Validator.assertRangeExtent`
+enforces both the schema and the relational endpoint invariants.
+
+### §entry-read-result 13.3 Client entry reads
 
 `EntryReadResult` is the exact transport-neutral projection of one entry. It
 does not expose workspace IDs, storage owner IDs, split scheme/pathname fields,
@@ -719,7 +865,6 @@ scope, or other persistence columns.
 | `entryId`           | Positive durable entry identifier                                                            |
 | `target`            | Client selector for the resolved entry, with any channel fragment removed                    |
 | `channels`          | Every channel for a full read, or exactly the selected channel for a sliced read             |
-| `tags`              | Unique non-empty entry tags                                                                  |
 
 | Channel field   | Contract                                                                                                      |
 |-----------------|---------------------------------------------------------------------------------------------------------------|
@@ -736,7 +881,7 @@ offset beyond the current end returns empty content at `contentLength`, not the
 unbounded requested offset. `Validator.assertEntryReadResult` enforces the
 schema, this suffix invariant, and Problem status equality.
 
-### 13.3 Operation results
+### 13.4 Operation results
 
 §operation-result Every public PLURNK operation returns one `OperationResult`:
 
@@ -750,7 +895,7 @@ fields and Problem Details extension members remain open. A malformed result is
 an internal producer contract violation; it is not converted into a second
 model-facing failure envelope.
 
-### 13.4 Problem Details
+### 13.5 Problem Details
 
 §problem-details `ProblemDetails` requires `type`, `title`, `status`, and `detail`;
 `instance` is optional until a durable host can attach the occurrence URI.
@@ -780,13 +925,13 @@ 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.
 
-### 13.5 Notices
+### 13.6 Notices
 
 §notice A `Notice` is a transient, nonterminal observation. It cannot determine durable
 failure truth, lifecycle, scheduling, or recovery. Sharing a renderer with
 Problems does not merge their semantics.
 
-### §client-display-capabilities 13.6 Client display capabilities
+### §client-display-capabilities 13.7 Client display capabilities
 
 `ClientDisplayCapabilities` is the transport-neutral installed-capability
 projection used by external clients. It is an ordered array of closed,
@@ -824,7 +969,7 @@ class PlurnkParseError extends Error {
 ```
 
 §parser-position Parser source locations are points, not text regions. An AST
-statement's `position` identifies the first `<` of its open tag; a diagnostic
+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 constructed without retained parsed source uses `UNKNOWN_POSITION`,
@@ -850,48 +995,40 @@ and 3.30.2](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html).
 | Source      | Boundary                                                                               |
 |-------------|----------------------------------------------------------------------------------------|
 | `"lexer"`   | Token-level failure, such as an unrecognized character or malformed `<L>` integer.     |
-| `"parser"`  | Structural failure, such as a missing close tag or wrong token order.                  |
+| `"parser"`  | Structural failure, such as the wrong heading depth or slot order.                     |
 | `"visitor"` | Semantic AST-construction failure, such as an invalid matcher dialect or signal shape. |
 
 `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 `<<PLAN`, end with a terminal `<<SEND`), and
-these targeted diagnostics:
-
-- §invented-closer-advisory **Invented closer.** When the forgiving parser
-  swallows a `<<Word…:Word` heredoc whose keyword is a known op confusion
-  (`<<CLOSE` → did you mean `<<FOLD`), it emits a `warning`-severity near-miss
-  advisory. On a never-closed body, when the swallowed text carries an
-  `:ALLCAPS` tag that is not the op's closer, the `unparsedTail` reason names it
-  (`found \`:COMPARISON_TASK\`, which is body text - the closer echoes the op's
-  name`) so a cap-cut runaway's recovery turn learns what happened, not just
-  that something did.
+turn-shape imperatives (begin with `# PLAN0`, end with a terminal
+`## SEND0 [code]`), and these targeted diagnostics:
+
 - §signal-scope-redirect **EXEC scope in the signal slot.** When EXEC's
   `[signal]` slot (executor-ident mode) hits a leading `-` or digit —
   mark-shaped `<timeout, poll>` scope content mistyped into the brackets — the
   lexer message becomes `timeout/poll ride the \`<scope>\` slot; try
-  \`EXEC<-1,300>\`` instead of a raw `unrecognized character`. The redirect is
+  \`## 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 slot region begins with `$`, `~`, or `@`, the lexer redirects the
-  unambiguous body matcher into `:body:` instead of returning the generic slot
-  list. Slash-led regex and XPath are excluded because the same character can
-  be a forgotten target wrap.
-- §plan-body-op-advisory **Operation text swallowed by PLAN.** When an
-  unsuffixed PLAN body contains op-shaped text (`<<EXEC`…), an advisory reports
-  that the likely omitted `:PLAN` swallowed the turn's ops (`ops belong after
-  the plan closes; did you omit \`:PLAN\`?`). A non-empty suffix deliberately
-  invokes {§suffix-discipline} and suppresses this advisory.
+  post-target header region begins with `$`, `~`, or `@`, the lexer redirects
+  the unambiguous matcher to the first body line instead of returning the
+  generic slot list. Slash-led regex and XPath are excluded because `/` can be
+  target data.
+- §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.
 - §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
-  path into `(…)` (`\`<<EDIT\` has no \`(target)\` - that path sits in the
-  \`[…]\` tag slot; a target goes in \`(…)\`. Try \`EDIT(path):…\``). This
-  catches the markdown `[label](url)` reading at the parse where the engine
-  otherwise returns only a bare 400. It is gated on a path-shaped signal so a
-  genuine tags-only slip is not mis-steered toward a path it lacks.
+  path into `(…)` (`\`## EDIT0\` has no \`(target)\` - that path sits in the
+  \`[…]\` 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.
 
 §error-shape The diagnostic class determines how much guidance the parser may
 provide:
@@ -901,20 +1038,20 @@ provide:
 | Hard fact              | `severity: "error"`   | One concise observed fact and violated constraint in PLURNK vocabulary.                   |
 | Targeted hard redirect | `severity: "error"`   | One canonical correction only when parser state makes the intended structure unambiguous. |
 | Non-fatal advisory     | `severity: "warning"` | One narrowly gated likely mistake and canonical alternative; input remains admitted.      |
-| Boundary loss          | `unparsedTail`        | Where trust ends, what remains open, and the required closer; later input is undefined.   |
+| Boundary loss          | `unparsedTail`        | Where trust ends, which header slot remains open, and why later input is undefined.        |
 
-All messages use PLURNK protocol vocabulary: open tag, close tag, signal,
-target, scope, line marker, body, statement header, or space between
-statements. They never expose ANTLR rule or token names. They refer to a slot or
+All messages use PLURNK protocol vocabulary: heading, lane, signal, 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.
 
 Examples of canonical hard facts:
 
-- `unrecognized character '<<' in target`
+- `unrecognized character '<' in target`
 - `unrecognized character ':' in signal`
 - `unrecognized character 'X' in statement header`
-- `expected close tag; got end of input`
+- `a turn must begin with \`# PLAN0\``
 - `expected ')'; got ':'`
 
 Each malformed statement produces at most one hard error. The first recorded
@@ -949,6 +1086,6 @@ runtime constructs this; the parser provides the fields):
     "column": 12,
     "source": "parser",
     "severity": "error",
-    "message": "expected close tag `:OPsuffix`; got end of input"
+    "message": "target slot of `## READ0` opened at line 1 but never closed - add `)`"
 }
 ```