takt 0.40.0 → 0.41.0

package/builtins/en/config.yaml

@@ -74,6 +74,8 @@ language: en        # UI language: en | ja
 # provider_options:
 #   codex:
 #     network_access: true
+#   opencode:
+#     variant: high
 #   claude:
 #     sandbox:
 #       allow_unsandboxed_commands: true

package/builtins/en/facets/instructions/_system/fallback-notice.md

@@ -0,0 +1,16 @@
+## Notice: This Step Is A Fallback Execution
+
+The previous step execution was interrupted by an external condition ({{fallback_reason}}) and is being retried in a new session.
+The previous session context is not carried into this session.
+
+- Interrupted step: {{step_name}}
+- Original iteration: {{original_iteration}}
+- Interruption reason: {{fallback_reason_detail}}
+- Previous provider/model: {{previous_provider}} / {{previous_model}}
+- Current provider/model: {{current_provider}} / {{current_model}}
+
+Previous work that remains on disk as files or reports is available, but chat context is not. Rebuild context as needed:
+
+1. Inspect existing reports under {{report_dir}}
+2. Inspect the latest commit or working tree diff
+3. If context is still missing, execute from the step instruction

package/builtins/en/facets/instructions/ai-antipattern-fix.md

@@ -1,16 +1,9 @@
 **This is AI Review iteration #{step_iteration}.**
-Use reports in the Report Directory as the primary source of truth. If additional context is needed, you may consult Previous Response and conversation history as secondary sources (Previous Response may be unavailable). If information conflicts, prioritize reports in the Report Directory and actual file contents.
-
-From the 2nd iteration onward, it means the previous fixes were not actually applied.
-**Your belief that they were "already fixed" is incorrect.**
 
-**First, acknowledge the following:**
-- The files you thought were "fixed" are actually not fixed
-- Your understanding of the previous work is wrong
-- You need to rethink from scratch
+Use reports in the Report Directory as the primary source of truth. If additional context is needed, you may consult Previous Response and conversation history as secondary sources (Previous Response may be unavailable). If information conflicts, prioritize reports in the Report Directory and actual file contents.
 
 **Required actions:**
-1. Open all flagged files with the Read tool (discard assumptions and verify the facts)
+1. Open all flagged files with the Read tool
 2. Search for the problem areas with grep to confirm they exist
 3. Fix the confirmed issues with the Edit tool
 4. Run tests to verify
@@ -20,11 +13,6 @@ From the 2nd iteration onward, it means the previous fixes were not actually app
 - NG: "It has already been fixed"
 - OK: "After checking file X at L123, I found issue Y and fixed it to Z"
 
-**Strictly prohibited:**
-- Reporting "already fixed" without opening the file
-- Making judgments based on assumptions
-- Leaving issues that the AI Reviewer REJECTed unresolved
-
 **Handling "no fix needed" (required)**
 - Do not judge "no fix needed" unless you can show verification results for the target file for each AI Review finding
 - If the finding relates to "generated output" or "spec synchronization", output the tag corresponding to "unable to determine" unless you can verify the source/spec

package/builtins/en/facets/instructions/ai-antipattern-review.md

@@ -3,15 +3,9 @@
 On the first iteration, review comprehensively and report all issues that need to be flagged.
 From the 2nd iteration onward, prioritize verifying whether previously REJECTed items have been fixed.
 
-Review the code for AI-specific issues:
-- Verification of assumptions
-- Plausible but incorrect patterns
-- Compatibility with the existing codebase
-- Scope creep detection
-- Scope shrinkage detection (missing task requirements)
+Review the diff for AI-specific issues.
 
-## Judgment Procedure
-
-1. Review the change diff and detect issues based on the AI-specific criteria above
-2. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
-3. If there is even one blocking issue, judge as REJECT
+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

package/builtins/en/facets/instructions/implement-after-tests.md

@@ -42,13 +42,12 @@ Small / Medium / Large
 ```
 
 **Pre-completion self-check (required):**
-Before running build and tests, verify the following:
-- If new parameters/fields were added, grep to confirm they are actually passed from call sites
-- For any `??`, `||`, `= defaultValue` usage, confirm fallback is truly necessary
-- Verify no replaced code/exports remain after refactoring
-- Verify no features outside the task specification were added
-- Verify no if/else blocks call the same function with only argument differences
-- Verify new code matches existing implementation patterns (API call style, type definition style, etc.)
+
+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
 
 **Required output (include headings)**
 ## Work results

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

@@ -41,13 +41,12 @@ Small / Medium / Large
 ```
 
 **Pre-completion self-check (required):**
-Before running build and tests, verify the following:
-- If new parameters/fields were added, grep to confirm they are actually passed from call sites
-- For any `??`, `||`, `= defaultValue` usage, confirm fallback is truly necessary
-- Verify no replaced code/exports remain after refactoring
-- Verify no features outside the task specification were added
-- Verify no if/else blocks call the same function with only argument differences
-- Verify new code matches existing implementation patterns (API call style, type definition style, etc.)
+
+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
 
 **Required output (include headings)**
 ## Work results

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

@@ -1,39 +1,7 @@
 Focus on reviewing **architecture and design**.
 Do not review AI-specific issues (already covered by the ai-antipattern-review-1st step).
 
-**Review criteria:**
-- Structural and design validity
-- Modularization (high cohesion, low coupling, no circular dependencies)
-- Functionalization (single responsibility per function, operation discoverability, consistent abstraction level)
-- Code quality
-- Appropriateness of change scope
-- Test coverage
-- Dead code
-- Call chain verification
-- Scattered hardcoding of contract strings (file names, config key names)
-
-
-**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 previous open findings and preliminarily classify as `new / persists / resolved / reopened`
-2. Review the change diff and detect issues based on the architecture and design criteria above
-   - Cross-check changes against REJECT criteria tables defined in knowledge
-   - If you find a DRY violation, require it to be fixed
-   - Before proposing a fix, verify that the consolidation target fits existing responsibility boundaries, contracts, and public API shape
-   - If you require a new wrapper, helper, or public API, explain why that abstraction target is the natural one
-   - If the proposed abstraction goes beyond the task spec or plan, state why the additional scope is necessary and justified
-   - When citing build, test, or functional verification as evidence, record the verified target, what was checked, and the observed result in the report
-3. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
-4. If there is even one blocking issue (`new`, `persists`, or `reopened`), judge as REJECT
+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

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

@@ -1,25 +1,9 @@
-Review the changes from the perspective of CQRS (Command Query Responsibility Segregation) and Event Sourcing.
-AI-specific issue review is not needed (already covered by the ai-antipattern-review-1st step).
+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).
 
-**Review criteria:**
-- Aggregate design validity
-- Event design (granularity, naming, schema)
-- Command/Query separation
-- Projection design
-- Eventual consistency considerations
+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
 
-**Note**: If this project does not use the CQRS+ES pattern,
-review from a general domain design perspective instead.
-
-
-**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
-
-## Judgment Procedure
-
-1. Review the change diff and detect issues based on the CQRS and Event Sourcing criteria above
-   - Cross-check changes against REJECT criteria tables defined in knowledge
-2. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
-3. If there is even one blocking issue, judge as REJECT
+**Note:** If this project does not use the CQRS+ES pattern, review from a general domain design perspective instead.

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

@@ -1,34 +1,8 @@
-Review the changes from a frontend development perspective.
+Focus on reviewing **frontend development**.
 
-**Review criteria:**
-- Design fidelity (top priority when a design reference is provided)
-- Component design (separation of concerns, granularity)
-- State management (local vs. global decisions)
-- Performance (re-renders, memoization)
-- Accessibility (keyboard navigation, ARIA)
-- Data fetching patterns
-- Reachability wiring for user-facing features (routes, entry paths, launch conditions)
-- TypeScript type safety
+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
 
-**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.
-
-
-**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
-
-## Judgment Procedure
-
-1. Review the change diff and detect issues based on the frontend development criteria above
-   - Cross-check changes against REJECT criteria tables defined in knowledge
-   - When new screens or user-facing features are added, verify that entry points and caller wiring were updated as well
-2. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
-3. If there is even one blocking issue, judge as REJECT
+**Note:** If this project does not include a frontend, proceed as no issues found.

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

@@ -1,32 +1,6 @@
-Review the changes from a quality assurance perspective.
+Focus on reviewing **quality assurance (test strategy, coverage, error handling, maintainability)**.
 
-**Review criteria:**
-- Test coverage and quality
-- Test strategy (unit/integration/E2E)
-- Error handling
-- Logging and monitoring
-- Maintainability
-
-
-**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 previous open findings and preliminarily classify as `new / persists / resolved / reopened`
-2. Review the change diff and detect issues based on the quality assurance criteria above
-   - Cross-check changes against REJECT criteria tables defined in knowledge
-   - Even if tests pass, verify whether any additional change outside the task or plan is justified
-   - If review-driven follow-up changes expand the design, evaluate whether that extra change is actually necessary
-   - When citing build, test, or functional verification as evidence, record the verified target, what was checked, and the observed result in the report
-3. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
-4. If there is even one blocking issue (`new`, `persists`, or `reopened`), judge as REJECT
+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

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

@@ -1,25 +1,11 @@
-Review the changes from a requirements fulfillment perspective.
+Focus on reviewing **requirements fulfillment**.
 
-**Review criteria:**
-- Whether each requested requirement has been implemented
-- Whether implicit requirements (naturally expected behaviors) are satisfied
-- Whether changes outside the scope (scope creep) have crept in
-- Whether there are any partial or missing implementations
+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
 
-
-**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
+## Step-Specific Additional Procedure
 
 1. Read `order.md`, the task body, `plan.md`, and `coder-decisions.md`, then extract the requirements one by one
 2. If a sentence contains multiple conditions or paths, split it into the smallest independently verifiable units
@@ -29,7 +15,3 @@ Review {report:coder-decisions.md} to understand the recorded design decisions.
    - Do not mark a row `satisfied` without concrete code evidence
    - Do not mark a row `satisfied` when only part of the cases is covered
 5. List out-of-scope changes and judge whether they are justified or unnecessary
-6. Reclassify prior findings into `new / persists / resolved / reopened`
-7. When citing build, test, or functional verification as evidence, record the verified target, what was checked, and the observed result in the report
-8. For each detected issue, classify it as blocking/non-blocking based on the Policy's scope table and judgment rules
-9. If there is even one blocking issue in `new`, `persists`, or `reopened`, judge as REJECT

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

@@ -1,39 +1,16 @@
-Review the changes from a security perspective. Check for the following vulnerabilities:
-- Injection attacks (SQL, command, XSS)
-- Authentication and authorization flaws
-- Data exposure risks
-- Cryptographic weaknesses
+Focus on reviewing **security**.
 
-**Primary sources to review:**
-- Review `order.md` to understand requirements and prohibitions.
-- Review `plan.md` to understand intended scope and design direction.
-- Review {report:coder-decisions.md} to understand the recorded design decisions.
-- Do not dismiss documented decisions as FP by default. Re-evaluate them against `order.md`, `plan.md`, and the actual code.
+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
 
-**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
+## Step-Specific Notes
 
-**Important:**
-- Do not treat documented precedence rules, extension points, or configuration override behavior as vulnerabilities by themselves.
-- Do not assume that removing an interactive confirmation or warning automatically means a security boundary regression.
-- To issue a blocking finding, make the exploit path concrete: who controls what input, and what newly becomes possible.
-
-## Judgment Procedure
-
-1. Cross-check `order.md`, `plan.md`, `coder-decisions.md`, and the actual code to determine whether the behavior is intentional product behavior
-2. Review the change diff and extract issue candidates by cross-checking changes against REJECT criteria in knowledge
-3. For each candidate, verify the concrete exploit path
-   - Which actor controls the input or configuration
-   - Whether the change enables new privilege, data access, code execution, or prompt modification
-   - Whether the impact exceeds the existing documented precedence or extension model
-4. When configuration precedence, local/global shadowing, or non-interactive selection is involved, additionally verify:
-   - Whether the behavior is intended by `order.md` or `plan.md`
-   - Whether explicit selectors or arguments already make the user's intent clear
-   - Whether there is an actual trust-boundary break or new attack capability, rather than merely an override relationship
-5. When citing build, test, or functional verification as evidence, record the verified target, what was checked, and the observed result in the report
-6. For each detected issue, classify it as blocking or non-blocking based on the Policy scope table and judgment rules
-7. If there is even one blocking issue, judge as REJECT
+- Do not treat documented precedence rules, extension points, or configuration override behavior as vulnerabilities by themselves
+- Do not assume that removing an interactive confirmation or warning automatically means a security boundary regression
+- To issue a blocking finding, make the exploit path concrete: which actor controls what input, and what newly becomes possible
+- When configuration precedence, local/global shadowing, or non-interactive selection is involved, additionally verify:
+  - Whether the behavior is intended by `order.md` or `plan.md`
+  - Whether explicit selectors or arguments already make the user's intent clear
+  - Whether there is an actual trust-boundary break or new attack capability, rather than merely an override relationship

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

@@ -1,31 +1,7 @@
 Focus on reviewing **Terraform convention compliance**.
 Do not review AI-specific issues (already covered by the ai-antipattern-review-1st step).
 
-**Review criteria:**
-- Variable declaration compliance (type, description, sensitive)
-- Resource naming consistency (name_prefix pattern)
-- File organization compliance (one file per concern)
-- Security configurations (IMDSv2, encryption, access control, IAM least privilege)
-- Tag management (default_tags, no duplication)
-- Lifecycle rule appropriateness
-- Cost trade-off documentation
-- Unused variables / outputs / data sources
-
-
-**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, extract open findings from "Previous Response"
-- Assign `finding_id` to each finding and classify current status as `new / persists / resolved`
-- If status is `persists`, provide concrete unresolved evidence (file/line)
-
-## Judgment Procedure
-
-1. First, extract previous open findings and preliminarily classify as `new / persists / resolved`
-2. Review the change diff and detect issues based on Terraform convention criteria
-   - Cross-check changes against REJECT criteria tables defined in knowledge
-3. For each detected issue, classify as blocking/non-blocking based on Policy's scope determination table and judgment rules
-4. If there is even one blocking issue (`new` or `persists`), judge as REJECT
+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

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/knowledge/cqrs-es.md

@@ -101,6 +101,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,7 +111,7 @@ 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 |
@@ -122,7 +123,8 @@ State Placement Guidelines:
 |--------------|----------------------|
 | 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