pbiplint 0.2.0 → 0.2.1

package/dist/pbiplint.mjs

@@ -1,13 +1,13 @@
 #!/usr/bin/env node
 
 // ../core/src/version.ts
-var VERSION = "0.2.0";
+var VERSION = "0.2.1";
 
 // ../core/src/engine/config.ts
 var ConfigError = class extends Error {
 };
 function bindConfig(config, rules) {
-  const idByUpper = new Map(rules.map((r) => [r.id.toUpperCase(), r.id]));
+  const ruleByUpper = new Map(rules.map((r) => [r.id.toUpperCase(), r]));
   const bound = {
     disabled: /* @__PURE__ */ new Set(),
     severity: /* @__PURE__ */ new Map(),
@@ -16,22 +16,23 @@ function bindConfig(config, rules) {
   };
   const unknownRules = [];
   for (const id of config.disabled) {
-    const real = idByUpper.get(id.toUpperCase());
+    const real = ruleByUpper.get(id.toUpperCase())?.id;
     if (real === void 0) unknownRules.push(id);
     else bound.disabled.add(real);
   }
   for (const [id, severity] of config.severity) {
-    const real = idByUpper.get(id.toUpperCase());
+    const real = ruleByUpper.get(id.toUpperCase())?.id;
     if (real === void 0) unknownRules.push(id);
     else bound.severity.set(real, severity);
   }
   for (const [id, options] of config.options) {
-    const real = idByUpper.get(id.toUpperCase());
-    if (real === void 0) {
+    const rule = ruleByUpper.get(id.toUpperCase());
+    if (rule === void 0) {
       unknownRules.push(id);
       continue;
     }
-    const rule = rules.find((r) => r.id === real);
+    const real = rule.id;
+    if (Object.keys(options).length === 0) continue;
     const declared = rule.options ?? [];
     if (declared.length === 0)
       throw new ConfigError(`pbiplint.config.json: rules["${real}"] takes no options`);
@@ -50,7 +51,7 @@ function bindConfig(config, rules) {
           `pbiplint.config.json: rules["${real}"].${name} must be one of ${decl.values.join(", ")}`
         );
     }
-    bound.options.set(real, options);
+    bound.options.set(real, { ...options });
   }
   return { config: bound, unknownRules: [...new Set(unknownRules)] };
 }
@@ -90,7 +91,7 @@ function resolveConfig(raw = {}) {
             );
           out.severity.set(id, SEVERITY_BY_NAME[severity]);
         }
-        if (Object.keys(options).length > 0) out.options.set(id, options);
+        out.options.set(id, options);
       } else
         throw new ConfigError(
           `pbiplint.config.json: rules["${id}"] must be "off", "info", "warning", "error", or an object with a severity and options`
@@ -284,7 +285,16 @@ function buildTable(r, model) {
     else if (c.kind === "object" && c.type === "partition") t.partitions.push(buildPartition(c, t));
     else if (c.kind === "object" && c.type === "hierarchy")
       t.hierarchies.push(buildHierarchy(c, t));
-    else if (c.type === "calculationgroup") t.calculationGroup = buildCalculationGroup(c, t);
+    else if (c.type === "calculationgroup") {
+      const group = buildCalculationGroup(c, t);
+      const first = t.calculationGroup;
+      if (first) {
+        first.precedence ??= group.precedence;
+        first.description ??= group.description;
+        Object.assign(first.annotations, group.annotations);
+        first.items.push(...group.items);
+      } else t.calculationGroup = group;
+    }
   }
 }
 function buildRelationship(r) {
@@ -335,7 +345,85 @@ function finalizeKinds(model) {
       c.kind = c.expression !== void 0 ? "calculated" : t.kind === "calculated" ? "calculatedTable" : "data";
   }
 }
-function buildModel(files, unreadPaths = []) {
+function walkOrder(a, b) {
+  const as = a.split("/");
+  const bs = b.split("/");
+  for (let i = 0; i < Math.min(as.length, bs.length); i++) {
+    const [x, y] = [as[i], bs[i]];
+    if (x !== y) return x.localeCompare(y, "en") || (x < y ? -1 : 1);
+  }
+  return as.length - bs.length;
+}
+function modelDeclarations(f) {
+  const declared = (n2) => n2.kind === "object" || n2.kind === "flag";
+  const isModel = (n2) => n2.type === "model" && declared(n2);
+  const out = [];
+  for (const r of f.roots) {
+    out.push(r);
+    const models = isModel(r) ? [r] : r.type === "database" && declared(r) ? r.children.filter(isModel) : [];
+    for (const m of models) {
+      if (m !== r) out.push(m);
+      out.push(...m.children);
+    }
+  }
+  return out;
+}
+function readDeclaration(r, model) {
+  if (r.kind === "ref" || r.kind === "prop" || r.kind === "expr") return;
+  switch (r.type) {
+    case "model":
+      readModel(r, model);
+      break;
+    case "annotation":
+      if (r.name && r.children.length === 0) model.annotations[r.name] = r.value ?? "";
+      break;
+    case "table":
+      buildTable(r, model);
+      break;
+    case "relationship":
+      model.relationships.push(buildRelationship(r));
+      break;
+    case "role":
+      model.roles.push(buildRole(r));
+      break;
+    case "perspective": {
+      const p = {
+        ...named(r),
+        tables: objects(r, "perspectivetable").map((t) => t.name)
+      };
+      model.perspectives.push(p);
+      break;
+    }
+    case "cultureinfo":
+      model.cultures.push(named(r));
+      break;
+    case "expression":
+      model.expressions.push({ ...named(r), expression: r.value ?? "" });
+      break;
+    case "function":
+      model.functions.push({ ...named(r), expression: r.value ?? "" });
+      break;
+    case "datasource": {
+      const ds = {
+        ...named(r),
+        kind: (r.value ?? "").trim().toLowerCase() === "provider" ? "provider" : "structured"
+      };
+      model.dataSources.push(ds);
+      break;
+    }
+    default:
+      break;
+  }
+}
+function readModel(r, model) {
+  Object.assign(model, named(r, r.name ?? "Model"), {
+    description: r.description ?? model.description,
+    annotations: model.annotations,
+    props: { ...model.props, ...r.props }
+  });
+}
+function buildModel(given, unreadPaths = []) {
+  const files = [...given].sort((a, b) => walkOrder(a.file, b.file));
   const model = {
     name: "Model",
     annotations: {},
@@ -352,64 +440,15 @@ function buildModel(files, unreadPaths = []) {
     files,
     unreadPaths: unreadPaths.filter((p) => p.endsWith(".tmdl") || p.endsWith("/"))
   };
-  for (const f of files) {
-    for (const r of f.roots) {
-      if (r.kind === "ref" || r.kind === "prop" || r.kind === "expr") continue;
-      switch (r.type) {
-        case "model":
-          Object.assign(model, named(r, r.name ?? "Model"), {
-            annotations: { ...model.annotations, ...annotationsOf(r) },
-            props: r.props
-          });
-          break;
-        case "annotation":
-          if (r.name) model.annotations[r.name] = r.value ?? "";
-          break;
-        case "table":
-          buildTable(r, model);
-          break;
-        case "relationship":
-          model.relationships.push(buildRelationship(r));
-          break;
-        case "role":
-          model.roles.push(buildRole(r));
-          break;
-        case "perspective": {
-          const p = {
-            ...named(r),
-            tables: objects(r, "perspectivetable").map((t) => t.name)
-          };
-          model.perspectives.push(p);
-          break;
-        }
-        case "cultureinfo":
-          model.cultures.push(named(r));
-          break;
-        case "expression":
-          model.expressions.push({ ...named(r), expression: r.value ?? "" });
-          break;
-        case "function":
-          model.functions.push({ ...named(r), expression: r.value ?? "" });
-          break;
-        case "datasource": {
-          const ds = {
-            ...named(r),
-            kind: (r.value ?? "").trim().toLowerCase() === "provider" ? "provider" : "structured"
-          };
-          model.dataSources.push(ds);
-          break;
-        }
-        default:
-          break;
-      }
-    }
-  }
+  for (const f of files) for (const r of modelDeclarations(f)) readDeclaration(r, model);
   finalizeKinds(model);
   return model;
 }
 
 // ../core/src/model/names.ts
 var isAutoDateTable = (t) => t.kind === "calculated" && (t.name.startsWith("DateTableTemplate_") || t.name.startsWith("LocalDateTable_"));
+var isAutoDateTableCopy = (t) => t.name.startsWith("LocalDateTable_") && t.partitions.some((p) => p.sourceType === "entity" && p.mode === "directquery");
+var isHiddenAutoDateTable = (t) => isAutoDateTable(t) || isAutoDateTableCopy(t);
 var tableRef = (name) => `'${name.replace(/'/g, "''")}'`;
 var bracket = (name) => `[${name.replace(/\]/g, "]]")}]`;
 var columnRef = (table, column) => `${tableRef(table)}${bracket(column)}`;
@@ -427,10 +466,12 @@ var ruleUrl = (id) => RULE_URL_BASE + slug(id);
 
 // ../core/src/index/reachability.ts
 var isTable = (n2) => "columns" in n2;
-var isMeasure = (n2) => "expression" in n2 && !("kind" in n2);
-var nameOf = (n2) => isTable(n2) ? tableRef(n2.name) : isMeasure(n2) ? measureRef(n2.name) : columnRef(n2.table.name, n2.name);
+var isMeasure = (n2) => "table" in n2 && !("kind" in n2);
 var listOf = (items) => items.length <= 2 ? items.join(" and ") : `${items.slice(0, -1).join(", ")}, and ${items.at(-1)}`;
 function buildReachabilityIndex(model, references, reportRefs) {
+  const functions = new Set(model.functions);
+  const isFunction = (n2) => functions.has(n2);
+  const nameOf = (n2) => isTable(n2) ? tableRef(n2.name) : isFunction(n2) ? n2.name : isMeasure(n2) ? measureRef(n2.name) : columnRef(n2.table.name, n2.name);
   const tables = new Map(model.tables.map((t) => [t.name.toLowerCase(), t]));
   const columnOf = (table, name) => tables.get(table.toLowerCase())?.columns.find((c) => c.name.toLowerCase() === name.toLowerCase());
   const measureOf = (table, name) => tables.get(table.toLowerCase())?.measures.find((m) => m.name.toLowerCase() === name.toLowerCase());
@@ -446,6 +487,7 @@ function buildReachabilityIndex(model, references, reportRefs) {
       if (r.kind === "column") reach(columnOf(r.table, r.name), from);
       else if (r.kind === "measure") reach(measureOf(r.table, r.name), from);
     }
+    for (const f of references.callsOf(owner)) reach(f, from);
   };
   for (const r of reportRefs.refs) {
     const res = r.resolution;
@@ -458,9 +500,10 @@ function buildReachabilityIndex(model, references, reportRefs) {
     }
     if ("variationOf" in res) reach(res.variationOf, null);
   }
+  for (const c of reportRefs.functionCalls) for (const f of c.calls) reach(f, null);
   const autoDate = (table) => {
     const t = tables.get(table.toLowerCase());
-    return t !== void 0 && isAutoDateTable(t);
+    return t !== void 0 && isHiddenAutoDateTable(t);
   };
   for (const rel of model.relationships) {
     if (autoDate(rel.fromTable) || autoDate(rel.toTable)) continue;
@@ -469,8 +512,7 @@ function buildReachabilityIndex(model, references, reportRefs) {
   }
   for (const role of model.roles)
     for (const tp of role.tablePermissions) {
-      for (const r of references.refsOf(tp))
-        if (r.kind === "column") reach(columnOf(r.table, r.name), null);
+      reachDax(tp, null);
       for (const cp of tp.columnPermissions) reach(columnOf(tp.table, cp.column), null);
     }
   for (const t of model.tables)
@@ -480,6 +522,10 @@ function buildReachabilityIndex(model, references, reportRefs) {
   for (const t of model.tables) for (const c of t.columns) if (c.alternateOf) reach(c, null);
   while (queue.length) {
     const n2 = queue.shift();
+    if (isFunction(n2)) {
+      reachDax(n2, n2);
+      continue;
+    }
     if (isTable(n2)) {
       if (n2.kind === "calculated") reachDax(n2, n2);
       for (const item of n2.calculationGroup?.items ?? []) reachDax(item, n2);
@@ -498,8 +544,8 @@ function buildReachabilityIndex(model, references, reportRefs) {
     if (base?.baseColumn) reach(columnOf(base.baseTable ?? "", base.baseColumn), n2);
     else if (base?.baseTable) reach(tables.get(base.baseTable.toLowerCase()), n2);
   }
-  const NAMEABLE = /* @__PURE__ */ new Set(["measure", "calculatedColumn"]);
-  const daxReferrers = (owners) => owners.filter((o) => NAMEABLE.has(o.kind)).map((o) => o.object);
+  const nameable = (o) => o.kind === "measure" || o.kind === "calculatedColumn" || o.kind === "function";
+  const daxReferrers = (owners) => owners.filter(nameable).map((o) => o.object);
   const referrersOf = (n2) => {
     if (isMeasure(n2)) return daxReferrers(references.measureReferencedBy(n2));
     const dax = daxReferrers(references.columnReferencedBy(n2));
@@ -521,7 +567,7 @@ function buildReachabilityIndex(model, references, reportRefs) {
       return path;
     },
     unreached: () => {
-      const listed = model.tables.filter((t) => !isAutoDateTable(t));
+      const listed = model.tables.filter((t) => !isHiddenAutoDateTable(t));
       const columns2 = listed.flatMap((t) => t.columns.filter((c) => !parent.has(c)));
       const measures = listed.flatMap((t) => t.measures.filter((m) => !parent.has(m)));
       const tables2 = listed.filter(
@@ -559,6 +605,41 @@ function extractRefs(expression) {
 }
 var lower2 = (s) => s.toLowerCase();
 var key = (table, name) => `${lower2(table)} ${lower2(name)}`;
+var escapeRegExp = (s) => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+function functionCallReader(functions) {
+  if (functions.length === 0) return () => [];
+  const byName2 = /* @__PURE__ */ new Map();
+  for (const f of functions) if (!byName2.has(lower2(f.name))) byName2.set(lower2(f.name), f);
+  const call = new RegExp(
+    `(^|[^\\p{L}\\p{N}_.])(${[...byName2.keys()].map(escapeRegExp).join("|")})(?=\\s*\\()`,
+    "giu"
+  );
+  const order3 = new Map(functions.map((f, i) => [f, i]));
+  return (expression) => {
+    const found = /* @__PURE__ */ new Set();
+    for (const m of expression.matchAll(call)) {
+      const f = byName2.get(lower2(m[2]));
+      if (f) found.add(f);
+    }
+    return [...found].sort((a, b) => order3.get(a) - order3.get(b));
+  };
+}
+function resolveBareName(name, owner, lookup) {
+  const measure = lookup.measureNamed(name);
+  if (measure !== void 0) return { kind: "measure", measure };
+  if (owner.kind === "calculationItem") return { kind: "none" };
+  if (owner.kind === "function") {
+    const columns2 = lookup.tables.flatMap((t) => lookup.columnOf(t, name) ?? []);
+    return columns2.length > 0 ? { kind: "columns", columns: columns2 } : { kind: "none" };
+  }
+  const own = owner.table && lookup.columnOf(owner.table, name);
+  if (own) return { kind: "columns", columns: [own] };
+  for (const t of lookup.tables) {
+    const column = lookup.columnOf(t, name);
+    if (column) return { kind: "columns", columns: [column] };
+  }
+  return { kind: "none" };
+}
 function buildReferenceIndex(model) {
   const tables = new Map(model.tables.map((t) => [lower2(t.name), t]));
   const columns2 = /* @__PURE__ */ new Map();
@@ -568,66 +649,83 @@ function buildReferenceIndex(model) {
     for (const m of t.measures) measures.set(lower2(m.name), m);
   }
   const columnOf = (t, name) => columns2.get(key(t.name, name));
+  const lookup = {
+    tables: model.tables,
+    columnOf,
+    measureNamed: (name) => measures.get(lower2(name))
+  };
   const resolve4 = (raw, ownerTable, ownerKind) => {
     if (raw.qualified) {
       const t = tables.get(lower2(raw.table));
       if (!t) return { kind: "unresolved", table: raw.table, name: raw.name, qualified: true };
       const col = columnOf(t, raw.name);
       if (col) return { kind: "column", table: t.name, name: col.name, qualified: true };
-      const meas2 = t.measures.find((m) => lower2(m.name) === lower2(raw.name));
-      if (meas2) return { kind: "measure", table: t.name, name: meas2.name, qualified: true };
+      const meas = t.measures.find((m) => lower2(m.name) === lower2(raw.name));
+      if (meas) return { kind: "measure", table: t.name, name: meas.name, qualified: true };
       return { kind: "unresolved", table: raw.table, name: raw.name, qualified: true };
     }
-    const meas = measures.get(lower2(raw.name));
-    if (meas) return { kind: "measure", table: meas.table.name, name: meas.name, qualified: false };
-    if (ownerKind === "calculationItem")
-      return { kind: "unresolved", name: raw.name, qualified: false };
-    if (ownerTable) {
-      const col = columnOf(ownerTable, raw.name);
-      if (col) return { kind: "column", table: ownerTable.name, name: col.name, qualified: false };
-    }
-    for (const t of model.tables) {
-      const col = columnOf(t, raw.name);
-      if (col) return { kind: "column", table: t.name, name: col.name, qualified: false };
-    }
+    const bare = resolveBareName(raw.name, { kind: ownerKind, table: ownerTable }, lookup);
+    if (bare.kind === "measure")
+      return {
+        kind: "measure",
+        table: bare.measure.table.name,
+        name: bare.measure.name,
+        qualified: false
+      };
+    if (bare.kind === "columns")
+      return bare.columns.map((c) => ({
+        kind: "column",
+        table: c.table.name,
+        name: c.name,
+        qualified: false
+      }));
     return { kind: "unresolved", name: raw.name, qualified: false };
   };
+  const callsIn = functionCallReader(model.functions);
   const owners = [];
   const byObject = /* @__PURE__ */ new Map();
-  const add = (kind, object, ownerTable, ...expressions) => {
+  const add = (of, ownerTable, ...expressions) => {
     const expression = expressions.filter((e) => e !== void 0).join("\n");
     const owner = {
-      kind,
-      object,
+      ...of,
       ownerTable,
       expression,
-      refs: extractRefs(expression).map((r) => resolve4(r, ownerTable, kind))
+      refs: extractRefs(expression).flatMap((r) => resolve4(r, ownerTable, of.kind)),
+      calls: callsIn(expression)
     };
     owners.push(owner);
-    byObject.set(object, owner);
+    byObject.set(of.object, owner);
   };
   for (const t of model.tables) {
-    for (const m of t.measures) add("measure", m, t, m.expression, m.formatStringDefinition);
+    for (const m of t.measures)
+      add({ kind: "measure", object: m }, t, m.expression, m.formatStringDefinition);
     for (const c of t.columns)
-      if (c.kind === "calculated") add("calculatedColumn", c, t, c.expression);
+      if (c.kind === "calculated") add({ kind: "calculatedColumn", object: c }, t, c.expression);
     if (t.kind === "calculated")
       add(
-        "calculatedTable",
-        t,
+        { kind: "calculatedTable", object: t },
         t,
         ...t.partitions.filter((p) => p.sourceType === "calculated").map((p) => p.source)
       );
     for (const item of t.calculationGroup?.items ?? [])
-      add("calculationItem", item, t, item.expression, item.formatStringDefinition);
+      add(
+        { kind: "calculationItem", object: item },
+        t,
+        item.expression,
+        item.formatStringDefinition
+      );
   }
   for (const role of model.roles) {
     for (const tp of role.tablePermissions)
       if (tp.filter !== void 0)
-        add("tablePermission", tp, tables.get(lower2(tp.table)), tp.filter);
+        add({ kind: "tablePermission", object: tp }, tables.get(lower2(tp.table)), tp.filter);
   }
+  for (const f of model.functions) add({ kind: "function", object: f }, void 0, f.expression);
   const columnRefs = /* @__PURE__ */ new Map();
   const measureRefs = /* @__PURE__ */ new Map();
+  const callers = /* @__PURE__ */ new Map();
   for (const o of owners) {
+    for (const f of o.calls) callers.set(f, [...callers.get(f) ?? [], o]);
     for (const r of o.refs) {
       if (r.kind === "column") {
         const k = key(r.table, r.name);
@@ -646,7 +744,9 @@ function buildReferenceIndex(model) {
     owners,
     refsOf: (object) => byObject.get(object)?.refs ?? [],
     columnReferencedBy: (c) => columnRefs.get(key(c.table.name, c.name)) ?? [],
-    measureReferencedBy: (m) => measureRefs.get(lower2(m.name)) ?? []
+    measureReferencedBy: (m) => measureRefs.get(lower2(m.name)) ?? [],
+    callsOf: (object) => byObject.get(object)?.calls ?? [],
+    functionCalledBy: (f) => callers.get(f) ?? []
   };
 }
 
@@ -706,7 +806,9 @@ function buildReportReferenceIndex(report, model) {
   const missingOn = (t, reason) => {
     const files = model?.files ?? [];
     const declaring = files.find(
-      (f) => partlyRead.has(f.file) && f.roots.some((r) => r.kind === "object" && r.type === "table" && r.name === t.name)
+      (f) => partlyRead.has(f.file) && modelDeclarations(f).some(
+        (r) => r.kind === "object" && r.type === "table" && r.name === t.name
+      )
     );
     if (declaring) return unread2(reason, declaring.file);
     if (neverRead !== void 0) return notRead(reason, neverRead);
@@ -822,6 +924,14 @@ function buildReportReferenceIndex(report, model) {
     }
   }
   for (const b of report.bookmarks) add({ kind: "bookmark", object: b }, b.file, b.refs);
+  const bareLookup = {
+    tables: model?.tables ?? [],
+    columnOf,
+    measureNamed: (name) => {
+      const inModel = measuresByName.get(lower3(name));
+      return inModel ? { table: inModel.table.name, name: inModel.name } : reportMeasuresByName.get(lower3(name));
+    }
+  };
   for (const m of report.measures) {
     const owner = { kind: "reportMeasure", object: m };
     for (const raw of extractRefs(m.expression)) {
@@ -831,30 +941,37 @@ function buildReportReferenceIndex(report, model) {
         add(owner, m.file, [{ kind, table: raw.table, name: raw.name, pointer: "" }]);
         continue;
       }
-      const modelMeasure = measuresByName.get(lower3(raw.name));
-      const extension = reportMeasuresByName.get(lower3(raw.name));
-      if (modelMeasure)
-        add(owner, m.file, [
-          { kind: "measure", table: modelMeasure.table.name, name: modelMeasure.name, pointer: "" }
-        ]);
-      else if (extension)
+      const bare = resolveBareName(
+        raw.name,
+        { kind: "reportMeasure", table: tables.get(lower3(m.table)) },
+        bareLookup
+      );
+      if (bare.kind === "measure")
         add(owner, m.file, [
-          { kind: "measure", table: extension.table, name: extension.name, pointer: "" }
+          { kind: "measure", table: bare.measure.table, name: bare.measure.name, pointer: "" }
         ]);
-      else {
-        const own = tables.get(lower3(m.table));
-        if (own && columnOf(own, raw.name))
-          add(owner, m.file, [{ kind: "column", table: own.name, name: raw.name, pointer: "" }]);
-        else
-          refs.push({
-            ref: { kind: "measure", table: m.table, name: raw.name, pointer: "" },
-            owner,
-            file: m.file,
-            resolution: missing(`no measure or column named ${q(raw.name)}`)
-          });
-      }
+      else if (bare.kind === "columns")
+        add(
+          owner,
+          m.file,
+          bare.columns.map((c) => ({
+            kind: "column",
+            table: c.table.name,
+            name: c.name,
+            pointer: ""
+          }))
+        );
+      else
+        refs.push({
+          ref: { kind: "measure", table: m.table, name: raw.name, pointer: "" },
+          owner,
+          file: m.file,
+          resolution: missing(`no measure or column named ${q(raw.name)}`)
+        });
     }
   }
+  const callsIn = functionCallReader(model?.functions ?? []);
+  const functionCalls = report.measures.map((measure) => ({ measure, calls: callsIn(measure.expression) })).filter((c) => c.calls.length > 0);
   const byTarget = /* @__PURE__ */ new Map();
   for (const r of refs) {
     const target = r.resolution.kind === "column" ? r.resolution.column : r.resolution.kind === "measure" ? r.resolution.measure : void 0;
@@ -867,7 +984,8 @@ function buildReportReferenceIndex(report, model) {
     refs,
     referencedBy: (target) => byTarget.get(target) ?? [],
     unresolved: () => refs.filter((r) => r.resolution.kind === "unresolved"),
-    fieldsOf: (v) => refs.filter((r) => r.owner.kind === "visualField" && r.owner.object === v)
+    fieldsOf: (v) => refs.filter((r) => r.owner.kind === "visualField" && r.owner.object === v),
+    functionCalls
   };
 }
 
@@ -877,9 +995,11 @@ function buildUsageIndex(model) {
   const sortTargets = /* @__PURE__ */ new Set();
   const levelColumns = /* @__PURE__ */ new Set();
   const variationDefaults = /* @__PURE__ */ new Set();
+  const groupByTargets = /* @__PURE__ */ new Set();
   for (const t of model.tables) {
     for (const c of t.columns) {
       if (c.sortByColumn !== void 0) sortTargets.add(key3(t.name, c.sortByColumn));
+      for (const g of c.groupByColumns) groupByTargets.add(key3(t.name, g));
       for (const v of c.variations)
         if (v.defaultColumn)
           variationDefaults.add(key3(v.defaultColumn.table, v.defaultColumn.column));
@@ -890,7 +1010,8 @@ function buildUsageIndex(model) {
   return {
     usedInSortBy: (c) => sortTargets.has(key3(c.table.name, c.name)),
     usedInHierarchies: (c) => levelColumns.has(key3(c.table.name, c.name)),
-    usedInVariations: (c) => variationDefaults.has(key3(c.table.name, c.name))
+    usedInVariations: (c) => variationDefaults.has(key3(c.table.name, c.name)),
+    usedInGroupBy: (c) => groupByTargets.has(key3(c.table.name, c.name))
   };
 }
 
@@ -916,20 +1037,42 @@ var isRecord2 = (v) => typeof v === "object" && v !== null && !Array.isArray(v);
 var kindOf = (v) => v === null ? "null" : Array.isArray(v) ? "an array" : typeof v === "string" ? "a string" : typeof v === "number" ? "a number" : "a boolean";
 var CONFLICT_MARKER = /^(?:<{7}|={7}|>{7})(?:\s|$)/;
 var LINE_BREAK = /\r\n?|\n/;
+function quoted(line) {
+  if (line === void 0 || line.length <= 120) return line ?? "";
+  const text2 = line.trimStart();
+  if (text2.length <= 120) return text2;
+  const high = text2.charCodeAt(118);
+  const end = high >= 55296 && high <= 56319 ? 118 : 119;
+  return `${text2.slice(0, end)}\u2026`;
+}
+var lineAt = (body, offset) => body.slice(0, offset).split(LINE_BREAK).length;
+var MAX_DEPTH = 256;
+function tooDeepAt(body) {
+  let depth = 0;
+  for (let i = 0; i < body.length; i++) {
+    const ch = body[i];
+    if (ch === '"') {
+      for (i++; body[i] !== '"'; i++) if (body[i] === "\\") i++;
+    } else if (ch === "{" || ch === "[") {
+      if (++depth > MAX_DEPTH) return i;
+    } else if (ch === "}" || ch === "]") depth--;
+  }
+  return -1;
+}
 var AT_POSITION = /\bJSON at position (\d+)/;
 var AT_LINE = /\bline (\d+) column \d+/;
 var QUOTED_RUN = /^Unexpected token '(.)', (?:\.\.\.)?"([\s\S]*)"(?:\.\.\.)? is not valid JSON$/;
 function lineOfParseError(body, message) {
   const lineCount = body.split(LINE_BREAK).length;
-  const lineOf = (offset2) => body.slice(0, offset2).split(LINE_BREAK).length;
+  const lineOf = (offset2) => lineAt(body, offset2);
   const at2 = AT_POSITION.exec(message);
   if (at2 && Number(at2[1]) <= body.length) return lineOf(Number(at2[1]));
   const named2 = AT_LINE.exec(message);
   if (named2 && Number(named2[1]) >= 1 && Number(named2[1]) <= lineCount) return Number(named2[1]);
-  const quoted = QUOTED_RUN.exec(message);
-  if (!quoted) return 1;
-  const char = quoted[1];
-  const run = quoted[2];
+  const around = QUOTED_RUN.exec(message);
+  if (!around) return 1;
+  const char = around[1];
+  const run = around[2];
   const start = body.indexOf(run);
   if (start < 0) return 1;
   const middle = run.length / 2;
@@ -943,7 +1086,7 @@ function readJson(file, text2, options = {}) {
   const body = text2.charCodeAt(0) === 65279 ? text2.slice(1) : text2;
   const lines = body.split(LINE_BREAK);
   const issues = lines.flatMap(
-    (line, i) => CONFLICT_MARKER.test(line) ? [{ file, line: i + 1, text: line, reason: "merge conflict marker" }] : []
+    (line, i) => CONFLICT_MARKER.test(line) ? [{ file, line: i + 1, text: quoted(line), reason: "merge conflict marker" }] : []
   );
   if (issues.length > 0) return { json: void 0, issues };
   let json;
@@ -955,7 +1098,22 @@ function readJson(file, text2, options = {}) {
     const flat = message.replace(/\s+/g, " ");
     return {
       json: void 0,
-      issues: [{ file, line, text: lines[line - 1] ?? "", reason: `not valid JSON (${flat})` }]
+      issues: [{ file, line, text: quoted(lines[line - 1]), reason: `not valid JSON (${flat})` }]
+    };
+  }
+  const deep = tooDeepAt(body);
+  if (deep >= 0) {
+    const line = lineAt(body, deep);
+    return {
+      json: void 0,
+      issues: [
+        {
+          file,
+          line,
+          text: quoted(lines[line - 1]),
+          reason: `nested more than ${MAX_DEPTH} levels deep`
+        }
+      ]
     };
   }
   if (!isRecord2(json)) {
@@ -967,7 +1125,7 @@ function readJson(file, text2, options = {}) {
         {
           file,
           line: start + 1,
-          text: lines[start] ?? "",
+          text: quoted(lines[start]),
           reason: `not a JSON object (the file holds ${kindOf(json)})`
         }
       ]
@@ -990,9 +1148,12 @@ function newerThan(a, b) {
   return false;
 }
 var newerMajor = (a, b) => Number(a.split(".")[0]) > Number(b.split(".")[0]);
+var escapePointer = (s) => s.replace(/~/g, "~0").replace(/\//g, "~1");
+var unescapePointer = (s) => s.replace(/~1/g, "/").replace(/~0/g, "~");
+var endsLine = (text2, i) => text2[i] === "\n" || text2[i] === "\r" && text2[i + 1] !== "\n";
 function lineOfPointer(text2, pointer) {
   if (pointer === "") return 1;
-  const want = pointer.split("/").slice(1).map((s) => s.replace(/~1/g, "/").replace(/~0/g, "~"));
+  const want = pointer.split("/").slice(1).map(unescapePointer);
   const path = [];
   const kinds = [];
   const parent = () => kinds[kinds.length - 1];
@@ -1001,7 +1162,7 @@ function lineOfPointer(text2, pointer) {
   let expectKey = false;
   for (let i = text2.charCodeAt(0) === 65279 ? 1 : 0; i < text2.length; i++) {
     const ch = text2[i];
-    if (ch === "\n") {
+    if (endsLine(text2, i)) {
       line++;
       continue;
     }
@@ -1012,13 +1173,18 @@ function lineOfPointer(text2, pointer) {
         if (text2[j2] === "\\") j2++;
         j2++;
       }
-      const value = JSON.parse(text2.slice(i, j2 + 1));
+      let value;
+      try {
+        value = JSON.parse(text2.slice(i, j2 + 1));
+      } catch {
+        value = text2.slice(i + 1, j2);
+      }
       if (parent() === "object" && expectKey) {
         path[path.length - 1] = value;
         expectKey = false;
         if (matches()) return line;
       } else if (parent() === "array" && matches()) return line;
-      for (let k = i; k <= j2; k++) if (text2[k] === "\n") line++;
+      for (let k = i; k <= j2; k++) if (endsLine(text2, k)) line++;
       i = j2;
       continue;
     }
@@ -1050,7 +1216,6 @@ function lineOfPointer(text2, pointer) {
 
 // ../core/src/pbir/refs.ts
 var isRecord3 = (v) => typeof v === "object" && v !== null && !Array.isArray(v);
-var escapePointer = (s) => s.replace(/~/g, "~0").replace(/\//g, "~1");
 var schemaOf = (node) => typeof node.Schema === "string" && node.Schema !== "" ? { schema: node.Schema } : {};
 function sourceOf(expression, aliases) {
   if (!isRecord3(expression)) return { table: "", noTable: "noSource" };
@@ -1434,7 +1599,7 @@ var folderHoldsFieldReferences = (folder) => ["definition", "page", "visual", "b
 );
 var PAGE_FOLDER = /^definition\/pages\/([^/]+)\/$/;
 var VISUAL_FOLDER = /^definition\/pages\/([^/]+)\/visuals\/([^/]+)\/$/;
-var definedByPbir = (path) => path.endsWith("definition.pbir") || path.endsWith(".platform") || path.endsWith(".pbip") || definitionFile(path);
+var definedByPbir = (path) => path === "definition.pbir" || path === ".platform" || path.endsWith(".pbip") || definitionFile(path);
 function buildReport(files, unreadPaths = []) {
   const report = {
     publicCustomVisuals: [],
@@ -1508,13 +1673,13 @@ function buildReport(files, unreadPaths = []) {
       });
     }
     const json = read.json;
-    if (f.path.endsWith("definition.pbir")) {
+    if (f.path === "definition.pbir") {
       report.datasetReference = datasetReferenceOf(json);
       continue;
     }
     if (!isRecord4(json)) continue;
     let m;
-    if (f.path.endsWith(".platform")) {
+    if (f.path === ".platform") {
       if (isRecord4(json.metadata) && json.metadata.type === "Report")
         report.displayName = str2(json.metadata.displayName);
     } else if (f.path === "definition/report.json") {
@@ -1662,7 +1827,7 @@ function factsLines(result) {
     rule: f.ruleId ?? ""
   }));
   const labelWidth = Math.max(...rows.map((r) => r.label.length));
-  const valueWidth = Math.max(...rows.map((r) => r.value.length));
+  const valueWidth = Math.max(0, ...rows.filter((r) => r.rule).map((r) => r.value.length));
   return [
     "Report at a glance",
     ...rows.map(
@@ -1728,9 +1893,10 @@ var dataType = (c) => (c.dataType ?? "").toLowerCase();
 var isNumericType = (c) => ["int64", "decimal", "double"].includes(dataType(c));
 var hiddenOrTableHidden = (c) => c.isHidden || c.table.isHidden;
 var isBlank = (s) => s === void 0 || s.trim() === "";
-var escapeRegExp = (s) => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+var escapeRegExp2 = (s) => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
 var isDirectQueryTable = (t) => t.kind === "table" && t.partitions[0]?.mode === "directquery";
 var modelPartlyRead = (m) => m.unreadPaths.length > 0 || m.files.some((f) => f.issues.some((i) => i.canDropObjects));
+var tablesPartlyRead = (m) => m.unreadPaths.length > 0 || m.files.some((f) => f.issues.some((i) => i.canDropTableLine));
 var tablesInScope = (m) => m.tables.filter((t) => t.kind !== "calculationGroup");
 var tableObjectType = (t) => t.kind === "calculated" ? "CalculatedTable" : t.kind === "calculationGroup" ? "CalculationGroupTable" : "Table";
 var columnObjectType = (c) => c.kind === "calculated" ? "CalculatedColumn" : c.kind === "calculatedTable" ? "CalculatedTableColumn" : "Column";
@@ -2056,13 +2222,13 @@ function generalFilter(v, key4) {
 function slicerSearch(v) {
   const found = generalFilter(v, "selfFilter");
   if (found === void 0) return void 0;
-  const [only, ...more] = found.where;
-  const condition = isRecord5(only) && isRecord5(only.Condition) ? only.Condition : {};
+  const [only2, ...more] = found.where;
+  const condition = isRecord5(only2) && isRecord5(only2.Condition) ? only2.Condition : {};
   const contains = isRecord5(condition.Contains) ? condition.Contains : {};
   const right = isRecord5(contains.Right) ? contains.Right : {};
   const value = isRecord5(right.Literal) ? right.Literal.Value : void 0;
-  const quoted = typeof value === "string" ? /^'(.+)'$/s.exec(value) : null;
-  return quoted === null || more.length > 0 ? { pointer: found.pointer } : { pointer: found.pointer, term: quoted[1].replaceAll("''", "'") };
+  const quoted3 = typeof value === "string" ? /^'(.+)'$/s.exec(value) : null;
+  return quoted3 === null || more.length > 0 ? { pointer: found.pointer } : { pointer: found.pointer, term: quoted3[1].replaceAll("''", "'") };
 }
 var reportMeasuresToMove = (project) => project.model && project.report ? project.report.measures : [];
 function openingPage(r) {
@@ -2123,22 +2289,31 @@ function reportFacts(project, report, known, ruleOptions) {
     )
   );
   const pane = filtersPaneState(report);
-  facts.push(
-    pane === void 0 ? {
+  if (pane === void 0) {
+    facts.push({
       layer: "report",
       label: "Filters pane",
       value: "unknown",
       detail: "report.json was not read"
-    } : withRule(
-      {
-        layer: "report",
-        label: "Filters pane",
-        value: pane.state,
-        ...pane.recordedAt === void 0 ? { detail: "read as open; report.json does not record it" } : {}
-      },
-      ruleOptions.get("FILTERS_PANE_STATE")?.expect !== void 0 ? "FILTERS_PANE_STATE" : void 0
-    )
-  );
+    });
+  } else {
+    const policySet = ruleOptions.get("FILTERS_PANE_STATE")?.expect !== void 0;
+    const detail = [
+      pane.recordedAt === void 0 && "read as open; report.json does not record it",
+      !policySet && known.has("FILTERS_PANE_STATE") && "not checked; set an expect policy for FILTERS_PANE_STATE in pbiplint.config.json to check it"
+    ].filter(Boolean);
+    facts.push(
+      withRule(
+        {
+          layer: "report",
+          label: "Filters pane",
+          value: pane.state,
+          ...detail.length ? { detail: detail.join("; ") } : {}
+        },
+        policySet ? "FILTERS_PANE_STATE" : void 0
+      )
+    );
+  }
   const visualUnread2 = visualFileUnread(report);
   const unreadVisual = "a visual.json could not be read";
   const hidden = pages.filter(isHiddenPage).length;
@@ -2254,16 +2429,17 @@ function buildFacts(project, indexes, knownRules, ruleOptions = /* @__PURE__ */
   const facts = reportFacts(project, project.report, knownRules, ruleOptions);
   const model = project.model;
   if (model) {
-    const shown = model.tables.filter((t) => !isAutoDateTable(t));
-    const columns2 = shown.reduce((s, t) => s + t.columns.length, 0);
-    const measures = shown.reduce((s, t) => s + t.measures.length, 0);
+    const shown2 = model.tables.filter((t) => !isHiddenAutoDateTable(t));
+    const columns2 = shown2.reduce((s, t) => s + t.columns.length, 0);
+    const measures = shown2.reduce((s, t) => s + t.measures.length, 0);
     const partly = modelPartlyRead(model);
     const count = (k, noun) => k === 0 && partly ? `${noun}s: unknown` : n(k, noun);
-    const countUnknown = partly && [shown.length, columns2, measures].includes(0);
+    const countUnknown = partly && [shown2.length, columns2, measures].includes(0);
+    const functions = model.functions.length > 0 ? `, ${n(model.functions.length, "function")}` : "";
     const fact = {
       layer: "model",
       label: "Model",
-      value: `${count(shown.length, "table")}, ${count(columns2, "column")}, ${count(measures, "measure")}`
+      value: `${count(shown2.length, "table")}, ${count(columns2, "column")}, ${count(measures, "measure")}${functions}`
     };
     const reach = indexes.reachability;
     const unreadModel = "a model file could not be fully read";
@@ -2284,18 +2460,35 @@ function buildFacts(project, indexes, knownRules, ruleOptions = /* @__PURE__ */
 
 // ../core/src/project/route.ts
 var isModelFile = (path) => path.endsWith(".tmdl");
-var isReportFile = (path) => path.endsWith("definition.pbir") || path.endsWith(".platform") || path.endsWith(".pbip") || /(^|\/)definition\/.*\.json$/.test(path);
+var isReportFile = (path) => /(^|\/)(definition\.pbir|\.platform)$/.test(path) || path.endsWith(".pbip") || /(^|\/)definition\/.*\.json$/.test(path);
 var isPbix = (path) => /\.pbix$/i.test(path);
-var PBIP_PREVIEW_HELP_URLS = Object.freeze([
-  "https://learn.microsoft.com/power-bi/developer/projects/projects-overview#enable-preview-features",
-  "https://learn.microsoft.com/power-bi/developer/projects/projects-report#enable-the-pbir-format-preview-feature",
-  "https://learn.microsoft.com/power-bi/developer/projects/projects-dataset#enable-tmdl-format-preview-feature"
+var SAVE_AS_PROJECT_URL = "https://learn.microsoft.com/power-bi/developer/projects/projects-overview#save-as-a-project";
+var CONVERT_TO_PBIR_URL = "https://learn.microsoft.com/power-bi/developer/projects/projects-report#convert-existing-report-to-pbir";
+var LEARN_HELP_URLS = Object.freeze([
+  SAVE_AS_PROJECT_URL,
+  CONVERT_TO_PBIR_URL
 ]);
-var SAVE_AS_PROJECT = `pbiplint reads a report saved as a Power BI project (PBIP). In Power BI Desktop, choose File > Save as and pick Power BI project files (*.pbip) as the file type. Depending on your version of Power BI Desktop, you may need to enable certain preview features first. Microsoft Learn explains them: ${PBIP_PREVIEW_HELP_URLS.join(" ")}`;
+var SAVE_AS_PROJECT = `pbiplint reads a report saved as a Power BI project (PBIP). In Power BI Desktop, choose File > Save as and pick Power BI project files (*.pbip) as the file type. See Microsoft Learn: ${SAVE_AS_PROJECT_URL}`;
 function pbixRefusal(path, others = 0) {
   const what = others === 0 ? `${path} is a Power BI Desktop file (.pbix)` : `${path} and ${others} other .pbix ${others === 1 ? "file" : "files"} are Power BI Desktop files`;
   return `${what}, which pbiplint cannot read. ${SAVE_AS_PROJECT}`;
 }
+function legacyReportNotice(name) {
+  return {
+    kind: "legacy-report-format",
+    path: name,
+    message: `${name} is stored as a single report.json (PBIR-Legacy), which pbiplint cannot read. Power BI Desktop converts it to PBIR when you edit and save it, in releases from September 2026 on. See Microsoft Learn: ${CONVERT_TO_PBIR_URL}`
+  };
+}
+function legacyModelNotice(name) {
+  return {
+    kind: "legacy-model-format",
+    path: name,
+    message: `${name} is stored as model.bim, which pbiplint cannot read; save it in the TMDL format from Power BI Desktop`
+  };
+}
+var LEGACY_REPORT_REASON = "the report is saved in the legacy report.json format";
+var LEGACY_MODEL_REASON = "the model is saved in the legacy model.bim format";
 var listOf2 = (items) => items.length <= 2 ? items.join(" and ") : `${items.slice(0, -1).join(", ")}, and ${items.at(-1)}`;
 var TMDL_ONLY = "Only a model stored as TMDL can be linted; if it is in the older model.bim format, save it in the TMDL format from Power BI Desktop first.";
 var holdNoTmdl = (folders) => `${listOf2(folders)} hold${folders.length === 1 ? "s" : ""} no .tmdl files`;
@@ -2314,7 +2507,8 @@ function datasetReference(pbirText) {
 function pairingDecision(ref, siblingModelFolder, reportFolder) {
   if (ref.kind === "byConnection")
     return { useModel: false, reason: "this report reads a published model" };
-  if (siblingModelFolder === void 0) return { useModel: false };
+  if (siblingModelFolder === void 0)
+    return ref.kind === "byPath" && ref.path.trim() !== "" ? { useModel: false, reason: `this report reads ${ref.path}, which this run did not include` } : { useModel: false };
   if (ref.kind === "none") return { useModel: true };
   const named2 = ref.path.replace(/\\/g, "/").replace(/\/+$/, "").split("/").pop() ?? "";
   if (named2.toLowerCase() === siblingModelFolder.toLowerCase()) return { useModel: true };
@@ -3133,11 +3327,12 @@ var RULE_SUMMARIES = {
   FIRST_LETTER_OF_OBJECTS_MUST_BE_CAPITALIZED: "Tables, measures, hierarchies, calculated columns, calculated tables, and calculation groups whose first character has an upper case form and is not upper case.",
   FIX_REFERENTIAL_INTEGRITY_VIOLATIONS: "Relationships where the many side holds key values that do not exist on the one side. The count of offending rows is a statistic of the loaded data, not of the model files, so pbiplint lists this rule but does not run it: it needs statistics that only a live model carries.",
   "FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS": "Visible columns whose name starts with Is and whose type is whole number, and visible columns whose name ends with the word Flag after a space and whose type is not text.",
+  HARDCODED_PERIOD_IN_DAX: "Measures, calculated columns, and calculation items whose DAX fixes a year or a date, and date tables whose CALENDAR ends on a fixed date.",
   HIDDEN_VISUAL_WITH_FIELDS: "Visuals hidden in the Selection pane, with their own eye icon or with that of a group they sit in, that still have fields in their wells.",
   HIDE_FACT_TABLE_COLUMNS: "Visible numeric columns that a measure aggregates directly with a fully qualified reference, such as `SUM('Sales'[Amount])`. COUNT, COUNTBLANK, SUM, AVERAGE, MIN, MAX, DISTINCTCOUNT, VALUES, DISTINCT, and the A-suffixed COUNTA, AVERAGEA, MAXA, and MINA count as aggregations.",
   HIDE_FOREIGN_KEYS: "Visible columns whose name matches the from column of a relationship whose from side is many. Only the from cardinality is tested, so a many-to-many relationship counts here too, not just many-to-one.",
   HIDE_TOOLTIP_DRILLTROUGH_PAGES: "Tooltip pages and drillthrough pages that are not hidden.",
-  INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED: "Inactive relationships that no measure or calculation item activates with USERELATIONSHIP.",
+  INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED: "Inactive relationships that no measure, calculation item, or user-defined function activates with USERELATIONSHIP.",
   INTEGER_FORMATTING: "Measures whose static format string is not a recognized whole-number, currency, or percentage format. The only format strings the rule accepts are `#,0`, `#,0.0`, and any string containing `$` or `%`. A measure with no format string at all fires too, and that is the common case: the rule reads only the format string, so it cannot tell an unformatted currency or ratio from an unformatted count.",
   ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS: "Hidden columns, or columns in hidden tables, that still have IsAvailableInMdx set to true and are not used to sort another column, in a hierarchy, or in a variation, and do not themselves sort by another column.",
   LANDING_PAGE_NOT_SET: "A report whose pages.json sets no landing page, so it opens on the page that was active when it was last saved, or, when pages.json records no active page either, on the first page.",
@@ -3152,12 +3347,12 @@ var RULE_SUMMARIES = {
   MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS: "Models that have at least one DirectQuery table, no aggregation table (no column has an alternateOf mapping), and the PowerBI_V3 data source version, which is every project Desktop writes today.",
   "MONTH_(AS_A_STRING)_MUST_BE_SORTED": "Text columns with month in the name, but not months, that have no sort-by column.",
   MONTHCOLUMN_FORMATSTRING: "DateTime columns with month in the name whose format string is not exactly `MMMM yyyy`.",
-  NOT_REACHED_FROM_REPORT: "Columns and measures that nothing in the report reaches, directly or through the model. The walk starts from every field the report names, both columns of every relationship except one to an auto date/time table, the columns that row-level and object-level security name, the default column of every variation, the columns of an aggregation table (the ones with an `alternateOf` mapping), and the fields the report's own measures reference, and it follows DAX references, sort-by and group-by columns, the detail column or table each mapping names, and calculated tables until nothing new is reached.",
+  NOT_REACHED_FROM_REPORT: "Columns and measures that nothing in the report reaches, directly or through the model. The walk starts from every field the report names, both columns of every relationship except one to an auto date/time table, the columns and measures that row-level security filters name, the columns that object-level security names, the default column of every variation, the columns of an aggregation table (the ones with an `alternateOf` mapping), the fields the report's own measures reference, and the user-defined functions those measures and the security filters call, and it follows DAX references, calls to user-defined functions, sort-by and group-by columns, the detail column or table each mapping names, and calculated tables until nothing new is reached.",
   NUMERIC_COLUMN_SUMMARIZE_BY: "Visible whole number, decimal, or double columns whose default summarization is anything other than None.",
   OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE: "Names that start or end with a space, for the model, tables, measures, hierarchies, perspectives, partitions, data columns, and calculated columns.",
   OBJECTS_WITH_NO_DESCRIPTION: "Visible tables, columns, measures, and calculation groups with no description. Visibility is the object's own flag.",
   OPENING_PAGE_INVALID: "A pages.json whose landing page names a page the report does not have, or, when no landing page is set, whose active page names a page the report does not have or a page hidden from readers.",
-  PARSE_ISSUE: "Lines the TMDL parser could not use: space indentation, an unterminated code fence, a line at an impossible indentation, a line in no form the parser recognizes, a line at the root of a file that TMDL does not allow there (a misspelt `table`, a `column` or a property that lost its tabs, or an annotation with lines under it, for example), and a `///` description with a blank line between it and its declaration; a report JSON file that is not valid JSON or carries a merge conflict marker; and a report file Microsoft publishes a schema for, such as report.json or a page.json, whose content is not a JSON object.",
+  PARSE_ISSUE: "Lines the TMDL parser could not use: space indentation, an unterminated code fence, a line at an impossible indentation, a line in no form the parser recognizes, a line at the root of a file that TMDL does not allow there (a misspelt `table`, a `column` or a property that lost its tabs, or an annotation with lines under it, for example), much the same directly under a model, where TMDL lets the model's tables, relationships, and other objects sit indented (a property that lost its tabs is reported there only when lines sit under it, and a flag such as `isHidden` only when a declaration does, since the model has properties and flags of its own), a declaration under a database other than its model, a `table` line under anything but a model, which a stray tab puts under the declaration above it, a declaration such as `table` or `role` written with no name, a name not enclosed in single quotes as TMDL requires, such as `table 'Date`, and a `///` description with a blank line between it and its declaration; a report JSON file that is not valid JSON, carries a merge conflict marker, or nests more than 256 levels deep; and a report file Microsoft publishes a schema for, such as report.json or a page.json, whose content is not a JSON object.",
   PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES: "Regular tables with exactly one partition whose name differs from the table name. Calculated tables and calculation groups are not checked.",
   PERCENTAGE_FORMATTING: "Measures with a percent format string other than `#,0.0%;-#,0.0%;#,0.0%`.",
   PERSPECTIVES_WITH_NO_OBJECTS: "Perspectives that contain no tables. The rule reads only a perspective's table entries, which is enough: each column, measure, and hierarchy a perspective includes sits under the entry for its table, so with no table entry it includes nothing.",
@@ -3187,7 +3382,7 @@ var RULE_SUMMARIES = {
   SPLIT_DATE_AND_TIME: "DateTime columns holding values that are not at midnight. Whether any row carries a time is a statistic of the loaded data, not of the model files, so pbiplint lists this rule but does not run it: it needs statistics that only a live model carries.",
   TAB_ORDER_FOLLOWS_LAYOUT: "Pages whose tab order, the order keyboard users move through the visuals in, disagrees with the order the layout reads in: rows from top to bottom, and left to right within a row. The rule checks this only when the project's policy asks for tab order to follow the layout, and reports nothing without it.",
   TRIM_OBJECT_NAMES: "Names that start or end with a space, across every named object type in the model.",
-  UNNECESSARY_COLUMNS: "Hidden columns, or columns in hidden tables, that nothing references: no DAX expression, relationship, hierarchy, sort-by column, row-level security filter, or object-level security rule.",
+  UNNECESSARY_COLUMNS: "Hidden columns, or columns in hidden tables, that nothing references: no DAX expression, relationship, hierarchy, sort-by column, group-by column, row-level security filter, or object-level security rule.",
   UNNECESSARY_MEASURES: "Hidden measures, or measures on hidden tables, that no DAX expression references.",
   "UNPIVOT_PIVOTED_(MONTH)_DATA": "Tables that have a numeric column for each of Jan, Feb, Mar, Apr, May, and Jun, matched as substrings of the column names.",
   USE_THE_DIVIDE_FUNCTION_FOR_DIVISION: "Expressions that use the division operator right after a closing bracket or parenthesis, such as `[Sales] / [Cost]` or `SUM(...) / SUM(...)`. A slash that starts a comment is ignored.",
@@ -3238,7 +3433,8 @@ var stripCategory = (name) => name.replace(/^\[[^\]]*\]\s*/, "");
 var extractUrls = (text2) => [
   ...new Set((text2.match(/https?:\/\/[^\s)"]+/g) ?? []).map((u) => u.replace(/[.,]$/, "")))
 ];
-function bpaRule(id, check) {
+function bpaRule(id, ...args) {
+  const [{ skipWhenModelUnread }, check] = args.length === 1 ? [{}, args[0]] : args;
   const meta = metaOf(id);
   return {
     id,
@@ -3248,6 +3444,7 @@ function bpaRule(id, check) {
     scope: mapScope(meta.scope),
     layer: "model",
     needs: ["model"],
+    ...skipWhenModelUnread ? { skipWhenModelUnread } : {},
     description: RULE_SUMMARIES[id] ?? stripCategory(meta.name),
     fixExpression: meta.fixExpression,
     references: extractUrls(meta.description),
@@ -3297,6 +3494,7 @@ var MONTH_AS_A_STRING_MUST_BE_SORTED = bpaRule(
 );
 var NUMERIC_COLUMN_SUMMARIZE_BY = bpaRule(
   "NUMERIC_COLUMN_SUMMARIZE_BY",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m) => columns(
     m,
     (c) => isNumericType(c) && (c.summarizeBy ?? "default").toLowerCase() !== "none" && !hiddenOrTableHidden(c)
@@ -3304,6 +3502,7 @@ var NUMERIC_COLUMN_SUMMARIZE_BY = bpaRule(
 );
 var FORMAT_FLAG_COLUMNS_AS_YES_NO_VALUE_STRINGS = bpaRule(
   "FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m) => columns(
     m,
     (c) => !hiddenOrTableHidden(c) && (c.name.startsWith("Is") && dataType(c) === "int64" || c.name.endsWith(" Flag") && dataType(c) !== "string")
@@ -3311,10 +3510,12 @@ var FORMAT_FLAG_COLUMNS_AS_YES_NO_VALUE_STRINGS = bpaRule(
 );
 var DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN = bpaRule(
   "DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m) => columns(m, (c) => c.kind === "data" && isBlank(c.sourceColumn))
 );
 var ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS = bpaRule(
   "ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS",
+  { skipWhenModelUnread: modelPartlyRead },
   (m, { indexes: { usage } }) => columns(
     m,
     (c) => c.isAvailableInMdx && hiddenOrTableHidden(c) && !usage.usedInSortBy(c) && !usage.usedInHierarchies(c) && !usage.usedInVariations(c) && c.sortByColumn === void 0
@@ -3327,33 +3528,38 @@ var SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS = bpaRule(
     (c) => !c.isAvailableInMdx && (usage.usedInSortBy(c) || usage.usedInHierarchies(c) || usage.usedInVariations(c) || c.sortByColumn !== void 0)
   )
 );
-var UNNECESSARY_COLUMNS = bpaRule("UNNECESSARY_COLUMNS", (m, { indexes }) => {
-  const permissions = allTablePermissions(m);
-  return columns(m, (c) => {
-    if (!hiddenOrTableHidden(c)) return false;
-    if (indexes.references.columnReferencedBy(c).length > 0) return false;
-    if (indexes.relationships.forColumn(c.table.name, c.name).length > 0) return false;
-    if (indexes.usage.usedInSortBy(c) || indexes.usage.usedInHierarchies(c)) return false;
-    const bare = `[${c.name}]`.toLowerCase();
-    const qualified = [
-      `${c.table.name}[${c.name}]`.toLowerCase(),
-      `'${c.table.name}'[${c.name}]`.toLowerCase()
-    ];
-    for (const tp of permissions) {
-      const f = tp.filter?.toLowerCase();
-      if (f === void 0) continue;
-      if (tp.table === c.table.name && f.includes(bare)) return false;
-      if (qualified.some((q2) => f.includes(q2))) return false;
-    }
-    for (const tp of permissions) {
-      if (tp.table !== c.table.name) continue;
-      if (tp.metadataPermission === "none") return false;
-      if (tp.columnPermissions.some((cp) => cp.column === c.name && cp.permission === "none"))
-        return false;
-    }
-    return true;
-  });
-});
+var UNNECESSARY_COLUMNS = bpaRule(
+  "UNNECESSARY_COLUMNS",
+  { skipWhenModelUnread: modelPartlyRead },
+  (m, { indexes }) => {
+    const permissions = allTablePermissions(m);
+    return columns(m, (c) => {
+      if (!hiddenOrTableHidden(c)) return false;
+      if (indexes.references.columnReferencedBy(c).length > 0) return false;
+      if (indexes.relationships.forColumn(c.table.name, c.name).length > 0) return false;
+      if (indexes.usage.usedInSortBy(c) || indexes.usage.usedInHierarchies(c)) return false;
+      if (indexes.usage.usedInGroupBy(c)) return false;
+      const bare = `[${c.name}]`.toLowerCase();
+      const qualified = [
+        `${c.table.name}[${c.name}]`.toLowerCase(),
+        `'${c.table.name}'[${c.name}]`.toLowerCase()
+      ];
+      for (const tp of permissions) {
+        const f = tp.filter?.toLowerCase();
+        if (f === void 0) continue;
+        if (tp.table === c.table.name && f.includes(bare)) return false;
+        if (qualified.some((q2) => f.includes(q2))) return false;
+      }
+      for (const tp of permissions) {
+        if (tp.table !== c.table.name) continue;
+        if (tp.metadataPermission === "none") return false;
+        if (tp.columnPermissions.some((cp) => cp.column === c.name && cp.permission === "none"))
+          return false;
+      }
+      return true;
+    });
+  }
+);
 var AGGREGATIONS = [
   "COUNT",
   "COUNTBLANK",
@@ -3374,7 +3580,7 @@ var HIDE_FACT_TABLE_COLUMNS = bpaRule("HIDE_FACT_TABLE_COLUMNS", (m) => {
   return columns(m, (c) => {
     if (c.isHidden || !isNumericType(c)) return false;
     const re = new RegExp(
-      `(?:${AGGREGATIONS.join("|")})\\s*\\(\\s*'*${escapeRegExp(c.table.name)}'*\\[${escapeRegExp(c.name)}\\]\\s*\\)`,
+      `(?:${AGGREGATIONS.join("|")})\\s*\\(\\s*'*${escapeRegExp2(c.table.name)}'*\\[${escapeRegExp2(c.name)}\\]\\s*\\)`,
       "i"
     );
     return measures.some((x) => re.test(x.expression));
@@ -3396,6 +3602,7 @@ var columnRules = [
 ];
 
 // ../core/src/rules/microsoft-bpa/dependencies.ts
+var isRuleOwner = (o) => o.kind !== "function";
 function ownerFinding(o) {
   switch (o.kind) {
     case "measure":
@@ -3412,13 +3619,14 @@ function ownerFinding(o) {
 }
 var DAX_COLUMNS_FULLY_QUALIFIED = bpaRule(
   "DAX_COLUMNS_FULLY_QUALIFIED",
-  (_m, { indexes: { references } }) => references.owners.filter(
+  { skipWhenModelUnread: modelPartlyRead },
+  (_m, { indexes: { references } }) => references.owners.filter(isRuleOwner).filter(
     (o) => (o.kind === "measure" || o.kind === "tablePermission" || o.kind === "calculationItem") && o.refs.some((r) => r.kind === "column" && !r.qualified)
   ).map(ownerFinding)
 );
 var DAX_MEASURES_UNQUALIFIED = bpaRule(
   "DAX_MEASURES_UNQUALIFIED",
-  (_m, { indexes: { references } }) => references.owners.filter(
+  (_m, { indexes: { references } }) => references.owners.filter(isRuleOwner).filter(
     (o) => o.kind !== "tablePermission" && o.refs.some((r) => r.kind === "measure" && r.qualified)
   ).map(ownerFinding)
 );
@@ -3442,6 +3650,7 @@ var MEASURES_SHOULD_NOT_BE_DIRECT_REFERENCES_OF_OTHER_MEASURES = bpaRule(
 );
 var UNNECESSARY_MEASURES = bpaRule(
   "UNNECESSARY_MEASURES",
+  { skipWhenModelUnread: modelPartlyRead },
   (m, { indexes: { references } }) => allMeasures(m).filter(
     (x) => (x.table.isHidden || x.isHidden) && references.measureReferencedBy(x).length === 0
   ).map(finding.measure)
@@ -3473,6 +3682,7 @@ var patternRule = (id, kinds, patterns) => bpaRule(
 );
 var PROVIDE_FORMAT_STRING_FOR_MEASURES = bpaRule(
   "PROVIDE_FORMAT_STRING_FOR_MEASURES",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m) => allMeasures(m).filter(
     (x) => !x.isHidden && !x.table.isHidden && isBlank(x.formatString) && isBlank(x.formatStringDefinition)
   ).map(finding.measure)
@@ -3564,15 +3774,17 @@ var measureRules = [
 ];
 
 // ../core/src/rules/microsoft-bpa/naming.ts
-var namedObjectRule = (id, test) => bpaRule(
+var namedObjectRule = (id, test, spec = {}) => bpaRule(
   id,
+  spec,
   (m) => namedObjects(m, mapScope(metaOf(id).scope)).filter((o) => test(o.name, o.description)).map((o) => o.finding)
 );
 var startsOrEndsWithSpace = (name) => name.startsWith(" ") || name.endsWith(" ");
 var TRIM_OBJECT_NAMES = namedObjectRule("TRIM_OBJECT_NAMES", startsOrEndsWithSpace);
 var OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE = namedObjectRule(
   "OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE",
-  startsOrEndsWithSpace
+  startsOrEndsWithSpace,
+  { skipWhenModelUnread: tablesPartlyRead }
 );
 var SPECIAL_CHARS_IN_OBJECT_NAMES = namedObjectRule(
   "SPECIAL_CHARS_IN_OBJECT_NAMES",
@@ -3597,6 +3809,7 @@ var PERSPECTIVES_WITH_NO_OBJECTS = bpaRule(
 );
 var CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS = bpaRule(
   "CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m) => m.tables.filter((t) => t.calculationGroup !== void 0 && t.calculationGroup.items.length === 0).map(finding.table)
 );
 var REMOVE_ROLES_WITH_NO_MEMBERS = bpaRule(
@@ -3605,6 +3818,7 @@ var REMOVE_ROLES_WITH_NO_MEMBERS = bpaRule(
 );
 var REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS = bpaRule(
   "REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS",
+  { skipWhenModelUnread: modelPartlyRead },
   (m) => {
     const partitions = allPartitions(m);
     return m.dataSources.filter(
@@ -3649,6 +3863,7 @@ var HIDE_FOREIGN_KEYS = bpaRule(
 );
 var MARK_PRIMARY_KEYS = bpaRule(
   "MARK_PRIMARY_KEYS",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m, { indexes: { relationships } }) => allColumns(m).filter(
     (c) => !c.isKey && c.table.dataCategory !== "Time" && relationships.forColumn(c.table.name, c.name).some(
       (r) => r.toTable === c.table.name && r.toColumn === c.name && r.toCardinality === "one"
@@ -3657,6 +3872,7 @@ var MARK_PRIMARY_KEYS = bpaRule(
 );
 var REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES = bpaRule(
   "REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES",
+  { skipWhenModelUnread: modelPartlyRead },
   (m, { indexes: { relationships } }) => {
     const all = allColumns(m);
     return all.filter(
@@ -3675,6 +3891,7 @@ var SNOWFLAKE_SCHEMA_ARCHITECTURE = bpaRule(
 );
 var ENSURE_TABLES_HAVE_RELATIONSHIPS = bpaRule(
   "ENSURE_TABLES_HAVE_RELATIONSHIPS",
+  { skipWhenModelUnread: modelPartlyRead },
   (m, { indexes: { relationships } }) => tablesInScope(m).filter((t) => relationships.forTable(t.name).length === 0).map(finding.table)
 );
 var MANY_TO_MANY_RELATIONSHIPS_SHOULD_BE_SINGLE_DIRECTION = bpaRule(
@@ -3698,15 +3915,17 @@ var RELATIONSHIP_COLUMNS_SAME_DATA_TYPE = bpaRule(
 );
 var INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED = bpaRule(
   "INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED",
+  { skipWhenModelUnread: modelPartlyRead },
   (m) => {
     const expressions = [
       ...allMeasures(m).map((x) => x.expression),
-      ...allCalculationItems(m).map((i) => i.expression)
+      ...allCalculationItems(m).map((i) => i.expression),
+      ...m.functions.map((f) => f.expression)
     ];
     return m.relationships.filter((r) => {
       if (r.isActive) return false;
       const re = new RegExp(
-        `USERELATIONSHIP\\s*\\(\\s*'*${escapeRegExp(r.fromTable)}'*\\[${escapeRegExp(r.fromColumn)}\\]\\s*,\\s*'*${escapeRegExp(r.toTable)}'*\\[${escapeRegExp(r.toColumn)}\\]`,
+        `USERELATIONSHIP\\s*\\(\\s*'*${escapeRegExp2(r.fromTable)}'*\\[${escapeRegExp2(r.fromColumn)}\\]\\s*,\\s*'*${escapeRegExp2(r.toTable)}'*\\[${escapeRegExp2(r.toColumn)}\\]`,
         "i"
       );
       return !expressions.some((e) => re.test(e));
@@ -3715,6 +3934,7 @@ var INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED = bpaRule(
 );
 var AVOID_EXCESSIVE_BIDIRECTIONAL_OR_MANY_TO_MANY_RELATIONSHIPS = bpaRule(
   "AVOID_EXCESSIVE_BI-DIRECTIONAL_OR_MANY-TO-MANY_RELATIONSHIPS",
+  { skipWhenModelUnread: modelPartlyRead },
   (m) => {
     const rels = m.relationships;
     const count = rels.filter(isBidirectional).length + rels.filter(isManyToMany).length;
@@ -3723,6 +3943,7 @@ var AVOID_EXCESSIVE_BIDIRECTIONAL_OR_MANY_TO_MANY_RELATIONSHIPS = bpaRule(
 );
 var AVOID_USING_MANY_TO_MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY = bpaRule(
   "AVOID_USING_MANY-TO-MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m, { indexes: { relationships } }) => {
     const permissions = allTablePermissions(m);
     return m.tables.filter(
@@ -3749,10 +3970,12 @@ var relationshipRules = [
 var hasDateTimeKey = (t) => t.columns.some((c) => c.isKey && dataType(c) === "datetime");
 var MODEL_SHOULD_HAVE_A_DATE_TABLE = bpaRule(
   "MODEL_SHOULD_HAVE_A_DATE_TABLE",
+  { skipWhenModelUnread: modelPartlyRead },
   (m) => m.tables.some((t) => t.dataCategory === "Time" && hasDateTimeKey(t)) ? [] : [finding.model(m)]
 );
 var DATE_CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE = bpaRule(
   "DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m) => tablesInScope(m).filter((t) => {
     const u = t.name.toUpperCase();
     return (u.includes("DATE") || u.includes("CALENDAR")) && (t.dataCategory !== "Time" || !hasDateTimeKey(t));
@@ -3781,6 +4004,7 @@ var UNPIVOT_PIVOTED_MONTH_DATA = bpaRule(
 );
 var PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES = bpaRule(
   "PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m) => m.tables.filter(
     (t) => t.kind === "table" && t.partitions.length === 1 && t.partitions[0].name !== t.name
   ).map(finding.table)
@@ -3809,6 +4033,7 @@ var MINIMIZE_POWER_QUERY_TRANSFORMATIONS = bpaRule(
 );
 var MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS = bpaRule(
   "MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS",
+  { skipWhenModelUnread: modelPartlyRead },
   (m) => m.tables.some(isDirectQueryTable) && !allColumns(m).some((c) => c.hasAlternateOf) && String(m.props.defaultpowerbidatasourceversion ?? "").toLowerCase() === "powerbi_v3" ? [finding.model(m)] : []
 );
 var TIME_INTELLIGENCE_FUNCTIONS = [
@@ -3853,6 +4078,7 @@ var TIME_INTELLIGENCE_FUNCTIONS = [
 var TIME_INTELLIGENCE = new RegExp(`(?:${TIME_INTELLIGENCE_FUNCTIONS.join("|")})\\s*\\(`);
 var MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY = bpaRule(
   "MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY",
+  { skipWhenModelUnread: modelPartlyRead },
   (m) => m.tables.some(isDirectQueryTable) ? expressionObjects(m, ["measure", "calculationItem"]).filter((o) => TIME_INTELLIGENCE.test(o.expression)).map((o) => o.finding) : []
 );
 var RLS_FUNCTIONS = [/RIGHT\s*\(/i, /LEFT\s*\(/i, /UPPER\s*\(/i, /LOWER\s*\(/i, /FIND\s*\(/i];
@@ -3881,7 +4107,7 @@ var AVOID_THE_USERELATIONSHIP_FUNCTION_AND_RLS_AGAINST_THE_SAME_TABLE = bpaRule(
     return tablesInScope(m).filter((t) => {
       if (!permissions.some((tp) => tp.table === t.name && tp.filter !== void 0)) return false;
       const re = new RegExp(
-        `USERELATIONSHIP\\s*\\(\\s*.+?(?=\\])\\]\\s*,\\s*'*${escapeRegExp(t.name)}'*\\[`,
+        `USERELATIONSHIP\\s*\\(\\s*.+?(?=\\])\\]\\s*,\\s*'*${escapeRegExp2(t.name)}'*\\[`,
         "i"
       );
       return measures.some((x) => re.test(x.expression));
@@ -3890,6 +4116,7 @@ var AVOID_THE_USERELATIONSHIP_FUNCTION_AND_RLS_AGAINST_THE_SAME_TABLE = bpaRule(
 );
 var OBJECTS_WITH_NO_DESCRIPTION = bpaRule(
   "OBJECTS_WITH_NO_DESCRIPTION",
+  { skipWhenModelUnread: tablesPartlyRead },
   (m) => m.tables.flatMap((t) => [
     ...isBlank(t.description) && !t.isHidden ? [finding.table(t)] : [],
     ...t.columns.filter((c) => isBlank(c.description) && !c.isHidden).map(finding.column),
@@ -4482,6 +4709,546 @@ var DEFAULT_PAGE_NAME = pbiplintRule({
 });
 var pageRules2 = [DEFAULT_PAGE_NAME];
 
+// ../core/src/dax/tokenize.ts
+var OPERATORS = ["==", "<>", "<=", ">=", "&&", "||", "=", "<", ">", "+", "-", "*", "/", "^", "&"];
+var NUMBER = /(?:\d+(?:\.\d*)?|\.\d+)(?:[eE][+-]?\d+)?/y;
+var IDENTIFIER = /[\p{L}_][\p{L}\p{M}\p{N}_.]*/uy;
+var WORD_CHAR = /[\p{L}\p{M}\p{N}_]/u;
+var DIGIT = /[0-9]/;
+var isWord = (t, word) => t?.kind === "identifier" && t.text.toUpperCase() === word;
+var isPunctuation = (t, char) => t?.kind === "punctuation" && t.text === char;
+function quoted2(text2, from, close) {
+  let value = "";
+  let j = from + 1;
+  while (j < text2.length) {
+    const c = text2[j];
+    if (c === close) {
+      if (text2[j + 1] !== close) return { value, end: j + 1 };
+      j++;
+    }
+    value += c;
+    j++;
+  }
+  return { value, end: text2.length };
+}
+function tokenizeDax(expression) {
+  const s = expression;
+  const tokens = [];
+  const push2 = (kind, text2, start, end) => {
+    tokens.push({ kind, text: text2, start, end, depth: 0 });
+  };
+  let i = 0;
+  while (i < s.length) {
+    const c = s[i];
+    if (/\s/.test(c)) {
+      i++;
+    } else if (s.startsWith("//", i) || s.startsWith("--", i)) {
+      const nl = s.indexOf("\n", i);
+      i = nl === -1 ? s.length : nl;
+    } else if (s.startsWith("/*", i)) {
+      const close = s.indexOf("*/", i + 2);
+      i = close === -1 ? s.length : close + 2;
+    } else if (c === '"') {
+      const q2 = quoted2(s, i, '"');
+      push2("string", q2.value, i, q2.end);
+      i = q2.end;
+    } else if ((c === "d" || c === "D") && (s[i + 1] === "t" || s[i + 1] === "T") && s[i + 2] === '"' && !(i > 0 && WORD_CHAR.test(s[i - 1]))) {
+      const q2 = quoted2(s, i + 2, '"');
+      push2("date", q2.value, i, q2.end);
+      i = q2.end;
+    } else if (c === "'" || c === "[") {
+      const q2 = quoted2(s, i, c === "'" ? "'" : "]");
+      push2(c === "'" ? "table" : "column", q2.value, i, q2.end);
+      i = q2.end;
+    } else if (DIGIT.test(c) || c === "." && DIGIT.test(s[i + 1] ?? "")) {
+      NUMBER.lastIndex = i;
+      const text2 = NUMBER.exec(s)[0];
+      push2("number", text2, i, i + text2.length);
+      i += text2.length;
+    } else {
+      IDENTIFIER.lastIndex = i;
+      const id = IDENTIFIER.exec(s)?.[0];
+      const op = id === void 0 ? OPERATORS.find((o) => s.startsWith(o, i)) : void 0;
+      const text2 = id ?? op ?? c;
+      push2(
+        id !== void 0 ? "identifier" : op !== void 0 ? "operator" : "punctuation",
+        text2,
+        i,
+        i + text2.length
+      );
+      i += text2.length;
+    }
+  }
+  annotate(tokens);
+  return tokens;
+}
+function annotate(tokens) {
+  const open = [];
+  const args = [];
+  const place = (t) => {
+    t.depth = open.length;
+    if (open.length === 0) return;
+    t.parent = open[open.length - 1];
+    t.arg = args[args.length - 1];
+  };
+  tokens.forEach((t, k) => {
+    if (isPunctuation(t, "(") || isPunctuation(t, "{")) {
+      place(t);
+      const before = tokens[k - 1];
+      if (t.text === "(" && before?.kind === "identifier") t.call = before.text.toUpperCase();
+      open.push(k);
+      args.push(0);
+    } else if (isPunctuation(t, ")") || isPunctuation(t, "}")) {
+      const o = open.pop();
+      args.pop();
+      if (o !== void 0) {
+        tokens[o].close = k;
+        t.open = o;
+      }
+      place(t);
+    } else {
+      place(t);
+      if (isPunctuation(t, ",") && args.length > 0) args[args.length - 1] = args.at(-1) + 1;
+    }
+  });
+}
+function opensBlock(tokens, k) {
+  if (isWord(tokens[k - 1], "RETURN")) return true;
+  const eq = tokens[k - 1];
+  return isWord(tokens[k - 3], "VAR") && tokens[k - 2]?.kind === "identifier" && eq?.kind === "operator" && eq.text === "=";
+}
+function daxVariables(tokens) {
+  const out = [];
+  tokens.forEach((t, k) => {
+    const name = tokens[k + 1];
+    const eq = tokens[k + 2];
+    if (!isWord(t, "VAR") || name?.kind !== "identifier" || eq?.kind !== "operator") return;
+    if (eq.text !== "=") return;
+    const from = k + 3;
+    let to = from;
+    let nested = 0;
+    for (; to < tokens.length; to++) {
+      const x = tokens[to];
+      if (x.depth < t.depth) break;
+      if (x.depth !== t.depth) continue;
+      if (isWord(x, "VAR")) {
+        if (opensBlock(tokens, to)) nested++;
+        else if (nested === 0) break;
+      } else if (isWord(x, "RETURN")) {
+        if (nested === 0) break;
+        nested--;
+      }
+    }
+    let blockEnd2 = to;
+    for (; blockEnd2 < tokens.length; blockEnd2++) {
+      const x = tokens[blockEnd2];
+      if (x.depth < t.depth || x.depth === t.depth && isPunctuation(x, ",")) break;
+    }
+    out.push({ name: name.text, at: k, from, to, blockEnd: blockEnd2 });
+  });
+  for (const v of out)
+    for (const d of out) if (d.from <= v.at && v.at < d.to && d.to < v.blockEnd) v.blockEnd = d.to;
+  return out;
+}
+function variableAt(vars, name, use) {
+  const key4 = name.toUpperCase();
+  let found;
+  for (const v of vars)
+    if (v.name.toUpperCase() === key4 && v.at < use && use < v.blockEnd && !(v.from <= use && use < v.to))
+      found = v;
+  return found;
+}
+
+// ../core/src/rules/pbiplint/period-words.ts
+var YEAR_WORDS = /* @__PURE__ */ new Set([
+  "year",
+  "years",
+  "yr",
+  "yrs",
+  "a\xF1o",
+  "a\xF1os",
+  "ano",
+  "anos",
+  "anio",
+  "jahr",
+  "ann\xE9e",
+  "annee",
+  "anno",
+  "jaar",
+  "\xE5r",
+  "rok",
+  "vuosi",
+  "ejercicio",
+  "exercice",
+  "fy",
+  "ay",
+  "cy",
+  "ly",
+  "py",
+  "yyyy",
+  "y"
+]);
+var MONTH_WORDS = /* @__PURE__ */ new Set([
+  "month",
+  "months",
+  "mes",
+  "m\xEAs",
+  "meses",
+  "monat",
+  "mois",
+  "mese",
+  "maand",
+  "mm",
+  "mon",
+  "mth",
+  "period",
+  "periodo",
+  "per\xEDodo"
+]);
+var QUARTER_WORDS = /* @__PURE__ */ new Set(["quarter", "qtr", "q", "trimestre", "quartal", "kwartaal"]);
+var COUNT_WORDS = /* @__PURE__ */ new Set(["of", "service", "experience", "at", "in", "since", "tenure", "old"]);
+function nameWords(name) {
+  return name.normalize("NFC").replace(new RegExp("(\\p{Ll})(\\p{Lu})", "gu"), "$1 $2").replace(new RegExp("(\\p{L})(\\p{N})", "gu"), "$1 $2").split(/[^\p{L}\p{M}\p{N}]+/u).filter((w) => w !== "").map((w) => w.toLowerCase());
+}
+function nameClass(name) {
+  const words = nameWords(name);
+  const low = name.toLowerCase();
+  const squeezed = low.replace(/ /g, "");
+  const year = words.some(
+    (w) => YEAR_WORDS.has(w) || w.startsWith("year") || w.endsWith("year") && w.length > 4
+  );
+  const month = words.some((w) => MONTH_WORDS.has(w) || w.startsWith("month"));
+  const quarter = words.some((w) => QUARTER_WORDS.has(w) || w.startsWith("quarter"));
+  if (year && (month || quarter || squeezed.includes("yearmonth") || squeezed.includes("yearqtr")))
+    return "yearKey";
+  if (year && words.includes("years") && words.some((w) => COUNT_WORDS.has(w))) return "yearCount";
+  if (year) return "year";
+  if (low.includes("yyyymm") || squeezed.includes("yearmonth") || low.includes("periodkey") || low.includes("monthkey"))
+    return "yearKey";
+  if (month) return "month";
+  if (quarter) return "quarter";
+  return void 0;
+}
+
+// ../core/src/rules/pbiplint/period-forms.ts
+var FIRST_YEAR = 1950;
+var LAST_YEAR = 2049;
+var COMPARISONS = /* @__PURE__ */ new Set(["=", "==", "<>"]);
+var WRAPPERS = /* @__PURE__ */ new Set([
+  "SELECTEDVALUE",
+  "MAX",
+  "MIN",
+  "VALUES",
+  "DISTINCT",
+  "FIRSTNONBLANK",
+  "LASTNONBLANK",
+  "MAXX",
+  "MINX",
+  "LOOKUPVALUE",
+  "RELATED",
+  "CALCULATE",
+  "HASONEVALUE",
+  "SUM",
+  "AVERAGE",
+  "CONVERT",
+  "INT",
+  "VALUE",
+  "FORMAT"
+]);
+var BOUNDS = /* @__PURE__ */ new Set(["CALENDAR", "GENERATESERIES"]);
+var YEAR_FORMATS = /* @__PURE__ */ new Set(["general date", "long date", "medium date", "short date"]);
+var UNIX_EPOCH = { year: 1970, month: 1, day: 1 };
+var STRING_DATES = /* @__PURE__ */ new Set(["DATEVALUE", "DATETIMEVALUE", "VALUE"]);
+var YEAR_FIRST = /^(\d{4})([-/])(\d{1,2})\2(\d{1,2})(?:[ T]\d{1,2}:\d{2}.*)?$/;
+var YEAR_LAST = /^(\d{1,2})[-/.](\d{1,2})[-/.](\d{4})(?:[ T]\d{1,2}:\d{2}.*)?$/;
+var isWhole = (t) => t?.kind === "number" && /^\d+$/.test(t.text);
+function yearIn(t, strings) {
+  const text2 = t?.kind === "number" ? t.text : strings && t?.kind === "string" ? t.text.trim() : void 0;
+  if (text2 === void 0 || !/^\d{4}$/.test(text2)) return void 0;
+  const year = Number(text2);
+  return year >= FIRST_YEAR && year <= LAST_YEAR ? year : void 0;
+}
+function argumentsOf(tokens, open) {
+  const end = tokens[open]?.close ?? tokens.length;
+  const spans = [];
+  let from = open + 1;
+  for (let k = open + 1; k < end; k++)
+    if (tokens[k].parent === open && isPunctuation(tokens[k], ",")) {
+      spans.push({ from, to: k });
+      from = k + 1;
+    }
+  spans.push({ from, to: end });
+  return spans;
+}
+var only = (tokens, span) => span && span.to - span.from === 1 ? tokens[span.from] : void 0;
+function callGivesYear(tokens, open) {
+  const o = tokens[open];
+  if (o.call === "YEAR") return true;
+  if (o.call === void 0 || !WRAPPERS.has(o.call) || o.close === void 0) return false;
+  const inside = tokens.slice(open + 1, o.close);
+  if (inside.some((x) => x.call === "YEAR")) return true;
+  for (const x of inside) {
+    const named2 = x.kind === "column" ? nameClass(x.text) : void 0;
+    if (named2 !== void 0) return named2 === "year";
+  }
+  return o.call === "FORMAT" && inside.some((x) => x.kind === "string" && /^(?:yy|yyyy)$/i.test(x.text));
+}
+function yearBefore(tokens, k) {
+  const t = tokens[k];
+  if (t === void 0) return false;
+  if (t.kind === "column" || t.kind === "identifier") return nameClass(t.text) === "year";
+  return isPunctuation(t, ")") && t.open !== void 0 && callGivesYear(tokens, t.open);
+}
+function yearAfter(tokens, k) {
+  const t = tokens[k];
+  const next = tokens[k + 1];
+  if ((t?.kind === "table" || t?.kind === "identifier") && next?.kind === "column")
+    return nameClass(next.text) === "year";
+  if (t?.kind === "column") return nameClass(t.text) === "year";
+  if (t?.kind === "identifier" && isPunctuation(next, "(")) return callGivesYear(tokens, k + 1);
+  return t?.kind === "identifier" && nameClass(t.text) === "year";
+}
+function isBound(tokens, open) {
+  for (let p = tokens[open].parent; p !== void 0; p = tokens[p].parent)
+    if (BOUNDS.has(tokens[p].call ?? "")) return true;
+  return false;
+}
+function isYearFreeFormat(tokens, open) {
+  const date = tokens[open - 1];
+  const p = date.parent;
+  if (p === void 0 || tokens[p].call !== "FORMAT" || date.arg !== 0) return false;
+  const format = only(tokens, argumentsOf(tokens, p)[1]);
+  return format?.kind === "string" && !/y/i.test(format.text) && !YEAR_FORMATS.has(format.text.toLowerCase());
+}
+var isRealDay = (year, month, day) => month >= 1 && month <= 12 && day >= 1 && day <= new Date(Date.UTC(year, month, 0)).getUTCDate();
+function daxDate(year, month, day) {
+  if (year > 9999) return void 0;
+  const full = year < 50 ? year + 2e3 : year < 100 ? year + 1900 : year;
+  const d = new Date(Date.UTC(full, month - 1, day));
+  if (Number.isNaN(d.getTime())) return void 0;
+  return { year: d.getUTCFullYear(), month: d.getUTCMonth() + 1, day: d.getUTCDate() };
+}
+function dateString(t) {
+  const text2 = t.text.trim();
+  const first = YEAR_FIRST.exec(text2);
+  if (first) {
+    const [year2, month, day] = [Number(first[1]), Number(first[3]), Number(first[4])];
+    return isRealDay(year2, month, day) ? { at: t.start, year: year2, date: { year: year2, month, day } } : void 0;
+  }
+  const last = YEAR_LAST.exec(text2);
+  if (!last) return void 0;
+  const [a, b, year] = [Number(last[1]), Number(last[2]), Number(last[3])];
+  const monthFirst = isRealDay(year, a, b);
+  const dayFirst = isRealDay(year, b, a);
+  if (monthFirst && dayFirst && a !== b) return { at: t.start, year, ambiguous: text2 };
+  if (monthFirst) return { at: t.start, year, date: { year, month: a, day: b } };
+  if (dayFirst) return { at: t.start, year, date: { year, month: b, day: a } };
+  return void 0;
+}
+function expressionPeriods(expression) {
+  const tokens = tokenizeDax(expression);
+  const found = [];
+  const year = (t, y) => {
+    found.push({ at: t.start, year: y });
+  };
+  tokens.forEach((t, k) => {
+    if (t.kind === "operator" && COMPARISONS.has(t.text) && !isWord(tokens[k - 2], "VAR")) {
+      const right = yearIn(tokens[k + 1], true);
+      if (right !== void 0 && yearBefore(tokens, k - 1)) year(tokens[k + 1], right);
+      const left = yearIn(tokens[k - 1], true);
+      if (left !== void 0 && yearAfter(tokens, k + 1)) year(tokens[k - 1], left);
+    }
+    const list = tokens[k + 1];
+    if (isWord(t, "IN") && isPunctuation(list, "{") && yearBefore(tokens, k - 1))
+      for (const x of tokens.slice(k + 2, list.close ?? tokens.length)) {
+        const y = yearIn(x, true);
+        if (y !== void 0) year(x, y);
+      }
+    if (t.call === "DATE" && !isBound(tokens, k) && !isYearFreeFormat(tokens, k)) {
+      const [y, m, d] = argumentsOf(tokens, k).map((span) => only(tokens, span));
+      const fixed = yearIn(y, false);
+      if (fixed !== void 0) {
+        if (isWhole(m) && isWhole(d)) {
+          const [month, day] = [Number(m.text), Number(d.text)];
+          const epoch = fixed === UNIX_EPOCH.year && month === UNIX_EPOCH.month && day === UNIX_EPOCH.day;
+          const date = daxDate(fixed, month, day);
+          if (!epoch && date) found.push({ at: tokens[k - 1].start, year: fixed, date });
+        } else year(y, fixed);
+      }
+    }
+  });
+  for (const v of daxVariables(tokens)) {
+    const y = yearIn(only(tokens, v), true);
+    if (y !== void 0 && nameClass(v.name) === "year") year(tokens[v.from], y);
+  }
+  const seen = /* @__PURE__ */ new Set();
+  const periods = [];
+  for (const p of found.sort((a, b) => a.at - b.at))
+    if (!seen.has(p.at)) {
+      seen.add(p.at);
+      periods.push(p);
+    }
+  return periods;
+}
+function wholeNumber(tokens, vars, span) {
+  let t = only(tokens, span);
+  if (t?.kind === "identifier") {
+    const v = variableAt(vars, t.text, span.from);
+    t = v ? only(tokens, v) : void 0;
+  }
+  return isWhole(t) ? Number(t.text) : void 0;
+}
+function fixedDay(tokens, vars, span, seen) {
+  const first = tokens[span.from];
+  if (first === void 0 || span.to <= span.from) return void 0;
+  if (span.to - span.from === 1) {
+    if (first.kind === "string") return dateString(first);
+    if (first.kind === "date") {
+      const m = /^(\d{4})-(\d{1,2})-(\d{1,2})/.exec(first.text.trim());
+      if (!m) return void 0;
+      const [year, month, day] = [Number(m[1]), Number(m[2]), Number(m[3])];
+      return isRealDay(year, month, day) ? { at: first.start, year, date: { year, month, day } } : void 0;
+    }
+    if (first.kind !== "identifier") return void 0;
+    const v = variableAt(vars, first.text, span.from);
+    if (v === void 0 || seen.has(v)) return void 0;
+    seen.add(v);
+    return fixedDay(tokens, vars, v, seen);
+  }
+  const open = span.from + 1;
+  if (first.kind !== "identifier" || tokens[open]?.close !== span.to - 1) return void 0;
+  const call = first.text.toUpperCase();
+  const args = argumentsOf(tokens, open);
+  if (call === "DATE" && args.length === 3) {
+    const [y, m, d] = args.map((a) => wholeNumber(tokens, vars, a));
+    if (y === void 0 || m === void 0 || d === void 0) return void 0;
+    const date = daxDate(y, m, d);
+    return date && { at: first.start, year: y, date };
+  }
+  const text2 = args.length === 1 ? only(tokens, args[0]) : void 0;
+  if (STRING_DATES.has(call) && text2?.kind === "string") return dateString(text2);
+  return void 0;
+}
+function calendarEnds(expression) {
+  const tokens = tokenizeDax(expression);
+  const vars = daxVariables(tokens);
+  const ends = [];
+  tokens.forEach((t, k) => {
+    if (t.call !== "CALENDAR") return;
+    const end = argumentsOf(tokens, k)[1];
+    const day = end && fixedDay(tokens, vars, end, /* @__PURE__ */ new Set());
+    if (day) ends.push(day);
+  });
+  return ends;
+}
+
+// ../core/src/rules/pbiplint/periods.ts
+var MONTHS2 = [
+  "January",
+  "February",
+  "March",
+  "April",
+  "May",
+  "June",
+  "July",
+  "August",
+  "September",
+  "October",
+  "November",
+  "December"
+];
+var shown = (p) => p.ambiguous !== void 0 ? `"${p.ambiguous}"` : p.date ? `${MONTHS2[p.date.month - 1]} ${p.date.day}, ${p.date.year}` : String(p.year);
+function englishList(items) {
+  const named2 = items.length > 3 ? [...items.slice(0, 3), `${items.length - 3} more`] : [...items];
+  if (named2.length <= 2) return named2.join(" and ");
+  const sep = named2.some((s) => s.includes(",")) ? "; " : ", ";
+  return `${named2.slice(0, -1).join(sep)}${sep}and ${named2.at(-1)}`;
+}
+function namesYear(name, year) {
+  const digits = String(year);
+  if (digits.length !== 4) return false;
+  return name.includes(digits) || new RegExp(`(?:^|\\D)${digits.slice(2)}(?:\\D|$)`).test(name);
+}
+function lineAt2(node, offset) {
+  if (node?.valueLine === void 0 || node.value === void 0) return void 0;
+  let line = node.valueLine;
+  for (let k = 0; k < offset && k < node.value.length; k++) if (node.value[k] === "\n") line++;
+  return { file: node.file, line };
+}
+function fixesDetail(periods) {
+  const names = [...new Set(periods.map(shown))];
+  const days = periods.filter((p) => p.date !== void 0 || p.ambiguous !== void 0).length;
+  const noun = days === 0 ? "year" : days === periods.length ? "date" : "period";
+  return `fixed ${noun}${names.length > 1 ? "s" : ""} ${englishList(names)}`;
+}
+function endsDetail(periods) {
+  const names = [...new Set(periods.map(shown))];
+  return names.length === 1 ? `ends on a fixed date, ${names[0]}` : `ends on fixed dates ${englishList(names)}`;
+}
+function fixedFinding(base, name, found, detail) {
+  const periods = found.map((f) => f.period);
+  if (periods.length === 0 || periods.some((p) => namesYear(name, p.year))) return [];
+  const where = lineAt2(found[0].node, found[0].period.at);
+  const own = detail(periods);
+  return [
+    {
+      ...base,
+      ...where ? { location: where } : {},
+      detail: base.detail === void 0 ? own : `${own} in ${base.detail}`
+    }
+  ];
+}
+var inNode = (node, expression) => expressionPeriods(expression).map((period) => ({ period, node }));
+function dateTableEnds(t) {
+  if (t.kind !== "calculated" || isAutoDateTable(t)) return [];
+  return t.partitions.filter((p) => p.sourceType === "calculated").flatMap((p) => {
+    const node = p.node?.children.find((c) => c.kind === "expr" && c.type === "source");
+    return calendarEnds(node?.value ?? p.source ?? "").map((period) => ({ period, node }));
+  });
+}
+function periodFindings(model) {
+  const out = [];
+  for (const t of model.tables) {
+    out.push(...fixedFinding(finding.table(t), t.name, dateTableEnds(t), endsDetail));
+    for (const x of t.measures)
+      out.push(
+        ...fixedFinding(finding.measure(x), x.name, inNode(x.node, x.expression), fixesDetail)
+      );
+    for (const c of t.columns)
+      if (c.kind === "calculated")
+        out.push(
+          ...fixedFinding(
+            finding.column(c),
+            c.name,
+            inNode(c.node, c.expression ?? ""),
+            fixesDetail
+          )
+        );
+    for (const i of t.calculationGroup?.items ?? [])
+      out.push(
+        ...fixedFinding(
+          finding.calculationItem(i),
+          i.name,
+          inNode(i.node, i.expression),
+          fixesDetail
+        )
+      );
+  }
+  return out;
+}
+var HARDCODED_PERIOD_IN_DAX = pbiplintRule({
+  id: "HARDCODED_PERIOD_IN_DAX",
+  name: "Hardcoded period in DAX",
+  category: "DAX Expressions",
+  severity: 1,
+  scope: ["Measure", "CalculatedColumn", "CalculationItem", "CalculatedTable"],
+  layer: "model",
+  // No skipWhenModelUnread: each finding rests on the object's own expression, so a file the
+  // parser could not read can hide an object from the rule, never put a period in one.
+  check: ({ model }) => model ? periodFindings(model) : []
+});
+var periodRules = [HARDCODED_PERIOD_IN_DAX];
+
 // ../core/src/rules/pbiplint/references.ts
 var fieldLabel = (ref) => {
   const inTable = (name) => ref.table === "" ? measureRef(name) : columnRef(ref.table, name);
@@ -4757,6 +5524,7 @@ var pbiplintRules = [
   ...visualRules2,
   ...pageRules2,
   ...measureRules2,
+  ...periodRules,
   ...actionRules,
   ...tabOrderRules
 ];
@@ -4792,6 +5560,14 @@ var NOT_MODELED = [
 ];
 var KNOWN = /* @__PURE__ */ new Set([...MODELED, ...NOT_MODELED]);
 var isRootType = (type) => KNOWN.has(type.toLowerCase());
+var isModelChildType = (type) => {
+  const t = type.toLowerCase();
+  return KNOWN.has(t) && t !== "model" && t !== "database" && t !== "createorreplace";
+};
+var isNamedRootType = (type) => {
+  const t = type.toLowerCase();
+  return t !== "model" && MODELED.includes(t);
+};
 
 // ../core/src/tmdl/parse.ts
 var HEADER = /^([A-Za-z_]\w*)(?:\s+(.+))?$/;
@@ -4804,6 +5580,9 @@ var tabIndent = (line) => {
 };
 var leadingWs = (line) => line.length - line.trimStart().length;
 var mayBeRootLine = (line) => line.trim() !== "" && tabIndent(line) === 0 && (!/^\s/.test(line) || splitHeader(line)?.type.toLowerCase() === "table");
+var namesTable = (line) => /^table(?:[\s:=]|$)/i.test(line.trim());
+var HOLDS_TABLE = /* @__PURE__ */ new Set(["model", "createorreplace"]);
+var nameReadable = (name) => !name.includes("'") || /^'(?:[^']|'')*'$/.test(name);
 function splitHeader(content) {
   let inQuote = false;
   let eqAt = -1;
@@ -4822,16 +5601,41 @@ function splitHeader(content) {
   return {
     type: m[1],
     name: m[2] === void 0 ? void 0 : unquoteName(m[2]),
+    nameReadable: m[2] === void 0 || nameReadable(m[2].trim()),
     hasEq: eqAt >= 0,
     inline
   };
 }
+var opensFence = (line) => {
+  const content = line.slice(tabIndent(line));
+  if (/^\s/.test(content) || REF.test(content) || PROP.test(content)) return false;
+  const h = splitHeader(content);
+  return h !== null && h.hasEq && h.inline === "```";
+};
+var isDescription = (line) => line.slice(tabIndent(line)).startsWith("///");
+var blockEnd = (lines, from, limit, depth, head) => {
+  const lead = lines[from]?.slice(0, leadingWs(lines[from])) ?? "";
+  const inBlock = (line) => line.trim() === "" || leadingWs(line) >= depth && (line.startsWith(lead) || tabIndent(line) > head + 1 || !namesTable(line));
+  let k = from;
+  while (k < limit && inBlock(lines[k])) k++;
+  return k;
+};
+var blockText = (lines, from, end, depth) => {
+  const out = lines.slice(from, end).map((l) => l.trim() === "" ? "" : l.slice(depth));
+  while (out.at(-1) === "") out.pop();
+  return out.join("\n");
+};
 function parseTmdl(file, text2) {
   const body = text2.charCodeAt(0) === 65279 ? text2.slice(1) : text2;
   const lines = body.replace(/\r\n?/g, "\n").split("\n");
   const roots = [];
   const issues = [];
   const stack = [];
+  const holders = /* @__PURE__ */ new Map();
+  const mayBeModelLevelLine = (line, depth) => {
+    const tabs = tabIndent(line);
+    return mayBeRootLine(line) || tabs > 0 && tabs <= depth && line.trim() !== "" && holders.has(stack[tabs - 1]) && (!/^\s/.test(line.slice(tabs)) || namesTable(line));
+  };
   let pendingDescription = null;
   const orphanDescription = (pending) => {
     issues.push({
@@ -4869,51 +5673,52 @@ function parseTmdl(file, text2) {
         text: raw,
         reason: "space indentation (TMDL requires tabs)",
         canDropObjects: true,
-        canDropTableLine: mayBeRootLine(raw)
+        canDropTableLine: mayBeRootLine(raw) || namesTable(raw)
       });
       i++;
       continue;
     }
+    let valueLine = lineNo;
     const collectBlock = () => {
       let j = i + 1;
       while (j < lines.length && lines[j].trim() === "") j++;
       if (j >= lines.length) return "";
       const blockIndent = leadingWs(lines[j]);
       if (blockIndent <= indent) return "";
-      const out = [];
-      let lastNonBlank = -1;
-      for (; j < lines.length; j++) {
-        const l = lines[j];
-        if (l.trim() === "") {
-          out.push("");
-          continue;
-        }
-        if (leadingWs(l) < blockIndent) break;
-        out.push(l.slice(blockIndent));
-        lastNonBlank = out.length - 1;
-      }
-      i = j - 1;
-      return out.slice(0, lastNonBlank + 1).join("\n");
+      valueLine = j + 1;
+      const end = blockEnd(lines, j, lines.length, blockIndent, indent);
+      i = end - 1;
+      return blockText(lines, j, end, blockIndent);
     };
     const collectFenced = () => {
-      const out = [];
+      valueLine = lineNo + 1;
       let j = i + 1;
-      while (j < lines.length && lines[j].trim() !== "```") {
-        out.push(lines[j]);
-        j++;
+      while (j < lines.length && lines[j].trim() !== "```" && !opensFence(lines[j])) j++;
+      if (j < lines.length && lines[j].trim() === "```") {
+        const boundary = leadingWs(lines[j]);
+        const out = lines.slice(i + 1, j).map((l) => l.slice(Math.min(boundary, leadingWs(l))));
+        i = j;
+        return out.join("\n");
       }
-      if (j >= lines.length)
-        issues.push({
-          file,
-          line: lineNo,
-          text: raw,
-          reason: "unterminated code fence",
-          canDropObjects: true,
-          canDropTableLine: out.some(mayBeRootLine)
-        });
-      const boundary = j < lines.length ? leadingWs(lines[j]) : 0;
-      i = j;
-      return out.map((l) => l.slice(Math.min(boundary, leadingWs(l)))).join("\n");
+      let first = i + 1;
+      while (first < j && lines[first].trim() === "") first++;
+      const blockIndent = first < j ? leadingWs(lines[first]) : 0;
+      const depth = blockIndent > indent ? blockIndent : 0;
+      let end = depth > 0 ? blockEnd(lines, first, j, depth, indent) : j;
+      if (end === j && j < lines.length)
+        while (end > i + 1 && isDescription(lines[end - 1])) end--;
+      const read = lines.slice(i + 1, end);
+      issues.push({
+        file,
+        line: lineNo,
+        text: raw,
+        reason: "unterminated code fence",
+        canDropObjects: true,
+        canDropTableLine: read.some((l) => mayBeModelLevelLine(l, indent))
+      });
+      const value = blockText(lines, i + 1, end, depth);
+      i = end - 1;
+      return value;
     };
     const base = {
       props: {},
@@ -4925,6 +5730,7 @@ function parseTmdl(file, text2) {
     let node;
     let m;
     let word;
+    let readableName = true;
     if (m = REF.exec(content)) {
       node = { ...base, kind: "ref", type: m[1].toLowerCase(), name: unquoteName(m[2]) };
     } else if (m = PROP.exec(content)) {
@@ -4939,23 +5745,33 @@ function parseTmdl(file, text2) {
           text: raw,
           reason: "unrecognized line",
           canDropObjects: true,
-          canDropTableLine: mayBeRootLine(raw)
+          canDropTableLine: mayBeModelLevelLine(raw, indent)
         });
         i++;
         continue;
       }
       word = h.type;
+      readableName = h.nameReadable;
       if (h.hasEq) {
         const value = h.inline === "```" ? collectFenced() : h.inline === "" ? collectBlock() : h.inline;
-        node = h.name === void 0 ? { ...base, kind: "expr", type: h.type.toLowerCase(), value } : { ...base, kind: "object", type: h.type.toLowerCase(), name: h.name, value };
+        node = h.name === void 0 ? { ...base, kind: "expr", type: h.type.toLowerCase(), value, valueLine } : {
+          ...base,
+          kind: "object",
+          type: h.type.toLowerCase(),
+          name: h.name,
+          value,
+          valueLine
+        };
       } else if (h.name !== void 0) {
         node = { ...base, kind: "object", type: h.type.toLowerCase(), name: h.name };
       } else {
         node = { ...base, kind: "flag", type: h.type.toLowerCase() };
       }
     }
+    let rootIssue;
     if (indent === 0 && word !== void 0) {
       const reason = node.kind === "prop" || node.kind === "expr" ? `"${word}" is a property, which TMDL allows only under an object` : isRootType(word) ? void 0 : `"${word}" is not a type TMDL declares at the root of a file`;
+      rootIssue = reason;
       if (reason !== void 0)
         issues.push({
           file,
@@ -4963,7 +5779,7 @@ function parseTmdl(file, text2) {
           text: raw,
           reason,
           canDropObjects: true,
-          canDropTableLine: node.kind === "object" || node.kind === "flag"
+          canDropTableLine: node.kind === "object" || node.kind === "flag" || namesTable(raw)
         });
     }
     if (pendingDescription) {
@@ -4979,11 +5795,44 @@ function parseTmdl(file, text2) {
         text: raw,
         reason: "orphan indentation",
         canDropObjects: true,
-        canDropTableLine: false
+        canDropTableLine: namesTable(raw) || roots.length === 0 && !issues.some((x) => x.canDropObjects)
       });
       i++;
       continue;
     }
+    const level = parent && holders.get(parent);
+    const declaration = node.kind === "object" || node.kind === "flag";
+    const keyword = word?.toLowerCase();
+    let malformed;
+    let mayBeTable = namesTable(raw);
+    if (rootIssue === void 0 && keyword !== void 0) {
+      if (!declaration) {
+        if (level === "model" && isModelChildType(keyword))
+          malformed = `"${word}" is not a property TMDL allows under a model`;
+      } else if (indent > 0 && keyword === "table" && !HOLDS_TABLE.has(parent?.type ?? "")) {
+        malformed = `"${word}" is a type TMDL declares only at the root of a file or under a model`;
+      } else if (level !== void 0 && !(level === "model" ? isModelChildType(keyword) : keyword === "model") && (node.kind === "object" || isRootType(keyword))) {
+        malformed = `"${word}" is not a type TMDL declares under a ${level}`;
+        mayBeTable = true;
+      } else if ((indent === 0 || level === "model") && (node.kind === "flag" || node.name === "") && isNamedRootType(keyword)) {
+        malformed = `"${word}" is declared with no name`;
+      } else if (!readableName) {
+        malformed = "the name is not enclosed in single quotes as TMDL requires";
+      }
+    }
+    if (malformed !== void 0) {
+      issues.push({
+        file,
+        line: lineNo,
+        text: raw,
+        reason: malformed,
+        canDropObjects: true,
+        canDropTableLine: mayBeTable
+      });
+      stack[indent] = node;
+      i++;
+      continue;
+    }
     if (parent) {
       if (node.kind === "prop" || node.kind === "expr") parent.props[node.type] = node.value ?? "";
       else if (node.kind === "flag") parent.props[node.type] = true;
@@ -4991,19 +5840,31 @@ function parseTmdl(file, text2) {
     } else {
       roots.push(node);
     }
+    if (declaration && (!parent && (node.type === "model" || node.type === "database") || level === "database" && node.type === "model"))
+      holders.set(node, node.type);
     stack[indent] = node;
     i++;
   }
   if (pendingDescription) orphanDescription(pendingDescription);
-  for (const r of roots) {
-    if (r.kind !== "object" && r.kind !== "flag" || r.children.length === 0) continue;
-    if (r.type !== "annotation" && r.type !== "extendedproperty") continue;
+  const modelLevel = [
+    ...roots.map((node) => ({ node, root: true })),
+    ...[...holders].filter(([, holds]) => holds === "model").flatMap(([m]) => m.children.map((node) => ({ node, root: false })))
+  ];
+  for (const { node: r, root } of modelLevel) {
+    if (r.children.length === 0) continue;
+    if (r.kind === "ref") continue;
+    const valued = r.kind === "prop" || r.kind === "expr";
+    const noted = r.type === "annotation" || r.type === "extendedproperty";
+    const holdsDeclaration = !root && r.kind === "flag" && !noted && r.children.some((c) => c.kind === "object");
+    if (!(valued ? !root : noted || holdsDeclaration)) continue;
     const text3 = lines[r.line - 1];
+    const where = root ? "at the root of a file" : "under a model";
+    const under = holdsDeclaration ? "a declaration" : "lines";
     const issue = {
       file,
       line: r.line,
       text: text3,
-      reason: `"${/^\w+/.exec(text3)[0]}" at the root of a file has lines under it, which TMDL does not allow`,
+      reason: `"${/^\w+/.exec(text3.trimStart())[0]}" ${where} has ${under} under it, which TMDL does not allow`,
       canDropObjects: true,
       canDropTableLine: false
     };
@@ -5208,14 +6069,14 @@ var oneLine = (s) => s.replace(/\r\n?|\n/g, " ");
 var text = (s) => showControls(s.replace(/\\/g, "\\\\")).replace(/&/g, "&amp;").replace(/</g, "&lt;").replace(/>/g, "&gt;").replace(/[`[\]*_~|@$]/g, "\\$&").replace(/:(?=\/\/)/g, "\\:").replace(/(www)\./gi, "$1\\.");
 var cell = (s) => text(oneLine(s));
 function code(name) {
-  const shown = showControls(oneLine(name)).replace(
+  const shown2 = showControls(oneLine(name)).replace(
     /(\\*)\|/g,
     (_, run) => `${run}${run.length % 2 ? "\\" : ""}\\|`
   );
-  const fence = "`".repeat(Math.max(0, ...(shown.match(/`+/g) ?? []).map((r) => r.length)) + 1);
-  const spaced = shown.startsWith(" ") && shown.endsWith(" ") && /[^ ]/.test(shown);
-  const pad = shown.startsWith("`") || shown.endsWith("`") || spaced ? " " : "";
-  return `${fence}${pad}${shown}${pad}${fence}`;
+  const fence = "`".repeat(Math.max(0, ...(shown2.match(/`+/g) ?? []).map((r) => r.length)) + 1);
+  const spaced = shown2.startsWith(" ") && shown2.endsWith(" ") && /[^ ]/.test(shown2);
+  const pad = shown2.startsWith("`") || shown2.endsWith("`") || spaced ? " " : "";
+  return `${fence}${pad}${shown2}${pad}${fence}`;
 }
 function formatMarkdown(result, _options = {}) {
   const out = [
@@ -5830,9 +6691,10 @@ Quirks
 - A relationship that is both bi-directional and many-to-many counts twice, once in each tally, so the ratio can exceed 1. A model of nothing but such relationships scores 2.0.
 - The denominator is every relationship in the model, and a model with no relationships at all is never reported.
 - Inactive relationships are counted on both sides of the ratio. A bi-directional relationship that no measure ever activates still pushes the model over the threshold.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the share is of every relationship in the model, and the relationships pbiplint missed could change it; pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/avoid-excessive-bi-directional-or-many-to-many-relationships`,
-    markdown: "### Example\n\nOne bi-directional relationship out of two is half the model, well past the threshold.\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		sourceColumn: ProductID\n\n	column 'Customer ID'\n		dataType: int64\n		sourceColumn: CustomerID\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n\ntable Customer\n	column 'Customer ID'\n		dataType: int64\n		isKey\n		sourceColumn: CustomerID\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n\nrelationship Sales_Customer\n	crossFilteringBehavior: bothDirections\n	fromColumn: Sales.'Customer ID'\n	toColumn: Customer.'Customer ID'\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		sourceColumn: ProductID\n\n	column 'Customer ID'\n		dataType: int64\n		sourceColumn: CustomerID\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n\ntable Customer\n	column 'Customer ID'\n		dataType: int64\n		isKey\n		sourceColumn: CustomerID\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n\nrelationship Sales_Customer\n	fromColumn: Sales.'Customer ID'\n	toColumn: Customer.'Customer ID'\n```\n\n### Why it matters\n\nEach bi-directional or many-to-many relationship adds a filter path the engine has to consider on every query. A few in the right places are fine. When they are a third of the model, most queries pay for filter propagation they do not need, and the model starts to show ambiguity: two routes between the same tables, the engine picking one, and totals that stop adding up.\n\n### How to fix it\n\nTake the direction off the relationships that do not need it. In Power BI Desktop, open the model view, double-click a relationship, and set Cross filter direction to Single in the Edit relationship dialog; in the TMDL file the same change is the `crossFilteringBehavior: bothDirections` line, deleted, since single direction is the default. Where one report genuinely needs the reverse filter, leave the relationship single and ask for the filter inside the measure that needs it, as in `Products Sold = CALCULATE(DISTINCTCOUNT('Product'[Product ID]), CROSSFILTER('Sales'[Product ID], 'Product'[Product ID], BOTH))`, so the cost falls on one visual instead of every query. For a many-to-many relationship, load a bridge table holding the distinct key values and relate both tables to it, which makes each hop many-to-one: in the dialog that is the Cardinality dropdown, and in the file it is `fromCardinality` and `toCardinality` on each relationship. The dialog and the properties read the same on an import model and a DirectQuery one.\n\n### When to ignore it\n\nA small model is the usual false alarm. Three relationships with one deliberate bi-directional relationship among them is 33 percent and fires, and there is nothing excessive about one. Count the relationships before you read the finding as a verdict: the rule is a ratio, and a ratio over four relationships says almost nothing. A model built on a bridge table by design is the other case, for example one that maps accounts to account groups or budgets to regions, where the many-to-many relationships are the architecture rather than an accident. What is not a legitimate exception is a large model whose bi-directional relationships nobody can account for one by one; that is the finding doing its job.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = AVOID_EXCESSIVE_BI-DIRECTIONAL_OR_MANY-TO-MANY_RELATIONSHIPS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"AVOID_EXCESSIVE_BI-DIRECTIONAL_OR_MANY-TO-MANY_RELATIONSHIPS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A relationship that is both bi-directional and many-to-many counts twice, once in each tally, so the ratio can exceed 1. A model of nothing but such relationships scores 2.0.\n- The denominator is every relationship in the model, and a model with no relationships at all is never reported.\n- Inactive relationships are counted on both sides of the ratio. A bi-directional relationship that no measure ever activates still pushes the model over the threshold.\n\nRead more: https://pbiplint.com/rules/avoid-excessive-bi-directional-or-many-to-many-relationships"
+    markdown: "### Example\n\nOne bi-directional relationship out of two is half the model, well past the threshold.\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		sourceColumn: ProductID\n\n	column 'Customer ID'\n		dataType: int64\n		sourceColumn: CustomerID\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n\ntable Customer\n	column 'Customer ID'\n		dataType: int64\n		isKey\n		sourceColumn: CustomerID\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n\nrelationship Sales_Customer\n	crossFilteringBehavior: bothDirections\n	fromColumn: Sales.'Customer ID'\n	toColumn: Customer.'Customer ID'\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		sourceColumn: ProductID\n\n	column 'Customer ID'\n		dataType: int64\n		sourceColumn: CustomerID\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n\ntable Customer\n	column 'Customer ID'\n		dataType: int64\n		isKey\n		sourceColumn: CustomerID\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n\nrelationship Sales_Customer\n	fromColumn: Sales.'Customer ID'\n	toColumn: Customer.'Customer ID'\n```\n\n### Why it matters\n\nEach bi-directional or many-to-many relationship adds a filter path the engine has to consider on every query. A few in the right places are fine. When they are a third of the model, most queries pay for filter propagation they do not need, and the model starts to show ambiguity: two routes between the same tables, the engine picking one, and totals that stop adding up.\n\n### How to fix it\n\nTake the direction off the relationships that do not need it. In Power BI Desktop, open the model view, double-click a relationship, and set Cross filter direction to Single in the Edit relationship dialog; in the TMDL file the same change is the `crossFilteringBehavior: bothDirections` line, deleted, since single direction is the default. Where one report genuinely needs the reverse filter, leave the relationship single and ask for the filter inside the measure that needs it, as in `Products Sold = CALCULATE(DISTINCTCOUNT('Product'[Product ID]), CROSSFILTER('Sales'[Product ID], 'Product'[Product ID], BOTH))`, so the cost falls on one visual instead of every query. For a many-to-many relationship, load a bridge table holding the distinct key values and relate both tables to it, which makes each hop many-to-one: in the dialog that is the Cardinality dropdown, and in the file it is `fromCardinality` and `toCardinality` on each relationship. The dialog and the properties read the same on an import model and a DirectQuery one.\n\n### When to ignore it\n\nA small model is the usual false alarm. Three relationships with one deliberate bi-directional relationship among them is 33 percent and fires, and there is nothing excessive about one. Count the relationships before you read the finding as a verdict: the rule is a ratio, and a ratio over four relationships says almost nothing. A model built on a bridge table by design is the other case, for example one that maps accounts to account groups or budgets to regions, where the many-to-many relationships are the architecture rather than an accident. What is not a legitimate exception is a large model whose bi-directional relationships nobody can account for one by one; that is the finding doing its job.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = AVOID_EXCESSIVE_BI-DIRECTIONAL_OR_MANY-TO-MANY_RELATIONSHIPS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"AVOID_EXCESSIVE_BI-DIRECTIONAL_OR_MANY-TO-MANY_RELATIONSHIPS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A relationship that is both bi-directional and many-to-many counts twice, once in each tally, so the ratio can exceed 1. A model of nothing but such relationships scores 2.0.\n- The denominator is every relationship in the model, and a model with no relationships at all is never reported.\n- Inactive relationships are counted on both sides of the ratio. A bi-directional relationship that no measure ever activates still pushes the model over the threshold.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the share is of every relationship in the model, and the relationships pbiplint missed could change it; pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/avoid-excessive-bi-directional-or-many-to-many-relationships"
   },
   AVOID_FLOATING_POINT_DATA_TYPES: {
     text: `Example
@@ -6423,9 +7285,10 @@ Quirks
 - Calculated tables are out of scope, and so are calculation groups. Only a plain table is reported, even where a calculated table carries the filter.
 - The relationship only has to touch the table. Direction is not tested, so a many-to-many relationship the security filter never travels through is reported the same as one it does.
 - A table permission with no filter expression does not count. An entry that only sets metadataPermission or a column permission, which is object-level security rather than row-level, leaves the table out of this rule.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could hold a calculated partition, which makes it a calculated table, out of the rule's scope, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/avoid-using-many-to-many-relationships-on-tables-used-for-dynamic-row-level-security`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Customer\n	column 'Customer ID'\n		dataType: int64\n		isKey\n		sourceColumn: CustomerID\n\n	column Region\n		dataType: string\n		sourceColumn: Region\n\ntable 'User Region'\n	column 'User Email'\n		dataType: string\n		sourceColumn: UserEmail\n\n	column Region\n		dataType: string\n		sourceColumn: Region\n\nrelationship UserRegion_Customer\n	fromCardinality: many\n	toCardinality: many\n	crossFilteringBehavior: bothDirections\n	fromColumn: 'User Region'.Region\n	toColumn: Customer.Region\n\nrole 'Regional Users'\n	modelPermission: read\n\n	tablePermission 'User Region' = 'User Region'[User Email] = USERPRINCIPALNAME()\n```\n\n**After the fix**\n\n```tmdl\ntable Customer\n	column 'Customer ID'\n		dataType: int64\n		isKey\n		sourceColumn: CustomerID\n\n	column Region\n		dataType: string\n		sourceColumn: Region\n\ntable Region\n	column Region\n		dataType: string\n		isKey\n		sourceColumn: Region\n\ntable 'User Region'\n	column 'User Email'\n		dataType: string\n		sourceColumn: UserEmail\n\n	column Region\n		dataType: string\n		sourceColumn: Region\n\nrelationship UserRegion_Region\n	crossFilteringBehavior: bothDirections\n	fromColumn: 'User Region'.Region\n	toColumn: Region.Region\n\nrelationship Customer_Region\n	fromColumn: Customer.Region\n	toColumn: Region.Region\n\nrole 'Regional Users'\n	modelPermission: read\n\n	tablePermission 'User Region' = 'User Region'[User Email] = USERPRINCIPALNAME()\n```\n\n### Why it matters\n\nA security filter is pushed through every relationship leading away from the secured table, on every query, for every user in the role. Through a many-to-many relationship that push is an expansion over the distinct values on both sides rather than a lookup, and it runs before the query proper. The slowdown grows with every such hop, and the model owner never sees it, because Desktop tests without roles.\n\n### How to fix it\n\nGive the two tables a dimension to meet on, so every hop is many-to-one. Load a small table of the distinct key values, one row per region in the example above, and in Power BI Desktop's model view drag both the security table's key and the fact or dimension key onto it; each new relationship is many-to-one because the new table's key is unique. In the TMDL file that is `fromCardinality: many` with `toCardinality: one`, which is what a relationship block with neither line already means, and marking the new table's key column with `isKey`. The security filter itself does not move: it stays where Modeling, Manage roles wrote it, as a `tablePermission` line under the role. Leave one bi-directional hop, from the security table up to the shared dimension, so the filter still reaches the facts, and make it that one hop rather than a many-to-many expansion. The patterns under Links set out the variants in full.\n\n### When to ignore it\n\nThe filter is the thing to look at first. This rule counts any row-level security filter, so a table filtered by a static expression such as `[Region] = \"East\"` is reported exactly like one filtered by a lookup on the signed-in user. A static filter resolves to the same rows for everyone in the role, so the expansion is cached and shared instead of repeated per user. The direction of the relationship is the second check: the finding only asks whether a many-to-many relationship touches the table, not whether the security filter travels through it, so a many-to-many relationship pointing away from the secured path costs nothing here. Size is the third: a security table of a few hundred rows expands cheaply, and the trade the rule assumes is one worth measuring in the service with the role applied before you rebuild anything. A large secured table reached through more than one many-to-many hop is the case the rule was written for, and there ignoring it is not defensible.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = AVOID_USING_MANY-TO-MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"AVOID_USING_MANY-TO-MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Any row-level security filter counts, not only dynamic filters that call USERNAME or USERPRINCIPALNAME.\n- Calculated tables are out of scope, and so are calculation groups. Only a plain table is reported, even where a calculated table carries the filter.\n- The relationship only has to touch the table. Direction is not tested, so a many-to-many relationship the security filter never travels through is reported the same as one it does.\n- A table permission with no filter expression does not count. An entry that only sets `metadataPermission` or a column permission, which is object-level security rather than row-level, leaves the table out of this rule.\n\nRead more: https://pbiplint.com/rules/avoid-using-many-to-many-relationships-on-tables-used-for-dynamic-row-level-security"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Customer\n	column 'Customer ID'\n		dataType: int64\n		isKey\n		sourceColumn: CustomerID\n\n	column Region\n		dataType: string\n		sourceColumn: Region\n\ntable 'User Region'\n	column 'User Email'\n		dataType: string\n		sourceColumn: UserEmail\n\n	column Region\n		dataType: string\n		sourceColumn: Region\n\nrelationship UserRegion_Customer\n	fromCardinality: many\n	toCardinality: many\n	crossFilteringBehavior: bothDirections\n	fromColumn: 'User Region'.Region\n	toColumn: Customer.Region\n\nrole 'Regional Users'\n	modelPermission: read\n\n	tablePermission 'User Region' = 'User Region'[User Email] = USERPRINCIPALNAME()\n```\n\n**After the fix**\n\n```tmdl\ntable Customer\n	column 'Customer ID'\n		dataType: int64\n		isKey\n		sourceColumn: CustomerID\n\n	column Region\n		dataType: string\n		sourceColumn: Region\n\ntable Region\n	column Region\n		dataType: string\n		isKey\n		sourceColumn: Region\n\ntable 'User Region'\n	column 'User Email'\n		dataType: string\n		sourceColumn: UserEmail\n\n	column Region\n		dataType: string\n		sourceColumn: Region\n\nrelationship UserRegion_Region\n	crossFilteringBehavior: bothDirections\n	fromColumn: 'User Region'.Region\n	toColumn: Region.Region\n\nrelationship Customer_Region\n	fromColumn: Customer.Region\n	toColumn: Region.Region\n\nrole 'Regional Users'\n	modelPermission: read\n\n	tablePermission 'User Region' = 'User Region'[User Email] = USERPRINCIPALNAME()\n```\n\n### Why it matters\n\nA security filter is pushed through every relationship leading away from the secured table, on every query, for every user in the role. Through a many-to-many relationship that push is an expansion over the distinct values on both sides rather than a lookup, and it runs before the query proper. The slowdown grows with every such hop, and the model owner never sees it, because Desktop tests without roles.\n\n### How to fix it\n\nGive the two tables a dimension to meet on, so every hop is many-to-one. Load a small table of the distinct key values, one row per region in the example above, and in Power BI Desktop's model view drag both the security table's key and the fact or dimension key onto it; each new relationship is many-to-one because the new table's key is unique. In the TMDL file that is `fromCardinality: many` with `toCardinality: one`, which is what a relationship block with neither line already means, and marking the new table's key column with `isKey`. The security filter itself does not move: it stays where Modeling, Manage roles wrote it, as a `tablePermission` line under the role. Leave one bi-directional hop, from the security table up to the shared dimension, so the filter still reaches the facts, and make it that one hop rather than a many-to-many expansion. The patterns under Links set out the variants in full.\n\n### When to ignore it\n\nThe filter is the thing to look at first. This rule counts any row-level security filter, so a table filtered by a static expression such as `[Region] = \"East\"` is reported exactly like one filtered by a lookup on the signed-in user. A static filter resolves to the same rows for everyone in the role, so the expansion is cached and shared instead of repeated per user. The direction of the relationship is the second check: the finding only asks whether a many-to-many relationship touches the table, not whether the security filter travels through it, so a many-to-many relationship pointing away from the secured path costs nothing here. Size is the third: a security table of a few hundred rows expands cheaply, and the trade the rule assumes is one worth measuring in the service with the role applied before you rebuild anything. A large secured table reached through more than one many-to-many hop is the case the rule was written for, and there ignoring it is not defensible.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = AVOID_USING_MANY-TO-MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"AVOID_USING_MANY-TO-MANY_RELATIONSHIPS_ON_TABLES_USED_FOR_DYNAMIC_ROW_LEVEL_SECURITY\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Any row-level security filter counts, not only dynamic filters that call USERNAME or USERPRINCIPALNAME.\n- Calculated tables are out of scope, and so are calculation groups. Only a plain table is reported, even where a calculated table carries the filter.\n- The relationship only has to touch the table. Direction is not tested, so a many-to-many relationship the security filter never travels through is reported the same as one it does.\n- A table permission with no filter expression does not count. An entry that only sets `metadataPermission` or a column permission, which is object-level security rather than row-level, leaves the table out of this rule.\n- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could hold a calculated partition, which makes it a calculated table, out of the rule's scope, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file's own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/avoid-using-many-to-many-relationships-on-tables-used-for-dynamic-row-level-security"
   },
   AVOID_USING_THE_IFERROR_FUNCTION: {
     text: `Example
@@ -6848,9 +7711,10 @@ Quirks
 
 - The rule counts items, not what they do. A group with one item whose expression is empty leaves this rule's condition, and EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION picks it up instead.
 - pbiplint reads a table as a calculation group when the table carries a calculationGroup block, whatever its partition says, and rules scoped to tables or calculated tables then pass over it.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could hold its calculation items, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/calculation-groups-with-no-calculation-items`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable 'Time Intelligence'\n\n	calculationGroup\n\n	column 'Time Calculation'\n		dataType: string\n		summarizeBy: none\n		sourceColumn: Name\n\n	partition 'Time Intelligence' = calculationGroup\n		mode: import\n\ntable Date\n	column Date\n		dataType: dateTime\n		sourceColumn: Date\n```\n\n**After the fix**\n\n```tmdl\ntable 'Time Intelligence'\n\n	calculationGroup\n\n		calculationItem YTD = CALCULATE(SELECTEDMEASURE(), DATESYTD('Date'[Date]))\n\n	column 'Time Calculation'\n		dataType: string\n		summarizeBy: none\n		sourceColumn: Name\n\n	partition 'Time Intelligence' = calculationGroup\n		mode: import\n\ntable Date\n	column Date\n		dataType: dateTime\n		sourceColumn: Date\n```\n\n### Why it matters\n\nA calculation group with no items still appears in the field list as a table with one column, and dropping that column on a visual does nothing. It is usually a group that was started and abandoned, and it puzzles whoever finds it later.\n\n### How to fix it\n\nIn Power BI Desktop, open Model view, find the group under Calculation groups in the Model explorer pane, choose New calculation item, and write its DAX in the formula bar. In the TMDL file the group is a `calculationGroup` block under the table, and each item is a `calculationItem` inside it with its DAX after the `=`. If the group is not wanted, delete the table: in Desktop, right-click it in the Data pane and choose Delete from model; in the project, remove its file from the `tables` folder and its `ref table` line from `model.tmdl`.\n\n### When to ignore it\n\nThe one moment the finding is noise is while you are building the group, between creating it and writing the first item, when it tells you something you already know. There is no reason to ship one: an empty group is a field in the list that does nothing when a report author uses it.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The rule counts items, not what they do. A group with one item whose expression is empty leaves this rule's condition, and `EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION` picks it up instead.\n- pbiplint reads a table as a calculation group when the table carries a `calculationGroup` block, whatever its partition says, and rules scoped to tables or calculated tables then pass over it.\n\nRead more: https://pbiplint.com/rules/calculation-groups-with-no-calculation-items"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable 'Time Intelligence'\n\n	calculationGroup\n\n	column 'Time Calculation'\n		dataType: string\n		summarizeBy: none\n		sourceColumn: Name\n\n	partition 'Time Intelligence' = calculationGroup\n		mode: import\n\ntable Date\n	column Date\n		dataType: dateTime\n		sourceColumn: Date\n```\n\n**After the fix**\n\n```tmdl\ntable 'Time Intelligence'\n\n	calculationGroup\n\n		calculationItem YTD = CALCULATE(SELECTEDMEASURE(), DATESYTD('Date'[Date]))\n\n	column 'Time Calculation'\n		dataType: string\n		summarizeBy: none\n		sourceColumn: Name\n\n	partition 'Time Intelligence' = calculationGroup\n		mode: import\n\ntable Date\n	column Date\n		dataType: dateTime\n		sourceColumn: Date\n```\n\n### Why it matters\n\nA calculation group with no items still appears in the field list as a table with one column, and dropping that column on a visual does nothing. It is usually a group that was started and abandoned, and it puzzles whoever finds it later.\n\n### How to fix it\n\nIn Power BI Desktop, open Model view, find the group under Calculation groups in the Model explorer pane, choose New calculation item, and write its DAX in the formula bar. In the TMDL file the group is a `calculationGroup` block under the table, and each item is a `calculationItem` inside it with its DAX after the `=`. If the group is not wanted, delete the table: in Desktop, right-click it in the Data pane and choose Delete from model; in the project, remove its file from the `tables` folder and its `ref table` line from `model.tmdl`.\n\n### When to ignore it\n\nThe one moment the finding is noise is while you are building the group, between creating it and writing the first item, when it tells you something you already know. There is no reason to ship one: an empty group is a field in the list that does nothing when a report author uses it.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"CALCULATION_GROUPS_WITH_NO_CALCULATION_ITEMS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The rule counts items, not what they do. A group with one item whose expression is empty leaves this rule's condition, and `EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION` picks it up instead.\n- pbiplint reads a table as a calculation group when the table carries a `calculationGroup` block, whatever its partition says, and rules scoped to tables or calculated tables then pass over it.\n- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could hold its calculation items, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file's own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/calculation-groups-with-no-calculation-items"
   },
   "CHECK_IF_BI-DIRECTIONAL_AND_MANY-TO-MANY_RELATIONSHIPS_ARE_VALID": {
     text: `Example
@@ -7066,9 +7930,10 @@ Quirks
 - Only data columns are read. pbiplint treats a column as calculated when its declaration carries an expression, and as a calculated table column when the table's partition is a calculated one, so neither is reported here.
 - Only the presence of the property is tested, never what it names. A sourceColumn that names a column the query does not produce passes the rule and fails the refresh.
 - A sourceColumn: line with nothing after it counts as missing, the same as no line at all.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could hold a calculated partition, which makes the column a calculated table's, with no source column of its own, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/data-columns-must-have-a-source-column`,
-    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column \'Order ID\'\n		dataType: int64\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n\n	partition Sales = m\n		mode: import\n		source =\n				let\n					Source = Sql.Database("localhost", "Sales"),\n					Sales = Source{[Schema="dbo",Item="Sales"]}[Data]\n				in\n					Sales\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column \'Order ID\'\n		dataType: int64\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: import\n		source =\n				let\n					Source = Sql.Database("localhost", "Sales"),\n					Sales = Source{[Schema="dbo",Item="Sales"]}[Data]\n				in\n					Sales\n```\n\n### Why it matters\n\nA data column is filled from a column in the partition query, and the source column name is how the engine finds it. Without it, processing fails for the whole table, with an error that names the column but not the cause.\n\n### How to fix it\n\nPower BI Desktop writes `sourceColumn` whenever it adds a column to a table, so a finding here means the column was written or edited by hand, or arrived in a migration. In the TMDL file, add a `sourceColumn:` line under the column, naming the field the partition\'s query produces and spelling it the way the query spells it. Where the query no longer produces it, the fix runs the other way: add the column back in Power Query, under Transform data, so the next refresh delivers it, or take the column out of the model, in Desktop by right-clicking it in the Data pane and choosing Delete from model, or by removing its `column` block from the table\'s TMDL file.\n\n### When to ignore it\n\nThere is none. A data column with no source column stops the whole table from loading, so the finding is a refresh failure reported before the refresh. The one thing worth checking is whether the column was meant to be a calculated column: if it was, give it a DAX expression instead, and the column leaves this rule for `EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION`, which asks the same question of the expression.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Only data columns are read. pbiplint treats a column as calculated when its declaration carries an expression, and as a calculated table column when the table\'s partition is a calculated one, so neither is reported here.\n- Only the presence of the property is tested, never what it names. A `sourceColumn` that names a column the query does not produce passes the rule and fails the refresh.\n- A `sourceColumn:` line with nothing after it counts as missing, the same as no line at all.\n\nRead more: https://pbiplint.com/rules/data-columns-must-have-a-source-column'
+    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column \'Order ID\'\n		dataType: int64\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n\n	partition Sales = m\n		mode: import\n		source =\n				let\n					Source = Sql.Database("localhost", "Sales"),\n					Sales = Source{[Schema="dbo",Item="Sales"]}[Data]\n				in\n					Sales\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column \'Order ID\'\n		dataType: int64\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: import\n		source =\n				let\n					Source = Sql.Database("localhost", "Sales"),\n					Sales = Source{[Schema="dbo",Item="Sales"]}[Data]\n				in\n					Sales\n```\n\n### Why it matters\n\nA data column is filled from a column in the partition query, and the source column name is how the engine finds it. Without it, processing fails for the whole table, with an error that names the column but not the cause.\n\n### How to fix it\n\nPower BI Desktop writes `sourceColumn` whenever it adds a column to a table, so a finding here means the column was written or edited by hand, or arrived in a migration. In the TMDL file, add a `sourceColumn:` line under the column, naming the field the partition\'s query produces and spelling it the way the query spells it. Where the query no longer produces it, the fix runs the other way: add the column back in Power Query, under Transform data, so the next refresh delivers it, or take the column out of the model, in Desktop by right-clicking it in the Data pane and choosing Delete from model, or by removing its `column` block from the table\'s TMDL file.\n\n### When to ignore it\n\nThere is none. A data column with no source column stops the whole table from loading, so the finding is a refresh failure reported before the refresh. The one thing worth checking is whether the column was meant to be a calculated column: if it was, give it a DAX expression instead, and the column leaves this rule for `EXPRESSION_RELIANT_OBJECTS_MUST_HAVE_AN_EXPRESSION`, which asks the same question of the expression.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"DATA_COLUMNS_MUST_HAVE_A_SOURCE_COLUMN": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Only data columns are read. pbiplint treats a column as calculated when its declaration carries an expression, and as a calculated table column when the table\'s partition is a calculated one, so neither is reported here.\n- Only the presence of the property is tested, never what it names. A `sourceColumn` that names a column the query does not produce passes the rule and fails the refresh.\n- A `sourceColumn:` line with nothing after it counts as missing, the same as no line at all.\n- The rule also needs every part of a table\'s declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could hold a calculated partition, which makes the column a calculated table\'s, with no source column of its own, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file\'s own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/data-columns-must-have-a-source-column'
   },
   "DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE": {
     text: `Example
@@ -7122,9 +7987,10 @@ Quirks
 - The data category comparison is exact and case-sensitive. A file that says dataCategory: time does not count as marked.
 - The key has to be a DateTime column. A calendar keyed on an integer date key is reported however it is categorized.
 - Calculated tables are in scope and calculation groups are not, so a calendar built with CALENDAR is checked and a calculation group called Date Intelligence is left alone.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could mark the table, hold its key column, or make it a calculation group, which the rule leaves out, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/date-calendar-tables-should-be-marked-as-a-date-table`,
-    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Date\n	column Date\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n**After the fix**\n\n```tmdl\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n### Why it matters\n\nMarking the date table tells the engine which column is the calendar key, and every time intelligence function relies on it: DATESYTD, SAMEPERIODLASTYEAR, and the rest return wrong or blank results over an unmarked table without raising any error. Marking it also lets you turn off Auto date/time, which otherwise adds a hidden date table for every date column in the model.\n\n### How to fix it\n\nIn Power BI Desktop, select the table in the Data pane, open Table tools, choose Mark as date table, and pick the column that holds the dates. Desktop checks the column before it accepts it: the values must be unique, have no blanks, carry the same time of day throughout, and run without a gap from the first day to the last. In the TMDL file the result is `dataCategory: Time` on the table and `isKey` on that column, and both have to be present before the finding clears. Where the column fails the check, fix it where it is loaded: in Transform data, remove the time part with Date under the Transform tab, drop the duplicate rows, and fill the gaps by generating the calendar rather than deriving it from a fact table. Where the table is not a calendar at all and only the name caught it, rename it or ignore the finding on it.\n\n### When to ignore it\n\nThe name test is a plain substring, so Updates, Candidates, and Mandates are all reported with no date in them anywhere. Those findings are noise and the rule has no way to see it. A table that holds dates without being a calendar is the more interesting case: an Event Calendar of scheduled events, or a Date Changes audit log. Marking either one would be wrong, because it is a fact table and the marking declares a calendar key. A calendar at a grain other than the day is the third case, for example a Fiscal Calendar of one row per period; Mark as date table requires one contiguous row per day, so the table cannot be marked and the finding stays for as long as the table exists. What is not a legitimate exception is the model\'s real day-grain calendar left unmarked because time intelligence appears to work in a quick test; it fails quietly at the edges of the range.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The table name is upper-cased before the test and the match is a substring, so `Date`, `date`, and `DATE_DIM` all count, and so do Updates and Candidates.\n- The data category comparison is exact and case-sensitive. A file that says `dataCategory: time` does not count as marked.\n- The key has to be a DateTime column. A calendar keyed on an integer date key is reported however it is categorized.\n- Calculated tables are in scope and calculation groups are not, so a calendar built with CALENDAR is checked and a calculation group called Date Intelligence is left alone.\n\nRead more: https://pbiplint.com/rules/date-calendar-tables-should-be-marked-as-a-date-table'
+    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Date\n	column Date\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n**After the fix**\n\n```tmdl\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n### Why it matters\n\nMarking the date table tells the engine which column is the calendar key, and every time intelligence function relies on it: DATESYTD, SAMEPERIODLASTYEAR, and the rest return wrong or blank results over an unmarked table without raising any error. Marking it also lets you turn off Auto date/time, which otherwise adds a hidden date table for every date column in the model.\n\n### How to fix it\n\nIn Power BI Desktop, select the table in the Data pane, open Table tools, choose Mark as date table, and pick the column that holds the dates. Desktop checks the column before it accepts it: the values must be unique, have no blanks, carry the same time of day throughout, and run without a gap from the first day to the last. In the TMDL file the result is `dataCategory: Time` on the table and `isKey` on that column, and both have to be present before the finding clears. Where the column fails the check, fix it where it is loaded: in Transform data, remove the time part with Date under the Transform tab, drop the duplicate rows, and fill the gaps by generating the calendar rather than deriving it from a fact table. Where the table is not a calendar at all and only the name caught it, rename it or ignore the finding on it.\n\n### When to ignore it\n\nThe name test is a plain substring, so Updates, Candidates, and Mandates are all reported with no date in them anywhere. Those findings are noise and the rule has no way to see it. A table that holds dates without being a calendar is the more interesting case: an Event Calendar of scheduled events, or a Date Changes audit log. Marking either one would be wrong, because it is a fact table and the marking declares a calendar key. A calendar at a grain other than the day is the third case, for example a Fiscal Calendar of one row per period; Mark as date table requires one contiguous row per day, so the table cannot be marked and the finding stays for as long as the table exists. What is not a legitimate exception is the model\'s real day-grain calendar left unmarked because time intelligence appears to work in a quick test; it fails quietly at the edges of the range.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"DATE/CALENDAR_TABLES_SHOULD_BE_MARKED_AS_A_DATE_TABLE": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The table name is upper-cased before the test and the match is a substring, so `Date`, `date`, and `DATE_DIM` all count, and so do Updates and Candidates.\n- The data category comparison is exact and case-sensitive. A file that says `dataCategory: time` does not count as marked.\n- The key has to be a DateTime column. A calendar keyed on an integer date key is reported however it is categorized.\n- Calculated tables are in scope and calculation groups are not, so a calendar built with CALENDAR is checked and a calculation group called Date Intelligence is left alone.\n- The rule also needs every part of a table\'s declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could mark the table, hold its key column, or make it a calculation group, which the rule leaves out, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file\'s own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/date-calendar-tables-should-be-marked-as-a-date-table'
   },
   DATECOLUMN_FORMATSTRING: {
     text: `Example
@@ -7227,13 +8093,14 @@ Quirks
 
 - Calculation items are in the rule's scope but never fire, because Tabular Editor does not resolve bare column references inside calculation items and pbiplint matches that.
 - A bare name that matches any measure in the model is treated as a measure reference, so a column that shares its name with a measure is never flagged.
-- A bare name that matches no measure is looked for on the expression's own table first, then on every other table in model order, so a finding can be raised by a column that lives on a table the expression never mentions.
+- A bare name that matches no measure is looked for on the expression's own table first, then on every other table in the order pbiplint reads the model's files, so a finding can be raised by a column that lives on a table the expression never mentions.
 - References are found by pattern matching, so a bare [Column] inside a string literal or a comment counts.
 - A measure's dynamic format string is read together with its expression, so a bare column reference written inside formatStringDefinition reports the measure that carries it.
 - Calculated columns and calculated tables are out of scope, so a bare column reference in either is not reported.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because a bare name reads as a column only when the model has no measure of that name, and a measure of that name could be in what pbiplint missed; pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/dax-columns-fully-qualified`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	measure 'Total Sales' = SUM([Amount])\n		formatString: #,0\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nIn DAX a bare `[Name]` is the convention for a measure. A column written the same way reads as a measure to everyone who maintains the model, and the two behave differently in a row context, so the expression is misread before it is ever debugged. The bare form also breaks when the column moves to another table, or when a measure with the same name is added and the engine binds to that instead.\n\n### How to fix it\n\nPut the table name in front of every column reference:\n\n```\nTotal Sales = SUM ( 'Sales'[Amount] )\n```\n\nIn Power BI Desktop, select the measure in the Data pane and edit it in the formula bar, which completes the qualified form as soon as you start typing the table name. A row-level security filter is edited under Modeling, Manage roles. In the TMDL file, edit the expression after `measure 'Total Sales' =`, or the filter after `tablePermission Sales =` inside the role.\n\n### When to ignore it\n\nThere is no case for the bare form. The rule is worth reading as a warning rather than a style note: the reference that fires it resolved to a column because no measure of that name exists today, and the day someone adds one, the expression silently starts reading the measure instead. Qualifying it is what stops that.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = DAX_COLUMNS_FULLY_QUALIFIED` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"DAX_COLUMNS_FULLY_QUALIFIED\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Calculation items are in the rule's scope but never fire, because Tabular Editor does not resolve bare column references inside calculation items and pbiplint matches that.\n- A bare name that matches any measure in the model is treated as a measure reference, so a column that shares its name with a measure is never flagged.\n- A bare name that matches no measure is looked for on the expression's own table first, then on every other table in model order, so a finding can be raised by a column that lives on a table the expression never mentions.\n- References are found by pattern matching, so a bare `[Column]` inside a string literal or a comment counts.\n- A measure's dynamic format string is read together with its expression, so a bare column reference written inside `formatStringDefinition` reports the measure that carries it.\n- Calculated columns and calculated tables are out of scope, so a bare column reference in either is not reported.\n\nRead more: https://pbiplint.com/rules/dax-columns-fully-qualified"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	measure 'Total Sales' = SUM([Amount])\n		formatString: #,0\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nIn DAX a bare `[Name]` is the convention for a measure. A column written the same way reads as a measure to everyone who maintains the model, and the two behave differently in a row context, so the expression is misread before it is ever debugged. The bare form also breaks when the column moves to another table, or when a measure with the same name is added and the engine binds to that instead.\n\n### How to fix it\n\nPut the table name in front of every column reference:\n\n```\nTotal Sales = SUM ( 'Sales'[Amount] )\n```\n\nIn Power BI Desktop, select the measure in the Data pane and edit it in the formula bar, which completes the qualified form as soon as you start typing the table name. A row-level security filter is edited under Modeling, Manage roles. In the TMDL file, edit the expression after `measure 'Total Sales' =`, or the filter after `tablePermission Sales =` inside the role.\n\n### When to ignore it\n\nThere is no case for the bare form. The rule is worth reading as a warning rather than a style note: the reference that fires it resolved to a column because no measure of that name exists today, and the day someone adds one, the expression silently starts reading the measure instead. Qualifying it is what stops that.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = DAX_COLUMNS_FULLY_QUALIFIED` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"DAX_COLUMNS_FULLY_QUALIFIED\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Calculation items are in the rule's scope but never fire, because Tabular Editor does not resolve bare column references inside calculation items and pbiplint matches that.\n- A bare name that matches any measure in the model is treated as a measure reference, so a column that shares its name with a measure is never flagged.\n- A bare name that matches no measure is looked for on the expression's own table first, then on every other table in the order pbiplint reads the model's files, so a finding can be raised by a column that lives on a table the expression never mentions.\n- References are found by pattern matching, so a bare `[Column]` inside a string literal or a comment counts.\n- A measure's dynamic format string is read together with its expression, so a bare column reference written inside `formatStringDefinition` reports the measure that carries it.\n- Calculated columns and calculated tables are out of scope, so a bare column reference in either is not reported.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because a bare name reads as a column only when the model has no measure of that name, and a measure of that name could be in what pbiplint missed; pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/dax-columns-fully-qualified"
   },
   DAX_MEASURES_UNQUALIFIED: {
     text: `Example
@@ -7542,9 +8409,10 @@ Quirks
 - The rule reads relationships by the table names written in them, matched exactly. A relationship that spells the table differently, in letter case or after a rename, counts for the name it carries and not for the table, so the table is still reported.
 - Visibility is not read. A hidden measures table with a single hidden column is reported like any other table.
 - A table with no partitions, such as one whose file was only partly written, is a table to this rule and is reported when nothing relates to it.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the table's relationships could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/ensure-tables-have-relationships`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		sourceColumn: ProductID\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n	column Category\n		dataType: string\n		sourceColumn: Category\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		sourceColumn: ProductID\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n	column Category\n		dataType: string\n		sourceColumn: Category\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n```\n\n### Why it matters\n\nA table that relates to nothing filters nothing and is filtered by nothing, so a visual that mixes its columns with another table's shows the same value repeated on every row. Sometimes that is the point: a parameter table, a measure table, or a security lookup that is read from DAX. More often it is a table that was loaded and never wired up, or a relationship that was deleted by accident.\n\n### How to fix it\n\nIn Power BI Desktop, open Model view and drag the key column of the fact table onto the matching column of the dimension, or use Manage relationships, New, and pick the two columns. Check the cardinality and the cross filter direction that Desktop proposes before you accept them. In the TMDL file a relationship is a `relationship` block of its own, with `fromColumn` on the many side and `toColumn` on the one side, each written as `Table.Column`. If the table really does stand alone, leave it as it is.\n\n### When to ignore it\n\nA table that is meant to stand alone is the case to ignore: a what-if parameter table, a field parameter table, a table of slicer labels that a measure reads with SELECTEDVALUE, a list of thresholds compared against measures, or a lookup table read only by a row-level security filter. Check that the table is one of those before you ignore the finding, because the same line appears when a relationship was dropped in a merge or when a rename left the relationship pointing at a table name that no longer exists.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = ENSURE_TABLES_HAVE_RELATIONSHIPS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"ENSURE_TABLES_HAVE_RELATIONSHIPS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The rule reads relationships by the table names written in them, matched exactly. A relationship that spells the table differently, in letter case or after a rename, counts for the name it carries and not for the table, so the table is still reported.\n- Visibility is not read. A hidden measures table with a single hidden column is reported like any other table.\n- A table with no partitions, such as one whose file was only partly written, is a table to this rule and is reported when nothing relates to it.\n\nRead more: https://pbiplint.com/rules/ensure-tables-have-relationships"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		sourceColumn: ProductID\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n	column Category\n		dataType: string\n		sourceColumn: Category\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		sourceColumn: ProductID\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n	column Category\n		dataType: string\n		sourceColumn: Category\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n```\n\n### Why it matters\n\nA table that relates to nothing filters nothing and is filtered by nothing, so a visual that mixes its columns with another table's shows the same value repeated on every row. Sometimes that is the point: a parameter table, a measure table, or a security lookup that is read from DAX. More often it is a table that was loaded and never wired up, or a relationship that was deleted by accident.\n\n### How to fix it\n\nIn Power BI Desktop, open Model view and drag the key column of the fact table onto the matching column of the dimension, or use Manage relationships, New, and pick the two columns. Check the cardinality and the cross filter direction that Desktop proposes before you accept them. In the TMDL file a relationship is a `relationship` block of its own, with `fromColumn` on the many side and `toColumn` on the one side, each written as `Table.Column`. If the table really does stand alone, leave it as it is.\n\n### When to ignore it\n\nA table that is meant to stand alone is the case to ignore: a what-if parameter table, a field parameter table, a table of slicer labels that a measure reads with SELECTEDVALUE, a list of thresholds compared against measures, or a lookup table read only by a row-level security filter. Check that the table is one of those before you ignore the finding, because the same line appears when a relationship was dropped in a merge or when a rename left the relationship pointing at a table name that no longer exists.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = ENSURE_TABLES_HAVE_RELATIONSHIPS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"ENSURE_TABLES_HAVE_RELATIONSHIPS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The rule reads relationships by the table names written in them, matched exactly. A relationship that spells the table differently, in letter case or after a rename, counts for the name it carries and not for the table, so the table is still reported.\n- Visibility is not read. A hidden measures table with a single hidden column is reported like any other table.\n- A table with no partitions, such as one whose file was only partly written, is a table to this rule and is reported when nothing relates to it.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the table's relationships could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/ensure-tables-have-relationships"
   },
   ENSURE_THEME_COLOURS: {
     text: `Example
@@ -8124,9 +8992,88 @@ Quirks
 - The suffix is a space followed by Flag, so Priority Flag is reported and PriorityFlag is not.
 - Hidden columns, and columns in hidden tables, are skipped by both halves.
 - The Is half needs the type to be exactly whole number, so a decimal IsActive is not reported. The Flag half fires on every type that is not text, boolean and DateTime included.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could hide the table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/format-flag-columns-as-yes-no-value-strings`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column IsReturned\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: IsReturned\n\n	column 'Priority Flag'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Priority Flag\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column IsReturned\n		dataType: string\n		summarizeBy: none\n		sourceColumn: IsReturned\n\n	column 'Priority Flag'\n		dataType: string\n		summarizeBy: none\n		sourceColumn: Priority Flag\n```\n\n### Why it matters\n\nA 0 or 1 in a slicer, a legend, or a table column tells the reader nothing without a lookup, and a whole-number flag is summed by default, so a card labeled Is Active shows a count of true rows that looks like something else. Yes and No read correctly everywhere and cannot be aggregated by accident.\n\n### How to fix it\n\nThe values have to change, not just the type, so the fix lives upstream of the model. In Power BI Desktop, choose Transform data, select the query, and either add a conditional column that returns Yes or No or use Replace Values on the column itself, then set the column's type to Text in Power Query. Where the query reads a view or a stored procedure, do the same in the select list and the model gets the text column already formed. The Data type box under Column tools changes the type in place on an import model but leaves the values as 0 and 1, so it is not the fix on its own. If a measure counts the flag, keep the numeric column and hide it, which also takes it out of this rule's reach.\n\n### When to ignore it\n\nA column whose type is already boolean is the common false alarm: Power BI shows it as True and False, which reads as well as Yes and No, and the rule reports it only because it tests for text. The name tests catch words that are not flags at all, so a whole-number Issue Count or Isotope Number is noise on the Is side. The case worth acting on is the one the rule was written for: a visible 0 and 1 column that a report author has to decode.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Both name tests are case-sensitive. The prefix is the two characters Is, so a whole-number column called Island or Issue Count is reported, and one called isActive is not.\n- The suffix is a space followed by Flag, so Priority Flag is reported and PriorityFlag is not.\n- Hidden columns, and columns in hidden tables, are skipped by both halves.\n- The Is half needs the type to be exactly whole number, so a decimal IsActive is not reported. The Flag half fires on every type that is not text, boolean and DateTime included.\n\nRead more: https://pbiplint.com/rules/format-flag-columns-as-yes-no-value-strings"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column IsReturned\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: IsReturned\n\n	column 'Priority Flag'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Priority Flag\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column IsReturned\n		dataType: string\n		summarizeBy: none\n		sourceColumn: IsReturned\n\n	column 'Priority Flag'\n		dataType: string\n		summarizeBy: none\n		sourceColumn: Priority Flag\n```\n\n### Why it matters\n\nA 0 or 1 in a slicer, a legend, or a table column tells the reader nothing without a lookup, and a whole-number flag is summed by default, so a card labeled Is Active shows a count of true rows that looks like something else. Yes and No read correctly everywhere and cannot be aggregated by accident.\n\n### How to fix it\n\nThe values have to change, not just the type, so the fix lives upstream of the model. In Power BI Desktop, choose Transform data, select the query, and either add a conditional column that returns Yes or No or use Replace Values on the column itself, then set the column's type to Text in Power Query. Where the query reads a view or a stored procedure, do the same in the select list and the model gets the text column already formed. The Data type box under Column tools changes the type in place on an import model but leaves the values as 0 and 1, so it is not the fix on its own. If a measure counts the flag, keep the numeric column and hide it, which also takes it out of this rule's reach.\n\n### When to ignore it\n\nA column whose type is already boolean is the common false alarm: Power BI shows it as True and False, which reads as well as Yes and No, and the rule reports it only because it tests for text. The name tests catch words that are not flags at all, so a whole-number Issue Count or Isotope Number is noise on the Is side. The case worth acting on is the one the rule was written for: a visible 0 and 1 column that a report author has to decode.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"FORMAT_FLAG_COLUMNS_AS_YES/NO_VALUE_STRINGS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Both name tests are case-sensitive. The prefix is the two characters Is, so a whole-number column called Island or Issue Count is reported, and one called isActive is not.\n- The suffix is a space followed by Flag, so Priority Flag is reported and PriorityFlag is not.\n- Hidden columns, and columns in hidden tables, are skipped by both halves.\n- The Is half needs the type to be exactly whole number, so a decimal IsActive is not reported. The Flag half fires on every type that is not text, boolean and DateTime included.\n- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could hide the table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file's own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/format-flag-columns-as-yes-no-value-strings"
+  },
+  HARDCODED_PERIOD_IN_DAX: {
+    text: `Example
+
+Fires the rule
+
+table Sales
+	column Amount
+		dataType: decimal
+		sourceColumn: Amount
+	column 'Order Date'
+		dataType: dateTime
+		sourceColumn: Order Date
+	measure 'Current Year Sales' = CALCULATE(SUM(Sales[Amount]), YEAR(Sales[Order Date]) = 2025)
+		formatString: #,0
+
+After the fix
+
+table Sales
+	column Amount
+		dataType: decimal
+		sourceColumn: Amount
+	column 'Order Date'
+		dataType: dateTime
+		sourceColumn: Order Date
+	measure 'Current Year Sales' = CALCULATE(SUM(Sales[Amount]), YEAR(Sales[Order Date]) = YEAR(TODAY()))
+		formatString: #,0
+
+Why it matters
+
+A year typed into DAX is right for the year it was written in and quietly wrong after it. A measure named Current Year Sales that filters on 2025 still shows 2025's sales all through 2026, under the same name, with no error, and a reader has no way to tell.
+
+A date table built with CALENDAR(DATE(2020, 1, 1), DATE(2026, 12, 31)) has no rows after December 31, 2026. From January 1, 2027, new rows in a table related to it find no date there. A visual that groups by the date table's columns shows them under a blank value: the blank virtual row (https://learn.microsoft.com/power-bi/transform-model/desktop-relationships-understand#regular-relationships) Power BI adds when a value on a relationship's many side has no match on its one side. A filter or slicer on the date table leaves them out, and time intelligence stops at the table's last day. Microsoft's guidance on date tables (https://learn.microsoft.com/power-bi/guidance/model-date-tables#generate-with-dax) says CALENDAR's start and end can come from other DAX functions, like MAX(Sales[OrderDate]). An end taken from the data moves with it.
+
+How to fix it
+
+Take the period from something that moves with time.
+
+- For the current period, use TODAY(): YEAR(TODAY()) for this year, as the fixed example does, or TODAY() itself for an as-of date.
+- For the latest period in the data, which stays right when a refresh runs late, take it from the fact table: YEAR(MAX(Sales[Order Date])). Inside a measure, MAX reads only the dates the visual's filters leave, so write CALCULATE(MAX(Sales[Order Date]), REMOVEFILTERS()) when the measure needs the latest date in all the data.
+- When a report reader should choose the period, add a parameter: on the Modeling tab, select New parameter, then Numeric range, and set its Minimum and Maximum to the first and last years it should offer. Power BI Desktop creates the parameter and, with it, a measure that gives the parameter's current value (what-if parameters (https://learn.microsoft.com/power-bi/transform-model/desktop-what-if#create-a-parameter)), and your measure compares with that measure instead of a number. Parameters are designed for measures (https://learn.microsoft.com/power-bi/transform-model/desktop-what-if#considerations-and-limitations), so this route suits a measure, not a calculated column.
+
+A filter argument of CALCULATE written as a comparison, as in the example, can't reference a measure or use a nested CALCULATE (https://learn.microsoft.com/dax/calculate-function-dax#boolean-filter-expressions), so put the latest year or the parameter's value in a variable first:
+
+Latest Year Sales =
+VAR LatestYear = YEAR ( CALCULATE ( MAX ( Sales[Order Date] ), REMOVEFILTERS () ) )
+RETURN
+    CALCULATE ( SUM ( Sales[Amount] ), YEAR ( Sales[Order Date] ) = LatestYear )
+
+For a date table, end CALENDAR on the data rather than on a day:
+
+Date = CALENDAR ( DATE ( 2020, 1, 1 ), DATE ( YEAR ( MAX ( Sales[Order Date] ) ), 12, 31 ) )
+
+This ends on the last day of the latest year in Sales, so the table spans full years, as Microsoft's guidance (https://learn.microsoft.com/power-bi/guidance/model-date-tables) asks of a date table, and grows when a refresh brings a new year. CALENDARAUTO (https://learn.microsoft.com/dax/calendarauto-function-dax#remarks) does the same from every date in the model outside calculated columns and tables, so a birth date or a placeholder such as December 31, 9999 stretches it too. To reach the end of the current year whether or not the data gets there yet, end CALENDAR on DATE ( YEAR ( TODAY () ), 12, 31 ) instead.
+
+In Power BI Desktop, select a measure, calculated column, or calculated table in the Data pane and edit its DAX in the formula bar. A calculation item is edited in Model view: select Model at the top of the Data pane to open Model explorer (https://learn.microsoft.com/power-bi/transform-model/model-explorer#find-model-explorer), then select the calculation item under its calculation group, and its DAX opens in the DAX formula bar (calculation groups (https://learn.microsoft.com/power-bi/transform-model/calculation-groups#add-a-new-calculation-group-in-model-view)). In TMDL, edit the expression after the object's =, or, for a date table, the source of its calculated partition.
+
+When to ignore it
+
+A fixed period is sometimes the point: a baseline year a measure compares against, a known event such as a change of data source or a day of bad data, a cohort such as customers whose first purchase was in 2023, a rule that changed in a given year, or sample data that never changes. A date table can end on purpose too, such as one that must stop at a contract's last day.
+
+Often the better move is a name that says so. An object whose name carries its year, such as Sales 2024 or Growth from 19/20, reads as deliberate to anyone who opens the model, and the rule leaves it alone.
+
+To ignore this rule on one object, add annotation pbiplint.ignore = HARDCODED_PERIOD_IN_DAX under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set "HARDCODED_PERIOD_IN_DAX": "off" under rules in pbiplint.config.json.
+
+Quirks
+
+- An object whose name carries one of the years it fixes, as four digits (Sales 2024) or as the year's last two digits with no digit beside them (Jan-24, 19/20), is left out, since such an object is almost always meant to fix its year. Two digits can match by chance, as Top 20 beside a fixed 2020 does, which hides that one object.
+- A date string at a date table's end whose day and month read either way, such as "01/02/2026", is quoted as written: DAX reads it by the model's culture, which pbiplint does not settle.
+- A year outside 1950 to 2049 is left alone, such as DATE(9999, 12, 31) as an open end or DATE(1900, 1, 1) as a default, and so is the Unix epoch, DATE(1970, 1, 1), the base of a conversion such as DATE(1970, 1, 1) + 'Log'[UnixTime] / 86400. A date table's end is reported whatever its year or day.
+- A year compared with <, <=, >, or >= is left out, since in real models it is usually a cut-off or a cohort, and so are year-month keys such as 202306 and date strings outside a date table's end, which never went stale there. Year arithmetic such as [Year] - 2025 and fiscal-year labels such as "2024/25" are left out too, since each came up in too few models to judge. A DATE() with a fixed year is read whatever it is compared with, though, so 'Sales'[Order Date] >= DATE(2024, 1, 1) is reported.
+- From a calculated table, the rule reads only where its CALENDAR calls end, so a year compared inside a date table's ADDCOLUMNS is not reported. The rest of a calculated table's DAX, user-defined functions, and row-level security filters are left out, since in real models they mostly hold inline data, sample generators, or deliberate cut-offs. Format string expressions are not read either, since they choose how a value is shown rather than which rows are counted, and fixed dates in Power Query (M) are left to pbiplint's Power Query rules, which are still to come. A date table end reached through a measure or written with arithmetic, such as DATE(2026, 12, 31) + 1, is not taken for a fixed end, and a DATE() inside a CALENDAR or GENERATESERIES call in a measure, a calculated column, or a calculation item is taken for a table's bound and left alone.
+- A month or a quarter compared with a number, a year-end date such as "6/30" given to DATESYTD, and a DATE() given straight to FORMAT with a format that shows no year, as in FORMAT(DATE(2000, [Month], 1), "mmmm") for a month's name, never fire: none of them goes stale. The rule counts a format as showing the year when it has a y in it or is one of the named formats General Date, Long Date, Medium Date, and Short Date, so FORMAT(DATE(2024, 12, 31), "Long Date") is reported. A DATE() inside another call within FORMAT is reported whatever the format, as in FORMAT(EOMONTH(DATE(2000, [Month], 1), 0), "mmmm").
+- Year names are read in several languages (year, a\xF1o, anio, jahr, ann\xE9e, anno, jaar, \xE5r, and more), whatever the model's culture.
+- Desktop's own auto date/time tables are left alone, since Desktop builds them itself.
+
+Read more: https://pbiplint.com/rules/hardcoded-period-in-dax`,
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	column 'Order Date'\n		dataType: dateTime\n		sourceColumn: Order Date\n	measure 'Current Year Sales' = CALCULATE(SUM(Sales[Amount]), YEAR(Sales[Order Date]) = 2025)\n		formatString: #,0\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	column 'Order Date'\n		dataType: dateTime\n		sourceColumn: Order Date\n	measure 'Current Year Sales' = CALCULATE(SUM(Sales[Amount]), YEAR(Sales[Order Date]) = YEAR(TODAY()))\n		formatString: #,0\n```\n\n### Why it matters\n\nA year typed into DAX is right for the year it was written in and quietly wrong after it. A measure named Current Year Sales that filters on 2025 still shows 2025's sales all through 2026, under the same name, with no error, and a reader has no way to tell.\n\nA date table built with `CALENDAR(DATE(2020, 1, 1), DATE(2026, 12, 31))` has no rows after December 31, 2026. From January 1, 2027, new rows in a table related to it find no date there. A visual that groups by the date table's columns shows them under a blank value: the [blank virtual row](https://learn.microsoft.com/power-bi/transform-model/desktop-relationships-understand#regular-relationships) Power BI adds when a value on a relationship's many side has no match on its one side. A filter or slicer on the date table leaves them out, and time intelligence stops at the table's last day. [Microsoft's guidance on date tables](https://learn.microsoft.com/power-bi/guidance/model-date-tables#generate-with-dax) says CALENDAR's start and end can come from other DAX functions, like `MAX(Sales[OrderDate])`. An end taken from the data moves with it.\n\n### How to fix it\n\nTake the period from something that moves with time.\n\n- For the current period, use `TODAY()`: `YEAR(TODAY())` for this year, as the fixed example does, or `TODAY()` itself for an as-of date.\n- For the latest period in the data, which stays right when a refresh runs late, take it from the fact table: `YEAR(MAX(Sales[Order Date]))`. Inside a measure, MAX reads only the dates the visual's filters leave, so write `CALCULATE(MAX(Sales[Order Date]), REMOVEFILTERS())` when the measure needs the latest date in all the data.\n- When a report reader should choose the period, add a parameter: on the Modeling tab, select New parameter, then Numeric range, and set its Minimum and Maximum to the first and last years it should offer. Power BI Desktop creates the parameter and, with it, a measure that gives the parameter's current value ([what-if parameters](https://learn.microsoft.com/power-bi/transform-model/desktop-what-if#create-a-parameter)), and your measure compares with that measure instead of a number. Parameters are [designed for measures](https://learn.microsoft.com/power-bi/transform-model/desktop-what-if#considerations-and-limitations), so this route suits a measure, not a calculated column.\n\nA filter argument of CALCULATE written as a comparison, as in the example, [can't reference a measure or use a nested CALCULATE](https://learn.microsoft.com/dax/calculate-function-dax#boolean-filter-expressions), so put the latest year or the parameter's value in a variable first:\n\n```\nLatest Year Sales =\nVAR LatestYear = YEAR ( CALCULATE ( MAX ( Sales[Order Date] ), REMOVEFILTERS () ) )\nRETURN\n    CALCULATE ( SUM ( Sales[Amount] ), YEAR ( Sales[Order Date] ) = LatestYear )\n```\n\nFor a date table, end CALENDAR on the data rather than on a day:\n\n```\nDate = CALENDAR ( DATE ( 2020, 1, 1 ), DATE ( YEAR ( MAX ( Sales[Order Date] ) ), 12, 31 ) )\n```\n\nThis ends on the last day of the latest year in Sales, so the table spans full years, as [Microsoft's guidance](https://learn.microsoft.com/power-bi/guidance/model-date-tables) asks of a date table, and grows when a refresh brings a new year. [CALENDARAUTO](https://learn.microsoft.com/dax/calendarauto-function-dax#remarks) does the same from every date in the model outside calculated columns and tables, so a birth date or a placeholder such as December 31, 9999 stretches it too. To reach the end of the current year whether or not the data gets there yet, end CALENDAR on `DATE ( YEAR ( TODAY () ), 12, 31 )` instead.\n\nIn Power BI Desktop, select a measure, calculated column, or calculated table in the Data pane and edit its DAX in the formula bar. A calculation item is edited in Model view: select Model at the top of the Data pane to open [Model explorer](https://learn.microsoft.com/power-bi/transform-model/model-explorer#find-model-explorer), then select the calculation item under its calculation group, and its DAX opens in the DAX formula bar ([calculation groups](https://learn.microsoft.com/power-bi/transform-model/calculation-groups#add-a-new-calculation-group-in-model-view)). In TMDL, edit the expression after the object's `=`, or, for a date table, the `source` of its `calculated` partition.\n\n### When to ignore it\n\nA fixed period is sometimes the point: a baseline year a measure compares against, a known event such as a change of data source or a day of bad data, a cohort such as customers whose first purchase was in 2023, a rule that changed in a given year, or sample data that never changes. A date table can end on purpose too, such as one that must stop at a contract's last day.\n\nOften the better move is a name that says so. An object whose name carries its year, such as `Sales 2024` or `Growth from 19/20`, reads as deliberate to anyone who opens the model, and the rule leaves it alone.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = HARDCODED_PERIOD_IN_DAX` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"HARDCODED_PERIOD_IN_DAX\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- An object whose name carries one of the years it fixes, as four digits (`Sales 2024`) or as the year's last two digits with no digit beside them (`Jan-24`, `19/20`), is left out, since such an object is almost always meant to fix its year. Two digits can match by chance, as `Top 20` beside a fixed 2020 does, which hides that one object.\n- A date string at a date table's end whose day and month read either way, such as `\"01/02/2026\"`, is quoted as written: DAX reads it by the model's culture, which pbiplint does not settle.\n- A year outside 1950 to 2049 is left alone, such as `DATE(9999, 12, 31)` as an open end or `DATE(1900, 1, 1)` as a default, and so is the Unix epoch, `DATE(1970, 1, 1)`, the base of a conversion such as `DATE(1970, 1, 1) + 'Log'[UnixTime] / 86400`. A date table's end is reported whatever its year or day.\n- A year compared with `<`, `<=`, `>`, or `>=` is left out, since in real models it is usually a cut-off or a cohort, and so are year-month keys such as `202306` and date strings outside a date table's end, which never went stale there. Year arithmetic such as `[Year] - 2025` and fiscal-year labels such as `\"2024/25\"` are left out too, since each came up in too few models to judge. A `DATE()` with a fixed year is read whatever it is compared with, though, so `'Sales'[Order Date] >= DATE(2024, 1, 1)` is reported.\n- From a calculated table, the rule reads only where its CALENDAR calls end, so a year compared inside a date table's ADDCOLUMNS is not reported. The rest of a calculated table's DAX, user-defined functions, and row-level security filters are left out, since in real models they mostly hold inline data, sample generators, or deliberate cut-offs. Format string expressions are not read either, since they choose how a value is shown rather than which rows are counted, and fixed dates in Power Query (M) are left to pbiplint's Power Query rules, which are still to come. A date table end reached through a measure or written with arithmetic, such as `DATE(2026, 12, 31) + 1`, is not taken for a fixed end, and a `DATE()` inside a `CALENDAR` or `GENERATESERIES` call in a measure, a calculated column, or a calculation item is taken for a table's bound and left alone.\n- A month or a quarter compared with a number, a year-end date such as `\"6/30\"` given to DATESYTD, and a `DATE()` given straight to FORMAT with a format that shows no year, as in `FORMAT(DATE(2000, [Month], 1), \"mmmm\")` for a month's name, never fire: none of them goes stale. The rule counts a format as showing the year when it has a `y` in it or is one of the named formats General Date, Long Date, Medium Date, and Short Date, so `FORMAT(DATE(2024, 12, 31), \"Long Date\")` is reported. A `DATE()` inside another call within FORMAT is reported whatever the format, as in `FORMAT(EOMONTH(DATE(2000, [Month], 1), 0), \"mmmm\")`.\n- Year names are read in several languages (year, a\xF1o, anio, jahr, ann\xE9e, anno, jaar, \xE5r, and more), whatever the model's culture.\n- Desktop's own auto date/time tables are left alone, since Desktop builds them itself.\n\nRead more: https://pbiplint.com/rules/hardcoded-period-in-dax"
   },
   HIDDEN_VISUAL_WITH_FIELDS: {
     text: `Example
@@ -8486,20 +9433,22 @@ Where nothing needs the relationship, delete it instead: open the model view, ri
 
 When to ignore it
 
-pbiplint reads the semantic model, not the reports built on it. A report-level measure in a live-connected report can call USERELATIONSHIP, and this rule cannot see it, so check the reports before deleting a relationship that looks unused. The same goes for a relationship activated from a calculated column, a calculated table, or a row-level security filter: none of those is scanned here, and a finding on one of them is noise. A relationship added this week for measures that are still being written is a fair thing to leave alone for a sprint.
+This rule reads the semantic model, not the reports built on it. A report-level measure in a live-connected report can call USERELATIONSHIP, and the rule cannot see it, so check the reports before deleting a relationship that looks unused. The same goes for a relationship activated from a calculated column, a calculated table, or a row-level security filter: none of those is scanned here, and a finding on one of them is noise. A relationship added this week for measures that are still being written is a fair thing to leave alone for a sprint.
 
 To ignore this rule on one object, add annotation pbiplint.ignore = INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set "INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED": "off" under rules in pbiplint.config.json.
 
 Quirks
 
 - Only USERELATIONSHIP(from column, to column) counts as activation; the reversed argument order does not, even though DAX accepts it.
-- Only measures and calculation items are scanned. A USERELATIONSHIP call in a calculated column, a calculated table, or a row-level security filter does not count as activation.
+- Only measures, calculation items, and user-defined functions are scanned. A USERELATIONSHIP call in a calculated column, a calculated table, or a row-level security filter does not count as activation.
+- A USERELATIONSHIP inside a user-defined function counts as activating the relationship, which Tabular Editor does not count, since the source rule reads measures and calculation items only. It counts even when nothing calls the function. When the function receives the two columns as parameters, as in USERELATIONSHIP ( fromColumn, toColumn ), the call names neither column, so the relationship is still reported.
 - The call is matched as text, in any letter case, so a USERELATIONSHIP written inside a string literal or a comment counts as activating the relationship.
 - Either table name may be written bare or in single quotes, and any spacing around the comma is accepted.
 - pbiplint escapes table and column names before building the pattern, which the source rule does not, so names with parentheses cannot break the check.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the DAX that activates the relationship with USERELATIONSHIP could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/inactive-relationships-that-are-never-activated`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		sourceColumn: OrderDate\n	column 'Ship Date'\n		dataType: dateTime\n		sourceColumn: ShipDate\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	measure 'Total Sales' = SUM(Sales[Amount])\n		formatString: #,0\n\ntable Date\n	column Date\n		dataType: dateTime\n		isKey\n		sourceColumn: Date\n\nrelationship Sales_Date_Order\n	fromColumn: Sales.'Order Date'\n	toColumn: Date.Date\n\nrelationship Sales_Date_Ship\n	isActive: false\n	fromColumn: Sales.'Ship Date'\n	toColumn: Date.Date\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		sourceColumn: OrderDate\n	column 'Ship Date'\n		dataType: dateTime\n		sourceColumn: ShipDate\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	measure 'Total Sales' = SUM(Sales[Amount])\n		formatString: #,0\n	measure 'Shipped Sales' = CALCULATE([Total Sales], USERELATIONSHIP(Sales[Ship Date], 'Date'[Date]))\n		formatString: #,0\n\ntable Date\n	column Date\n		dataType: dateTime\n		isKey\n		sourceColumn: Date\n\nrelationship Sales_Date_Order\n	fromColumn: Sales.'Order Date'\n	toColumn: Date.Date\n\nrelationship Sales_Date_Ship\n	isActive: false\n	fromColumn: Sales.'Ship Date'\n	toColumn: Date.Date\n```\n\n### Why it matters\n\nAn inactive relationship does nothing on its own. It exists so a measure can switch it on with USERELATIONSHIP, typically for a second date on a fact table. If no measure does, the relationship is either a leftover from a design that changed or a plan that was never finished, and a report author who sees the dotted line in the model view will assume the filter works.\n\n### How to fix it\n\nWrite the measure the relationship was put there for, so the second date has something that reads it:\n\n```\nShipped Sales = CALCULATE ( [Total Sales], USERELATIONSHIP ( Sales[Ship Date], 'Date'[Date] ) )\n```\n\nIn Power BI Desktop, choose New measure on the Home ribbon and type the expression in the formula bar. In the TMDL file, add the `measure` block to the fact table. Name the columns in the order the relationship declares them, its from column first. DAX takes them either way round, but only that order counts as activation here.\n\nWhere nothing needs the relationship, delete it instead: open the model view, right-click the dotted line, and choose Delete, or remove its `relationship` block from the TMDL file.\n\n### When to ignore it\n\npbiplint reads the semantic model, not the reports built on it. A report-level measure in a live-connected report can call USERELATIONSHIP, and this rule cannot see it, so check the reports before deleting a relationship that looks unused. The same goes for a relationship activated from a calculated column, a calculated table, or a row-level security filter: none of those is scanned here, and a finding on one of them is noise. A relationship added this week for measures that are still being written is a fair thing to leave alone for a sprint.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Only `USERELATIONSHIP(from column, to column)` counts as activation; the reversed argument order does not, even though DAX accepts it.\n- Only measures and calculation items are scanned. A USERELATIONSHIP call in a calculated column, a calculated table, or a row-level security filter does not count as activation.\n- The call is matched as text, in any letter case, so a USERELATIONSHIP written inside a string literal or a comment counts as activating the relationship.\n- Either table name may be written bare or in single quotes, and any spacing around the comma is accepted.\n- pbiplint escapes table and column names before building the pattern, which the source rule does not, so names with parentheses cannot break the check.\n\nRead more: https://pbiplint.com/rules/inactive-relationships-that-are-never-activated"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		sourceColumn: OrderDate\n	column 'Ship Date'\n		dataType: dateTime\n		sourceColumn: ShipDate\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	measure 'Total Sales' = SUM(Sales[Amount])\n		formatString: #,0\n\ntable Date\n	column Date\n		dataType: dateTime\n		isKey\n		sourceColumn: Date\n\nrelationship Sales_Date_Order\n	fromColumn: Sales.'Order Date'\n	toColumn: Date.Date\n\nrelationship Sales_Date_Ship\n	isActive: false\n	fromColumn: Sales.'Ship Date'\n	toColumn: Date.Date\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		sourceColumn: OrderDate\n	column 'Ship Date'\n		dataType: dateTime\n		sourceColumn: ShipDate\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	measure 'Total Sales' = SUM(Sales[Amount])\n		formatString: #,0\n	measure 'Shipped Sales' = CALCULATE([Total Sales], USERELATIONSHIP(Sales[Ship Date], 'Date'[Date]))\n		formatString: #,0\n\ntable Date\n	column Date\n		dataType: dateTime\n		isKey\n		sourceColumn: Date\n\nrelationship Sales_Date_Order\n	fromColumn: Sales.'Order Date'\n	toColumn: Date.Date\n\nrelationship Sales_Date_Ship\n	isActive: false\n	fromColumn: Sales.'Ship Date'\n	toColumn: Date.Date\n```\n\n### Why it matters\n\nAn inactive relationship does nothing on its own. It exists so a measure can switch it on with USERELATIONSHIP, typically for a second date on a fact table. If no measure does, the relationship is either a leftover from a design that changed or a plan that was never finished, and a report author who sees the dotted line in the model view will assume the filter works.\n\n### How to fix it\n\nWrite the measure the relationship was put there for, so the second date has something that reads it:\n\n```\nShipped Sales = CALCULATE ( [Total Sales], USERELATIONSHIP ( Sales[Ship Date], 'Date'[Date] ) )\n```\n\nIn Power BI Desktop, choose New measure on the Home ribbon and type the expression in the formula bar. In the TMDL file, add the `measure` block to the fact table. Name the columns in the order the relationship declares them, its from column first. DAX takes them either way round, but only that order counts as activation here.\n\nWhere nothing needs the relationship, delete it instead: open the model view, right-click the dotted line, and choose Delete, or remove its `relationship` block from the TMDL file.\n\n### When to ignore it\n\nThis rule reads the semantic model, not the reports built on it. A report-level measure in a live-connected report can call USERELATIONSHIP, and the rule cannot see it, so check the reports before deleting a relationship that looks unused. The same goes for a relationship activated from a calculated column, a calculated table, or a row-level security filter: none of those is scanned here, and a finding on one of them is noise. A relationship added this week for measures that are still being written is a fair thing to leave alone for a sprint.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"INACTIVE_RELATIONSHIPS_THAT_ARE_NEVER_ACTIVATED\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Only `USERELATIONSHIP(from column, to column)` counts as activation; the reversed argument order does not, even though DAX accepts it.\n- Only measures, calculation items, and user-defined functions are scanned. A USERELATIONSHIP call in a calculated column, a calculated table, or a row-level security filter does not count as activation.\n- A USERELATIONSHIP inside a user-defined function counts as activating the relationship, which Tabular Editor does not count, since the source rule reads measures and calculation items only. It counts even when nothing calls the function. When the function receives the two columns as parameters, as in `USERELATIONSHIP ( fromColumn, toColumn )`, the call names neither column, so the relationship is still reported.\n- The call is matched as text, in any letter case, so a USERELATIONSHIP written inside a string literal or a comment counts as activating the relationship.\n- Either table name may be written bare or in single quotes, and any spacing around the comma is accepted.\n- pbiplint escapes table and column names before building the pattern, which the source rule does not, so names with parentheses cannot break the check.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the DAX that activates the relationship with USERELATIONSHIP could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/inactive-relationships-that-are-never-activated"
   },
   INTEGER_FORMATTING: {
     text: `Example
@@ -8611,9 +9560,10 @@ Quirks
 - Both ends of a sort-by pair are out of scope: the column another column sorts by, and the column that names one in sortByColumn.
 - Variations are matched on the default column alone, so a column a variation reaches only through its default hierarchy is not protected here.
 - Relationships are not read. A hidden foreign key, which is exactly what HIDE_FOREIGN_KEYS asks you to create, is reported here.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because a variation on another table's column that names the column could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/isavailableinmdx-false-nonattribute-columns`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: OrderID\n\n	column 'Product Key'\n		dataType: int64\n		isHidden\n		summarizeBy: none\n		sourceColumn: ProductKey\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: OrderID\n\n	column 'Product Key'\n		dataType: int64\n		isHidden\n		isAvailableInMdx: false\n		summarizeBy: none\n		sourceColumn: ProductKey\n```\n\n### Why it matters\n\nWhen IsAvailableInMdx is true the engine builds an attribute hierarchy for the column at every refresh: a sorted structure that lets Excel and other MDX clients browse the column's values. A hidden column is never browsed, so the structure is built, stored, and rebuilt for nothing. On wide tables with many hidden keys and helper columns that is measurable refresh time and memory.\n\n### How to fix it\n\nAdd `isAvailableInMdx: false` under the column in its table's TMDL file. Power BI Desktop has no setting for the property and never writes it, but it keeps the value once it is in the file, and it keeps it the same way on an import table and a DirectQuery one. The other way to clear a finding is to decide the column should not be hidden after all: clear Is hidden in the Properties pane, or remove `isHidden` from under the column, and the rule stops reading it, as long as its table is visible too. Where a table has dozens of hidden keys, Tabular Editor's property grid sets the property on every selected column in one edit, which is quicker than the same change repeated down a file.\n\n### When to ignore it\n\nSize is the first judgment. The saving is roughly proportional to the column's distinct count, so a hidden flag with two values is not worth an edit and a hidden key with a million is. Work down the list by cardinality and stop where the numbers get small. A variation is the one case where acting on the finding can break something: pbiplint reads a variation's default column only, so a hidden column a variation reaches through its default hierarchy is reported here, and setting the property to false on it takes away the attribute hierarchy the variation needs. Check the date table's hidden columns against its variations before you touch them. A column you are about to unhide is a fair thing to leave, since unhiding it clears the finding anyway, as long as its table is visible.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A column with no `isAvailableInMdx` line counts as true, because that is the default pbiplint applies wherever the property is absent. Power BI Desktop never writes the property, so a Desktop-authored model gets a finding for every hidden column the rest of the condition does not excuse, until they are set by hand.\n- Visibility is the column's own `isHidden` or its table's. A visible column in a hidden table is reported.\n- Both ends of a sort-by pair are out of scope: the column another column sorts by, and the column that names one in `sortByColumn`.\n- Variations are matched on the default column alone, so a column a variation reaches only through its default hierarchy is not protected here.\n- Relationships are not read. A hidden foreign key, which is exactly what `HIDE_FOREIGN_KEYS` asks you to create, is reported here.\n\nRead more: https://pbiplint.com/rules/isavailableinmdx-false-nonattribute-columns"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: OrderID\n\n	column 'Product Key'\n		dataType: int64\n		isHidden\n		summarizeBy: none\n		sourceColumn: ProductKey\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: OrderID\n\n	column 'Product Key'\n		dataType: int64\n		isHidden\n		isAvailableInMdx: false\n		summarizeBy: none\n		sourceColumn: ProductKey\n```\n\n### Why it matters\n\nWhen IsAvailableInMdx is true the engine builds an attribute hierarchy for the column at every refresh: a sorted structure that lets Excel and other MDX clients browse the column's values. A hidden column is never browsed, so the structure is built, stored, and rebuilt for nothing. On wide tables with many hidden keys and helper columns that is measurable refresh time and memory.\n\n### How to fix it\n\nAdd `isAvailableInMdx: false` under the column in its table's TMDL file. Power BI Desktop has no setting for the property and never writes it, but it keeps the value once it is in the file, and it keeps it the same way on an import table and a DirectQuery one. The other way to clear a finding is to decide the column should not be hidden after all: clear Is hidden in the Properties pane, or remove `isHidden` from under the column, and the rule stops reading it, as long as its table is visible too. Where a table has dozens of hidden keys, Tabular Editor's property grid sets the property on every selected column in one edit, which is quicker than the same change repeated down a file.\n\n### When to ignore it\n\nSize is the first judgment. The saving is roughly proportional to the column's distinct count, so a hidden flag with two values is not worth an edit and a hidden key with a million is. Work down the list by cardinality and stop where the numbers get small. A variation is the one case where acting on the finding can break something: pbiplint reads a variation's default column only, so a hidden column a variation reaches through its default hierarchy is reported here, and setting the property to false on it takes away the attribute hierarchy the variation needs. Check the date table's hidden columns against its variations before you touch them. A column you are about to unhide is a fair thing to leave, since unhiding it clears the finding anyway, as long as its table is visible.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"ISAVAILABLEINMDX_FALSE_NONATTRIBUTE_COLUMNS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A column with no `isAvailableInMdx` line counts as true, because that is the default pbiplint applies wherever the property is absent. Power BI Desktop never writes the property, so a Desktop-authored model gets a finding for every hidden column the rest of the condition does not excuse, until they are set by hand.\n- Visibility is the column's own `isHidden` or its table's. A visible column in a hidden table is reported.\n- Both ends of a sort-by pair are out of scope: the column another column sorts by, and the column that names one in `sortByColumn`.\n- Variations are matched on the default column alone, so a column a variation reaches only through its default hierarchy is not protected here.\n- Relationships are not read. A hidden foreign key, which is exactly what `HIDE_FOREIGN_KEYS` asks you to create, is reported here.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because a variation on another table's column that names the column could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/isavailableinmdx-false-nonattribute-columns"
   },
   LANDING_PAGE_NOT_SET: {
     text: `Example
@@ -8921,9 +9871,10 @@ Quirks
 - A relationship that names no cardinality counts as many-to-one, which is Power BI's default, so an ordinary relationship block with only fromColumn and toColumn puts its to column in scope.
 - Inactive relationships count. A column that is only ever the one side of a relationship no measure activates is still reported.
 - The column is reported once however many relationships point at it.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could mark the table as a date table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/mark-primary-keys`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Product Key'\n		dataType: int64\n		isHidden\n		summarizeBy: none\n		sourceColumn: Product Key\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Product ID\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product Key'\n	toColumn: Product.'Product ID'\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Product Key'\n		dataType: int64\n		isHidden\n		summarizeBy: none\n		sourceColumn: Product Key\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		summarizeBy: none\n		sourceColumn: Product ID\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product Key'\n	toColumn: Product.'Product ID'\n```\n\n### Why it matters\n\nThe key flag declares that the column is unique, which lets the engine and client tools treat it as the identifier of the row rather than one more attribute to aggregate, and on an import model the engine enforces the uniqueness at refresh, so a duplicate key fails loudly instead of quietly doubling a total. It also documents intent: the next person reading the model can see at a glance which column defines the grain of the dimension, without tracing every relationship to work it out. Tables marked as date tables are skipped, because marking a table as a date table already sets the key on its date column.\n\n### How to fix it\n\nAdd `isKey` under the column in the TMDL file. Power BI Desktop has no box for the property on an ordinary table, and it keeps the value once it is in the file; the one place Desktop sets a key itself is Mark as date table, which sets it on the date column of the table you mark and takes that table out of this rule at the same time. Check that the column really is unique before you set it, because the engine takes the property at its word. Tabular Editor exposes the property in its property grid, which is a quicker way to set it across the dimensions of a large model than editing each file.\n\n### When to ignore it\n\nA dimension you cannot yet guarantee is unique is the case to leave alone. If the table is loaded from a feed that occasionally repeats a row, the key property turns a silent double-count into a loud failure, which is the right trade once the source is under control and the wrong one while you are still chasing it. Check the distinct count against the row count before you set the property, not after. A calendar table is the other case: mark it as a date table instead, which sets the key on its date column and takes the table out of the rule.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = MARK_PRIMARY_KEYS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"MARK_PRIMARY_KEYS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A table is skipped only when its data category is exactly `Time`, and the comparison is case-sensitive, so a file that says `dataCategory: time` does not count as a date table here.\n- A relationship that names no cardinality counts as many-to-one, which is Power BI's default, so an ordinary relationship block with only `fromColumn` and `toColumn` puts its to column in scope.\n- Inactive relationships count. A column that is only ever the one side of a relationship no measure activates is still reported.\n- The column is reported once however many relationships point at it.\n\nRead more: https://pbiplint.com/rules/mark-primary-keys"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Product Key'\n		dataType: int64\n		isHidden\n		summarizeBy: none\n		sourceColumn: Product Key\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Product ID\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product Key'\n	toColumn: Product.'Product ID'\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Product Key'\n		dataType: int64\n		isHidden\n		summarizeBy: none\n		sourceColumn: Product Key\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		summarizeBy: none\n		sourceColumn: Product ID\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product Key'\n	toColumn: Product.'Product ID'\n```\n\n### Why it matters\n\nThe key flag declares that the column is unique, which lets the engine and client tools treat it as the identifier of the row rather than one more attribute to aggregate, and on an import model the engine enforces the uniqueness at refresh, so a duplicate key fails loudly instead of quietly doubling a total. It also documents intent: the next person reading the model can see at a glance which column defines the grain of the dimension, without tracing every relationship to work it out. Tables marked as date tables are skipped, because marking a table as a date table already sets the key on its date column.\n\n### How to fix it\n\nAdd `isKey` under the column in the TMDL file. Power BI Desktop has no box for the property on an ordinary table, and it keeps the value once it is in the file; the one place Desktop sets a key itself is Mark as date table, which sets it on the date column of the table you mark and takes that table out of this rule at the same time. Check that the column really is unique before you set it, because the engine takes the property at its word. Tabular Editor exposes the property in its property grid, which is a quicker way to set it across the dimensions of a large model than editing each file.\n\n### When to ignore it\n\nA dimension you cannot yet guarantee is unique is the case to leave alone. If the table is loaded from a feed that occasionally repeats a row, the key property turns a silent double-count into a loud failure, which is the right trade once the source is under control and the wrong one while you are still chasing it. Check the distinct count against the row count before you set the property, not after. A calendar table is the other case: mark it as a date table instead, which sets the key on its date column and takes the table out of the rule.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = MARK_PRIMARY_KEYS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"MARK_PRIMARY_KEYS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A table is skipped only when its data category is exactly `Time`, and the comparison is case-sensitive, so a file that says `dataCategory: time` does not count as a date table here.\n- A relationship that names no cardinality counts as many-to-one, which is Power BI's default, so an ordinary relationship block with only `fromColumn` and `toColumn` puts its to column in scope.\n- Inactive relationships count. A column that is only ever the one side of a relationship no measure activates is still reported.\n- The column is reported once however many relationships point at it.\n- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could mark the table as a date table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file's own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/mark-primary-keys"
   },
   MEASURES_SHOULD_NOT_BE_DIRECT_REFERENCES_OF_OTHER_MEASURES: {
     text: `Example
@@ -9060,9 +10011,10 @@ Quirks
 - The names are matched anywhere in the expression, with no word boundary in front, so a measure or function whose name ends in one of them, such as MYDATEADD(, counts as a match. Whitespace between the name and the parenthesis is allowed.
 - The list is the source's thirty-seven functions, and it includes FIRSTNONBLANK, LASTNONBLANK, FIRSTNONBLANKVALUE, and LASTNONBLANKVALUE, which are regularly used over columns that hold no dates, so a measure with no date in it anywhere can be reported.
 - A table counts as DirectQuery when its first partition says mode: directQuery, letter case aside. No other mode counts, so a table set to Dual storage mode is not a DirectQuery table here, and a calculated table or a calculation group never is.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because a table is DirectQuery by its first partition and the partition that comes first could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/measures-using-time-intelligence-and-model-is-using-direct-query`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n	measure 'Sales Last Year' = CALCULATE(SUM('Sales'[Amount]), SAMEPERIODLASTYEAR('Date'[Date]))\n		formatString: #,0\n\n	partition Sales = m\n		mode: directQuery\n		source = let Source = Sql.Database(\"finance\", \"Warehouse\"), Sales = Source{[Item = \"Sales\"]}[Data] in Sales\n\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n	column 'Amount Prior Year'\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: AmountPriorYear\n\n	measure 'Sales Last Year' = SUM('Sales'[Amount Prior Year])\n		formatString: #,0\n\n	partition Sales = m\n		mode: directQuery\n		source = let Source = Sql.Database(\"finance\", \"Warehouse\"), Sales = Source{[Item = \"vwSalesWithPriorYear\"]}[Data] in Sales\n\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n```\n\n### Why it matters\n\nTime intelligence functions build sets of dates and evaluate the measure over each set. In Import mode that is in-memory work. In DirectQuery each set becomes a query, or a long list of dates inside one, sent to the source on every visual refresh, and sources are rarely fast at it. The functions work, but a page of year-to-date and prior-year cards can take many seconds to render.\n\n### How to fix it\n\nEither take the model out of DirectQuery or take the time intelligence out of the measure. For the first, select the table in Power BI Desktop's model view and set Storage mode to Import in the Properties pane, which is the partition's `mode: import` line in the TMDL file; the finding clears only once no table in the model is left in DirectQuery, because the condition is about the model and not about the tables the measure happens to read. For the second, move the comparison into the data: add the prior period's value to each row in the source view or the warehouse, load it as an ordinary column, and write the measure as a SUM over it, which is what the example above does. Where neither is possible, keep the number of time intelligence measures on one page small and cache what you can in the source, because every one of them is another round trip.\n\n### When to ignore it\n\nThe common false alarm is a measure that has nothing to do with the DirectQuery table. The rule reads the model, not the query path, so one small DirectQuery table kept for real-time status will report every time intelligence measure in the model, including the ones that run entirely over imported tables. Check which tables the measure actually touches before you act on it. A source that answers quickly is the second case: a well-indexed warehouse over a few million rows returns a year-to-date query in well under a second, and a page that renders fast is not a problem whatever the rule says. Time the visual before rewriting anything. What is not a legitimate exception is a large DirectQuery fact table over a source you do not control, where the finding is naming the reason the report is slow.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Function names are matched case-sensitively, in upper case only, as in the source rule, so `totalytd(` is not reported.\n- The names are matched anywhere in the expression, with no word boundary in front, so a measure or function whose name ends in one of them, such as `MYDATEADD(`, counts as a match. Whitespace between the name and the parenthesis is allowed.\n- The list is the source's thirty-seven functions, and it includes FIRSTNONBLANK, LASTNONBLANK, FIRSTNONBLANKVALUE, and LASTNONBLANKVALUE, which are regularly used over columns that hold no dates, so a measure with no date in it anywhere can be reported.\n- A table counts as DirectQuery when its first partition says `mode: directQuery`, letter case aside. No other mode counts, so a table set to Dual storage mode is not a DirectQuery table here, and a calculated table or a calculation group never is.\n\nRead more: https://pbiplint.com/rules/measures-using-time-intelligence-and-model-is-using-direct-query"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n	measure 'Sales Last Year' = CALCULATE(SUM('Sales'[Amount]), SAMEPERIODLASTYEAR('Date'[Date]))\n		formatString: #,0\n\n	partition Sales = m\n		mode: directQuery\n		source = let Source = Sql.Database(\"finance\", \"Warehouse\"), Sales = Source{[Item = \"Sales\"]}[Data] in Sales\n\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n	column 'Amount Prior Year'\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: AmountPriorYear\n\n	measure 'Sales Last Year' = SUM('Sales'[Amount Prior Year])\n		formatString: #,0\n\n	partition Sales = m\n		mode: directQuery\n		source = let Source = Sql.Database(\"finance\", \"Warehouse\"), Sales = Source{[Item = \"vwSalesWithPriorYear\"]}[Data] in Sales\n\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n```\n\n### Why it matters\n\nTime intelligence functions build sets of dates and evaluate the measure over each set. In Import mode that is in-memory work. In DirectQuery each set becomes a query, or a long list of dates inside one, sent to the source on every visual refresh, and sources are rarely fast at it. The functions work, but a page of year-to-date and prior-year cards can take many seconds to render.\n\n### How to fix it\n\nEither take the model out of DirectQuery or take the time intelligence out of the measure. For the first, select the table in Power BI Desktop's model view and set Storage mode to Import in the Properties pane, which is the partition's `mode: import` line in the TMDL file; the finding clears only once no table in the model is left in DirectQuery, because the condition is about the model and not about the tables the measure happens to read. For the second, move the comparison into the data: add the prior period's value to each row in the source view or the warehouse, load it as an ordinary column, and write the measure as a SUM over it, which is what the example above does. Where neither is possible, keep the number of time intelligence measures on one page small and cache what you can in the source, because every one of them is another round trip.\n\n### When to ignore it\n\nThe common false alarm is a measure that has nothing to do with the DirectQuery table. The rule reads the model, not the query path, so one small DirectQuery table kept for real-time status will report every time intelligence measure in the model, including the ones that run entirely over imported tables. Check which tables the measure actually touches before you act on it. A source that answers quickly is the second case: a well-indexed warehouse over a few million rows returns a year-to-date query in well under a second, and a page that renders fast is not a problem whatever the rule says. Time the visual before rewriting anything. What is not a legitimate exception is a large DirectQuery fact table over a source you do not control, where the finding is naming the reason the report is slow.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"MEASURES_USING_TIME_INTELLIGENCE_AND_MODEL_IS_USING_DIRECT_QUERY\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Function names are matched case-sensitively, in upper case only, as in the source rule, so `totalytd(` is not reported.\n- The names are matched anywhere in the expression, with no word boundary in front, so a measure or function whose name ends in one of them, such as `MYDATEADD(`, counts as a match. Whitespace between the name and the parenthesis is allowed.\n- The list is the source's thirty-seven functions, and it includes FIRSTNONBLANK, LASTNONBLANK, FIRSTNONBLANKVALUE, and LASTNONBLANKVALUE, which are regularly used over columns that hold no dates, so a measure with no date in it anywhere can be reported.\n- A table counts as DirectQuery when its first partition says `mode: directQuery`, letter case aside. No other mode counts, so a table set to Dual storage mode is not a DirectQuery table here, and a calculated table or a calculation group never is.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because a table is DirectQuery by its first partition and the partition that comes first could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/measures-using-time-intelligence-and-model-is-using-direct-query"
   },
   MINIMIZE_POWER_QUERY_TRANSFORMATIONS: {
     text: `Example
@@ -9188,9 +10140,10 @@ Quirks
 - The data category comparison is exact and case-sensitive, so dataCategory: time leaves the model reported.
 - Nothing else about the table is tested. It is not checked for contiguity, for covering the model's date range, or for being related to anything, so a one-row table marked as a date table clears the finding without helping any measure.
 - Any table can satisfy it, of any kind. A calculated calendar counts the same as a loaded one.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the date table could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/model-should-have-a-date-table`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n### Why it matters\n\nEvery time intelligence function needs a contiguous date column to work over, and the marked date table is where it finds one. Without it, the model either leans on Auto date/time, which adds a hidden date table per date column and cannot be extended with fiscal periods or holidays, or does no time intelligence at all. A single shared date table also gives every fact table the same month, quarter, and year attributes, so visuals from different tables line up.\n\n### How to fix it\n\nAdd a calendar with one row per day covering every date the model holds, then mark it. The first-choice route is the source: load a calendar view or table in Transform data, so the fiscal periods and holidays live where the rest of the business already agrees on them. Failing that, build one in Power Query from a list of dates, or in Power BI Desktop under Modeling, New table with DAX such as `Date = CALENDAR(DATE(2020, 1, 1), DATE(2030, 12, 31))`; New table needs a table in import storage mode, so a model whose tables are all DirectQuery has to take the calendar from the source. Then select the table, open Table tools, choose Mark as date table, and pick the date column, which writes `dataCategory: Time` on the table and `isKey` on that column in the file. Finish by relating each fact table's date column to it in the model view and turning off Auto date/time under File, Options and settings, Options, Data Load, so the hidden per-column calendars stop being built.\n\n### When to ignore it\n\nA model with no dates in it is the clean exception: a reference list, a product catalogue published for other models to join to, a survey result set. There is no time intelligence to do and no calendar would have anything to cover. A model that answers only current-state questions, such as a stock-on-hand report with no period comparison anywhere, is the same judgment made deliberately rather than by omission. Everything else that shows a trend, a year-to-date figure, or a comparison with last year needs the table, and the reason the rule is at warning is that the alternative, Auto date/time, works well enough in a demo to hide the problem until someone asks for a fiscal year.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = MODEL_SHOULD_HAVE_A_DATE_TABLE` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"MODEL_SHOULD_HAVE_A_DATE_TABLE\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Both properties are needed on one table: `dataCategory: Time` and `isKey` on one of its DateTime columns. A table with only one of them does not satisfy the rule.\n- The data category comparison is exact and case-sensitive, so `dataCategory: time` leaves the model reported.\n- Nothing else about the table is tested. It is not checked for contiguity, for covering the model's date range, or for being related to anything, so a one-row table marked as a date table clears the finding without helping any measure.\n- Any table can satisfy it, of any kind. A calculated calendar counts the same as a loaded one.\n\nRead more: https://pbiplint.com/rules/model-should-have-a-date-table"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n### Why it matters\n\nEvery time intelligence function needs a contiguous date column to work over, and the marked date table is where it finds one. Without it, the model either leans on Auto date/time, which adds a hidden date table per date column and cannot be extended with fiscal periods or holidays, or does no time intelligence at all. A single shared date table also gives every fact table the same month, quarter, and year attributes, so visuals from different tables line up.\n\n### How to fix it\n\nAdd a calendar with one row per day covering every date the model holds, then mark it. The first-choice route is the source: load a calendar view or table in Transform data, so the fiscal periods and holidays live where the rest of the business already agrees on them. Failing that, build one in Power Query from a list of dates, or in Power BI Desktop under Modeling, New table with DAX such as `Date = CALENDAR(DATE(2020, 1, 1), DATE(2030, 12, 31))`; New table needs a table in import storage mode, so a model whose tables are all DirectQuery has to take the calendar from the source. Then select the table, open Table tools, choose Mark as date table, and pick the date column, which writes `dataCategory: Time` on the table and `isKey` on that column in the file. Finish by relating each fact table's date column to it in the model view and turning off Auto date/time under File, Options and settings, Options, Data Load, so the hidden per-column calendars stop being built.\n\n### When to ignore it\n\nA model with no dates in it is the clean exception: a reference list, a product catalogue published for other models to join to, a survey result set. There is no time intelligence to do and no calendar would have anything to cover. A model that answers only current-state questions, such as a stock-on-hand report with no period comparison anywhere, is the same judgment made deliberately rather than by omission. Everything else that shows a trend, a year-to-date figure, or a comparison with last year needs the table, and the reason the rule is at warning is that the alternative, Auto date/time, works well enough in a demo to hide the problem until someone asks for a fiscal year.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = MODEL_SHOULD_HAVE_A_DATE_TABLE` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"MODEL_SHOULD_HAVE_A_DATE_TABLE\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Both properties are needed on one table: `dataCategory: Time` and `isKey` on one of its DateTime columns. A table with only one of them does not satisfy the rule.\n- The data category comparison is exact and case-sensitive, so `dataCategory: time` leaves the model reported.\n- Nothing else about the table is tested. It is not checked for contiguity, for covering the model's date range, or for being related to anything, so a one-row table marked as a date table clears the finding without helping any measure.\n- Any table can satisfy it, of any kind. A calculated calendar counts the same as a loaded one.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the date table could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/model-should-have-a-date-table"
   },
   MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS: {
     text: `Example
@@ -9280,9 +10233,10 @@ Quirks
 - The data source version has to be present and read as powerBI_V3, compared without regard to letter case. A model file that does not carry defaultPowerBIDataSourceVersion at all is never reported, whatever its tables say.
 - One column with an alternateOf block anywhere in the model clears the finding, whatever it maps to. A single half-finished aggregation table counts as much as a complete set.
 - A table counts as DirectQuery when its first partition says mode: directQuery, letter case aside. No other mode counts, so a table set to Dual storage mode is not a DirectQuery table here.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because an aggregation table could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/model-using-direct-query-and-no-aggregations`,
-    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\nmodel Model\n	culture: en-US\n	defaultPowerBIDataSourceVersion: powerBI_V3\n\ntable Sales\n	column \'Order Date\'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: directQuery\n		source = let Source = Sql.Database("finance", "Warehouse"), Sales = Source{[Item = "Sales"]}[Data] in Sales\n```\n\n**After the fix**\n\n```tmdl\nmodel Model\n	culture: en-US\n	defaultPowerBIDataSourceVersion: powerBI_V3\n\ntable Sales\n	column \'Order Date\'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: directQuery\n		source = let Source = Sql.Database("finance", "Warehouse"), Sales = Source{[Item = "Sales"]}[Data] in Sales\n\ntable \'Sales by Day\'\n	isHidden\n\n	column \'Order Date\'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n		alternateOf\n			baseColumn: Sales.\'Order Date\'\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n		alternateOf\n			summarization: sum\n			baseColumn: Sales.Amount\n\n	partition \'Sales by Day\' = m\n		mode: import\n		source = let Source = Sql.Database("finance", "Warehouse"), Agg = Source{[Item = "vwSalesByDay"]}[Data] in Agg\n```\n\n### Why it matters\n\nIn DirectQuery every visual sends a query to the source. Aggregation tables let the engine answer the common high-level questions, totals by month or by region, from a small imported table and send only the detail queries through. Without them, the summary page of a dashboard pays the full round trip to the source on every interaction. This is an info-level prompt to consider the feature, not a defect.\n\n### How to fix it\n\nBuild a summary table at the grain the reports use most, one row per day and region rather than one per transaction, and load it from a view in the source so the two tables stay consistent. Import it, keep the detail table in DirectQuery, and in Power BI Desktop right-click the summary table in the model view, choose Manage aggregations, and map each of its columns to the detail column it summarizes and the function that summarizes it. In the TMDL file that mapping is an `alternateOf` block under each aggregation column, which is the only thing the rule looks for. The block names the detail column in `baseColumn`, qualified by its table as in `Sales.\'Order Date\'`, or, for Count table rows, names the detail table alone in `baseTable`. It sets a `summarization`, such as `sum` or `count`, for every function except group by, which it leaves out. The summary table should be hidden, because report authors write their measures against the detail table and the engine redirects the query when it can. The Manage aggregations dialog hides it for you when you select Apply all, if it is not hidden already; in the TMDL file that is `isHidden` on the table, as in the example. Any one aggregation mapping anywhere in the model clears this finding, so treat the rule as a prompt to start rather than a measure of how far you got.\n\n### When to ignore it\n\nThe question is whether there is a summary worth precomputing. A DirectQuery table kept for a handful of live status tiles has none: the whole point is that the numbers are current to the second, and a cached summary would be wrong. A report that only ever reads detail rows, such as a lookup of one order by number, has none either, because there is no total for an aggregation to answer. A source that already serves a summarized view at the grain the report asks for is the third case, and there the aggregation exists, it is just on the other side of the connector. Where the report opens on a page of totals by month over a large DirectQuery fact table, the finding is worth acting on, and at info severity it will not fail a build while you decide.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The data source version has to be present and read as powerBI_V3, compared without regard to letter case. A model file that does not carry `defaultPowerBIDataSourceVersion` at all is never reported, whatever its tables say.\n- One column with an `alternateOf` block anywhere in the model clears the finding, whatever it maps to. A single half-finished aggregation table counts as much as a complete set.\n- A table counts as DirectQuery when its first partition says `mode: directQuery`, letter case aside. No other mode counts, so a table set to Dual storage mode is not a DirectQuery table here.\n\nRead more: https://pbiplint.com/rules/model-using-direct-query-and-no-aggregations'
+    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\nmodel Model\n	culture: en-US\n	defaultPowerBIDataSourceVersion: powerBI_V3\n\ntable Sales\n	column \'Order Date\'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: directQuery\n		source = let Source = Sql.Database("finance", "Warehouse"), Sales = Source{[Item = "Sales"]}[Data] in Sales\n```\n\n**After the fix**\n\n```tmdl\nmodel Model\n	culture: en-US\n	defaultPowerBIDataSourceVersion: powerBI_V3\n\ntable Sales\n	column \'Order Date\'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: directQuery\n		source = let Source = Sql.Database("finance", "Warehouse"), Sales = Source{[Item = "Sales"]}[Data] in Sales\n\ntable \'Sales by Day\'\n	isHidden\n\n	column \'Order Date\'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n		alternateOf\n			baseColumn: Sales.\'Order Date\'\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\n		alternateOf\n			summarization: sum\n			baseColumn: Sales.Amount\n\n	partition \'Sales by Day\' = m\n		mode: import\n		source = let Source = Sql.Database("finance", "Warehouse"), Agg = Source{[Item = "vwSalesByDay"]}[Data] in Agg\n```\n\n### Why it matters\n\nIn DirectQuery every visual sends a query to the source. Aggregation tables let the engine answer the common high-level questions, totals by month or by region, from a small imported table and send only the detail queries through. Without them, the summary page of a dashboard pays the full round trip to the source on every interaction. This is an info-level prompt to consider the feature, not a defect.\n\n### How to fix it\n\nBuild a summary table at the grain the reports use most, one row per day and region rather than one per transaction, and load it from a view in the source so the two tables stay consistent. Import it, keep the detail table in DirectQuery, and in Power BI Desktop right-click the summary table in the model view, choose Manage aggregations, and map each of its columns to the detail column it summarizes and the function that summarizes it. In the TMDL file that mapping is an `alternateOf` block under each aggregation column, which is the only thing the rule looks for. The block names the detail column in `baseColumn`, qualified by its table as in `Sales.\'Order Date\'`, or, for Count table rows, names the detail table alone in `baseTable`. It sets a `summarization`, such as `sum` or `count`, for every function except group by, which it leaves out. The summary table should be hidden, because report authors write their measures against the detail table and the engine redirects the query when it can. The Manage aggregations dialog hides it for you when you select Apply all, if it is not hidden already; in the TMDL file that is `isHidden` on the table, as in the example. Any one aggregation mapping anywhere in the model clears this finding, so treat the rule as a prompt to start rather than a measure of how far you got.\n\n### When to ignore it\n\nThe question is whether there is a summary worth precomputing. A DirectQuery table kept for a handful of live status tiles has none: the whole point is that the numbers are current to the second, and a cached summary would be wrong. A report that only ever reads detail rows, such as a lookup of one order by number, has none either, because there is no total for an aggregation to answer. A source that already serves a summarized view at the grain the report asks for is the third case, and there the aggregation exists, it is just on the other side of the connector. Where the report opens on a page of totals by month over a large DirectQuery fact table, the finding is worth acting on, and at info severity it will not fail a build while you decide.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"MODEL_USING_DIRECT_QUERY_AND_NO_AGGREGATIONS": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The data source version has to be present and read as powerBI_V3, compared without regard to letter case. A model file that does not carry `defaultPowerBIDataSourceVersion` at all is never reported, whatever its tables say.\n- One column with an `alternateOf` block anywhere in the model clears the finding, whatever it maps to. A single half-finished aggregation table counts as much as a complete set.\n- A table counts as DirectQuery when its first partition says `mode: directQuery`, letter case aside. No other mode counts, so a table set to Dual storage mode is not a DirectQuery table here.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because an aggregation table could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file\'s own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/model-using-direct-query-and-no-aggregations'
   },
   "MONTH_(AS_A_STRING)_MUST_BE_SORTED": {
     text: `Example
@@ -9467,7 +10421,7 @@ How to fix it
 
 Check first that nothing outside this report needs the field: another report built on the same model, a paginated report, or an Excel workbook that reads the model. Removing a column that something else uses breaks that thing, and pbiplint sees only the report in front of it.
 
-Then remove the field from the model. In Power BI Desktop, right-click the measure or calculated column in the Data pane, or select it in Model view, and choose Delete from model. For a column that Power Query loads, open Power Query Editor, select the column in the table's query, and choose Remove Columns, so it is no longer loaded at all. If a hierarchy level uses the column, first select the hierarchy in Model view and, in the Properties pane, set its levels without that column, then select Apply Level Changes. In the TMDL files, delete the measure or column block from the table's file, and, for a column Power Query loads, remove it from the table's query as well. When the finding names a level of a user hierarchy, also delete that level block, which sits under its hierarchy block in the same file and names the column on its column: line, or point that column: at another column of the same table. A dead chain is listed from the top, the measure first and then the fields only it used, so one pass down the list removes all of it.
+Then remove the field from the model. In Power BI Desktop, right-click the measure or calculated column in the Data pane, or select it in Model view, and choose Delete from model. For a column that Power Query loads, open Power Query Editor, select the column in the table's query, and choose Remove Columns, so it is no longer loaded at all. If a hierarchy level uses the column, first select the hierarchy in Model view and, in the Properties pane, set its levels without that column, then select Apply Level Changes. In the TMDL files, delete the measure or column block from the table's file, and, for a column Power Query loads, remove it from the table's query as well. When the finding names a level of a user hierarchy, also delete that level block, which sits under its hierarchy block in the same file and names the column on its column: line, or point that column: at another column of the same table. A dead chain is listed with its measures before its columns, so one pass down the list removes all of it. When a detail names a user-defined function, as in referenced only by Sales.NetAfterReserve, which nothing reaches either, nothing reaches that function either, and it has no finding of its own: delete its function block from definition/functions.tmdl too, or edit it so it no longer names the fields you delete, since a function that names a field the model no longer has breaks.
 
 When to ignore it
 
@@ -9478,17 +10432,18 @@ To ignore this rule on one object, add annotation pbiplint.ignore = NOT_REACHED_
 Quirks
 
 - The rule reads one report at a time. A model that several reports share lists, for each report, what that report does not reach, even when another report uses it.
-- Both columns of a relationship, the columns that row-level and object-level security name, the default column of a variation, and the columns of an aggregation table that carry an alternateOf mapping are reached whether or not the report uses them, because the model needs them. A column that a reached column sorts by or groups by is reached too, and so is the detail column or table that an aggregation column's mapping names. Report queries name the detail table, and Power BI answers them from the aggregation table when that table covers the query, so a report can use the mapped columns without naming them. A column of an aggregation table with no mapping is treated like any other column.
-- Calculated tables whose names start with LocalDateTable_ or DateTableTemplate_, which pbiplint reads as Power BI Desktop's auto date/time tables the way REMOVE_AUTO-DATE_TABLE does, are left out of the findings, reached or not. Desktop manages these tables and keeps them hidden even from modelers, so there is nothing here to delete; turning Auto date/time off removes them, and REMOVE_AUTO-DATE_TABLE reports them. The relationship Desktop adds from a date column to its auto date/time table does not count as a use of the date column, so a date column the report never shows is still reported.
-- UNNECESSARY_MEASURES and UNNECESSARY_COLUMNS keep the one-hop test of the ruleset they are ported from, so their results match Tabular Editor: they look only at hidden fields and at the model's own references. This rule reads the report and follows the chain as far as it goes, so it reports visible fields too, and a measure that only another unused measure references.
+- Both columns of a relationship, the columns and measures that row-level security filters name, the columns that object-level security names, the default column of a variation, and the columns of an aggregation table that carry an alternateOf mapping are reached whether or not the report uses them, because the model needs them: a role whose filter names a deleted measure fails, and UNNECESSARY_MEASURES already counts such a measure as used. A column that a reached column sorts by or groups by is reached too, and so is the detail column or table that an aggregation column's mapping names. Report queries name the detail table, and Power BI answers them from the aggregation table when that table covers the query, so a report can use the mapped columns without naming them. A column of an aggregation table with no mapping is treated like any other column.
+- Calculated tables whose names start with LocalDateTable_ or DateTableTemplate_, which pbiplint reads as Power BI Desktop's auto date/time tables the way REMOVE_AUTO-DATE_TABLE does, are left out of the findings, reached or not. So is a composite model's copy of one: a LocalDateTable_ table whose entity partition reads, in DirectQuery mode, the table of that name in the Power BI semantic model or Analysis Services model it extends, and which Desktop saves with showAsVariationsOnly, so it is shown only through a date column's hierarchy. Desktop manages these tables and keeps them out of view, so there is nothing here to delete. Turning Auto date/time off removes the calculated ones, and REMOVE_AUTO-DATE_TABLE reports them; the table a copy reads is calculated in the model it extends, and that model's own run reports it. The relationship Desktop adds from a date column to its auto date/time table, or to a copy, does not count as a use of the date column, so a date column the report never shows is still reported.
+- UNNECESSARY_MEASURES and UNNECESSARY_COLUMNS keep the one-hop test of the ruleset they are ported from, as Tabular Editor runs it: they look only at hidden fields and at the model's own references. This rule reads the report and follows the chain as far as it goes, so it reports visible fields too, and a measure that only another unused measure references.
 - DAX references are found by pattern, the way the model rules find them, so a field named inside a string or a comment of a reached measure counts as reached.
 - A table that nothing reaches has no finding of its own. Each of its columns and measures is reported instead.
+- A user-defined function that nothing reaches has no finding of its own either. Each column and measure that only it uses is reported, with the function named in the detail. A call is found by pattern too: the function's name, in any letter case, followed by an opening parenthesis, with no letter, digit, underscore, or dot just before the name.
 - The rule compares the report with its model, so it runs only when both are in the input.
 - The rule also needs every file it reads the report's fields from: report.json (the report's filters), reportExtensions.json (the report's own measures), each page.json (a page's filters and its drillthrough or tooltip fields), each visual.json, and each bookmark file. While one of them cannot be read, such as a visual.json holding merge-conflict markers, a reportExtensions.json that is not valid JSON, or a file pbiplint could not open at all, the rule reports nothing, because that file may use any field in the model and pbiplint does not guess what a file it could not read says. A folder under the definition folder that pbiplint could not open counts as every file it could hold. The skipped line gives the reason, a report file could not be read, the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open, and the Model line of Report at a glance says the count is unknown. pbiplint reads no field from version.json, pages.json, bookmarks.json, or a visual's mobile.json, which hold the report's format version, the order of its pages, the order and groups of its bookmarks, and a visual's mobile layout, so one of them that cannot be read, a merge conflict in pages.json included, does not stop the rule. Nor does a .platform or definition.pbir that cannot be read, or a JSON file of your own in the definition folder.
 - The rule also needs the whole model. While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces or a misspelt table, or pbiplint could not open a model file or folder at all, the rule reports nothing, because whatever only the missing declaration reaches, such as a measure that only its DAX uses, would read as reached by nothing. The skipped line gives the reason, a model file could not be fully read, the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open, and the Model line of Report at a glance says the count is unknown. A /// description with a blank line after it takes no declaration out, so it does not stop the rule. When a report file could not be read as well, the skipped line gives that reason instead.
 
 Read more: https://pbiplint.com/rules/not-reached-from-report`,
-    markdown: '### Example\n\nThe example runs against a model with one table, Sales, holding Amount and Region and the measure Total Sales.\n\n**Fires the rule in visual.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/visualContainer/2.8.0/schema.json",\n  "name": "c897ed0802274ab55e2d",\n  "position": { "x": 580, "y": 520, "z": 3000, "height": 190, "width": 650, "tabOrder": 3000 },\n  "visual": {\n    "visualType": "tableEx",\n    "query": {\n      "queryState": {\n        "Values": {\n          "projections": [\n            {\n              "field": { "Column": { "Expression": { "SourceRef": { "Entity": "Sales" } }, "Property": "Region" } },\n              "queryRef": "Sales.Region",\n              "nativeQueryRef": "Region"\n            }\n          ]\n        }\n      }\n    }\n  }\n}\n```\n\n**After the fix in visual.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/visualContainer/2.8.0/schema.json",\n  "name": "c897ed0802274ab55e2d",\n  "position": { "x": 580, "y": 520, "z": 3000, "height": 190, "width": 650, "tabOrder": 3000 },\n  "visual": {\n    "visualType": "tableEx",\n    "query": {\n      "queryState": {\n        "Values": {\n          "projections": [\n            {\n              "field": { "Column": { "Expression": { "SourceRef": { "Entity": "Sales" } }, "Property": "Region" } },\n              "queryRef": "Sales.Region",\n              "nativeQueryRef": "Region"\n            },\n            {\n              "field": { "Measure": { "Expression": { "SourceRef": { "Entity": "Sales" } }, "Property": "Total Sales" } },\n              "queryRef": "Sales.Total Sales",\n              "nativeQueryRef": "Total Sales"\n            }\n          ]\n        }\n      }\n    }\n  }\n}\n```\n\nWith only Region in the table, two findings come back: `[Total Sales]`, which nothing uses, and `\'Sales\'[Amount]`, which only Total Sales uses. Here the measure was meant to be in the table, so the fix adds it, and that reaches Amount through the measure\'s DAX. When a field really is unused, the fix is to delete it from the model, as How to fix it describes.\n\n### Why it matters\n\nA column earns its place in a model in one of two ways, Microsoft\'s modeling guidance says: a report filters, groups, or summarizes by it, or the model\'s structure needs it, for a relationship, a calculation, a security role, or formatting. A column that does neither can usually be removed, and an imported one is still loaded on every refresh and held in memory, where a smaller model refreshes faster and competes less for capacity. A measure nothing reaches adds no data to the model, but it sits in the Data pane beside the measures that matter, and the next author has to read it, keep it working through model changes, and guess whether something depends on it. The findings list what this report never touches, so that clean-up can start from evidence instead of a guess.\n\n### How to fix it\n\nCheck first that nothing outside this report needs the field: another report built on the same model, a paginated report, or an Excel workbook that reads the model. Removing a column that something else uses breaks that thing, and pbiplint sees only the report in front of it.\n\nThen remove the field from the model. In Power BI Desktop, right-click the measure or calculated column in the Data pane, or select it in Model view, and choose Delete from model. For a column that Power Query loads, open Power Query Editor, select the column in the table\'s query, and choose Remove Columns, so it is no longer loaded at all. If a hierarchy level uses the column, first select the hierarchy in Model view and, in the Properties pane, set its levels without that column, then select Apply Level Changes. In the TMDL files, delete the `measure` or `column` block from the table\'s file, and, for a column Power Query loads, remove it from the table\'s query as well. When the finding names a level of a user hierarchy, also delete that `level` block, which sits under its `hierarchy` block in the same file and names the column on its `column:` line, or point that `column:` at another column of the same table. A dead chain is listed from the top, the measure first and then the fields only it used, so one pass down the list removes all of it.\n\n### When to ignore it\n\nA measure kept for another report on the same model, or for people who analyze the model in Excel, is not dead because this report does not use it, and neither is a column that a paginated report or a workbook reads. When several reports share the model, a finding here says only that this report does not reach the field; weigh it against the others before deleting anything, and ignore it on the fields they need.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = NOT_REACHED_FROM_REPORT` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"NOT_REACHED_FROM_REPORT": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The rule reads one report at a time. A model that several reports share lists, for each report, what that report does not reach, even when another report uses it.\n- Both columns of a relationship, the columns that row-level and object-level security name, the default column of a variation, and the columns of an aggregation table that carry an `alternateOf` mapping are reached whether or not the report uses them, because the model needs them. A column that a reached column sorts by or groups by is reached too, and so is the detail column or table that an aggregation column\'s mapping names. Report queries name the detail table, and Power BI answers them from the aggregation table when that table covers the query, so a report can use the mapped columns without naming them. A column of an aggregation table with no mapping is treated like any other column.\n- Calculated tables whose names start with `LocalDateTable_` or `DateTableTemplate_`, which pbiplint reads as Power BI Desktop\'s auto date/time tables the way `REMOVE_AUTO-DATE_TABLE` does, are left out of the findings, reached or not. Desktop manages these tables and keeps them hidden even from modelers, so there is nothing here to delete; turning Auto date/time off removes them, and `REMOVE_AUTO-DATE_TABLE` reports them. The relationship Desktop adds from a date column to its auto date/time table does not count as a use of the date column, so a date column the report never shows is still reported.\n- `UNNECESSARY_MEASURES` and `UNNECESSARY_COLUMNS` keep the one-hop test of the ruleset they are ported from, so their results match Tabular Editor: they look only at hidden fields and at the model\'s own references. This rule reads the report and follows the chain as far as it goes, so it reports visible fields too, and a measure that only another unused measure references.\n- DAX references are found by pattern, the way the model rules find them, so a field named inside a string or a comment of a reached measure counts as reached.\n- A table that nothing reaches has no finding of its own. Each of its columns and measures is reported instead.\n- The rule compares the report with its model, so it runs only when both are in the input.\n- The rule also needs every file it reads the report\'s fields from: report.json (the report\'s filters), reportExtensions.json (the report\'s own measures), each page.json (a page\'s filters and its drillthrough or tooltip fields), each visual.json, and each bookmark file. While one of them cannot be read, such as a visual.json holding merge-conflict markers, a reportExtensions.json that is not valid JSON, or a file pbiplint could not open at all, the rule reports nothing, because that file may use any field in the model and pbiplint does not guess what a file it could not read says. A folder under the definition folder that pbiplint could not open counts as every file it could hold. The skipped line gives the reason, `a report file could not be read`, the file\'s own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open, and the Model line of Report at a glance says the count is unknown. pbiplint reads no field from version.json, pages.json, bookmarks.json, or a visual\'s mobile.json, which hold the report\'s format version, the order of its pages, the order and groups of its bookmarks, and a visual\'s mobile layout, so one of them that cannot be read, a merge conflict in pages.json included, does not stop the rule. Nor does a .platform or definition.pbir that cannot be read, or a JSON file of your own in the definition folder.\n- The rule also needs the whole model. While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces or a misspelt `table`, or pbiplint could not open a model file or folder at all, the rule reports nothing, because whatever only the missing declaration reaches, such as a measure that only its DAX uses, would read as reached by nothing. The skipped line gives the reason, `a model file could not be fully read`, the file\'s own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open, and the Model line of Report at a glance says the count is unknown. A `///` description with a blank line after it takes no declaration out, so it does not stop the rule. When a report file could not be read as well, the skipped line gives that reason instead.\n\nRead more: https://pbiplint.com/rules/not-reached-from-report'
+    markdown: '### Example\n\nThe example runs against a model with one table, Sales, holding Amount and Region and the measure Total Sales.\n\n**Fires the rule in visual.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/visualContainer/2.8.0/schema.json",\n  "name": "c897ed0802274ab55e2d",\n  "position": { "x": 580, "y": 520, "z": 3000, "height": 190, "width": 650, "tabOrder": 3000 },\n  "visual": {\n    "visualType": "tableEx",\n    "query": {\n      "queryState": {\n        "Values": {\n          "projections": [\n            {\n              "field": { "Column": { "Expression": { "SourceRef": { "Entity": "Sales" } }, "Property": "Region" } },\n              "queryRef": "Sales.Region",\n              "nativeQueryRef": "Region"\n            }\n          ]\n        }\n      }\n    }\n  }\n}\n```\n\n**After the fix in visual.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/visualContainer/2.8.0/schema.json",\n  "name": "c897ed0802274ab55e2d",\n  "position": { "x": 580, "y": 520, "z": 3000, "height": 190, "width": 650, "tabOrder": 3000 },\n  "visual": {\n    "visualType": "tableEx",\n    "query": {\n      "queryState": {\n        "Values": {\n          "projections": [\n            {\n              "field": { "Column": { "Expression": { "SourceRef": { "Entity": "Sales" } }, "Property": "Region" } },\n              "queryRef": "Sales.Region",\n              "nativeQueryRef": "Region"\n            },\n            {\n              "field": { "Measure": { "Expression": { "SourceRef": { "Entity": "Sales" } }, "Property": "Total Sales" } },\n              "queryRef": "Sales.Total Sales",\n              "nativeQueryRef": "Total Sales"\n            }\n          ]\n        }\n      }\n    }\n  }\n}\n```\n\nWith only Region in the table, two findings come back: `[Total Sales]`, which nothing uses, and `\'Sales\'[Amount]`, which only Total Sales uses. Here the measure was meant to be in the table, so the fix adds it, and that reaches Amount through the measure\'s DAX. When a field really is unused, the fix is to delete it from the model, as How to fix it describes.\n\n### Why it matters\n\nA column earns its place in a model in one of two ways, Microsoft\'s modeling guidance says: a report filters, groups, or summarizes by it, or the model\'s structure needs it, for a relationship, a calculation, a security role, or formatting. A column that does neither can usually be removed, and an imported one is still loaded on every refresh and held in memory, where a smaller model refreshes faster and competes less for capacity. A measure nothing reaches adds no data to the model, but it sits in the Data pane beside the measures that matter, and the next author has to read it, keep it working through model changes, and guess whether something depends on it. The findings list what this report never touches, so that clean-up can start from evidence instead of a guess.\n\n### How to fix it\n\nCheck first that nothing outside this report needs the field: another report built on the same model, a paginated report, or an Excel workbook that reads the model. Removing a column that something else uses breaks that thing, and pbiplint sees only the report in front of it.\n\nThen remove the field from the model. In Power BI Desktop, right-click the measure or calculated column in the Data pane, or select it in Model view, and choose Delete from model. For a column that Power Query loads, open Power Query Editor, select the column in the table\'s query, and choose Remove Columns, so it is no longer loaded at all. If a hierarchy level uses the column, first select the hierarchy in Model view and, in the Properties pane, set its levels without that column, then select Apply Level Changes. In the TMDL files, delete the `measure` or `column` block from the table\'s file, and, for a column Power Query loads, remove it from the table\'s query as well. When the finding names a level of a user hierarchy, also delete that `level` block, which sits under its `hierarchy` block in the same file and names the column on its `column:` line, or point that `column:` at another column of the same table. A dead chain is listed with its measures before its columns, so one pass down the list removes all of it. When a detail names a user-defined function, as in `referenced only by Sales.NetAfterReserve, which nothing reaches either`, nothing reaches that function either, and it has no finding of its own: delete its `function` block from `definition/functions.tmdl` too, or edit it so it no longer names the fields you delete, since a function that names a field the model no longer has breaks.\n\n### When to ignore it\n\nA measure kept for another report on the same model, or for people who analyze the model in Excel, is not dead because this report does not use it, and neither is a column that a paginated report or a workbook reads. When several reports share the model, a finding here says only that this report does not reach the field; weigh it against the others before deleting anything, and ignore it on the fields they need.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = NOT_REACHED_FROM_REPORT` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"NOT_REACHED_FROM_REPORT": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The rule reads one report at a time. A model that several reports share lists, for each report, what that report does not reach, even when another report uses it.\n- Both columns of a relationship, the columns and measures that row-level security filters name, the columns that object-level security names, the default column of a variation, and the columns of an aggregation table that carry an `alternateOf` mapping are reached whether or not the report uses them, because the model needs them: a role whose filter names a deleted measure fails, and `UNNECESSARY_MEASURES` already counts such a measure as used. A column that a reached column sorts by or groups by is reached too, and so is the detail column or table that an aggregation column\'s mapping names. Report queries name the detail table, and Power BI answers them from the aggregation table when that table covers the query, so a report can use the mapped columns without naming them. A column of an aggregation table with no mapping is treated like any other column.\n- Calculated tables whose names start with `LocalDateTable_` or `DateTableTemplate_`, which pbiplint reads as Power BI Desktop\'s auto date/time tables the way `REMOVE_AUTO-DATE_TABLE` does, are left out of the findings, reached or not. So is a composite model\'s copy of one: a `LocalDateTable_` table whose `entity` partition reads, in DirectQuery mode, the table of that name in the Power BI semantic model or Analysis Services model it extends, and which Desktop saves with `showAsVariationsOnly`, so it is shown only through a date column\'s hierarchy. Desktop manages these tables and keeps them out of view, so there is nothing here to delete. Turning Auto date/time off removes the calculated ones, and `REMOVE_AUTO-DATE_TABLE` reports them; the table a copy reads is calculated in the model it extends, and that model\'s own run reports it. The relationship Desktop adds from a date column to its auto date/time table, or to a copy, does not count as a use of the date column, so a date column the report never shows is still reported.\n- `UNNECESSARY_MEASURES` and `UNNECESSARY_COLUMNS` keep the one-hop test of the ruleset they are ported from, as Tabular Editor runs it: they look only at hidden fields and at the model\'s own references. This rule reads the report and follows the chain as far as it goes, so it reports visible fields too, and a measure that only another unused measure references.\n- DAX references are found by pattern, the way the model rules find them, so a field named inside a string or a comment of a reached measure counts as reached.\n- A table that nothing reaches has no finding of its own. Each of its columns and measures is reported instead.\n- A user-defined function that nothing reaches has no finding of its own either. Each column and measure that only it uses is reported, with the function named in the detail. A call is found by pattern too: the function\'s name, in any letter case, followed by an opening parenthesis, with no letter, digit, underscore, or dot just before the name.\n- The rule compares the report with its model, so it runs only when both are in the input.\n- The rule also needs every file it reads the report\'s fields from: report.json (the report\'s filters), reportExtensions.json (the report\'s own measures), each page.json (a page\'s filters and its drillthrough or tooltip fields), each visual.json, and each bookmark file. While one of them cannot be read, such as a visual.json holding merge-conflict markers, a reportExtensions.json that is not valid JSON, or a file pbiplint could not open at all, the rule reports nothing, because that file may use any field in the model and pbiplint does not guess what a file it could not read says. A folder under the definition folder that pbiplint could not open counts as every file it could hold. The skipped line gives the reason, `a report file could not be read`, the file\'s own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open, and the Model line of Report at a glance says the count is unknown. pbiplint reads no field from version.json, pages.json, bookmarks.json, or a visual\'s mobile.json, which hold the report\'s format version, the order of its pages, the order and groups of its bookmarks, and a visual\'s mobile layout, so one of them that cannot be read, a merge conflict in pages.json included, does not stop the rule. Nor does a .platform or definition.pbir that cannot be read, or a JSON file of your own in the definition folder.\n- The rule also needs the whole model. While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces or a misspelt `table`, or pbiplint could not open a model file or folder at all, the rule reports nothing, because whatever only the missing declaration reaches, such as a measure that only its DAX uses, would read as reached by nothing. The skipped line gives the reason, `a model file could not be fully read`, the file\'s own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open, and the Model line of Report at a glance says the count is unknown. A `///` description with a blank line after it takes no declaration out, so it does not stop the rule. When a report file could not be read as well, the skipped line gives that reason instead.\n\nRead more: https://pbiplint.com/rules/not-reached-from-report'
   },
   NUMERIC_COLUMN_SUMMARIZE_BY: {
     text: `Example
@@ -9528,9 +10483,10 @@ Quirks
 - The property value is compared without regard to letter case, so summarizeBy: None passes as well as summarizeBy: none.
 - Hidden columns, and columns in hidden tables, are skipped.
 - Only whole number, decimal, and double columns are in scope, so a DateTime or text column with a summarization set is never reported here.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could hide the table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/numeric-column-summarize-by`,
-    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Date\n	column Year\n		dataType: int64\n		sourceColumn: Year\n```\n\n**After the fix**\n\n```tmdl\ntable Date\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n### Why it matters\n\nWith a default summarization, dragging the column onto a visual produces an implicit sum, and it is easy to sum something that should never be summed: a year, a unit price, a percentage, a key. The implicit measure also bypasses the format string and the logic of the real measures, so two visuals of the same thing disagree. With summarization off, the column lands on a visual as a category and the author reaches for a measure.\n\n### How to fix it\n\nIn Power BI Desktop, select the column in the Data pane and set Summarization to Don\'t summarize under Column tools. In the TMDL file the property is `summarizeBy: none` under the column. Where the column really is a number reports need totals of, add an explicit measure for it, because the point of the change is that the aggregation becomes something the model defines rather than something a visual guesses.\n\n### When to ignore it\n\nAn additive column with no measure behind it is the case to weigh. On a small planning or budget table that a handful of people build their own matrices from, the implicit sum is the feature, and taking it away without writing the measures first makes the model harder to use, not safer. Check which reports drag the column in before you change it. A year, a key, a price, or a rate is never that case: summing any of them produces a number with no meaning, and those are the findings to act on first.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = NUMERIC_COLUMN_SUMMARIZE_BY` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"NUMERIC_COLUMN_SUMMARIZE_BY": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A column with no `summarizeBy` property is treated as Default, which is not None, so it is reported. That is where most findings come from.\n- The property value is compared without regard to letter case, so `summarizeBy: None` passes as well as `summarizeBy: none`.\n- Hidden columns, and columns in hidden tables, are skipped.\n- Only whole number, decimal, and double columns are in scope, so a DateTime or text column with a summarization set is never reported here.\n\nRead more: https://pbiplint.com/rules/numeric-column-summarize-by'
+    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Date\n	column Year\n		dataType: int64\n		sourceColumn: Year\n```\n\n**After the fix**\n\n```tmdl\ntable Date\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n### Why it matters\n\nWith a default summarization, dragging the column onto a visual produces an implicit sum, and it is easy to sum something that should never be summed: a year, a unit price, a percentage, a key. The implicit measure also bypasses the format string and the logic of the real measures, so two visuals of the same thing disagree. With summarization off, the column lands on a visual as a category and the author reaches for a measure.\n\n### How to fix it\n\nIn Power BI Desktop, select the column in the Data pane and set Summarization to Don\'t summarize under Column tools. In the TMDL file the property is `summarizeBy: none` under the column. Where the column really is a number reports need totals of, add an explicit measure for it, because the point of the change is that the aggregation becomes something the model defines rather than something a visual guesses.\n\n### When to ignore it\n\nAn additive column with no measure behind it is the case to weigh. On a small planning or budget table that a handful of people build their own matrices from, the implicit sum is the feature, and taking it away without writing the measures first makes the model harder to use, not safer. Check which reports drag the column in before you change it. A year, a key, a price, or a rate is never that case: summing any of them produces a number with no meaning, and those are the findings to act on first.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = NUMERIC_COLUMN_SUMMARIZE_BY` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"NUMERIC_COLUMN_SUMMARIZE_BY": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A column with no `summarizeBy` property is treated as Default, which is not None, so it is reported. That is where most findings come from.\n- The property value is compared without regard to letter case, so `summarizeBy: None` passes as well as `summarizeBy: none`.\n- Hidden columns, and columns in hidden tables, are skipped.\n- Only whole number, decimal, and double columns are in scope, so a DateTime or text column with a summarization set is never reported here.\n- The rule also needs every part of a table\'s declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could hide the table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file\'s own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/numeric-column-summarize-by'
   },
   OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE: {
     text: `Example
@@ -9581,9 +10537,10 @@ Quirks
 - The test is for the space character at the start or the end of the name. A name padded with a tab is not reported here; SPECIAL_CHARS_IN_OBJECT_NAMES covers that one.
 - The model object is in scope, and a finding on the model is always named Model whatever the model is called, so a stray space in the model's own name gives a finding with nothing in the line to show it. The model's name is on the model line in the TMDL file.
 - In the browser, the "Choose a folder" button in Chrome and Edge does not list a file whose name begins or ends with a space, so a table file named that way is never read on that route and its findings are missing. Drag the folder onto the page, or use the command line, to read it.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could hold a calculated partition, which puts the table and its columns out of the rule's scope, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/objects-should-not-start-or-end-with-a-space`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order ID '\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		summarizeBy: none\n		sourceColumn: Amount\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		summarizeBy: none\n		sourceColumn: Amount\n```\n\n### Why it matters\n\nA leading or trailing space is invisible on screen but is part of the name, so \"Sales \" and \"Sales\" are two different objects to the engine. That is enough to break a DAX reference, a report visual binding, or a deployment that expects the trimmed name, and the error you get back will name an object that looks perfectly correct. Stray spaces almost always arrive by accident, pasted in or inherited from a source column name, so trimming them is safe and rarely breaks anything downstream. `TRIM_OBJECT_NAMES` makes the same check across more object types at a lower severity, so every finding here appears there as well.\n\n### How to fix it\n\nIn Power BI Desktop, double-click the field in the Data pane and retype the name without the space, or select the object and clear the space from Name in the Properties pane. In the TMDL file the name is on the declaration line, so `column 'Order ID '` becomes `column 'Order ID'`. A data column carries its own `sourceColumn`, so trimming the model name does not change what the refresh loads. Renaming in Desktop updates the visuals bound to the field; a hand edit in the file does not, so open the report and check its visuals after one. Where the space arrives with a source column name, trim it in Power Query too, so the next column you add from that query comes in clean.\n\n### When to ignore it\n\nNo name should start or end with a space, and this rule reports at error severity because a name that reads as correct and is not costs more to diagnose than to fix. A leading space is sometimes used to push a measure to the top of the field list; a display folder puts the measure where it belongs without hiding a character in its name.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Narrower scope than `TRIM_OBJECT_NAMES`: levels, roles, named expressions, calculation items, calculation group tables, data sources, calculated tables, and calculated table columns are not checked here.\n- The test is for the space character at the start or the end of the name. A name padded with a tab is not reported here; `SPECIAL_CHARS_IN_OBJECT_NAMES` covers that one.\n- The model object is in scope, and a finding on the model is always named `Model` whatever the model is called, so a stray space in the model's own name gives a finding with nothing in the line to show it. The model's name is on the `model` line in the TMDL file.\n- In the browser, the \"Choose a folder\" button in Chrome and Edge does not list a file whose name begins or ends with a space, so a table file named that way is never read on that route and its findings are missing. Drag the folder onto the page, or use the command line, to read it.\n\nRead more: https://pbiplint.com/rules/objects-should-not-start-or-end-with-a-space"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order ID '\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		summarizeBy: none\n		sourceColumn: Amount\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		summarizeBy: none\n		sourceColumn: Amount\n```\n\n### Why it matters\n\nA leading or trailing space is invisible on screen but is part of the name, so \"Sales \" and \"Sales\" are two different objects to the engine. That is enough to break a DAX reference, a report visual binding, or a deployment that expects the trimmed name, and the error you get back will name an object that looks perfectly correct. Stray spaces almost always arrive by accident, pasted in or inherited from a source column name, so trimming them is safe and rarely breaks anything downstream. `TRIM_OBJECT_NAMES` makes the same check across more object types at a lower severity, so every finding here appears there as well.\n\n### How to fix it\n\nIn Power BI Desktop, double-click the field in the Data pane and retype the name without the space, or select the object and clear the space from Name in the Properties pane. In the TMDL file the name is on the declaration line, so `column 'Order ID '` becomes `column 'Order ID'`. A data column carries its own `sourceColumn`, so trimming the model name does not change what the refresh loads. Renaming in Desktop updates the visuals bound to the field; a hand edit in the file does not, so open the report and check its visuals after one. Where the space arrives with a source column name, trim it in Power Query too, so the next column you add from that query comes in clean.\n\n### When to ignore it\n\nNo name should start or end with a space, and this rule reports at error severity because a name that reads as correct and is not costs more to diagnose than to fix. A leading space is sometimes used to push a measure to the top of the field list; a display folder puts the measure where it belongs without hiding a character in its name.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"OBJECTS_SHOULD_NOT_START_OR_END_WITH_A_SPACE\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Narrower scope than `TRIM_OBJECT_NAMES`: levels, roles, named expressions, calculation items, calculation group tables, data sources, calculated tables, and calculated table columns are not checked here.\n- The test is for the space character at the start or the end of the name. A name padded with a tab is not reported here; `SPECIAL_CHARS_IN_OBJECT_NAMES` covers that one.\n- The model object is in scope, and a finding on the model is always named `Model` whatever the model is called, so a stray space in the model's own name gives a finding with nothing in the line to show it. The model's name is on the `model` line in the TMDL file.\n- In the browser, the \"Choose a folder\" button in Chrome and Edge does not list a file whose name begins or ends with a space, so a table file named that way is never read on that route and its findings are missing. Drag the folder onto the page, or use the command line, to read it.\n- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could hold a calculated partition, which puts the table and its columns out of the rule's scope, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file's own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/objects-should-not-start-or-end-with-a-space"
   },
   OBJECTS_WITH_NO_DESCRIPTION: {
     text: `Example
@@ -9632,9 +10589,10 @@ Quirks
 - A calculation group table is reported once, as a calculation group.
 - A description of only spaces or tabs counts as none, so padding a description to quiet the rule does not work.
 - Hierarchies, hierarchy levels, calculation items, partitions, roles, perspectives, data sources, and named expressions are outside the scope, so an undescribed hierarchy is never reported here.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could describe or hide the table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/objects-with-no-description`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n**After the fix**\n\n```tmdl\n/// One row per order line, loaded nightly from the sales warehouse.\ntable Sales\n\n	/// Line amount in US dollars, net of discount and before tax.\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	/// Sum of line amount over whatever the visual is filtered to.\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nThe description is the tooltip a report author sees when hovering a field in the field list, and it is the only place in the model to say what a measure counts, which currency a column is in, or which of two similar fields to use. Without it, every author works that out from the name, and gets it wrong at about the same rate. Descriptions also feed documentation tools, so the same sentence pays off twice.\n\n### How to fix it\n\nIn Power BI Desktop, open Model view, select the object, and type the Description in the Properties pane. In the TMDL file a description is one or more `///` lines directly above the object's declaration, with no blank line between the last `///` line and the declaration: a blank line ends the description, and the object below it is read as having none. With hundreds of objects, Tabular Editor can paste descriptions into many at once from a list.\n\n### When to ignore it\n\nA name that already says the whole thing needs nothing added: `'Date'[Year]` gains nothing from a sentence reading \"the year\". Spend the descriptions on measures, on any column whose unit, currency, grain, or filter behavior is not in its name, and on the two fields a reader has to choose between. A table or column you are about to hide is better hidden than described, because hiding it also clears this finding.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = OBJECTS_WITH_NO_DESCRIPTION` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"OBJECTS_WITH_NO_DESCRIPTION\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Visibility is the object's own isHidden flag: a visible column inside a hidden table is still reported.\n- A calculation group table is reported once, as a calculation group.\n- A description of only spaces or tabs counts as none, so padding a description to quiet the rule does not work.\n- Hierarchies, hierarchy levels, calculation items, partitions, roles, perspectives, data sources, and named expressions are outside the scope, so an undescribed hierarchy is never reported here.\n\nRead more: https://pbiplint.com/rules/objects-with-no-description"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n**After the fix**\n\n```tmdl\n/// One row per order line, loaded nightly from the sales warehouse.\ntable Sales\n\n	/// Line amount in US dollars, net of discount and before tax.\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	/// Sum of line amount over whatever the visual is filtered to.\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nThe description is the tooltip a report author sees when hovering a field in the field list, and it is the only place in the model to say what a measure counts, which currency a column is in, or which of two similar fields to use. Without it, every author works that out from the name, and gets it wrong at about the same rate. Descriptions also feed documentation tools, so the same sentence pays off twice.\n\n### How to fix it\n\nIn Power BI Desktop, open Model view, select the object, and type the Description in the Properties pane. In the TMDL file a description is one or more `///` lines directly above the object's declaration, with no blank line between the last `///` line and the declaration: a blank line ends the description, and the object below it is read as having none. With hundreds of objects, Tabular Editor can paste descriptions into many at once from a list.\n\n### When to ignore it\n\nA name that already says the whole thing needs nothing added: `'Date'[Year]` gains nothing from a sentence reading \"the year\". Spend the descriptions on measures, on any column whose unit, currency, grain, or filter behavior is not in its name, and on the two fields a reader has to choose between. A table or column you are about to hide is better hidden than described, because hiding it also clears this finding.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = OBJECTS_WITH_NO_DESCRIPTION` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"OBJECTS_WITH_NO_DESCRIPTION\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Visibility is the object's own isHidden flag: a visible column inside a hidden table is still reported.\n- A calculation group table is reported once, as a calculation group.\n- A description of only spaces or tabs counts as none, so padding a description to quiet the rule does not work.\n- Hierarchies, hierarchy levels, calculation items, partitions, roles, perspectives, data sources, and named expressions are outside the scope, so an undescribed hierarchy is never reported here.\n- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could describe or hide the table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file's own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/objects-with-no-description"
   },
   OPENING_PAGE_INVALID: {
     text: `Example
@@ -9773,13 +10731,13 @@ The second pair is a page.json saved in the middle of a merge, with both branche
 
 Why it matters
 
-pbiplint could not read the line, so whatever it declared, a column, a property, a measure, is missing from the model the rules see. Findings on that object and on anything that references it may be missing or wrong, and a result that looks clean may not be. A line at the root that TMDL does not allow there takes everything under it out of the model: a misspelt table takes the table's columns, measures, and partitions with it, and a column's property or annotation that lost its tabs takes the columns, measures, and partitions after it. The orphaned description is the mild case: no declaration is lost, only the description, which stops at the blank line instead of reaching the object below it, so that object is read as having none. Tabular Editor's TMDL reader is stricter and refuses to open a file that puts a blank line after a /// line at all.
+pbiplint could not read the line, so whatever it declared, a column, a property, a measure, is missing from the model the rules see. Findings on that object and on anything that references it may be missing or wrong, and a result that looks clean may not be. A line at the root, or directly under a model, that TMDL does not allow there takes everything under it out of the model: a misspelt table takes the table's columns, measures, and partitions with it, and a column's property or annotation that lost its tabs takes the columns, measures, and partitions after it. A code fence left open has no end pbiplint can be sure of: pbiplint ends the expression where the indented text under the declaration ends, which keeps what follows in most files, and otherwise runs it to the next line that opens a fence, or to the end of the file, taking the declarations between with it. The orphaned description is the mild case: no declaration is lost, only the description, which stops at the blank line instead of reaching the object below it, so that object is read as having none. Tabular Editor's TMDL reader is stricter and refuses to open a file that puts a blank line after a /// line at all.
 
-In a report, a JSON file that is not valid JSON, or that carries a conflict marker, is not read at all, and neither is a file Microsoft publishes a schema for, such as report.json, when its content is not a JSON object, so nothing in it reaches the rules. A visual whose visual.json fails is left out of every rule. A page whose page.json fails has no display name, size, visibility, or filters as far as the rules know, and nothing to say it is a tooltip or drillthrough page, so the rules that read those say nothing about it; its visuals sit in files of their own and are still checked, and an ignore annotation in the page.json no longer applies. A report.json that fails takes the report's theme, custom visuals, filters, and filter pane settings with it. None of those rules says what it could not read, so here too a result that looks clean may not be.
+In a report, a JSON file that is not valid JSON, that carries a conflict marker, or that nests too deep to read safely is not read at all, and neither is a file Microsoft publishes a schema for, such as report.json, when its content is not a JSON object, so nothing in it reaches the rules. A visual whose visual.json fails is left out of every rule. A page whose page.json fails has no display name, size, visibility, or filters as far as the rules know, and nothing to say it is a tooltip or drillthrough page, so the rules that read those say nothing about it; its visuals sit in files of their own and are still checked, and an ignore annotation in the page.json no longer applies. A report.json that fails takes the report's theme, custom visuals, filters, and filter pane settings with it. None of those rules says what it could not read, so here too a result that looks clean may not be.
 
 How to fix it
 
-Open the file at the reported line. TMDL is indented with tabs, and a fenced expression opens with three backticks (\`\`\`) after the = and closes with three backticks on a line of its own. Only a few types sit at the root of a TMDL file, such as table, relationship, and role: correct the word the finding names, or, when it names something that belongs inside another object, such as a column, indent it one tab deeper than that object's line. A property or child object sits one tab deeper than the object it belongs to, and a multi-line expression one tab deeper than that object's properties, so check the lines under it by the same rule. A /// description must sit directly above its declaration, with no blank line between them. Power BI Desktop writes valid TMDL, so a parse issue usually means a hand edit or a merge conflict marker. In a report JSON file, the finding names the file and the line where the JSON stops being valid, where a conflict marker sits, or where a document that is not a JSON object starts. Resolve the conflict or restore the JSON at that line. A file whose content is not an object needs its object restored, for example from version control: Microsoft's schema for each file it defines in a report's definition folder puts a JSON object at its root. Then reopen the report in Power BI Desktop to confirm that it loads.
+Open the file at the reported line. TMDL is indented with tabs, and a fenced expression opens with three backticks (\`\`\`) after the = and closes with three backticks on a line of its own; an unterminated code fence names the declaration whose fence never closes, so add that line where its expression ends. Only a few types sit at the root of a TMDL file, such as table, relationship, and role: correct the word the finding names, or, when it names something that belongs inside another object, such as a column, indent it one tab deeper than that object's line. The same types may sit one tab under the model line instead, and no declaration but the model under the database line: move any other declaration named there to the root of a file, or to the object it belongs to. A table line reported under another object has gained a tab: move it back to the start of the line, with the lines under it one tab shallower too. A declaration with no name needs its name back, and a name with a space, a dot, an equals sign, a colon, or a single quote in it is enclosed in single quotes, with each quote inside doubled, as in 'O''Brien'. A property or child object sits one tab deeper than the object it belongs to, and a multi-line expression one tab deeper than that object's properties, so check the lines under it by the same rule. A /// description must sit directly above its declaration, with no blank line between them. Power BI Desktop writes valid TMDL, so a parse issue usually means a hand edit or a merge conflict marker. In a report JSON file, the finding names the file and the line where the JSON stops being valid, where a conflict marker sits, where the document passes 256 levels of nesting, or where a document that is not a JSON object starts. Resolve the conflict or restore the JSON at that line. Power BI Desktop's own files nest a few dozen levels at most, so a file nested past 256 was generated or edited outside Desktop: restore it from version control, or rebuild what it holds in Desktop and save the report again. A file whose content is not an object needs its object restored, for example from version control: Microsoft's schema for each file it defines in a report's definition folder puts a JSON object at its root. Then reopen the report in Power BI Desktop to confirm that it loads.
 
 When to ignore it
 
@@ -9788,7 +10746,7 @@ Not on purpose. A parse issue means the model pbiplint checked is not the model
 This rule reports on files, so there is no object to annotate. To turn the rule off for a whole project, set "PARSE_ISSUE": "off" under rules in pbiplint.config.json.
 
 Read more: https://pbiplint.com/rules/parse-issue`,
-    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n    column Amount\n        dataType: decimal\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n```\n\nThe first snippet is indented with spaces, so both lines under the table are reported, and the model pbiplint checks has a Sales table with no columns.\n\n**Fires the rule in page.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/page/2.1.0/schema.json",\n  "name": "d3583278a4fc59eaa0d6",\n<<<<<<< HEAD\n  "displayName": "Sales overview",\n=======\n  "displayName": "Overview",\n>>>>>>> rename-pages\n  "displayOption": "FitToPage",\n  "height": 720,\n  "width": 1280\n}\n```\n\n**After the fix in page.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/page/2.1.0/schema.json",\n  "name": "d3583278a4fc59eaa0d6",\n  "displayName": "Sales overview",\n  "displayOption": "FitToPage",\n  "height": 720,\n  "width": 1280\n}\n```\n\nThe second pair is a page.json saved in the middle of a merge, with both branches\' names for the page still in it. Each of the three marker lines is reported, and nothing in the file is read until it is valid JSON again.\n\n### Why it matters\n\npbiplint could not read the line, so whatever it declared, a column, a property, a measure, is missing from the model the rules see. Findings on that object and on anything that references it may be missing or wrong, and a result that looks clean may not be. A line at the root that TMDL does not allow there takes everything under it out of the model: a misspelt `table` takes the table\'s columns, measures, and partitions with it, and a column\'s property or annotation that lost its tabs takes the columns, measures, and partitions after it. The orphaned description is the mild case: no declaration is lost, only the description, which stops at the blank line instead of reaching the object below it, so that object is read as having none. Tabular Editor\'s TMDL reader is stricter and refuses to open a file that puts a blank line after a `///` line at all.\n\nIn a report, a JSON file that is not valid JSON, or that carries a conflict marker, is not read at all, and neither is a file Microsoft publishes a schema for, such as report.json, when its content is not a JSON object, so nothing in it reaches the rules. A visual whose visual.json fails is left out of every rule. A page whose page.json fails has no display name, size, visibility, or filters as far as the rules know, and nothing to say it is a tooltip or drillthrough page, so the rules that read those say nothing about it; its visuals sit in files of their own and are still checked, and an ignore annotation in the page.json no longer applies. A report.json that fails takes the report\'s theme, custom visuals, filters, and filter pane settings with it. None of those rules says what it could not read, so here too a result that looks clean may not be.\n\n### How to fix it\n\nOpen the file at the reported line. TMDL is indented with tabs, and a fenced expression opens with three backticks (```) after the `=` and closes with three backticks on a line of its own. Only a few types sit at the root of a TMDL file, such as `table`, `relationship`, and `role`: correct the word the finding names, or, when it names something that belongs inside another object, such as a `column`, indent it one tab deeper than that object\'s line. A property or child object sits one tab deeper than the object it belongs to, and a multi-line expression one tab deeper than that object\'s properties, so check the lines under it by the same rule. A `///` description must sit directly above its declaration, with no blank line between them. Power BI Desktop writes valid TMDL, so a parse issue usually means a hand edit or a merge conflict marker. In a report JSON file, the finding names the file and the line where the JSON stops being valid, where a conflict marker sits, or where a document that is not a JSON object starts. Resolve the conflict or restore the JSON at that line. A file whose content is not an object needs its object restored, for example from version control: Microsoft\'s schema for each file it defines in a report\'s definition folder puts a JSON object at its root. Then reopen the report in Power BI Desktop to confirm that it loads.\n\n### When to ignore it\n\nNot on purpose. A parse issue means the model pbiplint checked is not the model in the file, or, in a report JSON file, that nothing the file defines was checked, so every other result on that file is in doubt until the line is fixed. The one exception is a line that Power BI Desktop wrote and opens without complaint and pbiplint still reports, in a TMDL file or a report JSON file: that is a gap in pbiplint\'s parser. Report it with the line. Until it is fixed, only the project-wide switch quiets it, and that also hides real parse issues, so weigh the two.\n\nThis rule reports on files, so there is no object to annotate. To turn the rule off for a whole project, set `"PARSE_ISSUE": "off"` under `rules` in `pbiplint.config.json`.\n\nRead more: https://pbiplint.com/rules/parse-issue'
+    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n    column Amount\n        dataType: decimal\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n```\n\nThe first snippet is indented with spaces, so both lines under the table are reported, and the model pbiplint checks has a Sales table with no columns.\n\n**Fires the rule in page.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/page/2.1.0/schema.json",\n  "name": "d3583278a4fc59eaa0d6",\n<<<<<<< HEAD\n  "displayName": "Sales overview",\n=======\n  "displayName": "Overview",\n>>>>>>> rename-pages\n  "displayOption": "FitToPage",\n  "height": 720,\n  "width": 1280\n}\n```\n\n**After the fix in page.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/page/2.1.0/schema.json",\n  "name": "d3583278a4fc59eaa0d6",\n  "displayName": "Sales overview",\n  "displayOption": "FitToPage",\n  "height": 720,\n  "width": 1280\n}\n```\n\nThe second pair is a page.json saved in the middle of a merge, with both branches\' names for the page still in it. Each of the three marker lines is reported, and nothing in the file is read until it is valid JSON again.\n\n### Why it matters\n\npbiplint could not read the line, so whatever it declared, a column, a property, a measure, is missing from the model the rules see. Findings on that object and on anything that references it may be missing or wrong, and a result that looks clean may not be. A line at the root, or directly under a model, that TMDL does not allow there takes everything under it out of the model: a misspelt `table` takes the table\'s columns, measures, and partitions with it, and a column\'s property or annotation that lost its tabs takes the columns, measures, and partitions after it. A code fence left open has no end pbiplint can be sure of: pbiplint ends the expression where the indented text under the declaration ends, which keeps what follows in most files, and otherwise runs it to the next line that opens a fence, or to the end of the file, taking the declarations between with it. The orphaned description is the mild case: no declaration is lost, only the description, which stops at the blank line instead of reaching the object below it, so that object is read as having none. Tabular Editor\'s TMDL reader is stricter and refuses to open a file that puts a blank line after a `///` line at all.\n\nIn a report, a JSON file that is not valid JSON, that carries a conflict marker, or that nests too deep to read safely is not read at all, and neither is a file Microsoft publishes a schema for, such as report.json, when its content is not a JSON object, so nothing in it reaches the rules. A visual whose visual.json fails is left out of every rule. A page whose page.json fails has no display name, size, visibility, or filters as far as the rules know, and nothing to say it is a tooltip or drillthrough page, so the rules that read those say nothing about it; its visuals sit in files of their own and are still checked, and an ignore annotation in the page.json no longer applies. A report.json that fails takes the report\'s theme, custom visuals, filters, and filter pane settings with it. None of those rules says what it could not read, so here too a result that looks clean may not be.\n\n### How to fix it\n\nOpen the file at the reported line. TMDL is indented with tabs, and a fenced expression opens with three backticks (```) after the `=` and closes with three backticks on a line of its own; an unterminated code fence names the declaration whose fence never closes, so add that line where its expression ends. Only a few types sit at the root of a TMDL file, such as `table`, `relationship`, and `role`: correct the word the finding names, or, when it names something that belongs inside another object, such as a `column`, indent it one tab deeper than that object\'s line. The same types may sit one tab under the `model` line instead, and no declaration but the model under the `database` line: move any other declaration named there to the root of a file, or to the object it belongs to. A `table` line reported under another object has gained a tab: move it back to the start of the line, with the lines under it one tab shallower too. A declaration with no name needs its name back, and a name with a space, a dot, an equals sign, a colon, or a single quote in it is enclosed in single quotes, with each quote inside doubled, as in `\'O\'\'Brien\'`. A property or child object sits one tab deeper than the object it belongs to, and a multi-line expression one tab deeper than that object\'s properties, so check the lines under it by the same rule. A `///` description must sit directly above its declaration, with no blank line between them. Power BI Desktop writes valid TMDL, so a parse issue usually means a hand edit or a merge conflict marker. In a report JSON file, the finding names the file and the line where the JSON stops being valid, where a conflict marker sits, where the document passes 256 levels of nesting, or where a document that is not a JSON object starts. Resolve the conflict or restore the JSON at that line. Power BI Desktop\'s own files nest a few dozen levels at most, so a file nested past 256 was generated or edited outside Desktop: restore it from version control, or rebuild what it holds in Desktop and save the report again. A file whose content is not an object needs its object restored, for example from version control: Microsoft\'s schema for each file it defines in a report\'s definition folder puts a JSON object at its root. Then reopen the report in Power BI Desktop to confirm that it loads.\n\n### When to ignore it\n\nNot on purpose. A parse issue means the model pbiplint checked is not the model in the file, or, in a report JSON file, that nothing the file defines was checked, so every other result on that file is in doubt until the line is fixed. The one exception is a line that Power BI Desktop wrote and opens without complaint and pbiplint still reports, in a TMDL file or a report JSON file: that is a gap in pbiplint\'s parser. Report it with the line. Until it is fixed, only the project-wide switch quiets it, and that also hides real parse issues, so weigh the two.\n\nThis rule reports on files, so there is no object to annotate. To turn the rule off for a whole project, set `"PARSE_ISSUE": "off"` under `rules` in `pbiplint.config.json`.\n\nRead more: https://pbiplint.com/rules/parse-issue'
   },
   PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES: {
     text: `Example
@@ -9836,9 +10794,10 @@ To ignore this rule on one object, add annotation pbiplint.ignore = PARTITION_NA
 Quirks
 
 - The condition tests tables with exactly one partition. A table with none, and a table with several, is never reported, whatever its partitions are called.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could hold another partition, or a calculated one, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/partition-name-should-match-table-name-for-single-partition-tables`,
-    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column \'Order ID\'\n		dataType: int64\n		sourceColumn: OrderID\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	partition SalesData = m\n		mode: import\n		source = Sql.Database("contoso", "Sales")\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column \'Order ID\'\n		dataType: int64\n		sourceColumn: OrderID\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	partition Sales = m\n		mode: import\n		source = Sql.Database("contoso", "Sales")\n```\n\n### Why it matters\n\nA single-partition table has no reason for its partition to carry a different name, and when it does it is usually the table\'s old name from before a rename. Refresh logs, error messages, and the TMDL file all name the partition, so a mismatch sends the reader looking for a table that no longer exists.\n\n### How to fix it\n\nThe partition\'s name sits on its declaration line, so `partition SalesData = m` under `table Sales` becomes `partition Sales = m`. Nothing else in the TMDL file refers to a partition by name, so on a single-partition table the rename changes nothing but the label in the refresh log. Power BI Desktop has no partition list and no field for a partition name: it names the partition when it creates the table and leaves the name alone afterwards, so a mismatch on a Desktop project points at a hand edit, a table renamed outside Desktop, or a model migrated from another tool. If a whole model needs correcting, Tabular Editor\'s partition editor renames partitions without opening each file.\n\n### When to ignore it\n\nA partition that the people who run the refresh already know by another name can keep it, for example one named after the stored procedure that fills it, because that is the name they will look for when the refresh fails. Outside that, a single partition named anything but its table is a leftover, and the rename costs nothing.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The condition tests tables with exactly one partition. A table with none, and a table with several, is never reported, whatever its partitions are called.\n\nRead more: https://pbiplint.com/rules/partition-name-should-match-table-name-for-single-partition-tables'
+    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column \'Order ID\'\n		dataType: int64\n		sourceColumn: OrderID\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	partition SalesData = m\n		mode: import\n		source = Sql.Database("contoso", "Sales")\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column \'Order ID\'\n		dataType: int64\n		sourceColumn: OrderID\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n	partition Sales = m\n		mode: import\n		source = Sql.Database("contoso", "Sales")\n```\n\n### Why it matters\n\nA single-partition table has no reason for its partition to carry a different name, and when it does it is usually the table\'s old name from before a rename. Refresh logs, error messages, and the TMDL file all name the partition, so a mismatch sends the reader looking for a table that no longer exists.\n\n### How to fix it\n\nThe partition\'s name sits on its declaration line, so `partition SalesData = m` under `table Sales` becomes `partition Sales = m`. Nothing else in the TMDL file refers to a partition by name, so on a single-partition table the rename changes nothing but the label in the refresh log. Power BI Desktop has no partition list and no field for a partition name: it names the partition when it creates the table and leaves the name alone afterwards, so a mismatch on a Desktop project points at a hand edit, a table renamed outside Desktop, or a model migrated from another tool. If a whole model needs correcting, Tabular Editor\'s partition editor renames partitions without opening each file.\n\n### When to ignore it\n\nA partition that the people who run the refresh already know by another name can keep it, for example one named after the stored procedure that fills it, because that is the name they will look for when the refresh fails. Outside that, a single partition named anything but its table is a leftover, and the rename costs nothing.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"PARTITION_NAME_SHOULD_MATCH_TABLE_NAME_FOR_SINGLE_PARTITION_TABLES": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The condition tests tables with exactly one partition. A table with none, and a table with several, is never reported, whatever its partitions are called.\n- The rule also needs every part of a table\'s declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could hold another partition, or a calculated one, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file\'s own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/partition-name-should-match-table-name-for-single-partition-tables'
   },
   PERCENTAGE_FORMATTING: {
     text: `Example
@@ -10001,9 +10960,10 @@ Quirks
 - A format string of nothing but spaces counts as no format string, so formatString: " " is reported.
 - A measure with only a dynamic format string passes here but fires INTEGER_FORMATTING, which reads the static format string alone.
 - Hidden measures, and measures on hidden tables, are skipped. INTEGER_FORMATTING skips neither.
+- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a table line, such as a misspelt table, the rule reports nothing, because a part of the table in what pbiplint missed could hide the measure's table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, a model file could not be fully read, and a notice names what pbiplint could not open, or the file's own PARSE_ISSUE finding names the line.
 
 Read more: https://pbiplint.com/rules/provide-format-string-for-measures`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		isHidden\n		summarizeBy: none\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		isHidden\n		summarizeBy: none\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nA measure with no format string is rendered with the client's default, which usually means no thousands separator and a decimal count that varies with the data, so the same measure can look different in two visuals on the same page. Setting the format on the measure fixes the presentation once for every report that will ever use the model, instead of leaving each report author to set it per visual and get it slightly wrong. Hidden measures and measures on hidden tables are not checked, because nothing displays them directly; a measure that has only a dynamic format string is also left alone.\n\n### How to fix it\n\nIn Power BI Desktop, select the measure in the Data pane and set Format under Measure tools. In the TMDL file, add `formatString` under the measure: `#,0` for whole numbers, `#,0.00` for decimals, a currency format such as `$#,0.00`, or `#,0.0%;-#,0.0%;#,0.0%` for percentages. Where the format depends on what the measure returns, a dynamic format string satisfies the rule as well: pick Dynamic in the Format list under Measure tools and write the expression in the formula bar, which the file records as a `formatStringDefinition` block under the measure.\n\n### When to ignore it\n\nA measure that returns text has nothing to format. A label measure that builds a title, and a measure that returns a hex color for conditional formatting, are both reported here and neither has a number behind it. Everything else the rule reports is a visible number a reader will see, so the finding is usually worth the ten seconds it takes to clear.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = PROVIDE_FORMAT_STRING_FOR_MEASURES` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"PROVIDE_FORMAT_STRING_FOR_MEASURES\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A format string of nothing but spaces counts as no format string, so `formatString: \" \"` is reported.\n- A measure with only a dynamic format string passes here but fires `INTEGER_FORMATTING`, which reads the static format string alone.\n- Hidden measures, and measures on hidden tables, are skipped. `INTEGER_FORMATTING` skips neither.\n\nRead more: https://pbiplint.com/rules/provide-format-string-for-measures"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		isHidden\n		summarizeBy: none\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		isHidden\n		summarizeBy: none\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nA measure with no format string is rendered with the client's default, which usually means no thousands separator and a decimal count that varies with the data, so the same measure can look different in two visuals on the same page. Setting the format on the measure fixes the presentation once for every report that will ever use the model, instead of leaving each report author to set it per visual and get it slightly wrong. Hidden measures and measures on hidden tables are not checked, because nothing displays them directly; a measure that has only a dynamic format string is also left alone.\n\n### How to fix it\n\nIn Power BI Desktop, select the measure in the Data pane and set Format under Measure tools. In the TMDL file, add `formatString` under the measure: `#,0` for whole numbers, `#,0.00` for decimals, a currency format such as `$#,0.00`, or `#,0.0%;-#,0.0%;#,0.0%` for percentages. Where the format depends on what the measure returns, a dynamic format string satisfies the rule as well: pick Dynamic in the Format list under Measure tools and write the expression in the formula bar, which the file records as a `formatStringDefinition` block under the measure.\n\n### When to ignore it\n\nA measure that returns text has nothing to format. A label measure that builds a title, and a measure that returns a hex color for conditional formatting, are both reported here and neither has a number behind it. Everything else the rule reports is a visible number a reader will see, so the finding is usually worth the ten seconds it takes to clear.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = PROVIDE_FORMAT_STRING_FOR_MEASURES` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"PROVIDE_FORMAT_STRING_FOR_MEASURES\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- A format string of nothing but spaces counts as no format string, so `formatString: \" \"` is reported.\n- A measure with only a dynamic format string passes here but fires `INTEGER_FORMATTING`, which reads the static format string alone.\n- Hidden measures, and measures on hidden tables, are skipped. `INTEGER_FORMATTING` skips neither.\n- The rule also needs every part of a table's declaration, which TMDL lets sit in more than one file (Power BI Desktop writes each table in one). While pbiplint could not open a model file or folder, or a parse issue took a line that could be a `table` line, such as a misspelt `table`, the rule reports nothing, because a part of the table in what pbiplint missed could hide the measure's table, and pbiplint does not guess what a file it could not read says. A parse issue inside a declaration, such as a property indented with spaces, does not stop the rule. The skipped line gives the reason, `a model file could not be fully read`, and a notice names what pbiplint could not open, or the file's own `PARSE_ISSUE` finding names the line.\n\nRead more: https://pbiplint.com/rules/provide-format-string-for-measures"
   },
   REDUCE_ADVANCED_FILTERS: {
     text: `Example
@@ -11201,12 +12161,13 @@ To ignore this rule on one object, add annotation pbiplint.ignore = REMOVE_AUTO-
 Quirks
 
 - The table has to be a calculated table as well as carry the name. A loaded table someone called DateTableTemplate_Old is not reported.
+- A composite model's copy of an auto date/time table is not reported either: a LocalDateTable_ table whose entity partition reads, in DirectQuery mode, the table of that name in the Power BI semantic model or Analysis Services model the composite model extends. The copy is not a calculated table, so the source rule leaves it out too. The table it reads is calculated in the model it extends, where this rule reports it and where Auto date/time is turned off.
 - The name test is case-sensitive and is a prefix, not a substring, so localdatetable_1 is not reported and neither is a table whose name merely contains the prefix further in.
 - Only these two names are known. A hidden calendar built by hand, or by another tool under another name, is invisible to this rule.
 - DateTableTemplate_ is the template table Desktop keeps; LocalDateTable_ is one table per date column. Both prefixes are reported, so a model with many date columns collects a finding for each of its hidden calendars.
 
 Read more: https://pbiplint.com/rules/remove-auto-date-table`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable LocalDateTable_8f2c1b4e\n	isHidden\n\n	column Date\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: [Date]\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: [Year]\n\n	partition LocalDateTable_8f2c1b4e = calculated\n		mode: import\n		source = Calendar(Date(Year(MIN('Sales'[Order Date])), 1, 1), Date(Year(MAX('Sales'[Order Date])), 12, 31))\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n### Why it matters\n\nWith Auto date/time on, Power BI Desktop creates a hidden calculated date table for every date column in the model, each with its own year, quarter, month, and day hierarchy. A model with a dozen date columns carries a dozen hidden tables, all rebuilt on every refresh, and none of them can be extended with fiscal periods or holidays or shared between fact tables. One real date table does everything they do, once.\n\n### How to fix it\n\nIn Power BI Desktop, open File, Options and settings, Options, then Current file, Data Load, and clear Auto date/time. Desktop deletes the hidden tables and the variations that point at them when the file is saved, so the `table LocalDateTable_...` blocks leave the project's TMDL files on the next save. The option itself is recorded on the model as `annotation __PBI_TimeIntelligenceEnabled`, which Desktop writes and clears for you rather than a property to edit by hand, and deleting the table blocks yourself without clearing the option only invites Desktop to write them again. Then give the model a calendar of its own: add a date table, relate each fact table's date column to it, and mark it with Mark as date table under Table tools, which writes `dataCategory: Time` on the table and `isKey` on its date column. Report authors lose the automatic date hierarchy under each date column when the option goes off, so expect to rebuild the visuals that used one against the new table's Year, Quarter, and Month columns.\n\n### When to ignore it\n\nThere is no lasting exception. These tables are not something a modeler chose, they are what Power BI Desktop falls back to, and every one of them is replaced by the single calendar the model should have anyway. The one honest reason to leave a finding for now is sequencing: in a report with many visuals built on the automatic date hierarchies, clearing the option breaks all of them at once, so the calendar goes in first, the visuals move across, and the option goes off last. That is a plan with a date on it rather than a decision to ignore the rule.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = REMOVE_AUTO-DATE_TABLE` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"REMOVE_AUTO-DATE_TABLE\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The table has to be a calculated table as well as carry the name. A loaded table someone called DateTableTemplate_Old is not reported.\n- The name test is case-sensitive and is a prefix, not a substring, so `localdatetable_1` is not reported and neither is a table whose name merely contains the prefix further in.\n- Only these two names are known. A hidden calendar built by hand, or by another tool under another name, is invisible to this rule.\n- DateTableTemplate_ is the template table Desktop keeps; LocalDateTable_ is one table per date column. Both prefixes are reported, so a model with many date columns collects a finding for each of its hidden calendars.\n\nRead more: https://pbiplint.com/rules/remove-auto-date-table"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable LocalDateTable_8f2c1b4e\n	isHidden\n\n	column Date\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: [Date]\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: [Year]\n\n	partition LocalDateTable_8f2c1b4e = calculated\n		mode: import\n		source = Calendar(Date(Year(MIN('Sales'[Order Date])), 1, 1), Date(Year(MAX('Sales'[Order Date])), 12, 31))\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order Date'\n		dataType: dateTime\n		formatString: mm/dd/yyyy\n		sourceColumn: OrderDate\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable Date\n	dataCategory: Time\n\n	column Date\n		dataType: dateTime\n		isKey\n		formatString: mm/dd/yyyy\n		sourceColumn: Date\n\n	column Year\n		dataType: int64\n		summarizeBy: none\n		sourceColumn: Year\n```\n\n### Why it matters\n\nWith Auto date/time on, Power BI Desktop creates a hidden calculated date table for every date column in the model, each with its own year, quarter, month, and day hierarchy. A model with a dozen date columns carries a dozen hidden tables, all rebuilt on every refresh, and none of them can be extended with fiscal periods or holidays or shared between fact tables. One real date table does everything they do, once.\n\n### How to fix it\n\nIn Power BI Desktop, open File, Options and settings, Options, then Current file, Data Load, and clear Auto date/time. Desktop deletes the hidden tables and the variations that point at them when the file is saved, so the `table LocalDateTable_...` blocks leave the project's TMDL files on the next save. The option itself is recorded on the model as `annotation __PBI_TimeIntelligenceEnabled`, which Desktop writes and clears for you rather than a property to edit by hand, and deleting the table blocks yourself without clearing the option only invites Desktop to write them again. Then give the model a calendar of its own: add a date table, relate each fact table's date column to it, and mark it with Mark as date table under Table tools, which writes `dataCategory: Time` on the table and `isKey` on its date column. Report authors lose the automatic date hierarchy under each date column when the option goes off, so expect to rebuild the visuals that used one against the new table's Year, Quarter, and Month columns.\n\n### When to ignore it\n\nThere is no lasting exception. These tables are not something a modeler chose, they are what Power BI Desktop falls back to, and every one of them is replaced by the single calendar the model should have anyway. The one honest reason to leave a finding for now is sequencing: in a report with many visuals built on the automatic date hierarchies, clearing the option breaks all of them at once, so the calendar goes in first, the visuals move across, and the option goes off last. That is a plan with a date on it rather than a decision to ignore the rule.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = REMOVE_AUTO-DATE_TABLE` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"REMOVE_AUTO-DATE_TABLE\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The table has to be a calculated table as well as carry the name. A loaded table someone called DateTableTemplate_Old is not reported.\n- A composite model's copy of an auto date/time table is not reported either: a `LocalDateTable_` table whose `entity` partition reads, in DirectQuery mode, the table of that name in the Power BI semantic model or Analysis Services model the composite model extends. The copy is not a calculated table, so the source rule leaves it out too. The table it reads is calculated in the model it extends, where this rule reports it and where Auto date/time is turned off.\n- The name test is case-sensitive and is a prefix, not a substring, so `localdatetable_1` is not reported and neither is a table whose name merely contains the prefix further in.\n- Only these two names are known. A hidden calendar built by hand, or by another tool under another name, is invisible to this rule.\n- DateTableTemplate_ is the template table Desktop keeps; LocalDateTable_ is one table per date column. Both prefixes are reported, so a model with many date columns collects a finding for each of its hidden calendars.\n\nRead more: https://pbiplint.com/rules/remove-auto-date-table"
   },
   REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS: {
     text: `Example
@@ -11257,9 +12218,10 @@ Quirks
 - Power BI Desktop never writes data sources, so this rule matters only for hand-built or migrated models.
 - The text test is a plain substring match on each partition's query or M text, and letter case has to agree. A data source whose name happens to appear in that text, even inside a comment or inside a longer name, counts as referenced, and a name the partition spells with different capitalization does not match at all.
 - The source rule searches each table's source expression as well as every partition's query. pbiplint reads the partitions for both, since that is where a TMDL file keeps the text.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the partition that uses the data source could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/remove-data-sources-not-referenced-by-any-partitions`,
-    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ndataSource \'Legacy SQL\' = provider\n	connectionString: Data Source=contoso;Initial Catalog=Warehouse\n	impersonationMode: impersonateServiceAccount\n\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: import\n		source = let Source = Sql.Database("contoso", "Sales") in Source\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: import\n		source = let Source = Sql.Database("contoso", "Sales") in Source\n```\n\n### Why it matters\n\nAn unused data source is a connection string, and usually a credential, that the model still asks to have configured on every deployment, so the service keeps prompting for credentials to a source nothing reads. It is a leftover from a migration or a source that was replaced.\n\n### How to fix it\n\nDelete the data source. In the project it is a `dataSource` block, usually in a file of its own under the `dataSources` folder: remove the file and the matching `ref` line in `model.tmdl`, or delete the block where it sits. Power BI Desktop does not show data sources, and Transform data, Data source settings lists the sources the queries name rather than these declarations, so the file is the place to do it. If the source is still wanted, point a partition at it instead, with `dataSource:` under the partition\'s `source` block.\n\n### When to ignore it\n\nA model whose partitions are created after it is deployed, by a pipeline or a script that binds them to a source the files do not yet name, keeps the declaration on purpose, and the finding on it is noise. So is a source you have just added and are about to wire up. Outside those, a data source nothing reads is a leftover, and the credential prompt it produces on every deployment is the cost of keeping it.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Tabular Editor 3 CLI 0.5.2 did not report this rule when loading from TMDL, although it did from .bim; pbiplint follows the rule text.\n- Power BI Desktop never writes data sources, so this rule matters only for hand-built or migrated models.\n- The text test is a plain substring match on each partition\'s query or M text, and letter case has to agree. A data source whose name happens to appear in that text, even inside a comment or inside a longer name, counts as referenced, and a name the partition spells with different capitalization does not match at all.\n- The source rule searches each table\'s source expression as well as every partition\'s query. pbiplint reads the partitions for both, since that is where a TMDL file keeps the text.\n\nRead more: https://pbiplint.com/rules/remove-data-sources-not-referenced-by-any-partitions'
+    markdown: '### Example\n\n**Fires the rule**\n\n```tmdl\ndataSource \'Legacy SQL\' = provider\n	connectionString: Data Source=contoso;Initial Catalog=Warehouse\n	impersonationMode: impersonateServiceAccount\n\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: import\n		source = let Source = Sql.Database("contoso", "Sales") in Source\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	partition Sales = m\n		mode: import\n		source = let Source = Sql.Database("contoso", "Sales") in Source\n```\n\n### Why it matters\n\nAn unused data source is a connection string, and usually a credential, that the model still asks to have configured on every deployment, so the service keeps prompting for credentials to a source nothing reads. It is a leftover from a migration or a source that was replaced.\n\n### How to fix it\n\nDelete the data source. In the project it is a `dataSource` block, usually in a file of its own under the `dataSources` folder: remove the file and the matching `ref` line in `model.tmdl`, or delete the block where it sits. Power BI Desktop does not show data sources, and Transform data, Data source settings lists the sources the queries name rather than these declarations, so the file is the place to do it. If the source is still wanted, point a partition at it instead, with `dataSource:` under the partition\'s `source` block.\n\n### When to ignore it\n\nA model whose partitions are created after it is deployed, by a pipeline or a script that binds them to a source the files do not yet name, keeps the declaration on purpose, and the finding on it is noise. So is a source you have just added and are about to wire up. Outside those, a data source nothing reads is a leftover, and the credential prompt it produces on every deployment is the cost of keeping it.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `"REMOVE_DATA_SOURCES_NOT_REFERENCED_BY_ANY_PARTITIONS": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Tabular Editor 3 CLI 0.5.2 did not report this rule when loading from TMDL, although it did from .bim; pbiplint follows the rule text.\n- Power BI Desktop never writes data sources, so this rule matters only for hand-built or migrated models.\n- The text test is a plain substring match on each partition\'s query or M text, and letter case has to agree. A data source whose name happens to appear in that text, even inside a comment or inside a longer name, counts as referenced, and a name the partition spells with different capitalization does not match at all.\n- The source rule searches each table\'s source expression as well as every partition\'s query. pbiplint reads the partitions for both, since that is where a TMDL file keeps the text.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the partition that uses the data source could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file\'s own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/remove-data-sources-not-referenced-by-any-partitions'
   },
   REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES: {
     text: `Example
@@ -11344,9 +12306,10 @@ Quirks
 - Any column on the related table counts as the duplicate, the relationship key and hidden columns included.
 - Cardinality is not tested, only the from and to sides of the relationship, so a one-to-one relationship counts the same as a many-to-one.
 - All three column kinds are in scope, so a loaded column, a DAX calculated column, and a calculated table's column are read alike.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the column's own relationship could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/remove-redundant-columns-in-related-tables`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		isHidden\n		sourceColumn: ProductID\n\n	column 'Product Name'\n		dataType: string\n		sourceColumn: ProductName\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n\n	column 'Product Name'\n		dataType: string\n		sourceColumn: ProductName\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		isHidden\n		sourceColumn: ProductID\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n\n	column 'Product Name'\n		dataType: string\n		sourceColumn: ProductName\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n```\n\n### Why it matters\n\nA fact table row that carries the product name as well as the product key stores the name once per sale instead of once per product, and offers the report author two Product Name fields that behave differently: the fact table's version cannot filter other fact tables and shows only the names that have sales. The dimension's copy is the one that should exist.\n\n### How to fix it\n\nStop loading the column on the fact table. In Power BI Desktop choose Transform data, select the fact table's query, and use Choose Columns or Remove Columns so the column never reaches the model; where the query reads a view or a stored procedure, drop it from the select list there instead and the refresh gets shorter too. A duplicate that is a DAX calculated column goes instead by right-clicking it in the Data pane and choosing Delete from model, or by removing its `column Name = expression` block from the table's TMDL file. Then point the visuals that used it at the dimension's column, which filters the way a report author expects, and where a measure needs the value at row grain, reach it with RELATED inside the measure rather than storing it again. Hiding the column is not a fix here: the rule never reads a column's visibility, so a hidden copy is reported exactly as a visible one is, and it still costs the same memory.\n\n### When to ignore it\n\nCoincidence is the common false alarm. The test is the column's name and nothing else, so `'Sales'[Description]` and `'Product'[Description]` are reported as duplicates when one is a line note and the other a catalogue blurb. Read both columns before removing either. A copy kept on purpose is the other legitimate case: a fact table that carries a snapshot of the attribute as it was on the order date is not the dimension's current value and must not be replaced by it, and a column the source system denormalized for a composite key can be cheaper to keep than to rebuild. Check whether the two columns hold the same values for the same key, which a quick visual of both will answer, and ignore the finding where they do not. A plain copy of a slowly changing dimension's current name on a large fact table is what the rule is for.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Matching is by column name only, exactly and with letter case respected, so two unrelated columns that happen to share a name fire too, and renaming the copy clears the finding without removing anything.\n- The direction matters. Only a column on the from side's table is reported, so the dimension's own copy is never named, and a column on the to side that duplicates a fact table column is not reported either.\n- A column that takes part in any relationship, on either side, is never reported. A foreign key whose name matches the dimension's key is therefore out of scope.\n- Any column on the related table counts as the duplicate, the relationship key and hidden columns included.\n- Cardinality is not tested, only the from and to sides of the relationship, so a one-to-one relationship counts the same as a many-to-one.\n- All three column kinds are in scope, so a loaded column, a DAX calculated column, and a calculated table's column are read alike.\n\nRead more: https://pbiplint.com/rules/remove-redundant-columns-in-related-tables"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		isHidden\n		sourceColumn: ProductID\n\n	column 'Product Name'\n		dataType: string\n		sourceColumn: ProductName\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n\n	column 'Product Name'\n		dataType: string\n		sourceColumn: ProductName\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Product ID'\n		dataType: int64\n		isHidden\n		sourceColumn: ProductID\n\n	column Amount\n		dataType: decimal\n		summarizeBy: sum\n		sourceColumn: Amount\n\ntable Product\n	column 'Product ID'\n		dataType: int64\n		isKey\n		sourceColumn: ProductID\n\n	column 'Product Name'\n		dataType: string\n		sourceColumn: ProductName\n\nrelationship Sales_Product\n	fromColumn: Sales.'Product ID'\n	toColumn: Product.'Product ID'\n```\n\n### Why it matters\n\nA fact table row that carries the product name as well as the product key stores the name once per sale instead of once per product, and offers the report author two Product Name fields that behave differently: the fact table's version cannot filter other fact tables and shows only the names that have sales. The dimension's copy is the one that should exist.\n\n### How to fix it\n\nStop loading the column on the fact table. In Power BI Desktop choose Transform data, select the fact table's query, and use Choose Columns or Remove Columns so the column never reaches the model; where the query reads a view or a stored procedure, drop it from the select list there instead and the refresh gets shorter too. A duplicate that is a DAX calculated column goes instead by right-clicking it in the Data pane and choosing Delete from model, or by removing its `column Name = expression` block from the table's TMDL file. Then point the visuals that used it at the dimension's column, which filters the way a report author expects, and where a measure needs the value at row grain, reach it with RELATED inside the measure rather than storing it again. Hiding the column is not a fix here: the rule never reads a column's visibility, so a hidden copy is reported exactly as a visible one is, and it still costs the same memory.\n\n### When to ignore it\n\nCoincidence is the common false alarm. The test is the column's name and nothing else, so `'Sales'[Description]` and `'Product'[Description]` are reported as duplicates when one is a line note and the other a catalogue blurb. Read both columns before removing either. A copy kept on purpose is the other legitimate case: a fact table that carries a snapshot of the attribute as it was on the order date is not the dimension's current value and must not be replaced by it, and a column the source system denormalized for a composite key can be cheaper to keep than to rebuild. Check whether the two columns hold the same values for the same key, which a quick visual of both will answer, and ignore the finding where they do not. A plain copy of a slowly changing dimension's current name on a large fact table is what the rule is for.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"REMOVE_REDUNDANT_COLUMNS_IN_RELATED_TABLES\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- Matching is by column name only, exactly and with letter case respected, so two unrelated columns that happen to share a name fire too, and renaming the copy clears the finding without removing anything.\n- The direction matters. Only a column on the from side's table is reported, so the dimension's own copy is never named, and a column on the to side that duplicates a fact table column is not reported either.\n- A column that takes part in any relationship, on either side, is never reported. A foreign key whose name matches the dimension's key is therefore out of scope.\n- Any column on the related table counts as the duplicate, the relationship key and hidden columns included.\n- Cardinality is not tested, only the from and to sides of the relationship, so a one-to-one relationship counts the same as a many-to-one.\n- All three column kinds are in scope, so a loaded column, a DAX calculated column, and a calculated table's column are read alike.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the column's own relationship could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/remove-redundant-columns-in-related-tables"
   },
   REMOVE_ROLES_WITH_NO_MEMBERS: {
     text: `Example
@@ -11544,12 +12507,12 @@ This rule reports on measures defined in the report, and pbiplint reads no annot
 
 Quirks
 
-- The rule reports only when the model the report reads is in the input. A report whose definition.pbir connects to a published model is left alone on purpose: Microsoft presents report measures as the way an author who builds on a shared semantic model through a live connection, which cannot change the model itself, adds calculations of their own. Such a report is linted without a model, as is a report given on its own, and the skipped line gives the reason, such as this report reads a published model or no model in the input.
+- The rule reports only when the model the report reads is in the input. A report whose definition.pbir connects to a published model is left alone on purpose: Microsoft presents report measures as the way an author who builds on a shared semantic model through a live connection, which cannot change the model itself, adds calculations of their own. Such a report is linted without a model, as is a report given on its own, and the skipped line gives the reason, such as this report reads a published model or this report reads ../Sales.SemanticModel, which this run did not include.
 - pbiplint reads no annotation on a measure in reportExtensions.json, so the rule is turned off for a whole project rather than for one measure.
 - A measure with an empty expression is reported like any other.
 
 Read more: https://pbiplint.com/rules/report-level-measures`,
-    markdown: '### Example\n\nThe example runs against a model with one table, Sales, holding Amount and Region and the measure Total Sales.\n\n**Fires the rule in reportExtensions.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/reportExtension/1.0.0/schema.json",\n  "name": "extension",\n  "entities": [\n    {\n      "name": "Sales",\n      "measures": [\n        {\n          "name": "Sales per Region",\n          "dataType": "Double",\n          "expression": "DIVIDE([Total Sales], DISTINCTCOUNT(\'Sales\'[Region]))"\n        }\n      ]\n    }\n  ]\n}\n```\n\n**After the fix in reportExtensions.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/reportExtension/1.0.0/schema.json",\n  "name": "extension",\n  "entities": []\n}\n```\n\nThe report defines Sales per Region for itself, on the Sales table, so the finding reads `[Sales per Region] (report)` with `defined in the report on table "Sales"`. The fixed file shows the report\'s side of the move: once the measure is in the model\'s Sales table, as How to fix it describes, the report defines none.\n\n### Why it matters\n\nA report measure is a calculation created directly within a report, without altering the semantic model, so the model never carries it and only the report that defines it can use it. Another report on the same model does not have it. When the model is in your hands, as it is when the report reads it by path from the same project, a calculation kept in one report splits the model\'s logic in two: the next author looking for it in the model does not find it, and a second report that needs it gets a copy of its own, free to drift from the first.\n\npbiplint checks such a measure less well too. Its DAX rules read the model\'s measures only, so none of them looks at a report measure\'s expression, and `BROKEN_FIELD_REFERENCE` does not report a field that a report measure\'s DAX names and the model lacks.\n\n### How to fix it\n\nMove the measure into the model, with the same name, on the same table, with the same DAX, then point the report at it.\n\nTake the measure\'s `name` and `expression` from its entry in reportExtensions.json, with any other property it sets, such as `formatString`, `displayFolder`, `description`, `hidden`, or `dataCategory`. Then delete that entry, and the entity with it when it holds no other measure, as in the example. Do this before the model gets the measure: the schema for reportExtensions.json asks that a report measure\'s name be unique across the model, so the two should not exist side by side.\n\nCreate the measure in the model. A report that reads its model by path opens that model for editing in Power BI Desktop: right-click the table in the Data pane, or hover over it and select More options (...), choose New measure, and type the name and the DAX into the formula bar. A measure created from a table\'s menu is saved in that table. In the model\'s TMDL, the same measure is a `measure` under the table in its file, as `measure \'Sales per Region\' = DIVIDE([Total Sales], DISTINCTCOUNT(\'Sales\'[Region]))`, with its other properties set to match.\n\nThen point the report at the model\'s measure. A reference to a report measure names the report\'s extension: `"Schema": "extension"` sits on the reference\'s `SourceRef`, beside the `Entity`, or, in a filter\'s condition, on the `From` entry its alias names, where a reference to a model measure has no `Schema`. Microsoft\'s schemas describe the key: in a query, `Schema` is "the name of the schema containing the referenced entity" and can be left out, and where a report measure lists the measures its DAX uses, the schema is left empty for a model measure and set to the extension\'s name for one of the extension\'s own. So every well, filter, sort, and bookmark that used the measure still names it in the extension after the move. In Power BI Desktop, add the model\'s measure from the Data pane to each well, filter, and sort that used the report measure, and for a bookmark that captured it, select the bookmark and choose Update from its More options menu. In the report\'s JSON, remove the `"Schema": "extension"` key from every reference to the measure, in each visual.json and in the bookmarks.\n\nLint again when you are done. `BROKEN_FIELD_REFERENCE` reports every reference still naming the extension, and each finding\'s detail depends on whether reportExtensions.json is still there. While it is, as in the fixed example, the detail reads `[Sales per Region]: no measure named "Sales per Region" on "Sales" in the report\'s extension`. A report\'s definition folder does not require the file, so once its `entities` list is empty you can delete it instead, and then the detail reads `[Sales per Region]: no measure named "Sales per Region" on "Sales": the report defines no extension measures`.\n\n### When to ignore it\n\nA report measure is the supported route for an author who cannot change the model, and such a report can still reach pbiplint beside the model. When the model and the report share a workspace, Fabric Git integration always exports the report with a reference by path to the model. Microsoft describes keeping a second .pbir file that connects to the published model, so that the report opens in live connect to work with report-level measures, while definition.pbir, the file pbiplint reads, keeps its reference by path. If that is how the report is built and the model belongs to someone else, ignore the finding. When the model is yours to change, a measure rarely has a reason to stay in one report.\n\nThis rule reports on measures defined in the report, and pbiplint reads no annotation on them, so there is no object to annotate. To turn the rule off for a whole project, set `"REPORT_LEVEL_MEASURES": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The rule reports only when the model the report reads is in the input. A report whose definition.pbir connects to a published model is left alone on purpose: Microsoft presents report measures as the way an author who builds on a shared semantic model through a live connection, which cannot change the model itself, adds calculations of their own. Such a report is linted without a model, as is a report given on its own, and the skipped line gives the reason, such as `this report reads a published model` or `no model in the input`.\n- pbiplint reads no annotation on a measure in reportExtensions.json, so the rule is turned off for a whole project rather than for one measure.\n- A measure with an empty expression is reported like any other.\n\nRead more: https://pbiplint.com/rules/report-level-measures'
+    markdown: '### Example\n\nThe example runs against a model with one table, Sales, holding Amount and Region and the measure Total Sales.\n\n**Fires the rule in reportExtensions.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/reportExtension/1.0.0/schema.json",\n  "name": "extension",\n  "entities": [\n    {\n      "name": "Sales",\n      "measures": [\n        {\n          "name": "Sales per Region",\n          "dataType": "Double",\n          "expression": "DIVIDE([Total Sales], DISTINCTCOUNT(\'Sales\'[Region]))"\n        }\n      ]\n    }\n  ]\n}\n```\n\n**After the fix in reportExtensions.json**\n\n```json\n{\n  "$schema": "https://developer.microsoft.com/json-schemas/fabric/item/report/definition/reportExtension/1.0.0/schema.json",\n  "name": "extension",\n  "entities": []\n}\n```\n\nThe report defines Sales per Region for itself, on the Sales table, so the finding reads `[Sales per Region] (report)` with `defined in the report on table "Sales"`. The fixed file shows the report\'s side of the move: once the measure is in the model\'s Sales table, as How to fix it describes, the report defines none.\n\n### Why it matters\n\nA report measure is a calculation created directly within a report, without altering the semantic model, so the model never carries it and only the report that defines it can use it. Another report on the same model does not have it. When the model is in your hands, as it is when the report reads it by path from the same project, a calculation kept in one report splits the model\'s logic in two: the next author looking for it in the model does not find it, and a second report that needs it gets a copy of its own, free to drift from the first.\n\npbiplint checks such a measure less well too. Its DAX rules read the model\'s measures only, so none of them looks at a report measure\'s expression, and `BROKEN_FIELD_REFERENCE` does not report a field that a report measure\'s DAX names and the model lacks.\n\n### How to fix it\n\nMove the measure into the model, with the same name, on the same table, with the same DAX, then point the report at it.\n\nTake the measure\'s `name` and `expression` from its entry in reportExtensions.json, with any other property it sets, such as `formatString`, `displayFolder`, `description`, `hidden`, or `dataCategory`. Then delete that entry, and the entity with it when it holds no other measure, as in the example. Do this before the model gets the measure: the schema for reportExtensions.json asks that a report measure\'s name be unique across the model, so the two should not exist side by side.\n\nCreate the measure in the model. A report that reads its model by path opens that model for editing in Power BI Desktop: right-click the table in the Data pane, or hover over it and select More options (...), choose New measure, and type the name and the DAX into the formula bar. A measure created from a table\'s menu is saved in that table. In the model\'s TMDL, the same measure is a `measure` under the table in its file, as `measure \'Sales per Region\' = DIVIDE([Total Sales], DISTINCTCOUNT(\'Sales\'[Region]))`, with its other properties set to match.\n\nThen point the report at the model\'s measure. A reference to a report measure names the report\'s extension: `"Schema": "extension"` sits on the reference\'s `SourceRef`, beside the `Entity`, or, in a filter\'s condition, on the `From` entry its alias names, where a reference to a model measure has no `Schema`. Microsoft\'s schemas describe the key: in a query, `Schema` is "the name of the schema containing the referenced entity" and can be left out, and where a report measure lists the measures its DAX uses, the schema is left empty for a model measure and set to the extension\'s name for one of the extension\'s own. So every well, filter, sort, and bookmark that used the measure still names it in the extension after the move. In Power BI Desktop, add the model\'s measure from the Data pane to each well, filter, and sort that used the report measure, and for a bookmark that captured it, select the bookmark and choose Update from its More options menu. In the report\'s JSON, remove the `"Schema": "extension"` key from every reference to the measure, in each visual.json and in the bookmarks.\n\nLint again when you are done. `BROKEN_FIELD_REFERENCE` reports every reference still naming the extension, and each finding\'s detail depends on whether reportExtensions.json is still there. While it is, as in the fixed example, the detail reads `[Sales per Region]: no measure named "Sales per Region" on "Sales" in the report\'s extension`. A report\'s definition folder does not require the file, so once its `entities` list is empty you can delete it instead, and then the detail reads `[Sales per Region]: no measure named "Sales per Region" on "Sales": the report defines no extension measures`.\n\n### When to ignore it\n\nA report measure is the supported route for an author who cannot change the model, and such a report can still reach pbiplint beside the model. When the model and the report share a workspace, Fabric Git integration always exports the report with a reference by path to the model. Microsoft describes keeping a second .pbir file that connects to the published model, so that the report opens in live connect to work with report-level measures, while definition.pbir, the file pbiplint reads, keeps its reference by path. If that is how the report is built and the model belongs to someone else, ignore the finding. When the model is yours to change, a measure rarely has a reason to stay in one report.\n\nThis rule reports on measures defined in the report, and pbiplint reads no annotation on them, so there is no object to annotate. To turn the rule off for a whole project, set `"REPORT_LEVEL_MEASURES": "off"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- The rule reports only when the model the report reads is in the input. A report whose definition.pbir connects to a published model is left alone on purpose: Microsoft presents report measures as the way an author who builds on a shared semantic model through a live connection, which cannot change the model itself, adds calculations of their own. Such a report is linted without a model, as is a report given on its own, and the skipped line gives the reason, such as `this report reads a published model` or `this report reads ../Sales.SemanticModel, which this run did not include`.\n- pbiplint reads no annotation on a measure in reportExtensions.json, so the rule is turned off for a whole project rather than for one measure.\n- A measure with an empty expression is reported like any other.\n\nRead more: https://pbiplint.com/rules/report-level-measures'
   },
   SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS: {
     text: `Example
@@ -12316,19 +13279,23 @@ For a data column, stop loading it: in Power BI Desktop, Transform data, select
 
 When to ignore it
 
-Report usage is the case to check first. A hidden column that a visual, a slicer, or a report-level filter binds to is in use, and pbiplint reads the model, not the report, so open the reports before you delete anything. A column named as the default column of a variation is in the same position: the rule does not read variations, so it reports one that Power BI Desktop is quietly relying on. A staging column you are about to reference is a fair thing to leave for a week. A hidden key that no relationship uses is not: that one is what the rule is for.
+Report usage is the case to check first. A hidden column that a visual, a slicer, or a report-level filter binds to is in use, but this rule reads the model only, as the source rule does, so it reports that column all the same. When the report is in the input, NOT_REACHED_FROM_REPORT says which fields that report never reaches; other reports on the same model are still yours to open before you delete anything. A column named as the default column of a variation is in the same position: the rule does not read variations, so it reports one that Power BI Desktop is quietly relying on. A staging column you are about to reference is a fair thing to leave for a week. A hidden key that no relationship uses is not: that one is what the rule is for.
 
 To ignore this rule on one object, add annotation pbiplint.ignore = UNNECESSARY_COLUMNS under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set "UNNECESSARY_COLUMNS": "off" under rules in pbiplint.config.json.
 
 Quirks
 
 - DAX references are approximated by pattern matching: references inside strings or comments count, and a bare [Column] reference resolves measure-first, then the expression's own table, then the first table with that column.
+- A column that a user-defined function names with its table counts as used, even when nothing calls the function, as Tabular Editor counts it.
+- A column that a user-defined function names without its table counts as used, on every table with a column of that name, since the caller can hand the function any table. In pbiplint's parity check, Tabular Editor counted such a name inside SUMX ( 'Sales', [Handling Fee] ) but reported the column a function names in MAX ( [Tax Rate] ), though deleting it would break the function.
+- A column that another column in its table groups by counts as used, as a field parameter's hidden Fields column is: the parameter's display column names it as its groupByColumn under relatedColumnDetails, and the parameter stops working without it. The source rule does not test groupByColumn, so Tabular Editor reports that column.
 - Report usage is not visible to this rule. A hidden column used only by a visual, a slicer, or a report-level filter is still flagged.
 - Variations are not tested, here or in the source rule, so a hidden column that a variation names as its default column is reported. SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS does read variations.
 - Row-level security is matched as text, ignoring letter case, the way the source rule matches it. A bare [Column] in any role's filter already counts as a DAX reference (see above), so the text test only adds the qualified forms Table[Column] and 'Table'[Column].
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because a measure, a relationship, or a security filter that uses the column could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/unnecessary-columns`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	column 'Legacy Region Code'\n		dataType: string\n		isHidden\n		sourceColumn: LegacyRegionCode\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nA hidden column that nothing uses is loaded, compressed, and refreshed for no reader. Key columns and helper columns pile up this way as a model evolves, and each one costs memory and refresh time in proportion to its cardinality. Removing them is the cheapest model diet there is.\n\n### How to fix it\n\nFor a data column, stop loading it: in Power BI Desktop, Transform data, select the query, and use Choose Columns or Remove Columns, so the column never reaches the model. Where the query reads a view or a stored procedure, drop it from the select list there instead and the refresh gets shorter too. For a calculated column, right-click it in the Data pane and choose Delete from model, or remove its `column` block from the table's TMDL file. If the column turns out to be needed after all, clear Is hidden in the Properties pane, or remove `isHidden` from under the column in the file, and the finding goes with it.\n\n### When to ignore it\n\nReport usage is the case to check first. A hidden column that a visual, a slicer, or a report-level filter binds to is in use, and pbiplint reads the model, not the report, so open the reports before you delete anything. A column named as the default column of a variation is in the same position: the rule does not read variations, so it reports one that Power BI Desktop is quietly relying on. A staging column you are about to reference is a fair thing to leave for a week. A hidden key that no relationship uses is not: that one is what the rule is for.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = UNNECESSARY_COLUMNS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"UNNECESSARY_COLUMNS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- DAX references are approximated by pattern matching: references inside strings or comments count, and a bare `[Column]` reference resolves measure-first, then the expression's own table, then the first table with that column.\n- Report usage is not visible to this rule. A hidden column used only by a visual, a slicer, or a report-level filter is still flagged.\n- Variations are not tested, here or in the source rule, so a hidden column that a variation names as its default column is reported. `SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS` does read variations.\n- Row-level security is matched as text, ignoring letter case, the way the source rule matches it. A bare `[Column]` in any role's filter already counts as a DAX reference (see above), so the text test only adds the qualified forms `Table[Column]` and `'Table'[Column]`.\n\nRead more: https://pbiplint.com/rules/unnecessary-columns"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	column 'Legacy Region Code'\n		dataType: string\n		isHidden\n		sourceColumn: LegacyRegionCode\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column 'Order ID'\n		dataType: int64\n		sourceColumn: OrderID\n\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nA hidden column that nothing uses is loaded, compressed, and refreshed for no reader. Key columns and helper columns pile up this way as a model evolves, and each one costs memory and refresh time in proportion to its cardinality. Removing them is the cheapest model diet there is.\n\n### How to fix it\n\nFor a data column, stop loading it: in Power BI Desktop, Transform data, select the query, and use Choose Columns or Remove Columns, so the column never reaches the model. Where the query reads a view or a stored procedure, drop it from the select list there instead and the refresh gets shorter too. For a calculated column, right-click it in the Data pane and choose Delete from model, or remove its `column` block from the table's TMDL file. If the column turns out to be needed after all, clear Is hidden in the Properties pane, or remove `isHidden` from under the column in the file, and the finding goes with it.\n\n### When to ignore it\n\nReport usage is the case to check first. A hidden column that a visual, a slicer, or a report-level filter binds to is in use, but this rule reads the model only, as the source rule does, so it reports that column all the same. When the report is in the input, `NOT_REACHED_FROM_REPORT` says which fields that report never reaches; other reports on the same model are still yours to open before you delete anything. A column named as the default column of a variation is in the same position: the rule does not read variations, so it reports one that Power BI Desktop is quietly relying on. A staging column you are about to reference is a fair thing to leave for a week. A hidden key that no relationship uses is not: that one is what the rule is for.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = UNNECESSARY_COLUMNS` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"UNNECESSARY_COLUMNS\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- DAX references are approximated by pattern matching: references inside strings or comments count, and a bare `[Column]` reference resolves measure-first, then the expression's own table, then the first table with that column.\n- A column that a user-defined function names with its table counts as used, even when nothing calls the function, as Tabular Editor counts it.\n- A column that a user-defined function names without its table counts as used, on every table with a column of that name, since the caller can hand the function any table. In pbiplint's parity check, Tabular Editor counted such a name inside `SUMX ( 'Sales', [Handling Fee] )` but reported the column a function names in `MAX ( [Tax Rate] )`, though deleting it would break the function.\n- A column that another column in its table groups by counts as used, as a field parameter's hidden Fields column is: the parameter's display column names it as its `groupByColumn` under `relatedColumnDetails`, and the parameter stops working without it. The source rule does not test `groupByColumn`, so Tabular Editor reports that column.\n- Report usage is not visible to this rule. A hidden column used only by a visual, a slicer, or a report-level filter is still flagged.\n- Variations are not tested, here or in the source rule, so a hidden column that a variation names as its default column is reported. `SET_ISAVAILABLEINMDX_TO_TRUE_ON_NECESSARY_COLUMNS` does read variations.\n- Row-level security is matched as text, ignoring letter case, the way the source rule matches it. A bare `[Column]` in any role's filter already counts as a DAX reference (see above), so the text test only adds the qualified forms `Table[Column]` and `'Table'[Column]`.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because a measure, a relationship, or a security filter that uses the column could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/unnecessary-columns"
   },
   UNNECESSARY_MEASURES: {
     text: `Example
@@ -12363,11 +13330,11 @@ A hidden measure that no other measure uses can only be reached by a report that
 
 How to fix it
 
-In Power BI Desktop, right-click the measure in the Data pane and choose Delete from model, or, if reports still use it, clear Is hidden in the Properties pane so the dependency is visible to the next person. In the TMDL file, remove the measure block from its table, or remove isHidden from under it. Search the project for the measure's name before you delete it: pbiplint has already read every expression in the model, so what a search adds is the report files, which it does not read.
+In Power BI Desktop, right-click the measure in the Data pane and choose Delete from model, or, if reports still use it, clear Is hidden in the Properties pane so the dependency is visible to the next person. In the TMDL file, remove the measure block from its table, or remove isHidden from under it. Search the project for the measure's name before you delete it: this rule has already searched the model's DAX (measures and their format strings, calculated columns and tables, calculation items, row-level security filters, and user-defined functions), so what a search adds is the report files, which this rule does not read, and anything else in the model that names the measure.
 
 When to ignore it
 
-Report usage is the case to check first. A hidden measure that a visual or a report-level filter binds to directly is in use, and pbiplint reads the model, not the report, so open the reports before you delete one. A measure you have written for a calculation item or a measure you have not finished is a fair thing to leave for as long as that lasts. A hidden measure nobody can name a caller for is what the rule is for.
+Report usage is the case to check first. A hidden measure that a visual or a report-level filter binds to directly is in use, but this rule reads the model only, as the source rule does, so it reports that measure all the same. When the report is in the input, NOT_REACHED_FROM_REPORT says which fields that report never reaches; other reports on the same model are still yours to open before you delete a measure. A measure you have written for a calculation item or a measure you have not finished is a fair thing to leave for as long as that lasts. A hidden measure nobody can name a caller for is what the rule is for.
 
 To ignore this rule on one object, add annotation pbiplint.ignore = UNNECESSARY_MEASURES under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set "UNNECESSARY_MEASURES": "off" under rules in pbiplint.config.json.
 
@@ -12376,10 +13343,12 @@ Quirks
 - References from calculation items and from other hidden measures count as usage.
 - Report usage is not visible to this rule. A hidden measure used only by a visual is still flagged.
 - A row-level security filter counts as a DAX expression, so a measure named in one is used.
+- A measure named in a user-defined function counts as referenced, even when nothing calls the function, as Tabular Editor counts it. When the report is in the input, NOT_REACHED_FROM_REPORT follows the calls, so it reports a measure that only an uncalled function uses.
 - A bare [Measure] reference resolves by name across the whole model, ignoring letter case, so it counts wherever the measure lives. References are found by pattern, not by parsing, so a measure named inside a string or a comment counts as used too.
+- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the DAX that references the measure could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, a model file could not be fully read, and the file's own PARSE_ISSUE finding names it, or a notice does for a file or folder pbiplint could not open.
 
 Read more: https://pbiplint.com/rules/unnecessary-measures`,
-    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n\n	measure 'Total Sales Legacy' = SUMX('Sales', 'Sales'[Amount])\n		isHidden\n		formatString: #,0\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nA hidden measure that no other measure uses can only be reached by a report that already had it, so it is either dead or a hidden dependency that breaks the day someone deletes it as dead. Either way it belongs in the open or in the bin.\n\n### How to fix it\n\nIn Power BI Desktop, right-click the measure in the Data pane and choose Delete from model, or, if reports still use it, clear Is hidden in the Properties pane so the dependency is visible to the next person. In the TMDL file, remove the `measure` block from its table, or remove `isHidden` from under it. Search the project for the measure's name before you delete it: pbiplint has already read every expression in the model, so what a search adds is the report files, which it does not read.\n\n### When to ignore it\n\nReport usage is the case to check first. A hidden measure that a visual or a report-level filter binds to directly is in use, and pbiplint reads the model, not the report, so open the reports before you delete one. A measure you have written for a calculation item or a measure you have not finished is a fair thing to leave for as long as that lasts. A hidden measure nobody can name a caller for is what the rule is for.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = UNNECESSARY_MEASURES` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"UNNECESSARY_MEASURES\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- References from calculation items and from other hidden measures count as usage.\n- Report usage is not visible to this rule. A hidden measure used only by a visual is still flagged.\n- A row-level security filter counts as a DAX expression, so a measure named in one is used.\n- A bare `[Measure]` reference resolves by name across the whole model, ignoring letter case, so it counts wherever the measure lives. References are found by pattern, not by parsing, so a measure named inside a string or a comment counts as used too.\n\nRead more: https://pbiplint.com/rules/unnecessary-measures"
+    markdown: "### Example\n\n**Fires the rule**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n\n	measure 'Total Sales Legacy' = SUMX('Sales', 'Sales'[Amount])\n		isHidden\n		formatString: #,0\n```\n\n**After the fix**\n\n```tmdl\ntable Sales\n	column Amount\n		dataType: decimal\n		sourceColumn: Amount\n\n	measure 'Total Sales' = SUM('Sales'[Amount])\n		formatString: #,0\n```\n\n### Why it matters\n\nA hidden measure that no other measure uses can only be reached by a report that already had it, so it is either dead or a hidden dependency that breaks the day someone deletes it as dead. Either way it belongs in the open or in the bin.\n\n### How to fix it\n\nIn Power BI Desktop, right-click the measure in the Data pane and choose Delete from model, or, if reports still use it, clear Is hidden in the Properties pane so the dependency is visible to the next person. In the TMDL file, remove the `measure` block from its table, or remove `isHidden` from under it. Search the project for the measure's name before you delete it: this rule has already searched the model's DAX (measures and their format strings, calculated columns and tables, calculation items, row-level security filters, and user-defined functions), so what a search adds is the report files, which this rule does not read, and anything else in the model that names the measure.\n\n### When to ignore it\n\nReport usage is the case to check first. A hidden measure that a visual or a report-level filter binds to directly is in use, but this rule reads the model only, as the source rule does, so it reports that measure all the same. When the report is in the input, `NOT_REACHED_FROM_REPORT` says which fields that report never reaches; other reports on the same model are still yours to open before you delete a measure. A measure you have written for a calculation item or a measure you have not finished is a fair thing to leave for as long as that lasts. A hidden measure nobody can name a caller for is what the rule is for.\n\nTo ignore this rule on one object, add `annotation pbiplint.ignore = UNNECESSARY_MEASURES` under the object in its TMDL file. Power BI Desktop keeps the annotation. To turn the rule off for a whole project, set `\"UNNECESSARY_MEASURES\": \"off\"` under `rules` in `pbiplint.config.json`.\n\n### Quirks\n\n- References from calculation items and from other hidden measures count as usage.\n- Report usage is not visible to this rule. A hidden measure used only by a visual is still flagged.\n- A row-level security filter counts as a DAX expression, so a measure named in one is used.\n- A measure named in a user-defined function counts as referenced, even when nothing calls the function, as Tabular Editor counts it. When the report is in the input, `NOT_REACHED_FROM_REPORT` follows the calls, so it reports a measure that only an uncalled function uses.\n- A bare `[Measure]` reference resolves by name across the whole model, ignoring letter case, so it counts wherever the measure lives. References are found by pattern, not by parsing, so a measure named inside a string or a comment counts as used too.\n- While a model file has a parse issue that can take a declaration out of the model, such as a line indented with spaces, or pbiplint could not open a model file or folder at all, the rule reports nothing, because the DAX that references the measure could be in what pbiplint missed, and pbiplint does not guess what a file it could not read says. The skipped line gives the reason, `a model file could not be fully read`, and the file's own `PARSE_ISSUE` finding names it, or a notice does for a file or folder pbiplint could not open.\n\nRead more: https://pbiplint.com/rules/unnecessary-measures"
   },
   "UNPIVOT_PIVOTED_(MONTH)_DATA": {
     text: `Example
@@ -12752,8 +13721,16 @@ Read more: https://pbiplint.com/rules/visual-without-fields`,
 };
 
 // src/walk.ts
-import { accessSync, constants, readdirSync as readdirSync2, readFileSync as readFileSync2, statSync } from "node:fs";
-import { basename, dirname as dirname3, join as join3, relative, resolve as resolve2 } from "node:path";
+import {
+  accessSync,
+  constants,
+  lstatSync,
+  readdirSync as readdirSync2,
+  readFileSync as readFileSync2,
+  realpathSync,
+  statSync
+} from "node:fs";
+import { basename, dirname as dirname3, isAbsolute, join as join3, relative, resolve as resolve2 } from "node:path";
 var EXPECTED_INPUT = "a PBIP folder, a .pbip file, a .SemanticModel folder, a .Report folder, a definition folder, or one .tmdl file";
 var SKIP_DIRS = /* @__PURE__ */ new Set([".git", ".pbi", "node_modules", "StaticResources", "CustomVisuals"]);
 var toPosix = (p) => p.split("\\").join("/");
@@ -12776,23 +13753,55 @@ function folderAt(p) {
     throw e;
   }
 }
-function unread(w, p, e) {
+function refusalOf(e) {
+  const reason = reasonOf(e);
+  return { reason, says: `could not be read (${reason})` };
+}
+var LINK = {
+  reason: "it is a symbolic link, which pbiplint does not follow",
+  says: "is a symbolic link, which pbiplint does not follow"
+};
+function unread(w, p, why, part, folder = false) {
   const path = toPosix(relative(w.base, p));
-  w.refusal ??= { path, error: e };
+  w.refusal ??= { path, reason: why.reason };
+  part?.unread.push(toPosix(relative(part.root, p)) + (folder ? "/" : ""));
   if (w.project.diagnostics.some((d) => d.kind === "unread-file" && d.path === path)) return;
   w.project.diagnostics.push({
     kind: "unread-file",
     path,
-    message: `${path} could not be read (${reasonOf(e)}), so it was not linted`
+    message: `${path} ${why.says}, so it was not linted`
   });
 }
+function isLink(p) {
+  try {
+    return lstatSync(p, { throwIfNoEntry: false })?.isSymbolicLink() ?? false;
+  } catch (e) {
+    if (isSystemError(e)) return false;
+    throw e;
+  }
+}
+function linked(w, p, part, folder = false) {
+  if (p === w.base || !isLink(p)) return false;
+  unread(w, p, LINK, part, folder);
+  return true;
+}
+function linkOnWay(w, to) {
+  const way = relative(w.base, to);
+  if (isAbsolute(way)) return isLink(to) ? to : void 0;
+  let at2 = w.base;
+  for (const segment of way.split(/[\\/]/)) {
+    at2 = join3(at2, segment);
+    if (segment !== "" && segment !== ".." && isLink(at2)) return at2;
+  }
+  return void 0;
+}
 function attempt(w, p, call, part, folder = false) {
+  if (linked(w, p, part, folder)) return void 0;
   try {
     return call();
   } catch (e) {
     if (!isSystemError(e)) throw e;
-    unread(w, p, e);
-    part?.unread.push(toPosix(relative(part.root, p)) + (folder ? "/" : ""));
+    unread(w, p, refusalOf(e), part, folder);
     return void 0;
   }
 }
@@ -12802,7 +13811,7 @@ function readTree(w, part, dir, keep, passed) {
     (a, b) => byName(a.name, b.name)
   )) {
     const p = join3(dir, entry.name);
-    if (entry.isDirectory()) {
+    if (entry.isSymbolicLink() ? folderAt(p) === true : entry.isDirectory()) {
       if (SKIP_DIRS.has(entry.name)) continue;
       if (passed && entry.name.endsWith(".SemanticModel"))
         passed.models.push(toPosix(relative(w.base, p)));
@@ -12815,14 +13824,14 @@ function readTree(w, part, dir, keep, passed) {
 }
 function modelPart(w, folder) {
   const def = join3(folder, "definition");
-  if (!isDir(def)) return void 0;
+  if (linked(w, def) || !isDir(def)) return void 0;
   const part = emptyPart(folder);
   readTree(w, part, def, (n2) => n2.endsWith(".tmdl"));
   return part.files.length ? part : void 0;
 }
 function reportPart(w, folder) {
   const def = join3(folder, "definition");
-  if (!isDir(def)) return void 0;
+  if (linked(w, def) || !isDir(def)) return void 0;
   const part = emptyPart(folder);
   for (const name of ["definition.pbir", ".platform"]) {
     const p = join3(folder, name);
@@ -12837,13 +13846,19 @@ var UNREAD_PART = {
   report: "the report folder could not be read"
 };
 function readPart(w, layer, folder, read) {
+  const via = linkOnWay(w, folder);
+  if (via !== void 0) {
+    unread(w, via, LINK);
+    if (layer) w.project.absent[layer] = UNREAD_PART[layer];
+    return void 0;
+  }
   let part;
   try {
     accessSync(folder, constants.X_OK);
     part = read(w, folder);
   } catch (e) {
     if (!isSystemError(e)) throw e;
-    unread(w, e.path ?? folder, e);
+    unread(w, e.path ?? folder, refusalOf(e));
   }
   const at2 = toPosix(relative(w.base, folder));
   const refused = w.project.diagnostics.some(
@@ -12854,7 +13869,9 @@ function readPart(w, layer, folder, read) {
 }
 function pbipIn(input, folder, preferred) {
   if (preferred !== void 0) return preferred;
-  const found = readdirSync2(folder, { withFileTypes: true }).filter((e) => e.isFile() && e.name.endsWith(".pbip")).map((e) => e.name).sort(byName);
+  const found = readdirSync2(folder, { withFileTypes: true }).filter(
+    (e) => e.name.endsWith(".pbip") && (e.isFile() || e.isSymbolicLink() && folderAt(join3(folder, e.name)) !== true)
+  ).map((e) => e.name).sort(byName);
   if (found.length > 1)
     throw new UsageError(
       `${input} contains ${found.length} .pbip files; point at one of them: ${found.join(", ")}`
@@ -12870,18 +13887,6 @@ function loneReportAbsent(report, folder) {
   );
   return !decision.useModel && decision.reason ? { model: decision.reason } : {};
 }
-var legacyReport = (folder, name) => ({
-  kind: "legacy-report-format",
-  path: name,
-  message: `${name} is stored as a single report.json, which pbiplint cannot read; save it in the PBIR format from Power BI Desktop`
-});
-var legacyModel = (folder, name) => ({
-  kind: "legacy-model-format",
-  path: name,
-  message: `${name} is stored as model.bim, which pbiplint cannot read; save it in the TMDL format from Power BI Desktop`
-});
-var LEGACY_REPORT_REASON = "the report is saved in the legacy report.json format";
-var LEGACY_MODEL_REASON = "the model is saved in the legacy model.bim format";
 function resolveProject(input) {
   const path = resolve2(input);
   try {
@@ -12899,7 +13904,8 @@ function resolveProject(input) {
           absent: {},
           diagnostics: []
         };
-      if (path.endsWith(".pbip")) return resolvePbip(input, path);
+      if (path.endsWith(".pbip"))
+        return resolvePbip(input, isLink(path) ? realpathSync(path) : path);
       if (isPbix(path)) throw new UsageError(pbixRefusal(input));
       throw new UsageError(`${input} is not a .tmdl file, a .pbip file, or a folder`);
     }
@@ -12916,9 +13922,9 @@ function walked(input, base, read) {
   const w = { base, project: { root: base, absent: {}, diagnostics: [] } };
   const project = read(w);
   if (!project.model && !project.report && w.refusal) {
-    const { path: below, error } = w.refusal;
+    const { path: below, reason } = w.refusal;
     const named2 = below === "" ? input : toPosix(join3(input, below));
-    throw new UsageError(`Could not read ${named2}: ${reasonOf(error)}`);
+    throw new UsageError(`Could not read ${named2}: ${reason}`);
   }
   return project;
 }
@@ -12953,7 +13959,9 @@ function resolvePbip(input, path) {
 function pbirOf(w, report, folder) {
   if (report) return report.files.find((f) => f.path === "definition.pbir")?.text;
   const at2 = toPosix(relative(w.base, folder));
-  if (w.project.diagnostics.some((d) => d.kind === "unread-file" && d.path === at2))
+  if (w.project.diagnostics.some(
+    (d) => d.kind === "unread-file" && (d.path === at2 || at2.startsWith(`${d.path}/`))
+  ))
     return void 0;
   const p = join3(folder, "definition.pbir");
   return attempt(w, p, () => isFile(p) ? readFileSync2(p, "utf8") : void 0);
@@ -12964,7 +13972,7 @@ function readNamed(w, input, pbip, text2, reportFolder, written) {
   const at2 = (p) => toPosix(relative(w.base, p));
   const report = readPart(w, "report", reportFolder, reportPart);
   if (!report && !out.absent.report && isFile(join3(reportFolder, "report.json"))) {
-    out.diagnostics.push(legacyReport(reportFolder, at2(reportFolder)));
+    out.diagnostics.push(legacyReportNotice(at2(reportFolder)));
     out.absent.report = LEGACY_REPORT_REASON;
   }
   if (report) report.files.push({ path: toPosix(relative(report.root, pbip)), text: text2 });
@@ -12978,9 +13986,13 @@ function readNamed(w, input, pbip, text2, reportFolder, written) {
     if (folderAt(modelFolder)) {
       model = readPart(w, "model", modelFolder, modelPart);
       if (!model && !out.absent.model && isFile(join3(modelFolder, "model.bim"))) {
-        out.diagnostics.push(legacyModel(modelFolder, at2(modelFolder)));
+        out.diagnostics.push(legacyModelNotice(at2(modelFolder)));
         out.absent.model = LEGACY_MODEL_REASON;
       }
+      if (!model && !out.absent.model) {
+        const { reason } = pairingDecision(ref, void 0, basename(reportFolder));
+        if (reason) out.absent.model = reason;
+      }
     } else {
       out.absent.model = `this report reads a model that is not there (${ref.path})`;
     }
@@ -12998,7 +14010,9 @@ function readNamed(w, input, pbip, text2, reportFolder, written) {
 function readFolder(w, input, path, preferred) {
   const out = w.project;
   const name = basename(path);
-  if (isDir(join3(path, "definition"))) {
+  const def = join3(path, "definition");
+  const namedPart = name.endsWith(".Report") || name.endsWith(".SemanticModel");
+  if (isDir(def) || namedPart && isLink(def)) {
     const model2 = readPart(
       w,
       name.endsWith(".SemanticModel") ? "model" : void 0,
@@ -13023,16 +14037,16 @@ function readFolder(w, input, path, preferred) {
       };
   }
   if (name.endsWith(".Report") && isFile(join3(path, "report.json"))) {
-    out.diagnostics.push(legacyReport(path, name));
+    out.diagnostics.push(legacyReportNotice(name));
     out.absent.report = LEGACY_REPORT_REASON;
     return out;
   }
   if (name.endsWith(".SemanticModel") && isFile(join3(path, "model.bim"))) {
-    out.diagnostics.push(legacyModel(path, name));
+    out.diagnostics.push(legacyModelNotice(name));
     out.absent.model = LEGACY_MODEL_REASON;
     return out;
   }
-  const dirs = readdirSync2(path, { withFileTypes: true }).filter((e) => e.isDirectory()).map((e) => e.name);
+  const dirs = readdirSync2(path, { withFileTypes: true }).filter((e) => e.isDirectory() || e.isSymbolicLink() && folderAt(join3(path, e.name)) === true).map((e) => e.name);
   const models = dirs.filter((d) => d.endsWith(".SemanticModel")).sort(byName);
   const reports = dirs.filter((d) => d.endsWith(".Report")).sort(byName);
   if (models.length > 1)
@@ -13045,12 +14059,12 @@ function readFolder(w, input, path, preferred) {
     );
   let model = models[0] ? readPart(w, "model", join3(path, models[0]), modelPart) : void 0;
   if (models[0] && !model && !out.absent.model && isFile(join3(path, models[0], "model.bim"))) {
-    out.diagnostics.push(legacyModel(path, models[0]));
+    out.diagnostics.push(legacyModelNotice(models[0]));
     out.absent.model = LEGACY_MODEL_REASON;
   }
   const report = reports[0] ? readPart(w, "report", join3(path, reports[0]), reportPart) : void 0;
   if (reports[0] && !report && !out.absent.report && isFile(join3(path, reports[0], "report.json"))) {
-    out.diagnostics.push(legacyReport(path, reports[0]));
+    out.diagnostics.push(legacyReportNotice(reports[0]));
     out.absent.report = LEGACY_REPORT_REASON;
   }
   if (report) {
@@ -13061,14 +14075,12 @@ function readFolder(w, input, path, preferred) {
       if (text2 !== void 0) report.files.push({ path: toPosix(relative(report.root, p)), text: text2 });
     }
     const pbir = report.files.find((f) => f.path === "definition.pbir");
-    const decision = pairingDecision(
-      pbir ? datasetReference(pbir.text) : { kind: "none" },
-      model ? models[0] : void 0,
-      reports[0]
-    );
+    const ref = pbir ? datasetReference(pbir.text) : { kind: "none" };
+    const decision = pairingDecision(ref, model ? models[0] : void 0, reports[0]);
     if (!decision.useModel) {
       model = void 0;
-      if (decision.reason) out.absent.model = decision.reason;
+      if (decision.reason && (ref.kind === "byConnection" || !out.absent.model))
+        out.absent.model = decision.reason;
     }
     if (decision.diagnostic) out.diagnostics.push(decision.diagnostic);
   }
@@ -13094,7 +14106,7 @@ function readFolder(w, input, path, preferred) {
 }
 
 // src/main.ts
-var VERSION2 = true ? "0.2.0" : "0.0.0-dev";
+var VERSION2 = true ? "0.2.1" : "0.0.0-dev";
 function listRules() {
   const width = Math.max(...defaultRules.map((r) => r.id.length));
   return defaultRules.map(