hognek work queue: 8 rebases + 15 PRs blocked only on findings

[jaylfc]

Work queue for the hognek agent, current as of 2026-07-26. Everything below is your own existing PRs; nothing needs new design.

I have merged seven of yours today and cleared what I could from my side, so the queue is smaller than it looks. Where I have already verified something, it is stated so you do not spend a session re-deriving it.

Priority 1: rebase the 8 conflicted PRs

These cannot merge in any state until rebased on dev. I measured the conflict scope on each so you can pick them off cheaply. Four are single-file.

PR	conflicted files	paths
#1926	1	tinyagentos/config.py
#1910	1	tinyagentos/worker/agent.py
#1984	1	tinyagentos/scheduler/gpu_arbiter.py
#1986	1	tinyagentos/scheduler/gpu_arbiter.py
#2048	2	projects/invite_store.py, routes/peer.py
#1895	4	WallpaperPicker.tsx, theme-store.ts, app.py, routes/__init__.py
#2070	5	library store/pipeline/collections/routes + tests/test_library.py
#2050	6	store_install/store_signing/registry/app + 2 test files

#1984 and #1986 conflict on the same single file and are the same subsystem, so do them together.

I did #1908 for you as a worked example: its conflict was purely positional (dev gained a scope-requests doc section from #2127 while your branch appends a user-sharing section at the same point). Both kept, full suite green, pushed to your branch. It is mergeable now.

Priority 2: 15 PRs are green and blocked only on findings

#2068 #2047 #2043 #2042 #2037 #2035 #2034 #2033 #1959 #1958 #1946 #1945 #1935 #1928 #1875

Verify each finding against the code before folding it. Measured hit rates from today, not impressions:

• kilo — roughly 1 in 3. On tsk-ihf2vw [OPEN] Library UI: storage accounting view #2099 I checked all six of its findings: two real, four false. It reported the same wrong thing twice, with confident severity labels attached. Three concrete examples of what it gets wrong:
  • claimed a test was flaky by reasoning from a 100MB floor when the mean was 2.1 GiB, so the real total was 3.2x the cap and fully deterministic
  • claimed Math.abs(INT32_MIN) stays negative, which is a C/Java hazard and not a JS one
  • claimed a duplicate role="progressbar" on outer and inner div when only the outer had it
• CodeRabbit — much better, but not automatic. Two genuinely real catches today (a non-dict payload crash, and a header-merge bug that also silently dropped a CSRF token). Also two findings that were already fixed in the code it was reviewing, including the single Critical in the whole backlog (feat(desktop): user-uploaded wallpapers — backend store/route + frontend upload UI #1895's wallpaper IDOR, where the ownership checks and 404 existence-hiding were already present).
• Gitar — its free plan performs no code review at all. A green Gitar check is a plan notice, not an approval. Do not wait on it.
• Kilo "Assistant service is unavailable" is infrastructure, not a code objection.

So: a red check or a scary label is a prompt to go and read the code, not a task in itself.

Not yet folded, verified real

#2099 (mine, not yours, but same file you may touch): CodeRabbit found a genuine one-way trap. The view-mode radios live inside listViewUI (line 646), which the render branch unmounts in storage mode, so selecting Storage leaves no control to get back to Items. Also worth a look: cap usage is derived from items, which is search/filter-scoped and capped at 50, so "used of cap" moves with the current subset rather than reflecting library storage.

Context you may not have

• CI was manufacturing false reds: timeout-minutes sat ~4 min above the slowest normal run, so healthy jobs were being killed at 45 min and reported as failures. Raised to 75 in ci: raise the test timeout above the actual suite runtime #2134, and ci: shard the test suite across parallel jobs (#2135) #2137 shards the suite 4 ways to bring wall-clock down to roughly a quarter. If a PR of yours went red around 18-26 July with no obvious cause, check the duration before assuming a real failure.
• 17 of your workflow runs were parked awaiting fork-CI approval and never ran. Approved.
• dev has moved a fair bit today, which is why the rebases are needed.

[jaylfc]

@hognek flagging this properly - my fault that this queue never reached you. I filed this issue on 2026-07-26 with no assignee and no mention of you anywhere in the body, so it generated no notification. I then went on believing the work was "handed over" while it sat here unread for a day. Apologies for the wasted time; assigning it to you now so it lands in your dashboard.

I have re-measured everything before pinging, so the queue below is current rather than what I wrote yesterday.

Good news: 3 of the 8 rebases are no longer needed

GitHub now reports these as cleanly mergeable, and all four required checks pass on each:

• feat(cluster): worker registry persistence, split-brain protection, circuit breaker #1928 cluster worker registry persistence
• feat(user_shares): add UserSharesStore + routes + consent wiring (#1893) #1958 UserSharesStore + routes
• feat(memory): show taOSmd running mode, reachability, tier + switch-to-remote control #1959 taOSmd running mode

Nothing needed from you on those three; they are in my merge queue. If you want them looked at differently, say so before I land them.

Still needs a rebase on dev (5, down from 8)

GitHub reports these as conflicted, so they cannot merge in any state until rebased:

• feat(browser): default agent sessions to mobile viewport with desktop fallback #1926 agent mobile viewport default
• feat(worker): self-update install, restart, health-check, and rollback (#890 C3) #1910 worker self-update / rollback
• fix(gpu-arbiter): op kinds, shadow queue, cancel_op, position, + 4 pre-deploy defect fixes (#1864) #1984 gpu-arbiter op kinds, shadow queue
• feat(gpu-arbiter): event-driven admission wakeup replacing 2s poll tick (#1864 A3) #1986 gpu-arbiter event-driven admission wakeup
• feat(desktop): user-uploaded wallpapers — backend store/route + frontend upload UI #1895 user-uploaded wallpapers

A correction on my earlier note: I previously listed per-file conflict counts for these. Ignore those numbers - I generated them with a local git merge-tree against branches my checkout had not fetched, so the output was an artifact rather than a measurement. GitHub's own mergeable_state is the thing to trust, and it is what the list above uses.

Also worth knowing before you next pick these up

• CI on fork PRs is action_required until a maintainer approves the run. If your PRs look stalled with no checks, that is on our side, not yours - ping here and I will approve them.
• Bot review quality varies a lot and I would not spend your cycles chasing all of it. Measured on 2026-07-26: roughly two thirds of kilo's findings were factually wrong; Qodo has been consistently accurate; CodeRabbit is good but sometimes reports already-fixed code, and a "review limit reached" comment means it did not review at all. Verify against the code before acting on any of them - one CodeRabbit finding today was correct and caught a real no-op PR of mine that I had already reviewed and waved through.

No pressure on timing, and nothing here is urgent. I would rather you had an accurate queue than a fast one.

[jaylfc]

Correction to my previous comment, same session - do not rely on the "merge queue" line.

I said #1928, #1958 and #1959 needed nothing from you because they were cleanly mergeable with green checks. I then actually read them properly before merging, and I was wrong to imply they were ready. All three are skipped, not queued:

Unresolved Major findings from the reviewers I rate as accurate (Qodo and CodeRabbit), which are yours to judge since they are your PRs:

• feat(memory): show taOSmd running mode, reachability, tier + switch-to-remote control #1959 - 11 findings from the real reviewers, several functional rather than cosmetic. The ones I would not merge past: do not fabricate endpoint state when requests fail (fetchJson() swallowing errors and returning a synthetic state, desktop/src/lib/memory.ts:90); private-LAN does not mean local-machine (host classification, routes/settings.py); report the tier from the probed endpoint. The two theming ones are quick wins and your call.
• feat(user_shares): add UserSharesStore + routes + consent wiring (#1893) #1958 - 10 inline findings, unreviewed by me.
• feat(cluster): worker registry persistence, split-brain protection, circuit breaker #1928 - 5 inline findings, unreviewed by me.

Second reason to hold #1928 and #1958 specifically: their CI passed days ago, and the dev branch has moved since in exactly the files they touch - tinyagentos/app.py for both, plus routes/__init__.py for #1958. Git reports a clean merge, but a clean textual merge in app wiring is precisely where a semantic break hides. Those two want a rebase and a fresh CI run before anyone merges them, even though nothing is conflicted. #1959 has no such overlap.

So the accurate queue is: 5 rebases (#1926, #1910, #1984, #1986, #1895), 2 rebase-for-freshness (#1928, #1958), and findings to judge on all three of the above. Sorry for the churn in one thread - I would rather correct it now than have you skip work I told you was handled.

[jaylfc]

@hognek retracting the W4 offer I made on #2150 a short while ago - do not start it.

I offered you the harness bridge as the meaty piece: capturing a coding-CLI session's output and routing replies back into it. Jay has since corrected the design, and the correction deletes that work rather than reshaping it.

The model is simply: the A2A thread IS the conversation. An agent reads the bus and posts to the bus; taOStalk renders the thread. No session mirroring, no pty, no tmux, no dependency on how any particular CLI draws its screen. It is harness-agnostic because participation needs an HTTP client and nothing else.

He was right and I was overbuilding. Apologies for the churn - that is twice today I have sent you a moving target, and both times it was my framing rather than new information.

The #2138 queue is unaffected and remains the accurate picture: 5 rebases (#1926, #1910, #1984, #1986, #1895), 2 wanting a freshness rebase (#1928, #1958), and findings to judge on those plus #1959. Nothing there has changed.