@emiliosp/pi-maestro 0.4.3 → 0.4.4
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/package.json
CHANGED
|
@@ -86,6 +86,25 @@ The verifier tool commits verifier-running before launch. That checkpoint is the
|
|
|
86
86
|
The verifier restores all temporary product changes. Its handoff tool commits only workflow.json and handoffs/verifier.json.
|
|
87
87
|
Read the returned verifier handoff. If there are findings, follow findings-decision. If there are none, follow candidate-ready.
|
|
88
88
|
|
|
89
|
+
### Explain findings and escalations
|
|
90
|
+
|
|
91
|
+
Before requesting a decision, read the active spec, the finding or escalation artifact, and the relevant code.
|
|
92
|
+
Trace the affected behavior across components. Do not just repeat the builder's or verifier's summary.
|
|
93
|
+
For findings, inspect the verified candidate. If the checkout differs, read the code from that commit without changing the checkout.
|
|
94
|
+
This inspection does not authorize product repairs, new verification runs, or experiments. Follow the existing permissions above.
|
|
95
|
+
|
|
96
|
+
For each finding or escalation, give the owner enough detail to decide without opening other files:
|
|
97
|
+
|
|
98
|
+
1. Identify the item by its ID. Explain the issue or open question and its relation to the approved contract.
|
|
99
|
+
2. For code-related issues, show a short code excerpt with its file path and line numbers. Explain how that code causes or constrains the behavior. A file reference alone is not enough.
|
|
100
|
+
3. Give a concrete example with starting conditions, input or action, current behavior, and practical impact. Compare with the contract's expected result when defined. Otherwise identify the behavior that needs an owner decision.
|
|
101
|
+
4. Explain each available choice, its required changes, scope, consequences, and next workflow step. For findings, cover fix-code, rejection, and spec revision when relevant. Explain what remains unchanged or unresolved if no code changes.
|
|
102
|
+
|
|
103
|
+
Distinguish observed results from illustrative examples, assumptions, and unknowns. Never invent evidence, code, or expected behavior.
|
|
104
|
+
If evidence is missing, inspect what is available and state the limit before asking for a decision.
|
|
105
|
+
Give a recommendation only when evidence supports it. Explain the reason without choosing for the owner.
|
|
106
|
+
Keep excerpts and explanations focused, but do not replace the details with severity labels or vague summaries.
|
|
107
|
+
|
|
89
108
|
### Record owner decisions
|
|
90
109
|
|
|
91
110
|
In escalation-decision, wait for the explicit owner answer. Do not choose an option for the owner.
|