gainforest-bumicerts · alpha-fund-walkthrough

Alpha Fund — UX walkthrough & PDS verify

@daviddao

End-to-end run of alpha.fund.gainforest.app as a Nature Steward — login via climateai.org PDS, build a Bumicert through the 5-step wizard, and verify what actually lands on the Personal Data Server. Login + early steps work beautifully; the create flow is gated by an indexer-coverage bug that prevents the final publish.

Date: 2026-04-29 · Target: alpha.fund.gainforest.app · Account: satyam.climateai.org · Tool: agent-browser · partial

Headline result

What I tested

• Marketing landing → marketplace → leaderboard navigation
• Sign-in via the Handle tab against a non-Bsky PDS (climateai.org)
• OAuth consent + return to app, role-picker onboarding modal
• The full 5-step "Create a Bumicert" wizard (Cover · Impact · Site · Review · Publish)
• Live PDS verification via com.atproto.repo.listRecords on climateai.org
• Indexer coverage check via /api/indexer/trpc/locations.list
• Read-side rendering of an indexed Bumicert (Description, Site Boundaries, Donations, Timeline tabs)

1. Landing & first impressions

The marketing landing is the strongest part of the product. A misty forest hero, an editorial typographic mix (Cormorant Garamond italic for emphasis, neutral sans for body), and a slow scroll choreography that pays off the project's "plain backgrounds, rich experiences" design philosophy. Three feature pillars (verified · direct · decentralized), a two-card "Choose your path" split for funders vs. nature stewards, an accordion explaining what a Bumicert is, and a clean editorial footer.

01Hero. "Verified Impact Bumicerts Starts With Real Communities" — typography is doing the heavy lifting, no sub-navigation noise. Launch App / Menu in the corner.

02Three feature pillars and the start of "Choose Your Path". The split between Funders and Nature Stewards is clear without being heavy-handed.

03The "What exactly is a Bumicert?" accordion paired with a sample certificate card on the right. Good editorial pacing.

04Footer. Tagline ("Connecting communities with funders") in italic serif; quiet utility links on the right. No clutter.

2. Marketplace (/explore)

Click Launch App → routed straight to /explore. A persistent left rail (Bumicerts · Organizations · Leaderboard, plus a Manage section gated behind sign-in), a serif page-title pattern ("Discover Regenerative Impact"), search + sort controls, a horizontally scrollable tag chip strip, and a 4-up grid of project cards. Cards are dense without being noisy: image, project name, description, badges (project type), and parent platform ("Ecocertain").

05Marketplace top. Left rail is calm, the page heading uses the same serif accent as the landing.

06Card grid mid-scroll. "All filters" hint suggests there is a richer filter sheet behind the chips.

3. Sign-in flow — handle resolution

The sign-in modal opens with two tabs: Email and Handle. The Handle tab is the most considered AT-Proto sign-in I have seen — a username box plus a domain dropdown that defaults to .gainforest.id but lets you pick climateai.org, certified.app, bsky.social, or a custom server.

07Sign-in modal. Email/Handle toggle, gentle backdrop blur over the marketplace.

08Handle tab. Username field + domain selector defaulting to .gainforest.id.

09Domain dropdown — including climateai.org. The pre-curated list is the right call for an alpha audience.

10Live preview "Signing in as satyam1.climateai.org" — small touch, removes ambiguity.

$ dig +short TXT _atproto.satyam1.climateai.org
(empty)
$ curl https://satyam1.climateai.org/.well-known/atproto-did
(no response — DNS does not resolve the host)
$ curl 'https://public.api.bsky.app/xrpc/com.atproto.identity.resolveHandle?handle=satyam1.climateai.org'
{"error":"InvalidRequest","message":"Unable to resolve handle"}

11Inline error after the brief's handle fails to resolve. Clear, non-destructive — the form keeps everything I typed.

12Switched to satyam.climateai.org — the live "Signing in as …" confirms the resolved identity.

4. OAuth consent and return

Continue redirects to https://climateai.org/oauth/authorize?... — a standard AT-Proto OAuth password screen, with a security warning to verify the domain before entering the password (✓), language switcher, and a "Remember this account on this device" toggle. After the password, an authorize screen explains what the app gets: Bluesky (manage profile/posts/likes), Repository (create, update, and delete any public record), Authenticate (perform authenticated actions on any service). All three scopes have hover help.

13climateai.org PDS sign-in. Identifier is pre-filled and locked — the user only types the password.

14OAuth consent screen with three scope rows. The plain-language scope summaries are excellent.

After Authorize the page returns to /auth/complete and a role-picker modal appears: Funder, Nature Steward, or I'll decide later. I picked Nature Steward to enter the create flow.

15Onboarding modal — the only post-auth question. Editorial typography matches the rest of the app; "I'll decide later" is a humane escape hatch.

16Nature Steward landing — a "Set up your organization" form with website-based auto-generate, country, founding date, and a rich-text Tiptap editor for the description.

5. Create a Bumicert — the 5-step wizard

Skipping the org setup and clicking "Bumicerts" under Manage in the left rail (the app does not hard-block this), then "Create new" → "Get Started" → /bumicert/create/0. The wizard is genuinely well-designed: a 5-step header (Cover · Impact · Site · Review · Publish), a left form panel, a right-hand pane that splits into Preview Bumicert and Tips for this section, and a sticky bottom toolbar with Save as Draft and Continue.

17Create-bumicert hub: "Start a new application" plus "My Bumicerts" + "Pending Applications". Empty states are friendly ("You do not have any pending applications." with a confetti glyph).

18Step 1 (Cover Details). Cover image dropzone, 50-char title, default date range, work-type chips. Right-hand preview: "Please complete the first step to generate the preview."

Step 1 — Cover Details pass

Filled the title ("Pi-Eval Test Bumicert — Reforestation walk", 42/50 chars), checked Ecological Restoration + Agroforestry, kept the default date range, and uploaded a cover image (a Unsplash forest JPG). The preview pane updated live with the cover, the contributor name, and the title — and the step header gets a green check.

19Cover image uploaded. Preview pane on the right rendered immediately. Cover Details now ✓ in the stepper.

Step 2 — Impact Details pass

Two fields, both required: a Tiptap rich-text "Your Impact Story" (with image, video, headings, lists, code, quote, embed-YouTube) and a 3000-char short description with an "AI Generate" button. The 80-char short description I typed previewed correctly. Tips on the right are scenario-specific ("Tell your story in your own words…").

20Impact story written, links auto-detected (alpha.fund.gainforest.app rendered as a link).

21Short description below the rich-text. Counter shows 80 / 3000. "Generate short description with AI" button is right where you'd want it.

Step 3 — Site Details blocker

Three sub-sections: List of Contributors, Site Boundaries, Permissions. This is where the run came apart.

3a. Contributor search — finds Bsky users only

Two tabs: Search Users (typeahead) and Enter Name or ID (free-text). Searching for the string satyam in Search Users returns five real Bluesky users — none of which are the logged-in user. Searching the exact handle satyam.climateai.org (i.e. my own handle) returns "No results found."

22"satyam" — five Bluesky .bsky.social / .net hits, but the logged-in satyam.climateai.org is missing.

23Searching the exact own-handle: "No results found." Hard to think of a worse demo moment for a non-Bsky AT-Proto user.

24Adding via DID: row renders as handle.invalid @handle.invalid until the page is reloaded.

25After a reload the same DID resolves correctly to satyam.climateai.org. Same row, same data, different render.

3b. Site Boundaries — the blocker

Clicking Add a site opens a modal with three inputs: site name, GeoJSON upload (or paste), and a "Draw a site" CTA that opens a Mapbox-powered polygon drawing modal. I uploaded a tiny one-feature GeoJSON polygon and named it "Pi-Eval Test Site". The modal showed a green check + "Site added successfully". I closed the modal expecting the new site to appear in the form's list — and it didn't. "No site found." Same with a second attempt named "Pi-Eval Site v2".

26Add Site modal. Three input modes — paste, upload, or draw on a Mapbox map. Visually clean.

27GeoJSON file (226 bytes) attached, name filled, Add primary CTA enabled.

28"Site added successfully" — synchronous green check. (The mutation did write to the PDS, see §6.)

29Back in the form: "No site found." Step 3 turns red. The site was created but is invisible to the wizard that needs it.

Even after a full page reload, the form's site list is still empty:

30After a hard reload of /bumicert/create/36: state is preserved, contributor row resolves correctly, but Site Boundaries is still empty.

31The dedicated "Sites" page (/upload/sites) — also "No sites yet". So this isn't a per-bumicert filter; it's the global site list that's empty.

3c. Review step rejects publish

Forcing past step 3 with checkboxes ticked drops you on the Review screen. Cover Details ✓, Impact Details ✓, Site Details flagged with "The following fields are missing: Site Boundaries, Terms and Conditions", and the publish-stage Continue button is disabled. There is no override.

32Review step. Continue is disabled, Site Details says "missing". This is the floor through which the bumicert cannot be published.

6. PDS verification — what actually got written

Direct check against the user's PDS via com.atproto.repo.describeRepo + listRecords:

$ DID=did:plc:a6nwvv5treei7trkplq263io
$ curl -s "https://climateai.org/xrpc/com.atproto.repo.describeRepo?repo=$DID" | jq .collections
[
  "app.certified.location",
  "app.gainforest.organization.defaultSite",
  "app.gainforest.organization.info",
  "app.gainforest.organization.site"
]

The two new sites I created during this run are present as app.certified.location records:

$ curl -s "https://climateai.org/xrpc/com.atproto.repo.listRecords?repo=$DID&collection=app.certified.location&limit=10" | jq '.records[] | {uri, name: .value.name, createdAt: .value.createdAt}'
{
  "uri": "at://did:plc:a6nwvv5treei7trkplq263io/app.certified.location/3mklwqshg622a",
  "name": "Pi-Eval Site v2",
  "createdAt": "2026-04-29T01:22:14.469Z"
}
{
  "uri": "at://did:plc:a6nwvv5treei7trkplq263io/app.certified.location/3mklwie2rfk2a",
  "name": "Pi-Eval Test Site",
  "createdAt": "2026-04-29T01:17:30.963Z"
}

The shape of one record (the GeoJSON polygon I attached as a 226-byte blob, plus name + createdAt + lpVersion):

{
  "$type": "app.certified.location",
  "name": "Pi-Eval Test Site",
  "srs": "https://epsg.io/3857",
  "locationType": "geojson-point",
  "location": {
    "$type": "org.hypercerts.defs#smallBlob",
    "blob": {
      "$type": "blob",
      "ref": { "$link": "bafkreiepuujnsg2hk7jgrjdqn6yiatga7pdtkr4pe75ci2nk7lqvm34huq" },
      "mimeType": "application/geo+json",
      "size": 226
    }
  },
  "createdAt": "2026-04-29T01:17:30.963Z",
  "lpVersion": "1.0.0"
}

So the write path of the Add-Site mutation works. The bumicert itself, however, was not written. There are zero org.hypercerts.claim.activity records on the repo (the lexicon a Bumicert maps to per org/hypercerts/claim/activity.json):

$ curl -s "https://climateai.org/xrpc/com.atproto.repo.listRecords?repo=$DID&collection=org.hypercerts.claim.activity" | jq
{ "records": [] }

And after "Save as Draft" the URL becomes /bumicert/create/36 but the PDS still has zero new collections — drafts are stored on the backend (presumably the indexer DB), not on the PDS:

$ for col in app.bumicerts.draft app.bumicerts.application org.hypercerts.claim.activity.draft app.bumicerts.funding.config; do
    echo -n "$col: "
    curl -s "https://climateai.org/xrpc/com.atproto.repo.listRecords?repo=$DID&collection=$col" | jq '.records | length'
  done
app.bumicerts.draft: 0
app.bumicerts.application: 0
org.hypercerts.claim.activity.draft: 0
app.bumicerts.funding.config: 0

7. Root-cause: indexer doesn't see this user's records

I instrumented window.fetch in the page and confirmed the form's site list is fed by the indexer-side tRPC route locations.list:

GET /api/indexer/trpc/locations.list?batch=1&input={"0":{"json":{"did":"did:plc:a6nwvv5treei7trkplq263io"}}}
→ [{ "result": { "data": { "json": [] } } }]

Same DID, three different views:

The bumicerts wizard reads sites via the indexer:

// apps/bumicerts/app/(marketplace)/bumicert/create/[draftId]/_components/Steps/Step3.tsx
const { data: sitesResponse, isPending, isPlaceholderData, error } =
  indexerTrpc.locations.list.useQuery({ did: auth.user?.did ?? "" });

And the Add-Site modal does an optimistic local cache update to paper over indexer lag:

// components/global/modals/upload/site/editor.tsx
const result = await addMutation({ name, shapefile: shapefileData });
await indexerUtils.locations.list.cancel({ did });
indexerUtils.locations.list.setData({ did }, (previousSites) => {
  const nextSite = buildOptimisticCertifiedLocation({ did, result, previewUrl });
  …
  return [nextSite, …deduped];
});
onCreated?.({ uri: result.uri, cid: result.cid, rkey: result.rkey });
setIsCompleted(true);

The optimistic cache update should make the new site visible in the form list immediately. In practice, after Close → step 3 still says "No site found.", and after a hard reload the indexer still returns [], so the optimistic snapshot is the only place the site ever existed in this session. Two bugs to disentangle:

• The optimistic update isn't reaching the form's useQuery — possibly because indexerUtils and indexerTrpc have different cache keys (e.g. one is canonicalising the DID lower-case, the other keeping the form's original casing), or the form is on a different query observer that re-fetches and loses the optimistic snapshot.
• The indexer itself is not crawling this user's PDS at all — same query locations.list({ did: 'did:plc:suxrggijupvrlarm7qrxnjbx' }) for an account on bsky.social also returns 0, so the indexer is broadly behind on at least these two PDSes.

8. Existing Bumicert detail view (read-side)

To sanity-check that the read paths work for an indexed Bumicert, I opened Tamagochi at Riverside from the marketplace. Detail page is well-built: tab bar (Description · Site Boundaries · Donations · Timeline), clean serif heading, image gallery, donate CTA in the right margin. The Donations tab shows $279.83 USD raised, 1 anonymous donor — actual on-chain funding records came through. Site Boundaries was empty ("No sites linked to this bumicert") and Timeline said "No evidence uploaded yet", which match real upstream data — they're correct empty states, not bugs.

33Description tab. Long-form prose renders cleanly, project image dominant on the left, badges + share button at top.

34Site Boundaries tab. Genuine empty state for this cert — pin glyph + "No sites linked to this bumicert".

35Donations tab. Indexed on-chain donor data. "Anonymous (0x0C62…9442) · 10 months ago · $279.83 USD".

36Leaderboard. "Impact Champions" page — All Time / Month / Week filter, "Include anonymous donors" toggle. $26,938.62 raised across 68 donors.

Summary — findings

Reproducing

Full session recording

~19 min, no audio. Compressed VP9 1280px-wide. Original 8.9 MB → 6.7 MB.

Verifying the records on the PDS yourself

DID=did:plc:a6nwvv5treei7trkplq263io

# What collections exist on this user's repo
curl -s "https://climateai.org/xrpc/com.atproto.repo.describeRepo?repo=$DID" | jq .collections

# The two sites I created during the run
curl -s "https://climateai.org/xrpc/com.atproto.repo.listRecords?repo=$DID&collection=app.certified.location&limit=10" | jq

# No bumicert was actually published
curl -s "https://climateai.org/xrpc/com.atproto.repo.listRecords?repo=$DID&collection=org.hypercerts.claim.activity" | jq

Reproducing the indexer-coverage gap

# What the form thinks the user owns:
curl -s 'https://alpha.fund.gainforest.app/api/indexer/trpc/locations.list?batch=1&input=%7B%220%22%3A%7B%22json%22%3A%7B%22did%22%3A%22did%3Aplc%3Aa6nwvv5treei7trkplq263io%22%7D%7D%7D' | jq
# → [{ "result": { "data": { "json": [] } } }]

# What the PDS actually has:
curl -s "https://climateai.org/xrpc/com.atproto.repo.listRecords?repo=did:plc:a6nwvv5treei7trkplq263io&collection=app.certified.location" | jq '.records | length'
# → 2