docs(nx): 📝 fix broken links

apps/cookbook/docs/nx/02-transitioning/01-set-up-nx.mdx

@@ -166,7 +166,7 @@ While this command works pretty well in most common cases, it is not perfect bec
 - the final result will not be exactly aligned with an Nx workspace created from scratch.
 
 :::tip
-We recommend [creating a new Nx workspace and moving existing code into it](#move-existing-code-into-a-new-nx-workspace).
+We recommend [creating a new Nx workspace and moving existing code into it](#option-2-merge-a-new-nx-workspace-into-an-existing-repository).
 :::
 
 ### Option 2: Merge a new Nx workspace into an existing repository

apps/cookbook/docs/nx/03-scaling/02-organize-libs.md

@@ -19,7 +19,7 @@ You are free to organize your libraries in any way that makes sense to you, your
 However, it is essential to define some rules to avoid ending up with a mess of libraries that are hard to understand and maintain.
 In addition, this will allow us to leverage certain [Nx features that will enforce these rules](./03-boundaries.md) and assist everyone on the team in following them.
 
-### Tags & Categories
+### Tags and Categories
 
 Nx allows us to tag our applications and libraries with custom tags.
 
@@ -49,7 +49,7 @@ Tags can be used to categorize libraries based on different criteria. They are u
 
 The first dimension of categories that can help you organize your libraries across various architectural styles is the `type` dimension.
 
-This group is commonly used to define **horizontal layers**, or in other words, to **segregate the technical responsibility** of the library _(e.g., container components vs. presentational components for the frontend, or controllers vs. repositories for the backend)_. Some common type categories are `feature`, `ui`, `data-access`, or `infra`. These are just examples that will be elaborated on [below](#library-categorization-examples).
+This group is commonly used to define **horizontal layers**, or in other words, to **segregate the technical responsibility** of the library _(e.g., container components vs. presentational components for the frontend, or controllers vs. repositories for the backend)_. Some common type categories are `feature`, `ui`, `data-access`, or `infra`. These are just examples that will be elaborated on [below](#library-type-categorization-examples).
 
 :::note
 The naming convention in the Nx community is to prefix the tags with `type:` _(e.g. `type:ui`)_.

apps/cookbook/docs/nx/03-scaling/03-boundaries.md

@@ -1,9 +1,8 @@
 ---
-draft: true
 slug: /nx/boundaries
 ---
 
-# 🚧 Enforce boundaries
+# Enforce boundaries
 
 Once you [have established the organization of your workspace and libraries](./02-organize-libs.md), and the underlying rules, you will probably want to enforce them.
 
@@ -14,10 +13,3 @@ As a matter of fact, even with the best intentions, it is easy to break the rule
 Here is where the [Nx eslint plugin](https://nx.dev/nx-api/eslint-plugin) _(`@nx/eslint-plugin`)_ comes into play. More precisely, the `depConstraints` option of the [`@nx/enforce-module-boundaries` rule](https://nx.dev/nx-api/eslint-plugin/documents/enforce-module-boundaries) allows you to enforce the boundaries you have defined for your workspace. For instance, it will prevent you from importing a library from another library that isn't supposed to depend on it.
 
 The `depConstraints` option is a list of constraints that define which projects can depend on which other projects. These constraints are tag-based, hence the need to [tag your libraries first](./02-organize-libs.md#tags-and-categories).
-
-# 🚧 TODO
-
-- Tagging libraries is a prerequisite.
-- The rule is configured in the `.eslintrc.json` file of your workspace.
-- The rules are multi-dimensional
-- why and how to whitelist & blacklist external dependencies