docs: note master is not locked in yet

The repo is still being assembled as a templated workspace, so the branch
conventions are the intended end state rather than a current rule. Recording
that in the README so the 'master is protected and immutable' line is not read
as an active restriction while the template is still taking shape.

README.md

@@ -4,6 +4,12 @@ This repo houses the code-like files for NCMR music videos. Binary assets live e
 
 ## Structure
 
+> **Repo state: workspace under construction.** `master` is *not* locked in yet —
+> it is still being assembled as the shared template. Until it is locked, any
+> branching strategy is fine and template/tooling work can land on `master`
+> directly. The branch conventions below describe the intended end state, not a
+> rule currently in force.
+
 ### `master` branch — shared template
 
 This branch holds the common scaffolding:
@@ -29,7 +35,8 @@ mkdir -p <song-name>
 # Place your song-specific compositions, assets manifests, etc.
 ```
 
-The `master` branch remains protected and mostly immutable. Song branches are independent.
+Once `master` is locked in it remains protected and mostly immutable. Until then,
+song branches are a rehearsal for that end state, not a requirement.
 
 ## Guideline
 
@@ -43,8 +50,9 @@ what each file is will be mandatory. Keep it as `BOM.md` alongside your song ass
 
 ### Branching
 
-- `master` — minimal template, protected
+- `master` — minimal template (protected once locked in)
 - `<song>/master` — song-specific work
 - `<song>/<feature>` — parallel features for a song
 
-This repo's branching rules supersede any generic git operation conventions.
+Once `master` is locked, this repo's branching rules supersede any generic git
+operation conventions. Before that point, use whatever is convenient.