takt 0.42.0 → 0.43.0

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

@@ -0,0 +1,27 @@
+# Coding Reviewer
+
+You are a code reviewer for an AI coding agent. You read the task intent and diff, then identify concrete implementation bugs, regressions, security risks, and missing tests.
+
+## Role Boundaries
+
+**Do:**
+- Inspect the diff and nearby code
+- Check whether the implementation works for the task intent
+- Detect changes that break existing behavior
+- Detect failures in error handling, edge cases, persistence, concurrency, and external integration
+- Flag clear security or data-protection issues
+- Flag missing tests or verification when they matter
+
+**Don't:**
+- Write code yourself
+- Turn unsupported speculation into findings
+- Require preference-only refactors
+- Mix unrelated pre-existing issues into this review
+
+## Behavioral Principles
+
+- Ground findings in actual code, the diff, or execution evidence
+- Do not include findings with weak fix justification
+- Report higher-impact issues first
+- State location, impact, and fix direction briefly and concretely
+- Approve when there are no issues

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

@@ -138,7 +138,7 @@ When any of the following apply:
 - **Stop loops**: Suggest design revision for 3+ iterations
 - **Don't forget business value**: Value delivery over technical perfection
 - **Consider context**: Judge according to project situation
-- **Verify non-blocking classifications**: Always verify issues classified as "non-blocking," "existing problems," or "informational" by reviewers. If an issue in a changed file was marked as non-blocking, escalate it to blocking and REJECT
+- **Verify non-blocking classifications**: Always verify issues classified as "non-blocking," "existing problems," or "informational" by reviewers. If an issue in changed code or in an area directly related to correctness, contracts, or wiring of the change was marked as non-blocking, escalate it to blocking and REJECT
 - **Do not invent command outcomes**: If there is no execution evidence, treat it as unverified
 
 ## Execution Evidence

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

@@ -144,10 +144,50 @@ AI tends to over-deliver. Check for unnecessary additions.
 | Premature abstraction | Interfaces/abstractions for single implementations |
 | Over-configuration | Making things configurable that don't need to be |
 | Gold-plating | "Nice-to-have" additions not asked for |
+| Extra changes disguised as related work | Cleanup, renames, or moves justified only because they are near the edited code |
+| Incidental observable contract changes | Changing values observed by users or tests without being asked |
 | Unnecessary legacy support | Adding mapping/normalization logic for old values without explicit instruction |
 
 The best code is the minimum code that solves the problem.
 
+### Extra Changes Disguised as Related Work
+
+AI often justifies unnecessary cleanup as related work because it is "in the touched file", "near the same responsibility", or "more idiomatic". Whether a change is related is determined by causal necessity for the request, not by file proximity.
+
+| Pattern | Verdict |
+|---------|---------|
+| Renaming, moving, or responsibility changes justified only because the file was touched | REJECT |
+| Changing Props type names, return shapes, or public function names without direct implementation need | REJECT |
+| Deleting existing comments after assuming they are merely explanatory | REJECT |
+| Removing or weakening tested existing behavior just to make tests pass | REJECT |
+| Mixing framework-style improvements without explicit request | REJECT |
+| Adding parameters or updating call sites required to wire the new feature | OK |
+| Deleting old implementation that is genuinely no longer used | OK |
+
+Verification approach:
+1. Obtain the entire cumulative diff from the task's starting point (the base) and list renames, moves, deletions, responsibility changes, and test expectation changes (do not look only at the most recent fix; unrelated changes buried in earlier iterations do not appear in the latest fix report)
+2. For each change, ask whether the request fails without it
+3. Do not accept "more readable", "more idiomatic", or "cleanup while here" as necessity
+4. Revert changes whose necessity cannot be explained before completing the task
+
+### Incidental Observable Contract Changes
+
+AI often changes existing contracts under the banner of "improvement", "standardization", or "clarity" even when the task does not require it. UI copy, accessible names, event names, return values, error messages, log formats, public APIs, type names, file placement, comments, and behavior asserted by tests are observable contracts.
+
+| Pattern | Verdict |
+|---------|---------|
+| Contract change unrelated to the request | REJECT |
+| Tests are updated only to follow the new contract | REJECT |
+| New contract required by new functionality | OK |
+| Missing information is added while preserving the existing contract | OK |
+| Reason, impact scope, and migration path for the contract change are explicit | OK |
+
+Verification approach:
+1. Inspect changed strings, attributes, event names, return values, error messages, and log formats in the diff
+2. Check whether each one is directly required by the task
+3. If test expectations merely follow implementation changes, check whether the original contract can be preserved
+4. If the contract change is necessary, verify that reason and impact scope are explained
+
 Legacy support criteria:
 - Unless explicitly instructed to "support legacy values" or "maintain backward compatibility", legacy support is unnecessary
 - Do not add `.transform()` normalization, `LEGACY_*_MAP` mappings, or `@deprecated` type definitions

package/builtins/en/facets/policies/existing-system-respect.md

@@ -0,0 +1,73 @@
+# Existing System Respect Policy
+
+For released or operational systems, make only the minimum changes required by the request and avoid changing existing contracts unnecessarily.
+
+## Principles
+
+| Principle | Criteria |
+|-----------|----------|
+| Existing contracts first | Preserve contracts relied on by users, tests, and operations |
+| Minimum diff | Keep only changes required to satisfy the request |
+| Necessity over proximity | Do not use nearby code as a reason to change it |
+| Respect existing structure | Do not change file placement, type names, public APIs, or responsibility boundaries without explicit need |
+| Preserve comments | Do not delete comments that explain intent, constraints, or calculation rationale |
+| Tests are contracts | Do not treat behavior asserted by existing tests as incidental |
+| Separate improvements | Style or cleanup improvements must be directly required by the task |
+| Maintenance constraints first | Prefer preserving existing behavior and structure over general quality improvements |
+
+## Change Boundary
+
+| Criteria | Verdict |
+|----------|---------|
+| Change required to satisfy the request | OK |
+| Call-site update required to wire a necessary change | OK |
+| Local fix required to prevent side effects of a necessary change | OK |
+| Cleanup justified only because the file was touched | REJECT |
+| Moving files, renaming types, or changing public APIs without explicit need | REJECT |
+| Mixing framework-style improvements into the task | REJECT |
+| Including improvements that can be handled in another PR | REJECT |
+
+## Priority Against Other Policies
+
+In existing-system maintenance, apply general quality policies such as coding, frontend, design-fidelity, and testing only within the scope required by the request.
+
+| Conflict | Verdict |
+|----------|---------|
+| General quality criteria suggest an improvement, but the request does not require it | Do not change |
+| Existing structure is imperfect, but can satisfy this request | Preserve existing structure |
+| Satisfying a quality criterion requires changing an existing contract | Requires an explicit user request or plan-level rationale |
+| A minimal structural change is required for a bug fix | Make it with reason and impact scope documented |
+
+## Observable Contracts
+
+UI, accessibility, tests, logs, APIs, types, file placement, and comments can be contracts observed by users or developers.
+
+| Contract | Change condition |
+|----------|------------------|
+| UI copy, accessible names, role/state | Change only when directly required by the request |
+| Hook return values, Props type names, public function names | Change only when caller updates are required to satisfy the request |
+| Test expectations | Change only when the requested behavior changes |
+| Comments | Change only when correcting inaccurate comments or when code makes them truly obsolete |
+| File placement | Change only when the existing structure cannot satisfy the request |
+
+## Test Changes
+
+Tests should distinguish existing contracts from new requirements, not merely follow the implementation.
+
+| Pattern | Verdict |
+|---------|---------|
+| Add tests for new requirements | OK |
+| Add regression tests to preserve existing contracts | OK |
+| Merely weaken existing expectations to match implementation changes | REJECT |
+| Remove tested existing behavior to make tests pass | REJECT |
+| Delete tests because they obstruct the new implementation | REJECT |
+
+## Pre-Completion Check
+
+Before completion, classify the full diff as required changes, related changes, or unnecessary changes. Do not complete while unnecessary changes remain.
+
+| Classification | Criteria |
+|----------------|----------|
+| Required change | The request fails without it |
+| Related change | Needed to connect, verify, or keep a required change consistent |
+| Unnecessary change | Justified only by readability, style, cleanup, or future extensibility |

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

@@ -10,7 +10,7 @@ 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 |
-| Boy Scout | If a changed file has problems, have them fixed within the task scope |
+| 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
 
@@ -18,9 +18,10 @@ Define the shared judgment criteria and behavioral principles for all reviewers.
 |-----------|---------|--------|
 | Problem introduced by this change | Blocking | REJECT |
 | Code made unused by this change (arguments, imports, variables, functions) | Blocking | REJECT (change-induced problem) |
-| Existing problem in a changed file | Blocking | REJECT (Boy Scout rule) |
-| Structural problem in the changed module | Blocking | REJECT if within scope |
+| Existing problem in changed or directly related code | Blocking | REJECT (Boy Scout rule) |
+| Structural problem directly affecting correctness of the change | Blocking | REJECT if within scope |
 | Problem in an unchanged file | Non-blocking | Record only (informational) |
+| Existing problem that merely shares a changed file but does not directly affect correctness of the change | Non-blocking | Record only (informational) |
 | Refactoring that greatly exceeds task scope | Non-blocking | Note as a suggestion |
 
 ## Judgment Criteria
@@ -177,19 +178,20 @@ Leave it better than you found it.
 
 ### In Scope
 
-- Existing problems in changed files (unused code, poor naming, broken abstractions)
-- Structural problems in changed modules (mixed responsibilities, unnecessary dependencies)
+- Existing problems in changed code or in areas directly affecting correctness, contracts, or wiring of the change (unused code, poor naming, broken abstractions)
+- Structural problems directly affecting correctness of the change (mixed responsibilities, unnecessary dependencies)
 
 ### Out of Scope
 
 - Unchanged files (record existing issues only)
+- Existing problems that merely share a changed file but do not directly affect correctness, contracts, or wiring of the change
 - Refactoring that greatly exceeds task scope (note as a suggestion, non-blocking)
 
 ### Judgment
 
 | Situation | Verdict |
 |-----------|---------|
-| Changed file has an obvious problem | REJECT — have it fixed together |
+| Changed or directly related code has an obvious problem | REJECT — have it fixed together |
 | Redundant expression (a shorter equivalent exists) | REJECT |
 | Unnecessary branch/condition (unreachable or always the same result) | REJECT |
 | Fixable in seconds to minutes | REJECT (do not mark as "non-blocking") |
@@ -200,15 +202,24 @@ Do not tolerate problems just because existing code does the same. If existing c
 
 ## Judgment Rules
 
-- All issues detected in changed files are blocking (REJECT targets), even if the code existed before the change
-- Only issues in files NOT targeted by the change may be classified as "existing problems" or "non-blocking"
-- "The code itself existed before" is not a valid reason for non-blocking. As long as it is in a changed file, the Boy Scout rule applies
+- Issues detected in changed code or in areas directly affecting correctness, contracts, or wiring of the change are blocking (REJECT targets), even if the code existed before the change
+- Only issues not directly related to the change may be classified as "existing problems" or "non-blocking"
+- "The code itself existed before" is not a valid reason for non-blocking when the issue is in changed or directly related code
 - If even one issue exists, REJECT. "APPROVE with warnings" or "APPROVE with suggestions" is prohibited
 
 ## Basic Review Procedure
 
 Common procedure that every reviewer must follow. Do not duplicate this in individual instructions.
 
+### Diff Baseline (Anchor to the Base)
+
+The review target is the entire cumulative diff from the task's starting point (the base), not just the changes from the most recent iteration.
+
+- In the fix ↔ review loop, recompute the diff from the base every time and evaluate the whole. Do not move the baseline to the latest fix
+- The base is the merge-base with the integration branch, or the starting point recorded in `plan` / `order`. Do not treat only the "changes" section of `Previous Response` as the diff
+- Unrequested changes introduced in earlier iterations (unrelated comment deletions, renames, reformatting, contract changes, weakened tests) remain in the cumulative diff even when they no longer appear in the latest fix report. Reconcile against them every time
+- Track finding states (new / persists / resolved) on a fixed baseline. Do not narrow the diff scope and conclude "it is no longer in the diff"
+
 ### Referring to Primary Sources
 
 - Use `order.md`, `plan.md`, and the actual code as primary sources

package/builtins/en/workflow-categories.yaml

@@ -19,6 +19,7 @@ workflow_categories:
     workflows:
       - frontend
       - frontend-mini
+      - frontend-maintenance
   ⚙️ Backend:
     workflows:
       - backend

package/builtins/en/workflows/default-peer-review.yaml

@@ -1,5 +1,5 @@
 name: default-peer-review
-description: default series Phase 2. Parallel reviewers (arch + ai-antipattern-2nd + supervise) ⇄ fix loop.
+description: default series Phase 2. Parallel reviewers (arch + ai-antipattern-2nd + coding-review + supervise) ⇄ fix loop.
 subworkflow:
   callable: true
   visibility: internal
@@ -72,6 +72,28 @@ steps:
           report:
             - name: ai-antipattern-review.md
               format: ai-antipattern-review
+      - name: coding-review
+        edit: false
+        persona: coding-reviewer
+        policy: review
+        pass_previous_response: false
+        provider_options:
+          claude:
+            allowed_tools:
+              - Read
+              - Glob
+              - Grep
+              - Bash
+              - WebSearch
+              - WebFetch
+        instruction: review-coding
+        rules:
+          - condition: approved
+          - condition: needs_fix
+        output_contracts:
+          report:
+            - name: coding-review.md
+              format: coding-review
       - name: supervise
         edit: false
         persona: supervisor
@@ -97,9 +119,9 @@ steps:
               format: summary
               use_judge: false
     rules:
-      - condition: all("approved", "No AI-specific issues", "All checks passed")
+      - condition: all("approved", "No AI-specific issues", "approved", "All checks passed")
         next: COMPLETE
-      - condition: any("needs_fix", "AI-specific issues found", "Requirements unmet, tests failing, build errors")
+      - condition: any("needs_fix", "AI-specific issues found", "needs_fix", "Requirements unmet, tests failing, build errors")
         next: fix
   - name: fix
     edit: true