@popoverai/dotrequirements 0.24.0 → 0.24.2

package/dist/codebase-to-spec/prompts/style-check.d.ts

@@ -2,11 +2,19 @@
  * System prompt for the local style-check tool.
  *
  * Reads a partial-spec file and produces severity-categorized feedback.
- * Stateless — same "fresh set of eyes" pattern as the existing cloud
+ * Stateless — same "fresh set of eyes" pattern as the cloud
  * `mcp__dotrequirements__style_check`.
  *
+ * IMPORTANT: This prompt is a verbatim copy of the cloud style-check prompt
+ * (REQUIREMENTS_STYLE_PRINCIPLES + severityGuidance) defined in
+ * `packages/convex/lib/prompts.ts`. The cts-local style-check is required to
+ * MIRROR the cloud tool (CTS-SPEC-3) — when the cloud principles change, this
+ * file must be updated in lock-step. A follow-up task should extract the
+ * principles into a shared module so this duplication can go away.
+ *
  * Requirements covered:
  * - CTS-SPEC-3: Specifier worker runs a local style-check on its own draft
+ *   that mirrors `mcp__dotrequirements__style_check`
  */
-export declare const STYLE_CHECK_PROMPT = "You are a stateless style reviewer for a single dotrequirements partial spec \u2014 one or more `dotrequirements` fenced blocks plus an optional one-line description above them. Your job is to give the author actionable feedback on per-requirement writing quality.\n\nThis check is a \"fresh set of eyes\" \u2014 you have no memory of prior feedback rounds. You are looking only at this file as it currently stands.\n\n## How to categorize feedback\n\n### MUST FIX\n\n- **The requirement does not describe an observable outcome.** \"The system manages memory efficiently\" gives a tester nothing to verify. The requirement needs to be rephrased around what the customer can observe.\n\n### SHOULD FIX\n\n- **Vague language** where concrete behavior is needed.\n- **Missing preconditions** that anchor the test \u2014 a When/Then with no Given-equivalent context.\n- **Internal-mechanics drift** \u2014 describing how the implementation works (library function names, syscall flags, internal scheduling vocabulary, buffer sizes) instead of what the customer observes.\n- **Documentation prose dressed as a requirement** \u2014 \"the documentation directs users to...\" style commentary that isn't testable behavior.\n- **Persona inconsistency** \u2014 the spec doesn't name a persona, or child requirements drop the persona established by their parent.\n- **Chained actions** \u2014 a single requirement covering multiple discrete actions that should be separate requirements.\n- **Hidden sibling dependencies** \u2014 a requirement that only makes sense if read alongside its siblings.\n- **Imposed format labels** \u2014 Given/When/Then or other framework labels applied uniformly without sharpening meaning. The dotrequirements default is unlabeled criteria; labels are used only when they help.\n\n### COULD IMPROVE\n\n- Over-long titles that read like full sentences.\n- Inconsistent terminology with the rest of the area.\n- Redundant sub-criteria that re-state the parent.\n- UI or design specifics where behavior alone would suffice.\n\n## How to write findings\n\nFor each finding:\n- Cite the specific requirement ID (e.g., `AUTH-LOGIN-1`).\n- Quote the offending text.\n- Explain why it's an issue.\n- Suggest a rephrasing, or recommend dropping the requirement.\n\nKeep findings specific and concrete. Vague critiques like \"could be more comprehensive\" are not useful \u2014 name the requirement and quote the issue.\n\n## When to be brief\n\nIf the partial is genuinely good, say so. Don't manufacture findings to fill space. A clean style check is the right outcome more often than not.\n\n## Output format\n\nMarkdown with these headings:\n\n```\n## MUST FIX\n\n- ...\n\n## SHOULD FIX\n\n- ...\n\n## COULD IMPROVE\n\n- ...\n```\n\nOmit any heading with no findings. End with a one-line summary like `OVERALL: <terse assessment>`.\n\n## Output discipline\n\n- Output ONLY the categorized feedback, beginning with the first heading.\n- No preamble, no chain-of-thought, no explanation of your process.\n- Be honest. Accurate signal helps the author iterate.";
+export declare const STYLE_CHECK_PROMPT = "You are a style checker for requirements documentation in the dotrequirements format.\n\nReview the requirements file and provide actionable feedback based on these principles:\n\n**IMPORTANT**: The arrow notation format (position. Label \u2192 content) is the standard dotrequirements format. NEVER suggest changing or removing this format. Focus on the CONTENT of requirements, not the format itself.\n\n1. **Use Concrete Examples**: Replace abstract descriptions with specific testable scenarios\n   - \u274C Bad: \"users can log in\"\n   - \uD83D\uDD36 Better: \"when a registered user provides valid credentials, they are authenticated\"\n   - \u2705 Best: \"when a registered user provides credentials like user123/pass123, they are authenticated\"\n\n2. **Write Concisely Using Natural Prose and Declarative Style**:\n   - \u274C Bad: \"registered user with valid credentials is authenticated\" (too terse)\n   - \u274C Bad: \"A registered user, whose life story is as follows...\" (too verbose)\n   - \u2705 Good: \"When a registered user provides valid credentials, they are authenticated\"\n   - Note: Avoid imperative constructions like \"should\" - use declarative statements that evaluate to true/false\n\n3. **Keep Arrange/Act/Assert in Mind**: Well-written requirements describe clear preconditions, a trigger, and an assertable result\n   - Example: \"When [preconditions:] a registered user [trigger:] provides valid credentials, [result:] they are authenticated\"\n   - This pattern helps ensure requirements are testable, regardless of the labeling format used\n\n4. **Be Framework Neutral**: Don't encourage or discourage specific requirement formats like Gherkin (Given/When/Then), BDD, or other frameworks\n   - \u2705 Good: Gherkin labels are fine if the user is using them\n   - \u2705 Good: Plain acceptance criteria without labels are also fine\n   - \u274C Bad: Telling users to add or remove Given/When/Then labels based on preference\n   - Focus on the quality of the requirement content, not the labeling style\n\n5. **Use Named Personas**: Establish personas in top-level requirements and reuse in children\n   - \u2705 Good: \"A registered user, Jaime, can log in normally\" (parent)\n           \"When Jaime provides valid credentials, they are authenticated\" (child)\n\n6. **Use User-Centric Language**: Describe user experience, not technical details\n   - \u274C Bad: \"they are redirected to app.dotrequirements.io/redirect/dashboard\"\n   - \u2705 Good: \"they are automatically brought to the dashboard\"\n\n7. **Avoid Multiple Actions in Single Requirements**:\n   - \u274C Bad: \"When Robin provides credentials, requests an OTP, then provides the OTP...\"\n   - \u2705 Good: Break into separate requirements for each action\n\n8. **Each Requirement Should Be Independent**: Requirements within a block should be independently testable. If requirements depend on each other (they share preconditions or form a sequence), they should either be nested or restate enough context to stand on their own\n   - \u274C Bad: Sibling requirements that share context but don't restate it\n     \"0. \u2192 When Jordan submits signup, an account is created\"\n     \"1. \u2192 Welcome email is sent\"\n     \"2. \u2192 Dashboard appears\"\n     Problem: Requirements 1-2 can't be tested without knowing the preconditions from 0\n   - \u2705 Good: Restate context so each is independently testable\n     \"0. \u2192 When Jordan submits signup, an account is created\"\n     \"1. \u2192 When Jordan submits signup, a welcome email is sent\"\n     \"2. \u2192 When Jordan submits signup, the dashboard appears\"\n   - \u2705 Also good: Use nesting to show the dependency\n     \"0. When \u2192 Jordan submits signup\"\n     \"  0.0. Then \u2192 an account is created\"\n     \"  0.1. Then \u2192 a welcome email is sent\"\n     \"  0.2. Then \u2192 the dashboard appears\"\n   - Test: Can you understand what's being tested by reading just one requirement, or do you need to read its siblings?\n\n9. **Focus on Behavior, Not Design**:\n   - \u274C Bad: \"enters valid credentials into two single-line input fields and presses a green button...\"\n   - \u2705 Good: \"provides valid credentials\"\n\n10. **Focus on User Outcomes, Not Implementation**:\n   - \u274C Bad: \"When the app requests that Twilio send Casey an OTP from /email/POST endpoint...\"\n   - \u2705 Good: \"When Casey requests an email OTP...\"\n   - Even technical requirements can be user-centric: \"95 percent of users experience under 1 second of delay\"\n\n11. **Flag Decomposition Issues**: If a requirement looks too large to validate with a single test, identify it\n\nProvide specific, actionable feedback. Do not use emojis. Format as a bulleted list of issues found, or \"No style issues found\" if the file follows best practices.\n\n## Severity Categorization\n\nOrganize your feedback by severity to help users prioritize:\n\n**MUST FIX** - Critical issues that block understanding or testability\n**SHOULD FIX** - Important issues that reduce quality\n**COULD IMPROVE** - Minor suggestions and polish\n\n**IMPORTANT**: Categorize each issue based on its actual impact, not to balance categories. Some files may have many issues in one category and none in others - that's expected and correct.\n\nDo not use emojis. Format your response as:\n\n## MUST FIX\n[List critical issues, or \"None\"]\n\n## SHOULD FIX\n[List important issues, or \"None\"]\n\n## COULD IMPROVE\n[List minor suggestions, or \"None\"]";
 //# sourceMappingURL=style-check.d.ts.map

package/dist/codebase-to-spec/prompts/style-check.js

@@ -2,77 +2,107 @@
  * System prompt for the local style-check tool.
  *
  * Reads a partial-spec file and produces severity-categorized feedback.
- * Stateless — same "fresh set of eyes" pattern as the existing cloud
+ * Stateless — same "fresh set of eyes" pattern as the cloud
  * `mcp__dotrequirements__style_check`.
  *
+ * IMPORTANT: This prompt is a verbatim copy of the cloud style-check prompt
+ * (REQUIREMENTS_STYLE_PRINCIPLES + severityGuidance) defined in
+ * `packages/convex/lib/prompts.ts`. The cts-local style-check is required to
+ * MIRROR the cloud tool (CTS-SPEC-3) — when the cloud principles change, this
+ * file must be updated in lock-step. A follow-up task should extract the
+ * principles into a shared module so this duplication can go away.
+ *
  * Requirements covered:
  * - CTS-SPEC-3: Specifier worker runs a local style-check on its own draft
+ *   that mirrors `mcp__dotrequirements__style_check`
  */
-export const STYLE_CHECK_PROMPT = `You are a stateless style reviewer for a single dotrequirements partial spec — one or more \`dotrequirements\` fenced blocks plus an optional one-line description above them. Your job is to give the author actionable feedback on per-requirement writing quality.
+export const STYLE_CHECK_PROMPT = `You are a style checker for requirements documentation in the dotrequirements format.
 
-This check is a "fresh set of eyes" — you have no memory of prior feedback rounds. You are looking only at this file as it currently stands.
+Review the requirements file and provide actionable feedback based on these principles:
 
-## How to categorize feedback
+**IMPORTANT**: The arrow notation format (position. Label → content) is the standard dotrequirements format. NEVER suggest changing or removing this format. Focus on the CONTENT of requirements, not the format itself.
 
-### MUST FIX
+1. **Use Concrete Examples**: Replace abstract descriptions with specific testable scenarios
+   - ❌ Bad: "users can log in"
+   - 🔶 Better: "when a registered user provides valid credentials, they are authenticated"
+   - ✅ Best: "when a registered user provides credentials like user123/pass123, they are authenticated"
 
-- **The requirement does not describe an observable outcome.** "The system manages memory efficiently" gives a tester nothing to verify. The requirement needs to be rephrased around what the customer can observe.
+2. **Write Concisely Using Natural Prose and Declarative Style**:
+   - ❌ Bad: "registered user with valid credentials is authenticated" (too terse)
+   - ❌ Bad: "A registered user, whose life story is as follows..." (too verbose)
+   - ✅ Good: "When a registered user provides valid credentials, they are authenticated"
+   - Note: Avoid imperative constructions like "should" - use declarative statements that evaluate to true/false
 
-### SHOULD FIX
+3. **Keep Arrange/Act/Assert in Mind**: Well-written requirements describe clear preconditions, a trigger, and an assertable result
+   - Example: "When [preconditions:] a registered user [trigger:] provides valid credentials, [result:] they are authenticated"
+   - This pattern helps ensure requirements are testable, regardless of the labeling format used
 
-- **Vague language** where concrete behavior is needed.
-- **Missing preconditions** that anchor the test — a When/Then with no Given-equivalent context.
-- **Internal-mechanics drift** — describing how the implementation works (library function names, syscall flags, internal scheduling vocabulary, buffer sizes) instead of what the customer observes.
-- **Documentation prose dressed as a requirement** — "the documentation directs users to..." style commentary that isn't testable behavior.
-- **Persona inconsistency** — the spec doesn't name a persona, or child requirements drop the persona established by their parent.
-- **Chained actions** — a single requirement covering multiple discrete actions that should be separate requirements.
-- **Hidden sibling dependencies** — a requirement that only makes sense if read alongside its siblings.
-- **Imposed format labels** — Given/When/Then or other framework labels applied uniformly without sharpening meaning. The dotrequirements default is unlabeled criteria; labels are used only when they help.
+4. **Be Framework Neutral**: Don't encourage or discourage specific requirement formats like Gherkin (Given/When/Then), BDD, or other frameworks
+   - ✅ Good: Gherkin labels are fine if the user is using them
+   - ✅ Good: Plain acceptance criteria without labels are also fine
+   - ❌ Bad: Telling users to add or remove Given/When/Then labels based on preference
+   - Focus on the quality of the requirement content, not the labeling style
 
-### COULD IMPROVE
+5. **Use Named Personas**: Establish personas in top-level requirements and reuse in children
+   - ✅ Good: "A registered user, Jaime, can log in normally" (parent)
+           "When Jaime provides valid credentials, they are authenticated" (child)
 
-- Over-long titles that read like full sentences.
-- Inconsistent terminology with the rest of the area.
-- Redundant sub-criteria that re-state the parent.
-- UI or design specifics where behavior alone would suffice.
+6. **Use User-Centric Language**: Describe user experience, not technical details
+   - ❌ Bad: "they are redirected to app.dotrequirements.io/redirect/dashboard"
+   - ✅ Good: "they are automatically brought to the dashboard"
 
-## How to write findings
+7. **Avoid Multiple Actions in Single Requirements**:
+   - ❌ Bad: "When Robin provides credentials, requests an OTP, then provides the OTP..."
+   - ✅ Good: Break into separate requirements for each action
 
-For each finding:
-- Cite the specific requirement ID (e.g., \`AUTH-LOGIN-1\`).
-- Quote the offending text.
-- Explain why it's an issue.
-- Suggest a rephrasing, or recommend dropping the requirement.
+8. **Each Requirement Should Be Independent**: Requirements within a block should be independently testable. If requirements depend on each other (they share preconditions or form a sequence), they should either be nested or restate enough context to stand on their own
+   - ❌ Bad: Sibling requirements that share context but don't restate it
+     "0. → When Jordan submits signup, an account is created"
+     "1. → Welcome email is sent"
+     "2. → Dashboard appears"
+     Problem: Requirements 1-2 can't be tested without knowing the preconditions from 0
+   - ✅ Good: Restate context so each is independently testable
+     "0. → When Jordan submits signup, an account is created"
+     "1. → When Jordan submits signup, a welcome email is sent"
+     "2. → When Jordan submits signup, the dashboard appears"
+   - ✅ Also good: Use nesting to show the dependency
+     "0. When → Jordan submits signup"
+     "  0.0. Then → an account is created"
+     "  0.1. Then → a welcome email is sent"
+     "  0.2. Then → the dashboard appears"
+   - Test: Can you understand what's being tested by reading just one requirement, or do you need to read its siblings?
 
-Keep findings specific and concrete. Vague critiques like "could be more comprehensive" are not useful — name the requirement and quote the issue.
+9. **Focus on Behavior, Not Design**:
+   - ❌ Bad: "enters valid credentials into two single-line input fields and presses a green button..."
+   - ✅ Good: "provides valid credentials"
 
-## When to be brief
+10. **Focus on User Outcomes, Not Implementation**:
+   - ❌ Bad: "When the app requests that Twilio send Casey an OTP from /email/POST endpoint..."
+   - ✅ Good: "When Casey requests an email OTP..."
+   - Even technical requirements can be user-centric: "95 percent of users experience under 1 second of delay"
 
-If the partial is genuinely good, say so. Don't manufacture findings to fill space. A clean style check is the right outcome more often than not.
+11. **Flag Decomposition Issues**: If a requirement looks too large to validate with a single test, identify it
 
-## Output format
+Provide specific, actionable feedback. Do not use emojis. Format as a bulleted list of issues found, or "No style issues found" if the file follows best practices.
 
-Markdown with these headings:
+## Severity Categorization
 
-\`\`\`
-## MUST FIX
+Organize your feedback by severity to help users prioritize:
 
-- ...
+**MUST FIX** - Critical issues that block understanding or testability
+**SHOULD FIX** - Important issues that reduce quality
+**COULD IMPROVE** - Minor suggestions and polish
 
-## SHOULD FIX
+**IMPORTANT**: Categorize each issue based on its actual impact, not to balance categories. Some files may have many issues in one category and none in others - that's expected and correct.
 
-- ...
-
-## COULD IMPROVE
+Do not use emojis. Format your response as:
 
-- ...
-\`\`\`
-
-Omit any heading with no findings. End with a one-line summary like \`OVERALL: <terse assessment>\`.
+## MUST FIX
+[List critical issues, or "None"]
 
-## Output discipline
+## SHOULD FIX
+[List important issues, or "None"]
 
-- Output ONLY the categorized feedback, beginning with the first heading.
-- No preamble, no chain-of-thought, no explanation of your process.
-- Be honest. Accurate signal helps the author iterate.`;
+## COULD IMPROVE
+[List minor suggestions, or "None"]`;
 //# sourceMappingURL=style-check.js.map

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

@@ -9,21 +9,56 @@
  * - CTS-PLAN-2: outline reviewer output structure (categorized findings + verdict)
  */
 import { z } from "zod";
+export declare const CustomerSchema: z.ZodObject<{
+    name: z.ZodString;
+    description: z.ZodString;
+}, "strip", z.ZodTypeAny, {
+    name: string;
+    description: string;
+}, {
+    name: string;
+    description: string;
+}>;
+export type Customer = z.infer<typeof CustomerSchema>;
 export declare const AreaSchema: z.ZodObject<{
     name: z.ZodString;
     description: z.ZodString;
     prefix: z.ZodString;
     files: z.ZodArray<z.ZodString, "many">;
+    /**
+     * Customers this area serves — at least one. Each customer is a *user* of
+     * the software (not a contributor to its codebase). The specifier will use
+     * one of these as the persona it grounds the area's requirements in.
+     * See CTS-PLAN-1 (customer threading).
+     */
+    customers: z.ZodArray<z.ZodObject<{
+        name: z.ZodString;
+        description: z.ZodString;
+    }, "strip", z.ZodTypeAny, {
+        name: string;
+        description: string;
+    }, {
+        name: string;
+        description: string;
+    }>, "many">;
 }, "strip", z.ZodTypeAny, {
     prefix: string;
     files: string[];
     name: string;
     description: string;
+    customers: {
+        name: string;
+        description: string;
+    }[];
 }, {
     prefix: string;
     files: string[];
     name: string;
     description: string;
+    customers: {
+        name: string;
+        description: string;
+    }[];
 }>;
 export type Area = z.infer<typeof AreaSchema>;
 export declare const OutlineSchema: z.ZodObject<{
@@ -35,16 +70,40 @@ export declare const OutlineSchema: z.ZodObject<{
         description: z.ZodString;
         prefix: z.ZodString;
         files: z.ZodArray<z.ZodString, "many">;
+        /**
+         * Customers this area serves — at least one. Each customer is a *user* of
+         * the software (not a contributor to its codebase). The specifier will use
+         * one of these as the persona it grounds the area's requirements in.
+         * See CTS-PLAN-1 (customer threading).
+         */
+        customers: z.ZodArray<z.ZodObject<{
+            name: z.ZodString;
+            description: z.ZodString;
+        }, "strip", z.ZodTypeAny, {
+            name: string;
+            description: string;
+        }, {
+            name: string;
+            description: string;
+        }>, "many">;
     }, "strip", z.ZodTypeAny, {
         prefix: string;
         files: string[];
         name: string;
         description: string;
+        customers: {
+            name: string;
+            description: string;
+        }[];
     }, {
         prefix: string;
         files: string[];
         name: string;
         description: string;
+        customers: {
+            name: string;
+            description: string;
+        }[];
     }>, "many">;
 }, "strip", z.ZodTypeAny, {
     title: string;
@@ -55,6 +114,10 @@ export declare const OutlineSchema: z.ZodObject<{
         files: string[];
         name: string;
         description: string;
+        customers: {
+            name: string;
+            description: string;
+        }[];
     }[];
 }, {
     title: string;
@@ -65,6 +128,10 @@ export declare const OutlineSchema: z.ZodObject<{
         files: string[];
         name: string;
         description: string;
+        customers: {
+            name: string;
+            description: string;
+        }[];
     }[];
 }>;
 export type Outline = z.infer<typeof OutlineSchema>;
@@ -104,8 +171,25 @@ export declare const OUTLINE_JSON_SCHEMA: {
                             readonly type: "string";
                         };
                     };
+                    readonly customers: {
+                        readonly type: "array";
+                        readonly minItems: 1;
+                        readonly items: {
+                            readonly type: "object";
+                            readonly properties: {
+                                readonly name: {
+                                    readonly type: "string";
+                                };
+                                readonly description: {
+                                    readonly type: "string";
+                                };
+                            };
+                            readonly required: readonly ["name", "description"];
+                            readonly additionalProperties: false;
+                        };
+                    };
                 };
-                readonly required: readonly ["name", "description", "prefix", "files"];
+                readonly required: readonly ["name", "description", "prefix", "files", "customers"];
                 readonly additionalProperties: false;
             };
         };

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

@@ -10,6 +10,10 @@
  */
 import { z } from "zod";
 // ---------- Outline ----------
+export const CustomerSchema = z.object({
+    name: z.string().min(1),
+    description: z.string().min(1),
+});
 export const AreaSchema = z.object({
     name: z.string().min(1),
     description: z.string().min(1),
@@ -17,6 +21,13 @@ export const AreaSchema = z.object({
         .string()
         .regex(/^[A-Z][A-Z0-9_]*$/, "prefix must be uppercase alphanumeric/underscore"),
     files: z.array(z.string()).min(0),
+    /**
+     * Customers this area serves — at least one. Each customer is a *user* of
+     * the software (not a contributor to its codebase). The specifier will use
+     * one of these as the persona it grounds the area's requirements in.
+     * See CTS-PLAN-1 (customer threading).
+     */
+    customers: z.array(CustomerSchema).min(1),
 });
 export const OutlineSchema = z.object({
     title: z.string().min(1),
@@ -45,8 +56,21 @@ export const OUTLINE_JSON_SCHEMA = {
                     description: { type: "string" },
                     prefix: { type: "string" },
                     files: { type: "array", items: { type: "string" } },
+                    customers: {
+                        type: "array",
+                        minItems: 1,
+                        items: {
+                            type: "object",
+                            properties: {
+                                name: { type: "string" },
+                                description: { type: "string" },
+                            },
+                            required: ["name", "description"],
+                            additionalProperties: false,
+                        },
+                    },
                 },
-                required: ["name", "description", "prefix", "files"],
+                required: ["name", "description", "prefix", "files", "customers"],
                 additionalProperties: false,
             },
         },

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

@@ -24,6 +24,12 @@ function buildUserMessage(ctx) {
         `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`,

package/dist/commands/codebase-to-spec/index.js

@@ -4,6 +4,7 @@
  * Subcommands route to focused handlers in this directory. Each subcommand can
  * be invoked granularly (e.g., `dotrequirements cts pack`) per CTS-CLI-2.
  */
+import { installCtsAbortHandlers } from "../../codebase-to-spec/progress.js";
 import { composeCommand } from "./compose.js";
 import { editLoopCommand } from "./edit-loop.js";
 import { fanOutCommand } from "./fan-out.js";
@@ -20,12 +21,20 @@ export function registerCodebaseToSpec(program) {
         .command("codebase-to-spec")
         .alias("cts")
         .description("Generate dotrequirements behavioral specifications from a codebase");
+    // Install SIGTERM/SIGINT handlers for every cts subcommand so an interrupted
+    // pipeline emits a structured `pipeline/aborted` line before exiting
+    // (CTS-OBSERVE-1.5). preAction fires after argv parsing and before the
+    // subcommand action runs.
+    cts.hook("preAction", () => {
+        installCtsAbortHandlers();
+    });
     cts
         .command("pack")
         .description("Pack the codebase (compressed and uncompressed views) into the cache")
         .option("-s, --scope <path>", "Limit to files under this path (subdir of project root)")
         .option("--fresh", "Clear the cache before running")
         .option("--budget <tokens>", "Override the working-context budget (in tokens)", (v) => parseInt(v, 10))
+        .option("--ignore-requirements", "Exclude `.requirements/**` from the pack (use when testing cts against a codebase whose existing requirements should not influence the output)")
         .action((opts) => packCommand({ ...opts, budgetTokens: opts.budget }));
     cts
         .command("plan-loop")
@@ -81,6 +90,7 @@ export function registerCodebaseToSpec(program) {
         .option("--non-interactive", "Force non-interactive mode (override TTY detection)")
         .option("--overwrite", "Replace existing .requirements/ files without prompting")
         .option("--skip-existing", "Leave existing .requirements/ files untouched")
+        .option("--ignore-requirements", "Write output to `.requirements/cts/` instead of `.requirements/` (use together with `cts pack --ignore-requirements` when isolating cts from an existing requirements directory)")
         .action((opts) => {
         const forceMode = opts.interactive
             ? "interactive"
@@ -91,6 +101,7 @@ export function registerCodebaseToSpec(program) {
             forceMode,
             overwrite: opts.overwrite,
             skipExisting: opts.skipExisting,
+            ignoreRequirements: opts.ignoreRequirements,
         });
     });
     cts
@@ -105,6 +116,7 @@ export function registerCodebaseToSpec(program) {
         .option("--non-interactive", "Force non-interactive mode for the present stage")
         .option("--overwrite", "Replace existing .requirements/ files without prompting")
         .option("--skip-existing", "Leave existing .requirements/ files untouched")
+        .option("--ignore-requirements", "Exclude `.requirements/**` from the pack and write output to `.requirements/cts/` instead of `.requirements/` (use when testing cts against a codebase whose existing requirements should not influence the output)")
         .action((opts) => {
         const forceMode = opts.interactive
             ? "interactive"
@@ -118,6 +130,7 @@ export function registerCodebaseToSpec(program) {
             forceMode,
             overwrite: opts.overwrite,
             skipExisting: opts.skipExisting,
+            ignoreRequirements: opts.ignoreRequirements,
         });
     });
     cts

package/dist/commands/codebase-to-spec/pack.d.ts

@@ -13,6 +13,12 @@ export interface PackOptions {
     scope?: string;
     fresh?: boolean;
     budgetTokens?: number;
+    /**
+     * When true, exclude `.requirements/**` from the pack so an existing
+     * requirements directory does not influence the generated output.
+     * See CTS-PRESENT-5.
+     */
+    ignoreRequirements?: boolean;
     /** Override progress emitter, mainly for tests. */
     progress?: import("../../codebase-to-spec/progress.js").ProgressEmitter;
     /** Override the project root, mainly for tests. */

package/dist/commands/codebase-to-spec/pack.js

@@ -43,6 +43,7 @@ export async function packCommand(rawOptions = {}) {
         projectRoot,
         paths,
         scope: rawOptions.scope,
+        ignoreRequirements: rawOptions.ignoreRequirements,
     });
     progress.emit({
         stage: "pack",

package/dist/commands/codebase-to-spec/present.d.ts

@@ -15,6 +15,11 @@ export interface PresentCmdOptions {
     overwrite?: boolean;
     /** Skip writing files that would conflict (non-interactive). */
     skipExisting?: boolean;
+    /**
+     * When true, write output under `.requirements/cts/` instead of
+     * `.requirements/`. See CTS-PRESENT-5.
+     */
+    ignoreRequirements?: boolean;
     projectRoot?: string;
 }
 export declare function presentCommand(rawOptions?: PresentCmdOptions): Promise<void>;

package/dist/commands/codebase-to-spec/present.js

@@ -51,16 +51,21 @@ export async function presentCommand(rawOptions = {}) {
         process.exitCode = ExitCode.InvalidFlags;
         return;
     }
+    const outputSubdir = rawOptions.ignoreRequirements ? "cts" : undefined;
+    const outputDirLabel = outputSubdir
+        ? `.requirements/${outputSubdir}/`
+        : ".requirements/";
     progress.emit({
         stage: "present",
         step: "start",
-        message: `Writing final spec to .requirements/ (mode: ${isInteractive ? "interactive" : "non-interactive"}, policy: ${policy})`,
+        message: `Writing final spec to ${outputDirLabel} (mode: ${isInteractive ? "interactive" : "non-interactive"}, policy: ${policy})`,
     });
     const result = await runPresent({
         outline,
         finalSpecPath: paths.specFinal,
         projectRoot,
         overwritePolicy: policy,
+        outputSubdir,
     });
     // Per-file outcome announcements.
     for (const action of result.actions) {

package/dist/commands/codebase-to-spec/run.js

@@ -77,6 +77,7 @@ export async function runCommand(options = {}) {
         forceMode: options.forceMode,
         overwrite: options.overwrite,
         skipExisting: options.skipExisting,
+        ignoreRequirements: options.ignoreRequirements,
         projectRoot: options.projectRoot,
     });
     // Present sets a non-zero exit code on overwrite refusal or validation

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@popoverai/dotrequirements",
-  "version": "0.24.0",
+  "version": "0.24.2",
   "description": "Requirements tracking CLI, test harness, and MCP server",
   "type": "module",
   "bin": {
@@ -24,10 +24,9 @@
     "test": "vitest",
     "test:run": "vitest run",
     "test:coverage": "vitest run --coverage",
-    "prepublish:check": "git diff-index --quiet HEAD || (echo 'Error: Uncommitted changes detected. Commit or stash them first.' && exit 1)",
-    "publish:patch": "pnpm prepublish:check && npm version patch && pnpm build && npm publish && git push && git push --tags",
-    "publish:minor": "pnpm prepublish:check && npm version minor && pnpm build && npm publish && git push && git push --tags",
-    "publish:major": "pnpm prepublish:check && npm version major && pnpm build && npm publish && git push && git push --tags"
+    "publish:patch": "echo 'ERROR: publish:patch is decommissioned. CLI npm publishes now happen via the cli-publish GitHub Action when a production PR with a CLI version bump merges. Use the /release Claude Code skill to queue a bump and open the production PR. See docs/working/cli-publish-workflow.md for details.' && exit 1",
+    "publish:minor": "echo 'ERROR: publish:minor is decommissioned. CLI npm publishes now happen via the cli-publish GitHub Action when a production PR with a CLI version bump merges. Use the /release Claude Code skill to queue a bump and open the production PR. See docs/working/cli-publish-workflow.md for details.' && exit 1",
+    "publish:major": "echo 'ERROR: publish:major is decommissioned. CLI npm publishes now happen via the cli-publish GitHub Action when a production PR with a CLI version bump merges. Use the /release Claude Code skill to queue a bump and open the production PR. See docs/working/cli-publish-workflow.md for details.' && exit 1"
   },
   "keywords": [
     "requirements",
@@ -42,7 +41,7 @@
   "license": "MIT",
   "homepage": "https://dotrequirements.io",
   "bugs": {
-    "email": "support@popover.ca"
+    "email": "support@dotrequirements.io"
   },
   "engines": {
     "node": ">=18"

package/dist/codebase-to-spec/prompts/planner-apply.d.ts

@@ -1,12 +0,0 @@
-/**
- * System prompt for the applying planner (apply mode).
- *
- * Receives the prior outline + an explicit list of mechanical revisions and
- * applies them verbatim. Used when the reviewer's verdict was
- * `approved-with-revisions`.
- *
- * Requirements covered:
- * - CTS-PLAN-4: Approved-with-revisions outline triggers one mechanical revision
- */
-export declare const PLANNER_APPLY_PROMPT = "You are applying mechanical revisions to a planning outline. A reviewer has approved the outline subject to a specific list of small revisions. Your job is to apply each revision verbatim and emit the revised outline.\n\nYou are NOT revising the outline using your own judgment. You are NOT adding new areas, dropping existing areas, or restructuring. You ONLY apply the listed revisions.\n\nYou will output a JSON object matching the schema you have been given. No prose preamble, no explanation, no markdown fences \u2014 JSON only.\n\nYou will receive:\n1. The previous outline as JSON\n2. An explicit list of revisions, each phrased as a directive\n\n## Process\n\nFor each revision in the list:\n- Apply the directive exactly as stated.\n- If the directive is ambiguous or would require new judgment, leave that area unchanged and proceed.\n\nPreserve everything else from the prior outline byte-for-byte (modulo the listed changes).\n\n## Output\n\nOutput ONLY the JSON object matching the supplied schema. No preamble. Begin with `{`.";
-//# sourceMappingURL=planner-apply.d.ts.map

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

@@ -1,32 +0,0 @@
-/**
- * System prompt for the applying planner (apply mode).
- *
- * Receives the prior outline + an explicit list of mechanical revisions and
- * applies them verbatim. Used when the reviewer's verdict was
- * `approved-with-revisions`.
- *
- * Requirements covered:
- * - CTS-PLAN-4: Approved-with-revisions outline triggers one mechanical revision
- */
-export const PLANNER_APPLY_PROMPT = `You are applying mechanical revisions to a planning outline. A reviewer has approved the outline subject to a specific list of small revisions. Your job is to apply each revision verbatim and emit the revised outline.
-
-You are NOT revising the outline using your own judgment. You are NOT adding new areas, dropping existing areas, or restructuring. You ONLY apply the listed revisions.
-
-You will output a JSON object matching the schema you have been given. No prose preamble, no explanation, no markdown fences — JSON only.
-
-You will receive:
-1. The previous outline as JSON
-2. An explicit list of revisions, each phrased as a directive
-
-## Process
-
-For each revision in the list:
-- Apply the directive exactly as stated.
-- If the directive is ambiguous or would require new judgment, leave that area unchanged and proceed.
-
-Preserve everything else from the prior outline byte-for-byte (modulo the listed changes).
-
-## Output
-
-Output ONLY the JSON object matching the supplied schema. No preamble. Begin with \`{\`.`;
-//# sourceMappingURL=planner-apply.js.map