Revise the Seriatim plan and workspace conventions

docs/roadmap/mvp.md

@@ -50,17 +50,21 @@ role will manage the native configuration needed to connect to it.
 - Released roles build an explicitly selected application release tag.
   Development may override the selected revision with a branch or commit.
 - Source checkouts reside at `/usr/local/src/<app>` and are owned by `root`.
-- Roles build into a staging location, validate the result, and then install
-  the binary at `/usr/local/bin/<app>` with `root:root` ownership and mode
-  `0755`. A failed build must not replace a working installed binary.
+- Roles build and install the binary at `/usr/local/bin/<app>` with
+  `root:root` ownership and mode `0755`, using the application's native build
+  command and the simplest clear Ansible task flow.
 - Builds use the application repository's own build contract, including any
   application-specific version-injection linker flags. The common baseline is
   `GOWORK=off`, `GOTOOLCHAIN=local`, `CGO_ENABLED=0`, and `-trimpath`.
-- Build state must account for the checked-out commit, Go toolchain, and build
-  arguments so that roles rebuild when a relevant input changes rather than
-  relying only on the existence of the installed binary.
-- Each application role exposes variables for its repository, selected
-  version or revision, source directory, binary path, and build settings.
+- Roles normally rebuild when the Git task reports a changed checkout, the
+  binary is absent, or an application-level version or smoke check shows that
+  the installed binary is unsuitable. They do not maintain fingerprints,
+  checksums, or sidecar build-state files for the MVP.
+- Each application role exposes variables only for meaningful consumer
+  choices, normally including its repository, selected version or revision,
+  source directory, binary path, dependency management, and Go Snap channel.
+  Fixed details of the upstream build contract need not become public
+  variables.
 
 ### Go toolchain
 
@@ -131,6 +135,13 @@ application-role releases in one source repository.
 - Small amounts of repeated prerequisite or installation logic are acceptable
   during the MVP. A shared helper role or collection plugin should be
   introduced only if substantial, stable shared behavior emerges.
+- Ansible modules are trusted to implement their documented state transitions,
+  idempotence, and change detection. Roles do not add preliminary existence
+  checks, manual comparisons, or supplemental state around a module that
+  already owns the desired behavior.
+- State gathering is appropriate only when it controls behavior outside the
+  responsible module's contract, such as deciding whether an application
+  binary must be rebuilt.
 
 ### Dependency and release reproducibility
 
@@ -213,6 +224,12 @@ remain to be designed.
 - Deploying or managing WhisperX
 - Versioned Narratio prompt-library releases and pinning
 - A role-managed scheduler or persistent Narratio service
+- Cryptographic artifact verification, supply-chain hardening, and protection
+  against adversarial source or dependency infrastructure
+- Transactional binary replacement and preservation of the prior executable
+  after a local build failure
+- Compiler-identity fingerprints, binary checksums, sidecar build-state files,
+  and recovery from deliberately malformed or redirected managed paths
 
 ## Design Work Still Open