Skip to content

Execution Plan

Last updated: 2026-06-13

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

Fallback feasibility staging note: - current branch may land bridge/telemetry exposure for algorithm hourly basal outputs before the actual fallback temp-basal command path is approved - current branch may also land secondary safety-track runtime-state persistence for fallback-basal candidates before any pump command path is enabled - current branch may also land explicit fallback event/reconciliation plumbing and Recent Dose Steps projection before any pump command path is enabled - do not treat hourly-basal surfacing as approval to issue fallback temp basals or rewrite pod basal schedules without the guarded masked-fallback / reconnect design - algorithm-owner feedback now points to: - fallback target policy: <=110 -> 120, 120 -> 130, 130 -> 130 - current autonomous implementation uses a masked fallback schedule derived from the secondary/safety track's Swift-maintained q5 nominalBasal profile; the scalar safety-track nominal rate remains a backup only when a profile cannot yet be generated - current four-entry schedule shape averages local-time 72-slot / 6-hour windows (00:00-06:00, 06:00-12:00, 12:00-18:00, 18:00-24:00) - while communication is healthy, keep that fallback schedule masked with repeated 0.0 U/hr temp basals in 30 minute windows - enter mask renewal once 20 minutes or less remain on the active mask and perform that renewal before the next loop execution when pump maintenance is safe - refresh the programmed fallback schedule at the configured cadence, but only through a connected maintenance sequence: when the derived rounded schedule changes, replace the programmed schedule during a healthy known-state window with no active bolus and immediately reapply the 0.0 U/hr / 30 minute mask so connected operation stays masked while successful loop steps continue - when a first usable fallback candidate is produced by the current loop step and no masked fallback is armed yet, attempt the first arm after algorithm calculation and before that same step's pump command so a step-0 bolus cannot start ahead of fallback arming - pre-command first-arm maintenance must not bypass normal pump-availability safety gates; if the refreshed pump status is unavailable or unknown, skip that hook and let the step's normal pump command path classify the unavailable/unknown state - if that first-arm attempt is cleanly blocked by an already unsafe pump state, record the block and allow the step's normal pump command path to continue; do not retry the same first-arm attempt again after that same step's pump command. If arm/remask failure leaves recovery state requiring pump reconciliation, including a late blocked/uncertain mask after the fallback schedule may already have been written, persist that recovery context and suppress the step's normal pump command before further pod mutation - if maintenance is blocked by active bolus or other unsafe pump state while the current mask is still active, record deferred maintenance and retry on the next safe wake instead of treating that attempt as an immediate failure - if step execution stalls or deferred maintenance continues long enough for the active mask to expire, allow fallback delivery to activate and record that transition for reconciliation - current implemented guardrail slice: once maskExpiredOffline is observed, persist reconciliation-required recovery state and block ordinary loop stepping, manual BG execution, meal announce, and new arm until reconnect recovery resolves - current implemented reconnect-recovery slice: while blocked recovery is pending, runtime attempts connected restore/disarm on start, foreground, or pump reconnect; successful restore preserves fallback review history and, when the loop remained armed through recovery, preserves the existing session/cadence anchor and now uses confirmed/corrected basal-only reconnect evidence to replay missed primary/secondary algorithm steps with CGM=-1, per-step pump delivery, and no catch-up pump commands, but only when same physical pod continuity and delivery-counter credibility are proven. Ambiguous evidence, a different/new pod, unknown pod identity, or delivery-history discontinuity remains on the explicit unreconciled/logging-only feasibility path without aggregating recovered delivery into the resumed live step. An explicit reset or loop-off intent restores the original schedule but leaves the loop off instead of silently resuming the prior session - if communication is lost and the mask expires, the pod autonomously resumes the programmed nominal-derived fallback schedule - current feasibility expectation: fallback arm and each 6 hour schedule refresh may emit the normal DASH confidence beep unless pod confidence beeps are disabled/silenced, because the existing basal-schedule programming path is not yet differentiated from manual profile-save commands - keep instantBasal available for review/telemetry only for now - no fallback-specific TMAX tuning for basal-only offline mode

Ed follow-up items for the week of 2026-04-27: - [ ] Fallback feasibility continuation: summarize the overnight hardware result, reconciliation behavior, and remaining evidence gaps before deciding whether the masked fallback path is ready for broader controlled testing. - [ ] Remote temporary settings access: define whether study staff should be able to change temporary settings remotely, whether those changes are user-initiated or backend-pushed, and what single-team access / MFA / audit controls would be required before implementation. - [ ] Pause-insulin behavior: verify whether the current pump-settings suspend option prevents new bolus delivery, how it interacts with active bolus state, and whether it should also block masked-fallback maintenance or reconnect recovery commands. - [ ] Omnipod settings UI safety: decide whether to hide or remove the Suspend Insulin action from the IDE/feasibility build until suspend-state interaction with bolus delivery, masked fallback maintenance, reconnect recovery, and operator feedback is fully specified and verified. - [ ] Unreliable-sensor fallback protection: evaluate whether bad CGM data could corrupt the safety-track nominal basal used for fallback and define what CGM quality gates, rate-change limits, or operator review conditions are needed before updating the programmed fallback rate. - [ ] Temporary-basal / fallback-rate operator access: determine whether users or study staff should have access to the temporary fallback basal rate in pump settings, and define the conditions under which that control is visible, editable, or locked out. - [ ] Algo2015 nominal-basal memory: verify with code and algorithm-owner review whether the nominalBasal value used for fallback reflects a 7-day rolling history, and document the implication for fallback safety when recent CGM data are unreliable. - [ ] Lost pump reconciliation rule: clarify the product rule that if pump reconciliation evidence is unavailable or not credible, runtime should skip pump-delta accounting and resume only according to the approved ambiguous recovery path rather than inventing delivered insulin. - [x] Generalized issued-dose reconciliation: extend the meal-disconnect attribution path to any applied or uncertain automatic bolus command (meal/correction/mixed/basal micro-dose), persist request-step/component/pod context, replay only from matching same-request same-pod pump evidence before live resume, reject non-credible delivered-unit evidence, skip live advancement while unresolved evidence may still be reconciled, and record different_or_new_pod with assumed-delivered replay/live attribution when a replacement pod, no-active-pod status, or hard service-stop status proves the original pod cannot be reconciled. The replacement/no-active/service-stop path strips unrelated replacement-pod lastDelivery from resumed live algorithm input, clears legacy different/new-pod holds as nonblocking, and allows later insulin-adding automatic commands, including automatic resume. Latest 2026-06-13 review fixes keep ambiguous raw same-pod pump totals out of fallback actualDeliveredUnits and feed persisted partition evidence into the live first attribution step when no historical replay rows are due. Final stopping-point review also keeps Home meal-progress restore scoped to meal-linked pending attribution and maps non-meal pending issued-dose attribution to unreconciledIssuedDose rather than uncertainPreviousMeal. Focused core/app, full BionicLoopCore, full app unit, lint/format report mode, and Xcode analyze evidence passed for this working-tree closure. Formal evidence promotion remains required before freeze. 2026-06-16 hardware-telemetry follow-up: same-pod reconnect recovery now subtracts confirmed/persisted issued-dose evidence that matches the pending attribution and is covered by the fallback baseline-to-recovery pump-total measurement window from raw pod-total delta before fallback replay planning. A pending issued dose that completed before the connected baseline no longer blocks fallback replay because it is outside that pump-total delta and remains handled by the normal issued-dose attribution path. When the remaining fallback residual is lower than modeled fallback exposure but does not exceed it, runtime records a corrected recovery and replays the lower pump-reported residual only across fallback-active missed steps after the 0 U/hr mask expired. - [x] Schedule-weighted replay allocation: implement the 2026-06-08 plan in Docs/Planning/MultiAgentTaskBoard.md so authorized same-pod pump-delta replay distributes the authoritative pump-reported delta across missed steps according to the programmed fallback schedule weights, including partial slots, 6-hour bucket crossings, midnight wrap, zero-weight suppression, and app-side proof that replay planning uses the persisted fallback schedule. Focused evidence passed 2026-06-08 in FallbackBasalReplayPlannerTests, FallbackBasalExposureReconcilerTests, PumpBasalScheduleTests, LoopRuntimeCoordinatorFallbackReplayTests, and BionicLoopRuntimeEngineReconnectEvidenceTests; full BionicLoopCore, full BionicLoopTests, Swift lint/format report mode, Xcode static analysis, and git diff --check also passed 2026-06-08 for the current uncommitted closure. Hardware evidence, commit/freeze SHA selection, and formal evidence promotion/rerun remain required before freeze. - [ ] Pregnancy range question: ask whether the pregnancy target/range behavior should extend to 130 mg/dL, and if so whether that applies to safety target selection, UI range display, fallback target policy, or all three.

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:
  • subject-scoped offline clinical unlock gate (investigational single-device 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 clinical unlock policy language and limitation notes (single-device investigational control; broader production role-based auth deferred unless explicitly pulled into scope).
  • [x] Add app-side secure material installation/refresh path for offline clinical unlock verifier material; preserve accepted counters, clear active unlock on refresh, and avoid hardcoded production master secrets.

K2. Settings IA and gating UX

  • [x] Add a clinician-only Clinical Settings section in settings.
  • [x] Gate entry with offline clinical unlock code prompt and clear failure messaging.
  • [x] Surface manual-lock persistence failures without falsely presenting Clinical Settings as locked.
  • [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 unlock verifier/state + selector normalization policy.
  • [x] Add unit tests for verifier material installation/refresh, subject mismatch rejection, non-ASCII code rejection, and manual-lock storage-failure handling.
  • [x] Add UI tests for clinical unlock gate, unlock failure/success/reuse rejection, grouped input, offline provisioned verifier path, 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.
  • [x] Reconcile one-step algorithm/runtime cadence lag before meal-step selection so live executedStep, pump request-step attribution, and algorithm input stepTime stay aligned.
  • [ ] 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.
  • [x] Generalize meal-only delivery attribution into issued-dose reconciliation for any algorithm-issued insulin bolus whose delivery is active, uncertain, or unavailable at the next due step; preserve controller component split (basal, correction/bolus, meal), reconcile against credible matching same-pod pump evidence, partition known in-flight issued-dose insulin from a combined fallback/pump-total delta before fallback replay, replay skipped steps before live resume, avoid using provisional in-progress delivery in primary/secondary algorithm inputs, retain raw pump-total delivery telemetry for operator review, and assume delivered without replacement-pod dosing hold when known different/new pod identity proves the original pod cannot be reconciled.
  • 2026-06-13 stopping-point review fix: meal UI restoration now requires a meal-linked attribution (flow_id or meal component), and non-meal pending issued-dose attribution blocks future meal announce as unreconciled issued dose instead of reopening meal-progress UI or showing uncertain previous meal copy.
  • 2026-06-15 clinical/algorithm feedback: known different/new-pod issued-dose disposition records different_or_new_pod, assumes delivered on the first eligible attribution step by replay or live-step input, clears legacy different_or_new_pod_unresolved holds as nonblocking, and should not add a general 4 hour autobolus/adaptation forget path. New open item: if the assumed-delivered unresolved dose is tied to a meal announcement and pod abandonment prevents pump confirmation, determine how to disqualify that meal announcement from meal-type learning while still assuming the insulin was delivered for conservative insulin accounting.
  • 2026-06-15 meal-modal safety follow-up: reconnect/status-refresh now also treats hasActivePod == false or pod hard service-stop as unreconcilable old-pod evidence for a pending meal-linked issued dose, records assumed-delivered clinical-policy evidence with no observed pod ID, clears the meal progress UI fields, and suppresses foreground progress restoration once matching evidence exists.
  • 2026-06-16 hardware-telemetry fix: when same-pod reconnect evidence contains both a completed issued bolus and fallback basal exposure in one pod-total delta, partition matching pending issued-dose evidence first, then replay only the remaining fallback residual. A pending issued dose that completed before the connected fallback baseline does not participate in that pump-total delta and no longer blocks fallback-basal replay. A lower-than-modeled residual is accepted as authoritative pump evidence and is distributed only over fallback-active missed step windows after mask expiry; a residual above modeled+tolerance remains ambiguous/no replay.
  • 2026-06-17 user escape route: unresolved meal delivery progress now offers an explicit Replace Pod confirmation only for the matching meal-linked issued-dose attribution after the original pod is known unavailable/service-stopped/different or the expected physical completion time has elapsed by 2 minutes. Confirmation records assumed_delivered_per_clinical_policy evidence with user_abandoned_unavailable_pod, clears only the meal-progress UI fields, preserves issued-dose attribution for replay/live-step accounting, and opens pod setup. If legacy/partial state lacks original pod identity, coordinator consumption is still allowed only for this user-confirmed assumed-delivered path and only when request step, requested units, delivered-unit bounds, and non-active pump status match.
  • 2026-06-18 issued-dose durability / clinical-policy follow-up: bolus command-start attribution is now persisted after local pump request metadata is recorded and immediately before the physical bolus command path, so force-quit or process loss after command start preserves the in-flight dose for reconciliation. Blocked bolus commands clear any pre-command attribution; uncertain/no-response outcomes retain it. Fresh same-pod idle/suspended unresolved issued doses now assume the requested dose was delivered per clinical guidance instead of blocking meal or live dosing, while stale pump status/evidence measured before the request remains rejected. Review also tightened replay ordering so assumed-delivered evidence is recorded only after the pending attribution is eligible for the current live/replay window.
  • 2026-06-18 fallback-overlap simplification: when a resolved pending meal/correction issued dose predates a valid fallback-active replay window, runtime no longer creates pre-fallback issued-dose-only replay rows. The resolved issued dose is merged into the first actual fallback replay row, and remaining replay rows carry fallback basal only; if no valid fallback replay rows are due, existing issued-dose live/replay handling remains responsible for consuming the dose without inventing fallback rows.

C3. Offline fallback (proposed feature)

  • [ ] Convert proposal into formal requirements (entry criteria, max duration, user messaging, recovery behavior).
  • [ ] Define fail-safe constraints before implementation.
  • [x] Gate masked fallback maintenance to active algorithm sessions with a newly completed successful step and program fallback immediately for new starts when no masked fallback is currently armed.
  • [x] Add persisted masked-fallback maintenance state (original programmed schedule, current fallback schedule/rate, safety target, maintenance timestamps/outcomes).
  • [x] Add connected maintenance eventing for arm, mask renewal, schedule refresh, offline mask expiry, and restore success/failure.
  • [x] Add reset/disarm restore attempt so masked fallback does not remain armed underneath the pod after a session clear.
  • [x] Change steady-state mask renewal to a 20 minute renewal window with pre-step renewal for already-masked fallback and deferred-not-failed handling when bolus/unsafe pump state blocks renewal while the current mask is still active.
  • [x] When offline mask expiry is recorded, persist reconciliation-required recovery state and suppress ordinary loop execution, manual BG, meal announce, and new arm until reconnect recovery is resolved.
  • [x] While masked-fallback recovery is pending, attempt connected restore/disarm on runtime start, app foreground, or pump reconnect; if restore succeeds while the loop remained armed, clear the blocked recovery state, preserve the existing session/cadence anchor, and either allocate pump-reported fallback delivery across missed algorithm steps with CGM=-1 and no catch-up pump commands when same physical pod continuity plus credible delivery-counter evidence are proven (confirmed / corrected evidence) or stay on the explicit unreconciled/logging-only feasibility path (ambiguous, different/new pod, unknown pod identity, or delivery-history discontinuity). Explicit reset/loop-off recovery restores the original schedule but keeps the loop off.
  • [x] Use basal-only reconnect evidence to drive pump-delta missed-step algorithm replay when recovery is confirmed / corrected and same-pod continuity is proven; replay uses the pump-reported delivered-insulin delta only, modeled expected fallback delivery is logging/review evidence only, ambiguous or non-continuous pod evidence still uses the explicit unreconciled/logging-only feasibility path, and broader reconstruction remains follow-on work.
  • [x] Bound pump-delta replay to missed algorithm steps whose delivery interval overlaps confirmed fallback-active time; disconnected missed steps before offline fallback activation remain missing and are not replayed as synthetic 0 U delivery rows.
  • [x] When resolved issued-dose evidence overlaps the recovery but its attribution step predates the first fallback-active replay row, merge that dose into the first fallback replay input instead of replaying pre-fallback issued-dose-only rows.
  • [x] Partition same-pod issued-dose evidence from reconnect pump-total deltas before fallback replay, including persisted pump_last_delivery evidence, only when the pending issued dose is fully covered by the fallback baseline-to-recovery pump-total measurement window. Lower pump-reported fallback residuals are replayed as corrected evidence; higher residuals or pre-baseline timing that overlaps the measured delta without covered evidence remain ambiguous to avoid over-crediting insulin.
  • [x] Keep local per-step telemetry / CSV export anchored to real algorithm executions: confirmed/corrected reconnect recovery records missed-step primary/secondary algorithm replay rows with CGM=-1 and per-step pump-delivery input, then resumes the current due step using actual refreshed pump status without duplicate recovered-delivery injection.
  • [x] Persist primary and secondary/safety q5 nominal-basal profiles in runtime state from algorithm scalar nominalBasal outputs, including local-time slot imputation and seven-observation slot history.
  • [x] Program the masked fallback schedule from the secondary/safety q5 nominal-basal profile as four six-hour DASH basal periods, with scalar safety nominal fallback only when no profile schedule is available.
  • [x] Model reconnect fallback exposure against the persisted multi-entry fallback schedule across six-hour bucket boundaries.
  • [x] Emit fallback schedule/profile cloud telemetry on fallback arm and schedule-refresh events, including four programmed schedule entries, profile source/kind, observed/imputed slot counts, timezone metadata, and the 288 q5 rates used for programming.
  • [x] Attempt first masked-fallback arm for a just-computed fallback candidate before the same step's pump command, including step 0, while preserving the distinction between a clean blocked first-arm attempt and a recovery-required remask failure.
  • [x] Review-fix step-0 first-arm ordering edge cases: skip pre-command fallback maintenance when pump status is unavailable/unknown, suppress same-cycle post-execution retry after any pre-command fallback event, and classify post-schedule mask blocking/failure as recovery-required remask failure.
  • [x] Review-fix fallback safety findings: require fresh idle pump status before pre-execution masked-fallback arm/renew/refresh maintenance, promote existing-mask remask failures to reconciliation-required recovery, clear invalid/not-required pending replay plans after trace emission, and add cached-idle/refresh-failure regression coverage. Working evidence passed 2026-06-11: full swift test --package-path BionicLoopCore (195 tests), focused app masked-fallback/disconnect runtime suite (27 tests), full BionicLoopTests (509 tests), SwiftFormat report mode (0/256 files require formatting), SwiftLint report mode (54 existing warnings, 0 serious), xcodebuild analyze exit 0, and git diff --check.
  • [ ] Expose the algorithm's nominal Q5BR0s / hourly nominal basal profile through the Swift bridge as scaled U/hr arrays and add a pure, tested mapper that averages the 288-point nominal profile into four 6-hour PumpBasalSchedule periods (00:00, 06:00, 12:00, 18:00). The currently defined q5BasalRates[288] / hourlyBasalRates[24] interface copies the active Q5BRs / HrlyBRs profile, so do not use it as the nominal fallback profile without adding an explicit nominal array. Keep this as follow-on bridge cleanup after the current Swift-maintained q5 nominal profile path.
  • [ ] Backlog a small OmniBLE change for silent masked-fallback schedule programming so fallback arm/refresh/disarm can avoid manual confidence beeps without changing the user's global pod-beep preference.
  • [x] Update Home Recent Dose Steps to show fallback-specific details:
  • selected fallback rate (U/hr)
  • source (nominalBasal from the safety track for the first autonomous masked implementation)
  • escalated safety target used for the safety track
  • mask duration / renewal state and later reconnect reconciliation outcome
  • modeled fallback delivery and pump-reported delivered insulin delta when reconnect evidence is available
  • [x] Enhance ordinary Recent Dose Steps rows to show both primary and secondary algorithm summaries for each executed step:
  • step count
  • suggested dose
  • nominal basal
  • instant basal

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.
  • [x] Ensure confirmed/corrected fallback recovery records no-command missed-step algorithm replay rows from credible same-pod pump delta, with CGM=-1 and per-step pump-delivery input, without duplicating recovered insulin on the resumed live step.
  • [x] Ensure fallback replay telemetry covers only confirmed fallback-active missed steps, preserving explicit 0 U rows only inside that active interval and omitting pre-activation disconnected gaps.
  • [ ] 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.
  • [x] Ensure fallback-specific fields are retained and surfaced in Recent Dose Steps without requiring raw telemetry inspection.

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).
  • [x] Define and implement no-active-pod critical alert policy: any state where the user does not have an active pod triggers a safety-critical local alert after debounce and repeats local notification attempts every 30 minutes until an active pod is restored or the final approved dismissal/exit condition is met. This covers inactive, deactivated, expired, missing, unpaired, setup-incomplete, and otherwise no-active-pod scenarios, not only armed-loop stepping interruptions.

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
  • replay/backfill algorithm.step.snapshot rows emitted before the resumed live step, with is_replay and replay delivery evidence fields so Scout structured-primary BP reconstruction can show recovered steps.
  • [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, block or continue only according to the existing armed-session state; do not automatically start, stop, reset, or replace the algorithm session, and surface the reason in logs/UI for explicit user action.

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/clinical-unlock 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, including shared reconnect reconciliation for uncertain meal bolus and other in-flight insulin delivery states.
  • [ ] Expanded clinical dashboards and study-report exports.