Prep for the SDLC coding team. Adds two upstream Gitea binaries to
the clawmates-runtime image so team-scoped agents can drive
git.redclaw.dev without custom MCP code:
- tea v0.14.2 (shell CLI: clone/push/pr checkout, git remote helper)
- gitea-mcp v1.3.0 (native MCP server: list_repo_pull_requests,
create_pull_request, create_file, update_file, create_branch,
create_issue, get_file_content, etc.)
Both installed by arch (amd64 / arm64) at image build time; also
adds git to the runtime layer since it was missing (needed by tea's
shell delegates).
research_container::inherited_env now propagates GITEA_ prefixed
vars so a team container inherits GITEA_TOKEN (+ optional GITEA_HOST)
from the server env. Team-scoped daemons can then start gitea-mcp
via stdio with --token-env GITEA_TOKEN.
Followup on gw-04:
1. rebuild clawmates-runtime image against the new Dockerfile
2. add [mcp_bundles.gitea_forge] to the runtime template
3. set GITEA_TOKEN in the server compose env
Two cosmetic bugs surfaced by the successful v0.8.3 pipeline run:
1. **'produced Invalid Date'** — research_outcomes.created_at was
an OffsetDateTime serialized by time's default array format
(`[y, ordinal, hh, mm, ss, ns, tz]`), which browser's
`new Date(...)` can't parse. Add `#[serde(with =
"time::serde::rfc3339")]` matching the pattern already in
threads.rs / routine_runs.rs.
2. **Stale error text on pipeline card** — the runs stage's
`latest_error` walked every run by `created_at DESC` and
returned the first non-empty error, so a topic with an earlier
failed run + a later completed run kept displaying the old
error next to '1 completed'. Now the error only surfaces when
the MOST RECENT run itself failed. Historical failures stay in
the run count but don't leak their message.
Runtime image now installs Node 22 (nodesource) + both agent CLIs —
@anthropic-ai/claude-code and @moonshot-ai/kimi-code — so the zeroclaw
daemon can spawn `kimi -p` for the new kimi_cli provider on a Kimi
membership, parallel to `claude -p` (claude_cli). Kimi needs Node >=22.19;
the image was on Node 18.
Documents the kimi_cli worker recipe in agent.config.example.toml (the
coding endpoint is User-Agent gated → drive Kimi through its own CLI, not a
raw OpenAI-compat client) and keeps GLM via the registry family.
Deployed & verified on gw-04: coordinator (claude_cli) answers "Anthropic
built me", worker_kimi (kimi_cli) answers "I am Kimi, built by Moonshot AI"
— heterogeneous Claude + Kimi on one runtime, over /ws/chat.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Switch the per-tenant runtime to ZeroClaw's new native `claude_cli` model
provider (added in the zeroclaw repo): every agent turn spawns `claude -p`
headless, authed by CLAUDE_CODE_OAUTH_TOKEN — i.e. the Claude subscription, no
per-minute API TPM ceiling (the groq free tier 429'd multi-turn pipelines).
- Dockerfile: install the Claude Code CLI (@anthropic-ai/claude-code) into the
runtime image.
- agent.config.example.toml: role-cast on model_provider = "claude_cli.default".
NOTE: set the model via env (ZEROCLAW_providers__models__claude_cli__default__model)
not the TOML sub-table, else resolve_default_model() reads empty -> NEEDS_ONBOARDING.
- .gitignore: token.key (local Claude OAuth token, never committed).
Validated live on gw-04: a 2-node researcher->writer pipeline ran via the
deployed POST /api/topologies/run -> claude_cli -> real claude turns; 2-step
RunRecord, cost_usd 0.0 (subscription), no rate limiting.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Omar Sobh