Plan D&D S3 storage and publishing

This commit is contained in:
2026-09-21 02:20:57 +00:00
parent ec69f5a03b
commit e262b61292
6 changed files with 1023 additions and 181 deletions

View File

@@ -1,26 +1,29 @@
# Implementation Plan 0014: Enroll Existing Pipeline Operators
# Implementation Plan 0015: Enable D&D S3 Storage and Publishing
Status: ready
Target executor: GPT-5.6-Terra
Feature roadmap:
`docs/roadmap/features/0014-existing-pipeline-operator-enrollment.md`
`docs/roadmap/features/0015-dnd-s3-storage-and-publishing.md`
Active plan location: `docs/roadmap/implementation.md`
## Objective
Add one empty-by-default pipeline interface that enrolls explicitly selected
existing human accounts in the suite's runtime group. Implement the behavior
with one account-existence lookup and one additive membership task, adapt the
existing operator integration scenario, and import the reviewed result into
the collection from public Gitea.
Configure the authoritative D&D pipeline role to use the selected Backblaze
S3-compatible archive, typed object-storage credential references, maximum S3
audio caching, immutable run publication, selected transcript and D&D artifact
outputs, and cleanup of successfully published workspace state. Validate the
configuration through Narratio's native interface, import the exact reviewed
pipeline commit into the collection from public Gitea, and leave the result
ready for the real-host deployment in Feature 0016.
The Feature 0014 roadmap remains authoritative for scope, rationale, target
state, and acceptance criteria. This plan does not authorize human-account
creation or removal, exact-list reconciliation, filesystem-policy changes, or
a new release.
The Feature 0015 roadmap remains authoritative for scope, rationale, target
state, and acceptance criteria. This plan does not authorize a second storage
implementation, real object-storage calls from repository tests, per-session
configuration management, stable publication of every Notarius extraction
lane, or changes to the generic Narratio role.
## Execution Rules
@@ -33,37 +36,49 @@ a new release.
worktree changes or branch divergence rather than overwriting them.
- Do not make unresolved product or architecture decisions during execution;
stop and report the decision required.
- Keep the production behavior to the roadmap's exact direct task flow: one
`ansible.builtin.getent` loop followed by one `ansible.builtin.user` loop.
- Do not add an assertion, registered fact, handler, command, shell operation,
explicit empty-list condition, membership comparison, post-change query,
sidecar state, or account abstraction.
- Trust `getent` to fail for a missing key and `user` to converge additive
membership. Do not reproduce either module's checks.
- Test the public behavior by adapting the existing temporary-operator
scenario. Do not add a missing-user test, inspect `/etc/passwd` or
`/etc/group`, assert task results, or duplicate the detailed test in the
collection.
- Run each stage's validation before committing it. Do not proceed after a
validation failure.
- Implement storage and publication entirely through the standalone Narratio
role's existing field-specific variables. Do not add a production task,
template, handler, fact, probe, command, wrapper, state file, or validation
layer to the pipeline role.
- Keep `dnd_pipeline_secrets` as the existing generic empty-by-default map.
Add no real, generated, placeholder, or fallback credential value to role
defaults, templates, documentation, tests, logs, or ordinary inventory.
- Keep the S3 access-key and secret-key reference variables nullable as a
pair. Do not add an Ansible assertion for pairing or secret presence;
Narratio owns native configuration validation and AWS provider selection.
- Do not configure `narratio_spool_delete_audio_after_publish` or
`narratio_notarius_chunk_cache`. Preserve the roadmap's single-owner
decisions for spool retention and Notarius cache policy.
- Treat accepted Notarius outputs and published outputs as separate
interfaces. Preserve `narratio.extraction.<output_key>` sources for future
analyze inputs without adding publication rules or new artifacts for them.
- Exercise explicitly supplied representative values in the detailed pipeline
integration scenario. Do not assert that those values are current defaults
or duplicate Narratio's own storage and publication test matrix.
- Do not make a real S3 request or paid model request during repository-local
validation.
- Run every stage's validation before completing the stage. Do not proceed
after a validation failure.
- Commit each completed stage with the stated plain-English intent. Push the
authoritative pipeline commit before importing it into the collection.
- Use only the public Gitea pipeline URL for the subtree update; do not import
- Use only the public Gitea pipeline URL for the subtree update. Do not import
from the local sibling repository.
## Starting State and Preconditions
- Features 0009, 0011, 0012, and 0013 are complete.
- This roadmap and implementation plan have been reviewed and committed in the
workspace repository before execution begins.
- The completed Feature 0013 closeout commits `eda361f` in the workspace and
`5e695f3` in the collection are pushed to their respective `origin/main`
branches before implementation begins. Preserve the Git-generated subtree
squash commit that accompanies `5e695f3`.
- `ansible-role-dnd-pipeline` starts clean on `main` at `78afffe`, equal to
`origin/main`.
- `ansible-collection-dnd` starts clean on `main` at `5e695f3`, equal to
`origin/main` after the prerequisite push.
- Features 0009, 0011, 0012, 0013, and 0014 are complete.
- The approved Feature 0015 roadmap and this implementation plan are committed
in the workspace repository before the sprint begins.
- `ansible-role-dnd-pipeline` starts clean on `main` at
`c13f726a0a846180a1aa95d110b8bbc801edaae5`, equal to `origin/main`.
- `ansible-collection-dnd` starts clean on `main` at
`c0b0ebd13e92199f3d94e138c6cc50d1ece5dadd`, equal to `origin/main`.
- `ansible-role-narratio` is clean at
`292d8669e7aad5cfe80b0c469d22b6177e8cf0f1`, equal to `origin/main`, and its
`v0.1.0` role release contains the Narratio v2.1.0 field-specific interface
required by this feature.
- The sibling Narratio application repository is clean at public release
`v2.1.0`. It is a read-only contract source during this sprint.
- The workspace `.venv` supplies the tested `ansible-playbook`,
`ansible-galaxy`, and `ansible-lint` commands used by the repository test
drivers.
@@ -71,27 +86,31 @@ a new release.
test-time sudo is available for the existing integration fixtures.
- Git credentials can push the pipeline and collection commits to their public
Gitea origins.
- No actual Backblaze or model-provider credential is required or available to
the implementation. Tests use conspicuously synthetic values only.
## Repository Scope
- `ansible-role-dnd-pipeline` owns the variable, argument specification,
account lookup, additive enrollment task, README, and detailed integration
behavior.
- `ansible-collection-dnd` receives the reviewed pipeline commit only through
its established squashed subtree and validates the assembled artifact.
- `ansible-workspace-dnd` records implementation progress and the review
handoff after the two implementation repositories are complete.
- All standalone application-role repositories, application source
repositories, asset repositories, and `rakestraw-ansible` are out of scope
and must remain unchanged.
- `ansible-role-dnd-pipeline` owns the suite defaults, argument specification,
Narratio dependency mappings, consumer documentation, and detailed
representative integration behavior.
- `ansible-collection-dnd` owns the artifact-level fixture update, faithful
squashed subtree import, assembled-artifact validation, and resulting public
collection snapshot.
- `ansible-workspace-dnd` records the implementation handoff after the two
implementation repositories are complete.
- `ansible-role-narratio`, all other standalone roles, application sources,
asset repositories, and `rakestraw-ansible` may be inspected but must remain
unchanged.
## Stage 1: Implement Existing-Operator Enrollment
## Stage 1: Implement D&D Storage and Publication Policy
### Objective
Give the standalone pipeline role its minimal public interface for enrolling
existing human accounts and prove the behavior through the existing operator
integration scenario.
Expose the approved suite-level S3 and publishing inputs through the
authoritative pipeline role, map them directly into Narratio, document the
operator contract, and prove representative composition without networked
storage access.
### Required Policy Review
@@ -103,17 +122,22 @@ Before beginning this stage, read:
- `docs/ansible.md`
- `docs/testing.md`
- `docs/planning.md`
- `docs/roadmap/features/0014-existing-pipeline-operator-enrollment.md`
- `docs/roadmap/features/0015-dnd-s3-storage-and-publishing.md`
- `ansible-role-dnd-pipeline/README.md`
- `../narratio/AGENTS.md`
- `../narratio/docs/development.md`
- `../narratio/docs/config.md`
- `../narratio/docs/operations.md`
### Preconditions
- The workspace planning commit is present.
- `ansible-role-dnd-pipeline` is clean at `78afffe` on `main`, is not behind
- The workspace planning commit containing this plan is present.
- `ansible-role-dnd-pipeline` is clean at the starting revision, is not behind
or diverged from `origin/main`, and contains no unrelated changes.
- Its Narratio dependency still creates the selected runtime group before the
pipeline role's ordinary tasks execute.
- The existing integration driver still contains the temporary operator and
representative group-access scenario described by the roadmap.
- The current `rakestraw.narratio` dependency mapping and existing integration
driver still match the structures reviewed while preparing this plan.
- Narratio v2.1.0 still accepts the roadmap-selected storage, publish, cleanup,
cache, and typed credential-reference fields.
### Owning Repository
@@ -121,38 +145,102 @@ Before beginning this stage, read:
### Required Changes
1. Add `dnd_pipeline_operator_users: []` beside the existing runtime identity
defaults in `defaults/main.yml`.
2. Add the matching `meta/argument_specs.yml` entry with `type: list`,
`elements: str`, and the same required/default-backed convention used by
the role's other public variables.
3. Add one unprivileged `ansible.builtin.getent` task near the beginning of
`tasks/main.yml`. Loop directly over `dnd_pipeline_operator_users`, use the
`passwd` database and each username as `key`, and rely on the module's
default missing-key failure. Do not register its result or add a separate
assertion.
4. Immediately follow it with one `become: true` `ansible.builtin.user` task
over the same list. Set `name` to the selected account,
`groups` to `dnd_pipeline_runtime_group`, `append: true`, and
`state: present`. Do not set or manage any other account property.
5. Revise the README variable reference and shared-execution section. Replace
the consumer-owned membership example and deferred wording with the new
interface, existing-account prerequisite, additive non-removal behavior,
authorization consequence, and new-login-session caveat.
6. Adapt `tests/integration` rather than adding another scenario. Create its
temporary operator before the initial role application without membership
in the runtime group, pass that username through
`dnd_pipeline_operator_users` for the baseline and repeated applications,
and retain the existing native configuration, secret-boundary, and shared
cache exercises under that identity. Reorder cleanup as necessary so any
final baseline convergence occurs while the selected fixture account still
exists, then remove the fixture account.
7. Retain the existing clean-repeat assertion. Do not add a negative
missing-user case or assertions about module internals, task traces, the
current default value, or raw account database entries.
8. Run the complete existing repository validation, commit the result, push
`main` to the public pipeline origin, and record the full pushed commit for
Stage 2.
1. Add the following exact suite defaults to `defaults/main.yml` near the
existing Narratio policy variables:
```yaml
dnd_pipeline_narratio_workspace_cleanup_after_publish: true
dnd_pipeline_narratio_storage_backend: s3
dnd_pipeline_narratio_storage_s3_bucket: rakestraw-assets
dnd_pipeline_narratio_storage_s3_root_prefix: dnd
dnd_pipeline_narratio_storage_s3_region: us-east-1
dnd_pipeline_narratio_storage_s3_endpoint: https://s3.us-east-005.backblazeb2.com
dnd_pipeline_narratio_storage_s3_force_path_style: true
dnd_pipeline_narratio_storage_s3_access_key_id: OBJECT_STORAGE_KEY_ID
dnd_pipeline_narratio_storage_s3_secret_access_key: OBJECT_STORAGE_KEY
dnd_pipeline_narratio_cache_s3_audio: true
dnd_pipeline_narratio_publish_enabled: true
dnd_pipeline_narratio_publish_upload_run: true
dnd_pipeline_narratio_publish_outputs:
- source: narratio.transcript.final
required: true
- source: narratio.transcript.final_trimmed
required: true
- source: narratio.transcript.final_markdown
required: true
- source: narratio.transcript.final_trimmed_markdown
required: true
- source: narratio.artifact.session_recap
required: true
- source: narratio.artifact.hostile_rumors
required: true
- source: narratio.artifact.deranged_rumors
required: false
```
Keep every `dest` omitted. Narratio derives transcript destinations from
built-in sources and artifact destinations from the already managed
artifact output paths.
2. Add matching public entries to `meta/argument_specs.yml`. Use `type: bool`
for the cleanup, path-style, cache, enabled, and upload settings; `type: str`
for the backend and S3 string fields; and `type: list` for the complete
publish output list. The S3 child fields, including both credential
references, must be non-required so callers may set every S3 child to
`null` when deliberately selecting the local backend or set the credential
pair to `null` when selecting the AWS SDK provider chain. The remaining
concrete suite-policy fields follow the role's existing required/defaulted
argument-spec convention.
3. In the `rakestraw.narratio` dependency entry in `meta/main.yml`, map every
new suite variable directly to its same-purpose standalone variable:
`narratio_workspace_cleanup_after_publish`, the eight
`narratio_storage_*` fields, `narratio_cache_s3_audio`,
`narratio_publish_enabled`, `narratio_publish_upload_run`, and
`narratio_publish_outputs`.
4. Do not map `narratio_spool_delete_audio_after_publish`. Do not map
`narratio_notarius_chunk_cache`. Do not add a new import, fragment,
template, task, handler, assertion, or configuration-validation command.
5. Revise the README's variable reference and processing-policy sections to
document the selected S3 destination, paired nullable credential
references, complete-list publish semantics, native destination derivation,
maximum S3 audio caching, successful-publication workspace cleanup, and
deliberate omission of spool deletion.
6. Extend the README's managed-credential example to show
`OBJECT_STORAGE_KEY_ID` and `OBJECT_STORAGE_KEY` mapped from encrypted
inventory beside the existing Audita and OpenRouter entries. Explain that
values remain outside ordinary configuration and that setting both S3
credential references to `null` selects Narratio's ambient AWS SDK provider
chain.
7. Replace the README's statement that storage and publishing are deferred
with concise operator-facing descriptions and public upstream links for S3
session audio, publish, restore, publication locks, status, and cleanup.
Explain that accepted Notarius lanes remain
`narratio.extraction.<output_key>` analyze inputs independently of whether
they have stable publish rules.
8. Adapt the existing `tests/integration` baseline rather than adding a new
scenario. Add two synthetic object-storage values to
`dnd_pipeline_secrets`; explicitly unset `OBJECT_STORAGE_KEY_ID` and
`OBJECT_STORAGE_KEY` alongside the existing provider variables when
invoking Ansible; and explicitly pass representative non-default S3,
cleanup, cache, and publish values through the new public variables.
9. Use representative values that exercise the interface without freezing the
defaults: for example an `.invalid` HTTPS endpoint and fixture bucket,
prefix, and region; intentional `false` values for cleanup, path style, and
S3 audio caching; the two configured credential reference names; enabled
run publication; and a short complete publish list containing one built-in
transcript source and `narratio.artifact.session_recap` with omitted
destinations.
10. Extend the existing secret-safe effective-configuration inspection only
enough to demonstrate the explicitly supplied representative storage
fields, typed credential names, falsey cache/cleanup choices, enabled
publication, and Narratio-derived destinations. Continue to use
`narratio config validate` as the native validity boundary. Do not inspect
role task results, call S3, or reproduce Narratio's validation rules.
11. Extend the current non-disclosure check to cover both synthetic
object-storage values. Preserve the complete existing integration matrix,
cleanup behavior, and immediate clean-repeat assertions.
12. Run the complete repository validation. Commit the valid result with the
stated plain-English message, push `main` to public Gitea, and record the
full pushed commit hash for Stage 3.
### Validation
@@ -162,34 +250,36 @@ Run from the workspace root:
(cd ansible-role-dnd-pipeline && tests/integration && git diff --check)
```
Expected result: syntax and production-profile lint pass; the temporary
existing account is enrolled through the public role variable and completes
the existing representative operator-access scenario; native application
checks pass; the immediate identical role application reports `changed=0`
and `failed=0`; and no credential value appears in test output.
Expected result: syntax checking and production-profile lint pass; all five
applications remain valid; the explicitly supplied S3 and publish values
resolve through Narratio's native configuration interface; only reference
names appear in effective output; no synthetic credential value appears in
captured output; no external S3 or model request occurs; and the immediate
identical repeat reports `changed=0` and `failed=0`.
### Completion Criteria
- The public interface, argument specification, two direct tasks, and README
implement exactly the roadmap contract.
- The existing operator scenario uses the role interface rather than fixture
group enrollment.
- Defaults, argument specifications, dependency mappings, and documentation
implement exactly the Feature 0015 contract.
- No production task, template, fragment, validation command, or second secret
path was added.
- The representative integration scenario exercises public inputs rather than
snapshotting defaults and retains the existing clean-repeat boundary.
- The full standalone integration suite and `git diff --check` pass.
- The role repository is clean after a plain-English commit.
- The pipeline repository is clean after the plain-English commit.
- The exact commit is present on public `origin/main` and its full hash is
available for the collection import.
### Commit
Commit intent: `Add optional pipeline operator enrollment`
Commit intent: `Enable D&D storage and publishing`
## Stage 2: Import the Reviewed Pipeline Change
## Stage 2: Prepare the Collection Credential Fixture
### Objective
Expose the reviewed operator interface through `rakestraw.dnd.pipeline` while
preserving the authoritative-standalone-repository and collection-artifact
boundaries.
Make the collection's artifact-level fixture compatible with the forthcoming
pipeline snapshot while its currently bundled role remains valid.
### Required Policy Review
@@ -201,17 +291,93 @@ Before beginning this stage, read:
- `docs/ansible.md`
- `docs/testing.md`
- `docs/planning.md`
- `docs/roadmap/features/0014-existing-pipeline-operator-enrollment.md`
- `docs/roadmap/features/0015-dnd-s3-storage-and-publishing.md`
- `ansible-collection-dnd/README.md`
### Preconditions
- Stage 1 is complete and its exact commit is publicly reachable from
`https://gitea.maximumdirect.net/eric/ansible-role-dnd-pipeline.git`.
- `ansible-collection-dnd` is clean at `5e695f3` on `main`, is not behind or
- Stage 1 is complete, validated, committed, and pushed.
- `ansible-collection-dnd` is clean at the starting revision, is not behind or
diverged from `origin/main`, and contains no unrelated changes.
- The collection's current `roles/pipeline` subtree still corresponds to the
authoritative pipeline history through `78afffe`.
- Its top-level `tests/integration` fixture still supplies the two existing
synthetic provider credentials through `dnd_pipeline_secrets`.
### Owning Repository
`ansible-collection-dnd`
### Required Changes
1. Update only the collection-level `tests/integration` fixture outside
`roles/pipeline`. Add conspicuously synthetic values for
`OBJECT_STORAGE_KEY_ID` and `OBJECT_STORAGE_KEY` to its existing
`dnd_pipeline_secrets` input.
2. Explicitly unset those two environment variables beside the existing
Audita and OpenRouter variables when the fixture runs Ansible so ambient
controller state cannot replace the managed synthetic files.
3. Do not add storage assertions or duplicate the standalone pipeline's
detailed representative test. The collection fixture owns only enough
input to validate the assembled artifact after Stage 3.
4. Do not edit anything under `roles/pipeline`, alter dependency manifests,
or change collection release metadata.
5. Check the fixture's shell syntax and whitespace, then commit the compatible
preparation with the stated message. Do not push separately unless needed;
Stage 3 will push both collection commits after full artifact validation.
### Validation
Run from the workspace root:
```text
(cd ansible-collection-dnd && bash -n tests/integration && git diff --check)
```
Expected result: the collection integration driver remains valid shell; the
diff changes only its generic managed-secret input and environment scrub; and
no subtree, dependency, or release file changed. Full semantic validation
occurs once against the imported snapshot in Stage 3.
### Completion Criteria
- The artifact-level fixture provides all four synthetic operational
credential names without exposing real values.
- No detailed storage behavior was duplicated in the collection.
- Only the collection-owned fixture changed.
- Shell syntax and `git diff --check` pass.
- The collection repository is clean after the plain-English commit.
### Commit
Commit intent: `Prepare collection storage credentials`
## Stage 3: Import and Validate the Reviewed Pipeline Snapshot
### Objective
Expose the reviewed Feature 0015 behavior through `rakestraw.dnd.pipeline`
while preserving the public-remote subtree and collection-artifact boundaries.
### Required Policy Review
Before beginning this stage, read:
- `AGENTS.md`
- `docs/orientation.md`
- `docs/conventions.md`
- `docs/ansible.md`
- `docs/testing.md`
- `docs/planning.md`
- `docs/roadmap/features/0015-dnd-s3-storage-and-publishing.md`
- `ansible-collection-dnd/README.md`
### Preconditions
- Stage 1's exact pipeline commit is publicly reachable from
`https://gitea.maximumdirect.net/eric/ansible-role-dnd-pipeline.git`.
- Stage 2 is complete and committed in `ansible-collection-dnd`.
- The collection is clean at the Stage 2 commit and its bundled pipeline
subtree still corresponds to the authoritative pipeline history through
`c13f726a0a846180a1aa95d110b8bbc801edaae5`.
### Owning Repository
@@ -220,27 +386,28 @@ Before beginning this stage, read:
### Required Changes
1. Set a shell variable to the full pushed Stage 1 commit hash and run the
documented remote-only update from the collection repository:
documented remote-only subtree update from the collection repository:
```text
pipeline_revision=<FULL_PUSHED_STAGE_1_COMMIT>
git subtree pull --prefix=roles/pipeline \
https://gitea.maximumdirect.net/eric/ansible-role-dnd-pipeline.git \
"$pipeline_revision" --squash -m "Import pipeline operator enrollment"
"$pipeline_revision" --squash -m "Import D&D storage and publishing"
```
2. Do not edit role behavior directly beneath `roles/pipeline`. The subtree
import should carry the new default, argument specification, tasks, README,
and standalone tests faithfully.
3. Do not change `galaxy.yml`, dependency manifests, collection-level tests,
or release documentation. No dependency or published version changes in
this feature, and the detailed behavior remains covered by Stage 1.
4. Run the existing collection integration suite against the built and
installed artifact. Commit no additional files after the subtree command
unless validation exposes a genuine collection-boundary issue within this
feature's scope.
5. Push the resulting collection history to `origin/main` and record the
resulting merge commit and Git-generated squashed subtree commit.
2. Do not edit role behavior directly beneath `roles/pipeline`. The import
must faithfully carry the reviewed defaults, argument specification,
dependency mappings, README, and detailed integration fixture.
3. Do not modify `galaxy.yml`, `requirements.yml`, release documentation, or
the published `v0.1.0` artifacts. Feature 0015 changes no standalone role or
native collection dependency and publishes no release.
4. Run the complete collection integration suite against the built and
installed artifact. Do not add collection-level assertions for the detailed
S3 configuration; native validation and clean convergence remain the
collection boundary.
5. If validation succeeds, push the Stage 2 fixture commit, the subtree merge
commit, and its Git-generated squash commit to `origin/main`. Record the
resulting commit hashes for Stage 4.
### Validation
@@ -250,33 +417,34 @@ Run from the workspace root:
(cd ansible-collection-dnd && tests/integration && git diff --check)
```
Expected result: the collection builds; the archive contains the updated
pipeline role while retaining its development-file exclusions; isolated
dependency and artifact installation succeeds; the FQCN resolves; native
representative application checks pass; and the immediate repeat reports
`changed=0` and `failed=0`.
Expected result: the collection builds; its archive contains the updated
pipeline role while retaining development-file exclusions; isolated
dependency and artifact installation succeeds; the FQCN resolves; Narratio
loads its typed storage references from the synthetic credential files without
contacting S3; native representative application checks pass; and the
immediate repeat reports `changed=0` and `failed=0`.
### Completion Criteria
- Git history records a squashed subtree import from the exact public Stage 1
commit with the stated plain-English merge message.
- Git history records the exact public Stage 1 revision through the documented
squashed subtree workflow and stated merge message.
- No pipeline behavior was authored directly in the collection.
- The existing collection suite and `git diff --check` pass without an
unnecessary duplicate operator test.
- The collection is clean and its new history is present on `origin/main`.
- The complete collection suite and `git diff --check` pass.
- The collection repository is clean and its Stage 2 and Stage 3 history is
present on public `origin/main`.
### Commit
Commit intent: `Import pipeline operator enrollment`
Commit intent: `Import D&D storage and publishing`
The subtree command creates the stage's merge commit and its generated squash
The subtree command creates this stage's merge commit and its generated squash
commit; do not add an empty or redundant manual commit.
## Stage 3: Record the Implementation Handoff
## Stage 4: Record the Implementation Handoff
### Objective
Record the completed implementation evidence without marking Feature 0014
Record the completed implementation evidence without marking Feature 0015
done before independent review.
### Required Policy Review
@@ -287,14 +455,15 @@ Before beginning this stage, read:
- `docs/orientation.md`
- `docs/conventions.md`
- `docs/planning.md`
- `docs/roadmap/features/0014-existing-pipeline-operator-enrollment.md`
- `docs/roadmap/features/0015-dnd-s3-storage-and-publishing.md`
### Preconditions
- Stages 1 and 2 are complete, committed, pushed, and validated.
- Stages 1 through 3 are complete, committed, pushed where required, and
validated.
- Their full commit hashes and validation results are available.
- The workspace repository is clean apart from the expected progress-record
edits for this stage and is not behind or diverged from `origin/main`.
- The workspace repository is clean at the planning commit, is not behind or
diverged from `origin/main`, and contains no unrelated changes.
### Owning Repository
@@ -302,15 +471,17 @@ Before beginning this stage, read:
### Required Changes
1. Change Feature 0014's roadmap status and status-table state to
1. Change Feature 0015's roadmap status and status-table state to
`in_progress`, indicating implementation is complete but independent review
remains outstanding.
2. Update the workspace current focus and Feature 0014 evidence with the exact
pipeline and collection commit hashes and the validation completed.
3. Replace this plan's Progress Notes with a concise record of the three stage
2. Update the workspace current focus and Feature 0015 evidence with the exact
pipeline commit, collection fixture commit, collection subtree merge and
squash commits, and validation completed.
3. Replace this plan's Progress Notes with a concise record of the four stage
states and their commits. Do not copy command logs into the repository.
4. Do not mark the feature `done`, remove the active plan, or create
`docs/roadmap/remediation.md`; those are review and closeout decisions.
4. Do not mark the feature `done`, remove this active plan, change Feature
0016's state, or create `docs/roadmap/remediation.md`; those are later review
and closeout decisions.
5. Commit the workspace handoff record with the stated plain-English message.
### Validation
@@ -324,49 +495,39 @@ git diff --check
Expected result: every repository is clean; the pipeline and collection are
not ahead of or behind their origins; only the workspace handoff commit may be
ahead of `origin/main`; and the dashboard points to the exact implementation
ahead of `origin/main`; and the dashboard points to exact implementation
evidence while retaining independent review as the next step.
### Completion Criteria
- Workspace status accurately identifies Feature 0014 as implemented and
awaiting review.
- The roadmap remains the durable target-state record and is not polluted with
execution logs.
- Workspace status accurately identifies Feature 0015 as implemented and
awaiting independent review.
- The roadmap remains the durable target-state record and contains no command
log or transient execution notes.
- The active plan records concise implementation evidence and contains no
false completion claim.
- The workspace repository is clean after the handoff commit.
### Commit
Commit intent: `Record pipeline operator enrollment implementation`
Commit intent: `Record D&D storage and publishing implementation`
## Final Validation and Handoff
- Confirm Stage 1's complete standalone integration result and Stage 2's
complete collection integration result.
- Confirm Stage 1's complete standalone pipeline integration result and Stage
3's complete collection integration result.
- Run `./scripts/status` and confirm every repository is clean, with no
unexpected branch divergence or untracked artifact.
- Report the full pipeline, collection merge, collection subtree-squash, and
workspace handoff commit hashes.
- Summarize any deviation from this plan, unresolved finding, or added
implementation complexity and identify the acceptance criterion that
required it.
- Do not mark Feature 0014 `done`; implementation results require independent
- Report the full pipeline commit, collection fixture commit, collection
subtree merge and squash commits, and workspace handoff commit.
- Confirm that `ansible-role-narratio`, all other standalone roles,
applications, assets, and `rakestraw-ansible` remained unchanged.
- Summarize any deviation from this plan, unresolved finding, or complexity
added beyond direct variable mapping and identify the acceptance criterion
that required it.
- Do not mark Feature 0015 `done`; implementation results require independent
review first.
## Progress Notes
- Stage 1 complete: `ansible-role-dnd-pipeline`
`c13f726a0a846180a1aa95d110b8bbc801edaae5` implements optional enrollment
of existing operators; the complete standalone integration suite passed and
the commit is public on `origin/main`.
- Stage 2 complete: `ansible-collection-dnd` merge
`c0b0ebd13e92199f3d94e138c6cc50d1ece5dadd` imports the exact public pipeline
change through squash `d292297b6ad179e4664c01ad07cddaefff12f769`;
the complete collection integration suite passed and the history is public
on `origin/main`.
- Stage 3 complete: `ansible-workspace-dnd`
`bf81461de60001a0d8050e560383c6ddf533209f` records the implementation
evidence while Feature 0014 remains `in_progress` for independent review.
- Deviations: none.
- Planning complete; implementation has not begun.