What only a founder can unblock

Portfolio architecture phases · measured 2026-10-14 by the dock driver · four items added later that day

Of the 53 open jobs in this dock's scope, 46 are waiting on Fede or Gera — not on anyone writing code. Seven showed no such marker, and at least three of those seven are blocked by something else my scan cannot see. So the number of jobs an engineer could pick up right now is four or fewer.

How much to trust this. It is a text match over each job's record and its newest attached change, not a hand census. It over-counts a job that merely mentions a founder in its history, and it under-counts one that is blocked without using those words — I checked five by hand and the scan missed a blocked one. Treat the direction as solid and the exact figure as approximate. If it is wrong, it is low. It also goes stale by itself: true of 2026-10-14 and no other day, so a line here may already be done.

The smallest one unblocks a whole lane

Cancelling four test appointments lets voice work move again. Not code, not a migration. Until they go, every change to what Clara says on the phone is blocked from its required proof step. bug-voice-fastlane-harness-and-e2e-test-runs-book-real-tours-and-never-clean-them-up

The chain, and what I checked myself

Shortest first. Our own rule is that any change to a voice prompt must run the fast lane twice before the pull request exists — once to reproduce the bug, once to prove the fix. The job that owns the leftover test appointments says in its own words that “the freeze bans fastlane runs until this lands”. So nobody can take a voice-prompt change through its mandatory proof while those appointments sit there. The code half is already merged; what remains is a human cancelling them.

What I verified, and what I did not. I checked both halves of the chain in the primary sources: the twice-before-the-PR rule, and the freeze sentence on the job’s own record. I did not verify how many appointments are open or where — that is live production data an unattended agent must not read, so the count of four, the test building and the dates are as the job records them, not as I measured them.

It blocks a second job behind it: a tour-window fix whose own completion terms require that same fast-lane pair. A coordinator listed that one as ready to pick up today. It is not — an engineer sent at it would write the fix, reach the mandatory step, and stop.

Found by the driver of the found-rows dock, which owns that job; verified and placed here because this page is where a founder meets this kind of thing, and because four cancellations buying back an entire lane is the best ratio on the page.

Read this one first — it needs an owner today

On a phone call, our own AI can tell the server which conversation it is working on, and the server believes it over its own record. The place it ends up has no check that the caller belongs to that company, and it writes to the conversation.

What is actually proven, by reading the code rather than inferring it. When the AI calls a tool mid-call, the server works out which conversation that is by looking first at what the AI said, and only then at what the server itself stamped when the call started. For this particular tool there is also no validation of what the AI passed, because the tool was never registered on the list that gets validated — nineteen others are. The handler it reaches never asks whether the person on the phone belongs to the company that owns that conversation; it works that out from the conversation it just opened, which tells you whose it is, not whether you were allowed to open it. And it writes.

How this realistically goes wrong, stated honestly. Not a stranger on the internet — the request has to come from our voice provider with our own secret. The real route is a resident or prospect on a live call talking Clara into it. The reach is limited to other companies' phone conversations.

What nobody has established, and I am not going to guess it. Whether another company's conversation would actually be shown to a property manager on that path was never traced. I am not calling that a leak and I am not calling it safe. The reviewers' ruling says it can be settled by more code reading, with no access to live data — so it does not have to wait for you. What does need you is whether this has ever actually happened, because that means reading production.

Why it is on your page instead of being fixed. Two independent reviewers were asked, and the answer was: file it, escalate it, build nothing. An unattended session must not design a fence for a live phone-call path that writes. It is also already written down in our own attack analysis, which named this exact thing and said the design's clean-up list forgot the file — and no job on the board owned it until now. The ruling is explicit that this should not turn into an open-ended wait for proof it was exploited: the owner comes first, the history second. bug-a-mid-call-voice-tool-takes-its-conversation-identity-from-a-model-controlled-argument…

Eight more, added later the same day

These came up after the figures above were measured, so they are not counted in them. Two of the eight are a single action each, one is a question rather than a task, one has a clock on it, one is the only thing standing between a finished feature and a closed job, and the last one is switched off and nobody noticed.

Type @claude review as a comment on pull request #19611. That is the whole action. The change deletes three sentences from one of our automatic checks that claim something is impossible which we made possible two weeks ago — including a sentence the check shows to whoever opens the pull request. It is finished and every test passes. Nothing in the fleet can do this one for you: the workflow that answers that comment requires a human author, and says so in its own words — "only humans do". A robot already tried and nothing happened. There is also a way to make the check pass by exemption, with nobody reading the change; a reviewer asked whether to use it and the answer was no, so it waits for you instead.
Merge local-bin #553 — in that repo, removing its hold label is the merge. It adds one command that tells a dock driver which of its jobs belong to a different driver, which is the thing that currently makes a driver accountable for work it is not allowed to touch. It is reviewed, green, and proven to change nothing else: the same captured input through both versions of the tool, across seven existing command shapes, zero differences. My own permission layer refused to drop the label, so I stopped rather than route around it.
The names import, on the live company — seven owner names from the property system, the street lookup (about two paid lookups), and your eye on the result. All the code for it is merged; what is left is the one run nobody but you may make, because it writes to production and costs money. I have marked that job as waiting on you rather than leaving it looking unowned, so nobody is sent at it by mistake.
How many buildings have no company recorded against them — a read-only count, but it needs somebody present while it runs. It is blocking a decision rather than a build: when a building has no company on file, one safety check that stands between a draft and every resident of that building currently logs a warning and carries on, reading staff permissions with no company to compare against. Whether that should refuse instead is a customer-visible change, and the code says so itself. The decision cannot honestly be made without the count, so I did not ask anyone to guess it.
63 test files are calling the live database every night, and we already know all 63 by name. A nightly sweep checks 9,190 test files one at a time and lists the ones that reach production data. It has reported failure every night for at least the last six, and its findings go into a single ticket — open since 5 October, updated every night, with not one comment on it. One of the 63 was a safety test we fixed today, and we found it by accident because a change happened to touch that file; the sweep had been naming it by path for nine days. This is not broken tooling and not drift. You approved the nightly, report-only sweep on 2 October, and it is doing exactly what was asked — it looks, it finds, it writes the list down, and it gates nothing. So the question is not where the report should go. It is: that is where you said it should go, this is what happened, do you want it to change? The trade is real — making it fail something spends attention on 63 existing items, and closing the gap at change-time instead would mean running a 110-minute sweep on every single change. bug-a-gauntlet-unit-test-calls-real-dynamodb…
One of our working sessions is heading for a wall it cannot avoid on its own, and this one has a clock on it. Sessions clear their own memory automatically when they fill up. This one cannot: the mechanism that does it refuses to type into its terminal window, because that window is labelled as belonging to a different session — one that has never run on this machine at all. The refusal is correct; typing into someone else's window would be worse. But the label is wrong and is trusted absolutely, so nothing can get through. Measured: it has failed every few minutes for over four hours, and the session's memory has climbed 81% → 83% → 84% → 86% while I watched. It is alive and working right now. When it fills, it stops, and whatever it was holding is gone. Why it needs you: the fix is a one-line-ish change in the tooling we merge by hand, so no agent can land it. The job that documents it is owned by another board and is pinned to the exact producing line, so the diagnosis is done — what is missing is somebody landing it. I did not try to re-label the window myself: guessing at another session's identity is how you type into the wrong one. bug-hosting-tmux-trusts-an-unstamped-hosts-stale-birth-session-id…
Sign in to the staging site as an administrator, once, so a finished feature can be proven and closed. The company switcher — one person, two companies, pick one and see that company's data — is built and merged. The test that proves it exists and matches what was asked of it point for point. It does not count, for one reason: it ran thirty-six minutes before the change it was meant to prove. So what it actually proved was the old behaviour, and nobody noticed until I read the timestamps. Re-running it needs a login on the staging site that only you can create, and somebody present while it runs, which is why no agent has done it. One thing to add while you are there, and it matters more than the re-run: the test deliberately throws away the saved pick to prove the server remembers it, and it never signs a second person in on the same browser. That means it reads clean over the exact bug we found beside it — one person's company pick outliving their session and scoping the next person at that browser. Half of that is already fixed; the half where a session simply expires is not. If the re-run passes without a second person signing in, we will have a green board over a live defect. ui-s-b
Switch one of our own robots back on — while it is off, nothing can approve a change to the build system, including by you. When a change touches one of the files that run our builds, the automatic reviewer deliberately stands aside and prints the way to ask for a review by hand: leave a comment saying @claude review. The robot that answers that comment has been switched off — not broken, switched off, by a person, at some point we have not identified. So the printed instruction does nothing, for anyone: a robot that tries it gets silence, and so would you. Measured: nothing in the whole repository has responded to a comment like that since 30 September — two weeks. One finished change is sitting green on every other check with this as its only blocker, and there is no sanctioned way for us to clear it. Why it needs you: turning a disabled robot back on is a deliberate act and somebody disabled it deliberately, so the honest question is not "fix it" but did you mean to turn this off, and do you want it back? If the answer is no, then the instruction it prints should stop promising a cure that does not exist — which is a change we can make, once we know. I did not look for a back door around it; the one that exists would mark the change approved with nobody having read it. bug-a-workflows-audit-trail-argument-rests-on-two-branch-protections…

What moved since the figures above, and what I deliberately did not restate. Open jobs in this dock's scope went from 53 to 68 — the same count on the same board, so that one is comparable. It went up because I keep filing jobs as I find real defects, which is intended: the finish line moves. I did not re-state the "46 of 53" above, because when I re-ran a scan for it my pattern was broader than the original and returned 66 of 68. That is a different instrument answering a slightly different question, not two weeks of progress or regress, and quoting it beside the first number would have invented a trend. The 46 stands as measured at 11:36 and nothing since.

What the 46 are waiting for

A job can need more than one of these, so the rows overlap and do not sum to 46.

Jobs	What only a founder can do
31	A production change — a backfill, a re-key run, an archive, a deletion. Irreversible, and nobody else may run one.
28	A decision or an answer still owed — several already drafted and waiting for a slot.
16	A read-only production measurement that needs somebody present while it runs.
9	Turning something on at a real property.
6	Removing a stuck label by hand on a finished change.

The biggest single pile: production changes

These are the ones no agent may run unattended, approval or not. A sample, each quoted from the job's own record:

The phone-address backfill — "a fresh read-only dry run + scoped preflight, then a founder's per-step yes on the exact apply (write-once heads, no undo)" p3-backfill
The conversation re-key — "the re-key run and archiving the old anchor are a founder's act against production data" p6-rekey-run, p6-conv-org, p9-conv-index
The vendor identity backfill — "a human runs it with apply mode; the script refuses an agent by design" p8-identity, p8-vendor-identity-cutover
Filling the new phone-config fields on the real rows v6-config-dumps
The lease repair — 36 leases with no person attached, in production p10-core-data
Merging vendor cards that already share a phone number p8-directory

The flips — one at a time, each followed by a quiet reading

A whole chain of jobs is queued behind a sequence only a founder performs: "a mailbox address flips first, then each customer phone line one at a time, Camellia last, each flip followed by the bake reading zero." Until the first mailbox flips, p5-mail-lane cannot close at all — its own record says so. p5-flip, p5-mail-lane, p5-config-dumps

Switches waiting to be turned on

The cross-company roster gate, currently refusing on two test buildings only — "a human must flip it from off to refuse for every building" p1-roster-refuse
Dispatch roster-walk at a real company — "without which the three parked readers cannot move" p8-roster
Texting on the Western Slope line — see the note below; the rule as written can never be satisfied p5-texting-gate-arithmetic…
Deleting the retired Western Slope prototype voice agent, and one customer-shaped call v0-970-onto-shared

Decisions drafted and waiting

Who may close a duplicate calendar-credential set. Asked, and the two reviewer passes disagreed with only the option order changed — so it was escalated rather than guessed. Nothing is waiting on it today: production holds zero duplicates, so the answer governs future ones. p3-cred-ci9
Who the invoice is addressed to, and what a building with no units costs. p7-billing-counterparty
What a caller hears about a building we do not manage. The engineering is specified and has been for weeks — what is recognised, which surface answers, and where the caller is sent are all written in the design record. What is not settled is the sentence itself. Both reviewer passes agreed on an answer and it was escalated anyway, because the question turns on a commitment made to a person: if we name somewhere to send them, we have to be able to keep it. Receipt f1cede87b. Three changes have now merged carrying this clause forward as the single word “Remains”. bug-the-building-import-trusts-the-browser-picker…, p6-ff-import-classifier
Two stuck labels on finished, green changes — one click each. A machine applied them and no code exists that can take them off. bug-704, p9-hold

Pick one of two readings — and one of them costs nothing

One job on this board is waiting for a test phone call that needs somebody present to set up and grade. It may not need to exist at all.

When the parent job was closed, the reviewer was asked what to do with one leftover clause. It gave two answers, and the only difference between them was the order the choices were listed in: “close it and file a separate job for the leftover”, or “close it and reword the clause to the thing we already proved”. Its own note says an answer that flips when you reorder the options is not a judgement, it is position bias — so it handed the choice to a person. Nobody ever answered. The separate job was filed on the first reading.

So: under the first reading, somebody sits down and makes a test call. Under the second, we reword one sentence and delete the job. One of those is free. You have never been asked which, and until you are, the job sits there looking like work.

This is not a re-ask of anything you have already decided — the question was escalated to a person in September and never reached you. Verified against the decision record by the phase-rows driver, 2026-10-14. p6-leasing-lookup-fallback-live-proof

Check one number — your plan says three administrators, the system has five

When you were asked in September whether to switch off the rule that gives full admin access to anyone with a company email address, the question handed you a read-only count of the live system and ended with this: “One wrinkle: your written plan says three administrators and the live system has five.” You answered “Leave it on for now”, which settled the switch. The wrinkle was never reconciled.

So the open question is not the switch — that is answered and deliberately deferred, and nobody should ask you again. It is the number: either two people hold admin who are not in your plan, or the plan is out of date. Both are one look at a list. Until it is settled, the same count will be quoted back to you the next time this comes up.

For context, from the same read-only check: switching the rule off would lock nobody out — five keep admin because they are properly assigned it, four lose admin they were never actually granted, and one unapproved sign-in stops seeing admin screens. Verified against the decision record by the phase-rows driver, 2026-10-14; the answer is recorded and marked carried out. p7-domain-override

Restart one agent by hand — frees 15 stuck items, costs minutes

One agent hit a weekly usage limit at about 05:39Z on 2026-10-14 and does not reset until 18 October. It holds 15 of the 79 open items in the “Found along the way” group. Those items can be neither worked (its session cannot act) nor handed to anyone else (its reservations keep renewing — measured +107 seconds of lease life in 71 seconds of real time while the session was frozen).

Nothing automatic will ever reach it. Every rescue mechanism we have keys on an agent dying; this one is alive, ticking and behaving correctly. It also runs outside the account-swapping setup, so swapping its seat is refused — and another session took over its window on 10 October, four days before the limit, so nothing typed can reach it either.

The fix is a hand restart (--resume under ccswitch exec). It ends that session and kills whatever it had running, which is exactly why no agent should do it.

Measured by the found-rows board driver, 2026-10-14, and sent to this page because the ask cannot be raised any other way: the decision ledger caps one agent at three open questions, and three older ones are already waiting. Only this one agent is down. Two others share the same setup weakness, but both are working normally — the risk there is latent, not live, so there is nothing to do about them. This is not caused by a Claude Code update; our own earlier watcher code is the cause (ADR-0054).

Three things worth knowing before you work through this

1. The texting rule can never be satisfied as written. Texting on one line stays off until a counter of cross-customer phone lookups reaches zero. All four it still counts are the gas-leak emergency lookup, which three separate rulings say must never be locked down. The reviewer has ruled on the fix — count only the holes we can actually close, and pin the permanent exceptions by name so a zero still proves we are looking. That fix has landed and this job is finished — the counter now measures only the holes somebody may actually close, and the four gas-leak lookups are pinned by name so a zero still proves the check is looking at them. Texting on that line is still OFF, and turning it on is still yours: it also needs a clean test from a resident of another customer.

2. A safety check is gated on an "approval" that was never a person's. It refuses to let work land until something is approved; that approval traces to a note from the backup reviewer model, which its own record says could not run its usual double-check. It is quoted as a ruling in four places including live code. Verified: the id returns "unknown — no ledger row anywhere", while a control id in the same breath returns a real answer from Gera.

3. Two jobs are labelled as yours and are not. Their records say so plainly — one reads "owner: fede is a stale label on this row: no founder act remains anywhere on it… what remains is three bounded engineering slices and no founder act", and it adds that the identical stale sentence is also on its sibling, amend both. Nobody did; I have now struck it on the sibling too. Both can start without you. p10-core-outcomes, p10-core-replay

A third in that family, p10-core-exit, is not one of them — I checked before writing this. It still carries a live clause reading "Fede must restate or accept it before replay can be judged against it", and it is a roll-up whose own text forbids dispatching it. It stays yours.

What this means

More agents will not move this board. The work they can reach is nearly finished. A sitting with the two of you — working down the production changes and the open decisions — is what moves it, and the production changes are the biggest single block by a wide margin.

PropFlow Docs