Who does what

1. 01
   Run the site walk honestly: answer cold, then open the key; re-answer misses

   Whythe score tells you where your picture of the system is wrong before it becomes a wrong plan
2. 02
   Measure, don't trust the shift handover. Your command wins; say so when it disagrees

   Whyshift handovers go stale within hours; a count in one was already wrong when the session opened
3. 03
   Read the live ticket and every linked ticket's scope line

   Whythe fact that decided one job's scope was in another ticket's boundary line
4. 04
   Check the repository before the board

   Whya ticket can look unblocked on the board while its description names prerequisites with no commits yet

1. 01
   Settle every fork yourself, with evidence and rejects (SCOPING.md §4)

   Whythe builder gets decisions, never questions; a rejected option recorded now isn't re-proposed later
2. 02
   Measure every name you introduce (0/0/0 in three grep forms)

   Whyone noun per concept; in one project every noun a ticket proposed was already taken
3. 03
   Find the hard points first: where a wrong plan ships a real defect, especially security (credentials, the verified user, data leaving the service)

   Whythe misses that matter most at plan level are exactly this kind
4. 04
   Have your own plan cold-read with /f-plancheck (optionally simplicity-critic) before work order 2. One read; judge findings against your locked decisions; record each fate; no second read unless the owner says so

   Whyin Topping Out, no builder plan exists for gate 1 to catch your mistakes
5. 05
   Write down what must NOT change (defaults, other services' files, schema)

   Whythe builder can't know a default is off-limits unless the work order says so
6. 06
   For an audition: fence the hint-bearing files

   Whythe shift handover and linked-ticket notes state the answers; move them aside or list the only readable files

Before sending, check every work order against this list:

1. 01
   "Done when" sits right under the opening line: the finish line the builder can check itself against (the tests that pass at head, one commit, the report written).
2. 02
   One outcome. One independently verifiable outcome; it may carry the several D- decisions that outcome needs. Two outcomes: split it.
3. 03
   Every decision labelled D-… and final, down to the exact expression or data shape.
4. 04
   Every command exact, with the prefix line of variables; NEW and SUITE defined once.
5. 05
   The state check pins the worktree, branch and exact HEAD sha (re-pinned after the previous work order's review).
6. 06
   Tests that must fail at the current head, named; for existing code, "break it, see it fail, restore it".
7. 07
   The hostile-input checklist H1–Hn, specific to this task, plus the coverage gate, probes per task, G1–G6 and "untested paths".
8. 08
   The existing tests of every touched module run before the commit, with the adapter's literal ran_ok + failed_ids diff (templates/TEST-ADAPTERS.md).
9. 09
   Every test case you specify can actually exist. Check it against the code before sending.

   Real missa "600-byte title" case for a field with no length limit
10. 10
    The reading fence lists only what the builder may open.
11. 11
    Every anchor a probe uses stays unique after this work order's edits, checked with grep.

    Real missa decision duplicated the literal a probe anchored on
12. 12
    Every assertion about logs, callbacks or library behaviour was probed in scratch first.

    Real missa library logs a callback error before re-raising it, so the planned log assertion couldn't hold
13. 13
    Page work: click the change in a real browser yourself before the owner sees it. A string test doesn't prove page JavaScript.
14. 14
    Character or prompt text: quote the owner's intent in words ("never invent the save's world"), not a list of forbidden nouns.
15. 15
    One report file, numbered sections, STOP. It opens with "Needs from the foreman" (none, or BLOCKED on X) and has a "Not confirmed" section: anything the builder couldn't confirm, with where it looked.
16. 16
    Read it once for contradictions: numbers, dates, names, SHAs, paths and line ranges agree everywhere in the work order.
17. 17
    The payload line range is computed from the banners, and you hand over a one-line pointer, never text in chat.
18. 18
    No builder name anywhere.

Pipelining: draft the next one or two work orders while the current one runs. Each still opens with its own state check, so a stale draft stops on its first step. Revise drafts after every review.

In this order, every time:

1. 01
   Disk first: commits (count, subjects, files, no trailer, not pushed), capture folders (.exit count, ALL DONE), any shared state restored (database roles, fixtures), the job file. Only then the report, starting with its "Needs from the foreman" line and its "Not confirmed" section.
2. 02
   Verify the test-first claim yourself: run the new tests against the previous commit's code (the repo profile's old-code method, templates/TEST-ADAPTERS.md). They must fail there and pass at head (except the work order's named "tests that cannot fail first", which a mutation probe pins instead).
3. 03
   Probe the new code yourself with hostile inputs: a scratch script, reproduced output pasted into the review.
4. 04
   Attribute every difference from the last capture (a real case: two "environment-dependent" skips turned out to be caused by the new test module).
5. 05
   Security code gets a paragraph of its own: what's checked, in what order, what's raised after its except block, and anything not frozen, with why it is or isn't exploitable.
6. 06
   Every finding reproduced before it goes into the next work order, test-first.
7. 07
   The switch-rule line: triggered or not, with evidence.
8. 08
   Update the job file (tasks done, plan in force, review links).

Keep your probes out of the product tree. A probe run from the wrong folder once made the package manager create a stray environment folder inside the worktree. Run from scratch space, and check git status --ignored after.

Know it stopped. Hand-carried: the owner tells you. Pane link: your background stop watcher wakes you (skills/orca-pi-connect, the loop step), armed after every send; if it isn't armed, you won't see the stop. Then check the disk first (commits, captures, git status, the report file) and only then read the report. A good stop looks like this: the builder hit an intermittent gate failure the work order didn't cover, stopped, and left its repairs uncommitted.

A stop is a gift, not a failure. Read it as possibly your mistake first:

1. 01
   A red-at-head test: characterise it (identical to base? isolated N/N on both sides? green in every earlier capture?), never retry it to green.
2. 02
   A stop that exposes an impossible test case you wrote: fix the work order (<m>b), keep the builder's work, and record your error.
3. 03
   A GREEN probe: it's a missing test, not a bad probe. Find the input only the guard refuses, reproduce it, add the test.

Only when the owner says "you take over". Nothing relaxes for you:

1. 01
   Run the existing tests of every touched module before the commit. This is the rule a foreman broke by committing first, which turned four existing proofs red. Writing a rule down doesn't exempt its author.
2. 02
   A fix must keep what callers need. One leak fix dropped the typed error code its callers acted on.
3. 03
   You can't sign off your own repair, except a fix the reviewer specified, implemented as specified, and proven in both states. Not for security or concurrency repairs: every one, whoever built it, goes back to the same reviewer with the changed-since-review diff and the final SHA, for an acknowledgment before merge (templates/ADJUDICATION.md). Anything else goes to the next independent round.
4. 04
   Treat warnings as errors where a warning could echo input: a validation library once repeated the caller's bad value inside a warning.

1. 01
   Base-vs-head twice: once by the builder, once by you at gate 2, and both again at the final head after the last fix.
2. 02
   Adjudicate every review claim by reproducing it first. "Ship with follow-ups" becomes: fixed now, or rejected with a reason. No follow-ups.
3. 03
   You run the lens inspection (/f-inspect) yourself, in your session, with fresh lens agents; the builder never reviews its own branch. You check each finding and decide what the builder fixes. It isn't independent of you (QUICK skips it). The independent round is the cross-model one: you pack it (/pack-review, templates/PACK-REVIEW.md) and check the brief before it goes out, a fresh session of another family runs /xreview, you run /adjudicate.
4. 04
   Scan the PR body for builder names before anyone opens it.
5. 05
   Greptile rounds, when the repo profile has it (/f-greploop, on the owner's "greploop"): at most three, each adjudicated, repaired by the builder, and re-run (tests, both base-vs-head, ledger) before the push; then stop for the owner.
6. 06
   The PR description check, every job: before asking for "merge", re-read the body against the final diff and results, and rewrite anything stale.

1. 01
   Decide on evidence and record what you rejected. No menus of options

   Whythe owner can't arbitrate technical choices, and shouldn't have to
2. 02
   Ask only for the acts listed in RULES.md (merge, any push, tracker, messages, deletions, out-of-scope edits, migrations, the "greploop" grant; the records push needs your word too, except the one after a verified merge, which the foreman makes itself). The job's own cleanup after a verified merge is not on that list: do it, then stop at the next-ticket discussion

   Whyeverything else is yours to decide
3. 03
   Report exactly what happened, including your own mistakes

   Whya foreman once told the owner "nothing was pushed" when the push had completed. Check the remote before you claim anything about it
4. 04
   A directional "yes" approves the goal, not the act

   Whyask again for each act that needs your word
5. 05
   The owner confirms the next job before the handover

   Whythe foreman recommends, the owner says yes or picks another, then the ground investigation, the board and the handover; under a /goal the foreman decides itself and records the goal
6. 06
   At the board's head, top out; never pick the next head

   Whyevery job merged or resolved: close the last job, topout, the topping out report, the candidate next heads, and stop. With jobs left, only the owner's own words top out. The next head is always the owner's pick (METHOD.md §11b)
7. 07
   Every job starts with work order 1

   Whyan audit or research job too: no job file, no later work order, inspection or PR
8. 08
   Every build job merges, code or not

   Whydocuments and research go through the PR too; /f-signoff refuses an unmerged job, and nothing new starts until the end-game lock clears
9. 09
   A standing goal is not a word

   Whyan autonomous goal ends at "ready for your word"; while waiting on the owner, say so once and stop
10. 10
    Except an autonomous run

    Whythe owner's own /goal autonomous run: <path to the opener> (or a night shift the owner started) covers the "go", the survey (its starred picks), the PR, greploop, the walkthrough (METHOD.md §10, within its spend cap), the merge and the records pushes for that job only; any failure stops it (RULES.md)
11. 11
    Explain plainly before any word. When something truly needs the owner, one plain paragraph on why, before the word itself. Better still, don't need them: post-merge cleanup and guard blocks are the agents'

    Whytwice in one job the owner had to ask why something needed them
12. 12
    Settled stays settled. Once a question is answered, by you on evidence or by the owner, treat it as done. Reopen it only on new evidence, and name the evidence

    Whylong sessions and compaction tempt re-deciding, and the owner shouldn't be asked twice
13. 13
    End every reply with the 5-line status block, state measured, owed complete

    Whyit's how the owner (and a compacted you) finds the place
14. 14
    When the owner writes a new pre-flight request or switch signal, say it plainly

    Whya switch to a new builder once went unnoticed because its only signal was a new pre-flight file

1. 01
   Count carriage returns with tr -cd '\r' < f | wc -c, not grep -c $'\r' (that miscounts).
2. 02
   Write quote-heavy text with a file tool, not a shell heredoc (heredocs break on it, repeatedly).
3. 03
   git rev-parse one ref per call. Not because Git needs it (two refs work), but so each expected value is unambiguous in the work order and the report.
4. 04
   Edit a published page from a fresh read of its URL, and strip the platform skeleton before republishing. When editing one part of a page, cut at that part's own closing line, or the previous job's content stays behind.
5. 05
   Every paid-key strip (env -u …) comes before every VAR=value, or the run exits 127 and runs nothing.
6. 06
   Never hand-roll a wait loop. A home-made Greptile poll once summed counts with bc, which Git Bash doesn't have, so every read said 0. Use the bundled waiters; a failed read is an error, never "nothing yet" (RULES.md rule 12).
7. 07
   On Windows, read SETUP.md "Windows notes" before the first job: line endings, ref:path arguments and headless screenshots each cost a turn the first time.

After each job, grade yourself as honestly as you grade the builder:

1. 01
   How many of your work orders needed a <m>b correction because of your error?

   Aim for0
2. 02
   How many real bugs got past your reviews to the independent inspection?

   Aim for0
3. 03
   Did you break the "existing tests before commit" rule?

   Aim fornever
4. 04
   Did you claim anything you hadn't checked on disk?

   Aim fornever
5. 05
   Work orders for the ticket, against your estimate at planning

   Aim forwithin your estimate

Record it in the dev report's learnings. The trend matters more than the number.

1. 01
   Run a pre-flight first. It checks the builder's environment is ready: shell, git on the target repo, reading and writing outside the project folder, tools, permissions. Nothing starts until it says READY.
2. 02
   Tell the foreman up front which builder it is, so it adapts every work order from work order 1 (BUILDER-PROFILES.md says what each kind needs spelled out).
3. 03
   Keep audition points out of reach. If you test the builder's planning, the foreman keeps hint-bearing notes (the shift handover, linked-ticket notes) out of the files the work order lets the builder read.

1. 01
   Decisions, never questions. The work order says what to build and how, not "decide X"

   Whyjudgment is a light builder's weak spot
2. 02
   One job per work order. Split any step carrying more than one decision

   Whyless for it to reason about
3. 03
   Exact commands, exact paths, a prefix line of variables on every command

   Whymany builders' shells don't keep variables between calls, and none should guess
4. 04
   Test-first. The foreman names the tests that must FAIL at the current head; the builder makes them pass

   Whyturns "think of edge cases" into "make these red tests green"
5. 05
   The hostile-input checklist (below) in every work order that writes or changes code

   Whyon one job, every bug found in the first task came from this area
6. 06
   "Done when: …" right under the opening line names the finish line: the tests that pass at head, one commit, the report written

   Whythe builder can check itself against it before it stops
7. 07
   Opens with a state check, ends with one report file and STOP

   Whysurvives a stopped or compacted session
8. 08
   The report opens with "Needs from the foreman": none, or BLOCKED on X

   Whya stop that needs a decision isn't buried under a success summary
9. 09
   "Report only what you observed. Do not explain differences away."

   Whya builder once called two new skipped tests "environment-dependent" when its own new test module caused them
10. 10
    Evidence on every claim. Every claim in the report cites its evidence: the command run and its output, the commit hash, the test name. A claim without evidence is treated as not done

    Whyagents often say they've finished when they haven't; it's the most common failure
11. 11
    A "Not confirmed" section. Anything the builder couldn't confirm goes there, with where it looked

    Why"where I looked" makes an excuse checkable

Make test breadth mechanical

A light builder's weakest areas are test breadth and judgment: on one job, four of fourteen work orders only repaired gaps found in review. These four steps turn "think of every edge case" into lists that must be empty:

Target: roughly 8–9 work orders for a mid-sized ticket, not 14.

What won't help: asking a light builder to plan more, or to review itself more deeply. Keep the thinking with the foreman and make every check mechanical.

The hostile-input checklist

Put this in the work order, word for word if needed:

1. 01
   A required key missing → a typed "unreadable" error, never a default and never a different error.
2. 02
   The wrong type in any field → the same.
3. 03
   Control characters in labels or names → refused at the edge, with the same rule the store uses.
4. 04
   Data that skipped validation on the way in (in Python, objects built with model_construct) → revalidate at the boundary, nested parts included.
5. 05
   An error raised while handling another can carry the first one's payload with it (in Python, __context__, prompt text included) → record a flag, raise after the handler, and check nothing is chained.
6. 06
   Hash or sign only validated data.

1. 01
   Don't copy prompts out of the chat window. It wraps long lines and breaks paths.
2. 02
   Give the builder a one-line pointer instead:

1. 03
   Ask the foreman for pointers, not full text in chat. Over a pane link, the foreman sends the pointer itself.

1. 01
   Tell the foreman "work order N done" (over a pane link, its watcher sees the stop).
2. 02
   It checks the disk first (commits, captures, report file), then reads the report, starting with its "Needs from the foreman" line.
3. 03
   It probes the new code itself and writes the findings into the next work order, test-first.

Switch to a stronger builder (BUILDER-PROFILES.md) only if a task review finds:

1. 01
   a security-class bug: credentials, leaked data, trusting unverified input; or
2. 02
   a repeat of something the work order already warned about.

Ordinary edge-case findings are normal. They get fixed in the next work order.

Every work order is self-contained, so a switch costs nothing: the new builder runs the pre-flight, then picks up at the next work order.

Don't miss the switch signal. When the foreman writes a new pre-flight (for example ...BUILDER-B-PREFLIGHT.txt), that is it asking you to change builder. On one job that was missed, and the old builder ran it.

1. 01
   Good: tasks with a settled design, clear tests and narrow files: repairs, adapters, readers, test suites, mechanical wiring.
2. 02
   Keep an eye on: anything touching identity, credentials, auth, or data that leaves the service.
3. 03
   Not the builder's job: scoping, planning, choosing between designs, deciding what a ticket owns.