5de3fe4b40
Evaluated a Password-Pusher-style service as a Tech Tool and tabled it. The note carries the decisions rather than just the idea, because those are what cost the time: it is NOT a Tools-plugin candidate as it stands (that plugin is browser only by design, with get_blueprint and get_models both empty), the sender must always be authenticated, a FILE recipient should be logged in too - which costs nothing on an intranet-only server where anyone who can resolve the link already has an account - and zero-knowledge encryption is right for a credential but questionable for a controlled document, where a server that cannot say what was shared is a liability rather than a feature. Intranet-only hosting is what makes the idea viable at all: a link mailed outside is dead and no ciphertext reaches a third party. Pointing staff at the public hosted instance instead would reinstate every problem this avoids.
84 lines
6.7 KiB
Markdown
84 lines
6.7 KiB
Markdown
# Roadmap
|
|
|
|
shopdb-flask is pre-1.0 on both series. Current contract and product versions are in [PROJECT-MAP.md](PROJECT-MAP.md), which is generated from the code rather than typed here. 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) | 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
|
|
|
|
### Must-have
|
|
|
|
- **Asset model fully wired**. `Asset.mapx, Asset.mapy` columns, `AssetRelationship.inheritsposition` column, and the `relationshiptypepropagations` M:N table (`RelationshipTypePropagation` model; propagation lives on `RelationshipType`, not `AssetRelationship`). 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/`. Per ADR-001, only `category='Equipment' AND machinenumber IS NOT NULL` migrates.
|
|
- **Printers retirement**. The printers plugin already runs on the asset architecture (blueprint `printers_asset_bp`); any remaining legacy printer-table cleanup is coordinated with the equipment migration.
|
|
- **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
|
|
|
|
- **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.
|
|
- 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).
|
|
- Secret and file sharing as a Tech Tool (tabled 2026-08-21). A one-view,
|
|
expiring link for handing someone a credential, in place of a chat message or
|
|
a sticky note. NOT a Tools-plugin candidate as it stands: that plugin is
|
|
browser-only by design (`get_blueprint` and `get_models` are both empty) and
|
|
this needs storage, expiry and an audit trail, so it would be its own plugin.
|
|
Decisions already reached, to save rediscovering them: the sender is always
|
|
authenticated; a FILE recipient should be logged in too, which costs nothing
|
|
on an intranet-only server where everyone with the link already has an
|
|
account; separate permissions for sharing a secret and sharing a file, because
|
|
the risk classes differ; and zero-knowledge encryption is right for a
|
|
credential but questionable for a controlled document, where "the server
|
|
cannot say what was in it" is a liability rather than a feature. Export
|
|
control should confirm internal link sharing in writing before it carries
|
|
drawings or NC programs.
|
|
|
|
## 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
|
|
- [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
|