Read which precondition a disabled control names

CHANGELOG.md

@@ -2,6 +2,15 @@
 
 ## 2026-09-15
 
+### Fixes
+
+- [Pilot] A control the page has disabled is no longer read as one missing required field. Pilot had a
+  single explanation for a disabled control, so it attributed the block to whichever field the scenario
+  happened to be about and steered the whole test at that field — hunting validation feedback that the
+  app never had a reason to show. It now identifies which precondition is unmet from what the page
+  states: other disabled controls name the unsatisfied constraint, and the form marks its required
+  fields. Where the page names a constraint the scenario did not predict, Pilot reports the difference
+  instead of testing a premise the app contradicts.
 ### Changes
 
 - [Pilot] A test that stops part-way through a multi-step flow is no longer failed outright when the

src/ai/pilot.ts

@@ -1127,7 +1127,9 @@ export class Pilot implements Agent {
       ${interactive ? '- Use askUser() only as last resort.' : ''}
 
       Diagnostic patterns (use <state>, executed/element/skipped fields, ariaDiff):
-      - Click failed + button in "disabled buttons" → required field missing. Instruct fill first.
+      - Scenario's target control in "disabled buttons" → a precondition is unmet; identify which before acting.
+        Other disabled controls often name the unsatisfied constraint; "active form" marks [required] fields.
+        Aim Tester at the constraint the page names, not the one the scenario assumed — note the difference in PROGRESS.
       - "overlay: none" but Tester targets an overlay → overlay closed; re-trigger.
       - "region:" in <state> → a large area appeared in place without navigation (subview, wizard step, panel). Direct Tester to act inside it; the rest of the page is still usable.
       - Action SUCCESS but ariaDiff empty → may have worked without visible DOM change; check result message.