mex-memory/mex

Summary When the Hub setup wizard does not launch a population agent, it still shows an empty transcript panel reading "Session ended" / "This session produced no output." next to the manual population prompt. Users read this as a crashed agent run, and the page never says why no agent ran. Repro On a checkout that needs setup, run mex (or mex setup). In the AI-tools step, select only tools other than Claude Code or Codex, or select Claude Code while claude is not on the PATH of the process that started mex. Continue to population. Result: the "Populate scaffold" card shows an empty transcript with "Session ended / This session produced no output.", followed by "Setup is waiting for population. Complete the prompt in your AI tool, then continue setup." and the copyable prompt. Why it happens launchSetupPopulationAsync (src/setup/population.ts) returns { tool: null, completed: false } when no selected tool is Claude/Codex (setupAgentCandidates) or where/which cannot find its CLI. No

Summary If a setup is committed before finalization runs, every clone of that repo has a Wiki that the Hub cannot read and cannot repair. Health shows Wiki index: Migration required · No repair recommended, with no action and no command. Seen on 0.8.3 in a real repository: the scaffold was populated by an agent and committed, but setup was never rerun. None of the committed .mex/*.md files carried a mex: key, so finalization had never migrated them. Repro In a code repo, run mex setup --cli (or have an agent run it). It pauses at population. Let the agent populate the scaffold, then commit .mex/ without rerunning setup. Clone the repo, or delete .mex/wiki.db, and run mex. The full Hub opens. Health → Wiki index shows migration_required, "Legacy Knowledge requires an explicit migration before Hub reads can continue", and No repair recommended. Why it happens Three gaps line up: Nothing enforces finalization before the commit. Terminal setup prints "After the agent finishes, rerun

A follow-up to #201, #202 and #203: mex check false positives on clean, freshly set-up scaffolds that none of those issues cover. Each was observed on a real scaffold. A freshly populated Hono scaffold scores 8/100, and 10 of its 12 issues are false. 1. Scoped packages declared in package.json but not installed ✗ MISSING_PATH Referenced path does not exist: @hono/node-server ✗ MISSING_PATH Referenced path does not exist: @typescript/native-preview ✗ MISSING_PATH Referenced path does not exist: @types/node All three are in the repository's devDependencies. pathExists (src/drift/checkers/path.ts:225) confirms a scoped package only through Node module resolution or a workspace name, so every clone that hasn't run npm install reports every scoped package it documents. The declared manifests should count, which loadAllDependencies already reads. (This is separate from #202 bullet 5, which is about installed packages with a strict exports map.) 2. A package's JSR name ✗ MISSING_PATH

Describe the bug On macOS machines with TeX Live installed, command -v mex resolves to TeX Live's mex binary instead of our CLI. The lookup returns cleanly - but for the wrong program. Any setup step, doc, or script that checks for mex by name can pass while mex-agent isn't actually installed or runnable, and users can invoke the wrong binary without an obvious error. Reported by Jang Young Jeong (@akillness) in a hands-on audit: https://akillness.github.io/posts/mex-macos-command-collision/ To Reproduce On macOS with TeX Live installed, run command -v mex It resolves to the TeX Live binary, not mex-agent Install/verify steps that check mex by name pass incorrectly Expected behavior Install verification and docs should verify capability (the resolved binary actually responds as mex-agent, e.g. via mex --version signature), not just the name - or at minimum detect the collision and warn with the exact path conflict. Command output See the audit above for the reporter's exact output an

loadAllDependencies in src/drift/checkers/dependency.ts discovers manifests inconsistently, so a monorepo gets false DEPENDENCY_MISSING warnings depending on where a subproject sits and which ecosystem it is: manifest discovered? code ./package.json yes resolve(projectRoot, "package.json") ./backend/package.json yes globSync("*/package.json") ./api/backend/package.json no glob is one level only ./pyproject.toml yes resolve(projectRoot, "pyproject.toml") ./backend/pyproject.toml no never globbed To reproduce A project whose root package.json holds the frontend and whose Python service lives in backend/, with a stack doc claiming FastAPI and Celery: backend/pyproject.toml [project] name = "backend" dependencies = ["fastapi>=0.115", "celery[redis]==5.4.0"] DEPENDENCY_MISSING: Claimed dependency "fastapi" not found in any manifest DEPENDENCY_MISSING: Claimed dependency "celery" not found in any manifest Move the identical file to the repository root and both claim