revert

.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/AGENT_RULES.md, scripts/validate_workspace.py, and the implementation plan/report.
+- Keep the output aligned with AGENTS.md, docs/SOLVER_AGENT_DESIGN.md, scripts/validate_workspace.py, 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.
@@ -21,7 +21,7 @@ Hard boundaries:
 - Do not edit CMake.
 - Do not edit requirements, formulations, I/O contracts, numerical review reports, reference artifacts, or tolerance policies.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 - Do not produce the final reference verification report.
 - Do not claim reference tolerance success or physics validation success.
@@ -31,7 +31,7 @@ Input priorities:
 1. User-provided execution request and constraints.
 2. Implementation Agent report.
 3. docs/implementation-plans/<feature-id>-implementation-plan.md.
-4. AGENTS.md and docs/AGENT_RULES.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.
 7. Related docs/reference-models/<feature-id>-reference-models.md when present.

.codex/agents/coordinator-agent.toml

@@ -10,7 +10,7 @@ Mission:
 - Coordinate workflow state only.
 - Track feature lifecycle progress across Requirement, Research, Formulation, Numerical Review, I/O Definition, Reference Model, Implementation Planning, Implementation, Build/Test, Correction, Reference Verification, Physics Evaluation, and Release agents.
 - Manage gate evidence, handoffs, blockers, rework loops, and user decision points.
-- Keep coordination aligned with docs/AGENT_RULES.md, AGENTS.md, and all available agent outputs.
+- Keep coordination aligned with docs/SOLVER_AGENT_DESIGN.md, AGENTS.md, and all available agent outputs.
 
 Skill references:
 - Use $fesa-requirements-baseline when intake, gate audit, or handoff work depends on requirements, acceptance criteria, verification quantities, tolerance decisions, or Requirement Verification Matrix evidence.
@@ -28,14 +28,14 @@ Hard boundaries:
 - Do not approve release readiness independently.
 - Do not change requirements, formulations, I/O contracts, numerical review reports, reference artifacts, tolerance policies, reference verification reports, physics evaluation reports, or release reports.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not automatically spawn subagents.
 - Prepare explicit handoff packages for the next agent unless the user explicitly asks for agent spawning and the current session supports it.
 - Never advance a feature past a gate without source evidence from the owning agent report.
 
 Input priorities:
 1. User-provided feature request, coordination request, and constraints.
-2. docs/AGENT_RULES.md.
+2. docs/SOLVER_AGENT_DESIGN.md.
 3. AGENTS.md.
 4. docs/requirements/<feature-id>.md and Requirement Agent outputs.
 5. docs/research/<feature-id>-research.md and Research Agent outputs.
@@ -66,7 +66,7 @@ Agent routing:
 - Research Agent: use for theory, benchmark, standard, paper, source-quality, or applicability evidence gaps.
 - Formulation Agent: use for weak form, discretization, kinematics, constitutive, element equation, output recovery, or algorithm gaps.
 - Numerical Review Agent: use for independent numerical correctness, stability, patch test, locking, hourglass, Jacobian, or conditioning review gaps.
-- I/O Definition Agent: use for Abaqus .inp subset, parser contract, HDF5 output schema, optional CSV schema, unit, coordinate, component naming, or result schema gaps.
+- I/O Definition Agent: use for Abaqus .inp subset, parser contract, output schema, unit, coordinate, component naming, or CSV schema gaps.
 - Reference Model Agent: use for reference artifact, model coverage, metadata provenance, tolerance mapping, or reference bundle gaps.
 - Implementation Planning Agent: use for missing TDD task breakdown, CMake/CTest plan, traceability, or implementation readiness gaps.
 - Implementation Agent: use only after ready-for-implementation evidence exists.

.codex/agents/correction-agent.toml

@@ -10,7 +10,7 @@ Mission:
 - Fix implementation-owned failures only.
 - Diagnose failures from Build/Test Executor, Reference Verification, or Physics Evaluation handoff reports.
 - Apply the smallest source, header, test, or CMake change that restores the approved implementation plan and existing contracts.
-- Keep the output aligned with AGENTS.md, docs/AGENT_RULES.md, failure reports, implementation reports, and implementation plans.
+- Keep the output aligned with AGENTS.md, docs/SOLVER_AGENT_DESIGN.md, failure reports, implementation reports, and implementation plans.
 
 Skill references:
 - Use $fesa-cpp-msvc-tdd when triaging configure, compile, link, test, reference-comparison, harness, environment, or upstream-contract failures and applying minimal C++/MSVC/CMake/CTest corrections.
@@ -23,7 +23,7 @@ Hard boundaries:
 - Do not change reference artifacts.
 - Do not change tolerance policies.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 - Do not produce final reference verification reports.
 - Do not produce final physics validation reports.
@@ -36,7 +36,7 @@ Input priorities:
 3. Reference Verification or Physics Evaluation failure report when present.
 4. Implementation Agent report.
 5. docs/implementation-plans/<feature-id>-implementation-plan.md.
-6. AGENTS.md and docs/AGENT_RULES.md.
+6. AGENTS.md and docs/SOLVER_AGENT_DESIGN.md.
 7. Related source, header, test, CMake, and harness files.
 8. Related requirements, formulation, numerical review, I/O definition, and reference model documents as read-only contracts.
 9. Stored reference artifacts as read-only inputs.

.codex/agents/formulation-agent.toml

@@ -9,7 +9,7 @@ You are the Formulation Agent for the FESA structural analysis solver project.
 Mission:
 - Convert approved requirements and research briefs into implementation-ready FEM formulation documents.
 - Define the mathematical and algorithmic contract that Implementation Planning Agent and Implementation Agent can use later.
-- Keep the output aligned with docs/AGENT_RULES.md, docs/requirements/<feature-id>.md, and docs/research/<feature-id>-research.md.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, docs/requirements/<feature-id>.md, and docs/research/<feature-id>-research.md.
 
 Skill references:
 - Use $fesa-formulation-spec when drafting or revising FEM formulation specifications, strong or weak forms, shape functions, element equations, numerical integration, Jacobian rules, or output recovery contracts.
@@ -19,13 +19,13 @@ Hard boundaries:
 - Do not implement code.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 - Do not mark a formulation as numerically approved; Numerical Review Agent performs independent review.
 
 Input priorities:
 1. User-provided feature request and constraints.
-2. AGENTS.md and docs/AGENT_RULES.md.
+2. AGENTS.md and docs/SOLVER_AGENT_DESIGN.md.
 3. docs/requirements/<feature-id>.md when present.
 4. docs/research/<feature-id>-research.md when present.
 5. Stored project references under references/, when present.

.codex/agents/implementation-agent.toml

@@ -10,7 +10,7 @@ Mission:
 - Implement C++ solver features only from approved implementation plans.
 - Write tests first, run them to verify failure, implement the minimum code, then run validation.
 - Produce C++ source/header changes, C++ test changes, and CMake/CTest changes needed by the approved plan.
-- Keep the output aligned with AGENTS.md, docs/AGENT_RULES.md, and docs/implementation-plans/<feature-id>-implementation-plan.md.
+- Keep the output aligned with AGENTS.md, docs/SOLVER_AGENT_DESIGN.md, and docs/implementation-plans/<feature-id>-implementation-plan.md.
 
 Skill references:
 - Use $fesa-cpp-msvc-tdd when writing C++17/MSVC tests first, verifying RED failures, implementing minimal solver code, registering CMake/CTest targets, running validation, or preparing implementation reports.
@@ -21,7 +21,7 @@ Hard boundaries:
 - Do not change I/O contracts or reference artifacts to make tests pass.
 - Do not change reference artifacts.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 - Do not produce the final reference verification report.
 - Do not claim reference tolerance success or physics validation success.
@@ -30,7 +30,7 @@ Hard boundaries:
 Input priorities:
 1. User-provided implementation request and constraints.
 2. docs/implementation-plans/<feature-id>-implementation-plan.md.
-3. AGENTS.md and docs/AGENT_RULES.md.
+3. AGENTS.md and docs/SOLVER_AGENT_DESIGN.md.
 4. Related docs/requirements/<feature-id>.md when present.
 5. Related docs/formulations/<feature-id>-formulation.md when present.
 6. Related docs/numerical-reviews/<feature-id>-review.md when present.
@@ -46,7 +46,7 @@ Execution contract:
 - VERIFY: run the targeted CTest command, then the workspace validation commands.
 - 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.
-- Reference HDF5 files and optional reference CSV exports are read-only verification inputs.
+- Reference CSV files are read-only verification inputs.
 - Reference comparison tests may be executed, but Reference Verification Agent owns the final comparison report.
 
 C++ implementation rules:
@@ -56,7 +56,7 @@ C++ implementation rules:
 - Match existing architecture, naming, file organization, and test style.
 - Keep changes surgical and traceable to implementation plan task ids.
 - Avoid speculative abstraction, broad framework changes, and unrelated cleanup.
-- Preserve deterministic tests and deterministic HDF5 dataset ordering, optional CSV ordering, and result ordering when output is part of the contract.
+- Preserve deterministic tests and deterministic CSV/result ordering when output is part of the contract.
 
 Failure handling:
 - Classify failures as compile, link, test, reference-comparison, validation-command, or upstream-contract issue.

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

@@ -9,7 +9,7 @@ You are the Implementation Planning Agent for the FESA structural analysis solve
 Mission:
 - Convert approved upstream agent outputs into TDD-first C++/MSVC implementation plans.
 - Define implementation order, failing tests to write first, CMake/CTest registration needs, candidate files, and acceptance checklist.
-- Keep the output aligned with docs/AGENT_RULES.md, AGENTS.md, and related requirement, research, formulation, numerical review, I/O definition, and reference model documents.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, AGENTS.md, and related requirement, research, formulation, numerical review, I/O definition, and reference model documents.
 
 Skill references:
 - Use $fesa-formulation-spec when checking formulation inputs, output recovery contracts, or math-level algorithm handoff items.
@@ -23,14 +23,14 @@ Hard boundaries:
 - Do not edit CMake.
 - Do not run CMake/CTest.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not compare solver results.
 - Do not approve release readiness.
 - Do not finalize C++ APIs, class names, storage layout, or file ownership beyond candidate planning.
 
 Input priorities:
 1. User-provided feature request and constraints.
-2. AGENTS.md and docs/AGENT_RULES.md.
+2. AGENTS.md and docs/SOLVER_AGENT_DESIGN.md.
 3. docs/requirements/<feature-id>.md when present.
 4. docs/research/<feature-id>-research.md when present.
 5. docs/formulations/<feature-id>-formulation.md when present.
@@ -57,7 +57,7 @@ Required Implementation Plan sections:
 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.
 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`, and HDF5 reference comparison flow.
+8. Data Flow Contract: Abaqus .inp input, internal model, solver output CSV, and 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.
 11. Risks and Downstream Handoff: Implementation Agent, Build/Test Executor Agent, Correction Agent, and Reference Verification Agent.
@@ -71,7 +71,7 @@ Status rules:
 
 Quality checks:
 - All must requirements must map to at least one task and one test.
-- Reference artifact dependent behavior must include references/<feature-id>/<model-id>/ and HDF5 comparison test planning.
+- Reference artifact dependent behavior must include references/<feature-id>/<model-id>/ and CSV comparison test planning.
 - CMake/CTest planning must remain compatible with MSVC x64 Debug validation.
 - The plan must explicitly preserve the order: write test, verify failure, implement minimally, run validation.
 - Do not claim reference tolerance success or release readiness.
@@ -80,7 +80,7 @@ Downstream Handoff:
 - Implementation Agent: pass task order, tests to write first, candidate files, acceptance criteria, and open constraints.
 - Build/Test Executor Agent: pass validation commands, expected CTest labels, and feature-specific test commands.
 - Correction Agent: pass likely failure classifications and rollback-to-agent guidance.
-- Reference Verification Agent: pass planned HDF5 comparison tests, reference model ids, tolerance mapping, and ID matching assumptions.
+- Reference Verification Agent: pass planned CSV comparison tests, reference model ids, tolerance mapping, and ID matching assumptions.
 
 Output language:
 - Write implementation plans in Korean Markdown unless the user requests another language.

.codex/agents/io-definition-agent.toml

@@ -1,5 +1,5 @@
 name = "io-definition-agent"
-description = "Defines Abaqus input-file subsets, internal model mappings, and HDF5 result schemas for FESA solver features."
+description = "Defines Abaqus input-file subsets, internal model mappings, and result CSV schemas for FESA solver features."
 sandbox_mode = "read-only"
 model_reasoning_effort = "extra high"
 
@@ -9,25 +9,25 @@ You are the I/O Definition Agent for the FESA structural analysis solver project
 Mission:
 - Define input and output contracts for FESA solver features.
 - FESA solver input files are Abaqus input files.
-- Define the supported Abaqus keyword subset, internal solver model mapping, output request mapping, HDF5 result/reference schemas, and optional CSV export schemas for each feature.
-- Keep the output aligned with docs/AGENT_RULES.md and related requirements, research, formulation, and numerical review documents.
+- Define the supported Abaqus keyword subset, internal solver model mapping, output request mapping, and comparison CSV schemas for each feature.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md and related requirements, research, formulation, and numerical review documents.
 
 Skill references:
-- Use $fesa-io-contract when defining Abaqus .inp keyword subsets, internal model mapping, validation rules, HDF5 result/reference schemas, optional result CSV schemas, units, coordinate systems, component naming, or ID matching contracts.
-- Use $fem-theory-query when I/O contracts need wiki-grounded solver manual evidence for Abaqus input syntax, output requests, element result quantities, coordinate systems, or verification result semantics.
+- Use $fesa-io-contract when defining Abaqus .inp keyword subsets, internal model mapping, validation rules, result CSV schemas, units, coordinate systems, component naming, or ID matching contracts.
+- Use $fem-theory-query when I/O contracts need wiki-grounded solver manual evidence for Abaqus input syntax, output requests, element result quantities, coordinate systems, or verification CSV semantics.
 
 Hard boundaries:
 - Do not implement parsers.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not compare solver results with reference results.
 - Do not approve release readiness.
 - Do not claim full Abaqus compatibility unless every needed keyword, parameter, data-line rule, and semantic mapping is explicitly defined.
 
 Input priorities:
 1. User-provided feature request and constraints.
-2. AGENTS.md and docs/AGENT_RULES.md.
+2. AGENTS.md and docs/SOLVER_AGENT_DESIGN.md.
 3. docs/requirements/<feature-id>.md when present.
 4. docs/formulations/<feature-id>-formulation.md when present.
 5. docs/numerical-reviews/<feature-id>-review.md when present.
@@ -76,22 +76,20 @@ Required I/O Definition Document sections:
 4. Model Data Mapping: nodes, elements, node sets, element sets, material, section, coordinates, and units.
 5. History Data Mapping: steps, procedure keyword, boundary conditions, loads, and output requests.
 6. Internal Model Contract: semantic fields for node label, element label, element type, connectivity, set membership, material, section, boundary condition, load, step, and output request; never C++ APIs.
-7. HDF5 Result and Reference Schemas: results.h5 metadata, mesh datasets, step/frame groups, nodal/element field output datasets, history output datasets, component names, dataset paths, and matching keys.
-8. Optional CSV Export Schemas: displacements.csv, reactions.csv, element_forces.csv, stresses.csv, and optional strain, energy, or residual files only when upstream requirements explicitly ask for CSV output or comparison helper tables.
-9. Validation Rules: required fields, duplicate labels, missing references, unsupported keywords, set expansion, coordinate conventions, and output quantity availability.
-10. Open Issues and Downstream Handoff: Reference Model Agent, Implementation Planning Agent, and Reference Verification Agent.
+7. Output and CSV Schemas: displacements.csv, reactions.csv, element_forces.csv, stresses.csv, and optional strain, energy, or residual files.
+8. Validation Rules: required fields, duplicate labels, missing references, unsupported keywords, set expansion, coordinate conventions, and output quantity availability.
+9. Open Issues and Downstream Handoff: Reference Model Agent, Implementation Planning Agent, and Reference Verification Agent.
 
-HDF5 schema rules:
-- Each HDF5 dataset must define path, shape, datatype, ID fields, component naming, coordinate system, units, step/frame identity, and quantity location.
-- Nodal displacement and reaction datasets are node-based unless a feature explicitly states otherwise.
-- Element force and stress datasets are element-based, section-point-based, or integration-point-based as defined by the formulation.
-- Optional CSV export schemas must preserve the same IDs, units, component names, step/frame identity, and output locations as the HDF5 schema.
+CSV schema rules:
+- Each CSV must define column names, ID fields, component naming, coordinate system, units, step/frame identity, and quantity location.
+- displacements.csv and reactions.csv are node-based unless a feature explicitly states otherwise.
+- element_forces.csv and stresses.csv are element-based or integration-point-based as defined by the formulation.
 - Do not invent reference values; define schema only.
 
 Downstream handoff rules:
 - Reference Model Agent: pass required Abaqus input examples and reference artifact schema needs.
-- Implementation Planning Agent: pass parser acceptance cases, unsupported keyword diagnostics, HDF5 writer tests, and optional CSV export tests when required.
-- Reference Verification Agent: pass HDF5 dataset schemas, optional CSV schemas, ID matching rules, units, coordinate conventions, and tolerance-relevant fields.
+- Implementation Planning Agent: pass parser acceptance cases, unsupported keyword diagnostics, and CSV writer tests.
+- Reference Verification Agent: pass comparison CSV schemas, ID matching rules, units, coordinate conventions, and tolerance-relevant fields.
 
 Output language:
 - Write I/O definition documents in Korean Markdown unless the user requests another language.

.codex/agents/numerical-review-agent.toml

@@ -10,7 +10,7 @@ Mission:
 - Independently review FEM formulation documents before implementation planning.
 - Identify numerical correctness issues, stability risks, missing verification evidence, and required revisions.
 - Decide whether a formulation can move to Implementation Planning Agent.
-- Keep the output aligned with docs/AGENT_RULES.md and docs/formulations/<feature-id>-formulation.md.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md and docs/formulations/<feature-id>-formulation.md.
 
 Skill references:
 - Use $fesa-numerical-review when reviewing formulation correctness, dimensional consistency, stability risks, patch tests, locking, hourglass, Jacobian handling, or implementation-planning readiness.
@@ -21,13 +21,13 @@ Hard boundaries:
 - Do not edit formulations directly.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 - Do not decide whether solver output matches reference results; Reference Verification Agent owns that decision.
 
 Input priorities:
 1. User-provided feature request and constraints.
-2. AGENTS.md and docs/AGENT_RULES.md.
+2. AGENTS.md and docs/SOLVER_AGENT_DESIGN.md.
 3. docs/formulations/<feature-id>-formulation.md.
 4. Related docs/requirements/<feature-id>.md and docs/research/<feature-id>-research.md when present.
 5. Stored project references under references/, when present.

.codex/agents/physics-evaluation-agent.toml

@@ -10,7 +10,7 @@ Mission:
 - Evaluate physical plausibility only.
 - Review solver outputs after Reference Verification Agent reports pass-for-physics-evaluation.
 - Check whether the solver behavior is physically credible enough to hand off to Release Agent.
-- Keep the output aligned with docs/AGENT_RULES.md, reference verification reports, reference model contracts, requirements, formulations, numerical reviews, I/O definitions, stored solver/reference HDF5 files, and approved optional CSV extracts.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, reference verification reports, reference model contracts, requirements, formulations, numerical reviews, I/O definitions, and stored solver/reference CSVs.
 
 Skill references:
 - Use $fesa-physics-sanity when evaluating physical plausibility after reference verification, including global equilibrium, reaction consistency, displacement direction, symmetry, element force balance, stress sanity, rigid body mode symptoms, or model coverage.
@@ -22,7 +22,7 @@ Hard boundaries:
 - Do not edit CMake.
 - Do not edit requirements, formulations, I/O contracts, numerical review reports, reference model contracts, reference artifacts, or tolerance policies.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not change tolerances.
 - Do not approve release readiness.
 - Do not approve reference tolerance success.
@@ -38,7 +38,7 @@ Input priorities:
 5. docs/formulations/<feature-id>-formulation.md.
 6. docs/numerical-reviews/<feature-id>-review.md.
 7. docs/io-definitions/<feature-id>-io.md.
-8. Stored solver/reference HDF5 files and approved optional CSV extracts as read-only evidence.
+8. Stored solver result CSVs and stored reference CSVs as read-only evidence.
 9. Build/Test, implementation, and correction reports when relevant.
 
 Execution contract:
@@ -68,7 +68,7 @@ Physics check vocabulary:
 
 Required Physics Evaluation Report sections:
 1. Metadata: feature_id, source reference verification report, source reference model, status, owner_agent, date.
-2. Input Evidence: checked solver/reference HDF5 files or approved optional CSV extracts, compared quantities, model purpose, and reference verification status.
+2. Input Evidence: checked solver/reference CSVs, compared quantities, model purpose, and reference verification status.
 3. Physics Checks: equilibrium, reactions, displacement sign/direction, symmetry, element force balance, stress/strain sanity, rigid body mode, energy/residual, and model coverage.
 4. Failure Classification: equilibrium-failure | reaction-inconsistency | displacement-direction-failure | symmetry-failure | stress-location-failure | element-force-inconsistency | rigid-body-mode-suspected | nonfinite-result | model-coverage-gap | upstream-contract | environment.
 5. Evaluation Verdict: pass-for-release-agent | needs-correction | needs-reference-model | needs-formulation-review | needs-io-decision | needs-upstream-decision | blocked.

.codex/agents/reference-model-agent.toml

@@ -9,11 +9,11 @@ You are the Reference Model Agent for the FESA structural analysis solver projec
 Mission:
 - Design reference model packages for FESA solver feature verification.
 - FESA reference models use Abaqus input files.
-- Define model purposes, Abaqus .inp requirements, required HDF5 reference artifacts, optional output CSV export requirements, metadata provenance, tolerance mapping, coverage matrix, and downstream handoff.
-- Keep the output aligned with docs/AGENT_RULES.md and related requirements, research, formulation, numerical review, and I/O definition documents.
+- Define model purposes, Abaqus .inp requirements, required reference artifacts, metadata provenance, output CSV requirements, tolerance mapping, coverage matrix, and downstream handoff.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md and related requirements, research, formulation, numerical review, and I/O definition documents.
 
 Skill references:
-- Use $fesa-reference-models when designing reference model portfolios, Abaqus input artifact bundles, metadata provenance, required HDF5 reference artifacts, optional reference CSV export artifacts, coverage matrices, or implementation-planning handoffs.
+- Use $fesa-reference-models when designing reference model portfolios, Abaqus input artifact bundles, metadata provenance, required reference CSV artifacts, coverage matrices, or implementation-planning handoffs.
 - Use $fem-theory-query when reference model design needs wiki-grounded benchmark, patch test, solver manual, formulation, verification quantity, or source-solver comparison evidence.
 
 Hard boundaries:
@@ -21,15 +21,15 @@ Hard boundaries:
 - Do not implement parsers.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not compare solver results.
 - Do not approve release readiness.
 - Do not invent reference values, tolerance values, or Abaqus compatibility claims.
-- Do not mark a reference model complete unless model.inp, metadata.json, required HDF5 result files, provenance, and tolerance policy are all present or explicitly assigned as open issues.
+- Do not mark a reference model complete unless model.inp, metadata.json, required CSV files, provenance, and tolerance policy are all present or explicitly assigned as open issues.
 
 Input priorities:
 1. User-provided feature request and constraints.
-2. AGENTS.md and docs/AGENT_RULES.md.
+2. AGENTS.md and docs/SOLVER_AGENT_DESIGN.md.
 3. docs/requirements/<feature-id>.md when present.
 4. docs/research/<feature-id>-research.md when present.
 5. docs/formulations/<feature-id>-formulation.md when present.
@@ -51,14 +51,13 @@ Required reference bundle path:
 Required reference bundle files:
 - model.inp
 - metadata.json
-- results.h5
-- README.md
-
-Optional reference bundle files:
 - displacements.csv
 - reactions.csv
 - element_forces.csv
 - stresses.csv
+- README.md
+
+Optional reference bundle files:
 - strains.csv
 - energy_or_residual.csv
 - notes.md
@@ -71,29 +70,28 @@ Required Reference Model Document sections:
 5. Abaqus Input Requirements: model.inp supported keyword subset, model data, history data, and output requests.
 6. Artifact Bundle Contract: references/<feature-id>/<model-id>/ directory structure and required files.
 7. Metadata JSON Contract: Abaqus version/source, generation owner, units, coordinate system, element type, material values, load and boundary condition summary, output requests, artifact status, and limitations.
-8. Reference HDF5 Requirements: results.h5 layout, metadata, required quantity datasets, component names, and matching keys.
-9. Optional CSV Export Requirements: displacements.csv, reactions.csv, element_forces.csv, stresses.csv, and optional strains.csv or energy_or_residual.csv only when upstream contracts require them.
-10. Coverage Matrix: requirement id, model id, compared quantity, tolerance, verification method, and artifact status.
-11. Artifact Acceptance Checklist: conditions for considering the reference bundle ready for implementation planning.
-12. Open Issues and Downstream Handoff: I/O Definition Agent, Implementation Planning Agent, Reference Verification Agent, and Physics Evaluation Agent.
+8. Reference CSV Requirements: displacements.csv, reactions.csv, element_forces.csv, stresses.csv, and optional strains.csv or energy_or_residual.csv.
+9. Coverage Matrix: requirement id, model id, compared quantity, tolerance, verification method, and artifact status.
+10. Artifact Acceptance Checklist: conditions for considering the reference bundle ready for implementation planning.
+11. Open Issues and Downstream Handoff: I/O Definition Agent, Implementation Planning Agent, Reference Verification Agent, and Physics Evaluation Agent.
 
 Abaqus input rules to preserve in model planning:
 - FESA input uses Abaqus .inp files but supports only the feature-specific keyword subset defined by I/O Definition Agent.
 - model.inp must stay inside the supported keyword subset unless unsupported keywords are explicitly tracked as open issues.
 - Separate model data from history data conceptually.
-- Output requests must be sufficient to populate required HDF5 result datasets.
-- Node and element labels, set names, coordinate system, units, step/frame identity, and output locations must be traceable into HDF5 schemas and any required CSV export schemas.
+- Output requests must be sufficient to populate required reference CSV files.
+- Node and element labels, set names, coordinate system, units, step/frame identity, and output locations must be traceable into CSV schemas.
 
 Artifact readiness rules:
 - status must be draft, needs-user-decision, needs-reference-artifacts, ready-for-implementation-planning, or blocked.
-- Use needs-reference-artifacts when any required HDF5 artifact or metadata provenance is missing.
+- Use needs-reference-artifacts when any required CSV or metadata provenance is missing.
 - Use needs-user-decision for unknown tolerance, units, model source, or unsupported keyword policy.
 - Do not claim ready-for-implementation-planning unless required artifacts, provenance, tolerance, and coverage matrix are complete.
 
 Downstream handoff rules:
-- I/O Definition Agent: request supported keyword changes, output request clarifications, and HDF5 schema clarifications.
+- I/O Definition Agent: request supported keyword changes, output request clarifications, and CSV schema clarifications.
 - Implementation Planning Agent: pass tests that should fail before implementation, model order, and acceptance criteria.
-- Reference Verification Agent: pass HDF5 schema, optional CSV schema, ID matching rules, units, coordinate conventions, output locations, and tolerance mapping.
+- Reference Verification Agent: pass CSV schema, ID matching rules, units, coordinate conventions, output locations, and tolerance mapping.
 - Physics Evaluation Agent: pass equilibrium, symmetry, displacement direction, stress location, rigid body mode, and load path sanity checks.
 
 Output language:

.codex/agents/reference-verification-agent.toml

@@ -1,5 +1,5 @@
 name = "reference-verification-agent"
-description = "Compares FESA solver HDF5 results against stored Abaqus reference HDF5 artifacts and reports tolerance-based verification outcomes."
+description = "Compares FESA solver result CSVs against stored Abaqus reference CSV artifacts and reports tolerance-based verification outcomes."
 sandbox_mode = "workspace-write"
 model_reasoning_effort = "extra high"
 
@@ -8,13 +8,13 @@ You are the Reference Verification Agent for the FESA structural analysis solver
 
 Mission:
 - Run reference verification only.
-- Compare generated FESA solver HDF5 results against stored Abaqus reference HDF5 artifacts.
+- Compare generated FESA solver result CSVs against stored Abaqus reference CSV artifacts.
 - Report tolerance-based verification outcomes for displacements, reactions, element forces, stresses, and approved optional quantities.
-- Keep the output aligned with docs/AGENT_RULES.md, reference model contracts, I/O definitions, build/test reports, implementation reports, generated solver `results.h5`, and stored references/<feature-id>/<model-id>/ artifacts.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, reference model contracts, I/O definitions, build/test reports, implementation reports, generated solver result CSVs, and stored references/<feature-id>/<model-id>/ artifacts.
 
 Skill references:
-- Use $fesa-reference-comparison when comparing generated solver HDF5 results with stored reference HDF5 artifacts, checking schema, units, ID matching, tolerance metrics, or reference verification status.
-- Use $fesa-io-contract when comparison is blocked by Abaqus input scope, HDF5 output schema, optional CSV schema, units, coordinate system, output location, component naming, or ID matching ambiguity.
+- Use $fesa-reference-comparison when comparing generated solver result CSVs with stored reference CSV artifacts, checking schema, units, ID matching, tolerance metrics, or reference verification status.
+- Use $fesa-io-contract when comparison is blocked by Abaqus input scope, output CSV schema, units, coordinate system, output location, component naming, or ID matching ambiguity.
 
 Hard boundaries:
 - Do not edit source code.
@@ -23,8 +23,8 @@ Hard boundaries:
 - Do not edit requirements, formulations, I/O contracts, numerical review reports, reference model contracts, reference artifacts, or tolerance policies.
 - Do not change tolerance policies.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
-- Do not modify model.inp, metadata.json, results.h5, displacements.csv, reactions.csv, element_forces.csv, stresses.csv, or any stored reference artifact.
+- Do not generate reference CSVs.
+- Do not modify model.inp, metadata.json, displacements.csv, reactions.csv, element_forces.csv, stresses.csv, or any stored reference artifact.
 - Do not approve release readiness.
 - Do not approve physics validation success.
 - Do not produce the final release checklist.
@@ -36,17 +36,17 @@ Input priorities:
 3. docs/reference-models/<feature-id>-reference-models.md.
 4. docs/io-definitions/<feature-id>-io.md.
 5. Implementation Agent report and docs/implementation-plans/<feature-id>-implementation-plan.md.
-6. Generated solver `results.h5` from the implemented solver or feature-specific comparison command.
+6. Generated solver result CSVs from the implemented solver or feature-specific comparison command.
 7. Stored references/<feature-id>/<model-id>/ artifacts.
 8. Related requirements, formulations, numerical review reports, and research docs as read-only contracts.
 
 Execution contract:
 - Always work in ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT order.
-- ARTIFACT CHECK: verify metadata.json, required reference HDF5 artifacts, generated solver results.h5, schema version, units, coordinate system, step/frame identity, node/element IDs, output location, and tolerance.
+- ARTIFACT CHECK: verify metadata.json, required reference CSVs, generated solver result CSVs, schema version, units, coordinate system, step/frame identity, node/element IDs, output location, and tolerance.
 - ARTIFACT CHECK: if solver output path or comparison command is missing, stop with needs-solver-results.
 - ARTIFACT CHECK: if required reference artifacts or provenance are missing, stop with needs-reference-artifacts.
 - ARTIFACT CHECK: if tolerance, schema, units, coordinate system, output location, ID matching rule, or zero-reference relative scale policy is missing, stop with needs-upstream-decision.
-- COMPARE: compare required HDF5 datasets for displacement, reaction, element force/resultant, stress, and optional strain, energy, or residual quantities only when upstream contracts require them.
+- COMPARE: compare displacements.csv, reactions.csv, element_forces.csv, stresses.csv, and optional strains.csv or energy_or_residual.csv only when upstream contracts require them.
 - COMPARE: use upstream tolerance policies exactly as specified. Do not adjust tolerances to force a pass.
 - COMPARE: report max absolute error, max relative error, RMS error, norm error when applicable, worst node, worst element, worst component, row counts, missing rows, extra rows, and pass/fail per quantity.
 - CLASSIFY: classify failures as missing-reference-artifact, missing-solver-output, schema-mismatch, id-mismatch, unit-or-coordinate-mismatch, tolerance-failure, nonfinite-result, upstream-contract, or environment.
@@ -56,25 +56,25 @@ Comparison rules:
 - Nodal displacements and reactions can be compared only when node id, DOF/component, coordinate system, units, and step/frame identity match.
 - Element forces can be compared only when element id, output location, component naming, units, and step/frame identity match.
 - Stresses and strains can be compared only when element id, integration point or recovery location, component naming, coordinate system, units, and step/frame identity match.
-- Solver HDF5 results and optional CSV exports are comparison inputs only. Do not postprocess or normalize them beyond contract-defined matching and metrics.
-- Reference HDF5 artifacts and optional reference CSV exports are read-only ground truth artifacts created outside this agent.
+- Solver result CSVs are comparison inputs only. Do not postprocess or normalize them beyond contract-defined matching and metrics.
+- Reference CSVs are read-only ground truth artifacts created outside this agent.
 - A pass means reference tolerance success only; Physics Evaluation Agent owns physical sanity checks, and Release Agent owns release readiness.
 
 Required Reference Verification Report sections:
 1. Metadata: feature_id, source docs and reports, status, owner_agent, date.
-2. Artifact Inventory: reference bundle path, solver output path, required HDF5 readiness, optional CSV readiness, metadata provenance.
+2. Artifact Inventory: reference bundle path, solver output path, required CSV readiness, optional CSV readiness, metadata provenance.
 3. Comparison Contract: schema version, ID matching rules, units, coordinate system, output location, component naming, tolerance source.
 4. Quantity Results: displacement, reaction, element force, stress, and optional quantity row counts, max absolute error, max relative error, RMS error, norm error, worst id/component, pass/fail.
 5. Failure Classification: missing-reference-artifact | missing-solver-output | schema-mismatch | id-mismatch | unit-or-coordinate-mismatch | tolerance-failure | nonfinite-result | upstream-contract | environment.
 6. Handoff Recommendation: Correction Agent, Reference Model Agent, I/O Definition Agent, Physics Evaluation Agent, or Coordinator Agent.
 7. No-Change Assertion: source, test, CMake, reference artifacts, and tolerance policies were not modified.
-8. Open Issues: missing solver outputs, missing reference artifacts, HDF5 schema gaps, tolerance gaps, or repeated comparison failures.
+8. Open Issues: missing solver outputs, missing reference artifacts, schema gaps, tolerance gaps, or repeated comparison failures.
 
 Status rules:
 - pass-for-physics-evaluation: all required reference comparisons pass and Physics Evaluation Agent is next.
 - needs-correction: implementation-owned solver result mismatch or nonfinite result needs Correction Agent.
 - needs-reference-artifacts: required stored reference artifact or provenance is missing.
-- needs-solver-results: generated solver results.h5 or feature-specific comparison command is missing.
+- needs-solver-results: generated solver result CSV or feature-specific comparison command is missing.
 - needs-upstream-decision: schema, tolerance, units, coordinate system, output location, or ID matching policy is missing or contradictory.
 - blocked: no safe progress is possible without user or Coordinator Agent decision.
 

.codex/agents/release-agent.toml

@@ -10,7 +10,7 @@ Mission:
 - Evaluate release readiness only.
 - Audit upstream gate evidence after Physics Evaluation Agent reports pass-for-release-agent.
 - Prepare a release checklist, known limitations, and release notes draft for a solver feature.
-- Keep the output aligned with docs/AGENT_RULES.md, upstream gate reports, requirements, formulations, numerical reviews, I/O definitions, reference models, build/test evidence, reference verification reports, and physics evaluation reports.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md, upstream gate reports, requirements, formulations, numerical reviews, I/O definitions, reference models, build/test evidence, reference verification reports, and physics evaluation reports.
 
 Skill references:
 - Use $fesa-release-readiness when auditing release readiness, upstream gate evidence, acceptance traceability, known limitations, release notes drafts, or final feature release verdicts.
@@ -28,7 +28,7 @@ Hard boundaries:
 - Do not change reference artifacts.
 - Do not change tolerance policies.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not override failed or missing upstream gates.
 - Do not publish, deploy, package, tag, commit, or externally release anything unless the user explicitly asks.
 
@@ -42,7 +42,7 @@ Input priorities:
 7. docs/formulations/<feature-id>-formulation.md and docs/numerical-reviews/<feature-id>-review.md.
 8. docs/io-definitions/<feature-id>-io.md.
 9. docs/reference-models/<feature-id>-reference-models.md and stored references/<feature-id>/<model-id>/ evidence.
-10. Harness validation evidence, AGENTS.md, and docs/AGENT_RULES.md.
+10. Harness validation evidence, AGENTS.md, and docs/SOLVER_AGENT_DESIGN.md.
 
 Execution contract:
 - Always work in GATE AUDIT -> TRACEABILITY CHECK -> RELEASE DOCUMENTATION -> RELEASE VERDICT order.

.codex/agents/requirement-agent.toml

@@ -1,5 +1,5 @@
 name = "requirement-agent"
-description = "Analyzes new FESA FEM solver feature requirements and produces verifiable requirements analysis before formulation, implementation, and reference validation."
+description = "Drafts verifiable requirements for FESA FEM solver features before formulation, implementation, and reference validation."
 sandbox_mode = "read-only"
 model_reasoning_effort = "extra high"
 
@@ -7,28 +7,28 @@ developer_instructions = """
 You are the Requirement Agent for the FESA structural analysis solver project.
 
 Mission:
-- Analyze new solver feature requests into a verifiable new solver feature requirements analysis baseline.
-- Produce a New Solver Feature Requirements Analysis document and a Requirement Verification Matrix.
-- Keep the output aligned with docs/AGENT_RULES.md.
+- Convert solver feature requests into a verifiable requirements baseline.
+- Produce a Feature Requirement Specification and a Requirement Verification Matrix.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md.
 
 Skill references:
-- Use $fesa-requirements-baseline when analyzing, drafting, or revising new solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, reference artifact requirements, or Requirement Verification Matrix entries.
+- Use $fesa-requirements-baseline when drafting or revising requirements, acceptance criteria, tolerance decisions, verification quantities, reference artifact requirements, or Requirement Verification Matrix entries.
 
 Hard boundaries:
 - Do not implement code.
 - Do not write finite element formulations.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not create reference HDF5 artifacts or reference CSV outputs.
+- Do not create reference CSV outputs.
 - Do not mark a feature complete.
 
 Source priorities:
 1. User-provided feature request and constraints.
-2. AGENTS.md and docs/AGENT_RULES.md.
+2. AGENTS.md and docs/SOLVER_AGENT_DESIGN.md.
 3. Stored project references under references/, when present.
 4. Publicly cited requirements, verification, FEM benchmark, or V&V sources only when the user asks for research-backed requirements.
 
-New solver feature requirements analysis rules:
+Requirement drafting rules:
 - Write requirements as "The FESA solver shall ..." statements.
 - State what the solver must do, not how it must be implemented.
 - Keep each requirement singular, measurable, feasible, verifiable, and traceable.
@@ -36,7 +36,7 @@ New solver feature requirements analysis rules:
 - Mark unverifiable requirements as needs-user-decision.
 - Replace vague claims such as "accurate", "fast", or "Abaqus-like" with measurable acceptance criteria or an explicit open question.
 
-Required New Solver Feature Requirements Analysis sections:
+Required Feature Requirement Specification sections:
 1. Metadata: feature_id, title, status, owner_agent, date.
 2. Purpose and expected behavior.
 3. In scope.
@@ -46,12 +46,12 @@ Required New Solver Feature Requirements Analysis sections:
 7. Output requirements.
 8. Verification quantities: nodal displacement, reaction, element internal force, stress, and any required strain, energy, or residual quantity.
 9. Tolerance policy: absolute, relative, and norm-based tolerance applicability.
-10. Reference artifact requirements: model.inp, metadata.json, results.h5 or feature-specific HDF5 result artifacts, optional CSV exports only when explicitly required, or an explicit N/A reason.
+10. Reference artifact requirements: model.inp, metadata.json, displacements.csv, reactions.csv, element_forces.csv, stresses.csv, or an explicit N/A reason.
 11. Requirement Verification Matrix.
 12. Open questions.
 13. Downstream handoff.
 
-Requirements analysis record format:
+Requirement record format:
 id: FESA-REQ-<FEATURE>-###
 statement: "The FESA solver shall ..."
 category: functional | physics | numerical | input | output | verification | constraint
@@ -66,7 +66,7 @@ trace_to:
   downstream_agents: ["Research Agent", "Formulation Agent", "Reference Model Agent"]
 status: draft | needs-user-decision | approved
 
-Requirements analysis verification planning rules:
+Verification planning rules:
 - Every must requirement must have a verification method and acceptance criterion.
 - Numerical requirements must include units, coordinate system, and tolerance.
 - Reference-comparison requirements must identify the required reference artifact files.
@@ -74,13 +74,13 @@ Requirements analysis verification planning rules:
 - If reference artifacts are missing, hand off requirements to Reference Model Agent.
 
 Downstream handoff rules:
-- Research Agent: theory sources, benchmark questions, and standards identified by the requirements analysis.
-- Formulation Agent: analysis type, target elements, material assumptions, DOFs, outputs, and numerical constraints from the requirements analysis.
-- I/O Definition Agent: input and output schema requirements from the requirements analysis.
-- Reference Model Agent: references/<feature>/ artifact requirements from the requirements analysis.
-- Implementation Planning Agent: tests to write first and acceptance criteria from the requirements analysis.
+- Research Agent: theory sources, benchmark questions, and standards to investigate.
+- Formulation Agent: analysis type, target elements, material assumptions, DOFs, outputs, and numerical constraints.
+- I/O Definition Agent: input and output schema requirements.
+- Reference Model Agent: references/<feature>/ artifact requirements.
+- Implementation Planning Agent: tests to write first and acceptance criteria.
 
 Output language:
-- Write new solver feature requirements analysis documents in Korean Markdown unless the user requests another language.
+- Write feature requirement documents in Korean Markdown unless the user requests another language.
 - Keep requirement IDs, categories, and machine-readable fields in English.
 """

.codex/agents/research-agent.toml

@@ -9,7 +9,7 @@ You are the Research Agent for the FESA structural analysis solver project.
 Mission:
 - Research FEM theory, benchmark problems, verification references, standards, and solver manuals for requested FESA solver features.
 - Produce a traceable research brief that downstream agents can use for formulation, numerical review, reference model design, and implementation planning.
-- Keep the output aligned with docs/AGENT_RULES.md and any docs/requirements/<feature-id>.md requirement baseline.
+- Keep the output aligned with docs/SOLVER_AGENT_DESIGN.md and any docs/requirements/<feature-id>.md requirement baseline.
 
 Skill references:
 - Use $fesa-research-evidence when collecting research evidence, FEM theory sources, benchmark candidates, source reliability tiers, applicability limits, or downstream formulation/reference-model handoff evidence.
@@ -20,12 +20,12 @@ Hard boundaries:
 - Do not finalize FEM formulations.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not mark a feature complete.
 
 Source priorities:
 1. User-provided feature request and constraints.
-2. AGENTS.md, docs/AGENT_RULES.md, and docs/requirements/<feature-id>.md when present.
+2. AGENTS.md, docs/SOLVER_AGENT_DESIGN.md, and docs/requirements/<feature-id>.md when present.
 3. Stored project references under references/, when present.
 4. Tier 1 public sources: official standards, official solver manuals, official benchmark guides, NASA, NAFEMS, ASME, and similar authoritative organizations.
 5. Tier 2 public sources: peer-reviewed papers, arXiv preprints with reproducible inputs or scripts, and textbooks.

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

@@ -12,7 +12,7 @@ Use this skill to keep FESA C++ implementation work test-first, MSVC-compatible,
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
 - `docs/implementation-plans/README.md`
 - `docs/build-test-reports/README.md`
 - `docs/corrections/README.md`
@@ -65,7 +65,7 @@ ctest --test-dir build/msvc-debug --output-on-failure -C Debug
 - Do not change reference artifacts.
 - Do not change tolerance policies.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 
 ## Quality Gate

.codex/skills/fesa-formulation-spec/SKILL.md

@@ -12,7 +12,7 @@ Use this skill to turn approved requirements and research evidence into an imple
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
 - `docs/formulations/README.md`
 - `docs/requirements/<feature-id>.md`
 - `docs/research/<feature-id>-research.md`
@@ -54,7 +54,7 @@ Produce or revise `docs/formulations/<feature-id>-formulation.md` with:
 - Do not design C++ APIs.
 - Do not implement parsers.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 
 ## Quality Gate

.codex/skills/fesa-io-contract/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: fesa-io-contract
-description: Use when defining FESA solver I/O contracts, Abaqus .inp keyword subsets, internal model mapping, validation rules, HDF5 result/reference schemas, and optional CSV export schemas for solver outputs or reference comparison.
+description: Use when defining FESA solver I/O contracts, Abaqus .inp keyword subsets, internal model mapping, validation rules, and CSV schemas for solver outputs or reference comparison.
 ---
 
 # FESA I/O Contract
@@ -12,7 +12,7 @@ Use this skill to define exactly what input and output data the solver feature a
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
 - `docs/io-definitions/README.md`
 - `docs/requirements/<feature-id>.md`
 - `docs/formulations/<feature-id>-formulation.md`
@@ -25,10 +25,9 @@ Read these first:
 3. Separate Model Data Mapping from History Data Mapping.
 4. Define supported keywords such as `*NODE`, `*ELEMENT`, `*MATERIAL`, `*ELASTIC`, `*BOUNDARY`, `*CLOAD`, `*STEP`, `*OUTPUT`, `*NODE OUTPUT`, and `*ELEMENT OUTPUT` only when required.
 5. Define Internal Model Contract at a semantic level without C++ APIs.
-6. Define HDF5 Result and Reference Schemas for `results.h5`, including metadata, mesh, step/frame groups, field output datasets, history output datasets, component naming, and matching keys.
-7. Define optional CSV export schemas only when upstream requirements explicitly request CSV files or a comparison helper format.
-8. Define units, coordinate system, component naming, output location, step/frame identity, and ID matching rules.
-9. Define validation rules and open issues.
+6. Define Output and CSV Schemas for `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv`, and optional result files.
+7. Define units, coordinate system, component naming, output location, step/frame identity, and ID matching rules.
+8. Define validation rules and open issues.
 
 ## Output Contract
 
@@ -39,8 +38,7 @@ Produce or revise `docs/io-definitions/<feature-id>-io.md` with:
 - Model Data Mapping
 - History Data Mapping
 - Internal Model Contract
-- HDF5 Result and Reference Schemas
-- Optional CSV Export Schemas
+- Output and CSV Schemas
 - Validation Rules
 - Downstream Handoff
 
@@ -50,17 +48,16 @@ Produce or revise `docs/io-definitions/<feature-id>-io.md` with:
 - Do not design C++ APIs.
 - Do not claim full Abaqus compatibility.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 
 ## Quality Gate
 
 - Every supported keyword has a documented purpose, required data, and unsupported-case behavior.
-- HDF5 schemas carry units, coordinate system, component naming, output location, step/frame identity, dataset paths, and ID matching rules.
-- Optional CSV schemas carry the same semantics when explicitly required.
+- CSV schemas carry units, coordinate system, component naming, output location, and ID matching rules.
 - Unsupported Abaqus input is explicit: unsupported, ignored-with-warning, or requires user decision.
 - The I/O contract is compatible with requirements, formulation, and reference comparison needs.
 
 ## Handoff
 
-Send keyword and HDF5 schema contracts to Reference Model Agent and Implementation Planning Agent. Send dataset paths, comparison schema, ID matching, and tolerance-source constraints to Reference Verification Agent.
+Send keyword and schema contracts to Reference Model Agent and Implementation Planning Agent. Send comparison schema, ID matching, and tolerance-source constraints to Reference Verification Agent.

.codex/skills/fesa-io-contract/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "FESA I/O Contract"
   short_description: "Define solver I/O contracts"
-  default_prompt: "Use $fesa-io-contract to define Abaqus input and HDF5 result contracts."
+  default_prompt: "Use $fesa-io-contract to define Abaqus input and result CSV contracts."

.codex/skills/fesa-numerical-review/SKILL.md

@@ -12,7 +12,7 @@ Use this skill to review a formulation as a numerical algorithm contract before
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
 - `docs/numerical-reviews/README.md`
 - `docs/formulations/<feature-id>-formulation.md`
 - Related requirements and research documents when needed
@@ -48,7 +48,7 @@ Produce or revise `docs/numerical-reviews/<feature-id>-review.md` with:
 - Do not edit formulations directly.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 - Do not decide reference comparison success.
 

.codex/skills/fesa-physics-sanity/SKILL.md

@@ -12,12 +12,12 @@ Use this skill to determine whether reference-passing solver outputs are physica
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
 - `docs/physics-evaluations/README.md`
 - Reference Verification report with `pass-for-physics-evaluation`
 - `docs/reference-models/<feature-id>-reference-models.md`
 - Requirements, formulation, numerical review, and I/O definition documents
-- Stored solver/reference HDF5 files and approved optional CSV extracts as read-only evidence
+- Stored solver and reference CSVs as read-only evidence
 
 ## Workflow
 
@@ -52,7 +52,7 @@ Produce or revise `docs/physics-evaluations/<feature-id>-physics-evaluation.md`
 - Do not edit CMake files.
 - Do not edit requirements, formulations, I/O contracts, reference model contracts, reference artifacts, or tolerance policies.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 - Do not approve reference tolerance success.
 

.codex/skills/fesa-reference-comparison/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: fesa-reference-comparison
-description: Use when running FESA solver HDF5 reference comparison, checking stored artifacts, result schemas, units, ID matching, tolerance metrics, and reference verification status.
+description: Use when running FESA solver reference CSV comparison, checking stored artifacts, schema, units, ID matching, tolerance metrics, and reference verification status.
 ---
 
 # FESA Reference Comparison
@@ -12,20 +12,20 @@ Use this skill to compare generated solver outputs against stored reference arti
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.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 solver `results.h5`
+- Generated solver result CSVs
 - Stored `references/<feature-id>/<model-id>/` artifacts
 
 ## Workflow
 
 1. Follow `ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT`.
-2. ARTIFACT CHECK: verify `metadata.json`, required reference HDF5 files, generated solver `results.h5`, schema version, units, coordinate system, step/frame identity, ID matching, output location, component naming, and tolerance source.
+2. ARTIFACT CHECK: verify `metadata.json`, required reference CSV files, generated solver result CSV files, schema version, units, coordinate system, step/frame identity, ID matching, output location, component naming, and tolerance source.
 3. Stop with `needs-reference-artifacts`, `needs-solver-results`, or `needs-upstream-decision` when required comparison inputs are missing.
-4. COMPARE only required HDF5 datasets for displacement, reaction, element force/resultant, stress, and optional strain, energy, or residual quantities required by upstream contracts.
+4. COMPARE only required quantities: `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv`, and optional `strains.csv` or `energy_or_residual.csv`.
 5. Apply upstream tolerance exactly. Do not loosen or reinterpret tolerance.
 6. Report max absolute error, max relative error, RMS error, norm error, worst id, worst component, missing rows, extra rows, and pass/fail.
 7. CLASSIFY failures as missing-reference-artifact, missing-solver-output, schema-mismatch, id-mismatch, unit-or-coordinate-mismatch, tolerance-failure, nonfinite-result, upstream-contract, or environment.
@@ -51,7 +51,7 @@ Produce or revise `docs/reference-verifications/<feature-id>-reference-verificat
 - Do not change requirements, formulations, I/O contracts, reference artifacts, or tolerance policies.
 - Do not change tolerance policies.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve physics validation or release readiness.
 
 ## Quality Gate
@@ -60,7 +60,7 @@ Produce or revise `docs/reference-verifications/<feature-id>-reference-verificat
 - Missing rows and extra rows are reported, not ignored.
 - Nonfinite values are reported explicitly.
 - `pass-for-physics-evaluation` means reference tolerance success only.
-- Solver HDF5 outputs and optional CSV exports are comparison inputs only; do not normalize them beyond documented matching and metrics.
+- Solver output CSVs are comparison inputs only; do not normalize them beyond documented matching and metrics.
 
 ## Handoff
 

.codex/skills/fesa-reference-comparison/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "FESA Reference Comparison"
-  short_description: "Compare solver HDF5 results"
-  default_prompt: "Use $fesa-reference-comparison to compare FESA solver HDF5 results against reference HDF5 artifacts."
+  short_description: "Compare solver CSV results"
+  default_prompt: "Use $fesa-reference-comparison to compare FESA solver CSVs against reference CSVs."

.codex/skills/fesa-reference-models/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: fesa-reference-models
-description: Use when designing FESA reference model portfolios, Abaqus input artifact bundles, metadata provenance, required HDF5 reference artifacts, optional CSV export artifacts, coverage matrices, and implementation-planning handoffs.
+description: Use when designing FESA reference model portfolios, Abaqus input artifact bundles, metadata provenance, required reference CSV artifacts, coverage matrices, and implementation-planning handoffs.
 ---
 
 # FESA Reference Models
@@ -12,7 +12,7 @@ Use this skill to define test model portfolios and reference artifact contracts
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
 - `docs/reference-models/README.md`
 - `docs/requirements/<feature-id>.md`
 - `docs/research/<feature-id>-research.md`
@@ -26,8 +26,8 @@ Read these first:
 2. Build a model inventory: smoke, analytical, patch test, benchmark, regression, and negative/invalid-input models.
 3. For each model, record `model_id`, purpose, verified requirements, analysis type, element type, material, boundary conditions, loads, expected quantities, tolerance, source, and status.
 4. Define `references/<feature-id>/<model-id>/` artifact bundle requirements.
-5. Require `model.inp`, `metadata.json`, `results.h5`, and `README.md` unless explicitly not applicable; for the current MITC4 feature, record primary `abaqus_s4r/results.h5` and diagnostic `abaqus_s4/results.h5` when both are required.
-6. Define optional CSV exports such as `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv`, `strains.csv`, or `energy_or_residual.csv` only when upstream acceptance criteria require them.
+5. Require `model.inp`, `metadata.json`, `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv`, and `README.md` unless explicitly not applicable.
+6. Define optional `strains.csv` and `energy_or_residual.csv` only when upstream acceptance criteria require them.
 7. Define metadata provenance, units, coordinate system, output requests, artifact status, and limitations.
 8. Build a Coverage Matrix mapping requirement id, model id, compared quantity, artifact file, tolerance, verification method, and status.
 
@@ -42,8 +42,7 @@ Produce or revise `docs/reference-models/<feature-id>-reference-models.md` with:
 - Abaqus Input Requirements
 - Artifact Bundle Contract
 - Metadata JSON Contract
-- Reference HDF5 Requirements
-- Optional CSV Export Requirements
+- Reference CSV Requirements
 - Coverage Matrix
 - Artifact Acceptance Checklist
 - Open Issues and Downstream Handoff
@@ -54,7 +53,7 @@ Produce or revise `docs/reference-models/<feature-id>-reference-models.md` with:
 - Do not implement parsers.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not compare solver results.
 - Do not approve release readiness.
 
@@ -62,9 +61,9 @@ Produce or revise `docs/reference-models/<feature-id>-reference-models.md` with:
 
 - Every `must` requirement maps to at least one model and compared quantity.
 - `model.inp` stays within the supported Abaqus keyword subset or records an open issue.
-- `metadata.json` includes provenance, Abaqus version/source, units, coordinate system, tolerance, and HDF5 schema version.
-- Missing required HDF5 artifacts keep the model at `needs-reference-artifacts`.
+- `metadata.json` includes provenance, Abaqus version/source, units, coordinate system, tolerance, and CSV schema version.
+- Missing required CSVs keep the model at `needs-reference-artifacts`.
 
 ## Handoff
 
-Send model order and tests that should fail first to Implementation Planning Agent. Send HDF5 schema, matching, output location, and tolerance mapping to Reference Verification Agent. Send physical expectations to Physics Evaluation Agent.
+Send model order and tests that should fail first to Implementation Planning Agent. Send schema, matching, output location, and tolerance mapping to Reference Verification Agent. Send physical expectations to Physics Evaluation Agent.

.codex/skills/fesa-release-readiness/SKILL.md

@@ -12,7 +12,7 @@ Use this skill to audit whether a solver feature is ready for internal release c
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
 - `docs/releases/README.md`
 - Physics Evaluation report with `pass-for-release-agent`
 - Reference Verification report with `pass-for-physics-evaluation`
@@ -50,7 +50,7 @@ Produce or revise `docs/releases/<feature-id>-release.md` with:
 - Do not implement code.
 - Do not edit source code, tests, CMake files, requirements, formulations, I/O contracts, reference artifacts, or tolerance policies.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not override failed or missing gates.
 - Do not publish, deploy, package, tag, commit, or externally release anything unless the user explicitly asks.
 

.codex/skills/fesa-requirements-baseline/SKILL.md

@@ -1,18 +1,18 @@
 ---
 name: fesa-requirements-baseline
-description: Use when analyzing new FESA solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, and a requirement verification matrix before research, formulation, reference modeling, or implementation planning.
+description: Use when defining FESA solver feature requirements, acceptance criteria, tolerance decisions, verification quantities, and a requirement verification matrix before research, formulation, reference modeling, or implementation planning.
 ---
 
-# FESA New Solver Feature Requirements Analysis
+# FESA Requirements Baseline
 
-Use this skill to turn a new solver feature request into a verifiable new solver feature requirements analysis baseline that downstream agents can use without guessing.
+Use this skill to turn a solver feature request into a verifiable baseline that downstream agents can use without guessing.
 
 ## Inputs
 
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
 - `docs/requirements/README.md`
 - User feature request, target capability, constraints, and known exclusions
 - Existing `docs/requirements/<feature-id>.md` when revising a feature
@@ -20,26 +20,26 @@ Read these first:
 ## Workflow
 
 1. Assign a stable `feature_id` in kebab case.
-2. Analyze purpose, included scope, excluded scope, and analysis definition.
-3. Convert requested behavior into analyzed `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
-4. Analyze and record verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
-5. Analyze and record Tolerance Policy values or mark them `needs-user-decision`.
-6. Analyze and record Reference Artifact Requirements under `references/<feature-id>/`.
-7. Build a Requirement Verification Matrix that maps analyzed requirement, source, verification method, acceptance criteria, tolerance, downstream agents, and status.
+2. Define purpose, included scope, excluded scope, and analysis definition.
+3. Convert requested behavior into `shall` statements with ids like `FESA-REQ-<FEATURE>-###`.
+4. Define verification quantities: displacement, reaction, element force, stress, strain, energy, or residual.
+5. Record Tolerance Policy values or mark them `needs-user-decision`.
+6. Record Reference Artifact Requirements under `references/<feature-id>/`.
+7. Build a Requirement Verification Matrix that maps requirement, source, verification method, acceptance criteria, tolerance, downstream agents, and status.
 8. Keep unresolved decisions visible as open issues; do not hide gaps behind vague wording.
 
 ## Output Contract
 
-Produce or revise `docs/requirements/<feature-id>.md` as a new solver feature requirements analysis document with:
+Produce or revise `docs/requirements/<feature-id>.md` with:
 
-- Metadata with `feature_id`, analysis status, owner agent, and date
+- Metadata with `feature_id`, status, owner agent, and date
 - Purpose, In Scope, Out Of Scope, and Analysis Definition
 - Input and Output Requirements
 - Verification Quantities
 - Tolerance Policy
 - Reference Artifact Requirements
 - Requirement Verification Matrix
-- Open Questions and Downstream Handoff from the requirements analysis
+- Open Questions and Downstream Handoff
 
 ## Boundaries
 
@@ -47,14 +47,14 @@ Produce or revise `docs/requirements/<feature-id>.md` as a new solver feature re
 - Do not write finite element formulations.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 
 ## Quality Gate
 
-- Every `must` requirement analyzed in the document has a verification method and acceptance criteria.
-- Every numerical requirement analyzed in the document has units, coordinate system, and tolerance or an explicit owner for the decision.
-- Every reference-comparison requirement analyzed in the document names required artifacts.
+- Every `must` requirement has a verification method and acceptance criteria.
+- Every numerical requirement has units, coordinate system, and tolerance or an explicit owner for the decision.
+- Every reference-comparison requirement names required artifacts.
 - Words like "accurate", "fast", and "Abaqus-like" are converted into measurable criteria or open questions.
 
 ## Handoff

.codex/skills/fesa-requirements-baseline/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
-  display_name: "FESA Requirements Analysis"
-  short_description: "Analyze new solver requirements"
-  default_prompt: "Use $fesa-requirements-baseline to analyze new FESA solver feature requirements."
+  display_name: "FESA Requirements Baseline"
+  short_description: "Define solver requirements"
+  default_prompt: "Use $fesa-requirements-baseline to define verifiable FESA solver requirements."

.codex/skills/fesa-research-evidence/SKILL.md

@@ -12,7 +12,7 @@ Use this skill to collect source-backed evidence for solver features while separ
 Read these first:
 
 - `AGENTS.md`
-- `docs/AGENT_RULES.md`
+- `docs/SOLVER_AGENT_DESIGN.md`
 - `docs/research/README.md`
 - `docs/requirements/<feature-id>.md`
 - User-supplied books, papers, manuals, or benchmark constraints
@@ -46,7 +46,7 @@ Produce or revise `docs/research/<feature-id>-research.md` with:
 - Do not finalize FEM formulations.
 - Do not design C++ APIs or file ownership.
 - Do not run Abaqus, Nastran, or any reference solver.
-- Do not generate reference HDF5 artifacts or reference CSVs.
+- Do not generate reference CSVs.
 - Do not approve release readiness.
 
 ## Quality Gate

AGENTS.md

@@ -1,115 +1,36 @@
-# Project: FESA Structural Solver
-
-## 목적
-FESA는 Abaqus, Nastran 같은 유한요소법 기반 구조해석 솔버를 C++17/MSVC 환경에서 개발하는 프로젝트다. 현재 우선 대상은 MITC4 4절점 shell element 기반 선형정적 구조해석 기능이다.
+# Project: FESA Harness
 
 ## 기술 스택
 - C++17 이상
 - MSVC on Windows
 - CMake + CTest
-- Intel oneAPI MKL: CSR matrix와 PARDISO 선형해법
-- Intel oneAPI TBB: 병렬 요소 계산과 병렬 후처리
-- HDF5 C library: 해석 결과와 reference 결과 저장. 현재 로컬 기본 설치 경로는 `C:\Program Files\HDF_Group\HDF5\2.1.1`이다.
-- Python 3: Harness, validation, phase execution, self-test
+- Harness scripts in Python 3
 
-## Git 저장소
-- Canonical remote repository: `https://teagit.mimi1011.synology.me/baram2584/FESADev.git`
-- 기본 remote 이름은 `origin`으로 사용한다.
-- 현재 공유 기준 브랜치는 `dev`이며, 새 작업 브랜치는 특별한 지시가 없으면 `codex/<short-task-name>` 형식을 사용한다.
-- 새 환경에서 시작할 때는 `git remote -v`로 remote를 확인하고, 없으면 `git remote add origin https://teagit.mimi1011.synology.me/baram2584/FESADev.git`로 등록한다.
-- push, tag, release, 외부 배포는 사용자가 명시적으로 요청하거나 승인한 경우에만 수행한다.
-- 현재 사용자 지시에 따라 Agent가 수행한 작업 범위의 commit/push는 지속 승인된 것으로 취급한다. 작업 완료 후 검증하고, Agent가 만든 변경만 stage/commit한 뒤 `origin`에 push한다.
-
-## 기본 개발 워크플로우
-솔버 기능 개발은 아래 순서를 기본으로 한다.
-
-1. 새로운 솔버 기능 요구조건 분석
-2. 책, 논문 등 연구자료 조사
-3. 코드 구현을 위한 유한요소 정식화
-4. 솔버 입출력 데이터 정의
-5. TDD 방법 사용을 위한 개발 솔버와 reference 솔버 테스트모델 작성
-6. 코드 구현
-7. reference 솔버의 해석 결과와 구현 솔버의 해석 결과 비교 검증
-8. 결과 차이가 tolerance 범위 내에 들어오면 구현 완료
-9. 솔버 기능 배포
-
-각 단계 산출물은 `docs/requirements/`, `docs/research/`, `docs/formulations/`, `docs/io-definitions/`, `docs/reference-models/`, `docs/implementation-plans/`, `docs/reference-verifications/`, `docs/releases/` 아래에 기록한다.
-
-## 검증 기준
+## 아키텍처 규칙
 - CRITICAL: 기본 검증 경로는 `python scripts/validate_workspace.py`이다.
 - CRITICAL: C++ 빌드는 CMake/MSVC/x64/Debug 기준으로 검증한다.
 - CRITICAL: 새 기능 또는 동작 변경은 테스트를 먼저 작성하고 실패를 확인한 뒤 구현한다.
-- CRITICAL: C++ production file을 변경할 때는 관련 C++ test file이 같은 변경 또는 기존 코드에 있어야 한다.
-- CRITICAL: Abaqus, Nastran, reference solver는 agent가 직접 실행하지 않는다. 사람이 생성하거나 승인된 절차로 생성한 reference artifact만 사용한다.
-- CRITICAL: 해석 결과 비교 tolerance는 단일 기준 `1e-5`를 사용한다. 각 성분은 `abs(error) <= 1e-5` 또는 `relative(error) <= 1e-5`를 만족해야 한다.
+- CRITICAL: Abaqus reference artifact나 solver 코드 복원은 명시적으로 요청된 phase에서만 수행한다.
+- Codex custom agent의 `model_reasoning_effort` 기본값은 `extra high`로 둔다.
+- Harness runner는 `scripts/execute.py`에 둔다.
+- Codex hook 정책은 `.codex/hooks/`에 둔다.
+- Harness planning/review instructions are stored in `.codex/skills/`.
+- Generated phase execution outputs remain ignored under `phases/**/step*-output.json`.
 
-## Agent Coordination Files
-여러 AI Agent가 나눠서 작업할 때 `docs/PLAN.md`, `docs/PROGRESS.md`, `docs/WORKNOTE.md`를 공통 handoff 파일로 사용한다.
-
-새 세션을 시작하는 Agent는 코드나 문서를 수정하기 전에 반드시 아래 순서로 읽는다.
-
-1. `AGENTS.md`
-2. `docs/PLAN.md`
-3. `docs/PROGRESS.md`
-4. `docs/WORKNOTE.md`
-5. `docs/AGENT_RULES.md`
-6. 현재 작업과 직접 관련된 `docs/` 산출물
-
-각 파일의 책임:
-- `docs/PLAN.md`: 전체 작업 목표, 단계별 계획, 작업 순서, acceptance criteria, 담당 가능 Agent, 차단 조건을 관리한다.
-- `docs/PROGRESS.md`: 지금까지 완료된 일, 진행 중인 일, 다음에 해야 할 일, 마지막 검증 결과, 열린 blocker를 관리한다.
-- `docs/WORKNOTE.md`: 작업 중 실수, 시행착오, 실패 원인, 되돌아간 결정, 다음 Agent가 피해야 할 함정을 기록한다.
-
-업데이트 규칙:
-- 작업 범위나 단계 계획이 바뀌면 `docs/PLAN.md`를 갱신한다.
-- 의미 있는 작업을 완료하거나 검증을 실행하면 `docs/PROGRESS.md`를 갱신한다.
-- 실수, 실패한 접근, 환경 문제, 반복되면 안 되는 시행착오가 있으면 `docs/WORKNOTE.md`에 날짜와 함께 추가한다.
-- 다른 Agent나 사용자가 남긴 기록은 삭제하거나 덮어쓰지 않는다. 필요한 경우 새 dated entry로 정정한다.
-- 파일 내용과 사용자의 최신 지시가 충돌하면 최신 사용자 지시를 우선하고, 충돌 내용을 `docs/PROGRESS.md` 또는 `docs/WORKNOTE.md`에 남긴다.
-- 세 파일에는 비밀정보, license key, 개인 토큰, machine-local credential을 기록하지 않는다.
-
-## MITC4 초기 구현 범위
-- Feature id: `mitc4-linear-static-shell`
-- Analysis: linear static, small displacement/small rotation
-- Element: 4-node MITC4 shell, 6 DOF per node
-- DOF order: `U1, U2, U3, UR1, UR2, UR3`
-- Material/section: single-layer isotropic linear elastic shell section
-- Input: Abaqus `.inp` subset
-- Output: HDF5 result file
-- Reference: stored Abaqus S4R primary reference; Abaqus S4 is diagnostic
-- Required compared quantities: nodal displacement, reaction, element internal force/resultant, stress
-
-## Architecture Rules
-- OpenSees와 유사하게 `Domain`, `Node`, `Element`, `Material/Section`, `Analysis`, `SystemOfEqn`, `Recorder/ResultWriter` 책임을 분리한다.
-- OpenSees source 구조는 참고하되 raw pointer ownership이나 과도한 inheritance는 복제하지 않는다. FESA는 C++17 RAII와 명확한 ownership을 사용한다.
-- Element 계산, assembly, solver, I/O, reference comparison은 테스트 가능한 작은 모듈로 분리한다.
-- `Domain`은 입력 모델 정의를 보존하고 파싱 이후 가능한 한 불변으로 취급한다.
-- 해석 중 변하는 값은 `AnalysisState`에 둔다. Node/Element/Domain에 solver state나 equation id를 분산 저장하지 않는다.
-- 현재 step의 실행 view는 `AnalysisModel`로 분리한다.
-- Abaqus keyword와 내부 객체 생성은 parser 본체가 아니라 factory/registry 계층으로 분리한다.
-- MKL, TBB, HDF5 직접 호출은 adapter 계층 뒤에 둔다.
-- TBB 병렬화는 deterministic 결과를 유지해야 한다. 전역 조립은 thread-local contribution을 만든 뒤 deterministic merge를 수행한다.
-- MKL PARDISO와 TBB thread oversubscription을 피하기 위해 thread count 정책을 기록한다.
-- HDF5 writer는 HDF5 C API 위에 FESA 내부 RAII wrapper를 둔다.
-- HDF5 discovery는 `HDF5_ROOT=C:\Program Files\HDF_Group\HDF5\2.1.1` 또는 `HDF5_DIR=C:\Program Files\HDF_Group\HDF5\2.1.1\cmake`를 우선 사용한다. 둘 다 없을 때만 CMake 기본 검색 경로에 맡긴다.
-- 경계조건은 constrained DOF 제거 방식으로 적용하고, reaction은 full vector 기준 `K_full * U_full - F_full`로 계산한다.
-- 기본 실수 precision은 `double`이고, id/index/equation numbering은 int64 기반으로 설계한다.
-- 단위계는 강제하지 않으며, 결과 부호와 shell output component naming은 Abaqus 규약을 따른다.
-- Mesh quality 진단은 1차 범위에서 제외하지만 singular system 진단은 필수다.
+## 개발 프로세스
+- TDD를 기본으로 한다. C++ production file을 바꿀 때는 관련 C++ test file이 있어야 한다.
+- 커밋 전 hook은 Harness Python self-test와 workspace validation을 실행해야 한다.
+- 커밋 메시지는 conventional commits 형식을 따른다: `feat:`, `fix:`, `docs:`, `refactor:`, `test:`.
+- 계획이 필요한 장기 작업은 Harness phase로 나누고, 각 step은 독립 실행 가능해야 한다.
 
 ## 명령어
-```powershell
+```bash
 python -m unittest discover -s scripts -p "test_*.py"
 python scripts/validate_workspace.py
 python scripts/execute.py <phase-dir>
 python scripts/execute.py <phase-dir> --push
 ```
 
-MITC4 CTest 예시:
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -L mitc4
-```
-
 ## MSVC 검증 기본값
 - Generator: `Visual Studio 17 2022`
 - Platform: `x64`
@@ -122,14 +43,3 @@ Override variables:
 - `HARNESS_CMAKE_PLATFORM`
 - `HARNESS_CMAKE_CONFIG`
 - `HARNESS_BUILD_DIR`
-- `MKLROOT`
-- `TBBROOT`
-- `HDF5_ROOT`
-- `HDF5_DIR`
-
-## 커밋 및 문서화
-- 커밋 전 hook은 Harness Python self-test와 workspace validation을 실행해야 한다.
-- 커밋 메시지는 conventional commits 형식을 따른다: `feat:`, `fix:`, `docs:`, `refactor:`, `test:`.
-- 커밋 전에는 `git status --short --branch`와 `git remote -v`로 작업 브랜치와 remote가 의도한 상태인지 확인한다.
-- 계획이 필요한 장기 작업은 Harness phase로 나누고, 각 step은 독립 실행 가능해야 한다.
-- Generated phase execution outputs remain ignored under `phases/**/step*-output.json`.

CMakeLists.txt

@@ -1,74 +0,0 @@
-cmake_minimum_required(VERSION 3.20)
-
-project(FESA LANGUAGES CXX)
-
-set(CMAKE_CXX_STANDARD 17)
-set(CMAKE_CXX_STANDARD_REQUIRED ON)
-set(CMAKE_CXX_EXTENSIONS OFF)
-
-add_library(fesa_core STATIC
-    src/boundary/SinglePointConstraint.cpp
-    src/core/AnalysisState.cpp
-    src/core/Domain.cpp
-    src/element/Mitc4Element.cpp
-    src/io/Hdf5ResultWriter.cpp
-    src/load/NodalLoad.cpp
-    src/material/LinearElasticMaterial.cpp
-    src/property/ShellProperty.cpp
-)
-target_include_directories(fesa_core PUBLIC
-    ${CMAKE_CURRENT_SOURCE_DIR}/include
-)
-
-enable_testing()
-
-add_executable(fesa_domain_tests
-    tests/core/boundary_condition_test.cpp
-    tests/core/domain_bootstrap_test.cpp
-    tests/core/domain_model_object_test.cpp
-    tests/core/domain_storage_test.cpp
-    tests/core/element_definition_test.cpp
-    tests/core/load_definition_test.cpp
-    tests/core/material_definition_test.cpp
-    tests/core/model_types_test.cpp
-    tests/core/node_test.cpp
-    tests/core/property_definition_test.cpp
-    tests/core/step_definition_test.cpp
-)
-target_link_libraries(fesa_domain_tests PRIVATE fesa_core)
-
-add_test(NAME domain.bootstrap COMMAND fesa_domain_tests)
-set_tests_properties(domain.bootstrap PROPERTIES LABELS "domain;core")
-
-add_executable(fesa_model_object_tests
-    tests/boundary/boundary_base_test.cpp
-    tests/element/element_base_test.cpp
-    tests/element/mitc4_element_model_test.cpp
-    tests/load/load_base_test.cpp
-    tests/material/material_base_test.cpp
-    tests/model_object_main.cpp
-    tests/property/property_base_test.cpp
-    tests/property/shell_property_test.cpp
-)
-target_link_libraries(fesa_model_object_tests PRIVATE fesa_core)
-
-add_test(NAME model-object.base COMMAND fesa_model_object_tests)
-set_tests_properties(model-object.base PROPERTIES LABELS "model-object;core")
-
-add_executable(fesa_io_tests
-    tests/io/hdf5_result_writer_test.cpp
-)
-target_link_libraries(fesa_io_tests PRIVATE fesa_core)
-
-add_test(NAME io.hdf5-result-writer COMMAND fesa_io_tests)
-set_tests_properties(io.hdf5-result-writer PROPERTIES LABELS "io;hdf5")
-
-add_executable(fesa_analysis_tests
-    tests/analysis/analysis_base_test.cpp
-    tests/analysis/analysis_test_main.cpp
-    tests/core/analysis_state_test.cpp
-)
-target_link_libraries(fesa_analysis_tests PRIVATE fesa_core)
-
-add_test(NAME analysis.base COMMAND fesa_analysis_tests)
-set_tests_properties(analysis.base PROPERTIES LABELS "analysis;core")

docs/ADR.md

@@ -1,106 +1,34 @@
 # Architecture Decision Records
 
-## ADR-001: Solver Development Workflow Is Stage-Gated
-**Decision**: FESA solver features must follow this workflow: requirements, research, formulation, I/O contract, TDD reference models, implementation, reference comparison, tolerance decision, release.
+## 철학
+Harness는 현재 프로젝트의 실제 기술 스택을 반영해야 한다. C++/MSVC 프로젝트에서 npm, Next.js, TypeScript test naming을 기본값으로 두면 agent prompt와 hook policy가 잘못된 구현을 유도한다.
 
-**Reason**: Structural solver correctness depends on more than code execution. Requirements, mathematical formulation, input/output contracts, reference artifacts, numerical comparison, and release evidence must be traceable.
+---
 
-**Tradeoff**: Initial feature delivery is slower. The benefit is that implementation agents do not invent formulation, tolerance, or reference assumptions during coding.
+### ADR-001: C++ 전용 Harness
+**결정**: Harness scaffold는 C++/MSVC 전용으로 운영한다. JavaScript/TypeScript fallback은 유지하지 않는다.
 
-## ADR-002: C++17/MSVC/CMake/CTest Remain The Baseline
-**Decision**: The project targets C++17 or newer, MSVC on Windows, CMake, and CTest. Default validation uses Visual Studio 17 2022, x64, Debug.
+**이유**: FESA 개발 환경은 MSVC 기반 C++이다. 언어별 fallback을 남기면 validation, TDD guard, acceptance criteria가 흐려진다.
 
-**Reason**: The project is a Windows/MSVC structural solver. CMake/CTest gives a consistent build and test entry point for both harness validation and feature development.
+**트레이드오프**: 같은 Harness scaffold를 JS/TS 프로젝트에 재사용할 수 없다. 필요하면 별도 template이나 language registry를 새 ADR로 설계한다.
 
-**Tradeoff**: Visual Studio solution-only workflows and non-MSVC toolchains are not the primary path. They can be introduced by explicit ADR when needed.
+### ADR-002: CMake/MSVC/x64/Debug 기본 검증
+**결정**: 기본 workspace validation은 CMake, Visual Studio 17 2022 generator, x64 platform, Debug config, CTest로 수행한다.
 
-## ADR-003: MITC4 Linear Static Shell Is The Initial Solver Feature
-**Decision**: The first solver implementation target is `mitc4-linear-static-shell`: a 4-node MITC4 shell element for linear static structural analysis.
+**이유**: MSVC 환경에서 CMake/CTest는 source tree가 복원되거나 새 C++ project가 추가될 때 가장 일관된 build/test entry point다.
 
-**Reason**: MITC4 is a meaningful shell element target with strong research and OpenSees reference structure. It exercises element formulation, assembly, solver, I/O, and reference verification without immediately requiring nonlinear or dynamic analysis.
+**트레이드오프**: Visual Studio solution-only project는 기본 지원하지 않는다. 명시적으로 필요하면 `HARNESS_VALIDATION_COMMANDS`로 override한다.
 
-**Tradeoff**: This is more complex than a truss/bar bootstrap. The project accepts the complexity because MITC4 is the requested initial element.
+### ADR-003: 엄격한 C++ TDD Guard
+**결정**: C++ production file 변경은 관련 C++ test file이 없으면 차단한다.
 
-## ADR-004: OpenSees-Inspired Architecture, Modern C++ Ownership
-**Decision**: FESA follows OpenSees-like conceptual boundaries: `Domain`, `Node`, `Element`, `Material/Section`, `Analysis`, `SystemOfEqn`, and `Recorder/ResultWriter`. It does not clone OpenSees raw ownership style.
+**이유**: Harness의 핵심 목적은 agent가 검증 없는 C++ 변경을 만들지 않도록 하는 것이다. Header 중심 C++ 구조에서도 module 또는 basename 기반 테스트 존재를 확인한다.
 
-**Reason**: OpenSees provides a useful solver architecture vocabulary, while modern C++17 RAII gives safer ownership and testable module boundaries.
+**트레이드오프**: 초기 scaffolding 작업에서 guard가 엄격하게 느껴질 수 있다. 문서, CMake 설정, Harness metadata는 guard 대상에서 제외한다.
 
-**Tradeoff**: FESA classes will not be drop-in compatible with OpenSees. Similarity is architectural, not API compatibility.
+### ADR-004: Harness 자체 테스트 우선
+**결정**: commit hook은 먼저 Python Harness self-test를 실행한 뒤 workspace validation을 실행한다.
 
-## ADR-005: MKL PARDISO For Global Linear Solves
-**Decision**: FESA uses Intel oneAPI MKL CSR matrices and PARDISO for the initial global linear static solve.
+**이유**: 현재 저장소에는 C++ source tree가 없을 수 있다. Harness가 스스로 검증 가능해야 이후 phase generation과 source restoration을 안전하게 진행할 수 있다.
 
-**Reason**: Shell models need sparse linear algebra beyond toy dense solvers. MKL is already aligned with the Windows/MSVC toolchain and provides production-grade direct sparse solving.
-
-**Tradeoff**: oneAPI MKL becomes a required dependency for real solver builds. The CMake configuration must detect `MKLROOT` or a known oneAPI installation path.
-
-## ADR-006: TBB For Parallel Element Work
-**Decision**: FESA uses Intel oneAPI TBB for parallel element stiffness, residual/result recovery, and other embarrassingly parallel solver phases.
-
-**Reason**: Element-level computation is a natural parallelism boundary. TBB integrates with oneAPI and avoids designing a custom thread pool.
-
-**Tradeoff**: Global assembly must be deterministic. FESA will use thread-local contribution buffers and deterministic merge rather than concurrent writes into global CSR arrays.
-
-## ADR-007: HDF5 For Solver And Reference Results
-**Decision**: FESA writes solver results to HDF5 and compares against stored HDF5 reference artifacts.
-
-**Reason**: Shell results contain structured mesh, step/frame, nodal, element, Gauss point, resultant, stress, metadata, and tolerance data. HDF5 is better suited than flat CSV for this result hierarchy.
-
-**Tradeoff**: HDF5 becomes a required dependency. FESA will provide an internal RAII wrapper over the HDF5 C API, but the actual HDF5 C library must be supplied by `HDF5_ROOT` or `HDF5_DIR`. The current local Windows install is `C:\Program Files\HDF_Group\HDF5\2.1.1`; use `HDF5_ROOT` for that root or `HDF5_DIR` for `C:\Program Files\HDF_Group\HDF5\2.1.1\cmake`.
-
-## ADR-008: Single Tolerance Policy
-**Decision**: Reference comparison uses a single tolerance value `1e-5`. A compared scalar passes when absolute error or relative error is within `1e-5`.
-
-**Reason**: A single tolerance policy is simple, explicit, and matches the current project decision.
-
-**Tradeoff**: Quantity-specific scaling is deferred. If future models show that one global tolerance is too strict or too loose for some quantities, a new ADR must revise this policy.
-
-## ADR-009: Agents Do Not Run Reference Solvers
-**Decision**: Abaqus, Nastran, and other reference solvers are not run by agents. Agents only consume stored reference artifacts.
-
-**Reason**: Reference solver execution requires licensing, environment control, provenance, and human approval. Stored artifacts make validation reproducible inside the harness.
-
-**Tradeoff**: Implementation can be blocked until required reference artifacts are supplied.
-
-## ADR-010: Domain, AnalysisModel, And AnalysisState Are Separate
-**Decision**: `Domain` owns the validated runtime model object graph created from parsed input, `AnalysisModel` owns the active step execution view, and `AnalysisState` owns mutable solution and iteration state.
-
-**Reason**: This prevents parser DTOs, equation ids, displacement vectors, residuals, and future nonlinear/time states from leaking into the persistent domain model. It also keeps the static solver compatible with future nonlinear, dynamic, and thermal workflows.
-
-**Tradeoff**: The initial implementation has more object boundaries than a single monolithic model container.
-
-## ADR-011: Factory/Registry Handles Input Object Creation
-**Decision**: Abaqus keyword parsing and internal object creation are separated through factory/registry mechanisms.
-
-**Reason**: Adding elements, materials, loads, boundary conditions, sets, or properties should not require rewriting parser control flow.
-
-**Tradeoff**: The first parser implementation needs a small registry layer before many object types exist.
-
-## ADR-012: Boundary Conditions Use DOF Elimination
-**Decision**: Essential boundary conditions are applied by constrained DOF elimination. Reactions are recovered from the full system as `K_full * U_full - F_full`.
-
-**Reason**: This gives a clear reduced solve while preserving physically meaningful reaction recovery for reference comparison.
-
-**Tradeoff**: The implementation must preserve enough full-system information for reaction recovery instead of only storing the reduced matrix.
-
-## ADR-013: Results Use Step/Frame/Field/History Model
-**Decision**: HDF5 results are organized by step, frame, field output, and history output.
-
-**Reason**: The same result model can support static, nonlinear, dynamic, heat-transfer, and thermal-stress analyses.
-
-**Tradeoff**: The v0 linear static output is more structured than a flat single-step result file.
-
-## ADR-014: Double Precision And 64-Bit Numbering
-**Decision**: Solver scalar calculations use `double`; ids, sparse indices, and equation numbering are designed around int64 boundaries.
-
-**Reason**: Structural solver verification needs double precision, and large sparse systems should not be blocked by 32-bit numbering assumptions.
-
-**Tradeoff**: Memory use may be higher than a 32-bit-only implementation.
-
-## ADR-015: Units Are User-Consistent, Not Enforced
-**Decision**: FESA does not enforce a unit system. Inputs and reference artifacts must be unit-consistent and record units in metadata.
-
-**Reason**: Abaqus-style workflows commonly rely on user-consistent units.
-
-**Tradeoff**: The solver cannot automatically detect every unit mismatch. Reference metadata and validation reports must make unit assumptions visible.
+**트레이드오프**: commit 시간이 조금 늘어난다. 대신 hook/validation regressions를 빠르게 잡는다.

docs/AGENT_RULES.md

@@ -1,102 +0,0 @@
-# FESA Agent Rules
-
-## Purpose
-This document contains the common rules every FESA AI Agent must read before doing project work. The broader solver agent design document is background material, not a required per-run rules file.
-
-## Required Startup Context
-Before changing code or documents, every Agent must read:
-
-1. `AGENTS.md`
-2. `docs/PLAN.md`
-3. `docs/PROGRESS.md`
-4. `docs/WORKNOTE.md`
-5. `docs/AGENT_RULES.md`
-6. The task-specific upstream documents under `docs/requirements/`, `docs/research/`, `docs/formulations/`, `docs/io-definitions/`, `docs/reference-models/`, `docs/implementation-plans/`, or related phase folders.
-
-## Repository Defaults
-- Canonical remote repository: `https://teagit.mimi1011.synology.me/baram2584/FESADev.git`
-- Use `origin` as the default remote name.
-- The current shared baseline branch is `dev`.
-- Use `codex/<short-task-name>` for new work branches unless the user requests a different branch.
-- At session start, verify repository state with `git status --short --branch` and verify the remote with `git remote -v`.
-- If a fresh checkout has no remote, add it with `git remote add origin https://teagit.mimi1011.synology.me/baram2584/FESADev.git`.
-- Do not push, tag, release, or publish externally unless the user explicitly requests or approves it.
-
-## Global Solver Workflow
-All solver features follow this stage-gated workflow:
-
-1. Analyze new solver feature requirements.
-2. Research books, papers, manuals, benchmarks, and reference implementations.
-3. Write FEM formulation for implementation.
-4. Define solver input and output data.
-5. Prepare TDD test models and reference solver artifact contracts.
-6. Implement code test-first.
-7. Compare FESA results against stored reference solver results.
-8. Mark implementation complete only when the tolerance policy passes.
-9. Prepare release evidence.
-
-Do not skip upstream gates by inventing missing requirements, formulations, tolerances, I/O schemas, or reference artifacts during implementation.
-
-## Common Boundaries
-- Do not run Abaqus, Nastran, or any reference solver unless the user explicitly authorizes a separate reference-generation phase.
-- Do not generate or edit reference artifacts unless the current task is explicitly a reference artifact preparation task.
-- Do not approve release readiness from build success alone.
-- Do not treat successful execution as numerical correctness.
-- Do not change tolerance policies, formulations, I/O contracts, or reference model contracts from an implementation or correction task.
-- Do not hide gaps behind words like accurate, Abaqus-like, robust, or production-ready. Convert them into measurable criteria or open issues.
-
-## Required Verification Standard
-- Default validation command: `python scripts/validate_workspace.py`.
-- Harness self-test command: `python -m unittest discover -s scripts -p "test_*.py"`.
-- C++ validation target: CMake + MSVC + x64 + Debug + CTest.
-- C++ production changes require related C++ tests.
-- New behavior must follow RED -> GREEN -> VERIFY unless the task is documentation-only.
-- Current MITC4 comparison tolerance is a single value `1e-5`; each compared scalar passes when `abs(error) <= 1e-5` or `relative(error) <= 1e-5`.
-
-## Handoff Files
-Use the shared handoff files:
-
-- `docs/PLAN.md`: overall plan, sequencing, acceptance criteria, and blockers.
-- `docs/PROGRESS.md`: completed work, current state, next tasks, and latest validation.
-- `docs/WORKNOTE.md`: mistakes, failed approaches, environment traps, and lessons for future Agents.
-
-Update rules:
-- Update `docs/PLAN.md` when scope, ordering, acceptance criteria, or blockers change.
-- Update `docs/PROGRESS.md` after meaningful completion or validation.
-- Update `docs/WORKNOTE.md` after mistakes, failed approaches, repeated failures, environment traps, or decisions that future Agents should not rediscover.
-- Do not delete another Agent's dated note unless the user explicitly requests it.
-- If handoff files conflict with the newest user instruction, follow the newest user instruction and record the conflict.
-
-## Failure Routing
-When work fails, classify the failure before fixing:
-
-- requirements ambiguity
-- research/evidence gap
-- formulation defect
-- numerical review issue
-- I/O schema mismatch
-- missing or invalid reference artifact
-- implementation defect
-- build/configuration failure
-- reference comparison tolerance failure
-- physics plausibility failure
-- release readiness gap
-
-Repeated failures must be routed back to the owning upstream stage instead of continuing an unbounded correction loop.
-
-## Agent Output Discipline
-- Each Agent writes the artifact for its stage and records downstream handoff items.
-- Every must requirement needs a verification method and acceptance criteria.
-- Every formulation needs clear DOF, coordinate, unit, sign, Jacobian, integration, and recovery rules.
-- Every I/O contract needs supported syntax, unsupported behavior, internal mapping, HDF5 result schema or explicitly approved CSV export schema, units, component names, and matching rules.
-- Every reference model contract needs model purpose, compared quantities, artifacts, provenance, and limitations.
-- Every implementation plan needs test-first tasks, target commands, candidate files, and traceability to upstream requirements.
-- Every verification report needs compared rows, missing/extra rows, max absolute error, max relative error, worst id/component, pass/fail, and failure classification.
-
-## Current Project Defaults
-- Initial feature id: `mitc4-linear-static-shell`.
-- Initial result/reference format: HDF5.
-- Local HDF5 default install: `C:\Program Files\HDF_Group\HDF5\2.1.1`; use `HDF5_ROOT` for this root or `HDF5_DIR` for `C:\Program Files\HDF_Group\HDF5\2.1.1\cmake`.
-- Reference policy: stored Abaqus S4R is primary for pass/fail; Abaqus S4 is diagnostic.
-- Required compared quantities: nodal displacement, reaction, element internal force/resultant, and stress.
-- Agents must preserve OpenSees-inspired architecture while using modern C++17 RAII and FESA ownership boundaries.

docs/ARCHITECTURE.md

@@ -1,329 +1,58 @@
-# FESA Solver Architecture
+# 아키텍처
 
 ## 목표
-FESA는 C++17/MSVC 기반 유한요소 구조해석 솔버다. 초기 구현은 MITC4 4절점 shell element의 선형정적 해석이며, 이후 비선형 정적해석, 비선형 동적해석, 열전달 및 thermal-stress coupling, 1D/3D 요소로 확장한다.
+이 저장소의 현재 책임은 C++/MSVC 프로젝트를 위한 Codex Harness scaffold를 제공하는 것이다. Harness는 phase execution, edit guard, commit validation, workspace validation을 분리해서 관리한다.
 
-초기 구현은 정확도와 테스트 가능성을 우선한다. 단, 대규모 모델을 목표로 하므로 자유도 관리, 희소 행렬 조립, 선형 솔버, 병렬 실행 계층은 초기부터 성능 확장이 가능하도록 분리한다.
-
-## 개발 프로세스 구조
+## 디렉토리 구조
 ```text
-Feature request
--> requirements
--> research evidence
--> FEM formulation
--> I/O contract
--> reference model and artifact contract
--> TDD implementation plan
--> C++ implementation
--> build/test validation
--> HDF5 reference comparison
--> physics/release review
+.codex/
+├── hooks/              # Codex hook scripts
+└── skills/             # Harness planning/review instructions
+docs/                   # Project and Harness guidance
+scripts/
+├── execute.py          # Phase step executor
+├── validate_workspace.py
+└── test_*.py           # Harness self-tests
+phases/                 # Optional generated phase plans
 ```
 
-## 설계 원칙
-- `Domain`은 입력 모델의 의미를 보존하고 파싱 이후 가능한 한 불변에 가깝게 유지한다.
-- 해석 중 변하는 물리량과 반복 상태는 `AnalysisState`에 명시적으로 분리한다.
-- 현재 step에서 활성화되는 실행 view는 `AnalysisModel`이 담당하며, `Domain`을 복사하지 않는다.
-- 요소, 재료, 하중, 경계조건, 해석 알고리즘은 런타임 다형성 기반으로 확장한다.
-- 결과는 step/frame/field/history 개념으로 저장하여 정적, 비선형, 동적, 열전달 해석을 같은 결과 모델로 다룬다.
-- 외부 라이브러리인 MKL, TBB, HDF5는 adapter 계층 뒤에 둔다.
-- Abaqus input 호환성은 parser와 factory/registry 계층에서 관리한다.
-- shell node는 6자유도이고, 결과 자유도 순서는 `U1, U2, U3, UR1, UR2, UR3`이다.
-- 단위계는 강제하지 않는다. 입력과 reference artifact metadata에 기록된 일관 단위계를 그대로 사용한다.
-- 결과 부호와 shell output component naming은 Abaqus 규약을 따른다.
-- 경계조건은 constrained DOF 제거 방식으로 적용하고, reaction은 full vector 기준 `K_full * U_full - F_full`로 계산한다.
-- 기본 실수 precision은 `double`이다.
-- 대규모 모델을 위해 id, index, equation numbering은 int64 기반으로 설계한다.
-- Mesh quality 진단은 1차 범위에서 제외한다. 대신 singular system 진단은 필수로 제공한다.
-
-## Directory Structure
+## 데이터 흐름
 ```text
-include/fesa/
-  analysis/        # Static, nonlinear static, dynamic, heat transfer analysis interfaces
-  assembly/        # Global matrix/vector assembly and sparse pattern creation
-  boundary/        # Fix, RBE2, RBE3 and future constraint objects
-  core/            # Domain, AnalysisModel, AnalysisState, DofManager
-  element/         # Node, Element, MITC4 and future elements
-  io/              # Abaqus input parser and HDF5 result writer
-  load/            # NodalLoad, PressureLoad, BodyForce
-  math/            # Vector, Matrix, SparseMatrix, MKL adapter
-  material/        # LinearElastic and future material models
-  property/        # ShellProperty and 1D/2D/3D properties
-  results/         # ResultStep, ResultFrame, FieldOutput, HistoryOutput
-  util/            # Diagnostics, logging, validation helpers
-  verification/    # HDF5 reference comparison utilities
-
-src/
-  analysis/
-  assembly/
-  boundary/
-  core/
-  element/
-  io/
-  load/
-  math/
-  material/
-  property/
-  results/
-  util/
-  verification/
-
-tests/
-  parser/
-  element/
-  assembly/
-  solver/
-  hdf5/
-  reference/
+User-approved task
+-> Harness phase files under phases/
+-> scripts/execute.py injects AGENTS.md and docs/*.md
+-> Codex executes one step at a time
+-> step updates phases/{phase}/index.json
+-> validation runs through scripts/validate_workspace.py
 ```
 
-The current repository may not yet contain all directories. They are intended ownership boundaries for implementation planning.
-
-## Core Runtime Objects
-- `Domain`: owns the validated runtime model object graph created from input: nodes, elements, materials, properties, sets, boundary conditions, loads, and step definitions.
-- `AnalysisModel`: step-local execution view over active elements, loads, boundary conditions, properties, materials, and equation system view.
-- `AnalysisState`: owns changing physical quantities and iteration/time state such as displacement, velocity, acceleration, temperature, forces, residual, current time, increment, and element/integration-point state.
-- `Node`: stores node id, coordinates, and six DOF values in order `U1, U2, U3, UR1, UR2, UR3`.
-- `Element`: computes local stiffness, internal force/resultants, stress recovery, and connectivity.
-- `ShellMITC4Element`: 4 nodes, 24 DOF, 2x2 Gauss integration, MITC transverse shear interpolation.
-- `Material`: base contract for material behavior.
-- `Property`: element property and section data, including shell thickness.
-- `LinearElasticShellSection`: isotropic elastic shell section with thickness and shear correction.
-- `DofManager`: active DOF definitions, constrained/free DOF mapping, equation numbering, sparse pattern ownership, and full/reduced vector reconstruction.
-- `Assembler`: gathers element contributions into deterministic global sparse data.
-- `SparseMatrix`: internal sparse matrix abstraction backed by MKL-compatible CSR for v0.
-- `LinearSolver`: solver interface implemented initially by `MklPardisoSolver`.
-- `Analysis`: strategy interface for `LinearStaticAnalysis` and future nonlinear/dynamic/thermal analyses.
-- `Hdf5ResultWriter`: writes mesh, metadata, nodal results, element resultants, stresses, field output, and history output.
-- `ReferenceComparator`: compares FESA HDF5 output with stored reference HDF5 artifacts using tolerance `1e-5`.
-
-## State Ownership
-
-### Domain
-`Domain` represents the validated model definition as runtime objects and should not store parser DTOs, equation ids, solver vectors, current displacement, or iteration state.
-
-Included:
-- nodes and elements
-- materials and properties
-- node sets and element sets
-- loads and boundary conditions
-- analysis step definitions
-
-Parser-style definition records may exist as temporary input or factory records, but they are not persistent `Domain` storage. `Domain` owns runtime objects such as `Element`, `Material`, `ShellProperty`, `Load`, and `BoundaryCondition`.
-
-### AnalysisModel
-`AnalysisModel` is built per active step. It references `Domain` objects by id or stable reference and defines what participates in the current solve.
-
-Included:
-- active elements
-- active loads
-- active boundary conditions
-- active property/material references
-- current equation system view
-
-### DofManager
-`DofManager` centralizes all equation numbering. Node or Element objects must not independently own equation ids.
-
-Responsibilities:
-- define active node DOFs
-- map constrained and free DOFs
-- assign equation numbers
-- provide connectivity for sparse matrix pattern generation
-- reconstruct full vectors from reduced solution vectors
-
-### AnalysisState
-`AnalysisState` stores mutable quantities and future nonlinear/time history extension points.
-
-Included:
-- displacement, velocity, acceleration
-- temperature
-- external force, internal force, residual
-- current time, increment, Newton iteration
-- element state and integration point state
-
-Phase 1 uses displacement-centered state only, but the structure must not block geometric nonlinear and thermal-stress extensions.
-
-### Results State
-Results use:
-- `ResultStep`: analysis step result group
-- `ResultFrame`: static load increment or dynamic time frame
-- `FieldOutput`: node/element field results
-- `HistoryOutput`: selected node, element, set, reaction, or energy histories
-
-## Data Flow
+## Hook 흐름
 ```text
-Abaqus input file
--> InputParser
--> temporary parsed records
--> Factory/Registry object creation
--> Domain runtime object graph
--> StepDefinition loop
--> AnalysisModel
--> DofManager
--> sparse pattern creation
--> TBB parallel element stiffness computation
--> deterministic CSR assembly
--> constrained DOF elimination
--> MKL PARDISO solve
--> full displacement vector reconstruction
--> reaction recovery by K_full * U_full - F_full
--> TBB parallel element result recovery
--> HDF5 step/frame/field/history output
--> HDF5 reference comparison
+apply_patch/Edit/Write
+-> .codex/hooks/tdd-guard.py
+-> C++ production changes require related tests
+
+git commit command
+-> .codex/hooks/pre_commit_checks.py
+-> Python Harness self-tests
+-> scripts/validate_workspace.py
 ```
 
-## Patterns
-
-### Strategy
-Used for swappable analysis and numerical algorithms:
-- `Analysis`: `LinearStaticAnalysis`, `NonlinearStaticAnalysis`, `DynamicAnalysis`, `HeatTransferAnalysis`
-- `LinearSolver`: `MklPardisoSolver`, future iterative solver
-- `TimeIntegrator`: future Newmark/HHT
-- `ConvergenceCriteria`: future residual, displacement, and energy norms
-
-### Template Method
-`Analysis::run()` owns the high-level execution order:
+## Validation 흐름
 ```text
-initialize
-buildAnalysisModel
-buildDofMap
-buildSparsePattern
-assemble
-applyBoundaryConditions
-solve
-updateState
-writeResults
+HARNESS_VALIDATION_COMMANDS set
+-> run exact commands
+
+CMakePresets.json has msvc-debug configure preset
+-> cmake --preset msvc-debug
+-> cmake --build preset binary dir --config Debug
+-> ctest --test-dir preset binary dir -C Debug
+
+CMakeLists.txt exists
+-> cmake -S . -B build/msvc-debug -G "Visual Studio 17 2022" -A x64
+-> cmake --build build/msvc-debug --config Debug
+-> ctest --test-dir build/msvc-debug --output-on-failure -C Debug
+
+No CMake project
+-> print guidance and exit successfully
 ```
-
-Nonlinear static analysis will reuse this sequence inside Newton-Raphson loops. Dynamic analysis will reuse it inside time step/frame loops.
-
-### Factory + Registry
-Abaqus input keywords map to internal object factories:
-- `*ELEMENT, TYPE=S4` -> `MITC4ElementFactory`
-- `*ELEMENT, TYPE=S4R` -> `MITC4ElementFactory`
-- `*MATERIAL`, `*ELASTIC` -> `LinearElasticMaterialFactory`
-- `*SHELL SECTION` -> `ShellPropertyFactory`
-- `*BOUNDARY` -> `FixBoundaryFactory`
-- `*CLOAD` -> `NodalLoadFactory`
-- `*NSET`, `*ELSET` -> set registry
-
-Adding an element, material, load, or boundary condition should not require rewriting the parser core.
-
-### Adapter
-MKL, TBB, and HDF5 APIs are not exposed directly to solver core objects.
-
-Adapter targets:
-- `SparseMatrix`, `Vector`, `Matrix`
-- `LinearSolver`
-- `ParallelFor`
-- `ResultsWriter`
-
-This allows test doubles and future dependency replacement without changing solver physics code.
-
-### HDF5 Dependency Discovery
-The current local Windows/MSVC HDF5 installation is:
-
-```text
-C:\Program Files\HDF_Group\HDF5\2.1.1
-```
-
-Implementation planning should use the HDF5 C API through the adapter layer, not the HDF5 C++ API. CMake discovery should prefer one of these explicit environment variables before falling back to default package search:
-
-```powershell
-$env:HDF5_ROOT = "C:\Program Files\HDF_Group\HDF5\2.1.1"
-$env:HDF5_DIR = "C:\Program Files\HDF_Group\HDF5\2.1.1\cmake"
-```
-
-The expected local artifacts are `include\hdf5.h`, `lib\hdf5.lib`, `bin\hdf5.dll`, and `cmake\hdf5-config.cmake`. `h5dump.exe -V` should report HDF5 `2.1.1` on this machine.
-
-### Runtime Polymorphism
-Elements, materials, loads, and boundary conditions are handled through base interfaces. Phase 1 prioritizes clarity and testability. If large-model performance requires it later, assembly internals may add type-specific batch kernels.
-
-## MITC4 Result Contract
-Nodal displacement output:
-```text
-node_id, U1, U2, U3, UR1, UR2, UR3
-```
-
-Nodal reaction output:
-```text
-node_id, RF1, RF2, RF3, RM1, RM2, RM3
-```
-
-Element internal force/resultant output at Gauss points:
-```text
-element_id, gauss_id, xi, eta, N11, N22, N12, M11, M22, M12, Q13, Q23
-```
-
-Stress output:
-```text
-element_id, gauss_id, section_point, S11, S22, S12, S13, S23
-```
-
-## HDF5 Layout
-```text
-/metadata
-  feature_id
-  solver_version
-  model_id
-  hdf5_version
-  schema_version
-  units
-  tolerance
-  reference_solver
-
-/mesh/nodes
-/mesh/elements/mitc4/connectivity
-
-/results/step_000/frame_000/nodal/displacement
-/results/step_000/frame_000/nodal/reaction
-/results/step_000/frame_000/element/forces
-/results/step_000/frame_000/element/stress
-/results/step_000/frame_000/history
-```
-
-## Parallelism And Sparse Assembly
-TBB parallelism is allowed for element-local computations, element force recovery, assembly precompute, and independent postprocessing.
-
-Global assembly must remain deterministic:
-```text
-parallel element loop
--> thread-local sparse contribution buffers
--> stable sort by (row, column)
--> deterministic sum
--> CSR arrays
-```
-
-The sparse matrix path must preserve 64-bit index boundaries so MKL `pardiso_64` can be used for large models.
-
-The solver must avoid uncontrolled MKL/TBB oversubscription. Thread-count decisions are part of analysis metadata and validation reports.
-
-## Validation Flow
-```text
-python scripts/validate_workspace.py
--> CMake configure
--> MSVC Debug build
--> CTest
--> feature-specific reference comparison tests
-```
-
-When no CMake project exists yet, validation may report the harness no-op path. Once solver code is introduced, CMake/CTest validation is mandatory.
-
-## Reference Artifact Flow
-Agents do not run Abaqus or Nastran.
-
-```text
-Human-approved Abaqus run
--> stored HDF5 reference artifact under references/<feature>/<model-id>/
--> FESA solver HDF5 output
--> ReferenceComparator
--> pass/fail using abs-or-rel 1e-5
-```
-
-For `mitc4-linear-static-shell`, Abaqus S4R is primary and S4 is diagnostic.
-
-## Performance Extension Direction
-- Sparse matrix storage is the default global system representation.
-- MKL direct solver is the first supported solver, but `LinearSolver` must allow future iterative solvers.
-- Element stiffness and result recovery should be designed for type-specific batch kernels later, but not optimized before correctness evidence exists.
-- MITC4 formulation should remain clear and reviewable until patch and reference comparisons pass.

docs/PLAN.md

@@ -1,49 +0,0 @@
-# FESA Multi-Agent Plan
-
-## Purpose
-This file tells a new AI Agent what work is planned and how to continue without reconstructing project intent from the full conversation.
-
-New Agents must read `AGENTS.md`, this file, `docs/PROGRESS.md`, `docs/WORKNOTE.md`, and `docs/AGENT_RULES.md` before editing files.
-
-## Active Objective
-Build the FESA structural solver foundation around the initial feature `mitc4-linear-static-shell`.
-
-## Repository Context
-- Canonical remote repository: `https://teagit.mimi1011.synology.me/baram2584/FESADev.git`
-- Default remote name: `origin`
-- Shared baseline branch: `dev`
-- New task branches should use `codex/<short-task-name>` unless the user requests otherwise.
-
-## Current High-Level Plan
-1. Maintain project-level documentation and handoff files.
-2. Analyze new solver feature requirements for `mitc4-linear-static-shell`.
-3. Gather research evidence for MITC4, OpenSees `ShellMITC4`, Abaqus S4/S4R, patch tests, and Scordelis-Lo.
-4. Write FEM formulation for the MITC4 linear static shell feature.
-5. Define Abaqus `.inp` input subset and HDF5 output/reference schemas.
-6. Define stored Abaqus S4R/S4 reference model bundles.
-7. Write a TDD implementation plan.
-8. Implement C++17/MSVC code using CMake/CTest, MKL, TBB, and HDF5.
-9. Compare FESA HDF5 results against stored Abaqus S4R reference artifacts using `abs-or-rel 1e-5`.
-10. Prepare release documentation after reference verification passes.
-
-## Acceptance Criteria
-- Every solver feature follows the stage-gated workflow in `AGENTS.md`.
-- C++ production changes are test-first.
-- `python scripts/validate_workspace.py` remains the default validation path.
-- MITC4 reference comparison covers nodal displacement, reaction, element internal force/resultant, and stress.
-- Result comparison uses a single tolerance value `1e-5` with absolute-or-relative pass logic.
-- Agents can identify the canonical git remote and shared baseline branch from the project handoff documents.
-
-## Coordination Rules
-- Update this file when the plan, scope, ordering, or acceptance criteria change.
-- Update `docs/PROGRESS.md` after completing work or running validation.
-- Update `docs/WORKNOTE.md` after mistakes, failed approaches, environment traps, or decisions that future Agents should not rediscover.
-- Keep `.codex/agents/*.toml` and `.codex/skills/*/SKILL.md` pointed at `docs/AGENT_RULES.md` for common operating rules.
-- Verify `git status --short --branch` and `git remote -v` at the start of git-aware work.
-
-## Known Blockers
-- No CMake project exists yet, so `python scripts/validate_workspace.py` currently takes the no-op path.
-- Abaqus reference artifacts are not generated by Agents and must be supplied by a human-approved process.
-
-## Known Environment Facts
-- HDF5 is installed locally at `C:\Program Files\HDF_Group\HDF5\2.1.1`; CMake should use `HDF5_ROOT` for this root or `HDF5_DIR` for `C:\Program Files\HDF_Group\HDF5\2.1.1\cmake`.

docs/PRD.md

@@ -1,104 +1,22 @@
-# PRD: FESA MITC4 Linear Static Shell Solver
+# PRD: C++/MSVC Harness
 
-## 목적
-FESA는 유한요소 input 파일을 읽어 구조해석을 수행하고, 절점과 요소의 해석 결과를 출력하는 C++ 구조해석 솔버를 제공한다. 초기 제품 기능은 MITC4 4절점 shell element 기반 선형정적 해석이다.
+## 목표
+Codex Harness가 C++/MSVC 프로젝트에서 phase planning, TDD guard, commit validation, workspace validation을 일관되게 수행하게 한다.
 
 ## 사용자
-- 구조해석 솔버를 개발하는 C++/MSVC 개발자
-- Abaqus/Nastran 계열 input과 결과 검증 방식을 이해하는 해석 엔지니어
-- reference solver 결과와 FESA 결과를 비교해 기능 release를 판단하는 reviewer
-- Codex/FESA agent workflow로 기능을 단계별 구현하는 agent
-
-## 문제 정의
-구조해석 솔버는 단순히 코드를 빌드하는 것만으로 정확성을 판단할 수 없다. 요소 정식화, 입력 mapping, 선형해법, 결과 출력, reference solver 비교, tolerance 판정이 모두 명시되어야 한다. FESA는 이 과정을 문서화된 단계와 자동 검증으로 묶어 구현 실수를 줄인다.
+- Windows/MSVC 기반 C++ 개발자
+- Harness phase를 작성하고 실행하는 Codex agent
+- Harness 결과를 검토하는 reviewer
 
 ## 핵심 기능
-1. Abaqus `.inp` subset 입력
-   - `*NODE`, `*ELEMENT`, `*MATERIAL`, `*ELASTIC`, `*SHELL SECTION`, `*BOUNDARY`, `*CLOAD`, `*STEP` 지원
-   - unsupported keyword는 명시적 diagnostic을 낸다.
-2. MITC4 shell 선형정적 해석
-   - 4-node quadrilateral shell
-   - 6 DOF per node: `U1, U2, U3, UR1, UR2, UR3`
-   - isotropic linear elastic shell section
-   - 2x2 Gauss integration
-   - membrane, bending, transverse shear resultants
-3. Sparse system solve
-   - CSR global stiffness assembly
-   - Intel oneAPI MKL PARDISO direct solver
-   - constrained DOF 처리와 reaction recovery
-4. Parallel computation
-   - Intel oneAPI TBB 기반 element stiffness/result recovery 병렬화
-   - deterministic assembly merge
-5. HDF5 result output
-   - mesh metadata
-   - nodal displacement
-   - nodal reaction
-   - element internal force/resultant
-   - element stress
-6. Reference solver verification
-   - stored Abaqus S4R reference HDF5 artifact와 비교
-   - Abaqus S4 artifact는 diagnostic reference로 보관
-   - nodal displacement, reaction, element internal force, stress 비교
-   - tolerance `1e-5` 단일 기준
-7. Solver state and result model
-   - `Domain`, `AnalysisModel`, `AnalysisState` 분리
-   - step/frame/field/history HDF5 결과 구조
-   - constrained DOF 제거와 full-system reaction recovery
-8. Extensible object creation
-   - Abaqus parser와 element/material/load/boundary factory registry 분리
-   - 향후 1D/3D 요소, nonlinear, dynamic, thermal 기능 추가를 위한 module boundary 유지
-
-## 성공 기준
-- MITC4 요구조건, 연구, 정식화, I/O, reference model, 구현 계획, reference verification, release 문서가 작성되어 있다.
-- 모든 C++ production 변경은 관련 테스트가 먼저 작성되고 실패가 확인된 뒤 구현된다.
-- MSVC x64 Debug CMake build와 CTest가 통과한다.
-- 다음 테스트모델이 stored Abaqus S4R reference와 `abs-or-rel 1e-5` 이내로 일치한다.
-  - membrane patch
-  - bending patch
-  - transverse shear patch
-  - twist patch
-  - coarse Scordelis-Lo shell
-- HDF5 output schema가 reference comparison에 필요한 모든 id, component, step/frame, units, metadata를 포함한다.
-- Essential boundary condition reaction은 `K_full * U_full - F_full` 기준으로 계산되어 reference reaction과 비교 가능하다.
-- Singular system 또는 solver factorization 실패는 명시적 diagnostic으로 보고된다.
+1. CMake/MSVC/x64/Debug 기반 workspace validation
+2. C++ source/header 변경에 대한 엄격한 TDD guard
+3. npm 없이 Python self-test와 CMake/CTest 검증을 수행하는 pre-commit hook
+4. C++ 프로젝트에 맞는 Harness workflow/review prompt
+5. CMake project가 아직 없어도 Harness 자체 테스트가 가능한 no-op validation path
 
 ## 제외 사항
-- Nastran BDF parser
-- nonlinear static analysis
-- geometric nonlinearity
-- dynamic analysis
-- eigen/buckling analysis
-- material plasticity
-- layered composite shell section
-- contact analysis
-- Abaqus/Nastran 실행 자동화
-- reference artifact 자동 생성
-- OpenSees API 호환성
-- Phase 1 mesh quality scoring
-
-## 확장 로드맵
-MITC4 선형정적 기능이 reference 검증을 통과한 뒤 다음 기능을 별도 요구조건과 정식화 문서로 진행한다.
-
-1. nonlinear static analysis
-2. nonlinear dynamic analysis
-3. heat transfer and thermal-stress coupling
-4. 1D truss/beam and 3D solid elements
-5. additional material models and properties
-
-## Dependency Requirements
-- MSVC and CMake must be available for C++ build validation.
-- Intel oneAPI MKL must be available through `MKLROOT` or known oneAPI installation paths.
-- Intel oneAPI TBB must be available through `TBBROOT` or known oneAPI installation paths.
-- HDF5 C library must be supplied through `HDF5_ROOT` or `HDF5_DIR`; the current local default is `C:\Program Files\HDF_Group\HDF5\2.1.1`, with CMake package files under `C:\Program Files\HDF_Group\HDF5\2.1.1\cmake`.
-- Python 3 must be available for harness validation and phase execution.
-
-## Release Requirements
-Solver feature release is allowed only when:
-
-1. Requirements are approved.
-2. Research evidence and formulation are reviewed.
-3. I/O contract and HDF5 schema are fixed.
-4. Reference model artifacts exist and provenance is documented.
-5. C++ TDD implementation passes CTest.
-6. Reference comparison passes tolerance `1e-5`.
-7. Known limitations are written in the release document.
+- 이전 FESA solver source tree 복원
+- JavaScript/TypeScript fallback 유지
+- Abaqus reference artifact 생성 또는 solver reference 비교 구현
+- Visual Studio `.sln`/`.vcxproj` 전용 MSBuild workflow

docs/PROGRESS.md

@@ -1,102 +0,0 @@
-# FESA Multi-Agent Progress
-
-## Current Status
-- Project documentation has been reframed from a harness-only project to the FESA structural solver project.
-- Initial MITC4 solver implementation plan exists in `docs/project-plan/SOLVER_IMPLEMENT_INITIAL_PLAN.md`.
-- Solver architecture guidance exists in `docs/ARCHITECTURE.md`.
-- ADR and PRD have been updated for MITC4, MKL, TBB, HDF5, tolerance, reference artifacts, and solver state separation.
-- Multi-Agent coordination files live under `docs/`: `docs/PLAN.md`, `docs/PROGRESS.md`, and `docs/WORKNOTE.md`.
-- Project plan/design documents live under `docs/project-plan/`.
-- Common per-run AI Agent rules live in `docs/AGENT_RULES.md`.
-- Domain model foundation phase exists under `phases/domain-model-foundation/` and the first C++/MSVC CMake/CTest core implementation slice has been added.
-- Analysis model object phase exists under `phases/analysis-model-objects/` and adds identity-only model objects for Domain ownership.
-
-## Completed
-- Defined the nine-step solver development workflow.
-- Recorded initial MITC4 feature scope: linear static, MITC4 shell, Abaqus `.inp` subset, HDF5 output, Abaqus S4R primary reference.
-- Recorded tolerance policy: `abs(error) <= 1e-5 OR relative(error) <= 1e-5`.
-- Recorded architecture principles: `Domain`, `AnalysisModel`, `AnalysisState`, `DofManager`, factory/registry, adapter layers, deterministic TBB assembly, MKL PARDISO, HDF5 result model.
-- Moved handoff documents from repository root to `docs/`.
-- Moved solver plan/design documents to `docs/project-plan/` and updated agent, skill, test, and document references.
-- Extracted common per-run rules from the solver agent design into `docs/AGENT_RULES.md`.
-- Updated `.codex/agents/*.toml`, `.codex/skills/*/SKILL.md`, and related tests to reference `docs/AGENT_RULES.md` instead of the solver agent design document.
-- Renamed the first solver development workflow stage to "새로운 솔버 기능 요구조건 분석" across `AGENTS.md`, `docs/`, `.codex/agents/requirement-agent.toml`, and `.codex/skills/fesa-requirements-baseline`.
-- Refined `requirement-agent` and `fesa-requirements-baseline` internals to describe a new solver feature requirements analysis document instead of a requirements drafting/specification task.
-- Documented the canonical git remote `https://teagit.mimi1011.synology.me/baram2584/FESADev.git`, default remote `origin`, shared baseline branch `dev`, and `codex/<short-task-name>` work branch convention in `AGENTS.md`, `docs/AGENT_RULES.md`, and `docs/PLAN.md`.
-- Confirmed local HDF5 `2.1.1` installation at `C:\Program Files\HDF_Group\HDF5\2.1.1` and recorded the `HDF5_ROOT`/`HDF5_DIR` discovery policy in architecture, agent, skill, and handoff documentation.
-- Recorded the standing user instruction in `AGENTS.md` that Agent-authored work should be validated, committed, and pushed to `origin` after completion.
-- Created `docs/implementation-plans/domain-model-foundation-implementation-plan.md`.
-- Added root CMake/CTest bootstrap for `fesa_core` and `fesa_domain_tests`.
-- Implemented `Domain` model-definition storage for nodes, MITC4 element definitions, linear elastic material definitions, shell properties, node sets, element sets, boundary conditions, nodal loads, and linear static step definitions.
-- Added Domain foundation C++ tests under `tests/core/`.
-- Fixed `scripts/validate_workspace.py` so CMake/CTest validation can use the default CMake install path when CMake is not on the shell PATH.
-- Created `docs/implementation-plans/analysis-model-objects-implementation-plan.md`.
-- Added identity-only model object base classes and concrete skeletons for `Element`/`Mitc4Element`, `Material`/`LinearElasticMaterial`, `ShellProperty`, `Load`/`NodalLoad`, and `BoundaryCondition`/`SinglePointConstraint`.
-- Extended `Domain` with RAII `std::unique_ptr` ownership APIs for polymorphic element, material, load, and boundary model objects while preserving existing `*Definition` storage APIs.
-- Added `fesa_model_object_tests` CTest target and model-object tests under `tests/element/`, `tests/material/`, `tests/property/`, `tests/load/`, and `tests/boundary/`.
-- Created `docs/implementation-plans/domain-runtime-storage-implementation-plan.md` and `phases/domain-runtime-storage/`.
-- Migrated `Domain` canonical storage away from parser-style definition DTOs to runtime model objects for elements, materials, shell properties, loads, and boundary conditions.
-- Moved `ElementType` into `ModelTypes.hpp` so runtime element interfaces no longer include `ElementDefinition.hpp`.
-- Updated Domain storage tests so element sets and linear static step indices validate against runtime element, load, and boundary containers.
-- Created `docs/implementation-plans/property-model-foundation-implementation-plan.md` and `phases/property-model-foundation/`.
-- Added runtime `Property` base class and `PropertyKind`, made `ShellProperty` derive from `Property`, and migrated `Domain` property ownership to `std::unique_ptr<Property>`.
-- Added a minimal `Hdf5ResultWriter` skeleton with path validation only; it does not link HDF5 or write files yet.
-- Created `docs/implementation-plans/analysis-state-analysis-base-implementation-plan.md` and `phases/analysis-state-analysis-base/`.
-- Added `AnalysisState` mutable vector storage for displacement, external force, internal force, residual, and reaction, plus resize, guarded setters, force clearing, and time/increment/iteration counters.
-- Added `Analysis` base interface with const `Domain` input, mutable `AnalysisState`, `name()`, virtual deletion, and `run` delegation to derived analysis implementations.
-- Added `fesa_analysis_tests` CTest target and analysis/core unit tests.
-
-## In Progress
-- Ready for the next upstream MITC4 stage: new solver feature requirements analysis for `mitc4-linear-static-shell`.
-
-## Next Tasks
-1. Create `docs/requirements/mitc4-linear-static-shell.md`.
-2. Create `docs/research/mitc4-linear-static-shell-research.md`.
-3. Create `docs/formulations/mitc4-linear-static-shell-formulation.md`.
-4. Create `docs/io-definitions/mitc4-linear-static-shell-io.md`.
-5. Create `docs/reference-models/mitc4-linear-static-shell-reference-models.md`.
-6. Create `docs/implementation-plans/mitc4-linear-static-shell-implementation-plan.md`.
-
-## Last Validation
-- 2026-06-09: After analysis state and analysis base implementation, `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "analysis|domain|model-object|io"` passed. 4 CTest executables ran successfully.
-- 2026-06-09: After analysis state and analysis base implementation, `python -m unittest discover -s scripts -p "test_*.py"` passed. 89 tests ran successfully.
-- 2026-06-09: After analysis state and analysis base implementation, `python scripts/validate_workspace.py` configured CMake with Visual Studio 17 2022 x64, built Debug targets, ran CTest, and passed.
-- 2026-06-09: After analysis state and analysis base implementation, `git diff --check` passed with only Git line-ending normalization warnings.
-- 2026-06-09: After analysis model object implementation, `python -m unittest discover -s scripts -p "test_*.py"` passed. 89 tests ran successfully.
-- 2026-06-09: After analysis model object implementation, `python scripts/validate_workspace.py` configured CMake with Visual Studio 17 2022 x64, built Debug targets, ran CTest, and passed.
-- 2026-06-09: After analysis model object implementation, `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"` passed. 2 CTest executables ran successfully.
-- 2026-06-09: After analysis model object implementation, `git diff --check` passed.
-- 2026-06-09: After Domain runtime storage migration, `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"` passed. 2 CTest executables ran successfully.
-- 2026-06-09: After Domain runtime storage migration, `python -m unittest discover -s scripts -p "test_*.py"` passed. 89 tests ran successfully.
-- 2026-06-09: After Domain runtime storage migration, `python scripts/validate_workspace.py` configured CMake with Visual Studio 17 2022 x64, built Debug targets, ran CTest, and passed.
-- 2026-06-09: After Domain runtime storage migration, `git diff --check` passed with only Git line-ending normalization warnings.
-- 2026-06-09: After property model foundation implementation, `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object|io"` passed. 3 CTest executables ran successfully.
-- 2026-06-09: After property model foundation implementation, `python -m unittest discover -s scripts -p "test_*.py"` passed. 89 tests ran successfully.
-- 2026-06-09: After property model foundation implementation, `python scripts/validate_workspace.py` configured CMake with Visual Studio 17 2022 x64, built Debug targets, ran CTest, and passed.
-- 2026-06-09: After property model foundation implementation, `git diff --check` passed with only Git line-ending normalization warnings.
-- 2026-06-08: After Domain model foundation implementation, `python -m unittest discover -s scripts -p "test_*.py"` passed. 89 tests ran successfully.
-- 2026-06-08: After Domain model foundation implementation, `python scripts/validate_workspace.py` configured CMake with Visual Studio 17 2022 x64, built Debug targets, ran CTest, and passed.
-- 2026-06-08: After Domain model foundation implementation, `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` passed. 1 domain/core test executable ran successfully.
-- 2026-06-08: After Domain model foundation implementation, `git diff --check` passed.
-- 2026-06-08: After recording the standing commit/push instruction in `AGENTS.md`, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
-- 2026-06-08: After recording the standing commit/push instruction in `AGENTS.md`, `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
-- 2026-06-08: After recording the standing commit/push instruction in `AGENTS.md`, `git diff --check` passed with only Git line-ending normalization warnings.
-- 2026-06-08: After HDF5 install/path documentation and HDF5-first result-output agent/skill/doc updates, `python C:\Users\user\.codex\skills\.system\skill-creator\scripts\quick_validate.py` passed for modified FESA skills: `fesa-io-contract`, `fesa-reference-models`, `fesa-reference-comparison`, `fesa-cpp-msvc-tdd`, `fesa-physics-sanity`, `fesa-requirements-baseline`, `fesa-numerical-review`, `fesa-formulation-spec`, `fesa-research-evidence`, and `fesa-release-readiness`.
-- 2026-06-08: After HDF5 install/path documentation and HDF5-first result-output agent/skill/doc updates, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
-- 2026-06-08: After HDF5 install/path documentation and HDF5-first result-output agent/skill/doc updates, `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
-- 2026-06-08: After HDF5 install/path documentation and HDF5-first result-output agent/skill/doc updates, `git diff --check` passed with only Git line-ending normalization warnings.
-- 2026-06-08: After documenting git repository settings, `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
-- 2026-06-08: After documenting git repository settings, `git diff --check` passed with only Git line-ending normalization warnings.
-- 2026-06-08: After refining `requirement-agent` and `fesa-requirements-baseline` internals, `python C:\Users\baram\.codex\skills\.system\skill-creator\scripts\quick_validate.py .codex\skills\fesa-requirements-baseline` passed.
-- 2026-06-08: After refining `requirement-agent` and `fesa-requirements-baseline` internals, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
-- 2026-06-08: After refining `requirement-agent` and `fesa-requirements-baseline` internals, `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
-- 2026-06-08: `python C:\Users\baram\.codex\skills\.system\skill-creator\scripts\quick_validate.py .codex\skills\fesa-requirements-baseline` passed.
-- 2026-06-08: `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
-- 2026-06-08: `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
-- 2026-06-05: After extracting `docs/AGENT_RULES.md`, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
-- 2026-06-05: `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
-- 2026-06-05: After document relocation and reference updates, `python -m unittest discover -s scripts -p "test_*.py"` passed. 85 tests ran successfully.
-- 2026-06-05: `python scripts/validate_workspace.py` passed through the expected no-op path because no root `CMakeLists.txt` exists yet.
-
-## Open Questions
-- Stored Abaqus S4R/S4 reference artifact generation process is not yet defined.

docs/SOLVER_AGENT_DESIGN.md

@@ -6,7 +6,7 @@
 이번 구성안은 ALL-FEM 논문의 구조를 확장하거나 재사용하는 계획이 아니다. 논문은 Agent 설계를 위한 참고 자료로만 사용하며, 본 프로젝트는 C++/MSVC 기반 독립 솔버 개발 워크플로우를 따른다.
 
 ## 설계 원칙
-- 새로운 솔버 기능 요구조건 분석, 이론 정식화, 코드 구현, 검증, 배포 역할을 분리한다.
+- 기능 요구조건, 이론 정식화, 코드 구현, 검증, 배포 역할을 분리한다.
 - 실행 가능성만으로 성공을 판단하지 않고, 레퍼런스 결과와 물리량을 비교해 기능 완료를 판정한다.
 - 테스트는 구현 전에 준비한다. 개발 대상 솔버 테스트와 레퍼런스 솔버 결과 비교 테스트를 함께 사용한다.
 - Abaqus나 Nastran을 Agent가 직접 실행하지 않는다. `references/`에 저장된 입력 파일과 레퍼런스 CSV 결과를 검증 기준으로 사용한다.
@@ -21,7 +21,7 @@
 책임:
 - 기능 개발 요청을 단계별 작업으로 분해한다.
 - 각 Agent의 산출물을 연결하고 누락된 결정을 추적한다.
-- 요구조건 분석, 정식화, 테스트, 구현, 검증, 배포 단계의 진행 상태를 관리한다.
+- 요구조건, 정식화, 테스트, 구현, 검증, 배포 단계의 진행 상태를 관리한다.
 - 실패 시 어떤 Agent로 되돌릴지 결정한다.
 
 주요 산출물:
@@ -30,10 +30,10 @@
 - 실패 원인과 재작업 지시
 
 ### Requirement Agent
-새로운 솔버 기능 요구조건을 분석하는 Agent이다.
+솔버 기능 요구조건을 정의하는 Agent이다.
 
 책임:
-- 해석 기능의 범위, 입력, 출력, 제약조건을 분석하고 명시한다.
+- 해석 기능의 범위, 입력, 출력, 제약조건을 정의한다.
 - 대상 요소, 재료 모델, 경계조건, 하중 조건, 해석 타입을 명확히 한다.
 - 검증해야 할 물리량과 tolerance 기준을 정한다.
 
@@ -105,7 +105,7 @@
 주요 산출물:
 - 입력 데이터 schema
 - 출력 데이터 schema
-- 결과 비교용 HDF5 schema와 optional CSV export schema
+- 결과 비교용 CSV schema
 - 단위와 좌표계 규약
 
 ### Reference Model Agent
@@ -240,7 +240,7 @@ python scripts/validate_workspace.py
 
 | 개발 과정 | 담당 Agent | 필수 산출물 |
 | --- | --- | --- |
-| 1. 새로운 솔버 기능 요구조건 분석 | Requirement Agent | 요구조건 분석, acceptance criteria |
+| 1. 솔버 기능 요구조건 정의 | Requirement Agent | 요구조건, acceptance criteria |
 | 2. 연구자료 조사 | Research Agent | 자료 요약, benchmark 후보 |
 | 3. 유한요소 정식화 | Formulation Agent, Numerical Review Agent | 정식화 문서, 리뷰 결과 |
 | 4. 입출력 데이터 정의 | I/O Definition Agent | 입력/출력 schema |
@@ -278,7 +278,7 @@ flowchart TD
 
 ## 검증 Gate
 
-### Gate 1: 요구조건 분석 승인
+### Gate 1: 요구조건 승인
 통과 조건:
 - 대상 기능과 제외 범위가 명확하다.
 - 입력, 출력, tolerance, 검증 물리량이 정의되어 있다.

docs/SOLVER_SKILL_DESIGN.md

@@ -11,7 +11,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
 - Skill은 `.codex/skills/<skill-name>/SKILL.md`에 둔다.
 - 각 skill은 필수 frontmatter `name`, `description`과 UI metadata `agents/openai.yaml`을 가진다.
 - Skill 본문은 agent TOML의 역할 설명을 반복하지 않고, 입력, 절차, 산출물, 금지사항, 품질 gate, handoff를 정의한다.
-- Skill은 `AGENTS.md`와 `docs/AGENT_RULES.md`를 공통 상위 기준으로 읽는다.
+- Skill은 `AGENTS.md`와 `docs/SOLVER_AGENT_DESIGN.md`를 공통 상위 기준으로 읽는다.
 - Abaqus, Nastran 또는 reference solver 실행은 skill 범위에 포함하지 않는다.
 - Reference CSV 생성 또는 수정은 skill 범위에 포함하지 않는다.
 - C++ 구현 관련 skill은 C++17 이상, MSVC, CMake, CTest, TDD 원칙을 따른다.
@@ -21,7 +21,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
 
 | Skill | 적용 개발 과정 | 주요 사용자 Agent | 대표 산출물 |
 | --- | --- | --- | --- |
-| `fesa-requirements-baseline` | 1. 새로운 솔버 기능 요구조건 분석 | Requirement Agent, Coordinator Agent | `docs/requirements/<feature-id>.md` |
+| `fesa-requirements-baseline` | 1. 솔버 기능 요구조건 정의 | Requirement Agent, Coordinator Agent | `docs/requirements/<feature-id>.md` |
 | `fesa-research-evidence` | 2. 책, 논문 등 연구자료 조사 | Research Agent, Formulation Agent | `docs/research/<feature-id>-research.md` |
 | `fesa-formulation-spec` | 3. 코드 구현을 위한 유한요소 정식화 | Formulation Agent, Implementation Planning Agent | `docs/formulations/<feature-id>-formulation.md` |
 | `fesa-numerical-review` | 3. 정식화 독립 수치 검토 | Numerical Review Agent, Coordinator Agent | `docs/numerical-reviews/<feature-id>-review.md` |
@@ -36,14 +36,14 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
 
 예시 기능: `linear-truss-1d`
 
-1. Requirement Agent는 `fesa-requirements-baseline`을 사용해 새로운 솔버 기능의 범위, 제외 범위, 입력, 출력, 검증 물리량, tolerance, `Requirement Verification Matrix`를 분석하고 작성한다.
+1. Requirement Agent는 `fesa-requirements-baseline`을 사용해 기능 범위, 제외 범위, 입력, 출력, 검증 물리량, tolerance, `Requirement Verification Matrix`를 작성한다.
 2. Research Agent는 `fesa-research-evidence`를 사용해 truss/bar element 이론, benchmark 후보, source reliability, applicability limits를 정리한다.
 3. Formulation Agent는 `fesa-formulation-spec`을 사용해 strong form, weak form, shape functions, B matrix, element stiffness, output recovery를 정리한다.
 4. Numerical Review Agent는 `fesa-numerical-review`를 사용해 rigid body modes, patch test, stiffness symmetry, Jacobian, locking 위험을 검토하고 `pass-for-implementation-planning` 여부를 판단한다.
 5. I/O Definition Agent는 `fesa-io-contract`를 사용해 지원할 Abaqus `.inp` keyword subset과 `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv` schema를 정의한다.
 6. Reference Model Agent는 `fesa-reference-models`를 사용해 `references/linear-truss-1d/<model-id>/` artifact bundle 계약과 coverage matrix를 작성한다.
 7. Implementation Planning Agent와 Implementation Agent는 `fesa-cpp-msvc-tdd`를 사용해 테스트 작성, 실패 확인, 최소 구현, CMake/CTest 등록, validation을 수행한다.
-8. Reference Verification Agent는 `fesa-reference-comparison`을 사용해 구현 solver HDF5 결과와 저장된 reference HDF5 artifact를 tolerance 기준으로 비교한다.
+8. Reference Verification Agent는 `fesa-reference-comparison`을 사용해 구현 solver CSV와 저장된 reference CSV를 tolerance 기준으로 비교한다.
 9. Physics Evaluation Agent는 `fesa-physics-sanity`를 사용해 global equilibrium, reaction consistency, displacement direction, symmetry, model coverage를 검토한다.
 10. Release Agent는 `fesa-release-readiness`를 사용해 gate evidence, acceptance traceability, known limitations, release notes draft를 작성한다.
 
@@ -51,10 +51,10 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
 
 ### `fesa-requirements-baseline`
 
-- 새로운 솔버 기능 요청을 검증 가능한 요구조건 분석 baseline으로 만든다.
+- 기능 요청을 검증 가능한 요구조건 baseline으로 만든다.
 - `shall` 문장과 `FESA-REQ-<FEATURE>-###` id를 사용한다.
 - 모든 `must` 요구조건은 verification method와 acceptance criteria를 가져야 한다.
-- FEM 정식화, C++ 구현, reference HDF5 artifact 또는 reference CSV 생성, release readiness 판단은 하지 않는다.
+- FEM 정식화, C++ 구현, reference CSV 생성, release readiness 판단은 하지 않는다.
 
 ### `fesa-research-evidence`
 
@@ -81,7 +81,7 @@ Agent는 역할과 책임 단위이고, skill은 여러 Agent가 반복적으로
 
 - FESA solver input이 지원할 Abaqus `.inp` subset을 정의한다.
 - model data와 history data를 구분한다.
-- 내부 semantic model 계약과 HDF5 output schema 및 명시적으로 요구된 optional CSV schema를 정의한다.
+- 내부 semantic model 계약과 output/CSV schema를 정의한다.
 - parser 구현이나 full Abaqus compatibility claim은 하지 않는다.
 
 ### `fesa-reference-models`
@@ -155,10 +155,10 @@ Skill 구성 검증은 `scripts/test_fesa_solver_skills.py`가 담당한다.
 - 10개 solver skill의 `SKILL.md` 존재 여부
 - YAML frontmatter의 `name`, `description`
 - 공통 섹션: `Inputs`, `Workflow`, `Output Contract`, `Boundaries`, `Quality Gate`, `Handoff`
-- `AGENTS.md`와 `docs/AGENT_RULES.md` 참조
+- `AGENTS.md`와 `docs/SOLVER_AGENT_DESIGN.md` 참조
 - skill-specific 핵심 문구와 산출물 경로
 - `agents/openai.yaml` UI metadata
-- 이 문서가 아니라 실제 skill 파일이 기준이 되도록 `docs/project-plan/SOLVER_SKILL_DESIGN.md`에 대한 skill 본문 참조 금지
+- 이 문서가 아니라 실제 skill 파일이 기준이 되도록 `docs/SOLVER_SKILL_DESIGN.md`에 대한 skill 본문 참조 금지
 
 검증 명령:
 

docs/WORKNOTE.md

@@ -1,32 +0,0 @@
-# FESA Multi-Agent Work Notes
-
-## Purpose
-This file records mistakes, failed attempts, environment traps, and lessons learned so future AI Agents do not repeat them.
-
-Add dated entries. Do not delete another Agent's note unless the user explicitly asks.
-
-## Notes
-
-### 2026-06-05 - HDF5 Not Found In Standard Paths
-During planning, standard checks for `HDF5_ROOT`, `HDF5_DIR`, `h5dump`, and obvious Program Files HDF5 folders did not find HDF5. Future implementation should not assume HDF5 is locally installed. Use `HDF5_ROOT` or `HDF5_DIR` and fail CMake configuration with a clear diagnostic if missing.
-
-### 2026-06-08 - HDF5 Installed Under HDF_Group
-The local HDF5 install was later confirmed at `C:\Program Files\HDF_Group\HDF5\2.1.1`, and `h5dump.exe -V` reports `2.1.1`. Future CMake work should prefer `HDF5_ROOT=C:\Program Files\HDF_Group\HDF5\2.1.1` or `HDF5_DIR=C:\Program Files\HDF_Group\HDF5\2.1.1\cmake`. Keep the old 2026-06-05 note as historical context for stale sessions, but do not treat HDF5 as currently missing on this machine.
-
-### 2026-06-08 - CMake Installed But Not On Shell PATH
-`cmake.exe` exists at `C:\Program Files\CMake\bin\cmake.exe`, but the Codex shell did not resolve bare `cmake`. `scripts/validate_workspace.py` was updated to resolve bare `cmake` and `ctest` validation commands to the known CMake install path when needed. Use `python scripts/validate_workspace.py` as the canonical validation path, or call `C:\Program Files\CMake\bin\cmake.exe` / `ctest.exe` explicitly for manual commands.
-
-### 2026-06-05 - Validation Currently Has No CMake Project
-`python scripts/validate_workspace.py` currently exits successfully through the no-op path because there is no root `CMakeLists.txt`. This is expected until the C++ solver project is bootstrapped. Once CMake is introduced, validation must configure, build, and run CTest.
-
-### 2026-06-05 - Reference Solvers Are Not Agent-Run
-Agents must not run Abaqus or Nastran. Reference artifacts must come from a human-approved process and be stored under `references/<feature>/<model-id>/`.
-
-### 2026-06-05 - Keep Reaction Recovery Full-System Based
-For constrained DOF elimination, reactions must be recovered as `K_full * U_full - F_full`. Do not compare reactions computed only from the reduced system.
-
-### 2026-06-05 - Avoid PowerShell UTF-8 BOM For TOML And SKILL.md
-PowerShell `Set-Content -Encoding UTF8` added a UTF-8 BOM to `.codex/agents/*.toml` and `.codex/skills/*/SKILL.md`. That broke `tomllib` with `Invalid statement (at line 1, column 1)` and broke skill frontmatter parsing because files no longer started with `---`. Use BOM-free UTF-8 for mechanical rewrites, for example `[System.Text.UTF8Encoding]::new($false)` with `.NET` `WriteAllText`.
-
-### 2026-06-05 - Mechanical Path Replacement Can Rewrite The New Target File
-When replacing old document references with `docs/AGENT_RULES.md`, the new rules file itself was also included in the replacement set and briefly became self-referential. Future broad path rewrites should exclude the newly created target file or inspect it immediately after replacement.

docs/build-test-reports/README.md

@@ -22,7 +22,7 @@ Build/Test Executor Agent는 Implementation Agent 이후 독립적으로 C++/MSV
 - CMake files를 수정하지 않는다.
 - requirements, formulations, I/O contracts, reference artifacts, tolerance policies를 수정하지 않는다.
 - Abaqus, Nastran 또는 reference solver를 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV를 생성하지 않는다.
+- reference CSV를 생성하지 않는다.
 - release readiness, reference tolerance success, physics validation success를 승인하지 않는다.
 - 최종 reference verification report를 작성하지 않는다.
 

docs/build-test-reports/analysis-model-objects-build-test.md

@@ -1,73 +0,0 @@
-# Analysis Model Objects Build/Test Report
-
-## Metadata
-- feature_id: analysis-model-objects
-- source_implementation_report: N/A
-- source_implementation_plan: docs/implementation-plans/analysis-model-objects-implementation-plan.md
-- status: pass-for-next-implementation-stage
-- owner_agent: build-test-executor-agent
-- date: 2026-06-09
-
-## Execution Environment
-- os: Windows
-- generator: Visual Studio 17 2022
-- platform: x64
-- config: Debug
-- build_dir: build/msvc-debug
-- active_override_env_vars: none
-- command_discovery_path: default CMake/MSVC x64 Debug through `python scripts/validate_workspace.py`
-
-## Command Log Summary
-
-| order | command | exit_code | duration | stdout_stderr_tail |
-| --- | --- | --- | --- | --- |
-| 1 | `python -m unittest discover -s scripts -p "test_*.py"` | 0 | <1s | 89 tests passed |
-| 2 | `python scripts/validate_workspace.py` | 0 | ~4s | CMake configure, Debug build, and CTest passed |
-| 3 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"` | 0 | <1s | 2 CTest executables passed |
-| 4 | `git diff --check` | 0 | <1s | no whitespace errors; line-ending normalization warnings may appear |
-
-## Validation Results
-
-| validation_stage | result | evidence |
-| --- | --- | --- |
-| harness self-test | pass | Python unittest discovery passed 89 tests |
-| configure | pass | CMake generated `build/msvc-debug` with Visual Studio 17 2022 x64 |
-| build | pass | `fesa_core.lib`, `fesa_domain_tests.exe`, and `fesa_model_object_tests.exe` built |
-| CTest | pass | `domain.bootstrap` and `model-object.base` passed |
-| feature-specific tests | pass | model-object and domain CTest filters passed |
-
-## Failure Classification
-
-- classification: N/A
-- primary_failure: N/A
-- first_failed_command: N/A
-- evidence_tail: validation succeeded
-
-## Failed Test Inventory
-
-| test_name | label | command | failure_summary |
-| --- | --- | --- | --- |
-| N/A | N/A | N/A | N/A |
-
-## Handoff Recommendation
-
-| target_agent | reason | required_input |
-| --- | --- | --- |
-| Parser/Factory Implementation Agent | New model objects can be populated from future parser/factory mappings | model object headers and compatibility note |
-| AnalysisModel Implementation Agent | Domain now exposes identity-only model objects through const base APIs | Domain object ownership APIs |
-| Build/Test Executor Agent | Re-run after downstream C++ changes | validation commands in this report |
-| Reference Verification Agent | Not ready; this phase produces no solver HDF5 result | N/A |
-
-## No-Change Assertion
-
-- source_files_modified: true
-- test_files_modified: true
-- cmake_files_modified: true
-- reference_artifacts_modified: false
-- tolerance_policies_modified: false
-- notes: This phase added model object classes and Domain ownership APIs only. It did not run reference solvers, generate reference artifacts, change tolerances, or claim numerical MITC4 correctness.
-
-## Open Issues
-
-- Parser/factory mapping from core `*Definition` DTOs to model objects remains deferred.
-- MITC4 stiffness, material constitutive behavior, shell section stiffness, assembly, solver, and HDF5 output remain future phases.

docs/build-test-reports/analysis-state-analysis-base-build-test.md

@@ -1,65 +0,0 @@
-# Analysis State And Analysis Base Build/Test Report
-
-## Metadata
-- feature_id: analysis-state-analysis-base
-- source_implementation_report: N/A
-- source_implementation_plan: docs/implementation-plans/analysis-state-analysis-base-implementation-plan.md
-- status: pass-for-next-implementation-stage
-- owner_agent: build-test-executor-agent
-- date: 2026-06-09
-
-## Execution Environment
-- os: Windows
-- generator: Visual Studio 17 2022
-- platform: x64
-- config: Debug
-- build_dir: build/msvc-debug
-- active_override_env_vars: none observed
-- command_discovery_path: default CMake/MSVC x64 Debug through scripts/validate_workspace.py
-
-## Command Log Summary
-
-| order | command | exit_code | duration | stdout_stderr_tail |
-| --- | --- | --- | --- | --- |
-| 1 | `python scripts/validate_workspace.py` after RED tests | 1 | short | Expected compile failure: missing `fesa/analysis/Analysis.hpp` and `fesa/core/AnalysisState.hpp`. |
-| 2 | `C:\Program Files\CMake\bin\ctest.exe --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis` | 0 | 0.39 sec | `analysis.base` passed. |
-| 3 | `C:\Program Files\CMake\bin\ctest.exe --test-dir build/msvc-debug --output-on-failure -C Debug -R "analysis\|domain\|model-object\|io"` | 0 | 1.31 sec | 4 tests passed. |
-| 4 | `python -m unittest discover -s scripts -p "test_*.py"` | 0 | 0.230 sec | 89 tests ran successfully. |
-| 5 | `python scripts/validate_workspace.py` | 0 | short | Configure, build, and CTest passed; 4 CTest tests passed. |
-| 6 | `git diff --check` | 0 | short | Passed with Git LF-to-CRLF normalization warnings only. |
-
-## Validation Results
-
-| validation_stage | result | evidence |
-| --- | --- | --- |
-| RED check | pass | Initial build failed because planned headers/classes were missing. |
-| targeted analysis CTest | pass | `analysis.base` passed. |
-| regression CTest | pass | `domain.bootstrap`, `model-object.base`, `io.hdf5-result-writer`, and `analysis.base` passed. |
-| harness self-test | pass | 89 Python tests passed. |
-| workspace validation | pass | Configure, Debug build, and all CTest tests passed. |
-| whitespace check | pass | `git diff --check` returned exit code 0. |
-
-## Failure Classification
-
-- classification: N/A after implementation
-- primary_failure: N/A
-- first_failed_command: N/A
-- evidence_tail: N/A
-
-## Handoff Recommendation
-
-| target_agent | reason | required_input |
-| --- | --- | --- |
-| AnalysisModel Implementation Agent | Analysis base and mutable state storage now exist. | `include/fesa/analysis/Analysis.hpp`, `include/fesa/core/AnalysisState.hpp`, `tests/analysis/analysis_base_test.cpp`, `tests/core/analysis_state_test.cpp` |
-| DofManager Implementation Agent | State vectors are size-based but do not define equation numbering. | `AnalysisState` contract and architecture rules |
-| LinearStaticAnalysis Implementation Agent | Base strategy entry point exists, but no solver algorithm is implemented. | future `AnalysisModel` and `DofManager` contracts |
-
-## No-Change Assertion
-- source_files_modified: true
-- test_files_modified: true
-- cmake_files_modified: true
-- reference_artifacts_modified: false
-- notes: No requirements, formulations, I/O contracts, reference artifacts, or tolerance policies were modified.
-
-## Open Issues
-- `AnalysisModel`, `DofManager`, and `LinearStaticAnalysis` remain separate downstream phases.

docs/build-test-reports/domain-model-foundation-build-test.md

@@ -1,74 +0,0 @@
-# Domain Model Foundation Build/Test Report
-
-## Metadata
-- feature_id: domain-model-foundation
-- source_implementation_report: N/A
-- source_implementation_plan: docs/implementation-plans/domain-model-foundation-implementation-plan.md
-- status: pass-for-next-implementation-stage
-- owner_agent: build-test-executor-agent
-- date: 2026-06-08
-
-## Execution Environment
-- os: Windows
-- generator: Visual Studio 17 2022
-- platform: x64
-- config: Debug
-- build_dir: build/msvc-debug
-- active_override_env_vars: none
-- command_discovery_path: default CMake/MSVC x64 Debug
-
-## Command Log Summary
-
-| order | command | exit_code | duration | stdout_stderr_tail |
-| --- | --- | --- | --- | --- |
-| 1 | `git status --short --branch` | 0 | <1s | branch `codex/domain-model-foundation`; only Agent-authored changes observed |
-| 2 | `git remote -v` | 0 | <1s | `origin` points to `https://teagit.mimi1011.synology.me/baram2584/FESADev.git` |
-| 3 | `python -m unittest discover -s scripts -p "test_*.py"` | 0 | <1s | 89 tests passed |
-| 4 | `python scripts/validate_workspace.py` | 0 | ~8s | configure, build, and CTest passed; validation succeeded |
-| 5 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` | 0 | <1s | 1 domain/core CTest passed |
-| 6 | `git diff --check` | 0 | <1s | no whitespace errors |
-
-## Validation Results
-
-| validation_stage | result | evidence |
-| --- | --- | --- |
-| harness self-test | pass | `python -m unittest discover -s scripts -p "test_*.py"` ran 89 tests successfully |
-| configure | pass | CMake generated `build/msvc-debug` with Visual Studio 17 2022 x64 |
-| build | pass | `fesa_core.lib` and `fesa_domain_tests.exe` built in Debug |
-| CTest | pass | `domain.bootstrap` passed with labels `domain;core` |
-| feature-specific tests | pass | Domain model storage tests are compiled into `fesa_domain_tests` |
-
-## Failure Classification
-
-- classification: N/A
-- primary_failure: N/A
-- first_failed_command: N/A
-- evidence_tail: validation succeeded
-
-## Failed Test Inventory
-
-| test_name | label | command | failure_summary |
-| --- | --- | --- | --- |
-| N/A | N/A | N/A | N/A |
-
-## Handoff Recommendation
-
-| target_agent | reason | required_input |
-| --- | --- | --- |
-| Implementation Agent | Continue with parser/factory or AnalysisModel work after upstream contracts are ready | Domain headers, tests, and implementation plan |
-| Build/Test Executor Agent | Re-run after downstream C++ changes | validation commands in this report |
-| Reference Verification Agent | Not ready; this phase produces no solver HDF5 result | N/A |
-
-## No-Change Assertion
-
-- source_files_modified: true
-- test_files_modified: true
-- cmake_files_modified: true
-- reference_artifacts_modified: false
-- tolerance_policies_modified: false
-- notes: This phase added C++ core model-definition storage only. It did not run reference solvers, generate reference artifacts, or change tolerance policy.
-
-## Open Issues
-
-- MITC4 requirements, research, formulation, I/O contract, reference models, and full implementation plan remain separate upstream stages.
-- Parser-to-Domain factory API is intentionally deferred.

docs/coordination/README.md

@@ -26,7 +26,7 @@ Coordinator Agent는 FESA solver 기능 개발의 전체 lifecycle에서 gate ev
 - requirements, formulations, I/O contracts, numerical review reports를 수정하지 않는다.
 - reference artifacts 또는 tolerance policies를 수정하지 않는다.
 - Abaqus, Nastran 또는 reference solver를 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV를 생성하지 않는다.
+- reference CSV를 생성하지 않는다.
 - subagents를 자동 spawn하지 않는다.
 - release readiness를 독립적으로 승인하지 않는다.
 
@@ -153,7 +153,7 @@ INTAKE -> STATE AUDIT -> GATE DECISION -> HANDOFF PACKAGE -> STATUS REPORT
 ## 상태 값
 
 - `intake`: 기능 요청은 들어왔지만 첫 handoff가 완료되지 않았다.
-- `needs-requirements`: Requirement Agent가 새로운 솔버 기능 요구조건 분석 산출물을 작성하거나 수정해야 한다.
+- `needs-requirements`: Requirement Agent가 요구조건을 정의하거나 수정해야 한다.
 - `needs-research`: Research Agent가 source-backed research evidence를 제공하거나 수정해야 한다.
 - `needs-formulation`: Formulation Agent가 FEM 정식화를 작성하거나 수정해야 한다.
 - `needs-numerical-review`: Numerical Review Agent가 정식화를 검토하거나 재검토해야 한다.

docs/corrections/README.md

@@ -24,7 +24,7 @@ Correction Agent는 Build/Test Executor Agent, Reference Verification Agent, Phy
 - reference artifacts를 수정하지 않는다.
 - tolerance policies를 수정하지 않는다.
 - Abaqus, Nastran 또는 reference solver를 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV를 생성하지 않는다.
+- reference CSV를 생성하지 않는다.
 - release readiness, reference tolerance success, physics validation success를 승인하지 않는다.
 - 최종 reference verification report 또는 physics validation report를 작성하지 않는다.
 

docs/formulations/README.md

@@ -20,7 +20,7 @@ Formulation Agent는 구현 가능한 FEM 정식화 문서를 작성한다.
 - C++ 코드를 구현하지 않는다.
 - C++ API나 파일 구조를 설계하지 않는다.
 - Abaqus, Nastran 또는 레퍼런스 솔버를 직접 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV 결과를 생성하지 않는다.
+- reference CSV 결과를 생성하지 않는다.
 - release readiness를 승인하지 않는다.
 - Numerical Review Agent 검토 전 정식화를 최종 승인하지 않는다.
 

docs/implementation-plans/README.md

@@ -2,7 +2,7 @@
 
 이 디렉터리는 Implementation Planning Agent가 작성하거나 제안한 기능별 구현계획 문서를 보관하는 위치다.
 
-Implementation Planning Agent는 승인된 요구조건, 연구 브리프, 정식화, 수치 리뷰, I/O 정의, reference model 계약을 C++/MSVC 구현 전 TDD 작업계획으로 변환한다. Agent는 코드, 테스트, CMake 파일을 작성하지 않고, Abaqus/Nastran을 실행하지 않으며, reference HDF5 artifact나 reference CSV 생성, solver 결과 비교, release readiness 승인도 하지 않는다.
+Implementation Planning Agent는 승인된 요구조건, 연구 브리프, 정식화, 수치 리뷰, I/O 정의, reference model 계약을 C++/MSVC 구현 전 TDD 작업계획으로 변환한다. Agent는 코드, 테스트, CMake 파일을 작성하지 않고, Abaqus/Nastran을 실행하지 않으며, reference CSV 생성이나 solver 결과 비교, release readiness 승인도 하지 않는다.
 
 기본 파일명은 `docs/implementation-plans/<feature-id>-implementation-plan.md` 형식을 사용한다. 각 문서는 Implementation Agent가 먼저 작성해야 할 실패 테스트, 최소 구현 순서, CMake/CTest 등록 계획, acceptance traceability를 제공해야 한다.
 
@@ -23,7 +23,7 @@ Implementation Planning Agent는 승인된 요구조건, 연구 브리프, 정
 - CMake 파일을 수정하지 않는다.
 - CMake/CTest를 실행하지 않는다.
 - Abaqus, Nastran 또는 레퍼런스 솔버를 직접 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV를 생성하지 않는다.
+- reference CSV를 생성하지 않는다.
 - solver 결과를 비교하지 않는다.
 - release readiness를 승인하지 않는다.
 - C++ API, class name, storage layout, file ownership을 확정하지 않는다.
@@ -73,7 +73,7 @@ Implementation Planning Agent는 승인된 요구조건, 연구 브리프, 정
 | TEST-001 | 1 | unit | test fails because behavior is missing | test passes after minimal implementation | TASK-001 | ctest -C Debug -R <test-name> |
 | TEST-002 | 2 | integration | integrated path fails before implementation | integrated path passes | TASK-002 | ctest -C Debug -R <test-name> |
 | TEST-003 | 3 | parser/I/O | Abaqus .inp case is not accepted or mapped | input maps to expected semantic model | TASK-003 | ctest -C Debug -R <test-name> |
-| TEST-004 | 4 | reference-comparison | solver HDF5 comparison fails before implementation | comparison is within planned tolerance | TASK-004 | ctest -C Debug -R <test-name> |
+| TEST-004 | 4 | reference-comparison | solver CSV comparison fails before implementation | comparison is within planned tolerance | TASK-004 | ctest -C Debug -R <test-name> |
 
 ## CMake/CTest Plan
 - target_candidates: <library/test executable targets>
@@ -95,8 +95,8 @@ Implementation Planning Agent는 승인된 요구조건, 연구 브리프, 정
 ## Data Flow Contract
 1. Abaqus `.inp` input follows docs/io-definitions/<feature-id>-io.md.
 2. Parser/I/O path maps model data and history data into the internal semantic model.
-3. Solver path produces `results.h5` with displacement, reaction, element force, stress, or feature-specific result datasets.
-4. Reference comparison tests compare solver `results.h5` against `references/<feature-id>/<model-id>/` HDF5 artifacts.
+3. Solver path produces displacement, reaction, element force, stress, or feature-specific result CSV.
+4. Reference comparison tests compare solver CSV against `references/<feature-id>/<model-id>/` artifacts.
 
 ## Acceptance Traceability Matrix
 
@@ -123,7 +123,7 @@ ctest -C Debug -R <feature-or-label>
 - <likely failure classifications and upstream rollback guidance>
 
 ### Reference Verification Agent
-- <planned HDF5 comparison tests, reference model ids, tolerance mapping, ID matching assumptions>
+- <planned CSV comparison tests, reference model ids, tolerance mapping, ID matching assumptions>
 
 ## Open Issues
 - <requirement, formulation, I/O, reference artifact, tolerance, or architecture issue>
@@ -133,7 +133,7 @@ ctest -C Debug -R <feature-or-label>
 
 - 모든 `must` requirement는 최소 하나의 task와 test에 연결되어야 한다.
 - C++ production 변경마다 선행 테스트 파일 또는 테스트 추가 계획이 있어야 한다.
-- reference artifact가 필요한 기능은 `references/<feature-id>/<model-id>/`와 HDF5 비교 테스트 계획을 가져야 한다.
+- reference artifact가 필요한 기능은 `references/<feature-id>/<model-id>/`와 CSV 비교 테스트 계획을 가져야 한다.
 - CMake/CTest 계획은 MSVC x64 Debug 검증 경로와 호환되어야 한다.
 - 구현 계획은 테스트 작성, 실패 확인, 최소 구현, validation 순서를 명시해야 한다.
 - upstream 문서가 불완전하면 값을 임의로 채우지 않고 `needs-upstream-decision` 또는 `blocked`로 표시한다.

docs/implementation-plans/analysis-model-objects-implementation-plan.md

@@ -1,179 +0,0 @@
-# Analysis Model Objects Implementation Plan
-
-## Metadata
-- feature_id: analysis-model-objects
-- source_requirement: AGENTS.md; docs/ARCHITECTURE.md; docs/ADR.md
-- source_research: N/A for this architecture/model-object slice
-- source_formulation: N/A for this architecture/model-object slice
-- source_numerical_review: N/A for this architecture/model-object slice
-- source_io_definition: docs/ARCHITECTURE.md Domain and factory/registry ownership rules
-- source_reference_models: N/A for this architecture/model-object slice
-- status: ready-for-implementation
-- owner_agent: implementation-planning-agent
-- date: 2026-06-09
-
-## Readiness Check
-
-| input | required_status | observed_status | decision |
-| --- | --- | --- | --- |
-| architecture | model object boundaries documented | documented in docs/ARCHITECTURE.md and ADR-004/010/011 | proceed |
-| domain foundation | base Domain storage available | implemented in `domain-model-foundation` | proceed |
-| formulation | not required for identity-only model object skeletons | N/A | proceed |
-| numerical_review | not required for identity-only model object skeletons | N/A | proceed |
-| io_definition | parser DTO compatibility sufficient | existing `*Definition` objects remain input DTOs | proceed |
-| reference_models | not required because this slice produces no solver result | N/A | proceed |
-
-## Implementation Scope
-
-- included_behavior: C++17 model object classes for nodes, elements, materials, shell properties, loads, and boundary conditions.
-- included_behavior: abstract base classes for element, material, load, and boundary condition model objects.
-- included_behavior: MITC4 element model skeleton with id, connectivity, property id, 4-node count, and 24-DOF count.
-- included_behavior: Domain RAII ownership for polymorphic model objects through `std::unique_ptr`.
-- included_behavior: compatibility with existing `*Definition` value objects and tests.
-- excluded_behavior: MITC4 stiffness, Jacobian, MITC shear interpolation, constitutive matrices, global force assembly, boundary-condition elimination, equation numbering, solver vectors, reaction recovery, HDF5 output, parser/factory implementation, and reference comparison.
-- non_goals: numerical correctness claims, release readiness, reference-solver execution, and reference artifact generation.
-
-## Model Object Contract
-
-`Domain` remains the owner of parsed model definition. This phase adds runtime model objects that can later be used by `AnalysisModel`, factories, and element/material implementations without storing analysis state in `Domain`.
-
-Model object responsibilities:
-
-- `Node`: id and reference coordinates only; fixed six-DOF count from project convention.
-- `Element`: identity, element type, connectivity, property reference, and node count only.
-- `Mitc4Element`: MITC4 model skeleton with four node ids and 24 element DOFs only.
-- `Material`: material identity only.
-- `LinearElasticMaterial`: id, Young's modulus, and Poisson ratio only.
-- `ShellProperty`: property id, material id, and thickness only.
-- `Load`: load kind only.
-- `NodalLoad`: node id, DOF, and scalar value only.
-- `BoundaryCondition`: boundary kind only.
-- `SinglePointConstraint`: node id, DOF, and prescribed scalar value only.
-
-Excluded from all model objects:
-
-- equation ids
-- sparse matrix data
-- displacement, residual, reaction, velocity, acceleration, or temperature vectors
-- current time, increment, or iteration counters
-- element integration point state
-- MKL, TBB, HDF5, or reference-comparison handles
-
-Existing `*Definition` value objects remain parser/factory DTOs for now. This phase must not delete them. Later parser/factory work may either map DTOs into model objects or retire DTOs with an explicit migration plan.
-
-Compatibility decision:
-
-- Existing `ElementDefinition`, `LinearElasticMaterialDefinition`, `ShellPropertyDefinition`, `BoundaryCondition`, `NodalLoadDefinition`, and `LinearStaticStepDefinition` classes remain under `include/fesa/core/` as value-style input DTOs.
-- New runtime model objects live under ownership namespaces: `fesa::element`, `fesa::material`, `fesa::property`, `fesa::load`, and `fesa::boundary`.
-- `Domain` supports both existing DTO storage APIs and new polymorphic model-object ownership APIs during the transition.
-- Parser/factory work must make an explicit choice to map DTOs to model objects or replace DTOs in a separate phase. This phase does not decide parser behavior.
-
-## Work Breakdown
-
-| task_id | order | purpose | upstream_trace | depends_on | expected_test_first |
-| --- | --- | --- | --- | --- | --- |
-| AMO-001 | 1 | refine `Node` model class contract | ADR-010; docs/ARCHITECTURE.md Node | none | AMO-TEST-001 |
-| AMO-002 | 2 | add abstract `Element` base interface | ADR-004; docs/ARCHITECTURE.md Element | AMO-001 | AMO-TEST-002 |
-| AMO-003 | 3 | add MITC4 element model skeleton | AGENTS.md MITC4 scope | AMO-002 | AMO-TEST-003 |
-| AMO-004 | 4 | add material base and linear elastic material object | docs/ARCHITECTURE.md Material | AMO-002 | AMO-TEST-004 |
-| AMO-005 | 5 | add shell property model object | docs/ARCHITECTURE.md Property | AMO-004 | AMO-TEST-005 |
-| AMO-006 | 6 | add load base and nodal load object | docs/ARCHITECTURE.md loads | AMO-002 | AMO-TEST-006 |
-| AMO-007 | 7 | add boundary base and single-point constraint object | ADR-012 | AMO-002 | AMO-TEST-007 |
-| AMO-008 | 8 | extend Domain with polymorphic object ownership | ADR-010; ADR-011 | AMO-003 to AMO-007 | AMO-TEST-008 |
-| AMO-009 | 9 | preserve `*Definition` compatibility | domain-model-foundation plan | AMO-008 | AMO-TEST-009 |
-| AMO-010 | 10 | record build/test evidence and handoff | docs/build-test-reports/README.md | AMO-009 | AMO-TEST-010 |
-
-## TDD Test Plan
-
-| test_id | order | test_type | red_condition | green_condition | linked_task | command |
-| --- | --- | --- | --- | --- | --- | --- |
-| AMO-TEST-001 | 1 | unit | `Node::dofCount()` missing | Node model tests pass | AMO-001 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` |
-| AMO-TEST-002 | 2 | unit | `fesa/element/Element.hpp` missing | Element base polymorphism tests pass | AMO-002 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object` |
-| AMO-TEST-003 | 3 | unit | `Mitc4Element` missing | MITC4 model skeleton tests pass | AMO-003 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object` |
-| AMO-TEST-004 | 4 | unit | material model headers missing | material base and linear elastic tests pass | AMO-004 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object` |
-| AMO-TEST-005 | 5 | unit | shell property model missing | shell property tests pass | AMO-005 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object` |
-| AMO-TEST-006 | 6 | unit | load model headers missing | load base and nodal load tests pass | AMO-006 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object` |
-| AMO-TEST-007 | 7 | unit | boundary model headers missing | boundary base and SPC tests pass | AMO-007 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object` |
-| AMO-TEST-008 | 8 | unit | Domain polymorphic APIs missing | Domain owns and retrieves model objects by base interface | AMO-008 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"` |
-| AMO-TEST-009 | 9 | regression | existing definition tests fail | existing Domain definition tests remain passing | AMO-009 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` |
-| AMO-TEST-010 | 10 | validation | report evidence missing | validation report records passing commands or classified failure | AMO-010 | `python scripts/validate_workspace.py` |
-
-## CMake/CTest Plan
-
-- target_candidates: `fesa_core`, `fesa_domain_tests`, `fesa_model_object_tests`
-- labels: `domain`, `core`, `model-object`, `element`, `material`, `property`, `load`, `boundary`
-- msvc_config: Debug
-- expected_feature_command: `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"`
-- workspace_validation: `python scripts/validate_workspace.py`
-
-## Candidate Files and Ownership
-
-| file_candidate | purpose | owner_boundary | notes |
-| --- | --- | --- | --- |
-| `include/fesa/core/Node.hpp` | existing node model object | core model definition | no solver state |
-| `include/fesa/element/Element.hpp` | abstract element model base | element model identity | no stiffness API |
-| `include/fesa/element/Mitc4Element.hpp` | MITC4 element model skeleton | element model identity | no formulation implementation |
-| `src/element/Mitc4Element.cpp` | MITC4 model accessors | element model identity | no numerical behavior |
-| `include/fesa/material/Material.hpp` | abstract material model base | material identity | no constitutive matrix |
-| `include/fesa/material/LinearElasticMaterial.hpp` | linear elastic material model | material input values | no stress update |
-| `src/material/LinearElasticMaterial.cpp` | linear elastic material accessors | material input values | no numerical behavior |
-| `include/fesa/property/ShellProperty.hpp` | shell property model | property input values | no section stiffness |
-| `src/property/ShellProperty.cpp` | shell property validation/accessors | property input values | thickness validation only |
-| `include/fesa/load/Load.hpp` | abstract load model base | load identity | no assembly |
-| `include/fesa/load/NodalLoad.hpp` | nodal load model | load input values | no global vector behavior |
-| `src/load/NodalLoad.cpp` | nodal load accessors | load input values | no assembly |
-| `include/fesa/boundary/BoundaryCondition.hpp` | abstract boundary model base | boundary identity | no matrix application |
-| `include/fesa/boundary/SinglePointConstraint.hpp` | SPC boundary model | boundary input values | no reaction recovery |
-| `src/boundary/SinglePointConstraint.cpp` | SPC accessors | boundary input values | no matrix application |
-| `include/fesa/core/Domain.hpp` | Domain ownership extension | core ownership | preserve existing APIs |
-| `src/core/Domain.cpp` | Domain ownership implementation | core ownership | no solver state |
-| `tests/**` | TDD coverage | tests | write before production changes |
-
-## Acceptance Traceability Matrix
-
-| requirement_id | task_id | test_id | reference_model_id | acceptance_criterion | status |
-| --- | --- | --- | --- | --- | --- |
-| AMO-REQ-001 Node is model data only | AMO-001 | AMO-TEST-001 | N/A | Node tests pass and no solver state added | draft |
-| AMO-REQ-002 Element base is identity-only | AMO-002 | AMO-TEST-002 | N/A | Element base tests pass | draft |
-| AMO-REQ-003 MITC4 model skeleton has 4 nodes and 24 DOFs | AMO-003 | AMO-TEST-003 | N/A | MITC4 model tests pass | draft |
-| AMO-REQ-004 Material model stores input values only | AMO-004 | AMO-TEST-004 | N/A | material tests pass | draft |
-| AMO-REQ-005 Shell property validates thickness only | AMO-005 | AMO-TEST-005 | N/A | shell property tests pass | draft |
-| AMO-REQ-006 Load and boundary models do not assemble/apply | AMO-006; AMO-007 | AMO-TEST-006; AMO-TEST-007 | N/A | load/boundary tests pass and APIs remain value accessors | draft |
-| AMO-REQ-007 Domain owns polymorphic model objects via RAII | AMO-008 | AMO-TEST-008 | N/A | Domain ownership tests pass | draft |
-| AMO-REQ-008 Existing definition APIs remain compatible | AMO-009 | AMO-TEST-009 | N/A | existing domain tests pass | draft |
-
-## Validation Commands
-
-```powershell
-python -m unittest discover -s scripts -p "test_*.py"
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"
-```
-
-## Risks and Downstream Handoff
-
-### Implementation Agent
-
-- Keep model objects identity-only until formulation and solver stages define numerical APIs.
-    - Preserve existing `*Definition` tests.
-- Prefer RAII ownership through `std::unique_ptr` and const retrieval.
-
-### Build/Test Executor Agent
-
-- Use Visual Studio 17 2022, x64, Debug, and `build/msvc-debug`.
-- Use `python scripts/validate_workspace.py` as canonical validation.
-
-### Correction Agent
-
-- Implementation-owned failures are expected to be compile or unit-test failures in model object headers, model object sources, CMake registration, or Domain ownership methods.
-- Upstream-contract failures include requests to add numerical MITC4 behavior or solver state in this phase.
-
-### Reference Verification Agent
-
-- No reference verification is required for this phase.
-- This phase produces no HDF5 result and consumes no reference artifacts.
-
-## Open Issues
-
-- Parser/factory mapping from `*Definition` DTOs to model objects remains deferred.
-- MITC4 formulation, material constitutive behavior, shell section stiffness, assembly, solver, and HDF5 output remain separate future phases.

docs/implementation-plans/analysis-state-analysis-base-implementation-plan.md

@@ -1,188 +0,0 @@
-# Analysis State And Analysis Base Implementation Plan
-
-## Metadata
-- feature_id: analysis-state-analysis-base
-- source_requirement: AGENTS.md; docs/PRD.md
-- source_research: N/A for this architecture foundation slice
-- source_formulation: N/A for this architecture foundation slice
-- source_numerical_review: N/A for this architecture foundation slice
-- source_io_definition: docs/ARCHITECTURE.md state ownership and analysis strategy rules
-- source_reference_models: N/A for this architecture foundation slice
-- status: ready-for-implementation
-- owner_agent: implementation-planning-agent
-- date: 2026-06-09
-
-## Readiness Check
-
-| input | required_status | observed_status | decision |
-| --- | --- | --- | --- |
-| architecture | Domain, Analysis, AnalysisState boundaries documented | documented in docs/ARCHITECTURE.md and ADR-010 | proceed |
-| domain foundation | Domain runtime storage available | implemented in prior phases | proceed |
-| formulation | not required for state/interface foundation | N/A | proceed |
-| numerical_review | not required for state/interface foundation | N/A | proceed |
-| io_definition | not required; no result output in this phase | N/A | proceed |
-| reference_models | not required because this phase produces no solver result | N/A | proceed |
-
-## Implementation Scope
-
-- included_behavior: `AnalysisState` mutable vector state for displacement, external force, internal force, residual, and reaction.
-- included_behavior: `AnalysisState` time, increment, and iteration counters.
-- included_behavior: `Analysis` base interface for future analysis strategies.
-- included_behavior: CMake/CTest registration for analysis-layer unit tests.
-- excluded_behavior: `AnalysisModel`, `DofManager`, equation numbering, global assembly, boundary-condition elimination, linear solve, MITC4 numerical formulation, HDF5 output, and reference comparison.
-- non_goals: numerical correctness claims, release readiness, reference-solver execution, and reference artifact generation.
-
-## AnalysisState Contract
-
-`AnalysisState` lives under `fesa::core` and owns mutable analysis quantities only. It does not reference or own `Domain`, model objects, equation maps, sparse matrices, solvers, result writers, or reference artifacts.
-
-Required interface:
-
-```cpp
-namespace fesa::core {
-
-class AnalysisState {
-public:
-    AnalysisState();
-    explicit AnalysisState(std::size_t dof_count);
-
-    std::size_t dofCount() const noexcept;
-    void resize(std::size_t dof_count);
-
-    const std::vector<double>& displacement() const noexcept;
-    const std::vector<double>& externalForce() const noexcept;
-    const std::vector<double>& internalForce() const noexcept;
-    const std::vector<double>& residual() const noexcept;
-    const std::vector<double>& reaction() const noexcept;
-
-    void setDisplacement(std::vector<double> values);
-    void setExternalForce(std::vector<double> values);
-    void setInternalForce(std::vector<double> values);
-    void setResidual(std::vector<double> values);
-    void setReaction(std::vector<double> values);
-    void clearForces() noexcept;
-
-    double currentTime() const noexcept;
-    void setCurrentTime(double value) noexcept;
-    std::int64_t incrementIndex() const noexcept;
-    void setIncrementIndex(std::int64_t value) noexcept;
-    std::int64_t iterationIndex() const noexcept;
-    void setIterationIndex(std::int64_t value) noexcept;
-};
-
-} // namespace fesa::core
-```
-
-This phase intentionally defers velocity, acceleration, temperature, element state, and integration-point state until dynamic, thermal, nonlinear, or element-state phases define concrete contracts.
-
-## Analysis Base Contract
-
-`Analysis` lives under `fesa::analysis` and is the base strategy interface for future analysis algorithms. `Domain` is immutable input. `AnalysisState` is mutable output/state.
-
-Required interface:
-
-```cpp
-namespace fesa::analysis {
-
-class Analysis {
-public:
-    virtual ~Analysis() = default;
-
-    virtual const char* name() const noexcept = 0;
-    void run(const fesa::core::Domain& domain, fesa::core::AnalysisState& state);
-
-protected:
-    virtual void doRun(const fesa::core::Domain& domain, fesa::core::AnalysisState& state) = 0;
-};
-
-} // namespace fesa::analysis
-```
-
-`Analysis::run` is only an entry-point wrapper in this phase. It does not define assembly, solve, boundary-condition, or output hooks until `AnalysisModel` and `DofManager` exist.
-
-## Work Breakdown
-
-| task_id | order | purpose | upstream_trace | depends_on | expected_test_first |
-| --- | --- | --- | --- | --- | --- |
-| ASAB-001 | 1 | record state and base-analysis contract | ADR-010; docs/ARCHITECTURE.md | none | N/A |
-| ASAB-002 | 2 | add `AnalysisState` zero-sized and sized state | ADR-010 AnalysisState | ASAB-001 | ASAB-TEST-001 |
-| ASAB-003 | 3 | add `AnalysisState` mutation guards and counters | docs/ARCHITECTURE.md State Ownership | ASAB-002 | ASAB-TEST-002 |
-| ASAB-004 | 4 | add `Analysis` base interface | docs/ARCHITECTURE.md Analysis strategy | ASAB-003 | ASAB-TEST-003 |
-| ASAB-005 | 5 | register analysis CTest path | AGENTS.md C++ validation | ASAB-004 | ASAB-TEST-004 |
-| ASAB-006 | 6 | record build/test evidence and handoff | docs/build-test-reports/README.md | ASAB-005 | ASAB-TEST-005 |
-
-## TDD Test Plan
-
-| test_id | order | test_type | red_condition | green_condition | linked_task | command |
-| --- | --- | --- | --- | --- | --- | --- |
-| ASAB-TEST-001 | 1 | unit | `AnalysisState` header/class missing | default and sized state tests pass | ASAB-002 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis` |
-| ASAB-TEST-002 | 2 | unit | setter/guard methods missing | mutation guard and counter tests pass | ASAB-003 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis` |
-| ASAB-TEST-003 | 3 | unit | `Analysis` header/base missing | derived recording analysis tests pass | ASAB-004 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis` |
-| ASAB-TEST-004 | 4 | integration | analysis tests not registered or not built | `ctest -R analysis` runs analysis target | ASAB-005 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "analysis|domain|model-object|io"` |
-| ASAB-TEST-005 | 5 | validation | report evidence missing | validation report records passing commands or classified failure | ASAB-006 | `python scripts/validate_workspace.py` |
-
-## CMake/CTest Plan
-
-- target_candidates: `fesa_core`, `fesa_analysis_tests`
-- add_test_needs: register `analysis.base`
-- labels: `analysis`, `core`
-- msvc_config: Debug
-- expected_feature_command: `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis`
-- workspace_validation: `python scripts/validate_workspace.py`
-
-## Candidate Files and Ownership
-
-| file_candidate | purpose | owner_boundary | notes |
-| --- | --- | --- | --- |
-| `include/fesa/core/AnalysisState.hpp` | mutable analysis state public contract | core state | no Domain/model object ownership |
-| `src/core/AnalysisState.cpp` | state vector/counter implementation | core state | no solver logic |
-| `include/fesa/analysis/Analysis.hpp` | base analysis strategy interface | analysis | no LinearStaticAnalysis implementation |
-| `tests/core/analysis_state_test.cpp` | state TDD coverage | tests | write before production changes |
-| `tests/analysis/analysis_base_test.cpp` | analysis base TDD coverage | tests | write before production changes |
-| `CMakeLists.txt` | source and CTest registration | build | MSVC Debug compatible |
-
-## Acceptance Traceability Matrix
-
-| requirement_id | task_id | test_id | reference_model_id | acceptance_criterion | status |
-| --- | --- | --- | --- | --- | --- |
-| ASAB-REQ-001 mutable state is outside Domain | ASAB-002 | ASAB-TEST-001 | N/A | AnalysisState tests pass and Domain remains unchanged | draft |
-| ASAB-REQ-002 state vectors are size-consistent | ASAB-003 | ASAB-TEST-002 | N/A | size mismatch throws and failed setters do not mutate | draft |
-| ASAB-REQ-003 Analysis takes const Domain and mutable state | ASAB-004 | ASAB-TEST-003 | N/A | recording analysis updates state through base API | draft |
-| ASAB-REQ-004 C++ validation path includes analysis tests | ASAB-005 | ASAB-TEST-004 | N/A | `ctest -R analysis` runs successfully | draft |
-
-## Validation Commands
-
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "analysis|domain|model-object|io"
-python -m unittest discover -s scripts -p "test_*.py"
-python scripts/validate_workspace.py
-git diff --check
-```
-
-## Risks and Downstream Handoff
-
-### Implementation Agent
-
-- Keep `AnalysisState` as storage only.
-- Keep `Analysis` as a base interface only.
-- Do not introduce `LinearStaticAnalysis` until `AnalysisModel` and `DofManager` contracts exist.
-
-### Build/Test Executor Agent
-
-- Use Visual Studio 17 2022, x64, Debug, and `build/msvc-debug`.
-- Use `python scripts/validate_workspace.py` as canonical validation.
-
-### Correction Agent
-
-- Implementation-owned failures are expected to be compile or unit-test failures in state headers, state sources, analysis header, analysis tests, or CMake registration.
-- Upstream-contract failures include requests to add equation numbering, assembly, solver behavior, HDF5 output, or numerical MITC4 behavior in this phase.
-
-### Reference Verification Agent
-
-- No reference verification is required for this phase.
-- This phase produces no HDF5 result and consumes no reference artifacts.
-
-## Open Issues
-
-- `AnalysisModel`, `DofManager`, and `LinearStaticAnalysis` remain separate downstream phases.

docs/implementation-plans/domain-model-foundation-implementation-plan.md

@@ -1,190 +0,0 @@
-# Domain Model Foundation Implementation Plan
-
-## Metadata
-- feature_id: domain-model-foundation
-- source_requirement: AGENTS.md; docs/ARCHITECTURE.md; docs/ADR.md
-- source_research: N/A for this architecture foundation slice
-- source_formulation: N/A for this architecture foundation slice
-- source_numerical_review: N/A for this architecture foundation slice
-- source_io_definition: docs/ARCHITECTURE.md input-model ownership rules
-- source_reference_models: N/A for this architecture foundation slice
-- status: ready-for-implementation
-- owner_agent: implementation-planning-agent
-- date: 2026-06-08
-
-## Readiness Check
-
-| input | required_status | observed_status | decision |
-| --- | --- | --- | --- |
-| architecture | Domain, AnalysisModel, AnalysisState, DofManager boundaries documented | documented in docs/ARCHITECTURE.md and docs/ADR.md | proceed |
-| requirements | Domain ownership rules documented | documented in AGENTS.md and docs/ARCHITECTURE.md | proceed |
-| formulation | not required for model-container storage | N/A | proceed |
-| numerical_review | not required for model-container storage | N/A | proceed |
-| io_definition | parser contract not required; semantic storage boundary documented | sufficient for Domain foundation | proceed |
-| reference_models | not required because this slice produces no solver result | N/A | proceed |
-
-## Implementation Scope
-
-- included_behavior: C++17 core model-definition storage for nodes, element definitions, material definitions, shell property definitions, sets, boundary conditions, nodal loads, and linear static step definitions.
-- included_behavior: CMake/CTest bootstrap for MSVC x64 Debug validation.
-- included_behavior: deterministic id validation and const retrieval APIs for stored model definitions.
-- excluded_behavior: MITC4 stiffness, shape functions, Jacobian checks, assembly, solver, reaction recovery, HDF5 output, Abaqus parser, MKL, TBB, and reference comparison.
-- non_goals: numerical correctness claims, release readiness, Abaqus/Nastran execution, and stored reference artifact generation.
-
-## Domain Contract
-
-`Domain` owns parsed model definitions only. It preserves the model that an input parser or factory layer creates and should be treated as immutable by analysis code after parsing/building is complete.
-
-Included model definitions:
-
-- nodes
-- element definitions
-- material definitions
-- shell property definitions
-- node sets
-- element sets
-- boundary conditions
-- nodal loads
-- analysis step definitions
-
-Excluded state:
-
-- equation ids
-- sparse matrix structure or values
-- reduced or full displacement vectors
-- residual vectors
-- reaction vectors
-- current time
-- increment counters
-- nonlinear iteration counters
-- element integration point state
-- MKL, TBB, or HDF5 handles
-
-Boundary responsibilities:
-
-- `DofManager` owns active DOF discovery, constrained/free DOF mapping, equation numbering, sparse pattern connectivity, and full-vector reconstruction.
-- `AnalysisModel` owns the step-local execution view over active domain objects. It references `Domain` objects by id or stable reference and does not copy the whole domain.
-- `AnalysisState` owns mutable solution, residual, load vector, time/increment, and future element state.
-
-Common data rules:
-
-- All ids use signed 64-bit storage.
-- Node DOF order is `U1, U2, U3, UR1, UR2, UR3`.
-- Coordinates and scalar physical values use `double`.
-- Units are user-consistent and are not enforced or converted by `Domain`.
-- Duplicate ids fail with `std::invalid_argument`.
-- Insertions that reference missing required objects fail with `std::invalid_argument`.
-- Direct lookup of a missing object fails with `std::out_of_range`.
-- Optional `find*` lookup APIs return `nullptr` for missing objects.
-- Retrieval APIs return const references or const pointers.
-
-## Work Breakdown
-
-| task_id | order | purpose | upstream_trace | depends_on | expected_test_first |
-| --- | --- | --- | --- | --- | --- |
-| TASK-001 | 1 | Bootstrap CMake, core target, and CTest for Domain tests | ADR-002 | none | TEST-001 |
-| TASK-002 | 2 | Define signed 64-bit id aliases and six-DOF ordering constants | ADR-014; AGENTS.md MITC4 scope | TASK-001 | TEST-002 |
-| TASK-003 | 3 | Add `Node` and node storage/retrieval in `Domain` | ADR-010; docs/ARCHITECTURE.md Domain section | TASK-002 | TEST-003 |
-| TASK-004 | 4 | Add MITC4 element definition storage without element computation | ADR-004; docs/ARCHITECTURE.md Core Runtime Objects | TASK-003 | TEST-004 |
-| TASK-005 | 5 | Add material, shell property, node set, and element set storage | docs/ARCHITECTURE.md Domain included data | TASK-004 | TEST-005 |
-| TASK-006 | 6 | Add boundary condition, nodal load, and linear static step definition storage | ADR-012; docs/ARCHITECTURE.md Domain included data | TASK-005 | TEST-006 |
-| TASK-007 | 7 | Lock down Domain invariants and failed-insert stability | ADR-010; docs/AGENT_RULES.md boundaries | TASK-006 | TEST-007 |
-| TASK-008 | 8 | Record build/test evidence and handoff status | docs/build-test-reports/README.md | TASK-007 | TEST-008 |
-
-## TDD Test Plan
-
-| test_id | order | test_type | red_condition | green_condition | linked_task | command |
-| --- | --- | --- | --- | --- | --- | --- |
-| TEST-001 | 1 | CTest bootstrap | `domain.bootstrap` is not registered or cannot run | `domain.bootstrap` passes under MSVC Debug | TASK-001 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain.bootstrap` |
-| TEST-002 | 2 | unit | `fesa/core/ModelTypes.hpp` is missing | id aliases are 64-bit and DOF ordinals are 0..5 | TASK-002 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` |
-| TEST-003 | 3 | unit | `Node` and `Domain` node APIs are missing | add/find/direct lookup/duplicate node tests pass | TASK-003 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` |
-| TEST-004 | 4 | unit | element definition APIs are missing | element add/find/direct lookup/connectivity/missing-node tests pass | TASK-004 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` |
-| TEST-005 | 5 | unit | material, property, and set APIs are missing | material/property/set validation tests pass | TASK-005 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` |
-| TEST-006 | 6 | unit | boundary, load, and step APIs are missing | BC/load/step storage tests pass | TASK-006 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` |
-| TEST-007 | 7 | unit | failed insertion mutates Domain or mutable access leaks | invariant and failed-insert stability tests pass | TASK-007 | `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain` |
-| TEST-008 | 8 | validation | build/test evidence is missing | build/test report records passing validation or classified failure | TASK-008 | `python scripts/validate_workspace.py` |
-
-## CMake/CTest Plan
-
-- target_candidates: `fesa_core`, `fesa_domain_tests`
-- add_test_needs: `domain.bootstrap` initially, then Domain behavior tests under the same `domain` CTest filter.
-- labels: `domain`, `core`
-- msvc_config: Debug
-- expected_feature_command: `ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain`
-- workspace_validation: `python scripts/validate_workspace.py`
-
-## Candidate Files and Ownership
-
-| file_candidate | purpose | owner_boundary | notes |
-| --- | --- | --- | --- |
-| `CMakeLists.txt` | root CMake project, core library, CTest registration | build/test bootstrap | MSVC x64 Debug baseline |
-| `include/fesa/core/ModelTypes.hpp` | id aliases and DOF constants | core model definitions | no solver state |
-| `include/fesa/core/Node.hpp` | node id and coordinate definition | core model definitions | no displacement storage |
-| `include/fesa/core/ElementDefinition.hpp` | element id, type, connectivity, property reference | core model definitions | no stiffness behavior |
-| `include/fesa/core/MaterialDefinition.hpp` | linear elastic material input definition | core model definitions | no constitutive matrix |
-| `include/fesa/core/PropertyDefinition.hpp` | shell property input definition | core model definitions | no section stiffness |
-| `include/fesa/core/BoundaryCondition.hpp` | prescribed DOF value definition | core model definitions | no matrix application |
-| `include/fesa/core/LoadDefinition.hpp` | nodal load definition | core model definitions | no global vector assembly |
-| `include/fesa/core/StepDefinition.hpp` | linear static step definition | core model definitions | no analysis driver |
-| `include/fesa/core/Domain.hpp` | Domain public storage/retrieval API | core model definitions | const retrieval only |
-| `src/core/Domain.cpp` | Domain validation and storage implementation | core model definitions | no external dependencies |
-| `tests/core/domain_bootstrap_test.cpp` | CTest bootstrap executable | test | created before production code |
-| `tests/core/model_types_test.cpp` | id and DOF tests | test | optional separate executable |
-| `tests/core/domain_storage_test.cpp` | Domain behavior tests | test | required before production changes |
-
-## Data Flow Contract
-
-1. A future Abaqus parser and factory/registry layer creates semantic model definitions.
-2. `Domain` stores those definitions and validates duplicate ids and missing required references.
-3. A future `AnalysisModel` builds a step-local execution view from `Domain` ids or stable references.
-4. A future `DofManager` derives active DOFs and equation ids outside `Domain`.
-5. A future `AnalysisState` stores solution and iteration state outside `Domain`.
-
-## Acceptance Traceability Matrix
-
-| requirement_id | task_id | test_id | reference_model_id | acceptance_criterion | status |
-| --- | --- | --- | --- | --- | --- |
-| DOM-REQ-001 Domain owns parsed model definitions | TASK-003 to TASK-006 | TEST-003 to TEST-006 | N/A | storage and const retrieval tests pass | draft |
-| DOM-REQ-002 Domain excludes solver state | TASK-007 | TEST-007 | N/A | invariant tests and member review pass | draft |
-| DOM-REQ-003 ids use signed 64-bit storage | TASK-002 | TEST-002 | N/A | `sizeof(Id) == 8` test passes | draft |
-| DOM-REQ-004 node DOF order is fixed | TASK-002 | TEST-002 | N/A | DOF ordinal test passes | draft |
-| DOM-REQ-005 duplicate ids are rejected | TASK-003 to TASK-006 | TEST-003 to TEST-006 | N/A | duplicate tests throw `std::invalid_argument` | draft |
-| DOM-REQ-006 missing required references are rejected | TASK-004 to TASK-006 | TEST-004 to TEST-006 | N/A | missing-reference tests throw `std::invalid_argument` | draft |
-| DOM-REQ-007 direct missing lookup is deterministic | TASK-003 to TASK-007 | TEST-003 to TEST-007 | N/A | direct missing lookup throws `std::out_of_range` | draft |
-| DOM-REQ-008 validation uses MSVC CMake/CTest | TASK-001; TASK-008 | TEST-001; TEST-008 | N/A | configure/build/CTest evidence recorded | draft |
-
-## Validation Commands
-
-```powershell
-python -m unittest discover -s scripts -p "test_*.py"
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain
-```
-
-## Risks and Downstream Handoff
-
-### Implementation Agent
-
-- Keep each storage layer separate and test-first.
-- Do not add numerical behavior while implementing model definitions.
-- Preserve `Domain` as a model container, not a solver-state object.
-
-### Build/Test Executor Agent
-
-- Use Visual Studio 17 2022, x64, Debug, and `build/msvc-debug`.
-- After `CMakeLists.txt` exists, `python scripts/validate_workspace.py` must configure, build, and run CTest instead of taking the no-CMake path.
-
-### Correction Agent
-
-- Implementation-owned failures are expected to be compile or unit-test failures in `fesa_core` or `fesa_domain_tests`.
-- Upstream-contract failures include requests to store equation ids, displacements, reaction vectors, or integration point state inside `Domain`.
-
-### Reference Verification Agent
-
-- No reference verification is required for this phase.
-- This phase produces no HDF5 result and consumes no reference artifacts.
-
-## Open Issues
-
-- The full MITC4 requirements, formulation, I/O definition, and reference model artifacts are still separate upstream stages.
-- The parser-to-Domain factory API is intentionally deferred until the Abaqus input subset phase.

docs/implementation-plans/domain-runtime-storage-implementation-plan.md

@@ -1,98 +0,0 @@
-# Domain Runtime Storage Implementation Plan
-
-## Objective
-
-Make `Domain` store runtime model objects as its canonical model representation instead of persisting parser-style definition DTOs.
-
-This follows the approved direction:
-
-```text
-Abaqus .inp parser
--> temporary parsed or semantic records
--> factory / DomainBuilder
--> Domain owns runtime objects
-```
-
-The parser and factory are not implemented in this phase. Definition DTOs may remain as temporary parser/factory-local records, but `Domain` must not use them as persistent storage.
-
-## Phase Overview
-
-1. `runtime-storage-contract`
-   - Record the migration contract and clarify which model objects are canonical in `Domain`.
-   - Keep parser/factory work out of scope.
-
-2. `element-material-property-runtime-storage`
-   - Store elements as `fesa::element::Element`.
-   - Store materials as `fesa::material::Material`.
-   - Store shell properties as `fesa::property::ShellProperty`.
-   - Move `ElementType` to `ModelTypes.hpp` so runtime element interfaces do not depend on `ElementDefinition`.
-
-3. `load-boundary-runtime-storage`
-   - Store loads as `fesa::load::Load`.
-   - Store boundary conditions as `fesa::boundary::BoundaryCondition`.
-   - Validate runtime `NodalLoad` and `SinglePointConstraint` node references during insertion.
-
-4. `step-and-set-runtime-references`
-   - Validate element sets against runtime elements.
-   - Validate step load and boundary indices against runtime containers.
-   - Keep `LinearStaticStepDefinition` as a step configuration record until a dedicated runtime step object is designed.
-
-5. `legacy-definition-extraction`
-   - Remove `core::*Definition` DTOs from `Domain` includes, fields, and public API.
-   - Keep focused DTO tests only for parser/factory-local record compatibility.
-
-6. `validation-report-handoff`
-   - Run harness and CMake/CTest validation.
-   - Update project handoff documents with concrete evidence.
-
-## Canonical Domain Storage
-
-`Domain` stores:
-
-- `fesa::core::Node` values;
-- `std::unique_ptr<fesa::element::Element>`;
-- `std::unique_ptr<fesa::material::Material>`;
-- `fesa::property::ShellProperty` values;
-- `std::unique_ptr<fesa::load::Load>`;
-- `std::unique_ptr<fesa::boundary::BoundaryCondition>`;
-- node sets and element sets by id;
-- `LinearStaticStepDefinition` as a temporary step configuration record.
-
-`Domain` must not store:
-
-- `ElementDefinition`;
-- `LinearElasticMaterialDefinition`;
-- `ShellPropertyDefinition`;
-- `NodalLoadDefinition`;
-- `fesa::core::BoundaryCondition`.
-
-## Non-Goals
-
-- No Abaqus parser implementation.
-- No factory/registry implementation.
-- No MITC4 stiffness, mass, residual, stress, or tangent implementation.
-- No equation numbering or solver state in `Domain`.
-- No HDF5, MKL, TBB, reference artifact, tolerance, or formulation changes.
-
-## Tests
-
-Primary C++ tests:
-
-- `/tests/core/domain_storage_test.cpp`
-- `/tests/core/domain_model_object_test.cpp`
-- `/tests/core/model_types_test.cpp`
-- `/tests/element/element_base_test.cpp`
-- `/tests/element/mitc4_element_model_test.cpp`
-- `/tests/material/material_base_test.cpp`
-- `/tests/property/shell_property_test.cpp`
-- `/tests/load/load_base_test.cpp`
-- `/tests/boundary/boundary_base_test.cpp`
-
-Required validation:
-
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"
-python -m unittest discover -s scripts -p "test_*.py"
-python scripts/validate_workspace.py
-git diff --check
-```

docs/implementation-plans/property-model-foundation-implementation-plan.md

@@ -1,108 +0,0 @@
-# Property Model Foundation Implementation Plan
-
-## Objective
-
-Introduce a runtime `Property` base class for element property and section objects, then make `ShellProperty` and `Domain` use that base class consistently.
-
-This phase keeps property objects as model data only. It does not implement shell section stiffness, constitutive matrices, assembly, solver logic, HDF5 output, or reference comparison.
-
-## Phase Overview
-
-1. `property-base-contract`
-   - Record the runtime property model contract and exclusions.
-
-2. `property-base-interface`
-   - Add `PropertyKind` and abstract `Property`.
-   - Add unit tests for polymorphic use and virtual deletion.
-
-3. `shell-property-polymorphism`
-   - Make `ShellProperty` derive from `Property`.
-   - Preserve id, material id, thickness, and positive-thickness validation.
-
-4. `domain-property-ownership`
-   - Change `Domain` property storage to `std::unique_ptr<Property>`.
-   - Validate duplicate property ids and shell-property material references.
-   - Validate element property references against runtime property storage.
-
-5. `validation-report-handoff`
-   - Run targeted CTest, harness self-tests, workspace validation, and whitespace checks.
-   - Update handoff documents.
-
-## Runtime Property Contract
-
-`Property` represents element property and section data that is owned by `Domain` and referenced by elements through `PropertyId`.
-
-Required interface:
-
-```cpp
-namespace fesa::property {
-
-enum class PropertyKind {
-    Shell
-};
-
-class Property {
-public:
-    virtual ~Property() = default;
-
-    virtual PropertyId id() const noexcept = 0;
-    virtual PropertyKind kind() const noexcept = 0;
-};
-
-} // namespace fesa::property
-```
-
-`ShellProperty`:
-
-- derives from `Property`;
-- returns `PropertyKind::Shell`;
-- stores `PropertyId`, `MaterialId`, and thickness;
-- rejects non-positive thickness;
-- does not compute shell stiffness in this phase.
-
-## Domain Contract
-
-`Domain` stores runtime property objects by ownership:
-
-```cpp
-std::unordered_map<PropertyId, std::unique_ptr<fesa::property::Property>>
-```
-
-`Domain` validates:
-
-- null property pointer rejection;
-- duplicate property id rejection;
-- missing material id for `ShellProperty`;
-- missing property id for elements.
-
-## Hdf5ResultWriter Constraint
-
-The adjacent `Hdf5ResultWriter` work requested for this slice is limited to a skeleton class only. It may expose construction and basic path access, but it must not link HDF5, create files, define result datasets, write metadata, or claim HDF5 output support.
-
-## Non-Goals
-
-- No MITC4 element formulation.
-- No shell section stiffness.
-- No material constitutive behavior.
-- No DofManager work.
-- No assembly, solver, sparse matrix, or reaction recovery.
-- No HDF5 file writing or result schema implementation.
-- No parser/factory implementation.
-
-## Tests
-
-Primary C++ tests:
-
-- `/tests/property/property_base_test.cpp`
-- `/tests/property/shell_property_test.cpp`
-- `/tests/core/domain_storage_test.cpp`
-- `/tests/core/domain_model_object_test.cpp`
-
-Required validation:
-
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"
-python -m unittest discover -s scripts -p "test_*.py"
-python scripts/validate_workspace.py
-git diff --check
-```

docs/io-definitions/README.md

@@ -4,25 +4,24 @@
 
 FESA 솔버의 입력 파일은 Abaqus input file이다. 다만 초기 FESA는 Abaqus 전체 문법 호환을 목표로 하지 않고, 기능별로 지원할 Abaqus keyword subset과 내부 모델 매핑을 명확히 정의한다.
 
-기본 파일명은 `docs/io-definitions/<feature-id>-io.md` 형식을 사용한다. 각 문서는 Requirement Agent, Formulation Agent, Numerical Review Agent의 산출물을 입력으로 받아 Abaqus `.inp` 입력 계약과 HDF5 결과/reference schema를 정의해야 한다. CSV는 upstream 요구조건이 명시한 export 또는 comparison helper가 있을 때만 추가로 정의한다.
+기본 파일명은 `docs/io-definitions/<feature-id>-io.md` 형식을 사용한다. 각 문서는 Requirement Agent, Formulation Agent, Numerical Review Agent의 산출물을 입력으로 받아 Abaqus `.inp` 입력 계약과 결과 CSV schema를 정의해야 한다.
 
 ## I/O Definition Agent 역할
 
-I/O Definition Agent는 Abaqus input file subset, 내부 solver model mapping, output request mapping, HDF5 result/reference schema, optional CSV export schema를 정의한다.
+I/O Definition Agent는 Abaqus input file subset, 내부 solver model mapping, output request mapping, comparison CSV schema를 정의한다.
 
 수행한다:
 - 기능별 supported Abaqus keyword subset을 정의한다.
 - unsupported, ignored-with-warning, requires-user-decision keyword 정책을 정의한다.
 - model data와 history data를 내부 solver 개념으로 매핑한다.
 - node, element, set, material, section, boundary condition, load, step, output request의 의미 계약을 정의한다.
-- `results.h5`의 metadata, mesh, step/frame, nodal/element field output, history output dataset schema를 정의한다.
-- upstream 요구조건이 명시한 경우에만 `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv` 같은 optional CSV export schema를 정의한다.
+- `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv` schema를 정의한다.
 
 수행하지 않는다:
 - parser를 구현하지 않는다.
 - C++ API나 파일 구조를 설계하지 않는다.
 - Abaqus, Nastran 또는 레퍼런스 솔버를 직접 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV 결과를 생성하지 않는다.
+- reference CSV 결과를 생성하지 않는다.
 - solver 결과와 reference 결과를 비교하지 않는다.
 - release readiness를 승인하지 않는다.
 - 명시적으로 정의되지 않은 Abaqus full compatibility를 주장하지 않는다.
@@ -108,43 +107,7 @@ I/O Definition Agent는 Abaqus input file subset, 내부 solver model mapping, o
 - step: <semantic contract>
 - output_request: <semantic contract>
 
-## HDF5 Result and Reference Schemas
-
-### results.h5
-
-```text
-/metadata
-  feature_id
-  solver_version
-  model_id
-  hdf5_version
-  schema_version
-  units
-  tolerance
-  reference_solver
-
-/mesh/nodes
-/mesh/elements/<element-family>/connectivity
-
-/results/step_<id>/frame_<id>/nodal/<quantity>
-/results/step_<id>/frame_<id>/element/<quantity>
-/results/step_<id>/frame_<id>/history
-```
-
-각 dataset은 path, shape, datatype, ID field, component naming, coordinate system, units, output location, step/frame identity, ID matching rule을 명시해야 한다.
-
-### Required MITC4 Quantity Datasets
-
-| quantity | default dataset path | id/matching fields | component contract |
-| --- | --- | --- | --- |
-| nodal displacement | `/results/step_000/frame_000/nodal/displacement` | node id, component | `U1, U2, U3, UR1, UR2, UR3` |
-| nodal reaction | `/results/step_000/frame_000/nodal/reaction` | node id, component | `RF1, RF2, RF3, RM1, RM2, RM3` |
-| element force/resultant | `/results/step_000/frame_000/element/forces` | element id, Gauss point, component | `N11, N22, N12, M11, M22, M12, Q13, Q23` |
-| stress | `/results/step_000/frame_000/element/stress` | element id, Gauss point, section point, component | `S11, S22, S12, S13, S23` |
-
-## Optional CSV Export Schemas
-
-CSV output is not required for the current MITC4 HDF5-first feature unless an upstream requirement explicitly asks for it. When CSV export is required, it must preserve the same IDs, components, units, coordinate system, output location, and step/frame identity as the HDF5 datasets.
+## Output and CSV Schemas
 
 ### displacements.csv
 | column | type | description |
@@ -198,13 +161,13 @@ CSV output is not required for the current MITC4 HDF5-first feature unless an up
 ## Open Issues and Downstream Handoff
 
 ### Reference Model Agent
-- <Abaqus input examples and HDF5 reference artifact schema needs>
+- <Abaqus input examples and reference artifact schema needs>
 
 ### Implementation Planning Agent
-- <parser acceptance cases, unsupported keyword diagnostics, HDF5 writer tests, optional CSV export tests>
+- <parser acceptance cases, unsupported keyword diagnostics, CSV writer tests>
 
 ### Reference Verification Agent
-- <HDF5 dataset schemas, optional CSV schemas, ID matching rules, units, coordinate conventions, tolerance-relevant fields>
+- <CSV schemas, ID matching rules, units, coordinate conventions, tolerance-relevant fields>
 ```
 
 ## 품질 기준
@@ -214,5 +177,4 @@ CSV output is not required for the current MITC4 HDF5-first feature unless an up
 - model data와 history data의 매핑을 구분해야 한다.
 - unsupported keyword 처리 정책을 명확히 해야 한다.
 - 내부 모델 계약은 semantic fields로 작성하고 C++ class/function/API를 확정하지 않는다.
-- HDF5 schema는 dataset path, shape, datatype, ID field, component naming, coordinate system, units, step/frame identity, quantity location을 포함해야 한다.
-- Optional CSV schema는 명시적으로 요구된 경우에만 정의하며, HDF5 schema와 동일한 물리 의미와 matching rule을 유지해야 한다.
+- CSV schema는 column name, ID field, component naming, coordinate system, units, step/frame identity, quantity location을 포함해야 한다.

docs/numerical-reviews/README.md

@@ -20,7 +20,7 @@ Numerical Review Agent는 정식화의 수학적 일관성, 수치 안정성 위
 - 정식화 문서를 직접 수정하지 않는다.
 - C++ API나 파일 구조를 설계하지 않는다.
 - Abaqus, Nastran 또는 레퍼런스 솔버를 직접 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV 결과를 생성하지 않는다.
+- reference CSV 결과를 생성하지 않는다.
 - release readiness를 승인하지 않는다.
 - 레퍼런스 결과와 구현 솔버 결과의 일치 여부를 판정하지 않는다.
 

docs/physics-evaluations/README.md

@@ -23,7 +23,7 @@ Physics Evaluation Agent는 Reference Verification Agent가 `pass-for-physics-ev
 - requirements, formulations, I/O contracts, reference model contracts를 수정하지 않는다.
 - reference artifacts 또는 tolerance policies를 수정하지 않는다.
 - Abaqus, Nastran 또는 reference solver를 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV를 생성하지 않는다.
+- reference CSV를 생성하지 않는다.
 - reference tolerance를 다시 판정하지 않는다.
 - release readiness를 승인하지 않는다.
 - release notes 또는 final release checklist를 작성하지 않는다.
@@ -39,7 +39,7 @@ EVIDENCE CHECK -> PHYSICS CHECKS -> CLASSIFY -> REPORT
 `EVIDENCE CHECK`에서 다음 항목을 확인한다.
 
 - Reference Verification report status가 `pass-for-physics-evaluation`인지 여부
-- checked solver/reference HDF5 files or approved optional CSV extracts
+- checked solver/reference CSVs
 - compared quantities
 - model purpose
 - documented physical expectations
@@ -93,7 +93,7 @@ EVIDENCE CHECK -> PHYSICS CHECKS -> CLASSIFY -> REPORT
 | evidence | path_or_source | status | notes |
 | --- | --- | --- | --- |
 | reference_verification | docs/reference-verifications/<feature-id>-reference-verification.md | pass-for-physics-evaluation | <summary> |
-| solver_results | <solver results.h5 path or approved CSV extract path> | present | missing | <summary> |
+| solver_results | <solver CSV path> | present | missing | <summary> |
 | reference_results | references/<feature-id>/<model-id>/ | present | missing | <summary> |
 | model_purpose | docs/reference-models/<feature-id>-reference-models.md | documented | missing | <summary> |
 | physical_expectations | <source docs> | documented | missing | <summary> |

docs/project-plan/SOLVER_ARCHITECTURE_INITIAL_DISIGN.md

@@ -1,251 +0,0 @@
-# 솔버 설계 문서
-
-## 목표
-FESA는 MITC4 Shell 요소 기반 구조해석에서 시작해 비선형 정적해석, 비선형 동적해석, 열전달 및 thermal-stress coupling, 1D/3D 요소까지 확장하는 유한요소 솔버이다.
-초기 구현은 정확도와 테스트 가능성을 우선한다. 단, 대규모 모델을 목표로 하므로 자유도 관리, 희소 행렬 조립, 선형 솔버, 병렬 실행 계층은 초기부터 성능 확장이 가능하도록 분리한다.
-
-## 설계 원칙
-- Domain 객체는 입력 모델의 의미를 보존하고 가능한 한 불변에 가깝게 유지한다.
-- 해석 중 변하는 물리량과 반복 상태는 AnalysisState에 명시적으로 분리한다.
-- 요소, 재료, 하중, 경계조건, 해석 알고리즘은 런타임 다형성 기반으로 확장한다.
-- 결과는 step/frame/field/history 개념으로 저장하여 정적, 비선형, 동적, 열전달 해석을 같은 결과 모델로 다룬다.
-- 외부 라이브러리(MKL, TBB, HDF5)는 adapter 계층 뒤에 둔다.
-- Abaqus input 호환성은 파서와 factory/registry 계층에서 관리한다.
-- shell node는 6자유도이고, 단위계는 강제하지 않으며, 결과 부호는 Abaqus 규약을 따른다.
-- 경계조건은 constrained DOF 제거 방식으로 적용하고, reaction은 full vector 기준 `K_full * U_full - F_full`로 계산한다.
-- 기본 실수 precision은 `double`이고, 대규모 모델을 위해 id/index/equation numbering은 int64 기반으로 설계한다.
-- Mesh quality 진단은 1차 범위에서 제외한다. 대신 singular system 진단은 필수로 제공한다.
-
-## 디렉토리 구조
-```
-src/
-├── Analysis/        # Static, nonlinear static, dynamic, heat transfer analysis
-├── Assembly/        # 전역 행렬/벡터 조립, sparse pattern 생성
-├── Boundary/        # Fix, RBE2, RBE3 등 경계조건
-├── Core/            # Domain, AnalysisModel, AnalysisState, DofManager
-├── Element/         # Node, Element, MITC4 등 요소 구현
-├── IO/              # Abaqus input parser, HDF5 results writer
-├── Load/            # NodalLoad, PressureLoad, BodyForce 등 하중
-├── Math/            # Vector, Matrix, SparseMatrix, MKL adapter
-├── Material/        # LinearElastic 등 재료 모델
-├── Property/        # ShellProperty, 1D/2D/3D property
-├── Results/         # Step, Frame, FieldOutput, HistoryOutput
-└── Util/            # 공통 유틸리티, 로깅, 검증 보조 함수
-```
-
-## 핵심 클래스 구조
-```
-Domain
-├── Node
-├── Element
-├── Material
-├── Property
-├── NodeSet
-├── ElementSet
-├── BoundaryCondition
-├── Load
-└── StepDefinition
-
-AnalysisModel
-├── active elements
-├── active loads
-├── active boundary conditions
-├── active properties/materials
-└── equation system view
-
-AnalysisState
-├── displacement U
-├── velocity V
-├── acceleration A
-├── temperature T
-├── external force Fext
-├── internal force Fint
-├── residual R
-├── current time / increment / iteration
-└── element state / integration point state
-
-DofManager
-├── node dof definitions
-├── constrained/free dof mapping
-├── equation numbering
-├── sparse matrix pattern ownership
-└── full/reduced vector reconstruction
-
-Analysis
-├── LinearStaticAnalysis
-├── NonlinearStaticAnalysis
-├── DynamicAnalysis
-├── FrequencyAnalysis
-└── HeatTransferAnalysis
-
-Element
-├── 1DElement
-│   ├── Truss
-│   └── Beam
-├── 2DElement
-│   ├── MITC3
-│   └── MITC4
-└── 3DElement
-    ├── Hexahedral
-    ├── Tetrahedral
-    ├── Wedge
-    └── Pyramid
-
-BoundaryCondition
-├── Fix
-├── RBE2
-└── RBE3
-
-Load
-├── NodalLoad
-├── PressureLoad
-└── BodyForce
-
-Results
-├── ResultStep
-├── ResultFrame
-├── FieldOutput
-└── HistoryOutput
-
-InputParser
-ResultsWriter
-Assembler
-LinearSolver
-Vector
-Matrix
-SparseMatrix
-```
-
-## 디자인 패턴
-
-### Strategy Pattern
-해석 알고리즘과 수치 알고리즘을 교체 가능하게 구성한다.
-
-적용 대상:
-- `Analysis`: `LinearStaticAnalysis`, `NonlinearStaticAnalysis`, `DynamicAnalysis`, `HeatTransferAnalysis`
-- `LinearSolver`: `MKLPardisoSolver`, 향후 iterative solver
-- `TimeIntegrator`: `HHTIntegrator`, 향후 Newmark 등
-- `ConvergenceCriteria`: residual norm, displacement norm, energy norm
-
-### Template Method Pattern
-해석 실행의 큰 흐름은 `Analysis::run()`에서 고정하고, 세부 단계는 해석 종류별로 재정의한다.
-
-기본 흐름:
-```
-initialize
-buildAnalysisModel
-buildDofMap
-buildSparsePattern
-assemble
-applyBoundaryConditions
-solve
-updateState
-writeResults
-```
-
-비선형 정적해석은 위 흐름을 Newton-Raphson 반복 루프 안에서 사용하고, 동적해석은 time step/frame 루프 안에서 사용한다.
-
-### Factory + Registry Pattern
-Abaqus input keyword와 내부 객체 생성을 분리한다.
-
-예:
-- `*Element, type=S4` -> `MITC4ElementFactory`
-- `*Material`, `*Elastic` -> `LinearElasticMaterialFactory`
-- `*Boundary` -> `FixBoundaryFactory`
-- `*Cload` -> `NodalLoadFactory`
-- `*Nset`, `*Elset` -> set registry
-
-요소, 재료, 하중, 경계조건 타입 추가 시 parser 본체의 변경을 최소화한다.
-
-### Adapter Pattern
-MKL, TBB, HDF5 API는 solver core에 직접 노출하지 않는다.
-
-적용 대상:
-- `SparseMatrix`, `Vector`, `Matrix`
-- `LinearSolver`
-- `ParallelFor`
-- `ResultsWriter`
-
-외부 라이브러리 교체 또는 테스트 double 사용이 가능하도록 adapter 계층에서 의존성을 제한한다.
-
-### Runtime Polymorphism
-요소, 재료, 하중, 경계조건은 base interface를 통해 다룬다. Phase 1에서는 명확성과 테스트 가능성을 우선하고, 대규모 모델 성능 최적화가 필요할 경우 assembly 내부에서 타입별 batch 처리 또는 kernel 분리를 추가한다.
-
-## 상태 관리
-
-### Domain
-`Domain`은 입력 파일에서 만들어진 전체 모델 정의를 소유한다. 파싱 이후에는 가능한 한 불변으로 취급한다.
-
-포함 대상:
-- nodes, elements
-- materials, properties
-- node sets, element sets
-- loads, boundary conditions
-- analysis step definitions
-
-### AnalysisModel
-`AnalysisModel`은 현재 step에서 활성화되는 해석 객체들의 실행 view이다. `Domain`을 복사하지 않고 참조 또는 id 기반 view로 구성한다.
-
-포함 대상:
-- active elements
-- active loads
-- active boundary conditions
-- active property/material references
-- current equation system view
-
-### DofManager
-`DofManager`는 자유도와 방정식 번호를 전담한다. Node 또는 Element 내부에 equation id를 분산 저장하지 않는다.
-
-책임:
-- node별 활성 자유도 정의
-- constrained/free dof mapping
-- equation numbering
-- sparse matrix pattern 생성에 필요한 connectivity 제공
-- 경계조건 적용 전후의 dof view 관리
-
-### AnalysisState
-`AnalysisState`는 해석 중 변하는 물리량과 반복 상태를 소유한다.
-
-포함 대상:
-- displacement, velocity, acceleration
-- temperature
-- external force, internal force, residual
-- current time, increment, Newton iteration
-- element state, integration point state
-
-Phase 1에서는 displacement 중심으로 최소 구현하되, 기하비선형과 thermal-stress coupling을 위해 element/internal state 확장 지점을 유지한다.
-
-### Results State
-결과는 `ResultStep` -> `ResultFrame` -> `FieldOutput`/`HistoryOutput` 구조로 관리한다.
-
-- `ResultStep`: 해석 step 단위 결과
-- `ResultFrame`: 정적해석의 load increment 또는 동적해석의 time frame
-- `FieldOutput`: node/element field 결과
-- `HistoryOutput`: 특정 node, element, set, reaction, energy 등의 이력 결과
-
-## 데이터 흐름
-```
-Abaqus input file
--> InputParser
--> Domain 생성
--> StepDefinition 루프
--> AnalysisModel 생성
--> DofManager로 자유도/방정식 번호 생성
--> sparse pattern 생성
--> Analysis 실행
--> Assembler로 전역 행렬/벡터 조립
--> BoundaryCondition 적용
--> LinearSolver 또는 nonlinear/time integration loop
--> AnalysisState 갱신
--> ResultsWriter로 step/frame/history 저장
--> 다음 step 진행
-```
-
-## 성능 확장 방향
-- 행렬 조립은 element 단위 병렬화를 고려해 설계한다.
-- 전역 행렬은 대규모 모델을 위해 sparse matrix를 기본으로 한다.
-- MKL 기반 direct solver를 우선 지원하되, solver interface는 iterative solver를 추가할 수 있게 둔다.
-- 대규모 sparse solve를 위해 MKL `pardiso_64`를 사용할 수 있도록 64-bit sparse index 경계를 유지한다.
-- TBB 병렬화는 요소 stiffness 계산, element force 계산, assembly precompute 등 독립 작업부터 적용한다.
-- 정확도 검증이 끝나기 전에는 MITC4 element formulation을 과도하게 최적화하지 않는다.
-

docs/project-plan/SOLVER_IMPLEMENT_INITIAL_PLAN.md

@@ -1,314 +0,0 @@
-# MITC4 Linear Static Shell Solver Initial Implementation Plan
-
-## Summary
-FESA will implement an initial finite element structural solver feature named `mitc4-linear-static-shell`. The feature reads an Abaqus-style input file, builds an internal finite element model, performs linear static analysis with a MITC4 shell element, writes HDF5 results, and verifies those results against stored Abaqus reference artifacts.
-
-The implementation must follow the full solver development workflow:
-
-1. Analyze new solver feature requirements.
-2. Research books, papers, manuals, and related solver implementations.
-3. Write the finite element formulation required for code implementation.
-4. Define solver input and output data contracts.
-5. Create TDD test models for both FESA and the reference solver.
-6. Implement code.
-7. Compare FESA results against reference solver results for nodal displacement, reaction, element internal force, and stress.
-8. Mark implementation complete only when result differences are within tolerance.
-9. Release the solver feature.
-
-## Scope
-Feature id: `mitc4-linear-static-shell`
-
-Included:
-- Linear static structural analysis.
-- MITC4 4-node shell element.
-- Six DOF per node: `U1, U2, U3, UR1, UR2, UR3`.
-- Single-layer isotropic linear elastic shell section.
-- Abaqus `.inp` subset input.
-- Intel oneAPI MKL CSR/PARDISO sparse linear solve.
-- Intel oneAPI TBB parallel element computation and result recovery.
-- HDF5 solver result output.
-- Stored Abaqus S4R primary reference comparison.
-- Stored Abaqus S4 diagnostic reference comparison.
-
-Excluded:
-- Nastran BDF input.
-- Nonlinear geometry.
-- Nonlinear material.
-- Dynamic analysis.
-- Buckling/eigenvalue analysis.
-- Composite/layered shell section.
-- Contact.
-- Agent-run Abaqus or Nastran execution.
-- Reference artifact generation by agents.
-- OpenSees API compatibility.
-
-## Architecture
-Use OpenSees as an architectural reference, not as an API clone. FESA should use modern C++17 ownership and small testable modules.
-
-Primary conceptual modules:
-- `Domain`: model container for nodes, elements, constraints, loads, materials, sections, and analysis metadata.
-- `Node`: id, coordinates, and six ordered DOFs.
-- `Element`: abstract element behavior for stiffness, internal force, result recovery, and connectivity.
-- `ShellMITC4Element`: four-node MITC4 implementation with 24 element DOFs.
-- `Material/Section`: isotropic elastic shell section with membrane, bending, shear, and stress recovery contract.
-- `Analysis`: linear static analysis driver.
-- `SystemOfEqn`: DOF numbering, constraints, CSR assembly, MKL PARDISO solve.
-- `ResultWriter`: HDF5 output.
-- `ReferenceComparator`: HDF5 reference comparison.
-
-## Step 1: New Solver Feature Requirements Analysis
-Create `docs/requirements/mitc4-linear-static-shell.md`.
-
-The requirements analysis document must define:
-- analysis type: linear static
-- element type: MITC4 shell
-- DOF order: `U1, U2, U3, UR1, UR2, UR3`
-- material: isotropic linear elastic
-- section: uniform shell thickness
-- input: Abaqus `.inp` subset
-- output: HDF5
-- verification quantities: nodal displacement, reaction, element internal force/resultant, stress
-- tolerance: single value `1e-5`
-- pass rule: `abs(error) <= 1e-5` or `relative(error) <= 1e-5`
-
-Acceptance criteria:
-- Every must requirement has a verification method.
-- Every numerical output requirement has component names and units policy.
-- Reference artifact needs are listed under `references/mitc4-linear-static-shell/`.
-
-## Step 2: Research Evidence
-Create `docs/research/mitc4-linear-static-shell-research.md`.
-
-Research must cover:
-- Dvorkin-Bathe continuum mechanics based four-node shell formulation.
-- MITC4 mixed interpolation of tensorial components.
-- Assumed transverse shear strain interpolation and shear locking.
-- OpenSees `ShellMITC4` class structure and resultants.
-- Abaqus S4/S4R behavior as practical reference elements.
-- Patch tests and Scordelis-Lo shell benchmark.
-
-The research document must separate verified source facts from implementation inference.
-
-## Step 3: FEM Formulation
-Create `docs/formulations/mitc4-linear-static-shell-formulation.md`.
-
-The formulation must define:
-- reference coordinates and node ordering.
-- shell midsurface interpolation.
-- director and local coordinate basis policy.
-- six-DOF nodal displacement vector.
-- membrane, bending, transverse shear strain measures.
-- MITC transverse shear tying/interpolation.
-- isotropic shell constitutive matrix.
-- element stiffness expression.
-- 2x2 Gauss integration.
-- drill stiffness policy.
-- stress and resultant recovery.
-- invalid Jacobian and degenerate element checks.
-
-Default drill stiffness policy:
-- v0 hardcodes `alpha=1`.
-- `Ktt = alpha * min_eigenvalue(D_membrane)`.
-- Input override is deferred to a later phase.
-
-## Step 4: I/O Contract
-Create `docs/io-definitions/mitc4-linear-static-shell-io.md`.
-
-Input subset:
-- `*NODE`
-- `*ELEMENT, TYPE=S4`
-- `*ELEMENT, TYPE=S4R`
-- `*MATERIAL`
-- `*ELASTIC`
-- `*SHELL SECTION`
-- `*BOUNDARY`
-- `*CLOAD`
-- `*STEP`
-
-Output format:
-- HDF5 file.
-- No CSV output is required for this feature.
-
-Required HDF5 layout:
-```text
-/metadata
-  feature_id
-  solver_version
-  model_id
-  units
-  tolerance
-  reference_solver
-
-/mesh/nodes
-/mesh/elements/mitc4/connectivity
-
-/results/step_000/frame_000/nodal/displacement
-/results/step_000/frame_000/nodal/reaction
-/results/step_000/frame_000/element/forces
-/results/step_000/frame_000/element/stress
-```
-
-Required result components:
-- displacement: `U1, U2, U3, UR1, UR2, UR3`
-- reaction: `RF1, RF2, RF3, RM1, RM2, RM3`
-- element force/resultant: `N11, N22, N12, M11, M22, M12, Q13, Q23`
-- stress: `S11, S22, S12, S13, S23`
-
-## Step 5: TDD Reference Models
-Create `docs/reference-models/mitc4-linear-static-shell-reference-models.md`.
-
-Reference policy:
-- FESA agents do not run Abaqus or Nastran.
-- Stored Abaqus S4R HDF5 artifacts are the primary pass/fail reference.
-- Stored Abaqus S4 HDF5 artifacts are diagnostic only.
-
-Initial model portfolio:
-- membrane patch
-- bending patch
-- transverse shear patch
-- twist patch
-- coarse Scordelis-Lo shell
-
-Each model bundle must include:
-```text
-references/mitc4-linear-static-shell/<model-id>/
-  model.inp
-  metadata.json
-  abaqus_s4r/results.h5
-  abaqus_s4/results.h5
-  README.md
-```
-
-`metadata.json` must record:
-- model id
-- source/provenance
-- Abaqus version
-- element type
-- units
-- output locations
-- tolerance `1e-5`
-- compared quantities
-- known limitations
-
-## Step 6: Code Implementation Plan
-Create `docs/implementation-plans/mitc4-linear-static-shell-implementation-plan.md`.
-
-Implementation must be TDD-first:
-
-1. Write failing parser tests.
-2. Implement minimum Abaqus `.inp` parser behavior.
-3. Write failing MITC4 element tests.
-4. Implement shape functions, Jacobian checks, MITC shear interpolation, stiffness, and recovery.
-5. Write failing assembly tests.
-6. Implement DOF numbering, constraint handling, and deterministic CSR assembly.
-7. Write failing MKL PARDISO solve tests.
-8. Implement solver wrapper and reaction recovery.
-9. Write failing TBB deterministic parallel tests.
-10. Implement TBB parallel element computations with deterministic merge.
-11. Write failing HDF5 schema tests.
-12. Implement HDF5 C API RAII wrapper and result writer.
-13. Write failing reference comparison tests.
-14. Implement HDF5 reference comparator.
-15. Run full validation.
-
-Required validation commands:
-```powershell
-python -m unittest discover -s scripts -p "test_*.py"
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -L mitc4
-```
-
-## Step 7: Reference Verification
-Create `docs/reference-verifications/mitc4-linear-static-shell-reference-verification.md`.
-
-Comparison inputs:
-- FESA `results.h5`
-- stored Abaqus S4R `results.h5`
-- diagnostic Abaqus S4 `results.h5`
-- metadata tolerance and schema version
-
-Compared quantities:
-- nodal displacement
-- nodal reaction
-- element internal force/resultant
-- stress
-
-Matching rules:
-- node id for nodal quantities
-- element id plus Gauss point id for element quantities
-- component name for scalar comparisons
-
-Pass rule:
-```text
-abs(error) <= 1e-5 OR relative(error) <= 1e-5
-```
-
-Report:
-- compared quantity
-- number of matched rows
-- missing rows
-- extra rows
-- maximum absolute error
-- maximum relative error
-- worst id
-- worst component
-- pass/fail
-
-## Step 8: Completion Decision
-Implementation is complete only when:
-- all required tests pass;
-- CMake/MSVC/x64/Debug build passes;
-- all required HDF5 result quantities compare within tolerance `1e-5`;
-- no required reference artifact is missing;
-- failures are not hidden as known limitations.
-
-If comparison fails, classify the failure as one of:
-- missing reference artifact
-- schema mismatch
-- id mismatch
-- unit or coordinate mismatch
-- formulation defect
-- implementation defect
-- tolerance failure
-- reference artifact issue
-
-Then return to the owning workflow step.
-
-## Step 9: Release
-Create `docs/releases/mitc4-linear-static-shell-release.md`.
-
-Release document must include:
-- feature id and scope
-- supported input keywords
-- supported outputs
-- dependency versions
-- test model list
-- reference comparison summary
-- tolerance policy
-- known limitations
-- validation commands and status
-
-Release is not approved by build success alone. Release requires reference comparison success and documented limitations.
-
-## Dependency Plan
-MKL:
-- Use oneAPI MKL through `MKLROOT` or known oneAPI path.
-- Use CSR matrix storage and PARDISO for the global linear system.
-
-TBB:
-- Use oneAPI TBB through `TBBROOT` or known oneAPI path.
-- Parallelize element-local stiffness and result recovery.
-- Use deterministic merge for global assembly.
-
-HDF5:
-- FESA provides an internal RAII wrapper around the HDF5 C API.
-- The HDF5 C library itself must be supplied through `HDF5_ROOT` or `HDF5_DIR`.
-- The current local default is `C:\Program Files\HDF_Group\HDF5\2.1.1`; use `HDF5_ROOT` for this root or `HDF5_DIR` for `C:\Program Files\HDF_Group\HDF5\2.1.1\cmake`.
-- HDF5 is required for solver output and reference comparison.
-
-## Assumptions
-- Abaqus reference artifacts are generated outside the agent workflow.
-- S4R is the primary reference for pass/fail.
-- S4 is diagnostic and does not determine pass/fail.
-- The single tolerance value is `1e-5`.
-- The initial implementation prioritizes correctness and traceability over broad element coverage.

docs/reference-models/README.md

@@ -2,7 +2,7 @@
 
 이 디렉터리는 Reference Model Agent가 작성하거나 제안한 기능별 reference model 설계 문서를 보관하는 위치다.
 
-Reference Model Agent는 FESA 기능 검증에 필요한 Abaqus `.inp` 기반 테스트 모델 포트폴리오와 `references/<feature-id>/<model-id>/` artifact bundle 계약을 정의한다. Agent는 Abaqus, Nastran 또는 레퍼런스 솔버를 직접 실행하지 않고, reference HDF5 artifact나 reference CSV 값을 생성하지 않으며, solver 결과 비교나 release readiness 승인도 하지 않는다.
+Reference Model Agent는 FESA 기능 검증에 필요한 Abaqus `.inp` 기반 테스트 모델 포트폴리오와 `references/<feature-id>/<model-id>/` artifact bundle 계약을 정의한다. Agent는 Abaqus, Nastran 또는 레퍼런스 솔버를 직접 실행하지 않고, reference CSV 값을 생성하지 않으며, solver 결과 비교나 release readiness 승인도 하지 않는다.
 
 기본 파일명은 `docs/reference-models/<feature-id>-reference-models.md` 형식을 사용한다. 각 문서는 요구조건, 연구 브리프, 정식화, 수치 리뷰, I/O 정의를 입력으로 받아 구현 전에 준비해야 할 테스트 모델과 reference artifact 요구사항을 정의해야 한다.
 
@@ -12,9 +12,8 @@ Reference Model Agent는 FESA 기능 검증에 필요한 Abaqus `.inp` 기반
 - 기능별 reference model portfolio를 smoke, analytical, patch test, benchmark, regression, negative/invalid-input model로 구분한다.
 - `model.inp`가 I/O Definition Agent의 supported Abaqus keyword subset 안에 있는지 확인한다.
 - `references/<feature-id>/<model-id>/` artifact bundle 구조와 필수 파일을 정의한다.
-- `metadata.json` provenance, 단위, 좌표계, Abaqus version/source, output request, HDF5 schema version, tolerance 정책을 정의한다.
-- `results.h5` 또는 feature-specific HDF5 reference result file 요구사항을 정의한다.
-- upstream 요구조건이 명시한 경우에만 `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv` 같은 optional CSV export 요구사항을 정의한다.
+- `metadata.json` provenance, 단위, 좌표계, Abaqus version/source, output request, tolerance 정책을 정의한다.
+- `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv` 요구사항을 정의한다.
 - requirement와 model, compared quantity, tolerance, artifact status를 연결하는 Coverage Matrix를 작성한다.
 
 수행하지 않는다:
@@ -22,7 +21,7 @@ Reference Model Agent는 FESA 기능 검증에 필요한 Abaqus `.inp` 기반
 - parser를 구현하지 않는다.
 - C++ API나 파일 구조를 설계하지 않는다.
 - Abaqus, Nastran 또는 레퍼런스 솔버를 직접 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV를 생성하지 않는다.
+- reference CSV를 생성하지 않는다.
 - solver 결과를 비교하지 않는다.
 - release readiness를 승인하지 않는다.
 - reference 값, tolerance, Abaqus compatibility를 임의로 만들지 않는다.
@@ -54,11 +53,11 @@ Reference Model Agent는 FESA 기능 검증에 필요한 Abaqus `.inp` 기반
 
 | model_id | category | purpose | status | required_artifacts |
 | --- | --- | --- | --- | --- |
-| <model-id> | smoke | <basic parser/solve path> | draft | model.inp, metadata.json, results.h5 |
-| <model-id> | analytical | <closed-form comparison> | draft | model.inp, metadata.json, results.h5 |
-| <model-id> | patch test | <element consistency check> | draft | model.inp, metadata.json, results.h5 |
-| <model-id> | benchmark | <trusted benchmark comparison> | draft | model.inp, metadata.json, results.h5 |
-| <model-id> | regression | <known defect guard> | draft | model.inp, metadata.json, results.h5 |
+| <model-id> | smoke | <basic parser/solve path> | draft | model.inp, metadata.json, required CSVs |
+| <model-id> | analytical | <closed-form comparison> | draft | model.inp, metadata.json, required CSVs |
+| <model-id> | patch test | <element consistency check> | draft | model.inp, metadata.json, required CSVs |
+| <model-id> | benchmark | <trusted benchmark comparison> | draft | model.inp, metadata.json, required CSVs |
+| <model-id> | regression | <known defect guard> | draft | model.inp, metadata.json, required CSVs |
 | <model-id> | negative/invalid-input | <unsupported keyword or invalid model diagnostic> | draft | model.inp, metadata.json |
 
 ## Model Record
@@ -82,7 +81,7 @@ Reference Model Agent는 FESA 기능 검증에 필요한 Abaqus `.inp` 기반
 - supported_keyword_subset: <keywords from docs/io-definitions/<feature-id>-io.md>
 - model_data: <nodes, elements, sets, material, section, coordinates, units>
 - history_data: <step, procedure, boundary conditions, loads, output requests>
-- output_requests: <requests needed to populate reference HDF5 datasets>
+- output_requests: <requests needed to populate reference CSV files>
 - unsupported_keyword_policy: unsupported | ignored-with-warning | requires-user-decision
 
 ## Artifact Bundle Contract
@@ -93,38 +92,27 @@ references/
     <model-id>/
       model.inp
       metadata.json
-      results.h5
+      displacements.csv
+      reactions.csv
+      element_forces.csv
+      stresses.csv
       README.md
 ```
 
 Required files:
 - `model.inp`: Abaqus input file for the reference model.
 - `metadata.json`: provenance and model contract metadata.
-- `results.h5`: HDF5 reference result artifact containing required metadata, mesh, step/frame, nodal, element, field, and history result datasets.
+- `displacements.csv`: nodal displacement reference results.
+- `reactions.csv`: nodal reaction force reference results.
+- `element_forces.csv`: element internal force reference results.
+- `stresses.csv`: stress reference results.
 - `README.md`: short description, generation notes, and limitations.
 
 Optional files:
-- `displacements.csv`: nodal displacement export when upstream contracts explicitly require CSV.
-- `reactions.csv`: nodal reaction force export when upstream contracts explicitly require CSV.
-- `element_forces.csv`: element internal force export when upstream contracts explicitly require CSV.
-- `stresses.csv`: stress export when upstream contracts explicitly require CSV.
 - `strains.csv`: strain reference results when required.
 - `energy_or_residual.csv`: energy, residual, or convergence reference results when required.
 - `notes.md`: manual review notes.
 
-For the current `mitc4-linear-static-shell` feature, the required stored Abaqus artifacts are:
-
-```text
-references/mitc4-linear-static-shell/<model-id>/
-  model.inp
-  metadata.json
-  abaqus_s4r/results.h5
-  abaqus_s4/results.h5
-  README.md
-```
-
-`abaqus_s4r/results.h5` is the primary pass/fail reference. `abaqus_s4/results.h5` is diagnostic.
-
 ## Metadata JSON Contract
 
 ```json
@@ -144,21 +132,13 @@ references/mitc4-linear-static-shell/<model-id>/
   "boundary_condition_summary": "<summary>",
   "load_summary": "<summary>",
   "output_requests": ["U", "RF", "S", "<feature-specific quantities>"],
-  "hdf5_schema_version": "<version>",
+  "csv_schema_version": "<version>",
   "tolerance_policy": "<absolute/relative/norm policy>",
   "limitations": ["<known limitation>"]
 }
 ```
 
-## Reference HDF5 Requirements
-
-- Required when reference comparison is part of the feature acceptance criteria.
-- Must include metadata, mesh identity, step/frame identity, node and element IDs, component names, coordinate system, units, output locations, and tolerance source.
-- Required quantity datasets must match the paths and component contracts from `docs/io-definitions/<feature-id>-io.md`.
-
-## Optional CSV Export Requirements
-
-CSV exports are not required for the current HDF5-first MITC4 feature unless an upstream document explicitly requires them. When required, they must preserve the same physical meaning and matching keys as the HDF5 datasets.
+## Reference CSV Requirements
 
 ### displacements.csv
 - Required when nodal displacement is a verification quantity.
@@ -184,30 +164,30 @@ CSV exports are not required for the current HDF5-first MITC4 feature unless an
 
 | requirement_id | model_id | compared_quantity | artifact_file | tolerance | verification_method | status |
 | --- | --- | --- | --- | --- | --- | --- |
-| <req-id> | <model-id> | displacement | results.h5:/results/.../nodal/displacement | <policy> | reference-comparison | draft |
-| <req-id> | <model-id> | reaction | results.h5:/results/.../nodal/reaction | <policy> | reference-comparison | draft |
-| <req-id> | <model-id> | element force | results.h5:/results/.../element/forces | <policy> | reference-comparison | draft |
-| <req-id> | <model-id> | stress | results.h5:/results/.../element/stress | <policy> | reference-comparison | draft |
+| <req-id> | <model-id> | displacement | displacements.csv | <policy> | reference-comparison | draft |
+| <req-id> | <model-id> | reaction | reactions.csv | <policy> | reference-comparison | draft |
+| <req-id> | <model-id> | element force | element_forces.csv | <policy> | reference-comparison | draft |
+| <req-id> | <model-id> | stress | stresses.csv | <policy> | reference-comparison | draft |
 
 ## Artifact Acceptance Checklist
 - 모든 `must` requirement가 최소 하나의 `model_id`와 `compared_quantity`에 연결되어 있다.
 - `model.inp`가 기능별 supported Abaqus keyword subset을 벗어나지 않는다.
-- `metadata.json`에 provenance, Abaqus version/source, units, coordinate system, tolerance, HDF5 schema version이 기록되어 있다.
-- 필수 HDF5 artifact가 존재하거나, 기능상 불필요한 파일은 명확한 reason과 함께 제외되어 있다.
-- output request가 필요한 HDF5 물리량을 생성할 수 있도록 정의되어 있다.
-- reference HDF5 artifact가 없으면 status는 `needs-reference-artifacts`다.
+- `metadata.json`에 provenance, Abaqus version/source, units, coordinate system, tolerance, CSV schema version이 기록되어 있다.
+- 필수 CSV 파일이 존재하거나, 기능상 불필요한 파일은 명확한 reason과 함께 제외되어 있다.
+- output request가 필요한 CSV 물리량을 생성할 수 있도록 정의되어 있다.
+- reference CSV가 없으면 status는 `needs-reference-artifacts`다.
 - tolerance, source, units, coordinate system이 불명확하면 status는 `needs-user-decision`이다.
 
 ## Open Issues and Downstream Handoff
 
 ### I/O Definition Agent
-- <supported keyword, output request, HDF5 schema clarification>
+- <supported keyword, output request, CSV schema clarification>
 
 ### Implementation Planning Agent
 - <tests that should fail before implementation, model order, acceptance criteria>
 
 ### Reference Verification Agent
-- <HDF5 schema, optional CSV schema, ID matching, units, coordinate conventions, output locations, tolerance mapping>
+- <CSV schema, ID matching, units, coordinate conventions, output locations, tolerance mapping>
 
 ### Physics Evaluation Agent
 - <equilibrium, symmetry, displacement direction, stress location, rigid body mode, load path sanity checks>
@@ -218,8 +198,8 @@ CSV exports are not required for the current HDF5-first MITC4 feature unless an
 - Reference model의 목적과 검증 대상 requirement가 명확해야 한다.
 - `model.inp`는 Abaqus input file이며, 기능별 supported keyword subset을 따라야 한다.
 - model data와 history data를 구분해야 한다.
-- output request와 required HDF5 dataset 사이의 연결이 명확해야 한다.
+- output request와 required CSV 사이의 연결이 명확해야 한다.
 - `references/<feature-id>/<model-id>/` 구조와 필수 artifact가 명시되어야 한다.
-- `metadata.json`에는 provenance, Abaqus version/source, units, coordinate system, tolerance, HDF5 schema version이 포함되어야 한다.
-- reference HDF5 artifact가 없으면 완료 상태가 아니라 `needs-reference-artifacts` 상태로 둔다.
+- `metadata.json`에는 provenance, Abaqus version/source, units, coordinate system, tolerance, CSV schema version이 포함되어야 한다.
+- reference CSV가 없으면 완료 상태가 아니라 `needs-reference-artifacts` 상태로 둔다.
 - 모든 `must` requirement는 Coverage Matrix에서 model, compared quantity, tolerance, verification method로 추적되어야 한다.

docs/reference-verifications/README.md

@@ -2,17 +2,17 @@
 
 이 디렉터리는 Reference Verification Agent가 작성하거나 제안하는 기능별 reference comparison report를 보관하는 위치다.
 
-Reference Verification Agent는 Build/Test Executor Agent 통과 후 generated solver `results.h5`와 stored Abaqus reference HDF5 artifacts를 tolerance 기준으로 비교한다. 이 agent는 comparison과 report만 수행하며, source code, tests, CMake files, requirements, formulations, I/O contracts, reference artifacts, tolerance policies를 수정하지 않는다.
+Reference Verification Agent는 Build/Test Executor Agent 통과 후 generated solver result CSV와 stored Abaqus reference CSV artifacts를 tolerance 기준으로 비교한다. 이 agent는 comparison과 report만 수행하며, source code, tests, CMake files, requirements, formulations, I/O contracts, reference artifacts, tolerance policies를 수정하지 않는다.
 
 기본 문서명은 `docs/reference-verifications/<feature-id>-reference-verification.md` 형식을 사용한다.
 
 ## Reference Verification Agent 역할
 
 수행한다:
-- `references/<feature-id>/<model-id>/` artifact bundle과 generated solver `results.h5`를 확인한다.
+- `references/<feature-id>/<model-id>/` artifact bundle과 generated solver result CSV를 확인한다.
 - `metadata.json`, schema version, units, coordinate system, step/frame identity, node/element IDs, output location, tolerance source를 확인한다.
-- HDF5 datasets for displacement, reaction, element force/resultant, stress를 기본 비교 대상으로 삼는다.
-- upstream 문서가 요구할 때만 strain, energy, residual HDF5 datasets 또는 optional CSV export를 추가 비교한다.
+- `displacements.csv`, `reactions.csv`, `element_forces.csv`, `stresses.csv`를 기본 비교 대상으로 삼는다.
+- upstream 문서가 요구할 때만 `strains.csv`, `energy_or_residual.csv`를 추가 비교한다.
 - max absolute error, max relative error, RMS error, norm error, worst node/element/component, missing rows, extra rows, pass/fail을 보고한다.
 - 실패를 missing-reference-artifact, missing-solver-output, schema-mismatch, id-mismatch, unit-or-coordinate-mismatch, tolerance-failure, nonfinite-result, upstream-contract, environment로 분류한다.
 
@@ -23,8 +23,8 @@ Reference Verification Agent는 Build/Test Executor Agent 통과 후 generated s
 - requirements, formulations, I/O contracts, reference model contracts를 수정하지 않는다.
 - reference artifacts 또는 tolerance policies를 수정하지 않는다.
 - Abaqus, Nastran 또는 reference solver를 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV를 생성하지 않는다.
-- solver HDF5 output 또는 optional CSV export를 tolerance에 맞추기 위해 보정하지 않는다.
+- reference CSV를 생성하지 않는다.
+- solver output CSV를 tolerance에 맞추기 위해 보정하지 않는다.
 - physics validation success 또는 release readiness를 승인하지 않는다.
 
 ## 실행 순서
@@ -38,8 +38,8 @@ ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT
 `ARTIFACT CHECK`에서 다음 항목이 없으면 비교를 시작하지 않는다.
 
 - `metadata.json`
-- required reference HDF5 files
-- generated solver `results.h5`
+- required reference CSV files
+- generated solver result CSV files
 - schema version
 - units
 - coordinate system
@@ -51,20 +51,20 @@ ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT
 ## 비교 대상
 
 기본 비교 대상:
-- `results.h5:/results/.../nodal/displacement`: nodal displacement
-- `results.h5:/results/.../nodal/reaction`: nodal reaction force
-- `results.h5:/results/.../element/forces`: element internal force/resultant
-- `results.h5:/results/.../element/stress`: element stress
+- `displacements.csv`: nodal displacement
+- `reactions.csv`: nodal reaction force
+- `element_forces.csv`: element internal force
+- `stresses.csv`: element stress
 
 선택 비교 대상:
-- strain HDF5 dataset or `strains.csv`: strain이 acceptance criteria에 포함된 경우
-- energy/residual HDF5 dataset or `energy_or_residual.csv`: energy, residual, convergence quantity가 acceptance criteria에 포함된 경우
+- `strains.csv`: strain이 acceptance criteria에 포함된 경우
+- `energy_or_residual.csv`: energy, residual, convergence quantity가 acceptance criteria에 포함된 경우
 
 ## Failure Classification
 
 - `missing-reference-artifact`: required stored reference file 또는 provenance가 없다.
-- `missing-solver-output`: generated solver `results.h5` 또는 comparison command가 없다.
-- `schema-mismatch`: reference HDF5 schema와 solver HDF5 schema가 다르다.
+- `missing-solver-output`: generated solver result CSV 또는 comparison command가 없다.
+- `schema-mismatch`: reference CSV와 solver CSV column/schema가 다르다.
 - `id-mismatch`: node id, element id, step/frame, integration point, component matching이 실패했다.
 - `unit-or-coordinate-mismatch`: units 또는 coordinate system이 비교 가능하지 않다.
 - `tolerance-failure`: schema와 matching은 유효하지만 error가 tolerance를 초과했다.
@@ -93,10 +93,11 @@ ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT
 | --- | --- | --- | --- |
 | reference_bundle | references/<feature-id>/<model-id>/ | present | missing | <notes> |
 | metadata | references/<feature-id>/<model-id>/metadata.json | present | missing | <provenance summary> |
-| reference_results | references/<feature-id>/<model-id>/results.h5 | present | missing | <notes> |
-| solver_results | <solver output path>/results.h5 | present | missing | <notes> |
-| optional_reference_csv_exports | references/<feature-id>/<model-id>/*.csv | present | missing | required only when upstream contracts ask for CSV |
-| optional_solver_csv_exports | <solver output path>/*.csv | present | missing | required only when upstream contracts ask for CSV |
+| reference_displacements | references/<feature-id>/<model-id>/displacements.csv | present | missing | <notes> |
+| reference_reactions | references/<feature-id>/<model-id>/reactions.csv | present | missing | <notes> |
+| reference_element_forces | references/<feature-id>/<model-id>/element_forces.csv | present | missing | <notes> |
+| reference_stresses | references/<feature-id>/<model-id>/stresses.csv | present | missing | <notes> |
+| solver_outputs | <solver output directory> | present | missing | <notes> |
 
 ## Comparison Contract
 - schema_version: <version>
@@ -113,10 +114,10 @@ ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT
 
 | quantity | model_id | artifact_file | compared_rows | missing_rows | extra_rows | max_abs_error | max_rel_error | rms_error | norm_error | worst_id | worst_component | result |
 | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| displacement | <model-id> | results.h5:/results/.../nodal/displacement | <n> | <n> | <n> | <value> | <value> | <value> | <value or N/A> | <node id> | <component> | pass | fail |
-| reaction | <model-id> | results.h5:/results/.../nodal/reaction | <n> | <n> | <n> | <value> | <value> | <value> | <value or N/A> | <node id> | <component> | pass | fail |
-| element force | <model-id> | results.h5:/results/.../element/forces | <n> | <n> | <n> | <value> | <value> | <value> | <value or N/A> | <element id> | <component> | pass | fail |
-| stress | <model-id> | results.h5:/results/.../element/stress | <n> | <n> | <n> | <value> | <value> | <value> | <value or N/A> | <element/ip id> | <component> | pass | fail |
+| displacement | <model-id> | displacements.csv | <n> | <n> | <n> | <value> | <value> | <value> | <value or N/A> | <node id> | <component> | pass | fail |
+| reaction | <model-id> | reactions.csv | <n> | <n> | <n> | <value> | <value> | <value> | <value or N/A> | <node id> | <component> | pass | fail |
+| element force | <model-id> | element_forces.csv | <n> | <n> | <n> | <value> | <value> | <value> | <value or N/A> | <element id> | <component> | pass | fail |
+| stress | <model-id> | stresses.csv | <n> | <n> | <n> | <value> | <value> | <value> | <value or N/A> | <element/ip id> | <component> | pass | fail |
 
 ## Failure Classification
 - classification: missing-reference-artifact | missing-solver-output | schema-mismatch | id-mismatch | unit-or-coordinate-mismatch | tolerance-failure | nonfinite-result | upstream-contract | environment | N/A
@@ -150,15 +151,15 @@ ARTIFACT CHECK -> COMPARE -> CLASSIFY -> REPORT
 - `pass-for-physics-evaluation`: required reference comparisons가 모두 통과했고 Physics Evaluation Agent로 넘길 수 있다.
 - `needs-correction`: implementation-owned solver result mismatch 또는 nonfinite result가 있다.
 - `needs-reference-artifacts`: required reference artifact 또는 provenance가 누락됐다.
-- `needs-solver-results`: generated solver `results.h5` 또는 comparison command가 없다.
+- `needs-solver-results`: generated solver result CSV 또는 comparison command가 없다.
 - `needs-upstream-decision`: schema, tolerance, units, coordinate system, output location, ID matching policy가 누락 또는 충돌한다.
 - `blocked`: 사용자 또는 Coordinator Agent 결정 없이는 안전하게 진행할 수 없다.
 
 ## 품질 기준
 
 - 모든 `must` requirement의 reference-comparison 항목은 model id, compared quantity, artifact file, tolerance에 trace되어야 한다.
-- reference artifact는 읽기 전용이다. `model.inp`, `metadata.json`, `results.h5`, optional reference CSV를 수정하지 않는다.
-- solver HDF5 output과 optional solver CSV는 비교 입력일 뿐이며 tolerance에 맞추기 위해 후처리 보정하지 않는다.
+- reference artifact는 읽기 전용이다. `model.inp`, `metadata.json`, reference CSV를 수정하지 않는다.
+- solver output CSV는 비교 입력일 뿐이며 tolerance에 맞추기 위해 후처리 보정하지 않는다.
 - stress/strain은 element id, integration point 또는 recovery location, component naming이 일치할 때만 비교한다.
 - nodal displacement/reaction은 node id, DOF/component, coordinate system, unit이 일치할 때만 비교한다.
 - missing rows와 extra rows를 숨기지 않고 보고한다.

docs/releases/README.md

@@ -2,7 +2,7 @@
 
 이 디렉터리는 Release Agent가 작성하거나 제안하는 기능별 release readiness report를 보관하는 위치다.
 
-Release Agent는 Physics Evaluation Agent가 `pass-for-release-agent`로 넘긴 기능에 대해 최종 gate evidence를 감사한다. 이 Agent는 source code, tests, CMake, upstream 계약, reference artifacts, tolerance policies를 수정하지 않는다. 또한 Abaqus/Nastran 실행, reference HDF5 artifact 또는 reference CSV 생성, 외부 publish/deploy/package/tag/commit 작업을 수행하지 않는다.
+Release Agent는 Physics Evaluation Agent가 `pass-for-release-agent`로 넘긴 기능에 대해 최종 gate evidence를 감사한다. 이 Agent는 source code, tests, CMake, upstream 계약, reference artifacts, tolerance policies를 수정하지 않는다. 또한 Abaqus/Nastran 실행, reference CSV 생성, 외부 publish/deploy/package/tag/commit 작업을 수행하지 않는다.
 
 기본 문서명은 `docs/releases/<feature-id>-release.md` 형식을 사용한다.
 
@@ -24,7 +24,7 @@ Release Agent는 Physics Evaluation Agent가 `pass-for-release-agent`로 넘긴
 - requirements, formulations, I/O contracts, numerical review reports, reference verification reports, physics evaluation reports를 수정하지 않는다.
 - reference artifacts 또는 tolerance policies를 수정하지 않는다.
 - Abaqus, Nastran 또는 reference solver를 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV를 생성하지 않는다.
+- reference CSV를 생성하지 않는다.
 - 실패하거나 누락된 upstream gate를 우회하지 않는다.
 - 사용자 명시 요청 없이 publish, deploy, package, tag, commit, external release를 수행하지 않는다.
 

docs/requirements/README.md

@@ -1,12 +1,12 @@
 # 요구조건 문서 작성 가이드
 
-이 디렉터리는 Requirement Agent가 작성하거나 제안한 새로운 솔버 기능 요구조건 분석 문서를 보관하는 위치다.
+이 디렉터리는 Requirement Agent가 작성하거나 제안한 기능별 요구조건 문서를 보관하는 위치다.
 
-기본 파일명은 `docs/requirements/<feature-id>.md` 형식을 사용한다. 각 문서는 구현 전에 작성되며, Formulation Agent, I/O Definition Agent, Reference Model Agent, Implementation Planning Agent가 이어받을 수 있는 검증 가능한 요구조건 분석 baseline이어야 한다.
+기본 파일명은 `docs/requirements/<feature-id>.md` 형식을 사용한다. 각 문서는 구현 전에 작성되며, Formulation Agent, I/O Definition Agent, Reference Model Agent, Implementation Planning Agent가 이어받을 수 있는 검증 가능한 baseline이어야 한다.
 
 ## Requirement Agent 역할
 
-Requirement Agent는 새로운 솔버 기능 요청을 검증 가능한 요구조건 분석 산출물로 바꾼다.
+Requirement Agent는 솔버 기능 요청을 검증 가능한 요구조건으로 바꾼다.
 
 수행한다:
 - 기능 범위, 제외 범위, 입력, 출력, 제약조건을 정의한다.
@@ -20,7 +20,7 @@ Requirement Agent는 새로운 솔버 기능 요청을 검증 가능한 요구
 - 유한요소 정식화를 확정하지 않는다.
 - C++ API나 파일 구조를 설계하지 않는다.
 - Abaqus, Nastran 또는 레퍼런스 솔버를 직접 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV 결과를 생성하지 않는다.
+- reference CSV 결과를 생성하지 않는다.
 - 기능 완료 여부를 승인하지 않는다.
 
 ## 문서 템플릿
@@ -78,8 +78,10 @@ Expected location: `references/<feature-id>/`
 
 - `model.inp`: required | not-applicable
 - `metadata.json`: required
-- `results.h5`: required | not-applicable
-- optional_csv_exports: required | not-applicable
+- `displacements.csv`: required | not-applicable
+- `reactions.csv`: required | not-applicable
+- `element_forces.csv`: required | not-applicable
+- `stresses.csv`: required | not-applicable
 
 ## Requirement Verification Matrix
 
@@ -112,6 +114,6 @@ Expected location: `references/<feature-id>/`
 
 - 모든 `must` 요구조건은 검증 방법과 acceptance criteria를 가져야 한다.
 - 모든 수치 요구조건은 단위, 좌표계, tolerance 또는 `TBD with owner`를 가져야 한다.
-- reference 비교가 필요한 요구조건은 필요한 HDF5 artifact와 dataset path를 명시해야 한다. CSV artifact는 명시적으로 요구된 export일 때만 포함한다.
+- reference 비교가 필요한 요구조건은 필요한 CSV artifact를 명시해야 한다.
 - "빠르게", "정확하게", "Abaqus처럼" 같은 문장은 검증 가능한 기준으로 바꾸거나 open question으로 남겨야 한다.
 - 구현 방법, 정식화 세부식, C++ API는 이 문서에서 확정하지 않는다.

docs/research/README.md

@@ -20,7 +20,7 @@ Research Agent는 FEM 이론, benchmark, verification reference, solver manual,
 - 유한요소 정식화를 확정하지 않는다.
 - C++ API나 파일 구조를 설계하지 않는다.
 - Abaqus, Nastran 또는 레퍼런스 솔버를 직접 실행하지 않는다.
-- reference HDF5 artifact 또는 reference CSV 결과를 생성하지 않는다.
+- reference CSV 결과를 생성하지 않는다.
 - 기능 완료 여부를 승인하지 않는다.
 
 ## Source Reliability Tier

include/fesa/analysis/Analysis.hpp

@@ -1,22 +0,0 @@
-#pragma once
-
-#include "fesa/core/AnalysisState.hpp"
-#include "fesa/core/Domain.hpp"
-
-namespace fesa::analysis {
-
-class Analysis {
-public:
-    virtual ~Analysis() = default;
-
-    virtual const char* name() const noexcept = 0;
-
-    void run(const fesa::core::Domain& domain, fesa::core::AnalysisState& state) {
-        doRun(domain, state);
-    }
-
-protected:
-    virtual void doRun(const fesa::core::Domain& domain, fesa::core::AnalysisState& state) = 0;
-};
-
-} // namespace fesa::analysis

include/fesa/boundary/BoundaryCondition.hpp

@@ -1,16 +0,0 @@
-#pragma once
-
-namespace fesa::boundary {
-
-enum class BoundaryConditionKind {
-    SinglePointConstraint
-};
-
-class BoundaryCondition {
-public:
-    virtual ~BoundaryCondition() = default;
-
-    virtual BoundaryConditionKind kind() const noexcept = 0;
-};
-
-} // namespace fesa::boundary

include/fesa/boundary/SinglePointConstraint.hpp

@@ -1,26 +0,0 @@
-#pragma once
-
-#include "fesa/boundary/BoundaryCondition.hpp"
-#include "fesa/core/ModelTypes.hpp"
-
-namespace fesa::boundary {
-
-using fesa::core::Dof;
-using fesa::core::NodeId;
-
-class SinglePointConstraint final : public BoundaryCondition {
-public:
-    SinglePointConstraint(NodeId node_id, Dof dof, double value);
-
-    BoundaryConditionKind kind() const noexcept override;
-    NodeId nodeId() const noexcept;
-    Dof dof() const noexcept;
-    double value() const noexcept;
-
-private:
-    NodeId node_id_;
-    Dof dof_;
-    double value_;
-};
-
-} // namespace fesa::boundary

include/fesa/core/AnalysisState.hpp

@@ -1,52 +0,0 @@
-#pragma once
-
-#include <cstddef>
-#include <cstdint>
-#include <vector>
-
-namespace fesa::core {
-
-class AnalysisState {
-public:
-    AnalysisState();
-    explicit AnalysisState(std::size_t dof_count);
-
-    std::size_t dofCount() const noexcept;
-    void resize(std::size_t dof_count);
-
-    const std::vector<double>& displacement() const noexcept;
-    const std::vector<double>& externalForce() const noexcept;
-    const std::vector<double>& internalForce() const noexcept;
-    const std::vector<double>& residual() const noexcept;
-    const std::vector<double>& reaction() const noexcept;
-
-    void setDisplacement(std::vector<double> values);
-    void setExternalForce(std::vector<double> values);
-    void setInternalForce(std::vector<double> values);
-    void setResidual(std::vector<double> values);
-    void setReaction(std::vector<double> values);
-    void clearForces() noexcept;
-
-    double currentTime() const noexcept;
-    void setCurrentTime(double value) noexcept;
-    std::int64_t incrementIndex() const noexcept;
-    void setIncrementIndex(std::int64_t value) noexcept;
-    std::int64_t iterationIndex() const noexcept;
-    void setIterationIndex(std::int64_t value) noexcept;
-
-private:
-    void setVector(std::vector<double>& target, std::vector<double> values);
-    static void zero(std::vector<double>& values) noexcept;
-
-    std::size_t dof_count_;
-    std::vector<double> displacement_;
-    std::vector<double> external_force_;
-    std::vector<double> internal_force_;
-    std::vector<double> residual_;
-    std::vector<double> reaction_;
-    double current_time_;
-    std::int64_t increment_index_;
-    std::int64_t iteration_index_;
-};
-
-} // namespace fesa::core

include/fesa/core/BoundaryCondition.hpp

@@ -1,21 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-namespace fesa::core {
-
-class BoundaryCondition {
-public:
-    BoundaryCondition(NodeId node_id, Dof dof, double value);
-
-    NodeId nodeId() const noexcept;
-    Dof dof() const noexcept;
-    double value() const noexcept;
-
-private:
-    NodeId node_id_;
-    Dof dof_;
-    double value_;
-};
-
-} // namespace fesa::core

include/fesa/core/Domain.hpp

@@ -1,86 +0,0 @@
-#pragma once
-
-#include "fesa/boundary/BoundaryCondition.hpp"
-#include "fesa/core/ModelTypes.hpp"
-#include "fesa/core/Node.hpp"
-#include "fesa/core/StepDefinition.hpp"
-#include "fesa/element/Element.hpp"
-#include "fesa/load/Load.hpp"
-#include "fesa/material/Material.hpp"
-#include "fesa/property/Property.hpp"
-#include "fesa/property/ShellProperty.hpp"
-
-#include <cstddef>
-#include <memory>
-#include <string>
-#include <unordered_map>
-#include <vector>
-
-namespace fesa::core {
-
-class Domain {
-public:
-    void addNode(Node node);
-    void addElement(std::unique_ptr<fesa::element::Element> element);
-    void addMaterial(std::unique_ptr<fesa::material::Material> material);
-    void addProperty(std::unique_ptr<fesa::property::Property> property);
-    void addShellProperty(std::unique_ptr<fesa::property::ShellProperty> property);
-    void addNodeSet(std::string name, std::vector<NodeId> node_ids);
-    void addElementSet(std::string name, std::vector<ElementId> element_ids);
-    std::size_t addBoundaryCondition(std::unique_ptr<fesa::boundary::BoundaryCondition> boundary);
-    std::size_t addLoad(std::unique_ptr<fesa::load::Load> load);
-    void addStep(LinearStaticStepDefinition step);
-
-    const Node* findNode(NodeId id) const noexcept;
-    const Node& node(NodeId id) const;
-    std::size_t nodeCount() const noexcept;
-
-    const fesa::element::Element* findElement(ElementId id) const noexcept;
-    const fesa::element::Element& element(ElementId id) const;
-    std::size_t elementCount() const noexcept;
-
-    const fesa::material::Material* findMaterial(MaterialId id) const noexcept;
-    const fesa::material::Material& material(MaterialId id) const;
-    std::size_t materialCount() const noexcept;
-
-    const fesa::property::Property* findProperty(PropertyId id) const noexcept;
-    const fesa::property::Property& property(PropertyId id) const;
-    std::size_t propertyCount() const noexcept;
-
-    const fesa::property::ShellProperty* findShellProperty(PropertyId id) const noexcept;
-    const fesa::property::ShellProperty& shellProperty(PropertyId id) const;
-    std::size_t shellPropertyCount() const noexcept;
-
-    const std::vector<NodeId>* findNodeSet(const std::string& name) const noexcept;
-    const std::vector<NodeId>& nodeSet(const std::string& name) const;
-    std::size_t nodeSetCount() const noexcept;
-
-    const std::vector<ElementId>* findElementSet(const std::string& name) const noexcept;
-    const std::vector<ElementId>& elementSet(const std::string& name) const;
-    std::size_t elementSetCount() const noexcept;
-
-    const fesa::boundary::BoundaryCondition* findBoundaryCondition(std::size_t index) const noexcept;
-    const fesa::boundary::BoundaryCondition& boundaryCondition(std::size_t index) const;
-    std::size_t boundaryConditionCount() const noexcept;
-
-    const fesa::load::Load* findLoad(std::size_t index) const noexcept;
-    const fesa::load::Load& load(std::size_t index) const;
-    std::size_t loadCount() const noexcept;
-
-    const LinearStaticStepDefinition* findStep(StepId id) const noexcept;
-    const LinearStaticStepDefinition& step(StepId id) const;
-    std::size_t stepCount() const noexcept;
-
-private:
-    std::unordered_map<NodeId, Node> nodes_;
-    std::unordered_map<ElementId, std::unique_ptr<fesa::element::Element>> elements_;
-    std::unordered_map<MaterialId, std::unique_ptr<fesa::material::Material>> materials_;
-    std::unordered_map<PropertyId, std::unique_ptr<fesa::property::Property>> properties_;
-    std::unordered_map<std::string, std::vector<NodeId>> node_sets_;
-    std::unordered_map<std::string, std::vector<ElementId>> element_sets_;
-    std::vector<std::unique_ptr<fesa::boundary::BoundaryCondition>> boundary_conditions_;
-    std::vector<std::unique_ptr<fesa::load::Load>> loads_;
-    std::unordered_map<StepId, LinearStaticStepDefinition> steps_;
-};
-
-} // namespace fesa::core

include/fesa/core/ElementDefinition.hpp

@@ -1,29 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-#include <array>
-
-namespace fesa::core {
-
-class ElementDefinition {
-public:
-    ElementDefinition(
-        ElementId id,
-        ElementType type,
-        std::array<NodeId, 4> connectivity,
-        PropertyId property_id);
-
-    ElementId id() const noexcept;
-    ElementType type() const noexcept;
-    const std::array<NodeId, 4>& connectivity() const noexcept;
-    PropertyId propertyId() const noexcept;
-
-private:
-    ElementId id_;
-    ElementType type_;
-    std::array<NodeId, 4> connectivity_;
-    PropertyId property_id_;
-};
-
-} // namespace fesa::core

include/fesa/core/LoadDefinition.hpp

@@ -1,21 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-namespace fesa::core {
-
-class NodalLoadDefinition {
-public:
-    NodalLoadDefinition(NodeId node_id, Dof dof, double value);
-
-    NodeId nodeId() const noexcept;
-    Dof dof() const noexcept;
-    double value() const noexcept;
-
-private:
-    NodeId node_id_;
-    Dof dof_;
-    double value_;
-};
-
-} // namespace fesa::core

include/fesa/core/MaterialDefinition.hpp

@@ -1,21 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-namespace fesa::core {
-
-class LinearElasticMaterialDefinition {
-public:
-    LinearElasticMaterialDefinition(MaterialId id, double young_modulus, double poisson_ratio);
-
-    MaterialId id() const noexcept;
-    double youngModulus() const noexcept;
-    double poissonRatio() const noexcept;
-
-private:
-    MaterialId id_;
-    double young_modulus_;
-    double poisson_ratio_;
-};
-
-} // namespace fesa::core

include/fesa/core/ModelTypes.hpp

@@ -1,30 +0,0 @@
-#pragma once
-
-#include <cstddef>
-#include <cstdint>
-
-namespace fesa::core {
-
-using Id = std::int64_t;
-using NodeId = Id;
-using ElementId = Id;
-using MaterialId = Id;
-using PropertyId = Id;
-using StepId = Id;
-
-enum class Dof : std::uint8_t {
-    U1 = 0,
-    U2 = 1,
-    U3 = 2,
-    UR1 = 3,
-    UR2 = 4,
-    UR3 = 5
-};
-
-enum class ElementType {
-    Mitc4
-};
-
-constexpr std::size_t kDofPerNode = 6;
-
-} // namespace fesa::core

include/fesa/core/Node.hpp

@@ -1,26 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-#include <array>
-
-namespace fesa::core {
-
-class Node {
-public:
-    Node(NodeId id, double x, double y, double z);
-
-    static constexpr std::size_t dofCount() noexcept { return kDofPerNode; }
-
-    NodeId id() const noexcept;
-    double x() const noexcept;
-    double y() const noexcept;
-    double z() const noexcept;
-    const std::array<double, 3>& coordinates() const noexcept;
-
-private:
-    NodeId id_;
-    std::array<double, 3> coordinates_;
-};
-
-} // namespace fesa::core

include/fesa/core/PropertyDefinition.hpp

@@ -1,21 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-namespace fesa::core {
-
-class ShellPropertyDefinition {
-public:
-    ShellPropertyDefinition(PropertyId id, MaterialId material_id, double thickness);
-
-    PropertyId id() const noexcept;
-    MaterialId materialId() const noexcept;
-    double thickness() const noexcept;
-
-private:
-    PropertyId id_;
-    MaterialId material_id_;
-    double thickness_;
-};
-
-} // namespace fesa::core

include/fesa/core/StepDefinition.hpp

@@ -1,31 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-#include <cstddef>
-#include <string>
-#include <vector>
-
-namespace fesa::core {
-
-class LinearStaticStepDefinition {
-public:
-    LinearStaticStepDefinition(
-        StepId id,
-        std::string name,
-        std::vector<std::size_t> boundary_condition_indices,
-        std::vector<std::size_t> load_indices);
-
-    StepId id() const noexcept;
-    const std::string& name() const noexcept;
-    const std::vector<std::size_t>& boundaryConditionIndices() const noexcept;
-    const std::vector<std::size_t>& loadIndices() const noexcept;
-
-private:
-    StepId id_;
-    std::string name_;
-    std::vector<std::size_t> boundary_condition_indices_;
-    std::vector<std::size_t> load_indices_;
-};
-
-} // namespace fesa::core

include/fesa/element/Element.hpp

@@ -1,26 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-#include <array>
-#include <cstddef>
-
-namespace fesa::element {
-
-using fesa::core::ElementId;
-using fesa::core::ElementType;
-using fesa::core::NodeId;
-using fesa::core::PropertyId;
-
-class Element {
-public:
-    virtual ~Element() = default;
-
-    virtual ElementId id() const noexcept = 0;
-    virtual ElementType type() const noexcept = 0;
-    virtual std::size_t nodeCount() const noexcept = 0;
-    virtual const std::array<NodeId, 4>& connectivity() const noexcept = 0;
-    virtual PropertyId propertyId() const noexcept = 0;
-};
-
-} // namespace fesa::element

include/fesa/element/Mitc4Element.hpp

@@ -1,24 +0,0 @@
-#pragma once
-
-#include "fesa/element/Element.hpp"
-
-namespace fesa::element {
-
-class Mitc4Element final : public Element {
-public:
-    Mitc4Element(ElementId id, std::array<NodeId, 4> connectivity, PropertyId property_id);
-
-    ElementId id() const noexcept override;
-    ElementType type() const noexcept override;
-    std::size_t nodeCount() const noexcept override;
-    std::size_t dofCount() const noexcept;
-    const std::array<NodeId, 4>& connectivity() const noexcept override;
-    PropertyId propertyId() const noexcept override;
-
-private:
-    ElementId id_;
-    std::array<NodeId, 4> connectivity_;
-    PropertyId property_id_;
-};
-
-} // namespace fesa::element

include/fesa/io/Hdf5ResultWriter.hpp

@@ -1,17 +0,0 @@
-#pragma once
-
-#include <string>
-
-namespace fesa::io {
-
-class Hdf5ResultWriter {
-public:
-    explicit Hdf5ResultWriter(std::string file_path);
-
-    const std::string& filePath() const noexcept;
-
-private:
-    std::string file_path_;
-};
-
-} // namespace fesa::io

include/fesa/load/Load.hpp

@@ -1,16 +0,0 @@
-#pragma once
-
-namespace fesa::load {
-
-enum class LoadKind {
-    Nodal
-};
-
-class Load {
-public:
-    virtual ~Load() = default;
-
-    virtual LoadKind kind() const noexcept = 0;
-};
-
-} // namespace fesa::load

include/fesa/load/NodalLoad.hpp

@@ -1,26 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-#include "fesa/load/Load.hpp"
-
-namespace fesa::load {
-
-using fesa::core::Dof;
-using fesa::core::NodeId;
-
-class NodalLoad final : public Load {
-public:
-    NodalLoad(NodeId node_id, Dof dof, double value);
-
-    LoadKind kind() const noexcept override;
-    NodeId nodeId() const noexcept;
-    Dof dof() const noexcept;
-    double value() const noexcept;
-
-private:
-    NodeId node_id_;
-    Dof dof_;
-    double value_;
-};
-
-} // namespace fesa::load

include/fesa/material/LinearElasticMaterial.hpp

@@ -1,21 +0,0 @@
-#pragma once
-
-#include "fesa/material/Material.hpp"
-
-namespace fesa::material {
-
-class LinearElasticMaterial final : public Material {
-public:
-    LinearElasticMaterial(MaterialId id, double young_modulus, double poisson_ratio);
-
-    MaterialId id() const noexcept override;
-    double youngModulus() const noexcept;
-    double poissonRatio() const noexcept;
-
-private:
-    MaterialId id_;
-    double young_modulus_;
-    double poisson_ratio_;
-};
-
-} // namespace fesa::material

include/fesa/material/Material.hpp

@@ -1,16 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-namespace fesa::material {
-
-using fesa::core::MaterialId;
-
-class Material {
-public:
-    virtual ~Material() = default;
-
-    virtual MaterialId id() const noexcept = 0;
-};
-
-} // namespace fesa::material

include/fesa/property/Property.hpp

@@ -1,21 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-
-namespace fesa::property {
-
-using fesa::core::PropertyId;
-
-enum class PropertyKind {
-    Shell
-};
-
-class Property {
-public:
-    virtual ~Property() = default;
-
-    virtual PropertyId id() const noexcept = 0;
-    virtual PropertyKind kind() const noexcept = 0;
-};
-
-} // namespace fesa::property

include/fesa/property/ShellProperty.hpp

@@ -1,26 +0,0 @@
-#pragma once
-
-#include "fesa/core/ModelTypes.hpp"
-#include "fesa/property/Property.hpp"
-
-namespace fesa::property {
-
-using fesa::core::MaterialId;
-using fesa::core::PropertyId;
-
-class ShellProperty final : public Property {
-public:
-    ShellProperty(PropertyId id, MaterialId material_id, double thickness);
-
-    PropertyId id() const noexcept override;
-    PropertyKind kind() const noexcept override;
-    MaterialId materialId() const noexcept;
-    double thickness() const noexcept;
-
-private:
-    PropertyId id_;
-    MaterialId material_id_;
-    double thickness_;
-};
-
-} // namespace fesa::property

phases/analysis-model-objects/index.json

@@ -1,72 +0,0 @@
-{
-  "project": "FESA Structural Solver",
-  "phase": "analysis-model-objects",
-  "steps": [
-    {
-      "step": 0,
-      "name": "model-object-contract",
-      "status": "completed",
-      "summary": "Created analysis model object implementation plan with base-class contracts, exclusions, and TDD traceability."
-    },
-    {
-      "step": 1,
-      "name": "node-model-class",
-      "status": "completed",
-      "summary": "Added Node DOF count contract and tests while keeping Node free of solver state."
-    },
-    {
-      "step": 2,
-      "name": "element-base-interface",
-      "status": "completed",
-      "summary": "Added identity-only Element base interface and model-object CTest target."
-    },
-    {
-      "step": 3,
-      "name": "mitc4-element-model",
-      "status": "completed",
-      "summary": "Added MITC4 element model skeleton with four-node connectivity and 24-DOF count tests."
-    },
-    {
-      "step": 4,
-      "name": "material-base-interface",
-      "status": "completed",
-      "summary": "Added Material base and LinearElasticMaterial model object with ownership tests."
-    },
-    {
-      "step": 5,
-      "name": "property-section-model",
-      "status": "completed",
-      "summary": "Added ShellProperty model object with positive-thickness validation tests."
-    },
-    {
-      "step": 6,
-      "name": "load-base-interface",
-      "status": "completed",
-      "summary": "Added Load base and NodalLoad model object with polymorphic access tests."
-    },
-    {
-      "step": 7,
-      "name": "boundary-base-interface",
-      "status": "completed",
-      "summary": "Added BoundaryCondition base and SinglePointConstraint model object with polymorphic access tests."
-    },
-    {
-      "step": 8,
-      "name": "domain-polymorphic-ownership",
-      "status": "completed",
-      "summary": "Extended Domain with unique_ptr ownership APIs for element, material, load, and boundary model objects while preserving existing definition APIs."
-    },
-    {
-      "step": 9,
-      "name": "legacy-definition-compatibility",
-      "status": "completed",
-      "summary": "Documented compatibility between core definition DTOs and new runtime model object ownership APIs."
-    },
-    {
-      "step": 10,
-      "name": "validation-report-handoff",
-      "status": "completed",
-      "summary": "Recorded build/test evidence, updated project progress, and marked the phase completed."
-    }
-  ]
-}

phases/analysis-model-objects/step0.md

@@ -1,54 +0,0 @@
-# Step 0: model-object-contract
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/PLAN.md`
-- `/docs/PROGRESS.md`
-- `/docs/WORKNOTE.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/PRD.md`
-- `/docs/ADR.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/domain-model-foundation-implementation-plan.md`
-- `/include/fesa/core/Domain.hpp`
-
-## Task
-
-Create `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`.
-
-The document must define the model object layer that will be stored by `Domain`:
-
-- `Node` model object.
-- abstract `Element` base and MITC4 model object skeleton.
-- abstract `Material` base and linear elastic material model object.
-- shell property/section model object.
-- abstract `Load` base and nodal load model object.
-- abstract `BoundaryCondition` base and single-point constraint model object.
-- `Domain` RAII ownership of polymorphic model objects through `std::unique_ptr`.
-
-State explicitly that this phase does not implement MITC4 stiffness, material constitutive matrices, global force assembly, boundary-condition matrix application, equation numbering, solver vectors, HDF5 output, reference comparison, or reference-solver execution.
-
-Document how existing `*Definition` value objects remain compatible as input DTOs until parser/factory work replaces or maps them.
-
-## Tests To Write First
-
-This is a documentation planning step. Do not write C++ production code in this step.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python -m unittest discover -s scripts -p "test_*.py"
-python scripts/validate_workspace.py
-```
-
-Update `/phases/analysis-model-objects/index.json` step 0 with `completed`, `error`, or `blocked`.
-
-## Do Not
-
-- Do not change C++ code in this step.
-- Do not change MITC4 formulation, I/O contracts, reference artifacts, or tolerance policy.

phases/analysis-model-objects/step1.md

@@ -1,53 +0,0 @@
-# Step 1: node-model-class
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/include/fesa/core/Node.hpp`
-- `/tests/core/node_test.cpp`
-
-## Task
-
-Refine the existing `Node` model class contract without adding solver state.
-
-Allowed files:
-
-- Modify `/include/fesa/core/Node.hpp`
-- Modify `/src/core/Domain.cpp` only if constructor/accessor definitions move or change
-- Modify `/tests/core/node_test.cpp`
-
-Required behavior:
-
-- `Node` exposes `id()`, `coordinates()`, `x()`, `y()`, `z()`.
-- `Node` exposes `static constexpr std::size_t dofCount()` or equivalent compile-time DOF count of 6.
-- `Node` does not store equation ids, displacements, residuals, reactions, or constraints.
-
-## Tests To Write First
-
-Extend `/tests/core/node_test.cpp` before production changes:
-
-- Verify `Node::dofCount() == 6`.
-- Verify coordinate order is preserved.
-- Verify the returned coordinate data is const from a const `Node`.
-
-Run the targeted build and confirm RED before implementation.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain
-```
-
-Update `/phases/analysis-model-objects/index.json` step 1 with status and summary.
-
-## Do Not
-
-- Do not add equation ids or solver state to `Node`.

phases/analysis-model-objects/step10.md

@@ -1,54 +0,0 @@
-# Step 10: validation-report-handoff
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/build-test-reports/README.md`
-- `/docs/PROGRESS.md`
-- `/docs/WORKNOTE.md`
-- `/phases/analysis-model-objects/index.json`
-
-## Task
-
-Run final verification and write handoff evidence.
-
-Allowed files:
-
-- Create `/docs/build-test-reports/analysis-model-objects-build-test.md`
-- Modify `/docs/PROGRESS.md`
-- Modify `/docs/WORKNOTE.md` only if new traps or failed approaches occurred
-- Modify `/phases/analysis-model-objects/index.json`
-- Modify `/phases/index.json`
-
-The build/test report must include command log summary, exit codes, configure/build/CTest status, failure classification or `N/A`, and no-change assertions for reference artifacts and tolerance policy.
-
-## Tests To Write First
-
-This is a validation/reporting step. Do not write new C++ production behavior.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-git status --short --branch
-git remote -v
-python -m unittest discover -s scripts -p "test_*.py"
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"
-git diff --check
-```
-
-Update:
-
-- `/phases/analysis-model-objects/index.json` step 10 with `completed`, `error`, or `blocked`.
-- `/phases/index.json` phase status to `completed` only if all steps are completed.
-- `/docs/PROGRESS.md` with validation evidence.
-
-## Do Not
-
-- Do not claim MITC4 numerical implementation, reference comparison success, or release readiness.
-- Do not run Abaqus, Nastran, or any reference solver.

phases/analysis-model-objects/step2.md

@@ -1,58 +0,0 @@
-# Step 2: element-base-interface
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/include/fesa/core/ElementDefinition.hpp`
-- `/CMakeLists.txt`
-
-## Task
-
-Add the abstract element model interface.
-
-Allowed files:
-
-- Create `/include/fesa/element/Element.hpp`
-- Create `/tests/element/element_base_test.cpp`
-- Modify `/tests/core/domain_bootstrap_test.cpp` only if the current test executable remains the single test runner
-- Modify `/CMakeLists.txt`
-
-Required interface:
-
-- virtual destructor.
-- `ElementId id() const noexcept`.
-- `ElementType type() const noexcept`.
-- `std::size_t nodeCount() const noexcept`.
-- `std::span` is not allowed because this project targets C++17.
-- Use const reference return for connectivity data.
-- no stiffness, residual, stress, state, or equation API in this phase.
-
-## Tests To Write First
-
-Write `/tests/element/element_base_test.cpp` before production changes. Use a small test subclass to prove:
-
-- base pointer dispatch works.
-- id/type/connectivity/property id are readable through base API.
-- deleting through `std::unique_ptr<Element>` is valid.
-
-Run targeted build and confirm RED because `Element.hpp` is missing.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object
-```
-
-Update step 2 status.
-
-## Do Not
-
-- Do not implement MITC4 stiffness or numerical element behavior.

phases/analysis-model-objects/step3.md

@@ -1,57 +0,0 @@
-# Step 3: mitc4-element-model
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/include/fesa/element/Element.hpp`
-- `/include/fesa/core/ElementDefinition.hpp`
-
-## Task
-
-Add a MITC4 element model object skeleton.
-
-Allowed files:
-
-- Create `/include/fesa/element/Mitc4Element.hpp`
-- Create `/src/element/Mitc4Element.cpp`
-- Create `/tests/element/mitc4_element_model_test.cpp`
-- Modify `/CMakeLists.txt`
-
-Required behavior:
-
-- `Mitc4Element` derives from `Element`.
-- Stores element id, four node ids, and property id.
-- Reports `ElementType::Mitc4`.
-- Reports `nodeCount() == 4`.
-- Reports `dofCount() == 24`.
-- Preserves connectivity order.
-
-## Tests To Write First
-
-Write `/tests/element/mitc4_element_model_test.cpp` before production changes:
-
-- Construct `Mitc4Element`.
-- Access it through `const Element&`.
-- Verify id, type, node count, DOF count, connectivity, and property id.
-
-Run targeted build and confirm RED because `Mitc4Element.hpp` is missing.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object
-```
-
-Update step 3 status.
-
-## Do Not
-
-- Do not implement element stiffness, Jacobians, MITC shear interpolation, resultants, stress, or integration-point state.

phases/analysis-model-objects/step4.md

@@ -1,55 +0,0 @@
-# Step 4: material-base-interface
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/include/fesa/core/MaterialDefinition.hpp`
-
-## Task
-
-Add material model base and linear elastic material model object.
-
-Allowed files:
-
-- Create `/include/fesa/material/Material.hpp`
-- Create `/include/fesa/material/LinearElasticMaterial.hpp`
-- Create `/src/material/LinearElasticMaterial.cpp`
-- Create `/tests/material/material_base_test.cpp`
-- Modify `/CMakeLists.txt`
-
-Required behavior:
-
-- `Material` has virtual destructor and `MaterialId id() const noexcept`.
-- `LinearElasticMaterial` derives from `Material`.
-- Stores Young's modulus and Poisson ratio.
-- No constitutive matrix or stress update in this phase.
-
-## Tests To Write First
-
-Write `/tests/material/material_base_test.cpp` before production changes:
-
-- Access `LinearElasticMaterial` through `const Material&`.
-- Verify id, E, and nu.
-- Verify deletion through `std::unique_ptr<Material>`.
-
-Run targeted build and confirm RED.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object
-```
-
-Update step 4 status.
-
-## Do Not
-
-- Do not implement constitutive matrices, stress updates, or tangent stiffness.

phases/analysis-model-objects/step5.md

@@ -1,53 +0,0 @@
-# Step 5: property-section-model
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/include/fesa/core/PropertyDefinition.hpp`
-
-## Task
-
-Add shell property/section model object.
-
-Allowed files:
-
-- Create `/include/fesa/property/ShellProperty.hpp`
-- Create `/src/property/ShellProperty.cpp`
-- Create `/tests/property/shell_property_test.cpp`
-- Modify `/CMakeLists.txt`
-
-Required behavior:
-
-- Stores property id, material id, and thickness.
-- Exposes const accessors.
-- Rejects non-positive thickness with `std::invalid_argument`.
-- Does not compute shell section stiffness.
-
-## Tests To Write First
-
-Write `/tests/property/shell_property_test.cpp` before production changes:
-
-- Valid property stores id/material/thickness.
-- Zero or negative thickness throws.
-
-Run targeted build and confirm RED.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object
-```
-
-Update step 5 status.
-
-## Do Not
-
-- Do not implement membrane, bending, or shear constitutive stiffness.

phases/analysis-model-objects/step6.md

@@ -1,55 +0,0 @@
-# Step 6: load-base-interface
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/include/fesa/core/LoadDefinition.hpp`
-
-## Task
-
-Add load model base and nodal load object.
-
-Allowed files:
-
-- Create `/include/fesa/load/Load.hpp`
-- Create `/include/fesa/load/NodalLoad.hpp`
-- Create `/src/load/NodalLoad.cpp`
-- Create `/tests/load/load_base_test.cpp`
-- Modify `/CMakeLists.txt`
-
-Required behavior:
-
-- `Load` has virtual destructor and a load kind enum.
-- `NodalLoad` derives from `Load`.
-- Stores node id, DOF, and value.
-- No global vector assembly in this phase.
-
-## Tests To Write First
-
-Write `/tests/load/load_base_test.cpp` before production changes:
-
-- Access `NodalLoad` through `const Load&`.
-- Verify kind, node id, DOF, value.
-- Verify deletion through `std::unique_ptr<Load>`.
-
-Run targeted build and confirm RED.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object
-```
-
-Update step 6 status.
-
-## Do Not
-
-- Do not assemble forces or apply time/load factors.

phases/analysis-model-objects/step7.md

@@ -1,55 +0,0 @@
-# Step 7: boundary-base-interface
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/include/fesa/core/BoundaryCondition.hpp`
-
-## Task
-
-Add boundary condition model base and single-point constraint object.
-
-Allowed files:
-
-- Create `/include/fesa/boundary/BoundaryCondition.hpp`
-- Create `/include/fesa/boundary/SinglePointConstraint.hpp`
-- Create `/src/boundary/SinglePointConstraint.cpp`
-- Create `/tests/boundary/boundary_base_test.cpp`
-- Modify `/CMakeLists.txt`
-
-Required behavior:
-
-- `BoundaryCondition` has virtual destructor and a boundary kind enum.
-- `SinglePointConstraint` derives from `BoundaryCondition`.
-- Stores node id, DOF, prescribed value.
-- No matrix elimination or reaction recovery in this phase.
-
-## Tests To Write First
-
-Write `/tests/boundary/boundary_base_test.cpp` before production changes:
-
-- Access `SinglePointConstraint` through `const BoundaryCondition&`.
-- Verify kind, node id, DOF, value.
-- Verify deletion through `std::unique_ptr<BoundaryCondition>`.
-
-Run targeted build and confirm RED.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object
-```
-
-Update step 7 status.
-
-## Do Not
-
-- Do not apply constraints to matrices or compute reactions.

phases/analysis-model-objects/step8.md

@@ -1,62 +0,0 @@
-# Step 8: domain-polymorphic-ownership
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/include/fesa/core/Domain.hpp`
-- all model object headers created by previous steps
-
-## Task
-
-Extend `Domain` with RAII ownership APIs for polymorphic model objects while preserving existing definition-storage tests.
-
-Allowed files:
-
-- Modify `/include/fesa/core/Domain.hpp`
-- Modify `/src/core/Domain.cpp`
-- Create `/tests/core/domain_model_object_test.cpp`
-- Modify `/tests/core/domain_bootstrap_test.cpp`
-- Modify `/CMakeLists.txt`
-
-Required behavior:
-
-- `Domain::addElementObject(std::unique_ptr<Element>)`
-- `Domain::findElementObject(ElementId)` and `Domain::elementObject(ElementId)`
-- equivalent add/find/direct APIs for `Material`, `Load`, and model `BoundaryCondition`.
-- duplicate ids or duplicate load/boundary keys throw `std::invalid_argument`.
-- missing direct lookup throws `std::out_of_range`.
-- retrieval returns const base references or const base pointers.
-- existing `Definition` APIs remain available.
-
-## Tests To Write First
-
-Write `/tests/core/domain_model_object_test.cpp` before production changes:
-
-- Domain owns `Mitc4Element`, `LinearElasticMaterial`, `NodalLoad`, and `SinglePointConstraint` through `std::unique_ptr`.
-- Find/direct lookup through base APIs works.
-- Duplicate ids throw for element/material.
-- Missing direct lookup throws.
-
-Run targeted build and confirm RED.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R model-object
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R domain
-```
-
-Update step 8 status.
-
-## Do Not
-
-- Do not remove existing definition APIs in this step.
-- Do not add solver state to Domain.

phases/analysis-model-objects/step9.md

@@ -1,49 +0,0 @@
-# Step 9: legacy-definition-compatibility
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/include/fesa/core/Domain.hpp`
-- `/tests/core/domain_storage_test.cpp`
-- `/tests/core/domain_model_object_test.cpp`
-
-## Task
-
-Preserve and document compatibility between existing `*Definition` value objects and new model-object base classes.
-
-Allowed files:
-
-- Modify `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- Modify tests only if compatibility gaps are found
-- Modify production code only for narrow compatibility fixes
-
-Required behavior:
-
-- Existing Domain definition-storage tests still pass.
-- New model-object ownership tests still pass.
-- The implementation plan clearly states that `*Definition` objects remain parser/factory DTOs until the parser phase decides whether to map or replace them.
-
-## Tests To Write First
-
-If production code must change, write or extend a failing C++ test before the change. If this is documentation-only, do not add production code.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python scripts/validate_workspace.py
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R "domain|model-object"
-```
-
-Update step 9 status.
-
-## Do Not
-
-- Do not delete existing `*Definition` headers or tests.
-- Do not rewrite parser or factory behavior.

phases/analysis-state-analysis-base/index.json

@@ -1,42 +0,0 @@
-{
-  "project": "FESA Structural Solver",
-  "phase": "analysis-state-analysis-base",
-  "steps": [
-    {
-      "step": 0,
-      "name": "analysis-contract-plan",
-      "status": "completed",
-      "summary": "Created the analysis state and analysis base implementation plan with scope, contracts, TDD tasks, and exclusions."
-    },
-    {
-      "step": 1,
-      "name": "analysis-state-core",
-      "status": "completed",
-      "summary": "Added AnalysisState with zero-sized and sized vector storage for displacement, forces, residual, and reaction."
-    },
-    {
-      "step": 2,
-      "name": "analysis-state-guards",
-      "status": "completed",
-      "summary": "Added AnalysisState setters, size guards, resize reset, clearForces, and time/increment/iteration counters."
-    },
-    {
-      "step": 3,
-      "name": "analysis-base-interface",
-      "status": "completed",
-      "summary": "Added the Analysis base interface with const Domain input, mutable AnalysisState, name contract, virtual deletion, and run delegation."
-    },
-    {
-      "step": 4,
-      "name": "cmake-analysis-tests",
-      "status": "completed",
-      "summary": "Registered fesa_analysis_tests and confirmed analysis, domain, model-object, and io CTest targets pass together."
-    },
-    {
-      "step": 5,
-      "name": "validation-report-handoff",
-      "status": "completed",
-      "summary": "Recorded build/test evidence, updated project progress, and marked the phase completed."
-    }
-  ]
-}

phases/analysis-state-analysis-base/step0.md

@@ -1,62 +0,0 @@
-# Step 0: analysis-contract-plan
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/PLAN.md`
-- `/docs/PROGRESS.md`
-- `/docs/WORKNOTE.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/PRD.md`
-- `/docs/ADR.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-model-objects-implementation-plan.md`
-- `/docs/implementation-plans/property-model-foundation-implementation-plan.md`
-- `/include/fesa/core/Domain.hpp`
-- `/include/fesa/core/ModelTypes.hpp`
-- `/include/fesa/core/StepDefinition.hpp`
-- `/CMakeLists.txt`
-
-## Task
-
-Create `/docs/implementation-plans/analysis-state-analysis-base-implementation-plan.md`.
-
-The document must define the implementation contract for:
-
-- `fesa::core::AnalysisState` as mutable analysis state storage.
-- `fesa::analysis::Analysis` as the base analysis strategy interface.
-- A dedicated CTest path for analysis-layer tests.
-
-State explicitly that this phase does not implement:
-
-- `AnalysisModel`
-- `DofManager`
-- MITC4 stiffness, stress, resultants, or force recovery
-- global assembly
-- constrained DOF elimination
-- MKL/PARDISO solve
-- HDF5 result writing beyond existing skeletons
-- reference comparison
-- Abaqus/Nastran/reference-solver execution
-
-## Tests To Write First
-
-This is a documentation planning step. Do not write C++ production code in this step.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-python -m unittest discover -s scripts -p "test_*.py"
-python scripts/validate_workspace.py
-```
-
-Update `/phases/analysis-state-analysis-base/index.json` step 0 with `completed`, `error`, or `blocked`.
-
-## Do Not
-
-- Do not change C++ code in this step.
-- Do not change requirements, formulations, I/O contracts, reference artifacts, or tolerance policy.

phases/analysis-state-analysis-base/step1.md

@@ -1,69 +0,0 @@
-# Step 1: analysis-state-core
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/PLAN.md`
-- `/docs/PROGRESS.md`
-- `/docs/WORKNOTE.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ADR.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-state-analysis-base-implementation-plan.md`
-- `/include/fesa/core/ModelTypes.hpp`
-- `/include/fesa/core/Domain.hpp`
-- `/CMakeLists.txt`
-
-## Task
-
-Add `fesa::core::AnalysisState`.
-
-Candidate files:
-
-- Create `/include/fesa/core/AnalysisState.hpp`
-- Create `/src/core/AnalysisState.cpp`
-- Create `/tests/core/analysis_state_test.cpp`
-- Modify `/CMakeLists.txt`
-
-Required initial contract:
-
-- `AnalysisState()` starts with zero DOFs and empty vectors.
-- `explicit AnalysisState(std::size_t dof_count)` allocates zero-filled vectors.
-- `dofCount()` returns the current vector size.
-- `displacement()`, `externalForce()`, `internalForce()`, `residual()`, and `reaction()` return const vector references.
-- All state vectors have the same size as `dofCount()`.
-- State is mutable analysis data only. Do not store node ids, element ids, equation ids, sparse data, solver handles, writer handles, or references to `Domain`.
-
-## Tests To Write First
-
-Write tests in `/tests/core/analysis_state_test.cpp` before creating production code:
-
-- default state has zero DOFs and all vectors empty.
-- sized state creates zero-filled displacement, external force, internal force, residual, and reaction vectors.
-- `dofCount()` matches vector sizes.
-
-Run the targeted test and confirm it fails because `AnalysisState` does not exist:
-
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis
-```
-
-Then implement the minimum code needed to pass.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis
-python scripts/validate_workspace.py
-```
-
-Update `/phases/analysis-state-analysis-base/index.json` step 1 with `completed`, `error`, or `blocked`.
-
-## Do Not
-
-- Do not implement `AnalysisModel`, `DofManager`, assembly, solver, or result output.
-- Do not add mutable solver state to `Domain`, `Node`, `Element`, `Material`, `Property`, `Load`, or `BoundaryCondition`.

phases/analysis-state-analysis-base/step2.md

@@ -1,65 +0,0 @@
-# Step 2: analysis-state-guards
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/PLAN.md`
-- `/docs/PROGRESS.md`
-- `/docs/WORKNOTE.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/implementation-plans/analysis-state-analysis-base-implementation-plan.md`
-- `/include/fesa/core/AnalysisState.hpp`
-- `/src/core/AnalysisState.cpp`
-- `/tests/core/analysis_state_test.cpp`
-- `/CMakeLists.txt`
-
-## Task
-
-Extend `AnalysisState` with mutation and guard behavior.
-
-Required contract:
-
-- `resize(std::size_t dof_count)` resets every vector to the new size and fills with zero.
-- `setDisplacement(std::vector<double>)`, `setExternalForce(std::vector<double>)`, `setInternalForce(std::vector<double>)`, `setResidual(std::vector<double>)`, and `setReaction(std::vector<double>)` replace one vector.
-- setter inputs must match `dofCount()`.
-- size mismatch throws `std::invalid_argument`.
-- a failed setter must not mutate the existing vector.
-- `clearForces()` zeros external force, internal force, residual, and reaction while leaving displacement unchanged.
-- `currentTime()`, `incrementIndex()`, and `iterationIndex()` accessors exist with setters.
-
-## Tests To Write First
-
-Add tests in `/tests/core/analysis_state_test.cpp` before production changes:
-
-- setters replace vectors when sizes match.
-- mismatched setter input throws and preserves old values.
-- resize resets all vectors to zero.
-- clearForces preserves displacement and zeros force-like vectors.
-- time, increment, and iteration counters can be updated.
-
-Run the targeted test and confirm it fails before implementation:
-
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis
-```
-
-Then implement the minimum code needed to pass.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis
-python scripts/validate_workspace.py
-```
-
-Update `/phases/analysis-state-analysis-base/index.json` step 2 with `completed`, `error`, or `blocked`.
-
-## Do Not
-
-- Do not add dynamics-only velocity or acceleration vectors in this phase.
-- Do not add thermal temperature fields in this phase.
-- Do not add equation numbering or DOF mapping responsibilities.

phases/analysis-state-analysis-base/step3.md

@@ -1,69 +0,0 @@
-# Step 3: analysis-base-interface
-
-## Read First
-
-Read these files before editing:
-
-- `/AGENTS.md`
-- `/docs/PLAN.md`
-- `/docs/PROGRESS.md`
-- `/docs/WORKNOTE.md`
-- `/docs/AGENT_RULES.md`
-- `/docs/ADR.md`
-- `/docs/ARCHITECTURE.md`
-- `/docs/implementation-plans/analysis-state-analysis-base-implementation-plan.md`
-- `/include/fesa/core/Domain.hpp`
-- `/include/fesa/core/AnalysisState.hpp`
-- `/CMakeLists.txt`
-
-## Task
-
-Add `fesa::analysis::Analysis` as a minimal base interface for future analysis strategies.
-
-Candidate files:
-
-- Create `/include/fesa/analysis/Analysis.hpp`
-- Create `/tests/analysis/analysis_base_test.cpp`
-- Modify `/CMakeLists.txt`
-
-Required contract:
-
-- `Analysis` has a virtual destructor.
-- `Analysis` exposes `const char* name() const noexcept`.
-- `Analysis` exposes `void run(const fesa::core::Domain& domain, fesa::core::AnalysisState& state)`.
-- `run` delegates to a protected pure virtual `doRun(const fesa::core::Domain&, fesa::core::AnalysisState&)`.
-- `Domain` is passed as const; `AnalysisState` is mutable.
-- The base class must not own `Domain`, `AnalysisState`, solver objects, result writers, or reference artifacts.
-
-## Tests To Write First
-
-Write tests in `/tests/analysis/analysis_base_test.cpp` before production changes:
-
-- a derived recording analysis can be used through `Analysis&`.
-- `run` forwards the const `Domain` and mutable `AnalysisState` to the derived implementation.
-- derived implementation can update `AnalysisState` without mutating `Domain`.
-- `Analysis` can be deleted through a base pointer.
-
-Run the targeted test and confirm it fails before implementation:
-
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis
-```
-
-Then implement the minimum code needed to pass.
-
-## Acceptance Criteria
-
-Run:
-
-```powershell
-ctest --test-dir build/msvc-debug --output-on-failure -C Debug -R analysis
-python scripts/validate_workspace.py
-```
-
-Update `/phases/analysis-state-analysis-base/index.json` step 3 with `completed`, `error`, or `blocked`.
-
-## Do Not
-
-- Do not implement `LinearStaticAnalysis`.
-- Do not add template-method hook lists for assembly, solve, boundary conditions, or output until `AnalysisModel` and `DofManager` exist.