Open questions
1 open 5 parked in spec 1 dismissedEvery question a meeting raised that wasn't decided in the moment. Open — still waiting on someone to decide. Parked in spec — logged into a module's "## Open Questions" section as a placeholder. Click any row to jump back to its source meeting where you can resolve it with an answer that gets written into the spec.
? The team has flagged an unresolved question about the intended delivery surfaces for the form builder and e-signature capture. John Ervin Ceriola noted that e-signature lends itself to the tablet surface; Elvina indicated that clarification is needed from Harry on whether the form builder is tablet-only or also covers the web portal and patient mobile app. This needs to be resolved before the tablet design can be finalised ahead of the April pilot.
Rationale: Elvina stated: 'I need clarification — if some mobile, but if some web app or some… I need clarification.' John noted: 'I like the tablet, especially my signature, mostly.' The surface scope for the form builder is treated as undecided in the meeting and is not explicitly resolved in the existing spec beyond the three surfaces already defined (web portal §5.1, Surgery Tablet §5.2, patient mobile app §5.3).
? The team discussed whether the aftercare template builder should have a bespoke drag-and-drop layout design or whether it can reuse existing block/component library elements from the forms surface. Harry confirmed templates should be clonable and editable, but the design approach (full drag-and-drop builder vs component reuse) was not formally resolved. Needs confirmation before Elvina begins detailed aftercare template design.
Rationale: Elvina asked: 'I just need to clarify if the one I'll create will be in just in view form or do I need to create this… this drag and drop feature.' Harry's response indicated component reuse is acceptable for MVP but left the exact design pattern open.
? Harry stated that aftercare content 'could be anything — a video, pictures' and that 'the more rich we can make that, the better', with a preference to 'just do it now'. However, it was not formally confirmed whether video and image block support is in scope for the MVP aftercare template or deferred. This has implications for the content block schema and Document Hub storage requirements.
Rationale: Harry Leak: 'Aftercare could be a video, it could be pictures… if a patient on their phone wants to visually see what to do and there's a nice explainer video, that'll be better.' Elvina agreed but the MVP/post-MVP boundary was not explicitly drawn.
? The tablet day view was discussed as a strict, flat day view — no morning/midday/evening time-segment controls. Today's date should appear prominently in the header (e.g. 'Wednesday 16 April') with prev/next day navigation buttons on either side, allowing nurses and managers to look ahead to the following day's work. Should the existing segment-based design be replaced entirely, or retained as an optional toggle?
Rationale: Harry stated: 'maybe just keep this as strictly like a day view… and then you can flick between checklists and the work package details' and 'it should say today's date… they have a button either side to flick between the two days, so maybe just put that in the header.'
? The left-hand navigation structure for the Task Manager module in the web portal has not been standardised. The meeting identified inconsistency across prototype screens (e.g. 'Task categories', 'Governance dashboard', 'My Task Overview', 'List view', 'Kanban view', 'Calendar', 'SLA', 'Templates'). A definitive navigation map — identifying which items are top-level menu entries versus sub-menu entries under 'Tasks', and which items are deferred to a later phase — must be agreed between Harry and Elvina before UX design is finalised.
Rationale: Elvina: 'what is our final left navigation or is it per user type?' Harry acknowledged the inconsistency was due to AI prototype artefacts and agreed it needed to be resolved. Neither party agreed a final structure during this session.
? Should the 1-hour notification snooze be modelled as a first-class `NotificationMute` artefact (with `UserId`, `ExpiresAt`, `CreatedAt`, `AuditTrail`) to satisfy the audit-logging requirement, or is it sufficient to store it as a transient field on the user session? The audit requirement (mute activation and expiry must be logged) suggests a persistent record is needed.
Rationale: The meeting decided mutes must be audit-logged (Harry specified this) but the data model for doing so was not discussed.