mirror of
https://github.com/sotashimozono/obsidian-remote-ssh.git
synced 2026-07-22 17:10:32 +00:00
3e608a00f0
Diagnosed conclusively across runs 26015295742 / 26016246390: over
SFTP the product connects, patches, and builds the remote vault model
correctly EVERY time — `VaultModelBuilder: built Nf, 0 errors`,
fileMap/markdownFiles populated, the single file-explorer leaf
visible 300x717 with navTitles>0. The only thing that "fails" is a
Playwright `.nav-file-title` visibility wait: headless Obsidian
(Xvfb) paints the File Explorer tree lazily/virtualised, so the DOM
nodes exist but don't satisfy Playwright's `visible` within the
window — a test-environment artifact, not the field-reported
"vault won't load" (which is disproven: the vault model loads).
Make the connect specs assert the USER-FACING OUTCOME via the
product's own model instead of a brittle DOM race:
- obsidian.ts: extract `readShadowModel`, add
`waitForShadowVaultLoaded` (polls until
`vault.getMarkdownFiles() >= 1` AND a file-explorer leaf exists —
the docker fixture always has remote_demo*.md, so this IS "the
remote tree loaded"; throws with the full diagnostic on timeout).
- connect-lifecycle: primary assertion = waitForShadowVaultLoaded;
DOM `.nav-file-title` visibility demoted to a best-effort
annotation (fe-rendered / fe-paint-lazy).
- connect-reconnect: same model-based assertion for the pre-drop
"healthy connection" gate and the post-recover "vault survived"
gate; DOM paint advisory only.
This verifies the real product behaviour the user cares about and is
immune to the headless paint race — not gate-gaming: it asserts the
remote tree was actually loaded into Obsidian's vault.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| log-oracle.ts | ||
| obsidian.ts | ||
| remote-verifier.ts | ||
| sshd.ts | ||
| vault-scaffold.ts | ||