@lssm/example.analytics-dashboard 0.0.0-canary-20251217060834 → 0.0.0-canary-20251217063201

package/dist/libs/contracts/dist/docs/tech/PHASE_4_PERSONALIZATION_ENGINE.docblock.js

@@ -0,0 +1,101 @@
+import { a } from "../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/PHASE_4_PERSONALIZATION_ENGINE.docblock.js
+const t = [{
+	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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+`
+}];
+a(t);
+
+//#endregion

package/dist/libs/contracts/dist/docs/tech/PHASE_5_ZERO_TOUCH_OPERATIONS.docblock.js

@@ -0,0 +1,16 @@
+import { a } from "../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/PHASE_5_ZERO_TOUCH_OPERATIONS.docblock.js
+const t = [{
+	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"
+}];
+a(t);
+
+//#endregion

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

@@ -0,0 +1,80 @@
+import { a } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/auth/better-auth-nextjs.docblock.js
+const t = [{
+	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.
+`
+}];
+a(t);
+
+//#endregion

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

@@ -0,0 +1,57 @@
+import { a } from "../../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/contracts/openapi-export.docblock.js
+const t = [{
+	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.`
+}];
+a(t);
+
+//#endregion

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

@@ -0,0 +1,228 @@
+import { a } from "../registry.js";
+
+//#region ../../libs/contracts/dist/docs/tech/lifecycle-stage-system.docblock.js
+const t = [{
+	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
+
+
+`
+}];
+a(t);
+
+//#endregion