Integration Report — Cal.com

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.

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

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.

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

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

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

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

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.

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.

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.

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.

Gap map

Do not touch

Quick wins

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.

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.

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.