Projects

Choose a meaningful repository root

A project provides the source boundary for indexing. Start at the repository or workspace root so the analyzer can see relevant package metadata and local modules together. Selecting a single nested folder may hide relationships that cross the selected boundary.

Open, inspect, then scan

1. Add a project and select its source folder. Review the detected path and project information.

2. Start the initial scan. Wait for its reported result rather than treating a queued or scanning state as complete.

3. Open the project, check its currentness state and use the file tree or symbol search to find a known source location.

When a file is missing

Check the selected root, language support and excluded or generated paths. Also distinguish a file that is not indexed from a symbol that is indexed but not present in the current bounded view. Search and the tree can help narrow that distinction.

After source changes

Read the project state and source notices after changes. Use Update to check for changes, or Rebuild index for full discovery and reanalysis, then check the published revision. A previous index can remain visible while a new one is built; a failed or canceled operation is not a successful refresh.

Code, declarations and documents

Executable source, SQL/OpenAPI declarations and project documentation serve different purposes. Code LOC applies to indexed source code, not to a count of database rows or the text of an OpenAPI contract. A file can be available as a document without having supported code relationships.

When a limit or unsupported language appears

• Check the current access shown in your account before adding or indexing another workspace.

• Each workspace has its own LOC limit; a small workspace does not transfer unused allowance to a larger one.

• Read the indexing result and notices. Do not treat an incomplete or rejected index as a newly published complete revision.

• Unsupported source does not acquire semantic analysis merely because the file is visible. Supported parts can still provide useful evidence; inspect the reported coverage.

Choose the workspaces within your allowance

Check Settings → Plans in Explorer for your current workspace allowance and LOC limit. These workspace places apply to this installation. Opening an already registered workspace again does not use a second place. When Explorer recognizes the same folder as an existing project, it reuses that library entry; a separate copy can be a different workspace.

If your library already contains more than two workspaces

Moving to Free does not automatically delete the extra library entries, source files or indexes. Explorer applies the allowance in a fixed internal project order. It is not based on the visible sort, the most recently opened project or when you registered it. Changing the visible sort does not choose which entries fit the allowance.

Keep a different pair of workspaces

1. Choose the two workspaces you want to keep registered on this installation. Wait for active indexing to finish, or use the scan controls before removing an entry.

2. In Project Library, use Remove on the other entries. Read the confirmation: only the library entry is removed. Its source files and Graphtia index are not deleted.

3. Check the remaining projects and their access state. Each workspace still has its own LOC limit; removing one does not transfer its unused LOC allowance to the other.

Register a removed workspace again

Make a place available first, then use Add project and select the original workspace folder. Explorer inspects the folder and any existing index it can read. Check the reported project state and revision; use Update when the source has changed. A retained index is not automatically proof that the current source is fully indexed.

Remove in Project Library is different from permanently deleting files from disk. You do not need to delete the source folder or index to free a library place. If those files have been deleted separately, adding the folder again does not restore them.

Index controls

Read progress before opening a result as current. Pause and resume work at supported checkpoints within the running process; do not assume closing Explorer preserves a resumable scan. Cancel stops work where possible and does not undo a revision already published.

Project index exclusions

Use Index exclusions to save relative patterns for a project, then run Update to apply the pending rules to a published index. A preview based on an existing index does not prove the new rules have been applied. Built-in exclusions remain in effect. Supported examples include generated/ and **/*.min.js. Patterns are case-sensitive and do not provide full .gitignore syntax, negated inclusions or absolute paths. Exclusions select what to analyze; they do not replace access permissions or erase displayed history.

Incremental work, resources and completion

The watcher can schedule incremental indexing for registered, indexed projects after file-system events. These events are not a one-to-one record of saves. Reconciliation covers changes made while the app was closed and gaps in event delivery; always check the resulting index state.

The first index can be labeled Update when there is no previous published revision. An update does not guarantee that only one file will be analyzed. Windows has a guarded shortcut for unchanged workspaces; Ubuntu follows its normal comparison path. Neither label is a promise of a fixed duration.

Eco, Balanced and Fast adjust indexing concurrency and admission according to available resources. They are not fixed RAM targets or guaranteed CPU percentages. Temporary work can be released after indexing while useful caches remain. The app does not promise zero memory use after completion.

Canceling before a new revision is committed preserves the previous revision. Treat completion, published revision, coverage and source currentness as separate observations. No current universal speed, minimum-memory or maximum-project-size benchmark is implied by these controls.

Watch, reconcile and verify

The project watcher groups changes for indexing. Reconciliation also checks the sources to recover changes made while Explorer was closed or events that were missed. If the available change evidence is incomplete, Explorer falls back to source discovery. A watcher event alone does not prove that the index is current.

Update can reuse earlier analysis and can keep the same revision when no changes are found. Rebuild performs full discovery and analysis. Windows can skip starting an indexing worker when a current watcher-backed check proves the sources unchanged; Linux uses the normal update path. This is not an identical instant-update promise across operating systems.

A new revision becomes Current after its publication is verified. If that verification fails, the project can require reconciliation or further attention; do not treat a previous recorded revision as automatically verified and available.

Progress describes the operation and its phases. A completion estimate appears only when enough observations are available. Elapsed phase time is wall-clock time, not CPU time, and a process lifetime memory peak is not the peak for that one run.

Resource profiles and measured workloads

• Choose Eco, Balanced or Fast

• Read historical indexing measurements and methodology

When a project needs attention

Read the project’s current state before choosing an action. A missing folder, unavailable index or busy library is not the same as an index that must be rebuilt.

Confirm project folder

Confirm the existing project folder when Explorer asks you to verify its location. This keeps the project’s existing index associated with the confirmed folder.

Project folder unavailable

Restore access to the folder or drive, then retry. Keep the project registration while you restore access rather than treating an unavailable folder as a deleted project.

Project identity changed

Review the folder and its identity before reconnecting it. Confirm that the location is the project you intend to use.

Index unavailable

Check access to the project and its storage, then use Check again. An unavailable index does not by itself mean a rebuild is required.

Update index

Update when the current source needs a new indexed revision. The previous published revision remains the available evidence until a new publication succeeds; check currentness before relying on it.

Rebuild required

Choose Rebuild index when Explorer reports that rebuilding is required. The previous published revision is preserved until a new one is successfully published.

Project library busy

Retry after the other library operation finishes. Avoid starting competing recovery actions while the library is busy.

Project library needs repair

Restore access or complete the interrupted library operation before making index changes. Follow the specific recovery message; this state is not a promise of automatic rollback or recovery from every storage failure.