You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* fix(pause): add TaskStop guarantee tier to teammate shutdown; codify TaskStop as the termination primitive
shutdown_request is cooperative-only — empirically, on the tmux backend an
approved shutdown_response does not terminate the teammate's pane/process.
pause.md step 6 now mirrors refresh.md step 5's two-tier shape (graceful
request, then TaskStop as the guarantee tier); the agent-teams skill and
orchestrator persona codify the same correction with one shared sentence
skeleton across all three surfaces. imPACT.md assessed: already
TaskStop-routed, no change.
* chore: bump plugin version to 4.6.1 (PATCH)
* fix(imPACT): shutdown_request is cooperative-only, not a standalone termination path
Rewrites the when-to-terminate clause to the shared cooperative-only /
termination-primitive skeleton, reconciles the 'last resort' framing with
the routine guarantee-tier role, and unifies the TaskStop signature to the
name form.
* fix(shutdown-docs): review-minors batch — honest dual-mode scoping, loop-error guidance, ported guards
refresh.md rationale aligned to the cooperative-only skeleton; pause.md
gains continue-on-not-found loop guidance plus refresh's no-sync-confirmation
and post-stop-send guards; SKILL.md scopes the non-termination claim to the
tmux backend (in-process semantics unprobed) and reframes memory-saving as
incremental; stagger phrasing unified (1 teammate/turn, request+stop = 2 ops).
* test: structural pins for pause two-tier shutdown + cross-surface termination skeleton
TestPauseShutdownStructure pins the two-tier loop invariants (order,
cooperative-only rationale, post-state note, no-delete line, error
idempotency); TestShutdownTerminationSkeletonAcrossSurfaces asserts the
uniform cooperative-only skeleton on all four shutdown surfaces so a
single-surface regression desyncs loudly.
* test: add imPACT.md to the termination-skeleton surface pins
* fix(teammate_idle): two-tier the force-threshold shutdown advisory
The ACTION-REQUIRED message the hook emits for the orchestrator now
instructs the graceful request followed by TaskStop, with the
cooperative-only rationale; test pins both tokens.
Copy file name to clipboardExpand all lines: pact-plugin/agents/pact-orchestrator.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -407,6 +407,8 @@ Exceptions:
407
407
- rePACT sub-scope specialists shut down after their nested cycle (orchestrator relays handoff details to subsequent sub-scopes)
408
408
- comPACT specialists shut down when user chooses "Pause work for now"
409
409
410
+
`shutdown_request` is cooperative-only — empirically, on the tmux backend an approved `shutdown_response` does not terminate the teammate's pane/process. `TaskStop("{teammate_name}")` is the authoritative termination primitive (reaps the pane/process and removes the roster entry; the team config file and team identity survive): any flow that requires a teammate actually gone MUST follow the graceful request with `TaskStop`.
411
+
410
412
**Inter-teammate messages always go individually by name.**`SendMessage` requires a specific `to=` recipient — there is no broadcast addressing mode. To reach multiple teammates (HALT, shutdown, plan approval, structured protocol messages, plain-text announcements), iterate over the relevant teammates and send one `SendMessage` per recipient. Use the Lead-Side HALT Fan-Out idiom below as the canonical pattern.
|**Not truly blocked**| Neither question is "Yes" | Instruct agent to continue with clarified guidance |
122
122
|**Escalate to user**| 3+ imPACT cycles without resolution | Proto-algedonic signal—systemic issue needs user input |
123
123
@@ -127,7 +127,7 @@ If the blocker reveals that a sub-task is more complex than expected and needs i
127
127
/PACT:rePACT backend "implement the OAuth2 token refresh that's blocking us"
128
128
```
129
129
130
-
**When to terminate**: Last resort — agent resumed once and stalled again, looping on same error 3+ times, context exhausted, or TeammateIdle stall unresolved by resume. `TaskStop` is a force-stop (immediate, non-cooperative); use `SendMessage(to="{agent-name}", message={"type": "shutdown_request"})`for cooperativeshutdown. After termination, spawn a fresh agent with partial HANDOFF from the terminated agent's task metadata.
130
+
**When to terminate**: Last resort — agent resumed once and stalled again, looping on same error 3+ times, context exhausted, or TeammateIdle stall unresolved by resume. `TaskStop` is a force-stop (immediate, non-cooperative) and the termination primitive; `SendMessage(to="{agent-name}", message={"type": "shutdown_request"})`is cooperative-only wind-down messaging that does not itself terminate the agent — any flow that requires the agent actually gone MUST follow the graceful request with `TaskStop`. "Last resort" scopes the decision to terminate an unrecoverable agent mid-workflow — not the `TaskStop` primitive itself, which is also the routine guarantee tier in graceful shutdown flows. After termination, spawn a fresh agent with partial HANDOFF from the terminated agent's task metadata.
131
131
132
132
> **Force-termination is a carve-out** to the team-lead-only-completion rule. The `metadata.terminated == true` marker on the team-lead-driven `TaskUpdate(status="completed")` distinguishes this path from the standard cooperative acceptance flow. The terminated teammate is not idling on `awaiting_lead_completion`; the team-lead is force-completing an unrecoverable agent's task out-of-band. See [Completion Authority](../protocols/pact-completion-authority.md#completion-authority) for the carve-out table.
Copy file name to clipboardExpand all lines: pact-plugin/commands/pause.md
+5-2Lines changed: 5 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -105,14 +105,17 @@ The timestamp (`ts`) is set automatically by `make_event()` and serves the same
105
105
106
106
### 6. Shut Down Teammates
107
107
108
-
Send `shutdown_request` individually to each active teammate **by name**and wait for responses. The secretary must have completed consolidation tasks (steps 1 and 3) before receiving the shutdown request.
108
+
Shut down each active teammate **by name**, staggered 1 teammate per turn — the stagger counts ops, and request + stop = 2 ops (rate-limit discipline): graceful `shutdown_request` first, then `TaskStop("{teammate_name}")` as the guarantee tier — `shutdown_request` is cooperative-only (empirically, on the tmux backend an approved `shutdown_response` does not terminate the teammate's pane/process); `TaskStop` is authoritative. The secretary must have completed consolidation tasks (steps 1 and 3) before receiving the shutdown request.
Do NOT delete the team — it will be garbage-collected or reused on resume.
116
+
Treat a `TaskStop` not-found / already-exited error as already-stopped success and CONTINUE the loop — never abort mid-iteration; an abort strands later teammates unstopped.
117
+
118
+
EXPECTED post-state: each stop removes that member's roster entry — the config FILE and the team IDENTITY survive; a lead-only roster is the correct post-pause state, not corruption. Do NOT add synchronous send-confirmation (message delivery lands asynchronously) — verify by a disk re-read of the team config, or simply proceed. A send to an already-stopped teammate fails hard with a no-agent-reachable error — this is EXPECTED post-stop behavior, not a diagnostic detour. Do NOT delete the team — it will be garbage-collected or reused on resume.
Copy file name to clipboardExpand all lines: pact-plugin/commands/refresh.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -117,7 +117,7 @@ The timestamp (`ts`) is set automatically by the journal writer and becomes the
117
117
118
118
### 5. SHUTDOWN teammates
119
119
120
-
Shut down each active teammate **by name**, staggered 1-2 sends per turn (rate-limit discipline): graceful `shutdown_request` first, then `TaskStop(name)` as the guarantee tier — a teammate may reject the request mid-task; `TaskStop` is authoritative.
120
+
Shut down each active teammate **by name**, staggered 1 teammate per turn — the stagger counts ops, and request + stop = 2 ops (rate-limit discipline): graceful `shutdown_request` first, then `TaskStop(name)` as the guarantee tier — `shutdown_request` is cooperative-only (empirically, on the tmux backend an approved `shutdown_response` does not terminate the teammate's pane/process); `TaskStop` is authoritative.
Copy file name to clipboardExpand all lines: pact-plugin/skills/pact-agent-teams/SKILL.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -520,7 +520,9 @@ When you receive a `shutdown_request`:
520
520
| Idle, consultant with no active questions, or domain no longer relevant | Approve |
521
521
| Mid-task, awaiting response, or remediation may need your input | Reject with reason |
522
522
523
-
> **Save memory before approving**: If you haven't saved domain learnings to your agent memory yet, do so before approving — your process terminates on approval.
523
+
> **Save learnings incrementally**: under guarantee-tier shutdown flows the lead may follow the graceful request with an immediate `TaskStop`, so you can be reaped before ever seeing the request. Save domain learnings to your agent memory as you work and treat any turn as possibly your last; approving a `shutdown_request` is a courtesy, not your save trigger.
524
+
525
+
`shutdown_request` is cooperative-only. Empirically, on the tmux backend an approved `shutdown_response` does not terminate the teammate's pane/process — approval authorizes termination but does not perform it. On the in-process backend, `shutdown_response` semantics are unprobed: platform documentation claims approval terminates the process, but this is unverified in either direction. `TaskStop` is the termination primitive; any flow that requires a teammate actually gone MUST follow the graceful request with `TaskStop` (or verify pane/process death).
0 commit comments