docs: preserve MITC4 prep failure and recovery plan

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

@@ -4,14 +4,14 @@
 - 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 이력 별도 보존)
+- Outcome: `blocked-environment` (execution-prep Step0의 지정 `.codex/hooks.json` 쓰기 거부)
+- Next owner: `coordinator-agent` (R2의 실제 Executor WIP checkpoint 할당; 이후 bounded Correction)
+- Attempt: `1` (prep native 실행 1회; transport 재시도 없음)
 - Completion: 미완료
-- Failure classification: `null`
-- Retry key: `null`
+- Failure classification: `environment` (별도 focused test 수정의 미검증 상태도 보존)
+- Retry key: `mitc4-shell-feast-eigen|implementation|environment|r2`
 - Escalation class: `null`
-- Blocker: `null` (실제 execution-prep/main 및 후속 기술 gate는 아직 미완료)
+- Blocker: Native workspace-write가 지정된 Hook 설정 변경을 거부했다. 실제 실패와 부분 구현을 보존하고 권한·재개 조건을 충족하기 전에는 pending reset이나 재실행을 하지 않는다.
 
 기준: [프로젝트 지침](../../AGENTS.md), [프로젝트 PRD](../PRD.md), [프로젝트 ADR](../ADR.md),
 [SOLVER_AGENT_DESIGN](../SOLVER_AGENT_DESIGN.md), [FEATURE_DOCUMENTATION](../FEATURE_DOCUMENTATION.md).
@@ -34,14 +34,49 @@
 | 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 확인 |
+| implementation r2 prep attempt 1 | [작성 시점 보고서](implementation-prep-evidence.md), [실제 terminal 상태](../../phases/mitc4-shell-feast-eigen-execution-prep/index.json), [원시 Codex 결과](../../phases/mitc4-shell-feast-eigen-execution-prep/step0-output.json) | blocked-environment; Hook 설정 미변경, 마지막 test 수정 미검증, 수동 full VERIFY 및 solver 구현/reference 미실행 |
 
 공통 문서 및 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은 아직 실행하지 않았다.
+Root의 intake 시작 Git 조사에서는 worktree clean을 확인했다. 당시 구현·build/test·외부 reference comparison은 미실행이었다. 이후 실제 실행 결과는 아래 prep attempt 기록으로 구분한다.
 관리문서 상대 링크 검사 결과는 `4`문서, 끊긴 local link `0`, exit code `0`이며 `git diff --check`도 exit code `0`이다.
 
 ## 현재 bounded dispatch
 
+Planning owner의 복구계획 반환4개를 감사했다. [R2](implementation-recovery.md#r2-root-checkpoint-이후의-정확한-wip-보존-명령)의 unchanged `_commit_paths` 호출은 timeout-only AST·origin 이후 정확8개 문서 경로·linked identity·role·default sandbox·source8/control2 dirty 범위·blocked/history/raw/모든 파일 bytes 불변을 확인한다. 구현 WIP와 blocked metadata를 별도 commit하고 성공 상태를 만들지 않는다. [R3/R4](implementation-recovery.md#r3-승인-후에만-가능한-status-only-checkpoint)는 실제 Correction/후속 checkpoint/해당 실행 직전 사용자 승인 뒤에만 조건부 실행한다.
+Owner 정적 검증은 Python checkpoint AST2/local links107/EOF·whitespace와 PowerShell block3 syntax errors0, 각 exit `0`이다. Coordinator는 반환4개 owner/r2/hash·links107/AST2를 재확인했고 exit `0`, 실제 read-only Executor constructor/identity/profile/linked/default sandbox 확인도 exit `0`이었다. `implementation-verification.md`, source/tests/index/top/raw는 이 Planning 작업에서 변경하지 않았다. 이 audit는 복구계획만 수용하며 implementation outcome은 `blocked-environment`를 유지한다.
+실행 순서는 Root의 정확8문서 checkpoint → Coordinator가 R2의 실제 Executor WIP 두 commit을 할당 → 공식 Correction Agent가 재현된 classifier 결함만 수정·검증 → 실제 결과에 대한 Planning의 후속 checkpoint 감사 → 사용자 exact-run 승인 및 status-only recovery → 새 prep process다. 이미 로드된 classifier를 reload/override하지 않는다. 현재는 Correction 미실행이고 별도 allowance를 아직 사용하지 않았다. R2 실행 중에는 모든 non-owned 문서/코드 편집과 Root Git 작업을 동결한다.
+
+아래는 완료된 bounded Planning dispatch 이력이다. Native prep attempt가 종료되어 관리문서 동결을 해제하고 Planning owner에게 실제 실패를 보존하는 복구 계획과 아래 classifier 결함의 최소 TDD 계획만 할당했다. 할당 범위는 `implementation-plan.md`, `implementation-environment.md`, 필요한 같은 폴더 `implementation-recovery.md`, `implementation-verification.md` 및 prep `step0.md`였으며 source/test/Implementation 보고서/phase index·status/Git은 수정하지 않았다.
+기존 unchanged Executor의 guarded `_commit_paths`로 부분 구현과 control metadata를 별도 blocked/WIP commit하는 최소 절차를 구체화한다. 새 관리/계획 문서는 Root가 정확 경로로 먼저 checkpoint하여 현재 Step의 경로 검사 밖 dirty 파일을 남기지 않아야 한다. 이 작업은 `_commit_step`이나 성공 판정·pending reset을 호출하지 않으며 Hook 설정 거부를 우회하는 편집을 하지 않는다.
+실제 native 실패, clean linked worktree와 해당 실행 직전 사용자 명시 승인이 필요한 sandbox 경계는 [Harness skill](../../.agents/skills/harness/SKILL.md#elevated-and-remote-execution)을 따른다. 권한 결정 이전에는 기존 failure history를 보존한 채 중단한다. 별도 사용자 승인은 아직 없다.
+
+### Execution-prep attempt 1 실제 결과
+
+Root는 최종 Planning checkpoint를 `d533b61`로 커밋했고 exact20 paths/staged check/commit/status를 확인했다. 재개 직전 clean, Git root 일치, 기본 sandbox 및 활성 중복 process 없음을 확인한 뒤 아래 승인된 E3 명령을 실행했다.
+
+```powershell
+python -B -c "from scripts import execute; execute.StepExecutor.CODEX_TIMEOUT_SECONDS = 14400; execute.main()" mitc4-shell-feast-eigen-execution-prep
+```
+
+Managed session `27453`은 shell exit `1`로 종료했다. 별도로 측정하지 않은 Python Executor exit를 추정하지 않는다. Raw Codex `exitCode=0`, `transportFailure=null`, 명시적 `blocked`가 보존되었고 Executor는 transport retry 없이 prep/top phase를 `blocked`로 기록했다. 실제 시작은 `2026-09-06T10:04:44+0900`, terminal history는 `2026-09-06T10:28:44+0900`이다. Branch는 `feat-mitc4-shell-feast-eigen-execution-prep`, HEAD는 여전히 `d533b615410751fe023dc73ac2be994f05d37d30`이며 Executor가 생성한 새 commit은 없다.
+Raw JSON SHA-256은 `0d5c0fe0aeba5604c5289764e7aad1834902548ca02158f8feac03484b195941`이다. Stderr에는 `patch rejected: writing outside of the project; rejected by user approval settings`가 3회 기록되었다. Native report의 대상은 `.codex/hooks.json`이며 실제 해당 파일은 변경되지 않았다. Executor의 일반 분류 문구 `Codex Windows sandbox helper를 실행할 수 없습니다.`를 모든 도구의 실행 불능으로 확대하지 않는다.
+
+Focused command는 `uv run --with pytest python -B -m pytest -v -rs tests/test_harness_timeouts.py`였다. Raw JSONL event62에서 첫 test fixture 오류를 포함해 4 failures, event64 test-only 수정 뒤 event66에서 의도한 1800 기본값에 대한 4 failures를 확인했다(각 exit `1`, 약0.40초). 이후 runtime 값 변경 뒤 event78은 exit `1`, `2 passed, 2 failed`, 1.86초였다.
+
+- `test_stop_passes_one_shared_deadline_to_root_toolchain_and_plan`: 7200 값과 deadline 전파는 도달했지만 서로 다른 import의 `ProjectKind.CMAKE` 객체 비교가 실패했다. Event80에서 `.value` 비교로 test-only 수정했으며 이후 pytest 실행은 없다. 적용된 수정은 미검증이다.
+- `test_registered_hook_and_one_time_invocation_contract`: Hook timeout `1800 != 7500` 실패다. 지정 `.codex/hooks.json` 쓰기 거부와 연결되며 설정은 1800으로 남아 있다.
+
+[Implementation 작성 시점 보고서](implementation-prep-evidence.md)는 두 실패와 후속 test-only 수정의 검증 상태를 충분히 구분하지 않는다. Coordinator는 본문을 수정하지 않고 raw 순서로 gate를 판정하며 재개 Implementation owner에게 정확한 보고서 갱신을 요구한다. Python·Hook의 runtime 일부와 tests/doc 변경은 owned 범위에 있으나 manual configure/build/CTest/full pytest는 실행하지 않았다. 뒤의 aggregate shell exit `0`에는 `python` CommandNotFound가 섞여 있어 개별 command 성공 증거가 아니다. 추가 `uv run python -B -c ...` 상태 확인은 사용자 uv cache 접근 거부로 exit `1`이었다.
+
+Native Codex의 실제 등록 Stop process `21804`와 CTest child `21716`를 관찰했다. 명령은 `python -X utf8 .../scripts/hooks/stop_validation.py`, `ctest --test-dir .../.harness/build -C Debug --output-on-failure`였고 실제 Debug/x64 build process도 관찰했다. 이는 수동 full VERIFY가 아니다. [CTest LastTest.log](../../.harness/build/Testing/Temporary/LastTest.log)는 362 `Test Passed`, 0 `Test Failed`, 시작10:12/종료10:28을 기록했다. 크기606010 bytes, SHA-256 `f32e535ba6d6b8b8ed7910b0790600698cfa5f20035d12ec5c6821c76df2291f`다. 별도 Stop/CTest process exit는 측정하지 못했으므로 `exit 0`으로 기록하지 않는다. 이 로그는 이후 실행으로 교체될 수 있는 ignored generated evidence다.
+Root가 workspace 내부의 ignored [attempt1 archive](../../.harness/build/mitc4-eigen-evidence/prep/attempt1/observation.json)에 `LastTest.log`, `step0-output.json`, `phase-index.json`, `top-index.json`을 복사하고 원본/복사본 hash 일치를 확인했다(exit `0`). [보존 CTest 로그](../../.harness/build/mitc4-eigen-evidence/prep/attempt1/LastTest.log)와 [보존 raw 결과](../../.harness/build/mitc4-eigen-evidence/prep/attempt1/step0-output.json)를 이후 audit의 안정 경로로 사용한다. Source/control/reference와 Hook state는 변경하지 않았다.
+Root의 추가 read-only/pure-function 재현은 [classifier observation](../../.harness/build/mitc4-eigen-evidence/prep/attempt1/classifier-observation.json)에 있다(SHA-256 `74c80fbdfc1eb5d4e28c5e1c77caf33d23af30858bbb7fb9742358e0d8df7eb5`, exit `0`). Raw stdout의 `orchestrator_helper_launch_failed` 7회는 성공한 source/test read command 4개(JSONL lines20/28/44/58, 각 exit `0`)에만 있고 stderr에는 없다. 기존 `_codex_environment_failure`는 성공한 source excerpt 문자열만 있는 exit0 payload도 helper failure로 반환했다. 따라서 현재 helper-launch reason은 source echo에 의한 Harness 분류 오탐이며 실제 도구 launch 실패의 evidence가 아니다. `.codex/hooks.json`의 실제 승인 설정 거부와 명시적 `blocked`는 여전히 유효하고 history를 수정하지 않는다.
+같은 source read가 재실행의 성공 결과도 막을 수 있으므로 Planning에 기존 prep 소유 `scripts/execute.py`/`tests/test_execute.py` 안의 최소 TDD 회귀 계획을 추가로 할당했다. 실제 helper failure, 명시 terminal, sandbox·transport retry·ownership 보호를 유지하는 분류 수정만 다음 Implementation에 포함하며 Coordinator/Root는 source를 수정하지 않는다. 이는 운영 결함의 계획 delta로 physics/schema/tolerance `r2`를 바꾸거나 Correction budget을 새로 만들지 않는다.
+Main Step0~7, solver C++ 변경, FEAST/reference 비교, physics/release는 미실행이다. Prep의 현재 outcome으로 구현 gate나 timeout activation을 통과시키지 않는다. Failure history·부분 구현을 보존하는 checkpoint 계획은 routine local 준비이며, 환경/사용자 결정 해소 후에만 Planning의 명시적 status-only recovery와 정확한 재실행을 허용한다.
+
+### 최초 Implementation 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`를 확인했다.
@@ -315,4 +350,5 @@ Root는 사용자 승인된 가역적 운영준비 범위 안에서, 실제 repo
 
 ## Retry 기록
 
-Correction 및 implementation rerun 사용 이력 없음. Transport attempt와 별도로 관리한다.
+`mitc4-shell-feast-eigen|implementation|environment|r2`: actual attempt `1`, native terminal `blocked`, transport retry `0`, Correction `0`, Implementation rerun `0`이다. Specialist가 반환한 `focused-verify` 문구를 implementation gate로 정규화했으며 새로운 실패 key를 만들지 않았다.
+Focused test의 마지막 적용 수정은 미검증으로 남는다. 이를 환경 실패로 통과 처리하거나 새 correction allowance로 취급하지 않는다. 환경 해소 후 같은 Step owner가 해당 test와 전체 필수 검증을 완료해야 한다.