Reconstructed claim support for issues #35 and #36

This supplement corrects F2 in the issue #40 reconciliation. The missing historical assessments were reconstructed from the four immutable source trees identified there. Original inventories, reports and failed receipts remain historical evidence. The new assessment overlay preserves each original occurrence, its revision and text, its ordered current correspondence, and the reason to retain, replace or remove it. It does not claim to recover lost execution logs.

The assessment covers every paragraph in the 22 lessons, all fields and operations in the 31 Scenario sources, their complete generated parts, and their specific ledger records and llms sections. A source assertion constrains its own operation, session and outcome. Repeated SQL and repeated mirror text remain separate occurrences. A result field without an assertion remains an observation. Narration, setup, formatting and navigation are identified separately; they do not supply extra demonstrated outcomes.

Historical claims are assessed from their original paragraphs and typed source events. A paragraph that combines detector settings, rollback, retry, lock order and diagnostics has separate dispositions for those subjects. Wrapped physical lines retain their original paragraph context. Source notes retain their exact old text and explicit limits; transcript and timeline occurrences first resolve to the old ordered source event. Physical diff hunks remain provenance and never select the semantic replacement. Withdrawn latency, external-effect and universal scheduling claims remain visible in the assessment with their removal reasons.

The retained temporary records contain the exact quoted manual passages, source assertion ranges, paragraph assessments and historical dispositions. The quotations below make the manual-only support visible to readers. They are excerpts, not a substitute for their linked conditions. Manual support targets MySQL 8.4 or PostgreSQL 18; carried execution evidence targets MySQL 8.4.11 and PostgreSQL 18.6 at 03915a35c875779ad28f0712e685be26b76e2cce.

MySQL locking

Claim	Exact versioned support and assessment
Deadlock detection and victim	The detector contract says InnoDB "tries to pick small transactions to roll back", measured by "the number of rows inserted, updated, or deleted". Detection must be enabled and able to see the cycle. The executed balances establish B's whole-transaction rollback, not a universal victim choice.
Diagnostic history	The handling manual describes "the most recent deadlock" and, with innodb_print_all_deadlocks, "each deadlock, not just the latest one". Neither diagnostic is an assertion in the deadlock schedules.
Statement versus transaction errors	The error contract says "Locks are not released in a rollback of a single SQL statement." The timeout Scenario additionally asserts the earlier value and lock survive with rollback-on-timeout OFF, then disappear on explicit ROLLBACK. The ON configuration is a separate manual contract.
Record and gap mechanisms	The locking manual defines a record lock as "a lock on an index record" and gap locks as "purely inhibitive". Its compatibility sections distinguish S/X record requests from coexisting gap locks; next-key includes the preceding gap. The three compatibility schedules do not establish compatibility for every lock type.
Access path and isolation	For locking reads (SELECT ... FOR UPDATE or FOR SHARE), UPDATE and DELETE at REPEATABLE READ, the MySQL 8.4 isolation contract limits an existing match through a unique index with a unique search condition to "only the index record found"; other search conditions lock "the index range scanned". For those operations at READ COMMITTED, InnoDB locks "only index records, not the gaps before them"; gap locking remains only for "foreign-key constraint checking and duplicate-key checking". Returned rows do not enumerate all scanned intervals.
Locking reads and queue limits	The locking-read contract states that NOWAIT/SKIP LOCKED "only apply to row-level locks" and are "unsafe for statement based replication". These options do not remove metadata waits, provide a consistent full-table view, or establish external delivery. FOR SHARE/UPDATE locks end on commit or rollback.
Scheduling	The queue lesson quotes both the CATS weight basis and the equal-weight rule from the MySQL 8.4 scheduling manual. Its Scenario asserts the blocker and final balance 211, not grant order or eventual acquisition under arbitrary load.
Lock instruments	The data-lock table reports locks "held and requested". The sys wait view exposes waiting_pid and blocking_pid. The metadata table uses the "wait/lock/metadata/sql/mdl" instrument, "enabled by default". Access privileges and enabled instrumentation remain conditions.
Diagnostic consistency	The consistency contract warns: "Data might not be consistent" between the transaction and lock tables. Separate monitor queries are not an atomic state snapshot.
Cancellation	The KILL contract says KILL QUERY "leaves the connection itself intact". Connection termination and statement cancellation have different transaction boundaries. Cancellation is not executed in the monitoring lesson.
Foreign-key declaration	The CREATE TABLE contract says "MySQL parses but ignores" inline REFERENCES. The demonstrated parent lock and RESTRICT error use a declared table-level FOREIGN KEY.
Foreign-key check locks	For a statement that must check a declared foreign key, the statement-lock contract says it "sets shared record-level locks on the records that it looks at to check the constraint". The parent UPDATE wait and DELETE error are asserted; this physical lock mechanism is documented separately.
Metadata lifetime and priority	The MDL contract defers release "until the transaction ends" and gives write requests "higher priority than read lock requests", subject to max_write_lock_count. The outage Scenario establishes its two wait states, not universal FIFO or a chosen DDL algorithm.
DDL boundaries	The implicit-commit contract describes a commit "before executing the statement". Temporary CREATE/DROP are exceptions, but "neither can the statement be rolled back". The lesson does not generalize ALTER behavior to every DDL form.
Metadata timeout	The variable reference states: "The timeout value applies separately for each metadata lock attempt." Its default is 31536000 seconds. The Scenario checks C after B times out, not throughout B's wait.

MySQL MVCC

Claim	Exact versioned support and assessment
Undo reconstruction	The undo-log contract says "the unmodified data is retrieved from undo log records". The multi-versioning contract identifies DB_TRX_ID and DB_ROLL_PTR and describes "rebuild the content of the row before it was updated". The SELECT results demonstrate visibility, not inspection of these physical fields.
Snapshot timing	The consistent-read contract uses "the snapshot established by the first such read" at REPEATABLE READ and a "fresh snapshot" at READ COMMITTED. Own earlier writes remain visible. The START TRANSACTION contract says the modifier "does not change the current transaction isolation level". WITH CONSISTENT SNAPSHOT is effective at REPEATABLE READ.
Transaction-ID allocation	The read-only optimization can "avoid the overhead associated with setting up the transaction ID". This does not define the numeric placeholder seen in the Scenario or make read views free of undo-retention costs.
History length	The purge contract describes history as undo-log pages for committed transactions and their retention while dependent read views exist. The assertion is trx_rseg_history_len >= 200 while R sees zero; it is not a 200-byte, 200-version, exact-delta or drainage-time measurement.
Undo-file truncation	The tablespace contract requires rollback segments to be free before truncation. Purging eligible records and truncating an undo file have different conditions. Ending one reader does not assert either operation completed.

Purge

The purge lesson now quotes the eligibility condition and the thread/lag variable contracts. It has no Scenario. The exact retained parameter passages distinguish the thread maximum from the number used, undo-log pages from rows or bytes, and a lag threshold from a completion guarantee. innodb_max_purge_lag=0 disables that lag delay. The batch-size reference defines "the number of undo log pages" processed per batch; this is not evidence that any tested workload drained.

PostgreSQL patterns

Claim	Exact versioned support and assessment
Relative updates and locking reads	The READ COMMITTED contract says the search condition "is re-evaluated" on an updated target. The three repair schedules assert balance 120 under their participating writer protocols. Stronger-level updates can fail with 40001; these are not cross-row or external-effect repairs.
Uniqueness and conflict actions	The INSERT contract guarantees "an atomic INSERT or UPDATE outcome" unless an independent error occurs, and returns "Only rows that were successfully inserted or updated". The constraint contract makes nulls distinct unless NULLS NOT DISTINCT changes that rule. The two email schedules assert their specific duplicate count, 23505, zero affected rows and returned row.
Idempotency inference	The marked † inference requires a retained unique key, a stable key per operation and every writer gating its local work inside the same transaction. The transaction contract gives "all-or-nothing" local effects. Two duplicate schedules establish balances 70 and 45, not every network retry, identical request payloads or remote charging. RC DO NOTHING can lose to a row absent from its statement snapshot; a subsequent statement has a fresh snapshot.
Advisory lifecycle	The advisory contract holds a session lock "until explicitly released or the session ends" and requires a "corresponding unlock request" for each acquisition. The function contract states "these two key spaces do not overlap" and permits shared or exclusive locks. Commit behavior is executed; rollback, termination, shared mode and reentrancy are documented.
Queue selection and termination	The locking clause says "Skipping locked rows provides an inconsistent view of the data". Table locks still apply. The termination contract says "any open transaction is rolled back, not committed" on normal or abnormal termination. The example executes explicit rollback, not a killed worker; task labels execute no external work.
Idle timeout and default isolation	The client settings describe a session "idle (that is, waiting for a client query) within an open transaction". The 500ms/1500ms settings and missing session/pending order are asserted. READ COMMITTED is a configurable default, not an ORM promise.
Retry boundary	The retry contract requires "retry the complete transaction" and says "Transaction retry does not guarantee that the retried transaction will complete". The helper source retries only 40001, defaults to five attempts and delegates rollback to its callback. Only one forced failure followed by success is executed.

PostgreSQL distributed

Claim	Exact versioned support and assessment
Outbox and compensation	The local all-or-nothing contract above supports order/event pairing. The separate broker table is a Receiver model. Omitted publication, CHECK failure, explicit relay rollback and a new compensating increment are the executed boundaries. The marked duplicate-window inference additionally assumes an external effect succeeded before removal committed; continued delivery needs retention, retry and receiver availability. Repeating the shown seats + 1 changes state again, so compensation identity remains application work.
Notification delivery	The NOTIFY contract defers delivery "until and unless the transaction is committed" and folds identical channel/payload notifications in one transaction. The source assertions cover bounded silence windows, channel, payload and sender, not permanent silence or measured relay latency.
Listener startup and lifetime	The LISTEN contract states "LISTEN takes effect at transaction commit" and "cannot be prepared for two-phase commit". It prescribes committing registration before inspecting state in a new transaction. Only registered listeners receive events. The source's SELECT polling is a psql implementation choice, not a requirement for all clients.
Prepared durability and hazards	The PREPARE contract stores state "on disk" and warns that it can "interfere with the ability of VACUUM to reclaim storage". It also prohibits preparation after LISTEN/NOTIFY and assigns recovery to an external manager. The example kills one backend, not the server, and measures four then one occupied tuple slots on one ledger page.
Enablement	The configuration contract says "Setting this parameter to zero (which is the default) disables the prepared-transaction feature." The carried execution uses 10 and superuser sessions.
Prepared resolution	COMMIT PREPARED requires "the same user" or "a superuser" and says "This command cannot be executed inside a transaction block." ROLLBACK PREPARED has the same restrictions. Only commit resolution in the same database is exercised; no global coordinator or automatic expiry is tested.

Assessment and execution boundaries

The replacement occurrence assessments supply the missing semantic work; inventory totals and mirror hashes alone do not establish it. Unchanged Scenario source, harness, dependencies, database configuration and generated bytes retain the prior execution, Python YAML parity and two-generation drift evidence at their original checked commit. The correction adds no database execution claim. Affected documentation checks and built-reader QA, followed by an independent review of the fix commits, are recorded separately in the correction handoff. No previous failed report or receipt is superseded by deletion.