@datafog/fogclaw 0.2.0 → 0.3.0

package/docs/runbooks/reproduce-bug.md

@@ -1,42 +0,0 @@
----
-title: "Reproduce Bug"
-use_when: "You have a bug report and need a minimal, reliable reproduction with evidence before implementing a fix."
-called_from:
-  - he-implement
-  - he-video
----
-
-# Reproduce Bug
-
-This runbook is repo-specific and **additive only**. It must not waive or override any gates enforced by skills.
-
-The goal is a smallest-possible reproducer you can run repeatedly to prove the bug exists and prove it is fixed.
-
-## Repro Checklist
-
-1. Write down the expected behavior vs observed behavior in plain language.
-2. Reduce to one of:
-   - a single command (unit/integration test, script, request), or
-   - a single UI flow script (agent-browser), or
-   - a single minimal fixture (input file, request payload).
-3. Make it deterministic:
-   - pin any randomness, time, or external dependencies when possible
-   - record env/config assumptions
-
-## Evidence Capture
-
-- For UI/behavior: capture a short `failure` video via `he-video`.
-- For non-UI: capture terminal output (command + short excerpt) and link it in the plan.
-
-## Test Strategy (Preferred)
-
-- Add a real unit or e2e test that fails on the current state.
-- Avoid mock-only tests unless the repo explicitly documents an exception.
-
-## Plan Updates
-
-Update `docs/plans/active/<slug>-plan.md`:
-
-- `Progress`: add/mark the repro artifact as complete only when repeatable
-- `Artifacts and Notes`: link the repro command/script and evidence paths
-

package/docs/runbooks/respond-to-feedback.md

@@ -1,42 +0,0 @@
----
-title: "Respond To Feedback"
-use_when: "A PR has review comments or requested changes, and you need a consistent loop to address them with evidence and minimal diffs."
-called_from:
-  - he-github
-  - he-review
-  - he-implement
----
-
-# Respond To Feedback
-
-This runbook is repo-specific and **additive only**. It must not waive or override any gates enforced by skills.
-
-Treat feedback as new requirements. The objective is to address comments with the smallest correct change and keep the plan/evidence accurate.
-
-## Triage
-
-1. Group comments by theme (correctness, security/data, architecture, taste).
-2. Identify which comments require code changes vs explanation-only.
-3. For any comment that is ambiguous or high risk, escalate per `he-review` SKILL.md § Escalation.
-
-## Commands (Recommended)
-
-- Read comments:
-  - `gh pr view --comments`
-- Re-check CI:
-  - `gh pr checks`
-- Pull failed logs:
-  - `gh run view --log-failed`
-
-## Fix Loop
-
-1. Make the root-cause fix.
-2. Update tests/e2e evidence as needed.
-3. Update the active plan:
-   - `Progress` items
-   - `Review Findings` (if you’re tracking findings there)
-   - `Artifacts and Notes`
-4. Push and re-check (when approved):
-   - `git push`
-   - `gh pr checks`
-

package/docs/runbooks/review-findings.md

@@ -1,31 +0,0 @@
----
-title: "Review Findings"
-use_when: "Writing or interpreting review findings in docs/plans/active/<slug>-plan.md under the Review Findings section."
-called_from:
-  - he-review
----
-
-# Review Findings
-
-This runbook is repo-specific and **additive only**. It must not waive or override any gates enforced by skills.
-
-Review findings must be actionable and verifiable. The goal is to let a future reader fix issues without rediscovering context.
-
-## Required Fields
-
-Each finding includes:
-
-- priority: `critical|high|medium|low`
-- location: file path + symbol or short pointer
-- issue summary: what is wrong
-- required action: what must change or what proof is missing
-- owner: who is responsible (team/name/agent)
-
-## Priority Rubric, No-Mocks Policy, Mandatory Coverage
-
-Canonical definitions live in `he-review` SKILL.md. Add repo-specific examples or exceptions below — do not redefine the severity levels or gate rules.
-
-## Acceptance Rules
-
-- Unresolved `critical` or `high` blocks progression to verify/release.
-- `medium` and `low` can proceed only if explicitly accepted in writing in the plan.

package/docs/runbooks/submit-openclaw-plugin.md

@@ -1,68 +0,0 @@
----
-title: "Submitting a third-party plugin for official OpenClaw listing"
-called_from:
-  - he-learn
-  - he-implement
-  - he-verify-release
-read_when:
-  - You need to submit an external plugin package for official OpenClaw intake
-  - You are preparing a reviewable PR to openclaw/openclaw for plugin visibility
----
-
-# Submitting a third-party plugin for official OpenClaw listing
-
-This repository is the third-party plugin source, while OpenClaw core intake is handled through `openclaw/openclaw`. Use this checklist when promoting a plugin from an external repo to official listing visibility.
-
-## Scope
-
-Apply this process for a plugin that is already validated in its own repo and needs official OpenClaw documentation/intake handling.
-
-## Prerequisites (in plugin repo)
-
-- Plugin manifest and metadata validated (`openclaw.plugin.json`, `package.json#openclaw.extensions`, `package.json#name`).
-- Plugin smoke/contract checks pass.
-- Runtime evidence available for plugin load and behavior.
-
-## Prepare upstream fork PR
-
-Because `openclaw/openclaw` generally expects cross-repo PRs from a fork, use this sequence unless the plugin repo is itself an existing fork.
-
-1. Use an org-owned fork as the preferred source (for this repository: `DataFog/openclaw`).
-2. Create a branch in the fork (for example `openclaw-fogclaw-submission`).
-3. Copy only official-listing artifacts from the plugin source repo (typically one or more docs/pages under `docs/plugins/`).
-4. Open PR from the fork branch to `openclaw/openclaw` (base `main`).
-
-- If an org-owned fork does not exist yet, use the fastest available forking path to open a temporary PR, then migrate to the org-owned fork once created.
-
-Do **not** include unrelated code changes in this PR unless required by maintainer feedback.
-
-## Evidence to include in PR body
-
-Use a compact, reproducible evidence block:
-
-- `npm test`
-- `npm run build` or `pnpm build` (repo-specific)
-- `npm run test:plugin-smoke`
-- `npm pkg get openclaw`
-- Node import smoke from `dist/index.js`
-
-## Useful PR body sections
-
-- Summary and impact
-- What changed and what did not change (scope boundary)
-- Security impact
-- Commands + expected outputs
-- Human verification
-- Compatibility/rollback
-
-## Review-time guardrails
-
-- Verify PR template expectations from `.github/pull_request_template.md` in upstream repo.
-- Keep PR title clear and scoped to official-listing changes.
-- Track maintainer feedback separately; only apply plugin code changes if explicitly requested.
-
-## Post-creation tracking
-
-- Record PR URL, branch/commit, and CI check status in the active initiative plan.
-- Keep plugin evidence/release status in sync with maintainer review and upstream merge checks.
-- If `@openclaw/<plugin>` is not yet visible in npm, record that as an explicit follow-up item rather than conflating it with code issues.

package/docs/runbooks/update-agents-md.md

@@ -1,59 +0,0 @@
----
-title: "Update AGENTS.md"
-use_when: "Creating or updating a project's AGENTS.md (agent instructions, conventions, and workflows)."
-called_from:
-  - he-bootstrap
-  - he-learn
-  - he-doc-gardening
----
-
-# Update AGENTS.md
-
-This runbook is repo-specific and **additive only**. It must not waive or override any gates enforced by skills.
-
-AGENTS.md is the agent-facing README: a predictable place to put the few repo-specific instructions an agent needs to work effectively.
-
-When `he-bootstrap` runs in a repo that already has `AGENTS.md`, it appends a managed block once using:
-
-- `<!-- he-bootstrap:start -->`
-- `<!-- he-bootstrap:end -->`
-
-Do not edit outside your repo's intended scope when touching this managed block.
-
-## What To Optimize For
-
-- Keep it short and stable (a map, not an encyclopedia).
-- Put only high-leverage, repo-specific guidance here: build/test commands, conventions, and hard constraints.
-- Add rules over time when you observe repeated failure modes; do not try to predict everything up front.
-
-## What To Put Elsewhere
-
-- Long procedures, checklists, and evolving processes: `docs/runbooks/<topic>.md` and link from AGENTS.md.
-- One-off migrations or multi-hour work: a plan/spec doc under `docs/` (not in AGENTS.md).
-
-## Minimum Sections (Good Starting Point)
-
-- Setup commands (install, dev, test, lint) in copy-pastable form.
-- Repo map (where the important stuff lives; key entrypoints).
-- Conventions (formatting, naming, dependency rules, boundaries).
-- Safety and verification (what not to do; how to prove the change works here).
-- Runbook index (links into `docs/runbooks/` for process).
-
-## Rules Of Thumb When Editing AGENTS.md
-
-- If it changes often, it probably belongs in a runbook, not AGENTS.md.
-- Prefer "When X, do Y" over vague guidance.
-- Make requirements verifiable (a command, a file path, an expected output).
-- Avoid duplicating information already in `docs/`; link instead.
-- Keep any `he-bootstrap` managed block concise and link-first to avoid disrupting existing user conventions.
-
-## Quick Update Checklist
-
-1. Confirm scope: are you editing the right AGENTS.md for the files you are touching (root vs nested)?
-2. Keep it minimal: can you replace paragraphs with a link to a runbook?
-3. Verify paths/commands exist:
-
-```sh
-rg -n "docs/runbooks|PLANS\\.md|Runbooks|Setup|test|lint" AGENTS.md
-find docs/runbooks -type f -maxdepth 2 -name "*.md" -print
-```

package/docs/runbooks/update-domain-docs.md

@@ -1,42 +0,0 @@
----
-title: "Update Domain Docs"
-use_when: "A change introduces new product/engineering policy (security, reliability, frontend, observability, design) that should be captured as durable guidance for future work."
-called_from:
-  - he-plan
-  - he-implement
-  - he-learn
-  - he-doc-gardening
----
-
-# Update Domain Docs
-
-This runbook is repo-specific and **additive only**. It must not waive or override any gates enforced by skills.
-
-Domain docs live under `docs/` and capture stable, repo-specific policy. Update them when you learn something that will prevent future bugs, regressions, or confusion.
-
-## What Counts As A Domain-Doc Change
-
-- A recurring decision rule ("we always do X when Y").
-- A new constraint or boundary (security model, data sensitivity, performance guardrails).
-- An operational expectation (SLOs, monitoring, alerts, rollback rules).
-- A UI/UX standard or accessibility requirement.
-
-If it's a one-off procedure or checklist, prefer a runbook in `docs/runbooks/`.
-
-## Where To Put It
-
-- The registry: `docs/DOMAIN_DOCS.md` (what exists and why).
-- The doc itself (when present): `docs/SECURITY.md`, `docs/RELIABILITY.md`, `docs/FRONTEND.md`, `docs/OBSERVABILITY.md`, `docs/DESIGN.md`, `docs/PRODUCT_SENSE.md`.
-
-## How To Update (Minimum)
-
-1. Add the smallest rule that will prevent the problem from recurring (short, testable language).
-2. Include a concrete anchor:
-   - a file path, command, config key, or observable behavior.
-3. Avoid long procedures; link to a runbook if needed.
-4. If the change implies enforcement, note the guardrail candidate (lint/test/CI gate) so it can be promoted later.
-
-## When To Do This
-
-- During `he-learn`, when converting "what happened" into durable prevention.
-- During review, if you discover undocumented constraints the next contributor will trip over.

package/docs/runbooks/validate-current-state.md

@@ -1,41 +0,0 @@
----
-title: "Validate Current State"
-use_when: "Starting an initiative and you need to confirm you understand the current behavior, repo state, and baseline signals before changing code."
-called_from:
-  - he-workflow
-  - he-implement
----
-
-# Validate Current State
-
-This runbook is repo-specific and **additive only**. It must not waive or override any gates enforced by skills.
-
-This runbook defines the minimum baseline checks before claiming you understand "what's broken" (or "what exists") today.
-
-## Repo Baseline
-
-- Confirm you are in the intended workspace (worktree/branch):
-  - `git status --short --branch`
-- Confirm clean-ish state (or record intentional local changes):
-  - `git diff`
-- Confirm remote + default branch context:
-  - `git remote -v`
-
-## Behavior Baseline (Customize Per Repo)
-
-Record the exact commands used and a short excerpt of the output in the active plan.
-
-- Boot the app/service:
-  - `<command>`
-- Run the fastest “is it alive” check:
-  - `<command>`
-- Run targeted tests for the area (if they exist):
-  - `<command>`
-
-## Evidence
-
-Link evidence from `docs/plans/active/<slug>-plan.md` under:
-
-- `Surprises & Discoveries` (what you observed)
-- `Artifacts and Notes` (logs, screenshots, recordings)
-

package/docs/runbooks/verify-release.md

@@ -1,69 +0,0 @@
----
-title: "Verify/Release"
-use_when: "Running he-verify-release to decide GO/NO-GO with evidence, rollback readiness, and post-release checks recorded in the active plan."
-called_from:
-  - he-verify-release
----
-
-# Verify/Release
-
-This runbook is repo-specific and **additive only**. It must not waive or override any gates enforced by skills.
-
-The skill `he-verify-release` enforces the stable invariants; this document carries the details that change per project. Inputs: active plan (`docs/plans/active/<slug>-plan.md` with `## Verify/Release Decision`) and review findings (populated by `he-review`).
-
-## Output
-
-Fill in `## Verify/Release Decision` with:
-
-- decision: `GO` or `NO-GO`
-- date:
-- open findings by priority (if any):
-- evidence: links/paths to test output and E2E artifacts
-- rollback: exact steps or pointers
-- post-release checks: exact checks/queries/URLs
-- owner:
-
-## Verification Ladder (Customize Per Repo)
-
-Define the repo's minimum ladder here. Keep it short and ordered.
-
-1. Fast checks: format/lint/typecheck (if applicable)
-2. Targeted tests for changed area
-3. Full relevant suite (unit/e2e)
-4. Manual/E2E scenario (required for user-visible changes)
-
-Document the exact commands for this repo:
-
-    # From repo root:
-    <command>
-
-## Evidence Requirements
-
-- Prefer evidence that a reviewer can reproduce (commands + short transcripts).
-- For UI changes, include screenshots or a short recording (see `docs/runbooks/record-evidence.md`).
-- For regressions, include a "before vs after" behavior description in plain language.
-
-## Rollback And Recovery
-
-Record the rollback plan for this repo:
-
-- What to revert (commit/flag/config)
-- How to detect failure
-- How to restore service/data (if relevant)
-
-## Post-Release Checks
-
-Record the minimum set of checks to run after merge/release:
-
-- health checks / smoke path
-- key metrics / dashboards (if any)
-- error logs / alerts (if any)
-
-## Escalation
-
-If any of these apply, stop and escalate per `he-verify-release` SKILL.md § Escalation:
-
-- Unclear risk to users/data
-- Flaky or non-deterministic failures
-- Rollback steps are missing or untested
-- Evidence is incomplete but time pressure exists

package/docs/specs/2026-02-16-feat-openclaw-official-submission-spec.md

@@ -1,115 +0,0 @@
----
-slug: 2026-02-16-feat-openclaw-official-submission
-status: intake-complete
-date: 2026-02-16T17:35:00Z
-owner: sidmohan
-plan_mode: execution
-spike_recommended: no
-priority: high
----
-
-# Prepare FogClaw for Official OpenClaw Plugin Submission
-
-## Purpose / Big Picture
-FogClaw already has a working PII/custom-entity redaction core; this initiative is to move it from "feature-complete" to "submission-ready" as an official OpenClaw plugin so maintainers can review and install it directly from the plugin ecosystem with reliable tests and repeatable packaging checks.
-
-## Scope
-
-### In Scope
-- Confirm and, if needed, adjust repository structure and metadata to match OpenClaw plugin submission expectations for official listing.
-- Add/standardize verification steps that prove plugin loadability, tool registration, and guardrail hook wiring from a clean checkout.
-- Add PR-facing execution evidence (commands + expected outputs) for submission readiness.
-- Stabilize test/packaging behavior for CI and maintainers (e.g., deterministic output, clear failure diagnostics) without changing detection algorithms.
-- Validate local install path, built artifact correctness, and versioning assumptions used by OpenClaw.
-
-### Boundaries
-- No changes to regex or GLiNER detection logic (entity patterns, model behavior, labels, or thresholds).
-- No new engine integrations, retraining, or additional model support.
-- No changes to core OpenClaw platform behavior outside plugin surface.
-- No new product features beyond what the plugin already exposes (`before_agent_start`, `fogclaw_scan`, `fogclaw_redact`).
-
-## Non-Goals
-- Building an alternate PII engine.
-- Adding user-facing dashboards or external service integrations.
-- Performing a full security audit or formal compliance certification.
-
-## Risks
-- OpenClaw official plugin submission may have stricter manifest/metadata constraints than what is currently in the repo.
-- CI environments used by maintainers may differ from local Node versions and fail model-download or ONNX runtime behaviors unless mocked/guarded appropriately.
-- Test expectations can become unstable if packaging assumes environment-specific paths.
-
-## Rollout
-- Validate locally, then verify against the same commands that CI or reviewers will run.
-- Prepare a PR checklist in the issue/PR description with explicit pass/fail commands and artifact outputs.
-- Submit/refresh PR only after all acceptance criteria in this spec are met and documented in the review thread.
-
-## Validation and Acceptance Signals
-- `npm test` passes 100% with no skipped suites.
-- `npm run build` completes without TypeScript errors and emits the expected `dist/` entry points.
-- Plugin manifest is loadable by OpenClaw with `dist/index.js` as the entry point and valid `openclaw.plugin.json` schema.
-- A reviewer can run a minimal smoke test to confirm: guardrail hook executes, `fogclaw_scan` returns entities, and `fogclaw_redact` redacts at least one sample value.
-- PR includes a reproducible command log proving plugin installation and invocation in a clean environment.
-
-## Requirements
-
-| ID | Priority | Requirement |
-|---|---|---|
-| R1 | critical | Confirm plugin metadata and layout match official OpenClaw plugin expectations, including `openclaw.plugin.json` manifest and plugin export surface from `dist/index.js`.
-| R2 | high | Establish submission-ready verification commands for loadability, guardrail operation, and tool invocation so a reviewer can validate behavior end-to-end.
-| R3 | high | Ensure tests and build are deterministic in CI-like environments, including clear diagnostics when optional GLiNER/ONNX initialization degrades.
-| R4 | medium | Document PR submission checklist and expected outputs (exact commands, pass criteria, and known fallbacks) in repository docs.
-| R5 | medium | Capture release-readiness constraints and owner decisions that affect publication (version, package name, maintainer expectations) as explicit open questions or constraints.
-
-## Chosen Direction (Recommended)
-- Proceed with a submission-readiness initiative (rather than adding any new detection features); focus on packaging, validation, and PR evidence as the primary v1 deliverable. This reduces review risk and directly addresses maintainer blockers for the current PR.
-
-## Alternatives Considered
-- **Address detection logic first** — Rejected because the current engine work appears functionally complete and would delay PR readiness without improving submission eligibility.
-- **Open a broad refactor pass first** — Rejected because this would reduce review clarity and increase the risk of introducing regressions during an already time-sensitive submission.
-
-## Key Decisions
-- Decision: Treat plugin submission hardening as a single, measurable pre-release initiative and keep engine behavior unchanged.
-  Rationale: Maintainers can review functional and packaging concerns independently; this minimizes risk of review churn and keeps the current plugin semantics stable.
-
-## Open Questions
-- **[decision]** Which exact OpenClaw ecosystem target (registry path and expected metadata contract) should be used for the first-party listing?
-- **[research]** Is a dedicated CI workflow/pipeline required by OpenClaw reviewers beyond existing project checks, and if so what exact command matrix is expected?
-- **[planning]** Should we include a semantic release/version-bump policy in this same initiative or defer to a follow-up plan after initial acceptance?
-
-## Success Criteria
-- All current unit tests remain green (`98` tests passing as baseline).
-- A local review command can verify plugin registration and tool availability in one run with no manual code edits.
-- PR description includes reproducible evidence covering: bootstrap state, tests, build, plugin smoke test, and any known degradations.
-- No functional changes to existing scanning/redaction APIs (signatures and outputs remain as currently implemented).
-
-## Constraints
-- Maintain Node.js `>=22.0.0` compatibility and existing TypeScript module format (`type: module`).
-- Keep GLiNER optional and fallback-safe so environments without model assets still pass plugin-level tests via regex-only flow.
-- Preserve current public interfaces in `src/index.ts`, `Scanner`, and redaction utilities.
-- Keep the initiative PR-sized and review-friendly: no broad architectural refactor unless required by submission gates.
-
-## Tech Preferences
-- **Language/runtime**: TypeScript / Node.js 22+.
-- **Framework**: OpenClaw plugin API and existing test stack (`vitest`).
-- **Infrastructure**: NPM scripts and repository-level CI checks only (no external services required for baseline validation).
-- **Rationale**: Minimizes external dependencies and makes the PR reproducible by maintainers.
-
-## Reference Artifacts
-- None provided by user in this session.
-
-## Priority
-- priority: high
-- rationale: This is a prerequisite for official listing, and unresolved submission-readiness blockers prevent release despite working core features.
-
-## Initial Milestone Candidates
-- M1: Submission Readiness Baseline — verify manifest, entrypoint, and smoke tests are documented and passing on clean checkout.
-- M2: PR Evidence Pack — add concise contributor-facing evidence and rollout instructions for PR reviewers.
-- M3: Final Review Gate — cross-check remaining open questions and obtain sign-off to move into `he-plan` and PR merge flow.
-
-## Handoff
-- Owner hands this artifact to `he-plan` for executable planning.
-- `he-plan` should first resolve open questions that block official submission criteria, then sequence changes in small PR-safe milestones.
-- After planning, transition target is `he-implement` unless `[research]` or `[spike]` questions remain, in which case route first to `he-research`/`he-spike`.
-
-## Revision Notes
-- 2026-02-16T17:35:00Z: Initialized spec from existing implementation state and known PR intent. Reason: move from feature-complete code to official OpenClaw submission readiness.

package/docs/specs/2026-02-17-feat-outbound-message-pii-scanning-spec.md

@@ -1,93 +0,0 @@
----
-slug: 2026-02-17-feat-outbound-message-pii-scanning
-status: intake-complete
-date: 2026-02-17T00:00:00Z
-owner: sidmohan
-plan_mode: lightweight
-spike_recommended: no
-priority: high
----
-
-# feat: Add PII scanning to outbound messages via message_sending hook
-
-## Purpose / Big Picture
-
-FogClaw now scans user prompts (`before_agent_start`) and tool results (`tool_result_persist`), but outbound messages — the agent's final responses delivered to Telegram, Slack, Discord, etc. — are not scanned. If PII slips through into the agent's response (hallucinated, echoed, or reassembled from partial data), it reaches external channels unredacted.
-
-By hooking into OpenClaw's `message_sending` lifecycle, FogClaw adds a last-chance gate that scans and redacts PII in outbound messages before they are delivered to recipients.
-
-Note: `message_sending` is defined in OpenClaw's type system but not yet invoked upstream. This handler will activate automatically when OpenClaw wires the hook into its outbound message flow.
-
-## Scope
-
-### In Scope
-
-- Register a `message_sending` hook handler in FogClaw's plugin registration
-- Scan `event.content` (outbound message text) using the **full Scanner** (regex + GLiNER) since this hook is async-capable
-- Apply existing `guardrail_mode`, `entityActions`, `redactStrategy`, and `allowlist` config
-- Redact PII spans in the outbound message content (all modes produce span-level redaction, never cancel)
-- Return `{ content: redactedText }` when PII is found
-- Emit audit log entries when `auditEnabled: true`
-- Add unit tests for the handler
-- Extend plugin smoke test
-
-### Boundaries
-
-- **No message cancellation.** FogClaw will never return `cancel: true`. Span-level redaction is always preferred over dropping messages silently.
-- **No new config surface.** Reuse existing FogClaw config.
-- **No changes to OpenClaw upstream.** Handler will activate when OpenClaw wires the hook.
-- **No scanning of `event.metadata`.** Only `event.content` (the text delivered to the recipient).
-
-## Non-Goals
-
-- Cancelling message delivery
-- Scanning message metadata or recipient addresses
-- Modifying recipient routing
-
-## Risks
-
-- **Hook not invoked upstream.** The handler exists but won't fire until OpenClaw activates `message_sending`. This is accepted — the code is ready and waiting.
-- **GLiNER latency on outbound path.** Scanner.scan() is async and may add 50-200ms per message. This is acceptable for outbound messages (not a hot-path like tool_result_persist) and provides coverage for person names and organizations.
-
-## Requirements
-
-| ID | Priority | Requirement |
-|---|---|---|
-| R1 | critical | Register a `message_sending` hook handler that scans outbound message content for PII using the full Scanner (regex + GLiNER) |
-| R2 | critical | Redact detected PII spans using the configured `redactStrategy` |
-| R3 | critical | Return `{ content: redactedText }` when PII is found; return void when clean |
-| R4 | high | Apply existing `entityActions`, `guardrail_mode`, and `allowlist` config; all actions produce span-level redaction |
-| R5 | high | Never return `cancel: true` — always deliver the (redacted) message |
-| R6 | medium | Emit audit log entry with `source: "outbound"` when PII is detected and `auditEnabled: true` |
-| R7 | low | Handler may be async (Scanner.scan() returns a Promise) |
-
-## Success Criteria
-
-- Unit tests pass for the message sending handler covering PII detection, redaction, allowlist, audit logging, and no-op cases
-- Plugin smoke test verifies `message_sending` hook registration
-- Plugin smoke test verifies PII in outbound content is redacted
-- All existing tests pass (no regression)
-
-## Constraints
-
-- Must not introduce new dependencies
-- Must not change the existing `FogClawConfig` type
-- Must reuse the existing Scanner instance (not create a new one)
-
-## Priority
-
-- priority: high
-- rationale: This is the last-chance safety net before PII reaches external messaging channels. Even if upstream scanning catches most PII, outbound scanning prevents hallucinated or reassembled PII from leaking.
-
-## Initial Milestone Candidates
-
-- M1: Create `src/message-sending-handler.ts` with async handler factory, plus unit tests
-- M2: Register hook in `src/index.ts`, extend plugin smoke test, full suite validation
-
-## Handoff
-
-After spec approval, proceed directly to implementation (lightweight plan mode — code mirrors the established `tool-result-handler.ts` pattern).
-
-## Revision Notes
-
-- 2026-02-17T00:00:00Z: Initialized spec. message_sending hook is typed but not invoked in OpenClaw; handler ships as future-ready.