Repository navigation
fix(listing): PermID listing only on OpenCheck's own GLEIF statement - #473
Merged
Merged
Conversation
…F statement Option C of the "PermID publicListing can be written onto Open Ownership's verbatim GLEIF statement" ticket. apply_to_bods picked the first statement resolving to gleif by description, which could be Open Ownership's stored statement in a curated bundle. The target is now listing.own_gleif_target: carries the LEI, stamped opencheckSourceId "gleif", published by OpenCheck. No fallback; without it the BODS carries no listing and the event and page line are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018BtA1PTjVwQtHVQNpe8Rha
Brings the branch up to date with main (Phases 389–390) before merging. Co-Authored-By: Claude <noreply@anthropic.com> Release-Steward: scheduled run 2026-10-21
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
2 participants
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.
Notion: https://app.notion.com/p/3ff7f3dc29288131be9dcdf425178cab
Option C of the ticket.
listing.apply_to_bodsused to putpublicListingon the first subject statement whose source resolved togleif. Open Ownership's stored GLEIF statements resolve togleifby their description, so in curatedbulkBodsbundles (BP, Rosneft…) the listing could end up inside another publisher'srecordDetails, which breaks the Phase 317 rule.listing.own_gleif_target(bods, lei): the entity statement that carries the LEI, is stampedsource.opencheckSourceId: "gleif"and is published by OpenCheck. That statement is the only possible target.integrated_ownership.annotation_target, because writing a field intorecordDetailschanges a statement more than adding an annotation. Without OpenCheck's own GLEIF statement, the BODS carries no listing. Thelistingevent, the page line, the report and the MCPlistingfield are unchanged.publicListingon an OO statement.docs/listing.mdand the Phase 236 section ofCLAUDE.md. Changeset in.phases/pending/.Local:
uv run pytest -q→ 8119 passed, 29 skipped, 3 xfailed; mypy ratchet clean;stamp_phase.py --checkok.After deploy: look up BP (
213800LH1BZH3DI6G760) and Rosneft (253400JT3MQWNDKMJE44). ConfirmpublicListingsits only on the statement whose publisher is OpenCheck.Generated by Claude Code