The opt-in configuration is defined and owned by WikiLambda's own code, using the CommunityConfiguration extension as the surface through which sysops edit it. The schema, the validation rules, the collision-detection logic, and the render-time lookup all live in WikiLambda; CommunityConfiguration provides the editing UI, the permission check, the persistence, and the audit log. That division matters both conceptually and for code ownership: bugs in the schema or the render path are WikiLambda's, bugs in the editing experience are CommunityConfiguration's, and a reviewer reading this bullet should come away knowing that we are consumers of the CommunityConfiguration extension rather than extending it from inside.
Acceptance criteria:
- A CommunityConfiguration schema owned by WikiLambda is registered and exposed to sysops on Test Wikipedia via CommunityConfiguration's editing surface.
- The schema captures QID (validated as Q\d+), local title (validated as a namespace-less MediaWiki title), and an optional free-text rationale, with uniqueness enforced on both QID and local title within the opt-in set.
- A new wikilambda-abstract-optin user right is registered and assigned to the sysop group by default, re-assignable by the standard $wgGroupPermissions mechanism without code changes.
- The wikilambda-abstract-optin right is also granted to the stewards and global sysops global groups via WMF mediawiki-config, matching the cross-wiki posture of wikilambda-abstract-purge.
- Editing the opt-in set through CommunityConfiguration produces entries in CommunityConfiguration's built-in audit log, verified by inspecting a test edit.
- The config UI shows a non-blocking alert for every configured entry whose local title currently collides with an existing local article; the alert updates when the underlying collision state changes, verified by creating and deleting a colliding local page in testing.
- The render-time lookup from local title to QID is implemented as a WANCache-backed lookup of the opt-in set, populated through CommunityConfiguration's config-read API on cache miss and invalidated across DCs via WANCache's standard purge path.
- A naive implementation that hits the underlying configuration store on every article read is not present, verified by code review of the hot path.
- The schema is shaped with the future opt-out / blocklist mode in mind (versionable or extensible with a mode field, render-time lookup not hard-coding allowlist assumptions, internal naming not baking "opt-in" into type/class/API surfaces where a more neutral term would survive the inversion).