Repository navigation
Conversation
Nothing left the pipeline without a challenge value, so an outside contributor could not seal a set without running stage 9d. The tally now takes --unchallenged (never beside --challenge-run): every record a challenge would judge is stamped not_required, which the pages already read as unchallenged, so nothing is owed and a coverage claim upgrades nothing. Contribute mode's seal takes the same flag and refuses a campaign that names a challenge run for such a set.
Deicyde
marked this pull request as draft
November 12, 2026 20:42
… keeps Decision B5 gives a subject passage's records the article's Wikidata QID only once a challenger judged the location and the subject label, which is why a challenge_pending record carries none. A run sealed --unchallenged had no challenger at all, so the tally now marks its rows `unchallenged` and records.article_qid gives none of their records the QID. The docs quoted a page label, "unchallenged", that no page prints; they now say the records read "Not re-checked" and carry no QID. Tests: an unresolved passage of an unchallenged run is exported not_required; the expository passage's scope record is stamped too; an unchallenged seal holds exactly the records a challenged seal of the same run holds, so a dropped passage fails; and a subject record of an unchallenged run carries no QID while the same record of a challenged run does.
Deicyde
marked this pull request as ready for review
November 13, 2026 11:27
This was referenced Nov 13, 2026
Jack, 2026-11-13: "Carry the QID". The locate worker's subject call stands without a challenger, so records.article_qid gives an unchallenged run's subject records the article's QID, as it does any record but a challenge_pending one. The tally's per-row unchallenged mark, which only withheld it, is gone.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lets a set be sealed without a challenge run (stage 9d), so an outside contributor can send what their own locate run found, and so the waves can run without one (Jack, 2026-11-12: "Waves, no challenge"). Until now nothing left the pipeline without a challenge value: a contributor's seal refused every row unless they ran a challenge of their own.
What changes.
tally.py --unchallenged(refused beside--challenge-run) stamps every record a challenge would judgenot_required: locations, absences, unresolved and scope records, and coverage claims. That is the value a plan gives a record no rule required, so the record format, the intake contract, the store builder and the reader are untouched. A coverage claim stamped this way upgrades nothing, like any claim no challenge confirmed.run_package.py --stage seal --unchallengedpasses it through and refuses a campaign that names a challenge run (run:<run>+<challenge run>), since the pages would cite a challenge that never ran. The tally report gainsunchallenged.QIDs. Jack, 2026-11-13: "Carry the QID". A subject passage's records of an unchallenged run carry the article's Wikidata QID, as any record but a
challenge_pendingone does (decision B5): the locate worker's subject call stands without a challenger.test_records.pypins it.What the pages say. A run-less
not_requiredrecord reads "Not re-checked: no challenge was required." The second half was written for records a plan exempted, so #192 changes the reader to say "Not re-checked." when no challenge run is named. That iswiki/src, release-affecting, so it waits for the next release; until then the sentence is true of these sets only in the sense that no challenge was asked for.The same flag would let WikiLean's own runs skip the challenge, if that is wanted; nothing here changes how they run today.
Release.
scripts/anddocs/only, so release-neutral.Checks. CI on 46a8d68: worker, python (tally, records and contribute tests), browser and attribution passed.
https://github.com/Deicyde/WikiLean/actions/runs/43512599537