diff --git a/.takt/.gitignore b/.takt/.gitignore
new file mode 100644
index 00000000..bd02579c
--- /dev/null
+++ b/.takt/.gitignore
@@ -0,0 +1,7 @@
+# Runtime data (not version-controlled)
+runs/
+tasks/
+clone-meta/
+worktree-sessions/
+session-state.json
+persona_sessions.json
diff --git a/.takt/config.yaml b/.takt/config.yaml
new file mode 100644
index 00000000..96381a26
--- /dev/null
+++ b/.takt/config.yaml
@@ -0,0 +1,27 @@
+provider: claude
+model: claude-opus-4-6
+
+auto_pr: false
+draft_pr: false
+
+persona_providers:
+  coder:
+    provider: cursor
+    model: composer-2-fast
+  architecture-reviewer:
+    provider: codex
+    model: gpt-5.4
+  acceptor:
+    provider: codex
+    model: gpt-5.4
+  supervisor:
+    provider: codex
+    model: gpt-5.4
+
+provider_profiles:
+  cursor:
+    default_permission_mode: edit
+  codex:
+    default_permission_mode: edit
+  claude:
+    default_permission_mode: edit
diff --git a/.takt/facets/instructions/acceptance.md b/.takt/facets/instructions/acceptance.md
new file mode 100644
index 00000000..a6bdf277
--- /dev/null
+++ b/.takt/facets/instructions/acceptance.md
@@ -0,0 +1,37 @@
+# Acceptance Testing Procedure
+
+Verify that the implementation meets the completion criteria of the task spec (order.md).
+
+## Steps
+
+1. List all completion criteria from order.md
+
+2. For each completion criterion:
+   - Read the relevant code and verify the implementation
+   - Judge whether the criterion is met as Yes/No
+   - If No, describe the specific deficiency
+
+3. Run validation:
+
+   ```bash
+   pnpm validate
+   ```
+
+   Confirm that all checks (format, lint, typecheck, build, test) pass
+
+4. If the task involves DB schema changes, also run:
+
+   ```bash
+   pnpm db:setup
+   ```
+
+   Confirm that clean-slate migration + seed succeeds
+
+5. Scope check:
+   - Get the list of changed files with `git diff --name-only HEAD`
+   - Cross-reference with the files to change listed in order.md
+   - Check for any out-of-scope changes (refer to prohibited actions in the policy)
+
+6. Judgment:
+   - All completion criteria Yes and validation passes -> approved
+   - Otherwise -> needs_fix (include specific fix instructions)
diff --git a/.takt/facets/instructions/spec-draft.md b/.takt/facets/instructions/spec-draft.md
new file mode 100644
index 00000000..b16a4cb1
--- /dev/null
+++ b/.takt/facets/instructions/spec-draft.md
@@ -0,0 +1,74 @@
+# Spec Draft Procedure
+
+Generate order.md based on the task description (issue body or user input).
+
+## Steps
+
+1. Read the task description and understand the purpose and scope of the implementation
+
+2. Investigate existing code:
+   - Identify files likely to be changed
+   - Review existing structure, patterns, and dependencies
+   - Check for test files and their organization
+
+3. Generate order.md (with the following structure):
+
+   ```markdown
+   # Task Name
+
+   ## Overview
+
+   What to do (1-3 sentences)
+
+   ## Background
+
+   Why this is needed (may quote from the issue)
+
+   ## Files to Change
+
+   - path/to/file.ts — Summary of changes
+
+   ## Implementation Details
+
+   - List specific changes as bullet points
+   - Do not include code examples (describe what to do, not how)
+
+   ## Database Changes (if applicable)
+
+   - Schema file to modify: `db/shared.sql` or `db/tenant.sql`
+   - New/modified tables and columns
+   - Migration safety considerations (existing data, destructive operations)
+
+   ## Completion Criteria
+
+   - [ ] List verifiable conditions
+   - [ ] pnpm validate passes
+   - [ ] pnpm db:setup passes (if schema changes)
+
+   ## Out of Scope
+
+   - Explicitly state what will not be done
+   ```
+
+4. Run the quality checklist before finalizing
+
+## Quality Checklist
+
+Before completing order.md, verify each item:
+
+- [ ] For refactoring tasks: existing behaviors that must be preserved are listed as explicit completion criteria (not just "keep behavior unchanged")
+- [ ] Negative test cases are required where applicable (e.g., "X does NOT happen when Y")
+- [ ] Each completion criterion is independently verifiable (can be checked Yes/No without ambiguity)
+- [ ] Files to change are confirmed by reading the actual code (not guessed from names)
+- [ ] Out of scope items do not contradict the implementation details or files to change
+- [ ] Implicit dependencies of changed files are accounted for (e.g., if a function signature changes, callers are in scope)
+- [ ] DB schema changes: migration safety is addressed (existing data preservation, IF EXISTS on manual DROP TABLE)
+- [ ] DB schema changes: `pnpm db:setup` is included in completion criteria
+- [ ] Multi-tenant security: mutations are scoped to org, auth guards are before form parsing
+
+## Rules
+
+- Do not include code examples or snippets (keep it at the requirements level)
+- Only list files to change after actually reading the code to confirm
+- Completion criteria must be granular enough to be judged as Yes/No
+- Do not use vague expressions ("appropriately", "as needed")
diff --git a/.takt/facets/instructions/spec-review.md b/.takt/facets/instructions/spec-review.md
new file mode 100644
index 00000000..099c8da0
--- /dev/null
+++ b/.takt/facets/instructions/spec-review.md
@@ -0,0 +1,47 @@
+# Spec Review Procedure
+
+Review the task spec (order.md) and the existing code targeted for changes.
+
+## Steps
+
+1. Read order.md and verify the following:
+   - Whether the implementation details are clear
+   - Whether the files to change are comprehensive (including implicit dependencies)
+   - Whether the completion criteria are verifiable
+   - Whether the out-of-scope section is clear
+
+2. Actually read the files to change and understand the existing code structure
+
+3. If a supervision report exists (`supervise-report.md`), read it and incorporate its findings into the review
+
+4. Review from the following perspectives:
+   - Are any files to change missing?
+   - Are the completion criteria sufficient (edge cases, error handling)?
+   - Is the scope appropriate (not too large/too small)?
+   - Can existing patterns or utilities be leveraged?
+
+5. Check for common spec omissions:
+
+   **Database changes:**
+   - If the spec modifies `db/shared.sql` or `db/tenant.sql`: does it address migration safety for existing production data?
+   - Are destructive operations (DROP TABLE, DROP COLUMN) justified and guarded with `IF EXISTS` where appropriate?
+   - Is `pnpm db:setup` included in completion criteria?
+   - Are Kysely type-regeneration (`pnpm db:generate`) consequences accounted for?
+
+   **Multi-tenant security:**
+   - Do mutations scope to the correct organization (shared DB: `WHERE organizationId = ?`, tenant DB: correct `getTenantDb`)?
+   - Is the auth guard called before `parseWithZod(request.formData())`?
+   - Are child resource ownership checks included where needed?
+
+   **Input validation:**
+   - New public API options used as counts, concurrency limits, or loop bounds: spec must define the exact valid domain
+   - Async operations in intervals/loops: is there a guard against concurrent in-flight requests?
+
+   **Behavioral preservation:**
+   - Existing behaviors that must be preserved: are they listed as explicit completion criteria with negative test cases?
+
+## Routing Guide
+
+- **spec-revise** (blocking issues): The spec has concrete problems that can be fixed by editing order.md — missing files, unclear criteria, scope gaps, contradictions between sections
+- **implement** (no blocking issues): The spec is clear enough to implement. Suggestion-level improvements can be noted but do not block
+- **ABORT** (fundamentally broken): The task itself is incoherent — e.g., the requested change contradicts the project's architecture, the task duplicates already-completed work, or the goal cannot be achieved with the described approach and no alternative is apparent
diff --git a/.takt/facets/instructions/supervise.md b/.takt/facets/instructions/supervise.md
new file mode 100644
index 00000000..199c2b48
--- /dev/null
+++ b/.takt/facets/instructions/supervise.md
@@ -0,0 +1,30 @@
+# Final Verification Procedure
+
+Verify the overall consistency of the implementation and determine whether it can be completed.
+
+## Steps
+
+1. List all completion criteria from order.md and check the status of each
+
+2. Run validation:
+
+   ```bash
+   pnpm validate
+   ```
+
+3. If the task involves DB schema changes, also run:
+
+   ```bash
+   pnpm db:setup
+   ```
+
+4. Check changed files with `git diff --name-only HEAD`:
+   - Are there any out-of-scope changes?
+   - Have order.md or PLAN.md been modified?
+
+5. If an acceptance testing report exists, review any remaining issues
+
+6. Judgment:
+   - All completion criteria met + validation passes -> ready to complete
+   - Only minor remaining issues -> issue fix instructions and route to fix
+   - Spec-level issues -> route back to spec-review
diff --git a/.takt/facets/knowledge/implementation-plan.md b/.takt/facets/knowledge/implementation-plan.md
new file mode 100644
index 00000000..cbb6f77d
--- /dev/null
+++ b/.takt/facets/knowledge/implementation-plan.md
@@ -0,0 +1,36 @@
+# Implementation Plan Context
+
+## Source of Truth
+
+- The task order (order.md) is the authoritative spec for the current task
+- Do NOT modify order.md — if it seems incomplete, implement what's there
+- Completion conditions in the task order are the acceptance criteria
+- CLAUDE.md contains project conventions — follow them
+
+## Project Validation
+
+```bash
+pnpm validate  # lint (Biome), format (Prettier), typecheck, build, test (Vitest)
+```
+
+When the task involves DB schema changes, also run:
+
+```bash
+pnpm db:setup  # Reset DB with migrations + seed data (verifies clean-slate migration)
+```
+
+## Database Migration Workflow
+
+1. Edit declarative schema: `db/shared.sql` (shared DB) or `db/tenant.sql` (tenant DB)
+2. Generate migration: `pnpm db:migrate`
+3. Review the generated SQL — Atlas auto-generates it, but you must verify correctness
+4. Apply migration: `pnpm db:apply`
+5. Regenerate Kysely types: `pnpm db:generate` (outputs to `app/services/type.ts`)
+
+## Key Conventions (from CLAUDE.md)
+
+- **CamelCasePlugin**: `sql` template literals don't transform identifiers — use `sql.ref('tableName.columnName')`
+- **DateTime**: Store as ISO 8601 with Z suffix; parse with `dayjs.utc(value)`; display with `.tz(timezone)`
+- **Server files**: `.server.ts` suffix for server-only code
+- **Form handling**: Conform + Zod with discriminated union schema + `ts-pattern`
+- **Multi-tenant security**: Auth guard before parseWithZod; scope mutations to org
diff --git a/.takt/facets/output-contracts/acceptance-report.md b/.takt/facets/output-contracts/acceptance-report.md
new file mode 100644
index 00000000..97b01d9c
--- /dev/null
+++ b/.takt/facets/output-contracts/acceptance-report.md
@@ -0,0 +1,35 @@
+```markdown
+# Acceptance Testing Result
+
+## Result: APPROVE / REJECT
+
+## Summary
+
+{1-2 sentence summary}
+
+## Completion Criteria Check
+
+| #   | Criterion | Result | Notes |
+| --- | --------- | ------ | ----- |
+| 1   |           | Yes/No |       |
+
+## Validation
+
+Summary of pnpm validate output
+
+## Database Setup (if applicable)
+
+Summary of pnpm db:setup output
+
+## Scope Check
+
+| Aspect                         | Result |
+| ------------------------------ | ------ |
+| Changed files are within scope | OK/NG  |
+| PLAN.md unmodified             | OK/NG  |
+| order.md unmodified            | OK/NG  |
+
+## Fix Instructions (if REJECT)
+
+-
+```
diff --git a/.takt/facets/output-contracts/spec-review-report.md b/.takt/facets/output-contracts/spec-review-report.md
new file mode 100644
index 00000000..442835d3
--- /dev/null
+++ b/.takt/facets/output-contracts/spec-review-report.md
@@ -0,0 +1,38 @@
+```markdown
+# Spec Review Result
+
+## Result: APPROVE / REJECT
+
+Judgment criteria:
+
+- APPROVE: No issues, or only minor improvement suggestions (no impediment to implementation)
+- REJECT: Contradictions in requirements, critical omissions in files to change, etc. — proceeding to implementation would certainly cause rework
+
+Minor improvement suggestions (naming alternatives, additional test case ideas, etc.) are filed as issues under APPROVE.
+Ambiguity that implementers can reasonably resolve on their own is not grounds for REJECT.
+
+## Summary
+
+{1-2 sentence summary}
+
+## Checklist
+
+| Aspect                               | Result | Notes |
+| ------------------------------------ | ------ | ----- |
+| Clarity of implementation scope      | OK/NG  |       |
+| Completeness of files to change      | OK/NG  |       |
+| Verifiability of completion criteria | OK/NG  |       |
+| Appropriateness of scope             | OK/NG  |       |
+| Leveraging existing patterns         | OK/NG  |       |
+| Multi-tenant security invariants     | OK/NG  |       |
+| DB migration safety (if applicable)  | OK/NG  |       |
+
+## Issues (if any)
+
+Assign a severity to each issue:
+
+- **blocking**: Implementation not possible. Grounds for REJECT
+- **suggestion**: Improvement proposal. Communicated to implementer while remaining APPROVE
+
+-
+```
diff --git a/.takt/facets/output-contracts/supervise-report.md b/.takt/facets/output-contracts/supervise-report.md
new file mode 100644
index 00000000..4b38ad04
--- /dev/null
+++ b/.takt/facets/output-contracts/supervise-report.md
@@ -0,0 +1,41 @@
+```markdown
+# Final Verification Result
+
+## Judgment: COMPLETE / FIX / SPEC_REVIEW
+
+Judgment criteria:
+
+- COMPLETE: All completion criteria met, validation passes, within scope
+- FIX: Implementation-level issues remain (resolvable by code changes)
+- SPEC_REVIEW: Spec-level issues (order.md needs modification)
+
+## Summary
+
+{1-2 sentence summary}
+
+## Completion Criteria Check
+
+| #   | Criterion | Result | Notes |
+| --- | --------- | ------ | ----- |
+| 1   |           | Yes/No |       |
+
+## Validation
+
+Summary of pnpm validate output
+
+## Scope Check
+
+| Aspect                         | Result |
+| ------------------------------ | ------ |
+| Changed files are within scope | OK/NG  |
+| PLAN.md unmodified             | OK/NG  |
+| order.md unmodified            | OK/NG  |
+
+## Remaining Issues (if FIX / SPEC_REVIEW)
+
+For each issue:
+
+- Description of the issue
+- Reason for routing to fix / spec-review
+- Specific fix instructions
+```
diff --git a/.takt/facets/personas/acceptor.md b/.takt/facets/personas/acceptor.md
new file mode 100644
index 00000000..7a70fdfd
--- /dev/null
+++ b/.takt/facets/personas/acceptor.md
@@ -0,0 +1,25 @@
+# Acceptor (Acceptance Tester)
+
+An agent that verifies whether the implementation meets the completion criteria of the task spec (order.md).
+Focuses on **spec compliance** and **behavior verification**, not code quality or style.
+
+## Role Boundaries
+
+**Does:**
+
+- Verify each completion criterion from order.md one by one
+- Execute validation commands and check results
+- Check for out-of-scope changes
+- Confirm that spec files (PLAN.md, order.md) have not been modified
+
+**Does not:**
+
+- Suggest code style improvements or refactoring (-> simplifier handles this)
+- Evaluate architecture design (-> architecture-reviewer handles this)
+- Propose new features
+
+## Behavioral Stance
+
+- Judge completion criteria as Yes/No
+- Do not offer vague "improvement suggestions"
+- On failure, provide specific reproduction steps
diff --git a/.takt/facets/personas/supervisor.md b/.takt/facets/personas/supervisor.md
new file mode 100644
index 00000000..9985a3e7
--- /dev/null
+++ b/.takt/facets/personas/supervisor.md
@@ -0,0 +1,24 @@
+# Supervisor (Final Verifier)
+
+An agent that verifies the overall consistency of the implementation and decides whether to complete, route back, or fix.
+
+## Role Boundaries
+
+**Does:**
+
+- Make a comprehensive judgment on completion criteria status
+- Execute validation and check results
+- Detect scope violations
+- Determine where to route back (fix / spec-review)
+
+**Does not:**
+
+- Suggest code style improvements or refactoring
+- Add new requirements
+- Rewrite the spec
+
+## Behavioral Stance
+
+- Complete what can be completed (do not hold things back with excessive nitpicking)
+- When routing back, clearly state the specific reason and target
+- Distinguish between spec issues and implementation issues
diff --git a/.takt/facets/policies/spec-revision.md b/.takt/facets/policies/spec-revision.md
new file mode 100644
index 00000000..cbbcc6a9
--- /dev/null
+++ b/.takt/facets/policies/spec-revision.md
@@ -0,0 +1,20 @@
+# Spec Revision Policy
+
+## Scope Rules
+
+- Only modify order.md
+- Do not change implementation code, tests, or config files
+- Do not change PLAN.md
+
+## Revision Rules
+
+- Always address blocking issues
+- Suggestion issues may be accepted or rejected at discretion (state the reason)
+- Maintain the spec structure (sections, completion criteria format)
+- When adding or removing files to change, read the existing code to confirm the rationale
+
+## Prohibited Actions
+
+- Changing implementation code
+- Ignoring review issues and reporting no changes
+- Significantly expanding the scope of order.md (consider splitting instead)
diff --git a/.takt/facets/policies/step-implementation.md b/.takt/facets/policies/step-implementation.md
new file mode 100644
index 00000000..4a7531b1
--- /dev/null
+++ b/.takt/facets/policies/step-implementation.md
@@ -0,0 +1,37 @@
+# Step Implementation Policy
+
+## Scope Rules
+
+- Only implement what the current step specifies
+- Do NOT implement anything from future steps
+- Do NOT modify the implementation plan (PLAN.md, RFC, design docs)
+- Do NOT modify the task order (order.md) — it is the authoritative spec
+- Changes to files outside the listed change targets are allowed ONLY if
+  the step's changes cause compilation or test failures in those files
+
+## Quality Rules
+
+- Run the project's validation command before declaring completion
+- Follow existing code patterns and conventions (refer to CLAUDE.md)
+- Keep changes minimal — no drive-by refactoring
+
+## Database Migration Rules
+
+When the task involves DB schema changes:
+
+- Edit the declarative schema (`db/shared.sql` or `db/tenant.sql`) first
+- Run `pnpm db:migrate` to generate migration SQL, then review it carefully
+- Atlas auto-generated SQL must be reviewed:
+  - Add `IF EXISTS` only to manually added `DROP TABLE` statements
+  - Do NOT modify Atlas-generated intermediate `DROP TABLE` in table-recreation flows
+    (to avoid breaking `atlas.sum` checksum validation)
+- Run `pnpm db:apply` to apply the migration
+- Run `pnpm db:generate` to regenerate Kysely types (`app/services/type.ts`)
+- Destructive operations must be tested against production-equivalent data before deploying
+
+## Prohibited Actions
+
+- Modifying spec/plan/RFC files
+- Modifying the task order (order.md)
+- Adding features not specified in the step
+- Changing test infrastructure unless the step requires it
diff --git a/.takt/pieces/implement-step.yaml b/.takt/pieces/implement-step.yaml
new file mode 100644
index 00000000..68dc7875
--- /dev/null
+++ b/.takt/pieces/implement-step.yaml
@@ -0,0 +1,153 @@
+name: implement-step
+description: 'Implement a single step from a plan: implement -> review -> fix loop'
+max_movements: 20
+initial_movement: implement
+
+loop_monitors:
+  - cycle:
+      - reviewers
+      - fix
+    threshold: 3
+    judge:
+      persona: supervisor
+      instruction: |
+        The review / fix loop has repeated {cycle_count} times.
+
+        Review the reports from each cycle and determine whether this loop
+        is making progress or stuck on the same issues.
+
+        **Reports to reference:**
+        - Architecture review: {report:architect-review.md}
+        - Supervisor validation: {report:supervisor-validation.md}
+
+        **Judgment criteria:**
+        - Are new issues being found/fixed in each cycle?
+        - Are the same findings being repeated?
+        - Are fixes actually being applied?
+      rules:
+        - condition: converging (findings decreasing, fixes applied)
+          next: reviewers
+        - condition: unproductive (same findings repeating)
+          next: ABORT
+
+movements:
+  - name: implement
+    edit: true
+    persona: coder
+    policy:
+      - coding
+      - step-implementation
+    knowledge:
+      - architecture
+      - implementation-plan
+    required_permission_mode: edit
+    instruction: |
+      You are implementing a specific step from an implementation plan.
+
+      **Read the task order carefully** — it contains the full specification:
+      - What to implement (and what NOT to implement)
+      - Which files to change
+      - Completion conditions
+      - Reference documents (read-only — do NOT modify them)
+
+      **Rules:**
+      - Only implement what the current step specifies
+      - Do NOT modify plan files, RFC documents, or design docs
+      - Each step must leave the project validation passing
+      - Follow existing code patterns and conventions (refer to CLAUDE.md)
+      - After implementation, run the validation command specified in the task order
+    rules:
+      - condition: Implementation complete, validation passes
+        next: reviewers
+      - condition: Cannot proceed, need clarification
+        next: ABORT
+        appendix: |
+          Blockers:
+          - {Issue description}
+    output_contracts:
+      report:
+        - name: coder-scope.md
+          format: coder-scope
+        - name: coder-decisions.md
+          format: coder-decisions
+
+  - name: reviewers
+    parallel:
+      - name: arch-review
+        edit: false
+        persona: architecture-reviewer
+        policy: review
+        knowledge: architecture
+        rules:
+          - condition: approved
+          - condition: needs_fix
+        instruction: |
+          Review the implementation changes against the task order specification.
+
+          **Review criteria:**
+          - Does the implementation match the spec in the task order?
+          - Are there any changes outside the specified scope?
+          - Were any plan/RFC/design files modified? (This is NOT allowed)
+          - Is the code consistent with existing patterns?
+          - Are there race conditions or edge cases missed?
+
+          Run the project validation command to verify the build passes.
+        output_contracts:
+          report:
+            - name: architect-review.md
+              format: architecture-review
+      - name: supervise
+        edit: false
+        persona: supervisor
+        policy: review
+        instruction: |
+          Validate the implementation against the step's completion conditions.
+
+          **Read the task order** and check each completion condition.
+
+          **Validation:**
+          - Run the project validation command — must pass
+          - Check each completion condition listed in the task order
+          - Verify no spec/plan/RFC files were modified
+          - Verify no unintended changes outside the step scope
+        rules:
+          - condition: All checks passed
+          - condition: Requirements unmet, tests failing, build errors
+        output_contracts:
+          report:
+            - name: supervisor-validation.md
+              format: supervisor-validation
+            - name: summary.md
+              format: summary
+              use_judge: false
+    rules:
+      - condition: all("approved", "All checks passed")
+        next: COMPLETE
+      - condition: any("needs_fix", "Requirements unmet, tests failing, build errors")
+        next: fix
+
+  - name: fix
+    edit: true
+    persona: coder
+    policy:
+      - coding
+      - step-implementation
+    knowledge:
+      - architecture
+      - implementation-plan
+    required_permission_mode: edit
+    instruction: |
+      Fix the issues found by the reviewers.
+
+      **Read the review reports** and address every issue raised.
+      After fixing, run the project validation command to confirm everything passes.
+
+      **Remember:**
+      - Do NOT modify plan/RFC/design files — fix only implementation code
+      - Stay within the step's scope
+    pass_previous_response: false
+    rules:
+      - condition: Fix complete
+        next: reviewers
+      - condition: Cannot proceed, insufficient info
+        next: ABORT
diff --git a/.takt/pieces/spec-implement-accept.yaml b/.takt/pieces/spec-implement-accept.yaml
new file mode 100644
index 00000000..d7c5fde6
--- /dev/null
+++ b/.takt/pieces/spec-implement-accept.yaml
@@ -0,0 +1,254 @@
+name: spec-implement-accept
+description: 'Spec generation -> Spec refinement -> Implementation -> Acceptance -> Supervision'
+max_movements: 30
+initial_movement: spec-draft
+
+# Custom facets
+personas:
+  acceptor: ../facets/personas/acceptor.md
+  supervisor: ../facets/personas/supervisor.md
+instructions:
+  spec-draft: ../facets/instructions/spec-draft.md
+  spec-review: ../facets/instructions/spec-review.md
+  acceptance: ../facets/instructions/acceptance.md
+  supervise: ../facets/instructions/supervise.md
+knowledge:
+  implementation-plan: ../facets/knowledge/implementation-plan.md
+policies:
+  step-implementation: ../facets/policies/step-implementation.md
+  spec-revision: ../facets/policies/spec-revision.md
+report_formats:
+  spec-review-report: ../facets/output-contracts/spec-review-report.md
+  acceptance-report: ../facets/output-contracts/acceptance-report.md
+  supervise-report: ../facets/output-contracts/supervise-report.md
+
+loop_monitors:
+  # Spec review <-> Spec revision loop
+  - cycle:
+      - spec-review
+      - spec-revise
+    threshold: 4
+    judge:
+      persona: architecture-reviewer
+      instruction: |
+        The spec review -> revision loop has repeated {cycle_count} times.
+
+        **Refer to the report:**
+        - Spec review result: {report:spec-review-report.md}
+
+        **Judgment criteria:**
+        - Are blocking issues decreasing?
+        - Are revisions being accurately reflected?
+        - Are new blocking issues continuing to emerge?
+        - If only suggestion-level issues remain, the spec can be finalized
+      rules:
+        - condition: Progress is being made (blocking issues decreasing, revisions reflected)
+          next: spec-review
+        - condition: Only suggestion-level issues remain and implementation is feasible
+          next: implement
+        - condition: Blocking issues are repeating without progress
+          next: ABORT
+
+  # Acceptance testing <-> Fix loop
+  - cycle:
+      - acceptance
+      - fix
+    threshold: 3
+    judge:
+      persona: acceptor
+      instruction: |
+        The acceptance testing -> fix loop has repeated {cycle_count} times.
+
+        **Refer to the report:**
+        - Acceptance testing result: {report:acceptance-report.md}
+
+        **Judgment criteria:**
+        - Are issues decreasing with each cycle?
+        - Are fixes actually being reflected?
+        - Are the same issues being repeated?
+      rules:
+        - condition: Progress is being made (issue count decreasing, fixes reflected)
+          next: acceptance
+        - condition: Unproductive (same issues repeating)
+          next: supervise
+
+movements:
+  # 1. Spec draft generation
+  - name: spec-draft
+    edit: true
+    persona: architecture-reviewer
+    knowledge: implementation-plan
+    instruction: spec-draft
+    required_permission_mode: edit
+    rules:
+      - condition: order.md generation complete
+        next: spec-review
+      - condition: Task description insufficient to write a spec
+        next: ABORT
+
+  # 2. Spec review
+  - name: spec-review
+    edit: false
+    persona: architecture-reviewer
+    knowledge: implementation-plan
+    instruction: spec-review
+    output_contracts:
+      report:
+        - name: spec-review-report.md
+          format: spec-review-report
+    rules:
+      - condition: Spec is clear and implementable (no blocking issues)
+        next: implement
+      - condition: Spec has improvable issues (blocking issues present)
+        next: spec-revise
+      - condition: Spec is fundamentally broken and cannot be fixed
+        next: ABORT
+
+  # 3. Spec revision
+  - name: spec-revise
+    edit: true
+    persona: architecture-reviewer
+    policy: spec-revision
+    knowledge: implementation-plan
+    required_permission_mode: edit
+    instruction: |
+      Revise order.md in response to issues raised in the spec review.
+
+      **Steps:**
+      1. Read the spec review report and understand the blocking issues
+      2. Read the files to change and verify the actual state of existing code
+      3. Revise order.md:
+         - Fix or supplement the spec to address blocking issues
+         - Selectively incorporate suggestions (not mandatory)
+         - Add or update files to change
+         - Add or update completion criteria
+      4. Report a summary of the changes
+
+      **Rules:**
+      - Only modify order.md (do not change implementation code)
+      - Do not include code examples or snippets (keep at requirements level)
+      - Maintain the existing structure of order.md
+      - Explicitly document how each review issue was addressed
+    rules:
+      - condition: Spec revision complete
+        next: spec-review
+      - condition: Cannot revise (fundamental direction change needed)
+        next: ABORT
+
+  # 4. Implementation
+  - name: implement
+    edit: true
+    persona: coder
+    policy:
+      - coding
+      - step-implementation
+    knowledge: implementation-plan
+    session: refresh
+    required_permission_mode: edit
+    instruction: |
+      Implement according to the task spec (order.md).
+
+      **Steps:**
+      1. Read order.md and understand the implementation details, files to change, and completion criteria
+      2. Read the files to change and understand the existing code structure
+      3. If DB schema changes are needed:
+         a. Edit the declarative schema (`db/shared.sql` or `db/tenant.sql`)
+         b. Run `pnpm db:migrate` to generate migration SQL
+         c. Review the generated migration carefully
+         d. Run `pnpm db:apply` to apply the migration
+         e. Run `pnpm db:generate` to regenerate Kysely types
+      4. Perform the implementation
+      5. Run formatting fix and validation:
+         ```bash
+         pnpm format:fix && pnpm validate
+         ```
+
+      **Rules:**
+      - Only modify files listed in order.md's files to change
+      - Do not modify PLAN.md or order.md
+      - Follow existing code patterns and conventions (refer to CLAUDE.md)
+      - Keep changes minimal
+    rules:
+      - condition: Implementation complete, validation passes
+        next: acceptance
+      - condition: Cannot implement, insufficient information
+        next: ABORT
+
+  # 5. Acceptance testing
+  - name: acceptance
+    edit: false
+    persona: acceptor
+    policy: step-implementation
+    knowledge: implementation-plan
+    instruction: acceptance
+    output_contracts:
+      report:
+        - name: acceptance-report.md
+          format: acceptance-report
+    rules:
+      - condition: All completion criteria met, validation passes
+        next: supervise
+      - condition: Completion criteria not met or issues found
+        next: fix
+
+  # 6. Fix
+  - name: fix
+    edit: true
+    persona: coder
+    provider: claude
+    policy:
+      - coding
+      - step-implementation
+    knowledge: implementation-plan
+    session: refresh
+    required_permission_mode: edit
+    pass_previous_response: false
+    provider_options:
+      claude:
+        allowed_tools:
+          - Read
+          - Glob
+          - Grep
+          - Edit
+          - Write
+          - Bash
+    instruction: |
+      Fix the issues raised in the acceptance testing.
+
+      **Steps:**
+      1. Read the acceptance testing report and understand the issues
+      2. If a supervise report exists (supervise-report.md), read it for additional context
+      3. Apply fixes for each issue
+      4. Run formatting fix and validation:
+         ```bash
+         pnpm format:fix && pnpm validate
+         ```
+
+      **Rules:**
+      - Do not modify PLAN.md or order.md
+      - Only make fixes within scope
+    rules:
+      - condition: Fix complete
+        next: acceptance
+      - condition: Cannot fix
+        next: supervise
+
+  # 7. Final verification
+  - name: supervise
+    edit: false
+    persona: supervisor
+    policy: step-implementation
+    knowledge: implementation-plan
+    instruction: supervise
+    pass_previous_response: false
+    output_contracts:
+      report:
+        - name: supervise-report.md
+          format: supervise-report
+    rules:
+      - condition: All completion criteria met, ready to complete
+        next: COMPLETE
+      - condition: Implementation-level issues remain (resolvable by code changes)
+        next: fix
+      - condition: Spec-level issues (order.md needs modification)
+        next: spec-review
diff --git a/.takt/tasks.yaml b/.takt/tasks.yaml
new file mode 100644
index 00000000..b05ae6b6
--- /dev/null
+++ b/.takt/tasks.yaml
@@ -0,0 +1 @@
+tasks: []