Backlog: Andy's five ideas as P1-P5 after F2-F5, with the decisions agreed 28fee1c9eb6c

- [ ] P1 **Conflict resolution on OxygenHub** (Andy's list, item 1). A resolver page for a conflicted state:

  - Per conflict region: pick a side, several sides, or none; edit freely; tree conflicts too (keep a candidate).

  - Commit the result as a `kind = resolution` change on the bookmark, through the web-edit path. Signing: sealed when the author next pushes, or "resolve in VS Code" hands off to oxygen-vscode.

  - Shareable link to a conflict.

  - First single-user, then P1b.

- [ ] P1b Real-time collaboration on the resolver: presence, live edits merged between viewers (SSE or WebSocket), and whoever is viewing sees the resolution land.

- [ ] P2 **Function history** (item 5; needs no semantic-deps):

  - oxy-core: a history query over a set of atoms (the changes that inserted or deleted any of them, with deleted atoms included).

  - Hub: function boundaries by tree-sitter for the languages we host (Rust, TypeScript, Python, shell).

  - Clicking a function on a file page shows every ChangeId that touched its lines, as a list and a small graph; exact because atoms keep identity across edits and moves.

  - The cross-file semantic graph stays out; noted as future work.

- [ ] P3 **Swimlanes** (item 3):

  - Hub: a bookmark's changes drawn as lanes of independent changes (oxy-core `lanes`), with dependencies as edges and no merge nodes.

  - P3b: drag and drop on proposal bookmarks only. Dropping a change onto another proposes a squash, dragging a dependent chain proposes a rebase. The hub produces a plan and the author's oxy or oxygen-vscode applies and signs it (V6 has split, squash and rebase). Reordering independent changes means nothing and is not offered.

- [ ] P4 **Signed Flow receipts**:

  - A `receipt` object type in the Oxygen spec.

  - A runner identity whose key (composite Ed25519 + ML-DSA-65) signs each receipt.

  - Receipts stored in the repository and verified by the hub.

  - Flow `output` and artifacts, so a release asset links to the receipt that built it.

- [ ] P4b **Trust dashboard** (item 4): per release and asset, a graph of authors' identities and signatures, the runner and its pinned environment, inputs (state, scope hash), and receipts, with a one-click audit view and export.

- [ ] P5 **Web workspaces** (item 2), in parts:

  - P5a: flow-casfs, a read-only FUSE mount of a state from CAS chunks, measured.

  - P5b: "Open in Workspace" on a change. openvscode-server (MIT, unmodified) with oxygen-vscode inside a Firecracker microVM per workspace, the state mounted read-only through casfs with an ephemeral overlay for edits, and commits back through oxy. Boot time measured, aiming under 100 ms for the mount.

  - A fork ("oxycode") only if an extension cannot do what we need; decided with Andy.

- [ ] P5c Import microsoft/vscode's full Git history with `oxy git import` into a local scratch repository (not published): about 130 000 commits as a stress test of import, log, blame and status at scale, recorded in docs/benchmarks.md.

- 2026-09-28 Andy agreed the order for his five ideas: F2–F5 first, then conflict resolution (P1, P1b), function history (P2), swimlanes (P3), signed receipts and the trust dashboard (P4, P4b), then web workspaces (P5, P5c).

  - Decisions from the discussion:

    - Web workspaces start from openvscode-server unmodified, not a VS Code fork.

    - Hub-side history rewrites are plans applied and signed by the author's client, only on proposal bookmarks.

    - Function history uses atom identity rather than the semantic-deps hook.

  - Andy asked the loop to carry straight through all of it.