@elevasis/sdk 1.44.3 → 1.45.0

package/reference/rules/vibe.md

@@ -9,209 +9,7 @@ paths:
 
 # Vibe Layer
 
-Vibe is an **ambient, always-on** intent classifier. It activates automatically whenever the user speaks in plain language -- no slash command, no activation phrase, no special syntax. Every natural-language message passes through vibe classification before the agent acts.
-
-This rule applies to all sessions inside external projects. It does NOT apply in the monorepo (ambient routing is off there by default).
-
-## What Vibe Is
-
-Vibe is the translation layer between the user's natural language and the correct agent action. The user describes reality -- "we track deals by Shopify platform", "I'm stuck on this task", "what should I work on next" -- and vibe determines which of the seven intent types the message represents. The agent then routes to the right behavior without the user ever knowing the classification happened.
-
-Vibe coders (non-technical builders) are the primary audience. They build by describing. They never memorize commands, IDs, or schema. The ambient layer closes the gap between what they say and what the system can act on.
-
-## Intent Types
-
-### 1. Capture
-
-The user wants to record something new -- a task, a note, a piece of information that should persist.
-
-**Recognize by:** action verbs like "add", "create", "remember", "track", "log", "note down", "write down", combined with a thing to record.
-
-**Fixture examples:**
-
-| Input                                               | Why it's Capture                             |
-| --------------------------------------------------- | -------------------------------------------- |
-| "Add a task to follow up with the Shopify client"   | Explicit "add a task" with a described item  |
-| "Remember to run the campaign report on Friday"     | "Remember to" signals something to persist   |
-| "Run the campaign report every Friday at 9am"       | Repeating schedule vocabulary to persist     |
-| "Track this conversation as a deal note"            | Explicit "track" with a described artifact   |
-| "Note for myself: the client prefers morning calls" | "Note for myself" = personal note to persist |
-
-**Agent action:** draft the capture in plain language, confirm with the user, then execute via `elevasis-sdk project:*` commands for project records, `elevasis-sdk note:create` for personal user notes (the Command Center right panel), or `elevasis-sdk schedule:create` for recurring automation. Disambiguate note scope: a note tied to a deal/task/project is `project:note:create` (a `project:*` record); a standalone personal note is `note:create`. Use repetition vocabulary ("every", "daily", "weekly", "monthly") for schedules; one-shot future reminders stay project tasks with due dates. Never write without confirmation.
-
-### 2. Query
-
-The user wants to know something about current state -- task priorities, what is pending, what is running, what failed.
-
-**Recognize by:** questions about the current list, status, or queue of things. Includes both static-model queries ("what systems are on?") and runtime-entity queries ("what's pending in the queue?"). Route Query to static-model sources (org model, Systems/Actions config) or runtime sources (operations domain) based on the referenced entity.
-
-**Fixture examples:**
-
-| Input                                        | Why it's Query                              |
-| -------------------------------------------- | ------------------------------------------- |
-| "What should I work on next?"                | Asking for prioritized task list            |
-| "What's pending in the HITL queue?"          | Runtime-entity query about operations state |
-| "What runs this week?"                       | Runtime query about upcoming schedules      |
-| "What systems are enabled for this project?" | Static-model query about Systems config     |
-
-**Agent action:** read the relevant source and narrate the answer in plain language. Use org model or `project:*` for project state, `elevasis-sdk queue:list --status pending --pretty` and `queue:status --pretty` for HITL queue state, and `elevasis-sdk schedule:list --status active --pretty` for upcoming recurring automation. No writes.
-
-### 3. Describe
-
-The user wants the agent to explain something -- a scope, an entity, a concept within the project.
-
-**Recognize by:** "what is", "what does", "tell me about", "explain", "where am I", "what's going on", "describe", "show me" without an action intent attached.
-
-**Fixture examples:**
-
-| Input                                      | Why it's Describe                                     |
-| ------------------------------------------ | ----------------------------------------------------- |
-| "What's going on with the ZentaraHQ deal?" | Asking for a plain-language description of an entity  |
-| "Tell me about the CRM system"             | Asking the agent to narrate what a model element does |
-| "Where am I in this project?"              | Asking for current scope narration                    |
-
-**Agent action:** read the relevant org-model label, entity, or scope. Narrate in plain language using label fields from the model -- never invent vocabulary not present in the model. Phase-1 scope covers Model, Systems/Actions, and Foundations layers only.
-
-**Stage/state/catalog sub-routing:** when the noun being described is a stage, state, status
-bucket, catalog entry, progress step, pipeline column, or similarly closed business vocabulary,
-also show the cross-system impact before the normal description:
-
-1. Read `operations/node_modules/@elevasis/sdk/reference/spine/spine-primer.md` for the layering pattern.
-2. Read the relevant domain in `core/config/organization-model.ts`.
-3. Explain the impact in vibe-coder language only: the business profile entry, the saved progress
-   on each record, the automations that produce updates, and the dashboard or reports that read it.
-4. Route follow-up changes through `/om <domain>`. Do not mention the technical pattern name
-   unless the user explicitly asks for internals.
-
-### 4. Transition
-
-The user wants to change the status of a task or entity.
-
-**Recognize by:** single-word or short-phrase state signals -- "done", "finished", "complete", "blocked", "stuck", "waiting", "in review", "cancelled" -- applied to a current task or named entity.
-
-**Fixture examples:**
-
-| Input                                         | Why it's Transition                         |
-| --------------------------------------------- | ------------------------------------------- |
-| "Done with the proposal draft"                | "Done" + named artifact = status transition |
-| "Stuck -- blocked waiting on client feedback" | "Stuck" + reason = blocked transition       |
-| "Mark the onboarding task as complete"        | Explicit status-change vocabulary           |
-| "Approve the pending checkpoint"              | Selects an action from the HITL queue       |
-| "Pause the Friday report"                     | Changes schedule state                      |
-
-**Agent action:** identify the task, queue item, schedule, or entity being transitioned, confirm the new status/action with the user, then apply it via `elevasis-sdk project:task:save`, `elevasis-sdk queue:select <id> --action-id <id>`, `elevasis-sdk queue:expire <id>`, `elevasis-sdk schedule:pause <id>`, `schedule:resume <id>`, or `schedule:cancel <id>` as appropriate. Never auto-transition without confirmation if the target entity is ambiguous.
-
-### 5. Navigate
-
-The user wants to shift focus -- to a different task, project, System, Action, or layer of the model.
-
-**Recognize by:** focus-shift vocabulary -- "focus on", "let's look at", "switch to", "back to", "move to", "open", "go to" -- followed by a scope target.
-
-**Fixture examples:**
-
-| Input                                        | Why it's Navigate                                   |
-| -------------------------------------------- | --------------------------------------------------- |
-| "Let's focus on the onboarding flow for now" | "Focus on" + scope target                           |
-| "Switch to the Shopify integration project"  | "Switch to" = navigate to a different project scope |
-| "Back to the CRM tasks"                      | "Back to" = return to a prior scope                 |
-
-**Agent action:** update the active scope in `prj_tasks.resume_context` (current project + task pointer), then narrate the new scope in plain language so the user knows where they are.
-
-### 6. Codify
-
-The user describes organizational reality that is not yet expressed in the model -- industry type, entity kinds, custom attributes, renamed stages, domain vocabulary.
-
-**Recognize by:** declarative "we are" / "we use" / "we track" statements, repeated attribute mentions (second time the same attribute appears), or explicit "add a type / add a field / model X as Y" requests.
-
-**NOT Codify — do not over-propose on questions.** "What systems are on?", "tell me about deals", "explain the lead-gen Action" are Describe, not Codify. The discriminator is _asking about_ versus _asking to change_ the model. Read-shaped inputs ("what", "tell me", "explain", "show me", "where am I") stay in Describe even when they reference the same vocabulary Codify edits — narrate, do not propose codification. Only propose codification when the user declares new structure ("we're an X company", "we track Y as Z") or explicitly asks for a model change ("add a field…", "rename stage…").
-
-**Fixture examples:**
-
-| Input                                                                            | Why it's Codify                                          |
-| -------------------------------------------------------------------------------- | -------------------------------------------------------- |
-| "We're an e-commerce company -- all our deals come from Shopify or Amazon"       | Declares industry + platform attributes not yet in model |
-| "We track deal stage as discovery, scoping, proposal, closed"                    | Describes custom CRM stages that should replace defaults |
-| "Add a project type called 'retainer' with monthly billing and a contract field" | Explicit request to add a new entity extension           |
-
-**Agent action:** delegate immediately to `/om`. Do not attempt the ceremony yourself. Invoke with the relevant domain: `/om sales` for deal/contact changes, `/om projects` for project types, `/om systems` for availability/routing toggles, and `/om actions` for invokable operation changes. Plain-language summary of what was detected is acceptable before delegating, but the actual draft-confirm-write ceremony belongs to `/om`.
-
-**Stage/state/catalog impact preview:** if the Codify intent adds, renames, removes, reorders, or
-re-scopes a stage, state, status bucket, catalog member, pipeline step, or progress vocabulary,
-preview the cross-system impact before delegating:
-
-- Which business-profile entry changes.
-- Which saved record progress keys may already exist.
-- Which automations or templates reference the key.
-- Which dashboard, report, queue, or API reads may display or filter by it.
-
-Then delegate to `/om <domain>` with that preview as context. Vibe does not write the
-change and does not expose monorepo-only commands.
-
-This routing applies to both codify levels (decision #21 -- Codify ceremony delegated to `/om`):
-
-- **Level A** (config-only edits to `organization-model.ts`, System availability/routing toggles, label renames): delegate to `/om <domain>` immediately.
-- **Level B** (new Zod extension files in `core/config/extensions/`): also delegate to `/om <domain>`; `/om` gates Level B to explicit user asks before scaffolding a new TS file.
-
-Vibe detects the intent and delegates in both cases. It does not run either pipeline itself.
-
-For "build/extend the CRM" asks, classify the structural org-model portion as Codify, then read `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-crm.md` before editing. CRM work often spans org-model sales semantics, shared UI routes, hooks, workflow adapters, and deal actions; do not reduce it to only `sales` config or only UI.
-
-For "build/extend lead gen" / "campaign creator" / "outbound list state" asks, classify the structural org-model portion as Codify, then read `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/extend-lead-gen.md` before editing. Lead-gen work often spans org-model prospecting semantics, shared UI routes, hooks, list/member state, artifacts, and workflow adapters; do not reduce it to only `prospecting` config or only UI.
-
-For "add a custom CRM action" / "Send Quote button" asks, classify as Codify, then read `operations/node_modules/@elevasis/sdk/reference/scaffold/recipes/customize-crm-actions.md` before editing. Start with the shared `crmActions` provider path for action visibility, labels, ordering, and render-time configuration. In v1, platform-known/default action endpoint behavior is server-constrained; use project-owned UI that calls the workflow directly when a custom key sits outside that server-dispatched set.
-
-Heuristics for when to propose codification (passed to `/om` as context):
-
-- First mention of a new attribute: note to `resume_context`, do not propose yet
-- Second mention OR explicit declaration ("we're ecom"): propose extension
-- Explicit ask ("track ecom deals separately"): propose immediately with fuller scope
-- Attribute appearing across 3+ tasks: propose adding field to existing extension
-
-### 7. Toggle
-
-The user wants to enable or disable a System.
-
-**Recognize by:** system-control vocabulary -- "turn on", "enable", "disable", "turn off", "activate", "deactivate" -- followed by a System name or description.
-
-**Fixture examples:**
-
-| Input                           | Why it's Toggle                              |
-| ------------------------------- | -------------------------------------------- |
-| "Turn on the lead-gen system"   | Explicit "turn on" + System name             |
-| "Disable monitoring for now"    | "Disable" + System reference                 |
-| "We don't use SEO, turn it off" | Declarative + "turn it off" = System disable |
-
-**Agent action:** delegate to `/om systems`. The ceremony (confirm + edit `core/config/organization-model.ts` + typecheck) belongs to `/om`, not to the ambient rule.
-
-**Tenant-local only.** Toggle operates on the tenant's own `core/config/organization-model.ts` — the project's own Systems. Platform-level Systems (the Elevasis monorepo's `packages/elevasis-core/src/organization-model/`) are not in scope; tenants cannot toggle them and vibe must not pretend they can. If a user names a platform-only System, surface the boundary in plain language rather than attempting a toggle.
-
-### 8. Operate
-
-The user wants to run an already-deployed workflow or agent against the platform — kick off an execution, not change configuration.
-
-**Recognize by:** action verbs "run", "execute", "launch", "trigger", "kick off", "start" combined with a named deployed resource (a workflow id, agent name, or named pipeline). Distinguish from:
-
-- **Capture** — "remember to run X" is a persisted reminder/schedule, not an immediate execution.
-- **Transition** — "the run is done" is a status change on an existing execution, not a new run.
-- **Codify** — "add a workflow called X" is a model change, not an execution of an existing one.
-
-**Fixture examples:**
-
-| Input                                            | Why it's Operate                               |
-| ------------------------------------------------ | ---------------------------------------------- |
-| "Run the daily-digest workflow"                  | "Run" + named deployed resource                |
-| "Kick off the lead-gen pipeline for ZentaraHQ"   | "Kick off" + named resource + named scope      |
-| "Execute the campaign builder against this list" | "Execute" + deployed workflow + concrete input |
-| "Launch the apify-init agent now"                | "Launch" + named deployed agent                |
-
-**Agent action:** delegate to `/elevasis`. The describe-then-exec ceremony belongs to that skill, not to the ambient rule:
-
-1. `elevasis-sdk describe <resourceId>` to fetch the deployed resource's input contract.
-2. Draft the input payload from the user's natural-language phrasing.
-3. Confirm with the user (plain-language summary of payload + target).
-4. `elevasis-sdk exec <resourceId> --input '{…}'` to run it.
-
-**Runs already-deployed resources only.** Operate never deploys, never creates, never edits the workflow source. If the named resource is not deployed, surface that in plain language and offer to route to Codify (define it) or Capture (record a follow-up) — do not attempt to deploy from the ambient rule.
+Vibe is **ambient and always on**. Every natural-language message is silently classified into one of the intents below before the agent responds -- no slash command, no activation phrase, no `/vibe`. This applies to sessions inside external projects; ambient routing is off inside the Elevasis monorepo.
 
 ## Quick Reference Table
 
@@ -226,48 +24,24 @@ The user wants to run an already-deployed workflow or agent against the platform
 | Toggle     | "enable", "disable", "turn on/off" + system                                    | Delegate to `/om systems` (tenant-local only)                                      |
 | Operate    | "run", "execute", "launch", "trigger", "kick off", "start" + deployed resource | Delegate to `/elevasis` -- `elevasis-sdk describe` + confirm + `elevasis-sdk exec` |
 
-## Source of Truth for Plain Language
-
-All plain-language labels come from the OrganizationModel itself -- never from hardcoded strings in this rule file. Every status, entity kind, and layer name in the model carries an inline `label` field (e.g., `{ id: 'revision_requested', label: 'changes needed', semanticClass: 'blocked' }`). When narrating state or confirming an action, read the label from the model and use it verbatim. Do not invent synonyms or fallback vocabulary.
-
-The unified manifest (delivered via `@elevasis/core/organization-model`) is the canonical vocabulary surface. Vibe classifies against it -- Systems, Actions, statuses, operations entities, and resource kinds are all discoverable from the manifest without hardcoding.
-
-## Ambiguous Intent
-
-When the user's input does not clearly map to one of the seven types, ask one clarifying question. Do not guess. Do not apply a precedence rule. Do not route to the "closest" intent.
-
-Format: a single neutral question that presents the two (or three) plausible intents as options and asks which the user means.
-
-Example: "That could be a note to capture or a status update on the current task -- which did you mean?"
-
-Never ask more than one question per ambiguous input. If the user's reply is still ambiguous, ask once more, then surface the options explicitly.
-
-## Classifier Threshold
-
-Default threshold: `balanced`.
-
-The threshold controls how aggressively the classifier proposes codification from ambiguous signals:
-
-- `strict` -- only explicit declarations or repeat mentions trigger codify proposals
-- `balanced` -- second mention OR explicit declaration triggers; default
-- `loose` -- first strong signal triggers a proposal
-
-Override per project in `core/config/organization-model.ts` under `vibe.classifierThreshold`. The override is merge-aware (Tier 2 sync) and will not be overwritten by template sync operations.
-
-## Phase-1 Scope
+## Safety Boundaries
 
-This rule covers Phase 1 of the vibe layer rollout. The layers the ambient classifier can narrate and codify in Phase 1 are:
+- **Never write without confirming.** Draft the change in plain language, confirm with the user, then execute. This gates every Capture, Transition, Codify, Toggle, and Operate route without exception.
+- **Never auto-execute a deployed resource.** Operate runs `elevasis-sdk describe` first, drafts the payload, confirms, then runs `exec`. It never deploys, never creates, never edits workflow source.
+- **Never write the model yourself.** Codify and Toggle detect intent and delegate to `/om <domain>`; the draft-confirm-write-typecheck ceremony belongs to `/om`.
+- **Never flip public agent exposure.** Making a deployed agent reachable on the public internet (the `agent_access_grants` row behind `/public/agents/:slug`, managed via `grant:create` / `grant:update` / `grant:disable` or the Resource-page public/private toggle) is a security boundary deliberately kept out of ambient routing -- a non-technical user describing their business must never expose an agent by accident. Do NOT classify "make my agent public" / "put the interview online" as Toggle, and do NOT auto-execute. Surface the `grant:*` CLI or the Resource-page toggle in plain language and require explicit confirmation.
+- **Toggle is tenant-local.** It edits this project's own `core/config/organization-model.ts` only. The Elevasis platform's own Systems cannot be toggled from here; surface that boundary rather than attempting it.
+- **Never guess an ambiguous intent.** Ask one neutral clarifying question presenting the plausible intents. Do not apply a precedence rule and do not route to the "closest" match.
+- **Never invent vocabulary.** Status, entity, and layer names come from the model's inline `label` fields, read verbatim -- never hardcoded synonyms.
 
-- Layer 1 (Model): narrate schema shape, propose codification edits via `/om`
-- Layer 4 (Systems/Actions): describe which Systems are on/off, propose enabling one via `/om`
-- Layer 7 (Foundations): explain and edit `organization-model.ts` and `extensions/` via `/om`
+## Related Rules
 
-Layers 2 (Public API), 3 (UI Shell Runtime), 5 (Toolkit), and 6 (Graph) require runtime read APIs that are not yet available. Do not attempt to narrate or classify against those layers in Phase 1. If the user's input clearly references one of those layers, acknowledge the scope and explain that full support arrives in a later phase.
+- **vibe-intents.md** -- the detail body; open it when a message is hard to classify or a route needs its exact ceremony
+- **organization-model.md** -- the `/om` entry point Codify and Toggle delegate to
+- **organization-os.md** -- Systems, Actions, and ontology vocabulary the classifier matches against
+- **agent-start-here.md** -- session bootstrap that runs before the first classified message
 
-## What Vibe Is Not
+## References
 
-- Vibe is not a slash command. There is no `/vibe` invocation (decision #19 -- ambient rule, not a skill or command).
-- Vibe is not a skill. It lives in this rule file + CLAUDE.md + the PreToolUse hook -- not in `.claude/skills/`.
-- Vibe does not own the codify ceremony. `/om` owns draft, confirm, write, and typecheck for both Level A and Level B codify pipelines (decision #21 -- Codify ceremony delegated to `/om`). Vibe detects intent and hands off.
-- Vibe is not active in the monorepo. If working inside the monorepo (not an `external/` project), this ambient routing does not apply.
-- Vibe does not flip **public agent exposure**. Making a deployed agent reachable on the public internet (the `agent_access_grants` row behind `/public/agents/:slug`, managed via `grant:create` / `grant:update` / `grant:disable` or the Resource-page public/private toggle) is a **security boundary deliberately kept out of ambient routing** — a non-technical user describing their business must never be able to expose an agent by accident. This is a deliberate non-route, not an unhandled gap: do NOT classify "make my agent public" / "put the interview online" as Toggle (which is System on/off) and do NOT auto-execute. Surface the `grant:*` CLI or the Resource-page toggle in plain language and require explicit confirmation.
+- `operations/node_modules/@elevasis/sdk/reference/rules/vibe-intents.md` -- per-intent recognition signals, fixture examples, exact agent actions, stage/state sub-routing, the classifier threshold, and phase scope
+- `core/config/organization-model.ts` -- label vocabulary, System availability, and the `vibe.classifierThreshold` override

package/reference/scaffold/core/organization-graph.mdx

@@ -1,113 +1,127 @@
----
-title: Organization Graph
+---
+title: Organization Graph
 description: Organization OS graph layer documentation for the organization graph derived from Organization Model Systems, resources, actions, entities, ontology catalogs, and typed links.
----
+---
 <!-- @generated by packages/sdk/scripts/copy-reference-docs.mjs -- DO NOT EDIT -->
 <!-- Regenerate: pnpm scaffold:sync -->
 
-
-## Overview
-
-The organization graph treats the organization model as the top-level ontology and bridges in Command View runtime topology. Command View is a lens over the shared graph, not a separate semantic model.
-
-Graph contracts live in `@repo/core`; rendering lives in `@repo/ui`.
-
-## Source of Truth
-
-- `packages/core/src/organization-model/graph/types.ts`
-- `packages/core/src/organization-model/graph/schema.ts`
-- `packages/core/src/organization-model/graph/build.ts`
-- `packages/core/src/organization-model/graph/link.ts`
-- `packages/core/src/organization-model/__tests__/graph.test.ts`
-- `packages/ui/src/features/operations/OrganizationGraphPage.tsx`
-- `packages/ui/src/features/operations/organization-graph/`
-
-## Model
-
-Node kinds:
-
-- `organization`
-- `system`
-- `role`
-- `action`
-- `entity`
-- `event`
-- `resource`
-- `knowledge`
-- `policy`
-- `stage`
-- `customer-segment`
-- `offering`
-- `goal`
-- `surface`
-- `navigation-group`
-
-Edge kinds:
-
-- `contains`
-- `references`
+
+## Overview
+
+The organization graph treats the organization model as the top-level ontology and bridges in Command View runtime topology. Command View is a lens over the shared graph, not a separate semantic model.
+
+Graph contracts live in `@repo/core`; rendering lives in `@repo/ui`.
+
+## Source of Truth
+
+- `packages/core/src/organization-model/graph/types.ts`
+- `packages/core/src/organization-model/graph/schema.ts`
+- `packages/core/src/organization-model/graph/build.ts`
+- `packages/core/src/organization-model/graph/link.ts`
+- `packages/core/src/organization-model/__tests__/graph.test.ts`
+- `packages/ui/src/features/operations/OrganizationGraphPage.tsx`
+- `packages/ui/src/features/operations/organization-graph/`
+
+## Model
+
+Node kinds:
+
+- `organization`
+- `system`
+- `client`
+- `role`
+- `action`
+- `entity`
+- `event`
+- `resource`
+- `knowledge`
+- `policy`
+- `stage`
+- `customer-segment`
+- `offering`
+- `goal`
+- `surface`
+- `navigation-group`
+- `ontology`
+
+`ontology` nodes are projected from compiled `System.ontology` scopes; `client` nodes come from the `clients` domain.
+
+Edge kinds:
+
+- `contains`
+- `references`
 - `maps_to`
 - `uses`
 - `governs`
 - `links`
 - `affects`
 - `emits`
-- `originates_from`
-- `triggers`
-- `applies_to`
+- `originates_from`
+- `triggers`
+- `approval`
+- `applies_to`
 - `effects`
+- `actions`
+- `reads`
+- `writes`
+- `uses_catalog`
+
+`approval`, `actions`, `reads`, `writes`, and `uses_catalog` are resource-ontology-binding and topology edge kinds; `relationshipType` on an edge (when present) is a closed `triggers | uses | approval` subset used for topology edges specifically.
 
 `governed-by` is a Knowledge Graph route verb for traversing incoming `governs` edges; it is not an Organization Graph edge kind.
-
-System nodes come from the id-keyed `OrganizationModel.systems` map. Their graph IDs use `system:<id>`, such as `system:sales.crm`.
-
+
+System nodes come from the id-keyed `OrganizationModel.systems` map. Their graph IDs use `system:<id>`, such as `system:sales.crm`.
+
 Resource, action, entity, policy, navigation, and ontology catalog edges are derived from canonical OM maps:
-
-```ts
-// ResourceEntry.systemPath => system -> resource contains
-// SystemEntry.actions[] => system -> action uses
-// Action.resourceId => action -> resource maps_to
-// Action.affects[] => action -> entity affects
-// Entity.links[] => entity -> entity links
-// ResourceEntry.emits[] => resource -> event emits
+
+```ts
+// ResourceEntry.systemPath => system -> resource contains
+// SystemEntry.actions[] => system -> action uses
+// Action.resourceId => action -> resource maps_to
+// Action.affects[] => action -> entity affects
+// Entity.links[] => entity -> entity links
+// resource.ontology.emits[] => resource -> event emits (canonical binding)
+// top-level ResourceEntry.emits[] => compatibility mirror for graph event projection
 // System.ontology.catalogTypes => ontology catalog nodes and relationships
-// AgentResource.invocations[] => agent resource -> invocation target uses/references
-```
-
-## Build Pipeline
-
-```ts
-interface BuildOrganizationGraphInput {
-  organizationModel: OrganizationModel
-  commandViewData?: CommandViewData
-}
-```
-
-`buildOrganizationGraph`:
-
-1. Reads Organization Model Systems and derives `system:*` nodes.
-2. Reads OM resources, including workflow, agent, integration, and script resources, as `resource` nodes.
+// AgentResource.invocations[] => agent resource -> invocation target uses/references
+```
+
+## Build Pipeline
+
+{/* doc-snippet:skip: shape excerpt from graph/types.ts -- OrganizationModel and CommandViewData are shown unimported here for readability */}
+
+```ts
+interface BuildOrganizationGraphInput {
+  organizationModel: OrganizationModel
+  commandViewData?: CommandViewData
+}
+```
+
+`buildOrganizationGraph`:
+
+1. Reads Organization Model Systems and derives `system:*` nodes.
+2. Reads OM resources, including workflow, agent, integration, and script resources, as `resource` nodes.
 3. Emits derived graph links from System, Resource, Action, Entity, Policy, Agent invocation, Knowledge, navigation, and ontology catalog contracts.
-4. Bridges Command View runtime topology into resource nodes and relationship edges.
-5. Returns a renderer-agnostic DTO.
-
-## Lenses
-
-UI lenses change presentation, not data:
-
-- `default` -- broad map view.
-- `command-view` -- operations-focused trace view.
-
-## Package Boundary
-
-- `@repo/core` owns graph DTOs, schemas, and build helpers.
-- `@repo/ui` owns Cytoscape conversion, filtering, path tracing, panels, and presentation.
-- `apps/command-center` owns route wiring.
-
-## Verification
-
-```bash
-pnpm --filter @repo/core test -- organization-model graph
-pnpm --filter @repo/ui test -- organizationGraph
-pnpm --filter command-center build
-```
+4. Bridges Command View runtime topology into resource nodes and relationship edges.
+5. Returns a renderer-agnostic DTO.
+
+## Lenses
+
+UI lenses change presentation, not data:
+
+- `default` -- broad map view.
+- `command-view` -- operations-focused trace view.
+
+## Package Boundary
+
+- `@repo/core` owns graph DTOs, schemas, and build helpers.
+- `@repo/ui` owns Cytoscape conversion, filtering, path tracing, panels, and presentation.
+- `apps/command-center` owns route wiring.
+
+## Verification
+
+```bash
+pnpm --filter @repo/core test -- organization-model graph
+pnpm --filter @repo/ui test -- organizationGraph
+pnpm --filter command-center build
+```