diff --git a/.agents/skills/coduels-delivery/SKILL.md b/.agents/skills/coduels-delivery/SKILL.md index fe6a3b2..5f84827 100644 --- a/.agents/skills/coduels-delivery/SKILL.md +++ b/.agents/skills/coduels-delivery/SKILL.md @@ -25,6 +25,13 @@ Read [references/pipeline-map.md](references/pipeline-map.md) before changing an 6. Keep build and deploy dependencies explicit. A deploy must not run when the image build failed, and must wait for a manual `production` environment approval after a root `CoDuels` pull request is merged. 7. Add least-privilege `permissions`, environments, concurrency, or approvals deliberately; explain rollout effects. +## Keep cross-service e2e gates coherent + +- Give each e2e scenario one local entry point and one owning pull-request workflow so a multi-service change does not start duplicate copies. +- Include every participating service, the scenario directory, the workflow itself, and related config/infrastructure paths in the workflow filters. +- Initialize required submodules recursively, use least-privilege permissions and a bounded timeout, and invoke the same command developers run locally. +- When adding a scenario, update `Backend/e2e/README.md`, the scenario README, agent verification guidance, and the delivery map together. + ## Verify safely - Parse changed YAML and run `ansible-playbook --syntax-check` where it does not require unavailable vault material. diff --git a/.agents/skills/coduels-delivery/references/pipeline-map.md b/.agents/skills/coduels-delivery/references/pipeline-map.md index f6d11db..ae4b7e9 100644 --- a/.agents/skills/coduels-delivery/references/pipeline-map.md +++ b/.agents/skills/coduels-delivery/references/pipeline-map.md @@ -22,6 +22,7 @@ - `duely_pull_request.yml`: .NET 8 Release tests and PR coverage report for `Duely/**`. - `exesh_pull_request.yml`: Go 1.24 tests plus Django dashboard system check for `Exesh/**`. - `taski_pull_request.yml`: Go 1.24 tests for Taski application changes, excluding the nested tasks submodule. +- `taski_exesh_e2e_pull_request.yml`: isolated Docker Compose Taski-Exesh A+B acceptance flow for Taski, Exesh, the scenario itself, and related root Compose/submodule configuration. It checks out recursive submodules and runs the same `e2e/taski-exesh/run.sh` entry point used locally. - `analyzer_pull_request.yml`: Python 3.10 dependency install, syntax compilation, and baseline/production model training for `Analyzer/**`. - `nginx_pull_request.yml`: validates `nginx/nginx.conf` using the production Nginx image. diff --git a/.agents/skills/coduels-execution/SKILL.md b/.agents/skills/coduels-execution/SKILL.md index 289fbb0..ac4e33d 100644 --- a/.agents/skills/coduels-execution/SKILL.md +++ b/.agents/skills/coduels-execution/SKILL.md @@ -34,6 +34,13 @@ Read [references/execution-map.md](references/execution-map.md) before changing - Do not run arbitrary or user-provided solutions outside the existing worker sandbox. - Avoid load tests by default; they consume substantial local resources. Use deterministic unit tests first. +## Maintain end-to-end coverage + +- Treat `Backend/e2e/taski-exesh` as a consumer of Taski/Exesh HTTP, message, job, artifact, configuration, task-package, Docker, and isolation contracts. +- After every Taski or Exesh change, run `Backend/e2e/taski-exesh/run.sh` after focused tests. If Docker or isolation is unavailable, report the exact verification gap. +- When Taski, Exesh, their configs, Docker/Compose/Ansible wiring, submodules, fixtures, or related infrastructure changes, review the scenario and update it in the same change if its services, configs, seeded data, requests, or assertions are stale. +- For a new cross-service scenario, follow `Backend/e2e/README.md` and add one pull-request workflow whose path filters include all participating services, the scenario, the workflow, and related config/infrastructure paths without duplicating the run for multi-service changes. + ## Verify 1. Run `go test ./...` in each changed Go module: Exesh, Taski, and/or filestorage. @@ -41,3 +48,4 @@ Read [references/execution-map.md](references/execution-map.md) before changing 3. If a contract changed, run tests in both producer and consumer and verify Duely gateways/pollers. 4. Use compose only when an integration result is necessary. Start the root Backend compose first so the external `coduels` network exists. 5. Report whether isolation was exercised; unit tests alone do not prove the host kernel/cgroup setup. +6. For Taski or Exesh changes, run the isolated Taski-Exesh e2e entry point; it owns its Compose project and does not require the regular Backend stack. diff --git a/AGENTS.md b/AGENTS.md index 1489332..8c65909 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -36,8 +36,11 @@ - Use the project skills when relevant: `$coduels-development`, `$coduels-execution`, `$coduels-anticheat`, and `$coduels-delivery`. - Start cross-service changes at the owning domain, then update transport contracts and consumers. Do not put business rules in Frontend components or HTTP handlers. +- Use Conventional Commits (`type(scope): description`) for every commit and use the same concise, imperative convention for pull-request titles. - Preserve the existing architecture: FSD boundaries in Frontend; application/domain/infrastructure direction in Duely; domain/usecase/adapter separation in Go services. - Never run user-supplied code directly on the host. Keep execution through Exesh workers and `isolate`. +- For every Taski or Exesh change, run `Backend/e2e/taski-exesh/run.sh` after focused tests. Review and update that scenario when related service contracts, Docker/Compose/Ansible configuration, task fixtures, submodules, infrastructure, or configs change. +- When adding a cross-service Backend e2e scenario, follow `Backend/e2e/README.md` and add a pull-request workflow whose paths cover all participating services, the scenario, and related configuration/infrastructure without duplicate runs. - Never decrypt, print, or replace `ansible/deploy/credentials.yml` unless the user explicitly requests credential maintenance. Never deploy, push images, or run production playbooks without explicit authorization. - Prefer focused verification. If dependencies or infrastructure are unavailable, report exactly which checks were not run. @@ -47,6 +50,7 @@ - Duely: from `Backend/Duely/`, run `dotnet test --configuration Release`. - Exesh: from `Backend/Exesh/`, run `go test ./...`. - Taski: from `Backend/Taski/`, run `go test ./...`. +- Taski-Exesh e2e: after any Taski or Exesh change, run `Backend/e2e/taski-exesh/run.sh` from the root repository. - filestorage: from `Backend/filestorage/`, run `go test ./...`. - Analyzer: use a Python 3.10 virtual environment, install `requirements.txt`, and run `python train.py --data-dir data/train` only when training/features change. Model artifacts are required before starting the API. - Docs: from `Docs/thesis/` or `Docs/slides/`, run `make` when LaTeX output is affected; this needs `latexmk`, a suitable TeX installation, Pygments, and shell escape.