feat(api): populate claim_url on every 201 anon provision response (DOG-21)#181
Merged
Merged
Conversation
mastermanas805
force-pushed
the
fix/populate-claim-url-on-anon-201
branch
from
a41c32a to
19c2cfb
Compare
…OG-21) DOG-21 — marketing landing page L106-109 promises "the agent surfaces the claim card directly in chat" with a clickable claim_url, but on the live 201 response /db/new (and every sibling) returned `claim_url: null`. Agents had to hand-construct `https://api.instanode.dev/start?t=<upgrade_jwt>` from the upgrade_jwt field — pushing composition responsibility into every vendor integration and producing different broken links per integration. Fix: emit `claim_url` alongside `upgrade` / `upgrade_jwt` at every 201 anonymous provision site. Same URL semantically (the /start?t=<jwt> page handles both claim and upgrade flows); distinct field signals intent so an agent can render a "Claim with email" CTA without parsing the upgrade URL from upgrade_jwt. Surfaces covered (rule 22): - db.go dedup branch + fresh-201 (2 sites) - cache.go dedup branch + fresh-201 (2 sites) - nosql.go dedup branch + fresh-201 (2 sites) - queue.go dedup branch + fresh-201 (2 sites) - vector.go dedup branch + fresh-201 (2 sites) - webhook.go dedup branch + fresh-201 (2 sites) - storage.go dedup branch + fresh-201 (2 sites) Total: 14 anon-provision emit sites — all carry claim_url. - openapi.go all 7 response schemas + ErrorResponse description widened to cover the 201-anon case (the pre-fix doc had it only on 402 recycle-gate, which is the documentation gap that produced the original report). What did NOT change: - upgrade / upgrade_jwt fields unchanged — back-compat preserved - Same URL as upgrade — no new endpoint, no new minting - Authenticated paths unchanged (no anon claim flow there) Coverage block: Symptom: claim_url:null on 201 /db/new despite marketing promise Enumeration: rg -n '"upgrade":[[:space:]]+upgradeURL,' internal/handlers/ Sites found: 14 (7 dedup + 7 fresh-201) Sites touched: 14 / 14 Coverage test: TestDOG21_ClaimURLEmittedOnEveryAnonProvision iterates the live anonProvisionHandlerFiles registry (rule 18 — registry- iterating, not hand-typed) and asserts claim_url count >= upgrade_jwt count per file; TestDOG21_OpenAPISchemaDocumentsClaimURL asserts ErrorResponse.claim_url description reflects the new 201 emit (rule 22 surface checklist). Live verified: pre-merge: see DOG-21 in personal-dogfood-log.md ("claim_url: null in the response"). post-merge curl below. Local gate: - go build ./... PASS - go vet ./... PASS - go test -short -run TestOpenAPI ./internal/handlers/ PASS (all 18 pass) - go test -short -run TestDOG21 ./internal/handlers/ PASS - go test -short -run Recycle ./internal/handlers/ PASS Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mastermanas805
force-pushed
the
fix/populate-claim-url-on-anon-201
branch
from
19c2cfb to
887ce7c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DOG-21 — marketing landing page promises 'the agent surfaces the claim card directly in chat' with a clickable claim_url, but the live 201 response on `/db/new` (and every sibling) returned `claim_url: null`. Agents had to hand-construct `https://api.instanode.dev/start?t=<upgrade_jwt>` from the `upgrade_jwt` field — pushing composition responsibility into every vendor integration.
Fix
Emit `claim_url` alongside `upgrade` / `upgrade_jwt` at every 201 anonymous provision site (14 total — 7 dedup branches + 7 fresh-201 branches across db/cache/nosql/queue/vector/webhook/storage).
Semantically same URL (the `/start?t=` page handles both claim and upgrade flows); distinct field signals intent so an agent can render a 'Claim with email' CTA without parsing the upgrade URL.
Surfaces (rule 22)
What did NOT change
Coverage block
```
Symptom: claim_url:null on 201 /db/new despite marketing promise
Enumeration: rg -n '"upgrade":[[:space:]]+upgradeURL,' internal/handlers/
Sites found: 14 (7 dedup + 7 fresh-201)
Sites touched: 14 / 14
Coverage test: TestDOG21_ClaimURLEmittedOnEveryAnonProvision iterates the
live anonProvisionHandlerFiles registry (rule 18 — registry-
iterating, not hand-typed) and asserts claim_url count ≥
upgrade_jwt count per file; TestDOG21_OpenAPISchemaDocumentsClaimURL
pins ErrorResponse + per-service schema description
Live verified: pre-merge DOG-21 in personal-dogfood-log.md
```
Local gate
🤖 Generated with Claude Code