Skip to content

Document open question: does Aug 28's vigil reading set apply to Greek? - #217

Closed
brianglass wants to merge 1 commit into
mainfrom
document-aug28-greek-readings-question
Closed

Document open question: does Aug 28's vigil reading set apply to Greek?#217
brianglass wants to merge 1 commit into
mainfrom
document-aug28-greek-readings-question

Conversation

@brianglass

Copy link
Copy Markdown
Owner

Summary

Doc-only change, no code/data touched. Follow-up to #215/#216.

While tracking down the fast_exception bug, Brian noticed Aug 28's scripture readings include a full vigil package (Vespers OT lessons, Matins Gospel, "St Job" Epistle/Gospel) shared by both traditions via tradition='common', for what's specifically a Slavic/ROCOR saint (Job of Pochaev). OCA's own page confirms this set is correct for Slavic. For Greek, antiochian.org's own citations only show the ordinary Epistle/Gospel; a linked "Great Vespers" PDF turned out to be cross-linked Aug 29 content (Beheading of John the Baptist, served the evening before), not evidence either way for Aug 28. Checked goarch.org too; also inconclusive.

No confirming evidence either way, so left the reading data as-is -- per this project's standing rule (see docs/saint-dedup-2026-08.md's verification bar), data doesn't get changed on inference alone. Logging this here so it isn't re-investigated from scratch if it comes up again.

Test plan

  • N/A -- documentation only, no behavior change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Hf6j2xXQXywHVh3HAVRxB3

While investigating the fast_exception bug (#215/#216), Brian noticed
Aug 28's scripture readings include a full vigil package (Vespers OT
lessons, Matins Gospel, "St Job" Epistle/Gospel) shared by both
traditions via tradition='common', for a specifically Slavic/ROCOR
saint (Job of Pochaev). OCA's own page confirms this set for Slavic.
For Greek, antiochian.org's citations only show the ordinary Epistle/
Gospel; a linked "Great Vespers" PDF turned out to be cross-linked
Aug 29 content (Beheading of John the Baptist, served the evening
before), not evidence either way for Aug 28. Checked goarch.org too;
also inconclusive.

No confirming evidence either way, so left as-is per this project's
standing rule against changing data on inference alone. Logged for
whoever picks this up next.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hf6j2xXQXywHVh3HAVRxB3
@brianglass

Copy link
Copy Markdown
Owner Author

Consolidated into #224. The open question this documented is now resolved: antiochian.org shows only the ordinary daily cycle on Aug 28 in 8 of 8 years (2019-2026), goarch.org agrees for 2026, and the six rows are retagged common -> slavic there.

The one durable finding here is carried over rather than lost -- the "Great Vespers" text linked from Aug 28 is actually Aug 29's Beheading service, cross-linked from both dates. That is now a Part II source trap in docs/greek-lectionary.md, since it is exactly what made the evidence look inconclusive.

@brianglass brianglass closed this Aug 28, 2026
brianglass added a commit that referenced this pull request Aug 28, 2026
… commit #220 dropped (#224)

* Add the 2020 Antiochian ordo rows; note why 2027 is not available

Harvesting the three ordo dates for 2020 filled the one gap in the Antiochian
side within its published range. The two jurisdictions now share 19 dates and
differ on five, up from four -- 2020-01-24 is a new one, where GOA reads
Matthew 22:1-14 and Antiochian Mark 12:1-12, and both are now shown labelled.

2027 could not be harvested: those dates return HTTP 500. That is not an API
horizon. The Antiochian liturgical chart is published a year at a time and
2027's does not exist yet, so the ordo has not been established. The doc now
says that rather than describing it as a reach limit, since the two call for
different responses -- wait and re-harvest, not give up.

Until then January 2027 shows GOA's reading alone and unlabelled, which is the
correct behaviour: a jurisdiction is only named when there is another to
contrast it with, and no contrast has been observed for that date.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019nQRjJpPqW89xqzAf1vsEX

* Aug 28's vigil set is Slavic only, not common

Resolves the open question logged in PR #217. Aug 28 carried a full vigil
package tagged `common` -- three Vespers Old Testament lessons, a Matins
Gospel, and a proper Epistle and Gospel -- for Job of Pochaev, a
17th-century Ukrainian saint kept in the Russian church. Greek was being served
a saint it does not commemorate.

#217 deliberately left the data alone because the evidence then was
inconclusive, and this project does not change reading data on inference. It is
now settled:

  * antiochian.org shows only the ordinary daily cycle on Aug 28 in 8 of 8
    harvested years (2019-2026), always titling the day with the plain cycle
    label and never naming a commemoration.
  * goarch.org agrees for 2026: 2 Cor 11:5-21 / Mark 4:1-9.
  * oca.org confirms the set is right for Slavic.

The absence is evidence rather than merely uninformative, which is the part the
earlier pass could not establish. The same antiochian.org feed demonstrably
does surface a saint's proper readings when one applies -- that is how most of
the Greek Menaion data in this project was found, and on Jul 5 this very
Epistle shows up for Athanasius of Athos.

Six rows retagged common -> slavic. Slavic unchanged; Greek now shows the
daily cycle alone. TestAug28JobOfPochaev covers both directions and that the
day is not left empty.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019nQRjJpPqW89xqzAf1vsEX

* Cross-check the Greek Menaion rows against oca.org

The ten Menaion readings added in #220 were scoped `greek` because no OCA
source was to hand to say whether Slavic keeps them. oca.org's daily readings
are plainly fetchable, so the question is now settled rather than assumed.

Nine of the ten are correctly `greek`: on each date oca.org either gives a
different reading (Apr 25, Apr 30, May 7, and Jul 5's Gospel) or none at all
(Jul 13, Aug 31, Sep 24, Dec 17).

The tenth is shared -- both traditions read Gal 5:22-26; 6:1-2 on Jul 5 -- but
should stay as two rows rather than collapse to one `common` row. They carry
different attributions and both are right: Slavic's says "either Saint",
because OCA commemorates Athanasius and the uncovering of Sergius of
Radonezh's relics that day and the Epistle serves either, while Greek's names
Athanasius. Merging would force one tradition's attribution on the other.

Also adds oca.org to Part II's source notes, including the trap that surfaced
here: a commemoration appearing on the page does not mean it has proper
readings. oca.org lists the Appearance of the Cross on May 7 and the Myrtle
Tree icon on Sep 24 and gives neither a Liturgy reading.

Incidentally, on all eight dates the app's Slavic output matches oca.org
exactly, Vespers and Matins included -- the first direct check of the Slavic
data against its own source anywhere in the doc.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019nQRjJpPqW89xqzAf1vsEX

* Salvage the Great Vespers source trap from PR #217

PR #217 logged the Aug 28 question and left the data alone. Its conclusion is
superseded, but the reason the evidence looked inconclusive is durable and was
not captured anywhere else: antiochian.org's Aug 28 page links a "Great
Vespers" service text that is actually Aug 29's Beheading of John the Baptist,
served the evening before and cross-linked from both dates.

Recorded as a Part II trap so closing #217 does not lose it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019nQRjJpPqW89xqzAf1vsEX

* Keep ordo pks stable across loader runs; correct the dump indent

load_ordo.py emptied OrdoReading and rebuilt it on every run, so adding a
single harvested date renumbered every row. That is why this branch's fixture
diff touches 119 pk lines to add one row: the churn buried the change.

Replace the up-front delete with a prune of what the sources no longer produce.
update_or_create then keeps a surviving row's pk, and re-running the loader over
unchanged sources is a no-op against the fixture.

Nothing references these rows -- OrdoReading is the target of no foreign key,
and both the runtime lookup and the tests address rows by their natural key
(jurisdiction, year, month, day, source) -- so the pks were free to move. This
is about diff legibility, not correctness.

Also correct the docstring's dump command from --indent=1 to --indent=2.
The fixture is stored at 2, and load_shared_menaion.py already said so; dumping
at 1 reformats all ~62,000 lines and has caused exactly that once already.

Verified: loading the fixture, re-running the loader and dumping produces an
empty diff, with all 60 rows keeping their pks; and a row the sources no longer
produce is still removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019nQRjJpPqW89xqzAf1vsEX

* Regenerate the fixture with the ordo pks main already had

The 119 pk lines in this branch's fixture diff were produced by the old
delete-and-rebuild loader, before the previous commit fixed it. Fixing the
loader stops future churn but does not undo churn already committed, so the
diff still renumbered every ordo row from main's 60-118 to 119-178.

Rebuilt on top of main's own pks with the corrected loader. The fixture diff
against main is now exactly the six Aug 28 `common` -> `slavic` retags and the
one added 2020-01-24 antiochian ordo row -- 1 pk line touched instead of 119.

No data changed; 189 tests still pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019nQRjJpPqW89xqzAf1vsEX

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
@brianglass
brianglass deleted the document-aug28-greek-readings-question branch August 28, 2026 16:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant