0020: Measure bundle size, then set a baseline
The 3 kB gzip figure in 0015 is not a cap. Core is built first, then tests/bundle records the measured size as the regression baseline.
Status
Accepted, September 2026. Supersedes the size-budget bullet of 0015. The rest of 0015 (one runtime dependency, no validator or serialiser or telemetry in core, ESM-only) stands.
Context
ADR 0015 set "core under about 3 kB gzip" because permix is 2.64 kB gzip and @zap-studio/permit is about 2.8 kB minified. That number is a competitor's size, not a PermDock measurement. PermDock core also carries a portable condition AST, a three-outcome Decision, boundary validation, and snapshots that retain conditions. Guessing 3 kB before any of that exists would make the budget a design constraint it was never meant to be.
tests/bundle is still the right place to measure per-entry min+gzip size. What was wrong was treating an unmeasured target as a CI fail and as a public claim.
Decision
- There is no size cap until core exists. Phase 1 does not fail CI, reject features, or advertise "under 3 kB gzip" against a guessed number.
- After core ships,
tests/bundlerecords the measured min+gzip size of each entry. That measurement is the baseline. Later PRs fail CI on a regression from the baseline, not from 3 kB. - Core stays small by construction: ESM-only, one types-only runtime dependency, no validator, no serialiser, no telemetry (0015). Size is a consequence of that, not a separate hard number.
Consequences
- The README, comparison table and success metrics do not claim a core size until one is measured.
- Adapter PRs still ship a
tests/bundlemeasurement; they do not invent a budget in the same PR as the first implementation. - Contributors do not cut the condition AST or
Decisionshape to chase 3 kB.
Alternatives considered
- Keep the 3 kB cap as a stretch goal. Rejected: a stretch goal that fails CI is a cap. The number was never measured.
- No size tracking at all. Rejected: permix #67 showed that per-entry measurement catches accidental client-bundle growth. Measure first, cap later.
Related
0019: x-permdock-* extensions, registered fallbacks only, Overlay output
Why PermDock's OpenAPI output lives in a registered x-permdock- namespace, borrows x-oai-* names only when the OpenAPI Initiative has registered them, prefers emitting an Overlay to mutating the source document, and defaults to target 3.2 while tracking 3.3.
0021: Embedded PDP, hosted ADS and control plane
PermDock is a policy decision point you embed and that never needs a network call to decide; PermDock Cloud is an optional Authorization Decision Service and control plane that implements interfaces anyone can implement, lives in its own repository, and is reached through the thin permdock/cloud entry.