@lssm/example.saas-boilerplate 0.0.0-canary-20251217060804 → 0.0.0-canary-20251217062139

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

@@ -0,0 +1,58 @@
+import{a as e}from"../../registry.js";e([{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.
+`}]);

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

@@ -0,0 +1,38 @@
+import{a as e}from"../../registry.js";e([{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.`}]);

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

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

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

@@ -0,0 +1,289 @@
+import{a as e}from"../../registry.js";e([{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
+`}]);

package/dist/modules/notifications/dist/libs/contracts/dist/docs/tech/mcp-endpoints.docblock.js

@@ -0,0 +1 @@
+import{a as e}from"../registry.js";e([{id:`docs.tech.mcp.endpoints`,title:`ContractSpec MCP endpoints`,summary:`Dedicated MCP servers for docs, CLI usage, and internal development.`,kind:`reference`,visibility:`mixed`,route:`/docs/tech/mcp/endpoints`,tags:[`mcp`,`docs`,`cli`,`internal`],body:"# ContractSpec MCP endpoints\n\nThree dedicated MCP servers keep AI agents efficient and scoped:\n\n- **Docs MCP**: `/api/mcp/docs` — exposes DocBlocks as resources + presentations. Tool: `docs.search`.\n- **CLI MCP**: `/api/mcp/cli` — surfaces CLI quickstart/reference/README and suggests commands. Tool: `cli.suggestCommand`.\n- **Internal MCP**: `/api/mcp/internal` — internal routing hints, playbook, and example registry access. Tool: `internal.describe`.\n\n### Usage notes\n- Transports are HTTP POST (streamable HTTP); SSE is disabled.\n- Resources are namespaced (`docs://*`, `cli://*`, `internal://*`) and are read-only.\n- Internal MCP also exposes the examples registry via `examples://*` resources:\n  - `examples://list?q=<query>`\n  - `examples://example/<id>`\n- Prompts mirror each surface (navigator, usage, bootstrap) for quick agent onboarding.\n- GraphQL remains at `/graphql`; health at `/health`.\n"}]);

package/dist/modules/notifications/dist/libs/contracts/dist/docs/tech/presentation-runtime.docblock.js

@@ -0,0 +1 @@
+import{a as e}from"../registry.js";e([{id:`docs.tech.presentation-runtime`,title:`Presentation Runtime`,summary:`Cross-platform runtime for list pages and presentation flows.`,kind:`reference`,visibility:`public`,route:`/docs/tech/presentation-runtime`,tags:[`tech`,`presentation-runtime`],body:"## Presentation Runtime\n\nCross-platform runtime for list pages and presentation flows.\n\n### Packages\n\n- `@lssm/lib.presentation-runtime-core`: shared types and config helpers\n- `@lssm/lib.presentation-runtime-react`: React hooks (web/native-compatible API)\n- `@lssm/lib.presentation-runtime-react-native`: Native entrypoint (re-exports React API for now)\n\n### Next.js config helper\n\n```ts\n// next.config.mjs\nimport { withPresentationNextAliases } from '@lssm/lib.presentation-runtime-core/next';\n\nconst nextConfig = {\n  webpack: (config) => withPresentationNextAliases(config),\n};\n\nexport default nextConfig;\n```\n\n### Metro config helper\n\n```js\n// metro.config.js (CJS)\nconst { getDefaultConfig } = require('expo/metro-config');\nconst {\n  withPresentationMetroAliases,\n} = require('@lssm/lib.presentation-runtime-core/src/metro.cjs');\n\nconst projectRoot = __dirname;\nconst config = getDefaultConfig(projectRoot);\n\nmodule.exports = withPresentationMetroAliases(config);\n```\n\n### React hooks\n\n- `useListCoordinator`: URL + RHF + derived variables (no fetching)\n- `usePresentationController`: Same plus `fetcher` integration\n- `DataViewRenderer` (design-system): render `DataViewSpec` projections (`list`, `table`, `detail`, `grid`) using shared UI atoms\n\nBoth accept a `useUrlState` adapter. On web, use `useListUrlState` (design-system) or a Next adapter.\n\n### KYC molecules (bundle)\n\n- `ComplianceBadge` in `@lssm/bundle.strit/presentation/components/kyc` renders a status badge for KYC/compliance snapshots. It accepts a `state` (missing_core | incomplete | complete | expiring | unknown) and optional localized `labels`. Prefer consuming apps to pass translated labels (e.g., via `useT('appPlatformAdmin')`).\n\n### Markdown routes and llms.txt\n\n- Each web app exposes `/llms` (and `/llms.txt`, `/llms.md`) via rewrites. See [llmstxt.org](https://llmstxt.org/).\n- Catch‑all markdown handler lives at `app/[...slug].md/route.ts`. It resolves a page descriptor from `app/.presentations.manifest.json` and renders via the `presentations.v2` engine (target: `markdown`).\n- Per‑page companion convention: add `app/<route>/ai.ts` exporting a `PresentationDescriptorV2`.\n- Build‑time tool: `tools/generate-presentations-manifest.mjs <app-root>` populates the manifest.\n- CI check: `pnpm llms:check` verifies coverage (% of pages with descriptors) and fails if below threshold.\n"}]);