tlc-claude-code 2.4.10 → 2.6.0

package/.claude/commands/tlc/autofix.md

@@ -95,7 +95,40 @@ process.stdout.write(JSON.stringify(result));" 2>/dev/null
    - Execute inline (Claude) AND dispatch to CLI models simultaneously
    - Collect and merge results
 
-**Override:** Pass `--model <name>` to route this specific run to a different model.
+**Override:** Pass `--model <name>` to route this specific run to a different model.
+
+After `resolveRouting` returns, immediately write `.tlc/.autofix-routing-active` with the active provider name from `models[0]` before doing any other autofix work. Remove `.tlc/.autofix-routing-active` on completion, cancellation, or failure cleanup.
+
+**Routing decision:**
+- If routing says external provider (`models[0] !== 'claude'`), follow **ONLY ORCHESTRATOR MODE** below.
+- If routing says Claude (`models[0] === 'claude'`), follow **INLINE MODE** below.
+
+## ORCHESTRATOR MODE
+
+Use this mode only when `models[0]` is **NOT** `claude`.
+
+Claude does not execute the autofix instructions inline in this path. Claude acts as the orchestrator for the routed provider run:
+
+1. Claude acts as the orchestrator for routed test-failure recovery rather than applying the autofix flow inline.
+2. Gather the failing test context, error output, project conventions, and relevant files before dispatching each fix attempt.
+3. Dispatch focused repair prompts through the provider CLI path, using `codex exec` for Codex-style providers or `gemini -p` for Gemini-style providers, preferably via the shared dispatch layer when available.
+4. Verify every routed fix before accepting it:
+   - Confirm the proposed change addresses the actual failure mode rather than masking symptoms.
+   - Confirm the relevant tests were re-run or that the provider clearly identified what still needs verification.
+   - Reject speculative or unverified fixes and dispatch a narrower retry using the latest failure data.
+5. Continue the dispatch, verify, and retry loop until the targeted failures are fixed or an explicit blocker is reported.
+6. Handle failures explicitly:
+   - If dispatch fails because of model mismatch, auth, or missing CLI, check `.tlc/.router-state.json` for the provider's actual available model and retry once with the corrected model.
+   - If retry still fails, stop and report the exact failure to the user. Do not silently fall back to Claude inline execution.
+   - If a routed fix worsens the state or returns partial edits, stop that branch and issue a corrective follow-up with the exact observed regression.
+7. When finished, display the routed autofix result, persist any captured memory, remove `.tlc/.autofix-routing-active`, and stop. Do **not** execute Inline Mode afterward.
+
+## INLINE MODE
+
+Use this mode only when `models[0]` **IS** `claude`.
+
+The existing autofix instructions below are the Inline Mode instructions and should be followed unchanged.
+
 
 ## What This Does
 

package/.claude/commands/tlc/build.md

@@ -96,9 +96,48 @@ process.stdout.write(JSON.stringify(result));" 2>/dev/null
    - Execute inline (Claude) AND dispatch each external provider via `dispatch` from `orchestration/cli-dispatch`
    - After each provider completes, capture its output with `captureFromProvider` from `capture`
    - Collect and merge results
+   - **CRITICAL: If a provider fails (wrong model, auth error, CLI missing), do NOT silently fall back to single-provider.** Instead:
+     1. Check `.tlc/.router-state.json` for the provider's actual available model and retry
+     2. If retry fails, ask the user: "[Provider] failed: [reason]. Run with [other provider] only, or fix and retry?"
+     3. Never say "proceeding with X-only" without user consent
 
 **Override:** Pass `--model <name>` to route this specific run to a different model.
 
+After `resolveRouting` returns, immediately write `.tlc/.build-routing-active` with the active provider name from `models[0]` before doing any other build work. Remove `.tlc/.build-routing-active` on completion, cancellation, or failure cleanup.
+
+**Routing decision:**
+- If routing says external provider (`models[0] !== 'claude'`), follow **ONLY Orchestrator Mode** below.
+- If routing says Claude (`models[0] === 'claude'`), follow **Inline Mode** below.
+
+## ORCHESTRATOR MODE
+
+Use this mode only when `models[0]` is **NOT** `claude`.
+
+Claude does not execute the build instructions inline in this path. Claude acts as the orchestrator for the routed provider run:
+
+1. Read the full build plan and break the work into the smallest practical execution slices for Codex-style `exec` dispatches.
+2. For each slice, prepare the exact task context, success criteria, test target, and file scope before dispatch.
+3. Resolve orchestration modules with fallback: try `tlc-claude-code/server/lib/...` first, then `$PROJECT_DIR/server/lib/...`.
+4. Build the full prompt with `buildFullPrompt` from `orchestration/prompt-builder`.
+5. Dispatch through unified CLI routing with `dispatch` from `orchestration/cli-dispatch`.
+6. After each provider response, capture output for memory with `captureFromProvider` from `capture`.
+7. Verify every returned result:
+   - Confirm the requested change was actually made.
+   - Confirm tests relevant to that slice were run or explain why not.
+   - Reject incomplete, unverifiable, or off-plan output.
+8. Handle failures explicitly:
+   - If dispatch fails because of model mismatch, auth, or missing CLI, check `.tlc/.router-state.json` for the provider's actual available model and retry once with the corrected model.
+   - If retry still fails, stop and report the exact failure to the user. Do not silently fall back to Claude inline execution.
+   - If a dispatched task returns partial or broken work, issue a focused follow-up dispatch for the fix instead of continuing blindly.
+9. Continue dispatch/verify/fix until the routed provider work is complete and validated.
+10. When finished, display the provider output summary, persist captured memory, remove `.tlc/.build-routing-active`, and stop. Do **not** execute Inline Mode instructions afterward.
+
+## INLINE MODE
+
+Use this mode only when `models[0]` **IS** `claude`.
+
+The existing build instructions below are the Inline Mode instructions and should be followed unchanged.
+
 ## Engineering Standards
 
 **Code like a senior engineer with 15+ years experience.** Every line should reflect:
@@ -276,8 +315,7 @@ This is the core TLC command. Tests before code, one task at a time.
 ```
 /tlc:build <phase_number>
 /tlc:build <phase_number> --sequential      # Force sequential mode
-/tlc:build <phase_number> --model sonnet    # Force all agents to use sonnet
-/tlc:build <phase_number> --model haiku     # Force all agents to use haiku (fast/cheap)
+/tlc:build <phase_number> --model opus      # All agents use opus (this is the default)
 /tlc:build <phase_number> --max-turns 30    # Limit agent execution length
 /tlc:build <phase_number> --agents 5        # Limit parallel agents to 5
 ```
@@ -333,7 +371,7 @@ After loading plans, analyze task dependencies and available providers to pick t
 |-----------|----------|--------------|
 | 2+ independent tasks, Claude + Codex available, tmux available | **Worktree + Tmux** | Each task gets own git worktree + tmux pane. Claude and Codex work simultaneously. |
 | 2+ independent tasks, Claude + Codex available, no tmux | **Worktree + Background** | Same but without tmux visibility. |
-| 2+ independent tasks, single provider only | **In-process agents** | Agent tool spawns parallel sub-agents (sonnet/haiku by complexity). |
+| 2+ independent tasks, single provider only | **In-process agents** | Agent tool spawns parallel sub-agents (all opus). |
 | All tasks have dependencies | **Sequential** | One task at a time, in dependency order. |
 | 1 task only | **Sequential** | Just build it. |
 
@@ -359,9 +397,9 @@ Providers: claude (1 available)
 Strategy: in-process agents (parallel)
 
   Task 1: Create user schema         → opus   (heavy)
-  Task 2: Add validation helpers     → sonnet (standard)
-  Task 3: Write migration scripts    → sonnet (standard)
-  Task 4: Create seed data           → haiku  (light)
+  Task 2: Add validation helpers     → opus (standard)
+  Task 3: Write migration scripts    → opus (standard)
+  Task 4: Create seed data           → opus  (light)
 
 Launching...
 ```
@@ -377,17 +415,18 @@ Strategy: sequential
 Starting Task 1...
 ```
 
-**Model auto-selection (in-process agent mode):**
-| Complexity | Model | When |
-|-----------|-------|------|
-| Heavy | opus | Architecture, multi-file features, security, auth, database |
-| Standard | sonnet | Normal implementation tasks (default) |
-| Light | haiku | Config, boilerplate, DTOs, enums, constants, seed data |
+**Model selection (in-process agent mode):**
+
+All agents use **opus**. No opus, no opus. Cost is not a concern — quality is.
+
+| Task | Model |
+|------|-------|
+| Any | opus |
 
 **Provider round-robin (worktree mode):**
 Tasks alternate between available providers. If Claude + Codex are both available, odd tasks go to Claude, even to Codex. Respects router state — never dispatches to unavailable providers.
 
-### Step 1b: Execute Parallel Build
+### Step 1c: Execute Parallel Build
 
 **Worktree + Tmux mode** (multi-provider):
 
@@ -397,9 +436,9 @@ Tasks alternate between available providers. If Claude + Codex are both availabl
 Spawning 4 agents in parallel...
 
 Agent 1: Task 1 - Create user schema          [opus]
-Agent 2: Task 2 - Add validation helpers      [sonnet]
-Agent 3: Task 3 - Write migration scripts     [sonnet]
-Agent 4: Task 4 - Create seed data            [haiku]
+Agent 2: Task 2 - Add validation helpers      [opus]
+Agent 3: Task 3 - Write migration scripts     [opus]
+Agent 4: Task 4 - Create seed data            [opus]
 
 [All agents spawned - working in background]
 ```
@@ -416,9 +455,9 @@ Agent 4: Task 4 - Create seed data            [haiku]
 
 ```
 Task(description="Agent 1: Task 1", prompt="...", subagent_type="general-purpose", model="opus", max_turns=50, run_in_background=true)
-Task(description="Agent 2: Task 2", prompt="...", subagent_type="general-purpose", model="sonnet", max_turns=50, run_in_background=true)
-Task(description="Agent 3: Task 3", prompt="...", subagent_type="general-purpose", model="sonnet", max_turns=50, run_in_background=true)
-Task(description="Agent 4: Task 4", prompt="...", subagent_type="general-purpose", model="haiku", max_turns=50, run_in_background=true)
+Task(description="Agent 2: Task 2", prompt="...", subagent_type="general-purpose", model="opus", max_turns=50, run_in_background=true)
+Task(description="Agent 3: Task 3", prompt="...", subagent_type="general-purpose", model="opus", max_turns=50, run_in_background=true)
+Task(description="Agent 4: Task 4", prompt="...", subagent_type="general-purpose", model="opus", max_turns=50, run_in_background=true)
 ```
 
 **Live Progress Monitoring (TaskOutput):**
@@ -449,9 +488,9 @@ Display format:
 | Agent | Task | Model | Tests | Phase |
 |-------|------|-------|-------|-------|
 | a1b2c3 | User Schema | opus | 29 ✓ | committed |
-| d4e5f6 | Validation | sonnet | 18 ✓ | implementing |
-| g7h8i9 | Migrations | sonnet | - | writing-tests |
-| j0k1l2 | Seed Data | haiku | 5 ✓ | committed |
+| d4e5f6 | Validation | opus | 18 ✓ | implementing |
+| g7h8i9 | Migrations | opus | - | writing-tests |
+| j0k1l2 | Seed Data | opus | 5 ✓ | committed |
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
@@ -515,7 +554,7 @@ After merge-back:
 4. If clean, the integration branch is ready for a single PR to main
 5. Continue to Step 8 (verification)
 
-### Step 1c: Sync and Claim (Multi-User, Sequential Only)
+### Step 1d: Sync and Claim (Multi-User, Sequential Only)
 
 **Note:** Skip this step if using Overdrive mode - agents handle claiming automatically.
 
@@ -547,6 +586,19 @@ Before starting work, coordinate with teammates:
 
 If no markers exist in PLAN.md, skip this step (single-user mode).
 
+### Step 1b: Migration Snapshot
+
+Check for migration files in the current diff:
+```bash
+MIGRATION_FILES=$(git diff --name-only main...HEAD | grep -E "prisma/migrations|drizzle/|migrations/.*\.(ts|js|sql)|alembic/versions" | grep -v "\.test\.")
+```
+
+If `MIGRATION_FILES` is not empty:
+1. Detect DB connection from `.env` or config
+2. Take snapshot: run `server/lib/scaffolding/snapshot-manager.js takeSnapshot()`
+3. Report: `DB snapshot taken: .tlc/snapshots/{filename}. Run /tlc:restore to rollback if needed.`
+4. If snapshot fails (DB not running): warn but continue build
+
 ### Step 2: Detect Test Framework
 
 #### Check TLC Config First
@@ -701,7 +753,24 @@ def test_login_raises_for_invalid_password():
         login("user@test.com", "wrong")
 ```
 
-#### 4b. Run this test file
+#### 4b. Generate E2E Tests
+
+After writing the unit test file for the task, generate matching end-to-end coverage from the task's acceptance criteria in `PLAN.md`.
+
+Process:
+- Parse acceptance criteria for the current task from `PLAN.md` using `server/lib/e2e/acceptance-parser.js`
+- Detect the existing E2E framework, or scaffold one if missing, using `server/lib/e2e/framework-detector.js`
+- Generate E2E test files for the current task using `server/lib/e2e/test-generator.js`
+- Place generated E2E coverage alongside the task's unit tests in the same red/green workflow
+
+Requirements:
+- E2E tests must map directly to acceptance criteria for the current task
+- Generated files must follow the detected or scaffolded framework conventions
+- If no E2E framework exists, scaffold it before generating tests
+- E2E tests should be committed alongside the unit tests for that task
+- Do NOT write implementation code while generating tests
+
+#### 4c. Run this test file
 
 ```bash
 npm test -- tests/auth/login.test.ts   # vitest
@@ -713,16 +782,18 @@ Verify:
 - ✅ Tests FAIL (not pass, not skip)
 - ❌ If import errors, add mocks/stubs and retry
 
-#### 4c. Commit this test file
+#### 4d. Commit this test file
 
 ```bash
 git add tests/auth/login.test.ts
 git commit -m "test: add login tests (red) - phase {N}"
 ```
 
-#### 4d. Move to next task
+If E2E files were generated for the task, stage and commit them in the same commit as the unit tests.
 
-Repeat 4a-4c for each task in the test plan.
+#### 4e. Move to next task
+
+Repeat 4a-4d for each task in the test plan.
 
 **Critical Rules:**
 - Tests must be **syntactically valid** and **runnable**
@@ -787,6 +858,33 @@ Review the task's:
 - Acceptance criteria
 - Test cases (now written and failing)
 
+#### 7a-gh. GitHub: Mark In Progress
+
+If GitHub sync is enabled, update the linked GitHub issue for this task:
+
+```bash
+node -e "
+const path = require('path');
+const fs = require('fs');
+const { execSync } = require('child_process');
+let gh;
+try { gh = require('tlc-claude-code/server/lib/github'); }
+catch { gh = require(path.join(process.cwd(), 'server/lib/github')); }
+try {
+  const cfg = gh.loadGitHubConfig(process.cwd(), { fs }).config;
+  if (!cfg) process.exit(0);
+  const exec = (cmd) => execSync(cmd, { encoding: 'utf-8', stdio: ['pipe','pipe','pipe'] });
+  const user = execSync('git config user.name', { encoding: 'utf-8' }).trim();
+  const issueNumber = process.argv[1];
+  if (issueNumber) {
+    gh.assignIssue({ owner: cfg.owner, repo: cfg.repo, number: Number(issueNumber), assignees: [user], exec });
+  }
+} catch (e) { console.error('[TLC] GitHub status update failed:', e.message); }
+" "{issue_number}" 2>/dev/null
+```
+
+If no issue is linked to this task, skip silently. Failures warn but never block.
+
 #### 7b. Implement the code
 Write the minimum code needed to pass the tests:
 - Create files specified in the task
@@ -828,6 +926,35 @@ This keeps the plan file as the single source of truth for task status. Do NOT w
 
 If in multi-user mode, also push to share progress with team.
 
+#### 7e-gh. GitHub: Mark Done
+
+If GitHub sync is enabled, update the linked issue status after marking the task `[x]`:
+
+```bash
+node -e "
+const path = require('path');
+const fs = require('fs');
+const { execSync } = require('child_process');
+let gh;
+try { gh = require('tlc-claude-code/server/lib/github'); }
+catch { gh = require(path.join(process.cwd(), 'server/lib/github')); }
+try {
+  const cfg = gh.loadGitHubConfig(process.cwd(), { fs }).config;
+  if (!cfg) process.exit(0);
+  const planPath = process.argv[1];
+  const r = gh.updateTaskStatuses({
+    planPath,
+    config: cfg,
+    ghClient: { exec: (cmd) => execSync(cmd, { encoding: 'utf-8', stdio: ['pipe','pipe','pipe'] }) },
+    fs
+  });
+  console.log(JSON.stringify(r));
+} catch (e) { console.error('[TLC] GitHub status sync failed:', e.message); }
+" ".planning/phases/{N}-PLAN.md" 2>/dev/null
+```
+
+Failures warn but never block the build.
+
 #### 7f. Move to next task
 Repeat 7a-7e for each task in the phase.
 
@@ -991,6 +1118,14 @@ After user approval:
 # Push branch
 git push -u origin "$branchName"
 
+# Warn if the PR will have no automated CI checks
+node -e "const fs = require('fs');
+const { detectCI } = require('./server/lib/scaffolding/ci-detector.js');
+const result = detectCI({ projectDir: process.cwd(), fs });
+if (result.platform === 'none') {
+  console.warn('No CI configured. PR will not have automated checks. Run /tlc:ci to set up.');
+}" 2>/dev/null
+
 # Create PR with phase summary
 gh pr create \
   --base "$mainBranch" \
@@ -1008,6 +1143,47 @@ gh pr create \
 {test runner summary}"
 ```
 
+**Merge strategy:** When merging PRs, ALWAYS use `--merge` (not `--squash`):
+```bash
+gh pr merge <number> --merge
+```
+- `--merge` preserves commit history and shows the correct PR title
+- `--squash` only when the user explicitly asks for it (messy WIP branches)
+- Sync PRs (dev → test, test → main) MUST use `--merge` — never squash a sync
+
+#### Step 11-gh: GitHub: Link PR to Project
+
+If GitHub sync is enabled, after the PR is created:
+
+1. Add `Closes #N` references to the PR body for all completed task issues (parse `<!-- gh:N -->` markers from PLAN.md)
+2. Add the PR to the GitHub project board if configured
+3. Set the phase issue Status to "In review"
+
+```bash
+node -e "
+const path = require('path');
+const fs = require('fs');
+const { execSync } = require('child_process');
+let gh;
+try { gh = require('tlc-claude-code/server/lib/github'); }
+catch { gh = require(path.join(process.cwd(), 'server/lib/github')); }
+try {
+  const cfg = gh.loadGitHubConfig(process.cwd(), { fs }).config;
+  if (!cfg) process.exit(0);
+  const exec = (cmd) => execSync(cmd, { encoding: 'utf-8', stdio: ['pipe','pipe','pipe'] });
+  const prNumber = Number(process.argv[1]);
+  const planPath = process.argv[2];
+  const content = fs.readFileSync(planPath, 'utf-8');
+  const issueRefs = [...content.matchAll(/<!-- gh:(\d+) -->/g)].map(m => Number(m[1]));
+  if (issueRefs.length > 0) {
+    gh.linkPrToIssue({ ...cfg, prNumber, issueNumbers: issueRefs, exec });
+  }
+} catch (e) { console.error('[TLC] GitHub PR link failed:', e.message); }
+" "{pr_number}" ".planning/phases/{N}-PLAN.md" 2>/dev/null
+```
+
+Failures warn but never block.
+
 **The PR is the deliverable, not the commits.** CI runs on the PR. Merge when green.
 
 **If the user has already been working on main** (e.g., first time using branching): push main directly but note that future phases MUST use branches.