Step 16: First usable slice check #12
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The first usable slice end to end in browser, CLI and MCP; budgets on the perf-test VM.
Step 16 in docs/PLAN.md. Done when: all green, numbers recorded
Starting S1 end-to-end suite work on branch
s1-e2e, based ondevat9688a2438a1c5bbeeb3326a5be8df58e5c4f9a0a. Scope is a newe2e/s1/suite plus a separatee2eentry point inscripts/verify; no product code orscripts/browser-check.mjsedits. The suite will use the release binary, Chromium virtual authenticator, real Docker and rootless Podman, capture timings/screenshots/JSON under/mnt/hdd/infraternal/artifacts/s1-e2e/, and report 12b/13b/14b as pending when absent from this base.Finding from base
9688a2438a1c: product-path features are absent despite being listed in the plan sequence.packages/web/src/routes/containers/[host_id]/[engine]/[container_id]/+page.sveltehas facts/ports/mounts/labels but no log or exec surface;/terminalsrenders a placeholder;crates/infraternal/src/main.rs::Commandhas nologs,exec, orsshvariants. I’ll make the suite report browser logs/exec, the terminal route, and CLI logs/exec/ssh aspending_featurewhen those controls/commands are absent. UI lifecycle, CLIpsplusstop --dry-run/--plan, and MCP list/refusal/plan/execute remain required passes.Decision: use a dedicated
scripts/verify e2elevel because this suite owns a single release-binary run spanning setup, Chromium, real engine fixtures, CLI device login, and MCP stdio; the existingintegrationandbrowserlevels remain focused on narrower checks.The bounded-log fixture policy follows issue #19. Docker supports
max-sizeandmax-file; installed Podman 5.4.2 documentsmax-sizefor its k8s-file driver but does not listmax-file, so fixtures will use the supported size bound there: https://docs.podman.io/en/latest/markdown/podman-run.1.htmlFinished: S1 E2E prep
Branch:
s1-e2eHead:
8acbb64b5f54bc6411a3897ac3842103bb8354b8Commits:
229775b(suite and gate),ac12de3(virtualized table filtering),8acbb64(CLI response assertions and exact-500 smoke).I added a dedicated
scripts/verify e2elevel because this flow spans browser authentication, a long-lived release server, CLI device login, MCP stdio, and real Docker/rootless Podman; it is broader than either the existing integration or browser gate.ps, stop dry-run and planai_agentMCP setup and stdio plan flowPending features detected at runtime:
--help.Smoke measurements (all are dev VM smoke; reportable only from the perf-test VM): keystroke p99 was 11.3 ms Docker / 23.7 ms Podman against a 5 ms target; list p99 at exactly 500 labelled containers was 19.63 ms against 20 ms; first-load JS was 218,816 encoded bytes against 122,880 bytes; idle server RSS was 35.15 MiB against 40 MiB. The suite records these target comparisons but does not treat dev VM values as reportable performance evidence.
Artifacts:
/mnt/hdd/infraternal/artifacts/s1-e2e/s1-mufedu4c-0f29cca6/report.json,dashboard-desktop.png,containers-desktop.png, andcontainers-mobile-390x844.png. Cleanup completed with no errors; temporary credentials were revoked, temporary data removed, and run-labelled containers removed.No product flow defect was found. The initial anonymous
POST /api/v1/auth/refreshreturns 401 before setup;authStore.initializecatches that response and clears the unauthenticated session. The first screenshot also showed the shared host inventory had 159 rows and the test fixture was outside the virtualized table's mounted rows; the suite now filters by its unique run suffix. Other failures were suite assertion mismatches and are corrected. No product code was edited.Gates (verbatim output)
scripts/verify fastscripts/verify e2eStarting independent review on branch
s1-e2e. Review head:8acbb64b5f54bc6411a3897ac3842103bb8354b8; fetched currentdevatd4d16de(includes steps 11b and 12f). I am merging that head before reviewing the E2E suite and gates.Independent review result
PASS by suite-review criteria; no open
blocks-mergefinding. Branchs1-e2e, final head7517cf3bc3941cdc87172d1a7fab9fca0286c35b. The review mergedorigin/devatd4d16de(including 11b and 12f) before reviewing. No push.1. S1 flow — PASS, with product gaps marked pending
Two post-fix sequential runs used the real release binary, real Docker, rootless Podman, and Playwright Chromium’s virtual authenticator. Step 1 setup-token startup, step 2 passkey registration, and step 3 live inventory transitions ran. Step 4 exercised UI start/stop/restart/remove on both engines; Logs/Exec UI is absent and pending. The real Chromium stream smoke ran. Step 5 visited Hosts list and detail; SSH controls are absent and pending. Step 6 exercised device login,
ps, and the stop plan; missing CLI logs/exec/ssh are pending. Step 7 used a scoped MCP token, verified a destructive action is refused without a plan, then executed the plan; missing MCP logs/exec/ssh are pending. Both reports arepassed_with_pending_features; no missing flow is silently skipped or marked passed.2. Measurements — PASS for JS budget; later for release performance evidence
The
218,816value is the sum of raw response-body bytes across 14 same-origin JavaScript files. The E2E runner separately gzip-compresses each body and sums to 76,762 bytes, below the budget of 122,880 bytes (120 KiB). Setup and authenticated dashboard reload both produce this count; the terminal lazy chunks were not loaded. The earlier browser gate’s 76,761 B uses the same per-responsegzipSyncmethod; its one-byte difference is immaterial. The four largest raw/gzip contributors areNozeucNs.js70,429/22,333 B,rbrvUBU4.js56,987/21,365 B,nodes/0.GrtJoSzt.js37,024/12,480 B, andDYb7skxK.js26,778/10,258 B. The remaining ten total 27,598 raw / 10,326 gzip bytes. The full per-file list is in the reports below. The embedded test server does not send a gzip content-encoding header, so raw bytes describe the test transfer and gzip bytes are the explicit budget measure.The reported 11.3/23.7 ms keystroke p99 values are not comparable with PLAN’s paced ~55 MiB/s stream workload: these are low-rate fixtures (~300 B in 5 seconds). The runner now labels them
plan_budget_comparable:falseandreportable:false, and records host load. In the second clean run, smoke p99 was 1.6 ms Docker / 5.9 ms Podman; load averages (1/5/15 min) were Docker 9.69/11.60/12.27 before and 8.72/11.33/12.18 after, Podman 8.72/11.33/12.18 before and 8.99/11.34/12.18 after. The first clean run measured 9.4/10.5 ms under 12.93–13.31 1-minute load. These are smoke diagnostics, not a keystroke budget pass.Container-list p99 used 200 nearest-rank samples over direct API calls returning exactly this run’s 500 labelled containers. In the second clean run it was 29.76 ms against the 20 ms target while load was 23.29/15.24/13.46 before and 23.02/15.31/13.50 after (1/5/15 min); it is explicitly a non-reportable dev-VM smoke. The timing ends after JSON parsing, so it is client-observed request-plus-decode time, not an internal server-handler timer.
Idle server RSS sampled the actual release-server PID’s
/proc/<pid>/statusVmRSSfive times after the browser and test containers were removed. Second-run peak was 39.41 decimal MB / 37.59 MiB at load 21.97/15.60/13.63; the first clean run was 41.10 decimal MB / 39.20 MiB at load 17.66/13.57/12.61. These dev-VM values are marked non-reportable; official budget evidence still belongs on the perf-test VM. Linux documentsVmRSSas resident set size, labels the fieldkB, and notes its reported value can be inaccurate: proc_pid_status(5).3. Isolation and cleanup — PASS
The suite uses a unique run ID, dynamically selected loopback port, per-run temp/database/HOME/XDG directories, unique artifact directory, run labels, and bounded container logs. The broad stale-container sweep was removed. After each normal run, exact Docker/Podman labels and temp roots were absent and
cleanup_errorswas empty.For the hard-kill check, I verified one labelled fixture in each engine, confirmed PID 1160101 was this run’s Node runner (process group 1160099), and sent SIGKILL only to that PID after step 3. The wrapper exited 137 as expected, then removed both exact container labels, the process group, and its temp root. No simultaneous duplicate suite was launched; the per-run isolation was exercised alongside other VM jobs without touching their processes.
4. Re-runnability — PASS
Two post-fix
scripts/verify e2eruns completed sequentially. Both reportedpassed_with_pending_features, had no cleanup errors, and left no run-scoped containers or temp roots. Their reports are:/mnt/hdd/infraternal/artifacts/review-s1-e2e-12-c/s1-1790251436470346072-1078539-23713/report.json/mnt/hdd/infraternal/artifacts/review-s1-e2e-12-d/s1-1790252233794916194-1103121-26991/report.json5. Gates — PASS
Verbatim output from final
scripts/verify fast:Verbatim status lines from the second clean
scripts/verify e2erun:Findings and fixes
blocks-merge— fixed inf8f72cf: the original 218,816-byte value was raw, but was compared as gzip. The corrected gzip value is 76,762 B and passes the budget.blocks-merge— fixed in7517cf3: SSH feature detection queried a fixture after step 4 had removed it. Step 3 now retains the host ID; step 5 visits Hosts list/detail and reports the absent SSH flow as pending.later: run the prescribed paced stream benchmark and controlled list/RSS A/B on the perf-test VM before making release-budget claims. Current dev-VM diagnostics are explicitly non-reportable and were collected under high load.Hard-kill injection output (expected failure):
Post-kill cleanup checks:
Orchestrator: the S1 end-to-end suite is merged to
devat0113f79and pushed (step 16 prep). The review passed with no blocks-merge findings. Gates on the merge head: fast 15/15;scripts/verify e2epassed with pending features (12b logs UI, 13b exec UI, 14b SSH, CLI logs/exec/ssh, and the matching MCP tools). First-load JS is 76,762 B gzip (budget 120 KiB). Watch item for step 16: 500-container list p99 29.76 ms against a 20 ms target, measured at load5 about 15 on the dev VM (non-reportable); it must be measured on the perf-test VM.