onto-mcp 0.3.0

package/.onto/processes/review/productized-live-path.md

@@ -0,0 +1,398 @@
+# Review Productized Live Path
+
+> 상태: Active
+> 목적: `검토 (review)`의 `제품화된 실시간 경로 (productized live path)`를 canonical 실행 경로로 고정한다.
+> 기준 문서:
+> - `.onto/processes/review/interpretation-contract.md`
+> - `.onto/processes/review/binding-contract.md`
+> - `.onto/processes/review/lens-prompt-contract.md`
+> - `.onto/processes/review/synthesize-prompt-contract.md`
+> - `.onto/processes/review/record-contract.md`
+> - `.onto/processes/review/record-field-mapping.md`
+> - `.onto/processes/review/execution-preparation-artifacts.md`
+> - `.onto/processes/review/prompt-execution-runner-contract.md`
+> - `.onto/processes/review/issue-stance-deliberation-contract.md`
+> - `.onto/processes/review/review-context-manifest-contract.md`
+> - `.onto/processes/review/pre-dispatch-contracts.md`
+> - `.onto/processes/review/review-execution-ux-contract.md`
+> - `.onto/authority/core-lexicon.yaml`
+
+---
+
+## 1. Position
+
+이 문서는 `검토 (review)`의 현재 canonical live execution truth다.
+
+즉 실제 productization target은 이 문서의 순서를 따른다.
+
+live path authority는 이 문서와 하위 review contracts가 가진다.
+
+---
+
+## 2. Canonical Live Path
+
+```text
+user request
+-> 호출 해석 (InvocationInterpretation)
+-> 주체자 확인 / 선택 확정
+-> 호출 고정 (InvocationBinding)
+-> execution preparation artifacts
+-> 9개 lens 독립 실행
+-> 통제된 lens 숙의 (controlled lens deliberation)
+-> 종합 단계 (synthesize)
+-> human-readable final output
+-> 리뷰 기록 (ReviewRecord)
+```
+
+---
+
+## 3. Step-by-Step
+
+### 3.1 주체자 요청 수집
+
+host가 아래를 받는다.
+
+- 주체자 자연어 요청
+- explicit target token
+- explicit domain token
+- explicit execution profile token
+- 현재 repo / selected target context
+
+### 3.2 호출 해석 (InvocationInterpretation)
+
+`LLM`이 아래를 해석한다.
+
+- entrypoint가 `review`인지
+- `검토 대상 범위 (review_target_scope)` 후보가 무엇인지
+- intent가 무엇인지
+- domain recommendation이 필요한지
+- `lens 선택 계획 (LensSelectionPlan)`이 무엇인지
+- `core-axis/full` recommendation이 필요한지
+
+prompt-backed path에서도 이 단계의 결과는 최종적으로
+`interpretation.yaml`로 materialize되어야 한다.
+
+### 3.3 주체자 확인 / 선택 확정
+
+필요한 경우 아래를 주체자와 확정한다.
+
+- `도메인 최종 선택 (DomainFinalSelection)`
+- `core-axis/full`
+- explicit override
+
+이 단계는 semantic recommendation과 deterministic binding의 중간에서
+주체자가 최종 authority를 행사하는 구간이다.
+
+현재 host-facing `review:invoke`의 기본 규칙:
+
+- explicit `--domain {name}` / `--no-domain` 이 있으면 그대로 사용
+- configured domain이 하나면 바로 사용
+- configured domain이 여러 개면 interactive selection을 수행
+- interactive selection이 불가능한 non-interactive 환경이면 fail-fast 하고 explicit domain selection을 요구
+- `--domain` 과 `--no-domain` 동시 지정은 parser layer 에서 fail-fast
+
+### 3.4 호출 고정 (InvocationBinding)
+
+runtime/host가 아래를 고정한다.
+
+- resolved target scope
+- final domain value
+- resolved execution realization
+- resolved host runtime
+- resolved review mode
+- resolved lens set
+- session root
+- artifact paths
+
+이 단계가 끝나면 prompt-backed path에서도
+적어도 `session_root`와 각 artifact path는 확정되어 있어야 한다.
+
+현재 bounded runtime step은 TypeScript core로 구현한다.
+
+Preferred repo-local combined entrypoint는 아래다.
+
+- `npm run review:invoke -- ...`
+
+기본 bounded start step은 아래다.
+
+- `npm run review:start-session -- ...`
+
+`review:start-session` 내부에서 interpretation, binding, execution preparation,
+prompt packet materialization을 순서대로 수행한다.
+
+### 3.5 Execution Preparation Artifacts
+
+binding 다음에는 최소 아래 artifact가 materialize되어야 한다.
+
+1. `session metadata`
+2. `target snapshot`
+3. `review target materialized input`
+4. `context candidate assembly`
+5. `execution plan`
+6. `actor invocation profiles`
+7. `actor consumer bindings`
+8. `domain binding`
+9. `review value-alignment criteria`
+10. `review context manifest`
+11. `prompt packets`
+12. `execution result`
+
+이 단계는 later `ReviewRecord`와 runtime replacement의 bridge다.
+
+세부 contract는 `.onto/processes/review/execution-preparation-artifacts.md`를 따른다.
+dispatch 전에 닫혀야 하는 gate와 phase boundary는
+`.onto/processes/review/pre-dispatch-contracts.md`를 따른다.
+
+prompt-backed path에서도 실제 파일이 만들어져야 한다.
+즉 이 단계는 단순 개념 설명이 아니라 artifact materialization step이다.
+
+`execution plan`은 아래를 deterministic하게 고정한다.
+
+- lens별 output seat
+- `synthesis.md` seat
+- `deliberation.md` seat
+- lens별 deliberation response seat
+- `error-log.md` seat
+- `final-output.md` seat
+- `review-record.yaml` seat
+- `execution-result.yaml` seat
+- boundary seat
+  - `BoundaryPolicy`
+  - `BoundaryPresentation`
+  - `BoundaryEnforcementProfile`
+  - `EffectiveBoundaryState`
+
+`prompt packets`는 아래를 deterministic하게 고정한다.
+
+- lens별 prompt handoff text
+- `synthesize` prompt handoff text
+- 각 packet이 읽어야 할 artifact path
+- 각 packet이 써야 할 output path
+- packet은 가급적 lightweight handoff여야 하며, authoritative artifact의 전체 본문을 과도하게 embedded하지 않는다
+- `맥락 격리 추론 단위 (ContextIsolatedReasoningUnit)`는 packet이 가리키는 artifact file을 직접 읽는다
+- synthesize runtime packet은 participating lens output의 seat/ref를 넘기되, 가능하면 본문 전체를 다시 중복 embedded하지 않는다
+- packet은 boundary policy와 effective boundary state를 함께 제시해, 허용된 탐색 공간과 강제 강도를 분명히 해야 한다
+
+### 3.6 9개 lens 독립 실행
+
+각 lens는 **맥락 격리 추론 단위 (ContextIsolatedReasoningUnit)** 로 실행된다.
+
+가능하면 host는 자유 텍스트 대신 TS core가 materialize한 prompt packet을 사용해야 한다.
+기본 bounded dispatch step은 아래다.
+
+- `npm run review:run-prompt-execution -- ...`
+
+이 step은 실행 종료 시 `execution-result.yaml`을 반드시 materialize해야 한다.
+
+canonical requirement:
+
+1. 각 lens는 자기 전용 맥락을 가진다
+2. Round 1에서는 다른 lens 결과를 보지 않는다
+3. 메인 `LLM` 콘텍스트는 per-lens detailed reasoning을 직접 모두 담지 않는다
+4. 각 실행 단위는 packet에 제시된 `BoundaryPolicy`와 `EffectiveBoundaryState`를 hard constraint로 읽는다
+5. 경계 안에서 충분한 근거를 얻지 못하면 broad search로 타협하지 않고 degraded/uncertain output을 남긴다
+6. lens dispatch는 병렬 실행이 기본이다
+7. runtime은 선택된 lens 전체를 dispatch한다. host가 자체 제한으로 이를 수행할 수 없으면 fail-loud하게 중단한다
+
+현재 repo-local TS bounded path에서 연결된 `ReviewExecutionProfile` mode는 아래다.
+
+- `main-workers`: main이 teamlead 역할을 수행하고 worker가 lens를 실행한다.
+- `nested-workers`: worker teamlead가 nested worker lens를 실행한다. `teamlead.llm`은 outer worker에, `lens.llm`은 inner lens worker에 각각 적용된다.
+- `synthesize.llm`: deliberation 이후 별도 synthesize unit에 적용된다. synthesize는 모든 lens output, issue artifacts, deliberation, problem framing을 통합하므로 높은 effort가 기본적으로 적합하다.
+
+worker executor는 profile resolution에서 아래 중 하나로 고정된다.
+
+- `codex`: host-bound OAuth 또는 Codex worker path.
+- `direct_call`: `api_key` 또는 `local` provider path.
+- `mock`: `ONTO_LLM_MOCK=1` 또는 explicit test override.
+
+중요한 점은 host-specific naming이 아니라:
+
+- `lens별 독립성`
+- `메인 콘텍스트 보존`
+- `독립 의미 검증`
+
+이 유지되는 것이다.
+
+packet materialization만 단독으로 디버깅해야 할 때는 아래 내부 bounded step을 쓸 수 있다.
+
+- `npm run review:materialize-prompt-packets -- ...`
+
+현재 TS bounded runner의 lens 병렬성은 선택된 lens 수와 같다. full review는
+9개 lens를 모두 병렬 dispatch하고, core-axis 또는 명시적 lens 선택은 해당 lens
+전체를 병렬 dispatch한다.
+
+Round 1 이후에는 `lens-completion-barrier.yaml`이 작성되어야 한다.
+canonical review path는 선택된 lens 전원이 완료되고, 선택된 lens 수가 최소 2개일 때만
+issue artifacts, controlled deliberation, synthesize로 진행한다.
+
+### 3.7 통제된 lens 숙의 (Controlled Lens Deliberation)
+
+Round 1 lens 결과가 나온 뒤, review는 반드시 통제된 lens 숙의 단계를 거친다.
+
+이 단계의 목적은 `synthesize`가 혼자 충돌을 판정하는 것이 아니라,
+서로 다른 관점의 lens가 teamlead가 제한한 context 안에서 자기 입장을 재평가하고,
+teamlead deliberation result가 합의/조건부 합의/지속 이견을 명시하게 하는 것이다.
+
+canonical requirement:
+
+1. 각 lens deliberation response는 fresh bounded context에서 실행된다.
+2. 입력은 해당 lens의 Round 1 결과와 다른 participating lens 결과로 제한된다.
+3. lens는 최종 종합을 수행하지 않고 자기 관점의 유지/수정/양보/지속 이견만 기록한다.
+4. teamlead-controlled deliberation result는 모든 lens response를 읽고 `deliberation.md`를 작성한다.
+5. `deliberation.md`는 synthesize보다 앞선 authoritative conflict-resolution artifact다.
+6. `synthesize`는 이 결과를 소비하며, 독자적으로 새 resolution을 만들지 않는다.
+
+MCP/TS runtime에서는 이 의미론을 provider 독립적인 controlled deliberation packet으로 실현한다.
+중요한 것은 기능명이 아니라 `분리된 관점 + 제한 context + teamlead 통제 + 기록 가능한 resolution`이다.
+
+#### 3.7.1 Issue-Stance Deliberation Target
+
+다음 runtime target은 `.onto/processes/review/issue-stance-deliberation-contract.md`를 따른다.
+
+목표 구조:
+
+```text
+Round 1 lens outputs
+-> finding-ledger.yaml
+-> finding-relation-graph.yaml
+-> issue-ledger.yaml
+-> issue-stance-matrix.yaml
+-> deliberation-plan.yaml
+-> issue-scoped controlled deliberation
+-> deliberation.md
+-> common spine + domain problem framing profile
+-> problem-framing.yaml
+-> synthesize
+```
+
+핵심 invariant:
+
+1. 모든 surface finding은 finding ledger에 등록된다.
+2. finding 간 관계를 검토해 root-cause issue cluster를 만든다.
+3. 모든 participating lens는 모든 root-cause issue에 대해 stance를 남긴다.
+4. material conflict가 있는 issue만 deliberation에 진입한다.
+5. deliberation은 서로 다른 입장의 이유와 root-cause 해석 차이, stance 유지/변경 여부를 확인한다.
+6. issue별 결론은 `no-deliberation-needed`, `resolved`, `narrowed`, `unresolved-with-reason` 중 하나다.
+7. review closure는 `problem-framing.yaml`에서 공통 spine과 선택된 domain profile 기반 분류를 기록한다.
+8. domain별 분류 축은 `.onto/domains/{domain}/problem_framing_profile.md`가 소유한다.
+9. `synthesize`는 issue status와 common spine/domain axes classification을 변경하지 않고 보존적으로 렌더링한다.
+
+### 3.8 종합 단계 (synthesize)
+
+`synthesize`는 lens finding을 읽고 아래를 정리한다.
+
+- consensus
+- conditional consensus
+- disagreement
+- overlooked premises
+- immediate actions
+- recommendations
+- final review result
+
+중요:
+
+- `synthesize`는 새 독립 관점을 만들지 않는다
+- `synthesize`는 deliberation actor가 아니다
+- 충돌 resolution의 authority는 `deliberation.md`다
+- `New Perspectives`는 `axiology`가 제시하는 영역이다
+- synthesize는 `axiology`가 제시한 추가 관점이 있으면 그것을 보존/배치할 수는 있지만, 스스로 invent하면 안 된다
+
+### 3.9 리뷰 기록 (ReviewRecord)
+
+`review`의 primary output은 `리뷰 기록 (ReviewRecord)`다.
+
+최종 human-readable output은 먼저 render될 수 있지만,
+later `learn/govern`가 읽을 canonical artifact는 `ReviewRecord`여야 한다.
+
+즉:
+
+- lens markdown
+- deliberation markdown
+- synthesis markdown
+
+은 최종적으로 `ReviewRecord`의 source/human-readable layer로 내려간다.
+
+세부 contract는 `.onto/processes/review/record-contract.md`를 따른다.
+
+prompt-backed path에서는 `final-output.md`를 먼저 render한 뒤,
+team lead 또는 bounded TS step이 마지막에 `review-record.yaml`을 actual aggregate로 assemble해야 한다.
+
+Preferred repo-local combined completion 포함 entrypoint는 아래다.
+
+- `npm run review:invoke -- ...`
+
+기본 bounded completion step은 아래다.
+
+- `npm run review:complete-session -- ...`
+
+필요하면 아래 분해된 step도 내부 bounded step으로 사용할 수 있다.
+
+- `npm run review:render-final-output -- ...`
+- `npm run review:finalize-session -- ...`
+
+### 3.10 Human-Readable Final Output
+
+주체자에게 보여주는 최종 review output은
+`ReviewRecord`와 synthesis result를 기반으로 render된 결과다.
+
+즉 사람이 읽는 결과와
+later system handoff artifact를 분리한다.
+
+기본 bounded render step은 아래다.
+
+- `npm run review:render-final-output -- ...`
+
+중요:
+
+- degraded case가 발생하면 `review:run-prompt-execution`은 `degradation-summary.yaml`을 구조화 source로 기록하고 `error-log.md`에는 실행 로그를 남긴다
+- `review:complete-session`은 `final-output.md`와 `review-record.yaml`을 모두 필수 산출물로 취급한다
+- 필수 artifact가 없으면 해당 단계는 즉시 실패한다
+
+### 3.11 Execution UX Presentation Target
+
+Review 진행 UX의 design target은 `.onto/processes/review/review-execution-ux-contract.md`를 따른다.
+
+이 UX contract는 final output만이 아니라 setup, pre-dispatch readiness, lens
+execution, issue construction, controlled deliberation, synthesize, halted partial
+result 전 구간에서 주체자가 판단 가능한 상태를 받도록 하는 presentation target이다.
+
+현재 active runtime truth는 기존 artifacts와 CLI/MCP 결과가 소유한다.
+`onto.review_status`는 artifact-backed `llmPresentation.progress`를 반환하며,
+그 안에는 polling liveness state, latest review signal, progress stepper가
+포함된다. halted partial일 때는 `llmPresentation.halt`도 반환한다. completed result는
+`llmPresentation.finalResult`, `final-output.md`, `review-record.yaml`에서 같은
+result classification projection을 노출한다.
+Progress step id/label/total truth는 runtime review progress contract와
+`review-run-manifest.yaml.execution_contract`가 소유한다.
+
+Severity/result classification은 runtime active projection이다. Projection source는
+`finding-ledger.yaml`, `issue-ledger.yaml`, `problem-framing.yaml`,
+`execution-result.yaml`이다.
+
+Target rules:
+
+- `severity`가 finding의 materiality boundary를 포함한다
+- `blocker`, `high`, `medium`은 material issue로 파생된다
+- `low`, `info`는 non-material finding 또는 evidence observation이다
+- 모든 material issue는 affected purpose, failure condition, impact, evidence refs를 가져야 한다
+- 시작 시점에는 환경, 방식, non-secret 모델/profile, 도메인, target, review direction을 짧게 제시해야 한다
+- 긴 실행 중에는 stepwise/progress-bar 형태로 진행 상태와 새로 수집된 review 정보를 함께 제시해야 하며, 새 정보가 없더라도 bounded liveness update를 제공해야 한다
+- issue-stage artifact가 생성되면 progress update는 finding/issue count, highest severity, material issue count 같은 새 review signal을 함께 제시해야 한다
+- 중간 finding-like update는 `lens_local`, `issue_candidate`, `deliberation_pending`, `deliberated`, `finalized` 같은 interim signal status를 표시해야 한다
+- halted partial result는 halt identity와 produced/absent artifact truth를 먼저 보여줘야 한다
+- CLI가 보이지 않는 MCP/host 환경에서는 `onto.review_status` polling을 기본 경로로 host LLM presentation input을 갱신해야 한다
+- 별도 HTML/UI 구현은 요구하지 않는다. CLI, MCP, `final-output.md`, `review-record.yaml`은 같은 bounded facts를 제시해야 한다
+
+---
+
+## 4. Immediate Follow-up
+
+이 문서의 productized live path는 현재 MCP `onto.review`에서
+`review:invoke`를 통해 `review:start-session`, `review:run-prompt-execution`,
+`review:complete-session` bounded steps를 유지한다.
+
+남은 follow-up은 live path 자체의 구조 변경이 아니라 운영/확장 품질이다.
+
+1. provider credentials/endpoints가 의도적으로 준비된 환경에서 provider별 live conformance를 수행한다.
+2. replay, stale artifact, partial worker, duplicate-dispatch semantics가 닫힌 뒤 explicit resume command를 설계한다.

package/.onto/processes/review/prompt-execution-runner-contract.md

@@ -0,0 +1,187 @@
+# Review Prompt Execution Runner Contract
+
+> 상태: Active
+> 목적: `execution-plan.yaml`과 `prompt-packets/*.prompt.md`를 읽고, 각 `맥락 격리 추론 단위 (ContextIsolatedReasoningUnit)`를 deterministic하게 dispatch하는 bounded runtime contract를 고정한다.
+> 기준 문서:
+> - `.onto/processes/review/productized-live-path.md`
+> - `.onto/processes/review/lens-prompt-contract.md`
+> - `.onto/processes/review/synthesize-prompt-contract.md`
+> - `.onto/processes/review/record-contract.md`
+> - `.onto/processes/review/pre-dispatch-contracts.md`
+> - `.onto/authority/core-lexicon.yaml`
+
+---
+
+## 1. Position
+
+이 contract는 runtime이 `LLM` 대신 의미 판단을 수행한다는 뜻이 아니다.
+
+runtime은 아래만 한다.
+
+1. `execution-plan.yaml`을 읽는다
+2. lens/deliberation/synthesize prompt packet seat를 확인한다
+3. 각 lens packet을 병렬로 외부 실행 단위에 deterministic하게 전달한다
+4. 각 output seat에 실제 결과 파일이 생성되었는지 검사한다
+5. 기준 미달이면 `fail-close` 한다
+6. `EffectiveBoundaryState`를 `error-log.md`와 degraded 판단의 구조적 basis로 남긴다
+7. Round 1 완료 후 `lens-completion-barrier.yaml`을 작성한다
+
+추가로 synthesize dispatch 직전에는 runtime이
+participating lens output과 controlled deliberation result의 seat/ref를 synthesize runtime packet에 반영할 수 있다.
+이건 새로운 semantic 판단이 아니라,
+이미 존재하는 lens 결과 seat를 declared handoff에 맞게 전달하는 deterministic handoff다.
+
+즉 이 runner는:
+
+- `결정론적 계약 실행기 (deterministic contract executor)`
+- `구조 적합성 게이트 (structural conformance gate)`
+
+역할만 가진다.
+
+---
+
+## 2. Inputs
+
+최소 입력:
+
+1. `project_root`
+2. `session_root`
+3. `execution-plan.yaml`
+4. `prompt-packets/{lens}.prompt.md`
+5. `prompt-packets/{lens}.deliberation.prompt.md`
+6. `prompt-packets/teamlead.deliberation.prompt.md`
+7. `prompt-packets/synthesize.prompt.md`
+8. executor realization
+   - `worker`
+   - `direct-call`
+9. host runtime
+   - `codex`
+   - `openai`
+   - `anthropic`
+   - `grok`
+   - `lmstudio`
+   - `standalone`
+10. selected lens count
+
+중요:
+
+- runtime은 packet 내용을 해석하지 않는다
+- packet과 output seat를 외부 실행 단위에 전달만 한다
+- lens dispatch order는 deterministic하게 유지하되, 실행은 bounded parallel이어야 한다
+
+---
+
+## 3. Outputs
+
+최소 출력:
+
+1. `round1/{lens}.md`
+2. `deliberation/round1/{lens}-deliberation.md`
+3. `deliberation.md`
+4. `synthesis.md`
+5. `execution-result.yaml`
+6. `error-log.md`
+
+원칙:
+
+- lens output seat는 `execution-plan.yaml`이 고정한다
+- deliberation output seat는 `execution-plan.yaml`이 고정한다
+- synthesize output seat도 `execution-plan.yaml`이 고정한다
+- `execution-result.yaml`은 actual execution truth의 canonical seat다
+- `lens-completion-barrier.yaml`은 downstream stage 진입 gate다
+- degraded case / partial failure는 `error-log.md`에 기록해야 한다
+- `error-log.md`는 최소 한 번 `EffectiveBoundaryState`를 기록해야 한다
+- `error-log.md`는 runner progress seat도 겸할 수 있다
+- runner는 seat를 바꾸면 안 된다
+- `execution-result.yaml`은 최소 아래를 담아야 한다
+  - planned/participating/degraded/excluded lens ids
+  - per-unit started/completed timestamps
+  - per-unit duration
+  - deliberation execution status
+  - synthesize execution status
+  - halt reason
+
+---
+
+## 4. Canonical Bounded Step
+
+현재 TS core bounded step:
+
+```bash
+npm run review:run-prompt-execution -- \
+  --project-root {project_root} \
+  --session-root {session_root} \
+  --executor-bin {executor_bin} \
+  --executor-arg {executor_arg}
+```
+
+옵션:
+
+- `--synthesize-executor-bin`
+- `--synthesize-executor-arg`
+
+를 통해 synthesize만 다른 realization으로 분리할 수 있다.
+
+현재 repo-local actual realization 예:
+
+```bash
+npm run review:run-prompt-execution -- \
+  --project-root {project_root} \
+  --session-root {session_root} \
+  --executor-bin npm \
+  --executor-arg=run \
+  --executor-arg=review:codex-unit-executor \
+  --executor-arg=--
+```
+
+현재 구현에서 prompt execution runner를 통해 실행되는 execution profile:
+
+- `worker + codex` (Codex CLI 경로)
+- `worker + direct-call` (API/local provider 경로)
+- `worker + mock` (conformance/test 경로)
+
+원칙:
+
+- 병렬 실행은 필수다
+- runtime은 선택된 lens 전체를 dispatch한다
+- host adapter가 선택된 lens 전체 dispatch를 보장할 수 없으면 fail-loud하게 중단한다
+- controlled lens deliberation은 participating lens outputs가 확정된 뒤에만 시작한다
+- synthesize는 `deliberation.md`가 생성된 뒤에만 시작한다
+- issue artifacts, controlled deliberation, synthesize는
+  `.onto/processes/review/pre-dispatch-contracts.md §6`의 lens completion barrier가
+  `downstream_allowed=true`일 때만 시작한다
+
+---
+
+## 5. What The Runner Must Not Do
+
+이 runner는 아래를 하면 안 된다.
+
+1. lens 순서를 semantic하게 재조정
+2. packet 내용을 해석해서 수정
+3. synthesize 결과를 임의로 보정
+4. missing output을 추론으로 보완
+5. output이 비어 있는데도 통과
+
+즉 이 단계는 semantic execution engine이 아니라
+semantic execution dispatch engine이다.
+
+packet은 가능하면 lightweight해야 한다.
+runtime은 packet을 giant embedded payload로 만들기보다,
+authoritative artifact path와 output seat를 고정하는 쪽을 우선한다.
+
+또한 runner는 boundary seat를 semantic하게 재해석하지 않는다.
+다만 아래는 해야 한다.
+
+1. `EffectiveBoundaryState`를 log basis로 남긴다
+2. 경계 제약 아래에서 output이 생성되지 않았을 때 degraded/fail-close 경로를 탄다
+
+---
+
+## 6. Immediate Follow-up
+
+다음 단계는 아래다.
+
+1. `review:start-session -> review:run-prompt-execution -> review:complete-session`를 `onto.review`의 canonical bounded runtime path로 유지한다
+2. 실제 host realization이 이 contract를 따르도록 연결한다
+3. provider별 controlled deliberation conformance test를 추가한다