generated from john/python-template
87 lines
3.2 KiB
Markdown
87 lines
3.2 KiB
Markdown
# Roadmap Plan (Starting at V6.0)
|
|
|
|
This roadmap starts at **V6.0** and tracks forward-looking work only.
|
|
|
|
## V6.0 - Hosting Migration
|
|
|
|
Objective: move from local-only operation to secure, stable remote hosting.
|
|
|
|
### Scope
|
|
1. Containerize app runtime for production deployment.
|
|
2. Run PostgreSQL in Docker and migrate from SQLite.
|
|
3. Add Cloudflare Tunnel exposure with Access protection.
|
|
4. Add operational safeguards (health checks, restart policies, backups).
|
|
|
|
### Deliverables
|
|
- Production-ready `docker-compose` deployment for app + database + tunnel.
|
|
- Environment-based configuration for DB, uploads, prompts, and logging.
|
|
- Verified data migration path into PostgreSQL.
|
|
- Runbook updates for deploy, rollback, and backup/restore.
|
|
|
|
### Exit Criteria
|
|
- `/healthz` reports healthy app and worker in deployed environment.
|
|
- One end-to-end document -> source -> job workflow succeeds remotely.
|
|
- Backup and restore procedure is tested.
|
|
|
|
## V6.1 - Reporting Features
|
|
|
|
Objective: improve research value with person-centric outputs.
|
|
|
|
### Scope
|
|
1. Person timeline views using document dates and linked records.
|
|
2. AI-assisted biography/family-history generation from curated sources.
|
|
3. Exportable report views (human-readable, print-oriented).
|
|
|
|
### Deliverables
|
|
- Timeline UI and service queries with clear ordering/filters.
|
|
- Prompted narrative generation workflow using existing evidence-safe patterns.
|
|
- Saved/printable report presentation for review and sharing.
|
|
|
|
### Exit Criteria
|
|
- Timelines are reproducible from persisted records.
|
|
- Narrative generation is traceable to source records and prompts.
|
|
- Reports can be reviewed without modifying archival source data.
|
|
|
|
## V6.2 - Access Control and Multi-User Readiness
|
|
|
|
Objective: prepare for managed collaboration beyond single-user operation.
|
|
|
|
### Scope
|
|
1. Introduce application-level authentication.
|
|
2. Add role-based authorization (admin/editor/contributor/viewer).
|
|
3. Add audit visibility for user-attributed write actions.
|
|
|
|
### Deliverables
|
|
- User identity model and login/session flow.
|
|
- Route/page/service authorization enforcement.
|
|
- Audit metadata for sensitive create/update/delete workflows.
|
|
|
|
### Exit Criteria
|
|
- Unauthorized operations are blocked consistently across UI/API.
|
|
- Role policies are enforced by deterministic tests.
|
|
- User-attributed changes are visible for audit/review.
|
|
|
|
## V6.3 - Scalability and Multi-Tenant Direction (Optional)
|
|
|
|
Objective: keep architecture ready for broader deployment footprints.
|
|
|
|
### Scope
|
|
1. Evaluate per-tenant or per-user data partitioning strategy.
|
|
2. Formalize connection/runtime strategy for tenant-aware DB selection.
|
|
3. Expand operational telemetry for throughput and cost monitoring.
|
|
|
|
### Deliverables
|
|
- Decision document for tenancy model and migration strategy.
|
|
- Prototype-safe runtime boundary for selecting data targets.
|
|
- Monitoring baseline for queue depth, job latency, and provider cost trends.
|
|
|
|
### Exit Criteria
|
|
- Selected tenancy strategy is documented and testable.
|
|
- Operational metrics support capacity planning.
|
|
|
|
## Planning Notes
|
|
|
|
- Keep architecture, schema, and UI contracts synchronized in `docs/` as each version lands.
|
|
- Prefer explicit schema migration over runtime compatibility write paths.
|
|
- Preserve evidence/provenance guarantees when adding new AI-powered features.
|