Revise the Seriatim plan and workspace conventions

docs/roadmap/implementation-template.md

@@ -23,6 +23,14 @@ for scope, rationale, target end state, and acceptance criteria.
 - Preserve unrelated and pre-existing changes.
 - Do not make unresolved product or architecture decisions during execution;
   stop and report the decision required.
+- Start from the feature roadmap's simplest viable implementation. Trust
+  module-provided idempotence, change detection, check-mode behavior, and
+  error handling rather than reproducing them with preliminary probes or
+  supplemental state.
+- Do not add a task merely for defensive completeness. Every probe, fact,
+  checksum, custom `changed_when`, shell or command invocation, sidecar state
+  file, staging layer, or abstraction must be required by an
+  acceptance criterion and must solve behavior that a direct module does not.
 - Run every stage's validation before committing it.
 - Commit each completed stage when it leaves the repository in a valid state,
   using the commit intent specified by that stage.
@@ -57,6 +65,8 @@ State the single outcome delivered by this stage.
 1. Describe concrete behavior to implement, including relevant files or
    components where known.
 2. State invariants, compatibility requirements, and explicit exclusions.
+3. Give the expected module-driven task flow. Call out every required use of
+   `command`, `shell`, state inspection, or manual change detection.
 
 ### Validation
 
@@ -91,6 +101,8 @@ and subsequent consecutive integers as needed.
 - Confirm every changed repository is clean and identify all resulting commit
   hashes.
 - Summarize deviations from this plan, unresolved findings, and deferred work.
+- Report any implementation complexity added beyond the planned task flow and
+  the acceptance criterion that required it.
 - Do not mark the feature `done`; implementation results require review first.
 
 ## Progress Notes