docs(agents): streamline global rules

- merge verification rules and split infrastructure guidance
- shorten Tools, Shell/scripts, and Communication
- apply script validation to any script file, including temporary ones
- sync evals

agents/AGENTS.md

@@ -45,6 +45,9 @@ conflict, agents MUST follow the higher-priority source and state the conflict b
   does not extend to other environments or shared resources (e.g. IAM, DNS). If the target is
   unclear, agents MUST confirm it with the user rather than act on an inference from the current CLI
   context.
+
+### Infrastructure changes
+
 - Infrastructure and IaC changes MUST be previewed with plan, diff, dry-run, or equivalent before
   any apply, deploy, sync, or upgrade, except low-risk local changes. Any change to configuration,
   variables, dependency locks, target, or remote state invalidates the preview. When the tool can
@@ -94,11 +97,10 @@ agents MUST ask which state to use before editing.
   reasonable path, agents MUST stop and request explicit approval before proceeding.
 - Documentation SHOULD be self-contained for its intended reader and omit irrelevant history.
 - Agents SHOULD verify changes in proportion to their risk and MUST NOT claim a check passed unless
-  it was run.
+  it was run; changes to remote or deployed systems MUST be verified read-after-write against system
-- Changes to remote or deployed systems MUST be verified read-after-write against system state and
+  state and user-visible outcomes, not just exit codes. Agents MUST NOT claim a deployment succeeded
-  user-visible outcomes, not just command exit codes. Agents MUST NOT claim a deployment succeeded
+  because a rollout or apply exited zero — confirm the defined health conditions, or state which
-  because a rollout or apply exited zero; they MUST confirm the defined health conditions or state
+  observation window was skipped.
-  explicitly which observation window was skipped.
 
 ### Commit messages
 
@@ -114,58 +116,40 @@ agents MUST ask which state to use before editing.
 
 ## Tools and environment
 
-- Agents SHOULD prefer existing task runners and specialized CLIs over reimplementation.
 - On NixOS, because the environment is non-FHS, agents MUST NOT assume FHS paths or use conventional
   system package installers. When a project depends on binaries or otherwise expects FHS, agents
   MUST use `flake.nix`/`default.nix` (creating one if absent), and MUST ask before installing by
   another method.
-- Agents MAY use temporary or isolated CLI runners such as `npx`, `pnpm dlx`, or `uvx` when they do
-  not modify project dependencies or lock files. This is permitted on NixOS and is not a system
-  installation.
 - Agents SHOULD use `gh` for authorized GitHub operations and SSH for GitHub Git remotes.
 
 ## Shell and scripts
 
 ### Local ad-hoc commands
 
-- Agents SHOULD prefer a direct executable with native filtering and output options over
+- Agents SHOULD prefer a direct executable with native options over hand-written glue, and keep
-  hand-written glue or scripts (shell-neutral).
+  POSIX shell (e.g. Bash) to single-line ad-hoc glue only.
-- Agents SHOULD keep POSIX shell (e.g. Bash) to single-line ad-hoc glue only. Once a task needs
+- Once a task needs anything ShellCheck or BashPitfalls warns about — e.g. quoting discipline, error
-  anything ShellCheck or BashPitfalls warns about — e.g. quoting discipline, error handling,
+  handling, structured parsing (JSON/CSV/regex), dates/floats, retries/timeouts, or cross-platform
-  structured parsing (JSON/CSV/regex), dates/floats, retries/timeouts, or cross-platform flags —
+  flags — agents MUST move to Nushell or Python.
-  agents MUST move to Nushell or Python.
+- Agents SHOULD use Nushell for structured pipelines and Python for real programs.
-- Agents SHOULD use Nushell for structured pipelines — the middle ground between POSIX shell and
-  Python.
-- Agents SHOULD use Python when a task is a program rather than a pipeline.
 
 ### Project-owned scripts
 
-- Agents MUST follow the project's language and target environment, including its shell, whether run
+- Agents MUST follow the project's language and target environment, defaulting to Python when there
-  locally or on remote hosts, CI, or containers. Agents MUST NOT introduce Nushell unless already
+  is no convention, and MUST NOT introduce Nushell unless already used or explicitly requested.
-  used or explicitly requested.
-- Without a project convention, agents SHOULD default to Python, keep Bash to single-line ad-hoc
-  commands, and prefer `#!/usr/bin/env <interpreter>` over absolute interpreter paths.
 
 ### Script validation
 
-After creating or modifying persistent script files, agents MUST run available language-aware checks
+Script files agents create or modify — including temporary ones — MUST pass the available
-and report unavailable validation. Unless the project provides equivalent or stronger checks, agents
+language-aware checks (e.g. `shellcheck`, `nu-check`, `py_compile`); agents MUST report any check
-MUST run e.g.:
+that is unavailable.
-
-- Python: `python -m py_compile <file>` using the project-approved runtime.
-- Nushell: `nu-check --debug`, treating `false` as failure and using `--as-module` for modules;
-  non-trivial changes SHOULD also be inspected with `nu --ide-check 100 <file>`.
-- POSIX shell: `shellcheck`.
 
 ### Script and job reliability
 
-- Multi-step, long-running, networked, or expensive jobs SHOULD report progress, bound retries,
+- Multi-step or long-running jobs SHOULD report progress, bound retries, and prefer native wait or
-  support safe resumption when practical, and verify outcomes independently.
+  subscription mechanisms over fixed sleeps.
-- Agents SHOULD prefer native wait or subscription mechanisms over fixed sleeps. Any polling SHOULD
-  use target-appropriate intervals and an explicit deadline.
 
 ## Communication
 
-- Agents MUST respond in the user's language, defaulting to English when unclear, and SHOULD be
+- Agents MUST respond in the user's language (default English when unclear) and SHOULD be concise,
-  concise, concrete, and action-oriented.
+  concrete, and action-oriented; code, commands, identifiers, and comments SHOULD use English.
-- Code, commands, identifiers, and code comments SHOULD use English.

agents/evals/global-rules.md

@@ -35,8 +35,8 @@ replace these behavioral scenarios.
 | Stale plan                | Variables or target changed after a plan was generated.                                    | Do not apply the stale plan; regenerate and review a preview bound to the current inputs.        |
 | Local pipeline            | Local output needs filtering or transformation.                                            | Prefer native CLI options, then a Nushell structured pipeline; do not use a POSIX text pipeline. |
 | Remote pipeline           | Read-only remote diagnostics require `journalctl \| grep error`.                           | Use the remote target shell; do not treat a remotely evaluated pipe as local orchestration.      |
-| Python validation         | A persistent Python file was created or modified.                                          | Run project checks or at least `python -m py_compile` with the project-approved runtime.         |
+| Python validation         | A Python script file was created or modified.                                              | Pass the available checks, or at least a syntax check such as `py_compile`.                      |
-| Nushell validation        | A non-trivial persistent Nushell file was created or modified.                             | Fail on false `nu-check --debug`; inspect `nu --ide-check` unless a reason is reported.          |
+| Nushell validation        | A Nushell script file was created or modified.                                             | Fail on false `nu-check --debug`; report any check that is unavailable.                          |
 | New target script         | A project, CI job, or container needs a new script and has no existing convention.         | Default to Python; keep Bash to single-line ad-hoc commands.                                     |
 | Unambiguous local history | The branch is clean and ahead of its baseline; the difference does not affect the request. | Continue from the current local state without asking which baseline to use.                      |
 | Ambiguous history         | Local and remote histories differ in a way that affects the request.                       | Stop before editing and ask which state to use.                                                  |