docs: fix some broken links (cosmos#6012)

* docs(e2e): fixed broken link

* docs: fixed architecture links

* docs: fixed more broken links

* docs: fixed some interchain accounts links

* fix: more links

* imp: updated markdownlint-cli2 API

* docs: ran linter

Makefile

@@ -337,7 +337,7 @@ docs-lint:
 
 #? docs-lint-fix: Lint markdown documentation files and fix
 docs-lint-fix:
-	markdownlint-cli2-fix "**.md"
+	markdownlint-cli2 "**.md" --fix
 
 #? docs-link-check: Run markdown-link-check
 docs-link-check:
@@ -390,4 +390,4 @@ proto-update-deps:
 help: Makefile
 	@echo " Choose a command run in "$(PROJECT_NAME)":"
 	@sed -n 's/^#?//p' $< | column -t -s ':' |  sort | sed -e 's/^/ /'
-.PHONY: help
+.PHONY: help

docs/architecture/README.md

@@ -25,7 +25,7 @@ If recorded decisions turned out to be lacking, convene a discussion, record the
 
 Note the context/background should be written in the present tense.
 
-To suggest an ADR, please make use of the [ADR template](./adr.template.md) provided.
+To suggest an ADR, please make use of the [ADR template](https://github.com/cosmos/ibc-go/blob/main/docs/architecture/adr.template.md) provided.
 
 ## Table of Contents
 
@@ -37,7 +37,7 @@ To suggest an ADR, please make use of the [ADR template](./adr.template.md) prov
 | [004](./adr-004-ics29-lock-fee-module.md) | ICS29 module locking upon escrow out of balance | Accepted |
 | [005](./adr-005-consensus-height-events.md) | `UpdateClient` events - `ClientState` consensus heights | Accepted |
 | [006](./adr-006-02-client-refactor.md) | ICS02 client refactor | Accepted |
-| [007](./adr-007-solomachine-signbytes.md) | ICS06 Solo machine sign bytes |
+| [007](./adr-007-solomachine-signbytes.md) | ICS06 Solo machine sign bytes | Accepted |
 | [008](./adr-008-app-caller-cbs.md) | Callback to IBC ACtors | Accepted |
 | [009](./adr-009-v6-ics27-msgserver.md) | ICS27 message server addition | Accepted |
 | [010](./adr-010-light-clients-as-sdk-modules.md) | IBC light clients as SDK modules | Accepted |

docs/docs/01-ibc/04-middleware/02-develop.md

@@ -283,7 +283,7 @@ See [here](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/apps/29-fee/ibc_
 
 #### Capabilities
 
-The middleware should simply pass the capability in the callback arguments along to the underlying application so that it may be claimed by the base application. The base application will then pass the capability up the stack in order to authenticate an outgoing packet/acknowledgement, which you can check in the [`ICS4Wrapper` section](02-develop.md#ics-4-wrappers).
+The middleware should simply pass the capability in the callback arguments along to the underlying application so that it may be claimed by the base application. The base application will then pass the capability up the stack in order to authenticate an outgoing packet/acknowledgement, which you can check in the [`ICS4Wrapper` section](#ics-04-wrappers).
 
 In the case where the middleware wishes to send a packet or acknowledgment without the involvement of the underlying application, it should be given access to the same `scopedKeeper` as the base application so that it can retrieve the capabilities by itself.
 

docs/docs/02-apps/02-interchain-accounts/02-development.md

@@ -15,7 +15,7 @@ This document will outline potential use cases and redirect each use case to the
 ## Custom authentication
 
 Interchain accounts may be associated with alternative types of authentication relative to the traditional public/private key signing.
-If you wish to develop or use Interchain Accounts with a custom authentication module and do not need to execute custom logic on the packet callbacks, we recommend you use ibc-go v6 or greater and that your custom authentication module interacts with the controller submodule via the [`MsgServer`](05-messages.md).
+If you wish to develop or use Interchain Accounts with a custom authentication module and do not need to execute custom logic on the packet callbacks, we recommend you use ibc-go v6 or greater and that your custom authentication module interacts with the controller submodule via the [`MsgServer`](./05-messages.md).
 
 If you wish to consume and execute custom logic in the packet callbacks, then please read the section [Packet callbacks](#packet-callbacks) below.
 
@@ -26,7 +26,7 @@ To facilitate such an action, the controller submodule may be provided an underl
 An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware.
 
 Implementers of this use case are recommended to follow the ADR 008 approach.
-The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](03-auth-modules.md#registerinterchainaccount) should continue to be utilized in such situations.
+The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](./10-legacy/01-auth-modules.md) should continue to be utilized in such situations.
 
 ## Packet callbacks
 
@@ -35,6 +35,6 @@ If a developer requires access to packet callbacks for their use case, then they
 1. Write a smart contract which is connected via an ADR 008 or equivalent IBC application (recommended).
 2. Use the controller's underlying application to implement packet callback logic.
 
-In the first case, the smart contract should use the [`MsgServer`](05-messages.md).
+In the first case, the smart contract should use the [`MsgServer`](./05-messages.md).
 
-In the second case, the underlying application should use the [legacy API](10-legacy/03-keeper-api.md).
+In the second case, the underlying application should use the [legacy API](./10-legacy/03-keeper-api.md).

docs/docs/03-light-clients/04-wasm/01-overview.md

@@ -13,7 +13,7 @@ Learn about the `08-wasm` light client proxy module.
 
 ### Context
 
-Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](../../../architecture/adr-010-light-clients-as-sdk-modules.md). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. 
+Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](/architecture/adr-010-light-clients-as-sdk-modules). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. 
 
 ### Motivation
 

docs/requirements/ics29-v1-requirements.md

@@ -92,7 +92,7 @@ See section [Definitions](https://github.com/cosmos/ibc/tree/main/spec/app/ics-0
 | 4.08 | Only packets that have been sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L376) | `Verified` |
 | 4.09 | A packet sent may be incentivized for some or all of `MsgRecvPacket`, `MsgAcknowledgement`, `MsgTimeout`. | Fees for any of the messages may be zero, but [not all of them](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/types/fee.go#L87). | `Verified` |
 | 4.10 | Only packets that have not gone through the packet life cycle (i.e. have not been acknowledged or timed out yet) may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L382-L410) | `Verified` |
-| 4.11 | If a channel exists, a packet sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L365) |
+| 4.11 | If a channel exists, a packet sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L365) | `Verified` |
 | 4.12 | If a channel is fee-enabled, a packet sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L357) | `Verified` |
 | 4.13 | If the fee module is not locked, a packet sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L350) | `Verified` |
 | 4.14 | A non-valid `Bech32` account address shall not be allowed to incentivize a packet sent. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L412) | `Verified` |

docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/02-development.md

@@ -26,7 +26,7 @@ To facilitate such an action, the controller submodule may be provided an underl
 An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware. 
 
 Implementers of this use case are recommended to follow the ADR 008 approach.
-The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](03-auth-modules.md#registerinterchainaccount) should continue to be utilized in such situations. 
+The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](./09-legacy/01-auth-modules.md) should continue to be utilized in such situations. 
 
 ## Packet callbacks
 

docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/02-development.md

@@ -26,7 +26,7 @@ To facilitate such an action, the controller submodule may be provided an underl
 An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware. 
 
 Implementers of this use case are recommended to follow the ADR 008 approach.
-The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](03-auth-modules.md#registerinterchainaccount) should continue to be utilized in such situations. 
+The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](./10-legacy/01-auth-modules.md) should continue to be utilized in such situations. 
 
 ## Packet callbacks
 

docs/versioned_docs/version-v7.3.x/03-light-clients/04-wasm/01-overview.md

@@ -13,7 +13,7 @@ Learn about the `08-wasm` light client proxy module.
 
 ### Context
 
-Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](../../../../architecture/adr-010-light-clients-as-sdk-modules.md). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. 
+Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](/architecture/adr-010-light-clients-as-sdk-modules). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. 
 
 ### Motivation
 

docs/versioned_docs/version-v8.1.x/01-ibc/04-middleware/02-develop.md

@@ -283,7 +283,7 @@ See [here](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/apps/29-fee/ibc_
 
 #### Capabilities
 
-The middleware should simply pass the capability in the callback arguments along to the underlying application so that it may be claimed by the base application. The base application will then pass the capability up the stack in order to authenticate an outgoing packet/acknowledgement, which you can check in the [`ICS4Wrapper` section](02-develop.md#ics-4-wrappers).
+The middleware should simply pass the capability in the callback arguments along to the underlying application so that it may be claimed by the base application. The base application will then pass the capability up the stack in order to authenticate an outgoing packet/acknowledgement, which you can check in the [`ICS4Wrapper` section](#ics-04-wrappers).
 
 In the case where the middleware wishes to send a packet or acknowledgment without the involvement of the underlying application, it should be given access to the same `scopedKeeper` as the base application so that it can retrieve the capabilities by itself.
 

docs/versioned_docs/version-v8.1.x/02-apps/02-interchain-accounts/02-development.md

@@ -26,7 +26,7 @@ To facilitate such an action, the controller submodule may be provided an underl
 An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware.
 
 Implementers of this use case are recommended to follow the ADR 008 approach.
-The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](03-auth-modules.md#registerinterchainaccount) should continue to be utilized in such situations.
+The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](./10-legacy/01-auth-modules.md) should continue to be utilized in such situations.
 
 ## Packet callbacks
 

docs/versioned_docs/version-v8.1.x/03-light-clients/04-wasm/01-overview.md

@@ -13,7 +13,7 @@ Learn about the `08-wasm` light client proxy module.
 
 ### Context
 
-Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](../../../../architecture/adr-010-light-clients-as-sdk-modules.md). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. 
+Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](/architecture/adr-010-light-clients-as-sdk-modules). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. 
 
 ### Motivation
 

e2e/README.md

@@ -63,7 +63,7 @@ The images which are used only exist on your machine.
 These environment variables allow us to run tests with arbitrary versions (from branches or released) of simd
 and the go relayer.
 
-Every time changes are pushed to a branch or to `main`, a new `simd` image is built and pushed [here](https://github.com/cosmos/ibc-go/pkgs/container/ibc-go-simd).
+Every time changes are pushed to a branch or to `main`, a new `simd` image is built and pushed [here](https://github.com/orgs/cosmos/packages?repo_name=ibc-go).
 
 ### Example Command
 
@@ -232,7 +232,7 @@ There are two main github actions for e2e tests.
 
 [e2e-fork.yaml](https://github.com/cosmos/ibc-go/blob/main/.github/workflows/e2e-fork.yml) which runs when forks are created.
 
-In `e2e.yaml`, the `simd` image is built and pushed to [a registry](https://github.com/cosmos/ibc-go/pkgs/container/ibc-go-simd) and every test
+In `e2e.yaml`, the `simd` image is built and pushed to [a registry](https://github.com/orgs/cosmos/packages?repo_name=ibc-go) and every test
 that is run uses the image that was built.
 
 In `e2e-fork.yaml`, images are not pushed to this registry, but instead remain local to the host runner.