Skip to content

Development Plan

SuperElectron edited this page Aug 21, 2026 · 8 revisions

Development Plan

Plan simple: build MVP first with keys we have. Add rest after v1.0.0.

Keys we have: Apollo, Tavily, local LLM, Mem0, Postgres. Gmail need no vendor key — own Google account, OAuth. Keys we lack: HubSpot, SendGrid, HeyReach, Slack. Those wait. No key, no build.

MVP still full hunt loop: CSV contacts in → Apollo/Tavily enrich → research + signals → Mem0 remember → LLM write email → Gmail send → poll replies → classify → report. One channel (email), whole brain.

Full detail (per-commit breakdown, dependency matrix, traps): .cache/commit-plan.md (v6).

Process

  • Branches: mainstagingfeature/<group>. One PR per feature group into staging. Milestone PR staging → main, tagged.
  • Issues: one GitHub issue per feature group, project board https://github.com/users/SuperElectron/projects/4/views/1, tasklists checked before close.
  • Gate per PR: cargo fmt --check && cargo clippy --all-targets -- -D warnings && cargo test green.
  • Review: code-reviewer pass on every PR. Milestone review sweep of full diff before each staging → main.
  • Design rules: no code comments; files aim under 400 lines (~500 guideline, split when big); I/O behind traits; thiserror per module; conventional commits.
  • Never: direct commits to staging/main; red merges; group started before prerequisites merged.

Milestones (sprints)

Milestone Tag Feature groups Outcome
M1 Foundation v0.1.0 FG-01 bootstrap, FG-02 domain, FG-03 config, FG-04 db, FG-05 llm, FG-06 memory (+ seed data) binary boots, migrations run, LLM + Mem0 reachable — done, merging
M2 Clients + email v0.2.0 FG-07 api-clients (Apollo/Tavily), FG-08 connectors (trait, notifier, gmail, health/metrics) data clients + email channel tested
M3 Workflows v0.3.0 FG-10 sync (CSV), FG-11 discovery, FG-12 research, FG-13 accounts, FG-14 generation, FG-15 analysis full business logic, dry-run capable
M4 Runtime v0.4.0 FG-16 runtime-core, FG-17 jobs-sync, FG-18 jobs-outreach, FG-19 jobs-inbound, FG-20 reporting system runs itself locally
M5 Release v1.0.0 FG-21 integration-tests, FG-23 docs+assets+agent-skills, FG-24 release shippable MVP
M6 Integrations v1.1.0 FG-25 slack (notifier impl), FG-26 sendgrid, FG-27 hubspot (connector + CRM sync pull/push), FG-28 heyreach (LinkedIn: messages, events, webhook, multichannel job) deferred until keys arrive; traits in place, each plug in with no core rework
M7 Credential broker v1.2.0 jentic-one broker transport for connectors + OpenClaw pairing secrets brokered, harness-agnostic operation
M8 Memory upgrade v1.3.0 Mem0 on shared Postgres pgvector; local embedding model on DGX one datastore, fully local embeddings

Key ordering constraints (why groups can't shuffle)

  • health/metrics need gmail connector → live in FG-08 tail
  • job error-notify use Notifier trait, log impl in MVP → Slack drop-in later, no runtime change
  • webhook router ships FG-16 with handler registry; inbound handlers register FG-19
  • tasks::execute needs generation → FG-15 after FG-14
  • signal_detection has widest fan-out → last job commit
  • reply monitoring = Gmail API polling primitives land with gmail connector
  • connector + notifier traits stay channel-open — M6 channels return, no email-only assumptions

See Home, Architecture.

Clone this wiki locally