@okf/ootils 1.46.0 → 1.47.0

package/dist/browser.d.mts

@@ -2005,8 +2005,39 @@ declare class BlockRegistry {
         comp: string;
         props?: any;
     }): boolean;
-    /** Check if a specific block has a specific capability. */
-    hasCapability(compType: string, capability: keyof BlockCapabilities): boolean;
+    /**
+     * Check if a specific block has a specific capability.
+     *
+     * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+     * optional third arg to honour per-instance overrides — today the only one is
+     * the annotation kill-switch: an annotation-capable block type returns `false`
+     * for the `annotation` capability when the instance sets
+     * `props.annotations.disable: true` in its tpl config. All other capabilities
+     * (and the no-instance form) fall through to the plain type-level check, so
+     * existing 2-arg callers are unaffected.
+     */
+    hasCapability(compType: string, capability: keyof BlockCapabilities, block?: {
+        props?: any;
+    }): boolean;
+    /**
+     * Per-instance annotation kill-switch.
+     *
+     * A block type may be annotation-capable at the registry level (e.g.
+     * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+     * block instance can be opted out of annotation entirely by setting
+     * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+     * to stop annotation on any field, add that prop — no code change.
+     *
+     * The single home for this `props.annotations.disable` path (note: `annotations`
+     * plural, distinct from the legacy singular `annotation.enable`). Consumed
+     * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+     * by consumers that must actively suppress annotation UI (e.g. the FE block
+     * generators forcing disableViewHighlights/disableCreateHighlights), where a
+     * type-level `false` isn't enough on its own.
+     */
+    isAnnotationDisabledForBlock(block: {
+        props?: any;
+    }): boolean;
     /**
      * Returns true if the block stores its value as an array (Mongo schema type is Array).
      * Useful for callers that need to know whether to query `valuePath.0` for existence
@@ -2028,7 +2059,15 @@ declare class BlockRegistry {
      * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
      * falls back to the legacy per-instance `props.annotation.enable` toggle.
      *
-     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+     * Per-instance kill-switch: any block is excluded when its tpl config sets
+     * `props.annotations.disable: true`, regardless of type-level capability. This
+     * is the single, config-only way to turn off annotation for a specific field —
+     * and because this method is the central gate used across every repo, the
+     * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+     * chunking/anno sync, filters).
+     *
+     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+     * auto-enabled unless explicitly disabled on the instance.
      */
     getAnnotationEnabledBlocks(allBlocks: Array<{
         comp: string;

package/dist/browser.d.ts

@@ -2005,8 +2005,39 @@ declare class BlockRegistry {
         comp: string;
         props?: any;
     }): boolean;
-    /** Check if a specific block has a specific capability. */
-    hasCapability(compType: string, capability: keyof BlockCapabilities): boolean;
+    /**
+     * Check if a specific block has a specific capability.
+     *
+     * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+     * optional third arg to honour per-instance overrides — today the only one is
+     * the annotation kill-switch: an annotation-capable block type returns `false`
+     * for the `annotation` capability when the instance sets
+     * `props.annotations.disable: true` in its tpl config. All other capabilities
+     * (and the no-instance form) fall through to the plain type-level check, so
+     * existing 2-arg callers are unaffected.
+     */
+    hasCapability(compType: string, capability: keyof BlockCapabilities, block?: {
+        props?: any;
+    }): boolean;
+    /**
+     * Per-instance annotation kill-switch.
+     *
+     * A block type may be annotation-capable at the registry level (e.g.
+     * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+     * block instance can be opted out of annotation entirely by setting
+     * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+     * to stop annotation on any field, add that prop — no code change.
+     *
+     * The single home for this `props.annotations.disable` path (note: `annotations`
+     * plural, distinct from the legacy singular `annotation.enable`). Consumed
+     * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+     * by consumers that must actively suppress annotation UI (e.g. the FE block
+     * generators forcing disableViewHighlights/disableCreateHighlights), where a
+     * type-level `false` isn't enough on its own.
+     */
+    isAnnotationDisabledForBlock(block: {
+        props?: any;
+    }): boolean;
     /**
      * Returns true if the block stores its value as an array (Mongo schema type is Array).
      * Useful for callers that need to know whether to query `valuePath.0` for existence
@@ -2028,7 +2059,15 @@ declare class BlockRegistry {
      * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
      * falls back to the legacy per-instance `props.annotation.enable` toggle.
      *
-     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+     * Per-instance kill-switch: any block is excluded when its tpl config sets
+     * `props.annotations.disable: true`, regardless of type-level capability. This
+     * is the single, config-only way to turn off annotation for a specific field —
+     * and because this method is the central gate used across every repo, the
+     * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+     * chunking/anno sync, filters).
+     *
+     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+     * auto-enabled unless explicitly disabled on the instance.
      */
     getAnnotationEnabledBlocks(allBlocks: Array<{
         comp: string;

package/dist/browser.js

@@ -625,11 +625,44 @@ var BlockRegistry = class {
       return value === cond.equals;
     });
   }
-  /** Check if a specific block has a specific capability. */
-  hasCapability(compType, capability) {
-    const block = this.blocks.get(compType);
-    if (!block) return false;
-    return !!block.capabilities[capability];
+  /**
+   * Check if a specific block has a specific capability.
+   *
+   * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+   * optional third arg to honour per-instance overrides — today the only one is
+   * the annotation kill-switch: an annotation-capable block type returns `false`
+   * for the `annotation` capability when the instance sets
+   * `props.annotations.disable: true` in its tpl config. All other capabilities
+   * (and the no-instance form) fall through to the plain type-level check, so
+   * existing 2-arg callers are unaffected.
+   */
+  hasCapability(compType, capability, block) {
+    const def = this.blocks.get(compType);
+    if (!def) return false;
+    if (!def.capabilities[capability]) return false;
+    if (capability === "annotation" && block && this.isAnnotationDisabledForBlock(block)) {
+      return false;
+    }
+    return true;
+  }
+  /**
+   * Per-instance annotation kill-switch.
+   *
+   * A block type may be annotation-capable at the registry level (e.g.
+   * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+   * block instance can be opted out of annotation entirely by setting
+   * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+   * to stop annotation on any field, add that prop — no code change.
+   *
+   * The single home for this `props.annotations.disable` path (note: `annotations`
+   * plural, distinct from the legacy singular `annotation.enable`). Consumed
+   * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+   * by consumers that must actively suppress annotation UI (e.g. the FE block
+   * generators forcing disableViewHighlights/disableCreateHighlights), where a
+   * type-level `false` isn't enough on its own.
+   */
+  isAnnotationDisabledForBlock(block) {
+    return block?.props?.annotations?.disable === true;
   }
   /**
    * Returns true if the block stores its value as an array (Mongo schema type is Array).
@@ -659,10 +692,19 @@ var BlockRegistry = class {
    * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
    * falls back to the legacy per-instance `props.annotation.enable` toggle.
    *
-   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+   * Per-instance kill-switch: any block is excluded when its tpl config sets
+   * `props.annotations.disable: true`, regardless of type-level capability. This
+   * is the single, config-only way to turn off annotation for a specific field —
+   * and because this method is the central gate used across every repo, the
+   * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+   * chunking/anno sync, filters).
+   *
+   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+   * auto-enabled unless explicitly disabled on the instance.
    */
   getAnnotationEnabledBlocks(allBlocks) {
     return allBlocks.filter((block) => {
+      if (this.isAnnotationDisabledForBlock(block)) return false;
       const blockDef = this.blocks.get(block.comp);
       if (blockDef) return !!blockDef.capabilities.annotation;
       return block.props?.annotation?.enable === true;

package/dist/browser.mjs

@@ -553,11 +553,44 @@ var BlockRegistry = class {
       return value === cond.equals;
     });
   }
-  /** Check if a specific block has a specific capability. */
-  hasCapability(compType, capability) {
-    const block = this.blocks.get(compType);
-    if (!block) return false;
-    return !!block.capabilities[capability];
+  /**
+   * Check if a specific block has a specific capability.
+   *
+   * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+   * optional third arg to honour per-instance overrides — today the only one is
+   * the annotation kill-switch: an annotation-capable block type returns `false`
+   * for the `annotation` capability when the instance sets
+   * `props.annotations.disable: true` in its tpl config. All other capabilities
+   * (and the no-instance form) fall through to the plain type-level check, so
+   * existing 2-arg callers are unaffected.
+   */
+  hasCapability(compType, capability, block) {
+    const def = this.blocks.get(compType);
+    if (!def) return false;
+    if (!def.capabilities[capability]) return false;
+    if (capability === "annotation" && block && this.isAnnotationDisabledForBlock(block)) {
+      return false;
+    }
+    return true;
+  }
+  /**
+   * Per-instance annotation kill-switch.
+   *
+   * A block type may be annotation-capable at the registry level (e.g.
+   * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+   * block instance can be opted out of annotation entirely by setting
+   * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+   * to stop annotation on any field, add that prop — no code change.
+   *
+   * The single home for this `props.annotations.disable` path (note: `annotations`
+   * plural, distinct from the legacy singular `annotation.enable`). Consumed
+   * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+   * by consumers that must actively suppress annotation UI (e.g. the FE block
+   * generators forcing disableViewHighlights/disableCreateHighlights), where a
+   * type-level `false` isn't enough on its own.
+   */
+  isAnnotationDisabledForBlock(block) {
+    return block?.props?.annotations?.disable === true;
   }
   /**
    * Returns true if the block stores its value as an array (Mongo schema type is Array).
@@ -587,10 +620,19 @@ var BlockRegistry = class {
    * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
    * falls back to the legacy per-instance `props.annotation.enable` toggle.
    *
-   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+   * Per-instance kill-switch: any block is excluded when its tpl config sets
+   * `props.annotations.disable: true`, regardless of type-level capability. This
+   * is the single, config-only way to turn off annotation for a specific field —
+   * and because this method is the central gate used across every repo, the
+   * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+   * chunking/anno sync, filters).
+   *
+   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+   * auto-enabled unless explicitly disabled on the instance.
    */
   getAnnotationEnabledBlocks(allBlocks) {
     return allBlocks.filter((block) => {
+      if (this.isAnnotationDisabledForBlock(block)) return false;
       const blockDef = this.blocks.get(block.comp);
       if (blockDef) return !!blockDef.capabilities.annotation;
       return block.props?.annotation?.enable === true;

package/dist/node.d.mts

@@ -2013,8 +2013,39 @@ declare class BlockRegistry {
         comp: string;
         props?: any;
     }): boolean;
-    /** Check if a specific block has a specific capability. */
-    hasCapability(compType: string, capability: keyof BlockCapabilities): boolean;
+    /**
+     * Check if a specific block has a specific capability.
+     *
+     * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+     * optional third arg to honour per-instance overrides — today the only one is
+     * the annotation kill-switch: an annotation-capable block type returns `false`
+     * for the `annotation` capability when the instance sets
+     * `props.annotations.disable: true` in its tpl config. All other capabilities
+     * (and the no-instance form) fall through to the plain type-level check, so
+     * existing 2-arg callers are unaffected.
+     */
+    hasCapability(compType: string, capability: keyof BlockCapabilities, block?: {
+        props?: any;
+    }): boolean;
+    /**
+     * Per-instance annotation kill-switch.
+     *
+     * A block type may be annotation-capable at the registry level (e.g.
+     * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+     * block instance can be opted out of annotation entirely by setting
+     * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+     * to stop annotation on any field, add that prop — no code change.
+     *
+     * The single home for this `props.annotations.disable` path (note: `annotations`
+     * plural, distinct from the legacy singular `annotation.enable`). Consumed
+     * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+     * by consumers that must actively suppress annotation UI (e.g. the FE block
+     * generators forcing disableViewHighlights/disableCreateHighlights), where a
+     * type-level `false` isn't enough on its own.
+     */
+    isAnnotationDisabledForBlock(block: {
+        props?: any;
+    }): boolean;
     /**
      * Returns true if the block stores its value as an array (Mongo schema type is Array).
      * Useful for callers that need to know whether to query `valuePath.0` for existence
@@ -2036,7 +2067,15 @@ declare class BlockRegistry {
      * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
      * falls back to the legacy per-instance `props.annotation.enable` toggle.
      *
-     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+     * Per-instance kill-switch: any block is excluded when its tpl config sets
+     * `props.annotations.disable: true`, regardless of type-level capability. This
+     * is the single, config-only way to turn off annotation for a specific field —
+     * and because this method is the central gate used across every repo, the
+     * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+     * chunking/anno sync, filters).
+     *
+     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+     * auto-enabled unless explicitly disabled on the instance.
      */
     getAnnotationEnabledBlocks(allBlocks: Array<{
         comp: string;

package/dist/node.d.ts

@@ -2013,8 +2013,39 @@ declare class BlockRegistry {
         comp: string;
         props?: any;
     }): boolean;
-    /** Check if a specific block has a specific capability. */
-    hasCapability(compType: string, capability: keyof BlockCapabilities): boolean;
+    /**
+     * Check if a specific block has a specific capability.
+     *
+     * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+     * optional third arg to honour per-instance overrides — today the only one is
+     * the annotation kill-switch: an annotation-capable block type returns `false`
+     * for the `annotation` capability when the instance sets
+     * `props.annotations.disable: true` in its tpl config. All other capabilities
+     * (and the no-instance form) fall through to the plain type-level check, so
+     * existing 2-arg callers are unaffected.
+     */
+    hasCapability(compType: string, capability: keyof BlockCapabilities, block?: {
+        props?: any;
+    }): boolean;
+    /**
+     * Per-instance annotation kill-switch.
+     *
+     * A block type may be annotation-capable at the registry level (e.g.
+     * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+     * block instance can be opted out of annotation entirely by setting
+     * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+     * to stop annotation on any field, add that prop — no code change.
+     *
+     * The single home for this `props.annotations.disable` path (note: `annotations`
+     * plural, distinct from the legacy singular `annotation.enable`). Consumed
+     * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+     * by consumers that must actively suppress annotation UI (e.g. the FE block
+     * generators forcing disableViewHighlights/disableCreateHighlights), where a
+     * type-level `false` isn't enough on its own.
+     */
+    isAnnotationDisabledForBlock(block: {
+        props?: any;
+    }): boolean;
     /**
      * Returns true if the block stores its value as an array (Mongo schema type is Array).
      * Useful for callers that need to know whether to query `valuePath.0` for existence
@@ -2036,7 +2067,15 @@ declare class BlockRegistry {
      * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
      * falls back to the legacy per-instance `props.annotation.enable` toggle.
      *
-     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+     * Per-instance kill-switch: any block is excluded when its tpl config sets
+     * `props.annotations.disable: true`, regardless of type-level capability. This
+     * is the single, config-only way to turn off annotation for a specific field —
+     * and because this method is the central gate used across every repo, the
+     * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+     * chunking/anno sync, filters).
+     *
+     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+     * auto-enabled unless explicitly disabled on the instance.
      */
     getAnnotationEnabledBlocks(allBlocks: Array<{
         comp: string;

package/dist/node.js

@@ -3063,11 +3063,44 @@ var BlockRegistry = class {
       return value === cond.equals;
     });
   }
-  /** Check if a specific block has a specific capability. */
-  hasCapability(compType, capability) {
-    const block = this.blocks.get(compType);
-    if (!block) return false;
-    return !!block.capabilities[capability];
+  /**
+   * Check if a specific block has a specific capability.
+   *
+   * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+   * optional third arg to honour per-instance overrides — today the only one is
+   * the annotation kill-switch: an annotation-capable block type returns `false`
+   * for the `annotation` capability when the instance sets
+   * `props.annotations.disable: true` in its tpl config. All other capabilities
+   * (and the no-instance form) fall through to the plain type-level check, so
+   * existing 2-arg callers are unaffected.
+   */
+  hasCapability(compType, capability, block) {
+    const def = this.blocks.get(compType);
+    if (!def) return false;
+    if (!def.capabilities[capability]) return false;
+    if (capability === "annotation" && block && this.isAnnotationDisabledForBlock(block)) {
+      return false;
+    }
+    return true;
+  }
+  /**
+   * Per-instance annotation kill-switch.
+   *
+   * A block type may be annotation-capable at the registry level (e.g.
+   * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+   * block instance can be opted out of annotation entirely by setting
+   * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+   * to stop annotation on any field, add that prop — no code change.
+   *
+   * The single home for this `props.annotations.disable` path (note: `annotations`
+   * plural, distinct from the legacy singular `annotation.enable`). Consumed
+   * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+   * by consumers that must actively suppress annotation UI (e.g. the FE block
+   * generators forcing disableViewHighlights/disableCreateHighlights), where a
+   * type-level `false` isn't enough on its own.
+   */
+  isAnnotationDisabledForBlock(block) {
+    return block?.props?.annotations?.disable === true;
   }
   /**
    * Returns true if the block stores its value as an array (Mongo schema type is Array).
@@ -3097,10 +3130,19 @@ var BlockRegistry = class {
    * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
    * falls back to the legacy per-instance `props.annotation.enable` toggle.
    *
-   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+   * Per-instance kill-switch: any block is excluded when its tpl config sets
+   * `props.annotations.disable: true`, regardless of type-level capability. This
+   * is the single, config-only way to turn off annotation for a specific field —
+   * and because this method is the central gate used across every repo, the
+   * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+   * chunking/anno sync, filters).
+   *
+   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+   * auto-enabled unless explicitly disabled on the instance.
    */
   getAnnotationEnabledBlocks(allBlocks) {
     return allBlocks.filter((block) => {
+      if (this.isAnnotationDisabledForBlock(block)) return false;
       const blockDef = this.blocks.get(block.comp);
       if (blockDef) return !!blockDef.capabilities.annotation;
       return block.props?.annotation?.enable === true;

package/dist/node.mjs

@@ -2971,11 +2971,44 @@ var BlockRegistry = class {
       return value === cond.equals;
     });
   }
-  /** Check if a specific block has a specific capability. */
-  hasCapability(compType, capability) {
-    const block = this.blocks.get(compType);
-    if (!block) return false;
-    return !!block.capabilities[capability];
+  /**
+   * Check if a specific block has a specific capability.
+   *
+   * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+   * optional third arg to honour per-instance overrides — today the only one is
+   * the annotation kill-switch: an annotation-capable block type returns `false`
+   * for the `annotation` capability when the instance sets
+   * `props.annotations.disable: true` in its tpl config. All other capabilities
+   * (and the no-instance form) fall through to the plain type-level check, so
+   * existing 2-arg callers are unaffected.
+   */
+  hasCapability(compType, capability, block) {
+    const def = this.blocks.get(compType);
+    if (!def) return false;
+    if (!def.capabilities[capability]) return false;
+    if (capability === "annotation" && block && this.isAnnotationDisabledForBlock(block)) {
+      return false;
+    }
+    return true;
+  }
+  /**
+   * Per-instance annotation kill-switch.
+   *
+   * A block type may be annotation-capable at the registry level (e.g.
+   * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+   * block instance can be opted out of annotation entirely by setting
+   * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+   * to stop annotation on any field, add that prop — no code change.
+   *
+   * The single home for this `props.annotations.disable` path (note: `annotations`
+   * plural, distinct from the legacy singular `annotation.enable`). Consumed
+   * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+   * by consumers that must actively suppress annotation UI (e.g. the FE block
+   * generators forcing disableViewHighlights/disableCreateHighlights), where a
+   * type-level `false` isn't enough on its own.
+   */
+  isAnnotationDisabledForBlock(block) {
+    return block?.props?.annotations?.disable === true;
   }
   /**
    * Returns true if the block stores its value as an array (Mongo schema type is Array).
@@ -3005,10 +3038,19 @@ var BlockRegistry = class {
    * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
    * falls back to the legacy per-instance `props.annotation.enable` toggle.
    *
-   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+   * Per-instance kill-switch: any block is excluded when its tpl config sets
+   * `props.annotations.disable: true`, regardless of type-level capability. This
+   * is the single, config-only way to turn off annotation for a specific field —
+   * and because this method is the central gate used across every repo, the
+   * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+   * chunking/anno sync, filters).
+   *
+   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+   * auto-enabled unless explicitly disabled on the instance.
    */
   getAnnotationEnabledBlocks(allBlocks) {
     return allBlocks.filter((block) => {
+      if (this.isAnnotationDisabledForBlock(block)) return false;
       const blockDef = this.blocks.get(block.comp);
       if (blockDef) return !!blockDef.capabilities.annotation;
       return block.props?.annotation?.enable === true;

package/dist/universal.d.mts

@@ -2005,8 +2005,39 @@ declare class BlockRegistry {
         comp: string;
         props?: any;
     }): boolean;
-    /** Check if a specific block has a specific capability. */
-    hasCapability(compType: string, capability: keyof BlockCapabilities): boolean;
+    /**
+     * Check if a specific block has a specific capability.
+     *
+     * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+     * optional third arg to honour per-instance overrides — today the only one is
+     * the annotation kill-switch: an annotation-capable block type returns `false`
+     * for the `annotation` capability when the instance sets
+     * `props.annotations.disable: true` in its tpl config. All other capabilities
+     * (and the no-instance form) fall through to the plain type-level check, so
+     * existing 2-arg callers are unaffected.
+     */
+    hasCapability(compType: string, capability: keyof BlockCapabilities, block?: {
+        props?: any;
+    }): boolean;
+    /**
+     * Per-instance annotation kill-switch.
+     *
+     * A block type may be annotation-capable at the registry level (e.g.
+     * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+     * block instance can be opted out of annotation entirely by setting
+     * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+     * to stop annotation on any field, add that prop — no code change.
+     *
+     * The single home for this `props.annotations.disable` path (note: `annotations`
+     * plural, distinct from the legacy singular `annotation.enable`). Consumed
+     * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+     * by consumers that must actively suppress annotation UI (e.g. the FE block
+     * generators forcing disableViewHighlights/disableCreateHighlights), where a
+     * type-level `false` isn't enough on its own.
+     */
+    isAnnotationDisabledForBlock(block: {
+        props?: any;
+    }): boolean;
     /**
      * Returns true if the block stores its value as an array (Mongo schema type is Array).
      * Useful for callers that need to know whether to query `valuePath.0` for existence
@@ -2028,7 +2059,15 @@ declare class BlockRegistry {
      * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
      * falls back to the legacy per-instance `props.annotation.enable` toggle.
      *
-     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+     * Per-instance kill-switch: any block is excluded when its tpl config sets
+     * `props.annotations.disable: true`, regardless of type-level capability. This
+     * is the single, config-only way to turn off annotation for a specific field —
+     * and because this method is the central gate used across every repo, the
+     * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+     * chunking/anno sync, filters).
+     *
+     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+     * auto-enabled unless explicitly disabled on the instance.
      */
     getAnnotationEnabledBlocks(allBlocks: Array<{
         comp: string;

package/dist/universal.d.ts

@@ -2005,8 +2005,39 @@ declare class BlockRegistry {
         comp: string;
         props?: any;
     }): boolean;
-    /** Check if a specific block has a specific capability. */
-    hasCapability(compType: string, capability: keyof BlockCapabilities): boolean;
+    /**
+     * Check if a specific block has a specific capability.
+     *
+     * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+     * optional third arg to honour per-instance overrides — today the only one is
+     * the annotation kill-switch: an annotation-capable block type returns `false`
+     * for the `annotation` capability when the instance sets
+     * `props.annotations.disable: true` in its tpl config. All other capabilities
+     * (and the no-instance form) fall through to the plain type-level check, so
+     * existing 2-arg callers are unaffected.
+     */
+    hasCapability(compType: string, capability: keyof BlockCapabilities, block?: {
+        props?: any;
+    }): boolean;
+    /**
+     * Per-instance annotation kill-switch.
+     *
+     * A block type may be annotation-capable at the registry level (e.g.
+     * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+     * block instance can be opted out of annotation entirely by setting
+     * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+     * to stop annotation on any field, add that prop — no code change.
+     *
+     * The single home for this `props.annotations.disable` path (note: `annotations`
+     * plural, distinct from the legacy singular `annotation.enable`). Consumed
+     * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+     * by consumers that must actively suppress annotation UI (e.g. the FE block
+     * generators forcing disableViewHighlights/disableCreateHighlights), where a
+     * type-level `false` isn't enough on its own.
+     */
+    isAnnotationDisabledForBlock(block: {
+        props?: any;
+    }): boolean;
     /**
      * Returns true if the block stores its value as an array (Mongo schema type is Array).
      * Useful for callers that need to know whether to query `valuePath.0` for existence
@@ -2028,7 +2059,15 @@ declare class BlockRegistry {
      * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
      * falls back to the legacy per-instance `props.annotation.enable` toggle.
      *
-     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+     * Per-instance kill-switch: any block is excluded when its tpl config sets
+     * `props.annotations.disable: true`, regardless of type-level capability. This
+     * is the single, config-only way to turn off annotation for a specific field —
+     * and because this method is the central gate used across every repo, the
+     * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+     * chunking/anno sync, filters).
+     *
+     * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+     * auto-enabled unless explicitly disabled on the instance.
      */
     getAnnotationEnabledBlocks(allBlocks: Array<{
         comp: string;

package/dist/universal.js

@@ -625,11 +625,44 @@ var BlockRegistry = class {
       return value === cond.equals;
     });
   }
-  /** Check if a specific block has a specific capability. */
-  hasCapability(compType, capability) {
-    const block = this.blocks.get(compType);
-    if (!block) return false;
-    return !!block.capabilities[capability];
+  /**
+   * Check if a specific block has a specific capability.
+   *
+   * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+   * optional third arg to honour per-instance overrides — today the only one is
+   * the annotation kill-switch: an annotation-capable block type returns `false`
+   * for the `annotation` capability when the instance sets
+   * `props.annotations.disable: true` in its tpl config. All other capabilities
+   * (and the no-instance form) fall through to the plain type-level check, so
+   * existing 2-arg callers are unaffected.
+   */
+  hasCapability(compType, capability, block) {
+    const def = this.blocks.get(compType);
+    if (!def) return false;
+    if (!def.capabilities[capability]) return false;
+    if (capability === "annotation" && block && this.isAnnotationDisabledForBlock(block)) {
+      return false;
+    }
+    return true;
+  }
+  /**
+   * Per-instance annotation kill-switch.
+   *
+   * A block type may be annotation-capable at the registry level (e.g.
+   * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+   * block instance can be opted out of annotation entirely by setting
+   * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+   * to stop annotation on any field, add that prop — no code change.
+   *
+   * The single home for this `props.annotations.disable` path (note: `annotations`
+   * plural, distinct from the legacy singular `annotation.enable`). Consumed
+   * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+   * by consumers that must actively suppress annotation UI (e.g. the FE block
+   * generators forcing disableViewHighlights/disableCreateHighlights), where a
+   * type-level `false` isn't enough on its own.
+   */
+  isAnnotationDisabledForBlock(block) {
+    return block?.props?.annotations?.disable === true;
   }
   /**
    * Returns true if the block stores its value as an array (Mongo schema type is Array).
@@ -659,10 +692,19 @@ var BlockRegistry = class {
    * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
    * falls back to the legacy per-instance `props.annotation.enable` toggle.
    *
-   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+   * Per-instance kill-switch: any block is excluded when its tpl config sets
+   * `props.annotations.disable: true`, regardless of type-level capability. This
+   * is the single, config-only way to turn off annotation for a specific field —
+   * and because this method is the central gate used across every repo, the
+   * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+   * chunking/anno sync, filters).
+   *
+   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+   * auto-enabled unless explicitly disabled on the instance.
    */
   getAnnotationEnabledBlocks(allBlocks) {
     return allBlocks.filter((block) => {
+      if (this.isAnnotationDisabledForBlock(block)) return false;
       const blockDef = this.blocks.get(block.comp);
       if (blockDef) return !!blockDef.capabilities.annotation;
       return block.props?.annotation?.enable === true;

package/dist/universal.mjs

@@ -553,11 +553,44 @@ var BlockRegistry = class {
       return value === cond.equals;
     });
   }
-  /** Check if a specific block has a specific capability. */
-  hasCapability(compType, capability) {
-    const block = this.blocks.get(compType);
-    if (!block) return false;
-    return !!block.capabilities[capability];
+  /**
+   * Check if a specific block has a specific capability.
+   *
+   * Type-level by default (keyed off `compType`). Pass the block INSTANCE as the
+   * optional third arg to honour per-instance overrides — today the only one is
+   * the annotation kill-switch: an annotation-capable block type returns `false`
+   * for the `annotation` capability when the instance sets
+   * `props.annotations.disable: true` in its tpl config. All other capabilities
+   * (and the no-instance form) fall through to the plain type-level check, so
+   * existing 2-arg callers are unaffected.
+   */
+  hasCapability(compType, capability, block) {
+    const def = this.blocks.get(compType);
+    if (!def) return false;
+    if (!def.capabilities[capability]) return false;
+    if (capability === "annotation" && block && this.isAnnotationDisabledForBlock(block)) {
+      return false;
+    }
+    return true;
+  }
+  /**
+   * Per-instance annotation kill-switch.
+   *
+   * A block type may be annotation-capable at the registry level (e.g.
+   * LexicalTextEditor has `capabilities.annotation === true`), but an individual
+   * block instance can be opted out of annotation entirely by setting
+   * `props.annotations.disable: true` in its tpl config. Generic and config-only:
+   * to stop annotation on any field, add that prop — no code change.
+   *
+   * The single home for this `props.annotations.disable` path (note: `annotations`
+   * plural, distinct from the legacy singular `annotation.enable`). Consumed
+   * internally by `hasCapability` and `getAnnotationEnabledBlocks`, and directly
+   * by consumers that must actively suppress annotation UI (e.g. the FE block
+   * generators forcing disableViewHighlights/disableCreateHighlights), where a
+   * type-level `false` isn't enough on its own.
+   */
+  isAnnotationDisabledForBlock(block) {
+    return block?.props?.annotations?.disable === true;
   }
   /**
    * Returns true if the block stores its value as an array (Mongo schema type is Array).
@@ -587,10 +620,19 @@ var BlockRegistry = class {
    * For backwards compat with un-migrated blocks (e.g. deprecated KPRichInput/RichTextEditor),
    * falls back to the legacy per-instance `props.annotation.enable` toggle.
    *
-   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is auto-enabled.
+   * Per-instance kill-switch: any block is excluded when its tpl config sets
+   * `props.annotations.disable: true`, regardless of type-level capability. This
+   * is the single, config-only way to turn off annotation for a specific field —
+   * and because this method is the central gate used across every repo, the
+   * switch applies everywhere (annotate UI, AI auto-annotation, explorer,
+   * chunking/anno sync, filters).
+   *
+   * Today: every registered annotation-capable block (e.g. LexicalTextEditor) is
+   * auto-enabled unless explicitly disabled on the instance.
    */
   getAnnotationEnabledBlocks(allBlocks) {
     return allBlocks.filter((block) => {
+      if (this.isAnnotationDisabledForBlock(block)) return false;
       const blockDef = this.blocks.get(block.comp);
       if (blockDef) return !!blockDef.capabilities.annotation;
       return block.props?.annotation?.enable === true;

package/package.json

@@ -3,7 +3,7 @@
   "publishConfig": {
     "access": "public"
   },
-  "version": "1.46.0",
+  "version": "1.47.0",
   "description": "Utility functions for both browser and Node.js",
   "main": "dist/index.js",
   "module": "dist/index.mjs",