Document the completed Seriatim remediation

docs/roadmap/features/0001-seriatim-source-installation.md

@@ -1,6 +1,6 @@
 # Feature 0001: Seriatim Source Installation
 
-Status: ready
+Status: in_progress
 
 ## Summary
 
@@ -35,10 +35,9 @@ the current design from becoming an accidental suite-wide pattern.
   `/usr/local/src/seriatim`.
 - Build Seriatim using the fixed upstream release build contract and install
   it at `/usr/local/bin/seriatim`.
-- Rebuild when the source checkout changes, the binary is absent, or the
-  installed binary does not report the selected version.
+- Rebuild when the source checkout changes or the binary is absent.
 - Converge the installed binary to `root:root` ownership and mode `0755`.
-- Validate a newly built binary with `seriatim --version`.
+- Verify the installed version in repository-local integration tests.
 - Keep the role interface, README, metadata, and focused local tests consistent
   with the simplified behavior.
 - Remove obsolete build-state files and implementation machinery from the
@@ -52,9 +51,8 @@ the current design from becoming an accidental suite-wide pattern.
 - Installation or configuration of any other pipeline application.
 - Pipeline composition, campaign data, prompts, secrets, or scheduling.
 - Installation from prebuilt release artifacts or removal behavior.
-- Detecting rebuild needs from Go compiler patch changes, fixed build-command
-  changes, or manually altered binary contents that still report the selected
-  version.
+- Detecting rebuild needs from Go compiler changes, fixed build-command
+  changes, or out-of-band modification of an existing binary.
 - Build fingerprints, binary checksums, or persistent sidecar build state.
 - Transactional replacement that preserves a previous executable after a
   failed local build.
@@ -72,9 +70,8 @@ under a root-owned `/usr/local/src/seriatim`, and installs a native executable a
 `/usr/local/bin/seriatim`. The executable is owned by `root:root`, has mode
 `0755`, and reports `seriatim version v1.5.0`.
 
-An immediate second application makes no changes. A changed Git checkout, a
-missing binary, or a binary reporting another version causes one build. The
-following application is again unchanged.
+An immediate second application makes no changes. A changed Git checkout or a
+missing binary causes one build. The following application is again unchanged.
 
 The role trusts `apt`, `community.general.snap`, `file`, and `git` to provide
 their documented idempotence and change detection. It does not inspect state
@@ -101,25 +98,28 @@ already manage.
   `1.26/stable`.
 - `community.general` is an approved dependency and provides Snap management;
   its version is pinned in the role's collection requirements.
-- The build runs from the checked-out source using `/snap/bin/go`,
-  `GOWORK=off`, `GOTOOLCHAIN=local`, `CGO_ENABLED=0`, `-trimpath`, package
-  `./cmd/seriatim`, and the upstream linker flag that injects the selected
-  version into `internal/buildinfo.Version`.
+- The build runs from the checked-out source using `seriatim_go_binary`
+  (defaulting to `/snap/bin/go`) with `GOWORK=off`, `GOTOOLCHAIN=local`,
+  `CGO_ENABLED=0`, `-trimpath`, package `./cmd/seriatim`, and the upstream
+  linker flag that injects the selected version into
+  `internal/buildinfo.Version`.
 - The selected version is both the Git revision and the version injected into
   the executable. Supporting independent source and build identities is not an
   MVP requirement.
 - The public interface is limited to meaningful deployment choices:
   `seriatim_version`, `seriatim_repository_url`, `seriatim_source_dir`,
-  `seriatim_binary_path`, `seriatim_manage_build_dependencies`, and
-  `seriatim_go_snap_channel`.
-- Fixed executable paths, build flags, linker symbols, environment values, and
-  package paths are implementation details, not public variables.
+  `seriatim_binary_path`, `seriatim_manage_build_dependencies`,
+  `seriatim_go_snap_channel`, and `seriatim_go_binary`.
+- Build flags, linker symbols, environment values, and package paths are
+  implementation details, not public variables.
+- Tasks that install dependencies or manage root-owned application state use
+  task-level privilege escalation.
 - `docs/decisions/0001-minimal-module-driven-ansible.md` governs the role's
   implementation style.
 
 ## Simplest Viable Implementation
 
-The intended Seriatim implementation is approximately the following ten
+The intended Seriatim implementation is approximately the following eight
 ordinary tasks.
 
 1. Assert the supported distribution, release, and architecture.
@@ -132,19 +132,17 @@ ordinary tasks.
 5. Check out the selected source with `ansible.builtin.git` and register its
    normal changed result.
 6. Inspect whether the installed binary exists.
-7. Read its version when it exists, without reporting a change.
-8. Run the upstream Go build when the Git checkout changed, the binary is
-   absent, or its reported version differs from the selected version.
-9. Converge source ownership and the installed binary's ownership and mode
+7. Run the upstream Go build when the Git checkout changed or the binary is
+   absent.
+8. Converge source ownership and the installed binary's ownership and mode
    with one `ansible.builtin.file` loop.
-10. Validate the version after a build, without reporting a change.
 
-For this fixed set of three rebuild triggers, the build remains an ordinary
+For this fixed set of two rebuild triggers, the build remains an ordinary
 task with the conditions applied directly to its `when` expression. This keeps
 the complete decision visible at the action site and avoids deferred execution
-or a play-wide handler flush. Permission convergence and post-build validation
-then follow in their natural task order. Do not create an intermediate
-`seriatim_build_required` fact.
+or a play-wide handler flush. Permission convergence then follows in its
+natural task order. Do not create an intermediate `seriatim_build_required`
+fact.
 
 The implementation may combine or split a task when required for clear and
 correct Ansible, but it must not add preflight checks around idempotent modules
@@ -154,10 +152,10 @@ file unless a split materially improves navigation.
 ## Rationale and Alternatives
 
 This design uses the Git module's changed result as the natural signal that
-source changed. The installed application's version is the only additional
-state needed to decide whether a binary must be built. That preserves useful
-convergence without maintaining a second database of compiler and build
-inputs.
+source changed. A binary existence check is the only additional state needed
+to decide whether the imperative build command must run. That preserves useful
+convergence without adding unrequested drift detection or maintaining a second
+database of compiler and build inputs.
 
 Building directly to the configured binary path is intentionally simpler than
 staging, checksumming, and recording a transactional installation. A failed
@@ -176,16 +174,18 @@ failure mode is not an MVP requirement.
 - `/usr/local/bin/seriatim --version` reports
   `seriatim version v1.5.0`.
 - An immediate second role run reports no changes.
-- A missing binary or a binary reporting the wrong version causes one rebuild
-  followed by an unchanged run.
+- A missing binary causes one rebuild followed by an unchanged run.
 - A changed selected version causes the Git task and build task to change and
   then converges.
 - The implementation contains no build-input documents, fingerprints, binary
   checksums, sidecar build state, manual Git reset or clean commands, or
   preliminary checks for state already managed by `apt`, Snap, `file`, or
   `git`.
-- Public defaults and argument specifications contain only the six variables
+- Public defaults and argument specifications contain only the seven variables
   named in this roadmap.
+- A caller may disable dependency management and select an existing Go
+  executable with `seriatim_go_binary`.
+- Tasks requiring superuser access use task-level privilege escalation.
 - Syntax checking, ansible-lint, a focused local convergence test, and a clean
   repeated run pass.
 - Role documentation describes the actual concise behavior and does not claim