Review changes

When work is out of date, the Review changes drawer is where you resolve it, reviewably, one action at a time. Hub proposes a review, you approve the actions you agree with, and only then does it apply.

Propose is safe to run anytime. Apply is the gated step, nothing changes until you approve specific actions and click Apply.

Opening it

The owner card on a spec or Goal that changed is Review changes. A completion gate also offers Review changes for in-progress tickets that are blocked from closing. The drawer lists each proposed action with Keep as-is, Update, Later, Create a spec, or Retire, plus why it is here. Check the ones you approve and click Apply.

Specs, then tickets

When a project uses the spec layer, review runs in two steps: specs under this Goal first, then tickets under each changed spec. The drawer shows Specs under this Goal at the top; once you apply it, Tickets under this spec surfaces one pane per affected spec (or you can reveal it from current state without applying). Each row lets you pick Keep as-is, Update, Later, Create a spec, or Retire, and toggle approval.

If an agent prepared the review, the drawer shows Prepared by. If something changed while you were looking, it says Something changed since this review was prepared. Refresh.

An agent proposes with MCP rinkata_propose_staged_reconcile and hands you the review; you apply it from this drawer, or with rinkata_apply_staged_reconcile / CLI rinkata reconcile staged-apply on your own human-bound key. Apply is human-only — agent keys and MCP OAuth are refused with STAGED_APPLY_HUMAN_REQUIRED.

When apply refuses

If something changed between propose and apply, apply refuses and the banner asks you to Refresh. Re-review what is current rather than overriding; treat that as a blocker.

See also

• How review works: the concept, the verbs, and the two-stage flow in depth.
• Why work goes out of date: what this review is resolving.
• The spec drawer: the specs this review walks.