Every change to the unpacked extension (content.js, driver-plan.js, background.js) needs a human click on chrome://extensions → reload, and nobody else can do it: chrome:// pages are off-limits to any extension, and the daemon has no handle on Chrome. Every dogfood of a bridge change went through that click (#1703, #1709, #1710).
An extension can reload itself: chrome.runtime.reload() re-reads an unpacked extension's files from disk, the same as the button. What is missing is the trigger — something has to notice the files changed. Options:
- The worker watches its own files. Each alarm beat (30 s) it fetches
chrome.runtime.getURL('content.js') and the other scripts, hashes the text, compares with the hash taken at worker start; a difference → chrome.runtime.reload(). No daemon involvement, ~20 lines. To spike first: whether that fetch returns the current disk file for an unpacked extension or a cached copy.
- The daemon says so. The worker already calls the daemon every beat and already compares a
version field (0.12.0 expected). The daemon would serve a fingerprint of packages/chrome-extension/ and the worker reload on a mismatch. Cleaner semantically ("the checkout moved"), but the daemon runs from dist/ and would need to know where the checkout is.
- A dev-only watcher process (
web-ext run style, or the "Extensions Reloader" pattern): a separate process on the developing machine only.
After the reload, the existing path takes over: the Driver tab gets the new content script on its next page load (≤ 1 minute), as it does after a manual reload today.
"Update" in the Web Store sense does not apply: the extension is unpacked and dogfood-only; the store's auto-update covers it once published.
Recommendation: option 1 behind the spike; option 2 if the fetch turns out to be cached.
🤖 automated · Fable 5, effort high
Every change to the unpacked extension (
content.js,driver-plan.js,background.js) needs a human click on chrome://extensions → reload, and nobody else can do it:chrome://pages are off-limits to any extension, and the daemon has no handle on Chrome. Every dogfood of a bridge change went through that click (#1703, #1709, #1710).An extension can reload itself:
chrome.runtime.reload()re-reads an unpacked extension's files from disk, the same as the button. What is missing is the trigger — something has to notice the files changed. Options:chrome.runtime.getURL('content.js')and the other scripts, hashes the text, compares with the hash taken at worker start; a difference →chrome.runtime.reload(). No daemon involvement, ~20 lines. To spike first: whether that fetch returns the current disk file for an unpacked extension or a cached copy.versionfield (0.12.0 expected). The daemon would serve a fingerprint ofpackages/chrome-extension/and the worker reload on a mismatch. Cleaner semantically ("the checkout moved"), but the daemon runs fromdist/and would need to know where the checkout is.web-ext runstyle, or the "Extensions Reloader" pattern): a separate process on the developing machine only.After the reload, the existing path takes over: the Driver tab gets the new content script on its next page load (≤ 1 minute), as it does after a manual reload today.
"Update" in the Web Store sense does not apply: the extension is unpacked and dogfood-only; the store's auto-update covers it once published.
Recommendation: option 1 behind the spike; option 2 if the fetch turns out to be cached.
🤖 automated · Fable 5, effort high