@aporthq/aport-agent-guardrails 1.0.8

package/docs/launch/OPENCLAW_FEEDBACK_AND_FIXES.md

@@ -0,0 +1,85 @@
+# OpenClaw feedback summary and fixes
+
+This doc summarizes external OpenClaw feedback on launch readiness and the **two fixes** needed so the guardrail is “ready for prime time” in a real OpenClaw environment.
+
+---
+
+## What the feedback said
+
+**Plan and messaging:** Strong. Strategy, checklist, and guardrail post content are sufficient for a shot at reach and developer adoption—**provided the product experience matches the promises.**
+
+**Guardrail readiness:** Not yet. The guardrail **logic** is correct (repo tests are green; ALLOW/DENY work across verification paths). The blockage is in the **OpenClaw environment** on the machine where you run OpenClaw:
+
+1. **Passport allowlist:** The guardrail script (or the `bash` invocation that runs it) was **not** in the passport’s **allowed_commands**. So every attempt to run the guardrail via `exec` got denied **before** APort could respond (“command must be in allowed list”). The tests pass because they use a temp OpenClaw dir with an allowlisted guardrail; the real `~/.openclaw` passport may have a narrower list.
+2. **Capability alignment:** Messaging checks were failing with “missing capability: messaging.send.” The passport must include the capabilities the plugin needs (e.g. **messaging.send** for messaging.message.send.v1). There was also a **400 Bad Request** from the APort API when config (local vs API) or request shape didn’t match.
+
+**Until you can run:**
+
+```bash
+~/.openclaw/.skills/aport-guardrail.sh system.command.execute '{"command":"mkdir","args":["/tmp/test"]}'
+# -> ✅ ALLOW
+
+~/.openclaw/.skills/aport-guardrail.sh system.command.execute '{"command":"rm","args":["-rf","/"]}'
+# -> ❌ DENY (blocked pattern)
+```
+
+—and capture that output for the launch post—you can’t truthfully say “5-minute setup, works today.”
+
+---
+
+## Fix 1: Passport allowlist (allowed_commands)
+
+**Problem:** OpenClaw uses **exec** for both (a) running the guardrail script and (b) running real shell commands. The policy **system.command.execute.v1** checks the **command** string against **passport.limits.system.command.execute.allowed_commands** (prefix match). If the guardrail is invoked via `exec` (e.g. `bash ~/.openclaw/.skills/aport-guardrail.sh ...`), that **command** must be allowed. And every **real** command you need (e.g. `mkdir`, `ls`, `npm`) must be in the same list.
+
+**Fix:**
+
+The **installer (`./bin/openclaw`) now does this for you:** after it installs the guardrail wrappers, it updates the passport so that the guardrail script paths and `bash`/`sh` are in **allowed_commands** (idempotent merge). It then runs a self-check and exits with a clear error if the guardrail is denied. You only need to edit the passport manually if you didn’t use the installer or you use a different config dir.
+
+If you do edit by hand:
+
+1. Open your passport (e.g. `~/.openclaw/passport.json`).
+2. Ensure **limits.system.command.execute.allowed_commands** includes:
+   - **`bash`** (so any `bash .../aport-guardrail.sh ...` invocation is allowed), and
+   - Every **real** command the agent may run: **mkdir**, **ls**, **npm**, **git**, **node**, **npx**, **cp**, **cat**, **echo**, **pwd**, **mv**, **touch**, **open**, etc.
+3. Alternatively use **`["*"]`** to allow any command (blocked_patterns still apply). Re-run the passport wizard and choose “allow all commands” for the broad default, or edit the JSON.
+
+**Where it’s set:** The wizard (`bin/aport-create-passport.sh` or `./bin/openclaw`) writes this when you create the passport. To change it later, edit the passport file or re-run the wizard.
+
+**Quick fix (allow any command):** Run once to set `allowed_commands` to `["*"]` (blocked_patterns still apply):
+
+```bash
+jq '.limits["system.command.execute"].allowed_commands = ["*"]' ~/.openclaw/passport.json > ~/.openclaw/passport.json.tmp && mv ~/.openclaw/passport.json.tmp ~/.openclaw/passport.json
+```
+
+**References:** [OPENCLAW_TOOLS_AND_POLICIES.md](../OPENCLAW_TOOLS_AND_POLICIES.md), [QUICK_LAUNCH_CHECKLIST.md](QUICK_LAUNCH_CHECKLIST.md).
+
+---
+
+## Fix 2: Capability alignment (messaging.send and API config)
+
+**Problem:** The policy **messaging.message.send.v1** requires the passport to have capability **messaging.send** (per OAP and the policy pack). If the passport was created with an old or different capability id (e.g. `messaging.message.send`), you get “missing capability: messaging.send.” Also, **400 Bad Request** from the APort API usually means wrong endpoint, missing/invalid body, or local vs API mode mismatch.
+
+**Fix:**
+
+1. **Passport capabilities:** In **passport.capabilities**, include an object with **`"id": "messaging.send"`** (not only `messaging.message.send`) if you use messaging. The wizard adds this when you answer “Send messages?” with yes.
+2. **Local vs API:** For **local** mode the plugin runs the guardrail script and does **not** call the APort API. Set **mode: local** and **guardrailScript** to your `~/.openclaw/.skills/aport-guardrail-bash.sh` (or equivalent). For **API** mode set **apiUrl** and optionally **apiKey**; ensure the passport and request format match what the API expects.
+3. **Limits for messaging:** Under **limits.messaging** include at least **msgs_per_min**, **msgs_per_day**, and any **allowed_recipients** / **approval_required** your policy uses.
+
+**References:** [QUICKSTART.md](../QUICKSTART.md) (“Missing required capabilities: messaging.send”), [extensions/openclaw-aport/README.md](../../extensions/openclaw-aport/README.md) (config).
+
+---
+
+## After the two fixes
+
+1. **Test a full flow:** Run a benign command through the guardrail → ALLOW; run a blocked command → DENY. Then run the same via OpenClaw (e.g. “create a folder and list it”) to confirm enforcement.
+2. **Capture the screenshot** (terminal ALLOW/DENY) for the launch post.
+3. **Re-run the Quick Launch Checklist** so repo, docs, and screenshots are ready.
+4. **Then** run the launch sequence (Valentine post → engagement → guardrail post).
+
+**TL;DR:** The launch plan and story are in good shape. The product needs **allowed_commands** (including `bash` and the commands you use) and **capability alignment** (e.g. **messaging.send**) in the passport so the guardrail runs and passes in your real OpenClaw environment. Once the ALLOW/DENY demo works and is captured, you're clear to execute the plan.
+
+---
+
+## Status: action items complete
+
+The **exec mapping bug is fixed** and **messaging now honors L0** by default. The installer sets `allowed_commands: ["*"]` automatically, so the action items above (allowlist + capabilities) are complete. New installs get a working guardrail with no manual passport edits for normal use.

package/docs/launch/POST_1_VALENTINE_IMPROVED.md

@@ -0,0 +1,233 @@
+# Post 1: Valentine Story (Set the Stage)
+
+**Format:** X Article (recommended) or Long Post
+**Timing:** Post this FIRST (today or tomorrow morning)
+**Platform:** X/Twitter (primary), LinkedIn (optional, 24h later)
+
+---
+
+## Hook & Title
+
+### X Article Title Option 1 (Recommended):
+**"I Built an AI Agent to Run Valentine's Day (Here's What Broke)"**
+
+### X Article Title Option 2:
+**"OpenClaw + Cron + R2: Automating Valentine's Day Messages (And Why You Need Guardrails)"**
+
+### Short Post Hook (if not Article):
+**"I used OpenClaw to automate my wife's Valentine's Day: timed messages, surprise web pages, and a 'roses are here' trigger when UPS delivered. She loved it. The agent? Not so much."**
+
+---
+
+## Full Article Draft
+
+### Opening
+
+[IMAGE_PLACEHOLDER: Screenshot of Mac terminal showing `openclaw cron list` with valentine jobs OR a generic "message scheduling" screenshot — NO real messages/links]
+
+I wanted Valentine's Day to feel special this year, but I'm a builder—so I automated it.
+
+**The setup:**
+- **OpenClaw** running on my Mac (local agent, no servers)
+- **Cron jobs** for timed WhatsApp messages throughout the day
+- **Custom web pages** on Cloudflare R2 (romantic timeline, surprise reveals)
+- **One smart trigger:** A script that watched UPS tracking and sent a "roses are here" message the moment they were delivered
+
+**The result:** My wife said it was *"memorable and precious"* and thanked me for the thought and effort. Mission accomplished.
+
+---
+
+### The Technical Stack
+
+Here's what actually ran:
+
+```bash
+# Setup script created all the cron jobs
+./setup-valentine-final.sh
+
+# 9am Friday: "Will you be my Valentine?" + web page link
+# 12pm Friday: Romantic message
+# When UPS delivered: "48 roses on the way up!" (script-triggered)
+# 5pm Friday: "Get ready, we're going out at 6"
+# 9am Saturday: Wake-up message + preserved rose gift reveal + memory timeline page
+# 1pm, 3pm, 5pm, 7pm, 11pm Saturday: Messages tied to activities
+```
+
+Each message was sent via OpenClaw's WhatsApp integration. The web pages were static HTML hosted on R2 with gradients, embedded Spotify playlists, photo timelines—all generated by Claude and served at unique URLs.
+
+The UPS tracking script was the fun part: a bash loop that polled the tracking API every 15 minutes, and when status changed to "Delivered," it triggered the cron job immediately. No delays, no manual intervention.
+
+---
+
+### What Actually Broke
+
+**1. Message tool was too chatty**
+
+When the agent sent a romantic message, sometimes it included its own confirmation:
+
+```
+[My romantic message]
+
+Message sent to +1...
+Status: delivered ✓
+```
+
+So my wife would get *my* words plus *the agent's* meta-commentary. Not terrible, but not the clean "just from you" experience I wanted.
+
+**2. No limits on what the agent could do**
+
+The agent could:
+- Run ANY shell command (`rm -rf` included)
+- Access ANY file on my system
+- Send unlimited messages to any number
+- Deploy anything to R2 without restrictions
+
+For a controlled Valentine's setup, this was fine—I wrote the scripts, tested everything, kept the Mac awake for 2 days.
+
+But imagine:
+- A typo in the cron schedule that sends 100 messages instead of 10
+- A prompt injection that changes the message content
+- A bad command that wipes your deployed web pages
+- An agent that decides to "optimize" by sending all messages at once
+
+---
+
+### Why This Matters
+
+**This same stack—OpenClaw + cron + WhatsApp + file access—is what people are using for:**
+- Email automation
+- Code deployments
+- Database operations
+- Customer messaging
+- Financial transactions
+
+And most of them don't have guardrails.
+
+The Valentine's Day project was low-risk. But the pattern is everywhere: give the agent access, write a good prompt, hope it follows instructions.
+
+**That's not security. That's luck.**
+
+---
+
+### So We Built Guardrails
+
+After Valentine's, I added **pre-action authorization** to the stack:
+
+**Before the agent runs ANY tool:**
+1. Check: Is this command in the allowlist?
+2. Check: Does this operation exceed limits?
+3. Check: Is there a kill switch active?
+4. THEN: Allow or deny (no prompt negotiation)
+
+```bash
+# Every tool call goes through this now
+~/.openclaw/.skills/aport-guardrail.sh system.command.execute '{"command":"mkdir test"}'
+
+# Exit 0 = allowed, Exit 1 = denied
+# Reads passport + policies, writes structured decision
+```
+
+The agent can't bypass it. The prompt can't disable it. It runs at the platform level, before execution.
+
+**Same stack that made my wife's day special—now with "only these commands, only these limits, only these messages."**
+
+---
+
+### The Personal Part
+
+I'm not sharing the actual messages or the surprise pages—those stay between us. But her reaction was real:
+
+> *"Thank you for the intrigue, excitement, fun, and thoughtfulness you put into planning our Valentine celebration. I love you and I'm blessed to be loved by you."*
+
+Worth every hour of setup, testing, and one close call where I almost triggered a test message at 2am.
+
+---
+
+### Next Post
+
+Shipping the guardrails today. Local-first, 5-minute setup, works with OpenClaw out of the box.
+
+If you're building with agents—whether it's Valentine messages or production systems—you want this running before the agent does anything it can't undo.
+
+---
+
+**[End of Article]**
+
+---
+
+## Short Version (Regular Post, not Article)
+
+[IMAGE_PLACEHOLDER: Terminal showing `openclaw cron list` OR generic message scheduling screenshot]
+
+**I automated Valentine's Day with OpenClaw: timed WhatsApp messages, custom web pages on R2, and a script that sent "roses are here" when UPS delivered.**
+
+My wife loved it. She said it was "memorable and precious."
+
+**But the stack had issues:**
+- Message tool sometimes sent my text + a "Message sent" confirmation
+- Agent could run any command, access any file, send unlimited messages
+- No guardrails = hope the prompt is right
+
+For a one-off Valentine? Fine. For anything else? Scary.
+
+**So I built pre-action authorization:** check before every tool run. Same stack, now with allowlists, limits, and kill switches.
+
+Next post: shipping the guardrails. Local-first, 5-min setup, works with OpenClaw today.
+
+---
+
+## Image Suggestions
+
+**Option 1 (Recommended):** Screenshot of `openclaw cron list` showing valentine jobs (blur job IDs if needed, keep the names like "valentine-friday-0900")
+
+**Option 2:** Terminal showing the setup script output (generic, no personal info)
+
+**Option 3:** Generic "message scheduling" diagram: User → OpenClaw → WhatsApp
+
+**DO NOT USE:**
+- Real web page links or screenshots (keep the surprise private)
+- Actual message content
+- Your wife's phone number or personal photos
+- Gift photos or specific locations
+
+---
+
+## Platform-Specific Notes
+
+### X/Twitter
+- **Article preferred** for this one (better narrative flow, more engagement for stories)
+- Post time: Morning (8-10am ET) or evening (6-8pm ET) for max reach
+- Include 1-2 hashtags max: `#OpenClaw` `#AIAgents` (don't overdo it)
+
+### LinkedIn (Optional)
+- Post 24h after X post
+- Slightly more formal tone: "I used OpenClaw to automate a personalized Valentine's experience for my wife"
+- Emphasize: "Same patterns we see in production: agent access + good prompt ≠ security"
+- Link to X post for full story, or re-post the short version
+- Relevant hashtags: `#AIAutomation` `#OpenClaw` `#AIEngineering`
+
+---
+
+## Pre-Post Checklist
+
+- [ ] Choose Article vs Short Post (Article recommended)
+- [ ] Add ONE screenshot (terminal or generic diagram—no personal content)
+- [ ] Remove all placeholders from article text
+- [ ] Schedule Post 2 (Guardrail) for 8-24h later
+- [ ] Test all formatting (line breaks, code blocks, links)
+- [ ] Double-check: NO real web page URLs, NO personal info
+
+---
+
+## Why This Works
+
+Based on successful OpenClaw posts from 2025-2026:
+
+1. **Real outcome upfront:** "She loved it" = social proof
+2. **Technical depth:** Actual commands, stack details, UPS tracking script
+3. **Relatable problem:** "Message tool was chatty" = everyone's had this
+4. **One human quote:** Your wife's message = emotional anchor
+5. **Bridge to product:** "So we built X" in ONE sentence (not salesy)
+6. **Clear next step:** "Next post: shipping the guardrails"
+
+**Most important:** This positions you as a builder who ships, not a marketer. The Valentine story is genuine, the technical details are specific, and the problem (no guardrails) emerges naturally from the experience.

package/docs/launch/POST_2_GUARDRAIL_IMPROVED.md

@@ -0,0 +1,369 @@
+# Post 2: Guardrail Launch (Ship the Product)
+
+**Format:** Regular Post or 3-Tweet Thread (NOT Article)
+**Timing:** Post 8-24h AFTER Valentine post
+**Platform:** X/Twitter (primary), LinkedIn (same day or next day)
+
+---
+
+## Hook Options
+
+### Option 1 (Recommended - Direct):
+**"OpenClaw + APort: Pre-action guardrails that run before every tool call."**
+
+### Option 2 (Story callback):
+**"Yesterday I shared how I automated Valentine's with OpenClaw. Today: the guardrails that make it safe to ship."**
+
+### Option 3 (Problem-first):
+**"Your OpenClaw agent can run any command, access any file, and send unlimited messages. That's the default. Here's the fix."**
+
+---
+
+## Single Post Draft (Recommended)
+
+[IMAGE_PLACEHOLDER: Screenshot from `openclaw logs --follow` showing `[APort Guardrails] ALLOW: system.command.execute` and `[APort Guardrails] BLOCKED: …` back-to-back. Run a safe command (e.g. `mkdir test`) then a blocked `rm -rf /` so both entries appear in one frame.]
+
+**OpenClaw just got guardrails.**
+
+We shipped **APort for OpenClaw**: pre-action authorization that checks every tool call before it runs—no bypass, no "trust the prompt," no crossed fingers.
+
+- **Before every tool call** — Platform enforces, AI cannot skip
+- **Command allowlist** — Only approved commands (`mkdir`, `npm`, `git`, etc.)
+- **Blocked patterns** — No `rm -rf`, no `sudo`, 40+ attack patterns
+- **Message limits** — Rate caps, capability checks, no spam
+- **Local-first** — Passport + policies on your machine; optional API mode (tested today) for hosted passports / kill switch
+- **5-minute setup** — One command: `npx @aporthq/aport-agent-guardrails` (no clone); optional hosted passport via agent_id
+
+---
+
+**What this fixes (from the Valentine project):**
+
+1. **"Message tool was chatty"** → Now: Check message against limits before send
+2. **"Agent could run anything"** → Now: Only allowlisted commands execute
+3. **"No restrictions"** → Now: Passport defines exact capabilities + limits
+
+---
+
+**How it works:**
+
+```bash
+# The plugin calls this before EVERY tool
+~/.openclaw/.skills/aport-guardrail.sh system.command.execute '{"command":"mkdir test"}'
+
+# Decision: ALLOW → tool runs
+# Decision: DENY → tool blocked, reason logged
+```
+
+Optional API mode uses the same policy packs via `aport-guardrail-api.sh …` (today’s smoke tests covered both local + api).
+
+**Every tool call = fresh guardrail check. No caching, no reusing old decisions. If you update your passport, the next tool call reflects it.**
+
+---
+
+**Stack:**
+
+- **OpenClaw plugin:** `before_tool_call` hook (deterministic enforcement)
+- **Passport (OAP v1.0):** Your agent's identity + capabilities + limits
+- **Policies:** 4 out-of-box (commands, messaging, MCP, sessions) + extensible
+- **Local evaluator:** Runs on your machine, no API required
+- **Optional API mode:** Cloud features, audit trail, kill switch
+
+---
+
+**What's protected:**
+
+| Tool Category | Policy | Example Limits |
+|---------------|--------|----------------|
+| System commands | `system.command.execute.v1` | Allowlist: `mkdir`, `npm`, `git`<br>Blocked: `rm -rf`, `sudo`, `;`, `\|` |
+| Messaging | `messaging.message.send.v1` | Daily cap: 50 messages<br>Capability: WhatsApp only |
+| MCP tools | `mcp.tool.execute.v1` | Approved servers only |
+| Git operations | `code.repository.merge.v1` | Max PR size, review required |
+
+---
+
+**Try it:**
+
+→ Repo: https://github.com/aporthq/aport-agent-guardrails
+→ QuickStart: [5-minute setup](https://github.com/aporthq/aport-agent-guardrails/blob/main/docs/QUICKSTART_OPENCLAW_PLUGIN.md) · [aport.io/openclaw](https://aport.io/openclaw)
+→ Plugin docs: [How it works](https://github.com/aporthq/aport-agent-guardrails/blob/main/extensions/openclaw-aport/README.md)
+
+```bash
+# One command — no clone required
+npx @aporthq/aport-agent-guardrails
+# Wizard: passport (hosted or local), plugin install, smoke test. Done.
+# Have a passport from aport.io? npx @aporthq/aport-agent-guardrails <agent_id>
+```
+
+---
+
+**Same stack I used for Valentine's — now anyone can ship agent automation without the "hope it follows instructions" part.**
+
+#OpenClaw #AISecurity #AgentGuardrails
+
+---
+
+**[End of Post]**
+
+---
+
+## 3-Tweet Thread Version (Alternative)
+
+### Tweet 1/3:
+
+**OpenClaw just got guardrails.**
+
+We shipped **APort for OpenClaw**: pre-action authorization that checks every tool call before it runs.
+
+No bypass. No "trust the prompt." Platform enforces policy.
+
+- Command allowlist
+- Blocked patterns (40+)
+- Message limits
+- Local-first
+- 5-min setup
+
+🧵👇
+
+---
+
+### Tweet 2/3:
+
+**What this fixes:**
+
+Yesterday I shared how I automated Valentine's with OpenClaw. The stack worked—but had no guardrails:
+- Message tool was chatty (sent message + confirmation)
+- Agent could run ANY command
+- No limits on files, messages, deploys
+
+Now: passport defines exact capabilities. Guardrail checks before every tool.
+
+---
+
+### Tweet 3/3:
+
+**How it works:**
+
+```bash
+# Plugin calls this before EVERY tool
+aport-guardrail.sh system.command.execute '{"command":"mkdir test"}'
+
+# ALLOW → tool runs
+# DENY → blocked, reason logged
+```
+
+Every call = fresh check. Update passport → next tool reflects it.
+
+Try it: https://github.com/aporthq/aport-agent-guardrails
+
+[IMAGE: Terminal showing ALLOW + DENY]
+
+---
+
+## LinkedIn Version (Same Day or +24h)
+
+[IMAGE_PLACEHOLDER: Same as X post—terminal or config screenshot]
+
+**Announcing APort Agent Guardrails for OpenClaw**
+
+Last week I automated a personalized Valentine's Day experience for my wife using OpenClaw: timed WhatsApp messages, custom web pages, and a smart UPS tracking trigger. She loved it—she said it was "memorable and precious."
+
+But the stack had a problem: no guardrails.
+
+The agent could run any command, access any file, and send unlimited messages. For a controlled project, that was fine. For anything in production? That's a security incident waiting to happen.
+
+**So we built pre-action authorization:**
+
+Before OpenClaw runs ANY tool, a guardrail checks:
+- Is this command in the allowlist?
+- Does this operation exceed limits?
+- Are there blocked patterns (rm -rf, sudo, command injection)?
+- Is there a kill switch active?
+
+Only then does the tool execute. The agent can't bypass it. The prompt can't disable it. It runs at the platform level.
+
+**What's included:**
+
+- OpenClaw plugin (before_tool_call hook)
+- Passport system (OAP v1.0 - agent identity + capabilities)
+- 4 out-of-box policies (commands, messaging, MCP, git)
+- 40+ security patterns (injection, traversal, escalation)
+- Local-first evaluator (no API required)
+- Optional API mode (audit trail, kill switch, cloud features)
+
+**Setup: 5 minutes**
+
+```bash
+./bin/openclaw  # Creates passport, installs plugin
+```
+
+Every tool call gets a fresh guardrail check. No caching, no reusing decisions. Update your passport, and the next tool call reflects it immediately.
+
+---
+
+**This is the same pattern we see in production: agent access + good prompt ≠ security.**
+
+Guardrails make it deterministic: policy enforced before execution, every time.
+
+**Open source, MIT licensed, works with OpenClaw today.**
+
+→ GitHub: https://github.com/aporthq/aport-agent-guardrails
+→ QuickStart: [5-minute setup guide](https://github.com/aporthq/aport-agent-guardrails/blob/main/docs/QUICKSTART_OPENCLAW_PLUGIN.md)
+
+If you're building with AI agents—whether for personal projects or production systems—you want guardrails running before the agent does anything it can't undo.
+
+#AIAutomation #OpenClaw #AIEngineering #AIAgents #AISecurity
+
+---
+
+**[End of LinkedIn Post]**
+
+---
+
+## Image Suggestions
+
+**Option 1 (Recommended):** Terminal showing:
+```bash
+$ aport-guardrail.sh system.command.execute '{"command":"mkdir test"}'
+- ALLOW - Decision ID: dec_abc123
+
+$ aport-guardrail.sh system.command.execute '{"command":"rm -rf /"}'
+❌ DENY - Blocked pattern: rm -rf
+```
+
+**Option 2:** Screenshot of `passport.json` showing:
+```json
+{
+  "agent_id": "...",
+  "capabilities": ["system.command.execute", "messaging.message.send"],
+  "limits": {
+    "system.command.execute": {
+      "allowed_commands": ["mkdir", "npm", "git"]
+    }
+  }
+}
+```
+
+**Option 3:** Screenshot of `openclaw.json` plugin config showing the APort plugin enabled
+
+**Option 4:** Simple diagram:
+```
+Before: User → Agent → Tool (no checks)
+After:  User → Agent → Guardrail → Tool (policy enforced)
+```
+
+---
+
+## Technical Details to Emphasize
+
+These are what make this different from "agent safety" talks:
+
+1. **Every tool call = fresh verify:** No caching decisions, no "same command = same result"
+2. **Platform-level enforcement:** `before_tool_call` hook, not prompt engineering
+3. **Local-first:** Passport on your machine, optional API for features
+4. **Structured decisions (OAP v1.0):** JSON schema, tamper-evident, chainable audit
+5. **Real command allowlist:** Not "be careful," actual "these 10 commands only"
+6. **40+ blocked patterns:** Injection, traversal, escalation—tested and documented
+7. **Works today:** OpenClaw plugin installed, no core changes needed
+
+---
+
+## Timing Strategy
+
+### Recommended Timeline:
+
+**Day 1 (Today/Tomorrow):**
+- Post Valentine story (X Article)
+- Monitor engagement, reply to comments
+
+**Day 2 (8-24h later):**
+- Post Guardrail launch (X Post)
+- Same day: Post on LinkedIn (more formal version)
+- Pin the Guardrail post to your profile
+
+**Day 3-7:**
+- Reply to questions, share repo stats
+- Optional: Short technical thread on how `before_tool_call` works
+- Optional: Demo video showing setup
+
+---
+
+## Pre-Post Checklist
+
+- [ ] Valentine post is already live (or you're okay reversing order)
+- [ ] Replace all GitHub URLs with real links (test that they work)
+- [ ] Add ONE screenshot (from `openclaw logs --follow`, showing ALLOW + BLOCKED back-to-back)
+- [ ] Test code formatting (bash blocks, JSON snippets)
+- [ ] Verify repo is public and README is updated
+- [ ] Check that QUICKSTART_OPENCLAW_PLUGIN.md is live
+- [ ] Pin this post after Valentine post gets initial traction
+
+---
+
+## Why This Works
+
+Based on successful OpenClaw launches and what resonates in 2025-2026:
+
+1. **Clear outcome:** "Pre-action authorization" = immediately understandable
+2. **Technical proof:** Real commands, actual config, terminal output
+3. **Story callback:** References Valentine (continuity) but stands alone
+4. **Scannable:** Checkboxes, table, code blocks—easy to skim
+5. **One CTA:** GitHub repo link, everything else follows
+6. **No marketing fluff:** "We shipped X. Here's what it does. Try it."
+
+**Most important:** This positions the project as production-ready, technically sound, and immediately useful. The Valentine story showed the problem; this post delivers the solution.
+
+---
+
+## Response Strategy
+
+**When people ask common questions:**
+
+**Q: "Does this slow down the agent?"**
+A: "Sub-300ms for local evaluation. Every call is fresh—no caching—so you get current passport state. P95 is 268ms."
+
+**Q: "Can the agent bypass this?"**
+A: "No. Runs at platform level via `before_tool_call` hook. Agent never sees the guardrail—it just gets allowed/denied."
+
+**Q: "What if I want to allow something custom?"**
+A: "Edit passport.json, add command to allowlist. Next tool call checks new state. Takes 30 seconds."
+
+**Q: "Does this work with [other agent framework]?"**
+A: "OpenClaw plugin ships today. Generic evaluator works anywhere—Node.js, Python, bash. See docs for integration."
+
+**Q: "Is this on npm/Homebrew?"**
+A: "Not yet—GitHub clone + ./bin/openclaw for now. npm publish is on the roadmap."
+
+---
+
+## Success Metrics to Watch
+
+**Engagement:**
+- Likes/Retweets within 24h (target: 100+)
+- Comments asking setup questions (good signal)
+- GitHub stars (track daily)
+
+**Conversion:**
+- GitHub repo visits (check traffic)
+- Clones/forks (people trying it)
+- Issues/PRs (community adoption)
+
+**Reach:**
+- Quote tweets from OpenClaw community
+- Shares in AI/agent Discord servers
+- Mentions in newsletters/podcasts
+
+---
+
+## Follow-Up Content (Optional, Week 2+)
+
+If this gets traction, consider:
+
+1. **Technical deep-dive thread:** "How `before_tool_call` enforcement works under the hood"
+2. **Demo video:** 5-minute setup + showing ALLOW/DENY in real-time
+3. **Case study:** "30 days with guardrails: what got blocked, what we learned"
+4. **Comparison post:** "AGENTS.md vs Plugin: why prompts ≠ security"
+5. **Community showcase:** Retweet interesting use cases from early adopters
+
+---
+
+**The goal: Position this as the obvious security layer for anyone running OpenClaw agents. Valentine story → why you need it. This post → how to get it.**