paperlint 2.0.0

package/skills/paper-pipeline/scripts/status.mjs

@@ -0,0 +1,295 @@
+// status.mjs — the one status view, computed. Replaces the table nobody could trust.
+//
+//   node .claude/skills/paper-pipeline/scripts/status.mjs <papers-root>/<paper-a>
+//
+// Everything printed here is derived from the ledger plus the bytes currently on disk. There is
+// no field a human can set, which is the entire point: the table it replaces was accurate only
+// for as long as someone remembered to un-tick it, and nobody ever did.
+//
+// 🔴 NOTHING IN THIS VIEW SAYS A PAPER PASSED, AND THAT IS ENFORCED, NOT INTENDED.
+// The ledger has no `PASS` constructor (see ledger.mjs), so this reader has nothing to render as
+// an acquittal. It reports, per check: how many findings the last run recorded, or — when the run
+// recorded none — the ABSTENTION reason it gave. `no-witness` means "ran, found nothing, and has
+// no witness for the negative"; it is displayed as an abstention and never as green.
+// `gates.harness.mjs` asserts that this file's output contains no word meaning "passed", because
+// a rule about tone that nothing checks is a rule that lasts one refactor.
+
+import {
+  status,
+  readLedger,
+  rowKey,
+  parseGate,
+  ABSTENTIONS,
+} from "./ledger.mjs";
+import { resolve, basename } from "node:path";
+import { isMain } from "./consumer.mjs";
+
+// The checks a paper is expected to have been put through. Listed explicitly so a check that has
+// NEVER run shows up as a row rather than as an absence — the difference between "we looked and
+// recorded nothing" and "nobody asked" is the whole failure this pipeline keeps having.
+//
+// 🔴 ENTRIES ARE CHECKS, NOT SKILLS. `skill` names a skill's own single pass; `skill/check` names
+// one mechanical check filed under that skill. Before 2026-08-10 the key was the skill, and
+// `status()` took the LAST row per skill — so two checks under one name took turns being the
+// answer and a clean run of one erased a finding of the other from every derived view. Three
+// checks now sit under `build-benchmark` and none of them can overwrite the others.
+export const EXPECTED_GATES = [
+  // — before a word is written —
+  "research-ideate",
+  "sweep-design-space",
+  "map-prior-work",
+  "find-venue",
+  "plan-paper-timeline",
+  // — building the evidence —
+  "build-benchmark",
+  "build-benchmark/check-provenance",
+  "build-benchmark/arm-permutation",
+  "build-benchmark/delivered-pdf",
+  "build-benchmark/generated-code",
+  "argument-arc",
+  "draft-paper",
+  "draft-paper/population-map",
+  // — the loop —
+  "cold-read-diff",
+  "tighten-paper",
+  "tighten-paper/structure",
+  "tighten-paper/round-diff",
+  "grade-paper-writing",
+  "grade-paper-writing/prose-lint",
+  // TeXtidote. Filed here because this skill owns the paper's PROSE surface and `prose-lint` is the
+  // other instrument reading it — style thresholds there, spelling and grammar here.
+  "grade-paper-writing/textidote",
+  "render-paper",
+  "render-paper/report-submission",
+  // — checking against the world —
+  "verify-citations",
+  "verify-citations/verify-cites",
+  // checkcites, the bibliography read backwards: verify-cites asks whether an entry names a real
+  // work, this asks whether anything cites the entry. Same surface, opposite arrow, same skill.
+  "verify-citations/uncited-refs",
+  "analyze-sibling-paper",
+  "study-accepted-papers",
+  // — the gates —
+  "paper-adversarial-review",
+  "pc-panel-review",
+  "harden-paper",
+  "harden-paper/artifact-coverage",
+  "submit-paper",
+  // — after —
+  "camera-ready",
+  "extend-paper",
+];
+// 🔴 This list is the table. A check that records a row but is absent here writes rows nobody
+// ever sees — it ran, and the status view says nothing, which is the precise failure this whole
+// directory was built to end. Found 2026-08-07, hours after the first version shipped with 12 of
+// the 22 wired skills listed. `paper-status` is deliberately absent: it REPORTS state rather than
+// producing a verdict about the paper, so a row for it would be the table grading itself.
+// Any new paper skill: wire it, then add it here. Any new mechanical check in `run-mechanical.mjs`:
+// add its `skill/check` key here. `unlistedGates()` below catches the omission.
+
+/** Checks that have recorded rows for this paper but are missing from the table above. */
+export function unlistedGates(rows) {
+  const listed = new Set(EXPECTED_GATES);
+  return [...new Set(rows.map(rowKey))].filter(
+    (k) => !listed.has(k) && parseGate(k).skill !== "paper-status",
+  );
+}
+
+const ICON = {
+  FRESH: "🟢",
+  "STALE-PAPER": "🟠",
+  "STALE-SKILL": "🟡",
+  "NEVER-RUN": "⬜",
+};
+
+const WHY = {
+  FRESH: "ran against these exact bytes",
+  "STALE-PAPER":
+    "the paper changed since it ran — its answer is about a document that is gone",
+  "STALE-SKILL":
+    "the check itself changed since it ran — that answer came from a different tool",
+  "NEVER-RUN": "nobody has asked this question about this paper",
+};
+
+/** What the last run of this check produced. Never a word that could be read as an acquittal. */
+function produced(r) {
+  if (r.state === "NEVER-RUN") return "—";
+  if (r.findings > 0) return `${r.blocking ? "🔴" : "•"} ${r.findings} found`;
+  if (r.legacy) return `legacy:${r.legacy}`;
+  if (r.abstained) return `abstained:${r.abstained.reason}`;
+  return "no row";
+}
+
+function main(argv) {
+  const dir = resolve(argv[2] || ".");
+  const rows = status(dir, { gates: EXPECTED_GATES });
+
+  console.log(`\n  ${basename(dir)}\n`);
+  const pad = (s, n) => String(s ?? "").padEnd(n);
+  console.log(
+    `  ${pad("check", 36)}${pad("freshness", 14)}${pad("last run produced", 22)}${pad("runs", 6)}when`,
+  );
+  console.log(`  ${"-".repeat(92)}`);
+
+  for (const r of rows) {
+    const when = r.ts ? r.ts.slice(0, 16).replace("T", " ") : "—";
+    console.log(
+      `  ${ICON[r.state]} ${pad(r.key, 34)}${pad(r.state, 14)}${pad(produced(r), 22)}${pad(r.runs, 6)}${when}`,
+    );
+  }
+
+  const stale = rows.filter(
+    (r) => r.state === "STALE-PAPER" || r.state === "STALE-SKILL",
+  );
+  const never = rows.filter((r) => r.state === "NEVER-RUN");
+  const mute = rows.filter((r) => r.runs > 0 && !r.everFound);
+
+  console.log("");
+  for (const r of stale)
+    console.log(`  ${ICON[r.state]} ${r.key}: ${WHY[r.state]}`);
+  if (never.length) {
+    console.log(`  ⬜ never run: ${never.map((r) => r.key).join(", ")}`);
+    console.log(
+      `     ${WHY["NEVER-RUN"]} — an unasked question reads exactly like a clean one in prose.`,
+    );
+  }
+
+  // 🔴 THE ABSENCE OF FINDINGS IS NOT A RESULT, AND THIS IS WHERE THAT IS SAID OUT LOUD.
+  // Under the old vocabulary these checks recorded PASS and this block was a footnote about a
+  // suspicious gate. With PASS deleted, "recorded no finding" is ALL that a clean run ever
+  // produces, so this is now the primary reading of the table rather than a warning about it.
+  if (mute.length) {
+    console.log(
+      `\n  🔇 has run and has NEVER recorded a finding: ${mute.map((r) => r.key).join(", ")}`,
+    );
+    console.log(
+      `     Borrowed from mutation testing: a test that kills no mutant is not a test. This is`,
+    );
+    console.log(
+      `     not proof the check is broken — it is the reason to go plant a defect and watch.`,
+    );
+    console.log(
+      `     Precedent here: a tightening pass returned KEEP on 80 of 81 sections and a`,
+    );
+    console.log(
+      `     justification pass never once recommended a deletion. Both "ran".`,
+    );
+  }
+
+  const legacy = rows.filter((r) => r.legacy);
+  if (legacy.length) {
+    const acquittals = legacy.filter(
+      (r) => !["FINDINGS", "FAIL"].includes(r.legacy),
+    );
+    console.log(
+      `\n  🏷️  answered in the RETIRED vocabulary: ${legacy.map((r) => `${r.key}=${r.legacy}`).join(", ")}`,
+    );
+    console.log(
+      `     Rows written before 2026-08-10 are kept verbatim and are NOT translated into the`,
+    );
+    console.log(
+      `     current constructors — a silent reinterpretation is the class of defect this`,
+    );
+    console.log(
+      `     pipeline removed. A retired FINDINGS/FAIL row still shows its count above, because`,
+    );
+    console.log(
+      `     it carries evidence and discarding evidence is the destructive direction.`,
+    );
+    if (acquittals.length) {
+      console.log(
+        `     ${acquittals.map((r) => `${r.key}=${r.legacy}`).join(", ")} carry NOTHING forward:`,
+      );
+      console.log(
+        `     they recorded that nothing was wrong, with no evidence attached, which is exactly`,
+      );
+      console.log(
+        `     the value that was deleted. Re-run those checks for an answer in a live vocabulary.`,
+      );
+    }
+  }
+
+  const orphans = unlistedGates(
+    readLedger().filter((r) => r.paper === basename(dir)),
+  );
+  if (orphans.length) {
+    console.log(`\n  ❗ recording but NOT IN THE TABLE: ${orphans.join(", ")}`);
+    console.log(
+      `     These ran and said something, and this view showed you nothing. Add them to`,
+    );
+    console.log(
+      `     EXPECTED_GATES — an invisible row is the failure this directory exists to end.`,
+    );
+  }
+
+  // 🔴 OPEN FINDINGS. The ledger has recorded a findings COUNT and a REPORT PATH on every row since
+  // it was written, and this view never showed either — a check could record "7 findings, report at
+  // <path>" and the table printed a single word. The number and the path went nowhere, so the one
+  // thing a check actually produces was the one thing you could not see without opening runs.jsonl
+  // by hand.
+  //
+  // NB this reports what the LEDGER holds. It cannot tell whether anyone acted on a finding — that
+  // lives in the session's task list, which is not a file and cannot be checked from the repo. So
+  // this makes findings VISIBLE and durable; it does not and cannot make them assigned.
+  const open = rows.filter((r) => r.findings > 0 && r.state !== "NEVER-RUN");
+  if (open.length) {
+    const total = open.reduce((s, r) => s + r.findings, 0);
+    console.log(
+      `\n  📌 open findings: ${total} across ${open.length} check(s)`,
+    );
+    for (const r of open) {
+      const where = r.report
+        ? ` → ${r.report}`
+        : " (no report path recorded — the count is all there is)";
+      const fresh =
+        r.state === "FRESH"
+          ? ""
+          : `  [${r.state}: this count describes an older text]`;
+      console.log(
+        `     ${r.blocking ? "🔴" : "•"} ${r.key}: ${r.findings}${where}${fresh}`,
+      );
+    }
+    console.log(
+      `     Nothing here proves anyone acted on these. The ledger records what a check SAID,`,
+    );
+    console.log(
+      `     never what was done about it — that lives in the session, not in a file.`,
+    );
+  }
+
+  const quiet = rows.filter(
+    (r) => r.state === "FRESH" && r.findings === 0 && r.abstained,
+  );
+  if (quiet.length) {
+    console.log(
+      `\n  🤍 ran against the current bytes and recorded nothing: ${quiet.length} check(s)`,
+    );
+    console.log(
+      `     ${quiet.map((r) => `${r.key} (${r.abstained.reason})`).join(", ")}`,
+    );
+    console.log(
+      `     Read this as the ABSENCE of a finding, which is what it is. \`no-witness\` means the`,
+    );
+    console.log(
+      `     check ran and has no witness for the negative answer — unlike a certifying`,
+    );
+    console.log(
+      `     algorithm (McConnell et al. 2011), which ships one for both answers. Our discipline`,
+    );
+    console.log(
+      `     is strictly weaker than theirs and this line is where that shows.`,
+    );
+    for (const [reason, meaning] of ABSTENTIONS) {
+      if (quiet.some((r) => r.abstained.reason === reason))
+        console.log(`       ${reason}: ${meaning}`);
+    }
+  }
+
+  const blocking = stale.length + never.length;
+  console.log(
+    `\n  ${blocking === 0 ? "🟢 every expected check answered for the current text" : `🔴 ${blocking} check(s) not answering for the current text`}\n`,
+  );
+  return 0; // advisory: this reports, it does not block
+}
+
+if (isMain(import.meta.url)) process.exit(main(process.argv));

package/skills/paper-status/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: paper-status
+description: Answer "what's the status of the paper?" in one pass — MEASURE what is measurable (page count from the real build, git state, which gates were run against the CURRENT text), then read the judgement rows, then print blockers worst-first split into mine and the author's. Use whenever the author asks "what's up with the paper / status / what's left / is it ready", at the start of a session touching a paper, or before deciding what to work on next. Not a review skill — it reports state, it does not grade, cut, or fix.
+allowed-tools: [Bash, Read, Grep, Glob]
+---
+
+<!-- vigiles:sha256:51bc50b2485782e4 compiled from skills/paper-status/SKILL.md.spec.ts -->
+
+# paper-status — state, measured before it is narrated
+
+## Run me
+
+🔴 FIRST, before any other step:
+
+```
+node .claude/skills/paper-pipeline/scripts/announce.mjs paper-status <paper-dir>
+```
+
+An advisory pass cannot be observed failing — silence is both its error state and its normal
+state — so starting is an event, and events get written down.
+
+The author asks "what's the status there?" constantly, and the answer keeps coming from the wrong place: my
+memory of the session, which drifts, or a 200-line scorecard he cannot skim. Both fail the same way —
+**they narrate state instead of measuring it.**
+
+Grounding failure, 2026-08-04 (`compile-rules-2026`, day before deadline): a status line in chat said
+the review panel was running. It had never been launched. Another said the paper was 8 pages while the
+real build said 9 and BLOCKED — steering a whole day of cuts by the wrong instrument. Both would have
+been caught by running two commands instead of recalling two facts.
+
+## The rule this skill exists to enforce
+
+**Anything a command can answer is not allowed to come from memory or from prose.** Measure first,
+read the scorecard second, and mark clearly which is which. A claim in `PIPELINE-STATUS.md` is a claim
+about the past; the build is the present.
+
+## 🔴 The second rule: status is PUSHED, never waited for
+
+The corpus owner, 2026-08-05: *"I have to constantly ask for the paper's status and direct you so you tell me what we can do next"*. Building a skill that answers when asked fixed the wrong half —
+the work he was complaining about is **the asking**, and a pull-only skill leaves all of it with him.
+
+So on any turn that touched a paper, the reply ends with **three lines, unprompted**:
+
+1. **where it stands** — the build's own verdict line, page count, deadline countdown;
+2. **the single next action, with an owner** — not a menu. If it is mine, it is already started or
+   started in the same reply. If it is his, it says exactly what to click.
+3. **what is stale** — a gate whose verdict predates the current text, named.
+
+Three failures make this a rule rather than a preference, all in one session:
+- I finished a page-fit cut and stopped, so he asked what the status was;
+- I left artifact hosting on his side of the split for a day and a half while the credential to clear
+  it sat in the environment (see `credential-available` in `pipeline-check.mjs`);
+- three consecutive panels returned Weak Accept and the ceiling they named was never the next task,
+  because nothing turned "here is the score" into "here is what to do about it".
+
+**Never end a paper turn on a completed sub-task alone.** "Fits in 8 pages" is a measurement, not a
+status; the status is what that measurement makes possible next.
+
+**Enforcement leg.** `pipeline-check.mjs` prints its banner **unconditionally**, including when it has
+zero findings — deadline countdown, verdict row, and `➡️ NEXT`. It runs from `paper-status-gates.sh`
+on every edit to a paper source, so the state arrives without anyone pulling it. If that banner and
+this section ever disagree, the banner is a measurement and this is prose: believe the banner.
+
+## How to run it
+
+### 1. Measure (no reading yet)
+
+```bash
+cd <paper-dir>
+bash repro/build-submission.sh 2>&1 | grep -Ei 'body pages|VERDICT|Overfull|undefined|anonymity'
+git status --porcelain                      # uncommitted work
+git log --oneline @{u}..HEAD                # unpushed commits
+```
+
+- **The build is the only page-count authority.** If the repo has an approximate measurer, do not use
+  it and say so. In this project `measure.sh` was gutted on 2026-08-04 for exactly this reason.
+- Report the build's own verdict line verbatim. Do not paraphrase `BLOCKED` into "nearly there".
+
+### 2. Detect stale gates — the part memory always gets wrong
+
+A gate is stale if the paper changed after the gate ran. Check it mechanically, not by recall:
+
+```bash
+git log -1 --format=%cd --date=short -- paper.md          # when the text last moved
+ls -la reviews/ | tail -20                                # when each gate last reported
+```
+
+Compare against the dates in `PIPELINE-STATUS.md`. If the paper moved after a gate's date, that
+gate's verdict **does not describe the current paper** — say so explicitly, and say what changed since.
+An accept-probability from a superseded draft is not evidence about this one; carrying it forward is
+the single most common way a status report lies.
+
+If the project ships a checker (`.claude/skills/paper-pipeline/scripts/pipeline-check.mjs`), run it.
+
+### 3. Read the judgement rows — from BOTH checklists, they answer different questions
+
+The project already carries the checklists this skill should report against. Do not invent a new list
+and do not report from one of them alone:
+
+| source | the question it answers | what to pull |
+|---|---|---|
+| **`<paper-dir>/PIPELINE-STATUS.md`** | were the QUALITY stages run, and what did they conclude | per-stage `☑`/`◐`/`☐`/`⚠`, dates, the one-line submit-ready verdict |
+| **`<paper-dir>/SUBMIT-CHECKLIST.md`** | does it comply with the VENUE's format, and is the submission mechanics understood | page limit, template, blind model, mandatory sections, portal URL, whether a supplementary-upload field exists, the deadline converted to the author's own zone |
+| **`.claude/hooks/paper-skills-nudge.hook.ts`** | which gates EXIST at all | the canonical pre-submit gate list — use it to spot a gate nobody has ever run, which no scorecard row will show because the row was never added |
+| `<paper-dir>/CLAIMS.md` | what may still be claimed | 🔴 retired claims — flag if the current text asserts one |
+| `<paper-dir>/CLAUDE.md` | what this venue rewards | only when it changes what to do next |
+
+🔴 **Both checklists must be green before upload, and they fail differently.** A paper can pass every
+quality gate and still be unsubmittable (no active account, no supplementary field so the artifact
+needs external hosting, deadline misconverted from AoE). Reporting only the quality side is how a
+"ready" paper misses its deadline. The compliance side usually contains the blockers that are *his*,
+which is exactly why they belong at the top of the output.
+
+### 4. Print it, in this shape and this order
+
+Short. He is asking because he wants to decide what to do next, not to read a report.
+
+1. **One line: can it be submitted right now?** The build verdict plus the hard blockers, nothing else.
+2. **Blockers, worst first, split by owner** — 🔴 his (accounts, hosting, anything needing a human or a
+   login) vs 🔵 mine (text, gates, artifacts). His come first: he can start them while I work.
+3. **Gates** (`PIPELINE-STATUS.md`), each marked ✅ ran against current text · ⚠️ ran against an older
+   text (name what changed) · ☐ never run. Cross-check against the hook's canonical gate list so a
+   gate with no row at all shows up as ☐ rather than vanishing.
+4. **Format compliance** (`SUBMIT-CHECKLIST.md`) — one line: green, or the specific item that is not.
+   Page limit and blind model come from the measured build, not from the checklist's memory of them.
+5. **What moved since he last asked**, three lines maximum.
+6. **The deadline, in his timezone**, and what is on the critical path to it.
+
+## Record the verdict
+
+🔴 LAST step, once the deliverable exists:
+
+```
+node .claude/skills/paper-pipeline/scripts/ledger.mjs record paper-status <paper-dir> FINDING <count> <report-path>
+node .claude/skills/paper-pipeline/scripts/ledger.mjs record paper-status <paper-dir> ABSTAINED <reason> "<one line>"
+```
+
+This skill reports state and does not judge the paper, so what it records is about the **status run**:
+**FINDING** — `<count>` blockers printed, `<report-path>` the status output.
+**ABSTAINED** — `no-witness`: the status run measured everything it can and printed zero blockers.
+`crashed`: the build did not run, so nothing was measured.
+
+🔴 `crashed` is the one outcome that must never be narrated as a status. This skill exists because
+state was being narrated instead of measured; a status report built on a build that did not happen
+is that same failure with a fresh timestamp on it. Under the old vocabulary this was `ERROR`, which
+sat in the same column as a verdict about the paper — it does not any more.
+
+🔴 **There is no PASS**, so "zero blockers" cannot be stored. Print it, and let the reader draw the
+conclusion from an empty blocker list they can see.
+
+## Rules
+
+- **Never report a gate as run because I intended to run it.** Predicting a background agent's result,
+  or calling a queued task "running" when nothing was launched, is the failure this skill was written
+  after. If a task was not launched, the honest line is "not started".
+- **Owner-split is not decoration.** A blocker only he can clear (an account, an upload, a phone call)
+  belongs at the top, because every hour it sits is an hour of pure schedule loss.
+- **Numbers, not adjectives.** "8/8 pages, fits" not "about right"; "78 stalls over 8 pages against a
+  threshold of 2" not "readable enough".
+- **Say what is NOT known.** A gate never run is a real answer and more useful than an optimistic one.
+- 🔴 **Send the built PDF with the report, every time, without being asked** (`SendUserFile`, from the
+  outdir the report's page count came from — never an older copy). The corpus owner, 2026-08-05: *"and I often ask for the PDF to be delivered"*. He reads the paper, not the scorecard; a status report that makes him ask for the
+  artifact costs a round trip for nothing. The caption states the build time and the page count, so
+  the file cannot be mistaken for an earlier one.
+- 🔴 **Never let "the gates are stale" be heard as "the measurements are stale."** They are different
+  objects and conflating them destroys trust in real data: a *measurement* is an experiment on the
+  tool or corpus and stays valid until the tool changes; a *gate* is a judgement of the paper text and
+  expires the moment the text moves. Name which one you mean, every time. On 2026-08-05 a one-word
+  slip here made a four-hour experiment sound like wasted work.
+- Do not fix anything while reporting. Status and work are different turns — mixing them is how the
+  status stops being trustworthy.
+
+## Compose with
+
+- `paper-pipeline` — owns the stage contract this reads.
+- `harden-paper` — the decision to submit; this only reports the inputs to it.
+- `handoff` — end-of-session preservation; this is the start-of-session counterpart.
+
+## Provenance
+
+Built 2026-08-04, the day before the `compile-rules-2026` deadline, after the author asked for paper status
+for the fourth time in one session and pointed out it should be a command: *"I ask this so often... there should be a skill"*. He was right, and the two things the skill measures first are the two
+things chat had most recently gotten wrong.

package/skills/paper-status/SKILL.md.spec.ts

@@ -0,0 +1,190 @@
+// Compiled to SKILL.md by `vigiles compile`. Edit THIS file, never the markdown.
+//
+// Adopted 2026-08-17 as part of the second batch. The body is the previous SKILL.md
+// VERBATIM, so the compiled diff shows only what the compiler adds. No `disallowedTools`
+// fence yet: the field exists on `SkillSpec` as of the branch `claude/skill-disallowed-tools`
+// but is not in a release `mine` installs, so adding it here would not compile.
+import { experimental_skill } from "vigiles/spec";
+
+export default experimental_skill({
+  name: "paper-status",
+  description:
+    "Answer \"what's the status of the paper?\" in one pass — MEASURE what is measurable (page count from the real build, git state, which gates were run against the CURRENT text), then read the judgement rows, then print blockers worst-first split into mine and the author's. Use whenever the author asks \"what's up with the paper / status / what's left / is it ready\", at the start of a session touching a paper, or before deciding what to work on next. Not a review skill — it reports state, it does not grade, cut, or fix.",
+  tools: ["Bash", "Read", "Grep", "Glob"],
+  body: `
+# paper-status — state, measured before it is narrated
+
+## Run me
+
+🔴 FIRST, before any other step:
+
+\`\`\`
+node .claude/skills/paper-pipeline/scripts/announce.mjs paper-status <paper-dir>
+\`\`\`
+
+An advisory pass cannot be observed failing — silence is both its error state and its normal
+state — so starting is an event, and events get written down.
+
+The author asks "what's the status there?" constantly, and the answer keeps coming from the wrong place: my
+memory of the session, which drifts, or a 200-line scorecard he cannot skim. Both fail the same way —
+**they narrate state instead of measuring it.**
+
+Grounding failure, 2026-08-04 (\`compile-rules-2026\`, day before deadline): a status line in chat said
+the review panel was running. It had never been launched. Another said the paper was 8 pages while the
+real build said 9 and BLOCKED — steering a whole day of cuts by the wrong instrument. Both would have
+been caught by running two commands instead of recalling two facts.
+
+## The rule this skill exists to enforce
+
+**Anything a command can answer is not allowed to come from memory or from prose.** Measure first,
+read the scorecard second, and mark clearly which is which. A claim in \`PIPELINE-STATUS.md\` is a claim
+about the past; the build is the present.
+
+## 🔴 The second rule: status is PUSHED, never waited for
+
+The corpus owner, 2026-08-05: *"I have to constantly ask for the paper's status and direct you so you tell me what we can do next"*. Building a skill that answers when asked fixed the wrong half —
+the work he was complaining about is **the asking**, and a pull-only skill leaves all of it with him.
+
+So on any turn that touched a paper, the reply ends with **three lines, unprompted**:
+
+1. **where it stands** — the build's own verdict line, page count, deadline countdown;
+2. **the single next action, with an owner** — not a menu. If it is mine, it is already started or
+   started in the same reply. If it is his, it says exactly what to click.
+3. **what is stale** — a gate whose verdict predates the current text, named.
+
+Three failures make this a rule rather than a preference, all in one session:
+- I finished a page-fit cut and stopped, so he asked what the status was;
+- I left artifact hosting on his side of the split for a day and a half while the credential to clear
+  it sat in the environment (see \`credential-available\` in \`pipeline-check.mjs\`);
+- three consecutive panels returned Weak Accept and the ceiling they named was never the next task,
+  because nothing turned "here is the score" into "here is what to do about it".
+
+**Never end a paper turn on a completed sub-task alone.** "Fits in 8 pages" is a measurement, not a
+status; the status is what that measurement makes possible next.
+
+**Enforcement leg.** \`pipeline-check.mjs\` prints its banner **unconditionally**, including when it has
+zero findings — deadline countdown, verdict row, and \`➡️ NEXT\`. It runs from \`paper-status-gates.sh\`
+on every edit to a paper source, so the state arrives without anyone pulling it. If that banner and
+this section ever disagree, the banner is a measurement and this is prose: believe the banner.
+
+## How to run it
+
+### 1. Measure (no reading yet)
+
+\`\`\`bash
+cd <paper-dir>
+bash repro/build-submission.sh 2>&1 | grep -Ei 'body pages|VERDICT|Overfull|undefined|anonymity'
+git status --porcelain                      # uncommitted work
+git log --oneline @{u}..HEAD                # unpushed commits
+\`\`\`
+
+- **The build is the only page-count authority.** If the repo has an approximate measurer, do not use
+  it and say so. In this project \`measure.sh\` was gutted on 2026-08-04 for exactly this reason.
+- Report the build's own verdict line verbatim. Do not paraphrase \`BLOCKED\` into "nearly there".
+
+### 2. Detect stale gates — the part memory always gets wrong
+
+A gate is stale if the paper changed after the gate ran. Check it mechanically, not by recall:
+
+\`\`\`bash
+git log -1 --format=%cd --date=short -- paper.md          # when the text last moved
+ls -la reviews/ | tail -20                                # when each gate last reported
+\`\`\`
+
+Compare against the dates in \`PIPELINE-STATUS.md\`. If the paper moved after a gate's date, that
+gate's verdict **does not describe the current paper** — say so explicitly, and say what changed since.
+An accept-probability from a superseded draft is not evidence about this one; carrying it forward is
+the single most common way a status report lies.
+
+If the project ships a checker (\`.claude/skills/paper-pipeline/scripts/pipeline-check.mjs\`), run it.
+
+### 3. Read the judgement rows — from BOTH checklists, they answer different questions
+
+The project already carries the checklists this skill should report against. Do not invent a new list
+and do not report from one of them alone:
+
+| source | the question it answers | what to pull |
+|---|---|---|
+| **\`<paper-dir>/PIPELINE-STATUS.md\`** | were the QUALITY stages run, and what did they conclude | per-stage \`☑\`/\`◐\`/\`☐\`/\`⚠\`, dates, the one-line submit-ready verdict |
+| **\`<paper-dir>/SUBMIT-CHECKLIST.md\`** | does it comply with the VENUE's format, and is the submission mechanics understood | page limit, template, blind model, mandatory sections, portal URL, whether a supplementary-upload field exists, the deadline converted to the author's own zone |
+| **\`.claude/hooks/paper-skills-nudge.hook.ts\`** | which gates EXIST at all | the canonical pre-submit gate list — use it to spot a gate nobody has ever run, which no scorecard row will show because the row was never added |
+| \`<paper-dir>/CLAIMS.md\` | what may still be claimed | 🔴 retired claims — flag if the current text asserts one |
+| \`<paper-dir>/CLAUDE.md\` | what this venue rewards | only when it changes what to do next |
+
+🔴 **Both checklists must be green before upload, and they fail differently.** A paper can pass every
+quality gate and still be unsubmittable (no active account, no supplementary field so the artifact
+needs external hosting, deadline misconverted from AoE). Reporting only the quality side is how a
+"ready" paper misses its deadline. The compliance side usually contains the blockers that are *his*,
+which is exactly why they belong at the top of the output.
+
+### 4. Print it, in this shape and this order
+
+Short. He is asking because he wants to decide what to do next, not to read a report.
+
+1. **One line: can it be submitted right now?** The build verdict plus the hard blockers, nothing else.
+2. **Blockers, worst first, split by owner** — 🔴 his (accounts, hosting, anything needing a human or a
+   login) vs 🔵 mine (text, gates, artifacts). His come first: he can start them while I work.
+3. **Gates** (\`PIPELINE-STATUS.md\`), each marked ✅ ran against current text · ⚠️ ran against an older
+   text (name what changed) · ☐ never run. Cross-check against the hook's canonical gate list so a
+   gate with no row at all shows up as ☐ rather than vanishing.
+4. **Format compliance** (\`SUBMIT-CHECKLIST.md\`) — one line: green, or the specific item that is not.
+   Page limit and blind model come from the measured build, not from the checklist's memory of them.
+5. **What moved since he last asked**, three lines maximum.
+6. **The deadline, in his timezone**, and what is on the critical path to it.
+
+## Record the verdict
+
+🔴 LAST step, once the deliverable exists:
+
+\`\`\`
+node .claude/skills/paper-pipeline/scripts/ledger.mjs record paper-status <paper-dir> FINDING <count> <report-path>
+node .claude/skills/paper-pipeline/scripts/ledger.mjs record paper-status <paper-dir> ABSTAINED <reason> "<one line>"
+\`\`\`
+
+This skill reports state and does not judge the paper, so what it records is about the **status run**:
+**FINDING** — \`<count>\` blockers printed, \`<report-path>\` the status output.
+**ABSTAINED** — \`no-witness\`: the status run measured everything it can and printed zero blockers.
+\`crashed\`: the build did not run, so nothing was measured.
+
+🔴 \`crashed\` is the one outcome that must never be narrated as a status. This skill exists because
+state was being narrated instead of measured; a status report built on a build that did not happen
+is that same failure with a fresh timestamp on it. Under the old vocabulary this was \`ERROR\`, which
+sat in the same column as a verdict about the paper — it does not any more.
+
+🔴 **There is no PASS**, so "zero blockers" cannot be stored. Print it, and let the reader draw the
+conclusion from an empty blocker list they can see.
+
+## Rules
+
+- **Never report a gate as run because I intended to run it.** Predicting a background agent's result,
+  or calling a queued task "running" when nothing was launched, is the failure this skill was written
+  after. If a task was not launched, the honest line is "not started".
+- **Owner-split is not decoration.** A blocker only he can clear (an account, an upload, a phone call)
+  belongs at the top, because every hour it sits is an hour of pure schedule loss.
+- **Numbers, not adjectives.** "8/8 pages, fits" not "about right"; "78 stalls over 8 pages against a
+  threshold of 2" not "readable enough".
+- **Say what is NOT known.** A gate never run is a real answer and more useful than an optimistic one.
+- 🔴 **Send the built PDF with the report, every time, without being asked** (\`SendUserFile\`, from the
+  outdir the report's page count came from — never an older copy). The corpus owner, 2026-08-05: *"and I often ask for the PDF to be delivered"*. He reads the paper, not the scorecard; a status report that makes him ask for the
+  artifact costs a round trip for nothing. The caption states the build time and the page count, so
+  the file cannot be mistaken for an earlier one.
+- 🔴 **Never let "the gates are stale" be heard as "the measurements are stale."** They are different
+  objects and conflating them destroys trust in real data: a *measurement* is an experiment on the
+  tool or corpus and stays valid until the tool changes; a *gate* is a judgement of the paper text and
+  expires the moment the text moves. Name which one you mean, every time. On 2026-08-05 a one-word
+  slip here made a four-hour experiment sound like wasted work.
+- Do not fix anything while reporting. Status and work are different turns — mixing them is how the
+  status stops being trustworthy.
+
+## Compose with
+
+- \`paper-pipeline\` — owns the stage contract this reads.
+- \`harden-paper\` — the decision to submit; this only reports the inputs to it.
+- \`handoff\` — end-of-session preservation; this is the start-of-session counterpart.
+
+## Provenance
+
+Built 2026-08-04, the day before the \`compile-rules-2026\` deadline, after the author asked for paper status
+for the fourth time in one session and pointed out it should be a command: *"I ask this so often... there should be a skill"*. He was right, and the two things the skill measures first are the two
+things chat had most recently gotten wrong.`,
+});