td-feature-qa

The full skill.

Original instructions from the publisher’s SKILL.md

# td-feature-qa — verify it works, not just exists

Most defects here live at **boundaries**, and a tool that returns success can still cook to errors or a black frame. So: read both sides of every boundary together, and check errors **after the network cooks**, not just the `create_*` return flag. Run incrementally — validate each feature as it lands so an early boundary bug doesn't propagate.

## Gates + suites — always run (offline, no TD needed)

- `npm run typecheck` · `npm run build` · `npm test`
- biome via `./node_modules/.bin/biome check .` (NOT `npm run lint` — RTK proxy gives a false ESLint parse error)
- `npm run validate:recipes` · `npm run test:bridge` (`python3 -m unittest discover -s td/tests`)

## Cross-boundary checks — open both sides

| Boundary | Left (producer) | Right (consumer) | Compare |
|---|---|---|---|
| Tool ↔ CLI | tool's Zod `inputSchema` | command in `src/cli/agent.ts` | every param reachable from CLI; types/defaults align; name maps to the right handler |
| Tool ↔ registry | `register…` export | `layer*/index.ts` + `tools/index.ts` | actually registered + aggregated, not just written |
| Tool ↔ docs | live registry | generated `docs/reference/tools.md` | regenerates and includes the new tool |
| `…Impl` ↔ test | real return / `isError` shape | msw test assertions | test exercises the actual shape, not a cast-away generic |
| Code ↔ TD | operator types created | what this build can create | optype exists + is createable (dir(td) suffix-match over-counts; ~22 names not createable; KB lags ~14 ops) |
| Bridge ↔ client | `td/` endpoint/payload | `touchDesignerClient.ts` + `validators.ts` envelope | response shape matches the Zod validator |

## Live TD validation — when the bridge is up

Policy: **offline gates always; live when available.** Call `get_td_info` first.
- **Bridge up:** build the feature through the agent CLI against the live bridge, capture `get_preview`, and check `get_td_node_errors` **after it cooks**.
- **Bridge offline:** run offline gates, mark live validation **UNVERIFIED — pending bridge** in the report. Do not fail the pipeline for a missing TD.

Before any live mutation, record the exact disposable PID/project/port and confirm the artist PID owns none of those resources. Do not probe the app binary with guessed flags and do not use Accessibility/menu/Textport automation when multiple TD processes are open. After Python bridge edits, restart only the disposable runtime, verify the loaded module paths and confirm arbitrary exec is disabled before calling product routes.

Live gotchas to rule out before declaring a bug:
- Silent failures: a Level TOP has no `gain` (it's `brightness1`); no cross-container wires (Select TOP).
- Paused timeline: time-dependent chains (motion / frame-diff / feedback / beat) read **0** when `op('/').time.play` is false — check it before concluding a reactive chain is dead.
- Staleness: a connected `mcp__tdmcp__*` runs the **old build** until restarted; editing `td/` doesn't reload the running bridge (`reload_bridge` / restart) — suspect stale modules before "fixing" correct code.
- GLSL: needs `out vec4 fragColor` + a self-supplied time uniform.
- Device sources can hang TD on a macOS permission modal — validate the synthetic/file source first.

## Output

A report at `_workspace/04_qa_<feature|batch>.md` with three explicit buckets — **PASS**, **FAIL** (`file:line` + concrete fix + owning agent), **UNVERIFIED** (what wasn't checked + why, e.g. bridge offline). Never silently skip a check; list it as UNVERIFIED.

## Fix loop

- Send each defect immediately to its owner (`td-builder` for handler/schema/test, `td-integrator` for wiring/CLI/docs); boundary bugs go to **both**. Re-validate after each fix.
- Cap at ~2–3 rounds per feature; if still failing, report a blocker with full findings instead of looping.
- If a gate fails due to a concurrent agent's unrelated in-flight WIP, say so and validate your slice in isolation (`vitest run <yourfile>`).