The goal of this milestone is that a reader on a client wiki, navigating to what looks like a normal mainspace URL, sees a fully rendered Abstract Content article — with a prominent, non-dismissible banner above the content explaining that what they are reading is Abstract Content drawn from abstract.wikipedia.org and displayed on their local wiki for their convenience, not a locally-authored article. The reader experience is the point of the milestone. The underlying mechanism is a sysop-driven opt-in via CommunityConfiguration, and the sysop is the supporting actor who enables that experience for a given topic on their wiki, but the reader — arriving at a URL from a link or from a community member sharing one — is who M2 is designed for.

The rendering reuses the M1 component unchanged, the banner is the M1 banner with its pre-planned slot populated by a sysop deactivate CTA, and the page carries the metadata a crawler needs to treat it as a real mainspace article. This is the milestone the Q1 readiness hypothesis is ultimately about: shipping M0 and M1 without M2 would give us a cross-wiki read path and a special page but no pilot-ready surface to show a candidate community, and shipping M2 is what converts the whole earlier stack into "a thing Product can demo".

M2 is structurally different from M0 and M1 because it is the first milestone that touches mainspace on a client wiki. Everything before this point has been either repo-side work on abstract.wikipedia.org (M0) or a contained special-page surface on Test Wikipedia (M1) where readers had to actively navigate to a URL that nobody would mistake for a regular article. In M2, the URL of an opted-in abstract article looks like a normal mainspace URL, so that a reader arriving from a link lands on it naturally without having to know it is a special kind of page. That URL-level indistinguishability is what makes the pilot demonstrable; it is explicitly balanced by the visually prominent, non-dismissible banner above the rendered content, which makes the provenance impossible to miss. M2 is an augmentation of the local wiki's content, not a replacement of it, and the sub-bullets below are shaped around that principle: the opt-in flow is sysop-controlled, collisions with pre-existing or subsequently-created local articles are always resolved in favour of the local article, and the banner makes the provenance unmistakable to any reader of any opted-in page. This framing matters not only for the design but because these tasks are public; a casual reader of the epic should come away understanding immediately that we are not proposing to displace community-authored content under any circumstances.

The collision policy in concrete form: when a sysop opts an abstract article in via CommunityConfiguration, they choose the local title under which it should appear on their wiki, and they are the ones responsible for picking a title that does not collide with any existing local article at the moment of opt-in. If a local article is subsequently created at that title (either by direct authorship or by a page move), the local article wins automatically — the opted-in abstract article becomes inaccessible at that title without any action on the sysop's part — and the CommunityConfiguration page shows an alert for every opted-in entry whose configured title has become colliding, so that sysops can see at a glance which opt-ins are currently not surfacing and decide what to do about each one. The specifics of how the alert is rendered and how the "local wins" check is wired in at render time are spelt out in the CommunityConfiguration and mainspace-rendering sub-bullets below.

Out of scope for M2, to prevent scope drift into M3 or into non-goals we committed to in the preamble:

• Local editing of opted-in abstract articles (preamble non-goal; edit tabs point cross-wiki via the mechanism M1 established).
• Integration with the local wiki's internal search surfaces — typeahead and CirrusSearch main search — which is the M3 stretch milestone.
• Revision history, watchlist, Special:WhatLinksHere, Special:RecentChanges, and XML dump representation of opted-in abstract articles. These are real concerns but handling them in M2 would balloon the milestone; they are flagged in the relevant sub-bullets as known-deferred and will be picked up in post-pilot work if pilot feedback shows they are blocking.
• Mobile app and MobileContentService parity. The mobile web skin (Minerva) is in scope because the M1 rendering component already supports it; the Wikipedia apps pull from REST surfaces that are outside WE2's purview and are explicitly deferred.