Skip to content

Code Review — RapidDraft (April 2026)

Status: Draft — produced 2026-04-17 Scope of review: GitHub repo adeelyj/rapiddraft_utumpitch (local copy at D:\02_Code\54_ClaudeReview_Rapiddraft\rapiddraft_utumpitch), live app app.rapiddraft.ai, wiki wiki.rapiddraft.ai, local project docs under C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management. Reviewer role assumed: Principal engineer / tech lead — balancing pilot readiness, the "deterministic, traceable, human-in-the-loop" USP, and a small team moving from prototype to paid pilots. Purpose: A durable, actionable code-review checklist designed to be consumed by Codex (or any AI coding agent) to land the changes incrementally.

How To Use This Section With Codex

Each finding is formatted as a task block with:

  • ID (e.g. A1) — stable reference
  • Status — Open, In progress, Done, Won't fix
  • Impact / Complexity / Time — triage dimensions (H/M/L, D=days, W=weeks)
  • Files — exact paths and line numbers from the April 2026 snapshot
  • Finding — what is wrong and why it matters
  • Action for Codex — a numbered, concrete instruction list
  • Acceptance criteria — how to verify the change is correct
  • Depends on — prerequisite finding IDs, if any

To run a finding with Codex: copy the whole task block into the Codex prompt, point it at the repo, and ask it to apply the change plus write the verification.

Policy when applying: do not bundle unrelated findings into one PR. Each finding corresponds to one PR ideally, or a tight cluster within one section.

When updating this doc: flip the Status field and add a link to the merged PR in a Landed: line at the bottom of the finding block. Do not rewrite the original finding — history matters for audit.

Finding Index

Section Topic File
A Security & auth 01_Security_and_Auth.md
B Runtime reliability 02_Runtime_Reliability.md
C Backend architecture 03_Backend_Architecture.md
D Frontend 04_Frontend.md
E Process, CI, release 05_CI_and_Process.md
F Product / trust gaps (wiki promises vs code) 06_Product_Trust_Gaps.md
G DFM PDF report template 07_PDF_Report_Template.md
— Suggested triage (top-10 before next pilot) 08_Priority_Triage.md
— Runtime pipeline audit synthesis 09_Runtime_Pipeline_Audit_Synthesis.md

Triage Dimensions

  • Impact — effect on pilot trust, security, reliability, or velocity
  • H = pilot-blocking, security-critical, or directly undermines the USP
  • M = degrades quality, adds friction, or costs engineering time every week
  • L = polish, cosmetic, or minor technical debt
  • Complexity — engineering difficulty
  • H = multi-subsystem, schema change, or new infrastructure
  • M = local refactor or new module
  • L = small, mechanical change
  • Time — calendar effort for one engineer
  • D = days, W = weeks

Conventions For Paths And References

All file paths are relative to the repo root unless otherwise noted. Line numbers reflect the April 2026 snapshot — when Codex applies a change, always grep for the symbol instead of trusting the line number.

Not In Scope

  • The wiki itself and its MkDocs build
  • The benchmark_data/ fixtures, media, and PDF attachments in the repo root
  • Personal project-management files referenced from AGENTS.md (absolute Windows paths — see finding E5)
  • RapidDraft Studio (the IDE-scope product) — reviewed separately

Summary Of The Highest-Impact Findings

The ten items in 08_Priority_Triage.md are the ones that should land before the next pilot kickoff. They cluster into three buckets:

  1. Close the door on the public internet (CORS, auth middleware, API-key-in-body, file upload limits) — A1, A2, A3, A4, A5.
  2. Harden the runtime so two simultaneous reviewers don't corrupt state (per-model locking, event-loop off-loading, pinned deps) — B1, B2, B5.
  3. Make the report and the UI actually carry the USP (app-level error boundary + toast, single API client, rule-ID/standard/observed-value on each PDF finding, activity log) — D2, D3, F1, G-findings.