Game Library plugin – Principal WP Pipeline (with design brief)

Nothing in the ticket said who could issue an invite, and that shapes whether the community grows on its own or stays gatekept by admins.

• Admin-only for version one, with member-to-member invites as a possible later step. (was the default)
• Open to any existing member, with no cap.
• Open to any existing member, but rate-limited with a per-inviter quota. (your answer, overriding the default)

If the personal library is a normal editable page, an editor can break the feature by moving or deleting its contents; a plugin-owned route cannot be broken that way.

• A plugin-owned, generated route, not editable as a WordPress page. (your answer, the default)
• An editable WordPress page that staff maintain, with guardrails against accidental breakage.

Every logged-in member can see any library, but the only address named was a self-view, so there was no defined way to browse another member’s collection.

• A stable per-member address, read-only to everyone but the owner. (your answer, the default)
• One self-only address, with other members’ libraries reached some other way, such as a directory or a modal.

The stated done-criteria only tested adding, viewing, and a status change showing in the feed, so a literal build could ship with no way to remove a game.

• Support add, status-change, and remove. (your answer, the default)
• Add and view only, with status-change as the sole edit and no remove in version one.

Version one has no engagement dashboard, but if these actions are not captured as they happen, a future dashboard could only be built from launch day forward.

• Ship basic event capture alongside the feature now, even with nothing consuming it yet.
• No separate event capture in version one; the activity feed’s own records of adds, changes, and follows suffice. (your answer)

Everything here is visible only to logged-in members, and joining collects an email, so member behavior identifies individuals in a way anonymous analytics does not.

• Use the same consent category as general analytics, and flag invite-email collection to whoever owns the privacy documentation. (your answer)
• Give member-activity tracking its own consent category, separate from anonymous analytics.

This is cheap to capture at registration and expensive to reconstruct later, even if nothing uses it in version one.

• Record the invite channel and the inviting member at redemption, even with nothing consuming it yet. (your answer)
• Don’t record it; capture only what version one needs.

Without a list view, whoever manages membership cannot check whether an invite arrived or clean up expired ones short of direct database access.

• Include an admin list of invites, with status, resend, and revoke, in version one. (your answer)
• Track invite state in the data model but don’t surface it in an admin screen for version one.

Because any member can already see any library, an approval step would not protect anything visibility does not already expose; it would only change what shows in a follower’s feed.

• One-directional and immediate, with no approval step. (your answer, the default)
• Follow requires approval from the followed member, with a request, accept, and decline flow.

Any wp-admin access beyond a member’s own profile is an unnecessary support surface for a front-end-only feature.

• The default Subscriber role, restricted to the front end with no wp-admin access beyond their own profile. (your answer)
• A custom role for library members, still restricted to the front end.
• Give members some wp-admin dashboard access.

If the size is meant as a ceiling, that is a registration rule to reject or queue invites past it, which was not stated anywhere.

• A planning assumption only, used for sizing caches and rate limits, with no enforced cap. (your answer, the default)
• A hard cap, where the system rejects or queues invites once membership reaches the limit.

You also corrected the size the plan should assume, from about 100 members up to about 1,000, and told the team to size caching, IGDB rate-limit handling, and query sizing accordingly: The ~100 figure came from a recommended default accepted without confirmation in the first discovery round and is now rejected.

If the plugin runs on a site that carries ads elsewhere, the new library, search, and feed pages would need to preserve those ad slots.

• The plugin runs standalone, with no advertising now or planned. (your answer, the default)
• The plugin runs alongside a site that carries ads, so ad-slot and layout constraints apply to the new pages.

A plugin-based hybrid would be faster to stand up, but the candidate plugins’ compatibility with this project’s conventions was assumed, not verified, and each would need its own data-export and erasure hooks confirmed.

• Build custom, native to this project’s conventions, with full control over the data model, erasure hooks, IGDB integration, and public-page output. (your answer, the default)
• A hybrid: install existing plugins for the social and invite layer, and build only the game-collection part custom.

This was a blocking check for the public catalog. The research agent could not reach IGDB’s terms directly to verify them, so every finding was a secondary source and the recommendation was to treat the question as open.

• Confirm directly with IGDB before any public-catalog work, then build it with a visible attribution line.
• Proceed now on the secondary-source indicators, with attribution built in and the surface ready to pull behind noindex quickly if the terms turn out to prohibit it. (your answer)

A public game page is shared by everyone who holds that game, so tying its removal to the member who first added it would take a popular page down for everyone still holding it.

• Key the page to the game, not to any one member; it persists while any active member holds the game, and erasure removes only the erased member’s own entries. (your answer, the default)
• Tie the page to the member who first added it, so erasing that member removes the public page even if others still hold the game.

Entries need to be filtered by member and status and kept out of the normal Posts screen, search, and feeds either way, and the choice is costly to change once entries exist.

• A custom table with indexed columns for faster per-member and per-status filtering, at the cost of hand-built admin and API surfaces. (your answer, the default)
• A custom post type with status as post meta, which gives free admin and API scaffolding but slower filtering at scale.

Every member’s library and feed is visible to every other member, with no pre-publish review, so after-the-fact correction is the only path.

• A minimal capability to correct a single cached game record and remove a single feed entry. (your answer, the default)
• No moderation tooling in version one; corrections happen through direct database access if needed.

A member flipping one game between statuses several times in a session could otherwise flood every follower’s feed with one entry per flip.

• One entry per status change, with no deduplication. (your answer, the default)
• Collapse repeated changes to the same game within a short window into a single updated entry.

This decides whether a background sync job is in scope at all, if IGDB later corrects a title, cover, or release date.

• Copy once on add, with a manual per-game refresh action for correcting a stale entry, and no background job. (your answer, the default)
• A scheduled background refresh that re-fetches cached games on a cadence.

The repository has no theme at all, so the badges, buttons, and forms this feature needs have nowhere to resolve design tokens unless something provides them by the time it ships.

• The plugin owns its tokens independently, with no dependency on a separate theme being installed. (your answer)
• The feature ships alongside a minimal theme whose token file these design tokens extend.

Member count is bounded at about 1,000, but each member’s library, follows, and activity generate rows, which affects the storage choice and whether the feed needs pagination from day one.

• Small: under 10,000 total rows even at five years.
• Medium: 10,000 to 1,000,000 rows, consistent with about 1,000 members each holding a few dozen to a few hundred games, follows, and feed rows. (your answer, the default)
• Large: over 1,000,000 rows within five years, which would need the storage and feed built for scale from day one.

The private, logged-in pages are bounded by the member count, but the public catalog exists to draw search traffic and could see much more if it ranks well.

• Low: under 10,000 pageviews a month across all surfaces.
• Medium: 10,000 to 1,000,000 pageviews a month across the private and public surfaces. (your answer, the default)
• High: over 1,000,000 a month, which would need the public catalog built for edge caching from day one.

The invite state machine was undefined, and a wrong guess here is expensive to unwind once members are registered against it.

• Four explicit states (pending, redeemed, expired, revoked), atomic redemption so a second concurrent attempt fails cleanly, and an already-registered email is told to log in instead. (your answer, the default)
• A simpler two-state active or inactive model, with duplicate redemptions and existing emails handled as generic errors.