| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix(runner): identify builds by source commit | 24 天前 | |
refactor: consolidate plugin contributions into owning component packages | 17 天前 | |
refactor: consolidate plugin contributions into owning component packages | 17 天前 | |
refactor: consolidate plugin contributions into owning component packages | 17 天前 | |
fix(docker): derive the image's workspace manifests from the build context The dependency layer copied each workspace package.json by name so that editing application source would not invalidate the pnpm install cache. That list only stayed correct while somebody remembered to update it: packages/agent-runtime was renamed to packages/runtime-core and nothing followed, leaving docker compose build failing on a path that no longer exists. The list had also fallen behind in bulk — it named 7 of the 32 workspace projects the lockfile records, so correcting the one path would still have failed in pnpm install --frozen-lockfile. A separate stage now extracts every package.json from the build context and the builder copies that whole extract. BuildKit keys COPY --from=<stage> on the copied content, which is byte-identical while only application source changes, so the install layer keeps the cache the handwritten list was there to protect. Nothing in the repository builds the product image, which is why the drift survived; scripts/docker-build-context.test.mjs now fails an ordinary architecture:check run when a Dockerfile build-context source is missing, when the dependency layer names workspace manifests one by one again, or when a lockfile importer has lost its manifest. | 13 天前 | |
fix(docker): derive the image's workspace manifests from the build context The dependency layer copied each workspace package.json by name so that editing application source would not invalidate the pnpm install cache. That list only stayed correct while somebody remembered to update it: packages/agent-runtime was renamed to packages/runtime-core and nothing followed, leaving docker compose build failing on a path that no longer exists. The list had also fallen behind in bulk — it named 7 of the 32 workspace projects the lockfile records, so correcting the one path would still have failed in pnpm install --frozen-lockfile. A separate stage now extracts every package.json from the build context and the builder copies that whole extract. BuildKit keys COPY --from=<stage> on the copied content, which is byte-identical while only application source changes, so the install layer keeps the cache the handwritten list was there to protect. Nothing in the repository builds the product image, which is why the drift survived; scripts/docker-build-context.test.mjs now fails an ordinary architecture:check run when a Dockerfile build-context source is missing, when the dependency layer names workspace manifests one by one again, or when a lockfile importer has lost its manifest. | 13 天前 | |
chore: 对齐源端线性同步基线 | 1 个月前 | |
ci(codearts): promote verified pipeline to main | 27 天前 | |
build: 打包阶段下载模型目录快照,开箱即可用 - scripts/fetch-model-catalog.mjs 下载目录文档并写出控制面读取的同一 信封格式;--source 可从本地文档生成,供离线或可复现构建使用 - 二进制发布在架构无关阶段下载到 app/resources/model-catalog/,缺失即 构建失败;Docker 仿 micromamba 用独立 build 阶段下载并 COPY 进镜像, 运行时用 SCIENCE_AGENT_MODEL_CATALOG_PATH 指向它。断网首启因此仍有目录 - 文档本身不入库:/resources/ 加入 .gitignore;本地开发可用 pnpm catalog:fetch 预置,或直接在设置里点刷新 - E2E 栈指向 test/fixtures/model-catalog.json 这份小体量摘录,浏览器用例 不依赖网络,也不随线上目录变动而漂移 - 测试:离线生成信封、拒绝非目录文档,并断言两条打包路径都仍会下载并 校验快照 | 1 个月前 | |
fix(ci): give the release scan the same path boundaries as the payload scan The payload scan now passes and the check on the finished executable stops the build in its place, for the same reason: a builder running as root has HOME=/root, and the artifact bundles the Model Context Protocol, whose own /roots/list_changed contains that string. Anchor both ends of the match here too, which keeps a NUL-delimited, quoted or URL-embedded path caught and lets the constant and a fixture path like /workspace/root script.sh through. | 24 天前 | |
chore(rename): 库内第一方 scienceagent 自称改为 sciencediscovery 覆盖容器与沙箱路径(/opt/sciencediscovery、/run/sciencediscovery、 egress 与 python-packages 挂载)、compose 服务与镜像名、CI 镜像与缓存 目录、发布元数据(payload magic、product、单文件与 micromamba 包名)、 API health 与 MCP 客户端名、环境快照 format 标识、工作区 .sciencediscovery 目录、默认 runner/memory-graph 内部 token、文档与测试夹具。 以下改名涉及已有本地数据或历史记录,按既有兼容契约保留旧名读取并打日志: - gateway 环境标记 .sciencediscovery-bootstrap.json 仍读旧文件名,避免 升级触发一次完整重装 - 历史压缩 checkpoint 标记与 additional_kwargs 键仍识别旧拼写,避免旧 会话被重复摘要 - Web localStorage 的 token、语言、工作区布局与 CSV 图表缓存键一次性 导入旧键 - antibody skill 的 ANTIBODY_REQUIRE_SCIENCEDISCOVERY_ENV 仍回退旧变量名 保留不改:launcher 的 science-agent-data / ~/.cache/science-agent 迁移 源路径、已停用默认 token 断言,它们指代的就是旧名本身。 | 1 个月前 | |
first commit | 1 个月前 | |
first commit | 1 个月前 | |
docs(deploy): gate the sandbox on the real probe instead of a sysctl The deployment guides and the deploy skill presented kernel.apparmor_restrict_unprivileged_userns=0 as a hard prerequisite on Ubuntu 24.04+, and the skill told the assistant to stop and ask for sudo sysctl -w ...=0 whenever the value was 1. That restriction is configured per AppArmor profile, so a host can leave it at 1 and still allow the sandbox: on an Ubuntu 24.04 host with the value at 1, both the host preflight and the in-container probe pass. Following the old text means asking a user to change a kernel switch for a working environment. What actually decides is the probe the product runs — the capability detection in packages/sandbox-capability and the preflight in the shared entry point. The guides now state that, give the reproducible in-container probe command, and reduce the sysctl to the third diagnostic after the container's security_opt and the host's AppArmor profiles. The entry-point warning and SANDBOX_UNUSABLE_HINT carry the same ordering, so the runtime text no longer contradicts the documentation. The probe command keeps its outer sh -c: with bwrap as the first process of a docker compose exec session, loopback setup fails for reasons that have nothing to do with sandbox capability, and pasting the command without the wrapper reads as a false negative. The Docker section also named .sciencediscovery-data/... as the micromamba seed target. That is the host-process default; under Compose the data directory is the bind mount, so the path is now written as it exists. | 13 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 24 天前 | ||
| 17 天前 | ||
| 17 天前 | ||
| 17 天前 | ||
| 13 天前 | ||
| 13 天前 | ||
| 1 个月前 | ||
| 27 天前 | ||
| 1 个月前 | ||
| 24 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 13 天前 |