modify documents

AGENTS.md

@@ -8,7 +8,9 @@
 - git 주소 : https://teagit.mimi1011.synology.me/baram2584/FESADev.git
 
 ## 아키텍처 규칙
-- CRITICAL: 레퍼런스가 되는 예제들과 결과 비교를 통해 솔버의 품질을 항상 유지
+- CRITICAL: 레퍼런스가 되는 예제들과 결과 비교를 통해 솔버의 품질을 항상 유지. 저장 위치는 `references/`이며, 기본 reference artifact는 Abaqus `*.inp` 입력 파일과 `*_displacements.csv` 같은 Abaqus 결과 CSV 파일이다
+- CRITICAL: 모든 새 작업 세션은 먼저 `PROGRESS.md`와 `PLAN.md`를 읽고 현재 진행 상황, 다음 작업, blocker를 파악할 것
+- CRITICAL: 구현 또는 phase 계획 전 `docs/README.md`의 문서 우선순위와 Phase 1 hard invariants를 확인할 것
 - CRITICAL: `docs/ARCHITECTURE.md`와 `docs/ADR.md`의 결정 사항을 우선 준수할 것. 구조 변경이 필요하면 먼저 ADR을 추가/수정할 것
 - CRITICAL: 수치 규약은 `docs/NUMERICAL_CONVENTIONS.md`를 우선 준수할 것. DOF, 좌표계, 단위, 부호, precision, reaction recovery 규약을 임의로 바꾸지 말 것
 - 요소, 재료, 하중, 경계조건, 해석 알고리즘은 런타임 다형성 기반으로 확장할 것
@@ -22,9 +24,34 @@
 - 대규모 모델을 목표로 sparse matrix, assembly, solver 계층은 성능 확장이 가능하게 설계하고, id/index/equation 번호는 int64 기반으로 둘 것
 - MITC4 요소 구현은 Phase 1에서 `docs/MITC4_FORMULATION.md`의 baseline formulation과 reference benchmark 통과를 우선하며, reference 검증 전 과도한 최적화를 하지 말 것
 - Mesh quality 진단은 Phase 1 범위에서 제외하되, singular system 진단은 필수로 구현할 것
+- Abaqus 실행을 로컬/CI 검증 요구사항으로 두지 말 것. 검증은 `references/`에 저장된 `*.inp`와 `*_displacements.csv` 등 reference artifact와 비교할 것
+- Reference input이 Phase 1 parser subset 밖의 Abaqus 기능(`S4R`, `Part/Assembly/Instance`, `NLGEOM=YES` 등)을 포함할 수 있다. 이런 파일은 저장 reference로 보존하되, 지원 범위를 조용히 확장하지 말고 `docs/ABAQUS_INPUT_SUBSET.md`와 `docs/VERIFICATION_PLAN.md`에 compatibility note를 남길 것
+- Phase 1 implementation plan을 만들기 전 `docs/README.md`의 Implementation Readiness Checklist 미결 항목을 명시할 것
+
+## 작업 상태 관리
+- `PLAN.md`는 앞으로 해야 할 일, 우선순위, task ownership, open question의 단일 진실 공급원으로 취급할 것
+- `PROGRESS.md`는 완료된 일, 검증 결과, blocker, 알려진 위험의 단일 진실 공급원으로 취급할 것
+- 작업을 시작할 때 `PROGRESS.md`에서 최근 완료 내역과 blocker를 확인하고, `PLAN.md`에서 현재 objective와 다음 task를 확인할 것
+- 의미 있는 문서/코드/계획 변경을 완료하면 `PROGRESS.md`에 날짜, 변경 파일, 검증, 후속 작업을 기록할 것
+- 앞으로 해야 할 일이 새로 생기거나 우선순위가 바뀌면 `PLAN.md`를 갱신할 것
+- 완료된 task는 `PLAN.md`에 방치하지 말고 `PROGRESS.md`에 완료 기록을 남긴 뒤 `PLAN.md`에서는 제거하거나 상태를 갱신할 것
+- 여러 에이전트가 동시에 작업할 수 있으므로, 파일 수정 전 `PLAN.md`의 owner/scope를 확인하고 서로의 작업 범위를 침범하지 말 것
+- `phases/{phase}/index.json`은 phase 실행 상태의 단일 진실 공급원이지만, phase 밖의 전체 프로젝트 진행 상태는 `PLAN.md`와 `PROGRESS.md`에서 관리할 것
+
+## Harness Engineering
+- FESA의 장기 작업은 기본적으로 Planner -> Generator -> Evaluator 구조로 수행할 것
+- Planner는 구현 전에 sprint contract 또는 `phases/{phase}/stepN.md`를 작성한다. 구현 세부를 과도하게 고정하지 말고, 산출물/검증/금지 범위를 명확히 할 것
+- Generator는 승인된 contract 하나만 구현한다. 여러 layer를 한 번에 묶어 구현하지 말고, 테스트를 먼저 작성한 뒤 contract의 acceptance criteria를 만족시키는 최소 변경을 수행할 것
+- Evaluator는 Generator와 분리된 관점으로 검토한다. 자기 작업을 스스로 승인하지 말고, architecture drift, 수치 규약 위반, reference 비교 누락, 테스트 누락, unsupported Abaqus feature의 조용한 확장을 실패로 판정할 것
+- 각 sprint contract는 최소한 다음 항목을 포함해야 한다: objective, scope, allowed files, explicit non-goals, required reading, tests to write first, reference artifacts, acceptance commands, evaluator checklist, handoff requirements
+- Sprint 시작 전 contract가 testable하지 않으면 구현하지 말고 contract를 먼저 보강할 것
+- Sprint 실패 시 Evaluator는 실패 이유와 재현 방법을 feedback artifact로 남기고, Generator는 그 feedback만을 대상으로 다음 반복을 수행할 것
+- 장기 실행 중 context가 커지면 `PROGRESS.md`, `PLAN.md`, phase step 파일, review feedback을 handoff artifact로 사용해 새 세션이 이어받을 수 있게 할 것
+- Harness 복잡도는 필요한 만큼만 유지한다. 단순 문서 변경은 단일 agent로 처리할 수 있지만, solver 구현/수치 검증/reference 비교가 포함되면 Planner/Generator/Evaluator 분리를 적용할 것
+- Harness contract와 평가 기준은 `docs/HARNESS_ENGINEERING.md`를 따를 것
 
 ## Harness Workflow
-- 먼저 `docs/PRD.md`, `docs/ARCHITECTURE.md`, `docs/ADR.md`, `docs/NUMERICAL_CONVENTIONS.md`, `docs/ABAQUS_INPUT_SUBSET.md`, `docs/VERIFICATION_PLAN.md`, `docs/RESULTS_SCHEMA.md`, `docs/MITC4_FORMULATION.md`를 읽고 기획/설계 의도를 파악할 것
+- 먼저 `PROGRESS.md`, `PLAN.md`, `docs/README.md`, `docs/HARNESS_ENGINEERING.md`, `docs/PRD.md`, `docs/ARCHITECTURE.md`, `docs/ADR.md`, `docs/NUMERICAL_CONVENTIONS.md`, `docs/ABAQUS_INPUT_SUBSET.md`, `docs/VERIFICATION_PLAN.md`, `docs/RESULTS_SCHEMA.md`, `docs/MITC4_FORMULATION.md`를 읽고 기획/설계 의도를 파악할 것
 - 단계별 실행 계획이 필요하면 repo skill `harness-workflow`를 사용해 `phases/` 아래 파일을 설계할 것
 - 변경사항 리뷰가 필요하면 repo skill `harness-review` 또는 Codex의 `/review`를 사용할 것
 - `phases/{phase}/index.json`은 phase 진행 상태의 단일 진실 공급원으로 취급할 것
@@ -38,6 +65,9 @@
 ## 검증
 - 기본 검증 스크립트는 `python scripts/validate_workspace.py`
 - 기준이 되는 Reference 모델들의 해석결과와 비교로 검증 수행
+- Abaqus는 실행하지 않는 전제이다. 사용자가 `references/` 아래에 정리한 입력/결과 artifact를 기준으로 비교할 것
+- Reference displacement CSV는 Abaqus export column `Node Label`, `U-U1`, `U-U2`, `U-U3`, `UR-UR1`, `UR-UR2`, `UR-UR3`를 FESA `U` field의 `UX`, `UY`, `UZ`, `RX`, `RY`, `RZ`와 비교하는 기본 형식으로 취급할 것
+- Reference 비교는 absolute tolerance와 relative tolerance를 함께 사용할 것
 
 ## 명령어
 - `python scripts/execute.py <phase-dir>`: Codex 기반 phase 순차 실행