task-pipeline-skill 1.85.2 → 1.86.3

package/plugins/task-pipeline/skills/project-audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: project-audit
-description: "Use when someone asks what is actually true of a whole project right now — what is finished, what is half-built, what is broken, and what nobody has looked at. Walks a cold start: discover what the project is, run a registry of probes chosen from that, read production evidence (published artefact against source, CI history, telemetry present or absent), then leave a self-contained HTML report and a JSON sidecar so the next audit can say what moved. Read-only: it proposes board rows and commits nothing. Triggers - 'project audit', 'audit the project', 'codebase audit', 'state of the project', 'what is unfinished', 'project health check', 'аудит проекта', 'проаудируй проект', 'состояние проекта', 'что не доделано', 'аудит кодовой базы'. Not for: auditing one deliverable inside a run (that is the pipeline's own ladder), reviewing a diff, or checking a skill's construction — say 'без диагностики' to opt out."
+description: "Use when someone asks what is actually true of a whole project right now — what is finished, what is half-built, what is broken, and what nobody has looked at. Walks a cold start: discover what the project is, run a registry of probes chosen from that, read production evidence (published artefact against source, CI history, telemetry present or absent), then leave a JSON sidecar so the next audit can say what moved, and a self-contained HTML report on request. Read-only: it proposes board rows and commits nothing. Triggers - 'project audit', 'audit the project', 'codebase audit', 'state of the project', 'what is unfinished', 'project health check', 'аудит проекта', 'проаудируй проект', 'состояние проекта', 'что не доделано', 'аудит кодовой базы'. Not for: auditing one deliverable inside a run (that is the pipeline's own ladder), reviewing a diff, or checking a skill's construction — say 'без диагностики' to opt out."
 license: MIT
 compatibility: "The collector (scripts/audit.py) needs python3 and reads committed state, so it needs git. Probes needing gh, npm, network or a browser declare it and report blind when it is absent — degraded, never silent."
 ---
@@ -122,23 +122,36 @@ audit: what a fix costs is the fixer's decision, not the finder's
 ([`references/prioritisation.md`](../task-pipeline/references/prioritisation.md)). An audit
 that edits while it reads cannot be re-run to check itself.
 
-## A finding carries its consequence, or it is a hypothesis
-
-**A mechanism is derived from the code; the consequence lives in production.** A row
-written from the mechanism alone is indistinguishable from a real finding until
-somebody measures it — and one audit had **eight consecutive rows** rewritten by that
-measurement, two of which would have destroyed inventory if remedied as written,
-because both read an absence of sales as an absence of demand.
-
-So before a row may be written as a `finding` rather than as a hypothesis:
-
-1. **how often does the mechanism fire?** A query, a log count, a telemetry read — or
-   an explicit statement that it has never been observed to fire;
-2. **where the answer is *never*, the row is still worth keeping**, priced as
-   **latent**: the remedy is weighed against zero rather than against the mechanism's
-   severity;
-3. **where the measurement is impossible, that is a `blind` on the consequence** and
-   the row says so. A blind consequence is not a finding.
+## A finding keeps its axes apart, or it is a guess wearing a verdict
+
+**Mechanism status, exploit/reproduction, exposure, observed incidence and impact
+uncertainty are FIVE axes, not one.** A row written from the mechanism alone is
+indistinguishable from a real finding until each axis says what it knows — and one
+audit had **eight consecutive rows** rewritten by measurement, two of which would
+have destroyed inventory if remedied as written, because both read an absence of
+sales as an absence of demand. But the correction cuts both ways:
+
+- **A proven defect may have incidence UNKNOWN.** An auth bypass or a race
+  reproduced locally is a code defect BEFORE any incident — the reproduction is the
+  proof, and no production log is needed to license the row. A confirmed local
+  crash with no production logs stays a code defect, external incidence UNKNOWN.
+- **UNKNOWN ≠ 0.** A zero sample is not zero risk; absent telemetry lowers what can
+  be said about EXPOSURE, never the technical truth — and the row says which.
+- **Unknown attacker control lowers exploitability CONFIDENCE**, never the observed
+  behaviour: what was watched happening stays written as watched.
+- **A documented exception does not turn a failed invariant into PASS** — decision
+  status and technical validity are the separate axes of the section below.
+
+The incidence axis is still asked: **how often does the mechanism fire?** A query, a
+log count, a telemetry read. Where the answer is *never*, keep the row priced as
+**latent** (the remedy weighed against zero); where the measurement is impossible,
+the INCIDENCE axis records `blind` — and the finding stands on its mechanism and
+reproduction axes. Each row records its observation scope and time, keeping code
+mechanism, deployment observation and assumptions apart —
+`templates/finding-evidence.json` in task-pipeline is the minimal schema, and the
+collector writes `mechanism`/`incidence`/`observed_scope`/`observed_at` into the
+sidecar. Ask an operator only when the unknown would change the action — an
+interview is not a prerequisite for a row.
 
 Two rules follow from the same place:
 
@@ -159,9 +172,20 @@ Five of eight rows in one run were that.
 - **Read the call site, not only the definition.** A finding about a module is not
   written until the places that use it have been read.
 - **Every row states which of three it is:** *(a)* undecided, *(b)* decided and
-  documented right here, *(c)* decided elsewhere and not propagated. Only **(a)** and
-  **(c)** are work. **(b)** is the audit being wrong, and recording that is worth more
-  than deleting the row.
+  documented right here, *(c)* decided elsewhere and not propagated. **(a)** and **(c)**
+  are work — and so is a **(b)** that is still WRONG, because **decision status and
+  technical validity are DIFFERENT AXES.** A documented decision can be mistaken, stale,
+  or break an external contract; "it's by design" is not a proof of correctness. So a
+  **(b)** splits:
+  - **accepted trade-off** — a conscious limitation with a real, named cost the project
+    chose to pay (single-browser support under a matching contract): mark it *accepted
+    limitation* with its cost, not a defect.
+  - **documented violation** — a decision that STILL breaks a security invariant, an
+    external contract, or its own stated goal (an ADR that permits logging a refresh
+    token): this REMAINS a `finding`, carrying the `decision_id`, the reason to revisit,
+    and the counter-evidence. Recording a **(b)** the audit got wrong (a false positive)
+    is worth more than deleting the row; but excluding every documented decision from
+    findings is a systemic source of false NEGATIVES, which is the more expensive miss.
 - **Where the verdict is (c), the remedy is a mechanical check, not an edit.** A
   written rule nobody verifies reaches exactly as far as the place it was written; the
   durable fix in all five cases was a guard that asks the project's own instruction of
@@ -210,7 +234,12 @@ Two more traps, both of which shipped in the first draft and are now fixtures:
 ## The artefacts — the sidecar always, the page on request
 
 `docs/audit/<date>-audit.json` is written on every run. **The HTML page is written
-only with `--report`.**
+only with `--report`.** Three output modes, and only one needs a browser:
+**stdout** (`--stdout` — the summary in the terminal, nothing written but the
+sidecar), **json** (the sidecar alone, the default — a machine reads it, no
+page and no browser), **html** (`--report` — the page too). A json-only or
+stdout run **never opens a browser and never requires one**; the browser is a
+concern of `--report` alone.
 
 The split is not symmetry. The sidecar is what makes this a ratchet rather than a
 snapshot, and the next run reads it — skipping it would silently turn every future run
@@ -230,6 +259,13 @@ stdout: an audit must not become the second place a credential leaks. Redaction
 is total rather than a prefix — half a credential plus its context is often
 enough to finish.
 
+**"Read-only" is about the TARGET, not the disk.** The audit reads the
+project's source, data and production evidence and mutates NONE of it, and it
+commits nothing. It DOES write its own artefacts into its allowed output
+directory (`docs/audit/` by default, `--out-dir` to relocate) — the sidecar
+always, the page on `--report`. Writing the sidecar there is not a violation of
+read-only; writing into the target's source, or `git add`-ing anything, is.
+
 **The sidecar is what makes this a ratchet rather than a snapshot.** Each
 finding carries an id derived from its probe and its place, so it survives a
 rewording; the next run prints what closed, what is new, and what has now
@@ -252,16 +288,21 @@ could not look.
 
 ## Exit criterion
 
-An audit is finished when:
+An audit is finished when — the criterion is CONDITIONAL on the deliverables
+requested, not a fixed page-and-browser:
 
 1. every probe has a verdict, and every `blind` one names why;
-2. the page and the sidecar are written and the page has been opened;
+2. the sidecar is written (always). **On `--report`, and only then**, the HTML
+   page also exists, its internal links are safe and resolve, and its
+   inspect/render status is recorded (opened, or `--no-open` noted) — WITHOUT
+   `--report` no page is created and the run is still complete;
 3. **every number in the report was produced by a command this run executed** —
    a restated count is an assertion (`evidence-docs`);
 4. at least one figure was **re-derived by a differently-shaped command** and
    both were printed. Re-running the same command is a spell-check of the first
    run;
-5. the proposed rows are printed for the operator, with nothing written.
+5. the proposed rows are printed for the operator, with nothing written to the
+   target.
 
 ## Rationalizations
 

package/plugins/task-pipeline/skills/project-audit/scripts/audit.py

@@ -897,12 +897,23 @@ def open_in_browser(path, opener=None):
 
 def _finding(probe_id, where, title, severity, blast, effort, remedy,
              detail="", evidence=""):
+    # The axes stay apart (FIX-PA-02.01): every shipped probe reads the tree,
+    # so its MECHANISM is confirmed with evidence — while this collector
+    # measures no production, so INCIDENCE is "unknown", and UNKNOWN != 0: it
+    # never lowers the mechanism's truth, only what may be claimed about
+    # exposure. Scope and time of the observation ride in the sidecar so the
+    # next audit knows what was looked at, and when.
     return {
         "id": finding_id(probe_id, where, title), "probe": probe_id,
         "title": title, "severity": severity, "where": where,
         "detail": detail, "evidence": evidence, "remedy": remedy,
         "blast": blast, "effort": effort, "runs_open": 0,
         "first_seen": datetime.date.today().isoformat(),
+        "mechanism": "confirmed",
+        "incidence": "unknown",
+        "observed_scope": "local checkout",
+        "observed_at": datetime.datetime.now(datetime.timezone.utc)
+                       .strftime("%Y-%m-%dT%H:%M:%SZ"),
     }
 
 

package/plugins/task-pipeline/skills/task-pipeline/SKILL.md

@@ -12,12 +12,15 @@ own built-in doctrine — no companion plugin required. Keeps the main thread
 disciplined: no stage advances until its gate passes; the whole run uses one model,
 confirmed before it starts.
 
-**Grill first, then run autonomously.** A one-line task ("make me feature X") is
-never enough to finish without a human in the loop. Stage 0 is **mandatory**: a
-relentless, one-question-at-a-time interview that resolves every decision branch
-*and* sweeps stages 1→10 for anything that would stop the run later — then locks
-the answers into a brief. Autonomy is bought there or not at all; every question
-skipped at stage 0 comes back as an interruption at stage 6.
+**Grill first, then run autonomously.** Stage 0 is **mandatory**, but it is a
+GAP CHECK before it is an interview: the brief is built from the request, the
+files and the harvest first, and a question is asked only for a **material
+unknown** the sources cannot answer. A complete brief yields ZERO intake
+questions; what the request or the project already decided is recorded, never
+re-negotiated. The interview, where gaps remain, is one-question-at-a-time and
+sweeps stages 1→10 for anything that would stop the run later — then locks the
+answers into a brief. Autonomy is bought there or not at all; every MATERIAL
+question skipped at stage 0 comes back as an interruption at stage 6.
 
 **Config contract: [`pipeline.schema.json`](pipeline.schema.json).** A pipeline is
 a machine-readable config — an ordered list of stages, each with `skills[]` (the
@@ -25,9 +28,21 @@ skills/agents that run it) and a `gate {type, check}`. The schema is the univers
 contract; it imposes **no** specific stages, skills, or gate assignments.
 [`pipeline.example.json`](pipeline.example.json) is a **copy-and-rewrite example**
 that encodes this plugin's own default flow (stage 0 intake + the 1→10 stages
-tabled below) and an optional, toggleable `release` block. Any project replaces it
-wholesale — any number of stages, run by its own skills/agents, with its own gate
-types (see *Bring your own skills*). Each gate has a **type**: `auto` (the
+tabled below) and an optional, toggleable `release` block.
+
+**Two layers, and only one is replaceable.** The **KERNEL** is what every
+pipeline must carry no matter how few stages it has — for every unit of work:
+its **scope** (what it may change), its **evidence** (a claim carries its
+receipt), its **deps** (what it reads and what must precede it), and a
+**resume** point (it survives context loss). The kernel is invariant. The
+**PROFILE** is the STAGE LIST — how many stages, their names, their skills,
+their gates — and a project **replaces the profile wholesale** (any number of
+stages, its own skills/agents, its own gate types; see *Bring your own
+skills*). **The stage numbers belong to the SELECTED profile, never to the
+kernel:** a minimal three-stage profile has no "stage 7", and a rule keyed on a
+global stage number is a rule about the default profile, not about every
+pipeline. What a custom profile may drop is stages; what it may not drop is a
+kernel field. Each gate has a **type**: `auto` (the
 orchestrator verifies the `check` itself, pass/fail), `judgment` (no complete
 deterministic check exists — a named judge rules, and the ruling is recorded as
 judgement, never as a measurement; `references/gates.md` → *The judgment gate*)
@@ -48,53 +63,30 @@ wiki and the code graph are recommendations. The **one** exception is deliberate
 named: on a user-facing task the stage-3 UX track requires super-ux, and the spec
 gate stops until it is installed.
 
-| Stage | Built-in doctrine |
-|---|---|
-| 0, 9 · The documentation system | `references/documentation.md` |
-| any stage · The canons, and where each is enforced | [`evidence-docs`](../evidence-docs/SKILL.md) — the sibling skill in this plugin |
-| 6–10 · Gates | `references/gates.md` |
-| 7–8 · Deploy targets | `references/deploy-targets.md` |
-| any stage · Hooks | `references/hooks.md` |
-| 0 Knowledge harvest (pre-grill) | `references/knowledge-sources.md` |
-| 0, 9 The code graph (graphify — recommended, never required) | `references/knowledge-graph.md` |
-| 0 Intake grill | `references/grill.md` |
-| 2 Brainstorm | `references/brainstorm.md` |
-| 2 Decompose (platforms only) | `references/decomposition.md` |
-| 3 Spec | `references/spec.md` |
-| 4 Plan | `references/planning.md` |
-| the queue the loop walks | `references/work-graph.md` |
-| 5–8 · how a **work-graph node** is CLOSED — three blind readings at three distances, all three required (ceiling 3); a **prose-plan task** closes through `review.md` instead — one reviewer, five-round cap | `references/certification.md` |
-| 5 Build (worktree, subagents, fix loop) | `references/build.md` + `references/review.md` |
-| 5–6 TDD + suite gate | `references/tdd.md` |
-| 5, 6, 8 The browser — the look, the spec suite, and the difference | `references/browser.md` |
-| 10 Acceptance (REQ close-out) | `references/acceptance.md` |
-| 10 Retrospective (the run's last act) | `references/retrospective.md` |
-| 10 + any audit (what's *missing*) | `references/audit.md` |
-| **first run in a project** (new or existing) | `references/adoption.md` |
-| **first run · the entry audit** (offered once) | `references/setup.md` |
-| **what travels with the bundle vs stays in a project** | `references/portability.md` |
-| any repeating loop | `references/loop-guard.md` |
-| run-wide · what the run **leaves running and leaves behind** — every gate, and stage 10 | `references/residue.md` |
-| run-wide · what the run **prints about itself** — the rail, the iteration line | `references/progress.md` |
-| run-wide · how a run keeps going (the loop mode + the context budget) | `references/continuity.md` |
-| run-wide · the work-list **between** runs, and the order it comes off | `references/backlog.md` + `references/prioritisation.md` |
-| run-wide · whether a **human** ever confirmed what shipped, and when | `references/verification.md` |
-| run-wide · how much unconfirmed work has piled up, and what to look at first | `references/exposure.md` |
-| any stage · Where each artifact belongs | `references/artifacts.md` |
-| preflight · Companion skills and their fallbacks | `references/companion-skills.md` |
-| 6–10 · How the host project's CLAUDE.md is read | `references/conventions.md` |
-| preflight · Model map, ids and the override | `references/model-tiering.md` |
+Which reference owns which stage — all forty-odd of them, by stage number:
+[`references/doctrine-map.md`](./references/doctrine-map.md).
 
 **Optional bridge.** An equivalent skill set the operator already runs can be mapped
 onto stages 2/4/5/6 in `pipeline.json` → `skills[]`. That is a **substitution, never a
-requirement**: the built-in doctrine is normative, the gates in `references/stages.md`
-still govern, and nothing detects, recommends or waits for an external provider.
+requirement**. And the precedence is explicit, because two layers could seem to
+disagree: on a CUSTOM profile the **kernel wins** — scope, evidence, deps and
+resume are owed by every unit of work — while `references/stages.md` is the
+**default profile's** normative gate set, governing the stages that profile
+actually selects, not imposing its stage numbers on a profile that dropped
+them. The built-in doctrine is normative for the default profile; the kernel is
+normative for all. Nothing detects, recommends or waits for an external
+provider.
 
-**super-ux — recommended for ANY user-facing task**, and the one thing that can stop a
-gate. The moment a task implies an interface (web / mobile / CLI / TUI), the
-WHY→UI→scenario chain runs through `/ux` and its linter, which belongs in the host's
-CI so UX drift cannot merge. **Not installed on a UI task? The stage-3 spec gate
-stops** — offer the install and wait (`references/companion-skills.md`).
+**super-ux — the preferred provider for ANY user-facing task.** The moment a task
+implies an interface (web / mobile / CLI / TUI), the WHY→UI→scenario chain runs
+through `/ux` and its linter, which belongs in the host's CI so UX drift cannot
+merge. **But the stage-3 gate checks the ARTIFACT, not the package**: valid
+scenarios covering the change — produced by super-ux, by an alternative provider
+honouring the same contract, or written inline against
+`references/companion-skills.md`'s fallback — pass the gate. What stops the gate
+is the ABSENCE of any scenario artifact: then create one (super-ux is the
+preferred way, the inline fallback is the floor), and a missing tool is reported
+as the NAMED check that was not done, never as a failed task.
 
 **The grill is built in and mandatory** (`references/grill.md`). No "clear enough task"
 exemption and no stage 1 without a committed, operator-confirmed brief. It produces the
@@ -153,7 +145,8 @@ Three things the grill does beyond clarifying the request, each in full in
    is built in, so this only checks the *optional* companions (super-ux for UI
    tasks, context7, wiki-update, graphify) and emits ONE block covering them
    **and the model decision** (`references/model-tiering.md`): recommend
-   the most capable model available, let the operator confirm or override, record
+   the most capable model available (advice), let the operator confirm or
+   override (the choice — inherited verbatim by plan, stages and subagents), record
    it. Ask once, here. **The same block carries the run mode**
    (`references/continuity.md`): read `pipeline.json` → `run.loop`; where it is
    recorded, arm it **at the point `run.loop.arm` names** — here at preflight, or
@@ -180,6 +173,15 @@ Three things the grill does beyond clarifying the request, each in full in
 3. Walk stages 1→10 on the model confirmed at preflight. **Don't re-ask about the
    model at every boundary** — only when the operator recorded a per-stage override
    map and the next stage's entry differs (`references/model-tiering.md`).
+   **The SELECTED profile is compiled once, at preflight, and only ITS declared
+   stages and gates run** (FIX-TP-03.02): the numbers "1→10" name the DEFAULT
+   profile, and a custom profile with three stages runs three — no hidden stage
+   0, 7 or 10 is injected because the default profile has one. What a custom
+   profile does NOT escape is the KERNEL (03.01): scope, evidence, deps and
+   resume are owed by every stage of every profile, so dropping stages never
+   drops the evidence gate. And an unknown MANDATORY capability blocks the
+   compile — a profile whose `must_understand` names a capability this runtime
+   does not have is refused, never run with the capability silently absent.
    **Is the brief a platform rather than a change?** Then stage 2 also cuts it into
    modules (`references/decomposition.md`) and stages 3→10 run **per module** in
    build order, one brick at a time — stages 0–2 run once, and the module map's
@@ -259,4 +261,19 @@ Most references are routed from the **Built-in doctrine** table above, keyed by
 the stage that sends you there. The rest are routed by prose: `stages.md` (named
 at every stage of *How to run*), `learned.md` (cited where a rule binds) and
 `probing.md` (from `gates.md`, whose checks it proves). The config contracts sit
-beside this file: `pipeline.schema.json` and `pipeline.example.json`.
+beside this file: `pipeline.schema.json` and `pipeline.example.json`. The
+family's task/context contract sits there too: `execution-packet.schema.json`
+with `execution-packet.example.json` — an immutable, content-addressed packet
+per dispatchable unit of work, validated dependency-free by
+`scripts/packet.py` before anything acts on it (an unknown mandatory version,
+a ref without its digest, or an unbound decision is rejected at the door) —
+and its answer half, `execution-result.schema.json` with
+`execution-result.example.json`: an AttemptGrant that a boolean can never
+substitute for, and a ResultEnvelope whose stale candidate (older revision, or
+a superseded fence) re-plans instead of landing as current
+(`scripts/packet.py validate-result`). The compiler's first stage maps an
+audit report onto parent tasks (`scripts/context_packets.py compile|verify`):
+ids derived from finding ids — never positional, so a shuffled report compiles
+byte-identically — evidence/limits/priority in their own fields separate from
+status, and any row it cannot map blocks the whole compile rather than being
+dropped silently.

package/plugins/task-pipeline/skills/task-pipeline/execution-attempt.schema.json

@@ -0,0 +1,68 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "$id": "https://raw.githubusercontent.com/ssheleg/task-pipeline/main/plugins/task-pipeline/skills/task-pipeline/execution-attempt.schema.json",
+  "title": "task-pipeline execution attempt (grant)",
+  "description": "One attempt at running one node — the identity that a claim on a graph node carries, so `next` can be raced by two processes and only one wins. This is the record `graph.py acquire/start/renew/release/recover` reads and writes (the next implementation leaf); this schema is the contract those verbs must round-trip.\n\nThe defect this exists to close (PF-01): the node's `owner` is a ROLE name, not an identity. Two independent `next` runs both saw N-001 `pending`, both dispatched it, and a `running` node with no fenced grant could be left orphaned forever — `next` then exits 4 until a human edits the file. A grant is owned by a SESSION/ATTEMPT, fenced by a monotonic token and a node revision, and expires, so a lost holder is reclaimable and a stale holder's write is rejected by its own fence.\n\nState is `ready` → `claimed`: `ready` is a grant minted but not yet installed on the node; `claimed` is the live hold. There is no third value here — `done`/`blocked`/`parked` are the NODE's states in graph.schema.json, not the attempt's. The record is ISSUED by `scripts/execution_authority.py` (PF-01.02) — a durable single-writer SQLite coordinator whose `BEGIN IMMEDIATE` makes ready→claimed atomic, so two racing `graph.py claim` runs yield one winner; the `fence` here is that coordinator's monotonic lease generation, and `expiry` bounds the run in place of a held OS lock. Local filesystem only; a Fabric adapter replaces the coordinator for distributed execution.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "schema_version",
+    "node",
+    "owner",
+    "attempt",
+    "revision",
+    "fence",
+    "expiry",
+    "state"
+  ],
+  "properties": {
+    "schema_version": {
+      "type": "string",
+      "pattern": "^execution-attempt/[0-9]+$",
+      "description": "Contract version. A consumer that does not know the major REJECTS the grant."
+    },
+    "node": {
+      "type": "string",
+      "pattern": "^N-[0-9]{3,}$",
+      "description": "The graph node this attempt claims."
+    },
+    "owner": {
+      "type": "string",
+      "minLength": 1,
+      "description": "The SESSION/ATTEMPT identity that holds the claim — never a role name. Two `next` runs of the same role are two owners; that is the whole point. `graph.schema.json`'s node `owner` stays the ROLE; this is who is actually running it right now."
+    },
+    "attempt": {
+      "type": "integer",
+      "minimum": 1,
+      "description": "Which attempt on this node this is. A recovered node's next claim increments it, so a retry is distinguishable from the run it replaced."
+    },
+    "revision": {
+      "type": "integer",
+      "minimum": 0,
+      "description": "The node revision this claim was taken against. `start`/`renew`/`release` must present the revision they read; a write against a stale revision is refused — the compare in compare-and-swap."
+    },
+    "fence": {
+      "type": "integer",
+      "minimum": 1,
+      "description": "A monotonic fence token, strictly increasing across the node's lifetime. A held-then-lost owner that wakes up and writes carries an OLD fence, and the store rejects it — the guarantee that a zombie cannot clobber the run that reclaimed its node."
+    },
+    "expiry": {
+      "type": "string",
+      "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\\.[0-9]+)?Z$",
+      "description": "ISO-8601 UTC. Past it, `recover` may reclaim the node for a new attempt. UNKNOWN is not a value — a grant with no expiry is an orphan waiting to happen, so the field is required."
+    },
+    "state": {
+      "enum": [
+        "ready",
+        "claimed",
+        "completed"
+      ],
+      "description": "`ready` — minted, not yet installed on the node; `claimed` — the live hold. The node's own lifecycle (pending/running/done/blocked/parked) lives in graph.schema.json, not here."
+    },
+    "installed_at": {
+      "type": "string",
+      "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\\.[0-9]+)?Z$",
+      "description": "When the claim went `claimed`. Optional — a `ready` grant has none yet."
+    }
+  }
+}

package/plugins/task-pipeline/skills/task-pipeline/execution-packet.example.json

@@ -0,0 +1,42 @@
+{
+  "schema_version": "execution-packet/1",
+  "id": "FIX-EX-01.01",
+  "parent_id": "FIX-EX-01",
+  "module": "example-module",
+  "intent": "Split received from completed in the webhook reference so a crash between them stops losing the event.",
+  "inputs": [
+    {
+      "address": "docs/evidence/audits/example/leaves/FIX-EX-01.01.md",
+      "sha256": "9b64e93e16025c61cce840b5facbeed619927a20c07f6f919ac92816d6ddc3b6",
+      "role": "primary packet brief"
+    }
+  ],
+  "decision_refs": [
+    {
+      "id": "DEC-0007",
+      "address": "docs/decisions.md#dec-0007",
+      "sha256": "276e15892305979ae04a402971c6632a53c249412d99fbea1cf49b4795dbf622"
+    }
+  ],
+  "source_scope": {
+    "edit_targets": [
+      {
+        "address": "plugins/example/skills/example/SKILL.md",
+        "mode": "Edit",
+        "baseline_sha256": "a0dcc36937f50a8da38261c1c39afe6caeb0f31674cdf3baaac48c4c81defe32"
+      },
+      {
+        "address": "test/audit_regressions/fix-ex-01.01.py",
+        "mode": "Create_or_extend"
+      }
+    ],
+    "claim": "FIX-EX-01.01"
+  },
+  "budgets": {
+    "context_bytes": 24576,
+    "token_note": "estimate: utf8 bytes / 3.9 chars-per-token (the family's measured divisor)"
+  },
+  "acceptance": [
+    "A crash after the receipt admits a repeat worker; a duplicate of a completed event never grants again."
+  ]
+}