@kotao/storefront-contracts
Die Vertragsschicht zwischen Theme und Plattform: Zod-Schemas, gegen die der Build dein Theme validiert, plus die Signed-Context-Primitive der Runtime.
Section- & Settings-Schemas
Abschnitt betitelt „Section- & Settings-Schemas“SectionSchemaSchema— validiert denschema-Export einer Section (Name, Settings, Blocks, Presets). Deine Sections werden beim Build dagegen geprüft.SettingInputSchema+SETTING_INPUT_TYPES— die erlaubten Setting-Input-Typen (Text, Select, Farbe, Bild, …), die Händler im Editor konfigurieren.BlockDefSchema/BlockInstanceSchema,PresetSchema,SectionInstanceSchema,ValuesDocumentSchema— die Bausteine der Settings-as-data-Dokumente.
Theme-Manifest
Abschnitt betitelt „Theme-Manifest“ThemeManifestSchema validiert kotao.theme.json — das Manifest, gegen das jeder Deploy
geprüft wird. AllowedOriginSchema und ScriptTagsSchema
(+ parseStorefrontScriptTags) regeln, was ein Theme von wo laden darf.
Signierter Shop-Kontext
Abschnitt betitelt „Signierter Shop-Kontext“signShopContext / verifyShopContext und signAssertion / verifyAssertion transportieren
die authentifizierte Shop-Identität zwischen Plattform und Theme (SHOP_HEADER,
SHOP_SIGNATURE_HEADER, CLIENT_IP_HEADER). Du rufst sie selten selbst auf — der
Worker-Entry des Scaffolds verdrahtet sie —, aber sie erklären, wie ein Request beweist, zu
welchem Shop er gehört.