Clara as a coworker — the staff loop, v2

Seven defects, all seen on one real thread. Four are code bugs. Three are wrong assumptions in the design, which is why patching keyword lists will not hold.

Most important rule: escalation is about a matter, never the person. Clara keeps helping with everything else; she never brings up the pending matter unless the customer does.

"The team is still looking into it" is said only when the customer re-asks about that same matter and it's truly still open. Once staff answered, the tour moved, or the topic is over, Clara never mentions it again — no per-turn reminders. Real past transcripts where Clara got stuck or kept repeating that line become harness fixtures.

The unit is the matter: one thing Clara is stuck on for one customer. When stuck, Clara judges which path applies using reasonable defaults, never a hard-coded list. Hand-off: a person must act (show up, get on a call, sign, negotiate, calm someone down). The guest card is assigned to that person, Clara steps back, no nags. The customer hears only Clara's own follow-up line. Knowledge question: a policy, process or price Clara lacks. She asks, keeps serving the customer, and saves the answer to the knowledge base with who said it.

 Clara handles the customer
        │  stuck
        ▼
 ┌─ judge (defaults, not a list) ──────────────────────────────┐
 │ knowledge q.    → ask team ──► WAITING_ON_STAFF (one reminder) │
 │ hand-off        → assign card to person ──► HUMAN_OWNED     │
 └─────────────────────────────────────────────────────────────┘

 staff reply on WAITING_ON_STAFF, judged by meaning:
   answered        → relay to customer + save to KB  → RESOLVED
   has it          → thank once, stop nags           → HUMAN_OWNED
   question back   → answer in the STAFF thread      → WAITING_ON_STAFF
   declined        → tell customer Clara's own line  → RESOLVED
   out of office   → ask the next person in chain    → WAITING_ON_STAFF
   unrelated       → no transition, no re-ask

 HUMAN_OWNED  → back to Clara only when the customer writes again
 any state    → EXPIRED when the linked tour / appointment has passed

After a hand-off

• The human contacts the prospect directly, on their own channel: their own phone, or AppFolio's texting/email from the guest card.
• Clara's line stays open, but she stops answering that matter: a new prospect message gets forwarded to the owner ("they reached out again asking X, can you follow up?"), and the prospect is told the owner has it.
• Staff can still relay through Clara ("tell him 2 pm works" — she says it in her own voice to the prospect).
• It comes back to Clara when the owner says "done" / "back to you," or the subject record closes (tour happened, application submitted).

No staff typing as Clara, no new staff screen.

While waiting on staff

One reminder per matter, ever. If the prospect asks again, Clara tells them the team is still looking into it — she does not re-ask staff.

If the answer was already in the knowledge base or settings, Clara was never stuck; a case like that is a red harness case against her answering, fixed there, never routed.

Rules kept from earlier rulings: staff talk to Clara like a person, over email first, with no new staff screen. Clara keeps working while she waits. She never promises on a named person's behalf. Staff answers become property policy directly, with provenance. No review queues, no engineering flags.

• Staff memory: each staff person has one thread with Clara and a list of the matters open with them, so "moved it to 3" lands on the right matter without a tour number. Details
• Seeing the back-and-forth: each matter shows its owner and every event in order, with the staff messages inline, on the customer's conversation page. Read-only.

Temporal is the engine we already use to keep long-running processes, such as a booked tour, alive for days and wake them when something happens. The workflow stays alive after a hand-off, so while a person has the matter we still know who owns it and keep every event. This extends today's escalation-matter workflow rather than starting a new one, the same pattern the renewals process already uses.

Where the code lives: one directory holds the workflow, its events (signals), its timer and its steps (activities). The matter row in the database is written by the workflow, as a copy for the screens to read. Every entry point feeds the one workflow; nothing keeps its own copy of a decision (Fede's rule, 2026-09-28). Once the timer owns the reminder, the 9 AM reminder job goes away.

The two judgments (stuck, and what a staff reply means) are LLM calls to Claude. They run only when Clara is stuck or when staff reply, a few calls a day, so quality matters more than cost.

Judge model: decided 2026-09-28

The bar: 100% on the reproduced incidents, at least 95% on the rest, and zero decisions swallowed as questions.

Sonnet 5's one miss sent an application-process question to a person instead of treating it as a fact question, the safe direction.

The judge is not called from the live path until the hand-off step routes on its verdict; a compute-and-log-only mode was rejected as shadow mode.

Today's default for replies: Clara's email and text replies to prospects use Sonnet 5 (claude-sonnet-5, the drafting tier in model-tiers.ts, high effort); other turns use the general tier, Sonnet 4.6.

How we tune it

• Eval set: the 52 real cases plus the 24 staff-reply variations in scripts/coworker-harness. It runs on every PR that touches a judgment.
• Pass bar (proposed): 100% on the reproduced incidents, at least 95% on the rest, and zero cases where a hand-off swallowed a decision.
• Mutation control: a gutted judge (always "unrelated", always "hand off") must show red.
• Every new production bug becomes a case first (red), then the fix (green).

Prompt shape

1. The matter: who the customer is, what they asked, what Clara already said.
2. The staff text, verbatim.
3. The outcomes, each with a one-line definition: two for the stuck judge (knowledge question, hand-off), six for the staff-reply judge. Pick one with reasonable defaults, never a keyword list.

52 real cases where Clara asked for help: 26 written questions and 26 missed-call callbacks. Most are from Camellia in August; 3 are from Western Slope. Test runs are counted separately.

Why Clara asked (26 written)

What staff did (same 26)

Key numbers

The paths

Top 5 wrong cells

1. Facts she should have had get forwarded instead of answered (14 real).
2. No reply from staff: one fixed reminder, then a silent close; the customer is never told.
3. Customer writes again while waiting: every message forwarded, customer gets nothing.
4. "I've got it" or out-of-office is read as an answer or a question.
5. Missed calls: one page per call, no callback tracked (0 of 26).

The 10 most instructive real threads are saved, scrubbed, as harness fixtures.

The case. Kat texted Clara from her personal cell and Clara did not recognise her. On 9/20 someone entered Kat's work number (the office landline) in the team page's single phone field. The code treated that field as "replace": saving the work phone replaced her mobile and retired it. The landline receives texts but cannot reply.

The model: two labeled slots

• The work phone is used only for call routing — where a transfer rings — like Western Slope's office landline.
• The mobile is where Clara sends every notice and update, and the number staff text Clara from.
• Saving one number never retires the other.
• Clara texts staff at the mobile if there is one, otherwise the work phone.
• Recognition accepts both numbers as the same person, with full staff tools.
• Retiring a number is an explicit admin action, never a side effect of a save.

In storage terms: two live number records on the person, each labeled work or mobile; the existing "primary" flag means "text me here".

What exists today

PRs

No landline detection. Nothing beyond the two slots.

No conflict with Gera's portfolio model: both numbers live on the one person record in the company. Caveat: recognising her by an old, already-retired number company-wide needs a company-wide staff role.

Every row is one PR, one concern, about 300 lines or fewer, with a harness fixture and a mutation control (plant the bug back, the check goes red). Each phase starts when its dependencies are merged and proven. Bug fixes ship live everywhere; behavior changes ship dark behind a property setting, default off, and Fede turns them on.

Phase 0 — stop the bleeding

For Kat: "I called them" ends the reminders. Her questions get answers addressed to her. Asks about a past tour close on their own. The conversation page shows she replied and who owns the matter now.

Phase 1 — the two paths

For Kat: when a customer needs a person, the guest card lands on her name in AppFolio with one email, and Clara stops talking about it. She is never asked the same kind of question twice once she has answered it.

Phase 2 — prove it

The harness first pass (a results table, each case red/green on main) gates Fede's own QA as Kat; Fede does not test until that table is green.

For Kat: nothing changes until the replays and Fede's own run as Kat pass. Then she gets the Phase 1 behavior at Western Slope, with staff-driven relays reviewed until they are proven.

Phase 3 — staff memory

For Kat: she can go back and forth with Clara over several messages, like a coworker who remembers yesterday's conversation.

Phases 0 and 1 overlap; Phase 2 is gated by the corpus pass and Fede's QA run; Phase 3 waits for real multi-turn staff traffic.

A hand-off goes to a role, picked by the type of task, never to a hard-coded person. The company's Team page and its role dropdown are the only source of people and roles. There is no separate list of roles or people; Clara looks at the team and its roles and delegates from there. We ship opinionated defaults; a client can tweak them later.

We use only the roles the Team page has today: Property Manager, Leasing Agent, Company Admin. No new roles now. At Western Slope: Kat and Beverly are leasing agents (Kat does the showings, Beverly does computer work), Cheryl is the property manager, and Kat is the default person.

Routing matrix (our recommended defaults)

Typical property-management team

The long-term role list the design scales to. Rows marked "later" are future only; nothing is added to the dropdown now.

Chunks: the design is the whole matrix; we build it one module at a time. Chunk 1 is leasing only, which is what we are tuning now: with today's roles only: tour logistics, paperwork and knowledge → leasing agent; exceptions → property manager; anything else → the default person (Kat at Western Slope). Later chunks are renewals, maintenance and collections; each adds its rows to the same matrix and, if needed, its roles to the same dropdown.

How a client tweaks it: later, a section on the company settings page, working title "Human in the loop", with one small table: task type → role. People still come only from the Team page. Left alone, it uses our defaults. Defaults ship first; this section is not built now. It follows the building-then-company settings order in Gera's portfolio design: the company sets the matrix, and a building's own default person wins for that building. [superseded 2026-09-29, see decisions]

One naming note: these are job roles, separate from the access roles in Gera's design (org admin, property owner, PMS credential holder). The Team page dropdown mixes the two today (Company Admin sits next to Leasing Agent); they must stay distinct in the model.

Short answer: there is a simple, shared model, and ours already matches most of it. Two things differ: how often we remind, and how module-specific the matter is. (Research 2026-09-28.)

The common mental model

• One work item, one owner at a time. Frameworks pause a run, save its state, and resume it when a person's typed answer arrives: LangGraph, OpenAI Agents SDK, Microsoft Agent Framework, Temporal, the engine that keeps a long-running process such as a booked tour alive for days, Google ADK.
• Two different moves. "Pause and ask" keeps the case with the agent. "Hand off" moves it: the new owner "takes over the conversation" (OpenAI handoffs). Anthropic: agents "pause for human feedback at checkpoints or when encountering blockers" (Anthropic).
• Support vendors only hand off. Intercom Fin, Agentforce, Zendesk and Forethought pass the whole conversation to a person; none documents asking a teammate a question while the AI keeps serving. Our knowledge-question path is the framework "pause and ask" applied to staff.
• The hand-off carries the pre-work. Humans step in "only after the AI has finished essential pre-work" (Salesforce); the packet is history, summary, actions tried and next step (Forethought).
• After a hand-off the AI steps back and the work lands as a task on the right team: Funnel creates tasks for people "only when emotional intelligence is required"; EliseAI routes tasks by topic to specialized teams.
• "Resolved" and "handed off" are separate outcomes. Fin counts a resolution only when the customer confirms or goes quiet for 24 hours (Intercom); Ada's automated resolution excludes escalation (Ada).
• Human answers become knowledge. Decagon drafts content from "real-world resolutions from your human agents"; Intercom groups gaps that blocked resolution.
• Waits have a deadline, not a loop. Temporal waits for the signal with a timeout (Temporal); an acknowledgement "stops the policy from escalating" (PagerDuty).

One hand-off shape for every module

The matter is the same record in every module: module · subject record · task type · owner (role → person) · what the human gets · what the customer hears · when it returns to Clara. Only the subject record and the AppFolio surface change.

How often to remind

Repeating the same reminder backfires: acceptance "dropped by 30% for each additional reminder" (Ancker 2017). Incident tools notify once, then move to the next person after a timeout (PagerDuty); help desks remind before the deadline and escalate after it (Freshdesk). So: not three reminders. One ask, one reminder timed to the customer's deadline, then the next person, then an honest line to the customer.

What this means for this design

1. Keep the two paths, one owner per matter, and "I've got it" as the acknowledgement that stops reminders. Everyone above works this way.
2. Change "nag ≤3" to one reminder at the customer's deadline, then the next person in the role, then the customer's line. — adopted 2026-09-28.
3. Change the matter to carry module and subject record now, and make the hand-off email a fixed packet (who, what they want, what Clara tried, the one action, link to the record). Renewals, maintenance and collections then reuse the engine by adding rows to the routing matrix. We keep saving staff answers straight to knowledge with who said it; vendors gate that with an approval step, which we reject by rule. — adopted 2026-09-28.

We built pieces of this loop several times: turnover texting for property managers, the promise ledger, the Camellia property-manager experiment, a reminder system for property-manager tasks, and a coworker test run. None became the product, but three of them solved the hard part, knowing which matter a staff message is about.

What we learned

• Follow the message Clara just sent, not the phone number. Turnover texting broke when a manager's phone also matched a tenant; replying to Clara's last text fixed it.
• Two open matters means one short question, never a guess. "Which one: Steven at 3 or Ana at 5?"
• Guessing from "the sender's latest open matter" was wrong often enough that we deleted it. Email reply headers are exact; keep them.
• A promise with no owner dies. The promise ledger found most broken promises had no tracked question behind them.
• One engaged person beats one reluctant one. The Camellia version was built for a single property manager and did not stick; Western Slope's team replies.

Staff memory

Today Clara knows a staff member's name and role, nothing else. Their questions and answers are stored inside the customer's conversation (the cause of Kat's reply landing in Steven's thread). No setting says "text me, don't email", and nothing lists the matters open with one person. The engine gets a thread per staff person, a list of their open matters kept current by the matter workflow, and preferences that only the person or the Team page can change.

Seeing the back-and-forth

Today staff messages show as collapsed rows on the customer's conversation, labelled by who wrote them only. There is no matter page, and the workflow keeps counts, not events. Needed: an ordered event list in the workflow, one matter view with owner and timeline, and a "with Clara" list on each person's Team page entry.

Fede, 2026-09-29: "I think we should remove all the switches and just have it on" and "there shouldn't be lines where it's not on." Every on/off switch on the staff loop has been deleted (all merged 2026-09-29) so the behaviour is simply on everywhere; only the coworker-mode switch remains, pending Fede's yes/hold.

Also: the default hand-off person is now one person per company (an organization setting), merged in #13547.

Proof: after deploy, the Willows dry run on Fede's cell (staff text loop end to end), a Temporal count showing escalation matters running, and one real-property memory-ack message id with a clean Sentry window.

Willows staff email dry run (2026-09-29, 3:20 PM; completed 2026-09-30)

The loop is proven end to end at Willows as of 2026-09-30. The staff mailbox used is our own Gmail test inbox, admitted by #13936.

Found by the dry run:

• The tenant follow-up text relayed the staff email raw (greeting, sign-off, quoted line). Fix in flight as a bug PR.
• Both Clara emails landed in Gmail spam at our own domain despite passing SPF/DKIM/DMARC. Issue to be filed.
• Thank-you wording "I'll remember that Pet Deposit Refund Terms." folds into the first fix above.

Fede (2026-09-28): only turning on at a customer needs his call; everything else is decided on the recommendation.

1. Who gets the guest card on a hand-off? (a) the property's escalation owner · (b) whoever replies "I've got it" · (c) the default person at escalation time, re-assigned to whoever says they have it — Decided by Fede 2026-09-28: the hand-off goes to a role picked by task type, filled by the client's people; start with Kat as primary at Western Slope; whoever says "I've got it" takes the card. See Who gets the hand-off.
2. What the customer hears once a person owns it. (a) nothing · (b) one line from Clara: "I've passed this to the team, they'll reach out" (no name) · (c) Clara checks back after a day — Decided by Fede 2026-09-28: one line from Clara, no name; repeat asks get "the team is still looking into it"
3. When does a human-owned matter come back to Clara? (a) only when the customer writes again · (b) also after some quiet days, with one check-in · (c) never — Decided by Fede 2026-09-28: back to Clara when the owner says so or the subject closes; meanwhile new prospect messages are forwarded to the owner
4. Scope now. (a) Phase 0 live today, Phase 1 dark right after, Phase 2 before any turn-on · (b) Phase 0 only, rest later · (c) go straight to Phase 3 — Decided 2026-09-28: (a) Phase 0 live, Phase 1 dark, Phase 2 before turn-on — decided on the recommendation
5. Where the default hand-off person lives. (a) a property setting on the property page · (b) one person per company · (c) reuse the escalation email chain — Decided 2026-09-28: (a) property setting — decided on the recommendation [superseded 2026-09-29, see decisions]
6. How staff map to AppFolio users. (a) matched automatically from the AppFolio user list by email · (b) typed per person on the property page — Decided 2026-09-28: (a) matched by email from the AppFolio user list — decided on the recommendation
7. Turning Phase 1 on at Western Slope after Phase 2 passes: yes, with the staff-reply review gate on until baked · hold — Decided 2026-09-28: Fede's call, asked once the harness passes [superseded 2026-09-29, see decisions]
8. Judge model: Decided: Sonnet 5.5, by benchmark. See The judge.
9. Kat's numbers: work phone = the office landline, mobile = her cell, Clara texts the cell — recommend yes · hold — Decided by Fede 2026-09-28: landline = call routing only; mobile = notices, updates and texting Clara.
10. Barry: wait for Kat's answer; if a real prospect, move his contact onto that card and take Kat's number off it — Decided by Fede 2026-09-28: move the tour to the 'Barry Unknown' card Kat made, send him the reminder, add the showing in AppFolio, give Kat her number back; in progress
11. Reminders: one, not three — decided by Fede 2026-09-28; setting later if a client asks.
12. Hand-off packet + one generic engine across modules — decided by Fede 2026-09-28.
13. Engine runtime = one Temporal workflow per matter — decided by Fede 2026-09-28. It extends today's escalation-matter workflow; see Architecture.
14. After a hand-off the human uses their own channel; Clara goes quiet on that matter and forwards repeat contacts — decided by Fede 2026-09-28.
15. Escalation is about a matter, never the person. Clara keeps helping with everything else and never volunteers the pending matter unless the customer does. "Still looking into it" only when the customer re-asks about that same matter and it's truly still open — once staff answered, the tour moved, or the topic is over, she never mentions it again; no per-turn reminders. Real transcripts where Clara got stuck or over-repeated become harness fixtures — decided by Fede 2026-09-28.
16. 2026-09-29 — No turn-on: the coworker loop is an improvement to a live behaviour. Fede, 2026-09-29: Clara already hands prospects to Western Slope staff today, so the staff loop improves a live path; there is no activation and no launch switch ('there shouldn't be lines where it's not on'). The Human in the loop company switch (#13211) is removed. The default hand-off person moves from the property page to the organization (#13232 placed it per property without approval; hand-off destinations are org-level). Proof is the Willows staff dry run on Fede's cell; then PR-D ships live everywhere. Decision 7 (turn Phase 1 on at WS) is withdrawn.

• Keyword or phrase lists that read staff intent, in any path (including the review-command phrase list, which gets the same treatment later).
• Per-case hard-coding of which situations are hand-offs.
• Any new staff screen or button. Staff talk to Clara by email and text.
• Property-manager review queues for escalations or hand-offs.
• Engineering feature flags. Only property or company settings, default off.

Why: Situs 2026-10-27: a staff note about an applicant was reworded and texted to the applicant; RCA: leak audit §Situs. Fede: 'we need to rewrite this'; checked with the Clara Refactor session (one shared reader, no rewrite layer, unsure never goes outward).

Checked against the vision (2026-10-27)

The Clara Refactor session and the Clara Coworker Vision session both reviewed this. Verdict: right shape, no conflict with the master page (/a/clara-coworker-loop-v3-2026-10: #turn-rebuilt, #gates, #inv-interfaces, #idea). Five changes, now part of the design:

1. The reader never sends. It returns a reading only: outcome, facts with ids, what is still open, and why. The existing doors act on it: handled, question, note and unclear become 'stay silent, with the reason' plus a matter state; an answer becomes a normal Clara reply. Any word to staff goes through the one team-ask path.
2. Staff facts enter Clara's reply as fact rows with ids, not a label. The writer declares which fact ids it used, and the facts check blocks any sentence to the person that traces to nothing. That is what stops 'I've already reviewed the packet' next time.
3. Today's claim checks on the answer path stay until the facts check exists, and are deleted in that PR, not in PR 2.
4. On handled or answer, Clara's own earlier held draft on the same matter is withdrawn. At Situs the held draft stayed approvable after the team had already answered.
5. The note back to staff is also a claim: on handled and note it says 'closed, nothing sent to the applicant'; on answer it says 'reply held for approval'. Never 'I've let her know'.

The picture

BEFORE  staff writes ──► phrase list ── no match + 15 chars = "the answer" ──►
        rewrite step ("as if you looked it up yourself") ──► person   (on failure: staff words sent verbatim)

AFTER   staff writes ──► ONE READER (model judge) ──► what is this?
          answer for the person ──► Clara's normal reply writer, staff fact labeled ──► Supervised hold ──► person
          staff handled it      ──► close as staff-owned, thank staff ──────────► person gets nothing
          question for Clara    ──► Clara answers staff from the records ───────► person gets nothing
          note / policy         ──► record it (policy is remembered) ───────────► person gets nothing
          unclear, or any error ──► one short line to staff, team-ask hold ─────► person gets nothing

1. The reader already exists

On Sep 29 we built a model judge (Sonnet 5.5, thinking on). It scored 64 of 64 on its own test set: 18 real incidents, the rest synthetic. The phrase list scored 53. It never reached main. We finish it rather than write a second one.

Reused: the model call, the model choice, the 64-case test set and runner. Missing: five outcomes, one shared door, the one-line staff ask, and the hand-off to Clara's reply writer.

2. What each outcome does

Answers take the path team notes already use, minus its "news you looked into yourself" line. Clara credits "our team" for staff actions, never names them. Writer fails: nothing sent, engineering alerted. Model error: three retries, then unclear. A typed out-of-office reads as a note. Staff get at most one unclear ask per matter.

Deleted: the phrase list, the rewrite step, the verbatim backup, the numbers-only check, once the facts check exists (not in PR 2).

3. Proof

• Test set: the 64 cases re-labeled to five outcomes and re-run (the old score doesn't carry over), plus 21 leak cases and 115 real replies, scrubbed, held out from the prompt. Two model voters label; the session reads disagreements. Subscription only.
• Bar: zero wrong sends. Today fails 15 of 21 leak cases. Planting the old code back must turn it red.
• Rungs: (1) read-only replay of every real staff reply. (2) Willows live: a real decision request, three test-mailbox replies. "I just responded to her" closes it, nothing sent; a real answer makes a held Clara reply; a vague one sends staff one line. Record ids in the PR. A fix: no switch, live on merge.

4. PR cut

1. Lift the judge to main + eval, with five outcomes and fail-closed. Nothing calls it. Proves the score.
2. Email replies and team notes go through it; old code deleted; withdraws the pending held draft; staff ack states what the record shows. Proves the Willows run.

Slack held-card replies keep today's grammar (Fede: no). The Clara Refactor session points in-thread teammate messages at the same door.

5. For Fede

• Fede 2026-10-27: no band-aid, no stopgap; the phrase-list patch (#22863) is closed and the rewrite ships straight through.

Engineering notes

• Source: #13384 merged into feat/staff-loop-v2 (not main): src/lib/domain/escalation/staff-loop/reply-meaning.ts (judgeStaffReply, JUDGE_STAFF_REPLY_MODEL = claude-sonnet-5-5), judgment.ts (callJudge), types.ts. Eval: scripts/coworker-harness/judge-staff-reply-benchmark.ts, fixtures/judge-staff-reply/{cases,labels}.json, results judge-staff-reply-benchmark-2026-09-28.md. Lift only these files, not the rest of the branch (routing, settings, team).
• PR 1 changes to the judge: bucket becomes answer | handled | question | note | unclear, plus facts[], stillOpen and followingUp. Prompt rule 5 flips to "unsure → unclear". The classifyStaffReply fallback becomes unclear; answer with no facts reads as unclear. Input adds person name/role, last ~6 turns, author, channel. The door is readStaffInput(), shaped like should-speak.ts, on the master page shared-door table. Folds in #13289 (held-out set), #13495 (zero-tolerance false-relay counter), #13496 (production timeout) and #13499 (unparseable vs unavailable). #13494 (Temporal activity wiring) is superseded by a direct call; close it with a pointer.
• PR 2 callers: releaseMatterOnStaffReply (replaces classifyStaffReply, the text OOO check and isUnrelatedStaffReply; header auto-reply, identity, retraction and dedupe stay) and ingestTeamReply ask (no check at all today). Answer path: relayTeamNoteAnswer → runTeamAnswerTurnUnderSupervisedHold(runTeamAnswerTurn). Rewrite buildTeamAnswerSystemContext and drop answeredByFirstName from it. Delete relayAnswerToPerson, buildStaffAnswerRelay/buildStaffUpdateRelay, relay-rephrase.ts, staff-reply-intent.ts and its tests, and the relay-site passesFabricationGuard. The staff_reply label leaves the relay. Repoint unmute-on-resolve.ts and gate-registry.ts. rememberStaffAnswerInThread runs only on answer/note; distillStaffAnswer's guard stays. Unclear asks go through #22866's team-ask hold.
• Leak cases: origin/harness/staff-reply-relay-leak. Scrub: scripts/promise-harness/scrub.ts. Willows recipe: scratchpad willows-proof-recipe.md (never a fede+ address). Related: #22863 stopgap, #22865 relay hold, #17641 (courtesy reply relayed) closes with PR 2.