Implement closed-loop workspace follow-ups

examples/AGENTS.md

@@ -21,6 +21,7 @@ Each TOML file in `workflows/` is a valid workflow loadable by the server. Keep
 
 - Add a new workflow example when a major new workflow type ships.
 - Prompts referenced by TOML files go in `workflows/prompts/`.
+- Freestyle architect prompts specify stage constraints, boundaries, and verification goals; they do not prescribe an exact resulting file list when the authoritative intent leaves implementation details open.
 - Do not add configs/plugins/stages stubs speculatively — populate when there is real content.
 
 ## Verification

examples/workflows/prompts/architect_freestyle.md

@@ -81,6 +81,10 @@ Emit a JSON object that validates against the `execution_plan` schema:
     decompose tasks here — task creation is out of scope for the plan.
 - Keep stages small and single-responsibility. Prefer more stages over large monolithic
   prompts.
+- Write stage prompts as constraints and verification goals, not a pre-scripted list of exact
+  resulting files or their full contents. State the responsibility, boundaries, existing APIs or
+  references to honor, acceptance checks, and what must not change; let the implementer inspect the
+  actual workspace and choose the smallest fitting file edits.
 - **Declare `touches` to fence a stage to its area.** When a stage's job belongs to one part of
   the tree (a frontend/client stage → `["frontend/**"]`; a stage that edits only the API layer →
   `["apps/server/**"]`), list those globs in `touches`. Every concrete path the stage `writes`