mirror of
https://github.com/Ed1s0nZ/CyberStrikeAI.git
synced 2026-10-19 22:17:42 +02:00
Sycun
cb8bc6b824
An operator running a fork has no honest way to upgrade: upgrade.sh downloads the Release tarball of one hard-coded third-party repository and rsyncs it over the tree, so "upgrade" means "overwrite yourself with somebody else's code", and the safe alternative is to pull by hand and remember the build command. internal/update drives the remote the directory already tracks: fetch, fast-forward, go build into .update-staging, atomic rename of the binary (the previous one kept as cyberstrike-ai.prev), and a .update-state.json so a rollback has a target that is not guessed at. Refusals are the point - local source edits and a diverged branch stop with the file names and commit counts in the error rather than being reset to match, and operator-owned content (roles/skills/tools/agents/data/config.yaml) is put aside before the merge and restored over it, with what was kept listed in keptContent instead of quietly dropped. Consumers: GET/POST /api/system/update* behind update:read / update:apply (mutations are process-global, so they need a global-scope session); a console page at #system-update with an apply button that names why it is blocked, a job polled from the server and a rollback control; the same three actions as -check-update / -update / -update-rollback on the binary; OpenAPI entries for all five endpoints. Permission gating no longer re-enables a control a page disabled for a reason of its own (data-state-disabled), which every state-disabled, permission-gated button in the console was subject to. upgrade.sh becomes a thin shell over the same implementation and only falls back to the tarball path for installs that are not git work trees. Docs and the zh/EN/RU dictionaries are updated. The package runs 13 tests against real temporary git repositories; the HTTP layer, RBAC and the console page each carry their own contract tests.
CyberStrikeAI Documentation
CyberStrikeAI documentation is organized by user journey. Start with deployment, then move to the topic that matches your task.
中文文档
按目标开始
- 快速体验：部署指南 → 配置参考 → 排错指南
- 生产部署：配置画像 → 安全加固 → 运维 Runbooks → 审计与监控
- 接入与自动化：API 参考 → API Recipes → MCP 联邦
- 参与开发：开发者指南 → 测试指南 → 贡献规范
核心概念与编排
功能指南
开发与发布
English Documentation
Choose a path
- Try locally: Deployment → Configuration → Troubleshooting
- Run in production: Configuration Profiles → Security Hardening → Runbooks → Audit and Monitoring
- Integrate and automate: API Reference → API Recipes → MCP Federation
- Contribute code: Developer Guide → Testing → Contributing
Concepts and orchestration
- Architecture
- Security Model
- Agents and Roles
- Skills
- Eino Multi-Agent
- Workflows
- Tool Execution Governance
- HITL Best Practices
Feature guides
Development and release
Documentation conventions
- Commands assume the repository root unless stated otherwise.
- Examples use placeholders; never commit real credentials or target systems without explicit authorization.
- Runtime behavior and configuration defaults are authoritative in
config.example.yamland the source code. If a document differs, report it as documentation drift.