diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 6a5a08f..efb8185 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -1,6 +1,6 @@ # Roadmap -shopdb-flask is at `__contract_version__ = '0.5.0'` (pre-1.0). This document captures what stands between today and a stable `1.0.0` release. Maintained as scope evolves; supersedes nothing in the ADRs. +shopdb-flask is at `__contract_version__ = '0.11.0'` (pre-1.0; product `__version__ 0.7.0`, tags through v0.7.0). This document captures what stands between today and a stable `1.0.0` release. Maintained as scope evolves; supersedes nothing in the ADRs. ## Phase status @@ -12,7 +12,9 @@ shopdb-flask is at `__contract_version__ = '0.5.0'` (pre-1.0). This document cap | 3 - Manifest-first loader, shopdb.api namespace, auto-register blueprints | DONE | `6f085a1` | | 4 - Plugin scaffolding (`flask plugin new`) | DONE | `8eb9362` | | 5 - Alembic baseline, per-site deploy, ADRs to docs/adr | DONE | `d4e3ac9` | -| 6 - Multi-site distribution readiness (settings-driven branding/ServiceNow/floor plan, security closeout, docs + Docker frontend build, release engineering) | IN PROGRESS | this phase | +| 6 - Multi-site distribution readiness (settings-driven branding/ServiceNow/floor plan, security closeout, docs + Docker frontend build, release engineering) | DONE | v0.5.0-v0.7.0 | + +The last big milestone before 1.0 is the legacy-ASP data import plus a production pilot deployment; the framework work below is what remains after that. ## What's left before tagging 1.0.0 @@ -21,15 +23,11 @@ shopdb-flask is at `__contract_version__ = '0.5.0'` (pre-1.0). This document cap - **Asset model fully wired**. `Asset.mapx, Asset.mapy` columns, `AssetRelationship.inheritsposition`, `AssetRelationship.propagatesthroughid` columns. Models match the locked ADR-001 surface that `resolve_asset_position` already targets. - **Equipment data migration script** for facilities migrating from legacy ASP shopdb. One-shot script under `scripts/migration/`. See [migrating-asset-schema](../../.claude/skills/migrating-asset-schema.md) for the policy. Per ADR-001, only `category='Equipment' AND machinenumber IS NOT NULL` migrates. - **Printers retirement**. Legacy `PrinterData` model, `printers_bp` legacy blueprint, and the frontend `PrinterForm.vue` references to `printer.printerdata.*` get removed in lockstep. Coordinated with the equipment migration. -- **Frontend hook contract**. Vue side equivalents for the backend hook system: how plugins expose asset-detail components, map markers, search-result renderers. Requires its own design ADR. -- **Per-plugin Alembic migrations**. The framework supports them via `shopdb/plugins/migrations.py`; bundled plugins still rely on `db.create_all()`. Move each bundled plugin onto its own version chain before sister sites adopt. +- **External plugin UI packaging**. The Vue-side hook contract ships (ADR-010: get_settings_cards / get_asset_panels / get_map_overlays / get_asset_presentation) and route gating is backend-driven (ADR-009), but plugin routes/views still live in core `frontend/src`. Let an external plugin ship its own Vue bundle so adopters can add UI without editing core. ### Nice-to-have -- **Bundle the Roboto font locally.** `frontend/src/assets/style.css:2` imports Roboto from Google Fonts (`fonts.googleapis.com`). Air-gapped facilities have no route to that host, so the font silently falls back to a system font. Vendor the woff2 files into `frontend/src/assets/` and `@font-face` them locally so every site renders identically offline. -- **Full palette theming.** `brand_primary_color` is settings-driven, but the rest of the CSS palette (surfaces, borders, accents) is still hardcoded in `style.css`. A complete theming pass would expose the palette as CSS variables a site can override, not just the one primary color. -- **Frontend plugin contract.** The backend hook system has no Vue-side equivalent yet (routes/views still ship in core; nav is already backend-driven). See the must-have entry above; this is the design ADR that unblocks external plugins shipping their own UI. -- `measuringtools` plugin built using the scaffold (validates the scaffold under realistic conditions). +- **Full palette theming.** `brand_primary_color` and a few brand colors are settings-driven, but the rest of the CSS palette (surfaces, borders, accents) is still hardcoded in `style.css`. A complete theming pass would expose the palette as CSS variables a site can override, not just the brand colors. - Frontend scaffolding skill (the backend has `flask plugin new`; the frontend stub is currently manual copy-paste). - Marketplace listing site (PLUGINS.md is a one-pager; a proper listing with links to sister-site plugins becomes useful when there are more than three external plugins). - Plugin contract surface diff tooling. Today version bumps are manual judgment; a CI check that diffs the contract surface against the previous tag would catch missed bumps. See ADR-002. @@ -63,3 +61,9 @@ When a roadmap item gets prioritized, document the why in a new ADR and link fro - [ADR-004](adr/ADR-004-deployment-topology.md) - Deployment topology (per-site) - [ADR-005](adr/ADR-005-equipment-vs-measuringtools.md) - Equipment vs measuringtools - [ADR-006](adr/ADR-006-collector-contract.md) - Collector contract pattern +- [ADR-007](adr/ADR-007-product-versioning-and-releases.md) - Product versioning and releases +- [ADR-008](adr/ADR-008-plugin-migration-ownership.md) - Plugin migration ownership (per-plugin chains) +- [ADR-009](adr/ADR-009-frontend-plugin-gating.md) - Frontend plugin route gating +- [ADR-010](adr/ADR-010-frontend-plugin-hooks.md) - Frontend plugin hook contract +- [ADR-011](adr/ADR-011-machines-rename.md) - Machines rename + modeltypes retyping +- [ADR-012](adr/ADR-012-geenforce-manifest-ownership.md) - GE-Enforce manifest ownership