@the-portland-company/shell 0.51.0 → 0.53.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +40 -0
- package/dist/app-chrome.cjs +742 -356
- package/dist/app-chrome.cjs.map +1 -1
- package/dist/app-chrome.d.cts +56 -3
- package/dist/app-chrome.d.ts +56 -3
- package/dist/app-chrome.js +282 -66
- package/dist/app-chrome.js.map +1 -1
- package/dist/{chunk-II5K6QT6.js → chunk-XEFBZ3PR.js} +461 -296
- package/dist/chunk-XEFBZ3PR.js.map +1 -0
- package/dist/native.cjs +463 -294
- package/dist/native.cjs.map +1 -1
- package/dist/native.d.cts +20 -2
- package/dist/native.d.ts +20 -2
- package/dist/native.js +1 -1
- package/package.json +1 -1
- package/dist/chunk-II5K6QT6.js.map +0 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,43 @@
|
|
|
1
|
+
## 0.53.0 — 2026-09-29
|
|
2
|
+
|
|
3
|
+
### Added — Loading Screen boot surface (Specs/Loading-Screen)
|
|
4
|
+
|
|
5
|
+
`PolitogyAppFrame` now renders the platform's boot screen: a full-screen
|
|
6
|
+
`ink-900` surface with the Politogy VRM lockup, a determinate/monotonic
|
|
7
|
+
gradient progress bar (Race Blue → Race Red), and a throttled monospace
|
|
8
|
+
status line, shown on cold start / hard reload / organization switch / mode
|
|
9
|
+
switch — the four events Global-Rules' Boot Screen Exception names — and
|
|
10
|
+
never for an in-page fetch or navigation. New export
|
|
11
|
+
`LoadingScreen`/`BootProgress` from `@the-portland-company/shell/app-chrome`
|
|
12
|
+
lets an app report real pipeline stages; a new `PolitogyAppFrame` prop
|
|
13
|
+
`appReady` lets an app dismiss the screen explicitly. Neither is required:
|
|
14
|
+
an app that passes nothing gets a truthful two-stage report driven by the
|
|
15
|
+
same org/nav resolution signal the frame already computes, so all 14
|
|
16
|
+
consumer apps keep working unchanged. `prefers-reduced-motion` skips the
|
|
17
|
+
exit transition; the bar is `role="progressbar"` with `aria-live` announced
|
|
18
|
+
copy throttled to one per 1.5s (final "Ready." always announced).
|
|
19
|
+
|
|
20
|
+
## 0.52.0 — 2026-09-12
|
|
21
|
+
|
|
22
|
+
### Added — mobile navigation (GLOBAL)
|
|
23
|
+
|
|
24
|
+
Every consumer hides the sidebar below the `lg` breakpoint
|
|
25
|
+
(`hidden … lg:flex`) and nothing opened it, so on a phone the main menu was
|
|
26
|
+
unreachable. `NavAppShell` now owns the open state: `NavTopBar` renders a
|
|
27
|
+
hamburger button (hidden at `lg` and up) as the first thing in the header,
|
|
28
|
+
and `NavSidebar` renders as a modal drawer when open — backdrop, a close
|
|
29
|
+
button, Escape, and focus moved to the close button and back to the
|
|
30
|
+
hamburger on close. It closes on route navigation and on a nav-link click.
|
|
31
|
+
Desktop is unaffected; both new sidebar props (`open`, `onClose`) and both
|
|
32
|
+
new top-bar props (`onOpenNav`, `navOpen`) are optional, so an app calling
|
|
33
|
+
`NavSidebar` / `NavTopBar` directly (outside `NavAppShell`) sees no change
|
|
34
|
+
unless it wires them up itself.
|
|
35
|
+
|
|
36
|
+
### Why
|
|
37
|
+
|
|
38
|
+
Reported from Petition Mode on a phone: "I cannot seem to access the menu on
|
|
39
|
+
my mobile device."
|
|
40
|
+
|
|
1
41
|
## 0.48.0 — 2026-08-13
|
|
2
42
|
|
|
3
43
|
V1-parity round 2, driven by a measured element-by-element audit of a live V1
|