DEV Community: FetchSandbox

AI Code Is Cheap. Your Pull Request Still Needs Proof.

FetchSandbox — Tue, 08 Sep 2026 20:59:59 +0000

Your coding agent opens a plausible pull request before lunch. The tests it wrote pass, the diff reads cleanly, and the reviewer is left with the expensive question: did this change survive the provider failure it claims to handle?

Writing the integration is now the cheap step. Establishing that the integration behaves correctly under retries, lost responses, stale events, webhooks, and partial failure is still the hard step.

How should you verify AI-generated code before merging it?

Verify AI-generated integration code with an independent runtime check, not only the agent's explanation or the tests it wrote. Reproduce the provider failure against the still-broken code, apply the proposed diff to a copy, run the same failure again, and require a measured broken-to-fixed result before merge.

The output should be a shareable receipt that records:

the failure scenario that ran
whether the bug reproduced before the patch
whether the invariant held after the patch
the requests, responses, and observed side effects
an explicit proven, rejected, or unproven verdict

That receipt changes the pull-request conversation from “the agent says this works” to “here is what ran, and here is what changed.”

Why is reviewing AI-written code becoming the bottleneck?

AI coding agents can produce more diffs than a team can carefully inspect. Faster generation increases review pressure because plausible code still has to be checked against the real behavior of every external system it touches.

Static review remains useful. It can catch an unsafe query, a missing authorization check, or an obviously incorrect SDK call. But many integration bugs do not live on one suspicious line:

the same webhook is delivered twice
a successful response disappears after the provider commits the write
a stale event arrives after a newer event
the first request creates an ID that the second request never persists
a handler returns 200 but leaves local state unchanged

The diff can look reasonable while the lifecycle is still broken.

Most current writing about AI code verification says the same broad thing: define acceptance criteria, run tests, and keep humans in the loop. That advice is correct, but it usually stops before the reviewer gets an inspectable artifact showing the failure on the actual code.

The missing layer is runtime evidence attached to the change.

Why is a green test written by the same agent not enough?

A test written by the same agent can repeat the agent's mistaken assumption. It may mock away the provider behavior, assert only an HTTP status, or accept a patch that removes the desired side effect along with the bug.

Consider a webhook that grants seats twice when Paddle redelivers one transaction.completed event. A weak verifier asks:

Did the seat count stop increasing?

An agent can satisfy that check by granting no seats at all. The duplicate is gone, the customer receives nothing, and CI is green.

The real invariant is:

One purchase grants the purchased seats exactly once,
however many times the same event is delivered.

That distinction matters because CI is an optimization target. If “make the reported symptom disappear” is enough to pass, a plausible but destructive patch can pass.

An independent verifier must be able to reject the first fix.

That gate behavior showed up in a separate measured FetchSandbox acceptance run against a Paddle billing demo. The bug in that run was a webhook trusting a client-controlled seat quantity. The first proposed patch came back fix_incomplete; the agent iterated, and only the second patch produced:

buggy tree   → invariant VIOLATED
fixed tree   → invariant HELD
verdict      → green_allowed: true
proof grade  → measured

Inspect the measured client-controlled-seat receipt.

What does FetchSandbox verify on an AI-generated fix?

FetchSandbox acts as the integration verification layer between the coding agent and the pull request. Its prove_fix MCP tool runs the customer's real code before and after the proposed patch against the same provider failure scenario.

The sequence is:

The agent identifies an integration bug with find_bugs.
It proposes a diff with fix_bug.
Before writing that diff into the working tree, it calls prove_fix.
FetchSandbox materializes the still-broken project.
It applies the diff to a separate copy.
It runs the same provider scenario against both versions.
It returns green only when the bug reproduces before and the required invariant holds after.

If FetchSandbox cannot reproduce the bug, it does not convert uncertainty into a pass. The result is unproven, and green_allowed remains false.

A successful result has a machine-readable shape:

{
  "green_allowed": true,
  "state": "proven",
  "reproduced": true,
  "verified": true,
  "receipt_url": "https://fetchsandbox.com/runs/fix-...?flow=..."
}

The receipt URL is public to anyone who has the link. A reviewer can inspect it without access to the original agent conversation.

What should go into the pull request?

An AI-authored pull request should include the claim, the invariant, and the evidence. A short verification block is enough:

## Integration verification

- Failure: duplicate Paddle transaction webhook
- Invariant: one purchase grants seats exactly once
- Before patch: reproduced
- After patch: held
- Receipt: https://fetchsandbox.com/runs/fix-...?flow=...
- Remaining review: authorization, data migration, rollout safety

The receipt does not replace code review. It narrows code review to what still needs human judgment.

The reviewer can now check architecture, maintainability, security boundaries, and whether the invariant represents the intended business rule. They do not have to infer whether the agent ever ran the failure it claims to have fixed.

How does the proof continue into CI/CD?

The pre-merge receipt and the CI workflow gate answer different questions. The receipt proves that one proposed diff changed a reproduced failure into the required behavior. CI keeps the provider workflow from regressing as the branch changes.

FetchSandbox's CLI produces structured JSON and exits non-zero when a normal workflow run fails:

- name: Run API integration workflows
  run: |
    npx fetchsandbox run "$FETCHSANDBOX_ID" --all --json \
      > fetchsandbox-workflows.json

Store fetchsandbox-workflows.json as a build artifact and make the job a required status check when your team is comfortable with its coverage. The same workflow definitions can be explored locally through FetchSandbox MCP and run headlessly in the pipeline.

Today, the prove_fix receipt is attached to the pull request as a link. An automatic GitHub Action that posts the receipt and check result is not yet a shipped FetchSandbox feature, so do not describe that automation as live. The available path is explicit and auditable: prove through MCP, paste the receipt into the PR, and keep the provider workflows running in CI.

What does a proof receipt prove?

A FetchSandbox proof receipt proves the behavior shown on the artifact: the named scenario ran, the bug reproduced on the pre-patch code, and the measured invariant held or did not hold after the patch.

It does not prove that every requirement in the pull request is correct. It does not prove an untested security property, a safe database migration, or a production rollout plan. Good evidence has boundaries.

That is also why an unproven verdict is useful. “We could not reproduce this failure” tells the reviewer where the evidence ends. A confident green with no execution would be worse.

What changes when every pull request carries evidence?

The unit of review changes from a diff plus a confident summary to a diff plus a falsifiable result.

The coding agent can still generate quickly. The human still owns intent and risk. The verification layer owns one narrower job: make the provider failure happen, run the proposed fix against it, and preserve what happened in a receipt.

Cheap code is useful only when teams can qualify it for production without creating an equally large review queue. The next improvement in agentic software development is not another faster generator. It is a better way to say no to an unproven patch.

Connect FetchSandbox MCP to Cursor or Claude Code, run find_bugs → fix_bug → prove_fix, and attach the returned receipt to the next integration pull request. For broader workflow setup, see agent API workflow testing and API integration testing in CI.

Questions developers ask

Does passing CI prove AI-generated code is correct?

No. Passing CI proves only that the checks configured in CI passed. Verify that those checks exercise the relevant provider failure and assert the intended business state, not just an HTTP status or the absence of an exception.

Should the coding agent write its own tests?

The agent can write tests, but those tests should not be the only judge of its patch. Use independent scenarios, reviewed invariants, negative controls, or a separate verification system that can reject the agent's first answer.

Does FetchSandbox replace human pull-request review?

No. FetchSandbox supplies runtime evidence for API integration behavior. Humans still review intent, architecture, security, migrations, and rollout risk.

Can FetchSandbox automatically comment on every GitHub pull request?

Not currently. The shipped workflow returns a shareable proof receipt through MCP, which you can attach manually. The CLI can run workflows as a CI status check; automatic PR comments are planned rather than live.

What happens when FetchSandbox cannot reproduce the bug?

The proof declines to green. An unavailable or inconclusive scenario remains unproven instead of being reported as verified.

Test ElevenLabs 429 Handling Without Burning API Quota

FetchSandbox — Mon, 07 Sep 2026 14:21:39 +0000

Your app loads the ElevenLabs voice list successfully. The user picks a voice, clicks Generate, and the text-to-speech request returns 429.

That is a more useful test than an API that always rate-limits. Authentication worked. Discovery worked. The failure happened on the expensive operation, after the UI had already promised progress.

The branch most mocks skip

A generated ElevenLabs integration usually proves this sequence:

GET  /v1/voices                    -> 200
POST /v1/text-to-speech/{voiceId}  -> 200

The fixture is green forever. It does not answer:

What happens when voice discovery succeeds but generation is throttled?
Does the client retry immediately?
Does the SDK already retry before your wrapper retries?
Does the UI create several concurrent generation jobs?
Is there a maximum attempt count?
What happens when no Retry-After header is present?

Those are client-policy questions. Burning production quota until ElevenLabs returns 429 is an expensive way to discover the answers.

A 429 is not permission to retry forever

Rate-limit handling needs a decision function, not a recursive catch:

type RetryDecision =
  | { action: "wait"; delayMs: number }
  | { action: "stop"; reason: string };

function decide429(
  response: Response,
  attempt: number,
  remainingMs: number
): RetryDecision {
  if (attempt >= 3) {
    return { action: "stop", reason: "retry budget exhausted" };
  }

  const retryAfter = response.headers.get("retry-after");
  const fallbackMs = Math.min(1000 * 2 ** attempt, 8000);
  const delayMs = retryAfter
    ? parseRetryAfter(retryAfter)
    : fallbackMs;

  if (delayMs > remainingMs) {
    return { action: "stop", reason: "deadline exceeded" };
  }

  return { action: "wait", delayMs };
}

The important assertions are:

generation_attempts <= 3
voice_list_calls == 1
no duplicate UI jobs
fallback backoff used when Retry-After is absent
controlled error returned when the retry budget ends

Do not assert only that the client eventually threw. A tight loop can throw after hammering the provider twenty times.

Watch for stacked retries

Many SDKs retry transient failures internally. If your application wrapper also retries, the budgets multiply:

SDK attempts:          3
application attempts:  3
actual HTTP requests:  9

That is why the test needs a request count. Pick one layer to own the policy, or coordinate the limits explicitly.

The failure can get worse in a browser. A disabled button that re-enables too early allows the user to start another retry tree while the first is waiting.

Force the real workflow shape without an API key

FetchSandbox ships an ElevenLabs twin with a curated text_to_speech workflow:

GET /v1/voices to discover available voices
Select the returned voice_id
POST /v1/text-to-speech/{voice_id}

Under the rate_limited scenario, only the textToSpeech operation changes:

rate_limited:
  overrides:
    - operation_id: textToSpeech
      response_status: 429
      error_code: rate_limit_exceeded
      error_detail: "Rate limit exceeded. Please try again later."

The first step still succeeds. The generation step returns the provider-shaped 429. The configured response intentionally has no Retry-After, so this scenario tests your documented fallback backoff and retry ceiling rather than server-directed waiting.

No ElevenLabs API key and no quota consumption are involved.

With FetchSandbox MCP in Cursor or Claude:

Run elevenlabs text_to_speech under rate_limited.
Verify voice discovery succeeds and generation returns 429.
Count every generation attempt, prove the voice list is not fetched
again, and confirm the client stops at its retry budget.
Give me the run receipt.

The receipt provides the request sequence and exact failure. Your app-level test supplies the clock and UI assertions.

Make backoff deterministic

Do not make CI literally sleep through production delays. Inject time:

type RetryClock = {
  now(): number;
  sleep(ms: number): Promise<void>;
  random(): number;
};

Production uses the real clock. Tests use a fake clock and record requested delays:

attempt 1 -> 429 -> requested sleep 1000ms
attempt 2 -> 429 -> requested sleep 2000ms
attempt 3 -> 429 -> stop

You can prove exponential backoff, jitter bounds, cancellation, and the total deadline without adding seconds to every CI run.

Local first, pipeline next

Ask the coding agent to run the twin while it writes the policy. Then keep the same scenario in CI:

fetchsandbox run <sandbox-id> text_to_speech \
  --scenario rate_limited \
  --json

The local receipt is useful during review. The pipeline prevents a future refactor from changing maxAttempts = 3 into unbounded recursion.

Questions people ask

How can I test ElevenLabs rate limits without using quota?

Point the integration at a service twin and force textToSpeech to return 429. This exercises the client contract without sending audio-generation requests to ElevenLabs.

Should I always use `Retry-After`?

Honor a valid Retry-After when the provider sends one, subject to your own deadline and attempt cap. When it is absent, use a documented capped backoff with jitter. Test both branches separately.

Should a 429 restart the whole workflow?

No. Resume from the safe failed operation. In this workflow, do not fetch voices again or create a second local generation job merely because text-to-speech was throttled.

Is rate limiting the same as exhausted quota?

No. A temporary rate limit is generally pause-and-retry. A hard quota or billing limit is stop-and-alert. OpenAI, for example, can use HTTP 429 for both while distinguishing them with error codes such as rate_limit_exceeded and insufficient_quota.

Does FetchSandbox replace ElevenLabs testing?

No. Use the twin for repeatable negative paths and CI. Use ElevenLabs afterward for final credentials, model availability, audio quality, and real account limits.

The evidence to attach

Require a receipt showing one successful voice lookup followed by the forced 429, plus an app assertion showing the exact retry count and requested delays.

The canonical guide covers mid-workflow 429 testing without partner quota. Connect the twins through FetchSandbox MCP.

Your PayPal Refund Worked. Your Lovable App Says It Failed.

FetchSandbox — Mon, 07 Sep 2026 13:26:57 +0000

Your app called PayPal's refund endpoint. PayPal completed the operation, but the 201 Created response never reached your server.

The app retries and receives 422 CAPTURE_FULLY_REFUNDED. If the handler treats every non-2xx response as a failed refund, your customer and support team now see opposite versions of reality.

This guide shows the production-safe behavior and how to test it before using a real payment.

What should a PayPal refund handler do after a timeout?

Reuse the same PayPal-Request-Id, then reconcile PayPal's state before marking the refund failed.

PayPal uses PayPal-Request-Id as the idempotency key for REST POST operations. One refund operation should have one stored request ID:

type RefundRecord = {
  id: string;
  captureId: string;
  paypalRequestId: string;
  status: "pending" | "completed" | "reconcile_required" | "failed";
};

Send that ID on the first attempt:

const result = await fetch(
  `${PAYPAL_API}/v2/payments/captures/${refund.captureId}/refund`,
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${accessToken}`,
      "Content-Type": "application/json",
      "PayPal-Request-Id": refund.paypalRequestId,
    },
    body: JSON.stringify({
      amount: {
        currency_code: "USD",
        value: "25.00",
      },
    }),
  }
);

If the request times out, send the same request ID again. Do not create a new UUID per attempt.

Why does PayPal return `CAPTURE_FULLY_REFUNDED`?

It means the capture's refundable balance is already zero. Possible causes include:

the first request worked but its response was lost
another support tool issued the refund
the PayPal dashboard issued it
several partial refunds already reached the captured total

The response shape is carried inside a broader 422:

{
  "name": "UNPROCESSABLE_ENTITY",
  "details": [
    {
      "issue": "CAPTURE_FULLY_REFUNDED",
      "description": "The capture has already been fully refunded."
    }
  ]
}

Do not branch on status code alone. 422 can also mean the amount exceeds the remaining balance, a chargeback blocks the refund, or the account cannot perform the operation.

Parse details[].issue, then choose the business response.

The correct state transition

When the issue is CAPTURE_FULLY_REFUNDED, stop automatic retries and move the local operation to reconcile_required.

if (response.status === 422) {
  const body = await response.json();
  const issues = body.details?.map(
    (detail: { issue: string }) => detail.issue
  ) ?? [];

  if (issues.includes("CAPTURE_FULLY_REFUNDED")) {
    await markReconcileRequired(refund.id);
    await reconcilePayPalRefund(refund);
    return;
  }
}

Reconciliation should confirm the external refund ID, amount, currency, and status before completing the local row. Avoid changing CAPTURE_FULLY_REFUNDED directly into success because PayPal may have been updated by a different system.

The invariant is:

PayPal has refunded the intended amount
AND the local operation points to that external state
AND another retry cannot issue or record the refund again

How do I test this in a Lovable or Bolt app?

Use a stateful PayPal service twin to force the failure before deployment.

FetchSandbox includes a curated PayPal Payments workflow called capture_and_refund. Its normal path:

Reads capture 2GG279541U471931P
Requests a partial refund of $25.00 USD
Expects 201 Created
Emits PAYMENT.CAPTURE.REFUNDED

The refund_not_allowed scenario changes the second step to:

response_status: 422
error_code: CAPTURE_FULLY_REFUNDED
error_detail: "The capture has already been fully refunded."

Add FetchSandbox MCP to Cursor, Claude, or another MCP-capable agent and ask:

Run paypal-payments capture_and_refund with refund_not_allowed.
Inspect my handler for the exact 422 issue. Prove it stops retries
and reconciles before reporting a failure. Return the receipt URL.

The run receipt records the request sequence and exact error contract. Your app-level assertion checks the database and UI.

For CI:

fetchsandbox run <sandbox-id> capture_and_refund \
  --scenario refund_not_allowed \
  --json

This gives the generated integration a failure-path acceptance test instead of relying on a code reviewer to infer behavior from the happy path.

Can Bolt preview receive PayPal webhooks?

Not directly. PayPal sends webhooks to a publicly reachable HTTPS endpoint, while Bolt's browser-based preview is not a public webhook destination. Deploy to Bolt Cloud, Netlify, or another host for final PayPal webhook connectivity testing.

The service twin handles a different job: it lets the agent exercise provider state, API errors, and expected webhook events before that deployment. Use both layers:

FetchSandbox for repeatable failure branches during development
PayPal sandbox for final credentials and webhook connectivity
Production only after both paths pass

Does a service twin replace an API mock?

No. A mock is useful when a component needs a shaped response. A twin is useful when correctness depends on what happened in earlier calls.

Refund testing needs state:

captured amount
- previous partial refunds
= remaining refundable amount

That is why CAPTURE_FULLY_REFUNDED is a lifecycle test rather than a fixture test.

Pull-request checklist

Before merging an AI-generated PayPal refund flow, attach evidence that:

one refund operation stores one PayPal-Request-Id
timeout retries reuse that ID
the handler parses details[].issue
CAPTURE_FULLY_REFUNDED stops automatic retries
local state reconciles before the UI reports success or failure
the pipeline can reproduce the same 422 path

The complete canonical guide is Test PayPal Refunds in Lovable Before Production. For the wider workflow, see integration testing for AI-built apps.

Your AI builder shipped the Stripe code in an afternoon. Verifying it took a week.

FetchSandbox — Sun, 06 Sep 2026 04:20:21 +0000

A friend shipped a booking app last month. Lovable built the whole thing, Stripe Checkout included, in something like an afternoon. It looked finished. It was finished, in the sense that you could pay and get a confirmation email.

Then a customer got charged twice for one booking.

Not a double-click. One payment, one payment_intent.succeeded, delivered twice, because Stripe retries. The handler ran twice and created two bookings. Nobody caught it in review, and here is the uncomfortable part: the code was fine on the happy path, and nobody reviewing it had written a line of it.

That is the actual shape of the problem right now. Build time collapsed. Verification time did not.

The generated code is not the problem

This is where I expected to find sloppy AI output, and I didn't. The handler read exactly like something a competent developer would write on a first pass:

app.post('/webhook', async (req, res) => {
  const event = stripe.webhooks.constructEvent(req.body, sig, secret);

  if (event.type === 'payment_intent.succeeded') {
    await createBooking(event.data.object.metadata.booking_id);
    await sendConfirmation(event.data.object.receipt_email);
  }

  res.json({ received: true });
});

Signature verified. Correct event type. Returns 200. It will pass code review and it will pass a smoke test, because the first delivery does exactly what it should.

There is no idempotency key anywhere in it. The agent was never asked "what happens on the second delivery," so it never answered that question. Neither did the reviewer, because you cannot see a retry in a diff.

Why the usual tools miss it

Mocks return the response you configured. A mock does not decide to retry you. That is the whole point of a mock, and it is also why it cannot catch this class of bug.

Staging proves the happy path against real credentials. To see a duplicate delivery you have to wait for Stripe to genuinely retry, which means causing a timeout on purpose and waiting out a backoff. Nobody does this on a Tuesday.

stripe trigger fires a fresh, well-formed event. Useful, but every trigger is a first delivery. The bug lives in the second one.

So the failure mode is invisible to all three, and it surfaces when real money moves.

Force the second delivery

What I actually wanted was a Stripe that behaves like Stripe, including the annoying parts, on demand. That is what a service twin is: stateful, so a created PaymentIntent can be read back later, and scriptable, so you can ask for the retry instead of waiting for it.

FetchSandbox runs as an MCP server, so the agent that wrote the integration can drive it. In Cursor or Claude:

Run the Stripe accept_payment workflow, then re-run it under the
webhook_retries scenario. Tell me how many bookings exist afterwards
and give me the receipt URL.

webhook_retries delivers each webhook once, then replays it twice with the same upstream event id at backoff intervals, which is the behaviour that matters. A handler deduping on a per-delivery header still fails here, because that header changes on every retry while event.id does not.

The run came back with three bookings for one payment. Not an opinion about the code, a count.

The fix is the boring one:

if (await alreadyProcessed(event.id)) {
  return res.json({ received: true });
}
await recordProcessed(event.id);

Then re-run the same scenario and the count stays at one. That buggy-to-fixed flip is the thing worth having, because "the agent says it fixed it" and "the retry no longer double-books" are different claims.

The part that makes it reviewable

Every run produces a receipt at a shareable URL: the requests in order, the state the twin held, the webhook events including the replays, and a verdict. The verdict is separate from the HTTP status on purpose, so a run can return 200 at every step and still come back unproven.

That distinction is what makes this useful when you didn't write the code. You are no longer reviewing an unfamiliar diff and hoping. You are reading evidence that a specific failure was forced and handled. Put the URL in the PR.

The same run works from the CLI when you want the pipeline to enforce it rather than a person remembering:

fetchsandbox run <sandbox-id> accept_payment \
  --scenario webhook_retries --json

Local proof while building, the same check gating merges. The failure branch becomes a required step instead of a thing you meant to test.

Beyond Stripe

Payments are where it bites hardest, but the pattern is identical anywhere an integration has a lifecycle. Paddle, Resend, Twilio, Clerk, Descope, and AgentMail have curated workflows and failure scenarios; the wider catalogue covers 50+ APIs generated from their OpenAPI specs. Same loop each time: run the flow, force the failure, keep the receipt.

Setup is one MCP config block, and there is more on the approach for AI-built apps if you want the longer version.

The actual question

I keep meeting people whose apps went from idea to paying customers in a weekend, and whose integration testing story is "staging looked fine."

So, genuinely: what are you doing here? Is anyone verifying the retry, the dropped webhook, and the mid-flow auth failure before production, or is the honest answer that you find out from a support ticket? I am more interested in what people actually do than what we all agree we should do.

undefined === undefined — the auth bypass your AI wrote into your checkout

FetchSandbox — Thu, 13 Aug 2026 17:40:08 +0000

TL;DR

An auth check that uses === where both sides can be undefined is fail-open — a missing config turns it from locked to open.

The one secret missing from .env.example was the internal auth token. Unset in a deploy, undefined === undefined let every anonymous request through.

Default to deny: validate types, reject empty, compare in constant time, and write the test that sends no credentials with the env var unset.

The coding agent handed me an auth middleware. It passed review. I almost shipped it.

function protect(req, res, next) {
  if (req.headers['x-internal-token'] === process.env.INTERNAL_API_TOKEN) return next();
  return requireAuth()(req, res, next);
}

Four lines, and it reads fine. An internal service calls with a shared token and skips the login flow; everyone else falls through to real auth. Then I checked what happens when the token isn't set.

What the check actually did

INTERNAL_API_TOKEN was the one secret missing from .env.example. Every other key was there — Stripe, Clerk, Paddle — but not this one. So on a deploy where nobody thought to set it, process.env.INTERNAL_API_TOKEN is undefined.

Now a normal browser request comes in. It doesn't send an x-internal-token header, so req.headers['x-internal-token'] is also undefined.

undefined === undefined → true → return next().

Auth bypassed. Every anonymous request to /checkout is treated as a trusted internal call. The endpoint is safest when the token is set and wide open when it's missing — which is exactly backwards. A misconfigured auth check should get more restrictive, not less.

And there's a quieter problem even when the token is set: === on a secret isn't constant-time. It short-circuits on the first mismatched byte, so response timing leaks the token one character at a time.

The real check

Fail closed:

const crypto = require('crypto');

function hasInternalToken(req) {
  const expected = process.env.INTERNAL_API_TOKEN;
  if (typeof expected !== 'string' || expected.length === 0) return false; // no token configured → deny
  const provided = req.headers['x-internal-token'];
  if (typeof provided !== 'string' || provided.length === 0) return false;
  const a = Buffer.from(provided), b = Buffer.from(expected);
  if (a.length !== b.length) return false;
  return crypto.timingSafeEqual(a, b);
}

function protect(req, res, next) {
  if (hasInternalToken(req)) return next();
  return requireAuth()(req, res, next);
}

No configured token means no bypass. An empty or missing header means no bypass. The compare is constant-time, and length is checked first (timingSafeEqual throws on length mismatch). Then add INTERNAL_API_TOKEN to .env.example so it can never be silently omitted again.

Why agents write it this way

The happy path looks correct. Token set, caller sends the right one, x === y is true — review sees a plausible auth check and moves on. The model optimizes for "works when configured," and === fails open by default. It never had to reason about the unset case, because the unset case isn't in the example the code was written against.

Humans do this too — the fail-open default, the === on a secret, the config that's "obviously" always set. Agents just do it faster and ship it greener.

Fail closed, and prove it

The tell isn't in the code. It's in the test you didn't write. Send a request with no credentials and the env var unset, and assert it's rejected:

delete process.env.INTERNAL_API_TOKEN;
const res = await request(app).post('/checkout').send({ seats: 5 });
expect(res.status).not.toBe(200); // must be 401/302 — not "welcome in"

If an unauthenticated request with no token configured gets a 200, your auth is open — and no amount of green on the happy path will tell you. The bug lives entirely in the case the tests never exercise.

What I changed in the habit

Auth defaults to deny. Every branch that grants access starts from "no."
Validate both sides — type is string, length > 0. undefined === undefined is not authentication.
Constant-time compare for any secret (crypto.timingSafeEqual), never ===.
Write the misconfigured-env test — unset the token, send nothing, assert rejected.
Every secret the code reads goes in .env.example. A missing one isn't a config gap; here it was the whole lock.

I found this the way I find most of them: reproduced it on the real code — an anonymous request returned 200 — applied the fix, and confirmed it flipped to a 302, with FetchSandbox. The bug was never in the happy path. It was in the case the code never had to handle.

Which is the rule every auth check should start from: fail closed.

Green passed. The fix granted zero seats.

FetchSandbox — Tue, 11 Aug 2026 14:05:17 +0000

TL;DR

"Did the bug stop?" is a weak invariant. An over-suppressing fix — grant nothing — also stops the bug.

Assert the exact correct end state: after N identical deliveries, seats == the purchased amount. Not more. Not zero.

A verifier that cannot reject a deliberately broken fix is not a verifier. It is a green light.

The coding agent handed me a patch. CI went green. I almost merged it.

The original bug was ugly and familiar. A Stripe webhook handler granted seats on invoice.paid (or whatever your equivalent is — checkout.session.completed, customer.subscription.updated, pick your poison). It was not idempotent. Stripe retried. The handler granted again.

A five-seat purchase became 5, then 10, then 15. Same event. Same customer. Three deliveries.

That is the bug everyone warns you about. At-least-once delivery. Dedupe on event id. INSERT … ON CONFLICT DO NOTHING. You have heard the sermon.

So I asked the agent to fix it. It wrote a patch. My verifier ran the retry series and graded the result green.

Then I looked at the seats.

delivery     buggy handler     agent "fix"      what we wanted
1            5                 0                5
2            10                0                5
3            15                0                5

The count had stopped growing. True. It had also stopped granting.

Customers who paid got nothing. Including on the first, legitimate delivery. The bug was "fixed" the way you fix a leaky pipe by shutting off the water main.

What the check actually asserted

The verifier was not stupid in a cartoon way. It did replay the webhook. It did look at a side effect. It did not just grep the diff for idempotent.

It asserted the thing I had complained about: the count should not keep climbing.

Something like this:

// Weak: "the bug stopped"
const series = seatsAfterEachDelivery(handler); // e.g. [0, 0, 0]

expect(series[2]).toBeLessThanOrEqual(series[0]);
expect(new Set(series).size).toBe(1); // "stable across retries"

[5, 10, 15] fails. Good.

[5, 5, 5] passes. Also good.

[0, 0, 0] passes. That is the hole.

Any monotonicity check, any "didn't grow," any "delta is zero after the first call" that never pins the value will accept the over-suppressing patch. Delete the grant. Swallow the event. Return 200 and write nothing. The graph is flat. Green.

If you have ever written expect(errors).toHaveLength(0) and then watched someone delete the code that could error, you have met this family.

The real invariant

Idempotency is not "nothing happens twice." It is "the same request leaves the system in the same correct state."

For this handler, after N identical deliveries of a five-seat purchase, seats must equal exactly five. Not fifteen. Not zero.

// Exact: after N identical deliveries, seats == purchased amount
const series = seatsAfterEachDelivery(handler);

expect(series).toEqual([5, 5, 5]);

That one line rejects [5, 10, 15] and [0, 0, 0]. It accepts [5, 5, 5].

When I switched the assert, the zero-grant patch went red. The agent tried again. The patch that actually deduped — grant once, ignore the retries — produced [5, 5, 5] and stayed green.

Same deliveries. Same metric. Different question.

"Did it stop doing the bad thing?" vs "Is the world in the state a correct implementation would leave it in?"

Why agents fail this way

I do not think the model was being clever. I think it was being literal.

You said: stop double-granting. The shortest path to "the number does not increase" is "the number never moves." Skip the write. Make the insert always look like a conflict. Short-circuit before grantSeats. Plenty of ways to get a flat series.

Humans do this too under time pressure. Feature flags that default off. if (false) around the dangerous block. Tests that mock the collaborator into a no-op. Agents just do it faster, and they will happily stop at the first green.

Your CI is an optimization target. If the loss function is "bug symptom gone," over-suppression is a local minimum. If the loss function is "exact end state," that minimum disappears.

This is not a Stripe trivia item. It is any side-effecting handler you let an agent touch:

A refund webhook that "fixes" double-refunds by refunding $0.
A provisioner that "fixes" duplicate users by creating none.
A retry queue that "fixes" duplicate emails by sending nothing, including the first time.

The shape is always the same. Symptom: too much. Naive fix: zero. Correct fix: once.

Positive control, negative control

Here is the part I now require before I trust a verifier — mine, yours, an agent's, a CI job.

Positive control. A known-good implementation must pass. For me that was the idempotent grant: [5, 5, 5]. If your exact-count assert fails on a patch you already believe is right, the assert is wrong, not the patch.

Negative control. A known-bad implementation must fail. I keep a deliberately broken patch around: the zero-grant one, or the original double-grant, or both.

expect(seatsAfterEachDelivery(buggy)).toEqual([5, 5, 5]);
// fail: [5, 10, 15]

expect(seatsAfterEachDelivery(zeroGrant)).toEqual([5, 5, 5]);
// fail: [0, 0, 0]   ← this is the control most suites skip

expect(seatsAfterEachDelivery(idempotent)).toEqual([5, 5, 5]);
// pass

If the zero-grant still greens, you do not have a proof. You have a check that the symptom you first noticed got quieter.

I used to stop at the positive control. "The good fix passes, ship it." That is how [0, 0, 0] got a green. The suite had never been shown a lying patch.

This is the same idea as a mutation test, just less academic. You do not need a framework. You need one broken cousin of the fix, and a gate that refuses to call itself a verifier until that cousin fails.

What I changed in the habit

I still replay the webhook three times. That part was never the mistake. The mistake was scoring the replay with a bound instead of an equality.

The checklist I use now, when an agent "fixes" a production-shaped bug:

Write the end state in English first. "After three identical invoice.paid deliveries for a 5-seat price, seat_limit == 5."
Put that number in the assert. Not <=. Not "unchanged after first." The number.
Run the original bug. It must fail that assert.
Run a spiteful fix (no-op, always-conflict, grant-zero). It must fail too.
Then run the agent's patch.

Step 4 is the one I had skipped. It is also the cheapest. You can write the no-op in thirty seconds. If your suite cannot fail it, do not let the suite pass the agent.

I hit this while building FetchSandbox, replaying Stripe deliveries against persistent seat state instead of a one-shot fixture.

The transferable rule is not about Stripe, and it is not about my tooling. When you verify an AI-written fix, "did the bug stop?" is the wrong question. Ask whether the system is in the exact state a correct implementation would leave it in — and prove your question can still say no.

You can't code-review a webhook retry

FetchSandbox — Tue, 04 Aug 2026 17:51:20 +0000

My coding agent wrote a Stripe webhook handler a few weeks ago. Signature check, event type check, fulfillment call, clean 200. The diff read like something I'd write on a good day. I approved it in about ninety seconds.

app.post("/webhooks/stripe", async (req, res) => {
  const event = verifySignature(req);
  if (event.type === "charge.succeeded") {
    await creditCustomer(event.data.object);
  }
  res.sendStatus(200);
});

Every line is correct. And the first time Stripe delivers that event twice — which it's allowed to do, and eventually will — the handler credits the customer twice.

Reading can't catch it

The bug isn't on any line, so no amount of reading finds it. Each statement is fine on its own. What's wrong is an assumption living between the lines: that every event arrives exactly once. Stripe promises at-least-once delivery. Retries and duplicates are documented, normal behavior.

Code review checks the diff against the traffic you can imagine. I imagined one clean charge.succeeded. So did the agent — the quickstart code it learned from imagined one too.

CI passed for the same reason

My tests replayed the events I thought of. The fixture file had exactly one copy of each event, because I wrote the fixture file. Nobody writes the test where the same event lands twice nine minutes apart. The suite was my assumptions checking my assumptions.

I spent three years on the developer platform of a very large payments company. This exact bug got past good reviewers more times than I can count. It was never a talent problem. Reading is the wrong tool for this class of bug.

The review that actually works

What caught it was running the failure. Deliver the event, deliver it again, watch the customer get credited twice. Add the dedupe on the event ID, run it again, watch it hold. Ten minutes, and the review went from "looks right" to "proved right."

That loop — reproduce the failure, fix it, rerun, keep the receipt — is what I built FetchSandbox to run from your IDE over MCP. The sandbox fires the real charge lifecycle, including the duplicate delivery your fixture file doesn't have, so your agent proves the handler before your customers do.

If you'd rather judge it on real code than my word, there's a webhook-dedupe bug planted in a Stripe app in our open playground, waiting to be caught: github.com/fetchsandbox/playground.

Why Paddle's subscription.activated arrives before subscription.created

FetchSandbox — Thu, 30 Jul 2026 13:58:08 +0000

You'd think events fire in the order things happen. They don't.

I was building a Paddle integration last week. Subscription billing, nothing fancy. Customer clicks buy, Paddle handles checkout, my app gets webhooks and updates the database.

The flow should be simple:

Customer completes checkout
subscription.created fires
subscription.activated fires
My app inserts a row on .created, updates status on .activated

That's what I built. It worked great in my head.

What actually happened

In production, subscription.activated arrived before subscription.created about 30% of the time.

My handler did a database insert on subscription.created:

case 'subscription.created':
  await db.insert(subscriptions).values({
    paddleId: event.data.id,
    status: 'created',
    customerId: event.data.customer_id,
  });
  break;

And an update on subscription.activated:

case 'subscription.activated':
  await db.update(subscriptions)
    .set({ status: 'active' })
    .where(eq(subscriptions.paddleId, event.data.id));
  break;

When .activated arrived first, the update found zero rows. No error, no exception. The WHERE clause just matched nothing. The update silently did nothing.

Then .created arrived and inserted the row with status created. But the .activated event was already gone. So the subscription was stuck in created status forever.

Customers had paid. Paddle showed them as active. My app showed them as pending. Support tickets started coming in.

Why this happens

Paddle does not guarantee webhook delivery order. Their docs mention it briefly but it's easy to miss when you're focused on the API endpoints.

The events are fired from different internal services. subscription.created comes from the subscription service. subscription.activated comes from the billing service after payment confirmation. They are async. They race.

This is not unique to Paddle either. Stripe has the same problem with payment_intent.created vs charge.succeeded. Most payment providers have some version of this.

The fix

The handler needs to be idempotent and order-independent. Every event should be able to create or update:

case 'subscription.created':
case 'subscription.activated':
  const status = event.event_type === 'subscription.activated' 
    ? 'active' : 'created';

  await db.insert(subscriptions)
    .values({
      paddleId: event.data.id,
      status,
      customerId: event.data.customer_id,
    })
    .onConflictDoUpdate({
      target: subscriptions.paddleId,
      set: { 
        status: sql`CASE WHEN ${status} = 'active' THEN 'active' ELSE ${subscriptions.status} END`
      },
    });
  break;

The key parts:

Both events can create the row if it doesn't exist
On conflict, active always wins over created regardless of arrival order
No silent failures, no missing updates

Testing this is the real problem

The ordering bug is easy to fix once you know about it. The hard part is reproducing it during development.

You can't control the order Paddle sends webhooks. You can't make .activated arrive first on demand. In testing you might run through the flow 20 times and the events always arrive in order. Then in production with real network latency and load, they don't.

I ended up testing this by sending the webhook events manually in the wrong order against a local sandbox. activated first, then created. Immediately saw the bug. Fixed it in 10 minutes.

The debugging in production took 4 hours.

If you're integrating Paddle or any payment provider with webhooks, test with events arriving in every possible order. Not just the happy path order from the docs.

Test Paddle webhook ordering in a sandbox →

The takeaway

Webhook events are not a queue. They are concurrent messages from different services that happen to be about the same thing. Your handler has to treat every event as potentially the first one it sees for that resource.

If your handler has an insert for one event type and an update for another, you have this bug. You just haven't hit it in production yet.

Webhook handlers that silently return 402: the event ordering bug most test suites miss

FetchSandbox — Tue, 21 Jul 2026 17:40:10 +0000

How to prove a handler is order-safe using permutation fuzzing

You're testing your Paddle webhook handler. You've got a test for subscription.created and subscription.activated, and maybe another one where you send them out of order. Looks good. All green. But weeks later, a customer hits a 402 on subscription.activated. No error in your logs. No alert. Just a failed charge and a confused user.

The problem isn't your test suite, it's the order of events.

A Paddle webhook handler that does an INSERT on subscription.created and an UPDATE on subscription.activated will silently return 402 when subscription.activated arrives first. The row doesn't exist yet. No error is raised. But if you send them in the "happy path" order, it works. Your test suite never sees the failure because it only runs one sequence. The bug is invisible until it hits production.

To prove a handler is order-safe, we built a permutation fuzzer in fetchsandbox MCP. It fires the same events in every permutation, including duplicates, and checks if the final state is the same in all of them. If it is, the handler is order-safe. If not, it returns the exact sequence that breaks it.

Here's what it found for the Paddle handler above:

When you send subscription.activated before subscription.created: the handler returns a 402.
When you send them in the "happy path" order: it returns a 200.
The fuzzer returns order_independent=False and shows you the diverging sequence.

After fixing the handler to use an upsert instead of separate INSERT and UPDATE, the fuzzer returns order_independent=True across every permutation and duplicate.

If you test API integrations in sandboxes constantly, you've hit this one too. I run it in Cursor every time I test a new webhook integration.

The fuzzer is in fetchsandbox MCP. It reads final state after each permutation, and reports order_independent=True only when every ordering converges to the same final state.

If you're trying to find webhook ordering bugs, or prove a handler is order-safe, this is the test you didn't know you needed.

Read the full spec for Paddle webhook testing at Paddle sandbox. Learn how fetchsandbox MCP works at fetchsandbox MCP.

We planted a Descope privilege-escalation bug — can your coding agent catch it?

FetchSandbox — Fri, 10 Jul 2026 18:39:39 +0000

We open-sourced a repo with a bug planted on purpose: github.com/fetchsandbox/playground.

The bug is in apps/descope — a small FastAPI "Agent Gateway" where AI agents exchange a Descope access key for a scoped session. The flaw: the exchange endpoint trusts whatever scopes the client requests. A read-only agent key can ask for users:write and get it.

This is the privilege-escalation shape that ships constantly in agentic auth. The token exchange returns 200, the happy path works, and nothing ever compares the granted scope against what the key was actually granted.

The 20-minute test drive

Two tasks, both run from your IDE (Cursor, Claude Code, or any MCP-capable editor). No Descope account, no API keys — the workflows run against FetchSandbox's hosted Descope sandbox over MCP, and each app ships a .mcp.json already wired.

Task 1 — greenfield. apps/descope-onboarding is a tiny notes app with placeholder auth. Ask your agent to add Descope OTP sign-up, but with one constraint: prove the OTP + session flow in the sandbox before writing any code, then propose the diff.

./fetchsandbox I'm adding Descope OTP sign-up to this app — prove the Descope
OTP + session flow in the sandbox before writing any code, then propose the
diff. I'll decide whether to apply.

Task 2 — brownfield. Point the agent at the Agent Gateway and ask it to audit:

./fetchsandbox our agent access-key exchange might be handing out more scope
than the key was granted — audit the descope agentic auth

What a real catch looks like

Static review is not the bar. "This looks vulnerable" is a guess. The bar is:

the escalation is reproduced — read-only key in, users:write session out
the proof shows buggy vs fixed on actual Descope routes (/v1/...)
there's a receipt URL — an openable run trace, not a claim in chat

Auth bugs live in the lifecycle: replayed magic links, expired sessions, JWTs that were decoded instead of verified, scope grants nobody re-checked. Mocks return clean 200s for all of these. That's the gap the playground is designed to expose.

The other planted bugs

If Descope isn't your stack, the repo also has broken Stripe (webhook dedup keyed on the wrong header — events processed 2–3×), Resend (bounces silently dropped, users stay "active"), Clerk (session validation skipped on one endpoint), and a few more. Each app is ~50–150 lines of Python.

The part where you tell us it fell flat

Findings go back as a PR — there's a FINDINGS_TEMPLATE.md in the repo. Paste your agent's session, the receipt URLs, and your honest reaction. Merged PRs show up on your GitHub contribution graph.

We explicitly want the failure reports: MCP wouldn't connect, the agent caught nothing, the proof felt fake. An honest "it didn't work" beats a polite green checkmark.

Start here: TESTING.md.

How to test Descope auth without real keys

FetchSandbox — Wed, 08 Jul 2026 14:04:28 +0000

Title options:

How to test Descope auth without real keys
How to test Descope passwordless auth without a project

Descope is easy to start with, but the part I would test first is not the OTP screen or the magic-link email.

It is what your app does with the session JWT after Descope returns it.

FetchSandbox has a Descope sandbox for the flows most apps wire up first:

email OTP signup
email magic-link sign-in
session refresh
agent/access-key exchange

No real Descope project. No real keys. No inbox setup.

The useful part is that the sandbox models the failure cases too: wrong OTP, expired session, replayed magic link, and the big one: accepting a forged session JWT because the app decoded it instead of verifying it.

Here is the concrete flow I would test.

Send a magic link:

POST /v1/auth/magiclink/signin/email

Verify the one-time token:

POST /v1/auth/magiclink/verify

The sandbox returns the shape your app should care about:

{
  "sessionJwt": "...",
  "refreshJwt": "...",
  "user": {
    "userId": "U2..."
  }
}

Call your protected route with the sessionJwt.

This is where the bug usually lives.

Bad handlers do something like:

const claims = jwt.decode(sessionJwt);
if (claims.role === "admin") allow();

That accepts whatever claims are inside the token. A forged alg: none token can become role=admin if the handler never checks the signature.

The fixed version verifies the session JWT against Descope's JWKS, or uses Descope's SDK validation path. It should reject alg: none, reject bad signatures, cache JWKS, and refresh on kid mismatch.

The sandbox route for this bug is meant to prove that difference:

forged unsigned token -> 401
valid signed session token -> 200

That is the whole point. Do not just test "magic link works." Test that the session you trust is actually verified.

You can also test refresh behavior:

POST /v1/auth/refresh
GET /v1/auth/me

If refresh returns 401, send the user back through sign-in. Do not keep rendering authenticated UI from a decoded-but-unverified token.

Docs are here if you want the exact Descope sandbox flows: https://fetchsandbox.com/docs/descope

Our CI mocked Stripe. Production still broke on step two.

FetchSandbox — Tue, 30 Jun 2026 14:23:58 +0000

Green CI. Broken staging. Sound familiar?

Our pipeline mocked POST /v1/payment_intents and asserted 200. Merge button enabled. First real checkout in staging failed because the handler never stored the PaymentIntent ID — step two of the webhook path read undefined.

Mocks proved shape. Not lifecycle.

What unit tests miss

CI check	What it proves	What it skips
Mocked `fetch()`	Request JSON looks right	Step 2 cannot read step 1's ID
Snapshot tests	Handler code unchanged	Webhook branch never runs
Manual smoke doc	Someone remembers sometimes	Agents ship faster than the checklist

The bug class: IDs do not chain across steps. Webhooks fire on mutations your mock never triggers.

What we run now — MCP locally, same workflow in CI

Before an agent touches payment code, we prove the provider flow in the IDE via FetchSandbox MCP:

quickrun stripe / accept_payment
→ create PaymentIntent
→ confirm / capture path
→ read back state

That is the contract the integration must satisfy — not a paragraph in the PR description.

Then CI runs the same curated workflow headless:

# .github/workflows/api-integration.yml
- name: Prove Stripe integration before deploy
  run: npx fetchsandbox run stripe --all --json

Exit code 0 → workflows passed, merge allowed.

Exit code 1 → named step failed (create_payment_intent, webhook reconcile, etc.) — PR blocked.

No staging dependency. No IP whitelist. No "works on my machine."

Why MCP belongs in the loop

Coding agents edit integration code constantly. Without a runnable proof:

The agent "fixes" the handler and moves on
CI mocks still pass
Production breaks on the path the agent never exercised

MCP gives the agent (and you) a receipt: sandbox timeline, step statuses, real provider-shaped IDs from the run — before opening the PR.

CI is the gate that keeps that proof from regressing on the next agent session.

What a workflow run actually checks

Not "does POST return 200 once."

Create a resource → mutate it → GET the same ID back
Trigger the webhook branch when state changes
Fail with a named step when auth or transitions break

That is integration testing — not HTTP cosplay.

What we stopped doing

Treating mocked unit tests as "integration covered"
Running only manual smoke before deploy
Letting agents merge Stripe/Resend/Clerk changes without a workflow receipt

Try it

Full write-up: API integration testing in CI

MCP + agent workflows: Agent API workflow testing

Install MCP in Cursor/Claude → run a Stripe workflow locally → paste the same npx fetchsandbox run step into Actions.

fetchsandbox.com · MCP setup

DEV Community: FetchSandbox

AI Code Is Cheap. Your Pull Request Still Needs Proof.

How should you verify AI-generated code before merging it?

Why is reviewing AI-written code becoming the bottleneck?

Why is a green test written by the same agent not enough?

What does FetchSandbox verify on an AI-generated fix?

What should go into the pull request?

How does the proof continue into CI/CD?

What does a proof receipt prove?

What changes when every pull request carries evidence?

Questions developers ask

Does passing CI prove AI-generated code is correct?

Should the coding agent write its own tests?

Does FetchSandbox replace human pull-request review?

Can FetchSandbox automatically comment on every GitHub pull request?

What happens when FetchSandbox cannot reproduce the bug?

Test ElevenLabs 429 Handling Without Burning API Quota

The branch most mocks skip

A 429 is not permission to retry forever

Watch for stacked retries

Force the real workflow shape without an API key

Make backoff deterministic

Local first, pipeline next

Questions people ask

How can I test ElevenLabs rate limits without using quota?

Should I always use Retry-After?

Should a 429 restart the whole workflow?

Is rate limiting the same as exhausted quota?

Does FetchSandbox replace ElevenLabs testing?

The evidence to attach

Your PayPal Refund Worked. Your Lovable App Says It Failed.

What should a PayPal refund handler do after a timeout?

Why does PayPal return CAPTURE_FULLY_REFUNDED?

The correct state transition

How do I test this in a Lovable or Bolt app?

Can Bolt preview receive PayPal webhooks?

Does a service twin replace an API mock?

Pull-request checklist

Your AI builder shipped the Stripe code in an afternoon. Verifying it took a week.

The generated code is not the problem

Why the usual tools miss it

Force the second delivery

The part that makes it reviewable

Beyond Stripe

The actual question

undefined === undefined — the auth bypass your AI wrote into your checkout

What the check actually did

The real check

Why agents write it this way

Fail closed, and prove it

What I changed in the habit

Green passed. The fix granted zero seats.

What the check actually asserted

The real invariant

Why agents fail this way

Positive control, negative control

What I changed in the habit

You can't code-review a webhook retry

Reading can't catch it

CI passed for the same reason

The review that actually works

Why Paddle's subscription.activated arrives before subscription.created

What actually happened

Why this happens

The fix

Testing this is the real problem

The takeaway

Webhook handlers that silently return 402: the event ordering bug most test suites miss

We planted a Descope privilege-escalation bug — can your coding agent catch it?

The 20-minute test drive

What a real catch looks like

The other planted bugs

The part where you tell us it fell flat

How to test Descope auth without real keys

Our CI mocked Stripe. Production still broke on step two.

What unit tests miss

What we run now — MCP locally, same workflow in CI

Why MCP belongs in the loop

What a workflow run actually checks

What we stopped doing

Should I always use `Retry-After`?

Why does PayPal return `CAPTURE_FULLY_REFUNDED`?