@popoverai/dotrequirements 0.13.0 → 0.15.0

package/dist/templates/antigravity-overview-rule.md

@@ -1,3 +0,0 @@
-<!-- BEGIN dotreq-overview -->
-{{OVERVIEW_CORE}}
-<!-- END dotreq-overview -->

package/dist/templates/antigravity-test-rule.md

@@ -1,3 +0,0 @@
-<!-- BEGIN dotreq-tests -->
-{{TEST_WRITING_CORE}}
-<!-- END dotreq-tests -->

package/dist/templates/behavioral-core.md

@@ -1,25 +0,0 @@
-# Requirements Capture
-
-ALWAYS ask about capturing requirements when the user requests new functionality (not bug fixes or refactoring).
-
-Ask: "Should we capture what this should do before we build it?"
-
-If yes, use the MCP tools for requirements writing.
-
-## Workflow
-
-1. **Ask questions** only if there are major gaps in expected behavior
-2. **Use requirements as alignment** - Get assumptions on paper quickly instead of playing twenty questions
-3. **Think MVP** - Don't expand scope without consulting the user
-4. **After building** - Suggest testing against the requirements using the project's standard testing tools
-
-Be helpful, consultative, and encouraging; not obstructive.
-
-## MCP Tools for Requirements
-
-- `create_requirement_document` - Get template with codebase-aware format guidance and style principles
-- `validate_requirements` - Check syntax before pushing (works offline)
-- `style_check` - Get AI feedback on writing quality and clarity
-- `push_requirements` - Sync to cloud (shows diff preview, then confirms)
-
-Note: Users can also explicitly trigger this workflow with `/capture-requirements`.

package/dist/templates/claude-code-overview-skill.md

@@ -1,6 +0,0 @@
----
-name: dotreq-overview
-description: Use this to understand what the system is supposed to do. ALWAYS use it when exploring expected behavior.
----
-
-{{OVERVIEW_CORE}}

package/dist/templates/claude-code-skill.md

@@ -1,6 +0,0 @@
----
-name: dotreq-requirements
-description: Use this when adding new expected behavior to the system. ALWAYS use it when implementing new functionality.
----
-
-{{BEHAVIORAL_CORE}}

package/dist/templates/claude-code-test-skill.md

@@ -1,6 +0,0 @@
----
-name: dotreq-tests
-description: Use this when validating expected behavior. ALWAYS use it when writing tests.
----
-
-{{TEST_WRITING_CORE}}

package/dist/templates/codex-agents.md

@@ -1,3 +0,0 @@
-<!-- BEGIN dotreq-requirements -->
-{{BEHAVIORAL_CORE}}
-<!-- END dotreq-requirements -->

package/dist/templates/codex-overview-agents.md

@@ -1,3 +0,0 @@
-<!-- BEGIN dotreq-overview -->
-{{OVERVIEW_CORE}}
-<!-- END dotreq-overview -->

package/dist/templates/codex-test-agents.md

@@ -1,3 +0,0 @@
-<!-- BEGIN dotreq-tests -->
-{{TEST_WRITING_CORE}}
-<!-- END dotreq-tests -->

package/dist/templates/cursor-overview-rule.mdc

@@ -1,5 +0,0 @@
----
-description: Use this to understand what the system is supposed to do. ALWAYS use it when exploring expected behavior.
----
-
-{{OVERVIEW_CORE}}

package/dist/templates/cursor-rule.mdc

@@ -1,5 +0,0 @@
----
-description: Use this when adding new expected behavior to the system. ALWAYS use it when implementing new functionality.
----
-
-{{BEHAVIORAL_CORE}}

package/dist/templates/cursor-test-rule.mdc

@@ -1,5 +0,0 @@
----
-description: Use this when validating expected behavior. ALWAYS use it when writing tests.
----
-
-{{TEST_WRITING_CORE}}

package/dist/templates/overview-core.md

@@ -1,27 +0,0 @@
-# Understanding Expected Behavior
-
-ALWAYS use this when you want to understand what the system is supposed to do.
-
-## Where to Find Expected Behavior
-
-This project uses **requirements as the source of truth** for expected behavior.
-
-**Location:** `.requirements/` directory contains `*.requirements.md` files
-
-**Format:** Requirements are structured as:
-- Requirement IDs (e.g., `AUTH-1`, `LOGIN-2`)
-- Descriptions of expected behavior
-- Hierarchical structure (parent requirements with child criteria)
-
-## MCP Tools for Exploration
-
-- `list_all_requirements` - Get overview of all requirements in the project
-- `get_requirement` - Get detailed requirement tree with test coverage
-- `search_requirements` - Search by text/regex across all requirements
-- `get_requirements_by_test` - See what a test file validates
-
-## Next Steps
-
-Once you understand the expected behavior:
-- **Adding new behavior?** Use the `dotreq-requirements` skill
-- **Writing tests?** Use the `dotreq-tests` skill

package/dist/templates/test-writing-core.md

@@ -1,72 +0,0 @@
-# Test Writing with Requirements
-
-ALWAYS use this guidance when writing tests based on requirements.
-
-## Core Principle
-
-Use `requirement()` AS the test description, not in the body or comments.
-
-```typescript
-// ✅ Good
-test(requirement('AUTH-1'), () => { /* test */ });
-
-// ❌ Bad
-test("user can log in", () => { requirement('AUTH-1'); });
-```
-
-## Test Structure
-
-**Match the requirement hierarchy:**
-
-For structured requirements, nest describe/it blocks:
-
-```typescript
-describe(requirement('LOGIN-1'), () => {
-  describe(requirement('LOGIN-1.given'), () => {
-    // Arrange
-  });
-  describe(requirement('LOGIN-1.when'), () => {
-    // Act
-    it(requirement('LOGIN-1.then'), () => {
-      // Assert
-    });
-  });
-});
-```
-
-For simple requirements, use a single test block.
-
-## Comments
-
-Comments should describe the TEST implementation, not copy the requirement text verbatim.
-
-**NEVER document coverage in comments.** Our MCP tools track coverage automatically.
-
-```typescript
-// ❌ Bad - creates second source of truth
-/**
- * Requirements coverage:
- * - AUTH-9.0: Backend creates project ✓
- * - AUTH-9.1: CLI writes to .env.local ✓
- */
-
-// ✅ Good - use MCP tools instead
-// Use get_requirement, get_requirements_by_test to see coverage
-```
-
-## Workflow
-
-After writing tests:
-
-1. Run tests to ensure they don't throw errors
-2. **ALWAYS run `review_test`** on the test file to validate tests actually check what requirements specify
-3. Fix any issues identified by the review
-
-## MCP Tools for Test Writing
-
-- `get_requirement` - Get requirement tree with existing coverage
-- `get_requirements_by_test` - See requirements referenced in a test file
-- `list_untested_requirements` - Find requirements without tests
-- `review_test` - Validate test actually checks what requirement specifies (run after writing tests)
-
-Note: Users can also explicitly trigger this workflow with `/write-tests`.

package/dist/utils/detect-existing-project.d.ts

@@ -1,5 +0,0 @@
-/**
- * Detect if .requirements/ directory exists and extract projectId from files
- */
-export declare function detectExistingProject(cwd: string): string | null;
-//# sourceMappingURL=detect-existing-project.d.ts.map

package/dist/utils/detect-existing-project.js

@@ -1,34 +0,0 @@
-import * as fs from 'fs';
-import * as path from 'path';
-import { parseRequirementsFromFile } from '../schema/index.js';
-/**
- * Detect if .requirements/ directory exists and extract projectId from files
- */
-export function detectExistingProject(cwd) {
-    const requirementsDir = path.join(cwd, '.requirements');
-    if (!fs.existsSync(requirementsDir)) {
-        return null;
-    }
-    // Look for .requirements.md files
-    const files = fs.readdirSync(requirementsDir)
-        .filter(f => f.endsWith('.requirements.md'));
-    if (files.length === 0) {
-        return null;
-    }
-    // Try to parse first file to get projectId
-    for (const file of files) {
-        try {
-            const filePath = path.join(requirementsDir, file);
-            const parsed = parseRequirementsFromFile(filePath);
-            if (parsed.metadata.projectId) {
-                return parsed.metadata.projectId;
-            }
-        }
-        catch (error) {
-            // Skip files that can't be parsed
-            continue;
-        }
-    }
-    return null;
-}
-//# sourceMappingURL=detect-existing-project.js.map