Startup, discovery and recall

Rubian prepares a view of the environment before you begin interactive work. Startup reports identify the connected system, discovered directories and files, available commands, and library preparation. After sign-in, the prompt supplies your current identity and location. This gives subsequent commands a common starting point for locating and organizing work.

What startup discovers#

The full interactive environment inventories three areas: the system locations exposed to Rubian, the Rubian environment itself, and files and directories beneath the host user's home. It also discovers the installed Rubian commands. The home inventory includes nested directories; access permissions and the supplied configuration determine what can be discovered.

This is an inventory of available locations and names. It does not relocate your existing files or classify their contents. The inspected interactive version does not guarantee discovery of every mounted disk, protected directory or hidden file on the host. A lightweight operational session can also begin with a smaller inventory than the full interactive environment.

Startup may prepare compatible installed libraries for use through Forge. The startup report distinguishes available libraries from skipped or unsuccessful registrations. A library being installed on the host does not establish that all of its interfaces are available in Rubian.

Read the prompt and inventory#

system_status
pwd
user_files
user_dirs
local_bin_files(show_status: false)

system_status prints the session's version, connection information and inventory counts. pwd returns the current path. The two user-inventory commands summarize discovered files and directories by location; local_bin_files displays the installed command names.

The prompt's [vfs] marker indicates a Rubian-managed working location. A host working location uses the host filesystem. Check this distinction before a write: the files reference shows which operations support each kind of location.

Browse an organized view#

inventory = user_files(:documents, limit: 20)
document_paths = inventory[:documents]
user_dirs(:downloads)

The first command displays up to 20 discovered Documents entries, including names, sizes and containing directories. Its returned hash still contains the full categorized inventory; limit controls the display, not the returned arrays. The second line retains the Documents paths for further work. Directory views list the selected category.

These groups organize the discovered paths by location. They are views of the inventory, rather than new folders containing copies of your files. Category counts can overlap, and a displayed number is a position in that view rather than a permanent file identifier. Use the full path when saving a procedure.

Refresh after the environment changes#

The inventory reflects discovery at startup or the last applicable refresh. A file created by another program may be readable at its explicit path before it appears in an inventory view.

report = refresh(:local, deep: true)
puts report[:ok]
puts report[:errors]
user_files(:documents, limit: 20)

Use deep: true when you need to discover changes across the user's home tree. The default refresh updates the local command environment and system view without repeating that broader home scan. This distinction matters on a machine with a large working tree: choose the wider operation when the inventory needs it.

refresh also reloads the available command environment. Finish sensitive work before using it in an active session. It returns a report with :ok, :scope, :commands, :command_total, :ms and :errors. A partial refresh can return a report containing errors; inspect the report before relying on newly available commands. Refreshing does not install a new product release.

refresh(:all, reason: 'Updated local tools') requests a refresh across participating workspaces. Use it only when that broader operation is intended. refresh_status reports the requested and observed state; a request does not establish that every workspace has applied it.

Return to previous work#

Use the terminal's command-history controls to revisit an earlier expression, then inspect it before executing it again. history(20) displays recent entries where the history command is supported by the supplied terminal. Interactive history can persist between sessions; keep credentials out of ordinary expressions. clear_history clears the command's in-memory history and is not a secure deletion procedure for saved history.

For work that needs a name, files and a record of decisions, use Projects and session notes. For an operation that must run again, save its inputs explicitly and use the recurring-work controls. A remembered command, a saved project and a recurring task serve different purposes.