@dzhechkov/p-replicator 1.2.0 → 1.5.2

package/templates/.claude/skills/cc-toolkit-generator-enhanced/references/security-patterns-library.md

@@ -0,0 +1,196 @@
+# Security Patterns Library
+
+Reference library of security patterns extracted from real-project harvest insights.
+Used by toolkit generator modules (03, 04, 05) when generating security.md rules,
+secrets-management.md, security-patterns/ skill, and code-reviewer agent.
+
+## Critical Patterns (Must-Have for Multi-Tenant Systems)
+
+### S-01: RLS Bypass Prevention — Pool vs Client Query
+
+**Problem:** Tenant middleware sets `app.tenant_id` via `SET LOCAL` on a dedicated
+PoolClient (`req.dbClient`), but repositories use `pool.query()` (shared pool).
+The query runs on a different connection without tenant context — RLS is bypassed.
+
+**Pattern:**
+```
+RULE: NEVER use pool.query() in multi-tenant systems with RLS.
+ALWAYS pass the tenant-scoped dbClient from middleware through service layer to repository.
+Every database query MUST use the same connection where SET LOCAL was executed.
+```
+
+**Detection:** Search for `pool.query()` in repository files when RLS is enabled.
+
+**Generated Rule (security.md):**
+```markdown
+- Multi-tenant RLS: All database queries MUST use tenant-scoped connection (req.dbClient),
+  NEVER the shared pool. Verify by grepping for pool.query() — any hit is a security bug.
+```
+
+---
+
+### S-02: SQL Injection via SET LOCAL
+
+**Problem:** String interpolation in `SET LOCAL app.tenant_id = '${tenantId}'`
+is an SQL injection vector even with UUID validation.
+
+**Pattern:**
+```
+RULE: NEVER use string interpolation for SET LOCAL.
+ALWAYS use parameterized set_config():
+  SELECT set_config('app.tenant_id', $1, true)
+```
+
+**Detection:** Search for `SET LOCAL` with template literals or string concatenation.
+
+**Generated Rule (security.md):**
+```markdown
+- Parameterized config: Use `set_config('key', $1, true)` instead of
+  `SET LOCAL key = '${value}'`. Applies to all session-level config.
+```
+
+---
+
+### S-03: Fail-Fast Secret Validation at Startup
+
+**Problem:** Service A falls back to `'dev-secret-change-me'` when JWT_SECRET is
+missing, while Service B uses `process.env.JWT_SECRET!`. Creates split-brain:
+signing uses weak fallback, verification uses undefined.
+
+**Pattern:**
+```
+RULE: NEVER provide fallback values for security-critical secrets.
+ALWAYS validate at startup and exit with process.exit(1) if missing or too short.
+
+Required checks:
+- JWT_SECRET: exists AND length >= 32 characters
+- DATABASE_URL: exists AND not localhost in production
+- API keys: exist AND not placeholder values
+```
+
+**Generated Rule (security.md):**
+```markdown
+- Startup secret guard: All security secrets (JWT_SECRET, API keys, encryption keys)
+  MUST be validated at application startup. Missing or weak secrets MUST cause
+  immediate process.exit(1). NEVER use fallback defaults for secrets.
+```
+
+---
+
+### S-04: Cross-Tenant Entity Ownership
+
+**Problem:** API endpoint accepts an entity ID (e.g., operatorId) without
+verifying that the entity belongs to the requesting tenant. RLS on the target
+table may not cover this cross-reference.
+
+**Pattern:**
+```
+RULE: Before using any entity ID from request params in a cross-table operation,
+verify the entity belongs to the same tenant:
+  1. Load entity by ID
+  2. Check entity.tenantId === request.tenantId
+  3. Return 403 if mismatch
+```
+
+**Generated Rule (security.md):**
+```markdown
+- Cross-tenant ownership: When an API accepts entity IDs (operatorId, userId, etc.),
+  ALWAYS verify entity.tenantId matches the requesting tenant before any operation.
+  RLS alone may not protect cross-table references.
+```
+
+---
+
+### S-05: Webhook Signature Verification
+
+**Problem:** Webhook endpoints accept any POST without HMAC/signature verification.
+Attackers can inject fake messages if webhook URLs are discovered.
+
+**Pattern:**
+```
+RULE: Every webhook endpoint MUST verify the request signature:
+- Telegram: verify X-Telegram-Bot-Api-Secret-Token header
+- Stripe: verify Stripe-Signature header with webhook secret
+- GitHub: verify X-Hub-Signature-256 header
+- Generic: verify HMAC-SHA256 of body with shared secret
+```
+
+**Generated Rule (security.md):**
+```markdown
+- Webhook HMAC: Every webhook endpoint MUST verify request signature/HMAC.
+  NEVER accept unsigned webhook requests. Log and reject unsigned payloads.
+```
+
+---
+
+## High-Priority Patterns
+
+### S-06: Singleton Service Instances
+
+**Problem:** Creating service instances per-request (e.g., `Service.fromEnv()` in
+route handler) means stateful components like circuit breakers never accumulate
+failure state and never trigger protection.
+
+**Pattern:**
+```
+RULE: Services with stateful protection mechanisms (circuit breakers, rate limiters,
+connection pools) MUST be created as singletons at application startup.
+NEVER create per-request instances of stateful services.
+```
+
+**Impact on Generated Code:**
+- In architect.md agent: include singleton pattern for infrastructure services
+- In coding-style.md rule: "stateful services are singletons, injected at startup"
+
+---
+
+### S-07: Environment-Specific Security Posture
+
+**Pattern:**
+```
+RULE: Security posture MUST match environment:
+- Development: relaxed CORS, verbose errors, debug logging
+- Staging: production-like security, sanitized test data
+- Production: strict CORS, generic errors, structured logging only
+
+NEVER: same security config across all environments
+NEVER: expose stack traces in production error responses
+```
+
+---
+
+## Integration Patterns for Generated Toolkit
+
+### How Patterns Map to Generated Files
+
+| Pattern | security.md | secrets-management.md | code-reviewer.md | architect.md |
+|---------|------------|----------------------|-------------------|--------------|
+| S-01 RLS Bypass | Rule | — | Check | Architecture note |
+| S-02 SQL Injection | Rule | — | Check | — |
+| S-03 Secret Validation | Rule | Primary content | Check | Startup validation |
+| S-04 Cross-Tenant | Rule | — | Check | — |
+| S-05 Webhook HMAC | Rule | Secret storage | Check | — |
+| S-06 Singleton | — | — | Check | Architecture pattern |
+| S-07 Env Security | Rule | Env-specific rules | — | Environment guide |
+
+### Usage in Module 03 (Generate P0)
+
+When generating `security.md` rule (Item 2), include applicable patterns:
+- IF multi-tenant detected: S-01, S-02, S-04
+- IF has_external_apis: S-03, S-05
+- IF has_database: S-01, S-02
+- ALWAYS: S-03, S-07
+
+### Usage in Module 04 (Generate P1)
+
+When generating `code-reviewer.md` agent (Step 2b), add security review checklist
+from applicable patterns to the agent's review criteria.
+
+When generating `architect.md` agent (Step 2c), include S-06 singleton pattern
+and S-07 environment posture in architecture guidelines.
+
+### Usage in brutal-honesty-review
+
+When reviewing code in Linus Mode, check for violations of all S-01 through S-07
+patterns as CRITICAL findings. Security violations should always trigger
+Level 3 (Brutal) calibration.

package/templates/.claude/skills/cc-toolkit-generator-enhanced/references/templates/automation-commands.md

@@ -27,6 +27,13 @@ description: Intelligent feature implementation pipeline. Analyzes complexity an
 One-command feature implementation that automatically selects the right pipeline
 based on feature complexity, then executes it without manual confirmations.
 
+> **PROCESS COMPLIANCE — BLOCKING RULES:**
+> - MUST use /plan, /feature, or /feature-ent commands — NEVER launch raw Agent tools directly
+> - MUST follow the skill chain: /next -> /go -> /plan|/feature|/feature-ent
+> - FORBIDDEN: Bypassing the skill chain by spawning parallel agents without commands
+> - FORBIDDEN: Batching multiple features into a single commit wave
+> - CRITICAL: Each feature MUST get its own plan, validation, and commit sequence
+
 ## Step 1: Determine Target Feature
 
 IF $ARGUMENTS is provided:
@@ -186,6 +193,14 @@ description: Autonomous project build loop. Bootstraps project and implements fe
 End-to-end autonomous project build: bootstrap → implement features in loop → done.
 Combines `/start`, `/next`, and `/go` into a single continuous pipeline.
 
+> **AUTONOMOUS EXECUTION — BLOCKING RULES:**
+> - MUST execute features ONE AT A TIME through the full /go pipeline
+> - MUST create 1 plan per feature, 1 validation per feature, 1 commit per feature
+> - NEVER batch features into parallel waves without individual plans
+> - NEVER skip the /next -> /go pipeline by launching raw implementation agents
+> - CRITICAL: If a feature fails 3 times, skip it and log — NEVER retry indefinitely
+> - MUST push state after each feature completion (independent commits)
+
 ## Step 0: Parse Scope
 
 ```

package/templates/.claude/skills/cc-toolkit-generator-enhanced/references/templates/ddd-agents.md

@@ -194,6 +194,44 @@ Proposed
 [What was rejected and why?]
 ```
 
+## Architecture Patterns
+
+### Singleton Services (Infrastructure)
+
+Services with stateful protection mechanisms MUST be created as singletons at
+application startup. NEVER create per-request instances of stateful services.
+
+**Why:** Per-request instances of circuit breakers, rate limiters, or connection pools
+bypass protection — the breaker never accumulates failure state and never opens.
+
+**Pattern:**
+```
+CORRECT:
+  const mcpService = MCPService.fromEnv()  // at startup, once
+  app.use((req, res, next) => {
+    req.mcpService = mcpService  // inject singleton
+    next()
+  })
+
+WRONG:
+  app.get('/api', (req, res) => {
+    const mcpService = MCPService.fromEnv()  // new instance per request!
+    // circuit breaker resets every request — never trips
+  })
+```
+
+**Applies to:** circuit breakers, rate limiters, connection pools, MCP clients,
+external service adapters, cache managers.
+
+### Security-by-Environment
+
+Security posture MUST match environment:
+- **Development:** relaxed CORS, verbose errors, debug logging
+- **Staging:** production-like security, sanitized test data
+- **Production:** strict CORS, generic errors, structured logging only
+
+NEVER use the same security configuration across all environments.
+
 ## Fitness Functions
 
 {{ARCHITECTURE_FITNESS_FUNCTIONS}}
@@ -206,6 +244,7 @@ For architecture questions:
 - Explain bounded context impact
 - List trade-offs explicitly
 - Suggest ADR if recording needed
+- Check singleton pattern for infrastructure services
 ```
 
 ---

package/templates/.claude/skills/cc-toolkit-generator-enhanced/references/templates/feature-lifecycle.md

@@ -65,6 +65,14 @@ description: Full feature lifecycle — from idea to reviewed implementation.
 Four-phase feature development lifecycle with quality gates between each phase.
 All documentation goes to `docs/features/<feature-name>/sparc/`.
 
+> **SKILL CHAIN — BLOCKING RULES:**
+> - MUST execute Phase 0 (pre-flight check) before ANY generation
+> - MUST use sparc-prd-mini skill for planning — NEVER generate SPARC docs from memory
+> - MUST use requirements-validator for validation — NEVER skip validation phase
+> - MUST use brutal-honesty-review for review — NEVER self-review
+> - FORBIDDEN: Skipping any phase without explicit user permission
+> - CRITICAL: Each phase MUST complete and commit before the next phase starts
+
 ## Phase 0: PRE-FLIGHT CHECK
 
 Before starting, verify all required skills exist:

package/templates/.claude/skills/requirements-validator/SKILL.md

@@ -103,13 +103,37 @@ Always flag these terms and suggest specific replacements:
 - Add AC: "Given X, when Y, then Z within 200ms"
 ```
 
+### Security Acceptance Criteria (10% bonus weight)
+
+When requirements involve authentication, data storage, external APIs, or multi-tenancy,
+apply additional security validation:
+
+| Criterion | Check | Red Flags |
+|-----------|-------|-----------|
+| Input Validation | All user inputs sanitized? | No validation mentioned, "trust client" |
+| Authentication | Auth mechanism specified? | "users can access", no auth context |
+| Authorization | Access control defined? | No role/permission model |
+| Data Protection | Sensitive data handling specified? | PII without encryption rules |
+| Multi-Tenant Isolation | Tenant boundary enforced? | Shared queries, no tenant context |
+| Secret Management | Secrets externalized? | Hardcoded keys, fallback defaults |
+| Webhook Security | Signature verification? | "Accept POST", no HMAC |
+
+**Scoring Bonus:** +5 points if security criteria present and specific, +0 if not applicable,
+-10 if security-relevant requirement lacks any security criteria (BLOCKED if score drops below 50).
+
+**Security BDD Scenarios:** For security-relevant requirements, ALWAYS generate:
+- Auth bypass attempt scenario
+- Input injection scenario (SQL, XSS, command)
+- Cross-tenant access attempt (if multi-tenant)
+- Rate limiting / brute force scenario (if auth endpoint)
+
 ### BDD Scenario Generation
 
 For each requirement, generate scenarios covering:
 1. **Happy path** (1-2 scenarios) — Primary success flow
 2. **Error handling** (2-3 scenarios) — Validation, network, server errors
 3. **Edge cases** (1-2 scenarios) — Boundaries, concurrent access
-4. **Security** (if applicable) — Auth, injection, rate limiting
+4. **Security** (1-3 scenarios) — Auth bypass, injection, cross-tenant, rate limiting
 
 See `references/bdd-patterns.md` for Gherkin templates and examples.