Cambium Remediation Plan

Date: 2026-03-22

Purpose

This document translates the reality check into concrete work.

The goal is not to add aspirational scope. The goal is to make Cambium’s existing claims literally true, close the highest-risk gaps, and give the project a credible path from demo-ready to production-ready.

Guiding Principle

Prioritize truth over surface area.

That means:

• Fix broken repo guarantees before adding new subsystem breadth
• Finish durability before adding more memory-only behavior
• Enforce architectural rules instead of merely documenting them
• Tighten operational seams in Loom before expanding the UI

Remediation Goals

1. Restore clean repo verification.
2. Complete the durable-state story for critical subsystem data.
3. Eliminate hardcoded or implicit workspace scoping in API handlers.
4. Add tooling that enforces architectural claims.
5. Establish a clear production-readiness baseline for Loom and the platform.

Priority Framework

P0

The project is currently making a strong claim that is false or unverifiable.

P1

The system works, but a restart, deployment, or operational incident would expose a structural weakness.

P2

The system is usable, but confidence is limited by missing enforcement, coverage, or operational ergonomics.

P3

Valuable follow-up hardening after the major truth gaps are closed.

Workstreams

Workstream 1: Restore Verification Integrity

Priority: P0

Problem

The repo fails pnpm turbo typecheck, so the project cannot currently claim clean repo-wide TypeScript verification.

Required changes

• Fix Loom typecheck so it succeeds from a clean checkout.
• Remove or stabilize the dependency on stale .next/types artifacts.
• Make sure pnpm turbo typecheck, pnpm turbo test, and pnpm turbo build all pass in a fresh environment.

Acceptance criteria

• pnpm turbo typecheck passes from a clean checkout.
• pnpm turbo test passes from a clean checkout.
• pnpm turbo build passes from a clean checkout.
• CI runs all three commands.

Likely implementation steps

• Adjust apps/loom/tsconfig.json so generated type includes are not brittle.
• Document the correct Next.js type-generation workflow if generation must remain.
• Add CI to verify the monorepo in the same way developers are expected to verify it locally.

Workstream 2: Finish Critical Persistence

Priority: P0

Problem

Cambium states that important state should not be memory-only and that PostgreSQL backs durable state. This is not yet true across several important stores.

Required changes

• Implement PostgreSQL-backed Quorum policy storage.
• Move budget storage to PostgreSQL.
• Move audit storage to PostgreSQL with a correct schema and type model.
• Move Cortex intent storage to PostgreSQL.
• Persist lifecycle stores that represent durable system behavior.

Acceptance criteria

• No critical operational state disappears on process restart.
• Production mode in Loom does not depend on in-memory stores for governance, budgets, intents, or lifecycle state.
• Service wiring in services.ts uses PostgreSQL-backed stores for all durable concerns.

Specific deliverables

2.1 Quorum policies

• Add policies table to DB schema and migration set.
• Implement PgPolicyStore.
• Replace in-memory policy store usage in Loom services.

Relevant files:

• packages/db/src/stores/pg-policy-store.ts
• apps/loom/src/lib/services.ts

2.2 Budgets

• Add budget schema and migrations if not already complete enough.
• Implement PgBudgetStore.
• Replace InMemoryBudgetStore in service wiring.

Relevant file:

• apps/loom/src/lib/services.ts

2.3 Audit

• Decide whether audit should have a dedicated audit table or a corrected event-backed representation.
• Implement a durable PgAuditStore path that matches the AuditAction model.
• Replace in-memory audit usage in service wiring.

Relevant file:

• apps/loom/src/lib/services.ts

2.4 Cortex intents

• Resolve the store type mismatch preventing PgIntentStore usage.
• Wire Cortex intent persistence through PostgreSQL.

Relevant file:

• apps/loom/src/lib/services.ts

2.5 Lifecycle durability

• Persist cycle history.
• Persist topic state.
• Persist autonomous intents.
• Persist lifecycle compost state if it is intended to survive restarts.

Relevant file:

• apps/loom/src/lib/services.ts

Workstream 3: Fix Auth Context and Workspace Scoping

Priority: P0

Problem

The app has API authentication, but workspace context is not consistently derived from authenticated request context. Some routes still hardcode workspace values.

Required changes

• Define a single request-context contract for API routes.
• Propagate workspace_id from middleware or equivalent auth context.
• Remove hardcoded workspace defaults from route handlers where the route should be context-aware.

Acceptance criteria

• All authenticated API routes derive workspace context consistently.
• No route handling mutable or sensitive data hardcodes 'default' as an operational fallback unless explicitly intended for dev-only mode.
• Route tests cover unauthorized, wrong-workspace, and happy-path cases.

Relevant file

• apps/loom/src/app/api/runs/route.ts

Workstream 4: Enforce Architectural Claims in Tooling

Priority: P1

Problem

Several project rules are currently conventions rather than enforceable guarantees.

Required changes

• Add package-boundary enforcement.
• Add circular dependency detection.
• Add CI checks for these rules.

Acceptance criteria

• A dependency violation fails CI.
• A circular dependency fails CI.
• Internal domain layering rules are documented and machine-checked.

Candidate tools

• dependency-cruiser
• madge
• ESLint import rules if they are sufficient for the chosen boundary model

Workstream 5: Establish E2E Confidence for Loom

Priority: P1

Problem

Loom builds and has a middleware unit test, but there is no visible browser-level end-to-end coverage.

Required changes

• Add Playwright or equivalent E2E coverage for core operator flows.
• Cover at least:
• viewing workflows
• starting a run
• viewing run detail
• viewing providers
• auth middleware protection on API routes

Acceptance criteria

• A small but meaningful E2E suite runs in CI.
• Loom’s critical operator paths are validated in a running app, not only at unit level.

Workstream 6: Harden Production Mode

Priority: P1

Problem

The app can build and run, but production-mode operational assumptions are still loose.

Required changes

• Define the supported production deployment profile explicitly.
• Add startup checks for required env vars in production mode.
• Make persistence mode selection explicit and safe.
• Ensure provider health monitors and background loops behave predictably in production boot.

Acceptance criteria

• Production startup fails fast on missing required configuration.
• There is a documented and tested “supported production config.”
• The service container does not silently start in a memory-backed mode when production durability is expected.

Workstream 7: Rationalize OAuth and Auth Operations

Priority: P2

Problem

OAuth support exists, but the operational path is still easy to misconfigure and still coexists with a stub implementation.

Required changes

• Make the supported OAuth flow explicit.
• Ensure provider templates, env requirements, and callback handling form one coherent path.
• Decide whether the stub flow remains test-only or should be removed from public exports.

Acceptance criteria

• A provider with OAuth can be configured end to end using documented steps.
• Misconfiguration errors are explicit and operator-readable.
• Tests cover both success and common failure modes.

Workstream 8: Clarify V1 Scope Boundaries

Priority: P2

Problem

Some subsystems are intentionally V1-limited, but the current docs and code can blur the line between “not yet built” and “deliberately deferred.”

Required changes

• Mark intentional V1 limits clearly in docs.
• Distinguish between:
• implemented
• partial
• deferred

Current examples

• Lifecycle scanner is RSS-only in V1.
• Some auth and workspace concerns are single-workspace simplifications.

Acceptance criteria

• The docs stop overstating maturity.
• Future contributors can tell whether a gap is a bug, debt, or deliberate scope limit.

Recommended Sequence

Phase 1: Make the repo truthful

1. Fix Loom typecheck and CI verification.
2. Add Quorum policy persistence.
3. Add budget persistence.
4. Add audit persistence.

Phase 2: Make the runtime durable

1. Add Cortex intent persistence.
2. Add lifecycle persistence.
3. Remove process-memory reliance for critical production state.

Phase 3: Make the app operationally coherent

1. Thread workspace/auth context through API routes.
2. Add production-mode configuration guards.
3. Harden OAuth operations.

Phase 4: Make the claims enforceable

1. Add boundary and dependency tooling.
2. Add Loom E2E coverage.
3. Update docs to match reality.

Definition of “Production-Ready Enough”

Cambium should be considered ready for a serious production pilot when all of the following are true:

• Repo verification passes cleanly in CI and locally.
• No critical subsystem loses state on restart.
• Authenticated API routes derive workspace context consistently.
• Governance policy, budgets, intents, audit, and lifecycle state are durable.
• Boundary and dependency checks are automated.
• Loom has at least minimal end-to-end operator-flow coverage.
• Production configuration is explicit and validated at boot.

What Not To Do Yet

Until the P0 and core P1 work is done, avoid prioritizing:

• broader provider ecosystem expansion
• richer lifecycle source types beyond the current V1 scanner scope
• more Loom surface area
• new biology-themed subsystem concepts

The maturity bottleneck is not ideation. It is truth, durability, and enforcement.

Suggested Immediate Next Tasks

The next concrete execution plan should start with these items, in order:

1. Fix @cambium/loom typecheck so the monorepo verifies cleanly.
2. Implement persistent Quorum policies.
3. Implement persistent budgets.
4. Implement persistent audit storage.
5. Remove hardcoded workspace assumptions from API routes.

If these are complete, the project’s public claims become materially more trustworthy without changing its product direction.