jampress.pw
PhilosophyDocsRoadmapPlaygroundGitHub

Documentation

PhilosophyThree tracks, modular scaling, and the foundation rules that shape every package.ArchitectureStable viewer contracts with swappable provider/storage internals.Astro Site BlueprintsFleet, collection, site, storage-topology, and downstream release boundaries.Capability FoundryReusable upstream capabilities with independent product and owner repositories.SecurityThreat model, token/session controls, and rate-limit requirements.RoadmapPhase-by-phase path from DIY auth to WordPress bridge and adapters.Auth Adoption PlanConcrete rollout order and milestones for zip, lobpress, inbox, DesBio, and DBScript.Host App IntegrationHow Astro and Workers apps wire middleware, hooks, and routes.Provider AdaptersThe AuthAdapter contract and migration path across login providers.Data ModelD1/MySQL schemas for identities, sessions, tokens, and rate limits.

Capability foundry and product boundaries

Jampress is the private upstream capability foundry for reusable contracts, kernels, adapters, blueprints, migrations, conformance tests, and deterministic release tooling. It is not the canonical source repository for every site or plugin assembled with those capabilities.

What belongs in Jampress

  • host-neutral contracts and implementation kernels;
  • storage, provider, framework, and administration adapters;
  • Astro collection and plugin blueprints;
  • schemas, migrations, compatibility metadata, and conformance fixtures; and
  • release, provenance, adoption, and upgrade tooling.

Private reference integrations may remain here when they exist only to prove a contract. An integration that acquires its own users, product name, marketplace identity, documentation, issue tracker, contributors, license, or release cadence belongs in an independent authoritative repository.

What belongs downstream

Owner collection repositories own brands, content, visual systems, app composition, Cloudflare configuration, and production promotion. Independent plugin repositories own their plugin descriptor and runtime, product-specific admin experience, public documentation and license, marketplace bundle, semantic version, and release approval.

Jampress may initialize those repositories and propose upgrades through pull requests. Generated-owned and product-owned paths must be declared separately; an update must not overwrite product implementation or intentional divergence.

Jampress capability release
  → immutable artifact + provenance + compatibility contract
  → reviewable adoption pull request in a product/collection repository
  → product-specific build and test
  → separately approved marketplace or site deployment

Jampress and downstream product versions are independent. Releasing Jampress has no production effect until a consumer deliberately adopts, tests, and promotes that release.

EmDash boundary

A private EmDash adapter with no independent lifecycle may live under integrations/emdash/. A catalog-facing plugin such as a future commerce plugin belongs in its own repository. Jampress can provide commerce contracts, kernels, adapters, plugin scaffolds, and compatibility tests; the product repository owns the EmDash entrypoints, admin UI, marketplace metadata, docs, and the final emdash plugin bundle release.

Existing independent repositories such as emdash-mail, form-mailer, and emdash-mail-cloudflare remain product sources of truth. Extract shared code only when genuine reuse appears; do not replace them with generated mirrors.

Private/public distribution boundary

Jampress and its packages are currently private and UNLICENSED. Checksummed private exports are for explicitly authorized private repositories only. A public product must not vendor those artifacts without a separate package distribution and licensing decision. If a public plugin needs a Jampress-authored package, choose a public/licensed package or source boundary deliberately before release.