FESADev/docs/ADR.md

# FESA Architecture Decision Records

## 목적과 기록 범위

FESA는 유한요소법 기반 구조해석 솔버를 단계적으로 구축한다. 이 문서는 그 과정에서
프로젝트 전반에 적용되는 결정의 이유와 트레이드오프를 관리한다. 제품 목표는
[PRD](PRD.md), 공통 책임과 의존성은 [ARCHITECTURE](ARCHITECTURE.md)를 따른다.

특정 요소·재료·하중·해석 절차의 정식화, 수치 기준과 구현 선택은
`docs/<feature-id>/ADR.md`에 기록한다. 해당 Feature의 목적·범위·acceptance 요약은
같은 폴더의 `PRD.md`, 상세 전문 계약은 requirements·formulation·I/O 등의 소유 문서에 둔다.
공통 ADR에 기능 목록, 진행 상태와 개별 실행 결과를 누적하지 않는다.

## 기존 결정의 보존과 읽는 방법

개정 전 ADR-001~023의 전체 원문은
[원문 보존본](archive/pre-generalization/ADR.md)에 있다. 아래 기존 ID 항목은 그 결정의
공통 부분을 요약한 것이며 번호 재사용, 새 physics 승인 또는 기존 세부 계약의 폐기가 아니다.
구체적인 적용 범위는 원문의 같은 ID와 해당 Feature의 승인된 최신 계약을 함께 확인한다.

- 과거 결정을 소급 수정하거나 모든 과거 상태를 일괄 `Accepted`로 표시하지 않는다.
- 일부만 대체된 결정은 유지되는 부분과 대체된 부분을 구분한다.
- 현재 선택된 toolchain, 외부 형식과 구현별 계약은 [AGENTS.md](../AGENTS.md) 및 승인된
  설정·Feature 계약을 따른다. 문서 일반화만으로 이를 교체하지 않는다.
- 기존 결정 번호는 다른 의미로 재사용하지 않는다. 후속 결정은 마지막 번호 다음으로 추가한다.
- ADR-024~027은 당시 agent·skill·Feature 문서 운영 계약의 이력이다. 현행 운영은
  [ADR-028](#adr-028)을 따른다. 대체 안내 아래의 기존 결정 본문과 그 안의 링크는
  결정 당시 설명으로 읽으며 현행 절차를 요구하는 근거로 사용하지 않는다.

## 프로젝트 공통 결정

### ADR-001: Solver 제품과 개발 운영 인프라를 분리한다

**결정**: 프로젝트의 제품은 구조해석 솔버다. Agent·skill·Harness는 소스, 문서와
검증 evidence를 관리하는 개발 운영 영역이며 solver runtime의 의존성이 아니다.

**이유**: 개발 자동화의 편의가 물리적 의미, 사용자 요구와 수치 검증을 대신하지 않게 한다.

**트레이드오프**: Solver의 완료 evidence와 자동화 자체의 correctness를 별도로 관리해야 한다.
현재 운영 역할과 검증 범위는 ADR-028을 따른다.

### ADR-002: 구현·검증 환경은 명시된 프로젝트 baseline으로 관리한다

**결정**: 현재 FESA의 C++ 언어·compiler·platform·build/test baseline을 프로젝트 지침과
설정으로 명시하고 실제 실행 환경을 evidence에 기록한다. 재사용 Harness가 다른
backend를 처리할 수 있다는 사실을 FESA 제품 지원으로 간주하지 않는다.

**이유**: 개발 환경의 암묵적 차이가 build와 numerical regression 판정을 흐리지 않게 한다.

**트레이드오프**: 새 환경은 별도의 compatibility와 실행 evidence가 필요하다. 원문의
기술 선택 이력은 유지하며, 현재 preset·명령 선택은 ADR-028이 유지하는 구성 경계를 따른다.

### ADR-003: 외부 입력은 승인된 subset의 의미로 지원한다

**결정**: 외부 형식의 syntax와 semantic mapping을 구분하고 지원·미지원 범위를 명시한다.
미지원 모델 의미는 fail-closed로 진단하며 무해하다고 계약된 항목만 warning/no-op으로 둔다.

**이유**: Parser가 읽을 수 있다는 사실과 물리적으로 해석할 수 있다는 사실은 다르다.

**트레이드오프**: 기존 외부 모델을 수정해야 할 수 있지만 silent approximation과 과도한
호환성 약속을 피할 수 있다. 실제 입력 형식의 선택은 기존 승인 계약을 유지한다.

### ADR-004: 모델 정의, 실행 view, equation과 mutable state를 분리한다

**결정**: 모델 owner, non-owning 실행 view, DOF/equation owner와 procedure state를
구분한다. View는 원본보다 오래 살지 않으며 승인된 procedure에 필요한 state만 둔다.

**이유**: Parsing, model activation, numerical solve와 recovery의 수명이 섞이지 않게 한다.

**트레이드오프**: 명시적인 연결과 lifetime 관리가 필요하지만 모델 복사와 분산된
equation numbering, 미래 state의 불필요한 할당을 줄인다.

### ADR-005: Authoritative result와 reference·debug artifact를 구분한다

**결정**: 공식 결과의 물리 identity와 versioned 저장 계약을 유지한다. Reference와
debug view를 공식 결과로 대체하지 않는다. 기존 HDF5 선택은 유지하며 보조 형식의 존재가
공식 형식 변경을 뜻하지 않는다.

**이유**: 결과 검토 도구나 비교 편의를 위해 authoritative quantity와 파일 의미가 바뀌는 것을 막는다.

**트레이드오프**: 물리 identity와 저장 mapping을 함께 관리해야 한다.
원문의 reference naming 규칙은 ADR-019로 대체되었고, 파일명·경로의 후속 결정은
보존본 ADR-023에 있다. 이를 문서 정리 과정에서 과거 값으로 되돌리지 않는다.

### ADR-006: 알고리즘과 backend를 명시적인 interface 뒤에 둔다

**결정**: 승인된 analysis와 numerical·parallel·output backend의 계약을 implementation과
분리한다. Vendor/OS 타입과 resource lifecycle은 private adapter에 둔다.

**이유**: 해석의 물리 의미가 특정 library API와 오류 처리에 종속되지 않게 한다.

**트레이드오프**: Adapter와 계약 테스트 비용이 생긴다. 실제 사용 사례가 없는 Strategy,
factory, 공통 base나 future capability를 미리 도입하지 않는다.

### ADR-007: 해석 procedure가 자신의 lifecycle을 소유한다

**결정**: 공통 analysis 경계는 최소 실행 계약만 제공한다. 구체적인 state, assembly,
solve, 반복·종료와 recovery 순서는 procedure별 승인 계약으로 정의한다.

**이유**: 서로 다른 해석의 의미를 하나의 고정된 Template Method나 조건문에 강제하지 않는다.

**트레이드오프**: Procedure 사이의 일부 코드가 중복될 수 있다. 승인된 연산 순서는
보존하며 실제 공통 책임이 확인된 경우에만 collaborator로 분리한다.

### ADR-008: Local contribution과 global assembly를 분리한다

**결정**: Local 계산은 명시된 ordering으로 contribution을 반환하고, 전역 조립은 지정된
pattern·scatter와 deterministic reduction을 사용한다.

**이유**: 요소 수식과 전역 연결 오류를 분리해 검증하고 scheduling에 의존하지 않게 한다.

**트레이드오프**: Buffer와 변환 비용이 생긴다. 기존 저장·조립 방식의 교체는 별도 evidence와
계약 검토가 필요하며 이 요약은 비결정적인 경로를 허용하지 않는다.

### ADR-009: 병렬화는 소유권이 명확한 독립 작업에 적용한다

**결정**: Worker는 자신의 local output에만 기록하고 공유 결과의 reduction과 diagnostic
선택은 결정적으로 수행한다.

**이유**: Race와 부동소수 누적 순서가 물리 검토·회귀 비교를 흔들지 않게 한다.

**트레이드오프**: 병렬화 범위와 throughput이 제한될 수 있다. Backend thread와 task
정책은 실제 측정과 검증을 통해 정하며 승인된 ordering을 보존한다.

### ADR-010: 외부 reference는 명시적인 소유권과 권한 아래 유지한다

**결정**: 저장된 reference는 read-only다. 생성·수정·복원과 외부 solver 실행은 명시적으로
승인된 범위에서만 다루며, 구현을 통과시키기 위해 artifact를 보정하지 않는다.

**이유**: 검증 기준과 구현 결과가 서로를 정당화하는 순환을 방지한다.

**트레이드오프**: 필요한 artifact가 없으면 적절한 owner나 환경 조치가 필요하다.
원문의 추가 metadata·provenance·naming 조건은 ADR-019로 대체되었다.

### ADR-012: 계획, 실행과 Hook 검증의 책임을 분리한다

> **부분 대체 — ADR-028:** 전용 Planning/Executor/Hook 분업은 폐기한다. 실제 검증
> evidence와 테스트 파일 존재의 구분은 유지한다. 아래 본문은 당시 결정의 이력이다.

**결정**: Planning은 할당된 계획 파일, Executor는 실행 상태와 Git 처리, Hook은 등록된
guardrail과 종료 검증을 담당한다. 테스트 파일 존재는 RED 관찰의 증거가 아니다.

**이유**: 자동화 각 계층이 보장하는 범위를 명확히 하여 검증 누락과 과장된 통과 판정을 막는다.

**트레이드오프**: Implementation은 실제 명령·결과를 별도 evidence로 남겨야 한다.
원문의 전체 Stop 검증 설명은 ADR-026의 조건별 검증 범위와 함께 읽고, 계획·실행의
권한은 ADR-024의 현행 운영 계약을 따른다.

### ADR-015: Build dependency와 runtime closure를 명시한다

**결정**: 외부 dependency를 프로젝트가 소유한 target 경계로 정규화하고 public API에
vendor type을 노출하지 않는다. 실행에 필요한 dynamic dependency도 검증 범위에 포함한다.

**이유**: Configure·link 성공만으로 실제 실행 환경의 완전성을 증명할 수 없다.

**트레이드오프**: Backend 추가마다 build 및 runtime 검토가 필요하다. 구체적인 package
선택·staging 구현은 현재 설정과 기존 승인 계약에 유지한다.

### ADR-016: 결정론과 failure preservation을 correctness로 취급한다

**결정**: Ordering과 reduction을 명시하고, state·result·final output은 검증된 candidate를
통해 반영한다. 실패 시 계약된 기존 유효 상태와 최종 결과를 보존한다.

**이유**: 재현 가능한 결과와 실패 후 신뢰할 수 있는 상태가 검증의 전제이기 때문이다.

**트레이드오프**: Buffer, candidate와 검증 비용이 증가한다. 성능 개선은 같은 보존
경계와 결과 의미를 입증해야 하며 correctness를 약화하는 예외로 처리하지 않는다.

### ADR-017: 제약 적용과 reaction 의미를 equation 계약으로 정의한다

**결정**: DOF mapping, 제약 적용, 해 복구, residual과 reaction의 의미를 명시적인
수학 계약으로 묶는다. Node/Element에 equation 번호를 분산 저장하지 않는다.

**이유**: 서로 다른 space나 enforcement 방식의 값을 같은 물리량으로 오인하지 않게 한다.

**트레이드오프**: 새 constraint 방식은 equation과 output의 영향을 함께 검토해야 한다.
원문에 있는 기존 elimination·full-residual 결정은 해당 기능 범위에서 계속 유지되며,
이 공통 요약이 다른 방식을 기존 구현에 적용할 권한을 주지 않는다.

### ADR-018: Kernel 존재와 제품 노출을 구분하고 계층형 검증을 요구한다

**결정**: 입력 의미, 내부 해석, 결과·진단과 필수 검증이 연결되어야 제품 기능으로 다룬다.
Local test, integration, reference 비교와 독립 물리 검토는 서로를 대체하지 않는다.

**이유**: 부분 구현이나 외부 수치 일치만으로 제품 지원과 correctness가 과장되는 것을 막는다.

**트레이드오프**: 작은 기능도 여러 종류의 evidence가 필요하다. Reference N/A는 이유와
승인된 대체 근거를 기록하며, 모든 기능에 동일한 benchmark 목록을 강제하지 않는다.

### ADR-019: 외부 solver의 관찰 가능한 의미와 내부 동등성을 구분한다

**결정**: 외부 제품의 공개 입력 의미와 승인된 출력량은 reference로 사용할 수 있지만
비공개 알고리즘·상태·결과 생성 절차를 추정하거나 동등성을 주장하지 않는다.
수치적 exact equality는 허용되지만 내부 동등성의 증거가 아니다.

필요한 source identity·component와 비교 artifact를 사용하며 기존 path와 값을 보존한다.
Canonical naming이나 중복 metadata·provenance를 기본 readiness gate로 추가하지 않는다.
이는 ADR-005·010의 관련 부수 조건을 대체하며 artifact immutability는 유지한다.

**이유**: 물리·수치 검증보다 외부 제품의 비공개 동작 추정이나 문서 형식 맞추기가 앞서지 않게 한다.

**트레이드오프**: 더 강한 provenance가 필요한 경우 별도 명시적 요구가 필요하다.
기본 비교에서도 누락·추가·중복·nonfinite 값과 잘못된 identity는 거부한다.

### ADR-021: Semantic definition과 runtime numerical contract를 분리한다

**결정**: 모델 정의는 identity와 입력 의미를 소유하고, runtime numerical object는
승인된 evaluation·contribution·recovery 계약을 제공한다. 생성 경계가 호환성을 검사한다.

**이유**: Parser와 global consumer가 모든 concrete element/material storage를 알 필요가
없도록 하면서 source identity와 명시적 소유권을 유지한다.

**트레이드오프**: Indirection과 compatibility 검증이 필요하다. Speculative cloning,
global registry와 future-only capability를 도입하지 않는다. 원문 리팩터링의 구현별
설명은 보존본에 있으며 당시 tolerance 참조는 후속 ADR-022와 함께 읽는다.

### ADR-022: 외부 reference comparison에 승인된 공통 정책을 적용한다

**결정**: 외부 reference의 family, scale, near-zero·row·RMS·zero-scale 판정과 보고·변경
관리는 [TOLERANCE](TOLERANCE.md)를 따른다. 기능별 비교량과 identity는 해당 Numerical
Review 및 I/O 계약으로 정의한다. 이 문서는 수치 상수와 판정식을 중복 유지하지 않는다.

**이유**: 기능마다 임의의 scale이나 오차 기준을 적용하거나 구현 결과에 맞춰 기준을
완화하는 일을 방지한다.

**트레이드오프**: 변경 시 관련 comparator와 evidence를 함께 재검증해야 한다.
ADR-014·020의 과거 수치 정책을 대체하지만 artifact 선택·identity·판정 영향 중 유지되는
부분은 원문과 후속 계약을 확인한다. 이번 일반화는 tolerance 변경이 아니다.

## 기능별·대체된 결정의 이관 기록

다음 ID는 프로젝트 공통 결정으로 다시 정의하지 않는다. 원문은
[보존본 ADR](archive/pre-generalization/ADR.md)의 같은 ID에 있으며, 향후 해당
`docs/<feature-id>/ADR.md`를 작성할 때 원래 ID·범위·revision과 대체 관계를 연결한다.
아직 작성하지 않은 Feature ADR을 존재하거나 승인된 문서처럼 링크하지 않는다.

| 기존 ID | 보존할 범위와 상태 | 이관 또는 조회 대상 |
| --- | --- | --- |
| ADR-011 | 구형 검증 진입점 폐기 이력; ADR-012로 대체됨 | 프로젝트 운영 이력 |
| ADR-013 | 최초 end-to-end 기능의 입력·해석 범위 결정 | `linear-static-3d-euler-beam` Feature ADR |
| ADR-014 | 최초 reference baseline 및 비교 계약 이력; tolerance와 projection은 ADR-022로 대체됨 | `linear-static-3d-euler-beam` Feature ADR |
| ADR-020 | 요소 확장의 reference 선택·판정 구분 이력; 수치 정책은 ADR-022로 대체됨 | `linear-static-mitc4-shell` Feature ADR |
| ADR-023 | 별도 procedure, accepted-frame 결과와 CLI 경로 결정 | `nonlinear-static-newton-raphson` Feature ADR; 공통 외부 경로의 후속 결정 근거로도 보존 |

원문의 결정 당시 상태를 현재 release verdict로 해석하지 않는다. 후속 Feature가 범위를
확장했거나 evidence가 stale인 경우 해당 승인 계약과 workflow 상태를 따로 확인한다.

## 공통 개발 운영 결정

### ADR-024: Coordinator가 evidence 기반 workflow와 유한 correction을 소유한다

> **부분 대체 — ADR-028:** 전용 Coordinator·고정 상태 전이·correction/rerun 예산을
> 폐기한다. 승인 범위의 자율 작업, 필요한 사용자 결정과 필수 evidence는 유지한다.

**상태**: 현재 [agent 운영 계약](SOLVER_AGENT_DESIGN.md)의 기록.
ADR-012의 계획·실행·검증 계층을 보완하며 specialist의 계약 소유권을 변경하지 않는다.

**결정**: Coordinator만 상태를 전이하고 specialist는 할당된 전문 판단과 산출물을
반환한다. 승인된 scope 안의 일반 작업에는 반복 승인 gate를 추가하지 않고 critical
decision만 사용자에게 요청한다. 계획 요청 자체는 실행 권한이 아니다.

동일 normalized `retry_key`의 correction은 한 번으로 제한하고 이후 Implementation
rerun을 한 번 수행한다. Executor transport attempt와 이를 혼용하지 않는다.
필수 evidence가 누락·실패·stale이면 통과시키지 않는다.

**이유**: 일상적인 handoff의 승인 병목을 줄이면서 제품 의미와 외부 권한을 사람이
통제하고, 같은 실패를 무한 반복하지 않게 한다.

**트레이드오프**: Owner, revision, evidence와 실패 signature를 명확히 기록해야 한다.
Release readiness가 외부 게시나 배포 권한을 주지는 않는다.

### ADR-025: 프로젝트 기준과 Feature 문서의 원본·소유권을 분리한다

> **부분 대체 — ADR-028:** 관리 문서 4개·coordination 상태 원본·필수 requirements
> 분리·전체 bundle 인계를 폐기한다. 프로젝트/Feature 경계, 전문 소유권과 원본 구분은 유지한다.

**상태**: 현재 [Feature 문서 관리](FEATURE_DOCUMENTATION.md) 계약의 기록.

**결정**: 프로젝트 PRD·ARCHITECTURE·ADR에는 공통 기준만 둔다. Coordinator는
Feature의 `FEATURED_AGENTS.md`, `PRD.md`, `ADR.md`, `coordination.md`와 문서
목록·링크를 관리하고 specialist는 자신의 전문 본문과 상세 문서를 소유한다.
상태 원본은 `coordination.md`, 상세 요구사항 원본은 `requirements.md`다.

`FEATURED_AGENTS.md`는 자동 로드되는 프로젝트 지침이 아니므로 dispatch와 Harness
step의 입력에 명시한다. 기본·상세 문서는 같은 Feature/revision과 evidence로 연결한다.
일반 Feature 작업에서 프로젝트 기준을 편집하지 않으며 공통 기준 변경은 별도 요청으로 다룬다.

**이유**: 기능 진행 정보가 공통 지침에 누적되거나 요약과 전문 계약이 서로 다른 원본이
되는 것을 방지한다.

**트레이드오프**: 문서 목록과 상대 링크를 관리해야 한다. 대신 원문 복제를 줄이고
upstream 변경의 영향과 stale evidence를 추적할 수 있다.

### ADR-026: Harness의 구성, Git 소유권과 검증 범위를 신뢰 경계로 관리한다

> **부분 대체 — ADR-028:** Executor의 자동 Git·transport·자체 sandbox 통제와 hook
> 검증을 폐기한다. Config/command 신뢰 경계, 사용자 변경 보존과 실제 runtime 권한은 유지한다.

**상태**: 현재 [Harness skill](../.agents/skills/harness/SKILL.md)과
[프로젝트 지침](../AGENTS.md)의 실행 계약 기록. ADR-002의 구체적 실행 구성과
ADR-012의 운영 설명을 보완한다.

**결정**: 명령은 승인된 계획과 프로젝트 설정·preset·실제 metadata에 대조해 선택한다.
Config와 preset은 실행 가능한 입력이며 Hook이나 `shell=False`만으로 side effect가
격리되었다고 보지 않는다.

범위 밖 사용자 변경은 보존해야 하며, Executor는 branch·step 선택·timestamp·path-scoped
commit을 소유한다. 이 결정 당시 구현은 시작 전 clean 검사를 수행하고 비-phase 변경과
phase metadata를 분리했지만, Step의 소스·테스트 소유 경로를 커밋 시점에 검증하지 않았다.
해당 한계와 실패 분류·기록 보존의 후속 보완은 ADR-027을 따른다.
실행 중 동시 편집을 피하고 범위 밖 변경 발견 시 완료 대신 Coordinator로 반환한다.
Transport attempt는 최대 2회이며 구현이나 상위 계약 실패를
transport 문제로 반복하지 않는다. 권한 확대·원격·파괴 작업에는 명시적 승인이 필요하다.

PreToolUse의 파일 존재 검사는 RED evidence가 아니다. Stop의 문서 전용 생략은
유효한 동일 session/turn의 기록된 편집 대상이 모두 저장소 내부 Markdown인 조건에
한정된다. 기록 누락·손상이나 비문서 기록이면 정상 검증 경로를 따르며, shell 쓰기의
완전한 추적을 보장하지 않는다. 생략·미실행을 build/test 통과로 표시하지 않는다.

**이유**: 자동화가 관련 없는 변경을 commit하거나 검증 범위·권한을 과장하는 것을 방지한다.

**트레이드오프**: 실행 전 상태 검사와 명시적인 evidence가 필요하다. 문서 작업의 정적
검토와 production 변경의 필수 실행 검증을 구분하며, 오래된 운영 문서가 현재 계약을
덮어쓰지 않도록 실제 source와 대조한다.

### ADR-027: Harness의 Step 결과와 커밋 범위를 명시적 계약으로 검증한다

> **실행 계약 대체 — ADR-028:** phase Step payload·owned_paths·attempt_history·자동
> commit·transport retry는 더 이상 사용하지 않는다. 실패 증거와 사용자 변경 보존은 유지한다.

**상태**: 사용자 승인된 Harness 보완 계획(실패 상태 보존, 파일 소유권 검증, 환경 오류
분류)에 따른 결정. ADR-026의 실행 경계를 보완하며 solver·Hook·sandbox 권한을 변경하지 않는다.

**결정**: 프로세스 종료 코드와 Step 보고를 함께 판정한다. 명시적 `error/blocked`는
nonzero에서도 사유를 보존하고 자동 재시도하지 않는다. 인식된 sandbox helper 환경 오류는
종료 코드 0에서도 차단한다. 실제 wrapper timeout으로 결과가 미보고된 경우만 최초 포함
최대 두 번 시도하며, 단순 종료 코드 124나 미분류 nonzero를 transport로 추정하지 않는다.
Executor 소유 `attempt_history`는 원래 보고·프로세스 진단·판정을 재시도와 재개 때 보존한다.

Planning은 Step마다 정확한 상대 파일 목록 `owned_paths`를 작성한다. Executor는 신뢰된
목록으로 매 시도 후·stage 전·commit 전의 변경과 staged 경로를 검증하고 rename 양쪽
경로를 확인한다. 범위 위반 시 사용자 변경을 보존하고 재시도·커밋·다음 Step을 중단한다.
기존 완료 이력은 필드 없이 읽되 pending Step은 실행 전에 승인 목록을 보완해야 한다.
구체적인 schema와 복구 절차는 [Harness skill](../.agents/skills/harness/SKILL.md)과
[동작 과정](HARNESS_WORKFLOW.md)을 따른다.

**이유**: 실패를 재시도로 덮어쓰거나 실행 중 나타난 미승인 파일을 자동 커밋하는 일을 막는다.

**트레이드오프**: 실행할 기존 계획의 파일 목록을 준비해야 하고 실패 이력이 누적된다.
경로 검사는 filesystem sandbox나 동시 writer에 대한 원자적 격리가 아니다. 구현·metadata
커밋도 단일 transaction이 아니므로 뒤쪽 커밋 실패 시 앞선 커밋을 보존하고 오류로 반환한다.

<a id="adr-028"></a>

### ADR-028: 메인이 필요한 전문 작업을 조정하고 Harness를 명시적 검증 실행기로 사용한다

**상태**: Accepted. 2026-09-07 사용자가 승인한
[문서 갱신 계획](superpowers/plans/2026-09-07-agent-harness-documentation-update.md)에 따라
Agent·Harness 경량화 결정을 공통 운영 문서에 반영한다. 솔버의 제품·물리·수치·입출력
계약과 외부 실행 권한은 변경하지 않는다.

**결정**:

- 메인 assistant가 작업 분해, 필요한 전문 작업의 위임, 구현 조정과 완료 확인을 맡는다.
  7개 specialist는 필요한 경우에만 호출한다. 고정 stage 순회와 전용
  coordinator/planning/correction/release profile은 사용하지 않는다.
- Harness는 `python scripts/execute.py`로 구성된 build/test를 한 번 명시 실행한다.
  내부 LLM·프롬프트 주입, phase 상태기계, 자동 Git·재시도, 파일명 TDD gate와 대화 종료
  hook은 사용하지 않는다. 기존 phase와 coordination 기록은 이력으로 보존한다.
- 동작 변경은 의미 있는 테스트로 검증하고, 버그는 가능한 경우 재현한 뒤 최소 수정한다.
  개발 중 관련 검사를 수행하며 솔버 기능 완료 시 전체 build/test와 필수 reference 비교를
  한 번 수행한다. 이후 변경·실패가 없으면 반복하지 않는다. 수식·요소·재료·적분·상태
  갱신 변경의 독립 수치 검토와 필요한 analytical/invariant·물리 검증은 유지한다.
- 관련 입력 경로/절, 작업·수정 범위와 검증 기준만 인계하고 결과·변경 파일·검사·미해결
  항목을 간결하게 반환한다. 일반 역할은 `medium`, 정식화·수치·물리 역할은 `high`를
  기본으로 하며 난해한 작업에만 필요한 범위에서 높인다.
- Feature를 초기화하면 메인이 `FEATURED_AGENTS.md`, `PRD.md`, `ADR.md`를 관리한다.
  현재 checklist와 작은 요구사항의 원본은 PRD에 둔다. 필요한 상세 계약·결과만 분리하여
  연결하고 간단한 구현·build/test·reference evidence는 하나의 보고서에 기록한다.
  Release-readiness 감사는 사용자가 명시적으로 요청할 때만 수행한다.

기존 Feature를 재개할 때 삭제된 profile·phase 실행 절차에는 이 결정을 적용하고,
승인된 제품 범위·수치 계약·필수 검증과 명시 요청된 감사는 해당 Feature 계약으로 유지한다.
메인은 남은 작업과 기존 근거 링크만 Feature PRD의 현재 checklist에 정리한다.
과거 coordination·phase·실패 기록을 재작성하거나 새 runner 입력으로 변환하지 않는다.
운영 전환만으로 기존 evidence가 새로 검증되었거나 실제 blocker가 해결되었다고 표시하지 않는다.

이 결정은 ADR-012·024~027의 위에 표시한 운영 부분을 대체한다. Config·preset·실행
command는 검토해야 할 실행 입력이며 `shell=False`나 경로 검사가 그 side effect를
sandbox처럼 격리하지는 않는다. 사용자 변경·reference를 보존하고 미실행·실패·stale
evidence를 통과로 표시하지 않는 원칙, 실제 도구 권한과 외부 작업의 명시적 승인은 유지한다.

**이유**: 반복적인 문맥 주입, 역할 전환, 형식적 보고와 중복 검증을 줄이면서 필요한
공학적 판단과 재현 가능한 evidence에 집중한다.

**트레이드오프**: 고정 상태기계나 자동 Git gate가 완료·변경 범위를 강제하지 않으므로
메인이 할당 범위, 필요한 검증과 미해결 항목을 확인한다. 명령 실패의 원인은 현재 구현
owner가 수정하며 새 근거나 변경 없이 같은 명령·agent 호출을 반복하지 않는다.

역할과 호출 조건은 [Agent 운영](SOLVER_AGENT_DESIGN.md), skill 적용은
[Skill 설계](SOLVER_SKILL_DESIGN.md), 문서 원본과 소유권은
[Feature 문서 관리](FEATURE_DOCUMENTATION.md), CLI·설정과 실패 진단은
[Harness](HARNESS.md) 및 [동작 과정](HARNESS_WORKFLOW.md)을 따른다.

## 후속 ADR 작성 기준

프로젝트 전체의 dependency 방향, 공통 identity·수명·결과 의미, 기술 baseline,
검증 정책 또는 agent 권한이 바뀌면 공통 ADR을 추가한다. 하나의 구현 항목에만
적용되는 선택은 Feature ADR에 기록한다.

각 결정에는 ID, 적용 범위, 상태, 결정, 이유, 트레이드오프, 근거와 영향받는 계약을 둔다.
기존 결정을 변경하면 명시적인 대체·보완 관계와 승인 근거를 남기며 과거 원문과 실패
evidence를 소급 수정하지 않는다. Feature 기록의 형식과 owner는
[FEATURE_DOCUMENTATION](FEATURE_DOCUMENTATION.md)을 따른다.