Skip to content

Review a Package

Goal: judge a package well as its assigned reviewer; thorough without re-doing the author's work.

Before Anything: the Board

Open Review & Approval. The readiness board has already checked the bookkeeping: gaps, risks, sign-offs, scope proposals. If blockers are open, your review is easy: request changes and point at the board. Your judgment is needed for what the board cannot check.

What Deserves Your Judgment

  1. The design against the intent. Read the inputs, then the Container view: does the shape answer the brief? Click through components; every one carries its rationale.
  2. The advisory context. Boundary growth versus the predecessor, commercial exposure, the design review verdict: these inform rather than block precisely because a human should weigh them. That human is you.
  3. The accepted risk. Read the register's treatments and any sign-off: is what was accepted actually acceptable?
  4. The deferrals. Exceptions with realistic review dates, or parking tickets?

Decide

  • Approve locks the package and starts the drift watch; it is enabled only when the board is clear.
  • Request Changes with a note that names the specific components, risks, or exceptions at issue; the author gets the package back and your note is the work order.

The Note Is the Review

"Needs work" helps nobody. "The payment flow enters the data zone unencrypted, and the deferral on secrets management has no realistic date" is a review. Name things; the whole package is one click deep.