feat: takt ワークフロー導入 (#272)

* feat: takt ワークフロー導入

durably の .takt/ 構成をベースに upflow 向けにカスタマイズ:
- spec-implement-accept ピース（フルフロー: 仕様 → レビュー → 実装 → 受入 → 監督）
- implement-step ピース（単一ステップ: 実装 → 並列レビュー → 修正）
- DB マイグレーション手順を knowledge/policy/instruction に組み込み
- マルチテナントセキュリティチェックを spec-review に追加

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* fix: CodeRabbit レビュー指摘を反映

- provider_profiles の default_permission_mode を full → edit に制限
- git diff --name-only に HEAD を明示（acceptance, supervise）
- spec-review-report にマルチテナントセキュリティチェック項目を追加
- supervise-report に PLAN.md unmodified チェックを追加
- DROP TABLE の IF EXISTS ルールで Atlas 生成分と手動分を明確に区別
- loop_monitor の分岐を分離（blocking 未解決時は ABORT）
- 英語表現の修正（supervise report → supervision report 等）

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: coji

.takt/.gitignore

@@ -0,0 +1,7 @@
+# Runtime data (not version-controlled)
+runs/
+tasks/
+clone-meta/
+worktree-sessions/
+session-state.json
+persona_sessions.json

.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

.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)

.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")

.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

.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

.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

.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)
+
+-
+```

.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
+
+-
+```

.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
+```