How it is built

Orders v2 with a payee on each purchase unit, so one checkout pays several recipients. PayPal JavaScript SDK v6 buttons, server-side capture with PayPal-Request-Id idempotency, approval links that capture on return, Payouts batches for funds reconciled with Transaction Search and the Balances API, signature-verified webhooks, and sandbox negative testing for the failure cases.

paypal/orders.tspaypal/capture.tspaypal/payouts.tspaypal/reporting.tswebhook/route.tsgift/PayPalPay.tsx

claude-opus-5-5 with adaptive thinking, vision and structured outputs validated by Zod, with server-side fallbacks. It never does the benefit math: the rules engine does.

ai/claude.tsai/tasks.tsread-bill/route.ts

ag-studio-react 3.0 with gifts and months data sources on a shared calendar, a theme built from the site tokens, a custom widget that runs the rules engine on whatever the filters leave in view, and the Studio Agent Framework running on Claude through our own adapter, with the rules engine as an extra tool.

dashboard/FamilyStudio.tsxdashboard/CheckWidget.tsxdashboard/studioAi.tsstudio-ai/translate.ts

A web service, a managed Postgres database, a Render Workflow and a cron job, all in one render.yaml. The workflow fans out one task per check (each failure case against the PayPal sandbox, each page on the product path, each public API promise) with retries, and files the run with the app; the cron job starts it nightly with the Render SDK, and /evidence can start it on demand.

render.yamlworkflows/src/main.tsworkflows/src/checks.tsstart/route.tsmonthly/route.ts

monthlyRun fans out one planMonthly task per active monthly gift, each with its own retries, so every giver's page already shows that month's split and what changed; rulebookIndex rebuilds the Elastic index from the rule files. The nightly cron starts them on the 1st and on Sundays. The workflow calls the app with CHECKS_SECRET and handles gift ids, never givers' private links.

workflows/src/main.tsworkflows/src/trigger.tsplan/route.tsrulebook/route.ts

POST /v1/search (in stock, with a price cap) from the organizer's view and the find_gift MCP tool. Giftwise maps each product's category to the rules, runs the rules engine on it paid straight to the retailer, and holds back gift cards, which SSA counts like cash when they can buy food or shelter. Without a key, a sample catalog on .example domains stands in.

lib/channel3.tsfind/route.tsmanage/ManageClient.tsx

Hybrid retrieval over the regulations, SSA's operating manual, its worked examples and the rule table: multi_match plus a semantic query on a semantic_text field with jina-embeddings-v3, fused by reciprocal rank (RRF), then the top 20 reranked by jina-reranker-v3. Claude answers from only those passages and a program checks every quote word for word. Without Elastic, an in-app BM25 ranking stands in.

lib/rulebook.tsask-rules/route.tslearn/AskRulebook.tsx

16 requests in five folders, each with tests: gift checks, a quarter's exclusions, the report and the page that checks it, the rulebook, the MCP server and its discovery documents. The same collection runs in the test suite with Newman, 20 of 20 assertions.

scripts/postman-collection.mjsscripts/run-postman.mjspostman/giftwise.postman_collection.json

Each PayPal capture posts a signed gift.received event to the organizer's webhook. A Zapier Catch Hook turns it into a text, an email, a Slack message or a spreadsheet row, with no code. HMAC-SHA256 signatures with a timestamp; private network addresses are refused.

lib/manage.tswebhook/route.ts

Bryntum Calendar 7.3 (trial) in month view. Dragging a gift to another day reruns the rules engine in the browser and lists which checks changed; a form does the same without dragging. A planner agent moves cash gifts on the calendar itself, by up to a week, so more of each falls under SSI's monthly and quarterly exclusions, and never into a month with no check. The light or dark Bryntum theme is loaded to match the site.

calendar/BenefitCalendar.tsxcalendar/model.tscalendar/schedule.tsbryntum/[file]/route.ts

@paypal/paypal-server-sdk, generated by APIMatic, creates every order (one purchase unit and payee per recipient, with a PayPal-Request-Id), with typed requests. Reads and capture are plain REST. The SDK checks each answer against its schema, and PayPal returns a captured order with several payees with an empty shipping address on each unit, which that schema turns away, so readOrder() in src/lib/paypal/orders.ts reads orders over REST. Capture in src/lib/paypal/capture.ts sends PayPal's negative-testing header for the failure cases and retries a 5xx with the same PayPal-Request-Id.

paypal/client.tspaypal/orders.ts