Wayfinder: mutual friends and live sprite-state viewing

Destination

Produce an implementation-ready specification for mutual FortSprite friendships: shareable raw-Clerk-ID friend links, approved requests, and live read-only views of each friend's signed-in sprite states.

Notes

• Signed-in users only may identify a link owner or send a request; links themselves may be opened while signed out.
• A friend link contains its owner's raw Clerk user ID and opens a confirmation screen before sending.
• Friendship is mutual only after explicit acceptance. Either participant may remove it, immediately revoking access for both.
• A decline clears the request; re-requesting is allowed. Blocking, reporting, public directories, messaging, and anonymous-progress sharing are out of scope.
• Accepted friends see a live, read-only full sprite matrix and summary for the owner's signed-in collection.
• Consult /domain-modeling and /grilling for decisions; use /prototype for the Friends UI and /research for external Clerk/Convex facts. Consult /convex:convex-expert before implementation in convex/.

Decisions so far

• Verify the secure identity and authorization seam for raw-ID friend links — Treat the raw Clerk ID as untrusted; authenticated Astro resolves a minimal confirmation profile, while Convex derives the caller and checks the friendship before every social or collection read.

Not yet specified

• The exact record invariants for crossed, duplicate, or stale friend requests.
• The Friends-area interaction design and routing.
• The presentation and availability behavior of a friend's collection view.
• Operational limits, error states, migration, and test strategy once the core contracts are selected.

Out of scope

• Blocking, reporting, public user discovery, social messaging, and sharing anonymous browser-only progress — excluded from the first release.

Start with /domain-modeling and /grilling for the unresolved friendship decisions, then review /prototype and /research for the Friends UI and Clerk/Convex constraints. Before implementation planning in convex/, consult /convex:convex-expert. Done means an implementation-ready specification covering record invariants, routing, collection-view behavior, limits, errors, migration, and tests.