[BUG] `gateway status` launches an extra gateway worker process

[drpedapati]

Problem

Running sciclaw gateway status starts a live gateway event loop instead of returning service state.

Impact

• Extra unmanaged gateway workers can run in parallel with launchd/systemd service.
• Discord responsiveness becomes inconsistent due to competing workers.
• Operators think they are running a read-only status check but actually mutate runtime state.

Expected

sciclaw gateway status should be a safe alias for sciclaw service status and must not start channels or agent loops.

Evidence

On data1, process list showed multiple sciclaw gateway status workers while the launchd gateway was already running.

Fix (implemented)

gateway status now delegates to service status and exits without launching gateway runtime.

[drpedapati]

Implemented in local branch feat/shared-workspace-policy with regression tests.

Code:

• cmd/picoclaw/main.go
• cmd/picoclaw/service_cmd.go
• cmd/picoclaw/service_cmd_test.go

Validation:

• go test ./cmd/picoclaw

[yofabr]

This is because..
When you run picoclaw gateway status, the CLI parses it as command="gateway", then passes the remaining args (["status"]) to gatewayCmd()

[nikolasdehor]

@yofabr identified the parsing issue correctly. The CLI dispatches 'gateway' as the command and passes ['status'] as args to gatewayCmd(), which then starts the full gateway runtime instead of treating 'status' as a subcommand.

The fix is straightforward -- add subcommand routing at the top of gatewayCmd() to intercept 'status' and delegate to serviceStatusCmd() instead of proceeding with the full gateway startup.

@drpedapati's branch (feat/shared-workspace-policy) has an implementation with tests -- is there a PR open for this? If not, it would be good to get one submitted since this is a footgun that can cause real issues (competing gateway workers, duplicate message delivery, resource contention).

One additional consideration: the extra gateway process started by 'gateway status' will also compete for the same port/socket that the real gateway uses. Depending on startup order, this could cause bind failures or split message routing. Worth adding a PID lockfile check at gateway startup to prevent this class of issues entirely -- something like:

func acquireGatewayLock() error {
    lockPath := filepath.Join(configDir, "gateway.lock")
    // Try flock, fail if another gateway is already running
}

This would protect against not just the 'gateway status' bug but any accidental double-start scenario (cron + systemd, multiple terminals, etc.).

[xiaket]

This has been long resolved by the cobra refactor #429. As of today, the behaviour looks like:

ubuntu@ubuntu:~/pico$ ./picoclaw gateway status
Error: unknown command "status" for "picoclaw gateway"
Usage:
  picoclaw gateway [flags]

Aliases:
  gateway, g

Flags:
  -d, --debug   Enable debug logging
  -h, --help    help for gateway