@bongos/core 1.20.41 → 1.20.43

package/.claude/skills/goal-close/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: goal-close
+description: >-
+  Close a goal's criteria: test the ones awaiting UAT on the live site and sign off, then decide the ones a UAT can't close (work abandoned or unlinked). Metic+. Triggers: "/goal-close", "/goal-uat", "/goal-review", "what's awaiting UAT".
+disable-model-invocation: true
+plain: >-
+  Walks you through trying finished goal work on the live site so a person can sign it off, then helps decide the checks nobody can test any more.
+reach-for: >-
+  When work is waiting for someone to try it for real, or a goal is stuck on checks nobody can finish.
+cost: >-
+  Free. Your sign-off or decision is recorded; nothing else changes.
+---
+
+You are running the **goal-close** session: the closing end of a goal. It is one skill with two parts that used to be two commands (task 1004471):
+
+- **Part 1 — UAT** (was `/goal-uat`): criteria whose work shipped, tested on the live site and signed off.
+- **Part 2 — residue** (was `/goal-review`): criteria a UAT cannot close, because all their work was abandoned or none was ever linked.
+
+**Which part to run.** `/goal-close` runs Part 1 then Part 2. `/goal-close uat` (or the old `/goal-uat`) runs Part 1 only; `/goal-close residue` (or the old `/goal-review`) runs Part 2 only. If the builder named a goal, keep only that goal's rows in both parts.
+
+> **The other end of this lifecycle is [`/goal-create`](../goal-create/SKILL.md)** — it opens a goal (scope wall, criteria, seed tasks).
+
+## Rank gate — Metic+ only (both parts)
+
+Signing off rides `criterion.review`, and an override rides `POST /api/bongos/done-when/:criterionId/satisfy` (`requireRank('metic','archon')`, pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle`). The server enforces both; this check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)).
+
+**Enforce the gate at the very top of the session, before reading anything else:**
+
+1. Call `node scripts/gds/api.js GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
+2. **If `rank` lowercases to `xenos` or `thetes`** → stop immediately. Tell the builder: *"Closing a goal's criteria is a Metic+ step — signing one off or overriding it closes out a slice of a version and can auto-achieve a goal. Ask an Archon to promote you, or ask a Metic to run it."* Do not list either queue.
+3. **If `rank` lowercases to `metic` or `archon`** → proceed.
+4. **If `rank` is absent** (a deployment where the three-rank model hasn't shipped) → treat the session as available, exactly as `/idea-triage` does in its pre-rank passthrough mode, and note that in the session log.
+
+---
+
+## Part 1 — UAT: test on the live site, then sign off
+
+A criterion no longer closes because its linked tasks shipped ([ADR 0351](../../../docs/adr/0351-a-criterion-closes-on-a-uat.md), task 1004392, superseding ADR 0183's "shipped is enough"). Once its work has shipped it reads **Awaiting UAT**, and it closes only when a person who did **not** ship that work does what the criterion describes **on the live site** and signs it off.
+
+This is the owner's rule because criteria were being closed by any tasks that happened to be linked to them, whether or not the thing the criterion describes was real. A UAT is the check against the criterion's **words**, not against the task list. Hold it to that.
+
+### The three checks (what you are verifying)
+
+| Check | Passes when | Who decides |
+|---|---|---|
+| **Code** | every linked task is done and at least one shipped | automatic |
+| **Live** | the shipped work is running on the deployed site | read automatically where the site can tell; otherwise the signer confirms it |
+| **UAT** | a signed-in person performed the criterion on the live site; a recording is stored | the signer, who must not have shipped any linked task (the project owner excepted) |
+
+A criterion marked **backend-only** (set when it was written, visible on the criterion) has no screen to record, so it takes a recording-free **backend sign-off** instead. It still needs a non-shipper to sign it.
+
+### Step 1: the queue
+
+```
+node scripts/gds/uat.js --queue
+```
+
+(Add `--version <id>` to scope it.) If nothing is awaiting UAT, say so and move on to Part 2 (or stop, if only Part 1 was asked for).
+
+### Step 2: one criterion at a time
+
+For each, run `node scripts/gds/uat.js <criterion-id>` and present, in plain words:
+
+- the criterion's text, in full;
+- its goal, and whether it is the goal's **last** open criterion (then signing it off achieves the goal);
+- the Live line (running, not yet, or "this site cannot tell");
+- whether it is backend-only.
+
+Then tell the tester exactly what to do **on the live site**, derived from the criterion's words: which page, what to click, what they should see. Write it as a short numbered script. If the criterion's words describe something the tester cannot find on the live site, that is the answer: **it is not met.** Say so and go to Step 4 (reject) rather than looking for a reading under which it passes.
+
+### Step 3: record and sign off
+
+The tester records their screen doing the script (any screen recorder that saves **mp4 or webm**, up to **100 MB**; Windows: Win+Alt+R with Xbox Game Bar, or the Snipping Tool's record button; macOS: Cmd+Shift+5). Then:
+
+```
+node scripts/gds/uat.js <criterion-id> --recording <path-to-file> --note "<one line: what was checked>"
+```
+
+For a backend-only criterion, after the tester has checked it by whatever means proves it (a log line, an API read, a test run against live):
+
+```
+node scripts/gds/uat.js <criterion-id> --backend-signoff --note "<how it was checked>"
+```
+
+Add `--live-attested` only when the server says this site cannot tell whether the work is live, and only if the tester really did it on the live site.
+
+**Refusals, in the words to give the builder:**
+
+| Refusal | Meaning |
+|---|---|
+| `signer_shipped_this_work` | they shipped linked work; someone else signs this one |
+| `work_not_live` | shipped but not deployed yet; sign off after the deploy |
+| `criterion_not_awaiting_uat` | linked work still open (or none linked, or all abandoned: that is Part 2) |
+| `criterion_needs_recording` / `criterion_is_backend_only` | wrong kind of sign-off for this criterion |
+| `live_attestation_required` | confirm it was tested on the live site (`--live-attested`) |
+
+A sign-off on a goal's last open criterion reports the goal achieved; say so.
+
+### Step 4: when it is NOT met
+
+The shipped work does not do what the criterion says. Do not sign off. File the missing work as a task linked to the criterion (`POST /api/bongos/tasks`, then `POST /api/bongos/tasks/<id>/criteria` with `{"criterion_id": <criterion-id>}`) so the criterion drops back to Open until that ships. That is what happened to `wa7-government` (task 1004400).
+
+### What Part 1 does NOT do
+
+- It never uses `POST /done-when/:id/satisfy`. That is the **override** (Part 2): it requires a written `override_reason` and the criterion reads "Satisfied (override)" for good. Use it only when the owner asks, and never to get past a refusal above.
+- It never marks a criterion backend-only to avoid recording one. Backend-only is set while a criterion is still open (`uat.js <id> --backend-only on`), and the server refuses it once the criterion is awaiting UAT.
+
+---
+
+## Part 2 — residue: the criteria a UAT cannot close
+
+This part mirrors `/idea-triage`, for the *closing* end of the work hierarchy (ADR 0086 §6). The review queue (`GET /done-when/pending-review`) also holds criteria nothing was delivered for, and a UAT cannot test those (every row carries `uat_state`; skip the `awaiting_uat` ones, they are Part 1's):
+
+1. **A criterion whose linked tasks were ALL ABANDONED.** Nothing shipped, so there is nothing to test. *Somebody must decide whether the criterion still means anything now that its work is gone*: reject it (file the work that will really deliver it, linked to it), or, if it was genuinely met another way, override it with the reason.
+2. **A criterion with NO linked tasks.** It cannot even reach Awaiting UAT. Link the tasks that deliver it (better — it makes the board true); it then goes through Part 1 like any other.
+
+**Rejecting is the valuable verdict here**; an override is the exception and says so forever ("Satisfied (override)").
+
+### Step 1 — fetch the review queue
+
+```
+node scripts/gds/api.js GET /api/bongos/done-when/pending-review
+```
+
+(Add `?version=BONGOS-V1` to scope to one version. `api.js` is the cross-platform Bongos API helper — it signs the request with your session token.)
+
+If no row is left once the `awaiting_uat` ones are skipped, print "review queue empty — no criteria pending review today" and finish.
+
+Each row carries: `id` (the criterion's numeric id — what you POST to), `criterion_id` (the slug) + `criterion_md` (the prose), `version_id`, `goal_id` + `goal_title` + `goal_status`, `task_total` (how many shipped tasks fulfilled it), and **`is_last_in_goal`** — `true` when this is the goal's only remaining unsatisfied criterion, so **closing it will auto-achieve the goal**.
+
+### Step 2 — walk the list, criterion by criterion
+
+Present each criterion with: its `criterion_md`, its goal (`goal_title`), how many tasks shipped under it (`task_total`), and — when `is_last_in_goal` is true — a clear flag:
+
+> ⚠️ This is the LAST open criterion in **{goal_title}** — closing it will mark the whole goal **achieved**.
+
+Then ask the user (concise; frame in product/outcome terms):
+
+> Criterion C{n} — "{criterion_md}". None of its linked work was delivered. **Reject and file the real work, override (it was met another way), or defer?**
+
+### Step 3 — apply the verdict
+
+**Override** (only for a criterion met some other way, never for one awaiting UAT) → it closes WITHOUT a UAT, so the server requires the reason and records it; the criterion reads "Satisfied (override)" from then on:
+
+```
+node scripts/gds/api.js POST /api/bongos/done-when/<criterion_id>/satisfy --body '{"override_reason":"<why this is met without a UAT>"}'
+```
+
+The response is `{ criterion, goal_achieved, goal }`. **If `goal_achieved` is true**, announce it: *"Goal '{goal.title}' is now achieved — all its criteria are closed."* (That goal now awaits disposition — see Step 4.)
+
+**Reject** → on review it is **not actually met** (the work missed something, or "done" was mis-scoped). There is no "unsatisfy the flag" — the durable fix is to **add the missing work**: capture what's still needed (a follow-up task linked to this criterion, or an idea via `node scripts/gds/capture.js "..."`), and note the rejection in the session log. Once an unshipped task is linked to the criterion, it drops out of `pending_review` on its own. If no follow-up is filed, the criterion simply stays flagged and resurfaces next session — an honest signal that a human said "not done" but nothing was queued to close the gap. **Do not close a criterion you would not stake the version on.**
+
+**Note / defer** is implicit — leave the criterion open by not POSTing. It stays in the queue and surfaces again next session (same as `/idea-triage`'s defer).
+
+### Step 4 — achieved goals (disposition)
+
+Any goal that flipped to `achieved` this session (or is already `achieved`) awaits a disposition: **archive** it (done, put it to rest) or **carry it forward** into the next version's scope. Surface each newly-achieved goal to the user and record the intended disposition in the session log.
+
+> The archive / reopen / carry-forward **actions** (the routes that mutate goal lifecycle) land in **BV1.R64** ([task 1518](https://example.com/builders#/task/1518)) — they are not wired here. For this session, *report* achieved goals and capture the intent; once R64 ships, this step gains the verbs to execute it.
+
+### Step 5 — dependency check (task 1002827, idea 1000276)
+
+A cheap housekeeping pass over the same corpus this session already has open: run the likely-missing-dependency detector and surface any `high`-confidence candidate for a human to triage.
+
+```
+node scripts/gds/audit-deps.js --min high
+```
+
+Each line names an open task and an unshipped task whose files it overlaps with no declared dependency between them. **Read both task descriptions before backfilling an edge** — most overlap is parallel work on a shared file, not a build order; a wrong edge gates the dependent (`POST /claims` → 409 `DEPS_NOT_SHIPPED`) until the named blocker ships. Report the count in the summary; zero is the common case and needs no further comment. This is advisory only — it never blocks the review, and skipping it on a rushed pass is fine (it resurfaces next session, same as a deferred criterion).
+
+---
+
+## Summary to give at the end
+
+- **Part 1:** criteria walked · signed off (ids) · goals achieved · rejected, with the follow-up task filed for each · left waiting (not live yet, or no tester available).
+- **Part 2:** criteria walked · overridden (count + ids) · goals auto-achieved (count + titles) · rejected (count + ids + what follow-up was filed) · deferred (count + ids — these surface again next session) · the new queue count · the dependency-check count.
+
+## Why we run this
+
+Without a closing cadence, criteria pile up "done but unconfirmed" and goals never flip to achieved — the version looks perpetually in-progress even when the work has shipped. A fast pass keeps the rollup honest. As with `/idea-triage`, the cadence is the discipline; a quick walk with mostly defers beats skipping it.
+
+## Tone for the user
+
+Frame each decision in terms of outcome — "this criterion was 'players see each other'; both tasks shipped — is that actually true in the live game?" not "flip satisfied=true on criterion 45." Decide the mechanics yourself; ask the owner only about whether the thing is *really* done.

package/.claude/skills/goal-create/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: goal-create
 description: >-
-  Plan and create ONE goal — the module-scoped workspace between a version and its criteria — drafting its done-when criteria and seed tasks. Metic+ only. Triggers: "/goal-create", "create a goal", "what goal should this live in", or a task created with no goal.
+  Plan and create ONE goal (the module-scoped workspace between a version and its criteria) with its done-when criteria and seed tasks. Metic+. Triggers: "/goal-create", "create a goal", "what goal should this live in", a task created with no goal.
 plain: >-
   Helps you set up a new goal: what it is for, how you will know it is done, and the first tasks to get there.
 reach-for: >-

package/.claude/skills/goal-review/SKILL.md

@@ -1,111 +1,14 @@
 ---
 name: goal-review
 description: >-
-  Decide criteria a UAT can't close: work abandoned or unlinked. Metic+. Triggers: "/goal-review".
+  Old name for /goal-close residue: decide criteria a UAT can't close (work abandoned or unlinked). Metic+. Triggers: "/goal-review".
+disable-model-invocation: true
 plain: >-
-  Helps you decide what to do with a goal's done-when checks that can no longer be tested, because their work was dropped or never linked.
+  The older name for deciding what to do with a goal's checks that can no longer be tested, because their work was dropped or never linked.
 reach-for: >-
-  When a goal is stuck on checks nobody can finish.
+  When you remember the old name; it opens the same walk as closing a goal.
 cost: >-
   Free. It only closes or changes a check when you decide to.
 ---
 
-You are running the **goal-review** session: the residue of the criterion close. It mirrors `/idea-triage`, for the *closing* end of the work hierarchy (ADR 0086 §6).
-
-> **Criteria close on a UAT now, and that is [`/goal-uat`](../goal-uat/SKILL.md), not this skill** ([ADR 0351](../../../docs/adr/0351-a-criterion-closes-on-a-uat.md), task 1004392, superseding ADR 0183's "shipped is enough"). A criterion whose linked work has shipped reads **Awaiting UAT** and closes when someone who did not ship it tests it on the live site and signs it off. If the builder wants to close finished work, send them to `/goal-uat`.
->
-> **The other end of this lifecycle is [`/goal-create`](../goal-create/SKILL.md)** — it opens a goal (scope wall, criteria, seed tasks).
-
-**What is left for this skill.** The review queue (`GET /done-when/pending-review`) also holds criteria nothing was delivered for, and a UAT cannot test those (every row carries `uat_state`; skip the `awaiting_uat` ones, they are `/goal-uat`'s):
-
-1. **A criterion whose linked tasks were ALL ABANDONED.** Nothing shipped, so there is nothing to test. *Somebody must decide whether the criterion still means anything now that its work is gone*: reject it (file the work that will really deliver it, linked to it), or, if it was genuinely met another way, override it with the reason.
-2. **A criterion with NO linked tasks.** It cannot even reach Awaiting UAT. Link the tasks that deliver it (better — it makes the board true); it then goes through `/goal-uat` like any other.
-
-**Rejecting is the valuable verdict here**; an override is the exception and says so forever ("Satisfied (override)").
-
-## Rank gate — Metic+ only
-
-**Gated to Metic+ (Metic, Archon); not Xenos.** Confirming a criterion sets `satisfied=true` and can auto-achieve a goal — a trusted-builder operation that closes out a slice of a version (the "who confirms" resolution in ADR 0086 §6: the planner, not only the Archon). The server enforces this — `POST /api/bongos/done-when/:criterionId/satisfy` is `requireRank('metic','archon')` and pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle` — so this check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)).
-
-**Enforce the gate at the very top of the session, before reading anything else:**
-
-1. Call `node scripts/gds/api.js GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
-2. **If `rank` lowercases to `xenos`** → stop immediately. Tell the builder: *"Goal review is a Metic+ operation — confirming a criterion closes out a slice of a version and can auto-achieve a goal. You're currently Xenos. Ask an Archon to promote you if you need to confirm criteria."* Do not list the queue, do not propose verdicts.
-3. **If `rank` lowercases to `metic` or `archon`** → proceed with the steps below.
-4. **If `rank` is absent** (a deployment where the three-rank model hasn't shipped) → treat the session as available, exactly as `/idea-triage` does in its pre-rank passthrough mode, and note that in the session log.
-
-## What this skill does
-
-1. Lists flagged criteria via `GET /api/bongos/done-when/pending-review` (optionally `?version=<id>`).
-2. For each row that is NOT `awaiting_uat`, prompts the user with: **reject** (leave it open and file the work that delivers it), **override** (it was met another way: close it with a written reason), or **note / defer** (it resurfaces next session).
-3. Applies an override via `POST /api/bongos/done-when/:criterionId/satisfy` with `override_reason` — and reports any goal that auto-achieved as a result.
-
-## How to use
-
-**Step 1 — fetch the review queue.**
-
-```
-node scripts/gds/api.js GET /api/bongos/done-when/pending-review
-```
-
-(Add `?version=BONGOS-V1` to scope to one version. `api.js` is the cross-platform Bongos API helper — it signs the request with your session token.)
-
-If `count` is 0, print "review queue empty — no criteria pending review today" and exit.
-
-Each row carries: `id` (the criterion's numeric id — what you POST to), `criterion_id` (the slug) + `criterion_md` (the prose), `version_id`, `goal_id` + `goal_title` + `goal_status`, `task_total` (how many shipped tasks fulfilled it), and **`is_last_in_goal`** — `true` when this is the goal's only remaining unsatisfied criterion, so **confirming it will auto-achieve the goal**.
-
-**Step 2 — walk the list, criterion by criterion.**
-
-Present each criterion with: its `criterion_md`, its goal (`goal_title`), how many tasks shipped under it (`task_total`), and — when `is_last_in_goal` is true — a clear flag:
-
-> ⚠️ This is the LAST open criterion in **{goal_title}** — confirming it will mark the whole goal **achieved**.
-
-Then ask the user (concise; frame in product/outcome terms):
-
-> Criterion C{n} — "{criterion_md}". None of its linked work was delivered. **Reject and file the real work, override (it was met another way), or defer?**
-
-**Step 3 — apply the verdict.**
-
-**Override** (only for a criterion met some other way, never for one awaiting UAT) → it closes WITHOUT a UAT, so the server requires the reason and records it; the criterion reads "Satisfied (override)" from then on:
-
-```
-node scripts/gds/api.js POST /api/bongos/done-when/<criterion_id>/satisfy --body '{"override_reason":"<why this is met without a UAT>"}'
-```
-
-The response is `{ criterion, goal_achieved, goal }`. **If `goal_achieved` is true**, announce it: *"Goal '{goal.title}' is now achieved — all its criteria are closed."* (That goal now awaits disposition — see Step 4.)
-
-**Reject** → the criterion's tasks all shipped, but on review it is **not actually met** (the work missed something, or "done" was mis-scoped). There is no "unsatisfy the flag" — the flag is *derived* from shipped tasks, so the durable fix is to **add the missing work**: capture what's still needed (a follow-up task linked to this criterion, or an idea via `node scripts/gds/capture.js "..."`), and note the rejection in the session log. Once an unshipped task is linked to the criterion, it drops out of `pending_review` on its own. If no follow-up is filed, the criterion simply stays flagged and resurfaces next session — an honest signal that a human said "not done" but nothing was queued to close the gap. **Do not confirm a criterion you would not stake the version on.**
-
-**Note / defer** is implicit — leave the criterion un-confirmed by not POSTing. It stays in the queue and surfaces again next session (same as `/idea-triage`'s defer).
-
-**Step 4 — achieved goals (disposition).**
-
-Any goal that flipped to `achieved` this session (or is already `achieved`) awaits a disposition: **archive** it (done, put it to rest) or **carry it forward** into the next version's scope. Surface each newly-achieved goal to the user and record the intended disposition in the session log.
-
-> The archive / reopen / carry-forward **actions** (the routes that mutate goal lifecycle) land in **BV1.R64** ([task 1518](https://example.com/builders#/task/1518)) — they are not wired here. For this session, *report* achieved goals and capture the intent; once R64 ships, this step gains the verbs to execute it.
-
-**Step 5 — surface a summary.**
-
-Report to the user:
-- Total criteria walked
-- Confirmed (count + ids)
-- Goals auto-achieved (count + titles)
-- Rejected (count + ids + what follow-up was filed)
-- Deferred (count + ids — these surface again next session)
-- New queue `count`
-
-**Step 6 — dependency check (task 1002827, idea 1000276).** A cheap housekeeping pass over the same corpus this session already has open: run the likely-missing-dependency detector and surface any `high`-confidence candidate for a human to triage.
-
-```
-node scripts/gds/audit-deps.js --min high
-```
-
-Each line names an open task and an unshipped task whose files it overlaps with no declared dependency between them. **Read both task descriptions before backfilling an edge** — most overlap is parallel work on a shared file, not a build order; a wrong edge gates the dependent (`POST /claims` → 409 `DEPS_NOT_SHIPPED`) until the named blocker ships. Report the count in the same summary as Step 5; zero is the common case and needs no further comment. This is advisory only — it never blocks the review, and skipping it on a rushed pass is fine (it resurfaces next session, same as a deferred criterion).
-
-## Why we run this
-
-Without a closing cadence, criteria pile up "done but unconfirmed" and goals never flip to achieved — the version looks perpetually in-progress even when the work has shipped. A fast pass keeps the rollup honest. As with `/idea-triage`, the cadence is the discipline; a quick walk with mostly defers beats skipping it.
-
-## Tone for the user
-
-Lars is the prompter (see CLAUDE.md §2). Frame each decision in terms of outcome — "this criterion was 'players see each other'; both tasks shipped — is that actually true in the live game?" not "flip satisfied=true on criterion 45." Decide the mechanics yourself; ask him only about whether the thing is *really* done.
+**This command is an alias (task 1004471).** `/goal-review` and `/goal-uat` were merged into one skill, `/goal-close`. Read [`.claude/skills/goal-close/SKILL.md`](../goal-close/SKILL.md) and run its rank gate, then **Part 2 — residue** only (the same as `/goal-close residue`), with every rule that file states: rejecting is the valuable verdict, and an override always carries its written reason.

package/.claude/skills/goal-uat/SKILL.md

@@ -1,90 +1,14 @@
 ---
 name: goal-uat
 description: >-
-  Test criteria awaiting UAT on the live site, then sign off. Metic+. Triggers: "/goal-uat", "what's awaiting UAT".
+  Old name for /goal-close uat: test criteria awaiting UAT on the live site, then sign off. Metic+. Triggers: "/goal-uat".
+disable-model-invocation: true
 plain: >-
-  Walks you through trying a finished goal on the live site, so a person can confirm it really works before it is signed off.
+  The older name for trying a finished goal on the live site, so a person can confirm it really works before it is signed off.
 reach-for: >-
-  When work is waiting for someone to try it for real.
+  When you remember the old name; it opens the same walk as closing a goal.
 cost: >-
   Free. Your sign-off is recorded; nothing else changes.
 ---
 
-You are running the **goal-uat** session: the closing step of a goal. A criterion no longer closes because its linked tasks shipped ([ADR 0351](../../../docs/adr/0351-a-criterion-closes-on-a-uat.md), task 1004392). Once its work has shipped it reads **Awaiting UAT**, and it closes only when a person who did **not** ship that work does what the criterion describes **on the live site** and signs it off.
-
-This is the owner's rule because criteria were being closed by any tasks that happened to be linked to them, whether or not the thing the criterion describes was real. A UAT is the check against the criterion's **words**, not against the task list. Hold it to that.
-
-## Rank gate: Metic+ only
-
-Signing off rides `criterion.review` (Metic+); the server enforces it. Check first so a Xenos is not walked into a wall of 403s: `node scripts/gds/api.js GET /api/bongos/me` and read `builder.rank`. If it lowercases to `xenos` or `thetes`, stop and say: *"Signing off a UAT is a Metic+ step. Ask an Archon to promote you, or ask a Metic to run it."*
-
-## The three checks (what you are verifying)
-
-| Check | Passes when | Who decides |
-|---|---|---|
-| **Code** | every linked task is done and at least one shipped | automatic |
-| **Live** | the shipped work is running on the deployed site | read automatically where the site can tell; otherwise the signer confirms it |
-| **UAT** | a signed-in person performed the criterion on the live site; a recording is stored | the signer, who must not have shipped any linked task (the project owner excepted) |
-
-A criterion marked **backend-only** (set when it was written, visible on the criterion) has no screen to record, so it takes a recording-free **backend sign-off** instead. It still needs a non-shipper to sign it.
-
-## Step 1: the queue
-
-```
-node scripts/gds/uat.js --queue
-```
-
-(Add `--version <id>` to scope it.) If nothing is awaiting UAT, say so and stop. If the builder named a goal, keep only that goal's rows.
-
-## Step 2: one criterion at a time
-
-For each, run `node scripts/gds/uat.js <criterion-id>` and present, in plain words:
-
-- the criterion's text, in full;
-- its goal, and whether it is the goal's **last** open criterion (then signing it off achieves the goal);
-- the Live line (running, not yet, or "this site cannot tell");
-- whether it is backend-only.
-
-Then tell the tester exactly what to do **on the live site**, derived from the criterion's words: which page, what to click, what they should see. Write it as a short numbered script. If the criterion's words describe something the tester cannot find on the live site, that is the answer: **it is not met.** Say so and go to Step 4 (reject) rather than looking for a reading under which it passes.
-
-## Step 3: record and sign off
-
-The tester records their screen doing the script (any screen recorder that saves **mp4 or webm**, up to **100 MB**; Windows: Win+Alt+R with Xbox Game Bar, or the Snipping Tool's record button; macOS: Cmd+Shift+5). Then:
-
-```
-node scripts/gds/uat.js <criterion-id> --recording <path-to-file> --note "<one line: what was checked>"
-```
-
-For a backend-only criterion, after the tester has checked it by whatever means proves it (a log line, an API read, a test run against live):
-
-```
-node scripts/gds/uat.js <criterion-id> --backend-signoff --note "<how it was checked>"
-```
-
-Add `--live-attested` only when the server says this site cannot tell whether the work is live, and only if the tester really did it on the live site.
-
-**Refusals, in the words to give the builder:**
-
-| Refusal | Meaning |
-|---|---|
-| `signer_shipped_this_work` | they shipped linked work; someone else signs this one |
-| `work_not_live` | shipped but not deployed yet; sign off after the deploy |
-| `criterion_not_awaiting_uat` | linked work still open (or none linked, or all abandoned: that is `/goal-review`) |
-| `criterion_needs_recording` / `criterion_is_backend_only` | wrong kind of sign-off for this criterion |
-| `live_attestation_required` | confirm it was tested on the live site (`--live-attested`) |
-
-A sign-off on a goal's last open criterion reports the goal achieved; say so.
-
-## Step 4: when it is NOT met
-
-The shipped work does not do what the criterion says. Do not sign off. File the missing work as a task linked to the criterion (`POST /api/bongos/tasks`, then `POST /api/bongos/tasks/<id>/criteria` with `{"criterion_id": <criterion-id>}`) so the criterion drops back to Open until that ships. That is what happened to `wa7-government` (task 1004400).
-
-## What this skill does NOT do
-
-- It never uses `POST /done-when/:id/satisfy`. That is the **override** now: it requires a written `override_reason` and the criterion reads "Satisfied (override)" for good. Use it only when the owner asks, and never to get past a refusal above.
-- It never marks a criterion backend-only to avoid recording one. Backend-only is set while a criterion is still open (`uat.js <id> --backend-only on`), and the server refuses it once the criterion is awaiting UAT.
-- The all-abandoned and no-linked-task residue is `/goal-review`'s, not this skill's.
-
-## Summary to give at the end
-
-Criteria walked · signed off (ids) · goals achieved · rejected, with the follow-up task filed for each · left waiting (not live yet, or no tester available).
+**This command is an alias (task 1004471).** `/goal-uat` and `/goal-review` were merged into one skill, `/goal-close`. Read [`.claude/skills/goal-close/SKILL.md`](../goal-close/SKILL.md) and run its rank gate, then **Part 1 — UAT** only (the same as `/goal-close uat`), with every rule that file states: hold each criterion to its words on the live site, and never use the override to get past a refusal.

package/.claude/skills/grade-audit/SKILL.md

@@ -1,93 +1,14 @@
 ---
 name: grade-audit
 description: >-
-  Accountability sweep over recent grades: override ledger, dropped findings on passing grades, false-pass spot-check, outage roll-up. Queues follow-ups only — never confirms, flips a status, or re-grades. Triggers: "/grade-audit", "audit recent grades", "what shipped past the grader".
+  Old name for /grade-sweep audit: the accountability half of the grade sweep (override ledger, dropped findings, false-pass spot-check). Queues follow-ups only. Triggers: "/grade-audit".
+disable-model-invocation: true
 plain: >-
-  Looks back over recent quality reviews for anything that slipped through: overrides, ignored findings, or passes that look wrong.
+  The older name for the look back over recent quality reviews, for anything that slipped through.
 reach-for: >-
-  Now and then, to check that the quality reviews are being trusted properly.
+  When you remember the old name; it opens the same check as the grade sweep.
 cost: >-
-  Free. It only files follow-up tasks; it never changes a review or a task's status.
+  Free. It only files follow-up notes; it never changes a review or a task.
 ---
 
-You are auditing the last week of grades for accountability gaps: work that shipped past a failing grade unaccounted for, real findings that rode passing grades into production and evaporated, and passes the panel structurally could not have judged. You **describe and queue**. You never confirm, flip, re-grade, or add a gate — every follow-up lands as a queued idea or a handoff to another skill.
-
-## The sweep window
-
-```bash
-node scripts/gds/api.js GET "/api/bongos/public/recent-shipped?days=7"
-```
-
-For each shipped task in the window, read its persisted grade:
-
-```bash
-node scripts/gds/api.js GET "/api/bongos/tasks/<id>?include=grade"
-```
-
-Bucket by grade shape: `passed`, failed, `signals.panel_outcome='unavailable'` (outage — no quality signal existed), or no grade row at all.
-
-**Then split off the no-artifact species before any leg reads the bucket** (task 1004011, ADR 0320). A grade with `signals.no_artifact_grade === true` judged the builder's **claim that nothing was needed** — the handoff notes and value summary against the task description — not a diff. There is no diff, no panel, and one generalist shot (`signals.lenses_dropped` names the four lenses that did not run). It is a real grade and a real gate, but it measures a different thing, so:
-
-- **Do not average or count it alongside diff grades.** A 7.5 over three paragraphs of prose and a 7.5 over a 400-line diff are not the same number.
-- **Leg 2 still applies, and matters more here.** A `blocker`/`major` on a no-artifact pass usually means the *evidence* was thin — queue it the same way.
-- **Leg 3 does not apply** — there is no merged diff to re-read for runtime behaviour. The equivalent question, worth asking on any no-artifact pass that shipped on assertion alone, is: *could a reader today re-run or re-read what the notes claim?* If not, queue it.
-- **A no-artifact FAIL is not an override candidate for Leg 1** unless it also landed. The builder's remedy is better evidence, not a permission.
-
-Note `task_grades.grader_kind` is **not** the discriminator: the server records `'subagent'` for everything arriving through `POST /tasks/:id/grade`. `signals.no_artifact_grade` is the durable marker.
-
-## Leg 1 — the override ledger
-
-For every shipped task whose grade **failed** (or is absent), the land needed an override. Cross-reference the ledger (Archon — `override_request.decide`):
-
-```bash
-node scripts/gds/api.js GET "/api/bongos/override-requests?status=approved"
-```
-
-- Split **infra vs real** first: a fail that is actually `panel_outcome='unavailable'` (or the errored-worker zero-issue shape) is an outage artifact, not an overridden quality verdict — route those to the Leg 4 roll-up.
-- A shipped task with a real failing grade and **no approved override-request row** landed via the raw confirm — the un-audited path. Name it in the report and print its unaddressed `issues[]` verbatim. That set is the ledger's debt.
-- For each such task, queue the debt (see the queueing rule below) — do not chase the lander, do not un-ship anything.
-
-## Leg 2 — dropped findings on passing grades
-
-A pass with `blocker`/`major` entries in `issues[]` shipped real findings that no process ever picks up (the evaluation counted 274 findings on passing ships with zero conversion paths). For each:
-
-- **Worker-attribution filter:** findings attributed to the advisory **Narc** are the known noise class — triage them by hand (read the finding, decide), never auto-trust them into the queue. Findings from the gating workers (Quality, Hacker, Efficiency) or the deterministic pre-passes are higher-confidence — queue them unless plainly stale.
-- **Queueing rule (idempotent):** first read the open inbox (`node scripts/gds/api.js GET /api/bongos/inbox`) and skip any finding already queued — the marker is the deterministic title prefix. Then:
-
-```bash
-node scripts/gds/capture.js "[grade-audit] task <id>: <finding summary>" --kind bug
-```
-
-One idea per surviving finding, titled exactly `[grade-audit] task <id>: …` so a re-run of this audit files nothing twice.
-
-## Leg 3 — false-pass spot-check (runtime-behavior blindness)
-
-The re-review found 2/8 material misses, both the same root cause: **the panel grades diff text and never reasons about runtime** — a CI workflow whose default shallow checkout broke on first run scored functional_fidelity 10/10, and an SSRF guard bypassable via HTTP redirect passed at 9.5. For the riskiest ships in the window — security surfaces, CI/workflow files, the largest diffs, and 9.5s with suspiciously few findings — re-read the merged diff asking one question: *what does this code do at runtime that the diff text does not show?* (defaults it inherits, redirects it follows, first-run behavior, tool/CI defaults). A suspicion is queued via the Leg 2 rule, prefixed the same way — never a re-grade, never a flipped verdict.
-
-## Leg 4 — outage roll-up
-
-Count the window's `panel_outcome='unavailable'` rows. One-off outages just get the `--regrade` pointer in the report; a streak (2+ consecutive, or clustered on one builder) is a health problem — hand off to **/grader-health**, which owns outage diagnosis. Do not diagnose here.
-
-## Report shape
-
-End with the ledger, most severe first:
-
-1. **Un-accounted overrides** — task, findings printed verbatim, queued-idea ref. A task that landed with no approved override-request row is the headline.
-2. **Queued findings** — what was filed this run, what was skipped as already-queued, what was held back by the Narc filter (and why).
-3. **Spot-check suspicions** — task, the runtime question the panel couldn't answer, queued-idea ref.
-4. **Outage roll-up** — count + the /grader-health handoff if a streak.
-
-A clean week is four one-liners.
-
-## Constraints
-
-- **Never confirm, never flip, never re-grade.** A verdict is advisory and never self-executing (ADR 0158 §2) — this skill's entire output is a report plus queued `idea_inbox` rows, and it adds no approval step to anyone's ship (ADR 0162, which retired review gates). If a leg tempts you to "just fix it", the fix is a queued idea or a claimed task, not an action inside the audit.
-- **Manual cadence.** Invoke by hand (weekly is the intended rhythm). Do not wire it to cron or depend on `.claude/scheduled-tasks/`.
-- **Idempotent re-runs.** The `[grade-audit] task <id>:` title marker + the inbox pre-check are what make running it twice harmless — keep both.
-- **Archon surfaces degrade gracefully.** Without `override_request.decide`, Leg 1 can only report "ledger unreadable at this rank" — say so rather than skipping silently.
-
-## Files this skill touches
-
-- Reads: `GET /api/bongos/public/recent-shipped`, `GET /api/bongos/tasks/:id?include=grade`, `GET /api/bongos/override-requests?status=approved` (Archon), `GET /api/bongos/inbox`.
-- Writes: `idea_inbox` rows via `node scripts/gds/capture.js` (queued follow-ups only).
-- Never calls: any confirm, status, grade, or regrade endpoint.
+**This command is an alias (task 1004471).** `/grade-audit` and `/grader-health` were merged into one skill, `/grade-sweep`. Read [`.claude/skills/grade-sweep/SKILL.md`](../grade-sweep/SKILL.md) and run its **Part B — grade audit** only (the same as `/grade-sweep audit`), with every rule that file states: describe and queue, never confirm, flip a status or re-grade.

package/.claude/skills/grade-recover/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: grade-recover
 description: >-
-  Diagnose why a ship parked at completed — grader outage, fabricated fail, or genuine quality fail — and run the right recovery. Adds no gate to the ship path. Triggers: "/grade-recover N", "my grade failed", "grader unavailable", or a ship that landed at completed.
+  Diagnose why a ship parked at completed (grader outage, fabricated fail, or a real quality fail) and run the right recovery. Triggers: "/grade-recover N", "my grade failed", "grader unavailable", or a ship that landed at completed.
 plain: >-
   Works out why a quality review held your work back, whether the reviewer broke, got it wrong, or found a real problem, and takes the right next step.
 reach-for: >-