agentleFS
NVIDIAKnown publisherNVIDIA/nvcf/deploy/stacks/AGENTS.md

nvcf / stacks

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

This subtree owns the Helmfile stacks and their release inventories. Read INVENTORY.md before adding, removing, or changing a chart, container image, hook image, operator-created image, or downloadable stack resource. - self-managed/ owns the NVCF control-plane stack. - nvcf-compute-plane/ owns the NVCF compute-plane stack. - observability/ owns shared observability infrastructure. - Each stack owns its own release-inventory.yaml and release asset. - Each stack releases from its own release-deploy/stacks/<stack>/vX.Y branch and advances its trains independently. All three started at 1.0.0. - Each…

The file

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

12 rules. About 0 are common, 7 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Do not reference another stack's Helmfile state from an inventory config.

    line 22
  2. Distinctive:

    Keep a dependency in the stack that installs or creates it.

    line 23
  3. Distinctive:

    Follow the nearest nested AGENTS.md when it adds stack-specific guidance.

    line 24
  4. Distinctive:

    Update the owning Helmfile, chart values, or stack configuration.

    line 30
  5. Very specific:

    Update the owning stack's release-inventory.yaml.

    line 32
  6. Distinctive:

    Add registry and repository overrides for images that customers must mirror.

    line 33
  7. Very specific:

    Update the artifact classification in docs/version-catalog/main.yaml.

    line 35
  8. Very specific:

    If the change alters which trains of another stack this stack works with, whether the minimum is raised, lowered, or a train entry changes, …

    line 36
  9. Very specific:

    Run the stack tests and the inventory and documentation checks described in INVENTORY.md.

    line 41
  10. Distinctive:

    After the stack release publishes its inventory asset, update the catalog and generated manifest in a documentation sync change.

    line 43
  11. Distinctive:

    Run from the repository root unless a command says otherwise:

    line 61
  12. Very specific:

    Do not hand-edit generated blocks in docs/overview/manifest.md, docs/overview/compatibility-matrix.md, or any other generated block under …

    line 74

≈ “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

AGENTS.md - Deployment Stacks

Purpose

This subtree owns the Helmfile stacks and their release inventories. Read INVENTORY.md before adding, removing, or changing a chart, container image, hook image, operator-created image, or downloadable stack resource.

Stack Boundaries

  • self-managed/ owns the NVCF control-plane stack.
  • nvcf-compute-plane/ owns the NVCF compute-plane stack.
  • observability/ owns shared observability infrastructure.
  • Each stack owns its own release-inventory.yaml and release asset.
  • Each stack releases from its own release-deploy/stacks/<stack>/vX.Y branch and advances its trains independently. All three started at 1.0.0.
  • Each stack has its own documentation tree (docs/self-managed/, docs/compute-plane/, docs/observability/) published as a Fern tab. One docs release selector records the qualified combination. Shared pages live in docs/overview/. Follow docs/dev/docs-editions.md for docs releases.
  • Do not reference another stack's Helmfile state from an inventory config.
  • Keep a dependency in the stack that installs or creates it.
  • Follow the nearest nested AGENTS.md when it adds stack-specific guidance.

Dependency Changes

For every dependency change:

  1. Update the owning Helmfile, chart values, or stack configuration.
  2. Give an optional release an explicit condition and inventory render profile.
  3. Update the owning stack's release-inventory.yaml.
  4. Add registry and repository overrides for images that customers must mirror.
  5. Record images that do not appear in rendered Kubernetes image fields.
  6. Update the artifact classification in docs/version-catalog/main.yaml.
  7. If the change alters which trains of another stack this stack works with, whether the minimum is raised, lowered, or a train entry changes, update the compatibility: block in docs/version-catalog/main.yaml in the same change (for example compute-plane: "1.2+"). It generates docs/overview/compatibility-matrix.md.
  8. Run the stack tests and the inventory and documentation checks described in INVENTORY.md.
  9. After the stack release publishes its inventory asset, update the catalog and generated manifest in a documentation sync change.

A dependency is not fully distributed when the released inventory or generated manifest omits one of its charts, images, or downloadable resources.

Required and Optional Artifacts

  • Mark an artifact required when the default stack installation needs it to become ready or perform its baseline function.
  • Mark an artifact optional when only an optional feature, provider, add-on, or non-default mode needs it.
  • An artifact used only by an optional release remains optional for the stack.
  • List a customer-provided prerequisite as a prerequisite, not as a distributed stack artifact.

Validation

Run from the repository root unless a command says otherwise:

make -C deploy/stacks/self-managed test
make -C deploy/stacks/nvcf-compute-plane test-local
make -C deploy/stacks/observability test
go test -C tools/docs-version-sync ./...
go run -C tools/docs-version-sync . --target main
./tools/ci/check-doc-version-sync
./tools/ci/check-docs
git diff --check

Do not hand-edit generated blocks in docs/overview/manifest.md, docs/overview/compatibility-matrix.md, or any other generated block under the product docs trees. The CI check against the latest released inventory is warn-only for now. Generated-document consistency remains blocking. Treat a release-drift warning as follow-up work and keep the local checks clean for a dependency change.

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.