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.

See it in PAPI
Build Handofftask-317 · Cycle 12
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

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