Skip to content

Execution Plan

Last updated: 2026-04-06 14:30 EDT

This replaces the old schedule with a traceable, checkbox-driven execution plan. Primary near-term objective is pregnancy-specific requirement integration with safe runtime behavior on real G7 + DASH hardware.

Planning Document Ownership

  • Docs/Planning/ExecutionPlan.md is the source of truth for priorities, sequencing, and checkbox status.
  • Docs/Planning/DevChangePlan.md captures intended code locations, implementation notes, and behavior contracts.
  • Update both when scope shifts, but keep action-status tracking only in this file.

Working Constraints

  • Closed-loop guardrail: algorithm-driven dosing only (no manual bolus controls in study mode).
  • IDE-quality documentation target: prepare a handoff-ready final draft package with complete metadata; formal review, approval, and release handling are owned by the receiving quality / submission team.

Done Criteria

A work item is only considered done when all are true: - Code is implemented. - Relevant tests are added/updated and executed. - Related docs are updated (Architecture, Requirements, Docs/Quality/RiskAnalysis.md, Docs/Quality/* trace docs).

How To Use This Plan

  • This file is the only checklist tracker. If an item has a checkbox, status lives here.
  • Docs/Planning/DevChangePlan.md holds implementation detail and code-location notes only.
  • Any completed workstream item must link to requirement/design/verification updates in Docs/Quality/* before closure.
  • Operator condensed view lives in Docs/Planning/NextSprintChecklist.md (derived from this file, not authoritative).

Active Focus Snapshot

  • O IDE software handoff package (new): IN PROGRESS
  • K Clinical Settings lock-down (new): IN PROGRESS
  • A Pregnancy requirement parameterization: IN PROGRESS
  • L Algo2015 full verification campaign (new): IN PROGRESS
  • B Runtime reliability on hardware: IN PROGRESS
  • F5 UI verification and traceability: IN PROGRESS
  • M Reinstall continuity (Pod + algorithm state): PLANNED
  • N Swift code quality standardization: IN PROGRESS

Workstream O: IDE Software Handoff Package (This Week)

Reference detail: - Docs/Quality/IDE_Submission_Readiness_Report.md - Docs/Quality/IDE_Baseline_Freeze_Plan.md - Docs/Quality/IDE_Submission_Closure_Checklist.md - Docs/Planning/IDE_Software_Scoping_Plan.md

Intent: - prepare the engineering-owned software package only - keep the packet focused on the current IDE scope and do not force broader closure on support material unless it is truly in scope - do not expand this week into full downstream quality/release closure work that belongs to the receiving quality / submission team

O1. Scope and ownership lock

  • [x] Publish the engineering-owned software document set and explicit non-owned downstream quality activities.
  • [x] Lock current package assumption:
  • app/runtime/algorithm/device software docs and software verification are in scope
  • cloud / Part 11 / final release approval remain deferred unless explicitly pulled back in
  • [x] Produce an explicit deferred-items list with owner, rationale, and next-decision target for out-of-scope items.

O2. Controlled software document normalization

  • [x] Move the core software docs from Draft v0.1 to handoff-ready final-draft / pending-review metadata state:
  • RiskAnalysis.md
  • SoftwareRequirementsSpecification.md
  • SoftwareDesignDescription.md
  • SoftwareVerificationAndValidationPlan.md
  • TraceabilityMatrix.md
  • CybersecurityPlan.md
  • DevelopmentSOP.md
  • Docs/Quality/STP/*.md
  • [x] Add revision-history and reviewer/approver placeholder metadata needed for downstream quality handling.
  • [x] Ensure the software doc set references the same package scope and handoff boundary.
  • [ ] Fill final baseline freeze SHA consistently at actual freeze time.

O3. Requirement and scope disposition

  • [x] Disposition SRS-BG-008 for the current software package.
  • [x] Disposition SRS-MEAL-004 for the current software package.
  • [x] Disposition SRS-CLIN-002 as an investigational software control with explicit transition note.
  • [x] Decide whether SRS-SEC-003..009 stay in this week's software handoff set or are explicitly deferred with rationale.
  • [x] Remove unresolved wording from in-scope controlled software statements or replace it with explicit deferred / out-of-scope language.

O4. Verification package readiness

  • [x] Promote Docs/Quality/STP/ from initial draft set to handoff-ready software protocol package.
  • [x] Confirm each in-scope TV-* row has one owning STP-* path or an explicit deferred disposition.
  • [x] Create a cybersecurity handoff register for inherited controls, local controls, provenance gaps, and missing software-package artifacts.
  • [x] Add supporting cybersecurity review notes for embedded-package provenance and the current file/permission surface.
  • [x] Add a dependency-inventory snapshot for the current software/cyber handoff package.
  • [x] Add dependency/SBOM freeze-time process notes for the software handoff package.
  • [x] Add a focused logging/secret-redaction review note for the current auth/network/telemetry surfaces.
  • [x] Add a supplier-artifact request list for remaining inherited DASH/G7/Dexcom-app evidence asks.
  • [x] Add an engineering baseline-acceptability recommendation for the current local export/file-sharing/logging posture.
  • [x] Add a curated security-relevant local-delta review for embedded LoopKit, G7SensorKit, and OmniBLE packages.
  • [x] Add a freeze-execution checklist for formal TV-SEC-001 evidence promotion.
  • [x] Audit RTM evidence rows into:
  • formal evidence already available
  • rerun/promote needed
  • deferred from this package
  • [ ] Keep Docs/Quality/Evidence/Working/ as support-only and stop using it as claimed closure evidence in handoff language.

O5. Handoff assembly

  • [x] Produce a software package index with exact included documents and package boundary.
  • [x] Produce a current handoff summary package using:
  • IDE_Submission_Readiness_Report.md
  • IDE_Software_Handoff_Disposition_Log.md
  • IDE_Software_Handoff_Index.md
  • [x] Create a dedicated IDE software packet folder with concise summary docs and use it as the default reviewer entry point.
  • [ ] Fill final baseline SHA in the package manifest at freeze time.
  • [x] Produce a one-page handoff memo summarizing:
  • software docs included
  • open decisions
  • deferred items
  • rerun-needed evidence
  • [x] Produce the formal evidence execution plan by protocol for the current packet freeze.
  • [ ] Update the IDE readiness docs to reflect software handoff prepared status once the above items are complete.

Workstream K: Clinical Settings Hardening (Current Focus)

Reference detail: Docs/Planning/DevChangePlan.md -> Clinical Settings (Planned) section. Field/mapping contract: Docs/Planning/ClinicalAlgorithmConfigContract.md (see Design Options (Pregnancy Protocol) and Phased Implementation Checklist sections).

K1. Scope lock and defaults

  • [x] Lock clinical settings field list and defaults:
  • passcode gate default 020508 (investigational control)
  • Subject ID
  • Weight entry in lbs (integer UI), stored as kg for algorithm
  • Start Algo / Reset Algo
  • target selector 90...130 mg/dL in increments of 10
  • meal upfront selector 75% or 90%
  • TMAX selector 40...70 in increments of 5
  • [x] Confirm temporary passcode policy language and limitation notes (non-production control; Cognito/role auth planned in Workstream I).

K2. Settings IA and gating UX

  • [x] Add a clinician-only Clinical Settings section in settings.
  • [x] Gate entry with passcode prompt and clear failure messaging.
  • [x] Move Subject ID, Weight, Start Algo, and Reset Algo from general settings into Clinical Settings.
  • Start Algo is exposed on the locked clinical screen only while no algorithm session is active; Reset Algo remains unlock-protected.
  • [x] Preserve participant-facing setup/settings paths outside clinician-only controls.
  • [x] Add clinician-controlled participant target-access profile (Pregnancy / Standard) to Clinical Settings.
  • [x] Add participant-facing target selector constrained to the active clinician-selected profile.
  • [x] Require approval capture (staff name + approximate approval time) before participant-facing target changes apply.
  • [x] Constrain the clinician target selector to the active profile and normalize draft target selection when the clinician switches profiles.

K3. Persistence and runtime mapping

  • [x] Add versioned persistence model for clinical settings with safe defaults/migration.
  • [x] Convert lbs->kg on save/read for algorithm input use.
  • [x] Wire target/upfront/TMAX selections into runtime algorithm-configuration path.
  • [x] Confirm fallback behavior when values are unset or invalid.
  • [x] Add draft-vs-applied settings flow (edits remain draft until explicit save confirmation).
  • [x] Add Save review confirmation (OK/Cancel) showing old -> new values before applying.
  • [x] Do not trigger doWork on save; runtime consumes saved changes on the next algorithm step only.

K4. Validation and safety checks

  • [x] Enforce UI bounds and step increments for each selector.
  • [x] Keep Start/Reset behavior unchanged after relocation.
  • [x] Ensure reset path does not wipe non-reset clinical settings unexpectedly.

K5. Verification and traceability

  • [x] Add unit tests for validation, conversion, and persistence migration.
  • [x] Add unit tests for clinical passcode + selector normalization policy.
  • [x] Add UI tests for passcode gate, unlock failure/success, and moved control visibility.
  • [x] Update quality trace docs (SRS, SDD, SVVP, RTM) for Clinical Settings and pregnancy-parameter controls.
  • [x] Add tests proving save/apply semantics: no runtime change before Save+OK; Cancel preserves prior applied config; new config takes effect on next step.
  • [x] Add telemetry coverage for settings-change flow:
  • ui.critical.state_viewed when review sheet opens
  • ui.critical.submit on Save+OK with old/new values + changed fields
  • ui.critical.cancel when review is dismissed/cancelled
  • ui.critical.blocked when save is invalid/blocked
  • [x] Add telemetry coverage for participant target governance:
  • approval sheet state_viewed / submit / cancel / blocked
  • [x] Ensure loop.step.executed payload includes the applied clinical config snapshot (target_mgdl, meal_upfront_percent, tmax_minutes) to prove when saved changes became active.

Workstream A: Pregnancy Requirements Integration

A1. Algorithm parameterization for pregnancy mode

  • [x] Confirm final pregnancy configuration constants with algorithm owner:
  • targets 90...130 in 10 increments
  • meal upfront % options 75/90
  • TMAX range 40...70 in 5 increments
  • [x] Implement target/upfront/TMAX support end-to-end in runtime + algorithm path (current UI source is existing Home settings; migration to clinician-gated section tracked in Workstream K).
  • [x] Implement bridge/C++ + core-algorithm support for meal-upfront (75/90) and TMAX (40...70, step 5), including deterministic normalization defaults.
  • [x] Implement C++ set-point support for 90 mg/dL target option (remove legacy lower clamp that blocked effective 90 operation).
  • [x] Add focused safety audit for set-point internals when enabling 90:
  • SetPtL, SetPt/SetPts clamp path
  • SetPtDesign dependent calculations
  • any guardrails assuming minimum setpoint 100
  • [x] Verify meal-controller behavior for both configured upfront modes (75% and 90%) in algorithm path.
  • [x] Verify insulin concentration and delivery quantum constants against DASH operational limits and study insulin assumptions.
  • [x] Add requirement IDs and test coverage links in Docs/Quality/SoftwareRequirementsSpecification.md and Docs/Quality/TraceabilityMatrix.md.

A2. Input parity and degraded-mode behavior

  • [x] Complete Marjorie parity slice for required input fields (including unavailable sentinels where intended), with per-step telemetry/CSV capture for runtime-applied pregnancy config fields (TMAX, meal-upfront).
  • [x] Add explicit BG/fingerstick fallback path requirements and implementation decision (in scope this phase).
  • [x] Define BG entry mapping into algorithm BGval and persistence/expiry policy for BG values used by runtime.
  • [x] Define BG-triggered doWork behavior as a separate wake cause (bgCheck) with no future-step borrowing.
  • [x] Validate CGM sanitization policy (<39 / >401 -> -1) against step-0 and step>0 behavior.
  • [x] Lock step-0 policy decision for current build: keep CGM-only gate (SRS-CGM-002 + SRS-BG-012), no BG-rescue at step 0.

A3. BG check entry path (new)

  • [x] Add Home BG-check UI flow (Enter BG) with guarded numeric entry, explicit submit, and clear validation messaging.

Workstream N: Swift Code Quality Standardization

Reference detail: Docs/Planning/SwiftCodeQualityPlan.md. Primary standard: Docs/Quality/SoftwareCodingStandard-Swift.md.

N1. Standard and policy lock

  • [x] Author Swift coding standard for app/core/test code.
  • [x] Define the non-functional-first cleanup rule for initial code-quality work.
  • [ ] Review/approve the standard and rollout policy with engineering stakeholders.

N2. Tooling decision

  • [ ] Decide formatter (SwiftFormat recommended).
  • [ ] Decide linter (SwiftLint recommended).
  • [ ] Decide app-side static-analysis lane (xcodebuild analyze recommended).
  • [ ] Decide whether unused-code analysis remains advisory-only in the initial rollout.

N3. Baseline assessment

  • [x] Add draft tooling configs in non-enforcing/report-only mode.
  • [x] Generate a baseline findings summary for app/core/test targets.
  • [ ] Classify findings into immediate-fix, warning-only, deferred, and not-applicable buckets.

N4. First cleanup pass

  • [ ] Limit first cleanup changes to non-functional formatting/readability/refactor work.
  • [ ] Require focused before/after regression runs for the impacted areas.
  • [ ] Require broader impacted-suite run after the cleanup pass.

N5. Enforcement rollout

  • [ ] Enable a conservative mandatory rule set for new/changed code.
  • [ ] Keep noisy legacy rules in warning/report-only mode until debt is reduced.
  • [ ] Define evidence/reporting expectations if the quality lane becomes part of formal verification packaging.
  • [x] On submit, trigger runtime doWork for current due step only (expectedStep), never nextStep + 1.
  • [x] Ensure BG check path is compatible with meal path but has no borrow semantics.
  • [x] Define BG freshness window for runtime use and reject stale manual BG values.
  • [x] Ensure BG source labeling is preserved in telemetry (manual BG vs CGM).

Workstream L: Algo2015 Full Verification Campaign (IDE-Critical)

Reference detail: Docs/Planning/Algo2015VerificationPlan.md.

L1. Protocol and evidence lock

  • [ ] Lock TV-ALG-001..011 protocol definitions and acceptance criteria in SVVP.
  • [ ] Define official STR artifact layout for algorithm evidence (Docs/Quality/Evidence/Formal/STR-ALG-001/...).
  • [ ] Define coverage threshold exception workflow (required rationale + risk disposition for uncovered regions).

L2. Harness and coverage tooling

  • [x] Implement instrumented Algo2015 build path for coverage collection (llvm-profdata + llvm-cov).
  • [x] Add deterministic replay harness for golden-vector scenarios and differential replay (baseline implementation in Algo2015GoldenVectorTests, including degraded/input-variant vectors).
  • [x] Add bridge-contract edge-case tests (null guards, sentinel mapping, subject-id boundaries, state handoff).

L3. Scenario and regression suite

  • [ ] Add nominal/degraded/meal/BG/pump-availability replay vectors and lock expected outputs.
  • [x] Add state continuity suite (persistence/reload/reset boundaries).
  • [x] Add pregnancy-configuration differential suite (target, meal upfront, TMAX).
  • [ ] Add long-run soak replay for step continuity and deterministic stability.
  • Implemented baseline subset:
    • nominal deterministic replay (TV-ALG-004 subset)
    • degraded/unavailable CGM replay (TV-ALG-005 subset)
    • meal/manual-BG replay (TV-ALG-006 subset)
    • persistence/reload/reset continuity replay (TV-ALG-007)
    • CGM boundary finite/safe replay (TV-ALG-008 subset)
    • target differential replay (TV-ALG-009 baseline subset)
    • TMAX + meal-upfront differential replay with deterministic applied-value assertions
    • explicit target=90 effective-setpoint replay after cpp clamp integration
    • expanded coverage harness vectors (TV-ALG-010 v7 baseline)

L4. IDE readiness closure

  • [x] Generate first complete STR package with command logs, pass/fail by TV-ALG-*, and full coverage report.
  • [x] Update RTM with concrete STR evidence link for RA-014 (Docs/Quality/Evidence/Working/STR-ALG-001/2026-02-19-tv-alg-phase-i-i6-rerun/manifest.json + evaluation-summary.json).
  • [ ] Run review pass with algorithm owner and clinical lead for acceptance of uncovered-line rationale (if any). Packet: Docs/Planning/Algo2015UncoveredBranchReviewPacket.md.

L5. Branch 100% closure campaign (post-Phase-G)

  • [ ] Execute do-now closure set (no product behavior change):
  • Directed vectors for Needs directed vectors + Sensor/pump field edge + Historical retention edge
  • Deterministic harness fault-injection for SaveData diagnostics branches
  • [ ] Track branch delta after each vector/harness increment with staged verification evidence.
  • [ ] Build decision package for gated branch groups:
  • Set_Target legacy knob path
  • ExpmtOver legacy trial path
  • constraint-implied/mutually-exclusive residual branches
  • [ ] Resolve gated branches by one of:
  • code-owner approved test seam/retirement enabling coverage closure, or
  • signed exception disposition in branch-exception-package.{json,md}.

Workstream B: Runtime Reliability on Hardware

B1. Pump/CGM restore and reconnect behavior

  • [ ] Validate recent PumpStatusObserver reconnect refresh fix on real device across app relaunch + reconnect cycles.
  • [ ] Ensure home pod card reflects true state transitions without visiting Pod settings.
  • [ ] Verify G7 manager ownership/single-manager behavior after setup + relaunch.
  • [ ] Confirm no duplicate central-manager initialization side effects in startup/setup flows.

B2. Cadence and step continuity

  • [ ] Validate anchored step cadence behavior overnight with real CGM events.
  • [ ] Validate skip/catch-up semantics after wake gaps and relaunch.
  • [ ] Verify reset semantics always create a true fresh session.
  • [ ] Validate BG-check-triggered step execution when CGM wake is missing and cadence would otherwise stall.
  • [ ] Validate BG-check-triggered step execution when CGM wake exists but CGM values are unusable for algorithm input.
  • [x] Lock reconnect-fallback policy for CGM absence:
  • only after first anchored step exists
  • only when accepted CGM receipt age exceeds approved freshness limit (current proposal: > 5 minutes)
  • current due step only
  • no step 0
  • no cadence re-anchor
  • no backlog replay
  • [x] Implement guarded reconnect-fallback wake path (secondary to CGM, not a new cadence source).
  • [x] Add unit/integration validation for reconnect-fallback gating and restored CGM priority after data resumes.
  • [ ] Add real-device validation for reconnect-fallback gating, same-slot duplicate suppression, and restored CGM priority after data resumes.

B3. Algorithm stepping interruption alerting

  • [x] Define approved interruption threshold for "no new CGM data, therefore no CGM-driven steps" and document how it relates to existing Home No CGM / Aging / Stale states.
  • [x] Reconcile runtime-stall alert timing with protocol wording for Dexcom Bluetooth interruption (> 2 hours) so operational stall messaging and protocol alerting are not conflated.
  • [x] Add a runtime-derived actionable alert for armed-loop stepping interruption when no successful algorithm step has completed beyond the approved threshold.
  • [x] Keep the stepping interruption alert distinct from G7-provided unavailable and failed/expired states.
  • [x] Define clear behavior, dedupe/debounce rules, and precedence against stronger CGM alerts.
  • [x] Add verification coverage for threshold breach, recovery clear, and no-alert cases when loop is disarmed.
  • [ ] Validate 15-minute interruption timing and clear-on-recovery behavior on real hardware/background delivery scenarios.
  • [x] Replace CGM-specific interruption alert semantics with broader Algorithm Stepping Interrupted semantics:
  • trigger when loop is armed and no successful algorithm step has occurred for >15 minutes
  • include non-CGM blockers (No Pod, signal loss, other runtime gates)
  • preserve stronger source-native CGM/pump alert precedence
  • clear on next successful step or loop disarm/reset
  • [x] Add verification for step-based alert timing, blocker-detail rendering, and clear-on-success behavior.

Workstream C: Safety and Fallback Logic

C1. Meal announce safety

  • [ ] Keep meal announce pump-ready gating explicit and tested (pump known, not delivering, borrow window valid).
  • [x] Ensure recovered current pump state reopens meal announce immediately after reconnect status recovery without waiting for another successful algorithm step, while keeping submit-time fresh pump-status gating conservative.
  • [ ] Add test coverage for all meal unavailable reasons shown in UI.
  • [ ] Keep BG-check policy explicitly separate from meal borrow policy (BG check cannot borrow future slots).
  • [x] Add initial durable meal-request lifecycle/idempotency baseline:
  • persist accepted/pending meal request state across relaunch
  • block duplicate meal entry while prior request is unresolved at relaunch/startup
  • reconcile pending meal-request state against executed-step history and reset/disarm
  • [x] Replace optimistic meal-submit success with explicit post-submit outcome handling:
  • no success UI or success telemetry before runtime result is known
  • blocked/rejected outcomes surface explicit operator guidance
  • [x] Extend meal-request lifecycle model:
  • add explicit uncertain-command-outcome state
  • block duplicate meal entry while command outcome remains uncertain, not just pending
  • reconcile uncertain pending state against pump-delivery evidence after pump attachment
  • [x] Define remaining full-resolution states (pending, accepted, success, blocked, uncertain, resolved) for cloud/UI lifecycle closure.
  • implemented baseline: persist meal flow ID with pending state
  • implemented baseline: emit correlated accepted + resolved meal lifecycle telemetry from runtime
  • implemented baseline: resolved closes immediate success, relaunch reconciliation after uncertainty, and session-reset clear paths
  • [x] Define slot-conflict policy for meal submits that lose the current due slot to CGM/reconnect:
  • implemented baseline: explicit slot_conflict blocked/retry result
  • no silent loss or silent reinterpretation of meal intent
  • [x] Add targeted verification for relaunch-safe pending meal blocking:
  • relaunch with pending meal request
  • startup reconciliation clears pending request when target step has already executed
  • [x] Extend relaunch/comms/race verification:
  • competing-trigger slot conflict handling
  • correlated meal request lifecycle telemetry
  • [x] Add active-delivery meal recovery path:
  • if meal announce opens while a bolus is already delivering, route to a destructive Cancel Delivery flow instead of allowing duplicate submit
  • show actual requested vs delivered insulin after cancellation in Home's alert-summary region above the chart, then allow the operator to reopen meal announce
  • preserve partial-delivery accounting for the next algorithm step

C2. Pump-unavailable strategy

  • [ ] Finalize and document command-block behavior while continuing algorithm step execution with unavailable pump input.
  • [ ] Decide and implement policy for prolonged comm loss fallback mode transitions.

C3. Offline fallback (proposed feature)

  • [ ] Convert proposal into formal requirements (entry criteria, max duration, user messaging, recovery behavior).
  • [ ] Define fail-safe constraints before implementation.

Workstream D: Data, Telemetry, and Visualization

D1. Step data integrity

  • [ ] Ensure per-step records include required input/output/command/reconciliation fields for review and export.
  • [ ] Validate that zero-dose steps are retained and rendered correctly in charts/scrub and step listings.
  • [ ] Confirm meal-announced doses remain distinguishable in telemetry and charts.

D2. Export/collection path

  • [ ] Keep local CSV export as development-only path only.
  • [ ] Define secure cloud telemetry upload requirements and phased migration plan.

Workstream E: Quality and Regulatory Readiness

E1. Traceability system

  • [x] Create Docs/Quality foundation (RA, SRS, SDD, SVVP, RTM, cybersecurity plan, SOP).
  • [x] Complete runtime refactor slice #1 (LoopSessionStore, LoopWorkScheduler, LoopAlertMediator, LoopTelemetryWriter, and LoopRuntimeWorkExecutor) with behavior-preserving regression tests.
  • [x] Progress Home refactor slice #2/#3 (presentation modifiers, status widget split, chart-container split, insulin-renderer extraction, reusable control extraction) with behavior-preserving regression tests.
  • [ ] Add formal scoring and acceptance criteria to quality RA register.
  • [ ] Populate RTM with concrete evidence links for each completed feature/test.
  • [ ] Create STP and STR templates for repeatable execution/reporting.

E2. Cybersecurity and compliance

  • [ ] Build initial threat model and map controls to SRS-SEC-* and RA-* IDs.
  • [ ] Define PHI/PII handling expectations for telemetry and exports.
  • [x] Add dependency/SBOM process notes for release-bound builds.

Workstream F: UI/UX (Separate Track)

F1. Information architecture and navigation

  • [ ] Define stable IA for Home, CGM, Pod, and Settings flows with reduced setup dead-ends.
  • [ ] Confirm default landing behavior for CGM and Pod modal flows (setup vs settings) based on actual manager state.
  • [x] Restore explicit startup Cancel path for CGM and Pod setup modals, including persisted-manager/no-active-pod Pod case.
  • [ ] Document navigation/state transitions for onboarding, re-onboarding, and recovery paths.
  • [ ] Clinical settings IA and gating implementation is tracked in Workstream K (do not duplicate checklist items here).

F2. Status and interaction UX

  • [ ] Finalize Home card state language set and keep wording aligned with runtime logic (SRS-UI-001, SRS-UI-002).
  • [ ] Finalize meal-announce unavailable messages and retry timing wording (SRS-MEAL-003).
  • [ ] Ensure status cards and critical controls remain readable and actionable in light/dark modes.

F3. Visual and chart UX

  • [ ] Finalize chart behavior spec (range presets, scrub behavior, edge clipping, zero-dose visibility).
  • [ ] Finalize color/contrast targets for CGM, insulin, and meal-dose overlays for light/dark modes.
  • [ ] Add visual regression checklist for major Home chart/status layouts.

F4. Input ergonomics and accessibility

  • [ ] Validate profile-entry UX (weight lbs input, clear affordance, keyboard dismissal) against SRS-VAL-001.
  • [ ] Add VoiceOver labels/traits for status cards, chart scrub pills, and critical action controls.
  • [ ] Add Dynamic Type and minimum hit-target review checklist for primary screens.

F5. UI verification and traceability

  • [ ] Add/expand UI tests for critical safety states (No CGM, No Pod, Ready, Active, Aging, Stale).
  • [ ] Add manual usability test protocol IDs and link them in Docs/Quality/TraceabilityMatrix.md.
  • [ ] Capture screenshot evidence for each clinical-facing major UI state in test reports (STR-*).
  • [ ] Apply screenshot UI review rubric on every user-facing slice (text integrity, spacing/alignment, contrast/accessibility, transition quality) and store pass/fail notes with evidence.
  • [x] Auto-cancel meal composer on app background transition and verify with automated test (TV-UI-004).
  • [x] Define and implement deterministic Xcode UI test fixtures (launch arguments/environment) for key runtime/UI states.
  • [x] Add accessibility identifiers for controls and state labels used by current UI automation scope.
  • [x] Add an automated UI smoke suite that covers navigation, setup modal dismiss/continue, settings entry, meal announce sheet open/cancel, and Alert Center entry/persistence checks.
  • [x] Add automated verification for state-driven messaging and gating text (for example meal unavailable reasons and alert-center state transitions).
  • [ ] Run UI automation in CI or pre-release gate with xcodebuild ... -only-testing:BionicLoopUITests test.
  • [ ] Define explicit UI automation boundaries (what remains manual/system-only on real hardware).

Workstream G: User Alerts and Escalation

G1. Alert source inventory and normalization

  • [x] Build canonical alert inventory for OmniBLE, G7SensorKit, algorithm/runtime, and app safety policy alerts.
  • [x] Define normalized alert model fields (source, severity, title, message, recommendedAction, timestamp, ackState, dedupeKey).
  • [x] Define source-to-normalized mapping table baseline and store in Docs/Quality/AlertInventoryAndMapping.md (linked from SDD).
  • [x] Identify which alerts are informational vs actionable vs safety-critical.

G2. Alert presentation and UX behavior

  • [ ] Define delivery channels by severity (in-app banner, blocking sheet, persistent home card state, optional local notification).
  • [x] Define and implement initial alert precedence/suppression for Home top alert (severity then recency).
  • [x] Define and implement initial debounce/coalescing for transient pump signal loss (5-minute debounce + auto-clear).
  • [ ] Define acknowledgement requirements (auto-clear vs explicit user acknowledgment).
  • [ ] Define and implement background system-notification policy for actionable/safety-critical alerts (authorization flow, throttling/coalescing, and tap-through routing).

G3. Clinical and protocol alignment

  • [ ] Map protocol-required alerts and response guidance to app alert IDs.
  • [ ] Add wording review pass for clinical readability and non-ambiguous action statements.
  • [ ] Define escalation path for unresolved critical states (including fallback mode messaging handoff).

G4. Verification and traceability

  • [x] Add SRS-ALERT-* requirements and RA-011 hazard mapping in quality docs.
  • [ ] Add complete TV-ALERT-* unit/integration/system tests for alert generation, suppression, and clearing.
  • [x] Add initial alert unit coverage for precedence and signal-loss debounce/clear behavior.
  • [ ] Add manual alert-drill test protocol (STP-ALERT-*) and evidence capture plan (STR-ALERT-*).
  • [ ] Add release checklist gate: no unresolved critical alert regressions.

Workstream H: Deterministic Simulation Harness (Mock CGM + Mock Pump)

Reference detail: Docs/Planning/MediumFidelityHarnessPlan.md.

H0. Contract and artifact lock

  • [ ] Approve medium-fidelity harness scope, non-goals, and deterministic guarantees.
  • [ ] Freeze scenario schema and versioning contract for deterministic replay.
  • [ ] Freeze STR-SIM artifact contract (scenario, expected, actual, diff, results, run-context metadata).
  • [ ] Define run-context metadata fields required for audit reproducibility.

H1. Harness core scaffold

  • [x] Implement VirtualClock with deterministic progression and no wall-clock dependency.
  • [x] Implement ScenarioRunner with deterministic event ordering and replay.
  • [x] Implement protocol-conformant MockCGMService on existing runtime ports.
  • [x] Implement protocol-conformant MockPumpService on existing runtime ports.
  • [x] Implement RuntimeProbe recorder for step execution, skip reason, algorithm I/O, command apply/block, and alert lifecycle state.
  • [x] Add deterministic harness entrypoint for local and CI runs.

H2. Campaign A (TV-SIM-001, TV-SIM-002)

  • [x] Implement cadence/anchor continuity scenarios (TV-SIM-001).
  • [x] Implement step-0 gate + step>0 degraded CGM sentinel scenarios (TV-SIM-002).
  • [x] Add deterministic assertions for expected step, executed step, and skip reason.
  • [x] Add deterministic assertions for degraded CGM input mapping behavior.

H3. Campaign B (TV-SIM-003, TV-SIM-004)

  • [x] Implement pump unavailable/unknown scenarios with command-block verification (TV-SIM-003).
  • [x] Implement meal/BG trigger interplay scenarios with missed-step/reconnect/degraded-input timing (TV-SIM-004).
  • [x] Assert no false command application while blocked states are active.

H4. Campaign C (TV-SIM-005)

  • [x] Implement alert lifecycle churn scenarios (issue/retract/precedence/dedupe).
  • [x] Validate minute-cadence updates for time-sensitive alert text in simulation outputs.
  • [x] Validate active/recent alert transitions and clear/ack behavior under churn.

H5. Evidence packaging and merge gating

  • [x] Emit STR-SIM-* artifact bundles from deterministic replay runs.
  • [x] Map scenario IDs to RA/SRS/TV trace rows in quality docs.
  • [x] Require simulation pass evidence for high-risk runtime merges.
  • [x] Use simulation output to detect false-safe/false-block states before hardware-only validation.

H6. High-fidelity emulation (eventual goal)

  • [ ] Define BLE-level emulator track for Omni/G7 transport/session behavior (timing, reconnect, ACK/failure quirks).
  • [ ] Keep high-fidelity emulation out of near-term critical path until medium-fidelity harness is stable.
  • [ ] Use high-fidelity emulation as confidence amplification for hardware-specific edge behavior not representable in medium-fidelity mocks.

Workstream I: Identity and Onboarding (Cognito)

I0. Baseline implementation (completed)

  • [x] Add secure local auth-session persistence (Keychain-backed token set storage).
  • [x] Add session-restore path on app launch that reconciles local auth state with token validity.
  • [x] Add access-token refresh behavior and one-time retry path for protected API requests on 401.
  • [x] Ensure sign-out clears both local auth state and secure persisted token session.
  • [x] Add unit coverage for sign-in token parsing, refresh behavior, session restore, and authenticated request retry.
  • [x] Add email/password recovery flow (ForgotPassword, ConfirmForgotPassword) with reset-code request, confirm reset, resend code, and unauthenticated-route UI wiring.
  • [x] Decouple auth/session state from local loop runtime lifecycle so unauthenticated state does not stop/reset therapy runtime.
  • [x] Enforce launch-time silent session-restore/refresh policy while preserving active-loop continuity via explicit unauthenticated Home bypass and persistent auth-recovery alert when restore/login is required (remote monitoring unavailable until login).

I1. Product/clinical policy decisions (required before implementation)

  • [ ] Confirm whether tester/participant authentication is required for current investigational phase, and which cohorts require sign-in.
  • [ ] Confirm accepted identity providers for onboarding: Sign in with Apple, Google, and Email (magic link vs password).
  • [ ] Confirm account model boundaries: individual user accounts vs shared team account patterns.
  • [ ] Confirm required legal/privacy content in onboarding flow (consent text, data-use disclosure, terms/privacy links).
  • [ ] Confirm deprovisioning and emergency access policy for clinical operations.

I2. Technical architecture plan

  • [ ] Define Cognito deployment model (User Pool, optional Identity Pool) and app environment split (dev, staging, prod).
  • [ ] Define token/session lifecycle rules (access-token TTL, refresh strategy, sign-out/revocation, device binding expectations).
  • [ ] Define secure backend authorization pattern for telemetry ingest and dashboard APIs (JWT validation, least-privilege scopes).
  • [ ] Define role model for future dashboards (for example clinical reviewer, engineering, admin).
  • [ ] Define failure behavior when auth provider is unavailable (safe read-only mode, retry paths, explicit user messaging).

I3. Verification and safety/privacy impact

  • [ ] Add SRS/SDD/SVVP/RTM trace rows for identity flows and authorization controls.
  • [ ] Add tests for onboarding success/failure, token expiry/revocation, and role-based access restrictions.
  • [x] Add unit coverage for password recovery request/confirm success paths against Cognito targets.
  • [ ] Verify no protected actions or data access occur without valid auth context.
  • [ ] Add cybersecurity evidence artifacts for auth configuration review and incident response.

Workstream J: AWS Telemetry, Observability, and Crash Reporting

Reference detail: Docs/Planning/TelemetryCloudIntegrationPlan.md. Backend handoff contract: Docs/Planning/TelemetryCloudContractForBionicScout.md. Execution tracker for completion + dry-runs: Docs/Planning/TelemetryCodeCompletionPlan.md.

J1. Contract lock against current cloud endpoint

  • [x] Lock app envelope to current BionicScout ingest requirements (event_type, schema_version, subject_id, created_at, payload) plus app-required correlation fields (event_id, session_id, version/build/env).
  • [x] Freeze event naming/versioning conventions for implemented event families (loop step + alert lifecycle); publish canonical examples for remaining families.
  • [x] Align app/cloud scope and auth assumptions for ingest (bionicscout.dev.api/telemetry.ingest) via authenticated API boundary reuse.

J2. Event taxonomy and source mapping

  • [x] Finalize event families:
  • app/auth lifecycle
  • loop/runtime/algorithm
  • CGM
  • pump
  • alert lifecycle
  • telemetry transport health
  • [x] Finalize payload contracts for each event type (required/optional fields and redaction rules).
  • [x] Add source mapping matrix from app components to event emitters.
  • [x] Add lifecycle timezone/clock-sync telemetry contract (device_timezone_id, UTC offset, UTC-check result/skew/rtt/timestamp) and emit reason = timezone_or_time_changed on timezone/significant-time-change triggers.

J3. Critical UI interaction telemetry (story reconstruction)

  • [x] Instrument critical controls for tap/submit/cancel/blocked/state_viewed events.
  • [x] Require flow_id for multi-step UX paths (meal announce, BG entry, setup flows).
  • [x] Ensure blocked actions include explicit reason codes suitable for support/clinical review.
  • [x] Define minimum “subject stuck” timeline completeness criteria.

J4. App reliability and delivery guarantees

  • [x] Implement persistent outbox contract (pending/inflight/acked/failed_permanent) with sequence ordering.
  • [x] Define and implement retry/backoff/jitter plus priority flush path for safety-critical events.
  • [x] Define queue caps and deterministic drop policy with drop-summary telemetry.
  • [x] Ensure telemetry failures cannot block local loop safety behavior.

J5. Cloud-side hardening and persistence

  • [x] Publish backend J5 contract-test packet (schema validation order, canonical error codes, idempotency semantics) in TelemetryCloudContractForBionicScout.md.
  • [x] Publish shared structured-inspection backend handoff note for BionicScout implementation tracking:
  • Docs/Planning/ScoutStructuredInspectionTelemetryHandoff.md
  • [ ] Add per-event schema validation by event_type + schema_version in BionicScout.
  • [ ] Add idempotent durable persistence keyed by (subject_id, event_id).
  • [ ] Add DLQ replay workflow and operational alarms.
  • [ ] Define role-scoped query path for incident timeline reconstruction.

J6. Crash and diagnostics correlation

  • [ ] Decide crash capture strategy (Sentry/Crashlytics vs AWS-only path).
  • [ ] Define crash metadata/redaction policy.
  • [ ] Link crash events to telemetry sessions/flows (crash_id, session_id, flow_id where applicable).

J7. Verification, traceability, and handoff-readiness gating

  • [ ] Add/refresh SRS-LOG-*, SRS-SEC-*, and related RA-* trace rows for telemetry story requirements.
  • [ ] Add TV-LOG-* and TV-SEC-* tests for schema integrity, outbox reliability, auth failures, and replay.
  • [ ] Create and run STR-CLOUD-* dry-run evidence package.
  • [ ] Require a passing end-to-end incident-story replay before production telemetry enablement.

J8. CloudWatch severity-filtered client logging

  • [x] Define client log level model (debug, info, warning, error) and default upload threshold (error).
  • [x] Add settings control for local log-upload threshold (selected level and above behavior) in debug builds (Home settings), persisted via CloudLogUploadPolicy.
  • [x] Implement cloud log upload event type (app.log.batch) with redaction and payload caps.
  • [ ] Add integration-test session mode for cloud-log review support:
  • generate/display test_run_id
  • temporarily elevate upload threshold for the session
  • append session metadata to app.log.batch entries
  • emit explicit start/stop/expiry log markers
  • support reviewer retrieval from tester-provided test_run_id + UTC time range
  • Implemented subset: persisted session state + persisted last-session ID for post-stop copy + threshold override + per-entry metadata + explicit marker batches + DEBUG Home settings start/stop/copy controls + active-session idempotent start guard + focused infrastructure coverage in BionicLoopInfrastructureTests + focused UI coverage in BionicLoopUITests.
  • Remaining work: scenario presets/share affordances, CloudWatch retrieval automation/canned queries, and end-to-end preservation of per-entry session metadata in CloudWatch fanout.
  • [ ] Define and implement remote override policy (subject-scoped, TTL-bound) with precedence over local setting.
  • [ ] Add verification for threshold filtering, override precedence/expiry, and privacy redaction.
  • Implemented subset: threshold default/invalid fallback + persisted local threshold filtering + override precedence/expiry unit coverage in BionicLoopInfrastructureTests.
  • [ ] Add operational governance for remote overrides (issuer role, max duration, audit trail).

J9. Algo2015 native diagnostic stream upload

  • [x] Route Algo2015 native BP_LOG_<timestamp>.txt stream into cloud log pipeline (no dosing-behavior change).
  • [x] Add native-line parser and severity mapping for prefix records (A/B/C/D/I/G/~I/~G/AD/P/PA/S) and summary lines (STEP=, *OUT).
  • [x] Correlate native uploads with session/step IDs and existing loop telemetry timeline.
  • [x] Enforce native-trace volume limits and duplicate suppression on app relaunch/reconnect.
  • [x] Add tests for offset checkpoint resume, parser robustness, and threshold-filter integration.
  • Implemented via Algo2015BPLogTailReader + Algo2015DiagnosticsTelemetryPump + CloudLogUploadLogger.logBatch.
  • Evidence in BionicLoopInfrastructureTests:
    • testAlgo2015BPLogTailReaderReadsOnlyDeltaClassifiesSeverityAndParsesStepHint
    • testAlgo2015BPLogTailReaderSwitchesToNewerFileWhenCurrentExhausted
    • testAlgo2015DiagnosticsTelemetryPumpSuppressesDuplicateUploadAcrossRelaunch
    • testAlgo2015DiagnosticsTelemetryPumpCapsLineVolumeAndAddsDropSummary
    • testCloudLogUploadLoggerLogBatchFiltersEntriesAndPreservesSource
  • [x] Add structured inspection telemetry baseline for cloud-side BP reconstruction:
  • algorithm.session.snapshot
  • algorithm.step.snapshot
  • full BP matrix row object
  • BP_LOG families A, I, G, ~I, ~G, AD/G24h, PA, P, B, C, D, S
  • [x] Add dual-write equivalence scaffold proving single-step BP/BP_LOG regeneration from structured snapshots.
  • [ ] Extend equivalence beyond single-step/golden fixtures before text-file upload retirement.

J10. Part 11 readiness for device-to-cloud algorithm telemetry

Reference: Docs/Quality/Part11_DeviceToCloud_ControlMatrix.md

  • [ ] P11-1 Applicability and policy lock
  • [ ] Approve Part 11 applicability memo for this investigational phase (record classes, intended use, predicate-rule position).
  • [ ] Decide and document electronic-signature scope (11.50/11.70/11.100/11.200/11.300) as implemented or explicitly not-applicable with rationale.
  • [ ] P11-2 Backend record/audit hardening
  • [ ] Complete cloud schema enforcement + idempotent durable persistence for telemetry records.
  • [ ] Add immutable audit metadata for ingest/reprocess/correction paths (who/when/why) and replay-safe operational workflow.
  • [ ] Add DLQ/replay operational controls with auditability and alarms.
  • [ ] P11-3 Inspection copy and retrieval controls
  • [ ] Implement role-scoped export/query path that reconstructs algorithm chronology from telemetry using UTC-normalized semantics.
  • [ ] Include provenance/correlation fields in inspection outputs (subject_id, auth_user_sub, event_id, session_id, timestamps).
  • [ ] Define retention/retrieval policy and verification checks for ready retrieval over required periods.
  • [ ] P11-4 Verification and objective evidence
  • [ ] Execute formal STR-CLOUD-* runs for auth/scope denial, schema failure handling, idempotent replay, and timeline reconstruction.
  • [ ] Link RA-008/RA-009, SRS-LOG-*, and SRS-SEC-* rows to formal evidence in RTM.
  • [ ] Add explicit closure criteria in IDE_Submission_Closure_Checklist.md for Part 11 readiness claims.

Workstream M: Reinstall Continuity (Pod Pairing + Algorithm State)

M1. Continuity model and trust boundaries

  • [ ] Define continuity snapshot schema (version, subject_id, account_id, device_binding, created_at, integrity metadata).
  • [ ] Define two-tier restore model:
  • Tier 1 (same-device reinstall): encrypted device-only Keychain snapshot.
  • Tier 2 (account recovery): cloud escrow copy protected by account auth + device-bound cryptographic envelope.
  • [ ] Confirm Omni restore-critical fields and classify:
  • restorable: pod identity/session/nonce/sequence/runtime fields needed for reconnect without re-pairing.
  • non-restorable: fields that force clean setup/new pod flow.

M2. Pod pairing/bond continuity path

  • [ ] On first launch after reinstall, detect continuity snapshot before showing default Pod setup.
  • [ ] Attempt restore handshake:
  • load snapshot
  • restore manager state
  • perform live pump status/session verification
  • [ ] If verification fails, require clean Pod setup and record explicit failure reason.
  • [ ] Add anti-mismatch safeguards:
  • subject/account consistency checks
  • stale/expired snapshot rejection
  • no cross-subject pod-state adoption

M3. Algorithm-state continuity path

  • [ ] Persist a signed algorithm continuity payload (stateData, timeStep, anchor/cadence metadata, required runtime context).
  • [ ] On reinstall restore, resume cadence from restored anchor (no forced step-0 reset when restore is valid).
  • [ ] Require restore preconditions before first post-restore execution:
  • restored state passes integrity/version checks
  • pump state reconciled (or degraded mode policy explicitly applies)
  • CGM/BG input policy satisfied for expected step
  • [ ] If restore preconditions fail, start a fresh algorithm session and surface clear reason in logs/UI.

M4. Verification and quality traceability

  • [ ] Add unit/integration tests for:
  • reinstall detection
  • successful Pod+algorithm restore
  • tampered/stale/mismatched snapshot rejection
  • fallback to clean setup/fresh session
  • [ ] Add deterministic simulation scenarios for reinstall mid-session continuity.
  • [ ] Update RA/SRS/SDD/SVVP/RTM with reinstall continuity controls and evidence links (TV-STATE-* extensions + new TV-PERSIST-* if needed).

M5. Sequencing and dependencies

  • [ ] Lock M1 design before extending Clinical Settings (K) values into continuity payload.
  • [ ] Align Tier 2 cloud escrow contract with Workstream J telemetry identity/auth patterns and Workstream I account lifecycle policies.
  • [ ] Define offline behavior when cloud restore is unavailable but local Tier 1 restore exists.

Current Sprint Queue (Rolling)

Priority 1: Clinical Settings

  • [ ] Complete K1 scope lock with team sign-off.
  • [x] Deliver K2 UI/passcode gating flow.
  • [x] Deliver K3 persistence + runtime mapping.
  • [x] Deliver K4 validation/safety checks.
  • [x] Deliver K5 unit/UI tests and trace updates.

Priority 2: Runtime + Pregnancy Parameter Integrity

  • [x] Complete A1 parameter verification against algorithm owner.
  • [ ] Run overnight cadence verification and summarize outcomes (B2).
  • [ ] Close remaining meal/pump unavailable on-device policy tests (C1/C2).

Priority 3: Quality/Release Readiness

  • [ ] Fill RTM entries for completed runtime safety policies.
  • [ ] Add CI/pre-release execution for UI smoke suite (F5).
  • [ ] Complete remaining alert verification coverage (G4).

Parking Lot (Not Current Sprint)

  • [ ] Extended fallback execution (offline basal) implementation.
  • [ ] Expanded clinical dashboards and study-report exports.