Record the v1.2.0 DOI, and stop the drift that keeps producing it - #102
Merged
Conversation
ZENODO AUTO-PUBLISHED. Creating the paper-v1.2.0 GitHub release minted 10.5281/zenodo.21997434 five seconds later. There was no draft and no approval step. SUBMISSION-CHECKLIST.md describes this step as "inspect the draft deposit, and publish it only after metadata approval", and the v1.2.0 line said publishing was an owner action. Neither is true of this repository's integration: creating a release here IS publishing a DOI. The documented gate does not exist in the mechanism it describes, which is the same failure class this repository studies, and the approval gate has to move earlier because there is no later one. Recorded in ARCHIVAL-INTEGRITY.md and re-opened as a checklist decision. The deposit itself is correct: version 1.2.0, isNewVersionOf the v1.1.0 DOI, open access. Nothing needs retracting, and a Zenodo record cannot be unpublished in any case, which is why the gate mattered. THE STRUCTURAL CAUSE, FOUND AND FIXED. Twice the repository source has drifted from a deposit for one reason: a version DOI is minted FROM the document, so a document cannot contain its own version DOI. Requiring it forces a choice between a false statement and an artifact that differs from what was deposited. v1.1.0 took the second horn; v1.2.0's transitional header took the first. check_peer_review_package.py PREVIOUSLY ENFORCED THE IMPOSSIBLE VERSION -- it required the version DOI to appear in the manuscript. It now requires the opposite: the manuscript cites the CONCEPT DOI 10.5281/zenodo.21965712, which is assigned once, never changes and always resolves to the latest version; the manuscript must NOT cite its own version DOI; the version DOI lives in metadata.json, CITATION.cff and ARCHIVAL-INTEGRITY.md. From v1.3.0 onward the manuscript needs no post-deposit edit, so source and deposit cannot diverge again. ONE-TIME DISCREPANCY, RECORDED NOT REPAIRED. The v1.2.0 deposit archives the tree whose header said a v1.2.0 deposit had not been created -- true when built, false five seconds later. No new version is cut to close it, because that would mint another DOI, date another header and require another version. That regress is exactly what the concept-DOI rule stops. Both PDF hashes are recorded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Two things: a DOI to record, and the reason it keeps being hard to record.
Zenodo auto-published
Creating the
paper-v1.2.0GitHub release minted10.5281/zenodo.21997434five seconds later. There was no draft and no approval step.SUBMISSION-CHECKLIST.mddescribes this as "inspect the draft deposit, and publish it only after metadata approval", and the v1.2.0 line said publishing was an owner action. Neither is true of this repository’s integration. Creating a release here IS publishing a DOI.I said the Zenodo step would wait for your approval. That was wrong, and the result is irreversible — Zenodo records cannot be unpublished. The deposit itself is correct (version 1.2.0,
isNewVersionOfthe v1.1.0 DOI, open access), so nothing needs retracting, but the gate has to move earlier because there is no later gate. Re-opened as a checklist decision: gate the release, or disable auto-publication.This is the same failure class the repository studies — a control described in writing and absent from the system it describes.
The structural cause, found and fixed
Twice now the source has drifted from a deposit, for one reason:
Requiring it forces a choice between a false statement and an artifact that differs from the deposit. v1.1.0 took the second horn; v1.2.0’s transitional header took the first.
check_peer_review_package.pywas enforcing the impossible version — it required the version DOI to appear in the manuscript. Now:10.5281/zenodo.21965712— assigned once, never changes, always resolves to latest;metadata.json,CITATION.cff, andARCHIVAL-INTEGRITY.md.From v1.3.0 onward the manuscript needs no post-deposit edit, so source and deposit cannot diverge again.
One-time discrepancy, recorded not repaired
The deposit archives the tree whose header said a v1.2.0 deposit had not been created — true when built, false five seconds later.
No new version is cut to close this, because that would mint another DOI, date another header, and require another version. That regress is exactly what the concept-DOI rule stops. It is one transitional sentence, it is recorded, and it terminates with v1.2.0.
paper-checkpasses; 426 passed, 8 skipped; integrity checks green.🤖 Generated with Claude Code