# ScopeDOPE — Software Development Life Cycle

**Parent document:** [CBB_SDLC.md](../../CBB_Corporate/03_-_Confidential/Process/CBB_SDLC.md) — CBB-wide master. This document extends the master for the ScopeDOPE product line (Android + iOS).
**Owner:** Cold Bore Ballistics LLC
**Product:** ScopeDOPE (Android + iOS)
**Status:** Active

---

## Purpose

This document defines the ScopeDOPE-specific software development process. It covers the technology stack, branching conventions, version numbering, release checklist, and platform-specific practices that are not addressed at the CBB master level. All CBB-wide policies (roles, machine setup, credential controls, dev workflow, requirements management, test principles, release principles, bug management, documentation standards, security, issue tracking) are governed by `CBB_SDLC.md` and are not duplicated here.

---

## Table of Contents

1. [Development Environment — ScopeDOPE Stack](#1-development-environment--scopedope-stack)
2. [Repository Structure](#2-repository-structure)
3. [Branching Strategy](#3-branching-strategy)
   - [3.3 ScopeDOPE Version Numbering Ladder](#33-scopedope-version-numbering-ladder)
   - [3.4 Website and Service Repository Branching](#34-website-and-service-repository-branching)
4. [Development Workflow — ScopeDOPE Specifics](#4-development-workflow--scopedope-specifics)
5. [Requirements Management — SPEC](#5-requirements-management--spec)
6. [Testing Strategy — ScopeDOPE Specifics](#6-testing-strategy--scopedope-specifics)
7. [Release Process](#7-release-process)
8. [Bug Management — ScopeDOPE Specifics](#8-bug-management--scopedope-specifics)
9. [Documentation Standards — ScopeDOPE Specifics](#9-documentation-standards--scopedope-specifics)
   - [9.1 dope-format Documentation](#91-dope-format-documentation)
10. [Tools Reference](#10-tools-reference)

---

## 1. Development Environment — ScopeDOPE Stack

General machine setup requirements are defined in CBB_SDLC.md §3. The ScopeDOPE stack adds:

### 1.1 Android

| Component | Detail |
|---|---|
| Language | Kotlin |
| UI Framework | Jetpack Compose |
| Architecture | MVVM + Use Cases (UI → ViewModel → Use Case → Repository → Data) |
| Engine | `:ballistics` KMP module — `commonMain` shared source; targets `androidTarget()` (production), `jvm()` (validation), `iosArm64`, `iosX64`, `iosSimulatorArm64` (XCFramework for iOS) |
| IDE | Android Studio |
| Build System | Gradle |
| Dependency Injection | Hilt |
| Local DB | Room (SQLite) |
| Concurrency | Kotlin Coroutines / StateFlow |
| Serialization | kotlinx.serialization (`.dope` JSON format) |
| BLE | Android BLE API |
| Min SDK | Android 12 (API 31) — see SPEC.md §3 |
| Target SDK | See SPEC.md §3 |
| Version Control | Git |
| Parity Requirement | Primary platform — iOS must match at initial launch |

### 1.2 iOS

| Component | Detail |
|---|---|
| Language | Swift |
| UI Framework | SwiftUI |
| Architecture | MVVM — mirrors Android domain layer structure |
| Engine | `:ballistics` KMP module (shared Kotlin code compiled to XCFramework; identical math, identical results) |
| IDE | Xcode (macOS required) |
| Build System | Xcode build system |
| Dependency Injection | N/A — Swift DI patterns |
| Local DB | SQLDelight (KMP-native; same schema as Android Room/SQLite — full `.dope` round-trip parity) |
| Concurrency | Swift Concurrency (async/await) |
| Serialization | Swift `Codable` (`.dope` JSON format — same schema as Android) |
| BLE | CoreBluetooth |
| Min OS | iOS 16 |
| Version Control | Git |
| Status | In development — simultaneous initial launch with Android |
| Parity Requirement | Feature parity with Android at initial launch |

---

## 2. Repository Structure

### 2.1 ScopeDOPE Repositories

The CBB GitHub organization and default visibility policy are defined in CBB_SDLC.md §4.1. ScopeDOPE repositories:

| Repo | Purpose | Visibility |
|---|---|---|
| `scopedope-android` | Primary Android app (includes `:ballistics` KMP module via submodule) | Private |
| `scopedope-ios` | iOS app — in development, simultaneous launch target | Private |
| `scopedope-shared` | Shared assets, ammo DB — git submodule in `scopedope-android` and `scopedope-ios` | Private |
| `scope-dope.com` | ScopeDOPE marketing website — static HTML. **Independent of ScopeDOPE app SDLC** — see §3.4. | Private (serves public site) |
| `coldboreballisticsllc.com` | Cold Bore Ballistics company website. **Independent of ScopeDOPE app SDLC** — see §3.4. | Private (serves public site) |
| `dope-format` | `.dope` file format specification and JSON schema | **Private** until v1.0 launch, then public (CC0 open standard) |
| `feedback-service` | Feedback intake API — **DEFERRED** — do not implement, deploy, or reference until reactivated | Private |
| `cbb-utils` | Internal scripts/utilities — **exempt from this SDLC**: no version branching, SPEC, changelog, or release checklist; commit directly to `main` | Private |
| `cbb-infra` | Terraform for Azure — **exempt from this SDLC**: commit directly to `main` | Private |

---

## 3. Branching Strategy

CBB-wide branching structure, rules, issue branch policy, and version numbering principles are defined in CBB_SDLC.md §5. ScopeDOPE-specific additions are below.

### 3.1 Build Manifest Alignment

The CBB-wide rule (CBB_SDLC.md §6.6) requires the `dev-<version>` branch name to match the declared version in the build manifest. For ScopeDOPE, that file is `versionName` in `build.gradle.kts`. Both `scopedope-android` and `scopedope-ios` follow this convention.

### 3.2 Ballistics Engine / `scopedope-shared` Submodule Flow

All Ballistics Engine work is committed in the **`scopedope-shared`** repo (it hosts the `:ballistics` KMP module). The engine is never edited in a platform repo's detached submodule checkout. The expected flow: commit in `scopedope-shared`, then advance the submodule pointer in `scopedope-android` and `scopedope-ios`.

### 3.3 ScopeDOPE Version Numbering Ladder

Implements CBB_SDLC.md §5.5. The MAJOR.MINOR.PATCH semantic versioning framework is CBB-wide; the table below defines *when* ScopeDOPE increments each component, driven by its hardware expansion milestones and dual-platform release cadence.

| Component | Trigger |
|---|---|
| **X.0.0** | Product generation milestone — v1.0.0 (launch), v2.0.0 (next major); also triggers on breaking `.dope` format changes |
| **X.1–3.0 / X.6–8.0** | Feature release — new corrections, label formats, export options, UI additions |
| **X.4.0-alpha.N / X.4.0-beta.N** | Pre-release cycle for hardware expansion |
| **X.5.0-rc.N** | Release candidate for hardware expansion — feature-frozen; bug fixes only |
| **X.5.0** | Hardware ecosystem expansion — new device in an existing hardware class |
| **X.9.0-alpha.N / X.9.0-beta.N** | Pre-release cycle for next major |
| **(X+1).0.0-rc.N** | Release candidate for next major — feature-frozen; bug fixes only |
| **X.Y.Z** (Z > 0) | Patch — bug fixes, crash fixes, performance, copy changes, BC value updates; no new user-facing features |

### 3.4 Website and Service Repository Branching

The website and service repos (`scope-dope.com`, `coldboreballisticsllc.com`, `feedback-service`) operate independently of the ScopeDOPE app SDLC and do not follow the `dev-<version>` branching model.

**Principles:**
- `main` is always deployable
- Changes are validated on the test environment before production promotion
- Independent semantic versioning per repo — not tied to app version numbers

**Anti-patterns:**
- Committing work-in-progress to `main`
- Tagging for production without test environment validation
- Tying website version tags to app version numbers
- Force-pushing or deleting the `active-test` branch
- Long-lived feature branches

**What still applies from CBB_SDLC.md:** conventional commit format, credential policy, security controls, documentation standards.

**What does not apply:** `dev-<version>` branching, Branch SPEC, `REQUIREMENTS.md`, the ScopeDOPE Release Checklist, or the SPEC-first requirement.

**Operations:** `Website_and_Service_Deployment_Guide.md`.

---

## 4. Development Workflow — ScopeDOPE Specifics

The CBB-wide feature development flow is defined in CBB_SDLC.md §7.2. ScopeDOPE-specific additions:

- **Step 1 (Spec first):** The ScopeDOPE SPEC is the four companion files described in §5.1. Voting board popularity does not override SPEC decisions — a highly-voted feature that conflicts with a SPEC architectural decision requires a SPEC revision first, approved by the Founder, before implementation begins.
- **Step 8 (issue working branches — all stages):** Squash-merge the issue branch into `dev-<version>` with a `Closes: <KEY>` trailer; draft/append the CHANGELOG.md `[Unreleased]` entry for the Founder's review; set the issue's Jira `fixVersion` (and `affectedVersion` if a Bug).

---

## 5. Requirements Management — SPEC

The CBB-wide requirements management policy is defined in CBB_SDLC.md §7. ScopeDOPE specifics:

### 5.1 The ScopeDOPE SPEC

The ScopeDOPE SPEC is split across four companion files in `OneDrive/ScopeDOPE/04_-_Highly_Confidential/SPEC/`:

| File | Covers |
|---|---|
| `SPEC.md` | §1–4: overview, repos, platforms, architecture |
| `SPEC_data_engine.md` | §5–9: ammo, engine, DOPE, conditions, sensors |
| `SPEC_features.md` | §10–15: calculation, labels, printing, sessions, UI |
| `SPEC_nonfunc_appendices.md` | §16–20 + appendices: NFRs, platform notes, pricing, validation, DB schema, devices |

The SPEC never lives in any git repo — OneDrive only.

**SPEC review cadence:** At each minor release, scan the full SPEC TOC for orphaned entries, stale references, and TOC/content mismatches before merging to `main`. This is a checklist item in §7.2.

### 5.2 Branch Spec

For each `dev-<version>` branch, a branch working spec is maintained at:

```
<org-root>/docs-working/<branch-name>-SPEC.md
```

This is an ephemeral working doc that captures spec additions and changes in progress for the current branch. Merge into the appropriate SPEC file(s) at branch close, then delete. Never edit the four SPEC files directly during branch work — changes go into the Branch Spec.

---

## 6. Testing Strategy — ScopeDOPE Specifics

CBB-wide test layer definitions and general unit test requirements are in CBB_SDLC.md §9. ScopeDOPE adds:

### 6.1 Test Layers (ScopeDOPE)

| Layer | What it covers | When it runs |
|---|---|---|
| **Unit tests** | Ballistics engine math, DOPE-Blend interpolation, unit conversions, `.dope` file parsing | Every commit |
| **Integration tests** | BLE driver lifecycle, Room DB migrations, session save/load round-trips | Every merge to main |
| **Engine validation** | Real-world DOPE data vs theoretical output (tiered — see §6.2) | Before every minor release |
| **Manual / device testing** | UI flows, BLE pairing, print pipeline end-to-end | Before every release |

Validation command: `./gradlew :shared:ballistics:jvmTest` from `scopedope-android/`.

### 6.2 Ballistics Engine Validation Framework

The engine is validated against real-world DOPE data using a tiered classification based on environmental data completeness. Exercises `BallisticsEngine.kt` directly through the `:ballistics` KMP module — no Python port, no device or emulator required. The suite runs LOO (leave-one-out, k=1) and exhaustive C(N,k) cross-validation across all test datasets.

**Tier system:**

| Tier | Environmental Data Completeness | Confirmed Impacts | What It Validates |
|---|---|---|---|
| Tier 1 | ≥ 85% of fields known | Required | Engine accuracy — direct comparison valid |
| Tier 2 | 40–84% of fields known | Required | Partial accuracy signal; deviations noted with caveats |
| Tier 3 | < 40% of fields known | Required | Robustness — graceful degradation test |
| Sub-3 | Any | None (calculated only) | Cross-calculator comparison only |

**Acceptable deviation thresholds:**

| Verdict | Tier 3 max \|Δ\| | Sub-3 max \|Δ\| |
|---|---|---|
| OK | ≤ 0.2 mil | ≤ 0.3 mil |
| INVESTIGATE | 0.2–0.5 mil | 0.3–0.7 mil |
| FAIL | > 0.5 mil | > 0.7 mil |

TRANSONIC flagged points: apply 2× tolerance. The goal is OK across all Tier 1 and Tier 2 cases.

**Report retention:** Before committing a new timestamped report in `ballistics/reports/` or `ballistics-test-data/jbm-refs/generated/`, delete the previous one. One file per series at all times.

**Performance benchmarks:**

| Operation | Target | Regression threshold |
|---|---|---|
| Full DOPE calculation (all ranges) | < 100 ms | > 250 ms |
| Single-range calculation | < 20 ms | > 50 ms |
| BLE sensor connection to first reading | < 5 s | > 10 s |

A result exceeding the regression threshold is treated as `bug:major` and blocks release.

### 6.3 `:ballistics` Unit Test Requirements

- All functions in `:ballistics` must have unit tests
- All `.dope` file format parse/serialize operations must have round-trip tests
- All Room DB migrations must have migration tests
- Coverage target: 80% for `:ballistics` module

### 6.4 BLE Testing

BLE drivers cannot be fully tested in emulator. Required physical devices:

| Device | Purpose |
|---|---|
| Android phone (physical) | BLE pairing, sensor integration, print pipeline |
| Niimbot B1 | Label printing validation |
| Niimbot B21 Pro | Label printing validation |
| BTMETER BT-100APP | BLE anemometer sensor integration |
| WeatherFlow Tactical | BLE weather sensor integration — direct Bluetooth pairing, no hotspot |

---

## 7. Release Process

Release principles are defined in CBB_SDLC.md §10. ScopeDOPE adds the version numbering ladder (§3.3), the full release checklist, and staged rollout policy.

### 7.1 Active Version

Current dev cycle: `dev-0.9.7-beta.5` (`versionName 0.9.7-beta.5`, `versionCode 14`). Last released tag: `v0.9.6-beta4` (interim beta). Pre-1.0.0 — 1.0.0 not yet declared.

### 7.1.5 Release Automation — the tag is the gate

A tag-triggered GitHub Actions workflow (`scopedope-android/.github/workflows/release.yml`, DOPE-50) automates the mechanical release steps. **Pushing a `v*` tag is the release gate** — a deliberate, outside-Jira act; nothing in Jira or a branch push can trigger a ship.

**On `v*` tag push, the workflow:**
1. Verifies the tag matches `versionName`, then **gates** on engine tests (`:ballistics:jvmTest`) + the hygiene guards — aborts the release on any failure.
2. Builds the debug APK.
3. Creates the **GitHub Release** with the APK + `CHANGELOG.md` attached and the version's changelog section in the body; the `prerelease` flag is derived from tag semantics (bare `vX.Y.Z` = public/not-prerelease, any `-pre.release` suffix = internal/prerelease).
4. **Syncs the Jira version** via REST — creates the matching DOPE version if absent and marks it released per tag semantics. (GitHub does **not** populate Jira versions natively; the workflow owns this.) This step runs **only if** the `JIRA_API_TOKEN`/`JIRA_EMAIL` repo secrets are set; it skips gracefully otherwise.

**What stays MANUAL (not in the workflow, by design):**
- **Signed release builds + store upload** — the keystore and store credentials are deliberately kept off CI pre-1.0. Do these locally (checklist Release items below).
- **The `[PROMPT]` gates** in §7.2 — device test, BLE/print verification, store smoke tests, staged rollout — are human judgment, performed before/after the tag push.
- **The interim-beta `dev`-reset-onto-`main` force-push** — too consequential to automate; documented manual step (CLAUDE.md → Release types).

So: **§7.2 below is the human-driven release procedure; the tag push within it fires the automation above for the mechanical parts.** Continuous-integration gates (engine tests, hygiene guards) also run on every push/PR via `engine-tests.yml` and `hygiene.yml` (DOPE-49), so several pre-release checklist items are enforced automatically before you ever tag.

### 7.2 Release Checklist

**[PROMPT]** = block and require explicit Founder confirmation before proceeding.

> **CI-enforced items** (✅ automated via DOPE-49/50 workflows) are marked below; the workflow re-checks them at tag time too.

**Pre-release (version branch → main):**
- [ ] All in-scope milestone items implemented and tested
- [ ] Engine validation run — no regressions vs previous baseline (`./gradlew :shared:ballistics:jvmTest`) — ✅ _CI-enforced (engine-tests.yml on every push/PR; re-gated at tag)_
- [ ] All unit and integration tests passing
- [ ] Performance benchmarks within targets (§6.2)
- [ ] SPEC TOC currency check — no orphaned entries or stale references (§5.1)
- [ ] SPEC.md version and date updated
- [ ] **[PROMPT]** CHANGELOG.md updated — every release (rename `[Unreleased]` → version+date; user-facing prose; mark internal builds `_(internal beta)_`). See CBB_SDLC.md §12.5.
- [ ] `versionCode` and `versionName` updated in `build.gradle.kts` (Android)
- [ ] Dependency audit complete — no new high-severity CVEs — ✅ _Dependabot files these continuously (weekly Gradle + actions, both repos)_
- [ ] No unguarded debug logging in production code paths — ✅ _CI-enforced (hygiene.yml block-aware guard; re-gated at tag)_
- [ ] **[PROMPT]** Privacy policy URL live and current
- [ ] Sentry integration verified in release build — test crash received in dashboard
- [ ] **Crash-test trigger is release-incapable** — confirm no test-crash trigger is reachable in the release build (debug-only guard intact); pipeline re-verified on a debug build of the RC, event carried only the permitted payload (no PII/identity/ballistic data). See §8.3.
- [ ] Sentry spending cap confirmed at $50/month; alert rule for 2% crash rate active
- [ ] **[PROMPT]** Sentry data-scrub currency check — review any new persisted/serialized field names added since the last release against the Sentry "Additional Sensitive Fields" scrub list; add any new identity/PII/location/file/ballistic field names that are missing. The scrub list is a prophylactic backstop and must not fall behind the app's field surface. (See Sentry_Security_Review.md §2.1.)
- [ ] OneDrive architecture references and runbooks reflect current infrastructure state
- [ ] **Jira version fields set** — every issue in this release has `fixVersion`; every Bug has `affectedVersion`; issues linked to ESUP counterparts (CBB_SDLC.md §11.3)
- [ ] **DRAFT-approval sweep** — review/approve any pending `DRAFT` revisions across SPEC, SDLC, policies, runbooks (CBB_SDLC.md §12.2)
- [ ] **Submodule pointer on origin** — the `shared` SHA referenced by the app is present on `origin` (and tagged at release); not local-canonical-only
- [ ] **Branch hygiene** — after tag, prune merged/dead local+remote branches; invariant restored (`main` + one `dev-<version>`)

Pre-release completed by: _____________  Date: ________

---

**Release (merge to main + tag):**
- [ ] **[PROMPT]** Final manual device test — full UI walkthrough
- [ ] **[PROMPT]** BLE pairing and print pipeline tested on physical hardware
- [ ] **[PROMPT]** Android: signed release AAB built
- [ ] **[PROMPT]** iOS: archive built and validated in Xcode
- [ ] **[PROMPT]** Google Play Console: internal test track upload and smoke test
- [ ] **[PROMPT]** Apple TestFlight: build uploaded and smoke test
- [ ] Merge to `main` and tag (`git tag v<version>`) — ask before executing. **Tag semantics:** bare `vX.Y.Z` = PUBLIC; any `-pre.release` suffix = internal/testing (CBB_SDLC.md §6.5)
- [ ] **GitHub Release created** for the tag with **build artifact + `CHANGELOG.md`** attached, and the version's changelog section in the release body; `prerelease` flag matches the tag (internal=true, public=false/"Latest"). Artifact also on the `files.` server where applicable
- [ ] Tag both `scopedope-android` and `scopedope-shared`

Release completed by: _____________  Date: ________

---

**Post-release:**
- [ ] **[PROMPT]** Google Play: promote from internal → production (staged rollout — §7.3)
- [ ] **[PROMPT]** Apple App Store: submit for review
- [ ] Voting board items shipping in this release updated to "Shipped" status
- [ ] Monitor crash reports and ratings for 48 hours post-launch

Post-release completed by: _____________  Date: ________

### 7.3 Staged Rollout Policy

Android Google Play staged rollout:
- 10% for 24 hours — monitor crash rate and ANR rate
- 50% for 24 hours — monitor
- 100% if no regressions

Halt rollout if:
- Crash rate exceeds 2% of sessions
- Any data loss bug is reported
- Print pipeline failure reported by multiple users

For a halted rollout: implement hotfix release, confirm fix is included, then resume.

---

## 8. Bug Management — ScopeDOPE Specifics

CBB-wide bug severity classification, SLAs, and issue tracking policy are defined in CBB_SDLC.md §11 and §14. ScopeDOPE adds:

### 8.1 Public Feature Voting Board

ScopeDOPE operates a public feature request and bug reporting board integrated into both the website and the app. Bug SLAs are defined in CBB_SDLC.md §11.1; the voting board is the user-facing surface where those SLAs are fulfilled.

**Board statuses:**
- `Submitted` — received, not yet reviewed
- `Under Review` — being evaluated against roadmap and SPEC
- `Planned` — accepted; will be in a future release
- `In Progress` — actively being worked
- `Shipped` — included in a released version
- `Declined` — not accepted; reason provided

**Response commitment:** All submitted items receive a status update within 7 days.

### 8.2 Internal Issue Tracking

GitHub Issues in `scopedope-android` (and `scopedope-ios` when iOS development begins) for internal tracking. Public voting board items that are accepted get a corresponding GitHub Issue.

**ScopeDOPE-specific issue labels:**

| Label | Meaning |
|---|---|
| `engine` | Ballistics engine |
| `ble` | BLE/sensor |
| `print` | Label printing pipeline |
| `ios` | iOS-specific |
| `android` | Android-specific |

### 8.3 Crash Reporting

**Selected tool: Sentry** (sentry.io)

Chosen over Firebase Crashlytics (no KMP crash attribution) and Bugsnag (KMP SDK in beta at selection date). Sentry's KMP SDK attributes crashes in shared Kotlin code to the correct common source — essential for diagnosing ballistics engine issues.

**Plan:** Free tier (5,000 errors/month) through closed beta. Team plan ($26/month, 50,000 errors/month) at public launch. Spending cap: $50/month.

**Consent model (mandatory):** Crash reporting is **opt-in and OFF by default**. The Sentry SDK is not initialized and transmits nothing until the user affirmatively consents. Consent is captured via a one-time first-run prompt (default action: decline) and can be changed at any time via a mandatory Settings toggle, independent of the prompt. See SPEC §16.1 for the full requirement.

**Privacy constraints (mandatory):**
- Default OFF — no crash data leaves the device without explicit user consent
- No user identifiers attached to crash events — "no accounts" brand position
- No PII in breadcrumbs or custom context; no ballistic data, session content, or file contents
- Permitted payload: stack trace, app version, OS version, device model, crash timing
- Privacy policy must describe crash reporting as optional and OFF by default **before** the SDK ships in any externally distributed build

**Integration points:**
- Android: `io.sentry:sentry-android`
- iOS: Sentry Cocoa SDK via Swift Package Manager
- KMP shared code: `io.sentry:sentry-kotlin-multiplatform`

**Staged rollout monitoring:** Configure a Sentry alert rule mirroring the halt conditions in §7.3 (2% crash rate threshold).

**Crash-test instrumentation (standing rule):** A deliberate test-crash trigger is a permitted and encouraged part of **debug builds** so the crash-reporting pipeline can be re-verified on any device at any time (e.g. long-press the version string in Settings to throw a test exception). It is subject to two mandatory constraints:

1. **Release-incapable by construction.** The trigger must be guarded so it cannot exist in a release build — wrap it in `if (BuildConfig.DEBUG)` (Android) / the equivalent debug-only compilation guard (iOS). A guard that merely hides the control at runtime is insufficient; the crash-throwing code path must not be reachable in a release binary.
2. **Verified every release.** The release checklist confirms (a) no test-crash trigger is reachable in the release build, and (b) the Sentry pipeline was re-verified on a debug build of the release candidate — a forced test crash reached the project dashboard carrying only the permitted payload (no PII, no user identity, no ballistic/session data). See §8.2 release checklist and CLAUDE.md.

This makes the test trigger permanent in debug and structurally absent from release, rather than something added and removed ad hoc each cycle.

---

## 9. Documentation Standards — ScopeDOPE Specifics

General documentation standards, including in-code documentation rules, commit standards, and CHANGELOG policy, are defined in CBB_SDLC.md §12. ScopeDOPE adds:

### 9.1 `dope-format` Documentation

The `.dope` file format specification is maintained in the `dope-format` repo (private until initial public launch). Versioned independently. Every format change requires: version bump, backward compatibility notes, migration guidance.

**`dope-format` tag policy:** NEVER tag or create a release on `dope-format` unless explicitly instructed. It will be tagged `v3.0` at the ScopeDOPE 1.0 release and not before.

**Public contribution:** `dope-format` becomes public and CC0 at ScopeDOPE 1.0 launch. A `CONTRIBUTING.md` lives in-repo and governs public contributions. See `dope-format/CONTRIBUTING.md`.

---

## 10. Tools Reference

| Tool | Purpose | Notes |
|---|---|---|
| Android Studio | Android development | — |
| Xcode | iOS development | macOS required |
| Google Play Console | Android distribution | $25 one-time |
| Apple Developer | iOS distribution | $99/year |
| Sentry | Crash reporting — KMP attribution | Free tier through beta, Team ($26/mo) at launch; cap $50/mo |
| Feature voting board | Public feedback | Integrated into website and app |
| `build-ammo-db.py` | Ammo database build script | In `scopedope-shared/assets/` |

CBB-wide tools (GitHub, M365, Atlassian, Azure, Slack, Claude Code, Zoho Books) are listed in CBB_SDLC.md §15.2.

---

## Document Control

| Field | Value |
|---|---|
| **Document owner** | `jschwefel@coldboreballisticsllc.com` |
| **Classification** | Confidential (03_-_Confidential/) |
| **Location** | `OneDrive/ScopeDOPE/03_-_Confidential/ScopeDOPE_SDLC.md` |
| **Cross-references** | `CBB_SDLC.md`; `COLD_BORE_STARTUP_GUIDE.md`; `ONEDRIVE_ORGANIZATION_GUIDE.md` |
| **Created** | 2026-06-04 |
| **Last updated** | 2026-06-08 |
| **Next full review due** | 2027-06-04 |

---

## Revision Control Block

**Version approval rule:** A revision number is assigned only when the Founder approves the revision. Changes may accumulate in DRAFT rows without a version number. Individual change entries do not require approval — only the version increment does.

| Rev | Date | Changed By | Reviewed By | Approved By | Summary |
|-----|------|------------|-------------|-------------|---------|
| 0.9 | 2026-06-04 | jschwefel | — | jschwefel | Initial release |
| DRAFT | 2026-06-08 | Claude Code | — | — | Resolved iOS TBDs (SQLDelight, iOS 16); selected Sentry for crash reporting; added rollback policy; added bug SLAs; added dependency audit to release checklist; added self-review checklist; extended PR standards; added SPEC review cadence; added engine performance benchmarks; added per-section sign-off lines; added voting board sync and docs currency check; added key rotation schedule; reframed as ScopeDOPE child SDLC under CBB_SDLC.md; applied all low findings |
| DRAFT | 2026-06-08 | Claude Code | — | — | Major restructure: promoted CBB-wide content to CBB_SDLC.md (§2–§12); retained ScopeDOPE-specific stack, branching model, version numbering, SPEC references, engine validation, BLE testing, release checklist, staged rollout, voting board, crash reporting, KDoc standards; added parent doc references throughout; updated docs-working/ to org-root; added dope-format CONTRIBUTING.md reference |
| DRAFT | 2026-06-08 | Claude Code | — | — | §3 further slimmed: branch structure, rules, and issue-branch policy moved to CBB_SDLC.md §5; §3 now holds only ScopeDOPE-specific items (build manifest alignment, submodule flow, version numbering ladder, website branching exception) |
| DRAFT | 2026-06-08 | Claude Code | — | — | §3.3 tightened: branch naming examples removed (now in CBB_SDLC.md §5.2); lead-in now explicitly identifies §3.3 as the ScopeDOPE implementation of CBB_SDLC.md §5.5 |
| DRAFT | 2026-06-08 | Claude Code | — | — | Further promotion to CBB level: §2.1 GitHub org removed (CBB_SDLC.md §4.1); §3.1 now references CBB_SDLC.md §6.6 for build manifest rule; §4.1 commit examples removed (format in CBB_SDLC.md §12.4); §8.1 bug SLAs removed (CBB_SDLC.md §11.1), voting board mechanism retained; §9.1–9.2 in-code doc and CHANGELOG absorbed into CBB_SDLC.md §12.5–12.6; updated all CBB_SDLC section refs to new numbering |
| DRAFT | 2026-06-08 | Claude Code | — | — | §8.3 Crash Reporting: added mandatory opt-in consent model (default OFF, first-run prompt, mandatory Settings toggle); expanded privacy constraints (permitted payload enumerated; no ballistic/session/file content); tied to SPEC §16.1 |
| DRAFT | 2026-06-09 | Claude Code | — | — | Process-hygiene audit: §7.1 active version → dev-0.9.7-beta.5; §3.3 ladder uses dot pre-release (`-beta.N`); §7.2 release checklist — CHANGELOG every release (was post-1.0.0), added gates for Jira fixVersion/affectedVersion, DRAFT-approval sweep, submodule-on-origin, branch hygiene, GitHub Release with artifact+changelog, public/internal tag semantics, tag both repos; Step 8 issue branches at all stages with Closes: trailer + version fields. Aligns with CBB_SDLC.md §6/§11/§12 revisions of same date. |
| DRAFT | 2026-06-10 | Claude Code | — | — | Added §7.1.5 Release Automation: documents the tag-triggered `release.yml` workflow (DOPE-50) — the tag push is the gate; on `v*` tag it gates on tests/hygiene, builds, creates the GitHub Release, and syncs the Jira version (secret-gated). Spells out what stays manual (signed builds, `[PROMPT]` gates, dev-reset force-push). Annotated §7.2 checklist items now CI-enforced via DOPE-49 workflows (engine tests, debug-output guard, Dependabot). |
