npm - claude-code-session-manager - Versions diffs - 0.37.0 → 0.37.2 - Mend

claude-code-session-manager 0.37.0 → 0.37.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (38) hide show

package/bin/cli.cjs +12 -1
package/dist/assets/{TiptapBody-Cg8YZhVZ.js → TiptapBody-BtrSXTRp.js} +1 -1
package/dist/assets/index-CD_LuJZF.css +32 -0
package/dist/assets/{index-_iBXLuvt.js → index-uVGdpAGF.js} +498 -490
package/dist/index.html +2 -2
package/package.json +2 -1
package/plugins/session-manager-dev/skills/develop/SKILL.md +134 -36
package/plugins/session-manager-dev/skills/develop/standards.md +24 -0
package/plugins/session-manager-dev/skills/requesting-code-review/SKILL.md +20 -17
package/scripts/lib/activeSessions.cjs +117 -0
package/scripts/lib/watchdogHelpers.cjs +829 -0
package/src/main/__tests__/classifyTranscriptLine.test.cjs +90 -0
package/src/main/__tests__/docEdit.test.cjs +164 -2
package/src/main/__tests__/prdCreate.test.cjs +265 -25
package/src/main/__tests__/scheduler-admin-routes.test.cjs +150 -0
package/src/main/__tests__/scheduler-boot-orphans.test.cjs +172 -0
package/src/main/browserAgentServer.cjs +11 -10
package/src/main/chatRunner.cjs +21 -2
package/src/main/docEdit.cjs +125 -5
package/src/main/health.cjs +15 -0
package/src/main/index.cjs +12 -6
package/src/main/ipcSchemas.cjs +14 -0
package/src/main/lib/__tests__/localAdminHttp.test.cjs +120 -0
package/src/main/lib/classifyTranscriptLine.cjs +89 -0
package/src/main/lib/localAdminHttp.cjs +157 -0
package/src/main/lib/personaImportHealth.cjs +161 -0
package/src/main/lib/prdCreate.cjs +107 -17
package/src/main/lib/rcaFeedbackHook.cjs +2 -2
package/src/main/lib/singleInstanceGuard.cjs +20 -0
package/src/main/scheduler.cjs +198 -54
package/src/main/templates/PRD_AUTHORING.md +4 -4
package/src/main/transcripts.cjs +1 -85
package/src/preload/api.d.ts +12 -1
package/src/preload/index.cjs +6 -0
package/dist/assets/index-CTTjT08J.css +0 -32
package/plugins/session-manager-dev/skills/security-review/SKILL.md +0 -105
package/src/main/__tests__/adminServer.test.cjs +0 -380
package/src/main/adminServer.cjs +0 -242

package/dist/index.html CHANGED Viewed

@@ -7,10 +7,10 @@
     <link rel="preconnect" href="https://fonts.googleapis.com">
     <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
     <link href="https://fonts.googleapis.com/css2?family=Newsreader:ital,opsz,wght@0,6..72,400;0,6..72,500;0,6..72,600;0,6..72,700;1,6..72,400&family=Geist:wght@300;400;500;600;700&family=IBM+Plex+Mono:wght@400;500;600&display=swap" rel="stylesheet">
-    <script type="module" crossorigin src="./assets/index-_iBXLuvt.js"></script>
+    <script type="module" crossorigin src="./assets/index-uVGdpAGF.js"></script>
     <link rel="modulepreload" crossorigin href="./assets/monaco-editor-BW5C4Iv1.js">
     <link rel="stylesheet" crossorigin href="./assets/monaco-editor-BTnBOi8r.css">
-    <link rel="stylesheet" crossorigin href="./assets/index-CTTjT08J.css">
+    <link rel="stylesheet" crossorigin href="./assets/index-CD_LuJZF.css">
   </head>
   <body class="bg-bg text-fg font-sans antialiased">
     <div id="root"></div>

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-session-manager",
-  "version": "0.37.0",
+  "version": "0.37.2",
   "description": "Local cockpit for the Claude Code CLI — multi-tab terminal, full config surface, scheduler, voice dictation, and live observability.",
   "type": "module",
   "main": "src/main/index.cjs",
@@ -12,6 +12,7 @@
     ".claude-plugin/",
     "plugins/",
     "scripts/postinstall.cjs",
+    "scripts/lib/",
     "src/main/",
     "src/preload/",
     "dist/index.html",

package/plugins/session-manager-dev/skills/develop/SKILL.md CHANGED Viewed

@@ -2,9 +2,9 @@
 name: develop
 description: >-
   Lead a software-development task by decomposing a feature/refactor/bugfix prompt into a
-  series of self-contained PRDs queued for the session-manager scheduler, each carrying the
-  engineering standards inline so the headless executor honors them — then track those PRDs
-  to completion, verify them against their acceptance criteria, and report back. Use whenever
+  series of self-contained PRDs queued for the session-manager scheduler, each pointing the
+  headless executor at the engineering standards file to read at runtime — then track those
+  PRDs to completion, verify them against their acceptance criteria, and report back. Use whenever
   the user says "/develop", "develop X", "build me X", "implement X", "let's code X", or
   otherwise starts dev work that should run as scheduled PRDs rather than inline now. This
   skill is the home for the developer-only guidance (performance, debugging, API-reuse, TDD)
@@ -41,16 +41,18 @@ The engineering standards (Performance, Debugging, API reuse / single source of
 and the executor-facing Execution discipline) live in **`standards.md`** beside this file, in
 the same skill directory (`.../skills/develop/standards.md` — NOT `~/.claude/skills/develop/`,
 which is a different, non-existent path; resolve it relative to wherever this SKILL.md itself
-was loaded from). **Re-read that file fresh with the Read tool immediately before pasting it
-into each PRD (Phase 1 step 4) — never reuse a copy cached earlier in the same conversation.**
-A long authoring session can span an edit to `standards.md` (including one autonomously applied
-by a prior incident's fix-plan) without the model noticing; pasting a stale in-context copy
-silently ships PRDs missing the latest execution-discipline rules. This is exactly the
-single-source-of-truth violation the standards themselves warn against — don't let it happen to
-the standards block itself. (Incident: PRDs 467/468 authored late in a long session carried a
-standards.md snapshot from before the "You ARE the executor" guard was added earlier that same
-session, so PRD 467's headless run repeated the exact anti-pattern the guard exists to prevent.)
-Never restate or fork its content — one concept, one implementation.
+was loaded from).
+**Reference it, don't embed it.** The headless executor (`claude -p`) runs on the same
+filesystem this authoring session does, with full tool access — so a PRD only needs to name
+`standards.md`'s absolute path (resolved once, at authoring time, the same way this file already
+resolves it) and instruct the executor to `Read` it before starting. There is now exactly one
+copy of this text on disk, ever — no pasted snapshot to go stale, and nothing to re-read fresh
+before writing (an earlier version of this skill pasted the full contents into every PRD and had
+to warn authors to re-read it fresh each time to avoid shipping a stale in-context copy — PRDs
+467/468 did exactly that and repeated an anti-pattern a guard added earlier the same session was
+meant to prevent. Referencing by path removes the failure mode instead of warning against it).
+Never restate or fork its content — one concept, one implementation, one location.
 For interactive dev work, also apply the `test-driven-development` and `systematic-debugging`
 skills; the headless PRDs get the distilled core from `standards.md` instead, since they
@@ -64,21 +66,85 @@ can't load skills.
    caller is `/process-feedback`, scope is already established by its evaluation — don't
    re-ask; build from the brief it hands you.)
-2. **Explore the target repo.** Identify the absolute `cwd`, existing patterns/utilities to
-   reuse (per the API-reuse standard — search before writing new code), the test command, and
-   any constraints. Capture exact file paths and signatures; they go straight into the PRDs.
-3. **Decompose into a series of SMALL, bounded PRDs.** Split a large ask into multiple PRDs and
-   sequence them. To pick each PRD's `NN` (parallel group), **compute the highest in-use number
-   deterministically — never eyeball or narrow-grep the `ls`** (a narrowed pattern like
-   `'^10[0-9]'` silently misses `110+` and collides):
+2. **Explore the target repo — broadly, not just the obvious file.** Identify the absolute
+   `cwd`, existing patterns/utilities to reuse (per the API-reuse standard — search before
+   writing new code), the test command, and any constraints. Capture exact file paths and
+   signatures; they go straight into the PRDs. Don't stop at the first component that looks
+   relevant — check its siblings too (does the same pattern appear in 2-3 similar components?
+   do they actually share the same shape, or only look similar — confirm by reading, don't
+   assume: a wrong assumption here means an inaccurate PRD, discovered only after the executor
+   runs it), check existing tests for the area, and check whether a prior PRD already touched
+   this subsystem (`ls ~/.claude/session-manager/scheduled-plans/prds/` for related slugs) —
+   duplicating or contradicting a still-queued PRD is a real failure mode, not a hypothetical one.
+3. **Draft a candidate decomposition, then run a completeness pass before finalizing it.** This
+   step exists because small, bounded individual PRDs (step 4) are correct and non-negotiable —
+   but a *set* of small PRDs can still be incomplete if the upfront decomposition missed
+   something. Keeping PRDs small is not a substitute for getting the decomposition right; it's a
+   separate concern, and this step is where decomposition quality gets checked.
+   - For a **genuinely trivial ask** (one obvious PRD, no cross-file consequences) — skip
+     straight to step 4, no ceremony needed.
+   - For anything **larger than one or two obvious PRDs, or touching more than one
+     component/subsystem** — before finalizing, dispatch a second, independent agent (the Agent
+     tool, `subagent_type: "Explore"` or `"general-purpose"` — this is a single extra dispatch,
+     not the full multi-agent Workflow tool, and needs no special opt-in) with: the original ask
+     verbatim, your draft PRD list (titles + one-line goals), and the instruction to find what's
+     missing — uncovered edge cases, error-handling paths, tests, cross-file consequences,
+     components that share the same pattern but weren't included, anything the draft assumed
+     without verifying. Treat its findings as a second opinion to weigh, not an automatic
+     addition — fold real, concrete gaps into the PRD set (add, split, or adjust a PRD); dismiss
+     vague or speculative ones. For a large, multi-subsystem ask, it's fine to repeat this once
+     more after folding in the first round's findings (a second completeness pass on the revised
+     set) — stop once a pass turns up nothing new, don't loop indefinitely.
+   - **Check each drafted PRD against explicit concern dimensions, not just "does the feature
+     work"**: missing features/edge cases beyond the happy path, tests, security, and quality
+     (perf, error handling). This is where depth actually comes from — a decomposition that only
+     ever asks "what file does this touch" produces exactly the narrow, single-concern PRDs this
+     step exists to catch.
+     - **Tests and security are NOT separate follow-up PRDs — they are mandatory AC lines inside
+       the SAME PRD as the feature they belong to.** This is non-negotiable: `standards.md`'s TDD
+       rule requires the test before/with the implementation, not after, and a security concern
+       (input validation at a boundary, auth checks, no string-built queries) is a decision made
+       while writing the code — a later "security review PRD" would just end up re-touching the
+       same lines, doubling work and leaving the shipped code insecure in the meantime. Every
+       feature PRD's own Acceptance Criteria must include its test command AND, when it touches
+       input/auth/data, the relevant security checks — don't spin these out.
+     - **Genuinely separable work MAY become its own sibling PRD**: deeper edge-case coverage
+       beyond what the core AC needs to prove correctness, performance/observability hardening,
+       docs. Splitting these out is exactly the "more isolated, narrower PRDs" instinct — apply
+       it here, where a dedicated PRD adds real value, not to tests/security where it subtracts
+       from correctness.
+   - This is a planning-quality step, not an execution step — it happens entirely in the
+     interactive main-loop session, before anything gets written to disk or queued.
+4. **Decompose into a series of SMALL, bounded PRDs.** Split the (now completeness-checked)
+   decomposition into individually small PRDs and sequence them.
+   **Prefer creating each PRD via the `scheduler_create_prd` MCP tool**
+   (`mcp__session-manager-scheduler__scheduler_create_prd`) over hand-writing the file. Its input
+   (`title`, `cwd`, `estimateMinutes`, `goal`, `acceptanceCriteria[]`, `implementationNotes`,
+   `outOfScope[]`) maps directly onto the sections below — pass them straight through. It
+   allocates the parallel-group `NN` atomically (no read-then-write race against another
+   concurrent `/develop`/`/process-feedback` invocation), derives and collision-checks the slug,
+   and embeds the standards pointer for you. Set `parallelGroup` explicitly only when this PRD
+   must share an existing sibling's `NN` (a logically independent PRD that can run in parallel
+   with one already queued); omit it to get the next free `NN` atomically.
+   **Fallback — only when the tool errors with "app not running" / admin API unreachable**
+   (the session-manager Electron app must be running for this MCP tool to work; if it isn't,
+   don't block on it): compute the highest in-use number deterministically yourself — never
+   eyeball or narrow-grep the `ls` (a narrowed pattern like `'^10[0-9]'` silently misses `110+`
+   and collides):
    ```bash
    ls ~/.claude/session-manager/scheduled-plans/prds/ | grep -oE '^[0-9]+' | sort -n | uniq | tail -5
    ```
    The last line is the current max. Then: same `NN` as a logically independent sibling that
    can run in parallel; **next free `NN` = max+1** when this PRD hard-depends on prior work or
-   is unrelated to every existing group. Record each cross-PRD dependency in the dependent
-   PRD's notes.
+   is unrelated to every existing group. This manual path has a small, accepted race (two
+   concurrent authors could compute the same "next free" `NN`) — cosmetic (two unrelated groups
+   end up sharing a number) rather than destructive, and only reachable when the atomic tool
+   path above isn't available. Record each cross-PRD dependency in the dependent PRD's notes
+   either way.
    ### PRD structure and location
@@ -166,12 +232,24 @@ can't load skills.
    failure** — it's the scheduler's designed auto-pause; the job auto-resumes at the next
    window reset. Don't add retry logic for it.
-4. **Emit each PRD** to the canonical path and structure above, then **append `## Engineering
-   standards` and paste the full contents of `standards.md` verbatim.** This is the
-   load-bearing step — it's the only way the standards (incl. Execution discipline) reach the
-   headless run. Honor the `PRD_AUTHORING.md` §10 pre-queue checklist.
+5. **Emit each PRD.** If you used `scheduler_create_prd`, this step is already done — the tool
+   wrote the file to the canonical path with the standards pointer included; skip to step 5.
+   **Fallback path only:** write to the canonical path and structure above, then **append `##
+   Engineering standards` with a one-line pointer**, not the file's contents:
+   ```markdown
+   ## Engineering standards
+   Before writing any code, read `<absolute path to standards.md, resolved above>` — it has the
+   Performance, Debugging, API-reuse, TDD, and Execution-discipline rules that apply to this PRD.
+   Every rule in it is mandatory, especially Execution discipline (bounded commands, verify
+   before done, the finish-protocol sentinel).
+   ```
+   This is the load-bearing step — it's the only way the standards (incl. Execution discipline)
+   reach the headless run, and it now stays current automatically since the executor reads the
+   live file rather than a snapshot taken at authoring time. Honor the `PRD_AUTHORING.md` §10
+   pre-queue checklist.
-5. **Confirm to the user**, per emitted PRD: filename, chosen `NN` + rationale
+6. **Confirm to the user**, per emitted PRD: filename, chosen `NN` + rationale
    (parallel-with-X / serial-after-Y), `cwd`, and an ETA + token-cost ballpark. Note they can
    "Run now" in the SchedulePanel or wait for `when-available` polling.
@@ -181,7 +259,7 @@ The queued PRDs run headlessly and can take a while. Don't fire-and-forget, and
 hand off to a recurring check. `/process-feedback` delegates to this exact phase, so it is the
 single definition of "tracked to done" for both entry paths.
-6. **Watch the scheduler every ~30 min.** Start a 30-minute monitoring loop (`/loop 30m` over
+7. **Watch the scheduler every ~30 min.** Start a 30-minute monitoring loop (`/loop 30m` over
    this watch step, or a `ScheduleWakeup` at 1800s if self-pacing) scoped to the PRD ids you
    emitted. On each tick, read the scheduler's job status (queue + run history under
    `~/.claude/session-manager/scheduled-plans/`, or the SchedulePanel) and branch:
@@ -195,22 +273,42 @@ single definition of "tracked to done" for both entry paths.
      your report rather than re-deriving the analysis, and let `/process-feedback` fold its
      prevention hint back into future PRD authoring. A `rateLimited` exit-1 is the
      scheduler's benign auto-pause (auto-resumes next window) — keep waiting, don't escalate.
-   - **All PRDs completed successfully** — go to step 7.
+   - **All PRDs completed successfully** — go to step 8.
-7. **Gate: definition of done** (same for both entry paths). Once the code has landed:
+8. **Gate: definition of done** (same for both entry paths). Once the code has landed:
    - **Verify live against each PRD's acceptance criteria** — run the health check, hit the
      endpoint, show before/after. The headless run asserted its own test command; this is the
      interactive confirmation it actually does what was asked.
-   - For a **major feature or risky change**, dispatch a review via the
-     `requesting-code-review` skill before calling it done; fix Critical/Important findings.
-   - **Report back**: what landed, PRD/commit refs, verification result, anything left open.
+   - **Route to the specialist that actually matches what changed** — not always the generic
+     reviewer. This environment has dedicated agents that sit unused unless explicitly called;
+     match the PRD's surface to the right one before calling a major/risky change done:
+     - Touches an API's request/response shape, REST/GraphQL contract, or endpoint design →
+       dispatch `api-designer` (Agent tool).
+     - Touches auth, input handling, secrets, or data storage → dispatch `security-auditor` in
+       addition to the mandatory security AC the PRD's own execution already required — the
+       auditor catches what the executor's self-check might miss.
+     - Is a structural refactor (no behavior change intended) → dispatch `refactorer`.
+     - Is performance-sensitive or touches a hot path → dispatch `perf-profiler`.
+     - Adds or updates a dependency → dispatch `dependency-auditor`.
+     - Touches a database schema, migration, or table design → **no specialist exists for this
+       in this environment today.** Don't silently let the generic code-reviewer stand in for a
+       schema review it isn't specialized for — say so explicitly in your report ("schema change,
+       no dedicated reviewer available, manual review recommended") rather than implying coverage
+       that isn't there.
+     - Anything else, or a **major feature/risky change** not covered above — dispatch the
+       generic `requesting-code-review` skill (`code-reviewer` agent) as the default.
+     Fix Critical/Important findings from whichever specialist(s) ran before calling it done.
+   - **Report back**: what landed, PRD/commit refs, which specialist(s) reviewed it (or the
+     explicit "no specialist available" note), verification result, anything left open.
 ## References (reuse, don't duplicate)
 - `~/.claude/session-manager/scheduled-plans/PRD_AUTHORING.md` — the §1–§10 safety rules.
-- `standards.md` beside this file — the engineering + execution-discipline rules inlined into every PRD. Re-read fresh each time (see "Standards" above) — don't reuse a cached copy.
+- `standards.md` beside this file — the engineering + execution-discipline rules. Every PRD points the executor at its absolute path (see "Standards" above) rather than embedding a copy.
 - `test-driven-development`, `systematic-debugging` — interactive dev sessions.
-- `requesting-code-review` — the Phase-2 review gate.
+- `requesting-code-review` — the Phase-2 default review gate; `api-designer`, `security-auditor`,
+  `refactorer`, `perf-profiler`, `dependency-auditor` — specialist agents routed to by surface
+  area (see step 8) rather than always defaulting to the generic reviewer.
 ## Notes

package/plugins/session-manager-dev/skills/develop/standards.md CHANGED Viewed

@@ -50,6 +50,30 @@
 - (Interactive sessions: the `test-driven-development` skill has the full red-green-refactor
   workflow. Headless PRD runs can't load it — the three rules above are the load-bearing core.)
+## Visual design (UI/visual acceptance criteria)
+When a PRD's acceptance criteria touch UI or visual output and no design brief is given,
+resolve the visual direction in this priority order — never substitute a generic default when
+a higher-priority source exists:
+1. **User-supplied design.** If the PRD or the conversation that spawned it includes a design
+   brief, mockup, brand palette, or explicit visual direction, use it verbatim.
+2. **Existing project design system.** Before reaching for any external skill, check the repo
+   itself for an existing theme — CSS custom-property blocks, `tailwind.config.js`, a
+   design-tokens file, a component library already in use. Reuse and extend what's there
+   rather than introducing a second visual language into the same project.
+3. **Only if neither exists**, invoke a design-oriented skill rather than eyeballing colors
+   from memory or hand-picking hex values (e.g. the bundled `dataviz` skill for
+   chart/table/dashboard work, or a `frontend-design`-class skill for overall aesthetic
+   direction) — and **render + screenshot both light and dark color-scheme modes** before
+   calling the work done. A palette validator that checks categorical/series colors does not
+   cover surrounding chrome tokens (panel/page/border) — those need their own contrast check
+   (WCAG relative luminance) and a visual look in each mode. "I checked light mode" is not "I
+   checked dark mode"; verify both, don't assume palette-reference hex values are safe by
+   construction. (Incident: a dashboard shipped with panel/page background contrast of
+   1.12:1 and a border at 1.34:1 in dark mode — both invisible — because only light mode was
+   ever rendered before the work was marked done.)
 ## Execution discipline (headless runs)
 Data-driven from 400+ scheduler runs: long hangs (not bad code) are the dominant real failure, and "exited clean but left a red test" is the top verifier downgrade. These rules run at execution time — they are inlined into every PRD because the headless executor reads nothing else.

package/plugins/session-manager-dev/skills/requesting-code-review/SKILL.md CHANGED Viewed

@@ -5,7 +5,7 @@ description: Use when completing tasks, implementing major features, or before m
 # Requesting Code Review
-Dispatch superpowers:code-reviewer subagent to catch issues before they cascade.
+Dispatch the native `code-reviewer` subagent (via the Agent tool, `subagent_type: "code-reviewer"`) to catch issues before they cascade.
 **Core principle:** Review early, review often.
@@ -31,7 +31,7 @@ HEAD_SHA=$(git rev-parse HEAD)
 **2. Dispatch code-reviewer subagent:**
-Use Task tool with superpowers:code-reviewer type, fill template at `code-reviewer.md`
+Use the Agent tool with `subagent_type: "code-reviewer"`, filling the template at `code-reviewer.md`
 **Placeholders:**
 - `{WHAT_WAS_IMPLEMENTED}` - What you just built
@@ -56,7 +56,7 @@ You: Let me request code review before proceeding.
 BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
 HEAD_SHA=$(git rev-parse HEAD)
-[Dispatch superpowers:code-reviewer subagent]
+[Dispatch code-reviewer subagent via the Agent tool]
   WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
   PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
   BASE_SHA: a7981ec
@@ -74,20 +74,23 @@ You: [Fix progress indicators]
 [Continue to Task 3]
 ```
-## Integration with Workflows
-**Subagent-Driven Development:**
-- Review after EACH task
-- Catch issues before they compound
-- Fix before moving to next task
-**Executing Plans:**
-- Review after each batch (3 tasks)
-- Get feedback, apply, continue
-**Ad-Hoc Development:**
-- Review before merge
-- Review when stuck
+## Integration with /develop
+This is the **default** reviewer at `/develop`'s Phase 2 done-gate (step 8) — but not the only
+one. `/develop` routes to a matching specialist first when a PRD's surface calls for it
+(`api-designer` for API-contract changes, `security-auditor` for auth/input/data, `refactorer`
+for structural refactors, `perf-profiler` for hot-path changes, `dependency-auditor` for
+dependency bumps) and only falls back to this generic reviewer for everything else or when no
+specialist fits. Don't treat this skill as covering ground those specialists already own.
+Since this project's actual unit of work is a scheduler PRD (not a live multi-task session), the
+review point is per-PRD, at its own commit range — `BASE_SHA`/`HEAD_SHA` above are that PRD's
+commit(s), not an arbitrary task boundary from a different workflow shape. Review:
+- **After a PRD completes**, as part of `/develop`'s definition-of-done gate (step 8) — every
+  major/risky PRD, before calling it done.
+- **When a PRD comes back `needs_review`** — read the scheduler's auto-filed RCA first
+  (`rcaFeedbackHook`'s `<date>-rca-<slug>-<runId>.md`), then use this review to confirm the fix
+  if one gets queued.
 ## Red Flags

package/scripts/lib/activeSessions.cjs ADDED Viewed

@@ -0,0 +1,117 @@
+'use strict';
+// activeSessions.cjs — returns distinct on-disk project cwds with an active
+// session within maxAgeMin minutes. Used by the feedback sweep (PRD 102) to
+// narrow scanning to projects the user is actually working in.
+//
+// Detection is transcript-based only (scans ~/.claude/projects/*/*.jsonl
+// mtimes). It has zero dependency on ~/.claude/knowledge-log/prompts.jsonl,
+// which PRD 356-retire purges along with its capture hook.
+const fs = require('node:fs');
+const os = require('node:os');
+const path = require('node:path');
+const HOME = os.homedir();
+// Transcript reads only need the last line with a `cwd` field — a few dozen
+// lines is always enough. 64 KB keeps peak RSS proportionate.
+const TAIL_BYTES = 64 * 1024;
+// Safety cap on distinct cwds to bound result set size. O(1) extra space.
+const MAX_CWDS = 50;
+/**
+ * readTailLines(filePath, maxBytes) → string[]
+ * Reads at most maxBytes from the END of filePath and splits into non-empty lines.
+ * O(1) in file size (bounded read). Returns [] on any I/O error.
+ */
+function readTailLines(filePath, maxBytes) {
+  let buf;
+  try {
+    const stat = fs.statSync(filePath);
+    if (stat.size === 0) return [];
+    const readSize = Math.min(maxBytes, stat.size);
+    const fd = fs.openSync(filePath, 'r');
+    try {
+      buf = Buffer.alloc(readSize);
+      fs.readSync(fd, buf, 0, readSize, stat.size - readSize);
+    } finally {
+      fs.closeSync(fd);
+    }
+  } catch {
+    return [];
+  }
+  return buf.toString('utf8').split('\n').filter((l) => l.trim());
+}
+/**
+ * activeProjectCwds(maxAgeMin = 90, opts?) → string[]
+ *
+ * Returns distinct, on-disk project cwds that have an open/active session
+ * within the last maxAgeMin minutes.
+ *
+ * Sole detection path: scan ~/.claude/projects/*/  for transcript *.jsonl
+ *   files modified within maxAgeMin, read `cwd` from the last parseable line
+ *   of the newest transcript per project dir.
+ *   Complexity: O(P × L) over P project dirs, each bounded-tail read (64 KB).
+ *
+ * opts (for testing):
+ *   projectsDir  — override the default ~/.claude/projects path
+ */
+function activeProjectCwds(maxAgeMin = 90, {
+  projectsDir = path.join(HOME, '.claude', 'projects'),
+} = {}) {
+  const cutoffMs = Date.now() - maxAgeMin * 60 * 1000;
+  const seen = new Set();
+  const result = [];
+  function addCwd(cwd) {
+    if (!cwd || typeof cwd !== 'string') return;
+    if (seen.has(cwd) || result.length >= MAX_CWDS) return;
+    try { fs.statSync(cwd); } catch { return; } // must exist on disk
+    seen.add(cwd);
+    result.push(cwd);
+  }
+  // Scan ~/.claude/projects/*/  transcript *.jsonl files.
+  let slugs;
+  try { slugs = fs.readdirSync(projectsDir); } catch { return result; }
+  for (const slug of slugs) {
+    if (result.length >= MAX_CWDS) break;
+    const projDir = path.join(projectsDir, slug);
+    let entries;
+    try {
+      entries = fs.readdirSync(projDir).filter((f) => f.endsWith('.jsonl'));
+    } catch { continue; }
+    // Find the most recently modified transcript in this project dir.
+    let newestPath = null;
+    let newestMtimeMs = 0;
+    for (const tf of entries) {
+      const fp = path.join(projDir, tf);
+      try {
+        const st = fs.statSync(fp);
+        if (st.mtimeMs > newestMtimeMs) {
+          newestMtimeMs = st.mtimeMs;
+          newestPath = fp;
+        }
+      } catch { continue; }
+    }
+    if (!newestPath || newestMtimeMs < cutoffMs) continue;
+    // Read `cwd` from the last parseable line of the transcript.
+    const tlines = readTailLines(newestPath, TAIL_BYTES);
+    for (let i = tlines.length - 1; i >= 0; i--) {
+      let row;
+      try { row = JSON.parse(tlines[i]); } catch { continue; }
+      if (row.cwd) { addCwd(row.cwd); break; }
+    }
+  }
+  return result;
+}
+module.exports = { activeProjectCwds };