PinAppAI

← All docs

The iteration loop

How PinAppAI organizes review rounds: an Inbox of change requests, one Apply command that hands them to your AI agent, and per-item reviewer verdicts.

PinAppAI’s backbone is a simple loop: reviewers request changes, your AI agent applies them, reviewers verify the result. The dashboard has exactly three tabs (Inbox, InReview, Closed) and every change request (CR) is always in exactly one of them.

The loop

reviewers pin change requests on the live site
   │
   ▼
Inbox            ← every new CR lands here (#N number assigned)
   │
   │  apply workflow: your AI agent edits source,
   │  regenerates /changes/, registers the round
   ▼
InReview         ← applied, awaiting verdicts
   │
   ├── Approve          → Closed (done)
   ├── Reject           → back to Inbox (next Apply reverts the edit)
   └── Request change   → back to Inbox (next Apply applies the new wording)

That’s the whole model. There is no separate triage ceremony: anything in the Inbox is Apply-eligible, and one apply run drains it.

Inbox

New pins arrive as CRs with a per-project short number (#41, #42): the same number you’ll see inside the pin marker on the page, on the /changes/ review card, in commit messages, and on the dashboard row. One identity everywhere.

Inbox rows carry a substate badge so you can see why something is here: 🆕 new, ↩ rejected (needs a revert), 🔄 change requested (needs new wording), ⏸ deferred. Defer parks a CR you’re not ready to act on. It’s skipped by Apply until you undefer it.

Apply

The Apply button (or running the apply workflow directly in Claude Code, Codex, Cursor, or any MCP-aware agent, see Run a workflow) hands every non-deferred Inbox CR to your AI agent. The agent:

  1. Edits your source files: new applies, reverts for rejected CRs, rewrites for change requests. It asks before doing anything it isn’t sure about, and nothing is ever committed without your explicit say-so.
  2. Regenerates the /changes/ review page to match.
  3. Records the round with PinAppAI, moving every applied CR to InReview.

Each Apply run is recorded as an iteration: the project’s apply history, visible per CR (“From iter #3”).

InReview

Applied CRs wait here for verdicts. Reviewers decide from the live page (green pin / review panel) or from /changes/; admins can also decide from this tab. First action wins: whoever verdicts first owns the decision.

Owning it does not mean being stuck with it. That reviewer can revise their own verdict until the change request is applied again, so a misclicked Reject is a two-second fix rather than an admin ticket. Another reviewer cannot overwrite the decision, but their verdict is not thrown away either: it is recorded in the change request’s history, so a disagreement stays visible instead of vanishing.

  • Approve closes the CR.
  • Reject or Request change sends it back to the Inbox with the matching substate, and the next Apply handles the revert or the new wording. Same CR, same #N. Nothing forks.

Closed

Terminal CRs: ✓ done or ✗ wontfix. Reopen sends one back to the Inbox if it turns out the work isn’t finished after all.

Where the AI fits

Everything the dashboard does is also available to your AI agent through the MCP server: apply is the loop’s engine, and companion workflows cover setup, /changes/ generation, analysis, and project reset.