chore(share): gate the public-profile surface off for launch#407
Merged
Conversation
Public profiles (/@handle pages) are cut from the launch scope. Handles are the root of the whole profile surface, so the cut is a gate on the claim path plus removal of the user-visible entry points — the profile page, listing flow, and backend stay in the tree, dark, for a cheap revival if user feedback asks for them. - share-backend: /api/handles/claim and /api/handles/check 404 unless PROFILES_ENABLED=1 is set on the Pages project - share-web /me: hide the Claim-a-handle card and the "No public handle yet" placeholder; drop handle-release wording from the delete-account modal - desktop PublishTab: hide the visibility picker — every publish is link-only (the "On profile" card could never be enabled without a claimable handle) - /privacy + /terms: rewrite profile-related copy to describe the service as it actually launches Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The desktop had its own claim surface that the first pass missed: Settings → Account rendered a full claim form (input + availability check + Claim button) for every signed-in user without a handle, and the delete-account confirm listed "your handle is released" as a consequence. Gate the form behind the same PROFILES_ENABLED convention and drop the handle bullet from the modal, matching the share-web cut. The claim/check IPC plumbing (preload + main) stays, dark — its only consumer is the gated form, consistent with keeping the backend endpoints revivable behind their env var. e2e now covers the gate: signed-in Account pane must render without the claim input, and the delete confirm must carry exactly the two surviving bullets. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…blish form Cutting the visibility picker left the signed-in publish form at roughly half the height of the two flat h-32 loading skeletons that precede it (cache lookup in ShareMenu, auth check in PublishTab), so the popover visibly shrank when the real form swapped in. Replace the form's empty body with a snapshot summary card — title, published-turn count (honouring an active TurnSelector selection), and a link-only visibility note that reuses the retired picker's copy so no new translations are needed beyond the turn counter. Both skeletons become a shared PublishTabSkeleton that mirrors the final layout, so the swap no longer moves the popover. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
What
Cuts public profiles (
/@handlepages and everything that hangs off them) from the share-publish launch scope. Nothing is deleted — the surface is gated so it can come back cheaply if user feedback asks for it.Why
Profiles add ongoing moderation/impersonation surface and legal-copy obligations that aren't justified before there's real usage. The launch ships link-only sharing; a share is visible to whoever has its URL, nothing is listed anywhere.
How it connects
Handles are the single root of the profile surface: publish and the visibility PATCH already reject
profile-listedwithout a live handle,/@handle404s without a row, and both clients key their profile affordances offuser.handle. With the claim path gated and the production D1 launching with zero handle rows, every downstream path stays dark without being touched:POST /api/handles/claimandGET /api/handles/checkreturn 404 unlessPROFILES_ENABLED=1is set on the Pages project. The revival checklist lives in a comment onprofilesEnabled()insrc/handles.ts./me— the Claim-a-handle card and the "No public handle yet" placeholder are gone; the delete-account modal no longer mentions releasing a handle.unlisted./privacy+/terms— profile-setup and profile-listed copy rewritten to describe the service as it actually launches.Kept dark on purpose:
Profile.tsx+ the/@route,handles.tsvalidation, thehandlestable, the deletion worker's handle release, and the desktop/web List-on-profile row actions (all unreachable while no user holds a handle).Known pre-existing quirk, unreachable while profiles are off: republishing from the share popover always submits
visibility: 'unlisted', so a listed share would be silently delisted on republish. Worth fixing before any futurePROFILES_ENABLEDflip.Test plan
share-publish.spec.tse2e 15/15 green — a new spec drives Settings → Account signed-in and asserts the claim input is absent and the delete confirm carries exactly the two surviving bullets; the publish-form spec asserts the visibility picker is absent and the publish landsunlistedon the mock backend; the row-menu listing spec stays as coverage for the dark path