mirror of
https://github.com/Ed1s0nZ/CyberStrikeAI.git
synced 2026-10-19 14:07:36 +02:00
Sycun
0d931569be
The repository's config.example.yaml ships the release version this code was cut from (upstream bumps it in the release commit: v1.7.21's config.example says v1.7.21), while the live config.yaml is operator data that no merge ever touches. So after an update the header badge - and the ?v= on every static asset - kept saying the version the installation was born with while the tree already ran newer code. An update, an adoption, or a rollback now keeps the two together: after the merge the update reads the version the new code carries (config.example.yaml) and writes it into the live config's version field - that one line, temp file plus atomic rename, everything else byte-for-byte preserved, and only when the value actually differs. The job log records the change (the page shows the step), and the state file records both numbers so a rollback puts the old version back with the old code; a number hand-edited after the update is the operator's and is left alone. The side effect worth naming: the version bump also changes the ?v= query on static assets, so a browser stops serving the pre-update JavaScript. Trees without a live config or without a shipped version are left untouched - a source checkout has nothing to sync, and nothing is ever guessed. internal/config gains the two focused helpers (FileVersion / WriteVersion, line level like the tarball upgrade path always did); tests pin the replace, the insert-when-absent, byte preservation, the mode, the malformed-value refusal, and the update/adopt/rollback/leave-alone behaviours end to end.
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.