takt 0.32.0 → 0.32.2

package/builtins/en/templates/instructions/ai-fix.md

@@ -1,74 +0,0 @@
-# ai-fix -- AI Issue Fix Instruction Template
-
-> **Purpose**: Fix issues identified by AI Review
-> **Agent**: coder
-> **Feature**: Built-in countermeasures against the "already fixed" false recognition bug
-
----
-
-## Template
-
-```
-**This is AI Review round {movement_iteration}.**
-
-If this is round 2 or later, the previous fixes were NOT actually applied.
-**Your belief that they were "already fixed" is wrong.**
-
-**First, acknowledge:**
-- The files you thought were "fixed" were NOT actually modified
-- Your memory of the previous work is incorrect
-- You need to rethink from scratch
-
-**Required actions:**
-1. Open ALL flagged files with the Read tool (abandon assumptions, verify facts)
-2. Search for the problem locations with grep to confirm they exist
-3. Fix confirmed issues with the Edit tool
-4. Run tests to verify
-5. Report specifically "what you verified and what you fixed"
-
-**Report format:**
-- NG: "Already fixed"
-- OK: "Checked file X at L123, found issue Y, fixed by changing to Z"
-
-**Strictly prohibited:**
-- Reporting "already fixed" without opening the file
-- Making assumptions without verification
-- Ignoring issues that the AI Reviewer REJECTed
-
-**Handling "no fix needed" (required)**
-- Do not judge "no fix needed" unless you can show verification results for the target file of each issue
-- If the issue relates to "generated artifacts" or "spec synchronization", output the tag corresponding to "cannot determine" if you cannot verify the source/spec
-- If no fix is needed, output the tag corresponding to "cannot determine" and clearly state the reason and verification scope
-
-**Required output (include headings)**
-## Files checked
-- {file_path:line_number}
-## Searches performed
-- {command and summary}
-## Fix details
-- {changes made}
-## Test results
-- {command and results}
-```
-
----
-
-## Typical rules
-
-```yaml
-rules:
-  - condition: AI issue fixes completed
-    next: ai_review
-  - condition: No fix needed (target files/specs verified)
-    next: ai_no_fix
-  - condition: Cannot determine, insufficient information
-    next: ai_no_fix
-```
-
----
-
-## Notes
-
-Use this template as-is across all pieces. There are no customization points.
-The bug where AI falsely believes fixes were "already applied" is a model-wide issue;
-modifying or omitting the countermeasure text directly degrades quality.

package/builtins/en/templates/instructions/ai-review-standalone.md

@@ -1,47 +0,0 @@
-# ai-review-standalone -- AI Review (Standalone) Instruction Template
-
-> **Purpose**: Specialized review of AI-generated code (runs as an independent movement with iteration tracking)
-> **Agent**: ai-antipattern-reviewer
-> **For parallel sub-step use, see variation B in `review.md`**
-
----
-
-## Template
-
-```
-**This is AI Review round {movement_iteration}.**
-
-On the first round, review comprehensively and report all issues.
-On round 2 and later, prioritize verifying whether previously REJECTed items have been fixed.
-
-Review the code for AI-specific issues:
-- Assumption verification
-- Plausible but incorrect patterns
-- Compatibility with the existing codebase
-- Scope creep detection
-```
-
----
-
-## Differences from parallel sub-step
-
-| | standalone | parallel sub-step |
-|--|-----------|-------------------|
-| Iteration tracking | Yes (`{movement_iteration}`) | No |
-| First/subsequent instruction branching | Yes | No |
-| Next movement | ai_fix or reviewers | Parent movement decides |
-
-Standalone is for pieces that form an ai_review -> ai_fix loop.
-Parallel sub-steps use variation B from review.md.
-
----
-
-## Typical rules
-
-```yaml
-rules:
-  - condition: No AI-specific issues
-    next: reviewers
-  - condition: AI-specific issues found
-    next: ai_fix
-```

package/builtins/en/templates/instructions/arbitrate.md

@@ -1,45 +0,0 @@
-# arbitrate -- Arbitration Instruction Template
-
-> **Purpose**: Arbitrate when the reviewer and coder disagree
-> **Agent**: architecture-reviewer (as a neutral third party)
-> **Prerequisite**: ai_fix judged "no fix needed" -> resolve the contradiction with the reviewer's findings
-
----
-
-## Template
-
-```
-ai_review (reviewer) and ai_fix (coder) disagree.
-
-- ai_review identified issues and REJECTed
-- ai_fix verified and judged "no fix needed"
-
-Review both outputs and arbitrate which judgment is valid.
-
-**Reports to review:**
-- AI review results: {report:ai-review.md}
-
-**Judgment criteria:**
-- Are ai_review's findings specific and pointing to real issues in the code?
-- Does ai_fix's rebuttal have evidence (file verification results, test results)?
-- Are the findings non-blocking (record only) level, or do they actually require fixes?
-```
-
----
-
-## Typical rules
-
-```yaml
-rules:
-  - condition: ai_review's findings are valid (should be fixed)
-    next: ai_fix
-  - condition: ai_fix's judgment is valid (no fix needed)
-    next: reviewers
-```
-
----
-
-## Notes
-
-- Change the report reference filename according to the piece
-- Use a third party for arbitration, not the reviewer or coder themselves

package/builtins/en/templates/instructions/architect.md

@@ -1,48 +0,0 @@
-# architect -- Architecture Design Instruction Template
-
-> **Purpose**: Architecture design (make design decisions based on the plan report)
-> **Agent**: architect
-> **Prerequisite**: Runs after the plan movement
-
----
-
-## Template
-
-```
-Read the plan report ({report:plan.md}) and perform the architecture design.
-
-**Criteria for small tasks:**
-- Only 1-2 file changes
-- No design decisions needed
-- No technology selection needed
-
-For small tasks, skip the design report and
-match the rule for "Small task (no design needed)".
-
-**Tasks requiring design:**
-- 3 or more file changes
-- Adding new modules or features
-- Technology selection required
-- Architecture pattern decisions needed
-
-**Actions:**
-1. Evaluate the task scope
-2. Determine file structure
-3. Technology selection (if needed)
-4. Choose design patterns
-5. Create implementation guidelines for the Coder
-```
-
----
-
-## Typical rules
-
-```yaml
-rules:
-  - condition: Small task (no design needed)
-    next: implement
-  - condition: Design complete
-    next: implement
-  - condition: Insufficient information, cannot determine
-    next: ABORT
-```

package/builtins/en/templates/instructions/fix.md

@@ -1,86 +0,0 @@
-# fix -- Review Fix Instruction Template
-
-> **Purpose**: Fix issues identified by reviewers
-> **Agent**: coder
-> **Variations**: General fix / Supervise fix
-
----
-
-## Template (General fix)
-
-```
-Address the reviewer feedback.
-Check the session conversation history and fix the issues raised by reviewers.
-
-{Customize: Add report references for multiple reviews}
-**Review the review results:**
-- AI Review: {report:ai-review.md}
-- Architecture Review: {report:architecture-review.md}
-
-{Customize: For multiple reviews}
-**Important:** Fix ALL issues from ALL reviews without omission.
-
-**Required output (include headings)**
-## Work results
-- {Summary of work performed}
-## Changes made
-- {Summary of changes}
-## Test results
-- {Command and results}
-## Evidence
-- {List of verified files/searches/diffs/logs}
-```
-
----
-
-## Template (Supervise fix)
-
-```
-Fix the issues raised by the supervisor.
-
-The supervisor identified problems from a holistic perspective.
-Address items in order of priority.
-
-**Required output (include headings)**
-## Work results
-- {Summary of work performed}
-## Changes made
-- {Summary of changes}
-## Test results
-- {Command and results}
-## Evidence
-- {List of verified files/searches/diffs/logs}
-```
-
----
-
-## Unified required output sections
-
-All fix-type movements require these 4 output sections:
-
-| Section | Purpose |
-|---------|---------|
-| Work results | Summary of what was done |
-| Changes made | Specific changes |
-| Test results | Verification results |
-| Evidence | Verified facts (files, searches, diffs) |
-
----
-
-## Typical rules
-
-```yaml
-# General fix
-rules:
-  - condition: Fixes completed
-    next: reviewers
-  - condition: Cannot determine, insufficient information
-    next: plan
-
-# Supervise fix
-rules:
-  - condition: Supervisor's issues have been fixed
-    next: supervise
-  - condition: Cannot proceed with fixes
-    next: plan
-```

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

@@ -1,102 +0,0 @@
-# implement -- Implementation Instruction Template
-
-> **Purpose**: Coding and test execution
-> **Agent**: coder
-> **Reports**: Scope + Decisions (format embedded in template)
-
----
-
-## Template
-
-```
-{Customize: Adjust based on the source movement}
-Implement according to the plan from the plan movement.
-
-**Reports to reference:**
-- Plan: {report:plan.md}
-{Customize: Add if architect movement exists}
-- Design: {report:architecture.md} (if exists)
-
-Only reference files within the Report Directory shown in Piece Context.
-Do not search or reference other report directories.
-
-{Customize: Add if architect exists}
-**Important:** Do not make design decisions; follow the design determined in the architect movement.
-Report any unclear points or need for design changes.
-
-**Important**: Add unit tests alongside implementation.
-- Add unit tests for newly created classes/functions
-- Update relevant tests when modifying existing code
-- Test file placement: follow the project's conventions
-- Running tests is mandatory. After implementation, always run tests and verify results
-
-**Scope output contract (create at implementation start):**
-```markdown
-# Change Scope Declaration
-
-## Task
-{One-line task summary}
-
-## Planned Changes
-| Type | File |
-|------|------|
-| Create | `src/example.ts` |
-| Modify | `src/routes.ts` |
-
-## Estimated Size
-Small / Medium / Large
-
-## Impact Area
-- {Affected modules or features}
-```
-
-**Decisions output contract (at implementation end, only when decisions were made):**
-```markdown
-# Decision Log
-
-## 1. {Decision}
-- **Background**: {Why the decision was needed}
-- **Options considered**: {List of options}
-- **Rationale**: {Why this was chosen}
-```
-
-**Required output (include headings)**
-## Work results
-- {Summary of work performed}
-## Changes made
-- {Summary of changes}
-## Test results
-- {Command and results}
-```
-
----
-
-## Typical rules
-
-```yaml
-rules:
-  - condition: Implementation complete
-    next: {ai_review or reviewers}
-  - condition: Implementation not started (report only)
-    next: {ai_review or reviewers}
-  - condition: Cannot determine, insufficient information
-    next: {ai_review or reviewers}
-  - condition: User input needed
-    next: implement
-    requires_user_input: true
-    interactive_only: true
-```
-
----
-
-## Report settings
-
-```yaml
-report:
-  - Scope: coder-scope.md
-  - Decisions: coder-decisions.md
-```
-
-**Note**: Do not add sequence numbers to report filenames.
-Use `coder-scope.md`, not `02-coder-scope.md`.
-Sequence numbers depend on piece structure and hinder template reuse.

package/builtins/en/templates/instructions/plan.md

@@ -1,55 +0,0 @@
-# plan -- Planning Instruction Template
-
-> **Purpose**: Task analysis, requirements gathering, implementation strategy
-> **Agent**: planner, architect-planner
-> **Customization points**: Indicated by `{Customize:}`
-
----
-
-## Template
-
-```
-Analyze the task and create an implementation plan.
-
-**Note:** If Previous Response is present, this is a replan;
-revise the plan based on its content.
-
-{Customize: Handling unknowns -- add the following when using architect-planner}
-**Handling unknowns (important):**
-If there are unclear points in the task, investigate by reading the code and resolve them yourself.
-Only judge as "unclear" for external factors that cannot be resolved through investigation (e.g., user intent is ambiguous).
-
-**Actions:**
-1. Understand the task requirements
-2. {Customize: Add related code investigation if needed}
-3. Identify the impact scope
-4. Decide on the implementation approach
-```
-
----
-
-## Variations
-
-### A. Standard plan (using planner)
-
-Planning only. Design is delegated to the architect movement.
-
-### B. Plan + design (using architect-planner)
-
-For lightweight pieces that omit the architect movement.
-Use architect-planner instead of planner to include design decisions in the plan.
-Add self-resolution instructions for unknowns.
-
----
-
-## Typical rules
-
-```yaml
-rules:
-  - condition: Requirements are clear and implementable
-    next: {implement or architect}
-  - condition: User is asking a question (not an implementation task)
-    next: COMPLETE
-  - condition: Requirements are unclear, insufficient information
-    next: ABORT
-```

package/builtins/en/templates/instructions/review.md

@@ -1,101 +0,0 @@
-# review -- Review Instruction Template
-
-> **Purpose**: Review within parallel sub-steps (general purpose)
-> **Agent**: architecture-reviewer, qa-reviewer, security-reviewer, frontend-reviewer, ai-antipattern-reviewer, etc.
-> **Feature**: Personas carry domain knowledge, so instructions can be minimal
-
----
-
-## Template (Basic form)
-
-```
-{Customize: One sentence describing the review focus}
-Focus on **{review name}** review.
-{Customize: Add exclusions if applicable}
-Do not review AI-specific issues (handled in the ai_review movement).
-
-{Customize: Add if reference reports exist}
-**Reports to reference:**
-- Plan: {report:plan.md}
-- Implementation scope: {report:coder-scope.md}
-
-**Review aspects:**
-{Customize: Aspect list based on persona expertise}
-- {Aspect 1}
-- {Aspect 2}
-- {Aspect 3}
-```
-
----
-
-## Variations
-
-### A. Architecture review
-
-```
-Focus on **architecture and design** review.
-Do not review AI-specific issues (handled in the ai_review movement).
-
-**Reports to reference:**
-- Plan: {report:plan.md}
-- Implementation scope: {report:coder-scope.md}
-
-**Review aspects:**
-- Consistency with plan/design
-- Code quality
-- Appropriateness of change scope
-- Test coverage
-- Dead code
-- Call chain verification
-```
-
-### B. AI review (parallel sub-step)
-
-```
-Review the code for AI-specific issues:
-- Assumption verification
-- Plausible but incorrect patterns
-- Compatibility with the existing codebase
-- Scope creep detection
-```
-
-### C. Security review
-
-```
-Review changes from a security perspective. Check for these vulnerabilities:
-- Injection attacks (SQL, command, XSS)
-- Authentication/authorization flaws
-- Data exposure risks
-- Cryptographic weaknesses
-```
-
-### D. QA review
-
-```
-Review changes from a quality assurance perspective.
-
-**Review aspects:**
-- Test coverage and quality
-- Testing strategy (unit/integration/E2E)
-- Error handling
-- Logging and monitoring
-- Maintainability
-```
-
----
-
-## Design principles
-
-- **Keep instructions minimal**: Personas carry domain expertise, so instructions only specify the review target and focus
-- **Aspect lists may overlap with persona**: The instruction's aspect list serves as a reminder to the agent
-- **State exclusions explicitly**: Use instructions to define responsibility boundaries between reviewers
-
----
-
-## Typical rules
-
-```yaml
-rules:
-  - condition: approved
-  - condition: needs_fix
-```

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

@@ -1,106 +0,0 @@
-# supervise -- Final Verification Instruction Template
-
-> **Purpose**: Run tests/builds, verify all review results, give final approval
-> **Agent**: supervisor, dual-supervisor
-> **Reports**: Validation + Summary (format embedded in template)
-
----
-
-## Template
-
-```
-Run tests, verify builds, and perform final approval.
-
-{Customize: Review pass status -- for dual pieces where all reviews have passed}
-## Previous Reviews Summary
-Reaching this movement means all of the following reviews have been APPROVED:
-{Customize: Actual review list}
-- AI Review: APPROVED
-- Architecture Review: APPROVED
-
-**Full piece verification:**
-1. Does the implementation match the plan ({report:plan.md}) {Customize: Add design report if applicable}?
-2. Have all review movement findings been addressed?
-3. Has the original task objective been achieved?
-
-**Report verification:** Read all reports in the Report Directory and
-check for any unaddressed improvement suggestions.
-
-**Validation output contract:**
-```markdown
-# Final Verification Results
-
-## Result: APPROVE / REJECT
-
-## Verification Summary
-| Item | Status | Verification Method |
-|------|--------|-------------------|
-| Requirements met | Pass | Compared against requirements list |
-| Tests | Pass | `npm test` (N passed) |
-| Build | Pass | `npm run build` succeeded |
-| Functional check | Pass | Main flow verified |
-
-## Artifacts
-- Created: {created files}
-- Modified: {modified files}
-
-## Incomplete items (if REJECT)
-| # | Item | Reason |
-|---|------|--------|
-| 1 | {item} | {reason} |
-```
-
-**Summary output contract (APPROVE only):**
-```markdown
-# Task Completion Summary
-
-## Task
-{Original request in 1-2 sentences}
-
-## Result
-Complete
-
-## Changes
-| Type | File | Description |
-|------|------|-------------|
-| Create | `src/file.ts` | Description |
-
-## Review Results
-| Review | Result |
-|--------|--------|
-{Customize: Adjust list based on the piece's review structure}
-| AI Review | APPROVE |
-| Architecture | APPROVE |
-| Supervisor | APPROVE |
-
-## Verification Commands
-```bash
-npm test
-npm run build
-```
-```
-```
-
----
-
-## Typical rules
-
-```yaml
-rules:
-  - condition: All checks passed
-    next: COMPLETE
-  - condition: Requirements not met, test failure, build error
-    next: plan  # or fix_supervisor
-```
-
----
-
-## Report settings
-
-```yaml
-report:
-  - Validation: supervisor-validation.md
-  - Summary: summary.md
-```
-
-**Note**: Do not add sequence numbers to report filenames.

package/builtins/en/templates/personas/character.md

@@ -1,45 +0,0 @@
-# {Character Name}
-
-You are {Character Name} of {System Name}. {One sentence describing the character's personality and traits}.
-
-## Role Boundaries
-
-**Do:**
-- {Evaluation aspect 1}
-- {Evaluation aspect 2}
-- {Evaluation aspect 3}
-
-**Don't:**
-- {What this character does not do 1}
-- {What this character does not do 2}
-- {What this character does not do 3}
-
-## Behavioral Principles
-
-- {Speech pattern/tone characteristic 1}
-- {Speech pattern/tone characteristic 2}
-- {Speech pattern/tone characteristic 3}
-- {Character's position}
-- {Role within the group}
-
-**Perspective on other characters:**
-- To {Character A}: {Assessment and critique}
-- To {Character B}: {Assessment and critique}
-
-## Domain Knowledge
-
-### Thinking Characteristics
-
-**{Trait 1 label}:** {Description. How they think and make judgments}
-
-**{Trait 2 label}:** {Description}
-
-**{Trait 3 label}:** {Description}
-
-### Judgment Criteria
-
-1. {Criterion 1} - {What to look for}
-2. {Criterion 2} - {What to look for}
-3. {Criterion 3} - {What to look for}
-4. {Criterion 4} - {What to look for}
-5. {Criterion 5} - {What to look for}