Remove unnecessary deployment gates and record preparation

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # Implementation Plan 0016: Deploy the D&D Pipeline to `pipeline-dnd`
 
-Status: blocked
+Status: in_progress
 
 Target executor: GPT-5.6-Terra
 
@@ -31,6 +31,14 @@ scope, rationale, target state, and acceptance criteria.
   Do not solicit secrets in chat or create placeholder credentials.
 - Stop dependent work when operational inputs are missing or validation fails.
   Record the concrete blocker; local checks do not prove a live deployment.
+- Evaluate failures against the required outcome. Documentation rendering,
+  incidental warnings, and optional diagnostics are not deployment acceptance
+  gates. Report them separately unless they demonstrate a failure of required
+  installation, parsing, convergence, or application behavior. Do not add new
+  checks as mandatory conditions during execution.
+- Reuse successful validation evidence while its inputs remain unchanged.
+  Rerun affected checks after changes; do not repeat entire stages solely to
+  produce another record or because a non-blocking diagnostic failed.
 - Scope blockers to the operation that requires the missing input. Complete
   Stages 1–2 locally without remote SSH, production Vault values, or an
   acceptance session. Controller/SSH/Vault inputs gate Stage 3; session and
@@ -70,7 +78,7 @@ scope, rationale, target state, and acceptance criteria.
   at the stage that needs them.
 - Local tooling is already installed and verified: Ansible Core 2.21.3 in
   `/home/eric/Workspace/ansible-dnd/.venv`. Use its `bin/ansible`,
-  `bin/ansible-playbook`, `bin/ansible-galaxy`, and `bin/ansible-doc`, or prepend
+  `bin/ansible-playbook` and `bin/ansible-galaxy`, or prepend
   that `bin` directory to `PATH`. No activation is required for absolute paths.
 
 ## Repository Scope
@@ -134,6 +142,8 @@ Workspace: `Close storage review and begin host deployment`.
 
 ## Stage 2: Prepare the Consumer Playbook and Inventory
 
+Completion: complete (consumer `12b2462`)
+
 ### Objective and Owning Repository
 
 Make `rakestraw-ansible` a complete consumer of the reviewed suite snapshot.
@@ -184,8 +194,8 @@ dependency paths, install from public sources with
 `ansible-galaxy install -r requirements.yml`. Configure role and collection
 destinations through Ansible configuration/environment; avoid a role-only
 custom path that would skip the collection section of the mixed manifest.
-Confirm resolution with `ansible-doc -t role rakestraw.dnd.pipeline` and the
-five `rakestraw.<app>` role names.
+Successful installation and playbook syntax checking are the dependency
+validation boundary. `ansible-doc` renders documentation and is not required.
 
 For local checks, use the workspace executables and the checked-out inventory.
 Configure isolated role and collection paths explicitly. From the consumer
@@ -238,8 +248,10 @@ checkout. Acceptance-session selection is not a prerequisite for this stage.
 ### Required Changes and Validation
 
 Before installation, confirm the operational controller's Ansible version and
-effective inventory, role, and collection paths. Confirm Ubuntu 26.04 and the
-existing `eric` account's required sudo access through read-only target checks.
+effective inventory, role, and collection paths. The target must support the
+roles' Ubuntu 26.04 contract and required sudo operations; ordinary connection,
+fact gathering, role platform guards, and privileged tasks establish these
+conditions. Separate preflight probes are optional troubleshooting, not gates.
 Have the operator create `inventory/host_vars/pipeline-dnd/vault.yml` encrypted
 in full, defining the four roadmap credential variables. Commit ciphertext
 with intent `Add encrypted D&D host credentials` after checking the diff
@@ -262,8 +274,9 @@ encrypted inventory and recorded Vault options before convergence.
    Immediately repeat the identical command after success. Require
    `changed=0`, `failed=0`, and no unreachable hosts on the repeat.
 3. On the target, execute
-   `sudo -u narratio /usr/local/bin/narratio config validate`, then validate
-   with `--profile testing`. The managed default campaign should make an
+   `sudo -u narratio /usr/local/bin/narratio config validate`.
+   Testing-overlay validation is optional; it has already passed suite review
+   and is not changed by this deployment. The managed default campaign should make an
    explicit campaign selector unnecessary.
 4. Start a fresh login as `eric` and execute the same default native validation
    without switching user, demonstrating usable supplementary group access.
@@ -304,7 +317,8 @@ Do not erase existing state to create a fixture.
 
 ### Required Changes and Validation
 
-1. As `eric` in a fresh authorized login, run:
+1. Under either supported runtime identity (`narratio` or `eric` with effective
+   runtime-group membership), run:
 
    ```text
    narratio session validate SESSION_ID --campaign CAMPAIGN --session SESSION_FILE
@@ -312,7 +326,9 @@ Do not erase existing state to create a fixture.
    narratio session artifacts SESSION_ID --remote --campaign CAMPAIGN --session SESSION_FILE
    ```
 
-   Substitute the operator-recorded values and use the production profile.
+   Substitute the operator-recorded values. Production is the default; an
+   operator-selected testing profile is also valid if the exercise covers the
+   agreed processing and publication path. Record the selected profile.
    The session document remains operational input; no session-management task
    belongs in the playbook. Observe transcription, processing, and successful
    publication. Do not force reprocessing or reduce the selected artifact set
@@ -349,8 +365,9 @@ this stage.
 
 ### Preconditions
 
-Stages 1–4 completed with committed changes and actual deployment/session
-evidence. A blocked live exercise does not satisfy this stage.
+Record progress at any stopping point, including a live-operation blocker.
+Full implementation handoff requires Stages 1–4 and actual deployment/session
+evidence; a partial handoff must explicitly identify uncompleted stages.
 
 ### Required Changes and Validation
 
@@ -390,20 +407,24 @@ independent review.
   merge commits are `cf3de016ee09edf91afc3bc1addfd926d4a172ad`,
   `77f67adbc0f700e88bc15554e02052eaa22f1033`, and
   `46913446765e86ecfb29ebad9955d579ef6a4c7e`.
-- Stage 2 local consumer preparation is next. The rejected target SSH identity,
+- Stage 2 local consumer preparation is complete. The rejected target SSH identity,
   operational controller details, and Vault workflow/values remain Stage 3
   prerequisites. The acceptance session/audio selection remains a Stage 4
   prerequisite. No live deployment has begun.
-- Stage 2 consumer changes are prepared but not committed because required
-  validation exposed a compatibility conflict in the reviewed dependency pins.
-  Installation from the mixed public manifest succeeded, the playbook selected
-  only `pipeline-dnd`, and syntax checking passed. With the required Ansible
-  Core 2.21.3 toolchain, `ansible-doc -t role` resolves the pipeline, Seriatim,
-  and Audita roles, but rejects the pinned `v0.1.0` Notarius, Scriptorium, and
-  Narratio argument specifications because public options lack required
-  `description` fields. The plan keeps those repositories read-only and
-  requires reporting demonstrated pin conflicts rather than changing them, so
-  Stage 2 and all dependent work are blocked pending an approved resolution.
+- Stage 2 consumer changes are committed in `12b2462`. Installation from the
+  public manifest, host selection, and syntax checks passed. The former
+  `ansible-doc` gate was unnecessary and has been removed: missing argument
+  descriptions prevent documentation rendering, not the demonstrated role
+  loading. The prepared consumer diff was reviewed and whitespace checks passed
+  before committing. Resume at Stage 3 when its operational inputs are
+  available. No dependency pin change is needed.
+
+## Non-blocking Follow-up
+
+The pinned Notarius, Scriptorium, and Narratio `v0.1.0` roles lack option
+descriptions required by `ansible-doc` documentation rendering. Consider adding
+descriptions in a separate role documentation change and normal later release.
+This is not a Feature 0016 acceptance criterion or a reason to change its pins.
 
 ## Open Questions