minutework 0.1.46 → 0.1.47

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

@@ -69,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/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,6 +87,9 @@ 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
@@ -124,10 +127,21 @@ generated Builder workspace.
     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
@@ -138,6 +152,12 @@ generated Builder workspace.
   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.
@@ -146,16 +166,4 @@ generated Builder workspace.
   - `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.
-  - `communication.send_email` -- Sidecar bridge mirroring the
-    runtime_bridge/integrations transport seam with a consent.check_channel preflight;
-    route sends through the send_notification seam, never inline in runtime. End-state
-    is an action capability like voice.initiate_call.
-  - `communication.send_sms` -- Sidecar bridge mirroring the runtime_bridge/integrations
-    transport seam with a consent.check_channel preflight; route sends through the
-    send_notification seam, never inline in runtime. End-state is an action capability
-    like voice.initiate_call.
-  - `ontology.resolve_local` -- Seed URNAnchor rows at install; treat resolution as a
-    read-only lookup over seeded anchors.
-  - `ontology.propose_candidate` -- Stage PromotionCandidate rows for manual review; the
-    promotion service is platform-owned, do not build it tenant-side.
 <!-- builder-doc-sync:active-primitives:end -->

package/assets/claude-local/skills/runtime-capability-inventory/primitive-catalog.json

@@ -190,13 +190,13 @@
       "requires_integration": true,
       "requires_secret": true,
       "metered": true,
-      "executor_ready": "none",
-      "executor_ref": "",
-      "executor_notes": "Catalogued only: no send executor is registered for this primitive id.",
+      "executor_ready": "live",
+      "executor_ref": "capability:communication.send_email",
+      "executor_notes": "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.",
       "agent_exposable": false,
       "agent_exposure_path": "none",
-      "approval_required": null,
-      "interim_path": "Sidecar bridge mirroring the runtime_bridge/integrations transport seam with a consent.check_channel preflight; route sends through the send_notification seam, never inline in runtime. End-state is an action capability like voice.initiate_call."
+      "approval_required": false,
+      "interim_path": ""
     },
     {
       "primitive_id": "communication.send_sms",
@@ -209,13 +209,13 @@
       "requires_integration": true,
       "requires_secret": true,
       "metered": true,
-      "executor_ready": "none",
-      "executor_ref": "",
-      "executor_notes": "Catalogued only: no send executor is registered for this primitive id.",
+      "executor_ready": "live",
+      "executor_ref": "capability:communication.send_sms",
+      "executor_notes": "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.",
       "agent_exposable": false,
       "agent_exposure_path": "none",
-      "approval_required": null,
-      "interim_path": "Sidecar bridge mirroring the runtime_bridge/integrations transport seam with a consent.check_channel preflight; route sends through the send_notification seam, never inline in runtime. End-state is an action capability like voice.initiate_call."
+      "approval_required": false,
+      "interim_path": ""
     },
     {
       "primitive_id": "consent.check_channel",
@@ -278,39 +278,39 @@
       "primitive_id": "ontology.resolve_local",
       "family": "ontology",
       "display_name": "Resolve Local Ontology",
-      "description": "Resolve a local record against the ontology bundle and Core URNs.",
-      "runtime_app": "runtime_memory",
+      "description": "Resolve a local record against the shared ontology: its fields' Core URN anchors, with app-pack kind mappings as fallback candidates.",
+      "runtime_app": "runtime_ontology",
       "dispatch_path": "",
       "status": "active",
       "requires_integration": false,
       "requires_secret": false,
       "metered": false,
-      "executor_ready": "none",
-      "executor_ref": "",
-      "executor_notes": "Catalogued only: URNAnchor models exist but no resolve executor is wired.",
-      "agent_exposable": false,
-      "agent_exposure_path": "none",
-      "approval_required": null,
-      "interim_path": "Seed URNAnchor rows at install; treat resolution as a read-only lookup over seeded anchors."
+      "executor_ready": "live",
+      "executor_ref": "tool:ontology.resolve_local",
+      "executor_notes": "Read-only native tool over URNAnchor/LocalOntologyMapping; not in the default READ_RING, granted per agent via enable_agent_tools.",
+      "agent_exposable": true,
+      "agent_exposure_path": "native_tool",
+      "approval_required": false,
+      "interim_path": ""
     },
     {
       "primitive_id": "ontology.propose_candidate",
       "family": "ontology",
       "display_name": "Propose Ontology Candidate",
-      "description": "Submit a promotion candidate to Core for shared ontology acceptance.",
-      "runtime_app": "runtime_bridge",
+      "description": "Stage a promotion candidate proposing a local entity/person/location for shared ontology acceptance.",
+      "runtime_app": "runtime_ontology",
       "dispatch_path": "",
       "status": "active",
       "requires_integration": false,
       "requires_secret": false,
       "metered": false,
-      "executor_ready": "none",
-      "executor_ref": "",
-      "executor_notes": "Catalogued only: PromotionCandidate models exist but no propose executor is wired.",
-      "agent_exposable": false,
-      "agent_exposure_path": "none",
-      "approval_required": null,
-      "interim_path": "Stage PromotionCandidate rows for manual review; the promotion service is platform-owned, do not build it tenant-side."
+      "executor_ready": "partial",
+      "executor_ref": "tool:ontology.propose_candidate",
+      "executor_notes": "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.",
+      "agent_exposable": true,
+      "agent_exposure_path": "native_tool",
+      "approval_required": false,
+      "interim_path": ""
     },
     {
       "primitive_id": "command_exec.run_template",

package/dist/cli-json.d.ts

@@ -1,5 +1,5 @@
 export declare const CLI_JSON_VERSION: 1;
-export type CliJsonCommand = "validate" | "compile" | "codegen" | "deploy" | "publish" | "gaps" | "sandbox";
+export type CliJsonCommand = "validate" | "compile" | "codegen" | "deploy" | "publish" | "gaps" | "sandbox" | "workspace";
 export type CliJsonEnvelope = {
     cliJsonVersion: typeof CLI_JSON_VERSION;
     command: CliJsonCommand;

package/dist/cli-json.js.map

@@ -1 +1 @@
-{"version":3,"file":"cli-json.js","sourceRoot":"","sources":["../src/cli-json.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,gBAAgB,GAAG,CAAU,CAAC;AAoB3C;;;;;;GAMG;AACH,MAAM,UAAU,qBAAqB,CAAC,QAMrC;IACC,MAAM,OAAO,GAAoB;QAC/B,cAAc,EAAE,gBAAgB;QAChC,OAAO,EAAE,QAAQ,CAAC,OAAO;QACzB,EAAE,EAAE,QAAQ,CAAC,EAAE;QACf,MAAM,EAAE,QAAQ,CAAC,MAAM;QACvB,MAAM,EAAE,QAAQ,CAAC,MAAM,IAAI,IAAI;QAC/B,KAAK,EAAE,QAAQ,CAAC,KAAK,IAAI,IAAI;KAC9B,CAAC;IACF,OAAO,GAAG,IAAI,CAAC,SAAS,CAAC,OAAO,EAAE,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC;AACjD,CAAC"}
+{"version":3,"file":"cli-json.js","sourceRoot":"","sources":["../src/cli-json.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,gBAAgB,GAAG,CAAU,CAAC;AAqB3C;;;;;;GAMG;AACH,MAAM,UAAU,qBAAqB,CAAC,QAMrC;IACC,MAAM,OAAO,GAAoB;QAC/B,cAAc,EAAE,gBAAgB;QAChC,OAAO,EAAE,QAAQ,CAAC,OAAO;QACzB,EAAE,EAAE,QAAQ,CAAC,EAAE;QACf,MAAM,EAAE,QAAQ,CAAC,MAAM;QACvB,MAAM,EAAE,QAAQ,CAAC,MAAM,IAAI,IAAI;QAC/B,KAAK,EAAE,QAAQ,CAAC,KAAK,IAAI,IAAI;KAC9B,CAAC;IACF,OAAO,GAAG,IAAI,CAAC,SAAS,CAAC,OAAO,EAAE,IAAI,EAAE,CAAC,CAAC,IAAI,CAAC;AACjD,CAAC"}

package/dist/developer-client.d.ts

@@ -217,6 +217,34 @@ export type AgentEventsResponse = {
     next_after_sequence: number;
     thread_id: string;
 };
+/**
+ * One subscribable dataset publication row from the platform discovery read
+ * (`/api/v1/cross-server-events/discovery/publications/`). The keys mirror
+ * the platform's reviewed cross-tenant field whitelist exactly, and the row
+ * shape is normalized to match the workspace MCP discovery tool
+ * (`minutework_discover_dataset_publications`) so both readers of the
+ * endpoint share one effective contract: own-tenant-only fields (`status`,
+ * `descriptor_digest`) are explicit `null` on cross-tenant rows, never
+ * absent keys. Discovery is read-only posture: nothing on this surface can
+ * create or activate a cross-server subscription.
+ */
+export type DeveloperDiscoverableDatasetPublication = {
+    descriptor_digest: string | null;
+    event_family: string;
+    event_types: string[];
+    publication_ref: string;
+    publisher: {
+        display_name: string;
+        is_self: boolean;
+    };
+    registered_at: string;
+    residency_classification: string;
+    status: string | null;
+    subject_key: string;
+};
+export type DeveloperDatasetPublicationDiscoveryResponse = {
+    publications: DeveloperDiscoverableDatasetPublication[];
+};
 export type DeveloperClientDependencies = {
     fetchImpl?: typeof fetch;
 };
@@ -310,6 +338,7 @@ export declare function createDeveloperClient(options: {
         sourceKind?: string;
         status?: string;
     }): Promise<DeveloperBuilderCapabilityRequestListResponse>;
+    listDiscoverableDatasetPublications(): Promise<DeveloperDatasetPublicationDiscoveryResponse>;
     attachAgent(): Promise<AgentAttachResponse>;
     resumeAgent(): Promise<AgentAttachResponse>;
     getAgentStatus(): Promise<AgentStatusResponse>;