[Feature] Project-scoped continual harness (per-project global state)

[Bonobo791]

Area

Agent core, Coding agent and CLI

Problem

What I'm trying to do: Keep durable, project-specific agent knowledge (build quirks, env-var conventions, dev-server diagnostics, deployment notes) attached to the project it belongs to, so it's available in future sessions
for that project and invisible elsewhere.

What's difficult today: The continual harness has only two scopes — local (a per-session file) and global (one machine-wide file at ~/.prime/agent/harness/harness_state.json). There is no project dimension:

• Every global entry is injected into every session's prompt, regardless of project. HarnessEntry.path exists (default "general") but is display-only metadata — nothing filters on it. Prompt assembly does
  mergeHarnessStates(loadHarnessState(globalDir), loadHarnessState(localDir)) and formats all entries (capped at 6/kind, 180 chars).
• A single agent install serves many projects, so one project's lessons crowd out the context (and the 6-per-kind overview cap) of unrelated sessions.
• RLM_GLOBAL_HARNESS_STATE_DIR is set by the host from getGlobalHarnessStateDir() and the host reads that same path directly for prompt assembly/refinement, so pointing it at a per-project dir from outside splits CRUD writes
  from what the host actually loads (split-brain).
• The refine planner is only told to name the project ("may be persisted globally only when the title, path, or content explicitly names the project/workspace") but nothing enforces it — applyRefinementProposal defaults to
  path: edit.path ?? before?.path ?? "general".
• Nothing auto-detects the project from the session cwd/git root; kernel CRUD defaults path to "general".

Net effect: the only way to get project-scoped global state today is a manual convention (pass path="" on every entry, rely on the model to route by relevance). That is not isolation, and nothing enforces or verifies
it.

Proposed direction

Treat the existing path field as a project key and filter on it end-to-end:

1. Project identity — derive automatically from the session: basename of the git work-tree root (git rev-parse --show-toplevel), fallback to cwd basename; expose to the kernel via an env var (e.g. RLM_PROJECT_NAME) and to the
   host via the session manager (which already knows cwd). Allow an explicit per-session override for repos whose basename isn't the desired key.
2. Storage — keep one global file (simplest migration): path: "general" = cross-project (always injected); path: "" = injected only into sessions whose project matches.
3. Prompt injection filter — in _loadMergedHarnessState()/formatHarnessStateForPrompt(): include global entries where path === "general" or path === currentProject; keep the per-kind cap; add a show-all-projects overview
   option for auditing.
4. Refinement — include currentProject in the refine planner's context so it can tag edits without guessing from the trajectory; make applyRefinementProposal project-aware (path: edit.path ?? detectedProject ?? "general");
   optionally flag project-looking content created without a path.
5. CRUD API — HarnessState gains a project (default auto-detected); create_* keeps path=; when omitted, default path=project for local scope and "general" for global scope (so a cross-project lesson isn't silently tagged);
   preserve update()'s preserve-on-None semantics; ship a retag/backfill helper for existing entries.
6. Documentation — update the system-prompt harness section to describe project scoping.

Expected experience: an entry created with path="project-a" shows up in project A sessions and never appears in project B sessions' prompts or refine-planner context; path="general" entries keep today's behavior; the same
project value is used by kernel CRUD, host prompt assembly, and the refine planner (no split-brain); refine.run() tags entries automatically with no extra prompting.

Alternatives considered

1. Per-project harness files (~/.prime/agent/harness/projects//harness_state.json, general at the top level). Harder isolation, but needs a second read/merge path and a migration; chose single-file + filtering as the
   smaller change. Happy to go this route if the team prefers filesystem isolation.
2. Env-var override only — pointing RLM_GLOBAL_HARNESS_STATE_DIR at a per-project dir from the shell. Rejected because the host sets that variable itself and reads getGlobalHarnessStateDir() directly for prompt assembly, so
   writes and reads diverge (split-brain) unless the host is also made env-aware.
3. Manual path= convention + model routing (current workaround). Works but is unenforced, invisible to prompt filtering, and still pollutes other projects' context up to the overview cap.
4. Stopgap patch (what I did locally): patched rlm/harness.py so path auto-fills from the git root when omitted, plus a global prompt note telling the refine planner to emit path. This makes tagging automatic on the CRUD side
   and nudges refinement, but it does not give isolation — host injection still shows everything, and the venv patch is lost on package reinstall.

Additional context

• Exact locations: rlm/harness.py (HarnessScope, HarnessEntry.path, state_file(), create()/upsert()/create*() defaults); host bundle (getGlobalHarnessStateDir(), _loadMergedHarnessState()/mergeHarnessStates(),
  formatHarnessStateForPrompt() with DEFAULT_OVERVIEW_ENTRY_LIMIT = 6 and DEFAULT_OVERVIEW_CONTENT_LIMIT = 180, applyRefinementProposal(), refine-planner system prompt).
• Real-world example: in this session I diagnosed a TinaCMS dev-server failure in the my the-lippincott-team repo (root-owned node_modules → EACCES on the admin Vite cache, port-9000 collision). That lesson is gold for
  future sessions in that repo and noise everywhere else — exactly the case this feature targets.
• Follow-up (low priority, same key): per-project skill visibility — only load Python skills tagged for the current project.