modify documents

2026-09-05 15:14:21 +09:00
parent 31dac85192
commit 97e4d7a971
79 changed files with 4570 additions and 2787 deletions
@@ -0,0 +1,50 @@
+---
+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.