Jean-Pierre

Appearance

View Markdown

Inherit config across workspaces ​

  • Status: Todo
  • Kind: Feature
  • Authors: jp
  • Date: 2026-08-19
  • Label: package=jp_config
  • Label: type=feature

A workspace cannot reuse another workspace's configuration. This ticket records the problem and a rough direction; the design is worth arguing properly, so it should be promoted to an RFD before implementation.

Problem ​

The moment a directory gains its own .jp/, find_root stops there and it is a standalone workspace. It inherits nothing from the workspace it sits inside, or from any other workspace.

So a second workspace needs its own copies of everything worth sharing: tool configuration, personas, skills, knowledge sections, model definitions, render style. Copies drift, and the drift is silent — the second workspace simply behaves like an older version of the first.

This is separate from [RFD 035] (multi-root load path resolution, which is about where --cfg looks for named entries within one workspace) and from [RFD D38] (which is about anchoring a single extends path at a named config root). Neither addresses one workspace inheriting another's config as a whole.

Rough direction ​

An extends-like mechanism that crosses the workspace boundary, so a workspace's .jp/config.toml can declare "start from that workspace's config, then override". Open questions that make this RFD-shaped rather than ticket-shaped:

  • What is the unit of inheritance? Whole config, or named entries only?
  • How is the parent identified — path, workspace id, or something stable across machines?
  • What happens when the parent is unavailable (moved, deleted, different machine)? Hard error, or degrade with a warning?
  • Does inheritance compose transitively, and how are cycles handled?
  • How does this interact with the four implicit sources and their precedence ([RFD 079])?
  • [RFD D38] — root-qualified extends paths. Solves the narrow case of addressing one file in another root; this ticket is the general case.
  • [RFD 046] — nested workspace projection.

Next step ​

Promote to an RFD. The problem is real and recurring, but the answer is a design argument, not an implementation.