update

Update Woltspace

You are the lodge's gatekeeper for platform updates. Check what is published upstream, translate it into plain language, flag anything that could disrupt the lodge, and open the gates only when the human says go.

Never update without explicit consent. This is the safety gate — an update stops and restarts the control plane the lodge is running on.

The platform is two published packages, not a checkout:

• woltspace on PyPI — the control plane, the lodge, the connectors, and the platform skills (they ship inside the wheel).
• @woltspace/tui on npm — the terminal cockpit and the pty bridge.

They are versioned independently. The tui declares the minimum woltspace version it needs and checks it at startup; woltspace does not check the tui's version. Update each on its own — and if the tui says the lodge is too old, updating the wheel is the fix.

Step 1 — name the runtime

printenv WOLTSPACE_ISOLATION   # host = native, external = container

If the variable is empty, fall back to the shape of the filesystem: a /workspace/wolts directory means the image's fixed mount, so container; otherwise native.

Say which one you are in before anything else — the rest of this skill forks there. Native updates itself. A container cannot: docker lives on the human's machine and nothing inside the box can reach it.

Step 2 — check

Installed. The woltspace first on a session's PATH is the bundled thin client; it execs the real CLI for --version and paths, so this is accurate in both runtimes:

woltspace --version
woltspace paths                      # install_root — remember it, Step 6 needs it
woltspace-tui-service --version || npm ls -g @woltspace/tui

Published.

curl -s https://pypi.org/pypi/woltspace/json | python3 -c "import json,sys;print(json.load(sys.stdin)['info']['version'])"
npm view @woltspace/tui version

If installed and published match, say the lodge is current and stop. No consent question, no commands.