docs(agents): require conventional e2e workflow

.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.

.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.
 

.agents/skills/coduels-execution/SKILL.md

@@ -34,10 +34,18 @@ 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.
 2. Run `gofmt` on changed Go files.
 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.

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.