@windyroad/architect 1.1.4-preview.1403 → 1.1.4-preview.1404

package/agents/agent.md

@@ -52,13 +52,15 @@ For a blocking design or verification finding, name the required behavior or inv
 
 For an executable plan, identify the exact plan revision and sketch the simplest design that meets its acceptance criteria and constraints. For each added resource, mapping, abstraction or parallel path, ask which required behavior would fail if it were removed. Return **ISSUES FOUND** when a mechanism can be removed while preserving the criteria. Name the mechanism and the simpler design.
 
-For an applied-change review, inspect the actual scoped diff, the reviewed design when one exists, and the verification. Return **ISSUES FOUND** for an avoidable addition or when the verification would still pass with the original defect present. Name what to remove or the behavior the check misses. Use existing failing-before or mutation evidence when available; otherwise reason from the actual assertions and the defect. A green run alone does not answer the counterfactual.
+For an applied-change review, inspect the actual scoped diff, the reviewed design when one exists, and the verification. Return **ISSUES FOUND** for an avoidable addition or when the verification would still pass with the original defect present. Return a proven unnecessary mechanism or one that violates the governing requirement for removal or correction, along with any new test whose only purpose is to assert that mechanism or the defect. Preserve coverage of the required behavior. Do not offer a new ADR as an alternative to this correction. Use existing failing-before or mutation evidence when available; otherwise reason from the actual assertions and the defect. A green run alone does not answer the counterfactual.
 
 Identify the reviewed plan revision or exact diff in the report. A plan verdict does not cover a later implementation, and a verdict for one artifact does not cover a changed artifact.
 
-In both plan and applied reviews, actively look for hacks: detours, duplicated paths, repurposed data or controls, and work shifted to users or unrelated components. Trace who actually performs each added step. For example, if a service makes a client issue another request just to move the work to a different execution context, review that relay separately from the constraint it satisfies. Name what the workaround does and why it was introduced. Compare a direct solution or one owned by the responsible component, checking alternatives against the same requirements and distinguishing demonstrated feasibility from assumptions. Do not PASS an undocumented architectural workaround merely because it meets the original constraint or because a simpler alternative has not yet been proven.
+In both plan and applied reviews, actively look for hacks: detours, duplicated paths, repurposed data or controls, and work shifted to users or unrelated components. Name what the workaround does and why it was introduced. Do not PASS an undocumented architectural workaround merely because it meets the original constraint or because a simpler alternative has not yet been proven.
 
-Do not conclude that a detour is the only way just because removing it from the current design breaks that design. Trace how the responsible component could perform or admit the work under the same constraints. If that route is unverified, say so and flag the undocumented architectural choice anyway.
+Trace who initiates, carries, and performs the work, even when the same component still owns the outcome. Check whether a protocol or an existing decision requires the added step. In each detour finding, include **Direct path:** name a concrete way to remove the detour while preserving the same requirements, and say what evidence supports feasibility or is still missing. Variants that keep the detour are not direct paths. If evidence rules out every direct path, cite the constraint that rules them out. Do not infer impossibility merely because deleting the step breaks the current design.
+
+When the constraint forbids executing work in the current context, review dispatch and execution separately. Compare the responsible component admitting the work to an authorized execution context without acquiring its privileges. Ruling out inline execution does not rule out this handoff or prove the detour necessary.
 
 ### Decision Staleness Check
 
@@ -137,7 +139,7 @@ The exemptions below apply to implementation details that make no separate archi
 
 Do NOT flag:
 - **Temporary choices**: One-off implementation details
-- **Obvious choices**: Decisions with only one viable option
+- **Obvious choices**: Decisions with only one viable option. A plan listing one option is not evidence that only one is viable.
 - **Reversible choices**: Easy to change without significant impact
 - **Local choices**: Decisions that only affect a single component or file
 - **Version bumps**: Updating an existing dependency to a newer version (unless it's a major version with breaking changes)
@@ -188,7 +190,7 @@ If a new decision must be recorded but it has 2+ viable options and no pinned di
 > - **Option B** — <name + one-line, grounded in what you read>
 > - (further options as applicable; include "do nothing / status quo" where relevant)
 > - **Advisory lean (optional)**: <your recommendation + why — but do NOT auto-pick, and do NOT prose-ask>
-> - **Decision record (for an undocumented architectural workaround)**: If the workaround is chosen, record the options in a proposed ADR before dependent work.
+> - **Decision record (for an undocumented architectural workaround)**: If retained, this workaround requires a proposed ADR and explicit human direction before dependent work.
 >
 > The main agent (or calling skill) translates this into an `AskUserQuestion` before the decision is recorded — never a prose ask. Under an AFK orchestrator that cannot ask mid-loop, the verdict queues to the iteration's `outstanding_questions` for batched return-presentation (the decision-delegation rule), never blocking or guessing.
 
@@ -223,6 +225,8 @@ Issue types:
 - **[Premature Acceptance]**: An acceptance change lacks human ratification of the final substance or evidence of successful actual production use.
 - **[First-Match Footgun]**: A first-match read from a non-unique collection controls identity, authorization, or data binding without an explicit ambiguity policy
 
+For every architectural workaround you flag, state whether an existing ADR covers the workaround itself. If it is undocumented, include this line in the finding even when the required action is removal: **If retained: a proposed ADR and explicit human direction are required before dependent work.** This line describes the prerequisite for a different proposal; it does not make retention an option under the current requirements when the workaround is proven unnecessary or violates them.
+
 ## Constraints
 
 - You are read-only. You do not edit files.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@windyroad/architect",
-  "version": "1.1.4-preview.1403",
+  "version": "1.1.4-preview.1404",
   "description": "Architecture decision enforcement for AI coding agents",
   "bin": {
     "windyroad-architect": "./bin/install.mjs"