minutework 0.1.45 → 0.1.47

package/assets/claude-local/CLAUDE.md.template

@@ -42,6 +42,12 @@ workspace state. It is wired for Cursor (`.cursor/mcp.json`) and Codex
 `mcp/claude-desktop.sample.json`. Refresh all of this with
 `minutework workspace sync-assets`.
 
+Primitive catalog membership does not imply executability or agent exposure;
+check the live-status block in skills/runtime-capability-inventory/SKILL.md and
+the minutework_runtime_primitive_status workspace MCP tool before authoring
+against a primitive (interim paths:
+skills/runtime-primitive-interim-paths/SKILL.md).
+
 ## Hosted Sandbox Runtime
 
 Use `minutework sandbox create` to provision and link the workspace to its
@@ -63,6 +69,10 @@ coding agent can use them as reference: browse `skills/` and read the relevant
 automatically and `/skill-name` invokes one directly; other agents (Codex,
 Cursor) can open the files directly or ask "What skills are available?".
 
+When the task involves event-driven behavior or reacting to external/reference
+datasets, read `skills/event-bus/SKILL.md` and
+`skills/cross-server-subscriptions/SKILL.md`.
+
 ## Capability Gaps
 
 When a request exposes missing shared MinuteWork substrate, read

package/assets/claude-local/skills/README.md

@@ -52,6 +52,7 @@ Generated-workspace-first guidance should live here, especially:
 - `workspace-guidance-refresh/SKILL.md`
 - `shell-architecture/SKILL.md`
 - `runtime-capability-inventory/SKILL.md`
+- `runtime-primitive-interim-paths/SKILL.md`
 - `integration-broker-and-connectors/SKILL.md`
 - `layering-and-import-modes/SKILL.md`
 - `standalone-mobile-client/SKILL.md`

package/assets/claude-local/skills/ai-capability-defaults/SKILL.md

@@ -23,6 +23,8 @@ generation, itinerary generation, content generation, or structured-output UX.
 - Start with `minutework_capability_inventory` and the generated workspace
   capability guidance before assuming runtime AI capability is present,
   missing, or unsupported.
+- When a needed primitive is catalogued but not yet executable or agent-exposed,
+  use the sanctioned interim paths in `runtime-primitive-interim-paths/SKILL.md`.
 - If runtime AI availability is unclear, inspect the linked runtime/workspace
   context or ask a clarifying question before inventing new AI infrastructure.
 - When AI drafting or generation touches external participants, guests,

package/assets/claude-local/skills/cross-server-subscriptions/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: cross-server-subscriptions
+description: "Reacting to changes in another server's published dataset: discovering dataset publications and declaring cross-server subscription candidates."
+---
+
+# Cross-Server Subscriptions
+
+Use this skill when the app should react to changes in another server's
+published dataset -- for example keeping a local mirror of a partner's
+registry, directory, or catalog feed in sync.
+
+The etiquette is law:
+**install proposes; only operators approve; nothing you build activates a cross-server subscription.**
+Two distinct operator acts stand between your declaration and any delivery.
+
+## Discover First
+
+Before declaring a candidate, list what the tenant could actually subscribe
+to. Both surfaces are read-only and can never create or activate anything:
+
+- Workspace MCP tool: `minutework_discover_dataset_publications`.
+- CLI: `minutework workspace discover-publications [--json]`.
+
+Each result row describes one publication: `publication_ref` (the stable
+reference to cite in your candidate reasoning), `event_family`,
+`subject_key`, `event_types`, `residency_classification`, `publisher`
+(`display_name`, `is_self`), and `registered_at`. Rows owned by your own
+tenant additionally carry `status` and `descriptor_digest`.
+
+- Discovery is flag-gated platform-side: when the feature is off the platform
+  returns HTTP 503 and the tools report an explicit empty list with
+  diagnostics, not a guess.
+- HTTP 401 means the developer token is stale: run `minutework login` and
+  retry.
+
+## Candidate Vocabulary
+
+Declare interest with `crossServerSubscriptionCandidates` in
+`schemas/schema.ts` (or `schema.mw`):
+
+- `id`: workspace-authored candidate identifier (shares one id namespace with
+  `eventSubscriptions`).
+- `eventPattern`: exact `<family>.<verb>` or trailing `<family>.*`. The v1
+  family is `dataset` with verbs `records_added` and `snapshot_refreshed`;
+  Core's registry, not the compiler, decides which families exist. Because
+  the compiler does not validate family names against that registry, a
+  candidate that compiles clean can still be rejected at report time as an
+  unknown family -- the rejection is receipted for operators and the local
+  declaration stays put; the fix is changing the pattern, whose new digest
+  reports afresh.
+- `subjectKey`: the correlation key the candidate expects on delivered
+  events (match it to the publication's `subject_key`).
+- `publisherHint` (optional): which publisher you expect, as a hint for the
+  reviewing operator.
+- `reason` (required): shown verbatim to the reviewing operator. Write it for
+  a human: say what the flow does with the data and why the subscription is
+  needed, not compiler-speak.
+- `targetFlow`: a flow declared in the same pack; it is what would wake if an
+  operator ever approves delivery.
+
+Candidates and `eventSubscriptions` share one `(pattern, targetFlow)` pair
+namespace in addition to the id namespace: each candidate compiles to its own
+local subscription half, so declaring an explicit local subscription with the
+same pair is a compile error
+(`compiler.event_subscription.duplicate_pattern_target`). Candidate-implied
+subscriptions carry no filters.
+
+## What Install Does -- And Does Not Do
+
+At install, each candidate:
+
+- Wires its local half: the local subscription that would wake `targetFlow`
+  IF the cross-server side is ever operator-approved. The local row alone is
+  inert and harmless.
+- Is declared runtime-locally with a declared/reported/withdrawn lifecycle
+  keyed by `candidate_digest`. Reinstalling a pack withdraws candidates whose
+  digests are absent from the new install.
+- May later be reported upward to Core as a proposal -- that reporting sweep
+  is itself flag-gated (`MW_CROSS_SERVER_CANDIDATE_REPORTING_ENABLED`,
+  default off). The same sweep reports withdrawals, so a still-pending Core
+  proposal is withdrawn when its digest disappears from a reinstall.
+
+Operators review reported proposals on the platform operator console. They
+may dismiss a proposal, or promote it into a pending-approval subscription
+that still requires a second digest-checked operator approval before anything
+is active. Promotion scopes that subscription from an active, family-matched
+publisher registration the operator picks -- your `subjectKey` and
+`publisherHint` are advisory input to that choice, not binding scope. Either
+operator decision is durable: re-reporting an unchanged digest is an
+idempotent duplicate and never resurrects a dismissed, promoted, or withdrawn
+proposal. The etiquette again:
+**install proposes; only operators approve; nothing you build activates a cross-server subscription.**
+
+Do not present an installed candidate as a working feed. Until both operator
+acts happen, no cross-server event will ever arrive.
+
+## Worked Example
+
+A subscriber pack that mirrors a generic upstream registry publication: one
+flow and one candidate. The candidate's implied local half is the pack's only
+subscription -- do not also declare an explicit `eventSubscriptions` entry
+with the same `(pattern, targetFlow)` pair; the candidate already implies
+that local half, so the duplicate is a compile error.
+
+```ts
+flows: [
+  {
+    id: "registry.sync_entry",
+    description:
+      "Upsert one local mirror entry when upstream registry records change.",
+  },
+],
+crossServerSubscriptionCandidates: [
+  {
+    id: "registry.upstream_feed_candidate",
+    eventPattern: "dataset.records_added",
+    subjectKey: "entry_ref",
+    publisherHint: "partner-registry",
+    reason:
+      "Keep this tenant's local registry mirror current so member-facing " +
+      "lookups reflect the partner registry without manual re-imports.",
+    targetFlow: "registry.sync_entry",
+  },
+],
+```
+
+The flow body should be replay-safe (for example, upsert the mirror record
+keyed on the event's opaque record ref) because wake delivery is
+at-least-once with deterministic convergence.
+
+## Staleness
+
+If this guidance looks stale or the discovery tooling seems missing, refresh
+managed workspace assets with `minutework workspace sync-assets` (see
+`skills/workspace-guidance-refresh/SKILL.md`).

package/assets/claude-local/skills/dataset-subscriber-flow/SKILL.md

@@ -0,0 +1,186 @@
+---
+name: dataset-subscriber-flow
+description: "A tenant wants their app or agent to react when an external or reference dataset changes: discovery-first subscriber packs over published cross-server datasets."
+---
+
+# Dataset Subscriber Flow
+
+Use this skill when the tenant goal is "react when that external or reference
+dataset changes" -- new records landing in a shared registry, a refreshed
+directory snapshot, a catalog another server publishes. The answer is a
+discovery-first, declarative subscriber pack -- never scraping, polling, or
+replicating the upstream dataset.
+
+Work the three steps in order. Do not skip discovery, and do not promise
+activation: that is an operator decision, not a build output.
+
+## Step 1 -- Discover
+
+Find out what is actually published before designing anything.
+
+- From a generated workspace, call the workspace MCP tool
+  `minutework_discover_dataset_publications`, or run:
+
+  ```bash
+  minutework workspace discover-publications
+  ```
+
+  (add `--json` for machine-readable output). Both call the platform
+  discovery API with the workspace's tenant-bound developer token. Discovery
+  is read-only: listing a publication grants nothing and subscribes to
+  nothing.
+- Interpret each result row:
+  - `publication_ref` -- the publication's stable opaque handle. Nothing
+    links a candidate to a `publication_ref` automatically, so echo the
+    matched publication's details into the candidate's `publisherHint` and
+    `reason` so the reviewing operator can find it.
+  - `event_family` and `event_types` -- what change signals exist. The v1
+    family is `dataset` with verbs `dataset.records_added` and
+    `dataset.snapshot_refreshed`.
+  - `subject_key` -- the correlation key delivered events will carry; your
+    candidate's `subjectKey` should match it.
+  - `residency_classification` -- how widely the publisher says the data may
+    travel; respect it when deciding what to mirror locally.
+  - `publisher` (`display_name`, `is_self`) -- who publishes it;
+    `is_self` means your own tenant.
+  - `registered_at`; own-tenant rows additionally show `status` and
+    `descriptor_digest`.
+- Expected failure modes: a `503` means the platform discovery surface is
+  flag-gated off; a `401` means the developer token is missing or expired --
+  run `minutework login`.
+- If nothing discoverable matches the tenant's dataset, **stop scaffolding**.
+  Do not improvise an ingestion path: no scraping the upstream surface, no
+  polling its APIs, no replicating its data into local records. Route to an
+  operator conversation instead -- record the missing publication as a
+  capability gap (see `skills/capability-gap-reporting/SKILL.md`) and let
+  humans decide whether the upstream side should publish.
+
+## Step 2 -- Scaffold The Subscriber Pack
+
+Build the subscriber declaratively in the workspace schema source
+(`schemas/schema.ts` or `schema.mw`) using three vocabulary keys: `flows`
+(compiled to `FlowManifestV1` documents) plus `eventSubscriptions` and
+`crossServerSubscriptionCandidates` (compiled together into
+`eventSubscriptionManifests` documents, `EventSubscriptionManifestV1`):
+
+- `flows`: `[{ id, description?, definition? }]` -- the local flow the event
+  wakes.
+- `eventSubscriptions`: `[{ id, eventTypePattern, targetFlow, filters? }]` --
+  local wiring for events that already reach this runtime (also valid on
+  connector packs). For cross-server dataset events you usually do not need
+  one: the candidate below implies it.
+- `crossServerSubscriptionCandidates`:
+  `[{ id, eventPattern, subjectKey, publisherHint?, reason, targetFlow }]` --
+  the proposal that a human operator will review.
+
+Generic worked sketch (a tenant whose app should react when a shared
+directory server publishes new registry entries):
+
+```ts
+flows: [
+  {
+    id: "flow.registry_change_intake",
+    description: "Mirror new upstream registry entries into local records.",
+  },
+],
+crossServerSubscriptionCandidates: [
+  {
+    id: "cand.registry_records_added",
+    eventPattern: "dataset.records_added",
+    subjectKey: "registry_entry_id",
+    publisherHint: "shared-directory-server",
+    reason:
+      "Keep this tenant's local supplier catalog current by waking the " +
+      "registry intake flow when the upstream directory publishes new " +
+      "entries; without it the catalog goes stale between manual checks.",
+    targetFlow: "flow.registry_change_intake",
+  },
+],
+```
+
+There is deliberately no plain `eventSubscriptions` entry in this sketch: the
+candidate alone compiles the local subscription half that wakes
+`flow.registry_change_intake`. The implied local half carries no `filters`,
+so any narrowing (for example, reacting only to `supplier` entries) belongs
+inside the woken flow.
+
+Authoring rules the compiler enforces:
+
+- Patterns are exact `<family>.<verb>` or a trailing `<family>.*` only; no
+  embedded `*`. The compiler does NOT validate family names against Core's
+  registry -- Core is the single source of truth for which families exist.
+- Filter operators are the verbatim runtime vocabulary: `eq`, `neq`, `in`,
+  `not_in`, `gt`, `gte`, `lt`, `lte`, `contains`, `starts_with`. Filters AND
+  together.
+- Duplicate `(pattern, targetFlow)` pairs and duplicate filters are compile
+  errors; `targetFlow` must name a flow in the same pack.
+- Candidates count toward the `(pattern, targetFlow)` pairs -- each candidate
+  compiles its own local subscription half (with no filters) -- so do not
+  also declare a plain `eventSubscription` for the same pair.
+- Write the candidate `reason` for the human operator who will review it: say
+  what the flow does with the events and why the tenant needs them. It is
+  shown verbatim to the reviewer; a vague reason earns a dismissal.
+
+Keep the woken flow replay-safe (delivery is at-least-once): idempotent local
+record upserts keyed on the event's record reference, and any effectful
+follow-up the flow proposes parks in the existing human-approval loop rather
+than executing directly.
+
+## Step 3 -- Etiquette
+
+**install proposes; only operators approve; nothing you build activates a cross-server subscription.**
+
+State this plainly to the tenant. What install actually does:
+
+- A candidate implies its local half: install wires the
+  `LocalEventSubscription` that will wake the flow IF the cross-server side
+  is ever operator-approved. The local row alone is inert and harmless --
+  firing additionally requires the pack to be `ACTIVE` and is globally gated
+  by the runtime flag `MW_LOCAL_EVENT_DISPATCH_ENABLED` (default off). A wake
+  is a deterministic flow-start job per (event, subscription).
+- Subscriptions are replaced per pack at install; an invalid target flow
+  fails the whole install. Candidates are stored runtime-locally with a
+  declared/reported/withdrawn lifecycle keyed by `candidate_digest`;
+  reinstalling withdraws digests no longer declared (withdrawals are reported
+  upward too, withdrawing a still-pending Core proposal).
+- Two operator acts stand between your candidate and a live subscription:
+  stored candidates are reported upward by a flag-gated runtime sweep
+  (`MW_CROSS_SERVER_CANDIDATE_REPORTING_ENABLED`, default off) to Core
+  proposals; operators review them on the platform operator console, where
+  promoting yields a pending-approval subscription that STILL requires a
+  second digest-checked operator approval (or they dismiss the proposal).
+  Either decision is durable: re-reporting an unchanged digest is an
+  idempotent duplicate and never resurrects a dismissed, promoted, or
+  withdrawn proposal -- a fresh proposal needs changed digest-covered content
+  (`eventPattern`, `subjectKey`, or `targetFlow`).
+- Delivery also requires the publisher side to be active and approved. Even a
+  fully approved subscriber receives nothing until the publishing server's
+  side is live.
+
+Never instruct or attempt any of the following: creating or activating a
+cross-server subscription, calling operator review or posture APIs, or
+presenting an installed candidate as a working integration. The honest status
+after install is "proposed, awaiting operator review."
+
+## Disqualifiers
+
+- **Bulk data movement.** If the tenant wants dataset slices copied locally,
+  that is the explicit grant-scoped import/copy flow, not a subscription.
+  Subscriptions deliver change signals, not the dataset.
+- **No discoverable publication.** Route to an operator conversation via the
+  capability-gap path (Step 1); never scrape, poll, or replicate.
+- **Per-customer deliverables.** Outputs for each of the tenant's customers
+  should be runtime content/workflow outputs produced through the installed
+  pack, not a new pack per customer.
+
+## Related Skills
+
+- `skills/cross-server-subscriptions/SKILL.md` -- the full vocabulary and
+  lifecycle detail behind candidates, proposals, and approvals.
+- `skills/event-bus/SKILL.md` -- runtime-local event wiring the woken flow
+  builds on.
+- `skills/capability-gap-reporting/SKILL.md` -- recording the gap when no
+  publication exists.
+- If this skill is missing from an older generated workspace, refresh managed
+  guidance with `minutework workspace sync-assets`
+  (see `skills/workspace-guidance-refresh/SKILL.md`).

package/assets/claude-local/skills/event-bus/SKILL.md

@@ -11,3 +11,73 @@ Use runtime-local events for decoupled app behavior.
 - Keep private payloads, traces, and detailed execution state runtime-local.
 - Project only safe receipts or summaries outward when required.
 - Use explicit filters and targets instead of broad catch-all handlers.
+
+## Source Vocabulary
+
+Declare event-driven behavior in `schemas/schema.ts` (or `schema.mw`):
+
+- `flows`: `[{ id, description?, definition? }]` -- the runnable targets that
+  subscriptions wake.
+- `eventSubscriptions`: `[{ id, eventTypePattern, targetFlow, filters? }]` --
+  local subscriptions. Also valid on connector packs.
+
+Minimal example:
+
+```ts
+flows: [
+  {
+    id: "registry.refresh_entry",
+    description: "Refresh one cached directory entry.",
+  },
+],
+eventSubscriptions: [
+  {
+    id: "registry.entry_updated_sub",
+    eventTypePattern: "directory.entry_updated",
+    targetFlow: "registry.refresh_entry",
+    filters: [
+      { field_path: "payload.status", operator: "eq", value: "active" },
+    ],
+  },
+],
+```
+
+## Pattern Rules
+
+- Patterns are exact `<family>.<verb>` or a trailing `<family>.*` wildcard
+  only. No embedded `*`, no bare `*`.
+- The compiler does not validate family names against Core's registry; Core
+  is the single source of truth for which event families exist.
+
+## Filters
+
+- Operators (verbatim runtime vocabulary): `eq`, `neq`, `in`, `not_in`, `gt`,
+  `gte`, `lt`, `lte`, `contains`, `starts_with`.
+- Multiple filters on one subscription AND together: an event must satisfy
+  every filter to wake the target flow.
+- Duplicate `(pattern, targetFlow)` pairs and duplicate filters are compile
+  errors. `targetFlow` must name a flow declared in the same pack.
+- Cross-server subscription candidates share the same id namespace and count
+  toward `(pattern, targetFlow)` uniqueness, because each candidate implies
+  its local subscription half (see
+  `skills/cross-server-subscriptions/SKILL.md`).
+
+## Dispatch Behavior
+
+- Subscriptions compile into the `eventSubscriptionManifests` document kind
+  and materialize as local subscription rows at install.
+- Flow targets only in v1: a matching event starts the target flow through a
+  deterministic flow-start job per `(event, subscription)` pair, so replays
+  converge on one run instead of double-firing.
+- Firing requires the owning pack to be ACTIVE and is globally gated by the
+  runtime flag `MW_LOCAL_EVENT_DISPATCH_ENABLED` (default off).
+
+## Install Semantics
+
+- Install replaces a pack's subscriptions wholesale (delete-and-recreate per
+  pack, mirroring sidecar registrations).
+- An invalid target flow fails the whole install -- no partial wiring, no
+  partial activation.
+
+For anything that crosses server boundaries (reacting to another server's
+published dataset), read `skills/cross-server-subscriptions/SKILL.md`.

package/assets/claude-local/skills/project-overview-and-strategy/SKILL.md

@@ -37,6 +37,9 @@ needed:
 - `sidecar-generation/SKILL.md` for bridge/integration execution, workers,
   webhooks, schedulers, and backend compute.
 - `standalone-mobile-client/SKILL.md` for Expo/native client boundaries.
+- `dataset-subscriber-flow/SKILL.md` for reacting to published cross-server
+  dataset changes: discovery-first subscriber packs, cross-server candidates,
+  and the operator-approval etiquette.
 - `ontology-mapping/SKILL.md` for shared URNs, overlays, explicit promotion,
   and the data network-effect story.
 - `shadow-participation-and-guest-threads/SKILL.md` for guests, external

package/assets/claude-local/skills/runtime-capability-inventory/SKILL.md

@@ -87,24 +87,83 @@ generated Builder workspace.
 - Collaboration, shadow identity, alias ingress, ontology ownership, and
   thread-routing questions are usually implemented-system questions. Prefer
   source inspection over MCP-only inference for those.
+- For reacting to published cross-server dataset changes (discovery-first
+  subscriber packs, cross-server candidates, and the operator-approval
+  etiquette), route to `skills/dataset-subscriber-flow/SKILL.md`.
 - The gap report contract lives at `.minutework/runtime/capability-gap-report.json`.
 
 ## Known Seeded Primitive Catalog
 
 <!-- builder-doc-sync:active-primitives:start -->
-- Current active primitives by family:
-  - `records`: `records.query`, `records.upsert`
-  - `workflow`: `workflow.run_action`, `workflow.schedule_timer`,
-    `workflow.resume_checkpoint`, `workflow.cancel_on_thread_activity`
-  - `projection`: `projection.publish_receipt`
-  - `integrations`: `integrations.query_provider`,
-    `integrations.execute_automation`
-  - `communication`: `communication.send_email`, `communication.send_sms`
-  - `consent`: `consent.check_channel`
-  - `scheduling`: `scheduling.book_appointment`
-  - `discovery`: `discovery.request_proposal`
-  - `voice`: `voice.initiate_call`, `voice.hangup_call`,
-    `voice.get_call_status`
-  - `ontology`: `ontology.resolve_local`, `ontology.propose_candidate`
-  - `command_exec`: `command_exec.run_template`
+- Three-layer rule: catalogued != executor-wired != agent-exposed. Catalog membership
+  never implies a primitive can execute today, and an executor never implies any agent
+  can call it; check each layer separately.
+- Default agent ring is the read-only READ_RING (`records.query`,
+  `app_pack.list_surfaces`, `app_pack.query`); its members need no grant. (`app_pack.*`
+  and `delegate_to_builder` are agent tools, not catalog primitives.) Every other tool
+  needs a per-agent `enable_agent_tools` grant (operator-only). Enabling the effectful
+  `app_pack.action` tool is additionally process-gated on the A1-A3 human-approval
+  surface being live for the tenant plane; surfaces with forced approval park on a human
+  approval before executing.
+- Machine-readable copy with per-primitive live-status fields:
+  `skills/runtime-capability-inventory/primitive-catalog.json` (synced from the runtime
+  fixture). The `minutework_runtime_primitive_status` workspace MCP tool serves the same
+  answer, linked-runtime-backed when a runtime binding exists.
+- Live executors (catalogued and wired today):
+  - `records.query` -- Native agent tool in the default READ_RING: enabled for the
+    provisioning-default agent without any grant.
+  - `records.upsert` -- Effectful; outside the default READ_RING, granted per agent via
+    enable_agent_tools (OPERATOR_RING member).
+  - `workflow.run_action` -- Agents reach this envelope through the app_pack.action tool
+    over manifest-declared agent_exposed action surfaces; approval is decided per target
+    capability/definition.
+  - `workflow.schedule_timer` -- Workflow-internal machinery (WORKFLOW_TIMER jobs); not
+    an agent-callable tool.
+  - `workflow.resume_checkpoint` -- Workflow-internal machinery driven by the jobs
+    worker; not an agent-callable tool.
+  - `workflow.cancel_on_thread_activity` -- Workflow-internal machinery; not an
+    agent-callable tool.
+  - `integrations.query_provider` -- Read-only provider query; preflight fail-closes on
+    connection/secret availability.
+  - `integrations.execute_automation` -- Approval is definition-forced in
+    mw.core.agent_actions (a definition can force approval, never relax it).
+  - `communication.send_email` -- Real provider send (Resend) registered as a metered
+    action capability; preflight fail-closes on connection/secret availability, and the
+    delivery row is idempotent on the ActionRun id with a SENT short-circuit. Not
+    agent-exposed yet: exposure is a separate per-definition mw.core.agent_actions flip.
+  - `communication.send_sms` -- Real provider send (Twilio) registered as a metered
+    action capability; preflight fail-closes on connection/secret availability, and the
+    delivery row is idempotent on the ActionRun id with a SENT short-circuit. Not
+    agent-exposed yet: exposure is a separate per-definition mw.core.agent_actions flip.
+  - `consent.check_channel` -- Service seam consumed by other executors and sidecars as
+    a preflight; not an agent-callable tool.
+  - `discovery.request_proposal` -- Effectful; outside the default READ_RING, granted
+    per agent via enable_agent_tools (BUILDER_DELEGATION_RING member).
+  - `ontology.resolve_local` -- Read-only native tool over
+    URNAnchor/LocalOntologyMapping; not in the default READ_RING, granted per agent via
+    enable_agent_tools.
+  - `command_exec.run_template` -- Operator/platform-dispatch surface; not an
+    agent-callable tool.
+  - `voice.hangup_call` -- VoiceSession finalization is live; the provider-side hangup
+    leg is platform-owned Phase 4. Not an agent-callable tool.
+  - `voice.get_call_status` -- Read-only session status lookup. Not an agent-callable
+    tool.
+- Partial executors (wired with a deferred leg; treat the deferred
+  leg as unavailable):
+  - `scheduling.book_appointment` -- Capability is registered but the direct booking
+    executor is MVP-deferred; preflight truthfully reports provider_unavailable.
+  - `ontology.propose_candidate` -- Staging leg only: records a PENDING
+    PromotionCandidate locally (idempotent on origin_ref+candidate_kind). The
+    cross-plane submission to Core (PENDING -> SUBMITTED -> resolved with a minted
+    core_urn) is a deferred, bridge-owned leg; the promotion service stays
+    platform-owned. Effectful; outside the default READ_RING, granted per agent via
+    enable_agent_tools.
+  - `voice.initiate_call` -- Pre-dial stack is live (consent + TCPA preflight, approval
+    parking, VoiceSession lifecycle); the Twilio dial + realtime media worker are
+    platform-owned Phase 4.
+- Catalogued-only (no executor wired; use the sanctioned interim
+  path):
+  - `projection.publish_receipt` -- Owning services emit receipts through the runtime
+    bridge directly (e.g. command_exec posts its own run receipts); do not build a
+    bespoke generic receipt executor.
 <!-- builder-doc-sync:active-primitives:end -->