# classify workspace load side effects

- **Status**: Todo
- **Kind**: Chore
- **Authors**: Jean Mertz
- **Date**: 2026-08-12
- **Label**: package=jp_workspace
- **Label**: type=task

Opening a workspace mutates it.
`load_workspace` in `jp_cli` currently performs, on every command that touches a
workspace:

- user-workspace directory creation, sibling merge, and the one-time durable
  conversation import (`with_user_storage`, RFD 031),
- the legacy `storage` symlink migration,
- a roots-registry recency upsert (`upsert_root`, RFD 087),
- a write of the workspace ID (`Workspace::id().store()`), which mints a fresh
  random ID when the stored one is unreadable.

None of these go through the persist backend, so `--no-persist` does not
suppress them.

RFD 087 introduced `LoadIntent::{Run, Inspect}` to stop `jp w show` from
reordering `l` / `latest` recency merely by reporting on a workspace.
That fixed one command by declaring it writes nothing at all.
It did not answer the general question, which is what this ticket is for:

**Which of these mutations are properties of running `jp` at all, and which
belong to specific commands?**

The two ends are clear and the middle is not.
A recency upsert plainly belongs to commands that use a workspace, not to ones
that describe it.
Repairing corrupt on-disk state plausibly belongs to any invocation that touches
the directory — but "repair" needs a careful definition first: minting a
default ID for an unreadable one *changes the workspace's identity*, which
breaks `roots::is_live` matching and silently detaches every registry entry and
session selection pointing at it.
That is closer to re-initialization than to repair.

Commands to consider once the rule exists:

- `jp c show`, `jp c ls`, `jp c print`, `jp config show` — read-only in intent,
  currently taking the full `Run` path.
- `jp w show` — already `Inspect`; check the taxonomy agrees with that choice
  rather than grandfathering it.
- The `--no-persist` contract: today it swaps the persist and lock backends but
  leaves workspace-setup writes untouched.
  Whether that is the intended boundary is part of the same question.

Deliverable: an RFD fixing the taxonomy and the vocabulary for it, then the
mechanical follow-up of tagging each command.
The `LoadIntent` enum is a starting point, not necessarily the final shape — a
two-value split may be too coarse once "always repair, never re-identify" is in
scope.

Context: PR #866 review threads on `crates/jp_cli/src/cmd/workspace/show.rs`,
where this was raised and explicitly deferred.