p24-infra Docs

cross-project-infra-requests

7 min read

Playbook: Submitting Cross-Project Infra Task Requests

Audience: Claude agents in non-p24-infra repos (et-operational-platform, Art-Agency, brandpilot, radekkonarski-personal-brand, etc.) that need infrastructure work done. For how requests are processed, see docs/playbooks/infra-task-executor.md.

When to use

Use this system when your session needs infrastructure work it cannot do itself:

  • Any server-side change (restart, deploy, config edit, credential rotation)
  • Any Supabase admin operation (schema change, RLS update, user grant)
  • Any DNS or Cloudflare change
  • Spinning up background workers for feature implementation in any repo

Do NOT use for:

  • Code edits and PRs in the current repo
  • Vercel env var changes (use Vercel dashboard or vercel env CLI)
  • Supabase migrations in the current repo (use supabase db push)

Before you submit — create a tracking issue in your own repo

Every infra request needs a Return-To issue in the originating repo. This is what p24-infra uses to post its callback comment and remove the waiting-infra label when the work is done.

Before submitting the infra request:

  1. If an issue already exists (e.g. a feature tracking issue like #27) — use it as Return-To.
  2. If no issue exists — create one first in your own repo:
gh issue create `
  --repo radieu/<your-repo> `
  --title "<short description of what you're waiting on infra for>" `
  --label "waiting-infra" `
  --body "Tracking issue for infra work. Callback from radieu/p24-infra will be posted here."
  1. Add the waiting-infra label to the issue (signals the pipeline it’s blocked on infra):
# Create the label if it doesn't exist yet in the repo
gh label create "waiting-infra" --color "0075ca" --description "Blocked on infra work in radieu/p24-infra" --repo radieu/<your-repo>
 
# Add to the issue
gh issue edit <N> --repo radieu/<your-repo> --add-label "waiting-infra"
  1. Use that issue number as Return-To: radieu/<your-repo>#<N> in the infra request body.

When p24-infra completes the work it will:

  • Post a callback comment on your Return-To issue
  • Remove the waiting-infra label so the pipeline knows it can proceed

Never use Return-To: none unless there is genuinely no downstream work waiting — workers flag none for human review to prevent silently lost results.

How to submit

Using the /request-infra skill (preferred)

/request-infra

The skill guides you through confirming the Return-To reference, choosing a priority, writing a clear task description, and submitting the issue.

Manual submission

gh issue create `
  --repo radieu/p24-infra `
  --title "[infra-task] <short description>" `
  --label "infra-task-request" `
  --body @"
Return-To: radieu/<your-repo>#<your-issue-number>
Priority: normal
E2E/Browser: no
 
## Task description
 
<Specific description of exactly what needs to be done — include service names,
container names, file paths, or SQL statements as appropriate. Never include
credential values.>
"@

Priority values: normal (default, processed in order) or urgent (processed first, use sparingly — for outages and data-loss risk only).

Issue body format (required)

Every infra-task-request issue body must include these lines at the top:

Return-To: radieu/<repo>#<issue-number>
Priority: normal|urgent
E2E/Browser: yes|no

## Task description

<specific description of what needs to be done>

Rules:

  • Return-To must reference a real issue in the originating repo (e.g. radieu/et-operational-platform#742). Use Return-To: none only if there is genuinely no issue to callback — workers flag none for human review to prevent lost results.
  • E2E/Browser — required field. Set to yes if the task includes running end-to-end tests or a browser (Playwright, Cypress, Puppeteer, headed Chrome, etc.). Set to no otherwise. The dispatcher uses this to classify worker weight: yes → heavy client (needs display/GPU resources, longer timeout); no → light client (CLI/API-only, standard timeout). Omitting this field defaults to no but logs a warning.
  • Never include credential values, passwords, API keys, or tokens in the issue body. Reference variable names only (e.g. rotate SUPABASE_SERVICE_KEY in secrets/brandpilot.env.sops).
  • For destructive operations — any task containing the words delete, drop, wipe, remove, truncate, or reset — the worker will automatically add a human-action label and pause before executing. A human must review the issue and remove human-action to unblock.

What to expect after submission

Your issue is picked up by the p24-infra worker infrastructure within ~2 minutes and executed autonomously. When done, the worker posts a callback comment on your Return-To issue and removes the waiting-infra label.

Track progress via GH labels on the p24-infra issue:

LabelMeaning
infra-task-requestSubmitted, awaiting pickup
wipWorker running
human-actionWorker paused — human review needed (see below)
infra-doneTask complete, callback posted

What to do while waiting

Do not block on the infra task. After submitting:

  1. Continue with all other tasks that do not depend on the infra result.
  2. Note the waiting-infra label on your Return-To issue — it will be removed when the callback arrives.
  3. Watch the Return-To issue for a new comment from the p24-infra worker.
  4. Once the callback comment arrives and waiting-infra is removed, resume dependent work.

Do not poll the p24-infra issue repeatedly — one status check after ~5 minutes is enough. The callback is the signal.

If the task gets stuck or human-action is added

You do not have the access to investigate or unblock the worker yourself. Post a comment on the p24-infra issue describing the situation and mention @radieu so a p24-infra admin picks it up.

If human-action was added because of a destructive keyword:

  1. Read the comment the worker posted — it explains what triggered the gate.
  2. If the operation is intentional: add a comment confirming approval (Approved — proceed), then ask a p24-infra admin to remove human-action and re-add infra-task-request.
  3. If the description needs clarification: edit the issue body, then ask an admin to re-queue.

Multi-step tasks — Orchestrator pattern

When a task has internal dependencies (step B needs step A, but step C is independent of step B), submit one orchestrator issue describing the full dependency graph — not multiple separate issues.

Why not multiple issues? The worker queue has no guaranteed ordering. Submitting 4 issues means up to 4 workers pick them up in unknown order — sequencing is broken. One orchestrator issue lets a single worker manage parallelism and sequencing correctly.

Format the dependency graph in the issue body:

## Dependency graph

Parallel (wave 1 — no mutual dependencies):
  [A] Supabase: run migrations user_storage + user_devices with RLS
  [B] Wasabi: create IAM policy wa-per-user-provisioning

Sequential (wave 2 — after A completes):
  [C] CF Worker wa-app-api: wrangler deploy (needs tables from A to write to)

Sequential (wave 3 — after C completes):
  [D] Vercel project p24-wa-a: create project, set root=web/, add env vars
      NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY,
      NEXT_PUBLIC_API_URL=<CF Worker URL from step C>

## Tasks

### [A] Supabase migrations
<specific SQL / migration file path>

### [B] Wasabi IAM
<policy JSON or reference to file in repo>

### [C] CF Worker deploy
<wrangler deploy command, secrets to inject>

### [D] Vercel project
<vercel project link command, env vars to set>

When to use multiple issues instead:

  • Tasks are genuinely unrelated (different services, no data flow between them)
  • Each task could succeed or fail independently without affecting the others
  • You want separate callbacks per task

Prevention

  • Always include a specific Return-To. Lost callbacks mean dependent work is never resumed.
  • Be specific. Name exact container names, service names, file paths, table names. Vague tasks always get human-action-gated.
  • Avoid unnecessary destructive-op keywords. If the operation is additive (restart, reload, add row, update config), do not use delete or remove unless you mean it.
  • One issue per logical operation group. For dependent multi-step work use the Orchestrator pattern above. For unrelated operations (different services, independent outcomes) submit separate issues. Never mix both patterns — a single issue covering unrelated operations that independently succeed/fail makes partial-failure handling impossible.
  • Do not submit the same task twice — check the p24-infra issue list for your Return-To first. Duplicate requests will both execute.
  • /request-infra skill — ~/.claude/commands/request-infra.md
  • Executor playbook (p24-infra admin): docs/playbooks/infra-task-executor.md

Graph View

Backlinks