@amityco/social-plus-vise 0.8.1 → 0.12.2

package/dist/outcomes.js

@@ -5,15 +5,18 @@ export function hasAnswer(answers, id) {
 const CLASSIFY_ORDER = [
     "setup-push",
     "setup-live-data",
+    "add-comments",
     "add-moderation",
     "add-chat",
-    "add-comments",
     "add-feed",
+    "add-community",
+    "add-follow",
+    "add-notifications",
     "troubleshoot",
     "validate-setup",
     "setup-sdk",
 ];
-const PUSH_PATTERNS = [/\b(push|notification|firebase|fcm|apns)\b/];
+const PUSH_PATTERNS = [/\b(push(?:\s+notification)?|push(?:\s+notifications)?|firebase|fcm|apns)\b/];
 const LIVE_PATTERNS = [
     /\b(live object|live objects|live collection|live collections|realtime collection|real-time collection|observe|observer|subscribe|subscription|unsubscribe|live update|live updates)\b/,
 ];
@@ -29,13 +32,48 @@ const MODERATION_OUTCOME_PATTERNS = [
 const CHAT_PATTERNS = [
     /\b(chat|messaging|dm|direct message|conversation|group chat|channel|inbox)\b/,
 ];
+// Community MANAGEMENT/membership — deliberately NOT bare "community" (which
+// co-occurs with feed: "community feed" must route to add-feed, handled by
+// classify order placing add-community AFTER add-feed).
+const COMMUNITY_PATTERNS = [
+    /\b(create|creating|build|building|manage|managing|join|joining|leave|leaving|set ?up)\s+(a\s+|the\s+)?communit/,
+    /\bcommunit\w*\s+(member|membership|role|invit|categor|setting|management|directory|discovery)/,
+    /\bcommunity\s+(creation|management|members?|roles?|invitations?|categories|settings|moderation)\b/,
+];
+// Social graph (follow/followers). "block user" is intentionally left to
+// add-moderation; blocking is still a capability under add-follow.
+const FOLLOW_PATTERNS = [
+    /\b(follow|unfollow|follower|followers|following)\b/,
+    /\b(social graph|user relationship|follow request|followers? list|following list)\b/,
+];
+// In-app notification tray/inbox/settings. Deliberately NOT bare "notification"
+// and NOT "push notification" (which routes to setup-push).
+// "notification feed"/"notification inbox" deliberately excluded — "feed" and
+// "inbox" are claimed by add-feed / add-chat respectively. Tray/center/in-app/
+// settings are non-colliding.
+const NOTIFICATION_PATTERNS = [
+    /\b(notification tray|notification cent(?:er|re)|in-?app notification)/,
+    /\bnotification (?:setting|preference)/,
+];
 const TROUBLESHOOT_PATTERNS = [/\b(error|broken|crash|not working|fail|timeout|401|403)\b/];
 const VALIDATE_PATTERNS = [/\b(validate|check|correct|setup right|initiali[sz])\b/];
-const SETUP_PATTERNS = [/\b(setup|set up|install|integrate|wire|configure)\b/];
+const SETUP_PATTERNS = [/\b(setup|set up|install|integrate|wire|configure|init sdk|sdk setup|session lifecycle)\b|initialise?s?\b/];
 export const BROAD_SOCIAL_REGEX = /\b(nice|social features|social feature|engagement|community experience)\b/i;
 export const DESIGN_REGEX = /\bdesign token|design tokens|theme|same design|design system|brand/i;
 export function classifyOutcome(request) {
     const normalized = request.toLowerCase();
+    // Precedence: a feed/timeline build that also mentions comments is a feed
+    // build, not a standalone "add comments to existing content" task. add-feed
+    // carries conditional comment guidance, so a multi-feature feed request must
+    // route there — otherwise add-comments (which precedes add-feed in the
+    // classify order) wins on the bare word "comment" and silently drops every
+    // feed/avatar/poll/notification step. Pure comment requests (no feed signal)
+    // still fall through to add-comments below.
+    const matchesFeed = outcomeRegistry["add-feed"].patterns.some((p) => p.test(normalized));
+    const matchesComments = outcomeRegistry["add-comments"].patterns.some((p) => p.test(normalized));
+    if (matchesFeed && matchesComments) {
+        return "add-feed";
+    }
     for (const id of CLASSIFY_ORDER) {
         const def = outcomeRegistry[id];
         if (def.patterns.some((pattern) => pattern.test(normalized))) {
@@ -134,10 +172,18 @@ const setupSdk = {
             step: "Initialize the social.plus client exactly once with API key and explicit region.",
             evidence: [platformQuickStart(ctx.platform).path, "requiredInputs.social.plus API key local env/config variable", "requiredInputs.social.plus region"],
         },
+        {
+            step: "When repairing setup, reuse the app's existing region or endpoint config source instead of hardcoding a guessed default value.",
+            evidence: [platformQuickStart(ctx.platform).path, "requiredInputs.social.plus region"],
+        },
         {
             step: "Wire login after user identity is known and before social.plus API queries/subscriptions.",
             evidence: ["social-plus-sdk/getting-started/authentication", "requiredInputs.user identity source for login"],
         },
+        {
+            step: "When adding renewal handling, keep it in the existing login path and retain the handler for the full session lifetime.",
+            evidence: ["social-plus-sdk/getting-started/authentication", "requiredInputs.user identity source for login"],
+        },
         { step: "Run validate_setup and detected command sensors after edits.", evidence: ["validate_setup", "run_sensors"] },
     ],
     validation: (platform) => [`${platform}.setup.present`, `${platform}.login.present`, `${platform}.region.explicit`],
@@ -436,6 +482,14 @@ const addFeed = {
             required: true,
             blocksImplementationWhenMissing: true,
         });
+        questions.push({
+            id: "engagement_surfaces",
+            question: "Which engagement surfaces are in scope alongside the feed: comments/replies, reactions, notifications, sharing?",
+            why: "A feed silently shipped without comments or reactions is the most common scope gap — the request often omits them, so the agent drops them without ever deciding. Naming the engagement surfaces turns a silent omission into an explicit, reviewable choice. This does NOT block a read-only feed: if unspecified, implement the surfaces the design shows and explicitly list any treated as out-of-scope in the final report.",
+            required: false,
+            blocksImplementationWhenMissing: false,
+            options: ["comments + replies", "reactions", "notifications", "sharing", "feed only (no engagement)"],
+        });
         return filterAnswered(ctx.answers, questions);
     },
     requiredInputs: () => [
@@ -470,8 +524,63 @@ const addFeed = {
                     "social-plus-sdk/core-concepts/realtime-communication/live-objects-collections/overview",
                 ],
             },
+            {
+                step: "When repairing or refactoring a feed query, preserve existing pagination inputs and state (for example pageToken, nextPage, hasMore/loadMore, or infinite-query wiring) unless the customer explicitly changes feed behavior.",
+                evidence: [
+                    "requiredInputs.feed scope",
+                    "implementationRules.file-specific edits",
+                ],
+            },
             { step: "Reuse the host app's existing visual system for the social surface.", evidence: designEvidence },
             { step: "Implement loading, empty, error, and data states.", evidence: ["implementationRules.file-specific edits"] },
+            {
+                step: "In post card renderers, resolve each media type from the parent post OR its childrenPosts — in a feed the parent is usually dataType 'text' and the image/video/poll/room rides on a child post. Handle at minimum: text, image, video, file, poll, room. Do NOT gate media on the parent's dataType alone (e.g. post.dataType === 'poll') — that never matches a text parent and the content silently never renders. When rendering the text body itself (post or comment), apply @mention highlights if metadata carries mention entries ({ type: 'user', index, length, userId }, length excluding the '@'): wrap each [index, index + length + 1] span in a styled element and resolve userId to a display name, rather than printing raw text. Pass mentionees on create so mentioned users are notified.",
+                evidence: ["social-plus-sdk/social/posts"],
+            },
+            {
+                step: "Read SDK objects through their own typed accessors and types (e.g. post.getImageInfo(), the Amity.* types) instead of casting return values to hand-written shapes like (post.data as { text?: string }). A hand-written cast silences the type-checker, so when an SDK upgrade renames a field your build still compiles and the bug only surfaces at runtime — reading through SDK types lets tsc/analyze flag the breakage.",
+                evidence: ["social-plus-sdk/social/posts"],
+            },
+            {
+                step: "For community and user avatars, use the SDK-provided URL (community.avatar?.fileUrl / community.avatarImage?.getUrl / community.getAvatar()?.getUrl) and fall back to an initial only when the field is absent. Do not derive an initial from the display name as the sole identifier.",
+                evidence: ["social-plus-sdk/social/user-profile"],
+            },
+            ...(COMMENT_PATTERNS.some((p) => p.test(ctx.request.toLowerCase())) ? [
+                {
+                    step: "If post cards display a comment count, implement the comment thread end to end — both read AND write. Read: CommentRepository.getComments live collection with an explicit pageSize. Write: a composer that calls CommentRepository.createComment, gated behind the current user's ban/permission state. A read-only comment list is incomplete; users expect to post. Wire cleanup on unmount.",
+                    evidence: [
+                        "social-plus-sdk/social/content-management/comments/creation/text-comment",
+                        "social-plus-sdk/social/content-management/comments/retrieval/query-comments",
+                        "social-plus-sdk/core-concepts/realtime-communication/live-objects-collections/overview",
+                    ],
+                },
+                {
+                    step: "If comments support replies (comment.childrenNumber > 0), render the reply hierarchy: load replies with getComments({ parentId: <commentId> }) and create replies with createComment({ ..., parentId }). The SDK supports up to Level 2 nesting — resolve deeper replies to the Level 1 ancestor via getParentId(). A flat single-level list drops the conversation structure.",
+                    evidence: ["social-plus-sdk/social/content-management/comments/creation/text-comment"],
+                },
+            ] : []),
+            ...(/notification|bell|tray|inbox/i.test(ctx.request) ? [
+                {
+                    step: "If the design includes a notification bell or notification center, implement it with the notificationTray SDK: getNotificationTrayItems (live collection), markItemsSeen on open, and an unread badge sourced from getNotificationTraySeen.",
+                    evidence: ["social-plus-sdk/social/notifications"],
+                },
+            ] : []),
+            {
+                step: "If the feed includes poll posts, render each answer by branching on answer.dataType: for 'text' use answer.data directly as a string (PollAnswer.data is the text, not an object); for 'image' render answer.image?.fileUrl. Support voting via PollRepository.votePoll(pollId, [answerId]) and PollRepository.unvotePoll(pollId). When poll.status === 'closed' or poll.isVoted is true, display voteCount percentage bars instead of vote buttons. Show the poll's time status from poll.closedAt (when it ended) or poll.closedIn (when it will end) so users know if voting is open.",
+                evidence: ["social-plus-sdk/social/content-management/posts/creation/poll-post"],
+            },
+            {
+                step: "In post card headers, show the post's target context when post.targetType === 'community': display 'Author.displayName › Community.displayName' by subscribing to CommunityRepository.getCommunity(post.targetId, cb) for the live community name.",
+                evidence: ["social-plus-sdk/social/communities", "social-plus-sdk/social/posts"],
+            },
+            {
+                step: "For room-type posts, subscribe to RoomRepository.getRoom(roomId, cb) to get the Room object and display room.title (not room.roomId). Show room.status (live/idle/ended) as a badge.",
+                evidence: ["social-plus-sdk/live-video/room"],
+            },
+            {
+                step: "Give each post card an actions menu gated by the viewer's relationship to the post. If the viewer is the author (post.postedUserId === currentUserId), show edit (PostRepository.editPost) and delete (PostRepository.deletePost). For posts the viewer does not own, show report/flag (PostRepository.flagPost). Author-ownership actions and moderator-role actions are distinct — do not show edit/delete to non-authors.",
+                evidence: ["social-plus-sdk/social/posts", "social-plus-sdk/social/moderation"],
+            },
             { step: "Run validate_setup and detected command sensors after edits.", evidence: ["validate_setup", "run_sensors"] },
         ];
     },
@@ -706,6 +815,10 @@ const addModeration = {
             },
             { step: "Implement block/mute state application to rendered content.", evidence: designEvidence },
             { step: "Add hidden/blocked content rendering per customer policy.", evidence: ["requiredInputs.post-action rendering policy"] },
+            {
+                step: "If building a moderator/review surface for a review-enabled community (ADMIN_REVIEW_POST_REQUIRED), query the reviewing feed (feedType: 'reviewing', gated on the REVIEW_COMMUNITY_POST permission) and wire approvePost()/declinePost() — not just the published feed. A regular member feed stays on published.",
+                evidence: ["social-plus-sdk/social/content-management/posts/moderation/post-review"],
+            },
             { step: "Run validate_setup and detected command sensors after edits.", evidence: ["validate_setup", "run_sensors"] },
         ];
     },
@@ -828,8 +941,8 @@ const addChat = {
                 evidence: ["social-plus-sdk/chat/channels", "social-plus-sdk/chat/messages"],
             },
             { step: "Reuse the host app's existing visual system for chat UI.", evidence: designEvidence },
-            { step: "Add message send with error handling and auth gate.", evidence: ["implementationRules.file-specific edits"] },
-            { step: "Wire read receipts and typing indicators if required.", evidence: ["requiredInputs.read receipt and typing indicator requirements"] },
+            { step: "Add message send with error handling and auth gate. Observe each message's syncState and surface failed sends (error state) with a retry/delete affordance instead of rendering optimistic success unconditionally; clean up unrecoverable failures (e.g. deleteFailedMessages) on init.", evidence: ["implementationRules.file-specific edits"] },
+            { step: "Wire read receipts and typing indicators if required — and mark the channel/messages read on open (channel.markAsRead() / message.markRead(), or startMessageReceiptSync paired with stopMessageReceiptSync on the view lifecycle) so the server-side unread count actually decrements. Reading the unread count without ever marking read leaves the badge stuck.", evidence: ["requiredInputs.read receipt and typing indicator requirements"] },
             { step: "Add moderation affordance on messages.", evidence: ["requiredInputs.moderation flow for chat messages"] },
             { step: "Run validate_setup and detected command sensors after edits.", evidence: ["validate_setup", "run_sensors"] },
         ];
@@ -858,6 +971,347 @@ const addChat = {
     ],
     resolveNotes: () => [],
 };
+const addCommunity = {
+    id: "add-community",
+    patterns: COMMUNITY_PATTERNS,
+    interpretation: "Build a community surface — create/join/leave communities, list members and roles, and handle invitations/join-requests — using the customer app's design system.",
+    docsQuery: (platform) => `${platform} community membership join leave members`,
+    docs: (platform) => [
+        {
+            path: "social-plus-sdk/social/communities-spaces/organization/join-leave-community",
+            reason: "Join/leave and join-request APIs for public vs private communities.",
+        },
+        {
+            path: "social-plus-sdk/social/communities-spaces/organization/query-community-members",
+            reason: "Query/observe community members, membership, and roles.",
+        },
+        {
+            path: "social-plus-sdk/social/communities-spaces/organization/community-invitation",
+            reason: "Community invitation flow (create/accept invitations).",
+        },
+        {
+            path: liveDataPlatformPath(platform),
+            reason: "Live Collection patterns for real-time community and member-list updates.",
+        },
+    ],
+    intakeQuestions: (ctx) => {
+        const questions = [
+            {
+                id: "community_scope",
+                question: "Which community surface are you building (create a community, browse/join communities, a community detail with members, or membership management)?",
+                why: "Each surface uses different repositories and flows; Vise must not assume.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+                options: ["create community", "browse/join communities", "community detail + members", "membership management"],
+            },
+            {
+                id: "community_privacy",
+                question: "Are communities public (instant join) or private (join-request approval)?",
+                why: "Private communities use the join-request approval flow (AmityJoinRequest); public communities join instantly. The UI and API differ.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+                options: ["public", "private (join requests)", "both"],
+            },
+            {
+                id: "community_target",
+                question: "Where does the community ID come from (route param, selection, or a create flow)?",
+                why: "The coding agent must not invent a communityId; it needs a concrete source.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+            },
+            {
+                id: "lifecycle_owner",
+                question: "What owns the lifecycle of the live community/member subscription (Activity, ViewController, Widget, React component)?",
+                why: "Live community/member observers must be cleaned up to prevent leaks and stale updates.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+            },
+            {
+                id: "target_screen",
+                question: "Which screen or component should display the community surface?",
+                why: "Vise needs the target file/route for placement.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+            },
+        ];
+        return filterAnswered(ctx.answers, questions);
+    },
+    requiredInputs: () => [
+        "community surface: create, browse/join, detail+members, or membership management",
+        "community privacy model: public (instant) vs private (join request)",
+        "concrete community ID source (route param, selection, or create flow)",
+        "lifecycle owner for community/member observer cleanup",
+        "target screen or component",
+    ],
+    implementationRules: () => [
+        "Do not invent or hardcode a communityId. Ask for the source or implement a selection/create flow.",
+        "Do not ask for API keys in chat. Create an env/config placeholder.",
+        "Query communities and members through Live Collections, not one-shot queries, so the UI stays live.",
+        "Handle public (instant join) and private (join-request approval) flows explicitly — do not assume one.",
+        "Gate moderator-only actions (roles, ban, remove) behind a role check; community/member observers must be cleaned up on lifecycle end.",
+    ],
+    implementationSteps: (ctx) => {
+        const designEvidence = ctx.designSignals.length > 0
+            ? ctx.designSignals.map((signal) => signal.file)
+            : ["requiredInputs.design token or theme source file"];
+        return [
+            {
+                step: "Confirm the community surface, privacy model, community ID source, and target screen before writing code.",
+                evidence: ["requiredInputs.community surface", "requiredInputs.community privacy model", "requiredInputs.concrete community ID source"],
+            },
+            {
+                step: "Implement the community/member query with the platform's Live Collection (AmityCommunityRepository / getMembers), with cleanup on the lifecycle owner.",
+                evidence: ["social-plus-sdk/social/communities-spaces/organization/query-community-members", liveDataPlatformPath(ctx.platform)],
+            },
+            {
+                step: "Wire join/leave — handle public (joinCommunity) and private (join-request approval) flows.",
+                evidence: ["social-plus-sdk/social/communities-spaces/organization/join-leave-community"],
+            },
+            { step: "Reuse the host app's existing visual system for the community UI.", evidence: designEvidence },
+            { step: "Implement loading, empty, error, and data states.", evidence: ["implementationRules.file-specific edits"] },
+            { step: "Add membership management (roles/moderation) and invitations where in scope, gated by role.", evidence: ["social-plus-sdk/social/communities-spaces/organization/community-invitation"] },
+            { step: "Run validate_setup and detected command sensors after edits.", evidence: ["validate_setup", "run_sensors"] },
+        ];
+    },
+    validation: () => [
+        "community membership uses a Live Collection (not a one-shot query)",
+        "join/leave handles public vs private (join-request) flows",
+        "no invented communityId",
+        "community/member observer cleaned up on lifecycle end",
+        "validate_setup",
+        "run_sensors",
+    ],
+    stopConditions: (ctx) => filterStops(ctx.answers, [
+        { id: "community_scope", text: "The community surface is unknown; do not assume create vs browse vs members vs management." },
+        { id: "community_privacy", text: "The privacy model is unknown; public (instant) and private (join-request) flows differ and must not be guessed." },
+        { id: "community_target", text: "The community ID source is unknown; do not invent a communityId." },
+        { id: "lifecycle_owner", text: "The lifecycle owner for community/member observer cleanup is unknown." },
+    ]),
+    resolvePlan: () => [
+        { file: "Target screen/component", intent: "Query communities/members via Live Collection; render loading/empty/error/data states." },
+        { file: "Join/leave flow", intent: "Handle public join and private join-request approval." },
+        { file: "Membership management", intent: "Roles/moderation/invitations, gated by role." },
+    ],
+    resolveVerification: () => [
+        "Confirm communities/members load via a Live Collection and update in real time.",
+        "Confirm join/leave handles both public and private flows.",
+        "Confirm the community/member observer is cleaned up on lifecycle end.",
+        "Confirm no communityId is hardcoded.",
+    ],
+    resolveNotes: () => [],
+};
+const addFollow = {
+    id: "add-follow",
+    patterns: FOLLOW_PATTERNS,
+    interpretation: "Build the social graph — follow/unfollow, follower/following lists, follow-request approval, and block/unblock — using the customer app's design system.",
+    docsQuery: (platform) => `${platform} follow unfollow followers following block user`,
+    docs: (platform) => [
+        {
+            path: "social-plus-sdk/social/user-relationship/following/get-follower-following-list",
+            reason: "Query/observe follower and following lists; follow/unfollow and follow status.",
+        },
+        {
+            path: "social-plus-sdk/social/user-relationship/blocking/block-unblock-user",
+            reason: "Block/unblock a user and how blocking affects the relationship.",
+        },
+        {
+            path: liveDataPlatformPath(platform),
+            reason: "Live Collection patterns for real-time follower/following list updates.",
+        },
+    ],
+    intakeQuestions: (ctx) => {
+        const questions = [
+            {
+                id: "follow_surface",
+                question: "Which social-graph surface (follow/unfollow button, follower list, following list, or blocked-users management)?",
+                why: "Each uses different AmityUserRepository calls and UI; Vise must not assume.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+                options: ["follow/unfollow button", "follower list", "following list", "blocked users"],
+            },
+            {
+                id: "follow_model",
+                question: "Is following automatic, or does it require a follow-request approval?",
+                why: "Follow-request flows have a pending/accept/decline state (AmityFollowStatusFilter) that changes the API and UI.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+                options: ["automatic", "follow request approval"],
+            },
+            {
+                id: "follow_target",
+                question: "Where does the target userId come from (route param, profile selection, current user)?",
+                why: "The coding agent must not invent a userId; it needs a concrete source.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+            },
+            {
+                id: "lifecycle_owner",
+                question: "What owns the lifecycle of the live follower/following subscription?",
+                why: "Live relationship observers must be cleaned up to prevent leaks and stale counts.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+            },
+            {
+                id: "target_screen",
+                question: "Which screen or component should display the social-graph surface?",
+                why: "Vise needs the target file/route.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+            },
+        ];
+        return filterAnswered(ctx.answers, questions);
+    },
+    requiredInputs: () => [
+        "social-graph surface: follow button, follower list, following list, or blocked users",
+        "follow model: automatic vs follow-request approval",
+        "concrete target userId source (route param, selection, current user)",
+        "lifecycle owner for relationship observer cleanup",
+        "target screen or component",
+    ],
+    implementationRules: () => [
+        "Do not invent or hardcode a userId. Ask for the source or wire it from the profile/route.",
+        "Do not ask for API keys in chat. Create an env/config placeholder.",
+        "Query follower/following lists through Live Collections so counts and state stay live.",
+        "Handle follow-request (pending/accept/decline) explicitly when following is not automatic.",
+        "Relationship observers must be cleaned up on lifecycle end.",
+    ],
+    implementationSteps: (ctx) => {
+        const designEvidence = ctx.designSignals.length > 0 ? ctx.designSignals.map((signal) => signal.file) : ["requiredInputs.design token or theme source file"];
+        return [
+            {
+                step: "Confirm the social-graph surface, follow model, target userId source, and target screen before writing code.",
+                evidence: ["requiredInputs.social-graph surface", "requiredInputs.follow model", "requiredInputs.concrete target userId source"],
+            },
+            {
+                step: "Implement follow/unfollow (AmityUserRepository) and the follower/following query as a Live Collection, with cleanup.",
+                evidence: ["social-plus-sdk/social/user-relationship/following/get-follower-following-list", liveDataPlatformPath(ctx.platform)],
+            },
+            { step: "Handle the follow-request approval flow (pending/accept/decline) when following is not automatic.", evidence: ["requiredInputs.follow model"] },
+            { step: "Wire block/unblock and a blocked-users surface where in scope.", evidence: ["social-plus-sdk/social/user-relationship/blocking/block-unblock-user"] },
+            { step: "Reuse the host app's existing visual system; implement loading/empty/error/data states.", evidence: designEvidence },
+            { step: "Run validate_setup and detected command sensors after edits.", evidence: ["validate_setup", "run_sensors"] },
+        ];
+    },
+    validation: () => [
+        "follower/following lists use a Live Collection (not a one-shot query)",
+        "follow model handled (automatic vs follow-request approval)",
+        "no invented userId",
+        "relationship observer cleaned up on lifecycle end",
+        "validate_setup",
+        "run_sensors",
+    ],
+    stopConditions: (ctx) => filterStops(ctx.answers, [
+        { id: "follow_surface", text: "The social-graph surface is unknown; do not assume follow button vs lists vs blocked users." },
+        { id: "follow_model", text: "The follow model is unknown; automatic vs follow-request approval flows differ." },
+        { id: "follow_target", text: "The target userId source is unknown; do not invent a userId." },
+        { id: "lifecycle_owner", text: "The lifecycle owner for relationship observer cleanup is unknown." },
+    ]),
+    resolvePlan: () => [
+        { file: "Target screen/component", intent: "Follow/unfollow + follower/following lists via Live Collection; loading/empty/error/data states." },
+        { file: "Follow-request flow", intent: "Pending/accept/decline when following is not automatic." },
+        { file: "Blocking", intent: "Block/unblock + blocked-users management." },
+    ],
+    resolveVerification: () => [
+        "Confirm follower/following lists load via a Live Collection and update live.",
+        "Confirm the follow model (automatic vs request) is handled.",
+        "Confirm the relationship observer is cleaned up on lifecycle end.",
+        "Confirm no userId is hardcoded.",
+    ],
+    resolveNotes: () => [],
+};
+const addNotifications = {
+    id: "add-notifications",
+    patterns: NOTIFICATION_PATTERNS,
+    interpretation: "Build an in-app notification tray/inbox — observe the notification tray, mark items seen, and respect notification settings — using the customer app's design system. (This is distinct from push-notification setup.)",
+    docsQuery: (platform) => `${platform} in-app notification tray seen settings`,
+    docs: (platform) => [
+        {
+            path: "social-plus-sdk/social/discovery-engagement/notifications/notification-tray-status",
+            reason: "Observe the notification tray and its seen/mark-as-seen status.",
+        },
+        {
+            path: liveDataPlatformPath(platform),
+            reason: "Live Object/Collection patterns for real-time tray updates and seen state.",
+        },
+    ],
+    intakeQuestions: (ctx) => {
+        const questions = [
+            {
+                id: "notification_surface",
+                question: "Which notification surface (in-app tray/inbox list, an unseen badge, or notification settings/preferences)?",
+                why: "The tray list, the seen-badge, and settings use different APIs; Vise must not assume.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+                options: ["tray / inbox list", "unseen badge", "notification settings"],
+            },
+            {
+                id: "lifecycle_owner",
+                question: "What owns the lifecycle of the live notification-tray subscription?",
+                why: "The tray observer must be cleaned up to prevent leaks and stale badges.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+            },
+            {
+                id: "target_screen",
+                question: "Which screen or component should display the notifications?",
+                why: "Vise needs the target file/route.",
+                required: true,
+                blocksImplementationWhenMissing: true,
+            },
+        ];
+        return filterAnswered(ctx.answers, questions);
+    },
+    requiredInputs: () => [
+        "notification surface: tray/inbox list, unseen badge, or settings",
+        "lifecycle owner for the tray observer",
+        "target screen or component",
+    ],
+    implementationRules: () => [
+        "This is the IN-APP notification tray, not push setup (see setup-push for FCM/APNS).",
+        "Do not ask for API keys in chat. Create an env/config placeholder.",
+        "Observe the notification tray as a Live Object/Collection so the seen state and badge stay live.",
+        "Mark items/tray seen so the unseen count clears server-side; clean up the observer on lifecycle end.",
+    ],
+    implementationSteps: (ctx) => {
+        const designEvidence = ctx.designSignals.length > 0 ? ctx.designSignals.map((signal) => signal.file) : ["requiredInputs.design token or theme source file"];
+        return [
+            {
+                step: "Confirm the notification surface (tray list / badge / settings) and target screen before writing code.",
+                evidence: ["requiredInputs.notification surface", "requiredInputs.target screen or component"],
+            },
+            {
+                step: "Observe the notification tray (getNotificationTraySeen / tray Live Object) with cleanup on the lifecycle owner.",
+                evidence: ["social-plus-sdk/social/discovery-engagement/notifications/notification-tray-status", liveDataPlatformPath(ctx.platform)],
+            },
+            { step: "Mark the tray/items seen so the unseen badge clears server-side (markAsSeen).", evidence: ["social-plus-sdk/social/discovery-engagement/notifications/notification-tray-status"] },
+            { step: "Respect notification settings/preferences where in scope (getSettings).", evidence: ["requiredInputs.notification surface"] },
+            { step: "Reuse the host app's existing visual system; implement loading/empty/error/data states.", evidence: designEvidence },
+            { step: "Run validate_setup and detected command sensors after edits.", evidence: ["validate_setup", "run_sensors"] },
+        ];
+    },
+    validation: () => [
+        "notification tray observed as a Live Object/Collection (not a one-shot query)",
+        "tray/items marked seen so the unseen count clears server-side",
+        "tray observer cleaned up on lifecycle end",
+        "this is in-app tray, not push setup",
+        "validate_setup",
+        "run_sensors",
+    ],
+    stopConditions: (ctx) => filterStops(ctx.answers, [
+        { id: "notification_surface", text: "The notification surface is unknown; do not assume tray vs badge vs settings." },
+        { id: "lifecycle_owner", text: "The lifecycle owner for the tray observer is unknown." },
+    ]),
+    resolvePlan: () => [
+        { file: "Target screen/component", intent: "Observe the notification tray; render list/badge with loading/empty/error/data states." },
+        { file: "Seen state", intent: "Mark tray/items seen so the unseen count clears." },
+    ],
+    resolveVerification: () => [
+        "Confirm the tray is observed live and updates in real time.",
+        "Confirm items/tray are marked seen and the unseen count clears.",
+        "Confirm the tray observer is cleaned up on lifecycle end.",
+    ],
+    resolveNotes: () => [],
+};
 const troubleshoot = {
     id: "troubleshoot",
     patterns: TROUBLESHOOT_PATTERNS,
@@ -878,6 +1332,7 @@ const troubleshoot = {
     implementationRules: () => [],
     implementationSteps: () => [
         { step: "Gather more evidence before implementation.", evidence: ["stopConditions", "search_docs", "inspect_project"] },
+        { step: "If the issue is an SDK-specific runtime symptom, run vise debug first and use the repair brief before broader repo exploration.", evidence: ["search_docs", "inspect_project"] },
     ],
     validation: () => [],
     stopConditions: () => [],
@@ -944,6 +1399,9 @@ const outcomeRegistry = {
     "add-comments": addComments,
     "add-moderation": addModeration,
     "add-chat": addChat,
+    "add-community": addCommunity,
+    "add-follow": addFollow,
+    "add-notifications": addNotifications,
     troubleshoot,
     "validate-setup": validateSetup,
     unknown,