Predict predeploy docs and audit tracker consolidation

.claude/rules/code-review.md

@@ -7,7 +7,7 @@ Read this manual-trigger file when the user asks for a code review. It is routed
 - When the user asks to "review uncommitted changes" or "review uncomitted changes", review the full working-tree diff.
 - For Move reviews, also read `.claude/rules/move.md` and `.claude/rules/unit-tests.md`.
 - **Deep Predict smart-contract audit.** This flat checklist is the quick pass. For a deep audit of the Predict contracts (predict + propbook + block_scholes_oracle + account), invoke the **`predict-audit`** skill (`.claude/skills/predict-audit/`): read its `primer.md` (orientation + current module map + finding format) and the relevant `lenses/NN-*.md` (`01-invariants`, `02-adversarial-audit`, `03-oracle-pricing-numerical`, `04-access-control`, `05-surface-area`, `06-assertions`, `07-lifecycle`, `08-cross-package-trust`, `09-economic-simulation`, `10-architecture-maintainability`), or launch its `orchestrator.workflow.js` (lens fan-out), `ownership-walk.workflow.js` (per-module ownership/boundary/policy conformance, R1–R7), or `rule-sweep.workflow.js` (per-rule mechanical sweep). Emit findings in the primer's Severity / Location / Claim / Scenario / Impact / Confidence / Recommendation format.
-- Treat design docs (`.redesign/`, `.claude/predict-design/`) as **leads to verify against current HEAD**, not ground truth — verify every load-bearing claim against Move source + git + `sui move test`.
+- Treat design/research docs (`packages/predict/predeploy/`, `.redesign/`, `.claude/predict-design/`) as **leads to verify against current HEAD**, not ground truth — verify every load-bearing claim against Move source + git + `sui move test`.
 - Findings should focus on correctness, regressions, missing coverage, and brittle assumptions.
 - Say whether the diff is safe as a standalone PR or only as an intermediate step that requires follow-up work in the same branch.
 

.claude/rules/move.md

@@ -211,9 +211,9 @@ Then call as `self.id.exists_(key)`, `self.id.add(key, value)`, `self.id.borrow(
 
 ### Predict Gas & Capacity
 
-Measured localnet capacity findings (2026-06 audit; full detail in `.claude/predict-design/audit/` + `.claude/predict-review/OPEN-ITEMS.md`). Respect them when touching the flush / NAV / liquidation paths.
-- **The full-pool flush is ONE mandatory PTB** (`PoolValuation` is a hot potato) that values EVERY active market, and `value_expiry`→`correction_value` is an *unbounded* per-leveraged-order walk. The per-market caps (24 markets / 1,000 nodes / 5,000 leveraged) are set INDEPENDENTLY with no joint gas budget, so together they exceed the ~5M computation wall: a single market bricks the flush WELL BELOW its own 5,000 cap (data-dependent; the measured order-count range lives in `.claude/rules/predict-simulations.md`, the gas-analysis home — don't restate it here), freezing all PLP supply/withdraw. Any new growth-sensitive per-market cap must be checked against `Σ_markets` under the wall, not in isolation.
-- **A batched leveraged mint/redeem amplifies the per-op cost vs standalone (measured ~15-20× at a saturated book, replicated across 2 runs; a PTB of ~110-150 leveraged mints OOGs the 5e9 cap — data-dependent on book, and a 100-mint PTB is ~3.4B = 68% of the cap).** The mechanism is per-TRANSACTION metering / command-position accumulation, NOT liq-book dirtying: a leveraged mint appended after 20 *1x* mints — which never touch the liquidation book (`insert_order` is a no-op for 1x) — is amplified just as much (more, by position), so the cost scales with command POSITION / accumulated tx state, not with prior `insert_order` writes to `book.pages` (harness `mint-batch` experiment, `.claude/predict-design/MINT_BATCH_FINDINGS_2026-07-01.md`; this REFUTES the earlier "dirtied dynamic fields" claim). `range_price` (`select_liquidation_candidates`) is pure math. Don't assume an op's standalone cost holds when batched — and the ceiling binds ANY large multi-command PTB, not just scan-heavy ops.
+Measured localnet capacity findings live in `packages/predict/predeploy/stress/`. Respect them when touching the flush / NAV / liquidation paths.
+- **The full-pool flush is ONE mandatory PTB** (`PoolValuation` is a hot potato) that values EVERY active market. The landed NAV price memo made the single-market 5,000 leveraged-order cap safe in the measured cheap branch (~2.36-2.68B MIST, ~47-54% of the wall), but the independent caps (24 markets / 1,000 nodes / 5,000 leveraged) still do not compose: the pool-total case OOGed around 8.6k leveraged orders across ~9 markets before a clean gas-only boundary was isolated. Any new growth-sensitive cap must be checked against `Σ_markets` under the ~5M computation wall, not in isolation.
+- **A batched leveraged mint/redeem amplifies the per-op cost vs standalone (measured ~15-20× at a saturated book, replicated across 2 runs; a PTB of ~110-150 leveraged mints OOGs the 5e9 cap — data-dependent on book, and a 100-mint PTB is ~3.4B = 68% of the cap).** The mechanism is per-TRANSACTION metering / command-position accumulation, NOT liq-book dirtying: a leveraged mint appended after 20 *1x* mints — which never touch the liquidation book (`insert_order` is a no-op for 1x) — is amplified just as much (more, by position), so the cost scales with command POSITION / accumulated tx state, not with prior `insert_order` writes to `book.pages` (harness `mint-batch` experiment, `packages/predict/predeploy/stress/mint-batch-findings-2026-07-01.md`; this REFUTES the earlier "dirtied dynamic fields" claim). `range_price` (`select_liquidation_candidates`) is pure math. Don't assume an op's standalone cost holds when batched — and the ceiling binds ANY large multi-command PTB, not just scan-heavy ops.
 - **`lp_pool_value` floors at 0** (`gross.saturating_sub(exclusion + pending_protocol_profit)`); when the sticky profit basis exceeds a collapsed gross it returns 0, and `supply_shares`/`withdraw_dusdc` then abort `EInvalidDrainMark` — a supply/withdraw brick. Treat NAV==0 as a real reachable state, not just an underflow guard.
 
 ## General Move Patterns

.claude/rules/predict-harness.md

@@ -128,4 +128,4 @@ user-facing overview; this file is the editing-critical knowledge.
   `gasOf`) against that cap; the flush's `InsufficientGas` deferral at that book size is the
   nav-stress BREAKPOINT (the measurement) and is excluded from the oracle — don't reintroduce a
   gas-budget ceiling (it both mis-reports the breakpoint and false-flags the OOGs as bugs). See
-  `.claude/predict-design/NAV_STRESS_FINDINGS_2026-06-30.md`.
+  `packages/predict/predeploy/stress/nav-stress-findings-2026-06-30.md`.

.claude/rules/predict-simulations.md

@@ -13,8 +13,8 @@ Before editing `packages/predict/simulations/**`, read:
 
 - Gas verdicts must respect the simulation determinism caveat: different `run.sh` invocations use different generated scenarios, so treat per-action deltas below the run-to-run noise floor (watch an untouched action like `supply`/`withdraw`) as neutral. Only a pinned-scenario A/B gives a trustworthy signal.
 - **The wall is computation, not gas budget.** A tx over `max_gas_computation_bucket` (~5,000,000 computation units on localnet protocol v127; `computationCost_MIST = units × RGP(1000)`) fails with `InsufficientGas` regardless of `--gas-budget`. Capacity OOGs are this wall, not the budget.
-- **Per-op gas can be data-dependent.** `range_price`→`normal_cdf` (fixed_math) has cheap (`|d2|>8` constant, `|d2|<SMALL` ~6 Horner) vs expensive (`SMALL..MEDIUM` d2 → `exp_series`) branches, so the SAME op costs ~3-4× more at some strike/forward/SVI than others (e.g. the single-market flush OOGs anywhere from ~1,400 to ~4,900 leveraged orders depending on the oracle state). A single pinned A/B can mislead — sweep multiple random scenarios (`stress/`) before trusting a per-op gas number.
-- **Multi-command PTBs amplify liquidation-book scans.** Each batched mint/redeem re-walks the paged liquidation book via `Table` (dynamic-field) reads; prior commands' `insert_order`s dirty those pages, so per-candidate scan cost inflates ~45× vs a standalone op (~30→~1,360 units), making a batched leveraged op ≈ 13× a standalone one. Measure batched ops separately; never extrapolate from a single-op number.
+- **Per-op gas can be data-dependent.** `range_price`→`normal_cdf` (fixed_math) has cheap (`|d2|>8` constant, `|d2|<SMALL` ~6 Horner) vs expensive (`SMALL..MEDIUM` d2 → `exp_series`) branches, so the SAME pricing eval costs materially more at some strike/forward/SVI than others. The landed NAV price memo removed the pre-memo single-market flush OOG cliff: one market at 5,000 leveraged orders measured ~47-54% of the wall. The remaining capacity question is pool-total and moneyness-sensitive — sweep multiple random scenarios (`stress/`) before trusting a per-op gas number.
+- **Multi-command PTBs amplify per-command work.** Batched mint/redeem PTBs are much more expensive than standalone ops, but the 2026-07-01 `mint-batch` discriminator refuted the earlier dirtied-liquidation-book-page explanation: a leveraged mint appended after many 1x mints (which never write the liquidation book) is amplified too. Treat this as command-position / accumulated-transaction-state metering, measure batched ops separately, and never extrapolate from a single-op number.
 
 ## Parallel localnet + stress sweeps
 

.claude/rules/unit-tests.md

@@ -277,7 +277,7 @@ contract (and the expected value was derived independently per Rule 1):
 - **Never** re-express the bug as an `expected_failure` of the buggy behavior.
 - **Never** "fix" the contract to make the test pass (that is a separate effort).
 
-Instead: add an entry to the live audit tracker (`.claude/predict-review/OPEN-ITEMS.md`), tag the
+Instead: add an entry to the committed predeploy tracker (`packages/predict/predeploy/open-items.md`), tag the
 test `// KNOWN-FAILING: <id>`, and leave it RED. The tracker is the authoritative
 manifest of expected-failing tests, so a *new* red (a regression) is distinguishable
 from a *known* red. A green-on-first-write suite is suspect; tests are supposed to