@naswerks/engineering-loop 0.5.1 → 0.7.0

package/skills/{spec-parent → spec-coordinator}/SKILL.md

@@ -1,12 +1,12 @@
 ---
-name: spec-parent
-description: Assume the COORDINATOR seat for a spec-pipeline effort — quarterback the build seats (one per spec) via prompts, TLDR reviews, verification, and commit calls. Use immediately after spec-pipeline in the same session (the author is already context-loaded), or in a fresh session with the topic name to resume/take a prepped effort. Run spec-parent {topic}.
+name: spec-coordinator
+description: Assume the COORDINATOR seat for a spec-pipeline effort — quarterback the build seats (one per spec) via prompts, TLDR reviews, verification, and commit calls. Use immediately after spec-pipeline in the same session (the author is already context-loaded), or in a fresh session with the topic name to resume/take a prepped effort. Run spec-coordinator {topic}.
 ---
 
-# spec-parent
+# spec-coordinator
 
 Turn this session into the **coordinator** for a `docs/research/{topic}/` spec pipeline. This is
-phase 3 of the backlog model (`docs-backlog`, `spec-pipeline`, **`spec-parent`**, seats build,
+phase 3 of the backlog model (`docs-backlog`, `spec-pipeline`, **`spec-coordinator`**, seats build,
 `docs-process`).
 
 **Find the format first.** This repository writes its formats (the doc header and status words, where an effort is filed, its rails) in the sections `rg -n '^#+ .*\(repository-owned\)' docs/_meta/` lists; read the one a step names before that step writes. This skill names the section, never the format.
@@ -73,8 +73,11 @@ the tracker exists and cut Prompt #1. **Step 0 still applies.**
 ## Your hands
 
 **`read_blackboard` first, always** — argless it is your DAY-ONE SWEEP and your roster: every seat you
-decide for, its state, and its newest tldr rev. With a seat id it returns that seat's artifacts.
-Hand-cranked, your tools are normal file tools on the blackboard files plus the human relay.
+decide for, its state, and its newest tldr rev. With a seat id it returns that seat's tldr (or
+`kind: plan`): whole, a window of it (`offset`), or only the sections new since a revision (`sinceRev`) —
+read what changed, not the whole conversation again. In a shared workspace the seat's `tldr.md` is also a
+file you read with your own tools. Hand-cranked, your tools are normal file tools on the blackboard files
+plus the human relay.
 
 <!-- control-plane-specific -->
 **The five that reach a seat, and what each one actually is:**
@@ -82,10 +85,10 @@ Hand-cranked, your tools are normal file tools on the blackboard files plus the
 | Verb | What it does | The part that bites |
 |---|---|---|
 | `seat_spawn` | Opens a DECLARED sibling's session | **It can never CREATE a seat** — the topology is the create door's, decided by a human — and you may only drive seats you `supervises`/`reviews` |
-| `accept_plan` | The verdict act: `accept` · `accept-with-riders` · `blocking-precondition`, **and NOTHING ELSE carries a go** — and an accepting verdict DELIVERS ITSELF: the seat's live session receives a one-line pointer to the ruling (the body is a `ruling` artifact on your act, on its board) | Pass the workspace HEAD you observed (a backticked sha is fine); an accepting verdict whose seat planned against a different tree is REFUSED, naming both shas. READ THE REPLY'S `delivery:` LINE — `NOT DELIVERED` means the seat is idle and only a `callout` reaches it |
-| `accept` | The rev-bound FINAL receipt | It binds to the seat's CURRENT tldr revision, so if the seat posts again your acceptance no longer covers what it publishes. **Re-accept — it is idempotent and cheap.** This receipt is what the push bar reads; prose is not a receipt |
+| `accept_plan` | The verdict act: `accept` · `accept-with-riders` · `blocking-precondition`, **and NOTHING ELSE carries a go** — and it DELIVERS ITSELF: the seat's live session receives a one-line pointer to the ruling, for an accepting verdict and for any verdict that filed a ruling in the seat's file | Write the ruling into the seat's `tldr.md` FIRST (`## COORDINATOR RULING (plan rev N — {verdict})`), then call with a one-line `ruling`: the file is mirrored before your act and the pointer names your section. Pass the workspace HEAD you observed (a backticked sha is fine); an accepting verdict whose seat planned against a different tree is REFUSED, naming both shas. READ THE REPLY'S `delivery:` and `file:` LINES — `NOT DELIVERED` means the seat is idle and only a `callout` reaches it |
+| `accept` | The rev-bound FINAL receipt — and it TELLS the seat, so it carries your commit call | Put the next instruction (commit, push, close-out) in `ruling`, or write it under `## COORDINATOR ACCEPT` in the seat's `tldr.md` first — the receipt then binds to that mirrored revision. It binds to the seat's CURRENT tldr revision, so if the seat posts NEW CONTENT again your acceptance no longer covers what it publishes. **Re-accept — it is idempotent and cheap.** This receipt is what the push bar reads; prose is not a receipt |
 | `complete` | The reap, and it is HONEST | It re-reads the seat and reports ok only after the terminal state is OBSERVED |
-| `callout` | **THE ONLY WAY YOU REACH A CHARGE** (besides the pointer an accepting `accept_plan` sends) | A charge that posted and ended its turn cannot resume any other way — without this verb it waits for a human. Your ruling must carry a DETERMINATE NEXT ACTION it can execute without inference. KEEP IT TO A LINE: over 600 chars the body is stored as a `ruling` artifact on the board and the seat receives a POINTER — the seat reads the body once, from the board, never twice |
+| `callout` | **THE ONLY WAY YOU REACH A CHARGE** (besides the pointers `accept_plan` and `accept` send) | A charge that posted and ended its turn cannot resume any other way — without this verb it waits for a human. Your ruling must carry a DETERMINATE NEXT ACTION it can execute without inference. **Write it into the seat's `tldr.md` first and pass a one-line `ruling`:** the file is mirrored before your act and the seat is pointed at your section. Without a file, KEEP IT TO A LINE: over 600 chars the body is stored as a `ruling` artifact on the board and the seat receives a POINTER — the seat reads the body once, never twice |
 
 **A QUESTION IS CLOSED BY AN ACT, NOT BY A FILE.** Answer a charge's question with a `callout` carrying
 that post's act id as `answeringActId` — **that act IS the answer**, and it is the only thing that stops
@@ -93,14 +96,23 @@ the re-raise. A `callout` without one steers and closes nothing, and **nothing y
 closes anything**: the latch reads the ledger, so a ruling you never sent is a question still open no
 matter what any blackboard says.
 
-**`seat_acts` IS NOT YOURS, and that is deliberate.** Your mint is `seat:read` · `pipeline:read` ·
-`drive:write` — the coordinator kind was the last one without `acts:read`, and granting it would have
-made that scope universal. **So do not plan a day-one argless act sweep you cannot run**; your sweep is
-`read_blackboard`, and any count you publish names the lane that produced it. The retro seat DOES carry
-`acts:read` — the sweep is its instrument, not yours.
+**THE COORDINATOR'S APPEND, HOSTED.** In a shared workspace a seat that posts its `tldr.md` by `path` shares
+the file with you: append your ruling with your own file tools under a coordinator-voice heading, then call
+the verb. The control plane reads the file, mirrors it as the next revision in YOUR voice before it records
+your act, and points the seat at the section you added; the reply's `file:` line says what was mirrored. A
+seat that posts bytes (a runner older than periscope 1.4.0) or works in its own workspace keeps the old form:
+the verb carries your words. **The act still decides** — a section closes nothing on its own.
+
+**`seat_acts` IS YOUR CENSUS.** Your mint carries `acts:read`: take counts, human touches and receipts from
+the ledger, never from a seat's report about itself, and name the lane any count you publish came from.
 
 **WAKES:** you are woken when a charge posts its plan or its tldr, and a one-line pointer rides the wake —
-read the board and answer on first receipt rather than spending a round-trip.
+the revision and the sections it added. Read what is new (`read_blackboard` with `sinceRev`, or the file) and
+answer on first receipt rather than spending a round-trip.
+
+**A verb that fails with a transport error** (`ECONNRESET`, a socket closed under the call) is the transport,
+not a refusal: call it once more, and journal it if it fails again. A refusal has a name; a dropped
+connection does not.
 
 **THE TRACKER IS YOURS ALONE.** Advance it at every seat boundary; never reconstruct it at the close.
 
@@ -117,7 +129,7 @@ read the board and answer on first receipt rather than spending a round-trip.
    corrected.
 
    **Pick the docs:** the floor and the loop's standard docs are settled (`spec-seat`'s Step 0 +
-   `spec-child`'s role table). **This repository's own docs are yours to seed, by path, every time:** copy
+   `spec-build`'s role table). **This repository's own docs are yours to seed, by path, every time:** copy
    the seat's role rows from `docs/_meta/doc-index.md` § Role reading lists into the prompt's `EXTRA DOCS`
    line — a seat follows a path in its prompt and does not reliably follow an index. Then add the extras
    the task itself warrants. When in doubt, seed the doc: a seat reading one extra doc is cheaper than a
@@ -342,10 +354,9 @@ so read them as run-time obligations, not close-out ones:
 
 - **Your zero-touch / ceremony claims must cite an ARGLESS sweep**, never a verb list you picked
   yourself. **Check on day one that the sweep is runnable at your run's scale — and that it is runnable
-  BY SOMEONE.** Hosted, your ticket carries no `acts:read`, so the argless act sweep is not yours; your
-  day-one check is whether the retro seat, a witness or an operator can produce it. If none can, that is
-  a day-one escalation, not a close-out discovery — a verb-filtered audit can only confirm what you
-  suspected.
+  BY SOMEONE.** Hosted, `seat_acts` is that sweep and your ticket carries it; hand-cranked, check that the
+  retro seat, a witness or an operator can produce it. If none can, that is a day-one escalation, not a
+  close-out discovery — a verb-filtered audit can only confirm what you suspected.
 - **A rev-bound acceptance goes stale on a post-acceptance append of NEW CONTENT — from either actor.**
   The receipt covers the tldr rev + HEAD it was written against; a later content post invalidates it and
   the cheap repair is an **argless re-accept sent WITH the retry order in the same act**. A re-accept with
@@ -420,10 +431,12 @@ so read them as run-time obligations, not close-out ones:
   wait or to reshape the command — not to complete a run or curl past the fence. **And a park that sails
   through anyway is DATA:** record it immediately as an incident, because a fence that failed silently once
   will fail silently again, and your record is the only trace.
-- **`parallel:true` is for specs that share no files — that is its whole purpose.** A refused spawn means
-  the previous seat is still holding the shared effort worktree and needs reaping; the answer is to reap
-  it, or to wait if it has not closed out yet. Reaching for `parallel` there is a category error rather
-  than a shortcut: it does not free the worktree, it just puts two seats in it.
+- **A shared worktree holds one live seat at a time, and nothing but you enforces it.** `seat_spawn`
+  refuses a terminal seat, a seat that already has a live session and a runner it cannot reach — it does
+  NOT refuse a second seat while another is still live in the shared tree, so spawning early puts two
+  seats in one worktree. Reap the previous seat first, or wait if it has not closed out yet. Parallel
+  seats need separate worktrees, which is the pipeline's shape, decided at create — and only for specs
+  that share no files.
 
 ## The steering channel — shape your callouts by SOLICITATION
 
@@ -442,10 +455,10 @@ send context attached to a ruling instead.
 
 ## The seat prompt template
 
-The ceremony rides the **`spec-child` skill** — the prompt is an IGNITER, not a ceremony restatement.
+The ceremony rides the **`spec-build` skill** — the prompt is an IGNITER, not a ceremony restatement.
 
 ```
-You are a BUILD SEAT in a coordinator-run effort: invoke the spec-child skill with
+You are a BUILD SEAT in a coordinator-run effort: invoke the spec-build skill with
 role={backend | frontend | mixed} before anything else, and ALWAYS after `spec-seat`: the seat header
 names `spec-seat` first, the job skill second.
 
@@ -473,7 +486,7 @@ THE TASK: {compressed spec restatement with the load-bearing specifics inline.}
 
 For investigation-first work, add **STEP 0 — INVESTIGATE, REPORT, STOP** before the task, or use
 `role={...} fixit` for no-spec defect sessions (the skill carries the fix-it ceremony). Fallback: if the
-seat can't invoke skills, paste the ceremony from the `spec-child` skill inline.
+seat can't invoke skills, paste the ceremony from the `spec-build` skill inline.
 
 ### The bookend rows (R and P) get a MANIFEST instead of prior shapes
 
@@ -514,7 +527,7 @@ P it is the difference between archiving this effort and sweeping somebody else'
 ## Ruling template (plan review / question answers)
 
 ```
-PARENT RESPONSE — PLAN TLDR {ACCEPTED / ACCEPTED WITH RIDERS / BLOCKING-PRECONDITION}.
+COORDINATOR RESPONSE — PLAN TLDR {ACCEPTED / ACCEPTED WITH RIDERS / BLOCKING-PRECONDITION}.
 {Verdict vocabulary: accept · accept-with-riders (numbered rulings anchored to the SEAT'S OWN item
 numbers — it folds them in and GOES, no re-approval round-trip; the dominant verdict) ·
 blocking-precondition ("accept, but step 0 first") · read-full-plan (not a verdict you send — you
@@ -539,18 +552,22 @@ still open, however good the prose; the seat is still holding and the re-raise i
 **The blackboard append.** Hand-cranked, the seat's `plan.md` and `tldr.md` are live FILES at
 `docs/research/{topic}/sessions/{spec-slug}/` — read the TLDR there with normal file tools instead of
 asking for a paste (`read-full-plan` = read `plan.md`, a pull, never force-fed). Deliver every ruling by
-**APPENDING it verbatim to the seat's `tldr.md`**, right under the questions it answers. Hosted, your
-verbs ARE the appends and the machinery writes them for you.
+**APPENDING it verbatim to the seat's `tldr.md`**, right under the questions it answers. Hosted, the same
+append, then the verb: the control plane mirrors the file before your act and points the seat at the
+section (§ Your hands, the coordinator's append).
 
 **Anchor grammar (canonical — the witness greps these):** rulings land under
-`## PARENT RULING (plan — {verdict})` hand-cranked, `## PARENT RULING (plan rev N — {verdict})` when the
-rev ladder exists; notes under `## PARENT NOTE ({context})`. The parent-voice vocabulary is a CLOSED list
-of four — `PARENT NOTE` · `PARENT ACCEPT` · `PARENT RULING` · `OPERATOR RULING` — so a fifth anchor you
-invent counts as nothing. **Never vary the prefixes**, and **never discuss the anchor grammar inside a
-steering note**: the detector matches the STRING, not your intent, and naming an anchor while explaining
-it derives a spurious acceptance receipt. Refer to it obliquely ("the acceptance anchor").
-**Point, don't paste:** steer with *"read your `tldr.md` under `## PARENT RULING`"*, never by re-pasting a
-multi-KB block into a composer.
+`## COORDINATOR RULING (plan — {verdict})` hand-cranked, `## COORDINATOR RULING (plan rev N — {verdict})`
+when the rev ladder exists; notes under `## COORDINATOR NOTE ({context})`. The coordinator-voice
+vocabulary is a CLOSED list of four — `COORDINATOR NOTE` · `COORDINATOR ACCEPT` · `COORDINATOR RULING` ·
+`OPERATOR RULING` — so a fifth anchor you invent counts as nothing. An older board spells the first three
+`PARENT NOTE` · `PARENT ACCEPT` · `PARENT RULING`; every reader of the anchors, each grep in this loop
+included, takes that spelling as the same three, and you write only the new one. **Never vary the prefixes**, and **never
+discuss the anchor grammar inside a steering note**: the detector matches the STRING, not your intent,
+and naming an anchor while explaining it derives a spurious acceptance receipt. Refer to it obliquely
+("the acceptance anchor").
+**Point, don't paste:** steer with *"read your `tldr.md` under `## COORDINATOR RULING`"*, never by
+re-pasting a multi-KB block into a composer.
 
 **When to read (hand-cranked):** the human's nudge is your wake signal, and the human is the ONLY bus — so
 before cutting each next prompt, sweep `sessions/*/tldr.md` mtimes for appends you were never nudged
@@ -564,7 +581,7 @@ plan-approval click is the human's counterpart of the product's accept-gate —
 ## Docs-write + commit call template
 
 ```
-PARENT RESPONSE — FINAL TLDR ACCEPTED {(+ what I verified myself)}.
+COORDINATOR RESPONSE — FINAL TLDR ACCEPTED {(+ what I verified myself)}.
 1. Run docs-write. Carry: {departures, honest gaps, deferred findings verbatim, gotchas}.
 2. COMMIT CALL — approved. Stage explicitly (never git add -A): YOUR diff + working doc,
    PLUS docs/research/{topic}/project-status.md — my ledger rides your commit,
@@ -583,7 +600,7 @@ PARENT RESPONSE — FINAL TLDR ACCEPTED {(+ what I verified myself)}.
 ```
 
 **THE ACCEPTANCE IS A RECEIPT VERB, AND PROSE IS NOT A RECEIPT.** Send the acceptance act carrying your
-text; it lands in the seat's `tldr.md` under `## PARENT ACCEPT (final — {slice})` and the rev-bound
+text; it lands in the seat's `tldr.md` under `## COORDINATOR ACCEPT (final — {slice})` and the rev-bound
 receipt derives from it. **An acceptance delivered as a steering note records zero rows** — and the push
 bar reads the row, not the paragraph.
 
@@ -591,10 +608,10 @@ bar reads the row, not the paragraph.
 (the receipt binds pre-commit), then the seat commits and pushes. **The receipt is rev-bound:** it covers
 the tldr rev + HEAD it was written against — if the seat re-posts its TLDR CONTENT after your acceptance,
 the unattended push parks naming both revs, and one **argless re-accept** is the cheap repair, **sent with
-the retry order in the same act**. A seat's post-push `## [child·…] CLOSE-OUT RECEIPT` append does NOT
+the retry order in the same act**. A seat's post-push `## [seat·…] CLOSE-OUT RECEIPT` append does NOT
 stale your acceptance — reap without a re-accept after it.
 
-**Hand-cranked:** append the same `## PARENT ACCEPT (final — {slice})` heading to the seat's
+**Hand-cranked:** append the same `## COORDINATOR ACCEPT (final — {slice})` heading to the seat's
 `sessions/{slug}/tldr.md` yourself — there is no machinery and no derivation; the anchor + your tracker
 row ARE the receipts.
 
@@ -617,7 +634,7 @@ post-merge.
   corrections, what you verified yourself, mid-build directives, and anything you don't want to forget —
   written when it happens, never reconstructed at close. **The tracker's own section notes say what each
   section holds**; follow them rather than inventing structure. Do **not** add a `## Checkpoint ledger` or
-  a `## Parent decisions` section — the session entry *is* the decision record, and a parallel section
+  a `## Coordinator decisions` section — the session entry *is* the decision record, and a parallel section
   splits one narrative across two places.
 - **If a retro has to supersede your session rows, the ledger was not kept.** A retro confirms the rows
   and adds the audit and economics; it never corrects facts that should already be written.
@@ -644,7 +661,7 @@ post-merge.
   a sequence, and do not treat a stale living doc as something this effort must fix.
 - Periodically remind the human to sweep your doc edits into a small `docs` commit.
 - Counterpart skills: `spec-seat` (the contract of every seat you arm — read it to know what they were
-  told) · `spec-child` (the builders' job skill) · `spec-pipeline` (how the specs came to exist) ·
+  told) · `spec-build` (the builders' job skill) · `spec-pipeline` (how the specs came to exist) ·
   `spec-review` (the outside look, before your retro) · `spec-retro` (your close-out audit) ·
   `spec-witness` (the read-only verifier) · `spec-ignite` (the ignition copilot that puts an authored
   effort onto the plane).

package/skills/spec-ignite/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spec-ignite
-description: Become the IGNITION COPILOT for a spec pipeline — verify the committed ignition brief against live state, verify every step by receipt, and kick on the human's word. Authoring belongs to spec-pipeline; this seat VERIFIES, so it can run cold. Use right after spec-pipeline when the pipeline will run hosted (the manual alternative is spec-parent), or fresh with a topic whose specs are already authored. Two verbal gates: nothing moves before "stage it"; nothing spawns before "kick it".
+description: Become the IGNITION COPILOT for a spec pipeline — verify the committed ignition brief against live state, verify every step by receipt, and kick on the human's word. Authoring belongs to spec-pipeline; this seat VERIFIES, so it can run cold. Use right after spec-pipeline when the pipeline will run hosted (the manual alternative is spec-coordinator), or fresh with a topic whose specs are already authored. Two verbal gates: nothing moves before "stage it"; nothing spawns before "kick it".
 ---
 
 # spec-ignite
@@ -119,10 +119,10 @@ injects** — the human keyboard and the hardened ladders are the only submit pa
 
 The coordinator's task is the brief's own **`## The kick`** section, copied verbatim. Roughly:
 
-> You are the COORDINATOR of the {topic} pipeline. Invoke the `spec-parent` skill, then read
+> You are the COORDINATOR of the {topic} pipeline. Invoke the `spec-coordinator` skill, then read
 > `docs/research/{topic}/00-ignition-brief.md` and follow it. Your branch is `{the effort's branch}`.
 
-**Do not draft a constitution here.** The seat's PROCEDURE is the `spec-parent` skill; its POLICY rides the
+**Do not draft a constitution here.** The seat's PROCEDURE is the `spec-coordinator` skill; its POLICY rides the
 un-skippable policy suffix the control plane supplies at open (you do not paste it, and you cannot
 override it); its HANDS are the coordinator charter the control plane attaches to a `coordinator` seed
 and to no other kind. This RUN's choreography is the committed brief. A task string cannot be diffed or
@@ -271,7 +271,7 @@ you found rather than working around it.
   anomalies that may change it — surprises are findings, not adjustments.
 
 ## Related
-- `spec-pipeline` (authors what you ignite, including the brief you verify) · `spec-parent` (the
-  coordinator's procedure, and the HAND-CRANKED alternative) · `spec-seat` + `spec-child` (what the
+- `spec-pipeline` (authors what you ignite, including the brief you verify) · `spec-coordinator` (the
+  coordinator's procedure, and the HAND-CRANKED alternative) · `spec-seat` + `spec-build` (what the
   control plane seeds into every build seat) · `spec-retro` (the close-out audit) · `spec-witness`
   (point one at the run you just ignited)

package/skills/spec-pipeline/SKILL.md

@@ -59,14 +59,14 @@ sessions/                        WHO PUTS IT THERE
                                  questions with the coordinator's rulings appended beneath them. Read
                                  top-to-bottom it IS the session's whole conversation, in message order
   code-review.md                 the review seat, in its own commit, if the run has a review row
-  parent-retrospective.md        the coordinator, at the close
+  coordinator-retrospective.md   the coordinator, at the close
   witness-ledger-*.md            a human commit — the witness is zero-writes by contract (its ticket
                                  cannot even carry the write scope), so its testimony reaches the repo
                                  by someone else's hand
 ```
 
 - **Per-seat artifacts go in a `{spec-slug}/` subfolder; effort-wide artifacts sit at the `sessions/`
-  root.** The first seat creates its subfolder and, incidentally, the parent folder; everything after
+  root.** The first seat creates its subfolder and, incidentally, `sessions/` itself; everything after
   writes into what exists.
 - **RE-COPY BOTH FILES ONCE, IMMEDIATELY BEFORE THE FINAL PUSH.** A seat's close-out receipt is written
   AFTER the commit that carries its testimony, so a single copy always lands truncated — and a follow-up
@@ -78,7 +78,7 @@ sessions/                        WHO PUTS IT THERE
   separate questions file, and there are no status snapshots: the tracker is committed live, so its git
   history already carries the progression a snapshot would fake.
 - **Append-only.** `tldr.md` grows; nobody rewrites it. The rev ladder is the history.
-- **Who READS it:** the coordinator reads each TLDR and appends its rulings under `## PARENT RULING` · the
+- **Who READS it:** the coordinator reads each TLDR and appends its rulings under `## COORDINATOR RULING` · the
   review seat reads every session's TLDR as testimony **and reads nothing else** · the retro greps it for
   acceptance anchors and unanswered questions · the witness uses rev counts and mtimes as a zero-cost
   heartbeat.
@@ -214,7 +214,7 @@ sessions/                        WHO PUTS IT THERE
 5. **Name the archive destination when only you can.** Read `docs/_meta/docs-workflow.md` § The archive
    convention (repository-owned). If where a pipeline files depends on something only this session knows
    (which living feature the effort belongs to, say), resolve it now and write the path into the
-   umbrella's blockquote as an `Archive:` line; `spec-parent` hands it to the docs-process row and
+   umbrella's blockquote as an `Archive:` line; `spec-coordinator` hands it to the docs-process row and
    `docs-process` files there. A convention that needs nothing from you needs no line.
 
 6. **Stop.** The specs stay in `research/{topic}/`. Do NOT implement, do NOT touch living docs, do NOT
@@ -320,7 +320,7 @@ cross-reading them; a human row recorded only by the coordinator has ONE, and th
 one whose errors nobody else catches.
 
 ## The kick — paste this verbatim as the coordinator's task
-> You are the COORDINATOR of the {topic} pipeline. Invoke the `spec-parent` skill, then read
+> You are the COORDINATOR of the {topic} pipeline. Invoke the `spec-coordinator` skill, then read
 > `docs/research/{topic}/00-ignition-brief.md` and follow it. Your branch is `{the effort's branch}`.
 
 Deltas true of THIS kick only (a concurrent pipeline, a model override, a one-off probe) go here as a
@@ -328,7 +328,7 @@ short list. Everything else is already in this brief — the task string is a PO
 stays short because a task buried in a run row cannot be diffed or reviewed the way this file can.
 ```
 
-**Do not restate the ceremony here.** The coordinator's procedure lives in `spec-parent` and its policy
+**Do not restate the ceremony here.** The coordinator's procedure lives in `spec-coordinator` and its policy
 is the one § This repository's rails (repository-owned) names, which a hosted run also carries in the
 un-skippable policy suffix the control plane supplies; a brief that re-teaches them accretes
 into prompt-law that breaks the coordinator it was meant to steer. The brief carries THIS RUN's
@@ -410,7 +410,7 @@ viewer because they are instructions to the coordinator, not content for the hum
 |---|---|---|---|
 ```
 
-**Never generate a `## Checkpoint ledger` or a `## Parent decisions` section.** The session section
+**Never generate a `## Checkpoint ledger` or a `## Coordinator decisions` section.** The session section
 *is* the decision record; a parallel section splits one narrative across two places.
 
 ## `live-checks.md`

package/skills/spec-retro/SKILL.md

@@ -13,8 +13,8 @@ today that perspective evaporates the moment the run closes. This skill turns it
 **Find the format first.** This repository writes its formats (the doc header and status words, where an effort is filed, its rails) in the sections `rg -n '^#+ .*\(repository-owned\)' docs/_meta/` lists; read the one a step names before that step writes. This skill names the section, never the format.
 
 Run it as the **last act of the coordinator seat**, after the final session's close-out commit — before or
-after the PR is cut, either works. Output: `docs/research/{topic}/sessions/parent-retrospective.md`. It is
-a scoped write on the pipeline's branch, so it rides the PR to the base branch either way.
+after the PR is cut, either works. Output: `docs/research/{topic}/sessions/coordinator-retrospective.md`.
+It is a scoped write on the pipeline's branch, so it rides the PR to the base branch either way.
 
 **You are one of the three kinds that do NOT compose `spec-seat`** — this skill is your whole contract,
 and the control plane's seed says so rather than merely omitting it.
@@ -45,16 +45,14 @@ human and exception rows included. **Start every audit with it: "what happened t
 not ask about."** A verb-filtered read can only confirm suspicions, never surface surprises — a run can
 certify itself "zero-touch" while `approved_by_human` rows sit one unqueried verb away.
 
-**Who holds the instrument, on the hosted plane:** a `retro` seat's ticket carries `acts:read`, so
-`seat_acts` argless IS your sweep. A `coordinator` ticket deliberately does **not** carry it — its mint is
-`seat:read` · `pipeline:read` · `drive:write` — so a coordinator writing this retro from its own seat
-reads `read_blackboard` (argless = the roster) and takes the act sweep from the retro seat, the
-effort's witness, or a credentialed operator. **Say which instrument produced every count in this
-document** — a number whose lane you cannot name is testimony, not an audit.
+**Who holds the instrument, on the hosted plane:** a `retro` seat's ticket and a `coordinator` ticket both
+carry `acts:read`, so `seat_acts` argless IS your sweep whichever of the two writes this retro. **Say which
+instrument produced every count in this document** — a number whose lane you cannot name is testimony, not
+an audit.
 
 **If the argless sweep is not runnable at your run's scale, that is a day-one escalation, not a
 close-out discovery.** A few thousand rows can exceed the lane's page budget; you cannot retroactively
-obtain the audit your own doctrine mandates. `spec-parent` carries this as a run-time obligation.
+obtain the audit your own doctrine mandates. `spec-coordinator` carries this as a run-time obligation.
 
 **Two instruments that share no code are the only way a ceremony audit means anything** — on one
 instrument you are grading your own homework with your own pencil. Where the control plane offers a
@@ -148,11 +146,13 @@ could not tell. And do not flatten predicates that were measured apart: a conten
 stales a PUSH; a close-out-receipt append does not stale a REAP. Report what you observe; never
 generalise one park into a law.
 
-**The derived-row path:** the acceptance's durable record is the `## PARENT ACCEPT (final — {slice})`
-anchor in each seat's `tldr.md`, and the receipt DERIVES from it. Reconcile file against substrate:
+**The derived-row path:** the acceptance's durable record is the `## COORDINATOR ACCEPT (final —
+{slice})` anchor in each seat's `tldr.md`, and the receipt DERIVES from it. A board written before this
+vocabulary spells it `## PARENT ACCEPT`; a reader of the anchors takes both spellings, so the grep does too. Reconcile
+file against substrate:
 
 ```bash
-rg -n "## PARENT ACCEPT" docs/research/{topic}/sessions/*/tldr.md
+rg -n "## (COORDINATOR|PARENT) ACCEPT" docs/research/{topic}/sessions/*/tldr.md
 ```
 
 **AUDIT THE QUESTION LANE THE SAME WAY — it is a heading grep, not a row query.** A seat asks by appending
@@ -163,8 +163,8 @@ run whose seats asked repeatedly and changed a ruling by it.
 **AND ON THE HOSTED PLANE THE FILE IS NOT THE CLOSE PREDICATE — audit BOTH halves, because they answer
 different questions.** *Was one asked?* is a fact about the file (the heading grep below, mirroring the
 control plane's grammar). *Was it answered?* is a fact about the LEDGER — the ruling act carrying the
-asking post's id — and it is deliberately not read from the file, because a seat can type a parent-voice
-heading into its own blackboard. **A retro that audits only the file can be shown a question that
+asking post's id — and it is deliberately not read from the file, because a seat can type a
+coordinator-voice heading into its own blackboard. **A retro that audits only the file can be shown a question that
 answered itself.** Reconcile the grep's hits against the ruling acts, and report any hit with no act as an
 unanswered question whatever the file says.
 
@@ -177,11 +177,12 @@ prefixed and plural headings, and the lane has TWO headings: `## QUESTIONS` (rec
 rg -niE '^##[[:space:]]*(\[[^]]*\][[:space:]]*)?(MID-BUILD[[:space:]]+)?QUESTIONS?\b' docs/research/{topic}/sessions/*/tldr.md | rg -viE 'QUESTIONS?[[:space:]]+ANSWERED'
 ```
 
-Reconcile each hit against the parent-voice append that answered it (`## PARENT RULING` / `## PARENT NOTE`
-in the same file) — an unanswered question is the finding. **Your audit instrument must be at least as
-tolerant as the code it audits.**
+Reconcile each hit against the coordinator-voice append that answered it (`## COORDINATOR RULING` /
+`## COORDINATOR NOTE` in the same file, or `## PARENT RULING` / `## PARENT NOTE` on an older board) — an
+unanswered question is the finding. **Your audit instrument must be at least as tolerant as the code it
+audits.**
 
-- **Hosted:** N `## PARENT ACCEPT` anchors imply N acceptance acts (rev-bound: the act carries the tldr
+- **Hosted:** N acceptance anchors (`## (COORDINATOR|PARENT) ACCEPT`) imply N acceptance acts (rev-bound: the act carries the tldr
   rev, the HEAD and a content hash). An anchor with no act means the derivation failed (LOUD in the
   logs — find it); an act with no anchor is a cockpit accept (legitimate; the act says so).
   Acceptance-shaped PROSE without the anchor writes nothing by design — flag it as a ceremony miss.
@@ -374,7 +375,7 @@ is the look of a record with none of a record's properties.
    session's `tldr.md`, and the working docs.
 2. **Query** the substrate for §§2-5. Verify each query FIRES on a known-positive row before trusting a
    clean result.
-3. **Write** `docs/research/{topic}/sessions/parent-retrospective.md` — NATIVELY, in the tree you were born
+3. **Write** `docs/research/{topic}/sessions/coordinator-retrospective.md` — NATIVELY, in the tree you were born
    in: the coordinator lives in the effort's worktree, so the scoped write (the effort home's own `.md`
    files, `sessions/`, the tracker, `live-checks.md` and the specs) lands on the effort's branch and rides
    its PR. Every write earns its loud audit row. **If the write REFUSES, that is a PLATFORM DEFECT:**
@@ -396,6 +397,6 @@ is the look of a record with none of a record's properties.
    leaves an identical belief standing in a sibling that words it differently has to be made twice.
 
 ## Related
-- `spec-parent` (the seat, and the run-time half of this skill's close-out demands) · `spec-child` (the
-  builders) · `spec-seat` (their shared contract) · `spec-witness` (the read-only verifier) ·
+- `spec-coordinator` (the seat, and the run-time half of this skill's close-out demands) · `spec-build`
+  (the builders) · `spec-seat` (their shared contract) · `spec-witness` (the read-only verifier) ·
   `spec-pipeline` (which authored the specs you are grading)

package/skills/spec-review/SKILL.md

@@ -24,7 +24,7 @@ else's job.
   Reading it anchors you on that grade and the pipeline pays for two opinions to get one.
 - **You do not fix anything.** Findings get classified and filed. A reviewer that repairs its own findings
   cannot be trusted to count them.
-- **You do not decide whether a fixit runs — you classify.** The parent rules on it. A reviewer that can
+- **You do not decide whether a fixit runs — you classify.** The coordinator rules on it. A reviewer that can
   trigger work is grading its own necessity.
 - **Every TLDR, spec, and doc claim is TESTIMONY to verify, never a fact to build on.** That includes
   anything your coordinator tells you: if a ruling arrives in your `tldr.md`, record it and treat it as a
@@ -194,8 +194,9 @@ testimony.
 
 ## The report — `sessions/code-review.md`
 
-Files beside `parent-retrospective.md` in the pipeline's `sessions/` folder. It is a pipeline artifact,
-not a chat transcript, and it archives with the effort.
+Files beside the coordinator's retrospective in the pipeline's `sessions/` folder
+(`coordinator-retrospective.md`, or `parent-retrospective.md` in an effort begun before that name). It is
+a pipeline artifact, not a chat transcript, and it archives with the effort.
 
 ```markdown
 # Code + session review — {topic}, pipeline {id}
@@ -244,7 +245,7 @@ that does not exist yet (an unauthored row, an unwritten charter) is NOT homed:
 
 ## Lineage   _(where § Doc metadata (repository-owned) keeps the footer)_
 - **Pipeline** — the tracker · the umbrella · sessions 02..NN
-- **Counterpart** — `parent-retrospective.md` (the inside look; written after this)
+- **Counterpart** — `coordinator-retrospective.md` (the inside look; written after this)
 ```
 
 ## Ceremony
@@ -254,7 +255,7 @@ TLDR with beliefs and numbered questions, the question lane, the parked-call dis
 vocabulary, the six-section FINAL TLDR, and the close-out order. You commit `sessions/code-review.md` on
 your coordinator's call like any seat.
 
-**The close-out receipt's heading token is the literal `child·` for you too** — it is a protocol anchor,
+**The close-out receipt's heading token is the literal `seat·` for you too** — it is a protocol anchor,
 not a description of your seat, and writing `[review·…]` stales your own acceptance. `spec-seat` carries
 the detail.
 
@@ -267,7 +268,7 @@ Your baselines are reads, not builds: you run the suites to confirm the pipeline
 number you cannot reproduce is a finding.
 
 ## Related
-- `spec-parent` (rules on your fixit candidates; writes the retro after you) · `spec-child` (the seats you
+- `spec-coordinator` (rules on your fixit candidates; writes the retro after you) · `spec-build` (the seats you
   are reviewing) · `spec-retro` (the inside look) · `spec-witness` (the live read-only seat; its ledger, if
   one exists, is evidence like any other artifact) · `docs-process` (consumes this report and gives every
   finding a disposition)