Project 01. The Fleet Readiness Audit

Illustrative composite. Orbital Notes, a five-person note-taking team, closed one ordinary week having run twelve agent tasks without anyone tracking what a single one of them actually cost to land. A redesign attempt got abandoned mid-build and had to be re-run narrower. A production investigation burned most of an hour and turned up nothing — the bug lived in a customer's browser, not the app. A rate-limiting change sat blocked at the end of the week, waiting on a credential nobody had requested. From the outside it looked like a normal sprint: twelve tasks, most of them merged. Nobody on the team could say what the week had cost per landed change, because nobody had priced it — that is the audit this project asks you to run, on your own week or on theirs.

You have read the case for four axes and a cost model that prices a merged change instead of an agent-hour. Now turn both on a real week, not a hypothetical one. If you keep your own agent logs, use them. If you do not — most solo operators and plenty of small teams do not, at least not yet — a full week of sample data sits below, borrowed from a fictional five-person team, so the exercise costs you a morning instead of a month of instrumentation you have not built yet. Either way you hand over the same artifact: every task from the week tagged parallel or sequential by lesson two's test, priced by lesson three's model, and a topology score on all four axes with the one axis you are actually going to move.

Your deliverable is fleet/readiness-audit.md — a costed week of your own agent usage with the topology decision it forces. It closes the Scope stage: everything module one taught about deciding whether, where and at what cost to run more than one agent lands here as a single committed page.

Brief

Reconstruct one week of agent-assisted work — your own if you have logs, the sample week below if you do not — and turn it into a costed, scored decision.

diagramsource

drawing

The four stages above are the whole project. Everything else in this brief is the raw material you need to run them.

The sample week (use this if you have no logs of your own)

Illustrative composite. The team, the repository and every number below are invented for this exercise. Use the shape; the exact figures are not evidence about a real fleet.

Orbital Notes is a five-person team shipping a note-taking web app. Over one working week they ran twelve agent tasks against one shared repository, on a Claude Pro-tier seat shared across two developers and one Max-tier seat used by a third. Two tasks were run twice after a first attempt was abandoned; both attempts stay in the log, because an abandoned run still cost tokens and time.

#	Task	Files touched	Duration	Tokens (in / out)	Outcome
1	Add a /health endpoint	1 new file	12 min	8,200 / 1,100	Merged
2	Fix a flaky date-comparison test	1 test file	34 min	41,000 / 6,400	Merged
3	Redesign the note-list layout, attempt 1	6 files	55 min	96,000 / 14,000	Abandoned — reviewer rejected, diff too broad
4	Redesign the note-list layout, attempt 2, scoped	2 files	28 min	38,000 / 5,900	Merged
5	Write the shared Note type for tasks 6 and 7	1 file	9 min	6,500 / 900	Merged
6	Build the note editor against the Note type	3 files	41 min	52,000 / 8,100	Merged
7	Build the note list against the Note type	2 files	37 min	49,000 / 7,300	Merged
8	Add tag filtering to the note list	1 file	19 min	15,000 / 2,600	Merged
9	Migrate the dev schema, add an archived column	migration + script	22 min	18,000 / 3,200	Merged
10	Investigate a production error report	0 files, read-only	48 min	61,000 / 4,000	No change — root cause was a client bug
11	Rewrite the onboarding email copy	1 file	15 min	9,800 / 3,100	Merged
12	Add rate limiting to the public API	2 files	63 min	88,000 / 11,000	Blocked — waiting on a credential nobody had provisioned

Illustrative composite. If you have no bill of your own to check against, use a stand-in rate of $3 per million input tokens and $15 per million output tokens, and say in your file that the rate is a stand-in, not a measured one.

Constraints on the exercise

• Tasks 5, 6 and 7 are a contract-first fan-out: task 5 wrote the interface, tasks 6 and 7 consumed it. Treat task 5 as a single writer and tasks 6-7 as parallel readers of a settled contract, per lesson two's rule.
• Task 3's abandoned attempt and task 4's successful retry are the same piece of work told twice. Both rows belong in the cost model; only one landed.
• Task 10 never touched a file. It still cost tokens and time, and it never becomes a landed change no matter how the week is scored.
• Task 12 is still open at the end of the week. Decide how an unresolved task enters a week-end audit before you tag it.

Name your operator profile

State, in one sentence, the constraint that binds you first: a solo builder limited by their own review bandwidth before they ever hit a budget ceiling; a small team limited by bursty demand and unclear ownership of the bill; an enterprise engineer blocked on a compliance sign-off before any fleet work starts; an open-source maintainer receiving a fleet of contributions they never assembled; a consultant who cannot let two clients' agents share one session; an ML engineer whose GPU meter is invisible to any coding subscription. Pick the closest one, or write your own — the rubric scores whether the line is honest and specific, not which profile you picked.

The Rule This Lab Tests

Use cost per landed change, never cost per attempted task or per agent-hour, to decide which axis to move next, once your week holds any task that did not cleanly merge — abandoned, blocked, or read-only. Price a week where every task landed the same way, if you ever have one; the two denominators only agree in that one case, and the sample week below is not that case.

Denominator	Safe when	What it hides
Cost per attempted task	Never, once any task is abandoned, blocked, or read-only	Spend on work that never landed disappears into the average
Cost per agent-hour	Never, for a topology decision	How busy the fleet looked, nothing about what it shipped
Cost per landed change	Any week, required once one task did not land clean	Exactly what an immature fleet's near-misses cost

Steps

Step 1 is worked — the row that trips up the tagging fastest is tagged for you below. Step 2 is faded: you decide where the still-blocked task belongs before checking your reasoning. Steps 3 through 5 are open, scored and decided entirely against your own fleet and your own profile.

1. Tag every task parallel or sequential — worked. Apply lesson two's test — disjoint files and no shared undefined interface means parallel; one task's output feeding another means sequential; a shared contract gets written once, then fanned out — to all twelve rows, or to your own week's tasks. A worked example: task 5 tags as a single writer, and tasks 6 and 7 both tag contract-first against the interface task 5 just committed, never as three separate parallel rows. Output: a tagged version of the table in fleet/readiness-audit.md.

2. Price every task, then price the week — faded. Convert each row's tokens into a cost using your runtime's published rate, or the stand-in rate above, then compute cost per landed change: total spend across every row, divided by the count of rows marked Merged. Decide for yourself where task 12's still-blocked status belongs before you check your reasoning below, then finish pricing the remaining rows, or your own week's tasks. Output: the cost table and the single cost-per-landed-change figure.

3. Score your own topology on the four axes — open. Concurrency, Isolation, Verification, Locus of control, 1 to 5 each, using lesson one's table — scored against your own fleet, not the fictional team's. Output: four scores, each with one sentence of justification.

4. Name the one axis you move next, and the row that forced it — open. Point at a specific row in the cost table: which task's cost or outcome makes the case. Output: the closing paragraph of fleet/readiness-audit.md.

5. State your operator profile — open. One sentence naming the constraint that binds you first, so the axis you chose reads correctly to a reviewer who does not share your context. Output: the profile line in fleet/readiness-audit.md.

Acceptance

• All twelve rows, or your own week's rows, are tagged parallel or sequential, with the shared-contract task marked as a single writer, not a parallel task.
• The abandoned attempt and its retry both appear in the cost table; only the retry counts as landed.
• The read-only investigation is priced but never counted as a landed change.
• The still-open task is handled explicitly, named as unresolved rather than dropped or silently counted as landed.
• Cost per landed change is total spend over merged-row count, not total spend over every row.
• All four axes are scored 1 to 5, each with a one-sentence justification.
• The file names one axis to move next and ties it to a specific row in the cost table.
• The file states which operator profile's constraint binds first.

Rubric

Criterion	Weak	Strong
Parallel/sequential tagging	Tagged by task size or a guess at independence	Tagged by lesson two's file-boundary test, with the shared-contract task called out as a single writer
Cost accounting	Every row counted equally toward cost per landed change	Abandoned and blocked rows counted as spend, excluded from the landed-change denominator
Axis scoring	Four numbers with no reasoning attached	Four numbers, each tied to a specific row or pattern in the week
Profile fit	The audit assumes one kind of reader	The file states its own operator profile, and the same scoring method still reads correctly for a solo builder and for an enterprise engineer
Decision clarity	"We should probably move to a container"	One named axis, one row of evidence, one next action

Key Takeaways

• Tag tasks by shared file and interface, not by how big they feel.
• Write a shared contract once, then fan out; never let two agents guess an interface.
• Price a week by landed changes, not by every attempt you funded.
• Count an abandoned run's cost without letting it inflate the landed total.
• Name your operator profile so your axis scores mean something to a reviewer.
• Move exactly one axis at a time, and name the row that proved it.

What You Have Now

fleet/readiness-audit.md — a costed week of your own agent usage with the topology decision it forces. It sits first in your Fleet Kit, the file every later deliverable gets checked against: the isolation launcher in lesson four exists because this audit found a collision-shaped task, and the venue in lesson nine gets chosen against the cost-per-landed-change figure this file just computed. Module two starts from the axis you named here.