Separate local preparation from deployment prerequisites

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: ready
 
 ## Summary
 
@@ -193,8 +193,11 @@ immediate identical Ansible run reports no changes.
 
 ## Operational Prerequisites
 
-Before implementation, establish the concrete deployment context and record
-the non-secret choices in the implementation plan or deployment runbook:
+Local repository preparation and syntax/dependency checks can proceed with the
+workspace's existing Ansible virtual environment. Before live deployment,
+establish the controller, target access, and Vault details below. Select the
+session/audio before the end-to-end exercise, not before local implementation.
+Record non-secret choices in the implementation plan or deployment runbook:
 
 - Identify the operational Ansible controller and its deployment checkout.
   The repository configuration currently selects `/etc/ansible/inventory`,

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # Implementation Plan 0016: Deploy the D&D Pipeline to `pipeline-dnd`
 
-Status: blocked
+Status: ready
 
 Target executor: GPT-5.6-Terra
 
@@ -31,6 +31,17 @@ 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.
+- 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
+  audio selection gate Stage 4. Continue independent authorized preparation.
+- A missing executable on `PATH` is not proof that tooling is uninstalled.
+  Check the workspace `.venv/bin` and repository test drivers before reporting
+  a missing dependency. Use the verified executable path in diagnostics.
+- An Ansible controller is the environment running Ansible; it requires no
+  controller daemon or `/etc/ansible` directory. Use explicit configuration,
+  inventory, role, and collection paths for local checks. Do not recreate the
+  operational controller layout or install system-wide tooling for that purpose.
 - Retain the historical playbook and proof-of-concept role. Role, collection,
   application, and asset repositories remain read-only during this feature.
 - Deployment and paid provider execution occur only during the approved sprint
@@ -54,9 +65,13 @@ scope, rationale, target state, and acceptance criteria.
   and S3 variables to migrate.
 - The selected collection still declares version `0.1.0`. An installed
   release with that number is not sufficient evidence of the selected content.
-- Approve and commit the planning documents before execution. Resolve the
-  operational inputs under Open Questions before the sprint, as required by
-  the roadmap; do not invent controller topology, credentials, or session data.
+- This plan is approved, with this revision permitting local preparation before
+  operational inputs are resolved. Do not invent those inputs; resolve them
+  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
+  that `bin` directory to `PATH`. No activation is required for absolute paths.
 
 ## Repository Scope
 
@@ -65,11 +80,11 @@ scope, rationale, target state, and acceptance criteria.
 - Workspace: feature status, implementation progress, and review handoff.
 - Other repositories: read-only compatibility and application references.
 
-## Stage 1: Establish the Operational Context
+## Stage 1: Establish Local Preparation and Record Deployment Inputs
 
 ### Objective and Owning Repository
 
-Record deployment prerequisites in `rakestraw-ansible` and close the reviewed
+Record known and pending deployment inputs in `rakestraw-ansible` and close the reviewed
 Feature 0015 in the workspace.
 
 ### Required Policy Review
@@ -80,23 +95,24 @@ roadmap, and `rakestraw-ansible/README.md` before this stage.
 
 ### Preconditions
 
-The plan is approved, repositories have been checked, and the operator has
-supplied the missing operational inputs below.
+The plan is approved and repositories have been checked. Local tooling is
+available; no remote access or credential/session input is required.
 
 ### Required Changes
 
 1. Create `rakestraw-ansible/docs/pipeline-dnd.md` and link it from README.
-   Record the actual controller, checkout, effective Ansible configuration,
-   inventory, role/collection paths, Vault selection method, and acceptance
-   campaign/session/audio location. Record only non-secret information.
-2. Confirm controller Ansible Core is at least 2.18 and the public suite
+   Record the local validation setup and known operational details. List the
+   operational controller/checkout, effective paths, Vault selection, and
+   acceptance session as pending where unknown, with their consuming stage.
+   Do not fabricate completed checks or turn missing values into blockers here.
+2. Confirm local Ansible Core is at least 2.18 and the public suite
    repositories and Galaxy are reachable. Inspect effective configuration
    without dumping decrypted host variables. Existing repository defaults are
    `/etc/ansible/inventory`, `/etc/ansible/roles`, and `/etc/ansible/collections`;
-   establish how the operational checkout supplies those paths.
-3. Use ordinary read-only host checks to confirm Ubuntu 26.04 and the existing
-   `eric` account's SSH and required sudo access. Record the outcome. Report
-   discrepancies before deployment rather than changing platform/account policy.
+   document these as operational defaults, not required local directories.
+3. Record the reported target SSH rejection as a Stage 3 prerequisite. Defer
+   target Ubuntu and sudo checks until authorized access is available. Repeated
+   attempts with the same rejected identity do not advance local preparation.
 4. Mark Feature 0015 `done` in its roadmap and workspace status, citing its
    reviewed commits and the successful independent standalone/collection
    integration runs. Leave historical remediation records unchanged. Mark
@@ -104,7 +120,8 @@ supplied the missing operational inputs below.
 
 ### Validation and Completion Criteria
 
-Operational inputs are concrete and target platform/access checks pass.
+Local tooling works and the runbook distinguishes known facts from pending
+operational inputs, assigning each to Stage 3 or Stage 4.
 Run `git diff --check` in both changed repositories. No deployment or provider
 request is necessary for this stage.
 
@@ -128,8 +145,7 @@ Stage 1 runbook before this stage.
 
 ### Preconditions
 
-Stage 1 is complete. The operator can populate and unlock the encrypted host
-file using the recorded Vault mechanism.
+Stage 1 is complete. Production credentials and remote access are not required.
 
 ### Required Changes
 
@@ -143,9 +159,10 @@ file using the recorded Vault mechanism.
    `dnd_pipeline_secrets` mappings. Remove obsolete `narratio_s3_*` and
    `narratio_default_campaign_id` settings. Preserve unrelated intervening edits
    and the separate connection file. Do not copy suite defaults into inventory.
-3. Have the operator create `inventory/host_vars/pipeline-dnd/vault.yml`, fully
-   Ansible Vault-encrypted, defining the four exact `vault_dnd_*` names from
-   the roadmap. Commit ciphertext only.
+3. Document `inventory/host_vars/pipeline-dnd/vault.yml` and its four required
+   `vault_dnd_*` names. Keep the inventory references unresolved until the
+   operator provisions that encrypted file in Stage 3. Do not create an empty
+   Vault file or substitute credentials to make local checks appear complete.
 4. Pin the existing `rakestraw.dnd` Git entry in root `requirements.yml` to
    `46913446765e86ecfb29ebad9955d579ef6a4c7e` with its existing public URL.
 5. Copy the five `roles` entries from that collection's compatibility manifest,
@@ -168,20 +185,29 @@ 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.
 
-From the consumer checkout, using the established Vault options, run:
+For local checks, use the workspace executables and the checked-out inventory.
+Configure isolated role and collection paths explicitly. From the consumer
+checkout, run:
 
 ```text
 ansible-playbook -i inventory playbooks/pipeline/dnd.yml --limit pipeline-dnd --list-hosts
 ansible-playbook -i inventory playbooks/pipeline/dnd.yml --limit pipeline-dnd --syntax-check
 ```
 
-Use the concrete inventory path from Stage 1 if different. Do not impose
+Host listing and syntax checking do not deploy or establish that credentials
+resolve. Run them without evaluating or printing secret values; do not supply
+fake Vault variables. If an existing unrelated encrypted inventory file needs
+an unavailable password, preserve it and use a disposable local inventory with
+only the target alias and its non-secret host variables for syntax checking.
+Report that narrower scope explicitly; full encrypted-inventory validation
+belongs to Stage 3. Do not change operational inventory to bypass encryption.
+Do not impose
 whole-repository lint changes on the established minimal-playbook style.
 
 ### Completion Criteria
 
 Only the intended host is selected. Public dependencies resolve without local
-sibling checkouts, syntax checking succeeds with encrypted inventory, and the
+sibling checkouts, local syntax checking succeeds within its recorded scope, and the
 diff contains no plaintext secrets.
 
 ### Commit
@@ -202,12 +228,22 @@ roadmap, and `rakestraw-ansible/docs/pipeline-dnd.md` before this stage.
 
 ### Preconditions
 
-Stage 2 passed. The operational checkout contains its committed changes and
-Vault is usable. Deliver changes through the established checkout workflow;
-do not overwrite a dirty operational checkout.
+Stage 2 passed. The operational controller/checkout and delivery workflow are
+identified, and target SSH access and the Vault mechanism are available.
+Deliver committed changes through that workflow without overwriting a dirty
+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.
+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
+exposes no plaintext. Rerun host listing and syntax validation with the real
+encrypted inventory and recorded Vault options before convergence.
+
 1. Install root requirements at the confirmed controller paths. Explicitly
    refresh only the D&D collection from its selected commit, even when `0.1.0`
    is already installed:
@@ -341,19 +377,20 @@ independent review.
 
 ## Progress Notes
 
-Execution began on 2026-09-21 but Stage 1 is blocked before any consumer or
-deployment change. The available `devbench-02.lxd` checkout is not the
-operational controller: Ansible is not installed and `/etc/ansible` does not
-exist. The public Gitea sources and Ansible Galaxy are reachable, but no
-operational controller hostname or checkout workflow has been supplied. Direct
-SSH to `pipeline-dnd.rakestrawhome.com` reaches the host but the available
-identity is rejected, so the Ubuntu release, `eric` access, and sudo access
-cannot be confirmed. The Vault selection mechanism and operator-populated
-credentials are unavailable, and no acceptance campaign/session/audio input
-has been selected. No stage is complete and no dependent work has begun.
+The initial attempt stopped before consumer changes. Its report that Ansible
+was not installed was incorrect: workspace `.venv/bin/ansible` and
+`.venv/bin/ansible-playbook` were verified as Core 2.21.3 on `devbench-02`.
+Stages 1–2 may now proceed locally. Public Gitea and Galaxy were reported
+reachable. The reported rejected target SSH identity, missing operational
+controller details, and unavailable Vault workflow/values remain Stage 3
+prerequisites. The unselected acceptance session/audio remains a Stage 4
+prerequisite. No stage or live deployment is complete.
 
 ## Open Questions
 
+Questions 1–2 gate Stage 3 only. Question 3 gates Stage 4 only. None prevents
+local preparation in Stages 1–2.
+
 1. Which controller/checkout executes deployment and how do committed changes
    reach it? Recommended: use the existing operational controller and its
    established `/etc/ansible/` layout, keeping one operational inventory.

docs/status.md

@@ -4,11 +4,10 @@ Last updated: 2026-09-21
 
 Current milestone: Operational D&D pipeline deployment
 
-Current focus: Feature 0016 is blocked before its first stage by missing access
-to the operational controller and target, the Vault workflow and credentials,
-and an operator-selected acceptance session. Feature 0015 passed independent
-review without findings; administrative closeout remains part of the blocked
-sprint.
+Current focus: Resume Feature 0016 local preparation using the installed
+workspace Ansible tools. Controller/SSH/Vault inputs gate live deployment;
+session selection gates the end-to-end exercise. Feature 0015 passed independent
+review without findings; administrative closeout remains part of Stage 1.
 
 | ID | Deliverable | Owner | State | Evidence or next step |
 | --- | --- | --- | --- | --- |
@@ -36,7 +35,7 @@ sprint.
 | F0013 | Publish the first coordinated suite release | all Ansible repositories and workspace | done | Public [`rakestraw.dnd` 0.1.0 release](https://gitea.maximumdirect.net/eric/ansible-collection-dnd/releases/tag/v0.1.0); documentation remediation completed in pipeline `78afffe` and collection `5e695f3` |
 | F0014 | Enroll existing pipeline operators | ansible-role-dnd-pipeline, ansible-collection-dnd, and workspace | done | Pipeline `c13f726` and collection import `c0b0ebd` passed their complete integration suites and independent review with no remediation findings |
 | F0015 | Enable D&D S3 storage and publishing | ansible-role-dnd-pipeline, ansible-collection-dnd, and workspace | in_progress | Pipeline `51566afcf69083cdbb5b5718f2544c86b079001c`, collection fixture `cf3de016ee09edf91afc3bc1addfd926d4a172ad`, collection squash `77f67adbc0f700e88bc15554e02052eaa22f1033`, and collection merge `46913446765e86ecfb29ebad9955d579ef6a4c7e` passed the complete repository suites; independent review is next |
-| F0016 | Deploy the D&D pipeline to `pipeline-dnd` | rakestraw-ansible and workspace | blocked | Stage 1 cannot proceed from `devbench-02`: the operational controller/checkout and target SSH access are unavailable, as are the Vault workflow/credentials and selected acceptance session; see the [implementation plan](roadmap/implementation.md) |
+| F0016 | Deploy the D&D pipeline to `pipeline-dnd` | rakestraw-ansible and workspace | ready | Revised [implementation plan](roadmap/implementation.md) permits local Stages 1–2 with `.venv` tooling; operational inputs gate Stages 3–4 only |
 | A0001 | Audit completed standalone-role test suites | workspace and standalone roles | done | Findings recorded in `docs/roadmap/test-suite-audit-findings.md` |
 | R0001 | Simplify completed standalone-role test suites | workspace and standalone roles | done | Role commits `e08c63c`, `d2d0b9d`, and `cfecf37` passed implementation and independent review |