takt 0.33.1 → 0.33.2

package/builtins/en/facets/instructions/architecture-audit-plan.md

@@ -0,0 +1,13 @@
+Audit the project architecture before making changes.
+
+**What to do:**
+1. Enumerate the main modules, layers, boundaries, and public entry points using Read, Glob, and Grep
+2. Identify the dependency directions, shared abstractions, and major call chains
+3. Build an audit scope that covers all modules relevant to structure, ownership, and wiring
+4. Highlight modules with higher architectural risk (boundary leaks, giant files, scattered logic, coupling hotspots)
+5. Prepare an audit order that reviews the highest-risk modules first
+
+**Important:**
+- Start from full module and boundary enumeration, not from a few suspicious files
+- Focus on structure and wiring, not style-only comments
+- If the architecture cannot be inferred from code alone, state the missing evidence explicitly

package/builtins/en/facets/instructions/architecture-audit-review.md

@@ -0,0 +1,15 @@
+Re-audit the modules or boundaries that were judged insufficient in the previous architecture audit.
+
+**Important:** Refer to these reports:
+- Plan report: {report:01-architecture-audit-plan.md}
+- Audit report: {report:02-architecture-audit.md}
+
+**What to do:**
+1. Read the flagged modules, boundaries, and call chains in full
+2. Re-check the structural claims and identify what was previously skipped or weakly evidenced
+3. Update the audit result with concrete file evidence, explicit scope coverage, and missing-item reasons where applicable
+
+**Strictly prohibited:**
+- Modifying production code
+- Claiming a boundary or dependency direction is valid without file evidence
+- Skipping a flagged module because it "looks standard"

package/builtins/en/facets/instructions/architecture-audit-supervise.md

@@ -0,0 +1,14 @@
+Verify the completeness and quality of the architecture audit itself.
+
+**Important:** Refer to these reports:
+- Plan report: {report:01-architecture-audit-plan.md}
+- Audit report: {report:02-architecture-audit.md}
+
+**Verification procedure:**
+1. Cross-check the module inventory from the plan against the audited modules in the audit report
+2. Reject if important modules or boundaries remain unaudited
+3. Reject if key dependency directions, wiring paths, ownership boundaries, or call chains from the plan are missing from the audit result without an explicit reason
+4. Verify the audit report includes concrete structural evidence, not just design opinions
+5. Verify the report includes the enumeration commands used and that they are sufficient to support the claimed scope
+6. Sample-read a few high-risk modules yourself to confirm the structural claims are credible
+7. Require re-audit if findings or suggested issue titles are too vague to file directly

package/builtins/en/facets/instructions/architecture-audit-team-leader.md

@@ -0,0 +1,22 @@
+Decompose the architecture audit, assign modules to each part, and execute in parallel.
+
+**Important:** Refer to the plan report: {report:01-architecture-audit-plan.md}
+
+**What to do:**
+1. Review the module inventory and architectural risk areas from the plan report
+2. Split the audit into 3 groups by module or boundary
+3. Assign exclusive ownership to each part so every relevant module is audited once
+
+**Each part's instruction MUST include:**
+- Assigned module and file list
+- The boundaries and call chains to verify
+- Required audit procedure:
+  1. Read the assigned files in full
+  2. Trace dependency direction, entry points, and shared abstractions
+  3. Record structural findings with concrete file evidence
+- Completion criteria: every assigned module has been audited and all findings are reported with evidence
+
+**Constraints:**
+- Each part is read-only
+- Do not audit files outside the assignment
+- Prefer evidence from code structure and call chains over style-only comments

package/builtins/en/facets/instructions/e2e-audit-plan.md

@@ -0,0 +1,13 @@
+Audit the target for E2E coverage before making changes.
+
+**What to do:**
+1. Enumerate all user entry points, major routes, task flows, and failure paths from the codebase
+2. Read the existing E2E tests and map which flows and scenarios are already covered
+3. Build a complete list of auditable user flows and scenario variants
+4. Identify missing E2E scenarios and prioritize them by user impact and regression risk
+5. Prepare an implementation order that covers the highest-risk missing scenarios first
+
+**Important:**
+- Start from complete route and flow enumeration, not from a few obvious pages
+- Include unhappy paths, permission differences, and recovery paths when relevant
+- If a flow cannot be audited from local code and tests alone, state the missing evidence explicitly

package/builtins/en/facets/instructions/e2e-audit-review.md

@@ -0,0 +1,16 @@
+Re-audit the routes or scenarios that were judged insufficient in the previous E2E audit.
+
+**Important:** Review the supervisor's verification results and understand:
+- Unaudited flows or scenarios
+- Coverage claims lacking evidence
+- Specific feedback on issue quality or scope
+
+**What to do:**
+1. Read the flagged route-related code and corresponding E2E tests in full
+2. Re-check the coverage claims for the flagged scenarios and identify what was previously skipped or weakly evidenced
+3. Update the audit result in issue-ready form with concrete evidence, explicit scope coverage, and missing-item reasons where applicable
+
+**Strictly prohibited:**
+- Modifying E2E tests or production code
+- Claiming a scenario is covered without citing the actual test evidence
+- Skipping a flagged route because it "looks fine"

package/builtins/en/facets/instructions/e2e-audit-supervise.md

@@ -0,0 +1,11 @@
+Verify the completeness and quality of the E2E audit itself.
+
+**Important:** Refer to the audit plan report: {report:01-e2e-audit-plan.md}
+
+**Verification procedure:**
+1. Cross-check the full route and flow inventory in the plan against the audited scenarios in the audit report
+2. Reject if any important entry point, user flow, unhappy path, permission variant, or recovery path from the plan is missing from the audit result without an explicit reason
+3. Verify the audit report includes concrete evidence for covered and missing scenarios, not just high-level claims
+4. Verify the report includes the enumeration commands used and that they are sufficient to support the claimed scope
+5. Sample-read a few high-risk routes and corresponding tests yourself to validate the coverage claims
+6. Require re-audit if issue titles, priorities, or recommended actions are too vague to be filed directly

package/builtins/en/facets/instructions/e2e-audit-team-leader.md

@@ -0,0 +1,22 @@
+Decompose the E2E audit, assign flows to each part, and execute in parallel.
+
+**Important:** Refer to the plan report: {report:01-e2e-audit-plan.md}
+
+**What to do:**
+1. Review the user flow list, existing scenarios, and risk areas from the plan report
+2. Split the audit into 3 groups by feature area or route cluster
+3. Assign exclusive ownership so every audited flow is reviewed once
+
+**Each part's instruction MUST include:**
+- Assigned routes, entry points, and corresponding E2E files
+- The happy paths, failure paths, and permission variants to verify
+- Required audit procedure:
+  1. Read the relevant code for the assigned flows
+  2. Read the corresponding E2E tests in full
+  3. Record covered and missing scenarios with concrete evidence
+- Completion criteria: every assigned flow has been audited and findings are reported in issue-ready form
+
+**Constraints:**
+- Each part is read-only
+- Do not modify E2E tests or production code
+- Do not audit routes outside the assignment

package/builtins/en/facets/instructions/unit-audit-plan.md

@@ -0,0 +1,13 @@
+Audit the target for unit test coverage before making changes.
+
+**What to do:**
+1. Enumerate the target production files, exported APIs, internal branches, error paths, boundary checks, and state transitions using Read, Glob, and Grep
+2. Read existing unit tests and map which behaviors are already covered
+3. Build a complete inventory of auditable behaviors for each target file
+4. Identify missing unit tests and prioritize them by regression risk
+5. Prepare an implementation order that covers the highest-risk gaps first
+
+**Important:**
+- Start from complete enumeration, not from a few obvious gaps
+- Do not stop after identifying a handful of missing tests
+- If the scope is unclear, state exactly which files or behaviors need clarification

package/builtins/en/facets/instructions/unit-audit-review.md

@@ -0,0 +1,16 @@
+Re-audit the files or behaviors that were judged insufficient in the previous unit audit.
+
+**Important:** Review the supervisor's verification results and understand:
+- Unaudited files or behaviors
+- Coverage claims lacking evidence
+- Specific feedback on issue quality or scope
+
+**What to do:**
+1. Read the flagged production files and corresponding tests in full
+2. Re-check the coverage claims for the flagged behaviors and identify what was previously skipped or weakly evidenced
+3. Update the audit result in issue-ready form with concrete evidence, explicit scope coverage, and missing-item reasons where applicable
+
+**Strictly prohibited:**
+- Modifying tests or production code
+- Claiming a behavior is covered without citing the actual test evidence
+- Skipping a flagged file or behavior because it "looks fine"

package/builtins/en/facets/instructions/unit-audit-supervise.md

@@ -0,0 +1,11 @@
+Verify the completeness and quality of the unit test audit itself.
+
+**Important:** Refer to the audit plan report: {report:01-unit-audit-plan.md}
+
+**Verification procedure:**
+1. Cross-check the full target inventory in the plan against the audited files and behaviors in the audit report
+2. Reject if any production file, exported API, branch, error path, boundary check, or state transition from the plan is missing from the audit result without an explicit reason
+3. Verify the audit report includes concrete evidence for both covered and missing behaviors, not just conclusions
+4. Verify the report includes the enumeration commands used and that they are sufficient to support the claimed scope
+5. Sample-read a few target production files and corresponding tests yourself to confirm the coverage claims are credible
+6. Require re-audit if issue titles, priorities, or recommended actions are too vague to be filed directly

package/builtins/en/facets/instructions/unit-audit-team-leader.md

@@ -0,0 +1,22 @@
+Decompose the unit audit, assign files to each part, and execute in parallel.
+
+**Important:** Refer to the plan report: {report:01-unit-audit-plan.md}
+
+**What to do:**
+1. Review the production file list, existing tests, and audited behavior inventory from the plan report
+2. Split the audit into 3 groups by module or test area
+3. Assign exclusive ownership so every target file and behavior is audited once
+
+**Each part's instruction MUST include:**
+- Assigned production files and corresponding test files
+- The behaviors, branches, error paths, and boundary checks to verify
+- Required audit procedure:
+  1. Read every assigned production file in full
+  2. Read the corresponding unit tests in full
+  3. Record covered and missing behaviors with concrete file evidence
+- Completion criteria: every assigned target has been audited and findings are reported in issue-ready form
+
+**Constraints:**
+- Each part is read-only
+- Do not modify tests or production code
+- Do not audit files outside the assignment

package/builtins/en/facets/output-contracts/architecture-audit-plan.md

@@ -0,0 +1,26 @@
+```markdown
+# Architecture Audit Plan
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Scope notes:
+  - {how modules, layers, boundaries, and entry points were enumerated}
+
+## Module Inventory
+| # | Module / Layer | Key Files | Responsibility | Main Boundaries | Risk |
+|---|----------------|-----------|----------------|-----------------|------|
+| 1 | {module or layer} | `src/file.ts` | {primary responsibility} | {boundary summary} | High / Medium / Low |
+
+## Audit Targets
+| # | Module / Layer | What to Verify | Priority |
+|---|----------------|----------------|----------|
+| 1 | {module or layer} | {dependency direction, wiring, ownership, abstraction} | High / Medium / Low |
+
+## Audit Order
+- {ordered module review plan}
+
+## Clarifications / Risks
+- {open questions or constraints}
+```

package/builtins/en/facets/output-contracts/architecture-audit.md

@@ -0,0 +1,38 @@
+```markdown
+# Architecture Audit Report
+
+## Result: APPROVE / IMPROVE / REJECT
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Coverage notes:
+  - {how you confirmed the full module and boundary set was audited}
+
+## Audit Scope
+| # | Module / Layer | Audited | Key Files | Boundaries Verified |
+|---|----------------|---------|-----------|---------------------|
+| 1 | {module or layer} | ✅ | `src/file.ts` | {boundary summary} |
+
+## Findings
+| # | Severity | Category | Location | Issue | Recommended Fix |
+|---|----------|----------|----------|-------|-----------------|
+| 1 | High / Medium / Low | boundary / coupling / wiring / dead-code | `src/file.ts:42` | {issue description} | {fix suggestion} |
+
+## Modules with No Blocking Issues
+- {modules audited with no blocking findings}
+
+## Suggested Issue Titles
+1. {Issue title}
+2. {Issue title}
+
+## Follow-up Notes
+- {non-blocking observations or constraints}
+- {explicit reasons for any intentionally unaudited item}
+```
+
+**Cognitive load reduction rules:**
+- APPROVE → Scope table only (15 lines max)
+- IMPROVE → Scope table + relevant findings only
+- REJECT → Include only blocking findings and impacted modules

package/builtins/en/facets/output-contracts/{security-audit.md → audit-security.md}

@@ -5,6 +5,13 @@
 
 ## Severity: None / Low / Medium / High / Critical
 
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Coverage notes:
+  - {how you confirmed the full file set was audited}
+
 ## Audit Scope
 | # | File | Audited | Risk Classification |
 |---|------|---------|-------------------|
@@ -18,9 +25,17 @@
 ## Files with No Issues
 - {list of files where no issues were detected}
 
+## Suggested Issue Titles
+1. {Issue title}
+2. {Issue title}
+
 ## Recommendations (non-blocking)
 - {security improvement suggestions}
 
+## Notes
+- {constraints, assumptions, or audit limits}
+- {explicit reasons for any intentionally unaudited item}
+
 ## REJECT Criteria
 - REJECT if one or more High or Critical issues exist
 ```

package/builtins/en/facets/output-contracts/e2e-audit-plan.md

@@ -0,0 +1,26 @@
+```markdown
+# E2E Audit Plan
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Scope notes:
+  - {how routes, flows, and E2E specs were enumerated}
+
+## Audited User Flows
+| # | Area | Route / Entry | Existing Scenarios | Coverage Status | Risk |
+|---|------|---------------|--------------------|-----------------|------|
+| 1 | {feature area} | {route or entry point} | {existing test names} | Covered / Partial / Missing | High / Medium / Low |
+
+## Missing Scenarios
+| # | Area | Scenario | Priority | Planned Test Location |
+|---|------|----------|----------|-----------------------|
+| 1 | {feature area} | {missing scenario} | High / Medium / Low | `e2e/example.spec.ts` |
+
+## Audit Order
+- {ordered audit plan}
+
+## Clarifications / Risks
+- {open questions or constraints}
+```

package/builtins/en/facets/output-contracts/e2e-audit.md

@@ -0,0 +1,41 @@
+```markdown
+# E2E Audit Report
+
+## Result: APPROVE / IMPROVE / REJECT
+
+## Summary
+{1-3 sentences summarizing the flow coverage situation}
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Coverage notes:
+  - {how you confirmed the full flow set was audited}
+
+## Scope
+| # | Area | Route / Entry | Existing Scenarios | Coverage Status | Risk |
+|---|------|---------------|--------------------|-----------------|------|
+| 1 | {feature area} | {route or entry point} | {existing test names} | Covered / Partial / Missing | High / Medium / Low |
+
+## Findings
+| # | Priority | Area | Location | Gap | Recommended Action |
+|---|----------|------|----------|-----|--------------------|
+| 1 | High / Medium / Low | e2e-testing | `e2e/example.spec.ts` / `src/page.tsx:42` | {missing or weakly tested scenario} | {issue-ready action} |
+
+## No-Issue Areas
+- {flows confirmed as adequately covered}
+
+## Suggested Issue Titles
+1. {Issue title}
+2. {Issue title}
+
+## Notes
+- {constraints, assumptions, or audit limits}
+- {explicit reasons for any intentionally unaudited item}
+```
+
+**Cognitive load reduction rules:**
+- APPROVE → Summary + Scope only
+- IMPROVE → Include only relevant gaps
+- REJECT → Include only blocking or high-priority gaps

package/builtins/en/facets/output-contracts/unit-audit-plan.md

@@ -0,0 +1,26 @@
+```markdown
+# Unit Test Audit Plan
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Scope notes:
+  - {how target production files and tests were enumerated}
+
+## Audit Scope
+| # | Production File | Existing Test Files | Audited Behaviors / Branches | Coverage Status |
+|---|-----------------|---------------------|------------------------------|-----------------|
+| 1 | `src/file.ts` | `src/__tests__/file.test.ts` | {exported APIs, branches, errors, boundaries} | Covered / Partial / Missing |
+
+## Missing Test Cases
+| # | Production File | Behavior / Branch | Priority | Planned Test Location |
+|---|-----------------|-------------------|----------|-----------------------|
+| 1 | `src/file.ts` | {missing behavior} | High / Medium / Low | `src/__tests__/file.test.ts` |
+
+## Audit Order
+- {ordered audit plan}
+
+## Clarifications / Risks
+- {open questions or constraints}
+```

package/builtins/en/facets/output-contracts/unit-audit.md

@@ -0,0 +1,41 @@
+```markdown
+# Unit Audit Report
+
+## Result: APPROVE / IMPROVE / REJECT
+
+## Summary
+{1-3 sentences summarizing the coverage situation}
+
+## Enumeration Evidence
+- Commands used:
+  - `rg ...`
+  - `rg --files ...`
+- Coverage notes:
+  - {how you confirmed the full target set was audited}
+
+## Scope
+| # | Production File | Existing Test Files | Audited Behaviors | Coverage Status |
+|---|-----------------|---------------------|-------------------|-----------------|
+| 1 | `src/file.ts` | `src/__tests__/file.test.ts` | {key behaviors} | Covered / Partial / Missing |
+
+## Findings
+| # | Priority | Area | Location | Gap | Recommended Action |
+|---|----------|------|----------|-----|--------------------|
+| 1 | High / Medium / Low | unit-testing | `src/file.ts:42` | {missing or weakly tested behavior} | {issue-ready action} |
+
+## No-Issue Areas
+- {files or behaviors confirmed as adequately covered}
+
+## Suggested Issue Titles
+1. {Issue title}
+2. {Issue title}
+
+## Notes
+- {constraints, assumptions, or audit limits}
+- {explicit reasons for any intentionally unaudited item}
+```
+
+**Cognitive load reduction rules:**
+- APPROVE → Summary + Scope only
+- IMPROVE → Include only relevant gaps
+- REJECT → Include only blocking or high-priority gaps

package/builtins/en/piece-categories.yaml

@@ -47,11 +47,13 @@ piece_categories:
       - review-fix-backend-cqrs
       - review-takt-default
       - review-fix-takt-default
-      - security-audit
-  🧪 Testing:
-    pieces:
-      - fill-unit
-      - fill-e2e
+      - audit-unit
+      - audit-e2e
+      - audit-security
+      - audit-architecture
+      - audit-architecture-frontend
+      - audit-architecture-backend
+      - audit-architecture-dual
   🎵 TAKT Development:
     pieces:
       - takt-default

package/builtins/en/pieces/audit-architecture-backend.yaml

@@ -0,0 +1,83 @@
+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
+
+loop_monitors:
+  - cycle: [supervise, review]
+    threshold: 4
+    judge:
+      persona: supervisor
+      instruction: |
+        The supervise → review cycle for the backend architecture audit has repeated {cycle_count} times.
+        Judge the overall completeness and quality of the audit, and decide whether the current results are acceptable.
+      rules:
+        - condition: Quality is sufficient
+          next: COMPLETE
+        - condition: Quality is insufficient with no prospect of improvement
+          next: ABORT
+
+movements:
+  - name: plan
+    persona: planner
+    knowledge:
+      - backend
+      - architecture
+    instruction: architecture-audit-plan
+    edit: false
+    output_contracts:
+      report:
+        - name: 01-architecture-audit-plan.md
+          format: architecture-audit-plan
+    rules:
+      - condition: Module inventory and audit scope complete
+        next: audit
+      - condition: Requirements unclear, insufficient info
+        next: ABORT
+
+  - name: audit
+    persona: architecture-reviewer
+    policy: review
+    knowledge:
+      - backend
+      - architecture
+    instruction: architecture-audit-team-leader
+    edit: false
+    team_leader:
+      max_parts: 3
+      part_persona: architecture-reviewer
+      part_edit: false
+    output_contracts:
+      report:
+        - name: 02-architecture-audit.md
+          format: architecture-audit
+    rules:
+      - condition: Audit complete
+        next: supervise
+
+  - name: supervise
+    persona: supervisor
+    policy: review
+    knowledge:
+      - backend
+      - architecture
+    instruction: architecture-audit-supervise
+    edit: false
+    pass_previous_response: false
+    rules:
+      - condition: Audit is complete and issue-ready
+        next: COMPLETE
+      - condition: Architecture audit is incomplete or evidence is insufficient
+        next: review
+
+  - name: review
+    persona: architecture-reviewer
+    policy: review
+    knowledge:
+      - backend
+      - architecture
+    instruction: architecture-audit-review
+    edit: false
+    rules:
+      - condition: Re-audit complete
+        next: supervise

package/builtins/en/pieces/audit-architecture-dual.yaml

@@ -0,0 +1,87 @@
+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
+
+loop_monitors:
+  - cycle: [supervise, review]
+    threshold: 4
+    judge:
+      persona: supervisor
+      instruction: |
+        The supervise → review cycle for the dual architecture audit has repeated {cycle_count} times.
+        Judge the overall completeness and quality of the audit, and decide whether the current results are acceptable.
+      rules:
+        - condition: Quality is sufficient
+          next: COMPLETE
+        - condition: Quality is insufficient with no prospect of improvement
+          next: ABORT
+
+movements:
+  - name: plan
+    persona: planner
+    knowledge:
+      - frontend
+      - backend
+      - architecture
+    instruction: architecture-audit-plan
+    edit: false
+    output_contracts:
+      report:
+        - name: 01-architecture-audit-plan.md
+          format: architecture-audit-plan
+    rules:
+      - condition: Module inventory and audit scope complete
+        next: audit
+      - condition: Requirements unclear, insufficient info
+        next: ABORT
+
+  - name: audit
+    persona: architecture-reviewer
+    policy: review
+    knowledge:
+      - frontend
+      - backend
+      - architecture
+    instruction: architecture-audit-team-leader
+    edit: false
+    team_leader:
+      max_parts: 3
+      part_persona: architecture-reviewer
+      part_edit: false
+    output_contracts:
+      report:
+        - name: 02-architecture-audit.md
+          format: architecture-audit
+    rules:
+      - condition: Audit complete
+        next: supervise
+
+  - name: supervise
+    persona: supervisor
+    policy: review
+    knowledge:
+      - frontend
+      - backend
+      - architecture
+    instruction: architecture-audit-supervise
+    edit: false
+    pass_previous_response: false
+    rules:
+      - condition: Audit is complete and issue-ready
+        next: COMPLETE
+      - condition: Architecture audit is incomplete or evidence is insufficient
+        next: review
+
+  - name: review
+    persona: architecture-reviewer
+    policy: review
+    knowledge:
+      - frontend
+      - backend
+      - architecture
+    instruction: architecture-audit-review
+    edit: false
+    rules:
+      - condition: Re-audit complete
+        next: supervise