@paigy/harness 0.3.16 → 0.3.28

package/README.md

@@ -22,15 +22,14 @@ without a desktop app. Two things need a process that actually owns the agent:
 The point isn't notifications, it's a conversation with an agent that happens to be
 running on your laptop. Both directions close (`paigy/conversation.ts`):
 
-- **Answering.** The agent's turn ends on a question → it banners → your reply goes
-  straight back into stdin as the next turn. Without this the loop is one-directional
-  and dies at the first idle.
-- **Initiating.** You say something unprompted from your phone → it arrives as a
-  `request` on the thread → same stdin. You never have to wait to be asked.
-
-Both ride the same thread, so the phone shows one conversation. `endsWithQuestion` is
-what decides "the agent is waiting on you" versus "here's your history", and it is
-deliberately conservative: a false positive buzzes someone who was never asked anything.
+- **Answering.** The agent asks through Paigy's `contact` — its only channel to you; the
+  harness never relays its terminal output (`companion.md` Part 4, one channel) → your
+  reply lands on its Goal and goes straight back into stdin as the next turn. Without this
+  the loop is one-directional and dies at the first idle.
+- **Initiating.** You say something unprompted from your phone → it arrives on the agent's
+  Goal → same stdin. You never have to wait to be asked. A Claude agent in the middle of a task
+  sees your words right after its next tool call, and gets them again as its next turn
+  (`companion.md` Part 4, words reach a running turn).
 
 Answers are read out of whatever shape they arrive in (`spokenText`) — a tapped option,
 a spoken sentence, a whole call log — because the words are what the agent needs, not
@@ -63,10 +62,8 @@ silent history from "answer me now" is `urgency`, not a second store:
 
 | Event | Level | Why |
 | --- | --- | --- |
-| a turn (agent or user) | `inbox` | lands, never buzzes; searchable, handoff-able history |
 | a blocked action | `banner` | claims attention; escalates on its own if unanswered |
 | a blocked **destructive** action | `call` | `rm -rf` doesn't get to wait for the escalation ladder |
-| a turn that **asked you something** | `banner` | a question filed silently is a conversation that dies |
 | a turn that failed | `push` | worth knowing soon, not worth a sound |
 | our own parse failure | — | not on the rail at all; it's our problem, not yours |
 
@@ -162,7 +159,7 @@ src/harness/   events.ts   the neutral HarnessEvent the driver produces
                catalog.ts  which harnesses exist, detection, auth probes, installs
                session.ts  spawn, line-split, lifecycle — the only impure file here
 src/paigy/     level.ts        event → NotifyLevel
-               bridge.ts       mirror turns, ask permissions/questions, setup nudges
+               bridge.ts       permission asks, cannot-work notices, the turn's end as Goal progress
                conversation.ts the round trip — your words into a running agent's stdin
 src/triage/    evidence.ts the deterministic signals; judge.ts the one model boundary
                verdict.ts  the prompt + its defensive parser; triage.ts the sweep itself
@@ -227,7 +224,9 @@ curl -fsSL https://paigy.ai/install | sh
 
 Installs the npm CLI (one self-contained file — the workspace libs are bundled) and
 runs `paigy-harness setup`: QR-pairs the machine, hatches each detected agent's
-identity (no codes), registers the MCP + statusline, grants a workspace, installs
+identity (no codes), registers the Paigy MCP in every harness it runs (`MCP_WIRES` —
+Claude Code, Codex, Antigravity: an agent's only channel to you) + the statusline,
+grants a workspace, installs
 the host service. `paigy-harness service` installs a
 macOS launchd agent so hosting survives reboots — the host loop IS the service,
 launchd just keeps it alive (the old "no daemon" note was about the WAKE channel,
@@ -292,7 +291,9 @@ LAST, after the hooks are gone.
 - **Protocol churn is the standing risk.** Neither `stream-json` nor ACP adapter
   behavior is a stability contract. Every driver fails soft by design: an unrecognized
   frame is skipped, never fatal. If mirroring goes quiet after a CLI update, re-verify
-  the frame names in the driver doc comments first.
+  the frame names in the driver doc comments first. An adapter can also leave a prompt
+  unanswered for good (claude-agent-acp#1145); the driver cancels one after a long quiet
+  with no tool running (`companion.md` Part 4, one way in).
 - **Auth probes are vendor commands** (`claude auth status`, `codex login status`) and
   can drift with CLI releases; a probe failure reads as "needs login", so drift shows
   up as a nagging hint, not a broken start.