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 pre-1.0 minor or stay on a known
mix.lock.
Operational pair
- Production readiness — ordered checklist for shipping billing in a real Phoenix app (what to verify, where to read next).
- Friction inventory + stop rules (monorepo) — ranked evidence and diminishing-returns doctrine live at
.planning/research/v1.17-north-star.md(stop rules) and.planning/research/v1.17-FRICTION-INVENTORY.md(intake table) relative to the git repository root (not shipped inside the Hex package tarball). Use a full monorepo checkout or GitHub browse to read them.
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.
When Accrue is in “maintenance posture”
Roughly: merge-blocking proof and package-doc contracts stay green, the post–0.3.1 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.shtaxonomy edits.
Related
- First Hour — How to enter (H/M/R capsules ↔ host README spine).
- Contributing — release gate and doc-contract expectations (monorepo root; not bundled in the Hex tarball).