Harbour from the Bridge

Harbour is a control plane for software delivery done by AI agents, run by one person. It reads a backlog from a task tracker, turns a ticket into a grounded prompt, dispatches that prompt to an agent session, and then checks the result against evidence rather than against the agent's own report. The landing page's phrase is "keep human intent in command of AI execution, one turn of the loop at a time."

It began in early 2026 as a read-only tree viewer for Linear. What compounded since then is not the model but the doctrine: staleness checks, a review-then-close-out split with a ledger of "what CI did not prove", a credential broker so no agent ever sees a live token, an operator decision queue, a north star the human alone may edit. The repository's CLAUDE.md alone is now roughly nineteen thousand words of that residue.

Two repositories make the product. LinearViewer is Harbour itself: the web app, the API agents call, the prompt engine, the observation and KPI surfaces. simple-dispatcher is the runner on the operator's Mac that polls Harbour's queue and drives each agent session through its phases. A third piece, Harbour OS, is the operator's in-browser workstation and is out of scope here.

It is dogfooded on itself. The tracker you are reading about is Harbour's own backlog, worked almost entirely by agents Harbour dispatched. One outward run on a foreign repository (28 August) proved the machinery ports but exposed that the non-Linear agent lane had never been exercised end to end.

The instance reports 12 users across 8 workspaces, but this workspace has one human: John Kershaw, the maintainer and operator. Everyone else on the board is an agent. The charter (a draft, dated 19 July, deliberately not yet adopted) says so plainly: "one maintainer and roughly one other user".

The division of labour is the design, not an accident of headcount.

Three agent roles sit above the workers. The Autopilot orchestrator chooses and accepts, never writes code. The Flight Companion is the observer: a chat surface that watches the fleet, narrates, and proposes follow-ups a human taps to approve; it is on rung one of a three-rung trust ladder (read-only, then supervised writes, then unattended). The Passage Runner flies a ratified passage leg by leg. All three answer to the same rule the handbook states: describe how things are going, but never redraw what "done" or "worth it" means.

Harbour's planning vocabulary is nautical and its scheduling unit is not a sprint. The terms a PM needs, in the order they nest:

Every issue on the team, read this afternoon. Harbour's convention: ✓done, ◐in progress, ○not started.

Three things the shape of the backlog says

• Half the open work is residue. 324 open tickets are kind:review-residue and 195 are kind:follow-up: 519 of 1,004. Reviews and close-outs file more than they fix, and what they file mostly waits (see the studies below).
• The runner is the heaviest front. dispatcher-substrate leads with 249 open tickets, and the operating-model hub ranks finishing the Linux dispatcher host above every other phase because "the September incident set is almost entirely the Mac host".
• Priority is not steering intake. The three Urgent tickets are all in Backlog, none scheduled; 104 top-level High tickets sit in Todo. Passages, not priorities, decide what gets flown.

Harbour publishes its own operating figures on a public, unlinked /kpis page. These are instance-wide, thirty-day windows unless stated.

Velocity, read honestly

The Recent Headwinds review counts mainline commit units per active day on the Harbour repo. It refuses to give a single number, and so should you: one 52-unit lane-run day on 23 August lifts the latest window's average from below the prior baseline to well above it.

The 23 August lane run itself is the best single day on record: fifteen long-lived sessions, 52 tickets to Done, 43 PRs merged, zero faked closes, wound down deliberately at 71% of the weekly budget. The method it codified (one session carries an ordered ticket list with a file carve, without pausing) is now one of three ways work is flown, alongside per-step autopilot and per-leg passage runs.

Where the money goes

A routing proposal dated 11 September priced 1,068 worker sessions across 155 issues over nineteen days at $6,687 API-equivalent. The orchestrator tier is the single largest line; implementation is where the cheaper model already runs.

The evidence behind the routing: Sonnet implementations passed review first time in 84% of 115 cases at a quarter of Opus's median cost, and terminal failures are rare on every kind. The proposal's whole saving is effort, not model: three effort reductions (research, review, close-out) touch a third of worker spend and would save roughly 10–15% if published curves hold. Nothing has been changed yet.

Harbour measures itself. Seven papers landed between 5 and 12 September, each answering one question about the process from the tracker's own data. Read together they describe a system whose gates work but whose exhaust is piling up.

The north star, v2, is titled "the self-funding loop" and makes one economic claim with seven clauses behind it:

• Verified beats claimed: CI green, merged, ledger discharged.
• Cost per verified task, visible and falling, in the money actually spent.
• Operator minutes and sessions are the scarce resources; silent failures outrank feature work.
• Gates buy evidence, never delay.
• Finish transitions before starting capabilities; the longest blocked chain and oldest compat lane are standing priorities.
• A stranger can trust it in one sitting; the free tier is a published line item.
• Every claim reachable from its evidence; every contract legible in one screen.

The alignment reading, nine days old

The roadmap report of 2 September scores the portfolio against that text. Its verdict, condensed: the operational core (evidence integrity, bounded runs, spend attribution, silent-failure work) is aligned. The drift it names is elective interface work: UX & Theme, The Ship's Biscuit, the Ship Journey map, and Flight Companion expansion whose effect on operator minutes has not been demonstrated. Two unscorables sit underneath: "verified task" is still a proxy (the KPI counts terminal markers, not discharged ledgers, tracked as LIN-1878), and the first published forecast (LIN-1626) is unstarted while blocking six tasks.

The report ends with the question it wants the human to answer: should supervised conversational control count as a north-star outcome in itself, or only when it demonstrably reduces operator minutes and sessions per verified task? Nine days on, that question is still open, and the Flight Companion has had two passages since.

The programmes on the board

Drawn from the last Recent Headwinds review (29 August), the Drift & Coherence review (29 August), the incident file, and today's live reads. Severity is the reviews' own.

These follow from the evidence above and respect the line the project draws: a PM here decides what is worth doing and what counts as done, and leaves the how to the loop. Each is one decision, most of them John's.

1. Answer the ratification waiting on LIN-2730. One "yes" as a comment. If the week's budget is the constraint (60% used, exhausting Monday at current burn, reset Thursday 06:00 UTC), ratify the trim-safe minimum only: legs A2 and B1.
2. Answer the roadmap report's open question. Whether supervised conversational control is a north-star outcome in itself decides whether the next three Flight Companion passages are core work or drift. Deciding it once is cheaper than re-deciding it per passage.
3. Drain or retire the periodicals. Seven are due. Eight have no run in thirty days, four of them corrective (test-coverage gap, security, API quality, dependency supply chain). A weekly cadence nobody meets is a false instrument; either run the reserved maintenance leg the passage template already provides, or cut the registry to the cadence the budget can carry.
4. Start LIN-1626, the first published forecast. The alignment reading calls it the unstarted bottleneck blocking six tasks, and "every cycle forecasts the next and scores the last" is a north-star clause with no evidence behind it yet.
5. Adopt or reject the effort-routing proposal. Three effort reductions, a claimed 10–15% of worker spend, no data of its own because every stamped run so far was at the same effort. The proposal asks for a five-minute check first: confirm what effort the host actually defaults to.
6. Rule on the two expired deferrals. LIN-1661 and LIN-1873: run the follow-on-ratio read now, or extend the date with a stated reason. Either closes a ledger row that has been silently wrong for three weeks.
7. Sweep the residue pile once, by policy. 519 open tickets are review residue or follow-ups, most of them the parent's own scope filed next door. The 12 September ruling stops new ones forming; it does nothing for the pile. A single triage rule (reattach to the parent, schedule, or cancel with a reason) applied by an agent in one lane would be cheaper than letting each one age.
8. Move the three Urgent tickets out of Backlog, either into a passage or down a priority. An Urgent ticket that is not scheduled is a label, not a priority.
9. Get the Linux host over the line. The operating-model hub already ranks it above everything in its own Phase 3; the blocked child (LIN-2422) needs a human to unblock, not another session.

Method and limits

Counts by state, project, priority and label were computed from all 2,769 issues paged over the proxy today. Passage and epic detail came from the same API. Throughput, cost breakdowns and risk severities are quoted from the project's own reviews and papers at the checked-out HEAD, and each is dated in the text so you can judge its age.

What this brief could not see: the issue list carries no creation dates, so ticket ages here are the reviews' numbers, not mine; the repository checkout was shallow, so commit velocity is quoted rather than recomputed; the KPI page aggregates all eight workspaces on the host; and cost figures are API-equivalent list rates on a subscription, so the cash cost is lower and the "verified" in cost per verified task is still, by the project's own admission, a proxy.