# Cold Bore Ballistics LLC — Software Development Life Cycle (Master)

**Owner:** Cold Bore Ballistics LLC
**Scope:** All CBB software projects
**Status:** Active

---

## Purpose

This document defines the CBB-wide software development process — principles, policies, and standards that apply to every project regardless of technology stack. Project-specific SDLCs extend this document with stack and product-line detail.

Where a project-specific SDLC conflicts with this master, the master wins unless the project SDLC explicitly and justifiably overrides a specific section.

---

## Table of Contents

1. [Project SDLCs](#1-project-sdlcs)
2. [Roles](#2-roles)
3. [Development Environment — Machine Setup](#3-development-environment--machine-setup)
4. [Repository Structure](#4-repository-structure)
5. [What Does NOT Go in Any Repository](#5-what-does-not-go-in-any-repository)
6. [Branching Strategy](#6-branching-strategy)
7. [Development Workflow](#7-development-workflow)
8. [Requirements Management](#8-requirements-management)
   - [8.3 docs-working/ Location](#83-docs-working-location)
   - [8.4 AI Development Assistant Session Handoff](#84-ai-development-assistant-session-handoff)
9. [Testing Strategy](#9-testing-strategy)
10. [Release Principles](#10-release-principles)
    - [10.3 Rollback Policy](#103-rollback-policy)
11. [Bug and Feature Management](#11-bug-and-feature-management)
12. [Documentation Standards](#12-documentation-standards)
13. [Security Controls](#13-security-controls)
14. [Issue Tracking Policy](#14-issue-tracking-policy)
15. [Tools Reference](#15-tools-reference)

---

## 1. Project SDLCs

Each active project or product line maintains its own SDLC document that extends this master. Project SDLCs live in their respective OneDrive namespace.

| Project / Product Line | SDLC Document | Status |
|---|---|---|
| ScopeDOPE (Android + iOS) | [ScopeDOPE_SDLC.md](../../ScopeDOPE/03_-_Confidential/ScopeDOPE_SDLC.md) | Active |
| cbb-sign (internal document signing platform) | [CBB_Sign_SDLC.md](../../CBB_Sign/03_-_Confidential/CBB_Sign_SDLC.md) | Active |
| Websites (`scope-dope.com`, `coldboreballisticsllc.com`) | Governed by §4.5 of ScopeDOPE_SDLC.md pending own doc | Active |
| `cbb-utils` | SDLC-exempt — commit directly to `main`; no versioning, changelog, or release checklist | Exempt |
| `cbb-infra` | SDLC-exempt — commit directly to `main`; Terraform state is the release artifact | Exempt |

When a new project reaches the point of requiring structured release management, create a project-specific SDLC and register it here.

---

## 2. Roles

| Role | Responsibilities |
|---|---|
| **Founder / Lead Developer** | Architecture, all development decisions, release authority, IP oversight |
| **AI Development Assistant** | Implementation, refactoring, test generation, documentation, code review support |
| **Software Test Lead** | Manual device testing, UI flow validation, hardware integration testing, regression verification, bug reporting |
| **Marketing Director** | Copy, social media, app store content, proofreading, general writing; repository access required — may contribute directly to app content |

**Note on Claude Code:** Claude Code is the primary implementation tool. All substantive code changes are initiated, reviewed, and approved by the Founder. Claude Code does not have unilateral commit authority. Every session should be treated as a pairing session — Claude Code writes, the Founder reviews and decides.

**Context compaction handling:** Claude Code loses context on long sessions. Use `REQUIREMENTS.md` files as session handoff documents — include only what the current session needs. Do not rely on Claude Code to remember prior sessions. See §7.4.

---

## 3. Development Environment — Machine Setup

Requirements applicable to any developer machine working on CBB projects:

- JDK 17+ (required for Gradle and Android builds)
- Android Studio installed and configured with KMP toolchain
- Xcode installed (macOS required for iOS builds)
- Git configured with SSH key registered to the ColdBoreBallistics GitHub org
- Python 3.x for build scripts (e.g., ammo DB builder)
- Azure CLI installed via the Microsoft install script — never the Debian/Ubuntu-native package

Project-specific SDLCs add stack-specific requirements (language runtimes, IDEs, emulators, hardware).

---

## 4. Repository Structure

### 4.1 Version Control Platform

| Property | Value |
|---|---|
| Platform | GitHub |
| Organization | ColdBoreBallistics |
| Default visibility | Private — all repos unless explicitly designated public |

### 4.2 Repository Registry

All CBB repositories are registered in the Project SDLCs table (§1) or the relevant project SDLC. A repo that exists but is not registered is a gap — add it.

Project SDLCs list the repositories that belong to that product line, their purpose, and their visibility. The CBB-wide exempt repos are:

| Repo | Purpose | SDLC status |
|---|---|---|
| `cbb-utils` | Internal scripts/utilities | Exempt — commit directly to `main` |
| `cbb-infra` | Terraform for Azure | Exempt — commit directly to `main` |

---

## 5. What Does NOT Go in Any Repository

The following must never be committed to any CBB repository under any circumstances:

- API keys, credentials, secrets, or tokens of any kind
- Signing files (`.jks`, `keystore.properties`, `*.p12`)
- NDA, legal filings, or financial documents
- SPEC files (trade secret — OneDrive only)
- Large binaries exceeding ~5 MB (exception: `ammo_builtin.db`, ~100 KB)
- Anything that would expose a user's PII

Violations are release-blocking and require immediate remediation: key rotation plus git history scrub.

---

## 6. Branching Strategy

All non-exempt CBB projects follow trunk-based development. Lightweight — appropriate for a solo founder team.

### 6.1 Universal Rules

- `main` is always deployable — no work-in-progress on `main`
- All active development occurs on version or feature branches
- Branch protection on `main`: no direct push, no force push
- Tags mark released versions — format: `v<version>`
- No credentials, secrets, or sensitive material committed to any branch at any time

### 6.2 Standard Branch Structure

```
main                                          ← production; always deployable; protected
└── dev-<version>                             ← active version dev branch
    └── dev-<version>-<issue-ref>_<slug>      ← issue working branch (used at all stages)
```

**Invariant:** at any time each active repo has exactly **`main` + one `dev-<version>`** long-lived branch, plus any transient issue branches. Prune everything else (release-checklist branch-hygiene step). The legacy `b<version>` branch prefix is **deprecated** — historical tags only.

Version development occurs on `dev-<version>`. When complete, it merges to `main` and is tagged `v<version>`.

The `dev-` prefix keeps dev branches distinct from `v<version>` tags and avoids `git push` ref collisions.

**Branch naming examples:**

```
dev-1.0.0                         ← major release cycle
dev-1.1.0                         ← feature release cycle
dev-1.5.0-rc.1                    ← release candidate (note dot)
dev-1.0.1-PROJ-42_fix_slug        ← Jira issue branch (private repos)
dev-1.0.1-123_fix_slug            ← GH issue branch (dope-format)

v1.0.0                            ← PUBLIC release tag (bare = public)
v1.5.0-rc.1                       ← internal RC tag (suffix = internal)
v0.9.7-beta.5                     ← internal beta tag (suffix = internal)
```

### 6.3 Branch Rules

| Branch | Protection | Who can push |
|---|---|---|
| `main` | Protected — no direct push | Merge from version dev branch only |
| `dev-<version>` | None | Founder |
| `dev-<version>-<issue-ref>_<slug>` | None | Founder; squash-merge back to `dev-<version>` |

### 6.4 Issue Working Branches

**Used at all stages (including pre-1.0.0).** Work on a specific issue is done on an issue working branch cut from the version dev branch, named `dev-<version>-<issue-ref>_<slug>`. *(This supersedes the prior "post-1.0.0 only" rule.)*

- Slug: lowercase, underscores, ≤30 chars
- Issue ref: Jira key for private repos (e.g., `DOPE-42`); GitHub issue number for `dope-format` (e.g., `123`)
- Issue branches **squash-merge** back into `dev-<version>`, are transient (delete after merge), and do not change the version name
- The squash-merge commit carries a `Closes: <KEY>[, <KEY>…]` trailer (feeds changelog + Jira fixVersion)

### 6.5 Version Numbering Principles

All CBB projects use **Semantic Versioning 2.0.0**: `MAJOR.MINOR.PATCH[-prerelease][+build]`

- `MAJOR` — breaking changes or product generation milestones
- `MINOR` — new features, backward-compatible
- `PATCH` — bug fixes, no new features
- **Pre-release identifiers are dot-separated with a numeric counter:** `-alpha.N`, `-beta.N`, `-rc.N` (e.g. `0.9.7-beta.5`, `1.0.0-rc.1`). The dot is required so the counter sorts numerically (`beta.2 < beta.11`, not string-sorted).

**Public vs internal is encoded in the tag string (MANDATORY):**
- A **bare `vX.Y.Z`** tag (no pre-release suffix) means **released to the public**.
- **Any `-pre.release` suffix** means **internal/testing only**.
- Never create a bare `vX.Y.Z` tag for a build that did not ship to the public. Reinforced by the GitHub Release `prerelease` flag (mirrors the tag) and artifact type (debug internal / signed public).

Project SDLCs define the version numbering ladder specific to their release cadence and platform constraints (e.g., hardware expansion milestones, store submission cycles).

### 6.6 Commit and Tag Hygiene

- The version portion of `dev-<version>` must exactly match the declared version in the project's build manifest — project SDLCs specify the manifest file (e.g., `versionName` in `build.gradle.kts` for Android)
- Tags are immutable — never move or delete a release tag
- Pre-release tags (`-alpha`, `-beta`, `-rc`) are created on the dev branch before merging to `main`; the final release tag is created on `main` after merge

---

## 7. Development Workflow

### 7.1 Iteration Cycle

CBB projects use a lightweight kanban-style flow rather than fixed sprints. Work is pulled from the backlog in priority order — no stand-ups, no velocity tracking.

```
Backlog → In Progress → Review → Done
```

**Priority order (universal):**
1. Blocking bugs (crash, data loss)
2. Current milestone items not yet implemented
3. High-priority feature requests
4. Non-blocking bugs
5. Next milestone items

### 7.2 Feature Development Flow

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

```
1. Spec first — the project's authoritative spec document must have a section covering the feature.
   If not, stop; update the spec before implementing.
2. Branch check — must be on the correct active branch per the project SDLC.
   On main or wrong branch: warn and require confirmation.
3. REQUIREMENTS.md — must exist for the session (§8.4). If absent, prompt the user to create before proceeding.
4. Implement.
5. [PROMPT] Self-review — read every changed file and verify:
   - No unguarded debug logging (Log.d, println, System.out.* not in DEBUG guard)
   - No credentials, secrets, or API keys
   - New or changed logic has corresponding tests
   - All changed behavior traces to a spec section
   - Naming follows the coding style guide
   - No commented-out dead code
6. Run test suite per the project SDLC.
7. Commit — conventional format referencing the relevant spec section.
8. [PROMPT] Close the issue when verified complete.
```

### 7.3 Hotfix Flow (Production Bug)

```
1. Cut a patch version branch from main (e.g., dev-1.0.1 from the v1.0.0 tag)
2. Implement fix
3. Test fix
4. Merge to main AND forward-port into the current active dev branch
5. Tag and deploy immediately if severity warrants
```

### 7.4 Pull Request Standards

Open a PR for all merges to `main`. Even as a solo developer, PRs create a permanent record and a natural self-review gate.

PR description must include:
- What changed (1–3 sentences)
- Why it changed (link to spec section, issue number)
- Test coverage (what was tested and how)
- Any spec sections updated

---

## 8. Requirements Management

### 8.1 Source of Truth

**The project's authoritative spec is the requirements document.** All development decisions trace back to it. If the spec and the code disagree, the spec is correct — fix the code or update the spec first.

No feature is implemented that is not in the spec. If a feature needs to be added, update the spec first, then implement.

Every active CBB project will maintain a product spec. The form and location of that spec is defined in the project-specific SDLC.

### 8.2 Spec Update Protocol

The project spec is updated:
- Before implementing any new feature (update first, implement second)
- When a design decision changes prior spec intent
- When a bug reveals a spec ambiguity
- When a validation process produces corrections

The project spec is NOT updated:
- As a post-hoc documentation exercise after code is written
- To reflect implementation details that belong in code comments

### 8.3 `docs-working/` Location

Branch working documents (session handoffs, branch specs, working drafts) are stored one level above the repository tree:

```
/home/jschwefel/repositories/ColdBoreBallistics/docs-working/
```

This location keeps ephemeral working files out of git while keeping them close to the repos. Files here are working artifacts for the current branch only. Permanent documentation lives in OneDrive.

Files that belong here:
- `REQUIREMENTS.md` — AI session handoff (see §7.4)
- `<branch-name>-SPEC.md` — Branch Spec (see CLAUDE.md)
- Any other branch-specific working documents

The directory should be clean (no active branch files) when no work is in flight.

### 8.4 AI Development Assistant Session Handoff

Claude Code loses context between sessions and on long sessions due to context compaction. To maintain continuity, a session handoff document (`REQUIREMENTS.md`) is created at the start of each non-trivial session and updated at the end.

The handoff document captures only what the current session needs — the task, relevant spec sections, current schema if applicable, and acceptance criteria. It is ephemeral, lives in `docs-working/` (§8.3), and is removed when the branch closes.

**Template:**

```markdown
# Session: [brief description]
# Date: YYYY-MM-DD
# Branch: dev-<version>
## Task
## Relevant Spec Sections
## Current Schema (if DB changes involved)
## Acceptance Criteria
- [ ]
## Do Not Touch
## Session Notes
```

---

## 9. Testing Strategy

### 9.1 Test Layers

| Layer | What it covers | When it runs |
|---|---|---|
| **Unit tests** | Core business logic, data transformations, format parsing | Every commit |
| **Integration tests** | Database migrations, API round-trips, service boundaries | Every merge to main |
| **Validation** | Real-world data vs theoretical output (where applicable) | Before every minor release |
| **Manual / device testing** | UI flows, hardware integration, end-to-end pipelines | Before every release |

Project SDLCs define stack-specific test frameworks, coverage targets, and hardware requirements.

### 9.2 General Unit Test Requirements

- All core logic functions must have unit tests
- All data format parse/serialize operations must have round-trip tests
- All database migrations must have migration tests
- Coverage targets defined per project in the project SDLC

### 9.3 Test Data Policy

Test data (real-world confirmed inputs and outputs) is stored in the repo alongside the test suite. It is not production data and must not contain PII. It may be committed to private repos.

---

## 10. Release Principles

- Every release is tagged on `main`
- No release without passing tests
- No release with unguarded debug logging in production code paths
- No release with known high-severity security vulnerabilities in dependencies
- Staged rollouts preferred over full immediate release where platform supports it
- Rollback of completed mobile app releases is not possible — hotfix release is the recovery path

Project SDLCs define version numbering schemes, release checklists, and platform-specific release procedures.

### 10.3 Rollback Policy

For platforms where deployment rollback is not possible (mobile app stores), the recovery path for a critical post-release defect is a hotfix release per §7.3. Halt any in-progress staged rollout, implement the fix, release as a patch version, then resume the rollout.

For server-side and web deployments, rollback procedures are defined in the relevant deployment runbook.

---

## 11. Bug and Feature Management

### 11.1 Bug Severity Classification and SLAs

| Label | Definition | Response | Resolution target |
|---|---|---|---|
| `bug:critical` | Crash or data loss | User-facing acknowledgment within 24 hours of confirmed reproduction | Hotfix release within 14 days; product pulled from distribution if data loss confirmed and no fix imminent |
| `bug:major` | Significant incorrect behavior | Status update within 7 days | Targeted for next patch release |
| `bug:minor` | Minor incorrect behavior, cosmetic | Status update within 7 days | Targeted for next minor release |

### 11.2 Internal Issue Tracking

Issue tracking is Jira-first for all private repos. GitHub Issues for `dope-format` (public) only. See §14 for the full policy.

**Issue labels (standard across projects):**

| Label | Meaning |
|---|---|
| `bug:critical` | Crash or data loss |
| `bug:major` | Significant incorrect behavior |
| `bug:minor` | Minor incorrect behavior, cosmetic |
| `feature:milestone` | In scope for the current milestone |
| `feature:backlog` | Planned for a future milestone |

Project SDLCs add domain-specific labels (e.g., `engine`, `ble`, `print`, `ios`, `android`).

### 11.3 Version Fields and Traceability — MANDATORY

For every issue across all Jira projects (DOPE, CBB, ESUP, …):

- **`fixVersion`** — set when an issue moves to In Review/Done: the release it ships in (e.g. `0.9.6-beta4`). Mandatory for all issue types. This makes "what shipped in release X" a query, and feeds the CHANGELOG.
- **`affectedVersion`** (Jira "Affects Version/s") — set for **Bug** issues: the version(s) where the defect was observed/reported. Reveals defect longevity and scopes regression/backport. Stories/Tasks: N/A.
- **Release-checklist gate:** before tagging, confirm every issue in the release has `fixVersion` set, every Bug has `affectedVersion`, and issues are linked to their support (ESUP) counterparts.

### 11.4 Resolution and Reopen Hygiene — all projects

- **Standard resolution values** across all projects: `Done`, `Won't Do`, `Duplicate`, `Cannot Reproduce`, `Superseded`. The resolve transition must expose the resolution dropdown so the correct value is chosen (not auto-set to `Done`).
- **A "Reopen" transition** from Done/Resolved back to an active status must exist on every project workflow, so a mis-resolved item can be corrected without a comment-only workaround. *(Jira-admin task — see the Jira workflow guide in docs-working.)*

---

## 12. Documentation Standards

### 12.1 General

- Documentation is written before implementation — never post-hoc
- All docs follow the CBB Technical Documentation Guide (`Style_Guides/TECHNICAL_DOCUMENTATION_GUIDE.md`)
- No spaces in filenames — underscores only
- Classification tiers apply to all documents — consult `ONEDRIVE_ORGANIZATION_GUIDE.md` before creating files

### 12.2 Versioned Documents

Documents with a revision control block (SDLCs, runbooks, architecture references, policies, guides) follow the version approval rule:

- Changes are recorded in the revision control block as `DRAFT`
- A version number is assigned only when the Founder explicitly approves the revision
- Individual change entries do not require approval — only the version increment does
- No version number in the document header — the revision control block at the bottom is the sole authority on version and date
- **DRAFT-approval sweep (release gate):** the revision block handles per-document approval, but pending DRAFTs can accumulate unseen across many documents. At each release, review and approve/clear any pending `DRAFT` revisions across the affected SPEC, SDLC, policies, and runbooks. (Added to the Release Checklist.) This converts "indefinitely pending" into "resolved at each release boundary."

### 12.3 Infrastructure Documentation

All infrastructure domains maintain the standard doc set: Architecture Reference, Operating Runbook, Rebuild Guide, Acquisition Brief. See `ONEDRIVE_ORGANIZATION_GUIDE.md` for the full mandatory doc type list.

### 12.4 Commit Standards

All CBB projects use conventional commit format:

```
type(scope): short description (ISSUE-KEY)

[optional body — why, not just what]

[Closes: ISSUE-KEY[, ISSUE-KEY…]   ← on squash-merge commits]
[Co-Authored-By: …]
```

**Types:** `feat`, `fix`, `test`, `docs`, `chore`, `refactor`, `perf`, `ci`, `build`, `style`

**Issue linkage — MANDATORY:**
- **Per-change commits** reference the issue in the **subject**: `fix(scope): description (DOPE-NN)`. Base the description on the **Jira issue title** so it is self-explanatory.
- **Squash-merge commits** carry a `Closes: <KEY>[, <KEY>…]` **trailer** listing every issue in the merge. This survives the squash, feeds the CHANGELOG, and drives Jira `fixVersion` stamping.

Commit messages describe *why*, not just *what*. Reference a spec section when relevant. No emoji. No vague messages ("fix stuff", "updates").

### 12.5 CHANGELOG Standards

**When:** **Every tagged release, per project** *(this supersedes the prior "post-1.0.0 only" rule)*. Each release repo maintains a `CHANGELOG.md` in [Keep a Changelog](https://keepachangelog.com/) format. SDLC-exempt repos (e.g. `cbb-utils`) are excepted.

**`[Unreleased]` discipline:** add entries **as work lands on `dev`** (at each issue squash-merge — one entry per issue), not retroactively. At release, rename `[Unreleased]` → `## [version] - YYYY-MM-DD` and open a fresh `[Unreleased]`.

**How:**
- Source: commit subjects + issue ref (`(KEY)`) + Jira `fixVersion`
- `feat:` → Added/Changed; `fix:` → Fixed; breaking change (`!`) → Changed/Removed
- Skip non-user-facing types: `chore`, `test`, `docs`, `refactor`, `perf`, `ci`, `build`, `style`
- Entries are user-facing prose — never raw commit lines, never engine internals or trade-secret details
- Mark internal/beta entries `_(internal beta)_`
- Claude Code drafts entries; Founder approves before commit

**At release (MANDATORY):** copy the version's section into the GitHub Release body AND attach `CHANGELOG.md`, alongside the build artifact. (A tag without a GitHub Release carrying artifact + changelog is incomplete — see project Release Process.)

**Starting point:** changelogs started clean at the current build (ScopeDOPE: `0.9.6-beta4`); releases prior to that point at git tags rather than being reconstructed.

### 12.6 In-Code Documentation

- All public API functions must have documentation comments (format per language convention — KDoc for Kotlin, DocC/`///` for Swift, etc.)
- Complex algorithms must have inline comments explaining the math or logic, not just restating the code
- State machines (BLE drivers, workflow orchestrators) must have comments describing each state transition
- No commented-out dead code committed to any repo

### 12.7 Spec / Format Documentation (Public-Facing)

Any public-facing file format or API spec maintained in a standalone repo (e.g., `dope-format`) follows the project's own contribution and versioning guide. Every format change requires:
- Version bump in the spec
- Backward compatibility notes
- Migration guidance for existing data

---

## 13. Security Controls

### 13.1 Credential and Secret Management

- No credentials, API keys, secrets, or signing files committed to any repository
- Secret management: Azure Key Vault for production secrets; environment variables or platform keystores for runtime secrets
- See `Azure_Key_Vault_Operating_Runbook.md`

### 13.2 Dependency Management

- Review all new dependencies before adding
- Prefer well-maintained, widely-used libraries with active security patch histories
- Run a dependency audit before each minor release — no new high-severity CVEs in direct or transitive dependencies
- Dependabot alerts enabled on all GitHub repos

### 13.3 GitHub Security Settings (All Repos)

- Branch protection on `main`: no force push, no direct commit
- Dependabot alerts enabled
- Secret scanning enabled
- No public forks permitted (private org setting)
- `dope-format` exception: becomes public at ScopeDOPE 1.0 launch (CC0)

### 13.4 Trade Secret Protection

The ScopeDOPE ballistics engine source and DOPE-Blend™ methodology are trade secrets. No engine internals, algorithmic descriptions, or DOPE-Blend details in:

- Public channels, social media, or issue trackers
- Commit messages or PR descriptions
- CHANGELOG.md entries
- Any document outside `04_-_Highly_Confidential/`

### 13.5 Key Rotation Schedule

| Key / Secret | Rotation trigger | Minimum rotation cadence |
|---|---|---|
| Application signing keys | Compromise suspected | Before each major release (X.0.0) |
| Third-party API keys and auth tokens | Compromise suspected; team member offboarding | Annually |
| Azure Key Vault secrets | Per Azure Key Vault Operating Runbook | Per Azure Key Vault Operating Runbook |
| Platform developer credentials | Compromise suspected | As required by platform policy |

Secrets stored in Azure Key Vault are presumed valid unless the Founder initiates rotation.

### 13.6 Vendor and Tool Security

Any new vendor or tool accessing confidential or PII data requires a written Security Review before use. Template: `OneDrive/CBB_Corporate/03_-_Confidential/Infrastructure/Security_Review_Template.md`.

---

## 14. Issue Tracking Policy

| Repo | Tracker |
|---|---|
| `dope-format` (public) | GitHub Issues only — never Jira |
| All other repos (private) | Jira — projects DOPE, CBB, ESUP |

Never create GitHub issues on private repos. Never create Jira issues for `dope-format`. Duplicate check required before creating any Jira issue.

---

## 15. Tools Reference

### 15.1 New Tool Adoption

Any new development tool, SDK, or service requires:
1. Evaluation documented (fit, cost, privacy, maintenance status)
2. Cost approval per the CBB Operating Directives (CLAUDE.md) if billable
3. Security Review if the tool accesses confidential or PII data
4. Registration in the relevant project SDLC tools table

### 15.2 CBB-Wide Tools

| Tool | Purpose |
|---|---|
| GitHub (ColdBoreBallistics org) | Version control, issues, PRs — private org |
| Microsoft 365 / OneDrive / SharePoint | Document storage and collaboration |
| Atlassian (Jira / Confluence / JSM) | Issue tracking, internal wiki, support |
| Azure | Cloud infrastructure — see `Azure_Architecture_Reference.md` |
| Slack | Internal communications |
| Claude Code | AI-assisted development — primary implementation tool |
| Zoho Books | Accounting |

Project SDLCs register additional tools specific to their stack.

---

## Document Control

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

---

## 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 |
|-----|------|------------|-------------|-------------|---------|
| DRAFT | 2026-06-08 | Claude Code | — | — | Initial creation — CBB master SDLC extracted from ScopeDOPE_SDLC.md |
| DRAFT | 2026-06-08 | Claude Code | — | — | Major expansion: absorbed roles (§2), machine setup (§3), what-not-to-commit (§4), full dev workflow (§6), requirements management (§7) with docs-working/ location and AI handoff, test strategy (§8), rollback policy (§9.3), bug management (§10), commit/changelog/spec standards (§11), key rotation schedule (§12.5); slimmed ScopeDOPE_SDLC.md to product-specific content; CBB-wide tools expanded |
| DRAFT | 2026-06-08 | Claude Code | — | — | Expanded §5 from principles-only to full branching strategy: branch structure, branch rules, issue working branch policy (pre/post-1.0.0), version numbering principles, commit/tag hygiene; ScopeDOPE_SDLC.md §3 slimmed to ScopeDOPE-specific items only |
| DRAFT | 2026-06-08 | Claude Code | — | — | Added branch naming examples to §5.2; §5.5 now explicitly calls out that project SDLCs define the version numbering ladder |
| DRAFT | 2026-06-08 | Claude Code | — | — | Added §4 Repository Structure (GitHub org, repo registry); merged bug SLAs into §11.1; absorbed CHANGELOG timing into §12.5; added §12.6 In-Code Documentation; generalised §6.6 build manifest alignment; renumbered §4–§15 throughout |
| DRAFT | 2026-06-09 | Claude Code | — | — | Process-hygiene audit changes: §6 issue branches now used at ALL stages (was post-1.0.0 only); added main+1-dev invariant and `b<version>` deprecation; §6.5 adopted strict SemVer 2.0.0 (dot pre-release `-beta.N`) + public/internal tag rule (bare `vX.Y.Z`=public, suffix=internal); §12.4 mandatory issue linkage (subject `(KEY)` + `Closes:` trailer); §12.5 CHANGELOG every release (was post-1.0.0 only) + Keep-a-Changelog + release attachment; §11.3 fixVersion/affectedVersion mandatory; §11.4 resolution/reopen hygiene all projects; §12.2 DRAFT-approval release sweep. |
