tlc-claude-code 2.5.0 → 2.6.1

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

@@ -103,6 +103,116 @@ process.stdout.write(JSON.stringify(result));" 2>/dev/null
 
 **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 is the **project manager**. Claude reads the plan, breaks tasks into small prompts, and dispatches each to the tlc-core orchestrator. Claude does NOT write code.
+
+### Step O1: Read the Plan
+
+Read `.planning/phases/{N}-PLAN.md`. Extract each task's goal, files, acceptance criteria, and test cases.
+
+### Step O2: Check Orchestrator Health
+
+```bash
+curl -sf http://localhost:3100/health
+```
+
+If healthy, dispatch via orchestrator (Step O3). If unreachable, fall back to direct Codex dispatch via Bash (Step O3-fallback).
+
+### Step O3: Dispatch Tasks to Orchestrator
+
+For each independent task, dispatch via the orchestrator API:
+
+```bash
+curl -s -X POST http://localhost:3100/sessions \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "project": "<project-name>",
+    "pool": "local-tmux",
+    "command": "<provider>",
+    "prompt": "<task prompt — one clear action, explicit file paths, under 500 words>"
+  }'
+```
+
+- `project`: the repo directory name under `/workspace/` (e.g., `Tools/TLC`)
+- `command`: the provider from routing result (e.g., `codex`)
+- `prompt`: small focused prompt for one task — include file paths, acceptance criteria, test command
+
+**Save each returned session ID** to `.tlc/.active-sessions.json`:
+
+```bash
+node -e "
+const fs = require('fs');
+const path = '.tlc/.active-sessions.json';
+const existing = fs.existsSync(path) ? JSON.parse(fs.readFileSync(path, 'utf8')) : [];
+existing.push({ sessionId: '<id>', taskName: '<task>', startedAt: new Date().toISOString() });
+fs.writeFileSync(path, JSON.stringify(existing, null, 2));
+"
+```
+
+### Step O3-fallback: Direct Dispatch (No Orchestrator)
+
+If orchestrator is down, dispatch directly via tmux on the host:
+
+```bash
+tmux new-session -d -s <task-id> -c $(pwd)
+tmux send-keys -t <task-id> "/opt/homebrew/bin/codex --full-auto '<prompt>'" Enter
+```
+
+### Step O4: Report and Free
+
+After dispatching all tasks, report:
+
+```
+Dispatched N tasks to orchestrator:
+  ses_abc123  Task 1: Create schema         codex  running
+  ses_def456  Task 2: Add validation         codex  running
+
+Run /tlc:status to check progress.
+I'm free — what would you like to work on?
+```
+
+**STOP HERE.** Do not write code. Do not execute inline mode. Claude is the PM, not the coder.
+
+### Step O5: Monitor (When User Asks)
+
+When the user asks for status or agents complete, check:
+
+```bash
+# Check all sessions
+curl -s http://localhost:3100/sessions | node -e "
+const d=require('fs').readFileSync('/dev/stdin','utf8');
+JSON.parse(d).forEach(s=>console.log(s.id, s.status, s.project));
+"
+
+# Check specific session output (inside container)
+docker exec tlc-agent-runner tmux capture-pane -t <session_id> -p -S -20
+```
+
+Auto-approve any prompts found in tmux sessions:
+
+```bash
+docker exec tlc-agent-runner tmux send-keys -t <session_id> Enter
+```
+
+### Step O6: Cleanup
+
+When all tasks complete, remove `.tlc/.build-routing-active` and report results.
+
+## 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:
@@ -391,7 +501,7 @@ All agents use **opus**. No opus, no opus. Cost is not a concern — quality is.
 **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):
 
@@ -519,7 +629,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.
 
@@ -551,6 +661,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
@@ -705,7 +828,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
@@ -717,16 +857,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.
+
+#### 4e. Move to next task
 
-Repeat 4a-4c for each task in the test plan.
+Repeat 4a-4d for each task in the test plan.
 
 **Critical Rules:**
 - Tests must be **syntactically valid** and **runnable**
@@ -1051,6 +1193,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" \
@@ -1068,6 +1218,14 @@ 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: