Logged Sourdough Bake #11 (08/23-08/24/26) as a new items-table entry (id 45): full mix/salt/massage/shape/cold-retard/bake timeline captured, then updated with the result when USR369 reported it -- came out very good, bottom clean. ROOT CAUSE / FIX CONFIRMED: bottom-burn (an open problem since Bake #1/#2, 5500ft elevation) was fixed this bake by TWO dry cookie sheets stacked on the rack below the Dutch oven for the full bake -- prior attempts (single water-filled sheet, pot swap) only partially worked or attributed success to a different variable. Appended this finding to item #9 (the standing bottom-burn note) so the full history lives in one place, and added it to knowledge-80.md as a new BOTTOM-BURN MITIGATION section (also corrected a stale 07/14/26 'last updated' header that hadn't tracked real 08/08/26 content already in the file). SEPARATELY: while trying to fulfil SOP-KITCHEN-LOG.md's spreadsheet dual-write requirement, hit 3 real access/data problems -- (1) items ids 41 (Bake #10) and others unreachable via get_items under any status filter tried, (2) file-reader.php returns HTTP 200 empty-body instead of an error for the Kitchen backup spreadsheet path (masks the documented backups/ web-lock), (3) dba_api.php rejected the standard token as a fallback read path. Reported all 3 to Server[40] via targeted inbox drop (msg 1147, delivery confirmed via get_message read-back) rather than working around any of them (NO-SELF-FORCING). Logged K427 to memory pipeline tying the bottom-burn finding and the access-gap finding together.