# PICKUP — Jihad Browser, current state (2026-08-10 body, deltas 2026-08-15 … 2026-11-03 evening below)

**Read this file first. It is the only current handoff.** Everything else in `docs/` is
reference material for a specific subsystem, not a status document.

---

## After Jihad Browser: Global Jihad (a distinct project — NOT started; begins only when Jihad Browser is finished)

Decided with the owner on 2026-10-18. System-wide Goanna: every webOS app rendered by Goanna, not
only the browser's pages. It is its own project with its own name; nothing of it is built inside
Jihad Browser, and it starts when Jihad Browser is finished.

**Facts that shape it (verified on the owner's TouchPad, 2026-10-18):**

- No engine-swap layer exists in Atlas or in webOS CE. Both replace the engine only for the browser
  app, behind BrowserAdapter → YAP → BrowserServer (Atlas: WPE WebKit 2.52 in
  `atlas-wpe-backend`; Jihad: Goanna). `luna-webkit-api` is an IME/field API, not an engine seam.
- The owner's TouchPad runs **webOS CE 3.1.0** (`/etc/palm-build-info`), not stock 3.0.5. Its web
  app manager is a forked second `LunaSysMgr -s` (ppid = the first; 124 MB) running the
  `WebAppManager` class from the LunaSysMgr binary and mapping `libWebKitLuna.so` (12.8 MB, Palm's
  WebKit; `SysMgrWebPage : QWebPage`). Stock 3.0.5 has the same child, closed-source.
- Apps load the JS frameworks by absolute path: 13 third-party apps and the stock ones use
  `<script src="/usr/palm/frameworks/enyo/0.10/framework/enyo.js">` (that directory IS Enyo 1;
  `enyo/1.0` is empty), Mojo apps `/usr/palm/frameworks/mojo/mojo.js` or `mojoloader.js`. A
  patched framework there serves every app, no per-app change.
- The frameworks' WebKit-only surface, counted on the device. Enyo 1 (`enyo/0.10`: 419 js, 170 css,
  12 MB): `-webkit-border-image` ×569 (no Gecko alias), `-webkit-box`/`-webkit-box-flex` ×16,
  `-webkit-gradient` ×11, `webkitTransform` ×23, `webkitTransitionEnd` ×11,
  `webkitRequestAnimationFrame` ×4, 31 `PalmSystem` members, `PalmServiceBridge` in 8 files. Mojo
  (10 js, 60 css): `-webkit-border-image` ×257, `-webkit-palm-mouse-target` ×19 (Palm-only), 46
  `PalmSystem` members, `PalmServiceBridge` in 6 files. 41 apps installed: 39 web, 2 PDK
  (unaffected), 3 Mojo.

**The strategy (the owner's):**

1. **Rebuild the forked WebAppManager instance from the webOS CE source on Goanna**, in place of
   `libWebKitLuna.so`: the LunaSysMgr window protocol (`luna-sysmgr-ipc` messages; card, popup,
   dashboard and alert surfaces; lifecycle; launch parameters), the `PalmSystem` object,
   `PalmServiceBridge`, NPAPI hosting, the IME path (`luna-webkit-api`). Jihad's daemon is the
   engine host to start from (headless Goanna, many pages per process, offscreen rendering, the
   Luna bus, NPAPI, input bridging).
2. **Patch the frameworks in place** at `/usr/palm/frameworks` (Enyo 1 and Mojo:
   `-webkit-border-image` → `border-image`, the Palm-only CSS, the prefixed JS under
   `layout.css.prefixes.webkit`), once for all apps.
3. **Support both webOS CE 3.1.0 and stock 3.0.5.** On CE the open LunaSysMgr allows the chart's
   60 fps rows (the engine's compositor presenting into LunaSysMgr); on stock the shared-buffer
   readback path stays, at T-502's numbers.
4. First proof when the project starts: an Enyo 1 app loaded in the Jihad daemon with a
   `PalmSystem` shim, judged by eye (the frame dumps, not screenshots).

Memory: `global-jihad-project.md`. The workspace `CLAUDE.md` carries the pointer and the corrected
target line (both webOS 3.0.5 and CE 3.1.0).

## 2026-11-03 (evening) — T-505 item 3 DONE: the parts' pictures by part, the express second frame back; item 4 next (READ FIRST)

**State:** main = this commit (on the owner's `ffd6aae2`, pulled from Gitea); the engine fork `jihad/uxp-RB_20261027` at
`adfaa7ff30` (patch 0073; `patch-queue.sh --check` and `check-engine-pins.sh` pass with the gitlink of this commit).
**Not pushed:** the owner's push, `bash .cavekit/handoff-2026-11-03/push.sh` (the engine branch first, then main to Gitea;
both read back). Codex was out of credits until Nov 4th, 01:42: the review gate was ONE ck:inspector.

**Item 3 (the owner's "cheaper part pictures"), built, reviewed, measured, verified:**
- Engine 0073: each rect of a frame's parts list carries a signature of its own (its outermost fixed or sticky layer's
  subtree; every subtree layer's last paint as the stamp of one counter that only goes up — every compositable update
  stamps its layer, part or not; the part's scale, quarter-pixel phase, place inside its rect and size);
  `jihad_offscreen_compose_post3`/`start3` (`overview_ok` 4) take the signatures the daemon holds and the pass reads
  only the rects not in the list; the poll's 54 ints carry each rect's signature and the rects read.
- Daemon: eight part pictures by signature; the list sent by default (`JIHAD_GPU_PARTS_PER=0` or `<state>/no-parts-per`:
  E2's rule, every part when the whole signature moved, the pictures still by part). `PartsReady()` needs an
  engine that answers 4 (a level-3 libxul puts the parts back on the GPU).
- The express lane's second frame on the first in flight is back when both are without their parts
  (`JIHAD_GPU_EXPRESS_SECOND_PARTS=1` or `<state>/express-second-parts`): the second's dress puts back what lay beneath
  the first's parts AND beneath the first's base's parts (slot records keep their base's serial and the rows read; a
  slot's previous record kept aside), never on a first that is itself two deep. `JIHAD_GPU_VERIFY=1` now verifies the
  express lane's frames (the reference composed BEFORE the job), and `JIHAD_GPU_TEST_DRESS_HOLD=<pre|mid>:<ms>` holds
  a first frame's dress so the second's copy really catches it.
- By finger (fps while frames flow): desktop Wikipedia 10.8 (whole) → 11.4 (per part) → 11.4 (+ the second frame); the
  long page 19.2 / 19.4 / 18.1. Wikipedia's parts are its two sidebars and the one that changes (the contents panel's
  highlight) is 310 of the 340 KB: the lever is bounded by the changing part's size; the passes are ~5 % of the time
  either way; the compositor job and the card's own redraw bound the rate. Verify after the pan mark: 0 wrong rows in
  every run, 142 two-deep frames among them, 55-80 with the first's dress held. `docs/rounds/t505-2026-11-03/notes.txt`.
- The inspector (review 3, `context/impl/impl-review-findings-t505-cpuparts.md`): REVISE, 3 P1 / 1 P2 / 3 P3, all fixed
  (a third frame on a two-deep first; a paint count that could return to an old value; the signature blind to a part's
  place and phase; the verify hiding the copy-vs-dress race; a store evicting this frame's picture; equal fallback
  signatures; a leaked verify buffer). The verify then found a LATENT main-lane fault from review 2's F4 (2026-11-02):
  a second job whose in-flight base the parts rule refused built on the newest finished frame but told the engine it
  was the previous composite, so the frame was recorded 316 rows off and the next own-slot frames copied wrong rows
  (5 wrong frames in one run) — fixed (`srcInFlight` in gpuJobStart; 0 wrong in three runs after).
- Desktop: the engine built clean, the adapter round-trip and headless-daemon tests pass; `check-engine-api.py` 0
  FAIL; `check-engine-calls.sh` ok.

**The owner's decisions (2026-11-03 evening, "choose based on performance"):** (1) the parts by part ON by default
(`JIHAD_GPU_PARTS_PER=0` or `<state>/no-parts-per` turns it off) — 11.4 against 10.8 fps on Wikipedia, 19.4 against
19.2 on the long page; (2) the express second frame stays OFF (`JIHAD_GPU_EXPRESS_SECOND_PARTS=1` turns it on) — 11.4
against 11.4, 18.1 against 19.4; (3) item 4 next, not the damaged-rows read (the passes are ~5 % of the time; the GPU
readback bounds the rate). Shipped so: daemon rebuilt, pushed to the three variants, default-check ×3.

**Open, in order:** item 4 — the scroll-only bands composed on the CPU from the tiles' CPU-side pixels, the GPU only for
tree changes (the owner's step 2 of "both, parts first"); then the Tier 91 kits (the webOS SDK T-548..T-550 with its
sudo step for the owner, the Atlas references T-545..T-547, the low-power levers T-555..T-560).

**Item 4, where to start (read on 2026-11-03 evening, nothing built):**
- The tiles: 256 px (`layers.tile-width/height`, `gfxVars::TileSize()`), `BufferTextureHost`s (Shmem/Memory:
  `CreateBackendIndependentTextureHost`) whose CPU pixels the compositor side reads with `GetBuffer()` under
  `AutoLockTextureHost`; drawn by `TiledContentHost::RenderLayerBuffer` → `RenderTile` (each tile's screen rects,
  `aTextureOffset`, the buffer's `GetFrameResolution()`; T-517's cull at TiledContentHost.cpp:597 is ours).
- The frames: by finger on desktop Wikipedia a round has ~90 express frames, 27-35 of them band frames, only 6-7
  "scroll only" by the engine's word (no tree change at all): the rest carry the displayport's paints — tiles, which
  the CPU copy serves as well. So the CPU band condition is "every layer under the bands is a tiled painted layer
  or a colour layer, drawn with 'over', no mask, a translation-only effective transform", not "scroll only".
- The catch — scale: Wikipedia pans at the fit zoom 0.6882 with the layers painted at resolution 1
  (`GpuResolutionFor`: 1.0 up to zoom 1.1), so a CPU band is a bilinear DOWNSCALE of the tiles (768 x ~50 rows, on
  one core, NEON or not), while the long page at zoom 1 is a pure copy. Either a CPU scaler, or the layers painted
  at the zoom's resolution below 1.1 too once a pinch settles (smaller tiles: cheaper paints and a pure copy; a full
  repaint at each settled zoom; T-504's 1.1 threshold was chosen for the zoom-in's sharp frame). A decision for the
  owner, by multiple choice, before the build; a counter under `JIHAD_GPU_LOG` of the band frames that qualify on
  both pages (and of the scale ≠ 1 ones) is the measurement to make first.
- The design then: `JIHAD_GPU_CPU_BANDS=1` — in `JihadComposeAndRead`, a job without its parts whose bands qualify has
  the compositor thread copy (or scale) the tiles' CPU pixels into `aReq->dest`'s band rows, the diff still taken for
  the tree change and the fixed rects/hold set still reported, no GL composite and no read for that frame (the band
  read's wait for the GPU — 11-36 ms under a finger — is what this removes); anything else in a band (canvas, video,
  a mask, a blend, a 3D transform) takes the GPU path as now. Behind the switch, measured by finger, verify 0 wrong
  rows, a review gate.

**Traps from this session (not in the source):** the host had 4 GB available of 32 with the zram swap 97 % full — 12 GB of
closed Claude sessions' scratch in `/tmp/claude-1000` (the permission classifier refused deleting it: the owner's
`rm -rf /tmp/claude-1000/-home-*`), and earlyoom's daemon is not running (only its runsv): engine builds ran at 2 jobs
(`build-goanna-arm.sh build 2`; `build/desktop/build-goanna.sh build 2` takes the argument since today). The desktop
README's podman line lacks the `/jihad` mount the components step needs: `-v "$PWD:/jihad"` (DESKTOP-POC.md has it). A
backgrounded build command once ran with its relative log path lost: use absolute paths. A verify round is judged by
the lines after the `inject pan` mark (memory `verify-counts-after-the-pan-mark`): Wikipedia's load gives 14 "wrong"
frames before it (tiles arriving between the job and its reference). `pan-run.sh` leaves the hand daemon running and
the Enyo job stopped: `gpu-spike-collect-stop.sh` after the last run. `finger-pan-device.sh`'s CPU ticks do not catch
the daemon (its command line is cut before its name).

**Device state:** the three variants run engine 0073 (libxul md5 `a597f8a2`, stripped from `adfaa7ff30`) and the daemon
(`ba9bd159`, the parts by part on by default) by `push-engine-update.sh enyo mochi mojo` (md5-verified, each job restarted; the `.ipk`s NOT rebuilt for
this head; the adapters still the packages of `62af6e82`). default-check passes in all three (the GPU path with the
express lane; faults 0, GPU off 0, express off 0; the Enyo screenshot looked at). No dev copies, `.orig`, gate files
(`parts-per`, `express-second-parts`, `no-cpu-parts`) or adapter gates; Default look, No proxy; the sensors running;
`/tmp/finger` on the device; the round dumps removed; `/var` 28 %.

## 2026-11-03 (later) — the engine on UXP `RB_20261027` (T-551..T-554 DONE); the device on it; the owner's push owed (READ FIRST)

**State:** main `62af6e82` + this PICKUP commit; the engine fork's NEW branch `jihad/uxp-RB_20261027` at `52ad9ab66e`
(72 patches, the queue renumbered from 0060 — the old 0061 is 0060 now; 0031's file name changed), and the old branch
`jihad/uxp-RB_20261006` at `1f54df3762` (0073). **Not pushed:** GitHub main is `1a0026e9`, the fork has neither branch
head. The owner's push: `bash .cavekit/handoff-2026-11-03/push.sh` (both engine branches first — the gitlinks of main's
commits must resolve — then main; all three read back), then `git ls-remote` over https. `.cavekit/handoff-2026-10-24/push.sh`
names only the old branch: do not use it. Codex is out of credits until Nov 4th, 01:42.

**The update (the owner, 2026-11-02: now; 0060 dropped; the certificate/HTTPS changes with special attention).**
`update-engine.sh RB_20261027` put the 73 patches on the tag in a worktree (0060 "already applied", byte-identical
certdata, fell away by itself), `--finish` checked the branch out, rewrote the queue and every pin (UXP/6b18be9 in the
UA and the three start pages, the recipe's SRCREV, `.gitmodules`), `JIHAD_APP_BUILD_ID` 20261103000000;
`patch-queue.sh --check`, `check-engine-pins.sh` and `check-engine-api.py` (its baseline rewritten, unchanged) agree.
`docs/ENGINE-SOURCE.md` has the base, the drop, the renumbering and the range's 12 commits each with its disposition:
the two NSS certificate commits were on the device since the roots of 2026-10-25 and are the base's now (`audit-roots.py`
against the fetched release certdata and the CCADB report: identical, none removed, `docs/rounds/certs-2026-11-03`); no
PSM/TLS/HSTS/UI change in the range; the memory-safety fixes (the JS OOB array copy, the `jar:` flag, feTile, the layout
frame table, the mutation observer's strong ref, SQLite 3.54.1) came with the base.

**Verified.** Desktop: the full build clean; the test harness had rotted since T-515/T-517 (five scripts could not
compile or link: GDK, the stall sampler, JihadFrameWindow.h, the Luna service — fixed, commit `6c0a12ca`); 14 of 18 pass,
the four left (zoom, input, dialog, settings2's popup half) are the desktop GTK path's known read-back limit (PICKUP
2026-10-14), covered on the device. ARM: libxul (the -j8 build beside the desktop one was killed by earlyoom —
`build-goanna-arm.sh build 4`, one engine build at a time), the daemon, the bundle, the three `.ipk`s, FULL pushes to all
three variants, default-check ×3 faults 0 / GPU off 0 / express off 0, the daemon's start line 28 of 29 optional exports
as before (the v1 displayport export its v2 replaced). The touched areas (`tools/device/engine-checks.sh`, new, with
pictures looked at): about:settings, about:personas, about:addons through `jar:` under the flag change; a cookie set and
counted through SQLite 3.54.1; `render/goanna/test/jihad-svg-filter.html` (new: feTile and the 1x1-tile-over-4000x4000
case) painted whole; a long press selects and raises the context menu; faults 0. The certificate kit's checks
(`tools/device/cert-checks.sh`, new): the TLS 1.0 refusal, TLS 1.2 / sha256 / Wikipedia clean, expired / wrong.host /
self-signed / untrusted-root with the SSL confirm's right flags, OCSP revocation enforced (grc.com, ssl.com, DigiCert),
revoked.badssl.com's CRL-only case loaded as on 2026-10-25 — nothing changed with the base. Records:
`docs/rounds/engine-rb27-2026-11-03/notes.txt`.

**Device state:** the three variants from the packages of `62af6e82` by `push-variant.sh` (payloads: enyo 44991 KiB md5=ab05250c; mochi 45571 KiB md5=d465badb; mojo 44321 KiB md5=1e993050; ; the
bundle's stripped libxul md5 `85d24822`); the jobs running; default-check passes in all three; no dev copies, `.orig` or adapter gates; Default
look, No proxy; the sensors running; `/tmp/finger` (the emulated finger, cross-built) left on the device; the round dumps
removed. The old ARM object directory's rollback copy was deleted once the device checked out.

**Open, in order (the owner's 2026-10-26 and 2026-11-02 words):**
1. T-505's items 3 and 4: cheaper part pictures (a per-part signature, only the changed part read, the express lane's
   second frame back under C1's condition), then the scroll-only bands composed on the CPU from the tiles — each behind a
   switch, measured by finger on desktop Wikipedia and the long page, a review gate (Codex from Nov 4th; the inspector
   until then).
2. The other Tier 91 kits: the webOS SDK (T-548 the Redux 0.4.1 submodule, T-549 novacom rebuilt, T-550 `/opt/PalmSDK`
   refreshed — a sudo step the owner runs), the Atlas references (T-545..T-547), the low-power levers (T-555..T-560).

**Traps from this session (not in the source):** the daemon's inject and load lines are stdout (buffered when redirected
to the log), its dialog lines stderr: a per-URL tail of a hand daemon's log mixes old and new lines — send the URLs with
fixed waits and read the whole log after the daemon exits (`cert-checks.sh` does). `JIHAD_DIALOG_MS=4000` makes an
unanswered alert take its default in 4 s instead of 60. Two engine builds at once get cc1plus killed by earlyoom (the ZFS
cache counts as used): one at a time, `build 4` when `free -g` shows under ~10 GB available; "Terminated" in a build log
is earlyoom, rerun the stage. `push-engine-update.sh` refuses a push until `make-device-bundle.sh` has run after a libxul
rebuild. ugrep prints nothing for `-c` on a binary (`strings | grep -c`). The desktop test scripts are named
`build-<t>-test.sh` except embed-smoke, embed-load, headless-daemon, adapter-roundtrip, page-driver.

## 2026-11-03 — T-505: the review gate passed, the long page's wrong verify frame fixed (engine 0073); `RB_20261027` found; the owner: the engine update next (READ FIRST)

**State:** main `c29f396c` + this PICKUP commit; the engine fork `1f54df3762` (patches through 0073; `patch-queue.sh --check`
and `check-engine-pins.sh` pass). **Not pushed:** GitHub main is `1a0026e9` and the fork's branch `446b22790a` — the
owner's push: `bash .cavekit/handoff-2026-10-24/push.sh` (the engine branch first, then main, both read back), then
`git ls-remote` over https. Codex is out of credits until Nov 4th, 01:42 (both `gpt-5.6-sol` and `-terra`): the review
gate owed on `81f56bef` + `446b22790a` was ONE ck:inspector (Cavekit 3.1's backup) — REVISE, six findings, all fixed
(`context/impl/impl-review-findings-t505-cpuparts.md`, review 2). CPU parts stay on by default (the owner's word).

**The long page's one wrong verify frame (PICKUP 2026-10-26's item 2) — found and fixed.** Reproduced with the verify
dumps (`JIHAD_GPU_VERIFY_DUMP_WRONG=1`) and a dress diagnostic (the daemon now logs each dress: the base record, its rect,
a pixel of it, d, the rows read, the rows put back; rate-limited): the restore ran right, but the base's record of what
lay beneath its header HELD THE HEADER. Its job was the load's tree change, a 4 px strip at x 764..768, composed by the
engine as a partial composite clipped and cleared to those columns (LayerManagerComposite::UpdateAndRender) while a
frame without its parts reads the changed rows WHOLE (0072's review fix D4 turned its column read off): the other
columns were the window target's last composite, in a verify run the whole reference with the parts. The verify
mode cannot see it (the CPU header is drawn over the GPU one); the first shift lands the old header where nothing
covers it. Engine 0073 (`LayerManagerComposite::JihadWholeRows`, set by the job's content-only scope): such a job's
partial composite covers the changed rows across the frame's width and reports them so. Verified: the long page's
scripted pan under `JIHAD_GPU_VERIFY=1`, 85 frames, 78 shifted, 0 wrong rows (2 wrong in each of the two rounds before),
every base record's probe the page's pixels; frames looked at. Records: `docs/rounds/t505-2026-11-02/notes.txt`. The
inspector reached the same cause from the code (its F1) and found: F2 one sample time per job (the test API's
`mTestTime`), F3 overlapping part rects (re-merged in the engine; the daemon records every beneath before drawing any,
restores in reverse), F4 the main lane's second job only on a base of its kind, F5 signature misses (a cut part's
slice, every clip rect, the mask's identity, blend modes as covered), F6 the parts pass under the cancel flag — all in
0073 / the daemon. Kit: R4's CPU-parts criterion [x]; R2 gains the read-width criterion.

**`RB_20261027` is on upstream** (T-551's each-session check; fetched into `third_party/uxp` as a tag, nothing checked
out): 12 commits over RB_20261006, 11 files. `[NSS] Remove emSign roots (eMudhra compromise)` 037cc5f614 and `[NSS]
Update certdata to Sept 2026` 4a68bbbd53 are the certificate commits and are ALREADY on the device (the
certificate-trust kit shipped certdata from 037cc5f614 on 2026-10-25, `ROOTS_SOURCE`); no PSM/TLS protocol change in
the range. NOT on the device: `[js] Avoid OOB array copy` 6b18be917d, the `jar:` protocol's `URI_LOADABLE_BY_ANYONE`
flag removed d42616bb12 (Jihad's own `jar:` pages must be checked), feTile overflow bae7a6ec8f, the layout frame table
8fea2ad823, the animation observer's strong ref c4339b14dc, SQLite 3.54.1. Only `certdata.txt` overlaps the queue (patch
0060, byte-identical). **The owner (2026-11-02, by multiple choice): the engine update NOW, before T-505's items 3 and
4; patch 0060 DROPPED; and "pay special attention to the certificate / https updates — pushed upstream in response to
recent exploits"** (kit `cavekit-engine-release-2026-10.md` R1's new criterion; memory
`engine-update-certificate-https-first`).

**Open, in order:**
1. **T-552:** `build/engine/update-engine.sh RB_20261027` (the queue on the tag in a worktree beside the repo; 0060 skipped
   at the `git am` stop with `git am --skip`), `--finish` (the branch, the queue written again, every pin), the
   `JIHAD_APP_BUILD_ID` bump, `docs/ENGINE-SOURCE.md` (the new base; 0060's drop and why; the range's commits with each
   one's disposition — the certificate ones first).
2. **T-553:** `tools/host/audit-roots.py` 0 findings on the new base.
3. **T-554:** the desktop engine build and tests (`docs/ENGINE.md` §7); the ARM engine + daemon + three packages by full
   `push-variant.sh` runs; default-check ×3; the areas the commits touch: Jihad's own pages through `jar:` and
   `resource:` (about:settings, about:personas, the start pages — the `jar:` flag change), cookies and history across
   the SQLite update, selection (the frame table), an SVG filter page; and the certificate kit's device checks (the TLS
   floor, a revoked/expired/mismatched host, the Trust dialog). Then the owner's push.
4. T-505's items 3 and 4 (cheaper part pictures: a per-part signature, only the changed part read; then the
   scroll-only bands composed on the CPU), each measured by finger; then the other Tier 91 kits.

**Traps from this session (not in the source):** a partial composite's clip is the invalid region's BOUNDS and whatever
is read beyond them is the previous composite — the verify's own reference in verify runs; compare the engine's read
extents (rows AND columns) with what it composed whenever either changes. `push-engine-update.sh` refuses a push until
`make-device-bundle.sh` has rebuilt the bundle after a libxul rebuild. The daemon-only push (`--daemon-only`) needs no
bundle. `JIHAD_GPU_VERIFY_DUMP_WRONG=1` dumps the first frame with > 50 wrong rows (`/tmp/vw-*.raw`) and the first
structurally wrong one (`/tmp/vs-*.raw`); fetch and remove them (`/tmp` is 40 MB). ugrep prints nothing for `-c` on a
binary: use `strings | grep -c`.

**Device state:** the three variants run engine 0073 (libxul md5 `673bb742`, stripped from `1f54df3762`) and the daemon
(`3eb1e911`) by `push-engine-update.sh` (md5-verified, each job restarted; the `.ipk`s NOT rebuilt for this head); the
adapters are still the packages of `554ed514`. default-check passes in all three (the GPU path with the express lane;
faults 0, GPU off 0, express off 0; screenshots looked at). No dev copies, `.orig` or adapter gates; Default look, No
proxy; the sensors running; `/tmp` dumps removed; `/var` 27 %.

## 2026-10-26 (night) — T-505: the parts on the CPU, exact (engine 0070-0072); four new kits; paused for a fresh agent (READ FIRST)

**Stopped here by the owner ("stop here and prepare the directory / cavekit 3.1 files for a fresh agent").** Nothing is
mid-edit: every change is committed (main `81f56bef` + this PICKUP commit; engine fork `446b22790a`, patches through
0072, `patch-queue.sh --check` and `check-engine-pins.sh` pass). **Not pushed:** GitHub main is still `d9816d2f` and the
fork's branch `078a0942` (read back over https at the stop) — the owner's push: `bash .cavekit/handoff-2026-10-24/push.sh`
(engine branch first, then main, both read back), then confirm with `git ls-remote` over https.

**Four kits from the owner (Tier 91, T-545..T-560), queued behind T-505 by the owner's word:** the low-power levers of the
UXP stack (`context/kits/cavekit-lowpower-uxp.md`, the scan in `docs/research/lowpower-uxp.md`; nothing measured yet);
the engine on UXP's next release (`cavekit-engine-release-2026-10.md`: the owner WAITS for the next `RB_` tag — none newer
than RB_20261006 on 2026-10-26; RC_20261026 on the release branch, 12 small commits, only patch 0060's roots overlap);
the webOS SDK (`cavekit-webos-sdk-update.md`: Redux 0.4 -> 0.4.1 AND `/opt/PalmSDK` refreshed — a sudo step the owner
runs; HP's PDK is final); the Atlas references (`cavekit-atlas-references.md`: the app moved to
`webOS-ports/org.webosports.app.atlas`).

**T-505 (R3), the owner's "both, parts first" — where it stands.** Every GPU frame is composed WITHOUT the page's fixed
and sticky parts (engine flag 128) and the daemon draws them over it on the CPU. The parts' picture is read **in the
frame's own job** (engine 0072, the inspector's design "E2") whenever the parts' signature (their layers' content,
attributes, structure, sizes) is not one the daemon holds; the daemon keeps three pictures by signature and dresses
each frame with its own, rect by rect — exact. Faults found on the way, all fixed: the picture never matching (keep
split), the lanes' two kinds, own-slot frames diffed without the scroll (engine 0071, on for every build), T-511's rule
taking a slot stale whole (fixed for every build), and the two reviews' findings (`context/impl/impl-review-findings-t505-cpuparts.md`,
every row's status filled). Measured: scripted pan with the card moving, desktop Wikipedia 9.4 -> 12.8 fps, the long
page 18.8 -> 23.6; **by finger Wikipedia 9.5 -> 12.3, the long page 15.7 -> 18.3**. Verify (main lane only): Wikipedia
0 wrong rows in 27 shifted frames (the engine's parts: 2 wrong frames in the same run). Records:
`docs/rounds/t505-2026-10-26/notes.txt` (the last sections). CPU parts are ON in the code (`JIHAD_GPU_CPU_PARTS=0` or
`<state>/no-cpu-parts` turns them off); the owner chose on by default once the findings are fixed — they are, but the
re-review below is owed first.

**Open, in order (T-505):**
1. **The review gate on `81f56bef` + engine `446b22790a`:** Codex (Cavekit 3.1's reviewer; `codex exec -m gpt-5.6-sol -s
   read-only -C <repo> -o <out> - < prompt`) was out of credits until 14:59 and the run was cancelled at the stop; the
   prompt is in `.cavekit/handoff-2026-10-26/codex-e2.prompt`. Inspector as backup. Fix what it finds.
2. **The long page's verify:** one frame of 58 (scroll-only, shift 184, built on its own slot, parts on the CPU) had 13
   wrong rows at frame rows 0..13 — where the base's fixed header lands after the shift (the restore of what lay beneath
   it, or the header's inflated rect edge, are the suspects). Find it (`pan-run.sh` with `JIHAD_GPU_VERIFY=1` and no
   `JIHAD_GPU_EXPRESS`, `docs/rounds/t505-2026-10-26/pan-v1-long-daemon-gpu.log`); compare with `JIHAD_GPU_CPU_PARTS=0`.
3. **The owner's "cheaper part pictures first":** E2 made a picture cost one parts pass in the frame's own job (7-78 ms
   compose, 7-66 ms read, 340 KB on Wikipedia, about one a drag). Next lever: read only the part whose layers changed
   (a per-part signature), and give back the express lane's second frame on the first (lost to review C1: allowed again
   only if the second frame's restore also covers the first frame's base's parts).
4. Then the owner's step 2: scroll-only bands composed on the CPU from the tiles. Then the four kits.
- Cover detection (a content layer drawn above a part) fires twice on desktop Wikipedia during the load (the sidebars
  not yet stuck): harmless (2 dropped frames, the engine's parts for 2 s), not during pans.

**Device state at the stop:** the three variants run this head's engine (libxul md5 `46a3b63e`, stripped from engine
`446b22790a`) and daemon (`f25ef5ba`) by `push-engine-update.sh enyo mochi mojo` (md5-verified, each job restarted); the
adapters are the packages of `554ed514` (the opaque wrap; unchanged since). The `.ipk`s were NOT rebuilt for this head
(build-variant-ipk.sh before a release). default-check passes in all three (the GPU path with the express lane; faults 0, GPU off 0, express off 0; screenshots looked at: desktop Wikipedia after the check's pinch, the sidebars in place). No adapter gates; Default look, No proxy; sensors running.

## 2026-10-26 (evening) — T-504 DONE: the bounded overview; T-505 measured read-only (READ FIRST)

**T-504 DONE (the owner's design; engine 0069).** A double tap out after a pan while zoomed in used to show nothing
until the paint at the old zoom (294-614 ms): the frame kept at the zoom in covers only the view as it was. Now,
right after a zoom in that raises the resolution, the express thread posts, all at once, two or three "windows"
(composites of a frame's rows each at the kept frame's scroll and a frame below and above it, at half the zoom,
overlapping by 32 rows) and one "parts" job (the page's fixed and stuck layers alone, at the kept frame's scroll and
its own zoom), while the tree still holds the tiles at a resolution of 1 (the paint at the new resolution can land
~350 ms after the zoom; posted one at a time the windows lost that race, r8). Engine flags 32 (a window: the
scrolled content alone) and 64 (the parts alone): both cleared transparent and read WITH their alpha (every other
read forces it), so rows no tile covered are left out and the parts keep their own alpha. At the zoom back (only
the "under half" case: a double tap to 2.33 and back; from 1.26 the express lane composes from the zoomed tiles as
before) the frame is the picture at twice its size with the parts drawn over it where they sit at the new position
(held where the neighbouring windows have them, moving with the page, or a sticky top; anything else makes no frame).
By finger: desktop Wikipedia 40-56 ms; the frames looked at against the painted ones, also on
`render/goanna/test/jihad-overview-alpha.html` (a see-through fixed header and sticky sidebar); a pan past the picture
is refused and waits for the paint (no black frame). An inspector review found six defects (the readback's forced
alpha among them: rows past the displayport would have shown black); all fixed and re-measured. Cost: the zoom
in's sharp frame later (682-779 ms against 519-545). Memory per zoomed card: the picture 1.8-2.8 MB and ~0.5 MB of
parts beside the kept frame's 3.7 MB; 7.5-9.4 MB of scratch for ~0.5 s. `JIHAD_GPU_NO_OVERVIEW=1` turns it off;
`JIHAD_GPU_OVERVIEW_DUMP=<path>` dumps the picture. R6's first-frame criterion is [x] and R6 gained the overview's
own criterion. Round tools: `tools/device/t502/zoom-pan.sh` (`PRE=<n>` drags at the fit zoom first). Records:
`docs/rounds/t504-2026-10-26/notes.txt`.

**T-505 measured, read only (the owner's "measure first, read-only" of today).** Eight finger drags,
`tools/device/t502/finger-pan.sh` + `tools/host/express-jobs.py`: while frames flow desktop Wikipedia 9.5 fps, the
long page 16.6. A frame is bound by the readback path on the GPU shared with LunaSysMgr's redraw: Wikipedia's band
frames 64 ms median (the read's GPU wait 36, the copy from the base 16, the compose 14; its sticky sidebars read as
columns double the read), the long page's 30 (11 / 13 / 3); the long gaps are the job's GPU waits. Records:
`docs/rounds/t505-2026-10-26/notes.txt`. Then, the owner's choices in turn: a Codex adversarial review
(`context/impl/impl-review-findings-t505-codex.md`: the copy-free path is refused whenever fixed/sticky content
exists; the GPU-contention claim unproven) -> **the cause proven** with a diagnostic switch (`JIHAD_GPU_NO_PUBLISH=1`:
frames made and read but never handed to the card): the same daemon work makes desktop Wikipedia 32 fps and the long
page 53 while LunaSysMgr draws nothing, 8.6 / 13.6 while the card moves — the card's redraw on the shared GPU and
memory makes every daemon stage ~3x slower -> **the card measured** (the adapter's paint timed, `[paint-stat]` lines
under its paint log): a ~10 ms SOFTWARE blit (Piranha's PSoftContext2D) of the whole view ~20 times a second, mostly
repaints of the frame it has; keeping the wrapped surface per frame changed nothing (not kept); a retained-scroll card
is impossible (a software buffer LunaSysMgr re-uploads); **the frame wrapped without alpha** (opaque: every path
writes alpha 255) halves the blit and cuts LunaSysMgr's CPU 15 % while panning, the picture the same — shipped as the
default (`<state>/alphawrap` reverts), the pan rate unchanged. **The plan (the owner, after "consider sharing tasks
across the CPU and GPU"):** (1) pan frames composed on the GPU as the scrolled content alone (T-504's flag 32 idea) and
the fixed/sticky parts blended on the CPU from a parts image, the pixels beneath them restored per slot; then (2)
scroll-only bands composed on the CPU from the tiles' CPU-side pixels — each behind a switch, measured by finger.

**Observed, not changed:** a main-lane republish of an unchanged frame writes no stuck block (T-544's rects), so the
card's hold has nothing for that frame; harmless at rest (the next pan's frames carry them), noted because the
overview could not take the kept frame's rects from it (it takes them from its own windows).

**Device state:** the three packages of this head (daemon `3c116fb2`, libxul `065b4273` stripped from engine
`c05685f4`, adapters with the opaque wrap and the paint timing: Enyo `3e4d0d31`, Mochi `86f4ac0f`, Mojo `45d32c37`); no
dev copies or `.orig`; no adapter gates (`adapterlog`, `opaque`, `pgcache`, `alphawrap`) left in `/var/palm/jihad/enyo`;
Default look, No proxy; the sensors running; default-check passes in all three (faults 0), screenshots looked at.

**Pushes:** the owner's — `bash .cavekit/handoff-2026-10-24/push.sh` (the engine fork's branch now `c05685f4`, patches
through 0069, and main).

## 2026-10-26 (later) — the scripted pan moves the card; R3 re-opened; sticky sidebars held still (T-544) (READ FIRST)

**The scripted pan never moved the card.** The owner, watching: the column stood still while frames changed. The
inject pan sent the card's scroll commands to the daemon; the card's own view stayed put, so every pan figure up to
T-527 (R3's "24 fps") left out the card's redraw. It now tells the card to scroll and the card reports its scroll,
as under a finger (`JIHAD_INJECT_PAN_NOCARD=1`: the old test). With the card moving: desktop Wikipedia ~7 fps (the
scripted pan and eight real finger drags agree), the long page ~19. Under a finger the readback waits behind
LunaSysMgr's redraw of the card on the same Adreno (a 15-row read 30-164 ms). **R3's first criterion is re-opened
against the corrected test** (the owner's choice); T-505 stays open with it. Measured and not kept: the express
thread's copy from the base (T-505's daemon-side prototype) and the card's redraw coalesced to 33/50 ms (the owner's
pick of lever): neither moved the rate.

**T-544 DONE (engine 0068):** the owner: "the center column is scrolling/panning smoothly but the sidebars are not".
Between frames the card moved the whole frame it holds, Wikipedia's sticky sidebars with it, and each frame put them
back. Now the engine returns each frame's fixed and stuck rects, the daemon writes them into the 192 bytes before
the segment trailer (`JihadStuckBlock`, `render/browserserver/Src/JihadFrameWindow.h`; `JIHAD_GPU_NO_HOLD=1` off),
and the adapter draws them where the frame drew them. Mid-drag screenshots: sidebars still in 4/4 (the column moved up
to 150 px), displaced 11-12 px in 2/4 without; no cost to the frame rate. Records: `docs/rounds/t527-2026-10-25/notes.txt`.

**Open:** T-504 (the owner's bounded overview, not started), T-505/R3 (Wikipedia ~7 fps under a finger: what is left
is structural — the readback on the GPU LunaSysMgr draws the card with; the CE presentation route the owner set aside
on 2026-10-24 is the lever that removes the readback; on stock 3.0.5 it stays), T-414's Pale Moon Persona step (owner).

**Device state:** the three packages of this head (daemon `6fbedc7b`, libxul `543e431b` stripped from engine
`078a0942`, adapters Enyo `044445d7`, Mochi `0ad03744`, Mojo `2b400757`); no dev copies or `.orig`; Default look, No
proxy; the sensors running; default-check passes in all three (faults 0).

**Pushes:** the owner's — `bash .cavekit/handoff-2026-10-24/push.sh` (engine fork branch now `078a0942`, patches
through 0068, and main).

## 2026-10-26 (end) — T-527 DONE; three decisions for the owner; the device on the packaged head (READ FIRST)

**T-527 is done** (and T-515, T-517 with it): the sensor bench (R3's 24 fps met with sensord/atlas-sensord stopped:
desktop Wikipedia 24.6/24.2, the long page 34.2; with them 22.7-23.6), engine 0062-0066, R8 met, the zoom's frames
(first frames 52-108 ms in, 0-3 ms out), and two inspector reviews of the work, every finding fixed (the second:
`31fce614` and engine 0066 `2f7898f0` — the zoom-back frame kept by whichever lane sees the zoom first and published
clear of reads in flight, about:addons repainted at its resolution after a zoom, the search filter re-measured).
Records: `docs/rounds/t527-2026-10-25/notes.txt` (its last sections).

**Three tasks wait on the owner** (build site Status says why):
- **T-504**: a double tap out after a pan while zoomed in has no early frame (the kept frame no longer covers the
  view). Covering it means keeping a picture of the whole page at the fit zoom — memory per card; your call.
- **T-505**: the pan's remaining 56 ms+ gaps are the compositor job itself (copy from the base 10-14 ms, read 7-12,
  compose ~8, on one thread). The next lever is the card composing the new band over the frame it holds (no copy a
  frame): an adapter change and a new meaning for the frame trailer; your call.
- **T-516**: one double tap in ten takes 251-276 ms — the GPU's clock ramp after an idle pause (a 230 ms composite
  with both CPUs at full clock). A GPU clock floor (kgsl) would remove it; a device power lever you have not
  authorized.

**Device state:** the three packages of this head (daemon `cbf72474`, libxul `420e0d27` stripped from engine
`2f7898f0`, adapters unchanged), no dev copies or `.orig`; Palefill only, Default look, No proxy in every profile;
the sensors running; default-check passes in all three. (A Mochi install dropped the USB link once mid-transfer —
the known long-transfer drop — and went through on the retry.)

**Pushes:** the owner's — `bash .cavekit/handoff-2026-10-24/push.sh` pushes the engine fork's branch (now `2f7898f0`,
patches through 0066) and main.

## 2026-10-26 — T-527: the review's fixes, engine 0064/0065, a double tap out's frame at once; about:settings and about:addons by finger

Records: `docs/rounds/t527-2026-10-25/notes.txt` (its last five sections), `docs/FINGER-TESTS.md`.

- **The flick no longer shows grey while the card coasts** (`0481ca94`): the express lane composes each frame where the
  card will be when it is shown (its speed × 80 ms, `JIHAD_GPU_EXPRESS_PREDICT_MS`); after the review the speed is
  measured over 30 ms at least and the lead is at most the overscan rows, not past the page's end. Still open: the
  fixed header slides for the coast's first ~250 ms (an adapter-side header band was considered and not built).
- **about:addons' long lists pan** (T-543, `a597e4a6`; Mochi and Mojo by finger today with the packages): the list's
  length on the root (`jihad-content-height`, jihadPersonas.js), the window made that tall, a XUL page moved by the
  compositor's world offset. An add-on's details longer than the card pan too (review #13, `180c8f07`: what overflows
  them at the card's height, kept while the same view is shown); the search results too (`45a63a92`, their rows
  now say Uninstall like the others). chrome-look R2 ticked.
- **An inspector review of the night's GPU-path changes**: fifteen findings, fourteen fixed (`623dc1ac`, engine
  0064/0065 `247e10f4`/`f4fefca0`): a XUL page's tall layout viewport no longer leaks to the next document; no more
  frameless pans under a zoom of 0.5; the rootless offset per document; the adoption of a main-lane frame keeps the
  main lane's bookkeeping; the lock, the dirty key, the displayport at a new window size; a failed band surface not
  retried every frame. Engine 0064 also skips a layer paint with nothing pending (`JIHAD_GPU_PAINT_ALWAYS=1` paints).
- **A double tap out shows a frame at once** (`286a9265`): the frame the card showed when a zoom in raised the
  resolution is kept and published again the moment the card comes back to that exact zoom (0 ms; the painted frame
  ~750 ms; `JIHAD_GPU_NO_ZOOM_BACK=1`, `JIHAD_GPU_ZOOM_BACK_DUMP=<path>`). R6's first frames by finger on desktop
  Wikipedia: double tap in 59-120 ms, out 0, pinch in 57-233, pinch out 75-237. Open: a double tap out after a pan
  while zoomed in (the kept frame no longer covers the view).
- **Measured, not kept**: a region-based read of the tree's change (the change is its hull in all but one of a
  Wikipedia pan's tree changes) and the slot's own frame as the base with stuck layers (verified correct, 0 rows
  wrong on three pages, but desktop Wikipedia 21.9-22.9 fps with more gaps). R3's open part is the compositor job
  itself: per express frame the copy from the base 10-14 ms, the read 7-12, the compose ~8 on the one thread;
  desktop Wikipedia 23.6 fps, the long page 33.1, verify 0 rows wrong. **On the owner's bench (sensord and
  atlas-sensord stopped, choice (b)) R3's 24 fps is met**: desktop Wikipedia 24.6 and 24.2 fps, the long page 34.2;
  the sensors restarted after.
- **about:settings by finger** (`f43a0165`, `tools/device/finger/prefs-finger-walk.sh`): in Enyo all 57 rows of the
  page's table changed and put back by a tap on their own control (the pickers' items tapped in the card's list),
  the Browser pane's controls (opened from the app menu so the card's own values travel), Clear Cancel/Clear, a
  pane reset; later the Fonts box, Forget (the list put back), Update, the go buttons; in Mochi and Mojo (a hand-started
  daemon with the inject channel) every tab and one control of each kind. FINGER-TESTS' item and preferences-ui R6's
  first criterion ticked. Not tapped: the certificates' Remove buttons (the owner's trust). Trap for the next walk:
  Mojo's card header (45 px) scrolls away with the page, so the page's top on the screen moves once it is scrolled.

**Device state (2026-10-26):** the three packages built from this head are installed (daemon `9257befc`, libxul
`707d9e76` stripped from engine `f4fefca0`, adapters `4f603df3`/`c93bbf54`/`ff4644d7`, impls `b79f1c1f`/`ee838ee6`/
`94f96c00`); no dev copies or `.orig` leftovers (the about:addons component and JihadEngine.jsm of `45a63a92` and the settings page of
`4b055141` put into all three, identical to what a package of this head carries); Luna restarted; default-check passes in all three (GPU path, express
lane, 0 faults). Every profile: Palefill only (the twelve test pads removed), Default look, No proxy — Mochi's and
Mojo's manual proxy to `192.168.1.245:3129` left by the 2026-10-25 proxy round was put back (nothing listened there).

**Pushes:** superseded by the delta above (the branch is now `2f7898f0`).

**Next:** T-527's open criteria (R3: the gaps' floor in the compositor job; R6: the
double tap out after a pan); WebOne needs a machine (the owner).

## 2026-10-25 (night) — T-527: the zoom's sharp frame 3-4x sooner (engine 0062); WebGL at 24+ fps (engine 0063) (READ FIRST)

**Measured by the emulated finger on desktop Wikipedia, sensors running** (`docs/rounds/t527-2026-10-25/notes.txt`,
`tools/device/t502/finger-zoom.sh`): the first frame painted at a new zoom's resolution now comes 593 ms after a
double tap in (was 2212), 669 after a double tap out (1890), 513 after a pinch in (1660), 551 after a pinch out (746);
the first frame at the new zoom (old tiles scaled) stays 58-105 ms. What it took:
- **The critical displayport** (daemon): a zoom that changes the resolution paints what the card shows first, no
  margins; the margins once a frame of that paint is out (`gpuCriticalEnd`, 2 s at most; `JIHAD_GPU_NO_CRITICAL=1`).
- **The express lane publishes the main lane's frame** when it was composed while the main thread is away in the
  engine (40 ms, `JIHAD_GPU_EXPRESS_TAKEOVER_MS`): a double tap's repaint sat composed for 845 ms behind a 1.1 s pump
  of the page's script. The main lane kicks the express thread when it posts (the thread slept up to a second).
- **The hold ends when the express frame is posted**, not published, so the paint runs while it is composed; a zoom
  out past half the painted resolution makes no frame from the old tiles (471 ms of minified tile draws on the
  Adreno for a mostly blank frame, holding the paint's transaction); the card scales its last frame meanwhile.
- **Engine patch 0062 (engine `63c20e39`)**: `nsLayoutUtils::PaintFrame` asks the root's `DecideScrollableLayer`
  with `aAllowCreateDisplayPort`, which REPLACED the root's displayport base with the composition size at the origin
  (CSS px) on every paint — the base `jihad_layout_set_displayport2` sets (0059: what the card shows at the shift,
  times the resolution) never reached a paint. Zoomed in, coverage came only from the margins and the clamp; with no
  margins the critical frame painted 660 of the 861 CSS px shown. Now the paint keeps the daemon's base
  (`nsLayoutUtils::JihadKeepsDisplayPortBase`). Probably also behind T-524's "clip above ~2.9" — not re-tested yet.

Checked: pans on the new engine 29.5-35.4 fps (long page) and 22.3-28.5 (desktop Wikipedia) with the sensors running,
mid-pan dumps looked at; verify without the express lane 0 rows wrong / 0 structurally wrong (59 + 69 frames). The
long page's frames differ below the threshold in most frames where T-519 found none — the head binaries do the same,
not this change. Measured, not changed: `JIHAD_GPU_TEX_POOL=160` cut a zoom's transaction 70-110 ms (+28 MB GPU at most).

**Pushes:** the owner's; `push.sh` pushes the engine fork's branch (now at `bda31412`) and main.

**Later the same night — R8 met, T-511 DONE.** The 480 px WebGL cube 25.3-28.0 fps on the card with the sensors
running (was 16.6-22.0; 360 px 28.9-29.9, 240 px 29.4-30 — the page's own ~30): (1) the daemon writes the rect that
changed since the frame before into the segment's trailer (`JihadFrameWindow.h` dirty words, with both frames' numbers)
and the adapter redraws only that rect when it shows that frame at the same geometry, zoom and scroll
(`BrowserAdapter::msgPainted`; `JIHAD_GPU_NO_DIRTY=1` off); (2) engine **0063** (`bda31412`): a change too tall for the
256-row band surface takes a 512-row band surface instead of the frame-sized target (`JIHAD_GPU_BAND_TALL`). Verify 0
rows wrong, the cube and a ticker drawn right; Wikipedia's pan unchanged. **The PDK adapter had not built since T-540**
(`YapProxy.h`'s member initializer; PDK gcc 4.3.3): fixed — a package build from c0aee8d0/ef9691ec would have failed.
The pan's ≥56 ms gaps are traced (`tools/host/gap-trace.py`, the express lane's `express idle:` notes): 24 in a 10 s
Wikipedia pan, all the compositor job's (a 50-100 ms whole read after a tree change, the copy from the base, a job
queued behind the page's tile uploads), none the main thread's. `docs/IPC-CONTRACT.md` now describes the trailer.

**Device state (end of the night):** Enyo runs DEV COPIES — daemon `b79f1c1f`, libxul `d69e0fd0` (bda31412 stripped),
the adapter `d4325248` in `/usr/lib/jihad/enyo/` (rootfs; LunaSysMgr restarted) — originals as `.orig` (47a68434,
161d7a88, a312e864). Mochi and Mojo: the packages (their adapters the old ones). The upstart Enyo job runs; the Enyo
default check passes. A packaged build of all three after the commits ships the adapters together (`build-all-device.sh`).

**Next (T-527):** the compositor job's floor behind the pan's gaps (the read, the copy from the base), desktop Wikipedia
≥ 24 fps with the sensors (R3), the double tap out's first frame (R6), the tile texture pool size.

## 2026-10-25 — the certificate-trust kit (Tier 90) done on the device; a TLS floor and a tighter Trust dialog (READ FIRST)

The owner's direction of 2026-10-25: audit the roots for exploited or abandoned CAs, drop what should not be
there, match what Pale Moon and Basilisk ship, pull in what was missing. Kit: `context/kits/cavekit-certificate-trust.md`
(R1–R7, all ticked); the how-to: `docs/CERTIFICATE-TRUST.md`; the record: `docs/rounds/certs-2026-10-25/`.

**What was found and done**
- The engine (RB_20261006, certdata of 2025-06-23) shipped **24 roots Mozilla has removed** (Entrust + AffirmTrust ×4,
  GLOBALTRUST 2020, CommScope ×4, Trustwave ×3 / SecureTrust / Secure Global / XRamp, TeliaSonera v1, certSIGN, ePKI,
  SecureSign CA12, FIRMAPROFESIONAL ROOT-A WEB, **emSign ×3 — removed upstream the day before after the eMudhra
  compromise**) and lacked 19 current ones (10 TLS). `tools/host/audit-roots.py` measures this (engine certdata vs UXP
  `release` and the CCADB removed report, by SHA-256; exit 1 on findings).
- **Rolled to UXP release's certdata.txt** (commit 037cc5f6, 2026-10-24 = Mozilla central's, what Pale Moon and
  Basilisk ship): engine patch **0060**, engine fork head `2212143d`, `engine-version.env` ROOTS_SHA256/SOURCE/DATE,
  `check-engine-pins.sh` checks the shipped file ("all agree"). 169 certificates, 118 trusted for sites, 0 on the
  removed report (the daemon's start line, `components/jihadCerts.js _logBuiltins`). The audit after: 0 findings.
- The platform import's list rebuilt from today's report (106 removed roots; `make-cert-lists.py` no longer needs HP's
  image for a refresh); with the Security setting on it now trusts **0** webOS roots (the five it used to add are built
  in). `update-engine.sh --pins` fetches release's certdata and warns when the roots moved.
- Device checks (`device-checks.txt`): the ten new TLS roots' CCADB test sites load with the import OFF; badssl's
  untrusted-root / self-signed / expired / wrong.host / sha1-intermediate get the dialog, rc4 / dh480 / null / 3des the
  engine's alert, sha256 and tls-v1-2 load; `revoked.badssl.com` LOADS (Let's Encrypt is CRL-only since 2025; UXP has
  no CRL fetch and no CRLite — recorded, same as Pale Moon); OCSP revocation IS enforced (ssl.com's and DigiCert's
  revoked demos refused). The padlock's View Certificate names DigiCert's issuer and dates.
- **Two findings fixed:** (1) **TLS 1.0/1.1 were accepted** (the engine's default min = 1): `jihad-platform-prefs.js`
  sets `security.tls.version.min` 3 — tls-v1-0/1-1 now refused (`SSL_ERROR_UNSUPPORTED_VERSION`), the Settings row
  can lower it (R6). (2) **A revoked certificate got Trust Once / Trust Always** (every security-module failure was a
  "certificate question"; the engine ignores an override for a non-overridable error, so accepting reloaded into the
  same failure): `GoannaRenderPage.cpp` now asks only for the engine's overridable set (`JihadOverridableCertError`,
  the cases of UXP's `DetermineCertOverrideErrors`) and reports the rest as a failed load with the engine's alert (R7;
  daemon build needs `-I$DIST/include/nss`, added to the ARM and desktop build scripts).
- Open: **T-534** — over TLS 1.3 this NSS (3.90.14) labels a revoked refusal `SSL_ERROR_RX_MALFORMED_SERVER_HELLO`
  (over TLS 1.2: `SEC_ERROR_REVOKED_CERTIFICATE`); the security info's errorCode was 0 on the measured case. Cosmetic
  (refused either way) but the alert misleads: find the mapping in the async auth-certificate completion.

**T-535 DONE — one tap, one click (all three shells).** Found while driving about:addons' row buttons by finger: the
adapter sent TWO clickAt per tap — the pen path's (handlePenClick → 400 ms double-click timer → "click" hit test →
the card may claim it in eventFired → clickAt, isis's contract) AND one from `npPalmGestureSingleTapEvent`, added
2026-07-07 when the daemon answered no hit test. A checkbox toggled twice per tap (`cb change=2 checked=0`), Disable
disabled and re-enabled, Preferences opened one run in five (the second click raced the view switch). The gesture's
clickAt is gone (`render/adapter/BrowserAdapter.cpp`); the three adapters rebuilt (`build-adapter-pdk.sh`: enyo
`a312e864`, mochi `72104039`, mojo `55d15ec5`), verified by finger in each shell (one clickAt, `checked=1` then `0`;
about:addons Disable/Enable/Preferences act). A tap's click now lands after the 400 ms timer, as on the stock browser;
if that feels slow, `kDoubleClickInterval` is the knob (the system's single-tap gesture could replace the timer, but
the double tap's zoom rides on that timer — measure before touching it). Probe recipe: a hand-started daemon with
`JIHAD_INJECT=1` (the packaged job has none), `rect anon:#addon-list > richlistitem|preferences-btn` for the row's
anonymous buttons (`anon:richlistitem|…` resolves the CATEGORY list's first item — icon/name/badge only), `gettext #e1`
on jihad-input-sweep.html, and the daemon's `clickAt (` lines counted per tap. `jsurl` does not run in a chrome
document (about:addons) — known, GoannaRenderPage.cpp says so.

**Personas by finger (after T-535):** Wear / Take off / Undo / Remove (two taps) / Install from file / a wear from
the add-on site / the addons.mozilla.org question — all act on one tap (docs/FINGER-TESTS.md, personas-ui R6). The
2026-10-24 oddities were the double click and the list putting the worn Persona first. Aurora Silk was removed and
re-installed from the site; Carbon Light re-installed from its .xpi; the Default look restored.

**about:addons, the three findings — DONE 2026-10-25 (afternoon).** (1) The tools menu's pixels stayed on the card after
"Check for Updates" ran: the composited popup's pixels sat in the frame slots and the GPU path's next frame built on the
slot that still had them. Fixed in the daemon: the popup-close transition voids every slot — the software path's `valid`
AND the GPU path's `gpuSlotsReset()` (the first try reset only the former and nothing changed); verified by finger, gone
after the item and after a dismiss. An engine-side content invalidation (tried as patch 0062) changed nothing and was
dropped — the engine stays at `ec8f0ed7` (patches through 0061). (2) The row after Undo on an uninstall read "Remove" —
a MutationObserver relabels it (`jihadPersonas.js`), verified. (3) The tools menu was pale on pale — `#utils-menu` styled
in `addons.css`, verified readable. Probe notes: the daemon's `painted … rows new=` counts only software-rendered rows
(0 on a GPU frame says nothing); a popup's close is seen at `PopupsOpen()`'s transition in the tick.

**Cavekit 3.1 — the owner's question of 2026-10-25 ("ensure jihad browser is managed with cavekit v3.1 not 2.0, and that
the cavekit files are aligned"):** what the session runs IS the 3.1 plugin — `claude plugin list` reads `ck@cavekit-local`
from `~/.claude/plugins/local/cavekit-marketplace/ck` (16 commands, 21 skills, 12 agents, the `ck:team` of 3.x); a stale
registry entry said 2.0.0 and was refreshed with `claude plugin update ck@cavekit-local` (it now reports **3.0.0**, because
the plugin's `.claude-plugin/plugin.json` in the Cavekit checkout says 3.0.0 while its `plugin.json` and the marketplace
say 3.1.0 — a version bump the Cavekit repo owes itself). The CLI's Go binary (`cavekit version`, `cavekit team`) does
not build on Linux from that checkout (`internal/tmux/terminal.go: undefined: unix.TIOCGETA` — Darwin ioctl names); the
node tools the loop uses are unaffected. **The files:** `.cavekit/tasks.json` held 171 tasks while the site had 327 (the
hand-added tiers 84–90 never reached it); `tools/host/cavekit-sync.py` now regenerates `tasks.json` and reconciles
`task-status.json` from every tier table of `context/plans/build-site.md` (run it after editing the site by hand; both
files are gitignored runtime state). In doing so the old registry was overwritten before its statuses were carried over,
so the states of tiers 0–83 are taken from the site's own words (DONE/BUILT/…, a Reason column = blocked) — 304 complete,
16 blocked (a person, a printer, hardware), 7 in progress (the GPU floor's T-504/505/511/515/516/517 and T-527).
`cavekit-overview.md`'s Status column is now counted from each kit's criteria (met / partial / open, with the latest
entry's date; the Finger Emulation row added); `plan-overview.md` and `impl-overview.md` point at the current sources.

**Device state (2026-10-25, night):** all three variants installed as PACKAGES through `push-variant.sh` from the packages
built at commit c0aee8d0 — `build/webos-oe/out-ipk/net.riverstonerelay.jihad-browser_1.0.4_all.ipk` `050c7b39`, `-mochi_1.0.0`
`8887d2f8`, `-mojo_1.0.0` `a0877cfe`; in each `deviceroot/hl`: libxul `161d7a88` (engine `ec8f0ed7`, patches through 0061),
daemon `47a68434` (T-536 … T-541, the 180 s login deadline, the fling lead and the one-height displayport),
`prefsui/content/preferences.js` `310b2098`, `libnssckbi.so` `f8e9ebea`, `goanna.js` with the TLS floor, the 2026-10-25 cert
lists; the adapters `a312e864` / `72104039` / `55d15ec5`. The Enyo card's test hook was pushed for the rotation scenario and
RESTORED (`card-selftest.sh enyo restore`, LunaSysMgr restarted). **The device IS the repository head.** Root filesystem
read-only; every variant's proxy prefs at the defaults; Palefill active; the Default look; no card open.

**T-534 DONE (engine patch 0061):** PSM's `retryDueToTLSIntolerance` remembered a certificate error as TLS-version
intolerance and retried at TLS 1.2, which trips a TLS 1.3 server's downgrade sentinel — so every certificate failure
against a TLS 1.3 server read "SSL_ERROR_RX_MALFORMED_SERVER_HELLO" (badssl.com is a TLS 1.2 server, which is why
its cases were right). Now a SEC_ERROR_* / pkix / bad-cert-domain failure never retries lower; verified on the
packaged build: ssl.com's and DigiCert's revoked hosts say "Peer's Certificate has been revoked".

**To push (the owner):** `bash .cavekit/handoff-2026-10-24/push.sh` — the engine fork `jihad/uxp-RB_20261006` now at
`ec8f0ed7` (patches 0060 and 0061) and Jihad-Browser main through this round's commits.

**Done since (2026-10-25, the afternoon and evening sessions), all by finger on the packaged build:** T-536 (about:addons:
the closed menu's stale pixels, the Undo row's label, the menu's look), T-537 (Enter in a textarea reaches the page first —
DuckDuckGo searches), T-538 (a field in a frame; the followed layout width survives the keyboard), T-539 (the slow-script
dialog names its buttons; Cancel stops the script), T-540 (a dialog whose card closed no longer holds the daemon for a
minute), T-541 (a fling no longer lands on grey: a height of displayport each way, a lead in the fling's direction), T-542
(no defect), the Personas items (Wear/Take off/Undo/Remove/from file/from the site/AMO's question, Remove while the picture
is made, no card flashes), everyday browsing and a login-asking proxy in all three shells, My own proxy typed on the
keyboard, the Relay when chosen — and the owner's rule: **the Riverstone Relay is never a default** (a fallback for webOS
older than 3.0 only; the shipped defaults audited; the settings page says so; a login dialog waits 180 s).

**Next, toward a shippable build:** FINGER-TESTS.md's remaining open items — rotate (needs the accelerometer or a person),
about:addons' list panning (needs more add-ons installed), about:personas' flashes and Remove-while-the-picture-is-made,
about:settings' every control, the proxy items (My own proxy, WebOne, a login proxy, the Relay for everyday browsing),
Flash/audio heard (a person); then T-527's compositor-thread work; the owner's push.

---

## 2026-10-24 (evening) — the owner's two new directives; the emulated finger, where it stands (READ FIRST)

**Later the same evening — the round's part 1 run and its findings fixed (READ THIS FIRST):** T-523 and T-524 are
DONE (T-514 with them). `tools/device/finger/` has tap, dtap, hold, drag, drag2, flick, pinch, sleep, raw; the kit's
R2 is all ticked. The round's scrolling and gesture items are run in all three interfaces (`docs/FINGER-TESTS.md`
carries each result; `docs/rounds/finger-2026-10-24/zoom-grey.txt` the data). **The owner's "areas turn grey" was
found and fixed:** (1) the smart zoom fitted a 104 px cell (6.2x) and the engine's default maximum-scale of 10 passed
the adapter — the block rule (a third of the card) and a 4.0 default (daemon); (2) at rest the zoomed frame lost its
right third from 2.0 and everything from 2.98: the ROOT'S DISPLAYPORT BASE AND CLIP ARE IN LAYOUT DEVICE PX once the
pres shell has a resolution (Gecko divides them by it) — `jihad_layout_set_displayport2` (the card's shift, base and
margins times the resolution) and the root's clip no longer divided (engine c79d16f8 = patch 0059, UXP_PIN moved;
memory `compositor-scroll-traps` 6 and 7); (3) the second double tap and any tap on a zoomed page found nothing — the
GPU path keeps the position in the engine's scroll, not the render pan (`docOffset`/`gpuAlignForHitTest`), and a
zoomed-in page with no block answers the page's width (back to the fit); (4) the resolution is set BEFORE the
displayport and the displayport re-set at every zoom (a pinch from 2.33 to 2.8 clipped again; the zoom-out painted
160 tiles). **Still open, dispositioned to T-527:** the flick's coast gap (the engine paints only at the coast's end:
~0.5 s of blank lower card and no fixed header), the first frame at a new zoom (1.6-2.9 s on desktop Wikipedia, R6),
the clip above ~2.9 on a page laid out 1116x1374 (closed for now by a GPU maximum-scale of 4000 / the declared
viewport's larger side; a page with no viewport tag keeps the adapter's 4.0 and will clip above ~3.3).
**Device state:** DEV COPIES on all three variants — libxul 4d753b8f (c79d16f8 stripped) and daemon 7c29035a in each
`deviceroot/hl`, the originals kept as `libxul.so.orig` / `jihad-browserserver.orig` (c66cd841 / 350c83ed); the
upstart jobs run them. A packaged build and install (the three ipks) is the clean way to ship them: `build-all-device.sh`
after the commit. **T-525 begun (part 2):** the chrome buttons of all three shells act, Mojo's back and forward included (the hour spent on a "dead back" was a tap on the disabled forward box: Mojo's bar boxes are back 197-247, forward 251-301, home 305-355 … in card px, not where the icons seem to be). TWO TRAPS from it: (1) the card's WebKit serves an app's JS from its memory cache across relaunches — a shell file edited on the device runs only after `build/webos-oe/luna-restart.sh` (every probe before that restart was a no-op); (2) palm-log and syslog carry none of a Mojo card's Mojo.Log lines on this build — report through the daemon instead (navigate to a URL with the data in its query; the load line carries it). Enyo's long-press on text and on a field done. The Mojo daemon runs a0e151e1 (7c29035a plus the pageBackward/pageForward log lines; Enyo and Mochi still 7c29035a); the Mojo shell file on the device is its original. **Later still — T-525 DONE, T-526 mostly:** every item of parts 2 and 3 that a finger can reach is run (see `docs/FINGER-TESTS.md`, each item dated 2026-10-24). Found open: Mojo's link hold shows the text commands only (the shell's hold menu never sees the hit test's link facts — Mochi claims them in JihadWebView.eventFired; mojo-ui R6); the about:addons extension ROW's buttons do not act on a tap at the 0.78 fit zoom (the hit test answers the `richlistitem`; the detail view's buttons do act — Palefill was disabled that way and put back by editing `userDisabled`/`active` in extensions.json with the daemon stopped); Mochi's Paste from the field sheet lands nothing (the card's clipboard write or read; JihadBrowser.js pagePaste). The device: Palefill enabled, the Default look on, the Mojo prefs restored, fonts restored. **And later:** the T-526 leftovers done (the caret and the Backspace repeat, Copy from the address and Paste into a field, two downloads — the CE bench has no handler app to open either type); two of the three opens FIXED and verified by finger — Mojo's link/image hold gets Open in New Card / Share Link / Copy URL (the shell claims those holds through the widget assistant's `eventFired`), Mochi's Paste lands (pagePaste clicks the held point before inserting: the sheet had blurred the field). Still open: the about:addons extension ROW's buttons at the fit zoom (the detail view's buttons act). Shell dev copies on the device match the repo (originals kept as .orig beside them). **T-527 begun — the sensor bench done:** desktop Wikipedia's scripted pan 21-22 fps with the sensors, 25-27.5 with `sensord` and `atlas-sensord` stopped (the long page 30-35 / 33-37); sensord alone is ~30% of a core at idle. The sensors are running again. **Next:** the compositor-thread floor in the engine (the frames composed off the main thread so the engine's paints and script do not gate them; T-505/T-511/T-517's items are its parts), measured by the same pan-run against these numbers; and the one finger open left, the about:addons extension row's buttons at the fit zoom. Not pushed: this session's commits — Jihad-Browser de4fb43c..64413a73 (12 commits) and the engine fork 7a872e8f..c79d16f8 (patch 0059; the main repo's gitlink points at it). `bash .cavekit/handoff-2026-10-24/push.sh` pushes both, reads them back and checks the pins (the owner's, GitHub key passphrase).

**The owner:** (1) "proceed with everything blocked by the finger tests, not by assuming it works, but by driving your
own tests by emulating a finger and addressing any issues that crop up. if youre not sure how best to emulate a finger
on the touchpad consult codex"; (3b) the GPU floor levers are authorized: the bench without `sensord`/`atlas-sensord`
and compositor-thread work in the engine (memory `gpu-floor-levers-authorized`; T-504/505/511/517 re-opened in the
registry). Also: "remember to use cavekit 3.1 and clear screenshots when you no longer need them" (memory
`clear-screenshots-when-done`; the 807 untracked dumps were deleted). **Not yet done:** a kit and Tier 89 tasks for the
finger emulation and the re-opened GPU work — write them first (Cavekit 3.1: sketch, map, make).

**The input path, established from the device and the binaries (context in `.cavekit/handoff-2026-10-24/finger-context/`,
git-ignored):** the Cypress panel is read by `hidd` (`/dev/ctp_uart`, plugin `libhidtouchpanel.so`, config
`/etc/hidd/HidTouchpanel_evt1.xml`), not evdev; `/proc/bus/input/devices` has only keys. hidd SENDS each scan as a
datagram of 16-byte Linux `input_event`s to the AF_UNIX **datagram** socket that the CONSUMER binds at
`/var/run/hidd/TouchpanelEventSocket` — LunaSysMgr (pid of the window server) holds it (fd 18; `KeypadEventSocket` fd 19),
through `libhal.so` + `/lib/hal/modules/halTouchpanelMain.module` (`HidInitPluginTransport` binds; `hal_hidd_read_events`
recv()s into a 4 KB buffer), then the Qt QPA plugin `/usr/plugins/platforms/libqpalm.so` (`QPAHiddTpHandler::readHiddData`
→ `qt_translateRawTouchEvent`). The module's parser (`touchpanel_get_event`, decompiled): per finger `EV_FINGERID` (type 7)
opens a touch item (id = value*1000 + code, the timestamp), `EV_ABS` code 0/1 = x/y, `EV_KEY BTN_TOUCH` 1 = down, 0 = up
(QPA: a "down" adds a finger, so send it on the first scan only; the up on the last), `EV_GESTURE` (type 6) = gesture code
then x and y velocity in two events (FLICK = 6), one `EV_SYN` ends the scan, 20 fingers at most; an empty scan is dropped.
Public source of the later Nyx version of the QPA plugin: github.com/openwebos/qt
`src/plugins/platforms/palm/hiddtp_qpa.cpp` (states, addNewTouch/updateOldTouch, mouse emulation, FlickGesture).

**The tool:** `tools/device/finger/finger.c` (builds with the toolchain line in its header; tap, dtap, hold, drag, flick,
pinch, raw) sends such datagrams to the socket as root, taking PORTRAIT screenshot coordinates (raw x = portrait y,
raw y = 767 − portrait x: a tap at raw (10, 737) opened the app menu at portrait (30, 10)). **Proven 14:06:** libhal
logs "Unexpected code 0x5" for a bad datagram (the parser runs on ours); a 500 px drag on `jihad-long-static.html`
scrolled the top from paragraph 1 to 8, a 160 ms flick coasted to 33, a pinch out zoomed in, a long press opened the
context menu. NB `jihad-touch.html` is no oracle: a page's DOM touch listeners are not fed by the card's pan path.
Still to tune: the double tap (two 70 ms taps 120 ms apart changed nothing on a zoomed page) and the tap on the address
field (no keyboard). The kit `cavekit-finger-emulation.md` and Tier 89 (T-523…T-527) carry the work. The old next
experiments, now moot: (a) confirm the datagram is read at all — `strace -p <LunaSysMgr> -e recv` is not on the device,
so instead send `finger raw` events and watch `/var/log/messages` for libhal's `_hal_log__` lines ("Unexpected code",
"No touch items") with HAL_LOG_LEVEL raised, or use `hidd`'s own `CreateFingerUpEvent` Luna method to see a real
datagram's effect; (b) the id scheme (try code 0 / value 1 as hidd may), the `BTN_TOUCH` code (0x14a) and whether hidd
sends `EV_KEY` at all for touch on this build; (c) whether the QPA delivers to the card only after a HAL "touchpanel
mode" or when the card has focus; (d) the coordinate frame (landscape 1024x768 vs portrait). Codex: out of usage until
18:30 after 468k tokens of grepping, no report; the inspector is the backup.

## 2026-10-24 delta — Tier 88: the kits' open criteria closed on the current build; the commits chained for the owner's passphrase (READ FIRST)

**The owner:** "Continue the implementation of Jihad Browser using Cavekit version 3.1." The registry had no
unblocked task (the finger rounds, the tabs tier and T-504/505/511/517 are the owner's), so Tier 88 was added
to the site (T-518…T-521): the acceptance criteria no task covered any more, and the engine's staged review
fixes (0058) not yet in the patch queue.

**T-518 (records) done.** Seven criteria met by earlier tasks ticked with their evidence (gpu R11's review,
content-blocking R7's three, modern-web R1's two and T-500's two); T-501's criterion kept `[~]` until T-520's
MSE probe; the template placeholders never filled (`T500_KIT`, `T501_KIT`, `T501_DEVICE_RESULT`,
`DEVICE_STATE_EVENING`, `TRACE_PICKUP`) filled; a stray JSON blob reverted out of `.cavekit/config` (the owner's
one-line file); the README's "Where it stands" regenerated.

**T-519 (the GPU sweep) done.** On engine 0058, the 10 s scripted pan on six pages under `JIHAD_GPU_VERIFY=1`
(`docs/rounds/t519-2026-10-24/`): 0 rows structurally wrong on all; 0 rows differ at all on the long page, the
new `jihad-fixed-both.html` (an opaque header AND footer, nothing else), sticky-mix, scroll-js and Hacker News;
Wikipedia 3 of 70 frames resampling-class. The animation page differs only inside its animated block (the
verify reference samples the CSS animation at its own compose time): R2's first criterion is `[~]` with the
engine fix named (pin the reference's animation time to its job's). R4's four ticked on the compositor's lines
(two bands with both kept on the fixed-both page, Wikipedia's panels as 2 columns in 3-5 chunks; sticky-mix takes
the whole path as in T-503's rounds). R3's table, the GPU path against `NOGPU=1` on every page, is in
`docs/RENDERING-OPTIONS.md`: ahead everywhere (long 30-33 against 11-12.5 fps, Wikipedia 18.5-26 against
2.7-2.9, Hacker News 37-48 against 6-10).

**T-520 (the blocker's device criteria) done, one criterion failed and fixed by T-522.** On the Enyo card through the
inject channel (`url`, `setpref`, `gettext`, `rect`, `click`, `jsurl`), with `123count.com`, `ad.doubleclick.net`, a neutral
`jihad.test` and the 200-image page's twenty hosts mapped to the host PC in `/etc/hosts` for the run: a listed host
opens top-level; a `$third-party` host loads first-party and is refused third-party; an `@@||host^` exception (a list
copy with one added) loads the host; the master switch and hiding flip live; the settings line shows the versions and
a counter that rose 10 → 16; "Update the lists now" moved the lists three times (1105 → 1606 → 1630 → 1635/1641);
`shouldLoad` on 200 refused images is within 10 % of blocking off; MSE reports H.264 and AAC (T-501's criterion
ticked). **R4's sheet cost was not met**: hiding on cost the MDN page about 4 s a load (its copy: off 2.6-3.0 s, on
3.7-7.5; the real page off 11 s, on 15) and 8-12 s on a daemon's first load. Four variants of the cached sheet named
the cause: the 268 `@-moz-document regexp` groups (one per site-excepted generic selector, each repeating the 160
generic-hide hosts' 2.4 KB regexp), not the 13,079 keyed selectors — the same sheet under `url-prefix` scopes or with
no wrapper costs nothing. T-522 moves those selectors into the per-document sheet (`excSel`, compiler 11) and leaves
the global sheet one regexp group: the MDN copy now loads in 2.9-3.1 s with hiding on against 2.6-2.8 off (+8.7 %), a daemon's first load 3.7 s where it took 8-12; `jihad-hiding.html` still hidden, the site-excepted `#ad-carousel` hidden on `jihad.test` (`t522-run2-host.log`). The bench's three variants run the new component (a dev copy, md5 e8f6c123; the packages carry it at the next bundle build). On a `$generichide` host (jetzt.de mapped to the PC) generic hiding does not apply and the excepted selectors are not added (`t522-generichide-host.log`; the compile line: 268 excepted selectors per document, 154 generic-hide sites and 4 address prefixes). NB two earlier runs of that check timed out and looked like a 25 s stall: the host was not mapped (a `sed` on the prep script had rewritten its own guard) and the load's error alert waited 60 s for a card to answer. Ledger: `docs/MODERN-WEB.md`, T-520; logs `docs/rounds/t520-2026-10-24/`.
New pages: `jihad-tp-first.html`, `jihad-tp-third.html`, `jihad-exception.html`, `jihad-hiding.html`, `jihad-excsel.html`,
`jihad-mse-probe.html`, `jihad-plain-ok.png`.

**Traps found today.** (1) A verify run's frame rate is not the path's: `JIHAD_GPU_VERIFY=1` composes and reads
a whole reference per job (5-6 fps on a 30 fps page); the first sweep had to be run again without it
(memory `verify-runs-are-not-measurements`). (2) The device's `/etc/hosts` ends without a newline: a line
appended with `>>` glues onto `palm-webos`, the mapping fails, and the card then sits under a "connection was
refused" dialog while the daemon takes no inject for a while — append with a leading `\n` and check with
`ping -c 1 <name>`. (3) EasyList carries `@@://192.168.$generichide`: a test page served from the host PC's
address gets no generic hiding; serve it under a host name mapped in `/etc/hosts` (`jihad.test`). (4) The inject
channel's `gettext` passes its argument straight to `querySelector` (no `sel:` prefix, unlike `rect`), and a
`jsurl javascript:` whose completion value is a string replaces the document — wrap it in `void(...)`. (5) The
lists load on the first card connect (the cache in about a second): a page launched with the card has its
requests judged before they are ready, so a blocking test waits for the `blocker: cache:`/`compiled:` line first.
(6) Mojo launched with `target: about:preferences#pane=privacy` shows an empty card; the pane is reached through
its test hook's `U` step.

**Commits — MADE (T-521, 2026-10-24 13:49) AND PUSHED by the owner (13:5x, `.cavekit/handoff-2026-10-24/push.sh`: engine fork `706d4782..7a872e8f`, Jihad-Browser `62df604c..de4fb43c`, both read back equal, the pin public).** The owner's rule, 2026-10-24: the Gitea token and the
`id_ed25519_gitea_signing` key serve `git.trueog.net` / `git.true-og.net` only (memory `gitea-credentials-are-gitea-only`);
the two GitHub repos commit unsigned (`commit.gpgsign false` per repo in Jihad-Browser and `third_party/uxp`), so
no prompt. Engine fork `7a872e8f` (patch 0058: the review fixes), Jihad-Browser `506c4114` (A: T-487), `3f4e1a27` (B:
T-513/T-499 with the fold, the pins and the gitlink; `check-engine-pins.sh` all agree, the 58 patches reproduce the
pin), `318869f2` (C: Tier 88) and the records commit after it. The chain and its message files stay in
`.cavekit/handoff-2026-10-24/` (git-ignored). The push was the owner's (the engine fork's remote is `fork`; GitHub access is the `id_optiplex_new` key, a passphrase per connection): `push.sh` pushes the engine first, then main, reads both back, runs `check-pins.sh`.
The 807 untracked jpg/log/png dumps of the 2026-10-19 rounds (42 MB, none cited by a doc) were deleted on 2026-10-24 at the owner's word: clear screenshots when they are no longer needed.

## 2026-10-19 (night) delta — T-513, T-487, T-499 done; the verify mode's reference; the layout viewport per document (READ FIRST)

**2026-10-24 (the session resumed after the weekly limit).** Codex reviewed the whole of it and found nine
more problems, all fixed (`context/impl/impl-review-findings-gpu-2.md`, C1-C9): late writes on the
engine's opt-in read paths, the previously shown buffer reclaimable by the 2 s valve, the verify pool,
the document key (now the inner window's id), the adapter's window bound, the inject threads, and the
spike scripts' daemon waits and restore order. The bench runs that build: engine (patch 0058), daemon and
the three rebuilt adapters (installed in /usr/lib/jihad/<v>, LunaSysMgr restarted). Re-run on it: two
cards 22 frames and six flicks 40 frames, 0 rows wrong; the probe page's rotation and navigation; the
three default checks. **Commits:** the owner turned on SSH commit signing on 2026-10-21 (memory
`commits-are-ssh-signed`); the engine commit waited on the passphrase prompt, and the two Jihad-Browser
commits (T-487; T-513/T-499) are written up in the session, not yet made. The registry has no unblocked
task left: the finger rounds, the tabs tier (set aside by the owner) and T-504/505/511/517 (the circuit
breaker) are the owner's.

**T-513 (the review of Tier 87) done.** Codex was out of credits; two inspectors reviewed the tier and found
12 problems, all fixed (`context/impl/impl-review-findings-gpu-2.md`; the worst: every card close left ~16 MB of
GPU memory in the share group, and the express lane could compose into the buffer the card shows). Twenty card
open/close cycles add 76 KB (R10). R2's new criterion, a fast flick and two cards panned in turn under
`JIHAD_GPU_VERIFY=1`, passes: 40 flick frames with shifts to 1200 rows and 26 two-card frames, 0 rows wrong.
It first "failed" by 744 rows: the verify mode composed its reference at the job's poll, after the flick had
moved the displayport on, so the reference lacked tiles the published frame had (the frame was right, by eye).
The reference is now posted right behind its job on the same layer tree (`gpuJobStart`, a static pool of four
buffers never freed, because a given-up compose can still be read into its buffer late). New round tools:
`tools/device/t502/two-cards.sh`, the inject channel's `target focus|last` (`JihadBrowserServer.cpp`), the Enyo
hook's `A` step (bring the other card to the front). Notes `docs/rounds/t513-2026-10-19/`.

**T-487 (the blocklist updater) done** on the Enyo card: a forced update (EasyList and EasyPrivacy 2026-10-19 over
HTTPS; a rule only in the new EasyPrivacy blocked the next page's image), the network off (two "no download"
lines, nothing changed, no dialog), no repeat within 4 days or within a day of a failure across restarts. Two
bugs found and fixed in `jihadContentBlocker.js`: EasyPrivacy was refused as "truncated" on every update (held
against both lists' rule count), and a due update skipped at the timer's one early look waited six hours.

**T-499 (the layout viewport) done.** Three changes on top of daemon 17's rule: the card's own size resent (every
NPAPI SetWindow) keeps a followed layout viewport (it used to shrink to 768 and grow back each time); the layout
viewport is the document's (`GoannaRenderPage::DocumentKey`/`ResetLayoutSize`: a new document starts at the
card's size, so a device-width page after a followed one is no longer laid out at 1000 and shown at 0.77); and
the rule waits for `readyState` past "loading" and never follows about:blank (mid-parse the engine lays a page
out at 980 as if it had no meta viewport, and a device-width page was followed to 980). Probe page with rotation
and navigation, BBC, YouTube mobile, Wikipedia, DuckDuckGo: `docs/rounds/t499-2026-10-19/`. NB DuckDuckGo now
declares `width=device-width` and its menu no longer shows, so the rule (no meta viewport only) does not apply
to it any more; the probe page keeps the original geometry.

**Traps found tonight.** (1) The bench's Wi-Fi flapped for an hour (link up for seconds, gateway unreachable,
"could not be found" and one `SSL_ERROR_RX_MALFORMED_SERVER_HELLO` from DuckDuckGo that a retry cleared); a
`palm://com.palm.wifi/setstate` off/on brought it back for a while, and it settled by itself later. Check
`ping -c 1 duckduckgo.com` on the device before reading a failed load as ours. A daemon that met the outage kept
failing loads to the LAN ("connection refused") until the network was steady again. (2) A spike's
`jihad.viewport.followOverflow=false` stayed in the shipped Enyo profile for hours: a daemon still exiting saves
its prefs over an edit. `gpu-spike-start.sh`, `gpu-spike-collect-stop.sh` and `set-prefs.sh` now wait for the
daemon to be gone before they touch `prefs.js`. (3) Several cards from successive test launches each connect to
the daemon (a launch into the running app opens a new card); a "page init FAILED ... shm resolve" line is a card
already gone. Close the cards between runs.

## 2026-10-19 (evening) delta — T-505/T-511/T-517 blocked by the circuit breaker; T-512 diagnostics gated (READ FIRST)

**Where the frame floor stands.** Desktop Wikipedia's 10 s scripted pan runs 23.2-24.1 fps since engine
0055/0056 (rounds 346-357). Tried tonight and not kept, each measured on the same pan: deferring the
page's tile uploads to the composite (a new texture's conversion then costs 11 ms inside the render
pass), a texture pool topped up ahead (6-7 ms a conversion), partial tile uploads as sub-images
(`gpu-bench.c` section 18: cheap with the GPU idle, but only 38 of a pan's 167 uploads are small), the
express lane on its own slot for every frame. `JIHAD_GPU_READ_FINISH=1` shows why the copy cuts do not
pay: after the 12 ms base copy the GPU still has 5.3 ms of the band frame's compose left (~17 ms of GPU
work a frame), with both cores full (the bench's `sensord` at ~18 % of a core, from the Atlas browser's
`atlas-sensord`). The 480 px WebGL cube reaches the card at 19.5-20.9 fps against the page's own
23.8-25.1 (round 358). T-505, T-511 and T-517 are `blocked` in the registry under Cavekit's circuit
breaker: the owner's finger round (T-514) judges smoothness, and running the bench without
`atlas-sensord` is the owner's call. Notes: `docs/rounds/t502-2026-10-17/floor-r314-320.txt` (rounds
349-357), `webgl-r281-313.txt` (358), `bench18-r355.txt`; `context/impl/dead-ends.md`.

**T-512 (part, `e8b0e425`).** The `[jihad-gpu]` lines print only with `JIHAD_GPU_LOG=1` or a device
round's `JIHAD_GPU_TIMELINE`/`VERIFY`/`DUMP_EVERY` (engine 0057, `mozilla/gfx/JihadGpuLog.h`; the daemon's
`render/goanna/JihadGpuLog.h`): a shipped daemon logs three engine startup lines. `default-check.sh` counts
the express lane's frames from the `page closed: <n> frames` line; all three interfaces pass on the bench
(bundle 49ad5cf7). `gpu-spike-start.sh` sets `JIHAD_GPU_LOG=1` (`NOLOG=1` not). The bench's three variants
run this build.

**Registry.** T-517 added; T-512 no longer waits on T-504/T-505/T-511/T-517 (T-504 -> T-514 -> T-513 ->
T-512 was a cycle). Next: T-513, Tier 87's review (Codex by direct invocation, the inspector as backup).
The session that ran rounds 349-354 died mid-build: a build started from a session must be detached
(`setsid nohup`), or it dies with the session.

## 2026-10-19 delta — T-515: frames made off the main thread, the express lane; T-516, T-510, T-511 (READ FIRST)

**What it is.** With `JIHAD_GPU_EXPRESS=1` (and the GPU path) each card's YAP commands are read on a
thread of the proxy's own (`render/browserserver/Yap/YapProxy.cpp`), and the daemon's frame
bookkeeping is under one frame lock (`render/goanna/JihadFrameLock.h` explains it) that the main
thread lets go of only in the engine's pump and in a frame's layer paint. An express thread
(`BrowserPageGoanna.cpp`, `expressStep`) composes the layer tree as it stands at the card's newest
scroll and zoom and publishes the frame itself: while the card moves it makes every frame (the main
lane paints layers and moves the anchor), and otherwise it fills the main thread's stalls. Engine
patch 0048 splits the frame's paint from its compose post and lets any thread post and poll jobs.
It is ON by default since T-510 (same day), with the GPU path: the three upstart jobs set
`JIHAD_GPU_COMPOSITOR=1 JIHAD_GPU_EXPRESS=1`; `JIHAD_GPU_COMPOSITOR=0` or `user_pref("jihad.gpu.enabled",
false)` in a variant's profile give the software path (the daemon reads them before the engine starts and
logs "rendering: ..."). The bench's /etc/event.d jobs were replaced in a remount window (/ back to ro).

**What it did (rounds 240-267, `docs/rounds/t502-2026-10-17/express-r240-267.txt`).** A zoom while the
page's script holds the main thread: Wikipedia after its load 10/10 within 160-225 ms (without the
lane: median 681 ms, max 1116, three zooms never framed); a page holding the main thread 600 ms in
every 700 (`render/goanna/test/jihad-script-hold.html`) within 45-91 ms (without: median 450). That
page pans at 26-32 fps (2.4-3.8). Desktop Wikipedia pans at 19-21 fps: the page's 2.2 s restyle now
runs under frames every ~45 ms, and the floor is the compositor thread's ~45 ms a Wikipedia frame
whichever lane asks (T-517). Card double taps 40-449 ms: the slow ones are GPU draws of the other
resolution's tiles after a zoom in (T-516). No regression with it off; clean daemon exit.

**Traps.** (1) Two locks: the frame lock (the main thread, the express thread, the inject threads)
and the want lock (the reader thread's scroll and zoom; never held while waiting). The reader
thread never waits for the frame lock: a proxy's teardown joins it (a returned buffer tries for 4 ms
and is left to the main loop). (2) With the lane on, the inject channel's `pan` and `zoom` go
through the card's own path on a thread (`zoom <z> <x> <y> [delay ms]`), so they arrive while the
main thread is busy; without it they are applied in the tick as before. The inject file itself is
read only when the main thread is free. (3) "Served" is by command, not by position: commands are
tagged in arrival order by the proxy and the main lane serves the card once its frame took up the
newest (the engine clamps and rounds positions; comparing them made the lane redraw every frame).
(4) A main-lane frame posted before an express publish is dropped at its poll; one at a zoom the
main loop has not taken up yet is held (300 ms at most). (5) `JIHAD_GPU_ZOOM_DUMP=<path>` frames are
3-4 MB each on a 40 MB `/tmp`: use `JIHAD_GPU_ZOOM_DUMP=log` for timelines, delete files at once.
(6) A scripted pan's screenshot is meaningless (the card's own scroll does not move); judge by the
dumps, `JIHAD_GPU_TIMELINE=1` and the paint pipeline lines.

**T-516 (same day, partial).** The double taps' slow first frames were not draws: the first readback
after a pause ran 100-390 ms and the CPU swizzle 20-122 ms (the clocks after two idle seconds and
the engine's other threads). The YAP reader now raises the clock hold on a scroll, zoom or smart-zoom
request, and the Compositor and JihadExpress threads run at nice -6: double taps over 250 ms went from
4-8 of 12 to 0-2 (median 158). Left: the GPU's ramp after a pause. A warm-up frame was tried and
made it worse (dropped). Engine 0050: the timeline logs every job, compose and read.

**T-510 done (same day).** The default as above; `tools/device/t502/default-check.sh <variant>` loads,
pans, pinches and closes Wikipedia through each card's self-test hook on its own upstart daemon: all
three pass. NB: the shipped jobs carry no `JIHAD_INJECT`; inject-driven rounds use the hand-started
daemons (`gpu-spike-start.sh`), as before.

**T-511 (same day, partial): WebGL.** On the GPU path `getContext("webgl")` gets a context on the
Adreno through EGL (engine 0051); on the software path it stays null. Every pbuffer context on the GPU
path is in one share group, so a canvas's texture is composited with no copy (the driver has no
EGLImage from a GL texture). The spinning cube (`render/goanna/test/jihad-webgl-cube.html`) renders
right; 8 card open/close cycles and a context lose/restore without a fault (the fault before: a
destroyed context left current; released first now). Card rates: 240 px cube 26.5-27 fps, 360 px
21.5-23, 480 px 18-20.5 (the page draws 21.5-25): the compositor job's ~45 ms for a 482-row change,
the same floor as Wikipedia's frames, carried by T-517. Engine 0052 reads a narrow change's bands as
one column (44 against 47 ms a job); an adapter that invalidates only the changed strip measured +12 %
(not kept: it needs a side channel for the rect). Rounds in `docs/rounds/t502-2026-10-17/webgl-r281-313.txt`.

**Traps found 2026-10-19.** (1) `/var` full: the adapter's paint log gate (`/var/palm/jihad/enyo/adapterlog`,
set by `adapter-install.sh` on 10-17) grew the log to 46.7 MB of /var's 62; the daemon's main thread then
sat in `log_wait_commit` after its first frame (no frames, cards that would not close, loads aborted
0x804b0002) and a day of WebGL teardown runs looked like engine faults. The script no longer sets the
gate; when a run turns strange, `df -h /var` and the D-state threads' `wchan` first. (2) The adapter
(PDK gcc 4.3.3) had not built since T-515 (`<mutex>`/`<atomic>` in `YapProxy.h`): pthread locks now; the
three adapters build, the bench's Enyo one is the new build. (3) On the bench `sensord` runs at 15-23 %
CPU and `atlas-sensord` at ~3 % all the time (sensord has 389 CPU minutes): not ours, and it is a core's
fifth during every measurement.

**T-517 (same day, investigated).** A Wikipedia pan frame with the sticky panels' column chunks takes
40-46 ms on the compositor thread, one without 18-27: the two pinned panels are see-through sticky layers,
composed again every frame in 3-4 chunks of the 256-row band surface, and every pass costs ~5 ms of CPU
whatever its area. Both cores are full during a pan (the daemon ~1.5 cores, WebAppMgr ~18 %, and sensord
~18 % beside the Atlas browser's `atlas-sensord`, all the time). Tried and reverted: the shift on a worker,
the whole path, one main-thread notification a frame. `pan-run.sh` takes `PAN_TOP=1` for the CPU split.
Notes in `docs/rounds/t502-2026-10-17/floor-r314-320.txt`.

**T-517 (later the same day, partial).** Two cuts kept. The frame rows' cache clean is skipped where
the segments are mapped write-through (they are; the clean was 4 ms a frame). Frame windows: a frame may
start further into its shared segment (`render/browserserver/Src/JihadFrameWindow.h`: a 64-byte trailer
at the segment's end, written by the daemon before each publish, read by the adapter's
`BrowserOffscreen::rasterBuffer()`; only an adapter that marked the segment it made gets non-zero windows),
so a scrolled slot's frame is its window moved, not 3.7 MB of rows moved (engine 0053). Both lanes now keep
every slot's stale rows (the express lane used to drop them on each publish), and the express lane builds
on its own slot's frame when that measures faster. Long test page 30.5-36.4 fps (median gap 29 -> 26 ms);
Wikipedia still 19-21. **The bench's three adapters are the window-aware build** (installed by hand from
`build/webos-oe/adapter-deps/build-pdk/<v>/`); a package built before this commit would carry old ones and
the daemon would keep windows at 0 (correct, just slower).

**Review and T-504 (later the same day).** An inspector review of the day's work found six real problems
(the express lane's own-slot base racing unpolled main-lane jobs, the kept rects' copy, older bases with
sticky layers, failed jobs' records, a recentring before a failed post, WebGL after a GPU give-up); all
fixed (`context/impl/impl-review-findings-gpu.md`, engine 0054). Scripted double taps: 2 of 18 first
frames over 250 ms (286, 367), with the second core unplugged after a pause; the scripted tap skips the
touch path's governor ramp, so a finger's tap goes to the finger round. T-504's own token budget (the
plugin's 45k default) is spent: raise it in `.cavekit/token-ledger.json` to continue it. Failed approaches
of the day: `context/impl/dead-ends.md`.

**T-517 (evening).** Engine 0055 composes a band frame's regions (its bands and the sticky columns'
chunks) in one composite instead of one each, and 0056 skips tiles that miss the clip before locking them:
chunked Wikipedia frames compose in 10.6 ms where they took 22.5. The 10 s scripted pan runs 23.4-23.9 fps
(20.0-21.7 before); the remaining long gaps are the page's own work (tile uploads queued ahead of the
express frame on the compositor thread, its script on the other core). The README now has a "Where it
stands" section generated by `tools/readme-progress.py` from the kits: run it after a criterion is met.
T-504 is marked blocked in the registry (`.cavekit/task-status.json`) on the finger round.

**Next.** T-517: Wikipedia's sticky columns. A rule that kept see-through sticky columns once proven still
was tried and reverted (round 333: the contents panel's highlight follows the reading position, so it does
change during a pan); what is left is fewer passes (one tree traversal for all of a frame's regions). Then T-512 (fit to
keep), T-513 (review). Knobs in `tools/device/t502/README.md` (the T-515, T-516, T-511 and T-517 paragraphs).

## 2026-10-18 (night) delta — T-385…T-387 done, T-504 (zoom) mostly done (READ FIRST)

**Engine-update readiness (T-385…T-387) done** and reviewed (the inspector, Tier 74: APPROVE, the
four P2s and the cheap P3s fixed, `context/impl/impl-review-findings-6.md`). The desktop engine
builds on RB_20261006 again (patch 0043); desktop tests `personas` 7/7, `media` 18/18, `prefsui`
38/38.

**T-504, zoom (rounds 162-186), the owner's "areas turn grey and zoom rendering lags":**
- *The zoom hold:* on a zoom only the compositor's world transform and scroll change; the
  displayport and the engine's anchor follow once a frame at the new zoom is out (or 800 ms). On a
  settled page the first frame at a new zoom now comes 52-217 ms after the command (was 1.2-1.75 s).
- *A grey strip, zoomed in:* the pan's settle moved the engine to the card's x, which a page whose
  scroll port does not scroll sideways cannot reach (desktop Wikipedia at 1.23: x 245 CSS px), and
  published frames at x 0 under a card at x 302. The compositor keeps the scroll the engine cannot
  reach now.
- *Tile uploads (engine 0044):* the "upload waits behind the GPU" of T-502 was wrong. On the Adreno
  220 the **first write into a texture after its first draw** costs ~18 ms per 256x256 (proportional
  to the size: 75 ms at 512, 285 at 1024), any format, once per texture; later writes cost ~1 ms,
  under a queued draw too; a regenerated name pays again; the conversion survives a re-specification
  at another size; a clear of the texture through a framebuffer triggers it without a wait
  (`tools/device/gpu-bench.c` sections 11-16, `BENCH_ONLY=<n>`). New tile textures are converted at
  1x1 (1-2 ms) and textures are pooled (`JIHAD_GPU_TEX_POOL`, 48). Wikipedia: 55-59 slow re-uploads
  a zoom run (24-37 ms average) down to one. The pans gained too: desktop Wikipedia at its fit zoom
  19-25 fps (T-503 left it at 16.4-18.5).
- *Sharp zoomed text:* above a zoom of 1.1 the pres shell's resolution follows the zoom (no
  scale-to: layout adds a post-scale, the geometry is unchanged), so tiles land one to one on the
  card; below 1.1 the 1x paint stays (a fit zoom's resolution paints fewer pixels but resamples
  every image and glyph on the CPU: the Wikipedia pan lost 3-5 fps). `JIHAD_GPU_NO_RES=1`.
- *DEAA (engine 0045):* Gecko's edge antialiasing is on for any non-integer transform, a scale too;
  its shader variants compile on first use, ~150 ms each on this GPU, and the first frame of a zoom
  compiled two. No DEAA for axis-aligned scales on the GPU path (`JIHAD_GPU_DEAA=1` restores it).
- *Tools:* the Enyo test hook's `t<x>,<y>` is a double tap (the adapter's smartZoom);
  `JIHAD_GPU_ZOOM_DUMP=<path>` keeps the frame the card shows after each zoom; `JIHAD_GPU_PHASES`
  logs slow composites and draws.

**Open on T-504 (with T-505):** while the page's own script holds the main thread (desktop Wikipedia
runs its modules for ~10 s after the load event) the daemon cannot read the zoom command at all:
the first frame then takes 0.8-1.7 s, and pans stall the same way. The fix is frames made off the
main thread (the compositor thread composes with the card's scroll and zoom and publishes itself);
that is T-505's work, and it closes T-504's criterion.

**T-505 (rounds 187-201):** the per-page table (the GPU path ahead everywhere: the test page 30-35
fps against 2.7-3.2, sticky-mix 17-19 against 2.4-3.1, desktop Wikipedia 19-26 against 2.7-2.9,
Hacker News 31-37 against 6.4-10.4). The 56 ms+ gaps are the page's own restyle on the first scroll
(Wikipedia's sticky header, 955 ms), the paints of the displayport moves (58-121 ms) and short page
events; the compositor itself floors at ~30 ms a frame on Wikipedia (one composite per band and per
sticky column chunk, the row shift, the read). **Overscan** (engine 0046): the GPU frame carries 0.15
of the card's height above and below the view, so a pan or a busy main thread shows the page past
the view's edges, not grey; verify is clean on four pages; it costs ~10% of the rate. The frame is
capped at 1400 rows (the compositor's first pbuffer: a taller frame read its top rows from the
bottom ones, flipped). Wikipedia at 24 fps needs **frames made off the main thread** (T-515, new):
an IPC thread reads the card's scroll and zoom, the compositor composes and the frame is published
while the main thread runs the page's script or a paint (the YAP proxy's sends then need a lock,
the job state too, and the adapter's buffer returns must reach that thread).

Traps found: the card's flick step (`f`) does not move a page (only a finger pans; the injected
`pan` does); the device's `/tmp` filled with stale `.raw` dumps from earlier rounds and every
`dev-sh.sh` then failed with "No space left on device" (remove them with `novacom run
file:///bin/rm -- -f <each file>`; a `-c` string is split by novacom); a zoom injected through
`inject.cmd` is not seen by the card (its frames are scaled to the card's own zoom).

## 2026-10-18 (evening) delta — the GPU path under Cavekit: Tier 87, T-503 done (READ FIRST)

**The owner:** after a finger test on the GPU path (*"areas turn grey and zoom rendering of page
content lags behind actual page zoom state"*; it ran on a hand-started diagnostic daemon while a
scripted pan was going, see the memory `owner-tests-clash-with-pan-runs`), *"continue using cavekit
3.1 to finish the implementation"*. The GPU work is now a kit (`context/kits/cavekit-gpu-rendering.md`,
R1-R12), Tier 87 of the build site (T-502…T-514) and the registry (`.cavekit/task-status.json`:
Tier 87 added; T-363 closed because the owner moved Codex's owed reviews to the inspector on
2026-10-13; T-366/369/370 closed as the site records; the tabs groundwork T-347…T-353 set
`blocked` by the owner's 2026-10-06 word). Order of the loop: T-385…T-387 (engine-update
readiness), then Tier 87.

**T-503 done (rounds 138-150):** fixed and sticky content at minimum cost, and frames that verify.
- Opaque fixed/stuck layers (the layer or its opaque children cover every pixel it covers) keep
  their pixels from the base frame, per covered rect; only the rows the shift uncovers beside them
  are read. A sliver under 32 rows and every non-opaque one are read as their columns, cut into
  chunks packed side by side on the band surface. `JIHAD_GPU_NO_KEEP=1`, `JIHAD_GPU_NO_FIXED_COLS=1`.
- The draw culling never culled: a quad the clip leaves nothing of became a 2x2 rect at the origin
  (60 draws per band pass on Wikipedia). `JIHAD_GPU_NO_CULL=1`.
- A sticky layer the engine already laid out stuck (an anchor move zeroes the async offset) counts
  as stuck: its sticky ranges are probed with a step both ways (a stuck sidebar slid with the
  content for a frame after every anchor move).
- The root composition on the GPU path covers what the card shows (a page laid out wider than its
  window, Hacker News at 0.955: the card shows 804x986 CSS px of a 764x942 scroll port, and the
  bottom 42 rows and right 38 columns were clipped blank, then carried up by every pan), and the
  page gets a displayport of what the card shows from the start and at every zoom (the pan slack
  only from the first pan).
- `JIHAD_GPU_VERIFY=1` is trustworthy now: its whole composite changes nothing the next frame reads
  (it consumed anchor moves' changes and the next frames kept stale rows), it skips frames made at
  another zoom, and it reports rows **structurally wrong** (16-row blocks that sit better at another
  row offset or differ heavily at every offset) apart from sub-pixel resampling (a fractional
  scroll resamples sharp text by a few levels; a tile seam by one pixel). 0 structurally wrong rows
  on `jihad-long-static.html`, the new `jihad-sticky-mix.html` (opaque header and footer, a
  transparent sticky sidebar over stripes), desktop Wikipedia and Hacker News.
- `JIHAD_GPU_PHASES=1` times a composite's phases; `JIHAD_GPU_BAND_ROWS=<n>` sizes the band surface;
  `tools/device/gpu-bench.c` section 10 (column reads cost by the pixel).

| Page (scripted pan, `pan-run.sh`) | GPU path | Software path |
| --- | --- | --- |
| `jihad-long-static.html` | 27-34 fps | — |
| `jihad-sticky-mix.html` | 15-17.5 fps | 0.9-3.1 fps |
| desktop en.wikipedia.org (`PAN_DELAY=12`) | 16.4-18.5 fps (was 13-14) | 9-12.4 fps |
| news.ycombinator.com | 34-37.5 fps | — |
| `jihad-anim-css.html` (no pan) | 24-32 fps | — |

**Next (the loop's order):** T-385…T-387, then T-504 (zoom: the owner's finger test; a zoom-in's
first frame took 1.2 s and later ones 1.7 s, each 256x256 tile upload 12-63 ms behind the GPU's
queue), T-505 (Wikipedia to 24 fps), T-506…T-514.

## 2026-10-17 delta — the rendering pick: 2 + 4, a one-week spike first (READ FIRST)

**End of session 2026-10-17 (rounds 11-86), the state to pick up:** the compositor path draws
correct frames on the card and runs the animation page at **21-27 fps** (the chart's 24 fps row,
the GPU's floor for a four-layer composite plus a readback) and the scroll page at **12-17 fps**
(the chart's row not reached: the daemon scrolls the engine per step, so every frame repaints and
re-uploads content; the designed remedy is a compositor-side scroll inside the painted
displayport). The whole account, the measured table, what is in and what was tried and dropped:
`docs/RENDERING-OPTIONS.md` "T-502, the spike" (rewritten; the round 6-10 frame rates further
down this file were measured on black frames and are superseded). The device scripts:
`tools/device/t502/`. Traps: `docs/RENDERING-OPTIONS.md` (same section) and the memory
`gpu-wedge-needs-a-reboot`.

**Done on 2026-10-18 morning:** the engine's temporary commit is folded into patches 0040 (the
compositor) and 0041 (the Adreno 220's GL), the diagnostics-only files restored; the patch queue
reproduces the pin (`e0c04228`), `check-engine-pins.sh` says all agree; the device's Enyo card runs
the bundle built from that tree (`116788fa`: animation page 21-26 fps, scroll page 13-15); the
branch was fast-forwarded into `main` (the only permanent branch). The owner pushes `main` and
force-pushes the engine fork's `jihad/uxp-RB_20261006` (its history was rewritten by the fold).

**2026-10-18, later (corrected):** the compositor-side scroll is in (engine patch 0042 with the
two-band reads, the band-sized target and the displayport/metadata/surface fixes;
`gpuScrollTo` in the daemon with an anchor; `JIHAD_GPU_ENGINE_SCROLL` restores the per-step
engine scroll). The 17-25 fps pans reported earlier that day were frames whose content moved
only at engine anchor moves; `docs/RENDERING-OPTIONS.md` "T-502" has the corrected account and
the three causes. Verify a pan ONLY with `tools/device/t502/pan-run.sh` (mid-pan frame dumps)
and `JIHAD_GPU_VERIFY=1`; never with a screenshot (the adapter's view does not move in a
scripted pan). The numbers after the surface fix (rounds 95-100, bundle `574ff024`+glFinish): band target
21-25 fps, whole reads 19 fps, header still and at rows 0..44, the compositor's whole frames at a
pinned scroll correct (`verify2b-*.jpg`).

**Rounds 99-112 (2026-10-18, later): the white rows found and the pan made fast.** The "one
composite in five white below row 484" was the Adreno 220 driver binning an FBO render by the
EGL SURFACE's size: the frame (942 rows) composed into an FBO while the 1100x1400 pbuffer was
current lost its bottom 1400-942 = 458 GL rows in some composites (every quad drawn, raw scissor
and viewport correct, `glFinish` and a second read no help; a magenta clear proved those rows were
never rasterized). The context's pbuffer is now the frame's size (`JihadUsePBufferOfSize`), and the
rule is: every render target and viewport the same size as the current surface. Scroll-only
frames compose their bands stacked on their own 768x256 pbuffer and FBO (`JihadBeginBandPass`;
the switch INTO that surface costs 11-13 ms, so it stays current between band frames and a whole
composite switches back), the 2.9 MB row shift runs while the GPU works, the compositor wakes the
daemon's loop through a pipe the moment a job finishes (`jihad_offscreen_set_done_fd`), and the
displayport is set from a page's first pan only (a still or animated page paid for 3.5 viewports
of painting). The compositor-side scroll is engaged by a card-driven pan only and settles 300 ms
after it (the engine scrolled to the card's position, the async scroll off); a scroll the page
makes itself is followed as before. Also fixed: two reads of a job after its hand-off (a
use-after-free race the wake pipe made frequent), and round 91's "a tree change makes the other
slots stale whole" (an animated page read whole frames every frame).

Measured on the bench (CE 3.1.0), frames verified by the dumps and by eye:

| Page | Frame rate | Note |
| --- | --- | --- |
| `jihad-long-static.html`, scripted pan 0 → 3000 card px in 10 s | **27-32 fps** | frame gaps mostly 24-31 ms; header still; no white or repeated rows |
| `jihad-anim-css.html` | **26-31 fps** | the diff first, then only the changed rows composed on the band surface (round 119) |
| `jihad-scroll-js.html` (the page scrolls itself) | 13.5-17.4 fps | the shift from the diff, the displayport from its first scroll, small steps on the band surface; the card lags the page's scroll (pre-existing) |
| news.ycombinator.com (1249 CSS px tall: the scripted pan overshoots its end; the real card clamps) | 36-37 fps | frames right up to the page's end |
| www.bbc.com/news, github.com | 0.2-2.4 fps, and 0.1-1.7 on the software path | the page itself (script, layout) holds the main thread on this CPU; not the compositor |
| **en.m.wikipedia.org/wiki/HP_TouchPad** (redirects to the desktop site), the same pan after 12 s of loading | **13-14 fps** (software path: 9-12.4) | correct only since round 132-134 (before, the right third and the bottom were never painted and a sticky header doubled); stuck sticky sidebars are ~540 fixed rows re-read every step |

Rounds 129-134 (the real page, correctness): on a page laid out wider than the card (the desktop
Wikipedia at a fit zoom of 0.69: a 1116x1374 CSS px scroll port) the root scroll frame clipped to
the COMPOSITION size, the engine window (764x942): the GPU path never showed the right third or
the bottom. The root's composition is its scroll port on the GPU path now
(`CalculateCompositionSizeForFrame`); the displayport base is set to the scroll port every time and
its margins cover what the card shows plus the anchor slack; the fixed rows read again are widened
by the shift (the base frame's fixed pixels land just above them on a scroll down: a sticky
header showed twice); a second job builds on the job in flight (exact while scrolling, round 130).
The dump counter restarts with a scripted pan, so `pan-run.sh`'s dumps are mid-pan.

Rounds 126-128 (a real page): the displayport is 0.5 heights up and down and none sideways unless
zoomed in (`JIHAD_GPU_DP_Y`, `JIHAD_GPU_DP_X`); the 1.25-height one painted ~95 tiles on an
image-heavy page at a fit zoom of 0.69 and every tile upload waits behind the GPU on this chip
(one composite 300 ms, a job 3 s). The anchor is 0.25 heights. Only sticky layers the compositor
holds in place count as fixed rows, and band frames recompute the fixed rows at their end. **Test
every GPU change on a real page against `NOGPU=1` on the same pan** (`PAN_DELAY=12`).

Rounds 118-119: a page that scrolls itself gets the displayport too; a frame whose tree changed
takes the layer diff first, without a render (`JihadDiffNow`: the composite's own steps up to the
diff, the stored tree refreshed), and when the changed rows, the asked bands, the entering band and
the fixed rows fit 256 rows it is composed on the band surface like a scroll-only frame. Also
fixed: the round-115 shift was cleared before the bridge could read it (the daemon's own estimate
had been carrying it). Open: an engine anchor move during a pan still diffs as every row changed.

Rounds 115-117: the layer-tree diff treats the root-content layer's pure vertical translation
as a scroll (`JihadDiffScrollBegin`/`JihadDiffScrollShift`, LayerTreeInvalidation): the engine
shifts the kept rows by it and reports the frame's position back, so a page's own scroll reads
the entering band, not the frame. The diff region is now scaled by the world transform (it was
in the root layer's CSS px: on a fit-zoomed page an animation's changed rows were composed and
read at the wrong rows). The two-deep queue reads the composed job's changed rows (it lost them
before) and is used only when nothing scrolls.

Round 113 builds each new frame from the NEWEST finished slot (copied with the scroll since it,
only the entering band read; the fixed rows only when the scroll moved), unless the slot's own frame
is at the same scroll with little stale (an animated page). Measure a still or animated page with
`tools/device/t502/pan-run.sh <name> <url> "<words>" none` (12 s, no inject).


**Left, in order:** (1) the owner's finger test of a real pan and flick (the entry is in
`docs/FINGER-TESTS.md`); (2) the pan's remaining long gaps (56 ms+, 2-8 per 2 s window): not the
anchor moves any more (round 124: the painted region reaches the compositor as the region, not
its bounds, and changed regions are clipped to the frame before their bounds, so an anchor move is
a 46-72-row band frame) and not the anchor size (0.15/0.3/0.6 heights alike, round 125); one tick
showed a 101 ms gap between ticks with no pump or paint, i.e. another main-loop source: trace the
loop uncapped (the tick log stops at 120); (3) fixed rows as two intervals (a page with a fixed
header AND a fixed footer reads the whole frame on every pan step); (3) a fourth shared buffer for the
two-deep frame queue; (4) a damage rectangle in the frame header so the adapter invalidates and
LunaSysMgr uploads only the band; (5) option 2 (WebGL through EGL); (6) prune the `[jihad-gpu]`
diagnostics that remain in the engine and the daemon (bounded, cheap; the verify mode and the
dumps stay, they are the test). The device: the Enyo card carries the probing adapter (stock as
`BrowserAdapterImpl.so.orig`); Mochi and Mojo untouched; host servers 8077/8078 still running.


**The owner, this morning:** the rendering report (the Claude doc "Jihad rendering options: speed
comparison", https://claude.ai/code/artifact/6436a954-170a-48b2-8b35-e87dc4b3fbf5; the same tables
in `docs/RENDERING-OPTIONS.md`) was cut down step by step: dominated combinations out, 6 (CE-only
LunaSysMgr change) and 2-without-4 (11 fps WebGL) advised against, rows under 24 fps scroll out,
rows without WebGL out; a Flash games column (Flash's own 27 / 22 fps bounds every row; the
movie-sized GPU readback and upload were measured for it: `tools/device/gpu-bench.c`, 4.9–6.3 /
1.9–2.3 ms and 1.8 / 0.55 ms), a webOS column (every survivor runs on 3.0.5 and CE 3.1.0), colour
chips, a compare-and-contrast of the last two. Then the owner's answers to the choosing questions:
video sometimes, 24 fps video acceptable, styled video matters (fades, rounded corners, video under
a modal: the overlay cannot do these), no date, spike first. **The pick: 2 + 4** (GPU compositor
with readback, then WebGL through EGL). 5 is held back as a full-screen-only overlay if 24 fps
full-screen displeases by eye.

**T-502, the spike (week 1):** the OpenGL compositor up in the headless daemon on the device, one
real frame of a page read back into the YAP buffer and shown on the card, timed against the 42 ms
model. Everything it needs is upstream code; the entry points, all verified in `third_party/uxp`:
- OMTC on: drop `JIHAD_DISABLE_OMTC=1` from `packaging/event.d/{jihad,jihad-mochi,jihad-mojo}`
  (the override in `gfxPlatform::UsesOffMainThreadCompositing`, patch 0003, then does nothing).
- The widget: `PuppetWidget::GetLayerManager` (patch 0005, `widget/PuppetWidget.cpp:635`) takes the
  BasicLayerManager branch under `JihadOffscreen()`; the spike adds a branch that calls
  `nsBaseWidget::CreateCompositor(w, h)` (`widget/nsBaseWidget.cpp:1292`, in-process through
  `GPUProcessManager::CreateTopLevelCompositor`, a `ClientLayerManager`).
- Acceleration: `AccelerateLayersByDefault()` is false in this build (`gfx/thebes/gfxPlatform.cpp:2126`,
  no `MOZ_GL_PROVIDER`); `layers.acceleration.force-enabled` or `--with-gl-provider=EGL`; and
  `gfxPlatformHeadless` must list `LAYERS_OPENGL` among its compositor backends (check
  `GetAcceleratedCompositorBackends`). The headless `GfxInfo` answers UNKNOWN, blocks nothing.
- The GL context: `CompositorOGL::CreateContext` (`gfx/layers/opengl/CompositorOGL.cpp:106`) with
  `MOZ_LAYERS_PREFER_OFFSCREEN=1` calls `GLContextProvider::CreateOffscreen` = an EGL pbuffer
  through `GLContextProviderEGL` (the headless build's default provider, `gfx/gl/GLContextProvider.h`;
  `GLLibraryEGL` loads `libEGL.so` by name, the vendor library `gpu-bench` already drove).
- The readback: `CompositorOGL::EndFrame` copies to `mTarget` when one is set (`CopyToTarget`, the
  measured `glReadPixels`); `CompositorBridgeParent::ForceComposeToTarget(DrawTarget*)`
  (`gfx/layers/ipc/CompositorBridgeParent.cpp:1267`) is the entry; from the main thread the upstream
  road is `ClientLayerManager::BeginTransactionWithTarget` → `MakeSnapshotIfRequired` →
  `SendMakeSnapshot` (sync) → `RecvMakeSnapshot` → `ForceComposeToTarget` into a shmem surface the
  client copies to the target: i.e. a `jihad_offscreen_render_region` that paints with a target
  instead of `RenderDocument`.
- Measure: the daemon's existing paint timing lines, per frame, on the device; compare with 42 ms
  (composite 12.9 + readback 12.3 + copy 5.1 + scale 8.2 + Luna 3.8).
What the pick does to the 39 engine patches (0020 and 0035 no-ops, 0003 and 0005 half, 0006 and
0021 change, the rest untouched): `docs/RENDERING-OPTIONS.md`, "The pick".

**T-502 RESULT (the same day, five rounds):** the compositor runs on the Adreno 220 (EGL pbuffer,
`CompositorOGL`, patch 0040 behind `JIHAD_GPU_COMPOSITOR`), composites four layers in 1–5 ms and
animates a CSS transform without main-thread paints; the frame on the device is 54–96 ms against
the 42 ms model because the readback is clock-bound (22–60 ms in the daemon, 12–21 in the bench),
the snapshot road adds 12–18 ms and the swizzle 7–16. THE TRAPS: (1) the bundle's goanna.js
carries `layers.offmainthreadcomposition.force-disabled=true` (the env now wins over it); (2) a
child PuppetWidget's Destroy() tore down the SHARED ClientLayerManager (crash in
BeginTransactionWithTarget; the child only drops its reference now); (3) a glReadPixels from a
TEXTURE-backed FBO costs 370–640 ms on this driver — the stock offscreen GLScreenBuffer is one —
so the spike draws into a plain pbuffer context (no screen buffer; a renderbuffer FBO reads even
faster, 12 ms); (4) `CopyToTarget` flips unconditionally and an offscreen context has no view
flip, so the frame was upside down: the direct read copies row 0 to row 0; (5) the content upload
takes the tiled `glTexSubImage2D` path (180–240 ms a change) — must become whole-texture; (6) the
compositor animates without dirtying the widget, so the daemon needs the compositor's own
"composite due" signal (`JIHAD_GPU_FORCE_FPS` stands in). Numbers, table and verdict:
`docs/RENDERING-OPTIONS.md` "T-502, the spike"; logs and screenshots `docs/rounds/t502-2026-10-17/`.
**Round 6 (the owner said "continue"):** the read on the compositor thread straight into the
YAP buffer (`CompositorBridgeParent::JihadComposeAndRead`, a task posted to the compositor loop,
the main thread waits on a Monitor), a renderbuffer FBO as the window target, PULL MODE
(`CompositorVsyncScheduler::ScheduleComposition` only counts under the env; the daemon pulls a
frame when `jihad_offscreen_compositor_seq` moves — an animation keeps asking after each
composite), and the clock-floor leak (a daemon that dies holding the floor left scaling_min_freq
at 1188000; the probe now takes cpuinfo_min_freq when it finds the floor at the top). Measured:
compose 1.4–4.6 ms, read 7–17 ms, **17–24 fps on the animation page** (`spike-run6-*`).
**Rounds 7–10 (the owner: the chart's numbers are the floor, keep going):** patch 0041 (the Adreno
220 takes whole-texture uploads: `GLRenderer::AdrenoTM220`, `CanUploadSubTextures` false), the
read forces alpha and the daemon samples the nonblank count; 20–31 fps on the animation page. The
compositor path now scrolls through the ENGINE at every zoom (`setZoomAndScroll` /
`setScrollPosition` GPU branches, no render pan) meant to run inside a displayport of a viewport up and
down (`SetGpuViewport`) — found on 2026-10-18 to have failed on every round (`rv 0x80004005`), so
the engine painted the viewport only; the 21–24 fps on `jihad-scroll-js.html` were per-step engine
scrolls with viewport-sized paints. THE TRAP: `nsIDOMWindowUtils::setResolutionAndScaleTo` and
`setScrollPositionClampingScrollPortSize` each black the whole frame on this path (bisected with
`JIHAD_GPU_NO_RESOLUTION` / `JIHAD_GPU_NO_CLAMP`; the displayport was in truth never set, see
2026-10-18; the resolution route is untested since the y-flip and surface fixes), so the zoom is a
WORLD TRANSFORM on the compositor's tree (`jihad_offscreen_set_view(widget, scale, offX, offY)` →
`LayerManagerComposite::JihadSetWorldTransform`, applied in `ComputeEffectiveTransforms`). The
residual visual offset (a pinch-in pan past the layout viewport) is passed as 0 until wired; the
33 ms frame-gap floor seen in the pipeline stats is the adapter's ack cadence (one buffer in
flight), the next thing to look at. The first content frame costs 125–131 ms once (shader
programs linking), not per change as first written.
**Next:** the world-transform zoom verified on the device (the colours page at the card's 0.7837),
the residual offset for pinch-in, the adapter cadence / a second buffer in flight, the GPU clock
(`/sys/devices/platform/kgsl/msm_kgsl/kgsl-3d0/io_fraction`), the daemon's own per-frame work (T-499's layout viewport and the
fit zoom today crop the frame), the plugin and video layers through the ImageBridge; then 2.

**Carried over, unchanged:** daemon 18 (the hold's release fix) built, NOT deployed; FFmpeg libs on
Mochi only; T-499's paint path restoring the card size; the placeholders in the evening delta below.
**Device:** CE 3.1.0, the three daemons as the evening delta left them; `gpu-bench` ran twice more
from `/tmp` and was removed. Host servers on 8077/8078 may still be running.

---

## 2026-10-16 (evening) delta — the README's caveats worked: the stall, H.264, the viewport (READ FIRST)

**The owner:** "fix the stall"; then "move all caveats in the readme into a dedicated caveats section
at the bottom. also change the language to be less corporate advertisement like while still being
2011 era appropriate" (done, `4a76dbae`); then "work to address all of the caveats in the README.md
which can reasonably be classified as solvable problems". The ledger (`docs/MODERN-WEB.md`) has
T-499 (the viewport, built), T-500 (the stall) and T-501 (H.264/AAC) with the numbers.

**T-500, the stall:** the daemon has a stall sampler (`$JIHAD_STALL_SAMPLER=<ms>`,
`GoannaRenderPage.cpp`; resolve with `tools/host/stall-resolve.py` against the unstripped libxul in
the obj dir — addr2line over ten thousand addresses takes ~10 min on the host). 33 stalls resolved:
the pages' own JavaScript (JIT code + the runtime) two thirds, compile (baseline, Ion, regular
expressions) and GC/CC the rest; two 5-s stalls are cycle collections. The clock: Palm's
`ondemandtcl` governor (up_threshold 95, sampling 200 ms, max_tickle_window 3 s) kept the CPU at
192–384 MHz through a page load. **The clock hold** (`JihadBrowserServer.cpp` tick loop, daemon 16/17,
pref `jihad.cpu.hold`): the frequency floor (`scaling_min_freq`, both cores; cpu1 is hot-plugged)
goes to the top while the engine has work, back after 2 s of idle ticks. **THE TRAP OF THE DAY** (a
reboot): writing `scaling_governor` wedged the kernel's cpufreq lock — every cpufreq read and
every `luna-send` hung, `reboot` hung, only `novacom run file://sbin/reboot -- -f` got out; memory
`cpufreq-governor-switch-wedges-the-touchpad`. A floor write is safe (tested with capped reads).
Status: DONE (the build site's T-500 row).

**T-501, H.264/AAC:** `build/webos-oe/fetch-ffmpeg.sh` (host, sha256 pinned) then
`in-container.sh --arm build/webos-oe/build-ffmpeg-arm.sh` → `out-arm/ffmpeg-arm/lib/libavcodec.so.58`
+ `libavutil.so.56` (FFmpeg 4.4.5, H.264/AAC/MP3 decoders and parsers only, LGPL v2.1+, linked
against the toolchain's own sysroot — the Debian one has no crt1.o). The bundle ships them when
built; NOTICE and `licenses/runtime/ffmpeg-COPYING.LGPLv2.1`. Patents on H.264/AAC: the owner's
call, noted in NOTICE. Status: DONE; on 2026-10-19 a device updated only by `push-engine-update.sh` had lost the libraries (every MP4 refused) and the push now carries them: H.264, AAC and MP3 play to the end again.

**T-499, the viewport:** `GoannaRenderPage::SetLayoutSize` + the once-per-page rule in
`emitGeometry` (content wider than the card by 8 px, ≤ 1100 px, no meta viewport; pref
`jihad.viewport.followOverflow`); reset on navigation and on `setWindowSize`. Status: PARTIAL, open: the engine window resizes but the page still reads innerWidth 768 (the paint path restores the card's size).

**Not solvable from here (the README's Caveats say so):** the device scope; the system's own TLS;
WebGL (no GPU driver); Flash's availability; `palm-install`; Akamai's and Reddit's gates;
GitHub's empty parts — its page uses an import map (120 module preloads under it), which the
engine lacks, and GitHub's script policy allows only its asset host, so an import-map shim (which
loads modules from blob URLs) cannot run there: engine work. Mastodon's timeline: not looked at
again (needs a console-on visit). The double-tap/pinch sharpness: PICKUP's 2026-10 note stands
(cause not found).

**Device state (2026-10-16 evening):** superseded — the state the device was left in is in the newest delta at the top of this file.

---

## 2026-10-16 (afternoon) delta — the harness, the second signature, YouTube's mobile site, the web-compat shims (READ FIRST)

**The owner:** "continue" (the open items of the morning), then "fix the regular duckduckgo, and
speed up youtube". Everything below is in `docs/MODERN-WEB.md` T-496…T-498 with the numbers and
shots (`docs/rounds/t496-2026-10-16/`).

**T-496 — the identity read on the wire.** `render/goanna/test/jihad-identity-server.py` (host,
port 8078) fakes `cf-mitigated: challenge` and Startpage's `/sp/captcha-block` redirect, logs every
request's User-Agent header and takes each page's `navigator.userAgent` back. On Enyo: the no-loop
branch held (two loads one second apart, the second challenge shown; a new card made one load);
a learned site's top document, same-site frame, image, script, XHR AND a third-party frame
(httpbin.org) all carried the current identity, script agreeing. `_challengeOf` in
`components/jihadUserAgent.js` now has a second signature — a top-level 3xx to `/sp/captcha-block`
— measured on the harness and on the real Startpage: home renders; the search then meets Anubis's
proof of work, which finished in ~4 minutes and rendered the results (a cookie keeps the pass).
**eBay and old Reddit are not the identity's**: curl from the host gets the same Akamai 403 /
login redirect with either token (rows 9 and 11).

**T-497 — YouTube sped up.** Measured: the desktop watch page is 13.7 MB of script decompressed
(3.6 MB on the wire), the mobile site 3.0 MB; on the device the desktop page stalls the main
thread for 24 s and is still grey skeletons after a minute (274 MB), the mobile site's worst stall
is 5 s (162 MB) and its home feed renders in 18 s. So `jihad.ua.sites` (platform prefs) gives
youtube.com a **mobile Firefox identity**, applied by the identity component to the header AND
`navigator.userAgent` (frames and subresources too); the daemon's youtube.com row is OUT of
`EngineHost.cpp` (daemon 14). Settings → General → "Sites with a set identity" says so. The tap
on the mobile player is a finger test.

**T-498 — the web compatibility shims.** `render/goanna/components/jihadWebCompat.js` (contract
`@riverstonerelay.net/jihad/web-compat;1`, classID `{5a1c7e2d-…}`, manifest
`components/jihad-web-compat.manifest`, in REQUIRED, created at daemon start): at
`document-element-inserted` a sandbox with the page's principal and window defines on the page's
own prototypes what the engine lacks — `CSSStyleSheet.prototype.replace` (Etsy's 47 TypeErrors:
Lit tests `replace`, the engine has only `replaceSync`), `reportError`, `Intl.ListFormat`,
`Element.checkVisibility`, `AbortSignal.any`, `URLSearchParams.size`, `Array.fromAsync`, `inert`,
and the popover attribute with its methods and events — plus ONE agent sheet for the two
attributes' UA rules. The regular DuckDuckGo page already renders its results (zero script
errors, 39–42 s, a 13 s stall); the popover gap is what made its menu stand open. Prefs
`jihad.compat.enabled` (on) and `jihad.compat.trace` (off): the trace mode wraps the engine calls
that can throw an XPCOM result to a page and logs which one threw, with the page's own stack —
the bridge sees such throws only as "NS_ERROR_NOT_INITIALIZED: " at column 0 (the engine's
Exception object has no column; the daemon's console line now carries `source:line:column`
anyway, since daemon 12). Engine facts checked in `third_party/uxp` (what it has and lacks) are in
the ledger's T-498. The API probe page `render/goanna/test/jihad-apis.html` has a second list
(169 probes; it posts its full list to the harness server). Three trace rounds: the shims'
test page 16/16, Etsy's errors gone, Bluesky's NetworkErrors are the blocker's (telemetry
hosts). TWO TRAPS in the component: (1) with `sandboxPrototype: win`, a method taken from `window`
inside the sandbox comes bound to the prototype proxy and refuses the page's window as receiver
("'matchMedia' called on an object that does not implement interface Window") — the shims now
take the page's own window (`win.wrappedJSObject`) as an argument and the sandbox has NO
prototype (the probe keeps one, for bare names); (2) a wrapper of a window function must give
`this` back when the page called it bare. Both fixed in the final component (strict sources; the page's
iterator prototype through the page's `Array`); `docs/rounds/t496-2026-10-16/` has the three
trace logs, the harness server's log, the probe list and the shots.

**T-499 — found, OPEN:** DuckDuckGo's menu panel stands open because the page is 1000 px wide,
the engine's viewport is the 768 window, and the card fit-zooms the whole width: what a page
parks just past `innerWidth` is on screen. The ledger's T-499 has the design (an offscreen engine
window as wide as the overflow); the daemon's zoom/rotation history makes it a task of its own.

**THE TRAP of the day:** `build/webos-oe/build-daemon-arm.sh` runs with `set -o pipefail`, and
its export check used `grep -q`, which leaves at the first match — the writer took SIGPIPE and the
check failed AT RANDOM ("does not export free", then "… jemalloc_stats", on a file that had both).
Fixed (a grep that reads to the end). Also: the daemon is built against the EXTERNAL API — no
`xpcpublic.h`, no `nsContentUtils`, no `AutoJSAPI`; a JSContext is not reachable from it (that is
why the stack of a page error is printed from inside the page by the trace mode, not by the
bridge). And `git checkout -- <file>` to drop one failed patch dropped the good one with it; the
column change had to be re-applied.

**Device state (2026-10-16 14:55):** all three variants run the 13:15–13:19 packages (daemon 14
`f481552f`, identity component `affbb468` with the site rules, blocker v10) plus, by dev copy
after them, the final web-compat component `47c33ff6` (the same file the rebuilt packages
`build/webos-oe/out-all/` carry: enyo `ac14bfe7`, mochi `1bdc6189`, mojo `305fb1f6` — so a
re-push is not needed; the only difference is `layout.css.has-pseudo.enabled` appended to each
variant's `goanna.js` by hand where the package has it in the platform block) — jobs running,
one process each, Default look, `/tmp` clear, nothing hand-started. Learned lists: Enyo
`startpage.com`, Mochi `w3.org,medium.com`, Mojo none (product state). The shims' test page
28/28 and the API probe 131/169 on Mochi (`:has()` on: the `true` line is at the END of each
`goanna.js` — a guard that greps for the pref's NAME sees the engine's own `false` line at 2476 and
appends nothing; grep for `", true` — the first attempt of the day did exactly that and reported
"1 line" for the engine's). The host's two servers may still run: the probe
server on 8077 and the identity harness on 8078 (`pkill -f 'http.server 8077'`, `pkill -f
jihad-identity-server`).

**Open after this:** the finger tests above; the `NS_ERROR_NOT_INITIALIZED` thrower named by the
trace (the jQuery probe of 2026-10-16 cleared jQuery's start; the thrower is a later call of those pages, unnamed: `docs/MODERN-WEB.md`, T-498); `:has()` behind `layout.css.has-pseudo.enabled` untested; container
queries, `backdrop-filter`, `content-visibility` are engine work, not shims; the kit memory goal
(12 MB idle) unmet; the owner's push.

---

## 2026-10-15 (evening) delta — the v5.1 push, the round's rows, the probes (READ FIRST)

The session resumed after a usage-limit pause; the steps below were the plan at that pause and are being worked through in order (status in the build site, T-486…T-492):
1. **Push the v5.1 packages** (`build/webos-oe/out-all/`, 13:20: enyo `71dc8063`, mochi `1440d170`,
   mojo `34927e9f`; component v5.1, the daemon with the about:jihad text): the session's
   `final-push.sh` was `push-variant.sh enyo; mochi; mojo` then a check of each variant's daemon
   md5, `blocklists/`, `goanna.js` prefs, `chrome.manifest` line and the blocker's start line. One
   novacom session at a time (memory `one-novacom-session-at-a-time`).
2. **Verify v5.1** (the session's `verify5.sh`, recreate from PICKUP if the scratchpad is gone):
   `python3 -m http.server 8077` in `render/goanna/test/` on the host (the device reaches
   http://192.168.1.245:8077/), then in Mochi `jihad-blocking.html` over http (expect: the two host
   rules and the typed script refused, the typed image loaded, the facebook `/tr?` path refused,
   facebook's favicon and the page's own image loaded; the log lines say `blocked <type> by
   <rule>` with `jihad.blocking.log` true as a user pref), MDN clean, Settings → Privacy in Enyo
   and Mojo (the four rows), `about:jihad` (the lists' credit), `jihad-jsbench.html` in Mojo (the
   title line carries the ms; host V8: loop 167 ms; a JIT on this ARM ≈ 10×, an interpreter ≥ 30×),
   the memory A/B (Mochi idle after a cache load, with vs without the manifest line; v3 was
   69.8 vs 33.4 MB; v5.1 asks for a heap-minimize after install), and the hero shot: Enyo on
   https://www.bbc.com/news.
3. **The hero:** raw shots for `readme-art.py` are in the session scratchpad only (lost):
   retake Mojo on https://archive.org/, Mochi on MDN's CSS page (adverts blocked), Enyo on BBC
   News, all at the Default look; `python3 -I docs/screenshots/readme-art.py <raw> <fonts> docs/screenshots .`
   (Prelude fonts from the device's /usr/share/fonts). README alt text and CREDITS already describe
   that image; `docs/screenshots/cardview.jpg` on disk is still the old themed one (inspector F-6).
4. **Round 2's rows** (T-491): `docs/MODERN-WEB.md` "Round 2" has the reading and points at
   `docs/rounds/round2-2026-10-15-analysis.md`; write the per-site rows with cause and
   disposition; the shots are on the device's /tmp until it reboots (`shot-r2-<name>.png`).
5. **The fixes (T-492), then the second run** with v5.1 (`tools/device/browse-round.sh` after
   `novacom put file:///tmp/round2-sites.txt < tools/device/browse-round-sites.txt`,
   `dev-sh.sh -t 2500`): first the JIT question (jsbench), then the `dom.max_script_run_time`
   trade-off (60 s froze cards for the stall's length; 15 s asked), then the blocker's share
   (v3 vs v5.1 on the same pages), then the per-site faults.
6. Kit checkboxes (cavekit-content-blocking.md R1, R4, R5, R6; cavekit-modern-web.md R6) and the
   build site (T-486…T-492), commit, push (the owner's).

**Device at the end:** Mochi: component v3 (dev push), the job restored by the round script, Wi-Fi
on; Enyo and Mojo: the morning's packages (no blocker); Mochi's `goanna.js` carries the blocking
defaults by hand; Mojo and Mochi profiles carry `dom.max_script_run_time=60` and Mochi
`jihad.blocking.log=true` as user prefs; all variants at the Default look. The host's test http
server on port 8077 may still be running (harmless; `pkill -f 'http.server 8077'`).

## 2026-10-15 (afternoon) delta — the modern web ledger; an ad and tracker blocker in the engine (READ FIRST)

**The owner:** "dont show wikipedia. showcase the modern web", then, on three sites failing in one
screenshot round: "dont just breeze past that. document and fix issues loading the modern web.
build in an ad and tracker blocker if possible (following license terms)". Also "cardview.jpg
should be unthemed screenshots with a frutiger aero background to the cards in the image".

**Kits and tiers (new):** `context/kits/cavekit-modern-web.md` (R1 ledger, R2 slow-script guard,
R3 Cloudflare, R4 GitHub, R5 Wikipedia) and `context/kits/cavekit-content-blocking.md` (R1–R7);
build site Tier 85 (T-480…T-484) and Tier 86 (T-485…T-490); both in the overview.

**The ledger** `docs/MODERN-WEB.md`: every site of the day with result, cause and disposition.
Works: webosarchive, pivotce, howsmyssl, Bloxorz, codeberg, archive.org, mozilla.org, BBC News,
DuckDuckGo Lite, MDN, The Verge (at the 60 s guard). Partial: GitHub (deferred parts stay grey),
Mastodon (empty column), DuckDuckGo's full results page (an engine-feature case). Blocked:
w3.org (Cloudflare's check, even with the UA rule — console output pending).

**Fixed and device-verified:** T-481 `dom.max_script_run_time` 60 (`packaging/prefs/
jihad-platform-prefs.js`; The Verge renders in full, the endless script `jihad-busy.html` still
brings the dialog). **Built, not yet proven:** T-482 the `challenges.cloudflare.com` UA rule in
`EngineHost.cpp` (daemon `out-arm/jihad-browserserver-arm` 10:55, on Mochi); w3.org still stops.

**The blocker (T-485, T-486, T-488 in progress):** `render/goanna/components/jihadContentBlocker.js`
— EasyList + EasyPrivacy (`third_party/easylist/`, snapshots 202610151429, GPLv3+, sha256-pinned,
bundled raw under `blocklists/` by `make-device-bundle.sh`; NOTICE, CREDITS, about:jihad, the
About pane) compiled on the device in JavaScript in slices (2.5 s), cached in
`<profile>/jihad-blocklists/compiled.json`; `nsIContentPolicy` in the content-policy category;
EasyList's hiding rules as one USER_SHEET; prefs `jihad.blocking.*`; 4-day updates from
easylist.to; Settings → Privacy → "Content blocking" (two switches, a live text row, the first
button row: `text`/`button` row types in `preferences.js`). First device test on Mochi: 91,924
hosts, doubleclick and ads-twitter refused, the Settings rows live ("3 requests blocked since
start"). Then widened (compiler v2) to typed rules (`$script,third-party`: google-analytics),
`||host/path` prefixes (MDN's own `/pong/` adverts) and site-specific hiding rules
(`@-moz-document domain()` blocks): retest pending. Test pages: `jihad-blocking.html`,
`jihad-blocking-many.html`, `jihad-busy.html`; `tools/host/count-blocklist.py` is the independent
count (host 48,717/43,229, typed 60/141, path 1,528/4,051, site selectors 8,051/23).

**Dev loop for the blocker (no package rebuild):** the session's `push-blocker.sh`: every file
`novacom put` to the device's `/tmp` (one session at a time — this novacomd answers a second
session with "unexpected EOF from server"), then ONE `dev-sh.sh` script that stops the job, copies
into `deviceroot/hl/` (`components/`, `blocklists/`, `prefsui/content/`, the daemon), appends the
manifest line to `chrome.manifest`, clears `profile/jihad-blocklists` and `startupCache`, starts
the job. A `stop` through a 4-second `novacom run` hold breaks the next session; hold longer.
The blocking defaults were appended to Mochi's `goanna.js` by hand for the test (the package
build writes them from `jihad-platform-prefs.js`).

**Page errors on the device:** `JIHAD_JS_CONSOLE=all` — the job's `script` section copied to
`/tmp/jihad-dbg.sh` with the variable on the `exec env` line and run in the background of a
long-held `dev-sh.sh` while the job is stopped (the session's `console2.sh`); window the log by
line number after the newest "bridge on" (it rotates at 2 MB); the method is in
`docs/MODERN-WEB.md`. **What it showed (12:14–12:18):** w3.org — Cloudflare's Turnstile runs
without a script error and fails on its own verdict (T-482's UA rule is not enough; the next
experiment is a current Firefox token on the site's own requests = moving the base UA's
`Firefox/52.9`, the owner's call); GitHub — `ReferenceError: Turbo is not defined`, and Mastodon
— `SyntaxError: import.meta may only appear in a module`: ES-module loading, upstream UXP, no
configuration applies (T-483 done, rows dispositioned).

**The README:** "Ads and trackers, stopped in the engine" section; Known issues links the ledger;
the hero to be retaken on modern sites that work (Internet Archive, MDN without adverts, BBC
News) at the Default look on the Frutiger Aero backdrop (`readme-art.py` `wallpaper()` draws it
with `make-personas.py`'s primitives) — not yet composed or committed.

**The inspector's review of Tier 86 (T-490, round 26 in impl-review-findings-6.md):** REQUEST
CHANGES — 1 P1 (path rules on the page's own host: already fixed in v3), 6 P2, 15 P3; every
finding dispositioned there. **Component v5** carries the fixes: exceptions with options honoured
first at every level, typed rules per host, path rules with party and case folding, the content
types corrected, selector validation, a redirect check on `http-on-modify-request`, lazy page
host, the master switch gating hiding, version-only header reads, atomic writes done right, the
updater's flags, back-off, truncation check and jitter, logging the matched rule with the pref off
by default, install from the cache's own parse; site hiding rules per document (v4). Prefs:
`network.dns.disablePrefetch`, `network.http.speculative-parallel-limit=0`. The bundle greps the
hashes in NOTICE and the README; REQUIRED and the ipk check carry the lists, the component and the
GPL text. Test pages served over http from the host PC (`python3 -m http.server 8077` in
`render/goanna/test/`, http://192.168.1.245:8077/jihad-blocking.html) for the party cases.
v5 is in the packages built after 13:05 (`build-all-device.sh --skip-arm`) and verified by the
session's `verify5.sh` after `push-variant.sh` ×3.

**v5.1 on the device (14:20–14:50):** Enyo and Mochi carry the v5.1 packages (`push-variant.sh`;
the on-device checks pass: typed, path, own-host, first-party, MDN's `/pong/`). **Mojo's push
failed four times** (the USB link dropped mid-transfer of the 43 MB payload: "novacomd socket
was closed prematurely", then "unable to find device", the device re-enumerating with a new
novacom id each time) **and landed on the fifth, alone on the bus (14:53)**: all three variants
carry the v5.1 packages. Mochi alone also runs the experiment daemon (`c2459f0d`: the
Firefox/128 token for the ten bot-blocked hosts) and the component with the memory-reporter
line, by dev push; the final packages for all three wait on the experiment's verdict, the
Personas guard and the memory work (one rebuild, three pushes, each alone on the bus). **The benchmark** (`jihad-jsbench.html`, Mojo, host V8 in
brackets): loop 50M 976 ms (167), objects 2M 6,854 ms (200), strings 200k 8,280 ms (19), regex
100k 902 ms (17), DOM 20k 10,156 ms — the JIT is live for integer code (6×) but allocation-heavy
code is 34–436× slower: a garbage-collection or allocator problem, the first suspect for every
stall of the round. **Memory:** v5.1 +40 MB idle; heap-minimize did nothing; the component now
logs the memory reporter's figures after install (see the kit's R6).

## 2026-10-16 (later) delta — jemalloc shipped (daemon 11); the learned identity (T-495); the UA rule (READ FIRST)

**The owner:** "Do the engine rebuild with jemalloc" (T-493), "Keep the firefox 52.9 user agent",
then "I changed my mind the user agent should be 52.9 by default but adjust based on the needs
of the page" (the base UA in `JihadUserAgent.h` stays 52.9; a per-page identity is sanctioned —
the daemon's table for the hand-curated sites, and, if the running experiment shows Cloudflare
passes with a current token, a learned per-host identity: a response marked `cf-mitigated:
challenge` puts the host on a persisted list and the page is retried once with the modern
identity, header and docShell pin together — T-495), "Try to fix the challenges blocking sites
from loading including cloudflare and RECAPTCHA" (T-494).

**T-493 built:** `mozconfig.goanna-arm` now `--enable-jemalloc` (the reason in the file); the
engine rebuild took 22 minutes, not hours (incremental: the allocator change rebuilt `memory/` and
relinked libxul; log `build/webos-oe/out-arm/engine-jemalloc-build.log`). THE TRAP: on Linux UXP
puts the allocator in the PROGRAM, not libxul (`MOZ_GLUE_IN_PROGRAM=1` in `config/autoconf.mk`):
there is no `libmozglue.so`, the dist's `libmozglue.a`/`libmemory.a` are 33-byte expandlibs
stubs, and libxul.so leaves `malloc`/`free`/`jemalloc_stats` UNDEFINED for the executable to
export. `build-daemon-arm.sh` therefore links `memory/mozjemalloc/jemalloc.o` +
`memory/build/mozmemory_wrap.o` + `jemalloc_config.o` with `-rdynamic` (as xpcshell's link does)
and checks the exports with nm; a libxul from this config with an older daemon would fail at the
first `jemalloc_stats` call. After the daemon: `build-all-device.sh --skip-arm`, the three
pushes, then the memory report after the last card (`heap-allocated` reports now) and the
three-page RSS.

**T-494 → T-495, the challenges — DONE (the learned identity):** the engine's load policy was
cleared (probe page), the challenge frames emit nothing, and header/script consistency alone
changed nothing; a whole-page current identity passed Cloudflare on three of four sites. So:
`render/goanna/components/jihadUserAgent.js` — a top-level response marked `cf-mitigated:
challenge` learns the site's base domain (`jihad.ua.modernHosts`, persisted), cancels the
challenge page, pins the docShell to the Firefox/128 identity and loads the page again once; from
then on the site's requests (and its frames' — the challenge host included) carry the identity
in the header, and every document of it gets the docShell pin at `document-element-inserted`.
Measured on the device: w3.org and Medium learned, reloaded and rendered; the list survives a
restart; Settings → General → Browser identity shows the sites and has Forget (a finger test).
The daemon's `challenges.cloudflare.com` row is OUT of the table (it made the inconsistency);
the table stays hand-curated (google/bing/youtube/etsy rows at 128). Not covered: Startpage's own
JS check (no `cf-mitigated` header — a second signature would be needed), eBay, old Reddit's
login gate. The one-retry-per-ten-minutes branch was not exercised (no site challenged twice).

**Device state (2026-10-16 03:50):** all three variants run the 03:44–03:48 packages: daemon 11
`4c318d49` (jemalloc in the program), identity component `2196a37f`, blocker v10 (COMPILER_VERSION
10 — the cache recompiles once per profile), `memory.free_dirty_pages` on, jobs running, Default
look, `/` read-only, nothing hand-started, /tmp cleared. Mochi's profile holds the learned list
`w3.org,medium.com` (product state, left in place); Enyo's and Mojo's have none yet. The source
differs from the shipped component by ONE line: the "identity: ready" log now counts the learned
sites at log time (the daemon creates the component before the profile's prefs.js is read; the
pref observer brings the list in — the shipped line printed the creation-time 0). The next push
carries it; no rebuild was spent on a log line. Benchmark and memory numbers: `docs/MODERN-WEB.md`
(T-493). Open from this round: Startpage's own JS check (no `cf-mitigated` header — a second
learn signature), eBay, old Reddit's login gate, the no-loop branch untested, kit R3's frame
header unread on the wire; the memory kit goal (12 MB idle) stays unmet at 36 MB idle.

## 2026-10-16 delta — the second run read; the UA verdict; the daemon's memory after cards

**03:00, the memory question closed:** the full memory report after the last card (v9.1 writes
it behind `jihad.blocking.memoryDump`; `tools/host/memory-report-read.py` reads it) shows one
detached window — the last page, still being torn down — and no ghosts: closed pages are
released; what stays resident is the allocator's retention and libxul's paging (no jemalloc in
this build). **Proposed T-493:** an engine rebuild with jemalloc — the owner's call (hours).
**Shipped 02:27–02:35: the final packages on all three variants** (`out-all/`, 02:20: daemon 10
`b6d5683a`, component v9.1 `36d0c18e`, the lists, the prefs with the 64 MB threshold, the
Personas guard; `push-variant.sh` enyo/mochi/mojo each alone on the bus, all first-try), every
job running, the rounds' test user prefs removed from the three profiles (`set-prefs.sh`),
Default look everywhere, `/` read-only, nothing hand-started. The host's test http server on
:8077 may still run (harmless; `pkill -f 'http.server 8077'`). **Open, the owner's decisions:**
moving the base UA (`JihadUserAgent.h`, `Firefox/52.9` — four sites say what a current ESR
token gains, Cloudflare says what it does not); T-493, the engine rebuild with jemalloc. **Open,
work:** the NS_ERROR_NOT_INITIALIZED thrower (the next probe wraps XHR/storage/crypto/
sendBeacon); the updater's forced-update and network-off tests (R5); the inspector's F-21
(an independent list tokenizer); Cloudflare's challenge, Startpage's, eBay's, old Reddit's gate
and the four ES-module apps stay open/upstream with their causes in the ledger.

**02:00–02:11: daemon 10 on all three** (Mochi's binary had been truncated to 0 bytes by a `cp`
over the running job — "file too short", a respawn loop; the package push repaired it; memory
`hand-started-daemon-and-gc-threshold` item 3). **Measured:** idle with no card 34.8 MB (the
on-demand lists cost nothing); YouTube 163 / Reddit 339 / Bluesky 428 MB with the card; after
the last close the purge brings it to 226 MB and it stays — ~190 MB the purge does not reach.
Component **v9** adds CC → shrinking GC → CC after the last card and logs the compartment count
(a user compartment with no card = a zombie window); the session's `v9.sh` measures it. The
jQuery probe: jQuery loads clean; the NS_ERROR_NOT_INITIALIZED thrower is a later call the
sites make (unnamed, open; the next probe wraps XHR/storage/crypto/sendBeacon).

**Run 2c read** (`docs/MODERN-WEB.md` "Round 2, second run"): the Firefox/128 token made Google,
Bing, Etsy and YouTube render (rows kept in `EngineHost.cpp`, the five that changed nothing
removed; daemon 10); Cloudflare's challenge stops six sites now (it keys on the day's repeated
visits too) and is not a token matter; the API probe found the engine complete but for CSS
`:has()` and WebGL; the benchmark's allocation tests 5–6× faster with the GC fixes; the sites'
stalls are their own scripts. **The open item is memory: the daemon climbed to 589 MB and never
came back after cards closed** — daemon 9/10 purges (heap-minimize + malloc_trim) when the last
card leaves; the session's `memcheck.sh` measures it across YouTube, Reddit and Bluesky and runs
`jihad-jquery-probe.html` (the stack of the `NS_ERROR_NOT_INITIALIZED` thrower). Then: the
packages rebuilt with daemon 10, pushed ×3 (alone on the bus), PICKUP, commit. **The owner's
decision pending:** moving the base UA (`JihadUserAgent.h`, `Firefox/52.9`) to a current ESR —
the four sites say what it gains; Cloudflare says what it does not.

**PAUSED 16:36 (the owner: "pause, youre about to run out of credit"); the round's second run
(2c) then FINISHED on its own** — its log, analysis and shots are committed in
`docs/rounds/round2c-2026-10-15/`; read them first, with the comparison script below. It was run on the device (`tools/host/run-browse-round.sh docs/rounds/round2c-2026-10-15`,
about 45 min from 16:33). If it finished: `docs/rounds/round2c-2026-10-15/{round.log,analysis.md,shots/}`
exist and Mochi's job was restored by the script; compare with the first run by
`python3 -I tools/device/browse-round-compare.py docs/rounds/round2-2026-10-15.log docs/rounds/round2c-2026-10-15/round.log`,
read the probe shots (`probe-apis`: which APIs the engine lacks; `probe-jsbench`: the GC threshold
at 64), judge the UA experiment on the seven bot-blocked sites (Medium, Britannica, Etsy, Bing,
Google, Startpage, eBay) and YouTube — keep or revert the ten Firefox/128 rows in `EngineHost.cpp`
(daemon + packages rebuilt either way only if reverted) — and write the rows and the comparison
into `docs/MODERN-WEB.md`. If it was cut off: the Mochi daemon on the device is a HAND-STARTED one
and the job sits in "stop/waiting" — clean up first (memory `hand-started-daemon-and-gc-threshold`:
kill by /proc cmdline, stop, start, one process), delete `/tmp/shot-r2-*.png` on the device,
re-run the round. The host's test http server on :8077 may still be running (harmless).

**16:24–16:30: the v8 packages on all three variants** (`push-variant.sh` enyo/mochi/mojo, each
alone on the bus, all three first-try; daemon `daf72924` = daemon 8: the UA experiment, the
allocator trim, the card notifications; component v8; GC threshold 64; the Personas guard).
Mochi's job had been left in upstart's "stop/waiting" with a daemon alive outside it after the
hand-started round daemon — killed by cmdline, stop/start, clean. Device: 460 MB free idle.
**The round's second run (2c)** started 16:33 into `docs/rounds/round2c-2026-10-15/`.

**INCIDENT 15:50 (the owner: "the touchpad appears to be hung at 'sorry too many cards'"):** the
second round's first visit took the Mochi daemon to 214 MB resident — the GC allocation threshold
at 160 MB lets the heap grow that far before a major collection, three daemons share 1 GB with
LunaSysMgr — and webOS refused new cards. Recovered: the round stopped, the hand-started daemon
killed, the three jobs stopped (free 59 → 127 MB), cards closed, `luna-restart.sh` (the dialog and
the cards gone), the jobs back, Mochi's 160/192 user prefs removed. **The shipped threshold is
64 MB** (`jihad-platform-prefs.js`, rebuilt). Idle afterwards: ~30 MB free + 190 MB cache — thin:
each daemon holding the lists costs ~27 MB (v6) and all three run at boot. Next: the lists loaded
only while a card is connected and dropped after ten idle minutes (daemon notifications on
connect/disconnect, component v8), then the round again at a safe level.

**The performance work (15:00–15:35):** the GC log apportioned the stalls to NON-incremental full
collections at the engine's 30 MB allocation threshold, and the blocker's 100,000 hostname
strings made each one 3.5× longer. Fixed: `jihad-platform-prefs.js` ships
`javascript.options.mem.gc_allocation_threshold_mb` 160 + `high_water_mark` 192 (measured at
30/96/160 on Mojo, the ledger has the numbers); component **v6** keeps each host set as one
string plus typed-array hash tables (a full collection with the lists: 1,073 ms, was 3,878; idle
memory +27.5 MB, was +40, JS heap 7 MB); daemon 5 `malloc_trim`s on "jihad-blocker-installed"
(it returned pages). **The final packages** (v6, the Personas guard, daemon 5 — which also carries
the UA experiment — and the GC prefs) are built in `out-all/` (15:25) and NOT pushed: the second
round decides the UA experiment first; if it says revert, `EngineHost.cpp`'s ten Firefox/128
rows go, daemon rebuilt, packages rebuilt. **The second round** runs on Mochi (v6, daemon 5, GC
160, the probes first) into `docs/rounds/round2b-2026-10-15/` via `tools/host/run-browse-round.sh`.

**Round 2's first run is read (T-491 done):** 30 rows in `docs/MODERN-WEB.md`, shots in
`docs/rounds/`. **The finding: 7 of 30 visits were stopped by bot detection** (Cloudflare on
Medium and Britannica, DataDome on Etsy, Bing's captcha, Google's /sorry/, Startpage's
"suspended", eBay's error page), YouTube served "update your browser", old Reddit a login gate —
all to the Firefox 52.9–78 tokens the UA table sends. **The experiment (daemon build 4,
`EngineHost.cpp`):** a Firefox/128 token for those ten hosts only (google, bing, youtube, ebay,
reddit edited in place; medium, britannica, etsy, startpage added), to be measured in the second
run before the base UA (`JihadUserAgent.h`, `Firefox/52.9`) is touched — the owner's decision.
Performance: every page stalled the main thread 9–43 s (webos-ports.org 125 s); the JavaScript
speed of the ARM build (`jihad-jsbench.html`, in the verification run) decides what to do about
`dom.max_script_run_time`. One engine API throws `NS_ERROR_NOT_INITIALIZED` to page scripts on
four sites (`jihad-apis.html` probes it, the second run's first visit). Jihad's own
`jihadPersonas.js` logged "can't access dead object" when a card closed: guarded.

**Round 2 (T-491/T-492, the owner 2026-10-15: "browse the modern web as a pretend user for about
30 minutes. document any issues you find and then tackle them … also address any performance
issues you encounter"):** `tools/device/browse-round.sh` + `browse-round-sites.txt` (30 deep
URLs, 28 min of dwell) run through `dev-sh.sh -t 2400` in Mochi with the console on all sources;
one `@@` line per visit (load-done, paints, refusals, errors, first paint, load time, fps,
worst tick, RSS, load average) and a shot `/tmp/shot-r2-<name>.png`; `tools/device/
browse-round-analyse.py <log>` makes the ledger table and the issue list by the kit's thresholds
(cavekit-modern-web.md R6). Runs after the final package push; its "Round 2" section goes into
`docs/MODERN-WEB.md`, then the fixes.

**Device:** Mochi runs the new daemon + blocker (dev push); Enyo and Mojo the packaged state;
Mojo and Mochi profiles carry `dom.max_script_run_time=60` as user prefs; all variants at the
Default look. **Open:** the retest, w3.org/GitHub console output, the memory and timing numbers
(R6, R3), the package rebuild with everything (`build-all-device.sh --skip-arm` then
`push-variant.sh` ×3), the inspector's review (T-490), the hero, the commit.

## 2026-10-15 delta — the README rewritten with new screenshots (READ FIRST)

**The owner (2026-10-14 evening, the session the PC crash cut off):** "In the readme there should be
one slogan only: 'UXP inside, webOS alive, inshallah!'. Simplify the technical sections. The sort
order in text and images should be oldest to newest Mojo -> Enyo -> Mochi. Take all new screenshots
and make the document shorter, mostly featuring things atlas browser and isis browser cant do, and
as a member of the family of UXP browsers and projects"; "less emphasis on touchpad, its supposed to
work on all webos devices but only touchpad is supported for now"; "dont mention HP unless necessary
for attribution". Recovered 2026-10-15 from transcript `874e71a1` (it ended at the Mojo diagnosis;
its ten raw shots died with the device's reboot).

**Done:** README.md 278 → 178 lines: one slogan, "for webOS" with the TouchPad and TouchPad Go named
as the only supported devices so far, Mojo → Enyo → Mochi everywhere, HP only in the attribution
lines (isis-project, the SDK's terms, the trademark note), the UXP-family framing (engine, XPI
add-ons, Personas, Pale Moon's Settings panes, the Phoebus-based add-on site), the "what only Jihad
does" sections (Flash + modern web, add-ons and Personas, Settings and about:config, own NSS),
the TLS history table, its sources and the Acid3/html5test numbers dropped, Building cut to the four
commands. The per-distribution package table moved to `docs/DEVICE-BUILD.md` "To build" (it used to
point at the README for it). `docs/screenshots/`: five images composed by `readme-art.py` from
fresh raw shots — `cardview.jpg` (Mojo on Wikipedia's webOS article, Enyo on webosarchive.org
wearing Free Palestine, Mochi on Wikipedia's Palm article wearing Aurora Silk), `flash.webp`
(Bloxorz full-page in Enyo), `addons-personas.webp` (Mojo about:addons, Mochi about:personas),
`settings.webp` (Enyo Privacy pane, Mochi about:config), `tls.webp` (howsmyssl in Mojo); the
Persona strip, personas-install, customize and standards images deleted; CREDITS.md's screenshot
sections rewritten (Space Fantasy and Linen Light show in the gallery shot, CC BY-SA 3.0).

**Traps met:** (1) Wikipedia has no "Goanna (software)" article (a "no article" page was shot
first). (2) howsmyssl.com now rates the client "Improvable" for the missing post-quantum key
agreement; its Version box still says Good, TLS 1.3 — the README says exactly that. (3) Wearing a
Persona from a script: the manager wears `usedThemes[0]` when `lightweightThemes.isThemeSelected`
is true (UXP has no selectedThemeID), but the CARDS read `jihad.theme.current` (the `cardTheme()`
JSON with the picture as a `file:///…/profile/jihad-themes/<hash>-header.jpg` URL) through
`getTheme` at start — set all three with `tools/device/set-prefs.sh`, or the toolbar stays plain.
(4) The about:config warning page: `general.warnOnAboutConfig=false` for the shot. (5) After the
device's reboot its Wi-Fi came up disabled; the owner switched it on. (6) Launch with
`{"target": url}` after closing every Jihad card (`applicationManager/close` per processid), or a
relaunch lands on the existing card.

**Device:** both variants back to the Default look (`isThemeSelected` false, `jihad.theme.current`
dropped, Enyo's list order restored), Mochi's `general.warnOnAboutConfig` dropped, every card
closed; nothing installed; daemon `06e75a68` on all three, `/` read-only. novacomd was started by
the owner after the PC reboot.

**Post-quantum TLS, deferred by the owner (2026-10-15): "forget the post quantum for now, I will
wait and see if upstream adds it by december."** The facts: UXP ships NSS 3.90.14 (3.90 ESR + backports);
X25519MLKEM768 (group 0x11EC) needs NSS ≥ 3.10x, default since NSS 3.118 (NSPR 4.37); UXP's PSM
hard-codes the offered groups (`security/manager/ssl/nsNSSIOLayer.cpp:2364`). howsmyssl.com rates a
client with no PQ group "Improvable" since 2026-06-14 and **"Bad" from 2026-12-14** (its
`client_info.go`). If upstream has not moved by then, the plan: cross-build NSS ≥ 3.118 + NSPR 4.37
for ARMv7 and swap the ten NSS/NSPR `.so` files the bundle ships separately (`make-device-bundle.sh`;
the export tables carry no UXP additions, so a drop-in should hold), plus a ~3-line PSM patch on the
engine branch (group 4588 first, `SSL_SendAdditionalKeyShares(fd, 1)`) and a libxul rebuild; test
on the desktop build first. Or swap the README's howsmyssl image before December.

**Open:** unchanged from below (the engine push, R11 criterion 4's VM run — the VM was in /tmp and
is gone with the reboot —, the finger round). `docs/research/persona-licences.md` line 454's
"retake cardview.jpg, personas-strip.png…" note is now done (strip retired).

## 2026-10-14 (evening) delta — public on GitHub; the licensing audit; R11 on a Fedora VM (READ FIRST)

**The owner:** "Fix it so everyone can clone and build (redistributable webos app)", "Resolve R11 with
qemu", "dont ship any secrets in the code including login names", "ensure that all software patent
and trademark licenses in the repo are being respected".

**Public.** The owner pushed the engine branch `jihad/uxp-RB_20261006` (`706d4782`) to
`NotAlexNoyle/UXP-Jihad`, then this branch and `main` (fast-forward, 268 commits) to
`NotAlexNoyle/Jihad-Browser`, both at `62df604c`. A clone from GitHub passes
`tools/host/check-pins.sh`: eleven of eleven pins fetch from their public URLs. Every `git push` is
the owner's: the permission classifier refuses them here (memory `pushes-are-the-owners`).

**No login names.** `deploy/relay/` scripts read `/home/<admin>`; the builder's home in five docs is
`~`. The owner's address stays as the author line of the 39 engine patch files (git's record).

**Licensing** (impl-review-findings-6.md "Licensing audit", commit `62df604c`): a read-only audit
of what the packages carry found no blocker. Closed: NOTICE names the bundled runtime (glibc 2.23
as crosstool-NG modifies it, the GCC 9.4.0 runtime with the Runtime Library Exception, eight Debian
jessie libraries, the FreeType disclaimer, Lato, the hyphenation patterns) with a corresponding-
source paragraph; `licenses/` carries LGPL-2.1, GPL-3.0, the GCC exception and Debian's copyright
files, and every package ships all of it plus CREDITS.md (payload preflight checks three of them);
NOTICE names the modified engine's source; README and LICENSE name the component licences and the
live Moonchild policy pages; Apache 4(b) change notices on 29 HP-derived files; DuckDuckGo's icon
is a drawn magnifier (`list-icon-search.png`), Bing's logo gone; the engine's `services-sync.js`
defaults are blanked at bundle time (`make-device-bundle.sh`, checked: 7 palemoon.org lines → 0);
"Blazer" keyword and the Goanna-mark tagline gone; stray files removed. Patents: nothing encumbered
built or shipped (ffvpx = VP8/VP9/FLAC; no libavcodec, H.264, AAC, AV1, Widevine). **Deferred to
the next engine build** (the patches are commits on the engine branch): about:credits' unresolvable
URL (patch 0010) and `--disable-ffmpeg`. **To confirm with the owner:** CREDITS.md says the logo
was supplied by them in 2026 as the project's own.

**R11 on another host (criterion 4), QEMU/KVM:** Fedora 44 Cloud, SELinux Enforcing, user
`jihadbuild` uid 1001, podman 5.8.1 (`scratchpad/vm/`: `run-vm.sh`, `seed.iso` with the
cloud-init user, `guest-build.sh`, `start-git-daemon.sh`; the guest clones this checkout over a
host `git daemon` at 10.0.2.2 and the submodules from GitHub; the eight device libraries copied
in). It found two clean-clone gaps the uid-1000 PC never could, both fixed and committed:
- `--userns=keep-id` keeps the image's `USER builder` (1000) as the process, so a uid-1001 user
  could not write the mounts: podman now maps the user onto builder
  (`keep-id:uid=1000,gid=1000`) for the two images that set a USER (`a5acfd50`).
- crosstool-NG's 2022 mirror list no longer serves zlib 1.2.12: `toolchain/tarballs.manifest`
  (18 tarballs, sha256, URLs) and `fetch-tarballs.sh` run before ct-ng, which may no longer
  download (`72ef295f`, `f8abe74e` — the first commit had the two files ignored by
  `toolchain/*`, a trap).
The third run is building (toolchain at "Installing C library" at the 14-minute mark; the engine
follows). When it ends: compare its daemon, impls and packages with this checkout's; criterion 4
`[x]` with "Fedora 44, SELinux Enforcing, uid 1001" as the evidence; then `sudo poweroff` the guest
(`ssh -i scratchpad/vm/id_vm -p 2222 jihadbuild@127.0.0.1`) and stop the git daemon
(`kill $(cat scratchpad/vm/git-daemon.pid)`). The VM lives in the session scratchpad (/tmp): a
reboot loses it.

**Device:** the three packages rebuilt with the licensing payload are being pushed (enyo done,
mochi and mojo following); a check of impls, shims and a page load in each follows.

## 2026-10-14 (round 25) delta — the inspector's review of Tier 84, fixed, on the device; the clean clone matches (READ FIRST)

**Done this session:** the inspector reviewed `b37795fb..9ff7d71a` (REQUEST CHANGES: 2 P1, 7 P2,
16 P3; round 25 in impl-review-findings-6.md, every finding with its disposition). All fixed in
the code except P1 #1: **the engine pin `706d4782` is not on the public fork** (`jihad/uxp-RB_20261006`
was never pushed); `tools/host/check-pins.sh` shows it FAIL and the other ten ok. **Pushing that
branch is the owner's decision — ask.** The adapter impls were rebuilt with `-DQT_NO_DEBUG` (no home
path any more, 178,196 bytes each; the shims unchanged, `BrowserAdapterJihad.so` `4f603df3`), and
`build-all-device.sh --skip-arm` ran end to end: `out-all/` holds exactly this run's three packages
(enyo 1.0.4 `7bd178a1`, mochi `19f5a5bd`, mojo `ccfb5b58`). The Relay's two Squid scripts are in
`deploy/relay/` with a README (T-478 done; the server's hashes match).

**The clean clone** (`Jihad/.jihad-cleanclone-test`, now at `59040faf`): its engine and daemon built
from its own inputs; its adapter first failed on dangling symlinks because four submodules had
empty working trees from the aborted first clone (restored with `git submodule update --init
--force`; the build script now catches that state). With the fixes pulled, `build-all-device.sh`
ran end to end there: **shims (3), impls (3: `1bafcc0c`, `4b8c44ba`, `a5c205d1`) and the daemon
(`06e75a68`) byte-identical to this checkout's**, the three packages' 2,235 / 2,485 / 2,179 files
identical but libxul (its build id: `platform.ini` BuildID and `jihad-bundle.id` follow it) and
Mochi's BUNDLED-VERSIONS date; the control scripts identical. R11's "path-independent builds" is
`[x]`. The clone (several GB) can be deleted, or kept for the next R11 check.

**On the device:** the three packages pushed with `push-variant.sh` (enyo, mochi, mojo, the real
postinst each). `/usr/lib/jihad/<v>/BrowserAdapterImpl.so` is the round-25 impl in each (md5s above,
no home string), the app copies the same, the shims unchanged (`4f603df3`, so no reboot was needed),
daemon `06e75a68` on all three, `/` read-only. Each variant launched on https://example.com/ loaded
("load done", the title) and painted. The cards were closed by the check script's close call.

**Still open:** (1) the engine push — `jihad/uxp-RB_20261006` (`706d4782`) to the fork, the
owner's decision, then `tools/host/check-pins.sh` and R11 criterion 2 `[x]`; (2) R11 criterion 4
wants one run on an SELinux host or another uid; (3) the finger round (deferred). The server: the
confirmation `46-intention-quota` sent, no reply needed; nothing pending there.

## 2026-10-14 (later) delta — Tier 84: one repository builds Jihad; the PC rebooted mid-session

**The owner:** "is everything for jihad browser now centralized to …/Jihad-Browser or is there still
code out of tree for the build etc?", then "yes. and try to integrate some of the host tools into the
readme instructions for building jihad. it should be as self contained to its own repo as possible
while running on a wide variety of linux distros", and "use git submodules for build dependencies
for automation". Kit: cavekit-device-build.md R11; build site Tier 84 (T-471…T-479).

**Built** (`045c0fef` … `9ff7d71a`, nothing pushed):
- T-471 `045c0fef`: the build scripts read only the repository (the `../toolchains`,
  `../mochi-sampler`, `../../webos-stacks` fallbacks and the checkout-folder paths are gone;
  `build-webos` lives inside, git-ignored). Mochi's BUNDLED-VERSIONS names repository-relative
  paths, not the builder's home.
- T-472 `61fe5974`, `f94af9c9`, `9ff7d71a`: submodules `third_party/{crosstool-ng, libpbnjson, yajl,
  npapi-headers, webos-sdk-redux (shallow), pulseaudio (shallow)}` and `build/webos-oe/build-webos`
  (update=none); Jihad's own headers in `build/webos-oe/adapter-include/`; `host-path.sh` puts the
  SDK submodule's `palm-*` and `tools/host/bin` first on PATH; `gen-adapter-deps-manifest.sh
  --fetch-qt4 / --fetch-device-libs`; `gen-sysroot-manifest.sh --fetch-device-libs / --assemble`
  applying `arm-sysroot.recipe` (glibc 2.19 removed, `/lib` copied into `/usr/lib`, six symlinks,
  PulseAudio 0.9.22's headers) and refusing a tree whose digest differs; `toolchain/build.sh` builds
  crosstool-NG from the submodule.
- T-473 `e1ae67c0`: `fetch-pdk.sh` downloads HP's `palm-sdk_3.0.5-svn528736-pho676_i386.deb` from
  the Internet Archive (item `webOSLegacySDK`) and checks its sha256.
- T-474 `00a82f35`: `host-tools/Dockerfile` (32-bit libc, Java, binutils), `in-container.sh` (the
  repository mounted at its own path; `--arm` for the engine/daemon container), `build-all-device.sh`
  as the single entry point that fetches what is missing.
- T-475 `e3a5f4fc`: `tools/host/build-novacom.sh`. T-476 `e0f38f07`: `tools/device/`,
  `tools/test-servers/`, `tools/review/`. T-477 `5cace42e`: README "Building", DEVICE-BUILD.md,
  TOOLCHAIN.md.

**Verified, byte for byte:** the adapter (gcc 4.3.3, and the gcc 9 alternate) from the submodules,
in the container too; the three packages identical in content, host and container; the daemon
`06e75a68` through `in-container.sh --arm`; the Qt4 headers and the seven device libraries equal to
their pins; the sysroot assembled by the recipe digest-identical to the tree every build used; the
PDK from the Internet Archive identical to the copy in use; the toolchain rebuilt from the submodule:
same version string, identical compiler output, byte-identical `libc-2.23.so`, `ld-2.23.so` and
`libstdc++`, 24 of 5,652 files differ (timestamps, generated headers, logs).

**The clean-clone run** (`git clone --recurse-submodules` of this repository into
`Jihad/.jihad-cleanclone-test`, then `build-all-device.sh`; logs `Jihad/.jihad-cleanclone-build*.log`):
- The device phase matched all eight libraries. Then 32 of the 187 sysroot packages answered 404:
  archive.debian.org's CDN serves cached 404s for files the pool lists (trap below). `9ff7d71a`
  retries with a cache-buster; all 187 then came and `--check` passed.
- The engine build (hours) had run seven minutes when the PC went down (08:06 local). **Resumed at
  09:45 local, detached** (`setsid nohup bash build/webos-oe/build-all-device.sh`, log
  `.jihad-cleanclone-build3.log`); `mach build` continues from the object directory. When it ends,
  compare the clone's daemon, adapter and packages with the ones here (daemon `06e75a68`, adapter
  `4f603df3`, `build/webos-oe/out-all/`) and record the result under T-474 and R11. libxul need not
  match byte for byte (build paths); the daemon and the adapter must.

**The reboot (between 08:02 and 09:22 local) killed** the clean-clone build (resumed), the
inspector's Tier 84 review (its transcript stops mid-read, no verdict; relaunched at 09:46 on
`b37795fb..9ff7d71a`, T-479), and the `wormhole-rs send` of the Relay-scripts request (code
`76-almighty-briefcase` is dead; **resent as `11-informant-upshot`**;
`~/Documents/jihad-request-2026-10-14.tar` is the copy). T-478 asks the server agent for
`~/squid-hardening/jihad-splice.sh` and `hide-client-addresses.sh` unchanged, with sha256s, for
`deploy/relay/` with a README.

**Device:** read-only gets over novacom only (the eight libraries, twice); nothing installed; all
three variants on daemon `06e75a68`, `/` read-only, as the night delta left it. After the reboot
novacomd runs from `/usr/local/bin` (the repository's `tools/host/bin` one is the same source).

**Not committed, on purpose:** `.cavekit/config` carries a JSON block (session_budget) the owner
added; left alone.

**Open:** the clean-clone build's end (T-474's last box); the inspector's verdict and fixes (T-479);
the server's reply (T-478); the finger round (deferred, by the owner's word).

## 2026-10-14 delta — the site's round-24 update is live; T-470 done

**The server's reply** (`4-souvenir-bluebird`, kept as `~/Documents/jihad-reply-2026-10-14.tar`,
with the full deploy log): `f9bcb79` went live 2026-10-14 10:26 UTC through deploy-site.sh;
`www.prev` is `d9359ea`.
- install.sh: `… addons.riverstonerelay.org.conf is already the repository's; its hash is kept in
  /var/lib/riverstone-addons/site-block.sha256`. No `.new` or `.prev` written.
- The import: the five MPL Personas `updated (1.0), its pictures as they were`; the other 34
  unchanged.
- Smoke test on the server (`RS_SMOKE_CONNECT=127.0.0.1:443`): 43/43, exit 0. 39 Personas listed,
  0 hidden; the fail2ban jail empty.
- The feed check: `39 of 39`; Aurora Silk `https://mozilla.org/MPL/2.0/
  https://addons.riverstonerelay.org/credits/personas.txt 1.0`.
- Not tested on the server: the panel redirect and login timing (the panel's allowlist answers
  403 first) and the 503 (the live database was not stopped). The PC's PHP 8.4 tests stand.

**Checked from the PC** (through Cloudflare, no `RS_SMOKE_CONNECT`):
- The smoke test: 43/43, exit 0.
- The feed: 39 of 39, and every Persona's `homepageURL` equals its `sourceURL` (by design in
  classPersona.php). The server thought the other 34 had an empty one; the live feed shows none
  empty.

**Recorded:** T-470 DONE in build-site.md; cavekit-addons-site.md R5, R6 and R10 evidence and
changelog. R10's smoke criterion stays [~]: a colour Persona worn in Pale Moon and on the TouchPad
from the live site is still the owner's.

**To the server:** `jihad-confirm-2026-10-14` (CONFIRM.md: confirmed, homepageURL is meant, delete
this round's incoming and outgoing folders, keep `www.prev`). Wormhole code **6-resistor-dragnet**,
received 10:42 UTC; no reply needed. Copy in `~/Documents/jihad-confirm-2026-10-14.tar`.

**Device:** not touched today; as the night delta below left it.

**Open:** the finger round (docs/FINGER-TESTS.md; deferred, by the owner's word). Nothing is
pending on the server. Codex owes no review.

## 2026-10-13 (night) delta — review round 24: the inspector does Codex's owed review

**The owner:** "do the codex review with the cavekit 3.1 backup inspector agent instead. defer all
finger tests. remove leftover mojo file." Codex is no longer owed anything: T-456 and T-466 are
done by the inspector.

**Reviewed** (five inspectors in parallel, read-only):
- Jihad: `4e480610..6e7b31a0` (Tier 78), `6e7b31a0..5db7860c` (round 22), `5db7860c..9a38a708`
  (Tier 83).
- The site: `9e5521b..d9359ea` (deploy kit and credits) and `upstream/TRUNK..d9359ea` (the PHP fork).

**Results.** Tier 83: REQUEST CHANGES (1 P1, 1 P2, 5 P3). Everything else: APPROVE with P3s. All
fixed:
- **Jihad, `cfbfbcf2` (T-469).** Details in impl-review-findings-6.md, round 24.
  - **P1:** a router's certificate accepted with Trust Always lands in Certificate Manager's store
    and says cA=TRUE. R4 would have made it a root for every site at the next start. Now R4 takes
    only roots: self-issued, keyCertSign, no subjectAltName or extendedKeyUsage. It also never takes
    a certificate the daemon's SSL dialog installed: the daemon raises `jihad-platform-cert`, and
    the SHA-256 goes into `jihad.security.webos_certs.accepted`.
  - **P2:** a blob: frame raised the CA question. The question now needs a one-use offer from a CA
    certificate opened as the page itself.
  - **Also:** the proxy-login marker is now "[proxy] ". webOS's proxy setting keeps its last plan
    when a read fails. The gallery offers the bundled set. Link buttons are 44 px. The kits are
    brought up to date.
  - **Rejected:** matching removed roots by subject and key would refuse GTS R1–R4, GlobalSign and
    Firmaprofesional (in dead-ends.md).
- **The site, `71dd173` and `f9bcb79` (T-470).**
  - install.sh keeps an owner's edited site block. DEPLOY.md step 11 is corrected.
  - The MPL Personas have their licence and source links.
  - The panel's open redirect is closed, and a database outage answers 503.
  - The feed's order and per_page are fixed, and login timing no longer reveals user names.
  - Local copy: smoke test 43/43, and each fix checked.

**On the device** (CE 3.1.0; all three on daemon `06e75a68`, `jihadCerts.js` `7ee7ae12`):
- R4 still trusts the same 5 roots.
- Three certificates placed in Certificate Manager's store:
  - a router's with an IP SAN: skipped as siteLike;
  - one without keyUsage: skipped as noCertSign;
  - a CA with keyCertSign: trusted. Removed again afterwards.
- Trust Once on a router-certificate site logged the marker, and the session serial was swept.
- A blob: CA frame: refused, no dialog.
- The test CA as an HTTP link: asks ("Offered by 192.168.1.245:8896").
- A router certificate as a link: refused.
- Proxy logins read "The proxy …" in Enyo and Mochi; Mojo's sheet reads "[proxy] …".
- The Enyo hook gained `D` (report open dialogs) and `VN` (answer the SSL dialog).

**Not shown on the device:**
- The gallery's bundled offer: every profile already has edition 8, so only a fresh profile shows
  it.
- jihadProxy's keep-last: a failed read cannot be brought about on demand.
- The 44 px buttons: in the finger round.

**The server:** the site update is sent as `jihad-site-2026-10-13c` (SITE.md plus
`riverstone-addons-f9bcb79.tar.gz`, sha256 `13b43fe2…`), wormhole code **5-stupendous-solo**,
received 15:36. The
reply should give install.sh's site-block line, the import of the five MPL Personas (updated at
1.0), the smoke test, and the feed check (`39 of 39`, Aurora Silk's links).

**Device state as left**
- All three on daemon `06e75a68`, no proxy, no hooks, `/` read-only.
- Mojo's leftover `app/assistants/JihadSelfTest.js` (evening delta) is removed: no `*SelfTest*`
  file in any of the three.
- Certificate Manager's store as before: 0 files in /var/ssl/certs, 190 links.
- The test fingerprint pref is cleared, and the device's /tmp test files are deleted.
- LunaSysMgr restarted.

**Open:** the server's reply to `5-stupendous-solo` (T-470), then the finger round (deferred, by the
owner's word).

## 2026-10-13 (evening) delta — the Relay hides users' addresses; T-465 withdrawn

**The owner:** "I do want the relay to hide users addresses, and I want T-465 fixed."

**The Relay and users' addresses (T-468, waiting on the server):**
- Measured earlier today: through the Relay, http://httpbin.org/ip showed the user's home address
  ahead of the server's. Squid's `forwarded_for` is at its default, so `X-Forwarded-For` names the user
  on plain http, and on every https request it re-signs for other webOS clients. Jihad's spliced
  https was never affected.
- Sent as `jihad-relay-2026-10-13b` (RELAY2.md plus `riverstone-addons-d9359ea.tar.gz`, sha256
  `ca773d7a…`), wormhole code **18-hazardous-classroom**, received 13:35. It asks for
  `forwarded_for delete`, with `curl` checks before and after (from the server the client is
  127.0.0.1). It also asks whether the archive peer on :3130 uses the header, and what Squid's access
  log keeps about clients (report only; the owner decides). The site update (`d9359ea`, install.sh's
  site-block line) rides along.
- **The reply** (`~/Documents/jihad-reply-2026-10-13c.tar`, code 7-repellent-eyeglass):
  - `forwarded_for delete` is live since 18:12 UTC (`squid.conf` line 103, above `cache deny all`).
    Parse was clean, and Squid was reconfigured in place.
  - From 127.0.0.1, plain http and bumped https went from `127.0.0.1,116.202.108.111` to
    `116.202.108.111`; spliced (Jihad's UA) was unchanged.
  - Rollback: `doas bash ~/squid-hardening/hide-client-addresses.sh --undo`, or the backup
    `squid.conf.bak.2026-10-13-xff`.
  - The archive (:3130) and setup (:3129) servers never read the header and log nothing.
  - `d9359ea` is live (18:13), with install.sh's new line printed; smoke 43/43. `www.prev` is
    `68caed1`.
- **On the device (Enyo, the Relay chosen):** http://httpbin.org/ip shows only `116.202.108.111`, and
  httpbin still sees Squid's `Cache-Control` (so the page went through the Relay). R2's criterion
  and T-468 are closed. Enyo is back on no proxy.
- **The access log: the owner chose to keep it as it is** (option 1, 2026-10-13). Nothing goes to
  the server. What it holds: Squid's default `access_log` records
  every client's address (field 3) with time, URL (a bumped https request's full URL; a spliced one
  only `CONNECT host:443`), status and bytes. `cache.log` names addresses in some errors.
  - Rotation is by size: logrotate hourly, `size 4500M`, `rotate 2`. That keeps roughly a week to
    ten days on disk (~2 GB a day).
  - The server's abuse handling runs on those addresses: the bans of 06-08, 07-18 and 08-24 came
    from them.
  - Options:
    - keep as is;
    - shorten it, e.g. rotate daily and keep 1–2 days;
    - Squid's `client_netmask 255.255.255.0`, which logs only each client's /24 (abuse handling by
      network, not by address);
    - no address at all.

**T-465 withdrawn: not a redraw bug.**
- Both "old picture" sightings were screenshots taken before the pick ran. `card-selftest.sh run`
  shoots `seconds` after the launch: `page:w10;587,595;w2;s2;w6` with 30 s put the pick at about 30 s.
- Replayed exactly on today's build: the 30 s shot shows the old state, and the pick is logged after
  it; the same steps with 40 s show the new one.
- 15 of 15 picks given time redrew within a second: Enyo and Mochi; No proxy ↔ Relay, My own proxy →
  Relay, and the original Mochi case (own proxy saved, page scrolled deep, shrinks on the pick). The
  adapter's paint log showed every `msgPainted` followed by a paint.
- **`card-selftest.sh run` now prints the shot's UTC time and marks hook lines logged after it**
  (`(after the screenshot)`). If the step a picture should show is marked, the picture is from before
  it. Trap recorded in `context/impl/dead-ends.md`.

**Device state as left**
- All three on the same build (daemon `1a831adc`). No proxy, the adapter paint logs off (gates and
  logs removed), `/` read-only.
- Enyo and Mochi hooks restored (LunaSysMgr restarted).
- **Mojo still has `app/assistants/JihadSelfTest.js` on the device**, from the 2026-10-13 morning
  login test. It is not loaded (its `sources.json` names no hook). The earlier "no test hooks" check
  missed it: BusyBox `find -name '*selftest*'` is case-sensitive. My `rm` was refused by the
  permission classifier; it goes with the next Mojo install, or `card-selftest.sh mojo restore`, or
  the owner removes it.

**Open:** Codex on Tier 83 after Oct 18th, 11:59
AM (T-466, now including `card-selftest.sh` and the site to `d9359ea`); the finger round.

## 2026-10-13 (later) delta — Tier 83: proxies and webOS's certificates

**The owner:** "add support for riverstone relay proxy, and webone, and self hosted proxies in jihad.
also add support for system certificates including community patches if installed." Their answers:
- webOS's certificates: "Added + patched" (not HP's stock roots, not Mozilla-removed ones).
- The Relay: HTTPS passes through untouched. Later the same day: "make using riverstone relay ca an
  option if riverstone relay proxy is installed but off by default".
- The Relay is open (no login).
- A proxy's CA: ask when it is opened.
- Default: No proxy.

The kit is `context/kits/cavekit-proxies-certs.md`; build site Tier 83 (T-457..T-467).

**Built** (Jihad `e223591f`, `9394c08b`, records `b33d5524`; nothing pushed)
- **Settings → Advanced → Proxy:** No proxy (now the engine default too), Use webOS's proxy setting,
  Riverstone Relay, WebOne, My own proxy (HTTP/HTTPS/SOCKS, a direct list), Automatic configuration
  URL.
  - The engine's "system proxy" (type 5) does nothing in the headless build and is gone.
  - webOS's setting: the daemon reads `com.palm.connectionmanager/getNwProxiesConfig` on its own Luna
    connection at start, at every card connect, and when the section is shown.
    `components/jihadProxy.js` applies it.
- **Settings → Security → Certificates** (`components/jihadCerts.js`): at the first page the daemon
  raises `jihad-nss-ready`, and the v3 CAs (basicConstraints cA=TRUE) in webOS's stores are trusted in
  memory, except:
  - HP's 3.0.5 roots;
  - roots Mozilla removed;
  - roots Jihad already has;
  - expired ones;
  - any squid-for-webos CA.

  The lists come from HP's doctor and CCADB (`render/goanna/certs/make-cert-lists.py`). On the CE 3.1.0
  TouchPad it trusts the 5 roots newer than Jihad's NSS (TrustAsia ×2, OISTE ×2, SwissSign 2022-1).
- **The Relay's CA:** pinned in the component; trusted only with the switch on and the Relay in use.
- **Opening a CA certificate asks on the card** (a JS `nsICertificateDialogs`). The question names who
  offered it and only appears for the page itself, never a frame. WebOne's download-marked CA opens
  too. Added CAs are listed with Remove.
- **A 407 names the proxy** (Enyo and Mochi say "The proxy …"; Mojo's webOS sheet is titled "proxy …").
- **Test tools:** `render/goanna/test/jihad-test-proxy.py` (logging proxy; `--auth`; `--mitm` with a
  test CA, serving `/test-ca.crt` and `/proxy.pac`). The Enyo hook gained `W<user>:<pass>` (answer the
  login dialog).

**Verified on the device** (CE 3.1.0; Enyo throughout, Mochi and Mojo for the import, the sections
and a login proxy; kit evidence per criterion):
- **Certificates:** the five roots trusted; nothing written to cert9.db; the SwissSign 2022-1 test site
  loads with the switch on and fails off (TLS sessions cleared through the daemon); a CA in
  Certificate Manager's store trusted after a start and gone after removal; a v1 self-signed
  certificate skipped.
- **Proxies:** manual, PAC, webOS's setting (set with `configureNwProxies`, then cleared), a login
  proxy, WebOne 0.18.3 (PC container; its CA from its link, then https through it), and the Relay
  (re-signing; fails with its CA off, loads on).
- **Refusals:** the Relay's CA from a link, a v1 certificate, certificate frames; "Offered by" shown.

**Review round 23** (inspector; Codex out until Oct 18th): REQUEST CHANGES, with 1 P1 (v1 self-signed
taken as a root), 4 P2 and 10 P3; all fixed or noted in `9394c08b`, and device-checked. The site's 3
P3s are fixed in `68caed1`. Details in impl-review-findings-6.md, round 23.

**Found on the way**
- JS components are read as **Latin-1**: non-ASCII in their strings came out garbled (the print
  status's "…", the Persona importer's BOM strip). They are escaped now. **Use `\u` escapes in
  components.**
- Reinstalling over an adapter LunaSysMgr had mapped left `/` read-write (a deleted file still open).
  The install scripts now leave a byte-identical adapter alone; Mochi, Mojo and Enyo pushes all left
  `/` read-only.
- **Open, T-465:** after picking Riverstone Relay in a card's drop-down (the page grows), the card
  keeps its old picture, its own list included, until the next touch (Enyo, Mochi). The daemon did
  paint. A page growing by itself redraws fine (`/media/internal/jihad-grow.html`, kept for this).

**Server** (Riverstone-Addons `c322904`, `68caed1` on `jihad`, not pushed)
- The server's round-22 reply (`~/Documents/jihad-reply-2026-10-13.tar`): `057dbad` live, smoke 43/43,
  migrate silent. Its two suggestions are done:
  - install.sh replaces an untouched site block in place (a stamped hash), `.new` only for an edited
    one;
  - DEPLOY.md notes `default_server`.
- Sent as `jihad-relay-2026-10-13` (RELAY.md plus `riverstone-addons-68caed1.tar.gz`, sha256
  `df511346…`), wormhole code **7-consensus-backward**; received 12:52 (the sender exited 0 after
  connecting directly to the server). It holds:
  - the Squid rule `acl jihad_browser browser JihadBrowser/` + `ssl_bump splice jihad_browser`
    above the bump rules, with checks;
  - the site update.
- **The reply** (`~/Documents/jihad-reply-2026-10-13b.tar`, code 7-performance-bedlamp):
  - The Relay rule is live since 17:07 UTC: `squid.conf` lines 31–33, above `ssl_bump peek step1`.
    `squid -k parse` is clean, and Squid was reconfigured in place (pid 2631). Through the Relay,
    example.com's issuer is Cloudflare TLS Issuing ECC CA 3 for `JihadBrowser/1.0` and `squid-proxy`
    for any other agent. Rollback: `~/squid-hardening/jihad-splice.sh --undo`, or either
    `squid.conf.bak.2026-10-13-jihad*`.
  - Note for later checks: `curl -v` prints `issuer:` only after a good handshake, so the
    bumped case needs `-k`.
  - `68caed1` is live (17:06), smoke 43/43, the catalogue unchanged. `site-block.sha256` was
    written, equal to the live block. `www.prev` is `057dbad`.
  - Its suggestion, a line when the block is already the repository's, is done in Riverstone-Addons
    `d9359ea`, not deployed: it rides the next site update.
- **On the device (Enyo, the Relay chosen, its CA off):**
  - https://example.com/ loads, and its padlock names Cloudflare TLS Issuing ECC CA 3 (TLS 1.3).
  - http://httpbin.org/ip shows `108.52.189.109, 116.202.108.111`; https shows only the Relay's
    address, with no Squid header.
  - R2 is met. Squid forwards the client's address on plain http (`forwarded_for` at its
    default): the server's business, noted for the owner.

**Device state as left**
- All three pushed from the same build: daemon `1a831adc`, `jihadCerts.js` `cfb5cda3`, engine
  unchanged. Daemons running, `/` read-only, no test hooks; LunaSysMgr restarted.
- No proxy in all three, no Jihad-added CAs; the webOS-certificates switch at its default (on).
  webOS's own proxy setting empty.
- Default look in all three.
- Test assets on `/media/internal`: `jihad-modern-web.html`, `jihad-blur-order.html`,
  `jihad-grow.html` (T-465).

**Open** (superseded by the evening delta above: T-465 withdrawn)
- Codex on Tier 83 and round 22 after Oct 18th, 11:59 AM (T-456, T-466).
- The finger round (`docs/FINGER-TESTS.md`, a proxies section added).
- The desktop build on the new engine.

## 2026-10-13 delta — Tier 82: review round 22 (the inspector; Codex out until Oct 18th, 11:59 AM)

**Codex** ran out at 22:32 on all four ranges of `scratchpad/codex/r22.sh` (146k tokens on the first,
nothing written). Next retry: **Oct 18th, 2026 11:59 AM**, then run the same four ranges
(T-456). The inspector reviewed what no one had: Jihad `a90b7fe3..0821484f`, Jihad `23ffd9af` (the
engine update) and Riverstone-Addons `d66fbc5..jihad`. All three APPROVE; every finding was checked
against the code and fixed or noted (context/impl/impl-review-findings-6.md, round 22).

**Fixed and verified on the device**
- **Keyboard-down blur:** `change` now fires before `blur`. Enyo: a test page's title read
  `order:focus,input,change,blur` after the system put the keyboard away (`enyo.keyboard.forceHide`);
  the daemon's window went 942 → 651 → 942.
- **Settings fonts:**
  - Names are stored as Unicode (`nsISupportsString`). Georgia was written to the profile, and
    Restore left no `font.` pref.
  - The 2 px minimum size is sorted into the list.
  - "Noto Sans Thai" is not a phantom: `/usr/share/fonts/HeiT_nb.ttf` is that font, so the filter
    was right and the kit's note was wrong.
- **Deep links and anchors at load:** the daemon sent a page-made scroll before the page's new
  size, so the card clamped it to the top. The size now goes first. Enyo and Mochi open
  `about:settings#pane=content&section=fonts` on Fonts & Colors.
- **about:addons:** only the setting types the manager knows are laid out. The device check caught
  the first version breaking Palefill's checkbox row, which is now fixed.
- **Card pictures:**
  - The gallery swaps only the pictures that changed, so no card is redrawn.
  - The queue restarts itself.
  - Small headers get a `.small` mark, and failed decodes are not retried until restart.
  - Checked by deleting one picture: it was made again, with no error.
- **Mojo:**
  - The keyboard-away mark is tied to the page `openUrl` opened.
  - **New:** a card opened on a page no longer comes up with the keyboard over it. The start page
    still focuses the address.
- **Engine tooling:**
  - `update-engine.sh` refuses to start unless the branch is at `UXP_PIN` and the queue matches it.
  - `--finish` checks first and can be re-run; `--abort` cannot delete the branch once finishing.
  - `pins()` checks every file before writing; `.gitmodules`' branch is now a pin.
  - The checker covers `loadURI`, `ResizeReflowIgnoreOverride` and 60 app units, and reads ICU from
    the pins. `LoadURIPlain` wraps the last positional call.
  - Checks: 0 FAIL, 0 WARN; pins agree; the start path stopped at "already on RB_20261006".
- **R8's missing device checks:**
  - Mochi and Mojo: howsmyssl TLS 1.3 "Good", Palefill 1.30 enabled, about:config, about:settings,
    and a Persona worn and taken off.
  - Enyo: about:addons and about:settings.
- **Install scripts:** one push left `/` rw ("Device or resource busy" right after ls-hubd and db8;
  the later pushes then kept it rw). The restore is now retried for about 10 s; tested on BusyBox.
  All three were pushed again from a read-only `/` and came back read-only.

**Site (Riverstone-Addons `057dbad`, branch jihad, not pushed):**
- Migration 002's key is retried until it holds.
- The importer updates a Persona whose id is taken.
- The smoke test runs end to end on the server and is stricter on the feed.
- :443 answers only `addons.riverstonerelay.org`.
- Tested on the local copy and a throwaway nginx.
- Sent to the server agent as `jihad-followup-2026-10-13` (FOLLOWUP.md, package sha256 `a5097cde…`)
  and **received at 08:02** with code `4-revenue-transit` (direct connection, wormhole-rs exit 0).
  Earlier codes all lapsed unreceived: the public rendezvous server answered 502 and reset
  `9-determine-algol` and `16-hazardous-suspense`; `597-sympathy-checkup` hit its time limit;
  `4-october-fallout` was replaced at the owner's request. Its `install.sh` keeps the server's site
  block, so the host check is merged there by hand (the steps say how).

**Not fixed, noted:**
- Following the same settings deep link again while it is the address does nothing. An about: page
  cannot `replaceState` (UXP's docshell), and replacing the fragment would scroll.
- A desktop test of the fonts section waits for the desktop build on RB_20261006.

**Device state as left:**
- All three pushed from the same build: daemon `7b02e00b`, engine `jihad/uxp-RB_20261006`.
- Daemons running, `/` read-only, no test hooks; LunaSysMgr restarted after the last push.
- Default look in all three; no `font.` prefs; `:has()` off.
- Test assets on `/media/internal`: `jihad-modern-web.html`, `jihad-blur-order.html`.

**The server's reply** (`~/Documents/jihad-reply-2026-10-13.tar`: REPLY.md and the deploy log): `057dbad`
live 2026-10-13 13:10 UTC; smoke test 43/43 twice; the feed 39 of 39; `migrate.sh` silent (the
`uq_browserId` key is there); the host check merged (helper `merge-site-block.sh`, the old block kept
as `.conf.prev`). Step 4 printed 0, but another site's page answered: nginx there has an explicit
`default_server` on :443 (`share.riverstonerelay.org`), so the host check is defence in depth and
never fires. Its two suggestions for the next site package (T-463):
1. install.sh should replace an unedited site block in place (compare with the previous copy's
   version or a stamped hash) and write `.new` only for an edited one.
2. DEPLOY.md should tell the reader to check `nginx -T | grep default_server` on :443.

**Open:**
- Codex on round 22's ranges after Oct 18th, 11:59 AM.
- T-463: the server's two suggestions, in the next site package.
- The finger round (`docs/FINGER-TESTS.md`, three tests added).
- The desktop build on the new engine.

## 2026-10-12 (night, later) delta — Tier 81: the engine on UXP RB_20261006

**The owner:** "Proceed with the UXP update, with a focus on making future updates easier, and
optimizing the code where possible, while supporting modern web standards. target the latest
release".

**Done** (docs/ENGINE.md has the whole story)
- **Engine:** on UXP release `RB_20261006` (was master `b2594a4`, 2026-06-30). Our 39 commits came
  across with no conflict, one commit per patch now (the squash of 0001–0031 was split). The six
  files both sides changed were read; only `--disable-npapi-gtk2` had to go from the mozconfigs.
  `check-engine-api.py`: 0 FAIL, and the baseline was re-written with no signature changes. The
  branch is `jihad/uxp-RB_20261006` at `706d4782ba`, not pushed.
- **Future updates are two commands:**
  - `build/engine/update-engine.sh [TAG]`: puts the queue on the release with a three-way merge,
    lists the overlapping files and runs the API check.
  - `--finish`: writes the queue again, checks out the new branch and rewrites every pin (the user
    agent, start pages and OE recipe; the bundler reads the ICU name from `engine-version.env`).
  - `UXP_TAG` is now in the pins.
  - `render/goanna/EngineCalls.h` puts the 15 fragile positional engine calls behind named
    wrappers.
- **Optimised:** a release build (dead-code removal, identical-code folding) in Thumb-2.
  - libxul, stripped: 46.2 → 30.2 MB (−35%); its code −43%.
  - Payload: 80 → 73 MB per variant.
  - Idle daemon: 33.8 MB resident, against 36 MB on the old engine.
- **Modern web, measured with `render/goanna/test/modern-web.html`:** `adoptedStyleSheets`,
  `replaceSync`, `URL.parse()` and `revert-layer` now work. `:has()` works with its new Settings
  switch, and is off by default as in upstream releases, because it is slow on some pages. TLS 1.3
  confirmed on howsmyssl.com.
- **Fixed on the way:** `postinst`/`prerm` took the initramfs `rootfs` line for a read-write `/`,
  never remounted it, and failed on a read-only root. The generator now reads the real root
  mount. The daemon includes `nsIDocument.h`, which the new `StyleSheet.h` needs.

**Verified on the device** (a full `push-variant.sh` to each)
- All three: "11 of 11 optional jihad_* exports present".
- Enyo: the feature page before and after; `:has()` switched on, then back off; TLS 1.3; a Persona
  worn and taken off; Palefill enabled; about:config; Flash at 23–25 fps.
- Mochi: the feature page. Mojo: Wikipedia.

**Device state as left:**
- All three on the new engine (bundle `71cef1fd…`; libxul from `jihad/uxp-RB_20261006`), daemons
  running, `/` read-only, no test hooks.
- Default look in all three; `:has()` off.
- `/media/internal/jihad-modern-web.html` is left in place as a test asset.

**Rollback:** the old engine build is `build/webos-oe/out-arm/obj-jihad-goanna-arm.RB-b2594a4` (with
`jihad-browserserver-arm.RB-b2594a4`). Put it back as `obj-jihad-goanna-arm`, rebundle,
`build-variant-ipk.sh`, then `push-variant.sh` each variant.

**Open:**
- Codex round 22 at 22:31 (session cron; the queue is kept out of its diff).
- The finger round (`docs/FINGER-TESTS.md`, engine section added).
- The desktop test build is not rebuilt on the new engine yet (docs/ENGINE.md §7).

## 2026-10-12 (late night) delta — Tier 80: fonts in Settings; no Persona by default; card pictures in the background

**The owner's rules this evening (both in auto-memory):**
- All finger tests wait for one round at the end, collected in `docs/FINGER-TESTS.md`.
- No Persona is worn by default in any variant. Tests may wear one, but put every variant back to
  the Default look afterwards.

**Done:**
- **Fonts (T-438, `11f09e07`, preferences-ui R9).** Settings → Content → Fonts & Colors has fonts per
  script, as Pale Moon's and Basilisk's Fonts & Colors and Advanced fonts dialog offer them: the
  engine's own list of installed fonts, a sample line under each, and Restore default fonts. The
  page link `about:settings#pane=content&section=fonts` opens the section.
  - Licensing: no font is shipped. The device's fonts are used in place: HP's Prelude family, the
    Microsoft core fonts, and the CJK fonts webOS carries. The code is our own MPL-2.0.
  - Device, Enyo: Georgia was picked for Serif and the serif text was drawn in it; Restore default
    fonts brought back Times New Roman. The section draws correctly in all three variants.
- **Default look (T-440, `97f5e871`).** The test Personas were taken off in all three variants.
  Fresh profiles already wore none: nothing sets `isThemeSelected`.
- **Card pictures (T-441, `97f5e871`).**
  - The cause: making pictures inside the gallery's own request held it 200–600 ms a card, the
    budget ran out by the eighth, and decodes failed under image-cache pressure. Carbon Light kept
    its full header, the one the owner saw flashing.
  - The fix: a background queue makes them one at a time, takes the size from the decode, writes
    natively and discards each decode.
  - Device, Mojo: all 16 made in one opening; every card drawn.
  - Mojo ignores `palm-launch`'s target parameter, so open its pages through the test hook.
- **Server.** It replied (`41-savagery-shamrock`, kept in `scratchpad/server-reply/`): package
  `5c1d54c` is live, migrations 001 and 002 are in, 24 Personas were imported (39 listed), the
  smoke test passes, and the credits are served. Its notes:
  - the Persona list's column drift: fixed (Riverstone-Addons `f148f1e`, which also records the
    deploy in DEPLOY.md);
  - Free Palestine's `license` stays a sentence, because the site's card shows that field as its
    credit;
  - Free Palestine's id matches in both repositories.
  - Nothing more for the server until Codex round 22.

**Device state as left:**
- All three variants have the same `deviceroot/hl` contents (the chrome scripts are those of
  `11f09e07`; `push-engine-update.sh` prints the id); daemon `644eba8a…`; libxul unchanged.
- No test hooks.
- Default look in all three (no Persona worn).
- Enyo's Western font settings are at their defaults (Restore default fonts was run after the
  Georgia test).

**Open:** Codex round 22 at 22:31 (session cron), then the finger round when the owner calls it.

## 2026-10-12 (night) delta — Tier 79: the owner's evening list; review rounds 20–21

**The owner's list**
- Select All in the URL bar's Cut/Copy bubble.
- Momentum on Settings and about:personas.
- Personas flashing (Carbon Light 2.0).
- The keyboard down when Settings or about:personas opens.
- Extension settings cut off.
- A caret left in about:addons' search field after the keyboard closes.
- Typing in text boxes works (the owner's finger).

**Done (Jihad `272ce0cd`)**
- **Keyboard down on Jihad's pages:** opening about:settings, about:preferences, about:personas or
  about:addons from the address field or the app menu takes the focus off the address field.
  - Enyo blurs in `Browser.urlChanged`.
  - Mochi blurs in `keyboardAwayFor`, from `openUrl` and `urlChanged`.
  - Mojo blurs in `keyboardAwayFor`, from `openUrl` and on arriving by a link.
- **No caret left behind:** the daemon clears the page's focus when the window grows back by 120 px
  or more at the same width while a field is focused (`BlurFocusedEditable`). The engine's blur
  then reaches the shell as editor-unfocused.
- **Card pictures:** an installed Persona's card draws an 800 px copy of its picture
  (`<24 hex>-thumb.jpg` in `jihad-themes`), made at most 1.2 s' worth per opening and pruned.
- **Add-on preferences:** each preference is its own block, text fields are dark, and the
  desktop margins are trimmed.
- **Mochi flicks:** Mochi now defines `Mojo.handleGesture`, LunaSysMgr's callback for a card's
  gestures. Enyo 1 has it and Enyo 2 lacks it, so the earlier DOM `flick` listener could never fire.
  Flicks are passed in whole numbers.
- **Inspector round 20, fixed:**
  - about:addons measures only the view it shows;
  - a page's own scroll jump within 300 ms of a pan is now applied instead of lost;
  - CREDITS covers the README strip's CC pictures;
  - AMO card state, https-only redirects, and a full /tmp are handled;
  - formerly bundled Personas keep their licence lines;
  - the README is up to date;
  - dead code removed.
- **Site agent:** fixed the site's round-20 findings (`6845226`..`d66fbc5`). Colour Personas' ids
  now come from their colours (kits updated). There is a Cloudflare real-IP conf, and the smoke
  test checks the feed contract (37/37 locally).

**Verified on the device** (bundle `219f12cd…` plus the project-drawn licence line; daemon rebuilt
with the focus and echo changes; all three variants)
- **Focus, all three:** after focusing the address field, opening a Jihad page left the focus on
  BODY; example.org left it on INPUT. In Mochi and Mojo the window grew from 705 to 996 px, so the
  keyboard went down.
- **Card pictures, Enyo:** 2, then 9 copies were made over three openings. They are real
  800x53 / 800x80 pictures, the cards draw them, and each shows its licence.
- **Preferences, Mochi (Palefill):**
  - Before: the controls ran past the right edge and the page zoomed out to 0.78.
  - After: everything is inside the page, with no sideways scrollbar.
  - The manager still scrolls its detail box down to the preferences, so the add-on's name sits
    above, in a box the card cannot pan.

**Needs a finger (the owner)**
- Flicks coast in Mochi, Enyo and Mojo on Settings and about:personas.
- Closing the keyboard over about:addons' search field leaves no caret. A scripted tap focuses the
  field but raises no keyboard.
- The flashing is gone.

**Select All (T-436, `a90b7fe3`):** it can't be added to the URL bar's Cut/Copy bubble, because
the system draws that bubble (none of the shells, Enyo 1 or LunaSysMgr's sources do). The owner
chose select-on-tap for all three:
- Enyo: `selectAllOnFocus`, already there.
- Mochi: Enyo 2's `selectOnFocus`, new.
- Mojo: `focusSelectMode`, already there.

Verified on the device with hook steps `K` (focus), `S` (selection) and `RF` (refocus with a caret
at 3, against a bare input):
- Enyo and Mochi select 0–20 of 20 while the bare input keeps its caret.
- Mojo, blurred (`B`) then focused, selects 0–20 of 20.
- Don't use `RF` on Mojo: its widget swaps the input for a div and the address empties. It was
  removed from that hook.

**Reviews:** Codex ran out again at 17:3x after 389k tokens, before writing its findings; retry
**10:29 PM**. Its notes named the focus-clearing path and the AMO install flow as the riskiest. The
inspector is reviewing in its place (round 21): Jihad `6e7b31a0..a90b7fe3`, site `26a9fdf..d66fbc5`.

**Round 21 fixed (`5ccc75a5`; site `2923301`..`5c1d54c`):**
- **Daemon:** the keyboard-down blur moved into the guarded pump (it ran page script inside a
  socket callback). A field in a frame is cleared and reported by the daemon itself.
- **Card pictures:** PNG kept PNG, 1400 px, all pruned on each opening. Device, Enyo: the 800 px
  ones are gone, the 14 Persona pictures intact, the cards drawn.
- **about:addons:** hidden settings stay hidden; checkbox titles wrap. Device, Mochi: Palefill
  still fits.
- **Shells:** Mochi's blur no longer submits a half-typed address; Mojo no longer blurs twice.
- **Site:**
  - real IP in our own server block;
  - UXP's colour grammar;
  - migration 002 (unique `browserId`);
  - smoke test 43/43 with `RS_SMOKE_CONNECT`;
  - credits served at `/credits/*.txt`.
- Free Palestine's licence line reads "based on "Village of Battir" by Labour Palestine, CC BY
  2.0" in both repos.

**Sent to the server agent:** folder `jihad-reply-2026-10-12`, holding `REPLY.md` and
`riverstone-addons-5c1d54c.tar.gz` (sha256 `40a2dd4c147a899c…`). It went over wormhole-rs with
code **46-determine-drunken**, for the owner to relay. REPLY.md has the owner's overrides, what
was done per section, the feed contract, the deploy steps, and the memory-note changes.

**Device state as left:**
- All three variants on bundle `37c3757ca422b7bfddc35373b24b98fe`, daemon `644eba8a…`; libxul
  unchanged (`ddf8cc70…`); daemons running.
- Card scripts: Mochi `JihadBrowser.js`/`JihadWebView.js` and Mojo `main-assistant.js` as in
  `5ccc75a5`; Enyo `Browser.js` as in `272ce0cd`.
- No test hooks, no user.js, no test CA; `/tmp` 1% used.
- Enyo wears Space Fantasy, and its `jihad-themes` now holds 11 card pictures beside the 14
  Persona files. Mochi wears Aurora Silk, Mojo Lime Fizz.

**Open, in order**
1. **Codex round 22 at 10:29 PM.** A session cron (one-shot, 22:31) runs
   `scratchpad/codex/r22.sh` in four slices, newest first:
   - Jihad `6e7b31a0..HEAD`;
   - site deploy;
   - Jihad `4e480610..6e7b31a0`;
   - site PHP.

   A single run burned out at 389k tokens, so the range is split. If this session has ended, run
   them by hand with `run.sh`; it now takes `HEADREF` for an end commit.
2. **Finger tests: deferred, all of them, to one round at the end** (the owner, 2026-10-12). They
   are collected in `docs/FINGER-TESTS.md`. Add new ones there; don't ask the owner piecemeal.
3. **Server:** the server agent deploys per REPLY.md.
4. **Known gaps:**
   - the same palette from AMO and from the site is two Personas;
   - a layered Persona's id comes from the merged header;
   - in about:addons, a Preferences tap scrolls the detail box past the add-on's name, which the
     card cannot pan back to.

## 2026-10-12 (evening) delta — Tier 78: the server agent's work order, the gallery, each shell's look

**The inputs**
- The owner's asks: the gallery's load flicker; each shell's own buttons; a Free Palestine Persona,
  then "an artistic depiction of palestinian land", then "photo realistic".
- The server agent's work order, `~/Documents/PROMPT-PC.md`: the gallery showing
  the site, bundling two, more catalogue formats, momentum, and about:addons in the webOS style.
- The owner's answers along the way:
  - bundle Free Palestine + Aurora Silk;
  - MIT colour palettes allowed, credited;
  - the gallery shows two previews per source, a full search of each and links to the websites,
    with the site's whole list staying on its own page;
  - addons.mozilla.org searched through its API, since its pages show this engine a robot check;
  - Personas managed in the gallery, because the card cannot scroll about:addons' lists;
  - about:addons dark, like Jihad's other pages: the light webOS look clashed.

**Done (Jihad `89571fb6`, `6128e29b`; Riverstone-Addons `b939443`..`26a9fdf`, built by a subagent to a fixed feed contract)**
- **about:personas:**
  - opens at once, and nothing moves or redraws while it loads;
  - Your Personas: wear, take off, remove (asks again), Undo in the toast, Default look, Install
    from file;
  - the bundled ones that aren't installed;
  - the site and AMO, two previews each, searched in place, each with a link to its website;
  - AMO Install fetches the theme from AMO's hosts only;
  - `#site-q=WORDS` links to a site search.
- **Bundle:** Free Palestine (from the CC BY 2.0 photo "Village of Battir" by Labour Palestine,
  credited) and Aurora Silk, edition 8. The rest are in the site's `catalogue/`, and a push now
  removes no-longer-bundled pictures from the device.
- **Look:** each shell's buttons on Settings, about:personas and about:addons (`shell.js`/`shell.css`,
  from `JIHAD_BS_NAME`). The settings tabs wrap. about:addons is dark with light text, the shell's
  buttons, toolbar buttons and dropdowns, and links drawn as links. Its Personas category is the worn
  one, Default look and a link to the gallery. The site's new discover pane is darkened inside it.
- **Scrolling:**
  - the daemon echoes no scroll while the card streams positions (an echo reset coasts on
    zoom-1 pages);
  - Mochi forwards flicks;
  - about:addons' root grows to the length of the list it shows, so the card can pan it.
- **Mojo:** the lost-connection panel floats under the bar instead of moving it.
- **Site:**
  - migration 001 (kind, colors);
  - the importer's three kinds (a colour theme gets a drawn header, layered ones are merged);
  - the feed's `kind`/`colors` strings;
  - 23 MIT palettes;
  - the discover pane in the Jihad skin;
  - the panel's text;
  - fail2ban's include;
  - DEPLOY.md's "The update of 2026-10-12".

**Verified on the device** (bundles up to `cddf3ea3…`, daemon `d200a97f…`, all three)
- **Gallery, Enyo:** the gallery against the live site and AMO; an AMO install through the confirm;
  Catppuccin Mocha from the local copy colouring the toolbar. Both profile tests were put back
  md5-identical.
- **Buttons and about:addons:** in all three.
- **Mojo:** the bar holds still during a lost connection.

**Needs a finger (the owner):** flicks coast on about:personas and Settings (Enyo, Mochi, Mojo); a
long about:addons list pans; typing a search.

**Device state as left:** all three on bundle `cddf3ea3941af6d8c055d7490c76d56e`, daemon
`d200a97f…` (libxul unchanged), daemons running; no test hooks, no user.js, no test CA; `/tmp` holds
nothing of ours; Enyo wears Space Fantasy (profile md5-identical to before the tests), Mochi Aurora
Silk, Mojo Lime Fizz; each profile has Free Palestine added (not worn). Local copy running with the
catalogue imported (40 Personas).

**Open, in order**
1. The inspector on both ranges (running), then Codex at 5:29 PM on the same ranges. Fix, record.
2. Pack the site (the catalogue travels inside it), write the reply to the server agent, send both
   with one wormhole code for the owner to relay.

## 2026-10-12 (later) delta — Settings: Personas, Extensions and Plugins, one button each

**Done** (`7cd6a158` and the round-19 fixes after it; `cavekit-preferences-ui.md` R8, build site
Tier 77, all criteria met). The owner asked for:
- a clear route to about:personas and extensions in Settings on all three variants;
- the extension not named as the row's subheading;
- plugins with the Flash Player's details;
- one button per row.

The Browser pane of about:settings now starts with a "Personas, Extensions and Plugins" group (blue
buttons). It replaces the old Appearance group:
- **Personas:** what is worn and how many are installed. **Browse Personas** opens about:personas,
  whose "Personas manager" link opens about:addons on its Personas list (take off, remove, Undo).
- **Extensions:** "Add features to web pages and to the browser. N installed" (and how many are
  off). **Manage Extensions** opens about:addons on its Extensions list.
- **Plugins:** "Adobe Flash Player 10.3 d185, on. From the HP Flash plugin installed on this
  device." **Manage Plugins** opens about:addons on its Plugins list.

**The inspector (round 19):** APPROVE, with 1 P2 and 4 P3, all fixed.
- Flash on "Ask to Activate" never plays here. The row now says so; the Content pane's Flash row shows
  it instead of a blank list; and the daemon's `getFlash` reports only state 2 as on, which needed a
  daemon rebuild.
- About reads the plugin host, so a Flash that is off no longer reads "not installed".
- The kits were updated for the new route.
- `render/goanna/test/prefs-addons-rows.test.js` covers the wordings (8 cases).
- The buttons are no longer the red of a confirming Clear.

**Verified on the device**
- All three variants: the group renders, on a page opened through each shell's own Settings entry,
  and each button lands on its page. The taps came from the hooks, not a finger; the pages were read
  back and photographed. The final bundle was re-checked on all three.
- Enyo, with `prefs.js` edited while the daemon was stopped (then put back md5-identical): state 1
  and state 0 each read the same in all four places. The manager link lands on the Personas list.

**Open**
1. Codex on `7cd6a158` and its fixes, when credits return (5:29 PM), together with the site's PHP
   part (afternoon delta, item 1).
2. The afternoon delta's other items are unchanged.

**Device state as left**
- All three variants on bundle `23953a34e209e90c358275c5e89c0dde`, daemon `4d8502ab…` (libxul
  unchanged); daemons running.
- No test hooks (the shipped manifests were checked by md5). No user.js, no test CA.
- Enyo's `prefs.js` is as before the test; Flash is on everywhere.
- Personas as below. `/tmp` holds nothing of ours. The test hooks gained Mojo's `t` (a tap).

## 2026-10-12 (afternoon) delta — round 17 verified on the device; Codex round 18 on the deploy kit fixed

**Verified on the device** (the TouchPad connected at 12:28; one task at a time)
- Bundle `eaa828a1877aa3b441213d51b6c2524e` on all three variants (the id read back from each).
  Enyo's `BrowserApp.js` and Mojo's `main-assistant.js` (round 17's UI fixes) were pushed with
  `push-card-js.sh`, and each card's boot stamp showed in the log.
- `test-site-profile.sh` under the device's BusyBox 1.17, on a scratch app
  (`JIHAD_TEST_APP=/tmp/fakeapp`, a copy of Enyo's profile):
  - setup, a test's changes, then restore → md5-identical;
  - a stray file planted in the backup → restore refused, profile untouched;
  - a restore cut off between its moves → finished.
  Then real cycles on Enyo and Mojo: both profiles md5-identical afterwards, with no CA, no user.js
  and no backup left.
- about:personas update check (local copy): the test Persona installed at 1.0.3. The site at 1.0.2
  → "Your Personas are up to date."; at 1.0.4 → an Update card for 1.0.4.
- Enyo, on a card started on the start page with a light-field theme: the reload and stop glyphs are
  drawn ink.
- Mojo share menu: a highlighted row's label takes `popup_highlight_text`. This was read from the
  stylesheet, with the row's `selected` class set by the hook, not under a finger.
- about:personas shows "Licence: MPL-2.0" on the five project-drawn Personas.
- Test tooling, now committed:
  - Enyo hook step `G` (the glyphs; it runs on the start page);
  - Mojo hook step `H` (a submenu's colours);
  - `card-selftest.sh … run <scenario> -` launches with no address.

**Codex round 18** (credits back at 12:28). The site range was split, because it never fits in one
window:
- **`deploy/`: done.** 2 P1, 5 P2, 1 P3, all fixed in site `9e5521b` and tested on the local copy
  and scratch directories (`impl-review-findings-6.md`, round 18):
  - php-cli installed by name;
  - both nightly archives watched;
  - a Persona import changes the files and the row together or not at all;
  - the smoke test accepts the allowlist's 403;
  - the owner account change is logged;
  - the local copy imports the Personas at every start;
  - unknown install.sh arguments are refused;
  - swap-in also refuses empty directories and special files.
- **The PHP part: ran out again.** Retry at **5:29 PM, 2026-10-12**.

**Open, in order**
1. Codex on the PHP part of the site. The prompt now tells it to stay off the web:
   `DIFFOPTS=--diff-filter=d EXTRA="This part is the PHP site (everything outside deploy/, which was
   reviewed separately)." scratchpad/codex/run.sh ../Riverstone-Addons upstream/TRUNK OUT LOG . ':!deploy'
   ':!libraries' ':!*.png' ':!*.jpg' ':!*.gif' ':!*.ico'`. Then fix, record, and stop the local
   copy (`deploy/local/down.sh`, no wipe).
2. The deploy guide: the copy sent with round 17 (`41-confidence-breakup`) timed out unreceived.
   DEPLOY.md is unchanged since `b9810ad`. Send it with wormhole-rs when the owner asks for a code.
3. The owner's items from the 2026-10-11 delta (deploy, typed search, landscape) are unchanged. The
   root-on-Devuan parts of the deploy kit (OpenRC, cron, nginx, the login message) are checked only
   by reading the code.

**Device state as left**
- All three variants on bundle `eaa828a1…` (daemon `5183c623…`, libxul unchanged `ddf8cc70…`),
  daemons running. Enyo's and Mojo's app sources are as committed, plus dev stamps from the pushes.
- No test hooks: the shipped manifests are back, checked by md5. No user.js, no test CA.
- Enyo wears Space Fantasy and Mojo Lime Fizz; both profiles md5-identical to before the tests.
  Mochi was untouched and wears Aurora Silk.
- `/tmp` holds nothing of ours (YAP sockets only). No Jihad card is open (the last LunaSysMgr restart
  closed them).
- Local copy `riverstone-local` running (PHP 8.4), 16 Personas; the test Persona is back at 1.0.3.

---

## 2026-10-12 delta — Codex round 17 on the Jihad range fixed; the site range still owed

**Done**
- The updated deploy guide reached the owner's desktop over wormhole-rs (the first send waited out
  its two hours unreceived; a fresh code worked).
- **Codex finished the Jihad range** `69c44675..83f0e817`: 1 P1, 5 P2, 4 P3, all fixed in
  `df590b3b` except one kept by design (`impl-review-findings-6.md`, round 17):
  - `test-site-profile.sh` judges every copy by md5, never by `cp`'s status (the device's BusyBox
    `cp` can report EBADF for a copy that landed). The backup records each folder's entry count
    (hidden and nested entries too) and every file's md5; restore refuses a backup that does not
    match, before touching anything. `extensions.ini` and `addons.json` are backed up too. A restore
    that does not finish leaves the daemon **stopped** and the backup kept: run restore again.
  - about:personas offers only a higher version as an update; an answer that is not about the
    Persona counts as not checked.
  - A colour-only Persona's drawn picture keeps translucent colours translucent (opaque ones are
    byte-identical to before, so their ids do not change); a multi-picture theme failing part-way
    removes the pictures it put in place.
  - Enyo: the ink reload/stop glyphs on a light field no longer need the browser view to exist.
    Mojo: highlighted menu labels take the theme's highlight text colour.
  - By design: updating or re-installing the worn Persona has no Undo (`cavekit-personas-ui.md` R3).
- Verified here: `test-site-profile.sh` in a local simulation (dash, a fake novacom and upstart, the
  engine's certutil): a full cycle left the profile identical; a `cp` that copies and then reports
  EBADF → setup and restore still succeed; a folder copy really cut short → daemon stopped, backup
  kept, the second restore finished identical; a changed nested file, an added hidden file, a
  changed backed-up file and an old-format backup are each refused with nothing touched. The
  gradient: opaque output identical to the old code's, the translucent one decodes as RGBA.

- **The inspector on the round-16 deploy fixes** (`cdaed4c`): REVISE, 1 P1 + 3 P2 + 9 P3, all fixed
  in site `b9810ad` (round 17 in the findings file). install.sh puts back nginx rules this server's
  nginx rejects and stops (the P1: `nginx -t && …` never stopped it), clears its stamp while it
  runs, runs only as the copy in place and needs cron. The new `migrate.sh` brings the database up
  to a copy BEFORE `swap-in.sh` puts it live (dump first; a migration only adds and runs twice
  harmlessly; a rollback names what it lacks). The new `watch.sh` (cron.daily) puts certificate and
  backup trouble on the panel's front page and in the login message. `swap-in.sh` refuses three
  more ways of losing the way back; `pack.sh` sends only `jihad`; the local copy re-issues its
  certificates and applies migrations. Tested on a throwaway MariaDB 10.11, scratch copies and the
  local copy (34/34); the root-on-Devuan parts are code only.

**Open, in order**
1. **Codex on the site range** `upstream/TRUNK..jihad` (now through `b9810ad`): it ran out again at
   ~150k tokens; retry **12:28 PM, 2026-10-12**. The owner's deploy guide changed with `b9810ad`:
   send it to the desktop again.
2. **When the TouchPad is connected** (one task at a time):
   - push bundle `eaa828a1877aa3b441213d51b6c2524e` (it also carries the plain `MPL-2.0` licence
     line) with `build/webos-oe/push-engine-update.sh --daemon-only enyo mochi mojo`;
   - reinstall the Enyo and Mojo app packages (the glyph and menu fixes are UI code);
   - run `test-site-profile.sh` on a scratch app directory first (`JIHAD_TEST_APP=/tmp/fakeapp`,
     under the device's BusyBox 1.17; the simulation used dash), then a real cycle on Enyo;
   - then check the about:personas update check against the local copy, the Enyo glyphs on a light
     field, the Mojo highlighted menu text, and an about:personas card's "Licence: MPL-2.0".
3. The owner's items from the 2026-10-11 delta (deploy, typed search, landscape) are unchanged.

**Device state as left:** unchanged since 2026-10-11 (below); the TouchPad was not connected at
00:32 or at 07:48 (`novacom -l` empty). Nothing was pushed.

---

## 2026-10-11 delta — Jihad's add-on site (built and tested locally, not deployed), three more Persona formats, review round 14 (READ FIRST)

**The owner's choices** (the Persona-index options, 2026-10-11): a Phoebus add-on site at
`addons.riverstonerelay.org`; colour-only themes, layered pictures and more colour slots; "Originals +
vetted CC"; build it locally first, with nothing published; their Devuan + nginx + OpenRC server;
the full Phoebus feature set, with Personas the only content for now; about:personas as a native
gallery plus the site; a Palm-era skin; submissions from the owner only; updates only when asked.
Kits: `cavekit-persona-formats.md`, `cavekit-addons-site.md`; build site Tiers 75–76 (T-390–T-414).

**Built**
- **Jihad** (`9e104699`, `7bf951a1`, `efa6844a`, `948e1c88`):
  - Colour-only and layered theme packages install as Personas. Extras live beside the Persona in
    `profile/jihad-themes/extras-<sha24>.json`.
  - A theme's other colours reach the address field, the menus, Mojo's command row and the start
    page.
  - Prefs point at the site: getAddons, discover, update, `galleryURL`/`siteURL`, and the install
    permission.
  - about:personas pages through and searches the site's Personas, and has "Check for updates".
  - No background update checks.
- **The site** is in `../Riverstone-Addons`, branch `jihad`. **Its only remote is `upstream`, which
  is Moonchild's Phoebus: never push there.** The owner creates the project's repository and adds
  it as `origin`. What it has:
  - the fork's hygiene, with licences and NOTICE;
  - PHP 8.2/8.4;
  - hardening;
  - Personas with an importer from `render/goanna/personas/personas.json`;
  - a JSON feed;
  - the Jihad skin;
  - a rootless local copy (`deploy/local/up.sh` / `down.sh`);
  - the deploy kit (`deploy/DEPLOY.md`, `deploy/server/*.sh`).

**Verified on the device** (against the local copy over the LAN, with its test CA in a test profile)
- Colour-only and four-layer Personas in all three shells. The colour-only bar is now stretched:
  Enyo measured #3e2164 at the top and #7c3aa8 at the bottom.
- The colour slots in all three shells. A classic Persona puts every slot back.
- Uninstall leaves nothing behind (Enyo).
- Re-installing the worn Persona with new colours repaints it (#cc2222).
- `hsl()` arrives as `rgb()`; a value carrying a shadow is dropped.
- An SVG-only theme: its picture is left out, and the Persona is offered and worn on its colours.
- The site's feed in about:personas. Its pager goes from page 1 of 2 to 2 of 2; "More on the web"
  opens `/personas/`.
- Install from the feed. Check for updates → Update (the picture's md5 changed).
- Wear on the site's page. The discover pane.
- about:addons Check for Updates, 1.0 → 1.1.
- Offline, about:personas says the site cannot be reached.
- Screenshots in Enyo: the front page, `/personas/`, an add-on page and a 404 in the skin.

**Verified on the local copy**
- Smoke test 31/31 on PHP 8.4 and on 8.2, with every page type and the panel's pages; the PHP log
  stayed empty.
- A POST without the token, or from another origin, gets 403.
- A hostile Persona name shows as text in the page, in the `data-browsertheme` JSON and in the feed.
- An unreviewed add-on is 404 publicly and still served by the panel.
- `persona-admin.php` hide, show and delete work; the delete leaves symlink targets alone.

**Reviews**
- Codex r13 (Jihad, morning): fixed.
- Inspector round 14, standing in for Codex, on both repos: one P1 (the panel path) and the
  P2/P3s, all fixed. See `context/impl/impl-review-findings-6.md`.
- Inspector round 15, on the round-14 fixes: APPROVE for both. The P2 (picture sizes could be
  under-read) and eighteen P3s are all fixed, and the dangerous ones were checked on the device.
- **Codex owes a review** of Jihad `69c44675..HEAD` and of the site's `upstream/TRUNK..jihad`.
  It ran out of credits again at 17:00, and again at 22:10 (after ~216k/243k tokens, before writing
  a finding); retry at **3:07 AM, 2026-10-12**. The site range now includes the wormhole-rs deploy
  (`8535d3b`..`cdaed4c`). The inspector reviewed it as round 16 (APPROVE, 2 P2 + 12 P3, all fixed in
  `cdaed4c`: copies checked against a manifest before going live, `www.prev` as the way back, an
  install stamp deciding when install.sh must run, `deploy/migrations/`, the certificate warned of
  by the smoke test; `impl-review-findings-6.md`).
  The wrapper is `codex exec -m gpt-5.6-sol -s read-only` with Cavekit's prompt and the diff (see
  the codex-gate memory); give the site diff `--diff-filter=d` and leave out `libraries/`.

**TRAP — it did real damage.** The TouchPad's BusyBox 1.17 `grep` has **no `-x`**.
`test-site-profile.sh restore` tested membership with `grep -qxF … || rm`. Every test errored, so
both of the day's Enyo restores deleted *everything* in `profile/jihad-themes/` and
`profile/extensions/`.
- Fixed, and then redesigned in round 15: restore no longer decides what to delete by matching
  names. Setup copies the whole of `jihad-themes/` and `extensions/` (and every profile file a test
  touches) into a backup that is written as `$BAK.tmp` and renamed only when complete. Restore
  refuses an incomplete backup or a short folder copy, and otherwise swaps the folders back.
- Tested on a scratch profile on the device (`JIHAD_TEST_APP=/tmp/fakeapp`): a test's added,
  deleted and rewritten files all came back md5-identical; the refusals changed nothing; an
  interrupted restore finished on a second run. Then two real cycles on Enyo were md5-identical.
- Enyo repaired:
  - its 13 pictures copied from Mochi under the same names (Mochi's and Mojo's copies are
    md5-identical);
  - Palefill re-offered by deleting `jihad.bundled-addons.palefill@addons.martoks-place.de.offered`,
    which reinstalled 1.30, active.
- The jihad-site-test add-on (a test file) went with it.
- **After any device-side clean-up, count what is left, not only what was meant to go.**

**Open, in order**
1. **Codex re-review** of both ranges (above). Fix the findings, then re-test on the local copy and
   on the device.
2. **[OWNER] Deploy**, following `../Riverstone-Addons/deploy/DEPLOY.md`, which is now numbered
   steps in the order they happen. **Every file goes over magic-wormhole-rs** (`wormhole-rs`; the
   owner's rule, 2026-10-11: no other wormhole may be installed, not the Python `magic-wormhole`
   that apt and xbps offer). `deploy/server/pack.sh` sends the last commit, and `swap-in.sh` puts it
   in place on the server; the Personas and the backups go the same way (a folder arrives as
   `<name>.tar`). `sync.sh` (rsync) is gone (site `8535d3b`, `fd41f7e`). In short:
   1. wormhole-rs is already on the PC (`~/.cargo/bin`) and on the server.
   2. Point DNS for `addons.riverstonerelay.org` at the server.
   3. Send the site and put it in place with `swap-in.sh`.
   4. On the server, as root, run `install.sh`, then `make-owner.php` (it asks for the password).
   5. Send the Personas and import them.
   6. Run `smoke-test.sh`.
   7. Install a Persona from a desktop Pale Moon or Basilisk, and from Jihad (R10).

   A repository of the site's own is optional (hosting doesn't need one); its only remote is still
   Moonchild's `upstream`, which is never pushed to.

   Until then, Jihad points at a site that does not exist. That is by design: about:personas says it
   cannot be reached, and the discover pane shows its offline message.
3. **[OWNER, finger]** Typed search in about:personas (the on-screen keyboard).
4. **[OWNER, hands]** The site in landscape on the TouchPad itself (R7). A desktop, a phone and
   1024×768 were checked in headless Firefox; they read well.
5. Undo, Default look and editions with the new formats have been checked in code only.

**Testing against the local site**
1. Run `../Riverstone-Addons/deploy/local/up.sh` (`PHP=8.2` for 8.2). The CA is at
   `deploy/local/state/tls/ca.crt` and the owner password at `state/owner-password`, both
   git-ignored.
2. Run `build/webos-oe/test-site-profile.sh setup <variant>`, test, then `restore <variant>`.
3. Run `status`, and count `jihad-themes/` and `extensions/`.

Click coordinates: Enyo's and Mochi's `clickAt` take view pixels (device y − 82); Mojo's are
card-relative (device y − 28). Only a finger pans, so jump with anchors (`about:personas#online-page`,
`#check-updates`), and use a `U<url>` step to re-jump after a tap. Phoebus refuses curl's user agent;
pass `-A JihadBrowser/1.0`.

**Device state as left**
- **Not yet on the device:** bundle `b3476e74b62eb6202250da58e0020bc6` (the five project-drawn
  Personas' licence reads plain `MPL-2.0`, without "(drawn for Jihad Browser)"; the owner's ask,
  2026-10-11). The TouchPad was not connected (`novacom -l` empty); push it with
  `build/webos-oe/push-engine-update.sh --daemon-only enyo mochi mojo` and check an about:personas card.
- All three variants on bundle `e6f75a783e82e5717c7b1b9e8d487008` (daemon-only pushes, round-15
  component), daemons running.
- No test hooks, no user.js, no test CA.
- Enyo wears Space Fantasy, with 13 pictures and Palefill 1.30 active. Mochi wears Aurora Silk and
  Mojo Lime Fizz.
- Test Personas removed from all three. Carbon Light's bundled details restored in Enyo.
- `/tmp` holds nothing of ours. The 18 stale YAP sockets of dead daemons were removed; the live
  ones were kept.

## 2026-10-08 (night) delta — complete themes, the Persona gallery, a licensed bundle, engine-update groundwork (READ FIRST)

**The owner's eight asks and what came of each:**
1. **Complete themes** — investigated (`docs/research/complete-themes.md`): they skin XUL chrome,
   and Jihad's look lives in the cards, which only Personas reach; wearing one would switch the
   Persona off, needs a restart path this embedding lacks, and a skin missing a required file can
   stop the engine at start-up. Decision: not supported. `jihadInstallPrompt.js` explains and
   points to Personas; a toolkit-targeted one that would install is taken straight back out.
   **Device (Enyo):** a Pale Moon complete theme → refused with the message; a toolkit one →
   installed then removed, nothing left in the profile.
2. **"Get Personas" repository** — `about:personas` (packaging/prefsui/content/personas.*), Jihad's
   own gallery (Pale Moon/Basilisk use their Phoebus sites; Basilisk's `lightweightThemes.getMoreURL`
   is honoured). Cards with picture, author, licence, Wear; an online https index
   (`jihad.personas.galleryURL`, empty by default) installs through the usual confirm — **the owner
   decides whether and where to publish one.** **Device:** Wear from the gallery works.
3. **Licences** — survey `docs/research/persona-licences.md`. Bundled: our five + ten CC BY / BY-SA
   Firefox-era Personas (pinned sha256, `import-third-party.py`; credits `CREDITS.md`, `NOTICE`,
   cards). Removed: Water-Like test assets (ARR; tests use Carbon Light), every README picture with
   an unlicensed Persona (retaken), and those Personas from the device profiles (Running Foxes,
   Aurora Borealis Delights, Blue Nebula, Dark Fox, Purple Night, Water-Like, test Personas).
4. **Names** — Bubble Lagoon, Cloud Nine, Meadow Morning, Aurora Silk, Lime Fizz (formerly Aero
   Aqua/Sky/Meadow/Ribbons/Orbs; renamed in place on every profile, uninstalled ones stay so).
5. **Clean-up** — see "Device state" below; scratch files deleted at the end of the session.
6. **README** — 333 → 201 lines (features that matter; no long-press notes; dev notes → pointers).
7. **Finger tests** — deferred by the owner; every `[human at the device]` box in the kits says so.
8. **Engine-update groundwork** — `docs/ENGINE.md` (read it before touching the engine);
   `build/engine/`: `engine-version.env` + `check-engine-pins.sh` (all pins agree),
   `patch-queue.sh --check` (the 39-patch queue reproduces `UXP_PIN` exactly — it had drifted:
   0031–0039 added, obsolete files removed), `check-engine-api.py` (0 FAIL on today's engine);
   `render/goanna/EngineCompat.h` declares every `jihad_*` export; the daemon logs
   "engine: 11 of 11 optional jihad_* exports present" at start-up. `docs/ENGINE-SOURCE.md` (the MPL
   record) lists all 39 changes. Kit `cavekit-engine-update.md`, Tier 74 (next steps T-385…T-387).

**Note:** the five renamed picture files landed in the engine-groundwork commit `30a4970b`
(staged renames rode along); the content is right, the commit boundary is not.

**Reviews:** the inspector's round 12 over `2cc01662..392c39e3`: ten P3s, all fixed (see
`impl-review-findings-6.md`). Found while verifying: removing a complete theme left its skin selected
and the Persona queued off for the next start — fixed (prompt clears both), Enyo's profile repaired.
**Codex owes a pass over `9e08c610..HEAD`** (out of credits until 10:07 PM 2026-10-08).

**Device state left:** all three variants on bundle 143 (daemon with `EngineCompat.h`, the
gallery, 15 bundled Personas, the complete-theme fix); Personas worn: Enyo Space Fantasy, Mochi
Aurora Silk, Mojo Lime Fizz; profiles hold only licensed Personas; test hooks restored to the shipped
manifests (Luna restarted); the device's `/tmp` test pages and scripts removed, and 76 stale
`/tmp/yapserver.jihad-browser*<pid>-<n>` sockets of dead processes removed (see below); host test
servers stopped; session scratch (~900 MB) and `~/.cache/jihad-personas` deleted —
`import-third-party.py` re-downloads and re-checks the pinned packages when run.

**Minor, open:** each card connection creates `/tmp/yapserver.<app><pid>-<n>`; `YapClient`'s
destructor unlinks it, but killing LunaSysMgr (every `luna-restart.sh`) skips that, so they pile up
until a reboot (0-byte files on the 40 MB tmpfs). A daemon-side sweep of dead-pid sockets at start-up
would fix it without touching the wire contract.

---

## 2026-10-08 delta — taps land where drawn, long-press menus back, the Personas manager, a Frutiger Aero set, the README (READ FIRST)

**Owner's reports this day and what came of each** (all device-verified unless marked):
- **"mojo tap targets seem inaccurate … I get duckduckgo when I click wikipedia"** — FIXED, three
  causes: the daemon divided adapter coordinates by the zoom a second time (since 2026-08-02; every
  shell, any zoom ≠ 1); Mojo's widget single-tap handler clicked a second time; the device's
  PGContext blit ignored the header strip, so the page was drawn one strip higher than taps were
  mapped. Mojo start page: one `clickAt` on the drawn Wikipedia link, opens it.
- **"using the url bar to search the web is slow"** — the first-paint hold is at most 1 s per
  document (it waited for load end, 12 s on Wikipedia). Owner's finger check pending.
- **Long-press link/image menus never appeared (found while taking screenshots)** — FIXED: the
  device's stock `/etc/palm/browser/HitTest.schema` does not compile in the pbnjson the adapter
  links (rejects even `{}`), and a rejected parse left the hit-test object empty. The adapter now
  validates against its own embedded schema. Enyo: link → Open In New Card / Share Link / Copy URL;
  image → Copy To Photos / Share Image / Set Wallpaper; Mochi's link sheet opens.
- **"make it user friendly to manage and install personas, using about:addons as a base"** — new kit
  `cavekit-personas-ui.md`, built (Tier 73, T-365…T-371). `components/jihadPersonas.js` decorates
  the engine's own about:addons (no engine change): category "Personas"; rows with the Persona's
  picture, author, version (1.0 default), In use first; Wear / Take off / Uninstall (44 px);
  Default look; an Undo bar for 30 s; Get Personas (AMO); Install from file (`.xpi` in
  `/media/internal/downloads` or `/media/internal`). Settings → Appearance is a summary with
  Manage Personas. Verified in Enyo, Mochi and Mojo. Owner direction folded in the same day: Try
  dropped for Wear + Undo, author and version on all rows, "Persona" everywhere (confirm, toasts,
  Settings, README), "Uninstall" not "Remove".
- **"add fruiter aero style themes"** — five original Frutiger Aero Personas
  (`render/goanna/personas/make-aero-personas.py` draws them; bundled under `personas/`), added once
  to each profile's list (not worn); an edition bump replaces the set's older pictures.
- **"blue nebula looks like it isnt working properly"** — wallpaper-sized pictures (AMO's
  3840×2160) exceed the 32 MB image cache and never drew in the engine: kept 1600 px wide at
  install, and the cards fit them to the bar (`headerFit`). Already-installed big ones need a
  reinstall.
- **"dark fox preview … not working"** — a row added while the pane is open is redecorated once its
  XBL binding attaches.
- **README** — rewritten as a webOS-era product page (card view, Personas strip, framed shots, the
  sourced HTTPS-on-webOS history). Art rebuilt by `docs/screenshots/readme-art.py` from raw device
  captures (Prelude fonts from the device, not in the repo). howsmyssl.com reports TLS 1.3.

**Found on the way, fixed:** the `resource://jihad-themes` mapping was never made after a daemon
restart (the constructor runs before the profile is known) — converted Personas lost their
pictures; the pane's `window.setTimeout` from the component never fires — the component uses its
own nsITimer; the daemon re-drove a page's load of an about: page by its resolved file address
(about:addons → `file:///…/extensions.xul`, refused as XUL from a file) — now by the original.

**Reviews:** Codex r9 (taps/first paint/hit-test, 4 findings, all dispositioned); the inspector r10
on the owed range `20310b3e..e7b9aa7d` (Codex ran out mid-run; P1 Mojo widget restoring zoom 1.0
on Back/reload, pinch drift, header after a link, stale meta viewport, setHeaderHeight — all fixed,
Back verified); the inspector r11 on the Personas work (8 findings, all fixed or already fixed) in
`context/impl/impl-review-findings-6.md`. **Codex owes a pass over `9e08c610..HEAD` when its credits
return (it said 10:07 PM on 2026-10-08).**

**Get Personas verified against the live AMO:** its Persona pages' **Download file** link installs
through the usual confirm (the big button only offers Firefox). **Still open:** the empty
state (needs every Persona uninstalled); double-tap speed and block choice; Mochi text soft at
~1.43; the owner's finger pass over all of the above; coordmap_test (fixed to the contract, not run
— no desktop engine build on this host).

**Device state left:** daemons, components, settings page and the Aero set (edition 3) deployed
to all three (bundle 137); adapters in `/usr/lib/jihad/<variant>/` with md5 enyo a952549dafab,
mochi 819269398a78, mojo 76f9d6979c55 (rootfs ro). Personas worn: Enyo Aero Ribbons (its Aero Sky
uninstalled for the edition test), Mochi Aero Ribbons, Mojo Aero Orbs. Test hooks restored to the
shipped manifests in all three (Luna restarted). The host's theme test server (8091) and http.server
(8092) are stopped. `/media/internal/downloads/dark_fox-2.0.xpi` is left there from the
Install-from-file test. Reviews: the inspector's round 11 on the Personas work is in
`impl-review-findings-6.md` (8 findings, all dispositioned).

---

## 2026-10-07 delta — owner's finger test: Mojo width loop fixed, menus polished, About page, README, Flash games (READ FIRST)

**The owner's finger-test report (2026-10-07) and what came of each item:**
- **Mojo "Wikipedia glitches, jumps, a stripe at the left"** — FIXED (daemon): the meta viewport was
  re-sent whenever its computed initial scale changed; Mojo sizes its node from that scale, so the
  page shrank each round (768 → 526 → … → 76 px). Re-sent now only when the page's declaration
  changes. Verified on en.m.wikipedia.org.
- **Long-press "not working on anything", all three** — NOT REPRODUCED. The owner's holds DID reach
  the engine (`hold at …`, `page-hold … (pushed)` in all three logs). A finger-like scripted
  press → hold → lift (new hook steps: Enyo/Mochi `J[ms]`, Mojo `Z0`) opens and keeps the menu in
  all three, whether it opens before or after the lift. The engine's answer takes ~1 s from
  finger-down. **Needs the owner:** does nothing appear at all, or does something flash and vanish,
  and how long was the finger held?
- **Mojo circles not themed** — FIXED: accent-colour fill, glyph set by text colour, bookmark glyph
  included.
- **Mochi dropdowns** — rounded corners; the app menu now flush with the left edge.
- **Mochi pinch makes text blurry** — OPEN, partly characterised: the daemon re-renders at the new
  zoom (frames at `contentZoom` = zoom, 1:1), unpinched text is equally sharp in Mochi and Enyo
  (edge metric 34.2 / 34.5), Mochi at 1.25 and Enyo at 1.28, 1.35 and 1.87 are crisp, Mochi at
  1.43 is soft. Not a stretched bitmap (the card's scaler is nearest-neighbour). Cause not found.
- **Home button default** — DuckDuckGo Lite in all three and on the settings page; a stored old
  default (`start.duckduckgo.com`) moves once, a home the user set is kept.
- **Enyo refresh icon** — 2 px higher (measured: field rows 38–66, glyph 47–59).
- **Flash test bookmark** — the page lives at `/media/internal/jihad-flash-test/` (survives reboots
  and reinstalls; a copy is in `render/goanna/test/flash-test-page/`), bookmarked in all three
  through each shell's own Add Bookmark. It now also links five real games on archive.org (direct
  SWFs: Helicopter, Bloxorz, Motherload, QWOP, Alien Hominid). **Bloxorz verified running** as a
  full-page plugin document. Enyo's address bar sent a typed `file:///` address to search — fixed.
- **Flash games / Bluetooth** — research in the session scratch (`flash-research.md`): Armor Games
  embeds the real SWF (should run natively), Y8 needs a UA tweak, Kongregate/CrazyGames/Newgrounds/
  archive.org item pages force Ruffle, archive.org DIRECT downloads work. webOS 3 pairs Bluetooth
  KEYBOARDS natively (keys reach the card and the adapter forwards them to the page) but has NO
  Bluetooth mouse support at all (pairing refused for non-keyboard HID) — a mouse is not feasible
  without OS changes; the touchscreen is Flash's mouse (double-tap for gesture lock). Keyboard +
  Flash still needs a real keyboard to verify (`key.html` on the test page).
- **About page** — Settings → About: interface, version, app id, engine and build, Flash version,
  user agent, licences and credits, read at run time. Verified (Mochi).
- **README** — rewritten around what only Jihad does on webOS, with screenshots in
  `docs/screenshots/`.

**Review:** Codex ran out of credits mid-review again (retry 12:41 PM) → inspector on the round-8
fixes (round 8b in `impl-review-findings-6.md`): one P1 — URLs still unbounded on other messages,
and an oversized YAP string reached the adapter as NULL → `strlen(NULL)` in the card host; fixed in
the daemon and in the shared YAP codec — plus five P3s, all fixed.

**Still open:** Mojo pinch (pinch in then out → grey; structural — see mojo-ui R6; proposed:
viewport-sized node in Mojo with the adapter owning pan/zoom, as in Enyo/Mochi); Mochi blur at
~1.43; long-press by finger (needs the owner's detail); slow pages can paint unstyled while their
stylesheets load (the offscreen renderer does not honour paint suppression); Mojo focuses the
address field (keyboard up) when launched with a URL; the Mochi profile carries test personas in
its used-themes list (Forget them in Settings → Appearance).

**Later the same day (owner: "long press works", "proceed with mojo pinch fix", "mojo themed
buttons are still broken", "the buttons and virtual keyboard should not be touching"):** Mojo's
WebView is now a screen-sized view with the adapter owning pan and zoom (mojo-ui R6 — verified pinch
in/out by script; **panning needs the owner's finger**); the themed circles keep the framework's
25 px borders so glyphs stay centred; the command row sits 23 px above the keyboard. Adapter: one
gesture path for every shell, pinch centre in window pixels. Long-press: confirmed working by the
owner.

**Second Mojo pass (2026-10-07/08, owner: scrolling dead, double tap dead, circles flash at
load, Wikipedia unstyled until touched, "I want mojo's toolbar to scroll off"):** all addressed —
see mojo-ui R6. Two of them were not Mojo's: the daemon's double-tap (smart zoom) request had
always been a stub (every shell), and the offscreen renderer ignored the engine's first-paint
gate (every shell; now held up to 5 s and fully repainted on release). Panning by finger in the
new Mojo model, and double tap in Enyo/Mochi, still want the owner's hands.

**Device state:** all three daemons on this round's build; adapter on the rootfs for all three
(md5 enyo `83e2b9f0…`, mochi `5851cff3…`, mojo `77d28024…`); rootfs ro; test hooks restored on all
three (shipped manifests); Flash test page + bookmarks
as above; theme Water-Like on all three.

## 2026-10-06 (night) delta — Codex r7 fixed; menus match on all three; Flash regression fixed and drivers off; Mojo pinch fixed (READ FIRST)

**Owner's asks this session:** "continue implementing everything you can using cavekit 3.1 with
codex adversarial review" plus: the upper-right menu the same on all three (Atlas as reference);
"optimize flash player for gaming performance"; DuckDuckGo Lite/HTML as search options, Lite the
default. Mid-session: "mojo should have no top toolbar icons next to url. bottom circular buttons
only"; "put the mojo refresh icon embedded in the right of the urlbar instead of the bottom as a
circular button"; "pinch to zoom is broken. the page turns grey and I get the copy/select
all/reload/find on page menu instead". The (evening) delta below is superseded: personas are done
and committed (`20310b3e`), and all three shells were device-verified with Water-Like.

**Verified on the device (TouchPad 3.0.5, one task at a time):**
- **Codex round 7 (12 findings) fixed** — table and device evidence in
  `context/impl/impl-review-findings-6.md` (round 7): referrer/policy carried on re-driven
  navigations (6 cases on the echo server's `/ref?v=`), title flood bounded and coalesced
  (`/titleflood`: 12 sends in ~6 s, ≤1024 bytes), theme preview only from https+"install"
  (http preview ignored), static-theme package limits/pending file/hash id, theme origin taken at
  the event, Enyo theme on the lazily created views (start page and browser bars both painted).
- **Menus:** Mochi's upper-right is now Share ▾ / New Card / Bookmarks ▾ and its title-bar app
  menu (Find on Page · Settings · Print) opens from a real sysmgr relaunch. Mojo has NO icons by
  the URL (owner) — Share ▸ and Bookmarks ▸ are submenus on the bottom circles (History circle
  became Bookmarks), reload/stop sits inside the address field, the app menu is Find · Settings ·
  Print; new Bookmarks / Downloads / Print scenes. Enyo was already the reference.
- **Flash, gaming:** a regression from `debd1934` made every frame a full paint (15-16 fps,
  ~25 ms paints); fixed (34 fps paints, 4-5 ms, all partial). The child's own timer is now off by
  default and the daemon only pulls after 150 ms of plugin silence: one producer, histogram at
  32-39 ms, a third less tick work — and the CONTENT rate (what a game's speed is), measured with
  a grid SWF and two timed screenshots, is the same as with the old drivers (22.5 vs 22.1 fps):
  they only re-drew frames. Knobs: `JIHAD_PLUGIN_SELF_DRIVE=1`, `JIHAD_PLUGIN_QUIET_MS=0` restore
  the old behaviour for an A/B. Shorter plugin ticks (10/12 ms) changed nothing.
- **Mojo pinch:** two adapter defects on the path only the Mojo widget uses (JS `gestureStart`):
  the first finger's hold timer was never cancelled (→ the long-press menu with Mojo's grey scrim),
  and the adapter zoomed/scrolled itself on top of the widget's own pinch (→ grey page). Fixed in
  `BrowserAdapter.cpp` (`widgetGestureStart`, hold dropped if a gesture began since). Verified with
  the hook's finger-like `Z` step (a held-still control does raise the menu; the pinch does not;
  engine zoom tracks the widget 1.01 → 1.20; page drawn in and back out). **A real finger pinch by
  the owner is still the final word.**
- DuckDuckGo Lite default (Mochi reads `duckduckgo-lite`), HTML listed, one-time migration.

**Not done / open:**
- **Codex is out of credits until Oct 7 1:53 AM** — round 8 (all of the above) was reviewed by the
  `ck:inspector` backup: 1 P1 (a re-drive without a referrer ran as the SYSTEM principal — could
  reach `file:` / top-level `data:`), 1 P2 (static-theme zip sizes trusted), 5 P3; all fixed and
  the P1/P2 verified on the device (round 8 in the findings file). **Owed: Codex on this
  session's commit (`20310b3e..HEAD`) once its credits are back** — the memory note
  `codex-gate-needs-direct-invocation.md` has the invocation.
- Flash's own rate on this CPU (~27 fps for a 30 fps 320x240 SWF, ~22 at 640x480) is the limit
  now; `sensord` takes ~15-20 % CPU on the test device at all times (not ours). Whether evenly
  paced 27 fps reads well in a real game is an eye test for the owner.
- One unexplained miss: a static theme's live notification did not paint Mochi's bar once (two
  later runs did). Tabs: groundwork only, as asked.
- Finger tests remain the owner's: pinch on Mojo, the menus by touch, the in-field reload.

**Device state as left:** all three daemons run the same hand-pushed build (this session's final
bundle; the packages under `build/webos-oe/out-ipk/` are built from the night commit, the same
tree, but NOT installed as packages — the device has the pushed files). Adapter on the rootfs for all three
(`/usr/lib/jihad/<V>/BrowserAdapterImpl.so`, md5 enyo `d9144bc4…`, mochi `831549b7…`, mojo
`8f1a90bd…`; Mojo-only widget pinch), rootfs **ro** (checked). Test hooks **restored** on all three
(shipped manifests, no hook files). No Jihad card open; no plugin-container. Host echo server
stopped.
`/tmp` holds `jihad-anim.*`, `jihad-grid.*`, `jihad-plain.html` (small). Mochi's current theme is
the static Water-Like (`static-theme:0dff6242…`), Enyo and Mojo Water-Like. The Enyo daemon is
on its job again (it was hand-started for the A/B runs).

## 2026-10-06 (evening) delta — personas IN PROGRESS, stopped at the usage limit (superseded by the night delta above)

**Owner's asks this session, in order:** fix the slow add-on manager (DONE, see commit `fb8d2cfc`);
"ensure all options in about:config that are relevant are working" (DONE: effect audit, same
commit); tabs decisions (DONE in the kit/design: `window.open` → new tab, strip invisible with
one tab, no cap — responsive scrolling strip, Atlas `TabLayer.js` as the UI reference, "buttons
and tabs should also be themed" added to R1); **personas** — "support firefox 52 personas, pale
moon personas, and basilisk personas", then "use the persona water-like by stick177 to test all
3 variants. buttons and tabs should also be themed" — IN PROGRESS, uncommitted parts committed
as they stand in the commit after this one.

**What is built and device-verified (Mochi only):**
- Engine/daemon: `GoannaRenderPage` catches the theme sites' `InstallBrowserTheme` /
  `PreviewBrowserTheme` / `ResetBrowserThemePreview` events on the content document; the pump
  hands them to `components/jihadPersonas.js` (new) as page command `theme`; the component asks
  the user through the existing `jihad-xpi-confirm` door (wording "Allow <host> to change the
  browser's look to the theme: <name>"), applies through the engine's `LightweightThemeManager`
  (which persists the header image into the profile), records the theme in pref
  `jihad.theme.current` and pushes category `theme` on the notification channel; Luna
  `getTheme` (new, both buses) answers a starting card. The notification door now lets `theme`
  JSON through whole (it was cut at 200 chars — the card parsed nothing; the first bug found).
- Mochi card: the toolbar is painted (accent + persisted header file, `rgb(92,30,47) url(file:///…/profile/lightweighttheme-header…)`) both at start (getTheme) and live on install. Test site:
  scratch `echo-server.py` `/persona?v=N` (and `?v=water` = Water-Like by stick177, from AMO's
  converted static theme: `theme_frame` jpg, frame `#00ccff`, text `#000000`); hook steps `T`
  (toolbar style), `Z` (clear card-side), `Y`/`a` (confirm answers).
- Settings page: an "Appearance" section (current theme + Remove; used themes with Use/Forget)
  in the Browser pane — CODE ONLY, not yet seen on the device.
- Static-theme XPIs (what AMO serves every former persona as): `jihadInstallPrompt.js` hands a
  -207 corrupt install's file to `jihadPersonas.js`, which reads a theme-only `manifest.json`,
  unpacks the image under `<profile>/jihad-themes/` (served as `resource://jihad-themes/…`),
  and applies it as a lightweight theme with the user's yes — CODE ONLY, untested. Test link on
  the site: "Install the AMO static-theme XPI" (`/water-like.xpi`, sha256 `c6b8b50d…`).
- Button tinting in all three shells (`-webkit-mask-image` of the glyph + textcolor; Enyo
  `.enyo-button-icon`, Mochi `img.jihad-nav-img` with a transparent src, Mojo the command row's
  sprites, re-applied after the row's model changes) — CODE ONLY, untested on the device
  (whether this WebKit honours `-webkit-mask-image` is the first thing to check: hook `T` reports
  the first icon's mask/background).
- Enyo and Mojo `applyTheme` + `getTheme` + `theme` routing — CODE ONLY, untested.

**Next steps, in order:** `card-selftest.sh {enyo,mochi,mojo} push`; per shell run
`page:w6;Z;T;107,146;w3;a;w3;T;w5;T;w1` on `http://192.168.1.245:8091/persona?v=water` (the
echo server must be running on the host: `python3 <scratch>/echo-server.py 8091`; the Water-Like
header jpg and xpi live in the scratch dir — copy them somewhere durable, e.g.
`render/goanna/test/personas/`, before the scratch dir is lost); screenshots of the themed bar
and buttons on each shell; the Mochi click coordinates differ per shell (Enyo/Mojo: read the
page's button position from a screenshot: image (80,168) at 576x768 → view x = 107, y =
168·1.333 − view top); then the AMO XPI link; then `about:preferences` Appearance section;
then `restore` all three hooks, rebuild bundle + packages (`build-variant-ipk.sh`), install
as upgrades, remount ro; kit cavekit-addons-extensions.md gains **R10 (lightweight themes)**
with these criteria (not yet written); PARITY rows; Codex/inspector review of the persona code
(`jihadPersonas.js`, `jihadInstallPrompt.js` hook, `GoannaRenderPage` theme events, the three
`applyTheme`s); PICKUP.

**Device state as left (NOT clean):** all three daemons run the hand-pushed bundle
`9feea335…` (daemon with idle drain, referrer, title, DNT, theme-door; components incl.
`jihadPersonas.js`), NOT the installed packages (those are at `3bafb9bb…`). **The Mochi test
hook is LOADED** (`card-selftest.sh mochi restore` before anything else); Enyo and Mojo shells
on the device are the OLD ones (no `applyTheme`). Mochi's profile holds test personas
`jihad-test-persona-1/2/3` as used themes and persona 3 as current — remove via the Appearance
section or `LightweightThemeManager.currentTheme = null`. Mochi's `prefs.js` is back to its
20 user prefs (the effect-audit batches were restored). The host echo server may still be
running (pid in `pgrep -f echo-server`). Root fs: rw after the hand pushes? — check
(`mount | grep store-root`), remount ro. No card open.

## 2026-10-06 (go-ahead) delta — everything that needed no hands: reinstall audit, reboot, a real sheet, Codex round 6, SDK 0.4, tabs groundwork

**The owner's word:** "You have my go ahead for all remaining tasks that you can achieve without me
physically touching the device. Also lay the groundwork for tabbed browsing but dont implement it
yet." Then: "Update to the latest community sdk" and "Pause completely when you need a sudo
command from me" (saved as a memory rule).

**Done, device-verified:**
- **SDK 0.4** (`~/eclipse-workspace/webos-sdk-redux` at tag `0.4-Release`; the owner ran
  `sudo ./install.sh`): `/opt/PalmSDK/Current → 0.4`, new `novacomd` (built 09:50) running, device
  seen. Among its fixes: novacom no longer drops a packet whose payload trails its header at
  close — the "output after stdin EOF is lost" trap may be softer now; `dev-sh.sh` stays the rule.
- **Enyo and Mojo removed through the installer and installed from nothing** (T-231–T-233, T-273;
  Mochi was 2026-10-05). Each removal left no app dir / job / shim / impl / role / service / state
  dir / socket, the hub forgot the name, the other daemons kept their PIDs, the citizen-audit diff
  shows only the variant's own entries (the empty package-registry dir stays, known). Each fresh
  postinst rescanned the hub, started the daemon from its deviceroot, registered Luna on first
  start, a card rendered Wikipedia, Palefill landed (Mojo's after ~70 s of an open card — the
  add-on manager is slow to come ready; the installer retries each start). Enyo's db8 history
  exported and put back (69 rows); Mojo's localStorage history restored. Backup of both profiles,
  state dirs and localStorage: `~/eclipse-workspace/Jihad/device-backups/jihad-backup-20261006.tgz`
  (+ `db8-enyo-*.json`). Snapshots in `build/webos-oe/out-audit/*-1006.txt` (git-ignored, host only).
- **Reboot (T-234):** `com.palm.power/shutdown/machineReboot`; back on novacom in ~40 s; 2.5 min
  later all three jobs running from the shipped upstart files, each daemon `luna: serving` with
  no `FAILED` and no retry, public-bus answered, sockets up, no D-state threads, `/` read-only, no
  crash reports, a card per variant rendering a live page. T-236's condition did not arise. The
  standalone `alsa_probe`/`plugin_mime_probe` were not re-run (diagnostic programs from closed
  investigations; the daemon itself plays media and scans plugins).
- **One real print** (T-310's last box): the small page printed to the IPP sink first
  (`evidence-2026-10-06/mochi_print-small-page-as-the-sink-received-it.jpg`, 0.7 % ink), then the
  same dialog to the Epson ET-2800 at 192.168.1.253 over IPPS: `sheet 1 accepted after 456 ms,
  job-id 32`. **The owner should find one sheet with three lines of text in the tray.**
- **Codex round 6** on the inspector-only range (its credits came back, then ran out again before
  the second range — retry 2:53 PM): nine findings, four already fixed, one accepted, four fixed
  now and installed as an upgrade: the padlock follows the COMMITTED address (typed https showed
  the old page's padlock, and its certificate, under the new address — Enyo `pending` through
  ActionBar/URLSearch/AddressInput, Mochi `_pendingUrl`; hook steps `U`/`L` drive it); Cut is bound
  to the field the copy came from and the copy must be under 15 s old; copied text is let go after
  15 s; `services_test`/`xpi_mismatch_test` sinks return `int`; `push-engine-update.sh` refuses a
  full push from a stale bundle before touching the device. Record: `impl-review-findings-6.md`.
- **Tabbed browsing — GROUNDWORK ONLY:** `context/kits/cavekit-tabbed-browsing.md` (R1–R6),
  `docs/TABS-GROUNDWORK.md` (plan B: pages in the daemon, one connection per card, `tabs/*` over
  the variant's own Luna service, YAP untouched; why not one adapter per tab: 37.7 MB of shared
  memory per connection), Tier 71 (T-347…T-354) all PENDING, overview row. Three questions for
  the owner at the end of the design note. Nothing built.

**Host test note:** `services_test` and `input_test` (desktop GTK path under Xvfb) read a black
window before any click — the desktop harness, not the device path; not chased.

**Not done, and why:** the two pushes (`git -C third_party/uxp push fork jihad-engine-mods`;
`git push origin jihad/about-preferences-and-settings-merge`) were refused by the session's
permission gate as outward publication — the owner runs them. The OE SRCREV is bumped to
`db070f0003` (the gitlink's commit; the recipe clones the in-repo submodule, so it needs no
push). T-341 / T-354 and T-280–T-289 / T-317 need a finger.

**Device state:** all three variants from the packages at this commit (bundle `3bafb9bb…`, daemon
`59c72b75…`, libxul `ddf8cc70…`; md5 `cf2fe975 / 5887986c / a5a78d55`), installed as upgrades
after the fresh installs, then REBOOTED and checked. Root read-only (the reboot did it). No hooks,
no staged packages, no backup copy on the device, `/tmp` holds nothing of mine. Palefill in all
three profiles. No card open. Enyo history 70 rows (69 restored + Wikipedia).

## 2026-10-06 (later) delta — Mojo's Copy/Cut/padlock never reached the engine; wide zoomed regions seen; three test hooks

**Why this session existed:** "Is there anything else you can do without me using the device
physically?" — the items that did not need a finger: the Mochi padlock after a failed load, a
pinch through the adapter's own gesture entry points, and a test hook for the Mojo shell. Each
turned up something.

**Found and fixed (device-verified, scripted):**
- **Mojo Copy, Cut and the padlock's `pageFocused` had never reached the engine.** The Mojo WebView
  widget (framework, not ours) implements `copy(callback)` as `this.adapter.copy(callback)`, so the
  shell's `callBrowserAdapter("copy")` handed the adapter one `undefined` argument, which
  `js_copy` refuses ("Bad arguments") — silently, because the shell's "method unavailable" line
  was at `Mojo.Log.warn`, which never reaches the device log (a trap already in the Mojo kit).
  And the widget wraps no `cut` and no `pageFocused` at all. Fix (`app-mojo/app/assistants/
  main-assistant.js`): `askCopy()` always passes a function; a method the widget does not wrap is
  called on the plugin element itself (`view.querySelector("object")` — `element.mojo` is the
  widget's exposed face and does not carry its `adapter`); the unavailable line is now `error`.
  The method-name set is unchanged (kit mojo-ui R3). Verified: word Copy → clipboard; field Paste;
  Select All → Copy/Cut appear; Cut → clipboard has the text, field empty, engine says "Cut.";
  padlock tap on Wikipedia → the Certificate alert; `pageFocused` logged by the daemon.
- **Wide zoomed regions were thrown away at the content's right edge.** The pinch hook (`g` step:
  adapter `gestureStart/Change/End`) does zoom (`setZoomAndScroll zoom=1.2434 scroll=658,686`),
  and the first wide frame came out one viewport wide: `mLastContentW * Zeff` gave 1387 while the
  band (clamped in CSS px, scaled the other way) ended at 1388, and the band-inside-region test
  dropped the wide region. `BrowserPageGoanna.cpp`: the content is at least as wide as the band.
  Verified: `region columns: content 1388 px wide at zoom 1.2434 ... -> [0, +1388), rows up to
  2266`, the composite on screen is right, pinch back to 0.8447 → 943x3335 with sweeps. The
  `region columns:` line logs only when the decision changes (kept; it is what made this visible).
- **Mochi padlock after a failed load** (`page:w6;l;a;w3;l;w3` over `https://no-such-host.invalid/`):
  showing before the engine's alert is answered, gone after, the tap then says "No certificate
  information is available for this page." Mochi hook gained `a` (answer the engine's alert).

**New: a Mojo test hook** — `render/goanna/test/mojo-selftest.js`, `card-selftest.sh mojo push|run|restore`
(the script now knows each shell's sources, manifest and hook path). Steps: `hX,Y` hold, `m`/`mN`
read/pick the open `popupSubmenu` (its model's items; a pick calls the model's `onChoose` with the
item's command, the popup's element removed first — this framework build's submenu has no
`mojo.close`), `l` padlock (`handleAddressTap` at x=12), `d`/`a` read and answer the open
`showAlertDialog`, `k`/`c=`/`p` clipboard, `W`/`P` list the widget's and the plugin's methods,
`?` state. The scenario comes from `PalmSystem.launchParams.jihadTest` (the stage hands the scene
only the url). Every `callBrowserAdapter` call is logged with the road it took (widget / plugin /
nowhere) — that is how the Copy defect showed.

**Review:** Codex still out of credits (retry 6:46 AM) → `ck:inspector` on the diff; findings and
what was done with them are in `context/impl/impl-review-findings-6.md` (round 5).

**Still open (unchanged in kind):** owner-only finger tests (T-341: pan/pinch feel, a hold on a link
per shell, the glyph itself), removal/reinstall (T-231…), hands-on checklist (T-280…), one real
print, pushing the engine branch. The sideways pan still has no script (it is the adapter's drag).
Agent-doable when Codex's credits return (6:46 AM local): a Codex pass over the inspector-only
rounds (3 and 5 in `impl-review-findings-6.md`; the scratch wrapper is described under "Codex
gate" in the delta below). Nothing else of the owner's list is reachable without a finger.

**Device state:** all three variants installed through the installer from the packages built at
this commit (bundle `622ea210…`, daemon `59c72b75…`, libxul unchanged `ddf8cc70…`, adapters
unchanged; packages `build/webos-oe/out-ipk/*.ipk`, md5 `c0273e34 / 3956cd95 / d7b7c1cd`) — the device is
the repository head. Each variant smoke-tested on Wikipedia from the package (title and frames
in its daemon log). Palefill XPI in each profile. Root filesystem read-only. Test hooks: none
loaded, manifests shipped. Staged packages and my `/tmp` files removed (`/tmp` 688 KB used). No
crash reports of mine (`/var/log/reports` holds only `librdx`). No card open.

**Review fixes applied after the inspector (same commit):** see `impl-review-findings-6.md`
round 5. The things to know: the Mojo hook answers an alert through the dialog's own
`close(value)` (a page `confirm()` → "answered yes" on the device) and taps a submenu node with
`Mojo.Event.tap`; Find on Page in Mojo had also never reached the engine (no `findInPage`
wrapper) and now does (`find 'charlie' -> 1`); a copy the engine answers `false` to gets its own
"could not be copied" toast after 1.5 s unless the engine's word came first.

## 2026-10-06 delta — the 2026-10-05 work finished, reviewed, packaged, device cleaned

**Commits (local, NOT pushed):** `657282c4` long-press menu · `debd1934` composed frames + padlock +
review fixes · `afb0db6e` Palefill · `707795de` / `bb16ea4a` docs · `31c5f445` review round 4
(Codex on Palefill, inspector on the last fixes). Engine branch `jihad-engine-mods` (local; owner pushes, then bump the OE SRCREV in
`build/webos-oe/recipes-jihad/goanna/goanna_1.0.bb`): `0048d50fa9` (windowless plugin),
`628ee50c99` (plugin child env), `db070f0003` (AppCompat vs toolkit target).

**What the owner asked for and what it is now** (kits: ui-shell R7/R8, offscreen R9, addons R9,
device-build R4; `context/impl/impl-review-findings-6.md` has every review finding):
- Long-press menu on any content, all three shells (Copy/Cut/Paste/Select All, page actions).
  Device, Enyo + Mochi, scripted holds. Mojo needs a finger.
- "Pages only load when observed": frames are composed (copy then render ≤ 768 new rows), region
  is the whole segment, sweeps, wide when zoomed. Row-exact after jumps. A real pan needs a finger.
- DDG "links don't work" = Flash pages killing the daemon in a loop → engine fix + crash guard.
- Padlock → certificate (+ connection, trust state). Enyo + Mochi device-verified; Mojo drawn.
- Palefill 1.30 bundled unmodified (MPL-2.0, hash-pinned, NOTICE); installed enabled in all three.
- Codex gate: Cavekit 3.1's script is silently incompatible with Codex CLI 0.160 — run
  `codex exec` directly with its prompt; `ck:inspector` when Codex's credits run out (they did,
  twice). Memory: `codex-gate-needs-direct-invocation.md`, `device-test-limits.md`.

**Device state:** all three variants installed through the installer from the packages built at
`31c5f445` (bundle `4887551a…`, daemon `b7be3e3c…`, libxul `ddf8cc70…`, adapters `88303cfc /
51d10886 / 1b0ac09d`, Palefill in each) — the device IS the repository head; nothing hand-pushed
on top. Packages: `build/webos-oe/out-ipk/net.riverstonerelay.jihad-browser{,-mochi,-mojo}_*.ipk`
(Enyo 1.0.4, the others 1.0.0). Root filesystem read-only. Test hooks restored (none loaded). `/tmp` holds nothing of
mine (39 MB free). `/var/palm/jihad/adapter-backup-20261005` removed; the 2026-08-10 backup is
still there. Crash reports: all of 2026-10-05's were mine (Flash loop, busybox, one
`media-pipeline.real` SIGSEGV at 15:18 during the first package install) and were deleted;
my attempt to copy them to the host first produced empty files, so they are gone unread.
Palefill in every profile. No card open.

**Still open:**
- Owner only: finger tests (pan/pinch smoothness; Mojo menu + padlock tap; Mochi padlock after a
  failed load; a hold on a link per shell) — T-341; Enyo/Mojo removal + install from nothing
  (T-231…); hands-on checklist (T-280…); one real print.
- Known gaps left on purpose: fields inside iframes get the page menu; Palefill buffers whole
  responses of the sites it rewrites (its own design); one `window.jihadClip` per card.
- Trap: after an upgrade that replaces the adapter, `/` will not remount read-only until
  LunaSysMgr restarts.

## 2026-10-05 delta — printing built; a stale-script defect found and fixed; Mochi installed from nothing (read first)

Per-task record: `context/impl/impl-ce310-loop.md` (rows from "2026-10-05"); evidence:
`context/impl/evidence-2026-10-05/`; plan: tiers 62–65 of `context/plans/build-site.md`.
**Nothing was pushed.** 10 local commits since `c726e8a7`.

**What the owner asked, and the answers:**
- *"I have a network printer, so why can't the TouchPad see it?"* It can. webOS's print daemon
  resolved the Epson over mDNS and logged `not HP printer and doing printer filtering` — the stock
  print stack discards every printer that is not HP. So the browser now prints by itself:
  `render/goanna/components/jihadPrint.js` finds IPP printers (mDNS, or a typed address), draws the
  page as JPEG sheets and sends them over IPP/IPPS; both the Enyo and the Mochi shell have a Print
  dialog (`JihadPrintDialog.js`) in place of the system one. On the device both dialogs list the
  Epson ET-2800 (192.168.1.253) and a Mac-shared ET-2720. Mochi's Print box is `[x]`; the parity
  list has no open row.
- *Share Image / Set as Wallpaper:* both run on the Mochi card through the long-press sheet's own
  handlers. The wallpaper changed and was put back (`19.jpg`); Share Image opened Email.
- *Why was `/` read-write?* The installer service (`org.webosinternals.ipkgservice`, Preware's
  backend) remounts `/` read-write before running a package's script and never restores it. Measured
  from a read-only start. Our scripts leave the state as found. A reboot, or
  `mount -o remount,ro /`, puts it back.
- *The Atlas fault report:* Atlas's own — a SIGBUS in its allocator thread at the 2026-10-02
  shutdown, nothing of ours in it. Atlas and a Jihad card rendered side by side again today.

**An accident, and the defect behind it.** A print test meant as a dry run put one full dark sheet
through the owner's Epson. The new print component was on the device and the daemon had been
restarted, but the engine ran the PREVIOUS version from its compiled-script cache
(`$APP/cache/startupCache`, keyed by path, never invalidated in an embedding — and untouched by an
`.ipk` upgrade, so every upgraded script was exposed to the same thing). Fixed in the daemon
(commit `c4e9bb9e`): it fingerprints the bundle at start and drops that cache when the bundle
changed. Look for `startup cache: bundle …` in the daemon log.

**Traps found this session:**
- **Test printing against `render/goanna/test/ipp-sink.py` first**, never the real printer:
  `python3 render/goanna/test/ipp-sink.py --port 8090 --out DIR`, then
  `card-selftest.sh <shell> run print:192.168.1.245:8090 <url> 66`. It keeps each sheet as a JPEG.
- After pushing ANY engine script by hand, confirm `startup cache: bundle CHANGED … dropped` before
  believing the new code is what runs.
- mDNS from an ephemeral port gets no answers on this device: the firewall admits only
  `udp dpt:5353` and established flows. Ask from port 5353.
- The Luna hub forwards a bus SIGNAL only from a sender named `com.palm.*`, and the device's
  `luna-send -s` needs `-m com.palm.lunasend` for that. Without it the signal shows in `ls-monitor`
  and reaches nobody.
- `ipkgservice/install` wants BOTH `filename` (the bare name) and
  `url` (`file:///media/internal/.developer/<name>`), and after a FIRST install the launcher does not
  know the app until `ipkgservice/rescan` (Preware calls it; a script must too).
- A card's `luna-send` on the device quits before its answer if its stdin is at end-of-file — which
  is what a carelessly held novacom session gives it. Use `build/webos-oe/dev-sh.sh`.
- `com.palm.display/control/setState off` is refused while on USB (`blockDisplay`), and there is no
  touch input device to inject a tap into.

**Tools added:** `build/webos-oe/luna-restart.sh` (restart LunaSysMgr and close the USB alert it
leaves over the top right of the screen; `--close` for the alert alone), `build/webos-oe/dev-sh.sh`
(run a local script on the device, all output, returns when it ends),
`render/goanna/test/ipp-sink.py`, `packaging/branding/make-enyo-toolbar-icons.py` (the Home and
Bookmarks/History toolbar icons, redrawn at the owner's request), print scenarios in both test
hooks, `holdpick` in the Mochi hook. `device-citizen-audit.sh` now lists the installer's package
directories.

**Still open, and why:**
- Enyo and Mojo removal and install from nothing (T-231…T-234, T-236, T-273): only the owner can run
  a removal on this device. Mochi's half is done. When that happens, look at
  `/media/cryptofs/apps/usr/palm/packages/<id>` afterwards: Mochi's removal left it as an empty
  directory (recorded in cavekit-device-build.md R8, not fixed — `prerm` cannot `rmdir` a directory
  ipkg still has files in). The test extension is no longer installed in any profile; T-273 needs it
  put back in two variants first.
- A sheet of paper printed from the dialog, seen by a person; a real long-press; and the rest of
  the hands-on checklist (T-280…T-289, T-317) — deferred by the owner.
- Not built yet: the daemon's "luna: serving" log line now names `findPrinters` / `printPage` in
  source, but the installed daemon predates that one-string change.

**Device state as left (2026-10-05):**
- All three variants installed from the same build through the installer: bundle id
  `a4a2f8e2b8bf…`, libxul `65e3cc84891c…`, daemon `889263013e40…`. Mochi was a fresh install, Enyo
  (1.0.4) and Mojo upgrades. Each daemon runs from its own deviceroot and answers on the public bus.
- Jobs: Enyo and Mojo as shipped; **Mochi's job carries `JIHAD_INJECT=1`** (added by the install
  helper). No test hook in any app directory. No extension in any profile.
- `/` is read-only (put back by hand after the installs). Wallpaper `19.jpg`, as found. No Email or
  Atlas card left open; one Enyo browser card is open.
- `/tmp` keeps the helpers (`fresh-card.sh`, `inst3.sh`, `rm1.sh`) and the test pages, including
  `jihad-print.html` and `jihad-print-tall.html`. `/tmp` is a tmpfs: all of it goes at a reboot.
- Old staged packages are still in `/media/internal/.developer/` from earlier sessions
  (`jihad-browser.ipk`, `jihad-mochi.ipk`, `jihad-mojo.ipk`, the 1.0.2 and 1.0.3 Enyo `.ipk`s) —
  about 230 MB of the user's volume that nothing uses. Left for the owner to delete.

---

## 2026-10-02 delta — owner decisions carried out; the Mochi parity omissions built (read first)

The owner answered the open decisions and gave a go-ahead for the removal audit, the engine push
and a reboot. Per-task record: `context/impl/impl-ce310-loop.md` (rows from "2026-10-02" on);
evidence: `context/impl/evidence-2026-10-02/`; plan: tiers 54–61 of `context/plans/build-site.md`.
**Nothing was pushed** (see "Waiting on the owner").

**Decisions taken, and done:**
- The card panels lose Block Popups / Accept Cookies / Enable JavaScript (Enyo, Mochi); the settings
  page owns them; "More Settings" opens it. The Enyo card no longer replays its stored copies.
- Flash comes from the device's own plugin folder (`/media/cryptofs/apps/usr/lib/BrowserServerPlugins`,
  the HP Flash plugin app) — scanned after the profile folder, skipped when the profile has its own
  copy. One stored on/off value (`plugin.state.flash`): a row on the settings page, a real switch in
  the Enyo and Mochi panels through the variant's Luna service (`getFlash` / `enableFlash` /
  `disableFlash`; the setters accept only the variant's own card).
- No Mochi parity omission was accepted. Built and shown on the device: bookmark editing, bookmark
  thumbnails, downloads a page starts (one fetch, with retry), long-press menu, share sheet and Add
  to Launcher, certificate details, search-engine choice, Flash switch, Clear History that clears the
  engine too, a confirmation before each clear, grouped history dates. `app-mochi/PARITY.md` is
  refreshed. **Print is not built**: no printer the device can reach, so nothing could be verified.

**Defects found on the way and fixed:**
- Closing ANY card unregistered the add-on install prompt and the JS notification door for the rest
  of the daemon's life (the page destructor cleared a process-wide sink, and clearing it dropped
  once-per-process observers). Installs were downloaded and then cancelled with no prompt.
- The Mochi bookmarks list could never show a row (ordered by an un-indexed db8 property), and a
  Mochi panel hidden at layout time opened blank (never measured).
- With a profile copy and the system folder both scanned, Flash was registered twice.
- The Enyo certificate view could never open on webOS CE (see traps) and threw on a certificate with
  no common name.

**Waiting on the owner (approved, but the session's permission gate refused both again):**
- Engine push: `git -C third_party/uxp push fork jihad-engine-mods`, then bump the gitlink and the OE
  SRCREV (T-279). Two local engine commits: `1fff802335`, `9dedcd5fe5`.
- Variant removal (T-231…T-234, T-273): the audit script is on the device —
  `/tmp/rm1.sh <variant> <appid> <job> <luna name> <shim>` (volatile: re-push it from the scratch
  copy or rewrite it if `/tmp` was cleared). The test extension is installed in the Enyo and Mochi
  profiles for the "its extensions go, the other's stay" check. Profile backups of all three variants
  were taken to the host before anything else.
- A printer the device can reach, for Print (T-310).
- The human checklist (T-317): hands-on steps, listed at the end of the session's report.

**Traps found this session:**
- `/tmp` on the device is a 40 MB tmpfs. Three profile tarballs filled it; `novacom put` then fails
  with "No space left on device". Stream large things straight to the host instead.
- A card may load a local file ONLY from its own application directory or `/media/internal`
  (LunaSysMgr `isAllowedFileAccess`), and its WebKit refuses a local file over XMLHttpRequest. A
  script or image tag pointing into the app directory works. `/var/…` and `/tmp/…` do not.
- `com.palm.certificatemanager` does not exist for a card on webOS CE ("Service does not exist").
- While an engine dialog is up the daemon answers nothing over Luna either.
- This Enyo 2 has `resize()`, not `resized()`; a panel shown after layout needs it.
- db8 refuses an ordered query on a property the kind has no index for (`-3965`), and an Enyo 2 card
  shows that as an empty list, not an error.
- `pkill -f <pattern>` kills the shell that runs it if the pattern is in its own command line.
- An upgrade `.ipk` install overwrites the package's files but does NOT remove an extra file: a
  pushed test hook's manifest edit is undone by an install, its `JihadSelfTest.js` is left lying in
  the app directory. Always finish a hook session with `card-selftest.sh <shell> restore`.

**Tools added:** `build/webos-oe/card-selftest.sh` (+ `render/goanna/test/{mochi,enyo}-selftest.js`)
drives a shell's own chrome on the device through its handlers; `build/webos-oe/prefs-row-walk.sh`
walks every settings-page row.

**Device state as left:**
- All three variants installed through `org.webosinternals.ipkgservice`: libxul
  `65e3cc84891c59e9ede40cc7b3de0802`, daemon `1a70344214e9e266c894782ed10286b9`, goanna.js `97f981b3bc03…`,
  PDK adapter impls unchanged (enyo `6a35d778…`, mochi `44ab2e23…`, mojo `25aa85a4…`). Shell sources
  on the device compare equal (md5) to the repo at the last commit. The Enyo package installed is
  `690d8c3c…`; Mochi and Mojo were installed from an earlier build of the same payload
  (`a9ca38d8…`, `59d727a0…`) — the copies now in `build/webos-oe/out-ipk/` are a later rebuild whose
  payload is identical but whose package bytes are not.
- **The device was rebooted once** (owner-approved) with the shipped, unmodified jobs: all three
  daemons came up, Luna registered at first start, extensions survived. Afterwards `JIHAD_INJECT=1`
  was re-added to the three jobs (remount rw → edit → remount ro) and the daemons restarted. The
  root filesystem is READ-ONLY at rest now (it was read-write before the reboot, found that way).
- Flash: no variant has a copy in its profile any more (the hand-copied one was removed from Enyo);
  all three get it from the system folder; the value is ON in all three.
- **The test extension `jihad-effect@riverstonerelay.net` is installed in the Enyo and Mochi profiles
  on purpose** (for the removal audit) — it turns every page's background magenta in those two
  variants. Remove it from `about:addons` once the audit is done.
- `/tmp` was wiped by the reboot. Restaged: the test pages (`stage-test-pages.sh`), `fresh-card.sh`,
  `inst3.sh`, `fin1.sh`, `ps.sh` and the removal audit script `rm1.sh`. NOT restaged: the media clips
  (`stage-media-pages.sh`), the Flash test movies except `jihad-anim`, `uinput_kbd`.
- Cards open: Enyo and Mochi on `file:///tmp/jihad-plain.html`. No test hook on the device: both
  manifests are the shipped ones and no `JihadSelfTest.js` is left (an upgrade install leaves an
  extra file behind — it was removed by hand).
- Mochi card data left from the tests: a few history rows and downloads-view rows (their files are
  deleted); the search engine is back on DuckDuckGo; no bookmarks.
- Four fault reports in `/var/log/reports/librdx/`; the new one is `BrowserServer-atlas` SIGBUS at
  the moment of the reboot — Atlas's daemon, not ours. LunaSysMgr was restarted about a dozen times
  by `card-selftest.sh push` / `restore` (by design: it caches card JS).
- `/var` 23%. Residue still to delete by hand: `/media/internal/downloads/jihad-testfile{,-1,-2}.bin`.
- Cavekit: registry 96 complete, 18 blocked (owner / person / printer), 1 pending behind them. The
  loop was torn down at the stop. `.cavekit/config` carries an uncommitted edit of the owner's.

---

## 2026-10-01 (third session) delta — every agent-doable sweep run on CE 3.1.0 (SUPERSEDED where the delta above disagrees)

`/ck:make` ran the rest of the build site inline. Registry: 72 complete, 18 blocked (owner / human),
1 pending behind a blocked task (T-236). Per-task record: `context/impl/impl-ce310-loop.md`; the kits
carry the evidence on each criterion; screenshots in `context/impl/evidence-2026-10-01/`.
**Nothing was pushed.** Engine commits `1fff802335` and `9dedcd5fe5` on `third_party/uxp`
`jihad-engine-mods` are LOCAL; the parent gitlink and the OE SRCREV still say `bd49435b` (T-279).

**Verified on the device (webOS CE 3.1.0), all three variants unless said:**
- Preferences: the page renders and writes only its own variant's `prefs.js`; typed values save on
  blur and on Enter; JavaScript row is back and survives a card relaunch and a daemon restart; the four
  frozen settings work from the page and from the shipping Enyo card; Mojo/Enyo/Mochi adopt page edits.
  Every one of the 56 table rows was then walked on the device through its own control
  (`build/webos-oe/prefs-row-walk.sh`): all 56 change the engine pref they name. A real key path
  (the kernel keyboard) types into a settings field.
- `window.open` from a tap opens a new card (new, `nsIWindowProvider` → `msgCreatePage`).
- Input sweep (taps, click count, toggles, key events, non-ASCII, selection, Enter/Tab, zoomed link),
  `about:config` end to end, the `about:addons` tools menu, touch events with one and two fingers.
- Offscreen sweep (size tracking, exact colours, buffer rotation, messages), `<select>` → card list.
- Shell sweeps: launch target on the variant's own socket, find, alert, failed load, 302, HTTP auth.
- Daemon sweeps: cookie + disk-cache persistence, low-memory guardrail, public `clearCookies` /
  `clearCache` on install-started daemons, dialogs hold the page.
- Device-build sweep: C++14 program, ELF attributes = CPU, memory (126 MB after eight sites, cap 150),
  the seven adapter-deps libraries match the manifest on CE.
- Key codes MEASURED from a real key path. `render/goanna/test/uinput_kbd.c` makes a kernel keyboard
  that LunaSysMgr on CE takes for a Bluetooth one; its keys reach the card and the daemon.
- Volume HUD: a volume KEY press during page audio changes the level and raises the HUD.
- Flash 33 fps; the in-tree control plugin loads, draws at the right place, takes a tap and a key.

**Defects found by the sweeps and fixed (all device-verified, all committed):**
no `change` event after typing; number fields edited the wrong element; chrome pages never scrolled
natively; the card re-enabled JavaScript on every connect; settings edits reverted on Back;
pages without a viewport tag drew as a thumbnail in Mojo; page key events carried raw webOS codes;
Up/Down were swapped, no Home/End; a field low on a tall page stayed under the keyboard; popup taps
were divided by the zoom twice and an opened menu was not painted; Mojo ignored a launch `target`;
find/selection was white on white; HTTP auth raised no dialog at all; damage rectangles were not
scaled at a fit zoom (clipped plugin, inexact Flash box).

**Still open, and why:**
- **Needs the owner's word:** removing a variant (T-231–T-234, T-273 — the permission gate refused
  it as irreversible deletion, so fresh-from-nothing install, the removal audit and "extensions of a
  removed variant" are untested); pushing the engine branch and bumping gitlink + SRCREV (T-279);
  how a user gets Flash; which rows the card's own settings panel should keep (T-290); Flash pacing
  B-vs-C (T-287); anything that needs a reboot (no reboot was made).
- **Needs a person at the device (T-280–T-291):** finger on card chrome, media controls, VKB typing
  and held Backspace, pinch, a real double tap on a plugin (T-212 is built and on the device), the
  physical volume rocker, the Mochi parity sign-off.
- **Known and recorded, not fixed:** arrow keys do not scroll a fit-zoomed page; the keyboard-cover
  check runs only at zoom 1; LunaSysMgr sometimes keeps Up/Left/Right from the kernel keyboard for
  itself; a failed load shows the engine's alert AND the shell's error panel; `window.open` gives
  the opener no window handle.
- **GRE key handover (gre-widgets R3):** `JIHAD_GRE_KEYS=1` in a job file turns it on for a session.
  It works for typing/arrows/Home/End/Backspace/Delete and does not crash; Enter/Tab stay on the
  daemon path. A clean handover needs two engine changes — see the kit.

**Device state as left:**
- All three variants installed through `org.webosinternals.ipkgservice` from the packages now in
  `build/webos-oe/out-ipk/` (enyo 1.0.4 `a0df34da…`, mochi 1.0.0 `dbe4f747…`, mojo 1.0.0 `074be9d3…`):
  libxul `65e3cc84891c59e9ede40cc7b3de0802`, daemon `50615b82ba73f06bb72cdbfc30a663fd`, goanna.js
  `82f9bbb3150b…`, PDK adapter impls enyo `6a35d778…` mochi `44ab2e23…` mojo `25aa85a4…`. Daemons were
  started by the installs; LunaSysMgr was not restarted by them (same pids before and after).
- Jobs are the shipped ones plus `JIHAD_INJECT=1` (re-added by hand after each install — an install
  writes the shipped job). No `JIHAD_GRE_KEYS`, `PULSE_SINK`, pacing or log env left behind.
- Enyo profile has `plugins/libflashplayer.so` (hand-copied, stock md5); the test plugin was removed.
  Mochi/Mojo have none. No test pref is left in any `prefs.js` (Enyo's was compared against a copy
  after the row walk).
- Cards left open: Enyo on `about:preferences`, Mochi and Mojo on `file:///tmp/jihad-shell.html` (none on `about:blank`).
- The uinput test keyboard is not running. `/tmp` holds test pages, scripts, `uinput_kbd` and
  screenshots (volatile). Residue to delete by hand: `/media/internal/downloads/jihad-testfile{,-1,-2}.bin`.
  `/media/internal/.developer/` holds our three `.ipk`s next to other people's.
- No reboot was made all session. `/` is read-write at rest (as found). `/var` at 21%.
- Three fault reports in `/var/log/reports/librdx/`, all from before this session's sweeps (the
  upgrade crash of the second session and two deliberate kills); none new.
- Cavekit: the loop is torn down (`teardown-loop`). The default `session_budget` of 500,000 stopped
  it at 1.1M tokens; the owner raised the live number in `.cavekit/token-ledger.json` to 10,000,000.
  `.cavekit/config.json` still says 500,000 and is what a NEW ledger starts from. `.cavekit/config` is
  a `key=value` file (it holds `codex_model`) and has an uncommitted edit of the owner's.

**Traps found this session:**
- Inject `click X Y` takes DOCUMENT px × zoom; `rect` answers in viewport CSS px. The card zooms to
  1.0 when a field takes focus, so coordinates taken before the first focus are wrong after it.
- `57346` is `0xE002`, not `0xE0A2` (57506). Arrow codes: Up 57504, Down 57505, Left 57506, Right 57507.
- Card JS is cached in LunaSysMgr until it restarts; `push-card-js.sh` handles it.
- `takeScreenShot` writes asynchronously: wait two seconds before reading the file.
- The `partial paint` log line is rate-limited to one per 2 s — it is not a frame counter.
- A banned port (e.g. 9) raises an engine alert that holds the daemon until the pipe is answered.
- An engine dialog holds the daemon: answer the FIFO named in the `dialog … -> card (pipe …)` line.
- `goanna.js` on the device comes from `make-device-bundle.sh`; a pref edit needs it re-run.
- A pref SET through the page while its value equals the default leaves no line in `prefs.js`.

---

## 2026-10-01 (second session) delta — kits updated, six defects fixed and device-verified; stopped early on the usage limit (SUPERSEDED where the delta above disagrees)

Kits were brought in line with CE 3.1.0 first (commit `f12c1111`), the build site regenerated
(`context/plans/build-site.md`, T-201…T-293), then `/ck:make` ran inline. Per-task record with every
number: `context/impl/impl-ce310-loop.md`. Screenshots: `context/impl/evidence-2026-10-01/`.
Nothing was pushed. The Cavekit loop was torn down at the stop (usage limit); the task registry (`.cavekit/task-status.json`, 37/91 complete) is intact and `/ck:resume` picks it up.

**Verified on the device (webOS CE 3.1.0), kit boxes closed:**
- `<video>` plays to the end — engine fix `1fff8023` on `third_party/uxp` `jihad-engine-mods`
  (LOCAL, unpushed; gitlink and OE SRCREV still `bd49435b`). 12/12 runs, VP8 + Theora, file + http.
- Codec table measured (VP8/VP9/Theora/Vorbis/Opus/WAV/FLAC play; H.264/MP3/AAC refused). FLAC needed
  the ffvpx libs, which were built but never bundled — now in `make-device-bundle.sh` and the push script.
- Idle daemon: 0.05% CPU, ~1 wakeup/s, 0 log bytes (was 2.4%, 117/s, 48 B/s). Log capped while running
  (copy-then-truncate, two in-lifetime rotations shown). `about:blank` settles (0 paints / 30 s).
- Card open on a static page: 2.2% CPU (was 12.3%) — quiet tick.
- Luna -1027 on fresh install: CONFIRMED, fixed in postinst (hub rescan) and daemon (retry), verified
  through `org.webosinternals.ipkgservice` on all three variants.
- Upgrade crash found and fixed: postinst `cp` over the mapped adapter shim killed LunaSysMgr at the
  next card launch; it now replaces by rename (three upgrades since, LunaSysMgr survived).
- TLS: `TLS 1.3` captured from howsmyssl and Cloudflare trace.
- Media controls: the stuck `0:00` scrubber bubble reproduced and fixed (daemon grows the damage box);
  click-seek works; mute/slider reach the pulse stream. Play/pause both directions.
- Cert store on CE works; two daemon fixes (retry the FAILED url after trust; drop the redundant
  engine error alert before the SSL confirm). Toast seen in all three shells.
- R9 probes: glibc 2.8 writes the same pshared-mutex `__kind` as 2.23 (the "second trap" was a
  2.5-proxy artefact); Flash's 67-lib closure resolves on CE.
- Flash on CE: works once `libflashplayer.so` is in the profile. The shipped build was pacing it on
  the 8 ms tick (worst histogram); the daemon now uses 16 ms while a plugin is on the page.

**Still open, and why:**
- **Fresh install from NOTHING + the postinst reboot (T-231…T-234, T-273):** removing a variant was
  refused by the session's permission gate (irreversible deletion). Needs the owner's go-ahead. The
  installs done today were install-OVER through ipkgservice.
- **Human-only (not attempted, not counted):** finger on the media controls / volume slider, volume
  HUD (needs a hardware key press), Flash B-vs-C eyeball, Downloads-app look, card-chrome taps, VKB.
- **Not reached (usage limit):** Atlas coexistence run (identity columns ARE checked: all distinct),
  volume-HUD write-up (T-240), add-ons/XPI sweep, preferences sweep, input sweep, offscreen sweep,
  shell sweeps, daemon sweeps, memory sweep, T-212 (plugin VKB), T-214 (arrow-key inject finding),
  rebuild of the three `.ipk`s.
- **Decisions for the owner:** how a user is meant to get Flash (nothing ships or installs
  `libflashplayer.so`; the CE profile had none); push `1fff8023` to the fork and bump gitlink + SRCREV.
- v3.1.0 `scripts/codex-review.sh` still needs `a833abf` cherry-picked; no Codex tier gate ran.

**Device state as left:**
- All three variants ipkg-registered, libxul `65e3cc84891c59e9ede40cc7b3de0802`, daemon
  `46d3714d430162502b3630cf63d4854b`, goanna.js `01154654…`, ffvpx libs present. **The `.ipk`s in
  `build/webos-oe/out-ipk/` are STALE** (daemon `3e29f045`, old Mojo toast): run `build-variant-ipk.sh`.
- Jobs are the shipped ones plus `JIHAD_INJECT=1` (all three). No pacing or log-cap env left behind.
  Enyo's `MOZ_LOG` is gone.
- Enyo profile has `plugins/libflashplayer.so` (hand-copied, stock md5). Mochi/Mojo have none.
- Mojo toast fix (`bottom: 84px`) is on the device but the card runs cached JS until LunaSysMgr restarts.
- LunaSysMgr crashed and restarted once today (the upgrade defect, 14:49 UTC; report in
  `/var/log/reports/librdx/`). The USB dialog it brought up was dismissed. Display set
  `onWhenConnected:true`.
- Residue to delete: `/media/internal/downloads/jihad-testfile{,-1,-2}.bin`; `/tmp/jm/*` and
  `/tmp/*.sh`/`*.png` are volatile. Other people's ipks in `/media/internal/.developer/` were left alone.
- `/` is mounted read-write at rest on this CE image (found that way). `/var` at 13%.
- Platform cert store holds session serials 1–3 from the tests (swept at daemon teardown/startup).

**Traps found today (all in `impl-ce310-loop.md`):** display off/locked or a system dialog makes
`takeScreenShot` return a stale frame; a second disconnected card is what gets photographed; inject
`click` takes CARD px, `clickoff`/`clickid` bypass the input queue; a `launch` in the first minute
after an ipkgservice install is dropped; `ipkgservice/install` returns before it is finished.

---

## 2026-10-01 session delta — device is now webOS CE 3.1.0, Cavekit is now v3.1.0 (SUPERSEDED by the delta above; kept as the stock-take)

This was a stock-take plus one finished diagnosis. **No kit was edited and nothing was fixed** — the
user's standing instruction is "update the kit criteria to reflect the current state BEFORE completing
tasks", and the session ended by moving the tooling to Cavekit 3, which needs a restart. Everything
below is input for that kit update. Nothing here is committed except what `git log` shows.

### Process: Cavekit v3.1.0 (was v2.0.0)

- `~/.cavekit` is on branch `cavekit-3.1.0` (tag `v3.1.0`, `9aa1905`). The two local v2 edits are saved
  as commits on `local/v2.0.0-edits-2026-10-01` (`a833abf` codex-review invocation, `b062631` findings).
  **v3.1.0's `scripts/codex-review.sh` still carries the stale `codex --approval-mode … -p` call and
  `o4-mini`**, so Codex review degrades until `a833abf` is cherry-picked onto it.
- **Start Claude Code from `Jihad-Browser/`, not from the parent `Jihad/`.** v3 resolves `context/` and
  `.cavekit/` against the CWD (`cavekit-tools.cjs`: `CAVEKIT_PROJECT_ROOT || process.cwd()`), and both
  live here. The parent's `CLAUDE.md` still loads from a subdirectory.
- First commands: `/ck:init` (idempotent — creates the v3 runtime state next to the existing v2
  `.cavekit/config`), then the kit update below, then `/ck:map`, then `/ck:make`. `/ck:status` and
  `/ck:resume` are new. The `bp:` alias is gone.
- **TRAP — v3's tool cache will serve stale device readings.** While a loop is active
  (`.cavekit/.loop.json` exists) a PreToolUse hook answers `Read`/`Grep`/`Glob`, and any Bash command
  that BEGINS with `ls|find|cat|head|tail|wc|which|file|git status|log|diff|show…`, from a 120 s cache.
  A device probe or a re-read of a growing log that starts with one of those words returns the previous
  output. Commands that begin with `novacom`, `cd`, or a variable assignment are never cached — keep
  device commands in that shape.

### The device: webOS CE 3.1.0 (build 86, BUILDTIME 20260830), freshly installed

Measured on the device, not assumed:

- Kernel `2.6.35-palm-tenderloin` and **glibc 2.8 are unchanged**, so every cross-ABI statement in
  cavekit-device-build.md R9 still describes this device.
- Stock OpenSSL 0.9.8 is still `/usr/lib/libssl.so.0.9.8`; the new stack is side-by-side OpenSSL 1.1.1w
  (`ssl11`, `ssl11dl`, `ssl11mail`; `curl 7.88.1 … OpenSSL/1.1.1w`). **Jihad uses neither** — page TLS is
  the engine's own NSS 3.90 (`security.tls.version.max=4`). HTTPS loads work (`https://example.com`,
  `https://www.howsmyssl.com/a/check`), but **the negotiated `tls_version` string was never captured**
  (the grep for it came back empty on 2026-09-27) — that one read is still owed before any kit says
  "TLS 1.3 verified".
- CE preinstalls the **Atlas** browser (`org.webosports.app.atlas`, `BrowserAdapterAtlas.so`,
  `/tmp/yapserver.atlas`, its own daemon). A fourth browser now coexists; R7 independence has not been
  re-checked against it.
- Flash is still present (`com.palm.app.flashplugin-001`, same `libflashplayer.so`), the
  `com.palm.flashgraphics` role name is in the stock browserServer role files, and there is still no
  keyboard (`gpio-keys`, `pmic8058_pwrkey`, `headset` only).
- **Every `[x]` that says "device-verified" was verified on webOS 3.0.5.** None has been re-run on CE
  3.1.0 except what is listed in this delta.

### What the interrupted 2026-09-27 session did (recovered from its transcript)

Rebuilt the daemon (YAP contract OK, 73 commands), built all three `.ipk`s (enyo 1.0.4, mochi/mojo
1.0.0) and deployed all three with `push-variant.sh` (the real postinst, as root). On CE 3.1.0 that
gave: three daemons running, three YAP sockets, card renders, pages load over HTTP and HTTPS.

- **`<audio>` works on a clean install.** Vorbis: `paused=false t=9.926 dur=15`, ALSA `state: RUNNING`,
  pulse sink-input RUNNING at 100%. The 2026-08-20 "currentTime never advances, stream stuck PREPARED"
  finding in `context/impl/impl-media-controls.md` was an artifact of the hand-pushed engine that
  session left behind — it does not reproduce. The scrubber/volume-widget/volume-HUD items in that file
  have NOT been re-tested.
- **Fresh-install LS2 ordering — unverified, looks real.** The first daemon start after postinst logged
  `LSRegisterPalmService('net.riverstonerelay.jihadBrowser') FAILED (code=-1027)`; it registered after
  `ls-control scan-services` plus a daemon restart. If postinst starts the daemon before the hub has
  rescanned the role files, the toast channel and `clearCookies`/`getChromePrefs` are dead until the
  next restart. Read `packaging/gen-variant-scripts.sh` before believing either way.

### NEW DEFECT 1 — `<video>` dies with MEDIA_ERR_DECODE after 10–60 frames. ROOT CAUSE FOUND, fix NOT applied

Symptom, every codec (VP8, Theora), `file://` and `http://`:
`err=3:0x8007000e: DoDecode`, `vq=9/0/0` … `57/0/0`, then playback stops. The frame count at failure
varies run to run, which is the tell.

Cause, from two rounds of temporary stderr traces plus the source:

1. `BasicImageLayer::Paint` (`gfx/layers/basic/BasicImageLayer.cpp:72`) swaps the `ImageContainer`'s
   factory to the BasicLayerManager's `BasicImageFactory` **for the duration of the paint** and restores
   it afterwards. `IsCompositingCheap()` is false for BasicLayers, and BasicLayers is what paints here
   because OMTC is off (`JIHAD_DISABLE_OMTC=1`).
2. The decoder thread calls `ImageContainer::CreatePlanarYCbCrImage()` concurrently. Inside that window
   it gets a `BasicPlanarYCbCrImage`.
3. `VideoData::SetVideoDataToImage` always does `SetDelayedConversion(true)` then `CopyData()`, and
   `BasicPlanarYCbCrImage::CopyData` (`gfx/layers/basic/BasicImages.cpp:88`) does
   `RecyclingPlanarYCbCrImage::CopyData(aData); if (mDelayedConversion) { return false; }` — it reports
   failure for a copy that succeeded.
4. `CreateAndCopyData` returns null → the decoder returns `NS_ERROR_OUT_OF_MEMORY` → MEDIA_ERR_DECODE.

On desktop the paint window is microseconds; on the TouchPad a software paint is 40–160 ms, so a decode
lands inside it within a second or two. Evidence: the trace fired `CreateAndCopyData:
SetVideoDataToImage/CopyData FAILED` with NONE of the inner allocation/lock/size traces — i.e. the base
copy succeeded and the `false` came from the delayed-conversion line.

Proposed fix (three lines, engine, **not built, not verified**): in `BasicPlanarYCbCrImage::CopyData`,
return the base class's result and return `true` under delayed conversion. A delayed image is fully
usable — `GetAsSourceSurface()` already converts on demand when `mDecodedBuffer` is null.

This also re-dates two kit boxes: "VP8 plays" (2026-08-10) and the play/pause `[~]` (2026-08-15,
`t=0.73`) were both read inside the first second, before the failure.

Test assets: device `/tmp/jm/` (volatile) holds `jihad-media.html` (state readout in `#state`, pick the
clip with `?v=clip10v.webm`), `clip10{,v,a,g,op}.webm`, `clip10.ogv`, `tone15.{ogg,wav}`. Regenerate:
`ffmpeg -f lavfi -i "testsrc=size=320x240:rate=15:duration=10" -c:v libvpx -b:v 200k -an clip10v.webm`,
`ffmpeg -f lavfi -i "sine=frequency=440:duration=15" -c:a libvorbis -q:a 3 tone15.ogg`. The page itself
was pulled off the device and is now `render/goanna/test/jihad-media.html` (untracked, md5-matched to
the device copy); the clips are regenerated, not stored.

### NEW DEFECT 2 — an idle daemon fills `/var`

A daemon with NO card connected writes one `tick period` line every 2 s and nothing else: **82 B/s,
~7 MB/day per variant** while the device is awake. mochi and mojo had reached **10.1 MB each** after
3.6 days idle, on a 62 MB `/var`. Three variants idle is ~21 MB/day. The job rotates the log only at
start. Same family as `jihad-var-full-kills-daemon-log`: a full `/var` freezes the log and a frozen log
reads as a live one. The same lines show the idle daemon ticking at 8 ms with no page (`n≈241` per 2 s,
~2.8% CPU each, indefinitely).

### NEW DEFECT 3 — `about:blank` is a repaint storm

On `about:blank` the daemon logs `painted shmid=… bytes=0 … ms=35` about 22 times a second forever
(663 full paints in 30 s, 2.4 KB/s of log, ~210 MB/day). The full path gets a zero-byte frame, will not
publish it, and tries again every tick. `about:blank` is an allowlisted home page (`safeUrl`), so a user
can select this state. A static page with real content is quiet (16 lines / 30 s).

### Seen, NOT verified

On the media test page the card and daemon traded `emitGeometry contentSize=…` / `setZoomAndScroll
zoom=…` continuously (1662 → 2102 → 2022 → 2012 → 1972 → 2042 px). The page's `#state` is
`white-space:pre` and its event line grows, so the content width really does change every 500 ms —
this is probably the page and not a fit-width feedback loop. Do not record it as a defect without a
page whose content width is fixed.

### Kit work owed before any task (this is the next step, not optional)

- cavekit-device-build.md R4: the target is now CE 3.1.0; add criteria for fresh install, LS2
  registration on first start, coexistence with Atlas, and a re-verification sweep of the 3.0.5-only
  `[x]` boxes. R8: a log-growth bound and an idle-tick criterion (defect 2).
- cavekit-gre-widgets.md R1: `<video>` is broken past the first second (defect 1) — the "VP8 plays"
  and play/pause boxes are overstated. R7 still says "the engine has NO audio output at all", which
  has been false since 2026-08-15.
- cavekit-offscreen-rendering.md R8: a genuinely blank page must settle (defect 3).
- cavekit-browser-services.md R5: record the engine-NSS TLS position and the uncaptured `tls_version`.
- `context/impl/impl-media-controls.md`: the 2026-08-20 diagnosis is superseded (see above).

### Device and tree state as left

- All three variants installed from the 2026-09-27 `.ipk` payloads. **enyo runs a TRACED libxul**
  (md5 `cb514e9e11f34a6db94ceb1d44222cce`, prints `[jihad-media-trace]` on a failed frame copy); mochi
  and mojo run the `.ipk` build (`78c3b51a60d9959cbe313696e8ae26a7`). A push of all three puts them
  back in step.
- `/etc/event.d/jihad{,-mochi,-mojo}` all carry the device-local `JIHAD_INJECT=1`. **enyo's also carries
  `MOZ_LOG=sync,MediaDecoder:5,…`** from 2026-09-27 — it produced zero lines and should be removed
  (`sed -i 's/ MOZ_LOG=[^ ]*//' /etc/event.d/jihad`, then `stop jihad; start jihad`).
- The enyo card is parked on `/tmp/jihad-plain.html` (static). **Do not park on `about:blank`** — defect 3.
- mochi and mojo logs were truncated at 05:31 device time; `/var` is at 12% (54.7 MB free). At the
  idle rate that is days, not weeks — check `df /var` first thing.
- `third_party/uxp` is clean at `bd49435b`; the trace edits were reverted. The out-arm objdir libxul
  (2026-10-01 08:25) is the traced build and is stale against the tree until the next engine build.

---

## 2026-08-17 session delta — speaker route + live volume SOLVED, Mochi safeUrl done (read first)

The non-human-gated engineering surface is essentially exhausted this session. Kit-wide only **2**
criteria remain open (`grep -rn '\- \[ \]' context/kits`), BOTH keyboard/hardware-gated (there is no
keyboard on the device — open work item 1). PICKUP **open work item 3 is STALE**: R8's last criterion
is `[x]`, decided 2026-08-10 (geometry guards + the sub-rect argument bound the partial path; no blank
check needed).

- **Engine media now plays on the built-in SPEAKER at the system volume, and volume buttons track it
  live** (`render/goanna/BrowserPageGoanna.cpp`, commit `ed6cced6`; pairs with UXP-Jihad cubeb
  `bd49435b`). audiod refuses to route/scale OUR stream (its media volume is a PULSE control, proven by
  an `amixer contents` diff showing zero ALSA change on a button press), so the daemon drives the
  WM8994 mixer directly: a poll thread on `jihad_pulse_active_streams()` runs state-dir shell scripts
  it (re)writes from embedded constants — `audio-on.sh` (level `numid=74/86` from `getVolume`, then the
  DAC1→speaker switches `191/186/237/235/87`), `audio-off.sh` (mute amp `87` at rest → no max-volume
  burst), and `audio-vol.sh` every ~400ms (re-mirror `getVolume` → live tracking). `pulse.props` keeps
  the stream on `pcm_output` (NOT `media.role`/pmedia, which the forced route can't reach). Full detail
  + the dead ends: `context/impl/impl-audio-backend.md` §2026-08-17. Ear-confirmed: speaker ✓, no burst
  ✓, ~volume ✓. **RESIDUALS (human-gated, not shipped-blocking):** the volume OSD/HUD does not show for
  direct mixer writes (audiod-bypass, cosmetic); HTML5 video-controls taps are the separate offscreen
  hit-test item. **SHIP GATE:** parent gitlink + OE SRCREV stay at `81e10aa3` until UXP-Jihad
  `bd49435b` is pushed — the .ipk engine keeps the counter inert (audio unchanged) until then; the
  device runs the full hand-deployed stack now.
- **Mochi `safeUrl` allowlist done** (`app-mochi/source/JihadChromePrefs.js`): `http(s)://` or
  `about:(preferences|settings|jihad|isis|blank)` pass, everything else → `""`, applied in
  cleanLinks/loadHome/saveHome.

---

## 2026-08-16 session delta — bitbake `.ipk`s ship + the media scrubber is fixed (read first)

The two biggest open items are CLOSED, and this session's work IS committed (branch
`jihad/about-preferences-and-settings-merge`; engine mods on `third_party/uxp` branch
`jihad-engine-mods`).

- **OE bitbake produces all three `.ipk`s (device-build R3 DONE).** `bitbake
  net.riverstonerelay.jihad-browser{,-mochi,-mojo}` → `639 tasks ... all succeeded`, zero errors;
  each `.ipk` extracted + verified COMPLETE by content (daemon, libxul, plugin-container, ld-2.23,
  goanna.js, 1104-file chrome). Five recipe gaps were fixed to get here — see `../context/plans/build-site.md`
  T-154 and `../context/impl/dead-ends.md`. **Trap that ate two "successful" builds:** a goanna
  SRCREV bump does NOT re-fetch in this bitbake-1.18 setup (do_unpack keeps the old checkout); a
  chrome-only change needs `bitbake -c cleansstate goanna jihad-deviceroot
  net.riverstonerelay.jihad-browser{,-mochi,-mojo}` (after pre-warming the DL_DIR git mirror) + a
  CONTENT check of the packaged file, never mtime/size.
- **Media scrubber jitter/flash/no-settle FIXED (gre-widgets R1 back to `[x]`), device-confirmed.**
  Instrumentation proved the media/DOM state is perfect — the defect was the daemon's offscreen
  paint: damage-only repaint into three rotating buffers left GHOST thumbs (each buffer got only the
  latest frame's damage though it was several frames stale). Fixed with per-buffer damage
  accumulation (`BrowserPageGoanna` `BufFrame.dmg*`). Plus videocontrols: `ended` snaps the thumb to
  `duration`, and a 40ms interval interpolates the thumb from the live currentTime clock. 40ms is
  the ceiling — faster (25ms) overruns the adapter round-trip and FREEZES (checked against Atlas
  BrowserServer's identical double-buffer + wait-for-return model). Residual un-smoothness is the
  ~25–30fps software-paint cap, i.e. hardware.
- **Audio plays** through the cubeb PULSE backend (`JIHAD_PULSE_SINK=pmedia`), device-confirmed
  audible — the ALSA-bridged path was policy-muted; the pulse-native path gets 100%.
- **Engine provenance changed:** the jihad engine delta is now a durable commit `0c10df5c` on
  `third_party/uxp` branch `jihad-engine-mods` (pristine UXP `b2594a4` + the delta), pinned by the
  goanna recipe SRCREV — not only the desktop patch queue. Reproducibility caveat: that commit is
  now pushed to the fork `https://github.com/NotAlexNoyle/UXP-Jihad` (`.gitmodules` points there,
  branch `jihad-engine-mods`, parent gitlink bumped to `81e10aa3`), so a fresh clone + submodule
  update resolves the SRCREV.
- **Dotted-mochi `.ipk` was a 07-29 orphan (removed).** Current recipes emit only the HYPHENATED
  ids (`…-mochi` / `…-mojo`).

Device was used this session (TouchPad on novacom); it runs the pulse-audio libxul + per-buffer-fix
daemon + scrubber-fixed videocontrols. The 2026-08-15 and 2026-08-10 sections below are retained as
history — where they say "nothing is committed" or "the device is absent", read this delta instead.

---

## 2026-08-15 DEVICE session — the TouchPad reappeared near the end (historical delta)

Full transcript: `context/impl/impl-device-2026-08-15.md`. The device was plugged in mid-session and
the enyo variant was redeployed (ipk 1.0.4 + current daemon/adapter). Verified ON HARDWARE:

- **Cert store (T-135) — CLOSED end to end.** `/var/ssl/jihad/enyo` created (daemon is in group
  `luna`), real DER→PEM written, classified to ordinal 18 from `nsISSLStatus` flags, `CertInitCertMgr
  rc=0`, `Adding Entry … serial 6`, `CertAddTrustedCert` rc=0, NSS override + reload, page loads.
  `libPmCertificateMgr.so` present on 3.0.5. browser-services R5 device box → `[x]`.
- **Toast channel (T-146) — CLOSED.** `clearCookies` on the public bus pushed a notify and the Enyo
  card rendered the "Cookies cleared." toast, visible in a device screenshot. gre-widgets R5 last → `[x]`.
- **Focus transitions correct on device** (editorFocused 1→0→1); the desktop focus_test failure is
  harness-side, not the daemon.
- **AUDIO: the backend works and reaches pulse, but output is webOS-POLICY-gated — and the gate is now
  FULLY reverse-engineered.** `<audio>` gives `err=0` and pulse shows our sink-inputs at
  `s16le 2ch 44100Hz`, but sinks stay SUSPENDED — webOS powers the WM8994 codec route only while a
  policy-recognised media stream plays. Stock mechanism: `element.palm.audioClass="media"` (Palm
  WebKit extension, `media.js:288`) → `pmedia` sink + audiod media scenario. Port's path (specified,
  three parts, none human-gated, in `impl-audio-backend.md` §2026-08-15): (1) route engine ALSA at the
  `pmedia` sink via `ALSA_CONFIG_PATH`, (2) hold a `com.palm.audio/media` scenario ref-counted over the
  playback lifetime (daemon already has an outbound Luna client), (3) validate. the mechanism is now
  FULLY DECODED and the fix is DETERMINED (a bounded build task, not research). Read
  `module-palm-policy.so`: virtual sinks (pmedia/…) are NULL sinks; audiod bridges one to hardware +
  powers the codec ONLY for a stream CREATED on that virtual sink; default-device streams are muted
  ("PLEASE CATEGORIZE USING A VIRTUAL STREAM"). Engine decode+clock WORKS (t 0→3.00, ended, err=0) but
  is policy-muted on pcm_output at 0%. **The ALSA backend was a DEAD END (policy-muted); the cubeb PULSE
  backend was BUILT + DEPLOYED + DEVICE-VERIFIED 2026-08-15 and it UNMUTES engine audio.** The engine
  stream is now pulse-native (`application.name="Jihad Browser"`), `Volume: 100%`/uncorked (not the
  ALSA path's forced 0%), and `/proc/asound/…/status` shows the WM8994 DAC consuming its samples
  (`hw_ptr` advancing ~44100/s). Implemented: mozconfig `--enable-pulseaudio`, pulse-0.9.22 headers
  staged in the sysroot (device-ABI-matching; re-fetch via `curl
  freedesktop.org/software/pulseaudio/releases/pulseaudio-0.9.22.tar.gz`, headers `src/pulse/*.h` +
  a `libpulse.pc`), patch `0030-cubeb-pulse-webos-virtual-sink.patch` (`JIHAD_PULSE_SINK`; cubeb
  dlopens libpulse, no link dep — all 62 symbols present in the device lib). The pulse-native app
  IDENTITY is what unmutes it. **Residual (the only thing left, needs a human EAR — both automated
  oracles broken here: `parec` monitor = 0 bytes, `hw_ptr` runs during pause): whether the speaker
  physically emits, plus a possible daemon-side hold of the `com.palm.audio/media` scenario to power
  the speaker amp (the unmute does not need it, measured).** Full spec: `impl-audio-backend.md`
  §"RESULT 2026-08-15". **Bundle-Jessie-libasound decision is WRONG:** Jessie 1.0.28 → `err=3`,
  device's own `/usr/lib/libasound.so.2` → `err=0`. Stop shipping the bundled one. MP3/AAC/H.264
  decoders remain a separate, orthogonal gap.

Device traps found: two stray `jihad.bak.*` upstart jobs were contending for the enyo socket
(removed); cryptofs forbids symlinks; a `file://` XPI navigation does NOT trigger the install flow
(so T-103's device screenshot is still open — needs an http-served or card-initiated XPI). Device
left: enyo on current binaries, job env back to shipped flags, test certs swept, adapter backup at
`/var/palm/jihad/adapter-backup-20260815/`.

## 2026-08-15 session delta — read before the 2026-08-10 body

A cavekit loop (`context/plans/build-site.md`, now reconciled row-by-row; per-wave record in
`context/impl/loop-log.md` Iteration 3) closed or advanced every host-doable open criterion.
No device all session, so nothing below is device-verified unless it says so.

**Closed outright:** ipc-contract R1 (generator vendored+patched, regeneration reproduces the
shipped wire, zero hand edits — `render/browserserver/CodeGen/`); gre-widgets R5 first criterion
(notificationbox attach/dismiss PASS on the offscreen PuppetWidget path — `prefsui_test`);
gre-widgets R7 prefs-single-source (eleven rows observed from the shared file on desktop);
preferences-ui flush box (was already device-proven 2026-08-10, box reconciled); opal machine
config (kernel string was WRONG — board is `shortloin`; pinned from HP's own source drop);
T-115 prebuilt-input manifests (187-deb sysroot + adapter-deps, generators in `build/webos-oe/`).

**Built, awaiting a device:**
- **Engine audio output** — cubeb ALSA backend is IN the ARM libxul (`--enable-alsa`, Jessie
  alsa-lib staged; `DT_NEEDED libasound.so.2`). First listen: `jihad-media.html` with an
  Ogg/Vorbis or WAV asset (MP3/AAC/H.264 decoders are STILL OFF — ffvpx config, separate gap).
  Fallbacks if silent, in order, in `context/impl/impl-audio-backend.md` (PCM `default` may route
  to a nonexistent pulse plugin; `ALSA_CONFIG_PATH` override; drop-bundled-lib).
- **Cert store (T-135)** — all three 2026-08-10 defects fixed and desktop-proven live (real PEM
  certFile, Palm-ordinal error mapping off `nsISSLStatus` — the raw nsresult was a transport-class
  lie —, three-way trust with session-serial sweep at teardown AND startup). Platform writes via
  dlopen'd `libPmCertificateMgr`; first device line: `ls /usr/lib/libPmCertificateMgr.so*`.
  Read-direction (store→NSS) is COSTED not built (`context/impl/impl-cert-store.md`).
- **Touch events (T-120)** — fence out behind **`JIHAD_TOUCH_EVENTS=1` (default OFF)**; 28-byte
  header re-staged (sizeof guard proven both ways); double-activation suppressor daemon-side;
  device procedure in `context/impl/impl-touch-events.md`. Two real bugs fixed en route (TouchEnd
  OOB index; `npPalmEnableTouchEvents` was never set — un-fencing alone was a silent no-op).
- **Non-blocking toast channel (T-146/T-148)** — `jihad::PostNotification` → `notifications` Luna
  subscription → plain-DOM toasts in all three shells. The only informational dialog (T-103
  incompatibility alert) moved onto it; cookies/cache-cleared and add-on-installed notices ADDED
  (they emitted nothing before). Three device unknowns; one Preferences→Clear-cookies run splits
  them (`context/impl/impl-toast-channel.md`).
- **XPI mismatch alert (T-103)** — observer fires on desktop with a discriminating control; device
  screenshot is the closer.

**NEW TRAPS, same class as the body's:**
- **`out-ipk/` ipks ≤1.0.3 have NO libasound.so.2 and their daemon will NOT START** against the
  new libxul. Install 1.0.4+ only; the enyo 1.0.4 / mochi / mojo ipks built 2026-08-15 carry it
  (verified in all three).
- **`build-goanna-arm.sh` exited 1 on every SUCCESSFUL build until 2026-08-15** (grep|while under
  pipefail; 27/29 patches have no JS). Fixed; historical automation that trusted its exit code
  never saw its own staleness guards run.
- **`mFlashGestureLock` is set ONLY by a DOUBLE-tap** (`handlePenDoubleClick`, which also
  smart-zooms) — the "tap inside a plugin rect" wording in older notes is wrong, and NO latch log
  compiles (`Debug.h` DEBUG off). T-124/T-144 rescoped; keyboard-arbitration procedure rebuilt
  around the address-bar screenshot (addons kit R7, 2026-08-15 annotation).
- **`javascript:` URLs are dead in ALL chrome documents** (HTML too, not just XUL) — so
  `GoannaRenderPage::ScrollTo` is a no-op on chrome pages. And a **stale desktop profile** fakes
  pref regressions (see `context/impl/dead-ends.md`, both dated 2026-08-15).
- The dotted Mochi app id in the workspace CLAUDE.md is fixed (hyphens are correct).

**What remains, exhaustively:** every open criterion is device-, hardware-, or human-gated. With
a device + novacom (needs root for novacomd): the verification batch above, T-108 (hidd routing),
T-116, T-119/T-133, T-131, T-141, T-142→T-147. Human at device: T-150/T-151/T-152 and the frame
pacing EYEBALL decision (device deliberately left in Flash-alone — body below). Human decisions:
T-155 sign-off, T-156 Mojo settings exemption, whether to commit this tree (137+ files were
already uncommitted before 2026-08-15; the session added more and committed nothing).

---

## What this is

Jihad Browser: a fork of isis-browser (webOS 3 / HP TouchPad) with **UXP/Goanna** replacing
QtWebKit, keeping the isis UI and the BrowserAdapter↔BrowserServer YAP IPC contract. Three
variants ship independently: Enyo (`app/`), Mochi (`app-mochi/`), Mojo (`app-mojo/`).

Requirements live in `context/kits/` — start at `cavekit-overview.md`. The Flash/NPAPI work is
`cavekit-addons-extensions.md` **R7**.

---

## Flash: where it actually stands

Adobe Flash renders animated content on the TouchPad through UXP/Goanna, takes mouse and
keyboard input, **plays sound**, survives crashes and freeze/thaw, and holds ~30 fps composite
with patch `0027`. Two things are UNFINISHED: chrome-side keyboard arbitration (untestable on
this hardware) and frame PACING — the composite RATE is met, and the pacing ROOT CAUSE is now
found and measured: **two producers.** Flash invalidates itself and we also drive it, and our
frames land between its own. Isolated three ways; Flash alone is slower but has **zero** gaps
under 16 ms. The decision left is a design one, not a debugging one — see open work item 2.
**Audio is CLOSED**, at parity with stock; an
earlier version of this sentence listed "MP3 static (fix landed, unheard)" and that contradicted
the dated audio section below, which cost a session start. Precisely:

| | state |
|---|---|
| renders animated content | ✅ device-verified |
| **frame rate** | ✅ **composite 30.6-32.5 fps** via patch `0027` (CPU boost); gap avg 28-29 / max 45-49 ms |
| **mouse input** | ✅ `palm event 0x1/0x2/0x10000` at correct coordinates |
| **keyboard input → plugin** | ✅ Flash's own AVM1 runs on a keypress (green 11768 → red 11750) |
| **keyboard arbitration (chrome)** | ⚠️ **UNTESTABLE on this hardware** — no keyboard exists; synthetic one is read by hidd but never dispatched |
| crash containment | ✅ daemon survives a plugin SIGSEGV; plugin respawns on reload |
| spotlight event | ✅ suppressed by default (delivering it kills Flash — matches stock) |
| **audio** | ✅ **CLOSED 2026-08-10 at parity with stock.** All three defects were in the TEST ASSETS. The residual per-loop click is Flash restarting its MP3 decoder, and the STOCK browser does it identically |
| **frame PACING** | ⚠️ **ROOT CAUSE FOUND 2026-08-10: TWO PRODUCERS.** Flash invalidates itself ~25/s AND we drive it ~26/s, and our frames land between its own — that interleaving is the bunching. Isolated and measured all three ways: Flash alone is **slower but perfectly unbunched (zero gaps under 16 ms)**, the pull is faster and bunched. The device is LEFT in Flash-alone for a human to eyeball |

### Audio: solved, and the bug was in the TEST ASSET

**Flash audio needed no port-side change at all.** Every "silent" measurement in this tree was
taken against SWFs that could not have made a sound in any player.

`make-audio-swf.py` emitted `DefineShape` **and** `DefineSound` with the **same character ID 1**.
A SWF has ONE character dictionary shared by shapes and sounds, so the sound redefined an ID that
was already taken; the player keeps the first definition and drops the sound, `StartSound 1` then
resolves to a shape, and nothing plays. Silently: no error, no audio device ever opened, no mixer
thread. All three assets (PCM, MP3 mono, MP3 stereo) shared the bug, which is exactly why they
"behaved identically" and made this look like a player-side gate.

Fixed by giving the sound its own ID (`SOUND_ID = 2`). With the STOCK, UNPATCHED
`libflashplayer.so` the corrected SWF immediately produces the whole ALSA bring-up that was
missing for the entire investigation:

```
open("/usr/share/alsa/alsa.conf")                       = 27
access("/etc/asound.conf", R_OK)                        = 0
open("/usr/lib/alsa-lib/libasound_module_pcm_pulse.so") = 27
open("/usr/lib/libsndfile.so.1")                        = 27
```
plugin-container goes **3 → 5 threads**, and the tone is audible from the device speaker.

All three assets have been regenerated and re-pushed. Regenerate before trusting any audio
measurement anyway — `/tmp` is volatile, and any SWF still sitting on a device from before
2026-08-10 is a broken one. The `--mp3` variants need a BARE frame stream with no ID3; make one
with `ffmpeg -f lavfi -i "aevalsrc=..." -codec:a libmp3lame -write_xing 0 -id3v2_version 0`.
PCM is confirmed clean by ear. **MP3 was heard too and IS clean** — the per-iteration click is
Flash restarting its decoder at the loop point, and the stock browser does it identically, so it
is not a port defect. Judge MP3 quality ONLY with `jihad-audio-long.swf` (30 s, `--loops 1`),
which has no loop point at all; every other MP3 asset here clicks once per iteration no matter how
healthy the port is. There is no open audio item.

### The "audio gate" in the previous handoff was the VIDEO DECODER — do not chase it

The function at **0x70ee0** and the loader at **0x73020** have nothing to do with audio. Measured,
not guessed: 0x73020's string table is `libmm-omxcore.so` / `libOmxCore.so` resolving `OMX_Init`,
`OMX_GetHandle`, `OMX_GetComponentsOfRole`; 0x70ee0 passes `"video_decoder.avc"` (rodata 0x760cec)
and `strncmp`s candidates against `"OMX.Nvidia"` (0x760d00) with 128-byte entries
(`OMX_MAX_STRINGNAME_SIZE`). It is hardware H.264 decoder setup. `+24` is a codec enum, and it
**does** equal 7 — the factory at 0x5bff0 returns NULL unless the caller asks for type 7 and the
constructor at 0x72a30 stores that same 7 (`72a94: str r4,[r8,#24]`). The old note had the gate
inverted as well as in the wrong subsystem.

**Where the real ALSA code lives**, if it is ever needed again (all GOT-relative, base 0x85897c):
- **0x2f7bd0** — the ALSA loader. `dlopen("libasound.so")`, falls back to `"libasound.so.2"`,
  resolves ~50 `snd_*`, then NULL-checks every one; any NULL and it returns 0.
- **0x2f71e0** — `OpenPCM`, vtable slot +8 at vptr 0x84e440, ctor 0x2f75f0. Opens the PCM, sets
  access/format/rate/channels, 500 ms buffer / 20 ms period, then `pthread_create`s the mixer.
  It asks for **`plughw:0,0`** (0x7b54c8) as its FALLBACK name — the old note's `hw:0,0` was that
  string read four bytes in.
- `0x2fbf08` is a separate availability **probe** that loads libasound unconditionally at startup.
  That is the `dlopen` every previous trace saw; it proves nothing about playback.

**Already eliminated — do NOT redo these:**
- Our runtime can play sound. `render/goanna/test/alsa_probe.c` writes a square wave and it is
  AUDIBLE, under both the device's own loader and `./ld-2.23.so --library-path $HL`.
- Not PIpc (zero `PIpcClient` ctors even with an audio SWF), not LS2 permissions (role grants
  `outbound:["*"]`), not Flash's OEM profile (`/media/cryptofs/apps/etc/adobe/{mms,oem}.cfg`,
  `cctrl = 3`), not click-to-play deferred start, and not the host — `libWebKitLuna` has no
  PluginView audio methods and no ALSA/pulse references at all.
- Not the two gates that looked like candidates. Both were nopped on-device and changed NOTHING:
  the sample-count check `2f7234: cmp r1,#31 / ble` in OpenPCM, and the `audioEnabled` check
  `19ba54: beq` on `sound+0x270`. That pair of null results is what finally pointed at the asset.
- One real bug WAS found and fixed here: Flash's `kind not registered:
  'com.palm.app.flashplayer.prefs:1' (-3970)` on every instantiation. The db8 kind is now
  registered (owner `com.palm.flashgraphics`) and the error is gone. It was unrelated.

---

### Frame rate: the cause is CPU FREQUENCY, not the pipeline and not Flash

**Measured 2026-08-10.** Sampling `/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq` once a
second while `jihad-anim.swf` played:

```
192000 192000 192000 192000 192000 192000 192000 540000 384000 384000 384000 384000 384000
idle, right after navigating AWAY: 1188000
```

Flash renders at **192-384 MHz out of a 1188 MHz maximum**. Frame rate tracks it exactly — daemon
paints 20.8-23.9 fps, composite 16.3-29.1 fps — and the SPREAD is what reads as "skippy". The
system was only 69% busy across 2 cores at the time, so this was never a capacity wall; the
pipeline is clean (`deferred=0`, `wanted == done`), and on one run at a higher clock the same
pipeline reached **39.2 fps**, well above the 30 the content is authored at.

The governor is Palm's **`ondemandtcl`** — touch-biased. It boosts while the user is touching the
screen and decays otherwise, so passive playback (watching an animation, listening to audio) runs
at the floor. This also explains the audio xruns: MP3 decode at 192 MHz underruns.

**DO NOT "just set the governor to performance" — it WEDGES THE DEVICE.** Writing
`scaling_governor` while `ondemandtcl` is live deadlocks the cpufreq policy lock in the kernel.
Every later reader of any cpufreq sysfs node blocks in **uninterruptible D state** — including the
Jihad daemon, `powerlog`, and the restore script itself, so the governor never gets put back and
the daemon stops painting. D state cannot be killed; only a reboot clears it. Nothing persists
(it is a runtime sysfs value), so a reboot returns to `ondemandtcl`, but the whole session's
measurements are lost. This cost a device reboot on 2026-08-10.

**THE SAFE LEVER, AND IT WORKS — measured 2026-08-10.** `ondemandtcl` exposes ordinary governor
tunables at `/sys/devices/system/cpu/cpufreq/ondemandtcl/`. Writing those does NOT switch
governors and does NOT take the path that deadlocks; the write returns instantly and a readback
succeeds. Stock values and the two that matter:

```
up_threshold  = 95      <-- only ramps when a core exceeds 95% load
sampling_rate = 200000  <-- and only looks 5 times a second
```

95% is why Flash never boosts: the daemon runs ~26% and plugin-container ~11% of two cores, so no
single core ever approaches the threshold. Setting `up_threshold=40` and `sampling_rate=50000`
pins the clock at 1188000 and produces, on `jihad-anim.swf` (30 fps authored), single instance:

| | stock | tuned |
|---|---|---|
| daemon paints | 24.0-28.7 fps | **31.4-33.0 fps** |
| card composite | 20.4-27.5 fps | **30.7-35.2 fps** |
| frame gap avg / max | 34-42 / 63-81 ms | **30-31 / 49-56 ms** |

Composite now meets the authored rate AND is matched to the draw rate, which is what the
criterion asks for. `deferred` stayed 0 throughout, both before and after — the pipeline was
never the constraint.

**What is NOT yet done: making this OURS rather than a manual poke.** These are SYSTEM-WIDE
tunables, so the daemon must apply them only while a plugin instance is alive and restore the
stock values on teardown (and on crash — an upstart `post-stop` is the honest place for the
restore, since a daemon that dies with `up_threshold=40` leaves the whole device tuned for
battery-burn). Read the stock values rather than hard-coding 95/200000. Do NOT touch
`/sys/devices/system/cpu/cpufreq/override/{turbo_mode,vdd_*}` — that is overclocking, and
`vdd_freqs` goes to 1836000.

---

## Frame pacing — what was wrong, what is fixed, what is left (2026-08-10)

The user's report was "the pink square is smoother in the STOCK browser". It is a real defect and
the average frame rate never showed it: the daemon was delivering 35-42 fps for a 30 fps SWF.

**The measurement that found it is a gap HISTOGRAM, not min/avg/max.** Summary statistics cannot
distinguish "evenly late" from "unevenly on time", and every earlier session's numbers were
summary statistics. Added to the 2 s counter block; the failure looked like this:

```
gap hist ms <16=19 16-23=20 24-31=10 32-39=24 40-55=6 56+=0     <-- FLAT = no pacing at all
```

Frames were landing at effectively random instants between 8 and 55 ms, so the compositor held
each one for anywhere between half a refresh and three. Three separate causes, all measured:

1. **`PumpFor` burned the tick.** It `g_usleep(1000)`s every iteration, and a 1 ms sleep really
   costs ~3 ms on this device, so `PumpFor(4)` measured **12 ms** of a 16 ms tick with the page
   IDLE. The tick was therefore WORK-bound at 26-28 ms rather than timer-bound at 16, and since
   a frame can only be published on a tick, every gap quantised to that. Fixed by `PumpReady()`,
   which drains what is ready and returns without sleeping — **work avg 12 ms → 1 ms idle**.
   `PumpFor` KEEPS its old behaviour because the tests use it as "let the engine run for N ms".
2. **Nothing paced the publish.** The damage gate was an 8 ms floor deliberately set BELOW the
   tick so it never gated. A fixed 33 ms deadline grid (not a floor — a floor drifts and beats,
   which is what the 2026-08 note in the source records) moved 30% → 69% of frames into the
   32-39 ms bucket.
3. **The daemon could not tell a NEW plugin frame from a repeat**, because its only signal is
   PuppetWidget's sticky dirty boolean, which the refresh driver and ordinary page damage also
   set. That ambiguity makes BOTH available policies wrong: publishing on every dirty tick sent
   ~78 card frames for ~60 plugin frames (duplicates, and `deferred` 22-44 because the adapter
   could not drain them), while the 33 ms grid sent ~57 for ~68 and DROPPED frames, so the
   animation stepped two positions at once. Fixed by exporting `jihad_plugin_frame_seq()` from
   `PluginInstanceParent::RecvShow` (weak-linked exactly like `jihad_offscreen_take_dirty`) and
   publishing one card frame per plugin frame: **done=91 against palm draw=92, `deferred=0`.**

**Why stock is structurally smoother, and it is not a tuning difference.** Stock has exactly ONE
clock: `PluginViewQt`/`PluginViewPalm` pulls the plugin synchronously inside the page paint, and
the producer blocks until the consumer drains, so publish times ARE drain times. We have two
free-running clocks — the plugin child's own repaint timer (a delayed task RE-POSTED after its
work, so its period drifts) and the daemon's tick — and we SAMPLE the plugin rather than pull it.
That is the remaining gap, and it is the next thing to attack.

**Two things were tried and are NOT settled — the runs that judged them were confounded:**
- **An 8 ms tick** (`JIHAD_TICK_MS=8`). Works mechanically: tick period 9-11 ms, 1:1 delivery,
  `deferred=0`. But the plugin then redrew ~45 times/s for 30 fps content, so content frames are
  shown 1 or 2 times in a beat — even DELIVERY of uneven CONTENT, the same artifact one layer up.
  Worth revisiting only together with a draw rate that matches the content.
- **`JIHAD_PLUGIN_REPAINT_DIV=3`** on top of it, to bring draws back to ~30. Draw rate did land
  at 28-34 fps, but the daemon then logged `flashRect remove id=N (gone)` and stopped painting
  while the child kept drawing.
  **That was NOT caused by the divisor, and the first write-up of it here was wrong.** The same
  stall persisted after reverting to `JIHAD_TICK_MS=16` and the default divisor, and a CLEAN
  restart (`stop jihad; pkill -f jihad-browserserver; pkill -f plugin-container; start jihad;
  killall LunaSysMgr`) cleared it completely on the identical build: `done=61 palm draw=63
  deferred=0`. What actually happened is a plugin CRASH LOOP — the log carries a
  plugin-container maps dump — reached by cycling `inject url` between pages repeatedly. Once the
  child is in that state the plugin rect goes away, widget invalidation stops with it, and every
  later number reads as a pacing regression that is not one.
  **NEW TRAP, same family as the two below: repeated inject-driven navigation can wedge the
  plugin, and the symptom is silence, not an error.** `flashRect remove id=N (gone)` with the
  child still logging `palm draw` is the signature. Do a clean restart before believing any
  frame measurement that follows one.

Everything here is env-tunable for A/B without a rebuild: `JIHAD_TICK_MS` (4-64, default 8 in
code / 16 on the device job), `JIHAD_PLUGIN_FRAME_MS` (0 disables the pacer and the seq gate with
it), `JIHAD_PLUGIN_REPAINT_DIV` (1-8, child side), and — added 2026-08-10 because the frame
question could not be A/B'd without them — the two DRIVER switches:

| var | side | effect |
|---|---|---|
| `JIHAD_PLUGIN_PULL=0` | daemon | disables the host request ONLY, leaving the publish policy alone. Use this, NOT `JIHAD_PLUGIN_FRAME_MS=0`, which also drops the publish gate to the 8 ms floor and so changes two things at once |
| `JIHAD_PLUGIN_SELF_DRIVE=0` | child | disables the child's own repaint timer outright |

**Setting only `JIHAD_PLUGIN_PULL=0` does NOT isolate the plugin** — the child's host-drive lease
expires and its timer takes over, so you measure patch `0026`, not Flash. Both switches together
leave the plugin's own `NPN_InvalidateRect` as the sole frame source. Each logs a line when it
engages (`plugin PULL disabled` / `self-drive timer DISABLED`); grep for it before believing a run.

**And when reading `show req:`, `hostinval` counts everything that reached
`JihadPalmRepaintTick` — the pull AND the child timer. It is not "the pull" on its own.**

### The PULL is built and measured (patch `0029`, 2026-08-10) — and it did NOT fix the pacing

`0029` does exactly what the item above asked for: an async parent→child `JihadRequestFrame`, the
child answering it with its existing `JihadPalmRepaintTick()`, its own timer standing down on a
150 ms LEASE (not a latch — the daemon can stop asking at any moment, and a latched plugin would
then never paint again), and the daemon asking once per whole-tick grid slot from its own tick.
It is live on all three variants. **The mechanism works and the outcome is not a win:**

|  | `0028` (sample) | `0029` (pull) |
|---|---|---|
| daemon done | 29.4-31.9 fps | 32.8-34.0 fps |
| frame gap avg | 31-34 ms | 29-30 ms |
| frame gap max | 47-62 ms | 45-55 ms |
| gap hist `<16` ms | 1-4 of ~60 | **5-8 of ~68** |
| `deferred` | 0 | 0 |

Average and max improve; the HISTOGRAM gets flatter, which is the metric that matters. Both runs
were clean restarts of `jihad-anim.swf` at `JIHAD_TICK_MS=16`, log-growth and card-connection
asserted. Why it does not work is open work item 2: **the pull is not exclusive** — 3988 draws
against 3072 requests — so a third driver is producing most of the frames.

Two things worth keeping from this even if `0029` is later reverted:

- **THE TICK IS ITSELF A JITTERY CLOCK, and that bounds every pacing scheme.** Against a 16 ms
  timer the measured period is `min=15 avg=18 max=41`, with `work avg=10-11` (pump 7, paint 3).
  Locking the plugin to that clock inherits its jitter, so "one clock" is necessary and not
  sufficient. **`JIHAD_TICK_MS=8` is WORSE, measured, and not for the reason recorded earlier:**
  the tick cannot actually run at 8 ms (work is 11-13 ms, so the observed period stays 14-16 ms),
  the draw rate rises to 36-40 fps for 30 fps content, and the histogram spreads across the 16-23
  and 24-31 buckets. Leave the device job at 16.
- **There is no clean runtime A/B for the pull alone.** `JIHAD_PLUGIN_FRAME_MS=0` does stop the
  requests (the child's lease expires and it resumes self-driving, i.e. `0026`/`0028` behaviour),
  but the same variable also drops the publish policy to the 8 ms floor, so the two effects cannot
  be separated without a rebuild. Do not read a `=0` run as "the pull, off".

## Open work, in priority order

1. **Keyboard arbitration, card side — blocked on the hardware, not on the code.** Keys reach and
   drive Flash; what is NOT verified is that the CARD does not also act on them. The gate is
   deployed (`handleKeyDown/Up` on `mPageFocused && (bEditorFocused || mFlashGestureLock)`) and
   its return value IS the arbitration, so the expression is not in doubt — what needs proving is
   that `mFlashGestureLock` is true during play.

   **A human at the device cannot test this either.** There is no keyboard: `/proc/bus/input/
   devices` has only `gpio-keys`, `pmic8058_pwrkey`, `headset`, and webOS's on-screen keyboard is
   drawn by LunaSysMgr in-process, not through `/dev/input`. The daemon's `key` inject command
   goes straight to the page and bypasses the adapter entirely, which is why it proved "Flash gets
   keys" and can never prove anything about the chrome.

   `render/goanna/test/uinput_kbd.c` synthesises a real one (PDK build → device glibc, no bundled
   loader; `build` it with the PDK gcc plus `--sysroot`). `/dev/input/uinput` exists and works,
   the device registers as `event3`, and **both `hidd` and LunaSysMgr open it** — yet no key ever
   reaches the daemon and `window.pageYOffset` never moves. So hidd reads it and does not dispatch
   it. Next: `/etc/hidd/HidPlugins.xml` routes generic devices through `HidInputDev`
   (`/usr/lib/libhidinputdev.so`, `/var/run/hidd/InputDevEventSocket`) — find out what it requires
   of a device before it forwards. Also fix the observable: arrows were used on the assumption the
   chrome scrolls, which a touch OS may not do at all; the adapter's own comment says the leak
   appeared as keystrokes landing in the ADDRESS BAR, so screenshot the URL field instead.
   `jihad-keyarb.html` (tall page + key SWF + `gettext #sy` scroll readout) is staged for this.
2. **Frame pacing: the pull is BUILT (patch `0029`) and it is NOT the fix. Find the third draw
   driver.** The pull described in the previous handoff now exists end to end and is device-live —
   see the section above for the numbers. It did not tighten the gap histogram, and the reason is
   a measurement nobody had taken before: **the plugin's draw rate is not set by whoever you think
   drives it.** Over 123 s the child logged **3988 draws against 3072 host requests**, and at an
   8 ms tick the gap widened to 3988-vs-~1900 territory (38 fps of draws for ~15 requests/s). So
   the majority of draws — and ALL of the excess — come from neither the child's own timer (it is
   provably stood down: exactly one `frame clock -> HOST` transition and no fall back for the
   whole run) nor from Flash self-invalidating (`gJihadNPNInvalidateRectCalls` stays 0, which is
   precisely why the host-driven path keeps running).
   **ANSWERED 2026-08-10, and the suspect this paragraph used to name was WRONG.** The counters
   were added (every `AsyncShowPluginFrame` call site, tagged, reported next to `palm draw` as
   `show req:`) and `RecvUpdateBackground` measured **exactly zero** — as did every other
   background path. The hypothesis that it was parent-driven and correlated with daemon paints is
   refuted; do not re-run it.
   **It was OUR OWN LEASE FLAPPING.** Every draw traces to `InvalidateRect`, and the accounting
   closes to the unit: **1856 host requests + 1846 child-timer invalidates = 3702 total**, with
   the child logging `HOST -> SELF -> HOST`. The daemon does not re-ask while a request is
   outstanding — it waits out `kJihadPluginReqTimeoutMs` (250 ms) — but the child's lease was
   150 ms, i.e. SHORTER, so one late frame dropped the lease and restarted the second clock. The
   invariant is now written into the source: **lease > request timeout + one grid period +
   margin** (lease 500 ms). Verified: the clock log now shows one `-> HOST` and no fallback.
   **AND THEN THE REAL ONE — PATCH `0026`'s FOUNDING PREMISE IS FALSE.** With the lease fixed,
   1344 host requests still did not account for 2662 invalidates. Splitting the counter at the
   funnel by whether `JihadPalmRepaintTick` is on the stack settles it:
   **`hostinval` ≈ 27/s against `plugininval` ≈ 22/s.** Flash invalidates itself constantly.
   The reason three sessions believed otherwise is that `gJihadNPNInvalidateRectCalls` — the
   counter `0026` reads to decide "the plugin never asks to be repainted" — is **structurally
   blind**: it lives in `JihadNPNInterpose.cpp` and only sees calls that bind the
   `NPN_InvalidateRect` SYMBOL, while an ordinary NPAPI plugin calls through the NPNetscapeFuncs
   table, which `PluginModuleChild` fills with its own `_invalidaterect` (`:986`) that forwards
   straight to `InstCast(aNPP)->InvalidateRect` (`:1302-1310`) and never touches the interpose.
   It can read 0 forever while the plugin invalidates 22 times a second.
   **So the pacing defect is TWO PRODUCERS BEATING**, ours and Flash's, funnelled into one
   coalescing path (~49 invalidates/s collapsing to ~32 draws/s). That is exactly the shape that
   produces an unconcentrated gap histogram at a healthy average.
   **NEXT EXPERIMENT, and it is cheap:** measure Flash with BOTH drivers off. `JIHAD_PLUGIN_FRAME_MS=0`
   alone is not enough — it stops the pull, the lease expires and the child's own timer takes
   over, which is just `0026` again. It needs one more child-side kill switch to disable the
   timer outright. If Flash alone holds the authored rate, the host clock should be deleted for
   plugins that self-invalidate rather than tuned.
   Measure with the gap histogram, NOT with average fps: the average was 35-42 fps throughout the
   whole period the animation looked worst, and `0029` IMPROVED the average and the max while
   making the histogram flatter.
3. **~~The partial-paint path publishes with no blank check~~ — STALE, resolved 2026-08-10.** R8's
   last criterion is `[x]`: the second pass decided NO blank check is needed. The geometry guards
   (segment-size check) catch the corruption class, and a partial paint only ever rewrites a sub-rect
   of a frame that already passed the full path's non-blank check, so it cannot publish a blank frame
   invisibly. Do not re-open. (Full reasoning: cavekit-offscreen-rendering.md R8, lines ~200-218.)
4. **`plugin-container` aborts on teardown.** Every navigation away from a Flash page ends in
   `mozalloc_abort` (pc 0xc35c in plugin-container's own text) — a deliberate Gecko abort, not a
   segfault. Harmless today (the child is going away) but it is noise in every log.
5. **The in-daemon plugin scan is a landmine.** `nsPluginFile::GetPluginInfo` dlopens EVERY
   plugin in the daemon ("Sadly we have to load the library for this to work"), pulling
   libWebKitLuna/libPiranha/libv8/libEGL into it, and `dlclose` does not unload them. A hostile
   plugin can wedge the daemon before any plugin logging runs.

---

## Traps — every one cost real time and none is discoverable from the source

**Device / measurement**
- **AVERAGE FRAME RATE CANNOT SEE THE DEFECT THE USER IS REPORTING.** Throughout the entire
  period the animation looked worst by eye, the daemon reported 35-42 fps for a 30 fps source —
  ABOVE the content rate. min/avg/max cannot separate "evenly late" from "unevenly on time"
  either. Read the `gap hist ms` bucket line: flat across the buckets means no pacing, weight in
  one bucket means smooth. Every earlier session's frame-rate conclusions were drawn from summary
  statistics and are worth re-reading with that in mind.
- **THE PLUGIN'S DRAW RATE IS NOT SET BY WHOEVER YOU THINK DRIVES IT — count, do not reason.**
  Three sessions have now attributed the draw rate to a specific clock (the child's timer, then
  the daemon's tick, then the host pull) and every attribution was made from reading the code, not
  from a count. When `0029` finally put a counter on the request side the numbers did not agree
  with ANY of them: 3988 draws against 3072 requests, with the child's own timer provably stood
  down and Flash provably not self-invalidating. Whenever you change what drives a frame, log both
  ends and divide. The ratio is the finding; the fps number cannot express it.
  **And the follow-up is the sharper lesson: "provably stood down" was itself an inference, and it
  was wrong.** The child's timer was gated on a lease, one `frame clock -> HOST` line was taken as
  proof the gate held, and nobody checked for a LATER transition. There were three. Tagging every
  call site closed the accounting to the unit — 1856 host + 1846 timer = 3702 — and the answer was
  a bug in the gate, not a third party. A transition log only proves what it logged; grep for
  ALL of them, and make counters that must SUM to something you already measure.
- **A WEDGED PLUGIN LOOKS EXACTLY LIKE A PACING REGRESSION.** Cycling `inject url` between pages
  repeatedly can leave the child in a crash loop; the daemon then logs `flashRect remove id=N
  (gone)`, painting stops entirely, and the child keeps logging `palm draw` the whole time so the
  plugin looks alive. This produced a confident, WRONG attribution to a tick-rate change on
  2026-08-10 — the identical build measured healthy after a clean restart. Before believing any
  frame number that follows repeated navigation: `stop jihad; pkill -f jihad-browserserver;
  pkill -f plugin-container; start jihad; killall LunaSysMgr`.
- **AN EMPTY LOG PASSES EVERY CHECK.** `grep -c 'inject: no page' $LOG` returns 0 on a log that
  is empty because the daemon wrote NOTHING, which reads as "card fine" and is the opposite of
  the truth. This produced two clean-looking but entirely void runs on 2026-08-10. Assert the log
  GREW (`wc -c`) before believing any grep over it — a zero-byte log means the run never
  happened, not that it went well. Same class as the "card connected" trap below, one level down.
- **NEVER write `/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor`.** Switching away from
  Palm's `ondemandtcl` deadlocks the cpufreq policy lock in the kernel; every later reader of any
  cpufreq node blocks in unkillable **D state** — the daemon, `powerlog`, and your own restore
  script, so the governor is never put back and the daemon stops painting. Only a reboot clears
  it, and **a clean `reboot` will NOT run**, because init waits on those D-state tasks: it takes
  `sync; sync; reboot -f`. The governor's own TUNABLES (`cpufreq/ondemandtcl/*`) are safe to
  write and return instantly — that is what patch `0027` uses. Cost a device reboot 2026-08-10.
- **Regenerating `/etc/event.d/<job>` from `packaging/gen-variant-scripts.sh` and pushing it
  verbatim KILLS THE INJECT CHANNEL.** The shipping template does not set `JIHAD_INJECT=1`; the
  device's copy carries it as a local addition. Lose it and every inject silently does nothing,
  the daemon logs nothing, and — see the first trap — every subsequent check "passes". Re-add
  `JIHAD_INJECT=1` to the `exec env` line whenever you reinstall the job, and remember the running
  daemon keeps its OLD environment until you `stop`/`start` it.
- **ASSERT THE CARD IS CONNECTED before believing any measurement.** If it disconnected, the
  daemon logs `inject: no page` and every downstream number — container present? draw count?
  thread count? — reads as a dramatic failure that is really "no page". This invalidated three
  of my own measurements and twice produced a wrong "audio kills the plugin" conclusion. Inject
  a known page and grep for `inject: no page` first.
- `novacom run` drops output arriving after host stdin hits EOF — pipe `sleep N |` into every
  run whose reply matters.
- `novacom run file://bin/sh -- -c '…'` silently drops the `-c` string. Stage a script with
  `novacom put` and run that.
- There is **no `timeout` binary** on the device. Background the process and `kill` it.
- `strace` DOES exist (`/usr/bin/strace`) and settled two problems in one run each.
- A screenshot captures the FOREGROUND card. The double-launch dance creates a second card, so a
  screenshot can silently be of the wrong one.
- The first card launch after `killall LunaSysMgr` does not navigate — launch twice, or use the
  inject channel (`JIHAD_INJECT=1`, `<state>/inject.cmd`), which is better.
- `/tmp` is cleared by a reboot; `/etc` comes back read-only (`mount -o remount,rw /`).

- **NEVER regenerate the YAP interface from `../ref-BrowserServer/CodeGen` — it would break every
  keystroke.** Established 2026-08-10 by building `YapCodeGen.cpp` against Qt 5.15 and RUNNING it,
  not by reading. The upstream `.defs` is stale against its **own** upstream output: it declares
  `KeyDown`/`KeyUp` (0x1008/0x1009) as two `uint16_t`, while both upstream's generated
  `BrowserServerBase.cpp` and ours read a third `int32 chr` — upstream hand-edited its generated
  file and never updated the `.defs` (the tell is the six-space indent on those lines inside a
  tab-indented generated file). Regenerating from it silently rewrites two LIVE commands from 12
  wire bytes to 4. Note this is a bigger break than the missing 0x1600, and the obvious fix —
  "just add our command to the upstream `.defs`" — would have shipped it.
  **Use the corrected in-tree copy: `render/browserserver/CodeGen/BrowserYapCommandMessages.defs`.**
  `build/webos-oe/check-yap-contract.sh` now runs inside `build-daemon-arm.sh` and fails the build
  on any drift (verified three ways: passes here, fails with 10 named defects on a real upstream
  regeneration, fails with exactly one on a regeneration from the corrected `.defs` — that one
  being the hand edit no `.defs` can express, since the generator emits every async command as
  `= 0;` and 0x1600 needs an empty default body to stay optional).
  **TRAP INSIDE THE TRAP:** a `.defs` line beginning with a SPACE hangs `YapCodeGen` forever —
  `ignoreLine()` scans for a non-space without advancing its pointer.

**Cross-ABI (bundled glibc 2.23 vs device glibc 2.8)** — see cavekit-device-build.md **R9**
- glibc 2.21 changed `sem_t`'s value word to `(tokens << 1) | has-waiters`. A named semaphore
  created by a 2.8 process reads to us as "0 tokens, waiters pending" and blocks FOREVER. This
  took Flash out entirely after one reboot and looked exactly like a code regression on
  untouched binaries — **it is a per-boot race, not a bug in your change.** Contained for
  `/PmLogLib` by `render/goanna/JihadPmLogSem.c` (patch 0025).
- `sem.browserserver.*` are created by the ADAPTER and nothing ever waits on them. The trap is
  ARMED, not sprung: adding a daemon-side `sem_wait` springs it, and `nwaiters` sits at a
  different offset too (8 in the 2.8 family, 12 in 2.23 — measured). Use SysV `semop` (a kernel
  object, no userspace layout) if a blocking handshake is ever needed. It does NOT fire on an
  EMPTY semaphore (raw 0 and `0 << 1 | 0` are the same word), so a first `sem_wait` would look
  fine right up until the adapter posts.
- **THIS WHOLE CLASS IS HOST-TESTABLE — stop spending device sessions on it.** Both toolchains are
  in the tree and `qemu-arm` runs their output on the build host: static-link one probe with the
  PDK gcc (sysroot glibc 2.5, the pre-2.21 side) and one with the crosstool gcc (2.23), run both,
  and the DIFFERENCE is the ABI. The `sem_t` hang above reproduces this way in about a minute.
  The PDK sysroot is 2.5 and the device is 2.8, so it is a pre-2.21 PROXY, not the device.
- **`pthread_mutex_t` PROCESS_SHARED is a SECOND armed trap, and the layouts being IDENTICAL is
  what makes it dangerous.** 24 bytes and the same fields in both, so every size and marker check
  passes — but glibc 2.23 sets `__kind = 128` (PTHREAD_MUTEX_PSHARED_BIT) and takes the futex
  private/shared flag from that bit, while the pre-2.21 side writes `__kind = 0` and returns
  EINVAL on a mutex whose `__kind` is 128. So one direction hangs under CONTENTION ONLY, and the
  other turns every `lock()` into a silent no-op. `ProcessMutex` is adapter-only and instantiated
  by nothing today; see cavekit-device-build.md R9 and the comment in `ProcessMutex.cpp`.
- `pthread_cond_t` still matches (48 bytes, same fields) — but **2.23 is the LAST glibc where that
  is true**; the condvar was rewritten in 2.25, and 2.24/2.25 tarballs are already in the
  toolchain source dir. `pthread_rwlock_t` ALREADY differs at 2.23 (same size, `__flags` narrowed
  and a new `__shared` byte added), which is the standing proof that `sizeof` does not clear a
  struct.
- The framebuffer header IS clean: `BrowserOffscreenInfo` is 32 bytes with identical offsets under
  both toolchains (plain int/double, so AAPCS fixes it and libc has no say). Do not re-check it.
- Prove each device library with a standalone probe run under BOTH loaders — the difference IS
  the diagnosis. See `plugin_mime_probe.c` and `alsa_probe.c`.

**Reverse-engineering libflashplayer.so**
- The code is **ARM, not Thumb**.
- String addresses are PIC: `add rX, r5, <negative literal>` with a base near 0x8ad010. Searching
  for an absolute address AND for `movw`/`movt` immediates both find ZERO references. Read the
  literal pool and add the base.
- Take PLT stub addresses from `objdump -d --section=.plt`, which labels them. A hand-rolled
  decode gave a wrong stub and made a BL scan report no callers.
- A function's entry can be one instruction BEFORE the `push` (the PIC `ldr rX,[pc,…]` comes
  first). Being off by 4 made a caller scan report zero callers and nearly sent the audio hunt
  down a "it must be a vtable" dead end.

**Build / deploy**
- **archive.debian.org's CDN serves cached 404s for files the pool lists.** 32 of the 187 pinned
  `.deb`s failed on a clean clone though every one is there; the same URL with a query string, or a
  later try, works. `--check-urls` used to probe five and pass. The fetchers now try five times with
  a cache-buster (`9ff7d71a`); sha256 still decides.
- **A PC reboot kills every background job of a session, and its wormhole-rs sends with them.** A
  wormhole code is one-use and lives in the sender process: after a reboot, resend and hand over the
  new code. The old session's subagent transcripts survive in
  `~/.claude/projects/<project>/<session-id>/subagents/agent-*.jsonl` (one that stops short has no
  verdict: run it again). A detached build (`setsid nohup … &`) survives a session, not a reboot;
  `mach build` resumes from its object directory.
- `push-engine-update.sh` pushes libxul + daemon + goanna.js. It does **NOT** push
  `plugin-container` or the adapter — **nor the loose JS components.**
  `components/jihadInstallPrompt.js` and `components/jihadAboutPreferences.js` live in each
  variant's `deviceroot/hl/components/` and are refreshed only by a bundle/`.ipk` push, or by
  pushing the one file per variant (which is what was done 2026-08-10 for the R3 install-failure
  observer). Editing one and running `push-engine-update.sh` ships nothing.
- **The variant app ids on device use a HYPHEN, not a dot: `net.riverstonerelay.jihad-browser-mochi`
  and `…-mojo`.** `CLAUDE.md` writes the Mochi id with a dot and is WRONG against the device.
  Pushing to the dotted path fails with `bad or error response from other side: 'file open failed'`,
  and the `ls` that follows reads as "this variant does not ship that file" — I briefly concluded
  mochi and mojo had no `components/` directory at all before checking the parent directory.
  Confirm a path against `ls /media/cryptofs/apps/usr/palm/applications/` before believing an absence.
- The `.ipk` ships the **PDK** adapter (`build-adapter-pdk.sh` → `adapter-deps/build-pdk/`), NOT
  the crosstool one (`build-adapter-arm.sh` → `adapter-deps/build/`). Rebuilding only the latter
  ships an old adapter in the package while the device runs the new one.
- The adapter runs INSIDE LunaSysMgr. Deploy it by swapping
  `/usr/lib/jihad/<variant>/BrowserAdapterImpl.so` + `/usr/lib/BrowserPlugins/BrowserAdapterJihad*.so`
  (needs `mount -o remount,rw /`), then restart LunaSysMgr. Back up first —
  `/var/palm/jihad/adapter-backup/` holds the pre-2026-08-10 pair.
- A hand-launched daemon survives `stop jihad` and serves a stale libxul. "Nothing changed" is a
  lie until you `pkill -f jihad-browserserver`.
- `cp` onto a mapped binary fails with "Bad file descriptor" on cryptofs — stop the daemon and
  `rm -f` first, or push to `.new` and `mv`.

---

## Build / deploy loop

```bash
# libxul (incremental ~45 s) and the daemon
podman run --rm --userns=keep-id \
  -v "$PWD/third_party/uxp:/src/uxp" -v "$PWD:/jihad" \
  -v "$PWD/build/webos-oe/toolchain/out-toolchain/x-tools/arm-webos-linux-gnueabi:/tc" \
  -v "$PWD/build/webos-oe/arm-sysroot/root:/sysroot" \
  -v "$PWD/build/desktop:/cfg" -v "$PWD/build/webos-oe:/armcfg" \
  -v "$PWD/build/webos-oe/out-arm:/out" \
  localhost/jihad-goanna-build bash /armcfg/build-goanna-arm.sh build   # or build-daemon-arm.sh

build/webos-oe/push-engine-update.sh enyo mochi mojo   # md5-verified

bash build/webos-oe/build-adapter-arm.sh    # adapter for a live swap
bash build/webos-oe/build-adapter-pdk.sh    # adapter the .ipk ships  <-- do both
bash build/webos-oe/build-variant-ipk.sh    # all three .ipks

bash build/webos-oe/build-test-plugin-arm.sh   # NPAPI control plugin
bash build/webos-oe/build-uinput-kbd.sh        # synthetic keyboard (PDK; needs --sysroot)
```

**Only `enyo` has libxul with patch `0027`.** `push-engine-update.sh enyo mochi mojo` pushes the
SAME libxul to all three, so just run it with all three variants next time you push and they are
back in step. Until then, a frame-rate measurement taken on mochi or mojo will show the OLD,
governor-limited numbers and look like a regression that is not one.

Clean device run:

```sh
stop jihad; sleep 2; pkill -f jihad-browserserver; pkill -f plugin-container; sleep 2
: > /var/palm/jihad/enyo/daemon.log
start jihad; sleep 3
killall LunaSysMgr; sleep 32
luna-send -n 1 palm://com.palm.applicationManager/launch \
  '{"id":"net.riverstonerelay.jihad-browser","params":{"target":"file:///tmp/jihad-plain.html"}}'
# then drive it with the inject channel:
echo 'url file:///tmp/jihad-anim.html' > /var/palm/jihad/enyo/inject.cmd
```

Read the `paint pipeline:` / `frame gap ms min/avg/max` counter pair for frame-rate work — the
gap SPREAD is what reads as stutter, not the average.

### Inject commands, and the two added 2026-08-10

`url`, `text`, `find`, `rect`, `gettext`, `clickid`, `dblclickid`, `clickoff`, `touch`, `cookie`,
`addon`, `spotlight`, `freeze`, `thaw`, `popups`, `jsurl`, and now:

| command | what it is for |
|---|---|
| `setpref <b\|i\|s> <name> <value>` | write a pref, with an immediate read-back on the same log line |
| `getpref <b\|i\|s> <name>` | read one back — after a restart, which is the half that proves persistence |
| `anon <selector>` | the element's NATIVE ANONYMOUS CONTENT: did an XBL binding actually attach. `?` = no such element, `0` = element exists and bound NOTHING (the real negative), otherwise a count plus the first few node names and `anonid`s |

**Both were added because their absence had already cost device runs, and both replace a probe
route that DOES NOT WORK — do not go back to it.** `jsurl` executes with the system PRINCIPAL but
in a CONTENT scope, so `Components` is not exposed: a `Components.classes[…preferences-service…]`
probe returns success and silently does nothing, which reads as a negative result about the thing
under test rather than a broken probe. Likewise `document.getAnonymousNodes` throws
`not a function` there regardless of privilege. Both questions have to be answered in the daemon,
which is in-process with libxul and already holds `nsIPrefBranch` and `nsIDOMDocumentXBL`.

---

## Test assets (`render/goanna/test/`)

| asset | what it answers |
|---|---|
| `make-anim-swf.py` → `jihad-anim.swf` | does content MOVE (x-centroid = frame number) |
| `make-audio-swf.py` → `jihad-audio*.swf` | audio; PCM by default, `--mp3`, `--stereo` |
| `make-key-swf.py` → `jihad-key.swf` | real AVM1: GREEN until a key is handled, then RED |
| `alsa_probe.c` | can THIS runtime play sound (run under both loaders) |
| `plugin_mime_probe.c` | reproduce the daemon's plugin scan standalone |
| `audio_shim.c` | LD_PRELOAD: trace dlopen/dlsym, substitute `snd_pcm_open` |
| `npapi_test_plugin.c` | control plugin — proves defects are OURS, not Flash's |
| `uinput_kbd.c` | synthesises a HARDWARE keyboard (this device has none) for chrome-side key tests |
| `abi_probe.c`, `sem_dump.c`, `mtx_dump.c` | **cross-ABI, and they need NO DEVICE.** Build each with both in-tree toolchains (PDK gcc 4.3.3 / glibc 2.5 and the crosstool 9.4 / glibc 2.23), run both under `qemu-arm`, and the diff IS the ABI. Reproduced the PmLogLib `sem_t` hang on the build host in about a minute. See the cross-ABI section at the end of this file for the 2.5-is-a-proxy caveat |

Pages/assets staged in `/tmp` on the device (volatile — re-push after any reboot). The HTML
wrappers are trivial and are NOT in the repo; regenerate them as a `<embed
type="application/x-shockwave-flash" src="<swf>" wmode="opaque" width="320" height="240">`:

| on-device page | asset | what it is for |
|---|---|---|
| `jihad-plain.html` | none | the SWF-FREE page. Navigate here first when you need a plugin-container to spawn FRESH on the next navigate, and to release the `0027` CPU boost |
| `jihad-anim.html` | `jihad-anim.swf` | frame-rate work |
| `jihad-audio.html` | `jihad-audio.swf` | PCM square — the only asset confirmed CLEAN by ear |
| `jihad-audio-mp3.html` / `-44k.html` | mono 22 k / stereo 44.1 k MP3 | MP3 decode path |
| `jihad-audio-5s.html` | `jihad-audio-5s.swf` | 5 s sine MP3. LOOPED, so it clicks once per iteration by design — that is Flash restarting its decoder, not a defect |
| `jihad-audio-long.html` | `jihad-audio-long.swf` | **30 s single-shot MP3 (`--loops 1`). The ONLY asset that can answer a question about audio QUALITY**, because it has no loop point at all. Every other MP3 asset here clicks per iteration no matter how healthy the port is |
| `jihad-keyarb.html` | `jihad-key.swf` + 3000 px scroll region + `#sy` readout | keyboard arbitration: read scroll back with `gettext #sy` |
| `jihad-media.html` | `jt.webm` (VP8) + `jt.mp3` | **ENGINE media, nothing to do with Flash.** Reports `canPlayType`/`readyState`/`currentTime`/`error` into `#r`; read it back with `gettext #r`. Measured 2026-08-10: **VP8 plays**, H.264 unsupported, **MP3 refused outright** (`error.code=4`) because the ARM build compiles cubeb with NO backend. Regenerate the two media files with `ffmpeg -f lavfi -i sine=…` and `-f lavfi -i testsrc=… -c:v libvpx` |

SWF authoring traps — **every one of these has already produced a false negative in this tree,
and a bad asset is indistinguishable from a broken port:**
- **Shapes and sounds share ONE character dictionary.** `DefineSound` may not reuse a
  `DefineShape` ID. The player keeps the first definition and drops the second, `StartSound`
  resolves to the wrong character, and the sound is silently never played. This cost a whole
  session chasing a nonexistent player-side audio gate. Fixed 2026-08-10 (`SOUND_ID = 2`).
- `0x00020000` is ClipEvent**KeyPress** (and carries a trailing KeyCode byte) — KeyDown is
  `0x00000040`; getting it wrong makes the SWF draw NOTHING rather than ignore keys.
- A sprite with no `Stop` on frame 1 loops, which looks exactly like a key response and is not.
- For MP3 event sounds the SoundData begins with a **SeekSamples SI16**, not the frame stream.

Parse an asset back out before believing a negative result from it. A 30-line tag walk that
prints each tag code and character ID is enough, and it is what caught the ID collision.

---

## Device state as left

- **2026-10-14 (round 25):** all three variants on daemon `06e75a68` with the round-25 impls
  (`1bafcc0c` enyo, `4b8c44ba` mochi, `a5c205d1` mojo; no home path), shims unchanged, no test
  hooks, no proxy, `/` read-only. Each was launched once on https://example.com/ and closed.
- **2026-08-10, later session:** the enyo daemon and libxul now also carry the frame-pacing work
  (`PumpReady`, the 1:1 seq gate, patch `0028`, the tick/gap counters). `/etc/event.d/jihad`
  carries `JIHAD_TICK_MS=16` and `JIHAD_PLUGIN_FRAME_MS=33` as device-local additions ALONGSIDE
  `JIHAD_INJECT=1` — all three are lost if the job is regenerated from the template. The device
  was last left on a CLEAN restart running `/tmp/jihad-anim.html`, measured healthy: `done=61
  palm draw=63 deferred=0`, gap mode 32-39 ms.
- **2026-08-10, pull session: ALL THREE VARIANTS ARE IN STEP** and were re-pushed together at the
  end of the session, so every one carries the same libxul and daemon with patches `0027`, `0028`
  AND `0029`. The previous enyo-ahead-of-mochi/mojo skew is gone, so a frame measurement on any
  variant is now comparable. (Read the current md5s off the device rather than trusting a number
  written here — this file has carried a stale one before. `push-engine-update.sh` prints them.)
- **The libxul on the device carries the pacing INSTRUMENTATION as well as the fix**, and it is
  what makes the open question answerable: the child logs `show req: setwin=… hostinval=…
  plugininval=… retry=… bgupd=… bgtail=… bgdestroy=…` next to `palm draw`, on the same 2 s
  boundary. `hostinval` is our pull, `plugininval` is the plugin invalidating itself. Those two
  counters are the whole of open work item 2 — read them before changing anything about pacing.
  Adapter is unchanged — still the PDK build matching the `.ipk` (md5
  `0410a348042af58a7e711b495db69833`).
- **THE DEVICE IS DELIBERATELY LEFT IN THE "FLASH ALONE" CONFIGURATION — this is not an accident
  and it is not the shipping default.** `/etc/event.d/jihad` carries `JIHAD_PLUGIN_PULL=0` and
  `JIHAD_PLUGIN_SELF_DRIVE=0`, so BOTH host frame drivers are off and the plugin's own
  `NPN_InvalidateRect` is the only frame source (verified: `hostinval` is exactly 0).
  **It is left this way so a human can LOOK at it**, because the eye is the only instrument that
  has ever detected this defect: Flash alone measures SLOWER (24-27 vs 30-33 fps) but perfectly
  unbunched (**zero** gaps under 16 ms, against 1-5 with the pull on). If evenly-spaced 25 fps
  reads better than bunched 32 fps, the host frame clock should be deleted — see the R7 frame-rate
  criterion for the full three-way table and the recommendation.
  **Revert to the shipped default in one line** (then `stop jihad; start jihad`):
  ```sh
  mount -o remount,rw / && sed -i 's/ JIHAD_PLUGIN_PULL=0 JIHAD_PLUGIN_SELF_DRIVE=0//' /etc/event.d/jihad
  ```
- `/etc/event.d/jihad` is back at **`JIHAD_TICK_MS=16`**. It was moved to 8 for one A/B during this
  session and moved back; 8 measured WORSE (see the pull section). The edit was a `sed` on that one
  token, never a regeneration from the template, so `JIHAD_INJECT=1` survived — verified after each
  edit. If you A/B it again, do it the same way and re-check `JIHAD_INJECT=1` afterwards.
- `/etc/event.d/jihad` is the normal job (`JIHAD_INJECT=1`, no `LD_PRELOAD`, no kill switches) and
  now also carries the `post-stop` governor restore. **TRAP: the SHIPPING template in
  `packaging/gen-variant-scripts.sh` does NOT set `JIHAD_INJECT=1` — that is a device-local
  addition.** Regenerating the job and pushing it verbatim silently kills the inject channel, and
  every subsequent test then "passes" against an empty log. Re-add it when you reinstall the job.
- db8 kind `com.palm.app.flashplayer.prefs:1` registered (owner `com.palm.flashgraphics`) — this
  is a deliberate addition that fixes Flash's only reported error. Remove with `delKind` if
  unwanted.
- `/var/palm/jihad/adapter-backup/` holds the pre-2026-08-10 adapter pair.
- Flash's `oem.cfg` was temporarily modified and has been RESTORED to original.
- **The device was REBOOTED on 2026-08-10** (forced: `sync; sync; reboot -f`, because a clean
  `reboot` hangs on D-state tasks — see the cpufreq trap). It came back healthy on `ondemandtcl`
  and all three daemons auto-started. Governor tunables are at STOCK (`up_threshold=95`,
  `sampling_rate=200000`); the daemon takes them to 40/50000 only while a plugin is instantiated.
- Test pages/SWFs re-pushed to `/tmp` after that reboot and ALL CURRENT — `jihad-anim`,
  `jihad-audio`, `jihad-audio-mp3`, `jihad-audio-44k`, `jihad-audio-5s`, `jihad-audio-sine`,
  `jihad-key`, plus `jihad-plain.html` and `jihad-keyarb.html`. `/tmp` is volatile: re-push after
  any reboot (see the Test assets table for what each one is for).
- The synthetic keyboard is NOT running — it was destroyed (`echo quit > /tmp/uinput.cmd`) and the
  process is gone. `/tmp/uinput_kbd` may or may not still be there; rebuild with
  `build/webos-oe/build-uinput-kbd.sh`.
- `libflashplayer.so` in the enyo variant's `profile/plugins/` is **stock**, md5
  `14c20ba9fc2183a93648c70488e0ec8e`, byte-identical to
  `/media/cryptofs/apps/usr/lib/BrowserServerPlugins/libflashplayer.so`, which is the restore
  source. Two patched builds were run there during the audio hunt and both have been removed.

---

## Uncommitted work in the tree (2026-08-10)

Nothing is committed. What this session added, and why, so it is not mistaken for cruft:

| path | what it is |
|---|---|
| `build/desktop/patches/0027-npapi-plugin-cpu-boost.patch` | **the frame-rate fix.** Holds a CPU-governor boost for the life of a plugin instance. Applied to `third_party/uxp` already, and the enyo device libxul is built from it |
| `packaging/gen-variant-scripts.sh` | adds the `post-stop` governor restore to the upstart template, so a crashed daemon cannot strand the tuning |
| `render/goanna/test/uinput_kbd.c` + `build/webos-oe/build-uinput-kbd.sh` | the synthetic hardware keyboard, for the open keyboard-arbitration criterion |
| `render/goanna/test/make-audio-swf.py` | two real asset bugs fixed: duplicate character ID, and `SeekSamples` 0 → 1105 |
| `render/goanna/test/audio_shim.c` | header rewritten — its old "measured" conclusion was wrong |
| `docs/PICKUP.md`, `context/kits/cavekit-addons-extensions.md` | this handoff and R7 |
| `build/desktop/patches/0028-npapi-plugin-frame-seq.patch` | **the 1:1 frame fix.** Exports `jihad_plugin_frame_seq()` from `PluginInstanceParent::RecvShow` so the daemon can tell a NEW plugin frame from a repeat. Applied to `third_party/uxp` already; the enyo device libxul is built from it. Dry-run verified against a reconstructed pristine copy, since several other patches also touch that file |
| `render/goanna/GoannaRenderPage.{h,cpp}` | `PumpReady()` (drain-and-return, the tick's pump) beside `PumpFor()` (spend-the-budget, what the tests need); weak `jihad_plugin_frame_seq` binding + `PluginFrameSeq()` |
| `render/goanna/BrowserPageGoanna.{h,cpp}` | the publish policy: 1:1 on the frame seq with a stale-damage fallback, the deadline pacer as the no-seq fallback, and the frame-gap HISTOGRAM that made the defect visible at all |
| `render/browserserver/JihadBrowserServer.cpp` | tick cadence counters (period vs work, split pump/paint) on a monotonic clock; the tick pumps with `drainOnly` |
| `render/browserserver/Main.cpp` | tick period is `JIHAD_TICK_MS` (4-64), so cadence can be A/B'd without a rebuild |
| `render/goanna/test/dump-swf.py` | walks a SWF back out and FAILS it on the three asset bugs that have each impersonated a port defect here (duplicate character ID, SeekSamples, SyncNoMultiple retrigger) |
| `render/goanna/test/make-audio-assets.sh` | regenerates every audio asset from scratch and verifies each one. The MP3 streams behind the checked-in SWFs previously existed only in `/tmp`, so the repo could not reproduce its own test assets |
| `build/webos-oe/stage-test-pages.sh` | pushes the SWFs + generates the HTML wrappers into the device `/tmp`, md5-verified. Replaces hand-making them after every reboot |
| `README.md`, `docs/*.md` | **de-duplicated against the kits** (user instruction 2026-08-10). The kits own requirements and per-criterion STATUS; docs own procedure. 233 lines of restated status removed, and with them three claims that had already gone stale and wrong: "Flash audio does not work", DEVICE-BUILD's "no device sysroot, no OE tree … and no TouchPad", and TOOLCHAIN's three-way toolchain choice presented as still open. README is now user-facing and positions against isis and Atlas |
| `context/plans/build-site.md` + `plan-overview.md` | regenerated from the kits: **56 tasks, 6 tiers, covering the 41 still-open criteria at 100%**, with the 8 hardware/human-gated ones quarantined in a final tier. The 2026-06-30 site is kept as `build-site-2026-06-30.archived.md` |
| `build/desktop/patches/0029-npapi-plugin-pull-frame.patch` | **the PULL.** New async parent→child `JihadRequestFrame`; the child answers with `JihadPalmRepaintTick()` and stands its own timer down on a 150 ms lease, logging every transition; `PluginInstanceParent` exports `jihad_plugin_request_frame()` over a file-static live-instance list. Applied to `third_party/uxp` already and live on all three variants. **Its own header records that it does NOT fix the pacing and why** — read it before building on it. Verified by reconstructing the pre-0029 baseline (reverse-applying only this session's edits), dry-running the patch onto it, and confirming it reproduces the working tree byte-for-byte |
| `render/goanna/BrowserPageGoanna.{h,cpp}` (pull) | `requestNextPluginFrame()`: the whole-tick request grid, the one-outstanding backpressure gate with a 250 ms timeout, and `jihadTickPeriodMs()` — the single definition of the tick period, which `Main.cpp` now calls instead of reading the env itself. Deliberately NOT gated on `mEmittedFlashRects`: that map is what EMPTIES when the plugin wedges, so gating there turns a recoverable wedge into a permanent one |
| `render/browserserver/JihadBrowserServer.cpp` (pull) | calls `requestNextPluginFrame()` once per tick — NOT from `maybePaint()`, which `returnBuffer()` also reaches off-tick, which would put requests off the grid they exist to stay on |
| `build/desktop/patches/make-0029.sh` + `.baseline-pre-0029/` | **the fix for the patch-authoring trap this file has warned about three times.** Reconstructs the correct baseline — `git show HEAD:` plus every EARLIER patch that touches the same four files (`0008 0017 0020 0022 0024 0026 0028`) — and diffs the live tree against it, so a new patch cannot silently fold in its predecessors or come out empty. `--rebuild-baseline` regenerates the dir. Generalise it before authoring `0030`; the file list and the `EARLIER` list are the only per-patch parts |

`third_party/uxp/dom/plugins/ipc/PluginModuleParent.cpp` is modified in place (that is how patches
work here — the build applies them to the shared tree, idempotently, with a dry-run gate). If you
regenerate `0027`, diff against a pristine copy of that file, not against the working tree.

---

## If you are picking this up cold, do this first

1. Read the Flash status table above, then the two open items at the top of **Open work**.
2. `novacom -l` — confirm `topaz-linux`. Re-push `/tmp` assets if the device rebooted.
3. The cheapest real progress available is **counting the third draw driver** (open work item 2):
   two 2 s counters, one on `PluginInstanceParent::SendUpdateBackground` and one on each
   `AsyncShowPluginFrame` call site, then one clean-restart run. Every pacing conclusion in this
   document rests on not knowing that number.
   **Audio is CLOSED — do not start there.** An earlier revision of this list sent you to an
   "MP3 static" question that the audio section above had already resolved at parity with stock;
   the contradiction cost a session start. If two parts of this file disagree, the dated
   subsection wins over this list.
4. Keyboard arbitration is NOT blocked on the browser — it is blocked on getting a key out of
   `hidd` into the card. Start at `/usr/lib/libhidinputdev.so`, not at the adapter.
5. Whatever you measure: assert the daemon log GREW, and assert the card is connected, BEFORE
   believing any number. Both failure modes look exactly like success.

---

## The cross-ABI class is now HOST-TESTABLE — do not wait for the device (2026-08-10)

`render/goanna/test/{abi_probe,sem_dump,mtx_dump}.c`, promoted out of a scratch dir because this
is the single most reusable thing found this session. Both toolchains are already in the tree and
`qemu-arm` runs their output on the build host:

- `build/webos-oe/pdk/opt/PalmPDK/arm-gcc` — gcc 4.3.3, sysroot glibc **2.5**
- `build/webos-oe/toolchain/.../arm-webos-linux-gnueabi` — gcc 9.4, glibc **2.23**

Static-link the same probe with each, run both under `qemu-arm`, and **the diff IS the ABI.**
This reproduced the PmLogLib `sem_t` hang off-device in about a minute — a bug that previously
cost a device session to find.

**CAVEAT, stated because it matters: the PDK sysroot is glibc 2.5 and the device is 2.8.** Both
are pre-2.21, so it is the right side of every cliff that matters here, but 2.5 is a PROXY and a
result that hinges on 2.5-vs-2.8 rather than pre-vs-post-2.21 is not proven by this method.