48d3160bc5
The equipment plugin is now the machines plugin, ending the UI-vs-code vocabulary split while the contract is pre-1.0 and nothing external depends on the old names. - plugins/equipment -> plugins/machines: manifest, class, /api/machines, machines.* permissions, registry key (with an auto-migrating load shim for existing installs). - Tables: equipment -> machines (equipmentid -> machineid) and equipmenttypes -> machinetypes, renamed in the plugin's own migration chain (machines0002rename), idempotent for both upgrading and fresh installs. - The legacy core machinetypes lookup actually types the vendor MODELS catalog, so it is renamed losslessly to modeltypes (models.modeltypeid, /api/modeltypes, Model Types settings page) rather than collapsed, freeing the machinetypes name. Core migration 7d17_machines_rename also flips data in place: assettypes row equipment -> machine, auditlog entitytype, identifier_/search_ settings keys, permission rows, and renames alembic_version_equipment. - Frontend: machinesApi/modeltypesApi, item.machine response shape, assettype value compares 'equipment' -> 'machine' (map, search, custom fields, relationships), routes machines.js with plugin gating retagged, /print/machine-badge, Machine Types (subtypes) and Model Types (catalog) settings pages, machines-by-type report id. - Docs swept; ADRs left as history per the authoring rule. Upgrade: flask db upgrade then flask plugin upgrade-all. Verified: dev DB flipped live (262 machines, 35 modeltypes, 95 models retyped, zero equipment tables remain); fresh scratch-MySQL install produces the new names; 341 tests green; naming/style green; frontend builds; live E2E on machines list/detail, PC relationships, map, reports, and both settings pages. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
66 lines
5.6 KiB
Markdown
66 lines
5.6 KiB
Markdown
# 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.
|
|
|
|
## Phase status
|
|
|
|
| Phase | Status | Commit |
|
|
|-------|--------|--------|
|
|
| 0 - Lock platform contract, naming, style enforcement | DONE | `d6725c0` |
|
|
| 1 - pytest baseline, production hardening, pinned requirements | DONE | `2d1bb83` |
|
|
| 2 - Plugin contract surface and compliance tests | DONE | `5fefb53` |
|
|
| 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 |
|
|
|
|
## What's left before tagging 1.0.0
|
|
|
|
### Must-have
|
|
|
|
- **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.
|
|
|
|
### 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).
|
|
- 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.
|
|
- Calibration cycles, maintenance windows, downtime tracking (domain extensions; would likely live in the `machines` and `measuringtools` plugins).
|
|
|
|
### Deferred (out of scope for 1.0)
|
|
|
|
- Multi-tenancy (rejected by ADR-004; revisit only if more than five sites adopt and operational overhead becomes painful).
|
|
- Pip-installable plugins (deferred per ADR-003 v2). Filesystem distribution stays the v1 model.
|
|
- Event bus on `BasePlugin` (removed per ADR-001; add via new ADR if a real use case appears).
|
|
- Frontend rebuild beyond Vue 3 + Pinia + Vite (the existing stack is fine).
|
|
|
|
## What 1.0.0 means
|
|
|
|
Tagging `1.0.0` is a commitment that the contract surface is stable for at least the next minor version cycle. Plugin authors at sister sites can pin `core_version: ">=1.0.0,<2.0.0"` and trust their plugin will not break on framework patches.
|
|
|
|
Concretely, 1.0.0 ships when:
|
|
|
|
1. ADR-001's full contract surface is implemented in code, not just documented (`Asset.mapx`, `RelationshipType.propagatesthroughid`, etc.)
|
|
2. The contract test suite covers every documented hook with both happy-path and a "broken plugin" failure-isolation test
|
|
3. At least one external plugin (likely `measuringtools` from the scaffold canary) has been built end-to-end with no contract changes required mid-build
|
|
4. The deploy runbook (DEPLOY.md) has been validated by an actual fresh-host deploy
|
|
|
|
## Decision log pointers
|
|
|
|
When a roadmap item gets prioritized, document the why in a new ADR and link from this file. The ADRs are the canonical source for design decisions; this file is the prioritized backlog.
|
|
|
|
- [ADR-001](adr/ADR-001-asset-as-platform-contract.md) - Asset as platform contract
|
|
- [ADR-002](adr/ADR-002-plugin-versioning.md) - Plugin contract versioning
|
|
- [ADR-003](adr/ADR-003-plugin-distribution.md) - Plugin distribution model
|
|
- [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
|