USR369 gave Health a gas station fill-up + odometer reading and (earlier this week) a restaurant receipt. Both are Daily[50]/Finance[60] jurisdiction respectively, not Health's -- forwarded via inbox rather than adding to Health's own item tracker, consistent with SOP-FINANCE-LEDGER.md's cross-system intake rule (never write directly into another system's data, send the raw material instead).

Health had reported inbox-api.php personal-queue resolve as not persisting (K440/K454), and had USR369 authorize forcing past the actionability gate to work around it. Server[40] investigated (D992) and found Health was calling the wrong endpoint pattern -- not a platform bug. Logged correction as K455, explicitly flagging the lesson: verify with the owning system before concluding platform bug and before asking USR369 to force through a gate.

USR369 screenshot showed Level='5+7' and Dist=blank in the new 3-section Cardio structure. Cross-checked backend before reporting: confirmed the old free-text distance field ('5+7', actually level data) was landing in the Level display slot, while the new dedicated distanceValue field was empty. Sent directly to CC[100] with exact field values and version (gym-logger.html v6.33, confirmed same-day fresh via last-modified header) since they were actively building this feature.

USR369 direction 09/07/26: when he says he's starting a new log/list of problems or things to add, the numbering he sees should start fresh from 1/2/3, not continue counting every item ever logged. Prior items should be treated as history -- still fully preserved in the system DB (decisions/items tables, handoff, LEGACY) for real record-keeping, just no longer counted or re-surfaced in a fresh list's numbering. This is a presentation/reporting convention, not a request to delete or renumber the underlying database rows. USR369 also asked this be noted for ALL systems, not just Health -- broadcasting to the platform.

USR369 gave Health a gas station fill-up (Arco, $64.53, 11.60gal) and later an odometer reading (77120), mid-gym-session. Recognized this is vehicle/fuel tracking, Daily[50]'s jurisdiction, not Health's -- forwarded both to Daily's inbox rather than logging as a Health item, and flagged the existing open odometer-gap question while doing so.

USR369 screenshot showed Level='5+7' and Dist=blank in the HTML app's new Cardio Warmup section. Cross-checked the live backend record rather than trusting the screenshot alone: confirmed duration=5, distance='5+7' (old free-text level data), distanceValue='' (the new numeric field, empty), distanceUnit='mi'. This proved it's a field-mapping bug in the in-progress rebuild (old distance key feeding the Level display), not a fresh unscoped feature request -- sent directly to CC[100] with the exact field values since they're the active builder.

USR369 asked Health to confirm it was working against the most current HTML build. Grepped the live file directly for the APP_VERSION constant rather than trusting any cached memory of the version number, and checked the HTTP last-modified header to confirm same-day freshness.

USR369 introduced 'Janus' as a session command (pickup + read all comms + run Janus). Discovered via SOP-INDEX.md search (TASKGATE itself missed the match) that SOP-JANUS-PEEK.md already existed, defining a two-face position-record protocol distinct from a full close. Followed it: logged a memory-pipeline finding (K440), ran CHECKPOINT and SYNC, appended to ARTIFACTS-70.md and LEGACY-70.md, rewrote handoff-70.md (new position on top, full prior history preserved below per shrink-guard), and dropped a position report -- which accidentally broadcast to all 11 systems instead of just Health's own inbox, an honest miss flagged to USR369 at the time.

USR369 asked for a single file listing all open Gym Logger items, split into Android-only, HTML-only, and both-apps-major-change sections, so he could hand it to CC[100] himself. Pulled exact item text live from 70-sys.db's items table rather than from memory, organized into the three requested sections, plus an appendix for older items that predate the Android/HTML naming convention (flagged as needing surface confirmation before anyone acts on them).

USR369 reported several instances of data appearing missing or lost in the Android app (stretching after quit/reopen, stretching again after Load-into-Current, full workout detail, and Info/Swimming/Recovery sections in History). In every case, direct comparison against the live gym.db backend showed the data was fully intact and correct -- these are UI/display or Load-into-Current transfer bugs, not real data loss. Filed each as a bug with the backend-verified state included, so whoever fixes it knows to look at rendering/transfer logic, not data persistence.

USR369 direction: going forward, saying 'app' always means the Android app and 'HTML' always means the HTML page (gym-logger.html) -- keep two separate bug lists, never conflate them. This directly closes the K437 gap where a bug batch was mis-scoped as HTML when it was actually Android, sent to CC[100] under the wrong label last session.

USR369 deleted the 08/24/26 workout in-app; the id was correctly tombstoned but its raw storage slot got overwritten with a duplicate of the separate 08/22/26 session's content instead of cleanly clearing. Recovered the true 08/24 content from a pre-deletion fetch captured earlier the same session and wrote it back as a new record (fresh id) rather than reuse the corrupted/tombstoned slot. Root cause not fully diagnosed, likely same family as K360 (id-reuse/draft-collision), not chased further per USR369's specific ask (restore only).

USR369 provided a screenshot 09/01/26, Android app, mid-workout, Biceps Curl exercise. Confirms and clarifies bug #26: the 'Exercise' field shows 'Custom exercis...' and tapping it opens a large white full-screen overlay list (Biceps Curl, FW Bicept curls, FW Tricept press, Leg Extension, Pec Fly, Pulldowns, Seated Leg Curl, Shoulder Press, Triceps Pushdown) covering most of the screen, including the Delete Exercise button and Notes field underneath. USR369: this menu is not needed/wanted. Confirmed HTML does NOT do this (matches item #25's Pec Fly 'Other' pattern being the desired, non-intrusive behavior). This is now visually documented, not just described secondhand.

USR369 direction 08/29/26: he will be going back and forth testing both Gym Logger surfaces this session. Going forward, when he says 'app' he means the Android app; when he says 'HTML' he means the HTML page (gym-logger.html). Keep two separate bug/issue lists, one per surface -- do not conflate them. This directly follows K437 (bugs reported were verified against HTML source and cited as confirmed, but USR369 later clarified they were actually Android -- unclear if same codebase). This is the fix: ask/confirm surface up front via his own terminology instead of assuming.

USR369 deleted the 08/24/26 workout (DLM-082426-025, id 1787532373855) from the Gym Logger HTML app. On inspection, the id was correctly added to the __tombstone_DLM__ deleted_ids list, but the SAME id's raw storage slot had also been overwritten with content matching the separate legitimate 08/22/26 session (id 1787417417563, code DLM-082226-024) -- a duplicate-content overwrite, not a clean delete. Root cause not fully diagnosed (likely an id-reuse/draft-collision pattern in the same family as K360), left as a finding, not chased further per USR369's specific ask (restore only). Recovered the full original 08/24 record (4 exercises, cardio warmup/main/cooldown, sauna 11:51-12:18, swimming 12:19-13:05 5-stroke breakdown, stretching 10:30-10:55) from a pre-deletion fetch captured earlier this same session (before the app-side deletion happened), and wrote it back as a NEW session record (fresh id 1788023671627, same code label DLM-082426-025 for continuity) rather than reusing the tombstoned/corrupted id 1787532373855, since that id will be filtered out on next Sync regardless of its content. Left the corrupted/tombstoned slot (1787532373855, now holding duplicate 08/22 content) untouched -- it is already correctly marked for deletion and removing it further was outside scope of what was asked.

USR369 asked for any housekeeping/maintenance due. CHECKPOINT was BLOCKED (handoff 24.6h stale, blocking) plus 2 non-blocking warns (LEGACY 213.8h stale, no memory-pipeline entry today). Fixed all 3: prepended fresh handoff-70.md entry summarizing this session's full old-zip backfill + SOPs + housekeeping, prepended fresh LEGACY-70.md session entry (append-only, most-recent-at-top format respected), logged memory-pipeline finding K424 (TASKGATE false-positive pattern). Also ran get_items and inbox pickup -- surfaced 7 open backlog items (2 high-priority: dental implant decision id10, medical clearance id3 -- now connectable via this session's thumb-CMC backfill; 1 needs USR369 confirmation: Medi-Cal/Covered CA status id12; 1 data-quality blank row id6 flagged not fixed). No reply yet from CC on the v6.00 followup.

TASKGATE false-positived to SOP-HEALTH-LOG.md (gym profile/dual-write, unrelated topic -- flagged as false positive rather than followed). Wrote a real SOP documenting: where the source zip lives, the 15 existing domain entries by category/id, what's deliberately NOT backfilled and why (AI diary, 90-entry backup log, blank questionnaire, empty archive index), and a repeatable 8-step process for backfilling future old-zip finds. Added to SOP-INDEX.md.

Continued the zip mining USR369 requested: reviewed 03B_USER_PROFILE (personal/location/household/comms prefs), GYM_LOG_Health_v1.0.md (pre-current-logger session PRs 06/13-07/05/26), 07B AI diary (GCO governance history, mostly obsolete mechanics -- not backfilled, noted as available), 06_BACKUP (90-entry daily log, mostly redundant granular health data already covered by medical backfill -- not individually backfilled, noted as available), ARCHIVE_INDEX (empty) and QUESTIONNAIRE (template only, no personal answers to extract). Wrote 5 more domain entries (ids 11-15): Location & Household, Weight Goal & Tracking Device, Communication Preferences, Pre-Gym-Logger PR history, and a meta pointer describing what's backfilled vs what's left in the zip. Total domain table now 15 entries for Health[70].

USR369 uploading legacy zips from old local systems to backups/old-zips/ (platform root, structure mirrors decade layout, upload in progress). TASKGATE returned genuine no-match for this task, per its own instruction wrote a new SOP rather than improvising. Documented the distinction between per-system archives (systems/[XX]-name/old-zips/, confirmed live for Health[70]) and the new shared consolidated one. Added entry to SOP-INDEX.md (append mode). Broadcast via COMMS action=broadcast to all systems (D671 correct mechanism, not inbox-api drop).

Root cause: 08_Medical_Details_v1.5.md (surgery history, chronic conditions, current meds, imaging history, BP episode/prevention protocol, weight history, blood/serology results) had been sitting in health-1_5_070526-master.zip (systems/70-health/old-zips/, 2.2MB) since 07/29/26 migration, never backfilled -- open as backlog item #4 since 07/06/26. USR369 confirmed via 'Yes' to backfill it now. Wrote 8 structured entries to 70-sys.db domain table (category=medical, ids 3-10): Basic Profile, Surgery History, Chronic Conditions, Current Medications, Imaging/Diagnostic History, BP Episode 03/22/26 Protocol, Weight History, Blood/Serology Irregularities. Closed backlog item #4 as resolved.

USR369: "the list is getting long and unmanageable" - referring to the exercise name picker, which pulls directly from every historical session's exercises[].name, deduped case-insensitively. Confirmed 24 unique names on file, real duplicates from typos/casing/phrasing (5 Biceps Curl variants, 3 Leg Extension variants, a mislabeled Tricep entry, one junk name "bicep curls two hands Redlands at 10 lb"). Renamed to canonical forms across all 13 affected sessions: Biceps Curl Single/Two-Hand/Bicept typos/junk-phrase-name -> Biceps Curl; Tricep curl free weights -> Triceps Extension; Leg Extension (2) -> Leg Extension; Leg extension roc-it (lowercase) -> Leg Extension Roc-It. Only the name label changed, not weight/reps/dates/any other data. Picker list now 15 raw names, ~9 after the app's own section-owned-activity filter (Bike/Pool/Swimming auto-excluded since those moved to dedicated sections).

Using gym-api.php's duplicates endpoint, reviewed all 8 duplicate clusters (16 redundant records, 26 true workouts). Found the tombstone list had the WRONG record marked for deletion in 4 of 8 clusters - the actual richest/most-complete record was tombstoned while a lesser duplicate survived, meaning the 07/10, 07/18 (no-timeIn), 08/13, and 08/15 workouts would have fully disappeared on next Sync, not just deduplicated. Rebuilt the tombstone list correctly: removed 4 wrongly-flagged keep records (1783709865322, 1783868092665, 1786466466626, 1786883160000), added 3 previously-missed genuine duplicates (1718064000001, 1786621380000, 1787058353434). Also cleared garbage/mismatched name fields on 3 surviving records ("Hello", "Text and images you copy..." clipboard-paste artifacts, and a wrong-date "David 15 easy workout" title bleeding onto a 06/13 and a 08/13 record).

v5.68: fixed newest-first sort not actually guaranteed after save (4 save paths). v5.69: brightened Cardio Warmup/Main/Cooldown section highlighting. v5.70: extended bright active-section highlight to ALL sections app-wide. v5.71: fixed blurry glow text, switched to clean light yellow. v5.72: added ✎ manager to Stretching Duration/Focus (last fields still on hardcoded lists). v5.73: added Stretching Time In/Out with auto-duration; found/fixed finishWorkout() silently dropping Swimming and Stretching entirely. v5.74: simplified Stretching (removed manual Duration, Focus full-width); converted ALL remaining plain-text Notes fields (Cardio x3, Swimming, Stretching) to reusable dropdowns; found/fixed my own v5.72 gap (stretch_dur/stretch_focus never declared in sharedLists) and Cardio Notes also being dropped by finishWorkout. v5.75: Swimming expanded 4->6 stroke rows. v5.76: renamed Sauna section to Recovery, added Type dropdown. v5.77: Recovery expanded to 3 independent entries (sau/rec2/rec3), same nested pattern as Cardio's Warmup/Main/Cooldown. Every version: backed up before edit, both script blocks node --check clean pre-deploy, deployed, live file fetched back and byte-diffed against source.

USR369 directive (msg 3678, originated from a Daily[50] miss): every pickup queue item must be read and acted on in full, no partial scans. Read every community and personal item in full (most from 08/10-08/18, mostly routine session-close reports and admin housekeeping). Two items specifically verified for Health relevance: msg 3557 (Daily's gym trip pattern analysis + their own Montclair mileage correction, informational, no Health action needed) and msg 1048 (Health's own outbound note to CC, already sent). Nothing found requiring new action from Health. Resolved all 65 community + 68 personal items individually via inbox-api.php/transfers action=resolve.

v5.56: Add Profile no longer requires Full Name, 3 initials alone suffice. v5.57 (K362): empty-profile-list native select with one option didn't fire onchange on mobile, added real always-tappable button. v5.58 (K363): History was sorted by record id (creation time) not the session's own date field, now sorts by date first. All three built live mid-workout, Health direct per D716/D720.

Root cause: clearForm() reset currentEditingId in-memory but never cleared localStorage['cai_gym_editing_id']/['cai_gym_hdr']. On next app load/reload, boot restore-check read the stale id back out and reattached it to the new record, so a fresh session could silently inherit an already-tombstoned id and vanish on next Sync. Fix: added localStorage.removeItem for both keys inside clearForm() itself. Built directly under Health authority (D716/D720), not routed to Builder.

SOP said canonical profile=david since 08/09, wrong since K357/08/15 discovery that DLM is the real app-facing profile. Rewrote SOP v1.0->v1.1: all profile references changed david->DLM, added CORRECTION section, updated HISTORY.

Sauna must use the app's dedicated session.sauna field, never an exercises[] entry -- corrected on 3 sessions, now a standing rule in todo-70.md for any future Health-built session writes.

When USR369 could not identify the exact swim stroke used, added an honest 'Surface (stroke unspecified)' option rather than guessing a specific stroke name for the data.

USR369 corrected initial build (v5.49) -- removing a profile from the Gym Logger app must NOT delete its gym.db session data, only remove it from the local device profile list. Implemented in v5.50, with a server-side explanatory marker record added in v5.51 per USR369's own suggestion.

Actual gap confirmed 08/13/26 as 07/08/26 through present (~11 sessions), not the 3 sessions previously tracked in todo-70.md. Flagged high priority, rebuild from gym.db directly rather than hand-patching the old file, not yet done on the yttcom.net side.

Direct read of live gym.db via load.php shows session id 20260811 status=complete with a FINAL CLOSE note already present -- the prior handoff's assumption that it was stuck in_progress was incorrect, no action needed, closing that todo item.

Two confirmed blockers: T2524/T-DRIVE-WRITE (Drive append) and T759 (local xlsx binary corruption). USR369 confirmed T759 is being worked on - holding.

save.php is INSERT...ON CONFLICT DO UPDATE only, no DELETE logic exists. Confirmed via source read and live test. Assigned Builder[20], priority med.