{ "repositories": [ { "id": "documenso", "name": "Documenso", "github_url": "https://github.com/documenso/documenso.git", "cases": [ { "id": "documenso-purpose", "category": "architecture", "question": "What is Documenso and what product problem is it trying to solve?", "ground_truth": "Documenso is an open-source document signing platform and DocuSign alternative. It lets users create, send, and sign documents electronically while emphasizing self-hosting, trust, and the ability to inspect how the signing system works under the hood.", "expected_sources": ["README.md", "MANIFEST.md", "ARCHITECTURE.md"], "must_include_any": ["document signing", "self-host", "DocuSign", "open trust"] }, { "id": "documenso-api-v2-document-router", "category": "api", "question": "Where is the current document API implemented and how is it exposed?", "ground_truth": "The current API V2 is implemented under packages/trpc/server, with document operations organized under a document router. It is exposed through /api/v2 and /api/v2-beta with tRPC and OpenAPI support, and it accepts API-token or session-cookie authentication depending on the route.", "expected_sources": ["ARCHITECTURE.md", "packages/trpc/server", "packages/trpc/server/document-router", "apps/remix/server"], "must_include_any": ["packages/trpc/server", "document-router", "API V2", "OpenAPI", "tRPC"] }, { "id": "documenso-signing-package", "category": "specific-function", "question": "What does the signing package do in Documenso?", "ground_truth": "The @documenso/signing package owns PDF signing behavior. Its signPdf entry point selects a signing transport, applies timestamp authority settings when configured, and supports local P12 signing and Google Cloud KMS/HSM-backed signing through transport implementations.", "expected_sources": ["ARCHITECTURE.md", "packages/signing/index.ts", "packages/signing/helpers", "packages/signing/transports", ".env.example"], "must_include_any": ["PDF signing", "transports", "local", "Google", "KMS"] }, { "id": "documenso-document-send-flow", "category": "cross-file", "question": "How does a document send operation flow across the Documenso codebase?", "ground_truth": "A document send operation starts at an API or UI route, goes through the API layer such as packages/trpc/server/document-router, delegates core behavior to packages/lib/server-only/document and related recipient or field logic, persists through packages/prisma, and can trigger emails or jobs through packages/email and packages/lib/jobs.", "expected_sources": ["packages/trpc/server/document-router", "packages/lib/server-only/document", "packages/lib/server-only/recipient", "packages/prisma", "packages/email", "packages/lib/jobs"], "must_include_any": ["document-router", "server-only/document", "prisma", "email", "jobs"] }, { "id": "documenso-required-env", "category": "config-setup", "question": "Which environment variables are central to running a self-hosted Documenso instance?", "ground_truth": "The setup expects values such as NEXTAUTH_SECRET, NEXT_PRIVATE_ENCRYPTION_KEY, NEXT_PRIVATE_ENCRYPTION_SECONDARY_KEY, NEXT_PUBLIC_WEBAPP_URL, NEXT_PRIVATE_DATABASE_URL, NEXT_PRIVATE_DIRECT_DATABASE_URL, NEXT_PRIVATE_SMTP_FROM_NAME, and NEXT_PRIVATE_SMTP_FROM_ADDRESS. The env example and self-hosting docs also cover internal URLs, signing transport, storage transport, and optional OAuth and webhook configuration.", "expected_sources": ["README.md", ".env.example", "apps/docs/content/docs/self-hosting/configuration/environment.mdx"], "must_include_any": ["NEXTAUTH_SECRET", "NEXT_PUBLIC_WEBAPP_URL", "DATABASE_URL", "SMTP", "encryption"] }, { "id": "documenso-playwright-tests", "category": "tests", "question": "Where does Documenso keep end-to-end app tests?", "ground_truth": "The architecture identifies @documenso/app-tests as the E2E test package, and the packages/app-tests directory is intended for Playwright coverage of app behavior.", "expected_sources": ["ARCHITECTURE.md", "packages/app-tests", "packages/app-tests/package.json"], "must_include_any": ["app-tests", "E2E", "Playwright"] }, { "id": "documenso-webhook-security-errors", "category": "error-handling", "question": "Where should you look for webhook security or SSRF-related safeguards?", "ground_truth": "Webhook safeguards belong in packages/lib/server-only/webhooks, with related configuration documented in .env.example such as NEXT_PRIVATE_WEBHOOK_SSRF_BYPASS_HOSTS. These sources explain where outbound webhook behavior and security exceptions are controlled.", "expected_sources": [".env.example", "packages/lib/server-only/webhooks"], "must_include_any": ["webhook", "SSRF", "bypass", "hosts"] }, { "id": "documenso-followup-signing-bridge", "category": "conversation", "turns": [ {"role": "user", "content": "How does Documenso seal or sign completed documents?"}, {"role": "assistant", "content": "PDF completion crosses server-only PDF/document logic and the @documenso/signing package, which supports local and Google-backed signing transports."} ], "question": "show me where signing plugs in", "ground_truth": "The follow-up should retrieve packages/signing, especially the signPdf entry point, transports, and helpers, plus the seal-document job where completed PDFs are decorated and passed into signing, and signing-related env configuration.", "expected_sources": ["packages/signing/index.ts", "packages/signing/transports", "packages/signing/helpers", "packages/lib/jobs/definitions/internal/seal-document.handler.ts", ".env.example"], "must_include_any": ["packages/signing", "transports", "PDF", "signing"] } ] }, { "id": "sqlite", "name": "SQLite", "github_url": "https://github.com/sqlite/sqlite.git", "cases": [ { "id": "sqlite-purpose", "category": "architecture", "question": "What is SQLite and how is the project organized at a high level?", "ground_truth": "SQLite is a self-contained, serverless, zero-configuration embedded SQL database engine. Its core sources live under src/, tests are TCL scripts, the build produces both a library and a single-file amalgamation, and the project's own AGENTS.md documents the execution pipeline for contributors.", "expected_sources": ["README.md", "src", "AGENTS.md"], "must_include_any": ["embedded", "serverless", "amalgamation", "SQL database engine"] }, { "id": "sqlite-query-pipeline", "category": "cross-file", "question": "How does a SQL statement flow through SQLite's execution pipeline?", "ground_truth": "SQL text is tokenized in tokenize.c, parsed by the Lemon-generated parser from parse.y, turned into VDBE bytecode by the code generator files (build.c, select.c, insert.c, update.c, delete.c, expr.c) after being optimized by the where*.c query optimizer, then executed by the VDBE in vdbe.c against the B-tree layer in btree.c, the pager in pager.c, the WAL in wal.c, and finally the OS-level VFS such as os_unix.c.", "expected_sources": ["src/tokenize.c", "src/parse.y", "src/vdbe.c", "src/btree.c", "src/pager.c", "src/wal.c", "AGENTS.md"], "must_include_any": ["tokenizer", "parser", "VDBE", "B-Tree", "pager", "WAL"] }, { "id": "sqlite-btree-role", "category": "specific-function", "question": "What role does btree.c play in SQLite?", "ground_truth": "btree.c implements the B-tree storage engine SQLite uses to organize table and index data on disk. Its public interface is declared in btree.h, while btreeInt.h defines the data structures used only internally by the module.", "expected_sources": ["src/btree.c", "src/btree.h", "src/btreeInt.h"], "must_include_any": ["B-Tree", "storage engine", "btree.h"] }, { "id": "sqlite-vdbe-opcodes", "category": "specific-function", "question": "How are VDBE opcodes generated and where do they come from?", "ground_truth": "VDBE opcode numbers and names are extracted automatically by scanning src/vdbe.c with the mkopcodeh.tcl script, which generates opcodes.h; a second script, mkopcodec.tcl, then generates opcodes.c, which provides the reverse opcode-to-name mapping used for EXPLAIN output.", "expected_sources": ["src/vdbe.c", "mkopcodeh.tcl", "mkopcodec.tcl"], "must_include_any": ["opcodes.h", "mkopcodeh.tcl", "VDBE", "EXPLAIN"] }, { "id": "sqlite-parser-generation", "category": "config-setup", "question": "How is the SQL grammar parser built for SQLite?", "ground_truth": "The grammar is defined in src/parse.y and compiled into parse.c by the Lemon LALR(1) parser generator in tool/lemon.c, which uses tool/lempar.c as a template and also emits the parse.h header as a side effect.", "expected_sources": ["src/parse.y", "tool/lemon.c", "tool/lempar.c"], "must_include_any": ["parse.y", "Lemon", "LALR", "parse.c"] }, { "id": "sqlite-testing", "category": "tests", "question": "How does SQLite run its test suite and what kind of tests does it use?", "ground_truth": "SQLite's tests are TCL scripts executed through the testfixture binary, which is built with make testfixture. AGENTS.md instructs contributors to run at least make devtest after any change under src/, and make sqlite3.c builds the amalgamation used for distribution.", "expected_sources": ["test", "AGENTS.md", "Makefile.in"], "must_include_any": ["testfixture", "TCL", "devtest", "test suite"] }, { "id": "sqlite-build-amalgamation", "category": "config-setup", "question": "What is the SQLite amalgamation and how is it produced?", "ground_truth": "The amalgamation is the single-file distribution form of SQLite, sqlite3.c, assembled from the individual sources under src/ during the build. The public C API is declared in the src/sqlite.h.in template, which is expanded into the sqlite3.h header shipped with the amalgamation.", "expected_sources": ["src/sqlite.h.in", "Makefile.in", "AGENTS.md"], "must_include_any": ["amalgamation", "sqlite3.c", "sqlite.h.in"] }, { "id": "sqlite-followup-wal", "category": "conversation", "turns": [ {"role": "user", "content": "How does SQLite guarantee that transactions survive a crash?"}, {"role": "assistant", "content": "Durability is enforced through the pager and, depending on journal mode, the write-ahead log."} ], "question": "which files implement that WAL behavior?", "ground_truth": "WAL-mode durability is implemented mainly in src/wal.c, working together with src/pager.c, which coordinates pager and journal behavior, and the OS-level VFS layer such as src/os_unix.c, which performs the actual fsync/durability calls.", "expected_sources": ["src/wal.c", "src/pager.c", "src/os_unix.c"], "must_include_any": ["wal.c", "pager.c", "fsync", "VFS"] } ] }, { "id": "fastapi", "name": "FastAPI", "github_url": "https://github.com/fastapi/fastapi.git", "cases": [ { "id": "fastapi-purpose", "category": "architecture", "question": "What is FastAPI and what is it built on top of?", "ground_truth": "FastAPI is a Python web framework for building APIs. It is built on top of Starlette for the web-facing parts and Pydantic for data validation and serialization, and it automatically generates an OpenAPI schema along with interactive Swagger UI and ReDoc documentation.", "expected_sources": ["README.md", "fastapi/applications.py", "pyproject.toml"], "must_include_any": ["Starlette", "Pydantic", "OpenAPI"] }, { "id": "fastapi-app-class", "category": "specific-function", "question": "What does the FastAPI application class do and where is it defined?", "ground_truth": "The central FastAPI class is defined in fastapi/applications.py. It ties together routing, dependency injection, middleware, exception handling, and OpenAPI schema generation for the whole application.", "expected_sources": ["fastapi/applications.py"], "must_include_any": ["applications.py", "routing", "OpenAPI"] }, { "id": "fastapi-routing", "category": "implementation", "question": "Where is path operation routing implemented in FastAPI?", "ground_truth": "Routing is implemented in fastapi/routing.py, which defines APIRoute and APIRouter. It handles path matching, resolves dependencies for each incoming request, and serializes the response for every registered endpoint.", "expected_sources": ["fastapi/routing.py"], "must_include_any": ["APIRoute", "APIRouter", "routing.py"] }, { "id": "fastapi-dependency-injection", "category": "cross-file", "question": "How does FastAPI resolve dependencies declared with Depends()?", "ground_truth": "Depends() and related parameter markers are defined in fastapi/params.py and fastapi/param_functions.py. The actual dependency tree resolution for each request happens in fastapi/dependencies/utils.py, which fastapi/routing.py calls while handling a request.", "expected_sources": ["fastapi/dependencies/utils.py", "fastapi/params.py", "fastapi/param_functions.py", "fastapi/routing.py"], "must_include_any": ["Depends", "dependencies/utils.py", "dependency"] }, { "id": "fastapi-openapi-generation", "category": "api", "question": "How does FastAPI generate the OpenAPI schema and interactive docs?", "ground_truth": "The OpenAPI JSON schema is generated in fastapi/openapi/utils.py from the app's routes and Pydantic models. The Swagger UI and ReDoc HTML pages are served through helper functions such as get_swagger_ui_html and get_redoc_html in fastapi/openapi/docs.py.", "expected_sources": ["fastapi/openapi/utils.py", "fastapi/openapi/docs.py"], "must_include_any": ["OpenAPI", "Swagger", "ReDoc", "openapi/utils.py"] }, { "id": "fastapi-error-handling", "category": "error-handling", "question": "How does FastAPI turn validation failures and raised exceptions into HTTP responses?", "ground_truth": "FastAPI defines HTTPException and RequestValidationError in fastapi/exceptions.py. The default handlers that convert those exceptions into JSON error responses are registered in fastapi/exception_handlers.py.", "expected_sources": ["fastapi/exceptions.py", "fastapi/exception_handlers.py"], "must_include_any": ["HTTPException", "RequestValidationError", "exception_handlers.py"] }, { "id": "fastapi-security", "category": "specific-function", "question": "How does FastAPI support authentication schemes like OAuth2 and HTTP Bearer tokens?", "ground_truth": "Authentication helpers live under fastapi/security, which provides classes such as OAuth2PasswordBearer and HTTPBearer. They integrate with the dependency injection system and are automatically reflected in the generated OpenAPI security schema.", "expected_sources": ["fastapi/security", "fastapi/openapi/utils.py"], "must_include_any": ["OAuth2", "HTTPBearer", "security", "dependency"] }, { "id": "fastapi-followup-encoder", "category": "conversation", "turns": [ {"role": "user", "content": "How does FastAPI encode response data before it goes back to the client?"}, {"role": "assistant", "content": "Response bodies are converted with jsonable_encoder before being serialized, factoring in the declared response_model."} ], "question": "where is that encoder implemented and how is it tested?", "ground_truth": "jsonable_encoder is implemented in fastapi/encoders.py, converting Pydantic models and other Python objects into JSON-compatible structures. Its behavior is covered by the pytest suite under the tests directory.", "expected_sources": ["fastapi/encoders.py", "tests"], "must_include_any": ["jsonable_encoder", "encoders.py", "tests"] } ] } ] }