Phase skill: TDD implementation — write tests first, then make them pass
Implement the change using TDD: write failing tests, then write code to make them pass.
Read the plan from state outputs.
state.outputs.plan exists (written by harness-plan). Use it.harness-plan is skipped, so state.outputs.plan is missing. Fall back to state.outputs.pickup (ticket title, description, requirements) and infer the work directly. Quick profile is meant for trivial changes (typos, small fixes) where a formal plan would be overkill — keep the implementation surface tight and skip TDD ceremony if the change is a one-liner.If schema changes needed:
packages/db/src/schema.tspackages/types/src/entities.ts and/or api.tspnpm --filter @agentfleet/db drizzle-kit generate to create migrationTDD cycle — for each change in the plan:
__tests__/ directories:
apps/api/src/**/__tests__/apps/web/**/__tests__/ or apps/web/components/__tests__/packages/types/src/__tests__/pnpm --filter <package> vitest run <test-file>Follow existing patterns:
apps/api/src/routes/, register in apps/api/src/index.tspackages/types/, imported by both api and webapps/web/components/, pages in apps/web/app/(dashboard)/db from @agentfleet/dbRecord to conversation file:
Insert before the ## Harness Issues marker in .harness/conversations/<task-id>.md (use Edit tool with ## Harness Issues as the anchor — do NOT literally append, that would land below the issues section):
## Implement
**Tests written:** <count>
**Files changed:** <list>
**Key decisions:** <any deviations from plan>
If you hit friction while implementing (failed test approach, unclear pattern, retried more than once, plan revision), append an entry to the literal end of the file — it will land inside the ## Harness Issues section since that section is last.