Early gate placement: where does test-lint run relative to red-assert? #311
Labels
No labels
P0
P1
P2
P3
bug
create
delete
enhancement
filed-by/agent
filed-by/user
frozen
lint-rule
needs-info
needs-triage
next
plugin/cc-architect
plugin/os
plugin/os-adr
plugin/os-aidd-lint
plugin/os-backlog
plugin/os-context
plugin/os-doc-hygiene
plugin/os-sdlc
plugin/os-vault
project/cc-os
ready-for-agent
ready-for-human
recurring
review
update
waiting
wayfinder:grilling
wayfinder:map
wayfinder:map
wayfinder:research
wayfinder:task
wayfinder:task
wontfix
worklist/deviations
worklist/lint-rule
worklist/new-implement-build
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
jared/cc-os#311
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Question
The new test-lint step runs after test-writer and before the programmer — but where exactly relative to red-assert and disclosure rows? Sub-questions: does rubocop autocorrect run on the test files at this gate (cheap, deterministic) before dispatching test-lint-fixer? Is the gate conditional (skipped entirely when rubocop is clean)? And after test-lint-fixer edits tests, must red-assert run (or re-run) to re-verify the tests still fail for the right reason?
Map: #310
Resolution (2026-08-07)
Gate order — red-assert brackets the gate. Pipeline becomes: write-failing-tests → disclose-test-writer → red-assert → [early test-lint gate] → conditional red-assert re-run → shard-plan. The first red-assert proves test-writer's output fails for the right reasons; the re-run (only when test-lint-fixer actually edited) proves the fixer preserved that. Unambiguous attribution between test-writer bugs and fixer-introduced breakage; extra test run only on the dirty path. Mirrors green-assert's re-verify-after-lint-fix pattern.
Gate scope — only files test-writer touched this run. Pre-existing offenses in untouched test files (like the 1 in #261) are left to the late gate (#313). Keeps the gate fast and blame-local.
Autocorrect — yes, safe autocorrect (rubocop -a) runs first, scoped to the same files, before any fixer dispatch; residual offenses fan out to test-lint-fixer. Mirrors the late gate's autocorrect → residual-fanout shape.
Conditionality — free by construction: clean rubocop → no fixer dispatch → no red-assert re-run; the gate adds zero cost on the clean path.