Ops & verification · control-plane primitive

A pattern from the gf.cx specimen book

Flag an agent to investigate

A failing check, an at-risk asset, a broken pipe — the reader is already looking at the problem. This pattern makes acting on it one click: a [data-flag] anchor that files a durable, dedupe-aware GitHub issue and fires a push, from any surface, with zero per-surface plumbing.

The three shared parts

Drop-in

<script src="https://assets.gf.cx/flag/flag.js" defer></script>

<a data-flag
   data-flag-subject="core scripts · linode_status.py"
   data-flag-context="no backing repo identified"
   data-flag-source="status.gf.cx/#core-recoverability"
   data-flag-dedupe="core/linode_status.py">🚩 flag</a>

The contract

Button states

🚩 flag → 🚩 flagging… → ✓ issue #N · pushed (links to the issue). A repeat flag on the same dedupe key reads ✓ issue #N · existing. On failure: ⚠ flag failed — retry.

Response

{ "ok": true, "issue": { "number": 128, "url": "https://github.com/…/128" },
  "deduped": false, "pushed": true }

Why a control plane

Same model as the made-with footer and the favicon: one source of truth, adopted by attributes. The wording, the endpoint, the abuse-gating live in one place — change them once and every surface follows. No copy-pasted fetch handler to drift.

Reference

Origin
status.gf.cx /core recoverability surface, 2026-08-05. Wired as a fleetwide ops-baseline control-plane primitive.
Client asset
assets.gf.cx/flag/flag.js — one delegated listener, no per-surface wiring.
Central endpoint
status.gf.cx/flag — secrets, GitHub issue filing, push, CORS allowlist for *.gf.cx.
Related patterns
Built-with provenance footer — the same control-plane model applied to page provenance. Investigate via agent — the detail-page panel that surfaces attributed failure points.
Build cost
One <script defer> per surface; one data-flag anchor per item. The shared script caches portfolio-wide. Secrets, endpoint, and dedup logic live in one place — zero per-surface work after the initial wire-up.