docs(ui): codify universal interaction patterns

docs/FRONTEND_LAYOUT_PRINCIPLES.md

@@ -23,6 +23,10 @@ Principles:
   panels, calendar list panels, or mailbox folder panels.
 - Keep collection navigation and collection-level actions close to the relevant
   pane header.
+- In a list-detail workspace such as Scheduling, keep related lists stacked in
+  the left pane and use the remaining main pane for view/create/edit. A single
+  Add action stays in the relevant list-pane header and opens the common main
+  editor; it does not create an additional menu or launcher.
 - Use bounded widths for navigation/list panes and let the main detail/content
   pane take the remaining space.
 - Keep filtering controls inside the pane they affect.
@@ -63,3 +67,11 @@ components directly.
 
 When a module-specific component becomes generally useful, promote it to core
 with a parameterized API before reusing it elsewhere.
+
+Non-self-explanatory fields use Core `FieldLabel`; documented omissions must
+name their accessible-label source. Explicit Discard and dirty navigation use
+the same Core unsaved-changes dialog. Table action sets retain unavailable row
+actions as disabled controls and reserve empty-state slots so Add remains
+aligned. Use central feedback/dialog components; `window.alert` is not an
+authorized product surface unless a product-owner-approved exception is first
+recorded in the Core decision ledger.