repro-api

Reproduce: API / CLI / Migration / Build

The bug does not need a browser. It lives in a handler, the CLI, the MCP server, a migration, the schema registry, or the build pipeline. Your goal is a deterministic reproduction you can put in the comment as evidence -- ideally a failing vitest test that becomes the regression fixture once fixed.

Environment

• Read and search in the VFS. Use read_file, ls, grep, and code to find the package, read the handler in full, and trace call sites. This is most of the work and none of it needs a container.
• Attach a container only to run the project. The harness has already installed dependencies and built the base workspace. Use the container for the focused reproduction command; do not repeat the install or root build.

Do not

• No git commit, git push, or branch creation. This stage never writes to the remote.
• No GitHub writes (no comments, labels, reactions). Read-only API GETs only.
• No network beyond the repo clone, the proxy-signed GitHub API, and the npm registry.
• No pnpm publish / npm publish.
• Touch no issue other than the one being investigated.

Procedure

1. Anchor on the issue's exact words. In the isolate, pull the commands, file paths, package names, and stack traces out of the issue body verbatim. Your reproduction matches what the reporter wrote, not a paraphrase. If the body links a repo or gist, fetch it read-only before choosing an approach.
2. Find the package (isolate). Use area plus file paths in the body. CLI -> packages/core/src/cli/. REST handlers -> packages/core/src/api/handlers/. Migrations -> packages/core/src/database/migrations/. MCP -> packages/core/src/mcp/. Build -> packages/*/tsdown.config.ts or root pnpm-workspace.yaml. If several packages are plausible, grep before guessing. Read the candidate code fully in the isolate before you spend a container on it.
3. Attach a container. Everything from here needs one.
4. Use the prepared toolchain. Do not run pnpm install or the root pnpm build. Run a package build only when the reproduction specifically targets compiled output.
5. Choose an approach, in order of preference:
   • Failing vitest test in the package's tests/ tree. Use setupTestDatabase() / setupForDialect() from tests/utils/test-db.ts for anything touching the database; use the dialect wrapper (describeEachDialect) when the bug could be dialect-specific. Mirror source structure (.../src/api/handlers/foo.ts -> .../tests/integration/api/handlers/foo.test.ts). Name it for the issue: it("reproduces #<number>: <short description>", ...). Run with pnpm --filter <package> test <path> and confirm it fails for the reason reported, not an unrelated setup error.
   • Repro script under /tmp/repro-<issueNumber>/ when a test would need too much scaffolding (needs a built binary, needs to spawn children in a specific order). One file when possible; capture stdout, stderr, exit code.
   • pnpm exec emdash ... when the bug is a single CLI invocation whose failure is obvious from the output.
6. Capture evidence. For every attempt record the exact command, the meaningful slice of stdout/stderr (trim -- do not dump thousands of lines), and the exit code. This transcript is the deliverable.
7. Confirm the failure mode matches. A crash for a different reason is not a reproduction. If you can only trigger an adjacent failure, say so and lower confidence.