@cosmicdrift/kumiko-framework 0.386.0 → 0.387.0

package/dist/engine/boot-validator/ownership.js

@@ -3,23 +3,23 @@ import { tableNameOf, } from "../ownership.js";
 import { SYSTEM_USER_ID } from "../system-user.js";
 import { SYSTEM_TENANT_ID } from "../types/identifiers.js";
 import { assertQualifiedWhereFragment, tableColumnSqlNames } from "../where-rule-lint.js";
-// --- Ownership rule validation (H.2) ---
+// --- Ownership rule validation ---
 //
 // Walks every entity.access and every field.access map, resolves each
 // FromRule against the cross-feature claim registry, and confirms the
 // referenced column exists on the entity. Catches typos, renames, and
 // cross-feature-claim-removal scenarios at boot instead of at request time.
 //
-// fw#2639: also probes every `{ kind: "where" }` rule against the where-rule
+// Also probes every `{ kind: "where" }` rule against the where-rule
 // lint (see ../where-rule-lint.ts) so a fail-open unqualified-column bug
 // fails the boot instead of waiting for a request from the right role.
 //
 // Field-level `access.read` rejects where-rules too: filterFieldsForRead
 // evaluates it in memory and userCanReadFieldRow fails closed on a where-rule.
 //
-// fw#2626: `access.write` maps reject `{ kind: "where" }` outright. A
-// where-rule is raw SQL and the write path never reaches SQL — it evaluates
-// rules in memory against the concrete row (userCanCreateFieldRow /
+// `access.write` maps reject `{ kind: "where" }` outright. A where-rule is
+// raw SQL and the write path never reaches SQL — it evaluates rules in memory
+// against the concrete row (userCanCreateFieldRow /
 // userCanWriteFieldRow), and a create has no row to run a predicate against
 // at all. Such a rule can therefore only ever deny, so the boot fails instead
 // of shipping an access map that silently locks the role out.
@@ -49,9 +49,8 @@ export function collectClaimKeys(features) {
 // corpora go in as undefined — a three-feature stack genuinely does not know
 // which roles and claims the whole app declares, and answering that question
 // from a slice produces false "unknown role"/"unknown claim" errors. The
-// subset-invariant checks (#2639 where-lint, #2626 where-on-write, unknown
-// column) run in full: those hold or fail per feature, whatever else is
-// mounted.
+// subset-invariant checks (where-lint, where-on-write, unknown column) run in
+// full: those hold or fail per feature, whatever else is mounted.
 export function validateOwnershipBoot(features) {
     for (const feature of features) {
         validateOwnershipRules(feature, undefined, undefined);
@@ -258,12 +257,16 @@ export function probeWhereRule(rule, roleName, probe, scope, featureName) {
         return;
     assertQualifiedWhereFragment(fragment.sqlText, probe.columns, `${scope} (role "${roleName}", feature: "${featureName}")`);
 }
+// Array.isArray does not narrow a readonly array out of a union.
+function isRoleList(access) {
+    return Array.isArray(access);
+}
 // Embedded sub-fields are filtered in memory too (filterFieldsForRead), so a
 // where-rule there is just as unevaluable as on a top-level field.
 function rejectWhereInEmbeddedRead(schema, parentScope, featureName) {
     for (const [subName, sub] of Object.entries(schema)) {
         const map = sub.access?.read;
-        if (!map || Array.isArray(map))
+        if (!map || isRoleList(map))
             continue;
         for (const [roleName, rule] of Object.entries(map)) {
             if (rule !== "all" && rule.kind === "where") {

package/dist/engine/boot-validator/parent-ref.js

@@ -1,5 +1,5 @@
 import { ENTITY_CONVENTION_QUERY_BRAND } from "@cosmicdrift/kumiko-types/handlers";
-// --- Parent-ref boot validation (fw#2766) ---
+// --- Parent-ref boot validation ---
 //
 // Join-row entities (EntityDefinition.parentRef) derive both the write-path
 // deny and the read-path SQL gate from one declaration. This is the boot-time

package/dist/engine/boot-validator/pii-retention.js

@@ -1,16 +1,17 @@
+import { createFallbackLogger } from "../../logging/utils.js";
 import { PII_DIRECT_NAME_HINTS, PII_USER_OWNED_NAME_HINTS, PII_USER_REFERENCE_NAME_HINTS, } from "./entity-handler.js";
-// Framework-managed Timestamp-Spalten — dürfen als retention.reference
-// genutzt werden auch wenn nicht in entity.fields deklariert.
+const log = createFallbackLogger("kumiko:boot");
+// Framework-managed timestamp fields may be used as retention.reference
+// even when they are not declared in entity.fields.
 const FRAMEWORK_TIMESTAMP_FIELDS = new Set([
     "createdAt",
     "updatedAt",
     "lastSeenAt",
     "deletedAt",
 ]);
-// Erlaubtes Format fuer retention.keepFor — Zahlen + Suffix (h/d/w/m/y).
-// Echtes Parsen kommt mit dem Cleanup-Job in Sprint 2; Boot-Validator
-// macht nur den Sanity-Check damit Tippfehler ("30days") frueh sichtbar
-// werden statt erst beim ersten Cleanup-Run.
+// Allowed format for retention.keepFor: a number followed by a suffix (h/d/w/m/y).
+// The cleanup job performs the actual parsing; the boot validator only checks
+// the format so typos ("30days") become visible before the first cleanup run.
 const KEEP_FOR_PATTERN = /^\d+[hdwmy]$/;
 const FILE_FIELD_TYPES = new Set([
     "file",
@@ -19,7 +20,7 @@ const FILE_FIELD_TYPES = new Set([
     "images",
 ]);
 // Excludes subjectRef: its `personal: "ref"` union member structurally
-// forbids `anonymize` (packages/types/src/fields.ts) — #2336.
+// forbids `anonymize` (packages/types/src/fields.ts).
 function hasAnonymizableSubjectField(annot) {
     return Boolean(annot.pii || annot.userOwned || annot.tenantOwned || annot.recordOwned);
 }
@@ -100,28 +101,28 @@ function validatePersonalJsonbField(featureName, entityName, entity, fieldName,
 }
 // --- PII / Subject-Key Annotations + Retention validation ---
 //
-// Drei Klassen von Checks:
+// Four classes of checks:
 //
-// 1. Mutual exclusion: pro Field nur EINE der drei Subject-Annotations
-//    (pii / userOwned / tenantOwned). Mehr ist semantisch widersprüchlich
-//    weil pro Field genau ein Subject-Key gehört.
+// 1. Mutual exclusion: each field may have only ONE subject annotation
+//    (pii / userOwned / tenantOwned). Multiple annotations are semantically
+//    contradictory because each field belongs to exactly one subject key.
 //
-// 2. Reference-Integrity: userOwned.ownerField muss auf ein existierendes
-//    reference-Field zeigen (das auf user-Entity zeigen sollte). Erkennt
-//    Tippfehler und Drop-Refactorings beim Boot statt beim ersten
-//    Encrypt-Aufruf.
+// 2. Reference integrity: userOwned.ownerField must refer to an existing
+//    reference field that should target the user entity. This catches typos
+//    and refactors that removed a field during boot instead of at encryption.
 //
-// 3. Heuristik-Warnings: Field-Namen die typischerweise PII enthalten
-//    (email, name, phone, body, etc.) ohne Annotation → Boot-Warning.
-//    Mit `{ personal: false, reason: "<reason>" }` unterdrückbar (geht in Audit).
+// 3. Heuristic warnings: field names that typically contain PII
+//    (email, name, phone, body, etc.) without an annotation produce a boot
+//    warning. `{ personal: false, reason: "<reason>" }` suppresses it and
+//    records the reason in the audit.
 //
-// 4. Retention-Integrity: retention.reference (wenn gesetzt) muss auf
-//    ein bestehendes Field zeigen (oder Framework-Timestamp). retention.
-//    strategy="blockDelete" ohne anonymize-Felder ist sinnlos — User-
-//    Forget kann nichts machen, Warning.
+// 4. Retention integrity: retention.reference, when set, must refer to an
+//    existing field or a framework timestamp. retention.strategy="blockDelete"
+//    without anonymizable fields is ineffective because user forget cannot
+//    remove anything, so it produces a warning.
 //
-// Encrypt/Decrypt-Mechanik landet in Sprint 3 (crypto-shredding); diese
-// Validation greift schon ab Sprint 0 damit Schema-Drift früh auffällt.
+// Encryption and decryption are handled elsewhere; this validation runs early
+// so schema drift is detected during boot.
 export function validatePiiAndRetention(feature) {
     for (const [entityName, entity] of Object.entries(feature.entities ?? {})) {
         const fieldsByName = entity.fields;
@@ -150,9 +151,9 @@ export function validatePiiAndRetention(feature) {
                 !annot.subjectRef) {
                 throw new Error(`[Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" (type "${field.type}") declares no personal stance. Build it with createTextField / createLongTextField and { personal: "self" | "tenant" | "ref" | { of: "<ownerField>" } | false }; false additionally needs { reason: "..." } stating why the value is not personal data.`);
             }
-            // lookupable (#818): nur text + nur MIT Subject-Annotation. Ohne
-            // Subject bleibt der Wert eh Klartext — der Blind-Index wäre eine
-            // zweite (deterministische!) Kopie ohne Nutzen.
+            // lookupable: only text fields with a subject annotation are supported. Without
+            // a subject, the value remains plaintext, so a blind index would be a
+            // second deterministic copy without any benefit.
             if (annot.lookupable === true) {
                 if (field.type !== "text") {
                     throw new Error(`[Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" declares find: "exact" (or "fuzzy") but has type "${field.type}" — blind-index equality lookups only apply to text fields. Use a text field or set find: "none".`);
@@ -161,9 +162,9 @@ export function validatePiiAndRetention(feature) {
                     throw new Error(`[Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" declares find: "exact" (or "fuzzy") without a subject annotation (personal: "self" / "tenant" / { of: "<field>" }). Plaintext fields don't need a blind index — add personal or set find: "none".`);
                 }
             }
-            // sensitive-Felder liegen seit #967 als Tabellen-Ciphertext im Event-
-            // Log — ohne ciphertext-at-rest würde der Append Klartext in die
-            // immutable History schreiben.
+            // Sensitive fields are stored as table ciphertext in the event log; without
+            // ciphertext at rest, appending the event would write plaintext to the
+            // immutable history.
             const sensitiveFlags = field; // @cast-boundary schema-walk
             if (sensitiveFlags.sensitive === true &&
                 annotCount === 0 &&
@@ -172,11 +173,10 @@ export function validatePiiAndRetention(feature) {
             }
             validateWriteOnlyField(feature.name, entityName, fieldName, field);
             // Sorting reads the projection column — that stays ciphertext, so
-            // sortable + subject annotation stays a boot-fail. searchable has
-            // been allowed since #1610: the search consumer decrypts into the
-            // derived index and forget purges those docs (see
-            // createSearchEventConsumer). sensitive + searchable stays forbidden
-            // (never searchable).
+            // sortable + subject annotation stays a boot-fail. searchable is allowed:
+            // the search consumer decrypts into the derived index and forget purges
+            // those docs (see createSearchEventConsumer). sensitive + searchable stays
+            // forbidden (never searchable).
             {
                 const flags = field; // @cast-boundary schema-walk
                 if (annotCount > 0 && flags.sortable === true) {
@@ -214,42 +214,37 @@ export function validatePiiAndRetention(feature) {
                 if (ownerField.required !== true && whenAbsent === undefined) {
                     throw new Error(`[Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" is personal: { of: "${ownerName}" }, but "${ownerName}" is not required — rows without an owner would fail to encrypt (SubjectResolutionError, HTTP 500) on update, delete and forget. Declare { personal: { of: "${ownerName}", whenAbsent: "tenant" } } to encrypt those rows under the tenant key, whenAbsent: "self" to encrypt them under the row's own record key (shreddable per record), or make "${ownerName}" required: true. Entity fields have no plaintext fallback (fw#3654).`);
                 }
-                // Soft-Warning wenn das reference-target nicht offensichtlich user
-                // ist — custom subject-entities (HR-Mitarbeiter, Patient) sind
-                // erlaubt, müssen aber bewusste Wahl sein.
+                // Warn when the reference target is not obviously a user. Custom subject
+                // entities (such as HR employees or patients) are allowed but should
+                // be an intentional choice.
                 if (ownerField.type === "reference") {
                     const refTarget = ownerField.entity;
                     const targetEntity = refTarget.includes(":") ? refTarget.split(":")[1] : refTarget;
                     if (targetEntity !== "user") {
-                        // biome-ignore lint/suspicious/noConsole: boot-time dev hint, no logger available yet
-                        console.warn(`[kumiko:boot] [Feature ${feature.name}] personal.of "${ownerName}" on entity "${entityName}" targets reference "${refTarget}" — typically should be a user reference. If intentional (custom subject-entity like employee/patient), ignore.`);
+                        log.warn(`[Feature ${feature.name}] personal.of "${ownerName}" on entity "${entityName}" targets reference "${refTarget}" — typically should be a user reference. If intentional (custom subject-entity like employee/patient), ignore.`);
                     }
                 }
             }
-            // PII-Heuristik: nur wenn keine Annotation gesetzt UND kein
-            // allowPlaintext-Marker. Ergibt false positives auf Geschäftsdaten
-            // mit personenartigem Namen (z.B. company.legalName) — Author
-            // unterdrückt mit { personal: false, reason: "is_business_data" }.
+            // PII heuristic: only when no annotation or allowPlaintext marker is set.
+            // Business data with person-like names (for example, company.legalName)
+            // can produce false positives; authors can suppress them with
+            // { personal: false, reason: "is_business_data" }.
             const noAnnotation = annotCount === 0 && !annot.allowPlaintext;
             if (noAnnotation) {
                 const lower = fieldName.toLowerCase();
                 if (FILE_FIELD_TYPES.has(field.type)) {
-                    // biome-ignore lint/suspicious/noConsole: boot-time dev hint, no logger available yet
-                    console.warn(`[kumiko:boot] [Feature ${feature.name}] File field "${fieldName}" on entity "${entityName}" has no personal annotation. A forget with strategy "delete" then only severs the uploader link and keeps the binary. If the file holds personal data, mark it { personal: "self" } or { personal: { of: "<ownerField>" } }. If it is business data, set { personal: false, reason: "is_business_data" } to silence.`);
+                    log.warn(`[Feature ${feature.name}] File field "${fieldName}" on entity "${entityName}" has no personal annotation. A forget with strategy "delete" then only severs the uploader link and keeps the binary. If the file holds personal data, mark it { personal: "self" } or { personal: { of: "<ownerField>" } }. If it is business data, set { personal: false, reason: "is_business_data" } to silence.`);
                 }
                 else if (PII_DIRECT_NAME_HINTS.has(lower)) {
-                    // biome-ignore lint/suspicious/noConsole: boot-time dev hint, no logger available yet
-                    console.warn(`[kumiko:boot] [Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" has a PII-typical name but no personal annotation. If this is PII, mark it { personal: "self", find: ... }. If business data, set { personal: false, reason: "is_business_data" } to silence.`);
+                    log.warn(`[Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" has a PII-typical name but no personal annotation. If this is PII, mark it { personal: "self", find: ... }. If business data, set { personal: false, reason: "is_business_data" } to silence.`);
                 }
                 else if (PII_USER_OWNED_NAME_HINTS.has(lower)) {
-                    // biome-ignore lint/suspicious/noConsole: boot-time dev hint, no logger available yet
-                    console.warn(`[kumiko:boot] [Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" has a user-content-typical name but no personal annotation. If this contains user-generated content, mark it { personal: { of: "<authorIdField>" }, find: ... }. If business data, set { personal: false, reason: "..." } to silence.`);
+                    log.warn(`[Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" has a user-content-typical name but no personal annotation. If this contains user-generated content, mark it { personal: { of: "<authorIdField>" }, find: ... }. If business data, set { personal: false, reason: "..." } to silence.`);
                 }
                 else if (PII_USER_REFERENCE_NAME_HINTS.has(lower) &&
                     !annot.subjectRef &&
                     !personalOfOwnerFieldNames.has(fieldName)) {
-                    // biome-ignore lint/suspicious/noConsole: boot-time dev hint, no logger available yet
-                    console.warn(`[kumiko:boot] [Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" has a user-reference-typical name but no personal annotation — a foreign key into \`user\` carries Art.17 obligations even with no annotated content on the entity. Mark it { personal: "ref" } AND register r.useExtension(EXT_USER_DATA, "${entityName}", …) for Art.17 coverage — this warning is the only boot-time check for that, registering the hook is not enforced. Or { personal: { of: "${fieldName}" } } on the field it owns. If business data, set { personal: false, reason: "..." } to silence.`);
+                    log.warn(`[Feature ${feature.name}] Field "${fieldName}" on entity "${entityName}" has a user-reference-typical name but no personal annotation — a foreign key into \`user\` carries Art.17 obligations even with no annotated content on the entity. Mark it { personal: "ref" } AND register r.useExtension(EXT_USER_DATA, "${entityName}", …) for Art.17 coverage — this warning is the only boot-time check for that, registering the hook is not enforced. Or { personal: { of: "${fieldName}" } } on the field it owns. If business data, set { personal: false, reason: "..." } to silence.`);
                 }
             }
         }
@@ -257,8 +252,7 @@ export function validatePiiAndRetention(feature) {
         const retention = entity.retention;
         if (retention) {
             if (!KEEP_FOR_PATTERN.test(retention.keepFor)) {
-                // biome-ignore lint/suspicious/noConsole: boot-time dev hint, no logger available yet
-                console.warn(`[kumiko:boot] [Feature ${feature.name}] Entity "${entityName}" retention.keepFor="${retention.keepFor}" has an invalid format. Expected: <number><h|d|w|m|y> (e.g. "30d", "10y", "6m"). The cleanup job cannot parse anything else; fix keepFor.`);
+                log.warn(`[Feature ${feature.name}] Entity "${entityName}" retention.keepFor="${retention.keepFor}" has an invalid format. Expected: <number><h|d|w|m|y> (e.g. "30d", "10y", "6m"). The cleanup job cannot parse anything else; fix keepFor.`);
             }
             if (retention.reference !== undefined) {
                 const refName = retention.reference;
@@ -271,15 +265,14 @@ export function validatePiiAndRetention(feature) {
             if (retention.strategy === "blockDelete") {
                 // blockDelete with no field that can carry `anonymize` is fine;
                 // subjectRef-only entities are covered by the V3 EXT_USER_DATA guard
-                // instead (#1622, #2336).
+                // instead.
                 const entityHasAnonymizableField = entityHasAnonymizableSubjectField(fieldsByName);
                 const hasAnonymize = Object.values(fieldsByName).some((f) => {
                     const a = f; // @cast-boundary schema-walk
                     return Boolean(a.anonymize);
                 });
                 if (entityHasAnonymizableField && !hasAnonymize) {
-                    // biome-ignore lint/suspicious/noConsole: boot-time dev hint, no logger available yet
-                    console.warn(`[kumiko:boot] [Feature ${feature.name}] Entity "${entityName}" retention.strategy="blockDelete" but no field has an anonymize-function. Once keepFor expires, the data-retention cron anonymizes nothing and the row keeps its PII. Add { anonymize: () => null } or () => "[ANONYMIZED]" to PII fields.`);
+                    log.warn(`[Feature ${feature.name}] Entity "${entityName}" retention.strategy="blockDelete" but no field has an anonymize-function. Once keepFor expires, the data-retention cron anonymizes nothing and the row keeps its PII. Add { anonymize: () => null } or () => "[ANONYMIZED]" to PII fields.`);
                 }
             }
         }

package/dist/engine/boot-validator/projection-list-screens.js

@@ -10,7 +10,7 @@ import { getZodObjectShape } from "./zod-shape.js";
 // reaches into feature.entities[screen.entity] — a projectionList has no
 // entity, so sharing the function would mean threading a discriminated
 // union through every entity-bound helper it calls.
-// Exported for query-refs.ts (fw#2178) — one source for the QN-derivation
+// Exported for query-refs.ts — one source for the QN-derivation
 // logic instead of duplicating it in both boot-validators.
 export function buildQueryHandlerMap(features) {
     const out = new Map();
@@ -29,7 +29,7 @@ function schemaAccepts(schema, key) {
     return shape !== undefined && key in shape;
 }
 // sortable/paginated are derived by buildAppSchema from the query's Zod
-// schema (fw#2165) — there is no separate wire type from the author-facing
+// schema — there is no separate wire type from the author-facing
 // ProjectionListScreenDefinition, so hand-authoring them would otherwise be
 // silently overwritten with no signal to the author. Reject outright.
 function rejectHandAuthoredDerivedFlags(prefix, screen) {
@@ -67,7 +67,7 @@ function validateOneProjectionListScreen(feature, screen, queryHandlers, feature
     validateProjectionListFilterSchemaAcceptance(prefix, screen, schema);
     validateProjectionListFacetsSchemaAcceptance(prefix, screen, schema);
 }
-// filter (fw#2224) sends `payload.filter` — same 422 footgun as facets below
+// filter sends `payload.filter` — same 422 footgun as facets below
 // if the handler's schema doesn't accept it.
 function validateProjectionListFilterSchemaAcceptance(prefix, screen, schema) {
     // skip: no filter declared, or the schema already accepts it — nothing to reject.
@@ -77,11 +77,11 @@ function validateProjectionListFilterSchemaAcceptance(prefix, screen, schema) {
         `schema — add filter: z.object({ field: z.string(), op: z.enum(["eq","ne","lt","gt","lte","gte","in"]), ` +
         `value: z.unknown() }).optional() (or reuse entityListSchema's shape) to the handler's schema.`);
 }
-// facets (fw#2224) send `payload.filters` — same failure mode as search/sort
-// (fw#2165): definePagedQueryHandler doesn't auto-merge params into the
+// facets send `payload.filters` — same failure mode as search/sort:
+// definePagedQueryHandler doesn't auto-merge params into the
 // handler's own Zod schema, so a declared facet would 422 on every query
 // unless the author added `filters` themselves.
-// A dateRange facet (fw#3104) sends its two bounds as the top-level payload
+// A dateRange facet sends its two bounds as the top-level payload
 // keys it names in `params`, not as a `filters` entry — so the query has to
 // accept exactly those keys. Catches the facet pointed at a field the query
 // can't narrow by, which would otherwise 422 on the first date the user picks.
@@ -203,7 +203,7 @@ function validateRelatedListGroupBy(prefix, section) {
 }
 // relatedList sections declare search/facets the same way a projectionList
 // screen does, and hit the same 422 footgun: definePagedQueryHandler doesn't
-// auto-merge params into the handler's own Zod schema (fw#2165/#2224), so an
+// auto-merge params into the handler's own Zod schema, so an
 // undeclared param would fail every query instead of failing at boot.
 // Reachable on projectionDetail only (screens.ts rejects relatedList
 // elsewhere), but the layout walk stays uniform so lifting that restriction

package/dist/engine/boot-validator/query-refs.js

@@ -25,7 +25,7 @@ function checkVisibleWhenQueryRef(queryHandlers, query, buildPrefix) {
         "Make the query's input fields optional or use a query without required input.");
 }
 // relatedList is currently only reachable on projectionDetail — screens.ts
-// rejects it outright on entityEdit/actionForm/configEdit (fw#2166). Walking
+// rejects it outright on entityEdit/actionForm/configEdit. Walking
 // the shared EditLayout uniformly here (instead of excluding those three
 // types) keeps this collector correct if that restriction is ever lifted.
 function checkEditLayoutQueryRefs(queryHandlers, featureName, screenId, screenType, layout) {

package/dist/engine/boot-validator/screens-actions.js

@@ -7,7 +7,7 @@ export function isRowClickAction(action) {
     return (action.kind === "navigate" || action.kind === "drawer") && action.rowClick === true;
 }
 // entityList and projectionList both allow a rowAction to double as the
-// row-body click target (rowClick: true, fw#1708/#2164) — at most one per
+// row-body click target (rowClick: true) — at most one per
 // screen, or the renderer can't tell which one should fire.
 export function validateAtMostOneRowClick(featureName, screenId, screenType, rowActions) {
     const rowClickActions = rowActions.filter(isRowClickAction);
@@ -30,18 +30,17 @@ export function readsNavigateParamsAsFormPrefill(target, explicitEntityId, sourc
         return false;
     return sourceScreenEntity === undefined || target.entity !== sourceScreenEntity;
 }
-// Tier 2.7e navigate rowAction → target-screen params validity. Shared by
-// entityList and projectionList (framework#1708) — projectionList has no
+// Navigate rowAction → target-screen params validity. Shared by
+// entityList and projectionList — projectionList has no
 // `screen.entity`, so there's no same-entity row["id"] auto-fill case: any
 // entityEdit target without an explicit entityId reaches create there.
 //
-// dashboard targets (framework#1708 follow-up, commit 4e0d6cb26) also read
-// URL search params — but only for the single `filter.id` a dashboard
-// declares (useFilterParams in dashboard-body.tsx seeds its value from
-// `nav.searchParams[filter.id]`). A dashboard with no `filter` has nowhere
-// for the value to land, and a params extractor whose keys don't include
-// the filter's id would silently miss it — both are boot errors instead of
-// a silently-empty dashboard.
+// Dashboard targets also read URL search params — but only for the single
+// `filter.id` a dashboard declares (useFilterParams in dashboard-body.tsx
+// seeds its value from `nav.searchParams[filter.id]`). A dashboard with no
+// `filter` has nowhere for the value to land, and a params extractor whose
+// keys don't include the filter's id would silently miss it — both are boot
+// errors instead of a silently-empty dashboard.
 export function validateRowActionNavigateParams(featureName, screenId, screenType, screenEntity, action, target, actionLabel = "rowAction") {
     // skip: not a navigate-with-params action — nothing to validate here.
     if (action.kind !== "navigate" || action.params === undefined)
@@ -122,7 +121,7 @@ export function validateActionHasIcon(featureName, screenId, screenType, context
             `its kebab segments via the default icon map (resolveActionIcon).`);
     }
 }
-// Tier 2.7e-3: pin an action's declarative field references against the entity
+// Pin an action's declarative field references against the entity
 // fields — a typo in pick/map source fields or visible.field would otherwise
 // silently yield `undefined` in the payload or permanently wrong visibility
 // (same "typo only surfaces on click" class as navigate/handler). Exported for
@@ -206,9 +205,9 @@ export function validateScreenNavTarget(featureName, screenId, screenKind, field
 // validateScreens below), the drawer mounts the target inline using this
 // feature's schema, so a cross-feature reference could never actually
 // render. Two distinct failure messages: dangling reference vs. wrong
-// screen type. Shared by ToolbarAction (fw#2225) and RowAction (fw#2710)
-// drawer variants — same target-resolution rule, only the label in the
-// error message ("toolbarAction" vs. "rowAction" vs. "action") differs.
+// screen type. Shared by ToolbarAction and RowAction drawer variants —
+// same target-resolution rule, only the label in the error message
+// ("toolbarAction" vs. "rowAction" vs. "action") differs.
 export function validateDrawerTargetAction(featureName, screenId, screenKind, actionLabel, action, screens) {
     const target = screens[action.screen];
     if (target === undefined) {
@@ -337,8 +336,8 @@ export function resolveRowActionNavigateTarget(featureName, screenId, screenType
 // redirect is either a short screen id (same-feature, e.g. "item-list") or
 // a fully-qualified cross-feature QN (`<feature>:screen:<id>`) — the
 // renderer strips the latter to the short id (lastSegment) when
-// navigating, which the nav-router resolves app-wide (#1946). The object
-// form (fw#2670) carries the same target under `screen` plus the payload
+// navigating, which the nav-router resolves app-wide. The object
+// form carries the same target under `screen` plus the payload
 // field `idFrom`. Shared by actionForm/secretMint (validateInlineFormNavTargets)
 // and entityEdit — same rule, same error message, one place to keep them in sync.
 export function validateRedirectTarget(feature, screenId, screenKind, redirect, lookups, 

package/dist/engine/boot-validator/screens-forms.js

@@ -4,7 +4,7 @@ import { isExtensionEditSection, isWriteFormEditSection, normalizeEditField, sec
 import { validateFormDerivations, validateFormDerivationsEnforced } from "./form-derivations.js";
 import { isSensitiveOrPasswordField, validateIdlessSuccessLink, validateRedirectTarget, validateScreenNavTarget, } from "./screens-actions.js";
 // A field type in NO_WIDGET_FIELD_TYPES renders read-only on the auto-wired
-// entityEdit path (#1925) — a required field the user can never fill would
+// entityEdit path — a required field the user can never fill would
 // block every save. Only the statically-resolvable case is caught here: a
 // literal `required: true` (screen-spec override or entity-level default).
 // A dynamic FieldCondition depends on runtime form values and can't be
@@ -95,7 +95,7 @@ export function validateNoWidgetRequiredField(featureName, screenId, entityDef,
     if (fieldDef === undefined || !NO_WIDGET_FIELD_TYPES.includes(fieldDef.type))
         return;
     // Embedded LIST fields (`multiple: true`) get their own EmbeddedListField
-    // grid widget (#1838) — only plain (non-list) embedded has no widget.
+    // grid widget — only plain (non-list) embedded has no widget.
     const isEmbeddedList = fieldDef.type === "embedded" && fieldDef.multiple === true;
     // skip: list variant has a widget — not the no-widget case this guard targets.
     if (isEmbeddedList)
@@ -115,8 +115,7 @@ export function validateNoWidgetRequiredField(featureName, screenId, entityDef,
 }
 // Shared by projectionDetail and entityEdit: a tab strip needs something to
 // label each tab with and a stable id per tab — the id anchors the ?tab=
-// param on projectionDetail and the jump-to-erroring-tab logic on entityEdit
-// (fw#3134).
+// param on projectionDetail and the jump-to-erroring-tab logic on entityEdit.
 export function validateTabSections(featureName, screenId, screenType, sections) {
     if (sections.length < 2) {
         throw new Error(`[Feature ${featureName}] Screen "${screenId}" (${screenType}) has mode: "tabs" but only ` +
@@ -149,7 +148,7 @@ export function validateTabSections(featureName, screenId, screenType, sections)
 export function validateWizardLayout(featureName, screenId, screenType, layout, featureMap) {
     // entityEdit renders tabs like wizard steps: every section stays mounted,
     // submit validates across all of them, and a field error jumps to the tab
-    // holding it (fw#3134). The other three have no such jump — actionForm and
+    // holding it. The other three have no such jump — actionForm and
     // secretMint are one-shot forms, configEdit fires a write per field — so a
     // required field on a hidden tab would still block their submit silently.
     if (layout.mode === "tabs") {
@@ -201,7 +200,7 @@ export function validateWizardLayout(featureName, screenId, screenType, layout,
 //
 // Field-level renderer QN strings (cross-feature `component:` references)
 // are NOT validated here — the r.uiComponent registry that would resolve
-// them ships in M4/M5. Until then those are kept opaque on purpose.
+// them ships later. Until then those are kept opaque on purpose.
 // Shared by the mint step's own handler (screen.handler) and its optional
 // confirm step (confirm.handler) — both are a bare write-handler QN with the
 // same registration requirement.
@@ -226,7 +225,7 @@ function validateWriteHandlerRegistered(featureName, screenId, context, handler,
 // secretMint's own `confirm` step — a second, independent inline form on the
 // same screen — can reuse the same checks as its `fields`/`layout` pair.
 // `allowEmpty` is only ever true for a secretMint's own mint step (an
-// input-less mint, fw#2838): the secret is server-generated and the mint
+// input-less mint): the secret is server-generated and the mint
 // step is just its submit button — actionForm and the confirm step always
 // require at least one field.
 function validateFormFieldsMap(featureName, screenId, context, fields, allowEmpty) {
@@ -330,7 +329,7 @@ export function validateFormSelectOptions(featureName, screenId, context, fieldN
         }
     }
 }
-// Fail-closed currency-source gate (fw#2839), the runtime half of the
+// Fail-closed currency-source gate, the runtime half of the
 // narrowed `FormFieldDefinition` — an untyped JS consumer has no compiler to
 // stop it. An inline form screen has no entity, so a money field there can't
 // borrow `entity.defaultCurrency`: without a declared source the renderer
@@ -454,7 +453,7 @@ function validateInlineFormNavTargets(feature, screenId, screen, kind, lookups)
 export function validateInlineFormScreen(feature, screenId, screen, kind, allWriteHandlerQns, lookups, featureMap) {
     validateWriteHandlerRegistered(feature.name, screenId, kind, screen.handler, allWriteHandlerQns);
     // Only a secretMint's own mint step may skip fields/sections entirely
-    // (input-less mint, fw#2838) — actionForm always needs at least one field.
+    // (input-less mint) — actionForm always needs at least one field.
     const allowEmptyMintForm = kind === "secretMint";
     const fieldNames = validateFormFieldsMap(feature.name, screenId, kind, screen.fields, allowEmptyMintForm);
     validateFormLayoutSections(feature.name, screenId, kind, screen.layout, fieldNames, screen.fields, allowEmptyMintForm && fieldNames.size === 0);
@@ -472,14 +471,14 @@ export function validateInlineFormScreen(feature, screenId, screen, kind, allWri
     }
     validateInlineFormNavTargets(feature, screenId, screen, kind, lookups);
 }
-// SecretMintConfirmStep (fw#2838): an optional proof-of-receipt form rendered
+// SecretMintConfirmStep: an optional proof-of-receipt form rendered
 // on the reveal card in place of the bare acknowledge button (TOTP enrollment:
 // scan the code, then enter one). Unlike the mint step, confirm always needs
 // at least one field — a step whose only job is proving receipt with no input
 // would be meaningless — and its layout is a single plain form, never a
 // wizard/tabs flow and never a persisted draft: a one-time reveal-confirm is
 // not a multi-step flow, and persisting a draft of it would re-open the leak
-// fw#2548 closed (a lingering copy of the just-revealed secret in storage).
+// (a lingering copy of the just-revealed secret in storage).
 export function validateSecretMintConfirm(feature, screenId, screen, allWriteHandlerQns) {
     const confirm = screen.confirm;
     // skip: the screen declares no confirm step — nothing to validate.

package/dist/engine/boot-validator/screens-lists.js

@@ -258,24 +258,23 @@ export function assertRefTargetRegistered(prefix, subject, refTarget, currentFea
                 .join(", ") || "(none)"}.`);
     }
 }
-// Facets (fw#2224) — unlike filter, a field inventory IS available here: the
+// Facets — unlike filter, a field inventory IS available here: the
 // declared columns. A facet on a field with no column is almost always a
 // typo (the user never sees the field anywhere), so this is hard-checked
-// rather than just documented. Shared by projectionList and relatedList
-// (fw#2740) — `prefix` carries the caller's own screen/section message lead-in.
+// rather than just documented. Shared by projectionList and relatedList —
+// `prefix` carries the caller's own screen/section message lead-in.
 //
-// `type: "reference"` is exempt from the same-name-column rule (fw akte-
-// bedienkonzept-2): it filters by an id field (e.g. "propertyId") but
-// displays a different, human-readable column (e.g. "propertyLabel") — a
-// column named after the filter field would almost never exist, and
-// requiring one anyway would force apps to add a column no design calls
-// for just to satisfy this check. Its own `entity` is mandatory on the type
-// (TS, not just this validator) and is resolved below — that explicit,
-// checked declaration is this facet type's field inventory, filling the
-// same "not just a typo" role the column-name check plays for select/
-// boolean facets. select/boolean facets keep the column requirement
-// unchanged: both filter and display the same field, so a facet with no
-// matching column is still almost always a typo.
+// `type: "reference"` is exempt from the same-name-column rule: it filters
+// by an id field (e.g. "propertyId") but displays a different,
+// human-readable column (e.g. "propertyLabel") — a column named after the
+// filter field would almost never exist, and requiring one anyway would
+// force apps to add a column no design calls for just to satisfy this check.
+// Its own `entity` is mandatory on the type (TS, not just this validator) and
+// is resolved below — that explicit, checked declaration is this facet type's
+// field inventory, filling the same "not just a typo" role the column-name
+// check plays for select/boolean facets. select/boolean facets keep the
+// column requirement unchanged: both filter and display the same field, so a
+// facet with no matching column is still almost always a typo.
 export function validateListFacets(prefix, facets, columns, currentFeatureName, featureMap) {
     const columnFieldNames = new Set(columns.map((col) => normalizeListColumn(col).field));
     const seenFacetFields = new Set();