peaks-loop 3.1.2 → 4.0.0-beta.10

package/dist/src/services/dispatch/leak-detector.js

@@ -1,72 +0,0 @@
-/**
- * Slice #009 / G5 RL-7 — dispatch record leak detector.
- *
- * After peaks-solo's reducer consumes a batch, any dispatch record that
- * is still `disposed === false` AND was created more than `thresholdMs`
- * ago is a **leak**. This helper scans the on-disk records under
- * `.peaks/_sub_agents/<sid>/` and returns the leaked ones. The CLI or
- * the reducer's next-batch step emits a user-visible warning when the
- * list is non-empty.
- *
- * Threshold: 1h (configurable). Rationale: the longest empirical
- * peaks-rd / peaks-qa fan-out + reducer cycle is < 60s; the threshold
- * gives slow slices headroom without hiding leaks for the next session.
- */
-import { existsSync, readdirSync, readFileSync } from 'node:fs';
-import { join } from 'node:path';
-import { isDispatchStatus, isOutcome } from './dispatch-record-writer.js';
-export const DEFAULT_LEAK_THRESHOLD_MS = 60 * 60 * 1000; // 1 hour
-export function findLeakedDispatchRecords(projectRoot, sessionId, options = {}) {
-    const now = options.now ?? (() => new Date());
-    const thresholdMs = options.thresholdMs ?? DEFAULT_LEAK_THRESHOLD_MS;
-    const nowMs = now().getTime();
-    const dir = join(projectRoot, '.peaks', '_sub_agents', sessionId);
-    if (!existsSync(dir))
-        return [];
-    const out = [];
-    for (const entry of readdirSync(dir)) {
-        if (!entry.startsWith('dispatch-') || !entry.endsWith('.json'))
-            continue;
-        const fullPath = join(dir, entry);
-        let raw;
-        try {
-            raw = readFileSync(fullPath, 'utf8');
-        }
-        catch {
-            continue; // skip unreadable files
-        }
-        let parsed;
-        try {
-            parsed = JSON.parse(raw);
-        }
-        catch {
-            continue; // skip malformed files
-        }
-        if (!isRecordShape(parsed))
-            continue;
-        if (parsed.disposed === true)
-            continue;
-        const createdMs = Date.parse(parsed.createdAt);
-        if (Number.isNaN(createdMs))
-            continue;
-        const ageMs = nowMs - createdMs;
-        if (ageMs < thresholdMs)
-            continue;
-        out.push({ path: fullPath, record: parsed, ageMs });
-    }
-    return out;
-}
-function isRecordShape(v) {
-    if (typeof v !== 'object' || v === null)
-        return false;
-    const obj = v;
-    return (typeof obj.createdAt === 'string' &&
-        typeof obj.role === 'string' &&
-        typeof obj.requestId === 'string' &&
-        typeof obj.sessionId === 'string' &&
-        typeof obj.prompt === 'string' &&
-        isOutcome(obj.outcome) &&
-        isDispatchStatus(obj.status) &&
-        typeof obj.disposed === 'boolean' &&
-        Array.isArray(obj.artifactPaths));
-}

package/dist/src/services/dispatch/slice-dag.d.ts

@@ -1,81 +0,0 @@
-/**
- * Slice complexity tier (v2.15.0 follow-up, G2 in 12 Gaps).
- * Used by Solo to schedule complex slices during user-attended hours
- * and trivial / simple slices overnight.
- */
-export type SliceComplexity = 'trivial' | 'simple' | 'complex';
-export declare const SLICE_COMPLEXITIES: readonly SliceComplexity[];
-export declare function isSliceComplexity(value: string): value is SliceComplexity;
-export interface SliceNode {
-    readonly id: string;
-    readonly role: string;
-    /** Human-readable label, optional. */
-    readonly label?: string;
-    /** Optional prompt override; dispatch falls back to a default placeholder. */
-    readonly prompt?: string;
-    /**
-     * v2.15.0 follow-up — G12: foundation slice. Foundation slices run before
-     * business slices in the layered DAG. Business slices do NOT wait for
-     * ALL foundation slices — they wait only for the foundation subset
-     * they declare as `dependsOn`. Optional; default false.
-     */
-    readonly foundation?: boolean;
-    /**
-     * v2.15.0 follow-up — G11: upstream sync slice. Marks a slice that
-     * syncs an upstream fork (e.g. hermes) to a new tag. UpstreamSync
-     * slices take priority within their topological level. Optional.
-     */
-    readonly upstreamSync?: boolean;
-    /**
-     * v2.15.0 follow-up — G2: complexity tier. Drives Solo's scheduling
-     * (complex = user-attended, simple/trivial = overnight). Optional.
-     */
-    readonly complexity?: SliceComplexity;
-}
-export interface DependsOn {
-    readonly from: string;
-    readonly to: string;
-}
-export interface SliceDag {
-    readonly nodes: readonly SliceNode[];
-    readonly edges: readonly DependsOn[];
-}
-/** Thrown by `validateDag` when the graph violates one of the constraints. */
-export declare class InvalidSliceDagError extends Error {
-    readonly path?: readonly string[] | undefined;
-    readonly code: "INVALID_SLICE_DAG";
-    constructor(message: string, path?: readonly string[] | undefined);
-}
-/** Thrown by `topologicalLevels` when the graph has a cycle (defensive). */
-export declare class SliceDagCycleError extends Error {
-    readonly cyclePath: readonly string[];
-    readonly code: "SLICE_DAG_CYCLE";
-    constructor(cyclePath: readonly string[]);
-}
-/**
- * Validate a SliceDag. Throws `InvalidSliceDagError` on the first violation.
- * Pure. Cheap. No I/O.
- */
-export declare function validateDag(dag: SliceDag): void;
-/**
- * Compute topological levels. Each level is an array of node IDs that can
- * run in parallel. Throws `SliceDagCycleError` on cycle (defensive;
- * `validateDag` should have caught it).
- *
- * Algorithm: Kahn's algorithm. O(V + E).
- */
-export declare function topologicalLevels(dag: SliceDag): readonly (readonly string[])[];
-/**
- * Return the next set of node IDs that are ready to run given the set of
- * completed node IDs. A node is ready when all of its `from` predecessors
- * are in `completed`.
- */
-export declare function sliceReadyToRun(dag: SliceDag, completed: ReadonlySet<string>): readonly string[];
-/**
- * Serialize the DAG into a deterministic JSON string. Node IDs are sorted;
- * edges are sorted by `(from, to)`. The result is suitable for SHA-256
- * hashing and for byte-stable diffs.
- */
-export declare function serializeDag(dag: SliceDag): string;
-/** SHA-256 hash of the serialized DAG. Stable across runs. */
-export declare function hashDag(dag: SliceDag): string;

package/dist/src/services/dispatch/test-tool-detection.d.ts

@@ -1,36 +0,0 @@
-/**
- * Slice 2026-06-24-test-tool-detection-injection.
- *
- * The Test Tool Detection block is prepended to every sub-agent prompt
- * dispatched by peaks-loop (both the single-dispatch chokepoint in
- * `src/cli/commands/dispatch-commands.ts` and the DAG-dispatch chokepoint
- * in `src/services/solo/dag-orchestrator.ts`). It tells the sub-agent
- * to read `package.json#scripts.test` first and use the project-local
- * runner — never `npx <runner>` — so it cannot bypass the lockfile or
- * spawn a network-bound tool call.
- *
- * Why a static constant (not a per-call detector):
- *  1. Predictable byte budget — the block is part of PROMPT_LIMIT_BYTES
- *     accounting (see dispatch-commands.ts line 113), and the size must
- *     be stable across calls.
- *  2. I/O-free — dispatch is a hot path; reading package.json here would
- *     add a filesystem hit per dispatch and run before the LLM has any
- *     context to act on the result.
- *  3. LLM does runtime lookup — the block itself instructs the sub-agent
- *     to introspect `package.json#scripts.test` (or `peaks test --json`)
- *     at run time, so the LLM gets the resolved framework + argv with
- *     its full context. The dispatch CLI just primes the instruction.
- *
- * Why every sub-agent gets the block (Karpathy #2 Simplicity First):
- *  the rule is machine-injected, not a prompt ritual. The LLM cannot
- *  "remove the redundancy" of a test-tool-detection instruction because
- *  the dispatch CLI always prepends it. This is a guarantee, not a
- *  suggestion.
- */
-export declare const TEST_TOOL_DETECTION_BLOCK = "## Test Tool Detection (mandatory)\n\nBefore running any test, read `package.json#scripts.test` to identify the project's test framework. Use the project-local runner \u2014 do NOT invoke `npx <runner>`:\n\n- **vitest** \u2192 `./node_modules/.bin/vitest run <file>` (or `pnpm test -- <file>`)\n- **jest**   \u2192 `./node_modules/.bin/jest <file>`   (or `pnpm test -- <file>`)\n- **mocha**  \u2192 `./node_modules/.bin/mocha <file>`  (or `pnpm test -- <file>`)\n\nIf unsure which framework the consumer project uses, run `peaks test --json` first to introspect the resolved framework + argv. Only as a last resort, ask the user before assuming a runner. The CLI command `peaks test <file>` already resolves the local binary for you (Windows-aware).";
-/**
- * Pure helper that returns the block. Exists as a function (not just an
- * exported constant) so future variants can take a runtime parameter
- * (e.g. projectRoot for context) without churning every call site.
- */
-export declare function formatTestToolDetection(): string;

package/dist/src/services/dispatch/test-tool-detection.js

@@ -1,46 +0,0 @@
-/**
- * Slice 2026-06-24-test-tool-detection-injection.
- *
- * The Test Tool Detection block is prepended to every sub-agent prompt
- * dispatched by peaks-loop (both the single-dispatch chokepoint in
- * `src/cli/commands/dispatch-commands.ts` and the DAG-dispatch chokepoint
- * in `src/services/solo/dag-orchestrator.ts`). It tells the sub-agent
- * to read `package.json#scripts.test` first and use the project-local
- * runner — never `npx <runner>` — so it cannot bypass the lockfile or
- * spawn a network-bound tool call.
- *
- * Why a static constant (not a per-call detector):
- *  1. Predictable byte budget — the block is part of PROMPT_LIMIT_BYTES
- *     accounting (see dispatch-commands.ts line 113), and the size must
- *     be stable across calls.
- *  2. I/O-free — dispatch is a hot path; reading package.json here would
- *     add a filesystem hit per dispatch and run before the LLM has any
- *     context to act on the result.
- *  3. LLM does runtime lookup — the block itself instructs the sub-agent
- *     to introspect `package.json#scripts.test` (or `peaks test --json`)
- *     at run time, so the LLM gets the resolved framework + argv with
- *     its full context. The dispatch CLI just primes the instruction.
- *
- * Why every sub-agent gets the block (Karpathy #2 Simplicity First):
- *  the rule is machine-injected, not a prompt ritual. The LLM cannot
- *  "remove the redundancy" of a test-tool-detection instruction because
- *  the dispatch CLI always prepends it. This is a guarantee, not a
- *  suggestion.
- */
-export const TEST_TOOL_DETECTION_BLOCK = `## Test Tool Detection (mandatory)
-
-Before running any test, read \`package.json#scripts.test\` to identify the project's test framework. Use the project-local runner — do NOT invoke \`npx <runner>\`:
-
-- **vitest** → \`./node_modules/.bin/vitest run <file>\` (or \`pnpm test -- <file>\`)
-- **jest**   → \`./node_modules/.bin/jest <file>\`   (or \`pnpm test -- <file>\`)
-- **mocha**  → \`./node_modules/.bin/mocha <file>\`  (or \`pnpm test -- <file>\`)
-
-If unsure which framework the consumer project uses, run \`peaks test --json\` first to introspect the resolved framework + argv. Only as a last resort, ask the user before assuming a runner. The CLI command \`peaks test <file>\` already resolves the local binary for you (Windows-aware).`;
-/**
- * Pure helper that returns the block. Exists as a function (not just an
- * exported constant) so future variants can take a runtime parameter
- * (e.g. projectRoot for context) without churning every call site.
- */
-export function formatTestToolDetection() {
-    return TEST_TOOL_DETECTION_BLOCK;
-}