Refactor TS Docs

docs/typescript/examples/checkout-tutorial.md

@@ -55,7 +55,7 @@ The handler is implemented in this `webCheckout` function and served from HTTP P
 static async webCheckout(@ArgOptional key: string): Promise<string> {
 ```
 
-It accepts an optional parameter `key`, used to invoke the checkout workflow [idempotently](../tutorials/programmingmodel/idempotency-tutorial).
+It accepts an optional parameter `key`, used to invoke the checkout workflow [idempotently](../tutorials/idempotency-tutorial).
 If a workflow is invoked many times with the same idempotency key (for example, because a customer pressed the buy button many times), it only executes once.
 
 ### Invoking the checkout workflow
@@ -68,7 +68,7 @@ const handle = const handle = await DBOS.startWorkflow(Shop, {workflowID: key}).
 ```
 
 ### Awaiting payment information
-After invoking the checkout workflow, the handler uses the DBOS [events API](../tutorials/programmingmodel/workflow-communication-tutorial#events-api) to await a notification from the checkout workflow that the payment session is ready.
+After invoking the checkout workflow, the handler uses the DBOS [events API](../tutorials/workflow-tutorial.md#workflow-events) to await a notification from the checkout workflow that the payment session is ready.
 We will see in the next section how the checkout workflow notifies the handler.
 Upon receiving the payment session ID, it generates a link to submit payment and returns it to the customer.
 
@@ -122,7 +122,7 @@ static async checkoutWorkflow(): Promise<void> {
 
 ### Reserving inventory
 Before purchasing an item, the checkout workflow reserves inventory for the order using the `reserveInventory` transaction.
-If this fails (likely because the item is out of stock), the workflow notifies its handler of the failure using the [events API](../tutorials/programmingmodel/workflow-communication-tutorial#events-api) and returns.
+If this fails (likely because the item is out of stock), the workflow notifies its handler of the failure using the [events API](../tutorials/workflow-tutorial.md#workflow-events) and returns.
 
 ```javascript
 // Attempt to update the inventory. Signal the handler if it fails.
@@ -136,7 +136,7 @@ try {
 ```
 
 ### Initiating a payment session
-Next, the workflow initiates a payment session using the `createPaymentSession` [step](../tutorials/programmingmodel/step-tutorial).
+Next, the workflow initiates a payment session using the `createPaymentSession` [step](../tutorials/step-tutorial).
 If this fails, it returns reserved items using the `undoReserveInventory` transaction, notifies its handler, and returns.
 ```javascript
 // Attempt to start a payment session. If it fails, restore inventory state and signal the handler.
@@ -152,16 +152,16 @@ if (!paymentSession.url) {
 ### Notifying the handler
 
 After initiating a payment ession, the workflow notifies its handler that the payment session is ready.
-We use [setEvent](../tutorials/programmingmodel/workflow-communication-tutorial#setevent) to publish the payment session ID to the workflow's `session_topic`, on which the handler is awaiting a notification.
+We use `DBOS.setEvent` to publish the payment session ID to the workflow's `session_topic`, on which the handler is awaiting a notification.
 ```javascript
 // Notify the handler of the payment session ID.
 await DBOS.setEvent(session_topic, paymentSession.session_id);
 ```
 
 ### Waiting for a payment
 After notifying its handler, the checkout workflow waits for the payment service to notify it whether the customer has paid.
-We await this notification using the [`recv`](../tutorials/programmingmodel/workflow-communication-tutorial#recv) method from the DBOS [messages API](../tutorials/programmingmodel/workflow-communication-tutorial.md).
-When the customer pays, the payment service sends a callback HTTP request to a separate callback handler (omitted for brevity, source code in `src/utilities.ts`), which notifies the checkout workflow via [`send`](../tutorials/programmingmodel/workflow-communication-tutorial.md#send).
+We await this notification using the `DBOS.recv` method from the DBOS [messages API](../tutorials/workflow-tutorial.md#workflow-messaging-and-notifications).
+When the customer pays, the payment service sends a callback HTTP request to a separate callback handler (omitted for brevity, source code in `src/utilities.ts`), which notifies the checkout workflow via [`DBOS.send`].
 
 ```javascript
 // Await a notification from the payment service.

docs/typescript/examples/kafka-alert-queue.md

@@ -32,7 +32,7 @@ export enum AlertStatus {
 }
 ```
 
-In this app we use [Knex](../tutorials/programmingmodel/orms/using-knex.md) for schema management. Our two tables are quite simple. The employee table has a nullable alert_id and the alert table has a nullable employee_name. These are set when an employee is assigned to an alert. Our schema migration file looks like so:
+In this app we use [Knex](../tutorials/orms/using-knex.md) for schema management. Our two tables are quite simple. The employee table has a nullable alert_id and the alert table has a nullable employee_name. These are set when an employee is assigned to an alert. Our schema migration file looks like so:
 ```typescript
 exports.up = async function(knex) {
   await knex.schema.createTable('employee', table => {
@@ -253,9 +253,9 @@ static async checkForExpiredAssignment(employee_name: string, currentDate: Date)
 ## 6. The Workflow to Assign and Release
 
 We now compose a workflow that leverages `getUserAssignment` and `checkForExpiredAssignment` to reliably assign alerts and then release them when they expire. This workflow takes the name of the employee and, optionally, whether this is a request for more time.  It does the following:
-1. use [DBOSDateTime](../reference/libraries.md#currenttimestep) to durably retrieve the workflow start time
+1. use [DBOSDateTime](../reference/libraries.md) to durably retrieve the workflow start time
 2. call `getUserAssignment` to retrieve the assignment status for the employee (creating a new assignment if appropriate)
-3. use [DBOS.setEvent](../tutorials/programmingmodel/workflow-communication-tutorial#setevent) to return the assignment status to the caller
+3. use [DBOS.setEvent](../tutorials/workflow-tutorial.md#setevent) to return the assignment status to the caller
 4. if this is a new assignment, go into a loop that performs durable sleep and calls `checkForExpiredAssignment` to release this assignment when time is up.
 
 In other words, if this is a new assignment, then the workflow runs longer, until the assignment is over. Else, it simply checks the status and returns quickly. We can do this with DBOS because workflows are guaranteed to continue executing to completion. 

docs/typescript/programming-guide.md

@@ -1,7 +1,7 @@
 ---
 sidebar_position: 1
 title: Learn DBOS TypeScript
-pagination_next: typescript/tutorials/programmingmodel/workflow-tutorial
+pagination_next: typescript/tutorials/workflow-tutorial
 pagination_prev: quickstart
 ---
 
@@ -125,7 +125,7 @@ To fix this problem, we'll use DBOS durable execution.
 ## 2. Durable Execution with Workflows
 
 Next, we want to **durably execute** our application: guarantee that it inserts exactly one database record per guestbook signature, even if interrupted or restarted.
-DBOS makes this easy with [workflows](./tutorials/programmingmodel/workflow-tutorial.md).
+DBOS makes this easy with [workflows](./tutorials/workflow-tutorial.md).
 We can add durable execution to our app with **just four lines of code** and an import statement.
 Copy the following code into your `src/main.ts`, replacing its existing contents:
 
@@ -204,7 +204,7 @@ main().catch(console.log);
 Only the **four highlighted lines of code** are needed to enable durable execution.
 
 - First, we annotate `sign_guestbook` and `insert_greeting` as _workflow steps_ on lines 9 and 25.
-- Then, we annotate `greeting_endpoint` as a [_durable workflow_](./tutorials/programmingmodel/workflow-tutorial.md) on line 31.
+- Then, we annotate `greeting_endpoint` as a [_durable workflow_](./tutorials/workflow-tutorial.md) on line 31.
 - Finally, we launch DBOS on line 53.
 
 Because `greeting_endpoint` is now a durably executed workflow, if it's ever interrupted, it automatically resumes from the last completed step.
@@ -252,7 +252,7 @@ To see this in action, replace the `insert_greeting` function in `src/main.ts` w
   }
 ```
 
-[`@DBOS.transaction()`](./tutorials/programmingmodel/transaction-tutorial.md) is a special annotation for workflow steps that access the database.
+[`@DBOS.transaction()`](./tutorials/transaction-tutorial.md) is a special annotation for workflow steps that access the database.
 It executes your function in a single database transaction.
 We recommend using transactions because:
 

docs/typescript/reference/configuration.md

@@ -46,7 +46,7 @@ Every field is required unless otherwise specified.
 - **ssl_ca** (optional): If using SSL/TLS to securely connect to a database, path to an SSL root certificate file.  Equivalent to the [`sslrootcert`](https://www.postgresql.org/docs/current/libpq-ssl.html) connection parameter in `psql`.
 - **connectionTimeoutMillis** (optional): Database connection timeout in milliseconds. Defaults to `3000`.
 - **local_suffix** (optional): Whether to suffix `app_db_name` with '_local'. Set to true when doing local development using a DBOS Cloud database. For local development only, not used in DBOS Cloud.
-- **migrate** (optional): A list of commands to run to apply your application's schema to the database. We recommend using a TypeScript-based migration tool like [Knex](../tutorials/programmingmodel/orms/using-knex.md#schema-management), [Drizzle](../tutorials/programmingmodel/orms/using-drizzle.md#schema-management), [TypeORM](../tutorials/programmingmodel//orms/using-typeorm.md#schema-management), or [Prisma](../tutorials/programmingmodel/orms/using-prisma.md#schema-management).
+- **migrate** (optional): A list of commands to run to apply your application's schema to the database. We recommend using a TypeScript-based migration tool as documented [here](../tutorials/transaction-tutorial.md#schema-management).
 - **rollback** (optional) A list of commands to run to roll back the last batch of schema migrations.
 
 **Example**:

docs/typescript/reference/tools/cli.md

@@ -114,7 +114,7 @@ For each retrieved workflow, emit a JSON whose fields are:
 - `status`: The status of the workflow
 - `workflowName`: The name of the workflow function
 - `workflowClassName`: The name of the class in which the workflow function is implemented
-- `workflowConfigName`: If the workflow is in a [configured class](../../tutorials/programmingmodel/configured-instances.md), the name of the configuration
+- `workflowConfigName`: If the workflow is in a [configured class](../../tutorials/instantiated-objects), the name of the configuration
 - `authenticatedUser`: The user who ran the workflow, if specified
 - `assumedRole`: The role with which the workflow ran, if specified
 - `authenticatedRoles`: All roles which the authenticated user could assume
@@ -139,7 +139,7 @@ A JSON whose fields are:
 - `status`: The status of the workflow
 - `workflowName`: The name of the workflow function
 - `workflowClassName`: The name of the class in which the workflow function is implemented
-- `workflowConfigName`: If the workflow is in a [configured class](../../tutorials/programmingmodel/configured-instances.md), the name of the configuration
+- `workflowConfigName`: If the workflow is in a [configured class](../../tutorials/instantiated-objects), the name of the configuration
 - `authenticatedUser`: The user who ran the workflow, if specified
 - `assumedRole`: The role with which the workflow ran, if specified
 - `authenticatedRoles`: All roles which the authenticated user could assume

docs/typescript/reference/tools/dbos-compiler.md

@@ -16,7 +16,7 @@ npm install --save-dev @dbos-inc/dbos-compiler
 
 ## Stored Procedure Versioning
 
-Since [@StoredProcedure](../../tutorials/programmingmodel/stored-proc-tutorial.md) functions must be tied to a specific [application version](../../../cloud-tutorials/application-management#managing-application-versions), both DBOS Transact and the DBOS Compiler are version aware. 
+Since [@StoredProcedure](../../tutorials/stored-proc-tutorial.md) functions must be tied to a specific [application version](../../../cloud-tutorials/application-management#managing-application-versions), both DBOS Transact and the DBOS Compiler are version aware. 
 By default, the application version is specified via the `DBOS__APPVERSION` environment variable, but can also be controlled via command line parameters.
 When a application version is specified, the DBOS Compiler will automatically prefix generated stored procedures with `v` and the application version.
 Likewise, DBOS Transact will automatically invoke prefixed versions of the deployed stored procedures when the application version is specified.