[OMEGA-181] System Versioning

[blackhammer116]

Description

This PR adds a version command to the OmegaClaw launcher script.

Users can now retrieve the local OmegaClaw version directly from the command line using:

scripts/omegaclaw --version

or:

scripts/omegaclaw -v

The version is resolved from the local Git repository in the following order:

1. The nearest reachable Git tag from the current checkout.
2. The latest available local tag sorted by version.
3. The current short commit hash if no tags exist.
4. OmegaClaw unknown if no Git metadata is available.

Changes

• Added a version() helper function to scripts/omegaclaw.
• Added support for --version and -v in the command dispatcher.
• Added --help as an alias for -h.
• Updated help output to document the new version option.

Closes #62

How Has This Been Tested?

Tested manually with:

scripts/omegaclaw --version
scripts/omegaclaw -v
scripts/omegaclaw --help

Expected version output format:

OmegaClaw vX.Y.Z

If no tag is available, the script falls back to the current commit hash.

Checklist

• The code generated by LLM is reviewed by the PR creator
• Self-review completed
• Test scenarios above are passed with the version of the code from PR

[TossSky]

Tested. Version resolves in Docker (as nobody) and standalone, --version/-v/--help and the in-chat version command all work. The startup version message now fires exactly once.

One caveat: it's not guaranteed to be the first message. The send is gated on readyToSend and skipped on the first iteration when the async channel join hasn't completed, so an LLM status line can go out ahead of it. If strict first-message ordering is required, block until the channel is ready before the first cycle instead of skipping.

Merge conflict is trivial: only src/channels.metta. main moved the search def into skills.metta where this branch added readyToSend in its place. Keep readyToSend, drop the old search block.

[vsbogd]

1. For the sake of this small feature, the PR adds an entire new function to the communication channels API, plus state for storing a parameter indicating whether we've sent the version or not. This adds conflicts with OMEGA-161, and if we merge this, it will need to be reworked right away in the near future. We need to rework it before merge.

2. Even though some infrastructure for adding the version to Docker has been put in place, the Docker images that will be created during the release will not contain the version, because it needs to be specified in the Docker build parameters. This is a problem for people who build the Docker image manually because they need to remember about it. For this version to appear in the release build, a CI change is also required (and testing of the release procedure, of course).

Bottom line: I don't think we can merge and test it today.

[vsbogd]

1. For the sake of this small feature, the PR adds an entire new function to the communication channels API, plus state for storing a parameter indicating whether we've sent the version or not.

@blackhammer116 I see why it is needed in fact, I just think the proper way is to change code of the communication channels to be more reliable in this sense. I.e. start_xxx function should wait while connection to the remote endpoint is established or send_message should put message into a queue and wait while communication channel is ready before sending it. I don't think using readyToSend from loop.metta is a proper way of solving this. In fact there are situation when this will not work. For example connection state is changed between readyToSend and send_message calls.

[vsbogd]

My suggestion about this PR. We have two tasks here:

1. To form version which can be show to the user when Docker image is built.

(a) We are able to show version when user runs standalone application using local Git repo. Current way of getting version seems working and reliable. (b) Second case we need to cover is Docker image where local Git repo index is absent. In such case we could save the version on the Docker image building stage. But this PR proposes passing it via arguments which adds the burden of specifying the argument. I suggest getting the version from the Git tree inside Dockerfile script. The simplest way is adding:

RUN git describe --tags >${OMEGACLAW_DIR}/version

But to make it equal to the version from standalone deployment I suggest rewrite Python function omegaclaw_version() to do the following: run git describe ... and return this version if command returned it, use version file in the root of the repo as a fallback. Then import this function inside omegaclaw script and inside Dockerfile to write the version into the file. Thus the only function omegaclaw_version() is used to prepare Docker image to show version from the command line, return it via OmegaClaw skill or to send it at the beginning of the session.

2. To ensure version sent via communication channel is delivered to the user.

I would suggest fix it in the communication channel plugins. The issue that message is not delivered when communication channel is not started affects the OmegaClaw right now. And also it can be triggered by temporary broken connection. The proper solution I see is to add the list of messages to be sent (similarly to the read_buffer we already have) and sent them to the user when connection is broken. This approach is already is implemented by wschat.py.

Another options which is more aligned with the current IRC/Telegram/Mattermost channels plugin design is to wait for _connected flag is set with some timeout instead of just skipping sending the message to the user.

Slack plugin doesn't skip the message if _connected flag is not set it sends its anyway thus I think Slack should be immune (to some extend) to this issue.

I would prefer this (2) part of the work is done under a separate PR. It should be done and merged first and after that we can proceed with changes for the part (1).