docs: plan MITC4 mass and FEAST implementation

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

@@ -3,15 +3,15 @@
 - Feature ID: `mitc4-shell-feast-eigen`
 - Owner: `coordinator-agent`
 - Contract revision: `r2` (사용자 승인 stabilization 개선·영향받는 정적/eigen 재검증 범위)
-- Stage: `implementation-planning`
-- Outcome: `pass` (r2 io-definition 입력·schema·mapping evidence 확인)
-- Next owner: `implementation-planning-agent`
+- 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` (Planning 및 후속 기술 gate는 아직 미완료)
+- 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).
@@ -33,6 +33,7 @@
 | 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가 검토한다.
@@ -41,11 +42,25 @@ Root의 시작 Git 조사에서 worktree clean을 확인했다. 구현·build/te
 
 ## 현재 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 이력
 
@@ -294,6 +309,10 @@ Root의 후속 read-only 조사(실제 adapter 구성 import `python -B -`, exit
 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와 별도로 관리한다.