# Gardener v3 Specification

## What we've decided: The system's purpose

Produce informed, bespoke-feeling outreach content for cold and warm leads in CT. Zoho handles delivery and scheduling. The Python system is the content engine — it answers "what should we send to lead X right now" with a touch grounded in current knowledge of that lead.

## The architecture is Path 1: OpenClaw-as-primary-operator

The codebase is a callable API/library that OpenClaw uses. A CLI exists as a thin wrapper for human debugging and spot-checks but isn't the primary interface. Functions are first-class. Each capability is independently invocable. Errors are structured. State is queryable.

Zoho is the postal relay, system-driven mode. Your system decides when touches are due (based on touch history, time since last touch, and lead state). It pushes touches into Zoho when ready. Zoho delivers on its schedule and reports back what happened (replies, eventually clicks). The system reads those signals to decide what to do next.

Touches are sequenced, not one-shot. Each lead can receive multiple touches over time. The schema tracks touch history with timestamps, content, angle chosen, lead-snapshot-at-send, and engagement data. Each touch is generated freshly based on what's known at that moment.

Each touch is grounded by a per-lead research note. Before drafting, the system runs a focused LLM call that produces a structured understanding of the specific business — what they do, what workflow detail matters, what's notable about how they present themselves, any flags. The research note is stored on the lead. The drafter uses it as input. Subsequent touches can re-use or refresh it.

Research is bounded to observable evidence. The research note describes what's verifiable from Brave results, the lead's website, and the filing. Inference (about IT needs, budgets, decision-makers) is a separate clearly-labeled step done on top of observation, not mixed into it.

Enrichment is timestamped and refreshable. Pattern A baseline (re-run standard enrichment when stale), Pattern B deepening (read the website more thoroughly for high-value leads), Pattern C targeted (driven by what the next touch needs — eventual goal, not v1).

Prompts and research questions live in files, not code. Each prompt is in prompts/ (or equivalent). Iterating on a prompt means editing a file. The research-step prompt is the same — a file that can be edited without touching core code.

News signals and cross-lead reasoning are v2. The architecture stays open to them (signals are a generic concept with pluggable sources) but they're not built in v1.

The hat system, template drafter, and all vestigial paths are dropped in the rebuild. The new schema doesn't carry hat_assignment, template_route, or the other dead fields. The new code doesn't include haberdasher, seed-planter, or the dead functions in lifecycle/drafter.

Current system stays running in parallel. Rebuild lives in a separate directory. Both can read the same backlog (or the rebuild can read a transformed copy). Migration is gradual; rollback is a directory switch.

That's the spec, compressed.

---

## On what to send opencode

The revised prompt to opencode needs to do three things:

1. **Keep Parts 1 and 2 of the existing assessment.** That work is solid. No reason to redo it.

2. **Replace Part 3 entirely with one informed by the design decisions above.** The current Part 3 was designed for "cleanup rebuild." The new Part 3 needs to be designed for "agent-driven content engine with sequenced touches and research-grounded drafting."

3. **Be explicit that this is a different architecture than the current assessment proposes.** Opencode will want to reuse its prior work; the prompt needs to make clear that some of it doesn't fit anymore.