rename(project): MS Battery to BaselineMS across code, config, and docs

Project-wide rename. New name is BaselineMS in all prose and identifiers.

Code:
- Move Java package com.mustafan4x.msbattery to com.mustafan4x.baselinems (main and test source trees).
- Rename Application class MSBatteryApp to BaselineMSApp; update AndroidManifest entry.
- Update Gradle namespace and applicationId to com.mustafan4x.baselinems.
- Update settings.gradle.kts rootProject.name to BaselineMS.
- Update strings.xml app_name to BaselineMS.
- Rename Room database file from msbattery.db to baselinems.db (no production users; emulator walkthrough still deferred per STATUS.md).
- Move Room schema directory app/schemas/com.mustafan4x.msbattery.data.AppDatabase to com.mustafan4x.baselinems.data.AppDatabase so MigrationTestHelper resolves v1 and v2 schemas under the new fully qualified class name.

Documentation:
- Replace MS Neuro Battery, MS Battery, MS-Battery, MSBattery, MsBattery with BaselineMS across SPEC.md, STATUS.md, README.md, CLAUDE.md, GETTING-STARTED.md, all agent briefs, all phase plans, all docs subfolders, and all citation logs.
- Replace lowercase msbattery with baselinems where it appeared (paths, filenames, identifiers).
- Update repo URL references (https://github.com/Mustafan4x/MS-Battery to https://github.com/Mustafan4x/BaselineMS) and absolute path references (/home/mustafa/src/MS-Battery to /home/mustafa/src/BaselineMS).

Verification:
- ./gradlew :app:testDebugUnitTest --rerun-tasks: 105 tests, 0 failures, 0 errors, 0 skipped (matches STATUS.md baseline).
- Final grep for any rename variants returns 0 matches outside .git, build, and .gradle.

Bare references to MS the disease (multiple sclerosis) are not affected; substitution targets only struck multi-character project name forms.

Author: MustafaNazeer

CLAUDE.md

@@ -1,14 +1,14 @@
-# CLAUDE.md, MS Neuro Battery project instructions
+# CLAUDE.md, BaselineMS project instructions
 
 This file is auto loaded by Claude Code in every session opened in this directory. It defines how the project is organized, how phases are paced, how specialists are dispatched, and which conventions every session must follow. Changes to this file change the project; read it carefully before editing.
 
 ## Project at a glance
 
-MS Neuro Battery is a native Android application that lets people living with Multiple Sclerosis self administer a five test neurological battery once a week, track results longitudinally on device, and share a clinician ready PDF report. The technical centerpiece is a validated gait analysis pipeline. Privacy posture is strict: no `INTERNET` permission, no cloud sync, no account, no telemetry.
+BaselineMS is a native Android application that lets people living with Multiple Sclerosis self administer a five test neurological battery once a week, track results longitudinally on device, and share a clinician ready PDF report. The technical centerpiece is a validated gait analysis pipeline. Privacy posture is strict: no `INTERNET` permission, no cloud sync, no account, no telemetry.
 
 Full specification lives at `SPEC.md` at the root of this project. Always treat `SPEC.md` as the source of truth for what is being built. Always treat `STATUS.md` as the source of truth for what phase is next.
 
-GitHub remote: https://github.com/Mustafan4x/MS-Battery
+GitHub remote: https://github.com/Mustafan4x/BaselineMS
 
 ## Inherited rules from the user's global CLAUDE.md
 
@@ -91,13 +91,13 @@ Never start, pause, or complete a phase without updating `STATUS.md` first.
 When the PM dispatches a specialist, use exactly this prompt shape (substitute the phase number and agent path):
 
 ```
-You are the <Agent name> for the MS Neuro Battery project.
+You are the <Agent name> for the BaselineMS project.
 
 Read these files in order before doing anything else:
-1. /home/mustafa/src/MS-Battery/SPEC.md
-2. /home/mustafa/src/MS-Battery/agents/<NN-agent-name>.md
-3. /home/mustafa/src/MS-Battery/STATUS.md
-4. /home/mustafa/src/MS-Battery/CLAUDE.md (specifically the "Inherited rules" and the dispatch template sections)
+1. /home/mustafa/src/BaselineMS/SPEC.md
+2. /home/mustafa/src/BaselineMS/agents/<NN-agent-name>.md
+3. /home/mustafa/src/BaselineMS/STATUS.md
+4. /home/mustafa/src/BaselineMS/CLAUDE.md (specifically the "Inherited rules" and the dispatch template sections)
 
 You are working on Phase <N>. Stay strictly in your role as defined in your agent brief.
 Do not recursively dispatch subagents; if you need work done outside your role, stop and report
@@ -149,7 +149,7 @@ A small set of skills is project relevant:
 ## Directory layout
 
 ```
-~/src/MS-Battery/
+~/src/BaselineMS/
 ├── CLAUDE.md                    (this file)
 ├── SPEC.md                      (project specification)
 ├── STATUS.md                    (single source of truth for phase status)

GETTING-STARTED.md

@@ -1,14 +1,14 @@
-# Getting started, MS Neuro Battery
+# Getting started, BaselineMS
 
 This is the first session walkthrough. If this is the very first session opened in this directory, follow these steps in order. After Phase 0 is complete, future sessions just read `STATUS.md` and run the "work on the next phase" flow.
 
 ## Before you start
 
 Check that:
 
-- `~/src/MS-Battery/SPEC.md` exists.
-- `~/src/MS-Battery/STATUS.md` exists and "Next phase" reads `Phase 0: Bootstrap setup`.
-- The user has confirmed the GitHub remote at https://github.com/Mustafan4x/MS-Battery is reachable.
+- `~/src/BaselineMS/SPEC.md` exists.
+- `~/src/BaselineMS/STATUS.md` exists and "Next phase" reads `Phase 0: Bootstrap setup`.
+- The user has confirmed the GitHub remote at https://github.com/Mustafan4x/BaselineMS is reachable.
 - Android Studio Iguana or later is installed on the machine where the build will actually happen. The session itself can run on Linux without Android Studio; the build steps in Phase 0 onward require Android Studio.
 
 If any of those is missing, stop and tell the user.
@@ -29,7 +29,7 @@ You are the Project Manager unless the user tells you otherwise.
 
 Briefly state:
 
-> "I'm the PM for MS Neuro Battery. The next phase is Phase 0, Bootstrap setup. Before I start it, I need to run the check-in protocol."
+> "I'm the PM for BaselineMS. The next phase is Phase 0, Bootstrap setup. Before I start it, I need to run the check-in protocol."
 
 Then ask the three check-in questions verbatim:
 
@@ -43,7 +43,7 @@ Wait for answers. Do not proceed without them.
 
 If the user says continue, briefly review `docs/plan.md` Phase 0 section with the user. Confirm the agents you intend to dispatch:
 
-- DevOps Engineer: scaffold the Android Studio project at `~/src/MS-Battery/app/`, wire git, push initial commit to the remote.
+- DevOps Engineer: scaffold the Android Studio project at `~/src/BaselineMS/app/`, wire git, push initial commit to the remote.
 - Security Engineer: write `docs/security/threat-model.md` and `docs/security/hardening-checklist.md`.
 - UI/UX Designer: write `docs/design/tokens.md` with Material 3 baseline plus accessibility tokens.
 - Documentation Engineer: write `docs/architecture.md` and finalize `README.md`.
@@ -60,23 +60,23 @@ Use the Task tool dispatch template from `CLAUDE.md` verbatim. A concrete exampl
 
 ```
 Task tool prompt:
-You are the DevOps Engineer for the MS Neuro Battery project.
+You are the DevOps Engineer for the BaselineMS project.
 
 Read these files in order before doing anything else:
-1. /home/mustafa/src/MS-Battery/SPEC.md
-2. /home/mustafa/src/MS-Battery/agents/08-devops-engineer.md
-3. /home/mustafa/src/MS-Battery/STATUS.md
-4. /home/mustafa/src/MS-Battery/CLAUDE.md (specifically the "Inherited rules" and the dispatch template sections)
+1. /home/mustafa/src/BaselineMS/SPEC.md
+2. /home/mustafa/src/BaselineMS/agents/08-devops-engineer.md
+3. /home/mustafa/src/BaselineMS/STATUS.md
+4. /home/mustafa/src/BaselineMS/CLAUDE.md (specifically the "Inherited rules" and the dispatch template sections)
 
 You are working on Phase 0. Stay strictly in your role as defined in your agent brief.
 Do not recursively dispatch subagents; if you need work done outside your role, stop and report
 the need back so the PM can dispatch it.
 
 Your Phase 0 deliverables:
-1. Initialize the Android Studio project at /home/mustafa/src/MS-Battery/app/ following Task 1
-   of /home/mustafa/src/MS-Battery/docs/plans/phase-1-foundation.md.
+1. Initialize the Android Studio project at /home/mustafa/src/BaselineMS/app/ following Task 1
+   of /home/mustafa/src/BaselineMS/docs/plans/phase-1-foundation.md.
 2. Wire git: `git init` at the project root, `git remote add origin
-   https://github.com/Mustafan4x/MS-Battery.git`, push the initial commit.
+   https://github.com/Mustafan4x/BaselineMS.git`, push the initial commit.
 3. Configure GitHub Actions on Linux runners to run `./gradlew :app:testDebugUnitTest` on PRs.
 
 When you finish, report:

README.md

@@ -1,12 +1,12 @@
-# MS Neuro Battery
+# BaselineMS
 
 A native Android application that lets people living with Multiple Sclerosis self administer a short, sensor backed set of five tests once a week, track results longitudinally on device, and share a clinician facing PDF report.
 
 The technical centerpiece is a gait analysis pipeline that turns 30 seconds of phone IMU data into stride length, cadence, step time variability, and stride asymmetry. Pipeline accuracy is validated against a measured walking course; methodology and error numbers documented in the project's Validation section.
 
 ## Problem
 
-MS clinic visits typically happen every three to six months. Between visits, people living with MS often want a simple, self directed way to keep an objective record of how their walking, hand dexterity, vision, cognition, and speech are changing, so that they can bring something concrete to their next neurology appointment. Existing research apps in this space are study only and not available as a self administered self tracking application for the broader community. MS Neuro Battery aims to fill that gap as a personal record keeping tool, not as a diagnostic instrument. The full problem statement is in `SPEC.md` Section 2.
+MS clinic visits typically happen every three to six months. Between visits, people living with MS often want a simple, self directed way to keep an objective record of how their walking, hand dexterity, vision, cognition, and speech are changing, so that they can bring something concrete to their next neurology appointment. Existing research apps in this space are study only and not available as a self administered self tracking application for the broader community. BaselineMS aims to fill that gap as a personal record keeping tool, not as a diagnostic instrument. The full problem statement is in `SPEC.md` Section 2.
 
 ## Solution
 
@@ -32,13 +32,13 @@ The application is a native Android codebase in Kotlin and Jetpack Compose, orga
 
 ### Running
 
-Open `~/src/MS-Battery` in Android Studio Iguana or later, select an Android 12 or later emulator (or attach a physical device with USB debugging enabled), and press Run.
+Open `~/src/BaselineMS` in Android Studio Iguana or later, select an Android 12 or later emulator (or attach a physical device with USB debugging enabled), and press Run.
 
 From the command line:
 
 ```
 ./gradlew :app:installDebug
-adb shell am start -n com.mustafan4x.msbattery/.MainActivity
+adb shell am start -n com.mustafan4x.baselinems/.MainActivity
 ```
 
 ### Testing
@@ -72,4 +72,4 @@ Full citations and the specific findings the project relies on are in `docs/sour
 
 ## Repository
 
-https://github.com/Mustafan4x/MS-Battery
+https://github.com/Mustafan4x/BaselineMS

SPEC.md

@@ -1,4 +1,4 @@
-# MS Neuro Battery: Design Specification
+# BaselineMS: Design Specification
 
 **Date:** 2026-05-06
 **Status:** Draft, approved by user. Updated 2026-05-06 to switch platform from iOS native to Android native.
@@ -149,7 +149,7 @@ Each module is grounded in a clinically validated MS assessment. Selection crite
 - **User experience.** 30 seconds of alternating taps on two on screen targets, performed once with the dominant hand and once with the non dominant hand.
 - **Sensors.** Touchscreen only.
 - **Outputs.** Tap rate (taps per second), inter tap interval coefficient of variation, dominant versus non dominant asymmetry, miss rate (operationally defined below).
-- **Miss rate operational definition.** A tap is classified into one of three buckets: (1) **valid**, the tap lands inside one of the two on screen target hit regions and alternates from the previously valid tap; (2) **non alternating**, the tap lands inside a target hit region but inside the same target as the previous valid tap; (3) **off target**, the tap lands outside both target hit regions. The two failure buckets are persisted as separate integer counts (`non_alternating_taps`, `off_target_taps`) per round, so the Phase 9 Reporting layer can present the two failure modes either separately or rolled up. The single rolled up `miss_rate` reported at the session level is computed across both rounds combined as `(non_alternating_taps + off_target_taps) / (valid_taps + non_alternating_taps + off_target_taps)`. This operational definition is the Option A variant ratified in the Clinical Validator's 2026-05-07 Phase 2 sign off (`docs/source/clinical-references.md`, "Phase 2 sign off, Bilateral Tap Test", Revision 1). The implementation lives in `app/src/main/java/com/mustafan4x/msbattery/battery/tap/TapFeatures.kt`.
+- **Miss rate operational definition.** A tap is classified into one of three buckets: (1) **valid**, the tap lands inside one of the two on screen target hit regions and alternates from the previously valid tap; (2) **non alternating**, the tap lands inside a target hit region but inside the same target as the previous valid tap; (3) **off target**, the tap lands outside both target hit regions. The two failure buckets are persisted as separate integer counts (`non_alternating_taps`, `off_target_taps`) per round, so the Phase 9 Reporting layer can present the two failure modes either separately or rolled up. The single rolled up `miss_rate` reported at the session level is computed across both rounds combined as `(non_alternating_taps + off_target_taps) / (valid_taps + non_alternating_taps + off_target_taps)`. This operational definition is the Option A variant ratified in the Clinical Validator's 2026-05-07 Phase 2 sign off (`docs/source/clinical-references.md`, "Phase 2 sign off, Bilateral Tap Test", Revision 1). The implementation lives in `app/src/main/java/com/mustafan4x/baselinems/battery/tap/TapFeatures.kt`.
 - **Quality score factors.** Sufficient number of taps recorded, sustained engagement across the full window, taps actually landing within target bounds.
 
 ### 6.2 Gait Test (deep module)
@@ -326,7 +326,7 @@ Captured here as a single section because validation is what gives the applicati
 2. **Real ground truth on gait.** As described in Section 7.2.
 3. **Test retest reliability across the full battery.** 5 repeated weekly sessions on healthy controls within a short time window, ICC above 0.75 on the primary feature of each test.
 4. **Beta cohort feedback.** Internal test track in Google Play Console with a cohort of 10 to 20 people, with a target of at least 2 to 3 self identified MS patients recruited through an MS support community with informed consent. Two week duration. Survey based feedback on usability, perceived value, and clarity of the report.
-5. **Retention measurement during the beta cohort.** Day 1, day 7, day 14, day 30 retention curves measured on the beta cohort, with reminders enabled by default. The empirical floor from the published Floodlight Open analysis (Galati et al. 2024, *JMIR Human Factors* 11:e57033, US MS cohort) is day 30 retention of 30.8 percent with reminders versus 9.7 percent without. MS Battery's target is to meet or exceed 30.8 percent day 30 retention with reminders enabled. The patient owned PDF for the neurologist (a clinical artifact Floodlight Open did not provide) is the project's intended retention lever, leveraging the Oh et al. 2024 finding that clinical supervision was the single largest persistence driver in the Floodlight cohort.
+5. **Retention measurement during the beta cohort.** Day 1, day 7, day 14, day 30 retention curves measured on the beta cohort, with reminders enabled by default. The empirical floor from the published Floodlight Open analysis (Galati et al. 2024, *JMIR Human Factors* 11:e57033, US MS cohort) is day 30 retention of 30.8 percent with reminders versus 9.7 percent without. BaselineMS's target is to meet or exceed 30.8 percent day 30 retention with reminders enabled. The patient owned PDF for the neurologist (a clinical artifact Floodlight Open did not provide) is the project's intended retention lever, leveraging the Oh et al. 2024 finding that clinical supervision was the single largest persistence driver in the Floodlight cohort.
 
 The numbers from layers 1, 2, and 3 are documented in a `Validation` section of the project README. The retention curves from layer 5 are reported in a `Retention` subsection of the same README.
 

STATUS.md

@@ -1,4 +1,4 @@
-# STATUS, MS Neuro Battery
+# STATUS, BaselineMS
 
 This file is the single source of truth for which phase is next. Read it at the start of every session.
 

agents/00-project-manager.md

@@ -10,7 +10,7 @@ The PM **must** stop and ask the user when uncertain about a decision, fact, or
 
 ## Mission
 
-Sequence and ship the MS Neuro Battery from bootstrap through Phase 11 by dispatching the right specialist at the right time, gating phase transitions on quality, and keeping `STATUS.md` honest about where the project actually is.
+Sequence and ship the BaselineMS from bootstrap through Phase 11 by dispatching the right specialist at the right time, gating phase transitions on quality, and keeping `STATUS.md` honest about where the project actually is.
 
 ## Inputs
 
@@ -23,7 +23,7 @@ Sequence and ship the MS Neuro Battery from bootstrap through Phase 11 by dispat
 
 ## Outputs
 
-- Updates to `/home/mustafa/src/MS-Battery/STATUS.md` at three moments per phase (start, pause, complete).
+- Updates to `/home/mustafa/src/BaselineMS/STATUS.md` at three moments per phase (start, pause, complete).
 - New `docs/plans/phase-N-<name>.md` files for phases that need a detailed plan beyond the existing Phase 1 plan. Written using the `superpowers:writing-plans` skill.
 - ADRs in `docs/adr/` for cross cutting decisions.
 - Dispatch records: short notes (kept in session memory or in a `docs/dispatch-log.md` if the user wants persistence) recording which specialists were dispatched in which phase and what they returned.

agents/01-clinical-validator.md

@@ -20,7 +20,7 @@ Ensure every test in the battery is a faithful, defensible digital adaptation of
 ## Outputs
 
 - Sign offs (or rejections, with rationale) on each test design before that test's phase begins.
-- Notes appended to `/home/mustafa/src/MS-Battery/docs/source/clinical-references.md` when new references are consulted.
+- Notes appended to `/home/mustafa/src/BaselineMS/docs/source/clinical-references.md` when new references are consulted.
 - A "validation acceptance criteria" memo for Phase 5, listing the specific numbers (stride length error percentage, cadence error percentage, ICC for each primary feature) the project must hit and the reasoning.
 - Reviews of any user facing clinical text on screen and in the PDF report.
 

agents/02-signal-processing-engineer.md

@@ -19,14 +19,14 @@ Implement, test, and validate every DSP module in the application: gait pipeline
 
 ## Outputs
 
-- `app/src/main/java/com/mustafan4x/msbattery/dsp/` package containing pure Kotlin DSP modules with no Android sensor or UI dependencies, including:
+- `app/src/main/java/com/mustafan4x/baselinems/dsp/` package containing pure Kotlin DSP modules with no Android sensor or UI dependencies, including:
   - Butterworth low pass filter.
   - Madgwick orientation filter.
   - Step detection (peak finder with prominence and inter peak distance constraints).
   - Stride pairing and segmentation.
   - Zero velocity update (ZUPT) stride length integrator.
   - Feature extractor producing cadence, stride length, step time CV, stride asymmetry, double support time.
-- `app/src/test/java/com/mustafan4x/msbattery/dsp/` directory with tests using synthetic IMU traces with known parameters. Target: 90 percent line coverage on the DSP module; stride length within 2 percent on clean synthetic signals.
+- `app/src/test/java/com/mustafan4x/baselinems/dsp/` directory with tests using synthetic IMU traces with known parameters. Target: 90 percent line coverage on the DSP module; stride length within 2 percent on clean synthetic signals.
 - For voice: pure Kotlin acoustic feature extractor (or, per the ADR in Phase 8, a thin wrapper around TarsosDSP).
 - ADRs for non obvious DSP choices (Madgwick from scratch vs library, TarsosDSP vs roll our own).
 - Validation report sections in `docs/source/validation-report.md` documenting Phase 5 numbers.

agents/03-android-engineer.md

@@ -23,7 +23,7 @@ Build the Android application on top of the data layer, the DSP modules, and the
 
 ## Outputs
 
-- All Kotlin source in `app/src/main/java/com/mustafan4x/msbattery/` outside `data/` (owned by Data Engineer) and `dsp/` (owned by Signal Processing Engineer). Specifically:
+- All Kotlin source in `app/src/main/java/com/mustafan4x/baselinems/` outside `data/` (owned by Data Engineer) and `dsp/` (owned by Signal Processing Engineer). Specifically:
   - `battery/` (TestModule interface implementations, BatteryOrchestrator, MockTestModule replacement per phase).
   - `ui/` (Compose screens, navigation, theming).
   - `signals/` (Sensor capture glue: `SensorManager`, `AudioRecord`, `CameraX`, exposed as `Flow`).