Repro Api

---
name: repro-api
description: Reproduce an EmDash bug below the browser layer -- REST handlers, CLI, MCP, migrations, schema registry, or build tooling. No browser. Prefer a failing vitest test in the affected package, run in an attached container.
---

# 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.

## When to skip

Mark skipped, with the reason, when the reproduction genuinely cannot happen here. Do not burn container time fighting these:

- Needs a WordPress export, customer dataset, or other artifact the reporter did not attach.
- Only manifests on a deployed Cloudflare Worker -- cold starts, eventual consistency, transient D1 errors, isolate eviction. A local run does not reproduce these faithfully.
- Needs Postgres at production scale (table sizes, pool exhaustion, planner choices). A handful of rows will not surface the same plan.
- Needs real Cloudflare Access, R2 credentials, AI Gateway routing, or other bindings the Workspace does not have.
- Timing-dependent heisenbug not reliably reproducible across runs. Note the symptom, leave it for a human.

## Output

Return:

- Whether you reproduced the bug.
- Whether you skipped, and the reason if so.
- The approach: `failing-test`, `repro-script`, `pnpm-command`, or `none`.
- Notes: the exact command(s), the failure output, and anything diagnose will need. Include the test file path if you wrote one.
- An empty screenshots list -- this skill produces none.

If you wrote a failing test, leave it in place; do not stage or commit it. A "could not reproduce" result with the full transcript of what you tried is a valid, useful outcome -- return it as one, not as silence.