shipyard-cp CLI Usage

shipyard-cp の日常運用は、実行可能な shipyard CLIを主入口とする。Claude Code / Codex の .claude/commands/ は同じCLIを呼ぶ薄い運用ラッパーである。

位置づけ

主導線: shipyard run/status/pipeline/accept/integrate/publish
補助導線: Web UI
内部契約: API / OpenAPI / schema

.claude/commands/ と Skills はcurlを再実装せず、product runtimeに同梱した shipyard CLIを案内する。

最初に読む順番

README.md
run.md
status.md
必要なら pipeline.md
GLM5 を主線にするときは glm5-quickstart.md
実運用向けの詳細手順は glm5-operation-instructions.md
セキュリティ計画と受け入れ条件は security/README.md
実装や現在値を深掘りするときは RUNBOOK.md

最短手順

pnpm install
pnpm run dev

その後、Claude Code / Codex から次を入口に使う。

単発 task: run.md
状態確認: status.md
フルフロー: pipeline.md

コマンドの役割

自己改善観測とEvidence ack

shipyard improve export [--since <ISO>] [--until <ISO>] [--output <path>] [--json]
shipyard evidence ack <task-id> <evidence-id> --reviewed-by <id> [--purpose <text>]

improve exportはAuditとRetrospectiveから再構築したself-improvement/v1を出力する。prompt、raw output、token、Authorization、artifact本文は含めない。GETやexportだけではEvidenceを既読にせず、evidence ackだけを利用統計へ反映する。

`/run`

task を 1 件作成して dispatch する
plan / dev / acceptance の単発実行に向く

`/status`

task / events / runs の現在値を確認する
問題が出たときの最初の確認入口

`/pipeline`

plan -> dev -> acceptance -> integrate -> publish を順に追う
リリース前の通し確認に向く

失敗時の確認順

status で task state を見る
task events を見る
run timeline / audit summary を見る
必要なら Web UI で補助確認する
それでも足りなければ API / OpenAPI を参照する

人手確認が入る場所

acceptance が needs_manual_review または高リスク判定になった場合
publish 承認
高リスク task の手動検証ログ確認

acceptance worker の accept verdict は証跡として保存されるが、Task は accepting に留まる。チェックリストと log artifact を確認し、shipyard accept で明示的に手動 gate を完了してから accepted へ進める。

最小環境変数

ローカル起動の最低限:

.env または環境変数
Redis を使う場合は REDIS_URL

worker / 外部連携で必要:

OPENAI_API_KEY
ANTHROPIC_API_KEY
GOOGLE_API_KEY
GITHUB_TOKEN
AUTH_ENABLED, API_KEY, ADMIN_API_KEY を本番または共有環境で必ず設定

GLM / local OpenAI-compatible runtime を使う場合:

CLAUDE_WORKER_BACKEND=glm
Alibaba_CodingPlan_API_ENDPOINT を DashScope または local llama-server の /v1 へ向ける
Alibaba_CodingPlan_MODEL に server が expose する model 名を入れる
local GGUF を使うときは、先に llama-server 側で model を起動してから shipyard-cp を起動する
dispatch時はpublic logical workerのclaude_codeを指定する: shipyard run "<objective>" --repo <owner/name> --worker claude_code
CLIの--worker glm_5は後方互換のためclaude_codeへ正規化される。APIのworker_selectionではclaude_codeを使う
worker指定を省略するとplan/devは既定のcodexへ流れる。CODEX_WORKER_BACKEND=opencodeでOpenCode CLIが未導入ならspawn opencode ENOENTになるため、GLMを使う実行ではworkerを省略しない

GLM5 を主線にする場合:

docs/glm5-quickstart.md の設定をそのまま使う
local GGUF は補助用途に回し、主 worker は GLM5 に寄せる

Bounded GLM advisory bridge

外部control planeがShipyard-cp管理下のGLM credentialを複製せずに、sanitized JSON advisoryだけを要求する場合は次を使う。

pnpm exec tsx src/bounded-glm-advisory-cli.ts --preflight
pnpm exec tsx src/bounded-glm-advisory-cli.ts <request-json-path>

bridgeはexact glm-5、DashScope coding-intl /v1、temperature 0、1024 output tokensで固定し、fallback、tool execution、external deliveryを行わない。credential値、prompt、provider error本文はstdoutへ出さない。成功結果にも上流taskのpromotion・Evidence・publish authorityはない。

ライブテストや publish 系では、必要なキーだけ個別に追加する。

インフラ資材の場所

compose: infra/docker-compose.yml
production compose: infra/docker/docker-compose.yml
backend Dockerfile: infra/docker/shipyard-cp/Dockerfile
k8s/TLS: infra/kubernetes/tls

Web UI の位置づけ

Web UI は補助UI。主導線は backend / worker / CLI に置く。

task / run の閲覧
状態確認
補助的な操作

本命運用は Claude Code / Codex コマンド経由の API 操作で考える。

FilesExpand file tree

cli-usage.md

Latest commit

History