Daily workflows

Daily development, team onboarding, CI, and maintenance routines; lockfile workflows apply to Arch, Debian, and Ubuntu.

A daily development loop

Start the day with a system check.
```
omg status
```
Apply available updates when you are ready.
```
omg update
```
Change into a project. The shell hook reads version files and switches runtimes automatically.
Run project tasks without knowing the ecosystem tool.
```
omg run dev
```
Record the day at a natural stopping point.
```
omg env capture
```

Inspect, preview, approve, verify Every mutation follows the same order. The dashed line is the step most people skip: going back to inspect when the preview surprises them.

On Arch, Debian, and Ubuntu, omg env capture writes supported package names and selected runtime versions to omg.lock. Commit that file with your project and run omg env check to inspect drift. It does not record system package versions or all application dependencies. Fedora and macOS do not support this capture path.

Team onboarding

The team lead pins versions in version files and captures omg.lock.
Commit the lockfile and version files to the repository.
```
git add omg.lock .nvmrc .python-version
```
A new member installs OMG and the shell hook, clones the project, and verifies the machine against the lock.
```
omg env check
```
Differences are visible immediately; fix them before running the project.
```
omg run dev
```

Keeping a team in sync

omg team init mycompany/frontend
omg team pull
omg env capture
omg team push

CI and container pipelines

Install OMG in a setup step and add ~/.local/bin to PATH.
Fail fast when the runner does not match the committed lockfile.
```
omg env check
```
Run tasks through the task runner.
```
omg run test
```
Print the recommended Linux cache paths and lockfile-based key, then copy them into your CI provider cache step.
```
omg ci cache
```

Generate CI configuration

omg ci init github
omg ci init gitlab
omg ci validate

In Docker images, install OMG in a RUN step, copy the project including omg.lock, and run omg env check before building. For non-interactive shells, pass --yes to commands that would prompt.

A practical security routine

Periodic security review

omg audit
omg audit secrets -p .
omg audit sbom -o sbom.json
omg audit verify

In v0.1.223, run the full routine on Arch and start omgd for the audit step; Debian and Ubuntu SBOM generation fails because required vulnerability matching is unavailable there. The newer checkout supports SBOMs on Arch, Debian, Ubuntu, and Fedora and can audit without a daemon. Findings alone do not make the vulnerability command exit with a failure status. The secret scan covers your project directory. The SBOM records installed packages and matched findings when inventory and advisory data are available. audit verify checks the retained log for local consistency; filesystem access can still delete, truncate, or rewrite it. Review the results before changing packages.

System maintenance

Weekly maintenance

omg update
omg clean --orphans
omg clean --cache
omg doctor

Before a major upgrade, create a restoration point.
```
omg snapshot create -m "Before upgrade"
```
Review recent transactions if anything looks wrong.
```
omg history --limit 20
```
Roll back the last transaction if the upgrade misbehaves.
```
omg rollback
```

Monitoring from the shell prompt

Prompt helper functions on Zsh

omg-ec
omg-uc

The Bash and Zsh shell hooks provide count functions for prompts. omg-ec shows explicit packages, omg-tc shows all packages, omg-oc shows orphans, and omg-uc shows available updates. They use the daemon binary status snapshot when it is fresh; consult omg status or the native package manager when you need current counts. Run omg dash for a full-screen view.