refactor: merge implementation verification workflow

This commit is contained in:
KOKO\Mimi
2026-08-15 02:32:26 +09:00
parent 0081f0bc12
commit 5a833d831a
7 changed files with 88 additions and 315 deletions
+35 -15
View File
@@ -1,11 +1,11 @@
---
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.
description: Use when planning, implementing, build/testing, correcting, or reference-comparing FESA solver C++17 MSVC CMake CTest work with TDD.
---
# FESA C++ MSVC TDD
Use this skill to keep FESA C++ implementation work test-first, MSVC-compatible, and bounded by approved upstream contracts.
Use this skill to keep FESA C++ implementation, build/test reporting, correction, and reference comparison test-first, MSVC-compatible, and bounded by approved upstream contracts.
## Inputs
@@ -13,13 +13,14 @@ 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`
- `docs/<feature-id>/implementation-plan.md`
- `docs/<feature-id>/implementation-report.md` when present
- `docs/<feature-id>/build-test.md` when present
- `docs/<feature-id>/reference-comparison.md` when present
- Related requirements, formulation, numerical review, I/O definition, and reference model documents
- Generated FESA `results.h5` and the exact feature-declared reference `.inp` and Abaqus CSV paths
For Harness implementation, also read `.agents/skills/harness/SKILL.md`,
`.codex/hooks.json`, the materialized phase indexes, and the Executor-selected current
@@ -41,21 +42,35 @@ For Harness implementation, also read `.agents/skills/harness/SKILL.md`,
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.
8. VERIFY: resolve commands from `.harness/config.json` first, then Harness defaults; run the targeted command, then the full MSVC x64 Debug build/test commands in order.
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.
12. Record every build/test command, exit code, duration, stdout/stderr tail, failed test names, environment, and project-selection path. Stop after the first decisive failure unless the implementation plan requires another diagnostic command.
13. For failure triage, classify as `configure | compile | link | test | reference-comparison | harness | environment | upstream-contract`.
14. Run reference verification in this literal order: `ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT`.
15. ARTIFACT CHECK requires exact declared input/CSV paths, generated `results.h5`, the `io.md` HDF5 projection, source identity/component matching, row uniqueness/finite checks, and approved tolerance.
16. COMPARE matches HDF5 and CSV rows by declared source identity and component, never by row order. Reject missing, extra, duplicate, and nonfinite required rows before tolerance; preserve warning-only behavior.
17. Fix implementation-owned failures only and keep changes traceable to the implementation plan.
## Output Contract
Produce one of these, depending on role:
Produce the applicable feature-bundled evidence:
- `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`
- `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`
`implementation-report.md` records RED/GREEN/VERIFY evidence. `build-test.md` uses
`owner_agent: implementation-agent` and records the historical build/test sections: metadata,
execution environment, command-log summary, validation results, failure classification, failed
test inventory, handoff recommendation, no-change assertion, and open issues.
`reference-comparison.md` records the exact input/CSV artifact inventory, `results.h5`, HDF5
projection, source-ID/component matching, row prechecks, approved tolerance, per-quantity
results, classification, handoff, no-change assertion, and open issues.
Required validation commands:
@@ -83,6 +98,7 @@ uv run --with pytest python -m pytest -v -rs
- Do not change numerical review reports.
- Do not change reference artifacts.
- Do not change tolerance policies.
- Do not change declared reference inputs.
- Do not run Abaqus, Nastran, or any reference solver.
- Do not generate or modify Abaqus reference CSV files.
- Do not approve release readiness.
@@ -96,8 +112,12 @@ uv run --with pytest python -m pytest -v -rs
- 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.
- Reference comparison rejects missing, extra, duplicate, and nonfinite required rows before tolerance.
- Warning-only quantities never change the blocking pass/fail result.
- 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.
Send `pass-for-physics-evaluation` evidence to Physics Evaluation Agent through Coordinator Agent.
Send implementation-owned failures to Correction Agent through Coordinator Agent. Send upstream-contract
failures to the owning upstream agent through Coordinator Agent.
@@ -1,4 +1,4 @@
interface:
display_name: "FESA C++ MSVC TDD"
short_description: "Plan and execute C++ TDD work"
default_prompt: "Use $fesa-cpp-msvc-tdd for FESA C++17 MSVC TDD implementation work."
display_name: "FESA C++ TDD and Verification"
short_description: "Implement and verify FESA C++ work"
default_prompt: "Use $fesa-cpp-msvc-tdd to plan, implement, build, test, and reference-verify FESA C++ work."
@@ -1,77 +0,0 @@
---
name: fesa-reference-comparison
description: Use when comparing FESA results.h5 quantities against feature-declared Abaqus CSV values or diagnosing reference tolerance, identity, row-set, or nonfinite-result failures.
---
# FESA Reference Comparison
Compare generated FESA HDF5 values with only the Abaqus CSV quantities declared by the feature.
The comparison tests observable values; it does not test Abaqus implementation equivalence.
## Inputs
Read these first:
- `AGENTS.md`
- `docs/SOLVER_AGENT_DESIGN.md`
- `docs/reference-verifications/README.md`
- Build/Test report with `pass-for-reference-verification`
- `docs/reference-models/<feature-id>-reference-models.md`
- `docs/io-definitions/<feature-id>-io.md`
- Generated FESA `results.h5`
- Declared reference `.inp` and required Abaqus CSV files
## Workflow
1. Follow `ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT`.
2. ARTIFACT CHECK: verify the declared input, `results.h5`, every required CSV, HDF5
projection, source-ID/component mapping, row prechecks, blocking/warning behavior, and tolerance.
3. Reject a missing input or required CSV as `needs-reference-artifacts`.
4. Reject a missing HDF5 result or comparison command as `needs-solver-results`.
5. Reject missing, extra, duplicate, or nonfinite required rows before tolerance evaluation.
6. COMPARE: normalize HDF5 values and match CSV values by declared source identity and component.
Never match by row order alone.
7. Apply the upstream tolerance exactly. Do not clamp values, drop rows, loosen tolerance, or
modify either artifact to obtain a pass.
8. Report per-row decisions, max absolute error, max relative error, RMS error, norm error when
required, worst source ID/component, and pass/fail or warning per quantity.
9. CLASSIFY failures as missing-reference-artifact, missing-solver-output, schema-mismatch,
id-mismatch, tolerance-failure, nonfinite-result, upstream-contract, or environment.
Do not require canonical names, README, metadata, Abaqus version/provenance, duplicated CSV
units/coordinates/step-frame fields, or a reference CSV schema version unless the feature
requirements explicitly make one of them part of comparison acceptance.
## Output Contract
Produce or revise `docs/reference-verifications/<feature-id>-reference-verification.md` with:
- Metadata
- Artifact Inventory
- Comparison Contract
- Quantity Results
- Failure Classification
- Handoff Recommendation
- No-Change Assertion
- Open Issues
## Boundaries
- Do not edit source, tests, CMake, upstream contracts, reference artifacts, or tolerances.
- Do not run Abaqus, Nastran, or another reference solver.
- Do not generate or modify reference CSV files.
- Do not approve physics validation or release readiness.
## Quality Gate
- Every declared required row has a deterministic source-ID/component match.
- Missing/extra/duplicate/nonfinite required rows remain visible and fail before tolerance.
- Warning-only quantities never change the blocking pass/fail verdict.
- `pass-for-physics-evaluation` means required reference tolerance success only.
- FESA `results.h5` remains authoritative solver output; Abaqus CSV remains external reference data.
## Handoff
Send passing reports to Physics Evaluation Agent. Send implementation-owned mismatches to
Correction Agent, missing declared files to Reference Model Agent, and HDF5 projection or
identity-contract conflicts to I/O Definition Agent.
@@ -1,4 +0,0 @@
interface:
display_name: "FESA Reference Comparison"
short_description: "Compare HDF5 with Abaqus CSV"
default_prompt: "Use $fesa-reference-comparison to compare FESA solver results.h5 against Abaqus reference CSV files."