github-issue-tower-defence-management 1.117.9 → 1.118.0

package/CHANGELOG.md

@@ -1,3 +1,17 @@
+# [1.118.0](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/compare/v1.117.10...v1.118.0) (2026-06-30)
+
+
+### Features
+
+* split sub-agent stall reminder into distinct idle and long-running messages ([#1124](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1124)) ([78e0be1](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/commit/78e0be11e5482b91cbdac1eace1ee3e04749688f)), closes [#1123](https://github.com/HiromiShikata/npm-cli-github-issue-tower-defence-management/issues/1123)
+
+## [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)
 
 

package/README.md

@@ -296,8 +296,10 @@ silentNotificationStaggerSeconds?: number # Optional: Seconds to wait between co
 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
+silentSubAgentIdleMessageHeader?: string # Optional: Overrides the line shown above the sub-process list in the idle (no-output) sub-process message. When unset, a generic built-in line is used
+silentSubAgentIdleMessageFooter?: string # Optional: Overrides the line shown below the sub-process list in the idle (no-output) sub-process message. When unset, a generic built-in line is used
+silentSubAgentLongRunningMessageHeader?: string # Optional: Overrides the line shown above the sub-process list in the long-running sub-process message. When unset, a generic built-in line is used
+silentSubAgentLongRunningMessageFooter?: string # Optional: Overrides the line shown below the sub-process list in the long-running sub-process message. When unset, a generic built-in line is used
 changeTargetPathAliases?: # Optional: Map of short alias keys to full repository-root-relative directory paths. Allows `change-target:<alias>` labels to reference deeply nested paths that exceed GitHub's 50-character label limit. When a `change-target:` label's value matches a key in this map, it is expanded to the corresponding full path before confinement checking. Values with leading or trailing slashes are normalized automatically. Example below
   adapter-interfaces: src/domain/usecases/adapter-interfaces
 ```
@@ -555,17 +557,17 @@ For each `In Tmux by human` issue with no live session, the reconciler launches
 
 ## Silent Live Session Notification
 
-Each schedule cycle, when `silentNotificationEnabled` is true, also inspects every live interactive Claude Code session and sends a short self-check reminder into a session via `tmux send-keys` when either of two independent conditions holds. The reminder is composed of only the sections whose condition is met, so a session receives one combined message containing one or both sections. When `silentNotificationEnabled` is not set, the entire step is a no-op even if the daemon picks up its configuration automatically.
+Each schedule cycle, when `silentNotificationEnabled` is true, also inspects every live interactive Claude Code session and sends a short self-check reminder into a session via `tmux send-keys` when either of two independent conditions holds. The reminder is composed of only the sections whose condition is met. The main-session-stalled section and the sub-process section are independent, and within the sub-process section the idle (no-output) condition and the long-running condition each produce their own distinct message so a small idle time is never lumped together with a long running time; a sub-process that matches both conditions is reported in both messages, kept separate. When `silentNotificationEnabled` is not set, the entire step is a no-op even if the daemon picks up its configuration automatically.
 
 Candidate sessions are first selected from the live process tree: every live tmux session is taken, the descendants of each session's pane processes are walked, and the first descendant that is an interactive Claude Code process (its command line contains `claude` and does not contain the owner-handover marker `Take ownership of`, and its environment exposes both `CLAUDE_CODE_SESSION_ID` and `CLAUDE_CONFIG_DIR`) is taken as that session's process. Because the walk is anchored on tmux panes, background owner-handover spawns, the preparation daemon, and monitor processes — none of which run inside an interactive tmux pane — are excluded; the owner-handover marker check is an additional guard. The monitor then acts only on sessions whose tmux name encodes a `github.com` issue or pull-request URL — that is, a name of the form `https_//github_com/{owner}/{repo}/issues/{N}` or `https_//github_com/{owner}/{repo}/pull/{N}` (the form tmux derives from the raw issue/PR URL by replacing only `.` and `:` with `_`; the raw `https://github.com/...` form is matched as well). Sessions whose name does not encode such a URL — for example an orchestrator session named with a plain word such as `workbench` — are left untouched: they receive neither a main-stall nor a sub-process notification, and the count of non-github-named sessions ignored each cycle is logged. Each selected session's transcript is then resolved by scanning the `projects/<cwd-slug>/` subdirectories of two roots — the per-session `<CLAUDE_CONFIG_DIR>/projects/` and the shared `~/.claude/projects/` — for a `<sessionId>.jsonl` file named by any of the session's candidate session ids. The candidate ids are derived from the process tree, in priority order: the current session id recorded in `<CLAUDE_CONFIG_DIR>/sessions/<pid>.json` (the session id rotates on resume or compaction, and this record holds the current value), then the interactive process's own launch id from the `CLAUDE_CODE_SESSION_ID` environment variable, then the distinct ids propagated to its descendant processes, all deduped. Searching the shared root and the rotated current id is required because, for a resumed or compacted session, the actively-written transcript is named by the current id and lives under the shared root rather than under the per-session config directory; the descendant-propagated ids are required because, for a session started without `--resume`, the own launch id names no transcript on disk and the live transcript is named by the descendant id. The candidate ids are tried strictly in this priority order, and the first candidate id that names an existing `<sessionId>.jsonl` file in either root is selected; the most recently modified match is used only as a tiebreak when that same id exists in both roots. Resolving by candidate-id priority rather than by the globally most recently modified file across all candidate ids is required because a session running a sub-agent has the sub-agent's own transcript on disk too, and that sub-agent transcript can be more recently modified than the parent session's transcript while not naming the parent. The parent session's own ids (the rotated current id and the launch id) come before any descendant-propagated id, so the parent's own transcript is selected ahead of a sub-agent transcript; a sub-agent transcript, which lives under `projects/<cwd-slug>/<parentSessionId>/subagents/agent-<id>.jsonl` rather than as a top-level `<sessionId>.jsonl` file, is never reached. This way a non-resume session and a session that has no issue URL both resolve just as reliably as a resume, issue-url-named one, and a session that is waiting on the owner while a sub-agent runs is evaluated against its own transcript rather than the sub-agent's.
 
 The main-session stalled section is sent when the session's main output has been idle for at least `mainSilentThresholdSeconds`, unless the session is currently waiting on the owner (in that case the silence is expected and the section is suppressed). Idle time is computed from the timestamp of the latest entry of any kind in the session's resolved transcript rather than from the transcript file modification time, so a session that keeps appending tool results, owner replies, or any other entry type while emitting no assistant text still counts as active and is not mistaken for a silent one. Whether a session is waiting on the owner is determined through an injectable port; the built-in default reports no session as waiting, so the suppression is only applied when a host provides an implementation. When `ownerCallMarker` is configured, a transcript-based implementation is used: it reads each session's resolved transcript and treats the session as waiting on the owner when the latest entry containing `ownerCallMarker` is newer (by full timestamp) than the latest genuine owner reply. A self-check reminder that the monitor injects into a session via `tmux send-keys` itself lands in that session's transcript as a `user` text entry; every injected reminder carries a fixed sentinel tag (`[TDPM_SILENT_SESSION_SELF_CHECK_REMINDER]`), and a `user` entry whose text contains that sentinel is not counted as a genuine owner reply. This prevents the monitor's own reminder from being mistaken for the owner answering, which would otherwise make a genuinely waiting session stop being suppressed. The stalled section's owner-call self-check point also instructs the agent on the required owner-call notification format: the owner-call must be emitted as the configured owner-call marker tag (interpolated from `ownerCallMarker` when set) as a complete matching pair — opening marker, content, then closing marker — on a single line with no newline inside the tag, and the content between the markers must begin with the 🔴 emoji immediately, because the owner's app only surfaces the notification together with its content when the exact, well-formed tag with the leading 🔴 is present and a malformed tag results in only a red indicator with no readable content. The same self-check point also tells the agent when to fire the owner-call: if the agent has completed or answered a request from the owner in this session, it must fire the owner-call to report the result to the owner, because completing or answering an owner's requested action is itself a reason to fire the owner-call. Completing or answering an owner request without firing the owner-call means the owner is never notified — the owner's app only surfaces the session when the owner-call fires — so the task silently stalls; the point states the causal link explicitly, noting that if the self-check reminder keeps arriving it is likely because an owner request was completed or answered without firing the owner-call, so the agent should fire the owner-call to report the result to the owner.
 
-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.
+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 and asks the agent to check whether it is stuck or legitimately waiting on an external dependency, 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. 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.
 
 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_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`.
+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_IDLE_MESSAGE_HEADER`, `TDPM_SILENT_SUBAGENT_IDLE_MESSAGE_FOOTER`, `TDPM_SILENT_SUBAGENT_LONG_RUNNING_MESSAGE_HEADER`, and `TDPM_SILENT_SUBAGENT_LONG_RUNNING_MESSAGE_FOOTER`.
 
 ## Token Rotation Order File