@popoverai/dotrequirements 0.26.2 → 0.27.1

package/dist/requirements/style-guide.js

@@ -11,27 +11,47 @@
  *
  * If the project has a `.requirements/STYLE.md`, callers can pass its
  * contents via `localStyleGuide` to use that body in place of the bundled
- * defaults. See {@link readLocalStyleGuide} for the lookup helper.
+ * defaults. See `readLocalStyleGuide` in ./style-guide-file.ts (CLI-only —
+ * this module stays free of node:fs so the web can serve the same primer).
  */
-import { existsSync, readFileSync } from "node:fs";
-import { join } from "node:path";
+import { ROOT_LABEL_MARKER } from "../schema/parser-core.js";
 /**
- * Conventional location of a project's STYLE.md, relative to the workspace
- * root. Exported so callers (init, push/pull, tests) can reference one place.
+ * How many discovered labels or key prefixes the guide will show.
+ *
+ * These lists exist under "match the existing pattern", and past ten that
+ * instruction stops being actionable — a reader can't match a hundred and forty
+ * things. Worse, an uncapped list presents whatever sprawl a codebase has
+ * accumulated as the house style, so each new author reproduces it and the list
+ * grows: the mechanism meant to hold conventions steady is what compounds their
+ * drift. Ten is a sample, and the trailing count says so rather than letting the
+ * truncation read as the whole set.
  */
-export const STYLE_MD_PATH = ".requirements/STYLE.md";
+const SAMPLE_LIMIT = 10;
 /**
- * Read `.requirements/STYLE.md` if the workspace has one. Returns the file
- * contents on success, `null` if the file is absent. Empty / whitespace-only
- * files are treated as absent so the bundled defaults still apply.
+ * The most-used values first, not the alphabetically-first.
+ *
+ * Sorting by name and taking the head is a trap: on this codebase it yields ten
+ * prefixes all beginning with "A", which under "match the existing pattern"
+ * teaches a convention nobody has. Frequency is what the phrase actually means —
+ * the prefixes carrying the most requirements are the house style. Ties break
+ * alphabetically so the sample is stable across runs.
  */
-export function readLocalStyleGuide(workspaceRoot) {
-    const fullPath = join(workspaceRoot, STYLE_MD_PATH);
-    if (!existsSync(fullPath)) {
-        return null;
-    }
-    const contents = readFileSync(fullPath, "utf-8");
-    return contents.trim().length > 0 ? contents : null;
+function sample(counts) {
+    const ranked = Array.from(counts.entries())
+        .sort(([aName, aCount], [bName, bCount]) => bCount === aCount ? aName.localeCompare(bName) : bCount - aCount)
+        .map(([name]) => name);
+    return {
+        list: ranked
+            .slice(0, SAMPLE_LIMIT)
+            .map((v) => `"${v}"`)
+            .join(", "),
+        more: ranked.length > SAMPLE_LIMIT
+            ? ` (and ${ranked.length - SAMPLE_LIMIT} more)`
+            : "",
+    };
+}
+function tally(counts, key) {
+    counts.set(key, (counts.get(key) ?? 0) + 1);
 }
 /**
  * Build the body of the bundled default style guide. This is the content
@@ -46,43 +66,45 @@ export function readLocalStyleGuide(workspaceRoot) {
  */
 export function generateStyleGuideBody(params) {
     const { requirements, customStyleGuidance } = params;
-    const labels = new Set();
-    const keyPrefixes = new Set();
+    const labels = new Map();
+    const keyPrefixes = new Map();
     for (const req of requirements) {
-        if (req.label?.trim()) {
-            labels.add(req.label);
+        // The root marker is on every root in every workspace and chosen by nobody,
+        // so counting it would hand back a storage detail as house style. Worst for
+        // a project that took this guide's own advice to leave criteria unlabelled:
+        // it would be the only label found, and would suppress the "default to
+        // unlabeled" branch below in favour of matching a label nobody types.
+        if (req.label?.trim() && req.label !== ROOT_LABEL_MARKER) {
+            tally(labels, req.label);
         }
         if (req.path.length === 0 && req.id) {
             const lastDashIndex = req.id.lastIndexOf("-");
             if (lastDashIndex > 0) {
-                keyPrefixes.add(req.id.substring(0, lastDashIndex));
+                tally(keyPrefixes, req.id.substring(0, lastDashIndex));
             }
         }
     }
-    const discoveredLabels = Array.from(labels).sort();
-    const discoveredPrefixes = Array.from(keyPrefixes).sort();
     let labelGuidance;
-    if (discoveredLabels.length > 0) {
-        const labelList = discoveredLabels
-            .slice(0, 10)
-            .map((l) => `"${l}"`)
-            .join(", ");
-        const more = discoveredLabels.length > 10
-            ? ` (and ${discoveredLabels.length - 10} more)`
-            : "";
+    if (labels.size > 0) {
+        const { list: labelList, more } = sample(labels);
         labelGuidance = `**Existing labels in this codebase:** ${labelList}${more}
 
 **Use these existing labels** to maintain consistency. If you're unsure which labels to use for a new requirement, ask the user.`;
     }
     else {
-        labelGuidance = `**No existing requirements found in this codebase.**
+        // Says *labels*, not requirements. Reaching here means nobody has labelled
+        // a criterion — which is what a project following the advice below looks
+        // like, not an empty one. The key-prefix branch shares this sentence and is
+        // right to: there, an empty set really does mean no requirements. Here it
+        // would contradict the prefix list printed two headings above.
+        labelGuidance = `**No labelled criteria found in this codebase.**
 
 **Default to unlabeled requirements** (\`0. → content\`). If the user wants labels, ask them which format they prefer. Do not choose an opinionated framework like Given/When/Then without explicit user consent.`;
     }
     let keyGuidance;
-    if (discoveredPrefixes.length > 0) {
-        const prefixList = discoveredPrefixes.map((p) => `"${p}"`).join(", ");
-        keyGuidance = `**Existing requirement key prefixes in this codebase:** ${prefixList}
+    if (keyPrefixes.size > 0) {
+        const { list: prefixList, more } = sample(keyPrefixes);
+        keyGuidance = `**Existing requirement key prefixes in this codebase:** ${prefixList}${more}
 
 **Match the existing pattern** when creating new requirement keys. Use the same domain prefixes and sequential numbering style.`;
     }

package/dist/schema/browser.d.ts

@@ -6,7 +6,7 @@
 export { buildRequirementMarkdown, buildRequirementsMarkdown, DEFAULT_DELIMITER, } from "./builder.js";
 export type { ConvexRequirement } from "./conversions.js";
 export { buildMetadata, constructKey, convexToRequirements, extractRequirementKeys, groupByRoot, parseKey, requirementsToConvex, } from "./conversions.js";
-export { DELIMITER_PATTERN, extractRequirementBlocks, findRequirementById, flattenRequirementTree, getAllRequirements, parseCriterionLine, parseRequirementBlock, parseRequirementBlocksFromMarkdown, parseRootLine, } from "./parser-core.js";
+export { DELIMITER_PATTERN, extractRequirementBlocks, findRequirementById, flattenRequirementTree, getAllRequirements, parseCriterionLine, parseRequirementBlock, parseRequirementBlocksFromMarkdown, parseRootLine, ROOT_LABEL_MARKER, } from "./parser-core.js";
 export type { Metadata, ParsedCriterion, RequirementKey, RequirementNode, RequirementPrefix, RequirementsFile, } from "./schemas.js";
 export { buildRequirementKey, MetadataSchema, normalizePrefix, ParsedCriterionSchema, parseRequirementKey, REQUIREMENT_KEY_PATTERN, REQUIREMENT_PREFIX_PATTERN, RequirementKeySchema, RequirementNodeSchema, RequirementPrefixSchema, RequirementsFileSchema, ValidationError, validateKey, validateMetadata, validatePrefix, validateRequirementNode, validateRequirementsFile, } from "./schemas.js";
 export type { BuildScenarioOptions, Scenario, ScenarioAssertionSource, ScenarioStep, } from "./scenario.js";

package/dist/schema/browser.js

@@ -8,7 +8,10 @@ export { buildRequirementMarkdown, buildRequirementsMarkdown, DEFAULT_DELIMITER,
 export { buildMetadata, constructKey, convexToRequirements, extractRequirementKeys, groupByRoot, parseKey, requirementsToConvex, } from "./conversions.js";
 // Parser core (pure TypeScript - browser-safe, no fs dependency)
 // These functions parse markdown strings directly without file I/O
-export { DELIMITER_PATTERN, extractRequirementBlocks, findRequirementById, flattenRequirementTree, getAllRequirements, parseCriterionLine, parseRequirementBlock, parseRequirementBlocksFromMarkdown, parseRootLine, } from "./parser-core.js";
+export { DELIMITER_PATTERN, extractRequirementBlocks, findRequirementById, flattenRequirementTree, getAllRequirements, parseCriterionLine, parseRequirementBlock, parseRequirementBlocksFromMarkdown, parseRootLine, 
+// The web reaches parser-core only through this entry point, so without this
+// its readers have no way to import the marker and must hard-code it.
+ROOT_LABEL_MARKER, } from "./parser-core.js";
 // Schemas and types (uses zod - browser-safe)
 export { buildRequirementKey, 
 // Zod schemas

package/dist/schema/parser-core.d.ts

@@ -5,6 +5,21 @@
  * making it safe to import in Convex runtime or browser environments.
  */
 import { type ParsedCriterion, type RequirementNode } from "./schemas.js";
+/**
+ * The label stamped on every requirement's root, for indexing and querying.
+ *
+ * An internal marker, not a convention: no author writes it, the markdown
+ * format has no syntax for it, and consumers that show labels to a human or an
+ * agent must exclude it — the harness's output filters, Convex's label queries,
+ * and the style guide's discovered-label list all do.
+ *
+ * Declared here because this is where parsing stamps it, but be warned: most of
+ * those readers still hard-code the literal, and `web/lib/markdown-conversion`
+ * stamps it independently for the BlockNote path. So renaming this does NOT yet
+ * move everyone with it — you would have to grep. Each reader migrated here is
+ * one that a rename can no longer silently strand.
+ */
+export declare const ROOT_LABEL_MARKER = "requirementHeader";
 /**
  * Default delimiter for requirements.
  * Can be overridden for organization-specific preferences.
@@ -15,6 +30,19 @@ export declare const DELIMITER_PATTERN = "(?:\u2192|->)";
  * Parse a criterion line in "position. Label → content" format.
  * Example: "0. Given → user has valid credentials"
  * Also supports optional label: "0. → user has valid credentials"
+ *
+ * This is the canonical criterion grammar (SYNC-KEY-1.4). The web editor's
+ * markdown-conversion parser mirrors this exact behavior; keep them in sync.
+ *
+ * Two behaviors are load-bearing:
+ *  - Split on the FIRST delimiter only, so an arrow inside the content
+ *    ("maps A -> B") is preserved verbatim rather than being re-consumed as a
+ *    label boundary. Everything before the first delimiter is the (optional,
+ *    freeform — custom labels are supported, see MARKDOWN_SCHEMA) label;
+ *    everything after is content.
+ *  - An empty criterion ("0. → ") is a valid criterion with content "", not a
+ *    parse failure. Returning null here would make parseRequirementBlocksFromMarkdown
+ *    reject the whole block, and would drop the criterion (and its subtree) on load.
  */
 export declare function parseCriterionLine(line: string, delimiter?: string): ParsedCriterion | null;
 /**

package/dist/schema/parser-core.js

@@ -5,30 +5,69 @@
  * making it safe to import in Convex runtime or browser environments.
  */
 import { ValidationError, validateKey, } from "./schemas.js";
+/**
+ * The label stamped on every requirement's root, for indexing and querying.
+ *
+ * An internal marker, not a convention: no author writes it, the markdown
+ * format has no syntax for it, and consumers that show labels to a human or an
+ * agent must exclude it — the harness's output filters, Convex's label queries,
+ * and the style guide's discovered-label list all do.
+ *
+ * Declared here because this is where parsing stamps it, but be warned: most of
+ * those readers still hard-code the literal, and `web/lib/markdown-conversion`
+ * stamps it independently for the BlockNote path. So renaming this does NOT yet
+ * move everyone with it — you would have to grep. Each reader migrated here is
+ * one that a rename can no longer silently strand.
+ */
+export const ROOT_LABEL_MARKER = "requirementHeader";
 /**
  * Default delimiter for requirements.
  * Can be overridden for organization-specific preferences.
  */
 export const DEFAULT_DELIMITER = "→";
 export const DELIMITER_PATTERN = "(?:→|->)"; // Non-capturing group for both Unicode and ASCII
+// Compiled once for the common (default-delimiter) path so parseCriterionLine
+// doesn't rebuild the same RegExp on every line.
+const DEFAULT_DELIMITER_REGEX = new RegExp(DELIMITER_PATTERN);
 /**
  * Parse a criterion line in "position. Label → content" format.
  * Example: "0. Given → user has valid credentials"
  * Also supports optional label: "0. → user has valid credentials"
+ *
+ * This is the canonical criterion grammar (SYNC-KEY-1.4). The web editor's
+ * markdown-conversion parser mirrors this exact behavior; keep them in sync.
+ *
+ * Two behaviors are load-bearing:
+ *  - Split on the FIRST delimiter only, so an arrow inside the content
+ *    ("maps A -> B") is preserved verbatim rather than being re-consumed as a
+ *    label boundary. Everything before the first delimiter is the (optional,
+ *    freeform — custom labels are supported, see MARKDOWN_SCHEMA) label;
+ *    everything after is content.
+ *  - An empty criterion ("0. → ") is a valid criterion with content "", not a
+ *    parse failure. Returning null here would make parseRequirementBlocksFromMarkdown
+ *    reject the whole block, and would drop the criterion (and its subtree) on load.
  */
 export function parseCriterionLine(line, delimiter = DELIMITER_PATTERN) {
-    // Match: position + period + space + optional(label + space) + delimiter + space + content
-    // Position can be: 0, 1.0, 2.3.1, etc.
-    // Label can contain any characters except the delimiter
-    const pattern = new RegExp(`^\\s*(\\d+(?:\\.\\d+)*)\\.\\s*(?:(.+?)\\s+)?${delimiter}\\s*(.+)$`);
-    const match = line.match(pattern);
-    if (!match) {
+    // Position prefix: "0.", "1.0.", "2.3.1." — required for a criterion line.
+    const positionMatch = line.match(/^\s*(\d+(?:\.\d+)*)\.\s*/);
+    if (!positionMatch) {
+        return null;
+    }
+    const rest = line.slice(positionMatch[0].length);
+    const delimiterMatch = rest.match(delimiter === DELIMITER_PATTERN
+        ? DEFAULT_DELIMITER_REGEX
+        : new RegExp(delimiter));
+    if (!delimiterMatch || delimiterMatch.index === undefined) {
         return null;
     }
+    const label = rest.slice(0, delimiterMatch.index).trim();
+    const content = rest
+        .slice(delimiterMatch.index + delimiterMatch[0].length)
+        .trim();
     return {
-        position: match[1],
-        label: match[2] ? match[2].trim() : "", // Preserve original case, empty if no label
-        content: match[3].trim(),
+        position: positionMatch[1],
+        label, // Preserve original case; freeform (empty when no label)
+        content, // May be "" for an empty criterion
     };
 }
 /**
@@ -79,9 +118,9 @@ export function parseRequirementBlock(key, blockContent) {
     }
     const root = {
         id: key,
-        // Root requirements always use "requirementHeader" label for indexing/querying
-        // The markdown format doesn't preserve root labels, but we standardize on this value
-        label: "requirementHeader",
+        // Root requirements always use this label for indexing/querying. The
+        // markdown format doesn't preserve root labels, so we standardize on it.
+        label: ROOT_LABEL_MARKER,
         content: rootParsed.content,
         children: [],
     };

package/dist/templates/context-file-section.md

@@ -10,13 +10,14 @@ requirements, so your plan should too.
 
 **ALWAYS follow this workflow when changing system behavior** (new features, bug fixes, any behavioral change). Only pure refactoring (same behavior, different code) may skip requirements.
 
-1. **Find or write requirements** - Check `.requirements/` for existing specs; write new ones if needed
-2. **Style-check** - Run `mcp__dotrequirements__style_check` on the file
-3. **Get approval** - Present requirements, wait for go-ahead
-4. **Implement** - Build the feature
-5. **Write tests** - Reference requirements with `requirement()`
-6. **Run tests** - Verify everything passes
-7. **Review tests** - Run `mcp__dotrequirements__review_test` to validate coverage
+1. **Find or write requirements** - Check `.requirements/` for existing specs (`dotreq search`, `dotreq get`, `dotreq list`); write new ones if needed (`dotreq create-requirement-document` prints the template and style guide)
+2. **Style-review** - Dispatch a subagent to run `dotreq style-check <file>` and judge the requirements against the style guide it emits. If this platform cannot dispatch subagents, run the command and perform the review in this conversation.
+3. **Validate** - Run `dotreq validate` to check syntax
+4. **Get approval** - Present requirements, wait for go-ahead
+5. **Implement** - Build the feature
+6. **Write tests** - Reference requirements with `requirement()`
+7. **Run tests** - Verify everything passes
+8. **Test-review** - Dispatch a subagent to run `dotreq review-test <test-file>` and judge the tests against the materials it emits. Same fallback: no subagent support, review in this conversation.
 
 ### Requirements Syntax
 
@@ -31,7 +32,7 @@ DOMAIN-1: Short description of expected behavior
 - Criteria: `position. -> content` (optional label before the arrow)
 - Nesting: Indent with 2 spaces, use `x.y` position paths
 - Delimiter: `->` or `→`
-- **Key style**: Use sequential keys with a short domain prefix (`ORCHESTRATOR-1`, `ORCHESTRATOR-2`, ...) rather than semantic keys (`AUTONOMOUS-ADVANCE`). Sequential keys stay stable when a requirement gets reworded, so test references don't break. Call `create_requirement_document` for full key-naming guidance.
+- **Key style**: Use sequential keys with a short domain prefix (`ORCHESTRATOR-1`, `ORCHESTRATOR-2`, ...) rather than semantic keys (`AUTONOMOUS-ADVANCE`). Sequential keys stay stable when a requirement gets reworded, so test references don't break. Run `dotreq create-requirement-document` for full key-naming guidance.
 
 ### Test Usage
 
@@ -44,21 +45,23 @@ test(requirement('REQ-ID'), () => { /* test the requirement */ });
 test(requirement('REQ-ID.0'), () => { /* test specific criterion */ });
 ```
 
-### MCP Tools
+### CLI Verbs
 
 **Exploration:**
-- `list_requirements` - Overview of all requirements (set `untested: true` to filter to coverage gaps)
-- `get_requirement` - Requirement tree with test coverage
-- `search_requirements` - Search by text/regex
+- `dotreq list [--untested]` - Overview of all requirements (`--untested` filters to coverage gaps)
+- `dotreq get <id>` - Requirement tree with test coverage
+- `dotreq search <query> [--regex]` - Search by text/regex
+- `dotreq requirements-for <test-file>` - See requirements a test file covers
+- `dotreq tests-for <req-file>` - See test coverage for a requirements file
 
 **Authoring:**
-- `create_requirement_document` - Get template with format guidance
-- `validate_requirements` - Check syntax (works offline)
-- `style_check` - AI feedback on clarity
-- `push_requirements` - Sync to cloud
-
-**Testing:**
-- `get_requirements_by_test` - See requirements a test file covers
-- `list_requirements` (with `untested: true`) - Find requirements without tests
-- `report_coverage` - Get test coverage from local cache or cloud
-- `review_test` - Validate tests match requirement intent
+- `dotreq create-requirement-document [path]` - Print the template and style guide
+- `dotreq validate [glob]` - Check syntax (works offline)
+- `dotreq push [file]` - Sync to cloud (shows diff preview, then confirms)
+
+**Review (judgment runs in the dispatched subagent):**
+- `dotreq style-check <file>` - Emits the style guide + content for the reviewer to judge (`--source cloud` for hosted review)
+- `dotreq review-test <test-file>` - Emits referenced requirement trees + test content for the reviewer to judge (`--source cloud` for hosted review)
+
+**Coverage:**
+- `dotreq report [--source local|cloud]` - Test coverage report

package/dist/utils/context-file.d.ts

@@ -3,7 +3,11 @@
  */
 export declare function getContextFileName(platform: string): string | null;
 /**
- * Find the git root directory
+ * Find the git root directory.
+ *
+ * CONTEXT-FILE-6: in a worktree, .git is a FILE pointing at the main
+ * checkout — matching directories only would walk past it and resolve to
+ * the main checkout's root, landing the context file in the wrong tree.
  */
 export declare function findGitRoot(): Promise<string | null>;
 /**
@@ -39,8 +43,8 @@ export declare function getContextFilePath(platform: string): Promise<string | n
  * Build a user-facing message explaining that context file installation
  * was skipped because the current directory is not inside a git repository.
  *
- * The MCP server itself is configured separately, so this message is only
- * about the second step (writing the platform's context file).
+ * Writing the platform's context file is the whole of setup now, so a missing
+ * git root means nothing was installed.
  */
 export declare function buildNoGitRepoMessage(fileName: string): string;
 //# sourceMappingURL=context-file.d.ts.map

package/dist/utils/context-file.js

@@ -11,7 +11,8 @@ const PLATFORM_CONTEXT_FILES = {
     cursor: "AGENTS.md",
     codex: "AGENTS.md",
     "github-copilot": "AGENTS.md",
-    antigravity: "GEMINI.md",
+    // Antigravity 2.0 retired the GEMINI.md/.gemini conventions for AGENTS.md
+    antigravity: "AGENTS.md",
 };
 /**
  * Get the appropriate context file name for a platform
@@ -20,10 +21,14 @@ export function getContextFileName(platform) {
     return PLATFORM_CONTEXT_FILES[platform] ?? null;
 }
 /**
- * Find the git root directory
+ * Find the git root directory.
+ *
+ * CONTEXT-FILE-6: in a worktree, .git is a FILE pointing at the main
+ * checkout — matching directories only would walk past it and resolve to
+ * the main checkout's root, landing the context file in the wrong tree.
  */
 export async function findGitRoot() {
-    const gitDir = await findUp(".git", { type: "directory" });
+    const gitDir = await findUp(".git", { type: "both" });
     return gitDir ? dirname(gitDir) : null;
 }
 /**
@@ -95,8 +100,8 @@ export async function getContextFilePath(platform) {
  * Build a user-facing message explaining that context file installation
  * was skipped because the current directory is not inside a git repository.
  *
- * The MCP server itself is configured separately, so this message is only
- * about the second step (writing the platform's context file).
+ * Writing the platform's context file is the whole of setup now, so a missing
+ * git root means nothing was installed.
  */
 export function buildNoGitRepoMessage(fileName) {
     return [
@@ -106,8 +111,6 @@ export function buildNoGitRepoMessage(fileName) {
         "   To finish setup, either:",
         "     • run `git init` here, then re-run `dotreq ai-setup`, or",
         "     • `cd` into an existing project directory and run `dotreq ai-setup` there.",
-        "",
-        "   Note: the MCP server itself was configured successfully — only the context file step was skipped.",
     ].join("\n");
 }
 //# sourceMappingURL=context-file.js.map

package/dist/utils/project-settings.d.ts

@@ -41,6 +41,7 @@ export interface ProjectInfo {
  * Returns undefined if either is missing.
  */
 export declare function getCredentialsFromEnv(): ProjectSettings | undefined;
+export declare function setAuthFromEnv(enabled: boolean): void;
 /**
  * Find the project root by walking up from startDir looking for .requirements/ folder
  * Returns the directory containing .requirements/, or undefined if not found

package/dist/utils/project-settings.js

@@ -18,6 +18,19 @@ export function getCredentialsFromEnv() {
     }
     return undefined;
 }
+/**
+ * AUTHZ-6: explicit CI/CD credential injection. Set by the global
+ * --auth-from-env flag (cli.ts preAction hook); when enabled,
+ * getProjectCredentials reads DOTREQ_PROJECT_ID / DOTREQ_PROJECT_SECRET
+ * instead of file-based discovery. Without the flag those variables are
+ * ignored entirely — the explicit opt-in prevents credential conflicts
+ * between local and CI environments. (Previously the retired MCP server's
+ * --auth-from-env; ported to the CLI with identical semantics.)
+ */
+let authFromEnv = false;
+export function setAuthFromEnv(enabled) {
+    authFromEnv = enabled;
+}
 /**
  * Find the project root by walking up from startDir looking for .requirements/ folder
  * Returns the directory containing .requirements/, or undefined if not found
@@ -157,6 +170,15 @@ export function getProjectInfo(startDir = process.cwd()) {
  * Get project credentials, throwing helpful error if not available
  */
 export function getProjectCredentials(startDir = process.cwd()) {
+    // AUTHZ-6.0 / 6.1: with the explicit flag, env credentials replace
+    // file-based discovery entirely
+    if (authFromEnv) {
+        const envCredentials = getCredentialsFromEnv();
+        if (!envCredentials) {
+            throw new Error("--auth-from-env requires both DOTREQ_PROJECT_ID and DOTREQ_PROJECT_SECRET environment variables to be set.");
+        }
+        return envCredentials;
+    }
     const info = getProjectInfo(startDir);
     if (!info) {
         throw new Error('No dotrequirements project found. Run "dotrequirements init" to create one.');

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@popoverai/dotrequirements",
-  "version": "0.26.2",
-  "description": "Requirements tracking CLI, test harness, and MCP server",
+  "version": "0.27.1",
+  "description": "Requirements tracking CLI and test harness",
   "type": "module",
   "bin": {
     "dotrequirements": "./dist/cli.js",
@@ -12,7 +12,7 @@
     "./test": "./dist/harness/index.js",
     "./schema": "./dist/schema/index.js",
     "./schema/browser": "./dist/schema/browser.js",
-    "./mcp": "./dist/mcp/index.js"
+    "./style-guide": "./dist/requirements/style-guide.js"
   },
   "publishConfig": {
     "access": "public"
@@ -34,7 +34,6 @@
     "test-coverage",
     "bdd",
     "tdd",
-    "mcp",
     "ai-assistant"
   ],
   "author": "Will Raymer @Popover",

package/dist/mcp/convexClient.d.ts

@@ -1,19 +0,0 @@
-/**
- * Production Convex deployment URL
- */
-export declare const CONVEX_URL = "https://data.dotrequirements.io";
-/**
- * Convex configuration for cloud operations
- */
-interface ConvexConfig {
-    convexUrl: string;
-    projectId: string;
-    projectSecret: string;
-}
-/**
- * Load Convex configuration from project settings.
- * Returns null if credentials are not configured.
- */
-export declare function loadConvexConfig(cwd?: string): ConvexConfig | null;
-export {};
-//# sourceMappingURL=convexClient.d.ts.map

package/dist/mcp/convexClient.js

@@ -1,24 +0,0 @@
-import { getProjectCredentials } from "../utils/project-settings.js";
-/**
- * Production Convex deployment URL
- */
-export const CONVEX_URL = "https://data.dotrequirements.io";
-/**
- * Load Convex configuration from project settings.
- * Returns null if credentials are not configured.
- */
-export function loadConvexConfig(cwd = process.cwd()) {
-    try {
-        const credentials = getProjectCredentials(cwd);
-        return {
-            convexUrl: CONVEX_URL,
-            projectId: credentials.projectId,
-            projectSecret: credentials.projectSecret,
-        };
-    }
-    catch {
-        // Credentials not found or project not connected to cloud
-        return null;
-    }
-}
-//# sourceMappingURL=convexClient.js.map

package/dist/mcp/handlers/authoring.d.ts

@@ -1,41 +0,0 @@
-/**
- * Authoring handlers for MCP tools
- *
- * Provides document creation and validation:
- * - create_requirement_document: Generate requirements template with format guidance
- * - validate_requirements: Validate requirements file syntax offline
- */
-import type { HandlerContext, ToolResponse } from "./types.js";
-/**
- * Arguments for create_requirement_document tool
- */
-export interface CreateRequirementDocumentArgs {
-    filePath?: string;
-}
-/**
- * Arguments for validate_requirements tool
- */
-export interface ValidateRequirementsArgs {
-    filePath: string;
-}
-/**
- * Handler for create_requirement_document tool
- *
- * Requirements covered:
- * - MCP-AUTHOR-1.0: The template includes format guidance with code block examples
- * - MCP-AUTHOR-1.1: The template includes style guidance (concrete examples, concise prose, testable conditions)
- * - MCP-AUTHOR-1.2: When the project has requirementsStyleContext configured, it is included in the template
- * - MCP-AUTHOR-1.3: When cloud credentials are unavailable, the template works without the custom context
- */
-export declare function handleCreateRequirementDocument(args: CreateRequirementDocumentArgs, context: HandlerContext): Promise<ToolResponse>;
-/**
- * Handler for validate_requirements tool
- *
- * Requirements covered:
- * - MCP-AUTHOR-2.1: When the file has valid syntax, the response confirms validation passed
- * - MCP-AUTHOR-2.2: When the file has syntax errors, the response lists each error with location
- * - MCP-AUTHOR-2.3: Validation does not require network access or cloud credentials
- * - MCP-AUTHOR-2.4: When the file does not exist, an error is returned
- */
-export declare function handleValidateRequirements(args: ValidateRequirementsArgs, context: HandlerContext): Promise<ToolResponse>;
-//# sourceMappingURL=authoring.d.ts.map