onto-mcp 0.3.0

package/.onto/processes/review/synthesize-prompt-contract.md

@@ -0,0 +1,343 @@
+# Review Synthesize Prompt Contract
+
+> 상태: Active
+> 목적: 현재 `onto` 프로토타입의 `종합 단계 (synthesize)`가 따라야 하는 `종합 프롬프트 계약 (SynthesizePromptContract)`을 고정한다.
+> 기준 문서:
+> - `.onto/processes/review/lens-registry.md`
+> - `.onto/processes/review/lens-prompt-contract.md`
+> - `.onto/processes/review/issue-stance-deliberation-contract.md`
+> - `.onto/authority/core-lexicon.yaml`
+
+---
+
+## 1. Position
+
+`종합 프롬프트 계약 (SynthesizePromptContract)`은
+`synthesize`가 lens finding을 읽고 final review output을 만드는 단계의 공통 실행 계약이다.
+
+이 계약의 source material은 아래다.
+
+- `.onto/roles/synthesize.md`
+- `src/core-runtime/cli/materialize-review-prompt-packets.ts`의 synthesize packet materializer
+- `.onto/processes/review/productized-live-path.md`의 canonical review flow
+
+---
+
+## 2. Core Role
+
+`synthesize`는 독립 lens가 아니다.
+다만 실행 realization은 필요에 따라
+**맥락 격리 추론 단위 (ContextIsolatedReasoningUnit)** 일 수 있다.
+
+역할은 아래다.
+
+1. lens finding을 읽는다
+2. consensus를 정리한다
+3. disagreement를 보존한다
+4. overlooked premises를 드러낸다
+5. immediate actions와 recommendations를 정리한다
+6. final review output을 작성한다
+
+단, purpose/value 관점에서의 추가 검토 관점 제안(`New Perspectives`)은
+`axiology`의 책임이다.
+`synthesize`는 그것이 명시적으로 제시된 경우에만 보존/배치할 수 있다.
+
+---
+
+## 2.1 Language Policy
+
+Synthesis markdown body 는 **English 고정**이다. 본 body 는 `ReviewRecord` 의 source 이며 audit 의 입력이 되므로 runtime translation path를 두지 않는다.
+
+Synthesize 프롬프트 템플릿에는 language setting을 주입하지 않는다. Principal-facing 설명은 synthesis 이후 final output에서 bounded summary와 comprehensive explanation으로 제공한다.
+
+---
+
+## 3. Required Inputs
+
+`종합 프롬프트 계약 (SynthesizePromptContract)`의 최소 입력은 아래다.
+
+1. participating lens list
+2. lens result file paths
+3. system purpose and principles
+4. resolved review mode
+5. materialized input ref (deliberation 시 evidence 재읽기 대상)
+6. `synthesis_output_path`
+7. contracted context refs
+   - participating lens outputs
+   - `deliberation.md`
+   - execution rule refs
+
+### 3.1 Input Expectations (Lens Output Fields)
+
+각 lens result file은 `lens-prompt-contract.md` §8 (schema_version: 2)에 따라
+최소 아래 필드를 포함해야 한다. synthesize는 이 필드들의 수신을 필수로 기대한다.
+
+- **4-field claim**: `{target, evidence_anchor, claim, lens_id}` — 각 finding별
+- **`upstream_evidence_required`**: 해당 시
+- **`domain_constraints_used`**: 해당 시 (durable provenance 형식)
+- **`domain_context_assumptions`**: 해당 시
+
+4필드의 의미와 co-location rule은 `.onto/processes/review/shared-phenomenon-contract.md`가 정의한다.
+이 계약은 수신 필수만 선언하며, 필드 의미를 재정의하지 않는다.
+
+---
+
+## 4. Mandatory Execution Rules
+
+`synthesize`는 아래 규칙을 지켜야 한다.
+
+1. 새로운 독립 관점을 추가하지 않는다
+2. lens finding을 건너뛰고 ad hoc 결론을 만들지 않는다
+3. unresolved disagreement를 묵살하지 않는다
+4. lens 간 disagreement resolution은 synthesize 이전의 controlled lens deliberation 결과를 따른다
+5. review 이후의 learn/govern surface를 정의하지 않는다
+6. `New Perspectives`를 스스로 invent하지 않는다
+7. `Purpose Alignment Verification`은 독립 판단으로 새로 만들지 않고, `axiology` finding을 보존적으로 반영한다
+
+---
+
+## 5. Output Obligation
+
+현재 프로토타입 기준의 synthesize output은 markdown 파일이다.
+
+최소 아래를 포함해야 한다.
+
+또한 output은 YAML frontmatter로 시작해야 하며, 최소 아래 field를 가져야 한다.
+
+```yaml
+---
+deliberation_status: performed
+participation:
+  expected_lenses: [<lens_id>, ...]         # binding 이 active 로 선언한 lens id 목록
+  received_lenses: [<lens_id>, ...]         # output 을 성공적으로 산출한 lens id
+  missing_or_failed_lenses:                 # expected 에 있으나 received 에 없는 lens
+    - { lens_id: <id>, reason: missing | failed | abstained }
+  run_status: full | degraded | insufficient
+---
+```
+
+### 5.1 `deliberation_status` 값 규칙
+
+완료된 synthesize output은 `performed`만 선언한다.
+
+- `performed`: synthesize 이전에 controlled lens deliberation이 실행되었고 synthesize가 그 결과를 소비한 경우.
+
+### 5.2 Participation completeness (IA-2)
+
+- `expected_lenses` / `received_lenses` / `missing_or_failed_lenses` / `run_status` 는 `.onto/roles/synthesize.md` §Participation completeness 가 요구하는 측정 결과의 직렬화다
+- `run_status` 매핑: `full` = expected == received. `degraded` = received 가 expected 의 non-empty 부분집합. `insufficient` = received 가 비어있거나 `axiology` 단독
+- `run_status=insufficient` 이면 consensus / disagreement 섹션은 "data insufficient" marker 로 남기고 합의 claim 을 produce 하지 않는다
+- 이 frontmatter 는 degraded run 을 full consensus 로 오독하는 것을 방지하는 audit 근거다
+
+### 5.2.1 Internal Body vs Final Review Summary (Output Structural Split)
+
+> **Status**: contract established, implementation deferred. 구현 trigger 조건 + scope 는 `.onto/processes/review/lens-prompt-contract.md §8.5` 와 동일 — 본 절은 lens 쪽 contract 의 synthesize 대응을 선언한다.
+
+#### 5.2.1.1 두 층의 경계
+
+| 층 | 섹션 범위 | 소비자 | 언어 정책 |
+|---|---|---|---|
+| **Internal Body** | §5.3 의 section list (1-12 번) 전체 | ReviewRecord assembler, audit | English 고정 |
+| **Final Review Summary** | §5.3 의 items 중 Principal 직접 소비 가치가 있는 subset 의 prose 요약 | Principal | final output stage에서 제공 |
+
+#### 5.2.1.2 Synthesize 특유 rationale
+
+Synthesize 는 Principal 이 **primary 소비자**이지만, 구조 (frontmatter + section list + per-item provenance) 는 ReviewRecord와 audit을 위해 고정되어 있다 (§5.3 canonical taxonomy, §5.5 provenance). 두 소비자를 동시에 서빙하려면:
+
+- Internal Body 는 §5.3 canonical taxonomy + §5.5 per-item provenance 유지 (machine-readable)
+- Final Review Summary 는 Internal Body 의 key findings 을 prose 로 재진술 (human-readable)
+
+본 split 없이 synthesize output 전체를 번역하면 ReviewRecord가 번역된 텍스트 기반이 되어 cross-session 비교가 어려워진다.
+
+#### 5.2.1.3 Contract invariant (구현 시)
+
+- Internal Body section list (§5.3) 는 변경되지 않음
+- Final Review Summary 는 Internal Body 에 없는 claim 도입 금지 (재진술만)
+- lexicon term 취급: canonical identifier 우선 보존
+
+#### 5.2.1.4 ReviewRecord 영향
+
+record-contract §4.5 Synthesis Layer 는 Internal Body 만 source. Final Review Summary 는 final output stage에서 생성하므로 ReviewRecord schema 추가 필드 불필요.
+
+### 5.3 Section list (canonical taxonomy)
+
+아래는 이 contract 가 정하는 **단독 canonical section 명칭** 이다. 동의어는 §5.4 alias map 을 따르며 이 list 로 정규화한다.
+
+1. consensus
+2. conditional consensus
+3. disagreement
+4. overlooked premises
+5. axiology-proposed additional perspectives (if any)
+6. purpose alignment verification
+7. immediate actions
+8. recommendations
+9. unique finding tagging
+10. deliberation decision
+11. final review result — principal-facing comprehensive explanation of the bounded review result. It explains what to conclude from the target/boundary, review target profile, root-cause issue clusters, lens agreement and disagreement, controlled deliberation outcome, problem-framing classification, closure/timing/obligation, and practical next step. It must be grounded in lens outputs and issue artifacts and must not introduce independent findings
+12. shared phenomenon summary — 동일 phenomenon에 대한 다중 lens claim이 있는 경우, claim relation 분류 결과를 명시한다 (corroboration / disagreement / partial overlap / dedup). 분류 규칙은 `.onto/processes/review/shared-phenomenon-contract.md` §4를 따른다. 이 계약은 분류 규칙을 재정의하지 않는다
+
+### 5.4 Alias map (IA-3)
+
+canonical label 과 자주 drift 되는 alias 쌍. synthesis output 은 canonical label 만 사용한다.
+
+| Canonical | Alias (금지) |
+|---|---|
+| `disagreement` | `contradiction`, `conflict` (lens 간 의견 차이 의미일 때) |
+| `conditional consensus` | `conditional agreement`, `conditional agreement (with stipulation)` |
+| `immediate actions` | `recommended actions (urgent)`, `required actions` |
+| `recommendations` | `recommended actions (non-urgent)`, `suggestions` |
+| `axiology-proposed additional perspectives` | `axiology-proposed new perspectives`, `new perspectives` (role header 제외) |
+
+alias 발견 시 synthesis output 은 canonical 로 정규화한다. prompt packet materializer 는 §5.3 label 만 emit 한다.
+
+### 5.5 Per-item provenance (IA-4)
+
+sections 1–12 의 각 item 은 아래 provenance 필드를 갖는다. 명시 형식은 markdown 내 bullet 로 기술한다 (직렬 예시 §5.5.1).
+
+- **supporting_lenses** — 이 item 의 claim 을 지지한 lens id 목록
+- **contesting_lenses** — 이 item 에 대해 반대 claim 을 제기한 lens id 목록. 없으면 빈 배열
+- **adjudication_basis** — 이견이 해소된 경우 `.onto/roles/synthesize.md` §Adjudication boundary 의 3 경로 중 어느 것 (`cited_lens_output` / `declared_rule_resolved_artifact` / `deliberation_artifact`) + 해당 근거 anchor (파일 경로 / lens output 위치). 미해소 시 `unresolved`
+- **evidence_gaps** — 해소에 부족한 증거 영역 (있는 경우, 1~2 문장)
+
+#### 5.5.1 직렬 예시
+
+```markdown
+- **consensus-1**: 모든 lens 가 X 접근이 목적 정렬에 부합한다고 판단한다.
+  - supporting_lenses: [logic, structure, semantics, dependency, pragmatics, evolution, coverage, conciseness, axiology]
+  - contesting_lenses: []
+  - adjudication_basis: cited_lens_output (round1/logic.md §3, round1/structure.md §2, ...)
+  - evidence_gaps: null
+```
+
+### 5.6 Immediate actions priority rule (IA-1)
+
+§5.3 item 7 `immediate actions` 에 부여되는 priority 는 아래 중 하나의 declared source 에 근거해야 한다.
+
+- cited lens output 이 "immediate" 또는 "blocking" 으로 표기한 finding
+- declared rule-resolved artifact (예: `shared-phenomenon-contract` 가 blocking 으로 분류) 
+- deliberation artifact 가 priority 를 명시
+
+위 source 중 어느 것도 없는 action 은 `recommendations` (§5.3 item 8) 로 분류하거나 priority 없이 `immediate actions` 에 unprioritized marker 와 함께 유지한다. synthesize 가 "합리적 판단" 으로 priority 를 부여하는 것은 §Adjudication boundary 금지 경로다.
+
+**Runtime packet과의 정합성**: 위 12개 항목 중 11 (final review result)은 현 runtime packet (`materialize-review-prompt-packets.ts`)에서 별도 heading으로 강제한다. 4 (overlooked premises)와 12 (shared phenomenon summary)는 현 runtime packet이 별도 heading으로 강제하지 않으며, 9개 분류 섹션 (Consensus / Conditional Consensus / Disagreement / Unique Finding Tagging)이 적용하는 Tagging Completeness Rule에 흡수된다. 4와 12를 별도 heading으로 부활시킬지 또는 이 contract에서 제거할지는 packet 갱신 PR이 단일 결정 seat이며, 본 contract는 그 결정 시점까지 12개 enumeration을 conceptual reference로 보존한다.
+
+즉 현재 prompt-backed reference path에서는
+`synthesis markdown`이 canonical prompt output이다.
+
+later productization에서는 이 output이
+`ReviewRecord`의 human-readable layer source가 된다.
+
+aggregate primary artifact는
+`.onto/processes/review/record-contract.md`에서 정의하는 `ReviewRecord`다.
+
+---
+
+## 6. Deliberation Rule
+
+### 6.1 Canonical Deliberation Position
+
+Deliberation은 synthesize 내부 동작이 아니다.
+
+Review는 Round 1 lens 실행 뒤 synthesize 전에 controlled lens deliberation을 수행하고,
+그 결과를 `{session_root}/deliberation.md`에 기록한다.
+
+canonical properties:
+
+1. lens별 deliberation response는 fresh bounded context에서 실행된다.
+2. 각 response 입력은 자기 Round 1 출력과 다른 participating lens 출력으로 제한된다.
+3. teamlead-controlled deliberation result가 합의, 조건부 합의, 지속 이견, resolution을 기록한다.
+4. synthesize는 `deliberation.md`를 읽고 보존적으로 최종 review output을 작성한다.
+5. synthesize는 새로운 disagreement resolution을 만들지 않는다.
+
+MCP/TS runtime에서는 이 의미론을 provider 독립 packet으로 실현한다.
+
+Issue-stance deliberation target에서는 synthesize가 추가로 아래 artifact를 소비한다.
+
+- `{session_root}/finding-ledger.yaml`
+- `{session_root}/finding-relation-graph.yaml`
+- `{session_root}/issue-ledger.yaml`
+- `{session_root}/issue-stance-matrix.yaml`
+- `{session_root}/deliberation-plan.yaml`
+- `{session_root}/deliberation.md`
+- `{session_root}/problem-framing.yaml`
+- `{session_root}/execution-preparation/review-target-profile.yaml`
+
+이 경우 synthesize는 issue status를 새로 판정하지 않는다.
+`no-deliberation-needed`, `resolved`, `narrowed`, `unresolved-with-reason`은
+`.onto/processes/review/issue-stance-deliberation-contract.md`가 소유한다.
+또한 synthesize는 `problem-framing.yaml`의 common spine, timing, closure, closure obligation, domain axes classification을 변경하지 않는다.
+Domain-specific axes are loaded and applied before synthesize from `.onto/domains/{domain}/problem_framing_profile.md`.
+
+### 6.2 frontmatter `deliberation_status`
+
+Synthesize output은 `deliberation_status: performed`를 emit해야 한다.
+이 값은 synthesize가 deliberation actor였다는 뜻이 아니라,
+synthesize가 required controlled deliberation artifact를 소비했다는 뜻이다.
+
+### 6.3 `deliberation.md` artifact 위상
+
+`{session_root}/deliberation.md`는 conflict-resolution authority다.
+
+- 존재하지 않으면 completed review로 assemble할 수 없다.
+- frontmatter는 `deliberation_status: performed`를 선언해야 한다.
+- `Deliberation Decision`은 contested point별로 resolved / narrowed / unresolved-with-reason을 기록한다.
+- synthesize output의 `Deliberation Decision` 섹션은 이 artifact를 보존적으로 반영한다.
+
+---
+
+## 7. Example Prompt Skeleton
+
+```text
+You are synthesize.
+
+[Your Definition]
+{Content of .onto/roles/synthesize.md}
+
+[Context Self-Loading]
+{lens outputs / deliberation artifact / execution rules}
+
+[Language Policy]
+Respond in English. Reasoning, tool arguments, YAML / markdown emits, and
+hand-offs to other agents stay English-only.
+Final principal-facing explanation is produced after synthesize from bounded
+review artifacts.
+
+[Task Directives]
+- Read all lens result files, the materialized input, and `{session_root}/deliberation.md`.
+- Preserve consensus and original lens positions in Disagreement.
+- Preserve the controlled deliberation decisions; do not create a new resolution inside synthesize.
+- Set frontmatter deliberation_status to `performed`.
+- Write the final synthesis output to {synthesis_output_path}.
+```
+
+---
+
+## 8. What This Contract Must Not Do
+
+이 계약은 아래를 하면 안 된다.
+
+1. 독립 lens처럼 자기만의 별도 검증 관점을 추가한다
+2. `axiology`를 대체한다
+3. lens evidence 없이 결론을 덮어쓴다
+4. `New Perspectives`를 독자적으로 제안한다
+
+즉 `synthesize`는
+새로운 검증자가 아니라 `구조 보존형 종합 단계`다.
+
+가능한 realization 예와 deliberation 경로 (§6.1):
+
+| Realization | Deliberation 경로 |
+|---|---|
+| `worker + codex` | bounded deliberation packet |
+| `direct-call + provider` | bounded deliberation packet |
+
+모든 realization은 synthesize 전에 같은 `deliberation.md` artifact를 생성한다.
+
+---
+
+## 9. Immediate Follow-up
+
+다음 단계는 아래다.
+
+1. provider별 controlled deliberation conformance harness를 확장한다
+2. `learn` / `govern`의 MCP-native surface를 별도 설계한다

package/.onto/processes/shared/target-material-kind-contract.md

@@ -0,0 +1,198 @@
+# Target Material Kind Contract
+
+> Status: design goal contract, partially registered in core lexicon.
+> Purpose: define the cross-process goal for material-aware target handling
+> across `review`, `reconstruct`, and future `evolve`.
+
+## 1. Goal Statement
+
+Establish a material-aware runtime contract so `review`, `reconstruct`, and
+future `evolve` can classify non-code targets and route them to appropriate
+observation, validation, artifact, and UX contracts without collapsing material
+type into domain, medium, target input kind, or semantic interpretation.
+
+In product terms:
+
+```text
+Targets are not assumed to be code.
+Runtime first classifies how the target must be read.
+LLM then interprets what the target means for the declared purpose.
+```
+
+## 2. Scope Boundary
+
+This goal includes:
+
+- the shared `target_material_kind` axis
+- review target profile schema alignment
+- reconstruct source profile and source observation alignment
+- material-aware unsupported/fail-loud behavior
+- artifact refs that preserve the detected material kind
+- user-facing presentation of material support and limitations
+
+This goal excludes:
+
+- automatic ontology Seed generation by runtime
+- full spreadsheet, document, database, or code semantic parsing
+- full `evolve` implementation
+- MCP exposure before runtime contracts and conformance tests exist
+- material-specific expert engines beyond the minimum adapter contract
+
+## 3. Shared Axis
+
+`target_material_kind` is owned by `.onto/authority/core-lexicon.yaml`.
+
+Allowed values:
+
+| Value | Meaning |
+|---|---|
+| `code` | Source code, package, service, script, test, config, schema, or implementation bundle. |
+| `spreadsheet` | Workbook, sheet, CSV, accounting schedule, formula model, report, or tabular calculation artifact. |
+| `document` | Prose, requirements, policy, guide, report, contract, PDF, DOCX, Markdown, or similar textual artifact. |
+| `database` | Database connection, schema, migration, SQL file, warehouse model, table, view, or query artifact. |
+| `mixed` | Bundle containing more than one material kind. Each member needs its own material classification. |
+| `unknown` | Runtime cannot classify the material safely. Adapter execution must halt or ask for clarification. |
+
+The axis is separate from:
+
+| Axis | Question answered |
+|---|---|
+| `domain` | What is the target about? |
+| `medium` | Which cross-product implementation or reference frame accumulates reusable learning? |
+| `target_input_kind` | How did the target enter runtime? |
+| `artifact_roles` | What responsibility does the artifact carry in this run? |
+| review context `source_kind` | Which context-source artifact is being admitted into prompt packets? |
+
+## 4. Cross-Process Alignment
+
+| Process | Required alignment |
+|---|---|
+| `review` | `review-target-profile.yaml` records `target_material_kind`; review must not claim material-aware validation before per-material validators exist. |
+| `reconstruct` | Source profiles, source adapters, source observations, and directive validation must be keyed by `target_material_kind`. |
+| `evolve` | Future adapters must not assume code-product inputs; adapter selection should start from `target_material_kind` as defined in `.onto/processes/evolve/material-kind-adapter-contract.md`. |
+
+## 5. Artifact Contract Additions
+
+| Artifact | Required change |
+|---|---|
+| `review-target-profile.yaml` | Preserve `target_material_kind`, detection confidence, confidence basis, and unsupported-material state. |
+| `target-material-profile.yaml` | New reconstruct runtime artifact for material candidates, selected material kind, selected profiles, and support state. |
+| `source-inventory.yaml` | Preserve material-specific inventory units and scan boundaries. |
+| `source-observations.yaml` | Include stable observation ids, material kind, adapter id, location, and structural data. |
+| `source-observation-directive-validation.yaml` | Preserve runtime validation of LLM-selected observation refs against `source-observations.yaml`. |
+| `seed-candidate-validation.yaml` | Preserve runtime validation that LLM-authored Seed claims cite selected runtime observations without runtime generating ontology meaning. |
+| `reconstruct-record.yaml` | Preserve refs to material profile, inventory, observations, directives, metrics, and final disposition. |
+| future `evolve-target-profile.yaml` | Preserve target refs, `target_material_kind`, support status, and boundary refs before any evolve adapter dispatch. |
+
+Artifact names remain contract-owned. Runtime implementation must either match
+these shapes or update the owning contract before code lands.
+
+## 6. Runtime Replacement Steps
+
+Implementation should proceed in this order:
+
+| Step | Status |
+|---|---|
+| Add a shared `target_material_kind` detection helper. | implemented |
+| Extend `review-target-profile.yaml` schema and materializer. | implemented |
+| Add reconstruct source profile loader. | implemented |
+| Add unsupported/fail-loud behavior for `unknown` and unsupported formats. | implemented for the current minimal adapter contract: unknown and unsupported refs are recorded and skipped without adapter dispatch |
+| Implement one minimal source adapter, preferably `document` or `spreadsheet`. | implemented: minimal structural observers write source observations for concrete material refs |
+| Define `source-observations.yaml` schema with stable observation ids. | implemented for preparation helper |
+| Validate directive evidence refs against observation ids. | implemented for `SourceObservationDirective` |
+| Validate Seed candidate claims against selected observation evidence refs. | implemented for `SeedCandidateDirective` helper |
+| Assemble reconstruct artifact refs into `reconstruct-record.yaml`. | implemented as record helper |
+| Add a reconstruct Core API facade over bounded runtime helpers. | implemented for preparation, profile listing, directive validation, and record assembly |
+| Add MCP schemas only after runtime contracts and tests exist. | implemented for `onto.list_source_profiles`, `onto.observe_source`, and `onto.validate_reconstruct_directive`; metrics remain future |
+
+Each step should replace one deterministic boundary. LLM-owned semantic
+judgment remains outside the runtime replacement steps.
+
+## 7. Validation Rules
+
+Runtime must validate:
+
+- `target_material_kind` is one of the allowed values
+- `unknown` does not dispatch a material adapter
+- `mixed` records per-member material kinds
+- unsupported formats halt or degrade explicitly
+- source observations do not claim ontology facts such as entity, relation,
+  business rule, aggregate root, or policy meaning
+- LLM-authored directives reference existing observation ids
+- evidence refs preserve source location and material kind
+- MCP results expose bounded facts and artifact refs, not semantic repairs
+
+## 8. Prompt-Backed Reference Runs
+
+Before full runtime implementation, at least one prompt-backed reference run
+must produce the planned artifact shapes and an acceptance observation.
+
+Recommended reference targets:
+
+| Target | Purpose |
+|---|---|
+| Spreadsheet reconstruct | Prove material observation without accounting-meaning inference. |
+| Document reconstruct | Prove section/quote/reference observation without business-rule inference. |
+| Mixed bundle review or reconstruct | Prove per-member material classification and cross-material refs. |
+
+Reference runs must preserve invocation/binding, material profiling, evidence
+refs, unsupported states, and user-facing result separation.
+
+Current evidence:
+
+- `development-records/reference/20260527-target-material-kind-reference-evidence.md`
+  records a spreadsheet review reference run proving the first material-aware
+  review target profile step.
+- `development-records/reference/20260527-reconstruct-material-kind-reference-evidence.md`
+  records a spreadsheet reconstruct reference slice proving material profiling,
+  source observation, LLM-authored directive evidence validation, and
+  `reconstruct-record.yaml` assembly. MCP conformance now covers the initial
+  reconstruct tool surface. The reference does not close user confirmation,
+  metrics, revision, full reconstruct workflow, or evolve runtime integration.
+
+## 9. UX Output Contract
+
+Opening output should expose:
+
+- selected environment, process, model, and domain
+- requested target and detected `target_material_kind`
+- planned material reading strategy
+- unsupported or partial-support status
+- runtime responsibilities and LLM responsibilities
+
+Progress output should expose:
+
+- material detection result
+- inventory completion
+- observation counts by material kind
+- directive validation status
+- unsupported, unknown, or skipped material members
+
+Result output should separate:
+
+- material observations collected
+- semantic claims promoted by LLM directives
+- evidence gaps
+- unsupported or out-of-scope material
+- next action candidates
+
+The output contract should be rendered by the host LLM from runtime facts or by
+existing CLI/MCP status surfaces. Do not add a separate HTML implementation just
+to display this progress.
+
+## 10. Goal Completion Conditions
+
+This design goal is implementation-ready when:
+
+1. `target_material_kind` is present in core lexicon and process contracts.
+2. Review and reconstruct contracts agree on the axis and naming boundaries.
+3. `source_kind` is not overloaded for material classification.
+4. Legacy `fact_type` is not used for new source observations.
+5. Artifact additions and validation rules are documented.
+6. The prompt-backed reference-run requirement is documented.
+7. Runtime replacement steps are small enough to implement and verify one by
+   one.
+
+It is implementation-complete only when the corresponding runtime schemas,
+materializers, adapters, validators, tests, and MCP surfaces have been added for
+the selected product slice.

package/.onto/roles/axiology.md

@@ -0,0 +1,81 @@
+# axiology
+
+## Perspective
+
+이 lens는 대상 시스템을 **가치 정렬과 목적 부합**의 관점에서 본다. 설계나 결정이 시스템의 선언된 목적, 가치, 의사결정 원칙에서 벗어나는지, 국소 최적화가 전체 목적을 훼손하는지, 암묵적 트레이드오프가 정당화 없이 수용되고 있는지를 검증한다. 이 lens의 관심은 "목적과 가치에 정렬되어 있는가"이다.
+
+이 관점은 가치/목적 정렬에만 초점을 둔다. 다른 모든 lens finding 을 집계하여 최종 결과를 만드는 것은 `synthesize` 의 역할이며 axiology 로 이동하지 않는다. 형식 논리적 모순 · 구조적 · 의존성 결함의 1차 탐지는 별도 관점의 범위이고, axiology 는 그러한 결함이 가치·목적에 미치는 영향을 평가한다. 본 review 1 회 실행에서 active lens set 은 확정되어 있으며, axiology 는 본 role 단독으로 신규 독립 lens 를 추가할 수 없다 (§New Perspectives 는 현재 lens set 을 변경하지 않는다).
+
+### Observation focus
+
+가치 충돌, 목적 drift, 규범적으로 정렬되지 않은 트레이드오프, 국소 최적화로 인한 전체 목적 훼손, 당연시되지만 목적과 무관한 전제, 현재 lens set 이 놓치고 있는 purpose-critical 관점.
+
+### Assertion type
+
+가치 정렬 진술: "이 결정은 시스템의 선언된 목적에서 벗어난다", "국소 최적화가 X 가치 약속을 훼손한다".
+
+## Core questions
+
+- 이 설계나 결정이 시스템의 선언된 목적에서 벗어나는가?
+- 국소 최적화가 더 넓은 가치 충돌이나 목적 drift 를 만드는가?
+- 명시적 정당화 없이 수용되고 있는 숨겨진 트레이드오프가 있는가?
+- 대상이 중요한 이해관계자, 경계, 가치 약속을 불리하게 하는가?
+- 당연시되는 전제가 실제로는 시스템 목적과 무관한가?
+- 현재 lens set 이 아직 고려하지 않았지만 목적/가치 정렬상 고려해야 할 추가 검토 관점이 있는가?
+
+## Authoritative alignment input
+
+이 lens 의 모든 value judgment 는 reviewer 의 개인 해석이 아니라 onto 의 canonical authority chain 에 근거한다. axiology 실행 전 execution preparation 단계에서 아래 authority 가 명시적으로 바인딩된 후 lens prompt 에 주입된다.
+
+### Authority source set
+
+| 순위 | 출처 | 성격 |
+|---|---|---|
+| 1 | `.onto/authority/core-lexicon.yaml` | 개념 SSOT. 각 entity · relation · principle 의 canonical 의미 |
+| 2 | `.onto/principles/productization-charter.md` | 제품 방향. 시스템이 왜 존재하는가 |
+| 2 | `.onto/principles/ontology-as-code-guideline.md` | OaC 원칙 |
+| 2 | `.onto/principles/llm-native-development-guideline.md` | LLM-native 원칙 |
+| 2 | `.onto/principles/product-locality-principle.md` | product 우선 원칙 |
+| 3 | `development-records/evolve/<onto-direction>.md` 최신 정본 | 상위 목표 · 4 축 · 완료 기준 |
+| 4 | 세션 binding `session_domain` 이 non-none 이면 해당 `.onto/domains/{domain}/` 의 purpose-critical 규정 | domain-specific 가치 commitments |
+
+이 순위는 동일 주제에서 충돌 시 낮은 번호 우선. 동순위 내 충돌은 `CLAUDE.md` authority 위계표의 원칙을 따른다 (동일 순위 파일 중복 금지 + 예외 cross-reference).
+
+### Binding timing
+
+- execution preparation 이 위 authority 파일을 자동으로 lens prompt 의 Context Self-Loading 영역에 주입한다
+- authority 파일 미존재 또는 읽기 실패 → finding 은 `insufficient evidence` + `upstream_evidence_required=true`. 개인 가치관에 기반한 판단은 금지
+- `session_domain: none` 이어도 순위 1~3 은 항상 바인딩. 순위 4 만 조건부
+
+## Finding evidence requirements
+
+각 axiology finding 은 일반 output schema (`.onto/processes/review/lens-prompt-contract.md` §8.1) 에 더해 아래 axiology-specific 필드를 포함한다.
+
+- `value_authority_anchor` — 판단 근거로 인용한 authority 의 정확한 seat. 형식: `{source: <file path>, anchor: <§번호 | term id | line range>, excerpt: <판단에 직접 사용한 문장 1~2 줄>}`. 복수 가능
+- `value_type` — 판단이 다룬 가치 범주 중 하나: `purpose` / `stakeholder` / `principle` / `boundary` / `tradeoff` / `commitment`
+- `alignment_direction` — finding 이 authority 와 정렬되어 있음을 주장하는지 (`aligned`), 위반/drift 를 지적하는지 (`misaligned`), 또는 판단 불가인지 (`indeterminate`)
+
+`value_authority_anchor` 가 빈 finding 은 produce 하지 않는다. 인용할 authority 가 없다면 그 finding 자체가 axiology 관할이 아니다.
+
+## New Perspectives (axiology-exclusive canonical slot)
+
+현재 lens set 에 빠진 purpose-critical 관점을 이 lens 가 발견하면 여기서 직접 제안한다. `synthesize` 는 이 제안을 보존할 수 있으나 독자적으로 발명할 수 없다. 이 slot 은 axiology 만 사용할 수 있는 의도적 canonical asymmetry 이다.
+
+New Perspectives 제안 시 최소 필수 필드:
+
+1. **trigger condition** — 제안을 촉발한 증거 (대상 · 관찰 · authority 미커버 영역)
+2. **proposed perspective** — 무엇을 평가할 것인가 (1~2 문장 perspective 요약)
+3. **insufficiency argument** — 기존 9 lens 각각이 이 관점을 왜 커버하지 못하는지 명시
+4. **intended receiving seat** — 제안이 착지해야 할 위치 (현재 review 의 `synthesize` 보존 / 후속 lens governance / axiology 내부 sub-check 등). 착지 seat 미지정 제안은 orphaned 로 간주하여 `synthesize` 가 거부할 수 있다
+
+New Perspectives 제안은 현재 리뷰 실행의 active lens set 을 변경하지 않는다. 실제 lens set 확장은 별도 governance 경로를 통한다.
+
+## Domain examples
+
+- Software: 최적화가 지역 성능을 개선하지만 안전성·유지보수성 약속을 약화
+- Product/process: KPI 개선이 제품의 실제 목적을 왜곡
+- Ontology: 분류가 깔끔해 보이지만 시스템의 의도된 용도와 가치 경계를 위반
+
+## Domain document
+
+none. 이 lens 는 시스템 목적 · 원칙 (§Authoritative alignment input 의 순위 1~3) 과 선택된 도메인 맥락 (순위 4, 조건부) 을 주요 판단 근거로 사용하며, 전용 도메인 규칙 문서를 두지 않는다.

package/.onto/roles/conciseness.md

@@ -0,0 +1,36 @@
+# conciseness
+
+## Perspective
+
+> **Scope 주의 (UF-2)**: 본 lens 의 `conciseness` 는 **ontology-level parsimony** (개념 공간의 parsimony) 를 의미한다. **prose brevity (문장을 짧게 쓰기) 가 아니다**. lexicon 정의와 동일 scope.
+
+이 lens는 대상 시스템을 **간결성**의 관점에서 본다. 불필요한 중복, 과잉 명세, 실질적 차이를 만들지 않는 구분이 존재하는지를 검증한다. 다른 lens들이 "존재해야 할 것이 있는가"와 "있는 것이 올바른가"를 검증하는 반면, 이 lens는 "없어야 할 것이 있는가"를 식별한다.
+
+이 관점은 불필요한 중복·과잉 명세의 존재에만 초점을 둔다. 질의 경로 비효율이나 도메인 영역 누락은 별도 관점의 범위이다.
+
+### Observation focus
+
+동일 또는 유사 개념의 중복 정의, 상위 개념이 보장하는 제약의 하위 재선언(과잉 명세), 실질적 차이 없는 하위 분류, 자식이 하나뿐인 불필요 중간 계층.
+
+### Assertion type
+
+과잉 진술: "X와 Y는 다른 경로/이름으로 중복 정의되어 있다", "이 하위 분류는 실질적 차이를 만들지 않는다".
+
+## Core questions
+
+- 동일 또는 유사 개념이 다른 경로/이름으로 중복 정의되어 있는가?
+- 상위 개념이 이미 보장하는 제약을 하위 수준에서 재선언하는 과잉 명세가 있는가?
+- 실질적 차이를 만들지 않는 하위 분류가 존재하는가?
+- 자식이 하나뿐인 불필요한 중간 계층이 있는가?
+
+## Domain examples
+
+- Software: 다른 경로로 표현된 동일 관계, 사용되지 않는 분류 노드
+- Law: 동일 조항에 대한 중복 규정, 적용 사례가 없는 예외 조항
+- Accounting: 거래가 없는 계정, 상위 계정과 동일한 하위 계정
+
+## Domain document
+
+`.onto/domains/{domain}/conciseness_rules.md` (`session_domain`이 설정된 경우).
+
+`session_domain`이 `none`이면 `.onto/processes/review/lens-prompt-contract.md` §9.3 Domain-None Fallback Rule에 따라 domain document 없이 실행한다.