fix(negotiations): the listing must say the park, from the same record the question came from

[yanekyuk]

The incident

Sandbox, 2026-08-20 22:04 UTC, negotiator DM for intent 34fa30bc-… (Hye-jin Park).

The client asked "Do we have a question?" while a negotiation sat parked input_required on her side — task aefff73b-…, open question "Timing: This week", parked for two hours.

Every #1470 surface was correct. The precedence gate found the question (logged declined — only reachable after finding one). The system prompt's open-questions section named it: position 1, "Timing: This week", recovered from the buried delivered message.

Then the model called list_negotiations. That tool renders pairings from OPPORTUNITY STATUS — where this pairing legitimately reads negotiating — and never surfaced that the negotiation was parked waiting on the client with a named open question. Holding a static context line saying one thing and a just-executed tool result saying another, the model went with the tool, as any model will:

"there are currently no open questions… I am still negotiating with Beatrice Hall's agent… nothing for you to decide."

Both clauses false at the task level; both faithful to the tool's rendering.

Root cause: the listing was the last surface still deriving "what's happening" from a source other than the shared resolver, so the tool and the context could disagree — and the tool wins the model's trust every time.

The fix

The listing says the park, from the same source of truth.

1. A pairing parked on the VIEWER renders as parked-waiting-on-you and NAMES the open question with its number. The number comes from NegotiationListingParkHost, whose api-side host (services/api/src/lib/question/negotiation-listing-park.host.ts) resolves it through readOpenQuestionsForIntent — the same call the open-questions prompt section and answer_pending_question make. The listing enumerates nothing of its own, so the number the client is shown is the number that routes their answer. A question's alsoUnblocks refs carry that same number, since one answer resumes them all.

2. A pairing parked on the COUNTERPARTY renders honestly too — waiting on their side, with no question content. That question is not this client's to read.

3. Statuses with no park keep today's rendering byte-for-byte, pinned by a fixture spec.

4. Parked-ness is never re-derived from opportunity status or a second predicate. classifyParkedNegotiation is split into classifyInflightPark / classifyPostStallPark — pure over the task and messages a caller already holds — and the async function becomes the reading half around them, keeping its lazy messages read. The listing calls them with material it already loaded: no extra query, no possible drift from the predicate answer routing uses.

lifecycleLabel states the park, superseding the status label. The persona is told to take lifecycleLabel as its user-facing wording, and "the agents are still negotiating" is exactly the sentence that became a false close-out. opportunityStatus still reports the true status; what it may no longer do is supply the sentence. connectionState gains parked_awaiting_your_answer / parked_awaiting_counterparty.

Prompt: the tool description and the negotiator persona both state that the listing's park annotations and the open-questions context section come from the same record — so the model has no basis to rank one over the other — and that negotiating alone never means "nothing is waiting on you".

The host is optional. Without it the listing still says whether a pairing is parked and on whose side; what it loses is the question's number.

Live verification (mechanical half)

list_negotiations rendered against the sandbox for the incident's exact (user 6c17f313-…, intent 34fa30bc-…). The Beatrice Hall pairing (72531450-…) now carries the parked line:

{
  "id": "aefff73b-d61f-4864-bfd8-859a8758ddcf",
  "counterpartyId": "72531450-4224-5612-b192-670629ab98af",
  "status": "input_required",
  "latestAction": "ask_user",
  "park": {
    "waitingOn": "you",
    "kind": "mid_flight",
    "question": 1,
    "questionLabel": "Timing: This week",
    "label": "PARKED — waiting on YOUR client’s answer to open question 1, “Timing: This week”. The agents are NOT exchanging turns and will not until the client answers; this is something for them to decide."
  },
  "lifecycle": {
    "opportunityStatus": "negotiating",
    "connectionState": "parked_awaiting_your_answer",
    "lifecycleLabel": "PARKED — waiting on YOUR client’s answer to open question 1, “Timing: This week”. …"
  }
}

opportunityStatus is still truthfully negotiating. It is no longer the sentence.

The human half — asking the agent "do we have a question?" again — is yours.

Tests

• services/api/src/lib/question/tests/negotiation-listing-park.host.spec.ts — the anti-divergence spec (fix(negotiations): a question is open because its negotiation is parked, not because its message is newest #1470's pattern): one fixture drives both readListingOpenQuestions and readOpenQuestionsForIntent, and the listing's numbers are asserted equal to the enumeration's. Plus the incident's buried question at number 1, alsoUnblocks expansion, empty parked set, and degradation to no-annotations on a failed read.
• packages/protocol/src/negotiations/tests/negotiation.tools.park.spec.ts — viewer park named with the record's number (a fixture where the record says 3 and a self-counting listing would say 1); the incident as a spec (negotiating + input_required on viewer → cannot render "negotiating" without the park); counterparty park narrated without content, asserted absent from the serialized result; post-stall park on the viewer; park-without-host; and the no-park fixture pin, field-for-field.
• Existing chat-tool suites (fix(negotiations): an answer to an open question is not a change of signal #1467/feat(negotiations): the owner's verdict needs a lane in their own DM #1471 families): green — 38 pass across the negotiator specs, 253 across shared/mcp, 697 across src/negotiations/tests.

Pre-existing failures, verified unrelated:

• negotiator-discovery-query.spec.ts (2) — live-LLM eval flake; passes in isolation (4/4).
• chat.graph / chat.suggester / chat.summarizer (11) — whole-dir-run pollution; all pass in isolation.
• tests/mcp.spec.ts (4, owner-approval/IND-593) — baselined by reverting mcp.controller.ts to HEAD and re-running: identical 66 pass / 4 fail.

Adjacent gap, not fixed here

status: 'active' maps to db state working, so a parked (input_required) negotiation is excluded from a filtered listing entirely — same family of "the listing says nothing is happening", but changing the filter's semantics is outside this diff. Flagging it rather than folding it in.

Boundaries

packages/protocol (listing rendering/guidance + the park predicate split + the new host interface), the api-side listing host, and its composition-root wiring. No changes to open-question-message.ts. No flags. Protocol patch bump 23.5.0 → 23.5.1 + changelog + lockfile sync (bun scripts/sync-lockfile-versions.ts).

Note on the handoff's file pointer: list_negotiations lives in packages/protocol/src/negotiations/negotiation.tools.ts (registered into the negotiator persona's toolset via the allowlist), not under src/chat/. The rendering change is there; the persona guidance line is in src/chat/negotiator.prompt.ts as specified.

🤖 Generated with Claude Code

https://claude.ai/code/session_01D46BEDXrtVKWUy9LNJ4JNR