OLS-3558 Decouple execution success from symptom checks - #374
Conversation
Clarify that success means apply completed, inline verification is observational only, and delayed symptom clearance must not fail the execution step when a dedicated Verification phase owns outcome assessment. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Skipping CI for Draft Pull Request. |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Summary
successmeans required apply work completed, not that the symptom has cleared.verification.conditionOutcomeas observational only;Unchanged/Degradedmust not forcesuccess: false.Context
Refinement of OLS-3558: an execution run correctly patched a NetworkPolicy, then set
success: falsebecause frontend logs still showed timeouts (~3s later / stale log lines). The operator hard-fails onsuccess: false, so formal Verification never ran.This PR is prompt-only and intended for design review during refinement. Spec updates (success vs inline verification contract) and any analysis-prompt changes (symptom post-checks in the execution script) are follow-ups.
Test plan
spec.verificationstep)successmust not be driven by symptom lag.ai/spec(sandbox-execution.md/crd-api.md)conditionOutcome: Unchanged→ execution advances to VerificationMade with Cursor