> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spreadknowledge.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SpreadKnowledge routing and environment origins

> How SpreadKnowledge resolves hosts across localhost, dev, and prod, and the cross-product routing and credential guardrails.

SpreadKnowledge treats host resolution as a correctness contract. Browser-facing URLs, dev origins, and prod origins are distinct, and unknown hosts are errors rather than fallbacks. This page documents the rules and the guardrails that keep products isolated.

## Origin rules

<Steps>
  <Step title="Local: localhost">
    All local browser-facing URLs must resolve on `localhost`. Aliases, `127.0.0.1`, and hosts-file entries are not interchangeable and are not supported for local development.
  </Step>

  <Step title="Dev and prod: separate origins">
    Dev and prod have distinct origins. Never point a local or dev build at a prod origin, and never point a prod build at a dev origin. Origin selection is environment-driven, not per-request.
  </Step>

  <Step title="Unknown hosts are errors">
    If a request arrives on an unknown host, the platform errors instead of falling back. Do not add wildcard host matching. Add the host explicitly to the approved configuration or reject the request.
  </Step>
</Steps>

## Cross-product routing

<Warning>
  SpreadKnowledge does not support cross-product routing. A request that enters one product must not be routed to, redirected to, or rendered by another product's surface.
</Warning>

Keep product boundaries intact:

* Do not import another product's routes, layouts, or shells into `sk-app`.
* Do not proxy requests between products at the SSR layer.
* Do not share cookies, storage keys, or auth tokens across product accounts.

## Credential isolation

<Warning>
  Never copy auth state, Mintlify access, or deployment credentials between product accounts. Each product account has its own approved config, its own reviewers, and its own EyeParity project. Reusing credentials invalidates visual proof and blocks review.
</Warning>

If you need access to another product, request it through the standard access flow and use the approved config for that product on its own machine or CI runner.