github-issue-tower-defence-management 1.143.0 → 1.143.2

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+## [1.143.2](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/compare/v1.143.1...v1.143.2) (2026-08-04)
+
+
+### Bug Fixes
+
+* **silent-monitor:** deliver the self-check reminder as a single line so no blank lines remain in the input box ([#1358](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1358)) ([08f4894](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/commit/08f489429da0136cb527efe3df2acb2b886f9a4e)), closes [#1357](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1357)
+
+## [1.143.1](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/compare/v1.143.0...v1.143.1) (2026-08-04)
+
+
+### Bug Fixes
+
+* **console:** expire the localStorage done overlay at each list regeneration ([#1352](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1352)) ([fd4b36a](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/commit/fd4b36a54ae2d826dcd35edcd3256a2a605d4153))
+
 # [1.143.0](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/compare/v1.142.3...v1.143.0) (2026-08-03)
 
 

package/README.md

@@ -597,11 +597,11 @@ 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` or has been running for `subAgentRunningThresholdSeconds`. It is composed of up to two 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. 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. Finished sub-agents are skipped, 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. Beyond the completion-or-termination marker at the end of the transcript, finished sub-agents are also excluded by two positive signals: 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`); the gate is skipped (fail-open) when the running set cannot be read, leaving the terminal-status and completion-marker exclusions as the sole guards. 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. 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. Whether a candidate session is actually re-injected is governed by the session-level fire-once latch described below, so a session with a persistent sub-process advisory is reminded once per silent episode rather than every cycle. A reminder that includes the main-session-stalled section is subject to the same fire-once latch and input-state gating, and 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` or has been running for `subAgentRunningThresholdSeconds`. It is composed of up to two 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. 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. Finished sub-agents are skipped, 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. Beyond the completion-or-termination marker at the end of the transcript, finished sub-agents are also excluded by two positive signals: 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`); the gate is skipped (fail-open) when the running set cannot be read, leaving the terminal-status and completion-marker exclusions as the sole guards. 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. 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.
 
-Each config key above has a matching environment variable read when the config key is unset: `TDPM_SILENT_NOTIFICATION_ENABLED` (the string `true` enables the step), `TDPM_SILENT_OWNER_CALL_MARKER`, `TDPM_SUBAGENT_OUTPUT_ROOT_DIRECTORY`, `TDPM_SUBAGENT_PROCESS_MATCH_PATTERN`, `TDPM_SUBAGENT_TRANSCRIPT_ROOT_DIRECTORY`, `TDPM_SUBAGENT_RUNTIME_ROOT_DIRECTORY`, `TDPM_MAIN_SILENT_THRESHOLD_SECONDS`, `TDPM_SILENT_UNANSWERED_OWNER_CALL_GRACE_SECONDS`, `TDPM_SUBAGENT_SILENT_THRESHOLD_SECONDS`, `TDPM_SUBAGENT_RUNNING_THRESHOLD_SECONDS`, `TDPM_SILENT_NOTIFICATION_STAGGER_SECONDS`, `TDPM_SILENT_CANDIDATE_DEBOUNCE_RECENCY_WINDOW_SECONDS`, `TDPM_SILENT_CANDIDATE_DEBOUNCE_STATE_FILE_PATH`, `TDPM_SILENT_NOTIFIED_STATE_FILE_PATH`, `TDPM_ACTIVE_HUB_TASK_STATUS`, `TDPM_SILENT_HUB_TASK_STATUS_CACHE_STATE_FILE_PATH`, `TDPM_SILENT_HUB_TASK_STATUS_CACHE_TTL_SECONDS`, `TDPM_SILENT_MAIN_STALLED_MESSAGE`, `TDPM_SILENT_MAIN_STALLED_STALE_OWNER_CALL_MESSAGE`, `TDPM_SILENT_SUBAGENT_IDLE_MESSAGE_HEADER`, `TDPM_SILENT_SUBAGENT_IDLE_MESSAGE_FOOTER`, `TDPM_SILENT_SUBAGENT_LONG_RUNNING_MESSAGE_HEADER`, and `TDPM_SILENT_SUBAGENT_LONG_RUNNING_MESSAGE_FOOTER`.
+Each config key above has a matching environment variable read when the config key is unset: `TDPM_SILENT_NOTIFICATION_ENABLED` (the string `true` enables the step), `TDPM_SILENT_OWNER_CALL_MARKER`, `TDPM_SUBAGENT_OUTPUT_ROOT_DIRECTORY`, `TDPM_SUBAGENT_PROCESS_MATCH_PATTERN`, `TDPM_SUBAGENT_TRANSCRIPT_ROOT_DIRECTORY`, `TDPM_SUBAGENT_RUNTIME_ROOT_DIRECTORY`, `TDPM_MAIN_SILENT_THRESHOLD_SECONDS`, `TDPM_SILENT_UNANSWERED_OWNER_CALL_GRACE_SECONDS`, `TDPM_SUBAGENT_SILENT_THRESHOLD_SECONDS`, `TDPM_SUBAGENT_RUNNING_THRESHOLD_SECONDS`, `TDPM_SILENT_NOTIFICATION_STAGGER_SECONDS`, `TDPM_SILENT_CANDIDATE_DEBOUNCE_RECENCY_WINDOW_SECONDS`, `TDPM_SILENT_CANDIDATE_DEBOUNCE_STATE_FILE_PATH`, `TDPM_ACTIVE_HUB_TASK_STATUS`, `TDPM_SILENT_HUB_TASK_STATUS_CACHE_STATE_FILE_PATH`, `TDPM_SILENT_HUB_TASK_STATUS_CACHE_TTL_SECONDS`, `TDPM_SILENT_MAIN_STALLED_MESSAGE`, `TDPM_SILENT_MAIN_STALLED_STALE_OWNER_CALL_MESSAGE`, `TDPM_SILENT_SUBAGENT_IDLE_MESSAGE_HEADER`, `TDPM_SILENT_SUBAGENT_IDLE_MESSAGE_FOOTER`, `TDPM_SILENT_SUBAGENT_LONG_RUNNING_MESSAGE_HEADER`, and `TDPM_SILENT_SUBAGENT_LONG_RUNNING_MESSAGE_FOOTER`.
 
 Each schedule cycle, when `outputDegenerationResetEnabled` is true, also inspects every live interactive Claude Code session named after a github.com issue or pull-request URL and resets a session whose output has collapsed into a repeat loop. A session is detected as degenerated when either of two independent conditions holds. The intra-turn condition looks at the session's most recent assistant turn and fires on any of three signatures: the longest consecutive run of an identical short token (at most 32 characters) is at least 5 and dominates at least 0.8 of the turn's tokens; or, after fenced code blocks, table rows, and list items are removed, an absolute consecutive run reaches at least 15 identical short tokens; or the duplicated 4-gram density of the filtered turn is at least 0.3 over at least 40 tokens. The cross-turn condition looks at the last 10 assistant turns and fires when the same isolated short purely-alphabetic trailing token recurs as the appended token in at least 4 of them. These thresholds are ported unchanged from the empirically-validated standalone monitor: healthy sessions never exceed 2 to 3 consecutive repeats of a single token in one turn and end turns with varied content, so both conditions have measured zero false positives. When a session is detected, a checkpoint warning is sent via `tmux send-keys`, the grace period is awaited, and the tmux session is killed so it is relaunched fresh; a per-session cooldown (default 300 seconds) prevents re-resetting the same session before its fresh relaunch completes. When `outputDegenerationResetEnabled` is not true the detection still runs and logs what it would do, but no warning or kill is performed, and any error during the step is logged and swallowed so the schedule cycle is never affected. Each config key above has a matching environment variable read when the config key is unset: `TDPM_OUTPUT_DEGENERATION_RESET_ENABLED` (the string `true` enables the step), `TDPM_OUTPUT_DEGENERATION_WARNING_MESSAGE`, `TDPM_OUTPUT_DEGENERATION_GRACE_SECONDS`, `TDPM_OUTPUT_DEGENERATION_COOLDOWN_SECONDS`, and `TDPM_OUTPUT_DEGENERATION_COOLDOWN_STATE_FILE_PATH`.