From fd54ef340ff0dc7637d3c7e11601c56d6598ae77 Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Tue, 22 Jul 2025 00:14:53 -0400
Subject: [PATCH 01/11] wip

---
 docs/architecture/adr/0027-angular-signals.md | 50 +++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 docs/architecture/adr/0027-angular-signals.md

diff --git a/docs/architecture/adr/0027-angular-signals.md b/docs/architecture/adr/0027-angular-signals.md
new file mode 100644
index 000000000..6b9a65d63
--- /dev/null
+++ b/docs/architecture/adr/0027-angular-signals.md
@@ -0,0 +1,50 @@
+---
+adr: "0026"
+status: "Accepted"
+date: 2025-07-21
+tags: [clients, angular]
+---
+
+# 0026 - Adopt Angular Signals for Component State
+
+<AdrTable frontMatter={frontMatter}></AdrTable>
+
+## Context and Problem Statement
+
+Signals are the new way to model reactive state in Angular (made as stable in v17). They
+
+- Angular is looking to remove RxJS as a dependency of the framework.
+
+Core Angular APIs are being updated to use signals, including: inputs, outputs, queries. As such,
+signals proliferate through the codebase one way or the other.
+
+At the time of writing, Bitwarden uses RxJS to model reactivity throughout 1.) the Angular UI layer,
+and 2.) the non-Angular JavaScript service layer.
+
+## Considered Options
+
+- **Ad-hoc usage** - Where we are today, Angular Signals are allowed to be used and are used
+  occasionally throughout the codebase but they is no outside encouragement to use them.
+- **Encourage usage** - Start encouraging usage through team training and encouragement to use them
+  in code reviews but don't make any automatic check to enforce usage.
+- **Enforce usage** - Start enforcing usage by...
+- **Disallow usage** - This is not possible. Angular has chosen signals for us to some degree.
+
+## Decision Outcome
+
+Chosen option: **Enforce usage**.
+
+### Positive Consequences
+
+- Standardization across the codebase
+- Follows Angular best practices and recommendations
+- Mitigates Angular deprecations early
+- Simpler for typical component development
+- Lower bundle size
+- More performant (can eventually remove ZoneJS as a dependency)
+
+### Negative Consequences
+
+- New paradigm.
+
+### Plan

From ad9582c38d3ff768503d80e38c99843504da3053 Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Tue, 22 Jul 2025 00:38:42 -0400
Subject: [PATCH 02/11] more WIP + some AI

---
 docs/architecture/adr/0027-angular-signals.md | 83 +++++++++++++------
 1 file changed, 59 insertions(+), 24 deletions(-)

diff --git a/docs/architecture/adr/0027-angular-signals.md b/docs/architecture/adr/0027-angular-signals.md
index 6b9a65d63..fb8949d36 100644
--- a/docs/architecture/adr/0027-angular-signals.md
+++ b/docs/architecture/adr/0027-angular-signals.md
@@ -1,50 +1,85 @@
 ---
-adr: "0026"
+adr: "0027"
 status: "Accepted"
 date: 2025-07-21
 tags: [clients, angular]
 ---
 
-# 0026 - Adopt Angular Signals for Component State
+# 0027 - Adopt Angular Signals for Component State
 
 <AdrTable frontMatter={frontMatter}></AdrTable>
 
 ## Context and Problem Statement
 
-Signals are the new way to model reactive state in Angular (made as stable in v17). They
+Signals are the new way to model reactive state in Angular (made stable in v17). Angular has made it
+clear that signals are the future of the framework:
 
-- Angular is looking to remove RxJS as a dependency of the framework.
+- Angular is actively working to remove RxJS as a core dependency of the framework
+- Core Angular APIs are being migrated to signals, including: inputs, outputs, and queries
+- The Angular team has deprecated several RxJS-based APIs in favor of signal equivalents
+- Future Angular features will be built signal-first
 
-Core Angular APIs are being updated to use signals, including: inputs, outputs, queries. As such,
-signals proliferate through the codebase one way or the other.
+This migration is effectively a foregone conclusion - Angular has chosen signals for the ecosystem.
+However, we can still make conscious decisions about how we adopt and interoperate between signals
+and RxJS.
 
-At the time of writing, Bitwarden uses RxJS to model reactivity throughout 1.) the Angular UI layer,
-and 2.) the non-Angular JavaScript service layer.
+**The Challenge: Portability vs. Angular Integration**
+
+Bitwarden's architecture presents unique challenges for signal adoption. We use RxJS extensively
+across:
+
+1. **Angular UI layer** - Components, services, and state management
+2. **Shared JavaScript service layer** - Business logic used across multiple contexts
+3. **Non-Angular environments** - Browser extension background/content scripts, Electron main
+   process, CLI tools
+
+Signals are Angular-specific and cannot be used outside of Angular injection contexts, which
+excludes significant portions of our codebase. This creates a tension between following Angular's
+direction and maintaining code portability across our diverse runtime environments.
 
 ## Considered Options
 
-- **Ad-hoc usage** - Where we are today, Angular Signals are allowed to be used and are used
-  occasionally throughout the codebase but they is no outside encouragement to use them.
-- **Encourage usage** - Start encouraging usage through team training and encouragement to use them
-  in code reviews but don't make any automatic check to enforce usage.
-- **Enforce usage** - Start enforcing usage by...
-- **Disallow usage** - This is not possible. Angular has chosen signals for us to some degree.
+- **Ad-hoc usage** - Where we are today, Angular Signals are allowed and used occasionally
+  throughout the codebase but without systematic guidance on when to use signals vs. RxJS.
+- **Encourage usage** - Start encouraging signal usage through team training and code review
+  guidance, but maintain flexibility for appropriate RxJS usage.
+- **Enforce usage in Angular contexts** - Systematically enforce signal usage for Angular-specific
+  state (components, directives) while maintaining RxJS for shared service layer and interop
+  scenarios.
+- **Disallow usage** - Not viable. Angular's migration path makes signals unavoidable in Angular
+  applications.
 
 ## Decision Outcome
 
-Chosen option: **Enforce usage**.
+Chosen option: **Enforce usage in Angular contexts**.
+
+We will adopt a layered approach that acknowledges both Angular's direction and Bitwarden's
+architectural constraints:
+
+1. **Angular UI Layer**: Enforce signals for component state, inputs, outputs, and Angular-specific
+   reactive patterns
+2. **Shared Service Layer**: Maintain RxJS for business logic that must work across Angular and
+   non-Angular contexts
+3. **Interop Layer**: Use built-in RxJS interop methods at the boundary between the two layers
+
+This means migrating Angular components to use:
+
+- Signal-based component properties and computed values
+- Signal inputs and outputs (`@Input()` → `input()`, `@Output()` → `output()`)
+- Signal-based queries (`ViewChild`/`ContentChild` → `viewChild()`/`contentChild()`)
 
 ### Positive Consequences
 
-- Standardization across the codebase
-- Follows Angular best practices and recommendations
-- Mitigates Angular deprecations early
-- Simpler for typical component development
-- Lower bundle size
-- More performant (can eventually remove ZoneJS as a dependency)
+- **Angular Alignment**: Follows Angular's established migration path and future direction
+- **Framework Integration**: Seamless integration with Angular's signal-based APIs (inputs, outputs,
+  queries)
+- **Performance Benefits**: Better change detection, smaller bundle sizes, eventual ZoneJS removal
+- **Developer Experience**: Simpler reactive patterns for typical Angular component development
+- **Future-Proofing**: Positions us well for upcoming Angular features and migrations
+- **Clear Boundaries**: Establishes explicit patterns for when to use signals vs. RxJS
 
 ### Negative Consequences
 
-- New paradigm.
-
-### Plan
+- **Learning Curve**: New reactive paradigm for developers familiar with RxJS patterns
+- **Interop Complexity**: Managing conversions between signals and observables at layer boundaries
+- **Ecosystem Split**: Two reactive systems within the same codebase require careful coordination

From 10618092da8a7cea9db0e75f866473b0edb8e1d0 Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Mon, 24 Nov 2025 13:48:02 -0500
Subject: [PATCH 03/11] add signal adr 28

---
 docs/architecture/adr/0027-angular-signals.md | 85 -------------------
 docs/architecture/adr/0028-angular-signals.md | 41 +++++++++
 2 files changed, 41 insertions(+), 85 deletions(-)
 delete mode 100644 docs/architecture/adr/0027-angular-signals.md
 create mode 100644 docs/architecture/adr/0028-angular-signals.md

diff --git a/docs/architecture/adr/0027-angular-signals.md b/docs/architecture/adr/0027-angular-signals.md
deleted file mode 100644
index fb8949d36..000000000
--- a/docs/architecture/adr/0027-angular-signals.md
+++ /dev/null
@@ -1,85 +0,0 @@
----
-adr: "0027"
-status: "Accepted"
-date: 2025-07-21
-tags: [clients, angular]
----
-
-# 0027 - Adopt Angular Signals for Component State
-
-<AdrTable frontMatter={frontMatter}></AdrTable>
-
-## Context and Problem Statement
-
-Signals are the new way to model reactive state in Angular (made stable in v17). Angular has made it
-clear that signals are the future of the framework:
-
-- Angular is actively working to remove RxJS as a core dependency of the framework
-- Core Angular APIs are being migrated to signals, including: inputs, outputs, and queries
-- The Angular team has deprecated several RxJS-based APIs in favor of signal equivalents
-- Future Angular features will be built signal-first
-
-This migration is effectively a foregone conclusion - Angular has chosen signals for the ecosystem.
-However, we can still make conscious decisions about how we adopt and interoperate between signals
-and RxJS.
-
-**The Challenge: Portability vs. Angular Integration**
-
-Bitwarden's architecture presents unique challenges for signal adoption. We use RxJS extensively
-across:
-
-1. **Angular UI layer** - Components, services, and state management
-2. **Shared JavaScript service layer** - Business logic used across multiple contexts
-3. **Non-Angular environments** - Browser extension background/content scripts, Electron main
-   process, CLI tools
-
-Signals are Angular-specific and cannot be used outside of Angular injection contexts, which
-excludes significant portions of our codebase. This creates a tension between following Angular's
-direction and maintaining code portability across our diverse runtime environments.
-
-## Considered Options
-
-- **Ad-hoc usage** - Where we are today, Angular Signals are allowed and used occasionally
-  throughout the codebase but without systematic guidance on when to use signals vs. RxJS.
-- **Encourage usage** - Start encouraging signal usage through team training and code review
-  guidance, but maintain flexibility for appropriate RxJS usage.
-- **Enforce usage in Angular contexts** - Systematically enforce signal usage for Angular-specific
-  state (components, directives) while maintaining RxJS for shared service layer and interop
-  scenarios.
-- **Disallow usage** - Not viable. Angular's migration path makes signals unavoidable in Angular
-  applications.
-
-## Decision Outcome
-
-Chosen option: **Enforce usage in Angular contexts**.
-
-We will adopt a layered approach that acknowledges both Angular's direction and Bitwarden's
-architectural constraints:
-
-1. **Angular UI Layer**: Enforce signals for component state, inputs, outputs, and Angular-specific
-   reactive patterns
-2. **Shared Service Layer**: Maintain RxJS for business logic that must work across Angular and
-   non-Angular contexts
-3. **Interop Layer**: Use built-in RxJS interop methods at the boundary between the two layers
-
-This means migrating Angular components to use:
-
-- Signal-based component properties and computed values
-- Signal inputs and outputs (`@Input()` → `input()`, `@Output()` → `output()`)
-- Signal-based queries (`ViewChild`/`ContentChild` → `viewChild()`/`contentChild()`)
-
-### Positive Consequences
-
-- **Angular Alignment**: Follows Angular's established migration path and future direction
-- **Framework Integration**: Seamless integration with Angular's signal-based APIs (inputs, outputs,
-  queries)
-- **Performance Benefits**: Better change detection, smaller bundle sizes, eventual ZoneJS removal
-- **Developer Experience**: Simpler reactive patterns for typical Angular component development
-- **Future-Proofing**: Positions us well for upcoming Angular features and migrations
-- **Clear Boundaries**: Establishes explicit patterns for when to use signals vs. RxJS
-
-### Negative Consequences
-
-- **Learning Curve**: New reactive paradigm for developers familiar with RxJS patterns
-- **Interop Complexity**: Managing conversions between signals and observables at layer boundaries
-- **Ecosystem Split**: Two reactive systems within the same codebase require careful coordination
diff --git a/docs/architecture/adr/0028-angular-signals.md b/docs/architecture/adr/0028-angular-signals.md
new file mode 100644
index 000000000..0a8ef03a6
--- /dev/null
+++ b/docs/architecture/adr/0028-angular-signals.md
@@ -0,0 +1,41 @@
+---
+adr: "0028"
+status: "Accepted"
+date: 2025-07-21
+tags: [clients, angular]
+---
+
+# 0027 - Adopt Angular Signals for Component State
+
+<AdrTable frontMatter={frontMatter}></AdrTable>
+
+## Context and Problem Statement
+
+Angular has adopted a new reactive primitive, signals. Signals have various improvements over RxJS:
+performance, simplicity, and deeper integrations into the rest of the framework.
+
+RxJS will become an optional dependency of Angular instead of a required. Certain asynchronous
+workflows will still benefit from RxJS--signals are synchronous. Furthermore, being a part of the
+core Angular library, Angular signals cannot readily be used in non-Angular environments.
+
+As such, Signals should be the default when operating _in the view layer_: components, directives,
+pipes, and services that are tightly coupled to the UI/Angular. Services that primarily deal with
+business logic should prefer RxJS to maximize portability (or, even better, be moved to the Rust
+SDK).
+
+## Outcome
+
+Signal-based APIs (inputs, outputs, child queries) will be required via linting:
+
+- `@Input()` → `input()`,
+- `@Output()` → `output()`
+- `@ViewChild`/`@ContentChild` → `viewChild()`/`contentChild()`
+
+## Reasons against other options
+
+- Disallow usage of signals and only use RxJS for reactivity.
+  - This is a non-starter. Signals are being built into Angular.
+- Continue the status quo of adhoc usage.
+  - Having multiple ways to do the same thing leads to analysis paralysis and complicated code.
+  - Signals + OnPush change detection provide a clear path to removing Zone.js. With that comes
+    notable performance and debugging improvements.

From 3d6c1b6aa26e8b50e6fe6d570a5cd52e0d56578b Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Mon, 24 Nov 2025 13:52:47 -0500
Subject: [PATCH 04/11] further reading; fix typo

---
 docs/architecture/adr/0028-angular-signals.md | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/docs/architecture/adr/0028-angular-signals.md b/docs/architecture/adr/0028-angular-signals.md
index 0a8ef03a6..1d1a76e44 100644
--- a/docs/architecture/adr/0028-angular-signals.md
+++ b/docs/architecture/adr/0028-angular-signals.md
@@ -1,11 +1,11 @@
 ---
 adr: "0028"
 status: "Accepted"
-date: 2025-07-21
+date: 2025-11-24
 tags: [clients, angular]
 ---
 
-# 0027 - Adopt Angular Signals for Component State
+# 0028 - Adopt Angular Signals for Component State
 
 <AdrTable frontMatter={frontMatter}></AdrTable>
 
@@ -25,7 +25,7 @@ SDK).
 
 ## Outcome
 
-Signal-based APIs (inputs, outputs, child queries) will be required via linting:
+Signal-based APIs (inputs, outputs, child queries) will be required in components via linting:
 
 - `@Input()` → `input()`,
 - `@Output()` → `output()`
@@ -39,3 +39,7 @@ Signal-based APIs (inputs, outputs, child queries) will be required via linting:
   - Having multiple ways to do the same thing leads to analysis paralysis and complicated code.
   - Signals + OnPush change detection provide a clear path to removing Zone.js. With that comes
     notable performance and debugging improvements.
+
+## Further reading
+
+- [Angular docs](https://angular.dev/guide/signals)

From c977fa50e4f69c165e8372cd785d3e1d8b1ebe55 Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Mon, 24 Nov 2025 13:59:28 -0500
Subject: [PATCH 05/11] wip

---
 docs/architecture/adr/0028-angular-signals.md | 34 +++++++++++++++----
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/docs/architecture/adr/0028-angular-signals.md b/docs/architecture/adr/0028-angular-signals.md
index 1d1a76e44..af0c329c4 100644
--- a/docs/architecture/adr/0028-angular-signals.md
+++ b/docs/architecture/adr/0028-angular-signals.md
@@ -14,23 +14,45 @@ tags: [clients, angular]
 Angular has adopted a new reactive primitive, signals. Signals have various improvements over RxJS:
 performance, simplicity, and deeper integrations into the rest of the framework.
 
-RxJS will become an optional dependency of Angular instead of a required. Certain asynchronous
-workflows will still benefit from RxJS--signals are synchronous. Furthermore, being a part of the
-core Angular library, Angular signals cannot readily be used in non-Angular environments.
+RxJS will become an optional dependency of Angular. Certain asynchronous workflows will still
+benefit from RxJS--signals are synchronous. Furthermore, being a part of the core Angular library,
+Angular signals cannot readily be used in non-Angular environments.
 
 As such, Signals should be the default when operating _in the view layer_: components, directives,
 pipes, and services that are tightly coupled to the UI/Angular. Services that primarily deal with
 business logic should prefer RxJS to maximize portability (or, even better, be moved to the Rust
 SDK).
 
-## Outcome
+## Decision
 
-Signal-based APIs (inputs, outputs, child queries) will be required in components via linting:
+Signal-based APIs (inputs, outputs, child queries) will be required in components and directives via
+linting:
 
-- `@Input()` → `input()`,
+- `@Input()` → `input()`
 - `@Output()` → `output()`
 - `@ViewChild`/`@ContentChild` → `viewChild()`/`contentChild()`
 
+Services tightly coupled to Angular should use signals. Services with business logic should prefer
+RxJS for portability. Use `toSignal()` and `toObservable()` to bridge between the two when needed.
+
+Existing code will be migrated gradually. New code must use signal-based APIs.
+
+## Consequences
+
+**Positive:**
+
+- Improved performance and simpler change detection
+- Clear path to removing Zone.js dependency
+- Better debugging experience
+- Aligned with Angular's direction
+- Simpler than RxJS for many common use cases
+
+**Negative:**
+
+- Temporary complexity during migration with mixed RxJS/Signals patterns
+- Learning curve for team members unfamiliar with signals
+- Migration effort required for existing codebase
+
 ## Reasons against other options
 
 - Disallow usage of signals and only use RxJS for reactivity.

From 7dbf35dc47ed5fee217577ec35b3b0d3add7b50f Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Mon, 15 Dec 2025 13:39:26 -0500
Subject: [PATCH 06/11] rename to ADR #29

---
 .../adr/{0028-angular-signals.md => 0029-angular-signals.md}    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename docs/architecture/adr/{0028-angular-signals.md => 0029-angular-signals.md} (99%)

diff --git a/docs/architecture/adr/0028-angular-signals.md b/docs/architecture/adr/0029-angular-signals.md
similarity index 99%
rename from docs/architecture/adr/0028-angular-signals.md
rename to docs/architecture/adr/0029-angular-signals.md
index af0c329c4..f159bc197 100644
--- a/docs/architecture/adr/0028-angular-signals.md
+++ b/docs/architecture/adr/0029-angular-signals.md
@@ -1,5 +1,5 @@
 ---
-adr: "0028"
+adr: "0029"
 status: "Accepted"
 date: 2025-11-24
 tags: [clients, angular]

From 3dfc3e4269b6f7555f9568f7cc82803f379c7b1a Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Mon, 15 Dec 2025 13:54:49 -0500
Subject: [PATCH 07/11] code review changes

---
 docs/architecture/adr/0029-angular-signals.md | 17 +++++++++++++----
 docs/contributing/code-style/web/angular.md   |  2 +-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/docs/architecture/adr/0029-angular-signals.md b/docs/architecture/adr/0029-angular-signals.md
index f159bc197..a8814c3af 100644
--- a/docs/architecture/adr/0029-angular-signals.md
+++ b/docs/architecture/adr/0029-angular-signals.md
@@ -15,7 +15,7 @@ Angular has adopted a new reactive primitive, signals. Signals have various impr
 performance, simplicity, and deeper integrations into the rest of the framework.
 
 RxJS will become an optional dependency of Angular. Certain asynchronous workflows will still
-benefit from RxJS--signals are synchronous. Furthermore, being a part of the core Angular library,
+benefit from RxJS (signals are synchronous). Furthermore, being a part of the core Angular library,
 Angular signals cannot readily be used in non-Angular environments.
 
 As such, Signals should be the default when operating _in the view layer_: components, directives,
@@ -33,9 +33,18 @@ linting:
 - `@ViewChild`/`@ContentChild` → `viewChild()`/`contentChild()`
 
 Services tightly coupled to Angular should use signals. Services with business logic should prefer
-RxJS for portability. Use `toSignal()` and `toObservable()` to bridge between the two when needed.
+RxJS for portability. Use `toSignal()` and `toObservable()` to bridge between RxJS and signals when
+necessary.
 
-Existing code will be migrated gradually. New code must use signal-based APIs.
+## Implementation Plan
+
+New code must use signal-based APIs; existing code will be migrated gradually. Angular provides
+automatic code migrations for signal
+[inputs](https://angular.dev/reference/migrations/signal-inputs) and
+[queries](https://angular.dev/reference/migrations/signal-queries).
+
+Much of `libs/components` was updated using these migrators:
+https://github.com/bitwarden/clients/pull/15340
 
 ## Consequences
 
@@ -57,7 +66,7 @@ Existing code will be migrated gradually. New code must use signal-based APIs.
 
 - Disallow usage of signals and only use RxJS for reactivity.
   - This is a non-starter. Signals are being built into Angular.
-- Continue the status quo of adhoc usage.
+- Continue the status quo of ad hoc usage.
   - Having multiple ways to do the same thing leads to analysis paralysis and complicated code.
   - Signals + OnPush change detection provide a clear path to removing Zone.js. With that comes
     notable performance and debugging improvements.
diff --git a/docs/contributing/code-style/web/angular.md b/docs/contributing/code-style/web/angular.md
index cf547ba5a..f97616f45 100644
--- a/docs/contributing/code-style/web/angular.md
+++ b/docs/contributing/code-style/web/angular.md
@@ -212,7 +212,7 @@ component "Organization Reports Module" {
 @enduml
 ```
 
-## Reactivity ([ADR-0003](../../../architecture/adr/0003-observable-data-services.md) & ADR-0028)
+## Reactivity ([ADR-0003](../../../architecture/adr/0003-observable-data-services.md) & [ADR-0029](../../../architecture/adr/0029-angular-signals.md))
 
 We make heavy use of reactive programming using [Angular Signals][signals] & [RxJS][rxjs]. Generally
 components should always derive their state reactively from services whenever possible.

From d7699295e524b587b4a2db049497379a6dc33d76 Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Mon, 15 Dec 2025 15:26:57 -0500
Subject: [PATCH 08/11] update prettier and run

---
 docs/getting-started/server/advanced-setup.md | 2 --
 docs/getting-started/server/guide.md          | 2 --
 2 files changed, 4 deletions(-)

diff --git a/docs/getting-started/server/advanced-setup.md b/docs/getting-started/server/advanced-setup.md
index e255078b6..eef8de099 100644
--- a/docs/getting-started/server/advanced-setup.md
+++ b/docs/getting-started/server/advanced-setup.md
@@ -63,7 +63,6 @@ integration.
 File uploads are stored using one of two methods.
 
 - Azure Storage is used by our production cloud instance.
-
   - Docker will create a local [Azurite](https://github.com/Azure/Azurite) instance which emulates
     the Azure Storage API. And is used for the primary testing.
   - We also have a test Azure Storage account for development use. The user secrets for this are
@@ -169,7 +168,6 @@ services).
 
 5. Spin up the required services locally, using a unique port for each running instance. **The ports
    must match the ports in the `reverse-proxy.conf` in the `upstream` configuration blocks.**
-
    - **Command line** _(in separate terminals)_
      ```bash
      # 1st instance
diff --git a/docs/getting-started/server/guide.md b/docs/getting-started/server/guide.md
index 7dc337c22..7a8f7b147 100644
--- a/docs/getting-started/server/guide.md
+++ b/docs/getting-started/server/guide.md
@@ -73,7 +73,6 @@ facilitate easy customization.
 
     Your MSSQL password must comply with the following
     [password complexity guidelines](https://docs.microsoft.com/en-us/sql/relational-databases/security/password-policy?view=sql-server-ver15#password-complexity)
-
     - It must be at least eight characters long.
     - It must contain characters from three of the following four categories:
     - Latin uppercase letters (A through Z)
@@ -213,7 +212,6 @@ repository.
     </Bitwarden>
 
 2.  Update `secrets.json` with your own values:
-
     - `sqlServer` > `connectionString`: insert your password where indicated
 
     <Community>

From c7ac12a2e74d8310fb32742440d09fb3948b9ddd Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Tue, 16 Dec 2025 22:23:42 -0500
Subject: [PATCH 09/11] fix spelling

---
 .../adr/0026-dotnet-dependency-injection-enhancements.md        | 2 +-
 docs/architecture/security/definitions.mdx                      | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/architecture/adr/0026-dotnet-dependency-injection-enhancements.md b/docs/architecture/adr/0026-dotnet-dependency-injection-enhancements.md
index 2a85feb61..6d0a31aee 100644
--- a/docs/architecture/adr/0026-dotnet-dependency-injection-enhancements.md
+++ b/docs/architecture/adr/0026-dotnet-dependency-injection-enhancements.md
@@ -107,7 +107,7 @@ as they are expected to always be included in the host -- those services are `IL
 
 ## Considered options
 
-- **Ad-hoc usage** - Where we are today, the `TryAdd` overloads are allowed to be used and are used
+- **Ad hoc usage** - Where we are today, the `TryAdd` overloads are allowed to be used and are used
   occasionally throughout the codebase but they is no outside encouragement to use them.
 - **Encourage usage** - Start encouraging usage through team training and encouragement to use them
   in code reviews but don't make any automatic check to enforce usage.
diff --git a/docs/architecture/security/definitions.mdx b/docs/architecture/security/definitions.mdx
index e4a7cb154..d7f6a6623 100644
--- a/docs/architecture/security/definitions.mdx
+++ b/docs/architecture/security/definitions.mdx
@@ -12,7 +12,7 @@ be able to do, and what they want to achieve, possibly even not having anything
 achieve, just the notion of "I want a secure product".
 
 A formal approach here is needed: to aid in communication and to also provide a clear set of goals
-to achieve. This applies both to ad-hoc conversations in which the participants don't yet share a
+to achieve. This applies both to ad hoc conversations in which the participants don't yet share a
 common understanding of security goals and the assumed attacker, but it also applies to
 long-standing assumed security we want to achieve for our clients, communication protocols, and
 cryptography. This is not limited to cryptographic topics.

From b796954ced965b29f43f2923bba36581f8217111 Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Tue, 16 Dec 2025 22:37:44 -0500
Subject: [PATCH 10/11] clarify guidance; update ADR 0003

---
 docs/architecture/adr/0003-observable-data-services.md |  8 ++++++++
 docs/architecture/adr/0029-angular-signals.md          | 10 +++++++---
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/docs/architecture/adr/0003-observable-data-services.md b/docs/architecture/adr/0003-observable-data-services.md
index 2b9d72015..942e0cb16 100644
--- a/docs/architecture/adr/0003-observable-data-services.md
+++ b/docs/architecture/adr/0003-observable-data-services.md
@@ -33,6 +33,14 @@ Chosen option: **Observable data services**, because
 - The work towards a reactive data model will allow us to adopt patterns like NGRX in the future
   should it be needed.
 
+:::info Updated Guidance
+
+This ADR remains valid for business logic services, but
+[ADR 0029](/architecture/adr/0029-angular-signals) introduces Angular Signals as the preferred
+approach over RxJS for view layer code (components, directives, pipes, and UI-coupled services).
+
+:::
+
 ### Example
 
 #### Organizations
diff --git a/docs/architecture/adr/0029-angular-signals.md b/docs/architecture/adr/0029-angular-signals.md
index a8814c3af..819eae8d3 100644
--- a/docs/architecture/adr/0029-angular-signals.md
+++ b/docs/architecture/adr/0029-angular-signals.md
@@ -32,9 +32,9 @@ linting:
 - `@Output()` → `output()`
 - `@ViewChild`/`@ContentChild` → `viewChild()`/`contentChild()`
 
-Services tightly coupled to Angular should use signals. Services with business logic should prefer
-RxJS for portability. Use `toSignal()` and `toObservable()` to bridge between RxJS and signals when
-necessary.
+Services tightly coupled to Angular should use signals. Services with non-presentational business
+logic should prefer RxJS for portability. Use `toSignal()` and `toObservable()` to bridge between
+RxJS and signals when necessary.
 
 ## Implementation Plan
 
@@ -46,6 +46,10 @@ automatic code migrations for signal
 Much of `libs/components` was updated using these migrators:
 https://github.com/bitwarden/clients/pull/15340
 
+See the
+[Angular Modernization Guide](https://contributing.bitwarden.com/contributing/code-style/web/angular-migration-guide/#signals)
+for more information.
+
 ## Consequences
 
 **Positive:**

From 1173f8afb65ce7c7986f34ec65f1f4ce82325fdd Mon Sep 17 00:00:00 2001
From: William Martin <contact@willmartian.com>
Date: Wed, 17 Dec 2025 09:15:30 -0500
Subject: [PATCH 11/11] fix broken link

---
 docs/architecture/adr/0003-observable-data-services.md | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/docs/architecture/adr/0003-observable-data-services.md b/docs/architecture/adr/0003-observable-data-services.md
index 942e0cb16..7c8edfee3 100644
--- a/docs/architecture/adr/0003-observable-data-services.md
+++ b/docs/architecture/adr/0003-observable-data-services.md
@@ -35,9 +35,9 @@ Chosen option: **Observable data services**, because
 
 :::info Updated Guidance
 
-This ADR remains valid for business logic services, but
-[ADR 0029](/architecture/adr/0029-angular-signals) introduces Angular Signals as the preferred
-approach over RxJS for view layer code (components, directives, pipes, and UI-coupled services).
+This ADR remains valid for business logic services, but [ADR 0029][signals] introduces Angular
+Signals as the preferred approach over RxJS for view layer code (components, directives, pipes, and
+UI-coupled services).
 
 :::
 
@@ -103,3 +103,4 @@ NGRX is the most popular Redux implementation for Angular. For more details, rea
 [observable]:
   https://blog.angular-university.io/how-to-build-angular2-apps-using-rxjs-observable-data-services-pitfalls-to-avoid/
 [redux-motivation]: https://redux.js.org/understanding/thinking-in-redux/motivation
+[signals]: ./0029-angular-signals.md