# Conversation config is resolved before the lock and never re-read after a wait

- **Status**: Todo
- **Kind**: Bug
- **Authors**: jp
- **Date**: 2026-08-31
- **Label**: domain=conversation
- **Label**: package=jp_cli
- **Label**: package=jp_config
- **Label**: type=bug

## What happens

The per-conversation config layer is resolved during bootstrap, before any
command acquires a conversation lock.
A command that then waits for the flock runs with config that predates whatever
the lock holder recorded while it waited.

`jp_cli/src/lib.rs:948-967` is phase 2 of the config pipeline: it eager-loads
the conversation (`eager_load_conversation`, line 951), folds the stream's
config deltas into the partial, and hands the result to
`ConfigPipeline::partial_with_conversation`.
Every command that resolves conversation config goes through this, and it
happens well before `acquire_lock`.

So if the lock holder appends a config delta during its turn — a model change,
a tool toggle, a compaction rule — the waiting command's `ctx.config()` does
not see it.

## Severity

This is wrong-config, not data loss.
`Workspace::lock_conversation` re-reads the event stream and the write
projection at acquisition, so the *stream* the command mutates is current; only
the resolved `AppConfig` derived from it is stale.

Visible effects depend on the command: `jp c compact` could summarize with the
model the conversation had before the other process switched it, or apply
compaction rules the conversation no longer configures.
The stale config is not persisted as a delta, so the damage is confined to the
waiting command's own run.

## Why it is not a small fix

The config pipeline runs once, before the command's `run` is called, and its
output is threaded through `Ctx`.
Re-resolving after lock acquisition means either:

- re-running phase 2 and phase 3 from inside the command, once the lock is held
  (each command would need to opt in, and `Ctx::config` would need to become
  replaceable), or
- moving lock acquisition ahead of config resolution for commands that write,
  which reorders bootstrap and changes when contention prompts appear relative
  to config errors.

Both are structural.
Worth checking against RFD 074 (Eager Loading with Command-Declared Data
Requirements), which already proposes declaring per-command data needs up front
and would give the ordering a natural home.

## Origin

Noticed while fixing the stale-event-stream data loss in #1045
(`Workspace::lock_conversation` now re-reads metadata, events, and the write
projection once the flock is held).
The config layer is the remaining thing read before the lock and not refreshed
after it.