Keysat
eb53afc186
Research confirms StartOS 0.4 supports per-package SMTP credentials fully independent of the server's system account: the "custom" branch of the manage-smtp action (gitea-startos and vaultwarden-startos both) never calls getSystemSmtp and works on a box with no system SMTP. Record this as the likely fit (a digest-only mailbox), built on sdk.inputSpecConstants.smtpInputSpec, plus the SDK version caveat (our ^0.4.0-beta.66 pin vs the references' 1.x).
113 lines
7.3 KiB
Markdown
113 lines
7.3 KiB
Markdown
# Venture CRM Roadmap (Airtable Replacement)
|
|
|
|
## Current status
|
|
- Premium Airtable-like frontend grid exists and is actively iterating.
|
|
- Backend now has production-grade APIs for:
|
|
- `GET /api/fundraising/state`
|
|
- `PUT /api/fundraising/state` (with optimistic version check)
|
|
- `GET /api/fundraising/export`
|
|
- `POST /api/fundraising/backup`
|
|
- `POST /api/fundraising/restore-preview`
|
|
- `POST /api/fundraising/restore`
|
|
- `GET /api/fundraising/backups`
|
|
- `GET/PATCH /api/fundraising/backup-policy`
|
|
- `GET /api/fundraising/relational-summary`
|
|
- `GET /api/feature-requests`
|
|
- `POST /api/feature-requests`
|
|
- `PATCH /api/feature-requests/:id`
|
|
- New DB tables:
|
|
- `fundraising_state`
|
|
- `fundraising_investors`
|
|
- `fundraising_contacts`
|
|
- `fundraising_funds`
|
|
- `fundraising_commitments`
|
|
- `fundraising_views`
|
|
- `feature_requests`
|
|
- `app_settings`
|
|
- Grid saves/restores now sync into relational fundraising tables automatically.
|
|
- Formula engine is now sandboxed (no `eval`/`new Function`) with expanded function support.
|
|
- Automation engine v1 added:
|
|
- Rule table + toggle API
|
|
- List memberships (`main`, `follow_up`, `graveyard`, `longshot`, `all`)
|
|
- Automation run log
|
|
- Collaboration/reliability additions:
|
|
- Unified activity feed API (`audit` + `automation` + `backup`)
|
|
- Backup integrity verification API
|
|
- Better version-conflict metadata (`updated_at`, `updated_by`)
|
|
- Security hardening additions:
|
|
- Basic IP rate limiting (login and write APIs)
|
|
- Configurable CORS origin (`CRM_CORS_ORIGIN`)
|
|
- Production secret enforcement (`CRM_ENV=production` requires `CRM_SECRET_KEY`)
|
|
- Security status API + go-live checklist (`SECURITY.md`)
|
|
|
|
## Phase 1 (Production foundation)
|
|
1. Persist grid + views on backend
|
|
- Wire frontend fundraising grid reads/writes to `/api/fundraising/state`.
|
|
- Keep localStorage only as emergency fallback.
|
|
- Add autosave debounce and conflict handling (`expected_version`).
|
|
|
|
2. Admin-invite auth model
|
|
- Disable self-register for non-admin users.
|
|
- Add admin-only invite/create-user endpoint.
|
|
- Keep role model: `admin`, `member`.
|
|
|
|
3. Deployment and remote access
|
|
- Add `docker-compose` for one-command launch.
|
|
- Reverse proxy + TLS option (Caddy/Traefik) for non-Tailscale deployments.
|
|
- Recommended for your use case: Tailscale private access to laptop host.
|
|
|
|
4. Data safety and operations
|
|
- Automated nightly SQLite backups and restore test script.
|
|
- Add `/api/fundraising/export` for JSON snapshot export.
|
|
- Add health/readiness checks.
|
|
|
|
## Phase 2 (Airtable parity)
|
|
1. Advanced views
|
|
- Multi-condition filter groups (AND/OR groups)
|
|
- Multi-column sorting
|
|
- Pinned/frozen columns
|
|
- Personal vs shared views
|
|
|
|
2. Formula engine v2
|
|
- Add functions: `SUM`, `MIN`, `MAX`, `ROUND`, `ABS`, `CONCAT` (done)
|
|
- Type-aware formulas and better errors
|
|
- Dependency graph and recalculation rules
|
|
|
|
3. Activity + audit
|
|
- Record-level change history in UI
|
|
- Last modified by / at fields
|
|
- Restore archived rows
|
|
|
|
## Phase 3 (Team workflow and automation)
|
|
1. Tasks/reminders tied to investors/contacts
|
|
2. Automation rules (graveyard/follow-up triggers)
|
|
3. Email/communication integrations (optional)
|
|
4. Granular permissions (if team grows)
|
|
|
|
## Backlog (post-Phase-1 agentic)
|
|
|
|
### Daily activity digest (email to the team)
|
|
*Requested 2026-06-15. Not yet built.*
|
|
|
|
Have the CRM send a **daily digest email** summarizing each registered user's activity — primarily **who emailed which investors and the substance of those emails** — to the fund principal (and eventually other admins). Scales with the synced-user count: 2 users synced today, ~5 eventually.
|
|
|
|
- **Source data:** the captured email-activity already flowing through the Gmail DWD propose→approve pipeline (`backend/email_integration/`), keyed per registered user → per investor/contact. Optionally fold in other CRM activity (audit feed, automation runs, new opportunities) later.
|
|
- **Send path is NEW capability.** Today nothing leaves the box — the system only *captures* Gmail and *creates drafts*. This needs outbound SMTP. StartOS 0.4 has a system-wide SMTP account (since v0.4.0-beta.9): the user configures it once for the whole server and services read it via `sdk.getSystemSmtp(effects).const()`, which returns a `T.SmtpValue` (`host`, `port`, `from`, `username`, `password`, `security`). Wire the digest sender to that rather than hardcoding any account. *Implementation path (researched 2026-06-15, our SDK pin `^0.4.0-beta.66`):* model a `manageSMTP` action on [gitea-startos](https://github.com/Start9Labs/gitea-startos) / [vaultwarden-startos](https://github.com/Start9Labs/vaultwarden-startos) — a three-way `selection` (system / custom / disabled) built on `sdk.inputSpecConstants.smtpInputSpec`, persisted to `storeJson`, with `main.ts` injecting `SMTP_HOST/PORT/USER/PASS/FROM/SECURITY` env vars into the daemon `exec` block (same shape as the existing `setAnthropicApiKey.ts` action). The Python sender reads them via `os.environ` and opens `smtplib.SMTP`/`SMTP_SSL`. **"Custom SMTP" is a dedicated per-package account, fully independent of the server's system SMTP** — the custom branch never calls `getSystemSmtp`, so the digest can send through its own provider even on a box with no system account configured (confirmed in both reference packages). This is the likely fit here: a digest-only mailbox separate from anyone's Gmail. Note StartOS 0.4 dropped the old `Config`/`Properties` manifest spec — SMTP config is an **action + storeJson**, not a manifest config field. **SDK caveat:** both reference packages use start-sdk 1.x (1.5.3); we pin `^0.4.0-beta.66`, so verify that the beta track exports `smtpInputSpec`/`smtpPrefill`/`getSystemSmtp` with the same shape (grep the installed `.d.ts`) — or bump the SDK — before building.
|
|
- **Analysis runs on Spark, never Claude.** The digest is deliberately **un-anonymized** (real LP names + email substance), so any summarization/analysis must go through **Spark Control to local models** — this is the one path that intentionally bypasses the scrub→Claude→re-hydrate boundary, because keeping the substance local is the whole point. Never route digest content to Claude.
|
|
- **Exempt from "agents draft, humans send."** That rule governs outward LP/prospect contact. This is an internal ops digest to the team's own inboxes — a different category — so an automated daily send here does not violate the draft-only guardrail. State this explicitly at build time.
|
|
- **Scheduling:** a daily cron, naturally co-located with the existing `backend/email_integration/scheduler.py` sync cadence.
|
|
- **Soft-delete:** every aggregate/read in the digest must filter `deleted_at IS NULL` (see the standing soft-delete rule).
|
|
|
|
Open design questions to resolve before building:
|
|
1. Recipients — just the principal, or all admins / each user gets their own?
|
|
2. Summarization — rule-based rollup vs. Spark-LLM narrative summary of email substance?
|
|
3. Digest granularity — per-user → per-investor threads, or a fund-wide activity roll-up?
|
|
4. Cadence/controls — fixed daily time, opt-out, "nothing happened today" suppression.
|
|
|
|
## Definition of done for "Airtable substitute" v1
|
|
- Team can manage all investors in one master table
|
|
- Saved views replicate current Airtable workflows
|
|
- CSV import from Airtable is reliable and repeatable
|
|
- Data persists safely and supports multi-user access
|
|
- Auth is invite-only and backups are automated
|