@lssm/example.learning-journey-registry 0.0.0-canary-20251219202229 → 0.0.0-canary-20251220002821

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

@@ -1 +1 @@
-{"version":3,"file":"overview.docblock.js","names":[],"sources":["../../../../../../../../../libs/contracts/dist/docs/tech/workflows/overview.docblock.js"],"sourcesContent":["import { registerDocBlocks } from \"../../registry.js\";\n\n//#region src/docs/tech/workflows/overview.docblock.ts\nconst tech_workflows_overview_DocBlocks = [{\n\tid: \"docs.tech.workflows.overview\",\n\ttitle: \"WorkflowSpec Overview\",\n\tsummary: \"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.\",\n\tkind: \"reference\",\n\tvisibility: \"public\",\n\troute: \"/docs/tech/workflows/overview\",\n\ttags: [\n\t\t\"tech\",\n\t\t\"workflows\",\n\t\t\"overview\"\n\t],\n\tbody: \"# 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\"\n}];\nregisterDocBlocks(tech_workflows_overview_DocBlocks);\n\n//#endregion\nexport { tech_workflows_overview_DocBlocks };\n//# sourceMappingURL=overview.docblock.js.map"],"mappings":";;;AAGA,MAAM,oCAAoC,CAAC;CAC1C,IAAI;CACJ,OAAO;CACP,SAAS;CACT,MAAM;CACN,YAAY;CACZ,OAAO;CACP,MAAM;EACL;EACA;EACA;EACA;CACD,MAAM;CACN,CAAC;AACF,kBAAkB,kCAAkC"}
+{"version":3,"file":"overview.docblock.js","names":[],"sources":["../../../../../../../../../libs/contracts/dist/docs/tech/workflows/overview.docblock.js"],"sourcesContent":["import { registerDocBlocks } from \"../../registry.js\";\n\n//#region src/docs/tech/workflows/overview.docblock.ts\nconst tech_workflows_overview_DocBlocks = [{\n\tid: \"docs.tech.workflows.overview\",\n\ttitle: \"WorkflowSpec Overview\",\n\tsummary: \"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.\",\n\tkind: \"reference\",\n\tvisibility: \"public\",\n\troute: \"/docs/tech/workflows/overview\",\n\ttags: [\n\t\t\"tech\",\n\t\t\"workflows\",\n\t\t\"overview\"\n\t],\n\tbody: \"# 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\"\n}];\nregisterDocBlocks(tech_workflows_overview_DocBlocks);\n\n//#endregion\nexport { tech_workflows_overview_DocBlocks };"],"mappings":";;;AAGA,MAAM,oCAAoC,CAAC;CAC1C,IAAI;CACJ,OAAO;CACP,SAAS;CACT,MAAM;CACN,YAAY;CACZ,OAAO;CACP,MAAM;EACL;EACA;EACA;EACA;CACD,MAAM;CACN,CAAC;AACF,kBAAkB,kCAAkC"}

package/dist/libs/contracts/dist/docs/tech-contracts.docs.js.map

@@ -1 +1 @@
-{"version":3,"file":"tech-contracts.docs.js","names":[],"sources":["../../../../../../../libs/contracts/dist/docs/tech-contracts.docs.js"],"sourcesContent":["import { registerDocBlocks } from \"./registry.js\";\n\n//#region src/docs/tech-contracts.docs.ts\nconst techContractsDocs = [{\n\tid: \"docs.tech.contracts.presentations-v2\",\n\ttitle: \"Presentations V2 — Unified Descriptor & Transform Engine\",\n\tsummary: \"How PresentationDescriptorV2 and TransformEngine keep docs/renderers consistent.\",\n\tvisibility: \"public\",\n\troute: \"/docs/tech/contracts/presentations-v2\",\n\tkind: \"reference\",\n\ttags: [\n\t\t\"presentations\",\n\t\t\"docs\",\n\t\t\"mcp\"\n\t],\n\tbody: `## Presentations V2 — Unified Descriptor & Transform Engine\n\n### Purpose\n\nUnify presentations into one descriptor (\\`PresentationDescriptorV2\\`) that declares a single source (React component key or BlockNote doc) and a list of output targets (react, markdown, application/json, application/xml). A pluggable \\`TransformEngine\\` renders any target and applies PII redaction.\n\n### Types\n\n\\`\\`\\`ts\ntype PresentationTarget =\n  | 'react'\n  | 'markdown'\n  | 'application/json'\n  | 'application/xml';\n\ntype PresentationSource =\n  | {\n      type: 'component';\n      framework: 'react';\n      componentKey: string;\n      props?: AnySchemaModel;\n    }\n  | { type: 'blocknotejs'; docJson: unknown; blockConfig?: unknown };\n\ninterface PresentationDescriptorV2 {\n  meta: PresentationV2Meta; // includes partial OwnerShipMeta + description\n  policy?: { flags?: string[]; pii?: string[] };\n  source: PresentationSource;\n  targets: PresentationTarget[];\n}\n\n// Shared ownership schema (source of truth in @lssm/lib.contracts/src/ownership.ts)\ninterface OwnerShipMeta {\n  title: string;\n  description: string;\n  domain: string;\n  owners: Owner[];\n  tags: Tag[];\n  stability: Stability;\n}\n\ntype Stability = 'experimental' | 'beta' | 'stable' | 'deprecated';\ntype Owner = string; // curated list available in code (e.g., '@sigil-team', 'team-strit')\ntype Tag = string; // curated list available in code (e.g., 'auth', 'spots')\n\n// For V2 presentations, meta is a Partial<OwnerShipMeta> plus description, name, version\ninterface PresentationV2Meta extends Partial<OwnerShipMeta> {\n  name: string;\n  version: number;\n  description?: string;\n}\n\\`\\`\\`\n\n### Engine\n\nUse \\`createDefaultTransformEngine()\\` and register custom renderers as needed (e.g., high-fidelity BlockNote → Markdown). The default engine supports markdown/json/xml; a React renderer returns a serializable descriptor the host app renders via a \\`componentMap\\` or a BlockNote renderer. The canonical source type string is \\`blocknotejs\\` (not \\`blocknote\\`).\n\nPII paths (JSON-like) are redacted from rendered outputs.\n\n### MCP Integration\n\n\\`createMcpServer\\` accepts \\`presentationsV2\\`. Each descriptor is exposed under \\`presentation://<name>/v<version>\\` and negotiated variants (\\`.md/.json/.xml\\`) are rendered by the engine.\n\n### Migration\n\n- V1 \\`PresentationSpec\\` remains supported; a back-compat helper converts V1 → V2 when convenient.\n- Prefer V2 for new work.\n\n### Examples (Sigil)\n\n- \\`sigil.auth.webauth_tabs_v2\\`: component source (\\`componentKey: 'sigil.webauth.tabs'\\`), targets \\`react/json/xml\\`.\n- \\`sigil.signup.guide_v2\\`: BlockNote doc source, targets \\`react/markdown/json/xml\\`.\n\n### React Rendering\n\nHost apps use a \\`componentMap\\` (e.g., \\`'sigil.webauth.tabs' → WebAuthTabs\\`) and a BlockNote renderer to turn the React render descriptor into elements.`\n}];\nregisterDocBlocks(techContractsDocs);\n\n//#endregion\nexport { techContractsDocs };\n//# sourceMappingURL=tech-contracts.docs.js.map"],"mappings":";;;AAGA,MAAM,oBAAoB,CAAC;CAC1B,IAAI;CACJ,OAAO;CACP,SAAS;CACT,YAAY;CACZ,OAAO;CACP,MAAM;CACN,MAAM;EACL;EACA;EACA;EACA;CACD,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4EN,CAAC;AACF,kBAAkB,kBAAkB"}
+{"version":3,"file":"tech-contracts.docs.js","names":[],"sources":["../../../../../../../libs/contracts/dist/docs/tech-contracts.docs.js"],"sourcesContent":["import { registerDocBlocks } from \"./registry.js\";\n\n//#region src/docs/tech-contracts.docs.ts\nconst techContractsDocs = [{\n\tid: \"docs.tech.contracts.presentations-v2\",\n\ttitle: \"Presentations V2 — Unified Descriptor & Transform Engine\",\n\tsummary: \"How PresentationDescriptorV2 and TransformEngine keep docs/renderers consistent.\",\n\tvisibility: \"public\",\n\troute: \"/docs/tech/contracts/presentations-v2\",\n\tkind: \"reference\",\n\ttags: [\n\t\t\"presentations\",\n\t\t\"docs\",\n\t\t\"mcp\"\n\t],\n\tbody: `## Presentations V2 — Unified Descriptor & Transform Engine\n\n### Purpose\n\nUnify presentations into one descriptor (\\`PresentationDescriptorV2\\`) that declares a single source (React component key or BlockNote doc) and a list of output targets (react, markdown, application/json, application/xml). A pluggable \\`TransformEngine\\` renders any target and applies PII redaction.\n\n### Types\n\n\\`\\`\\`ts\ntype PresentationTarget =\n  | 'react'\n  | 'markdown'\n  | 'application/json'\n  | 'application/xml';\n\ntype PresentationSource =\n  | {\n      type: 'component';\n      framework: 'react';\n      componentKey: string;\n      props?: AnySchemaModel;\n    }\n  | { type: 'blocknotejs'; docJson: unknown; blockConfig?: unknown };\n\ninterface PresentationDescriptorV2 {\n  meta: PresentationV2Meta; // includes partial OwnerShipMeta + description\n  policy?: { flags?: string[]; pii?: string[] };\n  source: PresentationSource;\n  targets: PresentationTarget[];\n}\n\n// Shared ownership schema (source of truth in @lssm/lib.contracts/src/ownership.ts)\ninterface OwnerShipMeta {\n  title: string;\n  description: string;\n  domain: string;\n  owners: Owner[];\n  tags: Tag[];\n  stability: Stability;\n}\n\ntype Stability = 'experimental' | 'beta' | 'stable' | 'deprecated';\ntype Owner = string; // curated list available in code (e.g., '@sigil-team', 'team-strit')\ntype Tag = string; // curated list available in code (e.g., 'auth', 'spots')\n\n// For V2 presentations, meta is a Partial<OwnerShipMeta> plus description, name, version\ninterface PresentationV2Meta extends Partial<OwnerShipMeta> {\n  name: string;\n  version: number;\n  description?: string;\n}\n\\`\\`\\`\n\n### Engine\n\nUse \\`createDefaultTransformEngine()\\` and register custom renderers as needed (e.g., high-fidelity BlockNote → Markdown). The default engine supports markdown/json/xml; a React renderer returns a serializable descriptor the host app renders via a \\`componentMap\\` or a BlockNote renderer. The canonical source type string is \\`blocknotejs\\` (not \\`blocknote\\`).\n\nPII paths (JSON-like) are redacted from rendered outputs.\n\n### MCP Integration\n\n\\`createMcpServer\\` accepts \\`presentationsV2\\`. Each descriptor is exposed under \\`presentation://<name>/v<version>\\` and negotiated variants (\\`.md/.json/.xml\\`) are rendered by the engine.\n\n### Migration\n\n- V1 \\`PresentationSpec\\` remains supported; a back-compat helper converts V1 → V2 when convenient.\n- Prefer V2 for new work.\n\n### Examples (Sigil)\n\n- \\`sigil.auth.webauth_tabs_v2\\`: component source (\\`componentKey: 'sigil.webauth.tabs'\\`), targets \\`react/json/xml\\`.\n- \\`sigil.signup.guide_v2\\`: BlockNote doc source, targets \\`react/markdown/json/xml\\`.\n\n### React Rendering\n\nHost apps use a \\`componentMap\\` (e.g., \\`'sigil.webauth.tabs' → WebAuthTabs\\`) and a BlockNote renderer to turn the React render descriptor into elements.`\n}];\nregisterDocBlocks(techContractsDocs);\n\n//#endregion\nexport { techContractsDocs };"],"mappings":";;;AAGA,MAAM,oBAAoB,CAAC;CAC1B,IAAI;CACJ,OAAO;CACP,SAAS;CACT,YAAY;CACZ,OAAO;CACP,MAAM;CACN,MAAM;EACL;EACA;EACA;EACA;CACD,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4EN,CAAC;AACF,kBAAkB,kBAAkB"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lssm/example.learning-journey-registry",
-  "version": "0.0.0-canary-20251219202229",
+  "version": "0.0.0-canary-20251220002821",
   "description": "Registry that aggregates learning journey example tracks.",
   "type": "module",
   "main": "./dist/index.js",
@@ -34,24 +34,24 @@
     "lint:check": "eslint src"
   },
   "dependencies": {
-    "@lssm/lib.schema": "0.0.0-canary-20251219202229",
-    "@lssm/lib.contracts": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-ambient-coach": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-duo-drills": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-crm-onboarding": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-platform-tour": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-quest-challenges": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-studio-onboarding": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-ui-shared": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-ui-gamified": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-ui-onboarding": "0.0.0-canary-20251219202229",
-    "@lssm/example.learning-journey-ui-coaching": "0.0.0-canary-20251219202229",
-    "@lssm/module.learning-journey": "0.0.0-canary-20251219202229",
-    "react": "^19.2.3"
+    "@lssm/lib.schema": "0.0.0-canary-20251220002821",
+    "@lssm/lib.contracts": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-ambient-coach": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-duo-drills": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-crm-onboarding": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-platform-tour": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-quest-challenges": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-studio-onboarding": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-ui-shared": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-ui-gamified": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-ui-onboarding": "0.0.0-canary-20251220002821",
+    "@lssm/example.learning-journey-ui-coaching": "0.0.0-canary-20251220002821",
+    "@lssm/module.learning-journey": "0.0.0-canary-20251220002821",
+    "react": "19.2.3"
   },
   "devDependencies": {
-    "@lssm/tool.tsdown": "0.0.0-canary-20251219202229",
-    "@lssm/tool.typescript": "0.0.0-canary-20251219202229",
+    "@lssm/tool.tsdown": "0.0.0-canary-20251220002821",
+    "@lssm/tool.typescript": "0.0.0-canary-20251220002821",
     "@types/react": "^19.1.6",
     "tsdown": "^0.18.1",
     "typescript": "^5.9.3"
@@ -75,7 +75,14 @@
       "./ui": "./dist/ui/index.js",
       "./ui/LearningMiniApp": "./dist/ui/LearningMiniApp.js",
       "./*": "./*"
-    }
+    },
+    "registry": "https://registry.npmjs.org/",
+    "access": "public"
   },
-  "license": "MIT"
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/lssm-tech/contractspec.git",
+    "directory": "packages/examples/learning-journey-registry"
+  }
 }