Az opcionális Complexity custom runtime deploymentje

A native Complexity-nézetek deploymentjéhez tartsd a COMPLEXITY_CUSTOM_RUNTIME_ENABLED=0 értéket, amíg a célhost nem teljesíti a custom runtime izolációs ellenőrzéseit. A gyökérben lévő Compose-konfiguráció alapértéke 0.

Release-követelmények

Használj Linux x86_64 rendszert glibc-vel, legalább Python 3.10-zel és libseccomp.so.2 könyvtárral. Pontosan a 2.5.4 és 2.5.5 könyvtárverziók elfogadottak, a megfelelő csomagolt policy-hashekkel. Eltérő verzió vagy sikertelen kernelvizsgálat esetén a capability nem érhető el.

Kövesd a backend előkészítését a kiválasztott release környezetében. A szokásos pnpm build csak runtime asseteket másol. A dist/lib/complexity/custom-runtime/python/ létrehozásához külön futtasd a pnpm complexity:runtime:prepare parancsot.

Az előkészítő parancs a vendored, hash alapján ellenőrzött wheelt használja, letöltés nélkül. Sikertelen ellenőrzés megkerüléséhez ne cseréld le a wheelt, a policyt vagy a manifestet. A backend szokásos közös buildjének az opcionális Python előkészítése nélkül is működnie kell.

Rögzített forrású deploymentnél kövesd az ellenőrzött forrás release-eljárását. Ugyanazt a forrást és célkörnyezetet készítsd elő, amelyet a service használ. Az újraindítás önmagában nem készít új buildet, és nem készíti elő a Pythont.

Aktiválás és fallback

A host izolációs ellenőrzései után állítsd be a COMPLEXITY_CUSTOM_RUNTIME_ENABLED=1 értéket a kiválasztott deploymenthez. A ComplexityService induláskor először a v1 próbáját futtatja az aktuális kernelen. Sikeres v1 próba után ellenőrzi a v2 secret-completion frissítéseket. A sikeres v2 próba engedélyezi a v2 authoringot a secretCompletion funkcióval. Ha a v2 próba nem érhető el, az authoring megtartja a v1-et megbízható secretbevitel nélkül. A meglévő v1 kimenetek továbbra is a pontos v1 csomagot használják.

A backend ellenőrzi a csomagolt asseteket, az elfogadott policyt, a gyermekfolyamat alacsony jogosultságú identitását, a korlátozott rendszerhívásokat és a tényleges kernelállapotot. Az assetek sikeres másolása vagy a Python előkészítése önmagában nem engedélyezi az authoringot.

Letiltott vagy elérhetetlen runtime esetén a native 1–3-as verziók továbbra is támogatottak. A custom nézetek olvasható fallback tartalmat és hoststátuszt mutatnak a generált böngészőkód futtatása helyett. A célzott release során őrizd meg a többi service-t és az alkalmazás adatait.

Felhasználói lehetőségek

A custom nézetek a meglévő displayOpenUI tool 4-es verzióját használják. Megtartják a meglévő toolengedélyeket és jogosultságokat. A custom forrás nem kerülheti meg a jogosultsági ellenőrzéseket.

A felhasználók az engedélyezett vezérlőkkel módosíthatják és menthetik a deklarált, nem titkos értékeket a kimenet pontos revíziójához. A mount, az újratöltés és a preview nem ment értékeket. A mentés írás előtt ellenőrzi az elvárt állapotverziót, így egy másik ablak nem írhatja észrevétlenül felül az újabb értékeket.

A mentett értékek újratöltés után is elérhetők. A chat protected-history tárolását és titkosítási policyjét használják. Nem kerülnek automatikusan modellkérésbe.

A runtime v2 megbízható secret mezőket mutathat a generált fán kívül. A Megadottnak jelölés (Mark as provided) eldobja az értéket, és csak egy nem ellenőrzött kitöltési boolean értéket küld. Nincs vault, hitelesítőadat-ellenőrzés, secretfogyasztó vagy jogosultságadás. A session legfeljebb 60 másodpercig tart. A zárolás, a bezárás, az újratöltés és az újracsatlakozás törli a bevitelt és a kitöltési státuszt. A runtime v1 elérhetetlenként jelzi a secretbevitelt.

A Levél megnyitása (Open mail) csak akkor jelenhet meg, ha egy jóváhagyott, működő hostimplementáció felkínálja a befejezett nézethez. Megbízható gombja a guest fán kívül jelenik meg. A generált custom gombok nem hajthatnak végre mailboxműveletet. A Piszkozat létrehozása (Create draft) a külön host gate-et, az action ledgert, valamint aktuális tool- és mailbox-jogosultságot igényel. A ComplexityService induláskor engedélyezi ezt a host gate-et. A szokásos kanonikus mentéshez nem kell külön jóváhagyás. A review-t igénylő javaslatok megbízható host Apply/cancel folyamatot és verzióhoz kötött baseline-ellenőrzést használnak.

A preview, az újrapróbálás, a forrásmásolás és a mentett értékek működéséhez olvasd el a custom nézet vezérlőit. Az erőforráskorlátokat a runtime korlátainál találod.

Host-action ledger

A ledger támogatja a tartós Levél megnyitása (Open mail) és Piszkozat létrehozása (Create draft) intenteket, a státusz-helyreállítást és a javaslatok review-ját. A custom nézet aktiválása önmagában nem engedélyez mailboxírást. A ComplexityService induláskor engedélyezi a külön draft gate-et, de a draft capabilitykhez ez a tábla és aktuális jogosultság is kell.

Őrizd meg a meglévő adatbázist

A ledger SQL csak új elemeket hoz létre, de a tábla jelenléte tartós intentkövetésre váltja az openMail útvonalat. Az SQL alkalmazása előtt fejezd be ennek az útvonalnak a biztonsági review-ját. Őrizd meg a meglévő táblákat, adatokat, modellneveket, @map/@@map mappingeket és foreign-key műveleteket mindkét Prisma schemában. A schemák szinkronizálásához ne használj prisma db pull parancsot, resetet vagy adatvesztést engedélyező flaget.

Az új elemeket létrehozó SQL alkalmazása

A kiválasztott instance jóváhagyott adatbázis-kapcsolatát használd. A complexity.chats és a complexity.messages táblának már léteznie kell.

1. Ellenőrizd a complexity.ui_action_intents tábla létezését ezzel a csak olvasó lekérdezéssel:

   SELECT to_regclass('complexity.ui_action_intents');

2. Ha a tábla hiányzik, alkalmazd a mailGen/ECS_MovePST_To_TempSQL/DB_Lib/Sql/20261021_complexity_ui_actions.sql fájlt a jóváhagyott adatbázis-klienssel.

3. Ellenőrizd az új táblát, a constrainteket és az indexeket az SQL-fájl alapján.

4. Ellenőrizd, hogy a meglévő táblák és foreign key-ek sértetlenek maradtak.

Az SQL létrehozza az intenttáblát, annak chat/message foreign key-eit és indexeit. Nem módosít meglévő táblát. A fájl nem idempotens. Ha a tábla már létezik, vagy az alkalmazás hibás, újabb kísérlet előtt ellenőrizd az adatbázis állapotát. Újrapróbáláshoz ne töröld a táblát.

A ledger titkosítva tárolja az action kéréseit és eredményeit. A státusz, a tulajdonos, a revízió és a művelet azonosítói támogatják az authorizationt és a reconciliationt. A tábla jelenléte önmagában nem igazolja az action implementáció működőképességét.

Mindkét Prisma client ellenőrzése és generálása

Az alkalmazásokhoz már előkészített dependencyket és adatbázis-konfigurációt használd. A mailGen/msmicroservices-architexture/ mappából futtasd:

pnpm exec prisma validate --schema src/prisma/schema.prisma
pnpm exec prisma generate --schema src/prisma/schema.prisma

A mailGen/bff/apps/web/ mappából futtasd:

pnpm exec prisma validate --schema prisma/schema.prisma
pnpm exec prisma generate --schema prisma/schema.prisma

Mindkét schema a complexity.ui_action_intents táblához rendeli a ComplexityUiActionIntent modellt, camelCase mezőkkel és snake_case oszlopmappingekkel. A tábla-, oszlop-, kulcs- és relationmappingek maradjanak összhangban. A schema ellenőrzése és a client generálása nem alkalmazza az SQL-t, és nem igazolja az adatbázis megőrzését.

Release előtt hasonlítsd össze a schemamódosítást a meglévő schemával offline. Állj meg, ha meglévő táblát töröl, vagy meglévő mappinget, illetve foreign-key műveletet módosít. A client generálása előkészítés, nem aktiválás. Az újrabuildelt service-ekhez a jóváhagyott, célzott release-eljárást használd.

Lásd a draft gate és a hiányzó tábla működését. A configureUiDraftActions(true) engedélyezi a host gate-et. Nem helyettesíti a ledger meglétét, az aktuális engedélyeket vagy a mailbox-ellenőrzéseket. A configureUiDraftActions(false) letiltja a draft capabilityket. A hitelesített recovery más böngészőfülről is beolvassa a meglévő intentet a pontos kimenethez és actionhöz. A recovery soha nem futtatja újra a writert.