chore(brand): replace double-dash em-dash substitutes with colons

docs/concepts/index.md

@@ -9,25 +9,25 @@ Understand the ideas behind the Internet Computer before you build on it. These
 
 ## Architecture
 
-- **[Network Overview](network-overview.md)** -- Subnets, nodes, consensus, and boundary nodes.
-- **[Application Architecture](app-architecture.md)** -- How ICP applications are structured: canisters, frontends, and inter-canister communication.
-- **[Canisters](canisters.md)** -- Smart contracts that run WebAssembly, hold state, serve HTTP, and pay for their own compute.
+- **[Network Overview](network-overview.md)**: Subnets, nodes, consensus, and boundary nodes.
+- **[Application Architecture](app-architecture.md)**: How ICP applications are structured: canisters, frontends, and inter-canister communication.
+- **[Canisters](canisters.md)**: Smart contracts that run WebAssembly, hold state, serve HTTP, and pay for their own compute.
 
 ## Core capabilities
 
-- **[Reverse Gas Model](reverse-gas-model.md)** -- Why users never pay gas: canisters pay cycles for compute, storage, and bandwidth.
-- **[Orthogonal Persistence](orthogonal-persistence.md)** -- How canister memory survives across executions and upgrades without databases.
-- **[HTTPS Outcalls](https-outcalls.md)** -- How canisters make HTTP requests to external services with consensus on responses.
-- **[Onchain Randomness](onchain-randomness.md)** -- Cryptographically secure random numbers using threshold VRF.
-- **[Timers](timers.md)** -- Periodic and one-shot scheduled tasks via the global timer mechanism.
+- **[Reverse Gas Model](reverse-gas-model.md)**: Why users never pay gas: canisters pay cycles for compute, storage, and bandwidth.
+- **[Orthogonal Persistence](orthogonal-persistence.md)**: How canister memory survives across executions and upgrades without databases.
+- **[HTTPS Outcalls](https-outcalls.md)**: How canisters make HTTP requests to external services with consensus on responses.
+- **[Onchain Randomness](onchain-randomness.md)**: Cryptographically secure random numbers using threshold VRF.
+- **[Timers](timers.md)**: Periodic and one-shot scheduled tasks via the global timer mechanism.
 
 ## Cryptography and cross-chain
 
-- **[Chain-Key Cryptography](chain-key-cryptography.md)** -- Threshold signatures that enable cross-chain integration, fast finality, and chain evolution.
-- **[Chain Fusion](chain-fusion.md)** -- How ICP connects to Bitcoin, Ethereum, Solana, and other blockchains natively.
-- **[VetKeys](vetkeys.md)** -- Verifiable encrypted threshold key derivation for onchain encryption and secret management.
+- **[Chain-Key Cryptography](chain-key-cryptography.md)**: Threshold signatures that enable cross-chain integration, fast finality, and chain evolution.
+- **[Chain Fusion](chain-fusion.md)**: How ICP connects to Bitcoin, Ethereum, Solana, and other blockchains natively.
+- **[VetKeys](vetkeys.md)**: Verifiable encrypted threshold key derivation for onchain encryption and secret management.
 
 ## Trust and governance
 
-- **[Security Model](security.md)** -- Canister isolation, trust boundaries, and the threat model for app developers.
-- **[Governance](governance.md)** -- The NNS, SNS for app governance, neurons, and proposals.
+- **[Security Model](security.md)**: Canister isolation, trust boundaries, and the threat model for app developers.
+- **[Governance](governance.md)**: The NNS, SNS for app governance, neurons, and proposals.

docs/concepts/orthogonal-persistence.md

@@ -5,9 +5,9 @@ sidebar:
   order: 5
 ---
 
-On traditional backends, application state lives in memory only while the process runs. To persist data across restarts, you need a database -- PostgreSQL, Redis, SQLite, or a file system. The application logic and the storage layer are separate concerns that developers must wire together.
+On traditional backends, application state lives in memory only while the process runs. To persist data across restarts, you need a database: PostgreSQL, Redis, SQLite, or a file system. The application logic and the storage layer are separate concerns that developers must wire together.
 
-On the Internet Computer, persistence is built into the execution model. A canister's memory persists between calls automatically -- no database and no file system. In Motoko, this is fully transparent: you declare a variable, assign it a value, and that value is still there the next time the canister executes -- no explicit save or load. In Rust, you choose persistent data structures that write directly to stable memory, giving you full control over what survives upgrades. Either way, the canister IS its own storage. This property is called **orthogonal persistence**: persistence is orthogonal to (independent of) the programming model.
+On the Internet Computer, persistence is built into the execution model. A canister's memory persists between calls automatically: no database and no file system. In Motoko, this is fully transparent: you declare a variable, assign it a value, and that value is still there the next time the canister executes (no explicit save or load). In Rust, you choose persistent data structures that write directly to stable memory, giving you full control over what survives upgrades. Either way, the canister IS its own storage. This property is called **orthogonal persistence**: persistence is orthogonal to (independent of) the programming model.
 
 There is no separate storage tier to configure, query, or maintain.
 
@@ -17,29 +17,29 @@ Every canister has two distinct memory regions, each with different characterist
 
 ### Heap (Wasm linear) memory
 
-This is regular program memory -- the space where variables, data structures, and the call stack live during execution. It maps to the Wasm linear memory of the canister module.
+This is regular program memory: the space where variables, data structures, and the call stack live during execution. It maps to the Wasm linear memory of the canister module.
 
 - **Size limit:** 4 GiB for wasm32 canisters, 6 GiB for wasm64
 - **Performance:** Fast, native Wasm memory access
-- **Upgrade behavior:** Wiped on canister upgrade (Rust) -- use stable structures to persist data; automatically preserved in Motoko with `persistent actor`
+- **Upgrade behavior:** Wiped on canister upgrade (Rust): use stable structures to persist data; automatically preserved in Motoko with `persistent actor`
 
 ### Stable memory
 
 A separate, dedicated memory region provided by the Internet Computer runtime. Its sole purpose is to survive canister upgrades.
 
 - **Size limit:** Up to 500 GiB per canister. The actual available capacity also depends on the subnet's total storage usage, since all canisters on a subnet share a common storage budget. For storage-heavy applications, consider [subnet selection](../guides/canister-management/subnet-selection.md).
-- **Performance:** Slower than heap memory -- each access goes through system API calls rather than direct Wasm memory operations
+- **Performance:** Slower than heap memory: each access goes through system API calls rather than direct Wasm memory operations
 - **Upgrade behavior:** Always survives upgrades
 
 The distinction between these two regions is the foundation of all persistence strategies on ICP.
 
 ## How persistence differs by language
 
-The two mainstream canister languages -- Motoko and Rust -- take fundamentally different approaches to persistence.
+The two mainstream canister languages (Motoko and Rust) take fundamentally different approaches to persistence.
 
 ### Motoko: true orthogonal persistence
 
-Motoko is the only ICP language that delivers true orthogonal persistence. With `persistent actor`, all variable declarations inside the actor body are automatically persisted across upgrades. Developers do not think about persistence at all -- they write normal code and data survives.
+Motoko is the only ICP language that delivers true orthogonal persistence. With `persistent actor`, all variable declarations inside the actor body are automatically persisted across upgrades. Developers do not think about persistence at all: they write normal code and data survives.
 
 The runtime transparently manages the mapping between the program's heap and stable memory during upgrades. Fields marked `transient var` reset to their initial value on upgrade, giving developers explicit control over what is ephemeral (caches, counters) versus durable.
 
@@ -51,7 +51,7 @@ For implementation details and code examples, see the [Data persistence guide](.
 
 Rust canisters take an explicit approach. The `ic-stable-structures` crate provides data structures (`StableBTreeMap`, `StableCell`, `StableLog`) that are backed directly by stable memory. Data written to these structures survives upgrades without any serialization step.
 
-This is not orthogonal persistence -- developers must consciously choose which data structures to use and how to partition stable memory. The tradeoff is full control: Rust developers decide exactly what persists, how it's stored, and how memory is allocated.
+This is not orthogonal persistence: developers must consciously choose which data structures to use and how to partition stable memory. The tradeoff is full control: Rust developers decide exactly what persists, how it's stored, and how memory is allocated.
 
 For implementation details and code examples, see the [Data persistence guide](../guides/backends/data-persistence.md).
 
@@ -73,7 +73,7 @@ Stable structures avoid this entirely by writing directly to stable memory durin
 | **API** | Native language constructs | `StableBTreeMap` etc. (Rust); automatic (Motoko) |
 | **Use case** | All data in Motoko `persistent actor`; caches and temporary computation in Rust | All persistent application data (Rust) |
 
-In Motoko with `persistent actor`, this trade-off is largely invisible -- the runtime manages the mapping between heap and stable memory during upgrades. In Rust, developers choose explicitly: heap data (fast but ephemeral) or stable structures (slightly slower but durable).
+In Motoko with `persistent actor`, this trade-off is largely invisible: the runtime manages the mapping between heap and stable memory during upgrades. In Rust, developers choose explicitly: heap data (fast but ephemeral) or stable structures (slightly slower but durable).
 
 ## Comparison with traditional backends
 
@@ -89,14 +89,14 @@ The mental model shift: instead of "my app talks to a database," think "my app I
 
 ## Further reading
 
-- [IC Internals: Orthogonal Persistence](https://medium.com/dfinity/ic-internals-orthogonal-persistence-9e0c094aac1a) -- deep dive into how orthogonal persistence works at the protocol level
-- [A Journey into Stellarator (Part 2)](https://medium.com/dfinity/a-journey-into-stellarator-part-2-d4a83c631748) -- the Stellarator engine that powers Motoko's persistent actors
-- [Orthogonal Persistence in 60 Seconds](https://www.youtube.com/shorts/g3sC2wjLzew) -- quick visual explainer
+- [IC Internals: Orthogonal Persistence](https://medium.com/dfinity/ic-internals-orthogonal-persistence-9e0c094aac1a): deep dive into how orthogonal persistence works at the protocol level
+- [A Journey into Stellarator (Part 2)](https://medium.com/dfinity/a-journey-into-stellarator-part-2-d4a83c631748): the Stellarator engine that powers Motoko's persistent actors
+- [Orthogonal Persistence in 60 Seconds](https://www.youtube.com/shorts/g3sC2wjLzew): quick visual explainer
 
 ## Next steps
 
-- [Data persistence guide](../guides/backends/data-persistence.md) -- practical implementation patterns for both languages
-- [Rust stable structures](../languages/rust/stable-structures.md) -- detailed Rust patterns with `StableBTreeMap`, `StableCell`, and `StableLog`
-- [Canister lifecycle](../guides/canister-management/lifecycle.md) -- how upgrades, reinstalls, and other lifecycle events interact with persistence
+- [Data persistence guide](../guides/backends/data-persistence.md): practical implementation patterns for both languages
+- [Rust stable structures](../languages/rust/stable-structures.md): detailed Rust patterns with `StableBTreeMap`, `StableCell`, and `StableLog`
+- [Canister lifecycle](../guides/canister-management/lifecycle.md): how upgrades, reinstalls, and other lifecycle events interact with persistence
 
 <!-- Upstream: informed by dfinity/portal persistence sections and stable-memory icskill -->

docs/getting-started/choose-your-path.md

@@ -11,81 +11,81 @@ Choose your next step based on what you want to build. Each path links to the fi
 
 If you prefer to learn the concepts before diving into guides, the [Concepts](../concepts/index.md) section explains how ICP works under the hood:
 
-- [Network overview](../concepts/network-overview.md) -- how the Internet Computer is structured
-- [Canisters](../concepts/canisters.md) -- the compute unit of ICP
-- [Orthogonal persistence](../concepts/orthogonal-persistence.md) -- how data survives canister upgrades
-- [Reverse gas model](../concepts/reverse-gas-model.md) -- why users don't pay gas fees
-- [Chain-key cryptography](../concepts/chain-key-cryptography.md) -- the cryptographic foundation enabling chain fusion
+- [Network overview](../concepts/network-overview.md): how the Internet Computer is structured
+- [Canisters](../concepts/canisters.md): the compute unit of ICP
+- [Orthogonal persistence](../concepts/orthogonal-persistence.md): how data survives canister upgrades
+- [Reverse gas model](../concepts/reverse-gas-model.md): why users don't pay gas fees
+- [Chain-key cryptography](../concepts/chain-key-cryptography.md): the cryptographic foundation enabling chain fusion
 
 ## Backend development
 
-**You want to:** Write canister logic -- store data, call APIs, run scheduled tasks.
+**You want to:** Write canister logic: store data, call APIs, run scheduled tasks.
 
 This is where most developers start after the quickstart. The backend guides cover the core patterns for building canister applications in Rust or Motoko.
 
-**Start with:** [Data persistence](../guides/backends/data-persistence.md) -- learn how canisters store and retrieve data using stable memory and orthogonal persistence.
+**Start with:** [Data persistence](../guides/backends/data-persistence.md): learn how canisters store and retrieve data using stable memory and orthogonal persistence.
 
 **Then explore:**
 
-- [HTTPS outcalls](../guides/backends/https-outcalls.md) -- call external APIs from your canister
-- [Timers](../guides/backends/timers.md) -- schedule recurring tasks
-- [Randomness](../guides/backends/randomness.md) -- generate unpredictable values onchain
-- [Calling other canisters](../guides/canister-calls/onchain-calls.md) -- compose functionality across canisters
+- [HTTPS outcalls](../guides/backends/https-outcalls.md): call external APIs from your canister
+- [Timers](../guides/backends/timers.md): schedule recurring tasks
+- [Randomness](../guides/backends/randomness.md): generate unpredictable values onchain
+- [Calling other canisters](../guides/canister-calls/onchain-calls.md): compose functionality across canisters
 
 ## Full-stack applications
 
 **You want to:** Build a web application with a frontend that talks to your canister.
 
 ICP can serve web assets directly from canisters, giving you a tamperproof application with no external hosting required.
 
-**Start with:** [Asset canister](../guides/frontends/asset-canister.md) -- deploy a frontend alongside your backend canister.
+**Start with:** [Asset canister](../guides/frontends/asset-canister.md): deploy a frontend alongside your backend canister.
 
 **Then explore:**
 
-- [Framework integration](../guides/frontends/frameworks.md) -- use React, Vue, Svelte, or other frameworks
-- [Custom domains](../guides/frontends/custom-domains.md) -- serve your app from your own domain name
-- [Internet Identity](../guides/authentication/internet-identity.md) -- add passwordless authentication
-- [Wallet integration](../guides/defi/wallet-integration.md) -- connect user wallets
+- [Framework integration](../guides/frontends/frameworks.md): use React, Vue, Svelte, or other frameworks
+- [Custom domains](../guides/frontends/custom-domains.md): serve your app from your own domain name
+- [Internet Identity](../guides/authentication/internet-identity.md): add passwordless authentication
+- [Wallet integration](../guides/defi/wallet-integration.md): connect user wallets
 
 ## Chain fusion (cross-chain)
 
 **You want to:** Integrate with Bitcoin, Ethereum, or other blockchains.
 
-Chain fusion lets your canister hold native assets, sign transactions, and interact with smart contracts on other chains -- without bridges or intermediaries. This is possible because ICP canisters can derive cryptographic keys and sign transactions using chain-key cryptography.
+Chain fusion lets your canister hold native assets, sign transactions, and interact with smart contracts on other chains, without bridges or intermediaries. This is possible because ICP canisters can derive cryptographic keys and sign transactions using chain-key cryptography.
 
-**Start with:** [Bitcoin integration](../guides/chain-fusion/bitcoin.md) -- read Bitcoin state and create transactions directly from a canister.
+**Start with:** [Bitcoin integration](../guides/chain-fusion/bitcoin.md): read Bitcoin state and create transactions directly from a canister.
 
 **Then explore:**
 
-- [Ethereum integration](../guides/chain-fusion/ethereum.md) -- interact with EVM smart contracts and hold ETH
-- [Solana integration](../guides/chain-fusion/solana.md) -- connect to the Solana network
-- [Dogecoin integration](../guides/chain-fusion/dogecoin.md) -- work with Dogecoin using the same chain-key ECDSA signing as Bitcoin
+- [Ethereum integration](../guides/chain-fusion/ethereum.md): interact with EVM smart contracts and hold ETH
+- [Solana integration](../guides/chain-fusion/solana.md): connect to the Solana network
+- [Dogecoin integration](../guides/chain-fusion/dogecoin.md): work with Dogecoin using the same chain-key ECDSA signing as Bitcoin
 
 ## DeFi and tokens
 
 **You want to:** Create tokens, interact with ledgers, or build financial applications.
 
 ICP has a standard token framework (ICRC) and chain-key tokens that represent assets from other chains. These guides cover the ledger APIs and token patterns you need for DeFi.
 
-**Start with:** [Token ledgers](../guides/defi/token-ledgers.md) -- understand ICRC token standards and interact with ledger canisters.
+**Start with:** [Token ledgers](../guides/defi/token-ledgers.md): understand ICRC token standards and interact with ledger canisters.
 
 **Then explore:**
 
-- [Chain-key tokens](../guides/defi/chain-key-tokens.md) -- work with ckBTC, ckETH, and other wrapped assets
-- [Rosetta API](../guides/defi/rosetta.md) -- integrate with exchanges and wallets using the Rosetta standard
+- [Chain-key tokens](../guides/defi/chain-key-tokens.md): work with ckBTC, ckETH, and other wrapped assets
+- [Rosetta API](../guides/defi/rosetta.md): integrate with exchanges and wallets using the Rosetta standard
 
 ## Decentralized governance
 
 **You want to:** Hand control of your application to a community through an SNS DAO.
 
 The Service Nervous System (SNS) lets you tokenize your application and create a decentralized autonomous organization that governs upgrades, treasury, and parameters through proposals and voting.
 
-**Start with:** [Launching an SNS](../guides/governance/launching.md) -- understand the process and requirements for decentralizing your application.
+**Start with:** [Launching an SNS](../guides/governance/launching.md): understand the process and requirements for decentralizing your application.
 
 **Then explore:**
 
-- [Managing an SNS](../guides/governance/managing.md) -- submit proposals and manage governance
-- [Testing an SNS](../guides/governance/testing.md) -- validate your SNS configuration before launch
+- [Managing an SNS](../guides/governance/managing.md): submit proposals and manage governance
+- [Testing an SNS](../guides/governance/testing.md): validate your SNS configuration before launch
 
 ## AI-assisted development