Engineering
Engineering begins with the shared requirements contract and follows it through design, pre-release evidence, continuous delivery, and production learning.
flowchart LR Req["REQUIREMENTS.md"] --> Arch["ARCHITECTURE.md"] Arch --> Test["TESTING.md"] Test --> Pub["PUBLISHING.md"] Pub --> Obs["OBSERVABILITY.md"] Obs -. "experience / requirements" .-> ReqPrivate product planning (REQUIREMENTS.md, experience journeys) lives in
graphforge-nextjs;
the engineering pages below stay public for contributors.
Lifecycle
Section titled “Lifecycle”| Document | Responsibility |
|---|---|
ARCHITECTURE.md |
Problem model, responsibility boundaries, and components that satisfy requirements |
TESTING.md |
How tests and CI prove the system before release |
PUBLISHING.md |
How verified artifacts are versioned, promoted, and rolled back |
OBSERVABILITY.md |
How CI/release/user signals feed discovery |
adrs/ |
ADR index (bodies in ../adr/ 0001–0014) |
Supporting documentation
Section titled “Supporting documentation”| Document | Description |
|---|---|
../book/architecture/ |
Deep architecture notes, pipeline, storage, embedding contracts |
../development/ |
Contributor workflow, testing detail, release process |
../contracts/ |
Frozen public API / fingerprint JSON contracts |
../reference/ |
Compatibility, TCK, scale limits, column naming |
| Private experience journeys | Journeys that requirements and tests must cover |
| Private strategy | Positioning and roadmap summary |
| Root AGENTS.md | Agent workflow and validation gates |
Decision records
Section titled “Decision records”Create the next Architecture Decision Record with:
docslime add adr <short-slug>Until bodies live under engineering/adrs/, add new ADR markdown under docs/adr/ and update
both ../adr/README.md and adrs/README.md in the same
change. Do not fork a second numbering sequence.