takt 0.30.0 → 0.32.0

package/README.md

@@ -12,7 +12,7 @@ TAKT is built with TAKT itself (dogfooding).
 
 **Batteries included** — Architecture, security, and AI antipattern review criteria are built in. Ship code that meets a quality bar from day one.
 
-**Practical** — A tool for daily development, not demos. Talk to AI to refine requirements, queue tasks, and run them. Automatic worktree isolation, PR creation, and retry on failure.
+**Practical** — A tool for daily development, not demos. Talk to AI to refine requirements, queue tasks, and run them. Worktree isolation on task execution, PR creation, and retry on failure.
 
 **Reproducible** — Execution paths are declared in YAML, keeping results consistent. Pieces are shareable — a workflow built by one team member can be used by anyone else to run the same quality process. Every step is logged in NDJSON for full traceability from task to PR.
 
@@ -39,7 +39,7 @@ Optional:
 npm install -g takt
 ```
 
-### Talk to AI, then execute
+### Talk to AI and queue tasks
 
 ```
 $ takt
@@ -55,21 +55,24 @@ Select piece:
 [AI clarifies requirements and organizes the task]
 
 > /go
-```
 
-TAKT creates an isolated worktree, runs the piece (plan → implement → review → fix loop), and offers to create a PR when done.
+Proposed task:
+  ...
 
-### Queue tasks, then batch execute
+What would you like to do?
+    Execute now
+    Create GitHub Issue
+  ❯ Queue as task          # ← normal flow
+    Continue conversation
+```
 
-Use `takt` to queue multiple tasks, then execute them all at once:
+Choosing "Queue as task" saves the task to `.takt/tasks/`. Run `takt run` to execute — TAKT creates an isolated worktree, runs the piece (plan → implement → review → fix loop), and offers to create a PR when done.
 
 ```bash
-# Queue tasks through conversation
-takt
-> Refactor the auth module
-> /go          # queues the task
+# Execute queued tasks
+takt run
 
-# Or queue from GitHub Issues
+# You can also queue from GitHub Issues
 takt add #6
 takt add #12
 
@@ -77,6 +80,8 @@ takt add #12
 takt run
 ```
 
+> **"Execute now"** runs the piece directly in your current directory without worktree isolation. Useful for quick experiments, but note that changes go straight into your working tree.
+
 ### Manage results
 
 ```bash
@@ -256,7 +261,7 @@ await engine.run();
 | [Task Management](./docs/task-management.md) | Task queuing, execution, isolation |
 | [Data Flow](./docs/data-flow.md) | Internal data flow and architecture diagrams |
 | [CI/CD Integration](./docs/ci-cd.md) | GitHub Actions and pipeline mode |
-| [Provider Sandbox](./docs/provider-sandbox.md) | Sandbox configuration for providers |
+| [Provider Sandbox & Permissions](./docs/provider-sandbox.md) | Sandbox, permission modes, and network access for Codex / OpenCode / Claude |
 | [Changelog](./CHANGELOG.md) ([日本語](./docs/CHANGELOG.ja.md)) | Version history |
 | [Security Policy](./SECURITY.md) | Vulnerability reporting |
 

package/builtins/en/config.yaml

@@ -2,17 +2,35 @@
 # Location: ~/.takt/config.yaml
 
 # =====================================
-# General settings (piece-independent)
+# General settings
 # =====================================
-# Note: this template contains global-only settings for ~/.takt/config.yaml.
 language: en        # UI language: en | ja
 
+# Default provider and model
+# provider: claude                    # Default provider: claude | codex | opencode | cursor | copilot | mock
+# model: sonnet                       # Default model (passed directly to provider)
+
 # Execution control
 # worktree_dir: ~/takt-worktrees   # Base directory for shared clone execution
 # prevent_sleep: false             # Prevent macOS idle sleep while running
 # auto_fetch: false                # Fetch before clone to keep shared clones up-to-date
+# base_branch: main                # Base branch to clone from (default: current branch)
+# concurrency: 1                   # Number of tasks to run concurrently in takt run (1-10)
+# task_poll_interval_ms: 500       # Polling interval in ms for picking up new tasks (100-5000)
+
+# PR / branch
+# auto_pr: false                   # Auto-create PR after worktree execution
+# draft_pr: false                  # Create PR as draft
+# branch_name_strategy: romaji     # Branch name generation: romaji | ai
+
+# Pipeline execution
+# pipeline:
+#   default_branch_prefix: "takt/"         # Branch prefix for pipeline-created branches
+#   commit_message_template: "{title}"     # Commit message template. Variables: {title}, {issue}
+#   pr_body_template: "{report}"           # PR body template. Variables: {issue_body}, {report}, {issue}
 
 # Output / notifications
+# minimal_output: false            # Suppress detailed agent output
 # notification_sound: true         # Master switch for sounds
 # notification_sound_events:       # Per-event sound toggle (unset means true)
 #   iteration_limit: true
@@ -20,12 +38,63 @@ language: en        # UI language: en | ja
 #   piece_abort: true
 #   run_complete: true
 #   run_abort: true
-# verbose: false                   # Shortcut: enable trace/debug and set logging.level=debug
 # logging:
 #   level: info                    # Log level for console and file output
 #   trace: true                    # Generate human-readable execution trace report (trace.md)
 #   debug: false                   # Enable debug.log + prompts.jsonl
-#   provider_events: false          # Persist provider stream events
+#   provider_events: false         # Persist provider stream events
+#   usage_events: false            # Persist usage event logs
+
+# Analytics
+# analytics:
+#   enabled: true                  # Enable local analytics collection
+#   events_path: ~/.takt/analytics/events  # Custom events directory
+#   retention_days: 30             # Retention period for event files
+
+# Interactive mode
+# interactive_preview_movements: 3 # Number of movement previews in interactive mode (0-10)
+
+# Per-persona provider/model overrides
+# persona_providers:
+#   coder:
+#     provider: claude
+#     model: opus
+#   reviewer:
+#     provider: codex
+#     model: gpt-5.2-codex
+
+# Provider-specific options (lowest priority, overridden by piece/movement)
+# provider_options:
+#   codex:
+#     network_access: true
+#   claude:
+#     sandbox:
+#       allow_unsandboxed_commands: true
+
+# Provider permission profiles
+# provider_profiles:
+#   claude:
+#     default_permission_mode: edit
+#   codex:
+#     default_permission_mode: edit
+
+# Runtime environment preparation
+# runtime:
+#   prepare: [node, gradle, ./custom-script.sh]
+
+# Piece-level overrides
+# piece_overrides:
+#   quality_gates:
+#     - "All tests pass"
+#   quality_gates_edit_only: true
+#   movements:
+#     review:
+#       quality_gates:
+#         - "No security vulnerabilities"
+#   personas:
+#     coder:
+#       quality_gates:
+#         - "Code follows conventions"
 
 # Credentials (environment variables take priority)
 # anthropic_api_key: "sk-ant-..." # Claude API key
@@ -35,7 +104,14 @@ language: en        # UI language: en | ja
 # groq_api_key: "..."              # Groq API key
 # openrouter_api_key: "..."        # OpenRouter API key
 # opencode_api_key: "..."          # OpenCode API key
-# codex_cli_path: "/absolute/path/to/codex"  # Absolute path to Codex CLI
+# cursor_api_key: "..."            # Cursor API key
+
+# CLI paths
+# codex_cli_path: "/absolute/path/to/codex"    # Absolute path to Codex CLI
+# claude_cli_path: "/absolute/path/to/claude"  # Absolute path to Claude Code CLI
+# cursor_cli_path: "/absolute/path/to/cursor"  # Absolute path to cursor-agent CLI
+# copilot_cli_path: "/absolute/path/to/copilot" # Absolute path to Copilot CLI
+# copilot_github_token: "ghp_..."              # Copilot GitHub token
 
 # Misc
 # bookmarks_file: ~/.takt/preferences/bookmarks.yaml  # Bookmark file location

package/builtins/en/facets/instructions/dual-team-leader-implement.md

@@ -0,0 +1,32 @@
+Analyze the implementation task and, if decomposition is appropriate, split into multiple parts for parallel execution.
+
+**Important:** Reference the plan report: {report:plan.md}
+
+**Steps:**
+
+1. Assess whether decomposition is appropriate
+   - Identify files to change and check inter-file dependencies
+   - If cross-cutting concerns exist (shared types, IDs, events), implement in a single part
+   - If few files are involved, or the task is a rename/refactoring, implement in a single part
+
+2. If decomposing: prioritize splitting along frontend and backend boundaries
+   - Splitting between frontend (UI, components, styles) and backend (API, logic, data layer) is the most natural decomposition axis
+   - When API contracts (request/response types) are defined, parallel implementation works well
+   - When API contracts are undecided, implement backend first in one part and defer frontend
+   - For frontend-only or backend-only tasks, group by layer/module
+   - If there are type or interface dependencies, keep both sides in the same group
+   - Never assign the same file to multiple parts
+   - Keep test files and implementation files in the same part
+
+3. Assign file ownership exclusively to each part
+   - Each part's instruction must clearly state:
+     - **Responsible files** (list of files to create/modify)
+     - **Reference-only files** (read-only, modification prohibited)
+     - **Implementation task** (what and how to implement)
+     - **Completion criteria** (implementation of responsible files is complete)
+   - If tests are already written, instruct parts to implement so existing tests pass
+   - Do not include build checks (all parts complete first, then build is verified together)
+
+**Constraints:**
+- Parts do not run tests (handled by subsequent movements)
+- Do not modify files outside your responsibility (causes conflicts)

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

@@ -1,9 +1,11 @@
 Run tests, verify the build, and perform final approval.
 
 **Overall piece verification:**
-1. Whether the plan and implementation results are consistent
-2. Whether findings from each review movement have been addressed
-3. Whether each task spec requirement has been achieved
+1. Check all reports in the report directory and verify overall piece consistency
+   - Does implementation match the plan?
+   - Were all review movement findings properly addressed?
+   - Was the original task objective achieved?
+2. Whether each task spec requirement has been achieved
    - Extract requirements one by one from the task spec
    - For each requirement, identify the implementing code (file:line)
    - Verify the code actually fulfills the requirement (read the file, run the test)

package/builtins/en/facets/instructions/team-leader-implement.md

@@ -1,17 +1,19 @@
-Decompose the implementation task into subtasks by file ownership and execute them in parallel. Assign files exclusively to each part to prevent conflicts.
+Analyze the implementation task and, if decomposition is appropriate, split into multiple parts for parallel execution.
 
 **Important:** Reference the plan report: {report:plan.md}
 
 **Steps:**
 
-1. Identify files to create/modify
-   - Reference the plan report and test scope to list all files to change
-   - Review the actual codebase to fill in any missing information
+1. Assess whether decomposition is appropriate
+   - Identify files to change and check inter-file dependencies
+   - If cross-cutting concerns exist (shared types, IDs, events), implement in a single part
+   - If few files are involved, or the task is a rename/refactoring, implement in a single part
 
-2. Group files by layer/module
+2. If decomposing: group files by layer/module
    - Create groups based on high cohesion (e.g., Domain layer / Infrastructure layer / API layer)
    - If there are type or interface dependencies, keep both sides in the same group
    - Never assign the same file to multiple parts
+   - Keep test files and implementation files in the same part
 
 3. Assign file ownership exclusively to each part
    - Each part's instruction must clearly state:

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

@@ -12,14 +12,13 @@ Refer only to files within the Report Directory shown in the Piece Context. Do n
    - Does a new status/state merge into an existing workflow?
    - Does a new option propagate through a call chain to the endpoint?
    - If any apply, create integration tests
-5. Run the build (type check) to verify test code has no syntax errors
 
 **Test writing guidelines:**
 - Follow the project's existing test patterns (naming conventions, directory structure, helpers)
 - Write tests in Given-When-Then structure
 - One concept per test. Do not mix multiple concerns in a single test
 - Cover happy path, error cases, boundary values, and edge cases
-- Write tests that are expected to pass after implementation is complete
+- Write tests that are expected to pass after implementation is complete (build errors and test failures are expected at this stage)
 
 **Scope output contract (create at the start):**
 ```markdown
@@ -55,5 +54,3 @@ Small / Medium / Large
 - {Summary of actions taken}
 ## Changes made
 - {List of test files created}
-## Build results
-- {Build execution results}

package/builtins/en/facets/knowledge/cqrs-es.md

@@ -408,6 +408,56 @@ Checklist:
 | Query side tests don't create data via Command | Recommended |
 | Integration tests consider Axon async processing | Required |
 
+## Master Data and CRUD
+
+Not everything in a CQRS+ES system needs event sourcing. Master data (reference data) with simple characteristics is better implemented as plain CRUD — it's simpler and easier to maintain.
+
+However, don't mechanically decide "it's master data, so CRUD". The more criteria below that apply, the more CRUD is suitable. Conversely, if even one requirement calls for CQRS+ES, consider adopting it.
+
+**Criteria for determining CRUD is sufficient:**
+
+| Aspect | Leans CRUD | Leans CQRS+ES |
+|--------|-----------|---------------|
+| Business requirements | Just "manage X" with no special mentions | Specific business rules or constraints |
+| Logic evolution | Simple reference/update, no foreseeable complexity | State transitions or lifecycle may grow complex |
+| Change history / audit | No need to track "who changed what when" | Change history or audit trail required |
+| Domain events | Changes don't affect other aggregates or processes | Changes trigger downstream processes |
+| Consistency scope | Self-contained, no cross-aggregate consistency needed | Must maintain consistency with other aggregates |
+| Point-in-time queries | No "what was the state at time T" queries | Point-in-time queries required |
+
+**Typical CRUD candidates:**
+- Code masters such as prefecture/country codes
+- Classification masters such as categories and tags
+- Configuration values, constant tables
+
+**Cases where CQRS+ES is justified:**
+- Product master, but price change history tracking is needed
+- Organization master, but changes trigger permission recalculation
+- Business partner master, but has credit assessment state transitions
+
+```kotlin
+// CRUD is sufficient: Simple category master
+@Entity
+data class Category(
+    @Id val categoryId: String,
+    val name: String,
+    val displayOrder: Int
+)
+
+// CQRS+ES is appropriate: Product with price change history tracking
+data class Product(
+    val productId: String,
+    val currentPrice: Money
+) {
+    fun changePrice(newPrice: Money, reason: String): PriceChangedEvent {
+        require(newPrice.amount > BigDecimal.ZERO) { "Price must be positive" }
+        return PriceChangedEvent(productId, currentPrice, newPrice, reason)
+    }
+}
+```
+
+Even when implementing with CRUD, other aggregates in the CQRS+ES system reference CRUD entities by ID. The principle that CRUD entities don't directly access aggregate internal state still applies.
+
 ## Infrastructure Layer
 
 Check:

package/builtins/en/facets/knowledge/security.md

@@ -98,6 +98,56 @@ app.get('/user/:id', authorize('read:user'), (req, res) => {
 - Missing type checks → REJECT
 - No size limits set → REJECT
 
+## Logging & Masking
+
+Prevent sensitive information from leaking into logs and responses.
+
+**Never log:**
+- Passwords, tokens, API keys
+- Credit card numbers, personal identification numbers
+- Session IDs, authentication header values
+- Personal information (email, phone) unless necessary for debugging
+
+**Masking patterns:**
+
+```typescript
+// NG - Password exposed in logs
+logger.info('User login attempt', { email, password })
+
+// OK - Exclude sensitive fields
+logger.info('User login attempt', { email })
+```
+
+```kotlin
+// NG - Logging entire request object
+logger.info("Request: {}", request)
+
+// OK - Log only safe fields
+logger.info("Request: userId={}, action={}", request.userId, request.action)
+```
+
+**Structured logging field filtering:**
+
+When passing objects to log output, ensure `toString()` or JSON serialization does not include sensitive fields.
+
+```kotlin
+// NG - data class toString() includes password
+data class UserCredentials(val email: String, val password: String)
+
+// OK - Override toString() to mask sensitive fields
+data class UserCredentials(val email: String, val password: String) {
+    override fun toString(): String = "UserCredentials(email=$email, password=***)"
+}
+```
+
+| Criteria | Verdict |
+|----------|---------|
+| Log output contains passwords, tokens, or API keys | REJECT |
+| Error responses contain stack traces or internal paths | REJECT |
+| data class toString() exposes sensitive fields | REJECT |
+| Sensitive info can be output regardless of log level | REJECT |
+| Debug logs contain PII but disabled in production | Warning. Risk of misconfiguration |
+
 ## Cryptography
 
 - Use of weak crypto algorithms → REJECT

package/builtins/en/facets/knowledge/task-decomposition.md

@@ -0,0 +1,60 @@
+# Task Decomposition Knowledge
+
+## Decomposition Feasibility
+
+Before splitting a task into multiple parts, assess whether decomposition is appropriate. Conditions that prohibit decomposition and REJECT criteria are defined in the Task Decomposition Policy. This section explains the underlying reasoning.
+
+### Decision Criteria Table (Rationale)
+
+| Perspective | Detection Pattern | Recommended Judgment | Rationale (Why) |
+|-------------|-------------------|----------------------|-----------------|
+| Shared contracts (ID/type) | A new ID/type is defined in one part and referenced by another | Do not decompose (single part) | Producer/consumer mismatches in type, naming, and handoff are common |
+| Event chains | Both emitter and receiver must be changed together | Do not decompose (single part) | Bidirectional assumptions drift and cause runtime inconsistencies |
+| Interface changes | Existing signature change + multiple call-site updates required | Do not decompose (single part) | Missed call-site updates easily lead to build/runtime failures |
+| File ownership overlap | Same file assigned to multiple parts | Do not decompose (restructure plan) | Overwrites/conflicts create repeated REJECT in review cycles |
+| Layer independence | API/Domain/Infra boundaries are clear and dependencies are one-way | Decomposition allowed | Clear boundaries reduce coupling across parts |
+
+### Detecting Cross-Cutting Concerns
+
+When any of the following apply, independent parts cannot maintain consistency. Consolidate into a single part.
+
+- A new ID, key, or type is generated in one module and consumed in another
+- Both the event emitter and event receiver need changes
+- An existing interface signature changes, requiring updates to all call sites
+
+## Grouping Priority
+
+When decomposition is appropriate, use the following criteria to group files.
+
+1. **By dependency direction** — keep dependency source and target in the same part
+2. **By layer** — domain layer / infrastructure layer / API layer
+3. **By feature** — independent functional units
+
+## Failure Patterns
+
+### Part Overlap
+
+When two parts own the same file or feature, sub-agents overwrite each other's changes, causing repeated REJECT in reviews.
+
+```
+// NG: part-2 and part-3 own the same file
+part-2: taskInstructionActions.ts — instruct confirmation dialog
+part-3: taskInstructionActions.ts — requeue confirmation dialog
+
+// OK: consolidate into one part
+part-1: taskInstructionActions.ts — both instruct/requeue confirmation dialogs
+```
+
+### Shared Contract Mismatch
+
+When part A generates an ID that part B consumes, both parts implement independently, leading to mismatches in ID name, type, or passing mechanism.
+
+```
+// NG: shared contract across independent parts
+part-1: generates phaseExecutionId
+part-2: consumes phaseExecutionId
+→ part-1 uses string, part-2 expects number → integration error
+
+// OK: single part for consistent implementation
+part-1: implements phaseExecutionId from generation to consumption
+```

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

@@ -81,15 +81,7 @@ You are the **human proxy** in the automated piece. Before approval, verify the
 | Production ready | No mock/stub/TODO remaining? |
 | Operation | Actually works as expected? |
 
-### 6. Backward Compatibility Code Detection
-
-**Backward compatibility code is unnecessary unless explicitly instructed.** REJECT if found:
-
-- Unused re-exports, `_var` renames, `// removed` comments
-- Fallbacks, old API maintenance, migration code
-- Legacy support kept "just in case"
-
-### 7. Spec Compliance Final Check
+### 6. Spec Compliance Final Check
 
 **Final verification that changes comply with the project's documented specifications.**
 
@@ -115,66 +107,6 @@ Additions can be reverted, but restoring deleted flows is difficult.
 - A "UI fix" task includes structural changes to backend domain models
 - A "display change" task rewrites business logic flows
 
-### 8. Piece Overall Review
-
-**Check all reports in the report directory and verify overall piece consistency.**
-
-Check:
-- Does implementation match the plan (00-plan.md)?
-- Were all review step issues properly addressed?
-- Was the original task objective achieved?
-
-**Piece-wide issues:**
-| Issue | Action |
-|-------|--------|
-| Plan-implementation gap | REJECT - Request plan revision or implementation fix |
-| Unaddressed review feedback | REJECT - Point out specific unaddressed items |
-| Deviation from original purpose | REJECT - Request return to objective |
-| Scope creep | REJECT - Deletions outside task order must be reverted |
-
-### 9. Improvement Suggestion Check
-
-**Check review reports for unaddressed improvement suggestions.**
-
-Check:
-- "Improvement Suggestions" section in Architect report
-- Warnings and suggestions in AI Reviewer report
-- Recommendations in Security report
-
-**If there are unaddressed improvement suggestions:**
-- Judge if the improvement should be addressed in this task
-- If it should be addressed, **REJECT** and request fix
-- If it should be addressed in next task, record as "technical debt" in report
-
-**Judgment criteria:**
-| Type of suggestion | Decision |
-|--------------------|----------|
-| Minor fix in same file | Address now (REJECT) |
-| Fixable in seconds to minutes | Address now (REJECT) |
-| Redundant code / unnecessary expression removal | Address now (REJECT) |
-| Affects other features | Address in next task (record only) |
-| External impact (API changes, etc.) | Address in next task (record only) |
-| Requires significant refactoring (large scope) | Address in next task (record only) |
-
-### Boy Scout Rule
-
-**"Functionally harmless" is not a free pass.** Classifying a near-zero-cost fix as "non-blocking" or "next task" is a compromise. There is no guarantee it will be addressed in a future task, and it accumulates as technical debt.
-
-**Principle:** If a reviewer found it and it can be fixed in minutes, make the coder fix it now. Do not settle for recording it as a "non-blocking improvement suggestion."
-
-## Workaround Detection
-
-**REJECT** if any of the following remain:
-
-| Pattern | Example |
-|---------|---------|
-| TODO/FIXME | `// TODO: implement later` |
-| Commented out | Code that should be deleted remains |
-| Hardcoded | Values that should be config are hardcoded |
-| Mock data | Dummy data unusable in production |
-| console.log | Forgotten debug output |
-| Skipped tests | `@Disabled`, `.skip()` |
-
 ## Important
 
 - **Actually run**: Don't just look at files, execute and verify

package/builtins/en/facets/policies/task-decomposition.md

@@ -0,0 +1,53 @@
+# Task Decomposition Policy
+
+Ensure decomposition quality for parallel parts.
+
+## Principles
+
+| Principle | Criteria |
+|-----------|----------|
+| Explicit decomposition judgment | Evaluate the knowledge base criteria table before decomposing; state the judgment explicitly |
+| File exclusivity | Each file is owned by exactly one part. No exceptions |
+| Dependency direction | If parts have dependencies, merge them into a single part |
+| Tests with implementation | Test files and corresponding implementation files belong to the same part |
+| Quality gates aggregate | Build/test execution belongs in a part that aggregates all other parts' results |
+
+## File Exclusivity
+
+When multiple parts edit the same file, sub-agents overwrite each other's changes.
+
+| Criteria | Judgment |
+|----------|----------|
+| Same file appears in multiple parts' assignments | REJECT |
+| Type definition file and consumer file in different parts | REJECT (merge into the type definition part) |
+| Assigned files described as "touch as needed on failure" or similar vague expressions | REJECT (determine files upfront) |
+| Test file and implementation file in different parts | REJECT |
+| Wildcard assignments (`src/**/*`) overlapping with another part's scope | REJECT |
+
+## Conditions That Prohibit Decomposition
+
+When any of the following apply, implement in a single part. Do not decompose.
+
+| Criteria | Judgment |
+|----------|----------|
+| Broad rename or refactor | Single part |
+| Shared types or IDs cross multiple parts | Single part |
+| Fewer than 5 files to change | Single part |
+| Existing interface signature change + updating all call sites | Single part |
+
+## Quality Gate Parts
+
+Parts responsible for build/test execution follow different rules from implementation parts.
+
+| Criteria | Judgment |
+|----------|----------|
+| Quality gate part includes implementation part files in its assignment | REJECT |
+| Quality gate split into multiple parts | REJECT (merge into one) |
+| Quality gate part's fix scope is "anything" | REJECT (specify target files upfront) |
+
+## Prohibited
+
+- **Skipping decomposition judgment** - decomposing without evaluating the knowledge criteria table
+- **Assigning the same file to multiple parts** - including via wildcard assignments
+- **Separating dependent changes** - putting type definitions and consumers, or event emitters and receivers, in different parts
+- **Parts with undefined file assignments** - vague assignments like "fix as needed" or "modify if required"

package/builtins/en/piece-categories.yaml

@@ -33,18 +33,20 @@ piece_categories:
       - terraform
   🔍 Review:
     pieces:
-      - review
-      - review-fix
-      - frontend-review
-      - frontend-review-fix
-      - backend-review
-      - backend-review-fix
-      - dual-review
-      - dual-review-fix
-      - dual-cqrs-review
-      - dual-cqrs-review-fix
-      - backend-cqrs-review
-      - backend-cqrs-review-fix
+      - review-default
+      - review-fix-default
+      - review-frontend
+      - review-fix-frontend
+      - review-backend
+      - review-fix-backend
+      - review-dual
+      - review-fix-dual
+      - review-dual-cqrs
+      - review-fix-dual-cqrs
+      - review-backend-cqrs
+      - review-fix-backend-cqrs
+      - review-takt-default
+      - review-fix-takt-default
   🧪 Testing:
     pieces:
       - unit-test
@@ -52,8 +54,8 @@ piece_categories:
   🎵 TAKT Development:
     pieces:
       - takt-default
-      - takt-default-team-leader
-      - takt-default-review-fix
+      - review-takt-default
+      - review-fix-takt-default
   Others:
     pieces:
       - research

package/builtins/en/pieces/backend-cqrs-mini.yaml

@@ -15,7 +15,7 @@ loop_monitors:
     threshold: 3
     judge:
       persona: supervisor
-      instruction_template: loop-monitor-reviewers-fix
+      instruction: loop-monitor-reviewers-fix
       rules:
         - condition: converging (findings decreasing, fixes applied)
           next: fix_both