diff --git a/framework/cached-packages/src/lib.rs b/framework/cached-packages/src/lib.rs
index 8e8cde056..323969727 100644
--- a/framework/cached-packages/src/lib.rs
+++ b/framework/cached-packages/src/lib.rs
@@ -1,2 +1,5 @@
+// NOTE: Diem generated code does not have
+// recent lint rules introduced in 2024
+#[allow(clippy::doc_lazy_continuation)]
 pub mod libra_framework_sdk_builder;
 pub mod libra_stdlib;
diff --git a/framework/cached-packages/src/libra_framework_sdk_builder.rs b/framework/cached-packages/src/libra_framework_sdk_builder.rs
index be8463587..d20e9b6b8 100644
--- a/framework/cached-packages/src/libra_framework_sdk_builder.rs
+++ b/framework/cached-packages/src/libra_framework_sdk_builder.rs
@@ -12,7 +12,7 @@
 
 #![allow(dead_code)]
 #![allow(unused_imports)]
-#![allow(clippy::too_many_arguments, clippy::doc_lazy_continuation)]
+#![allow(clippy::too_many_arguments)]
 use diem_types::{
     account_address::AccountAddress,
     transaction::{EntryFunction, TransactionPayload},
@@ -94,7 +94,8 @@ pub enum EntryFunctionCall {
 
     /// Generic authentication key rotation function that allows the user to rotate their authentication key from any scheme to any scheme.
     /// To authorize the rotation, we need two signatures:
-    /// - the first signature `cap_rotate_key` refers to the signature by the account owner's current key on a valid `RotationProofChallenge`,demonstrating that the user intends to and has the capability to rotate the authentication key of this account;
+    /// - the first signature `cap_rotate_key` refers to the signature by the account owner's current key on a valid `RotationProofChallenge`,
+    /// demonstrating that the user intends to and has the capability to rotate the authentication key of this account;
     /// - the second signature `cap_update_table` refers to the signature by the new key (that the account owner wants to rotate to) on a
     /// valid `RotationProofChallenge`, demonstrating that the user owns the new private key, and has the authority to update the
     /// `OriginatingAddress` map with the new address mapping `<new_address, originating_address>`.
@@ -539,7 +540,7 @@ pub enum EntryFunctionCall {
         friend_account: AccountAddress,
     },
 
-    /// will only succesfully vouch if the two are not related by ancestry
+    /// will only successfully vouch if the two are not related by ancestry
     /// prevents spending a vouch that would not be counted.
     /// to add a vouch and ignore this check use insist_vouch
     VouchVouchFor {
@@ -1032,11 +1033,14 @@ pub fn account_revoke_signer_capability(
 /// `OriginatingAddress` map with the new address mapping `<new_address, originating_address>`.
 /// To verify these two signatures, we need their corresponding public key and public key scheme: we use `from_scheme` and `from_public_key_bytes`
 /// to verify `cap_rotate_key`, and `to_scheme` and `to_public_key_bytes` to verify `cap_update_table`.
-/// A scheme of 0 refers to an Ed25519 key and a scheme of 1 refers to Multi-Ed25519 keys. `originating address` refers to an account's original/first address.
+/// A scheme of 0 refers to an Ed25519 key and a scheme of 1 refers to Multi-Ed25519 keys.
+/// `originating address` refers to an account's original/first address.
+///
 /// Here is an example attack if we don't ask for the second signature `cap_update_table`:
 /// Alice has rotated her account `addr_a` to `new_addr_a`. As a result, the following entry is created, to help Alice when recovering her wallet:
 /// `OriginatingAddress[new_addr_a]` -> `addr_a`
-/// Alice has had bad day: her laptop blew up and she needs to reset her account on a new one. (Fortunately, she still has her secret key `new_sk_a` associated with her new address `new_addr_a`, so she can do this.)
+/// Alice has had bad day: her laptop blew up and she needs to reset her account on a new one.
+/// (Fortunately, she still has her secret key `new_sk_a` associated with her new address `new_addr_a`, so she can do this.)
 ///
 /// But Bob likes to mess with Alice.
 /// Bob creates an account `addr_b` and maliciously rotates it to Alice's new address `new_addr_a`. Since we are no longer checking a PoK,
@@ -2353,7 +2357,7 @@ pub fn vouch_revoke(friend_account: AccountAddress) -> TransactionPayload {
     ))
 }
 
-/// will only succesfully vouch if the two are not related by ancestry
+/// will only successfully vouch if the two are not related by ancestry
 /// prevents spending a vouch that would not be counted.
 /// to add a vouch and ignore this check use insist_vouch
 pub fn vouch_vouch_for(friend_account: AccountAddress) -> TransactionPayload {
diff --git a/framework/releases/head.mrb b/framework/releases/head.mrb
index d0e20fa11..200037e84 100644
Binary files a/framework/releases/head.mrb and b/framework/releases/head.mrb differ