🔒 Protected via Cloudflare Access

environment.audit.ready — Review

The Live Seed

Slug: environment.audit.ready Parent: none (root) Contract: "a machine-readable environment audit exists at .environment-audit.json covering identity, platform, isolation, tooling, network, and write authority"

Prompt (full)

Create a reusable machine-readable audit of the current execution environment at .environment-audit.json in the working directory. This file is the primary output of the seed. Downstream seeds should be able to inspect it instead of rerunning basic probes.

Populate the audit with verified operating conditions, not guesses:

identity: whoami, pwd, and $HOME as absolute paths

platform: uname -a, plus sw_vers on macOS or /etc/os-release on Linux

shell_mode: $SHELL and whether tty indicates interactive or non-interactive execution

isolation: classify as bare-metal, vm, container, wasm, or sandboxed using /.dockerenv, /run/.containerenv, cgroup markers for docker/lxc/kubepods, and absence of /proc for WASM-like sandboxes

tools: use command -v, not --version, to check git, docker, curl, wget, python3, node, pip, npm, brew, apt, yum, ssh, jq, tar, zip; store available and missing separately

network: probe outbound HTTP once with curl -sI --max-time 5 https://httpbin.org/status/200 or wget equivalent; classify as connected, blocked, or dns-failure

write_authority: create and delete .audit-write-test in the working directory, test whether /tmp is writable, and check sudo -n true without using sudo for anything else; classify as full-write, workspace-only, read-only, or mixed

anomalies: flag root on a non-disposable host, missing critical tools, or unexpected restrictions

Write valid JSON only. If a check fails, record the failure explicitly in the JSON instead of omitting it. Do not install packages, change configuration, escalate privileges, or make network requests beyond the single probe. If the working directory is read-only and the audit file cannot be created, report that as the blocking failure.

What's Good ✅

Rich, expert-level prompt. This isn't a thin wrapper — it encodes real sysadmin knowledge (cgroup markers, /.dockerenv, the command -v vs --version distinction, sudo -n true).
Machine-readable output. The JSON file as primary artifact means downstream seeds can programmatically consume results instead of re-probing.
Defensive design. "Record failures explicitly instead of omitting" and "if working directory is read-only, report that as the blocking failure" — handles edge cases.
No side effects. Explicitly prohibits installing packages, changing config, escalating privileges.
Contract is concrete and testable. File exists at known path, covers specified sections — boolean check.

What's Missing or Questionable ❓

1. Code Execution Capability Not Tested

The seed assumes shell access but never verifies code runtime capabilities. It checks for python3 and node binary existence via command -v, but doesn't verify the agent can actually execute code and capture output. A cloud sandbox agent using E2B or an MCP code runner would pass command -v python3 but the execution model is completely different from local shell.

Gap: Agents using cloud sandboxes (E2B, Modal, Daytona), MCP code runners, or WASM runtimes would partially fail this — the shell probes assume local execution.

2. No Language Runtime Verification

Knowing python3 exists isn't the same as knowing it works. A broken Python installation, a venv-only setup, or a restricted sandbox could have the binary but not execute. The seed should consider running python3 -c "print('ok')" and node -e "console.log('ok')" as actual execution tests, not just path checks.

3. Heavily Unix-Biased

Windows agents would fail on nearly every probe (uname -a, $SHELL, $HOME, /proc, brew, apt, yum). No mention of PowerShell, %USERPROFILE%, wsl, winget, choco. This limits the seed to Unix-like environments.

Counterpoint: Most agent execution environments are Unix-like in 2026. May be intentional scope.

4. httpbin.org as Single Network Probe

Using httpbin.org as the sole network test introduces a dependency on a third-party service. If httpbin is down, the audit reports "blocked" incorrectly. Could add a fallback (e.g., google.com, cloudflare.com/cdn-cgi/trace).

5. No GPU/Accelerator Detection

For ML-oriented agents, knowing whether GPU is available (nvidia-smi, metal, etc.) could be valuable. Not critical for a general audit, but worth noting as a potential gap for compute-heavy use cases.

6. No Memory/Disk/Resource Limits

The audit doesn't check available RAM, disk space, or whether resource limits are applied (e.g., cgroup memory limits in containers). Agents hitting OOM or disk-full errors wouldn't be caught.

7. MCP Tool Discovery Missing

Many agents in 2026 execute code through MCP servers rather than direct shell access. The audit has no concept of "what MCP tools are available?" — which is increasingly the primary execution surface.

8. Slug: `environment.audit.ready` vs Original Plan

The shell thread proposed runtime.environment.audit. The live seed uses environment.audit.ready. The .ready suffix is consistent with other roots (gmail.api.ready, local.files.ready). Good choice.

Verdict

This is a solid seed — 8/10. It's one of the richer prompts in the registry. The main gap is that it's purely a shell-based systems audit — it doesn't address the code execution verification question this thread originally planned. The assumption is "agent has shell access," which is true for local agents but misses cloud sandbox and MCP-based execution models.

Recommendation

This seed is complete for what it is. The code.execute.ready concept from this thread is a different seed — it would verify the code→runtime→output round-trip regardless of execution surface (shell, sandbox, MCP, WASM). If you still want that, it's a sibling root, not a duplicate.