Skip to content

Next Sprint Checklist

Last updated: 2026-06-02 16:30 EDT Owner: BionicLoop engineering Status: Active (software handoff week)

This is a condensed execution checklist derived from: - /Users/jcostik/BionicLoop/Docs/Planning/ExecutionPlan.md - /Users/jcostik/BionicLoop/Docs/Quality/IDE_Submission_Readiness_Report.md - /Users/jcostik/BionicLoop/Docs/Quality/IDE_Baseline_Freeze_Plan.md

Sprint Goal

Produce a handoff-ready IDE software package for the receiving quality/submission team.

This sprint is explicitly about engineering-owned software deliverables, not full downstream quality approval or submission release handling.

Priority Order

  1. Workstream O (IDE software handoff package)
  2. Workstream L (algorithm verification package closure inputs that affect handoff)
  3. Workstream B / G only where they block software package traceability

Must-Lock Scope First

  • [x] Confirm the current software package includes local app/runtime/algorithm/device software only.
  • [x] Confirm cloud / Part 11 / final approval workflow remain out of this week’s package unless explicitly re-opened.
  • [ ] Confirm hardware evidence gaps are tracked as rerun-needed items rather than hidden as complete.

Deliverables Due This Week

0. Ed follow-up work for fallback / controlled settings

  • [ ] Summarize the overnight fallback hardware result, including modeled vs pump-reported delivery, reconciliation behavior, and remaining feasibility gaps.
  • [ ] Define temporary remote settings access: user-initiated vs backend-pushed, single-team access, MFA expectations, and audit/trace requirements.
  • [ ] Verify pump-settings pause/suspend behavior: whether it prevents new bolus delivery, how it handles active bolus state, and whether fallback maintenance commands must be blocked while suspended.
  • [ ] Decide whether to hide or remove the Suspend Insulin action from the Omnipod pump settings view for the IDE/feasibility build unless its interaction with active bolus delivery, masked fallback maintenance, fallback recovery, and operator-facing state is fully specified and verified.
  • [ ] Evaluate unreliable-CGM risk to fallback: can bad sensor data bias the safety-track nominalBasal, and what quality gates or rate-change limits are required before programming fallback.
  • [ ] Decide whether users or study staff should have controlled access to a temporary fallback basal rate in pump settings and under what conditions.
  • [ ] Verify whether Algo2015 nominalBasal is based on a 7-day rolling memory and document the fallback implication.
  • [ ] Confirm the lost-reconciliation rule: if pump evidence is unavailable or not credible, skip pump-delta accounting and use the explicit ambiguous recovery path.
  • [ ] Ask Ed whether pregnancy range / target behavior should extend to 130 mg/dL, and identify whether that affects UI display, safety target selection, or fallback target policy.
  • [x] Add no-active-pod critical alerting to the alert workstream: every no-active-pod scenario must raise a safety-critical local alert every 30 minutes until active pod state is restored or an approved exit condition is met.

1. Software document-set boundary

  • [x] Publish the engineering-owned software deliverable set.
  • [x] Publish the explicit non-owned downstream quality/release items.
  • [x] Publish a deferred-items list with rationale and owner.
  • [ ] Create a concise Software Device Description for IDE Baseline packet that wraps the existing SMD/SDD-level material for submission review. The packet must include intended use, supported configurations, software baseline/version/commit, architecture and data-flow summary, requirements and risk cross-reference, verification posture, cybersecurity/privacy summary, release/configuration controls, known limitations, and traceability links. Treat SRS/SDD/SVVP/RA/RTM as referenced source documents, not as the only device-description artifact.

2. Controlled software docs to handoff-ready status

  • [x] Move these 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.
  • [x] Align package scope text across the set.
  • [ ] Fill final baseline freeze SHA across the set at freeze time.

3. Requirement and scope disposition

  • [x] Disposition SRS-BG-008.
  • [x] Disposition SRS-MEAL-004.
  • [x] Disposition SRS-CLIN-002.
  • [x] Decide whether SRS-SEC-003..009 remain in this software package or are deferred.
  • [x] Remove unresolved wording from in-scope controlled text.

4. Verification package readiness

  • [x] Promote Docs/Quality/STP/ to a handoff-ready software protocol package.
  • [x] Ensure every in-scope TV-* row maps to one owning STP-* or an explicit deferred disposition.
  • [ ] Audit RTM evidence rows into:
  • formal-ready
  • rerun-needed
  • deferred
  • [ ] Remove handoff-language dependence on Docs/Quality/Evidence/Working/.

5. Handoff assembly

  • [x] Produce the software package index with exact included docs and package boundary.
  • [x] Produce the current engineering handoff summary using the readiness report + disposition log + package index.
  • [ ] Fill the final baseline SHA and freeze note for the receiving quality/submission team.
  • [ ] Update the readiness report to reflect software handoff status after closure.

Exit Criteria

  • [ ] Engineering-owned software package is explicitly scoped and documented.
  • [ ] Core software docs are in handoff-ready status with metadata placeholders.
  • [ ] STP/RTM package is coherent enough for downstream quality review.
  • [ ] Remaining gaps are written as explicit deferred or rerun-needed items, not hidden in draft language.