.claude/adr/0005-stock-firefox-policy-extensions.md

@@ -32,3 +32,6 @@ The policy path gives up build-time reproducibility of the extension binaries, a
 - First launch after a fresh build requires network to fetch the add-ons.
   An offline first boot comes up with the extensions not yet present, populating them once online.
 - Moving to a pinned-package posture later would mean changing the browser variant as well, since the two are coupled — the reason this is captured as a decision rather than a detail.
+- The no-pinned-package rule scopes to the three functional extensions, which is where the signature-enforcement conflict bites.
+  Nord chrome theming comes from the Stylix Firefox Color add-on, a signed add-on that Stylix pins and manages, so it loads on stock mainline Firefox and adds no flake input of ours.
+  That is a bounded, deliberate exception, not a reversal: it is what lets the browser be themed from the shared Stylix scheme without hand-written chrome CSS.

modules/desktop/firefox.nix

@@ -47,6 +47,10 @@ in
         profiles.default = {
           isDefault = true;
 
+          # The Nord chrome theme is a declared extension setting, so home-manager
+          # owns the extension-settings store, overwriting runtime changes to it.
+          extensions.force = true;
+
           settings = {
             # Sponsored surfaces the policies above do not reach.
             "browser.urlbar.suggest.quicksuggest.sponsored" = false;
@@ -75,9 +79,12 @@ in
       };
 
       # Nord chrome from the shared Stylix scheme, against the one profile.
+      # colorTheme recolours the toolbar and tabs, which the target does not do
+      # on its own, through the Stylix-managed Firefox Color add-on.
       stylix.targets.firefox = {
         enable = true;
         profileNames = [ "default" ];
+        colorTheme.enable = true;
       };
 
       # Links opened from other applications land in Firefox.