mirror of
https://github.com/Ed1s0nZ/CyberStrikeAI.git
synced 2026-09-29 20:51:53 +02:00
Runtime artifacts (agent workspaces, tool-output spill, C2 payloads, chat uploads, workflow checkpoints, diagnostic logs) previously accumulated without bound: most were only removed when a conversation or project was deleted, and tmp/c2 plus workflow checkpoints were never removed at all. Add a storage cleaner with named per-category tasks (Gitea-style), a settings page tab, and a background sweep that is off by default so upgrading never deletes existing data. Safety properties, since mis-deleting live task data costs far more than the disk saved: - dry-run is the default; a real cleanup requires dry_run=false together with confirm=true at the API layer, not just a frontend dialog - sessions active within active_grace_hours are always skipped, and a failed activity lookup skips conservatively (fail closed) - directories whose conversation/project no longer exists are reclaimed as orphans after orphan_grace_days - scanners never follow symlinks and every candidate path is confined to its category root; deletion renames to a .tmp-for-deletion marker first so a crash leaves recoverable residue instead of a half-deleted dir - storage:* permissions are admin-only; without the grantSystemRolePermissions skip the default branch would have given operators an irreversible file-deletion right Also fix two confirmed leaks: DeleteConversation left chat_uploads files on disk (their rows already vanished via ON DELETE CASCADE), and workflow checkpoints had no deletion path at all. Co-authored-by: Parallels <parallels@kali-linux-2025-2.localdomain>
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.