What we can actually use

Recorded 2026-08-16. This is an inventory, not a promise. A configured account is not usable capacity until a live status or usage record says it is, a VM that exists is not a running test machine, and a checked task is not proof the product worked. [RULING D63; OSL-AUDITS/deliverable/01-FULL-SPEC.md:98]

Two lines remain absolute: tests never message anybody except identities the owner controls, and no result is called proof until the claimed event was observed. [RULING D38; OSL-AUDITS/RULINGS.txt:203-220; design/UI-FINAL-INSTRUCTIONS/Strip.dc.html:259]

Headline

The next hour should go to one quiet, real Windows product run on the local host and OSL-QA-1, not more plan work or cloud setup: Daytona is actually capped at 1 CPU and 1 GiB, Azure is deallocated and spend-gated, the local machine is already under heavy load, and the project still lacks a current real packaged send/readback/decrypt result. [PLAN-2026-07-31.md:236-244; OSL-AUDITS/reference/MACHINE-STATE.md:79-82; TASK 7324; TASK 7325]

AI accounts

The email-to-home mapping below is owner-supplied. Authentication was checked without opening or printing credential contents. All four Codex homes return Logged in using ChatGPT, but that proves login only, not remaining quota. [OSL-AUDITS/reference/MACHINE-AND-CAPACITY.md:143-159; direct codex login status, 2026-08-16]

Codex can do non-interactive code changes, review, local commands, web research, images, plugins/MCP, sandboxed runs and model selection. Those are CLI features, not a guarantee that a particular account has quota. [codex --help, codex-cli 0.144.1; OSL-AUDITS/run-task.sh:569-649]

Claude has the strongest immediately observable AI headroom:

• ~/.claude is hypattv@gmail.com, Claude Max 20x, first-party OAuth. At 10:47 PDT its five-hour window was 5% used and resets at 11:20 PDT; its seven-day window was 78% used and resets 2026-08-19 04:00 PDT. Extra usage is disabled. [~/.claude/usage-cache.json; ~/.claude/.claude.json; direct claude auth status, 2026-08-16]
• ~/.claude-b is liamwerner@icloud.com, Claude Max 20x. Its latest visible snapshot is stale: 0% session and 33% weekly, fetched 2026-08-15 12:52 PDT, with the weekly reset shown as 2026-08-19 13:00 PDT. Current headroom cannot be established from that snapshot. [~/.claude-b/.claude.json; direct claude auth status, 2026-08-16]
• Claude refusals have historically been concurrency limits as well as quota limits; adding parallel lanes can make usable accounts refuse. [OSL-AUDITS/reference/MACHINE-AND-CAPACITY.md:151-155]

Kimi is installed but is not capacity. The CLI is 0.26.0, its local configuration exposes K2.7 Coding, K2.7 Coding Highspeed and K3 with 262,144-token contexts, but the provider log contains 1,271 HTTP 403 usage-limit failures, most recently at 10:47 PDT today. The provider says only “next cycle”; no reset date or account identity was observable. [OSL-AUDITS/rc-state/engine-blocked-kimi; ~/.kimi-code/config.toml; ~/.kimi-code/logs/kimi-code.log; OSL-AUDITS/reference/MACHINE-STATE.md:46-53]

Straight AI recommendation: use ~/.claude for bounded implementation or test diagnosis, reserve the remaining ~/.codex-d window for final judgment, and send nothing to ~/.codex, ~/.codex-b, ~/.codex-c or Kimi until their status changes. [RULING D60; ~/.claude/usage-cache.json; ~/.codex-d/sessions/2026/08/16/rollout-2026-08-16T10-44-14-01a00bac-948c-7a41-9f88-03c654fb84a3.jsonl; OSL-AUDITS/rc-state/engine-blocked-kimi]

This machine

WSL has 11 online logical CPUs, not 11 physical cores. It currently sees about 13.65 GiB RAM and 16 GiB swap. [OSL-AUDITS/reference/MACHINE-AND-CAPACITY.md:12-27; direct lscpu and /proc/meminfo, 2026-08-16]

This is a capable build and test host: Rust 1.88, Cargo, Node, npm, PowerShell, Windows cross-build tooling, UI Automation helpers, screenshot/diff tooling, cargo-nextest, sccache, mold, GitHub CLI and the packaged-app support scripts are present. The shipping app must be compiled through apps/osl-hub/Cargo.toml for the Windows target; cargo check --workspace does not include it, and a Linux green result does not prove the Windows product. [OSL-AUDITS/reference/MACHINE-STATE.md:24-44,88-131,196-218]

The current /home/liamw/discord-privacy-client checkout is on dirty branch unit-A1.1, not canonical integration/full. Do not build that checkout and call it release proof; use the canonical branch/worktree and the app manifest. [RULING D61; OSL-AUDITS/deliverable/01-FULL-SPEC.md:340-342]

The machine is not quiet enough for a build fan-out now. At 10:48 PDT load was about 19.6/19.4/13.7 on 11 CPUs, swapping was active, I/O wait was 13–22%, and the current boot had 50 order-7 page-allocation failures. That proves live pressure, not an OOM crash. [direct /proc/loadavg, vmstat, and kernel log, 2026-08-16; OSL-AUDITS/reference/MACHINE-STATE.md:220-228]

The statement that this machine previously crashed from load plus swap pressure cannot be established. Crashes occurred; one local record attributes them to RAM/linker fan-out, a later record identifies disk exhaustion as the known cause, and another says one crash remained unexplained with no OOM trace. The honest operational conclusion is only that concurrent build/test fan-out is risky. [~/.claude/projects/-home-liamw/memory/compute-capacity-real-limits.md; ~/.claude/projects/-home-liamw/memory/wsl-crash-cause-disk.md; ~/.claude/projects/-home-liamw/memory/wsl-crash-vitest-workers.md; OSL-AUDITS/reference/MACHINE-AND-CAPACITY.md:31-49]

There are three monitors. MON-1 at 0,0 is the owner's and must not be touched; agents use MON-2 at 1920,0; MON-3 at 3840,0 is spare. Every agent-opened window must be explicitly placed at x >= 1920 because default placement lands on MON-1. [OSL-AUDITS/reference/AGENT-WINDOW-PLACEMENT.md:1-21]

The free Windows test machine is local Hyper-V guest OSL-QA-1: Windows 11 Enterprise Evaluation, 4 vCPU, 4 GiB startup RAM, working network, and a pristine checkpoint. It is for clean install/first-run and genuinely separate-Windows-state tests; it costs about 4 GiB of host RAM, so do not run a large WSL build fan-out beside it. [RULING D13; OSL-AUDITS/reference/MACHINE-AND-CAPACITY.md:80-139; OSL-AUDITS/reference/MACHINE-STATE.md:82]

Daytona

One Daytona sandbox is started, one is stopped, and seven are archived. The started sandbox is Linux, has outbound HTTPS, a 3.0 GiB overlay with about 2.9 GiB free, and no Cargo or Rust compiler. [live read-only daytona list, daytona info, daytona exec, and df, 2026-08-16; OSL-AUDITS/proposals/daytona-usage.md:48-78]

The reported 48 CPUs and roughly 377 GiB RAM are not usable sandbox capacity. They are host visibility from lscpu and /proc/meminfo. The sandbox's cgroups and Daytona allocation record cap it at 1 CPU, 1 GiB RAM and 3 GiB disk. This exact nproc trap was already measured and written down. [PLAN-2026-07-31.md:236-244; live cpu.max, memory.max, and Daytona allocation record, 2026-08-16]

Daytona is therefore useful only for a tiny isolated Linux Node/Python/static-analysis job. It cannot run Windows UIA, carrier sessions, the packaged product, or a full Rust/Tauri build, and its 1 CPU allocation is slower than the local machine for ordinary compilation. [OSL-AUDITS/proposals/daytona-usage.md:3-13,34-44,76-96; TASK 7324]

Recommendation: stop the currently started Daytona sandbox now unless a named Linux-only job is queued for this hour. Its billing amount could not be established, so no dollar figure is claimed; keeping an unusable started sandbox merely preserves a possible spend. [PLAN-2026-07-31.md:236-244; OSL-AUDITS/proposals/daytona-usage.md:98-125]

Azure and VPS capacity

Azure assets exist. Read-only queries show an Azure for Students subscription, seven provisioned B2s_v2 Windows VMs, all deallocated, plus four successful snapshots. Five VMs use Windows Server 2022 and two use Windows 11 Pro 24H2. [live read-only az account show, az vm list -d, snapshot and resource listings, 2026-08-16; OSL-AUDITS/reference/MACHINE-STATE.md:79-82]

Azure is not established next-hour compute. The CLI says the subscription and billing profile are active, but the owner ruling and machine record say writes were disabled/refused; proving otherwise would require a start operation that can spend money. No VM was started. [RULING “TEST MACHINES”, OSL-AUDITS/RULINGS.txt:273-305; RULING D13; OSL-AUDITS/reference/MACHINE-STATE.md:79-82]

If the owner later authorizes Azure spend because a local test proves a real separate-network or physical-host need, the two Windows 11 VMs are the sensible QA candidates. Until then, leave all seven deallocated and use local Hyper-V or Windows Sandbox. [RULING D13; TASK 4801; OSL-AUDITS/RULINGS.txt:576-603]

No general-purpose VPS is established usable. The only configured SSH aliases are calibration-vps, calibration-data and calibration-dublin-shadow; they were not resolved, pinged or contacted. Calibration infrastructure is live real-money trading and is off limits. Local Lightsail and Contabo key files do not prove a live server or an authorized account, so those remain unknown rather than capacity. [~/.ssh/config; OSL-AUDITS/RULINGS.txt:273-275; OSL-AUDITS/reference/MACHINE-AND-CAPACITY.md:164-178; cleanup-log.md:35]

What testing really lacks

The broad “we need a second physical computer” gate should be cut. Two OSL instances and owner-controlled identities on this PC are the default; OSL-QA-1 supplies a separate Windows installation when that property matters. A second physical computer is justified only after a test names a property Hyper-V cannot exercise. [RULING “TEST MACHINES”, OSL-AUDITS/RULINGS.txt:295-305; RULING D13; TASK 4801]

What may genuinely require physical hardware is a second phone/number for Signal registration and, if still absent after revalidation, an Apple 2FA device for a second iCloud identity. A VM does not manufacture either. [TASK 4961; TASK 4963; TASK 7792]

A real second person is not required for transport proof. Two owner-controlled identities can prove send, provider storage, readback, receive and decrypt without contacting anybody else. A second person is useful for usability and out-of-band safety-number comparison, but may not be used as a real message endpoint under the non-negotiable third-party line. [RULING D38; TASK 7325; design/UI-FINAL-INSTRUCTIONS/Owned Confirmation Verify.dc.html:41]

A Windows code-signing certificate is not a V1 testing prerequisite. The authoritative spec deliberately ships without Authenticode, requires an honest Unknown Publisher/SmartScreen warning, and uses a separately signed release manifest. Requiring an Authenticode certificate before core testing would block the product without preventing a user harm or a false claim; defer it. [OSL-AUDITS/deliverable/01-FULL-SPEC.md:27,344,379; TASK 1603; OSL-AUDITS/RULINGS.txt:67]

Accounts are a smaller and messier gap than the plan suggests. RULING D59 says Discord, Telegram, general mail and provider pairs were verified and names only three genuine gaps: a second OSL Chats identity, a second Instagram identity and one isolated X identity. The current generated account record now says every requirement is UNKNOWN because its live-session verifier could not establish state; for Discord it specifically failed to wait for the asynchronous accessibility tree, and for Telegram it could not prove two identities from the switcher. That is a broken/currently inconclusive verifier, not evidence that all accounts disappeared. [RULING D59; RULING D63; OSL-AUDITS/proof/account-preconditions.json, recorded 2026-08-16]

Do not ask the owner to recreate every account and do not block basic product testing on the full carrier matrix. Revalidate only the two identities needed for the carrier under test; keep UNKNOWN as UNKNOWN; then work through remaining carriers. TASKS 4959-4965 are the refresh path, not a demand for a new account whenever automation cannot read a session. [RULING D59; RULING D63; TASKS 4959-4965]

The product does need two device identities because two-device sync is in V1, but the identity binding is currently unproved. Create or bind the second local/guest OSL identity and observe the behavior; do not turn that into a demand for another physical PC or a real third party. [RULING 13, 2026-08-09; OSL-AUDITS/proof/account-preconditions.json; TASK 7325]

The next hour

1. Stop Daytona and leave Azure deallocated. Do not touch any calibration host. [PLAN-2026-07-31.md:236-244; RULING D13; OSL-AUDITS/RULINGS.txt:273-275]

2. Let the current WSL load settle; do not start a wide Rust/Vitest fan-out. Use Claude ~/.claude for any small diagnosis and reserve Codex ~/.codex-d for the decision or fix that needs it. [OSL-AUDITS/reference/MACHINE-STATE.md:220-228; ~/.claude/usage-cache.json; ~/.codex-d/sessions/2026/08/16/rollout-2026-08-16T10-44-14-01a00bac-948c-7a41-9f88-03c654fb84a3.jsonl]

3. On MON-2, run the current packaged canonical Windows app against one revalidated pair of owner-controlled identities, using the host and OSL-QA-1 only if separate Windows state is needed. [OSL-AUDITS/reference/AGENT-WINDOW-PLACEMENT.md:7-21; RULING D13; TASK 7324]

4. Prove one narrow journey end to end: connect, protected send, provider-side stored row/readback, receive and decrypt. If that works, spend the remaining time on timer expiry and burn for the same pair. Record only events actually observed. [TASK 7325; OSL-AUDITS/deliverable/01-FULL-SPEC.md:15,98; design/UI-FINAL-INSTRUCTIONS/Strip.dc.html:259]

5. If the first carrier fails, fix the product path or report the exact failing boundary. Do not switch back to consent wording, certificate work, a second-person gate, exhaustive plan compliance, or another synthetic proof. [RULING D30(c); RULING D65; TASK 7323]

That hour answers the question that matters: can two owner-controlled endpoints actually exchange one protected message through the shipping Windows product? Everything else is secondary until the answer is yes. [TASK 7324; TASK 7325]