From 142c3b59daf87da673de6ae608ecb24888b7c2a4 Mon Sep 17 00:00:00 2001 From: Ryan Barlow <7389646+ryanbarlow97@users.noreply.github.com> Date: Wed, 14 Oct 2026 06:10:51 +0000 Subject: [PATCH 1/2] docs(recycler): gate delivered legacy recovery by journal phase --- projects/Recycler/docs/OWNERSHIP.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/projects/Recycler/docs/OWNERSHIP.md b/projects/Recycler/docs/OWNERSHIP.md index 062408e..c43abea 100644 --- a/projects/Recycler/docs/OWNERSHIP.md +++ b/projects/Recycler/docs/OWNERSHIP.md @@ -147,12 +147,18 @@ refunds, deliveries and restart recovery are held, and the tool refuses migration rollback. Estate settlement and other legacy migrations can continue; follow the operation ID through estate receipts to its current character copy. After confirming that no older JAR delivered it, restore its exact bytes from -`ownership/backups/.bin`. If an older JAR did deliver it, stop Paper, -archive the current copy and its receipts, record that delivery and set any -undelivered character copy to `cancelled` with a reason before restoring the -legacy bytes. Reconcile already delivered copies manually. The restored legacy -file is inert in this version and must stay outside the old queue on downgrade. -The backup alone cannot prove that another delivery is safe. +`ownership/backups/.bin`. If an older JAR did deliver it, stop Paper +and inspect `phase` in `ownership/migration/.json` before +restoring anything. Only for a `moved` journal, archive the current copy and its +receipts, record that delivery and set any undelivered character copy to +`cancelled` with a reason before restoring the legacy bytes. Reconcile already +delivered copies manually. For `planned` or `published`, keep the legacy file +absent, preserve the journal, any character copy and receipts, and reconcile them +manually with Paper stopped. Restoring a `planned` source can publish a fresh +pending return; cancelling a `published` copy and restoring its source leaves the +heir held. Do not reset the phase or delete history to force recovery. The +restored legacy file is inert in this version and must stay outside the old queue +on downgrade. The backup alone cannot prove that another delivery is safe. If apply fails after restoring some records, the report's `applied` paths name the completed actions alongside the original error. Preserve the backup and From c8716fbcfb9aed02fda745332bec28ef2500a1f8 Mon Sep 17 00:00:00 2001 From: Ryan Barlow <7389646+ryanbarlow97@users.noreply.github.com> Date: Wed, 14 Oct 2026 06:16:39 +0000 Subject: [PATCH 2/2] docs(cooking): require patched transaction provider for ownership migration --- projects/Cooking/docs/husbandry.md | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/projects/Cooking/docs/husbandry.md b/projects/Cooking/docs/husbandry.md index 0b83bda..f13bde5 100644 --- a/projects/Cooking/docs/husbandry.md +++ b/projects/Cooking/docs/husbandry.md @@ -145,10 +145,15 @@ reviewed heir remains the migration recipient. One SQLite transaction copies all legacy owner columns into the immutable archive, verifies its count, writes the fixed plan, inserts resolved character slots and writes completion. The archive includes committed WAL content through SQLite itself and cannot cascade away -when an animal dies. SQL failures and runtime exceptions roll back the archive, -plan and ownership publication together. Under TLibs 2.6.0, a JVM `Error` inside -the transaction can commit partial rows instead; an unfinished migration then -requires staff repair using the preserved archive and legacy rows. +when an animal dies. TLibs **2.6.1** rolls back the archive, plan and ownership +publication together on any transaction body failure, including a JVM `Error`. +An uncertain rollback discards the connection; a clean server restart reopens +husbandry storage. +Verify that TLibs 2.6.1 is loaded before running ownership migrations; Cooking's +compilation pin remains 2.6.0, with the same public API. Under TLibs **2.6.0 and +earlier**, a JVM `Error` inside the transaction can commit partial rows instead. +An unfinished migration written under those providers still requires staff repair +using the preserved archive and legacy rows; upgrading TLibs does not repair it. Missing heirs, malformed identities, unknown roles and conflicting slots remain recorded for staff; another character never claims them by opening a menu. Animal rows, snapshots, care, genes, timers and unknown columns @@ -185,8 +190,11 @@ and character references must agree with the recorded decision. Completed IDs must also agree with the preserved source archive for that death/revision; missing or changed receipt IDs cannot authorize another transfer. -SQL failures, runtime exceptions and process interruption roll back the -transaction. The TLibs 2.6.0 JVM-error boundary above also applies to estates. +TLibs **2.6.1** rolls back transaction body failures, including a JVM `Error`; +process interruption rolls back uncommitted SQLite work. An uncertain rollback +also requires a clean server restart. Under TLibs **2.6.0 and earlier**, +a JVM `Error` can leave partial estate rows; upgrading the provider does not +repair those existing rows. A retained incomplete intent or conflicting same-revision receipt is BLOCKED for review; affected ownership writers refuse changes while resolved co-owners can still care for or ride their