Maturity and maintenance

Copy Markdown View Source

How Accrue thinks about “done enough” for the core library and companion admin, and when new work should start — without duplicating the deep guides.

Accrue uses a stable-core / demand-driven expansion posture: the canonical SaaS billing loop is complete for declared scope, and expansion only reopens when evidence shows a concrete adopter-facing need.

Who this is for

  • Maintainers triaging issues and doc PRs.
  • Integrators deciding whether to pin another 1.0.x minor or stay on a known mix.lock.

Operational pair

  1. Production readiness — ordered checklist for shipping billing in a real Phoenix app (what to verify, where to read next).
  2. Friction inventory + stop rules (monorepo) — ranked evidence and diminishing-returns doctrine live in the repo-root planning notes for a full monorepo checkout. They are not shipped inside the Hex package tarball, so use GitHub browse or the repository root when you need the live inventory.

New P0 / P1 friction rows belong in that inventory only when they meet the priority bar in the inventory preamble (sources, integrator impact, CI contract). Broad doc sweeps without a row are out of policy — see north star S1 / S5.

Supported integration surface

The 1.0.x stability contract applies to the documented facade:

The SemVer boundary does not include internal schemas, workers, generated migration history, demo helpers, or Fake-processor internals. Those may change when correctness, docs, or proof quality require it, as long as the documented facade stays stable.

When Accrue is in “maintenance posture”

Roughly: merge-blocking proof and package-doc contracts stay green, the post-1.0 friction table has no open P0/P1 rows, and further changes should be intake-gated (new evidence, publish event, or security/correctness) rather than speculative polish.

Revisit triggers (examples — see inventory maintainer notes for the live list):

  • Next linked Hex publish for accrue / accrue_admin.
  • Intentional adoption proof matrix / verify_adoption_proof_matrix.sh taxonomy edits.
  • A concrete adopter failure mode tied to a correctness/security/data-loss risk.
  • A repeated support issue that the documented facade cannot absorb.
  • An operational failure that threatens day-two reliability.
  • An explicit strategy change with documented maintainer rationale.

Explicit non-goals in this posture

Stable core does not mean abandoned; it means we avoid broad speculative surface growth until evidence crosses the bar above. Non-goals remain:

  • expansion without a concrete adopter failure mode
  • shipping broad new capability before correctness/security/data-loss risk is addressed
  • using maintenance cycles for feature-chasing rather than support-contract hardening