Documentation gap closure plan
Purpose
Section titled “Purpose”This page records a phased execution plan for closing the gap between strong internal developer documentation and expectations for a full enterprise / audit-style artifact set. It is a planning and prioritization companion to:
- Engineering deliverables — the governance hub for named policies (release, test strategy, NFR/SLO, threat model, ADR practice).
- Documentation upgrade status & roadmap — what is upgraded on this site and recommended doc work order.
Scope: Updates to the docs/ handover site and documentation habits only. It does not authorize or require changes to the Frappe application under leekimerp/ — any app work is out of scope for this document.
1. Assessment (concise)
Section titled “1. Assessment (concise)”Strengths: Architecture and operations context, security and API inventories, domain deep dives (D1), generated DocType reference with overlays, CI and inventory gates — the core of codebase onboarding and change safety is in place.
Limitations: Until policy pages are filled and adopted, some “enterprise package” expectations (explicit SLO commitments, full threat review, compatibility matrix as a living artifact) remain template- or process-dependent. The Engineering deliverables hub exists to close that naming and structure gap.
2. Gaps → where work lives
Section titled “2. Gaps → where work lives”| Gap | Primary home on this site |
|---|---|
| Named test strategy, compatibility, release policy | Test strategy, Release & compatibility, linked from Test evidence & CI |
| NFR / SLO catalog | NFR & SLO — template ties to Introduction overview |
| STRIDE / trust boundaries beyond checklist | Threat model — Security checklist stays control-oriented |
| ADR accumulation | ADR practice + Architecture decisions |
| Thin generated DocType pages vs “what do I do when I change this?” | Domain documentation strategy — D1/D2/D3, docs/doctype-overlays/overlays.json, domain deep dives |
| Code ↔ docs consistency | Documentation conventions — Change type and documentation sync — table for PR/review |
| End-to-end flow navigation (onboarding & triage) | Critical paths (E2E), Business logic flows |
3. Principles
Section titled “3. Principles”- Single source of truth: Field tables stay generated; narrative stays in domain pages and overlays (ADR-004).
- Use the governance hub — avoid parallel “mystery” locations; link from Engineering deliverables instead of duplicating policy prose.
- Automation vs manual: Keep CI gates and Handover docs sync visible in runbooks.
4. Phased execution
Section titled “4. Phased execution”Phase A — Governance adoption (short horizon)
Section titled “Phase A — Governance adoption (short horizon)”Goal: Teams routinely cite Engineering deliverables for P0/P1 items (release, tests, NFR, threat review, ADRs).
| Action | Notes |
|---|---|
| Fill or assign owners for hub tables | Per NFR & SLO, Threat model, Release & compatibility |
| Change-type → doc matrix | Use Documentation conventions — Change type and documentation sync; extend in PR template or wiki if needed |
| E2E hubs in onboarding | New maintainers land on Start guide → Critical paths (E2E); keep Feature inventory aligned with docs/astro.config.mjs |
Exit criteria: “Where is test policy / compatibility / threat depth?” → Engineering deliverables in one hop.
Phase B — DocType actionability (ongoing)
Section titled “Phase B — DocType actionability (ongoing)”Goal: P1 DocTypes (per domain strategy) have domain narrative + overlay pointers, not only field tables.
Exit criteria: Critical-path changes have a clear “read this domain page + these overlays” path.
Phase C — Audit or large handoff (event-driven)
Section titled “Phase C — Audit or large handoff (event-driven)”Goal: Handover completion checklist optional rows are evidence-ready — use existing policy pages, not ad hoc docs.
Phase D — Automation (optional, later)
Section titled “Phase D — Automation (optional, later)”Tracked under Documentation upgrade roadmap §2.4 — e.g. richer API inventory generation; no app code requirement in this plan.
5. Recommended priority order
Section titled “5. Recommended priority order”- Phase A — adopt Engineering deliverables P0/P1.
- Phase B — overlays and domain depth for priority domains.
- Phase C — when audit or handoff dates are fixed.
- Phase D — after processes stabilize.
Aligns with recommended execution order on the upgrade roadmap, with governance adoption explicit first.
6. Risks
Section titled “6. Risks”| Risk | Mitigation |
|---|---|
| Duplicate policy locations | Single hub: Engineering deliverables |
| Doc-only scope creep | This plan does not require leekimerp/ code changes |
7. What this plan does not do
Section titled “7. What this plan does not do”- Change Python, DocType JSON, or Bench configuration — out of scope.
- Replace commercial Word/PDF handover — see Handover deliverables and Reference vs implementation.