UPDATE 09/02/26 (Master[10], D979): Root-caused the 08/21/26 rollback via the platform's own decision log (D792-D795) -- 3 separable failures: reactive/incomplete discovery, a sed bulk-edit corruption bug, substring-match verification too weak to catch it. Researched zero-downtime rotation patterns (9 sources), wrote SOP-TOKEN-ROTATION.md with a proposed 5-phase runbook (exhaustive discovery -> idempotent tooling tested before live -> small pilot -> platform-wide cutover -> disable-not-delete with tested rollback). Prep/research only -- no live token action taken. Open questions logged in the runbook itself: who builds the discovery tool (Server[40] territory), how to size the real observation window, whether this rotation should happen before or alongside the Authorization-header/split-credential architecture work this task originally describes.

T2523: built a tool to archive zip old entries out of LEGACY-[decade].md files (append-only, never-overwrite, grow forever otherwise). Deployed twice -- v1 accepted an arbitrary path param and got 403'd even with no params passed and a valid token, before PHP ever ran (compared directly against TASKGATE.php in the same folder, which correctly returns 401 for a bad/missing token -- so this is being blocked before reaching the script, not by the script's own logic). v2 removed the arbitrary path entirely -- hardcoded whitelist of only the 11 known LEGACY-[decade].md paths, decade code input only -- still 403's identically. So it is not the arbitrary-path shape that is triggering it. Likely candidate: the combination of file_put_contents mkdir ZipArchive in one file matches a generic webshell/file-manipulation signature regardless of access control. Need Server to check server/WAF logs for the actual block reason and either whitelist this specific tool or advise a different implementation approach that will not trip it. Current file content is at systems/commands/ROTATE.php (v2, decade-code-only design) -- safe to review, has not successfully run yet.

UPDATE 09/04/26 (Master[10]): BYTE-CONFIRMED orphaned, not just circumstantial anymore. Read Daily[50]'s own live data/api.php source directly: $db_file = $dir . '/50-sys.db' -- the real, active DB is 50-sys.db (147456 bytes), confirmed correct. systems/50-daily/data/50-daily-sys.db exists separately (36864 bytes, smaller, genuinely different file) and is not referenced anywhere in api.php's source. Same limitation as T738/T735 -- actual retire-to-trash needs retire-files.php, whose real path I couldn't find (see broadcast 121). Diagnosis is now certain; execution is the only remaining step.

Two '95-travel' folders exist on ikre84i@yttcom.net Drive under same parent (canonical: created 07/23, has Backup/ + ES2026/JT2026 history; duplicate: created 07/25 today, holds the working SD2026 Notes/Expenses/Daily Log files + a stray extra Daily Log copy). Canonical copies of Notes/Expenses/Daily Log now placed in canonical 95-travel/SanDiego-072526-072826/. No Drive delete tool available to this session — needs manual trash of duplicate folder tree (id 17qmjFNht9Q1laOpFB8YuNQvNAyQD3Ihk) and its contents.

D109 established context_pct field. Schema not yet applied to Server [40] and Builder [02] system DBs. Confirm which tables need the column and deploy.

USR369 direction 08/26/26: needs a single dedicated ZIP containing BOTH systems/old zips ref/ (293 archived zips, see SOP-OLD-ZIPS-INDEX.md) AND its connected database systems/old-zips-index.sqlite (FTS5 search index, J102 in jurisdiction.db) together, saved server-side (suggest backups/platform/, dated filename). One-time only -- neither the folder nor the db changes session to session, per SOP-SNAPSHOT-EXCLUDE.md. No existing platform tool does a scoped/targeted snapshot of an arbitrary path (SNAPSHOT.php only does full-platform runs, confirmed live 08/26/26 -- two accidental full 140MB snapshots created today while investigating this). Admin[00] deliberately did not write a throwaway script for this itself (server-side script execution is Server[40]'s lane, not Admin's, per LANE RULE + no-self-forcing). Companion to T2540 (excluding these same two paths from future regular SNAPSHOT.php runs) -- that task covers the ongoing exclude, this one covers the one-time standalone copy USR369 actually asked for.

Build Diary DB (backend/build-diary/api.php) has only 1 real entry (itself) as of 08/11/26 -- every actual app built before D718 (08/10/26) is missing. Master broadcast a call to all 11 systems 08/11/26 to self-report their own existing builds via action=add, since only the owning system reliably knows built_by/version/backup status/purpose for its own apps -- Master isn't guessing at that data. Tracking here until all systems confirm done or report they have nothing to backfill.

SPEC DELIVERED 08/05/26 - see systems/governance/SPEC-GOVFILE-SUFFIX.md for the full staged migration plan. Awaiting USR369 review/approval before Stage 1 (Server 40 build) begins. Original scoping detail preserved below. USR369 wants to know why decade isn't used platform-wide - honest answer: WHITELIST and (inconsistently) LEGACY already drifted that way, but directive/jurisdiction/knowledge/handoff/todo are still hardcoded to CODE suffix in OPEN.php and read by CLOSE.php/CHECKPOINT.php across all 11 systems. Standardizing for real means rewriting those Tier-1 command files, not just renaming gov files - needs a real spec, staged rollout, and testing per system before going live, not a live hot-patch. This ticket is the spec-drafting step; do not touch OPEN.php/CLOSE.php/CHECKPOINT.php until the spec is reviewed.

When adding a task via the UI, there is no field to set who it goes to (assigned_to). This should be a required or at least visible field on the task add form. USR369 flagged 07/16/26. Do not fix now — logged for later.

Pick button on backend/tools/db-admin.html not working on USR369's mobile. Admin [00] server-side diagnostic confirms wiring correct (toggleColPicker, z-index 10000, document.body append). Root cause is browser-side: mobile handling of position:fixed with overflow:auto containers, or touch events on dynamic DOM. Tech [03] needs browser console access to debug: check if panel appears in DOM inspector, check for JS errors. Admin exhausted 6 fix attempts blind. See inbox 191.

Tech[30] apps-directory sweep (msg 1185/4242) found SCRIPT-S002-S006 + one blank-code entry ("Fix File Permissions") sitting in their scripts table -- all genuinely Server[40] content (Find Large Files, SQLite DB Backup, PHP Error Log Tail, Trash Lifecycle Sweep, Write and Execute PHP via Temp File). Claimed via inbox reply to Tech[30]/Master[10] -- waiting on Tech to either register 30-app.db with dba_api.php or export the 6 rows directly, since dba_api.php does not have their db registered under any guessable key. Once received: decide proper home (40-sys.db items table already exists, 3 rows currently) and migrate.

Noticed while backing up file-reader.php before an edit (08/09/26): BACKUP.php's file-mode wrote backups/40-server/php/Server_file-reader_CURRENT.php. SOP-BACKUP.md RULE 1 explicitly bans both the System_ prefix and the _CURRENT suffix. The tool that's supposed to enforce the SOP doesn't follow it itself. Low priority, not blocking anything, but worth fixing since it'll keep producing non-compliant backups every time it's used until it is.

See K297. Not urgent -- SQLite is fairly resilient and no corrupted backup has been observed/reported -- but the current bootstrap's copy($src,$dst) doesn't account for WAL-mode's separate -wal sidecar file the way sqlite3's own .backup command or VACUUM INTO would. Server 40's call on priority and which fix to use.

Found during Server[40]'s USR369-authorized page consolidation project (HTML-CONSOLIDATION-TRACKER.md, D891/D892). Two different pages both relate to "Android Library": (1) frontend/30-Tech/android.html -- titled "Library — Tech[30]", confirmed byte-identical to windows.html (both serve Windows+Android content together, likely one shared multi-tab app deployed under two filenames), already linked from the Tech main page as "Android Library". (2) frontend/30-Tech/apps/android-library.html -- a separate app tool, titled "Android Library v1.0", rescued 08/26/26 from an orphaned Database_PREV copy that had no live version anywhere, now linked from the main page under a TEMPORARY label "Android App Library" to avoid an on-page naming clash. Content preview suggests real overlap (both have Scripts/Q&A/Log/Shortcuts/Commands sections) -- may need merging rather than just renaming, but that is a content judgment call for Tech[30], not decided here. Also unresolved: whether windows.html/android.html being byte-identical is intentional (one shared app, two entry URLs) or a bug -- also flagged in D884.

Master seeded backups/50-daily/spreadsheets/Daily-Mileage-Events-Log.xlsx (header row: Date, Type, Subject, Detail, Miles, Notes) and wrote SOP-DAILY-LOG.md v1.0 defining the dual-write requirement -- same pattern as Kitchen's bake log (SOP-KITCHEN-LOG.md). Going forward, every add_event also needs a matching row added to this spreadsheet, same session, events table stays source of truth. Read SOP-DAILY-LOG.md in full before the next logging session. Ownership of the file itself is Daily's from here per SOP-DATA-BACKUP.md's OWNERSHIP section -- this is a one-time seed, not something Master maintains going forward.

memory-pipeline-api.php is currently add-only - no way to retag or amend an existing knowledge record after the fact. Needed now because USR369 is flagging knowledge entries (starting with K183-K185, cross-ref K186) with an applications:yes/no tag for a planned personal app - a searchable tool that pulls from this knowledge DB plus shortcuts across other apps. Add an update_tags action (id + tags, same partial-update pattern as update_item/update_domain rolled out to system data APIs 07/29/26) so tags can be set/changed on existing records instead of requiring a new cross-reference entry every time. Made_by=USR369.

USR369 asked to look up a receipt using 'Marcus and TV' and report remaining balance. Searched all 41 Finance items (now 43) - no match for Marcus+TV together, no gift card/balance entries at all. Need USR369 to clarify what card/store/context this refers to before it can be resolved.

PARKED 08/05/26 by USR369 direction - page location unfindable after exhaustive search. USR369 said forget it for now, will find it later. Do not keep searching - resume only when USR369 provides the location or asks to rebuild from scratch using Travel's lightbox pattern (openLB/closeLB/shiftLB) as a base. Original detail preserved: Lightbox opens but image is tiny on mobile (layout bug). Rotate buttons present but not functioning. Delete untested. Token fix applied 07/26/26 but issue persists. Needs full debug and retest on Android Firefox.

Samsung Fit 3 syncs to Samsung Health app. Export path: Samsung Health CSV export. Goal: import exercise data into Gym Logger. Needs scoping by Health [07] and Builder [02]. Route via Master [01].

Found while closing T572: new pages built under backend/standards/system/ get cross-linked page-to-page (dir/nav/clean all link each other + system/index.html) but are NOT automatically registered in page-inventory.html (master page registry, currently 102+ pages) or reflected in site-index.html (quick-links corridor page, built 07/26/26). This is a category/discoverability gap, not a broken-link gap -- pages work standalone but aren't surfaced through the platform's top-level indexes. Also found: site-index.html itself is returning HTTP 503 on repeated direct calls while general platform reachability is fine (isolated 3x) -- worth checking if that's a real bug before folding it into the same audit. Scope: (1) audit which live pages are missing from page-inventory.html, (2) decide whether site-index.html needs restructuring into real categories rather than a flat corridor, (3) fix or replace whatever is causing site-index.html's 503s, (4) establish a standing rule -- new page build = page-inventory.html entry + site-index.html entry, not just page-to-page cross-links, so this gap does not recur.

These three frontend pages still use baked-in JS data arrays. Data should be migrated to 30-app.db (new tables as needed) and pages converted to DB-driven like windows.html and android.html.

10/26 Server[40] (D1090): TASKGATE logic read in full. The 3 recorded false positives are rare-body-word coincidences (score 2 / wscore 2.0) that IDF weighting cannot separate from true matches; needs per-SOP keyword tags in SOP-INDEX.md or a human-confirmed match step. Open for Master to choose.

gym-api.php fixed live (D1047). gym-notion-sync.php and 170's backup script still hold it. Rotation is what fixes history. USR369 decides history rewrite with lanes 140 and 170.

USR369 direction 08/05/26 - full spec at systems/governance/SOP-HOUSEKEEPING-SCHEDULE.md. Two-part: (1) confirm whether this host supports real cron (LiteSpeed/cPanel) - if yes, that is the actual fix for daily/weekly duties, build it. If no, fall back to the session-open enforcement gate design in the SOP (non-blocking warn, same tier as the tokens STALE check). (2) Build the weekly housekeeping sweep: CLEAN.php dry=1 review, CLEAN.php real run, CLEANBACKUPS.php rotation, and full automatic trash-lifecycle enforcement (trash/ >3 days -> trash/archive/, trash/archive/ >5 days -> deleted, NO approval gate - USR369 confirmed the 8-day recoverable buffer is sufficient safety). Also confirmed while scoping this: SOP-HEALTH-CHECK.md's daily check has never actually run once since 08/02/26 (0 entries in MAINTENANCE-LOG.md) - whatever enforcement mechanism gets built should cover that duty too, not just the new cleanup sweep.

PARKED 08/21/26 by Admin[00]: asked USR369 which system built the photo center -- USR369 confirmed he does not know what it was used for either. No further searching will help since the source of the reference is unclear even to USR369. Leaving open but do not re-investigate until USR369 recalls more context or a photo center surfaces some other way. Prior exhaustive search (589 inbox msgs + knowledge.db) already ruled out: no such report exists anywhere on the platform.

USR369 direction 08/05/26: DoughCalc (frontend/80-Kitchen/apps/DoughCalc/index.html, currently v18, built 08/04/26 - baker's-percentage bread/pizza/custom calculator) needs a BUILD-DIARY.md, which does not currently exist (confirmed - file-reader returned path not found). Kitchen has the real version-by-version detail (v6 through v18) that Master does not - Kitchen should write it, not Master reconstructing secondhand. Once written, hand off to Builder [02] for standard integration review: hub-page wiring, page-inventory.html registration, HUB-PAGE-STANDARD compliance check - matches the platform's HTML/frontend task-lane rule.

Discipline list item 8, added 08/04/26 by USR369. Two linked pieces: (1) INVENTORY - build a real accounting of which files are actually in use by each of the 11 systems (PHP/HTML/JS/gov/data) as the baseline - page-inventory.html covers frontend pages but not the full picture (PHP commands, data APIs, gov files, JS assets). (2) SCHEDULED CHECK - a script that walks that inventory on a schedule and checks each file for errors - for PHP this means real syntax validation (php -l or equivalent, same principle as the existing D-SEARCH-FIRST node --check requirement for JS, just extended to PHP and run on a schedule instead of only at deploy time), for JS the existing node --check pattern, flagging any file that fails. (3) SOP - once the inventory + check approach is proven, write it up as SOP-FILECHECK.md (or similar), add to SOP-INDEX.md, broadcast. USR369 direction: not built yet, this ticket is to put the requirement on record - scope/build in a coming session. Related but distinct from T732 (governance-claims-vs-live-behavior diff) - this one is file-level syntax/existence health, not documentation-vs-code claims.

UPDATE 09/04/26 (Master[10]): Verified live (file-reader.php, 40433 bytes), backed up via BACKUP.php file-mode (backups/10-master/file/Master_records-api_PREVIOUS.php_CURRENT.php, confirmed readable). STOPPED before actual removal -- retire-files.php's real path isn't documented anywhere I could find (WHITELIST-40.md names the tool but not its location), guessed backend/tools/critical/ which 404'd. Rather than guess further at an unfamiliar destructive tool's path/params in a security-critical directory, holding here. Backup is a safe, verified fallback either way -- Server[40] can complete the actual retire-to-trash step with the correct tool path, or confirm it for me to finish.

UPDATE 09/04/26 (Master[10]): Verified live (file-reader.php, 6227 bytes), backed up via BACKUP.php file-mode (backups/10-master/file/Master_TASKGATE.previous.php_CURRENT.php, confirmed readable). STOPPED before actual removal -- same reason as T738 (paired task, same session, same tool needed): retire-files.php's real path isn't documented anywhere findable, guessed path 404'd, not guessing further at an unfamiliar destructive tool in a whitelisted systems/commands/ directory. Backup is a safe, verified fallback.

Already in Server todo. Check systems/10-master/history/ systems/20-builder/history/ systems/40-server/history/ — what files are there, are they current or legacy, should they be cleaned.

UPDATE 09/02/26 (Master[10], D976): Added 5 confirmed entries (Recipes, Bake Journal, Grocery Tracker, Dashboard, Kill Switch -- ids 13-17). Left OPEN, not closed -- 3 categories of real remaining work identified but deliberately not guessed: (1) ML Editor/DB Admin/Web Viewer/Panel have no sourced built_by/version in any system's ARTIFACTS file, (2) Gym Logger's 2 existing rows are stale (v5.88/v5.77), real state is v6.11 per Health's own correction note -- needs an UPDATE not a new row, (3) Tech's shortcut library files deliberately skipped to avoid colliding with CC[100]'s active platform cleanup work per USR369 09/02/26 direction.

master-tool.php deployed 07/22/26. Actions: read/scan/grep/exec_php/wipe all live. COPY action stubbed but needs verify. COMMANDS-01.php should reference master-tool.php so it appears in session orient. Low priority — tool is usable now.

Need to finish a housekeeping schedule make sure it doesn't delete the

We need to get the right full system to hit the read/right append and delete records on Google Drive, also investment for all the other sisters the idea is to keep it away from the server itself as a second data savior

PARKED 08/21/26 by Admin[00]: asked USR369 which viewer needs the UX pass (DB Admin / Master List / Dashboard) -- USR369 confirmed he does not know what it's used for either, meaning the original 08/07/26 dictated task can't be scoped from either side right now. TASKGATE already returned matched:false (no SOP fits). Leaving open, not actioning further until USR369 identifies the actual viewer -- guessing risks wasted build effort on the wrong page.