fix: scope RED to writable behavior

.agents/skills/sdlc/SKILL.md

@@ -20,8 +20,12 @@ Use this skill for implementation, bug-fix, refactor, testing, release, publish,
 5. If confidence is below 95% for the next slice, research more before coding. Ask the user only if the uncertainty stays material.
    Keep slices small enough that confidence stays high in practice. If confidence is not high, say why plainly and tighten the slice.
    Freeze one issue, a closed behavior allowlist, one risk lane, and explicit exclusions. Feature creep becomes a separate follow-up issue unless omitting it would make the active change unsafe or nonfunctional.
-6. TDD is mandatory: write the failing test first, run it red, implement the minimum fix, then run it green.
-   Harness-repair lane: when broken SDLC enforcement or test bootstrap prevents the RED step for its own repair, declare the failing observable and exact file allowlist before editing, make the smallest repair, then write and run the missing regression test immediately after. This exception is only for repairing the harness itself; focused proof, final broad proof, and completion review still apply.
+6. Choose honest evidence before editing. Use RED only when a RED mutation is writable.
+   - **EVAL it:** agent-facing guidance whose effect is observable in a real scenario.
+   - **Plain-assert it:** a mechanical contract such as a byte, key, version, heading, or forbidden stale marker.
+   - **Review it:** judgment-call prose whose correctness depends on meaning; cross-model review is the guard.
+   For executable behavior, any observable input/output or side-effect difference makes a RED mutation writable; the meaning exception applies only to prose judged by a reader.
+   Harness-repair lane: implement-first is allowed only when a named gate blocks the required RED or evidence act itself. A gate refusing implementation because RED is missing is working, not an entry ticket. A cross-model ruling must APPROVE that same act and scope before the edit. Focused proof, final broad proof, and completion review still apply.
 7. Run the narrowest relevant verification first, then the full required suite before shipping.
 8. Self-review the exact diff. Check for regressions, scope creep, stale docs, and dead code.
 9. For release or publish work, treat version bump, docs, tests, publish, and verification as one SDLC slice.

AGENTS.md

@@ -9,15 +9,16 @@
 6. Default meaningful agentic coding to Sol `high`; escalate only difficult or high-risk slices to `xhigh` when `high` leaves unresolved risk
 7. Max is a single-task reasoning escalation; Ultra is a subagent-backed parallel-work escalation. Most tasks do not need Max or Ultra, and neither is a default for this repo.
 8. If `GOALS.md` exists, treat it as the active-scope contract and keep `ROADMAP.md` as backlog/history
-9. Write failing test FIRST (TDD RED), then implement (TDD GREEN)
+9. Use RED only when a RED mutation is writable; otherwise choose an honest eval, mechanical assertion, or review gate
 10. ALL tests must pass before commit - no exceptions
 
-## TDD Workflow (MANDATORY)
-1. Write the test file FIRST - the test MUST FAIL initially
-2. Run the test - confirm it fails (RED)
-3. Write the minimum implementation to make the test pass
-4. Run the test - confirm it passes (GREEN)
-5. Only then: commit
+## Evidence Workflow (MANDATORY)
+1. **EVAL it** when agent-facing guidance has an observable scenario.
+2. **Plain-assert it** for a mechanical contract.
+3. **Review it** for judgment-call prose; cross-model review is the guard.
+4. For executable behavior, any observable input/output or side-effect difference makes a RED mutation writable; the meaning exception applies only to prose judged by a reader.
+5. Implement-first is allowed only when a named gate blocks the required RED or evidence act itself. A gate refusing implementation because RED is missing is working, not an entry ticket. A cross-model ruling must APPROVE that same act and scope before the edit.
+6. Only commit after the selected evidence is green.
 
 ## After Implementation
 1. Self-review: read back your changes, check for bugs

CODEX_ADAPTER_PLAN.md

@@ -139,23 +139,23 @@ BaseInfinity/codex-sdlc-wizard/
 
 ### AGENTS.md
 
-Translated from our SDLC wizard, adapted for Codex. Since we can't hard-block file edits, AGENTS.md carries the TDD enforcement:
+Translated from our SDLC wizard, adapted for Codex. Since we can't hard-block file edits, AGENTS.md carries the evidence policy:
 
 ```markdown
 # SDLC Enforcement
 
 ## Before Every Task
 1. Plan before coding — outline steps, state confidence (HIGH/MEDIUM/LOW)
 2. LOW confidence? Research more or ASK USER
-3. Write failing test FIRST (TDD RED), then implement (TDD GREEN)
+3. Choose the honest evidence lane: RED for writable behavior, EVAL for agent guidance, Plain-assert for mechanical contracts, or Review for judgment prose
 4. ALL tests must pass before commit — no exceptions
 
-## TDD Workflow (MANDATORY)
-1. Write the test file FIRST — the test MUST FAIL initially
-2. Run the test — confirm it fails (RED)
-3. Write the minimum implementation to make the test pass
-4. Run the test — confirm it passes (GREEN)
-5. Only then: commit
+## Evidence Workflow (MANDATORY)
+1. Use RED only when a RED mutation is writable; any executable observable input/output or side-effect makes it writable
+2. EVAL agent-facing guidance in a real scenario
+3. Plain-assert mechanical contracts
+4. Review judgment-call prose; the meaning exception applies only to prose
+5. Use implement-first only when a named gate blocks the required RED/evidence act, and require cross-model APPROVE for that same act and scope
 
 ## After Implementation
 1. Self-review: read back your changes, check for bugs
@@ -219,7 +219,7 @@ Keep concise — shorter = better model attention. Codex official limit is 32KiB
 cat << 'EOF'
 SDLC BASELINE:
 1. Plan before coding — state confidence level
-2. TDD: Write failing test FIRST, then implement
+2. Choose honest RED/eval/assert/review evidence before implementation
 3. ALL tests must pass before commit
 4. Self-review before presenting to user
 EOF
@@ -462,7 +462,7 @@ jobs:
 1. **Claude** writes this plan (DONE)
 2. **Codex** cross-reviews until CERTIFIED (DONE — 9/10, round 5)
 3. **Claude** creates the GitHub repo `BaseInfinity/codex-sdlc-wizard` (DONE)
-4. **Codex** implements from this plan (TDD: tests first, then code)
+4. **Codex** implements from this plan using the honest evidence lane for each change
 5. **Claude** reviews the implementation
 6. **User** verifies and ships
 

README.md

@@ -83,13 +83,13 @@ A good goal should include:
 - `$sdlc` as the mandatory delivery contract
 - any additional repo-local skills that are already installed and relevant
 - the 95% confidence rule, including stopping to research or hand back when confidence drops
-- RED/GREEN tests, focused checks, full tests/lint when code or config changed, and native review/self-review
+- honest RED/eval/assert/review evidence, focused checks, full tests/lint when code or config changed, and native review/self-review
 - a clean break requirement: docs updated, evidence recorded, and changes committed locally before claiming the active task is done
 
 Suggested manual `/goal` text:
 
 ```text
-Get as far as possible through GOALS.md in small, shippable slices. Follow $sdlc for every code/doc change and include any relevant repo-local skills already installed here. Keep confidence >=95%; if confidence drops, research or stop at a clean handoff point. Use RED/GREEN tests, focused checks, full tests/lint when code or config changed, and native review/self-review before shipping. Stop only at a clean break with evidence recorded and changes committed locally.
+Get as far as possible through GOALS.md in small, shippable slices. Follow $sdlc for every code/doc change and include any relevant repo-local skills already installed here. Keep confidence >=95%; if confidence drops, research or stop at a clean handoff point. Choose honest RED/eval/assert/review evidence, use focused checks, run full tests/lint when code or config changed, and complete native review/self-review before shipping. Stop only at a clean break with evidence recorded and changes committed locally.
 ```
 
 ## What This Repo Is
@@ -139,7 +139,7 @@ Skip the `mv` when the legacy path does not exist. If the backup destination alr
 You want Codex to follow engineering discipline automatically:
 
 - **Plan before coding** instead of jumping straight to edits
-- **Write tests first** and keep TDD visible in the repo contract
+- **Choose honest evidence first**: RED for writable behavior, evaluation for agent guidance, assertions for mechanical contracts, and review for judgment prose
 - **State confidence** so low-confidence work triggers research instead of guessing
 - **Self-review before presenting** using Codex-native review where appropriate
 - **Prove the work is shippable** with fresh test/review evidence before commit or push
@@ -593,7 +593,7 @@ CODEX_E2E=1 bash tests/test-e2e.sh
 |----------|----------------|
 | [AGENTS.md](AGENTS.md) | Repo contract for planning, confidence, TDD, review, and model profile policy |
 | [START-SDLC.md](START-SDLC.md) | Quick operator entrypoint for starting SDLC work in an installed repo |
-| [SDLC-LOOP.md](SDLC-LOOP.md) | Repeatable plan -> test -> implement -> review -> prove loop |
+| [SDLC-LOOP.md](SDLC-LOOP.md) | Repeatable plan -> evidence -> implement -> review -> prove loop |
 | [PROVE-IT.md](PROVE-IT.md) | Proof-stamp gate for commit/push and examples for explicit check commands |
 | `GOALS.md` | Optional active-scope contract for long-running work; generated with `setup --goals` |
 | [RELEASE.md](RELEASE.md) | Maintainer release checklist before semver tags and npm/GitHub release publish |

SDLC-LOOP.md

@@ -9,10 +9,10 @@ Codex does not have a native `/sdlc` command. This file is the honest replacemen
 2. Pick the reasoning level
    Default to `high` for meaningful agentic coding. Escalate the difficult slice to `xhigh` for security review, migrations, destructive operations, long-running research, or challenging coding where `high` leaves unresolved risk. Repo-local instructions may define a measured exception.
    Use Max as a single-task escalation only when `xhigh` is not enough. Use Ultra only for subagent-backed parallel work that divides cleanly. Most tasks do not need Max or Ultra.
-3. Red first
-   Write the failing test first when the task is code-shaped.
-   If the task is setup, auth, or environment repair, define the failing observable first instead of pretending it is unit-testable.
-   Harness-repair lane: when broken SDLC enforcement or test bootstrap prevents RED for its own repair, declare the failing observable and exact file allowlist, make the smallest repair, then write and run the missing regression test immediately after. This never waives final proof or review.
+3. Choose honest evidence first
+   Use RED only when a RED mutation is writable. **EVAL it** when agent-facing guidance has an observable scenario. **Plain-assert it** for a mechanical contract. **Review it** when judgment-call prose depends on meaning; cross-model review is the guard.
+   For executable behavior, any observable input/output or side-effect difference makes a RED mutation writable; the meaning exception applies only to prose judged by a reader.
+   Harness-repair lane: implement-first is allowed only when a named gate blocks the required RED or evidence act itself. A gate refusing implementation because RED is missing is working, not an entry ticket. A cross-model ruling must APPROVE that same act and scope before the edit. This never waives final proof or review.
 4. Green with the smallest change
    Make the narrowest change that can satisfy the red check.
 5. Prove it

TESTING.md

@@ -118,7 +118,8 @@ them.
    not.
 3. Self-review the diff. Do not claim a review passed that you did not run.
 
-Follow a failing observable first: write or identify the failing test, watch it
-go red, make the smallest change that turns it green. For setup, authentication,
-or environment repair work, the failing observable replaces an artificial unit
-test — see `SDLC-LOOP.md` and `PROVE-IT.md`.
+Use RED only when a RED mutation is writable. EVAL agent-facing guidance through
+an observable scenario, Plain-assert mechanical contracts, and use cross-model
+review for judgment-call prose. For executable behavior, any observable
+input/output or side-effect difference is writable; the meaning exception applies
+only to prose judged by a reader. See `SDLC-LOOP.md` and `PROVE-IT.md`.

skill-sources/sdlc/SKILL.template.md

@@ -58,17 +58,17 @@ Check:
 
 Before implementation, do a docs update for the relevant feature area when the code change affects behavior, assumptions, or operator workflow.
 
-### 2. TDD
+### 2. Evidence before implementation
 
-Prefer:
+Use RED only when a RED mutation is writable:
 
-1. red
-2. green
-3. prove-it
+- **EVAL it:** agent-facing guidance whose effect is observable in a real scenario.
+- **Plain-assert it:** a mechanical contract such as a byte, key, version, heading, or forbidden stale marker.
+- **Review it:** judgment-call prose whose correctness depends on meaning; cross-model review is the guard.
 
-If strict test-first is not realistic for the very first primitive or baseline slice, say so explicitly and get back to TDD as soon as the baseline exists.
+For executable behavior, any observable input/output or side-effect difference makes a RED mutation writable; the meaning exception applies only to prose judged by a reader.
 
-Harness-repair lane: when broken SDLC enforcement or test bootstrap prevents the RED step for its own repair, declare the failing observable and exact file allowlist before editing, make the smallest repair, then write and run the missing regression test immediately after. This is not a general test waiver; focused proof, final broad proof, and completion review still apply.
+Harness-repair lane: implement-first is allowed only when a named gate blocks the required RED or evidence act itself. A gate refusing implementation because RED is missing is working, not an entry ticket. A cross-model ruling must APPROVE that same act and scope before the edit. This is not a general test waiver; focused proof, final broad proof, and completion review still apply.
 
 ### 3. Prove-it
 

skill-sources/sdlc/agents/openai.yaml

@@ -2,5 +2,4 @@ version: 1
 interface:
   display_name: sdlc
   short_description: Full SDLC workflow for Codex with planning, TDD, prove-it, and self-review.
-  default_prompt: Apply the full SDLC workflow for this task. Read the repo-local contract, state task, scope, confidence, verification plan, then drive red, green, prove-it, and self-review.
-
+  default_prompt: Apply the full SDLC workflow for this task. Read the repo-local contract, state task, scope, confidence, and verification plan, choose an honest RED/eval/assert/review evidence lane, then drive the smallest change through prove-it and self-review.

templates/AGENTS.baseline.md

@@ -7,8 +7,9 @@ Read `TESTING.md` and `ARCHITECTURE.md` when present and relevant. If `GOALS.md`
 1. Plan before coding. State the task, scope, confidence, and verification gate.
    Freeze one issue, a closed behavior allowlist, one risk lane, and explicit exclusions. Feature creep becomes a separate follow-up issue unless omission would make the active change unsafe or nonfunctional.
 2. If confidence is not high, research more before editing and ask only when material uncertainty remains.
-3. Write a failing test first for code-shaped changes, then implement the minimum fix.
-   Harness-repair lane: if broken enforcement prevents RED for its own repair, declare the failing observable and exact file allowlist, make the smallest repair, then write and run the missing regression test immediately after. Final proof and review remain mandatory.
+3. Use RED only when a RED mutation is writable. **EVAL it** for observable agent guidance, **Plain-assert it** for a mechanical contract, and **Review it** for judgment-call prose; cross-model review is the guard.
+   For executable behavior, any observable input/output or side-effect difference makes a RED mutation writable; the meaning exception applies only to prose judged by a reader.
+   Harness-repair lane: implement-first is allowed only when a named gate blocks the required RED or evidence act itself. A gate refusing implementation because RED is missing is working, not an entry ticket. A cross-model ruling must APPROVE that same act and scope before the edit. Final proof and review remain mandatory.
 4. Run focused checks, the broader relevant suite, and a self-review before commit.
 5. Never claim completion without fresh proof.
 6. Author-review and commit coherent green slices. Freeze the cumulative candidate for one fresh broad proof and completion review.
@@ -34,8 +35,8 @@ Read `TESTING.md` and `ARCHITECTURE.md` when present and relevant. If `GOALS.md`
 
 ## TDD Workflow
 
-1. Write the failing test or failing observable.
-2. Run it and confirm RED.
+1. Choose the honest evidence lane: EVAL it, Plain-assert it, or Review it.
+2. When a RED mutation is writable, run it and confirm RED.
 3. Implement the smallest coherent change.
 4. Run the focused check and confirm GREEN.
 5. Run the full relevant proof and review the exact diff.

templates/AGENTS.md.tmpl

@@ -33,9 +33,10 @@ Use skills for the visible workflow contract, let hooks enforce silently, and ke
    - LOW (<60%): Not sure — do more research or ASK the user before proceeding
    - Always state confidence on meaningful work, and keep slices small enough that confidence stays high in practice
    - Freeze one issue, a closed behavior allowlist, one risk lane, and explicit exclusions. Feature creep becomes a separate follow-up issue unless omission would make the active change unsafe or nonfunctional.
-2. **TDD Red:** Write a failing test FIRST that proves the feature/fix is needed
-3. **TDD Green:** Implement the minimum code to make the test pass
-   - Harness-repair lane: if broken enforcement prevents RED for its own repair, declare the failing observable and exact file allowlist, make the smallest repair, then write and run the missing regression test immediately after. This does not waive final proof or review.
+2. **Honest evidence:** Use RED only when a RED mutation is writable. **EVAL it** for observable agent guidance, **Plain-assert it** for a mechanical contract, and **Review it** for judgment-call prose; cross-model review is the guard.
+   - For executable behavior, any observable input/output or side-effect difference makes a RED mutation writable; the meaning exception applies only to prose judged by a reader.
+3. **Minimum change:** Implement only what the selected evidence requires.
+   - Harness-repair lane: implement-first is allowed only when a named gate blocks the required RED or evidence act itself. A gate refusing implementation because RED is missing is working, not an entry ticket. A cross-model ruling must APPROVE that same act and scope before the edit. This does not waive final proof or review.
 4. **Verify incrementally:** run focused proof for each coherent green slice; run the full required proof on the frozen completion candidate
 5. **Active goals:** When `GOALS.md` exists, complete that active scope before claiming the run is done; do not confuse active goal completion with roadmap completion.
 6. **Review to a decision:** author-review each incremental diff, then review the stable cumulative candidate once. Severity ladder: P0 stops the line; P1 blocks completion; P2 is a bounded fix or follow-up issue; P3 never blocks. When two reviewers are required, they exchange compact findings once. Allow at most two corrective rounds; unresolved P0/P1 requires decomposition, abandonment, or escalation.
@@ -121,7 +122,7 @@ After implementation, BEFORE presenting to the user:
 - Don't add features beyond what was asked
 - Delete dead code — no legacy fallbacks, no commented-out blocks
 - Test code is production code — same quality standards
-- Every bug fix starts with a failing test that reproduces the bug
+- Every executable bug fix starts with a writable failing observable; prose claims use the honest evidence lane above
 - If you fail twice on the same problem, STOP and ask the user
 
 ## Feedback and Repo Focus