@curdx/flow 2.3.11 → 3.1.0

package/gates/edge-case-gate.md

@@ -1,194 +0,0 @@
----
-gate: edge-case-gate
-category: enterprise-mode
-severity: warning
-depends_on: []
----
-
-# Edge Case Gate — Edge Case Hunter
-
-> Derived from BMAD-METHOD's "Edge Case Hunter".
->
-> **Core**: specifically hunts for **non-happy-path** scenarios. User stories describe the happy path; the real world is full of edge cases.
-
----
-
-## Trigger Timing
-
-- After the requirements phase ends (to supplement edge conditions)
-- After the design phase (to check error-path completeness)
-- After tests are written (to check whether only the happy path is covered)
-- Explicitly requested by /curdx-flow:verify --strict
-
----
-
-## 7 Categories
-
-Systematically inspect the object under review (function / component / API):
-
-### 1. Boundary Values
-
-- 0, -1, 1
-- INT_MAX, INT_MIN
-- Empty array `[]`, single-element array `[x]`, large array `[x...10000]`
-- Empty string `""`, single character `"a"`, extra-long string
-- First element / last element / middle element
-
-### 2. Nullish
-
-- `null`
-- `undefined`
-- Empty object `{}`
-- Object with missing fields (key does not exist in JSON)
-- Whether default parameters are actually applied
-
-### 3. Concurrency
-
-- Two requests arriving simultaneously
-- Write conflicts (optimistic / pessimistic lock)
-- Read-modify-write race
-- Cache invalidation timing
-- Distributed locks
-
-### 4. Error Recovery
-
-- Network outage → retry strategy?
-- DB unavailable → circuit breaker?
-- Disk full → degrade?
-- Permission revoked → graceful exit?
-- Dependency service 500 → fallback?
-
-### 5. Security
-
-- SQL/Command/XSS injection
-- Unauthorized access (use A's token to access B's resource)
-- Sensitive data leakage (logs / error messages / response)
-- Rate limiting bypass
-- CSRF / session fixation
-- Timing attack
-
-### 6. Internationalization (I18n)
-
-- Unicode (emoji, CJK, combining characters)
-- RTL (Arabic)
-- Time zones (UTC vs local, DST jumps)
-- Number formats (decimal point vs comma)
-- Sorting (locale-aware collation)
-
-### 7. Performance
-
-- N+1 queries
-- Slow queries (missing indexes)
-- Large responses (M/G scale)
-- Memory leaks (event listeners, closures)
-- Deadlocks / long-running transactions
-
----
-
-## Required Question Checklist
-
-For each category, the agent must answer (via sequential-thinking):
-
-```
-Q1. What inputs/scenarios will this feature encounter for [category]?
-Q2. If the input is [extreme value], what will the current implementation do?
-Q3. Is there a test covering this scenario?
-Q4. If no test, what test should be added to cover it?
-```
-
----
-
-## Execution Flow
-
-```
-Input: object under review (function / component / API) + requirements + tests
-  ↓
-For each category (1-7):
-  1. Use sequential-thinking to list every plausible edge scenario for this category — stop when you've covered the real risk surface, don't pad to a quota, don't fabricate scenarios that won't occur in production
-  2. Check whether each scenario has corresponding coverage in tests
-  3. Add uncovered ones to the "gap list"
-  ↓
-Output: edge-cases.md
-```
-
----
-
-## Output Format
-
-```markdown
-## Edge Case Hunt Report
-
-Object under review: src/auth/login.ts + login.test.ts
-
-## Covered (✓)
-
-- Valid email + password → 200 + JWT
-- Invalid email format → 400
-- Non-existent user → 401
-- Wrong password → 401
-
-## Gap List (✗)
-
-### 1. Boundary Values
-- ✗ Extra-long email (>255) may cause DB errors
-  - Recommendation: test("rejects email >255 chars", ...)
-- ✗ Password containing NUL character (bcrypt has historical issue)
-  - Recommendation: test("handles NUL in password safely", ...)
-
-### 2. Nullish
-- ✗ email is empty string vs undefined
-  - Currently: both return 400 (via schema validation), but no test
-  - Recommendation: explicit test for both cases
-
-### 3. Concurrency
-- ✗ Same user with 2 concurrent logins
-  - Risk: token generation uniqueness?
-  - Recommendation: test("handles concurrent logins", async () => Promise.all([...]))
-
-### 4. Error Recovery
-- ✗ bcrypt.compare() timeout
-  - Currently: no timeout, will wait indefinitely
-  - Recommendation: add Promise.race + timeout test
-
-### 5. Security
-- ⚠ Error message leak (user enumeration)
-  - Already reported in adversarial review
-- ✗ Timing attack: response time difference between email existing vs not
-  - Recommendation: run bcrypt.compare() in both cases, test response time difference < 10ms
-
-### 6. Internationalization
-- ✗ Unicode email (RFC 6531)
-  - Currently: regex may reject legitimate Unicode emails
-  - Recommendation: test("accepts unicode email like ñ@example.com")
-
-### 7. Performance
-- ⚠ bcrypt cost 12 response time (~100ms) not tested
-  - Recommendation: benchmark test, expect < 200ms P99
-
-## Summary
-
-Covered: 4 scenarios
-Gaps: 9 scenarios
-Priority ranking: 1 (concurrency) > 4 (timeout) > 7 (timing attack) > others
-
-Fix recommendations:
-- High priority: add 4 tests (concurrency, timeout, timing attack, unicode email)
-- Medium priority: add edge-case-tests.test.ts to unify edge-case test management
-```
-
----
-
-## Difference from Adversarial Review
-
-| Dimension | adversarial | edge-case |
-|------|-------------|-----------|
-| Goal | find **any** issue | find **edge-case** issues |
-| Scope | all dimensions (architecture/implementation/...) | inputs / scenarios |
-| Style | "attacker perspective" | "extreme case search" |
-| Output | issue list + fix recommendations | gap list + test recommendations |
-
-The two are complementary. Enterprise mode recommends enabling both.
-
----
-
-_Source: BMAD-METHOD's edge-case-hunter._

package/gates/karpathy-gate.md

@@ -1,130 +0,0 @@
----
-gate: karpathy-gate
-category: always-on
-severity: blocking
-depends_on: []
----
-
-# Karpathy Gate — Thinking Baseline Check
-
-> **Always enabled**. This is the code-level enforcement of L1. Violations block immediately.
-
-This gate maps to Karpathy's 4 principles. All flow-executor and flow-reviewer agents must enforce it.
-
----
-
-## Trigger Timing
-
-- Before code is written (pre-check)
-- Before commit (re-check)
-- When `/curdx-flow:review` runs (full review)
-
----
-
-## 4 Checks
-
-### G1. Think Before Coding
-
-**Violation patterns**:
-- ✗ Code embodies unstated assumptions (e.g. default encoding, default pagination count, default permission scope)
-- ✗ User goal has multiple interpretations but the agent picked one without saying so
-- ✗ Business-relevant changes (data export, permission modification) were not confirmed with the user
-
-**Check method**:
-1. Read commit message + change scope
-2. Look in `.progress.md` for "assumption:" entries
-3. If a key assumption is not explicit, mark as violation
-
-**Auto-fix**: impossible. Report to user.
-
----
-
-### G2. Simplicity First
-
-**Violation patterns**:
-- ✗ Introduces an abstraction with only one usage point (Strategy / Factory / Observer used in one place)
-- ✗ Code goes beyond task requirements (user asked for `A`, implemented `A` + `B` + `C`)
-- ✗ Over-defensive (error handling for cases that obviously won't happen)
-- ✗ Premature parameterization (hooks left "in case we need it later")
-- ✗ Tests changed to "always pass" to accommodate implementation
-
-**Check method**:
-1. Cross-reference with the FR list in requirements.md
-2. Check whether the commit's diff scope exceeds the FR description
-3. Scan new classes / interfaces / factories; only reasonable if used in > 1 place
-
-**Auto-fix**:
-- Dispatch flow-adversary agent to review, flag redundant code
-- Auto-deletion not allowed (may have reasons); list items and let the user decide
-
----
-
-### G3. Surgical Changes
-
-**Violation patterns**:
-- ✗ Task only modifies `auth/login.ts`, but the commit contains changes in `utils/`
-- ✗ Task is to add a feature, but the commit contains "incidental" refactoring
-- ✗ Changed comments, quotes, or indentation unrelated to the task
-- ✗ Deleted pre-existing (not self-caused) "dead code"
-
-**Check method**:
-1. Read the Files field in tasks.md
-2. Compare to the commit's changed files
-3. If there is a difference (commit changed files not in Files), mark as violation
-
-**Auto-fix**:
-- Dispatch flow-executor to extract the "incidental changes" into a separate commit
-- Or roll back and redo
-
----
-
-### G4. Goal-Driven Execution
-
-**Violation patterns**:
-- ✗ Commit message contains "should", "probably", "seems", "fixed" without verification evidence
-- ✗ The `Verify` field is skipped (claiming complete without running)
-- ✗ Tests were deleted instead of fixed (turning green into gray)
-- ✗ Claims "done" but AC-X.Y still cannot be verified via curl
-
-**Check method**:
-1. Grep commit messages for forbidden words
-2. Check .progress.md for Verify output records
-3. For each AC, confirm that an automated verification path can be found
-
-**Auto-fix**:
-- Trigger flow-verifier to run reverse verification
-- If AC is not met, send back for rework (dispatch flow-executor to fix)
-
----
-
-## Violation Levels
-
-| Violation | Level | Block? |
-|------|------|-------|
-| G1 (unstated assumption) | Medium | warning, require user confirmation |
-| G2 (over-engineering) | Medium | warning + suggest simplification |
-| G3 (surgical failure) | High | **block**, must split the commit |
-| G4 (no evidence) | High | **block**, must run verification |
-
----
-
-## Output Format
-
-```markdown
-## Karpathy Gate Check Result
-
-[G1] Think Before Coding: ✓ pass (3 explicit assumption records)
-[G2] Simplicity First:    ⚠ warning — src/auth/login-strategy.ts has a single-use Strategy pattern
-[G3] Surgical Changes:    ✗ violated — commit abc123 contains accidental changes in utils/
-[G4] Goal-Driven:         ✓ pass (all ACs have verification records)
-
-Blockers: 1
-Warnings: 1
-
-Fix recommendations:
-  G3: git reset HEAD~1, split commit abc123 into 2 atomic commits
-```
-
----
-
-_Applied to: all agent preamble.md has this built in; this file contains the detailed rules for concrete checks._

package/gates/security-gate.md

@@ -1,218 +0,0 @@
----
-gate: security-gate
-category: enterprise-mode
-severity: blocking
-depends_on: []
----
-
-# Security Gate — Security Baseline Enforcement
-
-> Enabled by default in Enterprise mode. Violating "high-risk" items blocks release.
-
----
-
-## Trigger Timing
-
-- When the `security-audit` skill runs
-- Before human PR/release handoff, after `/curdx-flow:verify` and `/curdx-flow:review`
-- When committing specs involving auth / payments / PII
-
----
-
-## Core Red Lines (high-risk, blocking)
-
-### SR-01: Hardcoded Credentials
-
-Scan:
-```bash
-grep -rnE "(api[_-]?key|secret|password|token)[[:space:]]*[:=][[:space:]]*['\"][^'\"]{12,}" src/
-```
-
-Hit → block release + force rotate credential.
-
-### SR-02: SQL/Command Injection Points
-
-```bash
-# String-concatenated SQL
-grep -rn "db.query.*\${.*req\." src/
-grep -rn "execute.*\${.*user" src/
-
-# Command injection
-grep -rn "exec.*\${\|spawn.*\${" src/
-```
-
-Hit → block, must switch to parameterized queries or shell escape.
-
-### SR-03: XSS Injection Points
-
-```bash
-grep -rn "innerHTML\|dangerouslySetInnerHTML" src/
-```
-
-Hit → must review data source. If it comes from user input without sanitization → block.
-
-### SR-04: Sensitive Data in Logs
-
-```bash
-grep -rnE "(console|logger)\.(log|info|warn|error).*(password|token|secret|creditCard|ssn)" src/
-```
-
-Hit → block, switch to a redact wrapper.
-
-### SR-05: Secret Management
-
-- JWT secret / DB password must be env variables
-- Validate at startup (fail fast)
-- Must not fall back to default values
-
----
-
-## Warning Items (non-blocking, must fix)
-
-### SW-01: Error Message Leaks Existence
-
-```
-"User not found" vs "Wrong password"
-```
-
-Different messages = can be enumerated. Recommend unifying to "Invalid credentials".
-
-### SW-02: Timing Attack
-
-Response-time differences leak information. bcrypt should run even for unknown users (using a fake hash).
-
-### SW-03: CORS Too Permissive
-
-`Access-Control-Allow-Origin: *` must be fixed before release.
-
-### SW-04: Rate Limiting Missing
-
-Login, registration, and password-reset paths without rate limit → can be brute-forced.
-
-### SW-05: Dependency CVE
-
-`npm audit` reports high/critical → must upgrade or exempt.
-
----
-
-## Mandatory Items (Enterprise default requirements)
-
-### SM-01: All APIs Have Authorization
-
-Not "public" by default. New endpoints default to `requireAuth`.
-
-### SM-02: User Data Isolation
-
-`WHERE user_id = ?` must use the current session's user_id; cannot trust the frontend parameter.
-
-### SM-03: HTTPS Enforced
-
-Production environment only accepts HTTPS. HTTP requests → 301 to HTTPS.
-
-### SM-04: Cookie Security Flags
-
-- HttpOnly (prevent XSS reads)
-- Secure (HTTPS only)
-- SameSite=Strict/Lax (prevent CSRF)
-
-### SM-05: Password Storage
-
-- Must be bcrypt/argon2 (not md5/sha)
-- cost factor ≥ 12
-
----
-
-## Checking Methods
-
-### Automated Scan
-
-```bash
-# Run all scans
-bash scripts/security-scan.sh  # provided by project (if available)
-
-# Or use flow-security-auditor agent via the `security-audit` skill
-# (or say "audit for security issues")
-```
-
-### Dependency CVE
-
-```bash
-npm audit --audit-level=high
-# or
-pnpm audit
-```
-
-### Manual Review (design layer)
-
-- Check if AD-NN in design.md has security relevance
-- Check NFR-S in requirements.md
-- Threat modeling (STRIDE)
-
----
-
-## Violation Handling
-
-### Blocking Items
-
-- If SR-01 ~ SR-05 are found → block immediately; do not hand off for PR/release
-- Must fix or explicitly exempt (record in STATE.md as tech debt + commitment to fix before release)
-
-### Warning Items
-
-- If SW-01 ~ SW-05 are found → warning, non-blocking
-- But record in `security-debt.md`
-- Re-check in the next audit
-
-### Mandatory Items
-
-- Missing SM-01 ~ SM-05 → warning (new features), blocking (production paths)
-
----
-
-## Exemption Path
-
-If you truly need to skip a security check:
-
-1. Record in `.flow/STATE.md`:
-```markdown
-## Security Exemptions
-- D-SEC-01 | 2026-04-19 | temporarily hardcoding JWT_SECRET in dev environment
-  - Exemption scope: dev environment only
-  - Risk owner: wdx
-  - Fix commitment: migrate to env before 2026-04-26
-```
-
-2. Explicitly mention in PR description
-
-3. Next audit must re-check whether it has been fixed
-
----
-
-## Output Format
-
-```markdown
-## Security Gate Report
-
-Scan: commits abc..xyz + npm audit
-Time: YYYY-MM-DD
-
-### Blockers (SR): 1
-- [SR-04] src/auth/login.ts:60 — logger records password field
-
-### Warnings (SW): 2
-- [SW-01] Inconsistent login error messages → enumerable
-- [SW-05] axios 1.5.0 has CVE → `npm install axios@^1.6.0`
-
-### Mandatory (SM): all satisfied
-
-Verdict: BLOCKED (1 SR)
-
-Fix list:
-1. SR-04: wrap logger with redactPassword() (blocking, required)
-2. SW-01: unify error messages (recommended)
-3. SW-05: upgrade axios (recommended)
-```
-
----
-
-_source: OWASP Top 10 + STRIDE + accumulated project experience._

package/gates/tdd-gate.md

@@ -1,182 +0,0 @@
----
-gate: tdd-gate
-category: standard-mode
-severity: blocking
-depends_on: []
----
-
-# TDD Gate — Red/Green/Yellow Cycle Enforcement
-
-> **Iron rule**: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.
-
----
-
-## Trigger Timing
-
-- All tasks in Phase 3 (Testing)
-- Production code changes outside the POC phase
-- Tasks explicitly marked `[RED]` / `[GREEN]` / `[YELLOW]`
-
----
-
-## Applicability
-
-✓ **TDD enforced**:
-- Adding production logic (business rules, algorithms, data transformations)
-- Modifying existing logic (even one line)
-- Bug fixes (must have a failing test that reproduces the bug)
-
-⊘ **Exemptible from TDD**:
-- POC phase (Phase 1 of POC-First)
-- Pure configuration changes (`.json` / `.yaml`)
-- Documentation (`.md`)
-- Formatting (does not change behavior)
-- Dependency upgrades (only modify package.json, unless major version)
-
----
-
-## RED → GREEN → YELLOW Enforcement Rules
-
-### RED (failing test)
-
-**Rules**:
-- The test **must actually fail** before continuing
-- "I wrote the test but haven't run it" is not allowed
-- "The test passes as soon as written" is not allowed (this means it doesn't actually test anything)
-
-**Check**:
-```bash
-# Expect a non-zero exit code
-npm test -- <test-file>
-echo "Exit: $?"  # must be non-0
-```
-
-**Commit format**: `test(scope): red - <what the test verifies>`
-
-**Violations**:
-- ✗ Wrote the test but didn't run it (no fresh evidence)
-- ✗ Test passes the first time it runs
-- ✗ Started writing implementation before writing the test
-
----
-
-### GREEN (minimal implementation)
-
-**Rules**:
-- Write the **least code** needed to pass the RED test
-- Don't think about elegance, abstraction, or extensibility
-- Focus on making the test pass
-
-**Check**:
-```bash
-npm test -- <test-file>
-echo "Exit: $?"  # must be 0
-```
-
-**Commit format**: `feat(scope): green - <what was implemented>`
-
-**Violations**:
-- ✗ Added functionality beyond what makes the test pass
-- ✗ Did abstraction and implementation at the same time
-- ✗ Other tests also pass but those tests were written outside this cycle
-
----
-
-### YELLOW (refactor)
-
-**Rules**:
-- Clean up GREEN-phase code; **tests must still pass**
-- No new behavior
-- No new tests
-
-**Check**:
-```bash
-# Tests run before and after, both exit 0
-npm test -- <test-file>
-```
-
-**Commit format**: `refactor(scope): yellow - <what was cleaned up>`
-
-**Violations**:
-- ✗ Test fails during YELLOW (means behavior changed)
-- ✗ YELLOW added new functionality
-- ✗ Deleted hard-to-change code (violates surgical changes)
-
----
-
-## Reasons to Refuse (agent must reject these excuses)
-
-| Excuse | Agent Response |
-|------|---------|
-| "This is too simple to test" | Simple code can break too. Write a minimal test. |
-| "Write code first, test later" | After-the-fact tests miss edge cases. Go back to RED. |
-| "I already tested manually" | No automation record means no regression. Write an automated test. |
-| "Existing code has no tests, I won't either" | Coverage only goes up or down. New code must at least cover the new logic. |
-| "Time pressure" | fast mode or /curdx-flow:fast can exempt. Otherwise go through full TDD. |
-
----
-
-## Exemption Path (explicit)
-
-If you really need to skip TDD, you must:
-
-1. Mark in `.flow/CONTEXT.md` or `.state.json`
-2. Provide an exemption reason
-3. Add a "tech debt" entry to `.flow/STATE.md`, with a commitment to fix later
-
-```markdown
-# STATE.md
-## Tech Debt
-- D-TDD-01 | 2026-04-19 | auth-system's refresh-token module skipped TDD
-  - Reason: urgent hotfix, CI takes 1 hour to complete
-  - Commitment: add tests next sprint, deadline 2026-04-26
-```
-
-No exemption record → TDD enforced.
-
----
-
-## Checking Methods
-
-### flow-reviewer's Stage 2 invokes this gate
-
-Scan git log; for each `feat(xxx):` commit:
-1. Find the preceding `test(xxx): red -` commit
-2. If none, that feat violates TDD
-3. Exception: commit message contains `[skip-tdd]` and a corresponding record exists in STATE.md
-
-### Coverage Check (auxiliary)
-
-```bash
-npm test -- --coverage
-# Line coverage for new code must be ≥ 80%
-# Uncovered lines must be explained in STATE.md
-```
-
----
-
-## Output Format
-
-```markdown
-## TDD Gate Check Result
-
-Scan range: commits abc123..def456
-Feat commits: 5
-Test commits (red): 4
-
-[T1] commit abc123 "feat(auth): add login endpoint"
-     Preceding RED: ✓ commit 789xyz "test(auth): red - login endpoint tests"
-     Verdict: compliant
-
-[T2] commit def456 "feat(auth): add password hashing"
-     Preceding RED: ✗ no preceding test commit
-     Verdict: violation
-     Exception check: no [skip-tdd] marker, no STATE.md exemption
-     Block: yes
-
-Violations: 1
-Compliant: 4
-
-Fix recommendations:
-  T2: add test test(auth): red - password hashing, verify it fails, then redo GREEN
-```