[MattDHill]

A daemon ready check that isn't satisfied yet now returns starting instead of loading, in the Postgres sidecar's pg_isready check.

loading means operational but catching up, and start-sdk's default trigger re-polls it every 30 s. A sidecar that reported loading on an early probe therefore held every daemon requiring it for up to 30 s after it was ready. starting is re-polled every second. The pattern came from the packaging guide's Postgres example, corrected in Start9Labs/start-technologies#4272. Start9Labs/start-technologies#4273 makes the SDK back off loading instead, for packages that don't change.

Beta serves 1.163.0:0, so this bumps to 1.163.0:1 with the release note "Performance improvement". 1.163.0:0 carries the homeserver.yaml migration, so it moves to versions/v1.163.0_0.ts and joins other in the version graph.

Per helix-a's review, 1.163.0:1 declares no down migration. With down: IMPOSSIBLE, StartOS would have refused to roll back to 1.163.0:0, though nothing on disk differs between them.

Verified: tsc --noEmit, Prettier and make javascript/index.js pass. Not installed on a box.

🤖 Generated with Claude Code

[helix-a]

The starting readiness result is correct, and the historical migration is preserved unchanged. One regression needs fixing before merge:

[P2] Preserve downgrade compatibility in startos/versions/current.ts. Adding down: IMPOSSIBLE changes canMigrateTo to =1.163.0:1, so after installing this performance-only update StartOS refuses rollback even to 1.163.0:0. Neither the image nor data format changes. Omit down and its unused import, preserving the existing no-op downgrade behavior. I reproduced the restricted graph on the PR head; the proposal restores >=1.156.0:0 && <=1.163.0:1, also confirmed in the returned package manifest.

The proposal additionally completes the lockfile's missing bundled start-core entries: npm install rewrote it once, and a second install left it unchanged. No dependency pins change.

Verification: clean merge-tree against origin/master; SDK 3.0.6 matches npm latest; tsc --noEmit, changed-file and full startos Prettier checks, rollback-range assertion, and make synapse.s9pk pass on the proposal. Inspected the returned .s9pk manifest. No runtime installation or startup timing measurement performed.

Proposed changes: 928012d...proposal/101

Helix-Harness: pi
Helix-Model: openai-codex/gpt-6.1-sol

[helix-a]

The rollback regression is fixed, and the lockfile is normalized. Head 1434bd2 is tree-identical to the proposal I already verified, so the prior typecheck, Prettier checks, rollback-range assertion, full package build, and returned-manifest inspection apply unchanged.

Rechecked merge-tree against current origin/master: clean. SDK 3.0.6 still matches npm latest. Both x86 and arm CI builds passed; DiscoverMatrix passed and the separate Retarget Build check was skipped. No remaining findings. Runtime startup timing has not been measured.

Helix-Harness: pi
Helix-Model: openai-codex/gpt-6.1-sol