Project and engineering documentation¶
This section is for contributors, maintainers, reviewers, and integrators who need to understand why PostProject is built the way it is.
It is intentionally not the starting point for ordinary users. Architecture notes, persistence details, benchmarks, release reports, and ADRs are important records, but they should not sit between a new reader and the basic PostProject model.
Current direction¶
Read Roadmap for planned work and release goals. The roadmap explains where the project is going; it should not be used as a substitute for the concept documentation that defines current behavior.
Contributing¶
Start with Contributor guide.
Changes to domain meaning, persistence, public APIs, or the ABI often need coordinated work across several layers. The contributor pages describe:
content-structure invariants;
metadata model rules;
provenance model rules;
standards policy.
Architecture and implementation reference¶
Use these pages when the implementation itself is relevant:
Portable exchange protocol and Exchange implementation inventory describe the experimental exchange contract and its implementation coverage.
Commercial host feasibility records the reviewed commercial integration routes and their runtime limits.
API ergonomics audit records the current API redesign and consumer migration status.
Revised 0.9 workflow design describes the canonical workflows and their preserved contracts.
PostProject 0.9 / ABI 57 qualification records the revised candidate and its source-scoped verification.
Revised 0.9 workflow comparison compares the five complete tasks with the qualified initial 0.9 candidate.
Python API measurements for 0.9 records installed Python scan and input costs against the published 0.8 wheel.
These are engineering references. Application integrators should prefer the integrator and concept guides unless they are diagnosing implementation behavior.
Compatibility and releases¶
Releases and compatibility collects the native compatibility contract, the release process, and the acceptance report of every release.
Historical reports should remain available because they are useful evidence, but they should be treated as history rather than mixed into the primary learning path.
The PostProject 0.7 candidate acceptance records delivered contracts, qualification and package scope. The PostProject 0.7 compatibility evidence records measured family use and its limits.
The PostProject 0.6 compatibility decision retains the approved 0.6.x C++ Result propagation promise.
Architecture Decision Records¶
Architecture decision records lists every ADR by area. ADRs explain significant design choices at the time they were made. They are valuable when changing an invariant or revisiting a boundary, but they are not normative onboarding documentation.
Use the current concept/API documentation for present behavior, then consult the relevant ADR to understand the reasoning and tradeoffs behind it.
Standards impact¶
When a change touches an area that maps to an external standard, consult the standards policy and standards-impact records before extending the core model. The default preference is to keep external-standard-specific behavior at adapter boundaries unless the concept is genuinely part of PostProject’s application-neutral production model.