Pegma Pegma

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-07-27. The repos are the source of truth.

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

Now: 0.1.0 on npm; deliberately close to frozen. — repository

Storage Core

published @pegma/storage-core · @pegma/storage-azure-tables

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

Now: 0.3.0 on npm with the Azure Tables adapter; in production behind the reference application. — repository

Authorization Core

in development @pegma/authorization-contracts · @pegma/authorization-core · @pegma/authorization-policy · @pegma/authorization-auth0 · @pegma/authorization-stripe · @pegma/authorization-storage · @pegma/authorization-tokens

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

Now: Phase 5 pre-release integration surface complete; first publication pending — 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

Now: Phase 1 complete; awaiting the first real consumer — repository · plan

Support Desk

in development @pegma/support-desk-contracts · @pegma/support-desk-core

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

Now: Foundation (0.x, public API unstable) — repository · plan

Webhooks

planned @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

Now: scaffold established; Phase 1 ledger extraction has not begun — repository · plan

Sessions

planned @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

Now: planning; nothing extracted yet — repository · plan

Mail

planned @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

Now: planning, deliberately dormant — this component is created by — repository · plan

Identity

planned @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

Now: planning; nothing built. Implementation is deliberately queued — repository · plan

Rate Limit

planned @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

Now: planning, deliberately dormant until its first consumer — repository · plan