@lssm/example.learning-journey-quest-challenges 0.0.0-canary-20251217080011 → 0.0.0-canary-20251219202229

package/dist/libs/contracts/dist/docs/registry.js

@@ -0,0 +1,45 @@
+import { docBlockToPresentationSpec, docBlocksToPresentationRoutes } from "./presentations.js";
+
+//#region ../../libs/contracts/dist/docs/registry.js
+var DocRegistry = class {
+	routes = /* @__PURE__ */ new Map();
+	constructor(blocks = [], options) {
+		blocks.forEach((block) => this.register(block, options));
+	}
+	register(block, options) {
+		const [route] = docBlocksToPresentationRoutes([block], options);
+		if (route) this.routes.set(block.id, route);
+		return this;
+	}
+	list() {
+		return [...this.routes.values()];
+	}
+	get(id) {
+		return this.routes.get(id);
+	}
+	toRouteTuples() {
+		return this.list().map(({ route, descriptor }) => [route, descriptor]);
+	}
+	toPresentationSpecs(options) {
+		return this.list().map(({ block }) => docBlockToPresentationSpec(block, options));
+	}
+};
+const requiredFields = [
+	"id",
+	"title",
+	"body",
+	"kind",
+	"visibility",
+	"route"
+];
+const defaultDocRegistry = new DocRegistry();
+function registerDocBlocks(blocks) {
+	for (const block of blocks) {
+		for (const field of requiredFields) if (!block[field]) throw new Error(`DocBlock ${block.id ?? "<missing id>"} missing field ${String(field)}`);
+		defaultDocRegistry.register(block);
+	}
+}
+
+//#endregion
+export { DocRegistry, defaultDocRegistry, registerDocBlocks };
+//# sourceMappingURL=registry.js.map

package/dist/libs/contracts/dist/docs/registry.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"registry.js","names":[],"sources":["../../../../../../../libs/contracts/dist/docs/registry.js"],"sourcesContent":["import { docBlockToPresentationSpec, docBlocksToPresentationRoutes } from \"./presentations.js\";\n\n//#region src/docs/registry.ts\nvar DocRegistry = class {\n\troutes = /* @__PURE__ */ new Map();\n\tconstructor(blocks = [], options) {\n\t\tblocks.forEach((block) => this.register(block, options));\n\t}\n\tregister(block, options) {\n\t\tconst [route] = docBlocksToPresentationRoutes([block], options);\n\t\tif (route) this.routes.set(block.id, route);\n\t\treturn this;\n\t}\n\tlist() {\n\t\treturn [...this.routes.values()];\n\t}\n\tget(id) {\n\t\treturn this.routes.get(id);\n\t}\n\ttoRouteTuples() {\n\t\treturn this.list().map(({ route, descriptor }) => [route, descriptor]);\n\t}\n\ttoPresentationSpecs(options) {\n\t\treturn this.list().map(({ block }) => docBlockToPresentationSpec(block, options));\n\t}\n};\nconst requiredFields = [\n\t\"id\",\n\t\"title\",\n\t\"body\",\n\t\"kind\",\n\t\"visibility\",\n\t\"route\"\n];\nconst defaultDocRegistry = new DocRegistry();\nfunction registerDocBlocks(blocks) {\n\tfor (const block of blocks) {\n\t\tfor (const field of requiredFields) if (!block[field]) throw new Error(`DocBlock ${block.id ?? \"<missing id>\"} missing field ${String(field)}`);\n\t\tdefaultDocRegistry.register(block);\n\t}\n}\nfunction listRegisteredDocBlocks() {\n\treturn defaultDocRegistry.list().map((r) => r.block);\n}\nfunction docId(id) {\n\tif (!defaultDocRegistry.get(id)) throw new Error(`DocBlock not registered: ${id}`);\n\treturn id;\n}\n\n//#endregion\nexport { DocRegistry, defaultDocRegistry, docId, listRegisteredDocBlocks, registerDocBlocks };\n//# sourceMappingURL=registry.js.map"],"mappings":";;;AAGA,IAAI,cAAc,MAAM;CACvB,yBAAyB,IAAI,KAAK;CAClC,YAAY,SAAS,EAAE,EAAE,SAAS;AACjC,SAAO,SAAS,UAAU,KAAK,SAAS,OAAO,QAAQ,CAAC;;CAEzD,SAAS,OAAO,SAAS;EACxB,MAAM,CAAC,SAAS,8BAA8B,CAAC,MAAM,EAAE,QAAQ;AAC/D,MAAI,MAAO,MAAK,OAAO,IAAI,MAAM,IAAI,MAAM;AAC3C,SAAO;;CAER,OAAO;AACN,SAAO,CAAC,GAAG,KAAK,OAAO,QAAQ,CAAC;;CAEjC,IAAI,IAAI;AACP,SAAO,KAAK,OAAO,IAAI,GAAG;;CAE3B,gBAAgB;AACf,SAAO,KAAK,MAAM,CAAC,KAAK,EAAE,OAAO,iBAAiB,CAAC,OAAO,WAAW,CAAC;;CAEvE,oBAAoB,SAAS;AAC5B,SAAO,KAAK,MAAM,CAAC,KAAK,EAAE,YAAY,2BAA2B,OAAO,QAAQ,CAAC;;;AAGnF,MAAM,iBAAiB;CACtB;CACA;CACA;CACA;CACA;CACA;CACA;AACD,MAAM,qBAAqB,IAAI,aAAa;AAC5C,SAAS,kBAAkB,QAAQ;AAClC,MAAK,MAAM,SAAS,QAAQ;AAC3B,OAAK,MAAM,SAAS,eAAgB,KAAI,CAAC,MAAM,OAAQ,OAAM,IAAI,MAAM,YAAY,MAAM,MAAM,eAAe,iBAAiB,OAAO,MAAM,GAAG;AAC/I,qBAAmB,SAAS,MAAM"}

package/dist/libs/contracts/dist/docs/tech/auth/better-auth-nextjs.docblock.js

@@ -0,0 +1,81 @@
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/auth/better-auth-nextjs.docblock.js
+const tech_auth_better_auth_nextjs_DocBlocks = [{
+	id: "docs.tech.auth.better-auth-nextjs",
+	title: "Better Auth + Next.js integration (ContractSpec)",
+	summary: "How ContractSpec wires Better Auth into Next.js (server config, client singleton, and proxy cookie-only redirects).",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/auth/better-auth-nextjs",
+	tags: [
+		"auth",
+		"better-auth",
+		"nextjs",
+		"cookies",
+		"proxy",
+		"hmr"
+	],
+	body: `# Better Auth + Next.js integration (ContractSpec)
+
+This repo uses Better Auth as the primary auth layer (sessions, organizations, teams, API keys, and OAuth).
+
+## Server config (Better Auth)
+
+- Source: \`packages/bundles/contractspec-studio/src/application/services/auth.ts\`
+- Important: \`nextCookies()\` must be the **last** plugin in the Better Auth plugin list so \`Set-Cookie\` is applied correctly in Next.js environments.
+
+## Better Auth Admin plugin
+
+ContractSpec Studio enables the Better Auth **Admin plugin** to support platform-admin user operations (list users, impersonation, etc.).
+
+- Server: \`admin()\` plugin in \`packages/bundles/contractspec-studio/src/application/services/auth.ts\`
+- Client: \`adminClient()\` in \`packages/bundles/contractspec-studio/src/presentation/providers/auth/client.ts\`
+
+### PLATFORM_ADMIN ⇒ Better Auth admin role
+
+Better Auth Admin endpoints authorize via \`user.role\`. ContractSpec enforces an org-driven rule:
+
+- If the **active organization** has \`type = PLATFORM_ADMIN\`, the signed-in user is ensured to have \`User.role\` containing \`admin\`.
+- This is applied in the session creation hook and re-checked in \`assertsPlatformAdmin()\`.
+
+This keeps admin enablement deterministic and avoids manual role backfills.
+
+## Client config (React web + Expo)
+
+To avoid duplicate background refresh/polling loops in dev (Fast Refresh/HMR), the Better Auth client is implemented as a singleton cached on \`globalThis\`.
+
+- Web client: \`packages/bundles/contractspec-studio/src/presentation/providers/auth/client.ts\`
+- Native client: \`packages/bundles/contractspec-studio/src/presentation/providers/auth/client.native.ts\`
+
+Import guidance:
+
+- If you only need the context/hook, prefer importing from \`@lssm/bundle.contractspec-studio/presentation/providers/auth\`.
+- If you explicitly need the Better Auth client instance (e.g. admin impersonation, direct API calls), import from \`@lssm/bundle.contractspec-studio/presentation/providers/auth/client\`.
+
+## Public routes (login / signup)
+
+Public auth pages should avoid eager \`authClient\` initialization.
+
+Pattern used:
+
+- In the submit handler, dynamically import \`@lssm/bundle.contractspec-studio/presentation/providers/auth/index.web\` and call \`authClient.signIn.*\` / \`authClient.signUp.*\`.
+
+This prevents session refresh behavior from starting just because a public page rendered.
+
+## Next.js proxy auth (web-landing)
+
+The Next.js proxy/middleware is used for **redirect decisions only**. It must not perform DB-backed session reads on every request.
+
+- Source: \`packages/apps/web-landing/src/proxy.ts\`
+- Approach: cookie-only checks via Better Auth cookies helpers:
+  - \`getSessionCookie(request)\`
+  - \`getCookieCache(request)\`
+
+These checks are intentionally optimistic and should only gate routing. Full authorization must still be enforced on server-side actions/routes and GraphQL resolvers.
+`
+}];
+registerDocBlocks(tech_auth_better_auth_nextjs_DocBlocks);
+
+//#endregion
+//# sourceMappingURL=better-auth-nextjs.docblock.js.map

package/dist/libs/contracts/dist/docs/tech/auth/better-auth-nextjs.docblock.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"better-auth-nextjs.docblock.js","names":[],"sources":["../../../../../../../../../libs/contracts/dist/docs/tech/auth/better-auth-nextjs.docblock.js"],"sourcesContent":["import { registerDocBlocks } from \"../../registry.js\";\n\n//#region src/docs/tech/auth/better-auth-nextjs.docblock.ts\nconst tech_auth_better_auth_nextjs_DocBlocks = [{\n\tid: \"docs.tech.auth.better-auth-nextjs\",\n\ttitle: \"Better Auth + Next.js integration (ContractSpec)\",\n\tsummary: \"How ContractSpec wires Better Auth into Next.js (server config, client singleton, and proxy cookie-only redirects).\",\n\tkind: \"reference\",\n\tvisibility: \"public\",\n\troute: \"/docs/tech/auth/better-auth-nextjs\",\n\ttags: [\n\t\t\"auth\",\n\t\t\"better-auth\",\n\t\t\"nextjs\",\n\t\t\"cookies\",\n\t\t\"proxy\",\n\t\t\"hmr\"\n\t],\n\tbody: `# Better Auth + Next.js integration (ContractSpec)\n\nThis repo uses Better Auth as the primary auth layer (sessions, organizations, teams, API keys, and OAuth).\n\n## Server config (Better Auth)\n\n- Source: \\`packages/bundles/contractspec-studio/src/application/services/auth.ts\\`\n- Important: \\`nextCookies()\\` must be the **last** plugin in the Better Auth plugin list so \\`Set-Cookie\\` is applied correctly in Next.js environments.\n\n## Better Auth Admin plugin\n\nContractSpec Studio enables the Better Auth **Admin plugin** to support platform-admin user operations (list users, impersonation, etc.).\n\n- Server: \\`admin()\\` plugin in \\`packages/bundles/contractspec-studio/src/application/services/auth.ts\\`\n- Client: \\`adminClient()\\` in \\`packages/bundles/contractspec-studio/src/presentation/providers/auth/client.ts\\`\n\n### PLATFORM_ADMIN ⇒ Better Auth admin role\n\nBetter Auth Admin endpoints authorize via \\`user.role\\`. ContractSpec enforces an org-driven rule:\n\n- If the **active organization** has \\`type = PLATFORM_ADMIN\\`, the signed-in user is ensured to have \\`User.role\\` containing \\`admin\\`.\n- This is applied in the session creation hook and re-checked in \\`assertsPlatformAdmin()\\`.\n\nThis keeps admin enablement deterministic and avoids manual role backfills.\n\n## Client config (React web + Expo)\n\nTo avoid duplicate background refresh/polling loops in dev (Fast Refresh/HMR), the Better Auth client is implemented as a singleton cached on \\`globalThis\\`.\n\n- Web client: \\`packages/bundles/contractspec-studio/src/presentation/providers/auth/client.ts\\`\n- Native client: \\`packages/bundles/contractspec-studio/src/presentation/providers/auth/client.native.ts\\`\n\nImport guidance:\n\n- If you only need the context/hook, prefer importing from \\`@lssm/bundle.contractspec-studio/presentation/providers/auth\\`.\n- If you explicitly need the Better Auth client instance (e.g. admin impersonation, direct API calls), import from \\`@lssm/bundle.contractspec-studio/presentation/providers/auth/client\\`.\n\n## Public routes (login / signup)\n\nPublic auth pages should avoid eager \\`authClient\\` initialization.\n\nPattern used:\n\n- In the submit handler, dynamically import \\`@lssm/bundle.contractspec-studio/presentation/providers/auth/index.web\\` and call \\`authClient.signIn.*\\` / \\`authClient.signUp.*\\`.\n\nThis prevents session refresh behavior from starting just because a public page rendered.\n\n## Next.js proxy auth (web-landing)\n\nThe Next.js proxy/middleware is used for **redirect decisions only**. It must not perform DB-backed session reads on every request.\n\n- Source: \\`packages/apps/web-landing/src/proxy.ts\\`\n- Approach: cookie-only checks via Better Auth cookies helpers:\n  - \\`getSessionCookie(request)\\`\n  - \\`getCookieCache(request)\\`\n\nThese checks are intentionally optimistic and should only gate routing. Full authorization must still be enforced on server-side actions/routes and GraphQL resolvers.\n`\n}];\nregisterDocBlocks(tech_auth_better_auth_nextjs_DocBlocks);\n\n//#endregion\nexport { tech_auth_better_auth_nextjs_DocBlocks };\n//# sourceMappingURL=better-auth-nextjs.docblock.js.map"],"mappings":";;;AAGA,MAAM,yCAAyC,CAAC;CAC/C,IAAI;CACJ,OAAO;CACP,SAAS;CACT,MAAM;CACN,YAAY;CACZ,OAAO;CACP,MAAM;EACL;EACA;EACA;EACA;EACA;EACA;EACA;CACD,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA0DN,CAAC;AACF,kBAAkB,uCAAuC"}

package/dist/libs/contracts/dist/docs/tech/contracts/openapi-export.docblock.js

@@ -0,0 +1,58 @@
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/contracts/openapi-export.docblock.js
+const tech_contracts_openapi_export_DocBlocks = [{
+	id: "docs.tech.contracts.openapi-export",
+	title: "OpenAPI export (OpenAPI 3.1) from SpecRegistry",
+	summary: "Generate a deterministic OpenAPI document from a SpecRegistry using jsonSchemaForSpec + REST transport metadata.",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/contracts/openapi-export",
+	tags: [
+		"contracts",
+		"openapi",
+		"rest"
+	],
+	body: `## OpenAPI export (OpenAPI 3.1) from SpecRegistry
+
+### Purpose
+
+ContractSpec specs can be exported into an **OpenAPI 3.1** document for tooling (SDK generation, docs, gateways).
+
+The export is **spec-first**:
+
+- Uses \`jsonSchemaForSpec(spec)\` for input/output JSON Schema (from SchemaModel → zod → JSON Schema)
+- Uses \`spec.transport.rest.method/path\` when present
+- Falls back to deterministic defaults:
+  - Method: \`POST\` for commands, \`GET\` for queries
+  - Path: \`defaultRestPath(name, version)\` → \`/<dot/name>/v<version>\`
+
+### Library API
+
+- Function: \`openApiForRegistry(registry, options?)\`
+- Location: \`@lssm/lib.contracts/openapi\`
+
+### CLI
+
+Export OpenAPI from a registry module:
+
+\`\`\`bash
+contractspec openapi --registry ./src/registry.ts --out ./openapi.json
+\`\`\`
+
+The registry module must export one of:
+
+- \`registry: SpecRegistry\`
+- \`default(): SpecRegistry | Promise<SpecRegistry>\`
+- \`createRegistry(): SpecRegistry | Promise<SpecRegistry>\`
+
+### Notes / limitations (current)
+
+- Responses are generated as a basic \`200\` response (plus schemas when available).
+- Query (GET) inputs are currently represented as a JSON request body when an input schema exists.
+- Errors are not yet expanded into OpenAPI responses; that will be added when we standardize error envelopes.`
+}];
+registerDocBlocks(tech_contracts_openapi_export_DocBlocks);
+
+//#endregion
+//# sourceMappingURL=openapi-export.docblock.js.map

package/dist/libs/contracts/dist/docs/tech/contracts/openapi-export.docblock.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"openapi-export.docblock.js","names":[],"sources":["../../../../../../../../../libs/contracts/dist/docs/tech/contracts/openapi-export.docblock.js"],"sourcesContent":["import { registerDocBlocks } from \"../../registry.js\";\n\n//#region src/docs/tech/contracts/openapi-export.docblock.ts\nconst tech_contracts_openapi_export_DocBlocks = [{\n\tid: \"docs.tech.contracts.openapi-export\",\n\ttitle: \"OpenAPI export (OpenAPI 3.1) from SpecRegistry\",\n\tsummary: \"Generate a deterministic OpenAPI document from a SpecRegistry using jsonSchemaForSpec + REST transport metadata.\",\n\tkind: \"reference\",\n\tvisibility: \"public\",\n\troute: \"/docs/tech/contracts/openapi-export\",\n\ttags: [\n\t\t\"contracts\",\n\t\t\"openapi\",\n\t\t\"rest\"\n\t],\n\tbody: `## OpenAPI export (OpenAPI 3.1) from SpecRegistry\n\n### Purpose\n\nContractSpec specs can be exported into an **OpenAPI 3.1** document for tooling (SDK generation, docs, gateways).\n\nThe export is **spec-first**:\n\n- Uses \\`jsonSchemaForSpec(spec)\\` for input/output JSON Schema (from SchemaModel → zod → JSON Schema)\n- Uses \\`spec.transport.rest.method/path\\` when present\n- Falls back to deterministic defaults:\n  - Method: \\`POST\\` for commands, \\`GET\\` for queries\n  - Path: \\`defaultRestPath(name, version)\\` → \\`/<dot/name>/v<version>\\`\n\n### Library API\n\n- Function: \\`openApiForRegistry(registry, options?)\\`\n- Location: \\`@lssm/lib.contracts/openapi\\`\n\n### CLI\n\nExport OpenAPI from a registry module:\n\n\\`\\`\\`bash\ncontractspec openapi --registry ./src/registry.ts --out ./openapi.json\n\\`\\`\\`\n\nThe registry module must export one of:\n\n- \\`registry: SpecRegistry\\`\n- \\`default(): SpecRegistry | Promise<SpecRegistry>\\`\n- \\`createRegistry(): SpecRegistry | Promise<SpecRegistry>\\`\n\n### Notes / limitations (current)\n\n- Responses are generated as a basic \\`200\\` response (plus schemas when available).\n- Query (GET) inputs are currently represented as a JSON request body when an input schema exists.\n- Errors are not yet expanded into OpenAPI responses; that will be added when we standardize error envelopes.`\n}];\nregisterDocBlocks(tech_contracts_openapi_export_DocBlocks);\n\n//#endregion\nexport { tech_contracts_openapi_export_DocBlocks };\n//# sourceMappingURL=openapi-export.docblock.js.map"],"mappings":";;;AAGA,MAAM,0CAA0C,CAAC;CAChD,IAAI;CACJ,OAAO;CACP,SAAS;CACT,MAAM;CACN,YAAY;CACZ,OAAO;CACP,MAAM;EACL;EACA;EACA;EACA;CACD,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsCN,CAAC;AACF,kBAAkB,wCAAwC"}

package/dist/libs/contracts/dist/docs/tech/lifecycle-stage-system.docblock.js

@@ -0,0 +1,17 @@
+import { registerDocBlocks } from "../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/lifecycle-stage-system.docblock.js
+const tech_lifecycle_stage_system_DocBlocks = [{
+	id: "docs.tech.lifecycle-stage-system",
+	title: "ContractSpec Lifecycle Stage System – Technical Design",
+	summary: "This document describes how ContractSpec implements lifecycle detection and guidance. It covers architecture, module boundaries, scoring heuristics, and integration points so libraries, modules, bundles, and Studio surfaces stay synchronized.",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/lifecycle-stage-system",
+	tags: ["tech", "lifecycle-stage-system"],
+	body: "## ContractSpec Lifecycle Stage System – Technical Design\n\nThis document describes how ContractSpec implements lifecycle detection and guidance. It covers architecture, module boundaries, scoring heuristics, and integration points so libraries, modules, bundles, and Studio surfaces stay synchronized.\n\n---\n\n### 1. Architecture Overview\n\n```\n┌──────────────────────┐\n│ @lssm/lib.lifecycle  │  Types, enums, helpers (pure data)\n└───────────┬──────────┘\n            │\n┌───────────▼──────────┐    ┌───────────────────────────┐\n│ modules/lifecycle-   │    │ modules/lifecycle-advisor  │\n│ core (detection)     │    │ (guidance & ceremonies)    │\n└───────────┬──────────┘    └───────────┬───────────────┘\n            │                           │\n            ├────────────┬──────────────┤\n            ▼            ▼              ▼\n  Adapters: analytics, intent, questionnaires\n            │\n┌───────────▼──────────┐\n│ bundles/lifecycle-   │  Managed service for Studio\n│ managed              │  (REST handlers, AI agent)     │\n└───────────┬──────────┘\n            │\n  ContractSpec Studio surfaces\n  (web/mobile APIs, CLI, docs)\n```\n\n- **Libraries** provide shared vocabulary.\n- **Modules** encapsulate logic, accepting adapters to avoid environment-specific code.\n- **Bundles** compose modules, register agents/events, and expose APIs for Studio.\n- **Apps** (web-landing, future Studio views) consume bundle APIs; they do not reimplement logic. For web-landing we now resolve `@lssm/bundle.contractspec-studio` and `@lssm/lib.database-contractspec-studio` directly from their `packages/.../src` folders via `tsconfig` path aliases so Prisma stays on the server build and Turbopack no longer pulls the prebundled `dist` artifacts into client chunks.\n\n---\n\n### 2. Core Library (`@lssm/lib.lifecycle`)\n\n- Stage enum (0–6) with metadata (`question`, `signals`, `traps`).\n- Axes types (`ProductPhase`, `CompanyPhase`, `CapitalPhase`).\n- `LifecycleSignal` (source, metric, value, timestamp).\n- `LifecycleMetricSnapshot` (aggregated numbers).\n- `LifecycleMilestone`, `LifecycleAction`, `LifecycleAssessment` interfaces.\n- Utility helpers:\n  - `formatStageSummary(stage, assessment)`\n  - `rankStageCandidates(scores)`\n\nThe library exports **no runtime dependencies** so it can be imported from apps, modules, and bundles alike.\n\n---\n\n### 3. Lifecycle Core Module\n\n**Location:** `packages/modules/lifecycle-core/`\n\n#### Components\n1. **StageSignalCollector**\n   - Accepts adapter interfaces:\n     - `AnalyticsAdapter` (pulls metrics from `@lssm/lib.analytics` or fixture streams).\n     - `IntentAdapter` (hooks into `@lssm/lib.observability` intent detectors or logs).\n     - `QuestionnaireAdapter` (loads JSON questionnaires and responses).\n   - Produces normalized `LifecycleSignal[]`.\n\n2. **StageScorer**\n   - Weighted scoring model:\n     - Base weight per stage (reflecting expected maturity).\n     - Feature weights (retention, revenue, team size, qualitative feedback).\n     - Confidence computed via variance of contributing signals.\n   - Supports pluggable scoring matrices via JSON config.\n   - Accepts sparse metric snapshots; the orchestrator sanitizes metrics to numeric-only records before persisting assessments so downstream analytics stay consistent.\n\n3. **LifecycleOrchestrator**\n   - Coordinates collectors + scorer.\n   - Returns `LifecycleAssessment` with:\n     - `stage`, `confidence`, `axisSnapshot`, `signalsUsed`.\n     - Recommended focus areas (high-level categories only).\n   - Emits events (internally) when stage confidence crosses thresholds (consumed later by bundle).\n\n4. **LifecycleMilestonePlanner**\n   - Loads `milestones-catalog.json` (no DB).\n   - Filters upcoming milestones per stage + axis.\n   - Tracks completion using provided IDs (caller persists).\n\n#### Data Files\n- `configs/stage-weights.json`\n- `configs/milestones-catalog.json`\n- `questionnaires/stage-readiness.json`\n\n#### Extension Hooks\n- All adapters exported as TypeScript interfaces.\n- Implementations for analytics/intent can live in bundles or apps without modifying module code.\n\n---\n\n### 4. Lifecycle Advisor Module\n\n**Location:** `packages/modules/lifecycle-advisor/`\n\n#### Components\n1. **LifecycleRecommendationEngine**\n   - Consumes `LifecycleAssessment`.\n   - Maps gaps to `LifecycleAction[]` using rule tables (`stage-playbooks.ts`).\n   - Supports override hooks for customer-specific rules.\n\n2. **ContractSpecLibraryRecommender**\n   - Maintains mapping from stage → recommended libraries/modules/bundles.\n   - Returns prioritized list with rationale and adoption prerequisites.\n\n3. **LifecycleCeremonyDesigner**\n   - Provides textual/structural data for ceremonies (title, copy, animation cues, soundtrack references).\n   - Ensures low-tech friendly instructions (clear copy, undo guidance).\n\n4. **AI Hooks**\n   - Defines prompt templates and tool manifests for lifecycle advisor agents (consumed by bundles).\n   - Keeps actual LLM integration outside module.\n\n---\n\n### 5. Managed Bundle (`lifecycle-managed`)\n\n**Responsibilities**\n- Wire modules together.\n- Provide HTTP/GraphQL handlers (exact transport optional).\n- Register LifecycleAdvisorAgent via `@lssm/lib.ai-agent`.\n- LifecycleAdvisorAgent meta: domain `operations`, owners `team-lifecycle`, stability `experimental`, tags `guide/lifecycle/ops` so ops tooling can route incidents quickly.\n- Emit lifecycle events through `@lssm/lib.bus` + `@lssm/lib.analytics`.\n- Integrate with `contractspec-studio` packages:\n  - Use Studio contracts for authentication/tenant context (without accessing tenant DBs).\n  - Store assessments in Studio-managed storage abstractions (in-memory or file-based for now).\n\n**APIs**\n- `POST /lifecycle/assessments`: Accepts metrics + optional questionnaire answers. Returns `LifecycleAssessment`.\n- `GET /lifecycle/playbooks/:stage`: Returns stage playbook + ceremonies.\n- `POST /lifecycle/advise`: Invokes LifecycleAdvisorAgent with context.\n\n**Events**\n- `LifecycleAssessmentCreated`\n- `LifecycleStageChanged`\n- `LifecycleGuidanceConsumed`\n\n---\n\n### 6. Library Enhancements\n\n| Library | Enhancement |\n| --- | --- |\n| `@lssm/lib.analytics` | Lifecycle metric collectors, helper to emit stage events, adapter implementation used by `StageSignalCollector`. |\n| `@lssm/lib.evolution` | Accepts `LifecycleContext` when ranking spec anomalies/suggestions. |\n| `@lssm/lib.growth` | Stage-specific experiment templates + guardrails referencing lifecycle enums. |\n| `@lssm/lib.observability` | Lifecycle KPI pipeline definitions (drift detection, regression alerts). |\n\nEach enhancement must import stage types from `@lssm/lib.lifecycle`.\n\n---\n\n### 7. Feature Flags & Progressive Delivery\n\n- Add new flags in progressive-delivery library:\n  - `LIFECYCLE_DETECTION_ALPHA`\n  - `LIFECYCLE_ADVISOR_ALPHA`\n  - `LIFECYCLE_MANAGED_SERVICE`\n- Bundles/modules should check flags before enabling workflows.\n- Flags referenced in docs + Studio UI to avoid accidental exposure.\n\n---\n\n### 8. Analytics & Telemetry\n\n- Events defined in analytics library; consumed by bundle/app:\n  - `lifecycle_assessment_run`\n  - `lifecycle_stage_changed`\n  - `lifecycle_guidance_consumed`\n- Observability pipeline includes:\n  - Composite lifecycle health metric (weighted sum of KPIs).\n  - Drift detection comparing stage predictions over time.\n  - Alert manager recipes for regression (e.g., PMF drop).\n\n---\n\n### 9. Testing Strategy\n\n1. **Unit**\n   - StageScorer weight matrix.\n   - RecommendationEngine mapping.\n   - Library recommender stage coverage.\n\n2. **Contract**\n   - Adapters: ensure mock adapters satisfy interfaces.\n   - Bundles: ensure HTTP handlers respect request/response contracts even without persistence.\n\n3. **Integration**\n   - CLI example runs detection + guidance end-to-end on fixture data.\n   - Dashboard example renders assessments, verifying JSON structures remain stable.\n\n---\n\n### 10. Implementation Checklist\n\n- [ ] Documentation (product, tech, ops, user).\n- [ ] Library creation (`@lssm/lib.lifecycle`).\n- [ ] Modules (`lifecycle-core`, `lifecycle-advisor`).\n- [ ] Bundle (`lifecycle-managed`) + Studio wiring.\n- [ ] Library enhancements (analytics/evolution/growth/observability).\n- [ ] Examples (CLI + dashboard).\n- [ ] Feature flags + telemetry.\n- [ ] Automated tests + fixtures.\n\nKeep this document in sync as modules evolve. When adding new stages or axes, update `@lssm/lib.lifecycle` first, then cascade to adapters, then refresh docs + Studio copy.*** End Patch*** End Patch\n\n\n"
+}];
+registerDocBlocks(tech_lifecycle_stage_system_DocBlocks);
+
+//#endregion
+//# sourceMappingURL=lifecycle-stage-system.docblock.js.map

package/dist/libs/contracts/dist/docs/tech/lifecycle-stage-system.docblock.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"lifecycle-stage-system.docblock.js","names":[],"sources":["../../../../../../../../libs/contracts/dist/docs/tech/lifecycle-stage-system.docblock.js"],"sourcesContent":["import { registerDocBlocks } from \"../registry.js\";\n\n//#region src/docs/tech/lifecycle-stage-system.docblock.ts\nconst tech_lifecycle_stage_system_DocBlocks = [{\n\tid: \"docs.tech.lifecycle-stage-system\",\n\ttitle: \"ContractSpec Lifecycle Stage System – Technical Design\",\n\tsummary: \"This document describes how ContractSpec implements lifecycle detection and guidance. It covers architecture, module boundaries, scoring heuristics, and integration points so libraries, modules, bundles, and Studio surfaces stay synchronized.\",\n\tkind: \"reference\",\n\tvisibility: \"public\",\n\troute: \"/docs/tech/lifecycle-stage-system\",\n\ttags: [\"tech\", \"lifecycle-stage-system\"],\n\tbody: \"## ContractSpec Lifecycle Stage System – Technical Design\\n\\nThis document describes how ContractSpec implements lifecycle detection and guidance. It covers architecture, module boundaries, scoring heuristics, and integration points so libraries, modules, bundles, and Studio surfaces stay synchronized.\\n\\n---\\n\\n### 1. Architecture Overview\\n\\n```\\n┌──────────────────────┐\\n│ @lssm/lib.lifecycle  │  Types, enums, helpers (pure data)\\n└───────────┬──────────┘\\n            │\\n┌───────────▼──────────┐    ┌───────────────────────────┐\\n│ modules/lifecycle-   │    │ modules/lifecycle-advisor  │\\n│ core (detection)     │    │ (guidance & ceremonies)    │\\n└───────────┬──────────┘    └───────────┬───────────────┘\\n            │                           │\\n            ├────────────┬──────────────┤\\n            ▼            ▼              ▼\\n  Adapters: analytics, intent, questionnaires\\n            │\\n┌───────────▼──────────┐\\n│ bundles/lifecycle-   │  Managed service for Studio\\n│ managed              │  (REST handlers, AI agent)     │\\n└───────────┬──────────┘\\n            │\\n  ContractSpec Studio surfaces\\n  (web/mobile APIs, CLI, docs)\\n```\\n\\n- **Libraries** provide shared vocabulary.\\n- **Modules** encapsulate logic, accepting adapters to avoid environment-specific code.\\n- **Bundles** compose modules, register agents/events, and expose APIs for Studio.\\n- **Apps** (web-landing, future Studio views) consume bundle APIs; they do not reimplement logic. For web-landing we now resolve `@lssm/bundle.contractspec-studio` and `@lssm/lib.database-contractspec-studio` directly from their `packages/.../src` folders via `tsconfig` path aliases so Prisma stays on the server build and Turbopack no longer pulls the prebundled `dist` artifacts into client chunks.\\n\\n---\\n\\n### 2. Core Library (`@lssm/lib.lifecycle`)\\n\\n- Stage enum (0–6) with metadata (`question`, `signals`, `traps`).\\n- Axes types (`ProductPhase`, `CompanyPhase`, `CapitalPhase`).\\n- `LifecycleSignal` (source, metric, value, timestamp).\\n- `LifecycleMetricSnapshot` (aggregated numbers).\\n- `LifecycleMilestone`, `LifecycleAction`, `LifecycleAssessment` interfaces.\\n- Utility helpers:\\n  - `formatStageSummary(stage, assessment)`\\n  - `rankStageCandidates(scores)`\\n\\nThe library exports **no runtime dependencies** so it can be imported from apps, modules, and bundles alike.\\n\\n---\\n\\n### 3. Lifecycle Core Module\\n\\n**Location:** `packages/modules/lifecycle-core/`\\n\\n#### Components\\n1. **StageSignalCollector**\\n   - Accepts adapter interfaces:\\n     - `AnalyticsAdapter` (pulls metrics from `@lssm/lib.analytics` or fixture streams).\\n     - `IntentAdapter` (hooks into `@lssm/lib.observability` intent detectors or logs).\\n     - `QuestionnaireAdapter` (loads JSON questionnaires and responses).\\n   - Produces normalized `LifecycleSignal[]`.\\n\\n2. **StageScorer**\\n   - Weighted scoring model:\\n     - Base weight per stage (reflecting expected maturity).\\n     - Feature weights (retention, revenue, team size, qualitative feedback).\\n     - Confidence computed via variance of contributing signals.\\n   - Supports pluggable scoring matrices via JSON config.\\n   - Accepts sparse metric snapshots; the orchestrator sanitizes metrics to numeric-only records before persisting assessments so downstream analytics stay consistent.\\n\\n3. **LifecycleOrchestrator**\\n   - Coordinates collectors + scorer.\\n   - Returns `LifecycleAssessment` with:\\n     - `stage`, `confidence`, `axisSnapshot`, `signalsUsed`.\\n     - Recommended focus areas (high-level categories only).\\n   - Emits events (internally) when stage confidence crosses thresholds (consumed later by bundle).\\n\\n4. **LifecycleMilestonePlanner**\\n   - Loads `milestones-catalog.json` (no DB).\\n   - Filters upcoming milestones per stage + axis.\\n   - Tracks completion using provided IDs (caller persists).\\n\\n#### Data Files\\n- `configs/stage-weights.json`\\n- `configs/milestones-catalog.json`\\n- `questionnaires/stage-readiness.json`\\n\\n#### Extension Hooks\\n- All adapters exported as TypeScript interfaces.\\n- Implementations for analytics/intent can live in bundles or apps without modifying module code.\\n\\n---\\n\\n### 4. Lifecycle Advisor Module\\n\\n**Location:** `packages/modules/lifecycle-advisor/`\\n\\n#### Components\\n1. **LifecycleRecommendationEngine**\\n   - Consumes `LifecycleAssessment`.\\n   - Maps gaps to `LifecycleAction[]` using rule tables (`stage-playbooks.ts`).\\n   - Supports override hooks for customer-specific rules.\\n\\n2. **ContractSpecLibraryRecommender**\\n   - Maintains mapping from stage → recommended libraries/modules/bundles.\\n   - Returns prioritized list with rationale and adoption prerequisites.\\n\\n3. **LifecycleCeremonyDesigner**\\n   - Provides textual/structural data for ceremonies (title, copy, animation cues, soundtrack references).\\n   - Ensures low-tech friendly instructions (clear copy, undo guidance).\\n\\n4. **AI Hooks**\\n   - Defines prompt templates and tool manifests for lifecycle advisor agents (consumed by bundles).\\n   - Keeps actual LLM integration outside module.\\n\\n---\\n\\n### 5. Managed Bundle (`lifecycle-managed`)\\n\\n**Responsibilities**\\n- Wire modules together.\\n- Provide HTTP/GraphQL handlers (exact transport optional).\\n- Register LifecycleAdvisorAgent via `@lssm/lib.ai-agent`.\\n- LifecycleAdvisorAgent meta: domain `operations`, owners `team-lifecycle`, stability `experimental`, tags `guide/lifecycle/ops` so ops tooling can route incidents quickly.\\n- Emit lifecycle events through `@lssm/lib.bus` + `@lssm/lib.analytics`.\\n- Integrate with `contractspec-studio` packages:\\n  - Use Studio contracts for authentication/tenant context (without accessing tenant DBs).\\n  - Store assessments in Studio-managed storage abstractions (in-memory or file-based for now).\\n\\n**APIs**\\n- `POST /lifecycle/assessments`: Accepts metrics + optional questionnaire answers. Returns `LifecycleAssessment`.\\n- `GET /lifecycle/playbooks/:stage`: Returns stage playbook + ceremonies.\\n- `POST /lifecycle/advise`: Invokes LifecycleAdvisorAgent with context.\\n\\n**Events**\\n- `LifecycleAssessmentCreated`\\n- `LifecycleStageChanged`\\n- `LifecycleGuidanceConsumed`\\n\\n---\\n\\n### 6. Library Enhancements\\n\\n| Library | Enhancement |\\n| --- | --- |\\n| `@lssm/lib.analytics` | Lifecycle metric collectors, helper to emit stage events, adapter implementation used by `StageSignalCollector`. |\\n| `@lssm/lib.evolution` | Accepts `LifecycleContext` when ranking spec anomalies/suggestions. |\\n| `@lssm/lib.growth` | Stage-specific experiment templates + guardrails referencing lifecycle enums. |\\n| `@lssm/lib.observability` | Lifecycle KPI pipeline definitions (drift detection, regression alerts). |\\n\\nEach enhancement must import stage types from `@lssm/lib.lifecycle`.\\n\\n---\\n\\n### 7. Feature Flags & Progressive Delivery\\n\\n- Add new flags in progressive-delivery library:\\n  - `LIFECYCLE_DETECTION_ALPHA`\\n  - `LIFECYCLE_ADVISOR_ALPHA`\\n  - `LIFECYCLE_MANAGED_SERVICE`\\n- Bundles/modules should check flags before enabling workflows.\\n- Flags referenced in docs + Studio UI to avoid accidental exposure.\\n\\n---\\n\\n### 8. Analytics & Telemetry\\n\\n- Events defined in analytics library; consumed by bundle/app:\\n  - `lifecycle_assessment_run`\\n  - `lifecycle_stage_changed`\\n  - `lifecycle_guidance_consumed`\\n- Observability pipeline includes:\\n  - Composite lifecycle health metric (weighted sum of KPIs).\\n  - Drift detection comparing stage predictions over time.\\n  - Alert manager recipes for regression (e.g., PMF drop).\\n\\n---\\n\\n### 9. Testing Strategy\\n\\n1. **Unit**\\n   - StageScorer weight matrix.\\n   - RecommendationEngine mapping.\\n   - Library recommender stage coverage.\\n\\n2. **Contract**\\n   - Adapters: ensure mock adapters satisfy interfaces.\\n   - Bundles: ensure HTTP handlers respect request/response contracts even without persistence.\\n\\n3. **Integration**\\n   - CLI example runs detection + guidance end-to-end on fixture data.\\n   - Dashboard example renders assessments, verifying JSON structures remain stable.\\n\\n---\\n\\n### 10. Implementation Checklist\\n\\n- [ ] Documentation (product, tech, ops, user).\\n- [ ] Library creation (`@lssm/lib.lifecycle`).\\n- [ ] Modules (`lifecycle-core`, `lifecycle-advisor`).\\n- [ ] Bundle (`lifecycle-managed`) + Studio wiring.\\n- [ ] Library enhancements (analytics/evolution/growth/observability).\\n- [ ] Examples (CLI + dashboard).\\n- [ ] Feature flags + telemetry.\\n- [ ] Automated tests + fixtures.\\n\\nKeep this document in sync as modules evolve. When adding new stages or axes, update `@lssm/lib.lifecycle` first, then cascade to adapters, then refresh docs + Studio copy.*** End Patch*** End Patch\\n\\n\\n\"\n}];\nregisterDocBlocks(tech_lifecycle_stage_system_DocBlocks);\n\n//#endregion\nexport { tech_lifecycle_stage_system_DocBlocks };\n//# sourceMappingURL=lifecycle-stage-system.docblock.js.map"],"mappings":";;;AAGA,MAAM,wCAAwC,CAAC;CAC9C,IAAI;CACJ,OAAO;CACP,SAAS;CACT,MAAM;CACN,YAAY;CACZ,OAAO;CACP,MAAM,CAAC,QAAQ,yBAAyB;CACxC,MAAM;CACN,CAAC;AACF,kBAAkB,sCAAsC"}

package/dist/libs/contracts/dist/docs/tech/llm/llm-integration.docblock.js

@@ -0,0 +1,358 @@
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/llm/llm-integration.docblock.js
+const tech_llm_integration_DocBlocks = [
+	{
+		id: "docs.tech.llm.overview",
+		title: "LLM Integration Overview",
+		summary: "Export specs to LLM-friendly formats, generate implementation guides, and verify implementations.",
+		kind: "reference",
+		visibility: "public",
+		route: "/docs/tech/llm/overview",
+		tags: [
+			"llm",
+			"ai",
+			"export",
+			"guide",
+			"verify"
+		],
+		body: `# LLM Integration
+
+ContractSpec provides first-class LLM integration to bridge specifications and AI coding agents.
+
+## Core Features
+
+### 1. Multi-Format Export
+
+Export specs to markdown in formats optimized for LLM consumption:
+
+- **Context format**: Summary for understanding (goal, context, acceptance criteria)
+- **Full format**: Complete spec with all details (I/O schemas, policy, events)
+- **Prompt format**: Actionable prompt with implementation instructions
+
+### 2. Implementation Guidance
+
+Generate agent-specific implementation plans:
+
+- **Claude Code**: Extended thinking mode with structured prompts
+- **Cursor CLI**: Background/composer mode with .mdc rules generation
+- **Generic MCP**: Standard format for any MCP-compatible agent
+
+### 3. Tiered Verification
+
+Verify implementations against specs:
+
+- **Tier 1 (Structure)**: Types, exports, imports validation
+- **Tier 2 (Behavior)**: Scenario coverage, error handling, events
+- **Tier 3 (AI Review)**: Semantic compliance analysis via LLM
+
+## Access Points
+
+| Surface | Commands/Tools |
+|---------|---------------|
+| CLI | \`contractspec llm export\`, \`guide\`, \`verify\`, \`copy\` |
+| MCP | \`llm.export\`, \`llm.guide\`, \`llm.verify\` tools |
+| VSCode | Export to LLM, Generate Guide, Verify, Copy commands |
+
+## Quick Start
+
+### CLI Usage
+
+\`\`\`bash
+# Export spec as markdown
+contractspec llm export path/to/my.spec.ts --format full
+
+# Generate implementation guide
+contractspec llm guide path/to/my.spec.ts --agent claude-code
+
+# Verify implementation
+contractspec llm verify path/to/my.spec.ts path/to/impl.ts --tier 2
+
+# Copy spec to clipboard
+contractspec llm copy path/to/my.spec.ts --format context
+\`\`\`
+
+### MCP Usage
+
+\`\`\`
+# Export spec
+llm.export { specPath: "path/to/my.spec.ts", format: "full" }
+
+# Generate guide
+llm.guide { specPath: "path/to/my.spec.ts", agent: "cursor-cli" }
+
+# Verify implementation
+llm.verify { specPath: "path/to/my.spec.ts", implementationPath: "path/to/impl.ts", tier: "2" }
+\`\`\`
+
+### Programmatic Usage
+
+\`\`\`typescript
+import { specToFullMarkdown, specToAgentPrompt } from '@lssm/lib.contracts/llm';
+import { createAgentGuideService, createVerifyService } from '@lssm/bundle.contractspec-workspace';
+
+// Export
+const markdown = specToFullMarkdown(mySpec);
+
+// Generate guide
+const guideService = createAgentGuideService({ defaultAgent: 'claude-code' });
+const guide = guideService.generateGuide(mySpec);
+
+// Verify
+const verifyService = createVerifyService();
+const result = await verifyService.verify(mySpec, implementationCode, {
+  tiers: ['structure', 'behavior']
+});
+\`\`\`
+`
+	},
+	{
+		id: "docs.tech.llm.export-formats",
+		title: "LLM Export Formats",
+		summary: "Detailed explanation of the three export formats for LLM consumption.",
+		kind: "reference",
+		visibility: "public",
+		route: "/docs/tech/llm/export-formats",
+		tags: [
+			"llm",
+			"export",
+			"markdown"
+		],
+		body: `# LLM Export Formats
+
+ContractSpec provides three export formats optimized for different LLM use cases.
+
+## Context Format
+
+Best for: Understanding what a spec does, providing background to LLMs.
+
+Includes:
+- Spec name, version, type
+- Goal and context
+- Description
+- Acceptance scenarios
+
+Example:
+
+\`\`\`markdown
+# users.createUser (v1)
+
+> Create a new user account with email verification.
+
+**Type:** command | **Stability:** stable
+
+## Goal
+Create a new user in the system and trigger email verification.
+
+## Context
+Part of the user onboarding flow. Called after signup form submission.
+
+## Acceptance Criteria
+### Happy path
+**Given:** Valid email and password
+**When:** User submits registration
+**Then:** Account is created, verification email is sent
+\`\`\`
+
+## Full Format
+
+Best for: Complete documentation, implementation reference.
+
+Includes everything:
+- All metadata
+- JSON schemas for I/O
+- Error definitions
+- Policy (auth, rate limits, PII)
+- Events emitted
+- Examples
+- Transport configuration
+
+## Prompt Format
+
+Best for: Feeding directly to coding agents.
+
+Includes:
+- Task header with clear instructions
+- Full spec context
+- Implementation requirements
+- Task-specific guidance (implement/test/refactor/review)
+- Expected output format
+
+The prompt format adapts based on task type:
+- **implement**: Full implementation with tests
+- **test**: Test generation for existing code
+- **refactor**: Refactoring while maintaining behavior
+- **review**: Code review against spec
+`
+	},
+	{
+		id: "docs.tech.llm.agent-adapters",
+		title: "Agent Adapters",
+		summary: "Adapters for different AI coding agents (Claude, Cursor, MCP).",
+		kind: "reference",
+		visibility: "public",
+		route: "/docs/tech/llm/agent-adapters",
+		tags: [
+			"llm",
+			"agents",
+			"claude",
+			"cursor",
+			"mcp"
+		],
+		body: `# Agent Adapters
+
+ContractSpec provides specialized adapters for different AI coding agents.
+
+## Claude Code Adapter
+
+Optimized for Anthropic Claude's extended thinking and code generation.
+
+Features:
+- Structured markdown with clear sections
+- Checklists for steps and verification
+- Icons for file operations (📝 create, ✏️ modify)
+- System prompt for ContractSpec context
+
+Usage:
+\`\`\`typescript
+const guideService = createAgentGuideService({ defaultAgent: 'claude-code' });
+const result = guideService.generateGuide(spec, { agent: 'claude-code' });
+// result.prompt.systemPrompt - Claude system context
+// result.prompt.taskPrompt - Task-specific instructions
+\`\`\`
+
+## Cursor CLI Adapter
+
+Optimized for Cursor's background/composer mode.
+
+Features:
+- Compact format for context efficiency
+- .mdc cursor rules generation
+- Integration with Cursor's file system
+- Concise step lists
+
+Generate Cursor Rules:
+\`\`\`typescript
+const cursorRules = guideService.generateAgentConfig(spec, 'cursor-cli');
+// Save to .cursor/rules/my-spec.mdc
+\`\`\`
+
+## Generic MCP Adapter
+
+Works with any MCP-compatible agent (Cline, Aider, etc.).
+
+Features:
+- Standard markdown format
+- Table-based metadata
+- JSON resource format support
+- Prompt message format
+
+The generic adapter is the default and works across all agents.
+
+## Choosing an Adapter
+
+| Agent | Best For | Key Features |
+|-------|----------|--------------|
+| Claude Code | Complex implementations | Extended thinking, detailed steps |
+| Cursor CLI | IDE-integrated work | Cursor rules, compact format |
+| Generic MCP | Any MCP agent | Universal compatibility |
+`
+	},
+	{
+		id: "docs.tech.llm.verification",
+		title: "Implementation Verification",
+		summary: "Tiered verification of implementations against specifications.",
+		kind: "reference",
+		visibility: "public",
+		route: "/docs/tech/llm/verification",
+		tags: [
+			"llm",
+			"verify",
+			"validation",
+			"testing"
+		],
+		body: `# Implementation Verification
+
+ContractSpec provides tiered verification to check if implementations comply with specs.
+
+## Verification Tiers
+
+### Tier 1: Structure (Fast)
+
+Checks TypeScript structure against spec requirements:
+
+| Check | What it validates |
+|-------|------------------|
+| Handler export | Function is properly exported |
+| Contracts import | Imports from @lssm/lib.contracts |
+| Schema import | Imports from @lssm/lib.schema |
+| No \`any\` type | TypeScript strict compliance |
+| Error handling | Error codes are referenced |
+| Event emission | Event patterns exist |
+| Input validation | Validation patterns used |
+| Async patterns | Async/await for commands |
+
+### Tier 2: Behavior (Comprehensive)
+
+Checks implementation coverage of spec behaviors:
+
+| Check | What it validates |
+|-------|------------------|
+| Scenario coverage | Acceptance scenarios implemented |
+| Example coverage | Example I/O values referenced |
+| Error cases | All error conditions handled |
+| Event conditions | Events emitted correctly |
+| Idempotency | Idempotent patterns (if required) |
+
+### Tier 3: AI Review (Deep)
+
+Uses LLM for semantic analysis:
+
+- Does the implementation fulfill the spec's intent?
+- Are edge cases properly handled?
+- Is the code quality acceptable?
+- Are there any subtle violations?
+
+Requires AI API key configuration.
+
+## Running Verification
+
+\`\`\`typescript
+const verifyService = createVerifyService({
+  aiApiKey: process.env.ANTHROPIC_API_KEY, // Optional, for Tier 3
+  aiProvider: 'anthropic',
+});
+
+const result = await verifyService.verify(spec, implementationCode, {
+  tiers: ['structure', 'behavior'],
+  failFast: false,
+  includeSuggestions: true,
+});
+
+console.log(result.passed);  // true/false
+console.log(result.score);   // 0-100
+console.log(result.summary); // Human-readable summary
+\`\`\`
+
+## Verification Report
+
+The report includes:
+
+- **passed**: Overall compliance
+- **score**: 0-100 score
+- **issues**: Array of problems found
+- **suggestions**: Recommended fixes
+- **coverage**: Metrics on scenario/error/field coverage
+
+Each issue has:
+- **severity**: error, warning, or info
+- **category**: type, export, import, scenario, error_handling, semantic
+- **message**: Description of the issue
+- **suggestion**: How to fix it
+`
+	}
+];
+registerDocBlocks(tech_llm_integration_DocBlocks);
+
+//#endregion
+//# sourceMappingURL=llm-integration.docblock.js.map

package/dist/libs/contracts/dist/docs/tech/llm/llm-integration.docblock.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"llm-integration.docblock.js","names":[],"sources":["../../../../../../../../../libs/contracts/dist/docs/tech/llm/llm-integration.docblock.js"],"sourcesContent":["import { registerDocBlocks } from \"../../registry.js\";\n\n//#region src/docs/tech/llm/llm-integration.docblock.ts\nconst tech_llm_integration_DocBlocks = [\n\t{\n\t\tid: \"docs.tech.llm.overview\",\n\t\ttitle: \"LLM Integration Overview\",\n\t\tsummary: \"Export specs to LLM-friendly formats, generate implementation guides, and verify implementations.\",\n\t\tkind: \"reference\",\n\t\tvisibility: \"public\",\n\t\troute: \"/docs/tech/llm/overview\",\n\t\ttags: [\n\t\t\t\"llm\",\n\t\t\t\"ai\",\n\t\t\t\"export\",\n\t\t\t\"guide\",\n\t\t\t\"verify\"\n\t\t],\n\t\tbody: `# LLM Integration\n\nContractSpec provides first-class LLM integration to bridge specifications and AI coding agents.\n\n## Core Features\n\n### 1. Multi-Format Export\n\nExport specs to markdown in formats optimized for LLM consumption:\n\n- **Context format**: Summary for understanding (goal, context, acceptance criteria)\n- **Full format**: Complete spec with all details (I/O schemas, policy, events)\n- **Prompt format**: Actionable prompt with implementation instructions\n\n### 2. Implementation Guidance\n\nGenerate agent-specific implementation plans:\n\n- **Claude Code**: Extended thinking mode with structured prompts\n- **Cursor CLI**: Background/composer mode with .mdc rules generation\n- **Generic MCP**: Standard format for any MCP-compatible agent\n\n### 3. Tiered Verification\n\nVerify implementations against specs:\n\n- **Tier 1 (Structure)**: Types, exports, imports validation\n- **Tier 2 (Behavior)**: Scenario coverage, error handling, events\n- **Tier 3 (AI Review)**: Semantic compliance analysis via LLM\n\n## Access Points\n\n| Surface | Commands/Tools |\n|---------|---------------|\n| CLI | \\`contractspec llm export\\`, \\`guide\\`, \\`verify\\`, \\`copy\\` |\n| MCP | \\`llm.export\\`, \\`llm.guide\\`, \\`llm.verify\\` tools |\n| VSCode | Export to LLM, Generate Guide, Verify, Copy commands |\n\n## Quick Start\n\n### CLI Usage\n\n\\`\\`\\`bash\n# Export spec as markdown\ncontractspec llm export path/to/my.spec.ts --format full\n\n# Generate implementation guide\ncontractspec llm guide path/to/my.spec.ts --agent claude-code\n\n# Verify implementation\ncontractspec llm verify path/to/my.spec.ts path/to/impl.ts --tier 2\n\n# Copy spec to clipboard\ncontractspec llm copy path/to/my.spec.ts --format context\n\\`\\`\\`\n\n### MCP Usage\n\n\\`\\`\\`\n# Export spec\nllm.export { specPath: \"path/to/my.spec.ts\", format: \"full\" }\n\n# Generate guide\nllm.guide { specPath: \"path/to/my.spec.ts\", agent: \"cursor-cli\" }\n\n# Verify implementation\nllm.verify { specPath: \"path/to/my.spec.ts\", implementationPath: \"path/to/impl.ts\", tier: \"2\" }\n\\`\\`\\`\n\n### Programmatic Usage\n\n\\`\\`\\`typescript\nimport { specToFullMarkdown, specToAgentPrompt } from '@lssm/lib.contracts/llm';\nimport { createAgentGuideService, createVerifyService } from '@lssm/bundle.contractspec-workspace';\n\n// Export\nconst markdown = specToFullMarkdown(mySpec);\n\n// Generate guide\nconst guideService = createAgentGuideService({ defaultAgent: 'claude-code' });\nconst guide = guideService.generateGuide(mySpec);\n\n// Verify\nconst verifyService = createVerifyService();\nconst result = await verifyService.verify(mySpec, implementationCode, {\n  tiers: ['structure', 'behavior']\n});\n\\`\\`\\`\n`\n\t},\n\t{\n\t\tid: \"docs.tech.llm.export-formats\",\n\t\ttitle: \"LLM Export Formats\",\n\t\tsummary: \"Detailed explanation of the three export formats for LLM consumption.\",\n\t\tkind: \"reference\",\n\t\tvisibility: \"public\",\n\t\troute: \"/docs/tech/llm/export-formats\",\n\t\ttags: [\n\t\t\t\"llm\",\n\t\t\t\"export\",\n\t\t\t\"markdown\"\n\t\t],\n\t\tbody: `# LLM Export Formats\n\nContractSpec provides three export formats optimized for different LLM use cases.\n\n## Context Format\n\nBest for: Understanding what a spec does, providing background to LLMs.\n\nIncludes:\n- Spec name, version, type\n- Goal and context\n- Description\n- Acceptance scenarios\n\nExample:\n\n\\`\\`\\`markdown\n# users.createUser (v1)\n\n> Create a new user account with email verification.\n\n**Type:** command | **Stability:** stable\n\n## Goal\nCreate a new user in the system and trigger email verification.\n\n## Context\nPart of the user onboarding flow. Called after signup form submission.\n\n## Acceptance Criteria\n### Happy path\n**Given:** Valid email and password\n**When:** User submits registration\n**Then:** Account is created, verification email is sent\n\\`\\`\\`\n\n## Full Format\n\nBest for: Complete documentation, implementation reference.\n\nIncludes everything:\n- All metadata\n- JSON schemas for I/O\n- Error definitions\n- Policy (auth, rate limits, PII)\n- Events emitted\n- Examples\n- Transport configuration\n\n## Prompt Format\n\nBest for: Feeding directly to coding agents.\n\nIncludes:\n- Task header with clear instructions\n- Full spec context\n- Implementation requirements\n- Task-specific guidance (implement/test/refactor/review)\n- Expected output format\n\nThe prompt format adapts based on task type:\n- **implement**: Full implementation with tests\n- **test**: Test generation for existing code\n- **refactor**: Refactoring while maintaining behavior\n- **review**: Code review against spec\n`\n\t},\n\t{\n\t\tid: \"docs.tech.llm.agent-adapters\",\n\t\ttitle: \"Agent Adapters\",\n\t\tsummary: \"Adapters for different AI coding agents (Claude, Cursor, MCP).\",\n\t\tkind: \"reference\",\n\t\tvisibility: \"public\",\n\t\troute: \"/docs/tech/llm/agent-adapters\",\n\t\ttags: [\n\t\t\t\"llm\",\n\t\t\t\"agents\",\n\t\t\t\"claude\",\n\t\t\t\"cursor\",\n\t\t\t\"mcp\"\n\t\t],\n\t\tbody: `# Agent Adapters\n\nContractSpec provides specialized adapters for different AI coding agents.\n\n## Claude Code Adapter\n\nOptimized for Anthropic Claude's extended thinking and code generation.\n\nFeatures:\n- Structured markdown with clear sections\n- Checklists for steps and verification\n- Icons for file operations (📝 create, ✏️ modify)\n- System prompt for ContractSpec context\n\nUsage:\n\\`\\`\\`typescript\nconst guideService = createAgentGuideService({ defaultAgent: 'claude-code' });\nconst result = guideService.generateGuide(spec, { agent: 'claude-code' });\n// result.prompt.systemPrompt - Claude system context\n// result.prompt.taskPrompt - Task-specific instructions\n\\`\\`\\`\n\n## Cursor CLI Adapter\n\nOptimized for Cursor's background/composer mode.\n\nFeatures:\n- Compact format for context efficiency\n- .mdc cursor rules generation\n- Integration with Cursor's file system\n- Concise step lists\n\nGenerate Cursor Rules:\n\\`\\`\\`typescript\nconst cursorRules = guideService.generateAgentConfig(spec, 'cursor-cli');\n// Save to .cursor/rules/my-spec.mdc\n\\`\\`\\`\n\n## Generic MCP Adapter\n\nWorks with any MCP-compatible agent (Cline, Aider, etc.).\n\nFeatures:\n- Standard markdown format\n- Table-based metadata\n- JSON resource format support\n- Prompt message format\n\nThe generic adapter is the default and works across all agents.\n\n## Choosing an Adapter\n\n| Agent | Best For | Key Features |\n|-------|----------|--------------|\n| Claude Code | Complex implementations | Extended thinking, detailed steps |\n| Cursor CLI | IDE-integrated work | Cursor rules, compact format |\n| Generic MCP | Any MCP agent | Universal compatibility |\n`\n\t},\n\t{\n\t\tid: \"docs.tech.llm.verification\",\n\t\ttitle: \"Implementation Verification\",\n\t\tsummary: \"Tiered verification of implementations against specifications.\",\n\t\tkind: \"reference\",\n\t\tvisibility: \"public\",\n\t\troute: \"/docs/tech/llm/verification\",\n\t\ttags: [\n\t\t\t\"llm\",\n\t\t\t\"verify\",\n\t\t\t\"validation\",\n\t\t\t\"testing\"\n\t\t],\n\t\tbody: `# Implementation Verification\n\nContractSpec provides tiered verification to check if implementations comply with specs.\n\n## Verification Tiers\n\n### Tier 1: Structure (Fast)\n\nChecks TypeScript structure against spec requirements:\n\n| Check | What it validates |\n|-------|------------------|\n| Handler export | Function is properly exported |\n| Contracts import | Imports from @lssm/lib.contracts |\n| Schema import | Imports from @lssm/lib.schema |\n| No \\`any\\` type | TypeScript strict compliance |\n| Error handling | Error codes are referenced |\n| Event emission | Event patterns exist |\n| Input validation | Validation patterns used |\n| Async patterns | Async/await for commands |\n\n### Tier 2: Behavior (Comprehensive)\n\nChecks implementation coverage of spec behaviors:\n\n| Check | What it validates |\n|-------|------------------|\n| Scenario coverage | Acceptance scenarios implemented |\n| Example coverage | Example I/O values referenced |\n| Error cases | All error conditions handled |\n| Event conditions | Events emitted correctly |\n| Idempotency | Idempotent patterns (if required) |\n\n### Tier 3: AI Review (Deep)\n\nUses LLM for semantic analysis:\n\n- Does the implementation fulfill the spec's intent?\n- Are edge cases properly handled?\n- Is the code quality acceptable?\n- Are there any subtle violations?\n\nRequires AI API key configuration.\n\n## Running Verification\n\n\\`\\`\\`typescript\nconst verifyService = createVerifyService({\n  aiApiKey: process.env.ANTHROPIC_API_KEY, // Optional, for Tier 3\n  aiProvider: 'anthropic',\n});\n\nconst result = await verifyService.verify(spec, implementationCode, {\n  tiers: ['structure', 'behavior'],\n  failFast: false,\n  includeSuggestions: true,\n});\n\nconsole.log(result.passed);  // true/false\nconsole.log(result.score);   // 0-100\nconsole.log(result.summary); // Human-readable summary\n\\`\\`\\`\n\n## Verification Report\n\nThe report includes:\n\n- **passed**: Overall compliance\n- **score**: 0-100 score\n- **issues**: Array of problems found\n- **suggestions**: Recommended fixes\n- **coverage**: Metrics on scenario/error/field coverage\n\nEach issue has:\n- **severity**: error, warning, or info\n- **category**: type, export, import, scenario, error_handling, semantic\n- **message**: Description of the issue\n- **suggestion**: How to fix it\n`\n\t}\n];\nregisterDocBlocks(tech_llm_integration_DocBlocks);\n\n//#endregion\nexport { tech_llm_integration_DocBlocks };\n//# sourceMappingURL=llm-integration.docblock.js.map"],"mappings":";;;AAGA,MAAM,iCAAiC;CACtC;EACC,IAAI;EACJ,OAAO;EACP,SAAS;EACT,MAAM;EACN,YAAY;EACZ,OAAO;EACP,MAAM;GACL;GACA;GACA;GACA;GACA;GACA;EACD,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAyFN;CACD;EACC,IAAI;EACJ,OAAO;EACP,SAAS;EACT,MAAM;EACN,YAAY;EACZ,OAAO;EACP,MAAM;GACL;GACA;GACA;GACA;EACD,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAkEN;CACD;EACC,IAAI;EACJ,OAAO;EACP,SAAS;EACT,MAAM;EACN,YAAY;EACZ,OAAO;EACP,MAAM;GACL;GACA;GACA;GACA;GACA;GACA;EACD,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA0DN;CACD;EACC,IAAI;EACJ,OAAO;EACP,SAAS;EACT,MAAM;EACN,YAAY;EACZ,OAAO;EACP,MAAM;GACL;GACA;GACA;GACA;GACA;EACD,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA+EN;CACD;AACD,kBAAkB,+BAA+B"}