KOKO\Mimi
51 lines
3.2 KiB
Markdown
51 lines
3.2 KiB
Markdown
---
|
|
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/<feature-id>/implementation-plan.md`
|
|
- `docs/<feature-id>/implementation-report.md`
|
|
- `docs/<feature-id>/build-test.md`
|
|
- `docs/<feature-id>/reference-comparison.md`
|
|
- `docs/<feature-id>/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.
|