@colixsystems/widget-sdk 0.145.0 → 0.147.0

package/README.md

@@ -71,7 +71,28 @@ See the design reference for the full architecture: [`docs/architecture/widget-m
 
 ## Status
 
-`v0.145.0` — pre-publish. The package surface (types, function names, export paths) is the v1 contract; runtime behaviour for some hooks is stubbed (each hook documents what's wired and what isn't). It is **not yet published to npm**.
+`v0.147.0` — pre-publish. The package surface (types, function names, export paths) is the v1 contract; runtime behaviour for some hooks is stubbed (each hook documents what's wired and what isn't). It is **not yet published to npm**.
+
+### What's new in 0.147.0 (contract 1.115.0)
+
+**BREAKING: the bottom navigation bar is themed by `footer` alone — `resolveFooterTokens` reads no `sidebar` (sc-8033).** Every colour fell back to the rail's, so restyling the sidebar restyled a page's bottom bar and the two could not be dressed apart. That is the defect sc-7951 set out to fix and only half did: it gave the strip a Design panel, but left the panel's "Active tab style" offering a **Follow the sidebar** option and every colour still inheriting. The resolver now reads `theme.footer` and nothing else, and the Studio panel offers the strip's **eight** settings with no inherit anywhere.
+
+- **The overloaded `activeColor` is retired** for **`footer.tabActiveBackgroundColor`** and **`footer.tabActiveTextColor`**. One key meant the FILL under `"filled"` and the LABEL under `"accent"`, which is exactly why no author could set both. They are independent now, and each style's *defaults* are what it already rendered — `"filled"`: the brand primary behind a white label; `"accent"`: no surface, a brand-primary label and top edge. So all four colours stay meaningful under both styles.
+- **`activeTint` is gone from `FooterTokens`.** The returned **`activeColor`** is the active tab's label, glyph and accent edge — one colour for all three, because a mark and its label disagreeing about which colour means "you are here" would be two marks.
+- **`backgroundColor` and `textColor` are resolved strings**, not raw-or-null. Both hosts kept their own `#ffffff` / `#475569` defaults for them; a default that lives in each host is the drift §8 exists to prevent, and these had already diverged once. `borderColor` stays nullable — no line, no colour.
+- **`borderWidth` admits `0` here alone**, where `resolveSidebarTokens` keeps sc-7965's 1–8 clamp. The strip's thickness is a Studio control offered down to zero, so a stored zero is an author saying "no line" rather than the junk that clamp refuses; it resolves into the existing no-divider state, so neither host needed new drawing code.
+
+**No shipped app moved.** A backfill (`20270123000000_sc8033_footer_tokens_uncouple`) materialised into each workspace's `footer` block exactly what it had been inheriting, and split every stored `activeColor` onto the key that says which half it meant. Nothing is written where the old chain ended in a default the new one also ends in.
+
+### What's new in 0.146.0 (contract 1.114.0)
+
+**The chrome divider's width is bounded in the resolver, so both hosts agree (sc-7965).** `resolveFooterTokens` and `resolveSidebarTokens` returned `borderWidth` as any finite number. Only the export bounded it — on its way into the StyleSheet — so a stored `1e9` ruled a **billion-pixel border across the published web app** and a normal one in the exported app. The clamp moved into the shared resolver, where both hosts inherit it.
+
+- **Clamped, not dropped.** A value past the end lands **on** the end (1–8), the idiom `tabRadiusOr` / `tabIndicatorOr` already use. This moves the EXPORT too for such a value: it used to *drop* out-of-range and fall back to the 1px hairline, and now renders 8px like the Player.
+- **Zero clamps up**, matching what the export already rendered there — the divider's COLOUR is its switch, so a coloured 0px edge is a contradiction rather than "off".
+- **Every legal 1–8 value is untouched**, and the write path has always refused anything else, so only a hand-edited or pre-coercer `theme_config` can hold a value this moves.
+
+The site header was already bounded by its own resolver and is unchanged. The compiler keeps its own `coerceBorderWidth` as defence in depth over a blob `PUT /tenant/config` still stores verbatim; a test pins the two bounds to each other behaviourally, since the SDK cannot import the backend coercer.
 
 ### What's new in 0.145.0 (contract 1.113.0)
 

package/dist/contract.cjs

@@ -4054,7 +4054,33 @@ const CONTRACT = deepFreeze({
   //    and the inherited colours are hex-guarded on the way out as well as in.
   //    Every colour still falls back to the sidebar's: an untouched workspace is
   //    unchanged.
-  version: "1.113.0",
+  // 1.114.0: behaviour (sc-7965) — `resolveFooterTokens` / `resolveSidebarTokens`
+  //    now return a `borderWidth` CLAMPED to 1-8 instead of any finite number.
+  //    The bound lived only in the export (`coerceBorderWidth(...) ?? 1`), so a
+  //    stored `1e9` ruled a billion-pixel divider across the web Player and a
+  //    1px one in the exported app. Clamped rather than dropped, like the tab
+  //    measurements beside it: a value past the end lands ON the end, which also
+  //    moves the EXPORT for such a value (it used to drop to the 1px hairline).
+  //    Zero clamps up for the same reason the export already rendered 1 there —
+  //    the divider's COLOUR is its switch. Every legal 1-8 value is unchanged,
+  //    and only a hand-edited or pre-coercer blob can hold anything else.
+  // 1.115.0: BREAKING on the pre-1.0 channel (sc-8033) — `resolveFooterTokens`
+  //    reads `theme.footer` and NOTHING else. Every colour used to fall back to
+  //    `theme.sidebar`, so restyling the rail restyled a page's bottom
+  //    navigation bar and the two could not be dressed apart — the defect
+  //    sc-7951 set out to fix and only half did. The wire block's overloaded
+  //    `activeColor` (the FILL under "filled", the LABEL under "accent") is
+  //    retired for `tabActiveBackgroundColor` + `tabActiveTextColor`, two
+  //    independent halves; `activeTint` folds into the returned `activeColor`,
+  //    which is now the active tab's label, glyph and accent edge. The returned
+  //    `backgroundColor` and `textColor` are resolved strings rather than
+  //    raw-or-null, so neither host keeps a default of its own. `borderWidth`
+  //    admits 0 HERE alone — the strip's thickness is a Studio control offered
+  //    down to zero, and zero resolves into the existing no-divider state —
+  //    where the rail's and the header's keep sc-7965's 1-8 clamp. A backfill
+  //    (`20270123000000_sc8033_footer_tokens_uncouple`) materialised what each
+  //    workspace was inheriting, so no shipped app moved.
+  version: "1.115.0",
   sharedTranslationKeys: SHARED_TRANSLATION_KEYS,
   hooks: HOOKS,
   primitives: PRIMITIVES,

package/dist/contract.js

@@ -4050,7 +4050,33 @@ const CONTRACT = deepFreeze({
   //    and the inherited colours are hex-guarded on the way out as well as in.
   //    Every colour still falls back to the sidebar's: an untouched workspace is
   //    unchanged.
-  version: "1.113.0",
+  // 1.114.0: behaviour (sc-7965) — `resolveFooterTokens` / `resolveSidebarTokens`
+  //    now return a `borderWidth` CLAMPED to 1-8 instead of any finite number.
+  //    The bound lived only in the export (`coerceBorderWidth(...) ?? 1`), so a
+  //    stored `1e9` ruled a billion-pixel divider across the web Player and a
+  //    1px one in the exported app. Clamped rather than dropped, like the tab
+  //    measurements beside it: a value past the end lands ON the end, which also
+  //    moves the EXPORT for such a value (it used to drop to the 1px hairline).
+  //    Zero clamps up for the same reason the export already rendered 1 there —
+  //    the divider's COLOUR is its switch. Every legal 1-8 value is unchanged,
+  //    and only a hand-edited or pre-coercer blob can hold anything else.
+  // 1.115.0: BREAKING on the pre-1.0 channel (sc-8033) — `resolveFooterTokens`
+  //    reads `theme.footer` and NOTHING else. Every colour used to fall back to
+  //    `theme.sidebar`, so restyling the rail restyled a page's bottom
+  //    navigation bar and the two could not be dressed apart — the defect
+  //    sc-7951 set out to fix and only half did. The wire block's overloaded
+  //    `activeColor` (the FILL under "filled", the LABEL under "accent") is
+  //    retired for `tabActiveBackgroundColor` + `tabActiveTextColor`, two
+  //    independent halves; `activeTint` folds into the returned `activeColor`,
+  //    which is now the active tab's label, glyph and accent edge. The returned
+  //    `backgroundColor` and `textColor` are resolved strings rather than
+  //    raw-or-null, so neither host keeps a default of its own. `borderWidth`
+  //    admits 0 HERE alone — the strip's thickness is a Studio control offered
+  //    down to zero, and zero resolves into the existing no-divider state —
+  //    where the rail's and the header's keep sc-7965's 1-8 clamp. A backfill
+  //    (`20270123000000_sc8033_footer_tokens_uncouple`) materialised what each
+  //    workspace was inheriting, so no shipped app moved.
+  version: "1.115.0",
   sharedTranslationKeys: SHARED_TRANSLATION_KEYS,
   hooks: HOOKS,
   primitives: PRIMITIVES,

package/dist/host.d.ts

@@ -173,35 +173,32 @@ export function normaliseNavigation(navigation: unknown): ResolvedNavigation;
  */
 export function menuItemCap(menuType: string): number | null;
 
-/** The app's bottom edge — a page's own bottom navigation bar. A `null` colour
- *  means the host keeps its own default; a `null` `borderColor` means no
- *  divider is drawn at all. */
+/** The app's bottom edge — a page's own bottom navigation bar. Every colour is
+ *  resolved, so no host keeps a default of its own; a `null` `borderColor`
+ *  means no divider is drawn at all. */
 export interface FooterTokens {
-  backgroundColor: string | null;
-  textColor: string | null;
-  /** Never `null`: an unset value resolves to the brand primary here rather
-   *  than in each host, which is what lets the two active-tab fields below be
-   *  resolved here at all. */
+  backgroundColor: string;
+  textColor: string;
+  /** The active tab's label, its glyph, and — under "accent" — the edge that
+   *  marks it. One colour for all three: a mark and its label disagreeing about
+   *  which colour means "you are here" would be two marks, not one. */
   activeColor: string;
+  /** `null` when no divider is drawn, which a zero `borderWidth` also means. */
   borderColor: string | null;
   borderWidth: number | null;
   activeStyle: "filled" | "accent";
   /** Whether a tab's glyph sits beside its label or above it (sc-7951). */
   tabLayout: "inline" | "stacked";
-  /** The active tab's surface, or `null` for none. Under "filled" with nothing
-   *  named this is the active colour — what both hosts shipped. */
+  /** The active tab's surface, or `null` for none — which is what "accent"
+   *  resolves to unless the author names one. */
   activeSurface: string | null;
-  /** The active tab's label and glyph. White only under an unnamed "filled"
-   *  surface, which is the pairing both hosts hard-coded. */
-  activeTint: string;
 }
 
 /**
- * Resolves the footer strip's tokens from a whole `theme_config`. Every colour
- * falls back to the sidebar's, so a workspace that never opens the Bottom
- * navigation bar panel renders exactly as it did before the block existed.
- * `tabActiveBackgroundColor` and `tabLayout` are the strip's own and inherit
- * from nothing — a vertical rail item has neither.
+ * Resolves the footer strip's tokens from a whole `theme_config`. It reads
+ * `theme.footer` and NOTHING else (sc-8033): the colours used to fall back to
+ * the sidebar's, so restyling the rail restyled the strip and the two could not
+ * be dressed apart.
  */
 export function resolveFooterTokens(theme: unknown): FooterTokens;
 

package/dist/navigation.cjs

@@ -71,78 +71,76 @@ function menuItemCap(menuType) {
 }
 
 // REQ-NAV-LOCAL: the app's BOTTOM EDGE — the tokens a page's own bottom
-// navigation bar is drawn from. Every colour falls back to the sidebar's, so a
-// workspace that never opens the panel keeps the appearance it has.
+// navigation bar is drawn from.
 //
 // sc-7753: the global quick bar these tokens were introduced for is retired;
 // the bar that reads them now is the page's own (`local_nav = BOTTOM_BAR`).
 //
-// sc-7951: three of the keys ARE that bar's own — the active-item style it
-// used to borrow from the rail for want of a control, the active tab's
-// surface, and whether the glyph sits beside the label or above it.
+// sc-8033: the block is SELF-CONTAINED — it reads `theme.footer` and nothing
+// else. Every colour used to fall back to the rail's, so restyling the sidebar
+// restyled the strip and the two could not be dressed apart; that is the defect
+// sc-7951 set out to fix and only half did. A one-off backfill materialised
+// what each workspace was inheriting, so no shipped app lost its look when the
+// chain went (migration `20260918000000_footer_tokens_uncouple`).
+//
+// The eight authorable keys are the eight controls the Design panel offers, one
+// for one: `backgroundColor`, `textColor`, `tabActiveBackgroundColor`,
+// `tabActiveTextColor`, `borderColor`, `borderWidth`, `activeStyle`,
+// `tabLayout`.
 function resolveFooterTokens(theme) {
   const config = isPlainObject(theme) ? theme : {};
   const footer = isPlainObject(config.footer) ? config.footer : {};
-  const sidebar = isPlainObject(config.sidebar) ? config.sidebar : {};
-  // Hex-guarded on the way out, not merely on the way in: `theme_config` is an
-  // opaque blob an operator can hand-edit, and the EXPORT already refused a
-  // malformed colour here while the Player passed it to a style object — so the
-  // guard is what stops the two hosts painting a stored junk value differently.
-  const pick = (key) => hexOrNull(footer[key]) || hexOrNull(sidebar[key]) || null;
-  const borderColor = pick("borderColor");
-  // sc-7951: the rail's style is the FALLBACK now, not the only source. Unset
-  // still follows the rail, which is what keeps every shipped app where it is.
-  const activeStyle = footer.activeStyle || sidebar.activeStyle;
-  const accent = activeStyle === "accent";
-  const activeColor = hexOr(pick("activeColor"), brandPrimary(config));
-  // Footer-only: a rail item is a full-width row with no tab surface to paint,
-  // so this inherits from nothing and unset means "no surface of its own".
-  const namedSurface = hexOrNull(footer.tabActiveBackgroundColor);
+  // Hex-guarded on read: `theme_config` is an opaque blob an operator can
+  // hand-edit, and the EXPORT already refused a malformed colour here while the
+  // Player passed it to a style object — so the guard is what stops the two
+  // hosts painting a stored junk value differently.
+  const accent = footer.activeStyle === "accent";
+  const borderColor = hexOrNull(footer.borderColor);
+  // sc-8033: the strip's thickness is authorable down to 0, where the rail's
+  // and the header's clamp up to 1 (sc-7965). The panel OFFERS zero, so zero is
+  // a choice rather than the junk value that clamp refuses — and it resolves
+  // into the existing no-divider state, so neither host needs a second way to
+  // draw nothing.
+  const borderWidth = borderColor ? footerBorderWidthOr(footer.borderWidth) : 0;
+  const divider = borderWidth > 0;
   return {
-    backgroundColor: pick("backgroundColor"),
-    textColor: pick("textColor"),
-    // Resolved here rather than by each caller, which is what lets the two
-    // active-tab fields below be resolved here too.
-    activeColor,
-    // REQ-THEME-LOOK: the divider's COLOUR is its switch. Unset draws no line at
-    // all — which the native strip did not honour before this, ruling a
-    // hairline across a tinted bar that had asked for none.
-    borderColor,
-    borderWidth: borderColor ? borderWidthOr(footer.borderWidth, sidebar.borderWidth) : null,
+    backgroundColor: hexOr(footer.backgroundColor, DEFAULT_FOOTER_SURFACE),
+    textColor: hexOr(footer.textColor, DEFAULT_CHROME_TEXT),
+    borderColor: divider ? borderColor : null,
+    borderWidth: divider ? borderWidth : null,
     activeStyle: accent ? "accent" : "filled",
     // sc-7951: bottom tabs are the only strip tall enough to stack the two, so
     // the choice is the footer's alone.
     tabLayout: footer.tabLayout === "stacked" ? "stacked" : "inline",
-    // sc-7951: the active tab's two halves, resolved HERE so neither host
-    // re-derives the back-compat rule. "filled" with nothing named is what both
-    // hosts shipped — the active colour as the fill, the label forced white —
-    // and that pairing is the only reason a marked tab's label is not simply
-    // the active colour. Naming a surface unbundles them: the surface is the
-    // author's and the label goes back to the active colour.
-    activeSurface: namedSurface || (accent ? null : activeColor),
-    activeTint: accent || namedSurface ? activeColor : FILLED_TAB_LABEL,
+    // sc-8033: the active tab's two halves are two KEYS, resolved here so
+    // neither host re-derives them. They used to be one overloaded
+    // `activeColor` — the fill under "filled", the label under "accent" — which
+    // is why no author could set both. Only the DEFAULTS still consult the
+    // style, and they are exactly what each style shipped: a brand-primary fill
+    // under a white label, or no fill under a brand-primary label and edge.
+    activeSurface: accent
+      ? hexOrNull(footer.tabActiveBackgroundColor)
+      : hexOr(footer.tabActiveBackgroundColor, brandPrimary(config)),
+    // The active tab's label, its glyph, and — under "accent" — the edge that
+    // marks it. One colour for all three: a mark and its label disagreeing
+    // about which colour means "you are here" would be two marks, not one.
+    activeColor: hexOr(
+      footer.tabActiveTextColor,
+      accent ? brandPrimary(config) : FILLED_TAB_LABEL,
+    ),
   };
 }
 
 // REQ-THEME-14 — the rail's and the app bar's tokens, resolved once for both
 // hosts.
 //
-// These return FULLY resolved values where `resolveFooterTokens` above still
-// returns raw-or-null for its SURFACE, LABEL and DIVIDER colours, and the
-// difference is deliberate. The footer's two hosts happen to agree on their
-// separately-written defaults for those three (`#ffffff` / `#475569` / no
-// line); the rail's and the bar's did not. sc-7951 resolved the footer's active
-// tab — `activeColor`, `activeSurface`, `activeTint` — because a rule that
-// pairs a surface with a label cannot live in two hosts; the three above are
-// what remains of the old shape. An unset `sidebar.backgroundColor` painted #ffffff on web and the app
-// background in the export, and an unset `topBar.textColor` painted the brand
-// primary on web and slate-700 in the export. A default that lives in the
-// resolver cannot drift; one that lives in each host already had. The footer's
-// three remaining raw colours want this same shape next.
-//
-// Every default is what the WEB Player renders today, so the Player does not
-// move and the export converges onto it. That is the direction the footer was
-// converged in too (compiler.service's footerBg defaults to the web's #ffffff).
+// Every default here is what the WEB Player renders, so the Player does not
+// move and the export converges onto it. An unset `sidebar.backgroundColor`
+// painted #ffffff on web and the app background in the export, and an unset
+// `topBar.textColor` painted the brand primary on web and slate-700 in the
+// export. A default that lives in the resolver cannot drift; one that lives in
+// each host already had — which is why `resolveFooterTokens` above stopped
+// returning raw-or-null too (sc-8033).
 //
 // sc-6596 — the ONE exception, and it moves BOTH hosts: an unset rail or bar
 // takes the page's own colour. Converging on the Player's white left a themed
@@ -151,13 +149,16 @@ function resolveFooterTokens(theme) {
 const DEFAULT_PRIMARY_COLOR = "#3b82f6";
 // The web nav item's `text-slate-600`.
 const DEFAULT_CHROME_TEXT = "#475569";
+// The strip's own surface. Both hosts already defaulted to this separately (the
+// web `footerBg`, the compiler's `#ffffff`); sc-8033 resolved it here instead.
+const DEFAULT_FOOTER_SURFACE = "#ffffff";
 // The web mobile header's icon colour, `text-slate-700`.
 const DEFAULT_TOP_BAR_TINT = "#334155";
 // The page beneath the chrome — the web's `DEFAULT_APP_BACKGROUND_COLOR`
 // (frontend/src/utils/theme.js) and the compiler's, which are the same slate-50.
 const DEFAULT_APP_SURFACE = "#f8fafc";
-// The literal both hosts hard-coded behind an unnamed "filled" surface, before
-// resolveFooterTokens decided the pairing once (sc-7951).
+// A filled tab's label where the author names none — the literal both hosts
+// hard-coded behind an unnamed "filled" surface before the resolver decided it.
 const FILLED_TAB_LABEL = "#ffffff";
 
 // A gradient shows only when BOTH stops are a flat hex — the rule both hosts'
@@ -365,11 +366,40 @@ function resolveTopBarTokens(theme) {
   };
 }
 
+// REQ-THEME-LOOK: the divider's width in px, bounded HERE so both hosts inherit
+// one range. The export clamped it on its way into the StyleSheet
+// (`coerceBorderWidth(...) ?? 1`) where the Player passed any finite number
+// straight to a style object, so a stored `1e9` ruled a billion-pixel border
+// across the published web app and a 1px one in the exported one (sc-7965).
+//
+// Clamped rather than dropped, like the tab measurements above: a value past
+// the end lands on the end instead of reverting to the hairline. Zero clamps up
+// for the same reason the export already turned it into one — the divider's
+// COLOUR is its switch, so a coloured 0px edge is a contradiction, not "off".
+const BORDER_WIDTH_MIN = 1;
+const BORDER_WIDTH_MAX = 8;
+
+// The BOTTOM strip's own range, which starts at zero. Its thickness is a
+// control the Design panel offers down to 0, so a stored zero is an author
+// saying "no line" rather than the junk value the clamp above refuses — and
+// `resolveFooterTokens` turns it back into the no-divider state both hosts
+// already draw, so the extra bound costs neither host a branch (sc-8033).
+function footerBorderWidthOr(value) {
+  if (typeof value !== "number" || !Number.isFinite(value)) {
+    return BORDER_WIDTH_MIN;
+  }
+  return Math.min(Math.max(Math.round(value), 0), BORDER_WIDTH_MAX);
+}
 function borderWidthOr(...values) {
   for (const value of values) {
-    if (typeof value === "number" && Number.isFinite(value)) return value;
+    if (typeof value === "number" && Number.isFinite(value)) {
+      return Math.min(
+        Math.max(Math.round(value), BORDER_WIDTH_MIN),
+        BORDER_WIDTH_MAX,
+      );
+    }
   }
-  return 1;
+  return BORDER_WIDTH_MIN;
 }
 
 module.exports = { normaliseNavigation, menuItemCap, resolveFooterTokens, resolveSidebarTokens, resolveTopBarTokens };

package/dist/navigation.js

@@ -62,78 +62,76 @@ export function menuItemCap(menuType) {
 }
 
 // REQ-NAV-LOCAL: the app's BOTTOM EDGE — the tokens a page's own bottom
-// navigation bar is drawn from. Every colour falls back to the sidebar's, so a
-// workspace that never opens the panel keeps the appearance it has.
+// navigation bar is drawn from.
 //
 // sc-7753: the global quick bar these tokens were introduced for is retired;
 // the bar that reads them now is the page's own (`local_nav = BOTTOM_BAR`).
 //
-// sc-7951: three of the keys ARE that bar's own — the active-item style it
-// used to borrow from the rail for want of a control, the active tab's
-// surface, and whether the glyph sits beside the label or above it.
+// sc-8033: the block is SELF-CONTAINED — it reads `theme.footer` and nothing
+// else. Every colour used to fall back to the rail's, so restyling the sidebar
+// restyled the strip and the two could not be dressed apart; that is the defect
+// sc-7951 set out to fix and only half did. A one-off backfill materialised
+// what each workspace was inheriting, so no shipped app lost its look when the
+// chain went (migration `20260918000000_footer_tokens_uncouple`).
+//
+// The eight authorable keys are the eight controls the Design panel offers, one
+// for one: `backgroundColor`, `textColor`, `tabActiveBackgroundColor`,
+// `tabActiveTextColor`, `borderColor`, `borderWidth`, `activeStyle`,
+// `tabLayout`.
 export function resolveFooterTokens(theme) {
   const config = isPlainObject(theme) ? theme : {};
   const footer = isPlainObject(config.footer) ? config.footer : {};
-  const sidebar = isPlainObject(config.sidebar) ? config.sidebar : {};
-  // Hex-guarded on the way out, not merely on the way in: `theme_config` is an
-  // opaque blob an operator can hand-edit, and the EXPORT already refused a
-  // malformed colour here while the Player passed it to a style object — so the
-  // guard is what stops the two hosts painting a stored junk value differently.
-  const pick = (key) => hexOrNull(footer[key]) || hexOrNull(sidebar[key]) || null;
-  const borderColor = pick("borderColor");
-  // sc-7951: the rail's style is the FALLBACK now, not the only source. Unset
-  // still follows the rail, which is what keeps every shipped app where it is.
-  const activeStyle = footer.activeStyle || sidebar.activeStyle;
-  const accent = activeStyle === "accent";
-  const activeColor = hexOr(pick("activeColor"), brandPrimary(config));
-  // Footer-only: a rail item is a full-width row with no tab surface to paint,
-  // so this inherits from nothing and unset means "no surface of its own".
-  const namedSurface = hexOrNull(footer.tabActiveBackgroundColor);
+  // Hex-guarded on read: `theme_config` is an opaque blob an operator can
+  // hand-edit, and the EXPORT already refused a malformed colour here while the
+  // Player passed it to a style object — so the guard is what stops the two
+  // hosts painting a stored junk value differently.
+  const accent = footer.activeStyle === "accent";
+  const borderColor = hexOrNull(footer.borderColor);
+  // sc-8033: the strip's thickness is authorable down to 0, where the rail's
+  // and the header's clamp up to 1 (sc-7965). The panel OFFERS zero, so zero is
+  // a choice rather than the junk value that clamp refuses — and it resolves
+  // into the existing no-divider state, so neither host needs a second way to
+  // draw nothing.
+  const borderWidth = borderColor ? footerBorderWidthOr(footer.borderWidth) : 0;
+  const divider = borderWidth > 0;
   return {
-    backgroundColor: pick("backgroundColor"),
-    textColor: pick("textColor"),
-    // Resolved here rather than by each caller, which is what lets the two
-    // active-tab fields below be resolved here too.
-    activeColor,
-    // REQ-THEME-LOOK: the divider's COLOUR is its switch. Unset draws no line at
-    // all — which the native strip did not honour before this, ruling a
-    // hairline across a tinted bar that had asked for none.
-    borderColor,
-    borderWidth: borderColor ? borderWidthOr(footer.borderWidth, sidebar.borderWidth) : null,
+    backgroundColor: hexOr(footer.backgroundColor, DEFAULT_FOOTER_SURFACE),
+    textColor: hexOr(footer.textColor, DEFAULT_CHROME_TEXT),
+    borderColor: divider ? borderColor : null,
+    borderWidth: divider ? borderWidth : null,
     activeStyle: accent ? "accent" : "filled",
     // sc-7951: bottom tabs are the only strip tall enough to stack the two, so
     // the choice is the footer's alone.
     tabLayout: footer.tabLayout === "stacked" ? "stacked" : "inline",
-    // sc-7951: the active tab's two halves, resolved HERE so neither host
-    // re-derives the back-compat rule. "filled" with nothing named is what both
-    // hosts shipped — the active colour as the fill, the label forced white —
-    // and that pairing is the only reason a marked tab's label is not simply
-    // the active colour. Naming a surface unbundles them: the surface is the
-    // author's and the label goes back to the active colour.
-    activeSurface: namedSurface || (accent ? null : activeColor),
-    activeTint: accent || namedSurface ? activeColor : FILLED_TAB_LABEL,
+    // sc-8033: the active tab's two halves are two KEYS, resolved here so
+    // neither host re-derives them. They used to be one overloaded
+    // `activeColor` — the fill under "filled", the label under "accent" — which
+    // is why no author could set both. Only the DEFAULTS still consult the
+    // style, and they are exactly what each style shipped: a brand-primary fill
+    // under a white label, or no fill under a brand-primary label and edge.
+    activeSurface: accent
+      ? hexOrNull(footer.tabActiveBackgroundColor)
+      : hexOr(footer.tabActiveBackgroundColor, brandPrimary(config)),
+    // The active tab's label, its glyph, and — under "accent" — the edge that
+    // marks it. One colour for all three: a mark and its label disagreeing
+    // about which colour means "you are here" would be two marks, not one.
+    activeColor: hexOr(
+      footer.tabActiveTextColor,
+      accent ? brandPrimary(config) : FILLED_TAB_LABEL,
+    ),
   };
 }
 
 // REQ-THEME-14 — the rail's and the app bar's tokens, resolved once for both
 // hosts.
 //
-// These return FULLY resolved values where `resolveFooterTokens` above still
-// returns raw-or-null for its SURFACE, LABEL and DIVIDER colours, and the
-// difference is deliberate. The footer's two hosts happen to agree on their
-// separately-written defaults for those three (`#ffffff` / `#475569` / no
-// line); the rail's and the bar's did not. sc-7951 resolved the footer's active
-// tab — `activeColor`, `activeSurface`, `activeTint` — because a rule that
-// pairs a surface with a label cannot live in two hosts; the three above are
-// what remains of the old shape. An unset `sidebar.backgroundColor` painted #ffffff on web and the app
-// background in the export, and an unset `topBar.textColor` painted the brand
-// primary on web and slate-700 in the export. A default that lives in the
-// resolver cannot drift; one that lives in each host already had. The footer's
-// three remaining raw colours want this same shape next.
-//
-// Every default is what the WEB Player renders today, so the Player does not
-// move and the export converges onto it. That is the direction the footer was
-// converged in too (compiler.service's footerBg defaults to the web's #ffffff).
+// Every default here is what the WEB Player renders, so the Player does not
+// move and the export converges onto it. An unset `sidebar.backgroundColor`
+// painted #ffffff on web and the app background in the export, and an unset
+// `topBar.textColor` painted the brand primary on web and slate-700 in the
+// export. A default that lives in the resolver cannot drift; one that lives in
+// each host already had — which is why `resolveFooterTokens` above stopped
+// returning raw-or-null too (sc-8033).
 //
 // sc-6596 — the ONE exception, and it moves BOTH hosts: an unset rail or bar
 // takes the page's own colour. Converging on the Player's white left a themed
@@ -142,13 +140,16 @@ export function resolveFooterTokens(theme) {
 const DEFAULT_PRIMARY_COLOR = "#3b82f6";
 // The web nav item's `text-slate-600`.
 const DEFAULT_CHROME_TEXT = "#475569";
+// The strip's own surface. Both hosts already defaulted to this separately (the
+// web `footerBg`, the compiler's `#ffffff`); sc-8033 resolved it here instead.
+const DEFAULT_FOOTER_SURFACE = "#ffffff";
 // The web mobile header's icon colour, `text-slate-700`.
 const DEFAULT_TOP_BAR_TINT = "#334155";
 // The page beneath the chrome — the web's `DEFAULT_APP_BACKGROUND_COLOR`
 // (frontend/src/utils/theme.js) and the compiler's, which are the same slate-50.
 const DEFAULT_APP_SURFACE = "#f8fafc";
-// The literal both hosts hard-coded behind an unnamed "filled" surface, before
-// resolveFooterTokens decided the pairing once (sc-7951).
+// A filled tab's label where the author names none — the literal both hosts
+// hard-coded behind an unnamed "filled" surface before the resolver decided it.
 const FILLED_TAB_LABEL = "#ffffff";
 
 // A gradient shows only when BOTH stops are a flat hex — the rule both hosts'
@@ -356,9 +357,38 @@ export function resolveTopBarTokens(theme) {
   };
 }
 
+// REQ-THEME-LOOK: the divider's width in px, bounded HERE so both hosts inherit
+// one range. The export clamped it on its way into the StyleSheet
+// (`coerceBorderWidth(...) ?? 1`) where the Player passed any finite number
+// straight to a style object, so a stored `1e9` ruled a billion-pixel border
+// across the published web app and a 1px one in the exported one (sc-7965).
+//
+// Clamped rather than dropped, like the tab measurements above: a value past
+// the end lands on the end instead of reverting to the hairline. Zero clamps up
+// for the same reason the export already turned it into one — the divider's
+// COLOUR is its switch, so a coloured 0px edge is a contradiction, not "off".
+const BORDER_WIDTH_MIN = 1;
+const BORDER_WIDTH_MAX = 8;
+
+// The BOTTOM strip's own range, which starts at zero. Its thickness is a
+// control the Design panel offers down to 0, so a stored zero is an author
+// saying "no line" rather than the junk value the clamp above refuses — and
+// `resolveFooterTokens` turns it back into the no-divider state both hosts
+// already draw, so the extra bound costs neither host a branch (sc-8033).
+function footerBorderWidthOr(value) {
+  if (typeof value !== "number" || !Number.isFinite(value)) {
+    return BORDER_WIDTH_MIN;
+  }
+  return Math.min(Math.max(Math.round(value), 0), BORDER_WIDTH_MAX);
+}
 function borderWidthOr(...values) {
   for (const value of values) {
-    if (typeof value === "number" && Number.isFinite(value)) return value;
+    if (typeof value === "number" && Number.isFinite(value)) {
+      return Math.min(
+        Math.max(Math.round(value), BORDER_WIDTH_MIN),
+        BORDER_WIDTH_MAX,
+      );
+    }
   }
-  return 1;
+  return BORDER_WIDTH_MIN;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@colixsystems/widget-sdk",
-  "version": "0.145.0",
+  "version": "0.147.0",
   "description": "Common widget interface for AppStudio. Implements WidgetManifest, WidgetContext, property schema, and helper hooks.",
   "homepage": "https://github.com/Colix-AB/AppStudio",
   "type": "module",