KOKO\Mimi
104 lines
5.0 KiB
Markdown
104 lines
5.0 KiB
Markdown
---
|
|
name: fesa-cpp-msvc-tdd
|
|
description: 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/HARNESS.md`
|
|
- `docs/HARNESS_WORKFLOW.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
|
|
|
|
For Harness implementation, also read `.agents/skills/harness/SKILL.md`,
|
|
`.codex/hooks.json`, the materialized phase indexes, and the Executor-selected current
|
|
`stepN.md`.
|
|
|
|
## Workflow
|
|
|
|
1. For planning, use the project-local `harness` skill to convert upstream documents into a
|
|
user-approved multi-Step draft. Materialize only planning files after approval; planning never
|
|
selects or runs a Step. Run `scripts/execute.py` only after a separate explicit user request.
|
|
2. For implementation, require the approved plan, materialized phase files, and the
|
|
Executor-selected current `stepN.md`. Do not start another pending Step.
|
|
3. Execute the current Step as `RED -> observed failure -> minimal GREEN -> focused/full VERIFY`.
|
|
Update only its Codex-owned `status` plus `summary`, `error_message`, or `blocked_reason`.
|
|
The Executor owns branch, pending-Step selection, retry, timestamps, commits, advancement,
|
|
and top-level phase status.
|
|
4. Hooks are automatic through `.codex/hooks.json`: PreToolUse intercepts before edits and Stop
|
|
performs whole-project validation. Do not manually run their entry points as substitutes.
|
|
5. RED: write the planned unit, integration, parser/I/O, or reference-comparison test first.
|
|
6. RED: run the targeted test and verify the expected failure before production code.
|
|
7. GREEN: implement the minimum C++17/MSVC-compatible code needed for the task.
|
|
8. VERIFY: run the targeted command, then the full MSVC build/test commands resolved from `.harness/config.json` or the Harness defaults.
|
|
9. For C++ production changes, require a related C++ test file in the same patch or already present.
|
|
10. 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.
|
|
11. Let Stop perform the final whole-project MSVC build/test before the Step ends.
|
|
12. For failure triage, classify as `configure | compile | link | test | reference-comparison | harness | environment | upstream-contract`.
|
|
13. 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:
|
|
|
|
```powershell
|
|
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:
|
|
|
|
```powershell
|
|
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.
|
|
- During planning, do not block on canonical reference naming, README, metadata, provenance, or
|
|
an unrequested reference portfolio. Require only feature-declared input/CSV files, matching, and tolerance.
|
|
|
|
## 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.
|