moflo 4.9.20 → 4.9.22

package/.claude/guidance/shipped/moflo-session-start.md

@@ -1,154 +0,0 @@
-# MoFlo Session-Start Lifecycle
-
-**Purpose:** Document everything that runs when Claude Code fires the `SessionStart` hook in a moflo-enabled project. The launcher does substantially more than "start the daemon" — it heals stale state, migrates DBs, syncs scripts, and reconciles hook wiring. Knowing what runs (and in what order) makes diagnosis fast.
-
-**Audience:** Agents and developers diagnosing slow session starts, unexpected mutations to `.claude/`, embedded migrations, daemon recycling, and post-upgrade behaviour.
-
----
-
-## Quick reference
-
-The launcher (`bin/session-start-launcher.mjs`, synced to `.claude/scripts/session-start-launcher.mjs`) is the single SessionStart hook moflo registers. Everything below runs in one process, in the listed order, before Claude Code begins the session. Total cost on a healthy install with no version change is typically < 200 ms; an upgrade or DB heal can extend it to several seconds.
-
-When anything runs, the launcher prints `moflo: <action> (<details>)` to stdout. Claude Code captures stdout as session-start `additionalContext`, so the agent sees every mutation. Failures land on stderr and similarly surface.
-
----
-
-## Stages, in execution order
-
-### 0. Headless skip
-
-If `CLAUDE_CODE_HEADLESS=true` is set in the environment, the launcher exits immediately. The moflo daemon spawns headless Claude processes (for indexing, pretraining, etc.); without this guard each spawned Claude would re-enter the launcher and fork the indexer chain on every daemon worker tick. ([#860](https://github.com/eric-cielo/moflo/issues/860).)
-
-### 0-pre. Drop stale upgrade-notice files
-
-`.moflo/upgrade-notice.json` is a transient handshake between launcher and statusline. Pre-#738 launchers wrote a 1-hour-TTL "complete" notice that could survive past the launcher run that wrote it. The launcher unconditionally removes any leftover before its own run begins.
-
-### 0c. Memory DB index repair
-
-Probes `.moflo/moflo.db` for `sqlite_autoindex_memory_entries_1` corruption and runs `REINDEX` in place if found. Must run before any sql.js consumer (embeddings migration, ephemeral-namespace purge, MCP server, daemon) — those swallow corruption errors and silently drop work otherwise. Cost on the happy path: one PRAGMA check (~10 ms). ([#743](https://github.com/eric-cielo/moflo/issues/743).)
-
-### 0d. Clear post-install restart notice
-
-If `.moflo/restart-pending.json` was written by `scripts/post-install-notice.mjs` after the last `npm install moflo` and the running version now matches the pending version, the file is removed. The user has restarted; the notice has done its job. ([#867](https://github.com/eric-cielo/moflo/issues/867).)
-
-### 2. Reset workflow state
-
-Writes a fresh `.claude/workflow-state.json` for the new session: `tasksCreated: false`, `memorySearched: false`, `sessionStart: <ISO timestamp>`. The gate scripts read this on every tool call.
-
-### 3. Auto-sync on version change (or drift)
-
-This is the biggest stage. It fires when **either** condition is true:
-
-- The installed version (`node_modules/moflo/package.json`) differs from the cached version stamp (`.moflo/moflo-version`), OR
-- Any file in `.moflo/installed-files.json` (the manifest from the previous successful sync) is missing or has drifted in size since we last wrote it.
-
-When triggered, the launcher walks the following sub-steps in order:
-
-| Sub-step | What runs | Why |
-|---------|-----------|-----|
-| Stop daemon | Kills the daemon recorded in `.moflo/daemon.lock` | The daemon was started under the previous moflo image; old module-cache + path resolution would clobber the upgrade. ([#851](https://github.com/eric-cielo/moflo/issues/851).) |
-| Cherry-pick learnings | `cherry-pick-learnings.js` reads legacy `.swarm/memory.db` and `INSERT OR IGNORE`s into `.moflo/moflo.db` | Carries user-authored knowledge forward across the v3 DB rename. Idempotent. |
-| Sync scripts | Copy `bin/*.mjs` and `bin/lib/**` and `bin/migrations/**` into `.claude/scripts/` | Hooks always run the latest version |
-| Sync helpers | Copy `bin/{gate.cjs,gate-hook.mjs,prompt-hook.mjs,hook-handler.cjs}` plus `.claude/helpers/{auto-memory-hook.mjs,statusline.cjs,...}` into `.claude/helpers/` | Same |
-| Sync shipped guidance | Copy every `node_modules/moflo/.claude/guidance/shipped/moflo-*.md` into `.claude/guidance/`, prefixing each with the auto-generated mirror header | These are the files indexed by the consumer's memory namespace |
-| Cleanup retired files | Anything in the OLD manifest but NOT in the new manifest is unlinked | Auto-removes files moflo no longer ships |
-| Per-file retry/circuit | Each copy retries `[50, 200, 800] ms` on `EBUSY`/`EPERM`/`EACCES` (Windows file lock, AV scan); after 5 distinct failures the circuit opens and the rest of the sync runs without retries | Prevents a sick host from compounding wall-clock cost; persistent failures land on stderr |
-| Manifest write | New `{path, size}` manifest committed to `.moflo/installed-files.json` | Drift detection on next launcher run |
-| Defer version stamp | Pending write of `.moflo/moflo-version` queued for stage 3g | Stamp is "launcher fully completed" — writing it mid-flight strands consumers on a half-applied upgrade ([#730](https://github.com/eric-cielo/moflo/issues/730)) |
-
-### 3a-pre. Recycle stale daemons
-
-Even when the version hasn't changed, the daemon-lock's `startedAt` is compared against `node_modules/moflo`'s install mtime. If the daemon predates the current install (with a 5 s skew margin), it's recycled. This catches the "user upgraded ages ago, ran one session that bumped the stamp + recycled the daemon, but the daemon they started long-ago is still alive holding stale module cache" failure mode.
-
-### 3a. Settings.json migration and self-heal
-
-See `moflo-settings-injection.md` for the full mechanism. The launcher applies, in order:
-
-1. **Drop stale `PATH` override** — pre-4.x settings injected `${PATH}` which Claude Code didn't expand, breaking node resolution.
-2. **Replace `npx flo` hook commands with direct `node "$CLAUDE_PROJECT_DIR/..."` invocations** — saves 2–5 s of `npx` cold-start per hook.
-3. **Ensure `statusLine` is wired** — the helper script is synced by stage 3 but the config block may be absent.
-4. **Repair + rewrite hook wirings** — `repairHookWiring()` adds missing required hooks; `rewriteIncorrectHookWiring()` rewrites known-stale hook commands (e.g. [#879](https://github.com/eric-cielo/moflo/issues/879) `gate.cjs record-memory-searched` → `gate-hook.mjs record-memory-searched`).
-
-### 3b. Restore + prune shipped guidance mirrors
-
-Even when stage 3 didn't fire (no version change, no drift), the launcher checks that every `moflo-*.md` from `node_modules/moflo/.claude/guidance/shipped/` exists at `.claude/guidance/<file>` with the auto-generated mirror header. Missing files are restored; mirror files whose source has been removed (and which still carry the `<!-- AUTO-GENERATED by moflo session-start.` marker) are pruned. ([#839](https://github.com/eric-cielo/moflo/issues/839).)
-
-### 3b-714, 3c. Legacy cleanup
-
-- `.swarm/vector-stats.json` (replaced by `.moflo/vector-stats.json` post-#699) is unlinked.
-- Pre-4.8.45 double-prefixed guidance files (`moflo-moflo-*.md`) are unlinked.
-
-### 3d-yaml. Append missing top-level sections to `moflo.yaml`
-
-`bin/lib/yaml-upgrader.mjs` walks the user's `moflo.yaml` and idempotently appends any registered top-level section that's absent (e.g., `sandbox:`, `auto_update:`, `daemon:`). Never modifies user-set values; never reorders or reformats. Surfaces appended section names so the user can find what changed. (Pattern documented in `internal/upgrade-contract.md` "Yaml upgrade pattern".)
-
-### 3d. Install global `flo` shim
-
-Best-effort install of a shim into npm's global bin so bare `flo` resolves to the local project's `node_modules/.bin/flo`. Idempotent — skips when already present. Non-fatal on failure: `flo` still works via `npx`.
-
-### 3e. Foreground embeddings migration
-
-`runEmbeddingsMigrationIfNeeded` checks `.moflo/moflo.db` for embeddings-version drift and, if needed, re-embeds rows in chunks. Runs synchronously with piped stdio so the renderer's progress bar reaches the user. Returns fast (~ms) when no migration is needed.
-
-### 3e-728, 3e-729. Hard-purge legacy memory rows
-
-- Soft-deleted tombstones (status='deleted' rows from pre-#728 builds) are hard-deleted and the DB is VACUUMed.
-- Ephemeral-namespace rows (`hive-mind`, `tasklist`, `epic-state`, `test-bridge-fix`) accumulated by pre-#729 builds are hard-deleted; going forward, writes to those namespaces skip embedding generation entirely.
-
-Both run **before** the daemon is restarted in stage 4 so a concurrent sql.js flush can't clobber the foreground purge.
-
-### 3f. Flip upgrade notice to "completed"
-
-If stage 3 wrote an "in-progress" upgrade notice for the statusline, it's flipped to "completed" with a 2-minute TTL. The next session-start's stage 0-pre wipes any leftover.
-
-### 3g. Commit deferred version stamp
-
-`.moflo/moflo-version` is finally written with the installed version. Any abort above leaves the stamp unchanged so the next launcher re-detects the upgrade and re-runs stage 3. ([#730](https://github.com/eric-cielo/moflo/issues/730).)
-
-### 4. Spawn background tasks
-
-- `node bin/hooks.mjs session-start` is spawned detached + unref'd. That script starts the daemon, the indexer, the pretrain pass, the HNSW build, and the neural-pattern training. None of it blocks the session.
-- Migrations (`run-migrations.mjs`) consult `.moflo/migrations.json` and run any unmigrated steps synchronously, then announce completed migrations via `moflo:` mutation lines.
-
-### 5. Exit
-
-`process.exit(0)`. Claude Code now begins the session with the launcher's stdout captured as additionalContext.
-
----
-
-## Diagnosing slow session starts
-
-Bottlenecks, in rough order of likelihood:
-
-| Symptom | Likely stage | Mitigation |
-|---------|-------------|------------|
-| Several-second delay on first start after `npm install` | Stage 3 (script + helper + guidance sync) | Expected — one-shot cost. Subsequent starts are ms. |
-| 30–60 s delay on first start after a major upgrade | Stage 3e (embeddings migration) | Surfaces a progress bar via stderr; cannot be skipped. |
-| Repeated multi-second delay on every start | Stage 3 firing every time = manifest drift loop | Check `moflo: repaired stale install` lines on stdout — usually means a file copy keeps failing (Windows AV, file lock). Run `flo doctor --fix`. |
-| Daemon appears to restart on every start | Stage 3a-pre — daemon predates install | Expected if you just upgraded; should stop after one session. |
-
-If a stage hangs, the launcher's per-step timeouts (5–30 s depending on the operation) protect against deadlock. A blocked stage that times out lands an error on stderr; the next launcher run retries.
-
----
-
-## Adding a new stage (developer note)
-
-Before adding work to the launcher, ask:
-
-1. Is this **per-session** work (hook reset, mirror restore) or **per-version** work (script sync, manifest)? Per-version belongs in stage 3 under the version-change gate; per-session goes in stage 2 or as its own gated stage.
-2. Does it touch `sql.js`? It must run **before** stage 4's daemon spawn — concurrent flushes from a long-lived sql.js consumer will clobber a foreground write.
-3. Does it mutate consumer state? It must `emitMutation()` so the user sees what changed via additionalContext. Silent mutations are a regression of the upgrade contract.
-4. Does it depend on a fresh-state invariant (e.g., daemon stopped, manifest written, version stamp committed)? Order matters — see the existing 3 → 3a → 3a-pre → ... → 3g → 4 sequence and slot in accordingly.
-
-Full ordering rules and historical violations live in `internal/upgrade-contract.md`.
-
----
-
-## See Also
-
-- `moflo-settings-injection.md` — the contract for what moflo writes into `.claude/settings.json` and how the surgical self-heal works.
-- `moflo-core-guidance.md` (Helper Script Auto-Sync) — the file lists for stage 3.
-- `moflo-memorydb-maintenance.md` — what runs against `.moflo/moflo.db` (embeddings, soft-delete, ephemeral purge).
-- Internal-only: `internal/upgrade-contract.md` — the "user must never re-run init" invariant the launcher enforces, with historical violations to learn from.
-- Internal-only: `internal/guidance-sync.md` — Stages 3 and 3b documented end-to-end as part of the three-layer guidance sync (filesystem → DB → HNSW).

package/.claude/guidance/shipped/moflo-spell-engine-architecture.md

@@ -1,145 +0,0 @@
-# Spell Engine & Messaging Architecture
-
-**Purpose:** Architectural decisions and analysis findings for Epic #100 (Generalized Spell Engine) and Epic #110 (Messaging Migration). Reference when working on stories #100-#117.
-
----
-
-## Epic #100: Generalized Spell Engine
-
-**Ships as part of moflo** — not a separate project. Heavy deps (Playwright, isolated-vm) are optional peer dependencies, same pattern as cli's embeddings module requiring `sql.js`.
-
-### Command Pattern for Steps
-
-Every spell step type implements a `StepCommand` interface with `execute()`, `validate()`, `describeOutputs()`, and optional `rollback()`. Register step commands via a plugin-style `StepCommandRegistry` — follow the existing `PluginRegistry` pattern in `src/cli/plugins/`.
-
-### Spell Definitions
-
-Spells are YAML/JSON files in `workflows/` or `.claude/workflows/`. Each declares:
-- `name` and `abbreviation` (short name for `/flo -wf {abbrev}`)
-- Typed `arguments` with `required`, `default`, `enum`, `description`
-- Ordered `steps` with `{stepId.outputKey}` variable interpolation
-
-### MoFlo Integration Levels Per Step
-
-| Level | Capabilities | Default For |
-|-------|-------------|-------------|
-| `none` | No MoFlo access | `bash`, `condition`, `wait` |
-| `memory` | search/store/list | `agent` steps |
-| `hooks` | Above + pre/post task hooks | — |
-| `full` | Above + swarm/hive-mind spawning | — |
-| `recursive` | Above + nested `/flo -wf` invocation | — |
-
-Capabilities only narrow going deeper — a nested spell cannot escalate beyond its parent.
-
-### Sandboxing Tiers
-
-| Tier | Mechanism | Status |
-|------|-----------|--------|
-| 1 | Capability declarations + enforcement | Build first |
-| 2 | Node `--experimental-permission` for bash steps | Build second |
-| 3 | `isolated-vm` for expression evaluation | Build third |
-| 4 | Linux namespaces (optional) | Defer |
-| 5 | WASM sandbox for community commands | Defer |
-
-### Build Order (no circular dependencies)
-
-| Phase | Stories | Can Start |
-|-------|---------|-----------|
-| 1 | #101 (Interface), #103 (Schema) | Immediately |
-| 2 | #102 (Commands), #106 (Credentials) | After Phase 1 |
-| 3 | #104 (Runner) | After Phase 2 |
-| 4 | #105 (Registry), #108 (Sandboxing T1-2), #107 (Playwright) | After Phase 3 |
-| 5 | #109 (Integration Levels), #117 (Scheduling) | After Phase 4 + Epic #110 |
-
-### Critical Findings
-
-- **Existing `spell_execute` is a no-op placeholder.** The engine is greenfield.
-- **`js-yaml` already a dependency** — used in `moflo-config.ts` and `epic.ts`.
-- **Plugin registry pattern is directly reusable** for `StepCommandRegistry`.
-- **No cron support exists** — needs `node-cron` dependency for #117.
-- **Retry logic is consumer-side**, not bus-side. Steps implement their own retry.
-
----
-
-## Epic #110: Messaging Migration to Memory DB
-
-**Migrate inter-agent messaging** from in-memory EventEmitter bus to memory DB namespace. The current bus only works within a single process — spawned subagents cannot participate.
-
-### Session Isolation
-
-All messages scoped by `sessionId`. Queries implicitly filter by current session. `endSession()` expires unhandled messages. `gc()` cleans up abandoned sessions after configurable TTL.
-
-### Build Order
-
-| Phase | Stories |
-|-------|---------|
-| 1 | #111 (Schema + CRUD) |
-| 2 | #112 (Notification/Pub-Sub) |
-| 3 | #113, #114, #115 (parallel) |
-| 4 | #116 (Deprecate old bus — last) |
-
-**Minimum viable to unblock Epic #100:** #111 + #112 only.
-
-### Critical Findings
-
-- **`queen-coordinator.ts` does NOT use MessageBus.** Hive-mind operates via MCP tools. Story #114 is greenfield, not migration.
-- **`unified-coordinator.ts` is coupled to concrete `MessageBus` class**, not `IMessageBus` interface. Must refactor.
-- **Zero existing message bus tests.** Write baseline suite first, then verify both backends pass.
-- **Two competing Message types:** `SwarmMessage` (shared/types.ts) vs `Message` (swarm/types.ts). Story #111 must reconcile.
-- **Memory DB supports namespaces and TTL** but needs queue semantics and metadata indexing added.
-- **`enablePersistence` config flag exists but was never implemented** — now being properly built.
-
-### Interface Incompatibility: Not a Clean Swap
-
-The `MemoryDbMessageBus` adapter (~300 lines) must handle:
-
-| Aspect | Current `IMessageBus` | New `MessageStore` |
-|--------|----------------------|-------------------|
-| Subscribe | Push-based callback | Pull-based `receive()` |
-| Acknowledge | `acknowledge(ack)` | `markRead()` |
-| Timestamps | `Date` objects | `number` (epoch ms) |
-| Sessions | None | `sessionId` required |
-| Channels | None (per-agent queues) | Channel-based routing |
-
----
-
-## Epic #118: Consolidate Messaging Systems (Pre-req for #110)
-
-**Three messaging systems → one layered broker.** Must complete before Epic #110 migration.
-
-| Story | What | Depends On |
-|-------|------|------------|
-| #119 | Unified Message Type & Extended IMessageBus | — |
-| #120 | SwarmCommunication → MessageBus consumer | #119 |
-| #121 | Hive-Mind → MessageBus + Memory DB write-through | #119, #120 |
-
-**Key decisions:**
-- MessageBus keeps its Deque hot path for delivery (~1000+ msg/sec)
-- Memory DB write-through is fire-and-forget, initially only for hive-mind namespace
-- TTL reaper lives in the broker (60s sweep), not the daemon
-- Daemon can do deeper GC pass but system must not depend on it
-
-**Build order:** Epic #118 → remaining #110 stories (#111, #115, #116) → Epic #100 Phase 5.
-
----
-
-## Cross-Epic Dependencies
-
-**Most of Epic #100 can proceed without Epic #110.** Only two things are hard-blocked:
-
-| Blocked Story | Needs from #110 | Why |
-|--------------|-----------------|-----|
-| #109 `full` tier | #113 (Swarm Migration) | Swarm spawning needs DB-backed messaging |
-| #109 `recursive` tier | #113 + #114 | Nested spells with hive-mind need consensus messaging |
-
-Stories #101-#108, #105, #117 have no dependency on Epic #110.
-
-**Epic #118 simplifies #110:** #112 (pub/sub) largely solved, #113 (swarm) done via #120, #114 (hive-mind) done via #121.
-
----
-
-## See Also
-
-- `.claude/guidance/shipped/moflo-core-guidance.md` — CLI, hooks, swarm, memory reference
-- `.claude/guidance/shipped/moflo-claude-swarm-cohesion.md` — Task & swarm coordination
-- `.claude/guidance/shipped/moflo-subagents.md` — Subagents protocol

package/.claude/skills/browser/SKILL.md

@@ -1,204 +0,0 @@
----
-name: browser
-description: Web browser automation with AI-optimized snapshots for claude-flow agents
-version: 1.0.0
-triggers:
-  - /browser
-  - browse
-  - web automation
-  - scrape
-  - navigate
-  - screenshot
-tools:
-  - browser/open
-  - browser/snapshot
-  - browser/click
-  - browser/fill
-  - browser/screenshot
-  - browser/close
----
-
-# Browser Automation Skill
-
-Web browser automation using agent-browser with AI-optimized snapshots. Reduces context by 93% using element refs (@e1, @e2) instead of full DOM.
-
-## Core Workflow
-
-```bash
-# 1. Navigate to page
-agent-browser open <url>
-
-# 2. Get accessibility tree with element refs
-agent-browser snapshot -i    # -i = interactive elements only
-
-# 3. Interact using refs from snapshot
-agent-browser click @e2
-agent-browser fill @e3 "text"
-
-# 4. Re-snapshot after page changes
-agent-browser snapshot -i
-```
-
-## Quick Reference
-
-### Navigation
-| Command | Description |
-|---------|-------------|
-| `open <url>` | Navigate to URL |
-| `back` | Go back |
-| `forward` | Go forward |
-| `reload` | Reload page |
-| `close` | Close browser |
-
-### Snapshots (AI-Optimized)
-| Command | Description |
-|---------|-------------|
-| `snapshot` | Full accessibility tree |
-| `snapshot -i` | Interactive elements only (buttons, links, inputs) |
-| `snapshot -c` | Compact (remove empty elements) |
-| `snapshot -d 3` | Limit depth to 3 levels |
-| `screenshot [path]` | Capture screenshot (base64 if no path) |
-
-### Interaction
-| Command | Description |
-|---------|-------------|
-| `click <sel>` | Click element |
-| `fill <sel> <text>` | Clear and fill input |
-| `type <sel> <text>` | Type with key events |
-| `press <key>` | Press key (Enter, Tab, etc.) |
-| `hover <sel>` | Hover element |
-| `select <sel> <val>` | Select dropdown option |
-| `check/uncheck <sel>` | Toggle checkbox |
-| `scroll <dir> [px]` | Scroll page |
-
-### Get Info
-| Command | Description |
-|---------|-------------|
-| `get text <sel>` | Get text content |
-| `get html <sel>` | Get innerHTML |
-| `get value <sel>` | Get input value |
-| `get attr <sel> <attr>` | Get attribute |
-| `get title` | Get page title |
-| `get url` | Get current URL |
-
-### Wait
-| Command | Description |
-|---------|-------------|
-| `wait <selector>` | Wait for element |
-| `wait <ms>` | Wait milliseconds |
-| `wait --text "text"` | Wait for text |
-| `wait --url "pattern"` | Wait for URL |
-| `wait --load networkidle` | Wait for load state |
-
-### Sessions
-| Command | Description |
-|---------|-------------|
-| `--session <name>` | Use isolated session |
-| `session list` | List active sessions |
-
-## Selectors
-
-### Element Refs (Recommended)
-```bash
-# Get refs from snapshot
-agent-browser snapshot -i
-# Output: button "Submit" [ref=e2]
-
-# Use ref to interact
-agent-browser click @e2
-```
-
-### CSS Selectors
-```bash
-agent-browser click "#submit"
-agent-browser fill ".email-input" "test@test.com"
-```
-
-### Semantic Locators
-```bash
-agent-browser find role button click --name "Submit"
-agent-browser find label "Email" fill "test@test.com"
-agent-browser find testid "login-btn" click
-```
-
-## Examples
-
-### Login Flow
-```bash
-agent-browser open https://example.com/login
-agent-browser snapshot -i
-agent-browser fill @e2 "user@example.com"
-agent-browser fill @e3 "password123"
-agent-browser click @e4
-agent-browser wait --url "**/dashboard"
-```
-
-### Form Submission
-```bash
-agent-browser open https://example.com/contact
-agent-browser snapshot -i
-agent-browser fill @e1 "John Doe"
-agent-browser fill @e2 "john@example.com"
-agent-browser fill @e3 "Hello, this is my message"
-agent-browser click @e4
-agent-browser wait --text "Thank you"
-```
-
-### Data Extraction
-```bash
-agent-browser open https://example.com/products
-agent-browser snapshot -i
-# Iterate through product refs
-agent-browser get text @e1  # Product name
-agent-browser get text @e2  # Price
-agent-browser get attr @e3 href  # Link
-```
-
-### Multi-Session (Swarm)
-```bash
-# Session 1: Navigator
-agent-browser --session nav open https://example.com
-agent-browser --session nav state save auth.json
-
-# Session 2: Scraper (uses same auth)
-agent-browser --session scrape state load auth.json
-agent-browser --session scrape open https://example.com/data
-agent-browser --session scrape snapshot -i
-```
-
-## Integration with Claude Flow
-
-### MCP Tools
-All browser operations are available as MCP tools with `browser/` prefix:
-- `browser/open`
-- `browser/snapshot`
-- `browser/click`
-- `browser/fill`
-- `browser/screenshot`
-- etc.
-
-### Memory Integration
-```bash
-# Store successful patterns
-npx moflo memory store --namespace browser-patterns --key "login-flow" --value "snapshot->fill->click->wait"
-
-# Retrieve before similar task
-npx moflo memory search --query "login automation"
-```
-
-### Hooks
-```bash
-# Pre-browse hook (get context)
-npx moflo hooks pre-edit --file "browser-task.ts"
-
-# Post-browse hook (record success)
-npx moflo hooks post-task --task-id "browse-1" --success true
-```
-
-## Tips
-
-1. **Always use snapshots** - They're optimized for AI with refs
-2. **Prefer `-i` flag** - Gets only interactive elements, smaller output
-3. **Use refs, not selectors** - More reliable, deterministic
-4. **Re-snapshot after navigation** - Page state changes
-5. **Use sessions for parallel work** - Each session is isolated