3.8 KiB
issue, issue_title
| issue | issue_title |
|---|---|
| 21 | Split src/index.ts (1,983 lines) into focused modules |
Retro: #21 — Split src/index.ts (1,983 lines) into focused modules
Final Retrospective (2026-05-03)
Session summary
Phase 1 (module extraction) had been completed in a prior session.
This session executed Phase 2: adding 12 unit test files covering every extracted and pre-existing focused module using vi.mock() + vi.fn() dependency injection.
The suite grew from 119 → 406 tests across 7 → 19 files, and testing uncovered one pre-existing bug (sanitizeAvailableToolsSection) that was documented with test.fails and filed as #33.
Observations
What went well
-
test.fails+ issue pattern on first use. WhensanitizeAvailableToolsSectionsilently destroyed prompt content after the last recognised section header, the test was left asserting expected behavior and markedtest.fails, with a detailed reproducer filed as #33. The suite stayed green, the bug is documented, and the fix has a clear home. Clean execution of a pattern not previously inAGENTS.md. -
tsccatching what esbuild missed.npm run buildsurfaced aRecord<string, string>vsRecord<string, PermissionState>mismatch in thebash-filtermock parameter type that all 406 Vitest tests passed through silently. The existing "runnpm run build" rule proved its value in practice.
What caused friction (agent side)
-
missing-context—vi.clearAllMocks()gap. The plan's own exampleafterEachshowed onlyvi.restoreAllMocks(), which is insufficient forvi.mock()factories: call counts bleed across tests. Thebash-filtertest wrote a "pre-compiled list should not callcompileWildcardPatterns" assertion that failed because of accumulated call counts from earlier tests. Fix required: addvi.clearAllMocks()beforevi.restoreAllMocks(). Impact: one failing test, one diagnosis round, one edit. Self-identified from the failure output. -
premature-convergence—truncateInlineTextboundary direction. Wrote the boundary test aslength === maxLength→ truncates, when the implementation uses>(strict). The implementation was correct; the assumption was wrong. Impact: one failing test, one edit, no rework. Self-identified from the failure output. -
scope-drift— ESM import side-question. The user asked mid-session about switching to ESM imports. The response engaged the technical analysis (correct) and filed issue #32 (correct), but took several turns. The right shape was: 30-second answer + issue filed. No rework, minor turn cost.
What caused friction (user side)
-
Failure triage coaching. Without the user's explicit instruction ("it may be showing false assumptions — don't assume the test is wrong"), the
sanitizeAvailableToolsSectionfailure would likely have been diagnosed as a test error and silently adjusted. The rule needed to be stated; it is now inAGENTS.md. Earlier placement would have prevented the coaching moment. -
Mock isolation example in the plan. The plan's own testing example showed
afterEach(() => { vi.restoreAllMocks(); })withoutvi.clearAllMocks(). Providing that example as the template seeded the bug into the first mock-heavy test file written. Earlier detection in plan review would have saved a turn.
Changes made
- Added mock-cleanup guidance to
AGENTS.md§ Testing: extractvi.fn()stubs to module-scope variables and call.mockReset()inbeforeEach; documentsvi.fn()vsvi.spyOn()distinction. (Refined after reviewing~/tinyigsoftware/repone/.agents/skills/testing/SKILL.md.) - Added
node:*built-in mockdefaultexport rule toAGENTS.md§ Testing. (Sourced from same skill.) - Added
test.fails+ issue pattern bullet toAGENTS.md§ Testing.