modify harness framework

.codex/agents/build-test-executor-agent.toml

@@ -10,7 +10,7 @@ Mission:
 - Run build and test validation only after Implementation Agent work.
 - Execute independent C++/MSVC/CMake/CTest validation and summarize failures for handoff.
 - Record command, exit code, duration, stdout/stderr summary, failed test names, and failure classification.
-- Keep the output aligned with AGENTS.md, docs/SOLVER_AGENT_DESIGN.md, scripts/validate_workspace.py, and the implementation plan/report.
+- Keep the output aligned with AGENTS.md, docs/HARNESS_WORKFLOW.md, docs/SOLVER_AGENT_DESIGN.md, `.harness/config.json` when present, and the implementation plan/report.
 
 Skill references:
 - Use $fesa-cpp-msvc-tdd when running C++/MSVC/CMake/CTest validation, recording validation evidence, classifying build/test failures, or preparing build/test handoffs.
@@ -32,23 +32,26 @@ Input priorities:
 2. Implementation Agent report.
 3. docs/implementation-plans/<feature-id>-implementation-plan.md.
 4. AGENTS.md and docs/SOLVER_AGENT_DESIGN.md.
-5. scripts/validate_workspace.py.
-6. CMakePresets.json, CMakeLists.txt, CMake files, and CTest metadata when present.
+5. `.harness/config.json` when present.
+6. CMakePresets.json, CMakeLists.txt, CMake files, Visual Studio solution/project files, and CTest metadata when present.
 7. Related docs/reference-models/<feature-id>-reference-models.md when present.
 8. Stored reference artifacts when present, read-only.
 
 Execution contract:
-- Default validation is python scripts/validate_workspace.py.
-- If the implementation plan requires harness self-test, run python -m unittest discover -s scripts -p "test_*.py" first.
-- If the implementation plan lists feature-specific CTest commands, run those before full workspace validation.
-- Run full workspace validation with python scripts/validate_workspace.py last.
-- scripts/validate_workspace.py resolves HARNESS_VALIDATION_COMMANDS, CMakePresets.json msvc-debug, or CMake/MSVC x64 Debug commands.
-- The default CMake/MSVC x64 Debug commands are:
-  1. cmake -S . -B build/msvc-debug -G "Visual Studio 17 2022" -A x64
-  2. cmake --build build/msvc-debug --config Debug
-  3. ctest --test-dir build/msvc-debug --output-on-failure -C Debug
+- Resolve the validation path from `.harness/config.json` first, then Harness project auto detection.
+- If Harness Python, Hook, or agent-config behavior changed, run `uv run --with pytest python -m pytest -v -rs` first.
+- Configure and build before running feature-specific and full tests.
+- If the implementation plan lists feature-specific CTest commands, run them after build and before the full test run.
+- For a non-preset CMake project, run:
+  1. cmake -S . -B .harness/build -A x64
+  2. cmake --build .harness/build --config Debug
+  3. ctest --test-dir .harness/build -C Debug -R <feature-or-label> --output-on-failure when specified
+  4. ctest --test-dir .harness/build -C Debug --show-only=json-v1
+  5. ctest --test-dir .harness/build -C Debug --output-on-failure
+- If `.harness/config.json` selects CMake presets, use its configure/build/test presets and binary directory.
+- If it selects direct MSBuild, use its solution, configuration, platform, and required `msbuild.testCommand`.
 - Preserve command order, exit code, duration, and stdout/stderr tail for every executed command.
-- For no-CMake workspaces, record the scripts/validate_workspace.py informational success path instead of treating it as a failure.
+- Record a no-project pass only when no C/C++ files and no build metadata exist. C/C++ files without build metadata are an error.
 - Stop after the first decisive failure unless the implementation plan explicitly asks for additional diagnostic commands.
 
 Failure classification:
@@ -57,13 +60,13 @@ Failure classification:
 - link: link step failed.
 - test: CTest or unit/integration tests failed.
 - reference-comparison: reference comparison test ran and reported comparison failure.
-- harness: Python harness self-test or validation script failed.
+- harness: Python Harness test, PreToolUse/Stop Hook, config loading, discovery, or adapter validation failed.
 - environment: generator, compiler, Python, path, permission, or local machine dependency is missing.
 - upstream-contract: implementation plan, requirements, formulation, I/O definition, reference artifacts, or tolerance policy is inconsistent or incomplete.
 
 Required Build/Test Report sections:
 1. Metadata: feature_id, source implementation report, status, owner_agent, date.
-2. Execution Environment: OS, generator, platform, config, build dir, and active override env vars.
+2. Execution Environment: OS, generator, platform, config, build dir, Harness config presence, and project selection path.
 3. Command Log Summary: command, exit code, duration, stdout/stderr tail.
 4. Validation Results: harness self-test, configure, build, CTest, and feature-specific tests.
 5. Failure Classification: configure | compile | link | test | reference-comparison | harness | environment | upstream-contract.

.codex/agents/correction-agent.toml

@@ -48,8 +48,9 @@ Execution contract:
 - MINIMAL FIX: modify only implementation-owned source, header, test, or CMake files needed to fix the classified failure.
 - MINIMAL FIX: keep changes surgical and traceable to the failure report or implementation plan acceptance criterion.
 - VERIFY: rerun the targeted command that reproduced the failure first.
-- VERIFY: run python scripts/validate_workspace.py after the targeted command.
-- VERIFY: run python -m unittest discover -s scripts -p "test_*.py" when harness, hook, or agent config behavior is involved.
+- VERIFY: run the full MSVC build/test commands resolved from `.harness/config.json` or Harness auto detection after the targeted command.
+- VERIFY: run `uv run --with pytest python -m pytest -v -rs` when Harness Python, Hook, or agent config behavior is involved.
+- VERIFY: allow Stop to rerun whole-project MSVC build/test before the correction Step ends.
 - If the same classification repeats after two focused correction attempts, stop and hand off to Coordinator Agent or the relevant upstream agent.
 - If a fix requires changing requirements, formulations, I/O contracts, reference artifacts, tolerance policies, or reference provenance, stop with needs-upstream-decision.
 - If the failure is environment-owned, do not work around it with code changes; classify it as needs-environment-fix.
@@ -61,7 +62,7 @@ Failure classification:
 - link: linker, symbol resolution, library registration, or target dependency failed.
 - test: CTest, unit, integration, parser/I/O, or ordinary regression test failed.
 - reference-comparison: deterministic reference comparison test failed against stored artifacts.
-- harness: Python harness self-test, TDD guard, hook, or validation script failed.
+- harness: Python Harness test, PreToolUse/Stop Hook, config loading, discovery, or adapter validation failed.
 - environment: MSVC, CMake, Python, path, permission, generator, or local dependency issue.
 - upstream-contract: requirements, formulation, I/O, reference artifact, tolerance, or implementation plan is incomplete or inconsistent.
 
@@ -70,7 +71,7 @@ Required Correction Report sections:
 2. Failure Triage: classification, first failed command, failed target or test, and evidence tail.
 3. Root Cause Summary: implementation defect, test defect, CMake registration issue, environment issue, or upstream-contract issue.
 4. Correction Scope: changed source, header, test, and CMake files plus excluded upstream contract files.
-5. Verification Evidence: targeted command, python scripts/validate_workspace.py, and Python harness self-test when relevant.
+5. Verification Evidence: targeted command, config-resolved full MSVC build/test, Stop result, and Harness Python pytest when relevant.
 6. Traceability: requirement id, task id, test id, failing command, corrected file, and acceptance criterion.
 7. Handoff Recommendation: Implementation Agent, Build/Test Executor Agent, Reference Verification Agent, Physics Evaluation Agent, upstream agent, or Coordinator Agent.
 8. Stop Condition: repeated failure, upstream ambiguity, reference artifact gap, or environment blocker.

.codex/agents/implementation-agent.toml

@@ -43,7 +43,9 @@ Execution contract:
 - RED: write the planned C++ unit, integration, parser/I/O, or reference-comparison test first.
 - RED: run the targeted test and verify failure before production implementation.
 - GREEN: implement the minimum code needed for the planned task and acceptance criterion.
-- VERIFY: run the targeted CTest command, then the workspace validation commands.
+- VERIFY: run the targeted CTest command, then the full MSVC build/test commands resolved from `.harness/config.json` or the Harness defaults.
+- VERIFY: record RED and GREEN evidence explicitly; PreToolUse only checks that a related test file exists.
+- VERIFY: allow Stop to rerun whole-project MSVC build/test before the Step ends.
 - If a C++ production file changes, a related C++ test file must be present in the same patch or already exist.
 - CMake/CTest changes must stay compatible with MSVC x64 Debug validation.
 - Abaqus reference CSV files are read-only verification inputs.
@@ -69,15 +71,19 @@ Required Implementation Report sections:
 2. Implemented Scope: completed task ids, skipped task ids, and reason.
 3. Test Evidence: tests written first, observed RED failure, GREEN pass, and commands.
 4. Code Changes: source, header, test, and CMake/CTest change summary.
-5. Validation Evidence: ctest -C Debug, python scripts/validate_workspace.py, and python -m unittest discover -s scripts -p "test_*.py" when relevant.
+5. Validation Evidence: targeted CTest, config-resolved full MSVC build/test, Stop result, and `uv run --with pytest python -m pytest -v -rs` when Harness Python behavior is relevant.
 6. Traceability: requirement id, task id, test id, and acceptance criterion.
 7. Blockers: upstream document mismatch, reference artifact gaps, formulation ambiguity, I/O ambiguity, or repeated failure.
 8. Downstream Handoff: Build/Test Executor Agent, Correction Agent, and Reference Verification Agent.
 
 Validation commands:
-- python -m unittest discover -s scripts -p "test_*.py"
-- python scripts/validate_workspace.py
-- ctest -C Debug -R <feature-or-label>
+- 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.
+- Run `uv run --with pytest python -m pytest -v -rs` when Harness Python, Hook, or agent-config behavior changes.
 
 Status rules:
 - in-progress: implementation is underway.

.codex/agents/implementation-planning-agent.toml

@@ -55,11 +55,11 @@ Required Implementation Plan sections:
 3. Implementation Scope: included behavior, excluded behavior, and non-goals.
 4. Work Breakdown: small ordered implementation tasks with task ids and dependencies.
 5. TDD Test Plan: unit, integration, parser/I/O, and reference-comparison tests ordered by RED/GREEN cycle.
-6. CMake/CTest Plan: target candidates, add_test needs, labels, and ctest -C Debug execution expectations.
+6. CMake/CTest Plan: target candidates, add_test needs, labels, and `.harness/config.json` or default `.harness/build` execution expectations.
 7. Candidate Files and Ownership: candidate source/header/test/CMake files and responsibility boundary; never final API.
 8. Data Flow Contract: Abaqus .inp input, internal model, solver results.h5, Abaqus reference CSV files under reference/<model-id>/, and FESA HDF5-to-reference-CSV comparison flow.
 9. Acceptance Traceability Matrix: requirement id, task id, test id, reference model id, and acceptance criterion.
-10. Validation Commands: python -m unittest discover -s scripts -p \"test_*.py\", python scripts/validate_workspace.py, and feature-specific CTest commands.
+10. Validation Commands: config-resolved full MSVC build/test commands, feature-specific CTest commands, and `uv run --with pytest python -m pytest -v -rs` when Harness Python behavior is in scope.
 11. Risks and Downstream Handoff: Implementation Agent, Build/Test Executor Agent, Correction Agent, and Reference Verification Agent.
 12. Open Issues: requirements, formulation, I/O, reference artifacts, tolerance, or architecture gaps that prevent ready-for-implementation.
 

.codex/agents/release-agent.toml

@@ -62,7 +62,7 @@ Required Release Report sections:
 2. Release Scope: included functionality, excluded functionality, supported analysis type, elements, materials, I/O subset, and artifact scope.
 3. Gate Evidence Inventory: requirements, formulation, numerical review, I/O definition, reference model, implementation, build/test, reference verification, and physics evaluation status.
 4. Acceptance Traceability: requirement id, acceptance criterion, test id, reference model id, verification report, and release disposition.
-5. Validation Evidence: python scripts/validate_workspace.py, CMake/MSVC/CTest evidence, reference verification status, and physics evaluation status.
+5. Validation Evidence: Build/Test report's config-resolved CMake/MSVC/CTest commands, Harness Python pytest when applicable, reference verification status, and physics evaluation status.
 6. Known Limitations: unsupported Abaqus keywords, element/material/analysis constraints, deferred issues, accepted risks, and open items.
 7. Release Notes Draft: user-facing feature summary, verification scope, main limitations, artifact paths, and usage notes.
 8. Release Verdict: ready-for-release | needs-correction | needs-reference-verification | needs-physics-evaluation | needs-documentation | needs-upstream-decision | blocked.