ptp-parcel-fast v8A

Immutable. This exact content never changes and is served at /api/v1/blob/cead454f335245a8.

---
name: ptp-parcel-fast
description: 'Activate this skill to run ONE committed parcel plan end-to-end under the locked AUTO + SINGLE preset — Phases 1-9 in a single run per plan, Gates A/B auto-cleared, Gate C N/A, terminating at PHASE_9 with Gate D OPEN. Invoked only by the `parcel-sprint` batch host (through the `ptp-parcel-fast` subagent); never user-selectable.'
version: 8
updated: 2026-09-20
---

# SKILL: Per-Plan Fast Runner (`ptp-parcel-fast`)

> **Boundary:** This skill owns exactly **one** plan's Phases 1-9. It is spawned by the `parcel-sprint` batch host (through the `ptp-parcel-fast` subagent) with a single plan path. It never walks the queue, never spawns anything, and never asks the Mode/Topology questions.

## Activation

- Owns one plan's Phases 1-9 in a single run.
- Locked preset: `Mode = AUTO`, `Agents = SINGLE`. **Never ask** the Mode or Topology selection questions.
- The lifecycle, gate set, and phase content are owned by `@pass-the-parcel`; this skill only fixes *how* they are sequenced for the batch path. Do not restate the pipeline.

## Per-plan chain (exact order)

1. Play `ptp-context-hunter` **inline** (Phases 1-3).
2. Play `ptp-phase3-answerer` **inline** (Phase 3.5).
3. Auto-clear Gate A (see *Auto-clear test*; the `AUTO` mode vocabulary is canonically homed in `.opencode/plans/base-context.md`).
4. Play `ptp-high-visionary` **inline** (Phases 4-5 — wiki spec + implementation plan + inline self-review).
5. Auto-clear Gate B; record Gate C `N/A`.
6. Play `ptp-code-surgeon` **inline** (Phases 8-9).
7. Commit the work with the exact message literal `plan: <code>`.
8. Set bottom **Status** `PHASE_9`, **Active Persona** `Executor`, leave **Gate D** `OPEN`, and set the claim front-matter `claim_status: GATE_D_USER_APPROVAL` — **not** `CLAIMED`. That value is what marks the plan as executed-but-unverified; it is the batch path's terminal claim state, and it is the state a dependent's `depends_on` accepts.

## Counter ownership (you never bump it)

`machinery-version` has **one writer per batch: the follow-up batch wrap-up**, reading the live value from `.devops/sync-manifest.yaml` at that moment (`.devops/rules/plan-lifecycle.md` § Claim Protocol → *Counter Ownership*; `@agent-wrap-up` § Batch Scope). This runner therefore:

- **never** bumps `machinery-version:` in `.devops/sync-manifest.yaml`;
- **never** writes a `.devops/logs/version-history.md` row;
- **does** still re-inline the prefix (`check-parcel-prefix.ps1 -Sync`) when its plan edits a reserved prefix surface — that repair stays with the edit, because a red `check-parcel-prefix.ps1` would fail the next claim's green baseline and no later step can un-fail it in time. The host owns the invariant, not the repair;
- **records the live value it observed** in its Phase 9 evidence as the "before", so the wrap-up's single increment has a stated base.

A plan whose own text instructs a per-plan counter bump is **overruled by this skill** — the plan body cannot see its siblings, and that is exactly the collision. Log the deviation in Phase 9; do not perform the bump. (A legacy plan bumping anyway is harmless — the counter contract is *strictly increasing values, each recorded*, not a count.)

## Plan Settings writer (frozen preset)

The chain's **first** action — at claim time, before Phase 1 — writes the plan's `## ⚙️ Plan Settings` block as the locked preset: `Mode=AUTO`, `Agents=SINGLE`, and `Models=<the batch model the host handed down>`. This closes the gap where plan-start config had no assigned writer under the batch path. The host (`parcel-sprint`) never authors it, and it is frozen thereafter.

**The `Models` value is handed down, never chosen here.** The batch host asks one model question for the whole batch at `@sprint-run` § 1 step 7 and passes the answer to this runner. Record it verbatim: `CLI default` when the operator declined, otherwise the concrete model the operator selected. This runner **never** asks the question itself and never substitutes a model of its own — a batch that silently runs on a different model than the operator chose is the failure this contract prevents. If the runtime cannot honour a concrete override, the host's stop-the-line (§ 5) fires before this runner is spawned.

**Record the flag in that same block.** When the claimed plan's claim front-matter carries `triage: MULTI`, the provenance line written with the preset must **name the flag** and state plainly that this run is `SINGLE` under the batch preset with **no independent review** — the operator accepted that risk at the fork (`@sprint-run` § 1), and the record belongs in the plan, not in the conversation log. Recording it at claim time is the one legal moment (the block is written once); Gate D then reads the risk instead of discovering it. Canonical semantics: `.devops/rules/plan-lifecycle.md` § Claim Protocol → *MULTI-worthy Yield*.

## Auto-clear test

A gate auto-clears only when its outputs satisfy the canonical **AUTO Gate Evidence Contract** (`.devops/rules/plan-lifecycle.md` § AUTO Gate Evidence Contract) — cited, never restated here. This chain auto-clears Gate A and Gate B; Gate C is recorded `N/A` under the locked `SINGLE` preset. Otherwise halt with the failure outcome below.

## Named exception

This single-run Phases 1→9 chain replaces the default per-group delegation (see Deviations).

## Per-plan outcome map (halt vs skip)

- `PHASE_8_FAILED` (rollback after two failed self-healing attempts) → return `HALT <code>: PHASE_8_FAILED`.
- An `AUTO` gate whose outputs exist but fail the canonical **AUTO Gate Evidence Contract** → return `HALT <code>: unproven <gate> — <missing artifact>`. Never repaired inline, never downgraded to a skip.
- A self-review `**REJECTED:**` at the inline Phase 6 checkpoint, or a Phase 3.5 `Unresolvable:` → return `HALT <code>: <cause>`. **Never** start an inline `PHASE_5_REVISION` loop — revision belongs to a fresh Group B run, not this locked chain.
- A plan whose bottom `Status` is already `PHASE_9` at entry → return `SKIP <code>: already PHASE_9` without re-running.
- A plan whose `depends_on` is unmet at entry → return `SKIP <code>: unmet depends_on`. A code is **satisfied** when it is present in `.devops/archive/` **or** present in `.devops/plans/` with `claim_status: GATE_D_USER_APPROVAL`; any other state (still `QUEUED`, or `CLAIMED` below `PHASE_9`) is unmet. This is the **same rule** the host applies in `sprint-run` § 2 clause 2, whose executable embodiment is `scripts/sprint_eligible.py` — the two layers must not diverge, which is why neither restates the rule: they cite `.devops/rules/plan-lifecycle.md` § Claim Front-Matter.

## Output contract

Return exactly one terse line:

- `DONE <code>` — terminal `Status` `PHASE_9` with `claim_status: GATE_D_USER_APPROVAL` and Gate D `OPEN`, plus the touched-file list.
- `SKIP <code>: <reason>` — nothing written.
- `HALT <code>: <cause>` — nothing further attempted.

Never advance past `PHASE_9`, never flip Gate D, never reorder or re-run a skipped plan.

## Safety

Validation at trust boundaries, error handling, and the Gate D human sign-off are **not** simplifiable. The batch defers Gate D — it never skips it.