23 KiB
Implementation Plan 0012: Assemble the D&D Collection
Status: proposed
Target executor: GPT-5.6-Terra
Feature roadmap:
docs/roadmap/features/0012-collection-assembly.md
Active plan location: docs/roadmap/implementation.md
Objective
Build the initial rakestraw.dnd collection around the independently
maintained pipeline role. The completed source repository must build and
install as collection version 0.1.0, expose the imported role as
rakestraw.dnd.pipeline, bootstrap the exact reviewed standalone role and
collection dependencies, and prove the packaged boundary through one focused
isolated integration path. The feature roadmap remains authoritative for
scope, rationale, target state, and acceptance criteria.
Execution Rules
- Execute stages in numeric order.
- Number stages with consecutive integers beginning with
Stage 1. Do not use zero-based, decimal, nested, or nonsequential stage identifiers. - Before each stage, confirm its preconditions and the working-tree state of its owning repository.
- Before each stage, read every document listed in that stage's Required Policy Review. Do not rely on policy recalled from an earlier stage.
- Preserve unrelated and pre-existing changes.
- Do not make unresolved product or architecture decisions during execution; stop and report the decision required.
- Start from the feature roadmap's simplest viable implementation. Use native Galaxy metadata, dependency manifests, collection layout, and Git subtree behavior rather than adding wrappers, generators, synchronization scripts, or private state.
- Do not alter pipeline behavior in the standalone repository or beneath the
imported
roles/pipelineprefix. Any discovered behavioral defect belongs in the standalone pipeline repository and requires a separately reviewed change before a new subtree import. - Do not add integrity, drift, release, publishing, signing, rollback, or offline-installation guarantees beyond the feature roadmap.
- Keep collection tests focused on the packaging boundary. Do not copy the standalone pipeline role's full integration matrix.
- Run every stage's validation before committing it. Stage 3 is the sole
mechanical exception:
git subtree addnecessarily creates its provenance commit as part of the import, so run its validation immediately afterward and do not proceed if it fails. - Commit each completed stage when it leaves the repository in a valid state, using the commit intent specified by that stage. Do not push any repository.
- Do not begin a dependent stage after an earlier stage fails validation.
Starting State and Preconditions
-
The workspace planning changes for Feature 0012, including this plan, have been reviewed and committed before execution begins.
-
ansible-workspace-dnd,ansible-role-dnd-pipeline, andansible-collection-dndbegin onmainwith clean working trees. -
The standalone pipeline role begins at
de1b191cd2b6895895d3915e7b453596994127cf. Stage 1 will create the new reviewed commit that Stage 3 imports. -
The collection begins at
976277b03374. It contains no role or Galaxy metadata yet; Feature 0012 planning files belong to the independent parent workspace repository. -
The pipeline dependency manifests select these exact application-role commits, which the collection bootstrap manifest must preserve:
rakestraw.seriatimate08c63c0b078658bdfa2d10a2e6e1e4f9372a075rakestraw.auditaat66ebea9a47ce82bfdbdc5e2855f3dfaaff8e2a16rakestraw.notariusat14a38e04e35ef524d6a97fa7fb5a04981a0a2161rakestraw.scriptoriumat8b4c86e48e7d8655e479b26dc510bf01683a0c8frakestraw.narratioat292d8669e7aad5cfe80b0c469d22b6177e8cf0f1
-
Collection dependencies remain
ansible.posix2.2.0 andcommunity.general13.3.0. -
The workspace
.venvprovides Ansible Core 2.21.3 and ansible-lint 26.8.0. Invoke them through.venv/binrather than assuming they are onPATH. -
Git includes the
git subtreecommand. -
The local Ubuntu 26.04 proxy host supports passwordless noninteractive
sudo, as required by the existing role integration suites. -
Network access is available for Galaxy dependencies and the pinned Git role sources. Local immutable
file://inputs fromassets/campaignsandassets/narratio-promptsremain available for integration testing.
Repository Scope
ansible-role-dnd-pipelinemay change only its README to document the two supported consumption forms. It remains authoritative for the role.ansible-collection-dndowns Galaxy and runtime metadata, the unified bootstrap manifest, collection documentation, build exclusions, the squashed pipeline-role subtree, and focused collection integration tests.ansible-workspace-dndmay change only planning and status documents during the final handoff stage.- The five standalone application roles, both asset repositories, all
application repositories, and
rakestraw-ansiblemay be inspected but must remain unchanged.
Stage 1: Document Standalone and Collection Consumption
Objective
Make the authoritative pipeline role's README accurately describe both its standalone role name and its collection FQCN before taking the collection snapshot.
Required Policy Review
Before beginning this stage, read:
AGENTS.mddocs/orientation.mddocs/conventions.mddocs/ansible.md
Preconditions
ansible-role-dnd-pipelineis clean atde1b191cd2b6895895d3915e7b453596994127cf.- Feature 0012 is committed and records the standalone repository as the authoritative role source.
Owning Repository
ansible-role-dnd-pipeline
Required Changes
- Revise
README.mdso it no longer describes collection exposure only as a future possibility. - Retain the existing standalone installation and
rakestraw.dnd_pipelineinvocation instructions. - Add a concise collection-use path that names
rakestraw.dnd.pipelineand directs collection consumers to the collection repository's unified bootstrap instructions. Do not duplicate the collection's complete build, dependency, or subtree maintenance documentation here. - Explain that this repository remains authoritative and the collection carries a reviewed snapshot. Do not claim that a collection release has been published or tagged.
- Make no changes to defaults, tasks, templates, metadata, dependency pins, tests, or role behavior.
Validation
Run from ansible-role-dnd-pipeline:
git diff --check
git diff -- README.md
git status --short
Expected result: the diff is limited to accurate README wording, contains no whitespace errors, preserves the standalone instructions, and introduces no claim of an already published collection release.
Completion Criteria
- Both role names and their distinct consumption contexts are documented.
- No executable or dependency file changed.
- The repository is ready to supply the exact commit for the subtree import.
Commit
Commit intent: Document standalone and collection pipeline usage
Stage 2: Establish the Collection Foundation
Objective
Create the valid, buildable collection metadata, reproducible dependency bootstrap, build policy, and operator documentation that will own the imported role.
Required Policy Review
Before beginning this stage, read:
AGENTS.mddocs/orientation.mddocs/conventions.mddocs/ansible.md
Preconditions
- Stage 1 is committed and its full pipeline-role commit hash is recorded.
ansible-collection-dndis clean at its currentmainHEAD.- The exact application-role and collection dependency pins still match the values in Starting State and Preconditions. Stop if a pin has changed.
Owning Repository
ansible-collection-dnd
Required Changes
-
Add
galaxy.ymlwith:- namespace
rakestraw, namednd, and development version0.1.0; README.md, Eric Rakestraw as author,license: [CC0-1.0], a concise D&D pipeline description, the tagsdnd,pipeline,transcript, andprocessing, repository URLhttps://gitea.maximumdirect.net/eric/ansible-collection-dnd.git, and issue URLhttps://gitea.maximumdirect.net/eric/ansible-collection-dnd/issues;- exact collection dependencies
ansible.posix: 2.2.0andcommunity.general: 13.3.0; and build_ignoreentries for the collection'stests, root.gitignore, and the imported role's.gitignore,ansible.cfg,collections,requirements.yml, andtestspaths.
- namespace
-
Add
meta/runtime.ymlwith only the native runtime requirementrequires_ansible: ">=2.18.0"and the normal YAML document marker. -
Add one root
requirements.ymlusing Ansible's unifiedroles:andcollections:format. Copy the five Git sources, canonical installed role names, and exact reviewed commit pins from the pipeline manifests. Include the same exact two collection versions declared ingalaxy.yml. -
Replace the placeholder README with concise documentation covering:
- purpose, Ubuntu 26.04 support, and the
rakestraw.dnd.pipelineFQCN; - the unified
ansible-galaxy install -r requirements.ymlbootstrap; - collection build and local artifact installation with
--no-depsafter bootstrap; - a minimal FQCN play example;
- the distinction between development commit pins and future released role tags; and
- exact
git subtree addandgit subtree pull --squashmaintenance examples usingroles/pipelineandhttps://gitea.maximumdirect.net/eric/ansible-role-dnd-pipeline.git.
- purpose, Ubuntu 26.04 support, and the
-
Make the subtree documentation explicit that role changes originate in
ansible-role-dnd-pipeline; collection maintainers import a reviewed commit and do not edit the snapshot directly. -
Extend
.gitignoreonly as needed to keep locally built*.tar.gzcollection artifacts untracked. The documented/tested workflow should still build into a temporary output directory. -
Do not create a wrapper role, placeholder role, sync script, lock file, generated manifest, release automation, or publication configuration.
Validation
Run from ansible-collection-dnd:
build_dir=$(mktemp -d)
trap 'rm -rf -- "$build_dir"' EXIT
../.venv/bin/ansible-galaxy collection build --output-path "$build_dir"
test -f "$build_dir/rakestraw-dnd-0.1.0.tar.gz"
git diff --check
git status --short
Expected result: Ansible recognizes and builds collection version 0.1.0
without metadata errors, the expected archive is created outside the
repository, and only the planned collection foundation files have changed.
The artifact does not yet need to contain the pipeline role.
Completion Criteria
- The collection has valid Galaxy and runtime metadata.
- The root requirements file exactly reproduces both existing dependency manifests in unified form.
- The README gives a complete source-consumer and maintainer workflow without claiming a published release.
- No role code exists in or has been copied into the collection yet.
Commit
Commit intent: Establish the D&D collection foundation
Stage 3: Import the Authoritative Pipeline Role
Objective
Create the self-contained roles/pipeline collection role through one
provenance-bearing squashed subtree import of the Stage 1 commit.
Required Policy Review
Before beginning this stage, read:
AGENTS.mddocs/orientation.mddocs/conventions.mddocs/ansible.md
Preconditions
- Stages 1 and 2 are committed and validated.
- Both
ansible-role-dnd-pipelineandansible-collection-dndare clean. roles/pipelinedoes not exist.- The exact Stage 1 pipeline commit is available from the sibling repository.
Owning Repository
ansible-collection-dnd
Required Changes
-
From the collection repository, capture and inspect the full Stage 1 pipeline HEAD, then import exactly that commit with:
pipeline_commit=$(git -C ../ansible-role-dnd-pipeline rev-parse HEAD) git subtree add --prefix=roles/pipeline ../ansible-role-dnd-pipeline "$pipeline_commit" --squash -
Retain the standard subtree-generated provenance commit and trailers. Do not replace the import with a manual copy, submodule, symbolic link, wrapper role, or custom synchronization record.
-
Do not edit, remove, or reformat any file beneath
roles/pipeline. Files excluded from the built artifact remain in source so the imported snapshot stays faithful to the authoritative repository. -
Do not change collection-owned metadata merely to hide an unexpected import result. Stop and report a mismatch between the roadmap, Stage 2 build policy, and the actual role source.
Validation
Run from ansible-collection-dnd immediately after the subtree command:
diff -ru --exclude=.git ../ansible-role-dnd-pipeline roles/pipeline
../.venv/bin/python -c 'import pathlib, yaml; root = yaml.safe_load(pathlib.Path("requirements.yml").read_text()); role = yaml.safe_load(pathlib.Path("roles/pipeline/requirements.yml").read_text()); collections = yaml.safe_load(pathlib.Path("roles/pipeline/collections/requirements.yml").read_text()); assert root["roles"] == role["roles"]; assert root["collections"] == collections["collections"]'
build_dir=$(mktemp -d)
trap 'rm -rf -- "$build_dir"' EXIT
../.venv/bin/ansible-galaxy collection build --output-path "$build_dir"
tar -tf "$build_dir/rakestraw-dnd-0.1.0.tar.gz" > "$build_dir/files.txt"
grep -Fx 'roles/pipeline/tasks/main.yml' "$build_dir/files.txt"
! grep -Eq '^roles/pipeline/(tests/|ansible.cfg$|collections/|requirements.yml$|\.gitignore$)' "$build_dir/files.txt"
git status --short
git log -2 --format=fuller
Expected result: source and imported role trees are byte-for-byte equivalent apart from Git metadata; both dependency sections match their authoritative pipeline manifests; the archive contains the pipeline task entry point but no imported development fixtures or nested manifests; and Git records the standard squashed subtree provenance. The collection working tree is clean because the subtree command created the import commit.
Completion Criteria
roles/pipelineis an exact snapshot of the Stage 1 pipeline commit.- The collection artifact is self-contained for the pipeline role.
- Build exclusions affect only the artifact and have not mutated the source snapshot.
- The dependency bootstrap remains consistent with the imported role.
Commit
Commit intent: retain the standard commit created by git subtree add; do not
create a second manual import commit.
Stage 4: Validate the Installed Collection Boundary
Objective
Add one lean integration path that proves the built artifact, unified dependency bootstrap, FQCN resolution, representative native configuration, and clean repeated convergence.
Required Policy Review
Before beginning this stage, read:
AGENTS.mddocs/orientation.mddocs/conventions.mddocs/ansible.mddocs/testing.md
Preconditions
- Stage 3 is committed and validated.
ansible-collection-dndis clean.- The workspace
.venv, passwordlesssudo, and both local asset repositories are available. - No developer-global Ansible installation may satisfy the test's role or collection dependencies.
Owning Repository
ansible-collection-dnd
Required Changes
-
Add
tests/inventoryfor local connection andtests/converge.ymlwhose only role invocation israkestraw.dnd.pipeline. -
Add an executable
tests/integrationshell driver consistent with the standalone role repositories. It must:- use
set -euo pipefail, locate the repository and workspace.venvwithout assuming the caller's working directory, and create one privatemktemp -droot with cleanup on exit; - set
ANSIBLE_ROLES_PATHandANSIBLE_COLLECTIONS_PATHexclusively to directories beneath that temporary root, without appending the workspace, sibling repositories, or user-global paths; - run the unified
ansible-galaxy install -r requirements.ymlwith those environment paths so both dependency sections are exercised; - build
rakestraw-dnd-0.1.0.tar.gzinto the temporary root and install that artifact into the isolated collection path with--no-depsbecause the unified bootstrap has already installed its exact dependencies; - confirm the archive includes the pipeline task entry point and excludes
the development-only subtree paths selected in
build_ignore; - run syntax checking and production-profile ansible-lint against
tests/converge.ymlonly after the isolated dependencies and artifact are installed; - derive immutable local asset revisions from
assets/campaignsandassets/narratio-prompts, pass theirfile://URLs and revisions through the pipeline's public variables, and use the same syntactically valid local WhisperX URL and distinctive synthetic credential values as the standalone suite; - apply the collection role without contacting WhisperX or any model provider;
- use the installed applications' native interfaces for one representative
assembled validation: Seriatim reports a version, Audita validates its
configuration, Notarius validates
dnd-session, Scriptorium resolves a deployed prompt or profile through its configured roots, and Narratio validates one deployed campaign; - immediately apply the identical play and variables a second time, capture
its play recap, and require
changed=0andfailed=0; and - remove only its temporary root during cleanup.
- use
-
Keep the test at this packaging boundary. Do not add alternate-version, mapping-composition, invalid-secret, human-operator, ACL, profile-matrix, or exhaustive artifact tests already owned by the standalone suite.
-
Do not assert current default values, task names or order, individual task results, module behavior, complete rendered files, or exact manifest contents. The small archive inclusion/exclusion check is permitted because packaged content is behavior owned specifically by this feature.
-
Do not place real credentials in the test, logs, inventory, or repository. Native configuration checks must remain offline.
Validation
Run from the workspace root:
bash -n ansible-collection-dnd/tests/integration
ansible-collection-dnd/tests/integration
ansible-role-dnd-pipeline/tests/integration
git -C ansible-collection-dnd diff --check
git -C ansible-role-dnd-pipeline status --short
Expected result: the collection driver builds and installs only the declared artifact and dependencies into isolated paths, resolves the FQCN, passes every native application check, and reports a clean immediate repeat. The existing standalone suite also passes, and the authoritative pipeline repository remains clean after testing.
Completion Criteria
- The source collection cannot accidentally satisfy its own FQCN or dependencies through workspace or user-global Ansible paths.
- One representative installed-artifact deployment and every selected native check pass without external service calls.
- The repeat application reports
changed=0andfailed=0. - The standalone pipeline integration suite remains green.
- The test suite contains no implementation snapshots or duplicated feature matrix.
Commit
Commit intent: Test the assembled D&D collection
Stage 5: Record the Implementation Handoff
Objective
Record the completed implementation stages and leave every changed repository clean for independent review without marking the feature complete.
Required Policy Review
Before beginning this stage, read:
AGENTS.mddocs/orientation.mddocs/conventions.mddocs/planning.md
Preconditions
- Stages 1 through 4 are committed and all validation has passed.
ansible-role-dnd-pipelineandansible-collection-dndare clean.- Full commit hashes for every implementation commit, including the subtree provenance commit, have been recorded.
Owning Repository
ansible-workspace-dnd
Required Changes
- Change Feature 0012's roadmap status from
readytoin_progress; do not mark itdonebefore independent review. - Update
docs/status.mdso M1-04 and F0012 remainin_progress, the current focus is independent implementation review, and the evidence names the resulting pipeline and collection commit hashes. - Replace this document's Progress Notes placeholder with one concise entry
per completed stage, including repository and commit hash. Record any
deviation from the plan; write
noneif there were no deviations. - Do not create or modify
docs/roadmap/remediation.md; independent review owns remediation findings.
Validation
Run from the workspace root:
git diff --check
./scripts/status
git status --short
git -C ansible-role-dnd-pipeline status --short
git -C ansible-collection-dnd status --short
Expected result: only the intended workspace progress documents are pending in
the parent repository; both implementation repositories are clean; status
points reviewers to concrete commits; and the feature remains in_progress.
Completion Criteria
- Every stage and deviation is recorded concisely.
- Workspace status requests independent review and does not claim completion.
- No remediation document was preemptively created.
- The workspace change is ready for its own commit.
Commit
Commit intent: Record the Feature 0012 implementation
Final Validation and Handoff
- Confirm the successful Stage 4 logs include collection build and isolated installation, FQCN syntax resolution, every selected native application check, and the clean repeat recap.
- Run
./scripts/statusand confirm the workspace,ansible-role-dnd-pipeline, andansible-collection-dndare clean after the Stage 5 commit. All repositories outside those three must remain unchanged. - Report the Stage 1 pipeline commit, the Stage 2 collection foundation commit, the Stage 3 subtree import commit, the Stage 4 collection test commit, and the Stage 5 workspace handoff commit.
- Summarize any deviations, unresolved findings, and deferred release work.
- Report any implementation complexity beyond native collection metadata, one unified requirements manifest, the standard subtree import, and the focused integration driver, together with the acceptance criterion that required it.
- Do not push commits and do not mark Feature 0012
done; implementation results require independent review first.
Progress Notes
- Stage 1 complete:
ansible-role-dnd-pipeline600eb21cd967831607c087f1773063636ff2c31bdocuments standalone and collection consumption without changing role behavior. - Stage 2 complete:
ansible-collection-dnd3f7f82e40f63ee19e883052822c34dc806d8d51festablishes buildable Galaxy metadata, unified pinned dependencies, build exclusions, and source-use and subtree-maintenance documentation. - Stage 3 complete:
ansible-collection-dndc84aa0db8feda65ac66af07bc53976a23a016486imports pipeline commit600eb21cd967831607c087f1773063636ff2c31bas an exact squashed subtree snapshot atroles/pipeline.