pi-cohort 5.3.4 → 6.0.1

package/CHANGELOG.md

@@ -1,6 +1,20 @@
 # Changelog
 
-## [Unreleased]
+## [6.0.1] - 2026-09-07
+
+### Fixed
+
+- `getFinalOutput` no longer truncates a multi-block assistant reply to its last text block; it now joins all non-empty text blocks with `\n`. Previously a `BLOCKED:` line in an earlier block was dropped, so the `BLOCKED:` classifier misread a blocked reply as successful (or a completed reply whose trailing block happened to start with `BLOCKED:` as failed).
+
+## [6.0.0] - 2026-09-07
+
+### Removed
+
+- **BREAKING:** Removed the pi-intercom integration: bridge, `intercomBridge` config, `intercom`/`contact_supervisor` tools, `notifyChannels: ["intercom"]`, intercom result/receipt delivery, doctor section, and foreground detach lifecycle. Stale config keys are ignored. ([#11](https://github.com/jjuraszek/pi-cohort/issues/11))
+
+### Changed
+
+- **BREAKING:** Unapproved decisions now use the `BLOCKED:` result contract; `resume` on a running child errors, while finished, failed, and paused siblings remain revivable; foreground abort terminates the child normally. Proposed version bump: 5.3.1 -> 6.0.0. ([#11](https://github.com/jjuraszek/pi-cohort/issues/11))
 
 ## [5.3.4] - 2026-09-07
 

package/README.md

@@ -121,7 +121,6 @@ Parent extension CLI flags (e.g. pi-lens's `--no-autofix`) are forwarded into sp
 
 Optional companions:
 
-- [pi-intercom](https://github.com/jjuraszek/pi-intercom) - lets a blocked child ask the parent a question instead of guessing. [doc/skills-and-companions.md](doc/skills-and-companions.md#optional-pi-intercom-companion)
 - [pi-essentials](https://github.com/jjuraszek/pi-essentials) - lets `context-builder` read referenced URLs. [doc/skills-and-companions.md](doc/skills-and-companions.md#optional-pi-essentials-companion)
 
 ## Deeper reference

package/agents/context-builder.md

@@ -1,7 +1,7 @@
 ---
 name: context-builder
 description: Analyzes requirements and codebase, generates context and meta-prompt
-tools: read, grep, find, ls, bash, write, fetch, intercom
+tools: read, grep, find, ls, bash, write, fetch
 thinking: medium
 systemPromptMode: replace
 inheritProjectContext: true
@@ -36,10 +36,10 @@ When running in a chain, expect to generate two files in the chain directory:
 - hard constraints: true invariants only, such as no edits for review-only work or escalation for unapproved decisions
 - suggested approach: concise direction without over-specifying every step
 - validation: targeted checks to run, or the next-best check if validation is unavailable
-- stop/escalation rules: when to ask via `intercom`, when enough evidence is enough, and when to stop
+- stop rules: when enough evidence is enough and when to stop
 - resolved questions and assumptions
 
 The goal is to hand the planner or another role subagent exactly enough code and requirement context to act without rediscovering the same ground. Write the meta-prompt as a compact contract: outcome, evidence, constraints, validation, and output expectations. Avoid long procedural scripts unless each step is a real requirement.
 
-## Supervisor coordination
-If runtime bridge instructions identify a safe supervisor target and you are blocked or need a decision, use `contact_supervisor` with `reason: "need_decision"` and wait for the reply. Use `reason: "progress_update"` only for meaningful progress or unexpected discoveries that change the plan. Do not send routine completion handoffs; return the completed context normally.
+## Decision blockers
+If an unapproved decision is required to continue safely, stop: begin your reply `BLOCKED: <decision needed>`, then `Done: <complete>` and `Remaining: <left>`; no heading, bold, list marker, or code fence; do not guess or wait for a reply.

package/agents/delegate.md

@@ -3,10 +3,10 @@ name: delegate
 description: Lightweight subagent that inherits the parent model with no default reads
 systemPromptMode: append
 inheritProjectContext: true
-tools: read, grep, find, ls, bash, edit, write, contact_supervisor
+tools: read, grep, find, ls, bash, edit, write
 inheritSkills: false
 ---
 
 You are a delegated agent. Execute the assigned task using the provided tools. Be direct, efficient, and keep the response focused on the requested work.
 
-If runtime bridge instructions identify a safe supervisor target and you are blocked or need a decision, use `contact_supervisor` with `reason: "need_decision"` and stay alive for the reply. Use `reason: "progress_update"` only for meaningful progress or unexpected discoveries that change the plan. Do not send routine completion handoffs; return normally when no coordination is needed.
+If an unapproved decision is required to continue safely, stop: begin your reply `BLOCKED: <decision needed>`, then `Done: <complete>` and `Remaining: <left>`; no heading, bold, list marker, or code fence; do not guess or wait for a reply.

package/agents/monitor.md

@@ -16,11 +16,10 @@ Loop:
 1. Record your start time. Run the first check immediately, before any sleep.
 2. Each cycle: check the target is alive, collect progress (new log lines, counts, phases, best-effort ETA), and compose a one-line delta vs the previous cycle.
 3. Append the delta with a timestamp to the trail.
-4. If contact_supervisor is available, send the delta with reason "progress_update".
-5. Sleep the cadence interval in chunks of <= 5 minutes, then repeat.
+4. Sleep the cadence interval in chunks of <= 5 minutes, then repeat.
 
 Cadence: every 15 minutes unless the task sets another interval.
 
-Stall: no growth in the watched log and no change in status.json lastUpdate since the previous cycle. Judge stall only by the signals your target has; a signal that does not exist never counts as change. Report it as "no output for <interval>, possible stall". After two consecutive silent cycles, escalate with contact_supervisor reason "need_decision". Never report "still working" without evidence.
+Stall: no growth in the watched log and no change in status.json lastUpdate since the previous cycle. Judge stall only by the signals your target has; a signal that does not exist never counts as change. Record "no output for <interval>, possible stall" in the trail only. Never report "still working" without evidence.
 
-Exit: when the target reaches a terminal state, send a final summary and end - the summary is your run result. Stop 24h after your recorded start time even if the target lives. Without contact_supervisor, the trail and final summary are the record; behave identically otherwise.
+Exit: when the target reaches a terminal state, send a final summary and end - the summary is your run result. Stop 24h after your recorded start time even if the target lives. The trail and final summary are the record.

package/agents/oracle.md

@@ -1,7 +1,7 @@
 ---
 name: oracle
 description: High-context decision-consistency oracle that protects inherited state and prevents drift
-tools: read, grep, find, ls, bash, intercom
+tools: read, grep, find, ls, bash
 thinking: high
 systemPromptMode: replace
 inheritProjectContext: true
@@ -15,9 +15,7 @@ Your primary job is to prevent the main agent from making hidden, conflicting, o
 
 Before you do anything else, reconstruct the key inherited decisions, constraints, and open questions from the forked conversation, codebase state, and task. Those decisions form your baseline contract. Preserve them unless there is strong evidence they should be overturned.
 
-If you need clarification from the main agent and runtime bridge instructions are present, use `contact_supervisor` with `reason: "need_decision"` and wait for the reply. Use `reason: "progress_update"` only for concise updates when blocked, explicitly asked for progress, or when a recommendation or concern would benefit from immediate discussion. Keep coordination traffic tight and purposeful. Do not narrate your whole review through `contact_supervisor`.
-
-Do not send routine completion handoffs. If no coordination is needed, return the final oracle recommendation normally. Fall back to generic `intercom` only if `contact_supervisor` is unavailable and the runtime bridge instructions identify a safe target.
+If an unapproved decision is required to continue safely, stop: begin your reply `BLOCKED: <decision needed>`, then `Done: <complete>` and `Remaining: <left>`; no heading, bold, list marker, or code fence; do not guess or wait for a reply.
 
 Core responsibilities:
 - reconstruct inherited decisions, constraints, and open questions from the context
@@ -38,9 +36,7 @@ What you do not do by default:
 
 Working rules:
 - Use `bash` only for inspection, verification, or read-only analysis.
-- If information is missing and it matters, ask the main agent with `contact_supervisor` and `reason: "need_decision"` instead of guessing.
-- If the answer depends on a decision the main agent has not made yet, stop and ask with `contact_supervisor` before continuing.
-- When bridge instructions are present, send concise coordination messages only when a recommendation, concern, or question would benefit from immediate discussion instead of waiting silently until the final return.
+- If information is missing or depends on an unmade decision, follow the blocker rule.
 - Prefer narrow, specific corrections to the current path over rewriting the whole plan.
 
 Your output should follow this shape. If no executor handoff is warranted, say so plainly.

package/agents/planner.md

@@ -1,7 +1,7 @@
 ---
 name: planner
 description: Creates implementation plans from context and requirements
-tools: read, grep, find, ls, write, intercom
+tools: read, grep, find, ls, write
 thinking: high
 systemPromptMode: replace
 inheritProjectContext: true
@@ -51,5 +51,5 @@ Anything likely to go wrong, need clarification, or need careful verification.
 
 Keep the plan concrete. Another agent should be able to execute it without guessing what you meant.
 
-## Supervisor coordination
-If runtime bridge instructions identify a safe supervisor target and you are blocked or need a decision, use `contact_supervisor` with `reason: "need_decision"` and wait for the reply. Use `reason: "progress_update"` only for meaningful progress or unexpected discoveries that change the plan. Do not send routine completion handoffs; return the completed plan normally.
+## Decision blockers
+If an unapproved decision is required to continue safely, stop: begin your reply `BLOCKED: <decision needed>`, then `Done: <complete>` and `Remaining: <left>`; no heading, bold, list marker, or code fence; do not guess or wait for a reply.

package/agents/reviewer.md

@@ -1,7 +1,7 @@
 ---
 name: reviewer
 description: Versatile review specialist for code diffs, plans, proposed solutions, codebase health, and PR/issue validation
-tools: read, grep, find, ls, bash, edit, write, intercom
+tools: read, grep, find, ls, bash, edit, write
 thinking: high
 systemPromptMode: replace
 inheritProjectContext: true
@@ -72,10 +72,8 @@ When asked to review for over-engineering, bloat, or "what can we delete", run a
 - If you are asked to maintain progress, record what you checked and what you found.
 - If review-only or no-edit instructions conflict with progress-writing instructions, review-only/no-edit wins. Do not write `progress.md`; mention the conflict in your final review only if it matters.
 
-## Supervisor coordination
-If runtime bridge instructions identify a safe supervisor target and you are blocked or need a decision, use `contact_supervisor` with `reason: "need_decision"` and wait for the reply. Do not ask for clarification when the only conflict is review-only/no-edit versus progress-writing; no-edit wins. Use `reason: "progress_update"` only for meaningful progress or unexpected discoveries that change the review plan. Do not send routine completion handoffs; return the completed review normally.
-
-Fall back to generic `intercom` only if `contact_supervisor` is unavailable and the runtime bridge instructions identify a safe target. If no safe target is discoverable, do not guess.
+## Decision blockers
+If an unapproved decision is required to continue safely, stop: begin your reply `BLOCKED: <decision needed>`, then `Done: <complete>` and `Remaining: <left>`; no heading, bold, list marker, or code fence; do not guess or wait for a reply. Do not ask for clarification when the only conflict is review-only/no-edit versus progress-writing; no-edit wins.
 
 ## Review output format
 Structure your findings clearly:

package/agents/scout.md

@@ -1,7 +1,7 @@
 ---
 name: scout
 description: Fast codebase recon that returns compressed context for handoff
-tools: read, grep, find, ls, bash, write, intercom
+tools: read, grep, find, ls, bash, write
 thinking: low
 systemPromptMode: replace
 inheritProjectContext: true
@@ -46,5 +46,5 @@ Explain how the pieces connect.
 ## Start Here
 Name the first file another agent should open and why.
 
-## Supervisor coordination
-If runtime bridge instructions identify a safe supervisor target and you are blocked or need a decision, use `contact_supervisor` with `reason: "need_decision"` and wait for the reply. Use `reason: "progress_update"` only for meaningful progress or unexpected discoveries that change the plan. Do not send routine completion handoffs; return the completed scout findings normally.
+## Decision blockers
+If an unapproved decision is required to continue safely, stop: begin your reply `BLOCKED: <decision needed>`, then `Done: <complete>` and `Remaining: <left>`; no heading, bold, list marker, or code fence; do not guess or wait for a reply.

package/agents/worker.md

@@ -5,7 +5,7 @@ thinking: high
 systemPromptMode: replace
 inheritProjectContext: true
 inheritSkills: false
-tools: read, grep, find, ls, bash, edit, write, contact_supervisor
+tools: read, grep, find, ls, bash, edit, write
 defaultContext: fork
 defaultReads: context.md, plan.md
 defaultProgress: true
@@ -19,7 +19,7 @@ Use the provided tools directly. First understand the inherited context, supplie
 
 If the task is framed as an approved direction, oracle handoff, or execution plan, treat that direction as the contract. Validate it against the actual code, but do not silently make new product, architecture, or scope decisions.
 
-If the implementation reveals a decision that was not approved and is required to continue safely, pause and escalate through the live coordination channel. If runtime bridge instructions are present, use them as the source of truth for which supervisor session to contact and how to coordinate. Use `contact_supervisor` with `reason: "need_decision"` when a new decision is needed, and stay alive to receive the reply before continuing. Use `reason: "progress_update"` only for concise non-blocking progress updates when that extra coordination is helpful or explicitly requested. Fall back to generic `intercom` only if `contact_supervisor` is unavailable. Do not finish your final response with a question that requires the supervisor to choose before you can continue.
+If an unapproved decision is required to continue safely, stop: begin your reply `BLOCKED: <decision needed>`, then `Done: <complete>` and `Remaining: <left>`; no heading, bold, list marker, or code fence; do not guess or wait for a reply.
 
 Default responsibilities:
 - validate the task or approved direction against the actual code
@@ -47,10 +47,7 @@ Working rules:
 - Mark a deliberate shortcut with a comment naming the ceiling and the upgrade path when the limit is non-obvious.
 - Use `bash` for inspection, validation, and relevant tests.
 - If there is supplied context or a plan, read it first.
-- If implementation reveals a gap in the approved direction, pause and escalate with `contact_supervisor` and `reason: "need_decision"` instead of silently patching around it with an implicit decision.
-- If implementation reveals an unapproved product or architecture choice, use `contact_supervisor` with `reason: "need_decision"` and wait for the reply instead of deciding it yourself or returning a final choose-one answer.
-- If your delegated task expects code or file edits and you have not made those edits, do not return a success summary. Make the edits, contact the supervisor if blocked, or explicitly report that no edits were made.
-- If you send a blocked/progress update through `contact_supervisor`, keep it short and still return the full structured task result normally.
+- If your delegated task expects code or file edits and you have not made those edits, do not return a success summary. Make the edits or explicitly report that no edits were made.
 - Do not send routine completion handoffs. Return the completed implementation summary normally when no coordination is needed.
 
 When running in a chain, expect instructions about:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-cohort",
-  "version": "5.3.4",
+  "version": "6.0.1",
   "description": "Delegate Pi work to focused child agents: code review, scouting, implementation, parallel audits, saved chains, and background jobs.",
   "author": "Jacek Juraszek",
   "license": "MIT",

package/skills/pi-cohort/SKILL.md

@@ -2,7 +2,7 @@
 name: pi-cohort
 description: |
   Delegate work to builtin or custom subagents with single-agent, chain,
-  parallel, async, forked-context, and intercom-coordinated workflows. Use
+  parallel, async, and forked-context workflows. Use
   for advisory review, implementation handoffs, and multi-step tasks where a
   single agent should stay in control while other agents contribute context,
   planning, or execution.
@@ -33,7 +33,7 @@ Humans often use the slash-command layer instead:
 - `/chain` — launch a chain of steps
 - `/parallel` — launch top-level parallel tasks
 - `/run-chain` — launch a saved `.chain.md` or `.chain.json` workflow
-- `/cohort-doctor` — diagnose setup, discovery, async paths, and intercom bridge state
+- `/cohort-doctor` — diagnose setup, discovery, and async paths
 
 Prefer the tool when you are writing agent logic. Prefer the slash commands when
 you are guiding a human through an interactive flow.
@@ -147,11 +147,11 @@ and user/project agents override builtins with the same name.
 |-------|---------|-------|------------------------|
 | `scout` | Fast codebase recon | inherits default | Writes `context.md` handoff material |
 | `planner` | Creates implementation plans | inherits default | Writes `plan.md` |
-| `worker` | Implementation and approved oracle handoffs | inherits default | Single-writer implementation with decision escalation |
+| `worker` | Implementation and approved oracle handoffs | inherits default | Single-writer implementation |
 | `reviewer` | Review-and-fix specialist | inherits default | Can edit/fix reviewed code |
 | `context-builder` | Requirements/codebase handoff builder | inherits default | Writes structured context files |
 | `delegate` | Lightweight generic delegate | inherits default | No fixed output; generic delegated work |
-| `oracle` | Decision-consistency advisory review | inherits default | Advisory review, intercom coordination |
+| `oracle` | Decision-consistency advisory review | inherits default | Advisory review |
 
 Builtin agents inherit the current Pi default model unless a run, user setting, or project setting overrides `model`. Override builtin defaults before copying full agent files when a small tweak is enough.
 
@@ -171,14 +171,14 @@ A strong subagent prompt usually includes:
 - **Goal**: the concrete outcome the child should produce.
 - **Context/evidence**: relevant plan paths, files, diffs, decisions, or user constraints already approved.
 - **Success criteria**: what must be true before the child can finish.
-- **Hard constraints**: true invariants only, such as no edits for review-only tasks, one writer thread, child must not run subagents unless it is an explicitly assigned `tools: subagent` fanout child, or escalation for unapproved decisions.
+- **Hard constraints**: true invariants only, such as no edits for review-only tasks, one writer thread, or child must not run subagents unless it is an explicitly assigned `tools: subagent` fanout child.
 - **Validation**: targeted checks to run, or the next-best check when validation is impossible.
 - **Output**: the expected summary shape, artifact path, or finding format.
-- **Stop rules**: when to ask via `intercom`, when to stop after enough evidence, and when not to keep searching.
+- **Stop rules**: when to stop after enough evidence, when not to keep searching, and when to report an unapproved decision.
 
 Avoid carrying over old prompt habits that over-specify every step. Use `must`, `always`, and `never` for real invariants; for judgment calls, give decision rules. For example, tell a reviewer to inspect the staged diff directly and report only evidence-backed findings, rather than prescribing every file or command. Tell a `context-builder` the retrieval budget: fetch the referenced sources, extract the strongest evidence, fetch again only when a required fact is missing, then stop.
 
-For implementation handoffs, name the approved scope and success criteria more clearly than the process. Good prompts say what to change, what not to change, where the evidence lives, how to validate, and when to escalate. They should not ask the child to create another subagent plan or continue the parent conversation.
+For implementation handoffs, name the approved scope and success criteria more clearly than the process. Good prompts say what to change, what not to change, where the evidence lives, how to validate, and which decisions are already approved. They should not ask the child to create another subagent plan or continue the parent conversation.
 
 Settings locations:
 - User scope: `~/.pi/agent/settings.json`
@@ -335,11 +335,11 @@ subagent({ action: "resume", id: "nested-run-id", message: "Continue this nested
 ```
 
 Resume behavior:
-- If an async child is still running and reachable, `resume` sends the follow-up to that live child over intercom.
-- If an async child has completed, `resume` revives it by starting a new async child from the persisted child session file.
-- Multi-child async runs require `index` unless only one running child is selectable.
+- A running child cannot be resumed: `Selected child is still active; wait for completion, then resume.`
+- A finished, failed, or paused child is revived by starting a new async child from its persisted child session file.
+- Multi-child async runs require `index` unless only one child is selectable. A finished sibling can be revived while another sibling is running.
 - Completed foreground single, parallel, and chain runs can also be revived by `index` while their run metadata remains in extension state.
-- Nested runs can be resumed by nested id when a live route or persisted nested session metadata is available.
+- Nested runs can be resumed by nested id when persisted nested session metadata is available; a running nested child errors with `Nested run <id> is still active; wait for completion, then resume.`
 - Revive starts a new child process from the old session context; it does not restart the same OS process.
 - If the chosen child has no persisted `.jsonl` session file, resume fails and reports that directly.
 
@@ -349,7 +349,7 @@ Use diagnostics when setup or child startup looks wrong:
 subagent({ action: "doctor" })
 ```
 
-Humans can use `/cohort-doctor` for the same read-only report. It checks runtime paths, discovery counts, async support, current session context, and intercom bridge state.
+Humans can use `/cohort-doctor` for the same read-only report. It checks runtime paths, discovery counts, async support, and current session context.
 
 Long-running job hygiene:
 
@@ -362,13 +362,12 @@ subagent({ agent: "worker", async: true, task: "<long job - emit progress lines
 subagent({ agent: "monitor", async: true, task: "Watch async run R at <D>. Report every 15m. Stop when it ends." })
 ```
 
-- Live 15m reports require the pi-intercom bridge; without it the monitor's trail and final summary are post-hoc records.
 
 ### Subagent control
 
 Subagent control is the runtime visibility and intervention layer for delegated runs. It is separate from lifecycle status. Lifecycle status says whether a child is `queued`, `running`, `paused`, `complete`, or `failed`. Activity reporting is factual: it tracks the last observed activity time and the current tool when known. It does not pretend to know that a child is truly stuck.
 
-Default behavior is intentionally conservative. When no activity has been observed past the configured threshold, the run emits a `needs_attention` control event. Foreground runs can push this as a `subagent:control-event` event, and async runs persist it to `events.jsonl` so the parent tracker can surface it without constant manual polling. Notification-worthy control events are also inserted into the visible transcript so both the user and the parent agent can see them, with a proactive hint plus concrete `nudge`, `status`, and `interrupt` options. Visible notifications fire once per child run and attention state.
+Default behavior is intentionally conservative. When no activity has been observed past the configured threshold, the run emits a `needs_attention` control event. Foreground runs can push this as a `subagent:control-event` event, and async runs persist it to `events.jsonl` so the parent tracker can surface it without constant manual polling. Notification-worthy control events are also inserted into the visible transcript so both the user and the parent agent can see them, with a proactive hint plus concrete `status` and `interrupt` options. Visible notifications fire once per child run and attention state.
 
 Use soft interrupt when a child is clearly blocked or drifting and the parent needs to regain control:
 
@@ -398,8 +397,6 @@ subagent({
 })
 ```
 
-If the run already has an active intercom bridge target, needs-attention notifications can also prepare a compact intercom ping for the orchestrator. When a child route is available, the ping tells the orchestrator which agent needs attention and includes the exact `intercom({ action: "send", to: "..." })` target for a nudge. Do not invent a target or ask the child to self-report when no bridge exists.
-
 ## Clarify TUI
 
 Single and parallel runs support a clarification TUI when you want to preview or
@@ -442,9 +439,8 @@ prefer a single-writer pattern instead.
 The intended oracle loop is:
 1. the main agent forks to `oracle`
 2. `oracle` reviews direction, drift, assumptions, and risks
-3. `oracle` can coordinate back through `contact_supervisor` when the bridge injects it
-4. the main agent decides what direction to approve
-5. only then should `worker` implement
+3. the main agent decides what direction to approve
+4. only then should `worker` implement
 
 ```typescript
 // Advisory review in a branched thread. Oracle defaults to forked context.
@@ -466,52 +462,6 @@ history as a baseline contract.
 
 Use `oracle` as a smart-friend escalation when the parent needs help with trajectory rather than diff inspection: architectural boundaries, model capability routing, merge conflicts, reviewer disagreement, context drift after long work, a worker about to invent a pattern, or fixes that require product/scope tradeoffs. Ask broad questions when the right concern is unclear, and let `oracle` point out missing context or files the parent should inspect before asking again. Keep `oracle` advisory unless it has been explicitly assigned the single writer role.
 
-## Subagent + Intercom Coordination
-
-`pi-cohort` works without `pi-intercom`. When `pi-intercom` is installed and enabled, the intercom bridge can automatically give child agents a private coordination channel back to the parent session.
-
-Most agents should not call generic `intercom` directly unless bridge instructions provide a target and `contact_supervisor` is unavailable. Do not invent a target. Prefer the tool from the injected bridge instructions.
-
-Use `contact_supervisor` with `reason: "need_decision"` when:
-- a subagent is blocked on a decision
-- a child needs clarification instead of guessing
-- an approval, product, API, or scope choice is required before continuing safely
-
-Do not use `contact_supervisor` just to resolve review-only/no-project-edit versus progress-writing or output-artifact instructions. The child must not modify project/source files, but returning findings through its normal response or configured output artifact is allowed unless the parent explicitly set `output: false`.
-
-Use `contact_supervisor` with `reason: "progress_update"` when:
-- a child is explicitly asked for progress
-- a meaningful discovery changes the plan
-- a long-running child needs to report a blocked/progress checkpoint without waiting for normal tool return flow
-
-Message conventions:
-- `reason: "need_decision"` waits for the parent reply and returns it to the child.
-- `reason: "progress_update"` is non-blocking and should stay concise.
-- Child-side routine completion handoffs are not expected. With the intercom bridge active, parent-side `pi-cohort` sends grouped completion results through `pi-intercom`: one grouped message per foreground parent run and one per completed async result file. Acknowledged foreground delivery returns a compact receipt with artifact/session paths; if unacknowledged, the normal full output is preserved. Grouped messages include child intercom targets, full child summaries, and compact nested summaries under the parent child that launched them.
-
-If bridge instructions provide the child-facing tool, a child can ask:
-
-```typescript
-contact_supervisor({
-  reason: "need_decision",
-  message: "Should I optimize for readability or performance here?"
-})
-```
-
-The parent replies with:
-
-```typescript
-intercom({ action: "reply", message: "Optimize for readability." })
-```
-
-Or inspects unresolved asks first:
-
-```typescript
-intercom({ action: "pending" })
-```
-
-If intercom messages do not show up, run `subagent({ action: "doctor" })` or `/cohort-doctor`.
-
 ## Management Mode
 
 The `subagent(...)` tool also supports management actions.
@@ -622,8 +572,6 @@ particular agent or with forked context.
 - **Default subagent nesting depth is 2.** Deeper recursive delegation is blocked
   unless configured otherwise.
 - **Attention signals are not lifecycle state.** `needs_attention` means no activity has been observed past the configured threshold. `paused` means the child turn was intentionally interrupted or is awaiting direction; it is not the same as `failed`.
-- **Intercom asks are blocking.** A session can only maintain one pending outbound
-  ask wait state at a time.
 - **Keep conversational authority clear.** Advisory subagents should not silently
   become second decision-makers.
 
@@ -650,19 +598,14 @@ user explicitly requests forked context.
 Give subagents specific tasks rather than vague mandates.
 `Review auth.ts for null-check gaps` works better than `Review everything`.
 
-### Escalate decisions upward
+### Stop on unapproved decisions
 
-If a subagent encounters an unapproved product, architecture, or scope choice,
-it should coordinate back via `intercom` instead of deciding alone.
+If a subagent encounters an unapproved product, architecture, or scope choice, it must stop with `BLOCKED: <decision needed>` as the first line, followed by `Done: <complete>` and `Remaining: <left>`. The parent receives an ordinary failed result, sequential chains stop at that step, and follow-up is a fresh dispatch after the parent or human decides.
 
 ### Intervene only on clear control signals
 
 Use subagent control proactively when a delegated run emits `needs_attention`, or when a human asks you to regain control. Do not interrupt just because a child has briefly produced no output. Silence can be normal during long tool calls, test runs, or model reasoning.
 
-### Name sessions meaningfully
-
-Use `/name` so intercom targeting stays stable.
-
 ## Common Workflows
 
 ### Recon → Plan → Implement
@@ -796,10 +739,10 @@ subagent({ action: "list" })
 // Check available agents and chains, then confirm scope/precedence.
 ```
 
-**Setup, discovery, or intercom confusion**
+**Setup or discovery confusion**
 ```typescript
 subagent({ action: "doctor" })
-// Check runtime paths, async support, discovery counts, current session, and intercom bridge state.
+// Check runtime paths, async support, discovery counts, and current session.
 ```
 
 **"Max subagent depth exceeded"**
@@ -812,11 +755,6 @@ subagent({ action: "doctor" })
 // Persist the current session before using context: "fork".
 ```
 
-**Intercom "Already waiting for a reply"**
-```typescript
-// Resolve the current outbound ask before starting another one.
-```
-
 **Parallel output-path conflict**
 ```typescript
 // Give each parallel task a distinct output path, or disable output for tasks that do not need it.

package/skills/pi-cohort/reference/config-fields.md

@@ -65,4 +65,4 @@ Per-call attention-tracking overrides: `subagent({ ..., control: {...} })`. Run-
 | `activeNoticeAfterTokens` | integer >= 1 | Notice by total tokens. | off |
 | `failedToolAttemptsBeforeAttention` | integer >= 1 | Mutating-tool failures before `needs_attention`. | `3` |
 | `notifyOn` | array of `"active_long_running"` \| `"needs_attention"` | Which events notify the parent. | both |
-| `notifyChannels` | array of `"event"` \| `"async"` \| `"intercom"` | Delivery channels. | all three |
+| `notifyChannels` | array of `"event"` \| `"async"` | Delivery channels. | both |

package/src/extension/control-notices.ts

@@ -8,21 +8,15 @@ export interface SubagentControlMessageDetails {
 	event: ControlEvent;
 	source?: "foreground" | "async";
 	asyncDir?: string;
-	childIntercomTarget?: string;
 	noticeText?: string;
 }
 
-export function controlNoticeTarget(details: SubagentControlMessageDetails): string | undefined {
-	return details.childIntercomTarget;
-}
-
 export function formatSubagentControlNotice(details: SubagentControlMessageDetails, content?: string): string {
-	return details.noticeText ?? content ?? formatControlNoticeMessage(details.event, controlNoticeTarget(details));
+	return details.noticeText ?? content ?? formatControlNoticeMessage(details.event);
 }
 
 function noticeTimerKey(details: SubagentControlMessageDetails): string {
-	const childIntercomTarget = controlNoticeTarget(details);
-	return `${details.event.runId}:${controlNotificationKey(details.event, childIntercomTarget)}`;
+	return `${details.event.runId}:${controlNotificationKey(details.event)}`;
 }
 
 export function clearPendingForegroundControlNotices(state: SubagentState, runId?: string): void {
@@ -41,17 +35,16 @@ function deliverControlNotice(input: {
 	details: SubagentControlMessageDetails;
 	isIdle: () => boolean;
 }): void {
-	const childIntercomTarget = controlNoticeTarget(input.details);
-	const key = controlNotificationKey(input.details.event, childIntercomTarget);
+	const key = controlNotificationKey(input.details.event);
 	if (input.visibleControlNotices.has(key)) return;
 	input.visibleControlNotices.add(key);
-	const noticeText = input.details.noticeText ?? formatControlNoticeMessage(input.details.event, childIntercomTarget);
+	const noticeText = input.details.noticeText ?? formatControlNoticeMessage(input.details.event);
 	input.pi.sendMessage(
 		{
 			customType: SUBAGENT_CONTROL_MESSAGE_TYPE,
 			content: noticeText,
 			display: true,
-			details: { ...input.details, childIntercomTarget, noticeText },
+			details: { ...input.details, noticeText },
 		},
 		{ triggerTurn: input.details.source !== "foreground" || !input.isIdle() },
 	);

package/src/extension/doctor.ts

@@ -2,7 +2,6 @@ import * as fs from "node:fs";
 import * as path from "node:path";
 import { discoverAgentsAll, type AgentSource } from "../agents/agents.ts";
 import { isAsyncAvailable } from "../runs/background/async-execution.ts";
-import { diagnoseIntercomBridge, type IntercomBridgeDiagnostic } from "../intercom/intercom-bridge.ts";
 import { discoverAvailableSkills, type SkillSource } from "../agents/skills.ts";
 import {
 	ASYNC_DIR,
@@ -24,18 +23,15 @@ interface DoctorDeps {
 	isAsyncAvailable: () => boolean;
 	discoverAgentsAll: typeof discoverAgentsAll;
 	discoverAvailableSkills: typeof discoverAvailableSkills;
-	diagnoseIntercomBridge: typeof diagnoseIntercomBridge;
 }
 
 interface DoctorReportInput {
 	cwd: string;
 	config: ExtensionConfig;
 	state: SubagentState;
-	context?: "fresh" | "fork";
 	requestedSessionDir?: string;
 	currentSessionFile?: string | null;
 	currentSessionId?: string | null;
-	orchestratorTarget?: string;
 	sessionError?: string;
 	expandTilde?: (value: string) => string;
 	paths?: DoctorPaths;
@@ -53,7 +49,6 @@ const DEFAULT_DEPS: DoctorDeps = {
 	isAsyncAvailable,
 	discoverAgentsAll,
 	discoverAvailableSkills,
-	diagnoseIntercomBridge,
 };
 
 function errorText(error: unknown): string {
@@ -186,22 +181,6 @@ function formatCostLines(input: DoctorReportInput): string[] {
 	return lines;
 }
 
-function formatIntercomDiagnostic(diagnostic: IntercomBridgeDiagnostic, context: "fresh" | "fork" | undefined): string[] {
-	const lines = [
-		`- bridge: ${diagnostic.active ? "active" : "inactive"}${diagnostic.reason ? ` (${diagnostic.reason})` : ""}`,
-		`- mode: ${diagnostic.mode}; context: ${context ?? "unspecified"}`,
-		`- orchestrator target: ${diagnostic.orchestratorTarget ?? "not available"}`,
-		`- pi-intercom: ${diagnostic.piIntercomAvailable ? "available" : "unavailable"} at ${diagnostic.extensionDir}`,
-	];
-	if (diagnostic.configPath && diagnostic.intercomConfigEnabled !== undefined) {
-		lines.push(`- intercom config: ${diagnostic.intercomConfigEnabled === false ? "disabled" : "enabled or absent"} (${diagnostic.configPath})`);
-	}
-	if (diagnostic.intercomConfigError) {
-		lines.push(`- intercom config warning: ${diagnostic.intercomConfigError}; runtime assumes enabled`);
-	}
-	return lines;
-}
-
 export function buildDoctorReport(input: DoctorReportInput): string {
 	const paths = input.paths ?? DEFAULT_PATHS;
 	const deps = { ...DEFAULT_DEPS, ...input.deps };
@@ -222,14 +201,6 @@ export function buildDoctorReport(input: DoctorReportInput): string {
 		"Discovery",
 		...formatDiscovery(input, deps),
 		"",
-		"Intercom bridge",
-		...lineFromCheck("intercom bridge", () => formatIntercomDiagnostic(deps.diagnoseIntercomBridge({
-			config: input.config.intercomBridge,
-			context: input.context,
-			orchestratorTarget: input.orchestratorTarget,
-			cwd: input.cwd,
-		}), input.context).join("\n")).split("\n"),
-		"",
 		...formatCostLines(input),
 	];
 	return lines.join("\n");

package/src/extension/fanout-child.ts

@@ -7,8 +7,6 @@ import { getArtifactsDir } from "../shared/artifacts.ts";
 import { createSubagentExecutor, type SubagentParamsLike } from "../runs/foreground/subagent-executor.ts";
 import { SUBAGENT_CHILD_ENV, SUBAGENT_FANOUT_CHILD_ENV } from "../runs/shared/pi-args.ts";
 import { readNestedControlRequests, resolveNestedRouteFromEnv, writeNestedControlResult } from "../runs/shared/nested-events.ts";
-import { deliverSubagentIntercomMessageEvent } from "../intercom/result-intercom.ts";
-import { resolveSubagentIntercomTarget } from "../intercom/intercom-bridge.ts";
 import { SubagentParams } from "./schemas.ts";
 import { loadConfig } from "./config.ts";
 import { deriveForwardedFlags } from "../runs/shared/forward-flags.ts";
@@ -84,21 +82,8 @@ function startNestedControlInboxListener(pi: ExtensionAPI, state: SubagentState)
 										: `Nested run ${request.targetRunId} has no active child step to interrupt.`;
 								} else if (!request.message?.trim()) {
 									message = "Nested resume requires message.";
-								} else if (!control.currentAgent) {
-									message = `Nested run ${request.targetRunId} has no active child message route.`;
 								} else {
-									const index = control.currentIndex ?? 0;
-									const target = resolveSubagentIntercomTarget(request.targetRunId, control.currentAgent, index);
-									ok = await deliverSubagentIntercomMessageEvent(
-										pi.events,
-										target,
-										`Follow-up for nested run ${request.targetRunId} (${control.currentAgent}):\n\n${request.message.trim()}`,
-										500,
-										{ source: "nested-resume", runId: request.targetRunId, agent: control.currentAgent, index },
-									);
-									message = ok
-										? `Delivered follow-up to live nested run ${request.targetRunId}.`
-										: `Nested child intercom target is not registered: ${target}`;
+									message = `Nested run ${request.targetRunId} is still active; wait for completion, then resume.`;
 								}
 							} catch (error) {
 								message = error instanceof Error ? error.message : String(error);

package/src/extension/index.ts

@@ -9,7 +9,7 @@
  * Toggle: async parameter (default: false, configurable via config.json)
  *
  * Config file: ~/.pi/agent/extensions/pi-cohort/config.json
- *   { "asyncByDefault": true, "forceTopLevelAsync": true, "maxSubagentDepth": 1, "showRosterOnStart": true, "intercomBridge": { "mode": "always", "instructionFile": "./intercom-bridge.md" }, "worktreeSetupHook": "./scripts/setup-worktree.mjs" }
+ *   { "asyncByDefault": true, "forceTopLevelAsync": true, "maxSubagentDepth": 1, "showRosterOnStart": true, "worktreeSetupHook": "./scripts/setup-worktree.mjs" }
  */
 
 import * as fs from "node:fs";
@@ -442,7 +442,7 @@ MANAGEMENT: action=list/get/create/update/delete (chainName for chains; packaged
 CONTROL: action=status/interrupt/resume (id, message, index); details: pi-cohort skill.
 
 DIAGNOSTICS:
-• { action: "doctor" } - read-only report for runtime paths, discovery, sessions, and intercom`,
+• { action: "doctor" } - read-only report for runtime paths, discovery, and sessions`,
 		parameters: SubagentParams,
 
 		execute(id, params, signal, onUpdate, ctx) {