菜单
DNS operations for Cogni multi-node infrastructure. Node app DNS is automatic + catalog-driven (do NOT hand-set it); this skill owns the genuinely-manual surface — one-time Cloudflare zone setup, the env apex record, decommissioning a purged node's record, and protected-record safety.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Manage which deploy-environments a Cogni node lives in (candidate-a / preview / production) via the operator app — the full request→owner-approve→verb→merge→verify loop for env (deploy-topology) membership. Use whenever an agent needs to add a node to an env or remove it from one, is asked to 'give this node a preview deploy', 'promote this node into production topology', 'take a node out of preview', 'stop deploying X to candidate-a', 'change a node's deploy reach / env set', 'onboard my node to an environment', or hits a 403 authz_denied / 503 authz_unavailable on POST /api/v1/nodes/{id}/envs. Also triggers on 'env_manager', 'can_manage_envs', 'env-membership PR', 'node deploy topology', 'catalog envs: line'. This is distinct from FLIGHTING a build (candidate-flight / can_flight) and from PROMOTING a sha (promote / can_promote_production) — env-membership changes WHERE a node is deployed, not WHICH build runs there. Do NOT use for provisioning a whole environment (that is provision-env), for secret-writes (
Take a Cogni node from NOT-deployed to live-and-validated on candidate-a, end to end, as a node-contributor agent — RBAC request → owner approve → env-membership verb (add candidate-a) → merge → Argo auto-reconcile → agent-api-validation. This is the cold-start runbook: a fresh agent with only its COGNI API key + a node id can follow it start to finish. Use when asked to 'get my node onto candidate-a', 'deploy node X to candidate-a', 'prove a node deploys e2e', 'add a node to the candidate environment', or to validate the env-membership verb against a real deployment. Distinct from node-setup (which BIRTHS a node into the registry — a prerequisite here) and from flighting/promoting a BUILD (candidate-flight / promote — which pick which image runs in an env you're already in). This picks the ENV itself, then proves the node actually deployed and answers.
Authoritative reference for the cogni-template test pyramid and production-like e2e test topology — enforcement vs test layers, vitest configs, infra prereqs, GitHub/DoltHub test org boundaries, the cogni-operator-test app, what agents can/can't run locally, coverage tracking, and the non-obvious gotchas that bite every time. Use this skill whenever the user is writing a new test, asking "which layer does this belong in", debugging a flaky test, hitting CWD/env-loading issues, deciding between unit/component/stack/external, running any `pnpm test:*` or `pnpm arch:check` / `pnpm lint` command, working with testcontainers, touching fake adapters or `APP_ENV=test`, troubleshooting skip-gates, seeing errors from `.env.test` not loading, wondering about coverage or whether a test will run in CI, or trying to decide whether to run stack/e2e locally vs defer to CI. Also trigger when the user mentions mocking the database, Privy/GitHub App construction errors in tests, the smee proxy, `pnpm test:smee`, validating the
CI/CD architecture reviewer and DevOps advisor for monorepo pipelines, branch workflows, and deployment strategy. Use this skill when reviewing GitHub Actions workflows, designing promotion pipelines, evaluating branch protection rules, reviewing deploy scripts, auditing CI/CD for anti-patterns, or making decisions about build/test/deploy strategy. Also triggers for: 'review this workflow', 'is this CI pattern correct', 'branch strategy', 'deploy pipeline design', 'release promotion', 'should we use PRs for this', 'CI is slow', 'pipeline gap analysis', 'provision', 'deploy script'.
Use whenever working on Cogni USDC credit top-ups, payment intent creation, payment activation, operator wallet funding, 0xSplits allocations, x402 outbound provider payments, Hyperbolic, EIP-3009 signatures, retired OpenRouter/Coinbase top-ups, system-tenant revenue share, repo-spec payment config, live payment rail guards, payment CI failures, or debugging money-loop behavior. Trigger on phrases like payments, payment rail, credits top-up, USDC, Split, 0xSplits, splitHash, x402, Hyperbolic, facilitator, signX402Payment, EIP-3009, OpenRouter funding, Coinbase Commerce, operator wallet, Privy wallet, markup_factor, revenue_share, system bonus, provider top-up, settlement_skipped, SPLIT_CONFIG_MISMATCH, activate payments, node payments, or "is this payment behavior validated". This skill is the launching point for future payments work and debugging.
Use when setting up, reviewing, or changing Cogni Conductor worktree bootstrap, including conductor.json, scripts/conductor-worktree-setup.sh, secret/auth symlinks, and AI launch-pack references for human or AI developers.
| name | dns-ops |
| description | DNS operations for Cogni multi-node infrastructure. Node app DNS is automatic + catalog-driven (do NOT hand-set it); this skill owns the genuinely-manual surface — one-time Cloudflare zone setup, the env apex record, decommissioning a purged node's record, and protected-record safety. |
Node app DNS is automatic, deterministic, and catalog-driven. Do NOT hand-create or curl-upsert per-node records. A hand-made <node>-<env> record drifts from the catalog the next flight reconciles. This skill is for the genuinely manual surface only: one-time Cloudflare zone setup, the env apex record, decommissioning a purged node, and protected-record safety.
Per-node public hosts — <node>-test.cognidao.org (candidate-a), <node>-preview.cognidao.org (preview), <node>.cognidao.org (prod) — are reconciled on every flight/promote, idempotently:
scripts/ci/reconcile-node-dns.sh <env> runs as the env-level reconcile-dns job in candidate-flight.yml (candidate-a) and promote-and-deploy.yml (preview/prod).type:node set, derives each host via host_for_node (scripts/ci/lib/image-tags.sh), reads the env VM IP from the operator apex A record, and upserts <node>-<env> → that IP, mirroring the apex's proxy state./version verify needs: it, so a node added to infra/catalog/<node>.yaml resolves at its public host on its first flight — no *-test wildcard, no hand-made record.scripts/ci/lib/cloudflare-dns.sh — refuses the zone apex / www unless CF_ALLOW_PROTECTED=1. CLOUDFLARE_API_TOKEN / CLOUDFLARE_ZONE_ID are env-scoped GH secrets; an env without them logs a warning and skips (its new nodes won't resolve) rather than failing the promote.docs/spec/ci-cd.md Axiom 21 DNS_IS_RECONCILED_PER_ENV. Don't duplicate the flow — point here.Therefore:
<node>-test shows NXDOMAIN right after a flight → almost always negative-cache on your resolver; re-check with dig <host> +short @1.1.1.1. If the flight's reconcile-dns job was green, the record exists.Only needed when standing up a brand-new zone. Existing envs are already wired.
dig <domain> NS +short shows cloudflare).CLOUDFLARE_API_TOKEN + CLOUDFLARE_ZONE_ID (not just .env.local) so CI's reconcile-dns can use them.<env> domain + <env>.vm.cognidao.org)This is the ONE record node DNS derives from — every <node>-<env> record inherits the apex's IP + proxy state. It is provisioned with the VM (scripts/setup/provision-env-vm.sh), not by reconcile-node-dns.sh. On a VM migration, update the apex together with the VM_HOST + SSH_DEPLOY_KEY GH secrets — see devops-expert's "deploy-pointer drift" rule.
reconcile-node-dns.sh only upserts; it never prunes. When a node leaves the catalog, its <node>-<env> record is orphaned (harmless but stale). Remove it explicitly via the @cogni/dns-ops helper (enforces protected-record safety):
import { CloudflareAdapter, removeDnsRecord } from "@cogni/dns-ops";
const cf = new CloudflareAdapter({
apiToken: process.env.CLOUDFLARE_API_TOKEN,
zoneId: process.env.CLOUDFLARE_ZONE_ID,
});
await removeDnsRecord(cf, "cognidao.org", "<node>-test", "A");
NEVER modify @ (zone apex), www, or MX records. @cogni/dns-ops (upsertDnsRecord/removeDnsRecord) and cloudflare-dns.sh enforce this — they throw PROTECTED / refuse without CF_ALLOW_PROTECTED=1 (only env provisioning of the apex sets it). For these, use the Cloudflare dashboard, never CI.
cognidao.org — Namecheap, expires 2027-04-06 (renew annually; a 2026-04-05 lapse caused a ~6h outage). Full inventory: work/charters/DOMAINS.md.
| Symptom | Fix |
|---|---|
<node>-<env> NXDOMAIN just after a green flight | Negative-cache. dig <host> +short @1.1.1.1; flush local (sudo dscacheutil -flushcache). If reconcile-dns was green the record exists. |
| Born node Healthy + DNS resolves but page 000/unreachable | Not DNS — the edge Caddy route. Reconciled by the flight's node-substrate job (reconcile-node-substrate.sh → reconcile-edge-caddy.remote.sh); see ci-cd.md. |
| A node never gets a record on flight | Env is missing CLOUDFLARE_API_TOKEN/CLOUDFLARE_ZONE_ID (reconcile skips with a warning), OR the node isn't a catalog type:node with envs: including that env. |
PROTECTED: refusing to modify | You targeted @/www. Use the dashboard. |
403 from Cloudflare | Token lacks Zone · DNS · Edit. Recreate. |
Legacy note:
packages/dns-ops/scripts/create-node.tscreates a<slug>.nodes.cognidao.orgformation/node-spec record — a separate, pre-Axiom-21 path, NOT the per-env app host. App-host DNS is the catalog-driven flow above; do not use create-node.ts for it.