platformos-check 0.4.11 → 0.4.13

data/docs/checks/translation_key_exists.md

@@ -1,39 +1,38 @@
 # Translation Key Exists (`TranslationKeyExists`)
 
-Checks if translation key is defined in the default language
+This check ensures that translation keys are defined in the default language, aiming to prevent missing translation errors.
 
-## Check Details
+## Examples
 
-This check is aimed at avoiding missing translation error.
+The following examples show code snippets that either fail or pass this check:
 
-:-1: Examples of **incorrect** code for this check:
+### ✗ Incorrect Code Example (Avoid using this):
 
 ```liquid
 {{ 'undefined.key' | t }}
 ```
 
-:+1: Examples of **correct** code for this check:
+### ✓ Correct Code Example (Use this instead):
 
 ```liquid
 {{ 'defined.key' | t }}
 
-## Check Options
+## Configuration Options
 
-The default configuration for this check is the following:
+The default configuration for this check:
 
 ```yaml
 TranslationKeyExists:
   enabled: true
 ```
 
-## When Not To Use It
+## Disabling This Check
 
-There should be no cases where disabling this rule is needed. For keys that are set via UI, and hence should not be part of the codebase,
-use proper configuration option in [app/config.yml](https://documentation.platformos.com/developer-guide/platformos-workflow/codebase/config)
+There should be no need to disable this rule. For keys set via the UI and not intended to be part of the codebase, use the appropriate configuration option in [app/config.yml](https://documentation.platformos.com/developer-guide/platformos-workflow/codebase/config).
 
 ## Version
 
-This check has been introduced in PlatformOS Check 0.4.10.
+This check has been introduced in platformOS Check 0.4.10.
 
 ## Resources
 

data/docs/checks/undefined_object.md

@@ -1,12 +1,12 @@
-# Prevent undefined object errors (`UndefinedObject`)
+# Prevent Undefined Object Errors (`UndefinedObject`)
 
-This check prevents errors by making sure that no undefined variables are being used
+This check ensures that no undefined variables are used, preventing errors in your Liquid code. It aims to eliminate undefined object errors and additionally reports any missing or unused attributes in `render`, `function`, and `background` tags.
 
-## Check Details
+## Examples
 
-This check is aimed at eliminating undefined object errors. Additionally it reports any missing or unused attributes in render, function and background tags.
+The following examples show code snippets that either fail or pass this check:
 
-:-1: Examples of **incorrect** code for this check:
+### ✗ Incorrect Code Example (Avoid using this):
 
 ```liquid
 {% if greeting == "Hello" %}
@@ -14,7 +14,7 @@ This check is aimed at eliminating undefined object errors. Additionally it repo
 {% endif %}
 ```
 
-:+1: Examples of **correct** code for this check:
+### ✓ Correct Code Example (Use this instead):
 
 ```liquid
 {% assign greetings = "Hello" %}
@@ -35,24 +35,22 @@ This check is aimed at eliminating undefined object errors. Additionally it repo
 %}
 ```
 
+## Configuration Options
 
-
-## Check Options
-
-The default configuration for this check is the following:
+The default configuration for this check:
 
 ```yaml
 UndefinedObject:
   enabled: true
 ```
 
-## When Not To Use It
+## Disabling This Check
 
-It is discouraged to disable this rule.
+Disabling this check is not recommended.
 
 ## Version
 
-This check has been introduced in Theme Check 0.1.0.
+This check has been introduced in platformOS Check 0.1.0.
 
 ## Resources
 

data/docs/checks/unknown_filter.md

@@ -1,39 +1,39 @@
-# Prevent use of unknown filters (`UnknownFilter`)
+# Prevent Use of Unknown Filters (`UnknownFilter`)
 
-This check exists to prevent user errors.
+This check prevents errors caused by using unknown filters in Liquid code and aims to eliminate the use of such filters.
 
-## Check Details
+## Examples
 
-This check is aimed at preventing the use of unknown filters.
+The following examples show code snippets that either fail or pass this check:
 
-:-1: Examples of **incorrect** code for this check:
+### ✗ Incorrect Code Example (Avoid using this):
 
 ```liquid
 {{ x | some_unknown_filter }}
 ```
 
-:+1: Examples of **correct** code for this check:
+### ✓ Correct Code Example (Use this instead):
 
 ```liquid
 {{ x | upcase }}
 ```
 
-## Check Options
+## Configuration Options
 
-The default configuration for this check is the following:
+The default configuration for this check:
 
 ```yaml
 UnknownFilter:
   enabled: true
 ```
 
-## When Not To Use It
+## Disabling This Check
 
-It is not safe to disable this rule.
+Disabling this check is not recommended, as it helps prevent user errors.
 
 ## Version
 
-This check has been introduced in PlatformOS Check 0.0.1.
+This check has been introduced in platformOS Check 0.0.1.
 
 ## Resources
 

data/docs/checks/unreachable_code.md

@@ -1,12 +1,12 @@
-# Unreachable code (`UnreachableCode`)
+# Unreachable Code (`UnreachableCode`)
 
-Unreachable code reports code that will never be reached, no matter what.
+This check detects and ensures that you do not accidentally write code that will never be executed because it is unreachable.
 
-## Check Details
+## Examples
 
-This check is aimed at ensuring you will not accidentally write code that will never be reached.
+The following examples show code snippets that either fail or pass this check:
 
-:-1: Examples of **incorrect** code for this check:
+### ✗ Incorrect Code Example (Avoid using this):
 
 ```liquid
   assign x = "hello"
@@ -23,7 +23,7 @@ This check is aimed at ensuring you will not accidentally write code that will n
   endif
 ```
 
-:+1: Examples of **correct** code for this check:
+### ✓ Correct Code Example (Use this instead):
 
 ```liquid
   assign x = "hello"
@@ -40,22 +40,22 @@ This check is aimed at ensuring you will not accidentally write code that will n
   endif
 ```
 
-## Check Options
+## Configuration Options
 
-The default configuration for this check is the following:
+The default configuration for this check:
 
 ```yaml
 UnreachableCode:
   enabled: true
 ```
 
-## When Not To Use It
+## Disabling This Check
 
-There should be no cases where disabling this rule is needed.
+Disabling this check is not recommended.
 
 ## Version
 
-This check has been introduced in PlatformOS Check 0.4.7.
+This check has been introduced in platformOS Check 0.4.7.
 
 ## Resources
 

data/docs/checks/unused_assign.md

@@ -1,12 +1,12 @@
-# Prevent unused assigns (`UnusedAssign`)
+# Prevent Unused Assigns (`UnusedAssign`)
 
-This check exists to prevent bloat in themes by surfacing variable definitions that are not used.
+This check helps prevent bloat in your platformOS application by identifying variable definitions that are not used, aiming to eliminate unnecessary code in apps and highlight user errors.
 
-## Check Details
+## Examples
 
-This check is aimed at eliminating bloat in apps and highlight user errors.
+The following examples show code snippets that either fail or pass this check:
 
-:-1: Examples of **incorrect** code for this check:
+### ✗ Incorrect Code Example (Avoid using this):
 
 ```liquid
 {% assign this_variable_is_not_used = 1 %}
@@ -16,7 +16,7 @@ This check is aimed at eliminating bloat in apps and highlight user errors.
 {% function this_variable_is_not_used = 'my_function' %}
 ```
 
-:+1: Examples of **correct** code for this check:
+### ✓ Correct Code Example (Use this instead):
 
 ```liquid
 {% assign this_variable_is_used = 1 %}
@@ -37,22 +37,22 @@ This check is aimed at eliminating bloat in apps and highlight user errors.
 {% function _ignore_this_var = 'my_function' %}
 ```
 
-## Check Options
+## Configuration Options
 
-The default configuration for this check is the following:
+The default configuration for this check:
 
 ```yaml
 UnusedAssign:
   enabled: true
 ```
 
-## When Not To Use It
+## Disabling This Check
 
-It's safe to disable this rule.
+This check is safe to disable if you do not prioritize eliminating unused variables.
 
 ## Version
 
-This check has been introduced in PlatformOS Check 0.0.1.
+This check has been introduced in platformOS Check 0.0.1.
 
 ## Resources
 

data/docs/checks/unused_partial.md

@@ -1,27 +1,23 @@
-# Remove unused partials in app (`UnusedPartial`)
+# Remove Unused Partials in App (`UnusedPartial`)
 
-This check warns the user about partials that are not used (Could not find a `render` or `function` tag that uses that partial)
+This check warns the user about partials that are not used, specifically when no `render` or `function` tag references the partial, and aims to eliminate these unused partials from your app.
 
-## Check Details
+## Configuration Options
 
-This check is aimed at eliminating unused partials.
-
-## Check Options
-
-The default configuration for this check is the following:
+The default configuration for this check:
 
 ```yaml
 UnusedPartial:
   enabled: true
 ```
 
-## When Not To Use It
+## Disabling This Check
 
-It's safe to disable this rule.
+This check is safe to disable if managing unused partials is not a priority.
 
 ## Version
 
-This check has been introduced in PlatformOS Check 0.0.1.
+This check has been introduced in platformOS Check 0.0.1.
 
 ## Resources
 

data/docs/checks/valid_yaml.md

@@ -1,12 +1,12 @@
-# Enforce valid YAML (`ValidYaml`)
+# Enforce Valid YAML (`ValidYaml`)
 
-This check exists to prevent invalid Yaml files in app.
+This check ensures that YAML files in the app are valid and aims to eliminate errors in these files.
 
-## Check Details
+## Examples
 
-This check is aimed at eliminating errors in YAML files.
+The following examples show code snippets that either fail or pass this check:
 
-:-1: Examples of **incorrect** code for this check:
+### ✗ Incorrect Code Example (Avoid using this):
 
 ```yaml
 ---
@@ -14,7 +14,7 @@ hello: world
 invalid
 ```
 
-:+1: Examples of **correct** code for this check:
+### ✓ Correct Code Example (Use this instead):
 
 ```yaml
 ---
@@ -22,22 +22,22 @@ hello: world
 invalid:
 ```
 
-## Check Options
+## Configuration Options
 
-The default configuration for this check is the following:
+The default configuration for this check:
 
 ```yaml
 Validyaml:
   enabled: true
 ```
 
-## When Not To Use It
+## Disabling This Check
 
-It is not safe to disable this rule.
+Disabling this check is not recommended.
 
 ## Version
 
-This check has been introduced in PlatformOS Check 0.0.1.
+This check has been introduced in platformOS Check 0.0.1.
 
 ## Resources
 

data/docs/language_server/how_to_correct_code_with_code_actions_and_execute_command.md

@@ -1,16 +1,14 @@
-# How to correct code with Code Actions, Commands and Workspace Edits
+# How to Correct Code with Code Actions, Commands, and Workspace Edits
 
-The [Language Server Protocol (LSP)][lsp] empowers Language Server developers to offer refactorings, quick fixes and the execution of commands to their users. In PlatformOS Check, we take advantage of this to offer quick fixes and autocorrection to users.
-
-This document exists to give you an overview of how that works.
+The [Language Server Protocol (LSP)][lsp] empowers Language Server developers to provide tools like refactorings, quick fixes, and command executions to their users. PlatformOS Check utilizes this protocol to offer quick fixes and auto-correction capabilities to users.
 
 ## Overview
 
-It goes like this:
+The process of correcting code using platformOS Check:
 
-1. The Client (VS Code, vim, etc.) asks the Server for [Code Actions](#code-actions) at a character position, and the server responds with available `quickfix` and `source.fixAll` code actions.
-2. The User _may_ select one of the code actions by interacting with the UI (see [visual examples](#code-actions)). The selection triggers the Client to asks the Server to execute a `correction` [Command](#Commands) for certain [Diagnostics](#diagnostic) on behalf of the user.
-3. The Server asks the Client to apply a [Workspace Edit](#workspace-edits) to fix the diagnostics.
+1. **Request Code Actions**: The Client (e.g., VS Code, vim) requests [Code Actions](#code-actions) from the Server based on the user's current cursor position or selection. The server returns actions categorized as `quickfix` or `source.fixAll`, which are available for the given text location.
+2. **User Selection**: The user selects a desired code action from the UI (see [visual examples](#code-actions)). This selection asks the Client to send a `correction` request to the Server to execute a specific action based on the identified [Diagnostics](#diagnostic).
+3. **Apply Edits**: The Server calculates the necessary changes and requests the Client to apply a [Workspace Edit](#workspace-edits) which adjusts the code to resolve the issues.
 
 ## Sequence Diagram
 
@@ -19,64 +17,64 @@ It goes like this:
 <details>
 <summary>Sequence Diagram Explanation</summary>
 
-1. The Client asks the Server for [code actions](#code-actions) for the current file and character range.
-2. The Server responds with a list of code actions that can be applied for this location and character range. (`quickfix` and `source.fixAll`)
-3. ...Wait for user input...
-4. The User selects one of the code actions
-5. The Client sends a `workspace/executeCommand` request to the Server for this code action.
-6. The Server figures out the [workspace edit](#workspace-edits) for the command and arguments.
-7. The Server sends a `workspace/applyEdit` request for the file modifications that would fix the diagnostics.
-8. The Client responds with the status of the `applyEdit`.
-9. The Server cleans up its internal representation of the diagnostics and updates the client with the latest diagnostics.
-11. The Server responds to the `workspace/executeCommand` request.
+1. **Request Code Actions**: The Client requests [code actions](#code-actions) from the Server, specifying the file and the exact location (character range) within it.
+2. **Server Response**: The Server responds with available code actions for that location, such as `quickfix` and `source.fixAll`.
+3. **Awaiting User Input**: The system pauses while waiting for the user to select a desired code action.
+4. **User Selection**: The User chooses a code action from the provided options.
+5. **Execute Command**: Following the selection, the Client requests the Server to execute the chosen code action by sending a `workspace/executeCommand`.
+6. **Calculate Edits**: The Server calculates the necessary changes, or [workspace edits](#workspace-edits), required to implement the command.
+7. **Apply Edits**: The Server requests the Client to apply these edits through a `workspace/applyEdit` command, which adjusts the file to resolve the issues.
+8. **Client Confirmation**: The Client confirms whether the edits were successfully applied (`applyEdit`).
+9. **Diagnostics Update**: The Server updates its internal diagnostics based on the changes and informs the Client of the latest diagnostic state.
+10. **Complete Execution**: The Server finalizes the process by responding to the `workspace/executeCommand` request, confirming the completion of the action.
 
 </details>
 
-## What it's like in the code
+## Code Action and Command Handling
 
-We handle two Client->Server LSP requests:
+platformOS Check handles two types of Client-to-Server LSP requests:
 
-1. On `textDocument/codeAction`, our `CodeActionEngine` returns the results obtained from all `CodeActionProvider`.
-2. On `workspace/executeCommand`, our `ExecuteCommandEngine` dispatches the command and arguments to appropriate `ExecuteCommandProvider`.
+1. **Code Actions**: On `textDocument/codeAction`, our `CodeActionEngine` returns the results obtained from all `CodeActionProvider`.
+2. **Execute Commands**: On `workspace/executeCommand`, our `ExecuteCommandEngine` dispatches the command and arguments to appropriate `ExecuteCommandProvider`.
 
-We define providers:
+### Providers Defined:
 
-- Two `CodeActionProvider`:
-  1. [`QuickFixCodeActionProvider`](/lib/platformos_check/language_server/code_action_providers/quickfix_code_action_provider.rb) - This one provides code actions that fix _one_ diagnostic.
-  2. [`SourceFixAllCodeActionProvider`](/lib/platformos_check/language_server/code_action_providers/source_fix_all_code_action_provider.rb) - This one provides code actions that fix _all diagnostics in the current file_.
-- One `ExecuteCommandProvider`:
-  1. [`CorrectionExecuteCommandProvider`](/lib/platformos_check/language_server/execute_command_providers/correction_execute_command_provider.rb) - This one takes a list of diagnostics as arguments, turns them into a [WorkspaceEdit](#workspace-edit) and tries to apply them with the server->client `workspace/applyEdit` request.
+- **CodeAction Providers**
+  1. [`QuickFixCodeActionProvider`](/lib/platformos_check/language_server/code_action_providers/quickfix_code_action_provider.rb) - Provides code actions that fix _one_ diagnostic.
+  2. [`SourceFixAllCodeActionProvider`](/lib/platformos_check/language_server/code_action_providers/source_fix_all_code_action_provider.rb) - Provides code actions that fix _all_ diagnostics in the current file.
+- **ExecuteCommand Provider**:
+  1. [`CorrectionExecuteCommandProvider`](/lib/platformos_check/language_server/execute_command_providers/correction_execute_command_provider.rb) - Takes a list of diagnostics as arguments, turns them into a [WorkspaceEdit](#workspace-edit) and requests the Client to apply them (`workspace/applyEdit`).
 
-We define a [`DocumentChangeCorrector`](/lib/platformos_check/language_server/document_change_corrector.rb) (an LSP analog to our [`Corrector`](/lib/platformos_check/corrector.rb) class). This class turns corrector calls into document changes supported by the LSP. For more details, see the [LSP reference on resource changes][lspresourcechange].
+### Additional Details
 
-## Definitions
+We define a [`DocumentChangeCorrector`](/lib/platformos_check/language_server/document_change_corrector.rb) (an LSP analog to our [`Corrector`](/lib/platformos_check/corrector.rb) class). This class turns corrector calls into document changes supported by the LSP. For more details, refer to the [LSP reference on resource changes][lspresourcechange].
 
-### Code Actions
+## Definitions and Examples
 
-A [CodeAction][lspcodeaction] is the Language Server Protocol construct for "stuff you might want to do on the code."
+### Code Actions
 
-Think refactoring, running tests, fixing lint errors, etc.
+A [CodeAction][lspcodeaction] is a suggestion for a change to the code that the User can apply directly. It could include refactorings, fixes for linting errors, or test executions.
 
-The client figures out which one it can run by executing the client->server `textDocument/codeAction` request.
+The Client determines which actions it can perform by sending a `textDocument/codeAction` request from the client to the server.
 
 <details>
 <summary>Visual Examples</summary>
 
-In VS Code, code actions of different kinds have special meanings and are mapped to multiple places in the UI.
+In VS Code, different types of code actions are represented and accessed differently within the user interface:
 
-* `Quick Fix...` button on diagnostic hover
+- **`Quick Fix...` button**: Appears when you hover over a diagnostic marker.
 
   <img src="code-action-quickfix.png" width=500>
 
-* Diagnostic right click in the problems tab
+- **Right-click on a diagnostic in the problems tab**:
 
   <img src="code-action-problem.png" width=500>
 
-* Command palette `Quick Fix...` and `Fix All`
+- **Command palette entries for `Quick Fix...` and `Fix All`**:
 
   <img src="code-action-command-palette.png" width=500>
 
-* Keyboard shortcuts
+- **Keyboard shortcuts**:
 
   <img src="code-action-keyboard.png" width=700>
 </details>
@@ -86,27 +84,27 @@ In VS Code, code actions of different kinds have special meanings and are mapped
 
   ```ts
   interface CodeAction {
-    title: string; // UI string, human readable for the action
-    kind?: CodeActionKind; // OPTIONAL, for filtering
-    diagnostics?: Diagnostic[]; // The diagnostics that the action SOLVES.
+    title: string; // Human-readable display name of the action, shown in the UI.
+    kind?: CodeActionKind; // OPTIONAL, used to filter actions based on type.
+    diagnostics?: Diagnostic[]; // List of diagnostics that the action SOLVES.
     isPreferred?: boolean; // Are used by auto fix and can be targetted by keybindings.
-    // Shown as faded out in the code action menu when the user request a more specific type of code action
+    // Shown as faded out in the code action menu when the user request a more specific type of code action.
     disabled?: {
       reason: string;
     },
 
-    // if both edit and command are present, edit is run first then command.
-    // I think edit is used so the client performs the change, wheras the command
-    // would be done by the server
-    edit?: WorkspaceEdit; // what this action does ??!!
-    command?: Command; // the command that it executes
-    data?: any; // sent from the CodeAction to the codeAction/resolve.
+    // If both an edit and a command are present, the edit is applied first, followed by the command.
+    // Generally, the edit is intended to be executed by the client to make changes to the document,
+    // while the command is executed by the server to perform additional actions.
+    edit?: WorkspaceEdit; // Describes the document changes to be made by the action.
+    command?: Command; // The command to be executed by the server.
+    data?: any; // Additional data sent from the CodeAction to the codeAction/resolve.
   }
 
   interface Command {
-    title: string; // Title of the command, like `save`
-    command: string; // id
-    arguments?: any[]
+    title: string; // Display name of the command, like 'Save'.
+    command: string; // ID of the command.
+    arguments?: any[] // Optional arguments for the command.
   }
   ```
 </details>
@@ -115,20 +113,18 @@ In VS Code, code actions of different kinds have special meanings and are mapped
 
 ### Commands
 
-A [Command][lspcommand] is the Language Server Protocol representation of a command that can be executed by the Server.
+A [Command][lspcommand] in the Language Server Protocol (LSP) is a representation of a function that can be executed by the server, based on instructions sent from the client.
 
-Think of them as data representation of function calls that can be made by the Client.
-
-Typically, a command is associated with a Code Action. If the Client wants to perform this Code Action, it will make a Client->Server `workspace/executeCommand` request.
+Think of commands as actionable requests - similar to function calls — that the client can initiate. These commands are often linked to a Code Action. When a client initiates a specific Code Action, it sends a `workspace/executeCommand` request from the client to the server.
 
 <details>
   <summary>TypeScript Interface</summary>
 
   ```ts
   interface Command {
-    title: string; // Title of the command, like `save`
-    command: string; // id
-    arguments?: any[]
+    title: string; // Display name of the command, like 'Save'.
+    command: string; // ID of the command.
+    arguments?: any[] // Optional arguments for the command.
   }
   ```
 </details>
@@ -137,9 +133,7 @@ Typically, a command is associated with a Code Action. If the Client wants to pe
 
 ### Workspace Edits
 
-A [WorkspaceEdit][lspworkspaceedit] is the Language Server Protocol construct that abstracts code changes as data.
-
-Think edit file, create file, delete file but as data.
+A [WorkspaceEdit][lspworkspaceedit] is a Language Server Protocol (LSP) construct designed to represent code changes in a structured data format. This approach allows operations like editing, creating, or deleting files to be described as data transactions.
 
 <details>
   <summary>TypeScript Interface</summary>
@@ -151,7 +145,7 @@ Think edit file, create file, delete file but as data.
     changeAnnotations?: { [id: string]: ChangeAnnotation }
   }
 
-  // see https://microsoft.github.io/language-server-protocol/specifications/specification-current/#resourceChanges
+  // See https://microsoft.github.io/language-server-protocol/specifications/specification-current/#resourceChanges.
   interface CreateFile {
     kind: 'create';
     uri: DocumentUri;
@@ -161,7 +155,7 @@ Think edit file, create file, delete file but as data.
 
   interface TextEdit {
     range: Range;
-    newText: string; // can be empty to delete
+    newText: string; // The new text to replace the specified range. An empty string indicates deletion.
   }
 
   interface TextDocumentEdit {
@@ -171,7 +165,7 @@ Think edit file, create file, delete file but as data.
 
   interface OptionalVersionedTextDocumentIdentifier {
     uri: TextDocumentURI;
-    // null is for when the file wasn't open from the client
+    // null is for when the file wasn't open from the client.
     // integer is for when you know what it was.
     version: integer | null;
   }
@@ -182,16 +176,14 @@ Think edit file, create file, delete file but as data.
 
 ### Diagnostic
 
-A [Diagnostic][lspdiagnostic] is the Language Server Protocol construct for errors, warnings and information bubbles.
-
-In our case, diagnostics are PlatformOS Check offenses.
+A [Diagnostic][lspdiagnostic] is a construct within the Language Server Protocol (LSP) used to represent issues within the code, such as errors, warnings, and informational messages.
 
-They appear in the Problems tab and in the gutter of the editor.
+In platformOS Check, diagnostics highlight ode offenses that need addressing, such as errors or warnings. They are shown in the _Problems_ tab and next to the code in the editor's gutter, helping developers quickly locate and understand the issues detected by the system.
 
 [lsp]: https://microsoft.github.io/language-server-protocol/specification
 [lspcodeaction]: https://microsoft.github.io/language-server-protocol/specification#textDocument_codeAction
 [lspcommand]: https://microsoft.github.io/language-server-protocol/specification#command
 [lspexecutecommand]: https://microsoft.github.io/language-server-protocol/specification#workspace_executeCommand
 [lspworkspaceedit]: https://microsoft.github.io/language-server-protocol/specification#workspaceEdit
-[lspdiagnostic]: https://microsoft.github.io/language-server-protocol/specifications/specification-3-17/#diagnostic
+[lspdiagnostic]: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnostic
 [lspresourcechange]: https://microsoft.github.io/language-server-protocol/specifications/specification-current/#resourceChanges

data/lib/platformos_check/language_server/completion_providers/filter_completion_provider.rb

@@ -57,7 +57,7 @@ module PlatformosCheck
 
       def available_filters_for(input_type)
         filters = PlatformosLiquid::SourceIndex.filters
-                                               .select { |filter| input_type.nil? || filter.input_type == input_type }
+                                               .select { |filter| input_type.nil? || filter.input_type == input_type || filter.input_type == 'untyped' }
         return all_labels if filters.empty?
         return filters if input_type == INPUT_TYPE_VARIABLE