Skip to content

Development SOP (Seed)

Status: Draft v0.1
Owner: BionicLoop engineering
Applies to: all software changes in this repository

1. Purpose

Define a repeatable process that preserves safety, traceability, and test evidence for an investigational connected-device app.

2. Workflow

  1. Define change scope
  2. Describe intent and impacted modules.
  3. Identify if change is safety-impacting.
  4. Update risk and requirements
  5. Update Docs/Quality/RiskAnalysis.md if risk profile changes.
  6. Add/update SRS-* items in Docs/Quality/SoftwareRequirementsSpecification.md.
  7. Update design record
  8. Update Docs/Quality/SoftwareDesignDescription.md for architecture or behavior changes.
  9. Implement change
  10. Keep closed-loop guardrails intact unless explicitly changed by requirement.
  11. Verify
  12. Add/modify tests in line with SVVP.
  13. Run relevant test suites.
  14. Run Xcode automated UI tests for user-facing flow changes when deterministic fixtures are available.
  15. Update traceability
  16. Update Docs/Quality/TraceabilityMatrix.md with requirement/test/evidence mapping.
  17. Document results
  18. Record test outcomes and unresolved risks.
  19. Store evidence artifacts under Docs/Quality/Evidence/STR-*/... and reference that path in bug/trace docs.

3. Minimum PR Gate (Quality)

A PR is not quality-complete unless it includes:

  • requirement linkage (SRS-*)
  • tests (or documented rationale if not feasible)
  • evidence summary
  • traceability update

4. Safety-Critical Change Rules

For runtime, dosing, state persistence, or device-command path changes:

  • require explicit risk review (RA-*)
  • require design note update (SDD-*)
  • require at least one verification artifact reference
  • require reviewer sign-off that behavior matches requirement intent

5. Documentation Sync Rules

When behavior changes, update at minimum:

  • Docs/Architecture/Architecture.md
  • Docs/Requirements/Requirements.md (high-level product requirement view)
  • corresponding Docs/Quality/* artifacts

6. Versioning and Records

  • Keep IDs stable (RA-*, SRS-*, SDD-*, TV-*).
  • Do not renumber historical IDs; mark deprecated if needed.
  • Keep superseded decisions in history (git + changelog notes).

7. Automated UI Test Usage Rules

  • Use automated UI tests primarily for deterministic verification:
  • routing/navigation
  • setup and dismissal behavior
  • control visibility and enablement
  • state-to-message rendering
  • Do not treat automated UI tests as sufficient evidence for:
  • BLE timing/reliability
  • background wake behavior
  • physical delivery/device-state correctness
  • For any user-facing change, include one of:
  • updated automated UI test coverage, or
  • documented rationale why automation is not feasible and manual/system protocol used instead.