ci: fail on broken links in guide

We weren't failing on the broken links in CI, but now we are. This
solves most of our problems: broken `include` statements still don't
throw an error, but they emit a warning. There's an upstream PR to
mdbook to update this behavior, which I've +1'd.

Also patches a few broken links here and there, related to reorg in GH #4215.

docs/guide/book.toml

@@ -22,7 +22,7 @@ additional-js =["theme/js/mermaid.min.js", "theme/js/mermaid-init.js"]
 [output.linkcheck]
 # Consider setting `follow-web-links=true` ad-hoc, to validate external URLs.
 follow-web-links = false
-warning-policy = "ignore"
+warning-policy = "error"
 
 # The buf.build website doesn't support HTTP HEAD calls, returning 405.
 # Only relevant when `follow-web-links=true`.

docs/guide/src/dev/metrics.md

@@ -6,13 +6,12 @@ the Penumbra software is doing. Penumbra Labs runs Grafana instances for the pub
   * https://grafana.testnet.penumbra.zone
   * https://grafana.testnet-preview.penumbra.zone
 
-## Viewing Metrics
+There's a more comprehensive WIP dashboard, gated by basic auth for PL team:
 
-TODO: add details on how to use Grafana:
+  * https://metrics.penumbra.zone
 
-- [x] link to <https://grafana.testnet.penumbra.zone> for dashboard on current testnet;
-- [ ] instructions on how to run Grafana + Prometheus for local dev setup (ideally this could work without requiring that `pd` itself is Dockerized, since local development is often more convenient outside of docker);
-- [x] instructions on how to commit dashboards back to the repo.
+Check the usual place for credentials. Eventually those views should be exported
+as public references.
 
 ## Adding Metrics
 

docs/guide/src/node/pd/chain-upgrade.md

@@ -40,7 +40,7 @@ at slightly different times.
 
 ### Testnet 70 -> 71
 
-For the first chain upgrade performed on a Penumbra testnet, use this value for genesis time: `{{ #include ../upgrade_genesis_time_70_71.md }}`.
+For the first chain upgrade performed on a Penumbra testnet, use this value for genesis time: `{{ #include ../../upgrade_genesis_time_70_71.md }}`.
 See an example below for how to supply this value when performing the migration.
 
 ## Performing a chain upgrade
@@ -52,7 +52,7 @@ If your instance is using a different directory, update the paths accordingly.
 2. Using the same version of `pd` that was running when the chain halted, prepare an export directory:
    `pd export --home ~/.penumbra/testnet_data/node0/pd --export-directory ~/.penumbra/testnet_data/node0/pd-exported-state`
 3. Back up the historical state directory: `mv ~/.penumbra/testnet_data/node0/pd ~/.penumbra/testnet_data/node0/pd-state-backup`
-4. Download the latest version of `pd` and install it. Run `pd --version` and confirm you see `{{ #include ../penumbra_version.md }}` before proceeding.
+4. Download the latest version of `pd` and install it. Run `pd --version` and confirm you see `{{ #include ../../penumbra_version.md }}` before proceeding.
 
 <!--
 An example log message emitted by `pd migrate` without providing `--genesis-start`:
@@ -62,7 +62,7 @@ An example log message emitted by `pd migrate` without providing `--genesis-star
 The value after `now=` is what should be copied. In practice, for testnets, Penumbra Labs will advise on a genesis time
 and provide that value in the documentation. Or should we just pick a genesis start ahead of time, and use that for all?
 -->
-5. Apply the migration: `pd migrate --genesis-start "{{ #include ../upgrade_genesis_time_70_71.md }}" --target-directory ~/.penumbra/testnet_data/node0/pd-exported-state/ --migrate-archive ~/.penumbra/testnet_data/node0/pd-migrated-state-{{ #include ../penumbra_version.md }}.tar.gz`.
+5. Apply the migration: `pd migrate --genesis-start "{{ #include ../../upgrade_genesis_time_70_71.md }}" --target-directory ~/.penumbra/testnet_data/node0/pd-exported-state/ --migrate-archive ~/.penumbra/testnet_data/node0/pd-migrated-state-{{ #include ../../penumbra_version.md }}.tar.gz`.
    You must use that precise genesis time, otherwise your node will not be able to reach consensus with the rest of the network.
 6. Move the migrated state into place: `mkdir ~/.penumbra/testnet_data/node0/pd && mv ~/.penumbra/testnet_data/node0/pd-exported-state/rocksdb ~/.penumbra/testnet_data/node0/pd/`
 7. Move the upgrade cometbft state into place: `cp ~/.penumbra/testnet_data/node0/pd-exported-state/genesis.json ~/.penumbra/testnet_data/node0/cometbft/config/genesis.json
@@ -73,5 +73,5 @@ Finally, restart the node, e.g. `sudo systemctl restart penumbra cometbft`. Chec
 past the halt height `n`.
 
 If you want to host a snapshot for this migration, copy the file
-`~/.penumbra/testnet_data/node0/pd-migrated-state-{{ #include ../penumbra_version.md }}.tar.gz` to the appropriate hosting environment,
+`~/.penumbra/testnet_data/node0/pd-migrated-state-{{ #include ../../penumbra_version.md }}.tar.gz` to the appropriate hosting environment,
 and inform the users of your validator.

docs/guide/src/node/pd/install.md

@@ -8,7 +8,7 @@ Make sure to choose the correct platform for your machine. After downloading the
 extract it, and copy its contents to your `$PATH`. For example:
 
 ```
-curl -sSfL -O https://github.com/penumbra-zone/penumbra/releases/download/{{ #include ../penumbra_version.md }}/pd-x86_64-unknown-linux-gnu.tar.xz
+curl -sSfL -O https://github.com/penumbra-zone/penumbra/releases/download/{{ #include ../../penumbra_version.md }}/pd-x86_64-unknown-linux-gnu.tar.xz
 unxz pd-x86_64-unknown-linux-gnu.tar.xz
 tar -xf pd-x86_64-unknown-linux-gnu.tar
 sudo mv pd-x86_64-unknown-linux-gnu/pd /usr/local/bin/
@@ -24,9 +24,9 @@ you'll need to [build from source](../../dev/build.md), or use the container ima
 You'll need to have [CometBFT installed](https://docs.cometbft.com/v0.37/guides/install)
 on your system to join your node to the testnet.
 
-You must use a specific version of CometBFT, `{{ #include ../cometbft_version.md }}`, which you can download
-[from the CometBFT releases page](https://github.com/cometbft/cometbft/releases/tag/{{ #include ../cometbft_version.md }}).
-If you prefer to compile from source instead, make sure you are compiling version `{{ #include ../cometbft_version.md }}`.
+You must use a specific version of CometBFT, `{{ #include ../../cometbft_version.md }}`, which you can download
+[from the CometBFT releases page](https://github.com/cometbft/cometbft/releases/tag/{{ #include ../../cometbft_version.md }}).
+If you prefer to compile from source instead, make sure you are compiling version `{{ #include ../../cometbft_version.md }}`.
 
 Previous versions of Penumbra used Tendermint, but as of Testnet 62 (released 2023-10-10),
 only CometBFT is supported. **Do not use** any version of Tendermint, which will not work with `pd`.

docs/guide/src/node/pd/join-testnet.md

@@ -102,5 +102,5 @@ sudo systemctl daemon-reload
 sudo systemctl restart penumbra cometbft
 ```
 
-See the [`deployments/`](https://github.com/penumbra-zone/penumbra/tree/{{ #include ../penumbra_version.md }}/deployments)
+See the [`deployments/`](https://github.com/penumbra-zone/penumbra/tree/{{ #include ../../penumbra_version.md }}/deployments)
 directory for more examples on configuration scripts.

docs/guide/src/node/pd/requirements.md

@@ -35,7 +35,7 @@ the `--grpc-auto-https <DOMAIN>` option. See `pd start --help` for more info.
 
 We expect node operators to manage the lifecycle of their Penumbra deployments.
 Some example configs for systemd, docker compose, and kubernetes helm charts
-can be found in the Penumbra repo's [`deployments/`](https://github.com/penumbra-zone/penumbra/tree/{{ #include ../penumbra_version.md }}/deployments) directory.
+can be found in the Penumbra repo's [`deployments/`](https://github.com/penumbra-zone/penumbra/tree/{{ #include ../../penumbra_version.md }}/deployments) directory.
 You should consult these configurations as a reference, and write your own
 scripts to maintain your node.
 

docs/guide/src/pcli/wallet.md

@@ -30,7 +30,7 @@ Address is viewable with this full viewing key. Account index is 0.
 Addresses are opaque and do not reveal account information. Only you, or someone
 who has your viewing key, can decrypt the account information from the address.
 
-### Getting testnet tokens on the [Discord] in the `#testnet-faucet` channel
+### Getting testnet tokens on Discord in the `#testnet-faucet` channel
 
 In order to use the testnet, it's first necessary for you to get some testnet tokens. The current
 way to do this is to join our [Discord](https://discord.gg/hKvkrqa3zC) and post your address in the `#testnet-faucet` channel.