Add --json for the machine-readable form. A caller holding uploaded files in memory, with nothing on disk, can pipe them in instead and skip the filesystem entirely:

$ echo '{"files": [{"name": "modules.csv", "content": "module_name,module_step\nM,Sleep\n"}]}' \
    | optics-lsp lint

Reading on stdin always answers JSON:

{
  "status": "FAIL",
  "analyzed": { "modules.csv": "modules" },
  "skipped": [],
  "diagnostics": [
    {
      "uri": "modules.csv",
      "severity": "error",
      "code": "keyword-arity",
      "message": "'Sleep' takes 1-1 params, got 0",
      "row": 2,
      "range": { "startLine": 1, "startColumn": 0, "endLine": 2, "endColumn": 0 },
      "source": "optics"
    }
  ]
}

row is 1-based for a person, range is 0-based for an editor. Diagnostics arrive sorted by file then row, so a caller need not re-sort.

Shelling out from Node: pass the arguments as an array with the payload on stdin rather than interpolating either into a shell string, and raise maxBuffer past its 1 MB default.

File kind comes from the header row, not the filename. analyzed says what each file became (test_cases, modules, elements, error_definitions); skipped lists the CSVs whose header matched none of those.

optics ignores those files too, so a skipped file is usually a dataset and fine. But a test_cases file with a typo in its header lands there as well, and would otherwise be indistinguishable from a clean one.

Everything from the linter section above, live, across the whole project. Because resolution is a project-wide question, defining an element in one file clears the element-not-found in another without touching it.

Aware of which column you are in, because in a CSV the column is the context.

Param completion is specific rather than generic. Read Data's second param offers the project's data files; Invoke API's first offers collection.api identifiers parsed out of the project's YAML; Run Loop and Execute Module offer modules, written bare. Params with a documented set of values offer exactly those. direction gives up, down, left, right; rule gives any, all; element_state gives visible, invisible, enabled, disabled. Condition alternates condition and target, so it offers modules in the target slots and modules-or-variables in the others, with ! inversion preserved.

Accepting a param the header does not yet cover widens the header in the same edit, because csv.DictReader drops cells the header does not name and the param would otherwise silently vanish.

A keyword's real signature and the framework's own docstring, which is where the accepted values are actually written:

Press Element(element, repeat='1', offset_x='0', offset_y='0', index='0',
              aoi_x='0', aoi_y='0', aoi_width='100', aoi_height='100', event_name=None)

Press a specified element.

:param element: The element to be pressed (text, xpath or image).
:param repeat: Number of times to repeat the press.
:param index: Index of the element if multiple matches are found.
:param aoi_width: Width percentage of Area of Interest (0-100). Default: 100.

Defaults are rendered as name='value', so what an omitted cell falls back to is visible without reading the source.

The keyword's params with the column you are in marked active, retriggering on every comma, which is how you tell param 4 from param 5 in a row of commas.

From a step to the module it runs, or from a ${ref} to the elements it reads. Every ${name} in the cell is offered, not just one: a fallback element is several rows, and so is ${a} == ${b}.

Two details it gets right. A module_step naming something that is also a keyword resolves to the keyword, so a same-named module is not offered, mirroring what the runner does. And Condition's !Name inversion is stripped the same way the runner strips it.

Every place a name is used across the project, optionally including where it is bound. Works on test cases, modules, elements and error codes, the things the project owns. A keyword belongs to the framework, and an image, data file or API identifier names something outside the CSVs, so neither comes back from here.

Renames across every file that writes the name, with prepare-rename so the client can reject an invalid position before you start typing. This is the feature that most needs to be project-wide: the runner keys everything by name, so a rename that misses one cell quietly changes what runs instead of failing loudly.

One file's outline: what it defines, and the rows making each one up:

Open App          [Function]  2 steps
    Launch App    [Method]
    Sleep         [Method]    2
Login             [Function]  1 step
    Press Element [Method]    ${btn}

Every name the project declares, searchable from anywhere — "Go to Symbol in Workspace" in VS Code, workspace/symbol on the wire. Declarations only: a module's steps and an element's locators belong to the file outline, and repeating them here would bury the handful of names being searched for under every row that mentions them.

The match is a case-insensitive substring, and each result carries the kind its file's header row made it (modules, test_cases, …) as the container, since that is the only thing telling a module from a test case of the same name.

Highlighting a CSV grammar cannot express, because the meaning of a cell depends on the column above it and on the rest of the project:

A framework keyword also carries the defaultLibrary modifier, so themes colour it apart from a module of the same shape, which they would otherwise draw identically.