All features
Briefing

Build Handoffs

Briefs your AI can run cold.

papibuildtyped in your AI tool
The problem

Your AI starts each task from nothing. You re-explain what to build, what not to touch, and how you will know it is done.

How it works

When you start a task, PAPI hands your AI a full brief: the goal, the scope boundary, the acceptance checks, the risks, and the files most likely involved. Your AI builds from the brief, not from a memory it does not have. PAPI calls this the handoff — work survives the AI that started it, because a different tool can pick it up and run it cold.

See it in PAPI
Build Handofftask-317 · Cycle 12

A BUILD HANDOFF is PAPI's written spec for one task: what to do, what not to do, and how you will know it is done. Your AI client builds from it.

Why nowCustomers who pay by card need refunds to settle to the original card, and the current flow has no idempotency on retries, so a dropped webhook can double-refund.
SCOPE (DO THIS)
  • Settle refunds to the original payment method.
  • Support partial refunds against a single charge.
  • Make webhook retries idempotent with a stored idempotency key.
SCOPE BOUNDARY (DO NOT DO THIS)
  • Do not touch the checkout capture path.
  • Do not add a new payment provider.
ACCEPTANCE CRITERIA

[ ] Refunds settle to the original card [ ] Partial refunds supported [ ] Webhook retries are idempotent [ ] A dropped-then-retried webhook never double-refunds

PRE-MORTEM
  • Most likely blocker: the provider sends the same webhook twice on retry with the same event id; key on the event id, not the charge id.
EFFORT

M

▸Show 1 additional section
FILES LIKELY TOUCHED
  • refunds.ts
  • webhooks.ts
  • portal.tsx

Related guides

Put this on your own project.

Connect PAPI to the AI tool you already build in. This surface, and every other, come with it.

Connect PAPI