You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As the developer running the native event investigation (Epic #32), I want a small WebdriverIO + wdio-obsidian-service harness that can drive Obsidian deterministically — switch Reading/Live Preview/Source, toggle the plugin, and dispatch trusted gestures — so the trace runs in #34 and #35 are clean, repeatable, and multi-sample instead of hand-performed and noisy.
This is the driver. Issue #33 (nativeEventTracer.ts) is the logger. They are complementary: the spike performs gestures; the tracer records them.
It is also the e2e PRD's Phase 0: it validates the four load-bearing assumptions before any full e2e suite is built. Building it here, where the investigation already needs a deterministic driver, earns that validation for free.
Findings recorded (which unknowns held, any surprises), and any that failed flagged before committing further to the e2e approach.
Committed test/vaults/parity/ + wdio.conf.mts exist (the foundation the later full suite reuses).
Out of scope
The full e2e assertion/parity suite (PRD Phases 1–4). That comes after the investigation, informed by its measured timing/event findings, as the black-box characterization net for the Phase 5–10 refactor.
Drive ordering-sensitive rows freely (event order is Obsidian's, not the driver's). Cross-check absolute timing-magnitude rows (e.g. the middle-click delay) against a manual gesture, since automated input dispatch can perturb latency. If the spike snags, #34 / #35 can fall back to manual driving — drop the blocker if so.
Story
As the developer running the native event investigation (Epic #32), I want a small WebdriverIO +
wdio-obsidian-serviceharness that can drive Obsidian deterministically — switch Reading/Live Preview/Source, toggle the plugin, and dispatch trusted gestures — so the trace runs in #34 and #35 are clean, repeatable, and multi-sample instead of hand-performed and noisy.This is the driver. Issue #33 (
nativeEventTracer.ts) is the logger. They are complementary: the spike performs gestures; the tracer records them.It is also the e2e PRD's Phase 0: it validates the four load-bearing assumptions before any full e2e suite is built. Building it here, where the investigation already needs a deterministic driver, earns that validation for free.
References
plan/e2e-automation-prd.md§9 Phase 0 — spike scope and the four unknownsplan/maintainability-plan-of-attack.mdPhase 3 → "e2e Phase 0 spike as the trace driver"plan/native-event-investigation.md§ Instrumentation Strategy / Exact ProcedureScope — the four unknowns to prove
leaf.setViewState({ type: "markdown", state: { file, mode, source } })and read the mode back.app.plugins.disablePlugin/enablePlugin) — the tracer's required plugin-disabled mode (procedure step 2).editor.setCursor).Definition of Done
earliest+latest).test/vaults/parity/+wdio.conf.mtsexist (the foundation the later full suite reuses).Out of scope
Caveat
Drive ordering-sensitive rows freely (event order is Obsidian's, not the driver's). Cross-check absolute timing-magnitude rows (e.g. the middle-click delay) against a manual gesture, since automated input dispatch can perturb latency. If the spike snags, #34 / #35 can fall back to manual driving — drop the blocker if so.
Relationships