Fix links into newly broken down Move doc (MystenLabs#3347)

README.md

@@ -7,7 +7,7 @@
 ## Quick links
 
 * To learn how to use Sui, take our [end-to-end tutorial](doc/src/explore/tutorials.md).
-* To jump right into building smart contract applications on top of Sui, start at the [Move Smart Contract Quick Start](doc/src/build/move.md).
+* To jump right into building smart contract applications on top of Sui, start at the [Move Smart Contract Quick Start](doc/src/build/move/index.md).
 * To experiment with the Sui CLI client, check out [Sui CLI client Quick Start](doc/src/build/cli-client.md).
 * To understand what's possible by browsing Move code built on top of Sui, review the [examples](doc/src/explore/examples.md).
 * To start coding against Sui's JSON-RPC APIs, start at [JSON-RPC API Quick Start](doc/src/build/json-rpc.md).

doc/src/build/cli-client.md

@@ -884,7 +884,7 @@ From the result, we can see three new coins were created in the transaction.
 
 The genesis state of the Sui platform includes Move code that is
 immediately ready to be called from Sui CLI. Please see our
-[Move developer documentation](move.md#first-look-at-move-source-code)
+[Move developer documentation](move/index.md#first-look-at-move-source-code)
 for the first look at Move source code and a description of the
 following function we will be calling in this tutorial:
 
@@ -1019,14 +1019,14 @@ id: 0x471c8e241d0473c34753461529b70f9c4ed3151b[1]
 
 In order for user-written code to be available in Sui, it must be
 *published* to Sui's [distributed ledger](../learn/how-sui-works.md#architecture).
-Please see the [Move developer documentation](move.md) for a
-description on how to [write a simple Move code package](move.md#writing-a-package),
+Please see the [Move developer documentation](move/index.md) for a
+description on how to [write a simple Move code package](move/write-package.md),
 which we can publish using Sui client's `publish` command.
 
 The publish command
 requires us to specify a directory where the user-defined package lives.
 It's the path to the `my_move_package` as per the
-[package creation description](move.md#writing-a-package), a gas
+[package creation description](move/write-package.md), a gas
 object that will be used to pay for publishing the package (we use the
 same gas object we used to pay for the function call in the
 [Calling Move code](#calling-move-code)) section, and gas budget to put
@@ -1093,7 +1093,7 @@ Another object created as a result of package publishing is a
 user-defined object (of type `Forge`) crated inside initializer
 function of the (only) module included in the published package - see
 the part of Move developer documentation concerning [module
-initializers](move.md#module-initializers) for more details on module
+initializers](move/debug-publish.md#module-initializers) for more details on module
 initializers.
 
 Finally, we see that the gas object that was used to pay for

doc/src/build/index.md

@@ -9,11 +9,10 @@ Now that you've [learned about Sui](../learn/index.md), it's time to start build
 Here is our recommended workflow to interact with Sui:
 
 1. [Install](../build/install.md) all of the *required tools*.
-1. [Quickstart](../build/move.md) Move *smart contract*s:
-   1. [Write](../build/move.md#writing-a-package) a package.
-   1. [Test](../build/move.md#testing-a-package) a package.
-   1. [Debug](../build/move.md#debugging-a-package) a package.
-   1. [Publish](../build/move.md#publishing-a-package) a package.
+1. [Write](../build/move/index.md) *smart contracts* with Move:
+   1. [Write](../build/move/write-package.md) a package.
+   1. [Build and test](../build/move/build-test.md) a package.
+   1. [Debug and publish](../build/move/debug-publish.md) a package.
 1. [Create](../build/cli-client.md#genesis) and [Start](../build/cli-client.md#starting-the-network) a *local Sui network*.
 1. [Start](../build/json-rpc.md#start-local-rpc-server) a *local JSON-RPC Gateway server*.
 1. [Connect](../build/cli-client.md#rpc-gateway) to the Sui network Gateway service with the *Sui CLI client*.

doc/src/build/install.md

@@ -138,7 +138,7 @@ $ cargo install --locked --git https://github.com/MystenLabs/sui.git --branch "d
 ```
 
 This will put the following binaries in your `PATH` (ex. under `~/.cargo/bin`) that provide these command line interfaces (CLIs):
-* sui - The Sui CLI tool contains subcommands for enabling `genesis` of validators and accounts, starting the Sui network, and [building and testing Move packages](move.md), as well as a [client](cli-client.md) for interacting with the Sui network.
+* sui - The Sui CLI tool contains subcommands for enabling `genesis` of validators and accounts, starting the Sui network, and [building and testing Move packages](move/index.md), as well as a [client](cli-client.md) for interacting with the Sui network.
 * [`rpc-server`](json-rpc.md) - run a local Sui gateway service accessible via an RPC interface.
 
 Confirm the installation with:
@@ -216,7 +216,7 @@ To contribute updates to Sui code, [send pull requests](../contribute/index.md#s
 
 Continue your journey through:
 
-* [Smart Contracts with Move](move.md)
+* [Smart Contracts with Move](move/index.md)
 * [Sui client Quick Start](cli-client.md)
 * [RPC Server API](json-rpc.md)
 * [End-to-End tutorial](../explore/tutorials.md)

doc/src/build/json-rpc.md

@@ -193,7 +193,7 @@ be owned by the address represented by `{{owner_address}}`.
 
 #### 1, Execute a Move call transaction by calling the specified function in
 the module of a given package (smart contracts in Sui are written in
-the [Move](move.md#move) language):
+the [Move](move/index.md) language):
 
 ```shell
 curl --location --request POST $SUI_RPC_HOST \
@@ -251,7 +251,7 @@ curl --location --request POST $SUI_RPC_HOST \
 ```
 
 This endpoint will perform proper verification and linking to make
-sure the package is valid. If some modules have [initializers](move.md#module-initializers), these initializers
+sure the package is valid. If some modules have [initializers](move/debug-publish.md#module-initializers), these initializers
 will also be executed in Move (which means new Move objects can be created in
 the process of publishing a Move package). Gas budget is required because of the
 need to execute module initializers.

doc/src/build/objects.md

@@ -20,7 +20,7 @@ In addition to common metadata, objects have a category-specific, variable-sized
 Every object has a *owner* field that indicates how this object is being owned. The ownership dictates how an object can be used in transactions. There are 4 different types of ownership:
 
 **Owned by an account address**
-This is the most common case for Move objects. A Move object upon creation in the Move code, can be [transferred](move.md#sui-move-library) to an account address. After the transfer, this object will be owned by that account address. An object owned by an account address can only be used (i.e. passed as a Move call parameter) by transactions signed by that owner account. Owned object can be passed as Move call parameter in any of the 3 forms: read-only reference (`&T`), mutable reference (`&mut T`) and by-value (`T`). It's important to note that even if an object is passed by read-only reference (`&T`) in a Move call, it's still required that only the owner of the object can make such a call. That is, the intention of the Move call is irrelevant when it comes to authenticate whether an object can be used in a transaction, the ownership is what matters.
+This is the most common case for Move objects. A Move object upon creation in the Move code, can be [transferred](move/sui-move-library.md) to an account address. After the transfer, this object will be owned by that account address. An object owned by an account address can only be used (i.e. passed as a Move call parameter) by transactions signed by that owner account. Owned object can be passed as Move call parameter in any of the 3 forms: read-only reference (`&T`), mutable reference (`&mut T`) and by-value (`T`). It's important to note that even if an object is passed by read-only reference (`&T`) in a Move call, it's still required that only the owner of the object can make such a call. That is, the intention of the Move call is irrelevant when it comes to authenticate whether an object can be used in a transaction, the ownership is what matters.
 
 **Owned by another object**
 An object can be owned by another object. It's important to distinguish this direct ownership from *object wrapping*. An object can be wrapped/embedded in another object when you have a field of one object's struct definition to be another object type. For example:
@@ -31,10 +31,10 @@ struct A {
 }
 ```
 defines a object type `A` that contains a field whose type is another object type `B`. In this case, we say an object of type `B` is wrapped into an object of type `A`. With object wrapping, the wrapped object (in this example, object `b`) is not stored as a top-level object in Sui storage, and it's not accessible by object ID. Instead, it's simply part of the serialized bytes content of an object of type `A`. You can think of the case of an object being wrapped similar to being deleted, except its content still exist somewhere in another object.
-Now back to the topic of object owned by another object. When an object is owned by another object, it's not wrapped. This means the child object still exists independently as a top-level object and can be accessed directly in the Sui storage. The ownership relationship is only tracked through the owner field of the child object. This can be useful if you still want to observe the child object or be able to use it in other transactions. We provide library APIs to make an object owned by another object. More details on how to do this can be found in [the Move library doc](move.md#sui-move-library)
+Now back to the topic of object owned by another object. When an object is owned by another object, it's not wrapped. This means the child object still exists independently as a top-level object and can be accessed directly in the Sui storage. The ownership relationship is only tracked through the owner field of the child object. This can be useful if you still want to observe the child object or be able to use it in other transactions. We provide library APIs to make an object owned by another object. More details on how to do this can be found in the [Sui Move library](move/sui-move-library.md).
 
 **Immutable**
-This means an object is immutable and cannot be mutated by anyone. Because of this, such an object doesn't have an exclusive owner. Anyone can use it in their Move calls. All Move packages are immutable objects: once published, they cannot be changed. A Move object can be turned into an immutable object through the [*freeze_object*](move.md#sui-move-library) library API. An immutable object can only passed as a read-only reference (`&T`) in Move calls.
+This means an object is immutable and cannot be mutated by anyone. Because of this, such an object doesn't have an exclusive owner. Anyone can use it in their Move calls. All Move packages are immutable objects: once published, they cannot be changed. A Move object can be turned into an immutable object through the [*freeze_object*](move/sui-move-library.md) library API. An immutable object can only passed as a read-only reference (`&T`) in Move calls.
 
 **Shared (WIP)**
 An object can be shared, meaning that anyone can use and mutate this object. Proper support of this is still being developed in Sui. A more detailed explanation about shared object support will come online soon. Here is a brief primer: for any other mutable object that's not shared, no two transactions can be mutating the same object at the same time since a transaction is pinned on a specific (and must be the latest) version of each object, hence Sui doesn't need to worry about reaching a consensus or ordering (it's ordered by construction). However for shared objects, in order to allow multiple transactions mutating the same object at the same time, we need a sequencer to properly order these transactions. Because of this, using a shared object can be much more expensive in terms of latency, throughput and gas cost. On the other hand, a shared object is also a powerful primitive that allows for expressing richer behavior that doesn't require central trust. Examples of this difference can be found in the two different implementations of TicTacToe in our Move examples.

doc/src/build/programming-with-objects/ch1-object-basics.md

@@ -29,7 +29,7 @@ Now `ColorObject` represents a Sui object type and can be used to create Sui obj
 > :bulb: The `Info` type is internal to Sui, and you most likely won't need to deal with it directly. For curious readers, it contains the unique `ID` of the object and the version of the object. Each time a mutable object is used in a transaction, its version will increase by 1.
 
 ### Create Sui object
-Now that we have learned how to define a Sui object type, how do we create/instantiate a Sui object? In order to create a new Sui object from its type, we must assign an initial value to each of the fields, including `info`. The only way to create a new unique `Info` for a Sui object is to call `object::new`. The `new` function takes the current transaction context as an argument to generate unique IDs. The transaction context is of type `&mut TxContext` and should be passed down from an [entry function](../move.md#entry-functions) (a function that can be called directly from a transaction). Let's look at how we may define a constructor for `ColorObject`:
+Now that we have learned how to define a Sui object type, how do we create/instantiate a Sui object? In order to create a new Sui object from its type, we must assign an initial value to each of the fields, including `info`. The only way to create a new unique `Info` for a Sui object is to call `object::new`. The `new` function takes the current transaction context as an argument to generate unique IDs. The transaction context is of type `&mut TxContext` and should be passed down from an [entry function](../move/index.md#entry-functions) (a function that can be called directly from a transaction). Let's look at how we may define a constructor for `ColorObject`:
 ```rust
 // object represents the object module, which allows us call
 // functions in the module, such as the `new` function, without fully
@@ -93,7 +93,7 @@ sui move build
 ### Writing unit tests
 After defining the `create` function, we want to test this function in Move using unit tests, without having to go all the way through sending Sui transactions. Since [Sui manages global storage separately outside of Move](../../learn/sui-move-diffs.md#object-centric-global-storage), there is no direct way to retrieve objects from global storage within Move. This poses a question: after calling the `create` function, how do we check that the object is properly transferred?
 
-To assist easy testing in Move, we provide a comprehensive testing framework in the [test_scenario](https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/sources/test_scenario.move) module that allows us to interact with objects put into the global storage. This allows us to test the behavior of any function directly in Move unit tests. A lot of this is also covered in our [Move testing doc](../move.md#sui-specific-testing).
+To assist easy testing in Move, we provide a comprehensive testing framework in the [test_scenario](https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/sources/test_scenario.move) module that allows us to interact with objects put into the global storage. This allows us to test the behavior of any function directly in Move unit tests. A lot of this is also covered in our [Move testing doc](../move/build-test.md#sui-specific-testing).
 
 The idea of `test_scenario` is to emulate a series of Sui transactions, each sent from a particular address. A developer writing a test starts the first transaction using the `test_scenario::begin` function that takes the address of the user sending this transaction as an argument and returns an instance of the `Scenario` struct representing a test scenario.
 

doc/src/build/programming-with-objects/ch2-using-objects.md

@@ -4,7 +4,7 @@ title: Chapter 2 - Using Objects
 
 In [Chapter 1](./ch1-object-basics.md) we covered how to define, create and take ownership of a Sui object in Move. In this chapter we will look at how to use objects that you own in Move calls.
 
-Sui authentication mechanisms ensure only you can use objects owned by you in Move calls. (We will cover non-owned objects in future chapters.) To use an object in Move calls, pass them as parameters to an [entry function](../move.md#entry-functions). Similar to Rust, there are a few ways to pass parameters:
+Sui authentication mechanisms ensure only you can use objects owned by you in Move calls. (We will cover non-owned objects in future chapters.) To use an object in Move calls, pass them as parameters to an [entry function](../move/index.md#entry-functions). Similar to Rust, there are a few ways to pass parameters:
 
 ### Pass objects by reference
 There are two ways to pass objects by reference: read-only references (`&T`) and mutable references (`&mut T`). Read-only references allow you to read data from the object, while mutable references allow you to mutate the data in the object. Let's try to add a function that would allow us to update one of `ColorObject`'s values with another `ColorObject`'s value. This will exercise using both read-only references and mutable references.

doc/src/build/programming-with-objects/index.md

@@ -2,15 +2,15 @@
 title: Programming Objects Tutorial Series
 ---
 
-Sui is a blockchain centered on [objects](../../build/objects.md). Once you start programming non-trivial [smart contracts](../../build/move.md) on Sui, you will start dealing with Sui objects in the code. Sui includes a rich, comprehensive library and testing framework to allow you interact with objects in a safe and yet flexible way.
+Sui is a blockchain centered on [objects](../../build/objects.md). Once you start programming non-trivial [smart contracts](../../build/move/index.md) on Sui, you will start dealing with Sui objects in the code. Sui includes a rich, comprehensive library and testing framework to allow you interact with objects in a safe and yet flexible way.
 
 In this tutorial series, we will walk through all the powerful ways to interact with objects in [Sui Move](../../learn/sui-move-diffs.md). At the end, we will also explore the designs of a few (close-to-)real-world examples to demonstrate the tradeoffs of using different object types and ownership relationships.
 
 ## Prerequisites
 
 Understand:
 - [Learn about Sui](../../learn/about-sui.md)
-- [Smart Contracts with Move](../../build/move.md)
+- [Smart Contracts with Move](../../build/move/index.md)
 - [Sui Objects](../../build/objects.md)
 
 Install:

doc/src/build/transactions.md

@@ -65,6 +65,6 @@ Inputs: A list of unique object references pointing to mutable objects owned by
 
 ## Further reading
 
-* See the [Move Quick Start](move.md) to learn about smart contracts.
+* See the [Move tutorial](move/index.md) to develop Sui smart contracts.
 * Transactions take objects as input and produce objects as output--learn about the [objects](objects.md), their structure and attributes.
 * Transactions are executed by Sui [validators](../learn/architecture/validators.md).