diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-09-13 21:55:08 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-09-13 21:55:08 +0200 |
| commit | 532d762678e0eda7ac08fcc6a361069114f12d79 (patch) | |
| tree | a78424551d48eb5ef8a7612d31cd01c15b995a53 /CLAUDE.md | |
| parent | 5d9b2c03fb6bdd28e4c233a35005c709cdd3760c (diff) | |
| download | meshbay-532d762678e0eda7ac08fcc6a361069114f12d79.tar.gz | |
docs: what this week's review left open, and a harness that lies
§15.3 gains the items the review found and did not close, each as what it is
rather than as a plan: the packaged install that has never been installed, QUIC
serving content outside every cap it does not implement, a relay registry
nothing calls, an unmetered third-party search, disk I/O on the node's event
loop, unbounded node announcements, and a migration chain exercised on a
database it does not ship on.
They are in the design rather than in a tracker because each is a sentence about
what the system currently is, and §15.3 is where the document already keeps
those. The seven that were closed this week are in §13.5b as AV20–AV25 and in
the sections they belong to.
CLAUDE.md gains the Firefox harness, which is the other kind of entry: eleven
errors at setup that look exactly like a regression, are not, and cost a full
diagnosis to place. `HOME` isolates the profile and not snap's single instance,
so any running Firefox blocks the headless probe, `--no-remote` and
`--new-instance` do not help, and a failed run leaves a process that blocks the
next. The chrome half covers the same geometry meanwhile.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UMxEQadpzPkYLFf5CYKhpW
Diffstat (limited to 'CLAUDE.md')
| -rw-r--r-- | CLAUDE.md | 12 |
1 files changed, 12 insertions, 0 deletions
@@ -144,6 +144,18 @@ These are about working on the tree rather than about the design: - **The SPA served in production may be older than this tree.** Check the served `/a/<hash>/` against `meshbay_hub.api.webapp.ASSET_V` before concluding a fix is missing. `site/` and the Caddy config have never been deployed +- **`test_sticky_header.py[firefox]` needs no Firefox instance on the machine, + and says nothing about the code when one is there.** The harness launches + `firefox --headless --screenshot` with `HOME` pointed at a throwaway + directory, which isolates the *profile* and not snap's single instance: with + any Firefox already up it prints "Firefox is already running, but is not + responding", never loads the page, and the fixture times out at 60 s — eleven + errors at setup that look like a regression and are not. Neither + `--no-remote` nor `--new-instance` changes it; a failed run also appears to + leave a process behind, which blocks the next one. Before reading anything + into these: `ps -eo pid,etimes,args | grep firefox`, and re-run against a + stashed tree. The `[chrome]` half of the same file covers the same geometry + and is the one to trust meanwhile - **One UI source.** `packages/meshbay-hub/src/meshbay_hub/static/` is the interface, for the web and the app alike; `packages/meshbay-client/scripts/ sync-ui.js` copies it (`npm run sync-ui`) and CI fails if the copy drifts — |