# Task: Repair project-doc gate and assess macOS runtime diagnosis

## Identity

- Task ID: 20260811-repair-gate-assess-runtime-3c7e
- Mode: Integration
- Branch: main
- Worktree: D:\Datas\OthersProjects\makelore
- Base commit: 2e6bc0373efe18ef9798cbb4275ecf4caf16450e
- Owner: codex
- Status: Ready for Integration

## Scope

- Restore the documented concurrent-task invariants and reconstruct missing local task reservations so the project-memory gates can run normally.
- Perform a read-only assessment of the reported macOS OpenCode startup `ENOENT`, including runtime path selection, pnpm topology, package metadata, existing tests, and packaged-runtime behavior.
- Do not modify runtime source code or claim the failing Mac's dependency tree was independently inspected.

## Intent And Constraints

- Separate confirmed repository facts from causal inference and unverified evidence supplied by the remote Mac diagnosis.
- Preserve the distinction between development resolution under `node_modules` and packaged resolution under Electron `resourcesPath`.
- Use the exact pnpm version pinned by the repository for local verification.
- Keep the repair limited to project-memory gate invariants and local reservation metadata; no unrelated canonical documentation or product behavior changes.

## Outcome

- Restored three missing invariants in the Concurrent Task Gate: reservation lifetime, serialized registry transactions, and feature-write-boundary precedence.
- Reconstructed six missing local task reservations for valid existing worktree-owner records; `task_context doctor` subsequently reported no registry inconsistency.
- Confirmed that development resolution checks only a root-hoisted native package and otherwise returns the unchecked `opencode-ai/bin/opencode` fallback. On non-Windows, that fallback does not match `opencode-ai@1.18.9`'s declared/generated `bin/opencode.exe`, while Darwin native packages contain `bin/opencode`.
- Confirmed that the reported `ENOENT` is raised when Electron Main spawns the nonexistent resolved path; it is unrelated to model or port configuration.
- Confirmed the permanent fix direction: resolve the platform package relative to `opencode-ai/package.json` with `createRequire`, join its platform-specific binary, validate it, and report a clear error when unavailable. The existing bundle script already uses this package-relative pattern.
- Classified pnpm 11 as a strong trigger hypothesis, not a proven sole cause: the repository pins pnpm 10.33.4 and relies on a hoisting setting that pnpm 11 no longer reads from `.npmrc`, but the failing Mac install tree was not captured independently.
- Identified a separate release risk: one host-architecture OpenCode binary is staged before Electron Builder emits both x64 and arm64 macOS artifacts.
- Made no runtime source-code changes.

## Verification

- `check_project_docs.py`: PASS after restoring the documented gate invariants.
- `task_context.py doctor`: PASS after reconstructing the six missing reservations.
- `corepack pnpm exec vitest run tests/unit/opencode-paths.test.ts`: PASS (7 tests); the suite currently covers only a root-hoisted Darwin development layout.
- Deterministic isolated-layout probe: reproduced the nonexistent fallback three consecutive times; temporary probe files were removed afterward.
- Package-relative `createRequire` probe: resolved an installed platform manifest through pnpm's physical virtual-store dependency graph.
- Independent final Sol high-reasoning read-only review: PASS, with the pnpm 11 causal claim explicitly retained as an inference rather than a confirmed fact.

## Follow-ups

- Implement package-relative development runtime resolution and add isolated-layout, missing-package, architecture-preference, and asynchronous spawn-`ENOENT` regression tests.
- Reinstall the failing Mac with the pinned pnpm 10.33.4 and capture `.modules.yaml`, nested optional-dependency links, and the resolved executable path to validate the trigger hypothesis.
- Stage and verify OpenCode independently for each macOS target architecture before the next dual-architecture release.

## Promotion Candidates

- None. The project-memory gate repair is already applied to its canonical contract; product/runtime conclusions remain task-local until an implementation task changes behavior.