# Backlog and release plan draft

Draft v0.5 · 13 October 2026 · Priorities revised for the self-guided portfolio demo. Relative sizes are estimates, not a delivery commitment.

## Full company-oriented POC reference backlog

This baseline preserves the broader functional POC described by FR01-FR14. Priorities below are proposed for that hypothetical POC, not confirmed company decisions. POC IDs distinguish this scope from portfolio BL items. The full POC is not complete; R1 subset implementation is recorded below.

| POC item | Full POC scope | Proposed POC priority | Portfolio coverage |
|---|---|---|---|
| POC01 | Roles, ownership policies and independent permissions | Must | BL01, BL15; BL18 adds portfolio visitor isolation |
| POC02 | Preferences, template matching, plan proposal and acceptance/decline | Must | BL02 |
| POC03 | Manual activity create/read/update/delete and provenance | Must | BL03 Must; BL14 Should |
| POC04 | Simulated import, coverage, deduplication and overlap handling | Must | BL04 Should; R1 uses seeded coverage for the missing-data scenario |
| POC05 | Check-in and deterministic weekly review | Must | BL05 for R1; import-related coverage depends on BL04 |
| POC06 | Explicit support requests, status and coach queue | Must | BL06 |
| POC07 | Coach adjustment and member acceptance with version checks | Must | BL07 |
| POC08 | Pause/resume/withdrawal and optional-permission revocation, including races | Must | BL08 Should; coaching revocation BL15 Must; import revocation accompanies BL04 |
| POC09 | Decision trace and defined programme delivery measures | Must | Trace BL09 Must; aggregates BL16 Could |
| POC10 | Role screens, accessibility and repeatable POC fixtures | Must | BL10 and BL18; company language requirements remain to be confirmed |

Additional health pathways, live wearables and incentives are outside this full activity-support POC baseline. They are possible separate initiatives, not automatically part of a company POC or production release. Portfolio publication and AI-assisted delivery evidence (BL17, BL19) serve the job-search goal.

## Portfolio R1 goal and priority definitions

Release R1 lets an employer open one public link, understand the case, and independently follow Camille from plan agreement through difficulty, an explicit support request, a coach proposal, member acceptance and an analyst decision trace. The interface defaults to English with a Belgian Dutch (`nl-BE`) switch.

Must means required before sharing R1 as the completed portfolio demo. Should means a useful follow-up, but not an R1 release blocker. Could means an optional extension. Deferred means outside the selected demo. These priorities describe delivery order, not implementation status or validated CM/MC requirements.

Existing FR, US, BR and TC identifiers remain valid. Where a backlog item is narrowed, its remaining behavior is retained in a separate item below. This release plan records the new scope; the detailed FA documents retain the broader POC reference scope. Add R1 coverage annotations and portfolio-specific requirements before affected implementation tickets are ready; do not delete full POC requirements to match the demo.

## Portfolio R1 prioritized backlog

| Item | Story or requirement | Scope | Priority | Relative size | Dependencies |
|---|---|---|---|---|---|
| BL01 | US02; FR02; NFR01 | Seeded member, assigned coach and analyst sessions; server ownership checks; independent optional permissions default off | Must | M | None |
| BL02 | US01; FR01, FR03, FR04 | Preferences, supported template matching, proposal, acceptance and decline; explicit unsupported result | Must | M | BL01 |
| BL03 | US03; FR05 | Create and display manual activity with provenance and validation; corrections and deletion move to BL14 | Must | S | BL02 |
| BL04 | US03; FR06 | Simulated import processing, coverage, deduplication, partial errors and overlap handling | Should | M | BL01, BL03, BL15 |
| BL05 | US04; FR07, FR08 | Check-in and deterministic review from manual records or seeded coverage; difficult and incomplete-data outcomes remain distinct | Must | M | BL02, BL03 |
| BL06 | US05; FR09 | Explicit member request, sharing prerequisite, duplicate-request protection, assigned-coach queue and visible status | Must | M | BL01, BL05 |
| BL07 | US06; FR10 | Coach adjustment and member accept/decline; immutable accepted versions, stale-version rejection and preserved history | Must | M | BL02, BL06 |
| BL08 | US07; FR11 | Pause, resume, withdrawal and suppression of queued reviews; coaching revocation is separated into BL15 | Should | M | BL05, BL06, BL07 |
| BL09 | US08; FR12 | Pseudonymous analyst decision trace with rule, input categories, outcome and template/version references; aggregate measures move to BL16 | Must | S | BL05 |
| BL10 | Portfolio interaction; NFR04, NFR05, NFR09 | Responsive role screens, EN/nl-BE copy and guidance, clear primary actions, explained unavailable actions, next-step feedback, role handoffs, free exploration and deterministic reset | Must | M | Incremental with BL01-BL03, BL05-BL07, BL09, BL15, BL18 |
| BL11 | US01 | Additional sleep or nutrition pathway | Deferred | L | Specialist and product review |
| BL12 | US03 | Real wearable integration | Deferred | L | Provider and privacy decisions |
| BL13 | US08 | Incentive programme | Deferred | L | Business and fairness review |
| BL14 | US03; FR05 | Correct and delete manual activities, preserve audit evidence and explicitly recalculate affected reviews | Should | S | BL03, BL05 |
| BL15 | US02, US07; FR14; BR14-BR16 | Revoke coaching sharing; block subsequent protected coach reads/writes, cancel unresolved requests and recheck permission for any queued protected work | Must | M | BL01, BL06, BL07 |
| BL16 | US08; FR13 | Aggregate programme delivery measures, cohort/timeframe definitions, missing-data counts and zero-denominator handling | Could | M | BL05, BL06, BL07 |
| BL17 | Portfolio entry and publication | English case page linking the demo, FA artifacts, source and actual test evidence; persistent public HTTPS URL and explicit fictional-case status | Must | M | BL10, BL18, BL19, BL20 |
| BL18 | Demo session and reset | Separate state for each visitor; server-scoped role switching; reset only that visitor's data; fixed clock and reproducible scenarios | Must | M | BL01 |
| BL19 | FA and delivery evidence | BPMN process and checked UML models; DevReady tickets for R1; updated scope/contracts/traceability; executed functional and access tests; documented example of LLM use with human verification | Must | M | Incremental with R1 implementation |
| BL20 | VPS setup and deployment | Inspect and configure the new VPS from scratch: secure access, Node.js, PostgreSQL, systemd, Caddy/HTTPS, firewall, backup/restore and public deployment; no Docker | Must | M | Local-first acceptance gate passed; VPS OS/access and domain decisions |

## Agreed R1 stack and separate VPS task

Next.js App Router + TypeScript, Tailwind CSS, next-intl (EN/nl-BE), PostgreSQL through pg and versioned SQL migrations, Vitest and Playwright. See architecture 10 and handoff 19. Node.js, PostgreSQL, systemd and Caddy are installed directly on the VPS; Docker/Compose are excluded.

BL20 is required for a publicly shared R1 and starts only after the local-first acceptance gate in handoff 19 passes. Local development uses local PostgreSQL, not the VPS database. Complete the R1 Must journey, tests, persistence checks and production-mode startup locally before configuring the server. Preparing the case page under BL17 precedes deployment; BL17's publication acceptance completes after BL20. VPS OS/version, access and domain are inputs to that separate task, not assumed available now. No server has been configured.

BL18 and BL01 are designed together: demo access requires no account registration, while server authorization remains enforced. BL10 uses BL18's isolated reset rather than resetting a shared database.

BL05 does not depend on implementing BL04. Jules's incomplete-coverage fixture demonstrates the missing-data rule without claiming a working import integration. The active repeat-operation scenario in R1 is retrying a support request. Import-event deduplication remains a Should extension with BL04.

BL15 is mandatory whenever coaching is exposed. If BL04 is implemented, its import-permission revocation and commit-time checks (FR14, TC21) become mandatory for that feature too. Deferring import does not authorize bypassing its access controls later.

## Demonstration slices

1. Foundation: isolated visitor session, seeded roles, permissions and reproducible reset.
2. Plan agreement: preferences, proposal, acceptance or decline and a manual activity.
3. Main Camille journey: difficult check-in, explicit support request, coach proposal, member acceptance and the related analyst trace.
4. Independent exploration: explain each next action, switch roles with context, inspect results, change EN/nl-BE and restart without affecting others.
5. Technical evidence: load Jules's incomplete-data scenario; retry support creation; attempt a stale plan change; revoke coaching sharing and verify protected access is denied.
6. Portfolio publication: case page, accessible FA artifacts, DevReady ticket examples, source, actual verification results and a stable public URL.

Should/Could work follows the complete R1 journey. Additional topics, integrations and dashboards must not displace the selected scenario or its access controls.

## R1 acceptance gates

- A first-time visitor completes the main scenario without spoken instructions. Visible guidance identifies the next action and explains its result.
- A coach proposal leaves the active plan unchanged until member acceptance. Decline and stale acceptance preserve the current version.
- A difficult check-in alone creates no request. Retrying request creation leaves one unresolved request.
- Incomplete coverage produces a data-quality explanation, not an assertion of inactivity or an adherence percentage.
- Server checks reject cross-member/unassigned-coach access and analyst access to personal notes. Revoked coaching sharing blocks protected actions.
- EN and nl-BE cover all implemented role screens, guidance, validation and error states. Switching languages preserves progress and does not change business-rule behavior.
- Two visitors have independent data. Reset restores only the initiating visitor's fixed-clock fixtures.
- The main journey supports keyboard use and a 360 px viewport; synthetic-data labels remain visible.
- The public case page distinguishes implemented, planned and simulated behavior. Source and FA links resolve; test results describe actual execution.

These gates must be mapped to explicit requirements and test cases before the relevant tickets are implementation-ready. No passed result is asserted here.

## Definition of ready

An item has a requirement or portfolio acceptance ID, acceptance criteria, known rule precedence, input/output shape, necessary fixtures and at least one failure scenario. Dependencies and unresolved decisions are visible. R1-specific sessions/reset, guidance and locale behavior need updated contracts and test cases. Clinical or real-data dependencies cannot be silently treated as resolved.

## Definition of done

Implemented acceptance behavior is demonstrated. Automated tests cover important rules and transactions; server access checks pass; manual checks cover guidance, keyboard use and translations. Changed contracts, fixtures and traceability are updated. Actual test evidence records the build and results. The visitor reset restores known fixtures, and the public URL works outside the developer's machine. A screenshot alone does not prove a backend rule.

## Current release status

Local R1 application and automated tests are implemented. See ../verification.md for actual results and remaining acceptance limits. BL01-BL03, BL05-BL07, BL09-BL10, BL15 and BL18 have local implementations; BL17/BL19 have local case/evidence artifacts. BL20 and public publication remain pending. Should/Could items and the full POC remain planned; no public release is claimed.