revert

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