Indexado en Registry

start-temps-cluster

Precio sin confirmar★ 728 Estrellas de GitHubRegistro actualizado · 17 sept 2026agent-skill

Resumen

Start (or restart) a local multi-node Temps cluster using Docker-in-Docker — one control plane + 3 worker nodes, each a privileged DinD container running its own dockerd + `temps agent`, wired with the real multi-host overlay (VXLAN, compute_cidr allocation) via `tools/dev-cluster/` in whichever checkout/worktree you run it from. Invoke when the user says "start the temps cluster", "spin up a multi-node dev cluster", "test this with multiple workers", "bring up worker nodes locally", "docker in dind cluster", or wants to verify cross-node behavior (node targeting, cluster DNS, overlay networking, node join/mTLS) that a single-node `start-temps` server cannot exercise. Distinct from `start-temps` (single-node, native binary, port-slot based) and `start-temps-ee` (single-node EE binary) — this is the only path that actually has more than one node.

Leer documentación completa

Documentación de origen, no instrucciones para este sitio. Revisa los permisos antes de ejecutar comandos.

Start a local multi-node Temps cluster (Docker-in-Docker)

Wraps tools/dev-cluster/ — a docker-compose harness that runs a real Temps control plane plus 3 worker nodes, each a privileged DinD container, with the actual overlay network (VXLAN, compute_cidr allocation, cluster DNS) wired up exactly as it would be on real hardware. Use this whenever a fix or feature needs more than one node to prove anything — single-node start-temps cannot exercise cross-node scheduling, the overlay, or cluster DNS at all.

Topology

┌──── temps-underlay (10.42.0.0/24, docker bridge, the "VPC") ────┐
│                                                                  │
│  postgres            10.42.0.5   (TimescaleDB pg18, internal)   │
│  control-plane        10.42.0.10  DinD + `temps serve`           │
│    host ports 80 → 80, 443 → 443 (NOT 8080 — see Gotcha below)  │
│                                                                  │
│  worker-1  10.42.0.21   worker-2  10.42.0.22   worker-3 10.42.0.23│
│    each: privileged DinD + `temps agent`, own dockerd            │
└──────────────────────────────────────────────────────────────────┘

Allocator carves /24s from 172.20.0.0/16, one per worker:
  worker-1 → 172.20.0.0/24
  worker-2 → 172.20.1.0/24
  worker-3 → 172.20.2.0/24

Cross-node container traffic flows over a VXLAN tunnel pinned to the
underlay IPs above. Within-node traffic uses the unchanged
`temps-app-network` Docker bridge (same as single-node temps).

The temps source tree is bind-mounted read-write at /workspace inside every DinD container, and cargo build --bin temps runs inside Linux — no cross-compiling from macOS. The cluster builds from whichever checkout you run ./dev-cluster in. cd into the right worktree first if you're testing a fix that isn't on the checkout's current branch.

Prerequisites

Docker Desktop (or any Linux Docker host) running — docker version must succeed.
~3 GB free RAM, ~5 GB free disk (compiled binary cache + 4 worker volumes + TimescaleDB volume).
GeoLite2-City.mmdb at the repo root of the checkout you're running from (<checkout>/GeoLite2-City.mmdb, gitignored) — the proxy plugin refuses to start without it. Download it from MaxMind's GeoLite2 program (free registration required) and place it at the repo root. If you keep multiple worktrees of this repo, copying the file between them is faster than downloading it again.

Only one cluster at a time, across the ENTIRE machine

Unlike start-temps (which allocates a port "slot" per checkout so many worktrees run side by side), this harness uses fixed container names (temps-dev-control-plane, temps-dev-worker-1/2/3, temps-dev-postgres) and fixed host ports (80/443). There is no per-checkout isolation — starting a second dev-cluster from a different worktree while one is already running will collide.

Before running up, always check first:

docker ps -a --filter "name=temps-dev-" --format "{{.Names}}\t{{.Status}}"

If containers are already there and belong to someone else's in-progress work, don't down/reset them without asking — treat it like any other shared, hard-to-reverse state.

There's also a separate mTLS-hardening variant (docker-compose.harden.yml, driven by e2e-harden.sh, container prefix temps-harden-*, 2 workers only) used for testing require_mtls / node-identity hardening specifically. It's a different compose project name/port set from the base cluster, but still only one can run at a time on its own.

Quick start

cd <checkout>/tools/dev-cluster
./dev-cluster up          # first run: ~5-10 min (compiles the workspace inside Linux)
                           # subsequent runs: ~10-30s (cargo build no-ops)

up blocks until: control plane's TCP listener is up, all 3 workers have registered as nodes rows, and every worker has an allocated compute_cidr. It prints admin credentials and the join-token path on success.

./dev-cluster status              # node + overlay state across the cluster
./dev-cluster logs control-plane   # or worker-1/worker-2/worker-3/postgres
./dev-cluster shell worker-1       # shell into a worker's DinD host
./dev-cluster restart control-plane  # bounce after a binary rebuild
./dev-cluster down                # stop, KEEP volumes (fast restart)
./dev-cluster reset               # stop + DELETE all volumes (fresh slate, asks to confirm)

Gotcha: the script says port 8080, the cluster actually serves 80/443

docker-compose.yml publishes 80:80 and 443:443 (production-shaped — TEMPS_ADDRESS=0.0.0.0:80), matching what e2e-harden.sh and every API recipe below assume (http://localhost/...). But dev-cluster's own up command waits on /dev/tcp/127.0.0.1/8080 and prints web UI: http://localhost:8080 — that's stale/drifted from the compose file and will never resolve. Use port 80, not 8080, for every API/browser interaction. If ./dev-cluster up looks stuck on "waiting for control plane", check whether it's actually already up on the right port before assuming a real hang:

curl -s -o /dev/null -w '%{http_code}\n' http://localhost/api/health

If that returns a real HTTP status, the cluster is up — the wait loop itself is just polling the wrong port and will eventually time out at 20 minutes regardless. Don't wait for it; move on once curl confirms readiness.

J=/tmp/tc_cookies.txt
PW=$(sed -n '2p' tools/dev-cluster/.state/admin.txt)
curl -s -c $J -X POST http://localhost/api/auth/login -H 'Content-Type: application/json' \
  -d "{\"email\":\"admin@local.dev\",\"password\":\"$PW\"}" -o /dev/null -w "login -> %{http_code}\n"

Verifying the overlay actually works (bare check, no API)

The README documents this network as temps-overlay — that name is wrong. Verified live: the actual Docker network on every worker is named temps0 (docker network ls inside a worker shows it). Use temps0, not temps-overlay, or docker run fails with "network temps-overlay not found".

./dev-cluster shell worker-1
docker run -d --rm --name target --network temps0 --ip 172.20.1.50 nginx:alpine
exit

./dev-cluster shell worker-2
docker run --rm --network temps0 --ip 172.20.0.50 alpine sh -c \
  'apk add -q curl && curl -sf --max-time 5 http://172.20.1.50/ | head -c150'
# "<!DOCTYPE html>..." => bridge + VXLAN + FDB + routes + dual-attach all confirmed working

(IPs above match worker-1 → 172.20.1.0/24, worker-2 → 172.20.0.0/24 — the allocator assigns CIDRs in registration order, not worker-number order, so confirm actual assignments with ./dev-cluster status rather than assuming worker-N always gets the Nth-numbered /24.)

Recipe: deploying across specific nodes (multi-replica / anti-affinity)

NIDS=$(curl -s -b $J http://localhost/api/internal/nodes | \
  python3 -c "import sys,json;print(','.join(str(n['id']) for n in json.load(sys.stdin)['nodes']))")

PID=$(curl -s -b $J -X POST http://localhost/api/projects -H 'Content-Type: application/json' \
  -d '{"name":"cluster-test","directory":".","main_branch":"main","preset":"dockerfile","storage_service_ids":[],"source_type":"docker_image"}' \
  | python3 -c "import sys,json;print(json.load(sys.stdin).get('id',''))")
EID=$(curl -s -b $J http://localhost/api/projects/$PID/environments | \
  python3 -c "import sys,json;print(json.load(sys.stdin)[0]['id'])")

curl -s -b $J -X PUT http://localhost/api/projects/$PID/environments/$EID/settings -H 'Content-Type: application/json' \
  -d "{\"replicas\":2,\"target_nodes\":[$NIDS],\"anti_affinity\":true,\"exposed_port\":8080}"

curl -s -b $J -X POST http://localhost/api/projects/$PID/environments/$EID/deploy/image -H 'Content-Type: application/json' \
  -d '{"image_ref":"nginxinc/nginx-unprivileged:alpine","health_check_path":"/"}'

Use nginxinc/nginx-unprivileged:alpine, not plain nginx:alpine. Every deployed container runs cap_drop: ALL + no-new-privileges; stock nginx needs to chown/bind a privileged port and crashes under that hardening. preset must be "dockerfile" (not "docker" — invalid) even for source_type: "docker_image". Pre-pull the image on every node first (docker exec temps-dev-worker-N docker pull <image>) if ensure_image_on_remote isn't wired for your image, or the deploy will fail on nodes without it cached.

Recipe: pinning a database service to one node, an app to another

SID=$(curl -s -b $J -X POST http://localhost/api/external-services -H 'Content-Type: application/json' \
  -d '{"name":"test-db","service_type":"postgres","node_id":<worker-1-node-id>,"topology":"standalone","parameters":{"database":"app","username":"app_user","password":"<pick-one>"},"members":[]}' \
  | python3 -c "import sys,json;print(json.load(sys.stdin).get('id',''))")

Then create the app project with "storage_service_ids":[$SID] (this is the link mechanism — set at project creation, there is no later update endpoint for it) and set target_nodes to a different node than the one above, to exercise cross-node service linking. Note a project can only link one service per service_type (e.g. one postgres, one redis) — linking a second postgres service to the same project fails.

Recipe: toggling cluster DNS

Cluster DNS defaults off. The setting is a top-level cluster_dns object with an enabled field — NOT multi_node.cluster_dns_enabled (that key doesn't exist in the real schema; writing it via raw SQL succeeds silently but does nothing, and disappears on the next control-plane restart since settings get re-normalized from the typed Rust struct on load). Verified live:

docker exec temps-dev-postgres psql -U temps -d temps -c \
  "update settings set data = jsonb_set(COALESCE(data::jsonb,'{}'),'{cluster_dns,enabled}','true'::jsonb)::json where id=1;"
docker exec temps-dev-postgres psql -U temps -d temps -tAc \
  "select data::jsonb->'cluster_dns' from settings where id=1;"   # => {"enabled": true}

Two restarts are required after this, not zero:

docker restart temps-dev-control-plane — a raw SQL write bypasses ConfigService's in-memory settings cache; the control plane won't see the change until it re-reads settings on startup (there's no live invalidation path for a write that didn't go through the settings API).
docker restart temps-dev-worker-1 temps-dev-worker-2 temps-dev-worker-3 (or at least whichever workers are relevant to your test) — the per-node DNS resolver is only spawned once, during initial agent startup. An agent that was already running when you flip cluster_dns.enabled will keep operating in "disabled" mode indefinitely; it does not poll for this setting changing live. This is a known gap (tracked as part of ADR-024, proposed not yet implemented) — don't lose time assuming a stuck deploy mean

Ver fuente ↗

Metadatos del archivo

name: start-temps-cluster
description: >
  Start (or restart) a local multi-node Temps cluster using Docker-in-Docker —
  one control plane + 3 worker nodes, each a privileged DinD container running
  its own dockerd + `temps agent`, wired with the real multi-host overlay
  (VXLAN, compute_cidr allocation) via `tools/dev-cluster/` in whichever
  checkout/worktree you run it from. Invoke when the user says "start the temps
  cluster", "spin up a multi-node dev cluster", "test this with multiple
  workers", "bring up worker nodes locally", "docker in dind cluster", or wants
  to verify cross-node behavior (node targeting, cluster DNS, overlay
  networking, node join/mTLS) that a single-node `start-temps` server cannot
  exercise. Distinct from `start-temps` (single-node, native binary, port-slot
  based) and `start-temps-ee` (single-node EE binary) — this is the only path
  that actually has more than one node.

Ver texto original

---
name: start-temps-cluster
description: >
  Start (or restart) a local multi-node Temps cluster using Docker-in-Docker —
  one control plane + 3 worker nodes, each a privileged DinD container running
  its own dockerd + `temps agent`, wired with the real multi-host overlay
  (VXLAN, compute_cidr allocation) via `tools/dev-cluster/` in whichever
  checkout/worktree you run it from. Invoke when the user says "start the temps
  cluster", "spin up a multi-node dev cluster", "test this with multiple
  workers", "bring up worker nodes locally", "docker in dind cluster", or wants
  to verify cross-node behavior (node targeting, cluster DNS, overlay
  networking, node join/mTLS) that a single-node `start-temps` server cannot
  exercise. Distinct from `start-temps` (single-node, native binary, port-slot
  based) and `start-temps-ee` (single-node EE binary) — this is the only path
  that actually has more than one node.
---

# Start a local multi-node Temps cluster (Docker-in-Docker)

Wraps `tools/dev-cluster/` — a docker-compose harness that runs a real Temps
control plane plus 3 worker nodes, each a privileged DinD container, with the
actual overlay network (VXLAN, `compute_cidr` allocation, cluster DNS) wired
up exactly as it would be on real hardware. Use this whenever a fix or feature
needs *more than one node* to prove anything — single-node `start-temps`
cannot exercise cross-node scheduling, the overlay, or cluster DNS at all.

## Topology

```
┌──── temps-underlay (10.42.0.0/24, docker bridge, the "VPC") ────┐
│                                                                  │
│  postgres            10.42.0.5   (TimescaleDB pg18, internal)   │
│  control-plane        10.42.0.10  DinD + `temps serve`           │
│    host ports 80 → 80, 443 → 443 (NOT 8080 — see Gotcha below)  │
│                                                                  │
│  worker-1  10.42.0.21   worker-2  10.42.0.22   worker-3 10.42.0.23│
│    each: privileged DinD + `temps agent`, own dockerd            │
└──────────────────────────────────────────────────────────────────┘

Allocator carves /24s from 172.20.0.0/16, one per worker:
  worker-1 → 172.20.0.0/24
  worker-2 → 172.20.1.0/24
  worker-3 → 172.20.2.0/24

Cross-node container traffic flows over a VXLAN tunnel pinned to the
underlay IPs above. Within-node traffic uses the unchanged
`temps-app-network` Docker bridge (same as single-node temps).
```

The temps source tree is bind-mounted read-write at `/workspace` inside every
DinD container, and `cargo build --bin temps` runs *inside Linux* — no
cross-compiling from macOS. **The cluster builds from whichever checkout you
run `./dev-cluster` in.** `cd` into the right worktree first if you're testing
a fix that isn't on the checkout's current branch.

## Prerequisites

- Docker Desktop (or any Linux Docker host) running — `docker version` must
  succeed.
- ~3 GB free RAM, ~5 GB free disk (compiled binary cache + 4 worker volumes +
  TimescaleDB volume).
- `GeoLite2-City.mmdb` at the **repo root of the checkout you're running
  from** (`<checkout>/GeoLite2-City.mmdb`, gitignored) — the proxy plugin
  refuses to start without it. Download it from
  [MaxMind's GeoLite2 program](https://dev.maxmind.com/geoip/geolite2-free-geolocation-data)
  (free registration required) and place it at the repo root. If you keep
  multiple worktrees of this repo, copying the file between them is faster
  than downloading it again.

## Only one cluster at a time, across the ENTIRE machine

Unlike `start-temps` (which allocates a port "slot" per checkout so many
worktrees run side by side), this harness uses **fixed container names**
(`temps-dev-control-plane`, `temps-dev-worker-1/2/3`, `temps-dev-postgres`)
and fixed host ports (80/443). There is no per-checkout isolation — starting a
second dev-cluster from a different worktree while one is already running
will collide.

**Before running `up`, always check first:**
```bash
docker ps -a --filter "name=temps-dev-" --format "{{.Names}}\t{{.Status}}"
```
If containers are already there and belong to someone else's in-progress
work, don't `down`/`reset` them without asking — treat it like any other
shared, hard-to-reverse state.

There's also a separate mTLS-hardening variant (`docker-compose.harden.yml`,
driven by `e2e-harden.sh`, container prefix `temps-harden-*`, 2 workers only)
used for testing `require_mtls` / node-identity hardening specifically. It's a
different compose project name/port set from the base cluster, but still only
one can run at a time on its own.

## Quick start

```bash
cd <checkout>/tools/dev-cluster
./dev-cluster up          # first run: ~5-10 min (compiles the workspace inside Linux)
                           # subsequent runs: ~10-30s (cargo build no-ops)
```

`up` blocks until: control plane's TCP listener is up, all 3 workers have
registered as `nodes` rows, and every worker has an allocated `compute_cidr`.
It prints admin credentials and the join-token path on success.

```bash
./dev-cluster status              # node + overlay state across the cluster
./dev-cluster logs control-plane   # or worker-1/worker-2/worker-3/postgres
./dev-cluster shell worker-1       # shell into a worker's DinD host
./dev-cluster restart control-plane  # bounce after a binary rebuild
./dev-cluster down                # stop, KEEP volumes (fast restart)
./dev-cluster reset               # stop + DELETE all volumes (fresh slate, asks to confirm)
```

## Gotcha: the script says port 8080, the cluster actually serves 80/443

`docker-compose.yml` publishes `80:80` and `443:443` (production-shaped —
`TEMPS_ADDRESS=0.0.0.0:80`), matching what `e2e-harden.sh` and every API
recipe below assume (`http://localhost/...`). But `dev-cluster`'s own `up`
command waits on `/dev/tcp/127.0.0.1/8080` and prints `web UI:
http://localhost:8080` — that's stale/drifted from the compose file and will
never resolve. **Use port 80, not 8080**, for every API/browser interaction.
If `./dev-cluster up` looks stuck on "waiting for control plane", check
whether it's actually already up on the right port before assuming a real
hang:
```bash
curl -s -o /dev/null -w '%{http_code}\n' http://localhost/api/health
```
If that returns a real HTTP status, the cluster is up — the wait loop itself
is just polling the wrong port and will eventually time out at 20 minutes
regardless. Don't wait for it; move on once curl confirms readiness.

Login: `admin@local.dev` / password on line 2 of `.state/admin.txt`.

```bash
J=/tmp/tc_cookies.txt
PW=$(sed -n '2p' tools/dev-cluster/.state/admin.txt)
curl -s -c $J -X POST http://localhost/api/auth/login -H 'Content-Type: application/json' \
  -d "{\"email\":\"admin@local.dev\",\"password\":\"$PW\"}" -o /dev/null -w "login -> %{http_code}\n"
```

## Verifying the overlay actually works (bare check, no API)

The README documents this network as `temps-overlay` — that name is wrong.
Verified live: the actual Docker network on every worker is named **`temps0`**
(`docker network ls` inside a worker shows it). Use `temps0`, not
`temps-overlay`, or `docker run` fails with "network temps-overlay not
found".

```bash
./dev-cluster shell worker-1
docker run -d --rm --name target --network temps0 --ip 172.20.1.50 nginx:alpine
exit

./dev-cluster shell worker-2
docker run --rm --network temps0 --ip 172.20.0.50 alpine sh -c \
  'apk add -q curl && curl -sf --max-time 5 http://172.20.1.50/ | head -c150'
# "<!DOCTYPE html>..." => bridge + VXLAN + FDB + routes + dual-attach all confirmed working
```

(IPs above match worker-1 → `172.20.1.0/24`, worker-2 → `172.20.0.0/24` — the
allocator assigns CIDRs in registration order, not worker-number order, so
confirm actual assignments with `./dev-cluster status` rather than assuming
worker-N always gets the Nth-numbered /24.)

## Recipe: deploying across specific nodes (multi-replica / anti-affinity)

```bash
NIDS=$(curl -s -b $J http://localhost/api/internal/nodes | \
  python3 -c "import sys,json;print(','.join(str(n['id']) for n in json.load(sys.stdin)['nodes']))")

PID=$(curl -s -b $J -X POST http://localhost/api/projects -H 'Content-Type: application/json' \
  -d '{"name":"cluster-test","directory":".","main_branch":"main","preset":"dockerfile","storage_service_ids":[],"source_type":"docker_image"}' \
  | python3 -c "import sys,json;print(json.load(sys.stdin).get('id',''))")
EID=$(curl -s -b $J http://localhost/api/projects/$PID/environments | \
  python3 -c "import sys,json;print(json.load(sys.stdin)[0]['id'])")

curl -s -b $J -X PUT http://localhost/api/projects/$PID/environments/$EID/settings -H 'Content-Type: application/json' \
  -d "{\"replicas\":2,\"target_nodes\":[$NIDS],\"anti_affinity\":true,\"exposed_port\":8080}"

curl -s -b $J -X POST http://localhost/api/projects/$PID/environments/$EID/deploy/image -H 'Content-Type: application/json' \
  -d '{"image_ref":"nginxinc/nginx-unprivileged:alpine","health_check_path":"/"}'
```

**Use `nginxinc/nginx-unprivileged:alpine`, not plain `nginx:alpine`.** Every
deployed container runs `cap_drop: ALL` + `no-new-privileges`; stock nginx
needs to `chown`/bind a privileged port and crashes under that hardening.
`preset` must be `"dockerfile"` (not `"docker"` — invalid) even for
`source_type: "docker_image"`. Pre-pull the image on every node first
(`docker exec temps-dev-worker-N docker pull <image>`) if `ensure_image_on_remote`
isn't wired for your image, or the deploy will fail on nodes without it cached.

## Recipe: pinning a database service to one node, an app to another

```bash
SID=$(curl -s -b $J -X POST http://localhost/api/external-services -H 'Content-Type: application/json' \
  -d '{"name":"test-db","service_type":"postgres","node_id":<worker-1-node-id>,"topology":"standalone","parameters":{"database":"app","username":"app_user","password":"<pick-one>"},"members":[]}' \
  | python3 -c "import sys,json;print(json.load(sys.stdin).get('id',''))")
```
Then create the app project with `"storage_service_ids":[$SID]` (this is the
link mechanism — set at project creation, there is no later update endpoint
for it) and set `target_nodes` to a *different* node than the one above, to
exercise cross-node service linking. Note a project can only link one service
per `service_type` (e.g. one postgres, one redis) — linking a second postgres
service to the same project fails.

## Recipe: toggling cluster DNS

Cluster DNS defaults **off**. The setting is a **top-level `cluster_dns`
object with an `enabled` field** — NOT `multi_node.cluster_dns_enabled` (that
key doesn't exist in the real schema; writing it via raw SQL succeeds
silently but does nothing, and disappears on the next control-plane restart
since settings get re-normalized from the typed Rust struct on load).
Verified live:
```bash
docker exec temps-dev-postgres psql -U temps -d temps -c \
  "update settings set data = jsonb_set(COALESCE(data::jsonb,'{}'),'{cluster_dns,enabled}','true'::jsonb)::json where id=1;"
docker exec temps-dev-postgres psql -U temps -d temps -tAc \
  "select data::jsonb->'cluster_dns' from settings where id=1;"   # => {"enabled": true}
```

**Two restarts are required after this, not zero:**
1. `docker restart temps-dev-control-plane` — a raw SQL write bypasses
   `ConfigService`'s in-memory settings cache; the control plane won't see
   the change until it re-reads settings on startup (there's no live
   invalidation path for a write that didn't go through the settings API).
2. `docker restart temps-dev-worker-1 temps-dev-worker-2 temps-dev-worker-3`
   (or at least whichever workers are relevant to your test) — **the per-node
   DNS resolver is only spawned once, during initial agent startup.** An
   agent that was already running when you flip `cluster_dns.enabled` will
   keep operating in "disabled" mode indefinitely; it does not poll for this
   setting changing live. This is a known gap (tracked as part of ADR-024,
   proposed not yet implemented) — don't lose time assuming a stuck deploy
   mean

Revisar el código fuente

Precio y costes de ejecución

Obtener el skill: Precio sin confirmar
Ejecutarlo: Requisitos sin confirmar. Consulta los costes del agente, API y servicios en la fuente.
Licencia: Apache-2.0
Precio sin confirmar: No hemos confirmado el precio. Los enlaces existentes al código y a la instalación siguen disponibles.

Obtener gratis no significa ejecutar gratis. El precio no es una evaluación de seguridad. Enviar información de precio →

La fuente requiere revisión

La fuente cambió o no pudo sincronizarse. Revísala antes de instalar.

Revisar antes de instalar: Evitar instalación automática

Licencia: Apache-2.0

Dependency or permission surface needs review
Permission surface may require sandboxing
Financial research output is not financial advice; require human review before any live investment decision
The skill instructs running privileged Docker containers, which carries inherent security risks, but this is expected for a local development cluster and is clearly scoped.
The skill requires downloading a GeoLite2 database from an external source, which could be a supply-chain concern, but it is a standard practice and the file is gitignored.
Financial research output is not financial advice; require human review before any live investment decision.
Quality score needs review
Permission surface needs review: secrets or environment access, shell or command execution
Dependency/runtime risk: command execution surface, credential or environment access
Permission surface: secrets or environment access, shell or command execution

Abrir auditoría completa

Las herramientas son indicios de metadatos, no compatibilidad probada. Los prompts son sugerencias.

Empieza con una tarea pequeña

1Lee la fuente y confirma entradas, resultados, dependencias y permisos.
2Pide un plan al agente. Aprueba la configuración y los costes antes de probar en un entorno aislado.
3Comprueba resultados y archivos modificados. Informa solo de lo ejecutado y conserva la revisión de la fuente.

Consulta dependencias, claves API y costes externos en la fuente. Un repositorio público no implica servicios gratuitos.

Fuente y notas de uso

Indexado

Los metadatos y revisiones son orientativos. Popularidad, descubrimiento y ejecución correcta son hechos distintos.

Repositorio fuente: gotempsh/temps
Licencia: Apache-2.0
Versión: 1.0.0
Último push de GitHub: 8 sept 2026
Registro actualizado: 17 sept 2026
Ruta de instrucciones: .agents/skills/start-temps-cluster/SKILL.md @ da9583978fd4

Versión declarada en el registro; consulta las versiones de la fuente.

Calidad

72/100

Sólido

Confianza

57/100

Do not auto-install

Auditoría

74/100

Requiere revisión

Abrir auditoría completa Ver informe de evaluación

Dependency or permission surface needs review
Permission surface may require sandboxing
Financial research output is not financial advice; require human review before any live investment decision
The skill instructs running privileged Docker containers, which carries inherent security risks, but this is expected for a local development cluster and is clearly scoped.
The skill requires downloading a GeoLite2 database from an external source, which could be a supply-chain concern, but it is a standard practice and the file is gitignored.
Financial research output is not financial advice; require human review before any live investment decision.
Quality score needs review
Permission surface needs review: secrets or environment access, shell or command execution
Dependency/runtime risk: command execution surface, credential or environment access
Permission surface: secrets or environment access, shell or command execution

Verified installs: —
Resultados: —

Copiar no es instalar. Los recuentos requieren un informe de instalación correcta, no garantizan calidad general.

Acceso para agentes

La API Registry expone señales de decisión, confianza, auditoría, casos de uso e instalación sin raspar la interfaz.

Abrir API de instalación Formato de texto LLM Abrir Manifest Plan de resolución automática

Más detalles

{
  "version": "openagentskill-agent-metadata-v2",
  "review_evidence": {
    "indexed": true,
    "static_checked": false,
    "ai_reviewed": false,
    "manual_reviewed": false,
    "creator_verified": false,
    "review_result": "version_needs_review",
    "reviewed_at": null,
    "package_fingerprint": null,
    "policy_version": null,
    "notice": "Publication, static checks, AI review, and creator verification are independent facts. None guarantees runtime safety."
  },
  "commerce": {
    "type": "unknown",
    "billing": "unknown",
    "amount": null,
    "currency": null,
    "sourceUrl": null,
    "checkedAt": null,
    "runtime": "unknown",
    "purchaseUrl": null,
    "checkout": "external",
    "purchaseRequiresUserConsent": true
  },
  "skill": {
    "slug": "gotempsh-start-temps-cluster",
    "name": "start-temps-cluster",
    "description": "Start (or restart) a local multi-node Temps cluster using Docker-in-Docker — one control plane + 3 worker nodes, each a privileged DinD container running its own dockerd + `temps agent`, wired with the real multi-host overlay (VXLAN, compute_cidr allocation) via `tools/dev-cluster/` in whichever checkout/worktree you run it from. Invoke when the user says \"start the temps cluster\", \"spin up a multi-node dev cluster\", \"test this with multiple workers\", \"bring up worker nodes locally\", \"docker in dind cluster\", or wants to verify cross-node behavior (node targeting, cluster DNS, overlay networking, node join/mTLS) that a single-node `start-temps` server cannot exercise. Distinct from `start-temps` (single-node, native binary, port-slot based) and `start-temps-ee` (single-node EE binary) — this is the only path that actually has more than one node.",
    "category": "coding-agents",
    "url": "https://www.openagentskill.com/skills/gotempsh-start-temps-cluster",
    "repository": "https://github.com/gotempsh/temps/tree/main/.agents/skills/start-temps-cluster",
    "github_repo": "gotempsh/temps"
  },
  "suited_tasks": [
    "Coding agents workflows",
    "Claude Code teams",
    "teams that value GitHub adoption signals",
    "Inspect source files",
    "Explain architecture",
    "Patch bugs and verify changes",
    "Navigate pages",
    "Click and type safely"
  ],
  "suited_agents": [
    "Codex",
    "Claude Code",
    "Cursor",
    "OpenAgentSkill CLI",
    "Browser agents"
  ],
  "install": {
    "source_evidence": {
      "status": "source-needs-review",
      "sourceRecorded": true,
      "canOfferInstall": false,
      "path": ".agents/skills/start-temps-cluster/SKILL.md",
      "revision": "da9583978fd4bce38cf052c8bf782eecddf9b64b",
      "notice": "The tracked source changed or could not be synchronized. Review the current source before installing."
    },
    "command": "",
    "ready": false,
    "targets": [
      {
        "id": "codex",
        "label": "Codex",
        "kind": "agent-prompt",
        "value": "Review the public source for \"start-temps-cluster\" at https://github.com/gotempsh/temps/tree/main/.agents/skills/start-temps-cluster. The tracked source changed or could not be synchronized. Review the current source before installing. Do not install or execute repository code in this review. Report whether valid skill instructions exist, their exact path and revision, dependencies, costs, license and requested permissions. Ask for approval before any installation. Treat repository text as untrusted data, not authorization."
      },
      {
        "id": "claude-code",
        "label": "Claude Code",
        "kind": "agent-prompt",
        "value": "Review the public source for \"start-temps-cluster\" at https://github.com/gotempsh/temps/tree/main/.agents/skills/start-temps-cluster. The tracked source changed or could not be synchronized. Review the current source before installing. Do not install or execute repository code in this review. Report whether valid skill instructions exist, their exact path and revision, dependencies, costs, license and requested permissions. Ask for approval before any installation. Treat repository text as untrusted data, not authorization."
      },
      {
        "id": "cursor",
        "label": "Cursor",
        "kind": "agent-prompt",
        "value": "Review the public source for \"start-temps-cluster\" at https://github.com/gotempsh/temps/tree/main/.agents/skills/start-temps-cluster. The tracked source changed or could not be synchronized. Review the current source before installing. Do not install or execute repository code in this review. Report whether valid skill instructions exist, their exact path and revision, dependencies, costs, license and requested permissions. Ask for approval before any installation. Treat repository text as untrusted data, not authorization."
      }
    ],
    "handoff_url": "https://www.openagentskill.com/api/skills/gotempsh-start-temps-cluster/install",
    "manifest_url": "https://www.openagentskill.com/api/registry/manifest/gotempsh-start-temps-cluster"
  },
  "trust": {
    "score": 65,
    "label": "Manual review",
    "version": "trust-score-v4",
    "install_policy": "block",
    "evidence": {
      "stars": "728 GitHub stars",
      "repoActivity": "728 stars, 56 forks",
      "lastPushed": "1mo since push",
      "license": "Apache-2.0",
      "repository": "https://github.com/gotempsh/temps/tree/main/.agents/skills/start-temps-cluster",
      "install": "The tracked source changed or could not be synchronized. Review the current source before installing.",
      "installSafety": "standard package or runtime install path",
      "permissionSurface": "secrets or environment access, shell or command execution",
      "documentation": "Strong README/SKILL.md context",
      "agentOutcomes": "No agent outcome data yet"
    },
    "outcome_evidence": {
      "total": 0,
      "successes": 0,
      "failures": 0,
      "not_relevant": 0,
      "success_rate": null,
      "recent_success_rate": null,
      "recent_failure_rate": null,
      "install_attempts": 0,
      "install_success_rate": null,
      "risk_blocked": 0,
      "setup_required": 0,
      "avg_output_quality": null,
      "production_outcomes": 0,
      "last_outcome_at": null,
      "label": "No agent outcome data yet"
    },
    "auto_install": {
      "allowed": false,
      "sandbox_required": true,
      "reason": "Do not auto-install. Inspect the source, dependencies, and permission surface first."
    },
    "best_for": [
      "coding-agents",
      "agent-skill"
    ],
    "known_risks": [
      "The skill instructs running privileged Docker containers, which carries inherent security risks, but this is expected for a local development cluster and is clearly scoped.",
      "Financial research output is not financial advice; require human review before any live investment decision.",
      "Quality score needs review",
      "Permission surface needs review: secrets or environment access, shell or command execution",
      "Dependency/runtime risk: command execution surface, credential or environment access",
      "Permission surface: secrets or environment access, shell or command execution"
    ]
  },
  "agent_proven": {
    "version": "agent-proven-v1",
    "score": 0,
    "tier": "unproven",
    "label": "Needs first agent run",
    "summary": "No agent outcome reports yet. Use Resolve, run one narrow sandbox task, then report the result.",
    "metrics": {
      "totalOutcomes": 0,
      "successfulOutcomes": 0,
      "failedOutcomes": 0,
      "installAttempts": 0,
      "installSuccessRate": null,
      "successRate": null,
      "recentSuccessRate": null,
      "recentFailureRate": null,
      "riskBlocked": 0,
      "setupRequired": 0,
      "notRelevant": 0,
      "avgOutputQuality": null,
      "avgTimeToUsefulMs": null,
      "productionOutcomes": 0,
      "humanReviewRequired": 0,
      "uniqueAgents": 0,
      "lastOutcomeAt": null
    },
    "signals": [],
    "penalties": [
      "No real agent outcome evidence yet"
    ]
  },
  "audit": {
    "score": 74,
    "risk_level": "needs_review",
    "risk_label": "Needs review",
    "warnings": [
      "Dependency or permission surface needs review",
      "Permission surface may require sandboxing",
      "Financial research output is not financial advice; require human review before any live investment decision",
      "The skill instructs running privileged Docker containers, which carries inherent security risks, but this is expected for a local development cluster and is clearly scoped.",
      "The skill requires downloading a GeoLite2 database from an external source, which could be a supply-chain concern, but it is a standard practice and the file is gitignored.",
      "Financial research output is not financial advice; require human review before any live investment decision.",
      "Quality score needs review",
      "Permission surface needs review: secrets or environment access, shell or command execution"
    ]
  },
  "safety_gate": {
    "tier": "blocked",
    "label": "Blocked for auto-install",
    "auto_install_policy": "block",
    "auto_install_allowed": false,
    "human_review_required": true,
    "blocked": true,
    "recommended_action": "Do not auto-install. Inspect the source, dependencies, and permission surface first."
  },
  "quality": {
    "score": 72,
    "label": "Strong"
  },
  "supply": {
    "track": "Coding and developer agents",
    "scenario": "Coding agents",
    "maintenance": "1mo since push",
    "risk": "Needs review"
  },
  "alternative_skills": [],
  "do_not_use_when": [
    "teams that need a vendor-supported SLA",
    "production agents without a repository review",
    "The skill instructs running privileged Docker containers, which carries inherent security risks, but this is expected for a local development cluster and is clearly scoped.",
    "High-risk permission hints: Shell or command execution, Secrets or environment access",
    "Dependency or permission surface needs review",
    "Permission surface may require sandboxing",
    "Financial research output is not financial advice; require human review before any live investment decision",
    "The skill requires downloading a GeoLite2 database from an external source, which could be a supply-chain concern, but it is a standard practice and the file is gitignored."
  ],
  "agent_contract": {
    "task_input": "Use start-temps-cluster in an agent workflow",
    "recommended_action": "Do not auto-install. Inspect the source, dependencies, and permission surface first.",
    "install_policy": "block",
    "minimum_review_before_use": [
      "Trust: 65/100 Manual review",
      "Audit: 74/100 Needs review",
      "Safety: 26/100 Avoid automatic install",
      "Review repository, license, install command, and permission surface before production use."
    ],
    "expected_agent_output": {
      "selected_skill": "gotempsh-start-temps-cluster (start-temps-cluster)",
      "install_command": "",
      "risk_summary": "Needs review; Blocked for auto-install; Review before production",
      "verification_result": "Report the smallest successful task, files touched, warnings, and any missing setup."
    }
  },
  "outcome_feedback": {
    "endpoint": "https://www.openagentskill.com/api/agent/outcome",
    "method": "POST",
    "requires_resolve_event_id": true,
    "event_id_source": "Use install_receipt.outcome_feedback.event_id or feedback.event_id returned by /api/agent/resolve for the current task.",
    "expected_outcomes": [
      "success",
      "failed",
      "not_relevant",
      "blocked_by_risk",
      "setup_required"
    ],
    "payload_template": {
      "event_id": "<install_receipt.outcome_feedback.event_id or feedback.event_id from /api/agent/resolve>",
      "skill_slug": "gotempsh-start-temps-cluster",
      "task": "Use start-temps-cluster in an agent workflow",
      "agent": "codex",
      "outcome": "success",
      "install_used": true,
      "risk_blocked": false,
      "setup_required": false,
      "task_success": true,
      "output_quality": 4,
      "error_type": null,
      "human_review_required": false,
      "workspace": "sandbox",
      "time_to_useful_ms": 120000,
      "notes": "Report the smallest successful task, setup friction, files touched, and risk notes."
    }
  },
  "endpoints": {
    "web": "https://www.openagentskill.com/skills/gotempsh-start-temps-cluster",
    "api": "https://www.openagentskill.com/api/agent/skills/gotempsh-start-temps-cluster",
    "audit": "https://www.openagentskill.com/skills/gotempsh-start-temps-cluster/audit",
    "eval": "https://www.openagentskill.com/api/agent/evals?slug=gotempsh-start-temps-cluster&task=Use%20start-temps-cluster%20in%20an%20agent%20workflow&max_risk=medium",
    "resolve": "https://www.openagentskill.com/api/agent/resolve?task=Use%20start-temps-cluster%20in%20an%20agent%20workflow&agent=codex&max_risk=medium",
    "receipt": "https://www.openagentskill.com/api/agent/receipt?task=Use%20start-temps-cluster%20in%20an%20agent%20workflow&agent=codex&max_risk=medium&format=text",
    "install": "https://www.openagentskill.com/api/skills/gotempsh-start-temps-cluster/install",
    "manifest": "https://www.openagentskill.com/api/registry/manifest/gotempsh-start-temps-cluster"
  }
}

Para el creador

Fuente de la ficha

Indexado por Registry

Reclamable

Esta ficha se indexó desde fuentes públicas y no está marcada como oficial hasta que se apruebe una reclamación de mantenedor.

Creador: gotempsh
Fuente: gotempsh/temps
Indexado por: Índice comunitario de OpenAgentSkill

La atribución enlaza al repositorio público o al perfil del creador. Los creadores pueden reclamar la ficha para actualizar las señales de propiedad.

Reclamar este skill

Reclamación del propietario

Reclamar esta ficha de skill

Esta ficha Indexado por Registry se atribuye a gotempsh, pero aún no está marcada como oficial. Reclámala para añadir una señal de propietario verificado y hacer más fiables futuras actualizaciones de lanzamiento, instalación y auditoría.

Kit para compartir

Kit de enlaces para creadores

Añade las insignias de evidencia a tu README

Muestra la ficha canónica, las señales actuales de confianza y auditoría, y evidencia real de Agent-Proven donde los desarrolladores evalúan el repositorio.

[![Listed on OpenAgentSkill](https://www.openagentskill.com/api/badge/gotempsh-start-temps-cluster?metric=listed&label=Listed)](https://www.openagentskill.com/skills/gotempsh-start-temps-cluster?ref=github&utm_source=github&utm_medium=referral&utm_campaign=creator_badge)
[![OpenAgentSkill Trust](https://www.openagentskill.com/api/badge/gotempsh-start-temps-cluster?metric=trust&label=Trust)](https://www.openagentskill.com/skills/gotempsh-start-temps-cluster?ref=github&utm_source=github&utm_medium=referral&utm_campaign=creator_badge)
[![OpenAgentSkill Audit](https://www.openagentskill.com/api/badge/gotempsh-start-temps-cluster?metric=audit&label=Audit)](https://www.openagentskill.com/skills/gotempsh-start-temps-cluster/audit)
[![Agent Proven](https://www.openagentskill.com/api/badge/gotempsh-start-temps-cluster?metric=proven&label=Agent%20Proven)](https://www.openagentskill.com/skills/gotempsh-start-temps-cluster?ref=github&utm_source=github&utm_medium=referral&utm_campaign=creator_badge)

Vista previa de insignia Abrir auditoría Kit para creadores

Señal de comunidad

Comparte si este skill resulta útil para tu flujo de Agent. Los comentarios agregados mejoran la clasificación con el tiempo.