docs: defer service activation until validation

Author: sumitake

README.md

@@ -268,7 +268,6 @@ Install the system service for a dedicated user named `encoder`:
 ```bash
 sudo install -m 0644 systemd/youtube-autoencoder@.service /etc/systemd/system/youtube-autoencoder@.service
 sudo systemctl daemon-reload
-sudo systemctl enable --now youtube-autoencoder@encoder.service
 ```
 
 For a user service instead:
@@ -277,9 +276,10 @@ For a user service instead:
 mkdir -p ~/.config/systemd/user
 cp systemd/user/youtube-autoencoder.service ~/.config/systemd/user/
 systemctl --user daemon-reload
-systemctl --user enable --now youtube-autoencoder.service
 ```
 
+The unit is installed but deliberately left disabled until OAuth, source, ingest, and visible-stream validation succeed.
+
 For Raspberry Pi specific notes, see `docs/raspberry-pi.md`.
 
 ## Configuration Model
@@ -450,6 +450,20 @@ YTA_INSTANCE_ID=encoder-hostname youtube-autoencoder-api run-visible-test \
 
 This validates OAuth, reusable-stream provisioning, idempotent broadcast reconciliation, stream binding, ingest detection, transitions to `testing` and `live`, and explicit completion. The normal unattended service never completes on exit.
 
+### 8. Enable the Service
+
+After visible validation succeeds, enable the system service:
+
+```bash
+sudo systemctl enable --now youtube-autoencoder@encoder.service
+```
+
+For a user service instead:
+
+```bash
+systemctl --user enable --now youtube-autoencoder.service
+```
+
 ### Common Authorization Problems
 
 | Symptom | Likely cause | Fix |

docs/superpowers/plans/2026-07-10-readme-architecture-diagrams.md

@@ -267,7 +267,11 @@ flowchart TD
 ```
 ````
 
-- [ ] **Step 3: Validate the approved diagram count and deployment branches**
+- [ ] **Step 3: Align service activation with successful validation**
+
+Remove both `enable --now` commands from the initial unit-install examples. State that the units remain disabled during provisioning, then add a post-validation section that enables either the system or user service only after the visible test succeeds.
+
+- [ ] **Step 4: Validate the approved diagram count and deployment branches**
 
 Run:
 
@@ -277,12 +281,13 @@ test "$(rg -c '^flowchart TB$' README.md)" -eq 1
 test "$(rg -c '^flowchart TD$' README.md)" -eq 1
 test "$(rg -c '^stateDiagram-v2$' README.md)" -eq 1
 rg -n 'DeploymentStreamDecision|DeploymentValidationDecision|DeploymentDiagnose --> DeploymentStreamDecision|remote-management recovery' README.md
+rg -n 'left disabled|### 8\. Enable the Service|enable --now youtube-autoencoder' README.md
 git diff --check
 ```
 
 Expected: exactly three approved Mermaid blocks, exactly one of each diagram type, both decision IDs found, and zero diff-check errors.
 
-- [ ] **Step 4: Commit the deployment flow**
+- [ ] **Step 5: Commit the deployment flow**
 
 ```bash
 git add README.md

docs/superpowers/specs/2026-07-10-readme-architecture-diagrams-design.md

@@ -97,6 +97,8 @@ Decision nodes will identify the two operator-significant branches:
 
 The detailed README text will state that `--create-stream` requires an existing writable OBS service file with a non-empty placeholder key. A validation failure returns to the reusable-stream decision so provisioning is retried when the prior attempt did not create a stream.
 
+Command-level instructions must follow the same order as the diagram: install the systemd unit during host setup, but do not enable or start it until OAuth, source, ingest, and visible-stream validation have succeeded.
+
 The existing numbered OAuth section remains the source of command and console detail.
 
 ## Mermaid Conventions