onto-mcp 0.3.1 → 0.3.2

package/.onto/processes/reconstruct/reconstruct-execution-ux-contract.md

@@ -7,10 +7,10 @@
 ## 1. Position
 
 `reconstruct` can take a long time because the host LLM must read source
-observations, choose evidence, propose Seed meaning, assess competency questions,
-and explain unresolved gaps. The user-facing experience must therefore expose
-new information as it is discovered, not only meta status such as "still
-running".
+observations, run reconstruct lens judgments, choose the next unjudged source
+frontier, propose Seed meaning, assess competency questions, and explain
+unresolved gaps. The user-facing experience must therefore expose new
+information as it is discovered, not only meta status such as "still running".
 
 The runtime owns structured facts, stage ids, artifact refs, liveness hints, and
 deterministic counts. The host LLM owns the short explanation shown to the user.
@@ -30,14 +30,23 @@ The brief must include:
   write policy
 - method: MCP/runtime path, source profile, semantic author realization, and
   confirmation provider realization
+- execution profile: observer/gate slice, full integral exploration, or a
+  test/fixture-only profile if a non-product harness is running, with the
+  completion claim allowed for that profile
 - model/provider: provider family or realization label without secrets
 - domain: selected domain, no-domain mode, or pending domain-context selection
 - material: `target_material_kind`, target input kind, and unsupported-material
   status if known
+- exploration loop: initial source frontier, round budget if any, and frontier
+  validation policy
 - reconstruction direction: what the reconstruct run will try to explain, and
   what it will treat as out of scope
-- ownership boundary: runtime observes and validates; the host LLM proposes
-  meaning; the user or host confirmation controls Seed acceptance
+- ownership boundary: runtime observes and validates; reconstruct lenses judge
+  meaning and source gaps; the user or host confirmation controls Seed
+  acceptance
+- skipped or deferred stages that already narrow downstream authority, such as
+  live lens judgment, source-frontier exploration, domain-context selection,
+  user confirmation, or competency-question assessment
 
 The opening brief should be declarative. It should not ask the user to approve
 internal implementation details unless the target boundary, domain, or write
@@ -45,25 +54,30 @@ policy is ambiguous.
 
 ## 3. Progress Presentation
 
-Progress is stepwise. Each update should include the current
-`ReconstructStageId`, a short label, a liveness state, and one or two newly
-learned facts.
+Progress is stepwise and round-aware. Each update should include the current
+`ReconstructStageId`, exploration round id when applicable, a short label, a
+liveness state, and one or two newly learned facts.
 
 Recommended update shape:
 
 ```text
-[stage 6/26] source_observation
+[round 2 | stage source_frontier_validation] source_frontier
 Status: running
-Learned: 38 source observations across routes, components, and API helpers.
-Next: select evidence-bearing observations for the Seed candidate.
+Learned: coverage requested billing service tests and rejected one already-seen helper.
+Next: observe 3 accepted source refs inside the declared project boundary.
 ```
 
 Progress updates should prefer facts such as:
 
 - material kind and profile confidence
 - scanned roots and skipped boundaries
+- initial source frontier artifact ref and first-observation source refs
 - source inventory counts by material-specific unit
+- exploration round count and new observation count by round
 - selected observation count and evidence-candidate rationale
+- per-lens judgment status and newly named semantic gaps
+- source frontier refs requested, accepted, rejected, already observed,
+  unsupported, or out of bounds
 - domain context refs and snapshot id
 - Seed claim count by entity, relation, action, property, and rule
 - claim realization stance counts
@@ -73,6 +87,7 @@ Progress updates should prefer facts such as:
 - revision proposal action counts
 - unresolved, deferred, and out-of-scope counts
 - current halt reason and reusable artifact refs when halted
+- skipped/deferred stage reason and downstream authority impact
 
 Progress updates should avoid pretending that intermediate semantic claims are
 final. Before Seed confirmation, claims are candidates. Before competency
@@ -87,6 +102,8 @@ Decision points:
 
 - target boundary is ambiguous or would require reading outside the bound root
 - material kind is unsupported or mixed in a way that changes adapter behavior
+- source frontier expansion would exceed the declared boundary, adapter support,
+  or round/cost budget
 - domain context selection changes the interpretation standard
 - Seed claim confirmation requires accepted, rejected, partial, or deferred
   state
@@ -107,11 +124,18 @@ separate:
 - revision proposals and action candidates
 - unresolved, deferred, unsupported, or out-of-scope items
 - artifact provenance: the owning ids and artifact refs behind the statements
+- execution profile and completion scope: what actually ran, what was skipped,
+  and which downstream authority claims are therefore narrowed
 
 The final output is not the authority for truth. It is a user-facing projection
 of `reconstruct-record.yaml`, `reconstruct-run-manifest.yaml`, and the
 stage-owned artifacts.
 
+Full integral exploration wording is allowed only when the run manifest records
+the full profile and the required exploration, domain-context, Seed,
+confirmation, competency-question, assessment, failure, revision, metrics, stop,
+and final-output stages are trusted or explicitly skipped with trusted reasons.
+
 ## 6. Halted Or Partial Runs
 
 If a run halts, the output should still be useful:
@@ -120,7 +144,11 @@ If a run halts, the output should still be useful:
 - show which artifact refs are reusable
 - show which stage failed and why
 - show the strongest safe statement supported by completed artifacts
+- show the latest accepted/rejected source frontier refs if the halt happened
+  inside exploration
 - avoid summarizing missing stages as if they ran
+- show the execution profile and the exact completion claim still supported by
+  trusted artifacts
 
 A halted run may provide candidate Seed content only if the corresponding
 artifact and validation refs exist. It may not imply Seed confirmation, CQ
@@ -132,11 +160,16 @@ ontology direction unless those artifacts exist.
 Future status/result payloads should expose enough facts for the host LLM to
 render this contract without scraping prose:
 
+- execution profile and allowed completion claim
 - current stage id and total planned stage count
+- current exploration round id, round state, and round budget if any
 - stage state: pending, running, completed, skipped, or halted
+- skipped/deferred stage reason and `authority_impact`
 - stage artifact refs and owner
 - liveness state and recommended polling interval
 - deterministic count summaries from the latest completed artifacts
+- latest source frontier summary and reusable trusted observation refs
+- initial source frontier artifact ref
 - unresolved/deferred/out-of-scope summaries
 - opening, progress, halt, and final presentation prompts or facts
 

package/.onto/processes/reconstruct/source-profile-contract.md

@@ -1,6 +1,6 @@
 # Reconstruct Source Profile Contract
 
-> Status: design contract, not wired runtime.
+> Status: design contract, partially wired runtime.
 > Purpose: define target-material observation contracts for `reconstruct`.
 
 ## 1. Canonical Seat
@@ -15,6 +15,11 @@ The historical `explorers/` folder is archived and must not be revived as an
 active runtime path. `SourceProfile` is the current name because the file guides
 runtime observation. It is not an autonomous semantic explorer.
 
+In the integral exploration design, source profiles still belong to the runtime
+observation side. Reconstruct lenses may ask for additional source refs through
+a validated source frontier, but the profile itself does not decide which source
+is semantically important.
+
 Source profiles are keyed by `target_material_kind`, the shared runtime axis
 defined in `.onto/authority/core-lexicon.yaml`. They must not use `source_kind`
 to mean code, spreadsheet, document, or database because review already uses
@@ -32,6 +37,8 @@ Current source profiles:
 | `spreadsheet` | `.onto/processes/reconstruct/source-profiles/spreadsheet.md` |
 | `database` | `.onto/processes/reconstruct/source-profiles/database.md` |
 | `document` | `.onto/processes/reconstruct/source-profiles/document.md` |
+| `mixed` | no standalone parser profile; requires per-member profiles or explicit unsupported/halt behavior |
+| `unknown` | no profile; runtime must halt or ask for clarification |
 
 ## 2. Profile Responsibility
 
@@ -43,11 +50,13 @@ A source profile may define:
 - detail location notation
 - context questions
 - scan targets
+- safe frontier-ref shapes for this material kind
 - correct and incorrect observation examples
 - current support status and explicit unsupported cases
 
 A source profile must not define rules that convert source structure into
-ontology concepts.
+ontology concepts or rules that choose the next source based on ontology
+meaning.
 
 Examples:
 
@@ -65,11 +74,17 @@ return observations, but they do not interpret ontology meaning. The source
 profile may guide observation scope, but the adapter schema is the runtime
 contract that fixes returned fields and observation ids.
 
+When a source adapter is invoked after the first round, it consumes only
+runtime-validated source frontier refs. It must not accept lens prose or
+semantic labels as source locations.
+
 The future adapter contract must fail explicitly when:
 
 - the target material kind cannot be resolved
 - the source format is unsupported
 - the target is outside the declared filesystem or connection boundary
+- a requested source frontier ref is not a concrete source location for this
+  material kind
 - an observation ref cited by a directive does not exist
 - required parser/tool support is unavailable
 
@@ -86,13 +101,16 @@ Every profile must make the material-specific reading strategy visible:
 | `spreadsheet` | Inspect workbook/sheet/range/formula/formatting structure without declaring accounting or business meaning. |
 | `document` | Inspect sections, headings, quotes, tables, references, and definitions without choosing canonical business rules. |
 | `database` | Inspect schemas, tables, columns, constraints, indexes, and queries without assigning business relation meaning. |
-| `mixed` | Inventory each member with its own material kind and preserve cross-material refs without collapsing them into one parser. |
+| `mixed` | Inventory each member with its own material kind and preserve cross-material refs without collapsing them into one parser. If a composite profile is not implemented, halt or ask before adapter dispatch. |
 | `unknown` | Halt or ask for clarification; do not guess an adapter. |
 
 Domain interpretation happens after observation. For example, an accounting
 spreadsheet is `target_material_kind=spreadsheet` and may use `domain=accounting`;
 the spreadsheet adapter reports cells and formulas, while the LLM interprets
-accounting meaning from evidence and selected domain documents.
+accounting meaning from evidence and selected domain documents. If that
+interpretation shows that another sheet, range, document section, table, or code
+file is needed, the host LLM writes a source frontier directive and runtime
+validates it before any additional observation occurs.
 
 ## 5. Extension Rule
 
@@ -100,8 +118,23 @@ Adding a new target material kind requires:
 
 1. A new source profile under `.onto/processes/reconstruct/source-profiles/`.
 2. Runtime adapter support or an explicit unsupported status.
-3. Tests for target material detection, observation shape, unsupported inputs,
-   and directive evidence-ref validation.
+3. Tests for target material detection, observation shape, source frontier
+   validation, unsupported inputs, and directive evidence-ref validation.
 4. MCP schema updates only after the runtime contract is implemented.
 
 The source profile alone does not make a target material kind supported.
+
+## 6. Mixed Material Rule
+
+`mixed` is a public `TargetMaterialKind` value, but it is not a material parser.
+Runtime must choose one of these behaviors before observation:
+
+| Behavior | Requirement |
+|---|---|
+| supported composite | Runtime writes per-member material classification, dispatches only supported member profiles, and preserves cross-material refs in inventory and observations. |
+| partial composite | Runtime observes supported members, records unsupported members separately, and exposes the downstream authority limit. |
+| unsupported | Runtime halts or asks for clarification with a stable unsupported reason before adapter dispatch. |
+
+No source profile may treat `mixed` as a shortcut for reading a bundle with one
+adapter. Cross-material semantic meaning remains LLM-owned and must be grounded
+in per-member observations plus validated cross-material refs.

package/.onto/processes/reconstruct/top-level-concept-discovery-contract.md

@@ -0,0 +1,387 @@
+# Reconstruct Top-Level Concept Discovery Contract
+
+> Status: design contract.
+> Purpose: define how `reconstruct` discovers purpose-relative top-level
+> concepts for an ontology Seed without turning the Seed into a broad claim
+> ledger or a full ontology draft.
+
+## 1. Position
+
+`reconstruct` Seed generation is a top-level concept discovery process.
+
+The Seed is not the full ontology. It is not a complete list of entities,
+relations, actions, properties, rules, implementation details, or all possible
+evidence-backed claims. Its purpose is to identify the smallest stable set of
+top-level concepts that explains the declared purpose of the target material,
+with explicit boundaries, evidence, open questions, and deferred lower-level
+details.
+
+Top-level concepts are purpose-relative. They are not the highest possible
+abstractions in a universal hierarchy. A concept is top-level for a reconstruct
+run when it is the most useful stable axis for explaining the declared purpose
+from the observed source evidence.
+
+Example:
+
+```text
+RawIngestEvent
+-> Usage Event
+-> Usage Activity
+-> User Behavior
+-> Organizational Knowledge Flow
+```
+
+For an AI usage dashboard Seed, `Usage Event` may be a top-level concept while
+`Organizational Knowledge Flow` is too abstract and `RawIngestEvent` is usually
+a lower-level implementation detail.
+
+## 2. Ownership Boundary
+
+Runtime owns material-aware observation, source inventories, artifact refs,
+validation gates, deterministic metrics, and source frontier boundary checks.
+
+The host LLM owns semantic grouping, abstraction-level judgment, top-level
+concept naming, boundary explanation, relation interpretation, convergence
+interpretation, and final user-facing explanation.
+
+Runtime must not decide that a source symbol, spreadsheet range, document
+section, database table, UI component, or service method is a top-level concept.
+Runtime may validate that LLM-authored top-level concept artifacts cite known
+evidence refs and preserve declared artifact shape.
+
+## 3. Design-Local Terms
+
+These names are design-contract terms until promoted through the concept
+registration gate in `reconstruct-boundary-contract.md`.
+
+| Term | Seat | Meaning |
+|---|---|---|
+| `TopLevelConcept` | reconstruct-local semantic artifact candidate | Purpose-relative concept that explains multiple lower-level observations and remains stable across likely implementation changes. |
+| `TopLevelConceptSet` | reconstruct-local semantic artifact candidate | Small selected set of top-level concepts for the declared purpose. |
+| `LowerLevelDetail` | design shorthand | Source-specific field, method, component, rule, property, table, sheet, or claim that should support a top-level concept rather than become the Seed center. |
+| `TopLevelnessPressure` | design shorthand | Unresolved reason that may change the selected concept set, concept boundary, or core relation. |
+| `ConceptConvergence` | design shorthand | State where further source exploration is expected to refine evidence or details rather than materially change the top-level concept set, boundaries, or core relations. |
+
+Do not introduce these names as TypeScript types, MCP fields, public artifact
+fields, or enum values before the concept registration gate is explicitly
+closed.
+
+## 4. Discovery Strategy
+
+Top-level concept discovery uses bottom-up observation, top-down purpose
+constraint, and graph compression.
+
+The process is not "keep climbing the hierarchy." It alternates between lifting
+source details into candidate concepts and grounding those candidates back into
+the declared purpose and observed evidence.
+
+```text
+material-aware source observations
+-> local semantic labels and gaps
+-> candidate concept clusters
+-> abstraction-level tests
+-> top-level concept set
+-> source frontier aligned to unresolved top-levelness pressure
+-> convergence assessment
+```
+
+### 4.1 Collect Local Candidates
+
+The first semantic pass may name many local candidates from files, symbols,
+tables, fields, formulas, headings, UI components, services, actions, states,
+rules, and document claims. This pass should avoid deciding top-level status too
+early.
+
+Local candidates are evidence-bearing raw material for clustering. They are not
+Seed output by default.
+
+### 4.2 Cluster By Purpose Role
+
+Local candidates should be clustered by the role they play in explaining the
+declared purpose:
+
+- shared lifecycle
+- shared user-facing meaning
+- shared source flow
+- shared ownership or authority
+- shared change fate
+- repeated co-occurrence across material slices
+- ability to explain multiple lower-level observations
+
+Example for an AI usage dashboard:
+
+| Local candidates | Candidate top-level concept |
+|---|---|
+| session row, session metrics, session context, session classification | `Usage Session` |
+| raw payload, ingest event, fingerprint, deduplication status | `Usage Event` |
+| billing aggregate, cost KPI, token cost, provider cost | `Usage Cost` |
+| page, KPI cards, session table, analytics summary | `Dashboard View` |
+
+### 4.3 Test Abstraction Level
+
+Each candidate must pass both upward and downward tests.
+
+Upward test:
+
+- Does this candidate explain multiple lower-level observations?
+- Does it survive likely implementation changes?
+- Is it necessary to explain the declared purpose?
+- Can a user understand it without reading implementation names?
+
+Downward test:
+
+- Is it still grounded in concrete evidence?
+- Does it avoid becoming a generic business abstraction?
+- Does it preserve enough boundary detail to guide later ontology work?
+- Does it avoid hiding materially different concepts that must be split?
+
+The target is the stable middle level that explains the purpose, not the most
+abstract reachable parent.
+
+### 4.4 Select A Small Concept Set
+
+The Seed should prefer a compact top-level concept set. The normal target range
+is small enough for a user to inspect in one pass, usually 3-7 concepts for a
+bounded product slice.
+
+The concept set may be larger when the declared purpose or target bundle is
+explicitly broad, but growth must be justified by purpose coverage, not by
+implementation surface area.
+
+### 4.5 Demote Lower-Level Detail
+
+Implementation details, fields, service methods, UI widgets, spreadsheet cells,
+schema columns, narrow rules, and action-level claims should be demoted unless
+they independently satisfy the top-level tests.
+
+Demotion does not discard evidence. The detail should be attached to one of:
+
+- `included_lower_concepts`
+- `supporting_evidence`
+- `deferred_detail_candidates`
+- `open_questions`
+- `boundary_notes`
+
+## 5. Top-Levelness Criteria
+
+A top-level concept candidate is strong when it satisfies most of the criteria
+below.
+
+| Criterion | Question |
+|---|---|
+| Purpose criticality | Would the declared purpose become hard to explain without this concept? |
+| Explanatory compression | Does it explain multiple lower-level observations without losing important distinctions? |
+| Boundary clarity | Can the run state what belongs under this concept and what is excluded or deferred? |
+| Relation centrality | Does it participate in core relations with other selected concepts? |
+| Material grounding | Is it supported by concrete source observations from the current material boundary? |
+| User-facing intelligibility | Can the concept be named in service language, not only implementation language? |
+| Evolution stability | Would the concept likely survive refactors, UI rewrites, schema reshaping, or source-format changes? |
+| Split pressure | Is there no unresolved material reason to split it now? |
+| Merge pressure | Is there no unresolved material reason to merge it with another selected concept now? |
+
+No single criterion is sufficient. Frequent source mentions or central code
+location do not by themselves make a concept top-level.
+
+## 6. Source Frontier Alignment
+
+Source frontier selection must align to top-level concept convergence.
+
+The frontier should not ask "what else can be read?" It should ask "what source
+could materially change the selected top-level concept set, concept boundaries,
+core relations, or convergence confidence?"
+
+Each LLM-authored frontier ref should carry the decision pressure it is meant
+to resolve.
+
+Recommended semantic payload:
+
+```yaml
+frontier_refs:
+  - source_ref: src/services/usage-mart.service.ts
+    frontier_question: Is UsageMart a top-level concept or a lower-level read model under Usage Cost or Dashboard View?
+    target_concepts:
+      - Usage Cost
+      - Dashboard View
+      - Usage Mart
+    pressure_type: split_or_demote
+    expected_decision_impact: May demote UsageMart from top-level concept to supporting detail.
+    priority: high
+```
+
+The exact public artifact field names remain subject to the registration gate.
+Until then, runtime may preserve this information inside existing rationale
+fields or design-local prompt payloads.
+
+Valid frontier pressure categories:
+
+| Pressure | Use when |
+|---|---|
+| `missing_axis` | The declared purpose may require a top-level concept not yet represented. |
+| `split_or_merge` | Two candidates may be the same concept, or one candidate may hide two materially different concepts. |
+| `boundary` | The concept's included and excluded lower-level details are unclear. |
+| `core_relation` | The relation between selected concepts may be wrong or incomplete. |
+| `abstraction_level` | A candidate may be too implementation-specific or too generic. |
+| `evidence_saturation` | The run needs to know whether additional source will introduce new top-level concepts or only reinforce existing ones. |
+
+Frontier requests that only gather lower-level implementation detail are valid
+only when that detail can resolve one of these pressures.
+
+## 7. Convergence Conditions
+
+Top-level concept discovery converges when further source exploration is
+expected to refine evidence, properties, rules, or lower-level details, but is
+not expected to materially change the selected top-level concept set, each
+concept's boundary, or the core relations between concepts for the declared
+purpose.
+
+Convergence is not the absence of all issues. It is a bounded claim about the
+stability of the top-level concept set.
+
+The run may report one of three convergence states:
+
+| State | Meaning | Typical next action |
+|---|---|---|
+| `not_converged` | Top-level concept candidates, boundaries, or relations are still changing materially. | Continue source frontier exploration. |
+| `provisionally_converged` | The main concept set is stable, but some split, merge, boundary, or deferred-detail questions remain. | Present Seed with disclosed limits and revision proposals. |
+| `converged_for_seed` | Purpose coverage, concept boundaries, and core relations are stable enough for Seed handoff. | Present Seed as the current top-level concept discovery result. |
+
+Signals for convergence:
+
+- selected concept set is stable across the latest exploration round
+- new observations map into existing concepts rather than creating new top-level
+  concepts
+- remaining issues concern evidence depth, properties, rules, or lower-level
+  details
+- no lens raises a material objection that a selected concept is too broad, too
+  narrow, too generic, too implementation-specific, missing, or duplicated
+- next frontier value is expected to improve confidence rather than change the
+  concept set
+
+Signals against convergence:
+
+- a new source slice introduces a previously missing purpose axis
+- selected concepts repeatedly require split or merge
+- relation direction between selected concepts changes
+- a selected concept cannot state included and excluded detail
+- a concept is only a code artifact, UI widget, schema artifact, spreadsheet
+  range, or document section with no purpose-level role
+- the concept set explains source structure but not the declared purpose
+
+## 8. Seed Output Shape
+
+The Seed should center top-level concepts. Current artifacts may continue to use
+existing Seed claim fields while the contract migrates, but the semantic shape
+should project to:
+
+```yaml
+purpose:
+  claim_id:
+  name:
+  statement:
+  evidence_refs:
+top_level_concepts:
+  - concept_id:
+    name:
+    definition:
+    why_top_level:
+    evidence_refs:
+    included_lower_concepts:
+    excluded_or_deferred_details:
+    core_relations:
+    open_questions:
+    confidence:
+top_level_relations:
+  - relation_id:
+    source_concept_id:
+    target_concept_id:
+    relation:
+    statement:
+    evidence_refs:
+deferred_detail_candidates:
+  - name:
+    belongs_to_concept_id:
+    reason_deferred:
+    evidence_refs:
+convergence:
+  state:
+  rationale:
+  remaining_pressures:
+```
+
+If existing `entities`, `relations`, `actions`, `properties`, and `rules`
+fields are used before schema migration, they must be interpreted narrowly:
+
+- `entities` should contain only top-level concept candidates or explicitly
+  marked provisional top-level entities.
+- `relations` should contain only relations between top-level concepts.
+- `actions`, `properties`, and `rules` should be sparse and limited to
+  purpose-level facts that affect top-level concept boundaries or relations.
+- lower-level actions, properties, rules, fields, methods, UI elements, and
+  schema details should move to deferred detail or supporting notes.
+
+## 9. Lens Responsibilities
+
+Reconstruct lenses should evaluate top-level concept discovery rather than
+merely collecting claim improvements.
+
+| Lens | Discovery question |
+|---|---|
+| semantics | Are the concept names and definitions meaningfully distinct and grounded? |
+| structure | Is the concept set neither over-split nor over-merged? |
+| dependency | Do selected concepts have stable dependency and flow relations? |
+| pragmatics | Can target users understand and act on this concept set? |
+| evolution | Will the concepts survive likely implementation and material changes? |
+| coverage | Does the set cover the declared purpose without missing a major axis? |
+| logic | Are relations and boundaries coherent and non-contradictory? |
+| conciseness | Is the Seed compact enough to serve as a Seed rather than a full ontology? |
+| axiology | Does the concept set preserve what matters for trust, value, and declared purpose? |
+
+Lens disagreement should be represented as split, merge, boundary, abstraction,
+or missing-axis pressure when it can affect top-level convergence.
+
+## 10. Validation Expectations
+
+Runtime validation should remain deterministic. It can validate:
+
+- artifact shape
+- required fields
+- known evidence refs
+- duplicate ids
+- relation endpoints referencing known top-level concepts
+- every top-level concept having at least one evidence ref
+- every top-level concept having a boundary statement
+- convergence state being one of the allowed values once promoted
+
+Runtime should not validate semantic truth such as whether `Usage Session` is
+really the right top-level concept. That remains LLM-authored and lens-reviewed.
+
+## 11. Non-Goals
+
+This contract does not require:
+
+- a full ontology graph
+- exhaustive entity extraction
+- automatic semantic repair by runtime
+- a universal hierarchy of concepts
+- reading every source file
+- turning every source detail into a Seed claim
+- declaring lower-level implementation details final
+
+## 12. Implementation Path
+
+Recommended implementation order:
+
+1. Update the Seed author prompt to make top-level concept discovery the primary
+   objective.
+2. Add compact prompt payloads that pass candidate labels, gaps, evidence ids,
+   and unresolved top-levelness pressure rather than full artifacts.
+3. Add a design-local top-level concept projection in final output before
+   changing public schema.
+4. Add Seed validation checks for required `name`, boundary, evidence, compact
+   concept set, and relation endpoints.
+5. Add frontier rationale fields or prompt requirements that align every
+   source frontier request to top-level concept pressure.
+6. Add convergence projection to metrics and final output.
+7. Promote stable names through `.onto/authority/core-lexicon.yaml` only after
+   the artifact shape has stabilized.
+

package/.onto/processes/review/lens-registry.md

@@ -71,6 +71,22 @@ controlled deliberation은 관점 간 충돌을 제한 맥락에서 정리하며
 - 다른 lens 전체를 요약하지 않는다
 - `New Perspectives` canonical slot을 소유한다 (axiology-exclusive)
 
+`New Perspectives`는 현재 review에서 관찰된 목적상 미커버 관점을 보존하는 슬롯이다.
+이 슬롯은 현재 실행의 active lens set을 변경하지 않는다.
+domain 문서, domain concern tag, CQ, case evidence는 lens 추가를 요구하거나 결정하는
+authority가 아니다. domain은 concern을 lens-usable 원칙, 사례, CQ, 관련 문서 경로로
+표현할 수 있지만, lens 추가/삭제/분할/통합 판단은 review process 차원의 lens governance
+문제다.
+
+`New Perspectives` 제안이 나오면 가능한 처리 경로는 아래 중 하나다.
+
+1. 기존 lens/CQ/domain rule 경로로 흡수한다.
+2. domain 문서의 concern tag 또는 CQ를 보강한다.
+3. 별도 lens-governance follow-up으로 보존한다.
+
+3번은 후속 검토 입력일 뿐이며, 본 review 실행이나 특정 domain 문서가 새 active lens를
+추가했다는 뜻이 아니다.
+
 ### 4.2 `synthesize`
 
 - lens set 전체와 `deliberation.md`를 읽어 final review output을 만든다