Fix docs links for GitHub browsing

design/docs/config.mdx

@@ -10,7 +10,7 @@ withdrawals, fee estimation, and system operations.
 
 You can update all configurable parameters through the `UpdateConfig`
 governance proposal, which requires 2/3 of committee weight (see
-[Governance Actions](/governance-actions)). Each key is validated against
+[Governance Actions](governance-actions.mdx)). Each key is validated against
 its expected type on update.
 
 ## Parameters
@@ -40,7 +40,7 @@ The minimum time that must elapse between a deposit being approved by the
 committee (`approve_deposit`) and being confirmed (`confirm_deposit`). Provides
 a window in which a fraudulent or erroneous approval can be detected and the
 service paused before any `hBTC` is minted. See the
-[deposit flow](/deposit#confirm) for how this delay fits into the overall
+[deposit flow](deposit.mdx#confirm) for how this delay fits into the overall
 process.
 
 ### `bitcoin_withdrawal_minimum`

design/docs/deposit.mdx

@@ -15,7 +15,7 @@ graph LR
 
 The split between **Approve** and **Confirm** introduces a configurable
 time-delay window (see
-[`bitcoin_deposit_time_delay_ms`](/config#bitcoin_deposit_time_delay_ms))
+[`bitcoin_deposit_time_delay_ms`](config.mdx#bitcoin_deposit_time_delay_ms))
 between the moment the committee certifies a deposit and the moment funds are
 minted. This delay gives operators a chance to detect a faulty or fraudulent
 approval and pause the service before any `hBTC` is minted.
@@ -30,7 +30,7 @@ graph LR
 
 The user creates a Bitcoin transaction that sends BTC to a Hashi deposit
 address. Each deposit address is a unique Taproot address derived from the
-target destination address on Sui (see [Bitcoin Address Scheme](/address-scheme)).
+target destination address on Sui (see [Bitcoin Address Scheme](address-scheme.mdx)).
 The deposit must meet the dust minimum (`546 sats`) to avoid creating
 unspendable UTXOs on Bitcoin.
 
@@ -93,14 +93,14 @@ graph LR
 
 Committee members monitor the Bitcoin network for the deposit transaction. The
 transaction must reach a sufficient number of block confirmations (see
-[`bitcoin_confirmation_threshold`](/config#bitcoin_confirmation_threshold))
+[`bitcoin_confirmation_threshold`](config.mdx#bitcoin_confirmation_threshold))
 before it is considered final. This guards against chain reorganizations where
 a confirmed transaction could be reversed. If the transaction is never
 confirmed or is invalidated by a reorg, the deposit is ignored.
 
 After confirmation, each committee member independently screens the deposit's
 source address by making a request to its configured sanctions-checking
-endpoint (see [Handling Sanctioned Addresses](/sanctions)). A member
+endpoint (see [Handling Sanctioned Addresses](sanctions.mdx)). A member
 that considers the address sanctioned does not vote to approve the deposit.
 
 After a node determines that a deposit request is both confirmed on Bitcoin
@@ -137,7 +137,7 @@ graph LR
 
 After approval, the deposit must wait through the configured time-delay
 window (see
-[`bitcoin_deposit_time_delay_ms`](/config#bitcoin_deposit_time_delay_ms))
+[`bitcoin_deposit_time_delay_ms`](config.mdx#bitcoin_deposit_time_delay_ms))
 before it can be confirmed. The window gives operators a chance to detect a
 faulty or fraudulent approval and pause the service before funds are minted.
 While the service is paused, `confirm_deposit` is rejected, so any pending

design/docs/node-operator-runbook.mdx

@@ -86,7 +86,7 @@ sha256sum -c out/hashi.sha256
 - `gpg` + `gpg-agent`, for decrypting backups, including with a YubiKey (works over a forwarded `gpg-agent` socket so you can restore on a server using a YubiKey plugged into your laptop)
 - Optionally [Sequoia `sq`](https://sequoia-pgp.org/) (local keys) or [`oct` / openpgp-card-tools](https://gitlab.com/openpgp-card/openpgp-card) (YubiKey key generation)
 
-See the [Hashi Node Backups](node-backup) guide for the full key-generation procedure.
+See the [Hashi Node Backups](node-backup.mdx) guide for the full key-generation procedure.
 
 ### 1.4 Sui RPC
 
@@ -238,7 +238,7 @@ backup-pgp-cert = "/path/to/hashi-backup-cert.asc"   # armored OpenPGP public ce
 backup-dir = "/var/lib/hashi/backups"
 ```
 
-Key generation and restore are covered in the [Hashi Node Backups](node-backup) guide. Store the private key / YubiKey securely and separately from the backup files.
+Key generation and restore are covered in the [Hashi Node Backups](node-backup.mdx) guide. Store the private key / YubiKey securely and separately from the backup files.
 
 ---
 
@@ -783,7 +783,7 @@ After execution, the previous committee resumes; the system can trigger a new re
 
 ## 10. Backup and restore
 
-The full key-generation and restore procedures (including YubiKey setup with `oct` and decrypting over SSH) are in the [Hashi Node Backups](node-backup) guide. This section is a quick summary.
+The full key-generation and restore procedures (including YubiKey setup with `oct` and decrypting over SSH) are in the [Hashi Node Backups](node-backup.mdx) guide. This section is a quick summary.
 
 When `backup-pgp-cert` is configured, the node automatically writes an encrypted backup every epoch: it packs the DB (MPC key shares, signing/encryption keys), config, and referenced key files into a tar archive and wraps it as an ASCII-armored OpenPGP (Sequoia) message. Encrypted archives use the suffix `.tar.asc`; unencrypted archives use `.tar`. The node writes backups to `backup-dir` (default `/tmp`, so set a persistent path). Encryption needs only the public certificate, so the private key need not be present during normal operation.
 

design/docs/reconfiguration.mdx

@@ -66,7 +66,7 @@ runs depends on whether this is the first Hashi epoch or a subsequent one:
   members act as dealers and the new committee members act as receivers.
 
 In both cases, the output is a `DkgOutput` containing the new committee's
-key shares and the MPC public key. See [MPC Protocol](/mpc-protocol)
+key shares and the MPC public key. See [MPC Protocol](mpc-protocol.mdx)
 for details.
 
 Each committee member then signs a `ReconfigCompletionMessage` containing
@@ -105,7 +105,7 @@ change flag.
 After the new epoch begins, the new committee initializes the signing state
 for the epoch by running the presigning protocol to generate a batch of
 presignatures needed for the threshold Schnorr signing protocol (see
-[MPC Protocol](/mpc-protocol)). After presignatures are ready, normal
+[MPC Protocol](mpc-protocol.mdx)). After presignatures are ready, normal
 operations resume for processing deposits and withdrawals.
 
 ### Abort Reconfig

design/docs/user-flows.mdx

@@ -41,7 +41,7 @@ sequenceDiagram
 ### BTC deposit address
 
 Every Sui address has its own unique Hashi Bitcoin deposit address. See
-[Bitcoin Address Scheme](/address-scheme) for the full derivation
+[Bitcoin Address Scheme](address-scheme.mdx) for the full derivation
 details.
 
 ### Deposit
@@ -62,7 +62,7 @@ Hashi.
    use the `hBTC` to interact with a DeFi protocol. For example, you can use
    the `hBTC` as collateral for a loan in `USDC`.
 
-For a detailed breakdown of each phase, see [Deposit](/deposit).
+For a detailed breakdown of each phase, see [Deposit](deposit.mdx).
 
 ## Withdraw flow
 
@@ -101,4 +101,4 @@ sequenceDiagram
    address, then uses MPC to sign the transaction.
 1. The transaction is broadcast to the Bitcoin network.
 
-For a detailed breakdown of each phase, see [Withdraw](/withdraw).
+For a detailed breakdown of each phase, see [Withdraw](withdraw.mdx).

design/docs/withdraw.mdx

@@ -34,7 +34,7 @@ public fun request_withdrawal(
 ```
 
 - `btc`: the `hBTC` to withdraw. Must be at least the
-  [`bitcoin_withdrawal_minimum`](/config#bitcoin_withdrawal_minimum).
+  [`bitcoin_withdrawal_minimum`](config.mdx#bitcoin_withdrawal_minimum).
 - `bitcoin_address`: the destination witness program, either `P2WPKH` (20
   bytes) or `P2TR` (32 bytes).
 
@@ -43,12 +43,12 @@ request can produce a valid Bitcoin transaction even under worst-case fee
 conditions. This minimum covers the flat protocol fee, the worst-case miner
 fee (which pays for both the user's transaction weight and opportunistic UTXO
 pool consolidation), and the dust threshold for the user's output. See
-[Fees](/fees) for the full breakdown.
+[Fees](fees.mdx) for the full breakdown.
 
 The full `hBTC` amount is stored with the request and placed in a queue with a
 timestamp. The user can cancel their request at any point before it has been
 approved, subject to a cooldown period
-([`withdrawal_cancellation_cooldown_ms`](/config#withdrawal_cancellation_cooldown_ms)).
+([`withdrawal_cancellation_cooldown_ms`](config.mdx#withdrawal_cancellation_cooldown_ms)).
 
 ## Approve
 
@@ -65,7 +65,7 @@ processed in FIFO order, but this is not a strict requirement.
 
 Each committee member independently screens the destination address against
 its configured sanctions-checking endpoint (see
-[Handling Sanctioned Addresses](/sanctions)). A member that considers
+[Handling Sanctioned Addresses](sanctions.mdx)). A member that considers
 the address sanctioned does not vote to approve the request. If a quorum
 still approves, all members must assist in completing the withdrawal.
 
@@ -108,7 +108,7 @@ The leader then constructs an unsigned Bitcoin transaction:
 1. **Coin selection**: select UTXOs from the pool to cover the total
    withdrawal amount (miner fees are taken from the user's withdrawn amount).
    The coin selector might include extra inputs to opportunistically
-   consolidate small UTXOs (see [Fees](/fees)).
+   consolidate small UTXOs (see [Fees](fees.mdx)).
 2. **Outputs**: one output per withdrawal request to each user's destination
    address, plus one change output back to a Hashi-controlled address.
 3. **Fee calculation**: the miner fee is estimated through `estimatesmartfee`,
@@ -149,13 +149,13 @@ graph LR
 ```
 
 Signing is a two-step process matching the 2-of-2 Taproot script (see
-[Bitcoin Address Scheme](/address-scheme)):
+[Bitcoin Address Scheme](address-scheme.mdx)):
 
 1. **Guardian signature**: the unsigned transaction and metadata are sent to
    the Guardian enclave, which independently validates the request and
    produces a Schnorr signature for each input.
 2. **MPC signature**: the committee runs the threshold Schnorr signing
-   protocol (see [MPC Protocol](/mpc-protocol)) to produce the second
+   protocol (see [MPC Protocol](mpc-protocol.mdx)) to produce the second
    signature for each input.
 
 Both signatures are combined into the taproot script-path witness for each
@@ -191,7 +191,7 @@ graph LR
 The fully signed transaction is broadcast to the Bitcoin network. The
 committee monitors the transaction until it reaches the configured number of
 block confirmations (see
-[`bitcoin_confirmation_threshold`](/config#bitcoin_confirmation_threshold)).
+[`bitcoin_confirmation_threshold`](config.mdx#bitcoin_confirmation_threshold)).
 Once confirmed, a committee member calls
 `hashi::withdraw::confirm_withdrawal`:
 
@@ -211,4 +211,4 @@ withdrawal, returning the spent UTXOs' change output to the pool.
 
 If a transaction gets stuck, fee bumping is handled through CPFP. Either the
 withdrawal recipient spends their output with a high-fee child, or Hashi
-spends the change UTXO (see [Fees: stuck transactions](/fees#stuck-transactions)).
+spends the change UTXO (see [Fees: stuck transactions](fees.mdx#stuck-transactions)).