relayfile CLI: writeback is create-only — no delete/update path for existing records (+ push reports false success)

[khaliqgant]

Summary

The relayfile CLI/mount writeback surface can only create records. There's no way to delete or update an existing provider record (e.g. bulk-delete test Linear issues, or change an issue's labels/state/project) through the file-native path. This blocks any cleanup/reorganization workflow and forces a fallback to the provider API.

Surfaced while trying to clean up the Linear AR backlog (delete ~74 test/canary issues, relabel/regroup ~88 real ones) entirely via relayfile.

Current writeback surface

relayfile writeback {list, push, status, retry, skip-stuck, sweep-drafts}. push takes a LOCAL_PATH and creates a draft only. No delete, no update.

Gaps

1. No delete (file_delete) from the CLI

The cloud writeback provider supports file_delete → issueDelete (Linear), but the CLI exposes no way to trigger it. There is no relayfile writeback delete <remote-path> and no rm. (relayfile workspace delete is unrelated — it removes a locally-tracked workspace.) So an agent can create a Linear issue but cannot delete one.

2. No update path from the CLI

update_issue → issueUpdate exists server-side, but the mount/CLI can only flush create-drafts. There's no way to push an update that sets labels/state/project on an existing record. (Adapter-side counterpart filed as relayfile-adapters#200.)

3. writeback push reports false success

For self-contained drafts the bulk write returns no opId, so dispatchStatus falls through to the hardcoded default "succeeded" (cmd/relayfile-cli/main.go:3031) — it's only overwritten with a real op status when opId != "". Result: push prints status: acked, dispatchStatus: succeeded even when the writeback later permanent_failures server-side. This actively misled debugging (we believed a Slack/Linear writeback delivered when it had dead-lettered). It should require/poll a real opId, or clearly mark the result as "staged, delivery unconfirmed."

Proposed

1. relayfile writeback delete <remote-path> [--workspace WS] [--json] → emit a file_delete writeback (provider record delete).
2. A CLI update path — e.g. writeback push against an existing record path, or writeback update — to flush update mutations (labels/state/project) on existing records.
3. Fix the false-success: don't print succeeded for a push that only staged a draft with no dispatch opId; surface the async terminal status (or pending/needs-attention).
4. (Related) expose /linear/projects and /linear/labels as resolvable resources so updates can reference them — see relayfile-adapters#200.

Impact

Without delete/update, relayfile can seed records but can't maintain or clean them up; bulk org/cleanup has to bypass relayfile and hit the provider API directly.

Refs

• Adapter counterpart (projects/labels not writable/resolvable): relayfile-adapters#200
• Cloud producer junk-enqueue (separate): AgentWorkforce/cloud#2205
• False-success origin: cmd/relayfile-cli/main.go:3030-3070

Found 2026-06-16 during Linear backlog cleanup.