ed/manual_slop
Private
Public Access
0
0
Fork 0
Code Activity

feat(directives): harvest 10 process/workflow directives from AGENTS.md + workflow.md

Browse Source
This commit is contained in:
ed
2026-07-02 22:07:08 -04:00
parent 02320a13ea
commit 412494d205
10 changed files with 203 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
conductor/directives/batch_verification_not_isolation/v1.md
+14
View File
@@ -0,0 +1,14 @@
# batch_verification_not_isolation — v1
**Why this iteration:** Lifted verbatim from `conductor/workflow.md` §"Isolated-Pass Verification Fallacy (Added 2026-06-09)" (lines 510-514). This is the baseline encoding — the rationale-then-rule style currently in production.
Future variants will test alternative encodings (rule-only, before/after) against this baseline.
**Source:** `conductor/workflow.md:510-514`
---
### Isolated-Pass Verification Fallacy (Added 2026-06-09)
A test that "passes when run after test X but fails in isolation" is a **fragile test, not a fragile fixture**. The flip side is also true: a test that "passes in isolation but fails in batch" is failing — its failure is masked by isolation. The only verification that matters for `live_gui` tests (or any test that depends on shared subprocess state) is the **batch run** in the suite the test will ship in.
**Rule:** For any `live_gui` test or any test that depends on shared subprocess state, do NOT commit a fix that you have only verified in isolation. The fix must pass in the batched run that includes the tests that share the subprocess. Run the batch first. If the test fails in batch, your fix is incomplete. Per the existing `Live_gui Test Fragility (Authoring-Side)` rule above, the bisect requires both directions. If you only run in isolation, you cannot tell "test needs work" from "real app bug."