# Task: Implement PI-150 packaging, E2E, and performance proof ## Identity - Task ID: 20260824-pi-release-proof-3e725ac7 - Mode: Feature - Branch: codex/20260824-pi-release-proof-3e725ac7-pi-release-proof - Worktree: D:\Datas\OthersProjects\makelore-pi-release-proof-3e725ac7 - Base commit: 977445ba450f4ad32b6e6db2caf048517513ab39 - Owner: codex-root - Status: Implementation and Spec Pass; PI-150 externally blocked by native non-WSL Linux evidence ## Scope - Implement and verify `PI-150 — Packaging, E2E, and performance release proof` from cumulative PI-140 delivery base `977445b`. - Own final Pi production-closure staging, electron-builder wiring, artifact verification, actual packaged Pi/provider-shaped smoke, Coding Electron E2E, performance evidence, release note/runbook draft, and README current-state updates. - Produce Windows x64 and Linux x64 final-product artifact evidence available from this host. Keep canonical `.project-docs` updates for PI-160 Integration Gate; this feature record contains the task-scoped evidence and promotion candidates. ## Intent And Constraints - Preserve Main-owned runtime/provider/credential boundaries, the exact pinned Pi package and pnpm versions, Makelore app identity, project-scoped state, and the single light product system. - Final artifact checks must prove Pi version/engine/entry/resources/production closure/`get_state`, extension and skill presence, no OpenCode production residue, and no development-machine absolute path. - `smoke:pi:real` means the actual Pi process seam from the final artifact using controlled loopback/provider-shaped endpoints. Real external Provider Accounts and real-provider two-worker turns are explicitly waived accepted risks, never Pass; every substitute report retains `realTurnVerified=false`. - The user explicitly skipped macOS validation. Do not manufacture or reuse static/cross-platform evidence for macOS x64 or arm64. Per the planner's second review this evidence is deferred to PI-160: it remains Not Pass and a final cross-platform release blocker, but is not a PI-150 blocker. - The canonical project memory at this base is stale and still describes OpenCode. Treat the planner-owned PI Spec/ticket and current source as the task authority; do not edit canonical memory in this feature worktree. - The main worktree is occupied by an older integration task. Remain rooted in this isolated worktree and do not inspect or modify peer uncommitted files. ## Plan 1. Audit the cumulative PI-140 tree against every PI-150 packaging, smoke, E2E, performance, release-note, and README requirement; reuse only verified existing seams and identify concrete missing behavior. 2. Implement focused missing harnesses/wiring/tests with behavior-level regression coverage, then run typecheck and relevant unit tests. 3. Run the full pinned validation set and build the Windows x64 final product artifact; run its verifier, actual packaged Pi/provider-shaped smoke, and required performance scenarios with structured statistics. 4. Use WSL2 only if available to perform a frozen Linux x64 install, final product build, verifier/smoke, and performance run; label any environment or artifact limitation precisely. 5. Record reproducible commands/results, accepted Provider risk, skipped macOS release blocker, release note/runbook, README delta, and PI-160 promotion candidates; complete the Task Documentation Gate without overstating release readiness. ## Outcome - Final code candidate `09841c8dbd7c58ce9ecda9dc49ea1c1b57759b67` closes the three P1 implementation/proof defects from the planner's second review and the two P1 defects from its third review. Final-product proof now runs Main from packaged `app.asar`, starts the packaged `resources/pi-runtime/dist/cli.js`, receives a real `subagent` tool call from a controlled loopback provider, dispatches through the real `PiSubagentScheduler`, and starts a real ephemeral Pi child with exactly the `find`, `grep`, `ls`, and `read` tools. - Each cold and warm proof is one Main-owned correlated timeline containing `worker.queue_wait`, `resources.ready`, `worker.spawn`, `rpc.ready`, `session.open`, `prompt.accepted`, `agent.start`, `provider.first_event`, and `agent.settled`. Direct admission emits an explicit zero-duration queue wait; reopening the same session after a resource rebuild is correctly classified as warm. - `provider.first_event` now accepts only Pi's Provider-backed assistant `message_start`, never `turn_start` or the local user-message lifecycle. The controlled Provider delays its first response by 75 ms; the packaged smoke asserts the source marker, strict timestamp ordering, and a measured delay of at least 75% of that value, so the old zero-millisecond false milestone fails. - The 4+4 pressure proof now holds four real persistent Pi parents and four real ephemeral Pi children as eight distinct live OS processes while four write leases are active, proves the product UI remains interactive, and then proves all processes, provider requests, process-budget entries, child permits, dispatches, parents, and write leases return to zero. - Pressure cleanup now attempts every bounded cleanup step even when an earlier step fails, keeps the global run handle until cleanup succeeds, and supports idempotent retry. Unit tests cover one-shot failure and a hanging step; final Windows and Linux products also inject a `parents.settle` failure into a real 4+4 run, observe the expected first failure, retry, and prove every counter and PID returns to zero. - Real concurrent parent startup exposed a supported Windows failure in the shared managed provider catalog: simultaneous temporary-file renames could fail with `EPERM`. Same-path catalog writes are now serialized, with focused concurrency regression coverage. This is a product fix, not a proof-only workaround. - Windows x64 and WSL2 Linux x64 final products passed Pi `0.84.2` production-closure, packaged composition, lifecycle, controlled provider-shaped, real parent/child extension execution, 4+4 pressure/isolation, cleanup, and performance qualification. Windows NSIS and Linux AppImage/DEB/RPM distributables were produced. - Full ASAR enumeration found zero product-owned OpenCode paths. Exact matches under the pinned upstream `@earendil-works/pi-ai/dist/providers/opencode*` closure remain classified separately because Pi imports them; they are not Makelore-owned runtime residue. - PI-150 remains blocked only by the missing independent native non-WSL Linux desktop/compositor acceptance evidence. WSL2/WSLg is useful final-product evidence but is not relabelled as that native environment. PI-160 must not start while this blocker remains. - QG-004/QG-005 remain `Explicitly Waived / Accepted Risk`, with `realTurnVerified=false`; concurrency, credential isolation, and protocol compatibility against real Provider accounts are not claimed as Pass. - The planner's fourth fixed-range review closed both remaining P1 findings, reported `Standards: Pass` and `Spec implementation review: Pass` with zero new P0/P1/P2 findings, and independently reconfirmed the Windows packaged delayed Provider milestone plus failure-injection/retry cleanup. The PI-150 gate itself remains `Blocked / Not Done` only because native non-WSL Linux desktop/compositor evidence is still absent. ## Verification - At the user's request, Windows x64 was rebuilt from clean task HEAD `2e1b90b7707aa912c576e042b94823dcb183e162` with the exact pinned pnpm `10.33.4` via `pnpm run package:win`. The resulting local NSIS installer is `release/Makelore-2.0.0-win-x64.exe`, 208,525,129 bytes, SHA-256 `316FC05C0DC5DA206FA9BE9AA694BEC6DE9DBB2DFBEEEBCFB67472C7F78AF5A3`. Its blockmap SHA-256 is `9E6259C90B41F24A0960EC147A50D5FF2527245669CF7BB98665ADF15D420AA9`; its final `app.asar` remains byte-identical to the reviewed code candidate at SHA-256 `872E8D1E7F22994EFF10353DF380016A198C59C145EBF63491E13DA1B1071B7F`. The local installer has no Authenticode signature and may therefore trigger Windows publisher/SmartScreen warnings; no signed-release claim is made. - The rebuilt package passed `verify:publish-runtime`, `verify:artifact:win`, `verify:artifact:pi`, `smoke:pi:real`, and `perf:pi:release`. The three structured reports are `release/evidence/pi-artifact-win-2e1b90b.json`, `release/evidence/pi-smoke-win-2e1b90b.json`, and `release/evidence/pi-performance-win-2e1b90b.json`; smoke and performance both record the clean `2e1b90b` commit. Five-sample performance passed all budgets with cold/warm Provider-first p95 `136/134 ms`, 4+4 pressure UI p95 `108 ms`, and exit p95 `18 ms`. The packaged fault-injection run retried the same cleanup handle and returned every process and resource counter to zero. - Exact pnpm `10.33.4` frozen install passed on Windows and WSL2 Ubuntu 24.04 x64; both final-product runs were bound to clean commit `09841c8`. The lockfile change remains limited to the direct `@electron/asar@3.4.1` verifier dependency. - Candidate-final Windows checks passed: `pnpm run typecheck`; `pnpm run lint:check` with 0 errors and five pre-existing warnings; focused proof tests and cleanup tests passed; focused concurrency tests passed; `pnpm test` with 179 files/1508 passed/2 skipped; `pnpm run test:e2e` with 24/24; and repeated `pnpm run build:vite` production builds. - Final Windows NSIS `release/Makelore-2.0.0-win-x64.exe` is 208,525,071 bytes with SHA-256 `396D6E8EC2BED60498DBC36CDA714176B629574914B85A5651C73DF8A63CECAA`. Its unpacked `app.asar` SHA-256 is `872E8D1E7F22994EFF10353DF380016A198C59C145EBF63491E13DA1B1071B7F`. The post-installer-build final product proof passed from that ASAR with real Pi parent/child PIDs and complete cleanup. Windows structured reports are `release/evidence/pi-smoke-win-final.json` and `release/evidence/pi-performance-win-final.json`. - Windows formal five-sample performance passed every budget and recorded all nine cold/warm milestones with five samples each. Cold p95 was queue `0 ms`, resources `30 ms`, spawn `18 ms`, RPC `750 ms`, session `4 ms`, accepted `2 ms`, agent start `1 ms`, Provider first event `151 ms`, and settled `1034 ms`; warm p95 was `0/10/9/660/1/2/0/144/146 ms`. Five 4+4 pressure samples had UI p95 `140 ms`; Renderer first-commit p95 was `33.6862 ms`; exit p95 was `16 ms`. - WSL2 Linux x64 final product was rebuilt at exact clean commit `09841c8`. AppImage/DEB/RPM SHA-256 values are respectively `d0923c3d80c046c3e98750f7d55696e2753b710f9441d043a94768e0395a69c5`, `930cc826993506f56544adc3c29fcddd993117c04e87332c81d031fd9d1ce070`, and `81c1ceefbbe6314dec9c98b1441507458f23eea52c9acbf1360be0db20a88986`. Final ASAR SHA-256 is `9ce9bce7a36e9d93a866b6982fb53c9e98f410d2dd92003fee2d3370deff7b15`. - Linux formal smoke passed Pi `0.84.2` production closure, 10,284-entry ASAR enumeration, zero product-owned OpenCode paths, actual final Pi processes, real packaged extension/subagent dispatch, 4+4 pressure, and zero cleanup. Reports copied beside the Windows evidence are `release/evidence/pi-smoke-linux-wsl2-final.json` and `release/evidence/pi-performance-linux-wsl2-final.json`. - Linux formal five-sample performance passed every budget and recorded all nine cold/warm milestones with five samples each. Cold p95 was queue `0 ms`, resources `14 ms`, spawn `6 ms`, RPC `480 ms`, session `2 ms`, accepted `2 ms`, agent start `0 ms`, Provider first event `114 ms`, and settled `740 ms`; warm p95 was `0/6/5/467/1/1/0/111/112 ms`. Five 4+4 pressure samples had UI p95 `115 ms`; Renderer first-commit p95 was `28.3212 ms`; exit p95 was `9 ms`. - Linux results are WSL2/WSLg final-product evidence, not an independent native non-WSL Linux desktop/compositor/distribution acceptance run. Controlled provider-shaped smoke issued six requests per protocol (distinct cold, warm, and abort-isolation paths); real Provider verification remains false by the explicit waiver. - Planner re-review of `ead9d1d..6d2232c` passed the fixed diff and documentation gates. Its independent Windows packaged rerun measured cold and warm Provider-first milestones at `127/129 ms`, both sourced from `pi.assistant_message_start` and strictly later than `agent.start`; cleanup unit tests passed `2/2`, and the real 4+4 injected-failure run retained the same handle for a successful retry with every PID, counter, permit, dispatch, lease, and Provider request returning to zero. ## Follow-ups - Planner re-review is complete: Standards and Spec implementation both pass, the two remaining P1 findings are closed, and no new finding was raised. - Do not start PI-160 or integrate the candidate while PI-150 remains blocked by the native non-WSL Linux platform evidence boundary. If the planner finds no new implementation defect, keep PI-150 as the active frontier until that external evidence is supplied or its gate is explicitly re-decided. - Keep missing macOS x64/arm64 artifact/runtime/resource/performance evidence as `Deferred to PI-160 / Not Pass`; do not promote a final cross-platform release without independent macOS execution, but do not use it to block PI-150. - Keep the lack of an independent native non-WSL Linux desktop/compositor/distribution run explicit. The WSL2/WSLg run qualifies the generated Linux artifacts and final process seam but does not erase that environment boundary. - Real Provider Account and real-provider concurrency/credential/protocol compatibility remain accepted risk unless the user explicitly revokes the waiver and supplies provider access. ## Promotion Candidates - After PI-150 is actually unblocked, PI-160 may promote the current Pi runtime/Conversation state from README and `docs/pi-runtime-release-runbook.md` into canonical project memory during integration review. - PI-160 must record QG-004/QG-005 as `Explicitly Waived / Accepted Risk`, with `realTurnVerified=false`; this is not a Pass. - PI-160 must preserve any unresolved macOS x64/arm64 or native Linux missing-evidence blocker; this candidate does not authorize overriding it.