docs(fast-inbox): document message-prefix consumption and correct the streaming Inbox docs

barretenberg/.claude/skills/gate-counts/SKILL.md

@@ -220,11 +220,13 @@ AZTEC_GENERATE_TEST_DATA=1 \
   yarn workspace @aztec/prover-client test regenerate_rollup_sample_inputs
 ```
 
-Regenerates `Prover.toml` for `rollup-block-root-first-empty-tx`,
-`rollup-block-root-first`, `rollup-block-root-first-single-tx`,
-`rollup-block-root`, `rollup-block-root-single-tx`, `rollup-block-root-msgs-only`,
-`rollup-block-merge`, `rollup-checkpoint-root`, `rollup-checkpoint-root-single-block`,
-`rollup-checkpoint-merge`, `rollup-tx-merge`, `rollup-root`.
+Regenerates the `Prover.toml` of every block-root variant plus the block-merge,
+checkpoint-root, checkpoint-merge, tx-merge and root circuits. Read the exact
+inventory off the `dump` fields of the `scenarios` array in
+`yarn-project/prover-client/src/test/regenerate_rollup_sample_inputs.test.ts`
+rather than from a list here: each scenario declares which circuits it is
+responsible for, and the set changes whenever a block-root variant is added or
+removed.
 
 **Private-kernel + transaction-base circuits — e2e prover full test** (spins up
 an L1/anvil sandbox):

barretenberg/.claude/skills/update-prover-toml/SKILL.md

@@ -31,7 +31,7 @@ Two commands cover the protocol-circuit tomls, split by whether the sample needs
 AZTEC_GENERATE_TEST_DATA=1 yarn workspace @aztec/prover-client test regenerate_rollup_sample_inputs
 ```
 
-Regenerates: `rollup-block-root-first-empty-tx`, `rollup-block-root-first`, `rollup-block-root-first-single-tx`, `rollup-block-root`, `rollup-block-root-single-tx`, `rollup-block-root-msgs-only`, `rollup-block-merge`, `rollup-checkpoint-root`, `rollup-checkpoint-root-single-block`, `rollup-checkpoint-merge`, `rollup-tx-merge`, `rollup-root`. The scenario list lives in the `scenarios` array in that test; each scenario's `dump` field names the tomls it owns.
+Regenerates every block-root variant plus the block-merge, checkpoint-root, checkpoint-merge, tx-merge and root tomls. Take the exact inventory from the `scenarios` array in that test rather than from a list here: each scenario's `dump` field names the tomls it owns, and the set changes whenever a block-root variant is added or removed.
 
 ### Private-kernel and transaction-base circuits — e2e prover full test
 

docs/docs-developers/docs/aztec-js/aztec_js_reference.md

@@ -16,7 +16,7 @@ This is an auto-generated reference. For tutorials and guides, see the [Aztec.js
 
 *Package: @aztec/aztec.js*
 
-*Generated: 2026-08-19T09:19:51.719Z*
+*Generated: 2026-09-10T04:03:25.794Z*
 
 This document provides a comprehensive reference for all public APIs in the Aztec.js library.
 
@@ -4682,7 +4682,7 @@ public override send(options?: Omit<SendInteractionOptions<InteractionWaitOption
 
 **Type:** Function
 
-Waits for the L1 to L2 message to be ready to be consumed.
+Waits for the L1 to L2 message to be ready to be consumed, that is, for a block that already exists to have inserted it into the message tree at the given tip. This is a check on the chain as it stands, not a promise about a future block: a node simulating public calls may optimistically include messages that are still only in the Inbox, and the block that eventually inserts them can stop short of the one being waited for.
 
 **Signature:**
 
@@ -4727,7 +4727,7 @@ export waitForL1ToL2MessageReady(
 
 **Type:** Function
 
-Returns whether the L1 to L2 message is ready to be consumed.
+Returns whether the L1 to L2 message is ready to be consumed: whether a block at `chainTip` has already inserted it into the message tree. A message that is in the Inbox but not yet in any block is not ready, even though a node may already simulate public calls against it; use this rather than a successful simulation when a caller needs to know the message is really there.
 
 **Signature:**
 

docs/docs-developers/docs/aztec-nr/framework-description/ethereum_aztec_messaging.md

@@ -31,7 +31,7 @@ Use the `Inbox` contract's `sendL2Message` function:
 #include_code deposit_public l1-contracts/test/portals/TokenPortal.sol solidity
 
 :::note Message availability
-L1 to L2 messages are not available immediately. The proposer batches messages from the Inbox and includes them in the next L2 block. You must wait for this before consuming the message on L2.
+L1 to L2 messages are not available the moment the L1 transaction is mined. Messages the proposer's node has observed on L1 are eligible for the next L2 block it builds, subject to the per-block and per-checkpoint message caps; near the end of a checkpoint, consumption stops at an Inbox bucket boundary and later messages wait for the next checkpoint. You must wait for a block containing the message before consuming it on L2. Public functions can consume a message in the block that inserts it; private functions prove membership against a block header the wallet has synced, so they additionally wait for that block to reach the wallet. See [Inbox](../../foundational-topics/ethereum-aztec-messaging/inbox.md#how-messages-reach-l2) for how consumption works.
 :::
 
 ### Consume the message on L2