github-issue-tower-defence-management 1.156.3 → 1.156.4

package/CHANGELOG.md

@@ -1,3 +1,10 @@
+## [1.156.4](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/compare/v1.156.3...v1.156.4) (2026-08-15)
+
+
+### Bug Fixes
+
+* **sub-agent-monitoring:** restore fail-open behavior when liveness record file is absent ([#1548](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1548)) ([db19f99](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/commit/db19f996bb10afb1565dc7f10752e8be7fb834f7)), closes [#1517](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1517)
+
 ## [1.156.3](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/compare/v1.156.2...v1.156.3) (2026-08-15)
 
 

package/README.md

@@ -332,8 +332,8 @@ silentNotificationEnabled?: boolean # Optional: Master switch for the silent liv
 subAgentOutputRootDirectory?: string # Optional: Root directory holding one output file per sub-process (file name derived from the sub-process label). The modification time of each file is read to compute how long the sub-process output has been idle. When unset, sub-process idle time is reported as 0 and only the running-time threshold can trigger a sub-process notification
 subAgentProcessMatchPattern?: string # Optional: Regular expression matched against each process command line to discover the sub-processes that belong to a monitored session. The expression must define a named capture group `session` whose value equals the monitored session name, and may define a named capture group `label` used as the display name. When unset, the sub-process check is skipped
 ownerCallMarker?: string # Optional: Marker substring that identifies an assistant message asking the owner for a decision or confirmation. When set, the main-session stalled section is suppressed while a session's latest marker-bearing assistant message is newer (by full timestamp) than its latest genuine owner reply. A marker ending with `>` also matches its candidate form, produced by replacing that trailing `>` with `-pending>`, so a configured `<call-to-user>` matches both `<call-to-user>` and `<call-to-user-pending>`; any marker not ending with `>` matches only itself. When unset, no session is treated as waiting on the owner
-subAgentTranscriptRootDirectory?: string # Optional: Projects root directory (for example `~/.claude/projects`) under which each session's transcript is stored as `<cwd-slug>/<sessionId>.jsonl` and its sub-agent transcripts live in the sibling `<cwd-slug>/<sessionId>/subagents/` directory as one `agent-<id>.jsonl` file per sub-agent. Because the on-disk directory is keyed by the session's working-directory slug and session id rather than by the tmux session name, the sub-agent directory is derived from the already-resolved main-session transcript path (the `.jsonl` suffix is stripped and `subagents` is appended). A sub-agent is treated as finished when the last meaningful entry of its transcript is a completion or termination marker: an assistant message whose `stop_reason` is `end_turn` or `stop_sequence`, an assistant message whose final content block is `text` (a final answer returned to the parent, which Claude Code often writes with a `null` `stop_reason`), a user message whose final content block is `text` (a terminal user entry such as `[Request interrupted by user]`), a user message whose final content block is a `tool_result` (the tool call completed and no assistant turn followed, the shape a sub-agent leaves when it ends right after its last tool — including the final `StructuredOutput` result — or when its process is gone), or a user message with no content blocks. A finished sub-agent is skipped only when it is no longer listed in the harness running-sub-agent set (`subAgentRuntimeRootDirectory`), or when that set cannot be read at all; a finished sub-agent the running set still lists is kept and reported as an unconsumed result, because the leader clears its record line once it has acted on the completion. Only a sub-agent whose last entry is an assistant message with a pending `tool_use` block and no following tool result is still considered active; its idle time is computed from the transcript file modification time (following symlinks) and the running time from its first entry timestamp. An active sub-agent whose pending tool command matches a live host process is classified as waiting on that external process and is exempt from the idle threshold (a genuinely hung sub-agent whose matching process is absent is still flagged), and the running threshold announces once per crossing per label. When set, this transcript-based discovery is used instead of `subAgentProcessMatchPattern`. When unset, the process-match discovery is used
-subAgentRuntimeRootDirectory?: string # Optional: Runtime root directory (for example `/tmp/claude-<uid>`) under which the harness writes each session's positive running-sub-agent set as `<cwd-slug>/<sessionId>/running-subagents.txt`. Each non-blank line has the form `<agentId> <label-or-branch-or-URL>`; only the first whitespace-delimited token of the line is taken as the sub-agent id, and any remaining text on the line (a label, branch name, or pull request URL) is ignored. Blank and whitespace-only lines are skipped. When transcript-based discovery is used, this enables a positive process-liveness gate: a sub-agent whose id is absent from the running set has already exited, so its stale on-disk transcript is not flagged even when its tail is a plain in-flight `tool_result`. Membership in the running set is also what distinguishes a consumed completion from an unconsumed one: a finished sub-agent the set still lists is reported as an unconsumed result and drives the unconsumed-result reminder section, while one absent from the set is dropped. When this directory is unset it defaults to `<os-tmpdir>/claude-<uid>` (or is disabled on platforms without a numeric user id); when the directory or the running-set file cannot be read the gate is skipped (fail-open) and the terminal-status and completion-marker exclusions remain the sole guards
+subAgentTranscriptRootDirectory?: string # Optional: Projects root directory (for example `~/.claude/projects`) under which each session's transcript is stored as `<cwd-slug>/<sessionId>.jsonl` and its sub-agent transcripts live in the sibling `<cwd-slug>/<sessionId>/subagents/` directory as one `agent-<id>.jsonl` file per sub-agent. Because the on-disk directory is keyed by the session's working-directory slug and session id rather than by the tmux session name, the sub-agent directory is derived from the already-resolved main-session transcript path (the `.jsonl` suffix is stripped and `subagents` is appended). A sub-agent is treated as finished when the last meaningful entry of its transcript is a completion or termination marker: an assistant message whose `stop_reason` is `end_turn` or `stop_sequence`, an assistant message whose final content block is `text` (a final answer returned to the parent, which Claude Code often writes with a `null` `stop_reason`), a user message whose final content block is `text` (a terminal user entry such as `[Request interrupted by user]`), a user message whose final content block is the `tool_result` of a `StructuredOutput` tool call (the structured output the sub-agent delivered as its final answer), or a user message with no content blocks. A finished sub-agent is skipped only when it is no longer listed in the harness running-sub-agent set (`subAgentRuntimeRootDirectory`), or when that set cannot be read at all; a finished sub-agent the running set still lists is kept and reported as an unconsumed result, because the leader clears its record line once it has acted on the completion. Only a sub-agent whose last entry is an assistant message with a pending `tool_use` block and no following tool result is still considered active; its idle time is computed from the transcript file modification time (following symlinks) and the running time from its first entry timestamp. An active sub-agent whose pending tool command matches a live host process is classified as waiting on that external process and is exempt from the idle threshold (a genuinely hung sub-agent whose matching process is absent is still flagged), and the running threshold announces once per crossing per label. When set, this transcript-based discovery is used instead of `subAgentProcessMatchPattern`. When unset, the process-match discovery is used
+subAgentRuntimeRootDirectory?: string # Optional: Runtime root directory (for example `/tmp/claude-<uid>`) under which each session's positive running-sub-agent set is expected at `<cwd-slug>/<sessionId>/running-subagents.txt`. Each non-blank line has the form `<agentId> <label-or-branch-or-URL>`; only the first whitespace-delimited token of the line is taken as the sub-agent id, and any remaining text on the line (a label, branch name, or pull request URL) is ignored. Blank and whitespace-only lines are skipped. When transcript-based discovery is used, this enables a positive process-liveness gate: a sub-agent whose id is absent from the running set has already exited, so its stale on-disk transcript is not flagged even when its tail is a plain in-flight `tool_result`. Membership in the running set is also what distinguishes a consumed completion from an unconsumed one: a finished sub-agent the set still lists is reported as an unconsumed result and drives the unconsumed-result reminder section, while one absent from the set is dropped. When this directory is unset it defaults to `<os-tmpdir>/claude-<uid>` (or is disabled on platforms without a numeric user id); when the directory or the running-set file cannot be read the gate is skipped (fail-open) and the terminal-status and completion-marker exclusions remain the sole guards
 mainSilentThresholdSeconds?: number # Optional: Seconds of main-session output silence after which the main-session self-check section is sent. Default 600
 unansweredOwnerCallGraceSeconds?: number # Optional: Retained only for backward compatibility of the configuration surface and no longer consulted. An unanswered owner call now suppresses the main-session stalled section unconditionally, with no age or grace expiry, so no value of this key changes any behaviour. Default 3600
 subAgentSilentThresholdSeconds?: number # Optional: Seconds of sub-process output silence after which the sub-process section is sent. Default 300
@@ -635,7 +635,7 @@ The main-session stalled section is sent when the session's main output has been
 
 The waiting-on-the-owner suppression is unconditional: whenever the session's latest owner call is newer than its latest genuine owner reply, the main-session stalled section is suppressed with no age or grace expiry, because the persistent unread indicator in the owner's app already covers a missed call. `unansweredOwnerCallGraceSeconds` (default 3600) is retained only for backward compatibility of the configuration surface and is no longer consulted, so the stale-owner-call reminder variant and its `silentMainStalledStaleOwnerCallMessage` override are currently never composed. The transcript-based owner-call detection still exposes the epoch timestamp of the latest unanswered owner call per session.
 
-The sub-process section is sent, regardless of main output, when at least one sub-process of the session has been output-idle for `subAgentSilentThresholdSeconds`, has been running for `subAgentRunningThresholdSeconds`, or has finished while its result stayed unconsumed for `subAgentSilentThresholdSeconds`. It is composed of up to three distinct messages, one per condition: an idle message that lists each sub-process that produced no output for at least `subAgentSilentThresholdSeconds` with its no-output minutes, tells the agent to treat that system-detected idle duration as the authoritative signal rather than re-deriving whether the sub-process is alive, forbids dismissing the signal from speculation, and requires the agent to determine the cause by a concrete check (whether there is genuinely no recent activity anywhere, including a very recent push or commit or output from nested sub-processes it started, versus being legitimately blocked on an external dependency such as a continuous-integration run, an external API, or another process), to act if stuck or state the waiting conclusion with concrete evidence if waiting, and to output that investigation result into the session as a log even though owner notification is not required, and a long-running message that lists each sub-process that has been running for at least `subAgentRunningThresholdSeconds` with its running minutes and asks the agent to verify it is genuinely advancing rather than caught in an infinite loop, a task that is too large, or a stuck approach. The long-running message foregrounds the running duration and does not surface the short idle time, so a sub-process flagged only for running long is not dismissed because its silent time looks small; a sub-process that matches both conditions appears in both messages. The long-running threshold is overridable per project via `subAgentRunningThresholdSeconds` (default 900 seconds) for repositories whose continuous integration legitimately runs longer. The third message is the unconsumed-result message: it lists each finished sub-process whose result has been waiting unread for at least `subAgentSilentThresholdSeconds` with the whole minutes it has been waiting, and asks the agent to read that result, act on it, and then mark the sub-process finished so it is no longer tracked as running. A finished sub-process is recognized as unconsumed while it is still listed in the harness running set, because the leader removes that record line once it has acted on the completion, and its waiting time is the age of the last transcript write. This condition is evaluated independently of main-session silence, so a leader that keeps producing output while a finished sub-process result sits unread is still reminded. A finished sub-process never appears in the idle or long-running messages; those two remain restricted to sub-processes that are still working. Sub-processes are discovered in one of two ways: when `subAgentTranscriptRootDirectory` is configured, each session's `subagents/agent-<id>.jsonl` transcripts are scanned. The sub-agent directory is the `subagents/` directory that sits next to the session's already-resolved main-session transcript file under `projects/<cwd-slug>/<sessionId>/subagents/`, derived by stripping the `.jsonl` suffix from the main-session transcript path and appending `subagents`; this on-disk path is keyed by the session's working-directory slug and session id, not by the tmux session name. Whether a sub-agent has finished is determined from the last meaningful transcript entry rather than from the last non-null `stop_reason` seen anywhere in the file. A sub-agent is treated as finished when its last entry is a completion or termination marker: an assistant message whose `stop_reason` is `end_turn` or `stop_sequence`, an assistant message whose final content block is `text` (a final answer returned to the parent, which Claude Code often writes with a `null` `stop_reason`), a user message whose final content block is `text` (a terminal user entry such as `[Request interrupted by user]`), a user message whose final content block is a `tool_result`, or a user message with no content blocks. The `tool_result` and empty-user terminal shapes are the ones a sub-agent leaves when it ends right after its last tool call completes — for example the `tool_result` of the final `StructuredOutput` call a sub-agent uses to return its result, the launch acknowledgement of a background command, or any other tool whose result is written but no assistant turn follows because the sub-agent's process is gone (killed, crashed, or token-exhausted). Recognizing these shapes as terminal is what lets a marker-less dead transcript be excluded by the completion signal itself rather than by an age cap. Only a sub-agent whose last entry is an assistant message with a pending `tool_use` block and no following tool result is still considered active and subject to the idle and running thresholds; this is the genuinely-incomplete shape — the sub-agent requested a tool that never returned and is hung mid-work. Idle time is taken from the transcript file modification time (following symlinks) while running time is taken from its first entry timestamp. Two positive signals drop a sub-agent outright: a parent-transcript task notification whose `<status>` is a terminal value (`completed`, `killed`, `stopped`, or `failed`) drops every `<task-id>` it lists, and, when `subAgentRuntimeRootDirectory` is configured, a process-liveness gate drops any sub-agent id absent from the harness running set (`running-subagents.txt`). A sub-agent that survives both signals and whose transcript ends in a completion or termination marker is the unconsumed-result case: it is still listed in the running set, so it is retained and reported with its completion state and the age of its last transcript write instead of being discarded, which is what lets the unconsumed-result message be composed. When the running set cannot be read at all, the completion marker alone excludes the sub-agent, because an unconsumed result cannot be distinguished from an already-cleared one without that set. There is no age cap: a sub-agent that is past the idle or running threshold and does not end in a completion or termination marker is flagged regardless of how long it has been silent, so a genuinely-stuck sub-agent that has been hung on a pending tool call for hours or days is still reported instead of being silently dropped. Otherwise sub-processes are discovered by matching `subAgentProcessMatchPattern` against process command lines. Because a sub-agent inside a single blocking call (for example a continuous-integration watch) is otherwise indistinguishable from a hung one, the transcript-based discovery additionally judges the sub-agent's actual wait state instead of applying any time-window suppression. A sub-agent whose transcript tail is an in-flight tool call — the last entry is an assistant tool-use with no following tool result — carrying a command string is classified as WAITING when a live process matching that command exists on the host: each pending tool command is normalized (whitespace collapsed, first 60 characters) and searched as a substring of the normalized host process command lines (`ps -eo etimes=,args=`, supplied through the injectable process lister). A WAITING sub-agent never produces an idle (no-output) reminder, no matter how long its transcript has been silent. The long-running message is selected on elapsed running time alone and is not affected by either signal: a sub-process that keeps producing output, and a sub-process classified as WAITING on a live external process, are both still reported once they pass `subAgentRunningThresholdSeconds`, because producing output and waiting on a long external command are exactly the states a genuinely long-running sub-process is normally in. This selection is also independent of whether the main session is silent, so a leader that is actively working is still told how long each of its sub-processes has been running. A sub-agent whose in-flight tool call has no matching live process is genuinely hung and its session is re-selected as a candidate on every qualifying cycle. A session that stays a candidate is re-injected on every qualifying cycle: there is no per-episode cap, so a session with a persistent sub-process advisory, and a session whose main output stays silent, are both reminded again each cycle until the condition clears. Main-session stall detection behavior is otherwise unchanged.
+The sub-process section is sent, regardless of main output, when at least one sub-process of the session has been output-idle for `subAgentSilentThresholdSeconds`, has been running for `subAgentRunningThresholdSeconds`, or has finished while its result stayed unconsumed for `subAgentSilentThresholdSeconds`. It is composed of up to three distinct messages, one per condition: an idle message that lists each sub-process that produced no output for at least `subAgentSilentThresholdSeconds` with its no-output minutes, tells the agent to treat that system-detected idle duration as the authoritative signal rather than re-deriving whether the sub-process is alive, forbids dismissing the signal from speculation, and requires the agent to determine the cause by a concrete check (whether there is genuinely no recent activity anywhere, including a very recent push or commit or output from nested sub-processes it started, versus being legitimately blocked on an external dependency such as a continuous-integration run, an external API, or another process), to act if stuck or state the waiting conclusion with concrete evidence if waiting, and to output that investigation result into the session as a log even though owner notification is not required, and a long-running message that lists each sub-process that has been running for at least `subAgentRunningThresholdSeconds` with its running minutes and asks the agent to verify it is genuinely advancing rather than caught in an infinite loop, a task that is too large, or a stuck approach. The long-running message foregrounds the running duration and does not surface the short idle time, so a sub-process flagged only for running long is not dismissed because its silent time looks small; a sub-process that matches both conditions appears in both messages. The long-running threshold is overridable per project via `subAgentRunningThresholdSeconds` (default 900 seconds) for repositories whose continuous integration legitimately runs longer. The third message is the unconsumed-result message: it lists each finished sub-process whose result has been waiting unread for at least `subAgentSilentThresholdSeconds` with the whole minutes it has been waiting, and asks the agent to read that result, act on it, and then mark the sub-process finished so it is no longer tracked as running. A finished sub-process is recognized as unconsumed while it is still listed in the harness running set, because the leader removes that record line once it has acted on the completion, and its waiting time is the age of the last transcript write. This condition is evaluated independently of main-session silence, so a leader that keeps producing output while a finished sub-process result sits unread is still reminded. A finished sub-process never appears in the idle or long-running messages; those two remain restricted to sub-processes that are still working. Sub-processes are discovered in one of two ways: when `subAgentTranscriptRootDirectory` is configured, each session's `subagents/agent-<id>.jsonl` transcripts are scanned. The sub-agent directory is the `subagents/` directory that sits next to the session's already-resolved main-session transcript file under `projects/<cwd-slug>/<sessionId>/subagents/`, derived by stripping the `.jsonl` suffix from the main-session transcript path and appending `subagents`; this on-disk path is keyed by the session's working-directory slug and session id, not by the tmux session name. Whether a sub-agent has finished is determined from the last meaningful transcript entry rather than from the last non-null `stop_reason` seen anywhere in the file. A sub-agent is treated as finished when its last entry is a completion or termination marker: an assistant message whose `stop_reason` is `end_turn` or `stop_sequence`, an assistant message whose final content block is `text` (a final answer returned to the parent, which Claude Code often writes with a `null` `stop_reason`), a user message whose final content block is `text` (a terminal user entry such as `[Request interrupted by user]`), a user message whose final content block is the `tool_result` of a `StructuredOutput` tool call (the structured output the sub-agent delivered as its final answer), or a user message with no content blocks. Only a sub-agent whose last entry is an assistant message with a pending `tool_use` block and no following tool result is still considered active and subject to the idle and running thresholds; this is the genuinely-incomplete shape — the sub-agent requested a tool that never returned and is hung mid-work. A plain trailing `tool_result` (from any tool other than `StructuredOutput`) is not treated as a completion marker, because a live agent alternates between pending `tool_use` and `tool_result` entries as tools complete; treating it as terminal would make an active agent flap in and out of the snapshot. Idle time is taken from the transcript file modification time (following symlinks) while running time is taken from its first entry timestamp. Two positive signals drop a sub-agent outright: a parent-transcript task notification whose `<status>` is a terminal value (`completed`, `killed`, `stopped`, or `failed`) drops every `<task-id>` it lists, and, when `subAgentRuntimeRootDirectory` is configured, a process-liveness gate drops any sub-agent id absent from the harness running set (`running-subagents.txt`). A sub-agent that survives both signals and whose transcript ends in a completion or termination marker is the unconsumed-result case: it is still listed in the running set, so it is retained and reported with its completion state and the age of its last transcript write instead of being discarded, which is what lets the unconsumed-result message be composed. When the running set cannot be read at all, the completion marker alone excludes the sub-agent, because an unconsumed result cannot be distinguished from an already-cleared one without that set. There is no age cap: a sub-agent that is past the idle or running threshold and does not end in a completion or termination marker is flagged regardless of how long it has been silent, so a genuinely-stuck sub-agent that has been hung on a pending tool call for hours or days is still reported instead of being silently dropped. Otherwise sub-processes are discovered by matching `subAgentProcessMatchPattern` against process command lines. Because a sub-agent inside a single blocking call (for example a continuous-integration watch) is otherwise indistinguishable from a hung one, the transcript-based discovery additionally judges the sub-agent's actual wait state instead of applying any time-window suppression. A sub-agent whose transcript tail is an in-flight tool call — the last entry is an assistant tool-use with no following tool result — carrying a command string is classified as WAITING when a live process matching that command exists on the host: each pending tool command is normalized (whitespace collapsed, first 60 characters) and searched as a substring of the normalized host process command lines (`ps -eo etimes=,args=`, supplied through the injectable process lister). A WAITING sub-agent never produces an idle (no-output) reminder, no matter how long its transcript has been silent. The long-running message is selected on elapsed running time alone and is not affected by either signal: a sub-process that keeps producing output, and a sub-process classified as WAITING on a live external process, are both still reported once they pass `subAgentRunningThresholdSeconds`, because producing output and waiting on a long external command are exactly the states a genuinely long-running sub-process is normally in. This selection is also independent of whether the main session is silent, so a leader that is actively working is still told how long each of its sub-processes has been running. A sub-agent whose in-flight tool call has no matching live process is genuinely hung and its session is re-selected as a candidate on every qualifying cycle. A session that stays a candidate is re-injected on every qualifying cycle: there is no per-episode cap, so a session with a persistent sub-process advisory, and a session whose main output stays silent, are both reminded again each cycle until the condition clears. Main-session stall detection behavior is otherwise unchanged.
 
 A two-consecutive-cycle debounce guards against transient false positives: a session is notified only when it meets the silent-target condition (output silent at or beyond the threshold and not waiting on the owner) in the current cycle and it was also a notification candidate in the immediately previous cycle. The set of candidate session names is persisted across cycles, keyed by the globally-unique session name, in a state file written atomically (the default path is `${XDG_CACHE_HOME:-~/.cache}/tdpm/silent-session-candidates.json`, overridable via `candidateDebounceStateFilePath`). The monitor runs as a fresh process each schedule cycle, so this on-disk state is what carries the previous cycle's candidate set forward. Each cycle loads the candidate set recorded within `candidateDebounceRecencyWindowSeconds` of now (default 900, a small multiple of the schedule interval to tolerate interval jitter), then records the current candidate set with the current timestamp; entries that age past the retention window are dropped on the next save, and a save merges with other recently-recorded session names so concurrent per-project runs do not clobber each other. A candidate that appears for only one isolated cycle — for example because the owner's reply has not yet been flushed to the transcript when the monitor reads it, or because a transient hub-task status resolution error fails open for a single cycle — is therefore deferred and never notified, while a genuine stall that persists across cycles is still caught, one cycle later. Because silence is measured from the latest transcript entry of any type — including the monitor's own injected reminder and the owner's reply — a notified session's measured silence resets as soon as it produces any activity, so a session that has resumed is not re-flagged. When more than one session is notified in the same cycle, the sends are spaced out sequentially with `silentNotificationStaggerSeconds` between consecutive sends (no wait before the first or after the last) so the targets are not all triggered at once. When `activeHubTaskStatus` is configured, each notification is gated on the latest GitHub state and Project Status of the session's hub task: a session whose name identifies a github.com issue or pull request — accepted both as a clean `https://github.com/{owner}/{repo}/issues/{N}` URL and as the real tmux session-name form `https_//github_com/{owner}/{repo}/issues/{N}` produced by replacing `.` and `:` with `_` (the `pull` path is accepted in both forms too) — is notified only while that hub task is open and in the configured active Status, so a session whose hub task has been closed, merged, or moved to another Status (for example Done) is suppressed; sessions whose name does not identify a github.com issue or pull request are never gated. To cut GitHub query load and remove most fail-opens, each resolved status is cached by issue URL in a state file written atomically (the default path is `${XDG_CACHE_HOME:-~/.cache}/tdpm/silent-session-hub-task-status.json`, overridable via `hubTaskStatusCacheStateFilePath`). On each cycle the gate reads the cache first: a cached entry recorded within `hubTaskStatusCacheTtlSeconds` of now (default 300) decides the gate without any GitHub query, and otherwise the hub task is re-resolved and the result written back to the cache. When live resolution fails — the resolver returns no tracked task (a closed or Done issue filtered out of the active project), or a transient API error is thrown — the gate falls back to the cached status even after it has expired: a cached active entry keeps the notification (still notified if genuinely stalled) and a cached closed or non-active entry suppresses it, each logged with a distinct warning. Only when there is no cached status at all and live resolution fails does the gate fail open once (a closed issue and a transient error are indistinguishable in that case without an extra network call), logging a distinct warning, so the next cycle can populate the cache. When `activeHubTaskStatus` is unset, this hub-task check is a no-op. Process-snapshot collection, transcript resolution, owner-call detection, the wait between sends, and the message wording are all performed through injectable ports, so the logic is unit-testable without touching the host, and the host-specific process and environment access, sub-process pattern, and message wording are supplied through adapters or configuration. When `silentNotificationEnabled` is not true the step is a no-op, and any error during the step is logged and swallowed so the schedule cycle is never affected.
 

package/bin/adapter/repositories/FileSystemSubAgentLivenessResolver.js

@@ -37,10 +37,6 @@ exports.FileSystemSubAgentLivenessResolver = void 0;
 const fs = __importStar(require("fs"));
 const path = __importStar(require("path"));
 const RUNNING_SUBAGENTS_FILE_NAME = 'running-subagents.txt';
-const isMissingFileError = (error) => typeof error === 'object' &&
-    error !== null &&
-    'code' in error &&
-    error.code === 'ENOENT';
 class FileSystemSubAgentLivenessResolver {
     constructor(runtimeRootDirectory) {
         this.runtimeRootDirectory = runtimeRootDirectory;
@@ -53,10 +49,7 @@ class FileSystemSubAgentLivenessResolver {
             try {
                 content = fs.readFileSync(runningFilePath, 'utf8');
             }
-            catch (error) {
-                if (isMissingFileError(error) && this.hasReadableRuntimeRootDirectory()) {
-                    return new Set();
-                }
+            catch {
                 return null;
             }
             const liveIds = new Set();
@@ -68,17 +61,6 @@ class FileSystemSubAgentLivenessResolver {
             }
             return liveIds;
         };
-        this.hasReadableRuntimeRootDirectory = () => {
-            if (this.runtimeRootDirectory === null) {
-                return false;
-            }
-            try {
-                return fs.statSync(this.runtimeRootDirectory).isDirectory();
-            }
-            catch {
-                return false;
-            }
-        };
         this.resolveRunningSubAgentsFilePath = (mainTranscriptPath) => {
             if (this.runtimeRootDirectory === null || mainTranscriptPath === null) {
                 return null;

package/bin/adapter/repositories/FileSystemSubAgentLivenessResolver.js.map

@@ -1 +1 @@
-{"version":3,"file":"FileSystemSubAgentLivenessResolver.js","sourceRoot":"","sources":["../../../src/adapter/repositories/FileSystemSubAgentLivenessResolver.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAAA,uCAAyB;AACzB,2CAA6B;AAG7B,MAAM,2BAA2B,GAAG,uBAAuB,CAAC;AAE5D,MAAM,kBAAkB,GAAG,CAAC,KAAc,EAAW,EAAE,CACrD,OAAO,KAAK,KAAK,QAAQ;IACzB,KAAK,KAAK,IAAI;IACd,MAAM,IAAI,KAAK;IACf,KAAK,CAAC,IAAI,KAAK,QAAQ,CAAC;AAE1B,MAAa,kCAAkC;IAC7C,YAA6B,oBAAmC;QAAnC,yBAAoB,GAApB,oBAAoB,CAAe;QAEhE,2BAAsB,GAAG,KAAK,EAAE,MAG/B,EAA+B,EAAE;YAChC,MAAM,eAAe,GAAG,IAAI,CAAC,+BAA+B,CAC1D,MAAM,CAAC,kBAAkB,CAC1B,CAAC;YACF,IAAI,eAAe,KAAK,IAAI,EAAE,CAAC;gBAC7B,OAAO,IAAI,CAAC;YACd,CAAC;YACD,IAAI,OAAe,CAAC;YACpB,IAAI,CAAC;gBACH,OAAO,GAAG,EAAE,CAAC,YAAY,CAAC,eAAe,EAAE,MAAM,CAAC,CAAC;YACrD,CAAC;YAAC,OAAO,KAAK,EAAE,CAAC;gBACf,IAAI,kBAAkB,CAAC,KAAK,CAAC,IAAI,IAAI,CAAC,+BAA+B,EAAE,EAAE,CAAC;oBACxE,OAAO,IAAI,GAAG,EAAE,CAAC;gBACnB,CAAC;gBACD,OAAO,IAAI,CAAC;YACd,CAAC;YACD,MAAM,OAAO,GAAG,IAAI,GAAG,EAAU,CAAC;YAClC,KAAK,MAAM,IAAI,IAAI,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC;gBACvC,MAAM,OAAO,GAAG,IAAI,CAAC,IAAI,EAAE,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC;gBAC5C,IAAI,OAAO,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;oBACvB,OAAO,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC;gBACvB,CAAC;YACH,CAAC;YACD,OAAO,OAAO,CAAC;QACjB,CAAC,CAAC;QAEM,oCAA+B,GAAG,GAAY,EAAE;YACtD,IAAI,IAAI,CAAC,oBAAoB,KAAK,IAAI,EAAE,CAAC;gBACvC,OAAO,KAAK,CAAC;YACf,CAAC;YACD,IAAI,CAAC;gBACH,OAAO,EAAE,CAAC,QAAQ,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC,WAAW,EAAE,CAAC;YAC9D,CAAC;YAAC,MAAM,CAAC;gBACP,OAAO,KAAK,CAAC;YACf,CAAC;QACH,CAAC,CAAC;QAEM,oCAA+B,GAAG,CACxC,kBAAiC,EAClB,EAAE;YACjB,IAAI,IAAI,CAAC,oBAAoB,KAAK,IAAI,IAAI,kBAAkB,KAAK,IAAI,EAAE,CAAC;gBACtE,OAAO,IAAI,CAAC;YACd,CAAC;YACD,MAAM,WAAW,GAAG,IAAI,CAAC,QAAQ,CAAC,kBAAkB,EAAE,QAAQ,CAAC,CAAC;YAChE,IAAI,WAAW,CAAC,MAAM,KAAK,CAAC,IAAI,WAAW,CAAC,QAAQ,CAAC,QAAQ,CAAC,EAAE,CAAC;gBAC/D,OAAO,IAAI,CAAC;YACd,CAAC;YACD,MAAM,OAAO,GAAG,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,OAAO,CAAC,kBAAkB,CAAC,CAAC,CAAC;YAChE,IAAI,OAAO,CAAC,MAAM,KAAK,CAAC,IAAI,OAAO,KAAK,GAAG,EAAE,CAAC;gBAC5C,OAAO,IAAI,CAAC;YACd,CAAC;YACD,OAAO,IAAI,CAAC,IAAI,CACd,IAAI,CAAC,oBAAoB,EACzB,OAAO,EACP,WAAW,EACX,2BAA2B,CAC5B,CAAC;QACJ,CAAC,CAAC;IA9DiE,CAAC;CA+DrE;AAhED,gFAgEC"}
+{"version":3,"file":"FileSystemSubAgentLivenessResolver.js","sourceRoot":"","sources":["../../../src/adapter/repositories/FileSystemSubAgentLivenessResolver.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AAAA,uCAAyB;AACzB,2CAA6B;AAG7B,MAAM,2BAA2B,GAAG,uBAAuB,CAAC;AAE5D,MAAa,kCAAkC;IAC7C,YAA6B,oBAAmC;QAAnC,yBAAoB,GAApB,oBAAoB,CAAe;QAEhE,2BAAsB,GAAG,KAAK,EAAE,MAG/B,EAA+B,EAAE;YAChC,MAAM,eAAe,GAAG,IAAI,CAAC,+BAA+B,CAC1D,MAAM,CAAC,kBAAkB,CAC1B,CAAC;YACF,IAAI,eAAe,KAAK,IAAI,EAAE,CAAC;gBAC7B,OAAO,IAAI,CAAC;YACd,CAAC;YACD,IAAI,OAAe,CAAC;YACpB,IAAI,CAAC;gBACH,OAAO,GAAG,EAAE,CAAC,YAAY,CAAC,eAAe,EAAE,MAAM,CAAC,CAAC;YACrD,CAAC;YAAC,MAAM,CAAC;gBACP,OAAO,IAAI,CAAC;YACd,CAAC;YACD,MAAM,OAAO,GAAG,IAAI,GAAG,EAAU,CAAC;YAClC,KAAK,MAAM,IAAI,IAAI,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC;gBACvC,MAAM,OAAO,GAAG,IAAI,CAAC,IAAI,EAAE,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC;gBAC5C,IAAI,OAAO,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;oBACvB,OAAO,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC;gBACvB,CAAC;YACH,CAAC;YACD,OAAO,OAAO,CAAC;QACjB,CAAC,CAAC;QAEM,oCAA+B,GAAG,CACxC,kBAAiC,EAClB,EAAE;YACjB,IAAI,IAAI,CAAC,oBAAoB,KAAK,IAAI,IAAI,kBAAkB,KAAK,IAAI,EAAE,CAAC;gBACtE,OAAO,IAAI,CAAC;YACd,CAAC;YACD,MAAM,WAAW,GAAG,IAAI,CAAC,QAAQ,CAAC,kBAAkB,EAAE,QAAQ,CAAC,CAAC;YAChE,IAAI,WAAW,CAAC,MAAM,KAAK,CAAC,IAAI,WAAW,CAAC,QAAQ,CAAC,QAAQ,CAAC,EAAE,CAAC;gBAC/D,OAAO,IAAI,CAAC;YACd,CAAC;YACD,MAAM,OAAO,GAAG,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,OAAO,CAAC,kBAAkB,CAAC,CAAC,CAAC;YAChE,IAAI,OAAO,CAAC,MAAM,KAAK,CAAC,IAAI,OAAO,KAAK,GAAG,EAAE,CAAC;gBAC5C,OAAO,IAAI,CAAC;YACd,CAAC;YACD,OAAO,IAAI,CAAC,IAAI,CACd,IAAI,CAAC,oBAAoB,EACzB,OAAO,EACP,WAAW,EACX,2BAA2B,CAC5B,CAAC;QACJ,CAAC,CAAC;IAhDiE,CAAC;CAiDrE;AAlDD,gFAkDC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "github-issue-tower-defence-management",
-  "version": "1.156.3",
+  "version": "1.156.4",
   "description": "",
   "main": "bin/index.js",
   "scripts": {

package/src/adapter/repositories/FileSystemSubAgentLivenessResolver.test.ts

@@ -69,7 +69,7 @@ describe('FileSystemSubAgentLivenessResolver', () => {
     expect(result).toEqual(new Set());
   });
 
-  it('returns an empty set when the runtime root exists and the session has no running file', async () => {
+  it('returns null when the runtime root exists and the session has no running file', async () => {
     const resolver = new FileSystemSubAgentLivenessResolver(runtimeRoot);
 
     const result = await resolver.resolveLiveSubAgentIds({
@@ -77,7 +77,7 @@ describe('FileSystemSubAgentLivenessResolver', () => {
       mainTranscriptPath,
     });
 
-    expect(result).toEqual(new Set());
+    expect(result).toBeNull();
   });
 
   it('returns null when the configured runtime root directory does not exist', async () => {
@@ -192,7 +192,7 @@ describe('running-subagents record agent id contract with TranscriptSessionSubAg
     ]);
   });
 
-  it('reports no sub-agent when the runtime root exists and the session has no running-subagents record', async () => {
+  it('detects a working sub-agent when the runtime root exists and the session has no running-subagents record', async () => {
     const subAgentsDirectory = path.join(
       transcriptRoot,
       cwdSlug,
@@ -224,6 +224,14 @@ describe('running-subagents record agent id contract with TranscriptSessionSubAg
       new Map([[sessionName, mainTranscriptPath]]),
     );
 
-    expect(result.get(sessionName)).toBeUndefined();
+    expect(result.get(sessionName)).toEqual([
+      {
+        label: `agent-${liveAgentId}`,
+        silentSeconds: 0,
+        runningSeconds: 694800,
+        waitingOnExternalProcess: false,
+        finishedResultUnconsumed: false,
+      },
+    ]);
   });
 });

package/src/adapter/repositories/FileSystemSubAgentLivenessResolver.ts

@@ -4,12 +4,6 @@ import { SubAgentLivenessResolver } from '../../domain/usecases/adapter-interfac
 
 const RUNNING_SUBAGENTS_FILE_NAME = 'running-subagents.txt';
 
-const isMissingFileError = (error: unknown): boolean =>
-  typeof error === 'object' &&
-  error !== null &&
-  'code' in error &&
-  error.code === 'ENOENT';
-
 export class FileSystemSubAgentLivenessResolver implements SubAgentLivenessResolver {
   constructor(private readonly runtimeRootDirectory: string | null) {}
 
@@ -26,10 +20,7 @@ export class FileSystemSubAgentLivenessResolver implements SubAgentLivenessResol
     let content: string;
     try {
       content = fs.readFileSync(runningFilePath, 'utf8');
-    } catch (error) {
-      if (isMissingFileError(error) && this.hasReadableRuntimeRootDirectory()) {
-        return new Set();
-      }
+    } catch {
       return null;
     }
     const liveIds = new Set<string>();
@@ -42,17 +33,6 @@ export class FileSystemSubAgentLivenessResolver implements SubAgentLivenessResol
     return liveIds;
   };
 
-  private hasReadableRuntimeRootDirectory = (): boolean => {
-    if (this.runtimeRootDirectory === null) {
-      return false;
-    }
-    try {
-      return fs.statSync(this.runtimeRootDirectory).isDirectory();
-    } catch {
-      return false;
-    }
-  };
-
   private resolveRunningSubAgentsFilePath = (
     mainTranscriptPath: string | null,
   ): string | null => {

package/types/adapter/repositories/FileSystemSubAgentLivenessResolver.d.ts

@@ -6,7 +6,6 @@ export declare class FileSystemSubAgentLivenessResolver implements SubAgentLiven
         sessionName: string;
         mainTranscriptPath: string | null;
     }) => Promise<Set<string> | null>;
-    private hasReadableRuntimeRootDirectory;
     private resolveRunningSubAgentsFilePath;
 }
 //# sourceMappingURL=FileSystemSubAgentLivenessResolver.d.ts.map

package/types/adapter/repositories/FileSystemSubAgentLivenessResolver.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"FileSystemSubAgentLivenessResolver.d.ts","sourceRoot":"","sources":["../../../src/adapter/repositories/FileSystemSubAgentLivenessResolver.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,wBAAwB,EAAE,MAAM,mEAAmE,CAAC;AAU7G,qBAAa,kCAAmC,YAAW,wBAAwB;IACrE,OAAO,CAAC,QAAQ,CAAC,oBAAoB;gBAApB,oBAAoB,EAAE,MAAM,GAAG,IAAI;IAEhE,sBAAsB,GAAU,QAAQ;QACtC,WAAW,EAAE,MAAM,CAAC;QACpB,kBAAkB,EAAE,MAAM,GAAG,IAAI,CAAC;KACnC,KAAG,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,GAAG,IAAI,CAAC,CAwB7B;IAEF,OAAO,CAAC,+BAA+B,CASrC;IAEF,OAAO,CAAC,+BAA+B,CAoBrC;CACH"}
+{"version":3,"file":"FileSystemSubAgentLivenessResolver.d.ts","sourceRoot":"","sources":["../../../src/adapter/repositories/FileSystemSubAgentLivenessResolver.ts"],"names":[],"mappings":"AAEA,OAAO,EAAE,wBAAwB,EAAE,MAAM,mEAAmE,CAAC;AAI7G,qBAAa,kCAAmC,YAAW,wBAAwB;IACrE,OAAO,CAAC,QAAQ,CAAC,oBAAoB;gBAApB,oBAAoB,EAAE,MAAM,GAAG,IAAI;IAEhE,sBAAsB,GAAU,QAAQ;QACtC,WAAW,EAAE,MAAM,CAAC;QACpB,kBAAkB,EAAE,MAAM,GAAG,IAAI,CAAC;KACnC,KAAG,OAAO,CAAC,GAAG,CAAC,MAAM,CAAC,GAAG,IAAI,CAAC,CAqB7B;IAEF,OAAO,CAAC,+BAA+B,CAoBrC;CACH"}