Skip to content

Centralize deployment-mode gating behind a capability definition#155

Open
CarsonDavis wants to merge 1 commit into
tests-both-modes-cifrom
lean/capability-gating
Open

Centralize deployment-mode gating behind a capability definition#155
CarsonDavis wants to merge 1 commit into
tests-both-modes-cifrom
lean/capability-gating

Conversation

@CarsonDavis

Copy link
Copy Markdown

Closes #152.

What this does

Replaces the ~30 scattered isFull()/isLean() deployment-mode checks with one capability definition that every gate reads, so "what does lean turn off?" is answered in one place and adding a mode is a one-table edit. Pure restructuring — no behavior change in either mode.

  • One backend definition (API/Backend/Utils/capabilities.js): a capability → enabling mode(s) map resolved through one accessor; throws on an unknown capability so a typo fails at boot.
  • Whole modules gate at the discovery seam (API/setups.js): each gated setup.js declares capability: "<name>" and the seam decides. onceInit/onceStarted are gated; onceSynced runs unconditionally, so every gated-off feature still creates its DB tables in both modes (a later mode flip needs no migration).
  • Partial gates (Missions mount, utils raster endpoints, mmgis-stac creation, the WITH_* Configure flags, the adjacent-servers spawn/proxy) ask the definition by capability name.
  • localSidecars collapses the sidecar cluster; localMissions is its own capability.
  • updateTools reads each tool's declared capability (Draw declares "draw") instead of a hardcoded name.
  • The Configure twin (configure/src/core/capabilities.js) is extended and Panel/SaveBar/DeploymentsWatcher migrated off raw mode-string checks. The twin uses the same list shape as the backend (warns + hides on unknown, rather than throwing — a render-time gate fails safe).

Deliberately left as direct mode checks: the upload S3-vs-disk storage fork (uploadRouter.js) and deploymentMode.js itself. staticHandlers.js is untouched (a call's static disposition isn't a pure function of its capability).

Verification

  • Unit suite: 674/674.
  • Live, both modes (init-db boot → assert gated tables exist → present/absent route checks):
    • full: 6/6 table groups present; 8/8 present/absent (full-only features present, deployments absent).
    • lean: 6/6 table groups present (despite routes gated off); 8/8 inverse (full-only features absent, deployments present).
  • Independent review pass: behaviour-preserving, completeness full (only the two intended exceptions), seam invariant holds. Dead isLeanMode export removed and the Configure twin DRY'd as part of review.

Merge order

Stacked on #154 (base tests-both-modes-ci). Merge after the test chain: #150#153#154 → this. The both-modes coverage from #154 is what gates this refactor in CI.

Replace scattered isFull()/isLean() checks with a single capability
definition (API/Backend/Utils/capabilities.js) that every gate reads.

- Backend modules declare `capability`; the discovery seam (API/setups.js)
  decides what to wire. onceInit/onceStarted are gated; onceSynced runs
  unconditionally so gated-off tables still exist in both modes.
- Partial gates (Missions mount, utils routes, mmgis-stac, WITH_* flags,
  adjacent-servers spawn/proxy) ask the definition by capability name.
- localSidecars collapses the sidecar cluster; localMissions kept separate.
- updateTools reads each tool's declared capability (Draw declares "draw").
- Configure twin extended; Panel/SaveBar/DeploymentsWatcher migrated off
  raw mode-string checks.
- Upload storage fork left as a direct mode check; staticHandlers untouched.

Unit suite: 674/674 green.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant