[ymote]

What

Bumps apps/appcard's octos-app pin 4f1ac61 → 78a1a8d (Octoscript-AppCard#92). The branch is based on fix/hosted-appcard-mobile (#24), so it keeps that fix. The only changes are apps/appcard/Cargo.toml and Cargo.lock. No kernel change: the bundled liboctos.so stays at octos deb433e9.

Why

When the kernel ran on DeepSeek V4 Flash (a thinking model, ~200 deltas/s), the hosted AppCard showed its weather card as a code block cut off mid-line. The kernel drops ephemeral message/delta frames when its stdio writer is backed up. The direct-sent turn/completed then overtakes the durable assistant_persisted row, so the app finalized on 897 of 1840 deltas (3251 of 7194 chars), an unclosed ```runl0 fence. 78a1a8d holds a turn at its terminal until that durable row arrives, either on the live lane or through session/hydrate, with an 8 s fallback. It also makes the L0 fence scanner line-based. Root-cause details are in #92.

Device evidence (OnePlus bf0a4730, this build, profile _main → DeepSeek V4 Flash direct)

request	hold logged	streamed chars	content_chars	kernel ledger assistant_final	L0 card accepted
tokyo weather	yes, 18:03:25.497	3981	6662	6662 (reasoning 1881, 2 fences)	yes, 18:03:27.290
osaka weather	yes, 18:03:57.399	3577	6667	6667 (reasoning 1881, 2 fences)	yes, 18:03:59.055

Logcat, Tokyo turn (paths trimmed):

18:03:25.497 W octos-ui-agent: legacy turn/completed for turn 01a0a296-… arrived before its persisted row; holding completion and hydrating _main:api:6aa89943-…
18:03:27.286 I aichat UI stream/persisted MISMATCH — streamed=3981 persisted=6662 chars; using persisted (a delta was lost or reordered)
18:03:27.286 I aichat UI turn complete content_chars=6662
18:03:27.290 I L0 card accepted at L0; declarations: source place sys.geocode(name: state.city) | …

Both turns still lost about 40% of their deltas in transit, as before. The difference is that the turn no longer finalizes on the partial stream. Before this build, the same request logged content_chars=3251 with no L0 card accepted, and the screen showed the card source as code.

Screenshots (also on the non-merge branch evidence/appcard-reasoning-model-cards):

tokyo weather	osaka weather

Desktop

cargo build -p octosense --features app-appcard built against the fix as a path patch. I replayed the recorded DeepSeek delta stream at full speed through a mock OpenAI server, with the real kernel over stdio. Result: stream/persisted MISMATCH — streamed=1633 persisted=7194, then content_chars=7194 (equal to the ledger final) and L0 card accepted.

Build

MAKEPAD_ANDROID_EXTRA_LIBS="liboctos.so=<octos deb433e9>/target/aarch64-linux-android/release/octos" \
  cargo-makepad makepad android --devices=bf0a4730 run -p octosense --release   # buildtool 1b11c4a

Merge order: #24, then Octoscript-AppCard#92, then this PR. The pin names 78a1a8d on #92's branch, so if #92 is squash-merged, re-pin this to the merge commit.

🤖 Generated with Claude Code

[ymote]

Closing as superseded: every commit in this stack (#22–#28) is already on OctoSense-ROM main, where the phone shell continued. Per ADR 0001 the phone layer moves into the shared crates/shell from that copy when OctoSense-Desktop and OctoSense-ROM are merged into one OctoSense repository, so nothing here is lost. #25's octos-app pin is obsolete: AppCard now comes from OctoSense-System-Apps on octos main. The branches are kept.

🤖 Generated with Claude Code