apply code review

Author: willmartian

docs/architecture/clients/index.md

@@ -17,15 +17,15 @@ The mono-repository root directory contains three main folders.
 
 ## Libs
 
-Historically, much of the feature logic of Bitwarden has existed within the `apps` directories, only
-being moved to `libs` (usually `libs/common` or `libs/angular`) if it needed to be shared between
-multiple clients.
+Historically, much of the feature logic of Bitwarden has existed within the `apps/` directories,
+only being moved to `libs/` (usually `libs/common/` or `libs/angular/`) if it needed to be shared
+between multiple clients.
 
 We are attempting to move to a more modular architecture by creating additional libs that are more
-feature-focused and more accurately convey team code ownership.
+feature-focused and which more accurately convey team code ownership.
 
 - `common`: Common code shared between all the clients including CLI
-- `angular`: Low-level Angular specific utilities used by all the visual clients
+- `angular`: Low-level Angular utilities used by all the visual clients
 - `node`: Used to be shared code for CLI and Directory Connector CLI, but since directory connector
   no longer uses the same version of libs this module is deprecated
 - `admin-console`: Code owned by the Admin Console team
@@ -38,15 +38,21 @@ feature-focused and more accurately convey team code ownership.
 - `platform`: Code owned by the Platform team
 - `vault`: Code owned by the Vault team
 
-For more on this approach, check out the
+### Background
+
+More on this approach can be found in the
 [Nx documentation](https://nx.dev/concepts/more-concepts/applications-and-libraries):
 
 > place 80% of your logic into the `libs/` folder and 20% into `apps/`
 
-We are doing the opposite of this right now. What code should be moved from `apps/` to `libs/`? At
-this time, any code in the `/apps/web/*` that doesn't have a tight coupling with the web client can
-be moved into a lib. For components, this means they should only be the CL, no global CSS or
-anything exported from web-specific modules.
+We are doing the opposite of this right now. The code that remains in `apps/` should be primarily
+concerned with bootstrapping the application and consuming and configuring code exported from
+`libs/`. Over time, code not meeting this criteria should be moved from `apps/` to `libs/`.
+
+Any code in the `apps/` that doesn't have a tight coupling with the client can be moved into a lib:
+if an exported member is wholly dependent on other libs but not `apps/`, it can likely be moved to a
+lib itself. (More concretely, this bars components that rely on global client-specific CSS, but not
+components built with Tailwind and the CL.)
 
 > Having a dedicated library project is a much stronger boundary compared to just separating code
 > into folders, though. Each library has a so-called "public API", represented by an index.ts barrel
@@ -56,10 +62,10 @@ anything exported from web-specific modules.
 
 An existing example of this pattern is `@bitwarden/components`:
 
-- It is used by multiple apps and other libs
+- It is consumed by multiple apps and other libs
 - It manages a clear public and private API boundary through its barrel file
-- Code ownership is clear--only the files within `libs/components`
-- The team can make independent decisions around internal folder structure and code style
+- Code ownership is clear--the CL team only owns the files within `libs/components`
+- The CL team can make independent decisions around internal folder structure and code style
 
 As part of this process, we are also investigating utilizing additional tooling (such as Nx) to make
 creating new libs on the fly easier.