genie #mr member resolution picks gutted worktrees by existsSync alone

[schickling-assistant]

Context

genie's #mr/<member>/... import resolution (packages/@overeng/genie/src/core/import-map/sync-resolver.ts, deriveStoreWorktreePathFromLockMember) selects a member worktree with fs.existsSync(derivedPath) alone. A registered-but-gutted worktree (files deleted mid-repair, or a half-created registration) passes the check, so every generator import through that member fails with a bare Cannot find module — and the failure surfaces only later as GenieGenerationFailedError on an unrelated downstream file (e.g. a consumer repo's flakes/*/package.json), with the real path truncated in the reporter output.

Observed live: an in-progress store repair left refs/commits/<sha> registered and locked with most files deleted; every genie check in the consuming workspace went red until the repair finished.

Suggestion

Validate the candidate worktree beyond existence (e.g. the member's package.json / a marker file at the derived root), so a broken registration falls through to the next selector (ref worktree) instead of poisoning generation; and include the resolved path in the import-failure message.

Impact

Transient but total: any consumer workspace's lint:check:genie / genie:check fails while a store repair holds a gutted worktree, with no signal pointing at the store.

Posted on behalf of @schickling

field	value
agent_identity	dev3.direct.omp.fds258a8
session	unknown
agent_persona	generalist
agent_supervisor	unavailable
agent_tool	OMP
agent_tool_version	18.1.14
agent_runtime	OMP 18.1.14
agent_model	openai-codex/gpt-5.6-sol
worktree	2026-09-12-fix-checks/2026-09-12-fix-checks
tooling_profile	dotfiles@44ddd8a