已收录

start-temps-cluster

价格未确认★ 728 GitHub Stars目录更新于 · 2026年9月17日agent-skill

概览

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 (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

查看来源 ↗

文件元数据

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.

查看原始文本

---
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

查看并核实来源

获取价格与运行成本

获取 Skill: 价格未确认
运行 Skill: 尚未确认运行要求，请查看来源中的 Agent、API 和服务费用。
许可证: Apache-2.0
价格未确认: 我们尚未确认此 Skill 的价格，现有来源与安装入口仍可使用。

免费获取不代表免费运行，价格标签不代表安全评级。提交价格信息 →

来源需要复核

已跟踪的来源发生变化或同步失败，请在安装前复核当前来源。

安装前审查: 避免自动安装

许可证: 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

打开完整审计

工具列表来自元数据，并非已测试的兼容性；Agent 提示词是建议的交接方式。

从一个小任务开始

1阅读来源，确认输入、预期输出、依赖和权限。
2先让 Agent 提出计划，批准环境配置和费用，再进行隔离的小规模测试。
3检查输出和变更文件，只报告实际执行结果，并保留来源版本以便复现。

请在来源中核实依赖、API 密钥及第三方费用。公开仓库不代表所有服务免费。

来源与使用须知

已收录

仓库元数据和审核信号仅供参考。受欢迎、已发现来源、成功运行是不同的事实。

来源仓库: gotempsh/temps
许可证: Apache-2.0
版本: 1.0.0
最近 GitHub 推送: 2026年9月8日
目录更新于: 2026年9月17日
技能指令路径: .agents/skills/start-temps-cluster/SKILL.md @ da9583978fd4

版本来自目录元数据，使用前请核实来源发布记录。

质量

72/100

强

信任

57/100

Do not auto-install

审计

74/100

需审查

打开完整审计查看评估报告

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: —
结果: —

复制不等于安装。安装数需有成功安装回报，不代表全面的质量保证。

Agent 接入

本页通过 Registry API 提供相同的决策、信任、审计、场景和安装信号，让 Agent 无需抓取界面即可排序。

打开安装 API LLM 文本格式打开 Manifest 自动解析计划

更多详情

{
  "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"
  }
}

创作者工具

收录来源

Registry 收录

可认领

此列表来自公开来源，维护者认领获批前不会标记为官方。

创作者: gotempsh
来源: gotempsh/temps
收录方: OpenAgentSkill 社区索引

归属链接指向公开仓库或创作者主页。创作者可认领列表以更新所有权信号。

认领此 Skill

所有者认领

认领此 Skill 页面

这条 Registry 收录列表归属于 gotempsh，但尚未标记为官方。认领后可增加已验证所有者信号，使后续发布、安装和审计更新更值得信赖。

分享工具包

创作者外链工具包

将证据徽章加入你的 README

在开发者评估仓库的位置展示规范页面、当前信任与审计信号，以及真实的 Agent 验证证据。

[![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)

预览徽章打开审计创作者工具包

社区信号

告诉我们这个 Skill 是否对你的 Agent 工作流有帮助。汇总反馈会持续改善排序。

概览