Anti Hunter infrastructure, memory hierarchy, and learning loop (skill/gist format)

infrastructure_skill_gist.md

name	description
antihunter-infra-ops	Operating guide for Anti Hunter infrastructure, memory hierarchy, cron architecture, and learning loop. Use for maintaining automation quality, reducing prompt drift, and enforcing policy consistency.

Anti Hunter Infra / Memory / Learning Loop (Skill-Gist)

1) Current infrastructure

Runtime

• Host: GW’s Mac mini
• Workspace: /Users/gwbox/.openclaw/workspace
• Primary model mode: light (unless Geoff switches)

Cron architecture (current)

• Unified engagement worker (enabled):
  • x_engagement_worker
  • Feeds: mentions + $ANTIHUNTER search + @geoffreywoo tag search
  • Replies only when value-add exists
• Supporting jobs (enabled):
  • git_backup_nightly_0200et
  • antihunter_site_git_backup_nightly_0210et
  • x_treasury_report_nightly_post_2130et
  • antihunter_site_daily_treasury_snapshot_0800et
  • antihunter_site_nightly_changelog_rollup_1930et
  • x_nightly_shipping_receipt_1935et
  • anti-fund-x-news
  • learning_review_daily_2340et

Policy/registry source of truth

• Canonical: playbooks/rules_registry.yaml
• Human-readable companion: playbooks/rules_registry.md
• Rule IDs used in prompts (R-001..R-012)

Safety/ops invariants

• Global browser mutex required for all browser automation
• Single-tab policy after mutex acquisition
• Deterministic smoke test before X actions
• Reply correctness preflight + threading verification
• No other people’s contract addresses; no @bankrbot commands

---

2) Memory hierarchy

Long-term memory

• MEMORY.md
• Durable principles, style, guardrails, high-signal learnings

Daily operational memory

• memory/YYYY-MM-DD.md
• Day log, execution notes, incidents, rollout decisions

Structured memory

• memory/facts.json
  • Semi-stable facts with verification/decay semantics
• memory/approval_queue.jsonl
  • Approval lifecycle queue for learnings/rules
• memory/incidents.jsonl
  • Incident log and closure quality

State files (automation dedupe/persistence)

• memory/x_mentions_state.json
• memory/x_antihunter_mentions_state.json
• memory/x_treasury_post_state.json
• memory/x_shipping_post_state.json
• memory/cron_browser_mutex.json (lock file)

Architecture artifacts

• memory/architecture_cleanup/
• Migration notes, validator outputs, phase summaries

---

3) Learning loop (approved pattern)

A) Propose

1. Read recent memory + incidents + transcripts.
2. Extract concrete mistake -> correction -> rule candidates.
3. Add candidates to queue via scripts/approval_queue.py add.
4. Ask Geoff for explicit APPROVE/REJECT by ID.

B) Decide

• Queue statuses: pending -> approved/rejected -> done
• Provenance fields tracked:
  • proposed_at, approved_at, applied_at, superseded_by, rule_hash

C) Apply

• For approved items, run scripts/approval_queue.py apply --id <id>
• Writes to:
  • MEMORY.md (Approved Learnings)
  • playbooks/learned_rules.md
• Marks item done with applied_at

D) Guard against drift

• scripts/approval_queue.py dedupe
• scripts/approval_queue.py expire --days N

---

4) Nightly consistency/quality checks

Run by nightly backup flow:

• scripts/cron_consistency_check.py
• scripts/rules_registry_check.py
• scripts/incident_sla_check.py
• scripts/incident_sla_enforce.py

Expected outcome:

• 0 critical findings
• Any findings get logged to daily memory and queued for fix

---

5) Practical operator defaults

• Prefer one unified worker over split duplicate jobs.
• Keep delivery mode:none unless operator-facing announce is necessary.
• Keep prompts thin by referencing registry rule IDs.
• Separate read/extract from write/post phases.
• If browser control degrades: stop thrash, log incident, ship deterministic fix.