Reduce re-review friction for GitHub-verified developer profiles, add Publisher URL verification

[admdly]

Summary

• upsertOwn no longer clears a developer profile's approved flag on every edit when the profile is currently GitHub org/user-verified — that identity check is an independently-computed signal strong enough to skip re-queuing for manual moderator review on every subsequent edit.
• New github_url_verified signal: cross-checks the profile's Publisher URL against GitHub's own on-file website for that org/user (same API call as the existing entity-type check, no extra request). Computed at profile creation, and re-checked via the owner's manual "Re-verify" action (POST /developers/me/reverify?check_url=true) — deliberately never by the opportunistic per-login re-check, which stays GitHub-API-free by design.
• New github_url_verified column (migration 0016), threaded through interfaces.ts (moderator/owner-only, excluded from PublicDeveloperSchema same as the other GitHub verification fields).

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	api	b068e92	Commit Preview URL Branch Preview URL	Jul 30 2026, 04:35 PM

[cubic-dev-ai]

All reported issues were addressed across 10 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[admdly]

Went through all 10 findings from cubic — 9 were valid and fixed in d80a6ed.

[admdly]

Two more updates in 2d7fa41:

1. The transient-GitHub-lookup-failure finding was already fixed in d80a6ed — the thread wasn't auto-marked because the fix lives in the caller (reverifyOwn in developers-database.ts), not the exact line cubic flagged (github-verification.ts:28). Verified via the passing test "preserves an existing Publisher URL verification when the GitHub lookup fails".

2. Rate limiting is now implemented for the one deferred finding: POST /developers/me/reverify?check_url=true returns 429/RATE_LIMITED if the same caller hits it again within 60 seconds, using the existing CACHE_KV binding as a per-user cooldown (no new infrastructure). The opportunistic per-login reverify is unaffected — it never sets check_url, so it never touches this path. Added 4 tests: blocks a rapid second call with zero extra GitHub API calls, doesn't rate-limit the no-check_url path, and scopes the cooldown per-caller (not global).

[cubic-dev-ai]

All reported issues were addressed across 9 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[admdly]

All 3 new findings addressed in 120453c — all were valid:

1. Stale URL on concurrent edit (developers-database.ts) — reverifyOwn's final write now re-asserts the Publisher URL hasn't changed since it was checked (same WHERE-clause-guard pattern already used for the ownership race just above it). A concurrent Publisher URL edit now surfaces as 409 CONFLICT instead of silently persisting a URL verification computed against the old URL. Covered by a test using the same SQL-hook race-simulation technique as the existing ownership-race test.

2. Non-atomic rate limit (index.ts) — you were right that a KV get-then-put isn't atomic. Replaced it entirely: the cooldown is now a conditional UPDATE ... WHERE url_check_cooldown_until IS NULL OR < CURRENT_TIMESTAMP directly on the developer's own row (new column, migration 0017), reusing the row already being touched in this function instead of standing up new infrastructure. This is a single atomic SQL statement, so two concurrent requests can't both win. Verified with a real concurrency test (Promise.all of two simultaneous requests) — passes.

3. Type-mismatch only cleared the URL signal, not identity (developers-database.ts) — when a manual re-check discovers GitHub's current entity type no longer matches the profile's type, github_org_verified now gets downgraded too, not just github_url_verified. matchesClaimant() never queries GitHub's actual current type on its own, so this was the only place post-creation that could catch the discrepancy at all.

[cubic-dev-ai]

All reported issues were addressed across 7 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[admdly]

Fixed in a30f515 — valid. url_check_cooldown_until lives on the developers row, so it's implicitly keyed by whoever currently owns it; without a reset, a new owner would inherit whatever was left of the previous owner's cooldown window.

There are actually two ownership-transfer write paths, not one — acceptTransfer (raw SQL via the direct transfer-link flow) and approveClaim (the claims-queue flow). Reset it in both:

• acceptTransfer is the one that's actually reachable today (a real previous owner with a real prior cooldown).
• approveClaim only ever targets never-owned profiles, so there's no prior owner's cooldown to inherit in practice — reset there too anyway, for the same reason, as defense-in-depth rather than something with a reachable test case.

[admdly]

Done in b068e92. `acceptTransfer` now also clears `github_org_verified`/`github_url_verified`/`github_verification_note`/`github_verified_at` on transfer, same as it already clears approval — a bare ownership handoff has no verification step of its own to carry over (unlike `approveClaim`, which carries over the claim's own verification, run specifically against the claimant), so this falls back to unverified until the new owner re-verifies.

[cubic-dev-ai]

0 issues found across 2 files (changes from recent commits).

<sub>Requires human review: Includes two database migrations (schema changes) and modifies approval behavior for GitHub-verified profiles, requiring operational judgment on trust and migration risk.

Re-trigger cubic</sub>