CMPSBL ® · The Collective Master Library

# Integration Report — Cal.com

What the library changes for this repository: the capabilities it gains, the evidence behind each one, the cost, and a staged roadmap.

Host
github.com/calcom/cal.com
Commit
176037d0
Host licence
MIT (ee/ commercial dir)
Library
v3.2.0 · kit r3.2.0
Generated
August 15, 2026
In 60 seconds

## What Cal.com gains

New capability first. Governed wrapping is one item in this library, not its headline — these are the things that change how the software behaves in production.

5,025
host TS/TSX files
0
circuit breakers in host
1
unretried webhook fetch
8
components recommended

### Rate limiting that cannot fail open

The host limiter returns success:true whenever the Unkey key is absent, errors, or exceeds its 5s timeout. A local token bucket runs underneath as the floor, so a vendor outage degrades throughput instead of removing the limit.

STIER-S-ACC02 + STIER-S-133 packages/lib/rateLimit.ts:32-56 2–3 days

### Webhook delivery that survives a subscriber outage

Subscriber delivery is one bare fetch with no timeout, retry or dead-letter path. A reliability engine adds bounded retry, idempotency keys and a DLQ so an hour of subscriber downtime stops dropping bookings.

STIER-S-114 + STIER-S-RLY04 webhooks/lib/sendPayload.ts:312 6–9 days

### A breaker in front of 153 third-party integrations

There is no circuit-breaker construct anywhere in the repository. A 3-state breaker with jittered backoff isolates a degraded calendar or video provider instead of the queue.

STIER-S-117 + BLD-ENG-011 packages/app-store/** (153) 4–6 days

### Retry with backoff instead of a fixed interval

Task.retry reschedules at a flat interval — a synchronised retry storm under provider outage. Exponential backoff plus jitter is a 30-line change.

BLD-ENG-011 tasker/repository.ts:110-137 1 day

### Tamper-evident audit for booking decisions

Audit today is application logging. A hash-chained ledger makes booking, payment and no-show decisions replayable and provably unaltered.

STIER-S-71 + STIER-S-CJ94 packages/features/audit-logs/** 5–8 days
Verdict
Buy — the single licence, scoped to the resilience seam
Net value US$34k–68k in year one against US$499 USD.

Step 0

## Licence conflict check

Run before any file was read for integration purposes. No CMPSBL file was copied, installed or wired into this repository — this is a pre-purchase evaluation.

Host licence (SPDX) | MIT (with a separately licensed `packages/features/ee` commercial directory)
Where it was found | `LICENSE` — "MIT License, Copyright (c) 2020-present Cal.com, Inc."
Will the host ship its own source under the perpetual licence? | Not asked and not assumed. Cal.com publishes under MIT and sells a commercial edition, so the answer is almost certainly no.
Door that applies | the single licence — CMPSBL(R) Perpetual Edition License 1.0. the single licence remains available but is impractical here.
Verdict | OK with care. MIT and perpetual licence may be combined, but under the single licence the combined work must be distributed under the perpetual licence — including for network use. A company selling a proprietary edition will not do that, which routes this host to the single licence.
Clause that drove it | LicenseRef-CMPSBL-Perpetual-1.0 §13 (network use) as applied to the combined work; the the single licence alternative removes the source-release obligation.
Scope limits imposed | Under the single licence no component may be sold, sublicensed or published as a product in its own right — renamed, refactored, translated or API-wrapped. Embedding inside Cal.com, which has substantial independent function, is permitted in any distribution shape including npm packages. The test is substance, not packaging. Attribution naming Kenneth E. Sweet Jr. and the components used goes in the host README or third-party notices.

Sub-package note: the 13 `@cmpsbl/*` package artifacts carry Apache-2.0 and are outside both doors. If a component were ever needed inside a package the host intends to keep permissive, only those 13 qualify.

Verdict

## Buy, at the commercial tier, for the resilience seam

Buy — scoped

Eight components, four designs, one seam that is genuinely broken today.

Cal.com is a mature codebase with good structure and one consistent weakness: every failure path is optimistic. The rate limiter fails open, the retry is flat, the webhook fetch is single-shot and unbounded, and 153 third-party integrations call out with no isolation. The library closes all four with components that are `C:ok I:ok` and strict-clean — which matters, because this monorepo compiles with `strict: true`. What it does not do is improve the product's core: nothing in the catalog makes scheduling better, and the 6,479-row Discovery Vault contributes nothing here at all.

- Net value (range): US$34k–68k against US$499 USD
- Break-even: Roughly the first two designs
- Highest-leverage item: Design #1 — the limiter floor
- Strongest argument against: Every component records testCoverage: Not claimed, and a team this size can write a breaker in a week

Step 5 — the highest-value part of this report

## New component designs

Each is buildable from named catalog IDs plus named host files. None exists in the catalog as shipped, and none exists in the host.

### Design 1 — Fail-Closed Limiter Sandwich

A two-tier limiter where the host keeps Unkey as the distributed authority and gains a local token bucket that is consulted when Unkey is unavailable — turning a fail-open vendor dependency into graceful degradation.

Built from | STIER-S-ACC02 (`createLimiter`, `tryConsume`, `adaptLimit`)
Plus host | `packages/lib/rateLimit.ts, packages/lib/checkRateLimitAndThrowError.ts`
New because | The catalog component is a limiter; the host has a limiter. What does not exist in either is the fallback contract: which limit applies when the authority is silent, and how the local bucket reconciles when it returns.
Unlocks | Removes the current single point of failure on every auth, SMS and API-key path in one seam.
Evidence path | `packages/lib/rateLimit.ts:32-56 (three separate fail-open returns)`
Effort | 2–3 days, basis: 58 entry LOC plus 3 correctness concerns (clock skew, reconciliation, namespace parity with the 8 Unkey namespaces).
Constraints | STIER-S-ACC02 — `C:ok I:ok B:exec T:— S:scan`. Test coverage: Not claimed. Independent security review: Not claimed. Mode `direct`, no governed-runtime slices, adapter ports `none`. In-process state only: per-instance buckets, which is the point of the fallback but must be sized per pod.
Confidence | High — the fail-open behaviour is explicit in host source, not inferred.

    request
      │
      ├─► Unkey (authority)  ──ok──►  allow / 429
      │        │
      │     error │ timeout │ no key
      │        ▼
      └─► STIER-S-ACC02 local bucket ──►  allow / 429  (degraded, logged)

### Design 2 — Subscriber-Aware Webhook Fabric

Webhook delivery with bounded retry, idempotency keys, per-subscriber circuit breaking and a dead-letter store that is analysed rather than merely written.

Built from | STIER-S-114 (`WebhookReliabilityEngine`, `DeliveryAttempt`) + STIER-S-117 (`createBreaker`, `canExecute`) + STIER-S-RLY04 (`DeadLetterIntelligenceEngine`)
Plus host | `packages/features/webhooks/lib/sendPayload.ts, packages/features/webhooks/lib/tasker/**, packages/features/tasker/repository.ts`
New because | Retry engines and breakers exist separately everywhere. Keying the breaker on subscriber URL and feeding its trips into dead-letter analysis produces something the host can act on: 'this customer's endpoint has been failing for 40 minutes' rather than 'a webhook failed'.
Unlocks | A supportable answer to the most common enterprise webhook complaint, and the data to email the customer before they open a ticket.
Evidence path | `packages/features/webhooks/lib/sendPayload.ts:312 (single fetch, no timeout); zero dead-letter matches repo-wide`
Effort | 6–9 days, basis: 198 + 91 + 107 entry LOC and 5 correctness concerns (idempotency, ordering, breaker keying, DLQ persistence, replay).
Constraints | STIER-S-114 `C:ok I:ok B:load T:— S:scan`; STIER-S-117 `C:ok I:ok B:exec T:— S:scan`; STIER-S-RLY04 `C:ok I:ok B:load T:— S:scan`. All three: test coverage Not claimed, independent security review Not claimed. Mode `direct`, adapter ports `none`. Two caveats: `WebhookStore` is an in-memory default and must be backed by the existing Prisma task table before production; STIER-S-RLY04 ships a shared entry (its 107-LOC entry also exports provenance and cascade symbols) — import the engine, do not adopt the file wholesale.
Confidence | Medium-high — delivery gap is proven; effort depends on how much of the tasker webhook path is reused versus replaced.

    trigger ─► WebhookService ─► ReliabilityEngine
                                  │
                     ┌────────────┼─────────────┐
                     ▼            ▼             ▼
            breaker(subscriber)  retry ladder  idempotency key
                     │            │
                  open│           └── exhausted ──► DLQ ─► RLY04 analysis
                     ▼                                     │
            skip + schedule probe   ◄─────────────────────┘

### Design 3 — Provider Health Fabric for the App Store

One breaker-and-quota layer shared by all 153 integration packages, exposing a per-provider health surface instead of per-package ad-hoc error handling.

Built from | STIER-S-117 (`getAllBreakers`, `recordFailure`) + STIER-S-133 (`ExternalAPIRateLimiter`) + BLD-ENG-011 (`createBreakerPanel`)
Plus host | `packages/app-store/_utils/**, packages/app-store/googlecalendar/lib/CalendarService.ts`
New because | The host treats each integration as an isolated package. A single fabric that knows Google is degraded lets booking-time availability logic route around it — a product behaviour, not just a resilience utility.
Unlocks | Status-page-grade provider health for free, and the option to hide or degrade a provider in the booker rather than fail a booking.
Evidence path | `153 packages under packages/app-store; googlecalendar/lib/CalendarService.ts is 914 lines with no AbortSignal or timeout`
Effort | 8–12 days for the fabric plus the first five providers, basis: 91 + 123 + 169 entry LOC and 4 concerns (per-tenant credential keying, quota accounting, half-open probes, availability fallback).
Constraints | STIER-S-117 `C:ok I:ok B:exec T:— S:scan`; STIER-S-133 `C:ok I:ok B:load T:— S:scan`; BLD-ENG-011 `C:ok I:ok B:load T:— S:scan`. Test coverage Not claimed, independent security review Not claimed on all three. STIER-S-133 is marked a twin of BLD-ENG-109 — take one, not both. Breaker state is per-process; multi-pod deployments need the trip signal shared or accept per-pod convergence.
Confidence | Medium — the gap is certain, the blast radius is 153 packages, and rollout discipline dominates the estimate.

    booker / availability
            │
            ▼
    provider fabric ── breaker(provider,tenant) ── quota(STIER-S-133)
            │                    │
            ├── healthy ─────────┴──► CalendarService call
            └── open ───────────────► degrade: hide slot, queue sync

### Design 4 — Replayable Booking Decision Ledger

A hash-chained record of the decisions behind each booking — which slots were offered, which rule rejected an attempt, which payment or no-show action fired — verifiable after the fact.

Built from | STIER-S-71 (`createAuditChain`) + STIER-S-CJ94 (`AuditGradeDecisionLedger`)
Plus host | `packages/features/audit-logs/**, packages/features/bookings/lib/handleNewBooking/**`
New because | Cal.com logs events. It does not record why a slot was unavailable, and cannot prove the record is unaltered. That combination is what enterprise procurement and dispute resolution actually ask for.
Unlocks | A concrete answer in security questionnaires, and support's ability to reconstruct a disputed booking instead of guessing.
Evidence path | `failure paths land in console.info (task-processor.ts:12-38); no hash chain in the repository`
Effort | 5–7 days for the chain plus booking-path instrumentation, basis: 68 + 73 entry LOC and 3 concerns (chain persistence, retention, PII in decision payloads).
Constraints | STIER-S-71 `C:ok I:ok B:exec T:— S:scan`; STIER-S-CJ94 `C:ok I:ok B:load T:— S:scan`. Test coverage Not claimed, independent security review Not claimed. Both are twins of BLD-ENG entries (BLD-ENG-009, BLD-ENG-136) — adopt one of each pair. A tamper-evident chain is a detection mechanism, not a compliance certification; do not market it as one.
Confidence | Medium — value is commercial rather than technical, and depends on whether enterprise deals are actually being lost on this.

    booking attempt ─► decision points ─► LedgerEntry
                                            │
                                createAuditChain (hash-linked)
                                            │
                         verify(range) ─────┴──► tamper report / replay

Build this one first: Design #1. It is the smallest, it fixes a defect that is live in production today, and it must precede the breaker work — a breaker in front of an unlimited request rate is theatre.

Scoreboard

## What was measured

Measure | Value | Basis
--- | --- | ---
Host files inspected | 5,025 | TS/TSX under packages/ and apps/, node_modules excluded
Catalog rows screened | 1,116 | engineered components in CATALOG-PHASE-3-COMPONENTS.md
Discovery Vault rows screened | 6,479 | DISCOVERY-VAULT-INDEX.md; 0 recommended, see Do not touch
Components recommended | 8 | after twin de-duplication
New component designs | 4 | Step 5, each built from named catalog IDs plus named host files
Confirmed host gaps | 6 | each with a file-and-line citation
Components with test-coverage claims | 0 | every row records testCoverage: Not claimed
Components with independent security review | 0 | the delivery makes no such claim
Recommended components clean on the strict pass | 8 of 8 | all recommendations are C:ok; the host compiles with strict: true

Step 1

## What this repository already has

Inventory of the units the recommendations touch. LOC is the file's own line count; `—` means the unit is a directory rather than a file.

Unit | Path | Exported surface | LOC | Job
--- | --- | --- | --- | ---
Rate limiter | `packages/lib/rateLimit.ts` | rateLimiter, RateLimitHelper, API_KEY_RATE_LIMIT | 134 | Wraps @unkey/ratelimit. Eight named namespaces (core, api, sms, ai…). Returns a permissive stub when UNKEY_ROOT_KEY is unset, on error, and on 5s timeout.
Limiter call site | `packages/lib/checkRateLimitAndThrowError.ts` | checkRateLimitAndThrowError | 23 | Throws HttpError 429 when the limiter reports failure. Used by auth, verification codes and API keys.
Task queue façade | `packages/features/tasker/tasker.ts` | Tasker interface | 41 | create / cleanup contract implemented by the internal and Redis taskers.
Task processor | `packages/features/tasker/task-processor.ts` | TaskProcessor.processQueue | 42 | Pulls a batch, dispatches handlers, calls Task.succeed or Task.retry. Errors are logged with console.info.
Task repository | `packages/features/tasker/repository.ts` | Task.create, Task.retry, Task.succeed, Task.getNextBatch | 200 | Persists attempts, maxAttempts, lastError, lastFailedAttemptAt. Retry reschedules at a flat minRetryIntervalMins when configured.
Webhook delivery | `packages/features/webhooks/lib/sendPayload.ts` | sendPayload, sendGenericWebhookPayload | 330 | Signs the payload and performs a single fetch to the subscriber URL (line 312). No timeout, no retry, no dead-letter path.
Webhook service | `packages/features/webhooks/lib/WebhookService.ts` | WebhookService | 41 | Resolves subscribers and hands payloads to the delivery path.
Third-party integrations | `packages/app-store/**` | 153 integration packages | — | Calendar, video and payment providers. Example: googlecalendar/lib/CalendarService.ts, 914 lines, no AbortSignal or timeout on outbound calls.
Compiler settings | `packages/tsconfig/base.json` | — | — | strict: true across the monorepo. Anything installed must be strict-clean.

Step 2

## Five-axis screen of the candidate set

Every candidate that reached the shortlist, plus the one whole corpus that was rejected. A silently dropped candidate is a defect, so the Discovery Vault appears here with its reason.

Component | 1 · Direct fit | 2 · Combinatorial fit | 3 · Revenue / retention | 4 · Cost and risk | 5 · Novelty
--- | --- | --- | --- | --- | ---
`STIER-S-ACC02` Adaptive Rate Limiting Engine | Direct — the host limiter fails open in three distinct code paths. | With STIER-S-133 and the Unkey namespaces: one limit model covering inbound abuse and outbound provider quota. | Retention/trust: an auth endpoint that stops limiting during a vendor outage is an incident waiting to be written up. | Low cost, low risk. Competes with a trusted system only if it replaces Unkey — it must not. | Novel — the team almost certainly knows Unkey can fail; the fallback contract is the part nobody schedules.
`STIER-S-114` Webhook Reliability Engine | Direct — replaces a single-shot fetch. | With STIER-S-117 and STIER-S-RLY04 → Design #2. | Revenue-adjacent: webhook reliability is a recurring enterprise objection and a support-cost line. | Medium cost. Public-facing path — outbound signing and idempotency need review. | Not novel. Any senior engineer would propose it; it has simply not been funded.
`STIER-S-117` Circuit Breaker Fabric | Direct — nothing of the kind exists in the repo. | With STIER-S-133 → provider health fabric (Design #3). | Product value: enables degrading a provider in the booker instead of failing a booking. | Medium. Per-process state; multi-pod convergence must be accepted or shared. | Not novel as a pattern. The per-tenant, per-provider keying is.
`BLD-ENG-011` Circuit Breaker (3-state, backoff + jitter) | Direct — supplies the retry policy the tasker lacks. | Its backoff policy is usable on its own against Task.retry, without adopting the breaker. | Reduces retry storms during provider incidents; cheapest measurable win in the report. | Very low. Marked twin of STIER-EXTRA-02 — adopt one. | Not novel.
`STIER-S-133` External API Rate Limiter | Direct — 153 integrations call third-party APIs with no quota accounting. | Feeds Design #3 alongside the breaker. | Avoids provider-side bans, which present to users as broken calendars. | Medium. Twin of BLD-ENG-109 — adopt one. | Novel — predictive throttling ahead of a provider's own limit is not how most teams handle this.
`STIER-S-RLY04` Dead Letter Intelligence Engine | Direct — the host has no dead-letter concept at all. | Only valuable once a DLQ exists; pairs with STIER-S-114. | Turns failures into a customer-facing signal rather than a log line. | Low, but shared entry: its file also exports provenance and cascade symbols. Import the engine only. | Novel — analysing the DLQ, rather than draining it, is a step most teams skip.
`STIER-S-71` Tamper-Evident Chain | Direct for audit; the host has logs, not a chain. | With STIER-S-CJ94 → Design #4. | Commercial: procurement and dispute resolution. | Low technical risk; retention and PII policy is the real work. Twin of BLD-ENG-009. | Not novel, but rarely built before a deal demands it.
`STIER-S-CJ94` Audit-Grade Decision Ledger | Direct — records the reasoning, not just the event. | Design #4 with STIER-S-71. | Same commercial lane; also shortens support investigations. | Low. Twin of BLD-ENG-136. | Novel — logging why a slot was withheld is not something scheduling products normally keep.
`Discovery Vault (6,479 rows)` — | Screened by capability keyword against the host's domain. | None found that combine usefully with a scheduling product. | Zero. | Zero — but screening it took real time and the result is a genuine negative. | Rejected in full. The vault is organised around CMPSBL's own primitive pairs; the fit here is near zero and inventing one would be a defect.

Step 3

## Constraints this host imposes

Verification strings quoted verbatim from the catalog rows. Expanded against the legend: `C:ok` = compiles under batch `tsgo --strict --noEmit`; `I:ok` = installed into an empty host and type-checked there; `B:exec` = zero-arity exports executed twice and compared structurally; `B:load` = entry point imports cleanly and exposes exports, with no zero-arity surface to execute without fabricated input; `T:—` = Not claimed; `S:scan` = the author's own 13-rule static unsafe-construct sweep recorded clean.

Component | Verified (verbatim) | Entry LOC | Symbols used
--- | --- | --- | ---
`STIER-S-ACC02` Adaptive Rate Limiting Engine | C:ok I:ok B:exec T:— S:scan | 58 | RateLimiter, createLimiter, tryConsume, adaptLimit, getLimiter, listLimiters
`STIER-S-114` Webhook Reliability Engine | C:ok I:ok B:load T:— S:scan | 198 | WebhookEvent, DeliveryAttempt, WebhookConfig, WebhookStore, DeliveryDisposition, WebhookReliabilityEngine
`STIER-S-117` Circuit Breaker Fabric | C:ok I:ok B:exec T:— S:scan | 91 | BreakerState, CircuitBreaker, createBreaker, recordSuccess, recordFailure, canExecute, getBreaker, getAllBreakers, resetBreaker
`BLD-ENG-011` Circuit Breaker (backoff + jitter) | C:ok I:ok B:load T:— S:scan | 169 | CircuitState, CircuitBreakerConfig, CircuitStats, createCircuitBreaker, createBreakerPanel
`STIER-S-133` External API Rate Limiter | C:ok I:ok B:load T:— S:scan | 123 | RateLimitConfig, RateLimitResult, ExternalAPIRateLimiter
`STIER-S-RLY04` Dead Letter Intelligence Engine | C:ok I:ok B:load T:— S:scan | 107 | DeadLetterIntelligenceEngine (shared entry — see constraints)
`STIER-S-71` Tamper-Evident Chain | C:ok I:ok B:exec T:— S:scan | 68 | createAuditChain
`STIER-S-CJ94` Audit-Grade Decision Ledger | C:ok I:ok B:load T:— S:scan | 73 | LedgerEntry, AuditGradeDecisionLedger

Every recommended component records test coverage: Not claimed and independent third-party security review: Not claimed. Those are the manifest's words, not a euphemism: the claim was not made and no such verification was run. `S:scan` is the author's own machine sweep.

Mode, slices and adapter ports. All eight are mode `direct`: none has `requiresGovernedRuntime`, so no runtime slices ship with them, and every one records adapter ports `none`. That is the low-friction case — but it also means no persistence is provided. `STIER-S-114`'s `WebhookStore` and `STIER-S-CJ94`'s ledger both default to in-process state and must be backed by the host's existing Prisma tables before production. Breaker state in `STIER-S-117` and `BLD-ENG-011` is per-process; on a multi-pod deployment each pod converges independently.

Twins. Five of the eight are marked twins of a second catalog entry (`STIER-S-117`/`BLD-ENG-047`, `BLD-ENG-011`/`STIER-EXTRA-02`, `STIER-S-133`/`BLD-ENG-109`, `STIER-S-71`/`BLD-ENG-009`, `STIER-S-CJ94`/`BLD-ENG-136`). Adopt one of each pair. `STIER-S-RLY04` ships a shared entry file that also exports provenance and cascade symbols — import the engine, not the file.

Host constraint that binds. `packages/tsconfig/base.json` sets `strict: true`. All eight recommendations are `C:ok`, so none carries the strict-mode cleanup budget that a `C:proj(n)` row would. That was a selection criterion, not luck: 144 of the library's 1,116 components record `C:proj(n)` and were excluded from consideration for this host on that basis.

Step 4

## Top-ranked enhancements

Ranked by expected value to this product, not by catalog prestige.

# | Enhancement | Catalog IDs | Symbols | Combined value | Effort | Why here specifically
--- | --- | --- | --- | --- | --- | ---
1 | Limiter floor beneath Unkey | `STIER-S-ACC02` | createLimiter, tryConsume, adaptLimit | Removes a live fail-open on every auth, SMS and API-key path. | 2–3 days | `packages/lib/rateLimit.ts:32-56` returns `success:true` with no key, on error, and on timeout.
2 | Webhook retry + DLQ | `STIER-S-114, STIER-S-RLY04` | WebhookReliabilityEngine, DeliveryAttempt | Stops silent loss when a subscriber is down; produces a supportable signal. | 6–9 days | `sendPayload.ts:312` is a single unretried, untimed fetch.
3 | Backoff + jitter in Task.retry | `BLD-ENG-011` | createCircuitBreaker (policy) | Cheapest measurable change in the report; ends synchronised retry storms. | ½ day | `tasker/repository.ts:110-137` reschedules at a constant interval.
4 | Breaker on the top five providers | `STIER-S-117` | createBreaker, canExecute, recordFailure | Isolates a degraded provider instead of saturating workers. | 3–4 days for five | No circuit-breaker construct exists in `packages/app-store/**` (153 packages).
5 | Outbound quota accounting | `STIER-S-133` | ExternalAPIRateLimiter | Prevents provider-side bans that surface to users as broken calendars. | 3–5 days | `googlecalendar/lib/CalendarService.ts`, 914 lines, no timeout or quota tracking.
6 | Booking decision ledger | `STIER-S-71, STIER-S-CJ94` | createAuditChain, AuditGradeDecisionLedger | Commercial lane: procurement answers and dispute reconstruction. | 5–7 days | Failures land in `console.info`; no verifiable record exists.

### Gap map

Gap | Evidence in the host | What addresses it
--- | --- | ---
Rate limiting fails open on vendor failure | packages/lib/rateLimit.ts:32-56 — no key, any error, or a 5s timeout all return {success:true, remaining:999}. | STIER-S-ACC02 as a local floor beneath Unkey; STIER-S-133 for outbound provider quotas.
No circuit breaker anywhere | Zero matches for circuit-breaker constructs across packages/ and apps/. 153 integrations call out with no isolation. | STIER-S-117 (fabric, half-open probing) or BLD-ENG-011 (3-state + jitter).
Retry has no backoff and no jitter | packages/features/tasker/repository.ts:110-137 — attempts increment, scheduledAt advances by a constant. | BLD-ENG-011's backoff and jitter policy applied to Task.retry.
Webhook delivery is single-shot | packages/features/webhooks/lib/sendPayload.ts:312 — one fetch, no timeout, no retry ladder. | STIER-S-114 with idempotency keys and bounded retry.
No dead-letter concept | Zero dead-letter matches in the repository; exhausted tasks simply stop. | STIER-S-RLY04 over the failed-task table.
Audit is logging, not a ledger | Delivery and task failures land in console.info; no hash chain, no replay. | STIER-S-71 plus STIER-S-CJ94 on booking/payment decisions.

### Do not touch

Catalog area | Reason
--- | ---
Anything that replaces Unkey outright | Unkey is a deliberate, funded dependency with distributed state. Put the catalog limiter underneath it as a floor; ripping it out trades a working system for a local one.
Catalog persistence, cache or ORM components | Prisma plus the repository pattern is load-bearing across 5,025 files. Nothing in the catalog improves on it, and the seam is not cheap.
Governed-runtime layer artifacts (VerticalLayerPack) | Layer-class artifacts are not attachable by import; they only take effect when the governed-runtime wrapper emits a wrapped Layer 2 file. Wiring one as a module here would be reported as integration that did not happen.
Any of the 6,479 Discovery Vault entries | The vault is organised around CMPSBL's own primitive pairs (BASTION↔TEMPEST, RUBRIC→QUIZMASTER). Screened against a scheduling product it lands near zero. Say so rather than manufacture a fit.
Auth, session or credential components | next-auth plus the host's own credential store is a reviewed path. Touching it buys risk, not capability.

### Quick wins

Win | Source | Effort | Why it is safe
--- | --- | --- | ---
Backoff + jitter in Task.retry | `BLD-ENG-011` | ≈½ day | Pure policy change inside one repository method. No new dependency, no schema change.
Timeout + AbortSignal on webhook fetch | `STIER-S-114 (timeout policy only)` | ≈½ day | One call site. Removes the unbounded-hang class outright, before any retry work.
Breaker around the Google Calendar service | `STIER-S-117` | 1 day | Single provider first, measured, before touching the other 152.

### Honest totals

Feasible here: 8 components across 4 designs. Producing a measurable change — something that shows up in an incident count, a support queue or a procurement answer: 3 (limiter floor, webhook fabric, retry backoff). Would actually fund, at this repository's apparent capacity: 2 — Designs #1 and #2, plus the half-day quick wins that sit inside them. Basis: the resilience seam is one team's surface area, the provider fabric touches 153 packages and needs its own quarter, and the ledger is a commercial bet that should wait for a deal that asks for it.

The honest negative: nothing in this library improves scheduling. If the question is "does this make Cal.com a better booking product", the answer is no. It makes it a more survivable one.

Step 6

## Time and cost, build versus buy

Assumptions: one senior engineer, US$115/hr fully loaded (US-market contractor rate for a senior TypeScript platform engineer, chosen because that is who would do this work), 6 productive hours per day. Ranges err low on (A) and high on (B), because avoided work is observable and counterfactual work is not.

Bucket | Contents | Estimate
--- | --- | ---
(A) Cost avoided — hard | Work already inevitable: webhook retry and DLQ, retry backoff, timeouts on outbound calls. Basis: 198 + 169 entry LOC and 8 distinct correctness concerns, not line count. | US$14k–24k
(B) Capability acquisition — counterfactual | The fail-closed limiter sandwich, DLQ analysis rather than drainage, predictive outbound quota throttling, and the decision ledger. These are the items the team would not have scheduled. | US$20k–44k
(C) Portfolio carry-over — conditional | Identified siblings in the same monorepo and org: the public API service (`apps/api`), the platform/atoms SDK, and the embed distribution. Components that carry over unchanged: `STIER-S-ACC02`, `STIER-S-117`, `STIER-S-133`. Re-implementation each would otherwise need: ≈US$6k–9k per repo × 3 repos. Marginal licence cost per additional repo: US$0 — the single licence is billed per company per year, not per repository or per seat. | US$18k–27k (conditional)
Minus integration cost | Wiring, Prisma-backing the two in-memory stores, review of the webhook signing path, multi-pod breaker semantics, and time to learn the library: ≈18–24 engineer-days. | −US$12k–17k
Net against licence | the single licence at the 51–250 headcount tier: US$499 USD. the single licence is US$0 in fees but requires the combined work — including the MIT-licensed host — to ship under the perpetual licence, which is not a cost this company would accept at any price. | US$34k–68k net, year one

Durable version: the patterns and reference implementations remain usable after any single product dies, and amortised across three codebases the annual price is roughly US$7.6k per codebase.

What they would never have arrived at. Three items in (B): a limiter whose failure mode is closed rather than open; dead-letter intelligence instead of a dead-letter queue; and a decision ledger that records why a slot was withheld. The first is a correction of a live defect nobody has noticed. The second and third change what the product can be sold as — a scheduling platform that can explain and prove its own behaviour is a different procurement conversation from one that cannot.

At US$499 USD, is this a good trade? Yes, narrowly, and only if the resilience work is actually on the roadmap. The case against is real: every component records testCoverage: Not claimed and no independent security review, the team is capable of writing a circuit breaker in a week, and roughly 1,154 of the 1,116 components are irrelevant to this repository — you are paying a company-wide fee for eight files and the thinking around them. What would change the answer: if Cal.com's incident history shows no provider-related outages, drop to the single licence for evaluation only, or decline. If it shows even two per quarter, the first design pays for the licence.

Step 7

## 90-day roadmap

Assumes purchase and roughly one engineer at 60% allocation — which is what this repository's commit shape suggests for platform work, not a six-person squad.

### Phase 1 · days 0–30 — Quick wins and the limiter floor

Ships: Backoff and jitter in `Task.retry`; timeout and `AbortSignal` on the webhook fetch; Design #1 (limiter sandwich) behind a flag, shadow-mode first.

Why here: These three touch one method each and remove the two failure classes that are live today. The limiter floor has to precede any breaker work, because a breaker that trips under an unlimited request rate is decoration.

Effort and gate: ≈5–7 engineer-days. Gate: if shadow-mode shows the local bucket disagreeing with Unkey on more than a few percent of decisions, stop and reconcile the namespaces before enabling it.

### Phase 2 · days 30–60 — Webhook fabric

Ships: Design #2 — reliability engine over the existing tasker table, per-subscriber breaker, DLQ persisted in Prisma, RLY04 analysis read-only at first.

Why here: It is the highest-value item and it depends on Phase 1's retry policy already being sane. Doing it first would mean building a retry ladder on top of a flat-interval scheduler.

Effort and gate: ≈6–9 days; cumulative ≈13–16. Gate: if DLQ volume in week one is dominated by one subscriber, that is a customer problem, not a platform problem — ship the notification and stop there.

### Phase 3 · days 60–90 — Provider fabric, five integrations only

Ships: Design #3 limited to the five highest-traffic providers, with the health surface exposed internally.

Why here: 153 packages is not a 30-day job and pretending otherwise is how this kind of work gets abandoned. Five providers proves the seam and produces the data to justify or kill the rest.

Effort and gate: ≈8–12 days; cumulative ≈21–28. Gate: if breaker trips over 30 days are below single digits across all five, the remaining 148 are not worth the churn.

The tempting first move that is wrong: starting with the provider fabric because 153 integrations looks like the biggest number. It is the largest blast radius, the slowest to validate, and it depends on both the limiter floor and sane retry policy existing first.

Single highest-leverage item: Design #1, the limiter floor. Where the designs sit: #1 in Phase 1, #2 in Phase 2, #3 partially in Phase 3, #4 post-90-days — the ledger is a commercial bet and should be pulled forward only by a named deal.

Step 8

## Self-correction addendum

Written after a second inventory pass over the repository. The body above was not edited.

- Got wrong: the initial screen assumed the host had no rate limiting at all. It has a full eight-namespace limiter in `packages/lib/rateLimit.ts`. The real finding is narrower and better: it fails open. Any recommendation that replaced it would have been wrong.
- Got wrong: the tasker was first read as having no retry. It has retry with attempt counting and a configurable minimum interval. The gap is backoff and jitter, not retry itself — which reduces the estimate for that quick win from days to half a day.
- Confirmed: no circuit-breaker construct anywhere in `packages/` or `apps/`; no dead-letter concept anywhere; `sendPayload.ts:312` is a single fetch with no timeout; `strict: true` across the monorepo.
- Confirmed: the Discovery Vault contributes nothing here. That was the expected answer and it survived the second pass.
- Estimate moves up: Design #2. The webhook subsystem is larger than the first pass suggested — a full `tasker/`, `facade/`, `infrastructure/` and `repository/` layout under `packages/features/webhooks/lib`. Integrating rather than bypassing it is more work than the raw entry LOC implies.
- Estimate moves down: Phase 1 overall. Both quick wins are single-method changes against code that is already well factored.
- Not verified: production incident history, deployment topology (pod count), and whether the commercial `ee` directory imposes additional distribution constraints. All three would move the Step 6 numbers and none is knowable from source alone.

This report cites the catalog shipped with the agent kit. Where the full delivery is present, `artifacts/<ID>/artifact-manifest.json` is authoritative and overrides it. Every component records `testCoverage: Not claimed`, and no component has had an independent third-party security review. Static scan results and adversarial test suites are the author's own.

Verification axes cited in this report: `C:ok`, `I:ok`, `B:exec`, `B:load`, `T:—`, `S:scan`, and `C:proj(n)` by reference.

### The Collective Master Library — Licensed Edition v3.2.0

1,116 components · 2,089 source files · 358,276 lines. Free under the GNU LicenseRef-CMPSBL-Perpetual-1.0 if this host's own source ships under the perpetual licence. Otherwise, use the CMPSBL(R) Perpetual Edition License 1.0, priced per company per year: US$499 USD up to 10 people, US$499 USD for 11 to 50, US$499 USD for 51 to 250, inquire above 250. One-year update term with perpetual commercial rights to releases published during the term, 30-day full refund. Offline delivery, no account, no telemetry.

Buy at cmpsbl.com/canon