Files
makelore/.project-docs/30-worklog/tasks/20260825-pi-session-reopen-installer-8c3e7a91.md
T

167 lines
8.9 KiB
Markdown

# Task: Fix persisted Pi session reopen and build Windows installer
## Identity
- Task ID: 20260825-pi-session-reopen-installer-8c3e7a91
- Mode: Feature
- Branch: codex/20260825-pi-session-reopen-installer-8c3e7a91-pi-session-reopen-installer
- Worktree: D:\Datas\OthersProjects\makelore-pi-session-reopen-installer-8c3e7a91
- Base commit: e74b59a67479a32619a9e3dbef476a65a6ad071f
- Owner: codex-root
- Status: Ready for Integration
## Scope
- Fix the packaged Pi runtime path that opens generation 1 without the
Conversation's already persisted Pi session binding after an application
restart or later re-entry.
- Add focused regressions proving the managed opener reuses the Registry
binding when `PiWorkerPool` does not provide an explicit `existingSession`,
while a genuinely new Conversation still creates one binding.
- Build and verify a Windows x64 NSIS installer from the cumulative hotfix base
`e74b59a67479a32619a9e3dbef476a65a6ad071f` plus this repair.
## Intent And Constraints
- Preserve the user's existing Pi JSONL and Conversation metadata. Do not
delete, rewrite, migrate, or silently replace a persisted binding.
- Derive the effective reopen binding from the explicit worker-pool binding or
the Main-owned Registry record, in that order. Keep the existing
`CODING_SESSION_UNREADABLE` mismatch checks fail-closed.
- Keep the repair inside the existing Pi managed opener/Registry boundary; do
not add a fallback runtime, compatibility layer, or product migration.
- Preserve new-Conversation allocation and fork semantics, and report a
Registry-backed reopen as warm telemetry.
- The previously diagnosed thinking-level submission stall is a separate task
with no accepted implementation. Do not mix an unverified fix into this
installer.
- Use pinned pnpm `10.33.4`, focused tests, full repository checks,
`build:vite`, Windows Electron E2E, formal Windows packaging, and final
artifact/runtime verification.
- Real Provider verification remains `Explicitly Waived / Accepted Risk` with
`realTurnVerified=false`; loopback/package evidence is not a real Provider
Pass. macOS and native non-WSL Linux evidence status is unchanged.
## Project Context Loaded
- Concurrent Task Gate: Passed in the isolated worktree owned by `codex-root`;
the task record, branch, worktree, and base commit match the registry.
- Planning Gate: Passed after reading the project entry/memory indexes, current
state, architecture/data-flow/evidence/commitment records, the installed
session-unreadable diagnosis, the cumulative Windows proxy hotfix, the
thinking-stall diagnosis, PI-150 packaging evidence, and all peer records
still marked planning or blocked.
- Canonical current-state documents predate the cumulative Pi delivery. The
current source, diagnostic evidence, hotfix task record, and cumulative
release-proof record are authoritative for this repair.
- Other planning tasks are on older or unrelated AI Design/Robot/OpenCode
baselines. The main-worktree OpenCode integration task is blocked and does
not package; no unresolved semantic conflict or code-write overlap changes
this plan.
- No subagents are used, per user direction and repository policy.
## Plan
1. Add a focused red regression for a Registry-persisted binding with no
explicit `existingSession`, including session-id argv and warm telemetry.
2. Make the managed opener use one effective binding consistently for session
selection, fork rejection, reopen mismatch validation, and telemetry.
3. Run focused Pi tests, typecheck, lint, full unit tests, `build:vite`, and
Windows Electron E2E; fix only task-caused failures.
4. Commit the clean candidate, build the Windows NSIS, and run final Windows
artifact/Pi/runtime/package smoke checks, including persisted-session reopen
and fresh-Conversation binding behavior.
5. Record the final installer path, size, SHA-256, exact evidence, and remaining
accepted/deferred risks; complete the task documentation gate.
## Outcome
- Implemented one effective reopen binding in `createPiManagedWorkerOpener`:
explicit worker-pool binding first, otherwise the persisted Registry binding.
Session-key selection, reopen/fork validation, Pi session-id mismatch checks,
and cold/warm telemetry now use that same binding.
- Preserved the existing post-open Registry mismatch guard and session-file
containment checks. No user session, Conversation schema, or migration path
changed.
- Extended the managed opener regression to simulate a process restart with a
fresh `PiSessionRegistry`: the persisted binding is reused without invoking
the new-session key generator, while the original first-open path still
creates exactly one binding.
- Committed the reviewed repair as
`862d1b6d921f421ff0eaeb2f1df16274445dbc01` and built the Windows x64
product from that clean commit.
- Generated the NSIS installer
`release/Makelore-2.0.0-win-x64.exe`. The final unpacked app runs Main from
`app.asar`, loads the packaged Pi `0.84.2` production closure, and passes the
existing managed extension/subagent/Host-proxy product proof.
- Ran a task-local, non-retained packaged restart proof against an isolated copy
of the exact user Conversation and Pi session reported in the incident. Two
separate launches of the final executable each hydrated 18 Conversation
nodes with worker `ready`, run `idle`, and no public error. The source
project/session and installed application were not modified.
## Verification
- Frozen install with pinned pnpm `10.33.4`: passed; lockfile unchanged.
- Red regression before implementation: failed at the exact existing
`Pi session binding does not match the Conversation registry` branch.
- Focused managed opener/Registry/runtime/worker-pool suite: 4 files / 23 tests
passed after the repair.
- `corepack pnpm run typecheck`: passed.
- `corepack pnpm run lint:check`: passed with 0 errors and five pre-existing
Renderer warnings.
- `corepack pnpm test`: passed; 178 primary files / 1512 passed / 2 skipped,
plus the isolated REN-008 pressure test 1/1.
- `corepack pnpm run build:vite`: passed with only existing advisory warnings.
- `corepack pnpm run test:electron:windows`: 2 files / 4 tests passed.
- `git diff --check`, task ownership drift, and required project-doc checks:
passed before packaging.
- `corepack pnpm run package:win`: passed from clean candidate `862d1b6`;
staged 130 Windows x64 Pi production packages and six runtime assets, then
produced the NSIS and blockmap.
- Final installer: 211,888,196 bytes; SHA-256
`00B474114B5B398DCA8374238A5C144E69A17E9419B21615143FCD59E4C62658`.
Blockmap SHA-256:
`AD2F44E242BF0A6C2C9C08FD3E068DBF4E2431D62663A93188E95D3DCA388439`.
Final `app.asar` SHA-256:
`6F5B95F653ED346DD1616C403584EC61F23A2AE6907DB47D27FE28EE5DA4AF09`.
- `corepack pnpm run verify:publish-runtime`: passed; bundled npm `11.6.2`.
- `corepack pnpm run verify:artifact:win`: passed and bound the artifact to
commit `862d1b6`; Electron `43.4.0` / Node `24.18.1`, bundled Python/uv/npm,
msgpackr, and Canvas native assets loaded from the final product.
- `corepack pnpm run verify:artifact:pi -- --samples 2`: passed; Pi `0.84.2`,
CLI, all 130 expected packages, six runtime assets, five unpacked native
assets, managed Skills, extension markers, session persistence, local worker
overlap/abort isolation, cleanup, and cold/warm budgets were verified. The
nested report correctly remains `partial-pass` for the pre-existing external
platform and real-Provider evidence boundaries.
- `corepack pnpm run test:pi-subagent:packaged`: passed from final
`win-unpacked/Makelore.exe`. Main executed from `app.asar`; cold/warm managed
turns, a real packaged parent and ephemeral child, 4+4 process pressure,
authenticated Host-proxy loopback, failure-safe cleanup/retry, UI
interactivity, token non-disclosure, and zero released resource counters all
passed with `realTurnVerified=false`.
- Final persisted-session packaged proof: two independent launches both
returned worker `ready`, run `idle`, 18 hydrated nodes, and no error. The
temporary verifier and isolated user-data copy were removed after the run.
- Final Windows process query found zero residual processes from this worktree.
- The local installer has no Authenticode signature (`NotSigned`); no signed
release claim is made and Windows may show a publisher/SmartScreen warning.
## Follow-ups
- The unsupported-thinking-level / indefinite `正在提交…` issue remains a
separately diagnosed defect. This package does not claim that unimplemented
fix.
- Real external Provider validation remains explicitly waived accepted risk,
with `realTurnVerified=false`; packaged loopback evidence is not a real
Provider Pass.
- macOS and native non-WSL Linux release evidence status is unchanged by this
Windows-only repair.
## Promotion Candidates
- Promote the invariant that generation-1 worker open must consume an existing
Main Registry binding, plus the packaged restart/re-entry regression, into
the Pi release runbook when the cumulative Pi branch is integrated.