Skip to content

Forge <-> CreatorTrack dev-workflow loop (client + dev-queue skill + chat.justin toggle)

URL: https://mkdocs.justinsforge.com/memory/general/reference_creatortrack_client/

Built 2026-07-11 (Workstreams C+D+E of the dev-tool-primitives handoff). LIVE and verified end-to-end against prod ws 90. Lets Justin flag a task in CreatorTrack and have a chat.justin agent build it.

The loop

  1. Justin adds a task in the Forge / Creator Track workspace (id 90), sets status "Send to Forge".
  2. In a chat.justinsforge session (project = creatortrack or forge) he ticks the "Dev queue (Send to Forge)" modifier (or says "work the dev queue").
  3. The agent runs the dev-queue skill: pulls Send-to-Forge tasks, flips each to "In Development" (idempotency guard), builds in the selected repo, appends what it did to each task's notes, leaves status at In Development. Never marks Done (Justin does that).

C: scripts/forge_creatortrack_client.py

Token-frugal, ws-90-scoped client. Reuses forge_workspace_capture.api_call for the ctk_ Bearer auth (no new secret, no hand-rolled HTTP). Talks to CREATORTRACK_BASE_URL (default http://localhost:3070, the local prod instance on Console, so it hits real prod and bypasses Cloudflare). Fails loud (raises CreatorTrackError on non-2xx/bad token). - Verbs: list_dev_tasks(status=None, include_completed=False, workspace_id=90) -> minimal {id,title,status,project,due}; get_task, get_task_notes, append_note(id,text), set_status(id,status), set_title(id,title), create_task, delete_task, list_workspaces. - Also queue_status(workspace_id=90) -> {status: count} board glance. - CLI: python3 scripts/forge_creatortrack_client.py <list|notes|append|status|title|create|delete|workspaces|queue> .... title <task_id> "<new title>" (added 2026-07-12) renames a task via the same PATCH /api/tasks/{id} endpoint as status, just a {"title": ...} body; smoke-tested end-to-end against prod ws 90. - Smoke test: python3 scripts/forge_creatortrack_client_smoke.py (self-cleaning throwaway task in ws 90; ALL PASS on the full loop). - Gotchas learned building it: POST /api/tasks ignores a status in the body on create (always seeds "To do", system-apps.ts:1054); create_task handles this by create-then-PATCH so a requested status actually applies. id comes back as a STRING from create but int from list; the client normalizes list ids to int. Delete is a soft-delete/archive.

D: .claude/skills/dev-queue/SKILL.md

Orchestrator skill, triggers "dev queue" / "send to forge". Chains the client + the repo build (+ /fanout for a batch). On-demand only, no cron. Terminal state is "In Development", never Done. Fails loud (append the failure to a task's notes, leave it In Development, never silently drop).

E: chat.justinsforge toggle

  • scripts/forge_session_launcher_api.py: dev_queue entry in PROMPT_BLOCKS["modifiers"] (composes with the project pick). Requires systemctl --user restart forge-session-launcher to take effect (done 2026-07-11).
  • sites/justinsforge.com/chat/launcher.js (~line 627): ['dev_queue','Dev queue (Send to Forge)'] first in the modifiers list. Served statically at /ui/.

ws-90 status setup (one-time, DONE)

The dev-queue needs "Send to Forge" and "In Development" as task statuses. Task statuses are separate from PROJECT statuses. They live on the Tasks collection (ws-90 id 6403) Status prop (id 1930, type status), NOT the Projects Status prop (1928). Options now: ['To do','Doing','Done','Send to Forge','In Development']. Set via PATCH /api/collection/prop/1930 {config:{options:[...]}} (preserve existing). A task with an UNregistered status vanishes from GET /api/tasks, so always register before using. (Discover a workspace's collections + prop ids via GET /api/collection/databases then GET /api/collection/{id}/props.)

Token

Uses the existing legacy full-access CREATORTRACK_API_TOKEN in ~/.forge-secrets/creatortrack-bot.env. After token scoping (Workstream B) deploys, re-mint scoped to tasks:read tasks:write notes:write bound to ws 90; the client is unaffected (just swap the token value).

Pipeline (automated-dev-pipeline Phase 1, 2026-07-11)

  • ws-90 Tasks Status now carries the full pipeline: To do -> Send to Forge -> In Development -> In Review -> Ready to Merge -> Deployed -> Done (+ Blocked). Plus custom fields Result (Passing/Failing/Pending, prop 2014) and Link (url, prop 2015) on the Tasks collection (6403).
  • Client helpers: set_field(task_id, name, value), report_build(task_id, result, branch, commit, pr_url, summary) (sets Result + Link + structured note + auto-advances status: Passing->In Review, Failing->Blocked, never Done), log_run(...) (structured run entry for the CT activity feed). CLI: field, report.
  • Guardrails: scripts/forge_creatortrack_devqueue_run.py [--wip N] returns claim_now (build these) / ready_waiting (over WIP cap) / blocked (unfinished blockedBy). The /dev-queue skill consults it instead of grabbing the whole queue.
  • Optional scheduler (SHIPS DISABLED): scripts/forge_creatortrack_devqueue_scheduled.sh + infra/systemd/forge-creatortrack-devqueue.{service,timer}. Enable only to opt into autonomous nightly runs.
  • Phase 2 (Automations engine + full builder UI, two-way GitHub, activity feed) is a separate CT-side build: plan creatortrack-automated-dev-pipeline-2026-07-11.

Surfaces (how Justin reaches the loop)

  • chat.justinsforge: the dev_queue launcher modifier (E), or the /dev-queue skill (build) / /dev-queue-status skill (glance).
  • CLI / any session: forge_creatortrack_client.py verbs + the /dev-queue and /dev-queue-status skills.
  • Telegram (@Forge_General_Purpose_Bot, added 2026-07-11 in forge_general_purpose_tools.py): dev_queue_status (glance), dev_queue_add (capture a task into Send to Forge from the phone), dev_queue_run (kick a build, spawns a session via forge_spawn_session.sh, returns the RC URL). Needs a forge-general-purpose.service restart after edits.
  • [[reference_creatortrack_api_token_scopes]] (least-privilege token for this client)
  • [[reference_creatortrack_bot_api]] (the underlying capture client this reuses)
  • [[reference_general_purpose_bot]] (the Telegram bot the dev-queue tools live in)
  • [[reference_fanout_orchestrator]] (batch build mechanism)
  • [[reference_creatortrack_automations]] (Phase 2 CT-side automation engine that reacts to task changes; the dev-pipeline rules are preloaded examples, DEPLOYED prod 2026-07-12)
  • [[reference_creatortrack_github_integration]] (Phase 2 CT-side GitHub both-directions; inbound events update the linked task, outbound task actions open a branch/PR/issue, DEPLOYED prod 2026-07-12)