feat: update architect guidance to require user confirmation for out-of-scope decisions

- Treat scope cuts and deferrals as proposals needing user confirmation
- Clarify that out-of-scope decisions must not be finalized without user agreement

Author: stiwicourage

.github/agents/architect.agent.md

@@ -13,6 +13,7 @@ release automation.
 - Identify the affected public surface, internal helper domains, tests, docs, and workflows.
 - Keep the change aligned with the repo's layering and ArchitectureGuardrails expectations.
 - Recommend the smallest structure that solves the problem cleanly.
+- Treat scope cuts, deferrals, and out-of-scope boundaries as proposals that require explicit user confirmation.
 - Once the discussion is sufficiently scoped, produce an issue-ready change design with acceptance criteria,
   out-of-scope boundaries, and a GitHub issue draft.
 
@@ -43,6 +44,7 @@ release automation.
 - Do not edit repository files unless the user explicitly asks to move from design into implementation.
 - Do not finalize the full design package until the user says the discussion is done, or you explicitly ask whether you
   should finalize it now.
+- Do not finalize out-of-scope decisions unless the user has explicitly confirmed them.
 
 ## Definition of done
 
@@ -59,3 +61,5 @@ release automation.
 - Must not create or edit repository files when the task is still in design mode.
 - Must not return a full implementation plan or finished issue draft in the first reply when the user is clearly asking
   for a design discussion.
+- Must not decide on its own that requested work is out of scope and then finalize the design without the user's
+  confirmation.

.github/instructions/repository-instructions.md

@@ -20,7 +20,8 @@ Read these files before making non-trivial changes:
 For new or not-yet-scoped work, start with `.github/agents/architect.agent.md` and
 `.github/prompts/design-change.prompt.md`. That flow should stay conversational first: analyze the request, ask
 clarifying questions, present design options when needed, and only draft the final scoped solution or GitHub issue after
-the discussion is complete.
+the discussion is complete. Proposed scope cuts or out-of-scope boundaries must be confirmed by the user before they are
+treated as final.
 
 ## Repository map
 

.github/prompts/design-change.prompt.md

@@ -6,6 +6,9 @@ starts editing files.
 This is a discussion-first prompt. The default behavior is to hold a short design conversation with the user before
 producing a final scoped solution, implementation handoff, or GitHub issue draft.
 
+Scope is not final until the user confirms it. That includes anything you think should be treated as out of scope,
+deferred, split into follow-up work, or excluded from the first implementation pass.
+
 ## Required inputs
 
 - The requested change, problem statement, or rough idea
@@ -23,11 +26,14 @@ producing a final scoped solution, implementation handoff, or GitHub issue draft
    help, website docs, `CHANGELOG.md`, or `RELEASE_NOTE.md`.
 5. Present the user with the clearest trade-offs, options, or design directions when more than one reasonable path
    exists.
-6. Keep the conversation interactive until the user says the task is clear enough to finalize, or until you explicitly
-   ask whether you should now draft the final design and GitHub issue.
-7. Only after that discussion is complete, produce the final scoped solution, implementation handoff, and GitHub issue
+6. When you believe part of the request should be out of scope, present that as a proposal and ask the user to confirm
+   or reject it. Do not silently narrow the task.
+7. Keep the conversation interactive until the user explicitly confirms the scope is correct and says the task is clear
+   enough to finalize, or until you explicitly ask whether you should now draft the final design and GitHub issue and
+   the user agrees.
+8. Only after that discussion is complete, produce the final scoped solution, implementation handoff, and GitHub issue
    draft.
-8. Do not edit repository files unless the user explicitly switches from design to implementation.
+9. Do not edit repository files unless the user explicitly switches from design to implementation.
 
 ## Discussion-phase output
 
@@ -38,12 +44,14 @@ Use the first response and follow-up design turns to drive a conversation, not t
 - 2-3 concrete solution directions when choices exist
 - clear trade-offs
 - a recommendation when one option is strongest
+- proposed scope and out-of-scope boundaries clearly marked as proposals until the user confirms them
 
 Do not produce the full final design package in the first response unless the user explicitly asks for it.
+Do not convert your own proposed scope boundaries into final decisions without the user's confirmation.
 
 ## Finalization output
 
-Once the user says the discussion is done, or explicitly asks for the final design, return:
+Once the user confirms the scope and says the discussion is done, or explicitly asks for the final design, return:
 
 - Problem
 - Why it matters
@@ -65,3 +73,6 @@ Once the user says the discussion is done, or explicitly asks for the final desi
 - Draft issue text in English unless the user explicitly asks for another language.
 - If the task still has unresolved choices, end the turn with the next best question or the next design decision the
   user should make.
+- If you think some requested work should be deferred or excluded, ask for confirmation before turning that judgment
+  into
+  the final scope or issue draft.

CHANGELOG.md

@@ -17,6 +17,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   - Adds a discussion-first architect flow so `architect.agent.md` together with `design-change.prompt.md` now keeps
     the early phase conversational, asks clarifying questions, presents design directions, and only finalizes the
     scoped solution and GitHub issue draft after the discussion is complete.
+  - Requires architect/design flows to treat out-of-scope cuts and deferred work as proposals that must be confirmed by
+    the user before they become part of the final scope or issue draft.
     - Includes branch-aware Conventional Commit guidance that derives ticket references from `$GIT_BRANCH_NAME` and
       keeps
       commit suggestions concise and English-only.

CONTRIBUTING.md

@@ -44,7 +44,8 @@ Repository-local agentic guidance now lives in `.github/`:
 
 When you are shaping a new change, start with `architect.agent.md` and `design-change.prompt.md` so the first phase is a
 design conversation: analysis, clarifying questions, and solution options before any final scoped proposal or GitHub
-issue draft is produced. Use `implement-issue.prompt.md` after the change is already scoped.
+issue draft is produced. Proposed out-of-scope boundaries should be confirmed by the user before they become part of the
+final scope. Use `implement-issue.prompt.md` after the change is already scoped.
 
 Pull requests against `main` and `develop` also run a CodeScene coverage-gate check when CI has produced the Cobertura coverage artifact, so PRs can be blocked when changed code falls below the configured coverage threshold.
 

README.md

@@ -65,6 +65,8 @@ Repository-local Copilot/AI guidance now lives under:
 For new or still-fuzzy work, start with `architect.agent.md` together with `design-change.prompt.md`. That pair should
 lead with discussion, questions, and design options rather than a finished solution in the first reply. Use
 `implement-issue.prompt.md` once the scope, acceptance criteria, and follow-on implementation path are already clear.
+If architect proposes that part of the request is out of scope, treat that as a proposal to confirm rather than a final
+decision.
 
 ### Prerequisites