create-ai-project 1.11.2

package/docs/rules-en/frontend/typescript-testing.md

@@ -0,0 +1,124 @@
+# TypeScript Testing Rules
+
+## Test Framework
+- **Vitest**: This project uses Vitest
+- **React Testing Library**: For component testing
+- **MSW (Mock Service Worker)**: For API mocking
+- Test imports: `import { describe, it, expect, beforeEach, vi } from 'vitest'`
+- Component test imports: `import { render, screen, fireEvent } from '@testing-library/react'`
+- Mock creation: Use `vi.mock()`
+
+## Basic Testing Policy
+
+### Quality Requirements
+- **Coverage**: Unit test coverage must be 60% or higher (Frontend standard 2025)
+- **Independence**: Each test can run independently without depending on other tests
+- **Reproducibility**: Tests are environment-independent and always return the same results
+- **Readability**: Test code maintains the same quality as production code
+
+### Coverage Requirements (ADR-0002 Compliant)
+**Mandatory**: Unit test coverage must be 60% or higher
+**Component-specific targets**:
+- Atoms (Button, Text, etc.): 70% or higher
+- Molecules (FormField, etc.): 65% or higher
+- Organisms (Header, Footer, etc.): 60% or higher
+- Custom Hooks: 65% or higher
+- Utils: 70% or higher
+
+**Metrics**: Statements, Branches, Functions, Lines
+
+### Test Types and Scope
+1. **Unit Tests (React Testing Library)**
+   - Verify behavior of individual components or functions
+   - Mock all external dependencies
+   - Most numerous, implemented with fine granularity
+   - Focus on user-observable behavior
+
+2. **Integration Tests (React Testing Library + MSW)**
+   - Verify coordination between multiple components
+   - Mock APIs with MSW (Mock Service Worker)
+   - No actual DB connections (backend manages DB)
+   - Verify major functional flows
+
+3. **Cross-functional Verification in E2E Tests**
+   - Mandatory verification of impact on existing features when adding new features
+   - Cover integration points with "High" and "Medium" impact levels from Design Doc's "Integration Point Map"
+   - Verification pattern: Existing feature operation → Enable new feature → Verify continuity of existing features
+   - Success criteria: No change in displayed content, rendering time within 5 seconds
+   - Designed for automatic execution in CI/CD pipelines
+
+## Test Implementation Conventions
+
+### Directory Structure (Co-location Principle)
+```
+src/
+└── components/
+    └── Button/
+        ├── Button.tsx
+        ├── Button.test.tsx  # Co-located with component
+        └── index.ts
+```
+
+**Rationale**:
+- React Testing Library best practice
+- ADR-0002 Co-location principle
+- Easy to find and maintain tests alongside implementation
+
+### Naming Conventions
+- Test files: `{ComponentName}.test.tsx`
+- Integration test files: `{FeatureName}.integration.test.tsx`
+- Test suites: Names describing target components or features
+- Test cases: Names describing expected behavior from user perspective
+
+### Test Code Quality Rules
+
+✅ **Recommended: Keep all tests always active**
+- Merit: Guarantees test suite completeness
+- Practice: Fix problematic tests and activate them
+
+❌ **Avoid: test.skip() or commenting out**
+- Reason: Creates test gaps and incomplete quality checks
+- Solution: Completely delete unnecessary tests
+
+## Mock Type Safety Enforcement
+
+### MSW (Mock Service Worker) Setup
+```typescript
+// ✅ Type-safe MSW handler
+import { rest } from 'msw'
+
+const handlers = [
+  rest.get('/api/users/:id', (req, res, ctx) => {
+    return res(ctx.json({ id: '1', name: 'John' } satisfies User))
+  })
+]
+```
+
+### Component Mock Type Safety
+```typescript
+// ✅ Only required parts
+type TestProps = Pick<ButtonProps, 'label' | 'onClick'>
+const mockProps: TestProps = { label: 'Click', onClick: vi.fn() }
+
+// Only when absolutely necessary, with clear justification
+const mockRouter = {
+  push: vi.fn()
+} as unknown as Router // Complex router type structure
+```
+
+## Basic React Testing Library Example
+
+```typescript
+import { describe, it, expect, vi } from 'vitest'
+import { render, screen, fireEvent } from '@testing-library/react'
+import { Button } from './Button'
+
+describe('Button', () => {
+  it('should call onClick when clicked', () => {
+    const onClick = vi.fn()
+    render(<Button label="Click me" onClick={onClick} />)
+    fireEvent.click(screen.getByRole('button', { name: 'Click me' }))
+    expect(onClick).toHaveBeenCalledOnce()
+  })
+})
+```

package/docs/rules-en/frontend/typescript.md

@@ -0,0 +1,131 @@
+# TypeScript Development Rules
+
+## Frontend-Specific Anti-patterns
+
+In addition to universal anti-patterns in coding-standards.md, watch for these Frontend-specific issues:
+
+- **Prop drilling through 3+ levels** - Should use Context API or state management
+- **Massive components (300+ lines)** - Split into smaller components
+
+## Type Safety in Frontend Implementation
+
+**Type Safety in Data Flow**
+- **Frontend → Backend**: Props/State (Type Guaranteed) → API Request (Serialization)
+- **Backend → Frontend**: API Response (`unknown`) → Type Guard → State (Type Guaranteed)
+
+**Frontend-Specific Type Scenarios**:
+- **React Props/State**: TypeScript manages types, unknown unnecessary
+- **External API Responses**: Always receive as `unknown`, validate with type guards
+- **localStorage/sessionStorage**: Treat as `unknown`, validate
+- **URL Parameters**: Treat as `unknown`, validate
+- **Form Input (Controlled Components)**: Type-safe with React synthetic events
+
+**Type Complexity Management (Frontend)**
+- **Props Design**:
+  - Props count: 3-7 props ideal (consider component splitting if exceeds 10)
+  - Optional Props: 50% or less (consider default values or Context if excessive)
+  - Nesting: Up to 2 levels (flatten deeper structures)
+- Type Assertions: Review design if used 3+ times
+- **External API Types**: Relax constraints and define according to reality (convert appropriately internally)
+
+## Coding Conventions
+
+**Component Design Criteria**
+- **Function Components (Mandatory)**: Official React recommendation, optimizable by modern tooling
+- **Classes Prohibited**: Class components completely deprecated (Exception: Error Boundary)
+- **Custom Hooks**: Standard pattern for logic reuse
+
+**Function Design**
+- **0-2 parameters maximum**: Use object for 3+ parameters
+  ```typescript
+  // ✅ Object parameter
+  function createUser({ name, email, role }: CreateUserParams) {}
+  ```
+
+**Props Design (Props-driven Approach)**
+- Props are the interface: Define all necessary information as props
+- Avoid implicit dependencies: Do not depend on global state or context without necessity
+- Type-safe: Always define Props type explicitly
+
+**Environment Variables**
+- **Use build tool's environment variable system**: `process.env` does not work in browsers
+- **No secrets on client-side**: All frontend code is public, manage secrets in backend
+
+**Dependency Injection**
+- **Custom Hooks for dependency injection**: Ensure testability and modularity
+
+**Asynchronous Processing**
+- Promise Handling: Always use `async/await`
+- Error Handling: Always handle with `try-catch` or Error Boundary
+- Type Definition: Explicitly define return value types (e.g., `Promise<Result>`)
+
+**Format Rules**
+- Semicolon omission (follow Biome settings)
+- Types in `PascalCase`, variables/functions in `camelCase`
+- Imports use absolute paths (`src/`)
+
+**Clean Code Principles**
+- ✅ Delete unused code immediately
+- ✅ Delete debug `console.log()`
+- ❌ Commented-out code (manage history with version control)
+- ✅ Comments explain "why" (not "what")
+
+## Error Handling
+
+**Absolute Rule**: Error suppression prohibited. All errors must have log output and appropriate handling.
+
+**Fail-Fast Principle**: Fail quickly on errors to prevent continued processing in invalid states
+```typescript
+// ❌ Prohibited: Unconditional fallback
+catch (error) {
+  return defaultValue // Hides error
+}
+
+// ✅ Required: Explicit failure
+catch (error) {
+  logger.error('Processing failed', error)
+  throw error // Handle with Error Boundary or higher layer
+}
+```
+
+**Result Type Pattern**: Express errors with types for explicit handling
+```typescript
+type Result<T, E> = { ok: true; value: T } | { ok: false; error: E }
+
+// Example: Express error possibility with types
+function parseUser(data: unknown): Result<User, ValidationError> {
+  if (!isValid(data)) return { ok: false, error: new ValidationError() }
+  return { ok: true, value: data as User }
+}
+```
+
+**Custom Error Classes**
+```typescript
+export class AppError extends Error {
+  constructor(message: string, public readonly code: string, public readonly statusCode = 500) {
+    super(message)
+    this.name = this.constructor.name
+  }
+}
+// Purpose-specific: ValidationError(400), ApiError(502), NotFoundError(404)
+```
+
+**Layer-Specific Error Handling (React)**
+- Error Boundary: Catch React component errors, display fallback UI
+- Custom Hook: Detect business rule violations, propagate AppError as-is
+- API Layer: Convert fetch errors to domain errors
+
+**Structured Logging and Sensitive Information Protection**
+Never include sensitive information (password, token, apiKey, secret, creditCard) in logs
+
+**Asynchronous Error Handling in React**
+- Error Boundary setup mandatory: Catch rendering errors
+- Use try-catch with all async/await in event handlers
+- Always log and re-throw errors or display error state
+
+## Performance Optimization
+
+- Component Memoization: Use React.memo for expensive components
+- State Optimization: Minimize re-renders with proper state structure
+- Lazy Loading: Use React.lazy and Suspense for code splitting
+- Bundle Size: Monitor with the `build` script (use the appropriate run command based on the `packageManager` field in package.json) and keep under 500KB

package/docs/rules-en/integration-e2e-testing.md

@@ -0,0 +1,149 @@
+# Integration Test & E2E Test Design/Implementation Rules
+
+## Test Types and Limits
+
+| Type | Purpose | File Format | Limit |
+|------|---------|-------------|-------|
+| Integration Test | Component interaction verification | `*.int.test.ts` | 3 per feature |
+| E2E Test | Critical user journey verification | `*.e2e.test.ts` | 1-2 per feature |
+
+**Critical User Journey**: Features with revenue impact, legal requirements, or daily use by majority of users
+
+## Behavior-First Principle
+
+### Observability Check (All YES = Include)
+
+| Check | Question | If NO |
+|-------|----------|-------|
+| Observable | Can user observe the result? | Exclude |
+| System Context | Does it require integration of multiple components? | Exclude |
+| Automatable | Can it run stably in CI environment? | Exclude |
+
+### Include/Exclude Criteria
+
+**Include**: Business logic accuracy, data integrity, user-visible features, error handling
+**Exclude**: External live connections, performance metrics, implementation details, UI layout
+
+## Skeleton Specification
+
+### Required Comment Format
+
+```typescript
+// AC: "[Acceptance criteria original text]"
+// ROI: [0-100] | Business Value: [0-10] | Frequency: [0-10]
+// Behavior: [Trigger] → [Process] → [Observable Result]
+// @category: core-functionality | integration | edge-case | ux | e2e
+// @dependency: none | [component name] | full-system
+// @complexity: low | medium | high
+it.todo('[AC number]: [Test name]')
+```
+
+### Property Annotations
+
+```typescript
+// Property: `[Verification expression]`
+// fast-check: fc.property(fc.[arbitrary], (input) => [invariant])
+it.todo('[AC number]-property: [Invariant description]')
+```
+
+### ROI Calculation
+
+```
+ROI = (Business Value × Frequency + Legal Requirement × 10 + Defect Detection) / Total Cost
+```
+
+| Type | Total Cost | E2E Generation Condition |
+|------|------------|-------------------------|
+| Integration | 11 | - |
+| E2E | 38 | ROI > 50 |
+
+## Implementation Rules
+
+### Property-Based Test Implementation
+
+When Property annotation exists, fast-check library is required:
+
+```typescript
+import fc from 'fast-check'
+
+it('AC2-property: Model name is always gemini-3-pro-image-preview', () => {
+  fc.assert(
+    fc.property(fc.string(), (prompt) => {
+      const result = client.generate(prompt)
+      return result.model === 'gemini-3-pro-image-preview'
+    })
+  )
+})
+```
+
+**Requirements**:
+- Write in `fc.assert(fc.property(...))` format
+- Reflect skeleton's `// fast-check:` comment directly in implementation
+- When failure case discovered, add as concrete unit test (regression prevention)
+
+### Behavior Verification Implementation
+
+**Behavior Description Verification Levels**:
+
+| Step Type | Verification Target | Example |
+|-----------|--------------------| --------|
+| Trigger | Reproduce in Arrange | API failure → mockResolvedValue({ ok: false }) |
+| Process | Intermediate state or call | Function call, state change |
+| Observable Result | Final output value | Return value, error message, log output |
+
+**Pass Criteria**: Pass if "observable result" is verified as **return value or mock call argument** of test target
+
+### Verification Item Determination Rules
+
+| Skeleton State | Verification Item Determination Method |
+|----------------|---------------------------------------|
+| `// Verification items:` listed | Implement all listed items with expect |
+| No `// Verification items:` | Derive from "observable result" in "Behavior" description |
+| Both present | Prioritize verification items, use behavior as supplement |
+
+**Derivation Example from Behavior**:
+```
+// Behavior: User completes payment → Order created in DB → Order confirmation screen displayed
+↓ Derived
+- Order is created in DB (or creation function is called)
+- Order confirmation screen data is returned
+```
+
+### Integration Test Mock Boundaries
+
+| Judgment Criteria | Mock | Actual |
+|-------------------|------|--------|
+| Part of test target? | No → Can mock | Yes → Actual required |
+| Is call verification target of test? | No → Can mock | Yes → Actual or verifiable mock |
+| External network communication? | Yes → Mock required | No → Actual recommended |
+
+**Judgment Flow**:
+1. External API (HTTP communication) → Mock required
+2. Component interaction under test → Actual required
+3. Log output verification needed → Use verifiable mock (vi.fn())
+4. Log output verification not needed → Actual or ignore
+
+### E2E Test Execution Conditions
+
+- Execute only after all components are implemented
+- Do not use mocks (`@dependency: full-system`)
+
+## Review Criteria
+
+### Skeleton and Implementation Consistency
+
+| Check | Failure Condition |
+|-------|-------------------|
+| Property Verification | Property annotation exists but fast-check not used |
+| Behavior Verification | No expect for "observable result" |
+| Verification Item Coverage | Listed verification items not included in expect |
+| Mock Boundary | Internal components mocked in integration test |
+
+### Implementation Quality
+
+| Check | Failure Condition |
+|-------|-------------------|
+| AAA Structure | Arrange/Act/Assert separation unclear |
+| Independence | State sharing between tests, execution order dependency |
+| Reproducibility | Depends on date/random, results vary |
+| Readability | Test name and verification content don't match |

package/docs/rules-en/project-context.md

@@ -0,0 +1,38 @@
+# Project Context
+
+## Basic Configuration
+
+### Project Nature
+- **Project Type**: Claude Code-specific TypeScript project template
+- **Usage Scope**: Configurable according to project requirements
+- **Implementation Policy**: LLM-driven implementation, quality-focused, strict YAGNI principle adherence
+
+### Technology Stack
+- **Foundation Technologies**: TypeScript, Node.js
+- **Test Framework**: Vitest
+- **Quality Management**: Biome, TypeScript strict mode
+
+## Implementation Principles
+
+### Implementation Policy Characteristics
+- **LLM-Driven Implementation**: Claude Code functions as the primary implementer
+- **Quality-First Culture**: Prioritize quality over speed
+- **YAGNI Principle**: Don't implement until necessary
+- **Systematic Design**: Design process through ADR/Design Doc/work plans
+
+## Customization Guide
+
+When using this template for new projects:
+
+1. **Add Project-Specific Information**
+   - Target user characteristics
+   - Business requirements and constraints
+   - Technical constraint conditions
+
+2. **Architecture Selection**
+   - Select appropriate patterns from `docs/rules/architecture/`
+   - Place project-specific designs in `docs/rules/architecture/`
+
+3. **Environment Configuration**
+   - Implement environment variable management methods suitable for the project
+   - Add project-specific configuration files

package/docs/rules-en/rules-index.yaml

@@ -0,0 +1,211 @@
+# Metadata for each rule file
+# Manages overview, tags, typical usage scenarios, and size for each rule
+
+rules:
+  coding-standards:
+    file: "coding-standards.md"
+    tags: [universal, anti-patterns, refactoring, type-safety, testing, code-deletion, rule-of-three, fail-fast, impact-analysis]
+    typical-use: "Universal coding principles applicable across all domains, foundational standards for all developers"
+    size: large
+    key-references:
+      - "Rule of Three - Martin Fowler"
+      - "Single Responsibility Principle - Clean Code"
+      - "DRY Principle - The Pragmatic Programmer"
+      - "YAGNI Principle - Kent Beck"
+      - "5 Whys - Toyota Production System"
+      - "Red-Green-Refactor - Kent Beck"
+      - "AAA Pattern - Arrange-Act-Assert"
+    sections:
+      - "Technical Anti-patterns (Red Flag Patterns)"
+      - "Basic Principles"
+      - "Comment Writing Rules"
+      - "Error Handling Fundamentals"
+      - "Rule of Three - Criteria for Code Duplication"
+      - "Common Failure Patterns and Avoidance Methods"
+      - "Debugging Techniques"
+      - "Type Safety Fundamentals"
+      - "Refactoring Techniques"
+      - "Situations Requiring Technical Decisions"
+      - "Continuous Improvement Mindset"
+      - "Implementation Completeness Assurance"
+      - "Red-Green-Refactor Process (Test-First Development)"
+      - "Test Design Principles"
+      - "Test Helper Utilization Rules"
+      - "Test Granularity Principles"
+      - "Continuity Test Scope"
+
+  typescript:
+    file: "typescript.md"
+    tags: [implementation, type-safety, async, refactoring, coding-style, functional-programming, dependency-injection, branded-types, backend]
+    typical-use: "Backend TypeScript code creation, modification, refactoring, modern type features utilization"
+    size: small
+    key-references:
+      - "YAGNI Principle - Kent Beck"
+      - "Clean Code - Robert C. Martin"
+      - "DRY Principle - The Pragmatic Programmer"
+      - "Refactoring - Martin Fowler"
+      - "TypeScript 4.9 satisfies Operator - Microsoft"
+      - "Branded Types - TypeScript Community"
+      - "Effect-TS / fp-ts - Functional Programming"
+      - "Dependency Injection - Martin Fowler"
+      - "Avoiding fallback in distributed systems - AWS Builders' Library"
+    sections:
+      - "Type Safety in Backend Implementation"
+      - "Coding Conventions"
+      - "Error Handling"
+      - "Performance Optimization"
+
+  typescript-testing:
+    file: "typescript-testing.md"
+    tags: [quality, testing, tdd, coverage, vitest, implementation, debugging, refactoring, backend]
+    typical-use: "Backend test creation, quality checks, test quality criteria, development steps for code/bug fixes, refactoring, and new feature implementation"
+    size: small
+    key-references:
+      - "Test-Driven Development - Kent Beck"
+      - "Rule of Three - Martin Fowler"
+      - "Red-Green-Refactor - Kent Beck"
+      - "AAA Pattern - Arrange-Act-Assert"
+    sections:
+      - "Test Framework"
+      - "Basic Testing Policy"
+      - "Test Implementation Conventions"
+      - "Test Quality Criteria"
+      - "Mock Type Safety Enforcement"
+      - "Basic Vitest Example"
+
+  technical-spec:
+    file: "technical-spec.md"
+    tags: [architecture, design, documentation, environment, data-flow, implementation, quality-commands, testing, build]
+    typical-use: "Technical design, environment configuration, documentation creation process, implementation policy decisions, quality check commands, build and test execution"
+    size: medium
+    key-references:
+      - "ADR Format - Michael Nygard"
+      - "Single Data Source Principle - Single Source of Truth"
+    sections:
+      - "Basic Technology Stack Policy"
+      - "Environment Variable Management and Security"
+      - "Architecture Design"
+      - "Architecture Patterns"
+      - "Unified Data Flow Principles"
+      - "Build and Testing"
+
+  project-context:
+    file: "project-context.md"
+    tags: [context, project-specific, implementation]
+    typical-use: "Project-specific information, understanding implementation principles"
+    size: small
+    key-references:
+      - "Project-specific (empirical)"
+    sections:
+      - "Basic Configuration"
+      - "Implementation Principles"
+      - "Customization Guide"
+
+  documentation-criteria:
+    file: "documentation-criteria.md"
+    tags: [documentation, adr, prd, design-doc, work-plan, decision-matrix]
+    typical-use: "Implementation start scale assessment, document creation decisions, ADR/PRD/Design Doc/work plan creation criteria"
+    size: medium
+    key-references:
+      - "ADR Methodology - Michael Nygard"
+      - "Design Doc Culture - Google Engineering Practices"
+      - "Single Source of Truth"
+    sections:
+      - "Creation Decision Matrix"
+      - "ADR Creation Conditions (Required if Any Apply)"
+      - "Detailed Document Definitions"
+      - "Creation Process"
+      - "Storage Locations"
+      - "ADR Status"
+      - "AI Automation Rules"
+      - "Diagram Requirements"
+      - "Common ADR Relationships"
+
+  implementation-approach:
+    file: "architecture/implementation-approach.md"
+    tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, confirmation-levels]
+    typical-use: "Implementation strategy selection, task decomposition, design decisions, large-scale change planning"
+    size: medium
+    key-references:
+      - "Strangler Fig Pattern - Martin Fowler"
+      - "Feature Slicing - Martin Fowler"
+      - "Walking Skeleton - Alistair Cockburn"
+      - "Facade Pattern - Gang of Four"
+    sections:
+      - "Meta-cognitive Strategy Selection Process"
+      - "Verification Level Definitions"
+      - "Integration Point Definitions"
+      - "Anti-patterns"
+      - "Guidelines for Meta-cognitive Execution"
+
+  integration-e2e-testing:
+    file: "integration-e2e-testing.md"
+    tags: [testing, integration-test, e2e-test, property-based-testing, fast-check, test-skeleton, test-review, quality]
+    typical-use: "Integration and E2E test skeleton generation, test implementation, test review, Property-Based Test implementation"
+    size: small
+    key-references:
+      - "fast-check - Property-based testing for TypeScript"
+      - "Node.js Testing Best Practices - Yoni Goldberg"
+      - "Property-Based Testing - 2025 Practices"
+    sections:
+      - "Test Types and Limits"
+      - "Behavior-First Principle"
+      - "Skeleton Specification"
+      - "Implementation Rules"
+      - "Review Criteria"
+
+  # Frontend-specific Rules
+  frontend-typescript:
+    file: "frontend/typescript.md"
+    tags: [frontend, react, implementation, type-safety, function-components, props-driven, async, refactoring, coding-style]
+    typical-use: "React component creation, Props type definitions, frontend TypeScript development"
+    size: small
+    key-references:
+      - "React Function Components - React Official"
+      - "Props-driven Design - React Best Practices"
+      - "YAGNI Principle - Kent Beck"
+      - "Clean Code - Robert C. Martin"
+      - "TypeScript satisfies Operator - Microsoft"
+    sections:
+      - "Frontend-Specific Anti-patterns"
+      - "Type Safety in Frontend Implementation"
+      - "Coding Conventions"
+      - "Error Handling"
+      - "Performance Optimization"
+
+  frontend-typescript-testing:
+    file: "frontend/typescript-testing.md"
+    tags: [frontend, react, quality, testing, tdd, coverage, vitest, react-testing-library, msw, implementation]
+    typical-use: "React component testing, React Testing Library tests, MSW API mocking, frontend test creation"
+    size: small
+    key-references:
+      - "React Testing Library - Kent C. Dodds"
+      - "MSW (Mock Service Worker) - MSW Team"
+      - "Test-Driven Development - Kent Beck"
+      - "Red-Green-Refactor - Kent Beck"
+      - "User-Observable Behavior Testing - Testing Library"
+    sections:
+      - "Test Framework"
+      - "Basic Testing Policy"
+      - "Test Implementation Conventions"
+      - "Mock Type Safety Enforcement"
+      - "Basic React Testing Library Example"
+
+  frontend-technical-spec:
+    file: "frontend/technical-spec.md"
+    tags: [frontend, react, vite, architecture, design, environment, data-flow, implementation, performance]
+    typical-use: "React technical design, Vite configuration, frontend environment setup, component architecture decisions"
+    size: medium
+    key-references:
+      - "React Official Documentation"
+      - "Build Tool Best Practices"
+      - "Single Source of Truth"
+    sections:
+      - "Basic Technology Stack Policy"
+      - "Environment Variable Management and Security"
+      - "Architecture Design"
+      - "Unified Data Flow Principles"
+      - "Build and Testing"
+      - "Quality Check Requirements"
+      - "Coverage Requirements"
+      - "Non-functional Requirements"