Merge branch 'main' into add-adr-about-breaking-up-core

Author: justindbaur

docs/architecture/adr/0030-adopt-pnpm.md

@@ -1,6 +1,6 @@
 ---
 adr: "0030"
-status: Proposed
+status: Accepted
 date: 2026-06-08
 tags: [clients, server, sdk]
 ---

docs/architecture/adr/0031-adopt-minimal-apis.md

@@ -0,0 +1,101 @@
+---
+adr: "0031"
+status: "Proposed"
+date: 2026-06-23
+tags: [server]
+---
+
+# 0031 - Adopt Minimal APIs
+
+<AdrTable frontMatter={frontMatter}></AdrTable>
+
+## Context and problem statement
+
+.NET 6 introduced minimal APIs — a lighter alternative to controllers designed for simplicity,
+speed, and ahead-of-time (AOT) compilation. As of .NET 10, minimal APIs now support automatic
+validation via data annotation attributes, closing the last significant feature gap with
+controllers.
+
+The key architectural advantage: minimal APIs let us decompose the server into smaller, composable
+pieces. Each feature in its own library owns its `.csproj` — and its dependencies — making it
+straightforward to deploy a feature independently or bundle several into a single Lite container.
+
+## Considered options
+
+- **Keep using controllers** - Continue using controllers for all our APIs. Controllers are well
+  understood by the team and have a proven track record. However, controllers are no longer
+  Microsoft's preferred direction, have no path to AOT compatibility, and resist the composable
+  architecture we're moving toward.
+- **Use minimal APIs for new endpoints** - Controllers and minimal APIs can be used side-by-side;
+  new features can use minimal APIs exclusively, segregating their concerns in their own project.
+  This also keeps a future AOT compilation path open.
+- **Migrate controllers to minimal APIs** - We could ban controllers entirely and embark on an
+  aggressive switch to minimal APIs, resulting in a consistent codebase with no mixed styles.
+  However, this is very time-consuming, and there are other pieces that need to fall into place
+  before we can achieve AoT compilation anyway — so we wouldn't get the performance benefits right
+  away.
+
+## Decision outcome
+
+Chosen option: **Use minimal APIs for new endpoints**.
+
+New endpoints use minimal APIs, placed in a feature-scoped library that exposes two methods:
+`Add[Feature]Services` and `Map[Feature]Endpoints`. The host service calls both under an endpoint
+group, which makes extracting any feature into a standalone service behind a reverse proxy
+straightforward later.
+
+```csharp
+// Feature library: MyFeature/ServiceCollectionExtensions.cs
+public static IServiceCollection AddMyFeatureServices(this IServiceCollection services)
+{
+    services.TryAddScoped<IMyFeatureService, MyFeatureService>();
+    return services;
+}
+
+// Feature library: MyFeature/EndpointRouteBuilderExtensions.cs
+public static RouteGroupBuilder MapMyFeatureEndpoints(this IEndpointRouteBuilder routes)
+{
+    var group = routes.MapGroup("");
+    group.MapGet("/", GetAll);
+    group.MapPost("/", Create);
+    return group;
+}
+
+// Host service: Program.cs
+builder.Services.AddMyFeatureServices();
+
+app.UseEndpoints(endpoints =>
+{
+    endpoints.MapDefaultControllerRoute();
+    endpoints.MapGroup("/my-feature")
+        .MapMyFeatureEndpoints();
+});
+```
+
+### Positive consequences
+
+- Better segregation of features similar to clients and sdk-internal
+- Teams own their feature library's `.csproj`, giving them direct control over their package
+  dependencies
+- Easier path to breaking a feature out as its own service, or composing features into a Lite
+  container
+- Enables a future path to AoT compilation, improving cold-start performance
+
+### Negative consequences
+
+- A new way of writing endpoints has to be learned
+- Controllers and minimal APIs will coexist in the codebase for the foreseeable future, which
+  increases the surface area developers need to be familiar with
+- `ActionFilterAttribute`s must be rewritten as endpoint filters before any controller that uses
+  them can be migrated to minimal APIs
+
+### Plan
+
+An `ENDPOINT_LIBRARY.md` in `src/Libraries` will document the canonical library shape, how to wire
+it into the existing monolith, and the path to extracting a feature as a standalone service.
+
+New endpoints added to existing controller-based projects should still use minimal APIs where
+possible, even if not yet in their own feature-scoped library. Existing controllers will be migrated
+opportunistically. Icons, Notifications, and Events are prioritized as early migration targets given
+their small endpoint surface area; migration for a project is considered complete when it has no
+remaining controller classes. Heavier projects will be migrated as opportunities arise.

docs/architecture/security/principles/01-servers-are-zero-knowledge.mdx

@@ -64,3 +64,30 @@ Communicated information is limited to vault item URIs. These URIs are part of a
 content, but we do this to speed up loading of vaults, ensure favicons accurately represent the
 associated URI, and avoid leaking vault contents to local network administrators. This feature is
 easily disabled in client settings.
+
+### Automatic confirmation policy
+
+By default, users invited to join a Bitwarden organization must be confirmed by an administrator
+once they accept an invitation to join. The confirmation step completes the key exchange which
+allows for end-to-end-encrypted sharing of items between organizations and their members.
+
+Enterprise organizations can optionally set up automatic confirmation of users if they do not want
+to manually confirm each user. Once activated, a background process will run in the unlocked browser
+extension of some administrator roles, which will perform this key exchange automatically upon
+request from the server.
+
+This is incompatible with end-to-end encryption because it allows the Bitwarden server to request a
+key exchange on demand. Any actor with control over Bitwarden infrastructure may fabricate an
+invite, which would trigger the automatic confirmation process and give the attacker a copy of the
+organization key. This can then be used to decrypt organization data.
+
+For these reasons:
+
+1. The feature is opt-in only and administrators are warned about the security implications. The
+   feature cannot be activated by the server acting alone - each browser extension that wishes to
+   perform the key exchange must also enable a setting that can only be set locally on that device.
+
+2. The organization and its members are cryptographically isolated from other organizations,
+   providers and users to prevent cryptographic traversal and the compromise of other parties. These
+   measures are outlined in our
+   [help documentation](https://bitwarden.com/help/automatic-confirmation/).