בס״ד

Start Here — Phase 2 Plan (always-on Claude)

docs/PHASE2_PLAN.md · last changed (pre-VM history) · rendered from GitHub master

Start Here — Phase 2 Plan (always-on Claude)

Status: scaffolded today (2026-05-21), dormant until Sam adds ANTHROPIC_API_KEY to Script Properties.
Target build date: Sunday 2026-05-24 (post-Shavuos)
Owner: Sam (configuration) + Claude Code (build/test)

What it is

The architectural endpoint of the Hook Street execution spine: a Telegram bot you can have a free-form conversation with, computer off, that knows your workspace context, classifies your captures, and answers questions with real reasoning — not just command verbs against a queue.

The architecture

Sam texts bot (anywhere, computer off)
  ↓
Cloudflare Worker proxy (telegram-webhook.workers.dev)
  ↓
Apps Script doPost (always-on, no terminal)
  ↓
Is it a known command (QUEUE / DONE / DEFER / etc.)?
  ├─ YES → engine handles → reply via sendMessage
  └─ NO  → callClaude_() with workspace context:
            • Top 20 open cards (buildClaudeContext_)
            • Recent .remember/now.md summary
            • CLAUDE.md operating principles
            • Sam's actual question
          → Claude API (Sonnet 4.6 default, Haiku for classification)
          → response → sendMessage reply to Sam

What's already built (today, 2026-05-21)

Function Where Status
callClaude_(userMessage, contextHint, opts) start-here.gs ✅ scaffolded, dormant until API key
buildClaudeContext_() start-here.gs ✅ — reads top 20 open cards into a context blob
classifyWithAI_(actionId) start-here.gs ✅ — fires after createAction_ when lane=GENERAL, asks Haiku to pick lane + priority
inferPriority_(text) start-here.gs ✅ — rule-based first pass (URGENT/FORECLOS=P0, TOMORROW/THIS WEEK=P1, etc.)
Expanded inferLane_ start-here.gs ✅ — now recognizes EDEN, CLIENT, HOUSEHOLD, FAMILY, PHONE lanes plus better keyword coverage
Multi-item GROCERY parser start-here.gs ✅ — comma/newline-separated items each become a row

What Sam needs to do (Sunday, ~5 min)

  1. Get an Anthropic API key. Visit console.anthropic.com → API keys → Create key → copy. (If you don't have a billing setup, that's a 2-min add — credit card + $5 minimum top-up gives you ~500 conversations on Sonnet, ~5000 on Haiku.)
  2. Paste into Script Properties. Apps Script editor → Project Settings → Script Properties → add: ANTHROPIC_API_KEY = the key.
  3. Test from Telegram. Text the bot something free-form: "what's the most urgent open card right now?" — bot calls Claude API, replies with reasoning.
  4. (Optional) Tune the model. Default is Sonnet 4.6 for most queries, Haiku 4.5 for classifications. Sam can change via opts.model if needed.

What Claude Code will build (Sunday, ~90 min once key is set)

  1. Route free-form questions through Claude — currently unknown commands get captured to INBOX as NOTE. Sunday change: if input doesn't match a known verb AND Sam is the sender, route through callClaude_() with workspace context → reply via Telegram.
  2. /ask command as an explicit Claude entry point — /ask what should I do today? always hits the API regardless of pattern.
  3. Memory-aware replies — context loader extended to include recent .remember/now.md entries + relevant memory files matched to Sam's question topic.
  4. Cost telemetry — log every Claude API call to a CLAUDE_USAGE tab so Sam sees daily/monthly spend.
  5. Daily summarizer cron — 7 AM Apps Script trigger calls Claude with yesterday's events → generates a 5-line summary → posts to Telegram + writes to .remember/today-YYYY-MM-DD.md.
  6. Auto-classify retries — currently classifyWithAI_ only fires on new cards. Add a one-shot batch that re-classifies the existing GENERAL backlog.

Cost model

Activity Frequency Per call Per month
Free-form questions (Sonnet 4.6) 5-20/day ~$0.025 $4-15
Card classifications (Haiku 4.5) every new card ~$0.001 <$1
Daily 7 AM summarizer (Sonnet) 30/month ~$0.05 $1.50
Weekly digest (Sonnet) 4/month ~$0.15 $0.60
Realistic total $7-18/month

Action_ID format — Sam's request

Sam 2026-05-21: "the action number maybe should be worked not so much by the date and the number of the action... I actually need the action number itself, and then I can have the date after that connected to it."

Current: A-20260521-001 (date prefix + daily-resetting sequence)
Proposed: A-001 (monotonic across all time) with date stamp in Created_At column (where it already lives)

Decision parked for Sunday — schema change requires:
- Migration plan for existing ~30 cards (rename Action_IDs)
- All references in code (getAction_ suffix-matching, PWA renderQueueLines parser) need to handle both formats during transition
- Calendar event titles use Action_ID slice — need to verify rename doesn't break

Risk: medium. Doable but should not happen while Sam is out of cycle. Recommendation: do this Sunday in a focused 30-min block with full test coverage.

Multi-bot architecture (Sam's "several bots" question)

Sam asked: "if I need more of those or several of those and create different bots and telegrams something else has different sheets and talking, maybe they can communicate with each other."

The shape if Sam pursues:
- Each bot = a separate domain (e.g., @HSMomBot for Mom's Wholesale OS, @HSEdenBot for Eden Gardens client work, @HSMISBot for trading)
- Each has its own Telegram token + its own Apps Script project + its own Sheet
- Bots communicate via a central "hub" Apps Script that they all POST to
- Hub maintains shared context (relevant cards visible to all bots), routes messages between them, prevents duplicate captures

Realistic scope: 2-day build for the hub + 1 hr per additional bot. Not Sunday. Probably mid-June, AFTER:
- Phase 2 Claude API works end-to-end
- Sam has used the single-bot setup for 1-2 weeks and identified what actually needs splitting
- Mildred is fully on the schedule + Eden is closed / progressed

Strong recommendation: don't multi-bot yet. Single bot with multi-lane classification is 90% of the value at 10% of the complexity. Multi-bot becomes useful when bot CONVERSATIONS become long enough that mixing domains hurts comprehension. We're not there yet.

Self-improving system — "day 30 / day 100 easier than day 1"

Sam's vision: more memory + more accumulated context = LESS friction over time, not more.

Already in place:
- .claude/memory/ files build session over session
- .remember/ checkpoints accumulate
- feedback_*.md patterns codify past frictions so we don't repeat them
- docs/CLAUDE_TOOLS_AVAILABLE.md so I don't re-discover tools each session

Phase 2 additions for compounding:
- Auto-extract repeated frictions into skill files (currently I do this manually)
- Auto-summarize each session into .remember/today-YYYY-MM-DD.md so Sunday I know exactly what Tuesday looked like without re-reading transcripts
- Weekly "what changed" digest = compounding view of where the system grew, deprecated, regressed

The acceptance test: at day 100, Sam asks "what was that thing we decided about Mildred's hours in May?" and the bot answers in 2 seconds, without Sam having to remember which document held it. That's the win condition.

Hermes vs OpenClaude vs custom — final recommendation

After today's research + comparing to your actual stack:

Recommendation: stay custom. You've effectively built Hermes-Lite on infrastructure you already own. Switching to Hermes means:
- Migrating off Sheets to Hermes' SQLite (loses your canonical data architecture)
- Running a VPS (you've explicitly avoided this)
- Learning a Python framework (your stack is Apps Script + JS)
- ~40 hour migration tax with no functional gain over Phase 2 here

What you'd ACTUALLY borrow from Hermes (already incorporated today or planned for Sunday):
- ✅ Persistent bidirectional channel — done today
- ✅ Tool inventory — done today
- ✅ .remember/ integration — done today
- 🟡 Auto-skill extraction — Sunday
- 🟡 FTS5 search over conversation — Phase 3 (June)
- 🟡 Subagent autonomy — Phase 3 (June)

The honest version: Hermes is a reference implementation of where YOU are headed. You're 70% there already. Don't switch frameworks — fund the last 30% on your existing infra.

Source trail · docs/PHASE2_PLAN.md @ master · rendered 2026-07-02 7:23 PM EDT by scripts/build-docs.py · the .md in the repo is the truth; this page is the phone-readable view