FESADev/docs/mitc4-shell-feast-eigen/implementation-environment.md

# 구현 환경·실행시간·evidence 운영 계획

- Feature ID: `mitc4-shell-feast-eigen`
- Owner: `implementation-planning-agent`
- Input contract revision: `r2`
- 기본 보고서: [implementation-plan](implementation-plan.md)

## E1. 실제 backend와 preflight

[현재 환경 evidence](coordination.md#후속-실행-준비-관찰)를 적용한다. 이 계획 단계에서는
Harness, CMake/CTest, C++ 또는 FEAST를 실행하지 않는다. Root의 과거 관찰은 신규 gate 성공이 아니다.

| 선택 | 실제 값 |
| --- | --- |
| Repository | linked worktree, `C:/Users/baram/orca/workspaces/FESADev/Eigen`; Git top-level과 Harness ROOT 동일 |
| Baseline | I/O checkpoint `1d4f5ac`; 사용자 branch `Eigen`에서 계획 작성 |
| Harness config | `.harness/config.json` 없음; autodetect CMake |
| Build | Visual Studio 18 2026 / MSVC / x64 / Debug / `.harness/build` |
| GoogleTest | `C:/git/googletest` |
| MKL_DIR | `C:/Program Files (x86)/Intel/oneAPI/mkl/2026.1/lib/cmake/mkl` |
| TBB_DIR | `C:/Program Files (x86)/Intel/oneAPI/tbb/2023.1/lib/cmake/tbb` |
| HDF5_DIR | `C:/Program Files/HDF_Group/HDF5/2.1.1/cmake` |
| Observed MKL configuration | 2026.1 / dynamic / intel_ilp64 / intel_thread; 실제 FEAST 실행에서 version/ABI를 다시 기록 |
| Python / CLI | Python3.11.15; python/uv/cmake/ctest/codex resolved. Codex transport/login은 아직 실행 검증 전 |
| Executor role | `.codex/agents/implementation-agent.toml`, gpt-5.6-terra / xhigh / workspace-write |

개인 설치 경로를 C++/CMake source에 고정하지 않는다. 아래는 이 workstation의 local cache
구성 명령이며 이미 Root가 exit0으로 확인했다. 실제 실행 전 cache의 경로/compilers/platform을
다시 읽고 stale/missing이면 동일 환경 준비 명령을 실행한다.

```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"
```

다음부터는 Step의 unadorned configure/build/CTest 명령을 사용한다. Preset은 dependency
환경변수4개를 참조하므로 현재 미설정된 부모 환경에서 preset을 호출하는 계획은 선택하지 않는다.
VS generator는 CMake가 MSVC를 선택하고 `--config Debug`/`-C Debug`로 검증한다.
필수는 CMake/MSVC/x64/Debug이며 Ninja 예시 자체가 필수는 아니다. Hook도 같은 absent-config
autodetect를 사용한다. Subprocess 환경을 부모 Stop에 전파했다고 가정하지 않는다.

## E2. 최소 deadline 변경과 근거

Actual code의 다음 모두가 유한 제한을 적용한다. 지원되는 CLI/config timeout option은 없다.

| 경계 | 현재 | prep 후 |
| --- | ---: | ---: |
| StepExecutor Codex wrapper | 1800 | 14400 |
| 등록 Stop outer | 1800 | 7500 |
| Stop discovery/configure/build/discovery/CTest shared | 1800 | 7200 |
| CommandSpec default per-command | 1800 | 7200 |
| execute_plan의 명시 deadline 없는 default shared | 1800 | 7200 |

전체 regression duration의 기존 합산 추정은1672.67초(약27.9분)다. 이는 여러 run의 값이며
단일 full suite wall time/pass가 아니다. 추가 eigensolver tests와 fresh reference 비용은
미측정이다. 7200초는 기존 약28분 검증에 초기 실행/신규 numerical tests 여유를 두되 유한하게
중단하는 운영 상한이다. Registered7500은 shared7200 종료/진단을 위한300초 여유,
wrapper14400은 coding·RED/GREEN·focused·수동 full VERIFY와 등록 Stop을 함께 감싼다.
상한을 더한 값을 실제 소요 시간이라고 보고하지 않는다.

Main은8개 Step이다. 각 Step은 하나의 완결된 API/data boundary를 담당하고 동일 session에서
작은 behavior별 RED/GREEN을 반복한다. 통상 coding/focused 약2시간 안, 수동 full과 Stop 각
약30~45분을 고려한 분해다. 이는 실행 예산 설계이며 소요 보장이나 시험 결과가 아니다.
예상보다 늦거나 failure이면 terminal evidence를 남기고 Coordinator가 원인을 분류한다.
Timeout을 무한대로 만들거나 test/Hook를 생략하지 않는다.

14개 초기 소단위를8개로 합쳐 불필요한 전체 검증 반복6회를 줄였다. Model+parser는 같은
frequency/density 정의, consistent+lumped+assembly는 같은 moment snapshot, call+search는
하나의 FEAST result/history, validation+procedure는 한 candidate, writer+CLI는 한 transaction,
comparator+fresh execution은 한 source matching 결과를 완성한다. Stabilization과 reduction은
각각 기존 static 영향과 analytic positive/null 경계라 독립 Step으로 유지한다.

## E3. One-time bootstrap와 새 process activation

일반1800초 invocation은 prep 중 source self-edit로 이미 시작된 wrapper의 timeout을 늘리지
못한다. Pressure 일부는 same-binary HDF5 cache를 사용하지만
`RunFesaApplicationOnCopiedInput()`은 nonlinear reference solver를 매번 직접 호출한다.
따라서 full VERIFY+registered Stop을 모두 cached/빠르다고 가정하지 않는다.

Root와 Coordinator가 사용자 승인된 가역적 운영 준비로 해석한 **one-time module invocation**을
prep에만 사용한다. 기존 CLI option이 아니다. 실제 module을 import하고 한 유한 class timeout만
설정한 뒤 unchanged `main()`을 호출하므로 기존 argparse/preflight/branch/ownership/sandbox/
terminal result/transport retry/commit/finalization 경로를 그대로 실행한다.

```powershell
python -B -c "from scripts import execute; execute.StepExecutor.CODEX_TIMEOUT_SECONDS = 14400; execute.main()" mitc4-shell-feast-eigen-execution-prep
```

Bootstrap은 Hook state/reentry flag/execution method를 override하지 않는다. Prep에서
`.codex/hooks.json`을 수정해도 이미 launch된 Codex의 registered Stop outer1800이 유지될
수 있다. 그 세션에 새7500이 반영됐다고 단정하지 않는다. Prep의 actual manual full/registered
Stop/Codex exit와 source/control commits를 확인해야 한다. Stop이 실제 cap을 넘거나 실패하면
원시 log와 terminal 상태를 보존한 채 환경 분류로 반환한다. 성공으로 덮어쓰기/즉시 재실행하지 않는다.

Prep Executor가 **정상 종료하고 Step0 completed·Codex exit0·등록 Stop 성공·정확 경로 commits·
clean 및 Coordinator의 사후 감사 완료**를 확인한 뒤 새 process에서 정상 main invocation을 실행한다.

```powershell
python scripts/execute.py mitc4-shell-feast-eigen
```

새 Executor는 source14400을 새로 읽고 새 Codex session은 변경된 등록7500/Stop7200/command7200
구성으로 시작한다. Source상 cap과 실제 검증 evidence를 함께 기록한다. Prep/main은
`feat-mitc4-shell-feast-eigen-execution-prep`와 `feat-mitc4-shell-feast-eigen` branch를
Executor가 차례로 소유한다. Main branch는 prep 완료 HEAD를 포함해야 한다.

## E4. Git와 활성 실행의 경계

1. Coordinator가 계획 gate를 감사한 뒤 Root가 완료 Feature 문서/계획 및 두 phase 제어 파일의
   정확 목록을 checkpoint한다. 두 phase를 만들었으므로 선택되지 않은 phase files까지 미리
   commit해 selected-phase allowlist 밖 dirty 파일이 없게 한다. 기존 unrelated pending beam
   phase/history는 보존하며 invocation 대상으로 삼지 않는다.
2. 실행 직전 `git rev-parse --show-toplevel`, `git status --porcelain=v1 --untracked-files=all`,
   actual role/config를 읽는다. Linked worktree와 Harness ROOT 동일성을 확인한다.
3. Active Executor 동안 Root/Coordinator/다른 specialist는 non-owned edits/commits를 멈춘다.
   Implementation은 선택 Step paths와 해당 Step result fields만 수정한다. Commit/branch/
   timestamp/attempt_history/phase 진전은 Executor 소유다.
4. Terminal failure는 raw payload·history·logs를 보존한다. Coordinator의 assigned recovery가
   없으면 pending reset/재시작하지 않는다. Correction budget과 transport retry는 별개다.
5. Default workspace-write를 사용한다. Danger-full-access는 같은 native command의 실제 실패,
   해당 실행 직전 사용자 명시 승인, clean linked worktree, 승인 flag를 모두 요구한다.
   이번 timeout 준비는 sandbox 확대 권한이 아니다. Remote push/tag/publish/deploy/package는 없다.

## E5. 실제 실행 evidence 보존

각 Step raw evidence root는 ignored `.harness/build/mitc4-eigen-evidence/stepN/`, prep은
`.../prep/`다. `New-Item -ItemType Directory -Force`와 `Copy-Item -LiteralPath`는 해당
resolved workspace 하위 generated 경로만 대상으로 한다. Recursive delete/move는 계획하지 않는다.
긴 command는 managed process/session으로 실제 exit까지 관찰하며 약60초마다 Coordinator에
의미 있는 진행을 보낸다. Detached/unobserved execution으로 deadline을 피하지 않는다.

RED/focused/full command stdout/stderr·actual exit·wall time·CTest discovery JSON·LastTest.log를
각각 고유 이름으로 보존한다. Tee/pipeline 사용 시 `$LASTEXITCODE`를 즉시 보존한다.
CTest observer shell exit0을 CTest exit0으로 기록하지 않는다. Hook state를 조작하거나
수동 hook 실행으로 evidence를 만들지 않는다. 등록 Stop 이후의 실제 실패는 manual full pass로
덮어쓰지 않는다. Implementation 보고 시점의 실제 manual evidence와 마지막 Stop/exit 확인 대기를 구분하며 미래 성공을 보고서에 쓰지 않는다. Executor 종료 뒤 Coordinator가 raw output·등록 Hook evidence·actual exit를 management 문서에서 감사한다. Coordinator는 specialist 보고서 본문을 대신 수정하지 않는다. Prep→main activation은 이 사후 감사까지 완료된 뒤에만 가능하다.

C++ source 변경 없는 prep의 same-binary 회귀와 새 binary의 fresh eigen/static 비교는 다른
evidence다. Final Step7는 직접 solver invocation·unique generated directory·원본 bytes/hash·
binary/lib hash·result/log mtime/hash·call count를 남겨 freshness를 증명한다. 기존 helper가
파일 존재/mtime로 cache를 사용한 사실만으로 fresh라고 주장하지 않는다.