takt 0.40.0 → 0.42.0

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

@@ -1,32 +1,11 @@
-Review the changes from a test quality perspective.
+Focus on reviewing **test quality**.
 
-**Review criteria:**
-- Whether all test plan items are covered
-- Test quality (Given-When-Then structure, independence, reproducibility)
-- Test naming conventions
-- Completeness (unnecessary tests, missing cases)
-- Appropriateness of mocks and fixtures
-- When an external contract exists, whether request body / query / path input locations are verified as defined
-- Whether the tests would catch an implementation that incorrectly reuses a response envelope for request parsing
+Procedure:
+1. Open the Knowledge and Policy Source paths with the Read tool and obtain the full content
+2. List every `##` section in each of them (do not cherry-pick)
+3. Match the criteria in each listed section against the diff and detect any issues
 
+## Step-Specific Additional Procedure
 
-**Design decisions reference:**
-Review {report:coder-decisions.md} to understand the recorded design decisions.
-- Do not flag intentionally documented decisions as FP
-- However, also evaluate whether the design decisions themselves are sound, and flag any problems
-
-**Previous finding tracking (required):**
-- First, inspect the review result previously produced by this step and its timestamped history in the Report Directory, treating the unversioned file as the latest result and the most recent timestamped file as the previous result
-- If "Previous Response" is available, use it only as supporting context; use report history as the source of truth for finding state transitions
-- Assign `finding_id` to each finding and classify current status as `new / persists / resolved / reopened`
-- If status is `persists`, provide concrete unresolved evidence (file/line)
-- Do not drop open findings from the prior report when producing the current report
-
-## Judgment Procedure
-
-1. First, extract prior open findings from report history and preliminarily classify them as `new / persists / resolved / reopened`
-2. Cross-reference the test plan/test scope reports in the Report Directory with the implemented tests
-3. When citing build, test, or functional verification as evidence, record the verified target, what was checked, and the observed result in the report
-4. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
-5. If there is even one blocking issue, judge as REJECT
-6. If an external contract exists and input locations (root body / query / path) are not verified, treat it as a coverage gap by default
+1. Cross-reference the test plan / test scope reports in the Report Directory with the implemented tests
+2. If an external contract exists and input locations (root body / query / path) are not verified, treat it as a coverage gap by default

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

@@ -1,52 +1,34 @@
 Verify existing evidence for tests, builds, and functional checks, then perform final approval.
 
-**Overall workflow verification:**
-1. Check all reports in the report directory and verify overall workflow consistency
-   - Does implementation match the plan?
-   - Were all review step findings properly addressed?
-   - Was the original task objective achieved?
-   - Are prior review findings themselves valid against the task spec, plan, and actual code?
-2. Verify the task spec, plan, and decision history as primary sources
-   - Read `order.md` and extract required behavior and prohibitions
-   - Read `plan.md` and confirm intended approach and scope
-   - Read `coder-decisions.md` and confirm why the implementation moved in that direction
-   - Do not treat prior review conclusions or requirements-review conclusions as authoritative unless they align with all three and the code
-3. Whether each task spec requirement has been achieved
-   - Extract requirements one by one from the task spec
+Procedure:
+1. Open the Knowledge and Policy Source paths with the Read tool and obtain the full content
+2. List every `##` section in each of them (do not cherry-pick)
+3. Match the criteria in each listed section against the diff, execution evidence, and reports
+
+## Step-Specific Additional Procedure
+
+1. Extract each requirement from the task spec one by one
    - If a single sentence contains multiple conditions or paths, split it into the smallest independently verifiable units
      - Example: treat `global/project` as separate requirements
      - Example: treat `JSON override / leaf override` as separate requirements
      - Example: split parallel expressions such as `A and B`, `A/B`, `allow/deny`, or `read/write`
-   - For each requirement, identify the implementing code (file:line)
-   - Verify the code actually fulfills the requirement (read the file, check existing test/build evidence)
+2. For each requirement, identify the implementing code (file:line)
+3. Verify the code actually fulfills the requirement (read the file, check existing test/build evidence)
    - Do not mark a composite requirement as ✅ based on only one side of the cases
-   - Evidence must cover the full content of the requirement row
-   - Do not rely on the plan report's judgment; independently verify each requirement
+   - Do not rely on the plan report or requirements-review judgment; independently verify each requirement
    - If any requirement is unfulfilled, REJECT
 4. Re-evaluate prior review findings
-   - Re-check each `new / persists / resolved` finding against the task spec, `plan.md`, `coder-decisions.md`, and actual code
    - If a finding does not hold in code, classify it as `false_positive`
    - If a finding holds technically but pushes work beyond the task objective or justified scope, classify it as `overreach`
    - Do not leave `false_positive` / `overreach` reasoning implicit
-5. Handling tests, builds, and functional checks
-   - Do not assume this step will rerun commands
-   - Use only evidence available in this run, such as execution logs, reports, or CI results
-   - If evidence is missing, mark the item as unverified rather than successful
-   - If report text conflicts with execution evidence, call out the inconsistency explicitly
-
-**How to read reports:**
-- For reports with the same base name, treat the unversioned file as the latest result and `{report}.{timestamp}` files as history
-- When re-evaluating prior findings, compare the unversioned file with the most recent timestamped history file and verify that the meaning of `new / persists / resolved / reopened` is preserved
-- Treat summary reports as summaries, not as primary evidence. Prefer reports that record execution results, reviewer reports with concrete verification details, and then actual code
-- You may treat `Build Results` / `Test Results` sections in reports that record execution results as primary evidence
-- For `architecture-review`, `qa-review`, `testing-review`, `security-review`, and `requirements-review`, prioritize each report's `Verification Evidence` section when checking evidence
+
+## Report Priority (supervise-specific)
+
+- Do not treat summary reports as primary evidence. Use execution-result reports, reviewer reports with concrete verification details, and actual code in that order
+- You may treat `Build Results` / `Test Results` sections in execution-result reports as primary evidence
+- For `architecture-review`, `qa-review`, `testing-review`, `security-review`, and `requirements-review`, prioritize each report's `Verification Evidence` section
 - Treat each `Verification Evidence` item as supporting evidence only when it states the verified target, what was checked, and observed result. If any part is missing, mark that item as `unverified`
-- Treat reviewer claims such as "confirmed success" as supporting evidence only when they state the verified target, what was checked, and the observed result
 - If items of evidence conflict, prioritize them in this order: `execution-result report > reviewer report with concrete verification details > summary report`
-- If a later report reclassifies an earlier finding as `resolved`, `false_positive`, or `overreach`, decide whether to accept that reclassification by checking it against the task, plan, and code
-
-**Report verification:** Read all reports in the Report Directory and
-check whether any blocking finding remains unresolved and whether those findings are themselves valid.
 
 **Validation output contract:**
 ```markdown

package/builtins/en/facets/instructions/write-tests-first.md

@@ -24,6 +24,11 @@ Refer only to files within the Report Directory shown in the Workflow Context. D
 - Include tests that would catch implementations that incorrectly reuse a response envelope when reading requests
 - Write tests that are expected to pass after implementation is complete (build errors and test failures are expected at this stage)
 
+**Non-executable asset constraints:**
+- Do not create tests that freeze prose, headings, or structure in explanations, guides, README files, or Markdown documentation
+- For docs-only changes, do not add tests unless an explicit executable contract exists
+- Tests are only needed when assets contain contracts tied to code behavior or machine processing, such as CLI examples, config examples, or generated artifacts
+
 **Test execution:**
 - Run tests after creating them to check results
 - Test failures and import errors are expected before implementation (including imports of not-yet-implemented modules)

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

@@ -374,14 +374,14 @@ Don't overlook compromises made to "just make it work."
 | Swallowed errors | Empty `catch {}`, `rescue nil` |
 | Magic numbers | Unexplained `if (status == 3)` |
 
-## Strict TODO Comment Prohibition
+## Unfinished Code Detection
 
-"We'll do it later" never gets done. What's not done now is never done.
+Unfinished-code judgment follows the coding policy. In architecture review, check whether TODO/FIXME comments, empty implementations, or stubs are being used as substitutes for required boundaries, authorization, validation, or contract updates.
 
-TODO comments are immediate REJECT.
+TODO/FIXME without an issue number, external blocker, and removal condition is REJECT.
 
 ```kotlin
-// REJECT - Future-looking TODO
+// REJECT - Authorization check deferred with TODO
 // TODO: Add authorization check by facility ID
 fun deleteCustomHoliday(@PathVariable id: String) {
     deleteCustomHolidayInputPort.execute(input)
@@ -398,12 +398,12 @@ fun deleteCustomHoliday(@PathVariable id: String) {
 }
 ```
 
-Only acceptable TODO cases:
+Acceptable TODO/FIXME cases:
 
 | Condition | Example | Judgment |
 |-----------|---------|----------|
-| External dependency prevents implementation + Issued | `// TODO(#123): Implement after API key obtained` | Acceptable |
-| Technical constraint prevents + Issued | `// TODO(#456): Waiting for library bug fix` | Acceptable |
+| External dependency prevents implementation + issue exists + removal condition documented | `// TODO(#123): Implement after API key obtained` | Acceptable |
+| Technical constraint prevents implementation + issue exists + removal condition documented | `// TODO(#456): Waiting for library bug fix` | Acceptable |
 | "Future implementation", "add later" | `// TODO: Add validation` | REJECT |
 | "No time for now" | `// TODO: Refactor` | REJECT |
 
@@ -429,7 +429,7 @@ When NOT to apply DRY:
 
 ## Spec Compliance Verification
 
-Verify that changes comply with the project's documented specifications.
+Contract-change consistency follows the coding policy. In architecture review, check whether changes contradict documented specifications, types, schemas, or config formats.
 
 Verification targets:
 
@@ -460,10 +460,10 @@ REJECT when these patterns are found:
 
 ## Call Chain Verification
 
-When new parameters/fields are added, verify not just the changed file but also callers.
+Missing wiring after contract changes follows the coding policy. In architecture review, check whether new parameters or fields actually reach callers, producers, and readers instead of staying local to the changed file.
 
 Verification steps:
-1. When finding new optional parameters or interface fields, `Grep` all callers
+1. When finding new optional parameters or interface fields, search all callers
 2. Check if all callers pass the new parameter
 3. If fallback value (`?? default`) exists, verify if fallback is used as intended
 
@@ -471,7 +471,7 @@ Danger patterns:
 
 | Pattern | Problem | Detection |
 |---------|---------|-----------|
-| `options.xxx ?? fallback` where all callers omit `xxx` | Feature implemented but always falls back | grep callers |
+| `options.xxx ?? fallback` where all callers omit `xxx` | Feature implemented but always falls back | Check callers |
 | Tests set values directly with mocks | Don't go through actual call chain | Check test construction |
 | `executeXxx()` doesn't receive `options` it uses internally | No route to pass value from above | Check function signature |
 
@@ -493,12 +493,12 @@ Call chain verification applies not only to "missing wiring" but also to the rev
 
 | Pattern | Problem | Detection |
 |---------|---------|-----------|
-| TTY check when all callers require TTY | Unreachable branch remains | grep all callers' preconditions |
+| TTY check when all callers require TTY | Unreachable branch remains | Check all callers' preconditions |
 | Null guard when callers already check null | Redundant defense | Trace caller constraints |
 | Runtime type check when TypeScript types constrain | Not trusting type safety | Check TypeScript type constraints |
 
 Verification steps:
-1. When finding defensive branches (TTY check, null guard, etc.), grep all callers
+1. When finding defensive branches (TTY check, null guard, etc.), check all callers
 2. If all callers already guarantee the condition, guard is unnecessary → REJECT
 3. If some callers don't guarantee it, keep the guard
 

package/builtins/en/facets/knowledge/cqrs-es.md

@@ -84,6 +84,54 @@ Event Granularity:
 - Appropriate: `ShippingAddressChanged` → Intent is clear
 - Too coarse: `OrderModified` → What changed is unclear
 
+## Event Evolution
+
+Events are persisted contracts. When the current event type changes, old events must still be replayable. Translation of old events belongs in the upcaster / migration layer at the event-store boundary, not in the event type itself or in domain logic.
+
+| Criteria | Judgment |
+|----------|----------|
+| Persisted event type or fields changed with no translation path | REJECT |
+| Current event type keeps aliases or compatibility-only properties for old field names | REJECT. Keep history compatibility in upcasters |
+| Aggregate or apply directly interprets old event shapes | REJECT. Convert to current events before replay |
+| Event carries "previous value" only for compatibility | REJECT. Events represent the fact after it happened |
+| Upcaster converts old payloads to the current event meaning | OK |
+| Tests verify old payloads deserialize into current events through the upcaster | OK |
+
+Responsibility split for event evolution:
+
+| Responsibility | Place |
+|----------------|-------|
+| Current event meaning and fields | Event type |
+| Translation of old payloads | Upcaster / migration layer |
+| State restoration by event replay | Aggregate `apply` |
+| Guarantee that old events can become current events | Upcaster tests |
+
+```kotlin
+// NG - mixing old-field compatibility into the current event type
+data class OrderAssignedEvent(
+    val orderId: String,
+    @JsonAlias("assigneeId")
+    val assigneeIds: List<String>
+)
+
+// OK - current event type represents only the current contract
+data class OrderAssignedEvent(
+    val orderId: String,
+    val assigneeIds: List<String>
+)
+```
+
+```kotlin
+// OK - convert old payloads to current payloads in the upcaster
+when (eventType) {
+    OrderAssignedEvent::class.java.typeName -> {
+        event.moveTextFieldToArray("assigneeId", "assigneeIds")
+    }
+}
+```
+
+Whether to keep old event classes depends on the framework and operations policy. In general, do not treat old classes as normal domain events; treat old serialized type names and payloads as the upcaster input contract and cover them with tests.
+
 ## Command Handlers
 
 | Criteria | Judgment |
@@ -101,6 +149,24 @@ Good Command Handler:
 4. Save emitted events
 ```
 
+### Aggregate Decision Boundary
+
+Aggregates make decisions only from state that can be restored from their event history and facts explicitly carried by commands. They are not the place to interpret, normalize, or authorize boundary-originated inputs.
+
+Validation inside an Aggregate should be limited to facts reproducible by event replay. Other validation should be resolved before command dispatch, and the Aggregate should receive already-resolved facts.
+
+| Decision target | Place |
+|-----------------|-------|
+| Whether the current state allows the operation | Aggregate |
+| Whether the command requester matches the Aggregate owner | Aggregate |
+| Whether HTTP/API input shape is valid | API layer |
+| Parsing external identifiers such as object keys, URLs, or paths | UseCase layer or boundary-side Policy/Verifier |
+| Whether an external identifier belongs to the current user/tenant | UseCase layer or boundary-side Policy/Verifier |
+| Checking Read Models or other Aggregate state | UseCase layer |
+| Checking that an external resource exists | Application-layer integration with the external service |
+
+Example: for an upload-completed command, the Aggregate decides whether the session owner matches the requester and whether the current state can be completed. The storage object key format and whether the key belongs to the current user/tenant are validated in the UseCase layer before sending the command.
+
 ## Projection Design
 
 | Criteria | Judgment |

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

@@ -84,6 +84,7 @@ Third-party UI libraries such as data grids, date pickers, charts, and virtualiz
 ## State Management
 
 Child components do not modify their own state. They bubble events to parent, and parent manipulates state.
+When multiple components read or update the same state, first place that state in their nearest common parent, then pass data and event callbacks down through props.
 
 ```tsx
 // ❌ Child modifies its own state
@@ -110,19 +111,33 @@ Exception (OK for child to have local state):
 | Criteria | Judgment |
 |----------|----------|
 | Unnecessary global state | Consider localizing |
-| Same state managed in multiple places | Needs normalization |
+| Same state managed in multiple places | REJECT. Normalize it in the nearest common parent or shared store |
 | 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 |
 
+### Canonical and Derived State
+
+State should hold canonical values such as user input, server data, and temporary UI state. Display values, aggregates, selection states, sorted results, and grouped results that can be computed from canonical state are derived values and must not be kept as independent state.
+
+| Criteria | Judgment |
+|----------|----------|
+| A value that can always be computed from one state is kept as another state | REJECT |
+| Multiple state fields have invariants that require constant synchronization | REJECT |
+| Display labels, counts, totals, all-selected flags, sorted results, or grouped results are kept as canonical state | REJECT |
+| API sending, persistence, or diffing depends on derived state instead of canonical state | REJECT |
+| Only canonical state is stored, and display, aggregation, and decisions are derived via selectors, render logic, or useMemo | OK |
+| Derived values required by external contracts are generated from canonical state at send or persistence boundaries | OK |
+
 State Placement Guidelines:
 
 | State Nature | Recommended Placement |
 |--------------|----------------------|
 | Temporary UI state (modal open/close, etc.) | Local (useState) |
 | Form input values | Local or form library |
-| Shared across multiple components | Context or state management library |
+| Shared across nearby parent/child or sibling components | Nearest common parent, passed through props |
+| Shared across deep hierarchy or multiple screens | Context or state management library |
 | Server data cache | Data fetching library (TanStack Query, etc.) |
 
 ## Initial load and refetch boundaries

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

@@ -109,12 +109,15 @@ const loadMore = async () => {
 ## 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.
+`useState` inside a custom hook creates a separate state instance for each caller. Calling the same hook from multiple components does not share state.
+When shared state is required, call the hook once in the nearest common parent and pass data through props, or move the state into Context/external store.
 
 | 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 |
+| Multiple components call the same stateful hook independently when they need shared state | REJECT |
 | A hook returns JSX | REJECT |
 
 ## Handling exhaustive-deps

package/builtins/en/facets/output-contracts/frontend-review.md

@@ -11,6 +11,7 @@
 |--------|--------|-------|
 | Component design | ✅ | - |
 | State management | ✅ | - |
+| Canonical and derived state | ✅ | - |
 | Performance | ✅ | - |
 | Accessibility | ✅ | - |
 | Type safety | ✅ | - |

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

@@ -153,6 +153,25 @@ Legacy support criteria:
 - Do not add `.transform()` normalization, `LEGACY_*_MAP` mappings, or `@deprecated` type definitions
 - Support only new values and keep it simple
 
+### Over-Abstracting with Function Objects
+
+AI often turns a small number of concrete branches into config arrays, function objects, and generic loops to make the code look "extensible". The problem is not Strategy itself; the problem is hiding differences in data without naming the concept. A Strategy is useful when it names a domain concept and makes the replacement boundary explicit.
+
+| Pattern | Example | Verdict |
+|---------|---------|---------|
+| Single-use operation config array | Processing `[{ kind, fields, removedFields }]` in a loop | REJECT |
+| Deletions, side effects, or exception cases are hidden in config objects | Readers must inspect config values to find destructive behavior | REJECT |
+| Function object introduced when each branch is only 1-3 lines | `handlers[type]()` adds indirection only | REJECT |
+| Strategy represents a domain concept and clarifies the implementation boundary | `TaxPolicy`, `PaymentMethod`, `RetryStrategy` | OK |
+| Many branches share the same shape and are expected to grow | Consider a handler map | OK |
+
+Verification approach:
+1. Grep usage sites for added arrays, Maps, Strategies, or function objects
+2. If used in only one place, check whether explicit branching would be clearer
+3. Check whether side effects, deleted fields, or compatibility behavior are hidden in config objects
+4. Prefer `when` / `switch` when branch names sufficiently express domain meaning
+5. Allow Strategy when naming the concept improves understanding
+
 ## Premature Caching Strategy Introduction
 
 AI tends to proactively introduce caching mechanisms to "improve" performance. Do not add caching strategies until explicitly requested.

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

@@ -14,6 +14,7 @@ Prioritize correctness over speed, and code accuracy over ease of implementation
 | Boy Scout | Leave touched areas a little better than you found them |
 | Fail Fast | Detect errors early. Never swallow them |
 | Project scripts first | Use project-defined scripts for tool execution. Direct invocation is a last resort |
+| State normalization | Do not keep the same fact in multiple states |
 
 ## No Fallbacks or Default Arguments
 
@@ -183,6 +184,41 @@ const handlers = { A: handleA, B: handleB, C: handleC };
 handlers[type]?.();
 ```
 
+### Do Not Over-Abstract
+
+Use abstraction to reduce duplication and real axes of change, and also to name concepts so the code is easier to understand. Turning a few concrete operations into "config objects + function objects + loops" is not abstraction if it only makes domain differences harder to read.
+
+| Criteria | Judgment |
+|----------|----------|
+| A small number of branches differs by event type, state, or domain concept | Use explicit `when` / `switch` |
+| The same operation with the same argument shape repeats in 3+ places | Consider abstraction |
+| A config array or function object is used in only one place | REJECT. Prefer explicit branching first |
+| Side effects or removed fields cannot be understood without reading config objects | REJECT |
+| Strategy names a domain concept and makes interchangeable implementations explicit | OK |
+| Branch names read as domain concepts | OK |
+
+```typescript
+// ❌ Over-abstracted - readers must inspect both the config array and loop to see behavior
+const operations = [
+  { kind: 'create', normalize: ['owner'], remove: [] },
+  { kind: 'revise', normalize: ['owner'], remove: ['legacyOwner'] },
+]
+for (const operation of operations) {
+  applyOperation(record, operation)
+}
+
+// ✅ When branch meaning matters, make it explicit
+switch (record.kind) {
+  case 'create':
+    normalizeOwner(record)
+    break
+  case 'revise':
+    removeLegacyOwner(record)
+    normalizeOwner(record)
+    break
+}
+```
+
 ### Keep Abstraction Levels Consistent
 
 Within a single function, keep operations at the same granularity. Extract detailed operations into separate functions. Do not mix "what to do" with "how to do it."
@@ -319,11 +355,56 @@ Dependencies and triggers must match the conditions under which the behavior sho
 | Rerun conditions correspond to URL, filters, explicit refresh actions, or other intended behavior | OK |
 | Initialization and later refetch triggers are designed separately | OK |
 
+## Contract Change Consistency
+
+When changing contracts that other code or users depend on — types, interfaces, APIs, config schemas, persistence formats, events, or file formats — keep definitions, producers, consumers, and verification aligned in the same change.
+
+| Criteria | Judgment |
+|----------|----------|
+| Only the contract definition is changed, while callers, producers, or readers are not updated | REJECT |
+| A new argument, field, or config value is added but there is no route to pass it to consumers | REJECT |
+| Fields or values not present in the documented schema/config format are used | REJECT |
+| Mocks, fixtures, or test data return shapes that differ from the real contract | REJECT |
+| The contract change and updates to callers, producers, and tests are made in the same change | OK |
+
 ## State Management
 
 - Confine state to where it is used
 - Children do not modify state directly (notify parents via events)
 - State flow is unidirectional
+- Do not keep derived values that can be computed from canonical state as independent state
+- If multiple fields require constant synchronization, revisit the state model
+
+| Criteria | Judgment |
+|----------|----------|
+| A value that can always be computed from one state is kept as another state | REJECT |
+| Multiple states have invariants that must always stay in sync | REJECT |
+| Persistence, sending, or diffing depends on derived values | REJECT |
+| Only canonical state is stored, and derived values are generated at use sites or boundaries | OK |
+
+## Unfinished Code
+
+Do not leave TODO/FIXME comments, empty implementations, stubs, or commented-out old implementations as substitutes for completed code. Implement what is needed now and delete what is not needed.
+
+| Criteria | Judgment |
+|----------|----------|
+| TODO/FIXME without an issue number, external blocker, and removal condition | REJECT |
+| Authorization, validation, persistence, or error handling is deferred with TODO | REJECT |
+| Empty implementations, `return null`, `pass`, or commented-out old implementations remain | REJECT |
+| An external dependency or known blocker makes implementation impossible now, with issue number and removal condition documented | Acceptable |
+| TODO only for future extension | REJECT |
+
+## Sensitive Information Handling
+
+Do not expose passwords, tokens, API keys, session IDs, auth headers, personal information, or other sensitive data in code, logs, error responses, or test output.
+
+| Criteria | Judgment |
+|----------|----------|
+| Sensitive data is hardcoded in source code or config files | REJECT |
+| Logs, exceptions, error responses, or test snapshots contain sensitive data | REJECT |
+| Whole requests or DTOs are logged and may include sensitive fields | REJECT |
+| Sensitive fields are explicitly omitted or masked | OK |
+| Debug logs include personal data but are assumed disabled in production | Warning. Verify it cannot leak through misconfiguration |
 
 ## Error Handling
 
@@ -486,10 +567,11 @@ Verification approach:
 - **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
 - **Explanatory comments** - Express intent through code. Do not write What/How comments
 - **Unused code** - Do not write "just in case" code
+- **Unfinished code** - Do not leave TODO/FIXME without an issue number, external blocker, and removal condition; do not leave stubs or commented-out old code
 - **any type** - Do not break type safety
 - **Direct mutation of objects/arrays** - Create new instances with spread operators
 - **console.log** - Do not leave in production code
-- **Hardcoded secrets**
+- **Sensitive information exposure** - Do not include sensitive data in hardcoded values, logs, error responses, or test output
 - **Scattered hardcoded contract strings** - File names and config key names must be defined as constants in one place. Scattered literals are prohibited
 - **Scattered try-catch** - Centralize error handling at the upper layer
 - **Unsolicited backward compatibility / legacy support** - Not needed unless explicitly instructed
@@ -497,6 +579,6 @@ Verification approach:
 - **Replaced code surviving after refactoring** - Remove replaced code and exports. Do not keep unless explicitly told to
 - **Workarounds that bypass safety mechanisms** - If the root fix is correct, no additional bypass is needed
 - **Direct tool execution bypassing project scripts** - `npx tool` and similar bypass the lockfile, causing version mismatches. Look for project-defined scripts (npm scripts, Makefile, etc.) first. Only consider direct execution when no script exists
-- **Missing wiring** - When adding new parameters or fields, grep the entire call chain to verify. If callers do not pass the value, `options.xxx ?? fallback` always uses the fallback
+- **Missing wiring** - When adding new parameters or fields, search the entire call chain to verify. If callers do not pass the value, `options.xxx ?? fallback` always uses the fallback
 - **Redundant conditionals** - When if/else calls the same function with only argument differences, unify using ternary operators or spread syntax
-- **Copy-paste patterns** - Before writing new code, grep for existing implementations of the same kind and follow the existing pattern. Do not introduce your own style
+- **Copy-paste patterns** - Before writing new code, search for existing implementations of the same kind and follow the existing pattern. Do not introduce your own style

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

@@ -22,7 +22,9 @@
 
 | Pattern | Verdict |
 |---------|---------|
-| Abandoned TODO/FIXME | Warning |
+| TODO/FIXME without an issue number, external blocker, and removal condition | REJECT |
+| TODO/FIXME with issue number, external blocker, and removal condition | Warning |
+| Empty implementations, stubs, or commented-out old implementations left behind | REJECT |
 | @ts-ignore, @ts-expect-error without reason | Warning |
 | eslint-disable without reason | Warning |
 | Usage of deprecated APIs | Warning |

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

@@ -37,13 +37,15 @@ REJECT without exception if any of the following apply.
 - Unused code ("just in case" code)
 - Direct mutation of objects/arrays
 - Swallowed errors (empty catch blocks)
-- TODO comments (not tracked in an issue)
+- TODO/FIXME without an issue number, external blocker, and removal condition
 - Essentially identical logic duplicated (DRY violation)
 - Method proliferation doing the same thing (should be absorbed by configuration differences)
 - Specific implementation leaking into generic layers (imports and branching for specific implementations in generic layers)
 - Internal implementation exported from public API (infrastructure functions or internal classes exposed publicly)
 - Replaced code/exports surviving after refactoring
 - Missing cross-validation of related fields (invariants of semantically coupled config values left unverified)
+- Missing caller, producer, or test data updates after a contract change
+- Sensitive data exposed in logs, error responses, or test output
 
 A DRY finding is not complete unless the proposed consolidation target is also sound. A consolidation proposal is invalid unless all of the following hold.
 
@@ -59,7 +61,7 @@ Not blocking, but improvement is recommended.
 - Tests coupled to implementation details
 - Overly complex functions/files
 - Unclear naming
-- Abandoned TODO/FIXME (those with issue numbers are acceptable)
+- TODO/FIXME with issue number, external blocker, and removal condition
 - `@ts-ignore` or `eslint-disable` without justification
 
 ### APPROVE
@@ -73,7 +75,7 @@ Always verify facts before raising an issue.
 | Do | Do Not |
 |----|--------|
 | Open the file and check actual code | Assume "it should be fixed already" |
-| Search for call sites and usages with grep | Raise issues based on memory |
+| Search for call sites and usages | Raise issues based on memory |
 | Cross-reference type definitions and schemas | Guess that code is dead |
 | Distinguish generated files (reports, etc.) from source | Review generated files as if they were source code |
 | Verify tool output is readable and uncorrupted | Raise issues based on garbled or abnormal output |
@@ -203,6 +205,36 @@ Do not tolerate problems just because existing code does the same. If existing c
 - "The code itself existed before" is not a valid reason for non-blocking. As long as it is in a changed file, the Boy Scout rule applies
 - If even one issue exists, REJECT. "APPROVE with warnings" or "APPROVE with suggestions" is prohibited
 
+## Basic Review Procedure
+
+Common procedure that every reviewer must follow. Do not duplicate this in individual instructions.
+
+### Referring to Primary Sources
+
+- Use `order.md`, `plan.md`, and the actual code as primary sources
+- Treat decisions from earlier steps (prior review results, planning decisions) as supplementary
+- When information conflicts, prioritize `order.md` / `plan.md` / actual code
+
+### Referring to Design Decisions
+
+- If the implementation step has emitted `coder-decisions.md`, read it and understand the recorded design decisions
+- Do not dismiss intentional decisions as false positives just because they were recorded. Evaluate validity against `order.md` / `plan.md` / actual code
+- If the design decision itself is flawed, raise it
+
+### Tracking Findings from Previous Reviews
+
+- Look in the Report Directory for review reports this step has previously produced, along with their timestamped history
+- Treat the unsuffixed file as the latest result and the most recent `{report-name}.{timestamp}` as the previous result
+- `Previous Response` may be used as supplementary information, but finding state determinations must prioritize the report history
+- Do not drop open findings from the previous report when producing the new report
+- Apply the `finding_id` management rules when classifying each finding as `new` / `persists` / `resolved` / `reopened`
+
+### Final Decision Steps
+
+1. Classify each detected issue as blocking / non-blocking according to the scope rules and decision rules above
+2. When citing test, build, or behavior verification as evidence, record the target, the check, and the result in the report
+3. REJECT if there is at least one blocking issue (`new`, `persists`, or `reopened`)
+
 ## Detecting Circular Arguments
 
 When the same kind of issue keeps recurring, reconsider the approach itself rather than repeating the same fix instructions.