takt 0.32.0 → 0.32.1

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/review-frontend.md

@@ -1,6 +1,7 @@
 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)
@@ -8,6 +9,12 @@ Review the changes from a frontend development perspective.
 - Data fetching patterns
 - 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.
 

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/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}
+```

package/builtins/en/facets/output-contracts/security-audit.md

@@ -0,0 +1,31 @@
+```markdown
+# Security Audit Report
+
+## Result: APPROVE / REJECT
+
+## Severity: None / Low / Medium / High / Critical
+
+## Audit Scope
+| # | File | Audited | Risk Classification |
+|---|------|---------|-------------------|
+| 1 | `src/file.ts` | ✅ | High / Medium / Low |
+
+## Detected Issues
+| # | Severity | Category | Location | Issue | Remediation |
+|---|----------|----------|----------|-------|-------------|
+| 1 | Critical | injection | `src/file.ts:42` | {issue description} | {remediation} |
+
+## Files with No Issues
+- {list of files where no issues were detected}
+
+## Recommendations (non-blocking)
+- {security improvement suggestions}
+
+## REJECT Criteria
+- REJECT if one or more High or Critical issues exist
+```
+
+**Cognitive load reduction rules:**
+- No issues → Audit scope table only (15 lines max)
+- Low/Medium only → + issues table (30 lines max)
+- High/Critical present → Full output

package/builtins/en/facets/personas/coder.md

@@ -19,6 +19,7 @@ You are the implementer. Focus on implementation, not design decisions.
 - Thoroughness over speed. Code correctness over implementation ease
 - Prioritize "works correctly" over "works for now"
 - Don't implement by guessing; report unclear points
+- When a design reference is provided, match UI appearance, structure, and wording to the design. Do not add, omit, or change anything on your own judgment
 - Work only within the specified project directory (reading external files for reference is allowed)
 
 **Reviewer's feedback is absolute. Your understanding is wrong.**

package/builtins/en/facets/personas/frontend-reviewer.md

@@ -12,6 +12,9 @@ The user interface is the only point of contact between the system and users. No
 
 ## Areas of Expertise
 
+### Design Fidelity
+- When a design reference is provided, verify implementation matches the design element by element
+
 ### Component Design
 - Separation of concerns and component granularity
 - Props design and data flow
@@ -34,6 +37,7 @@ The user interface is the only point of contact between the system and users. No
 
 ## Important
 
+- **Design fidelity first**: When a design reference exists, verify design match before evaluating UX quality
 - **Prioritize user experience**: UX over technical correctness
 - **Performance can't be fixed later**: Consider at design stage
 - **Accessibility is hard to retrofit**: Build in from the start

package/builtins/en/facets/policies/ai-antipattern.md

@@ -75,6 +75,49 @@ Verification approach:
 2. If the only difference is optional argument presence, unify with ternary or spread syntax
 3. If branches have different preprocessing, store results in a variable and make a single call
 
+## Callback + External Variable Capture Abuse
+
+AI tends to implement data retrieval via callbacks and external variable capture when return values would suffice.
+
+| Pattern | Example | Verdict |
+|---------|---------|---------|
+| Assign to external variable in callback | `let result; await f(x => { result = x })` | REJECT |
+| Get value via event handler | `emitter.on('data', d => { captured = d })` to synchronously get value | REJECT |
+| Build state across multiple callbacks | `forEach(item => { externalMap.set(...) })` to construct result | REJECT |
+
+```typescript
+// REJECT - Capturing external variable via callback
+let selectedMode: string | undefined;
+await promptUser(choices, (choice) => {
+  selectedMode = choice;
+});
+return selectedMode;
+
+// OK - Receive via return value
+const selectedMode = await promptUser(choices);
+return selectedMode;
+```
+
+Verification approach:
+1. Find places where callback functions assign to variables in the outer scope
+2. Check if the value can be returned as a function return value
+3. If possible, flag for rewriting to the return-value pattern
+
+## Inappropriate Response to Review Findings
+
+AI sometimes "addresses" review findings by adding tests or documentation that "verify the finding" instead of actually fixing the code.
+
+| Pattern | Example | Verdict |
+|---------|---------|---------|
+| Adding tests instead of fixing | "Remove unnecessary comments" → adds tests verifying comment presence | REJECT |
+| Adding docs instead of fixing | "DRY violation" → adds documentation explaining duplication is intentional | REJECT |
+| Changing unrelated files | Security finding → performs unrelated refactoring | REJECT |
+
+Verification approach:
+1. Check if the fix diff includes changes to the finding's target file and target lines
+2. If the fix consists only of new file additions, check whether those files "fix" the issue or merely "verify" it
+3. If tests are added as part of the fix, verify they test "correct behavior after the fix" (not "the finding itself")
+
 ## Context Fitness Assessment
 
 Does the code fit this specific project?

package/builtins/en/facets/policies/coding.md

@@ -305,6 +305,73 @@ function formatDate(date: Date): string { ... }
 function formatPercentage(value: number): string { ... }
 ```
 
+## Same Implementation with Different Names (DRY Violation)
+
+AI tends to define the same logic under multiple function names.
+
+| Pattern | Example | Verdict |
+|---------|---------|---------|
+| Same implementation with different names | `copyFacets()` and `placeFacetFiles()` doing the same thing | REJECT |
+| Same parameter signature and body | Two functions taking the same params and doing the same work | REJECT |
+
+```typescript
+// REJECT - Same implementation exists under different names
+function copyFiles(src: string, dest: string): void {
+  for (const f of readdirSync(src)) {
+    copyFileSync(join(src, f), join(dest, f));
+  }
+}
+function placeFiles(src: string, dest: string): void {
+  for (const f of readdirSync(src)) {
+    copyFileSync(join(src, f), join(dest, f));
+  }
+}
+
+// OK - Consolidate into a single function
+function copyFiles(src: string, dest: string): void {
+  for (const f of readdirSync(src)) {
+    copyFileSync(join(src, f), join(dest, f));
+  }
+}
+```
+
+Verification approach:
+1. Check if newly added functions have bodies identical or nearly identical to existing functions
+2. Compare functions within the same file and within the same module
+3. If duplication is found, consolidate into one and unify call sites
+
+## Dangerous Stateful Regex Patterns
+
+Regular expressions with the `/g` flag are stateful (they retain `lastIndex`). Defining them at module scope and mixing `test()` and `replace()` causes unexpected results.
+
+| Pattern | Example | Verdict |
+|---------|---------|---------|
+| Module-scope `/g` regex used with `test()` | `const RE = /x/g; if (RE.test(s)) ...` | REJECT |
+| `/g` regex shared between `test()` and `replace()` | `RE.test(s)` followed by `s.replace(RE, ...)` | REJECT |
+
+```typescript
+// REJECT - Module-scope /g regex used with test()
+const PATTERN = /\{\{facet:(\w+)\}\}/g;
+function hasFacetRef(text: string): boolean {
+  return PATTERN.test(text);  // lastIndex advances, next call returns different result
+}
+
+// OK - Don't use /g for test(), or create new RegExp inside function
+const PATTERN_CHECK = /\{\{facet:(\w+)\}\}/;  // no /g
+const PATTERN_REPLACE = /\{\{facet:(\w+)\}\}/g;  // /g for replace
+function hasFacetRef(text: string): boolean {
+  return PATTERN_CHECK.test(text);
+}
+function replaceFacetRefs(text: string): string {
+  return text.replace(PATTERN_REPLACE, ...);
+}
+```
+
+Verification approach:
+1. Check if module-scope regexes have the `/g` flag
+2. Check if `/g` regexes are used with `test()`
+3. Check if the same regex is used with both `test()` and `replace()`
+
 ## Prohibited
 
 - **Fallbacks are prohibited by default** - Do not write fallbacks using `?? 'unknown'`, `|| 'default'`, or swallowing via `try-catch`. Propagate errors upward. If absolutely necessary, add a comment explaining why