The stack
One repository per component, publishing under the @pegma scope. What a
component refuses to do is part of its contract — read both columns.
"Now" lines are compiled at build time from each repository's public
docs/PROJECT_PLAN.md where one exists; the rest fall back to a snapshot dated
2026-08-15. The repos are the source of truth.
Loading current stable release versions…
Spine
published @pegma/spineThe small, stable contracts every component shares.
Owns
- PrincipalId and IsoTimestamp — shared identity and time types
- Clock — time as an injected, test-fixable input
- Logger — a one-method structured logging port
- Typed event declarations and a best-effort in-process bus
Refuses
- Durable events — anything that must survive a crash goes to a storage-backed outbox, never the in-process bus
- Growth — the more spine changes, the more the ecosystem churns
Release: Loading…
Now: 0.1.2 on npm; deliberately close to frozen. — repository
Storage Core
published @pegma/storage-core · @pegma/storage-azure-tables · @pegma/storage-cloudflare-d1Persistence without the component knowing what the database is.
Owns
- Declared collections with codecs — schema-agnostic on purpose
- update deciders re-run against fresh state on every conflict
- Version-conditional deletes for safe sweeps
- Single-collection, single-partition transactions
- A conformance suite adapters must pass — verified against a real Azurite table service, never a fake
Refuses
- Server-side queries and secondary indexes
- Cross-partition anything
- Compatibility layers for pre-existing data layouts — Pegma targets net-new projects
Release: Loading…
Now: 0.4.0 on npm with the Azure Tables (0.4.0) and Cloudflare D1 (0.4.1) adapters; both adapters pass the same conformance suite. — repository
Storage Blobs
published @pegma/storage-blobs · @pegma/storage-azure-blob · @pegma/storage-cloudflare-r2 · @pegma/storage-s3Opaque object bytes through a narrow port — the counterpart to storage-core records.
Owns
- Streaming put/get, head, delete, and etag-conditioned writes for one container/bucket
- Bounded prefix listing for retention and GC
- A conformance suite every adapter must pass against a real empty backend
- Thin adapters for Azure Blob, Cloudflare R2, and S3-compatible endpoints
Refuses
- Client-facing signed URLs as the default path — hosts authorize on the API
- Authorization, rate limits, malware scanning, or attachment lifecycle inside the store
- Cross-object transactions or server-side query by metadata
Release: Loading…
Now: Phase 6 complete. @pegma/[email protected] and the Azure Blob, Cloudflare R2, and S3 adapters publish at the same version with trusted-publisher provenance from signed annotated release tags. 0.2.0 adds an optional cacheControl on put, stored as native object state by every first-class backend and returned by head/get. — repository · plan
Cache Core
published @pegma/cache-core · @pegma/cache-conformance · @pegma/cache-redis · @pegma/cache-azure-redis · @pegma/cache-elasticache · @pegma/cache-upstash-redisA cache port and adapters: ephemeral getOrCompute, namespaced keys, clock-driven TTL.
Owns
- Strict key namespacing with schema-aware codecs (JSON and binary)
- Cache-aside getOrCompute with single-flight coalescing and optional probabilistic early expiration (XFetch)
- Sliding and absolute TTL via an injected Spine Clock
- Fail-open / fail-closed fallback policies
- A conformance suite every adapter must pass
Refuses
- Durability guarantees — durable state belongs in @pegma/storage-core
- Implicit cross-partition multi-key ops; Redis Cluster hash tags are in the contract
- Unbounded local memory fallbacks when a remote cache is down
- Vendor clients leaking into application code
Release: Loading…
Now: Phase 5 — Upstash Redis adapter, published 0.1.1. @pegma/cache-core, @pegma/cache-conformance, @pegma/cache-redis, @pegma/cache-azure-redis, @pegma/cache-elasticache, and @pegma/cache-upstash-redis are published at 0.1.1. The 0.x API is unstable. — repository · plan
Authorization Core
published @pegma/authorization-contracts · @pegma/authorization-core · @pegma/authorization-policy · @pegma/authorization-auth0 · @pegma/authorization-entra · @pegma/authorization-stripe · @pegma/authorization-storage · @pegma/authorization-tokens · @pegma/authorization-identityProvider-neutral roles, entitlements, and permissions between identity, billing, and your API.
Owns
- Principals, roles, entitlements, permissions, and versioned policy
- Deterministic resolution: trusted facts in, effective permissions out
- Auth0, Entra, and Stripe adapters; storage over Storage Core
- Short-lived signed access grants (ES256, single-use)
Refuses
- Being an identity provider or processing payments
- Organization scope in v1
- Offline commercial licensing — a different artifact entirely
- Email as an authentication or authorization key
Release: Loading…
Now: Phase 5 complete; Phase 6 integration feedback and stabilization next (the signed v0.1.0 release published the original seven packages through OIDC with provenance on 2026-07-27; synchronized v0.1.2 corrects the pre-publish v0.1.1 release-test failure and first advertises Identity as the eighth package; synchronized v0.1.3 resolves the 2026-07-29 security review; synchronized v0.1.4 first advertises Entra as the ninth package; synchronized v0.2.0 aligns @pegma/storage-core at 0.4.0 across the stack; synchronized v0.3.0 delivers the identity-link write and lifecycle listing from the first reference-consumer feedback; synchronized v0.4.0 is prepared, first advertising the Admin role-administration service as the tenth package; 0.x public API remains unstable) — repository · plan
Audit
published @pegma/auditAppend-only audit records that commit atomically with the change they describe.
Owns
- One audit vocabulary — actor, subject, event, idempotency — for every component
- A TransactionAction the caller includes in its own transact call
Refuses
- Owning a store, a collection, or a partition — an audit record a component writes separately can lie; one inside the caller’s transaction cannot
- Tamper-evidence, SIEM ambitions, global ordering
Release: Loading…
Now: Phase 1 complete; awaiting the first real consumer (0.1.1 published, public API unstable; 0.2.0 is prepared, aligning @pegma/storage-core at 0.4.0 across the stack) — repository · plan
Support Desk
published @pegma/support-desk-contracts · @pegma/support-desk-core · @pegma/support-desk-application · @pegma/support-desk-templatesA composable support queue for web and email, authorized by permissions from day one.
Owns
- Tickets, channel-neutral messages, and requester trust levels
- Outbox-backed mail delivery — the state change and its delivery job commit in one transaction
- Inbound mailbox handling: threading, matching, abuse limits
Refuses
- Being a hosted SaaS — hosts run it, own its data, and choose its providers
- AI processing before the host documents what may leave its boundary
Release: Loading…
Now: The customer-facing Phase 1/2 application slice, staff detail and mutation services (Buildout Task 4), the staff queue repairable projection (Buildout Task 5), the host-neutral release candidate (Buildout Task 6), and the source portion of Phase 6 are implemented. Buildout Tasks 1–6 are complete; the exact 0.1.0 package set was published to the public npm registry on 2026-07-29 and released as the signed v0.1.0 tag. The 0.1.1 set is prepared, aligning @pegma/audit at 0.2.0, @pegma/authorization-core at 0.2.0, and @pegma/mail at 0.1.1 so the dependency tree resolves a single @pegma/[email protected]. Host deployments (Buildout Tasks 7–8) are unblocked. — repository · plan
Webhooks
published @pegma/webhooksInbound webhook receipts: idempotent dedup, poison quarantine, retention.
Owns
- One receipt per provider event id — the durable answer to “did we already process this?”
- Quarantine-then-acknowledge after bounded failures, ending retry storms
- Version-conditional retention sweeps
Refuses
- Exactly-once delivery — does not exist; will not be pretended
- Ordering guarantees — domain logic, deliberately excluded
- Storing payloads — receipts hold ids and counters, never customer data
Release: Loading…
Now: Phases 1 through 4 are complete. @pegma/[email protected] is published from the protected signed v0.1.1 release through npm trusted-publisher OIDC with provenance (0.x, public API unstable) — repository · plan
Sessions
published @pegma/sessionsServer-side session records: hashed ids, dual expiry, revoke-everywhere.
Owns
- SHA-256-hashed identifiers, non-optionally — a leaked table hands out no sessions
- Absolute plus idle expiry through one liveness predicate
- Principal-wide revocation that wins races; hygiene sweeps that lose them
Refuses
- Authentication — no OIDC, cookies, or CSRF; the host logs people in, this store remembers
- Tokens at rest, ever
Release: Loading…
Now: Phases 1–4 are complete. @pegma/[email protected] is published; RetireGolden is the first integrated consumer and pegma.dev is the second, live consumer. 0.2.0 is prepared, aligning @pegma/storage-core at 0.4.0 across the stack. The public API remains unstable. — repository · plan
Transactional mail: provider ports and an outbox pattern that owns no store.
Owns
- A delivery-job projection committed in the CALLER’s transaction — the lost-send gap closed by construction
- A lease-claiming delivery worker: bounded retries, dead jobs kept as durable human-visible rows
- A narrow send port with mandatory idempotency keys; provider adapters on consumer pull
Refuses
- Owning an outbox store — single-partition transactions make an owned outbox incapable of the promised atomicity (the audit precedent)
- Inbound mail, bulk/marketing sending, rich templating
- Deliverability abstraction — SPF/DKIM/DMARC live in the host’s DNS
Release: Loading…
Now: Phases 1–3 are complete. @pegma/[email protected] is published and is composed by both Identity and Support Desk. The public API remains unstable. — repository · plan
Billing Core
published @pegma/billing-core · @pegma/billing-stripeA provider-agnostic subscription ledger, maintained correctly under out-of-order webhook delivery.
Owns
- The event-arbitration guard: a per-account watermark, a snapshot freshness bound, and lifecycle-rank tie-breaking so a stale active can never resurrect a same-second canceled
- Snapshot reconciliation that repairs field drift without disturbing the dedup identity of events
- Declared ledger invariants (sticky, first-wins) enforced inside the write path, and an atomic single-opportunity checkout reservation
Refuses
- Processing payments, checkout flows, invoicing, tax, and metering — provider products; the ledger records lifecycle outcomes
- Entitlement resolution — what a subscription grants is Authorization Core’s job; this is what it is
- Card data, raw payloads, line items, amounts — the ledger stores identifiers and derived state only
Release: Loading…
Now: Phase 4 — Stripe adapter in-tree. @pegma/billing-core and @pegma/billing-stripe are published at 0.1.1. The 0.x API is unstable. Phase 5 stays soak-gated. — repository · plan
Identity
published @pegma/identityFirst-party identity: passkeys-first, email-code fallback, no passwords.
Owns
- Account creation, passkey sign-in, and email one-time codes for enrollment, fallback, and recovery
- User records in the host’s own storage — no external provider
- Enumeration resistance as a test-pinned property, and an honestly stated email-recovery security floor
Refuses
- Passwords — not a phase, a refusal: no password table, no reset flow, no breach class
- Being an OIDC/OAuth2 server for third parties
- Social login — external providers exist for that, and issuer-namespaced links let a host run both
Release: Loading…
Now: Phases 1–4 are complete. @pegma/[email protected] is published and live in pegma.dev with @pegma/[email protected]. The public API remains unstable. 0.1.2 is prepared, aligning @pegma/rate-limit at 0.2.0 and @pegma/mail at 0.1.1 so the dependency tree resolves a single @pegma/[email protected]. 0.1.1 was a documentation-only patch over 0.1.0 that closed the operator-guidance findings from the 2026-07-28 security scan; it changed no runtime behavior and no public API. — repository · plan
Rate Limit
published @pegma/rate-limitTwo honest tiers: in-memory abuse dampening, durable limits for expensive operations.
Owns
- A per-instance sliding window that says it is per-instance
- A durable fixed-window counter that fails closed and refuses read-only under attack
Refuses
- Pretending a per-instance window is a global quota — choosing a tier is mandatory
- DDoS protection — volumetric defense belongs at the edge
- Middleware and usage metering
Release: Loading…
Now: Phases 1, 2, and 4 are complete; Phase 3 has its first production consumer. @pegma/[email protected] is published, and pegma.dev composes the durable tier for its Identity surface. 0.2.0 is prepared, aligning @pegma/storage-core at 0.4.0 across the stack. The public API remains unstable. — repository · plan
Flags Core
published @pegma/flags-contracts · @pegma/flags-core · @pegma/flags-static · @pegma/flags-azure-appconfig · @pegma/flags-aws-appconfig · @pegma/flags-cloudflare-flagship · @pegma/flags-flagd · @pegma/flags-launchdarklyA flag port and adapters: typed evaluation, honest reasons, no authoring UI.
Owns
- Typed flag schema (declareFlags / flag.boolean|string|number|json)
- Standardized EvaluationContext and EvaluationDetail
- Local snapshot / TTL cache with stale-while-revalidate
- A conformance suite every adapter must pass
- Ports for Spine Logger, Clock, and a health probe helper
Refuses
- Flag authoring or a control-plane UI (@pegma/flags-storage is not in scope)
- A custom rule or expression language
- Global singletons or ambient request context
- Blocking synchronous network on the request path
- Returning a default without a log line and an evaluation reason
Release: Loading…
Now: Published 0.1.1 (2026-08-15). Public API unstable (0.x). — repository · plan
Logger Adapters
published @pegma/logger-tee · @pegma/logger-applicationinsights · @pegma/logger-cloudflare · @pegma/logger-datadogThin Spine Logger implementations for Application Insights, Cloudflare Workers Logs, and multi-sink teeing.
Owns
- Factories that implement Spine’s one-method Logger for named sinks
- A tee that fans one Logger out to many sinks at the composition root
Refuses
- A logging-core or Pegma-owned observability vocabulary — the port stays in Spine
- Traces, metrics, APM, or SIEM — hosts use OpenTelemetry or vendor SDKs beside Pegma
- Growing Spine with sink SDKs
Release: Loading…
Now: 0.1.3 on npm (tee, Application Insights, Cloudflare, Datadog); trusted publishing configured; OIDC publish workflow in-repo. Public API unstable. Host tee wiring on RetireGolden and pegma.dev is the remaining consumer bar. — repository · plan
Health
published @pegma/healthComposable health probes and HTTP responses for public liveness checks.
Owns
- Check contracts, aggregation, and HTTP status mapping
- Process, detail, and injected Store ping helpers
- Spine log events health.ok / health.degraded / health.failed
Refuses
- Owning a storage adapter or inventing domain collections
- Autodiscovery of checks — hosts register them at the composition root
- Metrics, APM, or alert fan-out
Release: Loading…
Now: 0.1.2 on npm; trusted publishing configured. 0.2.0 is prepared, aligning @pegma/storage-core at 0.4.0 across the stack. Public API unstable. — repository · plan