Search & Impact New in 1.0.4
Three related questions, answered from one index:
- Where is it? — full-text search across every project.
- Where is it used? — every place a tag, connection, script, view or named query is referenced.
- What will this break? — the dependents of a namespace node, shown before a rename or delete.
The index is derived and rebuilt from the artifacts themselves. It is an accelerator, not the authority: a delete is still governed by the server, and the index only makes the consequences visible first.
The command palette
Press ⌘K / Ctrl+K anywhere, or use the search box in the header.
Results are grouped by kind — Pipelines, Views, Scripts, Named Queries, Playbooks and Specialists — and searched across every project, not just the one you are in. Choosing a result activates that project and takes you to the artifact.
Filtering is server-side against the index, so the palette stays fast on a large installation, and it returns 50 hits at a time.
Filters
Click the filter control for checkboxes, or type the token — they are the same thing, and the input stays the single source of truth so the two can never disagree. Tokens survive in a shared link, which is why they are the underlying form.
| Token | Narrows to |
|---|---|
kind:pipeline · kind:view · kind:script · kind:query · kind:playbook · kind:specialist | One kind of artifact. Plurals work too. |
project:North Plant | One project. Quote a name containing spaces: project:"North Plant". |
Where is this used?
Two operators turn the palette into a usage lookup:
tag:Line1/PMP-01/Amps
conn:Plant DB
Both take everything to the end of the line as their value, because tag paths and connection names routinely contain spaces — so they are always the last thing you type. A connection is looked up by name: every reference stores an id internally, but nobody knows a connection by its id.
An unfinished operator shows help instead of running: typing tag: a character at a time would
otherwise fire a search for every prefix, and the flicker reads as the feature being broken.
Namespace filters
The Namespace panel has its own facets, describing tag configuration rather than artifact kind. Each label states a condition, never a field, so an unticked box plainly means "not filtering on this".
| Group | Options |
|---|---|
| Status | is:disabled · no:binding · is:unused · is:writable · has:alarm |
| History | has:history · no:history |
| Publish | is:published · no:published |
| Source | source:device · source:internal · source:expression |
Status options are independent and combine — disabled and no binding is a perfectly good question. History, Publish and Source are exclusive: holding two values of one facet at once asks for something contradictory and would always return nothing, so picking one clears its sibling. Clicking the selected box again returns that group to "don't care".
Only the exception gets a checkbox, because that is what people search for — Disabled is the one
you go looking for, Enabled matches nearly every tag and narrows nothing. The inverse of every
single-box facet is still reachable by typing it: is:enabled, has:binding, is:used,
is:readonly, no:alarm all parse.
A filter needs no search term. "Every disabled tag" is a legitimate question with no text in it, and text alone, filters alone, or both together are all valid.
Finding unused tags
is:unused lists tags that no view, script or pipeline references.
A reference whose target is built at runtime — system.tag.write(path, value) where path is a
variable — cannot be traced to any particular tag. Such a tag is reported as unused because nothing
statically names it, not because nothing uses it.
The filter also refuses outright, rather than answering, when the reference index is unavailable. An "unused" query against an absent index would report the entire namespace as unreferenced, and that is an answer people delete things on.
Impact, before a destructive edit
Renaming or deleting a namespace node shows a panel naming what depends on it, with the first few reference sites listed — headed This is still in use before a delete, and This rename has dependents before a rename.
The panel is absent when nothing depends on the node. A warning box that is usually empty is one people learn to click past, so its appearance means something.
Rename and delete break things differently, and the panel says which. A view binding stores a tag by path, so renaming a folder rewrites every descendant path and breaks those bindings just as surely as deleting them would:
| Action | What the panel says |
|---|---|
| Delete | Deleting will leave those references pointing at nothing. |
| Rename | Renaming changes the path those references point at, so they will stop resolving. |
Three qualifications are stated whenever they apply, and each exists to stop the panel being falsely reassuring:
- "You can see n of them." The count is taken over every artifact on the server, including ones you have no permission to open. Saying nothing depends on this because the reader lacks Designer rights is how a plant loses a screen.
- "This count is a floor, not a total." The folder was larger than the scan limit.
- "Some references build their target at runtime and could not be attributed either way." They neither prove nor disprove impact.
The panel never blocks: the dialog stays usable while it loads, and a failed lookup stays silent rather than implying safety it did not verify.
What is indexed
Pipelines, views, scripts, named queries, playbooks and specialists — their names, their content, and
the references inside them. A reference is recorded with a locator saying where inside the
artifact it lives (nodes.gauge.props.value, L42, node:io-1/L3), so a usage result points at the
line rather than at the file.
Tag references are resolved in both forms a reference can take — the path a view binding stores,
and the node id a pipeline stores — because neither is derivable from the other without a namespace
lookup. Asking for tag: fans out to both.