This document is the operating contract for any AI agent working in this repository. Read it fully before writing a single line of code.
Requirements live in docs/features/current_sprint/.
Before doing anything else:
ls docs/features/current_sprint/
Every .feature file is a Gherkin specification. Each scenario is a unit of work.
Scenarios are the source of truth — not comments, not README text, not chat history.
If a scenario is ambiguous, ask before implementing.
Folder layout:
| Folder | Meaning |
|---|---|
docs/features/current_sprint/ |
Active sprint — implement these |
docs/features/backlog/ |
Future sprints — do not touch unless explicitly asked |
docs/features/completed/ |
Shipped — reference only |
- Read every scenario in the relevant
.featurefile end-to-end. - Find the code that needs to change (
src/,extension/). Read it before editing it. - Implement the minimum code that makes all scenarios pass. No extras, no speculative abstractions.
- Follow the code style rules: SOLID, strategy, minimal, VERY MINIMAL. DRY. No unnecessary comments, docstrings, or type annotations on unchanged code.
- Do not add error handling for impossible cases. Trust internal guarantees.
- Do not add features, refactor, or "improve" code that was not in scope.
- When editing a function or class, only modify the lines that are necessary to implement the feature. and add comments on WHY WHAT HOW only
Every sprint closes with a full end-to-end test of the real system. This is non-negotiable.
See docs/features/current_sprint/21_sprint_e2e_requirement.feature for the exact definition.
- A real VS Code instance with the DebuggingAI extension installed (via
vscode-extension-tester). - A real target process being debugged — Node.js or Python. No mocks. No fake events.
- The test plays the role of the AI agent: it drives the debugger via MCP tools or HTTP (port 7890), reads real variable values, observes real bus events.
- All assertions are on real runtime data. Hardcoded expected values are only allowed when the fixture explicitly sets them.
npm run test:e2eThis launches a real VS Code instance via vscode-extension-tester. It must pass before any sprint is considered done.
Important: e2e test files use the .e2e.ts extension and run with Mocha via vscode-extension-tester. Do not use jest.setTimeout(), jest.mock(), or Jest's expect() in .e2e.ts files — use Mocha's this.timeout() and standard assertions (assert). Files with .test.ts extension (like multi-session.test.ts) are Jest unit tests and run with npm test.
- Unit tests only — not sufficient.
- Mocked debugger / mocked bus events — not sufficient.
- Manual verification — not sufficient.
- A passing CI pipeline without the e2e job — not sufficient.
If npm run test:e2e does not pass, the sprint is not closed. No exceptions.
- All scenarios in
current_sprint/are implemented. - All unit tests pass:
npm test - The full e2e suite passes:
npm run test:e2e - No linting errors:
npm run lint
Only after all four are green may you commit and open a PR.
src/— core TypeScript:BusRouter,DebugStateMachine, MCP server, CDP/DAP adapters.extension/— VS Code extension host: command registration, session lifecycle, Output Channel.src/e2e/— end-to-end tests (real VS Code, real processes).src/e2e/multi-session/— current sprint e2e fixture (server + client bug/fix scenario).
The MCP server exposes debug tools to AI agents over HTTP on port 7890.
The BusRouter is the shared pub/sub backbone — all session events flow through it.
Full architecture: docs/ARCHITECTURE.md.
- Do not mock the debugger, the bus, or VS Code APIs in e2e tests.
- Do not open a PR until e2e passes.
- Do not implement backlog features unless explicitly asked.
- Do not skip linting hooks (
--no-verify). - Do not add features, refactor, or "improve" code that was not in scope.
- Do not write to
docs/features/completed/— that is Mickey's job.