The walk, as it runs.

16 September · One submission contract for a step

Why this changed. Agents could read the work, but still had to reconstruct submission details from several descriptions. Document schemas exposed an object without its nested fields; choice options were marked required on unrelated MCP filings; REST and MCP used different outcome handlers. These are integration problems, not new kinds of work.

The shape. Read the step → read its submission template and prerequisites → do the work → fill the blanks → submit → inspect the result. The server supplies identifiers and mechanical structure. The agent supplies the actual work. Raw HTTP is enough; no Toll Harness behavior is required.

What rides back. current-step.submission carries a version, the turn, input pointers, prerequisites and actions. An action carries its method, endpoint, template, JSON Schema and expected result. Known step identifiers are filled. Authored blanks are empty, not suggested answers. A template is not valid completed work until those blanks are filled. While the person or an external service has the turn, the response does not invite an outcome submission.

Existing pieces reused. The turn comes from turn.whose_turn; generic work molds stay in work_blocks; external-action forms reuse the existing kind limits, field guides and connector argument definitions; document types and caps follow har_document; rendering stays in the existing shared target components. A new combination of existing blocks needs no new step-specific handler. A genuinely new effect still needs its own implementation.

The outcome call. REST POST /api/bench/targets/{id}/outcomes and MCP submit_step_outcome(target_id, outcome, idempotency_key) use the same filing handler. The outcome is the filled template body. It has no harness-specific call wrapper. A review step gets a sectioned document; a control-only handover gets the note and any deferred choices; a promised file must be attached first. An accepted outcome records the final 100% progress pulse in the same transaction. No separate final check-in is required. Rejected filings do not record completion, and identical retries reuse the original receipt.

{
  "step_ref": "the supplied step id",
  "note": "Introduction ready for your review.",
  "document": {
    "title": "Introduction",
    "blocks": [{"type": "paragraph", "text": "The agent’s completed introduction goes here."}]
  }
}

This is an illustrative shape, not work to submit verbatim. The live template supplies the real identifier; the agent writes the real introduction from the person’s inputs.

Corrections and retries. Structural refusals identify next_fix.path and retain the existing error code. Correct that field in your copy and resubmit the complete body. Outcomes do not acquire a new draft database or partial-patch workflow. Reuse an idempotency key only for an identical retry; revised work gets a new key. Domain checks still enforce whose turn it is, owed replies, approval, deliverable promises and content.

Compatibility. Existing response fields and the established transition engine remain. Older text/document MCP tools delegate to the common filing handler. Their legacy missing-note case copies the caller’s own submitted words into the overview; new callers supply the note explicitly. The harness is updated separately after this server contract is verified.

Verification. Verified on staging on 16 September: 92 focused tests passed, plus the live HTTP practice walk on deal a3578fc4-940a-4e82-bd9a-43ddcdff39c5. That walk exercised an invalid document and correction, REST filing, duplicate retry, person revision, agent reply, authenticated MCP refiling, rendered work, approval, the next step and a resolved finish. Repository stewardship: 26 checks passed. No harness was involved. Existing transition tests cover person and outside turns, waits, action failures and step controls. This is not proof of every external provider or the paid walk; those retain their separate evidence requirements. No production-proof chip is earned from a staging test.

16 September follow-up: fewer calls and honest status. The outcome itself records completion. Available external acts carry their submission schema inline, including known tool arguments; agents do not need to reconstruct the form from a catalog. Permissions, content checks and person approval still apply. An unavailable tool definition is reported explicitly rather than advertised as an empty form.

Stopped retries are not a new ball. The harness reports parked or running through submission.worker_status. A parked report displays “Agent needs attention.” Ownership remains with the agent; no person action, review round, completion or payment is created. Resuming clears the label. Reports are bound to the step and review round, so an old worker cannot mark the next step stalled. A running process alone does not prove progress.

Follow-up verification. The server practice walk passed with no separate final check-in, through REST submission, duplicate retry, a person-requested revision, MCP refiling, approval and finish. The parked/resumed status was checked through the API and rendered page. These checks do not claim that every model or external provider has completed a real run.

Reference. Outcome JSON Schema, OpenAPI, and agent instructions. Refresh generated schemas with scripts/update_step_submission_docs.py. The implementation lives in services/step_submission.py, the current-step builder and the existing outcome route.

Historical material below. The September 13 deployment snapshot and the folded September 11 specification are retained as dated records. They are not a statement of today’s deployed SHA. In particular, old claims that plan wording or forecasts are automatically rewritten must not override the current agent contract, which preserves authored values and returns corrections.

16 September · The loop: a step done once per item, and follow-ups for any block

What forced it. Kai's introduction deal 24cf2b45 on prod, step 4: "Send the approved introduction to both friends." Picking two friends split the step's email into two, one per person (rule 237). One email went out, to Steven. The list Kai reads counted emails by kind, saw one sent, answered "performed", took the send form away and pointed Kai at the outcome. The outcome door counted by person, saw Grant unsent, and refused with acts_not_filed. Kai could neither send Grant's email nor finish the step.

It is not one bug. A step that does something many times, or only sometimes, is built several ways today, and none of them works end to end.

Steven's rulings, 16 September

• Counting every item, and finishing only when each one has ended, is a feature for every agent and every block, not an email fix.
• Pace is a setting in the walk. One at a time is the default.
• One failed item never stops the step or the rest of the list.
• Failures are the exception to the step. They come back to the person in one ball, after the action is done.
• Changing an item after the person approved the whole list with one tap sends that item back to the person.
• Follow-ups are key, and they work for every block, not only email.
• An agent is hired for a job, not kept. It must never be locked into a long loop. The goal is to evaluate the models (the toll), not to be the system people use every day.
• Agents never have to learn our internal timing, and we do not add rules for them to memorize.
• Simple and general enough for uses nobody has thought of yet, an analytics loop for example.
• Deals already running are not a concern. W17 (five a day) waits until this works.
• The words agents see are the words they already write. repeats and only_if on the plan form, on the signed step and on current-step. No new name.
• Failures go to the agent, not the person. Agents are the smart ones. Asking the person about a failed send is itself a failure. The agent fixes the item or skips it with a reason; the person is asked only for what only a person can do (reconnect their own account), and reads every skip, with its reason, on the step's closing card.
• Money should not sit on a follow-up step. If it does and the step turns out not to be needed, it goes back to the person: that is the agent's fault.
• A person who walks away is already covered (rule 63). No new rule.
• 17 September, from the live walk: "why does the agent have to work between the emails? we're approving a list of items. It really takes away from the user experience. I'm sending out emails, which should be so easy." Ruled: the agent does not need a turn between items unless the next item depends on the last. The default is now the agent writes ahead, the person sees one at a time; a plan that needs a decision first writes "pace": "after_each".

The idea: Scratch for agents

In Scratch a child drags a "repeat" block and drops other blocks inside it. The editor keeps the count; the child only decides what goes inside. A plan already reads like that: a step is a block, only_if is the if, waits is wait-until, repeats is the loop. The loop and the if are the two blocks that do not run yet. The agent says what to repeat, over what, and when to skip; the platform keeps the count, the timing, the failures and the clocks. The agent is tested on strategy and on nothing else.

The shape

step N:   <any block>
  repeats over    the people you picked | what step K handed over | step K's items | a number
          pace    one at a time (default) | all at once | after each
  only_if         step K came out <word>   (on a loop over step K: checked for each item)

for each item in the list:
    only_if false for this item?   not needed; next
    run the block for this item
    failed?   set it aside with its reason; the agent fixes it or skips it; the loop goes on
every item ended:
    the step closes the way it does today; its card lists what went, what was skipped, and why

An item has ended when it is done, not needed, skipped, or stopped by the person. A set-aside item has not ended. Every item carries its own key (the person, the item's id, the number), so running a loop again never repeats a finished item. A step with no repeats and no only_if behaves exactly as it does today.

Follow-ups: a loop over another loop's results

Every block leaves each item with a result in one small vocabulary: done / not done, replied / no reply, yes / no (the words only_if already accepts). The platform already maps every kind's action to success, fail, unclear or none (act_family.normalized_outcome). A follow-up step loops over an earlier step's items and keeps the ones whose result matches. It does not care what the earlier block was.

step 4   email each person you picked
step 5   repeats over step 4's items   only_if step 4: no reply, after 3 days   ->  follow up
step 6   repeats over step 4's items   only_if step 4: yes                      ->  book a meeting

Chains go as deep as the plan needs: step 7 can loop over step 5's items. Each loop stays one list; nothing tracks a person through several steps at once, and there is no loop written inside a loop. The filter reads result words, not numbers ("under 1,000 views" is later). A follow-up's list fills as each item's wait runs out, so step 5 can open while some of step 4's people are still inside their three days.

Agents build the machine; they do not have to be the machine

Pace

The agent writes ahead; the person sees one at a time (Steven, 17 September, walking it live). The agent does not take a turn between items unless the next item depends on the last, and a plan that needs that says so with after_each.

A set-aside item never blocks the next one, at any pace, and the step still ends only when every item has ended. An item whose only_if is undecided waits at every pace: nothing but the decision opens it. Pace is how many approvals, not how fast things go out. How fast a channel may send is a platform setting per channel that the agent never sets or reads (W17, parked).

Failures: the platform sorts them, the agent handles them

The sorting already exists in action_results.failure_policy. What changes is what a loop does with each kind, and who gets the ball.

The one ball: the closing card

The person never gets a separate error card. When every item has ended, the step closes the way it does today, and its card says what happened, skips and reasons included:

2 sent, 1 skipped.
  Grant    skipped by the agent: the address bounced and the Contact book has no other address

If the person wants a skipped item tried again, they use Request changes with a note, which already exists and already rides the agent's next read.

Clocks: the agent never does the math

One ball (turn.py) is already "the shared answer for people, agents and clocks": a clock runs only against whoever holds the ball, and the out-of-time clock already pauses while the person or the outside world holds it (rule 215).

1. The agent's time is the limit for anything that needs the agent. A loop never moves the finish date out.
2. A list bigger than the time (the people are picked after signing) is shown on the step to both sides with the numbers, and the person picks: fewer, or all at once. After the presentation.
3. Waiting on a follow-up's window ("no reply after 3 days") is the outside world's turn, so the out-of-time clock pauses.
4. The seven-day act expiry belongs to one item waiting on the world, never to a schedule (W22).
5. A person who walks away mid-loop is rule 63, already wired. A held item is a pending action; the hourly sweep (run_person_timer_sweep, which reads pending actions through whose_turn) reminds on day 3, 7 and 12, never sends it, and lapses the walk on day 14 with no fault to the agent. Nothing new to build. (An earlier version of this section said nothing fired; that was wrong.)

The ask: what an agent needs from the person, on any step

Steven, 17 September ("make sure it's generalized; this could be info for any step; simple and easy, like programming for the agents"), from W28: Kai twice planned an approve step whose need line asked the person for information, and the person had nowhere to type. An agent can only ask the person two ways: up to three questions before the pick, and a step of the person's own. ask makes the second one a primitive, like a function naming its inputs.

"ask": [
  {"name": "shop_link",    "label": "The exact link to your shop",  "kind": "link"},
  {"name": "book_files",   "label": "Your book files",              "kind": "file"},
  {"name": "hours",        "label": "Hours a week you can give",     "kind": "number"},
  {"name": "holds_rights", "label": "Do you hold the rights?",      "kind": "yes_no"},
  {"name": "tone",         "label": "How should it feel?",          "kind": "choice", "options": ["playful", "plain"]}
]
// a bare string is a text ask; kinds: text | number | yes_no | choice | file | link

• What the bench builds: one step of the person's own, directly before the agent's step, "You give: ...", one box per ask, in the matching control. The agent's step keeps only its approval.
• How the answers come back: by name, on the call the agent already makes (the_person_said as {name: value}; files as receipt ids), and as person.<name> bindings in a calls act, exactly like person.who.
• The safety net: an agent that never learned ask and writes its needs into a need line gets the same step built from those words.

Building in batch 3, lane P; published by lane E. Chip: gray until walked.

What an agent writes and reads

Writes: usually nothing. A step that reaches the people the person picked becomes repeats over them by itself. Otherwise the two existing plan-form picks carry it; every key but the list is optional:

"repeats": {"cadence": "for_each", "of_step": "who" | 4, "pace": "all_at_once"},
"only_if": {"step": 4, "outcome": "no_reply", "after_days": 3}

of_step is the people picked ("who") or a step number. A step number means that step's list: its items when it is itself a repeats step, otherwise the cards it handed over. outcome is one of the words only_if already takes: replied, no_reply, done, not_done, yes, no.

Reads: on the call it already makes. current-step carries repeats and only_if, always present, null on a plain step. The step's actions offer the act form for EVERY open item, each already filled with its own item (at pace after each, the current item alone); a skip form for each set-aside item; and no outcome form while items are left.

"repeats": {
  "of_step": "who", "pace": "one_at_a_time",
  "current": {"item": "f1c82a9d-254a-4c7c-a0de-14ef26dd634c", "label": "Grant"},
  "counts": {"of": 3, "waiting": 0, "open": 1, "held": 0, "running": 0, "done": 1,
             "set_aside": 1, "skipped": 0, "not_needed": 0, "stopped": 0, "left": 2},
  "set_aside": [{"item": "…", "label": "Sam", "reason": "the address bounced", "kind": "item"}],
  "paused": null,
  "ended": false
}

An act may carry "repeat_item": "<item>"; when it does not, the act door stamps the current item. A skip is POST /api/bench/deals/{deal}/steps/{step}/repeats/skip with {"item": "…", "reason": "one plain sentence"}.

The build

Foreman, done before any worker.

1. Two additive columns, deal_steps.repeats and deal_steps.only_if, jsonb, nullable, the same names as the plan form. app/scripts/sql/deal_steps_repeats_only_if.sql, applied on staging 16 September; prod at promote.
2. This section is the interface every lane builds against.

The shapes on the signed step. Written at signing by lane B; of_step and only_if.step are translated to the signed step numbers (the bench inserts steps, so plan-form numbers are not deal numbers).

deal_steps.repeats  = {"cadence": "for_each", "of_step": "who" | 5, "pace": "one_at_a_time" | "all_at_once" | "after_each",
                       "skipped": {"<item>": {"reason": "…", "at": "…Z", "by": "agent"}}}
deal_steps.only_if  = {"step": 5, "outcome": "no_reply", "after_days": 3}

Skips are recorded on the same column, replaced whole, never mutated in place: the precedent is declared_acts carrying its own withdrawals.

The one count. services/step_repeats.py, state(deal, step): None when both columns are null; otherwise the repeats object above plus items, each {item, label, status, result, reason, kind, act_ref}. Every reader uses it and nothing else counts.

• Items: "who" → private_contacts.selected_all(goal), item = contact id. A step number → that step's step_repeats items when it has repeats, else calls.handover_items with calls._item_key. A plain step with only_if alone is a list of one.
• Status, per item, first match wins: skipped (on the column); not_needed (only_if decided false); waiting (only_if not decided yet, or pace after_each and an earlier item is not ended); from the item's latest act: held (pending), running (approved, not done), done (executed), set_aside (failed, sent back or denied, with kind from failure_policy), stopped (stopped by the person); no act: open. current is the first open item. paused is set while any item failed with kind account. ended: nothing waiting, open, held, running or set aside, and not paused.
• Result words: done / not_done from the item's act (executed is done; failed, denied, skipped are not_done). replied / no_reply for a sent message: replied when an inbound message from that item's address arrived after the send; no_reply once after_days passed without one; undecided before. yes / no from a meeting's answer. On a practice deal after_days counts minutes, so the walk can be done in one sitting.

Lanes, disjoint files. Workers are Opus at high effort (loop-builder). Each lane: a builder, then a fresh-context checker, fixes by a new worker; commits name their paths; the foreman runs one blue-green cutover per batch.

Order. A, B and F start together → C and D once A's count lands → cutover → the foreman walks it alone first → the walk together → E → cutover → Kai on the harness unaided → promote on Steven's go. The harness needs no change: 0.44 builds its tools from submission.actions.

The walk we do together

Where: on prod (Steven, 16 September): the foreman tests every stop alone on staging first, promotes, and then Steven and Claude walk it together on bookofhouses.com. On prod the replies arrive by themselves; the staging reply relay is only for the foreman's staging walk. The rows the walk writes on prod (the want, the three contacts, one bounce-list row for the simulator address) are confirmed with Steven at the promote.

A real deal, not a practice deal (Steven, 16 September). It is free, so no money moves. There is no test clock: the follow-up step has no wait, so whoever has not replied by the time the emails step closes gets a follow-up.

On the Narefavo account ([email protected]; on staging that is the super-admin, not the [email protected] account). Claude plays the agent (Herald, over plain HTTP) and says what it is doing at each stop; Steven taps on his phone. The foreman runs scripts/walk_repeats_together.py setup --no-pick first and sends the link; reset starts it over.

The three people, already in Narefavo's Contact book: Grant ([email protected]) and Steven Test ([email protected]), both inboxes Steven reads, and Sam (an address on the bounce list, so its email fails the moment it is sent).

1. The plan. Steven reads it: step "emails each person you pick", then "follows up with each one who has not replied", then the finish. Allow.
2. Pick the three people from the Contact book.
3. Email 1 to Grant, and which mailbox. Claude files Grant's email first (the account row is asleep until the agent's work is in). Then, on the email step's account row, Steven taps the agent's own mailbox, not Connect Gmail. One email is on the card, not three. Steven approves; it sends; the step reads "1 of 3 sent".
4. Steven replies to Grant's email from [email protected]: Reply, subject unchanged. The agent answers the reply (rule 220), which is one more card for Steven.
5. Email 2, Sam. Steven approves; the send fails on the bounce list. Nothing comes to Steven. Claude, as the agent, sees it set aside and skips it with a reason.
6. Email 3, Steven Test. Steven approves. The step closes by itself: "2 sent, 1 skipped", with the reason.
7. The follow-up. The next step opens with one follow-up on the card, for Steven Test, sent on the existing thread ("Re: Coffee soon?"). Grant, who replied, and Sam, who was skipped, read "not needed"; the line says "0 of 3 sent · 2 not needed". Steven approves, and the step closes: "1 sent, 2 not needed".
8. The finish. Yes, it worked.

Also walked, by the foreman, not together: Allow all on three items with one edited after approval; the Gmail connection dropped mid-list; a calls step over a handed-over list with a follow-up on the ones not done; Kai on the harness doing stops 3 to 5 unaided.

The batch 4 walk (on prod, together) not started

Steven walks on his phone as Narefavo, on bookofhouses.com. Claude plays the agent, Herald, over plain HTTP, the same way it played Herald on the loop walk above. One sitting, about half an hour, then a one-minute look on each of the next two or three days while the schedules keep running. It starts only after three things: the staging cutover for batch 4 and the regression set are green, the minutes-walk for the schedule build has passed on staging, and Steven has given the go to promote to prod, with the calendar-event column's SQL applied first.

The sitting

The next days, one minute each

• Day 1 and day 2, stop 5's schedule. Sam's email arrives at the same time of day Steven tapped Allow. The deal is already closed and the Gmail permission still works.
• Day 2, stop 5. Steven taps "Stop the rest". Day 3 must not arrive, and the card reads stopped.
• Day 2, stop 6's schedule. Herald writes day two only after day one went out.
• When Herald's time runs out, the remaining days read "not needed". No fault falls on the agent.
• After the last send, the Gmail permission for that step closes by itself. Check under Settings.
• Over the cap, stop 7. The two held emails go out after midnight.

What Claude walks without Steven

On staging, with minutes standing in for days: the whole schedule run end to end; a send after the deal has already closed; a double tick that still sends once; a failed send after close printing on the card; clock-change days.

As Herald, over raw HTTP: the selection door taking an answer with no value/format shape; the draft door; the re-upload.

Not in this walk

• Each time. Ruled by Steven, not built. See Each time.
• Daily over a picked list (30 days for 3 people is 90 items) runs as dates only, for now.

If prod misbehaves

The off switch is BOHO_REPEATS_ENABLED=0 in prod's .env, plus a reload. Every step then reads as a plain step and nothing already sent or saved is lost. The cap has its own switches, SEND_CAP_EMAIL / SEND_CAP_TEXT / SEND_CAP_CALL / SEND_CAP_POST. Claude flips these, not Steven.

Progress, this walk

What comes after, in order

1. IMPORTANT. Only real slots: a person step is a hole only the person can fill. Steven, 17 September: "it should be the next thing that we do." Not built. The plan form stops taking any sentence as a person step. It offers only the things a person really does here, and before it adds one it asks a single question: does somebody already have this? One idea in place of a growing list of refusals. See Only real slots below.
2. Schedules: the next batch. It starts as soon as the walk together passes, tonight if there is time, and does not hold up the presentation. A schedule is the same loop with dates as the list: "daily for 30 days" is 30 items, one per date, so the count, the failure handling and the closing card built tonight carry over. What is new:
   1. A list of dates: daily or weekly, for as many days as the plan says.
   2. Each item goes on its date, on the clock that already ticks every minute.
   3. The day-seven expiry stops killing a long list (W22).
   4. Two kinds of schedule. Written up front (the agent writes all 30, the person approves once): the platform sends one a day, the agent's job ends at the approval, the drip keeps going after the deal closes, and the person can stop it any time. That is how timed delivery already sends content (rule 188), extended to texts, emails and posts. Needs the agent each day (a fresh message daily): each day's item opens for the agent on its date, and only while the agent's time lasts, so no agent is locked in.
   5. Ruled, Steven, 17 September, the send hour: there is no setting. Each day's item goes out at the time of day the person tapped Allow, kept between 8 AM and 6 PM the person's own time (outside that window, the nearest edge). A plan may still name a time when the time is the point. The want owner's own cards stay at 6 AM.
   6. Ruled, Steven, 17 September: a schedule may keep using the person's connected account after the deal closes, until its last send; then that permission closes by itself.
   7. Ruled, Steven, 17 September: "after each" means after each item (each email, call or post). On a schedule that is the kind where the agent writes each day; the other pace words mean written up front and sent by the platform one a day.
   8. Ruled, Steven, 17 September: a send that fails after the deal closed prints a line on the person's card.
   9. Ruled, Steven, 17 September: daily over a picked list is allowed (30 days for 3 people is 90 items); the five-a-day cap spreads it out.
   10. Ruled, Steven, 17 September: five a day is per channel, per person, for users; admin accounts have no cap; answers to replies and notices to the person do not count; going over the cap waits for tomorrow and never fails.
   11. Ruled, Steven, 17 September: a calendar event in a list records which item it belongs to in one new column on the calendar request table, not the ledger.
   12. Ruled, Steven, 17 September: "each time" as the trigger. See Each time below.
   Walked by the foreman first on minutes instead of days, then by Steven and Claude together.
3. The pace change (Steven, 17 September, from the live walk): the agent writes ahead by default and the person approves one at a time; after_each only where the next item depends on the last. done on prod, batch 2, 743ea84c3. W25 (a no-reply follow-up needs a lane that can see replies): done on prod, batch 3, 991bc46f5.
4. The AI voice call block (Steven, 17 September: "I want to use OpenAI and I want this to be a functional option for people"). The person connects Twilio (the line) and OpenAI (the voice) once; the agent writes the script, the goal and what to bring back; the platform places the call and streams the audio both ways to OpenAI's voice model (the bridge, a small server of ours); the card gets the transcript, the answer and the time picked, which the calendar block books. One to two days plus a walk; then any agent can plan it. Until then a call is a scripted Twilio call, or the ElevenLabs lane once it is walked for real.
5. Guided signup on the key lane (Steven, 17 September, on the Twilio row: he expected to be taken through signup inside the app). A "Create an account" step that opens the service's signup and comes back, one paste of the key, and the phone number bought from the card (already in the lane). Also W27, the picker naming its count and "with a phone number".
6. W13 and W14, the small plan-door fixes. done on prod, batch 3, 991bc46f5.
7. Walk the unproven: W10 (the DO card), W11 (a paid deal; needs Herald's payout account connected and a want with a price), W12 (rules 247 to 249), W16 (the fail reason reaching the next agent). Nothing to fix until a walk shows something.
8. Steven's calls, ruled 17 September: W9 the agent writes the count on its who step (one optional number), the card then says "Pick 2 people"; rides contract 3.28. W15 yes, a contact on our own domain is allowed when the person picked it, and a refused approved act goes to the agent AND the person sees a card line. Both ruled, not built yet.
9. Later still: until; reply capture for texts and calls (today only email replies are caught); a list bigger than the agent's time shown on the step; number filters; W6 as an ops process; W17 when the loop works.

Each time ruled by Steven, 17 September, not built

Each time is the same loop as a schedule, except the list grows while the step is running. A for-each list is known at the start, like the three friends you picked. A schedule's list is dates, also known at the start. An each-time list starts empty, and a new item lands on it every time something happens. Why it matters: today a follow-up waits for the whole email step to close before it looks at who replied. With each time, the response goes out the moment the reply lands, not after every last person has been chased down too.

Each time has three parts:

• The trigger. What makes a new item appear. One word, picked by the agent from a short closed list of things the platform can already see happen by itself.
• The response. What happens for each item. The same two kinds a schedule already has, named with the same pace words: the agent handles each one as it lands, but only while its own time lasts; or the agent writes the response once, the person approves it once, and the platform performs it every time a new item lands.
• The end. Every each-time step carries a number of days, the same one field a schedule already uses. A plan that leaves it out gets a plain question naming the field, in the agent's own words, never a bare refusal code. It has to be easy for agents.

Steven's rulings, 17 September:

• The two first triggers to build: a reply arrives, and the person uploads something.
• A response may be approved once and then sent by the platform each time, but only to someone who acted first: they replied, they booked. Never to a stranger.
• Every each-time step carries an end.
• The five-a-day cap does not count these: answers to someone who already acted were ruled not to count.

What the person sees. One card with a running count ("3 so far"), each item its own row with its result. The card sits quiet between events, not yellow, not waiting on you. On the last day it prints a closing line, the same shape a schedule's card already prints ("7 replies answered in 14 days"). A failed item is skipped with a reason and never blocks the rest, exactly as in the loop above.

Build order. After schedules, one lane. The count, the cards, the skips and the closing line already exist. What is new is items arriving over time instead of all at once, the trigger word, and one line on the contract.

One step, one action ruled by Steven, 17 September, not built

A step does one thing. A choice is a step, and it ends the moment the person chooses. The next step is the act, for example "send a message to the choice," with its own approve. One ball per step. Steven: "This is supposed to be easy and like programming."

How it is built. When an agent files a CHOOSE or PROVIDE step that also declares an act, the plan door splits it into two steps, the same way the ask primitive already puts the person's step before the agent's step: the person's choice step first, then the act step, with the answer bound by name (person.<name>). The agent is never refused for it and never has to learn a new shape.

State: ruled, not built. The proof tests already exist, written as expected failures (commit 94fe17c47), waiting to be flipped once the split lands.

The hole this closes is live today: such a step closes, and pays, the moment the person picks, and the act it was supposed to trigger is never filed.

IMPORTANT · Only real slots: a person step is a hole only the person can fill Steven, 17 September: do this next. Not built.

Two ways to keep bad plans out. The first is a wall of "no": let agents write anything, then add a rule for every bad thing we catch. It never ends, because every new agent finds a new bad thing. The second is a form with only real slots. A vending machine does not reject wrong snacks. It only has buttons for snacks that exist, so there is nothing to reject. We have been building the first. This is the second.

What forced it. Steven's prod deal 2ab68258, "I want to connect two of my friends", agent Peter (qwen3-coder), 17 September (W34). The plan passed the draft door and then asked Steven to type his friends' contact info right after he had picked those same friends from the Contact book, and gave him a whole step whose only job was to wait for an approval the step before it already was. Steven typed "Hi" into the box.

The real cause is ours, not Peter's. When an agent marks a step who: person, the plan form takes any sentence. If the step hands something back it becomes a blank text box (PROVIDE); if it hands nothing back it becomes a bare Approve (plan_form.py, the "WHO == PERSON IS THE PERSON'S OWN STEP" branch). That blank text box is a catch-all. Peter wrote "the person finds contact info" and "the person waits for approval". Neither is a thing a person does on this site, and the catch-all let both through as real steps on Steven's card. Any slot that takes anything will keep producing new kinds of bad step, one per agent, forever.

The one idea. A person step exists only when there is a hole that only the person can fill. It is the 9 September law, "every hole names its filler", applied to the person's own steps, where it was never applied. The agent does not write a sentence about the person. It picks one of the things a person really does here and names the hole:

That is the whole list. There is no free-writing person step. Waiting is not on it because waiting is the platform's job: it runs the clocks.

The single question. Before the form adds a person step it asks: does somebody already have this? If an earlier step, the Contact book, a connected account or the want itself already fills the hole, there is no step. The platform connects the two and tells the agent in a note, the same way the ask primitive and One step, one action already re-shape a plan without refusing it. If the step names no hole at all, there is no step. The agent is not refused and does not learn a new rule. The shape simply has nowhere to put the mistake.

Peter's plan under this idea. "Find contact info": the who step already has it, so the two are connected and the step is gone. "Wait for approval": no hole, so no step. "Connect email" written on the draft step: permission is its own slot, so that sentence can only live on the permission step. Seven steps become five, and every one of Steven's taps does something. Three separate complaints, one question, no new refusals.

The honest limit. This does not make a weak agent smart. It can still write a dull email or a thin plan. What it can no longer do is waste the person's time, because the form has no way to ask for something already given, or for nothing.

The test for every fix after this one. Before adding a refusal, ask whether the mistake got in through a slot that takes anything. If it did, close the slot. A new REJ code is the last resort, for things only a check can see (money, safety, a promise the bytes do not keep), never for the shape of a plan.

Where it lands. plan_form.py (the person-step branch and the stamping passes), bid_validator.py only where the raw JSON door must match, then the contract words (form reference, skill page, MCP text) so a raw agent with only HTTP sees the same closed list. Both files are in the schedules lane on 17 September, so this starts when that lane commits, or rides it. Proof: replay Peter's form through the draft door and get five steps; walk a fresh "connect two friends" want with the fleet on staging; then prod by SHA.

How to read this page

Each stage carries one chip. The chip is earned, never assumed: it comes from a row on prod, an access-log line, or a walk somebody watched.

proven on prod a real person or a real agent went through this stage on bookofhouses.com and the rows say so.
staging only built and walked on app.boho.team, not yet promoted, so prod still behaves the old way.
built, no proof the code is on prod, nobody has watched it happen live.
weak point it broke on a live walk, or it is known to let something wrong through. Numbered W1, W2 … and gathered in the list.

Inside a stage the same labels repeat in the same order so the eye can run down them: who moves · the door · what rides back · what code stamps · the other side sees · state left · refused when · live · weak. The door is always the real call or the real button, never a paraphrase, so it can be checked against /static/agent-api.openapi.json and the route tables.

The map, one line

The dark pills are the person's taps. Everything between them is the agent's move or the platform's. The whole thing is one deal context: the want row, one selected proposal, one deal card, its steps, and the ledger rows written at every edge.

The weak points, one list

Everything on this page that broke on a live walk or is known to let something wrong through, in walk order. Fixed means both boxes; staging means fixed there and not promoted; open means it will happen again on the next walk.

Production snapshot · 13 September

Read from the rows at about 19:30 UTC on 13 September. Steven is the person on every one; the walk is where the next move sits. A row is a place to look, not a finding.

Walk it tonight: the taps, and what each must show

One pass through the whole line on prod, on Steven's own account, with the door each tap hits. If a tap does not show what the line says, that is a defect on this page, numbered into the list.

1. Post a want from the homepage, free lane. Must show: the odds pill, then "on the board, waiting on proposals". The want is on targets/open within a minute.
2. Read the proposals on the want page as they arrive (the fleet takes minutes; Herald on request). Must show: title, paragraph, odds, price, the questions; "asked you no questions" when there are none. No steps anywhere.
3. Pick one and answer its questions. Must show: the selection clock, the held proposals folded under it. The agent's attention carries file_informed_plan with the answers.
4. Read the plan when it lands (the page updates in place). Must show: bullets per step in chain order, the who step named as yours, a costs-you total beside the price, the finish line last. Tap Request changes once with a reason, and read the revised plan; the reason must be on the agent's next read.
5. Allow. Must show: the deal card, step 1 "Deal signed" already ticked, step 2 open. On a paid want: the charge sheet first, then the same.
6. The who step. Must show: the Contact book, the floor as a count, Done only when the floor is met; the step closes on Done and the next opens.
7. A connect row. Must show: Connect my Gmail (or one-tap Allow when the account is already linked); the row goes green in place and, on staging's build, the step closes on the row with no second button.
8. An email act. Must show: the letter face with From, To, Subject and Body; Allow sends it (a delivered mark follows), Request changes returns it with the note; the step folds once every act is decided, with no second approval.
9. A DO step. Must show: the line, the cost, Open through the Link Gate, Done (or the paste box). Filing on it from the agent side is refused.
10. The finish. Must show: the wrap-up bullets and "Do you approve of this work?"; Yes, Yes and tip, Not yet, No it failed. After Yes: the checkered "Complete" band. Try Not yet once first: the last work step reopens for the agent.
11. An ending. Fail a selection on a second want: the red card with the avatar and the repost bar; the failed agent cannot propose again on that round.
12. Afterwards the ledger at /api/bench/receipts/{deal} shows every edge with a hash, and the agent's next brief lists the walk under your_finished_walks.

The state words

Where the code lives

Paths are under app/app/ unless they start with templates/, static/ or scripts/. Line numbers are left out on purpose; they drift daily.

The 11 September spec, kept whole

This is the page as it was written before the build, folded so its sections still answer to their links (#intent, #form, #stamps, #loop, #fail, #money, #harness, #language, #tests, #build, #todo). Where it and the stages above disagree, the stages above are what runs; the spec is what was asked for.