@popoverai/dotrequirements 0.24.2 → 0.25.0

package/README.md

@@ -243,20 +243,18 @@ Optional settings: `vercelBypassSecret`, `browserbaseApiKey`, `browserbaseProjec
 
 ### `dotreq cts` *(Alpha)*
 
-Generate behavioral requirements from an existing codebase. Packs the codebase, plans a behavioral outline, fans out per-area specifier agents to draft per-area requirements, runs a dual review loop, and writes the result to `.requirements/`.
+Generate behavioral requirements from an existing codebase — it plans a behavioral outline, drafts the requirements for each area, converges each through independent review, then reconciles the whole spec in a final cross-area pass, and writes the result to `.requirements/`.
+
+It runs as a Claude Code skill backed by a dynamic workflow. Install it, then invoke it from Claude Code:
 
 ```bash
-dotreq cts run --scope src                 # full pipeline end-to-end
-dotreq cts run --scope src --fresh         # discard cache and start over
-dotreq cts run --scope src --ignore-requirements   # run against a codebase that already has its own .requirements/
-dotreq cts skill-install                   # install the conversational skill wrapper
+dotreq cts skill-install            # install into this project's .claude/
+dotreq cts skill-install --global   # …or into ~/.claude/ for every project
 ```
 
-`cts` shells out to `claude -p` and uses whatever auth mode you've configured for Claude Code. Each pipeline stage is also runnable on its own (`dotreq cts pack`, `plan-loop`, `fan-out`, `compose`, `edit-loop`, `present`) for partial re-runs and debugging.
-
-> **Alpha:** output quality is prompt-sensitive and varies by codebase. See the [Codebase to Spec docs](https://docs.dotrequirements.io/tools/cli/codebase-to-spec) for prerequisites, options, exit codes, and known rough edges. Feedback to support@dotrequirements.io welcome.
+Then, in Claude Code, run `/codebase-to-spec` (or just ask — e.g. "spec the auth module"). You confirm the scope; the workflow autonomously plans the areas, drafts and reviews each one, reconciles them in a cross-area pass, and writes the result to `.requirements/`. Requires a Claude Code version with dynamic-workflow support.
 
-> **Heads up:** as of June 15, 2026, `claude -p` bills against your Claude subscription's API credit instead of the subscription seat (per Anthropic's May 13, 2026 announcement). `cts` runs will draw from that credit.
+> **Alpha:** output quality is prompt-sensitive and varies by codebase. See the [Codebase to Spec docs](https://docs.dotrequirements.io/tools/cli/codebase-to-spec) for prerequisites, scoping, and known rough edges. Feedback to support@dotrequirements.io welcome.
 
 ### `dotreq ai-setup`
 

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

@@ -38,6 +38,12 @@ export interface CachePaths {
     specFinal: string;
     /** Final pipeline summary JSON, surfaced by present and consumed by wrappers. */
     pipelineSummary: string;
+    /**
+     * Conversational orchestrator outline — single YAML file that evolves
+     * across the run (Phase 2b refactor). Carries content + review.thread
+     * lifecycle state inline. Distinct from the legacy outline-N.json files.
+     */
+    outline: string;
 }
 export declare function cachePaths(projectRoot: string): CachePaths;
 export declare function ensureCacheDir(projectRoot: string): CachePaths;

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

@@ -29,6 +29,7 @@ export function cachePaths(projectRoot) {
         specReviewTurn: (n) => join(root, `spec-review-${n}.json`),
         specFinal: join(root, "spec-final.md"),
         pipelineSummary: join(root, "pipeline-summary.json"),
+        outline: join(root, "outline.yaml"),
     };
 }
 export function ensureCacheDir(projectRoot) {

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

@@ -0,0 +1,115 @@
+/**
+ * Dispatch-context composition for the codebase-to-spec workflow.
+ *
+ * A cts-worker runs `dotrequirements cts dispatch-context <dispatch-id>` to
+ * fetch the full composed prompt for its role (self-composition — there is no
+ * PreToolUse hook). Each returned prompt is self-contained: persona body +
+ * paths + any prior-round context the worker needs.
+ *
+ * Recognized dispatch IDs:
+ * - `planner-initial` — initial planner; writes outline.yaml
+ * - `planner-revise-<turn>` — revising planner; reads the prior outline.yaml
+ *   (with its review.thread), applies the latest thread entry's revisions, and
+ *   writes a new outline.yaml. `<turn>` is the round being PRODUCED (2 = first
+ *   revision).
+ * - `outline-reviewer` — independent reviewer of the area decomposition; appends
+ *   its verdict to the document-level review.thread.
+ * - `specifier-<area>` — drafts one area's partial.
+ * - `reviewer-<area>` — independent per-area reviewer; appends its verdict to
+ *   that area's review.thread.
+ * - `editor-<area>` — applies the per-area reviewer's revisions to the partial.
+ * - `cross-area-reviewer` — document-level reviewer of the composed spec
+ *   (cross-area issues + coverage); returns its verdict for the reconcile loop.
+ * - `compose-editor` — applies cross-area revisions to the composed spec.
+ * - `phase1-test` — mechanical plumbing self-test.
+ *
+ * Requirements covered:
+ * - CTSO-CONV-2: the outline converges via an independent reviewer loop
+ * - CTSO-CONV-5: cross-area review reconciles the composed spec
+ */
+export interface DispatchContext {
+    /**
+     * The full composed prompt the worker subagent should receive as its first
+     * turn. Includes the persona body + paths + any prior-round context needed
+     * to ground the worker's behavior.
+     */
+    prompt: string;
+}
+/** Phase 1 dispatch-id used to validate the mechanical plumbing end-to-end. */
+export declare const PHASE1_TEST_DISPATCH_ID = "phase1-test";
+/** Phase 1 token the test worker echoes back. */
+export declare const PHASE1_TEST_TOKEN = "PHASE1-WORKER-OK token=CTS9X";
+/** Phase 2 dispatch-id for the initial planner pass. */
+export declare const PLANNER_INITIAL_DISPATCH_ID = "planner-initial";
+/**
+ * Phase 2b dispatch-id prefix for planner revise dispatches. Suffix is the
+ * turn number being PRODUCED (e.g., `planner-revise-2` produces the
+ * second turn's outline, reading the prior outline + its latest review
+ * thread entry as inputs).
+ */
+export declare const PLANNER_REVISE_DISPATCH_ID_PREFIX = "planner-revise-";
+/**
+ * Phase 3 dispatch-id prefix for specifier dispatches. Suffix is the area's
+ * prefix from the approved outline (e.g., `specifier-PLAN` runs the
+ * specifier for the PLAN area).
+ */
+export declare const SPECIFIER_DISPATCH_ID_PREFIX = "specifier-";
+/**
+ * Phase 4 dispatch-id prefix for editor dispatches. Suffix is the area's
+ * prefix (e.g., `editor-PLAN` revises the PLAN area's partial based on
+ * the latest area.review.thread entry's revisions).
+ */
+export declare const EDITOR_DISPATCH_ID_PREFIX = "editor-";
+/**
+ * Dispatch-id prefix for per-area reviewer dispatches. Suffix is the area's
+ * prefix (e.g., `reviewer-PLAN` reviews the PLAN area's partial). The reviewer
+ * is a distinct worker from the specifier/editor that produced the partial
+ * (independent second pair of eyes — CTSO-CONV-3.1). It appends its verdict to
+ * that area's `review.thread` in outline.yaml (read by the editor dispatch) and
+ * also returns the verdict so the workflow's convergence loop can branch on it.
+ */
+export declare const REVIEWER_DISPATCH_ID_PREFIX = "reviewer-";
+/**
+ * Dispatch-id for the outline reviewer — the independent reviewer for the
+ * planner's area decomposition (project level, one per run). Distinct from the
+ * planner that produced the outline (CTSO-CONV-2.1). It appends its verdict to
+ * the project-level `outline.review.thread` and returns the verdict so the
+ * workflow's outline loop can branch on it. The outline loop is sequential, so
+ * unlike the per-area reviewers this writer never contends on the file.
+ */
+export declare const OUTLINE_REVIEWER_DISPATCH_ID = "outline-reviewer";
+/**
+ * Dispatch-id for the cross-area reviewer — the document-level reviewer that
+ * runs AFTER per-area work converges and the partials are composed into a single
+ * spec. It reviews the composed spec for cross-area issues (duplication,
+ * terminology/persona drift, awkward cross-cutting splits, depth imbalance) plus
+ * document-level coverage and framing. It appends its verdict to the outline's
+ * top-level `crossAreaReview.thread` (auditable, like the per-area reviewers)
+ * and also returns it so the workflow's reconcile loop can branch on it
+ * (CTSO-CONV-5). Reuses the legacy SPEC_REVIEWER_PROMPT persona. One per round,
+ * sequential — no file contention.
+ */
+export declare const CROSS_AREA_REVIEWER_DISPATCH_ID = "cross-area-reviewer";
+/**
+ * Dispatch-id for the compose-level editor — applies the cross-area reviewer's
+ * revisions to the whole composed spec (not one area). Reuses the legacy
+ * EDITOR_PROMPT persona at its native document scope, reading the revisions to
+ * apply from the outline's top-level `crossAreaReview.thread` — the same
+ * auditable channel the per-area editor uses for `area.review.thread`.
+ */
+export declare const COMPOSE_EDITOR_DISPATCH_ID = "compose-editor";
+export interface ComposeDispatchOptions {
+    /**
+     * Project root used to resolve cache paths. Defaults to `findProjectRoot()`
+     * starting from cwd. Tests pass a temp directory.
+     */
+    projectRoot?: string;
+}
+/**
+ * Compose the dispatch context for a given dispatch-id.
+ *
+ * @returns the composed dispatch context, or `null` if the id is unknown
+ *          or required inputs (cache files) are missing.
+ */
+export declare function composeDispatchContext(dispatchId: string, options?: ComposeDispatchOptions): DispatchContext | null;
+//# sourceMappingURL=dispatch.d.ts.map