8ba1b0e71570aed2ef277d11763a89ffb99f1b56
Why:
svc.sh only knew two hardcoded environments (dev/prod) and always built
the current workspace, so there was no way to deploy a specific Dev- repo
commit or a Releases artifact, and no record of what was actually started.
Evidence:
- scripts/svc.sh commits dev|release lists deployable commits (release
entries annotated with version + devCommit; both mark HEAD and the
environments already running them).
- deploy --from local|dev@<sha>|release@<version|sha> materializes the
chosen source: dev commits build in an isolated worktree
(runtime/.worktrees/<sha>, submodule pins verified to land exactly),
release artifacts are sha256-verified against versions/<v>/manifest.json
(a forged manifest is refused); --pick offers an interactive numbered
choice and --dry-run prints the plan.
- Environment names are generalized (^[a-z][a-z0-9-]{0,15}$, derived port
8800-9099 on collision-free scan); each env is self-contained under
runtime/<env>/{bin,plugins,data} with svc.env (current state) and
history.jsonl (append-only deploy/start/stop events). status scans all
registered envs and history [env] [N] merges the event stream.
- Old artifacts that predate --dsn/--auth have those flags auto-omitted
(probed via serve usage); legacy svc.env files still render in status.
- Verified end to end in the task worktree: stub-binary lifecycle, a real
release@0.1.0 deploy (HTTP 200, source shown in status, commits marked),
failure paths (sha mismatch, immediate exit, non-TTY --pick).
Impact:
scripts/svc.sh users gain multi-version side-by-side environments and
rollback by redeploying an older source; existing dev/prod defaults and
safety constraints (own-pidfile-only stop, port-occupancy check) are
unchanged. Environments deployed by the previous script need one fresh
deploy before start/restart works again. Makefile gains svc-commits and
svc-history targets.
Refs: .task/feature-svc-deploy-source-registry.md(任务卡=PR 描述)
Agent-System-Dev
Agent-System 的开发集成仓(父仓):以 submodule 固定全部模块组合,承载跨仓构建、测试编排与原生(非容器)开发环境。非分发单元——发布物在 Agent-System-Releases。
组合结构
modules/core Agent-System-Core 核心契约(领域模型/事件协议/插件 API/设置与 UI 词汇)
modules/backend Agent-System-Backend 后端单二进制(内嵌前端与嵌入式 SQLite)
modules/frontend Agent-System-Frontend 前端(React 19 + Vite + TS)
modules/documents Agent-System-Documents 系统文档与过程记录
modules/ui Agent-System-UI UI 组件库(词汇渲染器/设计令牌/收件箱卡片工作区组件)
deps/development-guidelines 开发规范(gitlink 固定版本)
deps/agent-native deps/agent-squad deps/agent-intent 生态执行/编排/意图
deps/agent-command Agent-Command 命令总线基础库(spec/注册表/危险分级/审计信封)
deps/error-code-system deps/logging-system 基础设施
plugins/ 示例插件与插件开发参考(P4 起填充)
父仓 gitlink 是各组件源码版本的权威;构建、审核与发布固定提交,不执行 submodule update --remote。
常用命令
make sync # 物化全部 submodule(递归)
make build # 构建单二进制 bin/agent-system
make test # 全量测试
make dev # 开发模式说明(前后端分离热更新)
约束(全局)
- 非容器化部署:默认单二进制,必要时拆分多个原生二进制;不发布容器镜像。
- 依赖方向:frontend→core←backend;插件只依赖 core;生态仓依赖纪律沿用各仓既有约定。
- 开发规范:
deps/development-guidelines(见各仓 AGENTS.md)。
文档
设计方案:modules/documents/docs/proposals/2026-09-29-system-skeleton-design-and-plan.md(含 D1–D16 决策记录)。
Description
开发集成仓:以 submodule 固定全部模块组合,承载跨仓构建、测试编排与原生(非容器)开发环境;发布物在 Agent-System-Releases。
32 MiB
Languages
Python
56.2%
Shell
35.9%
Go
5.3%
JavaScript
1.4%
Makefile
1.1%
Other
0.1%