modify documents

docs/PRD.md

@@ -1,179 +1,148 @@
 # PRD: FESA 구조해석 솔버
 
-## 목표
-FESA는 Abaqus `.inp` keyword subset을 입력으로 받아 자체 유한요소 정식화로 구조해석을
-수행하고, step/frame 단위 결과를 input lexical sibling `<stem>_results.h5` HDF5로 저장하며, 기능이 지정한 Abaqus
-reference CSV 수치와 비교 가능한 C++17/MSVC 솔버를 제공한다. Abaqus의 요소 알고리즘,
-적분법, stabilization 또는 내부 결과 생성 절차를 재현하는 것은 목표가 아니다.
+## 제품 정의
 
-이 프로젝트의 성공 기준은 단순 실행 성공이 아니다. 기능 구현은 요구조건, 정식화,
-I/O 계약, C++ build/test와 기능별 blocking reference comparison을 통과해야 완료된다.
-Physics sanity와 release readiness는 구현 완료 뒤 별도 배포 판단을 제공하며 Abaqus 내부
-동작 동등성을 요구하지 않는다.
+FESA는 유한요소법 기반 구조해석 솔버를 단계적으로 구축하는 프로젝트이다. 물리적으로
+설명 가능하고 재현 가능한 해석 결과를 제공하며, 새로운 기능을 요구사항부터 독립 검증까지
+추적 가능한 단위로 확장하는 것을 목표로 한다.
 
-## 사용자
-- Solver developer: C++17/MSVC/CMake/CTest 환경에서 요소, 재료, 해석 절차, solver backend를 구현한다.
-- Verification reviewer: reference artifact, tolerance, physics sanity, release readiness를 검토한다.
-- Analyst preparing Abaqus-compatible input subsets: FESA가 지원하는 제한된 `.inp` subset에 맞춰 입력 모델을 준비한다.
-- Codex agent workflow operator: project-local agent와 skill을 사용해 요구조건부터 release까지의 gate를 운영한다.
+이 문서는 특정 요소, 재료, 하중 또는 해석 절차의 명세가 아니라 모든 Feature에 적용되는
+제품 기준이다. 개별 지원 범위, 입력 옵션, 수식, 수치 기준과 검증 사례는
+`docs/<feature-id>/`의 승인 계약으로 정의한다. 특정 기능의 코드가 존재한다는 사실과
+그 기능의 검증 완료 또는 현재 release readiness는 서로 다른 상태다.
 
-## 핵심 기능
-1. Abaqus `.inp` keyword subset parser와 내부 `Domain` semantic model 생성
-2. `AnalysisModel`, `DofManager`, `AnalysisState` 기반의 step별 equation system 구성
-3. 선형 정적 해석을 시작점으로 하는 `Analysis` procedure 계층
-4. Stable source identity를 보존하는 concrete V0 node, B33 element, material, section, boundary, load record
-5. sparse matrix pattern 생성, 전역 행렬/벡터 조립, 제약조건 적용
-6. `LinearSolver`, `ParallelFor`, `ResultsWriter` interface를 통한 MKL PARDISO, oneTBB, HDF5 backend 격리
-7. HDF5 기반 versioned step/frame field-result 저장과 향후 history-output 확장 경계
-8. FESA HDF5 rows와 `reference/<model-id>/` 아래 Abaqus reference CSV rows의 직접 비교
-9. CMake/MSVC/x64/Debug, CTest 기반 개발 검증
+현재 선택된 기술 스택과 외부 형식은 [프로젝트 지침](../AGENTS.md) 및 승인된 계약을
+따른다. 공통 문서의 일반화는 기존 지원 범위, 파일 형식, 수치 정책 또는 호환성을 변경하는
+승인이 아니다.
 
-Element/material 계층의 일반적인 runtime polymorphism, iterative solver, history output은 장기 확장 방향이다. 현재 제품 계약으로 간주하지 않으며, 실제 사용 사례와 성능·수명 요구가 승인되기 전에 추상 base class를 미리 추가하지 않는다.
+## 대상 사용자
 
-## 사용자 관점 제품 흐름
+- Solver 개발자: 요소, 재료, 하중, 제약, 해석 절차와 수치 backend를 구현한다.
+- 해석 사용자: 문서화된 입력 범위로 모델을 구성하고 결과와 진단을 해석한다.
+- 검증 담당자: 수학적 일관성, 물리적 타당성, reference 비교와 회귀 evidence를 검토한다.
+- Maintainer와 workflow 운영자: 요구사항, 결정, 구현과 검증의 추적성 및 변경 범위를 관리한다.
 
-1. 사용자는 승인된 Abaqus `.inp` subset으로 모델과 단일 analysis step을 기술한다.
-2. FESA는 syntax를 읽은 뒤 semantic mapping과 model validation을 수행한다. 지원하지 않는 모델 의미는 구조화된 diagnostic과 안정된 exit code로 거부한다.
-3. 해석 procedure는 active model view, DOF/equation map과 sparse system을 만들고, essential constraint elimination을 적용해 선형계를 factorize하고 substitution한다.
-4. FESA는 full displacement를 복구하고 equilibrium residual/reaction과 element 결과를 계산한다.
-5. 성공 시 output request와 무관한 mandatory 결과, metadata와 diagnostic을 versioned lexical sibling `<stem>_results.h5`에 기록한다. 실패 시 불완전한 최종 결과 파일을 정상 결과처럼 남기지 않는다.
-6. 검증 workflow는 기능이 지정한 HDF5 quantity를 기존 Abaqus CSV의 source identity와
-   component에 대응시켜 tolerance를 판정하고, 별도로 equilibrium과 물리적 타당성을
-   검토한다. Reference bundle naming이나 provenance는 수치 비교 gate가 아니다.
+## 제품 목표
 
-Parser keyword, element kernel, solver backend 또는 output dataset 중 하나만 추가된 상태는 end-to-end 제품 기능이 아니다. 같은 기능의 입력 의미부터 외부 결과와 검증까지 연결되어야 한다.
+1. 해석의 물리·수치 의미를 입력부터 결과까지 보존한다.
+2. 작은 Feature를 end-to-end로 완성한 뒤 검증된 기반 위에서 지원 범위를 확장한다.
+3. 모델 의미, 계산 상태, 수치 backend와 저장 형식의 책임을 구분한다.
+4. 같은 입력과 승인된 실행 조건에서 source identity, 조립·결과·진단 순서를 재현한다.
+5. 잘못되거나 지원하지 않는 모델 의미를 조용히 근사하지 않고 명확히 진단한다.
+6. 요구사항, 설계 결정, 구현, 테스트와 검증 결과를 같은 Feature와 contract revision으로 연결한다.
 
-## V0 범위
-- 선형 정적 해석 파이프라인 구현
-- 승인된 첫 end-to-end 기능: 2절점 3D Euler–Bernoulli beam, Abaqus `TYPE=B33`
-- 입력 파일당 하나의 `*STEP, *STATIC`
-- 절점당 자유도 `[UX, UY, UZ, URX, URY, URZ]`
-- 축, 두 방향 굽힘, Saint-Venant 비틀림 및 선형 등방 탄성
-- 최소 Abaqus keyword subset:
-  - `*HEADING`
-  - `*PART`, `*END PART`
-  - `*NODE`, `*ELEMENT, TYPE=B33`
-  - `*NSET`, `*ELSET`, including `GENERATE`
-  - `*MATERIAL`
-  - `*ELASTIC`
-  - `*BEAM GENERAL SECTION, SECTION=GENERAL`
-  - `*SECTION POINTS`
-  - `*ASSEMBLY`, `*END ASSEMBLY`
-  - `*INSTANCE`, `*END INSTANCE`
-  - `*BOUNDARY`
-  - `*CLOAD`
-  - `*STEP`, `*STATIC`, `*END STEP`
-- `*PREPRINT`, `*RESTART`, `*TRANSVERSE SHEAR STIFFNESS`, `*OUTPUT, FIELD`,
-  `*OUTPUT, HISTORY`, `*NODE OUTPUT`, `*ELEMENT OUTPUT`, `*CONTACT OUTPUT`과 그에 속한
-  미지원 variable data는 warning 후 no-op 처리
-- 같은 part의 여러 identity instance와 stable source label mapping
-- nonzero prescribed displacement를 포함한 free/constrained partition
-- formulation의 constant local line-load equivalent nodal vector kernel. V0 parser와 CLI는
-  `*DLOAD`를 지원하거나 이 kernel을 호출하지 않음
-- deterministic COO-to-CSR stiffness assembly
-- MKL PARDISO 기반 sparse direct solver
-- stiffness factorization과 load-vector substitution 분리
-- displacements, reactions, equilibrium end actions, section resultants, generalized results,
-  axial `S11` output
-- HDF5 result schema v0
-- `fesa.exe <model.inp>` CLI with lexical sibling result/log names
-- 승인된 `reference/cantilever beam/` B33 결과와 displacement, reaction, section resultant
-  comparison; beam stress reference comparison은 N/A
+Harness와 agent·skill은 이 목표를 달성하기 위한 개발 운영 인프라다. 운영 스크립트나
+문서 체계 자체를 구조해석 솔버의 제품 기능으로 간주하지 않는다.
 
-## 승인된 Nonlinear Static 확장
+## 문서와 계약의 역할
 
-- `*STATIC, NLGEOM=YES` 단일 step은 parse/map을 정확히 한 번 수행한 뒤 linear static과
-  분리된 full-Newton procedure로 dispatch한다. Nonlinear path는 별도 mutable state,
-  unsymmetric tangent solver, iteration log writer와 schema-v1 HDF5 writer를 사용한다.
-- CLI는 정확히 하나의 `<model.inp>`만 받고 `<stem>_results.h5`와 `<stem>_log.txt`를 같은
-  lexical sibling directory에 유도한다. `--output`은 지원하지 않는다.
-- Nonlinear HDF5 schema v1은 committed accepted frame만 기록한다. factor-zero는 metadata
-  baseline이며 accepted frame이 아니고, successful factor-one row는 unique
-  `load_factor=1.0` accepted frame이다.
-- Factor-one `/global/equilibrium`은 global origin에서 current `X+u` arm과 spatial physical
-  moment를 사용한 applied-plus-constrained-reaction balance error다. Accepted free residual과
-  constrained-reaction resultant는 그 dataset의 대체 quantity가 아니다.
-- `shellNL-meshfine`는 primary nonlinear case, `shellNL`은 companion, `shell`은 linear
-  regression control이다. `U1/U2/U3`는 blocking, `UR1/UR2/UR3`는 warning-only이며 local
-  `RF/RM`은 review-only (`RM3` 및 stress 제외)로 비교한다.
+| 문서 | 소유하는 내용 |
+| --- | --- |
+| 이 PRD | 제품 목적, 공통 요구사항, 품질 속성과 완료 기준 |
+| [ARCHITECTURE](ARCHITECTURE.md) | 공통 책임, 의존성, 수명과 확장 경계 |
+| [ADR](ADR.md) | 프로젝트 전반의 설계 결정과 변경 이력 |
+| Feature `PRD.md` | 해당 요구의 목적·범위·제외·acceptance 요약과 상세 요구사항 링크 |
+| Feature `requirements.md` | Requirement Agent가 소유하는 검증 가능한 요구사항과 verification matrix |
+| Feature `ADR.md` | 해당 Feature의 결정·이유·영향·owner와 승인 근거 |
+| Feature 전문 산출물 | 연구, 정식화, 수치/reference 검토, I/O, 구현·검증, 물리 검토와 release evidence |
 
-## 신규 기능의 제품 완료 정의
+Feature 문서의 생성·재개, Coordinator 관리 문서와 상세 문서 분리는
+[FEATURE_DOCUMENTATION](FEATURE_DOCUMENTATION.md)을 따른다. Feature PRD가
+`requirements.md`와 별도의 요구사항 원본을 만들거나 공통 기준을 묵시적으로 덮어쓰지 않는다.
+공통 기준 자체의 변경은 별도로 승인된 프로젝트 문서 작업으로 다룬다.
 
-새로운 element, load, constraint, material, analysis procedure 또는 output quantity는 다음 조건을 모두 만족할 때 FESA 제품 기능으로 취급한다.
+## 공통 기능 요구사항
 
-1. 지원 범위와 제외 범위, 실패 category, solver output의 units/coordinates/identity,
-   blocking reference quantity와 tolerance가 요구조건과 I/O 계약에 명시되어 있다.
-2. 필요한 FEM 정식화와 recovery/sign convention이 검토되었고, 수치 위험과 검증 문제를 numerical review가 다룬다.
-3. Syntax와 semantic mapping이 내부 모델에 안정된 source identity로 연결되며 잘못된 입력을 fail-closed로 거부한다. Kernel만 제공하는 기능은 parser/CLI 지원 여부를 별도로 표시한다.
-4. DOF, sparse pattern, assembly, constraint, solver lifecycle과 mutable state ownership이 기존 아키텍처에 연결되거나 승인된 새 procedure 경계를 가진다.
-5. Mandatory HDF5 schema와 diagnostic, CLI 실패 의미가 정의되고 failure path가 기존 state 또는 최종 output을 오염시키지 않는다.
-6. Unit test가 local 수식과 validation을, integration test가 orchestration과 외부 계약을,
-   required reference comparison이 기능별 blocking quantity의 외부 수치 acceptance를
-   각각 증명한다. Reference가 N/A이면 그 이유와 대체 evidence를 명시한다.
+아래 `FESA-PRD-GEN-*`는 공통 원칙을 위한 추적 ID다. 기존 `FESA-PRD-001`부터
+`FESA-PRD-019`까지의 의미를 바꾸어 재사용하지 않으며, 그 원문과 적용 범위는
+[개정 전 PRD](archive/pre-generalization/PRD.md)에 보존한다. Feature의 상세 요구사항은
+별도 `FEM-REQ-<FEATURE>-###` ID와 해당 공통 기준을 연결한다.
 
-## 기능 요구조건
-| ID | 요구조건 | Acceptance Criteria | Verification Method |
-| --- | --- | --- | --- |
-| FESA-PRD-001 | FESA는 Abaqus `.inp` full compatibility가 아니라 승인된 keyword subset만 지원해야 한다. | 지원/미지원 keyword가 문서화되고, 미지원 keyword는 구조화된 diagnostic을 남긴다. | I/O contract review, parser unit test |
-| FESA-PRD-002 | FESA는 입력 모델을 `Domain`으로 변환해야 한다. | nodes, elements, materials, properties, sets, loads, boundary conditions, step definitions가 semantic model에 보존된다. | parser integration test |
-| FESA-PRD-003 | FESA는 현재 step의 실행 view를 `AnalysisModel`로 구성해야 한다. | active elements, loads, boundary conditions, properties/materials가 Domain 복사 없이 참조 또는 id view로 연결된다. | analysis model unit test |
-| FESA-PRD-004 | FESA는 equation numbering과 constraint/free mapping을 `DofManager`에 집중해야 한다. | Node/Element 내부에 equation id를 분산 저장하지 않는다. | code review, DofManager unit test |
-| FESA-PRD-005 | FESA는 해석 중 변하는 물리량을 `AnalysisState`에 저장해야 한다. | V0 displacement, external/internal force, residual, constrained reaction, step/frame identity와 element recovery rows가 출력에 연결되고 velocity, acceleration, temperature, iteration history는 할당하지 않는다. | state unit test, integration test |
-| FESA-PRD-006 | FESA는 solver 결과를 derived HDF5 authoritative output `<stem>_results.h5`로 저장해야 한다. | V0 step/frame field results, metadata, diagnostics가 schema version과 함께 저장된다. | HDF5 schema test |
-| FESA-PRD-007 | FESA는 기능이 지정한 Abaqus reference CSV quantity와 비교 가능한 deterministic source-row/component mapping을 제공해야 한다. | Required source IDs/components는 일대일 대응되고 missing/extra/duplicate/nonfinite row는 tolerance 전에 실패한다. Canonical naming, README, metadata, provenance 또는 CSV schema version은 요구하지 않는다. | reference comparison report |
-| FESA-PRD-008 | FESA의 production C++ 변경은 테스트를 먼저 작성하고 실패를 확인한 뒤 구현해야 한다. | 관련 C++ test file, RED 실패와 후속 GREEN 성공 증거가 있고 Stop의 전체 MSVC build/test가 통과한다. | implementation report, Hook guardrail, CTest |
-| FESA-PRD-009 | FESA는 외부 라이브러리 API를 solver core에 직접 노출하지 않아야 한다. | MKL, TBB, HDF5 의존은 adapter module에 제한된다. | architecture review, dependency review |
-| FESA-PRD-010 | FESA 기능 구현 완료는 build/test와 기능별 blocking reference comparison 통과를 요구해야 한다. | Required CTest가 통과하고 선언된 blocking quantity가 승인 tolerance 안에 있다. Physics sanity와 release readiness는 별도 후속 gate다. | build/test report, reference verification report |
-| FESA-PRD-011 | V0는 입력 파일당 하나의 linear static step과 Abaqus B33 3D Euler beam만 해석해야 한다. | 단일 B33 model은 해석되고, B31과 두 번째 step은 구조화된 unsupported diagnostic으로 거부된다. | parser/semantic unit test, CLI integration test |
-| FESA-PRD-012 | V0는 Part/Assembly/Instance wrapper와 source identity를 보존해야 한다. | 여러 identity instance의 node/element/set label이 stable internal ID로 deterministic하게 매핑되고 transform 또는 nested assembly는 거부된다. | semantic mapping unit test |
-| FESA-PRD-013 | Output-request allowlist는 해석 의미를 변경하지 않아야 한다. | 승인 keyword와 variable data는 warning 후 no-op이고, allowlist 밖 model-affecting keyword는 오류이며 기본 결과는 output request와 무관하게 생성된다. | parser diagnostic test, HDF5 integration test |
-| FESA-PRD-014 | 선형 정적 pipeline은 stiffness factorization과 load substitution을 분리해야 한다. | `Kff` factorization이 load vector assembly보다 먼저 수행되고, `rhs=Ff-Kfc*dc` substitution으로 full displacement를 복구한다. | orchestration test, solver-adapter test |
-| FESA-PRD-015 | FESA는 V0 결과와 diagnostic을 안정된 외부 계약으로 출력해야 한다. | CLI가 `0=success`, `2=usage`, `3=input`, `4=model`, `5=solver`, `6=HDF5` exit code를 사용하고 diagnostic field가 계약과 일치하며 HDF5가 displacement, reaction, end force, section resultant, generalized strain/resultant, axial `S11`을 포함하고 실패 시 불완전한 최종 파일을 남기지 않는다. | CLI integration test, HDF5 schema/atomicity test |
-| FESA-PRD-016 | Dense와 sparse math storage 및 backend 경계를 분리해야 한다. | `Vector`는 contiguous, `Matrix`는 row-major contiguous storage와 MKL CBLAS를 사용하고 `SparseMatrix`는 별도 0-based CSR 타입이며 MKL 타입이 public core API에 노출되지 않는다. | math unit test, dependency review |
-| FESA-PRD-017 | 모든 외부 reference comparison은 승인된 공통 family-scale tolerance를 사용해야 한다. | 각 matched row가 near-zero 대체 조건 또는 상대오차 `0.05`를 통과하고 각 family의 scale-relative RMS가 `0.01` 이하이며 missing/extra/duplicate/nonfinite row는 comparison 전에 실패한다. | reference comparison unit/integration test, verification report |
-| FESA-PRD-018 | 승인된 B33 reference artifact는 현재 경로의 read-only baseline으로 유지해야 한다. | `reference/cantilever beam/` 파일을 rename, rewrite 또는 보정하지 않고 기능이 선언한 exact path에서 읽는다. | artifact inventory, Git diff review |
-| FESA-PRD-019 | B33 beam section과 local axis를 Abaqus 의미에 맞게 매핑해야 한다. | `n1 -> local y`, `t x n1 -> local z`, `Iy=I11`, `Iz=I22`, `I12=0`을 적용하고 nonpositive property, zero-length element, tangent-parallel guide vector를 구조화된 model diagnostic으로 거부한다. | section-mapping unit test, element geometry test |
+| ID | 요구사항 | 확인할 evidence |
+| --- | --- | --- |
+| FESA-PRD-GEN-001 | 지원·미지원 범위와 관찰 가능한 동작을 Feature 계약으로 명시해야 한다. | 범위·제외·입력/출력 계약 및 양성·음성 검증 |
+| FESA-PRD-GEN-002 | 입력을 일관된 semantic model로 변환하고 잘못된 참조·중복·비유한 값·미지원 조합을 진단해야 한다. | Mapping·validation 계약과 실패 경로 테스트 |
+| FESA-PRD-GEN-003 | Source identity, internal index, DOF, equation과 result identity를 구분하고 필요한 대응 관계를 보존해야 한다. | Identity mapping과 재정렬·누락·중복 검사 |
+| FESA-PRD-GEN-004 | 모델 정의, 실행 view, equation 구성과 mutable state의 소유권·수명을 분리해야 한다. | Architecture·lifetime 검토와 관련 테스트 |
+| FESA-PRD-GEN-005 | 요소·재료·하중·제약의 수학적 계약을 검토한 뒤 local 계산과 전역 해석을 연결해야 한다. | 정식화, Numerical Review, local·integration evidence |
+| FESA-PRD-GEN-006 | 해석 절차마다 필요한 state, 해법, 종료 조건, commit과 recovery 의미를 정의해야 한다. | Procedure 계약과 성공·실패 lifecycle 검증 |
+| FESA-PRD-GEN-007 | 결과의 물리량, location, units, coordinates, component, entity와 step/frame 의미를 식별할 수 있어야 한다. | I/O·result schema 계약과 mapping 검증 |
+| FESA-PRD-GEN-008 | 실패한 candidate가 유효한 state나 최종 결과를 부분적으로 오염시키지 않도록 계약된 보존 범위를 지켜야 한다. | State commit·복구·출력 실패 검증 |
+| FESA-PRD-GEN-009 | 외부 형식과 vendor/OS API를 adapter 뒤에 격리하고 solver core에 노출하지 않아야 한다. | Public dependency와 adapter 경계 검토 |
+| FESA-PRD-GEN-010 | Production 동작 변경은 관련 테스트의 기대 실패를 관찰한 뒤 구현하고 지정된 검증 evidence를 남겨야 한다. | RED/GREEN, focused/full 검증 명령과 실제 결과 |
+| FESA-PRD-GEN-011 | 기능에 필요한 독립 검증과 reference 비교를 수행하고 승인된 identity·수치 정책을 유지해야 한다. | 검증 matrix, 사전검사, reference 또는 명시적 N/A와 대체 근거 |
+| FESA-PRD-GEN-012 | 기능 완료는 같은 계약 revision의 필수 evidence와 미해결 항목을 추적하여 판정해야 한다. | 요구사항부터 물리 검토·release readiness까지의 gate 기록 |
 
-## 비기능 요구조건
-- MSVC x64 Debug 환경에서 configure, build, CTest를 검증한다.
-- reference test 결과는 deterministic해야 한다.
-- HDF5 schema는 versioned contract로 관리한다.
-- 모든 외부 reference comparison은 동일 logical quantity와 unit dimension의 component
-  family별 Abaqus-only maximum scale을 사용한다. Near-zero ratio는 `0.01`, 일반 행
-  상대오차는 `0.05`, family scale-relative RMS는 `0.01`이며 독립 absolute-error gate는
-  사용하지 않는다.
-- B33 section resultant는 source element label과 endpoint node label로 직접 대응한다.
-  MITC4 `U1/U2/U3`만 blocking이고 `UR1/UR2/UR3` 초과는 warning-only다.
-- parser, solver, HDF5 writer는 실패 원인을 구조화된 diagnostic으로 보고한다.
-- oneMKL, oneTBB, HDF5는 CMake에서 명시 탐지하고 실패 원인을 분류한다.
-- 대규모 모델 성능 최적화보다 V0의 명확성, 테스트 가능성, 검증 traceability를 우선한다.
+요구사항 단계는 acceptance intent와 필요한 물리적 관찰을 정한다. Numerical Review는
+기존 승인 정책 안에서 논리적 비교량·identity/component·판정 구분을 구체화하고, I/O는 이를
+외부 syntax와 결과 schema에 대응시킨다. 구현 담당자가 누락된 상위 계약을 임의로 정하지 않는다.
 
-## Acceptance Gates
-1. Requirements approved: 기능 범위, 제외 범위, 입력, 출력, tolerance, 검증 물리량이 정의되어 있다.
-2. Research evidence complete: 정식화와 benchmark 근거가 신뢰도와 한계와 함께 정리되어 있다.
-3. Formulation reviewed: 약형, shape function, B matrix, constitutive contract, 수치적분, output recovery가 검토되어 있다.
-4. I/O contract approved: Abaqus keyword subset, internal model mapping, HDF5 result contract,
-   required reference quantity의 최소 source-ID/component matching이 승인되어 있다.
-5. Tests fail before implementation: C++/integration/reference test를 제품 코드보다 먼저 작성하고 같은 Step 안에서 RED 실패와 후속 GREEN 성공을 확인한다.
-6. CMake/CTest pass: MSVC/x64/Debug 기준 configure, build, test가 통과한다.
-7. Reference comparison pass: 기능이 blocking으로 선언한 FESA `<stem>_results.h5` quantity가
-   선언된 Abaqus CSV와 source identity/component별로 대응되고 승인된 tolerance 안에 있다.
-8. Physics sanity pass: equilibrium, reaction consistency, displacement direction, symmetry, section-force consistency와 normalized residual이 검토되어 있다.
-9. Release readiness pass: acceptance traceability, known limitations, release notes draft가 준비되어 있다.
+## 품질 속성
 
-## 제외 사항
-- Abaqus full parser 호환
-- Abaqus B31/Timoshenko beam
-- 다중 analysis step과 step 간 load/BC propagation
-- instance translation/rotation, nested assembly 및 dependent/independent mesh semantics
-- `I12 != 0`, taper, offset, release, curved beam, warping
-- Abaqus `*DLOAD` 입력과 Domain distributed-load object
-- 승인된 fixed-load-factor nonlinear-static 범위를 벗어난 기하·재료비선형, dynamics,
-  contact, thermal effects
-- transverse shear stress와 torsional shear stress recovery
-- beam stress에 대한 Abaqus reference comparison
-- Abaqus, Nastran 또는 reference solver 직접 실행 자동화
-- Agent가 Abaqus reference CSV 파일을 임의 생성 또는 수정하는 작업
-- GUI 또는 postprocessor
-- Visual Studio `.sln`/`.vcxproj` 전용 MSBuild workflow
-- plasticity와 shell end-to-end 구현
+| 속성 | 공통 기준 |
+| --- | --- |
+| Correctness | 실행 성공이나 유한한 결과만으로 판단하지 않고 수학적 계약과 기능별 검증으로 설명한다. |
+| Determinism | 승인된 실행 조건에서 identity, numbering, reduction, 결과와 diagnostic 순서를 재현한다. |
+| Traceability | 요구사항·결정·코드·테스트·artifact·verdict를 Feature ID와 revision으로 연결한다. |
+| Extensibility | 실제 사용 사례에 필요한 최소 경계를 추가하며, 지원하지 않는 physics나 미래 state를 선할당하지 않는다. |
+| Diagnosability | 실패 단계와 관련 source/entity, 원인과 재개에 필요한 정보를 제공한다. |
+| Safety | 미지원 의미는 fail-closed로 처리하고, reference와 관련 없는 사용자 변경을 보존한다. |
+| Maintainability | 사람이 계약과 수식을 대조할 수 있는 단순한 코드와 중복 없는 문서를 유지한다. |
+| Performance | 정확성·재현성을 보존하고 측정된 병목과 승인된 요구를 근거로 최적화한다. |
+
+특정 모델 크기, 성능 목표와 환경별 보장은 해당 요구와 evidence가 있을 때 Feature 계약으로
+정한다. 수치 검증 기준은 적용되는 공통 정책과 승인된 Feature 계약을 따르며 외부 reference
+기준을 기능마다 임의로 정하지 않는다. 이 표는 검증되지 않은 성능이나 모든 platform의
+동등성을 약속하지 않는다.
+
+## 검증과 완료 기준
+
+검증은 서로 다른 오류를 확인하는 계층으로 구성한다. Numerical Review가 Feature에 맞는
+unit, analytical/benchmark, integration, convergence, invariant 및 외부 reference coverage를
+정의한다. 한 계층의 성공이 다른 필수 계층을 대신하지 않는다.
+
+- 외부 reference 비교는 identity와 component를 대응시키고 missing, extra, duplicate,
+  nonfinite 값을 거부한 뒤 [TOLERANCE](TOLERANCE.md)를 적용한다.
+- 물리 평형, 수렴과 정식화 검증의 기준을 외부 reference tolerance와 혼용하지 않는다.
+- Reference artifact는 read-only로 취급하며 구현 결과에 맞추어 생성·보정하지 않는다.
+- 비교가 N/A인 경우 이유와 계약이 요구하는 대체 evidence를 명시한다.
+- 실패·미실행·stale evidence를 통과로 표시하지 않는다. 과거 통과 기록을 현재 검증으로
+  소급 적용하지 않는다.
+
+정규 Feature workflow는 다음과 같다.
+
+`requirements → research → formulation → numerical-review → io-definition →
+implementation-planning → implementation → physics-evaluation → release-readiness`
+
+구현 gate는 TDD, 지정된 전체 build/test와 필수 reference evidence가 갖추어졌을 때
+통과한다. Feature closure에는 그 뒤의 독립 물리 검토와 release-readiness 감사도 필요하다.
+Release readiness는 내부 완료 권고이며 외부 publish, push, tag, deploy 또는 package 권한이 아니다.
+
+Owner, 공통 handoff, outcome, stale 처리와 유한 correction은
+[SOLVER_AGENT_DESIGN](SOLVER_AGENT_DESIGN.md)을 따른다. Skill의 적용 경계는
+[SOLVER_SKILL_DESIGN](SOLVER_SKILL_DESIGN.md), 실행 절차는 각 현재 `SKILL.md`를 따른다.
+문서만 수정하는 작업을 solver Feature 전체 workflow로 확대하지 않는다.
+
+## 단계적 확장과 비목표
+
+새 Feature는 입력 의미부터 결과와 검증까지 연결되는 작은 단위로 정의한다. Kernel,
+parser 또는 dataset 하나가 존재한다는 이유만으로 제품 노출을 선언하지 않는다.
+공통 문서에 구현 항목별 목록이나 진행 상태를 누적하지 않고 해당 Feature 문서에서 관리한다.
+
+다음은 별도 승인 없이 목표로 삼지 않는다.
+
+- 특정 외부 solver의 전체 호환성이나 비공개 알고리즘·내부 상태·결과 생성 절차의 동등성
+- 아직 요구되거나 검증되지 않은 요소·재료·해석 절차·입출력 형식의 지원
+- GUI, 모델러, mesher 또는 범용 전후처리기로의 제품 범위 확대
+- 외부 solver 실행, reference 갱신, 원격 게시 또는 파괴적 작업의 자동 승인
+
+외부 제품의 공개 입력 의미, 출력 정의와 검증 사례는 승인된 범위의 reference로 사용할 수
+있다. 수치 결과의 exact equality는 허용되지만 내부 동작 동등성을 증명하지 않는다.
+
+## 개정 이력의 보존
+
+이 개정은 프로젝트 공통 기준과 구현 항목별 계약의 문서 경계를 정리한다. 기존 기능의
+요구사항을 폐기하거나 수치 acceptance를 변경하지 않는다. 기능별 설명과 기존 ID의 원문은
+[개정 전 PRD](archive/pre-generalization/PRD.md)에 보존하며, 향후 Feature PRD로 이관할 때
+원래 범위·revision·근거를 함께 연결한다. 보존본의 오래된 지원·검증 상태보다 해당 Feature의
+승인된 최신 계약과 evidence를 확인한다.