Plans

Programme plans usually live in a file that one person edits, and are then redrawn for each audience. Mine lived on a whiteboard as Gantt frames rendered from a master file. That has three problems:

• Changes aren't recorded. Nothing says who changed what, or why.
• Effects can't be previewed. You can't see what a change does to the critical path before you make it.
• It's disconnected from the deliverables. The plan says a milestone is on track. The deliverables say otherwise. Nobody notices until it's late.

So I built a scheduling engine into the portal, next to Deliverable Tracking, with two front doors: conversation and a browser. The programme's current plan was built wholly through conversation with Claude, and almost nothing was edited by hand. The whiteboard version was retired seventeen days after the first spec.

01What it does

02Two front doors, one plan

The design rule underneath everything is that there is one model and one writer. Claude's edits through MCP and a person's edits in the browser go through the same code path, so neither can see a plan the other can't. Each door is suited to a different job:

• Conversation is the better way to change a plan. You describe the change, see its consequences and confirm it in one exchange.
• The browser is the better way to read one, and to decide.

Two rules keep the trust boundary clear:

• A Claude session never accepts a proposal, whoever it's working for. Only a person does, in the browser.
• Time passing never rewrites the plan by itself.

The deliverable integration follows the same principle: one home per fact.

• Forecast dates. When the plan moves, the register's forecast date for the linked milestone moves with it, and an audit entry is written.
• Target dates. The target date changes only through a proposal that someone accepts. The plan never sets a target date itself.
• Progress. A task that names its deliverables takes its progress from them, by points, with a planned curve and a "ready by" date.

To be honest, the integration is still early. Linking tasks to deliverables is planning work, not software, and it's only partly done. That's why every progress figure is shown beside a coverage figure. A plan that is 90% complete across the 12% of it that's linked shouldn't be allowed to look like good news.

03What it took to build like this

Plans was a multi-agent build:

• Specs were written on a stronger model.
• Building and review were done by separate agents on a cheaper one, each in its own worktree.
• Merging and deploying was done only by the main session.

The work ran as eighty feature passes, thirty-eight on progress tracking and seventeen on UX. Each pass was reviewed. Reviews caught an access leak, a way to bypass the confirm step, and a record shape that would have broken the database at design scale.

It didn't go smoothly:

• Late test failures. Repo-wide tests that pinned counts went red late, five in one night.
• Stacked branches. Branches built on top of each other turned every upstream fix into a cascade of rebases.
• Too many agents at once. Running eight crashed the machine.

Each of those is now a written rule.

The bill was larger than it first looked. The first measurement said 141 million tokens for three days. A proper count of the eleven days found 13.1 billion raw tokens across 62,890 API calls, 97% of them cache reads. The first figure was the final size of each agent's context, not what it cost. The working practices adopted mid-build cut the daily figure by 41%.

The bigger point is that no mainstream project tool joins deliverable readiness to schedule logic. Task trackers barely do dependencies. Scheduling tools don't know whether the things a milestone needs are actually ready. That gap is where this sits, and conversation is what makes it maintainable.