Automation Components

Purpose

Describe the reusable UI components that compose the automation dashboard: stage cards, current processing card, run history, activity log, and configuration modal. These components visualize pipeline state, history, and settings sourced from automation services.

Code Locations (exact paths)

Stage cards & layout: frontend/src/pages/Automation/AutomationPage.tsx (renders stage cards from STAGE_CONFIG)
Current run card: frontend/src/components/Automation/CurrentProcessingCard.tsx
Activity log: frontend/src/components/Automation/ActivityLog.tsx
Run history: frontend/src/components/Automation/RunHistory.tsx
Config modal: frontend/src/components/Automation/ConfigModal.tsx
Shared UI: frontend/src/components/common/{ComponentCard,PageMeta,DebugSiteSelector}, frontend/src/components/dashboard/EnhancedMetricCard

High-Level Responsibilities

Stage cards: show each of the 7 pipeline stages with icon/color/status derived from pipeline overview.
CurrentProcessingCard: surface active run details, stage name, status, percent, timestamps, and controls (Pause/Resume).
ActivityLog: list recent automation events (from run log feed).
RunHistory: show prior runs with status and timestamps.
ConfigModal: edit and persist automation configuration per site.

Detailed Behavior

Stage Cards:
- Built from STAGE_CONFIG array (keywords→clusters, clusters→ideas, ideas→tasks, tasks→content, content→image prompts, image prompts→images, manual review).
- Status/progress comes from pipelineOverview.stages provided by automationService.getPipelineOverview.
CurrentProcessingCard:
- Receives currentRun and shows status; displays pause/resume buttons wired to page handlers that call automationService.pause/resume.
- Hidden when no current run; toggled by showProcessingCard.
RunHistory:
- Takes run list (from automationService.getCurrentRun payload history) and renders chronological entries.
ActivityLog:
- Displays textual log entries for the active run; consumes run log data supplied by the page.
ConfigModal:
- Opens from page button; on save calls automationService.updateConfig(activeSite.id, newConfig); merges into local config and refreshes pipeline/metrics.

Data Structures / Models Involved (no code)

AutomationRun (id, status, stage, progress, started_at/ended_at).
PipelineStage array with stage identifiers, names, progress.
AutomationConfig fields shown in modal (intervals/gates/etc., defined server-side).

Execution Flow

Page loads run + pipeline → passes data into stage cards, processing card, history, activity log.
User opens ConfigModal → submit triggers updateConfig → page reloads pipeline/metrics/run to reflect new settings.
Pause/Resume buttons on CurrentProcessingCard call page handlers, which in turn call automationService.

Cross-Module Interactions

Components depend on site context from useSiteStore and data from automationService; no direct planner/writer calls (metrics happen in page).

State Transitions

Components are pure renderers; state (visibility, selected config) managed by AutomationPage.

Error Handling

Errors in save/pause/resume are surfaced by the page via toasts; components render based on provided props.

Tenancy Rules

All data passed in is already scoped to activeSite; components do not alter scoping.

Billing Rules (if applicable)

None inside components; Run Now credit gating handled at page level.

Background Tasks / Schedulers (if applicable)

None; updates driven by page polling interval.

Key Design Considerations

Separation of concerns: components stay presentational; network calls remain in page.
Stage cards use color/icon metadata for fast visual scanning of pipeline status.

How Developers Should Work With This Module

Add new stages by extending STAGE_CONFIG and ensuring pipeline overview includes the new stage id/status.
Extend ConfigModal fields in sync with backend AutomationConfig; persist via automationService.
Keep CurrentProcessingCard controls minimal; any new action should call automationService and refresh run/pipeline afterward.

4.2 KiB Raw Blame History