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.

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.