@windyroad/architect 1.1.2-preview.1392 → 1.1.3-preview.1394
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/agents/agent.md
CHANGED
|
@@ -48,6 +48,8 @@ In pre-edit mode:
|
|
|
48
48
|
|
|
49
49
|
### Smallest design and verification
|
|
50
50
|
|
|
51
|
+
For a blocking design or verification finding, name the required behavior or invariant, its source, who enforces it, and the evidence from the reviewed artifact. A confirmed acceptance criterion, applicable policy or contract, or a demonstrated violation of an established trust boundary can ground a finding. Check whether the proposed mechanism and test are needed to enforce that requirement at this boundary. If a requirement or its ownership is unestablished, state the assumption as an advisory or a question. Keep a demonstrated violation blocking even if the suggested fix is only one option.
|
|
52
|
+
|
|
51
53
|
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.
|
|
52
54
|
|
|
53
55
|
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.
|
package/package.json
CHANGED
|
@@ -100,6 +100,8 @@ Build a self-contained prompt for the architect subagent that includes:
|
|
|
100
100
|
|
|
101
101
|
For an applied review, also request the simplest-design comparison and original-defect verification check. Ask which additions can be removed and whether the actual verification would pass with the original defect present. For a plan review, give the exact plan revision and ask the architect to sketch the simplest design that meets its acceptance criteria and constraints. In either mode, require the report to name the artifact it reviewed.
|
|
102
102
|
|
|
103
|
+
Ask the reviewer to ground each blocking design or verification finding in the applicable requirement, its source, the enforcement owner, and evidence from the artifact. Ask whether the suggested mechanism or test is needed at that boundary.
|
|
104
|
+
|
|
103
105
|
The architect permits implementation against documented proposals without prior ratification. It flags **[Premature Acceptance]** when acceptance lacks either final human ratification or successful actual production-use evidence. Apply this distinction to plans and edits alike; missing ratification alone does not block building.
|
|
104
106
|
|
|
105
107
|
### 5. Delegate to the architect agent
|
|
@@ -135,6 +137,8 @@ Present the full compliance report to the user. The architect subagent will repo
|
|
|
135
137
|
|
|
136
138
|
Return avoidable mechanisms and missed-defect verification to the author for revision and recheck the revised artifact. No new approval is needed to make those corrections within the reviewed scope and existing authority.
|
|
137
139
|
|
|
140
|
+
Keep conditional suggestions advisory until their premise is established. If a blocking verdict lacks grounding, ask the reviewer to clarify it before adding dependent work or treating the review as passed. Resolve evidenced violations within existing authority; a suggested fix does not itself establish a requirement.
|
|
141
|
+
|
|
138
142
|
If a substantive architecture decision or exception needs human direction, use the runtime's structured question mechanism to ask how the user wants to proceed:
|
|
139
143
|
- (a) Address the violations before continuing
|
|
140
144
|
- (b) Proceed with a documented exception
|