@taktdev/coda 1.0.0 → 1.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@taktdev/coda",
-  "version": "1.0.0",
+  "version": "1.1.0",
   "description": "Bugherd QA automation MCP server",
   "type": "module",
   "bin": {

package/skills/qa-approve/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: qa-approve
-description: "Commit and tag fixes for Bugherd tickets. Triggers Ready for Review in Bugherd."
+description: "Merge fix branches into main with tagged commits. Triggers Ready for Review in Bugherd."
 argument-hint: "<ticket-id> [ticket-id...]"
 user-invocable: true
 ---
 
 # /qa-approve
 
-Merge fix branches into main/current branch with tagged commits that trigger Bugherd's GitHub integration, then shut down the responsible agent to free a team slot.
+Tell the remediator to commit, then merge its branch into main with a tagged commit that triggers Bugherd's GitHub integration. Shut down the agent afterward.
 
 ## Usage
 
@@ -21,7 +21,8 @@ Merge fix branches into main/current branch with tagged commits that trigger Bug
 
 - **Single ticket:** `/qa-approve 42`
 - **Multiple tickets:** `/qa-approve 42 43 44`
-- **All pending:** `/qa-approve all` — finds all `.takty/qa/BH-*.md` files that have NOT been renamed to `-fixed` (i.e., excludes `BH-*-fixed.md`)
+- **All pending:** `/qa-approve all` — finds all `.takty/qa/BH-*.md` files, excluding both `BH-*-fixed.md` AND `BH-*-flagged.md`
+- **Flagged ticket:** `/qa-approve {id}` on a flagged ticket (`BH-{id}-flagged.md`) — warn user, show the Analysis section, and require explicit confirmation before proceeding
 
 ## Flow
 
@@ -29,37 +30,45 @@ For each ticket:
 
 ### 1. Read Remediation File
 
-Read `.takty/qa/BH-{id}.md` to get:
-- The branch name (from the "Worktree" section)
+Check for both `.takty/qa/BH-{id}.md` and `.takty/qa/BH-{id}-flagged.md`. Read whichever exists to get:
+- The branch name (from the `## Worktree` section)
 - The short description (from the `# BH-{id}: {title}` heading)
-- The list of changes made
-- The **agent name** (from the "Agent" section)
+- The agent name (from the `## Agent` section)
+- The worktree path (from the `## Worktree` section)
 
-### 2. Verify Branch Exists
+### 2. Check for Flagged
 
-Check that the branch exists:
+If the file is `BH-{id}-flagged.md`:
+- Show the Analysis section to the user
+- Warn that this ticket was flagged for manual review
+- Ask for explicit confirmation before proceeding
+- `/qa-approve all` **skips** flagged tickets and reports them at the end
+
+### 3. Tell Remediator to Commit
+
+Send a message to the remediator agent instructing it to commit in its worktree:
 
 ```bash
-git branch --list {branch-name}
+git add -A && git commit -m "fix: BH-{id} {description}"
 ```
 
-If the branch doesn't exist, report which tickets couldn't be found and skip them. Continue with remaining tickets.
+Do NOT add a `Co-Authored-By` line. The remediator confirms the commit.
 
-### 3. Merge the Branch
+### 4. Team Lead Merges
 
-Merge the ticket's branch into the current branch (usually `main`):
+In the **main workspace** (not the worktree), merge the remediator's branch:
 
 ```bash
-git merge {branch-name} --no-ff -m "{short description} [Ready for Review BH-{id}]"
+git merge {branch} --no-ff -m "{description} [Ready for Review BH-{id}]"
 ```
 
-This creates a merge commit with the Bugherd tag in a single step.
+This is safe because worktrees are isolated — merging one branch into main does not affect any other remediator's worktree.
 
-If there are merge conflicts:
+If merge conflicts arise (because main moved forward from earlier approvals):
 - For simple conflicts (whitespace, non-overlapping changes): resolve automatically
 - For complex conflicts: ask the user to resolve manually
 
-### 4. Verify Tagged Commit
+### 5. Verify Tagged Commit
 
 Confirm the merge commit was created with the correct tag format:
 
@@ -69,35 +78,39 @@ git log -1 --oneline
 
 **Tag format rules:**
 - The Bugherd tag **must be in the commit subject line** (first line), not in the body/description
-- Do NOT add a `Co-Authored-By` line — it can interfere with the tag parsing
+- Do NOT add a `Co-Authored-By` line — it can interfere with tag parsing
 - **Case-sensitive** — must be `Ready for Review` (capital R on Review), not `Ready for review`
-- Multiple tickets in one commit: `{short description} [Ready for Review BH-1,2,3]`
+- Multiple tickets in one commit: `{description} [Ready for Review BH-1,2,3]`
 
-### 5. Mark Remediation File as Fixed
+### 6. Rename Remediation File
 
-Rename the remediation file to append `-fixed`:
+Rename the remediation file to mark it as fixed:
 
 ```bash
 mv .takty/qa/BH-{id}.md .takty/qa/BH-{id}-fixed.md
 ```
 
-### 6. Shut Down the Agent
+(Or from `BH-{id}-flagged.md` to `BH-{id}-fixed.md` if it was a flagged ticket that was approved.)
 
-If the remediation file has an **Agent** name and that agent is still part of the team:
+### 7. Delete Branch
 
+Clean up the merged branch:
+
+```bash
+git branch -d {branch}
 ```
-SendMessage type: "shutdown_request" to the agent
-```
 
-This frees a team slot. If more tickets are waiting in the Bugherd development column, the team lead can spawn a new agent.
+### 8. Shut Down Agent
+
+Shut down the remediator agent to free resources.
 
-### 7. Report Result
+### 9. Report Result
 
 Report for each ticket:
 - Commit hash
-- Branch merged
-- Agent shut down (or already idle/gone)
-- Remaining team slots available (out of 10)
+- Branch merged and deleted
+- Agent shut down
+- Any skipped flagged tickets (when using `/qa-approve all`)
 
 ## Important Notes
 
@@ -106,5 +119,5 @@ Report for each ticket:
 - Process tickets sequentially to avoid merge conflicts between branches
 - If using `/qa-approve all`, first list which tickets will be approved and their descriptions before proceeding
 - The commit message format `{description} [Ready for Review BH-{id}]` is required by Bugherd's GitHub integration — tag must be in the subject line, case-sensitive
-- **Do NOT delete the team** after approving. The team persists until the user explicitly requests cleanup. Other agents may still be working or idle.
-- After shutting down an agent, check if there are unassigned tickets that could fill the freed slot
+- `/qa-approve all` skips flagged files (`BH-*-flagged.md`) — these need explicit `/qa-approve {id}` with user confirmation
+- Remediator commits in its worktree, team lead merges into main (worktree limitation)

package/skills/qa-remediate/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: qa-remediate
-description: "Fetch Bugherd tickets and fix bugs. Spawns parallel agents for batch mode."
+description: "Triage Bugherd tickets, spawn isolated remediators, and validate fixes sequentially."
 argument-hint: "[ticket-id] [context/hints]"
 user-invocable: true
 ---
 
 # /qa-remediate
 
-Fetch Bugherd tickets, group by similarity, and spawn team members to fix them. Up to 10 agents work in parallel, each on its own branch.
+Fetch Bugherd tickets, triage and group them, then spawn remediators (each in its own worktree) to fix them sequentially. A fresh Validator checks each remediator's work before moving on.
 
 ## Usage
 
@@ -19,76 +19,158 @@ Fetch Bugherd tickets, group by similarity, and spawn team members to fix them.
 
 ## Argument Parsing
 
-- **No arguments** → Batch mode: fetch all tickets from the "development" column
-- **Number only** → Single ticket mode: spawn one agent for that ticket
+- **No arguments** → Batch mode: spawn a Triager to fetch and file tickets, then remediators sequentially
+- **Number only** → Single ticket mode: team lead triages inline, spawns one remediator
 - **Number + text** → Single ticket mode with context hints to guide the fix
 
 ## Team Lead Role
 
 The team lead (you, the main session) is **only** responsible for:
 
-1. **Fetching** tickets from Bugherd
-2. **Grouping** tickets by similarity
-3. **Spawning and assigning** team members
-4. **Relaying** agent reports and status to the user
-5. **Managing slots** — spawn new agents as slots free up (max 10 concurrent)
+1. **Spawning the Triager** to fetch and file tickets
+2. **Receiving the Triager report** (groupings, remediator count, assignments)
+3. **Spawning all Remediators in parallel** (each in its own worktree)
+4. **Collecting worktree/branch reports** and writing them into remediation files
+5. **Sequencing active work** — telling one remediator at a time to start
+6. **Spawning a Validator** when a remediator finishes
+7. **Relaying validation feedback** to the remediator for corrections
+8. **Relaying status** to the user throughout
 
-The team lead does NOT fix tickets itself. All remediation work is done by spawned agents.
+The team lead does NOT fix tickets, does NOT call Bugherd MCP (the Triager does that), and does NOT validate code.
 
 ## Batch Mode Flow
 
-1. Call `list_tasks` MCP tool with `status="development"` to get tickets in the development column. **Only take the first 10 tickets** to avoid overloading context. If more exist, note the count and fetch the next batch after the current tickets are processed.
-2. Create a team: `TeamCreate` with name `qa-remediate` (if not already active)
-3. **Group tickets by similarity:**
-   - Same block/module/component
-   - Similar issue type across different components (e.g., "arrow icon wrong" on multiple blocks)
-   - Related CSS/styling changes
-   - Present the grouping to the user before spawning agents
-4. Create a `TaskCreate` for each ticket
-5. Spawn up to 10 remediator agents. Each agent MUST use:
-   - `isolation: "worktree"` — each agent works in its own isolated worktree
-   - `model: "opus"` — Opus 4.6 for complex reasoning
-   - `subagent_type: "general-purpose"`
-   - `team_name: "qa-remediate"`
-   - `name:` a descriptive name based on the ticket group (e.g., `remediator-hero`, `remediator-arrows`)
-   - Grouped tickets can go to the same agent if closely related
-6. Each remediator agent follows the **Remediator Steps** below
-7. As agents finish and report back, relay their summaries to the user
-8. **Do NOT shut down the team or agents.** Agents wait idle until the user reviews and approves via `/qa-approve`.
+### Step 1 — Spawn Triager
+
+Spawn a triager agent:
+- `model: "sonnet"`
+- `subagent_type: "general-purpose"`
+- `name: "triager"`
+- NO `isolation: "worktree"` — works in the main workspace
+
+Prompt includes: fetch development tickets, group them, create remediation files. See **Triager Steps** below.
+
+### Step 2 — Receive Triager Report
+
+The Triager reports back with:
+- Ticket groupings (which tickets go together)
+- Number of remediators needed
+- Ticket assignments per remediator
+
+Present the groupings to the user. Shut down the Triager.
+
+### Step 3 — Spawn All Remediators in Parallel
+
+Spawn all remediators at once, each with:
+- `isolation: "worktree"` — each agent works in its own isolated worktree
+- `model: "opus"` — Opus for complex reasoning
+- `subagent_type: "general-purpose"`
+- `name:` descriptive name based on ticket group (e.g., `remediator-hero`, `remediator-arrows`)
+
+Initial prompt: **report your worktree path and branch name immediately, then WAIT for further instructions.**
+
+### Step 4 — Collect Worktree Reports
+
+As each remediator reports its worktree path and branch, the team lead fills in the `## Agent` and `## Worktree` sections of each remediation file (in `.takty/qa/`).
+
+### Step 5 — Tell Remediator #1 to Start
+
+Send the first remediator its assigned remediation file paths (absolute paths). It begins work per the **Remediator Steps** below.
+
+### Step 6 — Remediator #1 Finishes
+
+Receive the remediator's summary of what was fixed, flagged, or changed.
+
+### Step 7 — Spawn Validator
+
+Spawn a fresh Validator agent:
+- `model: "sonnet"`
+- `subagent_type: "general-purpose"`
+- NO `isolation: "worktree"` — reads files via absolute paths in the remediator's worktree
+
+See **Validator Steps** below.
+
+### Step 8 — Handle Validation
+
+- If the Validator reports issues: relay them to the remediator for fixes, then re-validate
+- If the Validator reports "all clear": shut down the Validator
+
+### Step 9 — Tell Remediator #2 to Start
+
+Send the next remediator its assigned remediation file paths. Repeat steps 6–8.
+
+### Step 10 — Repeat
+
+Continue until all remediators have completed and been validated.
+
+### Step 11 — Report Summary
+
+Report to the user:
+- Which tickets are ready (fixed and validated)
+- Which tickets were flagged (renamed to `BH-{id}-flagged.md`)
+- Remind user to run `/qa-approve` to merge and tag
 
 ## Single Ticket Mode Flow
 
-Same as batch but for one ticket. Still spawns an agent — the team lead does not fix it directly.
+Skip the Triager — the team lead handles triage inline:
+
+1. Call `get_task` MCP tool with the ticket ID to get full details
+2. Create `.takty/qa/BH-{id}.md` — populate File, Ticket, Description sections
+3. Spawn one remediator (same worktree + opus settings as batch mode)
+4. Collect worktree report, fill in Agent + Worktree sections
+5. Tell the remediator to start
+6. When done, spawn a Validator, handle feedback loop
+7. Report result to user
+
+## Triager Steps
 
-1. Create a team: `TeamCreate` with name `qa-remediate` (if not already active)
-2. Create a `TaskCreate` for the ticket
-3. Spawn one remediator agent (same settings as batch mode)
-4. Agent follows the **Remediator Steps** below
-5. Relay the agent's report to the user when done
+The Triager agent performs these steps:
 
-## Slot Management
+### 1. Fetch Tickets
+- Call `list_tasks` MCP tool with `status="development"` to get tickets in the development column
+- Take up to 15 tickets. If more exist, note the count.
+- Call `get_task` for each ticket to get full details (description, priority, screenshots, comments)
 
-- Maximum 10 concurrent team members
-- When a ticket is approved via `/qa-approve`, that agent is shut down, freeing a slot
-- If more tickets remain in the current batch, the team lead can spawn a new agent for the next ticket
-- When all tickets from the current batch are assigned or completed, fetch the next 10 from Bugherd via `list_tasks`
-- Check `TaskList` and team config to track active vs idle agents
+### 2. Group by Similarity
+- Same block/module/component
+- Similar issue type across different components (e.g., "arrow icon wrong" on multiple blocks)
+- Related CSS/styling changes
+
+### 3. Create Remediation Files
+- Create `.takty/qa/BH-{id}.md` for each ticket using the template below
+- Populate only the **File**, **Ticket**, and **Description** sections
+- Leave Agent, Worktree, Analysis, Changes Made, Test Page, and Status sections empty
+
+### 4. Report to Team Lead
+- List the groupings with ticket IDs and descriptions
+- State how many remediators are needed
+- State which tickets are assigned to which remediator
+
+### 5. Done
+The Triager shuts down after reporting.
 
 ## Remediator Steps
 
-For each ticket:
+### 1. Report Worktree + Branch
+
+**Immediately** report your working directory and branch:
+
+```bash
+pwd
+git branch --show-current
+```
+
+Then **WAIT** for the team lead to tell you to start.
 
-### 1. Gather Context
-- Call `get_task` MCP tool with the ticket ID to get full ticket details and comments
-- If a screenshot URL is present, call `WebFetch` on it to view the screenshot
-- Note the priority, description, and any comments from the team
+### 2. Read Remediation Files
 
-### 2. Find Relevant Code
-- Use `Grep`, `Glob`, and `Read` to search the codebase for relevant code
-- Look at block templates, Blade views, CSS, and JS files related to the reported issue
-- Read the files to understand the current implementation
+When told to start, read the assigned remediation files. All ticket info is in the file — do NOT call Bugherd MCP tools. If a screenshot URL is present in the file, use `WebFetch` to view it.
 
-### 3. Assess Risk
+### 3. Find Relevant Code
+
+Use `Grep`, `Glob`, and `Read` to search the codebase for relevant code. Look at block templates, Blade views, CSS, and JS files related to the reported issue.
+
+### 4. Assess Risk
 
 Categorize the fix as **safe** or **risky**:
 
@@ -101,16 +183,18 @@ Categorize the fix as **safe** or **risky**:
 | Visibility/responsive tweaks | Authentication / permissions |
 | Changes scoped to a single block | **Changes to shared components** (`block-wrapper`, `block-header`, `button`, `eyebrow`) — these affect every block that uses them |
 
-### 4. Implement or Flag
-
 **Safe fixes:** Implement the fix directly in the worktree.
 
 **Risky fixes:** Do NOT implement. Instead:
-- Document the recommended fix in the remediation file
-- Explain why it's flagged in the Analysis section
-- Mark the status as "Flagged for manual review"
+- Document the recommended fix in the Analysis section
+- Explain why it's flagged
+- Rename the remediation file to `BH-{id}-flagged.md` and update the `## File` path to match
+
+### 5. Implement Fix
+
+Make changes in the worktree. Overlapping tickets in a group can be addressed together.
 
-### 5. Create Test Page
+### 6. Create Test Page
 
 Always attempt to create a draft page for QA verification. If `ddev exec` fails, note the command in the remediation file so it can be run later.
 
@@ -125,12 +209,55 @@ CONTENT='<!-- wp:paragraph --><p>Test content for BH-{id}</p><!-- /wp:paragraph
 ddev exec wp post create --post_type=page --post_title="QA: BH-{id}" --post_status=draft --post_content="$CONTENT"
 ```
 
-### 6. Write Remediation File
+### 7. Update Remediation File
+
+Update the remediation file via the **absolute path** from the `## File` section. Fill in:
+- Analysis
+- Changes Made table
+- Test Page URL and verification instructions
+- Status checkboxes (Analyzed, Fixed)
+
+### 8. Report and Wait
+
+After finishing:
+1. Send a summary to the team lead (ticket IDs, what was fixed/flagged, any concerns)
+2. **Do NOT commit.** Changes stay uncommitted in the worktree.
+3. **Wait idle** — do NOT shut down. The team lead will handle validation and approval.
 
-Create `.takty/qa/BH-{id}.md` using this template:
+## Validator Steps
+
+A fresh Validator is spawned for each remediator after it finishes. The Validator:
+
+### 1. Read Code Standards
+Read `.takty/code-standards-checklist.md` from the main workspace.
+
+### 2. Read Remediation Files and Changed Code
+- The team lead provides the remediation file paths
+- Read each remediation file to find the changed files
+- Read each changed file via its absolute path in the remediator's worktree
+
+### 3. Validate Against Standards
+Check for:
+- Tailwind over custom CSS
+- Tailwind scale values (not arbitrary pixel values)
+- `cn()` single-object pattern
+- `@class` directive for conditional classes
+- Use of existing shared components
+
+### 4. Report
+- If violations found: list each (file, line, what to fix)
+- If all clear: report "all clear"
+
+### 5. Done
+The Validator shuts down after reporting.
+
+## Remediation File Template
 
 ```markdown
-# BH-{id}: {title/short description}
+# BH-{id}: {title}
+
+## File
+- **Path:** {absolute path to this file}
 
 ## Ticket
 - **Bugherd ID:** {id}
@@ -138,56 +265,36 @@ Create `.takty/qa/BH-{id}.md` using this template:
 - **Admin link:** {admin_link}
 - **Screenshot:** {screenshot_url}
 
-## Agent
-- **Name:** {agent name, e.g. remediator-hero}
-- **Group:** {ticket group description, e.g. "Hero block styling"}
-
 ## Description
 {from Bugherd}
 
+## Agent
+- **Name:** {filled by team lead}
+- **Group:** {ticket group}
+
+## Worktree
+- **Branch:** {filled by team lead}
+- **Path:** {filled by team lead}
+
 ## Analysis
-{root cause, affected files}
+{filled by remediator}
 
 ## Changes Made
 | File | Change |
 |------|--------|
-| `path/to/file.php` | Fixed XYZ |
+{filled by remediator}
 
 ## Test Page
 - **URL:** {site_url}/qa-bh-{id}/
 - **What to verify:** {instructions}
 
-## Worktree
-- **Branch:** {branch name from worktree}
-- **Path:** {worktree path}
-
 ## Status
-- [x] Analyzed
-- [x] Fixed
+- [ ] Analyzed
+- [ ] Fixed
+- [ ] Validated
 - [ ] Approved
 ```
 
-For risky/flagged tickets, replace "Fixed" with "Flagged for manual review" and explain why in the Analysis section.
-
-### 7. Commit Changes
-
-Create a branch and commit all changes:
-
-```bash
-git checkout -b qa/bh-{id}
-git add -A
-git commit -m "fix: BH-{id} {short description}"
-```
-
-**Do NOT add a `Co-Authored-By` line.** Commits from QA workflows must not include co-author trailers.
-
-### 8. Report and Wait
-
-After committing:
-1. Send a message to the team lead with a summary (ticket ID, what was fixed, branch name, any concerns)
-2. Mark the task as completed
-3. **Wait idle** — do NOT shut down. The user will review the report and either approve or request changes via `/qa-resume`.
-
 ## Code Style Rules
 
 When writing fixes, follow these project conventions:
@@ -203,9 +310,11 @@ For the full checklist, see `.takty/code-standards-checklist.md`.
 ## Important Notes
 
 - The `.takty/qa/` directory is gitignored — remediation files are local working docs only, they do not get committed
-- ALWAYS use `isolation: "worktree"` when spawning remediator agents via the Task tool. Each agent's worktree gets its own branch automatically.
-- Remediator agents MUST commit their changes before reporting back
-- For risky fixes: still create the `.takty/qa/BH-{id}.md` file but mark it as "Flagged for manual review"
+- Remediators: ALWAYS use `isolation: "worktree"`. Do NOT commit. Do NOT call Bugherd MCP tools.
+- Risky fixes: rename remediation file to `BH-{id}-flagged.md` and update the `## File` path
+- Do NOT add `Co-Authored-By` on any QA workflow commits
+- Triager: `model: "sonnet"`, no worktree isolation
+- Validators: `model: "sonnet"`, no worktree isolation, fresh instance per remediator
+- All remediators are spawned at once (each in its own worktree) but only one is actively working at a time
 - When creating test pages with `wp post create`, assign block content to a shell variable first to avoid escaping issues with `!` in `<!-- wp:` markup
-- **Do NOT delete the team** until the user explicitly tells you to. The team persists across `/qa-approve` and `/qa-resume` calls.
-- Each remediation file MUST include the **Agent** section with the team member's name so `/qa-resume` can delegate back to it
+- Each remediation file MUST include the **Agent** section with the agent's name so `/qa-resume` can delegate back to it

package/skills/qa-resume/SKILL.md

@@ -7,7 +7,7 @@ user-invocable: true
 
 # /qa-resume
 
-Resume work on a Bugherd ticket by delegating to the original idle agent, or falling back to a new agent if the original is unavailable.
+Resume work on a Bugherd ticket by delegating to the original idle agent, or falling back to a new agent if the original is unavailable. Spawns a Validator after the remediator finishes.
 
 ## Usage
 
@@ -30,31 +30,35 @@ Error: Ticket number required. Usage: /qa-resume <ticket-number>
 
 ### 2. Read Remediation File
 
-Read `.takty/qa/BH-{id}.md` for context:
+Check for both `.takty/qa/BH-{id}.md` and `.takty/qa/BH-{id}-flagged.md`. Read whichever exists for context:
 - Previous analysis and root cause
 - Changes already made (file paths and descriptions)
 - Branch name and worktree path
 - Current status (what's done, what's pending)
-- **Agent name** (from the "Agent" section)
+- **Agent name** (from the `## Agent` section)
+- **Absolute file path** (from the `## File` section)
 
-If the file doesn't exist, report that no previous work was found for this ticket and suggest using `/qa-remediate {id}` instead.
+If neither file exists, report that no previous work was found for this ticket and suggest using `/qa-remediate {id}` instead.
 
 ### 3. Fetch Latest Ticket State
 
-Call `get_task` MCP tool with the ticket ID to:
+The **team lead** calls `get_task` MCP tool with the ticket ID to:
 - Check for new comments since the last session
 - See if priority or status has changed
 - Get any new screenshots or feedback
 
+Include the latest ticket state in the message to the remediator.
+
 ### 4. Delegate to the Original Agent
 
-If the remediation file has an **Agent** name (e.g., `remediator-hero`):
+If the remediation file has an **Agent** name (e.g., `remediator-hero`) and the agent is still running:
 
-1. Read the team config at `~/.claude/teams/qa-remediate/config.json` to check if the agent is still a team member
-2. If the agent exists, send it a message via `SendMessage`:
-   - Include the user's context/instructions from the `/qa-resume` arguments
-   - Include any new ticket comments or feedback from step 3
-   - The agent already has the worktree and branch context from its previous work
+1. Send it a message with:
+   - The absolute path to the remediation file (from the `## File` section)
+   - The user's context/instructions from the `/qa-resume` arguments
+   - Any new ticket comments or feedback from step 3
+   - Instructions: no commits, no Bugherd MCP, update file via absolute path
+2. The agent already has the worktree and branch context from its previous work
 3. Relay the agent's response back to the user when it reports back
 
 **The team lead does NOT do the fix itself.** Always delegate.
@@ -63,20 +67,36 @@ If the remediation file has an **Agent** name (e.g., `remediator-hero`):
 
 If the original agent is not found (shut down, crashed, etc.):
 
-1. Spawn a new remediator agent with the same settings as `/qa-remediate`:
+1. Spawn a new remediator agent with the same settings:
    - `isolation: "worktree"`
    - `model: "opus"`
    - `subagent_type: "general-purpose"`
-   - `team_name: "qa-remediate"`
    - `name:` reuse the original agent name from the remediation file
 2. Include in the agent prompt:
    - The full remediation file content (previous analysis, changes, branch)
    - The latest ticket state and new comments
    - The user's context/instructions
    - Instructions to check out the existing branch if it still exists, or start fresh if not
-3. The agent follows the same remediation steps: fix, commit, update remediation file, report back, wait idle
+   - **No commits, no Bugherd MCP, update file via absolute path**
+3. The agent follows the same remediator steps: fix, update remediation file, report back, wait idle
+
+### 6. Validate After Resume
+
+After the remediator reports completion, spawn a fresh Validator:
+
+- `model: "sonnet"`
+- `subagent_type: "general-purpose"`
+- NO `isolation: "worktree"` — reads files via absolute paths in the remediator's worktree
+
+The Validator follows the same steps as in `/qa-remediate`:
+1. Read `.takty/code-standards-checklist.md` from the main workspace
+2. Read remediation files and changed files via absolute paths
+3. Validate against code standards (Tailwind, scale values, `cn()`, `@class`, existing components)
+4. Report violations or "all clear"
+
+If issues found: relay to remediator for fixes, then re-validate. If clear: shut down Validator.
 
-### 6. Update Remediation File
+### 7. Update Remediation File
 
 After the agent reports back, ensure the remediation file is updated with:
 - The new agent name (if a fallback agent was spawned)