github-issue-tower-defence-management 1.117.8 → 1.117.10

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+## [1.117.10](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/compare/v1.117.9...v1.117.10) (2026-06-30)
+
+
+### Bug Fixes
+
+* **console:** make Reject gate consistent for inline comments on an issue's related PR diff ([#1126](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1126)) ([2177860](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/commit/2177860517cb9a34735afbd232dac49fbba01c45)), closes [#1125](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1125)
+
+## [1.117.9](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/compare/v1.117.8...v1.117.9) (2026-06-30)
+
+
+### Bug Fixes
+
+* debounce silent live-session notifications across two consecutive cycles ([#1121](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1121)) ([6be302a](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/commit/6be302ac61b97b2e3758f3811d84674a96c557ee))
+
 ## [1.117.8](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/compare/v1.117.7...v1.117.8) (2026-06-30)
 
 

package/README.md

@@ -293,6 +293,8 @@ mainSilentThresholdSeconds?: number # Optional: Seconds of main-session output s
 subAgentSilentThresholdSeconds?: number # Optional: Seconds of sub-process output silence after which the sub-process section is sent. Default 300
 subAgentRunningThresholdSeconds?: number # Optional: Seconds a sub-process may run before the sub-process section is sent regardless of its output silence. Default 900
 silentNotificationStaggerSeconds?: number # Optional: Seconds to wait between consecutive session notifications within one cycle, so the targets are notified sequentially rather than all at once. Default 25
+candidateDebounceRecencyWindowSeconds?: number # Optional: Recency window in seconds within which a session must have been recorded as a notification candidate in a previous cycle for the two-consecutive-cycle debounce to allow a notification this cycle. A small multiple of the schedule interval to tolerate interval jitter. Default 900
+candidateDebounceStateFilePath?: string # Optional: Path to the JSON state file that persists the per-cycle candidate session set used by the two-consecutive-cycle debounce. When unset, defaults to ${XDG_CACHE_HOME:-~/.cache}/tdpm/silent-session-candidates.json
 activeHubTaskStatus?: string # Optional: GitHub Project Status value that marks a session's hub task as still actively worked in an interactive session. For a session whose name is a `https://github.com/{owner}/{repo}/issues/{N}` issue URL, the hub task's latest Status is resolved before sending and the notification is skipped when the issue is closed or its Status differs from this value. Sessions whose name is not a github.com issue URL are never checked. When the hub task Status cannot be resolved, the notification is sent anyway (fail-open): a genuinely unresolvable hub task (the issue is not found, or its repository cannot be resolved by the token) is logged at info level without an error, while a real transient API error is logged as a warning so it stays visible. When unset, this hub-task active-status check is a no-op and existing behavior is preserved
 silentSubAgentMessageHeader?: string # Optional: Overrides the line shown above the sub-process list in the sub-process section. When unset, a generic built-in line is used
 silentSubAgentMessageFooter?: string # Optional: Overrides the line shown below the sub-process list in the sub-process section. When unset, a generic built-in line is used
@@ -561,9 +563,9 @@ The main-session stalled section is sent when the session's main output has been
 
 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`; the message lists each matched sub-process with its idle and running minutes. 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. Because sub-agents run in-process inside the parent session rather than as separate operating-system processes, no process-liveness signal can be matched back to a transcript; the completion-or-termination marker at the end of the transcript is the sole signal used to exclude finished sub-agents. 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.
 
-There is no per-session notification cooldown: every cycle, a session is notified whenever it still meets the silent-target condition (output silent at or beyond the threshold and not waiting on the owner). No suppression state is persisted. 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; this already prevents redundant nudges without a cooldown. 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 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 or moved to another Status is skipped; sessions whose name does not identify a github.com issue or pull request are never gated, and a hub task whose Status cannot be resolved fails open (the notification is sent): a genuinely unresolvable hub task (the issue is not found, or its repository cannot be resolved by the token) is logged at info level without an error, while a real transient API error is logged as a warning so it stays visible. 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.
+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 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 or moved to another Status is skipped; sessions whose name does not identify a github.com issue or pull request are never gated, and a hub task whose Status cannot be resolved fails open (the notification is sent): a genuinely unresolvable hub task (the issue is not found, or its repository cannot be resolved by the token) is logged at info level without an error, while a real transient API error is logged as a warning so it stays visible. 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_MAIN_SILENT_THRESHOLD_SECONDS`, `TDPM_SUBAGENT_SILENT_THRESHOLD_SECONDS`, `TDPM_SUBAGENT_RUNNING_THRESHOLD_SECONDS`, `TDPM_SILENT_NOTIFICATION_STAGGER_SECONDS`, `TDPM_ACTIVE_HUB_TASK_STATUS`, `TDPM_SILENT_MAIN_STALLED_MESSAGE`, `TDPM_SILENT_SUBAGENT_MESSAGE_HEADER`, and `TDPM_SILENT_SUBAGENT_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_MAIN_SILENT_THRESHOLD_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_MAIN_STALLED_MESSAGE`, `TDPM_SILENT_SUBAGENT_MESSAGE_HEADER`, and `TDPM_SILENT_SUBAGENT_MESSAGE_FOOTER`.
 
 ## Token Rotation Order File