ToppingOut02 · Order of worksOrder of works
From idea to merged job: 4 steps once per project, then 7 per ticket. Pick one.
Shape the idea
Your idea becomes clear decisions.
- Reads ←
- Your request, and the code itself.
- Writes →
- A notes file while it is rough, then a brief with every question answered.
RuleNo question left open.
Step by step
- 01.1
Bring the ideaYou
What you want built, in your words.
- 01.2
Survey itForeman
Every open question settled against the code.
Write the plan
The whole plan, before any code.
- Reads ←
- The settled decisions.
- Writes →
- The project plan.
RuleEvery decision made first.
Step by step
- 02.1
Write the blueprintForeman
One plan: decisions, acceptance checks, tasks.
Check the plan
Other AI models check the plan.
- Reads ←
- The plan, cold.
- Writes →
- One combined list of findings.
RuleIt passes before it is split.
Step by step
- 03.1
Cold read of the blueprintInspectors
One to five other AI models read it cold.
- 03.2
Settle every findingForeman
Each finding applied or answered. None left open.
Cut into tickets
The plan becomes jobs, in order.
- Reads ←
- The checked plan.
- Writes →
- The project's folder and its board.
RuleNothing written until you say go.
go · publish
at Approve the cut
Or skip the plan: an iteration board.For work found while testing a product: no blueprint, small jobs added as they turn up (f-board, init --iteration). It tops out the same way.
Step by step
- 04.1
Cut it into jobsForeman
One ticket per job, one PR each. Shown to you first.
- 04.2
Approve the cutYou
Two words: one to write it, one to publish the board.
Your word“go · publish” - 04.3
Board v1Foreman
The board page you follow. The first job is marked next.
Start the shift
A fresh foreman reads the notes, then the code.
- Reads ←
- The opener, the handover, the Logbook and the firm rules.
- Writes →
- The cards in force, listed in its first reply.
RuleWhere they disagree, the code wins.
go
at Say go
Step by step
- 05.1
Open a fresh sessionYou
Paste the opener the last job left.
- 05.2
Stand up as foremanForeman
Loads the rules, the playbook and this job's lessons.
- 05.3
Site walkForeman
Quiz answered cold, machine and ticket checked. Then stop.
- 05.4
Pre-flightBuilder
The builder proves its tools work: ready or blocked.
- 05.5
Say goYou
Choosing the ticket is not saying go.
Your word“go” - 05.6
Mark it startedForeman
In progress on the board.
Build
One small task at a time, test first.
- Reads ←
- The foreman's work orders.
- Writes →
- Code and tests, one commit per task.
RuleA test that breaks stops the work.
Repeat per task.Each task gets its own work order, build and review, until every task is built. Repairs go test-first into the next work order.
Step by step
- 06.1
Work order 1: setup and t0Builder
Worktree, job record, a baseline of every check. No code.
- 06.2
ScopingForeman
Every design fork settled, with what was rejected.
- 06.3
The plan and gate 1Foreman
Tasks and tests that must fail first, then a cold read.
- 06.4
Write the work orderForeman
One outcome, exact commands, a pinned commit.
- 06.5
Pass the pointerYou
One line to the builder, by hand or over the pane link.
- 06.6
Build itBuilder
Failing tests first, then code. One commit, a report, stop.
- 06.7
Review itForeman
Disk before words. The foreman probes it itself.
Inspect
Two reviews: a fresh AI session, then an AI from another company.
- Reads ←
- The changes, and a brief with every model name taken out.
- Writes →
- Findings, never fixes. Accepted fixes go back to the builder as a work order.
RuleBoth run, always.
Step by step
- 07.1
Base versus headBuilder
Every affected test, before and after. Red only after: stop.
- 07.2
Gate 2Foreman
Every commit against its review, and the safety fact.
- 07.3
Lens inspectionForeman
Fresh reviewers, findings only. No PR yet.
- 07.4
Check every findingForeman
Each one reproduced. Only accepted ones go back.
- 07.5
Fix what was acceptedBuilder
Test-first repairs, reviewed like any other.
- 07.6
Pack the reviewForeman
One blind brief. Nothing names the builder.
- 07.7
Cross-model reviewInspectors
Another company's model reviews it cold.
- 07.8
AdjudicateForeman
Every claim reproduced. Accepted fixes become work orders.
- 07.9
Final re-run and the ledgerForeman
Everything again at the final commit. Every requirement passes, or no PR.
Open the PR
The work goes up as a pull request.
- Reads ←
- The final changes and test runs.
- Writes →
- The pull request.
RuleOnly on your word, or your /goal.
open the PR
at Open the PR
Step by step
- 08.1
PR bodyForeman
What changed, the proof, the limits, the review record.
- 08.2
Open the PRYou
Pushed and opened. Opening is not merging.
Your word“open the PR”
Review the PR
Greptile reviews it; findings get fixed.
- Reads ←
- The review's findings.
- Writes →
- Fix commits, pushed with your word or your /goal.
RuleThree rounds at most.
greploop
at Greptile rounds
Step by step
- 09.1
Greptile roundsForeman
Scored out of 5, findings fixed. Three rounds at most.
Your word“greploop” - 09.2
PR description checkForeman
Re-read against the final code before you are asked to merge.
Merge
Merged, then checked against what was reviewed.
- Reads ←
- The reviewed branch.
- Writes →
- The merge.
RuleOnly on your word, or your /goal.
merge
at Mergetracker transition
at Clean up
Step by step
- 10.1
MergeYou
Then checked: what landed is what was reviewed.
Your word“merge” - 10.2
Clean upForeman
Branch and worktrees removed. The tracker waits for your word.
Your word“tracker transition”
Close
Every requirement checked, notes left for the next job.
- Reads ←
- The acceptance ledger and the job file.
- Writes →
- Logbook cards, the board close, the handover and the next opener.
RuleNothing left for later.
yes
at Confirm the next job
Back to 05 with the next job.Until every job on the list is merged or decided. On a night shift, the next job starts by itself. When the last job closes, the board tops out instead: frozen as the record, a report, and three to five next heads for you to pick from.
Step by step
- 11.1
Close the jobForeman
Only when merged and every requirement passed.
- 11.2
Dev reportForeman
The day's lesson and the foreman's scorecard.
- 11.3
Next-ticket decisionForeman
The foreman recommends the next job from the board.
- 11.4
Confirm the next jobYou
Say yes, or pick another. Under a /goal it decides.
Your word“yes” - 11.5
Ground investigationForeman
Four research agents look into the next job.
- 11.6
Board closeForeman
Merged, and the next job named. One new version.
- 11.7
Shift handover and openerForeman
Notes, a quiz and the next opener, ready to paste.
- 11.8
Top out (when the head is reached)Foreman
Every job done: the board is frozen as the record, with a report and three to five next heads.
- 11.9
Push the recordsForeman
The records pushed. The job ends.
Words used
- Ticket
- One piece of work from the plan. One job builds one ticket.
- Blueprint
- The full plan for a project, written before any code.
- Work order
- A short, exact instruction the foreman writes for the builder: one task, the commands to run, the code it starts from.
- Worktree
- A separate working copy of the repo, so a job's changes never touch your main copy until they are merged.
- VP
- A verification point: something that must be true when the work is done, with the way to check it.
- t0
- The test results captured before any change, so every later result can be compared with them.
- Base versus head
- Running the tests on the code before the job (base) and after it (head), to see exactly what the job changed.
- Gate 1, gate 2
- Check points the job must pass: gate 1 checks the job's plan, gate 2 the finished build.
- Cold read
- A review by someone who did not see the work being made, so it shares none of its assumptions.
- Model family
- AI models from one company. A reviewer from another family has different blind spots.
- Pull request (PR)
- A request to merge the job's branch, where the change is reviewed before it lands.
- Greptile
- An automated pull-request reviewer. It reviews each pull request, up to three rounds.
- Acceptance ledger
- Every requirement with its check and its result. Every row must pass before the job closes.
- Opener, handover
- What one session leaves the next: a short opener to paste, and the notes on where the job ended.
- D- decisions
- Design decisions in the plan, labelled D- and a letter, each settled down to the exact detail before a work order uses it.
- H1 to Hn
- The hostile inputs a work order lists for its task, such as missing keys or wrong types. Each one needs a test.
- G1 to G6
- The standard gap checklist in every work order: cancellation, deadlines, fields reaching their destination, every error path tested, many-item cases, typed errors for bad input.
- HEAD
- The latest commit on a branch. A work order names the exact one it starts from.