rebar-mcp 2.0.0

package/ccboot-v1.2.0-enforcement-spec.md

@@ -0,0 +1,1272 @@
+# ccboot-mcp-server v1.2.0 — The Enforcement Layer
+
+## STATUS: IMPLEMENTATION SPEC — NOT A DISCUSSION DOCUMENT
+
+Every section in this document is a directive. Do not paraphrase. Do not summarize.
+Do not replace specific text with "appropriate content" or "relevant rules."
+When this spec says "the template MUST contain the following text," copy it verbatim.
+When this spec says "the hook command MUST be," use that exact command string.
+
+---
+
+## What v1.2.0 Is
+
+v1.0 built the MCP server infrastructure (15 tools, npm publish, MCP registry).
+v1.1 added output modes, dry-run, CI mode, and testing.
+v1.2 turns the product from a scaffolding tool into an enforcement system.
+
+The difference: v1.0 generates files. v1.2 generates files that **prevent Claude from shipping broken code.**
+
+After v1.2, when a developer runs `ccboot_init_project`, they get a project where:
+- Claude cannot mark a task complete without tests passing
+- Claude cannot commit code with empty catch blocks or `any` types
+- Claude cannot skip error handling
+- Claude gets blocked by hooks if it tries dangerous operations
+- Claude gets audited by a code quality scanner that catches shortcuts
+- Every generated template contains battle-tested, specific instructions — not placeholders
+
+---
+
+## IMPLEMENTATION ORDER
+
+Complete these in exact sequence. Do not skip ahead.
+
+```
+Phase A: Rewrite all CLAUDE.md templates (Section 1)
+Phase B: Rewrite all skill templates (Section 2)
+Phase C: Rewrite all agent templates (Section 3)
+Phase D: Rewrite all hook templates (Section 4)
+Phase E: Build ccboot_audit_code_quality tool (Section 5)
+Phase F: Enhance ccboot_init_project to wire everything together (Section 6)
+Phase G: Update tests for all changes (Section 7)
+Phase H: Update README and publish v1.2.0 (Section 8)
+```
+
+After each phase, run `npm run build` and `npm run test`. Fix all errors before proceeding.
+
+---
+
+# SECTION 1: CLAUDE.md TEMPLATES
+
+## 1.1 Template Location
+
+All CLAUDE.md templates live in `templates/claudemd/`. Each template is a standalone markdown file with `{{variable}}` substitution markers.
+
+## 1.2 Template Variables
+
+Every CLAUDE.md template MUST support these variables:
+
+| Variable | Type | Description |
+|---|---|---|
+| `{{project_name}}` | string | Name of the project |
+| `{{tech_stack}}` | string | Primary framework/language |
+| `{{test_command}}` | string | Command to run tests (e.g., `npm test`) |
+| `{{build_command}}` | string | Command to build (e.g., `npm run build`) |
+| `{{lint_command}}` | string | Command to lint (e.g., `npm run lint`) |
+| `{{format_command}}` | string | Command to format (e.g., `npx prettier --write`) |
+| `{{primary_language}}` | string | e.g., TypeScript, Python, Java |
+| `{{package_manager}}` | string | e.g., npm, yarn, pnpm, pip, maven |
+| `{{team_size}}` | string | e.g., "solo", "small (2-5)", "medium (6-20)", "large (20+)" |
+
+## 1.3 Mandatory Sections
+
+EVERY CLAUDE.md template, regardless of tech stack, MUST contain ALL of the following sections in this exact order. These are non-negotiable. Do not omit any section. Do not reword the rules — use the exact text provided.
+
+### Section: Project Overview
+
+```markdown
+# {{project_name}}
+
+## Project Overview
+{{project_description}}
+
+### Tech Stack
+{{tech_stack_details}}
+```
+
+This section is customized per template. The content varies by tech stack.
+
+### Section: Mandatory Practices
+
+This section is IDENTICAL across all templates. Do not modify it per tech stack. Copy verbatim.
+
+```markdown
+## Mandatory Practices — NEVER VIOLATE THESE
+
+### Completion Standards
+- NEVER mark a task as complete without running `{{test_command}}` and confirming all tests pass
+- NEVER say "I've completed the implementation" unless you have ACTUALLY run the tests and seen them pass in the terminal output
+- NEVER skip writing tests for new functionality — every new function, endpoint, or component gets at least one test
+- NEVER leave TODO, FIXME, HACK, or XXX comments in code you claim is finished
+- If tests do not exist yet for the area you are modifying, WRITE THEM FIRST before making changes (test-driven development)
+- After making changes, ALWAYS run `{{build_command}}` to verify the project compiles/builds without errors
+
+### Error Handling
+- NEVER write empty catch blocks — every catch block must either: (a) log the error with context, (b) re-throw with additional information, or (c) handle the error with specific recovery logic
+- NEVER swallow errors silently — if you catch an exception, the catch block must DO something meaningful
+- ALWAYS validate user input at system boundaries (API endpoints, form handlers, CLI arguments, file readers)
+- ALWAYS handle the unhappy path — for every operation that can fail, write code that handles the failure case
+- NEVER use generic error messages like "Something went wrong" — error messages must describe what failed, why, and what the user/developer can do about it
+
+### Type Safety
+- NEVER use `any` type — use `unknown`, proper generic types, or specific interfaces instead
+- ALWAYS define explicit return types on functions (no implicit return type inference for exported functions)
+- ALWAYS define interfaces or types for data structures that cross module boundaries (API responses, database records, configuration objects)
+- NEVER use type assertions (`as SomeType`) unless you include a runtime check immediately before the assertion
+
+### Code Completeness
+- NEVER implement a partial solution — if a function needs error handling, input validation, logging, and the core logic, implement ALL of them, not just the core logic
+- NEVER create a file and say "I'll add the implementation later" — if you create a file, it must be complete and functional
+- NEVER stub out functions with `throw new Error("Not implemented")` in code you claim is finished
+- ALWAYS implement edge cases — empty arrays, null values, missing fields, network timeouts, concurrent access
+- ALWAYS clean up resources — close file handles, database connections, event listeners, and timers
+
+### Security
+- NEVER hardcode secrets, API keys, passwords, or tokens in source code
+- NEVER log sensitive data (passwords, tokens, PII, credit card numbers)
+- NEVER construct SQL queries with string concatenation — use parameterized queries or an ORM
+- NEVER trust user input — sanitize and validate everything from external sources
+- ALWAYS use HTTPS for external API calls
+- NEVER disable TLS certificate verification
+```
+
+### Section: Architecture Rules
+
+This section is customized per template. See individual template specs below.
+
+### Section: File Structure
+
+This section is customized per template. Describes the project layout.
+
+### Section: Build and Test Commands
+
+```markdown
+## Build & Test Commands
+- Build: `{{build_command}}`
+- Test: `{{test_command}}`
+- Lint: `{{lint_command}}`
+- Format: `{{format_command}}`
+
+### Testing Requirements
+- Run `{{test_command}}` after EVERY code change, not just at the end
+- If any test fails, fix it BEFORE moving on to the next task
+- New features require tests BEFORE implementation (write the test, see it fail, then implement)
+- Bug fixes require a regression test that reproduces the bug BEFORE fixing it
+```
+
+### Section: Code Review Checklist
+
+This section is IDENTICAL across all templates. Copy verbatim.
+
+```markdown
+## Self-Review Checklist — Run Before Every Commit
+
+Before committing any code, verify ALL of the following:
+
+1. [ ] `{{build_command}}` passes with zero errors
+2. [ ] `{{test_command}}` passes with all tests green
+3. [ ] `{{lint_command}}` passes with zero warnings
+4. [ ] No `any` types in changed files
+5. [ ] No empty catch blocks in changed files
+6. [ ] No TODO/FIXME/HACK comments in changed files
+7. [ ] All new functions have explicit return types
+8. [ ] All new functions have at least one test
+9. [ ] All error paths are handled (not just the happy path)
+10. [ ] No hardcoded secrets or credentials
+11. [ ] No `console.log` left in production code (use proper logging)
+12. [ ] Changed files are under 400 lines (split if longer)
+```
+
+## 1.4 Tech-Stack-Specific Templates
+
+### Template: `templates/claudemd/nextjs.md`
+
+In addition to ALL mandatory sections above, this template MUST include:
+
+```markdown
+## Architecture Rules — Next.js
+
+### Routing
+- Use the App Router (app/ directory), NOT the Pages Router, unless the project explicitly uses Pages Router
+- Every route MUST have a loading.tsx and error.tsx boundary
+- API routes go in app/api/ and MUST validate request bodies with Zod or a similar schema validator
+- Dynamic routes MUST handle the case where the parameter does not match any record (return 404, not a crash)
+
+### Data Fetching
+- Use Server Components by default — only add "use client" when the component genuinely needs browser APIs or interactivity
+- NEVER fetch data in client components if it can be done in a server component
+- ALWAYS handle loading and error states — no component should render without a loading fallback and error boundary
+- Cache API responses appropriately — use `revalidate` or `cache: 'no-store'` explicitly, never rely on defaults
+
+### Styling
+- Use Tailwind CSS utility classes for styling
+- NEVER use inline `style={}` objects when Tailwind classes exist for the same purpose
+- Component files should not exceed 200 lines — extract sub-components if they do
+
+### Database
+- Use Prisma for database access (if applicable)
+- NEVER write raw SQL queries — use Prisma's query builder
+- ALWAYS use transactions for operations that modify multiple tables
+- ALWAYS handle unique constraint violations and foreign key errors explicitly
+
+### State Management
+- Use React Server Components + Server Actions for server state
+- Use React hooks (useState, useReducer) for local UI state
+- Only reach for external state libraries (Zustand, Jotai) if you genuinely need cross-component client state that React context cannot handle efficiently
+
+### Environment Variables
+- Access environment variables ONLY through a validated config module, never directly via process.env scattered throughout the code
+- ALWAYS provide fallback values or throw clear errors for missing required environment variables
+```
+
+### Template: `templates/claudemd/python-fastapi.md`
+
+In addition to ALL mandatory sections above (with these substitutions: `{{test_command}}` = `pytest`, `{{build_command}}` = `python -m py_compile`, `{{lint_command}}` = `ruff check .`, `{{format_command}}` = `ruff format .`):
+
+```markdown
+## Architecture Rules — Python / FastAPI
+
+### Type Hints
+- EVERY function MUST have type hints for all parameters and return values
+- Use `from __future__ import annotations` at the top of every file
+- Use Pydantic BaseModel for ALL request/response schemas — never use raw dicts for API data
+- NEVER use `Any` from typing — use `object`, specific unions, or generic type variables instead
+
+### API Design
+- Every endpoint MUST have a Pydantic request model (for POST/PUT/PATCH) and response model
+- Every endpoint MUST have explicit status codes: 200, 201, 400, 401, 403, 404, 422, 500
+- NEVER return raw dicts from endpoints — always return Pydantic models
+- Use dependency injection for database sessions, auth, and config — never import globals directly
+- ALWAYS include OpenAPI summary and description on every endpoint
+
+### Error Handling
+- Use FastAPI's HTTPException with specific status codes and detail messages
+- Create custom exception handlers for domain-specific errors
+- NEVER let unhandled exceptions reach the client — always have a global exception handler
+- Log all exceptions with traceback using structured logging (not print())
+
+### Database
+- Use SQLAlchemy 2.0 style with async sessions
+- ALWAYS use Alembic for migrations — never modify the database schema manually
+- ALWAYS use transactions — wrap multi-step database operations in `async with session.begin()`
+- NEVER write raw SQL strings — use SQLAlchemy's expression language or ORM
+
+### Testing
+- Use pytest with pytest-asyncio for async tests
+- Use httpx.AsyncClient for API endpoint tests (not the synchronous test client)
+- Every endpoint needs at least: one happy-path test, one validation-error test, one auth-failure test
+- Use factories (factory_boy) or fixtures for test data — never hardcode test data inline
+
+### Project Structure
+- app/main.py — FastAPI app initialization
+- app/api/ — Route handlers grouped by domain
+- app/models/ — SQLAlchemy models
+- app/schemas/ — Pydantic request/response models
+- app/services/ — Business logic (not in route handlers)
+- app/core/ — Config, security, dependencies
+- tests/ — Mirrors app/ structure
+```
+
+### Template: `templates/claudemd/spring-boot.md`
+
+In addition to ALL mandatory sections above (with: `{{test_command}}` = `./mvnw test`, `{{build_command}}` = `./mvnw compile`, `{{lint_command}}` = `./mvnw checkstyle:check`, `{{format_command}}` = `./mvnw spotless:apply`):
+
+```markdown
+## Architecture Rules — Spring Boot / Java
+
+### Layered Architecture
+- Controller → Service → Repository — NEVER skip layers
+- Controllers handle HTTP concerns ONLY (request parsing, response formatting, status codes)
+- Services contain ALL business logic — controllers MUST NOT contain business logic
+- Repositories handle data access ONLY — no business logic in repository classes
+- NEVER inject a Repository directly into a Controller — always go through a Service
+
+### Exception Handling
+- Create a global @ControllerAdvice exception handler
+- Define custom exception classes for each error category (NotFoundException, ValidationException, ConflictException)
+- NEVER catch Exception broadly — catch specific exception types
+- NEVER return stack traces to API clients — log them server-side and return safe error responses
+- Every REST endpoint MUST document possible error responses in Swagger annotations
+
+### Validation
+- Use Jakarta Bean Validation annotations (@NotNull, @Size, @Email, @Pattern) on all DTOs
+- ALWAYS use @Valid on controller method parameters
+- Create custom validators for complex business rules
+- NEVER validate by writing if-else chains in controllers — use the validation framework
+
+### Database
+- Use Spring Data JPA repositories
+- ALWAYS define entity relationships with proper cascade types and fetch strategies
+- Use @Transactional on service methods that perform multiple database operations
+- NEVER use EntityManager directly unless JPA repository methods are genuinely insufficient
+- Write database migrations with Flyway or Liquibase — never use hibernate.ddl-auto in production
+
+### Testing
+- Unit tests: Test services with mocked repositories using @MockBean or Mockito
+- Integration tests: Test controllers with @SpringBootTest and MockMvc
+- Repository tests: Use @DataJpaTest with an in-memory database
+- Every service method needs: one happy-path test, one exception test, one edge-case test
+- ALWAYS use AssertJ for assertions (not JUnit's basic assertEquals)
+
+### Security
+- Use Spring Security for authentication and authorization
+- NEVER store passwords in plain text — use BCryptPasswordEncoder
+- ALWAYS validate JWT tokens on every protected endpoint
+- Use method-level security (@PreAuthorize) for authorization checks
+```
+
+### Template: `templates/claudemd/react-spa.md`
+
+In addition to ALL mandatory sections above (with: `{{test_command}}` = `npm test` or `npx vitest`, `{{build_command}}` = `npm run build`, `{{lint_command}}` = `npx eslint .`, `{{format_command}}` = `npx prettier --write .`):
+
+```markdown
+## Architecture Rules — React SPA
+
+### Component Design
+- Components MUST be under 200 lines — extract sub-components if they grow beyond this
+- Separate container components (data fetching, state) from presentation components (rendering)
+- NEVER put API calls directly in components — use custom hooks or a data layer (React Query, SWR)
+- Every component that accepts props MUST have a TypeScript interface defining those props
+- NEVER use `React.FC` — use plain function declarations with typed props
+
+### State Management
+- Use React hooks (useState, useReducer) for component-local state
+- Use React Query or SWR for server state (API data) — NEVER store server data in Redux/Zustand
+- Only use a state management library (Zustand, Jotai) for genuinely global client state
+- NEVER put form state in global state — use react-hook-form or controlled local state
+- NEVER create a "god context" that holds all application state — split contexts by domain
+
+### Error Handling
+- EVERY async operation needs try/catch with user-visible error feedback
+- Use Error Boundaries for component tree crash protection
+- NEVER show raw error objects to users — format them into human-readable messages
+- ALWAYS show loading states during async operations — no blank screens or frozen UIs
+
+### Routing
+- Use React Router v6+ with typed route parameters
+- Every route MUST have a fallback/404 handler
+- Protected routes MUST redirect to login, not show a blank page
+- ALWAYS handle the "back button" — navigating back should not break state
+
+### API Integration
+- Create a centralized API client (e.g., an axios instance with interceptors)
+- NEVER hardcode API URLs — use environment variables
+- ALWAYS handle: loading state, success, error, and empty-data states for every API call
+- ALWAYS handle token refresh and 401 responses in the API client interceptor
+
+### Testing
+- Use React Testing Library (not Enzyme)
+- Test behavior, not implementation — query by role, label, or text, NEVER by CSS class or test ID
+- Every component with conditional rendering needs tests for each condition
+- Every custom hook needs tests using renderHook()
+- Mock API calls with MSW (Mock Service Worker), not by mocking fetch/axios directly
+
+### Accessibility
+- EVERY interactive element must be keyboard accessible
+- EVERY image must have an alt attribute
+- Use semantic HTML (button, nav, main, aside) — not div for everything
+- Form inputs MUST have associated labels
+```
+
+### Template: `templates/claudemd/monorepo.md`
+
+In addition to ALL mandatory sections, add:
+
+```markdown
+## Monorepo Architecture
+
+### Package Boundaries
+- Each package MUST have its own CLAUDE.md with package-specific rules
+- Packages MUST NOT import from other packages using relative paths — use the package name
+- Shared types go in a dedicated `packages/shared` or `packages/types` package
+- Every package MUST have its own test suite that can run independently
+
+### Dependency Management
+- Use workspace protocol for internal dependencies (e.g., `"workspace:*"`)
+- NEVER duplicate dependencies across packages — hoist shared deps to the root
+- Run `{{package_manager}} install` from the workspace root, never from individual packages
+
+### CI/CD
+- Changes to a package MUST only trigger CI for that package and its dependents
+- The root build command MUST build packages in dependency order
+- NEVER deploy a package without running its tests AND the tests of packages that depend on it
+
+### Subdirectory CLAUDE.md files
+- Each package directory (e.g., packages/api, packages/web, packages/shared) should have its own CLAUDE.md
+- Subdirectory CLAUDE.md files inherit all Mandatory Practices from the root but add package-specific rules
+- When working in a subdirectory, Claude loads BOTH the root and subdirectory CLAUDE.md
+```
+
+---
+
+# SECTION 2: SKILL TEMPLATES
+
+Each skill template lives in `templates/skills/`. Each file is a complete SKILL.md with YAML frontmatter and detailed instructions. These are NOT stubs. Every instruction must be specific and actionable.
+
+## 2.1 Code Review Skill
+
+File: `templates/skills/code-review.md`
+
+```markdown
+---
+name: code-review
+description: Performs comprehensive code review on changed files, checking for bugs, security issues, missing tests, and code quality problems. Auto-invokes when reviewing PRs or when asked to review code.
+---
+
+## Code Review Process
+
+When performing a code review, follow this EXACT process in order:
+
+### Step 1: Identify Changed Files
+Run `git diff --name-only HEAD~1` (or the appropriate diff command for the context) to identify all changed files. List them before proceeding.
+
+### Step 2: For EACH Changed File, Check ALL of the Following
+
+**Correctness**
+- Does the logic actually do what it claims to do? Trace through the code mentally with sample inputs.
+- Are there off-by-one errors in loops or array indexing?
+- Are there race conditions in concurrent code?
+- Are null/undefined values handled at every point they could occur?
+- Do conditional branches cover all cases? Is there a missing else/default?
+
+**Error Handling**
+- Does every function that can fail have error handling?
+- Are catch blocks doing something meaningful (logging, recovery, re-throwing with context)?
+- Are there any empty catch blocks? FLAG THESE AS CRITICAL.
+- Do error messages include enough context to debug the issue?
+- Are errors propagated correctly up the call chain?
+
+**Security**
+- Is user input validated before use?
+- Are there any SQL injection vectors (string concatenation in queries)?
+- Are there any XSS vectors (unescaped user content in HTML)?
+- Are secrets or credentials hardcoded? FLAG AS CRITICAL.
+- Are there any path traversal vulnerabilities in file operations?
+- Is authentication/authorization checked before sensitive operations?
+
+**Testing**
+- Does every new function have at least one test?
+- Are edge cases tested (empty input, null, boundary values)?
+- Are error paths tested (what happens when things fail)?
+- If a bug was fixed, is there a regression test?
+- FLAG any new code without corresponding tests as a REQUIRED CHANGE.
+
+**Code Quality**
+- Are there any `any` types? FLAG THESE.
+- Are functions under 50 lines? Flag functions over 50 lines for extraction.
+- Are files under 400 lines? Flag files over 400 lines for splitting.
+- Are variable names descriptive? Flag single-letter variables outside of loop counters.
+- Is there duplicated code that should be extracted?
+- Are there TODO/FIXME/HACK comments? Flag these as incomplete work.
+
+### Step 3: Produce Review Summary
+
+Format your review as:
+
+```
+## Code Review Summary
+
+### Critical Issues (Must Fix)
+- [file:line] Description of the issue and why it's critical
+
+### Required Changes
+- [file:line] Description of what needs to change
+
+### Suggestions (Nice to Have)
+- [file:line] Description of the improvement
+
+### What Looks Good
+- Specific things that are well-implemented
+```
+
+NEVER produce a review that says "Looks good, no issues found" unless you have genuinely checked every item above for every changed file. If you only spot-checked, say so.
+```
+
+## 2.2 Test Writer Skill
+
+File: `templates/skills/test-writer.md`
+
+```markdown
+---
+name: test-writer
+description: Generates comprehensive tests for code changes. Auto-invokes when creating new functions, modules, or fixing bugs. Writes tests BEFORE implementation when doing TDD.
+---
+
+## Test Writing Process
+
+### Step 1: Analyze What Needs Testing
+- Read the function/module signature, parameters, and return type
+- Identify the happy path (normal successful execution)
+- Identify error paths (what can go wrong?)
+- Identify edge cases (empty input, null, boundary values, max values)
+- Identify integration points (database calls, API calls, file system)
+
+### Step 2: Write Tests in This Order
+
+1. **Happy path test** — The most basic successful case
+2. **Input validation tests** — Invalid inputs, missing required fields, wrong types
+3. **Edge case tests** — Empty arrays, zero values, very long strings, special characters
+4. **Error handling tests** — Network failures, database errors, file not found
+5. **Integration tests** — Full request/response cycle (if applicable)
+
+### Step 3: Test Structure
+
+Every test MUST follow this structure:
+
+```
+// Descriptive name that explains what is being tested and expected outcome
+test("createUser returns the created user with a generated ID when given valid input", async () => {
+  // ARRANGE: Set up test data and dependencies
+  const input = { name: "Test User", email: "test@example.com" };
+
+  // ACT: Execute the function under test
+  const result = await createUser(input);
+
+  // ASSERT: Verify the outcome
+  expect(result.id).toBeDefined();
+  expect(result.name).toBe("Test User");
+  expect(result.email).toBe("test@example.com");
+});
+```
+
+### Mandatory Test Categories
+
+For EVERY function, write tests covering:
+
+| Category | Example | Required? |
+|---|---|---|
+| Valid input, expected output | Normal successful operation | ALWAYS |
+| Missing required field | Omit a required parameter | ALWAYS |
+| Invalid type | Pass string where number expected | ALWAYS |
+| Empty input | Empty string, empty array, null | ALWAYS |
+| Boundary values | 0, -1, MAX_INT, very long string | WHEN APPLICABLE |
+| Duplicate/conflict | Creating something that already exists | WHEN APPLICABLE |
+| Not found | Requesting something that does not exist | WHEN APPLICABLE |
+| Unauthorized | Accessing without proper permissions | WHEN AUTH EXISTS |
+| Concurrent access | Two operations on same resource | WHEN APPLICABLE |
+| Error recovery | Service dependency fails | WHEN EXTERNAL DEPS EXIST |
+
+### Rules
+- Test file names MUST match source file: `user.service.ts` → `user.service.test.ts`
+- NEVER test implementation details — test behavior and outcomes
+- NEVER use `test("should work")` — test names must describe the specific scenario and expected outcome
+- EVERY test must be independent — no test should depend on another test running first
+- ALWAYS clean up test data (use beforeEach/afterEach or setup/teardown)
+- Mock external dependencies (databases, APIs, file system) — do not make real network calls in unit tests
+- NEVER write a test that always passes — verify your test fails before the implementation exists
+```
+
+## 2.3 Security Scan Skill
+
+File: `templates/skills/security-scan.md`
+
+```markdown
+---
+name: security-scan
+description: Scans code for security vulnerabilities including injection, XSS, hardcoded secrets, insecure dependencies, and missing auth checks. Auto-invokes when modifying auth, API, or data handling code.
+---
+
+## Security Scan Process
+
+### Step 1: Scan for Hardcoded Secrets
+Search the entire codebase for patterns matching:
+- API keys: strings matching `[A-Za-z0-9_-]{20,}` near variables named `key`, `token`, `secret`, `password`, `apiKey`, `api_key`, `auth`
+- AWS keys: strings starting with `AKIA`
+- Private keys: `-----BEGIN (RSA |EC |DSA )?PRIVATE KEY-----`
+- Connection strings with embedded passwords
+- .env files committed to git (check .gitignore)
+
+Use `grep -rn` with these patterns. Report EVERY match as CRITICAL.
+
+### Step 2: Scan for Injection Vulnerabilities
+For every file that constructs queries or commands:
+- SQL injection: String concatenation or template literals in SQL queries
+- Command injection: User input passed to exec(), spawn(), system(), or shell commands
+- Path traversal: User input used in file paths without sanitization
+- LDAP injection: User input in LDAP queries
+- NoSQL injection: User input in MongoDB queries without sanitization
+
+### Step 3: Scan for XSS Vulnerabilities
+For every file that renders user content:
+- Unescaped user input in HTML templates
+- innerHTML or dangerouslySetInnerHTML with user data
+- User data in href, src, or event handler attributes
+- Missing Content-Security-Policy headers
+
+### Step 4: Scan for Auth/AuthZ Issues
+- Endpoints without authentication middleware
+- Missing authorization checks (user can access other users' data)
+- JWT tokens without expiration
+- Passwords stored without hashing
+- Session tokens in URLs (should be in cookies or headers)
+- Missing CORS configuration or overly permissive CORS (`*`)
+
+### Step 5: Scan for Dependency Vulnerabilities
+Run the appropriate audit command:
+- Node.js: `npm audit` or `yarn audit`
+- Python: `pip-audit` or `safety check`
+- Java: `./mvnw dependency-check:check`
+
+Report any high or critical severity vulnerabilities.
+
+### Output Format
+```
+## Security Scan Results
+
+### CRITICAL (Fix Immediately)
+- [file:line] [CATEGORY] Description and remediation
+
+### HIGH (Fix Before Merge)
+- [file:line] [CATEGORY] Description and remediation
+
+### MEDIUM (Fix Soon)
+- [file:line] [CATEGORY] Description and remediation
+
+### LOW (Informational)
+- [file:line] [CATEGORY] Description
+```
+
+NEVER produce a clean scan without actually running the checks. If a check cannot be performed (e.g., no audit tool installed), say so explicitly.
+```
+
+## 2.4 Documentation Skill
+
+File: `templates/skills/documentation.md`
+
+```markdown
+---
+name: documentation
+description: Generates and updates documentation when code changes. Creates README updates, API docs, and inline documentation. Auto-invokes when creating new modules, endpoints, or public APIs.
+---
+
+## Documentation Standards
+
+### When to Generate Documentation
+- New module or package created → Generate module README
+- New API endpoint created → Update API documentation
+- New public function/class created → Add JSDoc/docstring
+- Configuration changed → Update setup documentation
+- Breaking change made → Update CHANGELOG and migration guide
+
+### Function/Method Documentation
+Every exported function MUST have a documentation comment containing:
+1. One-line summary of what the function does
+2. @param for every parameter with type and description
+3. @returns describing what is returned and when
+4. @throws listing every exception that can be thrown and why
+5. @example with at least one usage example
+
+### API Endpoint Documentation
+Every API endpoint MUST be documented with:
+1. HTTP method and path
+2. Description of what it does
+3. Request body schema (with all fields, types, and whether required)
+4. Response schemas for ALL status codes (200, 400, 401, 404, 500)
+5. Example request and response
+6. Authentication requirements
+
+### README Standards
+Every package/module README MUST contain:
+1. What the module does (one paragraph)
+2. How to install/setup
+3. Basic usage example that actually works
+4. Configuration options
+5. API reference or link to API docs
+
+NEVER generate documentation that says "Add description here" or contains placeholder text. If you don't know what something does, read the code and describe it accurately.
+```
+
+## 2.5 Performance Audit Skill
+
+File: `templates/skills/performance-audit.md`
+
+```markdown
+---
+name: performance-audit
+description: Identifies performance issues in code including N+1 queries, memory leaks, unnecessary re-renders, and inefficient algorithms. Auto-invokes when modifying database queries, loops, or data processing code.
+---
+
+## Performance Audit Checklist
+
+### Database Performance
+- [ ] N+1 query detection: Are queries inside loops? Should they be batched?
+- [ ] Missing indexes: Are WHERE clause columns indexed?
+- [ ] SELECT *: Are you fetching columns you don't need?
+- [ ] Unbounded queries: Is there a LIMIT? What if the table has 10 million rows?
+- [ ] Missing pagination: Are list endpoints paginated?
+- [ ] Transaction scope: Are transactions held open during slow operations?
+
+### Memory Performance
+- [ ] Unbounded collections: Are arrays/lists growing without limit?
+- [ ] Missing cleanup: Are event listeners, intervals, and subscriptions cleaned up?
+- [ ] Large object retention: Are references to large objects held after they're needed?
+- [ ] Stream vs. buffer: Are large files loaded entirely into memory, or streamed?
+
+### Algorithm Performance
+- [ ] Nested loops: Is there an O(n²) operation that could be O(n) with a map/set?
+- [ ] Repeated computation: Is the same value calculated multiple times?
+- [ ] Unnecessary sorting: Is data sorted when only the min/max is needed?
+- [ ] String concatenation in loops: Should use array join or string builder?
+
+### Frontend Performance (if applicable)
+- [ ] Unnecessary re-renders: Are components re-rendering when their props haven't changed?
+- [ ] Missing memoization: Should expensive computations use useMemo?
+- [ ] Bundle size: Are large libraries imported for small features?
+- [ ] Image optimization: Are images appropriately sized and lazy-loaded?
+- [ ] Missing virtualization: Are long lists rendered without windowing?
+
+Report issues with estimated impact (critical/high/medium/low) and specific remediation steps.
+```
+
+---
+
+# SECTION 3: AGENT TEMPLATES
+
+Each agent template lives in `templates/agents/`. Each file is a complete markdown file ready to be placed in `.claude/agents/`.
+
+## 3.1 Explore Agent
+
+File: `templates/agents/explore.md`
+
+```markdown
+---
+name: explore
+description: Read-only codebase investigation. Understands architecture, finds files, traces data flow. Never modifies files.
+allowed-tools: Read, Glob, Grep, Bash(find *), Bash(wc *), Bash(cat *)
+---
+
+You are an exploration agent. Your job is to understand codebases without modifying them.
+
+## Rules
+- NEVER use Write, Edit, or any tool that modifies files
+- NEVER run commands that could change state (no npm install, no git commit, no database writes)
+- ALWAYS explain your findings with specific file paths and line numbers
+- ALWAYS trace the full call chain when investigating how something works
+
+## When Asked to Explore
+1. Start by reading the project structure (`find . -type f -not -path '*/node_modules/*' -not -path '*/.git/*'`)
+2. Read the entry point files first (index.ts, main.py, App.java)
+3. Follow imports to understand the dependency graph
+4. Use Grep to find all usages of specific functions or types
+5. Summarize findings with a clear architecture description and specific file references
+```
+
+## 3.2 Plan Agent
+
+File: `templates/agents/plan.md`
+
+```markdown
+---
+name: plan
+description: Architecture planning and task decomposition. Produces detailed implementation plans without writing code.
+allowed-tools: Read, Glob, Grep, Bash(find *), Bash(wc *), Bash(cat *)
+---
+
+You are a planning agent. Your job is to produce detailed implementation plans.
+
+## Rules
+- NEVER write or modify code — only produce plans
+- ALWAYS read existing code before planning changes
+- ALWAYS break plans into tasks that are each completable in under 30 minutes
+- EVERY task must include: what files to create/modify, what to add/change, and how to verify it works
+- ALWAYS identify risks and dependencies between tasks
+
+## Plan Format
+```
+## Implementation Plan: [Feature Name]
+
+### Prerequisites
+- What must exist before starting
+
+### Tasks (in order)
+1. **[Task Name]** (estimated: X minutes)
+   - Files to modify: [list]
+   - Changes: [specific description]
+   - Verification: [how to test this task is done correctly]
+   - Dependencies: [which tasks must be done first]
+
+### Risks
+- [Risk]: [Mitigation]
+
+### Definition of Done
+- [ ] All tasks completed
+- [ ] All tests pass
+- [ ] No new lint warnings
+- [ ] Documentation updated
+```
+```
+
+## 3.3 Test Runner Agent
+
+File: `templates/agents/test-runner.md`
+
+```markdown
+---
+name: test-runner
+description: Executes test suites, analyzes failures, identifies flaky tests, and reports coverage gaps.
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+You are a test runner agent. Your job is to execute tests and provide detailed analysis.
+
+## Process
+1. Run the full test suite: `{{test_command}}`
+2. If tests fail:
+   - Read each failing test to understand what it expects
+   - Read the implementation code the test covers
+   - Identify whether the test or the implementation is wrong
+   - Provide specific fix recommendations
+3. If tests pass:
+   - Check coverage report if available
+   - Identify files/functions with low or zero coverage
+   - List the specific test cases that should be added
+4. Check for flaky tests:
+   - Run the suite 3 times
+   - Report any tests that pass sometimes and fail sometimes
+   - Flaky tests are BUGS — they indicate race conditions or test isolation issues
+
+## Output Format
+```
+## Test Report
+
+### Results: X passed, Y failed, Z skipped
+
+### Failures
+- test_name: Why it failed, recommended fix
+
+### Coverage Gaps
+- file.ts: Functions missing tests: [list]
+
+### Flaky Tests
+- test_name: Passed X/3 runs, likely cause
+
+### Recommendations
+- Specific tests to add, ordered by risk
+```
+```
+
+## 3.4 Security Auditor Agent
+
+File: `templates/agents/security-auditor.md`
+
+```markdown
+---
+name: security-auditor
+description: Comprehensive security audit of the codebase. Scans for vulnerabilities, checks dependencies, and reviews auth implementation.
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+You are a security auditor agent. Your job is to find security vulnerabilities.
+
+## Audit Process
+1. Run dependency audit (`npm audit` / `pip-audit` / equivalent)
+2. Scan for hardcoded secrets (grep for key patterns in all source files)
+3. Review authentication implementation (find auth middleware, check JWT handling)
+4. Review authorization (find access control checks, verify they cover all protected resources)
+5. Scan for injection vulnerabilities (SQL, command, path traversal, XSS)
+6. Check security headers (CORS, CSP, HSTS, X-Frame-Options)
+7. Review error handling (ensure no stack traces or internal details leak to clients)
+8. Check logging (ensure no sensitive data is logged)
+
+## Rules
+- NEVER mark a vulnerability as "low risk" to avoid inconvenience — report what you find honestly
+- ALWAYS include the specific file and line number
+- ALWAYS include a concrete remediation step, not just "fix this"
+- If you find a critical vulnerability, say so clearly at the top of your report
+```
+
+---
+
+# SECTION 4: HOOK TEMPLATES
+
+Hook templates live in `templates/hooks/`. Each file is a JSON object that gets merged into `.claude/settings.json` under the `hooks` key.
+
+## 4.1 Format-on-Write Hook
+
+File: `templates/hooks/format-on-write.json`
+
+```json
+{
+  "PostToolUse": [
+    {
+      "matcher": "Write(*.ts)|Write(*.tsx)|Write(*.js)|Write(*.jsx)",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "npx prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null || true"
+        }
+      ]
+    },
+    {
+      "matcher": "Write(*.py)",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "ruff format \"$CLAUDE_FILE_PATH\" 2>/dev/null || true"
+        }
+      ]
+    },
+    {
+      "matcher": "Write(*.go)",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "gofmt -w \"$CLAUDE_FILE_PATH\" 2>/dev/null || true"
+        }
+      ]
+    },
+    {
+      "matcher": "Write(*.rs)",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "rustfmt \"$CLAUDE_FILE_PATH\" 2>/dev/null || true"
+        }
+      ]
+    }
+  ]
+}
+```
+
+## 4.2 Lint-on-Write Hook
+
+File: `templates/hooks/lint-on-write.json`
+
+```json
+{
+  "PostToolUse": [
+    {
+      "matcher": "Write(*.ts)|Write(*.tsx)|Write(*.js)|Write(*.jsx)",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "npx eslint --no-error-on-unmatched-pattern \"$CLAUDE_FILE_PATH\" 2>&1 | head -20"
+        }
+      ]
+    },
+    {
+      "matcher": "Write(*.py)",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "ruff check \"$CLAUDE_FILE_PATH\" 2>&1 | head -20"
+        }
+      ]
+    }
+  ]
+}
+```
+
+## 4.3 Test Enforcement Hook
+
+File: `templates/hooks/test-enforcement.json`
+
+THIS IS THE MOST IMPORTANT HOOK. This is what prevents Claude from shipping untested code.
+
+```json
+{
+  "PostToolUse": [
+    {
+      "matcher": "Write(*.ts)|Write(*.tsx)|Write(*.js)|Write(*.jsx)|Edit(*.ts)|Edit(*.tsx)|Edit(*.js)|Edit(*.jsx)",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "npm test 2>&1 | tail -5; EXIT_CODE=${PIPESTATUS[0]}; if [ $EXIT_CODE -ne 0 ]; then echo '\\n❌ TESTS FAILED — Fix failing tests before continuing. Do not move to the next task.'; fi; exit 0"
+        }
+      ]
+    }
+  ]
+}
+```
+
+Note: The hook itself does not block (exit 0) because blocking on every file write is too aggressive. Instead, it surfaces the test failure prominently in Claude's context so it sees the failure and acts on it. For strict enforcement, change `exit 0` to `exit 2` which will cause Claude to stop and address the issue.
+
+## 4.4 Dangerous Command Blocker Hook
+
+File: `templates/hooks/danger-blocker.json`
+
+```json
+{
+  "PreToolUse": [
+    {
+      "matcher": "Bash",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "BLOCKED_PATTERNS='rm -rf|rm -fr|git push --force|git push -f|DROP TABLE|DROP DATABASE|TRUNCATE TABLE|:(){:|:&};:|dd if=|mkfs|format c:|del /f /s /q|chmod -R 777|curl.*|.*|sh$|wget.*|.*|sh$'; if echo \"$CLAUDE_BASH_COMMAND\" | grep -qiE \"$BLOCKED_PATTERNS\"; then echo 'BLOCKED: This command is potentially destructive and has been blocked by ccboot safety hooks. If you genuinely need to run this command, ask the developer for explicit approval.' >&2; exit 2; fi; exit 0"
+        }
+      ]
+    }
+  ]
+}
+```
+
+Exit code 2 is critical — it tells Claude Code to STOP and not execute the command.
+
+## 4.5 Secret Leak Detector Hook
+
+File: `templates/hooks/secret-detector.json`
+
+```json
+{
+  "PreToolUse": [
+    {
+      "matcher": "Bash(git commit*)|Bash(git add*)",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "STAGED=$(git diff --cached --name-only 2>/dev/null); if [ -z \"$STAGED\" ]; then exit 0; fi; SECRETS=$(git diff --cached | grep -inE '(api[_-]?key|secret|password|token|private[_-]?key|aws_access|AKIA[A-Z0-9]{16})\\s*[:=]\\s*[\"\\x27]?[A-Za-z0-9+/=_-]{8,}' | head -5); if [ -n \"$SECRETS\" ]; then echo \"BLOCKED: Potential secrets detected in staged files:\" >&2; echo \"$SECRETS\" >&2; echo 'Remove secrets and use environment variables instead.' >&2; exit 2; fi; exit 0"
+        }
+      ]
+    }
+  ]
+}
+```
+
+---
+
+# SECTION 5: NEW TOOL — ccboot_audit_code_quality
+
+## 5.1 Tool Registration
+
+Add this tool to `src/tools/management.ts` (or create a new `src/tools/enforcement.ts`).
+
+Tool name: `ccboot_audit_code_quality`
+
+## 5.2 Input Schema
+
+```typescript
+const AuditCodeQualitySchema = z.object({
+  project_path: z.string().describe("Path to the project root directory"),
+  language: z.enum(["typescript", "javascript", "python", "java", "auto"])
+    .default("auto")
+    .describe("Primary language to scan. 'auto' detects from project files."),
+  output_format: z.enum(["markdown", "json"])
+    .default("markdown")
+    .describe("Output format"),
+  fix_suggestions: z.boolean()
+    .default(true)
+    .describe("Include specific fix suggestions for each issue"),
+}).strict();
+```
+
+## 5.3 What It Scans
+
+The tool MUST scan for ALL of the following. Each check must be implemented. Do not skip any.
+
+### Check 1: TODO/FIXME/HACK/XXX Detection
+- Scan all source files for comments containing TODO, FIXME, HACK, or XXX
+- Report each occurrence with file, line number, and the comment text
+- Severity: MEDIUM (indicates incomplete work)
+
+### Check 2: Empty Catch Blocks
+- Scan for `catch` blocks that contain no statements (or only a comment)
+- For TypeScript/JavaScript: regex pattern `catch\s*\([^)]*\)\s*\{\s*\}` and `catch\s*\([^)]*\)\s*\{\s*//[^\n]*\s*\}`
+- For Python: `except.*:\s*pass` and `except.*:\s*#`
+- Report each occurrence with file and line number
+- Severity: HIGH (errors are being silently swallowed)
+
+### Check 3: `any` Type Usage (TypeScript/JavaScript only)
+- Scan for `: any`, `as any`, `<any>`, `any[]`, `Promise<any>`, `Record<string, any>`
+- Exclude files in node_modules/, dist/, and .d.ts declaration files
+- Report each occurrence with file and line number
+- Severity: HIGH (defeats the purpose of TypeScript)
+
+### Check 4: Console.log in Production Code
+- Scan for `console.log(` in source files (not test files)
+- Exclude files matching `*.test.*`, `*.spec.*`, and files in `__tests__/`
+- Report each occurrence
+- Severity: MEDIUM (should use proper logging)
+
+### Check 5: Large Files
+- Scan all source files and report any over 400 lines
+- Report the file path and line count
+- Severity: MEDIUM (indicates the file should be split)
+
+### Check 6: Long Functions
+- Scan for functions over 50 lines
+- For TypeScript/JavaScript: Track function/method declarations and count lines to closing brace
+- Report function name, file, line number, and line count
+- Severity: MEDIUM (indicates the function should be extracted)
+
+### Check 7: Hardcoded Strings That Look Like Secrets
+- Scan for patterns that look like API keys, tokens, or passwords in source code (not .env files)
+- Patterns: strings longer than 20 chars assigned to variables named key, token, secret, password, api_key, apiKey
+- Report each occurrence
+- Severity: CRITICAL (potential secret leak)
+
+### Check 8: Missing Error Handling in Async Code
+- For TypeScript/JavaScript: Find `await` expressions not inside a try/catch block
+- For Python: Find `await` expressions not inside a try/except block
+- This is a heuristic — report as WARNING, not ERROR
+- Severity: LOW (not all awaits need try/catch, but unhandled rejections are common bugs)
+
+## 5.4 Output Format
+
+Markdown output:
+```
+## Code Quality Audit Report
+
+**Project:** {{project_path}}
+**Scanned:** {{file_count}} files
+**Issues Found:** {{total_issues}}
+
+### Summary
+| Severity | Count |
+|----------|-------|
+| CRITICAL | X |
+| HIGH | X |
+| MEDIUM | X |
+| LOW | X |
+
+### CRITICAL Issues
+- **[file.ts:42]** Hardcoded secret: Variable `apiKey` contains a 32-character string that appears to be an API key. Move this to an environment variable.
+
+### HIGH Issues
+- **[file.ts:87]** Empty catch block: Error is caught but not handled. Add logging or error recovery.
+- **[file.ts:15]** `any` type: Parameter `data` is typed as `any`. Use a specific interface or `unknown`.
+
+### MEDIUM Issues
+...
+
+### Quality Score: X/100
+```
+
+JSON output must include: `{ success: true, data: { score, summary, issues: [...], scanned_files }, message, next_steps }`
+
+## 5.5 Quality Score Calculation
+
+```
+score = 100
+score -= (critical_count * 15)
+score -= (high_count * 5)
+score -= (medium_count * 2)
+score -= (low_count * 1)
+score = Math.max(0, Math.min(100, score))
+```
+
+---
+
+# SECTION 6: ENHANCED ccboot_init_project
+
+## 6.1 What Changes
+
+The existing `ccboot_init_project` tool must be updated to:
+
+1. Use the new opinionated CLAUDE.md templates instead of generic placeholders
+2. Install ALL hook templates (format-on-write, lint-on-write, test-enforcement, danger-blocker, secret-detector) into `.claude/settings.json`
+3. Install ALL skill templates into `.claude/skills/`
+4. Install ALL agent templates into `.claude/agents/`
+5. Run `ccboot_audit_code_quality` as a post-init step and include the results in the output
+
+## 6.2 Default Behavior Changes
+
+When `ccboot_init_project` is called without explicit options:
+
+- Detect tech stack from existing project files (package.json → Node.js, pyproject.toml → Python, pom.xml → Java, Cargo.toml → Rust)
+- Select the appropriate CLAUDE.md template based on detected stack
+- Install ALL hooks (all 5 hook templates)
+- Install ALL skills (all 5 skill templates)
+- Install ALL agents (all 4 agent templates)
+- Generate .claudeignore
+- Generate .claude/settings.json with appropriate permissions
+- Run the code quality audit and include results
+
+The output message should list everything that was created and highlight any immediate code quality issues found.
+
+---
+
+# SECTION 7: TESTING REQUIREMENTS
+
+## 7.1 Template Content Tests
+
+For every template, write a test that:
+1. Renders the template with sample variables
+2. Verifies the output contains the "Mandatory Practices" section verbatim
+3. Verifies the output contains the "Self-Review Checklist" section verbatim
+4. Verifies no `{{variable}}` markers remain in the output (all were substituted)
+5. Verifies YAML frontmatter parses correctly (for skill templates)
+
+## 7.2 Code Quality Audit Tests
+
+Write tests for `ccboot_audit_code_quality` that:
+1. Create a temp directory with intentionally bad code (empty catch, any types, TODO comments)
+2. Run the audit tool
+3. Verify each check catches the intentional issues
+4. Verify the quality score calculation is correct
+5. Test both markdown and JSON output formats
+
+## 7.3 Hook Template Tests
+
+Write tests for each hook template that:
+1. Verify the JSON is valid
+2. Verify the event names are valid Claude Code lifecycle events
+3. Verify the matcher patterns are syntactically correct
+4. For the danger blocker: verify that test patterns are blocked (echo "rm -rf /" should match)
+5. For the secret detector: verify that test patterns are detected
+
+---
+
+# SECTION 8: PUBLISH v1.2.0
+
+## 8.1 Version Bump
+Update package.json version to `1.2.0`.
+
+## 8.2 CHANGELOG
+Add a CHANGELOG.md entry:
+
+```markdown
+## [1.2.0] - 2026-XX-XX
+
+### Added
+- Opinionated CLAUDE.md templates for Next.js, FastAPI, Spring Boot, React SPA, and monorepo projects
+- Enforcement hook templates: test-enforcement, format-on-write, lint-on-write, secret-detector
+- `ccboot_audit_code_quality` tool: scans for empty catch blocks, any types, TODO comments, hardcoded secrets, large files, long functions
+- Complete skill templates with detailed instructions: code-review, test-writer, security-scan, documentation, performance-audit
+- Complete agent templates: explore, plan, test-runner, security-auditor
+- Quality score calculation (0-100) in audit results
+
+### Changed
+- `ccboot_init_project` now installs all enforcement hooks by default
+- `ccboot_init_project` runs code quality audit as post-init step
+- All CLAUDE.md templates now include mandatory practices and self-review checklist
+- All templates contain specific, actionable instructions instead of placeholders
+
+### Fixed
+- Templates no longer contain TODO or placeholder text
+```
+
+## 8.3 README Update
+Update README.md to highlight the enforcement features prominently. Lead with: "ccboot doesn't just set up Claude Code — it prevents Claude from shipping broken code."
+
+## 8.4 Publish
+```bash
+npm run build
+npm run test
+npm version 1.2.0
+npm publish
+```
+
+---
+
+## FINAL CHECKLIST
+
+Before marking v1.2.0 as complete, verify ALL of the following:
+
+- [ ] Every CLAUDE.md template contains the FULL "Mandatory Practices" section (copy-pasted from Section 1.3, not summarized)
+- [ ] Every CLAUDE.md template contains the FULL "Self-Review Checklist" section
+- [ ] Every skill template contains specific, step-by-step instructions (not "add appropriate content")
+- [ ] Every hook template contains a working shell command (not a placeholder)
+- [ ] The test-enforcement hook actually runs the test command and surfaces failures
+- [ ] The danger-blocker hook actually blocks rm -rf (exit code 2)
+- [ ] The secret-detector hook actually detects API key patterns (exit code 2)
+- [ ] ccboot_audit_code_quality scans for all 8 check categories
+- [ ] ccboot_init_project installs all hooks, skills, and agents by default
+- [ ] npm run build passes with zero errors
+- [ ] npm run test passes with all tests green
+- [ ] No TODO, FIXME, or placeholder text exists in any template
+- [ ] Version is 1.2.0 in package.json
+- [ ] CHANGELOG.md is updated
+- [ ] README.md highlights enforcement features
+
+If ANY item above is not checked, v1.2.0 is NOT complete. Do not publish.