--- name: fem-implementation-tdd description: Use when planning, implementing, correcting, building, testing, or reference-comparing structural FEM solver code under approved upstream contracts. --- # FEM Implementation TDD Implement only approved structural-solver behavior and produce reproducible RED/GREEN/verification evidence. ## Inputs - Project instructions, architecture decisions, and Harness configuration - Approved requirements, formulation, numerical review, reference model, and I/O contract - Implementation plan and Executor-selected current step when Harness is active - Existing implementation and validation reports when correcting a failure ## Workflow 1. For planning, map every requirement to bounded tasks, tests, commands, dependencies, and owned files. Leave critical upstream choices unresolved and return them to their owner. 2. For execution, change only the selected step. Write one focused test, run it, and observe the expected failure before production code. 3. Implement the minimum change; run the focused test, configured build/test suite, and declared comparison gates. 4. Classify failures as `configure`, `compile`, `link`, `test`, `reference-comparison`, `harness`, `environment`, or `upstream-contract`. Fix implementation-owned failures; route the rest. 5. Update only artifacts and status fields owned by the current role. The Executor owns step selection, transport/session retry, timestamps, commits, and phase advancement. The Coordinator owns normalized `retry_key` state, correction attempts, and the workflow retry budget. Read [toolchain and verification](references/toolchain-and-verification.md) before choosing commands. Use [evidence and handoff](../fem-requirements-baseline/references/evidence-and-handoff.md) for reports and [workflow and decision authority](../fem-requirements-baseline/references/workflow-and-decisions.md) for escalation. ## Output Follow [Feature document management](../../../docs/FEATURE_DOCUMENTATION.md): read the Coordinator's feature context, keep main reports concise, and link necessary owned details in the same feature folder. Produce the applicable canonical artifacts: - `docs//implementation-plan.md` - `docs//implementation-report.md` - `docs//build-test.md` - `docs//reference-comparison.md` - `docs//corrections.md` Each task and test traces to requirement IDs and owned files. Create only artifacts applicable to the dispatched role and completed gate. ## Evidence Record the RED failure reason, GREEN result, exact commands, exit codes, duration, relevant output, environment/config selection, changed artifacts and hashes, comparison prechecks and tolerance source, failure classification, assumptions, and residual risk. ## Boundary Never write production behavior before observing the corresponding test fail. Hooks are guardrails, not RED evidence. Do not change requirements, formulations, I/O contracts, tolerances, or reference artifacts to make tests pass. Do not run licensed external solvers, publish, deploy, or perform destructive version-control operations without explicit authorization. If the same retry key fails after the coordinator's bounded correction cycle, return the failure; do not loop or broaden scope.