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

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

@@ -1,155 +1,16 @@
-import { a } from "../registry.js";
+import { registerDocBlocks } from "../registry.js";
 
 //#region ../../libs/contracts/dist/docs/tech/PHASE_3_AUTO_EVOLUTION.docblock.js
-const t = [{
-	id: `docs.tech.PHASE_3_AUTO_EVOLUTION`,
-	title: `Phase 3: Auto-Evolution Technical Notes`,
-	summary: `**Status**: In progress`,
-	kind: `reference`,
-	visibility: `public`,
-	route: `/docs/tech/PHASE_3_AUTO_EVOLUTION`,
-	tags: [`tech`, `PHASE_3_AUTO_EVOLUTION`],
-	body: `# Phase 3: Auto-Evolution Technical Notes
-
-**Status**: In progress  
-**Last updated**: 2025-11-21  
-
-Phase 3 introduces self-learning capabilities that analyze production telemetry, suggest new specs, safely roll out variants, and generate golden tests from real traffic. This document captures the main building blocks delivered in this iteration.
-
----
-
-## 1. Libraries
-
-### @lssm/lib.evolution
-
-- \`SpecAnalyzer\` converts raw telemetry samples into usage stats + anomalies.
-- \`SpecGenerator\` produces \`SpecSuggestion\` objects and validates confidence thresholds.
-- \`SpecSuggestionOrchestrator\` routes proposals through the AI approval workflow and writes approved specs to \`packages/libs/contracts/src/generated\`.
-- Storage adapters:
-  - \`InMemorySpecSuggestionRepository\` for tests.
-  - \`PrismaSpecSuggestionRepository\` persists to the new Prisma model (see §4).
-  - \`FileSystemSuggestionWriter\` emits JSON envelopes for git review.
-
-### @lssm/lib.observability
-
-- Added intent detection modules:
-  - \`IntentAggregator\` batches telemetry into rolling windows.
-  - \`IntentDetector\` surfaces latency/error/throughput regressions and sequential intents.
-- \`EvolutionPipeline\` orchestrates aggregation → detection → intent events and exposes hooks for downstream orchestrators.
-- \`createTracingMiddleware\` now accepts \`resolveOperation\`/\`onSample\` hooks to feed telemetry samples into the pipeline.
-
-### @lssm/lib.growth
-
-- New \`spec-experiments\` module:
-  - \`SpecExperimentRegistry\`, \`SpecExperimentRunner\`, \`SpecExperimentAdapter\`.
-  - \`SpecExperimentAnalyzer\` + \`SpecExperimentController\` handle guardrails and staged rollouts.
-  - Helper \`createSpecVariantResolver\` plugs directly into \`HandlerCtx.specVariantResolver\`.
-- \`SpecVariantResolver\` is now a first-class concept in \`@lssm/lib.contracts\`. The runtime will attempt to execute variant specs before falling back to the registered handler.
-
-### @lssm/lib.testing
-
-- \`TrafficRecorder\` + \`TrafficStore\` capture production requests with sampling and sanitization hooks.
-- \`GoldenTestGenerator\` converts \`TrafficSnapshot\`s into Vitest/Jest suites.
-- \`generateVitestSuite\` / \`generateJestSuite\` output self-contained test files, and \`runGoldenTests\` offers a programmatic harness for CI pipelines.
-
----
-
-## 2. Telemetry → Intent → Spec Pipeline
-
-1. \`createTracingMiddleware({ onSample })\` emits \`TelemetrySample\`s for every HTTP request.
-2. \`IntentAggregator\` groups samples into statistical windows (default 15 minutes).
-3. \`IntentDetector\` raises signals for:
-   - Error spikes
-   - Latency regressions
-   - Throughput drops
-   - Sequential workflows that hint at missing specs
-4. \`EvolutionPipeline\` emits \`intent.detected\` events and hands them to \`SpecGenerator\`.
-5. \`SpecSuggestionOrchestrator\` persists suggestions, triggers approval workflows, and—upon approval—writes JSON envelopes to \`packages/.../contracts/src/generated\`.
-
----
-
-## 3. Spec Experiments & Rollouts
-
-1. Register spec experiments in \`SpecExperimentRegistry\` with control + variant bindings.
-2. Expose bucketed specs by attaching \`createSpecVariantResolver\` to \`HandlerCtx.specVariantResolver\` inside adapters.
-3. Record outcomes via \`SpecExperimentAdapter.trackOutcome()\` (latency + error metrics).
-4. \`SpecExperimentController\` uses guardrails from config and \`SpecExperimentAnalyzer\` to:
-   - Auto-rollback on error/latency breaches.
-   - Advance rollout stages (1% → 10% → 50% → 100%) when metrics stay green.
-
----
-
-## 4. Data Models (Prisma)
-
-File: \`packages/libs/database/prisma/schema.prisma\`
-
-- \`SpecSuggestion\` – stores serialized suggestion payloads + statuses.
-- \`IntentSnapshot\` – captured detector output for auditing/training.
-- \`TrafficSnapshot\` – persisted production traffic (input/output/error blobs).
-- \`SpecExperiment\` / \`SpecExperimentMetric\` – rollout state + metrics for each variant.
-
-> Run \`bun database generate\` after pulling to refresh the Prisma client.
-
----
-
-## 5. Golden Test Workflow
-
-1. Capture traffic via middleware or direct \`TrafficRecorder.record\`.
-2. Use the new CLI command to materialize suites:
-
-\`\`\`bash
-contractspec test generate \\
-  --operation billing.createInvoice \\
-  --output tests/billing.createInvoice.golden.test.ts \\
-  --runner-import ./tests/run-operation \\
-  --runner-fn runBillingCommand \\
-  --from-production \\
-  --days 7 \\
-  --sample-rate 0.05
-\`\`\`
-
-3. Generated files import your runner and assert against recorded outputs (or expected errors for negative paths).
-
----
-
-## 6. Operational Notes
-
-- **Approvals**: By default, every suggestion still requires human approval. \`EvolutionConfig.autoApproveThreshold\` can be tuned per environment but should remain conservative (<0.3) until OverlaySpec tooling lands.
-- **Sampling**: Keep \`TrafficRecorder.sampleRate\` ≤ 0.05 in production to avoid sensitive payload storage; scrub PII through the \`sanitize\` callback before persistence.
-- **Rollouts**: Guardrails default to 5% error-rate and 750ms P99 latency. Override per experiment to match SLOs.
-
----
-
-## 7. Next Steps
-
-1. Wire \`SpecExperimentAdapter.trackOutcome\` into adapters (REST, GraphQL, Workers) so every execution logs metrics automatically.
-2. Add a UI for reviewing \`SpecSuggestion\` objects alongside approval status.
-3. Expand \`TrafficRecorder\` to ship directly to the Prisma-backed store (currently in-memory by default).
-4. Integrate \`EvolutionPipeline\` events with the Regenerator to close the loop (auto-open proposals + attach evidence).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-`
+const tech_PHASE_3_AUTO_EVOLUTION_DocBlocks = [{
+	id: "docs.tech.PHASE_3_AUTO_EVOLUTION",
+	title: "Phase 3: Auto-Evolution Technical Notes",
+	summary: "**Status**: In progress",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/PHASE_3_AUTO_EVOLUTION",
+	tags: ["tech", "PHASE_3_AUTO_EVOLUTION"],
+	body: "# Phase 3: Auto-Evolution Technical Notes\n\n**Status**: In progress  \n**Last updated**: 2025-11-21  \n\nPhase 3 introduces self-learning capabilities that analyze production telemetry, suggest new specs, safely roll out variants, and generate golden tests from real traffic. This document captures the main building blocks delivered in this iteration.\n\n---\n\n## 1. Libraries\n\n### @lssm/lib.evolution\n\n- `SpecAnalyzer` converts raw telemetry samples into usage stats + anomalies.\n- `SpecGenerator` produces `SpecSuggestion` objects and validates confidence thresholds.\n- `SpecSuggestionOrchestrator` routes proposals through the AI approval workflow and writes approved specs to `packages/libs/contracts/src/generated`.\n- Storage adapters:\n  - `InMemorySpecSuggestionRepository` for tests.\n  - `PrismaSpecSuggestionRepository` persists to the new Prisma model (see §4).\n  - `FileSystemSuggestionWriter` emits JSON envelopes for git review.\n\n### @lssm/lib.observability\n\n- Added intent detection modules:\n  - `IntentAggregator` batches telemetry into rolling windows.\n  - `IntentDetector` surfaces latency/error/throughput regressions and sequential intents.\n- `EvolutionPipeline` orchestrates aggregation → detection → intent events and exposes hooks for downstream orchestrators.\n- `createTracingMiddleware` now accepts `resolveOperation`/`onSample` hooks to feed telemetry samples into the pipeline.\n\n### @lssm/lib.growth\n\n- New `spec-experiments` module:\n  - `SpecExperimentRegistry`, `SpecExperimentRunner`, `SpecExperimentAdapter`.\n  - `SpecExperimentAnalyzer` + `SpecExperimentController` handle guardrails and staged rollouts.\n  - Helper `createSpecVariantResolver` plugs directly into `HandlerCtx.specVariantResolver`.\n- `SpecVariantResolver` is now a first-class concept in `@lssm/lib.contracts`. The runtime will attempt to execute variant specs before falling back to the registered handler.\n\n### @lssm/lib.testing\n\n- `TrafficRecorder` + `TrafficStore` capture production requests with sampling and sanitization hooks.\n- `GoldenTestGenerator` converts `TrafficSnapshot`s into Vitest/Jest suites.\n- `generateVitestSuite` / `generateJestSuite` output self-contained test files, and `runGoldenTests` offers a programmatic harness for CI pipelines.\n\n---\n\n## 2. Telemetry → Intent → Spec Pipeline\n\n1. `createTracingMiddleware({ onSample })` emits `TelemetrySample`s for every HTTP request.\n2. `IntentAggregator` groups samples into statistical windows (default 15 minutes).\n3. `IntentDetector` raises signals for:\n   - Error spikes\n   - Latency regressions\n   - Throughput drops\n   - Sequential workflows that hint at missing specs\n4. `EvolutionPipeline` emits `intent.detected` events and hands them to `SpecGenerator`.\n5. `SpecSuggestionOrchestrator` persists suggestions, triggers approval workflows, and—upon approval—writes JSON envelopes to `packages/.../contracts/src/generated`.\n\n---\n\n## 3. Spec Experiments & Rollouts\n\n1. Register spec experiments in `SpecExperimentRegistry` with control + variant bindings.\n2. Expose bucketed specs by attaching `createSpecVariantResolver` to `HandlerCtx.specVariantResolver` inside adapters.\n3. Record outcomes via `SpecExperimentAdapter.trackOutcome()` (latency + error metrics).\n4. `SpecExperimentController` uses guardrails from config and `SpecExperimentAnalyzer` to:\n   - Auto-rollback on error/latency breaches.\n   - Advance rollout stages (1% → 10% → 50% → 100%) when metrics stay green.\n\n---\n\n## 4. Data Models (Prisma)\n\nFile: `packages/libs/database/prisma/schema.prisma`\n\n- `SpecSuggestion` – stores serialized suggestion payloads + statuses.\n- `IntentSnapshot` – captured detector output for auditing/training.\n- `TrafficSnapshot` – persisted production traffic (input/output/error blobs).\n- `SpecExperiment` / `SpecExperimentMetric` – rollout state + metrics for each variant.\n\n> Run `bun database generate` after pulling to refresh the Prisma client.\n\n---\n\n## 5. Golden Test Workflow\n\n1. Capture traffic via middleware or direct `TrafficRecorder.record`.\n2. Use the new CLI command to materialize suites:\n\n```bash\ncontractspec test generate \\\n  --operation billing.createInvoice \\\n  --output tests/billing.createInvoice.golden.test.ts \\\n  --runner-import ./tests/run-operation \\\n  --runner-fn runBillingCommand \\\n  --from-production \\\n  --days 7 \\\n  --sample-rate 0.05\n```\n\n3. Generated files import your runner and assert against recorded outputs (or expected errors for negative paths).\n\n---\n\n## 6. Operational Notes\n\n- **Approvals**: By default, every suggestion still requires human approval. `EvolutionConfig.autoApproveThreshold` can be tuned per environment but should remain conservative (<0.3) until OverlaySpec tooling lands.\n- **Sampling**: Keep `TrafficRecorder.sampleRate` ≤ 0.05 in production to avoid sensitive payload storage; scrub PII through the `sanitize` callback before persistence.\n- **Rollouts**: Guardrails default to 5% error-rate and 750ms P99 latency. Override per experiment to match SLOs.\n\n---\n\n## 7. Next Steps\n\n1. Wire `SpecExperimentAdapter.trackOutcome` into adapters (REST, GraphQL, Workers) so every execution logs metrics automatically.\n2. Add a UI for reviewing `SpecSuggestion` objects alongside approval status.\n3. Expand `TrafficRecorder` to ship directly to the Prisma-backed store (currently in-memory by default).\n4. Integrate `EvolutionPipeline` events with the Regenerator to close the loop (auto-open proposals + attach evidence).\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
 }];
-a(t);
+registerDocBlocks(tech_PHASE_3_AUTO_EVOLUTION_DocBlocks);
 
 //#endregion

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

@@ -1,101 +1,16 @@
-import { a } from "../registry.js";
+import { registerDocBlocks } 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-`
+const tech_PHASE_4_PERSONALIZATION_ENGINE_DocBlocks = [{
+	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"
 }];
-a(t);
+registerDocBlocks(tech_PHASE_4_PERSONALIZATION_ENGINE_DocBlocks);
 
 //#endregion

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

@@ -1,16 +1,16 @@
-import { a } from "../registry.js";
+import { registerDocBlocks } 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`],
+const tech_PHASE_5_ZERO_TOUCH_OPERATIONS_DocBlocks = [{
+	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);
+registerDocBlocks(tech_PHASE_5_ZERO_TOUCH_OPERATIONS_DocBlocks);
 
 //#endregion

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

@@ -1,20 +1,20 @@
-import { a } from "../../registry.js";
+import { registerDocBlocks } 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`,
+const tech_auth_better_auth_nextjs_DocBlocks = [{
+	id: "docs.tech.auth.better-auth-nextjs",
+	title: "Better Auth + Next.js integration (ContractSpec)",
+	summary: "How ContractSpec wires Better Auth into Next.js (server config, client singleton, and proxy cookie-only redirects).",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/auth/better-auth-nextjs",
 	tags: [
-		`auth`,
-		`better-auth`,
-		`nextjs`,
-		`cookies`,
-		`proxy`,
-		`hmr`
+		"auth",
+		"better-auth",
+		"nextjs",
+		"cookies",
+		"proxy",
+		"hmr"
 	],
 	body: `# Better Auth + Next.js integration (ContractSpec)
 
@@ -75,6 +75,6 @@ The Next.js proxy/middleware is used for **redirect decisions only**. It must no
 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);
+registerDocBlocks(tech_auth_better_auth_nextjs_DocBlocks);
 
 //#endregion

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

@@ -1,17 +1,17 @@
-import { a } from "../../registry.js";
+import { registerDocBlocks } 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`,
+const tech_contracts_openapi_export_DocBlocks = [{
+	id: "docs.tech.contracts.openapi-export",
+	title: "OpenAPI export (OpenAPI 3.1) from SpecRegistry",
+	summary: "Generate a deterministic OpenAPI document from a SpecRegistry using jsonSchemaForSpec + REST transport metadata.",
+	kind: "reference",
+	visibility: "public",
+	route: "/docs/tech/contracts/openapi-export",
 	tags: [
-		`contracts`,
-		`openapi`,
-		`rest`
+		"contracts",
+		"openapi",
+		"rest"
 	],
 	body: `## OpenAPI export (OpenAPI 3.1) from SpecRegistry
 
@@ -52,6 +52,6 @@ The registry module must export one of:
 - 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);
+registerDocBlocks(tech_contracts_openapi_export_DocBlocks);
 
 //#endregion