From 249087e943a06ce8823c341bb76f8440bbd096a4 Mon Sep 17 00:00:00 2001 From: steven_li Date: Fri, 22 May 2026 10:41:23 +0800 Subject: [PATCH] docs: clarify validation acceptance compatibility --- .../specs/2026-05-22-task-evidence-validation-design.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/superpowers/specs/2026-05-22-task-evidence-validation-design.md b/docs/superpowers/specs/2026-05-22-task-evidence-validation-design.md index 5bd54cc..4e762c9 100644 --- a/docs/superpowers/specs/2026-05-22-task-evidence-validation-design.md +++ b/docs/superpowers/specs/2026-05-22-task-evidence-validation-design.md @@ -54,7 +54,7 @@ recommended_revision_prompt: str - `status == "accepted"` -> `passed=True` - `status in {"rejected", "insufficient_evidence", "validator_error"}` -> `passed=False` -Task mode, retry, and status transition logic must branch on `status`. `accepted` remains `passed and score >= 0.75` for backward compatibility, but new code should not infer failure from `passed=False` alone. +Task mode, retry, and status transition logic must branch on `status`. New code treats `status == "accepted"` as the acceptance condition. Existing compatibility paths may continue to interpret acceptance as `passed and score >= 0.75` until they are migrated, but new logic should not derive status from `passed` or infer failure from `passed=False` alone. Rules: