agent-postmortem 0.4.0__tar.gz → 0.5.0__tar.gz

{agent_postmortem-0.4.0 → agent_postmortem-0.5.0}/CHANGELOG.md

@@ -5,6 +5,104 @@ All notable changes to this project are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.5.0]
+
+0.5 tells a session about the workers it launched, with nothing to arm. Claude Code records a
+background session's state in its job file and tells nobody: a worker sat 8.5 hours on a
+permission prompt while the session that launched it heard nothing. Now that session reads one
+line at its next tool call or prompt, and an idle session is woken for it. This needs the plugin;
+without it, `status` and `scan` print the same reasons when someone runs them.
+
+### Added
+
+- Worker notice. The plugin reads the `claude --bg` in the session's own Bash call and follows
+  that worker from then on: `WORKER night-run (a1b2c3d4) blocked 15m: waiting for a permission
+  approval (approve Entering worktree). A person must approve it: claude attach a1b2c3d4`. A
+  permission prompt, a question, a first prompt never sent, an API error, a failure and a worker
+  idle on a stuck command each have their own line, told once per change at the next tool call
+  or prompt, ahead of anything else the hook has to say. A worker that delivered gets a one-line
+  note with no problem word. The worker's own words are never printed: only the name its launch
+  printed, the short id and a permission's tool. A worker that finishes on its own schedule is
+  told finishing twice, then not until trouble. A first look after an upgrade tells trouble from
+  the last 24 hours and deliveries from the last 10 minutes, and records the rest silently. A
+  launch by a subagent, by another session or by a Bash call that ran in the background is not
+  linked; `status` and `scan` still list those workers.
+- Idle wake. Every Stop starts a watcher (`hook stop-watch`, an `asyncRewake` hook) when the
+  session has a worker or a running command to follow, and it wakes an idle session with the
+  same line. It checks every 20 s, wakes at most once per 5 minutes, leaves as soon as the session
+  acts again, and gives a worker's own report 2 minutes to arrive before it wakes for a delivery.
+  A session is never woken for a line it could not record as told, and any error exits without
+  waking it. It needs Claude Code 2.1.314 or later, a reboot loses it until the next Stop, and
+  `AGENT_POSTMORTEM_WAKE=0` turns it off. A running session starts it after `/reload-plugins` or
+  a restart; the per-call line does not need either.
+- Reason classes in `status` and `scan`. A BLOCKED row says what the session waits for
+  (`waiting for a permission approval`, `waiting for an answer`, `stopped on an API error`, `the
+  reason is not recorded`) and `dispatched by this session` when it did, those rows first. A
+  worker that delivered and waits on a decision has its own DELIVERED row. `--local` adds the
+  tool and the command that helps (`-> claude attach <id>`, `-> claude logs <id>`), `status
+  --json` adds `class` and `mine`, and `--local` adds `label` and `short`. Another session's row
+  older than 3 days folds into one count line.
+- `scan` lists under NEEDS ATTENTION every background session waiting on a person or failed in
+  the last day, read at scan time and whatever `--since` says, the caller's own workers first. One
+  that delivered is not listed. `scan --json` gains `blocked` only when one is listed.
+- Stall checks. A background command whose output has not changed for 30 minutes, or whose output
+  ends in codex's "Reading additional input from stdin..." for 2 minutes, is told once through a
+  COMMAND line at the next tool call or prompt. `status` prints a STALLED row and `scan` lists the
+  session first under NEEDS ATTENTION when its process is alive, its turn ended 30 minutes ago and
+  nothing is set to wake it. The BACKGROUND line counts such a session as stalled, not working. A
+  command under a real `timeout`, a timer by any path to `sleep`, or one carrying the marker
+  `# postmortem: silent-wait` is quiet by design, and only the stdin rule still speaks for it. So
+  is `perl -e 'alarm N; exec @ARGV' ...` or `'alarm shift; exec @ARGV' N ...`, in that exact shape
+  with only exact, literal steps around it. Any other wrapper is told once, in words that say it
+  may be fine: a loose rule would silence the only alarm for a real hang.
+- Codex stdin warning. `hook pre-bash` warns before a background `codex exec` with no stdin
+  redirect runs: codex reads stdin to its end when it is not a terminal, and one review hung
+  26 hours that way.
+- A Stop with a background command still running asks the session to arm a deadline, once per
+  command, wherever the idle watcher would not catch a hang: an interactive session, an older
+  Claude Code or plugin, or a command whose output the watcher cannot read (`> "$LOG"`).
+  A Monitor or a wake that can still fire counts as that deadline.
+- A background session whose subagents and workflows have all ended, with no `status`, `scan`,
+  `run` or `watch` of this tool since, is reminded once at a Stop with nothing else to say to run
+  `status` before reporting done. An interactive session gets none, and
+  `AGENT_POSTMORTEM_WATCH_HINT=0` turns it off.
+- At a session start with nothing else to say, at most once a day, the plugin says so when the
+  `agent-postmortem` on PATH is older than the plugin and its newer hooks stay silent. `hook
+  capabilities` lists `hooks`, and an older CLI is never started for `stop-watch`.
+
+### Changed
+
+- A tool call with nothing new starts about a third faster: 26 ms down to 15 ms for the CLI on Linux,
+  measured in a container. It no longer loads `dataclasses`, `tempfile`, `secrets` or `datetime`,
+  nor OpenSSL where Python has its builtin sha256, and that call uses none of them. Every tool call
+  of every session pays this.
+- `watch` flushes every line. A Monitor reads it through a pipe, where block buffering delivered
+  nothing until the run ended. It also stops quietly when its reader closes the pipe.
+- `watch --session`, `status` and `scan` read a worker's `tempo` before its `state`, which is
+  written only when a turn ends: a worker on a permission prompt reads `state: working, tempo:
+  blocked`, and one given a new prompt reads `state: blocked, tempo: active`.
+- The top-level help names `watch --session` and a background worker's blocked or needs-input
+  state.
+- In a session that is itself a background worker, `status` lists only the rows it launched and
+  ends the count line with `; this session launched <n>, scan lists the rest`. `--json` keeps every
+  row with its owner, and if it launched a worker whose id it never saw, all rows stay.
+
+### Fixed
+
+- `status` no longer keeps a finished subagent as RUNNING. A subagent resumed by a message ends
+  with a notice naming only its task, no tool-use id, and the live read dropped it, so the first
+  notice stood while the transcript grew past it. It now counts when the task is a subagent this
+  session launched.
+- A commit's id is read per segment of the shell command. When an assignment or expansion
+  elsewhere in the command made the whole command unplaced, an agent's printed summary line was
+  dropped and its COMMITS read `?`. Substitutions that spell a commit still read `?`.
+- A Monitor no longer gets the deadline request (Claude Code lists it as a plain shell task, so a
+  Monitor is now known from the session's own Monitor calls), and a deliberately silent wait no
+  longer reads as hung and suggests stopping it.
+- On CI the hook-speed test compares a nothing-new call with a bare start of the same interpreter
+  in interleaved rounds. A shared runner read 152 ms against the 150 ms budget on a correct
+  build; the 150 ms test still runs where CI is unset.
+
 ## [0.4.0]
 
 0.4 adds live mode: the tool checks a subagent's "done" the moment it returns, and tells the

{agent_postmortem-0.4.0 → agent_postmortem-0.5.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: agent-postmortem
-Version: 0.4.0
+Version: 0.5.0
 Summary: Reads the Claude Code logs already on your machine and tells you which agent's 'done' you can't trust, and what to run next.
 Project-URL: Homepage, https://github.com/zeyusuntt/agent-postmortem
 Project-URL: Issues, https://github.com/zeyusuntt/agent-postmortem/issues
@@ -23,9 +23,13 @@ Description-Content-Type: text/markdown
 
 # agent-postmortem
 
-Which "done" in your last Claude Code run can't you trust?
+Claude Code records the state. The plugin tells you.
 
-agent-postmortem reads the transcripts Claude Code already wrote under `~/.claude/projects` and, for every Workflow run and every session with subagents, says which agents were killed (in a Workflow, often quietly started over), which never returned, which said "done" while their own result said otherwise, and which files and commits that left at risk. Then it lists at most 3 next steps. No setup, no proxy, no LLM, no network access, and it never changes your files.
+One night a background worker sat 8.5 hours on a permission prompt. Its job file said `blocked` and `approve Entering worktree`, the session that launched it heard nothing, and its agent list showed the worker as idle. With the plugin, that session reads this at its next tool call, and an idle session is woken for it: `WORKER night-run (a1b2c3d4) blocked 15m: waiting for a permission approval (approve Entering worktree). A person must approve it: claude attach a1b2c3d4`.
+
+Nothing has to be armed. The plugin reads the `claude --bg` in the session's own Bash call and follows that worker from then on. A permission prompt, a question, an API error, a failure, or a worker idle on a command that never ends is told once per change, and a worker that delivered gets a one-line note. `AGENT_POSTMORTEM_WAKE=0` keeps a session from being woken.
+
+Which "done" in your last Claude Code run can't you trust? agent-postmortem reads the transcripts Claude Code already wrote under `~/.claude/projects` and, for every Workflow run and every session with subagents, says which agents were killed (in a Workflow, often quietly started over), which never returned, which said "done" while their own result said otherwise, and which files and commits that left at risk. Then it lists at most 3 next steps. No setup, no proxy, no LLM, no network access, and it never changes your files.
 
 On the maintainer's machine (scan 2026-10-27, 0.3.2), 13 of 166 workflow runs launched at least one agent's task a second time, and 10.2 hours went to retries and to attempts that ended without a result.
 
@@ -90,7 +94,7 @@ Coverage today, checked against the failure reports in Claude Code's issue track
 | Subagents that never returned | covered | WORK AT RISK says `unknown` instead of `none`, and names them |
 | `claude -p` (headless) | partial | killed and unreturned subagents show; with the plugin, a foreground subagent that returns on an error or without its prompted output file is reported at once. The process's own exit status (for example exit 0 with `result: success` after a kill) is not in the transcript, so the tool cannot see it |
 | Background subagents (`run_in_background`) | partial | killed and unreturned ones show; a "completed" that arrived while the agent's own background work was still running, or with a tool call that never got a result, is not flagged yet |
-| `claude --bg` sessions | partial | each job's session is read like any session; `watch --session` and `status` pass the job's own state (working, blocked, done, stopped) through as Claude Code records it, and a resumed session hears which of its subagents never returned. Work still in flight inside the job is not modeled |
+| `claude --bg` sessions | partial | with the plugin, the session that launched a worker is told each change at its next tool call or prompt and woken when idle (permission prompt, question, API error, failure, a stuck command, delivered). `status` and `scan` give the same reason when someone runs them, and `watch --session` prints each state change. Not linked: a launch by a subagent, by another session, or by a Bash call that itself ran in the background; `status` and `scan` still list those. "No report past its expected time" is not covered, since nothing records an expected time |
 | Agent teams | not yet | teammates and their idle or blocked states are not modeled |
 | Cross-session messages (`SendMessage`) | not yet | whether a message was delivered is not checked |
 
@@ -140,7 +144,7 @@ Verdict: 0.3 stops guessing. Severity, the WORK AT RISK block, and the run's end
 | `agent-postmortem rescue status <run-id>` | Print what the main session's own transcript shows was run and observed after the run ended. Reports only what it saw, never a confirmation that a check passed. |
 | `agent-postmortem watch <run-id>` | Follow one running workflow: print START, then KILL, FAILED, OK (a result came back), and QUIET as they happen, then DONE or LIMIT. DONE comes the moment the session's own record says the run ended, or after a grace period once every journal key is resolved. Read-only, designed to be a Claude Code Monitor command. |
 | `agent-postmortem watch --session [<session-id>]` | Follow one session while it runs, for a Claude Code Monitor: a line only when a subagent is interrupted with nothing in the session to explain it, fails after changing files, or returns while its own last entry says otherwise, plus background-session state changes. With no id it follows the session you are in. |
-| `agent-postmortem status [<session-id>]` | One snapshot of a session: its subagents running, returned, interrupted or failed, what an interrupted one changed, returns its own transcript contradicts, and the background sessions' states. Reads only what was appended since the last call. |
+| `agent-postmortem status [<session-id>]` | One snapshot of a session: its subagents running, returned, interrupted or failed, what an interrupted one changed, returns its own transcript contradicts, and the background sessions' states with what each waits for and whether this session dispatched it (a session that is itself a background worker lists only the rows it launched). Reads only what was appended since the last call. |
 | `agent-postmortem statusline subagents` | A `subagentStatusLine` command: adds a fact to a row of Claude Code's subagent panel and leaves every other row as Claude Code draws it. |
 | `agent-postmortem hook <event>` | Claude Code plugin hook entry point; reads hook JSON from stdin. |
 
@@ -190,7 +194,7 @@ Install the command-line tool first (Quick start above), so the plugin finds it
 /plugin install agent-postmortem@agent-postmortem
 ```
 
-Its hooks shell out to the same CLI, never touch a run directory, and never fail a turn. After every tool call and on every prompt they check the session's own subagents: one that was interrupted with nothing in the session to explain it, failed after changing files, or returned while its own transcript contradicts the return is reported to the agent at its next tool call, once. A call with nothing new prints nothing. On `SessionStart` they summarize any run that finished since you last looked, and a resumed session hears which of its own subagents never returned. On `Stop` and `StopFailure` they check every subagent and workflow unit spawned so far and print a finding the moment it is detected, not only at session end. On `SessionEnd` they run the read-only tooling checks over the main thread itself. On a `Workflow` launch they register the run immediately, so it is tracked even before its own directory exists, and hand the session the `watch` command to arm as a Monitor. Two skills come with it: `/postmortem` for the verdict and `/rescue` for the bounded rescue protocol.
+Its hooks shell out to the same CLI, never touch a run directory, and never fail a turn. After every tool call and on every prompt they read the job files of the workers this session launched with `claude --bg` and tell each change once, in a `WORKER` line that says the state, the reason and what helps; at each Stop a watcher starts if there is something to follow, and it wakes the session when it has gone idle. It checks every 20 s, wakes at most once per 5 minutes, and leaves when the session acts again. It needs Claude Code 2.1.314 or later, a session already running starts it after `/reload-plugins` or a restart, and `AGENT_POSTMORTEM_WAKE=0` turns it off. After every tool call and on every prompt the hooks also check the session's own subagents: one that was interrupted with nothing in the session to explain it, failed after changing files, or returned while its own transcript contradicts the return is reported to the agent at its next tool call, once. A call with nothing new prints nothing. On `SessionStart` they summarize any run that finished since you last looked, and a resumed session hears which of its own subagents never returned. On `Stop` and `StopFailure` they check every subagent and workflow unit spawned so far and print a finding the moment it is detected, not only at session end. On `SessionEnd` they run the read-only tooling checks over the main thread itself. On a `Workflow` launch they register the run immediately, so it is tracked even before its own directory exists, and hand the session the `watch` command to arm as a Monitor. Two skills come with it: `/postmortem` for the verdict and `/rescue` for the bounded rescue protocol.
 
 For your own view, add the subagent panel command to `~/.claude/settings.json`, at the top level:
 
@@ -280,7 +284,7 @@ It was built across two Claude Code Workflow runs, and those same runs are among
 
 ## Limits
 
-The formats this tool parses are internal to Claude Code, not a published API, and were observed on versions 2.1.251 to 2.1.312; a future version can change them without notice. A few transcript entry types first seen in 2.1.285 to 2.1.310 (`tools-used`, `relocated`, `agent-setting`, `history-suppression`, `continued-in`) are not interpreted yet, so an attempt whose transcript holds one reads as "the tool cannot see all of what was written". Claude Code deletes transcripts older than 30 days by default (the `cleanupPeriodDays` setting), and with them the history `scan`, `trend` and `rules propose` read; raise that setting to keep more. A session's retries are not observable the way a workflow's are: a session has no cache key to compare attempts against, so `silent_retry` never fires on one. Whether a main-session interrupt was a human pressing Escape is not knowable from the transcript, so it is never attributed, only recorded as a limit. Tested on macOS and Linux only. The repository check (`run --observe`, `rescue status`) uses `git status` to inspect paths, with every filter driver switched off and no network transport allowed; in a repository with a sparse index or a split index, git's own `status` can still store a cached tree object or refresh the shared index file's timestamps, without changing tracked content, commits, or branches.
+The formats this tool parses are internal to Claude Code, not a published API, and were observed on versions 2.1.251 to 2.1.318; a future version can change them without notice. A few transcript entry types first seen in 2.1.285 to 2.1.310 (`tools-used`, `relocated`, `agent-setting`, `history-suppression`, `continued-in`) are not interpreted yet, so an attempt whose transcript holds one reads as "the tool cannot see all of what was written". Claude Code deletes transcripts older than 30 days by default (the `cleanupPeriodDays` setting), and with them the history `scan`, `trend` and `rules propose` read; raise that setting to keep more. A session's retries are not observable the way a workflow's are: a session has no cache key to compare attempts against, so `silent_retry` never fires on one. Whether a main-session interrupt was a human pressing Escape is not knowable from the transcript, so it is never attributed, only recorded as a limit. Tested on macOS and Linux only. The repository check (`run --observe`, `rescue status`) uses `git status` to inspect paths, with every filter driver switched off and no network transport allowed; in a repository with a sparse index or a split index, git's own `status` can still store a cached tree object or refresh the shared index file's timestamps, without changing tracked content, commits, or branches.
 
 ## Contributing
 

{agent_postmortem-0.4.0 → agent_postmortem-0.5.0}/README.md

@@ -1,8 +1,12 @@
 # agent-postmortem
 
-Which "done" in your last Claude Code run can't you trust?
+Claude Code records the state. The plugin tells you.
 
-agent-postmortem reads the transcripts Claude Code already wrote under `~/.claude/projects` and, for every Workflow run and every session with subagents, says which agents were killed (in a Workflow, often quietly started over), which never returned, which said "done" while their own result said otherwise, and which files and commits that left at risk. Then it lists at most 3 next steps. No setup, no proxy, no LLM, no network access, and it never changes your files.
+One night a background worker sat 8.5 hours on a permission prompt. Its job file said `blocked` and `approve Entering worktree`, the session that launched it heard nothing, and its agent list showed the worker as idle. With the plugin, that session reads this at its next tool call, and an idle session is woken for it: `WORKER night-run (a1b2c3d4) blocked 15m: waiting for a permission approval (approve Entering worktree). A person must approve it: claude attach a1b2c3d4`.
+
+Nothing has to be armed. The plugin reads the `claude --bg` in the session's own Bash call and follows that worker from then on. A permission prompt, a question, an API error, a failure, or a worker idle on a command that never ends is told once per change, and a worker that delivered gets a one-line note. `AGENT_POSTMORTEM_WAKE=0` keeps a session from being woken.
+
+Which "done" in your last Claude Code run can't you trust? agent-postmortem reads the transcripts Claude Code already wrote under `~/.claude/projects` and, for every Workflow run and every session with subagents, says which agents were killed (in a Workflow, often quietly started over), which never returned, which said "done" while their own result said otherwise, and which files and commits that left at risk. Then it lists at most 3 next steps. No setup, no proxy, no LLM, no network access, and it never changes your files.
 
 On the maintainer's machine (scan 2026-10-27, 0.3.2), 13 of 166 workflow runs launched at least one agent's task a second time, and 10.2 hours went to retries and to attempts that ended without a result.
 
@@ -67,7 +71,7 @@ Coverage today, checked against the failure reports in Claude Code's issue track
 | Subagents that never returned | covered | WORK AT RISK says `unknown` instead of `none`, and names them |
 | `claude -p` (headless) | partial | killed and unreturned subagents show; with the plugin, a foreground subagent that returns on an error or without its prompted output file is reported at once. The process's own exit status (for example exit 0 with `result: success` after a kill) is not in the transcript, so the tool cannot see it |
 | Background subagents (`run_in_background`) | partial | killed and unreturned ones show; a "completed" that arrived while the agent's own background work was still running, or with a tool call that never got a result, is not flagged yet |
-| `claude --bg` sessions | partial | each job's session is read like any session; `watch --session` and `status` pass the job's own state (working, blocked, done, stopped) through as Claude Code records it, and a resumed session hears which of its subagents never returned. Work still in flight inside the job is not modeled |
+| `claude --bg` sessions | partial | with the plugin, the session that launched a worker is told each change at its next tool call or prompt and woken when idle (permission prompt, question, API error, failure, a stuck command, delivered). `status` and `scan` give the same reason when someone runs them, and `watch --session` prints each state change. Not linked: a launch by a subagent, by another session, or by a Bash call that itself ran in the background; `status` and `scan` still list those. "No report past its expected time" is not covered, since nothing records an expected time |
 | Agent teams | not yet | teammates and their idle or blocked states are not modeled |
 | Cross-session messages (`SendMessage`) | not yet | whether a message was delivered is not checked |
 
@@ -117,7 +121,7 @@ Verdict: 0.3 stops guessing. Severity, the WORK AT RISK block, and the run's end
 | `agent-postmortem rescue status <run-id>` | Print what the main session's own transcript shows was run and observed after the run ended. Reports only what it saw, never a confirmation that a check passed. |
 | `agent-postmortem watch <run-id>` | Follow one running workflow: print START, then KILL, FAILED, OK (a result came back), and QUIET as they happen, then DONE or LIMIT. DONE comes the moment the session's own record says the run ended, or after a grace period once every journal key is resolved. Read-only, designed to be a Claude Code Monitor command. |
 | `agent-postmortem watch --session [<session-id>]` | Follow one session while it runs, for a Claude Code Monitor: a line only when a subagent is interrupted with nothing in the session to explain it, fails after changing files, or returns while its own last entry says otherwise, plus background-session state changes. With no id it follows the session you are in. |
-| `agent-postmortem status [<session-id>]` | One snapshot of a session: its subagents running, returned, interrupted or failed, what an interrupted one changed, returns its own transcript contradicts, and the background sessions' states. Reads only what was appended since the last call. |
+| `agent-postmortem status [<session-id>]` | One snapshot of a session: its subagents running, returned, interrupted or failed, what an interrupted one changed, returns its own transcript contradicts, and the background sessions' states with what each waits for and whether this session dispatched it (a session that is itself a background worker lists only the rows it launched). Reads only what was appended since the last call. |
 | `agent-postmortem statusline subagents` | A `subagentStatusLine` command: adds a fact to a row of Claude Code's subagent panel and leaves every other row as Claude Code draws it. |
 | `agent-postmortem hook <event>` | Claude Code plugin hook entry point; reads hook JSON from stdin. |
 
@@ -167,7 +171,7 @@ Install the command-line tool first (Quick start above), so the plugin finds it
 /plugin install agent-postmortem@agent-postmortem
 ```
 
-Its hooks shell out to the same CLI, never touch a run directory, and never fail a turn. After every tool call and on every prompt they check the session's own subagents: one that was interrupted with nothing in the session to explain it, failed after changing files, or returned while its own transcript contradicts the return is reported to the agent at its next tool call, once. A call with nothing new prints nothing. On `SessionStart` they summarize any run that finished since you last looked, and a resumed session hears which of its own subagents never returned. On `Stop` and `StopFailure` they check every subagent and workflow unit spawned so far and print a finding the moment it is detected, not only at session end. On `SessionEnd` they run the read-only tooling checks over the main thread itself. On a `Workflow` launch they register the run immediately, so it is tracked even before its own directory exists, and hand the session the `watch` command to arm as a Monitor. Two skills come with it: `/postmortem` for the verdict and `/rescue` for the bounded rescue protocol.
+Its hooks shell out to the same CLI, never touch a run directory, and never fail a turn. After every tool call and on every prompt they read the job files of the workers this session launched with `claude --bg` and tell each change once, in a `WORKER` line that says the state, the reason and what helps; at each Stop a watcher starts if there is something to follow, and it wakes the session when it has gone idle. It checks every 20 s, wakes at most once per 5 minutes, and leaves when the session acts again. It needs Claude Code 2.1.314 or later, a session already running starts it after `/reload-plugins` or a restart, and `AGENT_POSTMORTEM_WAKE=0` turns it off. After every tool call and on every prompt the hooks also check the session's own subagents: one that was interrupted with nothing in the session to explain it, failed after changing files, or returned while its own transcript contradicts the return is reported to the agent at its next tool call, once. A call with nothing new prints nothing. On `SessionStart` they summarize any run that finished since you last looked, and a resumed session hears which of its own subagents never returned. On `Stop` and `StopFailure` they check every subagent and workflow unit spawned so far and print a finding the moment it is detected, not only at session end. On `SessionEnd` they run the read-only tooling checks over the main thread itself. On a `Workflow` launch they register the run immediately, so it is tracked even before its own directory exists, and hand the session the `watch` command to arm as a Monitor. Two skills come with it: `/postmortem` for the verdict and `/rescue` for the bounded rescue protocol.
 
 For your own view, add the subagent panel command to `~/.claude/settings.json`, at the top level:
 
@@ -257,7 +261,7 @@ It was built across two Claude Code Workflow runs, and those same runs are among
 
 ## Limits
 
-The formats this tool parses are internal to Claude Code, not a published API, and were observed on versions 2.1.251 to 2.1.312; a future version can change them without notice. A few transcript entry types first seen in 2.1.285 to 2.1.310 (`tools-used`, `relocated`, `agent-setting`, `history-suppression`, `continued-in`) are not interpreted yet, so an attempt whose transcript holds one reads as "the tool cannot see all of what was written". Claude Code deletes transcripts older than 30 days by default (the `cleanupPeriodDays` setting), and with them the history `scan`, `trend` and `rules propose` read; raise that setting to keep more. A session's retries are not observable the way a workflow's are: a session has no cache key to compare attempts against, so `silent_retry` never fires on one. Whether a main-session interrupt was a human pressing Escape is not knowable from the transcript, so it is never attributed, only recorded as a limit. Tested on macOS and Linux only. The repository check (`run --observe`, `rescue status`) uses `git status` to inspect paths, with every filter driver switched off and no network transport allowed; in a repository with a sparse index or a split index, git's own `status` can still store a cached tree object or refresh the shared index file's timestamps, without changing tracked content, commits, or branches.
+The formats this tool parses are internal to Claude Code, not a published API, and were observed on versions 2.1.251 to 2.1.318; a future version can change them without notice. A few transcript entry types first seen in 2.1.285 to 2.1.310 (`tools-used`, `relocated`, `agent-setting`, `history-suppression`, `continued-in`) are not interpreted yet, so an attempt whose transcript holds one reads as "the tool cannot see all of what was written". Claude Code deletes transcripts older than 30 days by default (the `cleanupPeriodDays` setting), and with them the history `scan`, `trend` and `rules propose` read; raise that setting to keep more. A session's retries are not observable the way a workflow's are: a session has no cache key to compare attempts against, so `silent_retry` never fires on one. Whether a main-session interrupt was a human pressing Escape is not knowable from the transcript, so it is never attributed, only recorded as a limit. Tested on macOS and Linux only. The repository check (`run --observe`, `rescue status`) uses `git status` to inspect paths, with every filter driver switched off and no network transport allowed; in a repository with a sparse index or a split index, git's own `status` can still store a cached tree object or refresh the shared index file's timestamps, without changing tracked content, commits, or branches.
 
 ## Contributing