Wikidata entity read path: platform wikibase module + patrol MVP (ADR-0016 / PRD-0011)

[tieguy]

Summary

Implements ADR-0016 (the Wikidata entity read mechanism) end to end and the PRD-0011
patrol-read MVP: picking wikidatawiki in the existing picker now yields a
readable, classified entity diff instead of a raw JSON line-diff, with the
queue/scoring gates in place. Wikitext review is byte-for-byte untouched throughout —
routing keys on the revision's content model, never the wiki id.

Seven commits, layered platform → shells:

1. sp42-platform::wikibase — the shared read model: typed entity/statement/snak
   values (each statement keeps its canonical raw JSON so change detection is exact
   for unmodeled datatypes; references keep the full snak set with P854 as one
   property), endpoint-agnostic parse_entity (Special:EntityData docs with redirect
   tolerance, or bare prop=revisions slot content), pure request builders over the
   HttpClient boundary, claim rendering, full-depth EntityDiff with the
   never-a-no-op honesty invariant (qualifier-only/rank-only/reference-only edits
   classify; unmodeled deltas surface as parts.other / UnknownEntityChange),
   ContentDiff routing, and the content-model capability axis.
2. sp42-mcp refactor — verify_wikidata_statement consumes the platform model
   (ADR-0016 Decision 2 promotion); its public contract and all three tests are
   unchanged.
3. EditEvent.content_model — additive Option<String> (serde default/skip;
   old snapshots deserialize unchanged). None = honestly unknown.
4. Revision-content parse + route_content_diff — the one-call
   prop=revisions…contentmodel diff fetch and the Decision 4 routing helper with
   honest degradation (unparseable entity → text; a broken before never fabricates
   an all-added diff).
5. Server — new /operator/content-diff/{wiki}/{rev}/{old} route returning
   ContentDiffReport (routed diff + labels resolved server-side in one batched
   wbgetentities call, best-effort). Media-reference extraction is not invoked for
   entity content. /operator/diff unchanged.
6. Browser — the patrol diff pipeline dispatches on the report: text → existing
   viewer/caches untouched; entity → new EntityDiffViewer ("educated at: University
   of X", added/removed/changed rows with changed-parts summaries).
7. MVP gates — ingestion seeds content_model from per-namespace site defaults
   (wikidata.org ns 0/120 → item/property; talk pages stay wikitext); entity events
   score a uniform base with zero signal contributions (chronological queue over the
   bot-excluded-by-default stream, PRD-0011 Q3); no LiftWing request is built for
   entity content; testwikidatawiki patrol/rollback covered by a mock write-path test.

Type

• Bug fix
• Feature
• Refactor
• Documentation
• Build, CI, or release
• Security-sensitive change

Validation Required

cargo clippy --workspace --exclude sp42-desktop --all-targets   # pedantic clean
cargo test --workspace --exclude sp42-desktop                   # 870 passed, 0 failed
./scripts/check-layering.sh                                     # passes (wikibase is platform)
cargo check -p sp42-app --target wasm32-unknown-unknown         # passes
cargo fmt --all --check

The one manual gate left from the PRD-0011 DoD is the live action acceptance on
test.wikidata.org (one real patrol/rollback, rev id recorded here) — that is the
dogfood step this PR enables.

Risk

• Touches auth/session/cookies/CSRF
• Touches deployment/runtime configuration
• Touches desktop packaging
• Touches scoring or Wikimedia action behavior
• Needs an ADR

Scoring behavior changes only for entity-content events (uniform base score, no
heuristic contributions, no LiftWing) — wikitext scoring is untouched, locked by a
test asserting the same event scores signals as wikitext and base-only as an entity.
Action behavior is unchanged (the new test only proves the existing generic path
works against test.wikidata.org). Governed by ADR-0016 (Proposed, in-tree).

Notes For Reviewers

• One deliberate deviation from ADR-0016 Decision 1's wording:
  EditEvent.content_model is Option<String> with None = unknown, rather than a
  serde default of "wikitext". A literal wikitext default would mislabel Wikidata
  events from ingestion sources that don't carry a content model; Option keeps old
  snapshots deserializing (the ADR's actual intent) while staying honest. Capability
  derivation treats None as pre-ADR behavior (wikitext signals on).
• Namespace-default seeding (default_namespace_content_model) mirrors
  MediaWiki's $wgNamespaceContentModels: it is a property of the site's namespace
  configuration that seeds the per-revision value routing keys on — a Wikidata
  talk-page edit stays on the wikitext path. Scoped to the wikidata.org family;
  other Wikibase hosts are additive.
• Convergence with Citation verification over MCP — read-only agent surface (MVP) #103 delivered: sp42-mcp/src/wikidata.rs now consumes the
  platform parser per the merged design plan
  (docs/design-plans/2026-07-01-wikidata-read-model.md); the two Wikidata read
  implementations are one.
• Places most worth scrutiny: the statement pairing rules in diff_entities
  (GUID-first, raw-equality fallback, id-less edits show as removed+added), the
  honest-degradation branches in route_content_diff, and the label-resolution
  error path in the server (failures render raw ids, never fail the diff).

🤖 Generated with Claude Code

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8aa2a003e7

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Fetch entity diff before accepting cached text diff

When the initial live-operator payload already includes a selected Wikidata edit, cache_initial_artifacts stores the server-provided raw text diff in diff_cache but the view has no ContentDiffReport. This cache-hit branch then clears current_entity_diff and returns before the new content-diff endpoint is fetched, so the initially selected entity revision renders raw JSON instead of the entity diff viewer until the cache is invalidated. Skip the text cache for entity content or check/fetch the content diff before returning here.

Useful? React with 👍 / 👎.

[tieguy]

Correct — the initial payload's server-computed text diff shadowed the entity view for the initially selected edit. Fixed in 786a0ca: cache_initial_artifacts now skips seeding entirely when the selected edit's content model classifies as entity (derive_content_model_capabilities(...).entity_diff), so the selection effect cache-misses and fetches the content diff. The event carries content_model from ingestion (namespace-default seeding), which is what makes this check possible client-side without a fetch.

---

Generated by Claude Code

[tieguy]

(Threading note: the follow-up round's fixes are in 49a0cf3 — see the two new thread replies.)

---

Generated by Claude Code

[tieguy]

Codex's third-round comments (changed-subpart details, statement reorders) are both valid and are fixed in the stacked follow-up #120, where the row rendering now lives (it moved from this component into the platform's shared render_entity_diff_report as part of the slim-report refactor). Fixing them here would have churned code #120 deletes.

---

Generated by Claude Code

[chatgpt-codex-connector]

Preserve first-revision entity diffs

For a newly created Wikidata entity, old_rev_id is absent (or passed as 0 by the client), so the lookup contains only the new revision and this branch returns None. That bypasses route_content_diff's before: None path that produces an all-added entity diff, leaving new items/properties with no structured diff at all. Treat a missing/zero old revision as before = None and route the fetched after content instead of dropping the artifact.

Useful? React with 👍 / 👎.

[tieguy]

Correct — new entities never reached route_content_diff's before: None path. Fixed in 786a0ca: old_rev_id == 0 now fetches only the new revision and, for entity content, routes as a first revision (all-added EntityDiff, per ADR-0016 Decision 3). Two deliberate boundaries: a first wikitext revision keeps today's no-artifacts behavior (the wikitext path stays byte-for-byte untouched), and a nonzero-but-missing parent (deleted/suppressed revision) still yields None rather than being passed off as a first revision — an all-added diff there would be dishonest.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 786a0cae16

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Gate selected diff scoring hints for entity content

When the selected item is wikibase-item/wikibase-property, this guard skips LiftWing, but the same function still fetches the raw JSON StructuredDiff and runs analyze_diff_for_scoring below, populating link/reference/category/profanity flags in scoring_context for entity revisions. That exposes wikitext-only signal state for Wikidata entity reviews even though entity scoring is supposed to have no wikitext signal contributions; skip the diff-hint path whenever derive_content_model_capabilities(...).wikitext_signals is false.

Useful? React with 👍 / 👎.

[tieguy]

Correct — the LiftWing guard didn't cover the hint pass, so entity revisions still got wikitext signal state (links/references/profanity/blanking) populated into the scoring context from their raw-JSON text diff. Fixed in 49a0cf3: the analyze_diff_for_scoring block is now gated on derive_content_model_capabilities(...).wikitext_signals for the selected item, so entity content gets neither LiftWing nor wikitext hint state — matching the scoring engine's uniform-base behavior (ADR-0016 Decision 5).

---

Generated by Claude Code

[chatgpt-codex-connector]

Gate media extraction on content model, not parse success

If a revision declares an entity content model but route_content_diff falls back to Text because the entity JSON is malformed or no longer matches the parser, content_diff is None and this branch invokes build_media_diff on the entity JSON. Media-reference extraction is a wikitext-only path, so the gate should key off after.content_model/capabilities rather than whether the structured entity diff parsed successfully.

Useful? React with 👍 / 👎.

[tieguy]

Correct — gating on content_diff.is_some() conflated "is entity content" with "entity parse succeeded", so malformed entity JSON fell through to wikitext media extraction. Fixed in 49a0cf3: the media gate now keys on derive_content_model_capabilities(after.content_model.as_deref()).wikitext_signals — the content model itself — so declared-entity revisions never run the wikitext-only path regardless of parse outcome.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 91e0004e3c

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Track statement reorders in entity diffs

When a Wikibase edit only reorders statements within the same property, the paired statements still have the same GUIDs and identical raw JSON, so this branch consumes them without pushing any StatementChange. The resulting EntityDiff can be empty and the UI will report no entity changes for a real revision whose display/order changed; compare the matched index with the original position or carry an explicit order-change part before continuing.

Useful? React with 👍 / 👎.

[tieguy]

Closing the loop now that #120 has been folded into this branch: this is fixed in-branch. diff_statement_lists tracks matched positions and emits StatementChange::Reordered { property } when pairing consumed statements out of order (matched_positions.windows(2).any(|p| p[0] > p[1])), so a reorder-only edit is no longer a no-op; the report renders it as a dedicated row. Covered by a reorder-only regression test.

---

Generated by Claude Code

[chatgpt-codex-connector]

Render changed statement subpart details

For edits where only a statement's qualifiers, rank, or references change, the before/after main value is usually identical, so this formatter renders only something like P123: X → X (references changed) and hides the actual reference URL, qualifier, or rank delta already present in before/after. In those cases reviewers cannot tell what changed from the entity diff view; include the changed subpart values when the corresponding parts flag is set.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ff085a9389

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve sitelink badge-only changes

When an edit only changes a Wikibase sitelink badge while the linked title stays the same, this parser keeps only the title. Since sitelinks is also treated as a modeled top-level key instead of being preserved in extra, diff_entities compares identical site-to-title maps and emits neither a SitelinkChange nor an UnknownEntityChange, so the entity diff can report no changes for a real entity edit. Preserve/diff the badge payload, or keep the raw sitelink data for unknown-change detection.

Useful? React with 👍 / 👎.

[tieguy]

Correct — sitelinks were parsed down to bare titles, so a badge-only edit compared equal and produced an empty diff, violating the module's own never-a-no-op invariant. Fixed in 0f8596e: sitelinks now parse as WikibaseSitelink { title, badges }, struct equality drives the diff (badge-only edits emit a SitelinkChange), and change rows carry the display form ("Douglas Adams [Q17437796]") so the wire shape of SitelinkChange is unchanged. Covered by a badge-only regression test asserting has_changes().

---

Generated by Claude Code

[chatgpt-codex-connector]

Include quantity units in rendered values

For a statement whose quantity unit changes but the numeric amount stays the same, statement_change_parts correctly marks the main value as changed, but this renderer drops the unit field and both sides display as the same amount. The entity diff then renders a row like P…: 5 → 5, hiding the actual unit change from reviewers; include the unit (or resolved unit entity) in the value text.

Useful? React with 👍 / 👎.

[tieguy]

Correct — the renderer dropped unit, so a unit-only change displayed as 5 → 5 even though the change was detected. Fixed in 0f8596e: quantity rendering now appends the unit entity id ("5 Q11573", extracted from the unit URI tail), and the dimensionless unit stays a bare amount. Resolving the unit id to its label is left as the "richer datatype rendering" follow-on the module already notes — the id makes the change visible; the label would only make it prettier.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0f8596ec16

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Include property namespace in Wikidata patrol defaults

This adds wikibase-property routing for namespace 120, but a derived wikidatawiki config still uses the shared default namespace allowlist [0,2,4,6,10,14], and the patrol filter UI does not offer namespace 120 either. In the Wikidata property-review case, unfiltered queues never request property edits and reviewers cannot select that namespace from the UI, so this new property diff path is effectively unreachable except via a hand-crafted query string; add namespace 120 to the Wikidata defaults/filter options along with this classifier.

Useful? React with 👍 / 👎.

[tieguy]

Correct — the routing existed but nothing fed it: derived wikidatawiki queues never requested namespace 120 and the filter offered no way to add it. Fixed in 25973fa: derive_wiki_config appends 120 to the allowlist for sites with an entity Property namespace (keyed on the same default_namespace_content_model(api_url, 120) check the routing uses, so the two can't drift), and the filter bar gains a Property checkbox. The checkbox appears in the static option list for all wikis (matching how the list already works), but it is default-selected only where the wiki's server-resolved defaults include 120 — enwiki reviewers see it unchecked. Regression test asserts wikidatawiki's derived allowlist contains 120 and enwiki's does not.

---

Generated by Claude Code

[chatgpt-codex-connector]

Seed content model for browser EventStreams inserts

When a Wikidata item/property edit arrives through the browser EventStreams path after the initial load, this queues it with content_model: None while the score above has already been computed with wikitext-style byte/identity signals. The server recentchanges and stream ingestor paths now seed Wikidata namespace defaults, so only these live browser inserts are treated as unknown/wikitext instead of entity content, which can mis-rank them in the queue; seed the same content model (and score through the entity gate) before inserting the event.

Useful? React with 👍 / 👎.

[tieguy]

Correct — the browser's live insert was the one ingestion path left unseeded, so a post-load Wikidata edit queued as unknown/wikitext with byte/identity signals while its initial-load neighbors scored as entities. Fixed in 25973fa: stream_event_to_queued_edit now seeds the content model via a new dbname-keyed platform helper (default_namespace_content_model_for_wiki, sharing the same namespace→model core as the api-url-keyed form — browser surfaces hold the wiki_id, not the api url), and entity content mirrors the scoring engine's gate: no wikitext identity/byte contributions, so live entity inserts stay chronological (PRD-0011 Q3). Tests cover the wikidata ns-0 (seeded, zero contributions), wikidata talk-page (wikitext path kept), and enwiki (signals kept) cases.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 25973fa295

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve quantity bounds in entity value diffs

When a Wikibase quantity changes only its uncertainty bounds (lowerBound/upperBound) while the amount and unit stay fixed, the raw mainsnak makes statement_change_parts emit a value change, but this parser keeps only amount/unit and the row renderer has no bound data to print. Reviewers then see an entity diff like P…: 5 → 5 with no indication of the actual bound edit; keep/render the bounds or add an explicit value-change detail for omitted quantity fields.

Useful? React with 👍 / 👎.

[tieguy]

Correct, and worth fixing at the family level rather than field by field. Fixed in 054c489 twice over: (1) quantity values now keep and render their bounds ("5 [4.8..5.2] Q11573"), so a bounds-only edit is visible directly; (2) a general honesty backstop in the changed-row details — when the raw main value moved (parts.value) but the best-effort renderer produces identical text on both sides, the row is annotated value details beyond the rendered form changed instead of silently presenting X → X. That covers today's remaining case (a calendar-model-only time edit, which is the regression test) and any future datatype detail the renderer doesn't model yet, so this class of finding can't recur silently.

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f2a003b887

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Include subpart details for added/removed statements

When a Wikibase edit adds or removes a statement that carries qualifiers, a non-normal rank, or references, this branch renders only statement_row_text, which contains the property and main value. In that scenario the entity diff hides the added/removed reference URL, qualifier values, and rank entirely, so reviewers cannot inspect the full statement being introduced or deleted from the patrol surface; include the same subpart rendering used for changed statements for added/removed rows as well.

Useful? React with 👍 / 👎.

[tieguy]

Correct — an added/removed statement's qualifiers, rank, and references were invisible; the row showed only the property and main value. Fixed in 23f8f26: added/removed rows now share the changed-row subpart rendering (P800: v (qualifiers [P580: 1979]; rank preferred; references [P854: https://…])), with each part included only when informative — qualifiers/references when present, rank when non-normal — so bare statements keep the plain row. Regression test covers both directions plus the bare case.

---

Generated by Claude Code