/cos-review

name: cos-review
description: "Review PL self-approvals, estimates, board drift, and close quality after a declared night shift. Loaded ONLY by the cos core via its routing table; NEVER auto-load from context or invoke directly."
requires:
  programs: []
  harness:
    - {slot: 4.shell, need: required}
    - {slot: 4.file-read-write, need: required}

COS — batch review

Apply the COS core's finite development budget and affected-test scope. Estimate setup, execution, and reporting from available prior runtimes; do not add estimation machinery or preflight. Full suites and new security checks need the owner's specific approval, never COS approval. Missing auxiliary records do not stop functional work.

Before running these commands, set `PL_SKILL_DIR` to the absolute directory of the installed `pl` skill, in the same Bash call.

Loaded when the owner returns from a declared night shift, or after a batch of closes lands.

**Exclusive authority of this overlay:** issuing the doubt list that reaches the owner. Nothing else in the COS tree may put a "this may be wrong" item in front of them.

This is **one batch pass, never per-decision interrupts**, run when the owner returns from a declared night shift. Do the approval pass once, as one batch when the owner returns; then whatever you cannot approve, or think has a problem, goes to the owner to confirm together.

Why a batch review is safe at all

Because everything done during the night shift stayed revertable. **Treat "a revert path exists" as a hard precondition, not a nice-to-have** — unpushed commits, commits that record checksums, checksum files, preserved copies of replaced work.

If a night decision left **no** revert path, that is itself a doubt-list item regardless of whether the decision looks correct.

Pass 1 — validity of what the PLs self-approved

Do not rubber-stamp PL prose. Re-derive each self-approval and classify it by the four classes in the `cos` core, §What may settle a decision — evidence-class, ruling-derived, delegated band, value-class — with the bands and owner-only list read from `~/.config/sno/decision-rights.md`, validating each exactly as that table specifies (open the cited evidence; a citation that does not resolve, or a ruling with a surviving second reading, converts the item to the doubt list; a value-class item goes there directly). The table lives in the core because it governs live dispositions as much as this batch pass; this pass is its re-audit application. **While classifying, also re-run the circuit-breaker count** (core, §The circuit breaker; `attempt-gate.sh count --slug <slug> --scan <card directory>` per recurring problem): three or more same-shape attempts at one problem in the night's cards is a breaker miss — and so is a recurring problem carded with no `attempt:` tag at all — and it goes on the doubt list even when the final attempt worked. **Also re-audit every `slow-ruling:` record from the shift** (core, §Fast thinking, slow thinking): its QUESTION line carries the original question and the one actually answered — when the two differ and the record answered the substitute, that is a substitution, and it goes on the doubt list like any invalid self-approval.

**Feed the decision-rights file.** Record in `~/.local/state/cos/LEARNING.md`, one line each with numbers: every time the owner overturns something decided alone (the decision and the file row it came under), and each kind of queued item the owner keeps approving. This pass only records; `cos-evolve` turns repeats into proposals for the file.

Output: an **approved list** and a **doubt list**. The doubt list goes to the owner with grounded background per the core's iron rule 3 — which repo, which charter filename, what was decided, what makes it doubtful, and what changes if they rule either way.

Pass 2 — close quality, against the four failure modes

Compare the close with available open-board records to catch omitted work. Use the recorded `board_before` revision when it exists; when it is absent or unreadable, report which comparison could not be made rather than inventing a historical board state. Keep actual omitted deliverables distinct from a missing record. Missing board metadata does not reject the close or skip the functional checks below. Report remaining work as carried, awaiting a named decision, or completed from available evidence; dropping owner-requested work still requires the owner's instruction.

Then the taxonomy. These are the four ways a night goes wrong, and three of them look green from inside:

1. **Under-delivery.** Read each charter's Proof table and success checks (run `sno deliver-proof check <charter>` when installed; read its output, not only its exit status) and diff the checks and deliverables against what actually landed. "Tests green" is not the check; the charter's numbered success checks are. A close that quietly dropped an item is the most common one. 2. **Scope inflation.** Diff the touched paths against the charter's fence. Files outside it need a justification in the close record, not an explanation invented now. 3. **No clean stop.** Ask first whether the **charter** is finished, not whether the journey is. Charter finished → the window should be disposed, the callsign released, and the audit thread free of dangling questions; a card arriving after that seal is lost forever. **Charter still open → a live parked window is the CORRECT state and must not be flagged** (core iron rule 11, one charter one agent): killing it turns the next slice into a fresh hire that re-learns what this agent already knows. What this pass actually hunts is the third case — a window left running with no charter behind it and nobody watching. 4. **Edits outside the assigned project.** When the project uses git, check `git log` in the assigned repo and, when there is any doubt, the sibling repos the executor could reach.

Pass 3 — estimate reconcili