What replaces the file watcher and live reload

[stueydubs]

Question

The reconcile loop is visible today because the server watches the served tree and pushes reloads over SSE. Without a server, what makes a reconcile land in front of the user?

This is not a nicety. CONTEXT.md records why it was built: reconcile happens in another window, and before live reload the user saved and then had no signal at all until they reloaded by hand. The reconcile badge reflects the edits file's own view (N pending until Claude flips the Batch to reconciled), which requires noticing that the edits file changed on disk.

Resolve:

• Whether the browser can observe changes to a granted directory at all, or whether polling is the only option.
• If polling, what to poll and how often. Note that this collides with #11: a poll that walks the Project is a per-interval cost at exactly the scale that ticket is testing. The old server capped watching at MAX_WATCHED_DIRS and MAX_WATCH_DEPTH and degraded to a startup note, so "files being watched" was already a smaller set than "pages in the Project".
• Whether the three reload safety rules survive, and how each is enforced without a server:
  1. A reload never runs over unsaved edits (guarded on dirty, not on "has edits").
  2. webtweak's own writes are excluded, or every Save bounces the page being edited. The server recognised its own write by comparing the exact bytes it had written.
  3. A reload never runs while this session's Batch is still pending. This one is a cross-component ordering coupling with reconcile, which writes source first and marks the Batch second. If it breaks, the Overlay re-applies a patch on top of already-reconciled source and doubles a nudge, silently.
• Whether the edits file still needs its own change signal separate from the source tree, as it does today, so the badge can reach reconciled.
• What the degraded mode is. The server's rule was to degrade to no live reload, never to a crash.

Blocked by #19, which establishes whether any change-notification capability exists.

[stueydubs]

Constrained by a decision on the map

Settled 2026-08-03: Firefox and Safari are supported at reduced fidelity, never at parity.

That partly answers this ticket before it is worked, and the answer is unwelcome. webkitdirectory yields a one-shot snapshot with no live handle, so in Firefox and Safari there is no way to observe the folder changing at all - not by watching, not by polling. The reconcile loop there ends with the user re-opening the folder by hand.

So this ticket is really two questions now, and they should not be answered together:

1. Chromium, where a retained directory handle exists and polling is at least possible. The three reload safety rules in the ticket body all apply here, including the cross-component ordering coupling with reconcile, which is the subtle one.
2. Everywhere else, where the honest answer is a manual re-open, and the design question is how to make that obvious rather than how to avoid it. The reconcile badge's N pending state may be the wrong shape for a session that cannot see the file flip to reconciled.

The old server's principle still applies to both: degrade to no live reload, never to a crash.