feat(core-link): carry a Core-validated path so a Project can be moved after it is created

[qcentic-dev]

Split out of #98 / PR #103, which closed the half-save it caused but not the underlying gap.

What is missing

A Project's path is set by op: "create" and no project mutation op carries one afterwards. CoreLinkProjectMutation has rename, pin, settings, archive and now appearance — none of them a path. So a Core-owned Project's folder is immutable for the lifetime of the row.

What PR #103 did about it

Made the UI honest rather than pretending otherwise. The Edit-project dialog disables the Working directory field and drops Browse… for a Core-owned project (pathIsImmutable in ProjectDialog.tsx), and the missing-path dialog's advice branches on ownership — "point the project at its new location from Edit project" is only offered where the Panel owns the row. Recorded in ADR 0022.

That stops the silent discard. It does not give the operator the thing they wanted.

Why it matters

The case is real and not rare: a project folder gets moved or renamed on the Core, and the Panel's only remedy today is remove the project and add it again at the new path — which, because archive cascades, takes every Session under it with it. An operator loses their session history to fix a typo in a directory name.

The shape it probably wants

A path op on CoreLinkProjectMutation, validated Core-side by the existing validateProjectPath (absolute, resolvable, not a file) exactly as create already validates it — the Panel has no standing to judge a VM path — with its own project:pathChanged event kind, per the pin / settings / appearance precedent. Protocol minor bump; no migration (the column exists).

Open questions for whoever picks this up:

1. What happens to running Sessions under the project? Their PTYs have the old path as cwd. Refuse the move while any Session is live, or allow it and let existing PTYs keep the old cwd until they exit?
2. Worktrees and per-Session state keyed on the old path — is anything else on the Core storing a derived path that would need moving with it?
3. Does the missing-path dialog become the natural home for this? That is where an operator actually is when they discover the folder moved, and it already has the project in hand.

Acceptance

• Editing a Core-owned Project's Working directory works, and an invalid path comes back as the Core's own error rather than a Panel-side guess.
• Every Panel watching that Core converges on the new path, including after reconnect (event replay).
• Panel-local projects keep their current PATCH behaviour.
• The pathIsImmutable gate and the ownership-branched missing-path copy from fix(core-link): edit and remove a Core-owned Project through the Core that owns it #103 come back out.

[qcentic-dev]

This was generated by AI during triage.

Agent Brief

Category: enhancement
Summary: Carry a Core-validated path op on the project mutation frame so a Core-owned Project can be repointed after it is created.

Triage findings

The three open questions in the body are answered below and folded into the spec — they are decided, not open.

1. Running Sessions do not block the move. A Session row stores no path or cwd; cwd travels on the spawn frame and is checked only at spawn time against the live project roots. A running process's cwd follows a renamed directory at the OS level — verified directly: after mv, /proc/<pid>/cwd reports the new path. So a live Session is already in the right folder and the stale row is the only thing naming the old location. Refusing the move would force an operator to kill live work to repair a path, which is a smaller copy of the failure this issue exists to remove.
2. Nothing else on the Core stores a derived path. Worktree scoping was removed, and harness hook files are written inside the project folder, so they travel with it. The one real coupling is the harness's own transcript tree, which is keyed by cwd — see Out of scope.
3. The missing-path dialog needs no new affordance. Removing fix(core-link): edit and remove a Core-owned Project through the Core that owns it #103's ownership branch already restores "point the project at its new location from Edit project", which becomes true for both owners the moment this lands.

Current behavior

CoreLinkProjectMutation carries create, rename, archive, pin, settings and appearance. Only create accepts a path, so a Core-owned Project's folder is fixed for the lifetime of the row.

PR #103 made that honest rather than fixing it: the Edit-project dialog disables the Working directory field and drops Browse… for a Core-owned project, and the missing-path dialog branches on ownership to offer remove-and-add-again instead of repointing. Because archive cascades, an operator who renames a folder on the Core can only fix the row by removing the project — taking every Session under it along. Panel-owned rows are unaffected; their path is already patchable over the Panel's own HTTP route.

Desired behavior

A dedicated path op on the project mutation union, validated on the Core with the same rules create uses — non-empty, absolute per the Core's OS, exists, is a directory — and refused with the Core's own message when invalid. The Panel has no standing to judge a VM path.

A successful change appends a dedicated project:pathChanged event so every Panel watching that Core converges, including one that reconnects and replays. A mutation naming a row that does not exist appends nothing.

The Edit-project dialog's Working directory field and Browse… button become available for a Core-owned project, and the missing-path dialog's advice stops branching on ownership.

The move is permitted while Sessions under the project are running, with no liveness check in the write path.

Key interfaces

• CoreLinkProjectMutation — a new path op carrying the project id and the new path. A dedicated op following the pin / appearance precedent, not a widening of an existing op into a generic field patch; the reasoning in ADR 0017 and ADR 0022 for rejecting a generic updateProject applies here unchanged.
• validateProjectPath — reused as-is with the Core's OS-native probe. Its thrown message is what the operator reads, so it travels back on the ordinary error frame; there is no error code to switch on.
• The Core's project-mutation switch and its event-kind mapping — a successful path change appends project:pathChanged, mirroring how pin, settings and appearance earn their own kinds.
• The Panel's project-event kind filter — must learn project:pathChanged, or a Panel with the project list open will not refetch and will keep drawing the old folder.
• CORE_LINK_PROTOCOL_VERSION — minor bump (0.15.0 → 0.16.0). Under ADR 0005's major.minor rule a Core still on the old minor renders as needing update. No migration: the path column has been in the shared schema bootstrap since the fork.
• The Panel-side mutation router that splits Core-owned from Panel-local rows — settle on one contract and document it: the path op is Core-only, and a Panel-owned row keeps changing its path over the existing PATCH route. The helper that turns a field-carrying op into a PATCH body is typed to the ops that have one; do not widen it into a second way to move a Panel-local folder.

Acceptance criteria

• Editing a Core-owned Project's Working directory saves, and the new path is what every Panel watching that Core reads back
• An invalid path — relative, missing, or a regular file — is refused with the Core's own message, and the row is left unchanged
• A Panel that disconnects, misses a path change, and reconnects converges on the new path through event replay
• A path change while a Session under the project is running is accepted, and the running Session is neither killed nor interrupted
• A Session started after the move spawns in the new folder and passes the project-root check
• Panel-owned projects keep their current path-editing behaviour, over the same route as today
• The Edit dialog's path-immutability gate and the ownership branch in the missing-path copy are both removed, along with the tests that pin them
• The protocol minor is bumped and the new frame round-trips through the frame-parser tests

Documentation

• A new ADR records the decision: the Core validates, the op is dedicated, and the move is allowed while Sessions are live. Next free number is 0023 — note that two existing ADRs both claim 0018.
• ADR 0022's consequence stating that a Core-owned Project's path is immutable, and naming this issue as the real fix, is amended to point at the new ADR. Leaving it as written would make the ADR trail contradict the code.

Out of scope

• Transcripts and usage filed before a move. The harness keys its own per-session logs by cwd under its private directory. Sessions started before a move keep their history under the old key, and resume-from-transcript is not guaranteed across one. Do not re-key another tool's store.
• A dedicated "Move project" affordance in the missing-path dialog. Reverting the ownership branch is sufficient; a bespoke flow can be filed separately if it still feels thin in use.
• Any change to how archive cascades to Sessions. That cascade is what makes this issue urgent, but it is not what this issue changes.
• Worktree-derived state. Worktree scoping is gone and hook files live inside the project folder; there is nothing to migrate alongside the path.