How to contribute

How to contribute to Elimi Docs

Audience: all contributors
Status: building
Owns: docs / delivery lead
Depends on: Domain entities, Maturity

This site is the single source of truth. Lower layers reference the domain and lifecycle; they never invent parallel names for the same concepts.

Ownership

Doc area	Primary owner	Reviewers
Domain / glossary / lifecycle	Product + backend	UX, QA
Experience (flows, personas)	UX	Frontend, tech writing
OpenAPI / API contract	Backend	Frontend, QA
Backend architecture / system architecture	Backend	Product
Backend stack ADR	Backend	Devops, leadership
Coding standards / observability / CI/CD / payment architecture / console commands	Backend + devops	Leadership
Event catalog / RBAC matrix	Backend + product	—
CAP workflow / NSQ lifecycle	Product + backend	UX, QA
Frontend structure	Frontend	UX
Test cases	QA	Product
Feature narrative	Tech writing	Product, UX
Maturity / ecosystem map	Delivery or product lead	Leadership (occasional)

Rule: one owner writes; others only link and challenge language.

Status values

Align page status with Ecosystem maturity:

Status	Meaning
`idea`	Named; not specified for build
`specced`	Enough docs for implementation to start
`building`	Implementation in progress
`alpha` / `beta` / `ga`	Increasing production readiness

Put status in the page header block (and optionally frontmatter) so readiness is visible without reading Delivery.

Every durable page should open with:

**Audience:** leadership | domain | ux | backend | frontend | qa | writing
**Status:** idea | specced | building | alpha | beta | ga
**Owns:** role or named owner
**Depends on:** links to domain / lifecycle / API / UX as relevant

Cross-link policy

From	Must link to
UX flow	Domain entity + lifecycle stage
OpenAPI / API group	Domain use case
Frontend area / component	UX screen + API
Test case	Lifecycle transition or policy
Feature brief	Experience + product module

Broken or missing links usually mean missing agreement—fix language first.

Page templates

Entity (domain)

Name, one-sentence definition
Key attributes (business, not DB columns)
Invariants / rules
Related entities and lifecycle stages

Flow (experience)

Persona, goal, entry point
Steps named with lifecycle stage / status codes
Screens (or placeholders)
Links to domain entities and policies

API operation group

Resource group name (e.g. Applications)
Domain use cases covered
Point to future openapi.yaml paths when they exist
Error / auth notes at a high level

Backend context

Bounded context name
Aggregates / entities owned
Adapters (NIN, payment, Orchestrator, LMS)
Links to API overview

Frontend area

Route / app area
Reusable components used
Links to UX flows + API groups (no duplicate lifecycle tables)

Test case (QA)

ID: TC-…
Given: stage X / status Y (and persona)
When: …
Then: …
Refs: lifecycle / policy / flow links

Feature brief (narrative)

Audience (candidate, centre, public, …)
Draft / Review / Published
What the feature does in plain language
Links to experience + product modules

CAP RPL as the template

LMS has left stub status (product spine + API + data model). When WorkMasters leaves stub, copy the CAP RPL (or LMS) layer folders:

experience/ · api/ · backend/ · frontend/ · qa/ · narrative/

plus the shared product spine (overview, lifecycle or equivalent, policies, personas).

Orchestrator already uses api/ + backend/ beside its overview. HTTP contracts:

Live CAP HTTP: elimi-ecosystem/apps/cap/openapi/openapi.yaml (copy to ecosystem-root cap-openapi.yaml after edits)
Docs seed: ecosystem-root orchestrator-openapi.yaml, cap-openapi.yaml, lms-openapi.yaml
Published: openapi/orchestrator.yaml, openapi/cap.yaml, openapi/lms.yaml (via pnpm sync:openapi)

Browse them in Contracts (Scalar). Event schemas live under contracts/events/; gRPC is synced from @yourorg/proto. See Backend stack ADR and Architecture handover.