tdd-workflow

# Go TDD Workflow Apply TDD end-to-end: write failing tests first, implement minimal code, refactor safely, and prove quality with coverage plus risk-path checks. ## Hard Rules - Start with tests, not implementation. - Preserve visible `Red -> Green -> Refactor` evidence in commands/output. - Keep test files co-located and named `<target>_test.go`. - Assertion strategy (adapt to project): - **If project uses testify**: `require` for fatal preconditions, `assert` for value checks. - **If project uses standard library only**: use `t.Fatalf` for fatal, `t.Errorf` for value checks; include got/want: `t.Errorf("Name = %q, want %q", got, want)`. - **If project uses go-cmp**: use `cmp.Diff` for deep struct comparison. - **Detection**: Check existing `_test.go` files for `"github.com/stretchr/testify"` imports. Follow project convention. - Prefer table-driven tests with `t.Run`. - Prefer real deps or lightweight fakes; avoid heavy mock chains by default. - Do not add speculative production code not required by failing tests. ## New Mandatory Gates ### 1) Defect Hypothesis Gate Before writing tests, list concrete defect hypotheses from target code: - boundary/index (`n-1`, `i+1`, last-item behavior) - error propagation/wrapping - mapping loss/data mismatch - concurrency/order/timing - idempotency/retry behavior Each hypothesis must map to at least one test case name. For detailed defect-hypothesis patterns and BAD/GOOD examples, cross-reference the **unit-test** skill:...