@datafog/fogclaw 0.2.0 → 0.3.0

package/docs/specs/2026-02-17-feat-submit-fogclaw-to-openclaw.md

@@ -1,125 +0,0 @@
----
-slug: 2026-02-17-feat-submit-fogclaw-to-openclaw
-status: intake-complete
-date: 2026-02-17T01:56:00Z
-owner: sidmohan
-plan_mode: execution
-spike_recommended: yes
-priority: high
----
-
-# Submit FogClaw to OpenClaw official plugin channel
-
-## Purpose / Big Picture
-
-FogClaw is already installable and usable via the `@openclaw/fogclaw` package, and it now has repository-side submission readiness artifacts. This initiative is to prepare and execute the **next submission step**: opening and completing the cross-repository contribution in the OpenClaw ecosystem so the plugin can be discovered through official OpenClaw workflows.
-
-The outcome is observable when a maintainer-facing OpenClaw repo PR is opened with reproducible validation evidence and receives maintainer review status. A user should be able to verify this by checking the new upstream PR and the documented checklist that proves package identity, installability, hook/tool behavior, and testability in a clean environment.
-
-## Scope
-
-### In Scope
-
-- Identify the exact official OpenClaw submission path for plugins and prepare the required contribution artifacts for FogClaw.
-- Create a maintainer-facing submission PR in the OpenClaw repository using the already-merged `DataFog/fogclaw` release state.
-- Include submission evidence mapping between this repository and OpenClaw review expectations (package name/version, manifest, installation command, and reproducible test checks).
-- Add/confirm any minimal metadata or docs updates needed specifically for external submission in this repo (if required after upstream validation).
-- Track and document outcomes, open questions, and blockers in spec/plan artifacts.
-
-### Boundaries
-
-- No changes to detection logic, redaction strategies, or plugin runtime behavior.
-- No implementation changes to OpenClaw platform code.
-- No introduction of new dependencies or CI infrastructure in the plugin repo.
-- No security/privacy model changes; this effort only covers publication workflow and submission evidence.
-
-## Non-Goals
-
-- Reworking plugin internals or adding new plugin features.
-- Re-running full internal feature validation already completed in the plugin merge.
-- Creating a parallel package/brand strategy beyond the existing `@openclaw/fogclaw` identity.
-
-## Risks
-
-- OpenClaw may enforce additional fields, naming constraints, or review expectations that were not covered by the DataFog repo readiness work.
-- Upstream PR template may require evidence format changes from repo-local PR notes.
-- There may be a delay between contribution and maintainer review if expectations remain unclear.
-- Maintainers may request a packaging/metadata adjustment after we submit, requiring a follow-up PR.
-
-## Rollout
-
-- Use the already-merged `main` state of `DataFog/fogclaw` as the submission baseline.
-- Draft and open the OpenClaw submission PR with reproducible commands and exact expected outputs.
-- If OpenClaw maintainers request changes, loop through `respond-to-feedback` and reopen on the same submission branch.
-- Close the initiative once the upstream PR is accepted and merged, or route back to `he-implement` if repository changes are required.
-
-## Validation and Acceptance Signals
-
-- Reproducible local evidence command block exists and matches what is sent in the OpenClaw submission PR.
-- `@openclaw/fogclaw` package identity remains stable and points to the merged `DataFog/fogclaw` release state.
-- OpenClaw upstream PR reaches at least “ready for review” with all requested evidence attachments present.
-- The maintainer-facing PR includes explicit answers for submission criteria and known caveats (for example model/download behavior in constrained environments).
-
-## Requirements
-
-| ID | Priority | Requirement |
-|---|---|---|
-| R1 | high | Prepare a submission PR in the OpenClaw repo that references the `@openclaw/fogclaw` package and the merged DataFog commit history relevant for reviewers.
-| R2 | high | Include a clean check list in the OpenClaw PR body with outputs for `npm test`, `npm run build`, `npm run test:plugin-smoke`, and package manifest verification.
-| R3 | medium | Confirm any OpenClaw-specific metadata expectations (template fields, review checklist, review labels, or required docs) before requesting maintainer action.
-| R4 | medium | Capture and resolve any maintainer feedback by returning to local implementation only when repository edits are required.
-| R5 | low | Record submission status and next action in durable docs (`docs/plans/...` and open questions log).
-
-## Chosen Direction (Recommended)
-
-- Use a single upstream pull request targeting the designated OpenClaw repository path as the primary submission vehicle (recommended) because it minimizes fragmentation and matches standard contributor workflows. The risk is that external process details may require iteration.
-- A second, duplicate submission route should be avoided unless a maintainer explicitly requests it, because duplicate PRs tend to create conflicting discussions and slower review.
-
-## Open Questions
-
-- **[research]** What exact OpenClaw repository/path and PR template must FogClaw target for official plugin publication?
-- **[research]** Does OpenClaw require an additional manifest or catalog file update inside their own repository in addition to package metadata?
-- **[decision]** Should this initiative include one follow-up patch branch for any requested metadata changes, or remain submission-only until maintainer asks?
-- **[planning]** If additional upstream packaging adjustments are required, should those be merged through the current open submission branch or a fresh follow-up branch?
-
-## Success Criteria
-
-- A new OpenClaw-side PR is created with: plugin identity, install command, reproducible tests, and evidence of `src/index.ts` contract behavior.
-- The submission PR body cites the merged plugin-merge commit from `DataFog/fogclaw` as canonical source-of-truth.
-- Maintainers can reproduce the core checks from the PR body without guessing or adding setup instructions.
-- Any blocking submission questions are answered in the PR thread or captured in plan artifacts before proceeding to final merge.
-
-## Constraints
-
-- Only proceed with outward-facing submission work while preserving plugin behavior unchanged.
-- Keep all package names and registry scope aligned to `@openclaw/fogclaw` unless OpenClaw maintainer instruction requires a temporary exception.
-- Do not assume access to external OpenClaw maintainer accounts beyond normal GitHub contributor permissions.
-- Avoid changing internal plugin code until submission blockers are confirmed as code-level.
-
-## Tech Preferences
-
-- **Language/runtime**: TypeScript / Node.js (repository remains unchanged).
-- **Framework/API**: OpenClaw plugin API and GitHub PR process for upstream submission.
-- **Infrastructure**: GitHub CLI and repository PR workflow.
-- **Rationale**: Keeps this initiative low-risk and focused on process and reviewability rather than implementation.
-
-## Handoff
-
-- This spec should transition to `he-plan` once the exact OpenClaw target path and submission requirements are clear.
-- `he-plan` should define submission mechanics and maintainer-proof evidence formatting as separate milestones.
-- If significant process uncertainty remains after planning, first route to `he-research` for missing process facts.
-
-## Priority
-
-- priority: high
-- rationale: This is the final official publication step and required for wider ecosystem discoverability.
-
-## Initial Milestone Candidates
-
-- M1: Confirm official OpenClaw submission target and required review template/evidence format.
-- M2: Draft and open the upstream OpenClaw PR with reproducible checks, package identity, and maintainer-facing rationale.
-- M3: Respond to initial feedback loop and either land metadata fixes or close with explicit blocker notes.
-
-## Revision Notes
-
-- 2026-02-17T01:56:00Z: Initialized spec to formalize the cross-repo OpenClaw submission step after plugin readiness merge landed on `DataFog/fogclaw` main.

package/docs/specs/2026-02-17-feat-tool-result-pii-scanning-spec.md

@@ -1,122 +0,0 @@
----
-slug: 2026-02-17-feat-tool-result-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 tool results via tool_result_persist hook
-
-## Purpose / Big Picture
-
-FogClaw currently only scans the user prompt text (`before_agent_start`). The majority of PII entering an agent's context comes from **tool results** — file reads, web fetches, API calls, database queries. This content bypasses FogClaw entirely today.
-
-By hooking into OpenClaw's `tool_result_persist` lifecycle, FogClaw can scan and redact PII in tool results **before they are persisted to the session transcript**, closing the largest gap in FogClaw's coverage.
-
-## Scope
-
-### In Scope
-
-- Register a `tool_result_persist` hook handler in FogClaw's plugin registration
-- Extract text content from `AgentMessage` tool result payloads
-- Scan extracted text using the **regex engine only** (synchronous constraint)
-- Apply the existing `guardrail_mode`, `entityActions`, `redactStrategy`, and `allowlist` config to detected entities
-- Redact PII spans in tool result text content (all modes — redact, block, warn — produce span-level redaction in tool results)
-- Emit audit log entries for tool result detections when `auditEnabled: true`
-- Add unit tests for the new hook handler
-- Add integration test confirming the hook registers and transforms tool results
-
-### Boundaries
-
-- **No GLiNER on this path.** The `tool_result_persist` hook is synchronous-only; async handlers are rejected by OpenClaw. Regex covers structured PII (SSN, email, phone, credit card, IP, date, zip). Unstructured entity detection (person names, organizations) is out of scope for this hook.
-- **No `before_tool_call` hook.** This hook exists in OpenClaw's type system but has zero active invocation sites upstream. Will be addressed in a future initiative once OpenClaw wires it in.
-- **No `message_sending` hook.** Outbound message scanning is a separate priority.
-- **No scanning of `event.messages` history.** Historical message scanning is a separate priority.
-- **No new config surface.** Reuse existing FogClaw config — no `toolResultScanning` sub-object.
-- **No changes to OpenClaw upstream.** This initiative is FogClaw-only.
-
-## Non-Goals
-
-- Blocking tool execution (requires `before_tool_call`, which is not wired upstream)
-- Modifying files on disk
-- Scanning binary/image content in tool results
-- Real-time GLiNER inference on tool results
-
-## Risks
-
-- **Performance on hot path.** `tool_result_persist` runs synchronously on every tool result. Regex scanning is sub-millisecond for typical payloads, but very large tool results (e.g., reading a 10K-line file) could add measurable latency. Mitigation: benchmark and consider a size cap with configurable threshold.
-- **AgentMessage structure varies.** Tool results are typed as `AgentMessage`, whose internal structure depends on the tool and provider. Text extraction must handle multiple content formats without crashing on unexpected shapes. Mitigation: defensive extraction with fallback to no-op.
-- **Redaction alters tool output semantics.** Replacing `123-45-6789` with `[SSN_1]` in a tool result changes what the model sees. This is the intended behavior, but could cause unexpected downstream effects if the model tries to use the redacted value literally. Mitigation: this is inherent to the feature and matches existing `before_agent_start` behavior.
-
-## Rollout
-
-- Ship as part of next FogClaw patch release (0.1.7 or 0.2.0)
-- Enabled by default when FogClaw is enabled (no separate toggle)
-- Audit logging captures tool result scans for observability
-
-## Validation and Acceptance Signals
-
-- Unit tests pass for text extraction from various `AgentMessage` shapes
-- Unit tests pass for regex scanning + redaction of tool result content
-- Integration test confirms `tool_result_persist` hook registers via `api.on()`
-- Integration test confirms a tool result containing PII is transformed before persistence
-- Audit log entries are emitted for tool result detections
-- Existing `before_agent_start` tests continue to pass (no regression)
-- Manual verification: install FogClaw in OpenClaw, have agent read a file with PII, confirm session transcript shows redacted content
-
-## Requirements
-
-| ID | Priority | Requirement |
-|---|---|---|
-| R1 | critical | Register a `tool_result_persist` hook handler that scans tool result text for PII using the regex engine |
-| R2 | critical | Redact detected PII spans in tool result messages using the configured `redactStrategy` (token/mask/hash) |
-| R3 | critical | Handler must be synchronous (no Promises returned) — OpenClaw rejects async `tool_result_persist` handlers |
-| R4 | high | Apply existing `entityActions` and `guardrail_mode` config to determine per-entity action; all actions produce span-level redaction in tool results |
-| R5 | high | Respect existing `allowlist` config (global values, patterns, per-entity lists) |
-| R6 | high | Extract text content defensively from `AgentMessage` payloads — handle string content, array-of-content-blocks, and unexpected shapes without throwing |
-| R7 | medium | Emit audit log entry per tool result scan when `auditEnabled: true`, including tool name, entity count, and labels (no raw PII values in logs) |
-| R8 | medium | Skip scanning for tool results with no extractable text content (binary, empty, non-string) |
-| R9 | low | Include `source: "tool_result"` in audit log entries to distinguish from prompt-level scans |
-
-## Key Decisions
-
-- **Regex-only on hot path**: GLiNER is async and cannot run in a synchronous hook. Regex covers the 7 structured PII types (SSN, email, phone, credit card, IP, date, zip) at sub-millisecond latency. This is a deliberate tradeoff — unstructured entities (person names, orgs) are not scanned in tool results.
-- **Reuse existing config**: No separate config section for tool result scanning. The same `guardrail_mode`, `entityActions`, `redactStrategy`, and `allowlist` apply everywhere. Simpler mental model for users.
-- **Span-level redaction for all modes**: Even when `entityActions` says `block` for an entity type, the tool result is redacted at the span level (not replaced entirely). This preserves non-PII context for the agent while removing sensitive values.
-
-## Success Criteria
-
-- PII in tool results (file reads, web fetches, etc.) is redacted before entering the session transcript
-- Regex engine detects SSN, email, phone, credit card, IP, date, and zip in tool result content
-- No measurable latency impact for typical tool results (<1KB text)
-- Audit log captures tool result scan events with entity counts and labels
-- All existing tests pass; new tests cover the hook handler, text extraction, and edge cases
-
-## Constraints
-
-- `tool_result_persist` handler MUST be synchronous (OpenClaw constraint)
-- Must not introduce new dependencies
-- Must not change the existing `FogClawConfig` type (reuse existing fields)
-- Regex engine only — no ONNX/GLiNER on this path
-
-## Priority
-
-- priority: high
-- rationale: This closes the single largest gap in FogClaw's PII coverage. Tool results are the primary vector for PII entering agent context, and this hook is the only active interception point OpenClaw provides for that data flow.
-
-## Initial Milestone Candidates
-
-- M1: Text extraction utility — defensively extract text from `AgentMessage` tool result payloads, handling string content, content block arrays, and edge cases. Likely files: `src/extract.ts`, `tests/extract.test.ts`.
-- M2: `tool_result_persist` hook handler — register the hook, wire in regex scanning + redaction + audit logging, return transformed message. Likely files: `src/index.ts`, `tests/tool-result-hook.test.ts`.
-- M3: Integration smoke test — end-to-end test confirming a registered FogClaw plugin transforms a tool result containing PII. Likely files: `tests/plugin-smoke.test.ts` (extend existing).
-
-## Handoff
-
-After spec approval, proceed to `he-plan` for implementation breakdown. No spike needed — the OpenClaw hook contract is well-documented and the regex engine + redactor already exist in FogClaw.
-
-## Revision Notes
-
-- 2026-02-17T00:00:00Z: Initialized spec from template. Reason: establish intake baseline for tool result PII scanning via `tool_result_persist` hook.

package/docs/specs/README.md

@@ -1,5 +0,0 @@
-# Specs
-
-Store initiative specs here using one file per slug.
-Each spec must start with YAML frontmatter and set `plan_mode: lightweight|execution`.
-Store spike findings separately in `docs/spikes/`.

package/docs/specs/index.md

@@ -1,8 +0,0 @@
-# Specs Index
-
-Use this index to track initiative specs in `docs/specs/`.
-
-## Active Specs
-
-- `<slug>`: `docs/specs/<slug>-spec.md`
-

package/docs/spikes/README.md

@@ -1,8 +0,0 @@
-# Spikes
-
-Time-boxed investigations for uncertain/risky initiatives.
-Use the pattern `docs/spikes/<slug>-spike.md`.
-
-Spike docs should start with YAML frontmatter (see `docs/PLANS.md` for the artifact contract).
-
-Recommended sections: `Context`, `Validation Goal`, `Approach`, `Findings`, `Decisions`, `Recommendation`, `Impact on Upstream Docs`, `Spike Code`, `Remaining Unknowns`, `Time Spent`, and append-only `Revision Notes`.

package/fogclaw.config.example.json

@@ -1,33 +0,0 @@
-{
-  "enabled": true,
-  "guardrail_mode": "redact",
-  "redactStrategy": "token",
-  "model": "onnx-community/gliner_large-v2.1",
-  "confidence_threshold": 0.5,
-  "entityConfidenceThresholds": {
-    "PERSON": 0.6,
-    "ORGANIZATION": 0.7
-  },
-  "custom_entities": ["project codename", "internal tool name"],
-  "entityActions": {
-    "SSN": "block",
-    "CREDIT_CARD": "block",
-    "EMAIL": "redact",
-    "PHONE": "redact",
-    "PERSON": "warn"
-  },
-  "allowlist": {
-    "values": [
-      "noreply@example.com"
-    ],
-    "patterns": [
-      "^internal-"
-    ],
-    "entities": {
-      "PERSON": [
-        "john doe"
-      ]
-    }
-  },
-  "auditEnabled": true
-}

package/scripts/ci/he-docs-config.json

@@ -1,123 +0,0 @@
-{
-  "required_docs": [
-    "AGENTS.md",
-    "docs/PLANS.md",
-    "docs/DOMAIN_DOCS.md"
-  ],
-  "expected_runbooks": [
-    "docs/runbooks/update-agents-md.md",
-    "docs/runbooks/update-domain-docs.md",
-    "docs/runbooks/code-review.md",
-    "docs/runbooks/review-findings.md",
-    "docs/runbooks/address-review-findings.md",
-    "docs/runbooks/validate-current-state.md",
-    "docs/runbooks/reproduce-bug.md",
-    "docs/runbooks/pull-request.md",
-    "docs/runbooks/respond-to-feedback.md",
-    "docs/runbooks/verify-release.md",
-    "docs/runbooks/record-evidence.md",
-    "docs/runbooks/ci-failures.md",
-    "docs/runbooks/merge-change.md"
-  ],
-  "domain_docs": [
-    "docs/DESIGN.md",
-    "docs/DATA.md",
-    "docs/FRONTEND.md",
-    "docs/PRODUCT_SENSE.md",
-    "docs/RELIABILITY.md",
-    "docs/SECURITY.md",
-    "docs/OBSERVABILITY.md",
-    "docs/design-docs/core-beliefs.md"
-  ],
-  "required_headings": {
-    "docs/SECURITY.md": [
-      "## Threat Model",
-      "## Auth Model",
-      "## Data Sensitivity",
-      "## Compliance",
-      "## Controls"
-    ],
-    "docs/RELIABILITY.md": [
-      "## Reliability Goals",
-      "## Failure Modes",
-      "## Monitoring",
-      "## Operational Guardrails"
-    ],
-    "docs/FRONTEND.md": [
-      "## Stack",
-      "## Conventions",
-      "## Component Architecture",
-      "## Performance",
-      "## Accessibility"
-    ],
-    "docs/DESIGN.md": [
-      "## Design Principles",
-      "## Visual Direction",
-      "## Interaction Standards"
-    ],
-    "docs/PRODUCT_SENSE.md": [
-      "## Target Users",
-      "## Key Outcomes",
-      "## Decision Heuristics",
-      "## Quality Criteria"
-    ],
-    "docs/DATA.md": [
-      "## Data Model",
-      "## Migrations",
-      "## Backfills And Data Fixes",
-      "## Integrity And Consistency",
-      "## Sensitive Data Notes"
-    ],
-    "docs/OBSERVABILITY.md": [
-      "## Logging Strategy",
-      "## Metrics",
-      "## Traces",
-      "## Health Checks",
-      "## Agent Access"
-    ]
-  },
-  "artifact_placeholder_patterns": [
-    "<slug>",
-    "<YYYY-",
-    "<title>"
-  ],
-  "lint_completed_plans": true,
-  "required_spec_frontmatter_keys": [
-    "slug",
-    "status",
-    "date",
-    "owner",
-    "plan_mode",
-    "spike_recommended",
-    "priority"
-  ],
-  "required_plan_frontmatter_keys": [
-    "slug",
-    "status",
-    "phase",
-    "plan_mode",
-    "priority",
-    "owner"
-  ],
-  "required_spike_frontmatter_keys": [
-    "slug",
-    "status",
-    "date",
-    "owner",
-    "timebox"
-  ],
-  "drift_rules": [
-    {
-      "regex": "(^auth/|/auth/|^middleware/|/middleware/|(^|/)security/|(^|/)permissions/)",
-      "doc": "docs/SECURITY.md"
-    },
-    {
-      "regex": "(^infra/|^ops/|^deploy/|^terraform/|^k8s/|^helm/|(^|/)monitoring/|(^|/)alerts/)",
-      "doc": "docs/RELIABILITY.md"
-    },
-    {
-      "regex": "(^package\\\\.json$|^pnpm-lock\\\\.yaml$|^yarn\\\\.lock$|^bun\\\\.lockb$|^tsconfig\\\\.json$|^vite\\\\.config\\\\.|^next\\\\.config\\\\.)",
-      "doc": "docs/FRONTEND.md"
-    }
-  ]
-}

package/scripts/ci/he-docs-drift.sh

@@ -1,112 +0,0 @@
-#!/bin/bash
-set -euo pipefail
-
-REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." && pwd)"
-DEFAULT_CONFIG_PATH="scripts/ci/he-docs-config.json"
-
-config_path="${HARNESS_DOCS_CONFIG:-$DEFAULT_CONFIG_PATH}"
-config_file="${REPO_ROOT}/${config_path}"
-
-if [[ ! -f "$config_file" ]]; then
-  echo "Error: he-docs-drift missing/invalid config: Missing config '${config_path}'. Fix: create it (bootstrap should do this) or set HARNESS_DOCS_CONFIG." >&2
-  exit 2
-fi
-
-cfg="$(cat "$config_file")"
-if ! echo "$cfg" | jq -e 'type == "object"' >/dev/null 2>&1; then
-  echo "Error: he-docs-drift missing/invalid config: Config must be a JSON object." >&2
-  exit 2
-fi
-
-base_ref="${GITHUB_BASE_REF:-}"
-head_ref="${GITHUB_HEAD_REF:-}"
-
-if [[ -n "$base_ref" ]]; then
-  diff_range="origin/${base_ref}...HEAD"
-else
-  if git -C "$REPO_ROOT" rev-parse -q --verify HEAD~1 >/dev/null 2>&1; then
-    diff_range="HEAD~1...HEAD"
-  else
-    diff_range=""
-  fi
-fi
-
-echo "he-docs-drift: starting" >&2
-echo "Repro: bash scripts/ci/he-docs-drift.sh" >&2
-if [[ -n "$base_ref" ]]; then
-  echo "PR context: base_ref='${base_ref}' head_ref='${head_ref}' diff='${diff_range}'" >&2
-else
-  echo "Local context: diff='${diff_range}'" >&2
-fi
-
-if [[ -n "$diff_range" ]]; then
-  changed="$(git -C "$REPO_ROOT" diff --name-only "$diff_range" 2>/dev/null || true)"
-else
-  changed="$(git -C "$REPO_ROOT" diff-tree --no-commit-id --name-only -r HEAD 2>/dev/null || true)"
-fi
-
-# Trim empty lines
-changed="$(echo "$changed" | sed '/^[[:space:]]*$/d')"
-
-if [[ -z "$changed" ]]; then
-  echo "he-docs-drift: no changes detected"
-  exit 0
-fi
-
-# Build list of changed docs (files starting with docs/)
-changed_docs="$(echo "$changed" | grep '^docs/' || true)"
-
-# Extract drift_rules array; default to empty array if missing or wrong type
-drift_rules="$(echo "$cfg" | jq -c '.drift_rules // [] | if type == "array" then . else [] end')"
-rule_count="$(echo "$drift_rules" | jq 'length')"
-
-missing=0
-
-for ((i = 0; i < rule_count; i++)); do
-  rule="$(echo "$drift_rules" | jq -c ".[$i]")"
-
-  # Skip non-object entries
-  if ! echo "$rule" | jq -e 'type == "object"' >/dev/null 2>&1; then
-    continue
-  fi
-
-  regex="$(echo "$rule" | jq -r '.regex // empty')"
-  doc="$(echo "$rule" | jq -r '.doc // empty')"
-
-  if [[ -z "$regex" || -z "$doc" ]]; then
-    continue
-  fi
-
-  # Validate regex by testing it
-  if ! echo "" | grep -qE "$regex" 2>/dev/null && [[ $? -eq 2 ]]; then
-    echo "Error: invalid drift rule regex: ${regex}" >&2
-    missing=1
-    continue
-  fi
-
-  # Find changed files matching the regex
-  matching="$(echo "$changed" | grep -E "$regex" || true)"
-
-  if [[ -z "$matching" ]]; then
-    continue
-  fi
-
-  # Check if the required doc is in the changed docs list
-  if ! echo "$changed_docs" | grep -qxF "$doc" 2>/dev/null; then
-    sample="$(echo "$matching" | head -n 10 | sed 's/^/- /')"
-    echo "::error file=${doc},title=Docs drift gate::Missing required doc update '${doc}' when files match /${regex}/ (see job logs for matching files)."
-    echo "Missing doc update: '${doc}' should change when files match /${regex}/." >&2
-    echo "Matching files (up to 10):" >&2
-    echo "$sample" >&2
-    echo "Fix: update '${doc}' in this PR, or edit drift_rules in '${DEFAULT_CONFIG_PATH}' (or HARNESS_DOCS_CONFIG) if this mapping is wrong." >&2
-    missing=1
-  fi
-done
-
-if [[ "$missing" -ne 0 ]]; then
-  echo "Error: docs drift gate failed (see missing doc updates above)" >&2
-  exit 1
-fi
-
-echo "he-docs-drift: OK"
-exit 0