vault: session notes 2026-07-09

firecrawl-usage-guide.md

@@ -74,6 +74,17 @@ As of 2026-07-09 the cloud `FIRECRAWL_API_KEY` (`fc-1bfc9a53...`) is still valid
 - **hermes01**: swap in `FIRECRAWL_API_KEY` (currently commented out in `~/.hermes/.env`) in place of `FIRECRAWL_API_URL` — the native provider reads the key and hits cloud instead.
 - This is a manual/one-off swap, not scripted health-check-and-failover — building that wasn't judged worth it given the subscription's short remaining life. Revisit if the subscription is kept longer-term.
 
+## Backlog idea: web-navigation router skill (not built)
+
+Floated 2026-07-09, not implemented — a small plugin/skill that routes a given URL/request to one of firecrawl-local, firecrawl-cloud, or WebFetch based on defined criteria, instead of a human/agent picking manually each time. Rough routing criteria to start from:
+
+- Simple static page → WebFetch (zero setup, no MCP/CLI overhead)
+- JS-heavy page / needs multi-page crawl or map → firecrawl-local (self-hosted)
+- Self-hosted returns an error, times out, or the target needs anti-bot/proxy features self-host lacks (see [[firecrawl-self-hosted-capabilities]]) → firecrawl-cloud, if the subscription is still active
+- Cloud subscription status is the gating factor — this idea is moot once/if the subscription is canceled, unless re-subscribed
+
+This generalizes the manual fallback above into scripted routing logic. Worth revisiting only if: (a) the cloud subscription is kept longer-term, or (b) self-host reliability issues actually recur often enough to justify automation.
+
 ## Related
 
 - [[firecrawl-self-host-setup]] — install/deploy and env-var reference

journal/2026-07-09.md

@@ -82,3 +82,10 @@ tags: [scope/global, type/log]
 **Reason:** other
 **Vault notes touched:**
 (none)
+
+## Session — 2026-07-09T15:25:59Z
+
+**Project:** /home/jared/servers/desktop
+**Reason:** prompt_input_exit
+**Vault notes touched:**
+(none)