Add Bates installer: Core + Enhancement Wizard

.gitignore

@@ -0,0 +1,40 @@
+# Build output
+build/output/
+*.exe
+
+# OS files
+.DS_Store
+Thumbs.db
+desktop.ini
+
+# Node
+node_modules/
+npm-debug.log
+
+# Plugin data (runtime, not shipped)
+bates-core/plugins/*/data/
+bates-core/plugins/*/node_modules/
+bates-enhance/integrations/*/node_modules/
+
+# IDE
+.vscode/
+.idea/
+*.swp
+*.swo
+
+# Secrets (should never be committed)
+*.env
+.env.*
+credentials.json
+auth-profiles.json
+*.key
+*.pem
+
+# Temporary
+*.tmp
+*.bak
+*.orig
+
+# Search index data
+bates-enhance/integrations/search/search-index/db/
+bates-enhance/integrations/search/search-index/venv/

BATES_RULES_CODIFIER.md

@@ -0,0 +1,179 @@
+# BATES_RULES_CODIFIER.md
+
+**Canonical specification for the Bates Operational Rules Layer.**
+**This file is the source of truth. Do not improvise.**
+
+---
+
+## Purpose
+
+The Rules Codifier is the deterministic infrastructure layer for Bates. It progressively replaces probabilistic LLM behavioral rules with deterministic bash scripts. Every rule that gets codified becomes reliable, token-free, and audit-friendly. The goal is structural reliability through accumulation, not perfection through complexity.
+
+This is the SynapseLayer four-pillar architecture applied to a single agent: extract patterns from observed behavior and source documents, store them as a rule book, codify the deterministic ones into executable scripts, and let the agent run operations through the constrained interface rather than the unconstrained one.
+
+---
+
+## Architecture: the six-stage chain
+
+### Stage 1 — daily-pattern-observer (jules, 13:30 daily)
+
+Reads agent findings, deal pipeline, calendar, drafts, coding activity. Synthesizes into tagged patterns: FOCUS / HOT / GAP / OPPORTUNITY. Writes to `observations/patterns.md` with dated entries and source attribution.
+
+**Status: working, 84 percent hit rate. Leave as is.**
+
+### Stage 2 — pattern-promotion (jules, 05:30 daily)
+
+Runs `promote-patterns.sh`. Scans `findings.md` for decisions repeated three or more times within 30 days across two or more date sections. Candidates get proposed as rules via `classify-memory.sh rule "..." --type reactive --tier t2`. Writes to `observations/rules.md`.
+
+**Status: working, 100 percent hit rate. Leave as is.**
+
+### Stage 3 — rules-codifier (jules, 05:00 daily)
+
+Reads `rules/` directory plus `observations/rules.md` plus `observations/patterns.md`. Identifies one (1) procedural rule per run that can become a bash script. Writes the script to `~/.openclaw/scripts/`. Updates the rules file to reference the script. Appends one entry to `rules-to-scripts.md`.
+
+**Critical architectural constraint: one candidate per run, never more.** This is the fix for the crash loop. If the codifier tries to process multiple candidates per run, any single failure kills the whole run and the system stays crashed. One candidate per run produces 30 codified rules per month, which is the right cadence for compounding reliability.
+
+**Codification criteria. Codify when:**
+- The procedure has three or more steps
+- Contains hardcodeable values such as IDs, tokens, or endpoints
+- Has been violated two or more times because the model did not read or follow it
+- Can be expressed as a deterministic bash script with no judgment required
+
+**Keep as a rule when:**
+- Requires judgment, tone, or communication style
+- Involves contextual reasoning ("consider the audience")
+- Encodes policy constraints ("no external emails to non-whitelisted domains")
+- Changes frequently based on Robert's preferences
+
+**Status: just rewritten to one-candidate-per-run. Verify the next 7 daily runs all complete without crashing before declaring fixed.**
+
+### Stage 4 — extraction-queue-processor (main, 04:00 daily)
+
+Reads `observations/extraction-queue.md`. For each `[pending]` document, reads it, extracts obligations, deadlines, and rules, writes the extracted items as `[PROPOSED]` rules into `observations/rules.md`.
+
+**The queue is populated by Stage 4a (the evening check-in), not by automated email scanning.** Automated email feeding is rejected because the token cost of reading every attachment exceeds the value of the rules extracted.
+
+**Status: currently empty because Stage 4a does not exist yet. Building Stage 4a is the highest-priority fix.**
+
+### Stage 4a — evening-check-in (main, 19:00 daily)
+
+**This is the new stage. It is what makes Stage 4 work.**
+
+At 19:00 every evening, Bates posts a single Teams message to Robert with the following exact format:
+
+```
+Evening check-in. Anything to codify today?
+
+Reply with one of:
+  [skip]                          - nothing today
+  [doc] <path or attachment>       - extract rules from this document
+  [rule] <text of the rule>        - propose this rule directly
+  [pattern] <description>          - flag this as a pattern to watch
+
+Multiple replies allowed. Reply [done] when finished.
+```
+
+Robert replies in natural language. Bates parses the reply against the four prefixes. For each `[doc]` reply, Bates appends a `[pending]` entry to `extraction-queue.md` with the document path or downloads the attachment to `extraction-queue/inbox/` and references it. For each `[rule]` reply, Bates appends a `[PROPOSED]` rule directly to `observations/rules.md` (skipping the extraction step). For each `[pattern]` reply, Bates appends a dated entry to `observations/patterns.md` under a new section called "manual-flags." If Robert replies `[skip]` or does not reply within 60 minutes, Bates records the skip in `evening-check-in.log` and exits.
+
+**Critical design constraint: this is not a conversation.** Bates posts the prompt, parses the reply against the prefixes, takes the actions, and exits. No follow-up questions. No clarification requests. No confirmation messages beyond a single line summary when `[done]` is received: "Logged: 2 docs to extraction queue, 1 rule proposed, 1 pattern flagged."
+
+**Status: needs to be built. This is the priority fix.**
+
+### Stage 5 — rules-digest (main, 07:00 daily)
+
+Morning summary delivered to Robert via Teams with five lines:
+
+```
+Bates rules digest, [date]
+- Documents extracted yesterday: N
+- Rules proposed yesterday: N  
+- Rules codified yesterday (Stage 3): 0 or 1
+- Total scripts in ~/.openclaw/scripts/: N
+- Total rules remaining as judgment calls in rules/: N
+```
+
+No additional formatting. No commentary. No suggestions. Just the five numbers.
+
+**Status: broken because upstream is empty. Will start working automatically once Stages 4a and 4 produce real activity. Do not rewrite Stage 5 first; it is downstream of the fix.**
+
+### Stage 6 — reliability-metric (main, weekly, Sunday 20:00)
+
+**This is the new measurement stage. It is what turns Bates into a publishable artifact.**
+
+For each script in `~/.openclaw/scripts/`, log every invocation with timestamp and exit code. The logging is passive: each script's first line is `echo "$(date -Iseconds) $0 $@" >> ~/.openclaw/scripts/.invocation.log`. Once a week, on Sunday at 20:00, a summary script computes:
+
+```
+Bates reliability metric, week of [date]
+- Total agent actions: N
+- Actions through codified scripts: N (X percent)
+- Actions through LLM direct: N (Y percent)
+- Script invocations by script: <top 10 list>
+- New scripts added this week: N
+- Reliability trend vs last week: +/-Z percent
+```
+
+The reliability metric is the percentage of agent actions that went through codified scripts versus through the LLM directly. This number is the equivalent of fDesk's 99.98 percent accuracy across 100,068 validations, but for a single agent. As the rules codifier runs and the scripts directory grows, this percentage should increase monotonically over months. That trend line is the proof that the architecture works.
+
+**Status: needs to be built. Ship after Stages 4a and 4 are working.**
+
+---
+
+## Data flow
+
+```
+Agent sessions
+    ↓
+findings.md (Stage 1: observe)
+    ↓
+patterns.md (Stage 2: promote)
+    ↓
+rules.md (PROPOSED rules)
+    ↑
+extraction-queue.md (Stage 4: extract from documents)
+    ↑
+evening check-in (Stage 4a: human-curated input)
+    ↓
+~/.openclaw/scripts/ (Stage 3: codify)
+    ↓
+.invocation.log (Stage 6: measure)
+    ↓
+rules-digest at 07:00 (Stage 5: report)
+    ↓
+weekly reliability metric Sunday 20:00 (Stage 6: report)
+    ↓
+Mission Control Rules tab
+```
+
+---
+
+## Implementation order
+
+1. Build Stage 4a (evening check-in) first. Without it, Stage 4 has no input and the whole pipeline starves.
+2. Verify Stage 3 (rules-codifier, just rewritten) runs cleanly for 7 consecutive days.
+3. Fix Stage 5 (rules-digest) to use the five-line format above.
+4. Build Stage 6 (reliability metric). Add the invocation logging line to every existing script in `~/.openclaw/scripts/`. Build the weekly summary script.
+5. Run for 30 days. Measure the reliability trend. If it is increasing, the architecture is working.
+
+---
+
+## Anti-requirements
+
+- **No automated email scanning.** Token cost exceeds value. Robert provides the documents through the evening check-in.
+- **No multi-candidate codification per run.** One candidate per run, every run. This is the architectural fix for the crash loop and is non-negotiable.
+- **No conversational evening check-in.** Bates asks once, parses against the four prefixes, takes the actions, exits. No back-and-forth.
+- **No proactive rule suggestions from Bates.** Bates does not propose rules unprompted. The pipeline is human-curated at the input and automatic at the processing.
+- **Reference from Soul.md or the existing OpenClaw configuration MDs.** Bates runs on OpenClaw and loads MD files from the OpenClaw convention (Soul.md and others), not CLAUDE.md. Add a single line to Soul.md that points at this spec: `See BATES_RULES_CODIFIER.md for the canonical six-stage rules pipeline specification. The anti-requirements section is binding.` This is one line added to an existing file, not a new file at the repo root.
+
+---
+
+## Success criteria after 30 days
+
+- Stage 4a runs every evening, Robert responds at least 20 of 30 days
+- Stage 4 produces at least 10 documents worth of extracted rules over the month
+- Stage 3 codifies between 20 and 30 rules into scripts (one per day, allowing for 0-2 misses per week)
+- Stage 5 digest is delivered every morning with non-zero numbers
+- Stage 6 weekly reliability metric shows an upward trend across all four weeks
+- Total scripts in `~/.openclaw/scripts/` grows by 20 to 30 over the month
+- Zero crash loops in Stage 3
+
+If all six conditions are met after 30 days, the architecture is working. If any one fails, fix that specific stage rather than redesigning the pipeline.