Remove unnecessary deployment gates and record preparation

docs/roadmap/features/0016-deploy-dnd-pipeline-to-pipeline-dnd.md

@@ -1,6 +1,6 @@
 # Feature 0016: Deploy the D&D Pipeline to `pipeline-dnd`
 
-Status: blocked
+Status: in_progress
 
 ## Summary
 
@@ -205,9 +205,9 @@ Record non-secret choices in the implementation plan or deployment runbook:
   paths so dependency installation and playbook execution use the same
   inventory and installed content. Distinguish those paths from this
   development workspace.
-- Confirm that `pipeline-dnd` runs the supported Ubuntu 26.04 environment and
-  that its existing `eric` account provides SSH access and the sudo access
-  required by the roles.
+- The target must satisfy the roles' Ubuntu 26.04 and access requirements.
+  Normal connection, role guards, and privileged tasks can establish these;
+  separate platform or sudo probes are not required acceptance tests.
 - Establish the controller's existing Vault password or identity mechanism
   and operator availability to populate the four credential values in the
   encrypted host file. Record how Vault is selected, never its password or
@@ -273,10 +273,11 @@ suite defaults.
   preserves `dilfs` as the default campaign through the existing standalone
   role variable, and inherits Feature 0015's storage and publishing defaults.
 - `dnd_pipeline_secrets` maps the required typed runtime keys to host Vault
-  variables, and the actual values exist only in a valid Ansible
-  Vault-encrypted file.
-- No plaintext credential value is present in any tracked revision, diff,
-  command example, validation output, or deployment documentation.
+  variables. Credential values in the consumer repository are Vault-encrypted;
+  runtime delivery uses the suite's existing restricted secrets files.
+- This feature introduces no plaintext credential values into commits, diffs,
+  command examples, validation output, or documentation. A repository-wide
+  historical secret audit is not an acceptance requirement.
 - Legacy Narratio storage values are either represented through the current
   pipeline interface or deliberately retired; no stale high-precedence host
   variable can override the selected suite configuration accidentally.
@@ -287,9 +288,9 @@ suite defaults.
 - The controller uses the selected collection commit even if collection
   version `0.1.0` was already installed. The documented inventory, role, and
   collection paths correspond to the operational controller.
-- On a controller bootstrapped from that manifest, `ansible-doc` resolves
-  `rakestraw.dnd.pipeline` and each role dependency, and the new playbook
-  passes syntax checking.
+- Public dependency installation succeeds, and the new playbook passes syntax
+  checking with the installed collection and roles. Documentation rendering
+  with `ansible-doc` is not required for deployment acceptance.
 - The initial limited playbook run against `pipeline-dnd` completes
   successfully using the encrypted inventory and ordinary sudo-capable remote
   account.
@@ -299,7 +300,9 @@ suite defaults.
   shared pipeline through runtime-group membership.
 - One operator-selected D&D session completes transcription, processing,
   storage, and publishing, and its expected published output is observable at
-  the configured destination.
+  the configured destination. Either supported runtime identity may execute
+  it. Production is the default profile; the operator may select the testing
+  profile while retaining the same processing and publication acceptance scope.
 - The operational documentation explains dependency installation, Vault use,
   deployment invocation, the login-session membership caveat, convergence
   verification, and representative pipeline invocation without disclosing