@bananapus/permission-ids-v6 0.0.26 → 0.0.27

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bananapus/permission-ids-v6",
-  "version": "0.0.26",
+  "version": "0.0.27",
   "license": "MIT",
   "repository": {
     "type": "git",
@@ -8,5 +8,11 @@
   },
   "engines": {
     "node": ">=20.0.0"
-  }
+  },
+  "files": [
+    "foundry.toml",
+    "references/",
+    "remappings.txt",
+    "src/"
+  ]
 }

package/ADMINISTRATION.md

@@ -1,62 +0,0 @@
-# Administration
-
-## At A Glance
-
-| Item | Details |
-| --- | --- |
-| Scope | Shared permission ID namespace for the wider ecosystem |
-| Control posture | Source-level coordination only |
-| Highest-risk actions | Reordering or reusing IDs already assumed by deployed contracts |
-| Recovery posture | Requires downstream code changes and redeployments where relevant |
-
-## Purpose
-
-`nana-permission-ids-v6` has no runtime admin surface. Its control significance is at the source level: it defines the shared permission namespace used by the rest of the ecosystem.
-
-## Control Model
-
-- No owner
-- No runtime governance
-- No mutable onchain state
-- Source-level coordination only
-
-## Roles
-
-| Role | How Assigned | Scope | Notes |
-| --- | --- | --- | --- |
-| Maintainer | Source-code author | Ecosystem-wide | Can add or reorder constants only by editing code and updating dependent deployments |
-
-## Privileged Surfaces
-
-There are no privileged runtime functions. The only meaningful changes are source changes to `JBPermissionIds.sol`.
-
-## Immutable And One-Way
-
-- Once deployed contracts depend on a given ID mapping, that mapping is effectively immutable for those deployments.
-- Reusing or reordering IDs is a cross-repo breaking change.
-
-## Operational Notes
-
-- Add new permission IDs append-only.
-- Update downstream docs and call sites in the same change set.
-- Treat permission ID changes as protocol changes, not refactors.
-
-## Machine Notes
-
-- Do not infer semantic compatibility from matching names if numeric IDs changed.
-- Treat `src/JBPermissionIds.sol` as append-only unless a breaking ecosystem-wide migration is intentional.
-- If docs and code disagree on a permission number, trust the code and update the docs before further review.
-
-## Recovery
-
-- There is no runtime recovery surface.
-- A bad ID assignment is fixed only by downstream code changes and redeployments where needed.
-
-## Admin Boundaries
-
-- Nobody can patch deployed contracts to reinterpret old permission bits.
-- This repo cannot grant, revoke, or inspect permissions by itself.
-
-## Source Map
-
-- `src/JBPermissionIds.sol`

package/ARCHITECTURE.md

@@ -1,53 +0,0 @@
-# Architecture
-
-## Purpose
-
-`nana-permission-ids-v6` is the shared permission namespace for the V6 ecosystem. It makes sure every repo agrees on what each permission bit means when interacting with `JBPermissions`.
-
-## System Overview
-
-This repo intentionally contains almost no logic. Other repos import `JBPermissionIds` and compare permission bits against these constants.
-
-## Core Invariants
-
-- Existing IDs must stay stable once deployed contracts or integrations use them.
-- New IDs should be appended intentionally, not reused or repurposed.
-- Numeric stability matters more than naming convenience.
-- `ROOT` must stay aligned with `JBPermissions` expectations in `nana-core-v6`.
-
-## Modules
-
-| Module | Responsibility | Notes |
-| --- | --- | --- |
-| `JBPermissionIds` | Defines canonical `uint8` permission IDs | Entire repo value |
-
-## Trust Boundaries
-
-- This repo has no runtime authority by itself.
-- It is tightly coupled to `nana-core-v6` and every repo that performs permission checks.
-
-## Critical Flows
-
-There is no runtime flow. Other repos import the library and use the constants in permission checks.
-
-## Accounting Model
-
-No accounting lives here.
-
-## Security Model
-
-- The code is trivial, but the coordination burden is not.
-- A rename or reorder here can silently break permissions across the ecosystem.
-- The real blast radius comes from deployed contracts that already use these values.
-- There is very little meaningful local runtime test surface in this repo.
-
-## Safe Change Guide
-
-- Treat any ID change as a cross-repo protocol change.
-- When adding a permission, update downstream repos and docs in the same change set.
-- Do not add aliases that hide the one-to-one mapping between bit position and meaning.
-
-## Source Map
-
-- `src/JBPermissionIds.sol`
-- `references/runtime.md`

package/AUDIT_INSTRUCTIONS.md

@@ -1,57 +0,0 @@
-# Audit Instructions
-
-This repo is only permission ID constants, but those constants are security-critical because many repos key access control off them.
-
-## Audit Objective
-
-There is a billion dollars of well-meaning projects' money in the Juicebox Money Engine, growing exponentially. Your job is to hack it before anyone else. Whoever hacks it first saves/steals the money, and you are obsessed with being this winner, while also being a steward of the protocol and wanting it to keep growing safely.
-
-Suggestions of where to look:
-
-- assign duplicate IDs to different permissions
-- mismatch IDs that downstream repos assume are canonical
-- create ordering or collision hazards for future permission additions
-
-## Scope
-
-In scope:
-
-- `src/JBPermissionIds.sol`
-
-## Start Here
-
-1. `src/JBPermissionIds.sol`
-2. downstream consumers in `nana-core-v6` and `revnet-core-v6`
-
-## Security Model
-
-This repo defines canonical numeric IDs that other repos treat as part of their permission model.
-
-- the file is small, but stale renumbering or collisions can silently widen or break access control elsewhere
-- correctness depends on cross-repo alignment, not local logic alone
-
-## Integration Assumptions
-
-| Dependency | Assumption | What breaks if wrong |
-|------------|------------|----------------------|
-| `nana-core-v6` | ERC-20 signature delegation still uses the documented ID | Signature authority checks mismatch |
-| `revnet-core-v6` | Loan permissions still use the documented IDs | Delegated actions widen, fail, or misroute |
-
-## Critical Invariants
-
-1. Each permission semantic has one stable numeric ID.
-2. No two distinct permissions share an ID.
-3. IDs match the expectations of all dependent repos in this workspace.
-4. ID `23` (`SIGN_FOR_ERC20`) matches the value used by `nana-core-v6` for ERC-1271 signature delegation.
-5. IDs used by `revnet-core-v6` match the values used in `REVLoans`.
-
-## Attack Surfaces
-
-- duplicate or reordered constants
-- stale cross-repo assumptions
-- permission additions that collide with previously assigned meanings
-
-## Verification
-
-- `npm install`
-- `forge build`

package/CHANGELOG.md

@@ -1,51 +0,0 @@
-# Changelog
-
-## Scope
-
-This file describes the verified change from `nana-permission-ids-v5` to the current `nana-permission-ids-v6` repo.
-
-## Current v6 surface
-
-- `JBPermissionIds`
-
-## Summary
-
-- The numeric permission map shifted. `LAUNCH_RULESETS` was inserted near the top of the sequence and every downstream numeric value moved with it.
-- v6 adds permissions for capabilities that did not exist in the old map, including `LAUNCH_RULESETS`, `ADD_TERMINALS`, `SET_TOKEN_METADATA`, `SET_BUYBACK_HOOK`, `SET_ROUTER_TERMINAL`, and `SET_SUCKER_DEPRECATION`.
-- The old swap-terminal-specific permissions are gone because the deployed ecosystem no longer centers on `nana-swap-terminal-v5`.
-- `SUCKER_SAFETY` no longer covers every safety action by itself. `SET_SUCKER_DEPRECATION` is its own permission in v6.
-
-## v6 additions: nana-core ERC-1271 delegation (ID 23)
-
-- `SIGN_FOR_ERC20` (23) — sign messages on behalf of a project's ERC-20 token via ERC-1271. Used for Etherscan contract verification and other off-chain signature validation.
-
-## v6 additions: revnet-core delegation
-
-- `OPEN_LOAN` — open a loan on behalf of a token holder via `REVLoans.borrowFrom`. Checked against the token holder.
-- `REALLOCATE_LOAN` — reallocate loan collateral on behalf of a loan NFT owner via `REVLoans.reallocateCollateralFromLoan`. Checked against the loan NFT owner.
-- `REPAY_LOAN` — repay a loan on behalf of a loan NFT owner via `REVLoans.repayLoan`. Checked against the loan NFT owner.
-
-These are consumed by `revnet-core-v6` and checked via inline `PERMISSIONS.hasPermission` calls (for `REVLoans`).
-
-## Verified deltas
-
-- `QUEUE_RULESETS` no longer also covers `launchRulesetsFor`; `LAUNCH_RULESETS` is its own constant.
-- `ADD_TERMINALS` was inserted between `SET_TERMINALS` and `SET_PRIMARY_TERMINAL`.
-- `SET_TOKEN_METADATA`, `SET_BUYBACK_HOOK`, `SET_ROUTER_TERMINAL`, and `SET_SUCKER_DEPRECATION` are new constants.
-- `ADD_SWAP_TERMINAL_POOL` and `ADD_SWAP_TERMINAL_TWAP_PARAMS` were removed.
-
-## Breaking ABI changes
-
-- There is no runtime contract ABI to port here.
-- The breaking surface is compile-time and application-logic-level: constant names, meanings, and numeric values changed.
-
-## Indexer impact
-
-- None directly from this repo.
-- Indirectly, any off-chain access-control model keyed to raw numeric IDs must be updated.
-
-## Migration notes
-
-- Hardcoded numeric permission IDs from v5 are stale and unsafe.
-- Rebuild every permission check from the named v6 constants.
-- Treat this repo as application-logic-critical even though it is not a large runtime surface.

package/RISKS.md

@@ -1,51 +0,0 @@
-# Permission IDs Risk Register
-
-This file covers the coordination risks in `JBPermissionIds`. The contract surface is tiny, but drift here can corrupt access control across the V6 ecosystem.
-
-## How To Use This File
-
-- Read `Priority risks` first. The main danger is cross-repo disagreement, not a local code bug.
-- Treat every ID change as an ecosystem migration event.
-- Use `Invariants to verify` to keep append-only discipline explicit.
-
-## Priority Risks
-
-| Priority | Risk | Why it matters | Primary controls |
-|----------|------|----------------|------------------|
-| P0 | Semantic drift across repos | If two packages assign different meanings to the same ID, permission checks can silently authorize the wrong actions. | Single source of truth, append-only changes, and synchronized downstream updates. |
-| P1 | Reusing or reordering existing IDs | Renumbering breaks deployed contracts and off-chain tooling without any on-chain migration safety. | Never repurpose an assigned ID. Append only. |
-| P1 | Over-trusting high-impact IDs | Some IDs directly control funds, routing, locking, or loan state. Misgrants are dangerous. | Explicit operator review and narrow-scoped grants. |
-
-## 1. Known Risks
-
-- **No runtime enforcement here.** This library only defines constants. Safety depends on every consuming repo checking the intended ID.
-- **`ROOT` is broad authority.** `ROOT` (ID `1`) grants all permissions, including permissions added in the future.
-- **Wildcard grants increase blast radius.** Any permission granted with `projectId = 0` applies to all projects owned by that account.
-- **Hook and router lock powers are bundled.** `SET_BUYBACK_HOOK` (`30`) and `SET_ROUTER_TERMINAL` (`31`) both cover setting and locking.
-- **Third-party extensions do not have an on-chain namespace.** IDs `41-255` are only socially coordinated, so external packages can collide without coordination. ID `40` is not currently assigned in `JBPermissionIds.sol`.
-
-## 2. High-Impact IDs
-
-- **Fund-moving IDs.** `CASH_OUT_TOKENS` (`4`), `SEND_PAYOUTS` (`5`), `MIGRATE_TERMINAL` (`6`), `SET_TERMINALS` (`15`), `USE_ALLOWANCE` (`18`), and `SET_SPLIT_GROUPS` (`19`) can redirect or release value.
-- **Hook-routing IDs.** `SET_BUYBACK_POOL` (`28`), `SET_BUYBACK_HOOK` (`30`), and `SET_ROUTER_TERMINAL` (`31`) materially control execution routes and can lock those routes permanently.
-- **Sucker lifecycle IDs.** `SUCKER_SAFETY` (`35`) and `SET_SUCKER_DEPRECATION` (`36`) control emergency recovery and bridge shutdown state.
-- **Revnet loan IDs.** `OPEN_LOAN` (`37`), `REALLOCATE_LOAN` (`38`), and `REPAY_LOAN` (`39`) are operationally powerful because they move collateral and debt state.
-
-## 3. Integration Risks
-
-- **Docs can lag deployed assumptions.** Off-chain tooling, UIs, and reviews often rely on human-readable permission names.
-- **Cross-package imports must stay canonical.** Downstream repos should import this library instead of redefining numeric literals locally.
-- **Future IDs expand current `ROOT` power.** Any new permission automatically becomes available to existing `ROOT` operators.
-
-## 4. Invariants To Verify
-
-- Assigned IDs are append-only and never repurposed.
-- `0` stays unused as a permission ID.
-- Every documented ID in this repo matches the numeric checks in downstream contracts.
-- ID `40` remains unused until a named constant is appended, and all new IDs are added without colliding with existing ecosystem assignments.
-
-## 5. Accepted Behaviors
-
-### 5.1 This repo is coordination infrastructure, not an enforcement layer
-
-`JBPermissionIds` intentionally has no access control, storage, or runtime checks. The repo matters because every other package can import the same constants and mean the same thing.

package/SKILLS.md

@@ -1,32 +0,0 @@
-# Juicebox Permission IDs
-
-## Use This File For
-
-- Use this file when you need the canonical numeric meaning of a Juicebox V6 permission constant.
-- Start here when reviewing changes that could affect permission numbering across the ecosystem.
-
-## Read This Next
-
-| If you need... | Open this next |
-|---|---|
-| Repo overview and scope | [`README.md`](./README.md), [`ARCHITECTURE.md`](./ARCHITECTURE.md) |
-| The actual constants | [`src/JBPermissionIds.sol`](./src/JBPermissionIds.sol) |
-
-## Repo Map
-
-| Area | Where to look |
-|---|---|
-| Constants | [`src/JBPermissionIds.sol`](./src/JBPermissionIds.sol) |
-
-## Purpose
-
-This repo is the single source of truth for Juicebox V6 permission ID constants. It has no runtime behavior. Its value is ecosystem-wide coordination.
-
-## Reference Files
-
-- Open [`references/runtime.md`](./references/runtime.md) when you need the stability expectations and why changes here affect the whole ecosystem.
-
-## Working Rules
-
-- Start in [`src/JBPermissionIds.sol`](./src/JBPermissionIds.sol). The file itself is the product.
-- Treat any numeric change as a cross-repo breaking change until proven otherwise.

package/STYLE_GUIDE.md

@@ -1,565 +0,0 @@
-# Style Guide
-
-How we write Solidity and organize repos across the Juicebox V6 ecosystem. `nana-core-v6` is the gold standard — when in doubt, match what it does.
-
-## File Organization
-
-```
-src/
-├── Contract.sol              # Main contracts in root
-├── abstract/                 # Base contracts (JBPermissioned, JBControlled)
-├── enums/                    # One enum per file
-├── interfaces/               # One interface per file, prefixed with I
-├── libraries/                # Pure/view logic, prefixed with JB
-├── periphery/                # Utility contracts (deadlines, price feeds)
-└── structs/                  # One struct per file, prefixed with JB
-```
-
-One contract/interface/struct/enum per file. Name the file after the type it contains.
-
-## Pragma Versions
-
-```solidity
-// Contracts — pin to exact version
-pragma solidity 0.8.28;
-
-// Interfaces, structs, enums — caret for forward compatibility
-pragma solidity ^0.8.0;
-
-// Libraries — pin to exact version like contracts
-pragma solidity 0.8.28;
-```
-
-## Imports
-
-Named imports only. Grouped by source, alphabetized within each group:
-
-```solidity
-// External packages (alphabetized)
-import {ERC2771Context} from "@openzeppelin/contracts/metatx/ERC2771Context.sol";
-import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
-import {SafeERC20} from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
-import {mulDiv} from "@prb/math/src/Common.sol";
-
-// Local: abstract contracts
-import {JBPermissioned} from "./abstract/JBPermissioned.sol";
-
-// Local: interfaces (alphabetized)
-import {IJBController} from "./interfaces/IJBController.sol";
-import {IJBDirectory} from "./interfaces/IJBDirectory.sol";
-import {IJBMultiTerminal} from "./interfaces/IJBMultiTerminal.sol";
-
-// Local: libraries (alphabetized)
-import {JBConstants} from "./libraries/JBConstants.sol";
-import {JBFees} from "./libraries/JBFees.sol";
-
-// Local: structs (alphabetized)
-import {JBAccountingContext} from "./structs/JBAccountingContext.sol";
-import {JBSplit} from "./structs/JBSplit.sol";
-```
-
-## Contract Structure
-
-Section banners divide the contract into a fixed ordering. Every contract with 50+ lines uses these banners:
-
-```solidity
-/// @notice One-line description.
-contract JBExample is JBPermissioned, IJBExample {
-    // A library that does X.
-    using SomeLib for SomeType;
-
-    //*********************************************************************//
-    // --------------------------- custom errors ------------------------- //
-    //*********************************************************************//
-
-    error JBExample_SomethingFailed(uint256 amount);
-
-    //*********************************************************************//
-    // ------------------------- public constants ------------------------ //
-    //*********************************************************************//
-
-    uint256 public constant override FEE = 25;
-
-    //*********************************************************************//
-    // ----------------------- internal constants ------------------------ //
-    //*********************************************************************//
-
-    uint256 internal constant _FEE_BENEFICIARY_PROJECT_ID = 1;
-
-    //*********************************************************************//
-    // ------------------------ private constants ------------------------ //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // --------------- public immutable stored properties ---------------- //
-    //*********************************************************************//
-
-    IJBDirectory public immutable override DIRECTORY;
-
-    //*********************************************************************//
-    // -------------- internal immutable stored properties -------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // --------------------- public stored properties -------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // -------------------- internal stored properties ------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // -------------------- private stored properties -------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ------------------- transient stored properties ------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // -------------------------- constructor ---------------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ---------------------------- modifiers ---------------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ------------------------- receive / fallback ---------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ---------------------- external transactions ---------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ----------------------- external views ---------------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // -------------------------- public views --------------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ----------------------- public transactions ----------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ---------------------- internal transactions ---------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ----------------------- internal helpers -------------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ----------------------- internal views ---------------------------- //
-    //*********************************************************************//
-
-    //*********************************************************************//
-    // ----------------------- private helpers --------------------------- //
-    //*********************************************************************//
-}
-```
-
-**Section order:**
-1. Custom errors
-2. Public constants
-3. Internal constants
-4. Private constants
-5. Public immutable stored properties
-6. Internal immutable stored properties
-7. Public stored properties
-8. Internal stored properties
-9. Private stored properties
-10. Transient stored properties
-11. Constructor
-12. Modifiers
-13. Receive / fallback
-14. External transactions
-15. External views
-16. Public views
-17. Public transactions
-18. Internal transactions
-19. Internal helpers
-20. Internal views
-21. Private helpers
-
-Use these additional section labels where they better match the contents of the block:
-- `internal functions` is accepted as equivalent to `internal helpers`
-- `events` and `structs` are acceptable in specialized contracts that define them explicitly
-
-Functions are alphabetized within each section.
-
-## Interface Structure
-
-```solidity
-/// @notice One-line description.
-interface IJBExample is IJBBase {
-    // Events (with full NatSpec)
-
-    /// @notice Emitted when X happens.
-    /// @param projectId The ID of the project.
-    /// @param amount The amount transferred.
-    event SomethingHappened(uint256 indexed projectId, uint256 amount);
-
-    // Views (alphabetized)
-
-    /// @notice The directory of terminals and controllers.
-    function DIRECTORY() external view returns (IJBDirectory);
-
-    // State-changing functions (alphabetized)
-
-    /// @notice Does the thing.
-    /// @param projectId The ID of the project.
-    /// @return result The result.
-    function doThing(uint256 projectId) external returns (uint256 result);
-}
-```
-
-**Rules:**
-- Events first, then views, then state-changing functions
-- No custom errors in interfaces — errors belong in the implementing contract
-- Full NatSpec on every event, function, and parameter
-- Alphabetized within each group
-
-## Naming
-
-| Thing | Convention | Example |
-|-------|-----------|---------|
-| Contract | PascalCase | `JBMultiTerminal` |
-| Interface | `I` + PascalCase | `IJBMultiTerminal` |
-| Library | PascalCase | `JBCashOuts` |
-| Struct | PascalCase | `JBRulesetConfig` |
-| Enum | PascalCase | `JBApprovalStatus` |
-| Enum value | PascalCase | `ApprovalExpected` |
-| Error | `ContractName_ErrorName` | `JBMultiTerminal_FeeTerminalNotFound` |
-| Public constant | `ALL_CAPS` | `FEE`, `MAX_FEE` |
-| Internal constant | `_ALL_CAPS` | `_FEE_HOLDING_SECONDS` |
-| Public immutable | `ALL_CAPS` | `DIRECTORY`, `PERMISSIONS` |
-| Public/external function | `camelCase` | `cashOutTokensOf` |
-| Internal/private function | `_camelCase` | `_processFee` |
-| Internal storage | `_camelCase` | `_accountingContextForTokenOf` |
-| Function parameter | `camelCase` (no underscores) | `projectId`, `cashOutCount` |
-
-## NatSpec
-
-**Contracts:**
-```solidity
-/// @notice One-line description of what the contract does.
-contract JBExample is IJBExample {
-```
-
-**Functions:**
-```solidity
-/// @notice Records funds being added to a project's balance.
-/// @param projectId The ID of the project which funds are being added to.
-/// @param token The token being added.
-/// @param amount The amount added, as a fixed point number with the same decimals as the terminal.
-/// @return surplus The new surplus after adding.
-function recordAddedBalanceFor(
-    uint256 projectId,
-    address token,
-    uint256 amount
-) external override returns (uint256 surplus) {
-```
-
-**Structs:**
-```solidity
-/// @custom:member duration The number of seconds the ruleset lasts for. 0 means it never expires.
-/// @custom:member weight How many tokens to mint per unit paid (18 decimals).
-/// @custom:member weightCutPercent How much weight decays each cycle (9 decimals).
-struct JBRulesetConfig {
-    uint32 duration;
-    uint112 weight;
-    uint32 weightCutPercent;
-}
-```
-
-**Mappings:**
-```solidity
-/// @notice Context describing how a token is accounted for by a project.
-/// @custom:param projectId The ID of the project.
-/// @custom:param token The address of the token.
-mapping(uint256 projectId => mapping(address token => JBAccountingContext)) internal _accountingContextForTokenOf;
-```
-
-## Numbers
-
-Use underscores for thousands separators:
-
-```solidity
-uint256 internal constant _FEE_HOLDING_SECONDS = 2_419_200; // 28 days
-uint32 public constant MAX_WEIGHT_CUT_PERCENT = 1_000_000_000;
-uint256 public constant MAX_RESERVED_PERCENT = 10_000;
-```
-
-## Function Calls
-
-Use named arguments for all function calls with 2 or more arguments — in both `src/` and `script/`:
-
-```solidity
-// Good — named arguments
-token.mint({account: beneficiary, amount: count});
-_transferOwnership({newOwner: address(0), projectId: 0});
-PERMISSIONS.hasPermission({
-    operator: sender,
-    account: account,
-    projectId: projectId,
-    permissionId: permissionId,
-    includeRoot: true,
-    includeWildcardProjectId: true
-});
-
-// Bad — positional arguments with 2+ args
-token.mint(beneficiary, count);
-_transferOwnership(address(0), 0);
-```
-
-Single-argument calls use positional style: `_burn(amount)`.
-
-This also applies to constructor calls, struct literals, and inherited/library calls (e.g., OZ `_mint`, `_safeMint`, `safeTransfer`, `allowance`, `Clones.cloneDeterministic`).
-
-Named argument keys must use **camelCase** — never underscores. If a function's parameter names use underscores, rename them to camelCase first.
-
-## Multiline Signatures
-
-```solidity
-function recordCashOutFor(
-    address holder,
-    uint256 projectId,
-    uint256 cashOutCount,
-    JBAccountingContext calldata accountingContext
-)
-    external
-    override
-    returns (
-        JBRuleset memory ruleset,
-        uint256 reclaimAmount,
-        JBCashOutHookSpecification[] memory hookSpecifications
-    )
-{
-```
-
-Modifiers and return types go on their own indented lines.
-
-## Error Handling
-
-- Validate inputs with explicit `revert` + custom error
-- Use `try-catch` only for external calls to untrusted contracts (hooks, fee processing)
-- Always include relevant context in error parameters
-
-```solidity
-// Direct validation
-if (amount > limit) revert JBTerminalStore_InadequateControllerPayoutLimit(amount, limit);
-
-// External call to untrusted hook
-try hook.afterPayRecordedWith(context) {} catch (bytes memory reason) {
-    emit HookAfterPayReverted(hook, context, reason, _msgSender());
-}
-```
-
----
-
-## DevOps
-
-### foundry.toml
-
-Standard config across all repos:
-
-```toml
-[profile.default]
-solc = '0.8.28'
-evm_version = 'cancun'
-optimizer_runs = 200
-libs = ["node_modules", "lib"]
-fs_permissions = [{ access = "read-write", path = "./"}]
-
-[fuzz]
-runs = 4096
-
-[invariant]
-runs = 1024
-depth = 100
-fail_on_revert = false
-
-[fmt]
-number_underscore = "thousands"
-multiline_func_header = "all"
-wrap_comments = true
-```
-
-**Optional sections (add only when needed):**
-- `[rpc_endpoints]` — repos with fork tests. Maps named endpoints to env vars (e.g. `ethereum = "${RPC_ETHEREUM_MAINNET}"`).
-- `[profile.ci_sizes]` — only when CI needs different optimizer settings than defaults for the size check step (e.g. `optimizer_runs = 200` when the default profile uses a lower value).
-
-**Common variations:**
-- `via_ir = true` when hitting stack-too-deep
-- `optimizer = false` when optimization causes stack-too-deep
-- `optimizer_runs` reduced when deep struct nesting causes stack-too-deep at 200 runs
-
-### CI Workflows
-
-Every repo has at minimum `test.yml` and `lint.yml`:
-
-**test.yml:**
-```yaml
-name: test
-on:
-  pull_request:
-    branches: [main]
-  push:
-    branches: [main]
-jobs:
-  forge-test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          submodules: recursive
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 25.9.0
-      - name: Install npm dependencies
-        run: npm install --omit=dev
-      - name: Install Foundry
-        uses: foundry-rs/foundry-toolchain@v1
-      - name: Run tests
-        run: forge test --fail-fast --summary --detailed --skip "*/script/**"
-        env:
-          RPC_ETHEREUM_MAINNET: ${{ secrets.RPC_ETHEREUM_MAINNET }}
-      - name: Check contract sizes
-        run: forge build --sizes --skip "*/test/**" --skip "*/script/**" --skip SphinxUtils
-```
-
-**lint.yml:**
-```yaml
-name: lint
-on:
-  pull_request:
-    branches: [main]
-  push:
-    branches: [main]
-jobs:
-  forge-fmt:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - name: Install Foundry
-        uses: foundry-rs/foundry-toolchain@v1
-      - name: Check formatting
-        run: forge fmt --check
-```
-
-**Static review workflow** (repos with `src/` contracts only):
-
-Keep repo-local static review automation current with the package's runtime surface. At minimum, CI should run formatting, linting, and build checks with `--deny notes`. Repos that only contain deployment scripts can rely on the shared formatting and lint jobs unless they add runtime contracts.
-
-### package.json
-
-```json
-{
-  "name": "@bananapus/package-name-v6",
-  "version": "x.x.x",
-  "license": "MIT",
-  "repository": { "type": "git", "url": "git+https://github.com/Org/repo.git" },
-  "engines": { "node": ">=20.0.0" },
-  "scripts": {
-    "test": "forge test",
-    "coverage": "forge coverage --match-path \"./src/*.sol\" --report lcov --report summary"
-  },
-  "dependencies": { ... },
-  "devDependencies": {
-    "@sphinx-labs/plugins": "0.33.3"
-  }
-}
-```
-
-**Scoping:** `@bananapus/` for Bananapus repos, `@rev-net/` for revnet, `@croptop/` for croptop, `@bannynet/` for banny, `@ballkidz/` for defifa.
-
-### remappings.txt
-
-Every repo has a `remappings.txt` as the **single source of truth** for import remappings. Never add remappings to `foundry.toml`.
-
-**Principle:** Import paths in Solidity source must match npm package names exactly. With `libs = ["node_modules", "lib"]`, Foundry auto-resolves `@scope/package/path/File.sol` → `node_modules/@scope/package/path/File.sol`. No remapping needed for packages installed as real directories.
-
-**Note:** Auto-resolution does **not** work for symlinked packages (e.g. npm workspace links). Workspace repos like `deploy-all-v6` and `nana-cli-v6` need explicit `@scope/package/=node_modules/@scope/package/` remappings for each symlinked dependency.
-
-**Minimal content** (most repos):
-
-```
-forge-std/=lib/forge-std/src/
-```
-
-Only add extra remappings for:
-- **`forge-std`** — always needed (git submodule with `src/` subdirectory)
-- **Repo-specific `lib/` submodules** that have no npm package (e.g., `hookmate/=lib/hookmate/src/`)
-- **Symlinked npm packages** — need explicit `@scope/package/=node_modules/@scope/package/` entries
-- **Nested transitive deps** — e.g., `@chainlink/contracts-ccip/` nested inside `@bananapus/suckers-v6/node_modules/`
-
-**Never add remappings for:**
-- npm packages that match their import path and are installed as real directories — they auto-resolve
-- Short-form aliases (e.g., `@bananapus/core/` → `@bananapus/core-v6/src/`) — fix the import instead
-- Packages available via npm that are also git submodules — remove the submodule, use npm
-
-**Import path convention:**
-
-| Package | Import path | Resolves to |
-|---------|------------|-------------|
-| `@bananapus/core-v6` | `@bananapus/core-v6/src/libraries/JBConstants.sol` | `node_modules/@bananapus/core-v6/src/...` |
-| `@openzeppelin/contracts` | `@openzeppelin/contracts/token/ERC20/IERC20.sol` | `node_modules/@openzeppelin/contracts/...` |
-| `@uniswap/v4-core` | `@uniswap/v4-core/src/interfaces/IPoolManager.sol` | `node_modules/@uniswap/v4-core/src/...` |
-
-### Linting
-
-Solar (Foundry's built-in linter) runs automatically during `forge build`. It scans all `.sol` files in `libs` directories, including `node_modules`.
-
-**All test helpers must use relative imports** (e.g. `../../src/structs/JBRuleset.sol`), not bare `src/` imports. This ensures solar can resolve paths when the helper is consumed via npm in downstream repos.
-
-### Fork Tests
-
-Fork tests use named RPC endpoints defined in `[rpc_endpoints]` of `foundry.toml`. No skip guards — fork tests should hard-fail if the RPC endpoint is unavailable, making CI failures explicit.
-
-```solidity
-function setUp() public {
-    vm.createSelectFork("ethereum");
-    // ... setup code
-}
-```
-
-The endpoint name (e.g. `"ethereum"`) maps to an env var via `foundry.toml`:
-
-```toml
-[rpc_endpoints]
-ethereum = "${RPC_ETHEREUM_MAINNET}"
-```
-
-For multi-chain fork tests, add all needed endpoints.
-
-### Formatting
-
-Run `forge fmt` before committing. The `[fmt]` config in `foundry.toml` enforces:
-- Thousands separators on numbers (`1_000_000`)
-- Multiline function headers when multiple parameters
-- Wrapped comments at reasonable width
-
-CI checks formatting via `forge fmt --check`.
-
-### Branching
-
-- `main` is the primary branch
-- Feature branches for PRs
-- All PRs trigger test + lint workflows
-- Submodule checkout with `--recursive` in CI
-
-### Dependencies
-
-- Solidity dependencies via npm (`node_modules/`)
-- `forge-std` as a git submodule in `lib/`
-- Sphinx plugins as a devDependency
-- Cross-repo references use `file:../sibling-repo` in local development
-- Published versions use semver ranges (`^0.0.x`) for npm
-
-### Contract Size Checks
-
-CI runs `forge build --sizes` to catch contracts approaching the 24KB limit. When the repo's default `optimizer_runs` differs from what you want for size checking, use `FOUNDRY_PROFILE=ci_sizes forge build --sizes` with a `[profile.ci_sizes]` section in `foundry.toml`.

package/USER_JOURNEYS.md

@@ -1,103 +0,0 @@
-# User Journeys
-
-## Repo Purpose
-
-This repo is the shared permission vocabulary for the V6 ecosystem. It does not store permissions or enforce them at runtime. It defines the constants that downstream repos should import so permissioned behavior stays clear and consistent.
-
-## Primary Actors
-
-- engineers choosing which permission constant should guard a feature
-- auditors checking whether a repo drifted from the shared vocabulary
-- maintainers extending the permission map without numeric collisions
-
-## Key Surfaces
-
-- `JBPermissionIds`: library of canonical permission constants used across V6 repos
-- grouped constants for core, 721, router, buyback, sucker, revnet, and related actions
-- reserved ranges documented in `README.md`, including `ROOT = 1`, currently assigned ecosystem IDs through `39`, unassigned ID `40`, and socially coordinated extension space above that
-
-## Journey 1: Map A Product Action To The Right Permission
-
-**Actor:** downstream engineer.
-
-**Intent:** protect an action with the canonical permission constant instead of inventing a local number.
-
-**Preconditions**
-- the action is governed by `JBPermissions`
-- the engineer knows which repo or domain owns the action
-
-**Main Flow**
-1. Find the action domain in `JBPermissionIds`, such as core, 721, router, buyback, or sucker permissions.
-2. Import the constant into the downstream repo.
-3. Use that constant in the runtime authorization check.
-4. Treat bundled high-impact IDs like `SET_BUYBACK_HOOK` and `SET_ROUTER_TERMINAL` as broader powers than their short names suggest because they also gate locking.
-
-**Failure Modes**
-- the repo hardcodes a number locally and drifts from the shared vocabulary
-- a repo picks the wrong existing constant because the action sounds similar but is not actually equivalent
-- a team grants `ROOT` or wildcard permissions without appreciating the blast radius
-- docs and tests describe a permission by nickname instead of the imported constant
-
-**Postconditions**
-- the downstream action is guarded by the shared permission vocabulary instead of a local numeric convention
-
-## Journey 2: Review An Existing Operator Setup
-
-**Actor:** auditor, operator, or integrator.
-
-**Intent:** decode opaque permission bits into named actions.
-
-**Preconditions**
-- the operator bitset or granted permission IDs are already known
-- the reviewer understands that this repo names permissions but does not prove how each repo uses them
-
-**Main Flow**
-1. Start with the permission bits granted on the project.
-2. Map each bit to its named constant here.
-3. Confirm the downstream repo still uses that constant consistently in authorization checks and docs.
-4. Check whether any granted IDs are really funds-moving, routing, locking, or loan-management powers rather than low-risk admin toggles.
-
-**Failure Modes**
-- downstream code reuses a permission ID for a different meaning
-- reviewers decode the bit correctly but underestimate what the downstream repo lets that permission do
-- reviewers rely on this repo alone and skip the guarded code
-
-**Postconditions**
-- the reviewer has a named permission map and knows which downstream repos still need inspection
-
-## Journey 3: Add A New Ecosystem Surface Without Permission Drift
-
-**Actor:** maintainer extending the permission vocabulary.
-
-**Intent:** add a new permission constant that the rest of the ecosystem can reuse.
-
-**Preconditions**
-- no existing constant already matches the new action
-- the maintainer understands the numeric ranges already in use
-
-**Main Flow**
-1. Choose the next unused ID in the relevant range.
-2. Add the named constant in `JBPermissionIds.sol`.
-3. Update downstream repos to import the constant instead of duplicating the number.
-4. Refresh docs and tests that explain the permission.
-5. If the new ID goes above the ecosystem-managed range, coordinate externally so third-party packages do not collide on the same number.
-
-**Failure Modes**
-- a new repo defines its own numeric constant first and creates drift
-- a new constant is added in the wrong semantic range, making later review harder
-- a new ID silently expands what existing `ROOT` operators can do without that blast radius being reviewed
-- documentation updates lag behind the code change
-
-**Postconditions**
-- the new ecosystem surface has a reusable canonical permission ID with coordinated downstream adoption
-
-## Trust Boundaries
-
-- this repo is trusted only as shared vocabulary
-- actual storage and enforcement live elsewhere
-- downstream repos can still misuse a constant even when they import the right one
-
-## Hand-Offs
-
-- Use [nana-core-v6](../nana-core-v6/USER_JOURNEYS.md) for the runtime permission registry that stores and checks these IDs.
-- Use the relevant downstream repo when the question is about what a permissioned action does after authorization succeeds.

package/foundry.lock

@@ -1,5 +0,0 @@
-{
-  "lib/forge-std": {
-    "rev": "ae570fec082bfe1c1f45b0acca4a2b4f84d345ce"
-  }
-}

package/test/formal/JBPermissionIdsHalmos.t.sol

@@ -1,68 +0,0 @@
-// SPDX-License-Identifier: MIT
-pragma solidity 0.8.28;
-
-import {JBPermissionIds} from "../../src/JBPermissionIds.sol";
-
-/// @notice Small Halmos entrypoints for the ecosystem permission namespace.
-/// @dev This package is constants-only, so the useful machine-check is exact namespace drift: values must remain
-/// contiguous from ROOT through REPAY_LOAN unless a future migration intentionally updates this proof.
-contract JBPermissionIdsHalmos {
-    /// @notice Proves the permission IDs are exactly the expected contiguous sequence.
-    function check_permissionIdsAreContiguousAndStable() public pure {
-        uint8[39] memory ids = [
-            JBPermissionIds.ROOT,
-            JBPermissionIds.QUEUE_RULESETS,
-            JBPermissionIds.LAUNCH_RULESETS,
-            JBPermissionIds.CASH_OUT_TOKENS,
-            JBPermissionIds.SEND_PAYOUTS,
-            JBPermissionIds.MIGRATE_TERMINAL,
-            JBPermissionIds.SET_PROJECT_URI,
-            JBPermissionIds.DEPLOY_ERC20,
-            JBPermissionIds.SET_TOKEN,
-            JBPermissionIds.MINT_TOKENS,
-            JBPermissionIds.BURN_TOKENS,
-            JBPermissionIds.CLAIM_TOKENS,
-            JBPermissionIds.TRANSFER_CREDITS,
-            JBPermissionIds.SET_CONTROLLER,
-            JBPermissionIds.SET_TERMINALS,
-            JBPermissionIds.ADD_TERMINALS,
-            JBPermissionIds.SET_PRIMARY_TERMINAL,
-            JBPermissionIds.USE_ALLOWANCE,
-            JBPermissionIds.SET_SPLIT_GROUPS,
-            JBPermissionIds.ADD_PRICE_FEED,
-            JBPermissionIds.ADD_ACCOUNTING_CONTEXTS,
-            JBPermissionIds.SET_TOKEN_METADATA,
-            JBPermissionIds.SIGN_FOR_ERC20,
-            JBPermissionIds.ADJUST_721_TIERS,
-            JBPermissionIds.SET_721_METADATA,
-            JBPermissionIds.MINT_721,
-            JBPermissionIds.SET_721_DISCOUNT_PERCENT,
-            JBPermissionIds.SET_BUYBACK_TWAP,
-            JBPermissionIds.SET_BUYBACK_POOL,
-            JBPermissionIds.SET_BUYBACK_HOOK,
-            JBPermissionIds.SET_ROUTER_TERMINAL,
-            JBPermissionIds.MAP_SUCKER_TOKEN,
-            JBPermissionIds.DEPLOY_SUCKERS,
-            JBPermissionIds.SET_SUCKER_PEER,
-            JBPermissionIds.SUCKER_SAFETY,
-            JBPermissionIds.SET_SUCKER_DEPRECATION,
-            JBPermissionIds.OPEN_LOAN,
-            JBPermissionIds.REALLOCATE_LOAN,
-            JBPermissionIds.REPAY_LOAN
-        ];
-
-        for (uint256 i; i < ids.length;) {
-            assert(ids[i] == i + 1);
-
-            unchecked {
-                ++i;
-            }
-        }
-    }
-
-    /// @notice Proves the first and final IDs stay pinned to the documented namespace bounds.
-    function check_permissionNamespaceBounds() public pure {
-        assert(JBPermissionIds.ROOT == 1);
-        assert(JBPermissionIds.REPAY_LOAN == 39);
-    }
-}