Skip to main content
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

1

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.
2

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.
3

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.

​
Cross-product routing

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.
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

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.
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.