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

package/dist/libs/identity-rbac/dist/contracts/dist/docs/tech/PHASE_4_PERSONALIZATION_ENGINE.docblock.js

@@ -1,86 +1,15 @@
-import{a as e}from"../registry.js";e([{id:`docs.tech.PHASE_4_PERSONALIZATION_ENGINE`,title:`Phase 4: Personalization Engine`,summary:`**Status**: Complete`,kind:`reference`,visibility:`public`,route:`/docs/tech/PHASE_4_PERSONALIZATION_ENGINE`,tags:[`tech`,`PHASE_4_PERSONALIZATION_ENGINE`],body:`# Phase 4: Personalization Engine
-
-**Status**: Complete  
-**Last updated**: 2025-11-21
-
-Phase 4 unlocks tenant-scoped personalization with zero bespoke code. We shipped three new libraries, a signing-aware Overlay editor, and the persistence layer required to observe usage and apply overlays safely.
-
----
-
-## 1. Libraries
-
-### @lssm/lib.overlay-engine
-
-- OverlaySpec types + validator mirror the public spec.
-- Cryptographic signer (\`ed25519\`, \`rsa-pss-sha256\`) with canonical JSON serialization.
-- Registry that merges tenant/role/user/device overlays with predictable specificity.
-- React hooks (\`useOverlay\`, \`useOverlayFields\`) for client-side rendering.
-- Runtime engine audits every applied overlay for traceability.
-
-### @lssm/lib.personalization
-
-- Behavior tracker buffers field/feature/workflow events and exports OTel metrics.
-- Analyzer summarizes field usage and workflow drop-offs into actionable insights.
-- Adapter translates insights into overlay suggestions or workflow tweaks.
-- In-memory store implementation + interface for plugging Prisma/ClickHouse later.
-
-### @lssm/lib.workflow-composer
-
-- \`WorkflowComposer\` merges base workflows with tenant/role/device extensions.
-- Step injection utilities keep transitions intact and validate anchor steps.
-- Template helpers for common tenant review/approval, plus merge helpers for multi-scope extensions.
-
----
-
-## 2. Overlay Editor App
-
-Path: \`packages/apps/overlay-editor\`
-
-- Next.js App Router UI for toggling field visibility, renaming labels, and reordering lists.
-- Live JSON preview powered by \`defineOverlay\`.
-- Server action that signs overlays via PEM private keys (Ed25519 by default) using the overlay engine signer.
-
----
-
-## 3. Persistence
-
-Added Prisma models (see \`packages/libs/database/prisma/schema.prisma\`):
-
-- \`UserBehaviorEvent\` – field/feature/workflow telemetry.
-- \`OverlaySigningKey\` – tenant managed signing keys with revocation timestamps.
-- \`Overlay\` – stored overlays (tenant/user/role/device scope) plus signature metadata.
-
----
-
-## 4. Integration Steps
-
-1. Track usage inside apps via \`createBehaviorTracker\`.
-2. Periodically run \`BehaviorAnalyzer.analyze\` to generate insights.
-3. Convert insights into OverlaySpecs or Workflow extensions.
-4. Register tenant overlays in \`OverlayRegistry\` and serve via presentation runtimes.
-5. Compose workflows per tenant using \`WorkflowComposer\`.
-
-See the \`docs/tech/personalization/*\` guides for concrete examples.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-`}]);
+import { registerDocBlocks } from "../registry.js";
+
+//#region ../../libs/identity-rbac/dist/contracts/dist/docs/tech/PHASE_4_PERSONALIZATION_ENGINE.docblock.js
+registerDocBlocks([{
+	id: "docs.tech.PHASE_4_PERSONALIZATION_ENGINE",
+	title: "Phase 4: Personalization Engine",
+	summary: "**Status**: Complete",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/PHASE_4_PERSONALIZATION_ENGINE",
+	tags: ["tech", "PHASE_4_PERSONALIZATION_ENGINE"],
+	body: "# Phase 4: Personalization Engine\n\n**Status**: Complete  \n**Last updated**: 2025-11-21\n\nPhase 4 unlocks tenant-scoped personalization with zero bespoke code. We shipped three new libraries, a signing-aware Overlay editor, and the persistence layer required to observe usage and apply overlays safely.\n\n---\n\n## 1. Libraries\n\n### @lssm/lib.overlay-engine\n\n- OverlaySpec types + validator mirror the public spec.\n- Cryptographic signer (`ed25519`, `rsa-pss-sha256`) with canonical JSON serialization.\n- Registry that merges tenant/role/user/device overlays with predictable specificity.\n- React hooks (`useOverlay`, `useOverlayFields`) for client-side rendering.\n- Runtime engine audits every applied overlay for traceability.\n\n### @lssm/lib.personalization\n\n- Behavior tracker buffers field/feature/workflow events and exports OTel metrics.\n- Analyzer summarizes field usage and workflow drop-offs into actionable insights.\n- Adapter translates insights into overlay suggestions or workflow tweaks.\n- In-memory store implementation + interface for plugging Prisma/ClickHouse later.\n\n### @lssm/lib.workflow-composer\n\n- `WorkflowComposer` merges base workflows with tenant/role/device extensions.\n- Step injection utilities keep transitions intact and validate anchor steps.\n- Template helpers for common tenant review/approval, plus merge helpers for multi-scope extensions.\n\n---\n\n## 2. Overlay Editor App\n\nPath: `packages/apps/overlay-editor`\n\n- Next.js App Router UI for toggling field visibility, renaming labels, and reordering lists.\n- Live JSON preview powered by `defineOverlay`.\n- Server action that signs overlays via PEM private keys (Ed25519 by default) using the overlay engine signer.\n\n---\n\n## 3. Persistence\n\nAdded Prisma models (see `packages/libs/database/prisma/schema.prisma`):\n\n- `UserBehaviorEvent` – field/feature/workflow telemetry.\n- `OverlaySigningKey` – tenant managed signing keys with revocation timestamps.\n- `Overlay` – stored overlays (tenant/user/role/device scope) plus signature metadata.\n\n---\n\n## 4. Integration Steps\n\n1. Track usage inside apps via `createBehaviorTracker`.\n2. Periodically run `BehaviorAnalyzer.analyze` to generate insights.\n3. Convert insights into OverlaySpecs or Workflow extensions.\n4. Register tenant overlays in `OverlayRegistry` and serve via presentation runtimes.\n5. Compose workflows per tenant using `WorkflowComposer`.\n\nSee the `docs/tech/personalization/*` guides for concrete examples.\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
+}]);
+
+//#endregion

package/dist/libs/identity-rbac/dist/contracts/dist/docs/tech/PHASE_5_ZERO_TOUCH_OPERATIONS.docblock.js

@@ -1 +1,15 @@
-import{a as e}from"../registry.js";e([{id:`docs.tech.PHASE_5_ZERO_TOUCH_OPERATIONS`,title:`Phase 5: Zero-Touch Operations`,summary:`**Status**: In progress`,kind:`reference`,visibility:`public`,route:`/docs/tech/PHASE_5_ZERO_TOUCH_OPERATIONS`,tags:[`tech`,`PHASE_5_ZERO_TOUCH_OPERATIONS`],body:"# Phase 5: Zero-Touch Operations\n\n**Status**: In progress  \n**Last updated**: 2025-11-21\n\nPhase 5 delivers progressive delivery, SLO intelligence, cost attribution, and anomaly-driven remediation so the platform can deploy continuously without pager rotations.\n\n---\n\n## 1. New Libraries\n\n### @lssm/lib.progressive-delivery\n- `DeploymentStrategy` types capture canary vs blue-green rollouts.\n- `CanaryController` + `CanaryAnalyzer` orchestrate stage evaluation against telemetry thresholds.\n- `TrafficShifter` keeps stable/candidate splits in sync with feature-flag or router state.\n- `DeploymentCoordinator` drives stage progression, emits events, and triggers rollbacks.\n- `RollbackManager` encapsulates safe revert hooks (spec version revert, traffic shift, etc.).\n\n### @lssm/lib.slo\n- Declarative `SLODefinition` with latency + availability targets per capability/spec.\n- `SLOTracker` stores rolling snapshots + error budget positions.\n- `BurnRateCalculator` implements multi-window burn computations (fast vs slow burn).\n- `SLOMonitor` pushes incidents to Ops tooling automatically when burn exceeds thresholds.\n\n### @lssm/lib.cost-tracking\n- `CostTracker` normalizes DB/API/compute metrics into per-operation cost totals.\n- `BudgetAlertManager` raises tenant budget warnings (80% default) with contextual payloads.\n- `OptimizationRecommender` suggests batching, caching, or contract tweaks to cut spend.\n\n### Observability Anomaly Toolkit\n- `BaselineCalculator` establishes rolling intent metrics (latency, error rate, throughput).\n- `AnomalyDetector` flags spikes/drops via relative deltas after 10+ samples.\n- `RootCauseAnalyzer` correlates anomalies with recent deployments.\n- `AlertManager` deduplicates notifications and feeds MCP/SRE transports.\n\n---\n\n## 2. Data Model Additions\n\nFile: `packages/libs/database/prisma/schema.prisma`\n\n| Model | Purpose |\n| --- | --- |\n| `SLODefinition`, `SLOSnapshot`, `ErrorBudget`, `SLOIncident` | Persist definitions, rolling windows, and incidents. |\n| `OperationCost`, `TenantBudget`, `CostAlert`, `OptimizationSuggestion` | Track per-operation costs, budgets, and generated recommendations. |\n| `Deployment`, `DeploymentStage`, `RollbackEvent` | Audit progressive delivery runs and automated rollbacks. |\n| `MetricBaseline`, `AnomalyEvent` | Store computed baselines and anomaly evidence for training/analytics. |\n\nRun `bun database generate` after pulling to refresh the Prisma client.\n\n---\n\n## 3. Operational Flow\n\n1. **Deploy**: Define a `DeploymentStrategy` and feed telemetry via `@lssm/lib.observability`. Canary stages run automatically.\n2. **Protect**: `CanaryAnalyzer` evaluates error rate + latency thresholds. Failures trigger `RollbackManager`.\n3. **Observe**: `SLOMonitor` consumes snapshots and opens incidents when burn rate exceeds thresholds.\n4. **Optimize**: `CostTracker` aggregates spend per tenant + capability, while `OptimizationRecommender` surfaces fixes.\n5. **Detect**: Anomaly signals route to `RootCauseAnalyzer`, which links them to specific deployments for auto-rollback.\n\n---\n\n## 4. Integration Checklist\n\n1. Instrument adapters with `createTracingMiddleware({ onSample })` to feed metric points into `AnomalyDetector`.\n2. Register SLOs per critical operation (`billing.charge`, `knowledge.search`) and wire monitors to Ops notifications.\n3. Attach `CostTracker.recordSample` to workflow runners (DB instrumentation + external call wrappers).\n4. Store deployment metadata using the new Prisma models for auditing + UI surfacing.\n5. Update `@lssm/app.ops-console` (next iteration) to list deployments, SLO status, costs, and anomalies in one timeline.\n\n---\n\n## 5. Next Steps\n\n- Wire `DeploymentCoordinator` into the Contracts CLI so `contractspec deploy` can run staged rollouts.\n- Add UI for SLO dashboards (burn rate sparkline + incident feed).\n- Ship budget suggestions into Growth Agent for automated cost optimizations.\n- Connect `AnomalyEvent` stream to MCP agents for root-cause playbooks.\n"}]);
+import { registerDocBlocks } from "../registry.js";
+
+//#region ../../libs/identity-rbac/dist/contracts/dist/docs/tech/PHASE_5_ZERO_TOUCH_OPERATIONS.docblock.js
+registerDocBlocks([{
+	id: "docs.tech.PHASE_5_ZERO_TOUCH_OPERATIONS",
+	title: "Phase 5: Zero-Touch Operations",
+	summary: "**Status**: In progress",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/PHASE_5_ZERO_TOUCH_OPERATIONS",
+	tags: ["tech", "PHASE_5_ZERO_TOUCH_OPERATIONS"],
+	body: "# Phase 5: Zero-Touch Operations\n\n**Status**: In progress  \n**Last updated**: 2025-11-21\n\nPhase 5 delivers progressive delivery, SLO intelligence, cost attribution, and anomaly-driven remediation so the platform can deploy continuously without pager rotations.\n\n---\n\n## 1. New Libraries\n\n### @lssm/lib.progressive-delivery\n- `DeploymentStrategy` types capture canary vs blue-green rollouts.\n- `CanaryController` + `CanaryAnalyzer` orchestrate stage evaluation against telemetry thresholds.\n- `TrafficShifter` keeps stable/candidate splits in sync with feature-flag or router state.\n- `DeploymentCoordinator` drives stage progression, emits events, and triggers rollbacks.\n- `RollbackManager` encapsulates safe revert hooks (spec version revert, traffic shift, etc.).\n\n### @lssm/lib.slo\n- Declarative `SLODefinition` with latency + availability targets per capability/spec.\n- `SLOTracker` stores rolling snapshots + error budget positions.\n- `BurnRateCalculator` implements multi-window burn computations (fast vs slow burn).\n- `SLOMonitor` pushes incidents to Ops tooling automatically when burn exceeds thresholds.\n\n### @lssm/lib.cost-tracking\n- `CostTracker` normalizes DB/API/compute metrics into per-operation cost totals.\n- `BudgetAlertManager` raises tenant budget warnings (80% default) with contextual payloads.\n- `OptimizationRecommender` suggests batching, caching, or contract tweaks to cut spend.\n\n### Observability Anomaly Toolkit\n- `BaselineCalculator` establishes rolling intent metrics (latency, error rate, throughput).\n- `AnomalyDetector` flags spikes/drops via relative deltas after 10+ samples.\n- `RootCauseAnalyzer` correlates anomalies with recent deployments.\n- `AlertManager` deduplicates notifications and feeds MCP/SRE transports.\n\n---\n\n## 2. Data Model Additions\n\nFile: `packages/libs/database/prisma/schema.prisma`\n\n| Model | Purpose |\n| --- | --- |\n| `SLODefinition`, `SLOSnapshot`, `ErrorBudget`, `SLOIncident` | Persist definitions, rolling windows, and incidents. |\n| `OperationCost`, `TenantBudget`, `CostAlert`, `OptimizationSuggestion` | Track per-operation costs, budgets, and generated recommendations. |\n| `Deployment`, `DeploymentStage`, `RollbackEvent` | Audit progressive delivery runs and automated rollbacks. |\n| `MetricBaseline`, `AnomalyEvent` | Store computed baselines and anomaly evidence for training/analytics. |\n\nRun `bun database generate` after pulling to refresh the Prisma client.\n\n---\n\n## 3. Operational Flow\n\n1. **Deploy**: Define a `DeploymentStrategy` and feed telemetry via `@lssm/lib.observability`. Canary stages run automatically.\n2. **Protect**: `CanaryAnalyzer` evaluates error rate + latency thresholds. Failures trigger `RollbackManager`.\n3. **Observe**: `SLOMonitor` consumes snapshots and opens incidents when burn rate exceeds thresholds.\n4. **Optimize**: `CostTracker` aggregates spend per tenant + capability, while `OptimizationRecommender` surfaces fixes.\n5. **Detect**: Anomaly signals route to `RootCauseAnalyzer`, which links them to specific deployments for auto-rollback.\n\n---\n\n## 4. Integration Checklist\n\n1. Instrument adapters with `createTracingMiddleware({ onSample })` to feed metric points into `AnomalyDetector`.\n2. Register SLOs per critical operation (`billing.charge`, `knowledge.search`) and wire monitors to Ops notifications.\n3. Attach `CostTracker.recordSample` to workflow runners (DB instrumentation + external call wrappers).\n4. Store deployment metadata using the new Prisma models for auditing + UI surfacing.\n5. Update `@lssm/app.ops-console` (next iteration) to list deployments, SLO status, costs, and anomalies in one timeline.\n\n---\n\n## 5. Next Steps\n\n- Wire `DeploymentCoordinator` into the Contracts CLI so `contractspec deploy` can run staged rollouts.\n- Add UI for SLO dashboards (burn rate sparkline + incident feed).\n- Ship budget suggestions into Growth Agent for automated cost optimizations.\n- Connect `AnomalyEvent` stream to MCP agents for root-cause playbooks.\n"
+}]);
+
+//#endregion

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

@@ -1,4 +1,22 @@
-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)
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/identity-rbac/dist/contracts/dist/docs/tech/auth/better-auth-nextjs.docblock.js
+registerDocBlocks([{
+	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).
 
@@ -55,4 +73,7 @@ The Next.js proxy/middleware is used for **redirect decisions only**. It must no
   - \`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.
-`}]);
+`
+}]);
+
+//#endregion

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

@@ -1,4 +1,19 @@
-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
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/identity-rbac/dist/contracts/dist/docs/tech/contracts/openapi-export.docblock.js
+registerDocBlocks([{
+	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
 
@@ -35,4 +50,7 @@ The registry module must export one of:
 
 - 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.`}]);
+- Errors are not yet expanded into OpenAPI responses; that will be added when we standardize error envelopes.`
+}]);
+
+//#endregion

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

@@ -1,213 +1,15 @@
-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
-
-
-`}]);
+import { registerDocBlocks } from "../registry.js";
+
+//#region ../../libs/identity-rbac/dist/contracts/dist/docs/tech/lifecycle-stage-system.docblock.js
+registerDocBlocks([{
+	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"
+}]);
+
+//#endregion

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

@@ -1,4 +1,22 @@
-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
+import { registerDocBlocks } from "../../registry.js";
+
+//#region ../../libs/identity-rbac/dist/contracts/dist/docs/tech/llm/llm-integration.docblock.js
+registerDocBlocks([
+	{
+		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.
 
@@ -86,7 +104,21 @@ 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
+`
+	},
+	{
+		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.
 
@@ -151,7 +183,23 @@ The prompt format adapts based on task type:
 - **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
+`
+	},
+	{
+		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.
 
@@ -208,7 +256,22 @@ The generic adapter is the default and works across all agents.
 | 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
+`
+	},
+	{
+		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.
 
@@ -286,4 +349,8 @@ Each issue has:
 - **category**: type, export, import, scenario, error_handling, semantic
 - **message**: Description of the issue
 - **suggestion**: How to fix it
-`}]);
+`
+	}
+]);
+
+//#endregion

package/dist/libs/identity-rbac/dist/contracts/dist/docs/tech/mcp-endpoints.docblock.js

@@ -1 +1,36 @@
-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"}]);
+import { registerDocBlocks } from "../registry.js";
+
+//#region ../../libs/identity-rbac/dist/contracts/dist/docs/tech/mcp-endpoints.docblock.js
+registerDocBlocks([{
+	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
+
+Three dedicated MCP servers keep AI agents efficient and scoped:
+
+- **Docs MCP**: \`/api/mcp/docs\` — exposes DocBlocks as resources + presentations. Tool: \`docs.search\`.
+- **CLI MCP**: \`/api/mcp/cli\` — surfaces CLI quickstart/reference/README and suggests commands. Tool: \`cli.suggestCommand\`.
+- **Internal MCP**: \`/api/mcp/internal\` — internal routing hints, playbook, and example registry access. Tool: \`internal.describe\`.
+
+### Usage notes
+- Transports are HTTP POST (streamable HTTP); SSE is disabled.
+- Resources are namespaced (\`docs://*\`, \`cli://*\`, \`internal://*\`) and are read-only.
+- Internal MCP also exposes the examples registry via \`examples://*\` resources:
+  - \`examples://list?q=<query>\`
+  - \`examples://example/<id>\`
+- Prompts mirror each surface (navigator, usage, bootstrap) for quick agent onboarding.
+- GraphQL remains at \`/graphql\`; health at \`/health\`.
+`
+}]);
+
+//#endregion

package/dist/libs/identity-rbac/dist/contracts/dist/docs/tech/presentation-runtime.docblock.js

@@ -1 +1,15 @@
-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"}]);
+import { registerDocBlocks } from "../registry.js";
+
+//#region ../../libs/identity-rbac/dist/contracts/dist/docs/tech/presentation-runtime.docblock.js
+registerDocBlocks([{
+	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"
+}]);
+
+//#endregion