ansible-workspace-dnd/docs/roadmap/remediation.md

# Feature 0001 Remediation Review

Status: resolved

## Finding 1: Synchronize Implementation Progress Tracking

Severity: low

The two implementation stages are marked complete in
`docs/roadmap/implementation.md`, with commits `325a5c7` and `718030e`, but the
same document still has status `proposed` and says that no stages have been
executed. `docs/status.md` likewise still describes plan review as the current
focus and Feature 0001 as `ready` rather than reflecting the completed
implementation and pending review outcome.

### Required Remediation

- Update the implementation plan status and progress notes to agree with its
  two recorded stage completions.
- Update workspace status to reflect that implementation is complete and the
  feature is awaiting review acceptance.
- Preserve the prior remediation history in Git rather than carrying its
  superseded contents in the active remediation document.

### Validation

- The implementation plan's status, stage completion annotations, and progress
  notes describe one consistent state.
- Workspace status names implementation review as the current activity and
  uses the corresponding feature state.
- `git diff --check` passes.

## Finding 2: Remove Production Version Interrogation

Severity: medium

`ansible-role-seriatim/tasks/main.yml` runs the installed binary before a build
to detect unexpected version output and again after a build to validate the
result. Neither operation is part of the required production convergence
contract. The first adds unrequested drift detection, while the second turns a
role task into a test of the role's own build implementation.

### Required Remediation

- Remove the pre-build `--version` command and its registered result.
- Rebuild only when the Git checkout changed or the binary is absent.
- Retain the binary `ansible.builtin.stat`, because its result is independently
  needed to decide whether the imperative build must run.
- Remove the post-build `--version` command, its registered build result, and
  the associated lint suppression.
- Continue verifying the installed version in repository-local integration
  tests.

### Validation

- The role contains no production invocation of `seriatim --version`.
- The build task has exactly the two required triggers: changed checkout or
  absent binary.
- Missing-binary and changed-checkout integration cases each cause a build and
  then converge to an unchanged repeat.
- The integration suite verifies the built binary's exact version output.

## Finding 3: Complete the Declarative Dependency and Privilege Contract

Severity: medium

The build command hard-codes `/snap/bin/go`, which makes dependency opt-out
unnecessarily dependent on the Snap installation path. The Git package task
also refreshes the APT cache without a validity interval, and tasks that modify
system-owned paths or install system dependencies currently rely on privilege
escalation supplied by the calling play.

### Required Remediation

- Add `seriatim_go_binary`, defaulting to `/snap/bin/go`, to the public defaults
  and argument specification, and use it as the build command executable.
- Add `cache_valid_time: 3600` to the Git `ansible.builtin.apt` task.
- Set `become: true` directly on tasks that install dependencies or modify
  root-owned application state. Do not add privilege escalation to the
  platform assertion or binary inspection merely for uniformity.
- Update the README's variable table, dependency opt-out description, and
  privilege behavior to match the implemented contract.

### Validation

- Dependency opt-out can use a caller-supplied Go executable.
- The APT task retains declarative cache management without refreshing a valid
  cache.
- A play connecting as an ordinary sudo-capable user can apply the role without
  play-level `become: true`.
- Defaults, argument specifications, tasks, and README agree on the seven
  public variables.

## Finding 4: Align the Feature Record and Focused Tests

Severity: medium

The active feature roadmap and completed implementation plan still require
wrong-version drift detection, post-build validation as a production task, a
hard-coded Go executable, and a six-variable interface. The integration driver
also contains a wrong-version rebuild case that would preserve the superseded
contract.

### Required Remediation

- Revise the feature roadmap to record the two rebuild triggers, the
  seven-variable interface, and the approximately eight-task target flow.
- Annotate or revise the completed implementation plan so it does not remain an
  apparently authoritative description of the superseded target.
- Remove the wrong-version rebuild case from the integration driver.
- Retain focused coverage of default convergence and idempotence, a missing
  binary, binary metadata convergence without a build, a changed selected
  version, platform rejection, and final version output.
- Update the README to describe only the revised behavior.

### Validation

- Workspace roadmap, implementation record, role implementation, README, and
  integration suite describe the same final architecture.
- No active document claims that unexpected version output triggers a rebuild
  or that the production role validates a newly built executable by running
  it.
- `tests/integration`, `bash -n tests/integration`, and `git diff --check` pass.

## Resolution

All four findings were resolved in `ansible-role-seriatim` commit `fb8dc41` on
2026-09-08. The role now uses an eight-task flow with two rebuild triggers, a
caller-selectable Go executable, bounded APT cache refreshes, and task-level
privilege escalation. Production tasks do not execute the installed
application; repository-local verification retains the version assertion. The
active roadmap, implementation record, status, README, interface, and focused
tests describe the same architecture.

Validation completed successfully with `tests/integration`,
`bash -n tests/integration`, and `git diff --check` in both changed
repositories.