chore: add scripts and configs layout

.markdownlint-cli2.yaml

@@ -4,12 +4,20 @@ config:
     allowed_elements:
       - br
       - details
+      - h3
       - img
       - p
       - summary
   MD060:
     style: compact
 overrides:
+  - filter:
+      - README.md
+    config:
+      MD029: false
+      MD036: false
+      MD041: false
+    combine: merge
   - filter:
       - CLAUDE.md
     config:

.pre-commit-config.yaml

@@ -10,7 +10,7 @@ repos:
     rev: v0.23.1
     hooks:
       - id: markdownlint-cli2
-        files: ^(?:[^/]+\.md|\.github/.*\.md|environments/[^/]+/README\.md|generators/.*\.md)$
+        files: ^(?:[^/]+\.md|\.github/.*\.md|environments/[^/]+/README\.md|(?:configs|generators|scripts)/.*\.md)$
 
   - repo: local
     hooks:

AGENTS.md

@@ -55,6 +55,8 @@ Use this guidance when contributing to the `residency-environments` repository i
 - During development, install environments (`/environments`) from the project's root directory using editable, local installs as `uv pip install -e ./environments/<env-name>`. DO NOT install from within the environment directories.
 - Every directory under `environments/` is a Verifiers v1 environment; no naming suffix is required.
 - For synthetically generated environments, the data generation and validation code lives in a matching `generators/<env-name>/` directory (see `generators/README.md`).
+- Environment-specific support code that is not part of the installable package lives in `scripts/<env-name>/` (see `scripts/README.md`). This includes sandbox image definitions and build helpers.
+- Reusable configurations for testing and evaluating an environment live in `configs/<env-name>/` (see `configs/README.md`). Never commit credentials or other secrets in configuration files.
 - Every environment must declare its full-eval convention in `pyproject.toml` under `[tool.verifiers.eval]` (`num_examples`, `rollouts_per_example`); automated eval runs read it when no sample count is given. Infinite tasksets fall back to 50 examples.
 - To check an environment implementation, use the v1 `eval` CLI. Start with a single example and two rollouts so tasksets using group rewards can compare outputs.
 
@@ -81,14 +83,20 @@ Tasksets go in *environments*.
 
 Questions/task descriptions, and possibly gold standard answers go into a HuggingFace dataset. If there's large amounts of data that the model has to work with, which takes time to setup in a sandbox, ship it in sandbox images and reference them in the Huggingface dataset for every prompt, so that each task starts with the right sandbox.
 
-If the data is generated synthetically, the scripts belong under *generators*.
+If the data is generated synthetically, the generation and validation code belongs under *generators*.
+
+Supporting development code, such as sandbox image definitions and build helpers, belongs under *scripts*. Reusable test and evaluation settings belong under *configs*.
 
 The structure is always:
 
 - environments
   - `<env-name>/<code>`
 - generators
   - `<env-name>/<code>`  # if data is synthetically generated
+- scripts
+  - `<env-name>/<code>`  # if the environment needs supporting development code
+- configs
+  - `<env-name>/<config>`  # if reusable test or evaluation configurations exist
 
 ### On tools
 

README.md

@@ -4,6 +4,8 @@ RL environments built by the Prime Intellect **RL Residency**.
 
 Each directory in `environments/` is an installable Verifiers v1 taskset.
 
+Supporting data generators, development scripts, and reusable test configurations live in `generators/`, `scripts/`, and `configs/`, respectively.
+
 ## Setup
 
 ```bash

configs/README.md

@@ -0,0 +1,5 @@
+# configs
+
+Reusable configuration files for testing and evaluating environments.
+
+Keep environment-specific configurations in `configs/<env-name>/`. Configurations should be portable, contain no credentials or other secrets, and describe the settings needed to reproduce the intended test or evaluation. Evaluation outputs do not belong here.

scripts/README.md

@@ -0,0 +1,7 @@
+# scripts
+
+Supporting code and build files for developing and operating environments.
+
+Keep environment-specific files in `scripts/<env-name>/`. This includes sandbox image definitions and build helpers, setup utilities, and other development code that is not part of the installable environment package. Synthetic data generation and validation code remains in `generators/<env-name>/`.
+
+Repository-wide utilities, such as `install.sh`, may remain directly under `scripts/`.