stabilise IOrderBookV6

[thedavidmeister]

Move IOrderBookV6 from unstable/ to src/interface/ as the current stable interface. Deprecate IOrderBookV5 to deprecated/v5/. Update import paths and document the interface lifecycle convention in CLAUDE.md.

Motivation

Solution

Checks

By submitting this for review, I'm confirming I've done the following:

• made this PR as small as possible
• unit-tested any new functionality
• linked any relevant issues or PRs
• included screenshots (if this involves a front-end change)

Summary by CodeRabbit

• New Features

  • IOrderBookV6 is now the stable interface, adding vaultless operation (vault ID 0) and input/output-based take order limits via an IOIsInput flag.
  • New callback interfaces for takeOrders introduced.

• Documentation

  • Added Interface Lifecycle section and updated versioning/conventions to reflect V6 as stable.

• Deprecations

  • IOrderBookV5 and earlier superseded by V6.

• Chores

  • Project import/path and reuse metadata references updated for consistency.

[coderabbitai]

Walkthrough

Promotes IOrderBookV6 as the documented stable interface (vaultless via vault ID 0, IOIsInput flag), adds V6 take-order callback interfaces, documents interface lifecycle and deprecation, and updates import paths across multiple deprecated IOrderBook versions plus REUSE.toml and related files.

Changes

Cohort / File(s)	Summary
Documentation CLAUDE.md	Replaces V5 with IOrderBookV6 as the stable interface; documents vaultless behavior (vault ID 0) and IOIsInput-controlled limits; adds IOrderBookV6OrderTaker and IOrderBookV6ArbOrderTaker; adds "Interface Lifecycle" section; updates deprecation lineage to include v1–v5.
Primary interface & immediate deprecated v5 src/interface/IOrderBookV6.sol, src/interface/deprecated/v5/IOrderBookV5.sol	Adjusted import paths to new relative locations; IOrderBookV5 moved under deprecated/v5; no public signature or logic changes in these files.
Deprecated interfaces (v1–v4) src/interface/deprecated/v1/IOrderBookV1.sol, src/interface/deprecated/v2/IOrderBookV2.sol, src/interface/deprecated/v3/IOrderBookV3.sol, src/interface/deprecated/v4/IOrderBookV4.sol	Updated import paths to point to reorganized deprecated locations (v1/v2 paths, consolidated imports); no changes to public interfaces or signatures.
Repository metadata REUSE.toml	Added path entries for CLAUDE.md and audit/**/ to REUSE.toml path list.
General note src/interface/...	Most edits are import path adjustments due to directory reorganization; no functional or signature changes reported across interfaces.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'stabilise IOrderBookV6' directly and clearly describes the main objective of the PR, which is to move IOrderBookV6 from unstable to stable and designate it as the current stable interface.
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
• Post copyable unit tests in a comment
• Commit unit tests in branch 2026-03-06-stable

---

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 and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/interface/IOrderBookV6.sol (1)

18-28: 🧹 Nitpick | 🔵 Trivial

Decouple the stable V6 surface from deprecated/v5.

IOrderBookV6 now reuses core public structs from ./deprecated/v5/IOrderBookV5.sol. That couples the new stable interface to a deprecated namespace and makes future retirement of V5 harder because V6's public API still transitively depends on it. Prefer extracting the shared structs into a version-neutral types module under src/interface/, then importing that from both V5 and V6.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/interface/IOrderBookV6.sol` around lines 18 - 28, The IOrderBookV6
interface currently imports public structs from deprecated/v5
(ClearStateChangeV2, ClearConfigV2, TaskV2, IOV2, OrderConfigV4, OrderV4,
TakeOrderConfigV4, QuoteV2) which couples V6 to V5; extract these shared
struct/type definitions into a new version-neutral module under src/interface
(e.g., IOrderBookTypes.sol or types/IOrderBookTypes.sol), move the definitions
there, update both deprecated/v5/IOrderBookV5.sol and IOrderBookV6.sol to import
from that new module instead of ./deprecated/v5/IOrderBookV5.sol, and ensure
visibility/comments and SPDX/pragmas remain consistent so compilation and public
API signatures are unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@src/interface/IOrderBookV6.sol`:
- Around line 18-28: The IOrderBookV6 interface currently imports public structs
from deprecated/v5 (ClearStateChangeV2, ClearConfigV2, TaskV2, IOV2,
OrderConfigV4, OrderV4, TakeOrderConfigV4, QuoteV2) which couples V6 to V5;
extract these shared struct/type definitions into a new version-neutral module
under src/interface (e.g., IOrderBookTypes.sol or types/IOrderBookTypes.sol),
move the definitions there, update both deprecated/v5/IOrderBookV5.sol and
IOrderBookV6.sol to import from that new module instead of
./deprecated/v5/IOrderBookV5.sol, and ensure visibility/comments and
SPDX/pragmas remain consistent so compilation and public API signatures are
unchanged.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4e6118da-bab5-4f77-b602-062aba4f8d72

📥 Commits

Reviewing files that changed from the base of the PR and between 00c21c0 and 0478f83.

📒 Files selected for processing (7)

• REUSE.toml
• src/interface/IOrderBookV6.sol
• src/interface/deprecated/v1/IOrderBookV1.sol
• src/interface/deprecated/v2/IOrderBookV2.sol
• src/interface/deprecated/v3/IOrderBookV3.sol
• src/interface/deprecated/v4/IOrderBookV4.sol
• src/interface/deprecated/v5/IOrderBookV5.sol

[github-actions]

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

• Simple bug fixes, typos, or minor refactoring
• Single-purpose changes affecting 1-2 files
• Documentation updates
• Configuration tweaks
• Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

• Fix typo in variable name
• Update README with new instructions
• Adjust configuration values
• Simple one-line bug fixes
• Import statement cleanup

Medium (M)

Characteristics:

• Feature additions or enhancements
• Refactoring that touches multiple files but maintains existing behavior
• Breaking changes with backward compatibility
• Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

• Add new feature or component
• Refactor common utility functions
• Update dependencies with minor breaking changes
• Add new component with tests
• Performance optimizations
• More complex bug fixes

Large (L)

Characteristics:

• Major feature implementations
• Breaking changes or API redesigns
• Complex refactoring across multiple modules
• New architectural patterns or significant design changes
• Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

• Complete new feature with frontend/backend changes
• Protocol upgrades or breaking changes
• Major architectural refactoring
• Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

• Test coverage impact: More comprehensive test changes lean toward larger classification
• Risk level: Changes to critical systems bump up a size category
• Team familiarity: Novel patterns or technologies increase complexity

Notes:

• the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
• the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
• do not include any additional text, only the size classification
• your assessment comment must not include tips or additional sections
• do NOT tag me or anyone else on your comment

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

SIZE=M