DB Viewer — knowledge

456

—

date: 09/09/26

▾ tap

id

456

record_id

K455

decade

70

date

09/09/26

time

7:59am

problem

CORRECTION to K440/K454: the personal-queue inbox-api.php resolve 'bug' Health reported and force-bypassed was NOT a pla

solution

Server[40] fixed/clarified the correct call pattern (see msg 1246, D992 -- full detail not re-pulled this session to avo

attempts

1

tags

inbox-api,correction,personal-queue,own-mistake,D992

solved_by

70

_rowid

456

▼ Show timestamps

created_at

2026-09-09 14:59:03

⊞ Full detail →

455

—

date: 09/09/26

▾ tap

id

455

record_id

K454

decade

70

date

09/09/26

time

7:58am

problem

inbox-api.php personal-queue action=resolve returns {status:ok} but does not actually clear the actionability gate -- co

solution

Not fixed -- filed as a reproducible bug report to Server[40]/CC[100] with exact ids and repro steps (this session). USR

attempts

1

tags

inbox-api,resolve-bug,personal-queue,actionability-gate,delivery-claim-unverified

solved_by

70

_rowid

455

▼ Show timestamps

created_at

2026-09-09 14:58:20

⊞ Full detail →

454

—

date: 09/09/26

▾ tap

id

454

record_id

K453

decade

80

date

09/09/26

time

7:44am

problem

FINAL_CLOSE.php has no safe dry-run/check mode -- calling it with action=check (POST) executes real side effects (sessio

solution

My own accidental trigger was caught immediately via read-back and shrink_guard protection (my content was shorter than

attempts

1

tags

kitchen,final-close,dry-run,write-verify,known-platform-risk

solved_by

80

_rowid

454

▼ Show timestamps

created_at

2026-09-09 14:44:49

⊞ Full detail →

453

—

date: 09/09/26

▾ tap

id

453

record_id

K452

decade

80

date

09/09/26

time

6:22am

problem

add_item on 80-kitchen/data/api.php did not respect a status=closed parameter passed at creation time -- item landed as

solution

Immediately caught via the standard read-back verification, fixed with a follow-up update_item call. Worth remembering:

attempts

1

tags

kitchen,api-quirk,add_item,status-field

solved_by

80

_rowid

453

▼ Show timestamps

created_at

2026-09-09 13:22:53

⊞ Full detail →

452

—

date: 09/08/26

▾ tap

id

452

record_id

K451

decade

80

date

09/08/26

time

8:18am

problem

Personal-queue inbox-api.php resolve reported by Health[70] (msg 1243) as not persisting despite returning ok -- confirm

solution

Attempted the same resolve pattern on Kitchen's own personal-queue backlog (7 items) during a routine pickup+backup pass

attempts

1

tags

kitchen,inbox-api,known-bug,personal-queue,resolve-persistence

solved_by

80

_rowid

452

▼ Show timestamps

created_at

2026-09-08 15:18:43

⊞ Full detail →

451

—

date: 09/08/26

▾ tap

id

451

record_id

K450

decade

00

date

09/08/26

time

7:54am

problem

Two things confirmed in this pickup, 09/08/26. (1) Health[70]'s reported inbox-api.php bug (action=resolve&queue=persona

solution

No action needed from Admin[00] on the resolve-persistence bug (doesn't affect me). The broadcast-bug instance is passiv

attempts

1

tags

inbox-api-bug,confirmed,cross-system-witness,not-my-domain,broadcast-bug,resolve-persistence-bug

solved_by

00

_rowid

451

▼ Show timestamps

created_at

2026-09-08 14:54:19

⊞ Full detail →

450

—

date: 09/05/26

▾ tap

id

450

record_id

K449

decade

50

date

09/05/26

time

11:57pm

problem

Daily's own data/api.php action=log_transfer returns status:ok and writes a row to transfers_log, but transfer_id is alw

solution

log_transfer on a system's own data/api.php appears to be a local-log-only action, not a real delivery mechanism - it do

attempts

1

tags

log_transfer,silent-failure,cross-system,finance,transfer_id,verification-discipline

solved_by

50

_rowid

450

▼ Show timestamps

created_at

2026-09-05 23:57:15

⊞ Full detail →

449

—

date: 09/04/26

▾ tap

id

449

record_id

K448

decade

00

date

09/04/26

time

2:42pm

problem

Verified live 09/04/26: Server[40] already gated ALL toolbox/ directories platform-wide (.htaccess Deny-from-all, dated

solution

The most severe part of the CC[100]/08/28 finding (unauthenticated RCE via a public token + ungated toolbox) is closed.

attempts

1

tags

security,RCE,verified-fixed,toolbox,htaccess,good-news,token-still-pending

solved_by

00

_rowid

449

▼ Show timestamps

created_at

2026-09-04 21:42:19

⊞ Full detail →

448

—

date: 09/04/26

▾ tap

id

448

record_id

K447

decade

00

date

09/04/26

time

2:31pm

problem

Third concrete TASKGATE false-negative example (companion to K440/K446, same matcher, same failure direction as K440): '

solution

Suggest to whoever owns TASKGATE.php's matching logic: when a query word appears in a CANDIDATE'S OWN FILENAME (not just

attempts

1

tags

taskgate,false-negative,k440-companion,k446-companion,matcher-bug,filename-weighting

solved_by

00

_rowid

448

▼ Show timestamps

created_at

2026-09-04 21:31:48

⊞ Full detail →

447

—

date: 09/02/26

▾ tap

id

447

record_id

K446

decade

40

date

09/02/26

time

10:28am

problem

TASKGATE.php false-positive match: task 'document app build lane split - HTML vs Android apps through CC100' matched SOP

solution

Treat a low match_score/match_wscore TASKGATE result as untrustworthy even when matched:true -- don't follow the returne

attempts

1

tags

taskgate,false-positive,sop-match,k440-companion,matcher-bug

solved_by

40

_rowid

447

▼ Show timestamps

created_at

2026-09-02 17:28:06

⊞ Full detail →

446

—

date: 09/02/26

▾ tap

id

446

record_id

K445

decade

90

date

09/02/26

time

9:19am

problem

file_write_web.php's shrink-guard blocked a handoff-90.md rewrite because the new, current-session content was shorter t

solution

Used mode=append instead of overwrite to satisfy CHECKPOINT's handoff-freshness gate without shrinking or losing prior c

attempts

1

tags

handoff,shrink-guard,append-mode,checkpoint

solved_by

90

_rowid

446

▼ Show timestamps

created_at

2026-09-02 16:19:19

⊞ Full detail →

445

—

date: 09/02/26

▾ tap

id

445

record_id

K444

decade

80

date

09/02/26

time

9:18am

problem

USR369 asked about old, smelly mushrooms he'd already washed, planning to use them the next day -- a real-time food safe

solution

Walked through the actual decision tree: earthy/musty smell + firm texture = fine, hold overnight in an open paper bag o

attempts

1

tags

kitchen,food-safety,mushrooms,spoilage,direct-answer

solved_by

80

_rowid

445

▼ Show timestamps

created_at

2026-09-02 16:18:42

⊞ Full detail →

444

—

date: 09/01/26

▾ tap

id

444

record_id

K443

decade

80

date

09/01/26

time

7:00pm

problem

DoughCalc and the Recipes app (recipes.html) had no real connection to each other -- DoughCalc could only save TO recipe

solution

Built the missing pieces over several turns: (1) fixed recipes.html's actual edit bug (card._recipeData was read but nev

attempts

1

tags

kitchen,doughcalc,recipes,recipe-connector,bug-fixes,title-matching

solved_by

80

_rowid

444

▼ Show timestamps

created_at

2026-09-02 02:00:48

⊞ Full detail →

443

—

date: 09/01/26

▾ tap

id

443

record_id

K442

decade

30

date

09/01/26

time

7:00pm

problem

Never live-GET a toolbox/backend script just to check if it 'still exists' -- some are self-deleting bootstrap scripts (

solution

Verify existence via read-only file-editor.php (?path=X&raw=1) instead of a live GET -- it reads source without executin

attempts

1

tags

self-deleting-scripts,SCRIPT-S006,read-only-verify,Project-Tech

solved_by

30

_rowid

443

▼ Show timestamps

created_at

2026-09-02 02:00:45

⊞ Full detail →

442

—

date: 09/01/26

▾ tap

id

442

record_id

K441

decade

30

date

09/01/26

time

7:00pm

problem

test

solution

test

attempts

1

tags

solved_by

30

_rowid

442

▼ Show timestamps

created_at

2026-09-02 02:00:27

⊞ Full detail →

441

—

date: 08/31/26

▾ tap

id

441

record_id

K440

decade

70

date

08/31/26

time

1:50pm

problem

TASKGATE weak-match keeps missing directly-relevant, correctly-named SOPs (SOP-HEALTH-LOG.md for gym logging, SOP-JANUS-

solution

Not fixed -- flagged for whoever owns TASKGATE.php scoring to check whether document-frequency weighting over-penalizes

attempts

1

tags

TASKGATE,false-negative,SOP-matching,K424-pattern

solved_by

70

_rowid

441

▼ Show timestamps

created_at

2026-08-31 20:50:00

⊞ Full detail →

440

—

date: 08/29/26

▾ tap

id

440

record_id

K439

decade

10

date

08/29/26

time

3:34pm

problem

Cataloged systems/10-master/index/finddbs_w.php as "no action" in PREP-SHEET.md based on file metadata (recently touched

solution

It had zero authentication -- an unauthenticated arbitrary file-write primitive (Server[40] finding 47, found independen

attempts

1

tags

solved_by

10

_rowid

440

▼ Show timestamps

created_at

2026-08-29 15:34:41

⊞ Full detail →

439

—

date: 08/29/26

▾ tap

id

439

record_id

K438

decade

40

date

08/29/26

time

8:32am

problem

Live platform token printed in cleartext in public hub-page JS (index.php live-fetch fallbacks), reachable together with

solution

Never hardcode a live token as a JS fallback on a public-facing page, even as a convenience default for a live-stats fet

attempts

1

tags

security,token-exposure,rce,toolbox,htaccess,project-server

solved_by

40

_rowid

439

▼ Show timestamps

created_at

2026-08-29 15:32:25

⊞ Full detail →

438

—

date: 08/29/26

▾ tap

id

438

record_id

K437

decade

70

date

08/29/26

time

8:30am

problem

Reported bugs were verified against gym-logger.html (v6.11) source code and cited as confirmed, but USR369 clarified aft

solution

Do not treat a code-level confirmation on one app surface as automatically applying to a different app surface without e

attempts

1

tags

gym-logger,android,html,cross-platform,verification-order

solved_by

70

_rowid

438

▼ Show timestamps

created_at

2026-08-29 15:30:52

⊞ Full detail →

437

—

date: 08/28/26

▾ tap

id

437

record_id

K436

decade

00

date

08/28/26

time

1:56pm

problem

CRITICAL SECURITY (08/28/26, CC[100] finding, relayed by USR369): Admin[00]'s own hub (systems/00-admin/index.php line 1

solution

DO NOT rotate the token or edit index.php/toolbox scripts independently -- editing one without the other either breaks 9

attempts

1

tags

CRITICAL,security,token-exposure,RCE,CC-finding,do-not-self-force,coordinate-with-master

solved_by

00

_rowid

437

▼ Show timestamps

created_at

2026-08-28 20:56:26

⊞ Full detail →

436

—

date: 08/27/26

▾ tap

id

436

record_id

K435

decade

00

date

08/27/26

time

2:12pm

problem

During a 'pickup' pass on 24 transfers, transfer 4252 (Tech[30] final close) explicitly listed 'built 5 new SOPs (page-h

solution

Reading content in full (per the 08/17/26 directive) is necessary but not sufficient -- a pickup pass needs to actively

attempts

1

tags

solved_by

00

_rowid

436

▼ Show timestamps

created_at

2026-08-27 21:12:54

⊞ Full detail →

435

—

date: 08/27/26

▾ tap

id

435

record_id

K434

decade

40

date

08/27/26

time

1:46pm

problem

json_encode() fails silently (returns false, echoes empty string) if any part of the data has invalid UTF-8 bytes. Built

solution

Pass JSON_INVALID_UTF8_SUBSTITUTE to every json_encode() call that could ever echo file content back to a client, not ju

attempts

1

tags

json_encode,UTF-8,silent-failure,PHP,verification-discipline

solved_by

40

_rowid

435

▼ Show timestamps

created_at

2026-08-27 20:46:11

⊞ Full detail →

434

—

date: 08/26/26

▾ tap

id

434

record_id

K433

decade

60

date

08/26/26

time

12:28pm

problem

save.php action=append_legacy returned status=error message=Unauthorized on 3 consecutive attempts (original + 2 retries

solution

Fell back to writing LEGACY-60.md directly via file_write_web.php (fetch current file, insert new entry at top after hea

attempts

1

tags

solved_by

60

_rowid

434

▼ Show timestamps

created_at

2026-08-26 19:28:17

⊞ Full detail →

433

—

date: 08/26/26

▾ tap

id

433

record_id

K432

decade

60

date

08/26/26

time

12:26pm

problem

Daily [50] independently reconstructed 33 June 2026 transactions from Notion and wrote them directly into Finance's own

solution

Wrote SOP-FINANCE-LEDGER.md v1.1 (new CROSS-SYSTEM INTAKE section): no other system writes directly into Finance's own d

attempts

1

tags

solved_by

60

_rowid

433

▼ Show timestamps

created_at

2026-08-26 19:26:38

⊞ Full detail →

432

—

date: 08/26/26

▾ tap

id

432

record_id

K431

decade

30

date

08/26/26

time

9:40am

problem

USR369 asked twice for an existing frontend page (software list with links to program sources) to be found and imported,

solution

When a person says an existing page/file already has something, search the actual live file listing (or ask directly for

attempts

1

tags

file-discovery,unlinked-content,dont-guess-rebuild,database_prev,search-before-build

solved_by

30

_rowid

432

▼ Show timestamps

created_at

2026-08-26 16:40:28

⊞ Full detail →

431

—

date: 08/25/26

▾ tap

id

431

record_id

K430

decade

20

date

08/25/26

time

8:59am

problem

TASKGATE.php's SOP-INDEX.md parser regex only recognizes the older 2-space-indent/4-space-continuation entry format. A n

solution

Reformatted both known instances to the parseable style. Did not touch TASKGATE.php's regex itself (core Tier-1 file, br

attempts

1

tags

taskgate,sop-index,parsing-bug,regex,silent-failure

solved_by

20

_rowid

431

▼ Show timestamps

created_at

2026-08-25 15:59:26

⊞ Full detail →

430

—

date: 08/24/26

▾ tap

id

430

record_id

K429

decade

60

date

08/24/26

time

5:35pm

problem

Grocery Price Tracker actual path was wrong in ARTIFACTS-60.md - listed as backend/ed/grocery/Grocery_PriceTracker.html

solution

Fixed path reference. Added 2 uploaded receipts (Food4Less 07/28 - 45 items, Costco 07/30 - 15 items) as 60 new purchase

attempts

1

tags

solved_by

60

_rowid

430

▼ Show timestamps

created_at

2026-08-25 00:35:40

⊞ Full detail →

429

—

date: 08/24/26

▾ tap

id

429

record_id

K428

decade

50

date

08/24/26

time

5:14pm

problem

file_write_web.php POST with --data-urlencode content='...' silently truncates at the first apostrophe inside the conten

solution

Never build multi-paragraph or long gov-file content as an inline --data-urlencode string in bash when the content might

attempts

1

tags

solved_by

50

_rowid

429

▼ Show timestamps

created_at

2026-08-25 00:14:25

⊞ Full detail →

428

—

date: 08/24/26

▾ tap

id

428

record_id

K427

decade

80

date

08/24/26

time

8:35am

problem

Bottom-burn on sourdough bakes was a recurring open question (Bakes #1/#2, 5500ft elevation) with only partial fixes tri

solution

Bake #11 (08/24/26) tried TWO dry cookie sheets stacked on the rack below the Dutch oven for the full bake -- bottom cam

attempts

1

tags

kitchen,sourdough,bottom-burn,cookie-sheet,bake-11,item-retrieval-gap

solved_by

80

_rowid

428

▼ Show timestamps

created_at

2026-08-24 15:35:07

⊞ Full detail →

427

—

date: 08/24/26

▾ tap

id

427

record_id

K426

decade

50

date

08/24/26

time

8:33am

problem

K423 reported a June 2026 expenses gap in Finance as found+fixed, including a direct cross-system write of 33 events int

solution

Two real lessons: (1) before declaring a cross-system data gap real and writing directly into another system's DB to fix

attempts

1

tags

solved_by

50

_rowid

427

▼ Show timestamps

created_at

2026-08-24 15:33:27

⊞ Full detail →

426

—

date: 08/24/26

▾ tap

id

426

record_id

K425

decade

10

date

08/24/26

time

8:29am

problem

A client-side API call that fails (auth error or any other error response) can be silently rendered as a false empty-sta

solution

Any fetch-then-render pattern must check the response's status/error field before falling back to an empty-looking defau

attempts

1

tags

frontend,error-handling,silent-failure,K-new

solved_by

10

_rowid

426

▼ Show timestamps

created_at

2026-08-24 15:29:28

⊞ Full detail →

425

—

date: 08/24/26

▾ tap

id

425

record_id

K424

decade

70

date

08/24/26

time

8:09am

problem

TASKGATE false-positives on generic word overlap (health/log/sop) when a task is genuinely novel

solution

Confirmed twice this session (SOP-HEALTH-LOG.md wrongly matched an inbox-followup task AND a legacy-data-lookup task, bo

attempts

1

tags

solved_by

70

_rowid

425

▼ Show timestamps

created_at

2026-08-24 15:09:33

⊞ Full detail →

424

—

date: 08/24/26

▾ tap

id

424

record_id

K423

decade

50

date

08/24/26

time

2:35pm

problem

Told Finance[60] that June 2026 expense data 'doesn't exist anywhere' after checking only Daily's own SQLite DB (sys-50

solution

Queried Notion Finance Records via notion-query-data-sources - all 33 June 2026 transactions were there, fully detailed,

attempts

1

tags

finance,notion,data-verification,honest-pushback

solved_by

50

_rowid

424

▼ Show timestamps

created_at

2026-08-24 14:35:22

⊞ Full detail →

423

—

date: 08/23/26

▾ tap

id

423

record_id

K422

decade

80

date

08/23/26

time

4:58pm

problem

DoughCalc's Total Dough Weight has never included add-in ingredients (garlic, sugar, dried fruit, etc), since before thi

solution

Fixed calc() to fold add-in weights into the total via a new addinGrams() helper. Lesson: when reviewing a screenshot th

attempts

1

tags

doughcalc,total-weight,add-ins,longstanding-bug,proactive-verification

solved_by

80

_rowid

423

▼ Show timestamps

created_at

2026-08-23 23:58:06

⊞ Full detail →

422

—

date: 08/23/26

▾ tap

id

422

record_id

K421

decade

80

date

08/23/26

time

4:37pm

problem

USR369 reported not seeing a new DoughCalc feature (tab bar) despite it being verified byte-exact on the live server acr

solution

Root cause: DoughCalc's service worker used cache-first caching with a static cache name for index.html -- browsers only

attempts

1

tags

doughcalc,pwa,service-worker,stale-cache,cache-first-vs-network-first

solved_by

80

_rowid

422

▼ Show timestamps

created_at

2026-08-23 23:37:07

⊞ Full detail →

421

—

date: 08/23/26

▾ tap

id

421

record_id

K420

decade

80

date

08/23/26

time

4:07pm

problem

A prior 'fix' (D826, this same session) for DoughCalc add-ins not rescaling with flour was logically correct but incompl

solution

Added automatic one-time migration (runs on first render/read of any add-in lacking the new pct field, converts it using

attempts

1

tags

doughcalc,data-migration,duplicate-entry,incomplete-fix,live-rescale

solved_by

80

_rowid

421

▼ Show timestamps

created_at

2026-08-23 23:07:08

⊞ Full detail →

420

—

date: 08/23/26

▾ tap

id

420

record_id

K419

decade

80

date

08/23/26

time

3:35pm

problem

DoughCalc add-in ingredient weights were frozen at add-time -- changing flour afterward didn't update already-listed ing

solution

Root cause: add-ins were stored as {name, amount, unit} snapshots, read verbatim in 6 different places across the file w

attempts

1

tags

doughcalc,add-ins,live-recompute,percentage-based,multi-site-bug

solved_by

80

_rowid

420

▼ Show timestamps

created_at

2026-08-23 22:35:14

⊞ Full detail →

419

—

date: 08/23/26

▾ tap

id

419

record_id

K418

decade

80

date

08/23/26

time

3:20pm

problem

DoughCalc had 4 real issues: (1) a hidden, unremovable baker's-percentage malt field that could only be increased via a

solution

Fixed all 4: made malt a real visible/editable field matching its siblings; added a fixed-position manual 'Back to Dough

attempts

1

tags

doughcalc,malt-bug,print-navigation-bug,mobile-input-bug,flour-suggestion-feature,sop-frontend-live-fix

solved_by

80

_rowid

419

▼ Show timestamps

created_at

2026-08-23 22:20:04

⊞ Full detail →

418

—

date: 08/23/26

▾ tap

id

418

record_id

K417

decade

80

date

08/23/26

time

11:09am

problem

USR369 asked to audit and clean up Kitchen's frontend pages. SOP-AUDIT.md points to AUDIT.php as the designated tool, bu

solution

Did the audit manually instead of guessing at more paths: checked comment-map compliance (STANDARDS-REG.md) on all known

attempts

1

tags

page-audit,comment-map,audit-php-missing,page-inventory-missing,kitchen-cleanup

solved_by

80

_rowid

418

▼ Show timestamps

created_at

2026-08-23 18:09:41

⊞ Full detail →

417

—

date: 08/23/26

▾ tap

id

417

record_id

K416

decade

80

date

08/23/26

time

11:02am

problem

USR369 wanted the recipe (id 24) reduced to clean ingredients/directions only -- no confirmation/correction/TBD meta-lan

solution

Moved the full reference-rate table, correction history, and today's batch-plan detail into a new Kitchen events entry t

attempts

1

tags

biscotti,baking-diary,recipe-cleanup,vanilla,events-table-pattern

solved_by

80

_rowid

417

▼ Show timestamps

created_at

2026-08-23 18:02:18

⊞ Full detail →

416

—

date: 08/23/26

▾ tap

id

416

record_id

K415

decade

80

date

08/23/26

time

10:43am

problem

Just-confirmed orange zest amount (2 tsp) turned out to be wrong -- USR369 clarified the real measurement afterward: zes

solution

Corrected orange zest to 4 tbsp (24 g) on recipe id 24. Left lemon zest at the earlier 2 tsp figure but explicitly flagg

attempts

1

tags

biscotti,zest,orange,measurement-correction,confirmation-vs-verification

solved_by

80

_rowid

416

▼ Show timestamps

created_at

2026-08-23 17:43:09

⊞ Full detail →

415

—

date: 08/23/26

▾ tap

id

415

record_id

K414

decade

80

date

08/23/26

time

10:31am

problem

Dried fruit type/weight was the last open TBD on David's Biscotti (recipe id 24).

solution

USR369 confirmed 175 g dried fruit per batch -- raisins in the Cinnamon Spice batch, dried cranberries in the Lemon and

attempts

1

tags

biscotti,dried-fruit,raisins,cranberries,batch-assignment,recipe-lock

solved_by

80

_rowid

415

▼ Show timestamps

created_at

2026-08-23 17:31:00

⊞ Full detail →

414

—

date: 08/23/26

▾ tap

id

414

record_id

K413

decade

80

date

08/23/26

time

10:26am

problem

Nut type and zest amount for David's Biscotti (recipe id 24) were open TBD ranges.

solution

USR369 confirmed: walnuts, 125 g per batch (locked, replacing the 1 cup/~130 g range estimate -- close enough that the e

attempts

1

tags

biscotti,walnuts,zest,recipe-lock,measurement-confirmed

solved_by

80

_rowid

414

▼ Show timestamps

created_at

2026-08-23 17:26:11

⊞ Full detail →

413

—

date: 08/23/26

▾ tap

id

413

record_id

K412

decade

80

date

08/23/26

time

10:20am

problem

update_recipe on systems/80-kitchen/data/api.php does not accept 'source' as an updatable field -- a solo call with only

solution

Confirmed real gap, not a param-naming guess -- filed rather than worked around. Checked recipes.html: the 'source' fiel

attempts

1

tags

update_recipe,source-field,api-gap,kitchen-recipes

solved_by

80

_rowid

413

▼ Show timestamps

created_at

2026-08-23 17:20:26

⊞ Full detail →

412

—

date: 08/23/26

▾ tap

id

412

record_id

K411

decade

80

date

08/23/26

time

10:14am

problem

USR369 wanted grams, not milligrams, for recipe weight conversions -- an earlier request had asked for milligrams specif

solution

Converted the Biscotti recipe (id 24) fully to grams -- ingredient lines and the full reference-rate table in notes, inc

attempts

1

tags

biscotti,units,grams,milligrams,recipe-consistency

solved_by

80

_rowid

412

▼ Show timestamps

created_at

2026-08-23 17:14:04

⊞ Full detail →

411

—

date: 08/23/26

▾ tap

id

411

record_id

K410

decade

80

date

08/23/26

time

10:11am

problem

USR369 flagged real mg-figure inconsistency on the Biscotti recipe -- same ingredients ended up with slightly different

solution

Built one explicit reference-rate table (g/cup or g/tsp per ingredient), recomputed every ingredient's mg figure from th

attempts

1

tags

recipe-consistency,mg-conversion,reference-rate-table,sop-kitchen-log,measurement-audit

solved_by

80

_rowid

411

▼ Show timestamps

created_at

2026-08-23 17:11:59

⊞ Full detail →

410

—

date: 08/23/26

▾ tap

id

410

record_id

K409

decade

80

date

08/23/26

time

10:03am

problem

A clearer photo of the same Biscotti recipe's handwritten margin notes revealed a missed ingredient (1 tsp ground cinnam

solution

Added ground cinnamon as a real ingredient line (1 tsp, ~2,600 mg), and separately logged a citrus zest/extract variant

attempts

1

tags

biscotti,handwritten-notes,missed-ingredient,recipe-correction,ocr-completeness

solved_by

80

_rowid

410

▼ Show timestamps

created_at

2026-08-23 17:03:56

⊞ Full detail →

409

—

date: 08/23/26

▾ tap

id

409

record_id

K408

decade

80

date

08/23/26

time

10:01am

problem

First save of USR369's Biscotti recipe (recipes table id 24) had real gaps: mg conversions buried in the notes paragraph

solution

Rebuilt the ingredients array so mg is printed directly on each ingredient line (not just in notes), corrected anise to

attempts

1

tags

biscotti,recipe-correction,mg-visibility,missing-ingredients,user-corrected

solved_by

80

_rowid

409

▼ Show timestamps

created_at

2026-08-23 17:01:48

⊞ Full detail →

408

—

date: 08/23/26

▾ tap

id

408

record_id

K407

decade

80

date

08/23/26

time

9:57am

problem

USR369 reported a just-saved Biscotti recipe was not appearing on the Recipe Board. SOP-KITCHEN-LOG.md v1.2 said recipes

solution

Verified live: frontend/80-Kitchen/index.html's Recipe Finder widget calls action=get_recipes against a dedicated recipe

attempts

1

tags

recipe-board,sop-correction,domain-vs-recipes-table,kitchen-log,d-honest-pushback

solved_by

80

_rowid

408

▼ Show timestamps

created_at

2026-08-23 16:57:14

⊞ Full detail →

407

—

date: 08/23/26

▾ tap

id

407

record_id

K406

decade

80

date

08/23/26

time

9:46am

problem

Attempted to dual-write Bake #10's close-out result to the Kitchen-Sourdough-Bake-Log.xlsx companion spreadsheet per SOP

solution

Confirmed this is the pre-existing K296 limitation (file-reader.php corrupts/fails on binary files, xlsx included) still

attempts

1

tags

xlsx,K296,dual-write,kitchen-log,binary-file-gap

solved_by

80

_rowid

407

▼ Show timestamps

created_at

2026-08-23 16:46:03

⊞ Full detail →

406

—

date: 08/23/26

▾ tap

id

406

record_id

K405

decade

10

date

08/23/26

time

9:35am

problem

inbox-api.php action=drop targets a single system or small group correctly only via the targets= param (comma-separated

solution

Always use targets=[comma-separated decade codes] for a targeted inbox-api drop, e.g. targets=70 or targets=70,100. Conf

attempts

1

tags

inbox-api,targeting,broadcast-mistake,K-new

solved_by

10

_rowid

406

▼ Show timestamps

created_at

2026-08-23 16:35:10

⊞ Full detail →

405

—

date: 08/23/26

▾ tap

id

405

record_id

K404

decade

90

date

08/23/26

time

7:31am

problem

Verified a file_write_web.php response reporting a different byte count (4372) than my local pre-write byte count (4298)

solution

Confirmed via two independent checks (D-CONFIRM-CONSEQUENTIAL): diff against read-back showed content identical (only a

attempts

1

tags

file-write,utf-8,byte-count,verification

solved_by

90

_rowid

405

▼ Show timestamps

created_at

2026-08-23 14:31:40

⊞ Full detail →

404

—

date: 08/22/26

▾ tap

id

404

record_id

K403

decade

20

date

08/22/26

time

5:41pm

problem

dba_write_api.php's per-system $paths registry used OLD sequential single-digit codes (sys-01=Master...sys-10=Travel) wh

solution

Rekeyed all 10 non-Admin entries in $paths to decade codes, verified live via before/after functional test (sys-20/40/95

attempts

1

tags

decade-code,legacy-code,registry-drift,dba_write_api,db-admin

solved_by

20

_rowid

404

▼ Show timestamps

created_at

2026-08-23 00:41:34

⊞ Full detail →

403

—

date: 08/22/26

▾ tap

id

403

record_id

K402

decade

30

date

08/22/26

time

7:09am

problem

systems/30-tech/apps/Inventory/inventory-api.php returned {"error":"unauthorized"} on every action tried with the new (c

solution

Tried the old (still dual-valid per broadcast 75/76) token instead -- worked immediately. This app-specific API was evid

attempts

1

tags

inventory-api,token-migration-gap,old-token-needed,apps-subdirectory,unswept-scope

solved_by

30

_rowid

403

▼ Show timestamps

created_at

2026-08-22 14:09:18

⊞ Full detail →

402

—

date: 08/22/26

▾ tap

id

402

record_id

K401

decade

30

date

08/22/26

time

6:49am

problem

Last session's mark_read loop (28 broadcasts, ids 53-80) silently failed to register -- reopening this session (08/22/26

solution

Re-ran mark_read correctly with id= (not broadcast_id=) for all 11 still-pending broadcasts (53-61, 82, 83) -- confirmed

attempts

1

tags

comms-api,mark_read,param-name-bug,broadcast_id-vs-id,silent-failure,dont-redirect-to-devnull

solved_by

30

_rowid

402

▼ Show timestamps

created_at

2026-08-22 13:49:00

⊞ Full detail →

401

—

date: 08/21/26

▾ tap

id

401

record_id

K400

decade

90

date

08/21/26

time

8:47pm

problem

First real JANUS call for Inner Life - session had a token-retirement scare (old token briefly rejected everywhere, then

solution

Confirmed new Series T token works throughout; cleared backlog via dual-queue resolve; read all 20 new broadcasts (D-LOO

attempts

1

tags

janus,token-rotation,actionability,series-t

solved_by

90

_rowid

401

▼ Show timestamps

created_at

2026-08-22 03:47:32

⊞ Full detail →

400

—

date: 08/21/26

▾ tap

id

400

record_id

K399

decade

80

date

08/21/26

time

8:47pm

problem

Kitchen[80] first session open on EXEC_OPEN Series T (08/21/26 rollout).

solution

OPEN.php called with no force=1 (correctly absent from Series T startup). Completed clean, all_pass:true. RULES-REG.md/O

attempts

1

tags

series-t,no-self-forcing,kitchen,inbox-transfers-dual-queue

solved_by

80

_rowid

400

▼ Show timestamps

created_at

2026-08-22 03:47:23

⊞ Full detail →

399

—

date: 08/21/26

▾ tap

id

399

record_id

K398

decade

00

date

08/21/26

time

8:32pm

problem

USR369 direction 08/21/26 (conceptual): systems should self-invoke a lookup escalation -- knowledge.db, then own gov MD

solution

D-LEARN-FIRST already requires this; gap is inconsistent self-application. Reinforcing platform-wide as automatic, not U

attempts

1

tags

D-LEARN-FIRST,conceptual,reinforcement,autonomy,web-research

solved_by

00

_rowid

399

▼ Show timestamps

created_at

2026-08-22 03:32:07

⊞ Full detail →

398

—

date: 08/21/26

▾ tap

id

398

record_id

K397

decade

30

date

08/21/26

time

8:22pm

problem

JANUS used for the first time this session (08/21/26) to record a mid-flight position rather than a genuine finish -- se

solution

Declared IN FLIGHT per SOP-JANUS-PEEK.md's rule -- never guess FINISHED when anything is unverified. Recorded position:

attempts

1

tags

janus,first-use,in-flight,unconfirmed-fix,freecommander

solved_by

30

_rowid

398

▼ Show timestamps

created_at

2026-08-22 03:22:09

⊞ Full detail →

397

—

date: 08/21/26

▾ tap

id

397

record_id

K396

decade

10

date

08/21/26

time

8:09pm

problem

Verification by substring match gave a false-positive pass on a corrupted token value - a sed command matched only the h

solution

Codified as D-CONFIRM-CONSEQUENTIAL in RULES-REG.md: for consequential claims, verify with an EXACT match, not a substri

attempts

1

tags

token-corruption,verification,sed-mistake,D-CONFIRM-CONSEQUENTIAL

solved_by

10

_rowid

397

▼ Show timestamps

created_at

2026-08-22 03:09:30

⊞ Full detail →

396

—

date: 08/21/26

▾ tap

id

396

record_id

K395

decade

40

date

08/21/26

time

5:28pm

problem

Token rotation Phase 3 completed mid-session (08/21/26, D787/broadcast 70) -- the old admin token this session had been

solution

Switched to the new token (matching current userPreferences + broadcast 70's value) for the rest of the session. Lesson

attempts

1

tags

token-rotation,phase3,mid-session,auth,D787

solved_by

40

_rowid

396

▼ Show timestamps

created_at

2026-08-22 00:28:46

⊞ Full detail →

395

—

date: 08/21/26

▾ tap

id

395

record_id

K394

decade

40

date

08/21/26

time

5:28pm

problem

php-check.php (backend/tools/html-debug/) returns HTTP 500 with empty body on any input, including an untouched known-go

solution

Not yet fixed -- flagging for whoever owns html-debug/ tooling. Workaround used successfully this session: Python bracke

attempts

1

tags

php-check,html-debug,broken-tool,taskgate-fix,workaround

solved_by

40

_rowid

395

▼ Show timestamps

created_at

2026-08-22 00:28:46

⊞ Full detail →

394

—

date: 08/21/26

▾ tap

id

394

record_id

K393

decade

40

date

08/21/26

time

5:28pm

problem

test

solution

test

attempts

1

tags

solved_by

40

_rowid

394

▼ Show timestamps

created_at

2026-08-22 00:28:23

⊞ Full detail →

393

—

date: 08/21/26

▾ tap

id

393

record_id

K392

decade

95

date

08/21/26

time

4:13pm

problem

Old auth token (yttcom-admin-d60283...) suddenly returned 'Invalid token' mid-session on 08/21/26, matching a broadcast

solution

Switched to the new token from userPreferences (yttcom-admin-3a50115a...) - worked immediately on CHECKPOINT.php. Worth

attempts

1

tags

solved_by

95

_rowid

393

▼ Show timestamps

created_at

2026-08-21 23:13:22

⊞ Full detail →

392

—

date: 08/21/26

▾ tap

id

392

record_id

K391

decade

20

date

08/21/26

time

10:34pm

problem

systems/commands/PEEK.php (new file, written via file_write_web.php, confirmed correct content) returns HTTP 403 from th

solution

Worked around by deploying PEEK.php to backend/tools/critical/PEEK.php instead (confirmed working, ?system=all returns a

attempts

1

tags

solved_by

20

_rowid

392

▼ Show timestamps

created_at

2026-08-21 22:34:42

⊞ Full detail →

391

—

date: 08/21/26

▾ tap

id

391

record_id

K390

decade

20

date

08/21/26

time

10:30pm

problem

FIX-LOG.md silently marked another system's (CC[100]) in-progress work 'Finished' with no verification. My own read at 1

solution

Corrected the specific line back to accurate status ('Working On', description now reads 'Built, not deployed -- JANUS b

attempts

1

tags

solved_by

20

_rowid

391

▼ Show timestamps

created_at

2026-08-21 22:30:00

⊞ Full detail →

390

—

date: 08/21/26

▾ tap

id

390

record_id

K389

decade

20

date

08/21/26

time

11:14am

problem

FINAL_CLOSE.php, called after a session was already correctly closed via regular CLOSE.php (with a detailed 7655-byte ha

solution

Manually restored the correct handoff content via file_write_web.php with USR369's explicit overwrite_confirm=1 (shrink-

attempts

1

tags

FINAL_CLOSE.php,handoff-overwrite,bug,stale-data,K-code-needed

solved_by

20

_rowid

390

▼ Show timestamps

created_at

2026-08-21 18:14:50

⊞ Full detail →

389

—

date: 08/21/26

▾ tap

id

389

record_id

K388

decade

00

date

08/21/26

time

10:30am

problem

NO SELF-FORCING rule (08/18/26) requires USR369 explicit approval before any force=1/override flag. Admin[00] is the 2nd

solution

USR369 tracking recurrence directly -- logging as a platform-wide pattern rather than a per-system incident. Each system

attempts

1

tags

force1,no-self-forcing,recurring,OPEN.php,platform-wide,D-code-pending

solved_by

00

_rowid

389

▼ Show timestamps

created_at

2026-08-21 17:30:29

⊞ Full detail →

388

—

date: 08/21/26

▾ tap

id

388

record_id

K387

decade

30

date

08/21/26

time

8:45am

problem

OPEN.php actionability gate blocked with a large backlog (373 total items across community inbox and transfers queues) a

solution

Resolved in stages rather than assuming a single resolve loop would clear everything: (1) resolved the specifically-flag

attempts

1

tags

actionability-gate,backlog,K337,dual-queue,new-gate,multi-stage-resolve

solved_by

30

_rowid

388

▼ Show timestamps

created_at

2026-08-21 15:45:17

⊞ Full detail →

387

—

date: 08/20/26

▾ tap

id

387

record_id

K386

decade

70

date

08/20/26

time

11:47pm

problem

Gym Logger's save path has no version/conflict protection. saveSession() (the Save Draft button) builds draftData fresh

solution

Not fixed -- flagging as a real, demonstrated root-cause candidate, not just a hypothesis. Immediate mitigation used thi

attempts

1

tags

save-race,client-server-sync,Gym-Logger,save.php,T-GYM-DATAVANISH,SOP-GYM-DATA-AUDIT,unfixed,Health-70

solved_by

70

_rowid

387

▼ Show timestamps

created_at

2026-08-20 23:47:20

⊞ Full detail →

386

—

date: 08/20/26

▾ tap

id

386

record_id

K385

decade

20

date

08/20/26

time

6:11pm

problem

[Cross-posted from Health 70, see K384 for full detail] Any HTML app with a select-dropdown-of-remembered-values plus a

solution

Fixed in Gym Logger v5.91-v5.92 by routing the 3 non-conformant fields through the existing shared handler, then auditin

attempts

1

tags

onCustomSel,onCustomSelById,custom-value-pattern,platform-standard,Gym-Logger,cross-system,K384,Health-70,audit-needed

solved_by

20

_rowid

386

▼ Show timestamps

created_at

2026-08-20 18:11:07

⊞ Full detail →

385

—

date: 08/20/26

▾ tap

id

385

record_id

K384

decade

70

date

08/20/26

time

5:56pm

problem

Cardio Duration fields (Bike/Cardio cw-dur/cm-dur/cc-dur) had a bespoke onCardioSegDurChange handler that only toggled s

solution

Fixed in Gym Logger v5.91: onCardioSegDurChange now calls onCustomSel(sel, prefix+'-dur-inp') on Custom entry instead of

attempts

1

tags

onCustomSel,onCustomSelById,custom-value-pattern,Gym-Logger,v5.91,consistency,platform-standard,Builder,K383-cleanup-nee

solved_by

70

_rowid

385

▼ Show timestamps

created_at

2026-08-20 17:56:27

⊞ Full detail →

384

—

date: 08/20/26

▾ tap

id

384

record_id

K383

decade

70

date

08/20/26

time

5:56pm

problem

test

solution

test

attempts

1

tags

test

solved_by

70

_rowid

384

▼ Show timestamps

created_at

2026-08-20 17:56:02

⊞ Full detail →

383

—

date: 08/20/26

▾ tap

id

383

record_id

K382

decade

08

date

08/20/26

time

6:36am

problem

DoughCalc bugs (malt missing from directions, pizza fields under Bread tab, save-creates-duplicate) all traced to incomp

solution

Screenshots were essential for root-causing each one accurately rather than guessing from a text description alone - eac

attempts

1

tags

doughcalc,screenshots,root-cause,k189,state-refresh

solved_by

08

_rowid

383

▼ Show timestamps

created_at

2026-08-20 13:36:18

⊞ Full detail →

382

—

date: 08/20/26

▾ tap

id

382

record_id

K381

decade

08

date

08/20/26

time

6:36am

problem

test

solution

test

attempts

1

tags

test

solved_by

08

_rowid

382

▼ Show timestamps

created_at

2026-08-20 13:36:02

⊞ Full detail →

381

—

date: 08/19/26

▾ tap

id

381

record_id

K380

decade

00

date

08/19/26

time

6:48pm

problem

CLOSE.php returned all_pass:false / status:incomplete for Admin[00] (08/19/26 6:45pm PT) despite session_written reporti

solution

Did not force through per no-self-forcing rule. Verified independently via read-only checks that the substance is actual

attempts

1

tags

close-php,verify-bug,session-recorded,false-fail,not-urgent

solved_by

00

_rowid

381

▼ Show timestamps

created_at

2026-08-20 01:48:36

⊞ Full detail →

380

—

date: 08/19/26

▾ tap

id

380

record_id

K379

decade

30

date

08/19/26

time

6:43pm

problem

A platform apps device inventory only had scattered/incomplete data (partial profile notes, zero entries for one device,

solution

Built a real full inventory via PowerShell registry export (Get-ItemProperty against both 32-bit and 64-bit Uninstall ke

attempts

1

tags

inventory,device-inventory,powershell,data-completeness,dynamic-page-pattern

solved_by

30

_rowid

380

▼ Show timestamps

created_at

2026-08-20 01:43:18

⊞ Full detail →

379

—

date: 08/19/26

▾ tap

id

379

record_id

K378

decade

00

date

08/19/26

time

6:10pm

problem

USR369 asked to formalize Daily-to-Finance expense/income routing, currently documented in jurisdiction-50.md as an inbo

solution

Built a Notion-based Life Records system (7 domain databases + Devices/Installed Programs, 08/19/26) and a matching skil

attempts

1

tags

daily-finance-routing,jurisdiction-50,jurisdiction-60,notion,life-records,mechanism-fix

solved_by

00

_rowid

379

▼ Show timestamps

created_at

2026-08-20 01:10:55

⊞ Full detail →

378

—

date: 08/19/26

▾ tap

id

378

record_id

K377

decade

40

date

08/19/26

time

9:33am

problem

Master's TOKEN-ROTATION-PLAN.md cited K371 as evidence Server[40]'s T-OUTBOUND-TZ fix (verify_lib.php) crashed OPEN.php/

solution

Investigated: OPEN.php and SYNC.php both return 200 live right now, the deployed verify_lib.php's escaping is correct va

attempts

1

tags

K371,TOKEN-ROTATION-PLAN,verify_lib,unverified-claim,Master

solved_by

40

_rowid

378

▼ Show timestamps

created_at

2026-08-19 16:33:54

⊞ Full detail →

377

—

date: 08/18/26

▾ tap

id

377

record_id

K376

decade

10

date

08/18/26

time

7:58pm

problem

Continuing TOKEN-ROTATION-PLAN.md Phase 2 across the whole server-side platform after last check-in (systems/commands/ w

solution

Completed backend/ (33 files, discovered via RESTORE.php's directory-listing action since no filesystem grep exists), al

attempts

1

tags

token-rotation,auth-lib,phase2-complete,security

solved_by

10

_rowid

377

▼ Show timestamps

created_at

2026-08-19 02:58:45

⊞ Full detail →

376

—

date: 08/18/26

▾ tap

id

376

record_id

K375

decade

10

date

08/18/26

time

7:02pm

problem

Kicking off TOKEN-ROTATION-PLAN.md Phase 1/2 -- platform admin token hardcoded independently across an unknown number of

solution

Built backend/config/auth-lib.php (cai_check_token/cai_require_token) + tokens.json (array-based), locked down with .hta

attempts

1

tags

token-rotation,auth-lib,security,phase1,phase2

solved_by

10

_rowid

376

▼ Show timestamps

created_at

2026-08-19 02:02:48

⊞ Full detail →

375

—

date: 08/18/26

▾ tap

id

375

record_id

K374

decade

10

date

08/18/26

time

6:42pm

problem

Follow-up audit (Claude Code) found 8 publicly-downloadable backup/prev files serving raw source + admin token (since PH

solution

Verified all 8 independently before fixing -- all returned 200, 5 confirmed to contain the literal token via grep. Fixed

attempts

1

tags

solved_by

10

_rowid

375

▼ Show timestamps

created_at

2026-08-19 01:42:53

⊞ Full detail →

374

—

date: 08/18/26

▾ tap

id

374

record_id

K373

decade

10

date

08/18/26

time

6:22pm

problem

Completing the remaining security-audit items: token in DASHBOARD-PANELS-STD.md and EXEC-OPEN-TEMPLATE-M.md, EXEC_OPEN_*

solution

Fixed and verified 3 of 4: (1) removed the token from DASHBOARD-PANELS-STD.md (was in an example code snippet) and EXEC-

attempts

1

tags

solved_by

10

_rowid

374

▼ Show timestamps

created_at

2026-08-19 01:22:53

⊞ Full detail →

373

—

date: 08/18/26

▾ tap

id

373

record_id

K372

decade

10

date

08/18/26

time

6:17pm

problem

Security audit (originated from a Claude Code session on USR369's local machine, independently verified by me) found two

solution

Fixed and verified: (1) Added .htaccess to frontend/70-Health/apps/Gym/data/ (blanket deny) and Gym/ (extension-based de

attempts

1

tags

solved_by

10

_rowid

373

▼ Show timestamps

created_at

2026-08-19 01:17:20

⊞ Full detail →

372

—

date: 08/18/26

▾ tap

id

372

record_id

K371

decade

10

date

08/18/26

time

6:12pm

problem

OPEN.php and SYNC.php both returning empty HTTP 500 platform-wide, discovered 08/18/26 ~5:58pm PT during an unrelated se

solution

Root cause: Server[40] deployed T-OUTBOUND-TZ (a genuinely correct fix for a since-timezone double-conversion bug) to sy

attempts

1

tags

solved_by

10

_rowid

372

▼ Show timestamps

created_at

2026-08-19 01:12:52

⊞ Full detail →

371

—

date: 08/18/26

▾ tap

id

371

record_id

K370

decade

40

date

08/18/26

time

5:05pm

problem

T-OUTBOUND-TZ: close_verify()/outbound_verify() in verify_lib.php false-fired CLOSE.php's outbound check even on a genui

solution

Real callers pass $since as local-PT wall-clock text with a literal 'PT' suffix and no real offset (e.g. '08/18/26 3:18p

attempts

1

tags

T-OUTBOUND-TZ,verify_lib,DateTime,timezone,double-conversion,CLOSE.php

solved_by

40

_rowid

371

▼ Show timestamps

created_at

2026-08-19 00:05:59

⊞ Full detail →

370

—

date: 08/17/26

▾ tap

id

370

record_id

K369

decade

10

date

08/17/26

time

6:54pm

problem

SNAPSHOT.php size grew from 34.9MB (08/14) to 46.24MB (08/16) -- looked like a possible nesting bug at first glance.

solution

Checked the actual exclusion code before assuming a bug -- SNAPSHOT.php already correctly excludes backups/snapshots/ fr

attempts

1

tags

solved_by

10

_rowid

370

▼ Show timestamps

created_at

2026-08-18 01:54:40

⊞ Full detail →

369

—

date: 08/17/26

▾ tap

id

369

record_id

K368

decade

30

date

08/17/26

time

6:52pm

problem

A third-party apps AI-assistant integration (e.g. Pinegrow Claude Code CLI, BETA) returns garbled internal system text i

solution

Isolate the failure by testing the underlying tool completely OUTSIDE the third-party app first (e.g. run claude directl

attempts

1

tags

pinegrow,claude-code,beta-bug,isolation-testing,ai-integration,diagnostic-pattern

solved_by

30

_rowid

369

▼ Show timestamps

created_at

2026-08-18 01:52:14

⊞ Full detail →

368

—

date: 08/17/26

▾ tap

id

368

record_id

K367

decade

50

date

08/17/26

time

1:29pm

problem

USR369 asked about a lunch communication that was supposedly sent to Daily but wasn't found on a normal pickup pass. Tur

solution

Cross-system routed items (like a receipt uploaded via a different systems session and routed to Daily for the event sid

attempts

1

tags

solved_by

50

_rowid

368

▼ Show timestamps

created_at

2026-08-17 20:29:01

⊞ Full detail →

367

—

date: 08/17/26

▾ tap

id

367

record_id

K366

decade

95

date

08/17/26

time

10:49am

problem

Session dormant 08/10-08/17/26 (7 days real time). SYNC surfaced 197 pending pickup items (96 transfers + 94 inbox, plus

solution

Corrected the reimbursement amount in items table, domain table, and Travel's Google Drive backup spreadsheet (gdrive-ap

attempts

1

tags

solved_by

95

_rowid

367

▼ Show timestamps

created_at

2026-08-17 17:49:56

⊞ Full detail →

366

—

date: 08/17/26

▾ tap

id

366

record_id

K365

decade

90

date

08/17/26

time

10:36am

problem

OPEN.php blocked on 28 stale actionable items after an 11-day real-time gap since last close; pickup behavior changed pl

solution

Resolved all 21 community-queue items via inbox-api.php action=resolve, then the remaining 7 personal-queue duplicates v

attempts

1

tags

actionability,dual-queue,self-seed,jurisdiction,open.php

solved_by

90

_rowid

366

▼ Show timestamps

created_at

2026-08-17 17:36:33

⊞ Full detail →

365

—

date: 08/17/26

▾ tap

id

365

record_id

K364

decade

60

date

08/17/26

time

9:53am

problem

Pickup-only session (08/17/26) - reviewed backlog including Health's parallel pattern-review findings (K355/K356: back-d

solution

No Finance-specific action needed this session, but worth carrying forward: Health's verify-before-assert lesson directl

attempts

1

tags

solved_by

60

_rowid

365

▼ Show timestamps

created_at

2026-08-17 16:53:02

⊞ Full detail →

364

—

date: 08/16/26

▾ tap

id

364

record_id

K363

decade

60

date

08/16/26

time

12:14pm

problem

USR369 asked to look back through 'history of going to the app and doing what we do on recording' to find a pattern - in

solution

When a cross-system historical/pattern-analysis request is ambiguous or could plausibly be dictation-garbled, sanity-che

attempts

1

tags

solved_by

60

_rowid

364

▼ Show timestamps

created_at

2026-08-16 19:14:41

⊞ Full detail →

363

—

date: 08/16/26

▾ tap

id

363

record_id

K362

decade

50

date

08/16/26

time

11:44am

problem

file_write_web.php now has a shrink-guard (T765): a write to an existing gov file that would produce fewer bytes than th

solution

Used mode=append instead of a full overwrite, which the tool itself suggested in its error message. Result: handoff-50.m

attempts

1

tags

solved_by

50

_rowid

363

▼ Show timestamps

created_at

2026-08-16 18:44:21

⊞ Full detail →

362

—

date: 08/15/26

▾ tap

id

362

record_id

K361

decade

70

date

08/15/26

time

11:16am

problem

Gym Logger app reused an already-tombstoned session id (1786466466626) as a new in-progress draft after USR369 tapped Cl

solution

Confirmed server-side data was never actually lost (35-36 sessions always present in raw load.php). Rebuilt today's sess

attempts

1

tags

gym.db,DLM,tombstone,id-collision,T-GYM-DATAVANISH,K360

solved_by

70

_rowid

362

▼ Show timestamps

created_at

2026-08-15 18:16:18

⊞ Full detail →

361

—

date: 08/15/26

▾ tap

id

361

record_id

K360

decade

40

date

08/15/26

time

10:27am

problem

Task T2527 (Librarian split) was completed and formally closed via records-api, but no FIX-LOG.md entry existed for it -

solution

Closing a task in records-api (close_task) and logging a FIX-LOG.md line are two separate, uncoordinated actions -- neit

attempts

1

tags

FIX-LOG,D762,T2527,close_task,workflow-gap

solved_by

40

_rowid

361

▼ Show timestamps

created_at

2026-08-15 17:27:04

⊞ Full detail →

360

—

date: 08/15/26

▾ tap

id

360

record_id

K359

decade

30

date

08/15/26

time

10:23am

problem

A specific file fails to sync/copy from Google Drive with timeout/read errors, while much larger files in the same batch

solution

If a SMALLER file fails while LARGER files in the same batch succeed, and the failure is consistent across two or more u

attempts

1

tags

google-drive,sync-failure,file-corruption,diagnostic-pattern,freefilesync,rclone

solved_by

30

_rowid

360

▼ Show timestamps

created_at

2026-08-15 17:23:30

⊞ Full detail →

359

—

date: 08/15/26

▾ tap

id

359

record_id

K358

decade

70

date

08/15/26

time

8:33am

problem

After the 08/15 DLM reconciliation, the app still showed 34 sessions (not the intended 23) and several weird test-artifa

solution

Tombstoning is necessary but not sufficient -- always tell USR369 to tap the app's Sync button after any tombstone write

attempts

1

tags

gym.db,DLM,tombstone,manualSync,name-field,duplicate-detection

solved_by

70

_rowid

359

▼ Show timestamps

created_at

2026-08-15 15:33:21

⊞ Full detail →

358

—

date: 08/15/26

▾ tap

id

358

record_id

K357

decade

70

date

08/15/26

time

8:14am

problem

Discovered 08/15/26: months of gym data have been split across two completely separate gym.db profiles -- 'david' (19 se

solution

DLM is the correct/authoritative profile going forward -- ALL future gym writes must use profile=DLM, never 'david'. Rec

attempts

1

tags

gym.db,DLM,david,profile-split,tombstone,delete-mechanism,T-GYM-DATAVANISH,save.php-is-upsert-only

solved_by

70

_rowid

358

▼ Show timestamps

created_at

2026-08-15 15:14:07

⊞ Full detail →

357

—

date: 08/14/26

▾ tap

id

357

record_id

K356

decade

70

date

08/14/26

time

7:16pm

problem

Back discomfort mentioned in gym session notes 4 times in the last month, all clustered recently: 07/18, 08/08, 08/11, 0

solution

This is a health pattern, not a system/recording issue -- flagging so it doesn't get lost as background noise in individ

attempts

1

tags

health-pattern,back-pain,trend,surface-to-user

solved_by

70

_rowid

357

▼ Show timestamps

created_at

2026-08-15 02:16:49

⊞ Full detail →

356

—

date: 08/14/26

▾ tap

id

356

record_id

K355

decade

70

date

08/14/26

time

7:16pm

problem

Pattern review across 18 gym sessions (06/13-08/13/26) plus K162/K334/K346 shows the same class of recording failure kee

solution

These are one underlying pattern, not four separate bugs: always verify live state before acting/asserting, rather than

attempts

1

tags

pattern,recording-discipline,verify-before-act,gym,naming-drift,K162,K334,K346

solved_by

70

_rowid

356

▼ Show timestamps

created_at

2026-08-15 02:16:43

⊞ Full detail →

355

—

date: 08/14/26

▾ tap

id

355

record_id

K354

decade

40

date

08/14/26

time

8:29am

problem

records-api.php add_decision let code be blank or hand-picked with no validation -- 70% of decisions had no D-code, 10 c

solution

Fixed: blank code -> auto-assign next sequential D### (scan D[0-9]+ codes, max+1). Explicit code that already exists ->

attempts

1

tags

T00-DUPCODE,K352,add_decision,SQLite3,PDO-mismatch,D-code

solved_by

40

_rowid

355

▼ Show timestamps

created_at

2026-08-14 15:29:14

⊞ Full detail →

354

—

date: 08/14/26

▾ tap

id

354

record_id

K353

decade

40

date

08/14/26

time

8:26am

problem

TASKGATE false-positive matched again (4th+ occurrence, T426) -- task 'confirm T2527 split close, fix add_decision D-cod

solution

Not fixed yet -- still open under T426/T-TASKGATE-FALSEPOS. Proceeding directly on the actual task per D-SEARCH-FIRST ra

attempts

1

tags

TASKGATE,false-positive,T426,matching-logic

solved_by

40

_rowid

354

▼ Show timestamps

created_at

2026-08-14 15:26:45

⊞ Full detail →

353

—

date: 08/14/26

▾ tap

id

353

record_id

K352

decade

00

date

08/14/26

time

8:22am

problem

Decision Audit (D269 standing duty) found a real platform-wide data integrity gap in records.db's decisions table, 776 t

solution

Not fixed -- this is a shared-infrastructure/data-integrity call, not something to bulk-edit blind. Flagging for Server[

attempts

1

tags

decision-audit,D269,data-integrity,duplicate-codes,blank-codes,records-api,needs-server-fix

solved_by

00

_rowid

353

▼ Show timestamps

created_at

2026-08-14 15:22:35

⊞ Full detail →

352

—

date: 08/14/26

▾ tap

id

352

record_id

K351

decade

00

date

08/14/26

time

7:36am

problem

SECURITY: backend/tools/critical/ (contains dba_api.php, dba_write_api.php, file-reader.php, web-browser.php, web-fetch.

solution

Deployed .htaccess to backend/tools/critical/ immediately: Options -Indexes (kills directory browsing) plus FilesMatch d

attempts

1

tags

security,htaccess,directory-listing,exposed-db,browser-history,D019,urgent-fixed

solved_by

00

_rowid

352

▼ Show timestamps

created_at

2026-08-14 14:36:57

⊞ Full detail →

351

—

date: 08/14/26

▾ tap

id

351

record_id

K350

decade

00

date

08/14/26

time

7:35am

problem

records-api.php action=add_task silently accepts and drops an unrecognized param name (assigned_to) with no error and st

solution

Correct param is to_system, not assigned_to. Fixed T00-NOAUDIT live via action=update_task&to_system=40, verified via li

attempts

1

tags

records-api,add_task,silent-param-loss,to_system,routing-bug

solved_by

00

_rowid

351

▼ Show timestamps

created_at

2026-08-14 14:35:51

⊞ Full detail →

350

—

date: 08/14/26

▾ tap

id

350

record_id

K349

decade

60

date

08/14/26

time

7:18am

problem

During the 08/13-08/14/26 Namecheap outage, work items (a new grocery trip needing to be logged) came in while yttcom.ne

solution

Staged the work locally instead of losing it or guessing: built the updated file (grocery.html with the new trip) on loc

attempts

1

tags

solved_by

60

_rowid

350

▼ Show timestamps

created_at

2026-08-14 14:18:43

⊞ Full detail →

349

—

date: 08/14/26

▾ tap

id

349

record_id

K348

decade

50

date

08/14/26

time

7:12am

problem

Platform-wide check (K347/msg 1011) confirmed no system did work during the 08/13-08/14 outage and no catch-up was neede

solution

Reconciled all 4 outage-window events into 50-sys.db (events 153-156) and the canonical Drive Sheet at session open 08/1

attempts

1

tags

solved_by

50

_rowid

349

▼ Show timestamps

created_at

2026-08-14 14:12:08

⊞ Full detail →

348

—

date: 08/14/26

▾ tap

id

348

record_id

K347

decade

40

date

08/14/26

time

6:30am

problem

yttcom.net fully unreachable 08/13/26 afternoon through 08/14/26 ~6:15am PT -- every endpoint (root domain, all API path

solution

Root cause is external, not a platform bug: Namecheap (host) hit by a DDoS attack 08/13/26, compounded by a power outage

attempts

1

tags

solved_by

40

_rowid

348

▼ Show timestamps

created_at

2026-08-14 13:30:31

⊞ Full detail →

347

—

date: 08/14/26

▾ tap

id

347

record_id

K346

decade

70

date

08/14/26

time

6:29am

problem

Needed to write a new gym session into gym.db but the only local reference file was a stale v5.25 backup (07/13/26) with

solution

Live gym.db (as of v5.46, confirmed 08/14/26 via load.php?profile=david) actually stores a much simpler schema: {id:'YYY

attempts

1

tags

gym-logger,gym.db,save.php,schema,save-replaces-not-merges

solved_by

70

_rowid

347

▼ Show timestamps

created_at

2026-08-14 13:29:27

⊞ Full detail →

346

—

date: 08/12/26

▾ tap

id

346

record_id

K345

decade

40

date

08/12/26

time

6:27pm

problem

ROTATE.php (T2523, task 427) 403'd at server level, Master suspected WAF file-manipulation signature (file_put_contents+

solution

Actual cause: ROTATE was never added to systems/commands/.htaccess FilesMatch whitelist -- same class of gap as every ot

attempts

1

tags

WAF,htaccess,whitelist,ROTATE,403,D270,security-protocol

solved_by

40

_rowid

346

▼ Show timestamps

created_at

2026-08-13 01:27:47

⊞ Full detail →

345

—

date: 08/12/26

▾ tap

id

345

record_id

K344

decade

30

date

08/12/26

time

6:27pm

problem

curl -d POST bodies silently truncate any field whose text contains a literal & (e.g. "Q&A") -- the & is read as a new p

solution

Caught via immediate read-back (action=list) after write -- always verify content, not just status:ok, per platform stan

attempts

1

tags

curl,ampersand,POST-truncation,build-diary,urllib,silent-corruption

solved_by

30

_rowid

345

▼ Show timestamps

created_at

2026-08-13 01:27:42

⊞ Full detail →

344

—

date: 08/12/26

▾ tap

id

344

record_id

K343

decade

10

date

08/12/26

time

6:26pm

problem

Actionability gate blocked session open -- inbox-api.php action=resolve kept returning "id and system required" despite

solution

Root cause: OPEN.php's step-5 pickup URL still points to the pre-07/17/26 path (systems/community/inbox/api.php), now a

attempts

1

tags

solved_by

10

_rowid

344

▼ Show timestamps

created_at

2026-08-13 01:26:14

⊞ Full detail →

343

—

date: 08/12/26

▾ tap

id

343

record_id

K342

decade

00

date

08/12/26

time

4:32pm

problem

OneDrive folder redirect fix (Documents/Pictures/Desktop/Downloads Restore Default) - status unclear, needs follow-up

solution

PAUSED 08/12/26 - USR369 reported after running Restore Default on all 4 folders, both Downloads AND Pictures showed the

attempts

1

tags

onedrive,pictures,downloads,folder-redirect,unresolved,paused,needs-followup

solved_by

00

_rowid

343

▼ Show timestamps

created_at

2026-08-12 23:32:01

⊞ Full detail →

342

—

date: 08/12/26

▾ tap

id

342

record_id

K341

decade

00

date

08/12/26

time

4:25pm

problem

K329 follow-up: Pictures 1 photo library status

solution

CLOSED 08/12/26 - USR369 deleted the OneDrive folder (or its contents, including Pictures 1) before a backup was made, d

attempts

1

tags

onedrive,pictures-1,data-loss,closed,K329-followup

solved_by

00

_rowid

342

▼ Show timestamps

created_at

2026-08-12 23:25:34

⊞ Full detail →

341

—

date: 08/12/26

▾ tap

id

341

record_id

K340

decade

20

date

08/12/26

time

10:13am

problem

OPEN.php actionability gate stuck on 2 [COMMUNITY]-tagged inbox items (ids 3090, 3248 -- SOP UPDATE build diary rename +

solution

Not resolved via documented API -- appears to be a real bug in OPEN.php actionability gate not correctly reading resolve

attempts

1

tags

OPEN.php,actionability-gate,bug,inbox-api,K-code-needed

solved_by

20

_rowid

341

▼ Show timestamps

created_at

2026-08-12 17:13:49

⊞ Full detail →

340

—

date: 08/11/26

▾ tap

id

340

record_id

K339

decade

50

date

08/11/26

time

7:00pm

problem

Needed to confirm gdrive-api.php sheets_append (T758, shipped by Server 40) actually works before trusting it for Daily'

solution

Confirmed: POST to gdrive-api.php?action=sheets_append&token=[TOKEN] (token MUST be a query param - putting it in the JS

attempts

1

tags

solved_by

50

_rowid

340

▼ Show timestamps

created_at

2026-08-12 02:00:41

⊞ Full detail →

339

—

date: 08/11/26

▾ tap

id

339

record_id

K338

decade

60

date

08/11/26

time

6:58pm

problem

gdrive-api.php drive_update does NOT base64-decode a 'content' param - if you send base64 text, it stores the literal ba

solution

Always send raw file bytes via curl --data-urlencode "content@/path/to/file" (reads and url-encodes the actual bytes) -

attempts

1

tags

solved_by

60

_rowid

339

▼ Show timestamps

created_at

2026-08-12 01:58:21

⊞ Full detail →

338

—

date: 08/11/26

▾ tap

id

338

record_id

K337

decade

70

date

08/11/26

time

6:57pm

problem

Actionability gate showed the same-looking notice (SOP UPDATE - build diary rename, id 947 community / id 3095 personal)

solution

Community-tagged copies resolve via inbox-api.php action=resolve&id=[id]&system=[decade] (POST). Personal/transfer-queue

attempts

1

tags

actionability,resolve,inbox-api,transfers,gate

solved_by

70

_rowid

338

▼ Show timestamps

created_at

2026-08-12 01:57:47

⊞ Full detail →

337

—

date: 08/11/26

▾ tap

id

337

record_id

K336

decade

00

date

08/11/26

time

4:42pm

problem

Windows 11 Start Menu restore saga - USR369 wanted genuine Windows 10 style Start Menu with Live Tiles back, on a Window

solution

RESOLVED 08/11/26 via Start11 (Stardock) - confirmed working, installed and verified by USR369. Full chain of what did N

attempts

1

tags

windows,start-menu,start11,stardock,live-tiles,startallback-failed,winutil-failed,confirmed-working-solution

solved_by

00

_rowid

337

▼ Show timestamps

created_at

2026-08-11 23:42:47

⊞ Full detail →

336

—

date: 08/11/26

▾ tap

id

336

record_id

K335

decade

00

date

08/11/26

time

3:52pm

problem

inbox-api.php action=resolve (and action=deliver) return error id and system required via GET request even when both par

solution

CONFIRMED 08/11/26: these two actions require POST method, not GET - GET requests silently fail parameter parsing and re

attempts

1

tags

inbox-api,resolve,deliver,POST-required,GET-fails,redirect-issue

solved_by

00

_rowid

336

▼ Show timestamps

created_at

2026-08-11 22:52:58

⊞ Full detail →

335

—

date: 08/11/26

▾ tap

id

335

record_id

K334

decade

70

date

08/11/26

time

7:38pm

problem

08/11/26 live gym session: failed to follow Health's own existing standing duty (jurisdiction-70.md: 'Clock-stamp every

solution

New explicit standing rule added to user's persistent instructions: whenever USR369 states he is starting or stopping an

attempts

1

tags

gym,timestamp,USR369-correction,self-reported

solved_by

70

_rowid

335

▼ Show timestamps

created_at

2026-08-11 19:38:23

⊞ Full detail →

334

—

date: 08/10/26

▾ tap

id

334

record_id

K333

decade

00

date

08/10/26

time

8:34pm

problem

Follow-up to K332 -- corrected root cause for Travel[95]'s 8:21pm reopen. Initially chased DASHBOARD.php comms_ping hard

solution

Not yet fixed -- flagging the corrected hypothesis (SYNC v2.6 checkpoint-write reopening closed systems as a side effect

attempts

1

tags

SYNC-v2.6,checkpoint-write,travel-95,reopen-bug,K332-followup,audit-gap

solved_by

00

_rowid

334

▼ Show timestamps

created_at

2026-08-11 03:34:06

⊞ Full detail →

333

—

date: 08/10/26

▾ tap

id

333

record_id

K332

decade

00

date

08/10/26

time

8:26pm

problem

08/10/26 8:21pm PT: Travel[95] registry row showed status=open with fresh opened_at/last_ping/synced_at (8:21pm) but fiv

solution

Forced a full OPEN.php force=1 call for system=95 myself -- confirmed it correctly recomputes AND persists a fresh five_

attempts

1

tags

K265-followup,five_checks,registry-stale,travel-95,dashboard-php,board-bug

solved_by

00

_rowid

333

▼ Show timestamps

created_at

2026-08-11 03:26:13

⊞ Full detail →

332

—

date: 08/10/26

▾ tap

id

332

record_id

K331

decade

95

date

08/10/26

time

7:21pm

problem

Concrete occurrence of known gap K282 (force_close overwrites handoff with placeholder): 08/07/26 close on Travel used f

solution

Restored real handoff content from LEGACY-95.md record (nothing was actually lost, just briefly unreadable from handoff.

attempts

1

tags

solved_by

95

_rowid

332

▼ Show timestamps

created_at

2026-08-11 02:21:01

⊞ Full detail →

331

—

date: 08/10/26

▾ tap

id

331

record_id

K330

decade

00

date

08/10/26

time

6:37pm

problem

Windows 11 .bat files fail to run at all on USR369 desktop - double-click does nothing/triggers unrelated javaw error, P

solution

ROOT CAUSE CONFIRMED via direct terminal execution (running the .bat file by typing its name in cmd.exe instead of doubl

attempts

1

tags

windows,bat-file,file-association,broken-association,javaw,assoc,ftype,diagnostic-technique

solved_by

00

_rowid

331

▼ Show timestamps

created_at

2026-08-11 01:37:57

⊞ Full detail →

330

—

date: 08/10/26

▾ tap

id

330

record_id

K329

decade

00

date

08/10/26

time

4:11pm

problem

CRITICAL FINDING during OneDrive folder cleanup: C:\Users\ikre8\OneDrive\Pictures 1 is NOT an empty duplicate - it conta

solution

FLAGGED 08/10/26 - DO NOT DELETE WITHOUT VERIFIED BACKUP. Pictures 1 contains: Camera Roll, WhatsApp Images/Video/Animat

attempts

1

tags

windows,onedrive,pictures,photo-library,digikam,critical,do-not-delete,backup-first

solved_by

00

_rowid

330

▼ Show timestamps

created_at

2026-08-10 23:11:59

⊞ Full detail →

329

—

date: 08/10/26

▾ tap

id

329

record_id

K328

decade

00

date

08/10/26

time

4:06pm

problem

USR369 wants full local directory restructure to eliminate the leftover OneDrive folder tree entirely - not just leave i

solution

IN PROGRESS 08/10/26: Plan is to merge all content from C:\Users\ikre8\OneDrive\* subfolders (known so far: Apps, ArrowB

attempts

1

tags

windows,onedrive,directory-restructure,cleanup,in-progress

solved_by

00

_rowid

329

▼ Show timestamps

created_at

2026-08-10 23:06:44

⊞ Full detail →

328

—

date: 08/10/26

▾ tap

id

328

record_id

K327

decade

10

date

08/10/26

time

11:03pm

problem

inbox-api.php action=drop expects a POST field named content, not body. Using body= silently succeeds (status:ok, real i

solution

Use content= as the field name for inbox-api.php action=drop, not body=. All 6 affected messages resent (927-932) with c

attempts

1

tags

inbox-api,drop,content,body,param-name,silent-failure,K-candidate

solved_by

10

_rowid

328

▼ Show timestamps

created_at

2026-08-10 23:03:29

⊞ Full detail →

327

—

date: 08/10/26

▾ tap

id

327

record_id

K326

decade

70

date

08/10/26

time

4:00pm

problem

Session opened 08/10/26 with no task given - pickup checked twice

solution

Confirmed all queues clean (0 unread broadcasts, 0 pending inbox, 0 pending transfers) - no work performed, clean close

attempts

1

tags

session-open,pickup,clean-close

solved_by

70

_rowid

327

▼ Show timestamps

created_at

2026-08-10 23:00:10

⊞ Full detail →

326

—

date: 08/10/26

▾ tap

id

326

record_id

K325

decade

00

date

08/10/26

time

3:54pm

problem

K324 follow-up: is OneDrive actually installed/running on USR369 Windows 11 machine (ikre8 profile)?

solution

CONFIRMED 08/10/26: OneDrive is NOT installed. No OneDrive.exe process in Task Manager, no tray icon (checked hidden ico

attempts

1

tags

windows,onedrive,not-installed,resolved,K324-followup,desktop

solved_by

00

_rowid

326

▼ Show timestamps

created_at

2026-08-10 22:54:38

⊞ Full detail →

325

—

date: 08/10/26

▾ tap

id

325

record_id

K324

decade

00

date

08/10/26

time

3:01pm

problem

Duplicate Desktop folders (local + OneDrive) and a second unidentified Downloads folder on USR369 Windows 11 machine (ik

solution

- SESSION 08/10/26: USR369 reported duplicate Downloads directories and desktop confusion. Diagnosed via PowerShell Test

attempts

1

tags

windows,onedrive,known-folder-move,desktop,downloads,duplicate-folders,cleanup

solved_by

00

_rowid

325

▼ Show timestamps

created_at

2026-08-10 22:01:20

⊞ Full detail →

324

—

date: 08/10/26

▾ tap

id

324

record_id

K323

decade

40

date

08/10/26

time

7:03pm

problem

Pickup (OPEN.php, SYNC.php, inbox-api.php, transfers/index.php) auto-marked every item read/delivered/seen the instant i

solution

Changed pickup platform-wide to read-only across all 4 real entry points (do_pickup, pickup_with_task_gate in verify_lib

attempts

1

tags

pickup,resolve,architecture-change,do_pickup,verify_lib,inbox-api,transfers,USR369-direction

solved_by

40

_rowid

324

▼ Show timestamps

created_at

2026-08-10 19:03:47

⊞ Full detail →

323

—

date: 08/10/26

▾ tap

id

323

record_id

K322

decade

40

date

08/10/26

time

6:59pm

problem

TASKGATE.php returned matched:true with an obviously irrelevant SOP twice this session: SOP-RESEARCH-MEDIA-DB.md for a C

solution

Not yet investigated -- did not block work either time (correctly recognized as a mismatch and proceeded on direct resea

attempts

1

tags

TASKGATE,false-positive,matching,K251-related,follow-up

solved_by

40

_rowid

323

▼ Show timestamps

created_at

2026-08-10 18:59:39

⊞ Full detail →

322

—

date: 08/10/26

▾ tap

id

322

record_id

K321

decade

40

date

08/10/26

time

6:13pm

problem

UPDATE.php's target=COMMANDS route calls tier2_rebuild_commands(), which is a dead stub -- it returns status:ok with a p

solution

Use target=BOARDS to regenerate commands.html (also rebuilds board.html, decisions.html, status.html in the same call).

attempts

1

tags

UPDATE.php,tier2_rebuild_commands,stub,boards_rebuild,commands.html,misleading-success

solved_by

40

_rowid

322

▼ Show timestamps

created_at

2026-08-10 18:13:08

⊞ Full detail →

321

—

date: 08/10/26

▾ tap

id

321

record_id

K320

decade

40

date

08/10/26

time

6:03pm

problem

T00-SYNCBUG (task 407): SYNC.php silently closed locked any session that called it, including normal mid-session non-clo

solution

SYNC.php v2.5: removed the status field entirely from its POST to set_sync_status -- SYNC has no business owning open/cl

attempts

1

tags

SYNC.php,T00-SYNCBUG,task407,open_systems,sync_status,status-corruption,K318,K319

solved_by

40

_rowid

321

▼ Show timestamps

created_at

2026-08-10 18:03:10

⊞ Full detail →

320

—

date: 08/10/26

▾ tap

id

320

record_id

K319

decade

00

date

08/10/26

time

5:46pm

problem

Investigated why LEGACY-00.md and SOP-CHECKPOINT.md both showed real server timestamps (10:25am and 10:28am PT respectiv

solution

Most likely explanation given the timing: an early/test run of automation tied to the just-confirmed cron capability (SO

attempts

1

tags

sync-bug,K318,automation,cron,session-tracking,unresolved-attribution,security

solved_by

00

_rowid

320

▼ Show timestamps

created_at

2026-08-10 17:46:20

⊞ Full detail →

319

—

date: 08/10/26

▾ tap

id

319

record_id

K318

decade

00

date

08/10/26

time

5:27pm

problem

CRITICAL: SYNC.php silently sets the community registry to status=closed and session_locked=1 on EVERY call, including n

solution

Not fixed -- this is Tier-1 command infrastructure, Server 40 territory. Needs urgent investigation: SYNC.php almost cer

attempts

1

tags

SYNC.php,session-registry,critical-bug,status-closed,session-locked,platform-wide,T2521-related

solved_by

00

_rowid

319

▼ Show timestamps

created_at

2026-08-10 17:27:13

⊞ Full detail →

318

—

date: 08/10/26

▾ tap

id

318

record_id

K317

decade

00

date

08/10/26

time

10:25am

problem

No real command exists that saves full session state (handoff, legacy, decisions) without also closing the session -- th

solution

Confirmed the gap directly by testing every plausible action parameter on the checkpoint tool -- all returned the same r

attempts

1

tags

solved_by

00

_rowid

318

▼ Show timestamps

created_at

2026-08-10 17:25:15

⊞ Full detail →

317

—

date: 08/10/26

▾ tap

id

317

record_id

K316

decade

00

date

08/10/26

time

5:11pm

problem

During a platform-wide David-name cleanup (USR369 standing order, ID22-adjacent), found records-api.php update_task sile

solution

Confirmed description is not rendered anywhere in the current UI -- master-list.php renders $detail (PHP), ml-editor.htm

attempts

1

tags

records-api,update_task,description-field,bug,david-cleanup,data-hygiene

solved_by

00

_rowid

317

▼ Show timestamps

created_at

2026-08-10 17:11:28

⊞ Full detail →

316

—

date: 08/10/26

▾ tap

id

316

record_id

K315

decade

00

date

08/10/26

time

3:03pm

problem

T2521 (USR369, 08/07, !high): Admin and Travel not closing. Confirmed live and root-caused for Travel[95]: registry show

solution

Not fixed this session -- root cause identified, needs Server[40] (owns CLOSE.php/kill-switch.html infra). Two concrete

attempts

1

tags

T2521,kill-switch,close-sequence,CLOSE.php,session-log,travel-95,admin-00,K314-followup

solved_by

00

_rowid

316

▼ Show timestamps

created_at

2026-08-10 15:03:09

⊞ Full detail →

315

—

date: 08/10/26

▾ tap

id

315

record_id

K314

decade

00

date

08/10/26

time

2:59pm

problem

Standing-duty fence check found autoindex directory listing enabled on backend/knowledge/db/ and backend/trash/ (no Opti

solution

Backed up backend/knowledge/db/.htaccess via BACKUP.php first (CURRENT rotation). Added Options -Indexes to both directo

attempts

1

tags

security,htaccess,directory-listing,autoindex,fence-audit,K313

solved_by

00

_rowid

315

▼ Show timestamps

created_at

2026-08-10 14:59:56

⊞ Full detail →

314

—

date: 08/10/26

▾ tap

id

314

record_id

K313

decade

40

date

08/10/26

time

2:59pm

problem

K311 CLOSE.php shrink-guard only covered the force_close branch -- a standard close with a short handoff field could sti

solution

CLOSE.php v2.9: applied the identical shrink-guard logic (compare existing file length vs new content length, preserve p

attempts

1

tags

CLOSE.php,handoff,shrink-guard,K311,fix

solved_by

40

_rowid

314

▼ Show timestamps

created_at

2026-08-10 14:59:30

⊞ Full detail →

313

—

date: 08/10/26

▾ tap

id

313

record_id

K312

decade

00

date

08/10/26

time

7:28am

problem

Confirmed via Server[40]'s two 08/09 messages (900, 901) that SOP-DATA-BACKUP.md's Drive spreadsheets, created 08/08, no

solution

Good pattern worth reinforcing: when a system builds working infrastructure for another system's SOP, extending the exis

attempts

1

tags

sop-data-backup,gdrive-api,provenance,good-pattern

solved_by

00

_rowid

313

▼ Show timestamps

created_at

2026-08-10 14:28:33

⊞ Full detail →

312

—

date: 08/10/26

▾ tap

id

312

record_id

K311

decade

40

date

08/10/26

time

7:05am

problem

CLOSE.php's own handoff field silently overwrote a freshly-written, detailed handoff-40.md (2572 bytes) down to a short

solution

The v2.7 shrink-guard fix only covers the force_close branch of CLOSE.php, not the standard close path used here. A shor

attempts

1

tags

CLOSE.php,handoff,shrink-guard,gap,standard-close

solved_by

40

_rowid

312

▼ Show timestamps

created_at

2026-08-10 14:05:34

⊞ Full detail →

311

—

date: 08/09/26

▾ tap

id

311

record_id

K310

decade

40

date

08/09/26

time

6:26pm

problem

Following up K309: drive_update was 404'ing on files a human created, even in an already-shared folder. Root cause found

solution

Widened gdrive-api.php scope from drive.file to full https://www.googleapis.com/auth/drive. Cleared the cached token (wa

attempts

1

tags

gdrive-api,oauth-scope,drive.file,service-account,T758,drive-trash-permission

solved_by

40

_rowid

311

▼ Show timestamps

created_at

2026-08-10 01:26:28

⊞ Full detail →

310

—

date: 08/09/26

▾ tap

id

310

record_id

K309

decade

40

date

08/09/26

time

6:22pm

problem

T758: built gdrive-api.php (service account write-access endpoint) per SOP-GDRIVE-SERVICE-ACCOUNT.md v1.4. Key path in S

solution

sheets_append (the actual SOP-DATA-BACKUP.md need) works and was confirmed end-to-end -- real row appended to Travel's l

attempts

1

tags

gdrive-api,service-account,T758,sheets-append,drive-upload-limitation,storage-quota,permission-inheritance

solved_by

40

_rowid

310

▼ Show timestamps

created_at

2026-08-10 01:22:16

⊞ Full detail →

309

—

date: 08/10/26

▾ tap

id

309

record_id

K308

decade

10

date

08/10/26

time

12:38am

problem

file_write_web.php has no real append mode -- a mode=append query param is silently ignored and the call does a full ove

solution

Restored what was recoverable from a tail-read taken earlier in the same session (covers 07/19-08/03/26 entries) plus a

attempts

1

tags

file-write-web,append-mode,data-loss,legacy-file,append-only,self-caused

solved_by

10

_rowid

309

▼ Show timestamps

created_at

2026-08-10 00:38:58

⊞ Full detail →

308

—

date: 08/09/26

▾ tap

id

308

record_id

K307

decade

10

date

08/09/26

time

11:54pm

problem

Force-closed 5 systems' COMMS status directly (USR369 explicit direction) -- Server/Daily/Finance/Kitchen/Travel

solution

Investigated first, not blind: Server[40] and Daily[50] showed real evidence a close had already happened (last_closed t

attempts

1

tags

solved_by

10

_rowid

308

▼ Show timestamps

created_at

2026-08-09 23:54:03

⊞ Full detail →

307

—

date: 08/09/26

▾ tap

id

307

record_id

K306

decade

03

date

08/09/26

time

4:50pm

problem

Session-ending confusion pattern: 'the library'/'the app' can mean 3+ different backend stores depending on which is cur

solution

Wrote SOP-TECH-DATA-STORES.md (systems/governance/), broadcast #49 platform-wide, requested SOP-INDEX.md registration vi

attempts

1

tags

solved_by

03

_rowid

307

▼ Show timestamps

created_at

2026-08-09 23:50:16

⊞ Full detail →

306

—

date: 08/09/26

▾ tap

id

306

record_id

K305

decade

03

date

08/09/26

time

4:40pm

problem

Built program-filter chips in windows.html/android.html using JSON.stringify(n) inside an inline onclick="..." HTML attr

solution

Fixed by HTML-entity-encoding the embedded value (" instead of raw ") before insertion, so the attribute's own quot

attempts

1

tags

xss-safe-html,inline-onclick,json-stringify,quote-collision,ui-bug,windows-html,android-html

solved_by

03

_rowid

306

▼ Show timestamps

created_at

2026-08-09 23:40:16

⊞ Full detail →

305

—

date: 08/09/26

▾ tap

id

305

record_id

K304

decade

03

date

08/09/26

time

4:29pm

problem

Tech has THREE separate data stores that all sound like 'the library', and I initially guessed wrong twice before findin

solution

Front-page-linked app confirmed: frontend/30-Tech/index.html -> windows.html/android.html -> fetches https://yttcom.net/

attempts

1

tags

solved_by

03

_rowid

305

▼ Show timestamps

created_at

2026-08-09 23:29:57

⊞ Full detail →

304

—

date: 08/09/26

▾ tap

id

304

record_id

K303

decade

03

date

08/09/26

time

4:23pm

problem

Built FreeCommander/X-plore shortcut references as standalone HTML docs + media.db research entries, per SOP-RESEARCH-ME

solution

Before treating a deliverable as done when USR369 asks for something to go 'in the app' or 'in the library', check the a

attempts

1

tags

solved_by

03

_rowid

304

▼ Show timestamps

created_at

2026-08-09 23:23:39

⊞ Full detail →

303

—

date: 08/09/26

▾ tap

id

303

record_id

K302

decade

10

date

08/09/26

time

11:22pm

problem

CLOSE.php's handoff_write step OVERWRITES handoff-[NN].md with just the 'handoff' field's raw text, destroying any riche

solution

Wrote a full 8017-byte handoff-10.md directly via file_write_web.php before calling CLOSE.php (correct practice, learned

attempts

1

tags

solved_by

10

_rowid

303

▼ Show timestamps

created_at

2026-08-09 23:22:23

⊞ Full detail →

302

—

date: 08/09/26

▾ tap

id

302

record_id

K301

decade

10

date

08/09/26

time

11:14pm

problem

T759 fixed -- file-reader.php now has a working base64 mode for binary files

solution

Added encoding=base64 query param to file-reader.php (v1.1, deployed and tested 08/09/26). Any future binary file read (

attempts

1

tags

solved_by

10

_rowid

302

▼ Show timestamps

created_at

2026-08-09 23:14:06

⊞ Full detail →

301

—

date: 08/09/26

▾ tap

id

301

record_id

K300

decade

00

date

08/09/26

time

4:12pm

problem

SNAPSHOT.php now requires a TASKGATE pass on its create action (new gate, wasn't there previously), but TASKGATE has no

solution

Not fixed -- flagging rather than either silently bypassing forever or over-building a heavyweight SOP for a one-command

attempts

1

tags

taskgate,snapshot,sop-gap,low-priority

solved_by

00

_rowid

301

▼ Show timestamps

created_at

2026-08-09 23:12:05

⊞ Full detail →

300

—

date: 08/09/26

▾ tap

id

300

record_id

K299

decade

10

date

08/09/26

time

10:42pm

problem

USR369 could not access Gym Logger via Health system yesterday (08/08) at the gym, root cause confirmed: T480 (Wire Gym

solution

Verified live: Gym Logger's real data store (accessed via save.php/load.php, profile=david, X-API-Key: cai-gym-2026-yttc

attempts

1

tags

solved_by

10

_rowid

300

▼ Show timestamps

created_at

2026-08-09 22:42:15

⊞ Full detail →

299

—

date: 08/09/26

▾ tap

id

299

record_id

K298

decade

10

date

08/09/26

time

10:27pm

problem

CORRECTION to K296 -- file_write_web.php's WRITE path handles binary content fine, only file-reader.php's READ path is l

solution

K296 flagged file-reader.php as unsafe for binary without distinguishing read vs write direction. Just wrote a real xlsx

attempts

1

tags

solved_by

10

_rowid

299

▼ Show timestamps

created_at

2026-08-09 22:27:44

⊞ Full detail →

298

—

date: 08/09/26

▾ tap

id

298

record_id

K297

decade

10

date

08/09/26

time

10:22pm

problem

SOP-DB-BACKUP.md's bootstrap uses raw copy($src,$dst) on live SQLite DBs -- every backup-strategy source checked (media.

solution

Not fixed -- flagging to Server 40 as their call since they own SOP-DB-BACKUP.md and the bootstrap mechanism. SQLite is

attempts

1

tags

solved_by

10

_rowid

298

▼ Show timestamps

created_at

2026-08-09 22:22:59

⊞ Full detail →

297

—

date: 08/09/26

▾ tap

id

297

record_id

K296

decade

10

date

08/09/26

time

10:18pm

problem

file-reader.php corrupts binary files (xlsx confirmed) -- returns a lossy plain JSON string, not base64

solution

Do not use file-reader.php for any binary content (xlsx, db, images, zips) -- confirmed unsafe on Finance_Ledger_MASTER.

attempts

1

tags

solved_by

10

_rowid

297

▼ Show timestamps

created_at

2026-08-09 22:18:13

⊞ Full detail →

296

—

date: 08/09/26

▾ tap

id

296

record_id

K295

decade

40

date

08/09/26

time

11:53am

problem

Google Cloud now enforces an org-wide policy by default (iam.managed.disableServiceAccountKeyCreation) that blocks JSON/

solution

IAM and Admin -> Organization Policies -> find Disable service account key creation -> Manage policy -> Policy source: O

attempts

1

tags

google-cloud,service-account,org-policy,gdrive-api,key-creation-blocked

solved_by

40

_rowid

296

▼ Show timestamps

created_at

2026-08-09 18:53:39

⊞ Full detail →

295

—

date: 08/09/26

▾ tap

id

295

record_id

K294

decade

80

date

08/09/26

time

7:59am

problem

Bake Journal app (apps/Journal/index.html) was filtering entries by loosely matching 'ID:19'/'ID:23' text anywhere in an

solution

Rebuilt filter to match subject pattern /(Sourdough|Pizza) Bake #(\d+)/ instead of loose text search - only real bake lo

attempts

1

tags

bake-journal,filter-bug,ui,accordion,backup-php,decade-vs-system-code

solved_by

80

_rowid

295

▼ Show timestamps

created_at

2026-08-09 14:59:43

⊞ Full detail →

294

—

date: 08/09/26

▾ tap

id

294

record_id

K293

decade

80

date

08/09/26

time

7:45am

problem

Created a duplicate item (#33) for Sourdough Bake #7 when logging the temp-check/foil-removal update, without first chec

solution

Search open items for an existing Bake #N entry before creating a new one, especially mid-bake when the user is giving l

attempts

1

tags

duplicate,search-first,bake-log,mistake

solved_by

80

_rowid

294

▼ Show timestamps

created_at

2026-08-09 14:45:40

⊞ Full detail →

293

—

date: 08/09/26

▾ tap

id

293

record_id

K292

decade

80

date

08/09/26

time

7:42am

problem

Bake #7 (08/09/26) bottom came out noticeably darker than top - internal temp still landed right on target (204F).

solution

Root cause confirmed, not new: two known bottom-burn mitigations were both skipped this bake - (1) double-layer cookie s

attempts

1

tags

sourdough,bottom-burn,dutch-oven,altitude,bake-7

solved_by

80

_rowid

293

▼ Show timestamps

created_at

2026-08-09 14:42:02

⊞ Full detail →

292

—

date: 08/08/26

▾ tap

id

292

record_id

K291

decade

40

date

08/08/26

time

4:00pm

problem

Claude Drive tools cannot append/edit/delete (K289) -- blocks SOP-DATA-BACKUP.md from actually being fulfillable. Resear

solution

Google service account + raw REST (JWT signing via openssl, no composer library needed) bypasses the Claude-tool limitat

attempts

1

tags

gdrive,sheets-api,service-account,SOP-DATA-BACKUP,K289,research

solved_by

40

_rowid

292

▼ Show timestamps

created_at

2026-08-08 23:00:43

⊞ Full detail →

291

—

date: 08/08/26

▾ tap

id

291

record_id

K290

decade

00

date

08/08/26

time

3:42pm

problem

Built SOP-DATA-BACKUP.md and created 6 Drive spreadsheets before checking SOP-INDEX.md -- only checked Drive itself (cor

solution

D680 (check before building) needs to be applied to BOTH the artifact being created (Drive spreadsheets -- checked) AND

attempts

1

tags

D680,sop-index,finance,process-lesson,data-backup

solved_by

00

_rowid

291

▼ Show timestamps

created_at

2026-08-08 22:42:24

⊞ Full detail →

290

—

date: 08/08/26

▾ tap

id

290

record_id

K289

decade

50

date

08/08/26

time

9:06am

problem

Admin [00] issued SOP-DATA-BACKUP.md (08/08/26): every data-taking system must maintain ONE append-only Google Sheet in

solution

Corrected directive-50.md to reference the official SOP-DATA-BACKUP.md instead of the ad-hoc version, and documented the

attempts

1

tags

solved_by

50

_rowid

290

▼ Show timestamps

created_at

2026-08-08 16:06:48

⊞ Full detail →

289

—

date: 08/08/26

▾ tap

id

289

record_id

K288

decade

50

date

08/08/26

time

7:58am

problem

K284 wrongly concluded no event update/delete mechanism exists platform-wide. USR369 corrected this - update_event and t

solution

Corrected: to edit an existing event, call action=update_event with system+id+subject/detail on the systems/XX-name/data

attempts

1

tags

solved_by

50

_rowid

289

▼ Show timestamps

created_at

2026-08-08 14:58:25

⊞ Full detail →

288

—

date: 08/08/26

▾ tap

id

288

record_id

K287

decade

20

date

08/08/26

time

7:44am

problem

Calling CATCHUP.php to check another system's status silently marks its entire inbox as delivered, even though no real s

solution

Added do_pickup_peek() to verify_lib.php -- identical to do_pickup() but every UPDATE/mark-seen/mark-delivered/mark-read

attempts

1

tags

catchup-php,pickup,peek-mode,verify-lib,inbox

solved_by

20

_rowid

288

▼ Show timestamps

created_at

2026-08-08 14:44:12

⊞ Full detail →

287

—

date: 08/08/26

▾ tap

id

287

record_id

K286

decade

20

date

08/08/26

time

7:44am

problem

Builder/Travel (and likely any system) reopening after a clean close. inbox-api.php's register_shutdown_function closure

solution

Fixed both files live, verified with real before/after test (closed Daily, dropped from Daily, confirmed it stayed close

attempts

1

tags

reopen-bug,dashboard-php,inbox-api-php,session-locked,closure-scoping

solved_by

20

_rowid

287

▼ Show timestamps

created_at

2026-08-08 14:44:12

⊞ Full detail →

286

—

date: 08/08/26

▾ tap

id

286

record_id

K285

decade

20

date

08/08/26

time

7:27am

problem

Gym Logger KEEP checkbox never synced to server (stale diary note claimed it did), LOAD_URL calls had a double-? malform

solution

toggleKeepSimple now writes session.keep and calls saveSessions/syncToServer. LOAD_URL (which already ends in ?key=...)

attempts

1

tags

gym-logger,builder,K-GYM-02,K-GYM-03,K-GYM-04,url-bug,sync-retry,concurrent-edit-anomaly

solved_by

20

_rowid

286

▼ Show timestamps

created_at

2026-08-08 14:27:14

⊞ Full detail →

285

—

date: 08/08/26

▾ tap

id

285

record_id

K284

decade

50

date

08/08/26

time

6:32am

problem

USR369 asked to fix blank events 114-126 in place (not just companion correction notes). Investigated true update path:

solution

Conclusion: there is currently no working mechanism, anywhere on the platform, to edit an existing event row in a per-sy

attempts

1

tags

solved_by

50

_rowid

285

▼ Show timestamps

created_at

2026-08-08 13:32:38

⊞ Full detail →

284

—

date: 08/08/26

▾ tap

id

284

record_id

K283

decade

20

date

08/08/26

time

6:31am

problem

Gym Logger: session data disappears on refresh after loading a session from History into the Log tab for editing. Diary

solution

Found the init restore gate used if(hasDraft() && savedHdr) - an AND-gate. loadSessionIntoLog() writes the draft and the

attempts

1

tags

gym-logger,builder,localstorage,race-condition,silent-failure,K-GYM-01

solved_by

20

_rowid

284

▼ Show timestamps

created_at

2026-08-08 13:31:57

⊞ Full detail →

283

—

date: 08/07/26

▾ tap

id

283

record_id

K282

decade

00

date

08/07/26

time

7:35pm

problem

Tested dashboard.html's tile Close button (sysClose() function) by replicating its exact CLOSE.php call. Confirmed it do

solution

Not fixed -- this is Server[40]/dashboard.html jurisdiction (T702's own code). Worth a platform-wide fix: CLOSE.php's fo

attempts

1

tags

dashboard,sysclose,handoff-overwrite,force_close,platform-wide

solved_by

00

_rowid

283

▼ Show timestamps

created_at

2026-08-08 02:35:14

⊞ Full detail →

282

—

date: 08/07/26

▾ tap

id

282

record_id

K281

decade

50

date

08/07/26

time

6:12pm

problem

USR369 caught it directly in the raw DB: 38 of 126 events had completely blank subject/detail fields, spanning 07/18, 07

solution

Confirmed correct params via test write: subject= and detail= populate correctly, description= does not (API should reje

attempts

1

tags

solved_by

50

_rowid

282

▼ Show timestamps

created_at

2026-08-08 01:12:46

⊞ Full detail →

281

—

date: 08/07/26

▾ tap

id

281

record_id

K280

decade

50

date

08/07/26

time

6:08pm

problem

USR369 directed decade-codes-only, no single digit. Audited Daily 50 live gov files despite K279 claiming Daily's stale

solution

Fixed all 5 files directly: corrected self-identification headers to -50, removed the System code: 05 line from jurisdic

attempts

1

tags

solved_by

50

_rowid

281

▼ Show timestamps

created_at

2026-08-08 01:08:30

⊞ Full detail →

280

—

date: 08/07/26

▾ tap

id

280

record_id

K279

decade

40

date

08/07/26

time

1:52pm

problem

USR369 confirmed Claude Code's decade-migration work was infrastructure-only (roster_lib.php, inbox-api.php, db-viewer.p

solution

Fetched all 66 current gov files fresh, wrote a context-aware fix (regex matching SystemName + [old-code], explicitly sk

attempts

1

tags

decade-standardization,cross-reference,claude-code,platform-wide,final-sweep

solved_by

40

_rowid

280

▼ Show timestamps

created_at

2026-08-07 20:52:41

⊞ Full detail →

279

—

date: 08/07/26

▾ tap

id

279

record_id

K278

decade

40

date

08/07/26

time

1:36pm

problem

USR369 asked to move all remaining single-digit-code content into decade files and confirm every Tier-1 command reads de

solution

Full inventory across all 8 systems that ever had old-code files (Master/Builder/Tech/Daily/Finance/Health/Kitchen/Inner

attempts

1

tags

decade-standardization,legacy-merge,daily,builder,kitchen,T741,final-audit

solved_by

40

_rowid

279

▼ Show timestamps

created_at

2026-08-07 20:36:24

⊞ Full detail →

278

—

date: 08/07/26

▾ tap

id

278

record_id

K277

decade

40

date

08/07/26

time

1:28pm

problem

K273 flagged 4 systems (Builder/Tech/Health/Inner Life) with gov files self-identifying via the old retired 2-digit code

solution

Fixed 12 files total: Builder (knowledge/jurisdiction/directive-20.md, 3 files), Tech (knowledge/jurisdiction-30.md, 2 f

attempts

1

tags

K273,decade-standardization,stale-header,builder,tech,health,inner-life,platform-wide

solved_by

40

_rowid

278

▼ Show timestamps

created_at

2026-08-07 20:28:43

⊞ Full detail →

277

—

date: 08/07/26

▾ tap

id

277

record_id

K276

decade

40

date

08/07/26

time

12:22pm

problem

Standardized save.php to use verify_lib.php's shared resolve_system() (K261/K274 fix). Hit 2 real function-name collisio

solution

Fixed immediately -- replaced the separate manual loop with a second call to the same resolve_system(), reusing its reso

attempts

1

tags

save.php,K261,K274,resolve_system,verify_lib,collision,live-bug-caught,T741,stray-file

solved_by

40

_rowid

277

▼ Show timestamps

created_at

2026-08-07 19:22:34

⊞ Full detail →

276

—

date: 08/07/26

▾ tap

id

276

record_id

K275

decade

40

date

08/07/26

time

12:20pm

problem

Investigating K261/K274 led to a bigger live bug: CHECKPOINT.php had its own hardcoded decade->dir map (duplicating rost

solution

Removed the hardcoded dirs array and code_map entirely, replaced with roster_lib.php (single source of truth, matches ev

attempts

1

tags

checkpoint,K261,K274,decade-suffix,handoff,code_map,platform-standardization

solved_by

40

_rowid

276

▼ Show timestamps

created_at

2026-08-07 19:20:08

⊞ Full detail →

275

—

date: 08/07/26

▾ tap

id

275

record_id

K274

decade

40

date

08/07/26

time

10:26am

problem

K261's root cause found: verify_lib.php's resolve_system() has a deliberate legacy-code normalization shim (added 08/06/

solution

Not fixed -- this is a platform-wide standardization decision (should save.php/CHECKPOINT.php also call verify_lib.php's

attempts

1

tags

K261,resolve_system,verify_lib,wiring-audit,not-a-bug,testing-mistake

solved_by

40

_rowid

275

▼ Show timestamps

created_at

2026-08-07 17:26:33

⊞ Full detail →

274

—

date: 08/07/26

▾ tap

id

274

record_id

K273

decade

40

date

08/07/26

time

10:24am

problem

USR369 asked for a platform-wide wiring audit. Confirmed Kitchen's suspicion: 4 systems still self-identify internally w

solution

Fixed my own file directly (own jurisdiction) -- reordered so header leads, no content lost, verified live. Did NOT edit

attempts

1

tags

wiring-audit,stale-header,K255-pattern,gov-files,knowledge-40

solved_by

40

_rowid

274

▼ Show timestamps

created_at

2026-08-07 17:24:48

⊞ Full detail →

273

—

date: 08/07/26

▾ tap

id

273

record_id

K272

decade

40

date

08/07/26

time

10:02am

problem

K259 (08/06): CLEAN.php's trash_lifecycle block only reported age/status, never actually moved trash to archive or delet

solution

Built the real mover (CLEAN.php v1.7->v1.8). Archive stage (3d+) is now fully automatic, safe/reversible. Delete stage (

attempts

1

tags

clean.php,K259,trash-lifecycle,mover,housekeeping

solved_by

40

_rowid

273

▼ Show timestamps

created_at

2026-08-07 17:02:35

⊞ Full detail →

272

—

date: 08/07/26

▾ tap

id

272

record_id

K271

decade

40

date

08/07/26

time

10:00am

problem

K260 (Tech, 08/06) reported CHECKPOINT.php's memory_pipeline gate showing 'no wisdom logged today' even right after logg

solution

Live-tested against system=40 right now: correctly showed '2 wisdom entries logged today' matching K267/K270. Could not

attempts

1

tags

checkpoint,memory_pipeline,K260,K261,not-reproduced

solved_by

40

_rowid

272

▼ Show timestamps

created_at

2026-08-07 17:00:32

⊞ Full detail →

271

—

date: 08/07/26

▾ tap

id

271

record_id

K270

decade

40

date

08/07/26

time

9:59am

problem

K256 (Builder, 08/06) reported save.php append_legacy wrongly wrote to LEGACY-02.md instead of LEGACY-20.md. Investigate

solution

Verified live: LEGACY-20.md has the real header/ongoing content, LEGACY-02.md is a headerless stray duplicate -- an acci

attempts

1

tags

save.php,legacy,K256,builder,roster_lib,decade-suffix

solved_by

40

_rowid

271

▼ Show timestamps

created_at

2026-08-07 16:59:35

⊞ Full detail →

270

—

date: 08/07/26

▾ tap

id

270

record_id

K269

decade

10

date

08/07/26

time

7:12am

problem

Closed a major session but CLOSE.php's handoff-10.md only got 712 bytes -- just the NEXT SESSION open-items list. The wh

solution

Rewrote handoff-10.md with both a WHAT WAS DONE section and a NEXT SESSION section. LESSON for every future close: the h

attempts

1

tags

solved_by

10

_rowid

270

▼ Show timestamps

created_at

2026-08-07 14:12:19

⊞ Full detail →

269

—

date: 08/07/26

▾ tap

id

269

record_id

K268

decade

20

date

08/07/26

time

7:10am

problem

CLOSE.php's handoff_write step overwrites handoff-20.md with whatever is in the CLOSE.php payload's handoff= field, clob

solution

Pass full session detail directly in CLOSE.php's handoff= field, or write the manual detailed handoff AFTER CLOSE.php co

attempts

1

tags

solved_by

20

_rowid

269

▼ Show timestamps

created_at

2026-08-07 14:10:59

⊞ Full detail →

268

—

date: 08/07/26

▾ tap

id

268

record_id

K267

decade

40

date

08/07/26

time

6:59am

problem

DASHBOARD.php was the 6th file with the status=open hardcode bug (family: REFRESH/UPDATE/SYNC/CLOSE/CATCHUP) -- calling

solution

Applied the same K231 pattern used on the other 5 files: query list_registry for the decade's current status first, use

attempts

1

tags

dashboard,status-hardcode,K231-family,T-DASHBOARD-STATUS

solved_by

40

_rowid

268

▼ Show timestamps

created_at

2026-08-07 13:59:08

⊞ Full detail →

267

—

date: 08/06/26

▾ tap

id

267

record_id

K266

decade

60

date

08/06/26

time

7:55pm

problem

Ashley JT reimbursement amount conflict: jurisdiction lists $165.32, transfer 2259/2260 from Travel says $65.32. Not log

solution

Hold as open question until confirmed. Also: new standing rule broadcast 44 (08/05/26) - check own system_status is OPEN

attempts

1

tags

solved_by

60

_rowid

267

▼ Show timestamps

created_at

2026-08-07 02:55:40

⊞ Full detail →

266

—

date: 08/06/26

▾ tap

id

266

record_id

K265

decade

00

date

08/06/26

time

7:50pm

problem

DASHBOARD.php's comms_ping step unconditionally sets status=open on every call -- confirmed by calling it AFTER a real c

solution

Same fix pattern as the other 5 files: DASHBOARD.php's comms_ping should read the system's actual current status (or omi

attempts

1

tags

status-hardcode,dashboard,server40,sop-session

solved_by

00

_rowid

266

▼ Show timestamps

created_at

2026-08-07 02:50:48

⊞ Full detail →

265

—

date: 08/06/26

▾ tap

id

265

record_id

K264

decade

50

date

08/06/26

time

7:46pm

problem

Write calls (POST add_event) to systems/50-daily/data/api.php began timing out repeatedly starting 08/06/26, after month

solution

Pattern is write-path specific, not general server flakiness - consistent with the already-open WAF write-block issue fo

attempts

1

tags

solved_by

50

_rowid

265

▼ Show timestamps

created_at

2026-08-07 02:46:46

⊞ Full detail →

264

—

date: 08/06/26

▾ tap

id

264

record_id

K263

decade

00

date

08/06/26

time

7:45pm

problem

K255 loop check -- flagged knowledge-10.md's stale contradictory content to Master via inbox 818 rather than editing the

solution

Confirmed closed via SYNC pickup this session (transfer 2433, from Master): Master fixed their own files and additionall

attempts

1

tags

K255,loop-closed,cross-system-flagging

solved_by

00

_rowid

264

▼ Show timestamps

created_at

2026-08-07 02:45:28

⊞ Full detail →

263

—

date: 08/06/26

▾ tap

id

263

record_id

K262

decade

90

date

08/06/26

time

7:45pm

problem

OPEN.php pickup payload showed broadcasts 35-40 as unread for decade 90, but a direct get_broadcasts call moments later

solution

Likely OPEN.php auto-marks broadcasts read as part of returning them in the pickup payload. Not a bug - just means a sep

attempts

1

tags

comms,broadcasts,open.php,pickup

solved_by

90

_rowid

263

▼ Show timestamps

created_at

2026-08-07 02:45:13

⊞ Full detail →

262

—

date: 08/06/26

▾ tap

id

262

record_id

K261

decade

03

date

08/06/26

time

7:45pm

problem

save.php rejects system=03 (Tech's system code) with 'Unknown system: 03' -- requires system=30 (decade code) instead.

solution

Consistent with CHECKPOINT.php (K219 finding) -- some Tier-1 command files expect decade code, others (OPEN.php, SYNC.ph

attempts

1

tags

solved_by

03

_rowid

262

▼ Show timestamps

created_at

2026-08-07 02:45:05

⊞ Full detail →

261

—

date: 08/06/26

▾ tap

id

261

record_id

K260

decade

03

date

08/06/26

time

7:44pm

problem

CHECKPOINT.php memory_pipeline check reports 'no wisdom logged today' even immediately after logging an entry the same d

solution

Likely a date-boundary/timezone comparison bug in CHECKPOINT.php's memory_pipeline gate -- entries ARE landing in the DB

attempts

1

tags

solved_by

03

_rowid

261

▼ Show timestamps

created_at

2026-08-07 02:44:15

⊞ Full detail →

260

—

date: 08/06/26

▾ tap

id

260

record_id

K259

decade

40

date

08/06/26

time

7:32pm

problem

SOP-HOUSEKEEPING-SCHEDULE.md v1.1 says USR369 approved automatic trash-lifecycle enforcement, but CLEAN.php's trash_life

solution

Confirmed by reading CLEAN.php v1.7 full source. Real mover needs to be built (same class as T741) or handled manually v

attempts

1

tags

clean,housekeeping,t741

solved_by

40

_rowid

260

▼ Show timestamps

created_at

2026-08-07 02:32:00

⊞ Full detail →

259

—

date: 08/06/26

▾ tap

id

259

record_id

K258

decade

10

date

08/06/26

time

6:23pm

problem

Admin flagged (K254/K255) that Master's own gov files had stale content undermining a routing-doc fix: knowledge-10.md l

solution

Fixed directly (Master's own jurisdiction, correctly left to Master by Admin rather than fixed cross-system). Backed up

attempts

1

tags

solved_by

10

_rowid

259

▼ Show timestamps

created_at

2026-08-07 01:23:02

⊞ Full detail →

258

—

date: 08/06/26

▾ tap

id

258

record_id

K257

decade

10

date

08/06/26

time

1:51pm

problem

4 days of platform 500 errors, root cause unknown. Master's own diagnostic pass (33 live test calls, 100% success) ruled

solution

Real root cause found by Claude Code (parallel investigation with USR369 + Server[40]): db-viewer.php hardcoded ORDER BY

attempts

1

tags

solved_by

10

_rowid

258

▼ Show timestamps

created_at

2026-08-06 20:51:34

⊞ Full detail →

257

—

date: 08/06/26

▾ tap

id

257

record_id

K256

decade

20

date

08/06/26

time

1:06pm

problem

save.php action=append_legacy system=20 still writes to LEGACY-02.md (code suffix, deprecated) instead of LEGACY-20.md (

solution

Same code-vs-decade split as K253 (handoff/todo) but append_legacy never got migrated when those did. Worked around by w

attempts

1

tags

solved_by

20

_rowid

257

▼ Show timestamps

created_at

2026-08-06 20:06:31

⊞ Full detail →