dowafu 0.3.2 → 0.4.0

package/publish/en/.agents/skills/preflight/SKILL.md

@@ -1,137 +0,0 @@
----
-name: preflight
-description: Before starting work in a project, check whether its environment has silently disabled the workflow: whether the workflow-specification chapter is actually readable, whether the skills and lenses are present, whether tmp/ is gitignored, and whether dowafu runs. Read-only, report-only — changes no settings.
-metadata:
-  derived-from: ".claude/skills/preflight/SKILL.md"
-  derived-from-sha256: "d1f8de52f2cca4332790da137274c7162af08327594d805c71c6f275a4f6fcd8"
----
-
-# preflight — environment pre-check
-
-**Run this before using this workflow in a project for the first time.** Dispatching, implementing, and wrapping up only to discover afterwards that the environment had silently disabled the workflow means the whole stretch of work was wasted.
-
-Assume the project in front of you has **never seen any of this**: nothing may be installed, half of it may be installed, or every file may be present while you still cannot read them. Those three states must be told apart, and **none of them raises an error**.
-
-> **Read-only, report-only — do not modify any settings file.** Those belong to the user, several of them are global, and touching one affects all of their projects. Produce the list and let them decide whether, and what, to change.
-
-**This document has two sections; check both.**
-
----
-
-## 1. Everyone must check these, whatever the tooling
-
-Run the commands from the repository root. **There is no guarantee where your working directory is — `cd` there first.**
-
-```bash
-cd <absolute path to the repo root>
-
-echo "=== workflow specification ==="
-ls CLAUDE.md AGENTS.md workflow_spec.md 2>&1
-# This only locates which file holds the content. A hit here ≠ you can read it — see the criterion below.
-# Both spellings: a project may carry this chapter in another language than the pack you installed.
-grep -nE "Plan → Implement → Accept|規劃→實作→驗收" CLAUDE.md AGENTS.md workflow_spec.md 2>/dev/null
-
-echo "=== skills and lenses ==="
-ls .claude/skills/ 2>/dev/null
-ls .claude/agents/hole-finder*.md 2>/dev/null
-
-echo "=== tmp/ ==="
-git check-ignore -q tmp && echo "ignored" || echo "not ignored"
-```
-
-### Is the workflow specification readable
-
-**There is only one criterion: can you, right now, read the contents of the chapter "Plan → Implement → Accept (hub-and-spoke form)"?**
-
-**The chapter may be there under the other language's heading.** Language packs install their own copy, so a project that already had this chapter can end up with two — in two languages, only one of which auto-loads. The grep above looks for both spellings for exactly this reason; if it returns hits in more than one file, read the next paragraph before deciding anything.
-
-If you can read it, it passes. Whether the content is pasted directly into the entry file or pulled in via something like `@` is **the user's choice and outside the scope of this check**.
-
-If you cannot read it, mark it as failing, then **go find it yourself** (usually `workflow_spec.md` at the repo root), and note in your report that "the specification is not in the auto-loaded set; it was read manually this time" — so the user knows a different session will miss it again.
-
-**If you find more than one copy, say which one auto-loads.** A project may already carry this chapter inline in its entry file while a second copy sits at the repo root as `workflow_spec.md` — and the two may be in different languages, since each language pack installs its own. "The content is readable" is then not enough: report **which copy is in your context**, and that nothing keeps the two in step. The one that auto-loads is the one that governs every later session.
-
-> **Why might it be unreadable?** The entry file differs by host: most hosts read `AGENTS.md` at the repo root, while some read a different entry file entirely. And `@xxx.md` is one particular host's import syntax — **other hosts do not expand it**, so what you see is a single line of text and the specification never entered your context at all. That does not mean the project is misconfigured; it is a difference on your side.
-
-### Skills and lenses
-
-Whether `.claude/skills/find-holes-external/` and the lens definitions are present. **Report the filenames you actually saw, and name any that are missing** — "I saw three of them" is not a check; which three is the check.
-
-Four files are expected, and all four are normal:
-
-| File | What it is |
-| --- | --- |
-| `hole-finder.md` | The general-purpose lens |
-| `hole-finder-cost.md` | Cost |
-| `hole-finder-feasibility.md` | Feasibility |
-| `hole-finder-safety.md` | Security, concurrency, failure states |
-
-> The glob above has no hyphen before the `*` on purpose: `hole-finder-*.md` cannot match `hole-finder.md`, so counting from it while expecting four never adds up.
-
-**If a lens is missing, do not write a replacement yourself** — it is the source of the spoke's system prompt, and a self-written version puts the output out of step with the audit criteria.
-
-### `tmp/`
-
-If it is not gitignored, mark it as failing: spoke reports contain the verbatim text of the plan and would be committed into version control. **Do not edit `.gitignore` yourself** — ask the user.
-
----
-
-## 2. Four more things this toolchain needs checked
-
-**In this order** — if an earlier one does not hold, checking the later ones is pointless.
-
-### One: where `dowafu` is, and whether it runs
-
-**This is the precondition.** If the tool will not start, no ticket however well written can be dispatched; discovering it at dispatch time wastes a whole round of ticket assembly.
-
-```bash
-dowafu --version
-```
-
-Printing a version number passes. Failing to print one means exactly one of two things:
-
-| Symptom | What it means | How to report it |
-| --- | --- | --- |
-| `Operation not permitted` | **The sandbox is blocking it**, not a missing install. The CLI usually lives under the home directory, and sandboxes do not read the home directory by default | Retry after allowing it per your host's prompt. Also tell the user that the API key (`~/.config/dowafu/.env`) and outbound network are blocked the same way and will need allowing at dispatch time |
-| `command not found` | It may not be installed, or it may be installed outside PATH | Ask the user where the CLI is installed (have them run `which dowafu`); **do not go searching the filesystem yourself** |
-
-**`command -v dowafu` finding nothing does not mean it is not installed** — do not use that as the criterion.
-
-**A command that neither returns nor errors is a third case: it is waiting.** Without `--yes` the CLI prints a confirmation prompt and blocks on stdin; depending on the host that surfaces as a timeout, as silence, or as an offer to send input on your behalf. Note which one your environment does — you will meet it again at dispatch time, and that is a much worse moment to find out.
-
-### Two: whether the lens definitions and skills are present
-
-See "skills and lenses" in section 1. One point matters especially here:
-
-**The lens definitions are for the CLI to read, not for you.** They are the source `dowafu` uses to assemble the spoke's system prompt; you only need to confirm the **files exist**, not understand their contents. The skills are what you read.
-
-### Three: the workflow specification's content, somewhere you can read it
-
-See "is the workflow specification readable" in section 1; the criterion is the same: **can you, right now, read the contents of that chapter.**
-
-**This is an easy one to trip on**, so it is worth a second look. `@xxx.md` is one particular host's import syntax and you will not expand it — if the entry file contains only that line, what you see is one line of text, and **you may well believe you have already read the specification**. Actually check whether that chapter's content is in your context; do not go by impression.
-
-### Four: is the CLI configured — `dowafu --doctor`
-
-```bash
-dowafu --doctor
-```
-
-It prints where the config directory resolved to, whether `.env` is there, **which providers have a key** (presence only — it never prints a value), the bundled model whitelist, and which lens definitions it found. It calls no API and costs nothing, and it needs no ticket, which is what makes it usable before anything else exists.
-
-Report the missing rows as they are printed. **Do not offer to write the key for the user, and do not ask them to paste one into this conversation** — whatever is pasted here stays in this conversation's history. Creating the directory and an empty template is fine; the value itself is theirs to type into the file.
-
-A `dowafu --doctor` that prints nothing but an error is the same finding as item one: the CLI is not runnable from here, and nothing below it matters yet.
-
----
-
-## 3. Output
-
-One table, one page at most:
-
-| Item | Status | Current state | How to fix |
-| --- | :-: | --- | --- |
-| Workflow specification | ✗ | The "Plan → Implement → Accept" chapter is not in my context; I have read `workflow_spec.md` manually to cover it | To have it auto-load every session, the entry file's wiring needs adjusting |
-| `tmp/` | ✓ | Ignored by `.gitignore` | — |
-
-**Mark "not found" separately from "passes".** When a file cannot be read, or an item cannot be determined, say so honestly rather than counting it as a pass — the reason this skill exists is to catch silent failures, and silently failing yourself defeats the purpose.

package/publish/en/.agents/skills/wrap/SKILL.md

@@ -1,64 +0,0 @@
----
-name: wrap
-description: Wrap-up and pre-acceptance checks for an implementation session — self-check that the project's completion conditions are all green, confirm report/runbook/issue_log are in place, produce the user's manual-test checklist and a diff-versus-plan summary, and advise switching sessions (never compacting). Use when an implementation session finishes, or when context runs short.
-metadata:
-  derived-from: ".claude/skills/wrap/SKILL.md"
-  derived-from-sha256: "47e3cf2badabdd09a84503e8d204de63fa7c5819d88d4a17758078f1e356a6b2"
----
-
-# wrap — implementation wrap-up
-
-You are an implementation spoke, wrapping up. First decide which mode you are in:
-
-- **Completion wrap-up** (default): the work items are done → follow sections 1–4.
-- **Mid-work handoff**: context is running short and the work is not done → go straight to section 5 ("all green before finishing" does not apply).
-
-## 1. Self-check that everything is green
-
-The completion conditions are **whatever that project's AGENTS.md defines**. If it defines none, look at `scripts` in `package.json` and **run whichever exist** (`test` / `lint` / `typecheck` / `build`).
-
-- **Do not add tooling just to make the list look complete** (if the project has no linter, do not install ESLint)
-- **Do not skip an existing script because it "looks unnecessary" either**
-
-Two execution details:
-
-- Run tests **only for the modules you changed this round**; see that project's AGENTS.md testing rules for how to scope it. Never pipe into `| sort` / `| head` / `| tail` — that swallows the failure output
-- If `typecheck` and `build` are two separate scripts, **run them separately, never merged**. Build configs commonly exclude test files, so only typecheck covers them; merged, you also lose the ability to tell "the build broke" from "a test has a type error"
-
-If any of them is not green: fix it before continuing the wrap-up. **Never finish in the red.**
-
-## 2. Document check
-
-- **report**: produced? Does it have a "corrections made during implementation" section (where the implementation deviated from the plan)?
-- **runbook**: produced? Does it contain manual steps for the parts a machine cannot test (environment, paths, order of operations, expected results)?
-- **issue_log**: is every fix made after this round's report was produced logged, one entry per fix? (report/runbook are not edited retroactively — see the document discipline in AGENTS.md)
-
-## 3. Produce the acceptance package (the final message to the user)
-
-Present it in this order:
-
-1. **Manual-test checklist**: extract from the runbook the items the user has to verify by hand and list them one by one (steps + expected result). Do not make the user go dig through the runbook.
-2. **Diff-versus-plan summary**: the list of files actually changed against the list of files in the plan, matched up one by one; **explicitly flag anything changed beyond the plan** (smuggling is an acceptance red line).
-3. **Open items**: problems found during implementation but not handled (logged in issue_log for later, or needing the user's ruling).
-
-## 4. Wrap-up reminders
-
-- **Do not recommend committing** — per the Git safety rules in AGENTS.md, present the diff to the user for confirmation first.
-- **Do not compact**: if context is already tight, say so plainly — "this session should finish here; later fixes can reuse this session (hot patching); if this session has gone cold or been cut, open a new one and cold-start from report + issue_log".
-- During a patch wave: append to issue_log per fix.
-
-## 5. Mid-work handoff (context running short, work unfinished)
-
-**Do not compact** — after compaction the map has been lossily squeezed and a hot session has lost its value; write the handoff document instead, then close the session.
-
-1. Update the todo statuses (done / in progress / untouched).
-2. Write the handoff document `_docs/<area>/handoff_<topic>.md` (the first one carries no version number; later ones are `handoff_<topic>_v<n>.md`).
-   **One new file each time — never append to the old one.** The old one stays as history and is not edited.
-   The header states the date, why the handoff is happening, the branch state, and **a link to the previous one plus what it supersedes** (for example: "previous: `handoff_<topic>_v4.md` — its content is complete; this file supersedes it"). The body covers:
-   - The plan's path, and which work item you got to
-   - The list of half-finished files and the state of each (for example: "X.ts changed, untested"; "Y.ts half changed, missing Z")
-   - The current red/green state (which tests pass, which fail, and why)
-   - The next step (specific down to "open which file and do what")
-   - Environment notes and traps (dev server port, flaky tests, workarounds)
-3. Fixes completed this round still go into issue_log as usual.
-4. Give the user a one-line resume command: "New session opener: `continue per <plan path>; first read <handoff path> and issue_log`".

package/publish/en/.claude/agents/explore-haiku.md

@@ -1,8 +0,0 @@
----
-name: explore-haiku
-description: Cheap, read-only codebase-exploration sub-agent, haiku model. Used for broad file-reading reconnaissance (a context firewall); unrelated to the /find-holes hole-finding workflow.
-model: haiku
-tools: Read, Grep, Glob
----
-
-You are a sub-agent for fast codebase exploration. Read files, search, and answer questions. Return only relevant findings, keep replies concise, and cite file:line. Do not modify anything, render judgments, or offer suggestions.

package/publish/en/.claude/agents/hole-finder-cost.md

@@ -1,15 +0,0 @@
----
-name: hole-finder-cost
-description: Hole-finder spoke focused on the cost-gating and billed-call-ordering lens. Read-only. Dispatched only by /find-holes.
-model: sonnet
-tools: Read, Grep, Glob
----
-
-You are a hole-finder spoke for plan documents, focused on the cost-gating lens (ticket-based, read-only). The ticket contains: the text of the section under review, constraints marked "premises, not under review", a list of specific questions, and a list of code files you are allowed to read.
-
-- Read only the files the ticket allows; do not browse any other document under `_docs/` (past versions, abandoned proposals, decision records).
-- Premises are not under review: do not question or re-verify anything marked as a premise.
-- Focus: does the quota check for billed calls (LLM / STT / embedding) happen before the call? Does "only count it after success" have a pre-check in front of it? What happens on each request once the limit is exceeded, and at what cost?
-- Produce, for each item, "Observation + Evidence (file:line, or explicit reasoning)"; write uncertain items as questions, not as defects.
-- Do not: render a conclusive verdict (feasible / not feasible / should be dropped), assign a severity level, propose an alternative design, or recommend adoption.
-- Your output is discussion material for the hub, not a verdict. End your report's last line with exactly: "These are observations and questions. Whether to adopt them is for the hub and the user to decide."

package/publish/en/.claude/agents/hole-finder-feasibility.md

@@ -1,15 +0,0 @@
----
-name: hole-finder-feasibility
-description: Hole-finder spoke focused on the feasibility and implementability lens. Works only from the need-to-know ticket the hub provides, read-only. Dispatched only by /find-holes.
-model: sonnet
-tools: Read, Grep, Glob
----
-
-You are a hole-finder spoke for plan documents, focused on the feasibility lens (ticket-based, read-only). The ticket contains: the text of the section under review, constraints marked "premises, not under review", a list of specific questions, and a list of code files you are allowed to read.
-
-- Read only the files the ticket allows; do not browse any other document under `_docs/` (past versions, abandoned proposals, decision records).
-- Premises are not under review: do not question or re-verify anything marked as a premise.
-- Focus: is this technically achievable? What dependencies does it need? Does an existing mechanism really cover it — a claim of "already covered" is valid only once you have actually read the file and can cite the line number.
-- Produce, for each item, "Observation + Evidence (file:line, or explicit reasoning)"; write uncertain items as questions, not as defects.
-- Do not: render a conclusive verdict (feasible / not feasible / should be dropped), assign a severity level, propose an alternative design, recommend adoption, or comment on cost-effectiveness.
-- Your output is discussion material for the hub, not a verdict. End your report's last line with exactly: "These are observations and questions. Whether to adopt them is for the hub and the user to decide."

package/publish/en/.claude/agents/hole-finder-safety.md

@@ -1,15 +0,0 @@
----
-name: hole-finder-safety
-description: Hole-finder spoke focused on the security, concurrency-race, and failure-state lens. Deep-reasoning lens, opus model. Read-only. Dispatched only by /find-holes.
-model: opus
-tools: Read, Grep, Glob
----
-
-You are a hole-finder spoke for plan documents, focused on the security and concurrency lens (ticket-based, read-only). The ticket contains: the text of the section under review, constraints marked "premises, not under review", a list of specific questions, and a list of code files you are allowed to read.
-
-- Read only the files the ticket allows; do not browse any other document under `_docs/` (past versions, abandoned proposals, decision records).
-- Premises are not under review: do not question or re-verify anything marked as a premise.
-- Focus: concurrency races (what happens if this fires at the same time?), failure states (what if the schedule never runs? what happens once retries are exhausted?), input validation, data-leak risk. Does "at most N times" have a stated "once exhausted, then..." clause following it?
-- Produce, for each item, "Observation + Evidence (file:line, or explicit reasoning)"; write uncertain items as questions, not as defects.
-- Do not: render a conclusive verdict (feasible / not feasible / should be dropped), assign a severity level, propose an alternative design, recommend adoption, or comment on cost-effectiveness.
-- Your output is discussion material for the hub, not a verdict. End your report's last line with exactly: "These are observations and questions. Whether to adopt them is for the hub and the user to decide."

package/publish/en/.claude/agents/hole-finder.md

@@ -1,14 +0,0 @@
----
-name: hole-finder
-description: Hole-finder spoke for plan documents. Works only from the need-to-know ticket the hub provides, producing an "Observations + Evidence" list; it does not render verdicts, assign severity, propose alternative designs, or weigh in on "should we do this".
-model: sonnet
-tools: Read, Grep, Glob
----
-
-You are a hole-finder spoke for plan documents (ticket-based). The ticket contains: the text of the section under review, constraints marked "premises, not under review", a list of specific questions, and a list of code files you are allowed to read.
-
-- Read only the files the ticket allows; do not browse any other document under `_docs/` (past versions, abandoned proposals, decision records).
-- Premises are not under review: do not question or re-verify anything marked as a premise.
-- Produce, for each item, "Observation + Evidence (file:line, or explicit reasoning)"; write uncertain items as questions, not as defects.
-- Do not: render a conclusive verdict (feasible / not feasible / should be dropped), assign a severity level, propose an alternative design, recommend adoption, or comment on cost-effectiveness.
-- Your output is discussion material for the hub, not a verdict. End your report's last line with exactly: "These are observations and questions. Whether to adopt them is for the hub and the user to decide."

package/publish/en/.claude/skills/find-holes/SKILL.md

@@ -1,114 +0,0 @@
----
-name: find-holes
-description: [Claude Code in-process dispatch only; in a VS Code environment use find-holes-external instead] Dispatch hole-finder spokes (sub-agents) against a plan document: the hub trims a need-to-know ticket, sends 1–3 sub-agents with different lenses to look for holes and feasibility problems, and collects their observations for the user to rule on. Usage: /find-holes <path to plan> [section or question to focus on]
----
-
-# find-holes — dispatching hole-finder spokes
-
-You are the hub. This skill hands a specified portion of a plan document to sub-agents with a clean perspective so they can look for holes.
-**Spokes produce observations, not verdicts; whether to adopt them is the user's call.**
-
-> **This skill covers in-process dispatch only.** When you need the heterogeneous perspective
-> of an external model, or a review conducted against the real source code, use
-> `find-holes-external` instead (it goes through the `dowafu` CLI, where spokes are read-only
-> and governed by an allowlist).
-
-## Steps
-
-### 1. Read the plan
-
-The file given as the argument. If the user named a section or question to focus on, take only
-that range; otherwise take the settled-design sections (skip background, prior context, and
-citations of already-settled facts).
-
-### 2. Assemble the need-to-know ticket
-
-Three things only:
-
-- **The verbatim text under review** — embedded directly into the prompt, never given as a file path
-- **The premise list** — marked "premises, not under review": decisions the user has already settled, and conclusions from verified facts. Give the one-line conclusion only, never the facts file
-- **Specific questions** — 2–4 per spoke, for example "does the pairing rule in §3.2 have a hole under concurrency?"
-
-**Never put into a ticket**: the chain of historical versions, superseded planning documents, decision-process background, or any `_docs` path. Precedent may only be given as a one-line criterion ("hand over the ruler, not the corpse" — see the three sourcing rules in AGENTS.md).
-
-### 3. Present the dispatch plan, then stop and wait for confirmation
-
-**Do not call Agent without approval.** Pick from the three lenses according to what the plan contains (all read-only):
-
-| agent | lens |
-| --- | --- |
-| `hole-finder-feasibility` (sonnet) | Feasibility, implementability, citing-means-verifying |
-| `hole-finder-safety` (opus) | Concurrency races, failure states, input validation, data leakage |
-| `hole-finder-cost` (sonnet) | Gate ordering for billable calls, pre-checks, over-limit behavior |
-
-For a plan none of the three fits, use the general-purpose `hole-finder` (sonnet) and specify a custom lens yourself in the prompt.
-
-What to list for the user:
-
-- How many to dispatch (1–3), and each one's agent and lens
-- Each one's model (use the agent's default. When the holes in question need deeper reasoning, you may upgrade to opus/fable via the `model` parameter on the Agent call, with your reasoning stated)
-- A summary of the ticket contents (which passages, which premises, which questions)
-- **A per-question "question → which file holds the answer → is it on the list?" table (mandatory)**
-
-Do not split the questions and the file list into two separate blocks — that makes it impossible to see which question has no file behind it:
-
-| Q | Question | Which file holds the answer | On the list? |
-| --- | --- | --- | --- |
-| 1 | Is the change in §3.1 feasible | `prisma/schema.prisma` | ✅ |
-| 2 | Does §2's description of the current state match the code | `lib/a.ts`, `lib/b.ts` | ❌ **must be added** |
-
-**This is the most common mistake** — "asking a question without providing the file needed to answer it". Listing it per question lets the user see at a glance what is missing. **That column is not a formality; it is currently the only thing standing between you and a missing file.**
-
-**Before writing a path into that column, confirm the answer is in that file** — grep for the symbol, or open it. Filled in from memory the column catches nothing: a plausible-looking filename passes the format check exactly as well as the right one does, and the difference only surfaces a full dispatch later. **Two spokes may end up with the same files, but say why** — an identical list is a result you can explain, not a starting point.
-
-**Any change the user makes to the count, the models, or the lenses is followed without argument.**
-
-### 3.1 Once confirmed, every prompt must contain
-
-- **The ticket contents** (step 2)
-- **The list of source-code files the spoke may read**, with an explicit prohibition on browsing any other document under `_docs/`
-
-  When trimming that list, **ask yourself question by question: "where is the answer to this one? is that file on the list?"** Matching files to the lens's name (giving the safety lens the security-related files) produces the wrong list — **the lens is the angle you look from, the list is the material you look at**. If the list does not line up with where the answers live, the spoke is physically incapable of answering correctly. **A missing file is the dispatcher's failure, not the spoke's.** **Each spoke's list is trimmed against its own questions** — do not give two lenses the same list because one list is less work to assemble; whatever only one of them needed is what goes missing.
-  **A file you did not open is not evidence that the answer is elsewhere** — if you cannot point to the file that answers a question, that question has no file behind it yet, whatever the table says.
-
-- **Put the large files last on the list** (ascending by file size). Spokes read files in list order, and every round resends everything read so far, so the earlier a file sits, the more times it is billed again — the gap can approach a factor of two. In-process dispatch has a different context mechanism and the effect may not be the same, but ordering costs nothing and has no side effects; doing it anyway cannot hurt.
-
-- **Output format**: a list of "observation + evidence (file:line, or reasoning)". **Never** conclusions or verdicts, severity ratings, "should be changed to" alternative designs, or adoption recommendations; anything uncertain is written as a question, not as a defect.
-
-### 4. Collection — summary by default, verbatim the exception
-
-The user must see each spoke's content, labeled with lens and model. **Synthesis is the default**, satisfying four required conditions:
-
-1. **Declare the trade-off explicitly** — state at the top of the section that "this is a summary, not verbatim"; never summarize silently
-2. **The reading must cover every item, skipping none** — every observation from every spoke has to appear in the "hub reading" below, which is what replaces verbatim reproduction as the source of auditability: an original not laid out in front of the user does not mean it went unread
-3. **The original is still in this conversation turn** — the sub-agent's full response stays in context, and it can be pasted back in full if the user asks
-4. **This only holds while the original can still be found** — once it has fallen out of context there is no original to check against
-
-> What this rule guards against is not "no original exists", it is **the hub cherry-picking what suits it**. Satisfy those four and a summary guards against it just as well; what has to be preserved is the purpose, not the "verbatim" mechanism itself.
-
-**Reproduce it verbatim in two situations**: the original has fallen out of context (there is no original left to check, so a summary cannot satisfy condition 4), or a single report is short enough that summarizing would be overkill. Everything else defaults to a summary.
-
-**If you cannot meet condition 2, dispatch fewer spokes rather than falling back to verbatim** — the problem is dispatch scale, not presentation; do not treat "not confident" as a reason to revert to full reproduction.
-
-Then **open a separate "hub assessment" section**: deduplicate, and annotate each item with your preliminary judgment (holds / does not hold + why / needs the user's ruling).
-
-### 5. After the user rules
-
-You revise the plan for the items that were adopted (a new version writes only the differences). **A spoke's output never becomes a document version directly.**
-
-## Three things you must verify when assessing a spoke's report
-
-**One: any claim about safety or correctness — open the file and verify it yourself before passing it on.** Do not report a spoke's claim to the user as a conclusion.
-
-**Two: a comment is not evidence.** "The spoke says a comment backs this conclusion" is not enough — you also have to verify **whether what the comment says still holds**. Comments drift away from the code, and a drifted comment reads exactly like a correct one.
-
-**Three: line numbers must be re-verified.** A spoke's citations can be off by anywhere from a few to dozens of lines while **the description of the content is usually right**: usable at the fact level, unusable at the location level.
-
-> **A wrong location is not a hallucination.** A hallucination is "that passage does not exist in that file at all", and the remedy is a rerun or a different model; a wrong location only needs you to locate it again. Mistaking the former for the latter throws away an entire usable output.
-
-**A spoke reporting "I could not read X" is a correct report, not a false alarm.** It names a file you did not put on its list, which makes it your gap and not its mistake — filing it under "false alarm", or quietly resolving it yourself and moving on, hides the one signal that tells you the list was wrong. Resolve it if you can, and still say plainly that the list was short.
-
-## Red lines
-
-- A spoke's observations **must never touch "whether to do it"**. If one produces a terminate/block style conclusion, discard that conclusion, keep only the factual part of it, and note this in your report.
-- **Never change a plan's status field on your own because of a spoke's observations.**