agentleFS
NVIDIAKnown publisherNVIDIA/nvcf/deploy/stacks/stargate-dev/benchmark/AGENTS.md

nvcf / benchmark

AGENTS.md261 starsChanged 9 days agoApache-2.0View on GitHub

This is a standalone Linux Rust 2024 workspace. Spark remains the load generator. The CLI owns plans, workload generation, detached execution in a Spark Pod, acceptance, reconciliation, and offline summaries. Deployment provisioning stays in ../scripts/. Run from this directory. rust-toolchain.toml pins the toolchain: Tests use a native stand-in for kubectl. They need Linux process APIs, Bash, coreutils, setsid, flock, grep, and tar. The test support compiles the stand-in with the rustc on PATH; through rustup, that is the pinned toolchain.…

The file

We split this AGENTS.md into the rules it gives an agent

7 rules. About 1 is common, 3 are distinctive, and 3 are very specific to this project.

  • ≈1

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run from this directory. rust-toolchain.toml pins the toolchain:

    line 10
  2. Distinctive:

    Keep suite parsing and workload recipes deterministic.

    line 50
  3. Distinctive:

    Keep effective inputs immutable.

    line 52
  4. Common:

    Keep credentials out of arguments, logs, and persisted command records.

    line 59
  5. Very specific:

    Use artifact.rs for shared atomic JSON, hashing, and managed-path operations.

    line 61
  6. Very specific:

    Keep external effects in campaign.rs, cluster.rs, pod.rs, and process.rs.

    line 62
  7. Distinctive:

    Follow the existing typed plan structure.

    line 63

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

Stargate development benchmark

This is a standalone Linux Rust 2024 workspace. Spark remains the load generator. The CLI owns plans, workload generation, detached execution in a Spark Pod, acceptance, reconciliation, and offline summaries. Deployment provisioning stays in ../scripts/.

Build and test

Run from this directory. rust-toolchain.toml pins the toolchain:

cargo build --locked --release
cargo fmt --check
cargo test --locked --all-targets
cargo clippy --locked --all-targets -- -D warnings

Tests use a native stand-in for kubectl. They need Linux process APIs, Bash, coreutils, setsid, flock, grep, and tar. The test support compiles the stand-in with the rustc on PATH; through rustup, that is the pinned toolchain. Tests do not require cluster access. CLI fixtures retain their own executable copy for resume. The repository's .github/workflows/build-test.yml runs these Rust checks.

Meaningful changes must also satisfy the Stargate mock integration and performance gates. The kubectl stand-in does not satisfy the runtime integration gate. Run a campaign against real Stargate with mock inference backends and retain accepted artifacts. Measurement or workload changes need a fixed workload and independent raw measurements so changed reporting cannot hide a performance regression.

Local end-to-end check

To run the CLI against real clusters without AWS, bring up the local-a and local-b k3d regions from README.md, then run from this directory:

cargo run --locked --release -- verify --region local-a --peer-region local-b

cluster.rs embeds each environment file with include_str!. When you add a region file under ../environments/, add it there as well. The helmfile reads every file in that directory as an environment.

Contracts

  • Keep suite parsing and workload recipes deterministic. Preserve checked numeric bounds, workload ordering, and disjoint cold-capacity prompt ranges.
  • Keep effective inputs immutable. Resume must validate them and reconcile owned work before checking current controls or starting traffic.
  • A lost acknowledgement is not evidence that a launch failed. Never relaunch it.
  • Require process ownership and stop proof for cleanup. Leave an uncertain stop blocking rather than marking it complete.
  • Publish acceptance only after every required report and environment check. Preserve raw evidence; rendering reads accepted artifacts and launches no work.
  • Keep credentials out of arguments, logs, and persisted command records.

Use artifact.rs for shared atomic JSON, hashing, and managed-path operations. Keep external effects in campaign.rs, cluster.rs, pod.rs, and process.rs. Follow the existing typed plan structure. The crate forbids unsafe Rust and denies Clippy warnings.

../loadtest/suite.yaml is the canonical input. ../loadtest/reduced.yaml selects the reduced pairs. Operator commands and artifact semantics are documented in README.md. Update that section when the CLI or acceptance contract changes.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.