Business Info Funnel to Slack

Goal: every active venture funnels its live signals into Slack and to Claude on a schedule, so Nabil runs all businesses from one interface with approval-gated actions — for tighter ops and better bottom lines.

Definition of done: each active business has (1) a data funnel, (2) a scheduled Claude routine posting a structured weekly report to its channel, (3) an approval-gated action loop. Dead scaffolding removed.

Evidence — current Slack state (read 2026-07-06)

• Works: #lot-logistics receives a weekly Claude cloud "self-improvement pass" (prod health, CI, draft PRs, security, competitive intel, learnings). This is the template.
• Dead scaffolding: all ops-*, tech-*, fin-*, legal-*, partners-*, #digest, #approvals, #announcements — setup + joins only, zero traffic since 2026-05-03.
• Two agents: Claude app (U0B24DT3GFM — reliable, posts reports + canvases) and "Nas"/OpenClaw (U0B20BNQWQL — stalled on email polling + rate limits, quiet since June).
• Abandoned: n8n SMBC (removed from #sales), PostHog app (in #roadside-ops, never posted).

Architecture — the funnel

Data sources → Claude cloud routine (scheduled) → Slack business channel → Nabil approves/acts → Obsidian (record) → graphify (cross-business queries)

Claude is the funnel processor: routines run Claude against the sources and post to Slack. Obsidian stays the source of truth; Slack is the interface; graphify answers "how does it all connect."

Decision: standardize on the Claude app + cloud routines. Retire Nas/OpenClaw — the proven path already runs on Claude routines; maintaining a second stalled agent is pure overhead.

Per-business funnel map

Business	Data sources (funnels)	Routine → channel	Cadence	Status
LotLogistics	GitHub repo, PostHog 483628, Stripe, Hasura fleet, Coolify	self-improvement pass → #lot-logistics	weekly	✅ live
Fleet P&L	Stripe + Uber/Lyft exports + costs (fleet-pnl skill)	weekly P&L → #fin-reporting	weekly	⬜ funnel the skill output to Slack
Roadside GA	GitHub, PostHog 483582 (app already in channel), prod	health + funnel metrics → #roadside-ops	weekly	⬜ wire PostHog alerts + routine
Tripsynk	GitHub, EAS builds	dev/release digest → #tech-tripsync	weekly	⬜
SwiftRide	Hasura fleet DB, App Store	co-owner monthly statement → #partners-swiftride	monthly	⬜
Dealer Connect	GitHub	build digest → #dealer-connect (create)	weekly	⬜ needs channel
Infra/Coolify	Coolify, Hostinger VPS	downtime + deploy alerts → #tech-alerts	event-driven	⬜
Stitch & Wear, BillBash	—	—	—	hold until status confirmed

The three action loops

1. Report loop (pull): scheduled routine reads sources → posts structured report to the business channel. Proven in #lot-logistics. Replicate.
2. Alert loop (push): PostHog/Coolify/CI fire events → #tech-alerts / channel. High-signal, low-noise.
3. Approve-to-act loop (bidirectional): Nabil asks in Slack → Claude drafts (email, PR merge, contract) → posts to #approvals thread → Nabil approves → Claude executes → confirms + records to Obsidian. First instance: the outbound-email loop (see Slack Obsidian Graphify Strategy).

Build order

1. Funnel the fleet P&L to #fin-reporting — the fleet-pnl skill already produces it; this is the fastest "better bottom line" win. Weekly routine.
2. Wire the approve-to-act email loop once Gmail MCP is connected (/mcp).
3. Replicate the report routine for Roadside GA (PostHog app is already in-channel) and Dealer Connect (after #dealer-connect is created).
4. Cleanup: archive dead channels (keep the active + report-target set), retire Nas/OpenClaw.
5. graphify layer: index the vault so Slack questions like "total Coolify exposure?" / "which ventures share the Stripe account?" get answered from the graph.

Fleet P&L funnel — implementation status (2026-07-06)

A (done): cloud routine Weekly Fleet P&L (revenue snapshot) (trig_019nh8sZFUx9kjqvxEdUtamA), Mon 07:00 UTC → posts Stripe revenue + balance to #fin-reporting, nudges to run the full local P&L. Uses Stripe + Slack cloud connectors (proven pattern — the Morning Briefing already pulls Stripe in cloud, correcting the earlier "Stripe isn't a cloud connector" note).

B (de-risked, one gate left): make the full per-vehicle P&L run in the cloud.

• ✅ Hasura endpoint https://hasura.swiftride.io/v1/graphql is publicly reachable; base vehicles/maintenance/insurance/stripe_data_* tables all present. Stripe is even mirrored into Hasura — a single authenticated endpoint can serve both revenue and fleet data.
• ✅ Purpose-built financial primitives exist: get_fleet_financial_summary, calculate_vehicle_profitability, get_vehicle_revenue, vehicle_kpi_dashboard (fields: revenue_per_week, gross_margin_per_week, subscription_occupancy, replacement flags).
• ⚠️ Caveat: the pre-aggregated vehicle_kpi_dashboard view is currently empty (populate job not running), and the get_fleet_financial_summary function requires non-default args (org_id/date — needs introspection). So B either (a) fixes/loads the KPI view, or (b) replicates the local skill's base-table computation via GraphQL.
• 🔑 The one blocker — auth. The cloud routine must authenticate to Hasura. Never embed the admin secret in a routine (it grants full write). Needed from Nabil: a read-only Hasura role + token scoped to fleet/financial tables, which the routine sends as a header. That single token unblocks the full cloud P&L.

B next steps: (1) Nabil provisions the read-only token; (2) introspect get_fleet_financial_summary args or fix the KPI populate job; (3) author the full-P&L cloud routine (disabled → enable after a verified test run); (4) retire routine A's "snapshot only" caveat.

C — local backup (scaffolded 2026-07-06)

A launchd job that runs the full per-vehicle P&L locally, as backup to A (cloud snapshot) and B (full cloud). Independent of B's Hasura token and the empty KPI view — it uses the local stdio MCPs that already work.

• Why it's a good backup: local stripe-sabronmbc + hasura-prod are stdio MCPs → they load headlessly, so the full P&L is generatable offline-of-cloud. StartCalendarInterval reruns a missed job on next wake, softening "Mac must be on."
• Key design decision: the Slack we post through is the claude.ai connector, which is NOT in the local MCP config and won't reliably auth headless. So C decouples: headless claude -p generates the report → curl posts it to a Slack incoming webhook.
• Artifacts (ready, inert until loaded): System/automation/fleet-pnl-weekly.sh (runner) + System/automation/com.sabronmbc.fleet-pnl.plist (launchd, Mon 08:00 Mac-local). Webhook secret path System/.slack-fin-webhook is gitignored.
• Two setup steps before it's live: (1) create a Slack incoming webhook for #fin-reporting and save it to System/.slack-fin-webhook; (2) validate one manual run (bash System/automation/fleet-pnl-weekly.sh) to confirm headless claude -p flags + MCP loading, then launchctl load the plist.
• ✅ Validated 2026-07-06: ran the runner end-to-end. Headless claude -p loaded the local Stripe + Hasura MCPs (no permission hang, ~5.5 min), generated a correct full W28 per-vehicle P&L (10 vehicles), wrote it to the vault, and correctly skipped the Slack post (no webhook) with a clean exit 0. The ONLY unproven link is the curl→webhook post itself — add the webhook to prove the last inch. Generation is proven.
• Bonus: the run surfaced that the fleet grew to 10 vehicles (new 2018 Kia Forte, in recon) — needs a vault note.

Cleanup candidates (channels to archive — zero traffic)

#new-channel, #social, #random, #digest, #digestsa, #claw-chat, #claw-logs, #claw-approvals (Nas retired), plus the unused ops-*/legal-* set — collapse to only channels that will actually receive a funnel. Confirm with Nabil before archiving.