@cosmicdrift/kumiko-bundled-features 0.385.0 → 0.387.0

package/dist/jobs/job-run-logger.js

@@ -26,7 +26,7 @@ const DEFAULT_CACHE_MAX_ENTRIES = 10_000;
 const DEFAULT_CACHE_TTL_MS = 60 * 60 * 1000; // 1 hour
 // Run rows hang on SYSTEM_TENANT_ID and a null trigger is a cron/system run;
 // job-run-table.ts declares whenAbsent: "tenant" for exactly that case, so the
-// logger must resolve the same subject the entity chain would (fw#3654).
+// logger must resolve the same subject the entity chain would.
 function jobRunSubject(triggeredById) {
     return triggeredById === null
         ? { kind: "tenant", tenantId: SYSTEM_TENANT_ID }
@@ -51,12 +51,12 @@ async function encryptOrSentinel(kms, subject, value, field) {
     }
 }
 // Same per-subject encryption as encryptStartedPayload, applied to each
-// batched log line's `message` (#2247) before insertMany into
+// batched log line's `message` before insertMany into
 // jobRunLogsTable — that table is unmanaged/direct-write, so there is no
 // event-piiFields catalog to lean on here either. "message" is the AAD
 // field name and must match the field passed to decryptStoredPii on read
 // (detail.query.ts) or decrypt fails loud. Same skip rule as the payload:
-// absent KMS (rollout mode) stays plaintext. Bounded concurrency (#2307) —
+// absent KMS (rollout mode) stays plaintext. Bounded concurrency —
 // unbounded Promise.all would fire one getOrCreateDek per log line at once
 // against the KMS adapter's pool.
 async function encryptLogMessages(logs, triggeredById) {
@@ -69,7 +69,7 @@ async function encryptLogMessages(logs, triggeredById) {
         message: await encryptOrSentinel(kms, subject, log.message, "message"),
     }));
 }
-// Mirrors encryptFailureError for the failure-path `error` column (#2307):
+// Mirrors encryptFailureError for the failure-path `error` column:
 // stored alongside logs[].message under the same triggering user's DEK, so
 // a log/error pair from the same failed run decrypt together or erase
 // together. Exported so stale-run-sweep.ts's crash-recovery write (a
@@ -82,12 +82,12 @@ export async function encryptFailureError(error, triggeredById) {
     return encryptOrSentinel(kms, jobRunSubject(triggeredById), error, "error");
 }
 // The run-started payload can carry arbitrary user data; triggeredById
-// names its owning user. No event-PII catalog involved (#2243 removed the
-// jobRun r.defineEvent registrations, so there is nothing to catalog) —
-// the subject is known statically, so we encrypt directly. A null subject
+// names its owning user. No event-PII catalog involved (the
+// jobRun r.defineEvent registrations were removed, so there is nothing to
+// catalog) — the subject is known statically, so we encrypt directly. A null subject
 // (system cron runs, recipient-less triggers) encrypts under the system
 // tenant key. Absent KMS adapter stays plaintext (rollout mode, unchanged).
-// A key already erased by the time the trigger lands (#2307) must not fail
+// A key already erased by the time the trigger lands must not fail
 // the whole run-start write — sentinel like the log/error paths.
 async function encryptStartedPayload(payload, triggeredById) {
     if (payload === null)
@@ -103,13 +103,12 @@ const TENANT_JOB_FAILURE_LOCK_NAMESPACE = 0x746a666c;
 // 'tjrl': serialises the finished-row write + prune per tenant run key.
 const TENANT_JOB_RUN_LOCK_NAMESPACE = 0x746a726c;
 const TENANT_RUN_CONFLICT_KEYS = ["tenantId", "jobName", "bullJobId"];
-// fw#3079 — which row the tenant-visible failure record lives in: one per
+// Which row the tenant-visible failure record lives in: one per
 // (tenant, job, subject), so the next outcome of the same work replaces or
 // clears it. `subject` is null for a job that declares no subjectFields.
 // Null target = nothing to write or clear: the job did not opt in, the run
 // was tenant-less (cron resolves to SYSTEM_TENANT_ID, where no tenant-scoped
-// query could ever read the row), or the caller predates fw#3079 and passes
-// no outcome at all.
+// query could ever read the row), or the caller passes no outcome at all.
 function tenantJobFailureTarget(jobName, outcome) {
     if (!outcome?.tenantVisible || outcome.tenantId === SYSTEM_TENANT_ID)
         return null;

package/dist/jobs/job-run-table.js

@@ -1,9 +1,9 @@
 import { defineUnmanagedTable, deriveEntityTableMeta, instant, table as pgTable, serial, text, } from "@cosmicdrift/kumiko-framework/db";
 import { createEntity, createNumberField, createTextField, createTimestampField, } from "@cosmicdrift/kumiko-framework/engine";
-// jobRun is a system-scoped direct-write store (#2243): every job execution
+// jobRun is a system-scoped direct-write store: every job execution
 // writes straight into jobRunsTable / jobRunLogsTable from the BullMQ
 // callbacks (onJobStart / -Complete / -Failed, see job-run-logger.ts) —
-// no event-store detour. Pre-#2243 this was an events-only aggregate
+// no event-store detour. Previously this was an events-only aggregate
 // replayed through two inline projections; that generated two permanent
 // `kumiko_events` rows per run for data that is itself already the
 // system of record (no other consumer replays or MSP-subscribes to it).
@@ -20,7 +20,7 @@ import { createEntity, createNumberField, createTextField, createTimestampField,
 // app boundary (same pattern as template-resolver kind/scope).
 // `table: "store_job_runs"` (not `read_*`) because this is no longer a
 // rebuildable projection — `defineUnmanagedTable`/`deriveEntityTableMeta`
-// reject the `read_` prefix for `source: "unmanaged"` (#1208/#1220).
+// reject the `read_` prefix for `source: "unmanaged"`.
 export const jobRunEntity = createEntity({
     table: "store_job_runs",
     fields: {

package/dist/jobs/screens.js

@@ -92,7 +92,7 @@ export const jobRunDetailScreen = {
                     "error",
                 ],
             },
-            // No section `title` here (fw#2312 label-dedup fix): the section
+            // No section `title` here (label-dedup fix): the section
             // holds exactly one field, so a title would repeat the field's own
             // label (rendered by RenderField as the Field's heading) verbatim.
             {

package/dist/jobs/tenant-job-failure-table.js

@@ -1,5 +1,5 @@
 import { index, instant, table as pgTable, requireEntityTableMeta, serial, sql, text, uniqueIndex, uuid, } from "@cosmicdrift/kumiko-framework/db";
-// The tenant's own view of a failed job (fw#3079). Direct-write store like
+// The tenant's own view of a failed job. Direct-write store like
 // store_job_runs: job-run-logger.ts writes it from the BullMQ callbacks,
 // outside any dispatcher transaction.
 //

package/dist/jobs/tenant-job-run-table.js

@@ -1,5 +1,5 @@
 import { index, instant, table as pgTable, requireEntityTableMeta, serial, sql, text, uniqueIndex, uuid, } from "@cosmicdrift/kumiko-framework/db";
-// The tenant's own view of a job's run state (fw#3616). Direct-write store
+// The tenant's own view of a job's run state. Direct-write store
 // like store_job_runs, written by job-run-logger.ts from the runner callbacks.
 //
 // store_job_runs cannot serve the tenant: it anchors every run on the system

package/dist/ledger/entity.js

@@ -5,7 +5,7 @@ import { ACCOUNT_TYPES, SCHEDULE_INTERVALS, TRANSACTION_STATUS } from "./web/con
 // detail via the standard handlers); the framework projects `read_ledger_accounts`
 // from its CRUD events. `parentId` null → root account; otherwise the chart-of-
 // accounts tree. `type` drives how the report layer interprets a balance. No
-// money column — balances are DERIVED from postings (Phase 1), never stored.
+// money column — balances are DERIVED from postings, never stored.
 // tenantId is a base column set by the framework → each tenant has its own books.
 export const accountEntity = createEntity({
     table: "read_ledger_accounts",
@@ -39,13 +39,13 @@ export const accountEntity = createEntity({
 // transaction — a journal entry. The balanced posting lines live embedded as
 // `lines` (embedded list: { accountId, amount }[], Σ amount = 0), so an entry is atomic:
 // the Σ=0 invariant holds within a single command, no cross-row write. The
-// framework projects `read_ledger_transactions`; Phase 1 adds a flat
-// `read_ledger_postings` projection (one row per line) for per-account/period
+// framework projects `read_ledger_transactions`; a flat
+// `read_ledger_postings` projection (one row per line) supports per-account/period
 // report queries.
 //
 // IMMUTABLE: the feature registers NO update/delete handler for transaction. A
-// posted entry is a fact; corrections are reverse-transaction (Storno) entries.
-// `status` carries draft|posted for the later Soll/Ist work — Phase 0 posts only.
+// posted entry is a fact; corrections are reverse-transaction entries.
+// `status` carries draft|posted.
 export const transactionEntity = createEntity({
     table: "read_ledger_transactions",
     description: "One journal entry: a booking date, a narration, an optional reference (a reversal points at the entry it corrects), a draft/posted status and the embedded posting lines of accountId plus signed minor-unit amount that must sum to zero; posted entries are immutable and corrected only by a reversing entry.",

package/dist/ledger/feature.js

@@ -7,8 +7,8 @@
 //      corrections are reverse-transaction (Storno) entries.
 //
 // Everything financial — banking, accounting, rent cashflow, credits, invoices —
-// is accounts + balanced transactions on top. Balances and reports (Bilanz, GuV,
-// Cashflow) are pure queries over the postings (Phase 1), never stored state.
+// is accounts + balanced transactions on top. Balances and reports (balance
+// sheet, P&L, cashflow) are pure queries over the postings, never stored state.
 //
 // Spec: kumiko-platform/docs/plans/ledger-feature.md
 import { defineEntityCreateHandler, defineEntityDetailHandler, defineEntityListHandler, defineEntityUpdateHandler, defineFeature, } from "@cosmicdrift/kumiko-framework/engine";
@@ -33,7 +33,7 @@ function registerLedger(r, access, toggleable) {
     r.entity({ name: "schedule", ...scheduleEntity });
     // Chart of accounts — plain CRUD, no custom logic. No delete in v1: removing an
     // account that has postings would orphan them; a posting-aware guard lands with
-    // the postings projection (Phase 1).
+    // the postings projection.
     r.writeHandler(defineEntityCreateHandler("account", accountEntity, {
         access,
         description: "Adds an account to the tenant's chart of accounts with a name, a type of asset, liability, equity, income or expense, an optional code and an optional parent account; use it before booking anything against that account.",

package/dist/ledger/handlers/confirm-schedule-period.write.js

@@ -12,11 +12,11 @@ const CONFIRM_PERIOD_LOCK_NAMESPACE = 0x6c637370;
 // balanced transaction (debit +amount / credit −amount), tagged with
 // scheduleReference(scheduleId, period) so the host can merge Soll vs. Ist.
 //
-// Idempotent + reversal-aware: if an ACTIVE (non-reversed) booking for this
+// Idempotent and reversal-aware: if an ACTIVE (non-reversed) booking for this
 // reference already exists, it's a no-op; a booking that was reversed (Storno)
 // leaves the period re-confirmable. Referential integrity (both accounts must
-// exist) mirrors create-transaction — a schedule could name a bogus account, the
-// generic CRUD create doesn't check.
+// exist) mirrors create-transaction because a schedule could name a bogus
+// account that the generic CRUD create does not check.
 export function createConfirmSchedulePeriodHandler(access = DEFAULT_LEDGER_ACCESS) {
     return {
         name: "confirm-schedule-period",

package/dist/ledger/recurring.js

@@ -1,17 +1,17 @@
 // Recurring schedules on top of the ledger primitive. A `schedule` is a standing
-// booking template ("Miete ab 1.1.2026, 500 €/Monat") from which two things fall
-// out WITHOUT booking every month up front:
+// booking template ("Rent from 1/1/2026, €500/month") used without booking every
+// month up front:
 //
-//   • projectSchedule()      — the Soll (forecast): pure projection over a window,
-//                              no transactions needed (chart, "trägt sich das?").
-//   • mergeScheduleActuals() — Soll vs. Ist: the projection left-joined against
-//                              the posted confirmations (per `reference`), so each
-//                              month is posted | open | forecast.
+//   • projectSchedule()      — the forecast: a pure projection over a window with
+//                              no transactions required (chart, "does it pay for itself?").
+//   • mergeScheduleActuals() — forecast vs. actual: the projection left-joined
+//                              against posted confirmations (by `reference`), so
+//                              each month is posted | open | forecast.
 //
-// confirm-schedule-period (handler) turns one projected month into ONE balanced
+// The confirm-schedule-period handler turns one projected month into one balanced
 // transaction tagged with `scheduleReference(id, period)`. Both functions here are
-// pure — no DB, no Date API (windows/asOf come in as params) — so the no-date-api
-// guard stays green and the forecast is deterministic.
+// pure—no DB or Date API (windows/asOf are supplied as parameters)—so the forecast
+// remains deterministic and the no-date-api guard stays green.
 // "schedule:<id>:<period>" — the stable idempotency + merge key on a confirmation.
 export function scheduleReference(scheduleId, period) {
     return `schedule:${scheduleId}:${period}`;
@@ -54,8 +54,8 @@ export function projectSchedule(schedule, window) {
     }
     return periods;
 }
-// Soll vs. Ist. A month is `posted` when a confirmation for its reference exists
-// AND has not been reversed (Storno); a reversed confirmation drops the month back
+// Planned vs. actual. A month is `posted` when a confirmation for its reference exists
+// AND has not been reversed; a reversed confirmation drops the month back
 // to `open` so it can be re-confirmed. Past/current unbooked months are `open`,
 // future ones `forecast` (asOf is the boundary — month-granular).
 export function mergeScheduleActuals(scheduleId, projection, transactions, asOf) {

package/dist/ledger/schemas.js

@@ -17,7 +17,7 @@ export const createTransactionPayloadSchema = z
     description: z.string().min(1).max(200),
     reference: z.string().max(120).optional(),
     // Defaults to "posted" in the handler. draft lifecycle (editable) lands with
-    // the Soll/recurring work — Phase 0 only ever creates posted entries.
+    // the debit/recurring work — only ever creates posted entries.
     status: z.enum(TRANSACTION_STATUS).optional(),
     lines: z.array(postingSchema).min(2),
     // Business-object reference (e.g. a lease contract) this entry is about.

package/dist/ledger/web/constants.js

@@ -25,14 +25,14 @@ export const LedgerQueries = {
     transactionDetail: "ledger:query:transaction:detail",
     scheduleList: "ledger:query:schedule:list",
     scheduleDetail: "ledger:query:schedule:detail",
-    // Reports — pure aggregations over the posted entries (Phase 1).
+    // Reports — pure aggregations over the posted entries.
     reportBalances: "ledger:query:report:balances",
     reportIncomeStatement: "ledger:query:report:income-statement",
     reportBalanceSheet: "ledger:query:report:balance-sheet",
 };
 // Account types double-entry needs to interpret a balance: asset/expense are
 // debit-normal, liability/equity/income are credit-normal. The report layer
-// (Phase 1) flips signs by type; the primitive only stores them.
+// flips signs by type; the primitive only stores them.
 export const ACCOUNT_TYPES = ["asset", "liability", "equity", "income", "expense"];
 export const TRANSACTION_STATUS = ["draft", "posted"];
 // Recurrence steps a schedule can project. Monthly is the only step v1 needs

package/dist/ledger/web/index.js

@@ -1,10 +1,10 @@
-// Client-safe ledger surface: QN constants, the pure recurring helpers
-// (projection + Soll/Ist merge), and the Zod payload schemas (for client-side
-// pre-validation before dispatch) — nothing else. The full `../ledger` entry
-// re-exports the feature/handlers/executor, which pull postgres-js — a
-// browser bundle that imports from there fails on Node builtins. A client screen
-// (e.g. a rent-cashflow view) imports the dispatch QNs + the pure forecast/merge
-// from HERE, then dispatches via the renderer's useDispatcher.
+// Client-safe ledger surface: QN constants, pure recurring helpers
+// (projection + Soll/Ist merge), and Zod payload schemas for client-side
+// pre-validation before dispatch. The full `../ledger` entry also re-exports
+// the feature/handlers/executor, which pull postgres-js; importing it in a
+// browser bundle fails on Node builtins. Client screens import dispatch QNs and
+// pure forecast/merge helpers from this module, then dispatch via the renderer's
+// useDispatcher.
 export { mergeScheduleActuals, projectSchedule, scheduleReference, } from "../recurring.js";
 export { confirmSchedulePeriodPayloadSchema, postingSchema, } from "../schemas.js";
 export { ACCOUNT_TYPES, LEDGER_FEATURE_NAME, LedgerHandlers, LedgerQueries, SCHEDULE_INTERVALS, TRANSACTION_STATUS, } from "./constants.js";

package/dist/legal-pages/feature.d.ts

@@ -4,10 +4,10 @@ import { type LegalPageRoute, type LegalRequiredBlock } from "./web/constants.ts
 export { type LegalPagesBootCheckCtx, runLegalPagesBootCheck } from "./lib/boot-check.ts";
 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

package/dist/legal-pages/feature.js

@@ -7,13 +7,12 @@ import { validateRoutes } from "./lib/validate-routes.js";
 import { renderMarkdownToHtml, wrapInLayout } from "./markdown.js";
 import { LEGAL_REQUIRED_BLOCKS, LEGAL_ROUTES, LEGAL_TERMS_ROUTES, } from "./web/constants.js";
 export { runLegalPagesBootCheck } from "./lib/boot-check.js";
-// 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";
 // 60s-shared-cache saves the origin-revalidate roundtrip; legal-content edits are live within 60s.
 const PUBLIC_PAGE_CACHE = { kind: "revalidate", maxAgeSeconds: 60 };
@@ -57,18 +56,18 @@ export function createLegalPagesFeature(opts = {}) {
                 // 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;
                     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 }, SYSTEM_TENANT_ID));
                     }
                     catch (err) {
@@ -87,8 +86,8 @@ export function createLegalPagesFeature(opts = {}) {
                         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") {
                         return cachedSecurePageResponse(c.req.raw, {
@@ -132,19 +131,19 @@ export function createLegalPagesFeature(opts = {}) {
                 handler: (c) => redirectToCanonicalPath(c.req.url, route.path),
             });
         }
-        // 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",
         }, async (_payload, ctx) => runLegalPagesBootCheck(ctx, requiredBlocks));

package/dist/legal-pages/markdown.js

@@ -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.js";
 export { renderSafeMarkdown as renderMarkdownToHtml } from "../page-render/markdown.js";

package/dist/legal-pages/web/client-plugin.js

@@ -1,22 +1,21 @@
-// 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 { LEGAL_OPTIONAL_BLOCKS, LEGAL_REQUIRED_BLOCKS } from "./constants.js";
 const treeProvider = () => (emit) => {
-    // V.1.5d Slug-first Verschachtelung (Variante C):
+    // Slug-first nesting:
     //   📁 Legal
     //     📁 imprint
     //       de
@@ -25,10 +24,10 @@ const treeProvider = () => (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();
     for (const b of [...LEGAL_REQUIRED_BLOCKS, ...LEGAL_OPTIONAL_BLOCKS]) {
@@ -57,14 +56,14 @@ const treeProvider = () => (emit) => {
             children: langLeaves,
         });
     }
-    // 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) {
     const navId = opts?.navId;
     return {

package/dist/legal-pages/web/index.js

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

package/dist/mail-foundation/feature.d.ts

@@ -40,8 +40,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/dist/mail-foundation/feature.js

@@ -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 { withPiiCiphertextGuard, } from "@cosmicdrift/kumiko-bundled-features/channel-email";
 import { requireDefined } from "@cosmicdrift/kumiko-bundled-features/foundation-shared";
 import { access, createSystemUser, createTenantConfig, defineFeature, } from "@cosmicdrift/kumiko-framework/engine";

package/dist/mail-transport-inmemory/feature.d.ts

@@ -1,12 +1,12 @@
 import type { EmailMessage } from "@cosmicdrift/kumiko-bundled-features/channel-email";
 /**
- * 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 declare function getInbox(tenantId: string): readonly EmailMessage[];
 /**
- * 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 declare function clearInbox(tenantId: string): void;
 export declare function createMailTransportInMemoryFeature(): import("@cosmicdrift/kumiko-types/feature").FeatureDefinition & {