Compare commits

..

37 Commits

Author SHA1 Message Date
43ecdebcc5 Close out the coordinated suite upgrade 2026-09-29 15:17:31 +00:00
6829439807 Record resolution of the suite upgrade review findings 2026-09-29 15:10:17 +00:00
fec2f89b48 Record coordinated suite upgrade validation 2026-09-29 14:58:35 +00:00
1f41045830 Record consumer upgrade preparation 2026-09-29 14:55:59 +00:00
f964b24f7e Record validated collection assembly revision 2026-09-29 14:51:58 +00:00
8b8c232043 Record validated pipeline assembly revision 2026-09-29 14:46:31 +00:00
1b1382fe6e Record suite configuration migration completion 2026-09-29 14:32:20 +00:00
c0a0dae794 Record the coordinated suite upgrade in progress 2026-09-29 14:16:57 +00:00
82e672b888 Record Gitea publication blocker 2026-09-29 14:11:02 +00:00
f084988c80 Prepare the coordinated suite upgrade sprint 2026-09-29 14:08:18 +00:00
005a1c8ad5 Close out the standalone Narratio upgrade 2026-09-29 13:16:41 +00:00
ced9e66382 Record Narratio upgrade validation 2026-09-28 14:55:53 +00:00
0dc7e5b965 Record Narratio selector validation 2026-09-28 14:54:06 +00:00
2477189047 Record the Narratio upgrade in progress 2026-09-28 14:50:08 +00:00
8c689ea113 Prepare the Narratio upgrade implementation sprint 2026-09-28 14:43:11 +00:00
e93ebea771 Close out the standalone Notarius upgrade 2026-09-28 14:36:06 +00:00
a0414244bb Record Notarius upgrade validation 2026-09-28 14:14:58 +00:00
ae8d93f71a Record Notarius retry validation 2026-09-28 14:13:33 +00:00
bcaf48155e Record the Notarius upgrade in progress 2026-09-28 14:09:01 +00:00
760a172b34 Prepare the Notarius upgrade implementation sprint 2026-09-28 14:06:57 +00:00
8111f66de5 Close out the standalone Audita upgrade 2026-09-28 13:52:04 +00:00
f58c960b56 Record the standalone Audita upgrade for review 2026-09-28 13:48:14 +00:00
5301dac921 Record completion of Audita configuration coverage 2026-09-28 13:45:52 +00:00
c0582faa24 Record completion of Audita version 2 role migration 2026-09-28 13:42:24 +00:00
e0153d938b Plan the standalone Audita version 2 upgrade 2026-09-28 13:33:47 +00:00
86836879eb Close out the standalone Scriptorium upgrade 2026-09-28 13:16:30 +00:00
e7f5e4753a Record the standalone Scriptorium upgrade for review 2026-09-28 03:52:37 +00:00
98abc1b905 Record completion of Scriptorium configuration interface 2026-09-28 03:50:16 +00:00
aa9338b135 Record completion of Scriptorium version adoption 2026-09-28 03:44:53 +00:00
5a8e3fccc9 Plan the standalone Scriptorium upgrade 2026-09-28 03:40:04 +00:00
3bc042ea22 Close out the Notarius testing overlay feature 2026-09-22 19:25:35 +00:00
47129b213d Record the Notarius testing overlay implementation for review 2026-09-22 19:01:09 +00:00
8cd642ffa6 Record the testing overlay collection snapshot 2026-09-22 18:57:31 +00:00
ad739671f6 Record the Notarius testing overlay implementation 2026-09-22 18:52:52 +00:00
0b2a45a327 Record the Notarius v0.7.1 role update 2026-09-22 18:36:23 +00:00
59b472d0a1 Record the Narratio profile selector implementation 2026-09-22 18:33:46 +00:00
38dfb0422c Plan the Notarius testing overlay implementation 2026-09-22 18:23:20 +00:00
10 changed files with 1499 additions and 133 deletions

View File

@@ -0,0 +1,88 @@
# Application Upgrade Sequence
Decision agreed: 2026-09-28
## Purpose and Order
Adopt the newly released applications through focused, individually reviewed
features in this order:
**Scriptorium → Audita → Notarius → Narratio → suite integration.**
This document tracks the cross-feature direction, not implementation steps.
Each feature roadmap owns its scope and decisions. Only one staged plan is
active at a time, at [implementation.md](implementation.md).
## Version Baseline
These are the suite pins at the start of this upgrade, not assertions about
what is installed on an operational host. Targets are the releases reviewed
on the decision date; later releases require deliberate review.
| Application | Starting suite version | Adoption target |
| --- | --- | --- |
| Scriptorium | v0.13.0 | v0.15.0 |
| Audita | v0.9.1 | v2.0.1 |
| Notarius | v0.7.1 | v0.8.1 |
| Narratio | v2.2.0 | v3.0.0 |
Seriatim is unchanged by this sequence.
## Progress and Feature Links
Release-summary and migration-guidance triage is complete. Standalone
Scriptorium, Audita, Notarius, and Narratio adoption are complete after independent
review. Coordinated suite integration and its three review remediations are
complete. This upgrade sequence was closed on 2026-09-29; operational deployment
and a new tagged release remain separate activities.
- [x] [Feature 0018: Scriptorium adoption](features/0018-scriptorium-v0-15-adoption.md) — complete through role `b174c8c`; independent review found no remediation issues.
- [x] [Feature 0019: Audita adoption](features/0019-audita-v2-adoption.md) — complete through role `c3dd59f`; independent review found no remediation issues.
- [x] [Feature 0020: Notarius adoption](features/0020-notarius-v0-8-adoption.md) — complete through role `6aef48b`; independent review found no remediation issues; suite unchanged.
- [x] [Feature 0021: Narratio adoption](features/0021-narratio-v3-adoption.md) — complete through role `3c0700b`; independent review found no remediation issues; suite unchanged.
- [x] [Feature 0022: Coordinated suite integration](features/0022-coordinated-suite-upgrade.md) — complete with three review findings resolved at public pipeline `37b1cf6`, public collection `b3bc045`, and local consumer `15f0f4e`.
## Adoption Boundaries
Completing a standalone-role update does **not** advance the suite's application
or role dependency pins, collection snapshot, or deployment-repository pins.
Keep that existing compatibility set until the final integration feature
assembles and validates the coordinated configuration.
Standalone features own generic application interfaces. The integration feature
owns D&D defaults, cross-application configuration, testing overlays, credential
references, compatible dependency pins, and consumer upgrade guidance. Each
feature follows roadmap → staged plan → implementation → review → closeout.
No operational deployment is authorized merely by this sequencing decision.
## Compatibility Constraints to Carry Forward
- **Scriptorium is not a documentation-only upgrade from our baseline.** The
intervening v0.14.0 introduces ConfigKit and changes configuration acceptance,
selection, and retry behavior. Review those changes as well as v0.15.0's
licensing and dependency updates.
- **Audita and Narratio need a coordinated suite cutover.** Audita v2 requires
migrated configuration; Narratio v3 expects that interface and no longer owns
the retired downstream settings or generated Audita configuration.
- **Overlay terminology changes on both sides of the Notarius boundary.**
Narratio's selector and the suite-managed downstream files must migrate
together. Preserve explicit selection and independent application ownership.
- **Existing Narratio manifests need operator migration guidance.** Carry the
upstream provenance-field migration into final integration planning. Preserve
session progress; do not infer a requirement to delete checkpoints, force all
stages, edit immutable remote snapshots, or automate the migration.
- **Review retry and timeout semantics explicitly.** New transport retry and
repair behavior is not necessarily equivalent to the previous settings.
Preserve user intent without copying old values mechanically or inventing
new suite policy.
The upstream documentation remains authoritative for exact fields and migration
procedures:
- [Scriptorium v0.14.0](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.14.0/docs/releases/v0.14.0.md)
and [v0.15.0](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/releases/v0.15.0.md).
- [Audita v2 migration](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/migrations/v2.md).
- [Notarius v0.8.0](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.0/docs/releases/v0.8.0.md)
and [v0.8.1](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.1/docs/releases/v0.8.1.md).
- [Narratio v3.0.0](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/releases/v3.0.0.md)
and [migration procedures](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/operations.md#migrating-manifest-overlay-provenance).

View File

@@ -0,0 +1,199 @@
# Feature 0017: Notarius Testing Overlay
Status: done
## Summary
Selecting Narratio's `testing` profile also selects a separately managed
Notarius `testing` configuration overlay. Operators can develop D&D assets
with economical extraction settings without modifying production configuration
or invoking Notarius separately.
## Problem or Opportunity
The suite's existing testing overlay changes Scriptorium selections but leaves
Notarius on its production configuration. Narratio v2.2.0 now provides the
explicit `pipeline.notarius.config_profile` interface requested by this consumer.
Notarius v0.7.1 retains the corresponding `--config-profile` option and updates
PromptKit and its provider catalogs. This feature adopts v0.7.1 as its baseline.
## Scope
- Expose the optional native selector in the standalone Narratio role.
- Update standalone Notarius and suite version defaults to v0.7.1, with
matching current-version documentation and collection distribution.
- Deploy a Notarius ConfigKit testing overlay through the suite role.
- Explicitly select that overlay from Narratio's existing testing overlay.
- Select `gpt-terra-latest` for production and `gpt-luna-latest` for testing,
while retaining inventory overrides for both choices.
- Document and validate the composed configuration, then distribute the
updated suite through the collection and refresh the consumer dependency pin.
## Non-goals
- Further upstream application changes or a Narratio-side LLM-profile override.
- Automatically propagating profile names between applications.
- Disabling Notarius, caching, publishing, or other pipeline stages for testing.
- New credentials, cache layouts, other production tuning, or deployment automation.
- Live controller/target deployment or paid model calls as completion gates.
## Target End State
### Standalone Narratio Interface
`narratio_notarius_config_profile` defaults to `null`. The role omits
`notarius.config_profile` when null and serializes explicitly supplied values,
including an empty string. Documentation and argument specifications expose
the field without duplicating or narrowing Narratio's selector semantics.
### Explicit Suite Composition
The suite leaves the base selector unset. Its existing Narratio
`profiles/testing.yml` includes:
```yaml
notarius:
config_profile: testing
```
The suite deploys `/usr/local/etc/notarius/profiles/testing.yml`. That file
overlays the selected suite pipeline's `llm_profile`, using
`dnd_pipeline_narratio_notarius_pipeline_id` as the pipeline key and a new
`dnd_pipeline_notarius_testing_llm_profile` variable as the value. It does not
copy the full pipeline definition. ConfigKit performs the ordinary merge.
The default suite pipeline currently inherits its LLM selection at pipeline
level. Caller-supplied binding-level selections retain Notarius's native
precedence; this feature does not rewrite arbitrary caller pipelines or promise
that a pipeline-level default overrides explicit binding choices.
### Production and Testing LLM Defaults
The suite's base `dnd-session` pipeline selects `llm_profile: gpt-terra-latest`
instead of `dnd-extraction`. Callers can continue overriding that choice through
the existing `dnd_pipeline_notarius_pipelines` mapping. The new
`dnd_pipeline_notarius_testing_llm_profile` defaults to `gpt-luna-latest`.
Both IDs are supplied by the OpenRouter catalog `v2.20260922.1` selected by
Notarius v0.7.1. Use those native catalog profiles directly; no operator profile
asset or profile-source setting is needed for these defaults. Retain the
existing `OPENROUTER_API_KEY` credential reference. These are deliberately
moving `latest` selections, not promises of immutable underlying model versions.
This production-model policy belongs to the suite, not the standalone role.
Notarius stays enabled and retains its configured caching, output contracts,
references, and production defaults outside this overlay. Existing Scriptorium
testing overrides remain intact. Credentials continue through the existing
typed reference and suite secrets interfaces; no credential values enter YAML.
Configuration files and directories use the suite's existing owner, group,
and mode variables. The selector and overlay add no new runtime identity or
filesystem-permission policy.
## Repository Ownership
- `ansible-role-narratio`: generic optional selector, documentation, and tests.
- `ansible-role-notarius`: v0.7.1 installation default and corresponding
documentation; existing profile-source settings remain sufficient.
- `ansible-role-dnd-pipeline`: testing policy, overlay assets, and composition.
- `ansible-collection-dnd`: imported pipeline snapshot and compatible dependency
manifest. Its current Narratio-role `v0.1.0` pin must advance to include the
new public variable; changing only the sibling role is insufficient.
- `rakestraw-ansible`: matching dependency pins and concise operator guidance.
- Workspace: roadmap, implementation plan, progress, and review.
- Narratio and Notarius applications: read-only authoritative contracts.
The standalone Notarius role already exposes profile-source settings and
does not need D&D-specific overlay policy.
## Constraints and Settled Decisions
Follow the [MVP roadmap](../mvp.md), [Ansible house style](../../ansible.md),
and [testing house style](../../testing.md). Narratio v2.2.0 is already selected
by the suite; Notarius v0.7.1 is the selected target. Consult these tags, not
only newer application checkouts.
### Notarius v0.7.1 Compatibility
The [upstream release notes](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.7.1/docs/releases/v0.7.1.md)
describe unchanged CLI, configuration, artifact, and subprocess contracts.
The application-owned `dnd-extraction` fallback retains its settings and no
configuration migration is required. Independently of that upstream behavior,
the user has selected `gpt-terra-latest` as this suite's new production default.
Profile selection must use the catalogs selected by v0.7.1 (PromptKit v0.10.0).
The removed `deepseek-3-2`, `deepseek-4-flash`, and `deepseek-4-pro` catalog IDs
must not be assumed available or silently replaced by similarly named profiles.
This is deployment guidance, not a request for an Ansible catalog validator.
Existing checkpoints with the previous profile-source identity are not reused;
source-keyed chunk plans and existing output artifacts are unaffected. Document
this upstream upgrade behavior without deleting caches or forcing Narratio
extraction automatically.
Each application owns its configuration. Narratio selects the downstream
overlay; Notarius resolves and validates it. Existing application behavior owns
extraction reuse when selections change and explicit-force handling for changes
behind a stable profile name. Do not add Ansible state tracking for either.
## Simplest Viable Implementation
Add one nullable role field and its conditional template output. Extend the
suite's existing directory/template management to deploy the Notarius overlay
and extend the existing Narratio testing template with the explicit selector.
Use native serialization and ordinary file/template modules. Select the two
existing catalog IDs rather than deploying duplicate profile definitions. No assembly facts,
preflight state probes, or generic overlay-management framework is required.
## Rationale and Alternatives
A downstream ConfigKit overlay can own model choices and later Notarius tuning
without expanding Narratio's configuration surface for each setting. Direct
LLM-profile forwarding would solve only the model-selection case. Automatic
profile propagation would couple unrelated profile names and is not selected.
## Acceptance Criteria
- The standalone role omits an unset selector and preserves explicitly supplied
representative values, including the empty-string base selector.
- Native configuration inspection shows Narratio testing selecting Notarius
testing, and Notarius testing selecting the requested LLM profile. Base
configuration retains its production selection.
- A representative inventory-supplied testing selection is supported. Tests
exercise behavior rather than asserting that today's default model stays fixed.
- Notarius's deployed-version validation accepts the composed pipeline and
selected profile. No paid inference is required.
- Existing integration coverage remains valid, and immediate repeated role
convergence reports no changes. Do not independently retest file-module
ownership, modes, or template-file existence.
- The built collection works with its declared public role dependencies; no
local sibling checkout is needed by consumers. Subtree imports follow the
documented public-Gitea workflow, and published tags remain immutable.
## Dependencies and Follow-up Work
The upstream selector shipped in Narratio v2.2.0; the downstream baseline is
now Notarius v0.7.1. Git history preserves the completed implementation plan.
Future testing-specific Notarius settings belong in its overlay but are not
implicitly included in this feature.
## Completion and Review Evidence
Completed and published in Narratio role `330afe7`, Notarius role `a82a83d`,
pipeline role `c56a942`, collection `ce5b838`, and consumer `0ced48c`.
Implementation reported passing full integration suites for both changed
application roles, the pipeline, and the collection, including clean repeated
convergence. Independent review found no code-quality issues, architecture gaps,
or unnecessarily strengthened requirements requiring remediation.
The review independently verified collection build and public dependency
installation, syntax and shell checks, native configuration validation,
consistent dependency pins, and exact subtree/source agreement. It reviewed
the recorded integration results without rerunning host-mutating suites.
Operational deployment and paid inference were neither required nor performed
as part of this feature review.
## Open Questions
None. The user selected `gpt-luna-latest` for testing and `gpt-terra-latest`
for production; both are available in the catalog selected by Notarius v0.7.1.

View File

@@ -0,0 +1,163 @@
# Feature 0018: Adopt Scriptorium v0.15.0 in the Standalone Role
Status: done
## Summary
Update the standalone Scriptorium role from v0.13.0 to v0.15.0 and expose its
new application-configuration settings using our existing nullable-variable
conventions. This is the first feature in the agreed
[application upgrade sequence](../application-upgrade-sequence.md).
## Problem or Opportunity
Although v0.15.0 primarily changes licensing and dependency versions, the
intervening v0.14.0 adopted ConfigKit and added application imports, overlays,
inspection, and transient retry controls. A version bump alone would leave
new configuration settings unavailable through the role's public interface.
The current role already emits `{}` for an unconfigured installation, omits
null optional fields, serializes mappings, and retains explicit falsey values.
Those practices remain compatible with the stricter upstream configuration
contract; no new production validation or migration mechanism is needed.
## Scope
- Adopt v0.15.0 as the standalone role's default source version.
- Expose ConfigKit imports and the application transient-retry setting.
- Confirm existing configuration variables and representative backend mappings
remain usable with the new application version.
- Update role documentation and focused offline integration coverage.
- Record completion and the role revision for later coordinated integration.
## Non-goals
- Changing pipeline, collection, consumer, or other application-role pins.
- D&D model choices, production/testing policy, or new provider credentials.
- Deploying prompt/profile/schema libraries or managing arbitrary overlay files.
- Selecting a runtime overlay for callers, managing a service, or adding HTTP
request/CLI-only controls such as execution reports and run deadlines to YAML.
- Upstream application changes, paid inference, or operational host deployment.
- Relicensing this Ansible role or copying upstream source/license material
into the role repository merely because the installed application changed.
## Target End State
### Installation and Existing Configuration
`scriptorium_version` defaults to `v0.15.0`. Retain the existing source checkout,
Go build, ownership, and permission behavior and the caller-selected version
interface. No build-toolchain change is required: the current Go 1.26 selection
satisfies the release's Go requirement.
Existing application fields keep their public variable names. Optional variables
remain null by default and are omitted; explicit supported zero/empty values
are serialized without truthiness checks. An installation with no application
settings still receives `{}`, not an empty file.
### New Public Variables
| Variable | Default | Rendered field |
| --- | --- | --- |
| `scriptorium_configkit_imports` | `null` | `configkit.imports` |
| `scriptorium_transient_retries` | `null` | `transient_retries` |
Imports are a native list of mapping entries, consistent with the other roles'
ConfigKit interfaces. Serialize the supplied list without reinterpreting path,
glob, or optional-entry semantics. Emit the parent section only when selected.
The caller owns referenced fragment and overlay files; ordinary inventory can
compose the list without a second raw-configuration interface.
Transient retries is an optional integer. Null means omit and inherit the
application/PromptKit default; zero explicitly disables additional transient
attempts. The standalone role does not freeze the upstream default or add a
retry budget of its own. Argument specifications and documentation describe
both variables consistently.
### Compatibility Guidance
Document the distinction between ConfigKit `overlays/` selected by
`--config-overlay` and PromptKit LLM profiles. Imports are configuration-root
relative, while application path values retain their process-working-directory
semantics. Link upstream for detailed validation and precedence rules.
Call out stricter YAML acceptance and changed retry behavior, plus the removal
of legacy DeepSeek catalog IDs, without installing compatibility aliases or
inventing role-side configuration guards. New fields should only be supplied
when selecting an application version that supports them.
Mention that Scriptorium v0.15.0's application grant is GPL-3.0-or-later and link
its tagged licensing notices. Do not conflate the application's grant with the
role's license or introduce legal approval as a deployment gate.
## Repository Ownership
- `ansible-role-scriptorium`: default version, variables, argument specification,
template, README, and repository-local tests.
- Workspace: feature roadmap, staged plan, progress, and review evidence.
- Scriptorium application: read-only tagged configuration/release contracts.
- Pipeline, collection, consumer, and asset repositories remain unchanged.
## Constraints and Settled Decisions
Follow the [Ansible house style](../../ansible.md),
[testing house style](../../testing.md), [MVP roadmap](../mvp.md), and
[upgrade sequence](../application-upgrade-sequence.md). Review the tagged
v0.15.0 contract rather than assuming later application changes apply.
The existing suite continues installing its current Scriptorium role/application
pins until final integration. Standalone adoption is not suite publication.
## Simplest Viable Implementation
Update the version default and extend the existing defaults, argument
specification, and single configuration template with the two optional fields.
Include both in the empty-document condition. Reuse the existing source/build
and file/template tasks unchanged. No additional runtime tasks are needed.
## Acceptance Criteria
- The default role installs v0.15.0 and native offline configuration validation
accepts the default and representative managed configurations.
- Representative non-null and falsey values remain correctly rendered; the new
retry field preserves explicit zero and is omitted when unset.
- A caller-supplied import is composed successfully by native configuration
inspection using a small externally supplied test fragment. An optional test
overlay can demonstrate native composition without adding role-owned overlay
management or retesting ConfigKit's complete precedence/error matrix.
- Existing offline profile/backend inspection remains useful and passes.
Application validation alone does not prove PromptKit source validity.
- Immediate repeated role application reports no changes. Tests assert supplied
configuration outcomes, not today's upstream/default version, catalog contents,
task arrangement, or file-module postconditions.
- Syntax/lint and repository integration checks pass without provider calls,
real secrets, or operational controller access.
- Suite and consumer pins remain unchanged, and completion identifies the role
commit available for the final integration feature.
## Dependencies and Follow-up Work
Git history preserves the completed staged plan.
Audita adoption is next. The eventual suite integration
feature owns propagation of the new role revision, deployment settings, and
coordinated upgrade guidance.
## Completion and Review Evidence
Completed in role commits `61dcafe`, `2fce529`, and `b174c8c`. Implementation
reported passing integration tests, including native configuration validation,
offline profile inspection, imports, explicit retry zero, and clean repeat
convergence. Independent review found no code-quality issues, implementation
gaps, or unnecessarily strengthened requirements requiring remediation.
Independent syntax, production-profile lint, shell syntax, whitespace, native
configuration validation, and focused template checks passed. The review used
recorded integration evidence without rerunning host-mutating suites. No new
production tasks or suite/collection/consumer pin changes were introduced.
No operational deployment is claimed.
## Upstream References
- [v0.15.0 configuration](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/config.md)
- [v0.14.0 migration notes](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.14.0/docs/releases/v0.14.0.md)
- [v0.15.0 release and licensing notes](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.15.0/docs/releases/v0.15.0.md)

View File

@@ -0,0 +1,199 @@
# Feature 0019: Adopt Audita v2.0.1 in the Standalone Role
Status: done
## Summary
Replace the standalone Audita role's version-1 configuration interface with
Audita v2.0.1's native interface. Keep provider and D&D policy outside the
generic role. This is the second feature in the agreed
[application upgrade sequence](../application-upgrade-sequence.md).
## Problem or Opportunity
The role currently installs Audita v0.9.1 and renders version-1 configuration.
Audita v2 requires version-2 YAML, named backends, and selected PromptKit
profiles. Old per-role endpoint/model/credential/concurrency settings no longer
apply. A version-only update would produce an unusable deployment.
Unlike the previous minimal configuration, a valid v2 configuration requires
at least one backend and a proposal profile whose file exists. The generic role
must not invent a provider, endpoint, model, or credential to meet that contract.
The caller-input boundary is settled below.
## Scope
- Default to Audita v2.0.1 and configuration version 2.
- Replace retired public configuration variables with native v2 settings.
- Preserve still-supported domain controls and inventory composition.
- Document the breaking role-variable migration and caller prerequisites.
- Adapt offline integration tests to real v2 configuration/profile fixtures.
## Non-goals
- Updating pipeline, collection, or consumer application/dependency pins.
- Choosing D&D models, endpoints, credentials, concurrency, or retry budgets.
- Compatibility shims, automatic v1 conversion, or a dual-schema template.
- Live inference, operational deployment, report ingestion, service management,
or runtime configuration validation tasks.
- Imports: Audita deliberately disables ConfigKit imports. Do not add an import
variable merely because other applications expose one.
- Automatically provisioning secret values or selecting runtime overlays.
## Target End State
### Installation and Schema
`audita_version` defaults to `v2.0.1`; `audita_config_version` defaults to `2`.
Retain the existing source checkout, conditional Go build, dependency management,
configuration location, and owner/group/mode interfaces. Go 1.26 remains suitable.
The role renders v2 only; selecting an older application does not translate its
configuration. Operators needing v1 retain the previous role revision.
### Public Configuration Interface
Use these field-specific variables; optional settings default to null and are
omitted, allowing Audita to own defaults. Serialize native values and preserve
intentional zero, false, empty strings, and empty collections where supported.
| Role variable | Native field | Ownership |
| --- | --- | --- |
| `audita_profiles_dir` | `profiles_dir` | Optional caller profile location |
| `audita_backends` | `backends` | Caller-supplied native mapping |
| `audita_llm_proposal_profile` | `llm.proposal_profile` | Caller-selected required profile |
| `audita_llm_validation_profile` | `llm.validation_profile` | Optional; omission inherits proposal |
| `audita_llm_transient_retries` | `llm.transient_retries` | Optional native retry budget |
| `audita_llm_repair_attempts` | `llm.repair_attempts` | Optional native repair budget |
| `audita_llm_operation_timeout` | `llm.operation_timeout` | Optional duration string |
| `audita_validation_max_prompt_tokens` | `validation.max_prompt_tokens` | Optional batching control |
| `audita_reporting_enabled` | `reporting.enabled` | Optional report policy |
| `audita_reporting_stdout_dir` | `reporting.stdout_dir` | Optional report destination |
| `audita_diagnostics_debug` | `diagnostics.debug` | Optional debug policy |
Retain existing variables for modules, output schema, chunking, normalization,
thresholds, context description, and diagnostics work directory. Normalization
gap/duration fields now represent numeric seconds, not duration strings.
Argument specifications must accept the native integer/fractional values without
turning them into quoted strings in YAML. Do not add a duration-conversion layer.
Remove the old `audita_llm_{proposal,validation}_{base_url,model,api_key_env,timeout,max_retries}`,
`audita_concurrency_{total_llm,proposal_llm,validation_llm}`, and
`audita_diagnostics_retention` interfaces from defaults, templates, argument
specifications, and current examples. Document their replacements rather than
silently interpreting them under different semantics or adding deprecation probes.
The backend mapping carries endpoint, credential reference, concurrency, and
queue capacity using Audita's schema. Inventory can compose it with ordinary
Jinja expressions. Credential values stay outside the role; every surviving
backend reference must be available when Audita loads configuration, even when
that backend is not selected. Do not introduce separate per-role secret variables.
Null role variables mean omission, not literal YAML null. In particular, omit
an unset validation profile so Audita can inherit the proposal selection.
Backend mapping values retain native semantics, including a null credential.
### Profile and Overlay Ownership
Callers provide `audita_backends` and `audita_llm_proposal_profile`; neither has
a fabricated concrete default. Callers also deploy the selected profile files
before invoking Audita. `audita_profiles_dir` may be supplied or omitted to use
Audita's conventional sibling `profiles/` directory. Keep profile documents and
ConfigKit `overlays/` content caller-owned in this feature.
The later suite feature will own its D&D profile assets and coordinate their
deployment with Narratio's new external Audita configuration contract. The role
does not start processing or validate file availability during convergence.
## Repository Ownership
- `ansible-role-audita`: generic installation/configuration interface, migration
documentation, and local tests.
- Workspace: roadmap, active plan, progress, and review evidence.
- Audita application: read-only tagged schema, migration, and profile contracts.
- Other applications/roles, assets, pipeline, collection, and consumer: unchanged.
## Constraints and Settled Decisions
Follow the [Ansible house style](../../ansible.md),
[testing house style](../../testing.md), [MVP roadmap](../mvp.md), and
[upgrade sequence](../application-upgrade-sequence.md). The suite continues to
use its old compatible role/application set until final integration; Narratio v2
must not be accidentally paired with Audita v2 through a changed suite pin.
Old timeouts and retries do not map one-to-one to profile per-attempt timeouts,
logical-operation deadlines, transport retries, and structural repair. Expose
native controls without choosing replacement tuning for the D&D suite here.
## Simplest Viable Implementation
Update the version/schema defaults and replace the single configuration template's
retired sections with native v2 sections. Align argument specifications and the
README. Keep ordinary file/template/source/build tasks. Use the existing test
harness with caller-owned local backend/profile fixtures; add no state assembly,
profile resolver, migration command, or production probe.
## Acceptance Criteria
- The role installs v2.0.1 and renders native v2 configuration from supplied
backend/profile choices and optional settings.
- Native offline validation and effective-settings/profile inspection accept
representative configuration with an externally supplied profile and local
fixture endpoint; no provider request is needed.
- Tests cover supplied mapping composition, omission/inherited validation
selection, representative numeric seconds, and meaningful zero/false values.
Avoid a comprehensive schema matrix or assertions of current upstream defaults.
- Existing useful build and clean-repeat coverage remains. Immediate repeated
role convergence reports no changes; do not test module postconditions.
- Documentation explains required caller inputs and the breaking variable/schema
migration, linking Audita for full field and report semantics.
- No suite, collection, or consumer pins change. Completion records the reviewed
standalone role revision for the final integration feature.
## Rationale and Alternatives
Native backend mappings and named profiles preserve Audita's ownership instead
of reproducing per-role endpoint/model settings in Ansible. A dual-schema role
would add maintenance and ambiguity without a selected requirement; retaining
the previous role revision is the simpler boundary for old deployments.
## Dependencies and Follow-up Work
Git history preserves the completed staged plan. Notarius adoption is next.
D&D backend/profile assets,
tuning migration, testing overlays, credential lists, and coordinated deployment
belong to the later integration feature.
## Settled Caller-Input Decision
The user approved required `audita_backends` and `audita_llm_proposal_profile`
inputs through the ordinary role argument interface, with caller-owned profile
files. Do not give these variables null or fabricated defaults. A no-input role
invocation is no longer valid; examples and tests supply explicit choices.
Role-managed profile definitions are not part of this feature.
## Open Questions
None.
## Completion and Review Evidence
Completed in role commits `6137ff2`, `52f67fe`, and `c3dd59f`. Implementation
reported passing integration tests with native v2 validation, offline profile
inspection, mapping composition, omission, numeric seconds, falsey values,
build/recovery coverage, and clean repeated convergence.
Independent review found no code-quality issues, implementation gaps, or
unnecessarily strengthened requirements needing remediation. Independent
Ansible syntax, production-profile lint, shell syntax, whitespace, and focused
template checks passed. The review used recorded native/integration results
without rerunning the host-mutating suite.
No production tasks were added. Profile files remain caller-owned, and suite,
collection, and consumer pins remain unchanged. No operational deployment or
paid inference was performed as part of this review.
## Upstream References
- [v2.0.1 configuration](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/config.md)
- [v2 migration guide](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/migrations/v2.md)
- [v2.0.1 release](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/releases/v2.0.1.md)

View File

@@ -0,0 +1,173 @@
# Feature 0020: Adopt Notarius v0.8.1 in the Standalone Role
Status: done
## Summary
Update the standalone Notarius role from v0.7.1 to v0.8.1, expose the new
PromptKit transient-retry setting, and document the ConfigKit overlay rename.
This is the third feature in the agreed
[application upgrade sequence](../application-upgrade-sequence.md).
## Problem or Opportunity
Notarius v0.8.0 renamed configuration selection to `--config-overlay` and
`overlays/<name>.yml`, removing the previous flag and lookup directory. It also
introduced configurable provider transport retries. v0.8.1 updates ConfigKit
and PromptKit to v0.4.2 and v0.11.2 without further intentional configuration or
subprocess-contract changes.
The standalone role currently renders schema version 5, supports native imports
and caller-supplied pipelines, and leaves profile assets externally managed.
Those boundaries remain appropriate. The suite, however, still uses the old
downstream selector; its application and dependency pins must not advance yet.
## Scope
- Default the standalone role to Notarius v0.8.1.
- Expose `promptkit.transient_retries` through one nullable role variable.
- Verify existing imports, pipeline composition, profile-source settings, and
cache configuration remain compatible with the target release.
- Update standalone compatibility guidance and focused offline tests.
- Record the reviewed role revision for later coordinated suite integration.
## Non-goals
- Updating suite, collection, consumer, or other application-role pins.
- Migrating suite-owned testing files or Narratio's downstream selector.
- Deploying arbitrary overlay or LLM-profile assets in the generic role.
- Choosing D&D model, retry, timeout, or credential policy.
- Automatic renames, compatibility aliases, cache deletion, forced extraction,
or production validation tasks.
- Upstream application changes, live inference, or operational deployment.
## Target End State
### Installation and Configuration
`notarius_version` defaults to `v0.8.1`. Configuration remains schema version 5.
Preserve existing build, dependency, path, and owner/group/mode interfaces.
The existing Go selection remains unchanged.
Add `notarius_promptkit_transient_retries: null`, documented and declared as an
optional integer in argument specifications. When non-null, serialize it as
`promptkit.transient_retries`. Include it in the parent-section condition so a
retry-only configuration renders correctly. Null means omit the field; zero
disables additional transient attempts. Do not copy PromptKit's default into
role defaults, add a second retry mechanism, or reinterpret existing module
and validator retry settings.
Keep all existing supported native configuration variables. Preserve caller
mapping/list composition and omission of unset optional settings. The role does
not resolve, inspect, or rewrite caller-owned profile or overlay files.
### Overlay Migration Guidance
Document `--config-overlay` and the conventional `overlays/` directory for
operators invoking the new application. The old `--config-profile` and ConfigKit
`profiles/` lookup no longer work. This does not rename PromptKit LLM-profile
sources: `notarius_promptkit_profile_dir`, `notarius_promptkit_profile_file`,
pipeline `llm_profile`, and `--llm-profile` retain their separate meanings.
Caller-owned configuration overlay files must be migrated by their owner. In
this workspace the D&D suite owns its testing overlay, so that migration belongs
to final integration together with Narratio's new selector. Do not add generic
file-moving tasks or broaden this feature to fix the old suite in place.
### Retry and Checkpoint Compatibility
Explain that transport retries are additional attempts per generation and are
separate from pipeline/validator retries. Omission inherits upstream behavior;
operators may explicitly select zero. Later suite planning will review combined
retry and timeout budgets rather than copying old values mechanically.
Document v0.8.1's changed profile-source checkpoint identity: old matching
checkpoint identities are not reused, while source-keyed chunk plans and
published output are unaffected. Leave cache lifecycle with Notarius and do not
delete data or force Narratio stages as part of installing the role.
## Repository Ownership
- `ansible-role-notarius`: version default, optional retry field, argument
specification, template, documentation, and repository-local tests.
- Workspace: feature roadmap, staged plan, progress, and independent review.
- Notarius application: read-only tagged configuration/release contracts.
- Pipeline, collection, consumer, other roles, and assets remain unchanged.
## Constraints and Settled Decisions
Follow the [Ansible house style](../../ansible.md),
[testing house style](../../testing.md), [MVP roadmap](../mvp.md), and
[upgrade sequence](../application-upgrade-sequence.md). Use v0.8.1's contract,
including the intervening v0.8.0 migration notes, not assumptions from a newer
application checkout.
Retain meaningful tests that explicitly install v0.7.0 to prove caller-selected
version behavior. Leave the new retry field unset in those older-version cases;
do not change them merely because the role default advances.
## Simplest Viable Implementation
Update the application version and add one optional variable, argument-spec
entry, and conditional template field. Extend the existing integration fixture
with explicit retry zero and native configuration inspection. No new production
tasks, state probes, compatibility framework, or role-managed assets are needed.
## Rationale and Alternatives
The role manages persistent configuration; application invocation owns overlay
selection. Adding an overlay-selection variable or file-migration tasks here
would confuse those responsibilities. Documenting the breaking invocation
change and coordinating it later preserves independently usable roles and the
existing suite compatibility set.
## Acceptance Criteria
- The default role installs v0.8.1, and native offline validation accepts the
baseline and representative managed configurations.
- Null retry selection is omitted; explicitly supplied zero is rendered and
visible through native effective-configuration inspection. A retry-only
configuration produces its enclosing PromptKit section.
- Existing useful coverage for native import/pipeline composition, profile
configuration, cache settings, selected application version, and supplied Go
executable remains valid. Do not add a comprehensive upstream schema matrix.
- Immediate repeat convergence reports no changes. Tests assert supplied values
and role outcomes, not today's version/catalog defaults or module postconditions.
- Documentation accurately distinguishes configuration overlays from LLM
profiles and describes retry/checkpoint upgrade consequences.
- Syntax/lint and repository integration checks pass without live provider
calls or operational-host access.
- Suite, collection, and consumer pins stay unchanged; the reviewed standalone
revision is recorded for final integration.
## Dependencies and Follow-up Work
Implementation and independent review are complete. Git history preserves the
completed staged plan. Narratio v3 standalone adoption is next. Final integration
owns the coordinated overlay/credential/configuration migration and public suite
dependency updates. No open product decision is required for this narrow scope.
## Implementation Evidence
- Standalone role commits: `b1b922c` (v0.8.1 default and optional retry
interface), `380b6a3` (integration coverage), and `6aef48b` (upgrade
guidance). No production tasks or suite dependencies changed.
- Syntax check and production-profile lint passed. `bash -n` and the local
integration harness passed with native offline configuration validation,
rendered/effective retry checks, older-version and supplied-Go behavior,
import and pipeline composition, and clean immediate repeats. Role and
workspace whitespace checks passed.
- Independent review of all three role commits found no required remediation
or unjustified strengthening of requirements. Syntax, production-profile
lint, shell syntax, whitespace checks, and installed v0.8.1 native
configuration validation passed again during review. The review used the
recorded successful integration run rather than rerunning its host-mutating
scenarios. No remediation document was changed.
- Reviewed standalone revision: `6aef48b`. Narratio adoption and coordinated
suite migration remain separate follow-up work; suite pins are unchanged.
## Upstream References
- [v0.8.1 configuration](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.1/docs/config.md)
- [v0.8.0 migration notes](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.0/docs/releases/v0.8.0.md)
- [v0.8.1 release notes](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.1/docs/releases/v0.8.1.md)

View File

@@ -0,0 +1,234 @@
# Feature 0021: Adopt Narratio v3.0.0 in the Standalone Role
Status: done
## Summary
Update the standalone Narratio role from v2.2.0 to v3.0.0 and align its
configuration interface with the new Audita and Notarius contracts. This is
the fourth feature in the agreed
[application upgrade sequence](../application-upgrade-sequence.md). Suite
integration remains a separate, subsequent feature.
## Problem or Opportunity
Narratio v3 replaces configuration-profile terminology with overlays, replaces
singular downstream credential references with lists, and delegates Audita v2
configuration to Audita. The existing role still exposes retired fields that
v3 rejects. Advancing only the executable would therefore leave callers and
the representative configuration fixture with an incompatible interface.
## Scope
- Default the standalone role to Narratio v3.0.0.
- Align defaults, argument specifications, template, examples, and tests with
the changed downstream configuration fields.
- Document operator migration, ownership boundaries, and native compatibility
consequences without automating session or asset migration.
- Record the independently reviewed role revision for final suite integration.
## Non-goals
- Updating pipeline, collection, consumer, or other application-role pins.
- Deploying downstream applications, changing D&D defaults, or migrating
suite-owned testing overlays and credentials.
- Creating arbitrary overlay assets or selecting Narratio's runtime overlay
through an installer variable.
- Compatibility aliases, dual-version template branches, automatic migration
of existing manifests, cache deletion, or forced stage reruns.
- New production validation, credential discovery, runtime version gates,
forwarding/redaction machinery, or upstream application changes.
- Live providers, operational deployment, or publication.
## Target End State
### Standalone Installation
`narratio_version` defaults to `v3.0.0`. Preserve source-build behavior, Go
selection, service account, filesystem paths, owner/group/mode interfaces, and
the required caller-supplied WhisperX URL. Configuration continues to use the
existing root document shape and one ordinary template task. Unchanged native
fields and caller composition remain supported.
### Audita Interface
Add the following optional variables with null defaults. Field paths below
refer to the root configuration document's `audita` section; upstream prose
also calls this `pipeline.audita`.
| Role variable | Native field | Argument type |
| --- | --- | --- |
| `narratio_audita_credentials` | `audita.credentials` | list of strings |
| `narratio_audita_overlay` | `audita.overlay` | string |
| `narratio_audita_proposal_profile` | `audita.proposal_profile` | string |
| `narratio_audita_validation_profile` | `audita.validation_profile` | string |
Remove these retired role variables and their rendered fields:
- `narratio_audita_llm_api_key`
- `narratio_audita_base_url`
- `narratio_audita_model`
- `narratio_audita_total_llm_concurrency`
- `narratio_audita_proposal_llm_concurrency`
- `narratio_audita_validation_model`
- `narratio_audita_validation_llm_concurrency`
- `narratio_audita_work_dir_retention`
- `narratio_audita_report`
Retain binary, timeout, modules, transcript description, config path, and output
schema variables. Null modules are omitted; explicit `[]` means no correction
modules. Audita owns backend definitions, model/profile contents, concurrency,
reporting, and debug policy. Document migration to Audita's own configuration
without trying to infer replacements for those policies.
### Notarius Interface
Replace `narratio_notarius_config_profile` with
`narratio_notarius_config_overlay`, an optional nullable string rendered as
`notarius.config_overlay`. Preserve supplied empty strings, `default`, and
named selectors exactly; null omits the selector. Selection is independent of
Narratio's own overlay and is not a PromptKit LLM-profile selection.
Replace `narratio_notarius_llm_api_key` with
`narratio_notarius_credentials`, an optional nullable list of strings rendered
as `notarius.credentials`. Preserve other Notarius configuration interfaces,
including cache controls, references, and output mappings.
### Rendering and Credential Ownership
Use `is not none`, appropriate serialization, and parent-section conditions
covering the new variables. Null omits a field; empty lists and strings remain
explicit. Do not copy native defaults into optional role defaults.
Credential lists contain environment-variable/secret-reference **names**, not
secret values. Narratio resolves and forwards them under their exact names.
The role neither resolves credentials nor infers them from downstream files.
Null omits the field and `[]` emits an explicit empty list; Narratio overlays
replace lists rather than append to them. Operators must list every backend
credential needed by the selected Audita configuration, including configured
but unselected backends. Notarius likewise requires names matching its selected
provider configuration. Resolution occurs at pipeline loading, even when a
downstream stage will not execute.
Removing retired variables is a documented breaking role-interface migration.
Do not add alias precedence, version-dependent rendering, or special guards
for old inventory. Users retaining old deployments retain their old role pin.
### Operator Upgrade Guidance
- Replace Narratio `--profile` with `--overlay` and selected `profiles/` files
with `overlays/`. Explicit imports from a directory named `profiles` remain
valid; this is not a blanket filesystem rename or an LLM-profile rename.
- Migrate downstream Notarius selection to `config_overlay` and its selected
files to `overlays/`. Named selection needs a supporting Notarius executable;
v0.8.1 is the tested baseline, not a new unconditional role version gate.
- Audita v2 must be configured independently before running polish. Narratio
does not generate its config or infer downstream overlay/profile selectors.
- Link the tagged manifest migration procedure: back up old manifests and
migrate `effective_config.selected_profile` to `selected_overlay` while
preserving progress/checkpoint state. Do not rewrite immutable remote
snapshots or infer that every stage must rerun.
- Note the native extraction-resume consequence for renamed named Notarius
selectors: the next applicable run regenerates extraction with normal
dependent invalidation. Omitted/base selections do not gain invalidation
solely from this rename. The role does not implement this behavior.
## Repository Ownership
- `ansible-role-narratio`: standalone interface, template, documentation, and
repository-local tests.
- Workspace: roadmap, later staged plan, status, and independent review.
- `../narratio`: read-only authoritative v3.0.0 contracts.
- Pipeline, collection, consumer, assets, and other roles remain unchanged.
## Constraints and Settled Decisions
Follow the [Ansible house style](../../ansible.md),
[testing house style](../../testing.md), [MVP roadmap](../mvp.md), and
[upgrade sequence](../application-upgrade-sequence.md). Use tagged v3.0.0
contracts rather than assuming a newer checkout has the same interface.
Keep meaningful explicit v2.1.0 version-selection and supplied-Go recovery
tests where their baseline inputs remain compatible. Do not turn configurable
version selection into a promise that new configuration fields work on old
applications; new fields stay unset in those cases.
## Simplest Viable Implementation
Change the version default and the affected defaults, argument-spec entries,
and conditional template fields. Adapt existing representative fixtures and
native validation to the new public interface. No additional production tasks,
state probes, file migration, or configuration assembly mechanism is needed.
## Rationale and Alternatives
Expose the native v3 interface directly instead of retaining aliases or
translating legacy Audita tuning into guessed backend/profile definitions.
This preserves application ownership and avoids a compatibility framework in
the generic installer. Coordinated suite migration can then make explicit D&D
policy choices against already-reviewed standalone roles.
## Acceptance Criteria
- The default role installs Narratio v3.0.0; native offline validation accepts
baseline and representative rendered configuration.
- Added and renamed fields agree across defaults, argument specifications,
template, examples, and documentation. Retired native fields are not emitted.
- Focused behavioral cases demonstrate null omission, supplied credential-name
lists, explicit empty lists, named/empty downstream selectors, and existing
meaningful falsey and artifact-composition behavior. Keep this representative,
not a matrix of every native rule or a snapshot of today's defaults.
- Native validation uses synthetic credential values supplied only to the test
process as needed; managed configuration contains names, not values. No live
provider calls or reimplementation of upstream forwarding/redaction tests is
required. Preserve existing useful log checks without expanding their scope.
- Immediate identical role application reports no changes. Selected-version
and supplied-Go/missing-binary outcomes remain covered.
- Syntax/lint and local repository integration checks pass. No operational
controller, target deployment, downstream pipeline execution, or real keys
are prerequisites for standalone-role acceptance.
- Documentation explains breaking variable changes and links upstream upgrade
procedures. No production validation or automatic migration has been added.
- Suite, collection, and consumer pins remain unchanged. Independent review
records the standalone revision for coordinated integration.
## Dependencies and Follow-up Work
Standalone adoption and independent review are complete for all four upgraded
applications. Git history preserves the completed staged plan. The next,
coordinated integration feature owns D&D
configuration, credentials, overlay assets, coordinated dependency pins,
collection assembly, and consumer migration guidance. It must deliberately
review retry/timeout budgets rather than copying retired tuning mechanically.
## Open Questions
None identified for this standalone scope.
## Implementation Evidence
- Standalone role commits: `a28f22c` (v3 interface and migrated fixtures),
`45f6836` (selector and credential-list coverage), and `3c0700b` (upgrade
guidance). Production tasks, suite dependencies, collection, and consumer
remain unchanged.
- `bash -n` and the local integration harness passed. The harness includes
syntax check and production-profile lint and exercised native offline
baseline, named, and explicit-empty validation, selected v2.1.0 behavior,
supplied-Go recovery, synthetic credential loading, and clean immediate
repeats. Role and workspace whitespace checks passed.
- Independent review on 2026-09-29 found no required remediation or unjustified
strengthening of requirements. Syntax checks, production-profile lint, shell
syntax, whitespace checks, and native v3.0.0 configuration validation passed
again during review. The review used recorded successful integration runs
rather than rerunning their host-mutating scenarios. No remediation document
was changed.
- Reviewed standalone revision: `3c0700b`. Coordinated suite migration remains
separate follow-up work; suite, collection, and consumer pins are unchanged.
## Upstream References
- [Narratio v3.0.0 release](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/releases/v3.0.0.md)
- [Configuration](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/config.md)
- [Audita integration](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/integrations/audita.md)
- [Notarius integration](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/integrations/notarius.md)
- [Operator migration procedures](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/operations.md)

View File

@@ -0,0 +1,300 @@
# Feature 0022: Integrate the Reviewed Application Upgrades
Status: done
## Summary
Bring the four reviewed standalone upgrades into the D&D pipeline role,
collection, and deployment consumer as one compatible configuration set.
This completes the agreed
[application upgrade sequence](../application-upgrade-sequence.md).
## Problem or Opportunity
The standalone roles now support the new releases, but the suite intentionally
retains its previous pins and configuration. Audita still receives v1 settings;
Narratio and Notarius testing selection still uses retired profile terminology.
Updating executable versions alone would break the deployed configuration.
## Scope
- Adopt the reviewed application/role versions together.
- Provide Audita v2 backend configuration and suite-owned PromptKit profiles.
- Migrate Narratio credential forwarding and Narratio/Notarius testing overlays.
- Preserve D&D processing, artifact composition, storage/publishing, shared
filesystem, and operator-access behavior.
- Update the collection snapshot, public dependency manifests, consumer pins,
operator guidance, and focused offline integration coverage.
## Non-goals
- Deploying to the operational controller or `pipeline-dnd` host, running real
transcripts, or calling inference, WhisperX, or object-storage services.
- New models, prompts, artifact families, extraction lanes, or processing policy
beyond migration choices expressly approved here.
- Automatic manifest conversion, cache deletion, forced stage reruns, broad
directory cleanup, compatibility aliases, or runtime version/integrity probes.
- Changing generic standalone-role ownership or adding production validation.
- A newly tagged collection release or replacement of published 0.1.0 assets.
This feature updates the public development compatibility set; formal release
packaging remains a separate decision.
## Target End State
### Coordinated Versions and Distribution
| Application | Suite version | Reviewed standalone role revision |
| --- | --- | --- |
| Scriptorium | v0.15.0 | `b174c8c` |
| Audita | v2.0.1 | `c3dd59f` |
| Notarius | v0.8.1 | `6aef48b` |
| Narratio | v3.0.0 | `3c0700b` |
| Seriatim | v1.5.0, unchanged | existing v0.1.0 role pin |
Dependency manifests use full immutable revisions resolved from these reviewed
commits. The pipeline role remains authoritative; the collection imports its
completed revision through the established public Gitea subtree workflow, never
by editing `roles/pipeline` directly. The collection continues bundling the
pipeline role and declaring standalone role dependencies separately.
Relevant reviewed commits must be published to their existing public origins
before downstream manifests/subtree imports depend on them. Publication of the
required Git commits is part of the eventual implementation workflow, not this
roadmap-writing pass. Do not rewrite tags or publish unrelated changes.
The consumer keeps its minimal playbook and host-vars organization. Its role
and collection pins select the same compatibility set. No controller install
or remote playbook execution is an acceptance gate.
### Audita Backend and Profile Ownership
The pipeline role supplies `audita_backends`, profile selection, and schema-2
settings to the standalone Audita role. The pipeline owns the missing profile
assets under `/usr/local/etc/audita/profiles/`, using its runtime owner/group and
configuration modes. This directory contains PromptKit LLM profiles, not
ConfigKit overlays; it must not be renamed to `overlays`.
Approved suite interface:
- `dnd_pipeline_audita_backends`: native backend map, defaulting to one backend
named `dnd`, endpoint `https://inference.ai.rakestrawhome.com/v1`, credential
reference `AUDITA_LLM_API_KEY`, and shared concurrency `4`. Omit queue capacity
to inherit the native default.
- `dnd_pipeline_audita_profiles`: a native profile mapping keyed by file/profile
ID, with complete `dnd-proposal` and `dnd-validation` entries. Each selects
backend `dnd`, model `google/gemma-4-31b-it`, and per-attempt
`timeout_seconds: 900`. Other model controls inherit native behavior.
- `dnd_pipeline_audita_llm_proposal_profile` and
`dnd_pipeline_audita_llm_validation_profile` select those respective IDs.
Render each supplied profile as one safely serialized native mapping with its
matching ID. Document profile-map keys as filename-safe IDs. Do not introduce
per-provider templates, profile merging, or discovery of external assets.
Callers can compose native maps in inventory and replace the supplied maps.
As with existing managed secrets, removing a map entry does not imply pruning
arbitrary files; only selected profiles participate in normal execution.
Preserve the ordered module sequence, `audita-v1` output, chunking values,
thresholds, context description, and normalization limits. Convert normalization
duration defaults from `3s`, `3s`, and `240s` to numeric `3.0`, `3.0`, and
`240.0` seconds. Preserve meaningful setting names where native semantics are
unchanged; update argument types accordingly.
Remove retired per-role endpoint/model/credential/concurrency/retry variables
in favor of the native backend/profile interface. Document their replacements;
do not infer a conversion from arbitrary old inventory. Remove diagnostics
retention; leave debug disabled through native defaults. Retain the existing
diagnostics work-directory choice where still supported. Reporting follows
Audita's native configuration; Narratio consumes its ordinary output contract.
Production and testing continue using the same Audita endpoint and model.
No separate Audita testing overlay is needed for an identical configuration.
### Credential Lists and Overlay Selection
Replace the suite's singular Narratio Notarius credential variable with
`dnd_pipeline_narratio_notarius_credentials`, default `[OPENROUTER_API_KEY]`.
Add `dnd_pipeline_narratio_audita_credentials`, default `[AUDITA_LLM_API_KEY]`.
Pass both through the reviewed Narratio role's native list variables. These
lists contain names, never values, and can be replaced with `[]`. Operators
overriding Audita backends must explicitly list all referenced credentials;
the suite does not inspect configurations to discover names.
Preserve `dnd_pipeline_secrets`, existing secret names, Vault references,
protected secret directory/files, and ordinary world-readable nonsecret
configuration. No credential rotation, secret relocation, or forwarding logic
is required in Ansible.
Deploy the suite-owned testing files at:
- `/usr/local/etc/narratio/overlays/testing.yml`
- `/usr/local/etc/notarius/overlays/testing.yml`
Narratio testing sets `notarius.config_overlay: testing`; production omits the
selector. Notarius remains enabled in both modes. Its production pipeline
continues selecting `gpt-terra-latest`, testing selects `gpt-luna-latest`, and
the existing caller-overridable pipeline map/ID behavior remains intact.
Scriptorium testing still selects `gemini-flash-latest`; production continues
using the prompt assets' selections. Retain separate artifact/family fragments.
Use Narratio `--overlay testing` and Notarius `--config-overlay testing` in
tests and operator examples. Deploy the new files declaratively; leave ignored
legacy `profiles/testing.yml` files alone and document that they are obsolete.
Do not delete `profiles/` directories or conflate them with PromptKit profiles.
### Runtime Paths and Existing Suite Behavior
Keep Narratio's explicit downstream binaries/config paths, output handoffs,
Notarius `/var/cache/notarius` roots and resume behavior, shared writable
directories/ACLs, service user, operator enrollment, and S3/publishing choices.
Audita profiles are configuration assets, not shared output directories.
No new runtime storage architecture is required.
### Retry and Timeout Policy
Retain the previously selected per-attempt Audita profile timeouts of 900
seconds while inheriting the new applications' retry,
repair, and whole-operation defaults. Expose nullable suite pass-throughs for
`audita_llm_transient_retries`, `audita_llm_repair_attempts`,
`audita_llm_operation_timeout`, `notarius_promptkit_transient_retries`, and
`scriptorium_transient_retries`, prefixed with `dnd_pipeline_` in the public
suite interface. Null means omit; explicit zero is preserved where valid.
Do not mechanically translate old `max_retries: 3` into both transport retries
and structural repairs. Preserve explicitly authored Notarius module retries;
they are a separate behavior. Keep Narratio stage timeouts unchanged. Explain
the nested budgets and the changed semantics, not a guarantee of identical
provider cost or timing.
## Repository Ownership
- `ansible-role-dnd-pipeline`: suite defaults, argument specs, dependency wiring,
Audita profile assets, testing overlays, documentation, and integration tests.
- `ansible-collection-dnd`: imported pipeline snapshot, dependency manifest,
collection tests, and compatibility guidance.
- `rakestraw-ansible`: matching dependency pins and deployment guidance; adjust
host variables only where required. Preserve Vault content and unrelated
inventory. Keep the hosts-and-roles playbook minimal.
- Standalone role repositories: reviewed commits are reused/published, not
redesigned. Application and campaign/prompt repositories are read-only
contracts/assets unless a concrete incompatibility is raised for discussion.
- Workspace: roadmap, later staged plan, decisions, progress, and review.
## Constraints and Settled Decisions
Follow the [Ansible](../../ansible.md), [testing](../../testing.md), and
[planning](../../planning.md) policies, [MVP roadmap](../mvp.md), and
[upgrade sequence](../application-upgrade-sequence.md). New D&D policy remains
in the pipeline role; optional generic application defaults remain null.
## Simplest Viable Implementation
Update dependency variables/pins and existing templates, add an ordinary
Audita profile directory task and one looped template deployment, and change
testing destinations to `overlays/`. Reuse existing declarative convergence,
secret delivery, and collection assembly. No production validation, state
fingerprints, migration framework, or generated credential inference is needed.
## Acceptance Criteria
- Pipeline and collection installations produce a compatible set of the four
upgraded applications while Seriatim remains unchanged.
- Native offline inspection/validation accepts Audita settings and selected
profiles, Notarius base/testing configurations, Scriptorium configuration,
and Narratio base/testing composition with synthetic credential inputs.
Direct Audita validation receives credential environment variables explicitly:
it does not bootstrap Narratio's secrets directory on its own.
- Focused cases prove caller-supplied backend/profile configuration and
credential lists, testing selection, and existing important composition and
path handoffs. Assert supplied values, not fixed copies of today's defaults.
- Immediate repeated convergence is clean. Existing meaningful shared-user,
cache, artifact-composition, and installed-collection behavior remains covered
without expanding into upstream module/runtime regression matrices.
- Collection build/install and consumer syntax checks use the established
public dependency manifests. No sibling application/role checkout is needed
by an external consumer. Required referenced commits exist on public Gitea.
- Consumer inventory retains comments/Vault references for unknown secrets;
no actual keys or operational deployments are required for completion.
- Guidance covers breaking inventory fields, new CLI selectors, obsolete
testing-file locations, and upstream manifest migration. Back up and migrate
local provenance without deleting progress or editing immutable snapshots;
document normal named-selector invalidation rather than forcing reruns.
## Open Questions
None. The user approved deferring to application defaults wherever possible,
with nullable inventory overrides, and confirmed retaining the existing
900-second Audita per-attempt policy. Do not freeze native retry, repair, or
operation-deadline defaults in suite variables. Operators should note that an
attempt may consume the entire logical-operation budget; these are separate
controls, not additive timeout guarantees.
## Dependencies and Follow-up Work
Features 0018–0021 provide the reviewed standalone revisions. Implementation,
independent review, and remediation are complete. Git history preserves the
completed staged implementation plan. Actual deployment,
session migration, live processing, and a formal tagged release are separate
operator actions, not completion gates for this feature.
## Implementation Evidence and Review Handoff
On 2026-09-29, the four reviewed standalone role revisions were published to
their existing public Gitea `origin/main` branches and verified after fetch:
Scriptorium `b174c8c2990bb79f8149d8f288c5e06ccb42bd73`, Audita
`c3dd59f5ac9b942306ffe540ae9e71d493998137`, Notarius
`6aef48b7e12e3651971444b8c224d96ff1879e6c`, and Narratio
`3c0700b5323293d44e3b1e67a50074d82d7a3bff`.
The pipeline role at public revision
`ea8b09e190419586ede6df3815d1ea999a0f4391` passed `bash -n`, its full
`tests/integration` harness twice (configuration migration and representative
override coverage), and `git diff --check`. The collection imported that exact
public revision by subtree; public collection revision
`3d77eb382bcb4c1742015d3c32e23630bb8c73bf` passed `bash -n`, its full
artifact-based `tests/integration`, and `git diff --check`. Both harnesses used
synthetic credentials and offline native application validation, with clean
repeats. The consumer's local commit
`f694dad9426ee21138b175e44a3855d42be99d4b` passed public dependency
installation into disposable paths, real-inventory `--list-hosts` limited to
`pipeline-dnd`, `--syntax-check`, and `git diff --check`. Its commit was not
pushed. Seriatim and native collection pins remain unchanged, and manifests
across the three repositories agree.
The local integration harnesses converged only the development installation;
there was no operational deployment or live inference, transcription, or object
storage call. Vault values and target access were not needed or verified.
After the override harness passed, a formatting-only split of its fixture JSON
line was checked with `bash -n`, JSON parsing, and `git diff --check` without
rerunning the long integration harness. Independent review subsequently found
the three issues resolved below. No tagged release was created.
## Remediation Follow-up
The three independent-review findings are resolved; see
[remediation evidence](../remediation.md). Public pipeline `37b1cf6` and
collection `b3bc045` remove default-identity assertions and correct migration
and credential guidance. Local consumer `15f0f4e` selects the corrected public
snapshot. Shell/whitespace checks, pipeline and installed-collection syntax and
lint, collection build/install, and real-inventory consumer target/syntax checks
passed. Full host-mutating convergence was not rerun for these documentation
and test-only changes. Application versions/defaults and runtime behavior are
unchanged.
## Closeout
Closed on 2026-09-29 after independent review and resolution of all three
findings. This completes the agreed application upgrade sequence. The active
implementation plan is retired; no additional implementation is required for
this feature. Consumer commits remain local. Operational upgrade, session
migration, live production/testing checks, and any new tagged release require
separate operator action and were not performed as part of closeout.
## Upstream References
- [Audita v2 migration](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/migrations/v2.md)
- [Audita configuration](https://gitea.maximumdirect.net/eric/audita/src/tag/v2.0.1/docs/config.md)
- [Narratio v3 release](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/releases/v3.0.0.md)
- [Narratio operations and migration](https://gitea.maximumdirect.net/eric/narratio/src/tag/v3.0.0/docs/operations.md)
- [Notarius v0.8.0 migration](https://gitea.maximumdirect.net/eric/notarius/src/tag/v0.8.0/docs/releases/v0.8.0.md)
- [Scriptorium v0.14.0 migration](https://gitea.maximumdirect.net/eric/scriptorium/src/tag/v0.14.0/docs/releases/v0.14.0.md)

View File

@@ -1,12 +1,13 @@
# Implementation Plan
No implementation plan is currently active. Select and agree on the next unit
of work before replacing this notice with its staged plan.
No implementation plan is currently active.
Feature 0016 is complete. Its durable scope and completion evidence are in
[the feature roadmap](features/0016-deploy-dnd-pipeline-to-pipeline-dnd.md)
and [workspace status](../status.md). Git history preserves the completed plan.
[Feature 0022](features/0022-coordinated-suite-upgrade.md) was closed on
2026-09-29 after implementation, independent review, and resolution of all
three findings. Its roadmap and [remediation record](remediation.md) retain
the completion evidence; Git history preserves the completed staged plan.
Completion covers the committed deployment playbook, host configuration,
dependency manifest, and operator documentation—not deployment or runtime
acceptance on the operational host.
The [application upgrade sequence](application-upgrade-sequence.md) is complete.
Discuss and select the next unit of work before preparing a new feature
roadmap or staged implementation plan. Operational deployment and a new tagged
release are not authorized by this notice.

View File

@@ -1,147 +1,144 @@
# Feature 0013 Remediation Review
# Feature 0022 Remediation Review
Status: resolved
Reviewed implementation and release state:
Reviewed on 2026-09-29:
- Pipeline `8ea8621` and `ea8b09e`.
- Collection subtree import through `a78c309` and assembly `3d77eb3`.
- Consumer `f694dad`.
- Application-role `v0.1.0` tags at the five roadmap-fixed commits
- Pipeline release commit and tag
`7c2bad827702fdcf78f8f77ece7d6270756bc3c5`
- Collection subtree import
`da348eb8bd9878a58404a37dbcf22ad6562ac5c9`
- Collection release commit and tag
`63e8f3fb090a583226c7435bd900e10d41a30b89`
- Public `rakestraw.dnd 0.1.0` Gitea release and
`rakestraw-dnd-0.1.0.tar.gz` attachment
- Workspace implementation record through
`06e1b35f25589a3a6ff3fd2884208c86c4fee9c4`
The production wiring implements the approved coordinated versions, Audita
backend/profile assets, credential lists, overlay paths, and nullable retry
controls. The collection's imported pipeline tree exactly matches the source
role. The following test-policy and operator-documentation issues were found
and have now been addressed as recorded below.
Git history preserves the previously resolved Feature 0013 remediation record.
## Review Summary
## Finding 1: New assertions freeze unconfigured suite defaults
Feature 0013 implements the release architecture and public consumer path.
The five application-role tags identify the exact reviewed commits selected by
the roadmap. The standalone pipeline and collection manifests use those
immutable tags, and the native collection dependencies remain pinned to
`ansible.posix` 2.2.0 and `community.general` 13.3.0. The collection subtree's
Git tree exactly matches public pipeline tag `v0.1.0`.
Priority: P2
Owners: pipeline role and collection tests.
All seven repositories and tags are public and synchronized with their local
counterparts. The collection's non-draft, non-prerelease Gitea release carries
one correctly named archive. Its manifest declares `rakestraw.dnd` 0.1.0, the
expected Ansible baseline and collection dependencies, and its file payload
matches a fresh build from the tagged collection tree.
Locations:
- `ansible-role-dnd-pipeline/tests/integration:172`–173.
- `ansible-collection-dnd/tests/integration:104`–105 and 108–109.
One low-severity documentation issue remains. The pipeline README now implies
that collection snapshots may be imported only from role releases. That
strengthens the settled maintenance contract beyond the requested release
feature and contradicts the documented development workflow, which also
permits a reviewed, pushed commit.
The new baseline assertions require specific Audita profile IDs and Narratio
credential lists, but the cases do not explicitly supply the corresponding
selection/list variables. Supplying synthetic values in `dnd_pipeline_secrets`
does not select the credential lists. These assertions therefore fail when
legitimate defaults change, even if installation and caller overrides work.
## Finding 1: Pipeline Documentation Narrows Subtree Imports to Releases
Required correction: remove redundant default-identity assertions from the
baseline smoke case, or explicitly supply the relevant public inputs and
assert those values. The pipeline already has a useful custom-credential
override case; prefer reusing its coverage. Keep native validation and clean
repeats. Do not replace literals by reading role defaults into expectations;
that would still test implementation identity rather than caller behavior.
Severity: low
This strengthens acceptance beyond the user's state-based testing policy.
The approved plan explicitly asked for supplied-value tests, not default
snapshots.
`ansible-role-dnd-pipeline/README.md:51-53` says that collection maintainers
“import a reviewed release as a snapshot.” The same sentence is present in the
faithfully imported collection copy at
`ansible-collection-dnd/roles/pipeline/README.md:51-53`.
## Finding 2: Upgrade guidance confuses configuration with session migration
That wording accurately describes the particular snapshot used for collection
release 0.1.0, but it reads as the general maintenance rule. The durable
architecture deliberately permits the collection to import any reviewed
pipeline commit that has been pushed to Gitea during development. An immutable
pipeline tag is required only when preparing a released compatibility set.
The collection's own maintenance section correctly accepts a pushed commit or
immutable tag.
Priority: P2
Owners: pipeline README and consumer deployment guidance.
This is an inadvertent requirement strengthening: it could force an otherwise
unnecessary pipeline-role release merely to assemble and test a development
collection snapshot. It does not affect runtime behavior, the released
dependency pins, subtree fidelity, or consumer installation.
Locations:
- `ansible-role-dnd-pipeline/README.md:166`–168 and 337–338.
- `rakestraw-ansible/docs/pipeline-dnd.md:86`–104.
### Required Remediation
The pipeline links “Audita's v2 manifest migration” to Audita's configuration
migration guide, but does not identify Narratio's actual session-manifest
migration. The consumer likewise refers to “Audita manifests” and only
generically warns about Narratio manifests. The roadmap specifically requires
guidance on backing up and migrating local provenance while preserving
progress and immutable snapshots. Existing Narratio manifests containing
`effective_config.selected_profile` are rejected by v3.
- In the authoritative pipeline README, replace the release-only wording with
concise language saying that collection maintainers import a reviewed,
pushed commit or immutable tag as a snapshot.
- Make no role, manifest, default, task, template, handler, or test change.
- Commit and push the pipeline documentation correction before importing it
into the collection.
- Refresh `roles/pipeline` through the documented squashed subtree command
using the pushed pipeline documentation commit as the remote revision. Do
not edit the collection's subtree copy directly.
- Confirm that the resulting collection subtree Git tree exactly matches the
selected pushed pipeline commit outside Git metadata.
- Do not move or replace any `v0.1.0` tag, modify the published Gitea release,
or replace its attachment. Those immutable artifacts correctly describe the
historical 0.1.0 source state.
- Do not create a new role or collection release solely for this
maintainer-facing wording correction.
Required correction:
- Describe Audita's change as a configuration/backend/profile migration.
- Link Narratio v3's exact operations section
`#migrating-manifest-overlay-provenance`; briefly explain backup and
`effective_config.selected_profile` → `selected_overlay` (or removal as
upstream permits), preserving stage/checkpoint state and leaving immutable
remote snapshots unchanged. Do not add automatic migration or forced reruns.
- Correct or remove the stale claim that Notarius v0.8.1 selects PromptKit
v0.10.0. Its tagged release specifies v0.11.2; prefer linking upstream release
notes over duplicating dependency/catalog versions.
### Required Validation
This is a missing operator handoff, not a request for additional runtime code.
Run:
## Finding 3: Documentation makes managed secret files mandatory
```text
cd ansible-role-dnd-pipeline
git diff --check
Priority: P2
Owners: pipeline README and consumer deployment guidance.
cd ../ansible-collection-dnd
../.venv/bin/ansible-galaxy collection build --output-path "$(mktemp -d)"
git diff --check
```
Locations:
- `ansible-role-dnd-pipeline/README.md:160`–163.
- `rakestraw-ansible/docs/pipeline-dnd.md:69`–71.
Also compare the imported `roles/pipeline` tree with a disposable clone of the
selected pushed pipeline commit. The full application, pipeline, and
collection integration suites do not need to be rerun because the remediation
changes documentation only and preserves all Ansible and dependency content.
The new text requires each credential to be supplied through
`dnd_pipeline_secrets`. Runtime behavior does not require that: Narratio can
resolve listed names from its process environment or existing secret files.
The README's existing managed-credentials section already describes environment
precedence and an empty default secrets map.
## Resolution
Required correction: require the credential names in the forwarding lists,
but describe managed secret files as the suite-supported provisioning option,
not the only permitted source. Preserve the consumer's chosen Vault workflow
without imposing it on every standalone suite user. No code or new tests are
needed for this wording correction.
Resolved in pipeline commit `78afffe` and collection subtree import
`5e695f3`.
This is an unintended documentation-level strengthening of the requirements.
The authoritative pipeline README now states that collection maintainers may
import either a reviewed, pushed commit or an immutable tag. The pipeline
commit was pushed before the collection imported that exact Gitea revision
through the documented squashed subtree workflow. The imported subtree and
pipeline source have the same Git tree ID,
`37f619ac24d2303847c4b9ea60db1f9fc1bf9d0e`.
## Review Validation
A fresh collection build succeeded, and `git diff --check` passed in both
repositories. No Ansible content or dependency selection changed, so the
integration suites were not rerun. The seven `v0.1.0` tags, published
collection release, and release attachment remain unchanged.
Shell syntax, changed-commit whitespace checks, pipeline syntax checking with
locally available collections, production-profile lint, and collection build
passed. Source and imported pipeline Git tree hashes match exactly. Reviewed
the recorded successful role/collection integration and consumer syntax runs;
did not rerun host-mutating convergence. A fresh dependency installation stalled
and was stopped, so this review does not independently establish a complete
fresh public dependency installation. No operational host was contacted.
## Review Validation Evidence
## Remediation Boundaries
- Every local and remote `v0.1.0` tag resolves to the commit recorded in the
Feature 0013 roadmap and implementation notes.
- All seven Gitea repositories report public visibility and `main` as their
default branch.
- The pipeline `v0.1.0` tree ID and the collection tag's
`roles/pipeline` tree ID are both
`44a9d2b010012d8a63720b3a4ed07e9f255a5dae`.
- The tagged raw collection manifest matches the repository manifest, and its
role and collection selections match the released pipeline manifests.
- The public release API reports tag `v0.1.0`, title
`rakestraw.dnd 0.1.0`, `draft: false`, `prerelease: false`, and one
`rakestraw-dnd-0.1.0.tar.gz` attachment.
- The published archive has the same file list, `MANIFEST.json`, `FILES.json`,
and file payload hashes as a fresh collection build from the tagged tree.
It contains the pipeline entry point and omits the selected development-only
subtree files.
- A fresh unauthenticated clone and release-attachment download installed the
five public role tags and the collection into isolated Ansible paths. The
installed `rakestraw.dnd.pipeline` role converged successfully and its
immediate repeat reported `changed=0` and `failed=0`.
- The complete repository-local collection integration suite independently
passed isolated bootstrap, collection build and installation, syntax check,
production-profile lint, native application validation, and immediate clean
convergence.
- `git diff --check` passes for the pipeline, collection, and workspace
implementation ranges. All workspace repositories are clean and synchronized
with their upstream branches before this review finding is recorded.
Fix authoritative pipeline files first, then publish and re-import the corrected
pipeline revision through the existing public Gitea subtree workflow. Do not
edit its collection copy directly. Update collection-owned tests and consumer
pins/links to the corrected public snapshot as needed. Preserve all agreed
application versions, configuration defaults, and runtime behavior. Validate
affected tests in proportion to the changes; no operational deployment,
credentials, live inference, or session migration is required.
No runtime code-quality issue, release-architecture gap, test-policy violation,
or other inadvertent requirement strengthening was found.
## Resolution Evidence
All three findings were addressed on 2026-09-29:
- Finding 1: pipeline `37b1cf6` removes redundant baseline credential-list
assertions while preserving custom-input coverage; collection `d9abb62`
removes default profile-ID and credential-list assertions. Native profile
inspection, configuration validation, and immediate clean-repeat checks remain.
- Findings 2 and 3: pipeline `37b1cf6` and consumer `15f0f4e` distinguish
Audita configuration migration from Narratio session migration, link the
exact provenance procedure, preserve progress and immutable snapshots,
and allow environment or file-based credential provisioning. The stale
Notarius dependency/catalog claim is replaced by tagged release guidance.
- The public pipeline revision is
`37b1cf6fab71c6a1212e49357c2e825cb0237a00`; collection subtree import and
public revision `b3bc0457efb7ea14ed11789978edd440537860fc` contain its exact
Git tree. Both remote branch heads were independently checked with
`git ls-remote`. Consumer `15f0f4e` selects that collection and links the
corrected source README; the consumer commit remains local.
- Shell syntax and whitespace checks passed. Pipeline and installed-collection
syntax checks and production-profile lint passed. Collection build and
disposable artifact installation passed. Consumer real-inventory host
listing selected only `pipeline-dnd`, and syntax checking passed without
deployment or Vault decryption.
- Validation used the previously downloaded public role dependencies and
available local collections. Full host-mutating integration was not rerun:
production code/defaults are unchanged, test changes remove assertions and
unused parsing, and prior full-run evidence remains applicable to unchanged
behavior. No operational system or session state was modified.

View File

@@ -1,13 +1,19 @@
# Workspace Status
Last updated: 2026-09-21
Last updated: 2026-09-29
Current milestone: Operational D&D pipeline deployment
Current focus: Select the next unit of work. Feature 0016 repository preparation
is complete and independently reviewed with no remediation findings. The
subsequent Narratio v2.1.2 update is published and pinned by the consumer.
Deployment and session execution remain separate operator work.
Current focus: Feature 0022 is complete, including all three review
remediations. The application upgrade sequence is complete; no implementation
plan is active. The corrected pipeline and collection revisions are public;
the consumer commits remain local. No operational deployment or tagged release
was performed. Recommended next activity: a separately authorized operational
upgrade and production/testing smoke run, followed by a coordinated tagged
release if desired. Broader downgrade/removal policy remains unselected design
work, not a blocker to the completed features.
See the [upgrade sequence](roadmap/application-upgrade-sequence.md) and
[feature evidence](roadmap/features/0022-coordinated-suite-upgrade.md).
| ID | Deliverable | Owner | State | Evidence or next step |
| --- | --- | --- | --- | --- |
@@ -36,6 +42,12 @@ Deployment and session execution remain separate operator work.
| 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 | done | Pipeline `51566afcf69083cdbb5b5718f2544c86b079001c`, collection fixture `cf3de016ee09edf91afc3bc1addfd926d4a172ad`, collection squash `77f67adbc0f700e88bc15554e02052eaa22f1033`, and collection merge `46913446765e86ecfb29ebad9955d579ef6a4c7e` passed the complete repository suites and independent review with no remediation findings |
| F0016 | Prepare the D&D deployment playbook for `pipeline-dnd` | rakestraw-ansible and workspace | done | Consumer `716a80e`, `12b2462`, and `7f8353d` passed independent review with no findings; public dependency installation, target-only host listing, syntax and whitespace checks passed. Follow-up `7f4c90a` pins collection `2a53979` for Narratio v2.1.2; collection build and syntax checks passed |
| F0017 | Compose the Notarius testing overlay | Narratio role, pipeline role, collection, consumer, and workspace | done | Published through Narratio `330afe7`, Notarius `a82a83d`, pipeline `c56a942`, collection `ce5b838`, and consumer `0ced48c`; independent review found no remediation issues; validation evidence is in the feature roadmap |
| F0018 | Adopt Scriptorium v0.15.0 | Scriptorium role and workspace | done | Role commits `61dcafe`, `2fce529`, and `b174c8c` passed independent review with no findings; feature roadmap records validation; suite pins unchanged |
| F0019 | Adopt Audita v2.0.1 | Audita role and workspace | done | Role `c3dd59f`, following `6137ff2` and `52f67fe`, passed independent review with no findings; [roadmap](roadmap/features/0019-audita-v2-adoption.md) records validation; suite pins unchanged |
| F0020 | Adopt Notarius v0.8.1 | Notarius role and workspace | done | Role `6aef48b`, following `b1b922c` and `380b6a3`, passed independent review with no findings; [feature roadmap](roadmap/features/0020-notarius-v0-8-adoption.md) records evidence; suite pins unchanged |
| F0021 | Adopt Narratio v3.0.0 | Narratio role and workspace | done | Role `3c0700b`, following `a28f22c` and `45f6836`, passed independent review with no findings; [feature roadmap](roadmap/features/0021-narratio-v3-adoption.md) records evidence; suite pins unchanged |
| F0022 | Integrate the reviewed application upgrades | Pipeline role, collection, consumer, and workspace | done | Closed after review and resolution of all three findings; public pipeline `37b1cf6`, public collection `b3bc045`, local consumer `15f0f4e`; [remediation evidence](roadmap/remediation.md) |
| 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 |