@cavuno/board 2.0.3 → 3.0.0

package/skills/cavuno-board-job-posting/SKILL.md

@@ -1,116 +0,0 @@
----
-name: cavuno-board-job-posting
-description: Build the anonymous "Post a job" funnel with the @cavuno/board SDK — jobPosting.plans, create and its status-discriminated JobPostingResult (checkout / published / pending_approval / invoice_sent), logo upload + fetchLogoByDomain, and the email-verified billing helpers (sendBillingVerification, getBillingOptions).
----
-
-# Job posting: the anonymous submission funnel
-
-The no-account "Post a job" wizard: pick a plan, upload a logo, submit — then branch on the status-discriminated result. Anonymous by design (no board-user token) and rate-limited server-side.
-
-Out of scope — do not invent exports: the `checkout` branch returns a Stripe Checkout **URL** — the full-page redirect is host-app-owned, and the webhook publishes the job after payment. The SDK ships no Stripe code and no publish/confirm method for the paid path.
-
-## When to use
-
-- The public `/post` wizard: plan picker, logo step, submission, and the post-submit screen.
-- Letting an existing plan/bundle holder submit against remaining capacity via email verification.
-
-## When not to use
-
-- Authenticated employer job management (drafts, edit, republish, ATS) — that is `board.me.companies.jobs.*`.
-- The candidate-access paywall — see `cavuno-board-paywall`.
-
-## Plans
-
-The chosen plan's `id` goes in `submission.selectedPlan`:
-
-```ts snippet
-const { data: plans } = await board.jobPosting.plans();
-for (const plan of plans) {
-  plan.id;            // → submission.selectedPlan
-  plan.prices;        // [{ currency, amountCents, isActive }]
-  plan.invoiceOnly;   // collect invoiceBilling instead of paying now
-  plan.isRecommended; // highlight in the picker
-  plan.features;      // [{ key, value }] rows for the plan card
-}
-```
-
-## Logo
-
-Upload a file, or fetch by company domain (Brandfetch). Both return a stored `publicUrl` you pass back as `logoUrl` on `create(...)`:
-
-```ts snippet
-const logo = await board.jobPosting.uploadLogo(file); // JPEG/PNG/WebP/GIF, ≤2 MB
-// or:
-const fetched = await board.jobPosting.fetchLogoByDomain('acme.com');
-// a BoardApiError code 'job_posting_logo_not_found' = no usable logo — continue without one
-```
-
-## Submit and branch on the result
-
-`create` returns a `JobPostingResult` — a discriminated union on `.status` with exactly four variants. The host app **must** branch on it; a rejected submission throws a `BoardApiError` instead.
-
-```ts snippet
-const result = await board.jobPosting.create({
-  submission: {
-    companyName: 'Acme',
-    contactName: 'Ada',
-    contactEmail: 'ada@acme.com',
-    title: 'Staff Engineer',
-    description: '<p>…</p>',
-    employmentType: 'full_time',
-    remoteOption: 'remote',
-    officeLocations: [],
-    applicationUrl: 'https://acme.com/apply',
-    salaryRangeEnabled: false,
-    selectedPlan: plan.id,
-  },
-  logoUrl: logo.publicUrl,
-});
-
-switch (result.status) {
-  case 'checkout':         // paid plan → send the poster to Stripe
-    location.href = result.checkoutUrl; // webhook publishes on payment
-    break;
-  case 'published':        // live now
-    result.jobSlug;        // link straight to the job
-    break;
-  case 'pending_approval': // moderated board — live after review
-    result.jobId;
-    break;
-  case 'invoice_sent':     // invoice plan — a Stripe invoice was emailed
-    result.jobId;
-    break;
-}
-```
-
-The five billing paths map onto those four statuses: paid-Stripe → `checkout`; free and existing bundle/subscription credit publish without payment (`published`, or `pending_approval` on moderated boards); invoice plans → `invoice_sent`.
-
-## Existing credit: the verified-email branch
-
-A submitter whose email already holds a plan/bundle can post against remaining capacity — no new charge. Verification is the gate: there is deliberately no pre-check by bare email (that would let anyone probe whether an address holds billing). Send the verification email, then read the options with the token; an option's fields become `selectedBilling`:
-
-```ts snippet
-await board.jobPosting.sendBillingVerification({ email }); // emails a token
-// …the poster pastes/clicks the token…
-const { options } = await board.jobPosting.getBillingOptions({
-  verificationToken,
-});
-if (options.length > 0) {
-  const option = options[0]!;
-  option.jobsRemaining;     // capacity left
-  option.featuredRemaining; // featured slots left
-  option.renewsAt;
-
-  await board.jobPosting.create({
-    submission, // as above — selectedPlan not needed on this path
-    selectedBilling: { type: option.type, id: option.id, planId: option.planId },
-  });
-}
-```
-
-## Verify
-
-- [ ] Every `create` call site handles all four `result.status` variants — no fallthrough that assumes `published`.
-- [ ] A paid-plan submission lands on Stripe via `result.checkoutUrl`, and the job appears on the board only after payment (webhook), not on redirect.
-- [ ] A free-plan submission on an unmoderated board returns `published` with a `jobSlug` that resolves.
-- [ ] `fetchLogoByDomain` on a bogus domain surfaces the not-found error path, and the wizard still submits without a logo.

package/skills/cavuno-board-server/SKILL.md

@@ -1,229 +0,0 @@
----
-name: cavuno-board-server
-description: SSR session plumbing with @cavuno/board/server — the __Host- httpOnly session-cookie codec (BoardSession serialize/parse/clear + the 5-minute isExpiringSoon window), the board-password grant-cookie codec with the open-redirect guards (safeRedirectPath, currentPathFromReferer), and createSessionRefresher, the single-flight rotation helper for the single-use refresh token. Use when wiring board-user auth or the board-password gate into any server-rendered frontend (TanStack Start, Next.js, Remix, Workers).
----
-
-# Server session plumbing
-
-`@cavuno/board/server` ships the pieces every SSR board frontend re-invents
-around auth: cookie codecs and the refresh-rotation helper. Everything is
-pure and platform-neutral — helpers take and return cookie **strings**
-(`Set-Cookie` values, `Cookie` headers), never framework request/response
-objects. The middleware objects themselves stay framework-owned: you write
-~20 lines of glue per framework (the `cavuno-board-tanstack-start` flavor
-skill has the reference wiring), and everything inside the glue comes from
-here.
-
-## When to use
-
-- Holding a board-user session (bearer pair) in an httpOnly cookie on SSR.
-- Refreshing the single-use refresh token safely under concurrency.
-- Wiring the board-password gate (`board.password.verify()` grant) with a
-  safe `?redirect=` round-trip.
-
-## When not to use
-
-- Browser-only SPAs with no server — use `auth.storage: 'local'` /
-  `'session'` / `'memory'` instead (see `cavuno-board-auth`).
-- Framework middleware objects, CSRF protection, cookie encryption — all
-  app-owned. The session cookie is httpOnly + JSON; if you want an encrypted
-  cookie, wrap the codec output yourself.
-
-## The session cookie
-
-The SDK never sees server storage (create the client with no `auth.storage`
-→ `nostore`). The bearer pair lives in ONE `__Host-` httpOnly cookie owned
-by your app; `BoardSession` is `{ accessToken, refreshToken, expiresAt }`.
-
-```ts snippet
-import {
-  clearSessionCookie,
-  parseSessionCookie,
-  serializeSessionCookie,
-} from '@cavuno/board/server';
-
-// After login: persist the pair (BoardAuthSession already carries expiresAt).
-const session = await board.auth.login({ email, password });
-setCookieHeader = serializeSessionCookie({
-  accessToken: session.accessToken,
-  refreshToken: session.refreshToken,
-  expiresAt: session.expiresAt,
-});
-
-// On every request: parse the Cookie header your framework hands you.
-const current = parseSessionCookie(request.headers.get('cookie'));
-
-// On logout (after board.auth.logout({ refreshToken })): expire it.
-setCookieHeader = clearSessionCookie();
-```
-
-`serializeSessionCookie` locks the attributes (`__Host-` prefix, `Path=/`,
-`HttpOnly`, `Secure`, `SameSite=Lax`, 30-day `Max-Age` matching the refresh
-token's server-side lifetime). `parseSessionCookie` returns `null` for
-absent, malformed, or wrong-shape cookies — treat `null` as signed out.
-
-## Single-flight refresh in a session middleware
-
-Refresh tokens are single-use: two concurrent requests that both refresh
-burn the pair — the loser 401s and the user is signed out mid-session.
-`createSessionRefresher` dedupes concurrent rotations per refreshToken, and
-`isExpiringSoon` gives you the proactive 5-minute window so the old access
-token still works while you rotate.
-
-```ts snippet
-import {
-  clearSessionCookie,
-  createSessionRefresher,
-  isExpiringSoon,
-  parseSessionCookie,
-  serializeSessionCookie,
-} from '@cavuno/board/server';
-
-// Module scope: ONE refresher per board client, shared by all requests —
-// that sharing IS the single-flight guarantee — WITHIN one process/isolate. Across instances (serverless/multi-pod) simultaneous refreshes can still race; the proactive isExpiringSoon window keeps that rare, it does not eliminate it.
-const refreshSession = createSessionRefresher(board);
-
-async function resolveSession(cookieHeader: string | null) {
-  const session = parseSessionCookie(cookieHeader);
-  if (!session) return { session: null, setCookie: null };
-  if (!isExpiringSoon(session, Date.now())) {
-    return { session, setCookie: null };
-  }
-  const next = await refreshSession(session);
-  return next
-    ? { session: next, setCookie: serializeSessionCookie(next) }
-    : { session: null, setCookie: clearSessionCookie() }; // burned/revoked → signed out
-}
-```
-
-The contract: a rotated `BoardSession` on success (write it back to the
-cookie), `null` on a 401 (the token is burned or the session revoked —
-clear the cookie and continue signed out, **never retry**), and anything
-else (network error, 5xx, 429) rethrows for your error handling. Calls with
-the SAME refreshToken while one rotation is in flight await that same
-rotation; after it settles, the next call starts fresh.
-
-Pass the access token per SDK call — the client itself stays stateless:
-
-```ts snippet
-const me = await board.me.retrieve(undefined, {
-  headers: { authorization: `Bearer ${session.accessToken}` },
-});
-```
-
-## The board-password grant cookie
-
-On password-protected boards, `board.password.verify({ password })` returns
-an HMAC grant token; gated reads take it as the `X-Board-Access` header.
-Same codec pattern, 24-hour cookie (hosted parity):
-
-```ts snippet
-import {
-  clearGrantCookie,
-  parseGrantCookie,
-  serializeGrantCookie,
-} from '@cavuno/board/server';
-
-const { token } = await board.password.verify({ password });
-setCookieHeader = serializeGrantCookie(token);
-
-// Thread it to gated reads:
-const grant = parseGrantCookie(request.headers.get('cookie'));
-const jobs = await board.jobs.list(undefined, {
-  headers: grant ? { 'X-Board-Access': grant } : {},
-});
-```
-
-When a read still fails with `isBoardPasswordRequired` (grant expired or
-the password rotated), send the visitor to your `/password` page and clear
-the stale cookie with `clearGrantCookie()`.
-
-## Open-redirect guards
-
-The `/password?redirect=` round-trip is the classic open-redirect hole.
-`safeRedirectPath` transcribes the hosted board's guard (tested
-against it): same-origin absolute paths pass through, everything else —
-`//evil.com`, full URLs, `javascript:`, backslash and control-character
-normalization bypasses — collapses to `'/'`.
-
-```ts snippet
-import {
-  currentPathFromReferer,
-  safeRedirectPath,
-} from '@cavuno/board/server';
-
-// Where to send the visitor after a correct password:
-redirect(safeRedirectPath(query.redirect));
-
-// Building the challenge link: derive the come-back path from the Referer
-// your framework read for you (already guarded internally).
-const backTo = currentPathFromReferer(request.headers.get('referer'));
-redirect(`/password?redirect=${encodeURIComponent(backTo)}`);
-```
-
-## Thread derivations (core entry, not /server)
-
-The messaging thread's pure rules ship on the main entry — they're
-client-safe view logic, not server plumbing:
-
-```ts snippet
-import { isColdRule, isOwnMessage, lastOwnMessageId } from '@cavuno/board';
-
-const mine = isOwnMessage(message, counterpartyId); // bubble side + actions
-const composerLocked = isColdRule(messages, counterpartyId); // cold-message cap
-const seenTargetId = lastOwnMessageId(messages, counterpartyId); // "Seen" row
-```
-
-`isColdRule` mirrors the server gate (`messaging_cold_rule` 403) so the
-composer can disable itself instead of surfacing the error — the server
-stays authoritative.
-
-## Multi-board origins
-
-One origin serving MULTIPLE boards must scope its cookies and storage per
-board — otherwise one board's login clobbers another's (hosted scopes its
-grant cookie per account for exactly this reason). Pass the board
-identifier to the codecs; the browser storage modes scope automatically via
-`createBoardClient`'s own `board`:
-
-```ts snippet
-import {
-  serializeSessionCookie,
-  parseSessionCookie,
-  sessionCookieName,
-} from '@cavuno/board/server';
-
-const scope = { board: 'pk_boardA' };
-const cookie = serializeSessionCookie(session, scope);
-const restored = parseSessionCookie(cookieHeader, scope);
-```
-
-Single-board deployments (one board per hostname — the starter model) omit
-the scope; the cookie names stay stable.
-
-## Anti-patterns
-
-```ts no-check
-// NEVER auto-retry a null refresh — the token is single-use; a retry loop
-// hammers the API with burned tokens:
-while (!(await refreshSession(session))) {} // wrong
-
-// NEVER create a refresher per request — per-request instances can't
-// dedupe, which defeats the single-flight design:
-const refreshSession = createSessionRefresher(board); // must be module scope
-
-// NEVER redirect to the raw query param:
-redirect(query.redirect); // open redirect — use safeRedirectPath
-
-// NEVER put the session in auth.storage on the server — auth.refresh persists the rotated pair into client.storage, so a shared persistent store bleeds one user's tokens into other requests (cross-user session leak). 'nostore' + per-call headers is the contract — a shared instance
-// leaks one user's tokens into another's request. Cookie + per-call header.
-```
-
-## Checklist
-
-- [ ] Session cookie parsed on every request; `null` treated as signed out.
-- [ ] `createSessionRefresher` instance is module-scoped (shared across
-      requests) and its `null` result clears the cookie without retrying.
-- [ ] Rotated sessions are written back with `serializeSessionCookie`.
-- [ ] Every `?redirect=` consumer goes through `safeRedirectPath`.
-- [ ] Bearer tokens ride per-call headers; the shared client has no storage.

package/skills/cavuno-board-suggest/SKILL.md

@@ -1,119 +0,0 @@
----
-name: cavuno-board-suggest
-description: Federated keyword search suggestions with the @cavuno/board SDK — board.search.suggest for companies + taxonomy terms in one server-ranked list, and the headless createSuggestController under @cavuno/board/suggest (debounce, abort, stale-drop). Use when building a search dropdown, typeahead, or autocomplete that mirrors the hosted board.
----
-
-# Search suggest: dropdown typeahead
-
-`board.search.suggest` returns ONE interleaved, server-ordered list of
-company and taxonomy-term suggestions for a keyword — the hosted search
-dropdown contract. `@cavuno/board/suggest` wraps that call in a headless
-controller so debounce / abort / stale-drop ship with the SDK and patch via
-npm update.
-
-## When to use
-
-- The global search input's suggestion dropdown.
-- Any typeahead that should offer companies and category/skill terms
-  together, ranked the way the hosted board ranks them.
-
-## When not to use
-
-- Location autocomplete — `board.taxonomy.places.list({ q })`.
-- Taxonomy-only option lists for filter sidebars —
-  `board.taxonomy.categories/skills/suggestions.list`.
-- Job results themselves — `board.jobs.list` / `board.jobs.search`.
-
-## Call the endpoint directly
-
-```ts snippet
-const { items, query } = await board.search.suggest({ q: 'acme', limit: 10 });
-// items is server-ranked — do NOT re-sort.
-for (const item of items) {
-  if (item.type === 'company') {
-    item.slug; // public company URL slug
-    item.name;
-    item.jobCount;
-  } else {
-    // item.type === 'term'
-    item.termType; // 'category' | 'skill'
-    item.displayName;
-    item.canonicalSlug; // for links
-    item.sourceSlug; // for job filters
-  }
-}
-```
-
-Queries under two characters return an empty `items` array. `limit` is
-1–25 (default 25). Order is the contract.
-
-## Prefer the headless controller for UI
-
-The controller owns debounce (default 250ms), min-chars (default 2),
-in-flight abort, and stale-drop. Compatible with `useSyncExternalStore`.
-
-```ts snippet
-import { createSuggestController } from '@cavuno/board/suggest';
-
-const suggest = createSuggestController(board, { limit: 10 });
-const unsub = suggest.subscribe(() => {
-  const { items, status, query } = suggest.getState();
-  // render dropdown; previous items are retained while status === 'loading'
-});
-suggest.setQuery(inputValue);
-// Hide the currently-applied company filter from the list:
-suggest.setExcludedCompanySlugs(appliedCompanySlugs);
-// teardown:
-unsub();
-suggest.dispose();
-```
-
-`setExcludedCompanySlugs` is the ONE permitted view-level filter (company
-items only, re-filters current items synchronously — no new request). Never
-reshape or re-sort the rest of the response.
-
-## Wire a company pick into the listing
-
-Company slugs are the URL identity. Map them onto the jobs surface as
-`companySlug` — never resolve slug→id client-side:
-
-```ts snippet
-import { parseListingFilters } from '@cavuno/board/filters';
-
-const filters = parseListingFilters(rawSearchParams);
-// filters.company is string[] of public slugs
-
-const page = await board.jobs.list({
-  limit: 20,
-  companySlug: filters.company,
-});
-```
-
-Unknown slugs are dropped server-side (not an error). If the entire company
-filter resolves to no known companies, the listing is empty (`count: 0`).
-Combined with `companyId` as a union when both are set.
-
-## Anti-patterns
-
-```ts no-check
-// NEVER re-sort server-ranked items:
-items.sort((a, b) => a.name.localeCompare(b.name));
-// NEVER resolve company slug → id on the client:
-const id = await lookupCompanyId(item.slug);
-board.jobs.list({ companyId: [id] });
-// NEVER hand-roll debounce/abort — use the controller so patches ship via npm.
-```
-
-## Out of scope — do not invent exports
-
-No React components, no dropdown UI, no keyboard navigation — this package
-is the data + controller layer. Location suggest stays on `taxonomy.places`.
-
-## Verify
-
-- [ ] Typing under 2 characters shows no suggestions and no network call
-      from the controller.
-- [ ] Fast typing cancels the previous request; only the final query's
-      results render.
-- [ ] Selecting a company writes its public slug into the URL and the
-      listing request uses `companySlug`, not a client-resolved id.

package/skills/cavuno-board-theme/SKILL.md

@@ -1,57 +0,0 @@
----
-name: cavuno-board-theme
-description: Optional hosted-board theme compatibility with @cavuno/board/theme. Use only when a custom frontend deliberately mirrors or migrates an existing Cavuno hosted theme; the consuming application normally owns tokens, fonts, and color mode.
----
-
-# Optional hosted-board theme compatibility
-
-The custom frontend owns its visual system by default: semantic design tokens, component styles, font loading, and light/dark-mode state belong in the application. Do not make remote `board.context().theme` the default source of truth for a new SDK frontend.
-
-`@cavuno/board/theme` exists for a narrower job: mirroring an existing hosted board or providing a starting point during a hosted-to-custom migration.
-
-## When to use
-
-- The human explicitly wants the custom frontend to mirror the current hosted board.
-- A migration needs a temporary compatibility layer while tokens move into the application.
-- One application intentionally renders many Cavuno boards with different operator-owned themes.
-
-## When not to use
-
-- A normal custom frontend whose design system already defines tokens and fonts.
-- Component-level styling.
-- As a replacement for the framework's theme provider or font system.
-
-## Read compatibility values
-
-```ts snippet
-import {
-  boardThemeToCss,
-  googleFontsUrl,
-  themeMode,
-} from '@cavuno/board/theme';
-
-const context = await board.context();
-const hostedTheme = {
-  css: boardThemeToCss(context.theme),
-  fontUrl: googleFontsUrl(context.theme),
-  mode: themeMode(context.theme),
-};
-```
-
-`boardThemeToCss` validates the stored colors before emitting CSS. A null theme returns no CSS, so the application default remains intact.
-
-## Migration guidance
-
-1. Compare the returned colors, fonts, and mode with the consuming design system.
-2. Move the chosen values into the application's own semantic tokens and font loader.
-3. Remove the runtime theme injection when the application becomes authoritative.
-
-If permanent multi-board mirroring is an explicit requirement, inject the validated CSS after the static theme and make the framework's theme provider apply the returned mode. Do not interpolate raw stored colors or build font URLs yourself.
-
-## Verify
-
-- [ ] The application renders correctly when `context.theme` is null.
-- [ ] New custom frontends do not fetch theme data merely to establish basic styling.
-- [ ] Compatibility CSS never contains unsafe stored color syntax.
-- [ ] Font loading and color-mode ownership are explicit and tested.
-- [ ] A migration has a documented point where the application becomes authoritative.

package/skills/flavors/tanstack-start/SKILL.md

@@ -1,100 +0,0 @@
----
-name: cavuno-board-tanstack-start
-description: TanStack-Start-on-Cloudflare-Workers reference wiring for a headless Cavuno board — SSR loaders calling @cavuno/board server-side, the session held in an __Host- httpOnly cookie owned by the app, a single-flight refresh helper, and FetchOptions cache passthrough on Workers.
----
-
-# Reference flavor: TanStack Start on Cloudflare Workers
-
-This is the framework-specific layer for the reference starter (`wollemiahq/cavuno-board-starter`). The core skills (`cavuno-board-client`, `-jobs`, `-auth`, `-errors`) define the SDK surface; this skill shows how to wire it into TanStack Start on Workers. Read the core skills first.
-
-## When to use
-
-- The project depends on `@tanstack/react-start`.
-- You need the SSR-loader + httpOnly-cookie + single-flight-refresh patterns.
-
-## One shared, stateless client
-
-```ts
-import { createBoardClient } from '@cavuno/board';
-
-// Module-scoped, no auth.storage → safe across concurrent Workers requests.
-export const board = createBoardClient({
-  board: process.env.PUBLIC_CAVUNO_BOARD!,
-});
-```
-
-## Read in server loaders; cache via FetchOptions
-
-Call the SDK only on the server (route loaders / server functions), never from the browser with a token. On Workers, pass cache directives straight through:
-
-```ts no-check
-import { createFileRoute } from '@tanstack/react-start';
-import { board } from '~/lib/board';
-
-export const Route = createFileRoute('/jobs')({
-  loader: async () => {
-    // `cf` rides straight to the Workers fetch — the SDK needs no framework knowledge.
-    return board.jobs.list({ limit: 20 }, { cf: { cacheTtl: 60 } } as never);
-  },
-});
-```
-
-## Session in an `__Host-` httpOnly cookie owned by the app
-
-The SDK never owns the cookie. Store the bearer pair in an `__Host-`-prefixed httpOnly cookie set by your server functions, read it on each request, and pass the token per call:
-
-```ts no-check
-import { board } from '~/lib/board';
-import { readSessionCookie } from '~/lib/session.server';
-
-export async function loadMe(request: Request) {
-  const { accessToken } = readSessionCookie(request);
-  // Pass the token via `options` (2nd arg). The 1st arg is `query`.
-  return board.me.retrieve(undefined, {
-    headers: { authorization: `Bearer ${accessToken}` },
-  });
-}
-```
-
-## Single-flight refresh
-
-Refresh tokens are single-use; concurrent 401s must trigger exactly one rotation. Encode it once and reuse everywhere:
-
-```ts no-check
-import { isUnauthorized } from '@cavuno/board';
-import { board } from '~/lib/board';
-
-let inflight: Promise<void> | null = null;
-
-// `getAccessToken`/`getRefreshToken` read your __Host- cookie (the SDK never
-// touches it). On a 401 we refresh exactly once — concurrent callers await the
-// same `inflight` promise — then retry `run` with the rotated token. Your
-// refresh handler must write the new pair to the cookie so the retry reads it.
-export async function withFreshSession<T>(
-  getAccessToken: () => string,
-  getRefreshToken: () => string,
-  run: (accessToken: string) => Promise<T>): Promise<T> {
-  try {
-    return await run(getAccessToken());
-  } catch (err) {
-    if (!isUnauthorized(err)) throw err;
-    inflight ??= board.auth
-      .refresh({ refreshToken: getRefreshToken() })
-      .then(() => undefined)
-      .finally(() => (inflight = null));
-    await inflight;
-    return run(getAccessToken()); // retry with the rotated token
-  }
-}
-```
-
-## Canonical URLs
-
-Mirror the hosted board's public URLs so indexed links survive a hosted → headless migration: job detail at `/companies/$companySlug/jobs/$jobSlug`, listings at `/jobs`, `/jobs/$keyword`, `/jobs/locations/$slug`.
-
-## Checklist
-
-- [ ] All SDK calls are server-side; no bearer token in the browser bundle.
-- [ ] Session in an `__Host-` httpOnly cookie owned by the app, passed per call.
-- [ ] Single-flight refresh wraps concurrent 401s.
-- [ ] Public route paths mirror the hosted board's canonical URLs.