scholarr: decide D2 unfollow retention, the favorite column, legacy read collapse, and the NEW rule #2

New issue

Open

opened 2026-08-20 11:32:04 +02:00 by justinzeus · 0 comments

justinzeus commented

2026-08-20 11:32:04 +02:00

Owner

Charter: runbooks/rewrite/charter.md

Goal

Owner decision D2 is answered on the record, and docs/specs/data-model.md reflects the answer.

Constraints

One of the seven blockers from the Card C.1 independent architecture review (2026-07-23, four adversarial dimensions over the e36e486 draft), which returned NO-FREEZE. All seven were spec-text gaps, not design flaws; the revision applying every finding is committed at a8c5939.
The question: Four coupled sub-decisions about per-user state, split out of the original D2 by the review: D2a unfollow retention, D2b the favorite column, D2c legacy read collapse, D2d the NEW rule.
The draft's recommended answer: D2a: hide publications with no remaining active follow path but retain read and favorite state; refollow restores it. D2b: migrate and retain favorited_at as a consciously carried dead column despite no v1 favorite control. D2c: a legacy publication is read if any legacy link for that user says read, deliberately lossy because unread-that-should-be-read is the worse watchlist error. D2d: derive NEW at read time only from recent incremental_sync origins within the service-wide new_window; never persisted.
What answering it decides: What survives an unfollow, what the one-time legacy import preserves, and whether NEW is stored state or a read-time derivation. D2c is irreversible against the seed dataset: the collapse happens once, at import.
This is an owner decision. An agent may lay out consequences and tradeoffs; it may not answer it.
The answer goes in the ## Owner decisions table of docs/specs/data-model.md, and any spec text it changes is edited in the same change.
The immutable doctrine in the charter binds any answer: no Google Scholar network contact, official APIs only, SQLite only, FollowedAuthor as the root entity.
Kept as one issue because the four are one coupled question about per-user state, and answering any one alone constrains the others. Answer all four together, and record all four.

Acceptance

The answer is recorded in the ## Owner decisions table of docs/specs/data-model.md
Any spec text the answer changes is edited in the same commit
The decision and its reasoning are stated in a closing comment here

Next action

Put D2 in front of the owner with the recommended answer and its consequence.

Charter: runbooks/rewrite/charter.md ## Goal Owner decision **D2** is answered on the record, and `docs/specs/data-model.md` reflects the answer. ## Constraints - One of the seven blockers from the Card C.1 independent architecture review (2026-07-23, four adversarial dimensions over the `e36e486` draft), which returned **NO-FREEZE**. All seven were spec-text gaps, not design flaws; the revision applying every finding is committed at `a8c5939`. - **The question:** Four coupled sub-decisions about per-user state, split out of the original D2 by the review: **D2a** unfollow retention, **D2b** the favorite column, **D2c** legacy read collapse, **D2d** the `NEW` rule. - **The draft's recommended answer:** **D2a:** hide publications with no remaining active follow path but retain read and favorite state; refollow restores it. **D2b:** migrate and retain `favorited_at` as a consciously carried dead column despite no v1 favorite control. **D2c:** a legacy publication is read if any legacy link for that user says read, deliberately lossy because unread-that-should-be-read is the worse watchlist error. **D2d:** derive `NEW` at read time only from recent `incremental_sync` origins within the service-wide `new_window`; never persisted. - **What answering it decides:** What survives an unfollow, what the one-time legacy import preserves, and whether `NEW` is stored state or a read-time derivation. D2c is irreversible against the seed dataset: the collapse happens once, at import. - This is an **owner decision**. An agent may lay out consequences and tradeoffs; it may not answer it. - The answer goes in the `## Owner decisions` table of `docs/specs/data-model.md`, and any spec text it changes is edited in the same change. - The immutable doctrine in the charter binds any answer: no Google Scholar network contact, official APIs only, SQLite only, `FollowedAuthor` as the root entity. - Kept as one issue because the four are one coupled question about per-user state, and answering any one alone constrains the others. Answer all four together, and record all four. ## Acceptance - [ ] The answer is recorded in the `## Owner decisions` table of `docs/specs/data-model.md` - [ ] Any spec text the answer changes is edited in the same commit - [ ] The decision and its reasoning are stated in a closing comment here ## Next action Put D2 in front of the owner with the recommended answer and its consequence.