anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: TDD workflow Life is good ☯ #8174

New Issue
Open
opened 2026-02-16 18:09:20 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 18:09:20 -05:00
Owner
Copy Link
Copy Source

Originally created by @colltoaction on GitHub (Jan 31, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

I wrote down these instructions that help my agent and thought I would share them here. Maybe I can contribute them to the code somehow?

# Agentic TDD Protocol: Autonomous Red-Green-Refactor

This document defines the specialized Test-Driven Development (TDD) protocol for agentic AI workflows. It prioritizes tool-verifiable state changes, architectural purity, and atomic progress.

## Phase 0: Environment Discovery & Tool Sync
Before mutation, the agent must synchronize its internal model with the project's testing capabilities.
- **Action**: Locate test suites via `find` or `ls`. Identify execution scripts (e.g., `Makefile`, `test.sh`).
- **Goal**: Establish a baseline command for "Run All" and "Run Specific".

---

## Phase 1: RED (Failure Establishment)
Identify a specific, reproducible failure. Never proceed without a verified baseline.
- **Protocol**:
    1. Create a failing case or target feature.
    2. Run the specific test command.
    3. Capture and analyze the diff/error.
- **Success Condition**: The agent can explain *exactly* why the test is failing and what output is expected.

---

## Phase 2: GREEN (Minimal Functional Mutation)
Implement the simplest possible change to satisfy the test. Prioritize correctness over elegance at this stage.
- **Protocol**:
    1. Modify the target file(s).
    2. Use simple logic (even hardcoded values) to bridge the gap.
    3. Rerun the specific test.
- **Success Condition**: The test passes (✅). Do not worry about technical debt yet.

---

## Phase 3: REFACTOR (Structural Refinement)
Elevate the "Green" implementation to meet project standards and theoretical constraints.
1. **Generalize**: Replace hardcoded logic.
2. **Align**: Ensure the code follows the project's core patterns.
3. **Cleanup**: Remove redundant code, temporary logs, hacks.
- **Success Condition**: The specific test still passes, but the code is now "architecturally sound".

---

## Phase 4: VERIFY (Regression Guard)
Verify that the refinement did not introduce regressions elsewhere in the system.
- **Protocol**:
    1. Run the **full** test suite.
    2. Analyze any new failures.
    3. If regressions occur, revert to the last stable "Green" state and re-evaluate the refactor.
- **Success Condition**: Zero regressions; full suite status is known and tracked.

---

## Phase 5: ATOMIC COMMIT (State Finalization)
Finalize the work and update tracking artifacts.

1. Update project tracking.
2. Commit with a message specifying the transition: `feat: ...`.

- **Goal**: Maintain a repository state where every commit is functional and compliant with the "Baby Steps" philosophy.

---

## Macro Cycle: History & Debt Management
For large-scale shifts (e.g., purging history, global refactors):
1. **Identify**: Use `git rev-list` to find technical debt/junk.
2. **Purge**: Apply macro tools (`git filter-repo`) globally.
3. **Reset**: Update `.gitignore` to prevent re-introduction of debt.
4. **Resync**: Verify the current HEAD remains compliant.

Life is good ☯
Originally created by @colltoaction on GitHub (Jan 31, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request I wrote down these instructions that help my agent and thought I would share them here. Maybe I can contribute them to the code somehow? ```md # Agentic TDD Protocol: Autonomous Red-Green-Refactor This document defines the specialized Test-Driven Development (TDD) protocol for agentic AI workflows. It prioritizes tool-verifiable state changes, architectural purity, and atomic progress. ## Phase 0: Environment Discovery & Tool Sync Before mutation, the agent must synchronize its internal model with the project's testing capabilities. - **Action**: Locate test suites via `find` or `ls`. Identify execution scripts (e.g., `Makefile`, `test.sh`). - **Goal**: Establish a baseline command for "Run All" and "Run Specific". --- ## Phase 1: RED (Failure Establishment) Identify a specific, reproducible failure. Never proceed without a verified baseline. - **Protocol**: 1. Create a failing case or target feature. 2. Run the specific test command. 3. Capture and analyze the diff/error. - **Success Condition**: The agent can explain *exactly* why the test is failing and what output is expected. --- ## Phase 2: GREEN (Minimal Functional Mutation) Implement the simplest possible change to satisfy the test. Prioritize correctness over elegance at this stage. - **Protocol**: 1. Modify the target file(s). 2. Use simple logic (even hardcoded values) to bridge the gap. 3. Rerun the specific test. - **Success Condition**: The test passes (✅). Do not worry about technical debt yet. --- ## Phase 3: REFACTOR (Structural Refinement) Elevate the "Green" implementation to meet project standards and theoretical constraints. 1. **Generalize**: Replace hardcoded logic. 2. **Align**: Ensure the code follows the project's core patterns. 3. **Cleanup**: Remove redundant code, temporary logs, hacks. - **Success Condition**: The specific test still passes, but the code is now "architecturally sound". --- ## Phase 4: VERIFY (Regression Guard) Verify that the refinement did not introduce regressions elsewhere in the system. - **Protocol**: 1. Run the **full** test suite. 2. Analyze any new failures. 3. If regressions occur, revert to the last stable "Green" state and re-evaluate the refactor. - **Success Condition**: Zero regressions; full suite status is known and tracked. --- ## Phase 5: ATOMIC COMMIT (State Finalization) Finalize the work and update tracking artifacts. 1. Update project tracking. 2. Commit with a message specifying the transition: `feat: ...`. - **Goal**: Maintain a repository state where every commit is functional and compliant with the "Baby Steps" philosophy. --- ## Macro Cycle: History & Debt Management For large-scale shifts (e.g., purging history, global refactors): 1. **Identify**: Use `git rev-list` to find technical debt/junk. 2. **Purge**: Apply macro tools (`git filter-repo`) globally. 3. **Reset**: Update `.gitignore` to prevent re-introduction of debt. 4. **Resync**: Verify the current HEAD remains compliant. Life is good ☯ ```
yindo added the discussiondocs labels 2026-02-16 18:09:20 -05:00
yindo commented 2026-02-16 18:09:20 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 31, 2026):

This issue might be a duplicate of or related to existing discussion:

  • #10278: [FEATURE]: tasks - Discussion about task management abstractions and following Claude Code features

Feel free to ignore if this doesn't address your specific case. The TDD workflow protocol you've proposed is a comprehensive development methodology that could complement task management features.

@github-actions[bot] commented on GitHub (Jan 31, 2026): This issue might be a duplicate of or related to existing discussion: - #10278: [FEATURE]: tasks - Discussion about task management abstractions and following Claude Code features Feel free to ignore if this doesn't address your specific case. The TDD workflow protocol you've proposed is a comprehensive development methodology that could complement task management features.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion docs
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#8174
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?