Let a conversation field track the workspace config

Todo2026-09-07jp

type: feature

A conversation pins its configuration: workspace edits and JP upgrades leave it resolving exactly as it did when it was created. That is deliberate, and --cfg WORKSPACE is the explicit way to move a conversation onto current workspace config.

What is missing is the same choice at field granularity. There is no way to say "stop pinning assistant.model.id for this conversation, follow whatever the workspace says from now on" while leaving every other field pinned.

Why the existing spellings do not cover it

--cfg foo.bar=null clears a field. null is a value in the config language, so it means "no value" wherever it appears, including in a config file that has no conversation to track. The field resolves to the program default, not to the workspace.

-C foo.bar=VALUE (RFD 070) reverts to a previous claimed state. That is a point in history, not a subscription: it answers "undo this assignment", and the answer stops moving once it is given.

Both are one-time operations on a stored value. Tracking is a standing instruction, which nothing in the model currently expresses.

Why it cannot be built yet

A conversation stores a resolved AppConfig and a list of deltas. Nothing in it distinguishes "this value came from the workspace" from "I set this deliberately", so there is no state to return a field to.

RFD 070 introduces that distinction: base becomes the resolved workspace configuration and init carries the creating invocation's contributions with provenance. Once a field's origin is recorded, "follow the workspace" has something to mean.

Even then, base is a snapshot taken at creation, so tracking needs a further step: a field marked as tracking has to be resolved against the workspace files at read time rather than against the stored base.

Open questions

• How is it spelled? A keyword value (foo.bar=inherit) reuses the config language but reintroduces a value whose meaning depends on conversation history, which is what keeps null simple. A directive (--track foo.bar) keeps that separation at the cost of another flag.
• Does a tracked field survive a fork, or does the fork re-pin it?
• What does jp conversation print show for a turn whose tracked field has since changed in the workspace? The conversation records what its turns ran under, and a tracked field deliberately breaks that.
• Does tracking apply to a whole subtree (--track style), or leaves only?
• How does a tracked field interact with -C, which walks a history the tracked field is no longer part of?

Related

• RFD 070 Negative Config Deltas: introduces the base / init split this depends on, and the claim provenance that makes a field's origin knowable.
• RFD 038 Config Reset Keywords: WORKSPACE is the whole-config version of this, and whatever spelling this lands on should read as its per-field sibling.

Next step

Blocked on RFD 070 Phase 3. Revisit once base and init exist, since the answer depends on what provenance is actually recorded.