Skip to Content
Core LoopOverview

Core Loop

The v1 release is organized around one operating loop:

trends -> remix -> generate -> publish -> analytics -> repeat

The repo already contains the live server surfaces for this loop. This section makes the wiring explicit so the OSS v1 story is inspectable instead of implicit.

What This Section Covers

  • Step 1: Trend Ingestion: how trend signals enter the platform and end up in collections/trends
  • Prelaunch Corpus Health: launch-minimum targets, health metrics, and freshness expectations for the global trend/reference corpus
  • Prelaunch Corpus Backfill: the credential-free global seed path for launch cold-start coverage
  • Agent Orchestration: how the V1 agent runtime should own turn state while campaigns, skills, and content pipelines stay as adapters or deterministic execution layers
  • Step 3: Generation Service: how generation-facing modules route into provider-backed media and text paths
  • Step 5: Analytics Backbone: how analytics-facing services aggregate activity into dashboard-visible output

Why This Matters For V1

The v1 milestone is not blocked on inventing these systems from scratch. It is blocked on making the current surfaces:

  • visible in docs
  • easier to verify
  • easier to reason about as one release candidate

Core Module Spine

The main server app already wires the three v1 surfaces directly in apps/server/api/src/app.module.ts:

  • TrendsModule
  • BatchGenerationModule
  • BusinessAnalyticsModule
  • AnalyticsModule
  • TwitterPipelineModule

Loop Map

Representative Smoke Paths

Each v1 area now has one narrow verification path:

  • Trend ingestion: verify TrendsService falls through the cached path into the live-fetch path when cache is empty
  • Prelaunch corpus health: verify launch readiness against explicit platform, content-type, freshness, and prompt-ready metadata targets
  • Prelaunch corpus backfill: dry-run the global seed plan, then apply it with seed:prelaunch-corpus when launch data is needed
  • Agent orchestration: verify new agent-facing automation routes through one runtime boundary instead of adding another peer orchestrator
  • Generation service: verify dynamic provider-backed model discovery merges into the stable generation-facing model surface
  • Analytics backbone: verify provider metrics are stored in postAnalytics, visible in publication analytics, and included in content-performance summaries once the data is no longer current-day incomplete
  • #159 Trend Ingestion API
  • #160 Analytics Backbone
  • #161 Generation Service
  • #210 Prelaunch corpus launch targets and health metrics
  • #211 Prelaunch corpus backfill

Continue with the step-specific pages for the concrete module inventories and smoke-path details.