feat(red-lines): add assertion verification and scope lock (v1.7.0)#12
Open
qozle wants to merge 1 commit intodanielmiessler:mainfrom
Open
feat(red-lines): add assertion verification and scope lock (v1.7.0)#12qozle wants to merge 1 commit intodanielmiessler:mainfrom
qozle wants to merge 1 commit intodanielmiessler:mainfrom
Conversation
Two behavioral failure patterns not covered by existing red lines: 1. Unverified factual assertions made during OBSERVE/PLAN/EXECUTE — market hours, licensing status, prices, deployment state — stated as fact without tool verification. "No rubber-stamp verification" only covers the VERIFY phase; this gap lets confident wrong claims slip through earlier. 2. Scope expansion during EXECUTE without user approval — research tasks that transition to building, bug fixes that add unrequested cleanup or convenience features. ISC Quality Gate enforces criteria completeness before BUILD but has no symmetric containment gate during execution. Adds two red lines after the v1.6.0 orphaned-PASS rule: - No unverified factual assertions - No scope expansion without approval Evidence: 51 failure captures, 78 algorithm reflections, 30-day window. Both patterns averaged 3.0–3.1/10 sentiment vs 5.1/10 overall. Closes danielmiessler#11
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #11
What
Adds two red lines to the existing enforcement section, versioned as v1.7.0 additions:
No unverified factual assertions — Before stating any current-state fact (prices, service status, API behavior, licensing, deployment state, UI contents), verify with a tool call first. If you can't verify, say so. This closes a gap where the existing "No rubber-stamp verification" red line covered VERIFY phase evidence but not confident factual claims made earlier in the run.
No scope expansion without approval — The ISC at end of PLAN is the complete work scope. Discovering adjacent work during EXECUTE (cleanup, bonus features, unrequested data pulls) requires asking before acting. Complements the ISC Quality Gate, which enforces completeness entering BUILD but provides no symmetric containment during execution.
Why these placement and wording choices
Both follow the same structure as the existing red lines (behavior described, violation defined, v-tagged). They sit after the v1.6.0 orphaned-PASS rule, which is the natural extension point as the most recently added enforcement.
"Explore X = find and report. Fix X = fix that specific thing." is intentionally concrete — vague rules don't change behavior.
Evidence
Derived from analysis of 51 failure captures and 78 algorithm reflections over a 30-day window. Both patterns produced avg sentiment 3.0–3.1/10 vs 5.1/10 overall — the two lowest-rated behavioral failure classes in the dataset. The unverified assertion pattern appeared in 7+ distinct incidents across multiple domains (market data, software licensing, infrastructure state).