Add sc start and sc stop, and show deployment state in sc apps #24

Merged

geusebio merged 2 commits from feature/start-stop-verbs into main

2026-08-14 18:08:55 +00:00

geusebio commented

2026-08-14 17:49:03 +00:00

Owner

The CLI half of the tray story: sc grows the two switch verbs, and sc apps says what state each deployment is in. Needs scclient #2 (pinned here as a pseudo-version and vendored) and the platform's listing change.

`sc start` / `sc stop`

Both address a deployment by name, resolved exactly as deploy resolves it — positional argument, then deployment: in .sc.yml, then the slugified branch — so switching the branch you are standing on off and back on takes no arguments:

sc stop                 # tear down what this branch has running
sc start                # put it back, following it until it's running
sc start staging -d     # another deployment, without waiting

Nothing is uploaded and nothing is rebuilt: stop leaves the images in the registry, start puts the same ones back up.

start follows what it dispatched. The platform answers 202 "queued", and the question a person asked is "is it up?" — so unless --detach, it attaches to the same progress stream sc deploy watches and exits non-zero unless the revision reached running.

A refused start says where to go. Activation is credit-gated, so a 402 prints the balance and the billing page rather than just the refusal.

`sc apps`

Each deployment row now carries the status of the revision speaking for it, and that revision's number:

grey-ooo  (owner)
└── test-webserver  (seq 1)
    └── main  running (#1)

Verified

Against a live platform dev stack — the transcript in the platform PR is this binary. go build, go vet, gofmt, go test ./... clean, vendored (GOWORK=off go test ./... passes offline, which is what CI runs). New toggle_test.go covers accepted/detached, following to success, following to failure, the 402 with its balance, an ordinary 409, an ambiguous slug, a platform too old for the route, and a missing token.

The CLI half of the tray story: `sc` grows the two switch verbs, and `sc apps` says what state each deployment is in. Needs [scclient #2](https://git.grey.ooo/Grey.ooo/someones.computer_scclient/pulls/2) (pinned here as a pseudo-version and vendored) and the platform's listing change. ## `sc start` / `sc stop` Both address a deployment **by name**, resolved exactly as `deploy` resolves it — positional argument, then `deployment:` in `.sc.yml`, then the slugified branch — so switching the branch you are standing on off and back on takes no arguments: ``` sc stop # tear down what this branch has running sc start # put it back, following it until it's running sc start staging -d # another deployment, without waiting ``` Nothing is uploaded and nothing is rebuilt: stop leaves the images in the registry, start puts the same ones back up. **`start` follows what it dispatched.** The platform answers `202` "queued", and the question a person asked is "is it up?" — so unless `--detach`, it attaches to the same progress stream `sc deploy` watches and exits non-zero unless the revision reached `running`. **A refused start says where to go.** Activation is credit-gated, so a `402` prints the balance and the billing page rather than just the refusal. ## `sc apps` Each deployment row now carries the status of the revision speaking for it, and that revision's number: ``` grey-ooo (owner) └── test-webserver (seq 1) └── main running (#1) ``` ## Verified Against a live platform dev stack — the transcript in the platform PR is this binary. `go build`, `go vet`, `gofmt`, `go test ./...` clean, vendored (`GOWORK=off go test ./...` passes offline, which is what CI runs). New `toggle_test.go` covers accepted/detached, following to success, following to failure, the 402 with its balance, an ordinary 409, an ambiguous slug, a platform too old for the route, and a missing token.

geusebio added 1 commit

2026-08-14 17:49:03 +00:00

Add sc start and sc stop, and show each deployment's state in sc apps

CI / build (pull_request) Successful in 1m46s

Details

2ec9a79870

The two switch verbs the platform has been able to answer since the tray
plan's phase 1. Both address a deployment by name, resolved exactly as
`deploy` resolves it — argument, then `.sc.yml`, then the slugified branch —
so switching the branch you are standing on off and back on takes no
arguments at all.

Nothing is uploaded and nothing is rebuilt: stop tears the stack down and
leaves the images in the registry, start puts the same ones back up. `start`
then follows the revision it dispatched through the progress stream `deploy`
already watches, because the platform answers "queued" and the question a
person asked was "is it up?". --detach stops at the 202.

A refused start is the one refusal with a way out of it, so it prints the
balance and the billing page rather than just the sentence.

`sc apps` gains the status and revision number per deployment, which the
listing now carries.

geusebio added 1 commit

2026-08-14 18:06:54 +00:00

Pin scclient to the merged contract commit

CI / build (pull_request) Successful in 1m46s

Details

e15deb3fa0

geusebio changed title from ~~WIP: Add sc start and sc stop, and show deployment state in sc apps~~ to Add sc start and sc stop, and show deployment state in sc apps

2026-08-14 18:07:24 +00:00

geusebio merged commit 69d8d6fc44 into main

2026-08-14 18:08:55 +00:00

geusebio referenced this pull request from a commit

2026-08-14 18:08:56 +00:00

Add sc start and sc stop, and show deployment state in sc apps (#24)