takt 0.45.0 → 0.47.0

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

@@ -7,25 +7,39 @@
 
 Extract requirements from the task spec and verify each one individually against actual code.
 
-| # | Decomposed requirement | Met | Evidence (file:line) |
-|---|------------------------|-----|---------------------|
-| 1 | {requirement 1} | ✅/❌ | `src/file.ts:42` |
-| 2 | {requirement 2} | ✅/❌ | `src/file.ts:55` |
+| # | Decomposed requirement | Original Requirement Source | Met | Evidence (file:line) | Exception / Optionalization Evidence |
+|---|------------------------|-----------------------------|-----|----------------------|------------------------------------|
+| 1 | {requirement 1} | `order.md:10` | ✅/❌ | `src/file.ts:42` | none |
+| 2 | {requirement 2} | `order.md:11` | ✅/❌ | `src/file.ts:55` | none |
 
 - If a sentence contains multiple conditions, split it into the smallest independently verifiable rows
 - Do not combine parallel conditions such as `A/B`, `global/project`, `JSON/leaf`, `allow/deny`, or `read/write` into one row
 - 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
+- Treat optionalization, exclusion, or exception not present in the task spec as unmet
+- Do not rely on plan report's judgment; independently verify mergeability
 
 ## Re-evaluation of Prior Findings
-| finding_id | Prior Status | Re-evaluation | Evidence |
-|------------|--------------|---------------|----------|
-| {id} | new / persists / resolved | valid / false_positive / overreach | `src/file.ts:42`, `reports/plan.md` |
+| finding_id | Prior Status | Original Expected Result | Re-evaluation | Evidence |
+|------------|--------------|--------------------------|---------------|----------|
+| {id} | new / persists / resolved | {Original finding acceptance criteria} | valid / false_positive / overreach | `src/file.ts:42`, `reports/plan.md` |
 
 - If final judgment differs from prior review conclusions, explain why with evidence
+- Treat `resolved` as valid only when it satisfies the original expected result and original requirement
 - If marking `false_positive` or `overreach`, state whether it conflicts with the task objective, the plan, or both
+- If overturning a pure-review conclusion, explain why with concrete evidence
+
+## Maintenance Scope Check (maintenance workflows only)
+
+| Check | Result | Evidence |
+|-------|--------|----------|
+| Only required changes remain | ✅/❌ | {Evidence} |
+| Related changes have clear reasons | ✅/❌ | {Evidence} |
+| No unnecessary changes remain | ✅/❌ | {Evidence} |
+| No out-of-scope comment deletion occurred | ✅/❌ | {Evidence} |
+| Type names, file placement, and public APIs did not change out of scope | ✅/❌ | {Evidence} |
+| UI copy, accessible names, and test expectations did not change out of scope | ✅/❌ | {Evidence} |
 
 ## Validation Summary
 | Item | Status | Verification Method |
@@ -38,6 +52,11 @@ Extract requirements from the task spec and verify each one individually against
 - When using `⚠️`, explain the missing evidence and the verified scope in the method column
 - If report text conflicts with execution evidence, treat that inconsistency itself as a finding
 
+## Unverified Scope
+| Item | Impact | Treatment |
+|------|--------|-----------|
+| {Unverified scope, or "none"} | {Primary or supporting requirement} | APPROVE allowed / REJECT reason |
+
 ## Current Iteration Findings (new)
 | # | finding_id | Item | Evidence | Reason | Required Action |
 |---|------------|------|----------|--------|-----------------|
@@ -49,14 +68,19 @@ Extract requirements from the task spec and verify each one individually against
 | 1 | VAL-PERSIST-src-file-L77 | `file:line` | `file:line` | Still unresolved | Apply fix |
 
 ## Resolved Findings (resolved)
-| finding_id | Resolution Evidence |
-|------------|---------------------|
-| VAL-RESOLVED-src-file-L10 | `file:line` now passes validation |
+| finding_id | Original Expected Result | Resolution Evidence |
+|------------|--------------------------|---------------------|
+| VAL-RESOLVED-src-file-L10 | {Original finding acceptance criteria} | `file:line` now passes validation |
 
 ## Deliverables
 - Created: {Created files}
 - Modified: {Modified files}
 
+## Outstanding Items (if REJECT)
+| # | Item | Reason |
+|---|------|--------|
+| 1 | {Item} | {Reason} |
+
 ## Rejection Gate
 - REJECT is valid only when at least one finding exists in `new` or `persists`
 - Findings without `finding_id` are invalid

package/builtins/en/facets/output-contracts/terraform-review-finding-contract.md

@@ -0,0 +1,31 @@
+```markdown
+# Terraform Convention Review
+
+## Result: APPROVE / REJECT
+
+## Summary
+{Summarize the result in 1-2 sentences}
+
+## Reviewed Aspects
+- [x] Variable declarations (type, description, sensitive)
+- [x] Resource naming (name_prefix pattern)
+- [x] File structure (one concern per file)
+- [x] Security settings
+- [x] Tag management
+- [x] lifecycle rules
+- [x] Cost trade-off documentation
+
+## Observed Findings
+| # | family_tag | Severity | Scope | Location | Issue | Impact | Fix Suggestion |
+|---|------------|----------|-------|----------|-------|--------|----------------|
+| 1 | tf-convention | High / Medium / Low | In-scope | `modules/example/main.tf:42` | Issue description | Operations, security, or maintainability impact | Fix approach |
+
+Scope: "In-scope" (fixable in this change) / "Out-of-scope" (existing issue, non-blocking)
+
+## Rejection Gate
+- REJECT only when at least one blocking finding is observed
+```
+
+**Cognitive load reduction rules:**
+- APPROVE → Summary only (5 lines or fewer)
+- REJECT → Include only relevant finding rows (30 lines or fewer)

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

@@ -0,0 +1,41 @@
+```markdown
+# Testing Review
+
+## Result: APPROVE / REJECT
+
+## Summary
+{Summarize the result in 1-2 sentences}
+
+## Reviewed Aspects
+| Aspect | Result | Notes |
+|--------|--------|-------|
+| Test coverage | ✅ | - |
+| Test structure (Given-When-Then) | ✅ | - |
+| Test naming | ✅ | - |
+| Test independence & reproducibility | ✅ | - |
+| Mocks & fixtures | ✅ | - |
+| Test strategy (unit/integration/E2E) | ✅ | - |
+| Contract input location (body/query/path) | ✅ | - |
+
+## Observed Findings
+| # | family_tag | Category | Severity | Location | Issue | Fix Suggestion |
+|---|------------|----------|----------|----------|-------|----------------|
+| 1 | test-structure | Coverage | high / medium / low | `src/test.ts:42` | Issue description | Fix suggestion |
+
+## 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}
+
+## 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 blocking finding is observed
+```
+
+**Cognitive load reduction rules:**
+- APPROVE: Summary and unverified scope only (8 lines or fewer)
+- REJECT: Only relevant findings in tables (30 lines or fewer)

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/findings-manager.md

@@ -0,0 +1,18 @@
+# Findings Manager
+
+You manage Finding Contract reconciliation.
+
+Compare reviewer raw findings with the existing ledger, then classify each issue as an existing match, new finding, resolved finding, or reopened finding. The engine allocates final IDs, so only map raw findings to existing IDs and grouped rawFindingIds.
+
+Responsibilities:
+- Reconcile the prior integrated ledger with current raw findings.
+- Classify raw findings as existing matches, new findings, resolved findings, or reopened findings.
+- Group rawFindingIds into structured data that lets the engine allocate final IDs.
+
+Rules:
+- Do not make semantic severity or priority judgments.
+- Do not merge findings with different `family_tag`, location, or issue meaning.
+- Do not blame reviewers.
+- Do not allocate final `finding_id` values.
+- Treat identical location + `family_tag` + issue meaning as the existing-match standard.
+- Treat ambiguous or merely similar findings as distinct.

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

@@ -1,5 +1,20 @@
 # AI Antipattern Detection Criteria
 
+Detect assumptions, over-implementation, and superficial fixes that AI-generated changes commonly introduce.
+
+## Principles
+
+| Principle | Criteria |
+|-----------|----------|
+| Requirement fit | Verify that the implementation answers the actual request |
+| Reality check | Do not infer APIs, settings, fields, or wiring paths |
+| Context fit | Match existing naming, structure, error handling, logging, and tests |
+| Minimal diff | Do not mix in unnecessary features, abstractions, settings, or compatibility code |
+| Contract preservation | Do not change UI copy, public APIs, return values, errors, or test expectations out of scope |
+| Direct fixes | Do not replace a fix with tests or documentation explaining the issue |
+| Reachability | Confirm that added or retained code is used by current call paths |
+| Verifiability | Check code paths, usage sites, and execution results instead of explanations |
+
 ## Assumption Verification
 
 AI often makes assumptions. Verify them.
@@ -112,11 +127,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
 
@@ -134,6 +151,22 @@ Questions to ask:
 - Does it feel like it belongs here?
 - Are there unexplained deviations from project conventions?
 
+## Integration Pattern Consistency
+
+Check whether the same kind of API connection, such as REST calls, is implemented in inconsistent ways within the project.
+
+| Pattern | Example | Verdict |
+|---------|---------|---------|
+| Mixed generated and hand-written clients | Screen A uses Orval-generated hooks, screen B calls axiosInstance directly | REJECT |
+| Different implementations for the same data-fetching pattern | Screen A uses useQuery + axios, screen B uses generated hooks | REJECT |
+| Mixed data type definition styles | Screen A uses generated types, screen B uses hand-written types | REJECT |
+
+Verification approach:
+1. Check the API calling style in the diff
+2. Grep existing code for the style used by code with the same purpose
+3. Check whether the project has API generation config, such as orval.config.ts
+4. If inconsistent, flag unification to the project standard pattern
+
 ## Scope Creep Detection
 
 AI tends to over-deliver. Check for unnecessary additions.

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,13 @@ 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 |
+| Contract coverage | Verify new contracts across normal entries, derived conditions, validation, evaluation, output, and re-injection paths |
+| Contract consistency | Verify that contracts carried by consolidation or abstraction are applied to existing equivalent branches by the same standard |
+| Specification completeness | When changing a user-facing contract, verify that implementation, tests, and documentation describe the same lookup order, override rules, special syntax, and failure conditions |
+| Requirement anchoring | Do not reinterpret required task items as optional, out of scope, or different requirements for implementation convenience |
+| Resolution judgment | Judge `resolved` against the original finding acceptance criteria and original task requirements, not merely against the presence of a fix |
+| 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 +38,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'`)
@@ -45,7 +53,11 @@ REJECT without exception if any of the following apply.
 - 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
+- Missing caller, producer, consumer, validator, test data, or derived-entry updates after a contract change
+- User-facing contract changes for configuration, CLI, or file formats where documentation or examples omit priority, first-match/merge behavior, inline overrides, scoped/special references, or failure conditions
+- Existing branches with the same contract remain on the old implementation after adding or changing a shared helper, normalizer, builder, or adapter
+- Fields, attributes, outputs, settings, or identifiers requested by the task are treated as optional, unset, out of scope, or missing for some entry point or execution mode without explicit evidence
+- 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 +73,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 +81,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.
@@ -114,12 +137,39 @@ Every issue raised must include the following.
 
 To prevent circular rejections, track findings by ID.
 
+Finding Contract applies to the whole review workflow, not to individual findings.
+Treat a workflow as using Finding Contract only when it is declared at workflow level
+with `finding_contract` configuration. A `findings-ledger.json` file, a dedicated
+"Finding Contract" section in the instruction template, or an `Observed Findings`
+table in the output contract is supporting evidence inside an already configured
+Finding Contract workflow; none of these artifacts enables Finding Contract by itself.
+
+When Finding Contract is in use, reviewers must not allocate new final `finding_id`
+values and must not classify lifecycle as `new`, `persists`, `resolved`, or
+`reopened`. Report observed problems as raw findings in the `Observed Findings`
+table. Refer to existing IDs only when they are present in the ledger. ID assignment
+and lifecycle matching belong to the findings-manager and engine.
+
+When a workflow is configured with Finding Contract and a parseable ledger is available,
+the ledger is the authoritative source for tracked findings. Individual reports and raw
+finding details are supporting evidence. If a ledger exists but is incomplete, follow
+mapped findings from the ledger and treat unmapped raw findings as potential new entries
+pending findings-manager reconciliation. If no parseable ledger is available in a
+configured Finding Contract workflow, use report history only as supporting evidence for
+observed raw findings. Do not assign final `finding_id` values or lifecycle states and
+do not apply the legacy rules; wait for ledger regeneration or findings-manager
+reconciliation.
+
+### Legacy Finding ID Rules (for workflows without Finding Contract)
+
+When a workflow does not use `finding_contract` configuration, follow these legacy rules.
+
 - Every issue raised in a REJECT must include a `finding_id`
 - If the same issue is raised again, reuse the same `finding_id`
 - For repeated issues, set status to `persists` and include concrete evidence (file/line) that it remains unresolved
 - New issues must use status `new`
 - Resolved issues must be listed with status `resolved`
-- Issues without `finding_id` are invalid (cannot be used as rejection grounds)
+- Issues without `finding_id` are invalid (cannot be used as rejection grounds). This legacy rule does not apply to Finding Contract workflows.
 - REJECT is allowed only when there is at least one `new` or `persists` issue
 - Before treating a prior finding as resolved, verify that the fix did not introduce a different structural or contract problem
 
@@ -225,6 +275,7 @@ The review target is the entire cumulative diff from the task's starting point (
 - 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
+- When a user-facing specification changes, treat documentation and configuration examples as part of the contract and verify that every behavior listed in the requirements is present
 
 ### Referring to Design Decisions
 
@@ -232,13 +283,43 @@ 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
 
+### Full Entry Review for Contract Additions and Changes
+
+When the diff adds or changes a contract such as a config value, state, condition expression, file format, event, builder, adapter, or state-transition function, enumerate and reconcile every entry, exit, and re-injection path that can carry that contract.
+
+- Verify that definition, production, normalization, validation, evaluation, persistence, output, and event emission all apply the same contract
+- Check derived paths as well as the normal entry: derived conditions, aggregate conditions, parent/child workflows, loop decisions, early exits, and exception paths
+- When persisted data or externally supplied data is re-injected into JSON, Markdown, logs, events, or later instructions, include escaping, boundary handling, and failure behavior in the contract
+- Search for existing returns, throws, catches, early returns, branches, and call sites with the same responsibility
+- If an existing branch does not satisfy the new contract, treat it as related code even if the code itself predates the change
+- If tests cover only the new path and do not verify existing equivalent branches or derived entries, treat it as a coverage gap
+- Treating a required contract as optional, excluded, or a different requirement requires evidence from the task spec, specification, or explicit user instruction
+- "Not explicitly stated in the task requirements" is not a valid reason to mark a contract inconsistency introduced by the diff as non-blocking
+
+### 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
-- 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`
+**Precedence:**
+
+1. If a parseable Finding Contract ledger / `findings-ledger.json` is available in a workflow configured with Finding Contract, use the ledger as the authoritative source for tracked findings. Fix only open findings from the ledger (`new`, `persists`, or `reopened`); ignore resolved or closed findings. Treat individual reports as supporting evidence reachable from the ledger.
+2. If a ledger exists but is incomplete, follow mapped findings from the ledger and treat unmapped raw findings as potential new entries pending findings-manager reconciliation.
+3. If the workflow is configured with Finding Contract but no parseable ledger is available, use the latest review reports in the Report Directory only as supporting evidence for observed raw findings. Do not assign final `finding_id` values or lifecycle states and do not apply the legacy rules; wait for ledger regeneration or findings-manager reconciliation.
+4. If the workflow does not use `finding_contract` configuration, use the latest review reports in the Report Directory as the primary evidence and apply the legacy rules:
+   - 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`
+   - Mark `resolved` only when the original expected result and original requirement are satisfied, not merely because a patch exists
 
 ### Final Decision Steps
 
@@ -248,12 +329,4 @@ The review target is the entire cumulative diff from the task's starting point (
 
 ## Detecting Circular Arguments
 
-When the same kind of issue keeps recurring, reconsider the approach itself rather than repeating the same fix instructions.
-
-### When the Same Problem Recurs
-
-1. Check if the same kind of issue is being repeated
-2. If so, propose an alternative approach instead of granular fix instructions
-3. Even when rejecting, include the perspective of "a different approach should be considered"
-
-Rather than repeating "fix this again," stop and suggest a different path.
+When the same kind of issue keeps recurring, reconsider the approach itself rather than repeating granular fix instructions.

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

@@ -21,6 +21,9 @@ Every behavior change requires a corresponding test, and every bug fix requires
 | New behavior | Test required. REJECT if missing |
 | Bug fix | Regression test required. REJECT if missing |
 | Behavior change | Test update required. REJECT if missing |
+| Side-effect or state-transition change | Successful path and representative failure paths must be verified. REJECT if failure paths are untested |
+| Contract changes through consolidation or abstraction | Must verify that the contract holds on existing equivalent branches, not only on the new shared path |
+| Parser or configuration boundary changes | Must verify syntactically valid inputs with unexpected shapes, missing values, and isolation from personal configuration |
 | Build (type check) | Build must succeed. REJECT if it fails |
 | Edge cases / boundary values | Test recommended (Warning) |
 
@@ -51,6 +54,18 @@ These assets change often during wording improvements and reorganization, so mak
 
 Verify non-executable asset changes with review, Markdown lint, link checks, or sample command execution when needed.
 
+## Tests for Replaced Old Specifications
+
+When a specification change replaces elements of an old design (UI, API, events, state, labels, etc.) with a new design, tests must positively verify the new behavior. Do not freeze only the absence of the old specification.
+
+| Criteria | Verdict |
+|----------|---------|
+| Adding a test that only verifies elements of the old specification are not present or not called | REJECT |
+| Keeping an absence-only test from the old specification in an implementation unit that no longer owns the responsibility | REJECT |
+| Changing only tests in a file whose production code has no final diff, solely to negate the old specification | REJECT |
+| Positively verifying the new specification in the layer that owns the new responsibility (upper module, service, integration flow, etc.) | OK |
+| Deleting obsolete tests for removed old behavior and replacing them with regression tests for the new specification | OK |
+
 ## Test Structure: Given-When-Then
 
 ```typescript
@@ -75,6 +90,40 @@ test('should return NotFound error when user does not exist', async () => {
 | Clarity | Failure cause is obvious | Failure cause is unclear |
 | Focus | One test, one concept | Multiple concerns mixed |
 
+## Testing Side Effects and State Transitions
+
+Changes involving side effects or state transitions are not sufficiently verified by successful-path coverage alone.
+
+| Criteria | Verdict |
+|----------|---------|
+| Only the successful path is tested, with no verification of state after failure, interruption, or early exit | REJECT |
+| Cleanup or duplicate execution for acquired, started, registered, or applied state is not verified | REJECT |
+| A change affects shared state or downstream execution but does not verify rerun behavior after partial failure | Warning. REJECT when it affects a primary path |
+| Mock-verified behavior is not distinguished from unverified real-integration scope | Warning. REJECT when it is a primary requirement |
+| Successful path, representative failure paths, and boundary state transitions are each verified | OK |
+
+## Testing Contract Changes and Existing Branches
+
+When a change standardizes a contract through a shared helper, normalizer, builder, or adapter, testing only the newly added path is not sufficient. Verify that existing equivalent branches satisfy the same contract.
+
+| Criteria | Verdict |
+|----------|---------|
+| Only the new shared path is tested, while existing equivalent branches are not verified for the same return value, side effect, or error contract | REJECT |
+| An existing branch is treated as "preserved behavior" without verifying that it does not conflict with the contract introduced by the diff | REJECT |
+| Return / throw / catch / early return paths in the changed function are not enumerated, causing representative failure paths to be missed | REJECT |
+| Existing branches with the same responsibility have tests for return values, side effects, events, and error classification contracts | OK |
+
+## Parser and Configuration Boundary Tests
+
+At boundaries that read external files, configuration, YAML/JSON, or CLI input, testing only the ideal typed input is not sufficient.
+
+| Criteria | Verdict |
+|----------|---------|
+| Array-like fields are not tested with object/null/missing values | REJECT |
+| File/directory checks are not tested with an existing regular file, broken link, or permission error | REJECT |
+| Tests that can inherit existing user or machine configuration do not isolate with an empty config directory or temporary HOME | REJECT |
+| Syntactically valid but contract-invalid shapes are pinned to ignore, normalize, or explicit-error behavior | OK |
+
 ## Test Data and Fixtures
 
 Test data should explicitly generate the minimum facts needed by each test. Mutating shared fixtures or using mocks that drift from real contracts reduces test reliability.

package/builtins/en/provider-options/edit.yaml

@@ -0,0 +1,21 @@
+claude:
+  allowed_tools:
+    - Read
+    - Glob
+    - Grep
+    - Edit
+    - Write
+    - Bash
+    - WebSearch
+    - WebFetch
+opencode:
+  allowed_tools:
+    - read
+    - glob
+    - grep
+    - edit
+    - write
+    - bash
+    - todowrite
+    - websearch
+    - webfetch