FESADev/.codex/skills/fesa-cpp-msvc-tdd/SKILL.md

name, description

name	description
fesa-cpp-msvc-tdd	Use when planning, implementing, validating, or correcting FESA solver C++17 MSVC CMake CTest work with TDD, build/test failure triage, or implementation-plan handoffs.

FESA C++ MSVC TDD

Use this skill to keep FESA C++ implementation work test-first, MSVC-compatible, and bounded by approved upstream contracts.

Inputs

Read these first:

• AGENTS.md
• docs/SOLVER_AGENT_DESIGN.md
• docs/implementation-plans/README.md
• docs/build-test-reports/README.md
• docs/corrections/README.md
• docs/implementation-plans/<feature-id>-implementation-plan.md
• Related requirements, formulation, numerical review, I/O definition, and reference model documents

Workflow

1. For planning, convert upstream documents into small ordered tasks and test ids.
2. For implementation, follow RED -> GREEN -> VERIFY.
3. RED: write the planned unit, integration, parser/I/O, or reference-comparison test first.
4. RED: run the targeted test and verify the expected failure before production code.
5. GREEN: implement the minimum C++17/MSVC-compatible code needed for the task.
6. VERIFY: run the targeted command, then the full MSVC build/test commands resolved from .harness/config.json or the Harness defaults.
7. For C++ production changes, require a related C++ test file in the same patch or already present.
8. Treat PreToolUse as a test-file-existence guardrail, not proof that RED was observed. Record the RED and GREEN commands and results in the implementation report.
9. Let Stop perform the final whole-project MSVC build/test before the Step ends.
10. For failure triage, classify as configure | compile | link | test | reference-comparison | harness | environment | upstream-contract.
11. Fix implementation-owned failures only and keep changes traceable to the implementation plan.

Output Contract

Produce one of these, depending on role:

• docs/implementation-plans/<feature-id>-implementation-plan.md
• Implementation report with RED/GREEN/VERIFY evidence
• docs/build-test-reports/<feature-id>-build-test.md
• docs/corrections/<feature-id>-correction.md

Required validation commands:

cmake -S . -B .harness/build -A x64
cmake --build .harness/build --config Debug
ctest --test-dir .harness/build -C Debug -R <feature-or-label> --output-on-failure
ctest --test-dir .harness/build -C Debug --show-only=json-v1
ctest --test-dir .harness/build -C Debug --output-on-failure

Use configured CMake presets or direct MSBuild commands instead when .harness/config.json selects them. For Harness Python, Hook, or agent-config changes, also run:

uv run --with pytest python -m pytest -v -rs

Boundaries

• Do not change requirements.
• Do not change formulations.
• Do not change I/O contracts.
• Do not change numerical review reports.
• Do not change reference artifacts.
• Do not change tolerance policies.
• Do not run Abaqus, Nastran, or any reference solver.
• Do not generate or modify Abaqus reference CSV files.
• Do not approve release readiness.

Quality Gate

• Every must requirement maps to at least one task and one test.
• Each test has a clear RED condition, GREEN condition, linked task, and command.
• CMake/CTest plans remain compatible with MSVC x64 Debug validation.
• Stop validation is green for the whole discovered C/C++ project; a no-project pass is valid only when no C/C++ files and no build metadata exist.
• Build/test reports record command, exit code, duration, stdout/stderr tail, and failure classification.
• Correction attempts stop when repeated failure indicates upstream contract ambiguity.

Handoff

Send passing build/test evidence to Reference Verification Agent. Send implementation-owned failures to Correction Agent. Send upstream-contract failures to the owning upstream agent through Coordinator Agent.