LeetCode

Build a local coding interview trainer. One repo, single user, no accounts, no cloud, no telemetry. It runs on my machine.

Stack, not negotiable: Python 3.11 with FastAPI on the backend, SQLite through SQLAlchemy, a Vite + React + TypeScript frontend using the Monaco editor, Docker for code execution. Do not add auth. Do not add a hosted judge API.

Problems live on disk, not in the database. Each problem is a folder under ./problems/<slug>/ containing problem.md (the statement), meta.yaml (title, difficulty, topic tags, language stubs) and tests.json (an array of {input, expected} objects, including at least one large case for timing). Write 12 seed problems yourself covering arrays, two pointers, a stack, binary search, BFS on a grid, interval merging, and one small DP. Do not scrape or reproduce LeetCode content.

Execution: POST /api/run accepts {slug, language, code} and runs it in a throwaway Docker container. Only python:3.11-slim and node:20-slim images. Flags: --network none, --memory 256m, --cpus 0.5, --pids-limit 64, read-only root filesystem, non-root user, 5 second wall clock kill. Wrap the submitted function with a harness that feeds each test case and compares output. Return per-test pass or fail, stderr, and runtime in milliseconds. Never execute submitted code outside Docker, not even in dev mode, not even as a fallback.

Store every submission in SQLite: slug, language, code, verdict, runtime, timestamp. I want to diff my third attempt against my first.

Review queue: SM-2 style spaced repetition over solved problems. Correct solve pushes the next due date out, a failure resets it. GET /api/due feeds a Today view that tells me what to redo.

UI, three routes: problem list with difficulty, last verdict and next due date · problem view with statement left, Monaco right, Ctrl+Enter to run, results panel below · stats page with a solve calendar and per-topic pass rate.

Explicitly out of scope: contests, leaderboards, other people's solutions, discussion threads, company tags, languages beyond Python and JavaScript, mobile layout, deployment.

Ship a README with a single make dev command and a .env holding only PORT and DOCKER_HOST. Before you claim it works, prove the sandbox survives an infinite loop, a fork bomb, a 2 GB allocation, and an outbound HTTP request, and paste the output.

# AGENTS.md — Build guide for LeetCode

## Project scope
A local judge that runs your submitted Python or JavaScript against test cases in Docker, stores every attempt, and resurfaces solved problems on a spaced repetition schedule.

Catalogue verdict: no. An agent can produce a Monaco editor, a problem list, a submissions table and a Judge0 sandbox in a session, and none of that is the product. LeetCode is a content and coordination asset: thousands of curated problems with hidden test cases that actually catch off-by-one and TLE, editorials, company frequency tags, and the social fact that interviewers pull questions from it, which you cannot self-host. Clone the harness and you sit staring at an empty problems directory; authoring good problems with adversarial test cases is the actual job. Build the trainer if you want a private drill rig over problems you have already seen, but do not pretend it replaces the bank.
Use the implementation prompt below to define the deliverable. Complete each phase's acceptance checks before extending the scope.

## Working agreement
- Inspect the repository and its existing instructions before choosing paths, dependencies or commands. Keep one coherent stack and explain changes to the proposed architecture.
- Plan a vertical slice that accepts a real input and produces the useful output described below. Persist only the state the prompt calls for; respect memory-only and upstream-managed workflows. Use fixtures only when they are clearly labelled.
- After scaffolding, document the actual install, development, check and build commands in README and keep them synchronized with the package or project manifest. Do not report commands as successful unless they ran.
- Work in small steps. At handoff, list implemented flows, checks actually performed, remaining blockers, and any credentials or provider setup the owner must supply.
- Do not publish, spend money, contact customers, delete source data or run irreversible migrations without the project owner's authorization.

## Prerequisites
- Docker installed and a willingness to trust your own container flags with untrusted code
- Your own problem statements and test cases, written by hand or from openly licensed sets
- Python 3.11 and Node for the app itself
- Time budget for the boring part: authoring adversarial test cases, not the UI

## Stack and architecture
- Stack, not negotiable: Python 3.11 with FastAPI on the backend, SQLite through SQLAlchemy, a Vite + React + TypeScript frontend using the Monaco editor, Docker for code execution. Do not add auth. Do not add a hosted judge API.
- Store every submission in SQLite: slug, language, code, verdict, runtime, timestamp. I want to diff my third attempt against my first.
- Interface for this coding interview prep workflow: a local web page with input, progress, review, and export views.

## Security and data integrity
- Execution: POST /api/run accepts {slug, language, code} and runs it in a throwaway Docker container. Only python:3.11-slim and node:20-slim images. Flags: --network none, --memory 256m, --cpus 0.5, --pids-limit 64, read-only root filesystem, non-root user, 5 second wall clock kill. Wrap the submitted function with a harness that feeds each test case and compares output. Return per-test pass or fail, stderr, and runtime in milliseconds. Never execute submitted code outside Docker, not even in dev mode, not even as a fallback.
- Keep API keys and OAuth secrets in .env; redact them from logs, generated files, and error responses.
- State the practical limit: The problem bank itself, thousands of problems with hidden tests tuned to catch the specific ways people get it wrong.

## Agent implementation rules
- Project rule, data: Store every submission in SQLite: slug, language, code, verdict, runtime, timestamp. I want to diff my third attempt against my first.
- Project rule, behavior: Review queue: SM-2 style spaced repetition over solved problems. Correct solve pushes the next due date out, a failure resets it. GET /api/due feeds a Today view that tells me what to redo.
- Project rule, recovery: Execution: POST /api/run accepts {slug, language, code} and runs it in a throwaway Docker container. Only python:3.11-slim and node:20-slim images. Flags: --network none, --memory 256m, --cpus 0.5, --pids-limit 64, read-only root filesystem, non-root user, 5 second wall clock kill. Wrap the submitted function with a harness that feeds each test case and compares output. Return per-test pass or fail, stderr, and runtime in milliseconds. Never execute submitted code outside Docker, not even in dev mode, not even as a fallback.

## Optional agent skills and references
No installable skill is listed for this guide; use the project rules and the stack documentation.

Read the linked SKILL.md and its dependencies before adding a skill. Select only the skills matching this project's runtime and task; their documentation does not supply API access, credentials or approval to perform external actions. Pin the reviewed revision where the tool supports it. Follow the chosen agent's documented project-level installation mechanism.

## Distribution ideas
These are optional planning notes. Obtain the owner's approval before publishing or contacting anyone.
- Demonstrate this coding interview prep operation with sample or user-owned data: Review queue: SM-2 style spaced repetition over solved problems. Correct solve pushes the next due date out, a failure resets it. GET /api/due feeds a Today view that tells me what to redo.
- Show a concrete result or export: Explicitly out of scope: contests, leaderboards, other people's solutions, discussion threads, company tags, languages beyond Python and JavaScript, mobile layout, deployment.
- State the practical limit: The problem bank itself, thousands of problems with hidden tests tuned to catch the specific ways people get it wrong.

## Engineering roadmap
1. Phase 1, architecture and data: Stack, not negotiable: Python 3.11 with FastAPI on the backend, SQLite through SQLAlchemy, a Vite + React + TypeScript frontend using the Monaco editor, Docker for code execution. Do not add auth. Do not add a hosted judge API. Store every submission in SQLite: slug, language, code, verdict, runtime, timestamp. I want to diff my third attempt against my first.
2. Phase 2, implement: Review queue: SM-2 style spaced repetition over solved problems. Correct solve pushes the next due date out, a failure resets it. GET /api/due feeds a Today view that tells me what to redo.
3. Phase 3, implement: Explicitly out of scope: contests, leaderboards, other people's solutions, discussion threads, company tags, languages beyond Python and JavaScript, mobile layout, deployment.
4. Phase 4, review and output: A local judge that runs your submitted Python or JavaScript against test cases in Docker, stores every attempt, and resurfaces solved problems on a spaced repetition schedule. Explicitly out of scope: contests, leaderboards, other people's solutions, discussion threads, company tags, languages beyond Python and JavaScript, mobile layout, deployment.
5. Phase 5, recovery and acceptance: Execution: POST /api/run accepts {slug, language, code} and runs it in a throwaway Docker container. Only python:3.11-slim and node:20-slim images. Flags: --network none, --memory 256m, --cpus 0.5, --pids-limit 64, read-only root filesystem, non-root user, 5 second wall clock kill. Wrap the submitted function with a harness that feeds each test case and compares output. Return per-test pass or fail, stderr, and runtime in milliseconds. Never execute submitted code outside Docker, not even in dev mode, not even as a fallback. Verify this invariant with a saved fixture: An invalid input or interrupted operation must retain the source and show a recoverable state; exported records must reload with the same IDs. State the practical limit: The problem bank itself, thousands of problems with hidden tests tuned to catch the specific ways people get it wrong.

## Paid-product capabilities outside this build
- The problem bank itself, thousands of problems with hidden tests tuned to catch the specific ways people get it wrong
- Company tags and frequency data, which is the main reason people pay for Premium
- Editorials and the discussion threads where the actual learning happens
- Contests, ratings, and the mild public humiliation that makes you keep showing up
- Any signal that you are practicing the same questions your interviewer will ask

## Implementation prompt
Build a local coding interview trainer. One repo, single user, no accounts, no cloud, no telemetry. It runs on my machine.

Stack, not negotiable: Python 3.11 with FastAPI on the backend, SQLite through SQLAlchemy, a Vite + React + TypeScript frontend using the Monaco editor, Docker for code execution. Do not add auth. Do not add a hosted judge API.

Problems live on disk, not in the database. Each problem is a folder under ./problems/<slug>/ containing problem.md (the statement), meta.yaml (title, difficulty, topic tags, language stubs) and tests.json (an array of {input, expected} objects, including at least one large case for timing). Write 12 seed problems yourself covering arrays, two pointers, a stack, binary search, BFS on a grid, interval merging, and one small DP. Do not scrape or reproduce LeetCode content.

Execution: POST /api/run accepts {slug, language, code} and runs it in a throwaway Docker container. Only python:3.11-slim and node:20-slim images. Flags: --network none, --memory 256m, --cpus 0.5, --pids-limit 64, read-only root filesystem, non-root user, 5 second wall clock kill. Wrap the submitted function with a harness that feeds each test case and compares output. Return per-test pass or fail, stderr, and runtime in milliseconds. Never execute submitted code outside Docker, not even in dev mode, not even as a fallback.

Store every submission in SQLite: slug, language, code, verdict, runtime, timestamp. I want to diff my third attempt against my first.

Review queue: SM-2 style spaced repetition over solved problems. Correct solve pushes the next due date out, a failure resets it. GET /api/due feeds a Today view that tells me what to redo.

UI, three routes: problem list with difficulty, last verdict and next due date · problem view with statement left, Monaco right, Ctrl+Enter to run, results panel below · stats page with a solve calendar and per-topic pass rate.

Explicitly out of scope: contests, leaderboards, other people's solutions, discussion threads, company tags, languages beyond Python and JavaScript, mobile layout, deployment.

Ship a README with a single make dev command and a .env holding only PORT and DOCKER_HOST. Before you claim it works, prove the sandbox survives an infinite loop, a fork bomb, a 2 GB allocation, and an outbound HTTP request, and paste the output.

## Completion evidence
Demonstrate the prompt's acceptance scenarios against the scoped workflow. Include setup from a clean checkout and failure recovery. Check persistence across restart and export/restore only for the state the prompt says to store; for memory-only tools, confirm that temporary content is discarded as specified. Record actual results and remaining limitations. A detailed plan alone does not establish a working replacement.