Portal (#6391)

# Description of Changes

## What & why

This PR introduces the **Stirling developer portal** — a new
control-plane frontend that sits alongside the existing PDF editor —
plus the shared design system and workspace structure needed to host
both apps in one frontend.

The portal is the parent product surface: where users connect sources,
compose pipelines, wire agents, and manage usage / billing /
infrastructure, with the PDF editor as one capability inside it. This PR
lays the **foundation** — workspace reshape, design system, app shell,
navigation, and a mock-driven home — rather than wiring real backends
(those surfaces are placeholders for follow-up phases).

## What's in this PR

**1. Frontend repo reshape (`frontend/src/` → `frontend/editor/`)**
The existing editor app moved under `frontend/editor/`, so `editor`,
`portal`, and `shared` are siblings in one workspace. All references
were updated accordingly: `LICENSE`, `.dockerignore`, `.gitignore`,
build/sign shell scripts, the GH language-check script, the Taskfile,
and Docker config. **No editor source logic changed — path references
only.**

**2. New shared design system (`frontend/shared/`)**
- **Design tokens** in `tokens.css` as the single runtime source of
truth (light/dark, category accents, gradients). `tokens.ts` now holds
only the `Tier` type — the old JS palette mirror was removed (nothing
consumed it and it had drifted).
- ~30 framework-light **components** (Card, Button, Input, Select, Tabs,
Modal, Drawer, Toast, MetricCard, StatusBadge, Skeleton, EmptyState, …)
with Storybook stories.
- **Typed data catalogues**: `endpoints.ts` (10 verticals / 64
endpoints) and `ops.ts`.

**3. New developer portal app (`frontend/portal/`)**
- App shell: `Header`, `Sidebar`, `AssistantPanel`, search modal,
notifications, tier switcher, theme toggle, MSW toggle.
- **Tier-aware** home (free / pay-as-you-go / enterprise): KPI strip,
30-day usage chart, onboarding checklist, quick actions, recent
activity, region health, product grid, and a curated **"Popular use
cases"** teaser.
- **Documents** view hosting the full, tab-filterable endpoint
catalogue.
- Placeholder views for Sources / Pipelines / Agents / Editor /
Infrastructure / Usage & Billing / Developer Docs / Settings (follow-up
phases).
- **MSW-mocked** API layer: `api/*` issues real `fetch`, intercepted by
mocks in dev/Storybook; pointing at a real backend is just a matter of
not registering MSW. `react-router` URLs; Tier / View / UI contexts.

**4. Tooling & guardrails**
- ESLint extended to `portal` + `shared`, with **layering-boundary
rules**: `shared/` may depend only on third-party packages and itself
(no `@app` / `@portal` / `@core` / `@proprietary` / Tauri), so it stays
cleanly extractable into a standalone package later.
- `dpdm` circular-dependency check now walks editor + portal + shared
(the old glob matched only 2 files).
- New **devDependencies only** — Storybook (+ a11y/docs/themes addons),
MSW. No runtime dependencies added.
- New tasks: `frontend:dev:portal`, `frontend:build:portal`.

## Testing done locally

- `tsc` for both `portal` and `shared` projects — clean
- `eslint --max-warnings=0` across the whole frontend — clean
- `dpdm` circular-dependency check — no cycles
- Editor builds clean: `vite build editor --mode core` (✓ built, only
the pre-existing >500 kB chunk-size advisory)
- Editor runs in dev (core mode) with **zero console errors**; portal
runs in dev across all three tiers

## Notes for reviewers

- The change is overwhelmingly **additive**: `shared/` and `portal/` are
brand-new; the existing editor is path-reference changes only.
- The portal is intentionally **mock-driven** at this stage — real
backends and the remaining views land in follow-up phases.

---

## Checklist

### General

- [ ] I have read the [Contribution
Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md)
- [ ] I have read the [Stirling-PDF Developer
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md)
(if applicable)
- [ ] I have read the [How to add new languages to
Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md)
(if applicable)
- [x] I have performed a self-review of my own code
- [x] My changes generate no new warnings

### Documentation

- [ ] I have updated relevant docs on [Stirling-PDF's doc
repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/)
(if functionality has heavily changed)
- [ ] I have read the section [Add New Translation
Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags)
(for new translation tags only)

### Translations (if applicable)

- [ ] I ran
[`scripts/counter_translation.py`](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/docs/counter_translation.md)

### UI Changes (if applicable)

- [ ] Screenshots or videos demonstrating the UI changes are attached
(e.g., as comments or direct attachments in the PR)

### Testing (if applicable)

- [ ] I have run `task check` to verify linters, typechecks, and tests
pass
- [x] I have tested my changes locally. Refer to the [Testing
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/DeveloperGuide.md#7-testing)
for more details.

---------

Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

frontend/portal/src/api/assistant.ts

@@ -0,0 +1,15 @@
+import { httpJson } from "@portal/api/http";
+
+/** GET /v1/assistant/suggestions */
+export async function fetchAssistantSuggestions(): Promise<readonly string[]> {
+  return httpJson<readonly string[]>("/v1/assistant/suggestions");
+}
+
+/** POST /v1/assistant/messages */
+export async function getAssistantReply(input: string): Promise<string> {
+  const res = await httpJson<{ reply: string }>("/v1/assistant/messages", {
+    method: "POST",
+    body: { input },
+  });
+  return res.reply;
+}

frontend/portal/src/api/endpoints.ts

@@ -0,0 +1,15 @@
+import { httpJson } from "@portal/api/http";
+import type { Vertical } from "@shared/data/endpoints";
+
+export type {
+  Endpoint,
+  EndpointSchema,
+  EndpointTierGate,
+  Vertical,
+  VerticalKey,
+} from "@shared/data/endpoints";
+
+/** GET /v1/endpoints — verticals plus their endpoints. */
+export async function fetchVerticals(): Promise<Vertical[]> {
+  return httpJson<Vertical[]>("/v1/endpoints");
+}

frontend/portal/src/api/home.ts

@@ -0,0 +1,44 @@
+import { httpJson } from "@portal/api/http";
+import type {
+  ActivityEvent,
+  KpiEntry,
+  OnboardingStep,
+  RegionHealth,
+  UsageSeriesResponse,
+} from "@portal/mocks/home";
+import type { Tier } from "@portal/contexts/TierContext";
+
+export type {
+  ActivityEvent,
+  ActivityKind,
+  KpiEntry,
+  OnboardingStep,
+  RegionHealth,
+  UsagePoint,
+  UsageSeriesResponse,
+} from "@portal/mocks/home";
+
+/** GET /v1/analytics/usage?window=30d */
+export async function fetchUsageSeries(): Promise<UsageSeriesResponse> {
+  return httpJson<UsageSeriesResponse>("/v1/analytics/usage?window=30d");
+}
+
+/** GET /v1/activity?limit=8 */
+export async function fetchRecentActivity(): Promise<ActivityEvent[]> {
+  return httpJson<ActivityEvent[]>("/v1/activity?limit=8");
+}
+
+/** GET /v1/home/kpis?tier=… */
+export async function fetchHomeKpis(tier: Tier): Promise<KpiEntry[]> {
+  return httpJson<KpiEntry[]>(`/v1/home/kpis?tier=${encodeURIComponent(tier)}`);
+}
+
+/** GET /v1/regions/health (Enterprise) */
+export async function fetchRegionHealth(): Promise<RegionHealth[]> {
+  return httpJson<RegionHealth[]>("/v1/regions/health");
+}
+
+/** GET /v1/onboarding (Free) */
+export async function fetchOnboarding(): Promise<OnboardingStep[]> {
+  return httpJson<OnboardingStep[]>("/v1/onboarding");
+}

frontend/portal/src/api/http.ts

@@ -0,0 +1,59 @@
+/**
+ * Shared HTTP plumbing for the portal's service layer.
+ *
+ * Every `api/*.ts` module calls {@link httpJson}, which issues a real `fetch`.
+ * In dev and Storybook those requests are intercepted by the MSW handlers in
+ * `mocks/` and answered with fixture data; pointing at a real backend is just
+ * a matter of not registering MSW. Consumers don't change either way.
+ */
+
+export interface HttpRequestOptions {
+  method?: "GET" | "POST" | "PUT" | "PATCH" | "DELETE";
+  body?: unknown;
+  /** Extra headers; Content-Type and Accept are set automatically. */
+  headers?: Record<string, string>;
+  signal?: AbortSignal;
+}
+
+export class HttpError extends Error {
+  constructor(
+    public readonly status: number,
+    public readonly statusText: string,
+    public readonly body: unknown,
+  ) {
+    super(`${status} ${statusText}`);
+    this.name = "HttpError";
+  }
+}
+
+/**
+ * Thin JSON fetch wrapper used by every api module. In dev/Storybook the
+ * request is served by MSW; against a real backend it hits the network.
+ */
+export async function httpJson<T>(
+  path: string,
+  options: HttpRequestOptions = {},
+): Promise<T> {
+  const res = await fetch(path, {
+    method: options.method ?? "GET",
+    headers: {
+      Accept: "application/json",
+      ...(options.body !== undefined
+        ? { "Content-Type": "application/json" }
+        : {}),
+      ...options.headers,
+    },
+    body: options.body !== undefined ? JSON.stringify(options.body) : undefined,
+    signal: options.signal,
+  });
+  if (!res.ok) {
+    let body: unknown = null;
+    try {
+      body = await res.json();
+    } catch {
+      // ignore — non-JSON error response
+    }
+    throw new HttpError(res.status, res.statusText, body);
+  }
+  return (await res.json()) as T;
+}

frontend/portal/src/api/notifications.ts

@@ -0,0 +1,19 @@
+import { httpJson } from "@portal/api/http";
+import type {
+  Notification,
+  NotificationCategory,
+} from "@portal/mocks/notifications";
+
+export type { Notification, NotificationCategory };
+
+/** GET /v1/notifications */
+export async function fetchNotifications(): Promise<Notification[]> {
+  return httpJson<Notification[]>("/v1/notifications");
+}
+
+/** POST /v1/notifications/mark-all-read */
+export async function markAllNotificationsRead(): Promise<void> {
+  await httpJson<{ ok: true }>("/v1/notifications/mark-all-read", {
+    method: "POST",
+  });
+}

frontend/portal/src/api/ops.ts

@@ -0,0 +1,37 @@
+import { HttpError, httpJson } from "@portal/api/http";
+import type { FeaturedOp, OpResultMap } from "@portal/mocks/ops";
+
+export type { FeaturedOp, OpResultMap };
+
+/** GET /v1/ops/featured */
+export async function fetchFeaturedOps(): Promise<FeaturedOp[]> {
+  return httpJson<FeaturedOp[]>("/v1/ops/featured");
+}
+
+export class UnknownOpError extends Error {
+  constructor(public readonly opId: string) {
+    super(`Unknown op: ${opId}`);
+    this.name = "UnknownOpError";
+  }
+}
+
+/** POST /v1/ops/{opId}/run */
+export async function runSingleOp(
+  opId: string,
+  sample: string,
+): Promise<{ result: OpResultMap; durationMs: number }> {
+  try {
+    return await httpJson<{ result: OpResultMap; durationMs: number }>(
+      `/v1/ops/${encodeURIComponent(opId)}/run`,
+      {
+        method: "POST",
+        body: { sample },
+      },
+    );
+  } catch (err) {
+    if (err instanceof HttpError && err.status === 404) {
+      throw new UnknownOpError(opId);
+    }
+    throw err;
+  }
+}

frontend/portal/src/api/search.ts

@@ -0,0 +1,9 @@
+import { httpJson } from "@portal/api/http";
+import type { QuickAction } from "@portal/mocks/search";
+
+export type { QuickAction };
+
+/** GET /v1/search/quick-actions */
+export async function fetchQuickActions(): Promise<QuickAction[]> {
+  return httpJson<QuickAction[]>("/v1/search/quick-actions");
+}