useAddressAutocomplete: drop the Google Maps JS SDK + loadGoogleMapsScript
in favor of an HTTP-fetch loop against a configurable endpoint (default
/api/geocoder), which we point at gsc-geocoder (183M-row OSM-derived
PostGIS database). Promote AddressAutocomplete from gscRegister fork into
the shared validation/components/. Pre-existing Google Maps TS namespace
issues vanish with the dep removal.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
50 .tsx components and 6 .ts hook files use React client APIs
(createContext, useState, useEffect, useRef, useMemo, useCallback,
forwardRef, etc.) but lacked the "use client" directive at the top
of the source file. tsc-emitted dist files therefore also lacked it.
Older Next.js / Turbopack versions traversed the import graph and
implicitly treated the imports as client when their consumer was a
client component. Next.js 16's stricter Turbopack rejects this: any
file that touches client-only React APIs must declare "use client"
explicitly, regardless of where it is imported from.
Symptom in consumers (gscSupport build, 2026-05-17):
./templates/limitless-ui/dist/theme/ThemeProvider.js:2:10
You're importing a module that depends on `createContext` into a
React Server Component module. This API is only available in
Client Components. To fix, mark the file (or its parent) with
the `"use client"` directive.
Adding the directive at source-file level cascades through tsc into
the emitted dist/ — verified gscSupport + gscCRM build cleanly after
this change.
Affected files (50 total):
src/theme/ThemeProvider.tsx
src/hooks/useDisclosure.ts
src/components/{Accordion,Carousel,DualListBox,Form,Wizard,…}.tsx
src/validation/hooks/{useValidation,useFieldValidation,…}.ts
src/genui/hooks/{useGenUI,useWebMCP}.ts
... and more — every component that touches createContext / a
React hook now self-declares as client.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previous AppShell composed limitless's high-level <Navbar> /
<Sidebar> / <Footer> / <PageShell>, which produced different markup
than chronos's own AdminShell. The visual didn't match what users
expect across the family.
Rewrite AppShell to render the same Bootstrap-flavoured markup
chronos uses inline:
- Navbar: `navbar navbar-dark navbar-expand-lg navbar-static`
with `navbar-brand`, controlled user-menu dropdown, status
indicator initials avatar, optional `navbarExtras` prop for app-
injected items (search/notifications/etc.).
- Sidebar: `sidebar sidebar-light sidebar-main sidebar-expand-lg`
with `nav nav-sidebar`, collapse + persistence in localStorage,
active highlighting via path comparison, submenu support.
- Footer: `navbar navbar-sm navbar-footer border-top` with optional
footerHtml branding + footer menu links.
All wired to ShellConfig — no fetch, no app-side state required.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The fallback for users without a displayName was hitting next-intl's
MISSING_MESSAGE error when the consumer didn't ship a `menu.account`
key. Default to the user's email (or empty string) instead of a
translation key the chrome can't guarantee.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The browser-fetching variant ran into the cross-origin / cert-trust
wall that came up the moment a real user loaded the page. Move the
network call out of the library: <AppShell> now takes a pre-resolved
ShellConfig as a required prop. Apps fetch from gsc-shell-api in
their RSC layout (server-to-server, no CORS, no cert dance) and pass
the result down.
Public surface:
AppShell, useShell, ShellConfig + sub-types
Removed:
ShellProvider (network logic gone), all fetcher props
(apiUrl, getToken, appKey, initialConfig, revalidateMs).
useShell() now returns ShellConfig directly (was ShellContextValue
with loading/error/refresh — no longer relevant).
Apps drive revalidation by re-rendering; chrome stays request-fresh
without any client-side polling.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This brings the long-untracked @limitless/ui source tree under version
control. Until now /srv/k8s/templates/limitless-ui has been a plain
file: dependency consumed by gscChronos / gscCRM / gscAdmin, with
copies scattered across web/gsc{Portal,WWW,Aether,Register}/ and
apps/gsc{Meet,Share}/. None were git-tracked.
Treating /srv/k8s/templates/limitless-ui as the canonical going
forward; secondary copies should be replaced with this version
in their consumers' Dockerfiles when they next get touched.
Changes in this initial commit beyond the snapshot:
- Add src/layout/AppShell.tsx — runtime-loaded chrome (header,
sidebar, footer) backed by gsc-shell-api. Public surface:
AppShell, ShellProvider, useShell, ShellConfig types
Framework-agnostic (no Next.js dep). Apps pass appKey + apiUrl +
getToken; AppShell composes the existing PageShell / Navbar /
Sidebar / Footer primitives with API data.
- Re-export AppShell from src/index.ts.
- Fix build script: `tsc -p tsconfig.json --noEmit false`. The bare
`tsc` command was a no-op because tsconfig.json sets noEmit:true
for typecheck speed. Existing dist/ only existed because of an
earlier emit; clean rebuilds were silently broken.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
