docs: refine OpenClaw analysis with quantified deltas

docs/plans/2026-02-18-openclaw-analysis.md

@@ -48,76 +48,18 @@ Interpretation for Flynn planning:
 - OpenClaw/MoltBot/ClawdBot should be treated as one continuous product strategy and code lineage.
 - The identity shifts were brand changes, not architecture resets.
 
-## 2) What Makes OpenClaw Efficient: 8 Mechanisms
+## 2) OpenClaw Efficiency Summary (Condensed)
 
-### 2.1 Unified multi-channel inbox
+The detailed weighted baseline remains in `docs/plans/analysis/openclaw-comparison.md`. In short, OpenClaw's assistant efficiency comes from:
 
-OpenClaw's gateway model centralizes many chat surfaces under one runtime.
+1. Unified multi-channel runtime that minimizes context switching.
-
+2. Rich queue/control semantics (`collect`/`followup`/`steer`/`interrupt`) for in-flight control.
-Why this improves assistant efficiency:
+3. Local-first gateway posture for trust and persistent daily use.
-- less context switching,
+4. Streaming/chunking tuned for chat UX quality under long outputs.
-- more opportunities for the assistant to be used in-place.
+5. Companion/node + voice surfaces that keep the assistant ambient.
-
+6. Continuity-oriented memory patterns (daily logs + curated durable memory).
-### 2.2 Queue policy as a UX primitive
+7. Profile-aware failover within provider before cross-provider fallback.
-
+8. Ecosystem leverage (skills/hook surfaces) for capability expansion velocity.
-OpenClaw queue docs define behavior modes beyond plain FIFO, including `collect`, `followup`, `steer`, `steer-backlog`, and legacy `interrupt` semantics.
-
-Why this improves assistant efficiency:
-- users can steer/reshape ongoing work without waiting for full completion,
-- long-running turns feel controllable instead of blocking.
-
-### 2.3 Local-first gateway architecture
-
-OpenClaw docs emphasize local gateway operation and user-controlled state.
-
-Why this improves assistant efficiency:
-- trust and privacy increase willingness to connect more accounts/tools,
-- lower friction for daily persistent use.
-
-### 2.4 Streaming + chunking tuned for messaging surfaces
-
-OpenClaw streaming docs describe bounded chunking (`minChars`/`maxChars`), break-preference logic, and markdown/code-fence-safe splitting.
-
-Why this improves assistant efficiency:
-- faster perceived response,
-- fewer formatting regressions during long outputs.
-
-### 2.5 Companion/node + voice surfaces
-
-OpenClaw platform narrative strongly emphasizes ambient access (desktop/mobile/voice-facing surfaces).
-
-Why this improves assistant efficiency:
-- the assistant is available in more contexts (hands-free/mobile),
-- proactive behavior has a reliable delivery surface.
-
-### 2.6 Memory model optimized for continuity
-
-OpenClaw memory docs define a dual pattern:
-- daily append-only logs (`memory/YYYY-MM-DD.md`),
-- curated long-term memory (`MEMORY.md`).
-
-Why this improves assistant efficiency:
-- better day-to-day recall without conflating temporary and durable facts.
-
-### 2.7 Model failover with auth-profile rotation
-
-OpenClaw model-failover docs show two-stage resilience:
-- rotate auth profiles within provider first,
-- then fallback across models/providers.
-
-They also document session profile stickiness and exponential cooldown/disable behavior.
-
-Why this improves assistant efficiency:
-- fewer hard failures under rate-limit/auth instability,
-- better cache behavior from per-session pinning.
-
-### 2.8 Ecosystem + hook surface
-
-OpenClaw docs show a public skill ecosystem (ClawHub) and lifecycle hooks (`agent:bootstrap`, model/prompt/tool/message hooks).
-
-Why this improves assistant efficiency:
-- ecosystem expands capability coverage faster than core-only development,
-- hooks allow behavior shaping without forking core runtime.
 
 ## 3) New Findings That Change Flynn Gap Priority
 
@@ -181,6 +123,7 @@ Conclusion:
 - default proactive delivery behavior and ambient surfaces,
 - interaction-level control for in-flight runs (steer/interrupt semantics),
 - continuity ergonomics (daily memory capture patterns),
+- event-driven reactions layer (match event patterns and trigger agent actions without cron/webhook glue),
 - profile-level auth failover resilience,
 - ecosystem-network effects (public skill discovery/install loops).
 
@@ -242,6 +185,17 @@ Implementation anchors:
 - `src/config/schema.ts`
 - auth store modules in `src/auth/*`
 
+### A6. Reactions/event-trigger automation layer
+
+Goal:
+- allow declarative event -> action rules (for example: incoming Gmail pattern match -> summarize -> notify), beyond fixed cron schedules and inbound HTTP triggers.
+
+Implementation anchors:
+- `src/automation/*` (new reactions engine and trigger bus)
+- `src/automation/gmail.ts` (first event source candidate)
+- `src/config/schema.ts` (reaction rule schema and safety constraints)
+- `src/audit/logger.ts` (traceability for auto-triggered actions)
+
 ## Tier B: meaningful medium-scope improvements
 
 - Guided onboarding upgrades in `src/cli/setup/*` (channel-specific test loops + safer defaults).
@@ -257,15 +211,34 @@ Implementation anchors:
 - Marketplace-scale ClawHub-equivalent infrastructure.
 - Advanced always-on wake-word runtime across platforms.
 
-## 6) Updated Takeaway Since Feb 12 Comparison
+## 6) Quantified Score Adjustment (Post-Findings)
+
+Baseline from `docs/plans/analysis/openclaw-comparison.md`:
+- OpenClaw: 478/500 (95.6%)
+- Flynn: 393/500 (78.6%)
+
+Assumption-based adjustment from findings in this document:
+- `Reach: channels and surfaces` (weight 16) for Flynn moves from 3.0 to 3.5 because companion/node backend protocol foundations are already present server-side (remaining work is primarily shipped client surfaces).
+
+Score impact:
+- +8 weighted points to Flynn (`0.5 * 16`)
+- Revised Flynn score: 401/500 (80.2%)
+- Revised gap to OpenClaw: 77 points (vs 85 baseline)
+
+Important:
+- This is an analytical adjustment, not a formal replacement for the canonical scorecard.
+- It should be read as an "effective readiness" estimate contingent on companion client delivery.
+
+## 7) Updated Takeaway Since Feb 12 Comparison
 
 What changed versus `docs/plans/analysis/openclaw-comparison.md`:
 - Companion gap is narrower than previously scored on backend foundations (protocol already present).
 - Queue control gap is now better understood: Flynn has mode vocabulary, but semantics need tightening for true interrupt/steer behavior.
 - Memory and failover priorities shift upward because they are high-leverage and relatively contained in scope.
+- Reactions/event-trigger automation should be treated as a first-class assistant gap, not folded into cron/webhook parity.
 
 Practical recommendation:
-- prioritize Tier A behavior-layer upgrades before chasing long-tail parity items.
+- prioritize Tier A behavior-layer upgrades (including reactions) before chasing long-tail parity items.
 - this path improves "personal assistant effectiveness" faster than broad surface-area expansion.
 
 ## Evidence and Confidence Notes

docs/plans/state.json

@@ -5214,6 +5214,17 @@
         "docs/plans/state.json"
       ],
       "test_status": "pnpm test:run src/automation/cron.test.ts src/automation/webhooks.test.ts src/config/schema.test.ts + pnpm typecheck passing"
+    },
+    "openclaw-analysis-refinement-2026-02-18": {
+      "status": "completed",
+      "date": "2026-02-18",
+      "updated": "2026-02-18",
+      "summary": "Refined the OpenClaw Phase-2 strategy document by condensing the generic mechanism section, adding an explicit reactions/event-trigger automation gap and roadmap item, and introducing a quantified score-adjustment section with assumptions and caveats.",
+      "files_modified": [
+        "docs/plans/2026-02-18-openclaw-analysis.md",
+        "docs/plans/state.json"
+      ],
+      "test_status": "Docs-only change (no code paths affected)"
     }
   },
   "overall_progress": {