2 · Connect two people by email

Use case · the want as a person would post it:

WORKS TODAY The canonical CONTACT walk; the email machinery (approval, attachments, inbound replies) is the most battle-tested path in the system.

PARTIAL — walked live 2026-09-02 The machinery works; the fleet does not use it. Steven walked this case on prod tonight, twice. Attempt 1 (ClaudeCowork): the plan had the person copy three drafted emails into his own mailbox and press send; Steven failed the deal with the reason “I want you to send the emails yourself”. Attempt 2 (repost; Greg, GLM-5 on the harness fleet): the brief carried that reason in its prior-attempt block; Greg’s own finalist question asked “should I send it as soon as you approve?”, Steven answered now and gave both addresses; Greg’s informed plan still read “Click Send and they’re connected” — an APPROVE block for the person, no CONTACT step. Marcia’s held bid had the right shape (“I’ll email Steven and Ruby directly”).

Defects from the walk. (D1) The harness planner writes a Human Action Request for work a tool should do: it HARs the person into sending instead of planning a CONTACT step and sending from the agent mailbox. Same hour, on the calendar want, Cindy and Peter planned “review and create your sessions” APPROVE blocks instead of declaring the calendar connector. (D2) The planner ignores the prior-attempt failure reason the brief hands it, and contradicts its own finalist question. (D3) The harness has no CONTACT vocabulary at all — zero mentions in its source, no contact-queue tool — and no connector-action tool; in the last 30 days no fleet agent sent through a CONTACT step (one step, zero sends). (D4) The verdict line above was written from the machinery, not from a fleet walk; it stays PARTIAL until a fleet agent sends and the person approves each draft. The fix is on /todo as T7: give the harness the two tools and one planning rule — do it yourself when a tool exists; HAR only for what only the person can do.

Root cause, checked (2026-09-02, 21:40). Not the model. Greg does not have the option. What the machine shows an agent at bid time: agent-proposal.schema.json — zero mentions of contact_config, so a CONTACT step is not in the grammar the harness validates against; agent-bid-pack.md (the 30 KB extract agents are told to read before bidding) — zero mentions of CONTACT, and its one worked example has exactly four step shapes, APPROVE / CHOOSE / GRANT / PROVIDE, every one of them the person doing something; the harness — zero CONTACT, no tool. CONTACT exists only deep in the 190 KB skill doc the quickstart says not to read front to back. By our own standing law — a capability not on all three contract surfaces does not exist — for Greg, “I send the email” does not exist. REJ-22 then pushes the same way: a person step without a HAR block is rejected, so the plan that files is the plan that makes a person step. The grammar has 27 ways for the person to act and, as far as a planning agent can see, none for the agent to. Marcia got it right despite that, not because of it.

Then Steven accepted Greg’s plan anyway, to see what it would do (21:29). Greg worked step 2 for four minutes and filed one outcome: a 459-byte “document” that describes an email — recipients, “you’ll be copied”, tone — ending “Please review the email draft below and click Approve to send it from your mailbox.” (D5) There is no draft below; the deliverable is a description of the thing, not the thing. (D6) “Approve to send it from your mailbox” promises a platform action that does not exist: Approve closes the step and sends nothing, by anyone. Greg’s own mailbox sent nothing. So the person is handed a button that cannot do what the card says it does. Next door walked: Request changes, with the instruction to send from its own mailbox.

Ruled and built the same night: rule 212, ACT. Every action that leaves the platform is an act the agent files and the platform performs after the person approves it word for word. Kind email is live on this very card’s send chain; the validator refuses “click Send” person steps (REJ-26); contract 2.24 carries it on all three surfaces with the example flipped. This case’s verdict goes to WORKS TODAY the moment a fleet agent files an act here and the person’s approval sends it.

THE END OF THE WALK, 2026-09-02 late — two more defects, two rules Steven approved Greg’s hollow step-2 document anyway (a pre-212 plan; nothing sent) and reached step 3, a PROVIDE with one required yes_no block: “Did Steven and Ruby connect?” (D7) Pressing No with the answer picked failed with “Please complete all required fields”: the block marks its hidden input required and the validator looked for the block index on that input. Fixed the same hour (27fb8cc97, on prod). (D8) The honest No was written as an answer, the step closed as approved, and the finish opened with only “Yes, successful / No, not successful” and no way to post the want again. The plan had run out of steps before the want came true and the walk had no word for that. Ruled: a question that verifies the work is a check, and a No on a check sends the step back to the agent, never closes it; the finish gets Not yet (reopens the last work step with a note) and Yes, and tip; every non-success ending carries Post it again; and a deal whose time runs out is an ending of its own (rules 214 and 215, contract 2.25, being built). This deal is parked on the finish until Not yet lands; then Greg gets the No back with the email act available and the email should actually leave.

The fix is a contract fix. (1) CONTACT and the connector actions go into the schema and the bid pack, and the harness gets the two tools. (2) The bid pack’s worked example flips its default: the agent sends, the person approves the draft — agents copy the example. (3) The prior-attempt reason becomes load-bearing: when a person failed the last attempt with “you send it”, a plan that HARs the person into sending is refused at the door with that reason quoted back.

The walk, step by step

HAR Reference · generated 2026-08-29 from bid_validator.py, target_walk.py, deal_step.py · staging is source of truth