@the-portland-company/shell 0.46.0 → 0.47.0-rc.2

package/CHANGELOG.md

@@ -1,3 +1,120 @@
+## 0.47.0 — 2026-08-13
+
+Petition Mode has been green since V1 and has rendered red for the whole of the
+0.4x chrome. This release fixes the cause rather than the symptom, and the cause
+turned out to be a platform bug that affects everyone.
+
+**Opt-in with byte-identical defaults.** Every change below is additive. An app
+that declares nothing renders exactly as it did on 0.46.0 — the tests assert the
+fallbacks explicitly, not just the new behaviour.
+
+### Fixed — the chrome painted its UI furniture with a political party colour
+
+`--color-race-red` is the PARTY identity token, the one the party-share charts
+use for Republican. The chrome used it directly in 32 places as its UI accent:
+the mode pill, the org badge, active nav rows, the avatar circle, focus rings,
+primary buttons, the nav hover sweep.
+
+Besides mis-signalling, it made the accent unoverridable — apps reasonably set
+`--color-accent` and nothing happened, because nothing read it.
+
+Those 32 references now resolve a semantic token, split by what the colour
+actually means: `--color-accent` for genuine accent furniture, and a new
+`--color-danger` for attention and error (count badges, the low-fuel meter and
+its nudge, validation messages). The danger set stays red in every Mode — a
+green "3 unread" badge is worse than a red one.
+
+`chrome.css` defines both as `var(--color-race-red)`, so **no pixels move**.
+The last hardcoded accent literal went too: the nav hover sweep's
+`linear-gradient(90deg,#EA4751 0%,#E63946 100%)` is now `--nav-hover-gradient`,
+defaulted to those same two ramp stops.
+
+Red ramp STOPS (`--color-race-red-400` etc.) are unchanged — the red ramp is
+legitimately the red ramp. It was the semantic "this is our accent" use that was
+wrong.
+
+### Added — one accent per Mode
+
+A Mode may now carry its own chrome accent; the platform keeps one accent by
+default.
+
+`NavAppShell` stamps `data-politogy-mode` on its root, sourced by
+`PolitogyAppFrame` from the `POLITOGY_APPS` registry — never from a prop an app
+passes, so an app still cannot pick its own chrome colour; it inherits its
+Mode's. The Brand API serves a Mode's values as
+`[data-politogy-mode="petition"] { --mode-accent: … }` and `chrome.css`
+re-declares the aliases on that element:
+
+```css
+[data-politogy-mode] {
+  --color-accent: var(--mode-accent, var(--color-race-red));
+}
+```
+
+The placement is load-bearing: a custom property is substituted at
+computed-value time on the element it is declared on, so declaring this at
+`:root` would resolve `--mode-accent` there (unset) and inherit the fallback
+down — the Mode block could never win.
+
+A Mode that declares no chrome group leaves `--mode-accent` unset and every
+line falls back to its pre-0.47 value. Relationship and Campaign declare none;
+unscoped apps carry no attribute at all, so the block does not even match them.
+
+Dark mode keeps the platform's neutral ramp. The Brand sheet resets the Mode
+SURFACES to the guaranteed-invalid value under `.dark` so they fall through to
+the neutrals; only the accent, a foreground colour, carries over.
+
+Active sub-rows also gain a 3px left rail drawn from `--nav-row-active-rail`,
+which resolves `transparent` unless the Mode declared a chrome group — so for
+every other app the span renders invisible and out of flow.
+
+Needs the matching Brand API release (`tokens.modes.<id>.chrome`).
+
+### Added — `NavItem { kind: 'section' }`, non-interactive section rows
+
+V1's rail grouped eleven rows under MANAGE / PIPELINE / PEOPLE / SYSTEM. 0.43
+dropped the capability; this restores it.
+
+`kind` is optional and defaults to `'link'`, so every existing `NavItem[]` keeps
+its type and rendering. It is a widened field rather than a discriminated union
+on purpose — a union would make `item.href` a type error for every consumer that
+reads it, turning an additive feature into a breaking change.
+
+It is also not the `disabled`-row trick apps have been faking it with: that
+renders `aria-disabled`, which announces a heading as an unavailable CONTROL. A
+section carries no control semantics at all.
+
+Rendered at both nesting levels, so an app that nests its tree under a standard
+nav entry (Petitions) gets its sections inside the expanded group too.
+
+### Added — registry-granted frame inputs
+
+`contentWrapper` and `page.breadcrumbs` existed but were gated to the core app,
+which left Petitions with a 1280px centred box around a 1550px left-aligned page
+container, and a trail reading "Dashboard › Adjudication" on every adjudication
+URL including a specific sheet and line.
+
+Rather than widening the `app === CORE_APP` gate — which would let any app
+re-specify any chrome element — the exception is declared in the registry:
+
+```ts
+petitions: { …, grants: ['contentWrapper', 'breadcrumbs'] }
+```
+
+`data.frame.<field>` is honoured only when the app's registry row lists it. An
+app cannot grant itself, the complete set of exceptions is one greppable table,
+and an ungranted app that passes the prop gets `undefined` — "no effect", never
+a silent effect.
+
+A grant is for a fact only the app HAS, never for a look.
+
+### Changed — prereleases publish under the `next` dist-tag
+
+`npm publish` tags `latest` whatever the semver, so an rc would silently become
+what a fresh `npm i @the-portland-company/shell` resolves to across the estate.
+The release workflow now detects a prerelease version and publishes it under
+`next`, leaving `latest` on the last stable release until the promotion tag.
+
 ## 0.41.1 — 2026-08-03
 
 ### Fixed — the Chakra tooltip override in 0.41.0 did not actually take