Skip to content

Plan: CreatorTrack as a fully operational, automated dev pipeline (the 5 features)

URL: https://mkdocs.justinsforge.com/memory/plans/creatortrack-automated-dev-pipeline-2026-07-11/

Date: 2026-07-11 Approved scope decisions: Automations engine = FULL builder UI (engine + create/edit rules pane + preloaded pipeline rules). GitHub/CI = BOTH directions (inbound events -> task, outbound task -> branch/PR/issue). North Star (unchanged): every primitive is generic, no "dev mode" / "software" label anywhere; the dev pipeline is just one configuration of universal automation/status/integration primitives that also serve a content creator.

Builds on (already deployed to prod 2026-07-11): task primitives (Type/Milestone/URL field/relations/Timeline), the dev-queue loop (forge_creatortrack_client.py + /dev-queue + chat.justin + Telegram), token scoping.

Verified integration points (CT repo)

  • Task mutation hook (automation trigger): lib/tasks.ts createTask (~1300), updateTask (~1425).
  • Webhooks: outbound app/api/settings/webhooks/route.ts; inbound app/api/hooks/[slug]/route.ts. SSRF guard lib/ssrf-guard.ts.
  • Activity (observability): lib/activity.ts logActivity, app/api/node/[id]/activity/route.ts.
  • External creds (GitHub token): lib/api-connections.ts, app/api/connections.
  • Prop/field seed: lib/system-apps.ts ensureTasksApp. Status options: PATCH /api/collection/prop/{id} or addProjectStatus.
  • Rules-pattern to model on: lib/calendar-sync-rules.ts.

PHASE 1, pipeline foundation (forge-side + light CT config; fast, low product risk)

Task 1.1: Pipeline statuses + Result field on the Tasks board (config)

  • Files: CT-side config only (no code): add task Status options via forge_creatortrack_client.py collection-prop PATCH on ws-90 Tasks Status prop (id 1930): add Ready to Merge, In Review, Blocked, Deployed (keep existing To do/Doing/Done/Send to Forge/In Development). Optionally seed a generic Result select (Passing/Failing/—) via ensureTasksApp-style default OR a client prop-add.
  • What: the pipeline needs terminal + intermediate states to move tasks through. Generic (a creator reads In Review as "needs approval", Deployed as "published").
  • Verification: forge_creatortrack_client.py can set_status <id> "In Review" and the task stays visible in the list.
  • Commit: n/a (prod config) OR a small seed script committed to forge.

Task 1.2: dev-queue writes structured feedback + auto-advances status (#1)

  • Files: /home/justinwieb/forge/scripts/forge_creatortrack_client.py (add set_field(task_id, field, value) and set_url(task_id, url) helpers), .claude/skills/dev-queue/SKILL.md (procedure: after building, write branch/commit/PR to the URL field, write a Result, then auto-advance status: built+passing -> "In Review", failing -> "Blocked"; still never auto-Done).
  • What: closes the loop so the board reflects real build state without reading notes.
  • Verification: run the dev-queue on a test task; confirm the URL field carries the PR/commit link, Result is set, and status advanced to In Review/Blocked (via queue/list).
  • Commit: feat(dev-queue): structured build feedback + auto-status

Task 1.3: dev-queue writes a structured run-log to task activity (#4, forge half)

  • Files: forge_creatortrack_client.py (an append_activity/structured note helper), .claude/skills/dev-queue/SKILL.md (after each run append: agent/model, fanout worker count, duration, result, Remote Control URL, /code-review summary).
  • What: every run leaves an auditable trail on the task (observability groundwork; CT-side surfacing is Task 2.5).
  • Verification: after a run the task notes/activity contain the structured run entry.
  • Commit: feat(dev-queue): structured run-log on each task

Task 1.4: queue guardrails, scheduling + WIP + priority + dependency order (#5)

  • Files: /home/justinwieb/forge/scripts/forge_creatortrack_devqueue_run.py (new orchestration entry the skill + a timer call), .claude/skills/dev-queue/SKILL.md (honor: WIP cap = max N In Development at once; pick Send-to-Forge in priority then due order; respect blockedBy so a task whose blocker isn't Done is skipped), optional systemd timer forge-creatortrack-devqueue.timer (nightly) written but OFF by default (Justin enables). NOTE: this reverses the handoff's earlier "no cron this round"; it is now in scope per Justin.
  • What: turns "I kick it" into "it runs itself, safely."
  • Verification: with 3 Send-to-Forge tasks and WIP=1, a run claims exactly 1; a task with an unmet blockedBy is skipped; priority order respected. Timer unit validates (systemd-analyze verify) but stays disabled.
  • Commit: feat(dev-queue): WIP/priority/dependency guardrails + optional scheduler

PHASE 2, CT product features (isolated worktree, background agents; large)

Built on a NEW branch feat/automations-github-pipeline off main via agent_bootstrap. Sequential within the worktree (shared index). Each task commits; verify each with tsc + a real :port browser/API check.

Task 2.1: Automations engine, schema + evaluation + action executors (#2)

  • Files: new migration (automations table: id, workspace_id, name, enabled, trigger jsonb {event, filters}, actions jsonb[]); lib/automations.ts (evaluate + execute); hook into lib/tasks.ts createTask/updateTask (fire matching rules after a change, guard against recursion/loops); action executors: internal (set field, move status, add subtask, assign, notify) + external (outbound webhook via the existing deliver path). Model triggers/conditions on lib/calendar-sync-rules.ts.
  • Verification: create a rule "status -> In Review => set field Result=pending"; move a task, confirm the action fires; loop-guard holds (no infinite cascade).
  • Commit: feat(automations): rule engine (trigger/condition/action) on record changes

Task 2.2: Automations builder UI (#2)

  • Files: app/api/automations/route.ts (+ [id]) CRUD; an "Automations" pane in workspace settings (extend components/profile/SettingsModal.tsx or a new workspace-settings surface); a rule editor (trigger picker, condition rows, action rows) rendered from a catalog of triggers/actions. Preload the pipeline rules as starter automations.
  • Verification: create/edit/delete a rule in the UI; it persists and fires; tsc + real browser check.
  • Commit: feat(automations): builder UI + preloaded pipeline rules

Task 2.3: GitHub inbound, events -> task (#3)

  • Files: app/api/hooks/github/route.ts (or reuse [slug]) verifying the GitHub webhook signature; map PR opened/merged, check_run/status pass/fail, push -> the linked task (matched via the URL field or a stored PR link) -> update Status + Result + log activity. Store the GitHub webhook secret + token via lib/api-connections.ts.
  • Verification: POST a sample GitHub PR/check payload; confirm the linked task's status/result/activity update; signature rejection on a bad payload.
  • Commit: feat(github): inbound events update linked tasks

Task 2.4: GitHub outbound, task -> branch/PR/issue (#3)

  • Files: lib/github.ts (GitHub REST client using the connection token); an automation action + a task action "Open branch/PR/issue"; wire as an available automation action (so "status -> Ready to Merge => open PR").
  • Verification: trigger the action on a test task against a test repo; confirm the branch/PR/issue is created and its URL lands on the task's URL field.
  • Commit: feat(github): outbound task-to-branch/PR/issue

Task 2.5: Observability surfacing on the task (#4, CT half)

  • Files: extend app/api/node/[id]/activity + the task peek/activity UI to render the structured dev-queue runs (Task 1.3), automation runs (2.1), and GitHub events (2.3) as a unified activity feed with links (Remote Control session, PR, code-review).
  • Verification: a task that went through a build + an automation + a GitHub event shows all three in its activity feed with working links.
  • Commit: feat(tasks): unified automation/build/github activity feed

Task 2.6: Register + document

  • Files: memory/general/reference_creatortrack_automations.md, memory/general/reference_creatortrack_github_integration.md, MEMORY.md index lines, update reference_creatortrack_client.md with the new client helpers.
  • Commit: docs(memory): CT automations + github pipeline

Sequencing + execution

  1. Phase 1 first (forge-side, I build directly, fast). Ships the pipeline behavior on the existing loop.
  2. Phase 2 in an isolated CT worktree via background agents, sequential (2.1 -> 2.2 -> 2.3 -> 2.4 -> 2.5 -> 2.6), each committed + verified. I review each before it merges.
  3. Deploy Phase 2 (plain code merge + migration for the automations table + restart) on Justin's go, same careful path as today's A/B deploy.

Out of scope

  • Per-branch preview deploys, throughput/cycle-time dashboards, AI spec->subtasks (the honorable mentions), unless promoted later.
  • Auto-merge to main / auto-deploy without a human gate (a rule can OPEN a PR and mark Ready, but a human merges).

Open risk to flag

  • Automations + GitHub two-way can create loops (a rule updates a task -> fires a rule -> calls GitHub -> webhook updates the task ...). The engine MUST have loop/recursion guards and an execution depth cap (built into Task 2.1).