Validate Docs Section

Validate Documentation Section

You are perfecting the documentation for a section of the Nethereum Docusaurus site. This is a staged workflow with user approval gates — never skip a gate.

Golden rule: ZERO HALLUCINATION. Every class name, method name, namespace, parameter, and code example must be verified against actual source code. Code examples must compile.

Fully-Gated README Accuracy — READMEs are first-knowledge for humans and agents

A README is the first thing both a developer and an AI agent read to learn a package. A hallucinated or stale claim doesn't just mislead a human — an agent acts on it and propagates the error into generated code. So a factual error in a README is a correctness defect, BLOCKING — same footing as a wrong result, not a docs nit.

Self-verification is not enough. An author is blind to their own hallucination — they "remember" an API that never existed, and re-reading their own prose confirms the false memory. A README is not done until an INDEPENDENT pass has re-verified it — a different agent/session than the author, given only the README plus read-only repo access, re-checking every factual claim against the instantiated source: every class, interface, enum member, method signature (return type + every parameter + every default), property name, namespace, constant, advertised capability, and dependency.

Rules of the independent gate (author ≠ gate):

• Verbatim from source, never from memory. The reviewer opens the file and copies the signature out of it. Recall is not evidence — code drifts silently (a capability list read "eth/68, eth/69" while the code advertised eth/68/69/70/71; invisible without opening the source).
• Per-claim evidence table. The verdict is one row per claim: VERIFIED / STALE(→ exact current value) / MISSING (a current public entity the README omits), each with file:line. STALE and MISSING rows first — they are the corrections.
• Any STALE, MISSING, or un-verifiable claim is BLOCKING. The README ships only when every claim is VERIFIED, or corrected and then RE-verified by another independent pass.
• Examples must compile against current signatures — verified against a real [NethereumDocExample] test or a throwaway compile. An example that won't compile is a blocking finding, not a nit.
• >2 unfindable types ⇒ treat the whole README as hallucinated (the X402 rule below) — stop spot-checking, remap the real public surface from source + tests, rewrite.
• The verdict table is a deliverable — recorded with the change so the next drift check starts from a known-verified baseline.

The correction loop: independent audit → fix from the verified values only → independent RE-audit of the changed claims → commit with the verdict recorded. The author never certifies their own README. This gate governs every README-touching stage below (it is what Gate 2 enforces); a green self-review is never a substitute for it.

Traceability — every reference tagged at its source ([NethereumDocExample])

Verifying signatures against source at gate-time is a snapshot — it goes stale the next time the code changes. Traceability makes it structural: every code reference in a README is tagged AT ITS SOURCE with [NethereumDocExample], so a tool can trace — and a test can drift-check — each block back to the live symbol.

• Runnable usage examples → the example is a [NethereumDocExample]-tagged PASSING TEST. An untagged runnable example is blocking.
• API signature / declaration blocks (a class surface, a method / interface / property / constructor signature) → the REAL production symbol carries [NethereumDocExample]. A reflection drift-verify test extracts the live signature from each tagged symbol and asserts the README still contains it; a documented signature with no tagged symbol behind it — or one that no longer matches the live symbol — is blocking.
• One attribute, both halves: usages trace to tests, declarations trace to real code. The attribute targets Method | Class | Interface | Property | Constructor | Enum | Struct for exactly this. Tag each package's symbols with its DocSection (e.g. DocSection.DevP2P) so the drift-verify test can locate the package README from the symbol's assembly.

This is what turns "verified once by a reviewer" into "CI will not let it drift." A declaration verified only by a gate-time audit is a snapshot; a declaration tagged on its live symbol and drift-checked cannot silently rot.

Running the gate — the verifier LOADS this skill and self-directs

The independent gate is not a bespoke brief re-written from scratch each time. Dispatch the verifier agent with an instruction to load this skill (validate-docs-section) — read .claude/skills/validate-docs-section/SKILL.md, this "Fully-Gated README Accuracy" section in particular — and apply it itself. The agent then self-directs from the skill: it knows to produce the per-claim VERIFIED / STALE / MISSING evidence table, to copy signatures verbatim from source (never memory), to treat any stale / missing / untraceable claim as blocking, and to check that every runnable example is test-tagged and every signature block traces to a tagged real symbol. The dispatcher supplies only the target (which README) and read-only scope — the discipline lives in the skill, so it stays identical across every gate run and cannot drift from whatever a hand-written brief happened to remember to include.

Paths

CRITICAL: Sidebar Structure Standard

Every section in sidebars.ts MUST follow this consistent structure:

{
  type: 'category',
  label: 'Section Name',
  items: [
    'section/overview',                    // 1. Overview page (always first)
    {
      type: 'category',
      label: 'Guide Sub-Group Name',       // 2. Guide categories (grouped by learning progression)
      collapsed: false,                     //    First group expanded, rest collapsed
      items: [
        'section/guide-topic-a',           //    Ordered for learner journey, NOT alphabetically
        'section/guide-topic-b',
      ],
    },
    // ... more guide sub-groups as needed
    {
      type: 'category',
      label: 'Package Reference',          // 3. Package Reference (ALWAYS last, ALWAYS this label)
      items: [
        'section/nethereum-package-a',     //    Auto-generated from READMEs via sync-readmes.js
        'section/nethereum-package-b',
      ],
    },
  ],
}

Rules

1. Overview always first — {section}/overview is the entry point
2. Guides grouped by learning progression — NOT one flat list. Group into sub-categories that reflect a learner's journey:
   • Essentials / Getting Started — the first things a learner needs (collapsed: false)
   • Deep Dives / Advanced — topics they explore after mastering essentials
   • Specialized — encoding, transport, infrastructure topics
3. Guide ordering within groups follows the learning path: What does a learner need first? What builds on what? Example: Query Balance → Unit Conversion → Fee Estimation → Send ETH (you need to understand balances before sending, units before fees, fees before sending)
4. Package Reference always last — all nethereum-*.md pages go here. These are auto-generated from READMEs and serve as API reference, not learning material
5. code-generation and similar reference-style pages go in the Guides group closest to their topic, not at the top level
6. Sub-groups within Package Reference are OK for large sections (e.g., JSON-RPC Transport, Networking, Storage providers)

Guide Sub-Group Examples (by section)

Core Foundation:

• Essentials: Query Balance, Unit Conversion, Fee Estimation, Send Ether, Send Transactions, Query Blocks
• Transaction Deep Dives: Transaction Types, Hash, Recovery, Replacement, Pending, Decode
• Keys, Signing & Encoding: Keys & Accounts, Message Signing, ABI, Hex, Address Utils, RLP
• Transport & Streaming: RPC Transport, Real-Time Streaming

Signing & Key Management:

• Guides: EIP-712 Signing, HD Wallets, Keystore, Hardware Wallets, Cloud KMS

Smart Contracts:

• Guides: Smart Contract Interaction, Deploy a Contract, ERC-20 Tokens, Code Generation, Events, Multicall, Error Handling, Built-in Standards, CREATE2

DevChain:

• Guides: DevChain Quickstart

Overview Must Link to Guides

Every overview.md MUST include a guide table at the bottom listing all guides in the section, grouped by sub-category. This is how learners discover guides from the overview page. Format:

## Guides

### Sub-Group Name

| Guide | What You'll Learn |
|---|---|
| [Guide Title](guide-slug) | One-line description |

CRITICAL: Simple Path First Structure

Every guide MUST lead with the simplest web3.Eth.* approach before showing advanced options. The design philosophy is: web3.Eth.* is a complete simple path for every common task. A developer should read the first 30 seconds of any guide, copy the simple code, and have it work — fees, nonce, gas all handled automatically. Deeper APIs are there when needed but never required.

The :::tip The Simple Way Pattern

Every guide that involves a web3.Eth operation MUST open with a tip callout showing 2-5 lines of the simplest working code:

:::tip The Simple Way
\`\`\`csharp
var receipt = await web3.Eth.GetEtherTransferService()
    .TransferEtherAndWaitForReceiptAsync("0xRecipient", 1.11m);
\`\`\`
That's it. Fees, gas, nonce — all automatic.
:::

Rules for the tip:

• Maximum 5 lines of code (excluding var web3 = ... setup)
• Must be a complete, working call — not a fragment
• Must explicitly state what's automatic ("Fees, gas, nonce — all automatic")
• For read-only guides, state: "No gas, signing, or fees needed — these are read-only calls."

Section Labeling for Advanced Content

Advanced or optional sections MUST be clearly labeled so beginners know they can skip them:

• "## More Control: Explicit Fee Parameters" — not just "## EIP-1559 Fee Parameters"
• "## Advanced: Transfer Entire Balance" — not just "## Transfer Entire Balance"
• "## Advanced: Find All Owned NFTs via Transfer Logs" — not just "### Find All Tokens Owned"
• Add intro text: "The sections below are optional — use them only when you need to override the automatic behavior."

The web3.Eth Simple Path Map

The overview page for any section that uses web3.Eth MUST include a simple path table. The Core Foundation reference table:

Key message after the table: "For every row above, Nethereum handles gas estimation, nonce management, EIP-1559 fee calculation, and transaction signing automatically. You only override when you need to."

Built-in Services to Surface

The overview must mention these built-in typed services — no ABI needed:

• web3.Eth.ERC20 — balances, transfers, allowances, metadata
• web3.Eth.ERC721 — NFT ownership, metadata, enumeration
• web3.Eth.ERC1155 — multi-token balances and batch operations
• web3.Eth.GetEIP7022AuthorisationService() — EIP-7702 delegation lifecycle (delegate, check, get delegate, revoke)
• EIP7022SponsorAuthorisationService — sponsored delegation (another account pays gas)

Fee Estimation Framing

The fee estimation guide MUST open with: "Fees are automatic. You probably don't need this guide." The structure should be:

1. "The Default: You Probably Don't Need This Guide" — show zero-config transfer
2. "When You Need More Control" — scenarios that justify reading further
3. Strategy comparison table FIRST (so they can pick), then details for each
4. Legacy mode last

Read-Only Query Callouts

Any guide that covers read-only operations (balance queries, block queries, transaction lookups) MUST note: "These are all read-only queries — no gas, no signing, no fees needed."

EIP-7702 Service Coverage

EIP-7702 is a first-class Nethereum feature with dedicated high-level services. The EIP-7702 guide and any overview referencing it MUST surface the FULL lifecycle:

• Delegate — AuthoriseRequestAndWaitForReceiptAsync(contract)
• Check if smart account — IsDelegatedAccountAsync(address)
• Get delegate contract — GetDelegatedAccountAddressAsync(address)
• Revoke delegation — RemoveAuthorisationRequestAndWaitForReceiptAsync()
• Sponsored delegation — EIP7022SponsorAuthorisationService (sponsor pays gas)
• Batch sponsorship — AuthoriseBatchSponsoredRequestAndWaitForReceiptAsync(keys, contract)
• Inline authorization — attach AuthorisationList to any FunctionMessage to delegate + execute in one transaction
• Gas calculation — AuthorisationGasCalculator.CalculateGasForAuthorisationDelegation() (automatic in transaction manager)
• Hardware wallet/KMS support — all external signers support Type 4 via IEthExternalSigner.SignAsync()

Guide Table Completeness

The overview guide tables MUST list EVERY guide in the section. During Core Foundation validation, the EIP-7702 guide (sidebar_position 13) was missing from the Transaction Deep Dives table — this is the exact kind of gap to catch. After creating or updating any guide, verify it appears in the overview tables.

CRITICAL: Guide Quality Standard

A guide is NOT a code dump with headers. Every guide must teach, not just show.

What makes a guide vs a code dump

Code dump (BAD):

## Encode a String
\`\`\`csharp
var encoded = RlpEncoder.EncodeElement(dogBytes);
\`\`\`
## Encode an Integer
\`\`\`csharp
var encoded = RlpEncoder.EncodeElement(valueBytes);
\`\`\`

Guide (GOOD):

## Why RLP?

RLP is how Ethereum serializes data for the wire — transactions, blocks, and
state trie nodes are all RLP-encoded before hashing or transmitting. You'll
encounter RLP when building raw transactions, verifying Merkle proofs, or
working with the state trie directly.

Most developers never call RLP directly — `Web3` handles it for you when
sending transactions. Use these APIs when you need to:
- Build raw signed transactions offline
- Verify block header proofs
- Decode data returned by `debug_traceTransaction`

## Encode Structured Data

RLP handles two things: byte arrays and lists of byte arrays. Everything
in Ethereum gets reduced to one of these.

\`\`\`csharp
// Encode a string — first convert to bytes, then RLP-wrap
string dog = "dog";
byte[] encoded = RlpEncoder.EncodeElement(dog.ToBytesForRLPEncoding());
\`\`\`

The encoded output is `0x83646f67` — the prefix `0x83` means "byte string
of length 3", followed by the UTF-8 bytes of "dog".

The Guide Quality Checklist

Every guide MUST have these elements. Score each guide against this list:

1. Opening context (2-3 sentences): What problem does this solve? When would a developer reach for this?
2. Prerequisites: What do you need before starting? (packages, accounts, running node, etc.)
3. Mental model: How does this concept work at a high level? Not implementation details — the "why" and "how it fits" into Ethereum/Nethereum.
4. Progressive examples: Start simple, build complexity. Each example builds on the previous one.
5. Guiding text between every code block (CRITICAL — no code dumps): Every code block MUST have at least 1-2 sentences BEFORE it explaining what we're about to do and why, and at least 1 sentence AFTER explaining the result, what to watch for, or how this connects to the next step. A guide that is just ## Header → code block → ## Header → code block is a code dump, not a guide. The text must teach — explain concepts, warn about gotchas, connect to the reader's mental model. All explanatory text must be factual and verifiable against actual Nethereum source code — never hallucinate API behavior, parameter names, or default values.
6. Real-world scenarios: Use realistic values and contexts, not just "hello world". Show addresses, token amounts, contract names that feel like real usage.
7. Decision guidance: When there are multiple approaches, explain when to use which. Tables are great for this.
8. Common mistakes/gotchas: What trips people up? What error will they see if they forget X?
9. What to do next: Connect this guide to related guides with context ("Now that you can sign transactions, you'll want to estimate gas fees to avoid overpaying.")
10. No orphan code: Every code block must be reachable from a real scenario. If code can't be motivated by a user story, it doesn't belong in a guide (put it in the README/API reference instead).

Guides Must Reflect a Learning Journey

Guides are NOT independent articles — they form a connected path through the section. A learner reads them in order and each guide builds on the previous one.

The Core Foundation section is the validated reference template. When validating any section, read the Core Foundation guides first to see the standard in action. Then apply the same patterns.

Journey requirements:

1. Next Steps must follow the learning sequence — the first link in "Next Steps" should be the NEXT guide in the sidebar order. Additional links can point to related topics, but the primary link guides the learner forward through the progression.

2. Prose must be helpful and factual, never hallucinated — every explanation must come from:

   • Verified source code behavior (e.g., "EIP-1559 is the default since version 4.3.1" — checked in TransactionManagerBase.cs)
   • Playground sample comments (verified working text)
   • Ethereum specification facts (e.g., "1 Gwei = 10^9 Wei")
   • Observable API behavior (e.g., "returns null if the transaction hasn't been mined yet")

   NEVER write commentary that sounds authoritative but isn't verifiable. If you're unsure about behavior, check the source code first.

3. Context flows between guides — early guides can mention concepts explored in later guides ("We'll cover fee estimation in detail in the Fee Estimation guide — for now, Nethereum handles it automatically"). Later guides can reference earlier ones ("As we saw in Query Balance, balances are returned in Wei").

4. sidebar_position values must match the learning order within each sub-group. Essentials: 1-6, Deep Dives: 7-12, Keys/Encoding: 13-18, Transport: 19-20 (for Core Foundation as example).

5. No standalone guides — every guide must have at least 2 links in Next Steps connecting it to other guides in the section. At least one link should point forward in the sequence.

Guide Opening Pattern (CRITICAL)

Every guide MUST open with 2-3 sentences that answer WHY and WHEN before any code appears. The opening establishes context for the learner and connects to what they already know from previous guides.

BAD opening (jumps straight to code):

# Query Blocks and Transactions

## Connect to Ethereum

\`\`\`csharp
var web3 = new Web3("https://mainnet.infura.io/v3/YOUR-PROJECT-ID");
\`\`\`

GOOD opening (establishes WHY and connects to journey):

# Query Blocks and Transactions

After sending transactions (as covered in [Transfer Ether](guide-send-eth) and
[Send Transactions](guide-send-transaction)), you'll want to inspect what happened
on-chain. This guide covers querying blocks, looking up transactions by hash,
reading receipts to check success/failure, and detecting whether an address is
a contract or a regular account.

Pattern examples from the validated Core Foundation guides:

The formula:

1. State what problem this solves (1 sentence)
2. Connect to what the learner already knows from previous guides (1 sentence with link)
3. Preview what this guide covers (1 sentence listing the specific topics)

Anti-Patterns to Avoid

These problems were identified during Core Foundation validation and must be checked in every section:

1. Assert-style code in guides — test code like Assert.Equal(expected, actual) or undefined variables from test fixtures does NOT belong in guide examples. Guides show realistic application code, not test assertions. If the source is a test, adapt it to show Console.WriteLine or meaningful variable usage.

2. Repeated boilerplate without cross-reference — if 5 guides all start with var web3 = new Web3(url), the later guides should say "Connect to Ethereum as shown in Getting Started" or simply show the line with a brief note, not a full "## Connect to Ethereum" section every time.

3. Reference disguised as a guide — a page that lists every transaction type with its fields but doesn't teach when to use each one is a reference page, not a guide. Guides answer "which one should I pick?" with decision tables and scenarios.

4. Dead-end guides — guides that end abruptly without Next Steps or that only link to unrelated sections. Every guide must connect back into its section's learning path.

5. Orphan concepts — mentioning a concept (like "EIP-1559 fees") without either explaining it or linking to the guide that does. The learner should never hit an unexplained term.

6. Code dumps — a section that is just ## Header followed immediately by a code block, repeated for every feature, with no explanatory text between them. Every code block MUST have at least 1-2 sentences BEFORE it explaining what we're about to do and why, and optionally a sentence AFTER explaining the output, what to watch for, or what the code connects to. The text must guide the reader through the code, not just label it. All explanatory text must reference actual Nethereum API behavior verified against source code — never hallucinate behavior or parameter names.

7. Entirely hallucinated READMEs — a README that documents a completely fictional API surface. During DeFi validation, the Nethereum.X402 README was 100% hallucinated: X402Service, X402Client, X402PaymentHeader, X402PaymentProposal, X402PaymentRequired attribute, IPaymentValidator, FacilitatorDiscoveryClient, IPaymentEventHandler, AddX402() — NONE existed in source code. The actual API (X402HttpClient, X402Middleware, RoutePaymentConfig, X402TransferWithAuthorisation3009Service) was completely different. Stage 2 MUST verify every class name against source, not spot-check. When a README smells wrong (aspirational API design, no matching tests), treat the entire file as suspect and rewrite from integration tests.

8. Wrong generic type parameters — MultiSendInput vs MultiSendFunctionInput<TFunctionMessage> is not a minor typo — it's a completely different API pattern. During DeFi validation, the GnosisSafe README used a non-existent MultiSendInput class and MultiSendOperationType enum (actual: ContractOperationType), and property To (actual: Target). Always verify generic type signatures, not just class names. Search for class ClassName AND class ClassName< to catch generic variants.

9. Wrong method return types — the Uniswap README showed CalculatePricesFromSqrtPriceX96 (plural) returning a tuple with .Item1/.Item2. The actual method is CalculatePriceFromSqrtPriceX96 (singular) returning a single decimal. Verify method signatures including return types, not just names. A method that returns decimal is fundamentally different from one returning (decimal, decimal).

10. Overview simple path tables propagating hallucinations — when a README is hallucinated, the overview page's simple path table, guide tip callouts, and skill examples all copy the same wrong API. After fixing any README, immediately check and fix all downstream artifacts: overview table, guide pages, plugin skills. Search for the old (wrong) class/method names across all doc files to catch every instance.

Guide vs README distinction

• README = API reference. Lists all public methods, parameters, return types. Complete but not pedagogical. Lives in src/{Package}/README.md.
• Guide = Task-oriented tutorial. Teaches how to accomplish a specific goal. Explains concepts. Lives in docs/{section}/guide-*.md.
• A guide should LINK to the README for "full API reference", not duplicate it.
• A guide covers ~20% of the API but explains WHY and WHEN for 100% of what it shows.

Skills must also teach

Plugin skills (plugins/nethereum-skills/skills/) serve AI models as well as users. A skill must contain enough context that an AI model understands:

• What problem this solves
• When to use this approach vs alternatives
• What packages are needed and why
• Complete, working code patterns (verified against tests)

Test-Driven Documentation

Every code example in guides, skills, and READMEs must be backed by a passing test tagged with [NethereumDocExample].

The [NethereumDocExample] Attribute

Located in src/Nethereum.Documentation/NethereumDocExampleAttribute.cs (namespace Nethereum.Documentation). Uses a DocSection enum to ensure section names match exactly:

[Fact]
[NethereumDocExample(DocSection.CoreFoundation, "send-eth", "Transfer ETH with EIP-1559 fees", Order = 2)]
public async void ShouldTransferEtherEIP1559() { ... }

Parameters:

• DocSection section — enum: CoreFoundation, Signing, SmartContracts, DeFi, EvmSimulator, InProcessNode, AccountAbstraction, DataIndexing, MudFramework, WalletUI, Consensus, ClientExtensions
• string useCase — slug matching the guide/skill name (e.g., "send-eth", "fee-estimation", "erc20-tokens")
• string title — human-readable title for the example
• string SkillName — optional, defaults to useCase (since guide/skill/test use cases should align)
• int Order — ordering within a use case (when multiple tests per use case)

Workflow

When creating doc examples:

1. Search for existing tests matching the use case — tag them with [NethereumDocExample]
2. If no test exists, create one in the appropriate test project and tag it
3. Guide pages and skills extract code from tagged tests — never invent examples
4. The attribute is extractable via reflection — tools can discover all doc examples by scanning for [NethereumDocExample] across test assemblies

Commit Integration

The /commit skill (.claude/commands/commit.md) enforces documentation propagation:

• When tagged tests change → README, guide, and skill updates are checked
• When new public API is added without a tagged test → flagged for follow-up
• This creates a closed loop: code change → test update → docs update → commit

Adding to test projects

The attribute lives in the standalone Nethereum.Documentation project (netstandard2.0, zero dependencies). To use it:

For xUnit test projects (already referencing Nethereum.XUnitEthereumClients):

1. The attribute is available transitively — XUnitEthereumClients references Nethereum.Documentation
2. Add using Nethereum.Documentation; to the test file

For console test projects or any other project:

1. Add <ProjectReference Include="..\..\src\Nethereum.Documentation\Nethereum.Documentation.csproj" /> to the .csproj
2. Add using Nethereum.Documentation; to the source file
3. Works with any target framework (netstandard2.0 compatible)

Plugin Architecture

User-facing skills are distributed as a Claude Code Plugin at plugins/nethereum-skills/. This is a single installable plugin that bundles all Nethereum user skills together. Users install it once with /plugin install nethereum-skills and all skills become auto-discoverable.

plugins/nethereum-skills/
├── .claude-plugin/
│   └── plugin.json              ← manifest (name, version, description, keywords)
└── skills/
    ├── send-eth/
    │   └── SKILL.md
    ├── erc20/
    │   └── SKILL.md
    ├── events/
    │   └── SKILL.md
    └── ...                      ← one skill per use case (or grouped tightly related use cases)

After installation, skills are:

• Auto-triggered by Claude based on context (user asks about ERC-20 → erc20 skill activates)
• Directly invocable via /nethereum-skills:send-eth, /nethereum-skills:erc20, etc.
• Listed in the user's available skills

Internal development skills (like this one) stay in .claude/skills/ — they are NOT part of the plugin.

Resumability

This workflow can span multiple sessions. At the start of each invocation:

1. Check if PROGRESS.md exists for this section
2. If yes, read it and resume from where you left off
3. If no, start from Stage 1

After completing each stage, update PROGRESS.md with:

• Which stage was completed
• Key decisions made (approved use cases, identified issues, etc.)
• What comes next

Stage 1: Define Use Cases

Goal: Identify every real-world task a developer would want to accomplish with this section's packages.

Process

1. Read the existing docs for this section in the Docusaurus site
2. Read the package READMEs for every package in this section
3. Read the actual source code — don't trust READMEs alone. Grep for public classes, check what APIs exist that aren't documented. The source is truth.
4. Search for playground examples — check if playground.nethereum.com has samples that map to this section. Search test projects in the repo for integration tests that demonstrate usage.
5. Search the old docs — check if the old MkDocs documentation (https://docs.nethereum.com/en/latest/) has guides for these use cases and note what content existed there
6. Check existing plugin skills — read plugins/nethereum-skills/skills/ to see what already exists. Don't duplicate.
7. Think as a user — what would someone Google? "how to send ETH C#", "decode EIP-712 typed data .NET", "abi.encodePacked equivalent C#". Each search query is a potential use case.
8. Define use cases as a table:

Each use case should be:

• A concrete task a developer wants to do ("Send ETH to an address", not "Learn about transactions")
• Sized appropriately — small focused tasks get their own row, large topics can be one row
• Mapped to exactly one guide page in the docs
• Mapped to a plugin skill (one skill per use case, or one skill covering a few tightly related use cases — use judgment)
• Linked to playground examples where they exist

Also note any external references the guide pages should link to:

• chainlist.org for finding public RPC endpoints
• Provider sign-up pages (Infura, Alchemy, Chainlink, etc.)
• Related tools (Foundry/Anvil, Hardhat, Remix, etc.)
• Ethereum documentation (ethereum.org) for concept explanations

Gate 1: Present the use case table to the user. Wait for approval before proceeding.

Stage 2: Validate NuGet Package READMEs

Goal: Every README referenced by the use cases must be 100% accurate. Every code example must compile.

Process

For each NuGet package referenced in the use case table:

1. Find the README: src/{PackageName}/README.md

2. Find the .csproj: Verify the package name matches the actual project file

3. Find the test projects: Search tests/ and consoletests/ for test files covering this package. These are the most reliable source of verified, working code. Map them:

   Test File	Type	What It Tests	Network?
   tests/Nethereum.XXX.UnitTests/SomeTest.cs	Unit	Feature X	No
   tests/Nethereum.XXX.IntegrationTests/OtherTest.cs	Integration	Feature Y	Yes

   Common test project locations:

   • tests/Nethereum.{Package}.UnitTests/ — unit tests (no network)
   • tests/Nethereum.{Package}.IntegrationTests/ — integration tests (need devchain)
   • tests/Nethereum.Contracts.IntegrationTests/ — many packages tested here (ERC20, Multicall, ErrorReason, etc.)
   • tests/Nethereum.Signer.UnitTests/ — transaction signing, EIP-712, EIP-155
   • consoletests/ — demo/console test programs

4. Cross-reference every code example in the README against source code:

   For each code snippet in the README:

   • Classes: Grep for class ClassName AND class ClassName< — does it exist? Correct namespace? Is it generic?
   • Methods: Grep for the method signature — correct parameters? Correct return type? A method returning decimal is NOT the same as one returning a tuple.
   • Properties: Verify they exist on the class — check the actual property name (e.g., Target vs To)
   • Constructors: Verify overload exists with shown parameters
   • Namespaces/usings: Verify they're correct
   • Extension methods: Verify the static class and method exist
   • Enums: Verify enum type names AND member names (e.g., ContractOperationType vs hallucinated MultiSendOperationType)

   CRITICAL: If more than 2 classes in a README cannot be found in source, the entire README is likely hallucinated. Stop spot-checking and instead:

   1. Map the ACTUAL public API surface from source code (Grep for all public class/interface/enum)
   2. Read integration tests to understand how the API is actually used
   3. Rewrite the README from scratch using tests as the source of truth

5. Compile-check: For each code example, verify it compiles. Prefer verifying against existing test code rather than creating new throwaway projects — if a test already exercises the same API, that's sufficient proof the example works. Only create a minimal .csx or console project for examples that have no corresponding test. If the example needs a running node, verify it compiles but note "requires running node".

6. Identify missing test coverage: For each package feature, check if a test exists. If a feature is documented but has no test, flag it. If a feature has a test but is undocumented, that's a missing-documentation gap. The test file is the best source for writing the documentation example.

7. Scan for missing functionality (critical — run every time):

   For each package, systematically compare what's in the source vs what's in the README:

   a. List all public classes in the package source directory (src/{PackageName}/). Use Grep for public class, public static class, public abstract class, public interface, public enum, public record.

   b. Cross-reference against the README: For each public class/interface/enum found in source, check if it appears anywhere in the README. Build a table:

   Class/Interface	Source File	In README?	Importance

   c. Flag missing high-value APIs: Focus on classes that represent major features users would want to discover:

   • New EIP/ERC implementations (e.g., EIP-7702 transaction types, EIP-2612 permit)
   • Cryptographic primitives (e.g., Poseidon hashing, BLS signatures)
   • Service classes that solve common developer tasks (e.g., fee estimation, nonce management)
   • Extension methods that add convenience (e.g., parameter conversion helpers)
   • Error handling types (e.g., custom exceptions for contract reverts)
   • High-level convenience classes like ABIEncode that wrap low-level primitives — these are what users actually want

   d. Categorize gaps by severity:

   • 🔴 Critical: Major feature completely undocumented (e.g., ABIEncode class, EIP-712 encoding in ABI package)
   • 🟠 Significant: Important utility/service missing (e.g., fee estimation strategies)
   • 🟡 Minor: Helper class or internal utility that advanced users might want

   e. Skip internal/infrastructure classes that aren't meant for direct consumer use (e.g., internal factories, test helpers).

8. Check playground alignment: If a playground example exists for this package, verify the README's examples are consistent with it.