modify documents

.codex/skills/fem-implementation-tdd/SKILL.md

@@ -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.

.codex/skills/fem-implementation-tdd/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "FEM Implementation TDD"
+  short_description: "Implement and verify structural FEM code"
+  default_prompt: "Use $fem-implementation-tdd to plan or implement an approved structural FEM solver change test-first."

.codex/skills/fem-implementation-tdd/references/toolchain-and-verification.md

@@ -0,0 +1,34 @@
+# Toolchain and Verification
+
+## Command authority
+
+Choose commands in this order:
+
+1. Executor-selected step and approved implementation plan
+2. `.harness/config.json`
+3. Project presets, build metadata, and repository instructions
+4. Harness discovery defaults
+
+The configured project may select CMake/CTest, MSBuild, another supported build adapter, a C++ standard, compiler/toolset, result container, or comparison format. Report the actual selection; do not substitute a familiar backend. Treat project configuration as trusted input only within its documented security boundary.
+
+## Test-first execution
+
+For each behavior:
+
+1. Add or identify a test that will fail for the missing behavior.
+2. Run it and confirm the failure is expected, not a setup error.
+3. Make the smallest production change.
+4. Re-run the focused test, then configured focused and full validation.
+5. Preserve clean warning/error output required by the project.
+
+A test that passed before the change is not RED evidence. A pre-edit hook confirms only that a test file exists. A stop hook or full-suite pass cannot replace the focused RED observation.
+
+## Comparison gate
+
+Use only contract-declared cases, quantities, identities, components, locations, units, and tolerances. Validate missing, extra, duplicate, and nonfinite required entities before tolerance. Match by declared identity, never incidental file or row order. Warning-only quantities do not change the blocking verdict.
+
+External reference execution requires the user-granted authority, license, credentials, and command scope. Existing approved artifacts may be consumed read-only.
+
+## Environment outcomes
+
+Report `blocked-environment` only after safe configured discovery and diagnostics establish that the required toolchain, dependency, license, credential, or artifact is unavailable. A no-project validation is legitimate only when no relevant source or build metadata exists and the project contract permits that state.