avoid fragment links

Author: pthmas

.github/workflows/external-link-check.yml

@@ -1,4 +1,4 @@
-name: External Link Checker
+name: Link Checker
 
 on:
   # This workflow requires pull_request and won't work with pull_request_target 
@@ -16,7 +16,7 @@ on:
     #- cron: "00 18 * * *"
 
 jobs:
-  external-link-check:
+  link-check:
     runs-on: ubuntu-latest
     permissions:
       issues: write # required for peter-evans/create-issue-from-file
@@ -27,7 +27,7 @@ jobs:
         id: lychee
         uses: lycheeverse/lychee-action@v2
         with:
-          args: -b . --verbose --no-progress --include-fragments './**/*.md'
+          args: -b . --verbose --no-progress --exclude '%23.*' './**/*.md'
           fail: true
 
       # Uncomment this if you want issues to be created for every dead link

guides/cw-orch.md

@@ -245,7 +245,7 @@ Now that you workspace is setup, you can [integrate with single contracts](#sing
 
 You can find more example interactions on the `counter-contract` example directly in the `cw-orchestrator` repo:  
 
-- Some examples <a href="https://github.com/AbstractSDK/cw-orchestrator/blob/main/contracts/counter/examples/deploy.rs" target="_blank">showcase interacting with live chains</a>.
-- Some other examples show <a href="https://github.com/AbstractSDK/cw-orchestrator/tree/main/contracts/counter/tests" target="_blank">how to use the library for testing your contracts</a>.
+- Some examples <a href="https://github.com/AbstractSDK/cw-orchestrator/blob/main/contracts-ws/contracts/counter/examples/deploy.rs" target="_blank">showcase interacting with live chains</a>.
+- Some other examples show <a href="https://github.com/AbstractSDK/cw-orchestrator/blob/main/contracts-ws/contracts/counter/tests/checksum.rs" target="_blank">how to use the library for testing your contracts</a>.
 
 > **FINAL ADVICE**: Learn more and explore our <a href="https://orchestrator.abstract.money" target="blank" >full `cw-orch` documentation !</a>.

guides/zkml.md

@@ -12,13 +12,13 @@ This approach not only secures the verification process of machine learning mode
 
 ## Prerequisites
 
-- An operational [EVM](/tutorials/beaconkit.md) using Rollkit (see next step)
+- An operational EVM using Rollkit (see next step)
 - A [Sindri](https://sindri.app) API key, which can be obtained [here](https://hen4zp9gxq3.typeform.com/to/hJHlUF8c?typeform-source=sindri.app)
 - Python 3.10+ installed as well as the [Sindri Python SDK](https://sindri.app/docs/reference/sdk/python/) (more information below)
 
 ### Setting Up the Polaris EVM using Rollkit
 
-This walkthrough assumes you started the Polaris EVM using Rollkit and should be interpreted as a direct continuation of this [Polaris EVM and Rollkit guide](https://rollkit.dev/tutorials/polaris-evm).
+This walkthrough assumes you started the Polaris EVM using Rollkit and should be interpreted as a direct continuation of this Polaris EVM and Rollkit guide.
 
 ### Installing the Sindri Python SDK
 

learn/stack.md

@@ -52,17 +52,17 @@ It's using the [Celestia Node API](https://node-rpc-docs.celestia.org)
 via the [`rollkit/celestia-da`](https://github.com/rollkit/celestia-da) package.
 To deploy a Rollkit rollup on Celestia you also have to [run a Celestia light node](https://docs.celestia.org/tutorials/node-tutorial/).
 
-New DA layer integrations can be added by using the [DA interface](https://docs.cosmos.network/v0.50/build/building-apps/app-mempool).
+New DA layer integrations can be added by using the [DA interface](https://github.com/rollkit/rollkit/blob/main/core/da/da.go).
 
 ## Node components
 
 ### Mempool
 
-The [mempool](https://github.com/rollkit/rollkit/tree/main/mempool) is inspired by the CometBFT mempool. By default, transactions are handled in a First Come, First Served (FCFS) manner. Ordering of transactions can be implemented on the application level; currently this is possible by returning a priority on `CheckTx`, and once we support ABCI++ it is also possible via `PrepareProposal` and the [application mempool](https://docs.cosmos.network/v0.47/building-apps/app-mempool).
+The [mempool](https://github.com/rollkit/go-execution-abci/blob/marko/vn/pkg/rpc/core/mempool.go) is inspired by the CometBFT mempool. By default, transactions are handled in a First Come, First Served (FCFS) manner. Ordering of transactions can be implemented on the application level; currently this is possible by returning a priority on `CheckTx`, and once we support ABCI++ it is also possible via `PrepareProposal` and the [application mempool](https://docs.cosmos.network/v0.53/build/building-apps/app-mempool).
 
 ### Block manager
 
-The [block manager](https://github.com/rollkit/rollkit/tree/main/block) contains routines `AggregationLoop`, `RetrieveLoop`, and `SyncLoop` that communicate through Go channels. These Go routines are run when a Rollkit node starts up (`OnStart`). Only the sequencer nodes run `AggregationLoop` which controls the frequency of block production for a rollup with a timer as per the `BlockTime` in `BlockManager`.
+The [block manager](https://github.com/rollkit/rollkit/blob/main/block/manager.go#L101) contains routines `AggregationLoop`, `RetrieveLoop`, and `SyncLoop` that communicate through Go channels. These Go routines are run when a Rollkit node starts up (`OnStart`). Only the sequencer nodes run `AggregationLoop` which controls the frequency of block production for a rollup with a timer as per the `BlockTime` in `BlockManager`.
 
 All nodes run `SyncLoop` which looks for the following operations:
 
@@ -75,7 +75,7 @@ All nodes also run `RetrieveLoop` which is responsible for interacting with the
 
 ### RPC
 
-Rollkit's [RPC](https://github.com/rollkit/rollkit/tree/main/rpc) fully implements the [CometBFT RPC](https://docs.cometbft.com/v0.37/spec/rpc/) interfaces and APIs for querying:
+Rollkit's [RPC](https://github.com/rollkit/rollkit/tree/main/pkg/rpc) fully implements the [CometBFT RPC](https://docs.cometbft.com/v0.37/spec/rpc/) interfaces and APIs for querying:
 
 - **Information about the rollup node**: information such as node's health, status, and network info.
 - **The rollup blockchain**: getting information about the rollup blockchain such as blocks and block headers.
@@ -102,7 +102,7 @@ curl http://127.0.0.1:26657/block?height=included
 
 ### P2P layer
 
-Rollkit's [P2P layer](https://github.com/rollkit/rollkit/tree/main/p2p) enables
+Rollkit's [P2P layer](https://github.com/rollkit/rollkit/tree/main/pkg/p2p) enables
 direct communication between rollup nodes.
 It's used to gossip transactions, headers of newly created blocks, and state fraud proofs.
 The P2P layer is implemented using [libp2p](https://github.com/libp2p).

tutorials/execution/cosmwasm.md

@@ -23,14 +23,12 @@ exploring how to integrate CosmWasm with local DA layer using Rollkit.
 The smart contract we will use for this tutorial is one provided by
 the CosmWasm team for Nameservice purchasing.
 
-You can check out the contract [here](https://github.com/InterWasm/cw-contracts/tree/main/contracts/nameservice).
-
 How to write the Rust smart contract for Nameservice is outside the scope of
 this tutorial.
 
 ## 💻 CosmWasm dependency {#dependencies}
 
-As with the [GM Rollup](https://rollkit.dev/tutorials/gm-world.md), we use [kurtosis](https://docs.kurtosis.com/) to help with managing all the services we need to run. You can [install kurtosis here](https://docs.kurtosis.com/install).
+As with the [GM Rollup](/tutorials/gm-world.md), we use [kurtosis](https://docs.kurtosis.com/) to help with managing all the services we need to run. You can [install kurtosis here](https://docs.kurtosis.com/install).
 
 Once installed, you can verify the installation by running: