26 · Coverage matrix & remaining systems
Honest checklist: what DocHub already covers in depth, what was only mentioned, and what still exists in the repo as stubs, debt, or thin docs. Use this before declaring “we’ve mapped everything.”
Covered in depth (DocHub chapters)
| Ch | Topic | Confidence |
|---|---|---|
| 00–07 | Orientation, hierarchy, deploy, data, auth, money, features, clients | solid |
| 09 | UPC/barcode dual GTM + POS/inventory path | solid |
| 14–15 | POS/Mobile · Floor/KDS/Signage | solid |
| 16–18 | Tickets/appointments · gift/loyalty · customers/storefront | solid |
| 19–22 | Bridge/devices · crypto/payments · HR · hub/reports | solid |
| 23–25 | Tax/receipts/notify · Master Admin · inventory | solid |
| 11–13 | Audit gaps · dev discipline · git/domains | solid |
Previously thin — summarized below
Real code exists; we had only name-drops. This chapter is the catch-all so nothing “invisible” remains.
- Catalog Manager (menus, 86, preparables, assignments)
- Theme system + toast/notification/error boundaries
- Plans / FeatureGate / tenant billing UI
- Audit log UI + taxonomy
- Webhooks + API keys + integrations admin
- Branding + device/printer/POS profiles
- Offline / PWA queue
- Staff permission sets (beyond HR roles)
- Frontend placeholders still in App.jsx
- Parallel
routes/api/*tree + legacy files
Catalog Manager (not the same as Inventory)
| Concept | Role | Where |
|---|---|---|
| Inventory | Stock truth, cost, ledger | DocHub 25 · /inventory/* |
| Catalog / menus | What appears on POS/storefront, categories, 86, preparables | /admin/catalog/* |
| Assignments | Bind menu to device / storefront / location | catalog assignments API |
| 86 board | Mark items unavailable | admin catalog 86 |
| Preparables | Kitchen prep definitions · feeds KDS routing | /api/preparables · catalog preparables UI |
| auto86ing service | Automated 86 from stock signals | auto86ing.service.js |
POS catalog load often comes from assigned menus + products, not raw inventory alone. Storefront menu-items endpoint respects assignments (DocHub 18).
Cross-cutting UX platform
| System | Location | Notes |
|---|---|---|
| App themes | frontend/src/theme/* · admin system themes |
Light/dark, CSS vars, optional remote theme |
| Vertical theme templates | themes/templates/* |
farm, restaurant, retail, service, kiosk — DocHub 10 |
| Nav themes / modules | lib/navigation/* · NavigationRenderer |
Feature-gated nav modules per business type |
| NotificationSystem + ToastHost | lib/ui/NotificationSystem.jsx · toast.jsx |
success/error toasts; uses errorFormatter |
| GlobalErrorBoundary | lib/error/* |
Tenant-aware crash boundary + RouteErrorBoundary in App |
| Branding | /admin/branding · brandingSettings |
Logos, brand colors, ties into receipts |
| Profiles | /admin/profiles/* · /api/profiles |
POS modes, printer profiles, device role templates |
Plans, feature gates, billing
| Piece | Detail |
|---|---|
planFeatures.js | BASIC / PREMIUM / ENTERPRISE module lists + limits |
FeatureGate component | Hides UI modules without plan feature |
checkFeatureAccess middleware | Server-side on many routers (inventory, kds, gift_cards, loyalty, staff_hr, …) |
/api/plans · /api/features | Plan/feature APIs |
| Tenant billing UI | /admin/billing · Master Admin billing pages |
| Permission sets | Team permission sets UI — deeper than role strings; evolving (coverage map admits RBAC depth) |
Inconsistency risk
Some modules gated only in UI, some only server, some both. Programs shell uses gift_cards gate for loyalty pages.
When adding features, always wire both FeatureGate + checkFeatureAccess.
Audit, webhooks, API keys, integrations
| System | Path / API | Notes |
|---|---|---|
| Audit | /api/audit · auditTaxonomy.js · Admin AuditLogs |
Strong OAO chapter; events in analytics DB; HR has separate write-only log |
| Webhooks | Admin Webhooks UI · generic + provider webhooks (stripe, coinbase, doge, ltc, …) | Inbound money/crypto + outbound dispatcher services |
| API keys | /admin/api-keys · models apiKey |
Integrations / external access surface |
| Integrations | /admin/integrations |
Hub UI for third-party wiring |
| API reference | /admin/api-reference · api-explorer in OAO |
Generated catalog; cross-check with live mounts |
Offline / resilience
| Piece | Status |
|---|---|
tryOnlineThenQueue · IndexedDB queue | Mutation queue works while tab open |
| Service worker registration | Disabled (reload-loop comment) — no offline app shell |
| Backend offline transaction uploaders | Services exist for bridge/offline upload |
| POS idempotency middleware | On pos.routes — important for replay |
Known UI stubs / placeholders (App.jsx)
Routes exist; do not sell as complete products without verification.
| Route / page | Status |
|---|---|
/pos/bar | Placeholder component |
/pos/restaurant · /pos/handheld | Lazy load throws → placeholder |
| KioskSelfServe | Hardcoded demo products |
/terminal virtual terminal | Placeholder |
/items · categories · modifiers · discounts · images (top-level) | Placeholders (real work under inventory/catalog admin) |
| Business hub analytics/ops/integration tiles | Some Placeholder routes |
| Master tenant-admin customers/analytics | Placeholder tiles |
/reports/payment-methods | Placeholder UI (API may exist) |
Architecture debt still open
| Debt | Impact |
|---|---|
Parallel routes/api/* tree | Confusion which handler wins; S11-10 |
| Duplicate gift/loyalty/inventory/dashboard files | .NEW/.OLD · dual services |
| Frontend Vite dev server in “production” | S1-2 maturity |
| No git on live app tree historically | Mitigated by gperep — keep using it |
| ICP workbook blank | Strategic; S0-3 |
| Storefront guest + card e-com | DocHub 18/20 checklist |
| Signage live map / multi prep board | DocHub 15 build list |
| Mobile POS parity | gift/loyalty/seating/catalog |
| External paid barcode API | DocHub 09 roadmap |
OAO vs DocHub
OAO = long-form technical chapters + appendices + AUDIT-FINDINGS (trust for depth).
DocHub = navigable visual map + product-oriented module pages for day-to-day orientation.
If something is missing in DocHub but exists in OAO (e.g. exhaustive route table Appendix A), use OAO — then optionally promote a summary into DocHub when it becomes a focus area.
- OAO still best for: full route table, schema appendix, auth appendix step lists, audit taxonomy detail
- DocHub best for: dual-GTM barcode, POS parity, theater floor vision, e-com gap list, coverage honesty
Recommended next (stop mapping, start choosing)
flowchart TB
MAP[Documentation map complete enough]
MAP --> A[Build: storefront e-com]
MAP --> B[Build: Mobile POS parity]
MAP --> C[Build: Signage live seat board]
MAP --> D[Build: paid barcode API]
MAP --> E[Verify: gift/loyalty E2E]
MAP --> F[Ops: frontend prod build + git workflow]
Nothing major product-shaped remains “undiscovered.” Remaining work is either thin cross-cutting polish in docs (this page), verification, or implementation of known gaps.