Saved project profiles and setup

Profiles save the explicit arguments needed to reopen a development workspace. They do not discover and execute project commands automatically. Creating, showing or checking a profile never runs its configured build/test command; opening it makes that command available to the terminal's explicit g action.

Start without ROS

Use a project directory and an existing task if you have one. The example command below is a deliberately small host check, so this workflow requires no ROS image.

flightops-tui profiles create .launchcommit/camera-profile.json \
  --name 'Camera development' --project /absolute/project \
  --session-dir /absolute/evidence/camera-session \
  --check-command python3 -c 'print("Configured host check completed")'
flightops-tui profiles show .launchcommit/camera-profile.json
flightops-tui profiles check .launchcommit/camera-profile.json
flightops-tui profiles open .launchcommit/camera-profile.json

In the terminal, 0 Project shows the saved settings, their origins and setup observations. 7 Results, then g, runs the configured command. Closing and reopening the same profile uses its saved session. Existing check cleanup and playback ownership rules still apply.

Add --task /absolute/task.json to create/open when using experiment planning and binding (source repository). Task records must belong to the selected project. They can be created with the existing tasks create command. An experiment's descriptive test string is never treated as executable.

Review and override settings

flightops-tui profiles show .launchcommit/camera-profile.json \
  --project /another/checkout --session-dir /another/evidence/session
flightops-tui profiles open .launchcommit/camera-profile.json --json

show prints the resolved profile, the exact workspace argv, value origins and an offline setup checklist. Explicit command-line settings override saved values for that invocation; the profile file is unchanged. There is no implicit profile discovery. Relative host paths supplied at creation/override resolve against the current working directory and are stored as absolute paths.

Use --no-live or --no-tf-use-sim-time for explicit Boolean overrides. --check-command consumes the remaining argv and must be last. Its strings are preserved literally; no shell expansion is applied. Profiles are machine-local configuration, not portable reproduction packages. Do not store credentials in them.

open --json renders the initial saved session and profile context without starting collectors, the native terminal, playback or a check. It does not claim live readiness. Profile creation refuses an existing output. Profiles require a project and durable session directory; without --session-dir, the default is PROFILE_STEM-session beside the profile file.

Existing ROS containers

Live profiles require an explicit ROS domain so resumption cannot inherit another domain. Observation and check containers remain separate settings. Flightops creates neither container and never pulls an image through this workflow.

flightops-tui profiles create .launchcommit/live-profile.json \
  --name 'Robot development' --project /absolute/project \
  --session-dir /absolute/evidence/robot-session \
  --live --ros-container existing-ros --ros-domain-id 81 \
  --check-container existing-ros --check-workspace /work/project --check test
flightops-tui profiles check .launchcommit/live-profile.json --observe
flightops-tui profiles check .launchcommit/live-profile.json \
  --observe --pin-environments
flightops-tui profiles open .launchcommit/live-profile.json

check without --observe examines local files, executable availability, storage, source declarations and interrupted-check markers. --observe explicitly invokes bounded Docker inspection and existing onscope sourcing diagnostics for live profiles. Use --doctor-topic /camera with --observe to request the existing topic doctor instead. These are read-only observations, not configured checks.

The checklist distinguishes available, missing, unsupported, unchecked and blocked items, including unsupported launch declarations. A successful observation never proves that a robot or its software is healthy.

--pin-environments explicitly saves observed container IDs, image IDs and mount identities. Interactive opening requires those pins and refuses changed/missing containers. It then uses immutable container IDs for subsequent operations, so later reuse of a container name cannot redirect the session. Writable source/artifact mounts are additionally verified by the existing check runner immediately before execution. Re-pinning is an explicit update after reviewing the changed environment.

Records, limits and exit codes

The new configuration record is flightops.project-profile/0; the diagnostic report is flightops.profile-setup/0 with assurance: none. Neither changes scenario version 0, proof records or assurance meanings. Input/output records are bounded to 4 MiB; argv has at most 128 entries and at most 4,096 characters per entry. Unknown schema versions/fields, duplicate JSON keys and invalid combinations fail.

Commands return 0 on successful handling, 2 on invalid input/publication refusal, and check returns 3 when a prerequisite is missing or blocked. Unsupported or unchecked items remain explicit and make the report incomplete. open otherwise returns the workspace exit code. Creating a profile does not validate its live state.