@popoverai/dotrequirements 0.26.0 → 0.26.1

package/dist/codebase-to-spec/planner.js

@@ -1,76 +0,0 @@
-/**
- * Planner functions (initial and revise).
- *
- * Two modes correspond to two places the planner is invoked:
- * - initial: first outline from the compressed pack (CTS-PLAN-1)
- * - revise:  address reviewer feedback — works for both
- *            `requires-another-review` (CTS-PLAN-5) and
- *            `approved-with-revisions` (CTS-PLAN-4). The orchestration
- *            decides whether to loop back to the reviewer or proceed to
- *            fan-out.
- *
- * Each mode is stateless — a fresh claude -p session per call.
- */
-import { runClaude } from "./claude.js";
-import { PLANNER_INITIAL_PROMPT } from "./prompts/planner-initial.js";
-import { PLANNER_REVISE_PROMPT } from "./prompts/planner-revise.js";
-import { OUTLINE_JSON_SCHEMA, parseOutline, } from "./schemas.js";
-/**
- * Run the planner in initial mode and return a parsed outline.
- * Requirement: CTS-PLAN-1
- */
-export async function runInitialPlanner(ctx) {
-    const runner = ctx.runner ?? runClaude;
-    const result = await runner({
-        systemPrompt: PLANNER_INITIAL_PROMPT,
-        userMessage: `The compressed packed codebase is at: ${ctx.overviewPath}\n\nRead it and produce the outline JSON described in your system prompt.`,
-        model: ctx.model,
-        tools: ["Read"],
-        addDirs: ctx.addDirs,
-        jsonSchema: OUTLINE_JSON_SCHEMA,
-    });
-    if (result.exitCode !== 0) {
-        throw new Error(`Planner failed (exit ${result.exitCode}): ${result.stderr || result.stdout}`);
-    }
-    return parseOutline(result.stdout);
-}
-/**
- * Run the planner in revise mode — produce a new outline that addresses the
- * reviewer's output. Handles both verdicts that trigger another planner pass:
- * `requires-another-review` (categorized findings, judgment-based) and
- * `approved-with-revisions` (explicit revisions list). The same prompt handles
- * both shapes; the prompt switches behavior based on what's in the review.
- *
- * Requirements: CTS-PLAN-4, CTS-PLAN-5
- */
-export async function runRevisingPlanner(ctx, priorOutline, review) {
-    const runner = ctx.runner ?? runClaude;
-    const userMessage = [
-        `The compressed packed codebase is at: ${ctx.overviewPath}`,
-        ``,
-        `## Prior outline`,
-        `\`\`\`json`,
-        JSON.stringify(priorOutline, null, 2),
-        `\`\`\``,
-        ``,
-        `## Reviewer output`,
-        `\`\`\`json`,
-        JSON.stringify(review, null, 2),
-        `\`\`\``,
-        ``,
-        `Produce a revised outline JSON that addresses the reviewer's output. Output JSON only.`,
-    ].join("\n");
-    const result = await runner({
-        systemPrompt: PLANNER_REVISE_PROMPT,
-        userMessage,
-        model: ctx.model,
-        tools: ["Read"],
-        addDirs: ctx.addDirs,
-        jsonSchema: OUTLINE_JSON_SCHEMA,
-    });
-    if (result.exitCode !== 0) {
-        throw new Error(`Revising planner failed (exit ${result.exitCode}): ${result.stderr || result.stdout}`);
-    }
-    return parseOutline(result.stdout);
-}
-//# sourceMappingURL=planner.js.map

package/dist/codebase-to-spec/prompts/outline-reviewer.d.ts

@@ -1,12 +0,0 @@
-/**
- * System prompt for the outline reviewer.
- *
- * Stateful across review turns (same conversation, same session-id). Reads
- * the outline and the compressed pack, produces a JSON object with
- * categorized findings and a verdict.
- *
- * Requirements covered:
- * - CTS-PLAN-2: Outline reviewer critiques the outline in a stateful session
- */
-export declare const OUTLINE_REVIEWER_PROMPT = "You are an outline reviewer for a codebase-to-spec pipeline. The pipeline takes a codebase, generates a planning outline (areas of behavior), then fans out specifier agents to produce detailed requirements per area. Your job: gate fan-out on outline quality. Bad outlines \u2192 wasted specifier work.\n\nThis is a **stateful conversation**. Across turns, you may receive multiple revisions of the outline, each addressing prior feedback. Track what you asked for and whether the planner addressed it.\n\nOutput a JSON object matching the supplied schema. No prose, no markdown fences.\n\n## What you receive on each turn\n\n- The first turn includes the compressed packed codebase and the planner's first outline JSON.\n- Each subsequent turn includes a revised outline JSON. The codebase is unchanged.\n- Some turns may include a convergence nudge \u2014 read and respect it.\n\n## What counts as a customer\n\nThe outline's summary should describe what the system is and who it's for. The \"who\" is the customer \u2014 the kind of person whose needs shape what counts as behavior.\n\nA useful customer description is **specific enough to shape behavior** \u2014 it goes one level deeper than generic categories like \"end-user,\" \"administrator,\" or \"developer.\"\n\n- Not \"an end-user\" but \"a shopper\" or \"a guest checking out without an account.\"\n- Not \"an administrator\" but \"a store manager who fulfills orders\" and \"a business owner who runs reports.\"\n- Not \"a developer\" but \"a React developer integrating an eCommerce SDK,\" \"a Python data engineer building ETL pipelines,\" or \"a distributed-systems engineer wiring up a message broker.\"\n\nMost large or sprawling codebases serve more than one customer. A system whose outline reads as if built for a single customer when the code clearly serves several is missing something \u2014 and surfacing that gap is one of the most useful things you can do.\n\n**Customers consume the software; contributors work on it.** A developer can be a legitimate customer when they consume the software being specified \u2014 a React developer integrating an SDK, a Python data engineer using a library, an operator running a CLI in CI, a contributor to an open-source project who uses it as much as they extend it. But a developer whose only role is to *work on this codebase* \u2014 described as \"a contributor,\" \"an internal maintainer,\" \"a stage author building the next feature,\" or similar \u2014 is not a customer. They're the audience for code comments and architecture docs, not for behavioral requirements. Data contracts between architectural components can still be (and often should be) specified, but think about whose experience they matter for. If an interface mediates business logic between a front-end and a server, that logic should be specified in terms of what it does for the user, not what it does for the front-end developer.\n\n## What to evaluate\n\nThe outline names its customers in the summary and breaks the system into areas. Your evaluation has two parts.\n\n### Part 1 \u2014 Per-area outcome checks\n\nFor each area, apply these four criteria:\n\n1. **Relevant to a customer.** Each area must declare at least one customer in its `customers` field. Apply the consume-vs-work-on test from \"What counts as a customer\" above: a customer is someone who *uses* the software being specified, not someone who works on its codebase. An area whose `customers` field is empty, missing, or contains only developers-of-this-codebase (contributors, maintainers, stage authors) is a `framing_error` \u2014 propose either reframing the area for a real customer or dropping it. When the area's description is written in mechanism-only voice (\"the subprocess wrapper that spawns...\", \"how the pipeline generates...\") with no customer named, that's the same finding even if a customer name was bolted on after the fact.\n2. **Speaks the customer's vocabulary.** Would the relevant customer go looking for this behavior under this area's name? The same name might be right for one kind of customer and wrong for another \u2014 what matters is whether it matches whom this area serves.\n3. **Groups a collection of functionality.** Does the area cover multiple related behaviors with a shared customer-meaningful purpose? An area with one isolated function, or a \"miscellaneous\" bucket of unrelated things, fails this test.\n4. **Has customer-observable outcomes.** Could the relevant customer verify whether the behavior is present or absent (return value, visible UI state, logged event, thrown error)? \"The system manages memory efficiently\" is true but not customer-observable.\n\nFailures of criterion 1, 2, or 4 are `framing_errors`. Failures of criterion 3 are `granularity_issues` \u2014 which also covers sizing problems more broadly.\n\n#### On sizing\n\nThink of organizing a big box of 100 crayons.\n\n- One drawer for all 100 crayons \u2192 impossible to find what you need.\n- 100 drawers, one crayon each \u2192 you've recreated the same problem with different semantics.\n- Organize by ROYGBIV \u2192 each drawer is a meaningful group, and you can find any crayon quickly.\n\nThe same logic applies to areas. An area too broad covers fundamentally distinct concerns; an area too narrow fragments what should hang together. Two areas that describe the same thing from different angles are a sizing problem \u2014 they should be one area, or split along a different axis. The right sizing for *this* codebase is whatever lets each area be coherent on its own and the whole set be complete.\n\n### Part 2 \u2014 Coverage and file assignment\n\n- What behavior is in the codebase but missing from any area? \u2192 `coverage_gaps`. Gaps matter most when they map to something a real customer would expect.\n- Are file paths actually present in the pack as written? Are files assigned to areas where they don't fit? Are public-contract docs (README, package metadata, LICENSE, CHANGELOG) unassigned? \u2192 `file_assignment_issues`.\n\n## On second and later turns\n\nAlso evaluate:\n\n- Did the revision address what you asked for in the prior turn? Be honest if it did or didn't.\n- Did the revision introduce new problems? Sometimes fixing one gap creates another.\n\n## Findings must be actionable\n\nA finding is only useful if the planner can act on it. Two principles:\n\n**Show your reasoning.** If your finding rests on a judgment about who the system is for, what the customer would want, or how an area should be reshaped, surface that reasoning. \"This outline doesn't read like it's for any specific customer\" gives the planner nothing to act on. \"I think this is most plausibly for a React developer integrating an eCommerce SDK; areas X and Y are organized around backend storage rather than what that developer would reach for; suggest reframing as Z\" does. Same pattern for any other \"this feels off\" finding \u2014 propose the alternative.\n\n**Be specific.** Cite paths and area names by exact spelling. \"Could be more comprehensive\" is not actionable. \"The outline has no area covering [behavior X], visible in [file Y]\" is.\n\n## Verdict types\n\nThe `verdict` field is exactly one of:\n\n- `approved` \u2014 outline is ready for fan-out as-is. No findings, or findings are negligible. Reserve for genuinely good outlines.\n- `approved-with-revisions` \u2014 outline is fundamentally sound and ready for fan-out, but includes specific small revisions that should be applied first. List the revisions in the `revisions` array. The planner will apply them mechanically without further review. Use for inline tweaks: rename a file path, split one bloated area into two, add a missing public-contract file to an area, tighten the customer description in the summary.\n- `requires-another-review` \u2014 outline has meaningful issues that need a structural fix, not just tweaks. Coverage gaps for whole subsystems, framing errors at the area level, customer set in the summary wrong or incomplete in ways that ripple through area design. The planner needs to think again, not just tweak.";
-//# sourceMappingURL=outline-reviewer.d.ts.map

package/dist/codebase-to-spec/prompts/outline-reviewer.js

@@ -1,89 +0,0 @@
-/**
- * System prompt for the outline reviewer.
- *
- * Stateful across review turns (same conversation, same session-id). Reads
- * the outline and the compressed pack, produces a JSON object with
- * categorized findings and a verdict.
- *
- * Requirements covered:
- * - CTS-PLAN-2: Outline reviewer critiques the outline in a stateful session
- */
-export const OUTLINE_REVIEWER_PROMPT = `You are an outline reviewer for a codebase-to-spec pipeline. The pipeline takes a codebase, generates a planning outline (areas of behavior), then fans out specifier agents to produce detailed requirements per area. Your job: gate fan-out on outline quality. Bad outlines → wasted specifier work.
-
-This is a **stateful conversation**. Across turns, you may receive multiple revisions of the outline, each addressing prior feedback. Track what you asked for and whether the planner addressed it.
-
-Output a JSON object matching the supplied schema. No prose, no markdown fences.
-
-## What you receive on each turn
-
-- The first turn includes the compressed packed codebase and the planner's first outline JSON.
-- Each subsequent turn includes a revised outline JSON. The codebase is unchanged.
-- Some turns may include a convergence nudge — read and respect it.
-
-## What counts as a customer
-
-The outline's summary should describe what the system is and who it's for. The "who" is the customer — the kind of person whose needs shape what counts as behavior.
-
-A useful customer description is **specific enough to shape behavior** — it goes one level deeper than generic categories like "end-user," "administrator," or "developer."
-
-- Not "an end-user" but "a shopper" or "a guest checking out without an account."
-- Not "an administrator" but "a store manager who fulfills orders" and "a business owner who runs reports."
-- Not "a developer" but "a React developer integrating an eCommerce SDK," "a Python data engineer building ETL pipelines," or "a distributed-systems engineer wiring up a message broker."
-
-Most large or sprawling codebases serve more than one customer. A system whose outline reads as if built for a single customer when the code clearly serves several is missing something — and surfacing that gap is one of the most useful things you can do.
-
-**Customers consume the software; contributors work on it.** A developer can be a legitimate customer when they consume the software being specified — a React developer integrating an SDK, a Python data engineer using a library, an operator running a CLI in CI, a contributor to an open-source project who uses it as much as they extend it. But a developer whose only role is to *work on this codebase* — described as "a contributor," "an internal maintainer," "a stage author building the next feature," or similar — is not a customer. They're the audience for code comments and architecture docs, not for behavioral requirements. Data contracts between architectural components can still be (and often should be) specified, but think about whose experience they matter for. If an interface mediates business logic between a front-end and a server, that logic should be specified in terms of what it does for the user, not what it does for the front-end developer.
-
-## What to evaluate
-
-The outline names its customers in the summary and breaks the system into areas. Your evaluation has two parts.
-
-### Part 1 — Per-area outcome checks
-
-For each area, apply these four criteria:
-
-1. **Relevant to a customer.** Each area must declare at least one customer in its \`customers\` field. Apply the consume-vs-work-on test from "What counts as a customer" above: a customer is someone who *uses* the software being specified, not someone who works on its codebase. An area whose \`customers\` field is empty, missing, or contains only developers-of-this-codebase (contributors, maintainers, stage authors) is a \`framing_error\` — propose either reframing the area for a real customer or dropping it. When the area's description is written in mechanism-only voice ("the subprocess wrapper that spawns...", "how the pipeline generates...") with no customer named, that's the same finding even if a customer name was bolted on after the fact.
-2. **Speaks the customer's vocabulary.** Would the relevant customer go looking for this behavior under this area's name? The same name might be right for one kind of customer and wrong for another — what matters is whether it matches whom this area serves.
-3. **Groups a collection of functionality.** Does the area cover multiple related behaviors with a shared customer-meaningful purpose? An area with one isolated function, or a "miscellaneous" bucket of unrelated things, fails this test.
-4. **Has customer-observable outcomes.** Could the relevant customer verify whether the behavior is present or absent (return value, visible UI state, logged event, thrown error)? "The system manages memory efficiently" is true but not customer-observable.
-
-Failures of criterion 1, 2, or 4 are \`framing_errors\`. Failures of criterion 3 are \`granularity_issues\` — which also covers sizing problems more broadly.
-
-#### On sizing
-
-Think of organizing a big box of 100 crayons.
-
-- One drawer for all 100 crayons → impossible to find what you need.
-- 100 drawers, one crayon each → you've recreated the same problem with different semantics.
-- Organize by ROYGBIV → each drawer is a meaningful group, and you can find any crayon quickly.
-
-The same logic applies to areas. An area too broad covers fundamentally distinct concerns; an area too narrow fragments what should hang together. Two areas that describe the same thing from different angles are a sizing problem — they should be one area, or split along a different axis. The right sizing for *this* codebase is whatever lets each area be coherent on its own and the whole set be complete.
-
-### Part 2 — Coverage and file assignment
-
-- What behavior is in the codebase but missing from any area? → \`coverage_gaps\`. Gaps matter most when they map to something a real customer would expect.
-- Are file paths actually present in the pack as written? Are files assigned to areas where they don't fit? Are public-contract docs (README, package metadata, LICENSE, CHANGELOG) unassigned? → \`file_assignment_issues\`.
-
-## On second and later turns
-
-Also evaluate:
-
-- Did the revision address what you asked for in the prior turn? Be honest if it did or didn't.
-- Did the revision introduce new problems? Sometimes fixing one gap creates another.
-
-## Findings must be actionable
-
-A finding is only useful if the planner can act on it. Two principles:
-
-**Show your reasoning.** If your finding rests on a judgment about who the system is for, what the customer would want, or how an area should be reshaped, surface that reasoning. "This outline doesn't read like it's for any specific customer" gives the planner nothing to act on. "I think this is most plausibly for a React developer integrating an eCommerce SDK; areas X and Y are organized around backend storage rather than what that developer would reach for; suggest reframing as Z" does. Same pattern for any other "this feels off" finding — propose the alternative.
-
-**Be specific.** Cite paths and area names by exact spelling. "Could be more comprehensive" is not actionable. "The outline has no area covering [behavior X], visible in [file Y]" is.
-
-## Verdict types
-
-The \`verdict\` field is exactly one of:
-
-- \`approved\` — outline is ready for fan-out as-is. No findings, or findings are negligible. Reserve for genuinely good outlines.
-- \`approved-with-revisions\` — outline is fundamentally sound and ready for fan-out, but includes specific small revisions that should be applied first. List the revisions in the \`revisions\` array. The planner will apply them mechanically without further review. Use for inline tweaks: rename a file path, split one bloated area into two, add a missing public-contract file to an area, tighten the customer description in the summary.
-- \`requires-another-review\` — outline has meaningful issues that need a structural fix, not just tweaks. Coverage gaps for whole subsystems, framing errors at the area level, customer set in the summary wrong or incomplete in ways that ripple through area design. The planner needs to think again, not just tweak.`;
-//# sourceMappingURL=outline-reviewer.js.map

package/dist/codebase-to-spec/slice.d.ts

@@ -1,49 +0,0 @@
-/**
- * Slice extraction: given a Repomix pack and a list of file paths (or
- * directory-prefix paths), produce a smaller pack containing only the matching
- * files.
- *
- * Pack format (from Repomix --style plain):
- *
- *   ================
- *   File: path/to/file
- *   ================
- *   <file contents>
- *
- *   ================
- *   File: next/file
- *   ================
- *   ...
- *
- * We preserve the pack header (everything before the first File: section) and
- * the matching sections.
- *
- * Requirements covered:
- * - CTS-SPEC-1: CLI fans out one specifier worker per area; each worker
- *   receives a slice extracted from the uncompressed pack
- */
-/**
- * Return true when `path` matches one of the entries in `wanted`.
- *
- * Each entry can be:
- * - An exact file path (e.g., `src/foo.ts`) — matches that exact path.
- * - A directory prefix ending in `/` (e.g., `src/services/browser/`) — matches
- *   any file under that directory tree.
- */
-export declare function pathMatchesWanted(path: string, wanted: Iterable<string>): boolean;
-export interface SliceExtractionResult {
-    /** Number of file sections matched (and written to the output). */
-    matched: number;
-    /** Total number of file sections in the input pack. */
-    total: number;
-}
-/**
- * Extract sections matching `wanted` from the pack at `inputPath` and write
- * them to `outputPath`. Preserves the pack header (Repomix metadata).
- */
-export declare function extractSlice(inputPath: string, outputPath: string, wanted: Iterable<string>): SliceExtractionResult;
-/**
- * Pure variant operating on already-loaded text. Useful for tests.
- */
-export declare function extractSliceFromText(text: string, outputPath: string, wanted: Iterable<string>): SliceExtractionResult;
-//# sourceMappingURL=slice.d.ts.map

package/dist/codebase-to-spec/slice.js

@@ -1,111 +0,0 @@
-/**
- * Slice extraction: given a Repomix pack and a list of file paths (or
- * directory-prefix paths), produce a smaller pack containing only the matching
- * files.
- *
- * Pack format (from Repomix --style plain):
- *
- *   ================
- *   File: path/to/file
- *   ================
- *   <file contents>
- *
- *   ================
- *   File: next/file
- *   ================
- *   ...
- *
- * We preserve the pack header (everything before the first File: section) and
- * the matching sections.
- *
- * Requirements covered:
- * - CTS-SPEC-1: CLI fans out one specifier worker per area; each worker
- *   receives a slice extracted from the uncompressed pack
- */
-import { readFileSync, writeFileSync } from "node:fs";
-const SEPARATOR = "================";
-const FILE_PREFIX = "File: ";
-/**
- * Return true when `path` matches one of the entries in `wanted`.
- *
- * Each entry can be:
- * - An exact file path (e.g., `src/foo.ts`) — matches that exact path.
- * - A directory prefix ending in `/` (e.g., `src/services/browser/`) — matches
- *   any file under that directory tree.
- */
-export function pathMatchesWanted(path, wanted) {
-    for (const w of wanted) {
-        if (w === path)
-            return true;
-        if (w.endsWith("/") && path.startsWith(w))
-            return true;
-    }
-    return false;
-}
-/**
- * Extract sections matching `wanted` from the pack at `inputPath` and write
- * them to `outputPath`. Preserves the pack header (Repomix metadata).
- */
-export function extractSlice(inputPath, outputPath, wanted) {
-    const wantedSet = new Set(wanted);
-    const text = readFileSync(inputPath, "utf-8");
-    return extractSliceFromText(text, outputPath, wantedSet);
-}
-/**
- * Pure variant operating on already-loaded text. Useful for tests.
- */
-export function extractSliceFromText(text, outputPath, wanted) {
-    const wantedSet = wanted instanceof Set ? wanted : new Set(wanted);
-    const lines = text.split("\n");
-    const out = [];
-    // Find the start of the first File: section.
-    let firstFileIdx = -1;
-    for (let i = 0; i + 1 < lines.length; i++) {
-        if (lines[i].trim() === SEPARATOR && lines[i + 1].startsWith(FILE_PREFIX)) {
-            firstFileIdx = i;
-            break;
-        }
-    }
-    if (firstFileIdx === -1) {
-        throw new Error("Input pack has no File: sections");
-    }
-    // Preserve the pack header (lines 0..firstFileIdx-1).
-    for (let i = 0; i < firstFileIdx; i++) {
-        out.push(lines[i]);
-    }
-    let matched = 0;
-    let total = 0;
-    let i = firstFileIdx;
-    while (i < lines.length) {
-        if (lines[i].trim() === SEPARATOR &&
-            i + 1 < lines.length &&
-            lines[i + 1].startsWith(FILE_PREFIX)) {
-            const path = lines[i + 1].slice(FILE_PREFIX.length).trim();
-            total++;
-            // Find the end of this section (next ====/File: pair or EOF).
-            let j = i + 3; // past the closing separator
-            while (j < lines.length) {
-                if (lines[j].trim() === SEPARATOR &&
-                    j + 1 < lines.length &&
-                    lines[j + 1].startsWith(FILE_PREFIX)) {
-                    break;
-                }
-                j++;
-            }
-            const contentEnd = j; // exclusive
-            if (pathMatchesWanted(path, wantedSet)) {
-                matched++;
-                for (let k = i; k < contentEnd; k++) {
-                    out.push(lines[k]);
-                }
-            }
-            i = j;
-        }
-        else {
-            i++;
-        }
-    }
-    writeFileSync(outputPath, out.join("\n"), "utf-8");
-    return { matched, total };
-}
-//# sourceMappingURL=slice.js.map

package/dist/codebase-to-spec/specifier.d.ts

@@ -1,60 +0,0 @@
-/**
- * Specifier worker: run a single specifier for one area.
- *
- * The specifier is given its slice + the outline + a target partial path, and
- * it orchestrates its own work via tools (Read, Write, Edit, Grep, Glob, Bash).
- * Self-style-check happens via `Bash dotrequirements cts style-check <path>`.
- *
- * Requirements covered:
- * - CTS-SPEC-1: per-area worker invocation
- * - CTS-SPEC-2: write partial to known path via Write tool
- * - CTS-SPEC-3: self-style-check via Bash
- * - CTS-SPEC-4: access to the full pack for cross-area context
- * - CTS-SPEC-5: failure detection and retry orchestrated by fan-out (this file
- *   produces a single attempt; fan-out wraps it with retry policy)
- */
-import { type ClaudeRunner } from "./claude.js";
-import type { Area, Outline } from "./schemas.js";
-export interface SpecifierContext {
-    outline: Outline;
-    area: Area;
-    /** Path to the area's slice (extracted from the uncompressed pack). */
-    slicePath: string;
-    /** Path to the full uncompressed pack (for cross-area discovery). */
-    fullPackPath: string;
-    /** Where the specifier should write its partial. */
-    partialPath: string;
-    /**
-     * The command the specifier should run to invoke schema validation on its
-     * own partial — typically `dotrequirements cts validate`. Run BEFORE
-     * style-check.
-     */
-    validateCommand: string;
-    /**
-     * The command the specifier should run to invoke style-check on its own
-     * partial — typically `dotrequirements cts style-check`. Run AFTER
-     * validate.
-     */
-    styleCheckCommand: string;
-    /** Directories the agent should have read+write access to. */
-    addDirs: string[];
-    runner?: ClaudeRunner;
-    model?: string;
-}
-export interface SpecifierResult {
-    /** True if the agent wrote a non-empty partial file at the expected path. */
-    wrotePartial: boolean;
-    /** Size of the partial in bytes, or 0 if missing. */
-    partialBytes: number;
-    /** Process exit code. */
-    exitCode: number;
-    /** Captured stdout. */
-    stdout: string;
-    /** Captured stderr. */
-    stderr: string;
-}
-/**
- * Run a single specifier. Returns details about whether it succeeded.
- */
-export declare function runSpecifier(ctx: SpecifierContext): Promise<SpecifierResult>;
-//# sourceMappingURL=specifier.d.ts.map

package/dist/codebase-to-spec/specifier.js

@@ -1,85 +0,0 @@
-/**
- * Specifier worker: run a single specifier for one area.
- *
- * The specifier is given its slice + the outline + a target partial path, and
- * it orchestrates its own work via tools (Read, Write, Edit, Grep, Glob, Bash).
- * Self-style-check happens via `Bash dotrequirements cts style-check <path>`.
- *
- * Requirements covered:
- * - CTS-SPEC-1: per-area worker invocation
- * - CTS-SPEC-2: write partial to known path via Write tool
- * - CTS-SPEC-3: self-style-check via Bash
- * - CTS-SPEC-4: access to the full pack for cross-area context
- * - CTS-SPEC-5: failure detection and retry orchestrated by fan-out (this file
- *   produces a single attempt; fan-out wraps it with retry policy)
- */
-import { existsSync, statSync } from "node:fs";
-import { runClaude } from "./claude.js";
-import { SPECIFIER_PROMPT } from "./prompts/specifier.js";
-function buildUserMessage(ctx) {
-    return [
-        `You are specifying ONE area of the system.`,
-        ``,
-        `Area name: ${ctx.area.name}`,
-        `Area description: ${ctx.area.description}`,
-        `Document defaultPrefix: ${ctx.outline.defaultPrefix}`,
-        `Area prefix: ${ctx.area.prefix}`,
-        ``,
-        `## Customers this area serves`,
-        `(Pick one of these as the named persona for your requirements. Do not invent a different customer. If none of these is a real user of the software — e.g., all entries describe a contributor to this codebase — follow the AREA-LACKS-CUSTOMER escape in your system prompt instead of writing requirements.)`,
-        `\`\`\`json`,
-        JSON.stringify(ctx.area.customers, null, 2),
-        `\`\`\``,
-        `Use full requirement IDs of the form: ${ctx.outline.defaultPrefix}-${ctx.area.prefix}-1, ${ctx.outline.defaultPrefix}-${ctx.area.prefix}-2, etc. (sequential, 1-indexed, no zero-padding).`,
-        ``,
-        `## Paths`,
-        `- Slice (your area's files): ${ctx.slicePath}`,
-        `- Full uncompressed pack (for discovering behaviors in tests/recipes/docs): ${ctx.fullPackPath}`,
-        `- Where to write your partial: ${ctx.partialPath}`,
-        `- Validate command (run FIRST after writing your draft — deterministic syntax check):`,
-        `    Bash: ${ctx.validateCommand} ${ctx.partialPath}`,
-        `- Style-check command (run SECOND, only after validate passes — AI clarity feedback):`,
-        `    Bash: ${ctx.styleCheckCommand} ${ctx.partialPath}`,
-        ``,
-        `## Full system outline (so you know what is in scope vs. not)`,
-        `\`\`\`json`,
-        JSON.stringify(ctx.outline, null, 2),
-        `\`\`\``,
-        ``,
-        `Follow the three-phase workflow in your system prompt: draft (Phase A) → validate (Phase B) → style-check (Phase C) → confirm.`,
-    ].join("\n");
-}
-/**
- * Run a single specifier. Returns details about whether it succeeded.
- */
-export async function runSpecifier(ctx) {
-    const runner = ctx.runner ?? runClaude;
-    const result = await runner({
-        systemPrompt: SPECIFIER_PROMPT,
-        userMessage: buildUserMessage(ctx),
-        model: ctx.model,
-        tools: ["Read", "Write", "Edit", "Grep", "Glob", "Bash"],
-        addDirs: ctx.addDirs,
-    });
-    // Inspect the partial file to determine whether the specifier wrote
-    // something usable.
-    let wrotePartial = false;
-    let partialBytes = 0;
-    if (existsSync(ctx.partialPath)) {
-        try {
-            partialBytes = statSync(ctx.partialPath).size;
-            wrotePartial = partialBytes > 0;
-        }
-        catch {
-            // ignore; treat as not written
-        }
-    }
-    return {
-        wrotePartial,
-        partialBytes,
-        exitCode: result.exitCode,
-        stdout: result.stdout,
-        stderr: result.stderr,
-    };
-}
-//# sourceMappingURL=specifier.js.map

package/dist/codebase-to-spec/summary.d.ts

@@ -1,51 +0,0 @@
-/**
- * Pipeline summary generation.
- *
- * Reads cached artifacts to assemble a structured summary of what the
- * pipeline produced. Surfaced both as JSON (parseable by wrappers like the
- * skill) and as a short human-readable block.
- *
- * Requirements covered:
- * - CTS-PRESENT-4: Final pipeline summary is surfaced
- * - CTS-OBSERVE-2 (partial): structured failure information available
- */
-import type { CachePaths } from "./cache.js";
-import { type Outline } from "./schemas.js";
-export interface PipelineSummary {
-    totalAreas: number;
-    totalRequirements: number;
-    outline: {
-        turnsUsed: number;
-        finalVerdict: string | null;
-        residualNotes: string[];
-    };
-    specifiers: {
-        completed: number;
-        missing: number;
-        /** Area names that have no usable partial. */
-        missingAreas: string[];
-    };
-    specReview: {
-        turnsUsed: number;
-        finalVerdict: string | null;
-        residualNotes: string[];
-    };
-    outputs: {
-        /** Paths under .requirements/ that were written. */
-        paths: string[];
-    };
-}
-export interface BuildSummaryInput {
-    outline: Outline;
-    paths: CachePaths;
-    /** Paths the present stage wrote (under .requirements/). */
-    outputPaths: string[];
-}
-export declare function buildPipelineSummary(input: BuildSummaryInput): PipelineSummary;
-/**
- * Render a short human-readable block for the summary. Designed to fit on a
- * small number of lines (CTS-PRESENT-4.2). Wrappers that want richer
- * presentation can read the JSON form instead.
- */
-export declare function renderSummaryText(summary: PipelineSummary): string;
-//# sourceMappingURL=summary.d.ts.map