# Divergences

What is not on `main`, and what on `main` is known to be wrong. Written so
that moving a bookmark does not quietly orphan work or hide a failure.

## Two lines, forked at `01104e7c`

`main` is not the only living line, and the other one is not behind it —
they are siblings:

```
◆ rruwvuzm  09-17  editor work: syntax, panes, modal, gui, fs, output
│ ◆ xqxpolmw 2b547e15  main  09-20  "Serve Unix and TCP 9P through cloud9.serve"
├─╯
◆ lsnxpxtq 01104e7c  09-16  "Add macOS backdrop blur and preserve PDF ink opacity"
```

* **`main`** carries the 9P work: the `cloud9.serve` runner, and now the
  posted-9P registry (`docs/cloud9.md`).
* **`rruwvuzm`** carries editor work — roughly 1300 lines across
  `src/syntax.zig`, `src/panes.zig`, `src/modal.zig`, `src/gui/gui.zig`,
  `src/fs.zig`, `src/pardes.zig`, `test/output.zig`, `docs/fs.md`. Reach it
  with `jj edit rruwvuzm`.

The fork matters for one concrete reason: **the cloud9 pin lives on `main`
only**. `rruwvuzm` still pins `ae310a20` (2026-09-14), `main` now pins
`9c4d668c`. Rebasing or merging the editor line will want the newer pin, or
`zig build` there fetches a cloud9 that predates `fs.Server`'s current shape.

## Other bookmarks

| bookmark | | |
|---|---|---|
| `reload-perf-wip` | 09-11 | unfinished: Reload presentation transport regression |
| `reload` | 09-10 | reload core code with shell-owned allocators |
| `reload-start` | 09-10 | names the Core/Shell seam, deferred Reload request |
| `ninep` | 08-27 | a 9P design note and a design registry to argue it in |
| `macos-fix` | 07-23 | |
| `full-prototype`, `term`, `tty-colors-mouse`, `vibes-ghostty`, `mouse` | 06-xx | older prototypes, also on the `vps` remote |

None of these are published to the FreeBSD mirror: only `main` is pushed
there, deliberately, because that box serves a public site.

## Known-failing on `main`, not caused by the 9P work

* **`zig build snap` fails `nested-optout`, and the cause is a real bug.**
  At the SECOND level of nesting -- a pardes whose shell runs a pardes whose
  shell runs a command -- two U+E016 codepoints are prepended to whatever is
  typed. U+E016 is 57366, which is vaxis's private-use spelling of **F3**
  (`Key.zig`, "kitty encodes these keys directly in the private use area"), so
  something in the chain is decoding a capability-query REPLY as a key and
  forwarding it to the shell as text. bash then sees
  `$'\356\200\226\356\200\226echo'` and answers `command not found`; with a
  path it answers `No such file or directory` for a path that exists and runs
  perfectly from the same shell a moment later.

  Minimal repro, in a snapshot script:

  ```
  dirmk innerdir
  file innerdir/deeper.txt deepest-marker\n
  start 31 100
  wait 8000 $
  stable 700 20000
  text (cd innerdir && $(readlink /proc/$PPID/exe) --nested)
  key enter
  wait 20000 cwd/innerdir
  stable 700 20000
  text E=$(readlink /proc/$PPID/exe); "$E" deeper.txt
  key enter
  settle 5000
  stable 700 10000
  snap probe
  ```

  `bash: E=/home/.../pardes: No such file or directory` -- bash did not even
  parse the assignment, because the line does not start where it looks like it
  starts. `--nested` is exactly the flag meant to opt a child out of this, so
  the fix belongs next to the key-forwarding path in `panes.Terminal.forwardKey`
  and whatever answers terminal capability queries on a nested stdin.

* **pardes does not start headless.** `pardes --9p=<name>` with no terminal
  exits 1 from the argument-forwarding path; the installed build fails
  earlier still, with `error.NoDevice` opening a terminal device. So the
  registry posting above is covered by unit tests
  (`zig build 9p-io-test`) rather than by running the editor.

## Upstream

`build.zig.zon` pins cloud9 `9c4d668c`. That commit exists because pinning
cloud9 `534c084f` here failed: cloud9's `build.zig` `@import`s each program's
build fragment, and `9harness` was missing from its `.paths`, so the
published package built from a checkout and not from a tarball. The pardes
build was the first consumer to notice.