How Jina reviews code
Understand planning, isolated investigations, validation, publication, and recovery.
Review stages
- Planner identifies materially affected runtime surfaces and failure modes.
- Investigation agents inspect and execute code in isolated Daytona sandboxes.
- Replanner adds evidence-driven follow-up work when another loop is useful.
- Reviewer validates, deduplicates, assigns severity, and determines merge readiness.
Evidence and severity
A finding names the triggering condition, failed behavior, impact, and smallest relevant source location. Execution-backed evidence is preferred when it is safe.
- P0 — critical, broadly exploitable, or irreversible loss.
- P1 — high-impact security, correctness, or data-loss failure.
- P2 — bounded but reproducible runtime, reliability, or compatibility failure.
- P3 — concrete low-impact defect; never a style preference.
Durability and status
Google Pub/Sub owns GitHub delivery retries. Trigger.dev owns queueing, concurrency, retries, and terminal run state. PostgreSQL binds exactly one Trigger run to each admitted work request and stores the product result.
Reviews shows durable product results. A one-minute repair job reconciles the internal high-level work projection without becoming another workflow engine.