takt 0.32.0 → 0.32.2

package/builtins/en/facets/instructions/e2e-coverage-implement.md

@@ -0,0 +1,26 @@
+Implement missing E2E tests based on the test case list.
+
+**Important:** Refer to the test plan report: {report:01-e2e-coverage-plan.md}
+
+**Note:** If Previous Response exists, this is a resubmission.
+Check which test cases were flagged as unimplemented and implement them.
+
+**What to do:**
+1. Review the numbered test case list from the test plan
+2. Implement tests following existing E2E test patterns (file structure, helpers, fixtures, mock strategy)
+3. Implement ALL cases in the test case list (do not stop after implementing just a few)
+4. Run E2E tests and confirm all tests pass
+5. Confirm existing E2E tests are not broken
+
+**Implementation constraints:**
+- Do not modify the existing E2E test framework
+- Write one scenario per concern with clear expected results
+- Follow existing fixture/helper/mock patterns for cases with external dependencies
+
+**Required output (include headings)**
+## Implemented Test Cases
+- {Test case list number and corresponding test file/test name}
+## Unimplemented Test Cases (if any)
+- {Number and reason for not implementing}
+## Test Results
+- {Execution command and results}

package/builtins/en/facets/instructions/e2e-coverage-plan.md

@@ -0,0 +1,38 @@
+Comprehensively identify all user operation routes in the application and create a list of missing E2E test cases.
+
+**Note:** If Previous Response exists, this is a resubmission.
+Review and revise the list based on that feedback.
+
+**What to do:**
+
+1. **Understand the E2E test infrastructure**
+   - Review existing E2E test directory structure, test runner, helpers, fixtures, and mock strategy
+   - Identify the test execution commands
+
+2. **Identify user operation entry points** (read CODE, not just documentation)
+   - For CLI: extract command definitions, subcommands, and options from code
+   - For Web: extract routing definitions, page transitions, and API endpoints from code
+   - Trace each entry point's handler and processing flow, identifying branches and state transitions
+
+3. **Deep-dive into UX variations**
+   - For each entry point, enumerate all possible routes a user can take
+   - Option/flag combinations that create different branches (e.g., `--pipeline` on/off, `--auto-pr` on/off)
+   - State-dependent branches (first run vs existing data, config present vs absent)
+   - Not just happy paths — error handling and recovery routes when things fail midway
+   - Permission/role-based routes
+   - External dependency state branches (connection success vs failure, normal vs abnormal response)
+
+4. **Cross-reference with existing E2E tests**
+   - Analyze what existing tests cover on a per-file basis
+   - Identify which routes are already covered by existing tests
+   - List uncovered routes as "missing test cases"
+
+5. **Create the test case list**
+   - Assign a unique number to every test case (this is the ledger supervisor uses for verification)
+   - Assign priority to each case (user impact × untested risk)
+   - **Do NOT abbreviate.** Don't stop at 1-2 cases — enumerate ALL identified routes
+
+**Strictly prohibited:**
+- Reading only docs/README and guessing test cases → PROHIBITED. Read the code
+- Cutting the list short with "there might be more" → PROHIBITED. Enumerate all
+- Including cases already covered by existing tests → PROHIBITED. Only list verified gaps

package/builtins/en/facets/instructions/e2e-coverage-supervise.md

@@ -0,0 +1,21 @@
+Cross-reference the test case list from the plan with implementation results, and verify all cases have been implemented.
+
+**Important:** Refer to the test plan report: {report:01-e2e-coverage-plan.md}
+
+**Verification procedure:**
+
+1. **Cross-reference with test case list (most important)**
+   - Check each numbered test case from the plan report one by one
+   - Identify the corresponding test file and test name for each case
+   - Read the test file to confirm the case is actually tested
+   - List any cases without a corresponding test as "unimplemented"
+   - REJECT if even one unimplemented case exists
+
+2. **Test quality verification**
+   - Does each test correctly verify the intent of the test case?
+   - Are assertions appropriate (not just existence checks, but value verification)?
+   - Does the mock/fixture usage follow existing patterns?
+
+3. **Test execution verification**
+   - Run E2E tests and confirm all tests pass
+   - Confirm existing tests are not broken

package/builtins/en/facets/instructions/fix.md

@@ -1,5 +1,9 @@
 Use reports in the Report Directory and fix the issues raised by the reviewer.
 
+**Fix principles:**
+- When a finding includes a "suggested fix", follow it rather than inventing your own workaround
+- Fix the target code directly. Do not deflect findings by adding tests or documentation instead
+
 **Report reference policy:**
 - Use the latest review reports in the Report Directory as primary evidence.
 - Past iteration reports are saved as `{filename}.{timestamp}` in the same directory (e.g., `architect-review.md.20260304T123456Z`). For each report, run Glob with a `{report-name}.*` pattern, read up to 2 files in descending timestamp order, and understand persists / reopened trends before starting fixes.

package/builtins/en/facets/instructions/loop-monitor-ai-fix.md

@@ -7,6 +7,7 @@ is healthy (making progress) or unproductive (repeating the same issues).
 - AI Review results: {report:ai-review.md}
 
 **Judgment criteria:**
-- Are new issues being found/fixed in each cycle?
-- Are the same findings being repeated?
-- Are fixes actually being applied?
+- Are the same finding_ids persisting across multiple cycles?
+  - Same finding_id repeatedly persists → unproductive (stuck)
+  - Previous findings resolved and new findings appear as new → healthy (progressing)
+- Are fixes actually being applied to the code?

package/builtins/en/facets/instructions/loop-monitor-reviewers-fix.md

@@ -4,6 +4,8 @@ Review the latest review reports in the Report Directory and determine
 whether this loop is healthy (converging) or unproductive (diverging or oscillating).
 
 **Judgment criteria:**
-- Is the number of new / reopened findings decreasing each cycle?
-- Are the same family_tag findings not repeating (is persists not growing)?
+- Are the same finding_ids persisting across multiple cycles?
+  - Same finding_id repeatedly persists → unproductive (stuck)
+  - Previous findings resolved and new findings appear as new → healthy (converging)
 - Are fixes actually being applied to the code?
+- Is the number of new / reopened findings decreasing overall?

package/builtins/en/facets/instructions/plan.md

@@ -19,7 +19,9 @@ For small tasks, skip the design sections in the report.
 4. Determine file structure and design patterns (if needed)
 5. Decide on the implementation approach
    - Verify the implementation approach does not violate knowledge/policy constraints
+   - When adding or changing a user-facing feature, fix the conditions, entry points, and reachability by which users arrive at it
 6. Include the following in coder implementation guidelines:
    - Existing implementation patterns to reference (file:line). Always cite when similar processing already exists
    - Impact area of changes. Especially when adding new parameters, enumerate all call sites that need wiring
    - Anti-patterns to watch for in this specific task (if applicable)
+   - When adding or changing a user-facing feature, all affected reachability, callers, and launch conditions

package/builtins/en/facets/instructions/review-frontend.md

@@ -1,13 +1,21 @@
 Review the changes from a frontend development perspective.
 
 **Review criteria:**
+- Design fidelity (top priority when a design reference is provided)
 - Component design (separation of concerns, granularity)
 - State management (local vs. global decisions)
 - Performance (re-renders, memoization)
 - Accessibility (keyboard navigation, ARIA)
 - Data fetching patterns
+- Reachability wiring for user-facing features (routes, entry paths, launch conditions)
 - TypeScript type safety
 
+**Design fidelity check (when a design reference exists):**
+1. Identify the design reference from the task order's referenced materials
+2. Compare design elements (layout, wording, colors, spacing) against implementation element by element
+3. For any discrepancy, check the decisions log to determine if it was intentional
+4. Report unintentional discrepancies as blocking issues
+
 **Note**: If this project does not include a frontend,
 proceed as no issues found.
 
@@ -21,5 +29,6 @@ Review {report:coder-decisions.md} to understand the recorded design decisions.
 
 1. Review the change diff and detect issues based on the frontend development criteria above
    - Cross-check changes against REJECT criteria tables defined in knowledge
+   - When new screens or user-facing features are added, verify that entry points and caller wiring were updated as well
 2. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
 3. If there is even one blocking issue, judge as REJECT

package/builtins/en/facets/instructions/security-audit-plan.md

@@ -0,0 +1,12 @@
+Understand the overall project structure and create a complete list of files to be audited for security.
+
+**What to do:**
+1. Identify the project's source code directories and list all files using Glob
+2. Understand the project's tech stack, frameworks, and major dependencies
+3. Classify each file's role briefly (API layer, domain layer, infrastructure layer, utilities, etc.)
+4. Identify files with high security risk (authentication, input handling, external communication, file operations, configuration, etc.)
+
+**Important:**
+- List ALL files without omission. Do not abbreviate
+- Include configuration files and test files
+- Even if the file count is large, list every single file

package/builtins/en/facets/instructions/security-audit-review.md

@@ -0,0 +1,22 @@
+Re-audit the files that were judged insufficient in the previous audit.
+
+**Important:** Review the supervisor's verification results and understand:
+- List of unaudited files
+- List of files flagged as insufficiently audited
+- Specific feedback
+
+**What to do:**
+1. **Read each flagged file in full using Read tool one by one**
+2. Review each file from a security perspective
+3. Report discovered issues with severity ratings
+
+**Strictly prohibited:**
+- Searching with Grep and only reviewing matching files → PROHIBITED
+- Reading only part of a file → PROHIBITED
+- Skipping a file because it "looks fine" → PROHIBITED
+
+**Required output (include headings):**
+## Re-audit Results
+- {Audit results for each file}
+## Detected Issues
+- {Issue details (severity, location, remediation)}

package/builtins/en/facets/instructions/security-audit-supervise.md

@@ -0,0 +1,20 @@
+Verify the completeness and quality of the security audit.
+
+**Important:** Refer to the plan report: {report:01-plan.md}
+
+**Verification procedure:**
+
+1. **Completeness verification (most important)**
+   - Cross-reference the file list from the plan report with files mentioned in the audit results
+   - List any files not mentioned in the audit results as "unaudited files"
+   - REJECT if even one unaudited file exists
+
+2. **Methodology verification**
+   - Check whether each file's audit result references specific code content
+   - If a file only says "no issues" without mentioning specific content checked, it may not have been actually Read → REJECT
+   - Check for signs that judgment was based solely on Grep keyword matching
+
+3. **Quality verification**
+   - Check whether severity classifications of detected issues are appropriate
+   - Read a few high-security-risk files yourself to verify no issues were missed
+   - Check whether there are too many false positives

package/builtins/en/facets/instructions/security-audit-team-leader.md

@@ -0,0 +1,27 @@
+Decompose the security audit task, assign files to each part, and execute in parallel.
+
+**Important:** Refer to the plan report: {report:01-plan.md}
+
+**What to do:**
+
+1. Review the file list from the plan report and understand all files to be audited
+2. Split files into 3 groups by module/layer
+   - Distribute high-security-risk files (authentication, input handling, external communication, etc.) evenly across groups
+   - Keep related files (within the same module) in the same group when possible
+3. Assign exclusive file ownership to each part
+
+**Each part's instruction MUST include:**
+- **Assigned file list** (all file paths to review via Read)
+- **Audit procedure:**
+  1. **Read each assigned file in full using Read tool one by one** (do NOT abbreviate with Grep or partial reads)
+  2. Review each file from a security perspective
+  3. Report discovered issues with severity ratings
+- **Strictly prohibited:**
+  - Searching with Grep and only reviewing matching files → PROHIBITED. Read ALL files
+  - Reading only part of a file → PROHIBITED. Read the entire file
+  - Skipping a file because it "looks fine" → PROHIBITED. Review every file
+- **Completion criteria:** All assigned files have been Read in full, and audit results are reported for each file
+
+**Constraints:**
+- Each part is read-only. Do not modify code
+- Do not audit files outside your assignment (to prevent overlap)

package/builtins/en/facets/knowledge/e2e-testing.md

@@ -0,0 +1,89 @@
+# E2E Testing Knowledge
+
+## E2E Test Scope
+
+E2E tests verify the entire user operation flow. Their scope differs from unit and integration tests.
+
+| Test Type | Scope | Verification Target |
+|-----------|-------|-------------------|
+| Unit | Function/Class | Logic correctness |
+| Integration | Inter-module coupling | Data flow correctness |
+| E2E | Entire user operation flow | Behavior as seen by the user |
+
+| Criteria | Judgment |
+|----------|----------|
+| Writing E2E tests for logic that unit tests can cover | Warning. Consider moving to unit tests |
+| Verifying user operation flows | E2E test is appropriate |
+| Scenarios spanning multiple commands/pages | E2E test is appropriate |
+| Error message display verification | E2E test is appropriate |
+
+## UX Route Identification
+
+E2E test completeness depends on thorough UX route identification. Identify entry points from code, not documentation.
+
+### Entry Point Identification
+
+| Application Type | How to Find Entry Points |
+|-----------------|-------------------------|
+| CLI | Extract command definitions, subcommand registrations, option/flag definitions from code |
+| Web | Extract routing definitions, page component lists from code |
+| API | Extract endpoint definitions, router registrations from code |
+
+### Branch Patterns
+
+Exhaustively enumerate routes branching from each entry point.
+
+| Branch Pattern | Example |
+|---------------|---------|
+| Option/flag combinations | `--verbose` on/off, `--format json` vs `--format table` |
+| State-dependent branches | First run vs existing data, config present vs absent |
+| Permission/role | Admin vs regular user, authenticated vs unauthenticated |
+| External dependency state | Connection success vs timeout, normal vs error response |
+| Error recovery | Retry on midway failure, rollback |
+| Input variations | Valid input, invalid input, empty input, boundary values |
+
+
+## Mock Boundary Design
+
+In E2E tests, deciding "how far to run real code and where to start mocking" is critical.
+
+### Mock Design Principles
+
+- Run the application code under test as-is
+- Insert mocks at external service boundaries
+- Follow existing fixture/helper mock patterns
+- Check existing mock infrastructure before introducing new mechanisms
+
+## Flaky Test Prevention
+
+E2E tests are prone to non-deterministic failures.
+
+| Cause | Mitigation |
+|-------|-----------|
+| Timing dependency | Use explicit wait conditions (state-based waits, not fixed sleeps) |
+| Port conflicts | Assign random ports per test |
+| Filesystem residue | Create temp directories per test, cleanup on teardown |
+| Process leaks | Set timeouts and force-kill |
+| Environment dependency | Explicitly set up prerequisites for test execution |
+| Execution order dependency | Initialize state so each test runs independently |
+
+```typescript
+// NG - fixed sleep for timing
+await sleep(3000)
+expect(result).toBeDefined()
+
+// OK - condition-based wait
+await waitFor(() => expect(result).toBeDefined(), { timeout: 5000 })
+```
+
+## Test Case Management
+
+Manage test cases as a list to guarantee E2E test completeness.
+
+| Principle | Description |
+|-----------|-------------|
+| Numbered list | Assign a unique number to each test case and track implementation status |
+| Classify by entry point | Group by command/page/endpoint |
+| Prioritize | Determine priority by user impact × untested risk |
+| Cross-reference with existing tests | Check existing test coverage before adding new tests |
+

package/builtins/en/facets/knowledge/frontend.md

@@ -45,6 +45,40 @@ features/{feature-name}/
 └── index.ts
 ```
 
+## Routing Wiring When Adding a Page
+
+Do not stop at creating the page component. A new page must also be wired into an actual entry path. Decide together with the implementation how the page is reached: router, menu, temporary route, or another explicit entry point.
+
+| Criteria | Judgment |
+|----------|----------|
+| A new page exists but no route is registered for it | REJECT |
+| Basename-based URL and route path mapping is not verified | REJECT |
+| Router wiring and page entry are decided together with the page implementation | OK |
+| A temporary development route is used and its purpose/removal plan is recorded | OK |
+| Routes are updated but actual entry points such as menus, buttons, links, or external callers are not checked | Warning |
+
+```tsx
+// OK - page and route are added together
+<Route path="/contreg" element={<ContainerRegisterPage />} />
+
+// REJECT - page exists but has no reachable route
+// src/pages/ContainerRegisterPage.tsx exists
+// Router has no matching route
+```
+
+Reachability is broader than router configuration. Confirm the real entry path users will follow, such as menus, transition buttons, dialog actions, links from other screens, or external callers.
+
+### Integrating third-party UI libraries
+
+Third-party UI libraries such as data grids, date pickers, charts, and virtualized lists can fail at runtime even when types pass. This is especially common across major-version changes where prop names or state model shapes are no longer compatible, and shallow mocks do not expose the problem.
+
+| Criteria | Judgment |
+|----------|----------|
+| Major UI library props are guessed without checking the version used by the project | REJECT |
+| Tests fully mock the library and miss real mount failures | Warning |
+| The real component is rendered with representative props and verified not to crash at screen level | OK |
+| Prop shapes are chosen by referencing existing in-project usage patterns and the installed version | OK |
+
 ## State Management
 
 Child components do not modify their own state. They bubble events to parent, and parent manipulates state.
@@ -78,6 +112,7 @@ Exception (OK for child to have local state):
 | State changes from child to parent (reverse data flow) | REJECT |
 | API response stored as-is in state | Consider normalization |
 | Inappropriate useEffect dependencies | REJECT |
+| Initial load tied to unstable Context/Provider function references | REJECT |
 
 State Placement Guidelines:
 
@@ -88,6 +123,17 @@ State Placement Guidelines:
 | Shared across multiple components | Context or state management library |
 | Server data cache | Data fetching library (TanStack Query, etc.) |
 
+## Initial load and refetch boundaries
+
+Initial loading should be separated from reactive refetching. If refetching is not driven by URL, filter, paging, or explicit user action, keep it mount-only and do not tie it to unstable callback references.
+
+| Criteria | Judgment |
+|----------|----------|
+| Initial load reruns because a Provider/Context callback changed identity | REJECT |
+| Refetch conditions are explicit (URL, filter, paging, refresh action) | OK |
+| Message display, loading toggles, or modal state cause refetching | REJECT |
+| Initial load is mount-only and later refetches are triggered explicitly | OK |
+
 ## Data Fetching
 
 API calls are made in root (View) components and passed to children via props.

package/builtins/en/facets/knowledge/react.md

@@ -0,0 +1,90 @@
+# React Knowledge
+
+## Effects and Re-execution
+
+`useEffect` is a mechanism for declaring when re-execution is allowed, not a generic place to put initialization. Decide first whether a load is mount-only or should rerun on dependency changes.
+
+| Criteria | Judgment |
+|----------|----------|
+| A mount-only initial load depends on recreated function references | REJECT |
+| Context/Provider functions are used as effect dependencies without a clear refetch requirement | REJECT |
+| Mount-only initialization is expressed with `useEffect(..., [])` and its intent is documented | OK |
+| Refetching on dependency change is required by the feature and those dependencies are explicit | OK |
+
+```tsx
+// REJECT - initial load can rerun because unstable function deps leak into the effect
+const fetchList = useCallback(async () => {
+  await loadItems()
+}, [setIsLoading, errorPage])
+
+useEffect(() => {
+  fetchList()
+}, [fetchList])
+
+// OK - explicitly mount-only initial load
+useEffect(() => {
+  void loadItemsOnMount()
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## Context and Provider Values
+
+`value={{ ... }}` in a Provider creates a new reference on each Provider render. When functions obtained from Context are placed in effect dependencies, consumers can enter unintended refetch loops.
+
+| Criteria | Judgment |
+|----------|----------|
+| Context-derived functions are placed in effect dependencies without checking reference stability | REJECT |
+| Mount effects rely on Provider functions whose stability is not guaranteed | REJECT |
+| Context functions are used from event handlers while initial load stays mount-only | OK |
+| Provider values are stabilized and refetch conditions are defined explicitly | OK |
+
+```tsx
+// REJECT - Context functions are used directly as initial-load effect deps
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData(setIsLoading, errorPage)
+}, [setIsLoading, errorPage])
+
+// OK - initial load is mount-only, Context functions are consumed inside it
+const { setIsLoading, errorPage } = useAppContext()
+useEffect(() => {
+  void loadInitialData({ setIsLoading, errorPage })
+  // mount-only initial load
+  // eslint-disable-next-line react-hooks/exhaustive-deps
+}, [])
+```
+
+## Initial Page Load
+
+Treat initial page load separately from reactive refetching. Unless refetching is required by filter, URL, pagination, or explicit user action, keep the initial fetch mount-only.
+
+| Condition | Recommendation |
+|-----------|----------------|
+| List is loaded once on page entry | mount-only effect |
+| Refetching follows filter, pagination, or URL changes | make those states explicit dependencies |
+| Loading state updates trigger refetching | REJECT |
+| Message display or dialog state triggers refetching | REJECT |
+
+## Custom Hook Responsibility
+
+A React custom hook should encapsulate state, effects, refs, or event translation. Pure calculations belong in function modules, not in a `use*` hook.
+
+| Criteria | Judgment |
+|----------|----------|
+| A module is named `use*` but does not use React state/effect/ref | Warning |
+| Pure functions are modeled as a custom hook | Warning |
+| Stateful UI control lives in a custom hook and pure calculations live in functions | OK |
+| A hook returns JSX | REJECT |
+
+## Handling exhaustive-deps
+
+`react-hooks/exhaustive-deps` is not a rule to satisfy mechanically. If adding dependencies changes a mount-only effect into a loop, keep the effect mount-only and document why the suppression exists.
+
+| Criteria | Judgment |
+|----------|----------|
+| Dependencies are added only to satisfy lint and they change runtime behavior | REJECT |
+| Lint suppression is added without explanation | Warning |
+| Mount-only suppression is documented with intent | OK |
+| A reactive effect that should rerun is incorrectly frozen with `[]` | REJECT |

package/builtins/en/facets/knowledge/unit-testing.md

@@ -0,0 +1,108 @@
+# Unit Testing Knowledge
+
+## Test Double Selection
+
+Choose test doubles based on purpose. Excessive mocking reduces test reliability.
+
+| Type | Purpose | Use Case |
+|------|---------|----------|
+| Stub | Return fixed values | Control output of external dependencies |
+| Mock | Verify invocations | Confirm method calls and arguments |
+| Spy | Record calls while preserving implementation | Verify side effects |
+| Fake | Lightweight implementation | In-memory DB or similar lightweight substitutes |
+
+### Mock Granularity
+
+- Mock only direct dependencies of the test target (not indirect dependencies)
+- "Too many mocks" suggests a design problem in the test target
+- Pure functions have no dependencies and need no mocking
+
+```typescript
+// NG - mocking internal implementation (testing implementation, not behavior)
+vi.spyOn(service, 'privateMethod')
+service.execute()
+expect(service.privateMethod).toHaveBeenCalled()
+
+// OK - mock external dependency, verify behavior
+const repository = { findById: vi.fn().mockResolvedValue(user) }
+const service = new UserService(repository)
+const result = await service.getUser('id')
+expect(result).toEqual(user)
+```
+
+## Boundary Value Analysis
+
+Boundary values and equivalence partitioning are fundamental unit testing techniques.
+
+| Technique | Description |
+|-----------|-------------|
+| Equivalence partitioning | Divide inputs into equivalent groups, test one from each |
+| Boundary value analysis | Test at equivalence class boundaries (boundary, boundary±1) |
+
+```typescript
+// NG - happy path only
+test('validates age', () => {
+  expect(validateAge(25)).toBe(true)
+})
+
+// OK - includes boundary values
+test('validates age at boundaries', () => {
+  expect(validateAge(0)).toBe(true)    // lower bound
+  expect(validateAge(-1)).toBe(false)  // lower bound - 1
+  expect(validateAge(150)).toBe(true)  // upper bound
+  expect(validateAge(151)).toBe(false) // upper bound + 1
+})
+```
+
+## Test Fixture Design
+
+Manage test data with factory functions.
+
+- Generate minimal fixtures with factory functions
+- Fill test-irrelevant fields with defaults
+- Do not share and mutate fixtures between tests (maintain test independence)
+
+```typescript
+// NG - defining all fields every time
+const user = { id: '1', name: 'test', email: 'test@example.com', role: 'admin', createdAt: new Date() }
+
+// OK - factory function with minimal overrides
+const createUser = (overrides: Partial<User> = {}): User => ({
+  id: 'test-id',
+  name: 'test-user',
+  email: 'test@example.com',
+  role: 'user',
+  ...overrides,
+})
+
+test('admin can delete', () => {
+  const admin = createUser({ role: 'admin' })
+  // only test-relevant fields are explicit
+})
+```
+
+## Test Target Isolation
+
+Testability is an indicator of design quality. Hard-to-test code has tightly coupled dependencies.
+
+### Dependency Injection Patterns
+
+| Pattern | Use Case |
+|---------|----------|
+| Constructor injection | Class-based dependency separation |
+| Function arguments | Accept dependencies as function parameters |
+| Module replacement | Replace entire modules during testing |
+
+```typescript
+// NG - creates dependency directly (cannot mock in tests)
+class OrderService {
+  private repo = new OrderRepository()
+  async create(order: Order) { return this.repo.save(order) }
+}
+
+// OK - constructor injection (mockable in tests)
+class OrderService {
+  constructor(private readonly repo: OrderRepository) {}
+  async create(order: Order) { return this.repo.save(order) }
+}
+```

package/builtins/en/facets/output-contracts/e2e-coverage-plan.md

@@ -0,0 +1,33 @@
+```markdown
+# E2E Coverage Plan
+
+## Project Overview
+{Tech stack, E2E test framework, test execution commands}
+
+## User Operation Entry Points
+| # | Entry Point | Type | Handler |
+|---|-------------|------|---------|
+| 1 | {command/route/endpoint} | CLI/Web/API | `src/file.ts:42` |
+
+## UX Route Analysis
+### {Entry Point Name}
+| # | Route | Branch Condition | Existing Test |
+|---|-------|-----------------|---------------|
+| 1 | {happy path} | - | ✅ `e2e/file.test.ts` / ❌ none |
+| 2 | {with option X} | `--flag` | ❌ none |
+| 3 | {on error} | {condition} | ❌ none |
+
+## Missing Test Case List
+| # | Entry Point | Test Case | Priority | Expected Result to Verify |
+|---|-------------|-----------|----------|--------------------------|
+| 1 | {entry point} | {case summary} | High/Med/Low | {expected result} |
+| 2 | {entry point} | {case summary} | High/Med/Low | {expected result} |
+
+## Test Strategy
+- {Mock strategy}
+- {Fixture design}
+- {Existing helper usage}
+
+## Implementation Guidelines
+- {Instructions for test implementer}
+```