Generating a WorkMap
A model can draw the map for a project that already exists, and keep it up to date as you work. You can see what a generation is likely to cost before it runs.
The onboarding dialog
When you open a folder that is a git repository and has no WorkMap yet, the app asks once, Create the WorkMap diagram for this project? The dialog says what it will read, which is the git history, the README and the top level files, and names the model that will draft the map.
- Generate starts the run. The dialog shows each stage as it happens, from reading the history to compiling the diagram. Hide puts the dialog away while the run carries on, and the diagram loads when it is ready.
- Not now records your answer, and the app does not ask again for that project. The close button, Escape or a click outside the dialog only dismisses it, so the app can ask again next time.
The Maintain WorkMaps for new projects row in Settings > WorkMap decides what happens.
| Choice | What happens |
|---|---|
| Ask | The default. A new project is offered a map through the dialog, and nothing else starts one. |
| Always | The dialog is offered the same way. A project without a map also gets a small one started from its first prompt, as described below. |
| Never | No dialog, and no map is started for you. |
A project that already has a map is kept up to date under all three.
Generating from the WorkMap window
The head of the WorkMap window has a button whose label depends on what is loaded.
| Button | What it does |
|---|---|
| Generate from repo | Shown while the project has no map of its own and the window is empty. Draws this project's own map from its repository. |
| Complete with AI | Shown when the project has its own map. Keeps your wording and every entry where it is, fixes grammar and commit links that point at the wrong requirement, then adds what the repository supports. |
| Regenerate | Shown beside Complete with AI. Builds the map again from the repository and replaces the current one. |
While a run is going the button reads Working…, and it names the attempt when the run is retrying. If a run cannot start or fails, the reason shows in the window head.
The estimate
Hover Generate from repo or Regenerate to see what the run is likely to cost before you click. The card names the fallback model the estimate is for. Under ESTIMATED it gives a range of tokens and a range of the five hour usage window, from a likely figure up to a high one.
After a generation finishes, the card also shows USED with what the run actually took, and the window head shows the estimate and the actual spend side by side.
The estimate reads unavailable for a folder that is not a git repository, and when the forecasting service is not running. Hovering again tries again.
What the model is given
A generation reads evidence from the repository only. That is the git log with each commit's subject, date and changed files, the README, the list of top level files, and the main manifest files such as package.json or Cargo.toml. The features come from what the project does, not from reading every source file.
A project made of several repositories is read as a whole. The app reads the project's own repository, then every repository nested up to two levels inside it, each as its own section, with one commit list across all of them.
The result is checked before anything is drawn. A draft that does not compile goes back to the model with the errors, up to two more times. If it still fails, the run reports the failure and the diagram on screen stays exactly as it was.
Keeping the map current
Once a project has its own map, two things keep it up to date without you asking.
- After work lands. When an automatic commit is not tied to a requirement, the fallback model records it with the smallest change that fits. Usually that is one new requirement, already shipped and linked to the commit, on the feature that owns that part of the project. Sometimes it is a status change, or a new feature when the work started one.
- When you ask for something new. The first prompt a terminal sends is read once. Work that has not landed yet is added as open requirements in the place that fits best, and the terminal is bound to what was added, so its commits are filed there. A question, a chat or some exploring adds nothing. A request that undoes earlier work marks that work deprecated.
Both run in the background. The terminal never waits for them, and if one fails nothing changes. A prompt sent with a requirement already picked, for example from a play control on the map, is already placed and is not read again.
Under Always, a project with no map at all gets one from that first prompt. The model draws the smallest map that covers the request, instead of mapping the whole codebase.
The model and where maps live
All of these runs use the Fallback model row in Settings > AI Providers, which the app describes as the model for background tasks and managing work. Each provider has its own fallback model, and the one for your default provider is the one used. The runs can read your project but never change it.
Each run uses the setting as it was when the run started. Changing it affects the next run, never one already going.
Maps are kept in the app's data folder, outside your project, one per project. Edits you make in the diagram are saved there.