# The nine projects that arrived after the map

REM had already told its owner what it found. A first run mapped four projects,
printed that count, and then started gathering the owner's coding-session
messages so it could write the selected pages. By the end of a private trial,
the notebook contained thirteen project files. Nine had appeared after the
map's answer.

The extra files were not a display bug. A second discovery path lived inside
the session-material extractor. It looked for recently active folders without
a project page and created one before selecting the first-run writing queue.
That path helps a later daily pass notice new work. During init it meant the
owner's first count was provisional without saying so, and a folder the map
had never listed could enter the experience as a project.

We kept the extraction: mapped projects still need the owner's own messages
to become useful pages. We changed what extraction may do at that moment.
During the first run, an unmatched folder stays in a private candidate list;
it cannot silently add a page after the map has been shown. In a small
invented notebook, the old path turned one mapped project into a two-row
Projects directory. The new path keeps one row and retains the other folder
for later review. The same result appears at desktop and phone widths.

This narrows one trust gap, but it also exposes another. A legitimate project
that the map misses will not be written in the first run just because a
session mentions its folder. REM needs a deliberate way to review those
candidates and improve attribution. The owner should be able to see why a
project is in the notebook before REM presents it as something remembered.