@lssm/example.marketplace 0.0.0-canary-20251217063201 → 0.0.0-canary-20251217073102

package/dist/libs/contracts/dist/docs/tech/studio/team-invitations.docblock.js

@@ -1,4 +1,21 @@
-import{a as e}from"../../registry.js";e([{id:`docs.tech.studio.team-invitations`,title:`Studio Teams & Invitations`,summary:`Admin-only team management and email invitation flow to join an organization and optionally a team.`,kind:`reference`,visibility:`public`,route:`/docs/tech/studio/team-invitations`,tags:[`studio`,`teams`,`invitations`,`access-control`,`onboarding`],body:`# Studio Teams & Invitations
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/studio/team-invitations.docblock.js
+const tech_studio_team_invitations_DocBlocks = [{
+	id: "docs.tech.studio.team-invitations",
+	title: "Studio Teams & Invitations",
+	summary: "Admin-only team management and email invitation flow to join an organization and optionally a team.",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/studio/team-invitations",
+	tags: [
+		"studio",
+		"teams",
+		"invitations",
+		"access-control",
+		"onboarding"
+	],
+	body: `# Studio Teams & Invitations
 
 Studio uses **organization membership** as the base access model. Teams are optional and used to refine access to projects.
 
@@ -8,58 +25,45 @@ Studio uses **organization membership** as the base access model. Teams are opti
 
 ## Invitation data model
 
-- \`Invitation\` rows are stored under an organization and target an **email** address.
-
+- \`Invitation\` rows are stored under an organization and target an **email** address.\n
 - An invitation can optionally target a \`teamId\`, which will grant the user membership in that team upon acceptance.
 
 Key fields:
-- \`email\`: invited address (must match the accepting user's account email)
-
-- \`status\`: \`pending | accepted | declined | expired\`
-
-- \`teamId?\`: optional team to join
-
+- \`email\`: invited address (must match the accepting user's account email)\n
+- \`status\`: \`pending | accepted | declined | expired\`\n
+- \`teamId?\`: optional team to join\n
 - \`inviterId\`: user who issued the invitation
 
 ## GraphQL surfaces
 
-- Team CRUD (admin-only):
-
-  - \`createTeam(name)\`
-
-  - \`renameTeam(teamId, name)\`
-
-  - \`deleteTeam(teamId)\`
-
-
-- Invitations (admin-only):
-
-  - \`organizationInvitations\`
+- Team CRUD (admin-only):\n
+  - \`createTeam(name)\`\n
+  - \`renameTeam(teamId, name)\`\n
+  - \`deleteTeam(teamId)\`\n
 
+- Invitations (admin-only):\n
+  - \`organizationInvitations\`\n
   - \`inviteToOrganization(email, role?, teamId?)\` → returns \`inviteUrl\` and whether an email was sent
 
 ## Accepting an invitation
 
-The invite link is served as:
-
+The invite link is served as:\n
 - \`/invite/{invitationId}\`
 
 Acceptance rules:
-- The user must be authenticated.
-
-- The authenticated user’s email must match \`Invitation.email\`.
-
-- If not already a member, create \`Member(userId, organizationId, role)\`.
-
-- If \`teamId\` is present, ensure \`TeamMember(teamId, userId)\`.
-
-- Mark invitation \`status='accepted'\` and set \`acceptedAt\`.
-
+- The user must be authenticated.\n
+- The authenticated user’s email must match \`Invitation.email\`.\n
+- If not already a member, create \`Member(userId, organizationId, role)\`.\n
+- If \`teamId\` is present, ensure \`TeamMember(teamId, userId)\`.\n
+- Mark invitation \`status='accepted'\` and set \`acceptedAt\`.\n
 - Set \`activeOrganizationId\` for the session so \`/studio/*\` routes work immediately.
 
 ## Email delivery
 
-- If \`RESEND_API_KEY\` is set, the system attempts to send an email.
-
+- If \`RESEND_API_KEY\` is set, the system attempts to send an email.\n
 - Otherwise, the UI uses the returned \`inviteUrl\` for manual copy/share.
-`}]);
+`
+}];
+registerDocBlocks(tech_studio_team_invitations_DocBlocks);
+
+//#endregion

package/dist/libs/contracts/dist/docs/tech/studio/workspace-ops.docblock.js

@@ -1 +1,47 @@
-import{a as e}from"../../registry.js";e([{id:`docs.tech.studio.workspace_ops`,title:`Workspace ops (repo-linked): list / validate / deps / diff`,summary:`Read-only repo operations used by Studio to inspect and validate a linked ContractSpec workspace.`,kind:`reference`,visibility:`mixed`,route:`/docs/tech/studio/workspace-ops`,tags:[`studio`,`repo`,`workspace`,`validate`,`diff`],body:"## API surface (api-contractspec)\n\nBase: `/api/workspace-ops`\n\nThese endpoints are **read-only** in v1 and never push to git:\n\n- `GET /api/workspace-ops/:integrationId/config?organizationId=`\n- `GET /api/workspace-ops/:integrationId/specs?organizationId=`\n- `POST /api/workspace-ops/:integrationId/validate` (body: organizationId, files?, pattern?)\n- `POST /api/workspace-ops/:integrationId/deps` (body: organizationId, pattern?)\n- `POST /api/workspace-ops/:integrationId/diff` (body: organizationId, specPath, baseline?, breakingOnly?)\n\n## Repo resolution\n\n- The repo root is resolved from the Studio Integration (`IntegrationProvider.GITHUB`) config:\n  - `config.repoCachePath` (preferred) or `config.localPath`\n- Resolution is constrained to `CONTRACTSPEC_REPO_CACHE_DIR` (default: `/tmp/contractspec-repos`)\n\n## Intended UX\n\n- Studio Assistant can run these checks and present results as suggestions.\n- Users can copy equivalent CLI commands for local runs:\n  - `contractspec validate`\n  - `contractspec deps`\n  - `contractspec diff --baseline <ref>`\n"}]);
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/studio/workspace-ops.docblock.js
+const tech_studio_workspace_ops_DocBlocks = [{
+	id: "docs.tech.studio.workspace_ops",
+	title: "Workspace ops (repo-linked): list / validate / deps / diff",
+	summary: "Read-only repo operations used by Studio to inspect and validate a linked ContractSpec workspace.",
+	kind: "reference",
+	visibility: "mixed",
+	route: "/docs/tech/studio/workspace-ops",
+	tags: [
+		"studio",
+		"repo",
+		"workspace",
+		"validate",
+		"diff"
+	],
+	body: `## API surface (api-contractspec)
+
+Base: \`/api/workspace-ops\`
+
+These endpoints are **read-only** in v1 and never push to git:
+
+- \`GET /api/workspace-ops/:integrationId/config?organizationId=\`
+- \`GET /api/workspace-ops/:integrationId/specs?organizationId=\`
+- \`POST /api/workspace-ops/:integrationId/validate\` (body: organizationId, files?, pattern?)
+- \`POST /api/workspace-ops/:integrationId/deps\` (body: organizationId, pattern?)
+- \`POST /api/workspace-ops/:integrationId/diff\` (body: organizationId, specPath, baseline?, breakingOnly?)
+
+## Repo resolution
+
+- The repo root is resolved from the Studio Integration (\`IntegrationProvider.GITHUB\`) config:
+  - \`config.repoCachePath\` (preferred) or \`config.localPath\`
+- Resolution is constrained to \`CONTRACTSPEC_REPO_CACHE_DIR\` (default: \`/tmp/contractspec-repos\`)
+
+## Intended UX
+
+- Studio Assistant can run these checks and present results as suggestions.
+- Users can copy equivalent CLI commands for local runs:
+  - \`contractspec validate\`
+  - \`contractspec deps\`
+  - \`contractspec diff --baseline <ref>\`
+`
+}];
+registerDocBlocks(tech_studio_workspace_ops_DocBlocks);
+
+//#endregion

package/dist/libs/contracts/dist/docs/tech/studio/workspaces.docblock.js

@@ -1,4 +1,21 @@
-import{a as e}from"../../registry.js";e([{id:`docs.tech.studio.workspaces`,title:`Studio projects, teams, environments`,summary:`Organization-first Studio: projects live under an organization; teams refine access; projects deploy to multiple environments.`,kind:`reference`,visibility:`mixed`,route:`/docs/tech/studio/workspaces`,tags:[`studio`,`projects`,`teams`,`rbac`,`environments`],body:`## Concepts
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/studio/workspaces.docblock.js
+const tech_studio_workspaces_DocBlocks = [{
+	id: "docs.tech.studio.workspaces",
+	title: "Studio projects, teams, environments",
+	summary: "Organization-first Studio: projects live under an organization; teams refine access; projects deploy to multiple environments.",
+	kind: "reference",
+	visibility: "mixed",
+	route: "/docs/tech/studio/workspaces",
+	tags: [
+		"studio",
+		"projects",
+		"teams",
+		"rbac",
+		"environments"
+	],
+	body: `## Concepts
 
 - **Organization**: the primary grouping boundary for Studio projects.
 - **Project**: one application (specs, overlays, deployments, integrations, evolution, learning).
@@ -38,4 +55,8 @@ Studio and Sandbox both use a shared shell:
 - \`/studio/projects\`: create/select/delete projects (organization-first).
 - \`/studio/{projectSlug}/*\`: project modules (canvas/specs/deploy/integrations/evolution/learning).
 - \`/studio/learning\`: learning hub without selecting a project.
-`}]);
+`
+}];
+registerDocBlocks(tech_studio_workspaces_DocBlocks);
+
+//#endregion

package/dist/libs/contracts/dist/docs/tech/telemetry-ingest.docblock.js

@@ -1,4 +1,20 @@
-import{a as e}from"../registry.js";e([{id:`docs.tech.telemetry.ingest`,title:`Telemetry Ingest Endpoint`,summary:`Server-side telemetry ingestion for ContractSpec clients (VS Code extension, CLI, etc.).`,kind:`reference`,visibility:`internal`,route:`/docs/tech/telemetry/ingest`,tags:[`telemetry`,`api`,`posthog`,`analytics`],body:`# Telemetry Ingest Endpoint
+import { registerDocBlocks } from "../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/telemetry-ingest.docblock.js
+const tech_telemetry_ingest_DocBlocks = [{
+	id: "docs.tech.telemetry.ingest",
+	title: "Telemetry Ingest Endpoint",
+	summary: "Server-side telemetry ingestion for ContractSpec clients (VS Code extension, CLI, etc.).",
+	kind: "reference",
+	visibility: "internal",
+	route: "/docs/tech/telemetry/ingest",
+	tags: [
+		"telemetry",
+		"api",
+		"posthog",
+		"analytics"
+	],
+	body: `# Telemetry Ingest Endpoint
 
 The ContractSpec API provides a telemetry ingest endpoint for clients to send product analytics events.
 
@@ -76,7 +92,20 @@ The endpoint requires \`POSTHOG_PROJECT_KEY\` environment variable to be set. If
 | Event | Description | Properties |
 |-------|-------------|------------|
 | \`contractspec.api.mcp_request\` | MCP request processed | \`endpoint\`, \`method\`, \`success\`, \`duration_ms\` |
-`},{id:`docs.tech.telemetry.hybrid`,title:`Hybrid Telemetry Model`,summary:`How ContractSpec clients choose between direct PostHog and API-routed telemetry.`,kind:`usage`,visibility:`internal`,route:`/docs/tech/telemetry/hybrid`,tags:[`telemetry`,`architecture`,`posthog`],body:`# Hybrid Telemetry Model
+`
+}, {
+	id: "docs.tech.telemetry.hybrid",
+	title: "Hybrid Telemetry Model",
+	summary: "How ContractSpec clients choose between direct PostHog and API-routed telemetry.",
+	kind: "usage",
+	visibility: "internal",
+	route: "/docs/tech/telemetry/hybrid",
+	tags: [
+		"telemetry",
+		"architecture",
+		"posthog"
+	],
+	body: `# Hybrid Telemetry Model
 
 ContractSpec uses a hybrid telemetry model where clients can send events either directly to PostHog or via the API server.
 
@@ -119,4 +148,8 @@ interface TelemetryClient {
 \`\`\`
 
 This allows future migration without changing client code.
-`}]);
+`
+}];
+registerDocBlocks(tech_telemetry_ingest_DocBlocks);
+
+//#endregion

package/dist/libs/contracts/dist/docs/tech/templates/runtime.docblock.js

@@ -1 +1,20 @@
-import{a as e}from"../../registry.js";e([{id:`docs.tech.templates.runtime`,title:`ContractSpec Template Runtime (Phase 9)`,summary:`Phase 9 introduces a full local-first runtime for templates so anyone can preview apps directly in the browser without provisioning any infrastructure.`,kind:`reference`,visibility:`public`,route:`/docs/tech/templates/runtime`,tags:[`tech`,`templates`,`runtime`],body:"## ContractSpec Template Runtime (Phase 9)\n\nPhase 9 introduces a full local-first runtime for templates so anyone can preview apps directly in the browser without provisioning any infrastructure.\n\n### Building Blocks\n\n- **Local database** – `@lssm/lib.runtime-local` wraps `sql.js` (SQLite WASM) and `IndexedDB` so we can seed demo data, run migrations, and persist state between sessions. Tests point the runtime to `node_modules/sql.js/dist` so CI doesn’t need a browser.\n- **Local GraphQL** – `LocalGraphQLClient` wires Apollo Client + SchemaLink to resolvers for tasks, messaging, and i18n recipes. All `/templates`, `/studio`, and `/sandbox` previews use those resolvers so we never call remote APIs during demos.\n- **Template registry + installer** – `.../templates/registry.ts` stores the catalog (todos, messaging, recipes). `TemplateInstaller` can seed the runtime (`install`) or export a base64 snapshot via the new `saveTemplateToStudio` mutation.\n- **TemplateShell** – Shared UI wrapper that creates a `TemplateRuntimeProvider`, shows `LocalDataIndicator`, and (optionally) surfaces the new `SaveToStudioButton`.\n\n### Runtime Flows\n\n1. `/templates` now opens a modal that renders `TemplateShell` for each template. Users can explore without leaving the marketing site.\n2. `/studio` switches to a tabbed mini-app (Projects, Canvas, Specs, Deploy) to showcase Studio surfaces with mock data. Visitors see a **preview** shell, while authenticated users (Better Auth via Sigil) unlock full persistence, versioning, and deployment controls.\n3. `/sandbox` lets visitors pick a template and mode (Playground, Spec Editor, Visual Builder). The console at the bottom streams runtime events for transparency.\n\n### GraphQL Mutations\n\n- `saveTemplateToStudio(input: SaveTemplateInput!): SaveTemplateResult!` writes a placeholder project + spec so that templates installed from the sandbox appear in Studio. The mutation is intentionally simple right now: it records which template was imported, stores metadata, and returns `{ projectId, status: 'QUEUED' }` for the UI.\n- `saveCanvasDraft(input: SaveCanvasDraftInput!): CanvasVersion!` snapshots the current Visual Builder nodes to a draft version tied to a canvas overlay. Inputs include `canvasId`, arbitrary `nodes` JSON, and an optional `label`. The resolver enforces org/org access before calling `CanvasVersionManager`.\n- `deployCanvasVersion(input: DeployCanvasVersionInput!): CanvasVersion!` promotes a previously saved draft (`versionId`) to the deployed state. The returned object includes `status`, `nodes`, `createdAt`, and `createdBy` for UI timelines.\n- `undoCanvasVersion(input: UndoCanvasInput!): CanvasVersion` rewinds the visual builder to the prior snapshot (returns `null` when history is empty) so Studio’s toolbar can surface “Undo” without shelling out to local storage.\n\n### Studio GraphQL endpoint\n\n- The landing app exposes the Studio schema at `/api/studio/graphql` via Yoga so React Query hooks (`useStudioProjects`, `useCreateStudioProject`, `useDeployStudioProject`, etc.) can talk to the bundle without spinning up a separate server.\n\n### Spec Editor typing\n\n- Studio’s spec editor now preloads Monaco with ambient declarations for `@lssm/lib.contracts` and `zod`, so snippets receive autocomplete and inline errors even before the spec ships to the backend. The helper lives in `presentation/components/studio/organisms/monaco-spec-types.ts` and registers the extra libs once per browser session via `monaco.languages.typescript.typescriptDefaults.addExtraLib`.\n- Compiler options are aligned with our frontend toolchain (ES2020 + React JSX) which means drafts written in the editor behave like the compiled artifacts that flow through Studio pipelines.\n\n### Spec templates\n\n- Selecting a spec type now injects a ready-to-edit scaffold (capability, workflow, policy, dataview, component) so authors start from a canonical layout instead of a blank file. Templates live alongside `SpecEditor.tsx`, and we only overwrite the content when the previous value is empty or when the author explicitly switches types via the dropdown.\n\n### Spec preview\n\n- The validation side panel now embeds a `SpecPreview` widget that shows validation errors alongside transport artifacts (GraphQL schema, REST endpoints, component summaries) once a preview run completes. Tabs let authors toggle between “Validation” and “Artifacts,” mirroring the UX described in the Studio plan.\n\n### Testing\n\n- `src/templates/__tests__/runtime.test.ts` covers todos CRUD, messaging delivery, and recipe locale switching through the local GraphQL API.\n- Studio infrastructure tests live in `src/__tests__/e2e/project-lifecycle.test.ts` and continue to exercise project creation + deploy flows.\n\n### Next Steps\n\nFuture templates can register their React components via `registerTemplateComponents(templateId, components)` so TemplateShell can render them automatically. When new templates are added, remember to:\n\n1. Update the registry entry (schema + tags).\n2. Register components inside `presentation/components/templates`.\n3. Document the template under `docs/templates/`.\n\n\n\n\n\n"}]);
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/templates/runtime.docblock.js
+const tech_templates_runtime_DocBlocks = [{
+	id: "docs.tech.templates.runtime",
+	title: "ContractSpec Template Runtime (Phase 9)",
+	summary: "Phase 9 introduces a full local-first runtime for templates so anyone can preview apps directly in the browser without provisioning any infrastructure.",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/templates/runtime",
+	tags: [
+		"tech",
+		"templates",
+		"runtime"
+	],
+	body: "## ContractSpec Template Runtime (Phase 9)\n\nPhase 9 introduces a full local-first runtime for templates so anyone can preview apps directly in the browser without provisioning any infrastructure.\n\n### Building Blocks\n\n- **Local database** – `@lssm/lib.runtime-local` wraps `sql.js` (SQLite WASM) and `IndexedDB` so we can seed demo data, run migrations, and persist state between sessions. Tests point the runtime to `node_modules/sql.js/dist` so CI doesn’t need a browser.\n- **Local GraphQL** – `LocalGraphQLClient` wires Apollo Client + SchemaLink to resolvers for tasks, messaging, and i18n recipes. All `/templates`, `/studio`, and `/sandbox` previews use those resolvers so we never call remote APIs during demos.\n- **Template registry + installer** – `.../templates/registry.ts` stores the catalog (todos, messaging, recipes). `TemplateInstaller` can seed the runtime (`install`) or export a base64 snapshot via the new `saveTemplateToStudio` mutation.\n- **TemplateShell** – Shared UI wrapper that creates a `TemplateRuntimeProvider`, shows `LocalDataIndicator`, and (optionally) surfaces the new `SaveToStudioButton`.\n\n### Runtime Flows\n\n1. `/templates` now opens a modal that renders `TemplateShell` for each template. Users can explore without leaving the marketing site.\n2. `/studio` switches to a tabbed mini-app (Projects, Canvas, Specs, Deploy) to showcase Studio surfaces with mock data. Visitors see a **preview** shell, while authenticated users (Better Auth via Sigil) unlock full persistence, versioning, and deployment controls.\n3. `/sandbox` lets visitors pick a template and mode (Playground, Spec Editor, Visual Builder). The console at the bottom streams runtime events for transparency.\n\n### GraphQL Mutations\n\n- `saveTemplateToStudio(input: SaveTemplateInput!): SaveTemplateResult!` writes a placeholder project + spec so that templates installed from the sandbox appear in Studio. The mutation is intentionally simple right now: it records which template was imported, stores metadata, and returns `{ projectId, status: 'QUEUED' }` for the UI.\n- `saveCanvasDraft(input: SaveCanvasDraftInput!): CanvasVersion!` snapshots the current Visual Builder nodes to a draft version tied to a canvas overlay. Inputs include `canvasId`, arbitrary `nodes` JSON, and an optional `label`. The resolver enforces org/org access before calling `CanvasVersionManager`.\n- `deployCanvasVersion(input: DeployCanvasVersionInput!): CanvasVersion!` promotes a previously saved draft (`versionId`) to the deployed state. The returned object includes `status`, `nodes`, `createdAt`, and `createdBy` for UI timelines.\n- `undoCanvasVersion(input: UndoCanvasInput!): CanvasVersion` rewinds the visual builder to the prior snapshot (returns `null` when history is empty) so Studio’s toolbar can surface “Undo” without shelling out to local storage.\n\n### Studio GraphQL endpoint\n\n- The landing app exposes the Studio schema at `/api/studio/graphql` via Yoga so React Query hooks (`useStudioProjects`, `useCreateStudioProject`, `useDeployStudioProject`, etc.) can talk to the bundle without spinning up a separate server.\n\n### Spec Editor typing\n\n- Studio’s spec editor now preloads Monaco with ambient declarations for `@lssm/lib.contracts` and `zod`, so snippets receive autocomplete and inline errors even before the spec ships to the backend. The helper lives in `presentation/components/studio/organisms/monaco-spec-types.ts` and registers the extra libs once per browser session via `monaco.languages.typescript.typescriptDefaults.addExtraLib`.\n- Compiler options are aligned with our frontend toolchain (ES2020 + React JSX) which means drafts written in the editor behave like the compiled artifacts that flow through Studio pipelines.\n\n### Spec templates\n\n- Selecting a spec type now injects a ready-to-edit scaffold (capability, workflow, policy, dataview, component) so authors start from a canonical layout instead of a blank file. Templates live alongside `SpecEditor.tsx`, and we only overwrite the content when the previous value is empty or when the author explicitly switches types via the dropdown.\n\n### Spec preview\n\n- The validation side panel now embeds a `SpecPreview` widget that shows validation errors alongside transport artifacts (GraphQL schema, REST endpoints, component summaries) once a preview run completes. Tabs let authors toggle between “Validation” and “Artifacts,” mirroring the UX described in the Studio plan.\n\n### Testing\n\n- `src/templates/__tests__/runtime.test.ts` covers todos CRUD, messaging delivery, and recipe locale switching through the local GraphQL API.\n- Studio infrastructure tests live in `src/__tests__/e2e/project-lifecycle.test.ts` and continue to exercise project creation + deploy flows.\n\n### Next Steps\n\nFuture templates can register their React components via `registerTemplateComponents(templateId, components)` so TemplateShell can render them automatically. When new templates are added, remember to:\n\n1. Update the registry entry (schema + tags).\n2. Register components inside `presentation/components/templates`.\n3. Document the template under `docs/templates/`.\n\n\n\n\n\n"
+}];
+registerDocBlocks(tech_templates_runtime_DocBlocks);
+
+//#endregion

package/dist/libs/contracts/dist/docs/tech/vscode-extension.docblock.js

@@ -1,4 +1,20 @@
-import{a as e}from"../registry.js";e([{id:`docs.tech.vscode.extension`,title:`ContractSpec VS Code Extension`,summary:`VS Code extension for spec-first development with validation, scaffolding, and MCP integration.`,kind:`reference`,visibility:`public`,route:`/docs/tech/vscode/extension`,tags:[`vscode`,`extension`,`tooling`,`dx`],body:`# ContractSpec VS Code Extension
+import { registerDocBlocks } from "../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/vscode-extension.docblock.js
+const tech_vscode_extension_DocBlocks = [{
+	id: "docs.tech.vscode.extension",
+	title: "ContractSpec VS Code Extension",
+	summary: "VS Code extension for spec-first development with validation, scaffolding, and MCP integration.",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/vscode/extension",
+	tags: [
+		"vscode",
+		"extension",
+		"tooling",
+		"dx"
+	],
+	body: `# ContractSpec VS Code Extension
 
 The ContractSpec VS Code extension provides spec-first development tooling directly in your editor.
 
@@ -47,7 +63,20 @@ The extension uses a hybrid telemetry approach:
 2. Otherwise → send directly to PostHog (if project key configured)
 
 Telemetry respects VS Code's telemetry settings. No file paths, source code, or PII is collected.
-`},{id:`docs.tech.vscode.snippets`,title:`ContractSpec Snippets`,summary:`Code snippets for common ContractSpec patterns in VS Code.`,kind:`reference`,visibility:`public`,route:`/docs/tech/vscode/snippets`,tags:[`vscode`,`snippets`,`dx`],body:`# ContractSpec Snippets
+`
+}, {
+	id: "docs.tech.vscode.snippets",
+	title: "ContractSpec Snippets",
+	summary: "Code snippets for common ContractSpec patterns in VS Code.",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/vscode/snippets",
+	tags: [
+		"vscode",
+		"snippets",
+		"dx"
+	],
+	body: `# ContractSpec Snippets
 
 The VS Code extension includes snippets for common ContractSpec patterns.
 
@@ -65,4 +94,8 @@ The VS Code extension includes snippets for common ContractSpec patterns.
 ## Usage
 
 Type the prefix in a TypeScript file and press Tab to expand the snippet. Tab through the placeholders to fill in your values.
-`}]);
+`
+}];
+registerDocBlocks(tech_vscode_extension_DocBlocks);
+
+//#endregion

package/dist/libs/contracts/dist/docs/tech/workflows/overview.docblock.js

@@ -1 +1,20 @@
-import{a as e}from"../../registry.js";e([{id:`docs.tech.workflows.overview`,title:`WorkflowSpec Overview`,summary:"WorkflowSpec provides a declarative, versioned format for long-running flows that mix automation and human review. Specs stay inside `@lssm/lib.contracts` (`src/workflow/spec.ts`) so the same definition powers runtime execution, documentation, and future generation.",kind:`reference`,visibility:`public`,route:`/docs/tech/workflows/overview`,tags:[`tech`,`workflows`,`overview`],body:"# WorkflowSpec Overview\n\n## Purpose\n\nWorkflowSpec provides a declarative, versioned format for long-running flows that mix automation and human review. Specs stay inside `@lssm/lib.contracts` (`src/workflow/spec.ts`) so the same definition powers runtime execution, documentation, and future generation.\n\n## Core Types\n\n- `WorkflowMeta`: ownership metadata (`title`, `domain`, `owners`, `tags`, `stability`) plus `name` and `version`.\n- `WorkflowDefinition`:\n  - `entryStepId?`: optional explicit entry point (defaults to first step).\n  - `steps[]`: ordered list of `Step` descriptors.\n  - `transitions[]`: directed edges between steps with optional expressions.\n  - `sla?`: aggregated timing hints for the overall flow or per-step budgets.\n  - `compensation?`: fallback operations executed when a workflow is rolled back or fails.\n- `Step`:\n  - `type`: `human`, `automation`, or `decision`.\n  - `action`: references either a `ContractSpec` (`operation`) or `FormSpec` (`form`).\n  - Optional `guard`, `timeoutMs`, and retry policy (`maxAttempts`, `backoff`, `delayMs`, `maxDelayMs?`).\n  - `requiredIntegrations?`: integration slot ids that must be bound before the step may execute.\n  - `requiredCapabilities?`: `CapabilityRef[]` that must be enabled in the resolved app config.\n- `Transition`: `from` → `to` with optional `condition` string (simple data expressions).\n\n## Registry & Validation\n\n- `WorkflowRegistry` (`src/workflow/spec.ts`) stores specs by key `<name>.v<version>` and exposes `register`, `list`, and `get`.\n- `validateWorkflowSpec()` (`src/workflow/validation.ts`) checks:\n  - Duplicate step IDs.\n  - Unknown `from`/`to` transitions.\n  - Empty guards/conditions.\n  - Reachability from the entry step.\n  - Cycles in the graph.\n  - Operation/Form references against provided registries.\n- `assertWorkflowSpecValid()` wraps validation and throws `WorkflowValidationError` when errors remain.\n\n## Runtime\n\n- `WorkflowRunner` (`src/workflow/runner.ts`) executes workflows and coordinates steps.\n  - `start(name, version?, initialData?)` returns a `workflowId`.\n  - `executeStep(workflowId, input?)` runs the current step (automation or human).\n  - `getState(workflowId)` retrieves the latest state snapshot.\n  - `cancel(workflowId)` marks the workflow as cancelled.\n  - `preFlightCheck(name, version?, resolvedConfig?)` evaluates integration/capability requirements before the workflow starts.\n  - Throws `WorkflowPreFlightError` if required integration slots are unbound or required capabilities are disabled.\n- `StateStore` (`src/workflow/state.ts`) abstracts persistence. V1 ships with:\n  - `InMemoryStateStore` (`src/workflow/adapters/memory-store.ts`) for tests/dev.\n  - Placeholder factories for file/database adapters (`adapters/file-adapter.ts`, `adapters/db-adapter.ts`).\n- Guard evaluation: expression guards run through `evaluateExpression()` (`src/workflow/expression.ts`); custom policy guards can be provided via `guardEvaluator`.\n- Events: the runner emits `workflow.started`, `workflow.step_completed`, `workflow.step_failed`, and `workflow.cancelled` through the optional `eventEmitter`.\n- React bindings (`@lssm/lib.presentation-runtime-react`):\n  - `useWorkflow` hook (polls state, exposes `executeStep`, `cancel`, `refresh`).\n  - `WorkflowStepper` progress indicator using design-system Stepper.\n  - `WorkflowStepRenderer` helper to render human/automation/decision steps with sensible fallbacks.\n\n## Authoring Checklist\n\n1. Reuse existing operations/forms; create new specs when missing.\n2. Prefer explicit `entryStepId` for clarity (especially with decision branches).\n3. Give automation steps an `operation` and human steps a `form` (warnings surface otherwise).\n4. Use short, meaningful step IDs (`submit`, `review`, `finalize`) to simplify analytics.\n5. Keep guard expressions deterministic; complex policy logic should move to PolicySpec (Phase 2).\n\n## Testing\n\n- Add unit tests for new workflows via `assertWorkflowSpecValid`.\n- Use the new Vitest suites (`validation.test.ts`, `expression.test.ts`, `runner.test.ts`) as examples.\n- CLI support will arrive in Phase 1 PR 3 (`contractspec create --type workflow`).\n\n## Tooling\n\n- `contractspec create --type workflow` scaffolds a WorkflowSpec with interactive prompts.\n- `contractspec build <spec.workflow.ts>` generates a runner scaffold (`.runner.ts`) wired to `WorkflowRunner` and the in-memory store.\n- `contractspec validate` understands `.workflow.ts` files and checks core structure (meta, steps, transitions).\n\n## Next Steps (Non-MVP)\n\n- Persistence adapters (database/file) for workflow state (Phase 2).\n- React bindings (`useWorkflow`, `WorkflowStepper`) and presentation-runtime integration (PR 3).\n- Policy engine integration (`guard.type === 'policy'` validated against PolicySpec).\n- Telemetry hooks for step execution metrics.\n\n"}]);
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/workflows/overview.docblock.js
+const tech_workflows_overview_DocBlocks = [{
+	id: "docs.tech.workflows.overview",
+	title: "WorkflowSpec Overview",
+	summary: "WorkflowSpec provides a declarative, versioned format for long-running flows that mix automation and human review. Specs stay inside `@lssm/lib.contracts` (`src/workflow/spec.ts`) so the same definition powers runtime execution, documentation, and future generation.",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/workflows/overview",
+	tags: [
+		"tech",
+		"workflows",
+		"overview"
+	],
+	body: "# WorkflowSpec Overview\n\n## Purpose\n\nWorkflowSpec provides a declarative, versioned format for long-running flows that mix automation and human review. Specs stay inside `@lssm/lib.contracts` (`src/workflow/spec.ts`) so the same definition powers runtime execution, documentation, and future generation.\n\n## Core Types\n\n- `WorkflowMeta`: ownership metadata (`title`, `domain`, `owners`, `tags`, `stability`) plus `name` and `version`.\n- `WorkflowDefinition`:\n  - `entryStepId?`: optional explicit entry point (defaults to first step).\n  - `steps[]`: ordered list of `Step` descriptors.\n  - `transitions[]`: directed edges between steps with optional expressions.\n  - `sla?`: aggregated timing hints for the overall flow or per-step budgets.\n  - `compensation?`: fallback operations executed when a workflow is rolled back or fails.\n- `Step`:\n  - `type`: `human`, `automation`, or `decision`.\n  - `action`: references either a `ContractSpec` (`operation`) or `FormSpec` (`form`).\n  - Optional `guard`, `timeoutMs`, and retry policy (`maxAttempts`, `backoff`, `delayMs`, `maxDelayMs?`).\n  - `requiredIntegrations?`: integration slot ids that must be bound before the step may execute.\n  - `requiredCapabilities?`: `CapabilityRef[]` that must be enabled in the resolved app config.\n- `Transition`: `from` → `to` with optional `condition` string (simple data expressions).\n\n## Registry & Validation\n\n- `WorkflowRegistry` (`src/workflow/spec.ts`) stores specs by key `<name>.v<version>` and exposes `register`, `list`, and `get`.\n- `validateWorkflowSpec()` (`src/workflow/validation.ts`) checks:\n  - Duplicate step IDs.\n  - Unknown `from`/`to` transitions.\n  - Empty guards/conditions.\n  - Reachability from the entry step.\n  - Cycles in the graph.\n  - Operation/Form references against provided registries.\n- `assertWorkflowSpecValid()` wraps validation and throws `WorkflowValidationError` when errors remain.\n\n## Runtime\n\n- `WorkflowRunner` (`src/workflow/runner.ts`) executes workflows and coordinates steps.\n  - `start(name, version?, initialData?)` returns a `workflowId`.\n  - `executeStep(workflowId, input?)` runs the current step (automation or human).\n  - `getState(workflowId)` retrieves the latest state snapshot.\n  - `cancel(workflowId)` marks the workflow as cancelled.\n  - `preFlightCheck(name, version?, resolvedConfig?)` evaluates integration/capability requirements before the workflow starts.\n  - Throws `WorkflowPreFlightError` if required integration slots are unbound or required capabilities are disabled.\n- `StateStore` (`src/workflow/state.ts`) abstracts persistence. V1 ships with:\n  - `InMemoryStateStore` (`src/workflow/adapters/memory-store.ts`) for tests/dev.\n  - Placeholder factories for file/database adapters (`adapters/file-adapter.ts`, `adapters/db-adapter.ts`).\n- Guard evaluation: expression guards run through `evaluateExpression()` (`src/workflow/expression.ts`); custom policy guards can be provided via `guardEvaluator`.\n- Events: the runner emits `workflow.started`, `workflow.step_completed`, `workflow.step_failed`, and `workflow.cancelled` through the optional `eventEmitter`.\n- React bindings (`@lssm/lib.presentation-runtime-react`):\n  - `useWorkflow` hook (polls state, exposes `executeStep`, `cancel`, `refresh`).\n  - `WorkflowStepper` progress indicator using design-system Stepper.\n  - `WorkflowStepRenderer` helper to render human/automation/decision steps with sensible fallbacks.\n\n## Authoring Checklist\n\n1. Reuse existing operations/forms; create new specs when missing.\n2. Prefer explicit `entryStepId` for clarity (especially with decision branches).\n3. Give automation steps an `operation` and human steps a `form` (warnings surface otherwise).\n4. Use short, meaningful step IDs (`submit`, `review`, `finalize`) to simplify analytics.\n5. Keep guard expressions deterministic; complex policy logic should move to PolicySpec (Phase 2).\n\n## Testing\n\n- Add unit tests for new workflows via `assertWorkflowSpecValid`.\n- Use the new Vitest suites (`validation.test.ts`, `expression.test.ts`, `runner.test.ts`) as examples.\n- CLI support will arrive in Phase 1 PR 3 (`contractspec create --type workflow`).\n\n## Tooling\n\n- `contractspec create --type workflow` scaffolds a WorkflowSpec with interactive prompts.\n- `contractspec build <spec.workflow.ts>` generates a runner scaffold (`.runner.ts`) wired to `WorkflowRunner` and the in-memory store.\n- `contractspec validate` understands `.workflow.ts` files and checks core structure (meta, steps, transitions).\n\n## Next Steps (Non-MVP)\n\n- Persistence adapters (database/file) for workflow state (Phase 2).\n- React bindings (`useWorkflow`, `WorkflowStepper`) and presentation-runtime integration (PR 3).\n- Policy engine integration (`guard.type === 'policy'` validated against PolicySpec).\n- Telemetry hooks for step execution metrics.\n\n"
+}];
+registerDocBlocks(tech_workflows_overview_DocBlocks);
+
+//#endregion

package/dist/libs/contracts/dist/events.js

@@ -1 +1,10 @@
-import"./schema/dist/index.js";function e(e){return e}export{e};
+import "./schema/dist/index.js";
+
+//#region ../../libs/contracts/dist/events.js
+/** Identity function to keep type inference when declaring events. */
+function defineEvent(e) {
+	return e;
+}
+
+//#endregion
+export { defineEvent };

package/dist/libs/contracts/dist/experiments/evaluator.js

@@ -1 +1 @@
-import"node:crypto";
+import "node:crypto";

package/dist/libs/contracts/dist/index.js

@@ -1 +1,71 @@
-import{n as e,t}from"./spec.js";import"./schema/dist/SchemaModel.js";import"./schema/dist/index.js";import{e as n}from"./events.js";import"./presentations.v2.js";import"./client/react/feature-render.js";import"./client/react/form-render.js";import"./client/index.js";import"./jsonschema.js";import"./server/graphql-pothos.js";import"./presentations.js";import"./server/mcp/createMcpServer.js";import"./server/rest-generic.js";import"./server/rest-elysia.js";import"./server/rest-express.js";import"./server/rest-next-app.js";import"./server/rest-next-pages.js";import"./server/index.js";import{a as r,i,o as a}from"./docs/presentations.js";import{a as o,i as s,n as c}from"./docs/registry.js";import"./registry.js";import{e as l,r as u,t as d}from"./ownership.js";import{i as f,n as p,r as m}from"./contract-registry/schemas.js";import"./contract-registry/index.js";import"./install.js";import"./openapi.js";import"./prompt.js";import"./promptRegistry.js";import"./resources.js";import{d as h,l as g,m as _,o as v,p as y,s as b}from"./onboarding-base.js";import"./capabilities/openbanking.js";import"./telemetry/tracker.js";import"./telemetry/index.js";import"./tests/runner.js";import"./tests/index.js";import"./experiments/evaluator.js";import"./integrations/providers/stripe.js";import"./integrations/providers/postmark.js";import"./integrations/providers/qdrant.js";import"./integrations/providers/mistral.js";import"./integrations/providers/elevenlabs.js";import"./integrations/providers/gmail.js";import"./integrations/providers/google-calendar.js";import"./integrations/providers/twilio-sms.js";import"./integrations/providers/gcs-storage.js";import"./integrations/providers/powens.js";import"./integrations/providers/registry.js";import{i as x,n as S,r as C}from"./integrations/openbanking/models.js";import{t as w}from"./integrations/openbanking/telemetry.js";import{d as T,f as E,p as D}from"./integrations/openbanking/contracts/accounts.js";import{d as O,u as k}from"./integrations/openbanking/contracts/transactions.js";import{d as A,u as j}from"./integrations/openbanking/contracts/balances.js";import"./integrations/openbanking/contracts/index.js";import"./integrations/index.js";import"./knowledge/spaces/product-canon.js";import"./knowledge/spaces/support-faq.js";import"./knowledge/spaces/email-threads.js";import"./knowledge/spaces/uploaded-docs.js";import"./knowledge/spaces/financial-docs.js";import"./knowledge/spaces/financial-overview.js";import"./knowledge/index.js";import{_ as M,g as N,h as P,m as F,p as I}from"./integrations/contracts.js";import{_ as L,g as R,h as z,m as B,v as V}from"./knowledge/contracts.js";import"./regenerator/service.js";import"./regenerator/index.js";import"./workflow/runner.js";import"./workflow/index.js";import"./docs/index.js";import"./llm/exporters.js";import"./llm/prompts.js";import"./llm/index.js";
+import { defineCommand, defineQuery } from "./spec.js";
+import "./schema/dist/SchemaModel.js";
+import "./schema/dist/index.js";
+import { defineEvent } from "./events.js";
+import "./presentations.v2.js";
+import "./client/react/feature-render.js";
+import "./client/react/form-render.js";
+import "./client/index.js";
+import "./jsonschema.js";
+import "./server/graphql-pothos.js";
+import "./presentations.js";
+import "./server/mcp/createMcpServer.js";
+import "./server/rest-generic.js";
+import "./server/rest-elysia.js";
+import "./server/rest-express.js";
+import "./server/rest-next-app.js";
+import "./server/rest-next-pages.js";
+import "./server/index.js";
+import { docBlockToPresentationSpec, docBlockToPresentationV2, docBlocksToPresentationRoutes } from "./docs/presentations.js";
+import { DocRegistry, defaultDocRegistry, registerDocBlocks } from "./docs/registry.js";
+import "./registry.js";
+import { OwnersEnum, StabilityEnum } from "./ownership.js";
+import { ContractRegistryFileSchema, ContractRegistryItemSchema, ContractRegistryItemTypeSchema } from "./contract-registry/schemas.js";
+import "./contract-registry/index.js";
+import "./install.js";
+import "./openapi.js";
+import "./prompt.js";
+import "./promptRegistry.js";
+import "./resources.js";
+import { CompleteOnboardingBaseInput, CompleteOnboardingBaseOutput, DeleteOnboardingDraftOutput, GetOnboardingDraftOutput, SaveOnboardingDraftInput, SaveOnboardingDraftOutput } from "./onboarding-base.js";
+import "./capabilities/openbanking.js";
+import "./telemetry/tracker.js";
+import "./telemetry/index.js";
+import "./tests/runner.js";
+import "./tests/index.js";
+import "./experiments/evaluator.js";
+import "./integrations/providers/stripe.js";
+import "./integrations/providers/postmark.js";
+import "./integrations/providers/qdrant.js";
+import "./integrations/providers/mistral.js";
+import "./integrations/providers/elevenlabs.js";
+import "./integrations/providers/gmail.js";
+import "./integrations/providers/google-calendar.js";
+import "./integrations/providers/twilio-sms.js";
+import "./integrations/providers/gcs-storage.js";
+import "./integrations/providers/powens.js";
+import "./integrations/providers/registry.js";
+import { AccountBalanceRecord, BankAccountRecord, BankTransactionRecord } from "./integrations/openbanking/models.js";
+import { OPENBANKING_TELEMETRY_EVENTS } from "./integrations/openbanking/telemetry.js";
+import "./integrations/openbanking/contracts/accounts.js";
+import "./integrations/openbanking/contracts/transactions.js";
+import "./integrations/openbanking/contracts/balances.js";
+import "./integrations/openbanking/contracts/index.js";
+import "./integrations/index.js";
+import "./knowledge/spaces/product-canon.js";
+import "./knowledge/spaces/support-faq.js";
+import "./knowledge/spaces/email-threads.js";
+import "./knowledge/spaces/uploaded-docs.js";
+import "./knowledge/spaces/financial-docs.js";
+import "./knowledge/spaces/financial-overview.js";
+import "./knowledge/index.js";
+import "./integrations/contracts.js";
+import "./knowledge/contracts.js";
+import "./regenerator/service.js";
+import "./regenerator/index.js";
+import "./workflow/runner.js";
+import "./workflow/index.js";
+import "./docs/index.js";
+import "./llm/exporters.js";
+import "./llm/prompts.js";
+import "./llm/index.js";

package/dist/libs/contracts/dist/install.js

@@ -1 +1,2 @@
-import"./registry.js";import"zod";
+import "./registry.js";
+import "zod";