Skip to content

docs: Codify recurring PR review feedback into AGENTS.md - #8198

Open
mvadari wants to merge 10 commits into
developfrom
mvadari/codify-agents-md
Open

mvadari wants to merge 10 commits into
developfrom
mvadari/codify-agents-md

Conversation

@mvadari

@mvadari mvadari commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

High Level Overview of Change

Mines the last 6 months of merged-PR human review comments (bots excluded) for conventions that recur across multiple PRs/reviewers but aren't already documented in CONTRIBUTING.md/docs/CodingStyle.md, and folds them into AGENTS.md files so AI coding agents pick them up automatically. Each rule lives in the narrowest directory it applies to (not root), so agents working elsewhere don't load irrelevant context.

Context of Change

  • Root AGENTS.md: Doxygen comments on new public functions/methods (genuinely repo-wide); trimmed the Architecture section's amendment mention to a pointer, since the detail now lives in tx/AGENTS.md.
  • src/libxrpl/tx/AGENTS.md: a precise "when is an amendment required" test and a design-considerations checklist (sourced from an internal amendment-writer doc); new/deleted invariant checks must be amendment-gated (consensus-safety, since an un-gated invariant risks validators disagreeing on a transaction's result).
  • src/libxrpl/tx/transactors/AGENTS.md (new): amendment-gating code shape (single enabled/disabled block, not scattered checks), per-amendment flag naming (fix340Enabled not fixEnabled), UNREACHABLE/LCOV_EXCL_START/STOP pairing, pseudo-accounts (Vault/LoanBroker/AMM) being exempt from requireAuth/freeze checks as a class, and preferring one object-level invariant over duplicating a delta check per transactor. All evidenced in vault/lending transactor PR reviews specifically, so scoped here rather than the parent tx/AGENTS.md.
  • src/libxrpl/ledger/helpers/AGENTS.md (new): helpers should assert the SLE type they're handed rather than inventing a new error-handling idiom.
  • src/xrpld/rpc/AGENTS.md: the API-CHANGELOG.md requirement lives here (its natural home) rather than at root, since it's the primary place API-visible changes happen; tx/AGENTS.md has a one-line pointer to it for the signing-behavior case.
  • src/test/AGENTS.md (new): shared test setup/helpers belong in jtx/, not copy-pasted across test files.
  • Thin pointer AGENTS.md files (with CLAUDE.md symlinks, matching the existing convention) for subsystems that already have a substantial README.md but no AGENTS.mdoverlay/, app/ledger/, shamap/, peerfinder/, nodestore/, app/consensus/, include/xrpl/consensus/, and rpc/. Agent tooling auto-loads AGENTS.md when working in a directory but not README.md, so those existing design docs were otherwise easy for an agent to miss.

Every added rule cites the specific PR(s) where it recurred; I cross-checked each against CONTRIBUTING.md/docs/CodingStyle.md first to avoid duplicating what's already documented there.

API Impact

  • Public API: New feature (new methods and/or new fields)
  • Public API: Breaking change (in general, breaking changes should only impact the next api_version)
  • libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
  • Peer protocol change (must be backward compatible or bump the peer protocol version)

Mined 6 months of merged PR review comments (human reviewers only) for
conventions that recur across multiple PRs/reviewers but aren't already
documented in CONTRIBUTING.md/CodingStyle.md, and folded them in:

- Doxygen comments expected on new public functions/methods.
- API-CHANGELOG.md requirement is repo-wide, not RPC-directory-scoped.
- Shared test setup belongs in jtx/, not copy-pasted across test files.
- Amendment requirement test and a design-considerations checklist,
  sourced from the internal "Considerations for Future Amendments" doc.
- Amendment gating shape (single enabled/disabled block), per-amendment
  flag naming, and UNREACHABLE/LCOV_EXCL pairing, all recurring asks in
  tx/vault/invariant PR reviews.
…and READMEs

Round 2 of PR-review mining: found two subsystem-specific, unrecorded
conventions (pseudo-account auth/freeze exemption in vault/lending
transactors; SLE-type assertion in ledger helpers) that warrant their
own nested AGENTS.md rather than more root-level bullets.

Also added thin AGENTS.md pointer files (with CLAUDE.md symlinks,
matching the existing convention) for subsystems that already have a
substantial README.md but no AGENTS.md — agent tooling auto-loads
AGENTS.md when working in a directory but not README.md, so those
conventions were otherwise invisible to an agent that didn't think to
look.

@xrplf-ai-reviewer xrplf-ai-reviewer Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doc-only change adding/updating AGENTS.md (and matching CLAUDE.md symlinks) files. Checked all new relative links (to repo-level AGENTS.md, README.md, docs/consensus.md) against each file's actual directory depth and they all resolve correctly. Content additions (jtx test-setup rule, Doxygen requirement, repo-wide API-CHANGELOG rule, amendment-gating guidance, pseudo-account exemption note, SLE-helper assertion note) are consistent with the stated conventions and don't contradict existing docs. No correctness, security, or wiring issues found in the changed lines.

@codecov

codecov Bot commented Sep 8, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@xrplf-ai-reviewer xrplf-ai-reviewer Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs-only change adding/updating AGENTS.md files across the repo to codify recurring PR review feedback for AI coding agents. Checked all new relative markdown links (root AGENTS.md, README.md, docs/consensus.md) against each file's actual directory depth — all path traversals (../../../, ../../../../, etc.) resolve correctly. The new API-Changelog anchor reference (AGENTS.md#api-changelog) matches the corresponding heading. CLAUDE.md symlinks are consistent with the existing repo convention. No correctness, security, or process-config issues found; nothing in this diff touches behavior-affecting code or repo-wide gating/config files.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Two newly added guidance statements are inconsistent with established code patterns/behavior (pseudo-account freeze/deep-freeze handling and std::expected/std::unexpected usage), which could mislead future changes.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates and expands AGENTS.md guidance across the repo to capture recurring review expectations (especially around API changelog discipline, amendments, and subsystem design pointers) so AI coding agents automatically load the right conventions when working in those directories.

Changes:

  • Promotes repo-wide API changelog + Doxygen expectations into the root AGENTS.md and clarifies how RPC changes fit that rule.
  • Expands src/libxrpl/tx/AGENTS.md with amendment “when required” guidance plus concrete gating conventions.
  • Adds “thin pointer” AGENTS.md files in several subsystems to direct agents to existing design docs (README.md, docs/consensus.md).
File summaries
File Description
AGENTS.md Adds shared-test placement guidance, clarifies Doxygen expectations, and adds an explicit repo-wide API changelog rule.
src/xrpld/rpc/AGENTS.md Clarifies that RPC behavior changes fall under the repo-wide API changelog requirement and points to the RPC README.
src/xrpld/peerfinder/AGENTS.md Adds a pointer to repo-level guidance and the peerfinder design README.
src/xrpld/overlay/AGENTS.md Adds a pointer to repo-level guidance and overlay design README.
src/xrpld/app/ledger/AGENTS.md Adds a pointer to repo-level guidance and ledger subsystem README.
src/xrpld/app/consensus/AGENTS.md Adds pointers to repo-level guidance, local README, and docs/consensus.md.
include/xrpl/shamap/AGENTS.md Adds a pointer to repo-level guidance and SHAMap README.
include/xrpl/nodestore/AGENTS.md Adds a pointer to repo-level guidance and NodeStore README.
include/xrpl/consensus/AGENTS.md Adds pointers to repo-level guidance, local README, and docs/consensus.md.
src/libxrpl/tx/AGENTS.md Adds detailed amendment criteria and conventions for structuring amendment-gated code paths.
src/libxrpl/tx/transactors/AGENTS.md Adds transactor-specific guidance about pseudo-accounts and preferring invariants over duplicated per-transactor checks.
src/libxrpl/ledger/helpers/AGENTS.md Adds guidance on asserting SLE type/non-nullness and recommended error-handling style for helpers.
Review details
  • Files reviewed: 21/21 changed files
  • Comments generated: 2
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread src/libxrpl/ledger/helpers/AGENTS.md Outdated

See the repo-level [AGENTS.md](../../../../AGENTS.md) for general guidance.

A helper that takes an `SLE`/`std::shared_ptr<SLE const>` should `XRPL_ASSERT` that it's non-null and of the expected ledger-entry type at entry, and keep a real runtime check/error-return alongside the assert (asserts compile out in release builds). Don't invent a new error-handling idiom for this (e.g. `std::unexpected`) — return the existing `tec`/`ter`/`tef` code used elsewhere in the codebase.
Comment thread src/libxrpl/tx/transactors/AGENTS.md Outdated
Comment thread src/xrpld/overlay/CLAUDE.md
Comment thread src/xrpld/peerfinder/AGENTS.md Outdated
@@ -0,0 +1,3 @@
# AGENTS.md — peerfinder

See the repo-level [AGENTS.md](../../../AGENTS.md) for general guidance and [README.md](./README.md) for the peer-discovery design.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please explain why do we need two almost identical files in every directory? I don't really know best practice here, but it looks like duplication

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It just points to the README in each of these subfolders, since the README already covers all the data needed and there's no need for separate agent-specific documentation. This seems in line with your earlier comment suggesting that we have contributor-focused documentation instead of just AI-focused documentation.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The project-map.md file basically describes and links to appropriate source for everything. We don't really need to put these files in each sub-dir.

Comment thread src/libxrpl/tx/AGENTS.md
See the repo-level [AGENTS.md](../../../AGENTS.md) for general build/test/style guidance.

Any change to transaction-processing behavior must be gated behind an amendment. New amendments (and fixes, i.e. `fix*` amendments) are added to [`include/xrpl/protocol/detail/features.macro`](../../../include/xrpl/protocol/detail/features.macro), as an `XRPL_FEATURE(...)` or `XRPL_FIX(...)` entry added to the top of the list (the list is kept in reverse chronological order). Once the pre-amendment code path for a retired amendment is removed, move its entry to `XRPL_RETIRE_FEATURE(...)`/`XRPL_RETIRE_FIX(...)` instead of deleting it.
## When an amendment is required

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe instead we should have a contributing guidelines doc? Such rules may be useful not only for agents but for new contributors

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No objections here, we can make it a readme that the agents.md points to like what other files in this PR do. That should be a separate PR though, because I'd like this in first. Fine with this info migrating later, but I'd rather not have perfect be the enemy of good here.

Comment thread src/libxrpl/tx/AGENTS.md Outdated

When a file or function checks more than one amendment, name local enablement booleans per-amendment (e.g. `fix340Enabled` for `fixCleanup3_4_0`), not a generic `fixEnabled` — it becomes ambiguous once a second amendment is checked in the same scope.

Only use `UNREACHABLE` for genuinely impossible paths, not to avoid writing a test for one that's reachable but rare. When a branch marked `UNREACHABLE` is excluded from coverage, wrap it in `LCOV_EXCL_START`/`LCOV_EXCL_STOP`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This rule is not related to amendment

Team decided AGENTS.md content should live in the narrowest folder it
applies to, rather than the broadest, to keep context small for agents
working elsewhere in the repo. Restructure round 1/2's additions
accordingly, with no change in the rules themselves:

- Move the repo-wide API-CHANGELOG.md rule out of root AGENTS.md and
  into rpc/AGENTS.md (its natural home), with a one-line pointer left
  in tx/AGENTS.md for the signing-behavior case.
- Move the amendment-gating *code style* rules (single enabled/disabled
  block, per-amendment flag naming, UNREACHABLE/LCOV_EXCL pairing) from
  tx/AGENTS.md down into transactors/AGENTS.md, since all cited PR
  evidence was in transactor code, not tx/-level files.
- Move the "shared test setup belongs in jtx/" rule out of root
  AGENTS.md into a new src/test/AGENTS.md (+ CLAUDE.md symlink).
- Trim the now-duplicated amendment sentence out of root's Architecture
  bullet in favor of a pointer to tx/AGENTS.md.

@xrplf-ai-reviewer xrplf-ai-reviewer Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a documentation-only change adding/expanding AGENTS.md files (plus CLAUDE.md symlinks) across the repo. I checked every new/modified relative link (root AGENTS.md, docs/consensus.md, README.md pointers, cross-references between tx/AGENTS.md, transactors/AGENTS.md, and rpc/AGENTS.md) and all resolve to the correct depth given each file's location. The symlinks are all simple 'AGENTS.md' relative symlinks matching the stated existing convention, and each target AGENTS.md exists alongside it. No code, security, or correctness issues apply since no executable code is touched; content changes are guidance text sourced from cited PR review history per the description, which is outside the scope of an automated correctness review. No issues found worth flagging.

- Build section now recommends the Nix devshell rather than requiring
  it; contributors can use their own toolchain/build flow.
- Move the directory-by-directory architecture map out of AGENTS.md
  into a new top-level ARCHITECTURE.md, with a pointer left behind.
- Add a short note asking contributors to keep AGENTS.md/README/
  ARCHITECTURE.md files current when they change what those docs cover.
- ledger/helpers/AGENTS.md also needs the amendment-gating shape,
  per-amendment flag naming, and UNREACHABLE/LCOV_EXCL pairing notes
  (previously only in transactors/AGENTS.md) — the vault/lending
  helper files these were evidenced on live in ledger/helpers/, not
  tx/transactors/.

@xrplf-ai-reviewer xrplf-ai-reviewer Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a documentation-only MR adding/editing AGENTS.md files. All relative markdown links check out (correct ../ depth for every new/modified file), and the added guidance is generally consistent with the MR's stated rationale. One notable inconsistency: the amendment-gating and UNREACHABLE/LCOV guidance is duplicated verbatim in both the new ledger/helpers/AGENTS.md and tx/transactors/AGENTS.md, which cuts against the MR's own stated principle that each rule should live in the narrowest directory it applies to.

mvadari and others added 2 commits September 9, 2026 13:58
… section

- ledger/helpers/AGENTS.md: std::expected<..., TER>/std::unexpected(tec*)
  is already the established idiom here (confirmed in AMMHelpers.cpp,
  CredentialHelpers.cpp), not something to avoid; reword so the rule
  doesn't read as discouraging it.
- transactors/AGENTS.md: the UNREACHABLE/LCOV_EXCL coverage rule isn't
  amendment-specific, so give it its own heading instead of nesting it
  under "Gating amendment-dependent code".
- Root AGENTS.md: comments should explain why, not what/how, since the
  code already shows that.
- Drop the pseudo-account exemption rule from transactors/AGENTS.md —
  needs refining before it's codified.

Addresses PR review comments:
#8198 (comment)
#8198 (comment)

@xrplf-ai-reviewer xrplf-ai-reviewer Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation-only change (AGENTS.md/ARCHITECTURE.md additions). Cross-file links and relative paths all resolve correctly, and the new content generally matches the stated goal of scoping rules to the narrowest applicable directory. Found two places where the actual file content doesn't match the MR's own description/design intent: ledger/helpers/AGENTS.md duplicates transactor-specific amendment-gating/UNREACHABLE guidance that the MR description says is scoped to transactors/ only, and transactors/AGENTS.md is missing the pseudo-account (Vault/LoanBroker/AMM) requireAuth/freeze exemption rule that the MR description claims was added there.

@godexsoft godexsoft left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine to me for the first version. We can always improve later 👍

Comment thread include/xrpl/consensus/AGENTS.md Outdated
Comment thread ARCHITECTURE.md
@@ -0,0 +1,9 @@
# Architecture

@pratikmankawde pratikmankawde Sep 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to go in project-map.md file. Attaching mine:
project-map.md

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

project-map.md file then links to other files like docs/consensus.md to deeper details. None of those files are actually loaded in context at startup. They are pulled as required. I have files containing details on architecture, components, features, etc.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like primarily a disagreement on file name, and seems to disagree with your desire on keeping context small (i.e. IMO this project map file should be split up into smaller files, one of them being this ARCHITECTURE.md). Can you clarify what you're looking for?

@pratikmankawde pratikmankawde Sep 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not the name really. Since we will need to refer it in some repo level CLAUDE.md/AGENTS.md file, and we can use any name there.

It's about the purpose. So the project-map is supposed to contain short idea about how the project is structured. It is supposed to map the project tree itself. It is the go to place for AI Agent to find things. Hence the name. A map basically. It stays under 200 lines. It should always remain in context, so that the agent can look at the map and navigate. It should need to be read again and again. If we break this down into individual files, the agent will definitely miss (intentionally skip in most cases) reading connected/related pieces together.

The architecture.md contains the architecture of the software itself. Like the building blocks and how they interact. I am sharing my achitecture.md file here.
architecture.md

I had this linked into the project-map file but I removed it before sharing that file, it it had local paths and to avoid confusion.

@pratikmankawde pratikmankawde Sep 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

project-map file basically removes the need of individual indirection files in each sub-folder. I tried to find the blog post from Anthropic or OpenAI, where they suggest the usecase and benefits of project-map.md file and they use the same name. But couldn't find it now. Maybe they removed it after their source leak was attributed to the leaked project-map file XD
Not attached to the name though. It is just that architecture.md should define software, and project-map should define the project arrangement.

@mvadari mvadari Sep 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you open a separate PR that adds those? I'd like to get the benefits from this PR in first, and these changes would be a big scope expansion (plus, I think it makes more sense for that PR to come from you).

@pratikmankawde pratikmankawde Sep 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But that new PR will anyway remove all the agents.md files from all the sub dirs!

For this PR, I would suggest we put the project-map.md file in .agents/ folder. That's it. Remove everything else.

It already points to other important files. It points to Contributing.md file as well, which contains code guidelines. It also points to other coding and general guidelines files.

Any developer can just point their agents.md/claude.md to this project-map.md.
In next iterations, we can include more specific files. All of them will go in .agents/ folder.

If we do it any other way, we just add redundant linked files all over the repo. This way we get what we need, a repo level+ repo. specific common info. inside the repo. itself, without breaking anyone's personal setup. Since that goes through repo level AGENTS.md/CLAUDE.md files, which we really should not touch.

@kuznetsss What do you think?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sub-dir AGENTS.md files are all different than what's contained in the project-map - the project-map.md file doesn't contain information that is helpful for an agent wrt actually doing the work, it only points it to the right section of the code to get started.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly what the project-map.md file is for. 'information helpful for actually doing the work' is something, we want the agent to read only when it is needed. We don't want to pollute the context with info about each module per say.
A-few lines in info about a feature is not going to help the agent much anyway. It will read the code and docs. And its better that it reads it on need basis. But we can anyway put such info at one place, like in architecture.md, workflow.md, feature.md file. That way the agent has info about the subject + dependencies.

@kuznetsss kuznetsss Sep 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should have a good default for everyone with a way to opt out. Turns out claude code has a way to exclude any file form automatic loading: https://code.claude.com/docs/en/memory#exclude-specific-claude-md-files. Maybe worth adding the link to CONTRIBUTING.md.

Because there is a way to opt out, I'm ok to merge this PR as it is and improve the structure in the next iteration.

My suggestion would be to put all the rules into a doc file per subdirectory, something like docs/conventions/dirs/subdirectory.md. And reference such file in subdirectory's AGENTS.md.
Such structure would help to avoid duplications between include and src subdirectories, keep all the rules in one place and store rules as docs, so humans could also read them.

Comment thread AGENTS.md
@@ -4,13 +4,13 @@ This file provides guidance to AI coding agents (Claude Code, and other AGENTS.m

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of duplicating content here, we should just point to the relevant files. BUILD.md, CONTRIBUTING.md, others: rippled/docs/*.md. This doesn't need to sit it context. This should only be fetched when required.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any specific places I should point to? It's already pointing to those files when one exists and not duplicating existing documentation.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pointing will be per-heading:
Build: Build.md
Coding Guidlines: docs/CodingStyle.md
Please check the project-map.md file I attached in another comment.

Comment thread AGENTS.md Outdated
…tion

- The harness auto-loads every ancestor AGENTS.md (including root), so
  a nested file telling an agent to "see the repo-level AGENTS.md" is
  pure overhead — it can trigger a re-load/duplication-check/discard
  cycle, and some models just retain the duplicate content in context.
  Drop that pointer from every nested AGENTS.md; keep pointers to
  things that are NOT auto-loaded (README.md, docs/consensus.md,
  non-ancestor AGENTS.md like tx/ -> rpc/).
- Root AGENTS.md's Build section is now a short index pointer to
  BUILD.md and docs/build/nix.md instead of restating Nix setup steps,
  per review feedback that AGENTS.md should mostly index other docs
  rather than duplicate them.

Addresses PR review comments:
#8198 (comment)
#8198 (comment)

@xrplf-ai-reviewer xrplf-ai-reviewer Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation-only PR (AGENTS.md conventions). The overall structure is sound and matches the stated "narrowest directory" design principle, with one exception: the new src/libxrpl/ledger/helpers/AGENTS.md duplicates the amendment-gating and UNREACHABLE/coverage guidance verbatim from src/libxrpl/tx/transactors/AGENTS.md, even though the PR description explicitly scopes that guidance to transactors (evidenced from vault/lending transactor PR reviews) and describes the helpers file as being only about SLE-type assertions.

@@ -0,0 +1,7 @@
# AGENTS.md — ledger/helpers

A helper that takes an `SLE`/`std::shared_ptr<SLE const>` should `XRPL_ASSERT` that it's non-null and of the expected ledger-entry type at entry, and keep a real runtime check/error-return alongside the assert (asserts compile out in release builds) — the established idiom in this directory is `std::expected<..., TER>`, returning `std::unexpected(tec*)` on failure. Don't invent a new error-handling idiom for this.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we limit this to helpers where non-nullness and the entry type are actual preconditions? isPseudoAccount, for example, explicitly accepts null pointers and non-account entries and returns false. Adding the assertions described here would break that contract in Debug builds, even if we kept the runtime checks.

Comment thread src/test/AGENTS.md

See [README.md](./README.md) for basic `--unittest` invocation.

Shared test setup/helper code used by more than one test file belongs in `jtx/`, not copy-pasted across test files.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we scope this to shared transaction-building helpers rather than all shared test code? We already keep general utilities like SuiteJournal in src/test/unit_test/ and shared lending fixtures in src/test/app/lending/LoanTestBase.h. Avoiding copy-paste makes sense, but those helpers shouldn't have to move into jtx/ just because multiple tests use them.


Prefer a single amendment-enabled block and a single disabled block over scattering `rules.enabled(...)` checks through a function, even if the two blocks are similar. When a file or function checks more than one amendment, name local enablement booleans per-amendment (e.g. `fix340Enabled` for `fixCleanup3_4_0`), not a generic `fixEnabled`.

Only use `UNREACHABLE` for genuinely impossible paths, not to avoid writing a test for one that's reachable but rare. When a branch marked `UNREACHABLE` is excluded from coverage, wrap it in `LCOV_EXCL_START`/`LCOV_EXCL_STOP`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a general rule for the whole project and it is duplicated in src/libxrpl/tx/transactors/AGENTS.md.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we talked on Wednesday, you didn't want this to be in the top level of the project because it doesn't apply to Rust code. Can you confirm which you'd prefer?

@kuznetsss kuznetsss Sep 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be in a document cpp_guidelines.md and AGENTS.md could reference that document.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or it can be in a single code_conventions.md file with the file/path filtering you shared earlier?
https://code.claude.com/docs/en/memory#path-specific-rules
Either way is fine.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The UNREACHABLE/codecov stuff I'm fine with moving to a separate doc, but the amendment notes should stay here, since that doesn't apply to the whole repo.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could put them in amendments.md file. There will also be a features.md file with short desc. of features and links to XLS docs.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That won't work if the agent is working on something that it doesn't think is an amendment.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

subdir/AGENTS.md could refer to the related directory doc which would contain directory specific rules or links to the other common docs. I would prefer to keep AGENTS.md as simple as possible and not duplicating docs for humans (not a blocker for this PR).

@kuznetsss kuznetsss left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some comments about duplications and structure, but those could be resolved in the next PR.


Prefer a single amendment-enabled block and a single disabled block over scattering `rules.enabled(...)` checks through a function, even if the two blocks are similar. When a file or function checks more than one amendment, name local enablement booleans per-amendment (e.g. `fix340Enabled` for `fixCleanup3_4_0`), not a generic `fixEnabled`.

Only use `UNREACHABLE` for genuinely impossible paths, not to avoid writing a test for one that's reachable but rare. When a branch marked `UNREACHABLE` is excluded from coverage, wrap it in `LCOV_EXCL_START`/`LCOV_EXCL_STOP`.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll also want to mention SOMETIMES here. We tend to use it for situations that are rare.

For instance, values that should be positive - the code rejects non-positive values, but since the values are supplied by a peer it is technically possible for them to send us a negative value. Example:

bool isNegative = value.peek() < 0;
SOMETIMES(isNegative, "....")
if (isNegative)
{
    JLOG(journal.debug(), "....");
    return false;
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these AGENTS.md files discuss UNREACHABLE, XRPL_ASSERT, etc. multiple times, I'd highly recommend updating the external/antithesis-sdk/README.md with explanations of these defines, and then referencing that README.md in the agent files.

Comment thread AGENTS.md
New file placement and header levelization: see [CONTRIBUTING.md](./CONTRIBUTING.md#before-making-a-pull-request). Braces, whitespace, member order, and other conventions: see [docs/CodingStyle.md](./docs/CodingStyle.md). `XRPL_ASSERT`/`UNREACHABLE` contracts: see [CONTRIBUTING.md](./CONTRIBUTING.md#contracts-and-instrumentation). Commit messages: see [CONTRIBUTING.md](./CONTRIBUTING.md#good-commit-messages).
New file placement and header levelization: see [CONTRIBUTING.md](./CONTRIBUTING.md#before-making-a-pull-request). Braces, whitespace, member order, and other conventions: see [docs/CodingStyle.md](./docs/CodingStyle.md). `XRPL_ASSERT`/`UNREACHABLE` contracts: see [CONTRIBUTING.md](./CONTRIBUTING.md#contracts-and-instrumentation). Commit messages: see [CONTRIBUTING.md](./CONTRIBUTING.md#good-commit-messages). New public functions/methods need a Doxygen-style comment.

Comments should explain _why_, not _what_/_how_ — the code already shows that. Only describe what/how when the code itself would otherwise be confusing (a non-obvious workaround, a subtle invariant, a surprising constraint).

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd also suggest expressing a preference here for comments that follow proper sentence format: start with a Capital letter and end with a period.

The codebase is very inconsistent and it's not worth spending dedicated time on cleaning them up by rewriting. However, it would be worth to ensure that new/updated comments are consistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants