mirror of
https://github.com/Akkudoktor-EOS/EOS.git
synced 2026-11-13 09:13:30 +01:00
2245976de4
The sandbox provides an isolated Docker environment for AI-assisted development (OpenCode + Claude Code + Qwen Code) against the local AkkudoktorEOS repository. The sandbox does not protect the repository from harmful changes by the agent. It limits what a misled agent can reach on the machine, but the agent can still write any change into the repository. Primary security defence is to check every change before it is run on the host. Same holds for opening a pull request or updating one. Additional changes - Reduce AGENTS.md to the project summary, baseline rules, completion checklist, and an index of the skills. - Add skills for the Python environment and REST API error responses. - Add the development guide page docs/develop/ai.md: the AI coding workflow, how agents get the project rules from AGENTS.md and ai/skills, and how to use the sandbox (start, agent logins, project commands with a virtual environment outside the workspace, running EOS and EOSdash, GitHub access, persistent data, security model). - Add a checklist for reviewing agent changes before pushing, starting with .git, which stays writable in the sandbox. - Check out all text files with LF line endings (.gitattributes), also on Windows with core.autocrlf, so the sandbox scripts run in the container and git in the container agrees with git on the host. Batch files keep CRLF. - Publish the ports of ai/compose.yaml on request (AI_SANDBOX_PORTS=1). docker compose run publishes them only with --service-ports. Off by default, so that several sandboxes can run in parallel. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
31 lines
1.0 KiB
Markdown
31 lines
1.0 KiB
Markdown
---
|
|
name: testing
|
|
description: Use when adding or updating pytest tests, fixing bugs, or changing behavior that needs test coverage.
|
|
---
|
|
|
|
# Testing
|
|
|
|
## When to use
|
|
|
|
- Any behavior change or bug fix.
|
|
|
|
## Rules
|
|
|
|
- **Prefer adding tests to existing test classes in existing test modules.**
|
|
Extend the relevant class/module rather than creating new files.
|
|
- Create a new test module only when:
|
|
- functionality is a distinct aspect that does not fit any existing module, or
|
|
- it targets a different component/test target.
|
|
- Follow existing conventions, fixtures, and markers.
|
|
- Prefer deterministic, isolated tests; mock external services/devices.
|
|
- Cover boundary conditions and error paths.
|
|
- Do not weaken tests to accommodate implementation defects.
|
|
|
|
## Verify
|
|
|
|
- Run the relevant pytest tests and checks with the project's configured
|
|
commands and environment before declaring the change complete.
|
|
- Run a full test run:
|
|
- Only one run at a time. Stop any running full test run before start of a new.
|
|
- Run the equivalent of make gen-docs before a full run.
|