ConnectOnion 1.9.0a15 (preview)

This preview fixes one first-run trust break in REM. The map announced a project count, but the later session-material pass could silently create more project pages before the first run finished. On an isolated private run of 1.9.0a14, the map listed 4 projects while the final notebook contained 13: 9 were created by that later pass. No private names or source text are in this release note.

co rem init now prepares session evidence only for projects already in its map. Unmatched session folders remain private candidates in .state/projects/index.json; they do not change the first-run project count or join its model-writing queue. co rem projects and the later daily discovery path keep their existing behavior. This is the first slice of #2079, not a claim that all project detection, privacy or page-quality issues are fixed.

Evidence

An invented notebook with one mapped project and one later-discovered folder shows the old two-row Projects directory and the new one-row directory at desktop and phone widths. The changed path has a regression test that checks the first-run selection, unchanged page count and retained candidate. Relevant first-run, project and CLI tests pass. The screenshots use invented data; no private reader screenshot is published.

An installed 1.9.0a15 wheel was also run against an isolated private five-day notebook. It exited successfully: the map listed 3 projects, the final notebook still had 3 project files, one selected project page was accepted, and material extraction created 0 additional pages. It retained 122 unmapped session-folder candidates, including older folders. These are aggregate counts, not a review of whether every candidate represents a real project. The owner's page also completed and the init result reported no source errors.

Remaining work

The map can still miss a legitimate workspace-attributed project. The private candidate list has no reader review flow or useful ranking, and the daily discovery policy is separate. REM is still a preview: a bounded overnight pass, verified morning changes, owner correction, useful retrieval and durable recall all need their full product acceptance checks before a stable 1.9.0 release.