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/spine

The 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-d1

Persistence 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-s3

Opaque 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-redis

A 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-identity

Provider-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/audit

Append-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-templates

A 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/webhooks

Inbound 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/sessions

Server-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

Mail

published @pegma/mail

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-stripe

A 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/identity

First-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-limit

Two 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-launchdarkly

A 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-datadog

Thin 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/health

Composable 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