@contractspec/bundle.library 3.8.10 → 3.8.11

package/dist/node/components/docs/ops/ops-runbooks-a.docblocks.js

@@ -1,38 +1,8 @@
-// src/components/docs/ops/ops-runbooks-a.docblocks.ts
-var opsRunbookDocsA = [
-  {
-    id: "docs.ops.anomaly-detection.goal",
-    title: "Anomaly detection goal",
-    summary: "Why anomaly detection matters for ops stability.",
-    kind: "goal",
-    visibility: "public",
-    route: "/docs/ops/anomaly-detection/goal",
-    tags: ["ops", "observability"],
-    body: "Ensure anomalies are detected early to protect latency, error rate, and throughput SLAs; keep rollback hooks ready and audits reproducible."
-  },
-  {
-    id: "docs.ops.anomaly-detection.usage",
-    title: "Anomaly detection usage guide",
-    summary: "How to run and consume anomaly detection in operations.",
-    kind: "usage",
-    visibility: "public",
-    route: "/docs/ops/anomaly-detection/usage",
-    tags: ["ops", "observability"],
-    body: `- Enable tracing middleware; emit latency/error/throughput samples.
+var e=[{id:"docs.ops.anomaly-detection.goal",title:"Anomaly detection goal",summary:"Why anomaly detection matters for ops stability.",kind:"goal",visibility:"public",route:"/docs/ops/anomaly-detection/goal",tags:["ops","observability"],body:"Ensure anomalies are detected early to protect latency, error rate, and throughput SLAs; keep rollback hooks ready and audits reproducible."},{id:"docs.ops.anomaly-detection.usage",title:"Anomaly detection usage guide",summary:"How to run and consume anomaly detection in operations.",kind:"usage",visibility:"public",route:"/docs/ops/anomaly-detection/usage",tags:["ops","observability"],body:`- Enable tracing middleware; emit latency/error/throughput samples.
 - Configure thresholds per capability when bursty traffic exists.
 - Wire rollback hook in DeploymentCoordinator for error spikes.
 - Export anomaly JSON into incidents; update MetricBaseline post-fix.
-- Run chaos/load checks to validate signals within 30s.`
-  },
-  {
-    id: "docs.ops.anomaly-detection.how",
-    title: "Anomaly detection runbook",
-    summary: "Step-by-step runbook for anomaly signals and rollback hooks.",
-    kind: "how",
-    visibility: "public",
-    route: "/docs/ops/anomaly-detection/how",
-    tags: ["ops", "observability"],
-    body: `# Anomaly Detection Runbook
+- Run chaos/load checks to validate signals within 30s.`},{id:"docs.ops.anomaly-detection.how",title:"Anomaly detection runbook",summary:"Step-by-step runbook for anomaly signals and rollback hooks.",kind:"how",visibility:"public",route:"/docs/ops/anomaly-detection/how",tags:["ops","observability"],body:`# Anomaly Detection Runbook
 
 ## 1. Pipeline Overview
 1. \`createTracingMiddleware({ onSample })\` emits metric points (latency, errors, throughput).
@@ -59,65 +29,4 @@ var opsRunbookDocsA = [
 
 ## 5. Testing
 - Use load test harness to inject latency and verify detector emits signals within 30 seconds.
-- Chaos suite should simulate upstream outages to ensure throughput-drop detection fires.`
-  },
-  {
-    id: "docs.ops.cost-optimization.goal",
-    title: "Cost optimization goal",
-    summary: "Keep spend predictable and actionable for ops and finance.",
-    kind: "goal",
-    visibility: "public",
-    route: "/docs/ops/cost-optimization/goal",
-    tags: ["ops", "cost"],
-    body: "Align telemetry, budgets, and rollback levers so cost spikes are detected early, communicated clearly, and mitigated without breaking SLAs."
-  },
-  {
-    id: "docs.ops.cost-optimization.usage",
-    title: "Cost optimization usage guide",
-    summary: "Quick checklist to run cost tracking and optimization.",
-    kind: "usage",
-    visibility: "public",
-    route: "/docs/ops/cost-optimization/usage",
-    tags: ["ops", "cost"],
-    body: `- Emit \`CostSample\` via wrapped DB/HTTP clients; include provider/invoice cost.
-- Batch into \`OperationCost\` every 5m; alert at 80% of monthlyLimit.
-- Nightly run \`OptimizationRecommender.generate\`; push tickets with evidence.
-- Use regional overrides for \`defaultCostModel\` when infra prices differ.
-- Send proactive alerts for ±20% deviations to enterprise tenants.`
-  },
-  {
-    id: "docs.ops.cost-optimization.how",
-    title: "Cost optimization runbook",
-    summary: "Step-by-step cost tracking, alerting, and communication.",
-    kind: "how",
-    visibility: "public",
-    route: "/docs/ops/cost-optimization/how",
-    tags: ["ops", "cost"],
-    body: `# Cost Tracking & Optimization Runbook
-
-## 1. Instrumentation
-- Wrap DB client and HTTP adapters to emit \`CostSample\`s to \`CostTracker.recordSample\`.
-- For external APIs, attach provider name + actual invoice cost when available.
-- Persist aggregate rows into \`OperationCost\` (batch job every 5 minutes).
-
-## 2. Budgets
-- Insert/update \`TenantBudget\` per workspace.
-- Default alert threshold: 80% of \`monthlyLimit\`.
-- \`BudgetAlertManager.track(summary)\` emits Slack + email payloads including breakdown JSON.
-
-## 3. Optimization Suggestions
-- Nightly job reads \`OperationCost\` and creates \`OptimizationSuggestion\` records via \`OptimizationRecommender.generate\`.
-- Auto-file tickets or push to Growth Agent backlog with the evidence (avg reads, compute share, external spend).
-
-## 4. Forecasting
-- Cost model inputs live in \`@contractspec/lib.cost-tracking\` (\`defaultCostModel\`). Override per region if infra prices differ.
-- Keep a history of \`OperationCost\` to render spark lines in Ops Console; highlight slopes > 15% week-over-week.
-
-## 5. Customer Communication
-- For enterprise tenants offer proactive alerts when spend deviates ±20% from plan.
-- Connect \`TenantBudget\` alerts to CRM notes so Success teams see when automation saved costs.`
-  }
-];
-export {
-  opsRunbookDocsA
-};
+- Chaos suite should simulate upstream outages to ensure throughput-drop detection fires.`},{id:"docs.ops.cost-optimization.goal",title:"Cost optimization goal",summary:"Keep spend predictable and actionable for ops and finance.",kind:"goal",visibility:"public",route:"/docs/ops/cost-optimization/goal",tags:["ops","cost"],body:"Align telemetry, budgets, and rollback levers so cost spikes are detected early, communicated clearly, and mitigated without breaking SLAs."},{id:"docs.ops.cost-optimization.usage",title:"Cost optimization usage guide",summary:"Quick checklist to run cost tracking and optimization.",kind:"usage",visibility:"public",route:"/docs/ops/cost-optimization/usage",tags:["ops","cost"],body:"- Emit `CostSample` via wrapped DB/HTTP clients; include provider/invoice cost.\n- Batch into `OperationCost` every 5m; alert at 80% of monthlyLimit.\n- Nightly run `OptimizationRecommender.generate`; push tickets with evidence.\n- Use regional overrides for `defaultCostModel` when infra prices differ.\n- Send proactive alerts for ±20% deviations to enterprise tenants."},{id:"docs.ops.cost-optimization.how",title:"Cost optimization runbook",summary:"Step-by-step cost tracking, alerting, and communication.",kind:"how",visibility:"public",route:"/docs/ops/cost-optimization/how",tags:["ops","cost"],body:"# Cost Tracking & Optimization Runbook\n\n## 1. Instrumentation\n- Wrap DB client and HTTP adapters to emit `CostSample`s to `CostTracker.recordSample`.\n- For external APIs, attach provider name + actual invoice cost when available.\n- Persist aggregate rows into `OperationCost` (batch job every 5 minutes).\n\n## 2. Budgets\n- Insert/update `TenantBudget` per workspace.\n- Default alert threshold: 80% of `monthlyLimit`.\n- `BudgetAlertManager.track(summary)` emits Slack + email payloads including breakdown JSON.\n\n## 3. Optimization Suggestions\n- Nightly job reads `OperationCost` and creates `OptimizationSuggestion` records via `OptimizationRecommender.generate`.\n- Auto-file tickets or push to Growth Agent backlog with the evidence (avg reads, compute share, external spend).\n\n## 4. Forecasting\n- Cost model inputs live in `@contractspec/lib.cost-tracking` (`defaultCostModel`). Override per region if infra prices differ.\n- Keep a history of `OperationCost` to render spark lines in Ops Console; highlight slopes > 15% week-over-week.\n\n## 5. Customer Communication\n- For enterprise tenants offer proactive alerts when spend deviates ±20% from plan.\n- Connect `TenantBudget` alerts to CRM notes so Success teams see when automation saved costs."}];export{e as opsRunbookDocsA};

package/dist/node/components/docs/ops/ops-runbooks-b.docblocks.js

@@ -1,38 +1,4 @@
-// src/components/docs/ops/ops-runbooks-b.docblocks.ts
-var opsRunbookDocsB = [
-  {
-    id: "docs.ops.profile-settings.goal",
-    title: "Profile settings goal",
-    summary: "Keep identity/profile flows reliable and debuggable.",
-    kind: "goal",
-    visibility: "public",
-    route: "/docs/ops/profile-settings/goal",
-    tags: ["ops", "auth"],
-    body: "Ensure profile linking/unlinking stays stable across FC+ and SMS flows, with clear monitoring and quick recovery steps."
-  },
-  {
-    id: "docs.ops.profile-settings.usage",
-    title: "Profile settings usage guide",
-    summary: "Quick checklist for profile settings operations.",
-    kind: "usage",
-    visibility: "public",
-    route: "/docs/ops/profile-settings/usage",
-    tags: ["ops", "auth"],
-    body: `- Verify Better Auth config in \`src/lib/auth.ts\`; JWKS for FC+.
-- Monitor Sentry spans \`profile.*\`; PostHog events connection_linked/unlinked.
-- On unlink failures: check \`/api/auth/connections/unlink\` logs.
-- FC+ issues: validate discovery URL and partner redirects.
-- OTP throttling: confirm SMS service rate limiter is active.`
-  },
-  {
-    id: "docs.ops.profile-settings.how",
-    title: "Profile settings runbook",
-    summary: "Detailed runbook for profile/settings operations.",
-    kind: "how",
-    visibility: "public",
-    route: "/docs/ops/profile-settings/how",
-    tags: ["ops", "auth"],
-    body: `## Runbook – Profile Settings
+var e=[{id:"docs.ops.profile-settings.goal",title:"Profile settings goal",summary:"Keep identity/profile flows reliable and debuggable.",kind:"goal",visibility:"public",route:"/docs/ops/profile-settings/goal",tags:["ops","auth"],body:"Ensure profile linking/unlinking stays stable across FC+ and SMS flows, with clear monitoring and quick recovery steps."},{id:"docs.ops.profile-settings.usage",title:"Profile settings usage guide",summary:"Quick checklist for profile settings operations.",kind:"usage",visibility:"public",route:"/docs/ops/profile-settings/usage",tags:["ops","auth"],body:"- Verify Better Auth config in `src/lib/auth.ts`; JWKS for FC+.\n- Monitor Sentry spans `profile.*`; PostHog events connection_linked/unlinked.\n- On unlink failures: check `/api/auth/connections/unlink` logs.\n- FC+ issues: validate discovery URL and partner redirects.\n- OTP throttling: confirm SMS service rate limiter is active."},{id:"docs.ops.profile-settings.how",title:"Profile settings runbook",summary:"Detailed runbook for profile/settings operations.",kind:"how",visibility:"public",route:"/docs/ops/profile-settings/how",tags:["ops","auth"],body:`## Runbook – Profile Settings
 
 ### Feature flags / Env
 
@@ -48,41 +14,7 @@ var opsRunbookDocsB = [
 
 - Unlink failures → check \`/api/auth/connections/unlink\` logs
 - FC+ link issues → verify discovery URL and partner console redirects
-- Phone OTP rate limit → server-side limiter in SMS service`
-  },
-  {
-    id: "docs.ops.progressive-delivery.goal",
-    title: "Progressive delivery goal",
-    summary: "Roll out safely with fast rollback and clear guardrails.",
-    kind: "goal",
-    visibility: "public",
-    route: "/docs/ops/progressive-delivery/goal",
-    tags: ["ops", "delivery"],
-    body: "Use canary/blue-green with metrics guardrails so deployments can be halted or rolled back before customer impact."
-  },
-  {
-    id: "docs.ops.progressive-delivery.usage",
-    title: "Progressive delivery usage guide",
-    summary: "Quick checklist for canary/blue-green runs.",
-    kind: "usage",
-    visibility: "public",
-    route: "/docs/ops/progressive-delivery/usage",
-    tags: ["ops", "delivery"],
-    body: `- Register \`DeploymentStrategy\`; wire telemetry via observability middleware.
-- Define rollback actions (flag toggle/spec revert/infrastructure swap) in \`RollbackManager\`.
-- Use canary thresholds (err 1%, P99 500ms) or stricter per domain.
-- Pipe stage events to Ops Slack + Ops Console timeline.
-- For blue-green, run smoke tests before swap; freeze old env 24h post-swap.`
-  },
-  {
-    id: "docs.ops.progressive-delivery.how",
-    title: "Progressive delivery runbook",
-    summary: "Step-by-step for canary and blue-green rollouts.",
-    kind: "how",
-    visibility: "public",
-    route: "/docs/ops/progressive-delivery/how",
-    tags: ["ops", "delivery"],
-    body: `# Progressive Delivery Runbook
+- Phone OTP rate limit → server-side limiter in SMS service`},{id:"docs.ops.progressive-delivery.goal",title:"Progressive delivery goal",summary:"Roll out safely with fast rollback and clear guardrails.",kind:"goal",visibility:"public",route:"/docs/ops/progressive-delivery/goal",tags:["ops","delivery"],body:"Use canary/blue-green with metrics guardrails so deployments can be halted or rolled back before customer impact."},{id:"docs.ops.progressive-delivery.usage",title:"Progressive delivery usage guide",summary:"Quick checklist for canary/blue-green runs.",kind:"usage",visibility:"public",route:"/docs/ops/progressive-delivery/usage",tags:["ops","delivery"],body:"- Register `DeploymentStrategy`; wire telemetry via observability middleware.\n- Define rollback actions (flag toggle/spec revert/infrastructure swap) in `RollbackManager`.\n- Use canary thresholds (err 1%, P99 500ms) or stricter per domain.\n- Pipe stage events to Ops Slack + Ops Console timeline.\n- For blue-green, run smoke tests before swap; freeze old env 24h post-swap."},{id:"docs.ops.progressive-delivery.how",title:"Progressive delivery runbook",summary:"Step-by-step for canary and blue-green rollouts.",kind:"how",visibility:"public",route:"/docs/ops/progressive-delivery/how",tags:["ops","delivery"],body:`# Progressive Delivery Runbook
 
 **Scope**: Contracts runtime deployments running on ContractSpec infrastructure.
 
@@ -126,9 +58,4 @@ thresholds: {
 ## 5. Incident Hooks
 - \`Deployment\`, \`DeploymentStage\`, and \`RollbackEvent\` tables store the full history.
 - Tag rollbacks with incident ID to keep Ops Console synchronized.
-- Auto-resolve the incident once \`status === 'completed'\` and SLO burn rate returns < 2x.`
-  }
-];
-export {
-  opsRunbookDocsB
-};
+- Auto-resolve the incident once \`status === 'completed'\` and SLO burn rate returns < 2x.`}];export{e as opsRunbookDocsB};

package/dist/node/components/docs/ops/ops-slo-tenant.docblocks.js

@@ -1,38 +1,4 @@
-// src/components/docs/ops/ops-slo-tenant.docblocks.ts
-var opsSloTenantDocs = [
-  {
-    id: "docs.ops.slo-management.goal",
-    title: "SLO management goal",
-    summary: "Keep availability/latency SLOs observable and enforceable.",
-    kind: "goal",
-    visibility: "public",
-    route: "/docs/ops/slo-management/goal",
-    tags: ["ops", "slo"],
-    body: "Ensure every capability has a versioned SLO with alerts, burn-rate workflows, and incident cross-links so rollbacks are justified and auditable."
-  },
-  {
-    id: "docs.ops.slo-management.usage",
-    title: "SLO management usage guide",
-    summary: "Quick checklist for defining and operating SLOs.",
-    kind: "usage",
-    visibility: "public",
-    route: "/docs/ops/slo-management/usage",
-    tags: ["ops", "slo"],
-    body: `- Define \`SLODefinition\` per capability; tag tenant/tier for filtering.
-- Deploy \`SLOMonitor\`; pipe incidents to PagerDuty + Ops Slack.
-- Fast burn 14x -> page; slow burn 6x -> create ticket.
-- Use \`SLOSnapshot\` for dashboards; include deployment IDs in incidents.
-- Reset or advance error budgets after resolution when appropriate.`
-  },
-  {
-    id: "docs.ops.slo-management.how",
-    title: "SLO management runbook",
-    summary: "Detailed runbook for SLO lifecycle and incident handling.",
-    kind: "how",
-    visibility: "public",
-    route: "/docs/ops/slo-management/how",
-    tags: ["ops", "slo"],
-    body: `# SLO Management Runbook
+var e=[{id:"docs.ops.slo-management.goal",title:"SLO management goal",summary:"Keep availability/latency SLOs observable and enforceable.",kind:"goal",visibility:"public",route:"/docs/ops/slo-management/goal",tags:["ops","slo"],body:"Ensure every capability has a versioned SLO with alerts, burn-rate workflows, and incident cross-links so rollbacks are justified and auditable."},{id:"docs.ops.slo-management.usage",title:"SLO management usage guide",summary:"Quick checklist for defining and operating SLOs.",kind:"usage",visibility:"public",route:"/docs/ops/slo-management/usage",tags:["ops","slo"],body:"- Define `SLODefinition` per capability; tag tenant/tier for filtering.\n- Deploy `SLOMonitor`; pipe incidents to PagerDuty + Ops Slack.\n- Fast burn 14x -> page; slow burn 6x -> create ticket.\n- Use `SLOSnapshot` for dashboards; include deployment IDs in incidents.\n- Reset or advance error budgets after resolution when appropriate."},{id:"docs.ops.slo-management.how",title:"SLO management runbook",summary:"Detailed runbook for SLO lifecycle and incident handling.",kind:"how",visibility:"public",route:"/docs/ops/slo-management/how",tags:["ops","slo"],body:`# SLO Management Runbook
 
 ## 1. Definition Lifecycle
 1. Create an entry in \`SLODefinition\` via migration or the Ops Console.
@@ -64,41 +30,7 @@ monitor.recordWindow({ good, bad, latencyP99, latencyP95 });
 
 ## 5. Reporting
 - Weekly summary = AVG burn rate, # incidents, # auto-rollbacks triggered by SLO monitor.
-- Feed \`SLOIncident\` into Growth Agent for customer comms when SLAs impact tenants.`
-  },
-  {
-    id: "docs.ops.tenant-customization.goal",
-    title: "Tenant customization goal",
-    summary: "Let tenants customize overlays/workflows safely with audit and rollback.",
-    kind: "goal",
-    visibility: "public",
-    route: "/docs/ops/tenant-customization/goal",
-    tags: ["ops", "tenant"],
-    body: "Provide controlled overlays and workflow extensions per tenant with signed assets, versioning, and observability so UI/flow tweaks stay safe and reversible."
-  },
-  {
-    id: "docs.ops.tenant-customization.usage",
-    title: "Tenant customization usage guide",
-    summary: "Quick steps for onboarding a tenant customization.",
-    kind: "usage",
-    visibility: "public",
-    route: "/docs/ops/tenant-customization/usage",
-    tags: ["ops", "tenant"],
-    body: `- Capture fields to hide/rename and workflow deviations.
-- Build overlay in overlay editor; sign JSON with tenant key.
-- Persist in \`Overlay\` table; register via \`OverlayRegistry\` or admin API.
-- Compose \`WorkflowExtension\`; store alongside overlay metadata.
-- Run sandbox smoke tests; ensure audit logs capture overlay events.`
-  },
-  {
-    id: "docs.ops.tenant-customization.how",
-    title: "Tenant customization runbook",
-    summary: "Detailed runbook for overlays and workflow extensions.",
-    kind: "how",
-    visibility: "public",
-    route: "/docs/ops/tenant-customization/how",
-    tags: ["ops", "tenant"],
-    body: `# Tenant Customization Runbook
+- Feed \`SLOIncident\` into Growth Agent for customer comms when SLAs impact tenants.`},{id:"docs.ops.tenant-customization.goal",title:"Tenant customization goal",summary:"Let tenants customize overlays/workflows safely with audit and rollback.",kind:"goal",visibility:"public",route:"/docs/ops/tenant-customization/goal",tags:["ops","tenant"],body:"Provide controlled overlays and workflow extensions per tenant with signed assets, versioning, and observability so UI/flow tweaks stay safe and reversible."},{id:"docs.ops.tenant-customization.usage",title:"Tenant customization usage guide",summary:"Quick steps for onboarding a tenant customization.",kind:"usage",visibility:"public",route:"/docs/ops/tenant-customization/usage",tags:["ops","tenant"],body:"- Capture fields to hide/rename and workflow deviations.\n- Build overlay in overlay editor; sign JSON with tenant key.\n- Persist in `Overlay` table; register via `OverlayRegistry` or admin API.\n- Compose `WorkflowExtension`; store alongside overlay metadata.\n- Run sandbox smoke tests; ensure audit logs capture overlay events."},{id:"docs.ops.tenant-customization.how",title:"Tenant customization runbook",summary:"Detailed runbook for overlays and workflow extensions.",kind:"how",visibility:"public",route:"/docs/ops/tenant-customization/how",tags:["ops","tenant"],body:`# Tenant Customization Runbook
 
 Phase 4 introduces managed overlays and workflow extensions. Ops teams should follow this flow when onboarding a tenant that requests UI tweaks or workflow changes.
 
@@ -138,9 +70,4 @@ Managed tenants can override lifecycle playbooks without touching database schem
 4. **Event routing**
    - Subscribe to \`LifecycleKpiPipeline\` events (see \`@contractspec/bundle.lifecycle-managed\`) to forward stage changes into tenant-specific analytics.
 
-All lifecycle overrides must be versioned alongside the tenant’s overlay and workflow extensions so ops can rollback safely.`
-  }
-];
-export {
-  opsSloTenantDocs
-};
+All lifecycle overrides must be versioned alongside the tenant’s overlay and workflow extensions so ops can rollback safely.`}];export{e as opsSloTenantDocs};

package/dist/node/components/docs/ops/ops-top.docs.js

@@ -1,14 +1,4 @@
-// src/components/docs/ops/ops-top.docs.ts
-var opsTopDocs = [
-  {
-    id: "docs.ops.index",
-    title: "Operations docs index",
-    summary: "Entry point for operations runbooks and guides.",
-    kind: "goal",
-    visibility: "public",
-    route: "/docs/ops",
-    tags: ["ops"],
-    body: `# Operations
+var o=[{id:"docs.ops.index",title:"Operations docs index",summary:"Entry point for operations runbooks and guides.",kind:"goal",visibility:"public",route:"/docs/ops",tags:["ops"],body:`# Operations
 
 Browse runbooks and guides for ops workflows:
 - Anomaly detection (goal/usage/how)
@@ -17,9 +7,4 @@ Browse runbooks and guides for ops workflows:
 - Profile settings (goal/usage/how)
 - Progressive delivery (goal/usage/how)
 - SLO management (goal/usage/how)
-- Tenant customization (goal/usage/how)`
-  }
-];
-export {
-  opsTopDocs
-};
+- Tenant customization (goal/usage/how)`}];export{o as opsTopDocs};