Windows/Android/Server library content lives in database rows (scripts/qa_log/shortcuts/commands tables), not files, so FreeCommander can never show it. Built frontend/30-Tech/apps/library-lookup.html: pick a library, search across all 4 categories at once, live counts per category, highlighted match text. Uses tech-library-proxy.php (built 09/08/26). Caught and fixed a field-name mismatch before finalizing: commands table uses 'cmd' not 'code'. Linked from Tech's categorized page list and added to page-inventory.html.

CC[100] flagged 28/38 qa_log rows with a literal 'n' where newlines should be, correctly declined to auto-fix given ambiguity. USR369 authorized fixing only the safe subset: 'n' immediately followed by a digit+period (clear numbered-list break pattern). Scanned all 38 rows, found 33 regex matches across 14 rows. Before applying, tested on row 27 first and caught a genuine false positive: 'python3.' matches the same n+digit+period shape but is a real word, not a stripped newline. Excluded row 27 entirely. Manually reviewed all remaining 32 matches with context to confirm each was a genuine numbered-list break, not another coincidental term. Fixed pattern also correctly handles doubled 'nn' (paragraph breaks) as two real newlines, not just single ones. Applied to 13 rows via 30-app-api.php action=update.

CC[100] correctly blanked the exposed admin token in these 2 pages, which broke their Q&A/scripts/shortcuts panels (30-app-api.php returns 403 without it). Built frontend/30-Tech/apps/tech-library-proxy.php -- holds the token server-side via auth-lib's cai_current_token(), whitelists only action=list (the single read-only action these pages use), matching Kitchen's doughcalc-api.php/bread-recipes.php pattern exactly. Updated both pages' API variable to point at the proxy instead of the direct API.

Per USR369's direct instruction, built a dedicated site-root directory with its own SQLite database (findings/progress/todo tables, tagged by project name) and API, so large multi-hour Project sweeps like this one log their granular detail there instead of bloating the main system decisions log.

A stuck keyboard key on USR369's end triggered accidental deletions while browsing the file manager. Diagnosed the actual blast radius via a real file-by-file comparison rather than assuming -- found the live site itself was untouched, only a staging copy (v2/) had lost files. Restored the live personal pages from this session's own snapshot.

Built a new 12-banner platform overview (11 systems + 369), each with Front End/Back End buttons colored to a recomputed high-contrast palette, went through many rounds of USR369 visual feedback before final deployment, replacing the prior backend/index.html (preserved to Trash).

Fixed 5 instances of a dead hardcoded admin token across android.html, win/server/android-scripts.php, COMMANDS-30.php, and factory-api.php. Genuinely removed 26+ confirmed-dead files (toolbox scratch scripts, temp/ pre-migration archives, internal trash folders) via server-side unlink/rmdir after preserving each to Trash first, not just content-stubbing.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Full detail: restructuring-project/restructure.db, project='Project Tech'.

Per USR369 direct instruction: large Projects (SOP-PROJECT-WORKFLOW.md) were bloating the main system decisions log with granular sweep detail. Built restructuring-project/ (site root) -- restructure.db (findings/progress/todo tables, one shared DB across all future Projects, tagged by project field) + restructure-api.php (standard shared auth-lib.php token, not hardcoded) + README.md. Backfilled Project Tech's 3 completed areas into progress, sample findings/todo entries confirmed working. Standard pages (page-inventory.html etc.) still updated directly and normally -- only the granular blow-by-blow moved out. Broadcast 103 sent to all systems. Full detail: restructuring-project/restructure.db, project='Project Tech'.

USR369 wanted a visual way to see which links have actually been checked -- added a linkOk field to the page-inventory.html data model, color-coded the URL button per entry (light blue #60a8e8 = verified live, red = verified broken, dim gray default = not yet checked), added a matching legend at the top of the page. Marked linkOk:true on all 23 entries actually verified in today's audit (the 19-page/57-link Tech sweep plus separately-confirmed android-library.html and backend/369/index.html) -- did not mark anything unverified as true, the color is meant to mean 'actually tested,' not 'assumed fine.' Also, per USR369's explicit direction, formalized the naming/process convention used all session into SOP-PROJECT-WORKFLOW.md: large sweeps like today's get called 'Project [Name]' (this one: Project Tech), with a 5-item close-out checklist (decisions logged, links checked+color-coded, page-inventory current, handoff rewritten with a full summary, confirmed-clean result copied to v2/). Registered in SOP-INDEX.md, broadcast platform-wide (broadcast 102) since this is meant to apply beyond just Tech.

USR369 asked for a closing audit before treating the Tech area as done: is page-inventory.html accurate for everything added/removed, and is everything recorded? Checked systematically rather than assuming: (1) page-inventory.html -- searched for any stale entries pointing at things retired today (temp/ library files, backend/369/claude code, Server_AuditDeliverables) -- found none, since those were never page-inventory-tracked items to begin with (backend utility/dropzone files, not user-facing pages). Confirmed n:181 (android-library.html) accurately reflects SUPERSEDED status pending Server[40]'s pickup. Confirmed n:184 (backend/369/index.html) is the only 369-related entry and is accurate. (2) Decision count audit -- confirmed via direct ping against Tech's own system DB that all 13 decisions logged this session (D913-D925) landed correctly (decisions count 38 at session start -> 51 now, exact match). (3) handoff-30.md was stale (last updated 10:58am, well before the systems/30-tech deep audit, the v2/ staging build, the full backend/369 cleanup, and the stuck-key incident/repair) -- rewrote it with a comprehensive summary of everything that happened after 10:58am as a new top resume-point item, so a future session (or USR369 himself) has an accurate record without needing to reconstruct it from decisions alone.

USR369 clarified 'move to trash, don't delete' -- since the actual content was already safely preserved in Trash/ from earlier this session (verified with real byte counts before touching anything: MASTER-INDEX.md 4100b, EXEC_OPEN Series R 33124b, Server audit zip 23627b, all confirmed non-empty), what remained in backend/369/ were 34 leftover placeholder stub files (the retirement-note text I'd left behind earlier, not the real content) cluttering the directory across claude code/, Server_AuditDeliverables_07_18_26/, and the old internal Trash/ subtree. Used PHP's own unlink()/rmdir() via a server-side bootstrap script to genuinely remove these 34 stub files and the 6 now-empty directories -- this is a real move (content already copied to Trash/, originals now actually gone), not a delete (nothing was lost, everything's still in Trash/ with real content). backend/369/ now holds only the 5 genuinely current/usable files (README.md, index.html, manifest.json, and the 2 intentional data/ redirect stubs) plus the untouched user369_space/. Re-synced v2/backend/369/ to match (wiped and re-copied fresh, 16 files now vs the prior 50 -- the drop matches exactly the 34 removed).

USR369 reported backend/369 'all got deleted' while browsing. Investigated live (not just HTTP status, direct filesystem read via file-editor.php) and found user369_space/ genuinely gone from the live site -- restored all 9 files (index.html, computer/index.html, electronics/index.html, 3 data files, personal.db, and the 2 legitimately-retired _TEST.html stubs) from my own local snapshot copy (downloaded earlier this session, independent of the live server, unaffected by whatever happened). Root cause per USR369: a stuck Delete key on his keyboard while browsing cPanel File Manager -- not anything Claude did. Ran a full file-by-file comparison (custom PHP script, live vs v2 mirror) to determine the actual blast radius rather than assume -- found the LIVE site was fully intact (missing_from_live: [], size_mismatch: [] -- confirms nothing was actually lost there beyond the user369_space files already restored), but v2/backend/369/ had dropped from 50 files to 9 -- the accidental deletions hit the v2/ staging mirror, not the live/old system. Re-copied the full backend/369 tree (50 files, 136076 bytes) from the confirmed-intact live copy into v2/backend/369/, repairing it completely.

USR369 confirmed the dropzone deliverables (EXEC_OPEN Series R zip, Server audit deliverables) were already picked up -- retired both, preserved to Trash. Retired the 'claude code' folder (4 files) -- confirmed stale via content read: a one-month-old snapshot of Master[10]'s setup (Series M, 07/30/26), long superseded by current Series T. Consolidated backend/369's own internal Trash/ subfolder (27 files -- old EXEC_OPEN D-series files, a GymLogger test artifact, old Series E/F zips) into the platform-wide Trash/ convention, since having two separate 'Trash' locations was itself part of the confusion. All content copied server-side and verified before any live file was cleared. USR369's personal space (user369_space/ -- computer, electronics, personal.db with 75 real rows) confirmed completely untouched and separate from all of this -- explicitly checked and confirmed live before and after.

Retired the last remaining confirmed-dead items: 4 pre-migration temp/ library files (LIBR_Android/Windows/Definitions_Tech + Tech_Library_UI.jsx, all confirmed unreferenced anywhere via full-snapshot grep before touching) and the qa_seed_boot.php/qa_seed_exec.php one-time DB seed pair -- handled these last two with extra care since qa_seed_exec.php contains a live DELETE FROM qa statement, so both were fetched and retired via read-only file-editor.php + direct content write only, never a live GET, to avoid any risk of accidentally re-triggering a data wipe (learned from the earlier self-deletion incident this session).\n\nFULL LINK AUDIT: extracted every href from the 19 live Tech[30] pages (frontend hub + all 10 apps/ pages + all 6 php-ed/ pages + the systems/30-tech backend hub + laboratory/apps-hub.html) -- 142 link instances, 57 unique internal targets after dedup. Checked live HTTP status on all 57. 5 initially flagged as 401 turned out to be a false positive in my own check script (file-editor.php links correctly require a token param, which my automated HEAD/GET check omitted) -- confirmed with the token, all 5 return 200. Real result: all 57 unique links across all 19 pages are live and working.\n\nPAGE-INVENTORY UPDATED: systems/30-tech/index.php entry (n:27) updated to reflect the Apps-link fix and link-audit result, status MINOR->DONE. Added 4 new entries not previously tracked: backend/369/index.html (n:184, the rebuild), and win-scripts.php/server-scripts.php/android-scripts.php (n:185-187, the token+title fixes) -- these 3 render live HTML pages but had no page-inventory entry before today.

MISTAKE FIRST, disclosed plainly: while doing a routine 'does this file still exist' HTTP status check on 4 toolbox files (boot_bkidx.php, boot_fix_hub.php, boot_roster2.php, boot_tools_desc.php), I didn't realize their content was a self-deleting bootstrap pattern (decode a companion .b64.txt file, write+include it, then unlink(__FILE__)). The GET request itself triggered execution and all 4 deleted themselves. Investigated the actual impact before doing anything else: their required .b64.txt payload files didn't exist (confirmed absent from the directory listing), so file_get_contents() returned empty, base64_decode('') produced an empty string, and the resulting _run.php files that got created were confirmed 0 bytes via read-only file-editor.php (not via a live GET, to avoid a repeat). No real code executed beyond the self-deletion. Preserved the pre-incident content (from the snapshot, fetched hours earlier and unlikely to have changed) to Trash for all 4, and cleared the 4 orphaned empty _run.php residue files. Lesson for future checks: read a toolbox/backend script's actual source via file-editor.php (read-only) before ever hitting it with a live GET for a status check -- a 200 isn't harmless on files that can have side effects.\n\nREAL BUG FOUND AND FIXED: COMMANDS-30.php (the CURRENT, actively-referenced toolbox command file per REFERENCE-30.md's standing duties) had the same dead hardcoded token as 4 other files fixed earlier this session -- confirmed broken with the current token (unauthorized), fixed, confirmed working with a live functional test (real link_check output, not just a write-success response). This is the 5th instance this session of the same token-migration gap.\n\nRETIRED (confirmed dead/superseded by actual content read, not just filename pattern), all preserved to Trash first: bak_exec.php, dbcheck.php, dbcheck2.php, dirscan.php, test_write_check.php (already-zeroed/empty leftover scratch scripts) -- COMMANDS-03.php (explicitly self-marked INCOMPLETE, superseded by COMMANDS-30.php) -- 3 config/EXEC_OPEN_Tech.30.*.txt dot-naming files (each self-documented 'ARCHIVED 08/01/26 -- superseded by Series P -- no longer active') -- the 4 self-deleted boot_*.php files (preserved from snapshot) and their 4 empty _run.php residue files.

USR369 asked to go through 369/ and clean up duplicates, keeping the more complete version of each. Corrected an earlier assumption of mine along the way: 369/data/electronics-public.json and personal-api.php are NOT stale duplicates -- verified by reading actual content, they're intentional 410/moved redirect stubs pointing to the real files in user369_space/data/, working exactly as designed. Left those alone. Actually retired (all verified by content, not filename pattern): (1) 369/data/personal.db -- confirmed empty via direct SQLite query (0 rows in all tables), no redirect function unlike its siblings, genuinely stale vs the real personal.db (75 real computer_items rows). (2) user369_space/computer/index_TEST.html -- internal version comment showed v1.0 vs the live page's v1.1, confirmed superseded draft via diff. (3) user369_space/electronics/index_TEST.html -- diffed against the real page, confirmed it's the pre-migration version whose own fetch path now points at a dead 'moved' stub, would show broken/empty data if loaded. All three preserved to Trash/ (byte-verified) before the live copies were replaced with either a retirement marker or a meta-refresh stub pointing to the real page. Also asked USR369 directly whether the EXEC_OPEN downloader embedded in 369/index.html was still in use -- confirmed not (superseded by direct file-upload to Claude, exactly how this session started) -- rebuilt the page: removed ~100KB of dead Series-F content (5 series behind current, every embedded example had the retired admin token baked in), fixed a real bug found along the way (dropzone file listing fetched the wrong path, /0369/manifest.json instead of /backend/369/manifest.json, silently showing 'Could not load files'), kept the working 'Your Space' personal-area link that was already correctly separated from the front page.

USR369 asked for a way to give Claude real directory visibility (not one-off HTTP guesses) ahead of a multi-file cleanup pass, and specifically wanted it built as an organized, repeatable, platform-wide pattern since every system will eventually need this. Discovered backups/snapshots/ is 403-blocked from direct web access at the server level (confirmed: not just directory listing, a specifically-named file inside it also 403s). Solved by writing a one-time server-side PHP bootstrap script (SCRIPT-S006 pattern -- temp file, execute via HTTP, zero after) that uses PHP's own copy() function to move the ZIP out of backups/ into a new web-reachable dated folder (snapshots/preview_08_27_26/) -- server-side file copy isn't subject to the same web-request-level block. Verified byte-identical at copy time (41977901=41977901) and again after download into Claude's own workspace, then confirmed extracted file count (3444) matches the platform's own snapshot response. Documented the full pattern in a new SOP (systems/governance/SOP-SNAPSHOT-WEB-ACCESS.md), registered it in SOP-INDEX.md, created the tracking log the SOP requires (SNAPSHOT-WEB-ACCESS-LOG.md), and broadcast it platform-wide (broadcast 101) since USR369 explicitly said all systems will need this. Also logged (in the tracking log, not hidden) a mistake made during discovery: guessed an invalid SNAPSHOT.php action=download value which silently created a duplicate snapshot instead of erroring -- that duplicate was left alone, not used or cleaned up, flagged for whoever wants to deal with it.

Follow-up to D917 (fixed the Apps link on systems/30-tech/index.php). With that link no longer pointing to systems/30-tech/apps/index.php, checked whether anything else referenced it -- nothing did, it was now fully orphaned. Rather than leave a dead, misleading placeholder reachable by direct URL or bookmark ('No apps listed yet' despite 11+ real apps existing), preserved the original content to Trash/systems/30-tech/apps/index_superseded_08_27_26_11amPT.php (byte-verified, 1402b) and replaced the live file with a simple PHP redirect to frontend/30-Tech/index.html, the real maintained hub.

Continuing the backend audit: systems/30-tech/index.php (the backend Tech landing page) had an 'Apps' quick-access link pointing at systems/30-tech/apps/index.php -- a placeholder scaffold from 07/12/26 that was never populated ('No apps listed yet -- build out links here as apps are completed'), despite 11+ real apps existing in that exact directory now, all properly indexed on frontend/30-Tech/index.html. Anyone clicking 'Apps' from the backend hub was landing on a misleading dead end. Fixed by pointing the link directly at the real, actively-maintained frontend hub instead of duplicating a second app list that would need separate upkeep. Also noticed (not fixed, flagging only): the adjacent 'Internet' quick-link on the same page is a literal href="#" stub that goes nowhere -- purpose unclear, left alone per 'ask don't guess' rather than assuming what it should link to.

Continuing the backend token-check sweep: found factory-api.php (systems/30-tech/apps/Factory/) hardcoded the same dead old admin token as its OWN internal validation check ($TOK = 'yttcom-admin-d60283...'), rejecting the current token outright. Confirmed via direct test: current token returned {error:unauthorized}, old dead token returned status:ok. This is a 4th instance of the same migration gap but a different shape -- the prior 3 fixes this session (android.html, win/server/android-scripts.php) were CLIENT pages calling out to an API with a stale token; this one is the API endpoint ITSELF validating against a stale token internally. Fixed by migrating to the same shared backend/config/auth-lib.php pattern already proven working in apps/Inventory/inventory-api.php (fixed 08/22/26 by Server[40], msg 1118/4054) -- replaced the hardcoded $TOK exact-match check with require_once auth-lib.php + cai_require_token($token), which accepts either a current active token from tokens.json or an authenticated browser session cookie. Also checked systems/30-tech/laboratory/apps-hub.html (the frontend hub's 'Applications Reference' link) which calls lab-api.php and inventory-api.php with the same old hardcoded token as a CLIENT value -- confirmed this is NOT a bug: both of those APIs only accept the old token (lab-api.php rejects the current token outright, inventory-api.php accepts both via its own auth-lib.php fix) -- left apps-hub.html untouched since changing its token would break it against lab-api.php specifically.

Started the backend half of the audit (systems/30-tech/). Investigated the HTML-CONSOLIDATION-TRACKER.md Family F secondary bug (win-scripts.php/server-scripts.php/android-scripts.php -- flagged as byte-identical, wrong titles on 2 of 3). Found two real, distinct issues, not one: (1) The tracker's read was incomplete -- these are NOT a duplicate-content bug, same pattern as the frontend android.html/windows.html case: one shared template with a self-detecting IIFE (checks location.pathname, sets page-title span + platform badge + fetches library-specific data live). The actual content correctly differentiates once loaded. (2) A REAL bug the tracker missed: all 3 files had a single hardcoded TOKEN constant that was fully dead (confirmed via direct API test -- old token returns {status:error,message:unauthorized}), meaning the live data fetch was silently failing in the browser on all 3 pages even though the page shell loaded fine (200). Same root-cause pattern as K402 (apps/Inventory/inventory-api.php) and the android.html fix earlier this session -- a third instance of the Core Five token-migration gap in a per-system subdirectory the broadcast 76 sweep never covered. Also fixed a real cosmetic bug while in there: the static <title> HTML tag always read 'Windows Scripts' on all 3 files regardless of which page you were on (only the in-page page-title span updated dynamically) -- corrected server-scripts.php and android-scripts.php's <title> tags to match their actual content.

Full pass over frontend/30-Tech/ following up on the 08/26-27 sweep + this session's naming-collision fix. Checked every remaining loose item: (1) apps/Inventory/davidslaptop-reference.html and its _TEST copy -- both already 404, prior 08/25 personal-data migration already removed them, nothing to do. (2) php-ed/ -- 6 files, all live (200), internal next/prev nav chain verified intact (index->01->02->03->04->05->back to index, no broken links), each has a working but non-standard back-link instead of the full platform Top Bar/Bottom Tabs chrome -- left as-is (matches existing MINOR status in page-inventory.html, functional not broken, didn't rebuild UI chrome on 6 files without being asked). (3) 'Applications Reference' hub link to systems/30-tech/laboratory/apps-hub.html -- verified live (200), a legitimate frontend-to-backend bridge link, not a duplicate or mess. (4) check_temp.php (flagged open-question in the prior tracker) -- already 404, moot. (5) Re-verified all 11 real app files plus the hub itself all return 200. Frontend/30-Tech/ is clean modulo the one still-open item (android-library.html live-file retirement, waiting on Server[40], transfer 4264).

Investigated the android.html vs android-library.html naming collision (transfer 4238/inbox 1184, filed by Server[40]) instead of just picking a new name. Root cause found: android-library.html was promoted 08/26/26 from an archived Database_PREV copy as a stopgap because android.html was broken at the time (stale token in 30-app-api.php blocked all data). Verified via live API query (action=list&table=qa_log&library=android): the live DB now has the SAME 6 Q&A entries (Termux duplicate finder, X-plore transfer, large-file finder, heredoc method, python install, Termux keys) as the static file's QA-A001-A006, plus MORE shortcuts (28 live vs 11 static) and commands (19 live vs 17 static) since android.html was fixed 08/27/26. Confirmed android.html/windows.html sharing the same 11,778-byte template is by design (JS detects LIB from URL path, fetches library-specific data live) -- not a bug, resolving Server[40]'s own HTML-CONSOLIDATION-TRACKER.md Family F 'NEEDS DECISION' item too. Actions taken: preserved android-library.html content at Trash/frontend/30-Tech/apps/android-library_superseded_08_27_26_11amPT.html via file_write_web.php (byte-verified 28257b match, full content diff clean), removed its link from the Tech hub (frontend/30-Tech/index.html, verified), updated page-inventory.html entries n:148 and n:181 to reflect resolution. Could NOT execute the actual live-file retirement -- backend/tmp/retire-files.php (per SOP-PAGE-HYGIENE.md, owned/built by Server[40]) returned 404 on every path/method tried (GET, GET+path param, POST). Sent Server[40] the full finding plus a request to execute the retirement with their own tool.

New standing rule: every system's final close now re-scans the actual conversation transcript (not just internal memory) to confirm everything discussed was logged and anything unfinished is written into the handoff before CLOSE.php runs.

Every system, every handoff write, now sorts items into still-open/resolved-verified-preserved(drop)/resolved-routine(drop) instead of only ever appending. Shrink-guard + NO-SELF-FORCING still require USR369's yes every time.

Piloted SOP-APPS-DIRECTORY-STANDARD.md: fixed stale token blocking Windows/Android Library, rebuilt corrupted scripts.html to fetch live data instead of a broken static snapshot, moved windows/android/scripts/define/shortcuts/php.html into apps/, updated every hub link, updated page-inventory.html for every touched page.

USR369 asked for a conversation-level audit before starting a fresh Tech session, plus a new standing rule that every final close reviews the conversation itself. Audited: pulled list_decisions for system=30 and confirmed every decision made this conversation (D883, D885, D894 through D909) is actually logged -- nothing missing. Updated handoff-30.md with 2 items that weren't yet captured: (1) SOP-LEGACY-HYGIENE.md exists but has never been applied to a real file yet (not urgent, Tech's own LEGACY-30.md is still too short to need it), (2) the platform-wide apps-directory sweep is only done for Tech[30] -- 10 systems still to go, pointer to APPS-SWEEP-STATUS.md added. Built SOP-CLOSE-CONVERSATION-REVIEW.md: every system, every final close (CLOSE.php specifically, not JANUS), re-scans the actual conversation transcript before submitting the close -- cross-checks that everything discussed has a matching logged decision (pulled from the real decisions list, not assumed from memory) and that anything genuinely unfinished gets written into the handoff rather than silently dropped because the conversation is ending. Works alongside the two hygiene SOPs from earlier this session -- this one catches gaps before close, the other two keep the handoff/LEGACY current afterward.

USR369's proposed basis for trimming LEGACY files: if a LEGACY entry's content is already captured in a logged decision (structured, D-code searchable, more authoritative), the prose duplicate in LEGACY can be trimmed. Wrote SOP-LEGACY-HYGIENE.md: verify entry-by-entry (not wholesale) that EVERY fact in a given LEGACY entry is covered by a matching decision before trimming -- a resolved entry can still contain narrative/context never formally logged, which doesn't qualify. Different test than SOP-HANDOFF-HYGIENE.md (that one asks 'safe to drop from the active list', this one asks 'is every fact already in the database'). Same shrink-guard/NO-SELF-FORCING applies -- ask USR369 first every time. Periodic review, not a per-session step like handoff hygiene.

USR369 approved the first live test of SOP-HANDOFF-HYGIENE.md on Tech's own handoff-30.md. Verified before pruning: the 08/26-27/26 apps-directory sweep + archive-hunt narrative was already fully preserved in LEGACY-30.md (JANUS append, 08/27/26 9:11am PT entry, confirmed present) and in decisions D883/D885/D894 through D908 (Tech's own system API + records-api, all confirmed logged this session). Pruned that resolved narrative out of the active handoff, replacing it with a short pointer to where it actually lives now (LEGACY entry + decision codes + the 2 live tracking pages). Carried forward every still-open item unchanged (naming collision, Server[40] pending message, Computer/Windows-11-Desktop question, FreeCommander confirmation, Handy app, and all prior-session open items). Result: handoff dropped from 9909 to 4728 bytes -- deliberate, verified, not accidental.

USR369 identified a real gap: LEGACY-XX.md accumulates history correctly via automatic JANUS/CLOSE.php append, but handoff-XX.md never gets pruned of resolved items -- it only grows, and the shrink-guard (meant to prevent accidental loss) makes deliberate cleanup require an ad-hoc override each time, which discourages it. Wrote SOP-HANDOFF-HYGIENE.md: every system, every handoff write, sorts each item into still-open (keep) / resolved-and-worth-keeping (verify it's actually in LEGACY or a logged decision, append first if not, then remove from handoff) / resolved-and-routine (drop, no LEGACY entry needed). Shrink-guard still requires USR369's yes every time -- this SOP makes pruning a routine verified step, not a bypass.

Executed USR369's follow-up instructions after the apps-directory sweep: (1) retired check_temp.php to Trash (was a tiny debug utility, not a user-facing app -- not hard-deleted). (2) Sent Server[40] a full write-up via inbox-api.php (transfer id 4242, confirmed delivered to Server's personal queue) about SCRIPT-S002-S006 sitting in Tech's own 30-app.db, asking Server[40] to claim-and-move or delete them -- Tech left them alone per cross-system scoping. (3) Updated page-inventory.html: corrected URLs for all 6 moved files (root -> apps/), updated statuses to DONE, added a missing entry for shortcuts.html (was never in the inventory), flagged the android.html/android-library.html naming collision directly in both entries' descriptions. (4) Ran JANUS -- SYNC/LEGACY-append/inbox-self-drop all completed clean, but the handoff-30.md write was correctly blocked by the shrink-guard (my summary was much shorter than the existing 8,735-char handoff, which had real carried-forward context going back to 08/21). Per no-self-forcing, did not override -- instead wrote a genuinely comprehensive replacement (9,909 chars) that preserves every still-open item from the prior handoff (naming question, FreeCommander confirmation, Handy app, C: drive cleanup, etc), marks the Database_PREV search thread as resolved (confirmed non-existent, real content recovered from archive instead), and adds this session's full work. Deployed successfully on the second attempt.

Completed the Tech[30] apps-directory sweep (pilot for SOP-APPS-DIRECTORY-STANDARD.md, new SOP written this session). Fixed windows.html/android.html by correcting a stale hardcoded token in systems/30-tech/data/30-app-api.php (didn't match current live admin token) -- confirmed both now load genuinely distinct real data (22 Windows Q&A entries, 6 Android Q&A entries, plus scripts/shortcuts/commands tables, 137 shortcuts total). Rebuilt scripts.html (v1.0a -> v2.0): its static data was confirmed corrupted (duplicate ids sharing the same orig_id with different content, several Windows entries had Android/Termux answer text pasted in instead of their real answers) -- rebuilt to fetch live from the same fixed API, filtered to library IN (windows,android) only, explicitly excluding Server[40]'s own scripts (SCRIPT-S002 etc) that live in the same shared database table. Old corrupted static version archived to Trash (not deleted). Moved all 6 real root-level files (windows/android/scripts/define/shortcuts/php.html) into frontend/30-Tech/apps/, retired the originals to Trash via retire-files.php, updated every hub link to point at the new apps/ locations, consolidated the hub's 3 separate box sections into one. The 2 stale PREVIOUS_ files were already gone (404) before I could retire them -- USR369 must have removed them separately. check_temp.php (a tiny debug utility, not a user-facing app) left in place -- its purpose is clear but where it belongs isn't, flagged rather than guessed on. Built the Tech[30] sweep tracking page and updated the platform-wide APPS-SWEEP-STATUS.md.

USR369 clarified he doesn't want systems reading/using each other's data points from the old-zips archive, only their own. Added a 'Cross-system scope' section: the archive is one shared pool (not per-system), so search hits belonging to other systems will surface incidentally -- each system is responsible for only acting on/saving its own relevant hits, never writing another system's recovered content into its own live pages, and saving findings only in its own files, not another system's space or a shared governance file (unless genuinely platform-wide).

USR369 asked for platform-wide guidance so ANY system reading the old-zips archive knows to save specific extraction paths for reuse, matching the sandbox breadcrumb practice built for Tech[30] earlier today. Added a new section to SOP-OLD-ZIPS-SEARCH.md (owned by Server[40], applies to all systems per its existing 'Who: All systems' line): what to save (search terms, exact confirmed path, one-line verdict), where to save it (sandbox page / decision detail field / knowledge note -- whichever fits the system), and why it matters specifically for this archive (false leads look identical to real ones until content is actually read, so the reasoning behind a rejection needs recording too, not just the accept/reject outcome).

Corrected my earlier characterization: windows.html and android.html are NOT a duplicate-content bug -- they're a single legitimate template that switches content based on URL path (location.pathname detection), by design. The real problem is their shared backend (systems/30-tech/data/30-app-api.php) returns status:error/unauthorized for both -- neither page can load any data right now, confirmed via direct API test. Checked the other 4 root-level files: define.html (138 real entries, self-contained, working), php.html (~74 entries, self-contained, working), shortcuts.html (menu page linking to 2 real working detail pages -- FreeCommander and X-plore shortcut references at systems/30-tech/laboratory/library/, both confirmed 200/substantial size), scripts.html (real unique QA-driven data structure but has scrambled title/answer pairs -- confirmed one entry titled about Windows 11 performance actually returns an Android duplicate-finder answer -- plus the QA-A006/QA-W010-013 entries recovered earlier today are present with correct titles but empty answer fields). Per USR369's rule (use what's active/working/non-duplicate, flag the rest), added a directory-location badge to every box on the Tech hub (frontend/30-Tech/index.html) showing exactly where each file lives (30-Tech root vs apps/ vs laboratory/ vs php-ed/), plus a visible warning label on Windows Library, Android Library, and Tech Scripts noting they're currently broken so nobody clicks in expecting them to work.

USR369 reviewed the second, root-level Tech library set (windows.html, android.html, scripts.html, shortcuts.html, php.html, define.html at frontend/30-Tech/ root -- separate from the apps/ set fixed earlier this session) after I found real bugs in it: windows.html and android.html are byte-identical (android.html should have distinct content but doesn't), and scripts.html has scrambled title/answer pairs plus empty answer fields for the QA-A006/QA-W010-013 entries that were correctly recovered into the apps/ set today. USR369's decision: leave this second set as-is, not worth fixing since it's not the set actually being used. No changes made to any of these files. Two pre-existing PREVIOUS_ files in this same folder (PREVIOUS_scripts_07-24-26.html, PREVIOUS_index_07-24-26.html, dated before today's SOP-PAGE-HYGIENE.md) also left untouched pending this same 'leave it' call -- not cleaned up, flagged for awareness only.

USR369 requested a standing SOP: capture electronics info and tech Q&A into the database automatically, and register it in TASKGATE. Also, while checking TASKGATE for this task, discovered a new same-day SOP (SOP-PAGE-HYGIENE.md) that directly prohibits the exact pattern I'd used earlier this session -- creating PREVIOUS_[name]_MM-DD-YY.html backup copies inside the live apps/ folder before overwriting (I'd done this 3 times: housekeeping-library, script-library, android-library). Corrected immediately via backend/tmp/retire-files.php, moving all 3 into Trash/frontend/30-Tech/apps/ with proper _superseded_ timestamp suffixes -- nothing lost, live folder now clean per the new SOP. Then built SOP-ELECTRONICS-CAPTURE.md: devices go to personal-api.php's computer_items table (device field is free text, not limited to computer hardware), Q&A goes to housekeeping-library.html's existing qaData array using an 'ELEC / ...' topic string when no clearer sub-category fits. Registered in SOP-INDEX.md, confirmed TASKGATE now matches it (score 2/1.2) for electronics-related task descriptions. Immediately put it to use: added Samsung HW-T650 Soundbar and Samsung PS-WR65BB Wireless Subwoofer (from this session's photos) as new computer_items rows (ids 74, 75), regenerated + redeployed computer-public.json (75 total rows), and added QA-011 to housekeeping-library.html's QA log covering the Bluetooth pairing + 'Unknown device' troubleshooting steps worked out this session.

USR369 approved using the recovered content from the archive hunt ('ones you have unless you get better ones'). Added the 3 confirmed real gaps found in round 3: (1) SCRIPT-005 'Disable OneDrive Completely' (PowerShell, full working code) added to script-library.html's SCRIPTS array, now 001-005; backed up prior live version to PREVIOUS_script-library_08-26-26.html first. (2) QA-A006 'Connect Android to Windows via X-plore' added to android-library.html's QA array, now A001-A006; backed up prior live version to PREVIOUS_android-library_08-26-26.html first. (3) 4 Windows-specific QA entries (QA-W010 LAN file sharing, QA-W011 Pinegrow editor recommendation, QA-W012 FTP/cPanel server connection, QA-W013 Windows password recovery) added to housekeeping-library.html's existing but until-now-unused qaData array (that tab was rendering correctly but had zero matching entries before this -- confirmed QA-001 through QA-010 were already there, W-series were the gap). All content converted from the archive's compact single-quoted JS literal format to each live page's own double/mixed-quote field format, matching existing entries exactly.

USR369 reviewed the archive-review sandbox (D895) and approved swapping live housekeeping-library.html for the archived HousekeepingLibrary_v1.0.html (47,297B vs the old live 33,773B). Backed up the pre-swap live version to frontend/30-Tech/apps/PREVIOUS_housekeeping-library_08-26-26.html (matching the folder's existing PREVIOUS_* naming convention) before overwriting. Then went hunting per USR369's direct instruction for missing/richer content across the other 3 flagged pages using the same old-zips archive tools. Found: (1) SESSION/08_QA_LOG_Housekeeping_v1.4.md -- a genuine master QA narrative log with 14 full Q&A entries (QA-001 through QA-014), most of which the newly-restored housekeeping-library.html already includes (confirmed QA-001 through QA-010 plus QA-014 present in its own QA array -- QA-011/012/013 appear missing even from the archived version, a gap worth flagging back to the source log, not something I invented); (2) Master/TRANSITORY/Tech_Scripts_v1_0_06_29_26_v1_0a.html -- a unified cross-system QA search prototype (despite the filename, contains QA entries not SCRIPT entries) proving QA-015 through QA-018 and QA-W010 through QA-W013 (Windows-specific) and QA-A006 (one more Android QA than currently live anywhere) once existed -- this content has NOT been located/recovered yet, flagged as the next real lead; (3) Tech_Library_UI_PREV.html -- re-confirmed as a genuine dead end/false lead (internally titled 'Housekeeping Library v1.0', not real Tech content) -- no other unique Tech Library UI historical content found in this session's search despite additional passes; (4) Tech_Android_Library_v1.0.html and LIBR_Android_Tech_06_20_26_v1.0a.html -- both confirmed byte-identical or functionally identical to the current live android-library.html (3 scripts, 5 QA, same content) -- no richer historical Android version found, the current live page appears to be at its actual historical peak for this specific dataset; (5) No evidence anywhere in the archive of a SCRIPT-005 or higher -- script-library.html's 4 live entries (SCRIPT-001 through 004) appear to be the full historical set, not a trimmed-down version, based on everything searched this session.

USR369 asked for a link to the new Tech[30] archive-review sandbox page (D895) placed directly below Page Inventory in the backend/index.html 'New / Recently Built' box. Added one <a> line matching the existing style, pointing to /frontend/30-Tech/sandbox/archive-review/index.html.

USR369 asked me to search the old-zips archive for pre-existing/more-complete versions of 5 flagged Tech library pages (Tech_Library_UI, housekeeping-library, script-library, navigator, android-library), and to build a browsable sandbox index so he could compare live vs archived without me overwriting anything. Used systems/old-zips-index-api.php (fast FTS5 discovery) then systems/old-zips-search-api.php (to get exact extraction paths) against the 263-zip old-zips archive. Found archived candidates for 4 of 5: HousekeepingLibrary_v1.0.html (47,297B vs live 33,773B, correctly titled, has an extra Android tab + 2 empty placeholder tabs not present live -- best lead), Tech_Library_UI_PREV.html (55,761B but internally titled 'Housekeeping Library v1.0' -- false lead, a mislabeled shared template not real Tech content), ScriptLibrary_Housekeeping_v1.0.html (27,064B, smaller than live 31,260B -- live already more complete), CAI_Navigator_Master_v1.1.html (56,727B, about same size as live 57,532B -- low priority). No archived match found for android-library.html; working theory is it used to be a tab inside the combined Housekeeping library page rather than its own file. Built frontend/30-Tech/sandbox/archive-review/index.html linking directly to both live pages and the archived files in-place (systems/old zips ref/_extracted/... is directly web-viewable, confirmed via HEAD request, so no copying was needed). Page also embeds a full search-log breadcrumb (tool names, exact extraction paths, what was tried, what's not yet tried) so a future session can resume the dig without re-deriving any of this. Also resolved a standing open question: confirmed frontend/30-Tech/apps/Database_PREV/ does not exist live (404) -- the name is real but it's the OLD per-system archival folder convention (ARCHIVE/Database_PREV/) from pre-decade-code CAI versions, not something that should exist on the current live server.

USR369 manually deleted frontend/30-Tech/apps/Inventory/ directory via FreeCommander XE (direct FTP to server277.web-hosting.com), containing davidslaptop-reference.html and davidslaptop-reference_TEST.html. Both were dead stub pages ("content has been moved to a private personal area") left over from when personal device inventory moved to backend/369/user369_space/. Neither file was linked from the Tech[30] hub or any other live page checked. Cleanup performed by USR369 directly on the server, not by Claude.

Follow-up to D883: USR369 said links still weren't drilling down to real pages. Root cause: several OEM/system-component rows pointed at generic vendor root pages (dell.com/support repeated across 5 different Dell components) or had no link at all (Fusion Service, Microsoft Update Health Tools). Used web search (Exa) to find the actual specific documentation/driver page for each: Dell Connected Service Delivery, its SubAgent, Dell Core Services, the SupportAssist OS Recovery Plugin, and SupportAssist PC Analytics each now link to their own distinct official Dell page instead of a shared generic one. Fusion Service was previously listed as 'exact function unconfirmed' -- research confirmed it's the background service for the My Dell/My Alienware support app, updated purpose text and added a source link. Microsoft Update Health Tools (KB4023057) confirmed and linked to the official Microsoft KB article. Epson Software Updater given its own dedicated Epson page instead of the shared printer hub page. Only 1 of 69 software rows now has no link: id 73 (Handy) -- still genuinely unconfirmed what this app is, not guessed.

Fixed backend/369/user369_space/computer/index.html (USR369 personal space, v1.0->v1.1) after USR369 reported the page was disorganized: hardware was rendering as paragraph blobs for 2 of 4 rows because the JS blindly split all hardware notes on ' | ' -- only 1 of 4 rows (HARDWARE SUMMARY) actually had pipe-delimited notes; the other 2 (Speccy report, Task Manager/DxDiag confirmation) were free-text paragraphs with no pipes, so they rendered as single giant list items. Root cause fixed: added isStructured() check -- only pipe-delimited rows render as the clean line-item spec list now; the 2 narrative rows moved to a collapsible Research History panel, rendered as labeled paragraphs (not fake list rows). Also reformatted the MATSHITA BD-MLT UJ272 external drive row into clean pipe-delimited fields so it joins the structured spec list. Second complaint: software items had no link to where each program comes from, only a purpose/description field, per USR369 wanting the old link+explanation format restored. Added a link TEXT column to computer_items table in personal-api.php (idempotent ALTER TABLE, verified existing 73 rows unaffected), added update_computer action, then populated link+cleaned-purpose for 68 of 69 software rows: many already had the URL embedded inline in the purpose text (e.g. '...tool | https://freefilesync.org') which was split out into its own field; OEM/bundled components with no purpose text (Dell services, Epson drivers, Microsoft redistributables, etc) were given a one-line description plus a publisher support link. One row (id 73, Handy, Windows 11 Desktop) deliberately left blank -- purpose was already flagged unconfirmed in handoff-30.md and I do not know what this app is, so I did not guess; will ask USR369 directly. Software cards now render name+version+description+a real clickable source link, grouped by device, matching the link+explanation format from the old library page.

Server[40] shipped a new age/volume-based actionability check on OPEN.php overnight, in addition to the prior keyword-only check. This surfaced backlog going back to 07/15/26 that had built up silently. Resolved in 4 stages: 146 flagged community-inbox items (inbox-api.php action=resolve), 79 more found duplicated in the personal/transfers queue for the same messages (transfers/index.php action=resolve -- K337 dual-queue pattern confirmed again), then after the flagged list cleared, OPEN.php still blocked on a general pending-volume threshold with zero specifically-flagged items remaining -- pulled the full pending list via action=list&status=pending on both endpoints and resolved everything found there too (137 community + 11 transfers). Every single item was read in full before resolving (no partial scans per 08/17 platform directive) -- all were old close reports, status broadcasts, or already-resolved matters from other systems, nothing new or actionable for Tech.

David wants to use Claude Code CLI together with this chat to clean up and re-inventory DavidsLaptops C: drive. Wrote full instructions covering how to launch/use Claude Code CLI, and a clear division of labor: Claude Code handles mechanical scanning (large folders, duplicates, file listings), while Claude (this chat) handles judgment calls and record-keeping (cross-checking against Device Inventory, logging decisions, updating Inventory after cleanup). Logged as QA-W033 on the same Housekeeping Library page used throughout this session. No actual cleanup work has been done yet -- this is a documented, ready-to-start plan for next session.

Ran PowerShell registry export (Get-ItemProperty against 32-bit and 64-bit Uninstall keys), deduplicated 76 raw rows to 60 real entries, bulk-logged into Inventory app. Discovered a second device already had inventory data under an unexpected name (Windows 11 Desktop, not ikre8 as assumed) and a third older device (Computer). Built a new live, database-backed viewer page (frontend/30-Tech/apps/inventory.html) with device tabs, search, and category grouping -- deliberately dynamic rather than static so future additions do not require rebuilding the page. Added descriptions and official website links for 28 significant standalone programs directly into the database, updated the page to auto-linkify URLs into real clickable links. Linked from the Tech hub index, replacing an earlier incorrect link to a raw static file.

Installed Node.js LTS and Claude Code CLI on DavidsLaptop, logged into paid Claude Pro/Max (confirmed free, no separate API billing). Connected Claude Code CLI as Pinegrows AI assistant provider (Mr. Pine Cone). Testing revealed the integration consistently returns garbled internal system text (leaked command tags, [object ArrayBuffer] placeholders) instead of real answers on every request, small or large. Isolation-tested by running claude standalone in Command Prompt outside Pinegrow -- confirmed Claude Code itself works correctly, so the bug is confirmed to live in Pinegrows own BETA integration layer, not in the install/login/config on our end.

Connected WinSCP directly to yttcom.net (FTP+TLS Explicit encryption, port 21098) for real server file access. Installed and configured Pinegrow as a local HTML/CSS editor pointed at a dedicated local mirror folder. Established manual workflow: WinSCP downloads files to edit -> Pinegrow edits locally -> WinSCP uploads changes back to live server. No auto-sync, deliberately manual to avoid accidental live-site damage.

AI Old.zip and v 1.5 AI.zip were failing to sync/copy consistently. Cross-checked failure against two unrelated tools (FreeFileSync and rclone FTP) -- both failed identically while a much larger file in the same batch transferred cleanly, ruling out network/timeout and confirming server-side file corruption. David deleted both files. Diagnostic pattern logged to memory pipeline as K359 for reuse on future similar cases.

David wanted manual, on-demand Google Drive access from FreeCommander without installing Google Drive for Desktop and without a persistent drive letter. Configured rclone remote (gdrive, Google Drive, full access scope, standard shared client_id), started as an on-demand FTP bridge on 127.0.0.1:2121. Full walkthrough saved as QA-W030 in Laboratory; restart command + login saved to new PASSWORDS-30.md for fast reference.

Added 4 build-diary entries (ids 5-8) for Techs pre-existing apps, which had zero entries before this session. Two of the four (Laboratory, Inventory) initially wrote truncated because curl -d interpreted a literal ampersand in the text as a param delimiter; caught via read-back verify and fixed with a proper urllib-encoded POST, then re-verified clean.

David direction — heavy breadcrumbs so next session starts where we left off. Separate from handoff. Documents every decision, build, problem, and solution.

build-diary-03.md as primary continuity document

Old JS codeTemplate functions cannot be stored in SQLite. Replaced with plain text {{KEY}} placeholders. inputs_json stores field definitions. Simple find/replace at generate time.

Script template format — {{VAR}} placeholders

Separate from 30-sys.db following Health pattern (70-sys + 70-app). Tables: scripts/qa_log/shortcuts/commands. One DB for all Tech programs.

30-app.db as separate app database

frontend/30-Tech/ for users looking things up. systems/30-tech/ for build tools. Script builders moved to backend. Rule: build tools never on frontend.

Frontend vs backend split — user-facing vs controller tools

v1.5 → v1.8 migration complete. Server authoritative. config.json active. EXEC_OPEN deployed. Package A.

Tech [03] UP HERE v1.8 — 07/06/26