@plurnk/plurnk-service 1.26.0 → 1.27.0

package/SPEC.md

@@ -143,7 +143,7 @@ which depends on core semantic conventions v1.44.0: a CLIENT-kind
 spelling, never its tuning alias; unmatched IDs are preserved, `other` for an
 unregistered handle), and `gen_ai.request.model`;
 on settlement it gains `gen_ai.usage.input_tokens` and
-`gen_ai.usage.output_tokens` by aggregating every reported request quantity in
+`gen_ai.usage.output_tokens` for quantities reported by every physical request in
 validated accounting ({§tokenomics-provider-usage}), plus
 `gen_ai.response.finish_reasons`; failures carry `error.type` as the class
 name only. Plurnk custom attributes (attempt, kind, status, loop/turn ids)
@@ -586,9 +586,17 @@ Every admitted authority is a literal `workers.name`; self-addressing uses the c
   the errors section), just above it. Body-suppressed child activity is durable
   history; this section is the current inventory that keeps an active obligation
   visible even when no new activity arrived. Each open stream pointer carries
-  its channels' sizes and growth since the last packet in `detail`
-  (`{"status":"active","path":"sh:///ab3d5678","detail":"stdout 340 lines (+2048 bytes)"}`)
-  — the only thing the model learns about a stream before it closes
+  elapsed runtime, output inactivity, and its channels' sizes and growth since
+  the last packet in `detail`
+  (`{"status":"active","path":"sh:///ab3d5678","detail":"elapsed 300s; output unchanged 120s; stdout 340 lines (+2048 bytes)"}`).
+  Both durations are whole seconds at packet assembly, floored and bounded
+  below by zero. Runtime starts at subscription opening. Output inactivity
+  starts there too, then resets atomically when any published channel's content
+  changes, including replacement or clearing. Identical writes, empty appends,
+  READs, publication acknowledgements, metadata, and channel-state changes do
+  not reset it. The clock is durable; an upgraded stream lacking that evidence
+  reports `output timing unknown` until its next content change, never a guessed
+  timestamp. These are observations, not new timeouts or wake conditions
   ({§exec-stream}). It is orienting state, never advice: the model sees its live
   subtree (`{"status":102,"path":"worker://worker-x"}`) and reasons for itself —
   READ, SEND, or KILL via the path.
@@ -736,7 +744,8 @@ identity, and terminal disposition without exposing raw bytes or a base64 lane.
 | ---------------------------------- | ---------------------------------------------------- | -------------------------------------------------------------------------------- |
 | Text                               | Verbatim Unicode under the detected textual mimetype | READ and EDIT use the snapshot.                                                  |
 | Binary with readable projection    | Derived Unicode as `text/markdown`                   | READ uses the projection; source-aware EDIT remains 415.                         |
-| Binary without projection/over cap | Empty marker under the source binary mimetype        | READ and EDIT return 415; private metadata distinguishes unavailable from limit. |
+| Binary without projection          | Empty marker under the source binary mimetype        | READ uses source bytes under {§read-bytes}; text EDIT remains 415.                |
+| Failed or oversized acquisition    | Empty marker carrying the producer failure           | The operation preserves that failure under {§membership-materialization-limit}. |
 
 §membership-materialization-limit **A pathological member degrades, never the
 workspace.** `PLURNK_SERVICE_FILE_MATERIALIZE_MAX_BYTES` is a required positive
@@ -836,19 +845,38 @@ all use that one definition.
 
 ### §worker-wait-timing Durable waits and wake ownership
 
-WAIT has no timing operand; its optional path is a label ({§send-wait-scope}).
-With live work—an open stream or a live child worker—the loop parks durably
-and wakes on settlement, on a
-message, or on the inherited observation cadence of its open streams
-({§exec-lifetime}); without live work it continues at once, told so. A wake
-continues the same loop with the same messages, generation policy, and
-cumulative turn ceiling; it never creates another assignment. Scheduled messages
-exist independently of a loop's optional attachment to one occurrence.
+With live work—an open stream or a live child worker—the loop parks until an
+ordinary wake or its maximum wait elapses. `PLURNK_SERVICE_WAIT_SEC` supplies the
+bound; `WAIT <seconds>` overrides that one park ({§send-wait-scope}). The wake time
+commits atomically with the wait revision, rounded up to the next millisecond.
+Expiry queues the same loop through normal worker/provider admission; it never
+cancels work or fabricates a result.
+
+With live work, each WAIT receipt exposes `waitSeconds`, the maximum accepted
+for that operation. It is not elapsed time or a promised sleep: an ordinary wake
+or a shorter sibling WAIT can resume the loop sooner. An idle WAIT has no bound.
+Historical unbounded receipts do not acquire one during projection.
+
+| Boundary | Outcome |
+|---|---|
+| Message or work settlement before expiry | Wake normally; retire the old timer. |
+| Several WAITs | One park at the earliest requested bound; a bare WAIT requests the configured bound. |
+| Zero bound | Continue at 102 without parking, a timer, cancellation, or a warning; a later WAIT chooses its own bound. |
+| Eligible completion joining live work | Use the configured bound. |
+| No live work | Continue immediately; do not arm a timer. |
+| Later WAIT after any wake | New wait identity and bound; no inherited override or backoff. |
+| Restart | Restore the durable due time; an overdue wait becomes runnable. |
+| Cancellation or terminal loop | Late timers are inert. |
+| Provider-recovery or client-review wait | Keep its owning recovery/admission semantics, not this observation bound. |
+
+A wake preserves the loop's messages, generation policy, cumulative turn ceiling,
+and execution allowance. Parked time does not consume that allowance. Scheduled
+messages remain independent; WAIT neither creates one nor selects its waker.
 
 ```mermaid
 stateDiagram-v2
     Running --> Parked: atomically persist the wait identity
-    Parked --> Queued: arrival / completion / inherited observation, guarded by wait identity
+    Parked --> Queued: arrival / completion / wait expiry, guarded by wait identity
     Parked --> Terminal: cancellation
     Queued --> Running: same loop claimed by its worker's drain
 ```
@@ -964,7 +992,7 @@ completion. Closure is always a wake edge.
 
 | §worker-lifecycle-poll-matrix stream | While open | On closure |
 |------------------------------------------------|---|---|
-| any lifetime but `turn`                        | the daemon's exponential-backoff observation wakes ({§exec-lifetime}) | resume once with terminal observation |
+| any lifetime but `turn`                        | bounded wait expiry permits inspection ({§worker-wait-timing}) | resume once with terminal observation |
 | `[{"lifetime":"turn"}]`                        | reap at the next pre-turn boundary | surface the terminal outcome |
 
 The structured-concurrency sequence is identical whether a child performs an
@@ -980,7 +1008,7 @@ sequenceDiagram
     P->>P: WAIT parks on live child
     C->>S: execution opens subscription
     C->>C: WAIT parks on live stream
-    loop backoff, fixed cadence, or explicit arrival
+    loop wait expiry or explicit arrival
         S-->>C: optional progress observation
         C->>C: continue or park
     end
@@ -1294,7 +1322,6 @@ The parser owns its boundaries; core admits determinate work and exposes its fai
 | Lost boundary after a closed operation | Admit the closed operations and record the boundary diagnostic under {§unparsed-tail-boundary}. |
 | Lost boundary before any closed operation | Reject the attempt; neither outside text nor a reasoning NOTE substitutes for a closed operational statement. Reasoning FIND/READ count as such statements ({§reasoning-operations}). |
 | Outside text carrying a log-entry heading, other than an emission row's | Reject the attempt ({§fabricated-log-entry}). |
-| A response the provider stopped at a repeated line | Reject the attempt with the provider's sentence as its diagnostic ({§repetition-stop}); no provider recovery, notice, or problem row. |
 
 §fabricated-log-entry **Only the harness writes the log.** A line of outside response text that begins with a log-entry heading, `### log:///<loop>/<turn>/<sequence>/` ({§log-wire-format}), is the model continuing the packet's transcript instead of answering it: it writes the receipts it expects and then acts on them. The attempt is rejected under {§invalid-emission-attempts}, so neither that text nor any operation beside it runs or is stored as outside text ({§outside-text}), and its one diagnostic, at the heading's line, reads `` `### log:///2/1/5/READ` is a log entry, and only the harness writes the log. Write the operation, then wait for its receipt. `` Text inside an operation body is not examined, so a SEND or KILL may quote a receipt. A heading whose leaf is `emission` is exempt: the transcript shows it before each of the worker's own emissions ({§emission-row}), and repeating it invents no receipt, so the attempt is admitted and the heading stays outside text, counted by the digest as an echo. In 10,486 recorded emissions, 101 carried such a heading in outside text, every one a fabrication: 85 of 1,675 from deepseek-flash, 81 of them opening with one, and 16 from glm-5.3-flash, deepseek-v4-pro and qwen3.8-flash, which appended an invented `## Log` after their own operations.
 
@@ -1613,7 +1640,7 @@ Registration precedes loop affinity:
 - §op-synchronous **Decisive operations settle before the next operation.** The dispatcher awaits each operation and its proposal resolution. Work remains in flight only when the operation's contract deliberately creates concurrency: FORK, WORK, a stream-producing execution, and streaming READ after acquisition. Such a READ first establishes its durable subscription and returns `102`; a later operation may address that live owner. Dispatching an execution before KILL does not wait for the process to finish using a resource. KILL of a worker synchronously ends its live loops before disposition checks the pending set; physical scope cleanup remains asynchronous.
 - §edit-execution **One authored EDIT is one mutation.** Each EDIT resolves against current resource state when dispatch reaches it, owns its proposal when gated, and records its own resulting revision. No later EDIT is prepared or applied in advance. Numeric scopes address current coordinates; an earlier EDIT may change what those numbers select. Rejection applies only to that operation, not its successful siblings.
 - §edit-anchor-continuity **Own EDITs preserve untouched hash targets within one program.** Core carries an anchor through exact, successfully applied EDIT splices when its line survives unchanged, even if its ordinal or neighborhood changes. Scoped entry KILL uses the same deletion path. Target-line replacement or deletion invalidates that binding. Continuity is private to the admitted program and canonical resource/channel; it is not a new published anchor format. The complete normalized line content must match the expected result of the preceding recorded EDIT, otherwise retained bindings are discarded and ordinary current-state validation applies. Reviewer replacement and results without an applied EDIT receipt do not carry bindings forward. A retained binding resolves alone: a twin neighbourhood this program's own splice created elsewhere does not make the carried anchor ambiguous, and an anchor the program never bound resolves against current state. Normalization is the same line-content representation used by READ and line hashing; file-write revision checks remain independent. No approximate text matching is used. Lowered coordinates retain a current-anchor precondition at the mutation owner; ambiguous matches and concurrent changes remain collisions.
-- §anchor-offset **An anchor offset is tolerated, never taught (#749).** A line mark may carry an offset from its anchor (`@abcde+1`, `@abcde-2`), and a bare `+N` after an anchor counts from that anchor (`<@abcde,+1>`). The anchor resolves as usual and the offset is added; a result before line 1 is an invalid mark, and past the end is the ordinary range refusal. Continuity and current-anchor preconditions check the anchor's own line. No teaching text, scope table or receipt mentions offsets; `plurnk.md` keeps its two anchor forms. A bare `+N` with no anchor before it is refused as before.
+- §anchor-offset **An anchor offset is tolerated, never taught (#749).** A line mark may carry an offset from its anchor (`@abcde+1`, `@abcde-2`), and a bare `+N` after an anchor counts from that anchor (`<@abcde,+1>`). The anchor resolves as usual and the offset is added; a result before line 1 is an invalid mark, and past the end is the ordinary range refusal. Continuity and current-anchor preconditions check the anchor's own line. `plurnk.md` keeps its two anchor forms. Numeric relative endpoints normalize under {§scope-range-recovery}; a reversed range produced by anchor resolution is never reinterpreted as a count.
 - §edit-batch **One compound operation may require atomic splices.** The scheme's `editBatch` primitive validates all supplied numeric edits against one snapshot and commits one revision or none. Core supplies one statement for an authored EDIT; same-resource MOVE can supply multiple splices as one operation. This primitive does not group separate authored operations. Its replacement, insertion, conflict, and receipt rules remain owned by the shared Slicer.
 - §edit-batch-receipt **A refusal describes its own unapplied work.** An anchor collision lists every distinct unresolved anchor in that EDIT, including both range endpoints, in `unresolvedAnchors` (`anchor`, `kind: missing | ambiguous`, and matching `lines` when ambiguous). Missing is not proof of earlier validity or subsequent change. It carries `editCount: 1`, `applied: 0`, and recovery directing a READ for current coordinates; it makes no claim about other operations. A refused compound splice batch lists all conflicting pairs in `conflicts`, non-conflicting regions in `cleanRegions`, its first pair in `conflictingRegions`, and its own `editCount` and `applied: 0`.
 - §edit-batch-merges **Normalizations require evidence and a receipt.** An EDIT body carrying only this resource's published `L<@xxxxx>` prefixes (the number right-aligned) is stripped when those prefixes verify against current anchors or this worker's preserved READ receipts (`rendered-prefix-stripped`); otherwise it remains literal content (`rendered-prefix-unverified`). Within a single atomic splice batch, the Slicer can deduplicate identical regions/bodies, concatenate same-boundary insertions, assign a shared endpoint to the sole body reproducing that line, or relocate an inner change when its original content occurs exactly once in the outer body. An already-applied inner body can be dropped. Unevidenced overlap remains a collision. These batch resolutions never reinterpret separate authored EDITs. Applied normalizations carry their exact merge facts and a notice; receipts describe only the applied effects.
@@ -2035,24 +2062,24 @@ AST: `{ op: "EDIT", target, body: string | null, signal: tags | null, lineMarker
   ```` ```EDIT (path) [{"pattern": "/foo/"}] ```` reads the resource once under
   the channel's own mimetype, matches, and expands into one atomic batch
   ({§edit-batch}) of four-coordinate splices, all relative to the same original
-  content: a regex span is its evidence region; a literal (a glob without
-  metacharacters) is each of its occurrences on every matched line; a glob with
-  metacharacters is the whole matched line; a node dialect's span (`//` xpath,
-  `$` jsonpath) is the node's whole region as its handler reports it, across as
+  content under {§slice-semantics-compose-pattern}: a regex span is its match;
+  a literal is each substring occurrence; a glob selects matching line content;
+  a node dialect's span (`//` xpath, `$` jsonpath) is the selected node's source
+  region, not its enclosing context, across as
   many lines as the node spans, so ```` ```EDIT (books.xml) [{"pattern":
   "//book[price > 35]"}] ```` replaces each such element and an empty body
-  removes it. The body is literal replacement text, never a template; an absent
-  body deletes the spans and leaves their lines. A regex anchors each line (`^`,
-  `$`) and a regex span never crosses a line break — a match that would is
-  refused before any change (400 `pattern-span-invalid`). A numeric scope bounds the lines
-  a pattern may touch; `<0>` and `<-1>` name positions, not lines, and are refused
+  removes it. FTS uses its located token/phrase occurrences; graph uses the
+  definitions or references selected under {§graph-relations}. The body is
+  literal replacement text, never a template; an absent body deletes only the
+  spans. Regex anchors apply per line (`^`, `$`); matches may cross line breaks.
+  A numeric scope admits only complete matches inside its resolved source
+  region, including columns; `<0>` and `<-1>` name insertion positions and are refused
   (400 `pattern-scope-invalid`). Every touched line's anchor guards the batch as a
   precondition, so a same-turn change to one of them is the ordinary
   {§edit-collision}. Zero matches change nothing: 204 with `matched: 0`, never a
   clobber. The result is one operation receipt: `matched` spans, `receipt` for the
   first splice ({§edit-result-receipt-projection}), and `last` beside it for the
-  final one when there were several. Resource-selecting dialects (`~`, `&`)
-  name no spans: 400 `pattern-dialect-unsupported`. A scheme without textual EDIT scopes refuses the
+  final one when there were several. A scheme without textual EDIT scopes refuses the
   pattern before any read (400 `pattern-unsupported`). Same-turn anchor continuity
   ({§edit-anchor-continuity}) does not carry through a pattern batch; the next
   anchored EDIT validates against current state.
@@ -2083,25 +2110,20 @@ READ is the one fan-out core performs ({§read-fan-out}).
 - §log-range-miss-names-stream A 416 on a log execution item is the range twin of its channel miss ({§log-channel-miss-names-stream}): the coordinate addresses the row's invocation (its authored call body, often empty or one line) while the execution's output stays readable at the stream address the row records. When that stream link exists, the 416 gains it as `stream`, the detail appends where the command's streams live, and `recovery` is `READ <stream> for the command's stream`, whether the invocation's extent is empty or merely shorter than the range (#759). A 416 on a row with no recorded stream stays byte-identical to the generic slicer's.
 - §read-pattern **A pattern selects the lines a READ renders.** With a heading
   matcher ({§matcher-option} in the contracts SPEC) an exact-target READ stays a
-  READ: the matcher runs over the channel's text line by line — a regex anchors
-  each line, so `^` and `$` are the line's ends — and every line a match touches,
+  READ: the matcher runs over the channel's complete text — a regex anchors
+  each line, so `^` and `$` are the line's ends, while matches may span lines — and every line a match touches,
   in source order, is the visible selection. The scope still bounds it: a scoped
   READ renders exactly the selected lines the scope holds; a whole-resource one
   pages through the selected lines under the ordinary preview bound, never showing
   an unselected line. Selected lines keep their physical ordinals and their
   ordinary anchors, so a pattern READ is a coordinate source for EDIT and KILL. The
   result carries `matched`, the count of selected lines inside the scope. Zero
-  matches is an empty read (204, `matched: 0`), never a failure. A full-text
-  (`~`) or graph (`&`) pattern selects resources, not lines: 400
-  `pattern-dialect-unsupported` ({§pattern-dialect-find-only}); a matcher its mimetype cannot run answers the
-  matcher's own 415/400 ({§matcher-dispatch}).
-- §pattern-dialect-find-only **A `~` or `&` matcher outside FIND is refused as FIND's alone.** Every
-  400 `pattern-dialect-unsupported` — READ, EDIT, KILL, COPY, MOVE, SEND — names the model's
-  matcher and says only FIND takes it, and its recovery gives both working forms with the
-  model's own target: the FIND carrying that matcher, and the same operation with a text
-  pattern built from the symbol or words it named (regex metacharacters escaped, words joined
-  by `|`): `` Locate it with `FIND (django/urls/resolvers.py) &RoutePattern`, or select lines
-  with a text pattern: `READ (django/urls/resolvers.py) /RoutePattern/`. ``
+  matches is an empty read (204, `matched: 0`), never a failure. Full-text and
+  graph matches project their located occurrences through the same line
+  presentation. A matcher its mimetype cannot run answers the
+  matcher's own 415/400 ({§matcher-dispatch}). A selected value with neither
+  exact nor enclosing source coordinates answers 422 `pattern-source-unlocated`;
+  READ does not substitute an unrelated ancestor or the whole resource.
 - §read-fan-out **A READ over a glob reads every matching path.** `READ (pets_*.md)`
   and `READ (pets_*.md) /dogs/i` keep their glob ({§read-find-normalization} in the
   contracts SPEC) and dispatch fans them out: the ordinary FIND over the same
@@ -2120,8 +2142,24 @@ READ is the one fan-out core performs ({§read-fan-out}).
   receipt on the authored glob (`matched: 0` when a pattern selected nothing); a
   FIND failure is that failure on the authored glob. The FIND's resource page bounds
   the fan-out: when more paths matched than were read, one `read_fanout_bounded`
-  notice names both counts. A full-text (`~`) or graph (`&`) matcher selects
-  resources, not lines, so that READ dispatches as the FIND survey.
+  notice names both counts. Every dialect follows this same READ fan-out;
+  none substitutes a FIND receipt for the requested content.
+
+§read-pattern-evidence **Match regions survive line-oriented presentation.** A patterned
+READ retains `matches` ({§matcher-selection-signal}) for findings intersecting its
+returned text, in physical source coordinates. The body shows matching lines;
+its `range` describes that presentation, not the match boundaries. A match's
+region is never clipped into a different selection when a preview or authored
+READ scope shows only part of it. An empty read carries an empty match array.
+
+The packet projects each visible match's `locator`, exact `region`, or
+explicitly enclosing `enclosingRegion`
+using {§packet-extent-metadata}, without duplicating matched body text. Log
+curation removes metadata for matches outside the retained body. Match metadata
+uses the ordinary preview allowance ({§body-projection}), keeping only complete
+items; `matchLocationCount` appears when that preview omits locations. Exact
+FIND pages the complete location set ({§find-result-projection}).
+
 - §read-bytes A binary channel, and the `#bytes` view of
   any resource whose scheme supplies bytes, reads as the source bytes one hexadecimal
   octet per line: coordinate = line = byte, so `<a,b>` selects bytes, the markerless
@@ -2141,34 +2179,24 @@ READ is the one fan-out core performs ({§read-fan-out}).
   into a byte READ (`region` spans the hexadecimal lines of the matched bytes; `matched`
   is their hex). The load is bounded by the mimetypes binary input ceiling; a larger
   resource fails 413 `bytes-too-large` by name rather than being skipped.
-- §binary-parity A binary member is not a second-class resource. It behaves exactly as a text
-  member does for existence, FIND by path, KILL/delete, mimetype, weight, and membership; it
-  READs whole as its byte projection ({§read-bytes}) and, on a supporting route, contributes native
-  content to the next model request ({§packet-attachment-parts}),
-  READs and FINDs by byte range and byte pattern ({§read-bytes}/{§find-bytes}); and COPY or MOVE transfers
-  its bytes exactly, between file members and into or out of a DB-backed `worker://` entry alike. A
-  whole-resource transfer writes the source's bytes ({§read-bytes} `ByteSource`) verbatim to the
-  destination through the ordinary proposal gate, the receipt reporting the byte count rather than a text
-  line diff; "whole-resource" is the markerless selection or `<1,-1>` ({§move-canonical-whole-source}),
-  and a MOVE deletes the source after the destination lands. A **byte range** `<a,b>` transfers exactly
-  those source bytes (coordinate = byte, 1-indexed inclusive). A transfer **into** a destination byte
-  range is a splice: `<c,d>` replaces exactly the destination bytes c..d with the source bytes and a
-  single position `<c>` inserts the source bytes before byte c (`<-1>` appends); every byte outside the
-  window is preserved, and the whole spliced result is re-written through the proposal gate. A binary
-  **lives in a DB entry** as its bytes base64 in the channel's TEXT content; the same READ, byte range,
-  and COPY/MOVE recover them through a byte source synthesized from that content, so a File member and a
-  `worker://` entry hold and yield a binary identically. An empty binary channel represents
-  zero bytes, not an unsupported format; whole COPY/MOVE preserves it. Failed acquisition
-  is not an empty success: its producer outcome remains authoritative for READ and transfer.
-  This supersedes the older blanket refusal (#140)
-  for both the file and the entry case. Native image/PDF/audio attachment facts come from the configured
-  mimetype handler over original bytes, whether supplied by a file or stored channel
-  ({§packet-attachment-parts}); the hexadecimal view remains available. The exceptions are narrow and
-  defined, each a clear receipt rather than a dead end: a binary region addressed by a **textual anchor**
-  rather than a numeric byte coordinate has no meaning (416 — bytes are not lines), **authoring** binary
-  content from a text EDIT body is impossible (a text emission cannot type bytes), and a scheme that keeps
-  no bytes for a binary channel — no disk file, no stored content — has nothing to transfer and says so
-  (415). None is the entry-storage dead end the older text named; that cell is filled.
+- §binary-parity Binary resources share ordinary existence, membership, FIND-by-path,
+  deletion, and proposal rules. Files supply native bytes; DB-backed channels store
+  them as base64 and recover the same bytes through their byte source. Empty binary
+  content is zero bytes, never an unsupported format. Acquisition failure preserves
+  its producer result and cannot become a successful empty transfer.
+
+| Binary operation | Contract |
+| --- | --- |
+| READ / FIND | Hexadecimal byte projection and byte-pattern coordinates under {§read-bytes}/{§find-bytes}. Eligible image/PDF/audio attachments use original bytes independently ({§packet-attachment-parts}). |
+| Whole COPY / MOVE | Markerless or `<1,-1>` transfers the original bytes verbatim ({§move-canonical-whole-source}); MOVE deletes its source after the destination lands. |
+| Source range or pattern | `<a,b>` selects 1-indexed inclusive bytes. Patterns use {§find-bytes}; a source scope admits complete matches. Fragments concatenate without separators. MOVE removes exactly those bytes after destination success. |
+| Destination range | `<c,d>` replaces bytes c..d; `<c>` inserts before byte c, `<0>` prepends, and `<-1>` appends. All coordinates name the pre-mutation source. Other bytes remain unchanged. |
+| Same-channel MOVE | Destination insertion and source removal use one pre-mutation snapshot and one proposal-gated write. Overlapping selections refuse with 409 before writing. |
+| Deferred MOVE | The source byte snapshot is retained as a content-hash precondition; changed bytes refuse removal with 409 `edit-collision`. A landed destination remains reported under {§copy-move-observation}. |
+| Mutation result | Ordinary proposal gate and byte count; no fabricated text diff. |
+| Text anchor on a transfer | 416: native byte coordinates are numeric. |
+| Text EDIT of native bytes | 415: an EDIT body authors text, not native bytes. |
+| Binary channel without a byte source | 415, not an empty success. |
 
 ### §log-history-projection Durable history and active projection
 
@@ -2250,7 +2278,11 @@ Coordinates and anchors retain the original body's physical lines; selection occ
 before omitted lines are removed, and sparse receipts retain their original line
 ordinals. Automatic previews remain retrieval bounds, not deletions. COPY can read
 an active log source under ordinary read authority, without minting log history;
-destinations and MOVE sources still require independently writable entry storage.
+entry destinations require independently writable storage; MOVE retires its
+source under {§move-decomposition}. A pattern spanning retained lines on either
+side of a curated gap maps to separate exact source regions, never to a bounding
+region that restores hidden lines. Concatenating those fragments reproduces only
+the matched readable text.
 Trimming invalidates derived search attachments; an in-flight derivation attaches
 only if its source projection is still current. Forks copy both projection facts;
 forensics always retain the complete immutable body and curation history.
@@ -2371,7 +2403,7 @@ The packet projects one actionable owner for each retrieval fact:
 | catalog/path FIND | `range` in resources | none | none |
 | broad matcher FIND | `range` in resources | per-resource match-location counts; a resource with exactly one match also carries that match's `locator`/`region` | nonzero complete `matchLocationCount` |
 | exact matcher FIND | `range` in match locations | each row's locator/region; a regex or glob row also carries `matched`, the matched text | none |
-| pattern READ ({§read-pattern}) | `range` over the physical lines | the selected lines with their ordinals and anchors | the heading's pattern and `matched`, the selected line count |
+| pattern READ ({§read-pattern}) | `range` over the physical lines | selected lines with ordinals and anchors; precise `matches` under {§read-pattern-evidence} | heading pattern and selected-line `matched`; `matchLocationCount` only when the metadata preview omits locations |
 
 Any row whose statement carried a heading pattern ({§matcher-option}) retains it
 in its H3, and a pattern mutation ({§edit-pattern}, {§kill-pattern},
@@ -2588,24 +2620,23 @@ Operand syntax: {§transfer-resource-selections}. Result projection: {§copy-mov
    channel is 404. Entry sources follow {§membership-source-projection}; active
    log sources follow {§log-readable-projection}. Binary sources transfer bytes
    under {§binary-parity}; text anchors resolve under {§line-anchors}.
-   - §copy-move-pattern **A source pattern selects whole matching lines; a
+   - §copy-move-pattern **A source pattern selects exact source spans; a
      destination is a place.** A source operand's heading pattern
      (```` ```COPY (notes.md) [{"pattern": "TODO"}] (todos.md) <-1> ````) runs
-     over the source text line by line, bounded by the source scope and by what
-     the source shows ({§log-readable-projection}); the selection is every line a
-     match touches, in source order, each with its own line separator exactly as
-     a scoped whole-line selection carries it. The result reports `matched`. Zero
+     over the addressed source channel, bounded by the source scope and by what
+     the source shows ({§log-readable-projection}). The selected fragments are
+     concatenated verbatim in source order, without invented separators or
+     enclosing line context ({§slice-semantics-compose-pattern}). The result
+     reports `matched` spans. Zero
      matches transfer nothing: 204 with `matched: 0`, and no destination is
-     created. A MOVE retires exactly the selected lines through the source's EDIT
-     path, one empty-body line splice per line in one batch guarded by their
-     anchors ({§edit-pattern}); within one channel the insertion and the removals
+     created. A textual MOVE removes exactly those spans through the source's EDIT
+     path, one empty-body exact splice per span in one batch guarded by their
+     anchors ({§edit-pattern}); byte selections use {§binary-parity}. Within one channel the insertion and the removals
      are one atomic batch, and a deferred MOVE ({§proposal}) retires the same
-     lines after acceptance. A curated source retires rows, not lines of its
+     spans after acceptance. A curated source retires rows, not arbitrary text of its
      projection, so a pattern MOVE from `log:///` is 400 `pattern-unsupported`
-     (COPY the lines, then KILL its rows by pattern); a pattern on a binary
-     channel is 400 `pattern-unsupported` (bytes have no lines); a pattern on
-     the destination is 400 `pattern-destination-unsupported`; resource-selecting
-     dialects (`~`, `&`) are 400 `pattern-dialect-unsupported`.
+     (COPY its selected text, then KILL its rows by pattern). A pattern on
+     the destination is 400 `pattern-destination-unsupported`.
 2. Resolve destination path, channel, and optional text scope. Source and
    destination mimetypes must be compatible under {§mimetype-verbatim-transfer}
    or the result is 415. Destination anchors
@@ -2768,7 +2799,7 @@ same durable liveness.
 | New unpublished message | Continue; publish it in the next packet. |
 | Fresh operation/parser failure, without an authored WAIT | Continue before any automatic parking. |
 | Neither an authored WAIT nor an eligible completion request ({§kill-conclusion}) | Continue, regardless of earlier replies or live work. |
-| Live work and either WAIT or an eligible completion request | Park the same loop; message arrival, child or stream settlement, or stream cadence wakes it. No final-answer body is delivered while joining. |
+| Live work and either WAIT or an eligible completion request | Park the same loop; message arrival, child or stream settlement, or wait expiry wakes it ({§worker-wait-timing}). No final-answer body is delivered while joining. |
 | WAIT without live work | Continue; never invent a future wake. Its row says only `Nothing is in flight. Continuing.`, however often the loop yields this way. |
 | Unobserved operation results, failures, child results or stream conclusions | Continue; the next packet presents them. |
 | Eligible completion request with no unpublished arrivals, live work or unobserved results | Conclude successfully, whether or not it delivers an answer. |
@@ -3115,14 +3146,10 @@ executor target is refused `scope-unsupported` (400), naming the field.
 | `turn`       | Reaped at the worker's next pre-turn via the registry abort, before the turn's own spawns, so it never survives into the subsequent turn; its terminal output surfaces born visible like any close ({§exec-stream}). |
 | `detached`   | Outlives its loop's terminal, 200 included. It never binds to the loop's teardown and is nobody's obligation — completion is not gated by it, WAIT does not park on it, optimistic settlement looks past it — and it ends only by KILL, the worker's total reap, or daemon shutdown; its late conclusion surfaces without opening a loop. |
 
-**Cadence is the daemon's, never the model's.** While a loop is parked on an open
-stream the daemon wakes it on the worker's exponential backoff
-(`PLURNK_SERVICE_EXEC_POLL_SEC`, `PLURNK_SERVICE_EXEC_POLL_TURNS`, floored by
-`PLURNK_SERVICE_OPTIMISTIC_WAIT_MS`) to inspect progress; it does nothing while
-the loop is active, because ambient stream deltas already surface progress.
-Closure is a wake edge regardless. Child-only joins never use this timer: child
-settlement is their durable wake edge. A recurring check on the calendar is a
-schedule targeting yourself ({§schedule-delivery}), not a loop that polls.
+Observation timing belongs to the bounded wait ({§worker-wait-timing}), separately
+from execution lifetime. Wait expiry permits inspection of still-running work;
+closure remains an independent wake edge. Active loops already receive ambient
+stream deltas. Calendar recurrence remains a schedule ({§schedule-delivery}).
 
 §exec-host-proposes **Effect-gating.** Each executor — and each scheme operation that mutates something outside this process — declares an `effect` (`pure` | `read` | `host`); the service maps it to policy (`EffectPolicy`). The declarer states the FACT, the panel decides the POLICY, and one rule covers every operation: nothing that changes the world runs on nobody's authority. A `host` runtime (subprocess; file-backed sqlite) proposes under {§proposal}, and so does an outbound request that mutates a remote resource ({§http-outbound-proposes}). Once accepted, it spawns and writes channels at its workspace execution address ({§execution-output-identity}), returning `102 Processing`. Channel state transitions (`active` → `closed`/`errored`) drive subsequent observations ({§channel-state}).
 
@@ -3188,7 +3215,7 @@ two states and no others:
 
 | state | what the model receives |
 |---|---|
-| active | nothing in the Log. The `## Delegation` stream pointer names the stream with each channel's size and its growth since the last packet ({§child-orientation}); the model READs any range it wants, and every READ of a stream channel carries `terminal: false` while it runs and `terminal: true` once it has concluded, so an empty page is never mistaken for a finished command that printed nothing. |
+| active | nothing in the Log. The `## Delegation` stream pointer reports timing and channel activity ({§child-orientation}); the model READs any range it wants, and every READ of a stream channel carries `terminal: false` while it runs and `terminal: true` once it has concluded, so an empty page is never mistaken for a finished command that printed nothing. |
 | terminal | ONE `origin=_plurnk` READ at the execution's channel address, born visible, that is exactly a markerless READ of the channel — its bounded first page ({§read-selection-projection}, the whole channel when it fits, the channel's own mimetype), the `range` or `region`, terminal status and Problem, `terminal: true`, and any producer-supplied integer `exitCode`. The packet writes the read resource as its operand, exactly as an explicit READ does ({§log-address-metadata}). |
 
 §stream-observation-result **One liveness fact.** The durable READ result owns
@@ -3517,6 +3544,20 @@ Capability admission precedes this decision, so proposal disposition cannot gran
 
 The durable row is lifecycle evidence and the lookup key, not a serialized callback. `subscriptions.open()` establishes both halves before yielding a composed `StreamSubscription`: an `AbortSignal` whose fused `notifyChunk` and terminal `close` methods are safe to retain without the operation's general `SchemeCtx`. `close(result, summary?, channelResults?)` validates one universal terminal producer result plus exact named channel overrides. One SQLite transition closes the subscription and installs each channel's terminal `producerResult`; its lifecycle state derives from that result. The transition then wakes the worker when appropriate and unregisters the live handle. `close_status` is a constrained relational projection of `close_result.status`, never an independent result, while `channel_results` preserves historical overrides after a later subscription replaces the channel's current evidence. A durable open row without a live handle is an explicit lifecycle failure, never a fabricated cancellation success. Channel state ({§channel-state}) + log entries ({§no-chunk-rows}) carry lifecycle.
 
+§subscription-finalization Executors and scheme subscriptions share the durable
+close boundary. Concurrent closes join one attempt; a committed close is
+idempotent, including its completion wake.
+
+| Boundary | Ownership and recovery |
+| --- | --- |
+| Persistence fails | Surface the cause, retain the terminal result and callable owner, and emit no completion wake. Another close or cancellation retries settlement, not execution. |
+| Persistence commits | Release ownership before observational delivery. Attempt channel notifications and the completion wake even if another observer throws. |
+| Observer fails after commit | Surface the cause without reverting terminal state, retaining a false live owner, or repeating delivery on another close. |
+
+Cancellation remains coalesced while work is live. Failed cancellation or
+failed settlement permits a subsequent cancellation attempt; it never converts
+the producer's already obtained outcome into a fictitious cancellation result.
+
 At process restart every still-open row is necessarily missing its callable owner. Boot
 settles it as interruption (`500`) and errors active channels before evaluating parked
 loops ({§worker-lifecycle-restart-recovery}); it never reports cancellation (`499`) or
@@ -4101,10 +4142,13 @@ The shared deadline bounds every phase, including observer delivery; forced
 shutdown may therefore lose notifications and reports the unfinished phase.
 
 §crash-only-stop The settle sequence is deadline-bounded
-(`PLURNK_SERVICE_STOP_TIMEOUT_MS`, default 30000): past the deadline each wait
+(`PLURNK_SERVICE_STOP_TIMEOUT_MS`): one absolute deadline spans daemon drains
+and the enclosing observability, database, and HTTP-listener cleanup. No phase
+renews the budget. The service joins core's bounded producer/observer drain
+before releasing enclosing resources, including on timeout. Past the deadline each wait
 is abandoned with a named error instead of hanging the daemon on a child that
 never closes. A wedged child costs a forced shutdown; it must never cost an
-unbounded one. When the teardown settles, success or failure, the process ends
+unbounded one. Later cleanup phases are still attempted. When the teardown settles, success or failure, the process ends
 itself: `0` after a clean teardown, `1` after a reported one. A handle an abandoned
 wait left alive never keeps a stopped daemon running; the supervisor's kill is a
 backstop, not the exit.
@@ -4162,8 +4206,13 @@ transfer, or remove ownership of workspace tools or shared resources.
 
 §module-workspace-quiescence **A Functionality snapshot changes between
 workspace operations.** Mutation admission, external installation/removal,
-preparation, and publication hold the same exclusive gate. Explicit client
-mutations use `try` and fail 409 before effects while the workspace is held.
+preparation, and publication hold the same exclusive gate. Every mutation or
+background refresh acquires that gate before the family's serialization lane;
+turn-admission refresh uses its already-held gate. A queued background refresh
+cannot own the family lane while waiting for a turn that needs that lane.
+Settling the coordinator includes accepted refreshes waiting for that gate,
+not only work already inside a family lane.
+Explicit client mutations use `try` and fail 409 before effects while the workspace is held.
 Refused mutations reserve no queue position; a client retry is a new admission.
 An accepted model mutation uses `wait`, proceeding after its originating turn. Activation and turn-admission refresh use `none` inside
 their already-held demand boundary. Providers reject replacement while active
@@ -4518,7 +4567,9 @@ execution stream.** Preparation and publication share the family's serialized
 lane. Publication acquires workspace exclusivity after current turns release
 their leases; the invoking stream remains pending until publication completes.
 It then reports `active`, `unavailable`, or `authorization-required`, or the exact
-publication failure. A preparation failure may publish enabled-but-unavailable
+publication failure. Resource readiness is not execution liveness: a mutation's
+`202 authorization-required` body remains exact, while the finished manager
+execution closes with `200`. It does not wait for sign-in. A preparation failure may publish enabled-but-unavailable
 state; a publication failure never reports a successful mutation. Stream polling,
 waiting, and result observation use the ordinary execution lifecycle, without a
 separate deferred-commit queue. An explicit client action publishes now, rejects
@@ -4970,9 +5021,16 @@ time of measurement.
 - §tokenomics-neutral-telemetry **Curation telemetry is state, not response allowance.** The model-facing `Context Curation` section is one JSON object carrying `logTokensTotal` and `logTokensMax`. It never presents their difference as free response tokens. The protocol definition directly requires KILL of irrelevant log items and ranges to keep the next packet within the maximum. Per-entry weights remain on log rows where they describe visible cost and curation savings. Generic packet composition and physical-token speculation are absent.
 - §tokenomics-pressure-inventory **Pressure identifies its reclaimable concentration.** At `PLURNK_SERVICE_BUDGET_PRESSURE` of `logTokensMax`, a Markdown `> [!WARNING]` block follows the JSON with `> YOU MUST KILL superseded, stale, or irrelevant log items and ranges.` New output withholding replaces that mandate under {§context-output-warning}. The JSON may include `logTokensLargest`: at most `PLURNK_SERVICE_BUDGET_LARGEST_ITEMS` retained log items, each `{path, logTokens}`, ranked by that charge descending and then path. Native-only, suppressed, and metadata-only items remain eligible: whole-item KILL can reclaim their actual contribution. Include the largest prefix that fits; drop the optional list before the warning. Both participate in the final fixed-point total and complete request admission check.
 - §tokenomics-content-hash-identity **Content identity, not per-tokenizer counts.** A settled channel's `content_hash` (SHA-256) is its body's identity in the content store ({§content-store}); a writer may bind it, a bound hash must match the content, and an active stream has none until it settles. `weight` is stored beside that content and is never keyed or recomputed by model.
-- §tokenomics-provider-usage **Provider accounting is physical-request evidence, not curation state.** Every issued physical request has one durable pre-I/O `provider_requests` identity beneath the normalized {§inference-ledger} and settles once as response or error. Each record preserves conventional {§provider-usage} quantities and required {§provider-cost} evidence; an unreported quantity remains absent, including on response-less failures, and is never replaced by zero. `model_calls` own response/failure evidence, `turn_attempts` specialize emission admission, and `provider_requests` are the sole durable accounting representation. Emissions, BARE calls, rejected responses, retries, failovers, and errors therefore remain cardinal and ordered. Turn, loop, worker, workspace, digest, and protocol accounting are derived from those records through the shared {§provider-accounting} projection; only emission calls contribute the latest-packet context gauge. The baseline stores no floating-point money, denormalized totals, or rollup triggers. A documented direct charge becomes `charged`; otherwise the provider may compute an exact-decimal USD `estimated` amount from complete usage and the exact model's Models.dev rates; insufficient evidence becomes `unknown`. Derived `costUsd` sums every USD-expressible request and is `null` only when no request is expressible; a response-less failure or an uncataloged model is skipped, never allowed to erase the expressible evidence. Each derived aggregate usage field independently sums its reported quantity, so heterogeneous detail coverage remains partial rather than becoming fictitiously complete. This is operational request accounting, not invoice reconciliation. Output and reasoning are quantities the model cannot KILL, so they never alter the model-facing Budget ledger.
+- §tokenomics-provider-usage **Provider accounting is physical-request evidence, not curation state.** Every issued physical request has one durable pre-I/O `provider_requests` identity beneath the normalized {§inference-ledger} and settles once as response or error. Each record preserves conventional {§provider-usage} quantities and required {§provider-cost} evidence; an unreported quantity remains absent, including on response-less failures, and is never replaced by zero. `model_calls` own response/failure evidence, `turn_attempts` specialize emission admission, and `provider_requests` are the sole durable accounting representation. Emissions, BARE calls, rejected responses, retries, failovers, and errors therefore remain cardinal and ordered. Turn, loop, worker, workspace, digest, and protocol accounting are derived from those records through the shared {§provider-accounting} projection; only emission calls contribute the latest-packet context gauge. The baseline stores no floating-point money, denormalized totals, or rollup triggers. A documented direct charge becomes `charged`; otherwise the provider may compute an exact-decimal USD `estimated` amount from complete usage and the exact model's Models.dev rates; insufficient evidence becomes `unknown`. Complete totals and known subtotals remain distinct under {§provider-accounting}; unknown requests cannot impersonate free requests, and missing usage never becomes zero. This is operational request accounting, not invoice reconciliation. Output and reasoning are quantities the model cannot KILL, so they never alter the model-facing Budget ledger.
 - §tokenomics-negative-pressure **Negative curation pressure is honest but never submitted.** The provisional readout may report `logTokensTotal` above `logTokensMax`. Crossing the maximum withholds new returned output under {§context-output-admission}; no over-ceiling packet reaches `provider.generate`. Output admission creates neither a strike nor another turn.
 
+Each physical request also retains {§provider-request-evidence}, atomically
+with its accounting settlement. Failure does not discard received fragments.
+The digest emits one linked `requests/<id>.json` artifact per physical request,
+including unavailable evidence as `null`, reading heavy records one at a time.
+Failed partial operations and reasoning remain forensic data only; they never
+execute, enter model history, or become a later request's successful output.
+
 ### §context-output-admission Budget enforcement: returned-output admission
 
 Operations and their results are execution history. Packet admission controls
@@ -5377,7 +5435,7 @@ retain distinct contracts and lifetimes.
 - **Self-explaining rows.** A problem `title` names the stable class and `detail` states the occurrence-specific cause. Producer-known operands belong in factual extensions. `stage` appears only when neighboring stages imply different recovery; `recovery` states one generally valid next action; `retryable` is true only when the producer recommends automatically retrying the identical request. Unknown recovery or retryability is omitted rather than guessed. General workflow teaching stays in the packet rather than being duplicated into every failure. The runtime-neutral writing contract is owned by `@plurnk/plurnk-contracts`.
 - **Exact Problems cross durable and external boundaries.** Scheme capabilities, proposal application, subscription conclusion, loop settlement, AG-UI, clients, digests, and benchmark records preserve the originating Problem object. The model packet alone derives `{§problem-projection}` without mutating that object. An adapter may add a missing durable `instance`, never replace an existing one; it must not rebuild failure truth from `status`, `detail`, `RUN_ERROR`, a scheduler projection, or a legacy string. A failed boundary without a valid Problem is a contract violation and fails hard.
 - **Caught diagnostics are bounded.** Core-owned Problems may include a bounded preview of a caught runtime diagnostic when it states the occurrence-specific cause. `PLURNK_SERVICE_ERROR_DETAIL_LIMIT` owns that model-facing character bound; complete errors remain in daemon diagnostics. Input validation and stable contract failures do not spend this allowance on implementation text.
-- §notice-drain-on-read **Notices** - the few observations that are not log rows render one terse line under their distinct `## Notices` section, never a JSON dump. Packet rendering normalizes whitespace, bounds the producer message with the shared preview limits, and appends any typed position. The notice buffer drains on read; event Notices appear on at most one packet. Stateful derivation progress and provider availability coalesce in the buffer, so clients observe every checkpoint live while a later model packet receives only the current state under ordinary level filtering.
+- §notice-drain-on-read **Notices** - the few observations that are not log rows render one terse line under their distinct `## Notices` section, never a JSON dump. Packet rendering normalizes whitespace, bounds the producer message with the shared preview limits, and appends any typed position. The notice buffer drains on read; event Notices appear on at most one packet. Parking preserves pending notices for that loop's next packet; another loop cannot consume them. Terminal cleanup, including cancellation while parked, discards undelivered notices. This buffer is process-local, not restart-persistent. Stateful derivation progress and provider availability coalesce in the buffer, so clients observe every checkpoint live while a later model packet receives only the current state under ordinary level filtering.
 - §rail-accounting-private **Rail accounting is private.** Visibility is owned by {§engine-rails}: the model sees concrete failures from admitted turns, never rejected emissions, attempt counts, the strike streak, or cycle detection. Surfacing internal state creates a gamification surface where the model optimizes for engine metrics instead of the task.
 
 **The error rows (one channel) + the only non-log notices:**
@@ -5401,7 +5459,20 @@ retain distinct contracts and lifetimes.
 
 §notice-event-notify **Client surface.** Engine Notices broadcast live via the `notice/event` notification — `{ workerId, loopId, notice: { source, kind, level, message?, position?, …kind-specific } }` per the grammar's `Notice` schema — the moment they land. A loop Notice names its owning Worker; workspace derivation progress alone carries `workerId=null, loopId=0`. AG-UI projects the same observation as the custom `plurnk.notice` event. Failures do not broadcast on this surface: they are log rows, and the client reads them through `log.read` / the `log/entry` notification, the durable log.
 
-§loop-status-notice **The drain beats the loop's lifecycle on the notice channel.** When the drain claims a loop to run it broadcasts `notice/event` `{ workerId, loopId, notice: { source: "engine:lifecycle", kind: "loop_status", level: "info", status: 102 } }`, and when it leaves a loop parked ({§loop-wake-identity}) the same with `status: 202`; a wake that the drain claims again is another `102`. The beat is transient: broadcast to the workspace like any notice ({§notice-event-notify}), never a log row, never in a packet. Terminals stay `loop/terminated`'s; a client that reads the beat has the running/parked edges a parked delegation otherwise never publishes.
+§loop-status-notice **The drain publishes lifecycle and its observation deadline together.**
+`notice/event` carries `{ workerId, loopId, notice: { source: "engine:lifecycle", kind: "loop_status", level: "info", status, waitUntil } }`.
+
+| Edge | `status` | `waitUntil` |
+|---|---|---|
+| Claimed to run | 102 | `null` |
+| Parked | 202 | Persisted Unix-millisecond observation deadline, or `null` for an untimed park |
+| Woken, awaiting dispatch | 100 | `null` |
+
+Park observations and wakes use the worker's existing drain serialization, so
+an earlier park cannot overwrite a later wake's cleared countdown.
+The beat is transient: broadcast to the workspace ({§notice-event-notify}), never
+a log row or packet. Terminals remain `loop/terminated`'s. Reattachment obtains
+the same deadline through {§application-loop-observation}, not a restarted clock.
 
 §share **A share is the database's record, ready to send.** `plurnk-service share [<file.db>] [<folder>]`, and `npm run share` from a checkout, take a consistent copy of the database (`VACUUM INTO`; a live database is never read in place), and write its digest into `<folder>`, an ordinary folder the user archives or attaches however they like. Without a database the service's own is shared. Nothing is overwritten: a folder that exists and is not empty is refused, and a caller reusing a place removes it first. The share is the user's bug report and our dogfood, benchmark and forensics artifact alike.
 
@@ -5486,11 +5557,13 @@ final packet and the newest attempts always testify. A windowless witness
 
 §turn-accounting-notice **The completion beat carries the spend.** `turn_generated`
 carries the turn's exact settled wire accounting — request count, exact nullable
-USD, and token totals across every physical exchange the turn paid for, failed
+USD and token totals with separately named known subtotals across every physical exchange the turn paid for, failed
 calls included. It is the shared exact derivation from the ledger, never a second
 stored fact, so a live watcher accrues running loop cost per turn (#465).
 
 §notice-content-offset-pointer **Content-offset position.** A non-fatal diagnosis on an accepted emission (for example `grammar_unenforced` or `parse_advisory`) carries `position: { type: "content-offset", line, column }` into the model's exact `ops://<worker>/<loop>/<turn>` source; the transcript shows that turn's canonical emission instead ({§emission-row}), so the position names a line of the source, which READ of its address shows. A bounded hard parse error becomes a durable failed operation whose Problem Details preserve its line, column, source, and parser-owned diagnostic. Hard errors that make the frame untrustworthy remain only with their rejected forensic attempt.
+Reasoning normalization notices use source `grammar:reasoning` and omit the
+content-offset position: reasoning coordinates do not address the content source.
 
 ### Executable tool resources
 
@@ -5543,6 +5616,12 @@ with a multiline regex over matching fences), so turn 0 names every tool with it
 signature — one row per tool, paged like every survey. Capability attenuation
 restricts that matcher to the admitted exact tools. No document is delivered
 unasked.
+When the registry supplies {§executor-tool-catalog} definitions, the family
+document links to its sibling `<runtime>.json`. The catalog contains exactly
+the effective tools and is an ordinary `application/json` resource for READ,
+FIND, and JSONPath selection. It follows the same reconciliation as the family
+document and per-tool schemas; neither the catalog nor its definitions are
+automatically included in turn 0 or expanded-tool surveys.
 Attached tools are capabilities like every other runtime; the model never
 learns an origin.
 
@@ -5873,7 +5952,17 @@ container identity.
 | ------------ | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
 | `&<symbol`   | In-scope resources that reference `symbol`                                       | Each matching reference's source span                                     |
 | `&>symbol`   | In-scope resources defining names referenced by each definition of `symbol`      | Each referenced symbol's definition span                                  |
-| `&symbol`    | Union of definitions of `symbol`, referrers, and definitions of referenced names | Corresponding definition/reference spans, deduplicated by resource + span |
+| `&symbol`    | In-scope resources defining `symbol` | Each definition's source span |
+
+Graph storage preserves the handler's complete text coordinates, including
+reference columns and end positions. Match evidence and source text come from
+the same immutable derivation. A definition without handler-supplied columns
+selects its declared whole-line extent; a reference always retains its exact
+region. Matches are deduplicated by resource and complete region, not line.
+READ presents whole lines with that evidence ({§read-pattern-evidence}); EDIT
+replaces the selected region literally, not a semantic rename of the symbol.
+Upgrades invalidate obsolete derived indexes, never their source content or
+retained history ({§db-migrations}).
 
 | Result | HTTP status |
 |---|---|
@@ -5901,16 +5990,32 @@ one binary marker to fail a repository-wide text search.
 Glob anchoring (`TODO*` starts-with, `*TODO*` contains, `*.log` ends-with,
 `[Tt]odo*` character class) lives in the mimetypes framework.
 
+§derivation-in-flight **In-flight derivation and query are live uses.** An exact
+indexed operation holds its content-addressed artifact from derivation through
+the completed query. Producers hold artifacts while building and attaching
+them. Derivation and content collection share one per-database exclusion boundary:
+parallel uses remain parallel, a collection pass skips these two collectors
+while a use is active, and a new use waits for an already-running collection.
+Successful, failed, and cancelled uses release in `finally`; no durable pin or
+additional retention setting is introduced. The ordinary later pass or drained
+shutdown collects unattached artifacts under {§retention-policy}.
+
 ### Matcher selection and evidence
 
-- §matcher-selection-signal **Matching carries navigation evidence** - a matcher is a boolean resource predicate. Internally, each selected resource carries `matches: MatchEvidence[]`, where `MatchEvidence` is `{channel?,locator?,region?}`; `channel` names the entry channel the finding was located in and is absent for channel-less resources such as log rows, so line coordinates cannot be mis-attributed across channels of the same resource ({§channel-selection-visibility}). `locator` preserves a structural address without overloading the resource row's `path`; `region` is a complete four-coordinate `TextRegion` only when the finding maps honestly into the exact text the model can READ. Exact duplicate evidence deduplicates. Relation findings map their indexed source spans through the same readable text coordinate index. FIND alone decides whether that grouped selection projects as resource rows or flat locations ({§find-result-projection}); the engine never fabricates a region or guesses which surgical READ the model wants.
+- §matcher-selection-signal **Matching carries navigation evidence** - each selected resource carries `matches: MatchEvidence[]`, where `MatchEvidence` is `{channel?,locator?,region?,enclosingRegion?}`. `channel` identifies the entry channel and is absent for channel-less resources such as log rows ({§channel-selection-visibility}); `locator` preserves the structural address. `region` is the exact selection; `enclosingRegion` is presentation context only. Both use complete four-coordinate `TextRegion`s in the readable source. Exact duplicate evidence deduplicates. FIND projects this evidence as resource rows or flat locations ({§find-result-projection}); consumers never invent missing precision. An operation requiring exact source fragments refuses a selection containing unlocated or enclosing-only findings with 422 `pattern-source-unlocated`, before any mutation.
+
+§matcher-index-readiness **Indexed patterns require complete evidence.** A held
+resource snapshot whose search derivation is excluded or failed answers 422
+`search-unavailable`, preserving the reason. Graph selection requiring an
+unsettled relationship universe answers retryable 503 `search-index-incomplete`.
+Neither condition is a successful empty match.
 
 §matcher-result-resource-selection **A matcher selects resources; it never extracts a value or chooses a retrieval
 window.** Every dialect answers whether a resource matches and may return
-`MatchEvidence { locator?, region? }` ({§matcher-selection-signal}). `locator` is a
-canonical structural locator. `region` is a complete `TextRegion` in the exact
-text the model can READ and may be exact or the smallest honest enclosing
-region. A matcher miss is 204. FIND's target shape projects the selected
+`MatchEvidence { locator?, region?, enclosingRegion? }` ({§matcher-selection-signal}).
+`locator` is a canonical structural locator. `region` is an exact selected
+`TextRegion`; `enclosingRegion` identifies presentation context, not a selection.
+Both address the physical text the model can READ. A matcher miss is 204. FIND's target shape projects the selected
 resources according to {§find-result-projection}.
 
 | Dialect | Selects | Natural use |
@@ -5946,16 +6051,17 @@ One/two-coordinate line shorthand is newline-aware so deleting a line does not
 leave an empty line. A terminal position after a final newline is an exact
 insertion anchor, not an additional whole line. `<1,-1>` selects all content.
 
-§zero-width-column-one-insert **A zero-width region at column 1 inserts whole lines.** The
-schemes region algebra ({§slicer-text-algebra}) inserts every body verbatim; the missing
-newline is a fence artifact, so core repairs it where a fenced EDIT body becomes inserted
-content, through the one schemes helper `wholeLineBody`, at the mutation and again in the
-receipt and anchor-continuity recomputation so every site sees one body. At `<L,1,L,1>`,
+§zero-width-column-one-insert **An authored zero-width column-1 scope inserts whole lines.**
+Core prepares that fenced EDIT body once, using `wholeLineBody`, before handing
+literal replacements to the scheme. Mutation, receipt, and anchor-continuity
+calculation all consume that same prepared body. At `<L,1,L,1>`,
 an anchored `<@hash,1,@hash,1>`, or `L` = final line + 1 when the content ends with a
 newline, a non-empty body that does not end in a newline is inserted with the content's
 line separator appended, so `X` at `<2,1,2,1>` into `a\nb` yields `a\nX\nb`. An empty
 body inserts nothing. A zero-width region at any other column stays a byte-exact insert with
-nothing appended. COPY and MOVE transfer source bytes, not a fenced body, and are untouched.
+nothing appended. A pattern's generated coordinates select exact matches, not
+authored line-insertion syntax: `/^/` inserts a literal prefix without adding
+a newline. COPY and MOVE transfer source bytes and are likewise untouched.
 The runtime also tolerates an authored three-coordinate
 `<startLine,startColumn,endLine>` scope, immediately lowers it to the complete
 four-coordinate region ending after the final code point of `endLine`, and
@@ -5974,10 +6080,31 @@ down; overlaps and duplicate insertion boundaries are 409. This is the adopted
 SARIF region/replacement algebra for exact spans and same-snapshot ordering, not
 adoption of the SARIF interchange envelope.
 
-§slice-semantics-compose-pattern **Compose from evidence.** A match region already uses the four-coordinate
-scope shape. A follow-up ```` ```READ (resource) <SL,SC,EL,EC> ```` retrieves that exact
-region. JSONPath/XPath remain locators and matchers; they do not introduce a
-second structural scope or structural EDIT language.
+§slice-semantics-compose-pattern **One selection, independent of operation.**
+A pattern runs over the canonical source channel, never a READ receipt's
+line-ending normalization, preview, coordinate prefixes, or other presentation.
+A match region uses the four-coordinate source scope. FIND reports it, READ
+shows its lines with that evidence, EDIT replaces it, COPY transfers it, MOVE
+transfers then removes it, and a textual KILL removes it. Enclosing display
+context never enlarges the selected span. Multiple fragments retain source
+order and literal text; COPY/MOVE insert no separators between them. Scope
+composition admits complete matches, never clipped fragments or other matches
+on the same line. Mutation batches retain {§edit-batch-merges} and collision
+handling; a pattern does not create another overlap-recovery algorithm.
+
+FIND retains locators even without source coordinates. READ may display
+`enclosingRegion` as context, but a selected value with neither kind of location
+returns `422 pattern-source-unlocated`. EDIT, COPY, MOVE,
+and textual KILL require exact `region` evidence for every selected match;
+enclosing or unlocated values return that same Problem without changing any
+source or destination. Absence of matches remains an ordinary empty selection.
+
+A follow-up ```` ```READ (resource) <SL,SC,EL,EC> ```` retrieves the exact
+region. JSONPath/XPath remain locators and matchers, not a structural update
+language: `//item` selects the element, `//item/text()` its direct text nodes,
+and `$.host` the JSON value including its lexical quotes/escapes, never the
+property name or colon. Literal replacement does not serialize a value or
+repair neighboring punctuation. Readable projections have their own coordinates.
 
 ### §ext-mimetype Path-extension declares mimetype
 
@@ -6038,7 +6165,7 @@ Auto-derived text mimetypes anywhere in plurnk-service normalize to `text/markdo
 Carried from the contract walk; durable.
 
 - **Dialect/mimetype mismatch** → 415 (xpath on text/plain → 415; jsonpath on JSON-shapeless mimetypes → 204 because outline is empty, not 415).
-- **Binary markers** → 415 for text operations. A readable binary source is durably represented as projected `text/markdown` under {§membership-source-projection}; source-aware File EDIT remains 415.
+- **Binary coordinates** are numeric byte positions for READ and transfer; text EDIT does not author native bytes ({§binary-parity}). Readable projections retain their own textual coordinates ({§membership-source-projection}).
 - **EDIT `<L>` on non-existent entry** → body becomes content; `<L>` is positional-only on existing content.
 - §copy-l-source-range **COPY/MOVE source scope** selects only the addressed source channel and
   first resolves and, when required, prepares the same canonical
@@ -6059,7 +6186,7 @@ Carried from the contract walk; durable.
   {§copy-move-observation}.
 - **READ rx** prefixes every textual line under {§render-rule-line-navigable-prefix}; eligible
   editable resources carry `@hash N:`, and all others carry `N:`.
-- **FIND pattern** (`[{"pattern": …}]` in the heading, {§matcher-option}) applies to the addressed entry channel (all dialects), per-candidate via the in-tree `Matcher.matchAgainstContent` ({§matcher-dispatch}; status 200 = content hit → entry selected). The target scope and channel select candidates; the path-glob is the (target). On READ, EDIT, KILL, COPY and MOVE the same heading pattern selects lines within one resource ({§read-pattern}, {§edit-pattern}, {§kill-pattern}, {§copy-move-pattern}).
+- **Pattern selection** applies to the addressed source channel under {§slice-semantics-compose-pattern}. The path and channel select resources; FIND reports matches and READ displays their lines. EDIT, textual KILL, COPY, and MOVE act on exact selected spans, not their enclosing lines ({§read-pattern}, {§edit-pattern}, {§kill-pattern}, {§copy-move-pattern}).
 - **Scoped KILL** on the **log** (`log:///`) removes a body span from its readable projection ({§log-kill-scope}); on an entry it deletes that span through the EDIT path ({§kill-scope-entry}). A whole-entry KILL deletes the entry, or one `#fragment` channel.
 - **File scheme** detects with `Mimetypes.detect({ path })` and classifies with the same configured service ({§mimetype-classification-consumption}). Handler-declared binary sources materialize through {§membership-source-projection}; projected bodies are READ-able, while source-aware EDIT remains 415.
 
@@ -6067,7 +6194,14 @@ Carried from the contract walk; durable.
 
 A KILL with a text-coordinate scope aimed at an entry-bearing scheme deletes exactly that span: core prepares and dispatches it as an EDIT with an empty body over the same marker, so anchors resolve, proposals gate it, and the merge facts and receipt are the EDIT path's — while the log row records the model's KILL. Its packet metadata and canonical log body use {§edit-result-receipt-projection}. ```` ```EDIT (path) <scope> ```` with an empty body remains the same act spelled the other way; the teaching names KILL.
 
-§kill-pattern **A pattern on an entry KILL deletes each matching line.** ```` ```KILL (path) [{"pattern": "beta"}] ```` takes the same EDIT path as a scoped KILL, expanded under {§edit-pattern} in whole lines: the resource is read once, the matcher runs line by line, and every line a match touches becomes one empty-body line splice in one atomic batch guarded by those lines' anchors. A numeric scope bounds the lines the pattern may touch. Zero matches change nothing (204, `matched: 0`); a whole-entry KILL never widens from a pattern that selected nothing. The receipt is the EDIT path's, compacted the same way: `matched` lines, the first deletion's `receipt` with its `removedText` ({§edit-receipt-removed-text}), and `last` for the final one. Node-selecting patterns (`//`, `$`) select whole lines here, as they name nodes with line extents; resource-selecting ones (`~`, `&`) are refused (400 `pattern-dialect-unsupported`, {§pattern-dialect-find-only}). The log stays the exception: a pattern on `log:///` selects rows ({§log-curation-set-selection}), and a stream scheme's KILL is process control, so a pattern there is 400 `kill-pattern-unsupported`.
+§kill-pattern **A pattern on a textual entry KILL removes exactly its matches.**
+It is the same empty-body EDIT under {§edit-pattern}, including exact column
+and multiline regions, scope, preconditions, proposals, and receipt. It has no
+separate line-deletion mode. Zero matches leave the resource unchanged (204,
+`matched: 0`); a pattern never becomes whole-resource deletion. The receipt
+counts selected spans and retains the first and last applied effects.
+Log KILL still selects retirement rows ({§log-curation-set-selection}); stream
+KILL controls a process and refuses a content pattern (`kill-pattern-unsupported`).
 
 ---
 
@@ -6087,7 +6221,7 @@ teardown. The runner joins the test body's cleanup before starting the next
 specimen. The shared workspace and story helpers cover setup, inference and
 oracle failures, preserve the primary failure when their cleanup also fails,
 and attempt every registered disposal.
-Provider attempt/recovery limits remain independent; a harness cancellation is
+The provider whole-call deadline and recovery policy remain independent; a harness cancellation is
 not evidence that the provider's own deadline expired.
 
 §provider-conformance-matrix **Every configured model alias is exercised through a