meshbay.git/packages/meshbay-hub/tests/harness/group_tab_probe.py, branch 0.13

refactor(mnp)!: one answer to "may this member write", and it is the root

2026-09-10T15:23:40Z

The group-wide `member_upload` switch is gone: the message, the signed operation, the field on the handshake ack, the `upload` alias on every root in the index payload, and the client's fallback path to it. Whether a member may write has been a property of each root for a while, and that is the model that survives: a single flag over the group cannot express "this library is published read-only and that folder is a drop box", which is the ordinary arrangement. What was left of the switch was a handler that logged a deprecation and acted on nothing, and a client that read `ack.member_upload` whenever the roots carried no `writable` — a second source for one question, with whichever the code consulted first deciding it. `roots.describe()` drops `upload` for the same reason: it was `writable` under an older name, and two names for one boolean is one too many. The paperclip now says "nowhere to write" rather than picking a root, in a group that has none writable. That is the honest answer; the fallback picked whatever came first and failed at send time. Node suite 1215 passed. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01AsoWC3GmhNdwVFomW3QjH3

test(hub): stop the Chrome profile cleanup racing its own children

2026-09-08T11:21:02Z

`terminate()` signals the parent only. Chrome's zygote, renderer and gpu children outlive it by a moment and go on writing into the profile, so rmtree walked a directory that gained a file between its readdir and its rmdir and raised "Directory not empty". The probe exited non-zero, and every test in the file errored at setup — intermittently, roughly one run in three, for a reason nowhere near the chat code they were testing. TemporaryDirectory(ignore_cleanup_errors=True) in all four probes that own a profile: a few bytes left in a throwaway directory are harmless, failing the run is not. `proc.wait()` after `kill()` was also missing — a killed process still has to be reaped. layout_probe.py never cleaned up at all (mkdtemp, no removal) and never waited for Chrome; it leaked a profile into /tmp on every run. Ten consecutive runs of test_chat_send.py are clean. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01HCGdheDLxGReuKHga3BtST

fix(hub): fall back to the group's first app when the landing tab is absent

2026-09-01T22:38:27Z

A group could open on a tab that rendered nothing: no panel, no tab shown active, and nothing on screen to explain it. The landing tab is chosen at mount from a preference -- default_tab for the group, else the account-wide one, else 'chat'. Which applications the group runs comes from the node, in the handshake ack, several awaits later. A preference is a preference, not a promise that the app exists here, so the two disagree in two ordinary cases: the group has Chat disabled while 'chat' is everyone's default, or the reader prefers an app this group does not run. `apps.map(a => tab === a.key && ...)` then matches nothing. The first app the group does offer answers both. Two more cases come free: a preference naming an app that no longer exists, and an operator disabling the app someone is currently looking at -- enabledApps changes live over apps_enabled, and being moved to a working tab beats staring at an empty panel. Settings is exempt: it is not an application, and the create-group wizard lands on it deliberately. `const apps` moves above the effect that reads it; a const further down would be in its temporal dead zone, which is the hook-ordering trap already recorded in CLAUDE.md. tests/harness/group_tab_probe.py renders the real GroupPage against a stub node answering a chosen enabled_apps and reads the tab bar back, over five cases. With the fix reverted the three fallback cases report no active tab at all and four of the six tests fail; the two that pass either way are the ones that must not change -- a group running everything, and a preference the group does honour (Videos stays selected, so the fallback has not become "always the first app"). Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01W8oRqEHhnKUr1NfmTVdcyL