Small cleanups reflecting style guide meeting

Author: cshannon1218

docs/blockchain-development-tutorials/cadence/cadence-advantages/compose-with-cadence-transactions.md

@@ -21,8 +21,6 @@ keywords:
 
 # Compose wth Cadence Transactions
 
-## Overview
-
 In this tutorial, you'll **compose with someone else's contracts** on Flow testnet. You'll write a Cadence transaction that reads public state from a contract named `Counter` and only increments the counter when it is odd. Then you'll extend the transaction to mint NFTs when the counter is odd, demonstrating how to compose multiple contracts in a single transaction. Everything runs against testnet using the Flow CLI and the dependency manager.
 
 You can use transactions developed and tested this way from the frontend of your app.

docs/blockchain-development-tutorials/cadence/cadence-advantages/native-data-availibility-with-cadence-scripts.md

@@ -23,8 +23,6 @@ keywords:
 
 # Native Data Availability With Cadence Scripts
 
-## Overview
-
 In Solidity, you can only retrieve data from **view** functions that the contract author anticipated and included in the original contract. If the exact query you want is not exposed, teams typically rely on a _data availability service_ such as The Graph, Covalent, Alchemy Enhanced APIs, Reservoir, or NFTScan to compute and serve that view.
 
 In Cadence, **scripts** are general-purpose read programs. They can traverse public account storage, read public capabilities, and compose types from multiple contracts to answer new questions without modifying those contracts. You are not limited to the pre-written surface area of a single contract's views.

docs/blockchain-development-tutorials/cadence/cadence-advantages/upgrading-cadence-contracts.md

@@ -18,8 +18,6 @@ keywords:
 
 # Upgrading Cadence Contracts
 
-## Overview
-
 In Cadence, you can upgrade deployed contracts by adding new functionality while preserving existing state and maintaining the same contract address. Unlike other blockchain platforms that require complex proxy patterns or complete redeployment, Cadence allows you to seamlessly extend your contracts with new functions and events through multiple incremental upgrades.
 
 This tutorial demonstrates how to upgrade a deployed contract through two scenarios: 

docs/blockchain-development-tutorials/forte/fixed-point-128-bit-math.md

@@ -18,7 +18,6 @@ sidebar_label: DeFi Math Utils
 
 # High-Precision Fixed-Point 128 Bit Math 
 
-## Overview
 Dealing with decimals is a notorious issue for most developers on other chains, especially when working with decentralized finance (DeFi). Blockchains are deterministic systems and floating-point arithmetic is non-deterministic across different compilers and architectures, which is why blockchains use fixed-point arithmetic via integers (scaling numbers by a fixed factor). 
 
 The issue with this is that these fixed-point integers tend to be very imprecise when using various mathematical operations on them. The more operations you apply to these numbers, the more imprecise these numbers become. However [`DeFiActionsMathUtils`] provides a standardized library for high-precision mathematical operations in DeFi applications on Flow. The contract extends Cadence's native 8-decimal precision (`UFix64`) to 24 decimals using `UInt128` for intermediate calculations, ensuring accuracy in complex financial computations while maintaining deterministic results across the network.
@@ -27,7 +26,7 @@ Through integration of this math utility library, developers can ensure that the
 
 :::info
 
-While this documentation focuses on DeFi use cases, you can use these mathematical utilities for any application requiring high-precision decimal arithmetic beyond the native 8-decimal limitation of `UFix64`.
+While this document focuses on DeFi use cases, you can use these mathematical utilities for any application requiring high-precision decimal arithmetic beyond the native 8-decimal limitation of `UFix64`.
 
 :::
 

docs/blockchain-development-tutorials/forte/flow-actions/basic-combinations.md

@@ -19,8 +19,6 @@ We will update these tutorials, but you may need to refactor your code if the im
 
 :::
 
-## Overview
-
 Flow Actions are designed to be **composable**, which means you can chain them together like LEGO blocks to build complex strategies. Each primitive has a standardized interface that works consistently across all protocols and eliminates the need to learn multiple APIs. This composability allows atomic execution of multi-step workflows within single transactions, ensuring either complete success or safe failure. When developers combine these primitives, they create sophisticated decentralized finance (DeFi) strategies like automated yield farming, cross-protocol arbitrage, and portfolio rebalancing. The [5 Flow Actions Primitives] are:
 
 - **Source** → Provides tokens on demand by withdrawing from vaults or claiming rewards. Sources respect minimum balance constraints and return empty vaults gracefully when nothing is available.

docs/blockchain-development-tutorials/forte/flow-actions/connectors.md

@@ -24,8 +24,6 @@ We will update these tutorials, but you may need to refactor your code if the im
 
 :::
 
-## Overview
-
 **Connectors** are the bridge between external DeFi protocols and the standardized Flow Actions primitive interfaces. They act as **protocol adapters** that translate protocol-specific APIs into the universal language of Flow Actions. Think of them as "drivers" that provide a connection between software and a piece of hardware without the software developer needing to know how the hardware expects to receive commands, or an MCP allowing an agent to use an API in a standardized manner. 
 
 Flow Actions act as "money LEGOs" with which you can compose various complex operations with simple transactions. These are the benefits of connectors:

docs/blockchain-development-tutorials/forte/flow-actions/flow-actions-transaction.md

@@ -25,8 +25,6 @@ We will update these tutorials, but you may need to refactor your code if the im
 
 :::
 
-## Overview
-
 [Staking] is a simple way to participate in the blockchain process. You supply tokens to help with governance and, in return, you earn a share of the network's rewards. It's a way to grow unused assets and provides a much higher rate of return than a savings account. 
 
 :::warning

docs/blockchain-development-tutorials/forte/flow-actions/intro-to-flow-actions.md

@@ -36,7 +36,6 @@ We are reviewing and finalizing Flow Actions in [FLIP 339]. The specific impleme
 We will update these tutorials, but you may need to refactor your code if the implementation changes.
 
 :::
-## Overview
 
 _Actions_ are a suite of standardized Cadence interfaces that allow developers to compose complex workflows, starting with decentralized finance (DeFi) workflows, by connecting small, reusable components. Actions provide a "LEGO" framework of blocks where each component performs a single operation (deposit, withdraw, swap, price lookup, flash loan) while maintaining composability with other components. This creates sophisticated workflows executable in a single atomic transaction.
 
@@ -52,7 +51,7 @@ By using Flow Actions, developers can remove large amounts of tailored complexit
 
 ## Learning Objectives
 
-After completing this tutorial, you will be able to:
+After you complete this tutorial, you will be able to:
 
 - Understand the key features of Flow Actions including atomic composition, weak guarantees, and event traceability
 - Create and use Sources to provide tokens from various protocols and locations

docs/blockchain-development-tutorials/forte/scheduled-transactions/scheduled-transactions-introduction.md

@@ -25,8 +25,6 @@ We will update these tutorials, but you may need to refactor your code if the im
 
 :::
 
-# Overview
-
 Flow, EVM, and other blockchains are a form of a **single** shared computer that anyone can use, with no admin privileges, super user roles, or complete control. For this to work, it must be impossible for any user to freeze the computer, on purpose or by accident.
 
 As a result, most blockchain computers, including EVM and Solana, aren't [Turing Complete], because they can't run an unbounded loop. Each transaction must occur within one block, and can't consume more gas than the limit.