Game Library plugin: Starter pipeline (with design brief)

The ticket called the community invite-only but never said how invitations are issued or redeemed, and that answer determines a large part of what the plugin has to build. No default was offered here. The pick had to match how the community was meant to grow.

• Closed registration: no public sign-up form, and an administrator creates each account by hand.
• A global invite code: a sign-up form that accepts an admin-set code, or a managed list of codes.
• Per-member invite links: every existing member can generate a limited number of single-use links to share, and the plugin tracks who invited whom. (your answer)

The community is gated at registration, but the ticket never said who can see a member’s library and activity once they are in.

• Closed community: nothing is public, and any logged-in member can view any other member’s library and activity. (was the default)
• Follower-gated: nothing is public, and a member’s library is visible only to their approved followers.
• Partially public: a member’s library is viewable by anyone, and only actions like adding or following require login.
• A per-member toggle: each member sets their own library public or private. Private stays visible to logged-in members only; public is visible to everyone, including logged-out visitors. (your answer, overriding the default)

You replaced the single site-wide rule with a per-member choice that blends the closed and public options.

Follow each other was stated without saying whether a follow is instant or needs the other person to accept.

• One-directional: any member can follow any other instantly, with no approval. (your answer, the default)
• Mutual follow: a follow sends a request the other member must accept first.

The ticket named an activity feed but not whose activity it shows.

• Only activity from members the viewer follows; logged actions are game added and status changed. (was the default)
• Sitewide activity from every member, regardless of who the viewer follows.
• Additional actions beyond game added and status changed, such as a new follow.
• A toggle between two audiences, Following for members the viewer follows and Everyone for sitewide activity; logged actions are game added and status changed. (your answer, overriding the default)

You gave the feed two audiences the viewer switches between. The default proposed only the follower-only view.

Games can hold one of four statuses, but the ticket never said whether a member sets the status while adding a game or changes a default afterward.

• The member picks one of the four statuses at the moment of adding, with no implicit default. (your answer, the default)
• Adding assigns a default status automatically, which the member changes later from their library.

Searching the game database needs API credentials that have to live somewhere, and a lookup can fail. The ticket did not say whether an administrator configures the credentials through a screen or in code, or what shows when a call fails.

• An admin settings screen holds the credentials and shows a notice when a lookup fails. (was the default)
• Credentials are set in code only, with no settings screen and no admin notice on failure.
• Both: a settings screen and code-level configuration constants, where the constants take precedence and make the screen fields read-only when present, with an admin notice shown on a failed lookup. (your answer, overriding the default)

You pre-approved the dual mechanism, with instruction to keep both paths even if a reviewer flags the overlap.

This feature is built around a member’s collection and shown to other members. The ticket set no visual bar, and a plain list or a designed layout would both be functionally complete.

• A polished, componentized layout using the theme’s design tokens: a cover-art card grid for the library and a designed activity feed. (your answer, the default)
• A minimal, utilitarian layout: plain list markup with default theme styling.

How much pagination and indexing attention is warranted depends on how large the data gets.

• Small: under 10,000 total rows after a year, and under 10,000 visits a month. Straightforward pagination, with queries still indexed and bounded as a matter of course. (your answer, the default)
• Medium: 10,000 to a million rows.
• Large: over a million rows.

The per-member visibility toggle and the feed’s Following and Everyone toggle were settled separately. Research raised how they interact but did not settle it. Should the sitewide Everyone feed include a member whose library is private?

• The Everyone feed respects per-member privacy: a private-library member’s activity is hidden from the sitewide feed and from anyone who could not otherwise see that library. (your answer, the default)
• The Everyone feed shows all activity regardless of library privacy, including actions from private libraries.

You made visibility govern both the library page and the feed. A follower still sees a followed member’s activity in the Following view, because following is an explicit relationship, but a private library stays hidden from logged-out visitors and from the sitewide audience.