THOTH-CHAPTER-01: Enforce a single parent for chapter works

[ja573]

Status

APPROVED FOR DESIGN/IMPLEMENTATION SPECIFICATION - CTO DECISION RECORDED

Programme

Thoth core data integrity

Repository

thoth-pub/thoth

Base branch / PR target

Classification: HIGH-RISK HOTFIX

• Base branch: master
• PR target: master
• Reason: develop contains unrelated, unreleased development which must not be released as a side effect of this hotfix; the change must therefore be cut from, and merged to, origin/master.
• Post-release reconciliation: after the hotfix lands on master and production is verified, merge master forward into develop (a separate, controlled step).
• Explicit prohibition: do not merge develop into master as part of THOTH-CHAPTER-01: Enforce a single parent for chapter works #803, and do not import unreleased develop implementation into the hotfix.

Supersedes the original instruction (develop -> develop), updated per the CTO HIGH-RISK HOTFIX decision. The approved domain decision, scope, invariants, existing-data audit requirements, acceptance criteria, rollout gate, rollback requirements and risk classification are unchanged.

Risk

HIGH - database/domain integrity rule affecting write acceptance and potentially existing data.

Dependencies

• CTO/domain decision: a chapter Work must have at most one parent Work.
• Existing-data audit must complete before any enforcing migration or production activation.

Decision

Although reuse of an unchanged chapter across editions is theoretically possible, current product practice does not rely on it. Thoth will therefore enforce that a chapter Work has at most one parent relation.

This rule is an integrity guard, not a way for the API to infer user intent. If the first relation submitted for a newly created chapter points at the wrong book, the API cannot independently know which book the user intended. The thoth-app regression task remains necessary.

Explicit scope

1. Determine the narrowest authoritative enforcement point for 'chapter has at most one parent'. Prefer database/domain enforcement over UI-only checks.
2. Audit existing production-compatible data for chapter Works with more than one parent before adding enforcement.
3. Define the exact relation/work-type semantics being constrained: BOOK_CHAPTER child relation(s) representing parent book membership.
4. Add tests proving a second parent assignment for the same chapter is rejected.
5. Preserve normal creation of a chapter under its first parent.
6. Ensure the error returned through the API is deterministic and safe for clients.
7. Add migration(s) only if required for authoritative enforcement.
8. Record rollout, rollback, and existing-data evidence in the implementation report.

Non-goals

• Do not add a transactional 'create chapter under book' endpoint in this task.
• Do not change chapter deletion semantics.
• Do not attempt to determine whether the first supplied parent is the user's intended book.
• Do not modify bulk import behavior except where necessary to comply with the same invariant.
• Do not broaden this into general WorkRelation semantic validation.

Invariants

• A chapter Work may have zero or one parent while intermediate/orphan records remain technically possible under the current two-step creation flow.
• A chapter Work may never persist two distinct parent-book relationships after enforcement is active.
• Existing valid chapter relationships must remain unchanged.
• No migration may silently choose a surviving parent for already-corrupt multi-parent data; any such rows must be reported and explicitly resolved before enforcement.
• Authorization behavior must not be weakened.

Existing-data audit gate

Before migration/activation, produce evidence identifying:

• count of chapter Works with 0 parents;
• count with exactly 1 parent;
• count with >1 parents;
• identifiers/details for every >1-parent case sufficient for CTO/data-owner resolution.

If >1-parent records exist, return BLOCKED for activation until they are explicitly resolved. Do not auto-delete or auto-reparent them.

Acceptance criteria

• A first valid parent relation for a chapter succeeds.
• A second distinct parent relation for the same chapter is rejected at the authoritative write boundary even if both Works are authorized for the caller.
• Repeated/idempotent behavior, if supported by current relation semantics, is explicitly tested and documented.
• Non-chapter WorkRelation types are unaffected unless the implementation necessarily shares a generic constraint; any broader effect requires separate approval.
• Existing-data audit evidence is attached to the PR/implementation report.
• Populated and empty database migration tests pass if a migration is introduced.
• API/client-facing failure behavior is covered by tests.
• Changelog updated under Unreleased.

Required verification

• make check-all or the exact equivalent repository checks.
• Migration verification against both empty and representative populated databases if schema changes are made.
• Targeted WorkRelation/domain tests for first-parent success and second-parent rejection.
• Authorization regression tests around the affected mutation path.
• git diff --check.
• Independent final-diff review at the exact PR head.

Rollout

Initially inactive until:

1. existing-data audit is complete;
2. any corrupt multi-parent data is explicitly resolved;
3. CI and migration evidence are green;
4. independent review returns APPROVED;
5. CTO explicitly approves merge/production activation.

Rollback

Must be specified by implementation according to the chosen enforcement mechanism. A migration-based constraint must have a tested rollback path that does not delete or rewrite chapter data.

Relationship to incident

This guard reduces the space of possible chapter-parent corruption and prevents one chapter from becoming attached to multiple books. It does not explain or prevent a wrong first parent UUID; that is covered by the separate thoth-app investigation/regression task.

[ja573]

THOTH-CHAPTER-01 / #803 — Phase A evidence (audit + design)

Classification: HIGH-RISK HOTFIX · Phase A only — no enforcement activated, no migration, no production write behaviour changed, no production data or credentials accessed.

• Draft PR: THOTH-CHAPTER-01 (#803): enforce single parent for BookChapter works [HIGH-RISK HOTFIX] #806 (base: master)
• Hotfix branch: hotfix/803-chapter-single-parent-audit, cut from origin/master
• Starting origin/master: aa36ecfcf30df1153741c9590cbe3d23a1b5b6c0
• HEAD: 137f36aba2801586321ca0c5eba77993c71f0172
• Observed origin/develop: 1c752a522f7048963efde00b50565379d7c14b4d (235 commits ahead of master; none included here)

Semantic findings (from master). A chapter's parent-book membership is a work_relation row with relation_type = 'is-child-of' (relator = chapter, related = parent), stored bidirectionally with its has-child inverse via WorkRelation::create. work.work_type = 'book-chapter' identifies a chapter Work but is mutable and lives in a separate table. work_relation_relator_related_uniq already rejects exact-duplicate parents (so ">1 rows" ⇒ ">1 distinct parents" for is-child-of); no existing constraint limits distinct parents — two distinct parents are currently allowed. The only write path is create_work_relation, which performs no single-parent check. Authorization (WorkRelationPolicy) requires membership of all publishers spanned; enforcement must stay independent of it.

Audit mechanism. Read-only SQL (validated in work_relation/tests.rs); predicate = works that are is-child-of >1 DISTINCT related_work_id. Full copy/paste operator procedure (read-only transaction) is in the PR description.

Local/test evidence (cargo test -p thoth-api --features backend model::work_relation::tests::audit): 4 passed — classification 0→2 / 1→1 / >1→2 on controlled data; blocking query flags exactly the three >1 works and none of the single/zero/unrelated-type/is-part-of/opposite-orientation works; duplicate parent rejected; candidate index builds over valid data and rejects a 2nd distinct parent; index build fails over corrupt data (no silent activation).

Production audit evidence: NOT YET AVAILABLE (expected Phase A gate). Production activation: BLOCKED.

Recommended enforcement (Phase B). Partial unique index CREATE UNIQUE INDEX work_relation_single_is_child_of_parent_uniq ON work_relation (relator_work_id) WHERE relation_type = 'is-child-of'; — table-local (no dependency on the mutable work_type), concurrency-safe (atomic unique index defeats the check-then-insert race), narrow (only is-child-of; has-child/is-part-of/others untouched). Deterministic client error via one new DATABASE_CONSTRAINT_ERRORS entry — no new error framework. Corrupt data ⇒ index build fails ⇒ no silent reparenting. Rollback = DROP INDEX (no data touched).

Concurrency conclusion. The existing pg_advisory_xact_lock in create() is orientation-dependent and only serialises ordinal assignment; it is not a sufficient single-parent guarantee. The DB unique index is the authoritative, concurrency-safe mechanism.

Confirmation: production write behaviour remains unchanged in this PR.

Open gates: production audit + evidence · resolve any >1-parent chapters · Phase B implementation · Phase B concurrency evidence · migration validation · independent review APPROVED · CTO high-risk approval · production verification · master → develop forward integration.

[ja573]

THOTH-CHAPTER-01 / #803 — Phase A evidence (revised after independent review)

This supersedes the earlier Phase A evidence comment above. That earlier comment scoped the audit and enforcement to any is-child-of relator and proposed a global partial unique index. Independent review correctly found this broader than the approved #803 invariant (chapter Works only; "do not broaden into general WorkRelation validation"). Corrected below. Still HIGH-RISK HOTFIX, Phase A only — no enforcement activated, no migration, no production write behaviour changed, no production data/secrets accessed.

• Draft PR: THOTH-CHAPTER-01 (#803): enforce single parent for BookChapter works [HIGH-RISK HOTFIX] #806 (base master) · HEAD: e09c9dc9db5e58a6c9022f1a999b26c52b43e255
• Starting origin/master: aa36ecfcf30df1153741c9590cbe3d23a1b5b6c0 · Observed origin/develop: bcb6ce3081abb14467798b372fcc3e6af9da1c6a (none included)

Independent-review finding addressed — domain scope. The authoritative audit and enforcement are now scoped to chapter Works (work_type = 'book-chapter') with is-child-of parent relations, matching the approved invariant.

Corrected BookChapter audit (read-only SQL, validated in work_relation/tests.rs): (A) blocking = book-chapter Works with >1 DISTINCT is-child-of parent; (B) per-parent detail; (C) 0/1/>1 distribution. Local/test evidence: summary 0→2 / 1→1 / >1→2; blocking flags exactly the two multi-parent book-chapters; a Monograph with two is-child-of parents is not blocked.

Separate non-BookChapter diagnostic (D): SEMANTIC CONSISTENCY DIAGNOSTIC — NOT #803 BLOCKING EVIDENCE. Lists non-BookChapter Works carrying is-child-of relations (>1 first). Informational; does not block activation unless a later CTO decision broadens the invariant. Test confirms the Monograph surfaces here (count 2, type monograph), not in the blocking set.

Revised enforcement design (Phase B). A partial unique index cannot express the invariant (it depends on the mutable work.work_type in another table). Recommended Option A: a BookChapter-scoped trigger that serialises on the chapter's work row (FOR NO KEY UPDATE) and rejects a second distinct parent, plus a BEFORE UPDATE ON work trigger guarding the work_type→book-chapter transition. RAISE … USING CONSTRAINT + one DATABASE_CONSTRAINT_ERRORS entry gives a deterministic client error (test-verified constraint name). Covers all six state transitions (insert 1st/2nd parent, relation UPDATE relator/related/type, work_type transition). Option B (broad "any is-child-of = chapter" rule / global index) is broader than #803 and NOT adopted; it would require an explicit CTO decision to broaden the invariant.

Concurrency conclusion. The existing pg_advisory_xact_lock is orientation-dependent and ordinal-only — not a single-parent guarantee. The trigger's FOR NO KEY UPDATE row lock is the authoritative serialisation point (a bare SELECT-count would lose the race under MVCC). A genuine two-connection concurrency test is a Phase B deliverable.

Design-validation tests (ephemeral, rolled-back, ships nothing): the trigger rejects a 2nd distinct book-chapter parent with the mapped constraint name; a Monograph may hold two is-child-of parents (scope); is-part-of/has-child unaffected; flipping a 2-parent Work to book-chapter is rejected; a 1-parent Work may transition.

Migration corrupt-data safety: because a trigger only guards new writes, the Phase B migration must run a pre-flight guard that aborts if any book-chapter currently has >1 parent (no silent activation over corrupt data). Rollback = DROP TRIGGER/FUNCTION (no data touched).

Operational claims corrected: the earlier "fast" characterisation is withdrawn. Expected overhead is low based on the PostgreSQL mechanism; trigger creation takes a brief ACCESS EXCLUSIVE metadata lock; production duration/lock-wait remain UNVERIFIED and are a release gate.

CI/changelog: check-changelog failed for lack of a CHANGELOG.md entry. As Phase A is test/design-only (no user-visible change), the repository's no changelog label has been applied to PR #806 rather than adding a misleading entry. Phase B must add a CHANGELOG.md entry under Unreleased.

Production audit evidence: NOT YET AVAILABLE. Production activation: BLOCKED. Production write behaviour remains unchanged.

Verification (new HEAD): git diff --check clean · cargo fmt --check clean · cargo clippy -p thoth-api -D warnings clean · targeted audit tests 4 passed · make check-all passed (rc=0) · GitHub Actions all 7 checks green at HEAD e09c9dc (build, test, lint, format_check, run_migrations, check-changelog, staging docker).

Open gates: production audit + evidence · resolve any >1-parent book-chapters · Phase B implementation · Phase B concurrency evidence · migration guard validation · independent review APPROVED · CTO high-risk approval · production verification · master → develop forward integration.

[ja573]

THOTH-CHAPTER-01 / #803 — Phase A evidence (revised after 2nd independent review)

This supersedes the earlier Phase A evidence comments (which are retained above; not edited). Still HIGH-RISK HOTFIX, Phase A only — no enforcement activated, no migration, no production write behaviour changed, no production data/secrets accessed.

• Draft PR: THOTH-CHAPTER-01 (#803): enforce single parent for BookChapter works [HIGH-RISK HOTFIX] #806 (base master) · HEAD: 7a664e296b854307151b6c9105b4bea50c537b14
• Starting origin/master: aa36ecfcf30df1153741c9590cbe3d23a1b5b6c0 · Observed origin/develop: bcb6ce3081abb14467798b372fcc3e6af9da1c6a (none included)

Two concurrency/design defects in the previous (R2) trigger design were found and fixed:

1. Pre-lock work_type read race. The R2 trigger read work_type before acquiring the serialization lock, so a Monograph path skipped locking and could race a concurrent Monograph→BookChapter transition → a BookChapter with two parents. Fix: both the relation trigger and the work_type-transition trigger now acquire the SAME per-Work lock — FOR NO KEY UPDATE on the chapter's work row — before reading work_type/counting. A non-BookChapter is-child-of mutation therefore also briefly takes the lock (operational synchronization, not a semantic expansion).

2. Migration guard→install TOCTOU. The R2 migration ran the clean-data guard, then created triggers, leaving a window for a violating writer. Fix: the migration now does BEGIN; LOCK TABLE work, work_relation IN SHARE ROW EXCLUSIVE MODE; <guard>; CREATE FUNCTIONs/TRIGGERs; COMMIT; — validation and installation are one write-excluded atomic transition (SHARE ROW EXCLUSIVE conflicts with the ROW EXCLUSIVE lock all DML takes).

Operational correction: CREATE TRIGGER takes SHARE ROW EXCLUSIVE (PostgreSQL 17), not ACCESS EXCLUSIVE; it conflicts with ROW EXCLUSIVE DML (blocks concurrent writes while held) but not ACCESS SHARE reads. The "brief"/"fast" production characterisation is withdrawn — production lock-wait/duration remain UNVERIFIED and are a release gate.

Concurrency evidence (test-backed, work_relation/tests.rs). Two deterministic two-connection tests, both lock orderings, coordinated by channels + a bounded pg_stat_activity wait-for-lock gate (no correctness sleeps): each asserts the loser actually blocked on the lock, exactly one side commits, and the final persisted state is never book-chapter with >1 parent (transition-first → book-chapter/1 parent; relation-first → monograph/2 parents). Plus a production-path test: WorkRelation::create rejects a second distinct parent and the paired inverse row is rolled back. cargo test … model::work_relation::tests::audit = 8 passed.

Audit (accepted, unchanged): (A) BookChapter blocking, (B) detail, (C) 0/1/>1 distribution, (D) non-BookChapter is-child-of diagnostic (informational). Local/test: summary 0→2 / 1→1 / >1→2; a Monograph with two is-child-of parents is not blocked, only diagnosed.

Production audit evidence: NOT YET AVAILABLE. Production activation: BLOCKED. Production write behaviour remains unchanged.

Verification (new HEAD): git diff --check clean · cargo fmt --check clean · cargo clippy -p thoth-api -D warnings clean · audit module 8 passed · make check-all passed (rc=0) · GitHub Actions all 7 checks green at HEAD 7a664e2 (build, test, lint, format_check, run_migrations, check-changelog, staging docker); the two-connection concurrency tests passed in CI's postgres:17 test job.

Open gates: production audit + evidence · resolve any >1-parent book-chapters · Phase B implementation · Phase B concurrency evidence (relation-vs-relation and relation-vs-transition) · migration activation-race + empty/valid/invalid validation · independent review APPROVED · CTO high-risk approval · production verification · master → develop forward integration.

[ja573]

THOTH-CHAPTER-01 / #803 — Production existing-data audit evidence

Production audit completed on 2026-08-12 by an authorized operator using the approved read-only audit procedure inside a transaction with SET TRANSACTION READ ONLY, followed by ROLLBACK.

Authoritative BookChapter results

• BookChapter Works with 0 qualifying parents: 278
• BookChapter Works with exactly 1 qualifying parent: 19,235
• BookChapter Works with >1 distinct qualifying parents: 0
• Blocking query (book-chapter + is-child-of + COUNT(DISTINCT related_work_id) > 1): 0 rows
• Blocking-detail query: 0 rows

Result: the #803 existing-data corruption gate is CLEAR. There are no existing multi-parent BookChapter records requiring CTO/data-owner resolution before implementation/enforcement.

The 278 zero-parent BookChapter Works are permitted by the approved invariant: a chapter may have zero or one parent while orphan/intermediate records remain technically possible under the current two-step creation flow.

Non-BookChapter is-child-of diagnostic — informational only, not #803 blocking evidence

• 41c011c4-b12e-4f51-8f48-8ffba4f32697 — edited-book — 1 distinct parent
• 8610efab-7a5b-4078-9770-ab39d79329d2 — edited-book — 1 distinct parent

These diagnostic rows do not violate the approved BookChapter-specific invariant and do not block the hotfix.

Gate status after audit

• Existing-data audit: PASSED
• Corrupt multi-parent BookChapter resolution: NOT REQUIRED
• Phase B implementation: PENDING
• Phase B migration/concurrency/authorization evidence: PENDING
• Independent exact-head review: PENDING
• CTO high-risk merge/production activation approval: PENDING

This evidence clears the existing-data prerequisite only. It does not authorize merge, deployment, or production activation.

[ja573]

CTO process decision — Phase B will continue in PR #806

The production audit gate has passed and Phase A has been independently reviewed at exact head 7a664e296b854307151b6c9105b4bea50c537b14.

Decision: continue Phase B implementation on the existing hotfix/803-chapter-single-parent-audit branch and draft PR #806 instead of merging Phase A separately and opening a new PR. This is treated as one bounded #803 hotfix task.

The previous Phase A-only PR wording is superseded for process purposes; the Phase A revision/evidence history must remain preserved in the final PR description/evidence.

Final release controls are unchanged: target master; no develop -> master; complete Phase B migration/concurrency/auth/API/changelog evidence; new independent exact-head review of the complete Phase A+Phase B diff; explicit CTO approval before merge/activation; production verification; then master -> develop forward integration.

[ja573]

THOTH-CHAPTER-01 / #803 — Phase B implementation evidence

Phase B (production enforcement) implemented on the existing branch / PR #806 per the recorded CTO same-PR decision. Historical Phase A (R1/R2/R3) and production-audit evidence above are unchanged.

• PR: THOTH-CHAPTER-01 (#803): enforce single parent for BookChapter works [HIGH-RISK HOTFIX] #806 (base master, draft) · HEAD: 31eeeeba97bcfe41f3227995ecd45032e31a6ace
• Starting origin/master: aa36ecfcf30df1153741c9590cbe3d23a1b5b6c0
• Production existing-data audit gate: PASSED — 278 zero-parent / 19,235 one-parent / 0 multi-parent BookChapter; corrupt-row resolution NOT REQUIRED.

Migration thoth-api/migrations/20260813_v1.6.3/{up,down}.sql. Diesel runs each migration in one transaction, so up.sql acquires LOCK TABLE work, work_relation IN SHARE ROW EXCLUSIVE MODE, runs the corrupt-data guard (RAISE if any book-chapter has >1 distinct is-child-of parent), then creates two functions + two triggers — all in that single transaction (no guard→install TOCTOU). down.sql drops the triggers/functions only (no data touched).

Error mapping: one DATABASE_CONSTRAINT_ERRORS entry → deterministic client message "A book chapter may belong to only one parent work." (thoth-errors).

Serialization: both triggers take the SAME FOR NO KEY UPDATE lock on the relator/target work row before reading the mutable work_type (closes the R2 race).

Concurrency results (two independent connections, both orderings; loser asserted to block on the lock; final state verified): parent-vs-parent → exactly one commits (chapter ends with 1 parent); relation-first-vs-transition → Monograph/2 parents (transition rejected); transition-first-vs-relation → BookChapter/1 parent (second parent rejected). BookChapter/2-parents unreachable.

Production WorkRelation::create path: both orientations (Parent→HasChild→Chapter and Chapter→IsChildOf→Parent) reject a second distinct parent and roll back the paired inverse (no orphan has-child).

Relation-update semantics: replace-only-parent A→B allowed; second-parent-by-related/relator/relation_type change rejected; change away from is-child-of allowed; exact duplicate still rejected by the existing constraint.

Work_type transition: →book-chapter rejected when >1 parent, allowed when ≤1.

Non-BookChapter: Monograph/EditedBook multi-is-child-of, has-child, is-part-of all unaffected.

API / client error: GraphQL createWorkRelation test — a second distinct parent returns the safe message via juniper::execute_sync.

Authorization: authorized (superuser) caller: first parent OK, second rejected by integrity; unauthorized (anonymous): rejected by authorization (different message), no capability gained.

Migration tests (throwaway DBs): empty→OK · valid populated→OK (data unchanged) · invalid (2-parent chapter)→aborts, no partial triggers, no data change · down→removes enforcement, data intact · up→down→up→OK · activation-race→concurrent violating writer blocks on the table lock through the guard→install window and is rejected after commit (no invalid row persists).

Changelog: Unreleased entry added; no changelog label removed.

Rollback: down.sql removes triggers/functions only; no data deleted/reparented/rewritten.

Release-time re-audit: an authorized operator must re-run the approved read-only BookChapter audit immediately before activation; the migration guard remains authoritative regardless.

Operational: SHARE ROW EXCLUSIVE on work/work_relation during the migration (DML waits; ACCESS SHARE reads not blocked); is-child-of writes take a FOR NO KEY UPDATE row lock on the relator. PRODUCTION LOCK-WAIT / DURATION: UNVERIFIED.

Develop compatibility: 20260813_v1.6.3 sorts after develop's newest (20260812_v1.7.0); no collision, no overlapping single-parent implementation; nothing imported.

Verification: git diff --check clean · cargo fmt --check clean · cargo clippy -p thoth-api -D warnings clean · targeted #803 tests (20) + GraphQL/authz test pass · make check-all passed (rc=0) · GitHub Actions all 7 checks green at HEAD 31eeeeb (real build-test-and-check run: thoth-api 866 passed / 0 failed + full workspace; build, test, lint, format_check, run_migrations, check-changelog, staging docker).

Remaining release gates: release-time production re-audit · independent exact-head review of the complete Phase A+B diff · explicit CTO high-risk merge/activation approval · production deployment + verification · master → develop forward integration. This evidence does not authorize merge, deployment, or activation.

[ja573]

CTO control decision — 2026-08-13

Explicit authorization has been given to merge and activate the THOTH-CHAPTER-01 (#803) HIGH-RISK hotfix, with production deployment to be performed separately by the CTO/operator.

Execution state:

• PR THOTH-CHAPTER-01 (#803): enforce single parent for BookChapter works [HIGH-RISK HOTFIX] #806 independently APPROVED at exact head 31eeeeba97bcfe41f3227995ecd45032e31a6ace.
• PR THOTH-CHAPTER-01 (#803): enforce single parent for BookChapter works [HIGH-RISK HOTFIX] #806 merged to master as d6c7effbaf63fa4a591a3859e61cb7714984f27f.
• Post-merge master Actions observed terminal success for the push workflows checked.
• Production has NOT been deployed or accessed by the reviewing agent.
• Release-time read-only production re-audit remains an operator action immediately before production activation; the migration's internal guard remains authoritative.
• v1.6.3 must point to merge commit d6c7effbaf63fa4a591a3859e61cb7714984f27f.
• Forward integration must remain master -> develop only. PR Forward-integrate v1.6.3 hotfix from master into develop #810 records that forward integration but currently has a real conflict in CHANGELOG.md and thoth-api/src/graphql/tests.rs; no develop -> master merge is permitted.

[ja573]

CTO release-sequence override — 2026-08-13

The CTO has explicitly authorized the following sequence for this hotfix, superseding the earlier timing that placed forward integration after production verification:

1. Merge approved THOTH-CHAPTER-01: Enforce a single parent for chapter works #803 hotfix to master — COMPLETE at d6c7effbaf63fa4a591a3859e61cb7714984f27f.
2. Create/push annotated release tag v1.6.3 at that exact master merge commit.
3. Forward-integrate master into develop only (never develop -> master).
4. CTO/operator makes the v1.6.3 release and deploys production.

The release-time read-only production audit remains required immediately before production activation, and the migration's internal corrupt-data guard remains authoritative.

Forward integration currently requires conflict resolution because develop has independent additions in CHANGELOG.md and thoth-api/src/graphql/tests.rs. The direct PR #810 was closed to prevent GitHub conflict resolution from writing develop-only content onto its master head. Safe integration branch: hotfix/803-forward-integrate-v1.6.3, based on develop 3b6b3a31f9358011f0c998015dfd0c2508380e83.