Link fixes detailed in FAB-18494

Signed-off-by: Nikhil Gupta <ngupta@symbridge.com>

docs/source/advice_for_writers.md

@@ -17,7 +17,7 @@ In this topic, we're going to cover:
 
 Before you make a documentation change, you might like to connect with other
 people working on the Fabric documentation. Your [Linux Foundation
-account](./contributing.html#getting-a-linux-foundation-account) will give you
+account](./CONTRIBUTING.html#getting-a-linux-foundation-account) will give you
 access to many different resources to help you connect with other contributors
 to the documentation.
 
@@ -67,7 +67,7 @@ Each workgroup has a list of members and their contact information.
 
 Hyperledger Fabric has many other collaboration mechanisms such as mailing
 lists, contributor meetings and maintainer meetings. Find out about these and
-more [here](./contributing.html).
+more [here](./CONTRIBUTING.html).
 
 Good luck getting started and thanks for your contribution.
 

docs/source/capabilities_concept.md

@@ -36,7 +36,7 @@ As we discussed earlier, there is not a single capability level encompassing an
 
 While it is possible to create an ordering service using a legacy process in which a "system channel" administered by the ordering service is created before any application channels are created, the recommended path is to create a channel without using a system channel.
 
-If you do use the [legacy system channel process](./create_channel/create_channel.html), the **orderer** and **channel** capabilities of a channel are inherited by default from the ordering system channel, where modifying them are the exclusive purview of ordering service admins. As a result, peer organizations should inspect the genesis block of a channel prior to joining their peers to that channel. Although the channel capability is administered by the orderers in the orderer system channel (just as the consortium membership is), it is typical and expected that the ordering admins will coordinate with the consortium admins to ensure that the channel capability is only upgraded when the consortium is ready for it. Note: because the ordering system channel does not define an **application** capability, this capability must be specified in the channel profile when creating the genesis block for the channel.
+If you do use the [legacy system channel process](./create_channel/create_channel_test_net.html), the **orderer** and **channel** capabilities of a channel are inherited by default from the ordering system channel, where modifying them are the exclusive purview of ordering service admins. As a result, peer organizations should inspect the genesis block of a channel prior to joining their peers to that channel. Although the channel capability is administered by the orderers in the orderer system channel (just as the consortium membership is), it is typical and expected that the ordering admins will coordinate with the consortium admins to ensure that the channel capability is only upgraded when the consortium is ready for it. Note: because the ordering system channel does not define an **application** capability, this capability must be specified in the channel profile when creating the genesis block for the channel.
 
 If you use the recommended process to [Create a channel](./create_channel/create_channel_participation.html), all these capability levels are specified in the application channel genesis block that is created.
 

docs/source/config_update.md

@@ -941,7 +941,7 @@ However, as you'll see, this conceptual simplicity is wrapped in a somewhat conv
 We have two tutorials that deal specifically with editing a channel configuration to achieve a specific end:
 
 * [Adding an Org to a Channel](./channel_update_tutorial.html): shows the process for adding an additional organization to an existing channel.
-* [Updating channel capabilities](./updating_a_channel.html): shows how to update channel capabilities.
+* [Updating channel capabilities](./updating_capabilities.html): shows how to update channel capabilities.
 
 In this topic, we'll show the process of editing a channel configuration independent of the end goal of the configuration update.
 
@@ -994,7 +994,7 @@ At this point, you have two options of how you want to modify the config.
 1. Open ``modified_config.json`` using the text editor of your choice and make edits. Online tutorials exist that describe how to copy a file from a container that does not have an editor, edit it, and add it back to the container.
 2. Use ``jq`` to apply edits to the config.
 
-Whether you choose to edit the config manually or using `jq` depends on your use case. Because `jq` is concise and scriptable (an advantage when the same configuration update will be made to multiple channels), it's the recommend method for performing a channel update. For an example on how `jq` can be used, check out [Updating channel capabilities](./updating_a_channel.html#Create-a-capabilities-config-file), which shows multiple `jq` commands leveraging a capabilities config file called `capabilities.json`. If you are updating something other than the capabilities in your channel, you will have to modify your `jq` command and JSON file accordingly.
+Whether you choose to edit the config manually or using `jq` depends on your use case. Because `jq` is concise and scriptable (an advantage when the same configuration update will be made to multiple channels), it's the recommend method for performing a channel update. For an example on how `jq` can be used, check out [Updating channel capabilities](./updating_capabilities.html#Create-a-capabilities-config-file), which shows multiple `jq` commands leveraging a capabilities config file called `capabilities.json`. If you are updating something other than the capabilities in your channel, you will have to modify your `jq` command and JSON file accordingly.
 
 For more information about the content and structure of a channel configuration, check out our [sample channel config](#Sample-channel-configuration) above.
 

docs/source/create_channel/create_channel_config.md

@@ -17,7 +17,7 @@ You can use this tutorial to learn how to use the `configtx.yaml` file to build
 
 Because different sections of the file work together to create the policies that govern the channel, we will discuss channel policies in [their own tutorial](channel_policies.html).
 
-Building off of the [Creating a channel tutorial](create_channel.html), we will use the `configtx.yaml` file that is used to deploy the Fabric test network as an example. Open a command terminal on your local machine and navigate to the `test-network` directory in your local clone of the Fabric samples:
+Building off of the [Creating a channel tutorial](create_channel_participation.html), we will use the `configtx.yaml` file that is used to deploy the Fabric test network as an example. Open a command terminal on your local machine and navigate to the `test-network` directory in your local clone of the Fabric samples:
 ```
 cd fabric-samples/test-network
 ```

docs/source/create_channel/create_channel_test_net.md

@@ -61,7 +61,7 @@ By default, when you start the test network, it does not contain any channels. T
 
 ### Set up the configtxgen tool
 
-Channels are created by generating a channel creation transaction in a genesis block, and then passing that genesis block to an ordering service node in a join request. The channel creation transaction specifies the initial configuration of the channel and can be created by the [configtxgen](../commands/configtxgen.html) tool. The tool reads the `configtx.yaml` file that defines the configuration of our channel, and then writes the relevant information into the channel creation transaction and outputs a genesis block including the channel creation transaction. When you [installed Fabric](install.html), the `configtxgen` tool was installed in the `fabric-samples\bin` directory for you.
+Channels are created by generating a channel creation transaction in a genesis block, and then passing that genesis block to an ordering service node in a join request. The channel creation transaction specifies the initial configuration of the channel and can be created by the [configtxgen](../commands/configtxgen.html) tool. The tool reads the `configtx.yaml` file that defines the configuration of our channel, and then writes the relevant information into the channel creation transaction and outputs a genesis block including the channel creation transaction. When you [installed Fabric](../install.html), the `configtxgen` tool was installed in the `fabric-samples\bin` directory for you.
 
 Ensure that you are still operating from the `test-network` directory of your local clone of `fabric-samples` and run this command:
 

docs/source/developapps/gateway.md

@@ -39,7 +39,7 @@ A gateway can be used by an application in two different ways:
   these roles in the connection profile [topic](./connectionprofile.html).
 
   The SDK will use this static topology, in conjunction with gateway
-  [connection options](./connectionoptions), to manage the transaction
+  [connection options](connectionoptions.html), to manage the transaction
   submission and notification processes. The connection profile must contain
   enough of the network topology to allow a gateway to interact with the
   network on behalf of the application; this includes the network channels,

docs/source/developapps/transactionhandler.md

@@ -85,7 +85,7 @@ shows you the exact form of these handlers.
 
 Once a handler has been added to the smart contract, it will be invoked during
 transaction processing. During processing, the handler receives `ctx`, the
-[transaction context](./transationcontext.md), performs some processing, and
+[transaction context](transationcontext.html), performs some processing, and
 returns control as it completes. Processing continues as follows:
 
 * **Before handler**: If the handler completes successfully, the transaction is

docs/source/developapps/wallet.md

@@ -144,7 +144,7 @@ particular `identityLabel`.
 The `Gateway` class only requires the `mspId` and `type` metadata to be set for
 an identity -- `Org1MSP` and `X.509` in the above example. It *currently* uses the
 MSP ID value to identify particular peers from a [connection profile](./connectionprofile.html),
-for example when a specific notification [strategy](./connectoptions.html) is
+for example when a specific notification [strategy](./connectionoptions.html) is
 requested. In the DigiBank gateway file `networkConnection.yaml`, see how
 `Org1MSP` notifications will be associated with `peer0.org1.example.com`:
 

docs/source/kafka_raft_migration.md

@@ -185,7 +185,7 @@ channel, and elect a leader on each channel.
 **Note**: Since the Raft-based ordering service uses client and server TLS certificates for
 authentication between orderer nodes, **additional configurations** are required before
 you start them again, see
-[Section: Local Configuration](./raft_configuration.md#local-configuration) for more details.
+[Section: Local Configuration](raft_configuration.html#local-configuration) for more details.
 
 After restart process finished, make sure to **validate** that a
 leader has been elected on each channel by inspecting the node logs (you can see

docs/source/secured_asset_transfer/secured_private_asset_transfer_tutorial.md

@@ -4,7 +4,7 @@ This tutorial will demonstrate how an asset can be represented and traded betwee
 Each on-chain asset is a non-fungible token (NFT) that represents a specific asset having certain immutable metadata properties (such as size and color) with a unique owner. When the owner wants to sell the asset, both parties need to agree to the same price before the asset is transferred. The private asset transfer smart contract enforces that only the owner of the asset can transfer the asset. In the course of this tutorial, you will learn how Fabric features such as state based endorsement, private data, and access control come together to provide secured transactions that are both private and verifiable.
 
 This tutorial will deploy the [secured asset transfer sample](https://github.com/hyperledger/fabric-samples/tree/main/asset-transfer-secured-agreement/chaincode-go) to demonstrate how to transfer a private asset between two organizations without publicly sharing data. You should have completed the task
-[Install Samples, Binaries, and Docker Images](./install.html#install-samples-binaries-and-docker-images).
+[Install Samples, Binaries, and Docker Images](../install.html#install-samples-binaries-and-docker-images).
 
 
 ## Scenario requirements

docs/source/tutorial/commercial_paper.md

@@ -404,7 +404,7 @@ and approve the chaincode as administrators of both MagnetoCorp and DigiBank.
 administrator installs a copy of the `papercontract` onto a MagnetoCorp peer.*
 
 Smart contracts are the focus of application development, and are contained
-within a Hyperledger Fabric artifact called [chaincode](../chaincode.html). One
+within a Hyperledger Fabric artifact called [chaincode](../chaincode4ade.html). One
 or more smart contracts can be defined within a single chaincode, and installing
 a chaincode will allow them to be consumed by the different organizations in
 PaperNet. It means that only administrators need to worry about chaincode;
@@ -854,7 +854,7 @@ All the time, the underlying Fabric SDK handles the transaction endorsement,
 ordering and notification process, making the application's logic
 straightforward; the SDK uses a [gateway](../developapps/gateway.html) to
 abstract away network details and
-[connectionOptions](../developapps/connectoptions.html) to declare more advanced
+[connectionOptions](../developapps/connectionoptions.html) to declare more advanced
 processing strategies such as transaction retry.
 
 Let's now follow the lifecycle of MagnetoCorp 00001 by switching our emphasis