# Feature 0008 Remediation Review Status: resolved Reviewed implementation commits: - `bc6df2a Add the D&D Audita configuration defaults` - `7ca812c Add the Narratio D&D processing configuration` - `c1fa8ba Test the D&D processing configuration` - `e99983b Document D&D processing profiles and artifacts` The implementation substantially matches Feature 0008. The pipeline role selects the complete D&D Audita policy, deploys a small explicit ConfigKit layout, keeps each ordinary artifact and the character family in its own fragment, and provides a testing overlay that changes only Scriptorium profile selection. Production convergence adds only one directory loop and one template loop. Native validation, artifact inspection, both campaigns, profile selection, and repeated convergence all succeed. Two narrow findings remain. ## Finding 1: Pin the Narratio Configuration Boundary Used by the Pipeline Severity: medium `ansible-role-dnd-pipeline/tasks/main.yml:29-65` writes suite-owned fragments under the fixed `/usr/local/etc/narratio` root and assigns them to the fixed `narratio` group. `meta/main.yml:75-96` gives the standalone Narratio role relative imports, but does not set `narratio_config_path` or `narratio_group`. The assembled role therefore relies on two standalone-role defaults for state that the pipeline itself consumes. If inventory supplies either unmapped standalone variable—or if the standalone defaults later change—the Narratio role can write its root document somewhere other than `/usr/local/etc/narratio/pipeline.yml` or create a differently named group, while the pipeline role continues using its fixed path and group. The result is either unresolved relative imports or a failed file task on a fresh host. These are cross-role coordination values, not application-local defaults. The roadmap explicitly fixes the root document, imported layout, and `root:narratio` ownership boundary, so the suite role must establish the same values on both sides. ### Required Remediation - In the `rakestraw.narratio` dependency variables, explicitly set `narratio_config_path: /usr/local/etc/narratio/pipeline.yml` and `narratio_group: narratio`. - Keep the fixed task paths and ownership unchanged. Do not add state probes, path-discovery facts, or new public variables merely to restate this fixed topology. - Retain the exact relative import list and confirm native base/testing validation and clean repeated convergence. ## Finding 2: Derive the Production Prompt Profile in the Integration Test Severity: low `ansible-role-dnd-pipeline/tests/integration:87-90` separately asks Scriptorium to inspect the hard-coded `claude-fable-latest` profile and then inspects `dnd.session_recap` version `2.0.0`. The useful behavior is that the explicitly inspected prompt's declared production profile resolves. The literal profile name instead freezes a prompt-owned current value in the test. If the prompt deliberately selects a new default profile, this check can either fail because the old profile is removed or continue passing without verifying the new production profile. That is the change-detector pattern prohibited by the testing policy. ### Required Remediation - Capture the existing native JSON result for the explicitly selected `dnd.session_recap` prompt once. - Read its `default_profile_id` and pass that value to Scriptorium's native `inspect profile` command. - Preserve the explicit `endpoint-profile` override as the representative caller-selected testing case. - Do not assert that `claude-fable-latest`, `gemini-flash-latest`, or any other prompt/profile value remains a current default, and do not snapshot the complete prompt document. ## Resolution Resolved in pipeline-role commit `3e253d7`. The Narratio dependency now pins the fixed configuration path and group consumed by the pipeline role. The integration driver now obtains the selected recap prompt's `default_profile_id` from Scriptorium's native JSON inspection and validates that profile without naming a prompt-owned default in the test. No public variables, convergence tasks, or supplemental state were added. ## Validation From `ansible-role-dnd-pipeline`, run: ```text bash -n tests/integration tests/integration git diff --check git status --short --branch ``` Expected result: syntax checking and production-profile lint pass; Audita and Narratio validate natively; base/testing comparison, representative inferred dependency, family expansion, derived production-profile resolution, and the explicit testing-profile override all succeed without provider calls; every immediate repeat reports `changed=0` and `failed=0`; and only intended remediation changes remain before commit. From the workspace root, run: ```text ./scripts/status ``` Expected result: implementation and reference repositories remain clean except for intended remediation work before it is committed. ## Review Validation Evidence During review, `ansible-role-dnd-pipeline/tests/integration` completed successfully. It installed fresh pinned dependencies, passed Ansible syntax checking and production-profile lint, validated the managed Audita policy, validated base and testing Narratio configuration, observed the enabled recap, inferred recap-to-rumor dependency, and disabled party-expanded character family, resolved production and explicitly selected testing Scriptorium profiles, and reported `changed=0` and `failed=0` on every required immediate repeat. Cleanup restored the baseline suite. Direct review also validated the `dilfs` campaign, inspected ConfigKit source ownership and the complete effective artifact catalog, confirmed that the default `gemini-flash-latest` testing profile currently resolves, and verified that all profile differences are confined to `profile_id` leaves. All repositories were clean before this remediation document was written. After remediation, `bash -n tests/integration`, the complete integration driver, and `git diff --check` passed again. The driver performed fresh dependency bootstrap, syntax checking, production-profile lint, native Audita and Narratio validation, artifact and profile inspection, the explicit testing-profile scenario, the explicit Seriatim-version scenario, and clean immediate repeats before restoring the baseline suite.