minutework 0.1.46 → 0.1.49

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/README.md

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

package/assets/claude-local/skills/app-pack-authoring/SKILL.md

@@ -93,11 +93,13 @@ An `app pack` is the shipped product unit.
   infer access policy from artifact metadata.
 - Public-site authoring should stay CMS/runtime-backed, while anonymous live
   delivery should prefer published snapshots.
-- Prefer this decision order before writing greenfield code:
+- Prefer this decision order before writing greenfield code (route a fresh
+  request through `solution-router/SKILL.md` first):
   - reuse existing MinuteWork substrate or a reviewed capability skill
   - extend app-pack/schema/flow surfaces
   - adopt a strong OSS library or product when it clearly fits
-  - use `attached_app` when the foreign system should stay its own subsystem
+  - use `attached_app` when the foreign system should stay its own subsystem;
+    see `attached-app/SKILL.md` for the authoring procedure
   - use repo intake or greenfield code only when the cleaner options do not fit
 - If a mature OSS product already solves the problem well, prefer integrating,
   wrapping, or governing it instead of rebuilding it from scratch.

package/assets/claude-local/skills/attached-app/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: attached-app
+description: "Authoring a governed control surface around a mature foreign subsystem the tenant hosts: declare attachment, bridge, projection, and health metadata; compile to a declarative or hybrid app pack plus subordinate metadata; never a new app class."
+---
+
+# Attached App
+
+Use this skill when a mature foreign subsystem the tenant already hosts should
+stay its own system of record while MinuteWork compiles a governed control
+surface around it -- typed actions, governed reads, policy, federation -- rather
+than rewriting it natively or reshaping it into a sidecar. Reach this skill
+through `solution-router/SKILL.md` once the selected mode is `attached_app`.
+
+## The boundary (read first)
+
+These rules are non-negotiable; an attach that breaks one has become a second
+install system:
+
+- `attached_app` is a deployment and authoring **mode**, not an `app_class`. It
+  never becomes `app_class = attached_app`; it compiles to an existing class --
+  normally `declarative` or `hybrid` -- plus **subordinate** attachment
+  metadata. It is never a parallel activation path.
+- the foreign system may remain the domain-data system of record, but it is not
+  itself the trusted install contract. The compiled manifest graph is the only
+  authoritative activation surface.
+- generated APIs stay manifest-driven even here: reads come from `QueryManifest`,
+  writes from `ActionManifest`, custom routes from `RouteManifest`, and docs
+  derive from the active schema and manifests.
+- the foreign subsystem must report healthy through its **declared health
+  checks** before the generated manifests may become `active`.
+
+## When to use, and when not
+
+Use when the upstream system is already mature and intact, rewriting it would be
+wasteful, the tenant wants AI control/governance/federation over it more than a
+deep rewrite, and it can keep its own subsystem boundary while exposing typed
+verbs through a generated adapter.
+
+Do not use when:
+
+- the system is a remote third-party SaaS reached over its API -- that is a
+  `connector`, not an attach.
+- the tenant wants MinuteWork to own the data natively from day one -- that is
+  build-native / `native_pack`.
+- the code is unfinished and you would clone it to co-develop it -- that is
+  `external_repo_intake` toward a code-backed pack, a different combination on a
+  different axis. Attach a system **once it is a working, intact subsystem**
+  (build-then-attach), not before.
+
+## Authoring procedure
+
+The procedure is identical for every domain. All domain identity comes from the
+selected reviewed instance and the manifests the tenant authors -- never from
+this skill.
+
+### Step 1 -- Identify the foreign subsystem
+
+Confirm it is mature, intact, and tenant-hosted, with a typed surface (an HTTP
+API, a DRF layer, an ORM the adapter can reach). Capture its base location and
+how it authenticates as a **secret reference**, never a literal credential (see
+`secrets-runtime-bridge/SKILL.md`). If credentials, provider writes, spend, or
+audit receipts are involved, route the adapter through broker substrate (see
+`integration-broker-and-connectors/SKILL.md`).
+
+### Step 2 -- Declare the subordinate attachment metadata
+
+These are subordinate documents and refs inside the standard graph, not a second
+pipeline:
+
+- `AttachedApp` -- the foreign base plus its auth reference.
+- `BridgeAdapter` -- how typed verbs reach the foreign system.
+- `ProjectionContract` -- the governed projected read shape: safe summaries,
+  receipts, and selected previews. It does not imply a one-to-one mirror of
+  every foreign table or endpoint.
+- declared health checks -- the endpoints that define "ready."
+- optional `PolicyLayer` / `ProjectionPolicy` for bounds and redaction.
+
+### Step 3 -- Emit the standard governed artifact graph
+
+- `AppManifest` with `app_class = declarative` or `hybrid` (`hybrid` when
+  runtime-native records or code sit alongside the projection).
+- `ActionManifest` for every write/mutation verb.
+- `QueryManifest` for every read.
+- `RouteManifest` for internal callbacks or bounded adapter routes.
+- `FlowManifest` for sync cadence, retry, and operator-escalation runbooks.
+- `OntologyMappingManifest` mapping foreign objects onto shared URNs.
+- `ProjectionContract` and a `PromotionRule` set.
+- optionally a tenant-facing `SkillManifest` for operator/downstream-agent verbs.
+
+### Step 4 -- Wire the health gate
+
+Bind the declared health checks so the foreign subsystem must report ready
+before activation. On a failed or unready check the install parks in a retriable
+non-active state -- never a silent activate. An attach into an already-active
+workspace must health-gate the new attached surface without disturbing the
+existing active app.
+
+## Worked examples (illustrative instances, not framework)
+
+Two different domains run through the **same** Steps 1-4 above; only the selected
+instance and the authored manifests change. These are reviewed-skill instances,
+not part of the framework.
+
+### Example A -- a self-hosted commerce backend
+
+*Illustrative instance, e.g. the `commerce.medusa_attached_app` reviewed seed --
+not framework.* A tenant self-hosts a mature commerce engine and wants AI to
+operate merchant workflows while the engine stays the system of record. Author:
+`AttachedApp` + `BridgeAdapter` over the engine; a `ProjectionContract` for
+order/inventory summaries and receipts; health checks on the engine; an
+`AppManifest` (`hybrid`); `ActionManifest` writes (e.g. `commerce.create_product`,
+`commerce.issue_refund`) bounded by policy (refunds above a threshold require
+approval); `QueryManifest` reads (e.g. `commerce.list_orders`,
+`commerce.low_inventory_report`); `FlowManifest` recovery runbooks. Compiles
+`hybrid` + subordinate attachment metadata.
+
+### Example B -- a self-hosted regulatory data-plane
+
+*Illustrative instance, e.g. the `datalake.fmcsa_attached_app` reviewed seed --
+not framework.* A tenant self-hosts a large regulatory dataset subsystem
+(scheduled ingestion, a relational store) and wants other runtimes and agents to
+query it through governed verbs while it stays the system of record. Author:
+`AttachedApp` + `BridgeAdapter` over the data-plane; a `ProjectionContract` for
+freshness, receipts, and safe summaries; health checks on ingestion/query;
+an `AppManifest` (`hybrid`); `ActionManifest` writes (e.g. `datalake.run_sync`,
+`datalake.import_slice`) where broad import/copy requires approval;
+`QueryManifest` reads (e.g. `datalake.lookup_carrier`, `datalake.sync_status`);
+`FlowManifest` sync-cadence runbooks. Compiles `hybrid` + subordinate attachment
+metadata.
+
+Swap Example A for Example B and Steps 1-4 are unchanged. If your procedure only
+works for one of them, a domain has leaked into the mechanics -- pull it back
+into the instance and the manifests.
+
+## Current status / honest caveat
+
+Today the runtime does **not yet** honor subordinate attachment metadata or
+health-gate activation, and the runtime `app_class` set does not yet include
+`hybrid` (it carries `declarative` and `sidecar` only). You can **draft** the
+full governed attach graph now -- `AttachedApp`/`BridgeAdapter`/`ProjectionContract`/
+health checks plus the Action/Query/Route/Flow/Ontology manifests -- but full
+end-to-end execution (the installer consuming the metadata, and activation
+blocking on foreign health) depends on that runtime work landing. State this
+plainly to the tenant: an attach you author now is a governed draft, not a live,
+health-gated integration. If the gap blocks the tenant, record it (see
+`capability-gap-reporting/SKILL.md`).
+
+## Related skills
+
+- `solution-router/SKILL.md` -- how a request gets routed to `attached_app` in
+  the first place, and the connector/sidecar/intake alternatives.
+- `layering-and-import-modes/SKILL.md` -- where attach sits in the configure ->
+  app-pack -> overlay -> attach -> intake -> greenfield order.
+- `app-pack-authoring/SKILL.md` -- the shipped app-pack artifact family the
+  attach graph compiles into.
+- `secrets-runtime-bridge/SKILL.md` -- referencing the foreign system's
+  credentials without embedding them.
+- `ontology-mapping/SKILL.md` -- mapping foreign objects onto shared URNs.
+- If this skill is missing from an older generated workspace, refresh managed
+  guidance with `minutework workspace sync-assets`
+  (see `workspace-guidance-refresh/SKILL.md`).

package/assets/claude-local/skills/capability-gap-reporting/SKILL.md

@@ -78,13 +78,17 @@ open GitHub PRs, or require monorepo permissions for capability gaps.
     gateway, ingress, workflow, thread, or AI substrate, but not yet a built-in
     baseline product capability.
   - `reviewed_skill` when the missing piece is Builder-side routing or solution
-    guidance rather than runtime/platform substrate.
+    guidance rather than runtime/platform substrate (see
+    `solution-router/SKILL.md` for how reviewed skills are ranked and selected).
   - `app_pack` when the missing reusable thing should land as an installable
     product capability rather than a lower-level primitive.
   - `overlay_only` when the gap is presentation, projection, or policy layering
     over existing substrate rather than new execution capability.
   - `attached_app` when the right home is an attached-app integration surface
-    rather than shared core substrate.
+    rather than shared core substrate (see `attached-app/SKILL.md`). Until the
+    runtime honors attachment metadata and health-gated activation, a needed
+    attach capability that cannot fully execute yet is itself a valid gap to
+    record.
 - Prefer one concrete gap per missing shared capability.
 - Use gap reports to tell MinuteWork where shared substrate may be missing. Do
   not treat them as automatic implementation instructions.

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/layering-and-import-modes/SKILL.md

@@ -6,7 +6,9 @@ description: "Choosing between configuration, app-pack changes, overlays, attach
 # Layering And Import Modes
 
 Use this skill when choosing between configuration, app-pack changes, overlays,
-`attached_app`, or OSS intake.
+`attached_app`, or OSS intake. For a fresh product request, start at
+`solution-router/SKILL.md`, which classifies the request and ranks reviewed
+capability skills before this layering decision.
 
 - Prefer the highest layer that solves the request:
   - configure an existing capability, skill, or baseline substrate first
@@ -21,7 +23,10 @@ Use this skill when choosing between configuration, app-pack changes, overlays,
   `integration-broker-and-connectors/SKILL.md` and use the broker substrate when
   it fits.
 - Use `attached_app` when a mature foreign system should remain its own
-  subsystem and MinuteWork should compile a governed control surface around it.
+  subsystem and MinuteWork should compile a governed control surface around it;
+  see `attached-app/SKILL.md` for the authoring procedure and
+  `solution-router/SKILL.md` for choosing it over a connector, sidecar, or repo
+  intake.
 - Use `external_repo_intake` only when no reviewed capability skill or cleaner
   `attached_app` path fits. Any repo intake must stay inside the bounded Builder
   sandbox.

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

@@ -31,12 +31,19 @@ needed:
   belongs in governed runtime capabilities instead of browser/provider calls.
 - `layering-and-import-modes/SKILL.md` for build-native vs govern-existing,
   `attached_app`, OSS adoption, and greenfield-last decisions.
+- `solution-router/SKILL.md` for routing a common product request to the right
+  reviewed capability skill and deployment mode before open-ended research.
+- `attached-app/SKILL.md` for governing a mature foreign subsystem the tenant
+  hosts as an attached control surface, reads via Query and writes via Action.
 - `integration-broker-and-connectors/SKILL.md` for external integrations, paid
   acquisition, ads, brokered connectors, spend/approval governance, and
   `mw.connector.ads`.
 - `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