Dark Software Factory: How Groupon Runs a Lights-Out CMS on GitHub Issues and PRs

Here is how I learned that a dark factory is not a thought experiment. It is a weekend project that accidentally becomes production infrastructure.

Groupon had a careers site. It was the kind of site you have seen a thousand times: blue gradients, stock photos of people shaking hands, centered text saying We are passionate about excellence. It said nothing true. It attracted no one worth hiring. The old site lived at grouponcareers.com and it was embarrassing every time a candidate opened it.

I decided to fix it. Not in a quarter. Not with a roadmap. Over a single weekend. The goal was not to ship a perfect site. The goal was to ship a site that told the truth about working at Groupon during an AI transformation, and to build it using the same agentic patterns we were already preaching internally.

The preview lives at groupon-careers.vercel.app. Go look at it. The difference is not just visual. The old site was a declaration of conditions we wished were true. The new one is a declaration of conditions that actually exist: live marketplace pressure, legacy systems, AI workflows in production, real customer weight. It does not say join our journey. It says build while running.

The build process itself was the experiment. I did not write the content files by hand. I opened GitHub Issues. cms-spotlight-add for employee profiles. cms-insight for leadership articles. cms-location for office pages. The agent read each issue, loaded the correct skills from .claude/skills/, generated headshots via fal-ai/gpt-image-2, wrote the MDX, ran pnpm lint, and opened a PR. I typed /publish on the issue. The PR merged. Vercel deployed.

By Monday morning, the preview site had eight employee spotlights, three insight articles, five location pages, and a full FAQ. None of the content was written by a human sitting at a keyboard. All of it was reviewed by a human before merge. That is the distinction that matters: the factory does not replace judgment. It compresses execution.

What I learned over that weekend became the pipeline this article describes. The BOT_PAT trap, the WAITING/READY signal protocol, the branch detection bug, the recursive comment filter, the media generation fallback chain — every trap in this article was discovered in real time while building the careers preview. The factory taught itself by failing, and I watched the logs.

A dark software factory is a repository where the control plane is not a dashboard or a scheduler. It is the native GitHub surface: Issues for intake, Pull Requests for implementation, Comments for dialogue, and Labels for state machine transitions. AI agents run inside GitHub Actions, reading the same interfaces humans use, producing the same artifacts humans produce, and following the same quality gates humans follow.

The term comes from manufacturing: a dark factory runs without lights because there are no humans on the floor. In software, it means the repository keeps shipping while the team sleeps, attends meetings, or works on harder problems. The humans write specs and design harnesses; the agents write code, generate images, and manage state.

This article is a deep teardown of a production CMS pipeline at Groupon that processes content requests through GitHub Issues. It covers the exact workflow DAGs, the AI configuration surface, the media generation pipeline, the issue type taxonomy, and the specific traps that will break your factory in production. Everything here is drawn from running systems and committed code.

The factory's job queue is not a free-form inbox. It is a typed taxonomy of six issue labels, each with a strict schema, required fields, and a specific set of skills the agent must load before acting. The label is the routing key. The schema is the contract.

When an issue is opened with a cms-* label, the cms.yml workflow fires. The first thing the agent does is read AGENTS.md and load the skills mapped to that label. This is not optional configuration. It is a mandatory skill-loading protocol that determines whether the agent generates a headshot, expands an article draft, or edits a location page.

The taxonomy is rigid for a reason. The agent cannot invent a new issue template. It cannot generate a logo because cms-logo is not a label. It cannot write a component change without the frontend-design skill. The harness is the design: human-authored constraints that prevent the agent from wandering outside its lane.

For spotlights, the quote field has a specific quality gate: it must be specific enough to be false. A generic quote like I love working here fails the audit because it could apply to anyone. The agent must ask for a replacement via the clarification loop. For insights, the body must contain factual anchors — names, dates, tools, outcomes — or the cms-article-expand skill refuses to expand it.

A dark factory is not one massive workflow. It is 11 small workflows that compose into a closed loop. Each workflow owns one state transition, reads one event type, and writes one artifact type. This decomposition is what makes the system debuggable when an agent hallucinates a file path or a label filter misfires.

The 11 workflows are: cms.yml (Issue Intake), issue-clarify.yml (Clarification Loop), cms-ci-healer.yml (CI Auto-Healer), pr-code-review.yml (Code Review + Auto-Fix), cms-publish.yml (Publish/Merge), vercel-preview.yml (Preview Notifications), cms-spend-alert.yml (Cost Monitoring), cms-stale-prs.yml (Stale PR Cleanup), cms-canary.yml (Skill Loading Test), ci.yml (Quality Gates), pr-checks.yml (Coverage Gate), and the implicit build job that Vercel runs on every push.

cms.yml is the heart of the factory. It triggers on issues.opened and issues.reopened when the issue carries a cms-* label and does not carry cms-bot-waiting. The first gate is the kill switch: vars.CMS_BOT_ENABLED == 'true'. If the repository variable is anything other than 'true', the workflow exits immediately. This is how you halt the entire factory without touching code.

The workflow uses pnpm/action-setup@v4 with Node 20 caching, checks out the repo with fetch-depth: 0, installs the genmedia CLI for image generation, and and then invokes anthropics/claude-code-action@beta. The action is the agent container. Everything that follows depends on three configuration surfaces: model, allowed_tools, and direct_prompt.

The model field pins the agent to claude-sonnet-4-6. This is not the latest model. It is the calibrated model. The factory was tested against this specific version, and changing it without re-calibrating the allowed_tools patterns and prompt instructions risks breaking the agent's behavior.

The allowed_tools field is the security boundary. It uses a comma-separated list where each Bash command is prefixed with Bash(...) and supports wildcard arguments. Bash(git add:*) allows git add content/spotlights/jana-novotna.mdx but Bash(git add:*) does not allow git add . && rm -rf .git because the action treats the entire string as a single command and rejects &&. This is critical: the action's Bash tool does not support command chaining, pipes, or semicolons. Every Bash call must be a single executable with literal arguments.

The allowed_tools list includes Bash(pnpm exec tsx scripts/cms/*) for cap-checking (cap-check.ts) and image postprocessing (postprocess-image.ts), and Bash(genmedia run:*) for media generation via the genmedia CLI. The direct_prompt is the control surface. It is not a suggestion. It is a script that the agent executes line by line. The prompt ends with an explicit signal instruction: READY or WAITING on its own line. The workflow reads this signal from the action's output JSON file.

The clarification loop is where most dark factory implementations break. A user opens an issue, the agent asks for a photo, the user uploads one in a comment, and now a second workflow must re-run the agent with the accumulated context. The trigger is issue_comment.created, but the filter is the hardest part of the entire system. The pipeline now also filters on github.event.actor != 'github-actions[bot]' as a second guard against recursive triggering.

You must exclude: bot comments (to prevent recursive self-triggering), /publish commands (handled by cms-publish.yml), /cancel commands, comments on pull requests (not issues), and issues that do not have both cms-bot-waiting and a cms-* label. The Groupon pipeline uses a join-based prefix match for label filtering because GitHub Actions' contains() on arrays does exact matching only. contains(join(labels.*.name, ' '), 'cms-') checks whether any label starts with cms-, which is the correct behavior for a prefix-based taxonomy.

The clarification workflow has a pre-download step that runs before the agent. It extracts photo URLs from the comment thread using gh issue view --comments --json comments, downloads them with curl and GITHUB_TOKEN auth, and writes them to public/images/spotlight/{slug}.jpg. This solves two sandbox problems at once: the agent cannot access /tmp, and GitHub attachment URLs expire after a short time. By downloading images in a workflow step, the photos are available in the repo workspace when the agent starts.

A critical bug that appeared during calibration: removing the cms-bot-waiting label before PR creation. If the label is removed early and gh pr create fails, the issue no longer has the waiting label, so issue-clarify.yml will not re-trigger on the user's next reply. The issue is stranded. The fix is to remove the label only after successful PR creation, in the success path of the same step that creates the PR.

The CI Auto-Healer is the most recent addition to the factory. It triggers on workflow_run.completed when the conclusion is failure, watching CI and CMS — Process content request workflows. It downloads the run log archive via gh api repos/{repo}/actions/runs/{id}/logs, extracts the last 200 error lines, and invokes Claude Code on the exact failing SHA (not main).

The agent receives the error context and a diagnostic prompt. It creates a fix/ci-healer-{run_id}-{sha} branch, pushes it, applies the fix, and opens a PR. The pr-code-review.yml workflow explicitly skips fix/ci-healer-* branches to prevent the review loop from re-triggering on its own healing PRs.

The PR Code Review workflow runs on every pull request against main (opened, synchronize, reopened). It fetches the full diff with git diff base...head, pipes it to Claude Code for a structured code review, and then — if the review finds must_fix or should_fix issues — invokes a second pass to auto-fix them on the same branch.

The workflow has a critical guard: it skips branches starting with fix/ci-healer- or claude/. Without this, a bot-fix PR would trigger another review, which might trigger another fix, creating an infinite loop. The allowed_tools list is narrower than the CMS workflows: it excludes media generation and headshot scripts, focusing only on lint, typecheck, and test tools.

Here is the single most expensive trap in dark factory engineering. When a GitHub Actions workflow creates a PR using the default GITHUB_TOKEN, that PR does not fire pull_request events. This means your ci.yml, your pr-checks.yml, your required status checks, and your auto-merge rules will never trigger. The PR sits open, green in the sense that no checks failed, but unmergeable because no checks ran.

The fix is a Personal Access Token with repo scope, stored as BOT_PAT. PRs created with BOT_PAT fire events normally because GitHub treats them as user-created, not action-created. The tradeoff is that you must rotate this token and scope it to the minimum repositories.

In the Groupon pipeline, BOT_PAT is used only for gh pr create. All subsequent operations — labeling, commenting, merging — use GITHUB_TOKEN so the comments are attributed to github-actions[bot] and do not re-trigger issue workflows.

The PR creation step uses gh pr merge --squash --admin for same-day merges when the cms-approved label is applied. This bypasses the 24-hour branch protection delay for bot PRs that have passed all quality gates. The step also runs quality gates: pnpm lint and pnpm exec tsc --noEmit. These must run on the agent's branch, not on the workflow's checkout of main. A common latent bug is checking out main, then running lint against main while the agent's commits sit on an undetected branch. The fix is to git checkout the action branch after detecting it with git branch -r | grep origin/claude/issue-N-....

The PR body includes a cost report generated by scripts/cms/cost-report.ts. This script reads .cms-fal-log.json for fal.ai spend and estimates Anthropic cost from token counts or issue body length. Every automated PR carries its own price tag in the description.

The publish workflow has two jobs that communicate through labels, not through shared state or message queues. Job 1 listens for /publish comments on issues, finds the associated bot PR by searching for Closes #N in PR bodies, verifies the PR has the bot-generated label, and adds cms-approved. Job 2 listens for pull_request.labeled events where the label is cms-approved and the PR has the bot-generated label, and immediately squash-merges with gh pr merge --squash --admin.

This label-based coordination is robust against failure. If the associated PR is not bot-generated (missing the bot-generated label), Job 1 replies with a warning and exits. If the user types /publish before the bot has opened a PR, Job 1 replies with a helpful message and exits cleanly. If gh pr create failed but the waiting label was already removed, the label-based trigger would not fire because the PR does not exist. The state machine degrades gracefully: the user replies again, the clarification loop re-triggers, and the system recovers.

The factory does not just write code. It generates images. Two distinct pipelines handle media: insight article headers and spotlight headshots. Both use fal.ai, both enforce a monthly spend cap, and both exit with structured JSON that the workflow parses.

The insight header pipeline lives in scripts/cms/generate-image.ts. It uses fal-ai/flux/dev as the primary model and fal-ai/flux/schnell as the fallback. The prompt is appended with . No text, no logos. to prevent the model from rendering watermarks or typography. The output is resized to 1200×630 via sharp, EXIF-stripped, and written atomically to public/images/insights/{slug}.png.

The headshot pipeline lives in scripts/cms/generate-headshot.ts. It uses fal-ai/gpt-image-2 as the primary model (image-to-image conditioning) and fal-ai/flux-pro/kontext as the fallback. The input photo is base64-encoded and passed as image_url. The canonical STYLE_PROMPT is professional headshot, light neutral background, soft fill lighting, square crop 1:1, no text, photographic style. The output is 1024×1024, EXIF-stripped, and written to public/images/spotlight/{slug}.png.

Both pipelines share a cost logging mechanism: .cms-fal-log.json. It tracks requests and costUsd per month. The checkCap function throws when spend reaches 90% of FAL_MONTHLY_CAP_USD. This is not a soft warning. It is a hard stop that prevents the agent from burning the monthly budget on a runaway generation loop.

The download-attachment.ts script handles location photos and user-uploaded spotlight photos. It validates MIME type (image/*), enforces a 10 MB streaming byte cap, guards against path traversal in the slug, strips EXIF via sharp.rotate().png(), and writes atomically using a temp file and fs.renameSync. It also checks that the output path is not a symlink or special file before overwriting.

Cost governance in a dark factory is not an afterthought. It is a first-class concern because the dominant cost is LLM inference, and runaway agents can burn through a daily budget before anyone notices. The Groupon pipeline has three cost control layers: per-PR cost reporting, daily spend alerts, and monthly media caps.

scripts/cms/cost-report.ts generates a markdown cost block for every PR. It reads .cms-fal-log.json for fal.ai spend and estimates Anthropic cost using Claude Opus pricing: $15/MTok input, $75/MTok output. If the action does not expose per-run token counts (which claude-code-action@beta does not as of the latest calibration), the script falls back to estimating from ISSUE_BODY_LENGTH: ~4 characters per token, plus a 2,000 token base for context, with output assumed at 30% of input.

scripts/cms/check-daily-spend.ts runs on a cron at 07:00 UTC (after stale PR cleanup at 06:00 UTC). It estimates yesterday's total spend from .cms-fal-log.json and .cms-token-log.json, compares it against DAILY_SPEND_THRESHOLD_USD (default 50), and opens a GitHub issue with label ops-cost-alert if the threshold is exceeded. The issue body includes a JSON breakdown and instructions to set CMS_BOT_ENABLED=false to pause the factory.

A dark software factory is not about removing humans from software development. It is about removing humans from the parts that do not need them: the translation from spec to branch, from branch to PR, from PR to merge, and from merge to deployed preview. The human still writes the spec, still approves the merge with /publish, and still designs the harness that constrains the agent via AGENTS.md and allowed_tools.

What changes is the latency. A content request that once sat in a backlog for two days now ships in twenty minutes. A bug report that once required finding an available engineer now generates a fix while the reporter is still writing the reproduction steps. The factory does not replace judgment; it compresses execution.

The 11 workflow files in this article are under 700 lines combined. The complexity is not in the code; it is in the edge cases. The BOT_PAT behavior, the recursive trigger prevention, the branch detection timing, the WAITING/READY signal protocol, and the media generation fallback chains are all learned from failed runs, not from documentation. Build the simple version first, run it for a week, and let the failures teach you what to guard against. The factory that cannot fail gracefully is not a factory. It is a bomb.