FESADev/docs/mitc4-shell-feast-eigen/coordination.md

# MITC4 Shell Mass Matrix와 FEAST 고유치해석 coordination

- Feature ID: `mitc4-shell-feast-eigen`
- Owner: `coordinator-agent`
- Contract revision: `r2` (사용자 승인 stabilization 개선·영향받는 정적/eigen 재검증 범위)
- Stage: `implementation`
- Outcome: `pass` (r2 implementation-planning 실행 계약·정적 evidence 확인)
- Next owner: `implementation-agent` (Executor-selected execution-prep Step0)
- Attempt: `0` (r2 구현·수치 실패 관찰 없음; r1 이력 별도 보존)
- Completion: 미완료
- Failure classification: `null`
- Retry key: `null`
- Escalation class: `null`
- Blocker: `null` (실제 execution-prep/main 및 후속 기술 gate는 아직 미완료)

기준: [프로젝트 지침](../../AGENTS.md), [프로젝트 PRD](../PRD.md), [프로젝트 ADR](../ADR.md),
[SOLVER_AGENT_DESIGN](../SOLVER_AGENT_DESIGN.md), [FEATURE_DOCUMENTATION](../FEATURE_DOCUMENTATION.md).
문서 목록은 [FEATURED_AGENTS.md](FEATURED_AGENTS.md), 범위는 [PRD.md](PRD.md), 결정은 [ADR.md](ADR.md)를 따른다.

## Gate evidence

| Gate | Evidence | Coordinator 판정 |
| --- | --- | --- |
| intake | 사용자 요청, 공통 운영 계약 및 관리문서 4개 생성 | pass |
| requirements r0 초안 | [requirements](requirements.md), [관찰·결정 evidence](requirements-evidence.md) | needs-user-decision; 질량 선택 미승인으로 baseline pass 보류 |
| requirements r1 | [requirements](requirements.md), [관찰·결정 evidence](requirements-evidence.md), MFE-ADR-002/004 사용자 명시 결정 | pass; 26개 must와 owner/revision/hash 검증, 미결정 0 |
| research r1 | [research](research.md), [primary-source 상세 근거](research-evidence.md) | pass; primary source 11개 그룹·프로젝트 근거2개, 26개 requirement coverage 및 API 보장 한계 확인 |
| formulation r1 | [기본 수학 계약](formulation.md), [mass](formulation-mass.md), [eigen](formulation-eigen.md), [verification](formulation-verification.md) | pass; owner/revision/상세 수식·26개 coverage·정적 evidence 확인, 독립 수치판정은 NR 소유 |
| numerical-review r1 | [NR verdict](numerical-review.md), [반례·독립 evidence](numerical-review-evidence.md), [reference-model](reference-model.md) | return-upstream; NR-MFE-001, 전체 internal controls 미확정, gate 미통과 |
| requirements r1 intent 재검토 | [Requirement 판단](requirements.md), [MFE-OQ-003 대안·영향](requirements-evidence.md#nr-mfe-001-requirements-intent-검토) | needs-user-decision; 원래 26개 matrix 행 유지, 단순 clarification으로 반례 제외 불가 |
| requirements r2 | [27개 must](requirements.md), [승인 delta·회귀 범위](requirements-evidence.md#r2-승인-범위와-정적-재검증), MFE-ADR-007 | pass; 사용자 승인 반영, owner/revision/27개 ID/43 local links 및 미결정 0 확인 |
| research r2 | [research](research.md), [R07 delta](research-evidence.md#r07--r2-stabilization-근거와-영향) | pass; 27개 coverage/32 local links, 추가 primary S12/S13 및 r1 질량·FEAST·reference 근거 보존 확인 |
| formulation r2 | [main](formulation.md), [mass](formulation-mass.md), [eigen](formulation-eigen.md), [verification](formulation-verification.md), [stabilization](formulation-stabilization.md) | pass; 5개 문서/27개 coverage/57개 상대 경로 및 단일 scale·수학 적용 경계 확인; 독립 판정은 NR 소유 |
| numerical-review r2 | [verdict](numerical-review.md), [독립 evidence](numerical-review-evidence.md), [controls](numerical-review-controls.md), [cases](numerical-review-cases.md), [reference-model](reference-model.md) | pass; NR-MFE-001 수학적 해소, 내부 수치 기준/27개 case/27개 requirement 및 logical reference readiness 모두 확인 |
| io-definition r2 | [main](io.md), [input](io-input.md), [schema](io-schema.md), [mapping](io-mapping.md) | pass; 4개 owner/r2 문서·27개 requirement·66개 상대 링크 및 원본 grammar/identity·additive schema·failure 보존 확인 |
| implementation-planning r2 | [main](implementation-plan.md), [environment](implementation-environment.md), [interfaces](implementation-interfaces.md), [verification](implementation-verification.md), [prep](../../phases/mitc4-shell-feast-eigen-execution-prep/index.json), [main phase](../../phases/mitc4-shell-feast-eigen/index.json) | pass; 실제 read-only StepExecutor validator·16산출물·1+8 steps·owned128회/고유110·요구27/NR27/I/O11·신규test40·links575/anchor0 확인 |

공통 문서 및 reference 파일 목록의 read-only 조사 명령은 exit code `0`으로 완료했다.
확인된 reference 파일은 `shellNL-eigen-meshfine.inp`, `shellNL-eigen-meshfine eigenvalues.txt`이며 실제 의미와 readiness는 담당 owner가 검토한다.
Root의 시작 Git 조사에서 worktree clean을 확인했다. 구현·build/test·외부 reference comparison은 아직 실행하지 않았다.
관리문서 상대 링크 검사 결과는 `4`문서, 끊긴 local link `0`, exit code `0`이며 `git diff --check`도 exit code `0`이다.

## 현재 bounded dispatch

Planning owner의 r2 `pass` envelope와 계획 main/detail 4개 및 phase 제어문서 12개를 감사하여 implementation으로 전이한다. Source 변경·C++/FEAST/reference 성공을 뜻하지 않는다.
초기 14개 main 단위를 결합된 API/data 경계 기준으로 8개로 통합했고 각 step의 behavior별 RED/GREEN·focused/full VERIFY·등록 Stop은 유지한다. 운영 prep 1개는 다섯 deadline default와 관련 Harness tests만 소유하며 physics·schema·sandbox·retry·ownership을 바꾸지 않는다.
Owner는 첫 감사에서 Step2 대응 test owned 누락과 anchor 두 곳을 찾아 index/Markdown·정확한 링크를 수정했다. Actual `StepExecutor` read-only schema/owned validator와 최종 정적 감사는 exit `0`이다. Coordinator도 [V7의 실제 command](implementation-verification.md#v7-계획-정적-감사)를 읽은 뒤 재실행해 같은 결과와 16개 bundle SHA-256 `a28b78ad52a7e9606d026100934fea3ff324218be4210aa772e89cbaae42b413`를 확인했다.
결과는 prep1/main8, owned paths128회/고유110, Step별 upstream22 필수입력, 요구27/NR27/I/O11, 신규 필수 test40, local links575/anchor warning0, 기존 top index5개 entry/history 보존, `git diff --check` exit `0`이다. `fesa_tests` aggregate가 unit/integration/reference targets 모두를 의존한다는 실제 graph와 각 필수 새 test의 discovery 확인도 계획에 명시되어 있다.
Root의 최초 `git diff --cached --check`는 새 plan/verification/prep index의 EOF blank 3개를 검출해 exit `1`이었다. Planning owner가 해당 3개만 수정하고 V7에 unstaged diff의 신규파일 검사 한계 및 EOF 검사를 보완했다. Coordinator의 V7 재실행은 전체 EOF 검사·동일 coverage·위 갱신 hash를 확인하며 exit `0`이다. Phase JSON 의미·metadata·계약은 변하지 않았고 구현 correction/revision 변경으로 취급하지 않는다. Root의 재staging/checkpoint 완료 전 실행하지 않는다.
실행 dispatch는 `feature_id=mitc4-shell-feast-eigen`, `stage=implementation`, `outcome=pass`(Planning gate), `next_owner=implementation-agent`, `contract_revision=r2`, `attempt=0`, failure/retry/escalation/blocker=`null`을 적용한다. 필수 evidence inputs는 Feature 폴더/관리3개·승인 upstream22개·Planning4개 및 assigned prep index/step0이며 정확한 경로는 [prep Step0](../../phases/mitc4-shell-feast-eigen-execution-prep/step0.md)에 포함된다.
Root의 정확 경로 checkpoint와 clean/active process/sandbox preflight 후 [E3의 one-time module invocation](implementation-environment.md#e3-one-time-bootstrap와-새-process-activation)으로 execution-prep Step0를 할당한다. Implementation은 그 Step의 exact code/tests/evidence paths와 terminal result만 소유하고 Executor가 branch/attempt/commit/phase 진행을 소유한다. 이 invocation 동안 Root/Coordinator는 관리문서를 포함한 non-owned 편집·커밋을 동결한다.
종료 뒤 actual manual evidence·raw Executor result·등록 Stop/actual exit·정확 source/control commits/clean을 감사한 다음에만 새 main invocation을 할당한다. 실패 시 상태/로그를 보존하고 실제 분류로 반환하며 pending reset/즉시 재실행을 하지 않는다. 실제 구현/전체 검증/reference 및 physics/release gate는 아직 미완료다.

### Implementation Planning r2 이력

I/O owner의 r2 `pass` envelope와 실제 기본 1개/상세 3개 문서를 감사하여 implementation-planning으로 전이한다.
Constant density와 frequency options/data의 exact subset, 공식 공개 syntax 근거와 source warning, 별도 eigen procedure, 기존 static을 보존하는 additive schema 및 candidate/state 보존을 확인했다. Source Step-2/canonical Step-1과 공개 N/all-c 검증을 분리하고 raw lambda·frequency validity·실제 lumped mass/backend를 보존한다.
Owner의 `python -B -` 정적 audit은 owned 4개 metadata, relative links 66개/anchors 13개, requirement 27행, 원본 N10/data fields6 및 TXT full grammar 10행/hash 일치, exit `0`이었다. Owned paths의 `git diff --check`와 별도 untracked whitespace/table 검사도 exit `0`이다. 잘못된 초기 directory/glob 검색과 해소는 owner evidence에 기록되어 있다.
Coordinator는 전체 22문서의 local-link 누락 0, I/O 4개 owner/r2 metadata·반환 SHA-256 일치 및 coverage 27행을 확인했다(`python -B -`, exit `0`). External Value-only/10 singleton/common tolerance 및 기존 static U/UR·reaction 역할은 유지한다.
Planning은 모든 승인 문서와 27개 NR cases/11개 I/O obligations를 실행 가능한 정확한 owned paths, RED/GREEN/focused/full VERIFY와 fresh reference evidence에 연결한다. 실제 MSVC/x64/Debug backend, dependency cache, Executor/Stop의 1800초 경계 및 Git·sandbox·retry 소유권은 아래 준비 evidence와 현재 Harness 구현을 대조한다. 아직 C++/FEAST/eigen reference 비교는 미실행이다.
Root는 I/O r2 exact 8개 경로 checkpoint를 `1d4f5ac` (`docs: define MITC4 eigen input and result contracts`)로 커밋했고 staged path set/diff/commit exit `0`, 이후 clean을 확인했다.
Planning owner에게 `implementation-plan.md`와 필요한 같은 폴더 상세, `phases/index.json`의 신규 entry 및 `phases/mitc4-shell-feast-eigen/`의 index/연속 step 문서를 할당했다. 운영 준비를 별도 invocation으로 완료해야 한다고 판단하는 경우에만 `phases/mitc4-shell-feast-eigen-execution-prep/`의 index/step과 entry도 할당했다. 기존 phase 이력과 모든 runtime/source/test/config는 read-only이며 실행은 아직 할당하지 않았다.
이미 로드된 Executor는 자기 source 수정 후에도 최초 timeout 값을 유지할 수 있으므로 계획에서 새 process activation 경계를 명시해야 한다. 이 관찰은 timeout·sandbox·Hook 정책의 임의 우회 승인이 아니다.

### I/O r2 이력

NR owner의 r2 `pass` envelope와 실제 5개 기본/상세 문서를 감사하여 io-definition으로 전이한다.
NR-MFE-001의 r1 실패를 보존하고 독립 직접 적분의 r2 complete K/질량/고유치/정적 response·reaction covariance 결과로 수학 계약의 해소를 확인했다. 문서에서 추출한 `python -B -` 재현도 exit `0`이다.
V1~V6의 단위·zero branch·analytic rank/conditioning·원 residual/Gram·FEAST controls/seed/QR/thread/정수·memory/budget과 27개 필수 case/요구 mapping이 고정되었다. MFE-C13의 BC 조합은 실제 global component BC로 표현 가능한 경우만 적용함을 owner가 명시했다.
Owner 정적 audit은 5문서/64 local links/27개 요구/27개 cases/8개 기존 static artifacts, exit `0`; `git diff --check` exit `0`이다. 최초 audit의 encoding/URL-decoding 오류와 수정 후 재확인은 전문 evidence에 보존했다.
Coordinator는 18문서의 local-link 누락 0, NR 5개 문서 owner/r2 metadata·반환 hash, 27개 case/27개 requirement mapping 행을 확인했다(`python -B -`, exit `0`). 원본 input/TXT hash와 외부 Value-only/10 singleton/common policy는 유지한다.
I/O owner는 승인된 입력 subset·부수 옵션·density mapping, 별도 eigen procedure state와 additive HDF5/source/modal identity·failure preservation·deterministic 비교 projection을 고정한다. 수식/수치 기준을 다시 선택하지 않으며 실제 C++/FEAST/fresh reference 비교는 Implementation의 후속 필수 작업이다.
Root는 NR r2 exact 9개 경로 checkpoint를 `ea883ad` (`docs: complete MITC4 eigen numerical review`)로 커밋했고 staged path set/diff/commit exit `0`, 이후 clean을 확인했다.

### Numerical-review r2 이력

Formulation owner의 r2 `pass` envelope와 실제 5개 문서의 변경·상세 수식/단위/ordering/실패/검증 경계를 감사하여 numerical-review로 전이한다.
Owner가 `k_ref=sum_i trace(R_i)/8`, `k_d=10^-3 k_ref`를 확정했고 S1~S8에 positivity, complete K 공변성, partial BC, physical rigid/null 및 nonlinear 초기 고정 potential/Hessian의 적용 경계를 명시했다.
Exact arithmetic `python -B -`는 exit `0`, `kd=19/4800`, `lambda=10369/450`, 단위 tangent moment 응답 `7500/10369`이며 formulation 식의 산술 확인이다. NR의 독립 반례 해소나 runtime 결과로 취급하지 않는다.
Owner 정적 검사는 5문서/57개 상대 경로/27개 coverage/issues 0, exit `0`; `git diff --check` exit `0`이다. Coordinator는 16문서 local-link 누락 0, 5개 owner/r2 metadata와 반환 SHA-256 일치를 확인했다(`python -B -`, exit `0`).
NR는 r1의 비충돌 mass oracle/API/reference 근거를 보존하고 새 stabilization을 독립 재검토한다. 이어 미완료 V1~V6 내부 threshold·conditioning·FEAST controls/endpoint/count/solve budget·seed 및 27개 요구의 필수 case matrix를 모두 고정해야 한다. 논리 reference readiness도 r2로 확인한 뒤에만 I/O로 전이할 수 있다.
Root는 formulation r2의 exact 9개 경로를 `4d30383` (`docs: define covariant MITC4 stabilization formulation`)로 커밋했고 staged diff/commit exit `0`, 이후 clean을 확인했다.
NR owner의 중간 독립 계산은 기존 R block을 입력하지 않고 평판 membrane/curvature/MITC shear work를 직접 적분해 complete `24×24 K`를 구성했다. 회전 전후 `lambda=23.04222222222223`, `thetaZ=0.7233098659465717`이 같고 K/M/response/reaction covariance 오차는 각각 `7.90e-17`/`4.66e-17`/`0`/`1.15e-16`이었다(`python -B -`, exit `0`). 최종 보고서/controls/coverage 반환 후 gate를 감사하며 C++/FEAST runtime evidence와 구분한다.

### Formulation r2 이력

Research owner의 r2 `pass` envelope, 두 owned 문서와 추가 R07 상세 근거를 감사하여 formulation으로 전이한다.
Trace/spectral scale 후보, 초기 고정 nonlinear potential의 미분 구조 및 linear `Kzz>0`/`Kpz=0` 전제를 구분했고 특정 수식이나 수치 반례 해소를 연구 gate로 승인하지 않았다.
Owner의 Python 정적 검사는 2문서/32 local links/27개 coverage/issues 0, exit `0`; 기존 S01~S11/R01/R02/R04/R05 보존 비교와 `git diff --check`도 exit `0`이다.
Coordinator는 15문서 local-link 누락 0, owner/r2 metadata·반환 hash 일치를 확인했다(`python -B -`, exit `0`).
`research.md` SHA-256은 `8b552b35342a1e0c81ee8c4effd03f240ea88c7553a5e3eee523b1c0f3cf55f6`, `research-evidence.md`는 `b1825090886ca71510d33c335fc0048f61a53f5f58441fc3d36fffe0e894c492`이다.
Formulation owner는 승인된 범위 안에서 하나의 공변 scale을 정하고 positivity·완전 K 변환·partial BC·initial-fixed nonlinear 계약 및 finite/null 처리 증명을 최소 delta로 갱신한다. 아직 외부 수치 comparison·새 구현·r2 NR gate는 미실행이다.
Root는 research r2 checkpoint 6개 exact paths를 `b99a5e5` (`docs: record covariant MITC4 stabilization research`)로 커밋하고 diff/commit exit `0`, clean을 확인했다.

### Research r2 이력

Requirement owner의 r2 `pass` envelope와 두 owned 문서 delta를 감사하여 research로 전이한다.
기존 26개 ID를 보존하고 `002/008/014/020/024`를 승인 범위에 정합시켰으며 `027`을 추가했다. 기존 fixed scale의 대체 경계와 linear/nonlinear 정적 회귀 portfolio·identity·정책을 연결했고 물리 kernel·source/schema·공통 tolerance는 변경하지 않았다.
Owner의 `Get-Content`/`rg`와 Python audit은 exit `0`, 27개 요구/43 local links/깨진 링크 0이다. Coordinator audit은 15문서/깨진 링크 0/27 unique IDs, exit `0`이다.
`requirements.md` SHA-256은 `bcc17774190cc19b28595b3d0151c0202f4470a14aa90947c5cba6188c9ef909`, `requirements-evidence.md`는 `452ea5ed49b43ffaea3f6065fecf62003ea74f0e6bb3eae7812b9af8e7b8d514`이다.
Research owner는 r1 근거를 보존하며 승인된 stabilization 공변성, 기존 static scale lifecycle과 finite-null 처리에 필요한 근거만 최소 delta로 보완한다. 수식·threshold·NR 판정은 후속 owner 소유이며 실제 구현·수치 재검증은 미실행이다.
Root는 r2 requirements checkpoint 6개 exact paths를 `adef07e` (`docs: baseline covariant MITC4 stabilization requirements`)로 커밋하고 `git diff --check`/commit/status exit `0`, worktree clean을 확인했다.

### Requirements r2 갱신 이력

사용자가 “네 개선과 영향받는 기존 정적해석과 고유치해석의 재검증까지 범위에 포함해주세요.”라고 답하여 [MFE-ADR-007](ADR.md#mfe-adr-007--기존-stabilization과-좌표-불변성-acceptance-정합)의 개선안을 명시적으로 승인했다.
Coordinator는 승인된 scope 변경에 따라 `r2`로 전이하고 Requirement owner에게 필요한 요구·검증 matrix와 기존 fixed `kd` 계약의 대체 범위를 최소 delta로 갱신하도록 할당한다.
기존 질량 흐름·입력 N·reference Value-only·공통 tolerance는 유지한다. r1 NR 반례는 개선 후 필수 회귀 evidence로 연결하며 사용자 승인 자체를 NR gate 통과로 해석하지 않는다.
이후 Research, Formulation, NR의 영향받는 evidence를 순서대로 owner 검토하고 5~9단계로 진행한다. 새 r2 실패는 아직 없고 r1 retry signature의 correction 사용은 0회다.
Root는 앞선 결정 요청 6개 exact paths를 `78d2943` (`docs: record MITC4 stabilization decision request`)로 커밋했고 재개 시 clean 및 기존 VS18/x64 dependency cache를 확인했다.
Root가 이전 자동 Stop으로 보이는 실행 중 CTest를 read-only 추적하고 있다. 수동 중복 build/test/Hook를 실행하지 않으며 최종 결과가 확인되면 환경 evidence로 별도 기록한다.
Requirement owner의 중간 검토는 기존 physical kernel/director/mapping을 유지하면서 numerical stabilization 개선을 분리하고, 개선된 constrained pencil의 spectrum 보존 및 NR 부분 BC 반례의 blocking 좌표 검증을 명시하는 방향이다. 보고서 반환 전 r2 requirements gate를 통과로 처리하지 않는다.

### Requirements 사용자 결정 대기 이력

Requirement owner의 두 owned 보고서와 `needs-user-decision` envelope를 감사했다.
원래 r1의 지원 partial BC 반례를 acceptance에서 제외하는 것은 실제 변경이며, 기존 stabilization 개선 또한 scope/physics 변경이라는 판단과 두 대안·권고를 [MFE-ADR-007](ADR.md#mfe-adr-007--기존-stabilization과-좌표-불변성-acceptance-정합)에 기록했다.
질량·FEAST·입력 N의 승인 선택은 유지하고 Root에 한 건의 결정 묶음을 전달했다. 사용자 응답 전 계약 변경·다음 stage 통과는 보류한다.
Requirement owner의 `Get-Content`/`rg` 및 Python 정적 검사는 exit `0`, matrix 26행은 기존 HEAD와 동일하고 링크 누락이 없다. 수식 유도·수치 재실행·source 변경은 하지 않았다.
당시 SHA-256은 `requirements.md`: `ae08d2c7a52cce5261e3420618e5b84b3f25c20258d0992b1b6941511baa7d09`,
`requirements-evidence.md`: `528bdf8a948a964f269cc100c2072d68e65ebaff333b9246b1f718a2052d408e`이다.
Coordinator의 `python -B -` 정적 audit은 15문서/끊긴 local link 0, matrix 26행과 HEAD 동일, exit `0`이다. 최초 audit helper는 ID의 backtick을 잘못 가정하여 0행/exit `1`을 반환했고 실제 문서 형식에 맞춘 패턴으로 수정해 재확인했다. 문서나 계약을 변경하여 검사에 맞추지 않았다.
`git diff --check`는 exit `0`; 변경 경로는 관리 4문서와 Requirement owner 2문서뿐이다.
Root는 NR finding 7개 exact paths checkpoint를 `c8876da` (`docs: record MITC4 numerical review contract finding`)로 커밋하고 clean을 확인했다.

### Requirements return-upstream 이력

NR owner의 실제 보고서 3개와 `return-upstream` envelope를 확인하여 정확한 Requirement owner로 반환한다.
같은 지원 partial BC를 보존한 45도 회전의 직접 계산에서 `lambda=23.04088888888889 -> 23.040628726287263`,
상대차 `1.1291343961675893e-5`가 재현되었다(`python -B -`, exit `0`). 기존 `kd` 규칙과 REQ-014의 acceptance intent 사이의 발견이다.
NR의 independent rational mass oracle, Intel API/count/trace 검토와 reference 원본/10-mode logical readiness evidence는 보존한다.
Owner 정적 검사는 3문서/35 local links/issues0, exit `0`; 수치 reference comparison·FEAST runtime·구현은 미실행이다.
`014`에 영향을 받는 research R06 coverage와 formulation V5/coverage를 부분 stale로 표시하고, 나머지 수학·reference evidence는 향후 revision 영향 검토 후 재사용한다.
Requirement owner는 기존 literal intent의 기술적 정합 가능성과 실제 critical acceptance/physics 선택을 구분한다. 새로운 사용자 결정을 이미 필요하거나 승인된 것으로 표시하지 않는다.
이번 건은 upstream 계약 문제이며 Implementation/Correction Agent로 보내지 않는다. Correction 및 transport 재시도 budget은 사용하지 않았다.

### Numerical-review 이력

Formulation owner의 r1 `pass` envelope와 실제 기본/상세 문서 4개를 감사하여 numerical-review로 전이한다.
Owner 정적 검사는 `4`문서, `38` local links, requirement coverage `26`, issues `0`, `python -B -` exit `0` 및 `git diff --check` exit `0`이다.
Coordinator는 모든 상세 문서의 metadata·수식/단위/identity/오류/검증/한계 절과 링크를 읽고 필수 항목 존재를 확인했으며 수학적 correctness verdict를 대신하지 않았다.
NR는 수학 correctness와 reference-model readiness를 모두 검토하고 명시된 metric/zero branch의 수치값, FEAST controls·bounded budgets 및 필수 verification portfolio를 고정한다.
Root의 두 독립 감사 포인트를 필수 handoff로 포함한다: count 기능의 실제 API 보장보다 강한 completeness를 주장하지 않을 것;
기존 basis-dependent drilling stabilization과 `FEM-REQ-MITC4-EIGEN-014`의 coordinate-invariance coverage 관계를 명시하여 acceptance의 조용한 축소를 막을 것.
현재 새 사용자 미결정이나 implementation correction은 없다.
Formulation checkpoint는 Root가 `2c3a86a` (`docs: define MITC4 mass and FEAST formulation`)로 8개 exact paths를 커밋했고 이후 clean을 확인했다.

### Formulation 이력

Research owner의 r1 `pass` 반환을 Coordinator가 감사하여 formulation으로 전이한다.
연구 기본/상세 문서의 owner, r1, source locators, Fact/Derivation/Candidate 구분, 실제 명령 exit code 및 미실행 항목을 확인했다.
연구 문서 SHA-256: `research.md` = `c044031f844798f32bedc95fd998c181f965fbac00c3ed8f594a48d0164b8956`,
`research-evidence.md` = `aa7cf3be8c3858a9358ca2bd3d117ca0e85a6a0d42c1b439bd812f4ee3d3120f`.
Coordinator local-link audit은 Feature 8문서/끊긴 링크0, exit code `0`; `git diff --check`도 exit code `0`이다.
설치 header와 공식 count 기능 존재는 runtime 또는 완전성의 자동 통과 증거가 아니다. 실제 API의 수치적 한계, endpoint/count 실패, 독립 작은 spectrum 검증이 연구 보고서에 기록되었다.
Formulation owner는 approved MITC4 geometry에 대한 consistent 적분, derived block lumping·물리 관성·massless drilling/constraints,
FEAST의 낮은 N개 계산·복원·실패 보존 및 modal evidence 식을 구현 가능한 계약으로 작성한다. 최종 numerical/reference acceptance는 다음 NR가 독립 검토한다.
Research checkpoint는 Root가 `a7c13ff` (`docs: record MITC4 mass and FEAST research evidence`)로 완료 문서 6개를 커밋했고 이후 clean을 확인했다.
Formulation owner의 중간 관찰은 기존 `Tphys/Tdrill`과 양의 nodal drilling 강성에 기반한 `Kpz=0` 증명,
곡면의 `C1` coupling을 유지하는 derived block lumping과 `3×3×3` mass 적분 차수 검토이다.
이는 작성 중인 정식화의 owner 관찰이며 formulation 또는 numerical gate 통과를 뜻하지 않는다.

### Research 및 baseline 이력

Requirement owner의 최종 r1 `pass` 반환을 Coordinator가 감사하여 requirements gate를 통과시키고 research로 전이한다.
당시 SHA-256은 `requirements.md`: `1ebe65f231e49ffc15a9a1985dcdbbb7e6fc47b9e1ddb5a76f2c2489e5982690`,
`requirements-evidence.md`: `2241ef8dacc7e07d40c731667e202bd9c104ae43b1a5f6eab4530a6831fea918`이다.
Coordinator 정적 audit은 Feature 6문서, 끊긴 local link 0, must rows/unique IDs `26/26`, exit code `0`; `git diff --check` exit code `0`이다.
Research owner는 승인된 consistent→lumped→FEAST, 물리 관성·massless drilling·제약·최저 모드 완전성 및 독립 verification의 primary-source evidence를 수집한다.
연구 계약은 다음 stage의 수식을 대신 승인하지 않는다. Reference 비교량, tolerance 및 사용자 mass 선택은 변경하지 않는다.
요구조건 checkpoint는 Root가 `29d88b4` (`docs: baseline MITC4 lumped-mass FEAST requirements`)로 6개 exact paths를 커밋했고 이후 clean을 확인했다.
사용자가 “inp 파일의 고유치 개수를 사용합니다”라고 확인했다. 기존 r1의 `FEM-REQ-MITC4-EIGEN-009/015`와 일치하므로 [MFE-ADR-005](ADR.md#mfe-adr-005--요청-고유치-개수의-입력-권위)에 설명을 기록하고 r1을 유지한다.
Research와 후속 Formulation/NR은 FEAST interval count 기능의 exact guarantee와 stochastic estimate를 구분하고 공식 API가 보장하는 범위를 넘는 completeness 주장을 하지 않는다.

### Requirements 이력

2026-09-06 사용자 후속 답변을 수신했다. Consistent mass를 계산하고 이를 이용한 lumped mass도 계산한다는 요구로 [MFE-ADR-002](ADR.md#mfe-adr-002--mitc4-질량-이산화)를 갱신했다.
`r1` 입력을 Requirement owner에게 반환하여 양자택일 초안과 matrix를 수정하고 actual FEAST mass/lumping 의미의 중요 미결정 여부를 확인한다.
Requirement owner는 두 mass의 계산 관계만으로 FEAST의 실제 `M`이 유일하게 결정되지 않는다고 판단했다.
[MFE-ADR-004](ADR.md#mfe-adr-004--feast에-사용하는-질량행렬)에 derived lumped 사용 권고와 consistent 사용 대안, spectrum·residual 영향 및 질문을 기록하고 Root에 전달했다.
Detailed lumping 수식은 Research/Formulation이 담당하며 현재 질문은 FEAST 사용 질량 한 건이다.
같은 날 사용자 명시 답변으로 `consistent mass -> lumped mass -> 고유치 해석` 순서와 FEAST의 lumped mass 사용이 확정되었다.
`MFE-OQ-001`과 `MFE-OQ-002`는 해소되었으며 Requirement owner에게 r1 baseline 확정과 pass 검토 요청을 전달했다.
FEAST 및 내부 modal residual/normalization/orthogonality는 사용된 lumped `M`을 기준으로 한다. 같은 선택에 대한 재질문은 하지 않는다.
아래 r0 기록은 이력이며 현재 승인을 뜻하지 않는다. r0 requirements 결정 항목은 stale이고 후속 stage 산출물은 아직 없다.

Requirement Agent는 r0 입력에서 요구사항과 검증 matrix, reference 관찰 사실 및 중요한 미결정 사항을 작성한다.
질량 정식화나 reference 해석 의미를 승인으로 추정하지 않으며 질문이 필요하면 선택지·영향·권고를 하나로 묶어 Coordinator에게 반환한다.
일반 문서·계획·local 실행은 사용자 요청으로 승인되었으며 반복적인 stage 승인을 추가하지 않는다.

Requirement owner의 중간 조사에서 단일 `Step-2`의 `nlgeom=NO, perturbation`, `*Frequency` 요청 `10`모드,
선행 정적 step·하중·preload 없음이 확인되었다. 이 관찰은 무하중 원형상 procedure 의미를 뒷받침하며 최종 requirements 보고서에서 추적한다.
`Value`와 `Freq(cycles/time)`가 별도로 있는 원본 txt는 Mode `1..10`을 포함한다. 수치 비교는 아직 수행하지 않았다.

Requirement owner는 `consistent mass`와 `nodal lumped mass`가 유한 mesh의 고유치·운동에너지 의미를 달리하는 critical 선택임을 반환했다.
[MFE-ADR-002](ADR.md#mfe-adr-002--mitc4-질량-이산화)의 권고/대안/영향을 Root에 전달하여 사용자에게 하나의 질문으로 요청한다.
Requirements 기본·상세 보고서 2개의 owner `requirement-agent`, input revision `r0`를 확인했다.
Coordinator 정적 audit: 전체 Feature `6`문서, 끊긴 local link `0`, must matrix `25`행 및 고유 ID `25`, exit code `0`.
원본 reference 2개 SHA-256이 specialist 기록과 일치했다. Requirements 초안은 질량 선택 대기를 명시하며 연구 이후 gate의 빈 보고서는 없다.
기본 보고서 SHA-256: `8d5fbcb8ba2c2bd25d736418450b1b69e7aba7a84c8370d6e2a89e4e259daa66`.
상세 보고서 SHA-256: `85ee91dd745f74cc65ef8e660227465a8fa5ad302e639a51464d0ba31f449d22`.
결정에 의존하는 baseline pass 및 다음 stage는 보류한다. 응답 수신 뒤 Requirement owner가 승인 선택을 반영하고 Coordinator가 revision과 gate를 다시 감사한다.

## 후속 실행 준비 관찰

후속 사용자 지정 `FESA_GTEST_SOURCE_DIR=C:\git\googletest`에 대해 Root가 `CMakeLists.txt` 존재를 확인했다.
Root는 다른 dependency·Harness 환경을 별도로 조사하며 완료 문서 checkpoint와 사용자 수정 `AGENTS.md` 커밋을 담당한다.
실제 implementation 실행 전 환경 준비와 configure/build/test 성공이 필요하며 아래 과거 Stop failure를 소급 변경하지 않는다.
사용자 수정 `AGENTS.md`의 경로 예시 한 줄은 Root가 `fab168b` (`docs: document local GoogleTest source path`)로 커밋했다.
Root read-only 환경 조사에서 다음 설치 경로를 확인했다. 이 목록은 설치 존재 evidence이며 configure/build/test 성공은 아니다.

| 항목 | 확인 경로 |
| --- | --- |
| GoogleTest | `C:/git/googletest` |
| MKL CMake config | `C:/Program Files (x86)/Intel/oneAPI/mkl/2026.1/lib/cmake/mkl` |
| TBB CMake config | `C:/Program Files (x86)/Intel/oneAPI/tbb/2023.1/lib/cmake/tbb` |
| HDF5 CMake config | `C:/Program Files/HDF_Group/HDF5/2.1.1/cmake` |
| Ninja executable | `C:/Program Files/Microsoft Visual Studio/18/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe` |

VS `18/Community` DevShell script/dll이 존재하며 Ninja는 현재 PATH에 없다. Planning/Executor는 각 실행 subprocess의 MSVC x64 Developer 환경과 dependency 환경을 명시해야 한다.
Root는 global environment, Hook state/code를 변경하지 않았다.
후속 Root read-only `Get-Command`에서 `python`, `uv`, `cmake`, `ctest`, `codex`가 해석되었다. Codex launcher는 `C:/Users/baram/AppData/Local/Programs/OpenAI/Codex/bin/codex.exe`다. Launcher 실행·로그인·설정 변경은 없었고 tool availability는 Harness transport 성공 evidence가 아니다.
추가 Root read-only 확인: Python `3.11.15`, oneMKL `mkl_rt.lib`/`bin/mkl_rt.3.dll` 및 FEAST 선언이 존재한다.
현재 작업 경로는 primary `C:/git/FESADev`의 linked worktree이며 branch는 `Eigen`이다.
Implementation profile은 `gpt-5.6-terra` / `xhigh` / `workspace-write`이고 당시 configure/link/runtime는 미실행이었다.
Root가 읽은 현재 config schema는 dependency environment/cacheVariables를 직접 받지 않으며, root preset은 dependency `$env{...}` 값을 cacheVariables로 지정한다.
개별 subprocess environment가 부모 Stop process에 전파된다고 가정하지 않는다. Planning은 실제 Hook backend/환경과 CMake cache·preset을 함께 대조한다.
AGENTS의 Ninja preset은 예시이며 필수 검증은 MSVC/x64/Debug CMake/CTest다. 자동 감지의 VS18 cache 재사용도 현재 환경에서 가능한지 평가할 수 있으나,
과거 native sandbox의 FileTracker 한계와 현재 runner 정책까지 확인해야 한다. 당시 backend 선택·config 변경·실행은 하지 않았으며 이후 Root의 configure 환경 교정은 아래에 구분해 기록한다.

현재 `.harness/config.json`은 없고 preset과 `.harness/config.example.json`은 있다.
Planning은 자동 감지 결과와 승인 MSVC preset을 대조하여 실행명령 및 Hook backend를 명시해야 한다.
`scripts/execute.py`의 preflight는 selected phase 제어 파일 외의 dirty 경로를 거부한다.
따라서 구현 실행 전에 Feature 문서 baseline과 Executor의 path-scoped Git 처리 경계를 Planning에서 구체화한다.
이 관찰은 환경 실패 판정이나 별도 사용자 승인 요청이 아니다.

Root가 전달한 자동 Stop hook configure 실패는 별도의 실제 환경 evidence로 보존한다.
실행 명령은 `C:/Program Files/CMake/bin/cmake.exe -S C:/Users/baram/orca/workspaces/FESADev/Eigen -B C:/Users/baram/orca/workspaces/FESADev/Eigen/.harness/build -A x64`, exit code `1`이며
`cmake/FesaDependencies.cmake:9`에서 `FESA_GTEST_SOURCE_DIR` 미설정을 보고했다.
Root의 read-only 원인 조사에서 현재 process의 `FESA_GTEST_SOURCE_DIR`, `MKL_DIR`, `TBB_DIR`, `HDF5_DIR`가 모두 미설정이고,
자동 감지는 `Visual Studio 18` generator를 사용하며 local config가 없어 승인 Ninja/MSVC preset과 맞지 않음이 확인되었다.
당시 수동 Hook·CMake·CTest 재실행, config 변경 또는 Hook state 조작은 하지 않았다.
당시 requirements gate의 critical 질량 선택과 별개로 Implementation Planning에서 dependency 경로·설정된 backend를 준비하고 검증하도록 보존한 기록이다.
이 실패를 build/test 통과로 보고하거나 현 단계의 미실행 검증을 대체하는 증거로 사용하지 않는다.

### Root의 configure 환경 교정 확인

2026-09-06 Root는 사용자 지정 GoogleTest와 확인된 dependency 경로로 기존 자동 감지 backend의 cache를 구성하고 이전 실패 명령을 재확인했다.

```powershell
cmake -S . -B .harness/build -A x64 "-DFESA_GTEST_SOURCE_DIR=C:/git/googletest" "-DMKL_DIR=C:/Program Files (x86)/Intel/oneAPI/mkl/2026.1/lib/cmake/mkl" "-DTBB_DIR=C:/Program Files (x86)/Intel/oneAPI/tbb/2023.1/lib/cmake/tbb" "-DHDF5_DIR=C:/Program Files/HDF_Group/HDF5/2.1.1/cmake"
cmake -S C:/Users/baram/orca/workspaces/FESADev/Eigen -B C:/Users/baram/orca/workspaces/FESADev/Eigen/.harness/build -A x64
```

각 명령 exit `0`이며 실행 시간은 약 5초와 1.5초였다. `CMakeCache.txt`의 dependency 경로 4개 및 `Visual Studio 18 2026`/x64를 확인했고 MKL `2026.1`, dynamic/`intel_ilp64`/`intel_thread`가 선택되었다.
Cache는 Git ignored이며 source·설정·Hook code/state를 변경하지 않았다. 수동 Hook·build·CTest·FEAST 실행은 없었다.
이전 configure 원인은 해소되었지만 build/link/test 또는 feature TDD gate 통과 evidence는 아니다. Planning은 실제 backend와 cache를 대조하고 Debug를 build `--config Debug` 및 CTest `-C Debug`로 명시해야 한다.

### 자동 Stop baseline 중단 관찰

Root가 기존 CTest PID `21104`의 `--test-dir .harness/build -C Debug --output-on-failure` 실행을 read-only로 관찰했다.
362개 중 test 355 `ShellSurfacePressureReference.SelectsUniqueSchemaOneFactorOneAcceptedFrame`는 약 193.43초 뒤 `Test Failed`를 기록했고, test 356 `Projects729WideRowsTo2187LogicalRowsPerFamily`는 보고 시점에 진행 중이었다.
원시 출력은 `.harness/build/Testing/Temporary/LastTest.log.tmpe803a`에 있다. 실패 출력은 RUN 이후 종료되어 원인을 아직 단정하지 않는다. 최종 CTest exit code도 아직 없다.
이 관찰은 신규 source 변경 없는 baseline 실행이며 feature correction budget을 사용하지 않는다. Root가 최종 결과·환경 원인을 추적하고 Planning/Implementation 전에 분류할 evidence로 전달한다.
일부 앞선 nonlinear reference test가 약 460초 뒤 통과한 사실은 전체 suite 통과를 뜻하지 않는다. 수동 중복 test·Hook 또는 source 수정은 수행하지 않았다.
Root의 후속 관찰에서 CTest와 parent/test process는 종료되었다. Observer shell은 exit `0`이지만 관찰한 `ctest.ExitCode`는 빈 값이어서 CTest 실제 종료 코드는 확인하지 못했다.
Raw log 집계는 `354 Test Passed`, `1 Test Failed`, 요청 362개 중 완료 기록 355개로 suite가 미완료다. 첫 실패의 solver log는 target 0.3 iteration 2 continue에서, 후속 test는 target 0.5 iteration 3 accepted에서 끝났고 후속 test의 완결 HDF5는 없다.
이 evidence만으로 코드 결함, timeout 또는 turn interruption 중 원인을 선택하지 않는다. 관련 Windows ApplicationError 기록도 확인되지 않았다.
Root가 원시 CTest 기록을 Git ignored `.harness/build/baseline-before-mitc4-eigen/`에 복사 보존했다. `LastTest.log.tmpe803a` 크기는 `592656` bytes이며 현재 활성 build/test process는 없다.
Planning/Implementation은 이 중단 baseline과 구분되는 실제 전체 suite exit code 및 완전한 결과를 확보해야 한다. 관찰 shell의 성공을 CTest 성공으로 대체하지 않는다.

Root는 활성 중복 실행이 없음을 확인한 뒤 아래 단독 재현을 같은 source/test/환경으로 실행했다.

```powershell
ctest --test-dir .harness/build -C Debug -R '^ShellSurfacePressureReference\.SelectsUniqueSchemaOneFactorOneAcceptedFrame$' --output-on-failure
```

Managed session `2839`의 실제 exit는 `0`, `1/1 passed`, 전체 실행 시간 `636.99`초였다. 이전 실패는 동일 조건에서 재현되지 않았지만 최초 중단 원인을 확정하지 않는다.
기록은 Git ignored `.harness/build/baseline-before-mitc4-eigen/focused-rerun/`의 로그 및 `observation.json`에 있고, `LastTest.log` SHA-256은 `56e13949bf6af8b43c9a9177d1e261d1a13b115ac688c4f86318aa8156ae3690`이다.
전체 362개 suite 통과나 새 feature TDD evidence는 아니다. 현재 해당 단독 실행은 종료되었다.
Root의 read-only 관찰에서 이 test는 `fesa_solver.lib` mtime에 따라 기존 HDF5를 재사용한다. Planning/Implementation은 영향받는 최종 reference 검증이 새 binary에 대한 fresh solve인지 명시적으로 확인해야 한다.

Root는 이전 중단에서 미관찰된 나머지 pressure 7개를 같은 binary와 위 단독 재현의 fresh HDF5로 확인했다.

```powershell
ctest --test-dir .harness/build -C Debug -R '^ShellSurfacePressureReference\.' -E '(AuditsExactRequiredArtifactsAndIgnoresOptionalReviewArtifacts|SelectsUniqueSchemaOneFactorOneAcceptedFrame)$' --output-on-failure
```

Exit `0`, `7/7 passed`, `1.09`초이며 Git ignored `.harness/build/baseline-before-mitc4-eigen/remaining-pressure-tests/`의 `LastTest.log`/`observation.json`에 보존했다.
로그 SHA-256은 `60823270ffc3c9386a5936ddc8f3ac3fb89a5895412046b2689216ec7a50472f`다. 변경 전 baseline의 중단 실행 354 pass, 단독 재현 1 pass, 나머지 7 pass를 각각 확보했으나 단일 전체 suite 성공으로 합쳐 보고하지 않는다.
Root의 baseline 분류 작업은 종료되었고 source/test/환경/reference 변경은 없었다. 새 binary의 TDD·전체 suite·fresh reference 검증은 Implementation owner의 필수 작업이다.
Root의 read-only 시간 집계는 보존된 355개 duration 합 `1228.04`초에서 중단된 pressure `193.43`초를 성공 단독 실행 `636.97`초로 대체하고 나머지 7개 `1.09`초를 더한 `1672.67`초(약 27.9분)다.
이는 서로 다른 관찰의 합산 추정이며 실제 단일 전체 suite wall time 또는 pass evidence가 아니다. Planning은 full VERIFY와 fresh reference solve의 실제 소요를 고려하되 이 추정으로 timeout 변경·test 생략·검증 축소를 승인받았다고 해석하지 않는다.

### Executor와 등록 Stop의 실행시간 경계

Coordinator의 read-only `rg`/`Get-Content`(exit `0`)에서 [Executor](../../scripts/execute.py)의 `CODEX_TIMEOUT_SECONDS=1800`이 각 Codex `subprocess.run`의 전체 coding/RED/build/VERIFY session에 적용되고 별도 CLI timeout 인수가 없음을 확인했다.
Root의 후속 read-only 조사(실제 adapter 구성 import `python -B -`, exit `0`)는 다음 경계를 확인했다.

| 경계 | 현재 실제 설정 |
| --- | --- |
| [.codex/hooks.json](../../.codex/hooks.json) 등록 Stop | outer timeout 1800초 |
| [stop_validation.py](../../scripts/hooks/stop_validation.py) | `TOTAL_TIMEOUT_SECONDS=1800`; repo/toolchain/configure/build/discovery/CTest 전체 shared deadline |
| [models.py](../../scripts/msvc_harness/models.py) | `CommandSpec.timeout_seconds=1800` |
| [process.py](../../scripts/msvc_harness/process.py) | 각 command cap과 shared remaining의 최솟값 사용 |
| [config.py](../../scripts/msvc_harness/config.py) 및 실제 adapter | local config 없음, timeout field 지원 없음/unknown key 거부; 자동 CMake/VS18/x64/Debug plan은 각 command cap1800, preset 없음 |

이 관찰은 Hook 실행이나 실제 timeout 실패가 아니다. 전체 VERIFY 합산 추정과 비교하면 coding/RED/build 및 등록 Stop까지 포함할 여유가 작으며 Executor만 변경해도 다른 cap은 늘지 않는다.
Planning은 기존 지원 설정 유무와 실제 full/fresh VERIFY를 대조해 최소 실행 방식을 구체화해야 한다. 기존 knob가 없다면 Root가 확인한 사용자 실행 승인 범위 안의 필요한 가역적 운영 개선으로, 대응 Harness tests를 갖춘 bounded timeout 설정/수정을 검토할 수 있다. 정확한 변경·owned paths·검증은 계획이 확정하며 현재 어떤 runtime/config/source도 수정하지 않았다.
Sandbox, transport retry 횟수·증거, ownership, full VERIFY 및 Hook 검증 의미는 유지한다. Cached reference를 새 실행으로 주장하거나 unobserved process로 deadline을 피하지 않는다. Runtime 변경 자체로 새 사용자 승인 gate를 만들지 않되 별도의 명시 critical boundary가 생기면 그 규칙을 따른다.

Planning의 실제 helper 대조에서 nonlinear `RunFesaApplicationOnCopiedInput()`은 매번 FESA application을 호출하므로 pressure 일부 helper의 cache로 전체 prep VERIFY가 빨라진다고 가정할 수 없음이 확인되었다. 또한 `process.execute_plan`의 default shared fallback과 prep Codex launch 당시 등록된 Stop outer cap의 수명도 대조해야 한다.
Root는 사용자 승인된 가역적 운영준비 범위 안에서, 실제 repository `StepExecutor`/`main`을 호출하기 직전 **단 하나의 유한 `CODEX_TIMEOUT_SECONDS` 값만 지정하는 one-time Python module invocation**을 계획에 명시할 수 있다고 판단했다. 이는 기존 CLI timeout option이 아니며 아직 실행하지 않았다. 정확한 값·명령·activation 경계는 Planning owner가 고정한다.
해당 준비 실행도 기본 `workspace-write`, native failure 뒤 별도 승인이 필요한 확대 경계, exact ownership, Executor branch/commit, full VERIFY, registered Stop, terminal result와 retry budget을 유지한다. Hook state/reentry flag, 실행 메서드, tests 또는 다른 guard를 override하지 않는다. Prep process가 이전 Stop outer 1800초를 유지할 가능성을 기록하고 실제 성공 evidence 없이 활성화를 주장하지 않는다. Active Executor 동안 Root/Coordinator의 관리문서 편집·커밋도 중지한다.

## Retry 기록

Correction 및 implementation rerun 사용 이력 없음. Transport attempt와 별도로 관리한다.