minutework 0.1.47 → 0.1.50

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/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,6 +31,10 @@ 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`.

package/assets/claude-local/skills/solution-router/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: solution-router
+description: "Routing a common product request: classify intent, ask only the clarifying questions that change the choice, rank reviewed/published capability skills, pick the deployment and intake mode, and fall back to OSS research only when nothing fits."
+---
+
+# Solution Router
+
+Use this skill first when a user asks for a recurring product capability --
+ecommerce, CRM, ingestion, analytics, an integration, "make my existing system
+agentic," "bring in my app." Do not open these with open-ended OSS research.
+Route through the reviewed capability-skill catalog first and only research when
+nothing fits.
+
+Neither a reviewed capability skill nor an OSS repo is a runtime install
+contract. Whatever you select, the authoritative output is still the governed
+compiled artifact graph (`AppManifest` plus the manifests and contracts the
+chosen mode requires). The router chooses the path; it never installs anything.
+
+Work the steps in order. The domain list is **data-driven from the catalog**:
+rank whatever reviewed/published skills exist, never a hardcoded vertical list.
+
+## Step 1 -- Classify the request
+
+Name the problem class in horizontal terms (commerce backend, SaaS
+orchestration, dataset reaction, internal API, public site), not a vendor or
+vertical. The same sentence can resolve to different paths -- "bring in my
+existing app" might be a connector, an attached subsystem, a sidecar, or a repo
+intake -- which is exactly why the router exists and a fixed `init` choice does
+not.
+
+## Step 2 -- Ask the minimum clarifying questions
+
+Ask only the questions whose answers **change the solution choice**, and stop.
+The high-signal axes are almost always:
+
+- managed SaaS the tenant already uses, or a system they self-host?
+- should the existing system stay the system of record, or does the tenant want
+  MinuteWork to own the data natively?
+- read-only, governed writes, or autonomous workflows -- and what needs human
+  approval?
+- is there a mature intact system to govern, or unfinished code to develop?
+
+Each reviewed skill declares its own `minimum_clarifying_questions`; prefer
+those over inventing new ones. Do not interrogate when the choice is already
+unambiguous.
+
+## Step 3 -- Rank the reviewed capability skills
+
+Score the catalog entries against the answers using their declared fields:
+`domain`, `problem_class`, `solution_type`, `source_intake_mode`,
+`hosting_model`, `runtime_relationship`, `autonomy_support`, required infra,
+storage profile, and **disqualifiers**. A single disqualifier hit drops a
+candidate regardless of other fit.
+
+Lifecycle gates which candidates you may pick automatically:
+
+- auto-select only `reviewed` or `published` skills;
+- `candidate` and `draft` skills may be *suggested*, but require explicit human
+  confirmation before they drive a build;
+- a promoted skill keeps its mapping to solution type, intake mode, and governed
+  outputs -- carry that mapping into the compile step.
+
+## Step 4 -- Select the mode
+
+Selection resolves two orthogonal axes; do not collapse them.
+
+- `solution_type` (where it runs / system of record):
+  - `connector` -- a remote third-party SaaS reached over its API; normally
+    compiles `declarative`, often as a ConnectorPack.
+  - `attached_app` -- a mature foreign subsystem the tenant hosts stays its own
+    system of record while MinuteWork compiles a governed control surface around
+    it. Compiles to `declarative`/`hybrid` plus **subordinate** attachment
+    metadata, never a new app class. See `attached-app/SKILL.md`.
+  - `sidecar` -- a MinuteWork-owned backend process (webhooks, workers,
+    schedulers, compute). See `sidecar-generation/SKILL.md`.
+  - `native_pack` -- rebuild natively; resolves before compile to
+    `declarative`, `hybrid`, or `code_backed`.
+- `source_intake_mode` (does Builder clone code to author?):
+  - `catalog_native` -- compile directly from a known shape; no clone. The fast
+    path, and what the `attached_app` and connector seeds use.
+  - `external_repo_intake` -- clone a pinned repo into the bounded Builder
+    sandbox, inspect license/stack/auth/DB/jobs/routes, classify, then compile.
+    Choose this only when the selected skill or research result explicitly
+    requires source analysis.
+
+Cloning an unfinished repo to co-develop it is `external_repo_intake` toward a
+code-backed pack -- a different combination from `attached_app`, and not what
+this router reaches for when a mature system should stay foreign.
+
+## Step 5 -- Fall back to research only when nothing fits
+
+Reach for `oss_capability_research` only when no reviewed skill matches,
+confidence stays too low after clarifying questions, or the user explicitly
+wants an unsupported stack. Research may compare candidates by fit, license,
+hosting model, and risk, then emit a recommendation, a draft reviewed skill, or
+a draft artifact graph for review. It must not install software directly or
+treat a popular repo as an install contract. Default research output is a
+recommendation, not an activation.
+
+## Status (today)
+
+The seed catalog
+(`reference/mwv3-dj6-docs/reviewed_capability_skill_seed_catalog.md`) is still
+`draft`, and there is no machine-readable registry to rank over yet -- so every
+catalog entry currently needs explicit human confirmation before it drives a
+build, and ranking is a reading-the-catalog judgement rather than an automated
+score. Treat this skill as the procedure; promotion of concrete instances to
+`reviewed` is a separate, human-gated step.
+
+## Related skills
+
+- `attached-app/SKILL.md` -- the authoring procedure once the mode is
+  `attached_app`.
+- `layering-and-import-modes/SKILL.md` -- the higher-level configure ->
+  app-pack -> overlay -> attach -> intake -> greenfield decision order.
+- `integration-broker-and-connectors/SKILL.md` -- credentialed connector and
+  brokered-spend solutions.
+- `sidecar-generation/SKILL.md` -- when the answer is a MinuteWork-owned backend
+  process rather than a foreign system.
+- `capability-gap-reporting/SKILL.md` -- when no reviewed skill and no clean
+  research path fit, record the gap instead of forcing a bespoke build.
+- 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/templates/vuilder-shell/src/app/app/demo/page.tsx

@@ -0,0 +1,9 @@
+import { ManifestDemo } from "@/features/demo/components/manifest-demo";
+
+export const metadata = {
+  title: "Demo",
+};
+
+export default function DemoPage() {
+  return <ManifestDemo />;
+}

package/assets/templates/vuilder-shell/src/features/demo/components/manifest-demo.tsx

@@ -0,0 +1,79 @@
+"use client";
+
+import { useState } from "react";
+import { Database, RefreshCcw } from "lucide-react";
+
+import { PanelFrame } from "@/design-system/patterns/panel-frame";
+import { Button } from "@/design-system/primitives/button";
+import {
+  platformSessionSchema,
+  type PlatformSession,
+} from "@/lib/platform/contracts";
+
+type DemoResult = {
+  session?: PlatformSession;
+};
+
+export function ManifestDemo() {
+  const [result, setResult] = useState<DemoResult | null>(null);
+  const [error, setError] = useState("");
+  const [pending, setPending] = useState(false);
+
+  async function loadSession() {
+    setPending(true);
+    setError("");
+    try {
+      const response = await fetch("/api/auth/session", {
+        method: "GET",
+        cache: "no-store",
+      });
+      const payload = (await response.json().catch(() => null)) as unknown;
+
+      if (!response.ok) {
+        const detail =
+          typeof payload === "object" &&
+          payload !== null &&
+          "detail" in payload &&
+          typeof payload.detail === "string"
+            ? payload.detail
+            : "Session request failed.";
+        throw new Error(detail);
+      }
+
+      setResult({ session: platformSessionSchema.parse(payload) });
+    } catch (caught) {
+      setError(caught instanceof Error ? caught.message : "Session request failed.");
+    } finally {
+      setPending(false);
+    }
+  }
+
+  return (
+    <div className="grid gap-6">
+      <PanelFrame tone="floating" radius="xl" padding="lg" className="space-y-5">
+        <div className="flex items-center gap-2">
+          <Database className="size-5 text-primary" />
+          <h2 className="text-2xl font-semibold tracking-tight">
+            Platform session
+          </h2>
+        </div>
+        <p className="max-w-2xl text-sm leading-7 text-muted-foreground">
+          This shell uses the platform member session established by central SSO.
+        </p>
+        <div className="flex flex-wrap gap-3">
+          <Button type="button" variant="outline" onClick={loadSession} disabled={pending}>
+            <RefreshCcw className="size-4" />
+            Load session
+          </Button>
+        </div>
+        {error ? <p className="text-sm text-destructive">{error}</p> : null}
+      </PanelFrame>
+
+      <PanelFrame tone="raised" radius="xl" padding="lg">
+        <pre className="min-h-40 overflow-auto rounded-md bg-muted p-4 text-xs text-muted-foreground">
+          {result ? JSON.stringify(result, null, 2) : "No result yet"}
+        </pre>
+      </PanelFrame>
+    </div>
+  );
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "minutework",
-  "version": "0.1.47",
+  "version": "0.1.50",
   "description": "MinuteWork CLI for workspace scaffolding, local preview workflows, and hosted preview deploys.",
   "type": "module",
   "bin": {
@@ -25,7 +25,7 @@
     "jiti": "^2.6.1",
     "zod": "^4.3.6",
     "@minutework/platform-config": "0.1.3",
-    "@minutework/schema-compiler": "0.1.9"
+    "@minutework/schema-compiler": "0.1.12"
   },
   "devDependencies": {
     "@types/node": "^24.9.1",

package/vendor/workspace-mcp/types.d.ts

@@ -408,12 +408,15 @@ export declare const SchemaStatusSchema: z.ZodObject<{
                 }>;
                 app_id: z.ZodString;
                 app_version: z.ZodString;
+                attached_apps: z.ZodOptional<z.ZodArray<z.ZodString>>;
+                bridge_adapters: z.ZodOptional<z.ZodArray<z.ZodString>>;
                 description: z.ZodString;
                 display_name: z.ZodString;
                 flows: z.ZodOptional<z.ZodArray<z.ZodString>>;
                 integration_dependencies: z.ZodOptional<z.ZodArray<z.ZodString>>;
                 ontology_mappings: z.ZodOptional<z.ZodArray<z.ZodString>>;
                 projection_contracts: z.ZodOptional<z.ZodArray<z.ZodString>>;
+                readiness_gates: z.ZodOptional<z.ZodArray<z.ZodString>>;
                 queries: z.ZodArray<z.ZodString>;
                 required_secrets: z.ZodOptional<z.ZodArray<z.ZodObject<{
                     description: z.ZodString;
@@ -424,6 +427,18 @@ export declare const SchemaStatusSchema: z.ZodObject<{
                 skills: z.ZodOptional<z.ZodArray<z.ZodString>>;
                 version: z.ZodLiteral<"AppManifestV1">;
             }, z.core.$strict>>;
+            attachedApps: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                app_id: z.ZodString;
+                attachment_id: z.ZodString;
+                definition: z.ZodRecord<z.ZodString, z.ZodType<unknown, unknown, z.core.$ZodTypeInternals<unknown, unknown>>>;
+                version: z.ZodLiteral<"AttachedAppV1">;
+            }, z.core.$strict>>>;
+            bridgeAdapters: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                adapter_id: z.ZodString;
+                app_id: z.ZodString;
+                definition: z.ZodRecord<z.ZodString, z.ZodType<unknown, unknown, z.core.$ZodTypeInternals<unknown, unknown>>>;
+                version: z.ZodLiteral<"BridgeAdapterV1">;
+            }, z.core.$strict>>>;
             eventSubscriptionManifests: z.ZodOptional<z.ZodArray<z.ZodObject<{
                 app_id: z.ZodString;
                 cross_server: z.ZodNullable<z.ZodObject<{
@@ -506,6 +521,7 @@ export declare const SchemaStatusSchema: z.ZodObject<{
             queryManifests: z.ZodArray<z.ZodObject<{
                 agent_exposed: z.ZodOptional<z.ZodBoolean>;
                 app_id: z.ZodString;
+                bridge_adapter_ref: z.ZodOptional<z.ZodString>;
                 definition: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodType<unknown, unknown, z.core.$ZodTypeInternals<unknown, unknown>>>>;
                 description: z.ZodString;
                 entity_name: z.ZodString;
@@ -515,11 +531,36 @@ export declare const SchemaStatusSchema: z.ZodObject<{
                     detail: "detail";
                     list: "list";
                 }>, z.ZodLiteral<"connector">]>;
+                query_resolver: z.ZodOptional<z.ZodString>;
                 required_roles: z.ZodOptional<z.ZodArray<z.ZodString>>;
                 schema_key: z.ZodString;
                 version: z.ZodLiteral<"QueryManifestV1">;
                 web_customer_exposed: z.ZodOptional<z.ZodBoolean>;
             }, z.core.$strict>>;
+            readinessGateManifests: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                app_id: z.ZodString;
+                gate_id: z.ZodString;
+                probes: z.ZodArray<z.ZodObject<{
+                    auth_ref: z.ZodOptional<z.ZodString>;
+                    expect_status: z.ZodDefault<z.ZodArray<z.ZodNumber>>;
+                    failure_budget: z.ZodDefault<z.ZodNumber>;
+                    interval_ms: z.ZodDefault<z.ZodNumber>;
+                    method: z.ZodDefault<z.ZodEnum<{
+                        GET: "GET";
+                        POST: "POST";
+                        HEAD: "HEAD";
+                    }>>;
+                    path: z.ZodDefault<z.ZodString>;
+                    probe_kind: z.ZodEnum<{
+                        http_probe: "http_probe";
+                    }>;
+                    ready_threshold: z.ZodDefault<z.ZodNumber>;
+                    timeout_ms: z.ZodDefault<z.ZodNumber>;
+                    url_ref: z.ZodString;
+                }, z.core.$strict>>;
+                require_all: z.ZodDefault<z.ZodBoolean>;
+                version: z.ZodLiteral<"ReadinessGateManifestV1">;
+            }, z.core.$strict>>>;
             releaseMetadata: z.ZodArray<z.ZodRecord<z.ZodString, z.ZodType<unknown, unknown, z.core.$ZodTypeInternals<unknown, unknown>>>>;
             routeManifests: z.ZodArray<z.ZodObject<{
                 action_id: z.ZodNullable<z.ZodString>;