takt 0.33.2 → 0.35.0

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

@@ -19,6 +19,14 @@ you verify "**was the right thing built (Validation)**".
 - Fix code
 - Re-run tests or builds
 
+## 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
+- 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
+
 ## Human-in-the-Loop Checkpoint
 
 You are the **human proxy** in the automated piece. Before approval, verify the following.
@@ -40,6 +48,7 @@ You are the **human proxy** in the automated piece. Before approval, verify the
 ### 1. Requirements Fulfillment (Most Critical)
 
 - Verify all requirements individually; do NOT APPROVE if any single requirement is unfulfilled
+- If a sentence contains multiple conditions, split it into the smallest independently verifiable rows
 - Can it **actually** do what was claimed?
 - Are implicit requirements (naturally expected behavior) met?
 - "Mostly done" or "main parts complete" is NOT grounds for APPROVE. All requirements must be fulfilled
@@ -115,5 +124,6 @@ Additions can be reverted, but restoring deleted flows is difficult.
 - **Don't take at face value**: Don't trust "done", verify yourself
 - **Be specific**: Clarify "what" is "how" problematic
 - **Do not infer command outcomes**: If there is no evidence, mark it unverified rather than guessing
+- **Do not convert unverified items into passed or failed**: Keep them explicitly unverified unless evidence exists
 
 **Remember**: You are the final gatekeeper. What passes through here reaches the user. Don't let "probably fine" pass.

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

@@ -77,6 +77,93 @@ function createEngine(config, cwd: string) {
 3. **Is there a path to pass the value from above?** → If not, add a parameter or field
 4. **Do related values have invariants?** → Cross-validate at load/setup time
 
+## Unify Resolution Responsibility
+
+Values that can be decided early — config, options, providers, paths, permissions — must be resolved once at the boundary. Do not re-resolve the same value in multiple layers.
+
+| Pattern | Judgment | Reason |
+|---------|----------|--------|
+| Resolve at the entry point and pass the value explicitly downward | OK | Source of truth stays traceable |
+| Delegate resolution to a dedicated method/object | OK | Preserves a single source of truth |
+| Resolve the same config separately in upper and lower layers | REJECT | Creates precedence drift |
+| Resolve separately for display and execution | REJECT | Logs and behavior diverge |
+| Stack `if` branches for config resolution inside main flow | REJECT | Leaks details into orchestration |
+
+```typescript
+// REJECT - Each layer resolves config independently
+function executeTask(options) {
+  const provider = options.provider ?? loadGlobalConfig().provider;
+  return runAgent({
+    provider,
+    stepProvider: resolveProviderForStep(options.step),
+  });
+}
+
+function runAgent(options) {
+  const provider = options.provider ?? resolveProviderFromConfig();
+  return getProvider(provider).call();
+}
+
+// OK - Resolve at the boundary, then use resolved values only
+function executeTask(options) {
+  const resolved = resolveExecutionContext(options);
+  return runAgent({
+    resolvedProvider: resolved.provider,
+    resolvedModel: resolved.model,
+  });
+}
+
+function runAgent(options) {
+  return getProvider(options.resolvedProvider).call();
+}
+```
+
+Decision criteria:
+1. Can this value be fixed before execution starts? → Resolve it at the boundary
+2. Does the same precedence logic exist in 2+ places? → Centralize it in a dedicated method/object
+3. Does a lower layer know config sources directly? → Pass only resolved values
+4. Are display, execution, and persistence resolving separately? → Share the same resolved result
+
+## Phase Separation
+
+Separate input collection, interpretation/normalization, execution, and output/side effects into distinct phases. Do not keep receiving unresolved input in the middle of loops or main processing and interpret it on the spot.
+
+| Pattern | Judgment | Reason |
+|---------|----------|--------|
+| Split into stages such as `RawOptions -> ResolvedOptions -> ExecutionContext` | OK | Responsibility of each phase is explicit |
+| Normalize input before entering the loop | OK | Every iteration runs on the same assumptions |
+| Resolve `options ?? config ?? env` inside every iteration | REJECT | Iteration assumptions can drift |
+| Mix input interpretation and execution logic per iteration | REJECT | Intent of the flow becomes unreadable |
+| Even when true streaming/optimization forces per-item handling, isolate interpretation in a dedicated method | OK | Keeps minimum responsibility separation |
+
+```typescript
+// REJECT - Interpret input inside the loop every time
+for (const step of steps) {
+  const provider = options.provider
+    ?? step.provider
+    ?? projectConfig.provider
+    ?? globalConfig.provider;
+  const result = await executeStep(step, { provider });
+  printResult(result);
+}
+
+// OK - Resolve first, loop only executes
+const context = resolveExecutionContext(rawOptions, steps);
+
+for (const step of context.steps) {
+  const result = await executeStep(step, {
+    resolvedProvider: step.resolvedProvider,
+  });
+  printResult(result);
+}
+```
+
+Decision criteria:
+1. Is a branch inside the loop business logic or input interpretation? → Move input interpretation outside
+2. Is the same interpretation repeated for each iteration? → Normalize once up front
+3. Does an execution function accept raw input directly? → Convert to a `Resolved*` type first
+4. Does optimization require incremental handling? → At least extract interpretation into a dedicated function
+
 ## Abstraction
 
 ### Think Before Adding Conditionals

package/builtins/en/{piece-categories.yaml → workflow-categories.yaml}

@@ -1,38 +1,38 @@
-piece_categories:
+workflow_categories:
   🚀 Quick Start:
-    pieces:
+    workflows:
       - default
       - frontend-mini
       - backend-mini
       - compound-eye
   ⚡ Mini:
-    pieces:
+    workflows:
       - frontend-mini
       - backend-mini
       - backend-cqrs-mini
       - dual-mini
       - dual-cqrs-mini
   🎨 Frontend:
-    pieces:
+    workflows:
       - frontend
       - frontend-mini
   ⚙️ Backend:
-    pieces:
+    workflows:
       - backend
       - backend-mini
       - backend-cqrs
       - backend-cqrs-mini
   🔧 Dual:
-    pieces:
+    workflows:
       - dual
       - dual-mini
       - dual-cqrs
       - dual-cqrs-mini
   🏗️ Infrastructure:
-    pieces:
+    workflows:
       - terraform
   🔍 Review:
-    pieces:
+    workflows:
       - review-default
       - review-fix-default
       - review-frontend
@@ -55,12 +55,12 @@ piece_categories:
       - audit-architecture-backend
       - audit-architecture-dual
   🎵 TAKT Development:
-    pieces:
+    workflows:
       - takt-default
       - review-takt-default
       - review-fix-takt-default
   Others:
-    pieces:
+    workflows:
       - research
       - deep-research
       - magi

package/builtins/en/{pieces → workflows}/audit-architecture-backend.yaml

@@ -1,7 +1,7 @@
 name: audit-architecture-backend
 description: Backend-focused architecture audit. Enumerate service modules and boundaries, then produce an issue-ready report without modifying code
-max_movements: 12
-initial_movement: plan
+max_steps: 12
+initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
@@ -17,7 +17,7 @@ loop_monitors:
         - condition: Quality is insufficient with no prospect of improvement
           next: ABORT
 
-movements:
+steps:
   - name: plan
     persona: planner
     knowledge:

package/builtins/en/{pieces → workflows}/audit-architecture-dual.yaml

@@ -1,7 +1,7 @@
 name: audit-architecture-dual
 description: Full-stack architecture audit. Enumerate frontend/backend boundaries and cross-layer wiring, then produce an issue-ready report without modifying code
-max_movements: 12
-initial_movement: plan
+max_steps: 12
+initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
@@ -17,7 +17,7 @@ loop_monitors:
         - condition: Quality is insufficient with no prospect of improvement
           next: ABORT
 
-movements:
+steps:
   - name: plan
     persona: planner
     knowledge:

package/builtins/en/{pieces → workflows}/audit-architecture-frontend.yaml

@@ -1,7 +1,7 @@
 name: audit-architecture-frontend
 description: Frontend-focused architecture audit. Enumerate UI modules and boundaries, then produce an issue-ready report without modifying code
-max_movements: 12
-initial_movement: plan
+max_steps: 12
+initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
@@ -17,7 +17,7 @@ loop_monitors:
         - condition: Quality is insufficient with no prospect of improvement
           next: ABORT
 
-movements:
+steps:
   - name: plan
     persona: planner
     knowledge:

package/builtins/en/{pieces → workflows}/audit-architecture.yaml

@@ -1,7 +1,7 @@
 name: audit-architecture
 description: Comprehensive architecture audit. Enumerate modules and boundaries, then produce an issue-ready report without modifying code
-max_movements: 12
-initial_movement: plan
+max_steps: 12
+initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
@@ -17,7 +17,7 @@ loop_monitors:
         - condition: Quality is insufficient with no prospect of improvement
           next: ABORT
 
-movements:
+steps:
   - name: plan
     persona: planner
     knowledge: architecture

package/builtins/en/{pieces → workflows}/audit-e2e.yaml

@@ -1,13 +1,13 @@
 name: audit-e2e
 description: Comprehensive E2E audit. Enumerate user flows and coverage gaps, then produce an issue-ready report without modifying code
-piece_config:
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 12
-initial_movement: plan
+max_steps: 12
+initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
@@ -23,7 +23,7 @@ loop_monitors:
         - condition: Quality is insufficient with no prospect of improvement
           next: ABORT
 
-movements:
+steps:
   - name: plan
     persona: test-planner
     policy: testing

package/builtins/en/{pieces → workflows}/audit-security.yaml

@@ -1,7 +1,7 @@
 name: audit-security
 description: Full security audit. Reads every project file one by one for security review
-max_movements: 15
-initial_movement: plan
+max_steps: 15
+initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
@@ -17,7 +17,7 @@ loop_monitors:
         - condition: Quality is insufficient with no prospect of improvement
           next: ABORT
 
-movements:
+steps:
   - name: plan
     persona: planner
     instruction: audit-security-plan

package/builtins/en/{pieces → workflows}/audit-unit.yaml

@@ -1,13 +1,13 @@
 name: audit-unit
 description: Comprehensive unit test audit. Enumerate behaviors and coverage gaps, then produce an issue-ready report without modifying code
-piece_config:
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 12
-initial_movement: plan
+max_steps: 12
+initial_step: plan
 
 loop_monitors:
   - cycle: [supervise, review]
@@ -23,7 +23,7 @@ loop_monitors:
         - condition: Quality is insufficient with no prospect of improvement
           next: ABORT
 
-movements:
+steps:
   - name: plan
     edit: false
     persona: test-planner

package/builtins/en/{pieces → workflows}/backend-cqrs-mini.yaml

@@ -1,13 +1,13 @@
 name: backend-cqrs-mini
-description: CQRS+ES-focused mini development piece (plan -> implement -> parallel review -> fix if needed -> complete)
-piece_config:
+description: CQRS+ES-focused mini development workflow (plan -> implement -> parallel review -> fix if needed -> complete)
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 20
-initial_movement: plan
+max_steps: 20
+initial_step: plan
 loop_monitors:
   - cycle:
       - reviewers
@@ -21,7 +21,7 @@ loop_monitors:
           next: fix_both
         - condition: unproductive (same findings repeating)
           next: supervise_fix
-movements:
+steps:
   - name: plan
     edit: false
     persona: planner

package/builtins/en/{pieces → workflows}/backend-cqrs.yaml

@@ -1,13 +1,13 @@
 name: backend-cqrs
-description: CQRS+ES development piece with test-first, AI review, 2-stage reviews, fix loops, and supervision
-piece_config:
+description: CQRS+ES development workflow with test-first, AI review, 2-stage reviews, fix loops, and supervision
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 30
-initial_movement: plan
+max_steps: 60
+initial_step: plan
 loop_monitors:
   - cycle:
       - ai_review
@@ -33,7 +33,7 @@ loop_monitors:
           next: reviewers_1
         - condition: unproductive (same findings repeating)
           next: supervise
-movements:
+steps:
   - name: plan
     edit: false
     persona: planner

package/builtins/en/{pieces → workflows}/backend-mini.yaml

@@ -1,13 +1,13 @@
 name: backend-mini
-description: Backend-focused mini development piece (plan -> implement -> parallel review -> fix if needed -> complete)
-piece_config:
+description: Backend-focused mini development workflow (plan -> implement -> parallel review -> fix if needed -> complete)
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 20
-initial_movement: plan
+max_steps: 20
+initial_step: plan
 loop_monitors:
   - cycle:
       - reviewers
@@ -21,7 +21,7 @@ loop_monitors:
           next: fix_both
         - condition: unproductive (same findings repeating)
           next: supervise_fix
-movements:
+steps:
   - name: plan
     edit: false
     persona: planner

package/builtins/en/{pieces → workflows}/backend.yaml

@@ -1,13 +1,13 @@
 name: backend
-description: Backend development piece with test-first, AI review, 2-stage reviews, fix loops, and supervision
-piece_config:
+description: Backend development workflow with test-first, AI review, 2-stage reviews, fix loops, and supervision
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 30
-initial_movement: plan
+max_steps: 60
+initial_step: plan
 loop_monitors:
   - cycle:
       - ai_review
@@ -33,7 +33,7 @@ loop_monitors:
           next: reviewers_1
         - condition: unproductive (same findings repeating)
           next: supervise
-movements:
+steps:
   - name: plan
     edit: false
     persona: planner

package/builtins/en/{pieces → workflows}/compound-eye.yaml

@@ -1,20 +1,20 @@
 name: compound-eye
 description: Multi-model review - send the same instruction to Claude and Codex simultaneously, synthesize both responses
-piece_config:
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 10
-initial_movement: evaluate
-movements:
+max_steps: 10
+initial_step: evaluate
+steps:
   - name: evaluate
     parallel:
       - name: claude-eye
         edit: false
         persona: coder
-        provider: claude
+        provider: claude-sdk
         session: refresh
         knowledge: architecture
         provider_options:

package/builtins/en/{pieces → workflows}/deep-research.yaml

@@ -1,14 +1,14 @@
 name: deep-research
-description: Deep research piece - discovery-driven investigation that follows emerging questions with multi-perspective analysis
-piece_config:
+description: Deep research workflow - discovery-driven investigation that follows emerging questions with multi-perspective analysis
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 15
-initial_movement: plan
-movements:
+max_steps: 15
+initial_step: plan
+steps:
   - name: plan
     persona: research-planner
     policy: research

package/builtins/en/{pieces → workflows}/default.yaml

@@ -1,13 +1,13 @@
 name: default
-description: Test-first development piece (plan → write tests → implement → AI antipattern review → parallel review → complete)
-piece_config:
+description: Test-first development workflow (plan → write tests → implement → AI antipattern review → parallel review → complete)
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 30
-initial_movement: plan
+max_steps: 30
+initial_step: plan
 loop_monitors:
   - cycle:
       - ai_review
@@ -45,7 +45,7 @@ loop_monitors:
           next: reviewers
         - condition: unproductive (same findings repeating)
           next: ABORT
-movements:
+steps:
   - name: plan
     edit: false
     persona: planner

package/builtins/en/{pieces → workflows}/dual-cqrs-mini.yaml

@@ -1,13 +1,13 @@
 name: dual-cqrs-mini
-description: CQRS+ES frontend + backend mini development piece (plan -> implement -> parallel review -> fix if needed -> complete) with CQRS+ES knowledge injection
-piece_config:
+description: CQRS+ES frontend + backend mini development workflow (plan -> implement -> parallel review -> fix if needed -> complete) with CQRS+ES knowledge injection
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 20
-initial_movement: plan
+max_steps: 20
+initial_step: plan
 loop_monitors:
   - cycle:
       - reviewers
@@ -21,7 +21,7 @@ loop_monitors:
           next: fix_both
         - condition: unproductive (same findings repeating)
           next: supervise_fix
-movements:
+steps:
   - name: plan
     edit: false
     persona: planner

package/builtins/en/{pieces → workflows}/dual-cqrs.yaml

@@ -1,13 +1,13 @@
 name: dual-cqrs
-description: Frontend + backend development piece (CQRS+ES specialized) with CQRS+ES, frontend, security, and QA reviews with fix loops
-piece_config:
+description: Frontend + backend development workflow (CQRS+ES specialized) with CQRS+ES, frontend, security, and QA reviews with fix loops
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 30
-initial_movement: plan
+max_steps: 60
+initial_step: plan
 loop_monitors:
   - cycle:
       - ai_review
@@ -33,7 +33,7 @@ loop_monitors:
           next: reviewers
         - condition: Unproductive (same findings repeating)
           next: supervise
-movements:
+steps:
   - name: plan
     edit: false
     persona: planner

package/builtins/en/{pieces → workflows}/dual-mini.yaml

@@ -1,13 +1,13 @@
 name: dual-mini
-description: Frontend + backend mini development piece (plan -> implement -> parallel review -> fix if needed -> complete) with frontend + backend knowledge injection
-piece_config:
+description: Frontend + backend mini development workflow (plan -> implement -> parallel review -> fix if needed -> complete) with frontend + backend knowledge injection
+workflow_config:
   provider_options:
     codex:
       network_access: true
     opencode:
       network_access: true
-max_movements: 20
-initial_movement: plan
+max_steps: 20
+initial_step: plan
 loop_monitors:
   - cycle:
       - reviewers
@@ -21,7 +21,7 @@ loop_monitors:
           next: fix_both
         - condition: unproductive (same findings repeating)
           next: supervise_fix
-movements:
+steps:
   - name: plan
     edit: false
     persona: planner