docs: align guidance with simplified agent and harness workflow

docs/ARCHITECTURE.md

@@ -37,13 +37,13 @@ Solver runtime
                                     └─ numerical backend
 
 개발 운영 영역
-사용자 요구 → Coordinator → 담당 specialist → 산출물과 evidence → gate 판정
-                               │
-                               └─ 할당된 계획 / Harness / 코드·테스트·문서 변경
+사용자 요구 → 메인 assistant → 필요한 전문 작업·구현 → 검증·결과 확인
+                                   │
+                                   └─ 명시적 Harness / 코드·테스트·문서 변경
 ```
 
 첫 흐름은 해석 데이터의 전달을, 두 번째는 개발 작업과 검증의 흐름을 나타낸다.
-Agent, prompt, phase 파일과 Harness는 solver runtime API나 물리 모델의 일부가 아니다.
+Agent, skill과 Harness는 solver runtime API나 물리 모델의 일부가 아니다.
 개발 운영 영역은 저장소의 변경과 검증을 통제하며 solver가 실행 중 이를 호출하지 않는다.
 
 ## 공통 책임과 의존성
@@ -193,8 +193,10 @@ Diagnostic은 실패 단계, 안정된 code와 메시지, 가능한 source locat
 ## 검증과 reference 경계
 
 검증 coverage와 비교량의 논리적 정의는 Numerical Review, 물리량의 저장·외부 대응은
-I/O, 실행 evidence는 Implementation, 독립 물리 판단은 Physics Evaluation이 소유한다.
-각 단계는 상위 계약을 결과에 맞춰 수정하지 않는다.
+I/O, 실행 evidence는 구현 담당자, 독립 물리 판단은 Physics Evaluation의 전문 책임이다.
+메인은 작업에 필요한 전문 판단만 배정하며 고정 stage 순회를 요구하지 않는다. 수식·요소·
+재료·적분·상태 갱신 변경에는 독립 수치 검토와 해당 analytical/invariant 검증을 수행한다.
+각 담당자는 상위 계약을 결과에 맞춰 수정하지 않는다.
 
 - Source identity, location과 component 일치 여부를 수치 tolerance보다 먼저 확인한다.
 - Missing, extra, duplicate와 nonfinite required value를 숨기지 않는다.
@@ -208,50 +210,40 @@ Architecture 문서의 그림이나 모듈명이 기능의 완료 증거를 대
 
 ## 개발 운영 인프라
 
-공통 agent 상태 전이는 [SOLVER_AGENT_DESIGN](SOLVER_AGENT_DESIGN.md), skill의 역할은
-[SOLVER_SKILL_DESIGN](SOLVER_SKILL_DESIGN.md)을 따른다. 실제 실행 절차는
-[Harness skill](../.agents/skills/harness/SKILL.md)과 현재 agent/skill profile을 읽는다.
+현행 운영은 [ADR-028](ADR.md#adr-028), 역할·인계는
+[SOLVER_AGENT_DESIGN](SOLVER_AGENT_DESIGN.md), skill 적용은
+[SOLVER_SKILL_DESIGN](SOLVER_SKILL_DESIGN.md)을 따른다. 실행 동작은
+[Harness skill](../.agents/skills/harness/SKILL.md)과 현재 source·config에 대조한다.
 
 | Owner | 책임 |
 | --- | --- |
-| Coordinator | Feature 문서 목록·상태, dispatch, evidence gate, revision·retry budget과 closure |
-| Specialist | 할당된 stage의 전문 판단, 기본·상세 산출물과 공통 handoff |
-| Planning Agent | 할당된 implementation plan과 phase/index/step 계획 파일 |
-| Executor | 현재 step 선택, branch, transport attempt, timestamp, path-scoped commit과 phase 진행 |
-| Implementation Agent | 선택된 step의 코드·테스트·보고서와 result payload |
-| Hook | 도구 호출 전 guardrail과 설정된 종료 검증; TDD 관찰이나 완전한 sandbox의 대체가 아님 |
+| 메인 assistant | 범위·작업 분해, 필요한 전문 작업 배정, 직접 계획·구현·수정, Feature context와 완료 evidence 확인 |
+| Specialist | 할당된 전문 판단·파일과 간결한 결과; 상위 계약 문제를 owner와 메인에 전달 |
+| 구현 담당자 | 메인 또는 implementation-agent로서 코드·테스트·관련 검증과 필요한 reference evidence 작성 |
+| Harness runner | 명시 호출 시 config·project·toolchain 선택, adapter 계획 실행과 결과 반환 |
+| Backend adapter/process | CMake/CTest 또는 MSBuild 명령 구성, argv/cwd·timeout·실패·결과 검사 |
 
-Coordinator만 workflow를 전이한다. Specialist의 outcome은 전이 요청이고, Harness의
-step 상태는 별개의 실행 상태다. Executor transport attempt는 최대 2회이며 동일
-`retry_key`의 correction 1회와 뒤따르는 Implementation rerun은 Coordinator가 관리한다.
-두 budget을 혼용하거나 실패 문구만 바꿔 반복하지 않는다.
+Runner는 내부 LLM, phase 상태기계, 자동 Git·retry, 파일명 TDD gate나 대화 종료 hook을
+사용하지 않는다. 과거 phase/coordination 기록은 이력으로 보존한다. 일반 실패는 현재
+구현 owner가 수정하며 새 근거나 변경 없이 같은 명령·agent 호출을 반복하지 않는다.
 
-승인된 scope와 할당된 작업 안의 일반 계획·문서·local 실행에는 반복 승인 gate를
-추가하지 않는다. 계획 요청만으로 실행을 시작하지 않으며 외부 solver, 원격·파괴 작업과
-sandbox 권한 확대에는 해당 명시적 권한이 필요하다.
+Project config·preset·command는 검토해야 할 실행 입력이다. Repository 경로 검사,
+`shell=False`와 timeout이 실행 파일의 side effect를 모두 격리하는 sandbox는 아니다.
+사용자 변경을 보존하고 실제 도구 권한과 외부 solver·원격·파괴 작업의 명시적 승인을 따른다.
+승인된 일반 작업에 반복 승인을 추가하지 않으며 계획 요청만으로 실행을 시작하지 않는다.
 
-Project config, preset과 실행 command는 검토해야 하는 실행 입력이다. Hook 통과나
-구조화된 argument list만으로 그 side effect가 격리되었다고 간주하지 않는다.
-Executor는 시작 전 선택된 phase 제어 파일 밖의 변경을 거부하며 모든 pending Step의
-Planning 소유 `owned_paths`를 검증한다. 매 시도 후와 stage/commit 경계에서 신뢰된 목록과
-변경·staged 경로를 대조하고 구현 변경과 phase metadata를 분리한다. 범위 밖 변경은
-보존하고 재시도·커밋·다음 Step을 중단한다. 이 검사는 동시 writer의 원자적 격리나 여러
-커밋의 단일 transaction을 보장하지 않는다. 실행 중 동시 편집을 피한다.
-종료 코드와 Step 보고 상태를 함께 판정하며 명시적 실패를 transport 재시도로 덮어쓰지
-않는다. 실제 wrapper timeout이고 결과 미보고일 때만 최초 포함 최대 두 번 시도한다.
-환경·실패 진단과 원래 보고는 Executor 소유 `attempt_history`에 남기고 재개 때 보존한다.
-등록된 Hook을 수동 실행하여 검증 evidence를 대신하지 않는다.
-
-문서 전용 Stop 생략은 기록된 동일 session/turn의 허용된 편집 대상이 모두 저장소 내부
-Markdown인 조건에 한정된다. 기록이 없거나 불완전한 읽기 전용 작업과 shell 쓰기까지
-안전하게 분류한다고 가정하지 않는다. 생략은 build/test 통과가 아니다.
-사용자가 실행을 제외한 문서 작업은 정적 검토와 미실행 항목을 보고한다.
+변경 중에는 관련 검사를, 솔버 기능 완료 시에는 구성된 전체 build/test와 계약상 필수
+reference 비교를 한 번 수행한다. 요청이나 넓은 영향으로 전체 검증이 필요한 경우에도
+실행하고 이후 변경·실패가 없으면 반복하지 않는다. 문서 작업은 정적 검토로 확인한다.
+명령·exit code·판정값과 미실행 항목을 필요한 보고서에 기록하며 Harness 성공만으로
+물리·수치 correctness나 외부 release readiness를 선언하지 않는다.
 
 ## 문서와 아키텍처의 변경
 
 프로젝트 공통 원칙의 변경은 공통 ADR로, 구현 항목별 선택은 해당 Feature ADR로
-기록한다. Feature PRD는 범위와 acceptance 요약을, requirements·formulation·I/O는
-전문 계약의 원본을 소유한다. 관리 문서와 기본·상세 산출물은
+기록한다. Feature PRD는 범위·작은 요구사항·acceptance와 현재 checklist의 원본이다.
+복잡한 requirements·formulation·I/O는 필요한 경우에만 전문 문서로 분리하고 PRD에서
+참조하여 원본을 중복하지 않는다. 메인이 관리하는 핵심 문서 3개와 선택적 상세 산출물은
 [FEATURE_DOCUMENTATION](FEATURE_DOCUMENTATION.md)의 소유권과 링크 규칙을 따른다.
 
 Public dependency, identity, 수명, result meaning이나 lifecycle 변경은 영향받는