Issue to Code documentation

What this system does

Issue to Code is a multi-agent service that converts an issue (a bug report, a feature request, an improvement) into a pull request opened on GitHub. The user creates an issue from the application, the pipeline runs in the background, the user reviews and approves the plan, and a PR appears in their repository minutes later.

Under the hood the work is split among seven specialised agents orchestrated with LangGraph. Each agent has one responsibility and communicates through a shared graph state. Long-running steps are streamed to the frontend over Server-Sent Events.

The seven agents

1. Parser (Claude Haiku 4.5) — extracts the issue type, keywords, affected areas and a one-sentence summary from the raw title and description.
2. Locator (Claude Sonnet 4.6) — runs a two-phase retrieval over the indexed repository: semantic search over symbol embeddings, then expansion through the dependency graph.
3. Plan Generator (Claude Sonnet 4.6) — produces a structured plan describing files to modify, files to create and the subtasks involved.
4. Human review — the pipeline pauses at a LangGraph interrupt. The user approves, rejects or instructs the agent before any code is generated.
5. Few-shot retriever — pulls up to three historical resolved issues from the same user as in-context examples. No LLM, just an embedding lookup.
6. Code Generator (Claude Sonnet 4.6) — rewrites each file in the approved plan in full.
7. Self-Reflector (Claude Sonnet 4.6) — a second pass of the same model reviewing its own output (plan alignment, imports, exports, completeness). Up to three retries.
8. PR Creator (Claude Haiku 4.5) — opens the branch, commits the files and writes the PR description.

The UI compresses these into six visible steps; the Few-shot Retriever is presented as a sub-step inside Code because it is preparatory work without its own LLM call.

How to read this documentation

• Architecture— the bird's eye view of how the services fit together (Postgres, Redis, Qdrant, the FastAPI backend, the Next.js frontend).
• Authentication — how sessions work. Note the API does not use bearer tokens: it relies on an HTTP-only cookie.
• Streams (SSE) — the two long-running streams the backend exposes and the shape of the events they emit.
• Rate limits & errors — every limit currently in place and the conventional meaning of every HTTP status code.
• API reference— the endpoints grouped by resource. The content is generated from the backend's live /openapi.json so it cannot drift from the real implementation.

Scope of this reference

The reference covers the endpoints that drive the product end-to-end: /api/repos, /api/issues and the GitHub helpers under /api/github. Authentication endpoints, settings and health-check endpoints are intentionally omitted; they are internal to the application shell and not part of the “Issue to Code” flow.