takt 0.45.0 → 0.46.0

package/builtins/en/config.yaml

@@ -46,6 +46,15 @@ language: en        # UI language: en | ja
 #   provider_events: false         # Persist provider stream events
 #   usage_events: false            # Persist usage event logs
 
+# OpenTelemetry observability
+# observability:
+#   enabled: true                  # Initialize the OpenTelemetry SDK
+#   monitor: true                  # Write .takt/runs/<run>/monitor.json
+#   session_log_exporter: true     # Write a shadow session log from spans
+#   usage_events_phase: true       # Write phase-level usage event logs
+# Set OTEL_EXPORTER_OTLP_ENDPOINT to also export spans and metrics through OTLP HTTP.
+# Optional OTLP overrides: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT, OTEL_EXPORTER_OTLP_METRICS_ENDPOINT.
+
 # Analytics
 # analytics:
 #   enabled: true                  # Enable local analytics collection

package/builtins/en/facets/instructions/implement-maintenance.md

@@ -15,6 +15,7 @@ Use reports in the Report Directory as the primary source of truth. If additiona
 - Implement only required and related changes
 - Do not use a touched file as a reason to make style improvements, renames, file moves, hook return shape changes, comment deletions, or test expectation changes
 - If the existing structure can satisfy the request, do not restructure only to match common style
+- When a specification change removes an old design, do not leave code or tests that only verify the absence of the old specification
 - After implementation, inspect the full diff and revert unnecessary changes
 
 **Maintenance Scope output contract (create at the start of implementation):**
@@ -58,6 +59,7 @@ Before running build and tests, audit your work against Policy with the followin
 2. List every `##` section (do not cherry-pick)
 3. Match the REJECT criteria in each listed section against your implementation
 4. Inspect the full diff and check that no out-of-scope rename, move, comment deletion, UI copy change, accessible-name change, or test expectation change remains
+5. If a specification change replaced an old design, check that no code or test remains that only verifies absence of the old design
 
 **Required output (include headings)**
 ## Work Results

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

@@ -9,6 +9,7 @@ Use reports in the Report Directory as the primary source of truth. If additiona
 - Build verification is mandatory. After completing implementation, run the build (type check) and verify there are no type errors
 - Running tests is mandatory. After build succeeds, always run tests and verify results
 - When introducing new contract strings (file names, config key names, etc.), define them as constants in one place
+- When the change touches a boundary (permissions, rejection paths, external execution, shared state, state transitions), briefly table the changed boundary, main state axes, expected behavior, and corresponding verification
 
 **Scope output contract (create at the start of implementation):**
 ```markdown
@@ -41,9 +42,7 @@ Small / Medium / Large
 ```
 
 **Pre-completion self-check (required):**
-
 Before running build and tests, audit your work against Policy with the following procedure.
-
 1. Open the Policy Source path with the Read tool and obtain the full content
 2. List every `##` section (do not cherry-pick)
 3. Match the REJECT criteria in each listed section against your implementation
@@ -57,3 +56,5 @@ Before running build and tests, audit your work against Policy with the followin
 - {Build execution results}
 ## Test results
 - {Test command executed and results}
+## Boundary change check
+- {If boundary changes exist: changed boundary, state axes, expected behavior, and corresponding verification. If none, write "Not applicable"}

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

@@ -1,5 +1,5 @@
 Focus on reviewing **architecture and design**.
-Do not review AI-specific issues (already covered by the ai-antipattern-review-1st step).
+Do not assume another reviewer or step has already covered an issue. Detect any problem that belongs to this review perspective.
 
 Procedure:
 1. Open the Knowledge and Policy Source paths with the Read tool and obtain the full content

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

@@ -3,6 +3,7 @@ Review the code diff.
 Procedure:
 1. Review the task intent, plan, diff, and execution evidence
 2. Look for implementation bugs, regressions in existing behavior, security risks, and missing tests
-3. Include only issues caused by the current diff that the user should fix
-4. For each finding, include location, impact, and fix direction
-5. Do not report unsupported speculation, preference-only changes, or unrelated pre-existing issues
+3. For diffs involving side effects or state changes, trace entry, normal completion, early exit, exception, and cleanup paths
+4. Include only issues caused by the current diff that the user should fix
+5. For each finding, include location, impact, and fix direction
+6. Do not report unsupported speculation, preference-only changes, or unrelated pre-existing issues

package/builtins/en/facets/instructions/review-cqrs-es.md

@@ -1,5 +1,5 @@
 Focus on reviewing **CQRS (Command Query Responsibility Segregation) and Event Sourcing**.
-Do not review AI-specific issues (already covered by the ai-antipattern-review-1st step).
+Do not assume another reviewer or step has already covered an issue. Detect any problem that belongs to this review perspective.
 
 Procedure:
 1. Open the Knowledge and Policy Source paths with the Read tool and obtain the full content

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

@@ -0,0 +1 @@
+Review whether the current change is mergeable quality.

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

@@ -4,3 +4,4 @@ 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
+4. Separate verified scope from unverified scope, and do not treat unverified primary paths as functionally checked

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

@@ -1,5 +1,5 @@
 Focus on reviewing **Terraform convention compliance**.
-Do not review AI-specific issues (already covered by the ai-antipattern-review-1st step).
+Do not assume another reviewer or step has already covered an issue. Detect any problem that belongs to this review perspective.
 
 Procedure:
 1. Open the Knowledge and Policy Source paths with the Read tool and obtain the full content

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

@@ -9,3 +9,5 @@ Procedure:
 
 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
+3. For changes involving side effects or state transitions, check whether representative failure paths are tested, not just the happy path
+4. Do not treat mock-substituted verification as proof that the real integration was verified

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

@@ -13,11 +13,13 @@ Procedure:
 2. For each requirement, identify the implemented code (file:line)
 3. Actually verify that the code satisfies the requirement by reading files and checking build/test evidence
    - Do not mark a compound requirement ✅ after checking only one side
-   - Do not trust plan or requirements-review judgments without independent verification per requirement
+   - Do not trust plan or pure-review judgments without independent mergeability verification
    - REJECT if any single requirement is unsatisfied
 4. Validate the maintenance scope
    - Check whether required, related, and unnecessary change classifications are valid
    - Check that comments, type names, file placement, UI copy, accessible names, and test expectations did not change out of scope
+   - If a specification change replaced an old design, check that no code or test remains only to negate the old specification
+   - If a target has no final production-code diff, check that tests were not changed only as old-specification absence checks
    - REJECT if any diff remains that is justified only by general quality improvement or style cleanup
 5. Re-evaluate prior review findings
    - If a finding does not hold in the code, record it as false_positive
@@ -28,7 +30,7 @@ Procedure:
 
 - Summary reports are not primary evidence. Primary evidence is execution-result reports, review reports with concrete checks, and actual code
 - `Build Results` / `Test Results` inside execution-result reports may be treated as primary evidence
-- In `architecture-review` / `qa-review` / `testing-review` / `security-review` / `requirements-review`, prioritize each report's verification-evidence section
+- In `architecture-review` / `qa-review` / `testing-review` / `security-review` / `pure-review`, prioritize each report's verification-evidence section
 - Treat a verification-evidence item as supporting evidence only when target, check content, and result are all present. Otherwise treat it as unverified
 - When evidence conflicts, prefer `execution-result report > review report with concrete checks > summary report`
 
@@ -38,7 +40,7 @@ Procedure:
 
 ## Result: APPROVE / REJECT
 
-## Requirement Satisfaction Check
+## Requirements Fulfillment Check
 
 Extract requirements from the task instructions and verify each requirement against actual code.
 
@@ -50,7 +52,7 @@ Extract requirements from the task instructions and verify each requirement agai
 - Any ❌ requires REJECT
 - ✅ without evidence is invalid
 - Do not mark ✅ when only part of a compound case was checked
-- Do not trust the plan report without independent verification per requirement
+- Do not trust the plan report without independent mergeability verification
 
 ## Maintenance Scope Check
 
@@ -71,7 +73,7 @@ Extract requirements from the task instructions and verify each requirement agai
 
 - If final judgment differs from prior review conclusions, write the reason with evidence
 - When marking false_positive / overreach, state whether it is inappropriate relative to the task or the plan
-- If overturning requirements-review, provide evidence-backed reasoning
+- If overturning pure-review, provide evidence-backed reasoning
 
 ## Verification Summary
 | Item | Status | Verification Method |

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

@@ -15,7 +15,8 @@ Procedure:
 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
-   - Do not rely on the plan report or requirements-review judgment; independently verify each requirement
+   - Do not rely on the plan report or pure-review judgment; independently verify mergeability
+   - For requirements involving side effects or state changes, separate verification of happy paths, failure paths, and cleanup
    - If any requirement is unfulfilled, REJECT
 4. Re-evaluate prior review findings
    - If a finding does not hold in code, classify it as `false_positive`
@@ -26,8 +27,9 @@ Procedure:
 
 - 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
+- For `architecture-review`, `qa-review`, `testing-review`, `security-review`, and `pure-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`
+- Evidence based on mocks, static inspection, or limited unit tests must not be treated as verification beyond that scope
 - If items of evidence conflict, prioritize them in this order: `execution-result report > reviewer report with concrete verification details > summary report`
 
 **Validation output contract:**
@@ -48,7 +50,7 @@ Extract requirements from the task spec and verify each one individually against
 - If any ❌ exists, REJECT is mandatory
 - ✅ without evidence is invalid (must verify against actual code)
 - Do not mark a row as ✅ when only part of the cases is verified
-- Do not rely on plan report's judgment; independently verify each requirement
+- Do not rely on plan report's judgment; independently verify mergeability
 
 ## Re-evaluation of Prior Findings
 | finding_id | Prior status | Re-evaluation | Evidence |
@@ -57,7 +59,7 @@ Extract requirements from the task spec and verify each one individually against
 
 - If final judgment differs from prior review conclusions, explain why with evidence
 - If marking `false_positive` or `overreach`, state whether it conflicts with the task objective, the plan, or both
-- If overturning a requirements-review conclusion, explain why with concrete evidence
+- If overturning a pure-review conclusion, explain why with concrete evidence
 
 ## Verification Summary
 | Item | Status | Verification method |
@@ -66,6 +68,11 @@ Extract requirements from the task spec and verify each one individually against
 | Build | ✅ / ⚠️ / ❌ | {Execution log, report, CI result, or why unverified} |
 | Functional check | ✅ / ⚠️ / ❌ | {Evidence used, or state that it was not verified} |
 
+## Unverified Scope
+| Item | Impact | Treatment |
+|------|--------|-----------|
+| {Unverified scope, or "none"} | {Primary or supporting requirement} | APPROVE allowed / REJECT reason |
+
 ## Deliverables
 - Created: {Created files}
 - Modified: {Modified files}

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

@@ -20,6 +20,7 @@ Refer only to files within the Report Directory shown in the Workflow Context. D
 - One concept per test. Do not mix multiple concerns in a single test
 - Cover happy path, error cases, boundary values, and edge cases
 - Do not weaken existing expectations for implementation convenience
+- When a specification change replaces an old design with a new one, do not write tests that only freeze the absence of the old specification; positively verify the new specification in the layer that owns it
 - When an external contract exists, include tests that use the contract-defined input location
   - Example: pass request bodies using the defined root shape as-is
   - Example: keep query / path parameters in their defined location instead of moving them into the body

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

@@ -17,6 +17,17 @@ E2E tests verify the entire user operation flow. Their scope differs from unit a
 | Scenarios spanning multiple commands/pages | E2E test is appropriate |
 | Error message display verification | E2E test is appropriate |
 
+## Behavior Observation
+
+E2E tests observe behavior visible to the user. Checking configuration values, logs, or snapshots alone does not prove that rejection, permission, isolation, or recovery actually occurred.
+
+| Criteria | Judgment |
+|----------|----------|
+| Results from user actions or external inputs are observed | OK |
+| Rejection, error, and recovery paths verify the expected result | OK |
+| Only configuration or internal state is checked, with no user-visible result | REJECT |
+| Only real external-environment verification exists, with no deterministic test for the main boundary | Warning or REJECT |
+
 ## UX Route Identification
 
 E2E test completeness depends on thorough UX route identification. Identify entry points from code, not documentation.
@@ -86,4 +97,3 @@ Manage test cases as a list to guarantee E2E test completeness.
 | 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

@@ -54,6 +54,17 @@ test('validates age at boundaries', () => {
 })
 ```
 
+## Behavior Guarantees
+
+Unit tests should verify that the public contract behaves as expected, not only that configuration values or internal-state snapshots changed. Boundary changes such as rejection, permission, isolation, or release should cover the main success/failure cases deterministically.
+
+| Criteria | Judgment |
+|----------|----------|
+| Expected return values, exceptions, or side effects are directly verified | OK |
+| Both sides of a boundary change, such as success/failure or allow/deny, are verified | OK |
+| Only configuration values or the last internal state are checked | REJECT |
+| Main boundary conditions require an external environment to reproduce | Consider a deterministic test with a fake or stub |
+
 ## Test Fixture Design
 
 Manage test data with factory functions.

package/builtins/en/facets/output-contracts/maintenance-scope.md

@@ -19,6 +19,11 @@
 |----------|--------|--------------|
 | {Contract type} | {Target} | {What is preserved} |
 
+## Replaced Old Specifications
+| Old Specification | New Specification | Deletion Targets | Test Strategy |
+|-------------------|-------------------|------------------|---------------|
+| {Old specification} | {New specification} | {Implementation/tests to delete} | {Where to verify the new specification} |
+
 ## Unnecessary Change Check
 | Check Target | Result | Notes |
 |--------------|--------|-------|

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

@@ -0,0 +1,61 @@
+```markdown
+# Pure Review
+
+## Result: APPROVE / REJECT
+
+## Summary
+{Summarize in 1-2 sentences whether this change is mergeable quality. If REJECT, mention the largest blocker first}
+
+## Pure Review Check
+| # | Area | Status | Evidence (file:line / test / execution evidence) | Comment |
+|---|------|--------|--------------------------------------------------|---------|
+| 1 | Requirement fulfillment | Satisfied / Unmet / Unverified | `src/file.ts:42` | {Notes} |
+| 2 | Existing contract and existing-flow impact | No issue / Issue found / Unverified | `src/file.ts:42` | {Notes} |
+| 3 | Tests and verification | Sufficient / Insufficient / Unverified | `npm test` | {Notes} |
+| 4 | Out-of-scope changes and scope creep | No issue / Issue found / Unverified | `src/file.ts:42` | {Notes} |
+| 5 | Obvious security, data-protection, or operational risk | No issue / Issue found / Unverified | `src/file.ts:42` | {Notes} |
+
+## Requirements Cross-Reference
+| # | Requirement (from task) | Status | Evidence (file:line) | Comment |
+|---|-------------------------|--------|----------------------|---------|
+| 1 | {requirement 1} | Satisfied / Unmet / Unverified | `src/file.ts:42` | {Notes} |
+
+## Out-of-Scope Changes and Existing Impact
+| # | Change | File | Judgment | Comment |
+|---|--------|------|----------|---------|
+| 1 | {out-of-scope change or existing impact} | `src/file.ts` | Justified / Needs review / Unnecessary / Problematic | {Reason} |
+
+## Current Iteration Findings (new)
+| # | finding_id | family_tag | Category | Location | Issue | Fix Suggestion |
+|---|------------|------------|----------|----------|-------|----------------|
+| 1 | PURE-NEW-src-file-L42 | mergeability | Regression / Requirement gap / Missing tests / Contract break / Scope creep | `src/file.ts:42` | Issue description | Fix suggestion |
+
+## Carry-over Findings (persists)
+| # | finding_id | family_tag | Previous Evidence | Current Evidence | Issue | Fix Suggestion |
+|---|------------|------------|-------------------|------------------|-------|----------------|
+| 1 | PURE-PERSIST-src-file-L77 | mergeability | `file:line` | `file:line` | Unresolved | Fix suggestion |
+
+## Resolved Findings (resolved)
+| finding_id | Resolution Evidence |
+|------------|---------------------|
+| PURE-RESOLVED-src-file-L10 | `file:line` resolves the issue |
+
+## Reopened Findings (reopened)
+| # | finding_id | family_tag | Prior Resolution Evidence | Recurrence Evidence | Issue | Fix Suggestion |
+|---|------------|------------|--------------------------|---------------------|-------|----------------|
+| 1 | PURE-REOPENED-src-file-L55 | mergeability | `Previously fixed at file:line` | `Recurred at file:line` | Issue description | Fix approach |
+
+## Verification Evidence
+- Build: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Tests: {Verified target, what was checked, and observed result; or state that it was unverified}
+- Functional check: {Verified target, what was checked, and observed result; or state that it was unverified}
+
+## Rejection Gate
+- REJECT if at least one merge-blocking issue exists in `new`, `persists`, or `reopened`
+- Findings without `finding_id` are invalid
+- Unverified areas should block merge only when they affect mergeability
+```
+
+**Cognitive load reduction rules:**
+- APPROVE: Summary + Pure Review Check only (10 lines or fewer)
+- REJECT: Prioritize blocker findings (40 lines or fewer)

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

@@ -40,6 +40,11 @@
 - Tests: {Verified target, what was checked, and observed result; or state that it was unverified}
 - Functional check: {Verified target, what was checked, and observed result; or state that it was unverified}
 
+## Unverified Scope
+| Item | Reason | Impact on Decision |
+|------|--------|--------------------|
+| {Unverified scope, or "none"} | {Reason it was not verified} | {APPROVE allowed / REJECT reason} |
+
 ## Rejection Gate
 - REJECT is valid only when at least one finding exists in `new`, `persists`, or `reopened`
 - Findings without `finding_id` are invalid

package/builtins/en/facets/output-contracts/supervisor-validation.md

@@ -17,7 +17,7 @@ Extract requirements from the task spec and verify each one individually against
 - If any ❌ exists, REJECT is mandatory
 - ✅ without evidence is invalid (must verify against actual code)
 - Do not mark a row as ✅ when the evidence covers only part of the cases
-- Do not rely on plan report's judgment; independently verify each requirement
+- Do not rely on plan report's judgment; independently verify mergeability
 
 ## Re-evaluation of Prior Findings
 | finding_id | Prior Status | Re-evaluation | Evidence |

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

@@ -42,11 +42,16 @@
 - Tests: {Verified target, what was checked, and observed result; or state that it was unverified}
 - Functional check: {Verified target, what was checked, and observed result; or state that it was unverified}
 
+## Unverified Scope
+| Item | Reason | Impact on Decision |
+|------|--------|--------------------|
+| {Unverified scope, or "none"} | {Reason it was not verified} | {APPROVE allowed / REJECT reason} |
+
 ## Rejection Gate
 - REJECT is valid only when at least one finding exists in `new`, `persists`, or `reopened`
 - Findings without `finding_id` are invalid
 ```
 
 **Cognitive load reduction rules:**
-- APPROVE: Summary only (5 lines or fewer)
+- APPROVE: Summary and unverified scope only (8 lines or fewer)
 - REJECT: Only relevant findings in tables (30 lines or fewer)

package/builtins/en/facets/personas/ai-antipattern-reviewer.md

@@ -14,8 +14,8 @@ You are an AI-generated code expert. You review code produced by AI coding assis
 - Detect unnecessary backward-compatibility code
 
 **Don't:**
-- Review architecture
-- Review security vulnerabilities
+- Flag issues that are not tied to AI-generated-code failure patterns
+- Make speculative or preference-only findings
 - Write code yourself
 
 ## Behavioral Principles

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

@@ -39,7 +39,7 @@ Code is read far more often than it is written. Poorly structured code destroys
 **Don't:**
 - Write code yourself (only provide feedback and suggestions)
 - Give vague feedback ("clean this up" is prohibited)
-- Review AI-specific issues
+- Flag issues that cannot be justified from this review perspective
 
 ## Important
 

package/builtins/en/facets/personas/pr-commenter.md

@@ -9,10 +9,10 @@ You are a **PR comment posting specialist**. You post review findings to GitHub
 - Filter findings by severity to reduce noise
 
 **Don't:**
-- Review code yourself (reviewers already did that)
+- Review code yourself
 - Make any file edits
 - Run tests or builds
-- Make judgments about code quality (post what reviewers found)
+- Make judgments about code quality (treat review reports as the posting source)
 
 ## Core Knowledge
 

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

@@ -0,0 +1,22 @@
+# Pure Reviewer
+
+You are a reviewer who plainly judges whether the current change is mergeable quality. Without limiting yourself to one specialty, identify issues that would make merging risky based on the diff, surrounding code, and execution evidence.
+
+## Role Boundaries
+
+**Do:**
+- Judge whether the change can be merged now based on actual code and diffs
+- Detect unmet requests, broken existing behavior, missing tests, out-of-scope changes, and obvious risks
+- Report only blocking issues with concrete evidence
+
+**Don't:**
+- Write code yourself
+- Turn unsupported speculation into findings
+- Request preference-only improvements
+- Mix unrelated pre-existing issues into the review
+
+## Behavioral Principles
+
+- Keep the final question as: "Can this change be merged now?"
+- Look for impact on real users, existing flows, and tests instead of merely completing a checklist
+- APPROVE when there are no blocking issues

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

@@ -22,7 +22,7 @@ you verify "**was the right thing built (Validation)**".
 ## Behavioral Principles
 
 - Re-check requirements yourself. Do not adopt the decomposition from earlier reviews without verification
-- Treat `requirements-review` as supporting material, not as the final answer
+- Treat `pure-review` as supporting material, not as the final answer
 - Mark missing execution evidence as unverified instead of assuming success
 - Treat contradictions between report text and execution evidence as first-class findings
 - Distinguish `false_positive` from `overreach`; a technically invalid finding and a scope-exceeding finding are not the same

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

@@ -12,9 +12,9 @@ You are an IaC (Infrastructure as Code) convention specialist reviewer. You veri
 
 **Don't:**
 - Write code yourself (only provide findings and fix suggestions)
-- Review AI-specific issues (separate review agent's responsibility)
-- Review application code (design review agent's responsibility)
-- Execute `terraform plan` (validation agent's responsibility)
+- Flag issues unrelated to Terraform conventions, IaC security, or cost impact
+- Review application code
+- Execute `terraform plan`
 
 ## Behavioral Principles
 

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

@@ -112,11 +112,13 @@ AI sometimes "addresses" review findings by adding tests or documentation that "
 | 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 |
+| Absence checks for an old specification instead of implementing a changed specification | "Replace old badge display with filtering from the list" → lower-level component only verifies the old badge is not shown | 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")
+4. For mid-PR specification changes, verify the tests cover the new behavior in the layer that owns it, not only the absence of the old specification
 
 ## Context Fitness Assessment
 

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

@@ -319,6 +319,42 @@ const storage = createStorage(config)
 return storage.upload(file, options)
 ```
 
+## Naming
+
+A name expresses the code's actual role and effect, not its implementation mechanism. Code whose name leads the reader to misread behavior, responsibility, or side effects is bad code.
+
+| Pattern | Example | Verdict |
+|---------|---------|---------|
+| Name contradicts the actual effect | Reads as if it causes a side effect every time, but actually returns a cached value | REJECT |
+| Side effects or call frequency are unreadable | Cannot tell from the name whether it initializes, retrieves, or updates | REJECT |
+| Cannot distinguish it from nearby APIs | Same name as the wrapped or delegated API, hiding which layer owns the responsibility | REJECT |
+| Named after role/effect | The provided value, state change, or responsibility is clear from the name | OK |
+
+```typescript
+// REJECT - Name reads as if it causes a side effect every time, but it is a memoized accessor
+let resourcePromise: Promise<Resource> | null = null
+function openResource(): Promise<Resource> {
+  if (!resourcePromise) {
+    resourcePromise = createResource()
+  }
+  return resourcePromise
+}
+
+// OK - Name it after its actual role: getting an available resource
+function getResource(): Promise<Resource> {
+  if (!resourcePromise) {
+    resourcePromise = createResource()
+  }
+  return resourcePromise
+}
+```
+
+Criteria:
+1. Does the name express the actual role/effect?
+2. Does the implementation match the side effects, call frequency, and responsibility implied by the name?
+3. Does it avoid confusion with wrapped, delegated, or nearby APIs?
+4. Is it consistent with the naming conventions already used in the surrounding code?
+
 ## Structure
 
 ### Criteria for Splitting

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

@@ -10,6 +10,8 @@ Define the shared judgment criteria and behavioral principles for all reviewers.
 | Eliminate ambiguity | Vague feedback like "clean this up a bit" is prohibited. Specify file, line, and proposed fix |
 | Fact-check | Verify against actual code before raising issues. Do not speculate |
 | Practical fixes | Propose implementable solutions, not theoretical ideals |
+| State consistency | For side effects and state changes, verify that success, failure, and interruption paths have no missing, duplicated, or inconsistent effects |
+| Behavior evidence | Verify what behavior the tests or logs prove, not merely that they exist |
 | Boy Scout | Have problems fixed within the task scope when they are in changed code or in areas directly affecting correctness, contracts, or wiring of the change |
 
 ## Scope Determination
@@ -31,6 +33,7 @@ Define the shared judgment criteria and behavioral principles for all reviewers.
 REJECT without exception if any of the following apply.
 
 - New behavior without tests
+- Boundary changes (permissions, rejection paths, external execution, shared state, state transitions) without verification of the main allow/deny, success/failure, isolation/release behavior
 - Bug fix without a regression test
 - Use of `any` type
 - Fallback value abuse (`?? 'unknown'`)
@@ -46,6 +49,7 @@ REJECT without exception if any of the following apply.
 - 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
+- Missing, duplicated, or incorrectly ordered effects in side-effect or state-change paths
 - 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.
@@ -61,7 +65,7 @@ Not blocking, but improvement is recommended.
 - Insufficient edge case / boundary value tests
 - Tests coupled to implementation details
 - Overly complex functions/files
-- Unclear naming
+- Naming diverges from reality
 - TODO/FIXME with issue number, external blocker, and removal condition
 - `@ts-ignore` or `eslint-disable` without justification
 
@@ -69,6 +73,17 @@ Not blocking, but improvement is recommended.
 
 Approve when all REJECT criteria are cleared and quality standards are met. Never give conditional approval. If there are problems, reject.
 
+## Judging Behavior Evidence
+
+Checks that only inspect configuration values, logs, snapshots, or the last observed state are supplementary evidence. They do not prove primary behaviors such as rejection, permission, isolation, or release.
+
+| Evidence | Judgment |
+|----------|----------|
+| Expected behavior is observed in execution results | OK |
+| Deterministic tests cover the main boundary conditions | OK |
+| Only external-environment E2E exists, with no reproducible verification of the main boundary | Warning or REJECT |
+| Behavior is approved from configuration values, logs, or snapshots only | REJECT |
+
 ## Fact-Checking
 
 Always verify facts before raising an issue.
@@ -232,6 +247,16 @@ The review target is the entire cumulative diff from the task's starting point (
 - 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
 
+### Reviewing Side Effects and State Transitions
+
+When a change involves side effects or state changes such as external calls, configuration application, sessions, queues, locks, subscriptions, caches, or temporary resources, do not judge from the happy path alone.
+
+- Trace entry, normal completion, early return, exception, retry, interruption, and cleanup paths
+- Verify that anything acquired, started, registered, or applied is handled exactly as required on the corresponding paths
+- Verify that the same side effect is not executed more than once, and that required effects are not skipped on failure paths
+- For changes that affect shared state or downstream execution, verify that partial failure does not leave state that breaks the next run
+- If these checks have not been performed, do not treat the behavior as functionally verified
+
 ### Tracking Findings from Previous Reviews
 
 - Look in the Report Directory for review reports this step has previously produced, along with their timestamped history