test(fork): add FORK_VAULT_COUNT enumeration to lock vault table length

[thedavidmeister]

Summary

• Adds FORK_VAULT_COUNT = 15 constant to test/lib/LibFork.sol — the canonical count of WT_* vault address constants.
• Adds testForkVaultEnumeration() which builds a fixed-size address[FORK_VAULT_COUNT] table of all 15 vaults and runs checkVault over each.
• Because Solidity fixed-size array literals must have exactly FORK_VAULT_COUNT entries, adding a new WT_* address without bumping the constant (and adding it to the table) causes a compile error — a new address cannot ship without a corresponding test entry.

Closes #139.

Why this is needed

After PR #184 merged, expected values are now derived from the vault oracle rather than hand-typed. But the vault address list itself remains unchecked: adding a WT_* constant without a test lets the address ship untested, silently. FORK_VAULT_COUNT enforces structural completeness at compile time.

Test plan

• forge build succeeds (fixed-size array initializer count matches FORK_VAULT_COUNT)
• Fork CI (FORK_RPC_URL_BASE set): testForkVaultEnumeration passes for all 15 vaults
• Temporarily change FORK_VAULT_COUNT to 16: forge build fails (compile error on array initializer length)

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

Summary by CodeRabbit

• Tests
  • Enhanced test coverage for vault enumeration validation across fork configurations.

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 18 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 9e687219-7085-4d52-8b5b-350e741672fa

📥 Commits

Reviewing files that changed from the base of the PR and between f85d1a4 and 6f74b9b.

📒 Files selected for processing (2)

• test/lib/LibFork.sol
• test/src/concrete/ERC4626Words.fork.t.sol

Walkthrough

Adds a FORK_VAULT_COUNT constant (value 15) to test/lib/LibFork.sol and introduces testForkVaultEnumeration() in the ERC4626 fork test, which constructs parallel arrays of all WT_* vault addresses and labels sized by that constant, then iterates over them calling checkVault for each.

Changes

Fork vault enumeration

Layer / File(s)	Summary
FORK_VAULT_COUNT constant and enumeration test test/lib/LibFork.sol, test/src/concrete/ERC4626Words.fork.t.sol	FORK_VAULT_COUNT is defined as 15 in LibFork.sol and imported in the fork test. testForkVaultEnumeration() is added: it allocates vaults and labels arrays of size FORK_VAULT_COUNT, populates them with all WT_* addresses and names, and calls checkVault(vaults[i], labels[i]) for each index.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

Possibly related issues

• 15 vault addresses + a pinned fork block + hand-computed expected outputs are three independent sources of truth with no enforced agreement #139: This PR directly implements part of the structural fix proposed in that issue — specifically the enumeration assertion that ties the number of WT_* vault constants to the test table length, preventing new addresses from being added without corresponding test coverage.
• Fork test vault list and the per-vault test functions are two hand-kept parallel lists with no enumeration test guaranteeing every declared  #141: The PR's introduction of FORK_VAULT_COUNT and testForkVaultEnumeration() matches the enumeration infrastructure described in this issue as the mechanism to enforce coverage of all declared fork vault constants.
• Hardcoded fork block + per-vault 1e18 golden values rot silently and must be hand-refreshed #143: The new enumeration test is complementary to this issue's concern; the PR adds coverage enumeration but does not yet replace hand-coded 1e18 literals with direct vault contract calls as that issue proposes.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Linked Issues check	❓ Inconclusive	The PR implements the enumeration aspect of the structural fix for #139 by adding FORK_VAULT_COUNT as compile-time enforcement. However, it does not yet implement the full fix: expected values are still hand-typed literals, not computed from vault's own convertToShares/convertToAssets calls.	Confirm this PR is Phase 1 of the fix (enumeration enforcement), and Phase 2 (oracle computation from vault calls) is planned in a follow-up PR.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: adding FORK_VAULT_COUNT constant to enforce vault enumeration and prevent accidental mismatches.
Out of Scope Changes check	✅ Passed	All changes are within scope: FORK_VAULT_COUNT constant addition and testForkVaultEnumeration() method directly address the enumeration enforcement mechanism described in #139.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 2026-06-20-issue-139-fork-vault-enumeration

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/lib/LibFork.sol`:
- Line 25: The FORK_VAULT_COUNT constant at line 25 is a manual source of truth
that can drift from the actual number of WT_* vault constants defined above it.
Instead of maintaining separate WT_* constants and a manual count, consolidate
all vault definitions into a single canonical registry (such as an array or
mapping) that contains all the WT_* vault identifiers, and then derive
FORK_VAULT_COUNT mechanically from the length or size of this registry. This
ensures the count is always in sync with the actual number of vaults defined and
cannot accidentally drift out of sync.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 670937f4-6488-4ba1-8e0a-c778436ab244

📥 Commits

Reviewing files that changed from the base of the PR and between dec96d6 and f85d1a4.

📒 Files selected for processing (2)

• test/lib/LibFork.sol
• test/src/concrete/ERC4626Words.fork.t.sol

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

FORK_VAULT_COUNT is still a manual source of truth and can silently drift.

At Line 25, the count is not mechanically tied to the number of WT_* constants above. A new WT_* constant can still be added without compile/test failure if this count and the enumeration table are not updated in the same change, so the “cannot ship untested” guarantee is incomplete. Please consolidate to a single canonical vault registry (from which count is derived) instead of maintaining independent constants and a manual count.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/lib/LibFork.sol` at line 25, The FORK_VAULT_COUNT constant at line 25 is
a manual source of truth that can drift from the actual number of WT_* vault
constants defined above it. Instead of maintaining separate WT_* constants and a
manual count, consolidate all vault definitions into a single canonical registry
(such as an array or mapping) that contains all the WT_* vault identifiers, and
then derive FORK_VAULT_COUNT mechanically from the length or size of this
registry. This ensures the count is always in sync with the actual number of
vaults defined and cannot accidentally drift out of sync.