shopdb-flask/docs/ROADMAP.md

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 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 - Asset as platform contract
• ADR-002 - Plugin contract versioning
• ADR-003 - Plugin distribution model
• ADR-004 - Deployment topology (per-site)
• ADR-005 - Equipment vs measuringtools
• ADR-006 - Collector contract pattern