@cosmicdrift/kumiko-samples 0.385.0 → 0.387.0

package/packages/bundled-features/src/legal-pages/feature.ts

@@ -24,13 +24,12 @@ import {
 
 export { type LegalPagesBootCheckCtx, runLegalPagesBootCheck } from "./lib/boot-check.ts";
 
-// QN-Konstante als dokumentierter Public-Contract des template-resolver-
-// Features. Ein magic-string statt eines Code-Imports ist hier explizit
-// gewollt: Cross-Feature-Calls gehen nur über stable Public-API
-// (handler-name + payload-shape), nicht über interne Module-Refs. Wenn
-// template-resolver's Handler-Name sich ändert, ist das ein semver-major
-// und muss in beiden Features synchronisiert werden — gleiches Risiko
-// wie bei jedem API-Endpunkt.
+// QN constant as the documented public contract of the template-resolver
+// feature. A magic string is intentional instead of a code import: cross-feature
+// calls use only the stable public API (handler name + payload shape), not
+// internal module references. If template-resolver's handler name changes, it is
+// a semver-major change and must be synchronized in both features—the same risk
+// as with any API endpoint.
 const TEXT_BLOCK_BY_SLUG_QN = "template-resolver:query:by-slug";
 
 // Return shape of bySlugQuery (template-resolver/handlers/by-slug.query.ts).
@@ -53,25 +52,25 @@ const PUBLIC_PAGE_CACHE = { kind: "revalidate", maxAgeSeconds: 60 } as const;
 // additional pages (e.g. terms/AGB).
 //
 // Cross-Feature-Decoupling:
-//   • Routes nutzen app.fetch zu "/api/query" mit dem QN-string
-//     `template-resolver:query:by-slug` — kein Code-Import von template-resolver
-//   • Boot-Check nutzt ctx.templateResolver (über extraContext) — symmetrisch
-//     zum config/tenant-Pattern
-//   • Single Type-Import (TemplateResolverApi) bleibt — type-only verstößt
-//     nicht gegen Cross-Feature-Coupling
+//   • Routes use app.fetch to "/api/query" with the QN string
+//     `template-resolver:query:by-slug`—no code import from template-resolver
+//   • The boot check uses ctx.templateResolver (via extraContext), symmetrically
+//     with the config/tenant pattern
+//   • The single type import (TemplateResolverApi) remains; type-only imports do
+//     not violate cross-feature coupling
 //
-// Voraussetzungen für Production:
-//   • App-Bootstrap muss extraContext: { templateResolver: createTemplateResolverApi(db, registry) }
-//     setzen — sonst wirft Boot-Check beim Start
-//   • anonymousAccess: { defaultTenantId: SYSTEM_TENANT_ID } — sonst
-//     antworten die Routes mit 503
+// Production requirements:
+//   • App bootstrap must set extraContext: { templateResolver: createTemplateResolverApi(db,
+//     registry) } —otherwise the boot check throws at startup
+//   • anonymousAccess: { defaultTenantId: SYSTEM_TENANT_ID }—otherwise
+//     the routes respond with 503
 export type LegalPagesWrapLayout = PublicPageWrapLayout;
 
 export type LegalPagesOptions = {
-  /** Custom Layout-Wrapper für die /legal/*-Routes. Default: minimaler
-   *  HTML-Skeleton aus markdown.ts (`wrapInLayout`). Apps die ihr eigenes
-   *  Marketing-Layout (Header/Footer/Theme) auch um Legal-Body legen
-   *  wollen, übergeben hier ihre Render-Function. */
+  /** Custom layout wrapper for the /legal/* routes. Default: minimal
+   *  HTML skeleton from markdown.ts (`wrapInLayout`). Apps that want to place
+   *  their own marketing layout (header/footer/theme) around the legal body
+   *  can provide their render function here. */
   readonly wrapLayout?: LegalPagesWrapLayout;
   /** Public HTML routes to register. Default: LEGAL_ROUTES (DACH: DE+EN
    *  imprint/privacy). Non-DACH apps (other default language, additional
@@ -140,18 +139,18 @@ export function createLegalPagesFeature(opts: LegalPagesOptions = {}): FeatureDe
         // Public pages backed by a DB query: bound the per-IP read rate.
         rateLimit: { per: "ip+handler", limit: 60, windowSeconds: 60 },
         handler: async (c, { systemQuery }) => {
-          // Architektur: 1 App = X Tenants = 1 Impressum. Egal welche
-          // Subdomain der Visitor besucht (apex, admin.*, tenant-x.*) —
-          // legal-pages serven IMMER die SYSTEM_TENANT-Texte. systemQuery
-          // erzwingt SYSTEM_TENANT_ID in-process (kein X-Tenant-Header-
-          // Trick über app.fetch — der sähe für einen host-basierten
-          // anonymousAccess-Resolver wie ein Client-Override aus und würde
-          // von resolverTrust: "authoritative" zurecht abgelehnt).
+          // Architecture: 1 app = X tenants = 1 imprint. Regardless of which
+          // subdomain the visitor uses (apex, admin.*, tenant-x.*),
+          // legal-pages ALWAYS serves the SYSTEM_TENANT texts. systemQuery
+          // enforces SYSTEM_TENANT_ID in-process (no X-Tenant-Header trick
+          // through app.fetch—the host-based anonymousAccess resolver would
+          // see that as a client override and correctly reject it with
+          // resolverTrust: "authoritative").
           let data: TextBlockQueryResult;
           try {
             // @cast-boundary engine-payload — dispatcher.query returnt
-            // unknown; Shape ist durch bySlugQuery's Handler-Return-Type
-            // (siehe template-resolver/handlers/by-slug.query.ts) vertraut.
+            // unknown; the shape is trusted because of bySlugQuery's handler return type
+            // (see template-resolver/handlers/by-slug.query.ts).
             data = (await systemQuery(
               TEXT_BLOCK_BY_SLUG_QN,
               { slug: route.slug, locale: route.lang },
@@ -178,8 +177,8 @@ export function createLegalPagesFeature(opts: LegalPagesOptions = {}): FeatureDe
             String(data.modifiedAt ?? ""),
           ]);
           const extra = { "content-type": "text/html; charset=utf-8" };
-          // 304 (Revision unverändert) und HEAD überspringen beide das
-          // Markdown-Rendern — der Body wird ohnehin verworfen.
+          // Both 304 (unchanged revision) and HEAD skip Markdown rendering—the body
+          // would be discarded anyway.
           if (
             etagMatches(c.req.raw.headers.get("if-none-match"), etag) ||
             c.req.method === "HEAD"
@@ -228,21 +227,21 @@ export function createLegalPagesFeature(opts: LegalPagesOptions = {}): FeatureDe
       });
     }
 
-    // Boot-Check via ctx.templateResolver (extraContext-Pattern, symmetrisch
-    // zu requireConfigResolver in config). App-Bootstrap muss templateResolver
-    // wired haben — der Helper gibt einen klaren Wiring-Hinweis wenn nicht.
+    // Boot check via ctx.templateResolver (extraContext pattern, symmetrical
+    // with requireConfigResolver in config). App bootstrap must wire
+    // templateResolver; the helper gives a clear wiring hint if it is missing.
     //
-    // Body als named function extrahiert (`runLegalPagesBootCheck`) damit
-    // die Logik direkt unit-testbar ist statt nur indirekt über Routes.
-    // Pattern: thin job-shell ruft testable function — keine Test-Coupling
-    // zum JobRunner.
+    // The body is extracted as the named function (`runLegalPagesBootCheck`) so
+    // the logic can be unit-tested directly instead of only indirectly through
+    // routes. Pattern: a thin job shell calls a testable function, avoiding
+    // coupling tests to the JobRunner.
     r.job(
       "legal-pages-boot-check",
       {
         trigger: { manual: true },
         // bootGate, not runOnBoot: only an inline gate can actually abort the
         // boot. runOnBoot merely enqueues, so a missing imprint would fail a
-        // queue job while the pod goes ready anyway (fw#2590).
+        // queue job while the pod goes ready anyway.
         bootGate: true,
         runIn: "api",
       },

package/packages/bundled-features/src/legal-pages/markdown.ts

@@ -1,6 +1,6 @@
-// Re-export aus dem geteilten page-render-Kern (managed-pages nutzt
-// denselben gehärteten Renderer + Default-Layout). Namen bleiben stabil
-// für legal-pages' Public-API (index.ts exportiert renderMarkdownToHtml +
+// Re-export from the shared page-rendering core (managed pages use
+// the same hardened renderer and default layout). Keep these names stable
+// for legal-pages' public API (index.ts exports renderMarkdownToHtml and
 // wrapInLayout).
 
 export { wrapInLayout } from "../page-render/layout.ts";

package/packages/bundled-features/src/legal-pages/web/client-plugin.ts

@@ -1,26 +1,25 @@
-// Client-Feature-Factory für legal-pages Visual-Tree. Liefert statische
-// Tree-Knoten für die DACH-Compliance-Blöcke (imprint, privacy in de/en).
-// Jeder Knoten linkt auf text-content's edit-Action — reines Cross-Feature-
-// Linking, kein eigener State oder Fetch nötig.
+// Client feature factory for the legal-pages visual tree. Provides static
+// tree nodes for the DACH compliance blocks (imprint, privacy in de/en).
+// Each node links to text-content's edit action — pure cross-feature
+// linking, with no own state or fetch required.
 //
-// **Static statt fetch**: legal-pages weiß out-of-the-box welche Blocks
-// existieren (LEGAL_REQUIRED_BLOCKS + LEGAL_OPTIONAL_BLOCKS aus constants).
-// Anders als text-content's Provider (der alle Slugs des Tenants holt)
-// ist diese Liste bekannt zur Build-Zeit — kein /api/query-Round-trip nötig.
+// **Static instead of fetch**: legal-pages knows out of the box which blocks
+// exist (LEGAL_REQUIRED_BLOCKS + LEGAL_OPTIONAL_BLOCKS from constants).
+// Unlike text-content's provider (which fetches all tenant slugs), this list
+// is known at build time — no /api/query round trip is needed.
 //
-// **Content-State unbekannt**: V.1.2 setzt keine state-Markierung; alle
-// Knoten erscheinen "filled" (default). V.1.3+ könnte via by-slug-Query
-// ermitteln ob ein Block tatsächlich body hat und „stub" markieren wenn
-// leer (Provider-Author-Hinweis dass Block existiert aber befüllt werden
-// muss). Aktuell ist legal-pages's Boot-Check der primäre Wächter für
-// fehlende Pflicht-Blocks.
+// **Content state unknown**: no state marker is set; all nodes appear
+// "filled" (default). A by-slug query could determine whether a block
+// actually has a body and mark it as "stub" when empty (a provider-author hint
+// that the block exists but must be filled). Currently, legal-pages's boot
+// check is the primary guard for missing required blocks.
 
 import type { TreeChildrenSubscribe, TreeNode } from "@cosmicdrift/kumiko-framework/engine";
 import type { ClientFeatureDefinition } from "@cosmicdrift/kumiko-renderer/web";
 import { LEGAL_OPTIONAL_BLOCKS, LEGAL_REQUIRED_BLOCKS } from "./constants.ts";
 
 const treeProvider: TreeChildrenSubscribe = () => (emit) => {
-  // V.1.5d Slug-first Verschachtelung (Variante C):
+  // Slug-first nesting:
   //   📁 Legal
   //     📁 imprint
   //       de
@@ -29,10 +28,10 @@ const treeProvider: TreeChildrenSubscribe = () => (emit) => {
   //       de
   //       en
   //
-  // Slug ist der Übersetzungs-Anker — User pflegt DE+EN-Versionen
-  // desselben Inhalts zusammen statt nach Sprache zu gruppieren.
-  // Sub-Items sind reine Sprach-Leaves; Label = Sprache, target zeigt
-  // auf template-resolver:edit mit slug+locale.
+  // The slug is the translation anchor — users maintain the DE+EN versions
+  // of the same content together instead of grouping them by language.
+  // Sub-items are language-only leaves; label = language, and target points
+  // to template-resolver:edit with slug+locale.
 
   // Group all blocks by slug, collect set of langs per slug.
   const bySlug = new Map<string, string[]>();
@@ -62,15 +61,15 @@ const treeProvider: TreeChildrenSubscribe = () => (emit) => {
     });
   }
 
-  // Der App-seitige r.nav-Knoten IST der "Legal"-Container → der Provider
-  // emittiert die slug-Folder direkt darunter.
+  // The app-side r.nav node IS the "Legal" container → the provider
+  // emits the slug folders directly beneath it.
   emit(slugFolders);
   return () => {};
 };
 
-// `navId` = QN des r.nav({ provider: true })-Knotens den die App registriert.
-// Statisch (kein Fetch, keine Entities) → kein SSE-Refresh nötig. Ohne navId:
-// kein Sidebar-Knoten (server-only-Consumer leaken nichts).
+// `navId` = the QN of the r.nav({ provider: true }) node registered by the app.
+// Static (no fetch, no entities) → no SSE refresh is needed. Without navId:
+// no sidebar node (server-only consumers expose nothing).
 export function legalPagesClient(opts?: { readonly navId?: string }): ClientFeatureDefinition {
   const navId = opts?.navId;
   return {

package/packages/bundled-features/src/legal-pages/web/index.ts

@@ -1,3 +1 @@
-// Public exports für die Browser-Seite des legal-pages Features.
-
 export { legalPagesClient } from "./client-plugin.ts";

package/packages/bundled-features/src/mail-foundation/feature.ts

@@ -2,34 +2,33 @@
 //
 // mail-foundation as a Kumiko bundled feature.
 //
-// **Was diese Feature liefert:**
-//   1. **Plugin-API** für Mail-Transport-Provider via `r.extendsRegistrar
-//      ("mailTransport", ...)`. Provider-Features (mail-transport-smtp,
-//      mail-transport-brevo-api, ...) registrieren sich namentlich.
-//   2. **Tenant-Config-key** `provider`: select-Wert der zur Runtime
-//      bestimmt welcher registrierte Plugin verwendet wird.
-//   3. **createTransportForTenant(ctx, tenantId)** Factory die den
-//      gewählten Plugin im Registry sucht und seine `build`-Methode
-//      aufruft.
+// **What this feature provides:**
+//   1. **Plugin API** for mail transport providers via `r.extendsRegistrar
+//      ("mailTransport", ...)`. Provider features (mail-transport-smtp,
+//      mail-transport-brevo-api, ...) register by name.
+//   2. **Tenant config key** `provider`: a selection value that determines at
+//      runtime which registered plugin is used.
+//   3. **createTransportForTenant(ctx, tenantId)** factory that looks up the
+//      selected plugin in the registry and calls its `build` method.
 //
-// **Was diese Foundation NICHT mehr macht (im Vergleich zur ersten
-// Iteration):**
-//   - Keine SMTP/Brevo/Postmark-spezifischen Config-Keys mehr in
-//     mail-foundation. Provider-spezifische Config (host/port/from/
-//     authUser für SMTP, apiUrl/accountId für Brevo etc.) lebt im
-//     jeweiligen Provider-Plugin-Feature.
-//   - Kein direkter Import von `createSmtpTransport`. Die Foundation
-//     kennt nur das `EmailTransport`-Interface (Type-Import, kein
-//     runtime-coupling), nicht die konkrete Implementation.
+// **What this foundation no longer does (compared with the first
+// iteration):**
+//   - No SMTP/Brevo/Postmark-specific config keys in mail-foundation.
+//     Provider-specific config (host/port/from/authUser for SMTP,
+//     apiUrl/accountId for Brevo, etc.) lives in the respective provider
+//     plugin feature.
+//   - No direct import of `createSmtpTransport`. The foundation knows only
+//     the `EmailTransport` interface (type import, no runtime coupling), not
+//     the concrete implementation.
 //
-// **Pattern-Vorbild:** identisch zu `delivery` + `channel-email`. Die
-// delivery-feature deklariert `r.extendsRegistrar("deliveryChannel")`,
-// channel-email registriert sich via `r.useExtension("deliveryChannel",
-// "email", {...})`. Selbe Trennung Foundation ↔ Provider.
+// **Pattern precedent:** identical to `delivery` + `channel-email`. The
+// delivery feature declares `r.extendsRegistrar("deliveryChannel")`, and
+// channel-email registers via `r.useExtension("deliveryChannel",
+// "email", {...})`. The foundation ↔ provider separation is the same.
 //
-// **Standalone:** Foundation ist ohne tier-engine nutzbar. Existing
-// `channel-email` (App-wide-Mail-Sender via delivery) bleibt unangetastet
-// — additive Feature.
+// **Standalone:** The foundation can be used without tier-engine. Existing
+// `channel-email` (app-wide mail sender via delivery) remains unchanged—an
+// additive feature.
 
 import {
   type EmailTransport,
@@ -97,8 +96,8 @@ export type MailTransportContext = {
  * an EmailTransport. Per-call construction so a tenant editing config
  * sees the change on the next mail.
  *
- * **Plugin-Author-Warnung:** `ctx` ist EXPLIZIT ein MailTransportContext,
- * nicht ein voller HandlerContext (siehe MailTransportContext-Doc).
+ * **Plugin-author warning:** `ctx` is EXPLICITLY a MailTransportContext,
+ * not a full HandlerContext (see the MailTransportContext doc).
  */
 export type MailTransportPlugin = {
   readonly build: (ctx: MailTransportContext, tenantId: string) => Promise<EmailTransport>;

package/packages/bundled-features/src/mail-transport-inmemory/feature.ts

@@ -1,25 +1,25 @@
 // kumiko-feature-version: 1
 //
-// mail-transport-inmemory — In-Memory-EmailTransport für die mail-
-// foundation Plugin-API. Sammelt Mails in einem per-Tenant-Buffer
-// statt sie über einen echten SMTP-Server zu senden. Designed für
-// Demos, Sample-Apps und Tests die ohne Mailpit/Mailcrab/echten SMTP
-// laufen sollen.
+// mail-transport-inmemory — In-memory email transport for the mail-
+// foundation plugin API. Collects emails in a per-tenant buffer
+// instead of sending them through a real SMTP server. Designed for
+// demos, sample apps, and tests that should run without Mailpit,
+// Mailcrab, or real SMTP.
 //
-// **Was diese Feature liefert:**
-//   1. Plugin-Registration via `r.useExtension("mailTransport",
-//      "inmemory", { build })`. Tenants setzen
-//      "mail-foundation:config:provider" auf "inmemory" und kriegen
-//      die buffered-Variante.
-//   2. **Pro-Tenant Inbox.** Jeder Tenant hat einen eigenen
-//      Mail-Buffer (Map<tenantId, EmailMessage[]>). Demo-Apps können
-//      die Inbox via `getInbox(tenantId)` lesen + UI rendern.
+// **What this feature provides:**
+//   1. Plugin registration via `r.useExtension("mailTransport",
+//      "inmemory", { build })`. Tenants set
+//      "mail-foundation:config:provider" to "inmemory" and receive
+//      the buffered variant.
+//   2. **Per-tenant inbox.** Each tenant has its own mail buffer
+//      (Map<tenantId, EmailMessage[]>). Demo apps can read the inbox
+//      via `getInbox(tenantId)` and render a UI.
 //
-// **Pattern-Vorbild:** mirrors mail-transport-smtp.
+// **Pattern reference:** mirrors mail-transport-smtp.
 //
-// **NICHT für Production.** Buffer ist im Process-Memory, geht beim
-// Restart verloren. Cap-Counter / Audit-Trail bleiben trotzdem korrekt
-// — die hängen am event-store, nicht am Transport.
+// **NOT for production.** The buffer is in process memory and is lost
+// on restart. Cap counters and the audit trail remain correct because
+// they are tied to the event store, not the transport.
 
 import type {
   EmailMessage,
@@ -39,9 +39,9 @@ const FEATURE_NAME = "mail-transport-inmemory";
 // Per-tenant in-memory buffer
 // =============================================================================
 //
-// Module-level Map weil der Plugin-build-call pro Send einen neuen
-// Transport-Wrapper baut, aber wir wollen dass alle Wrapper für
-// denselben Tenant auf denselben Buffer zeigen. Map<tenantId,
+// The module-level Map is needed because the plugin build call creates
+// a new transport wrapper for each send, while all wrappers for the
+// same tenant must point to the same buffer. Map<tenantId,
 // InMemoryTransport>.
 
 const transportsByTenant = new Map<string, ReturnType<typeof createInMemoryTransport>>();
@@ -56,16 +56,16 @@ function getOrCreateTransportForTenant(tenantId: string) {
 }
 
 /**
- * Demo/Test-Helper: lies die "versendeten" Mails eines Tenants. Im
- * Sample-App rendert ein query-Handler darauf die Inbox-UI.
+ * Demo/test helper: reads the emails "sent" for a tenant. A query
+ * handler in the sample app uses this to render the inbox UI.
  */
 export function getInbox(tenantId: string): readonly EmailMessage[] {
   return transportsByTenant.get(tenantId)?.sent ?? [];
 }
 
 /**
- * Demo/Test-Helper: clear einen Tenant-Buffer (z.B. zwischen Test-
- * Szenarien).
+ * Demo/test helper: clears a tenant's buffer, for example between
+ * test scenarios.
  */
 export function clearInbox(tenantId: string): void {
   const t = transportsByTenant.get(tenantId);
@@ -82,10 +82,9 @@ export function createMailTransportInMemoryFeature() {
       r.describe(
         'Registers an in-process `"inmemory"` provider for `mail-foundation` that buffers sent mails per tenant instead of contacting an SMTP server. Use `getInbox(tenantId)` and `clearInbox(tenantId)` in demo apps and tests; not for production (buffer is process-memory, lost on restart).',
       );
-      // Kein requires auf "config" oder "secrets" — der
-      // In-Memory-Transport hat keine Config (nichts zu konfigurieren) und
-      // kein Secret. Der einzige hard-require ist mail-foundation, das den
-      // extension-point "mailTransport" definiert.
+      // No `config` or `secrets` requirement: the in-memory transport has
+      // no configuration and no secret. The only hard requirement is
+      // mail-foundation, which defines the "mailTransport" extension point.
       r.requires({ features: ["mail-foundation"] });
 
       const plugin: MailTransportPlugin = {

package/packages/bundled-features/src/mail-transport-smtp/feature.ts

@@ -1,29 +1,29 @@
 // kumiko-feature-version: 1
 //
-// mail-transport-smtp — concrete SMTP-implementation for the
-// mail-foundation plugin-API.
+// mail-transport-smtp — concrete SMTP implementation for the
+// mail-foundation plugin API.
 //
-// **Was diese Feature liefert:**
-//   1. Provider-spezifische Tenant-Config (host/port/secure/from/authUser)
-//      und Secret (smtp.password). Self-contained — mail-foundation kennt
-//      diese Schlüssel nicht; wenn ein App-Owner zwischen SMTP und Brevo-
-//      API wechseln will, hat er pro-Plugin eigenständige Config-Sets.
-//   2. **Plugin-Registration** via `r.useExtension("mailTransport",
-//      "smtp", { build })`. Beim Boot kennt mail-foundation's
-//      Factory-Lookup damit den name "smtp" ↔ build-Funktion.
-//   3. `build(ctx, tenantId)` liest die config-keys + secret und ruft
-//      `createSmtpTransport()` aus channel-email auf. Das ist der
-//      EINZIGE Cross-Feature-Import dieses Plugins — bewusst lokal
-//      gehalten, mail-foundation bleibt provider-frei.
+// **What this feature provides:**
+//   1. Provider-specific tenant config (host/port/secure/from/authUser)
+//      and secret (smtp.password). Self-contained — mail-foundation does not
+//      know these keys; when an app owner switches between SMTP and the Brevo
+//      API, each plugin has its own independent config sets.
+//   2. **Plugin registration** via `r.useExtension("mailTransport",
+//      "smtp", { build })`. At boot, mail-foundation's factory lookup maps
+//      the name "smtp" to the build function.
+//   3. `build(ctx, tenantId)` reads the config keys and secret, then calls
+//      `createSmtpTransport()` from channel-email. This is the plugin's
+//      ONLY cross-feature import, deliberately kept local so
+//      mail-foundation remains provider-independent.
 //
-// **Pattern-Vorbild:** mirrors `channel-email` registering itself for
-// `delivery`. Diese Feature ist analog: registriert sich für
-// mail-foundation's "mailTransport"-Extension-Point.
+// **Pattern reference:** mirrors `channel-email` registering itself for
+// `delivery`. This feature is analogous: it registers for
+// mail-foundation's "mailTransport" extension point.
 //
-// **Boot-Dependencies:**
+// **Boot dependencies:**
 //   - `mail-foundation` — extension-point owner
-//   - `config` — für die Tenant-Config-Keys
-//   - `secrets` — für das verschlüsselte SMTP-Password
+//   - `config` — for the tenant config keys
+//   - `secrets` — for the encrypted SMTP password
 
 import type { lookup } from "node:dns/promises";
 import {

package/packages/bundled-features/src/managed-pages/branding.ts

@@ -20,13 +20,13 @@ import { type BrandingTokens, EMPTY_BRANDING } from "../page-render/index.ts";
 // `write: access.withSystem(access.admin)` — tenant admins self-service via
 // configEdit AND the system actor (ctx.systemWriteAs) may provision/migrate
 // these keys. The scope default (`access.admin`, admin-only) has no system
-// path, so a continuity migration could not set them (issue #396). Adding
-// SYSTEM_ROLE keeps the keys human-writable (checkWriteAccess collapses to
+// path, so a continuity migration could not set them. Adding SYSTEM_ROLE
+// keeps the keys human-writable (checkWriteAccess collapses to
 // system-only only when system is the SOLE writer), so self-service survives.
 //
-// CONTINUITY (Phase 5 — Prod trap): these keys land under
+// CONTINUITY (Prod trap): these keys land under
 // `managed-pages:config:branding-*`, NOT the live `publicstatus:config:
-// branding-*`. The publicstatus consumer (Phase 5) MUST migrate the existing
+// branding-*`. The publicstatus consumer MUST migrate the existing
 // read_config_values rows to the new QNs per tenant BEFORE switching the read
 // path, or every tenant resets to defaults on deploy. The migration is
 // deliberately NOT built here — the source QNs belong to the consumer app.
@@ -37,7 +37,7 @@ import { type BrandingTokens, EMPTY_BRANDING } from "../page-render/index.ts";
 // also renders. text keys carry an explicit length cap too — `validateType`
 // only checks the JS type, and the configEdit `maxLength` is client-side, so a
 // direct config:write:set would otherwise be unbounded (the page body is
-// likewise capped in Phase 2).
+// likewise capped).
 const HEX_PATTERN = {
   regex: "^$|^#(?:[0-9a-fA-F]{3}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})$",
 } as const;
@@ -67,7 +67,7 @@ export const MANAGED_PAGES_CSS_FEATURE = "managed-pages-css";
 // site-url`. BRANDING_QN below is the single source those QN strings are read
 // from (configEdit screen + render read); the integration test pins write-
 // target == read-source end-to-end.
-// Admin self-service + system provisioning (see write-access note above, #396).
+// Admin self-service + system provisioning.
 const BRANDING_WRITE = access.withSystem(access.admin);
 
 export const BRANDING_KEYS = {