fix(template): mirror the platform's portless worker rules locally

[CarmenDou]

What

insta template deploy ./dir validates a local insta.template.yaml before anything travels. With insta-platform#490 the platform accepts type: worker and deploys it as a portless (port: 0) service, and it refuses three shapes that contradict that. This PR says the same three things locally:

• port on a worker: a worker has no routed port
• healthcheck on a worker: a worker has no HTTP endpoint to probe, its health is the machine's state
• alwaysOn: false on a worker: a worker cannot scale to zero, nothing would wake it

A bare worker (type: worker + image) passes as before, alwaysOn: true too.

How

src/template-manifest.ts is the twin of the platform's templateManifest.ts. The three checks land next to the existing port and healthcheck rules, with the platform's messages verbatim. alwaysOn is added to ManifestService, the postgres bare-shape rule already read it through a string list.

The twin does not validate ${services.<name>.url|host} references at all today, so the platform's fourth rule (nothing may reference a worker's address) stays server-side, as the other reference rules already do.

No behavior change for by-code deploys or for insta template deploy <github-url> beyond the same local check. No release is needed for this alone, it rides the next CLI release.

Verify

• npm run typecheck passes.
• npx vitest run: 1710 passed, 84 files.
• New case in test/template.test.ts: "a worker is portless" covers the three refusals and the two accepted shapes.

Companion: https://github.com/InsForge/instacloud-platform/pull/490 (platform, merge and deploy first).

🤖 Generated with Claude Code

---

Summary by cubic

Fixes local template validation to match the platform's portless worker rules, so authors hear about invalid worker shapes before upload. Workers are now refused if they define a port, a healthcheck, or alwaysOn: false — they deploy as port-0 services with no routed port, no HTTP endpoint, and cannot scale to zero. Bare workers and alwaysOn: true pass as before; no behavior change for other deploy paths.

^{Written for commit 11e4d1c. Summary will update on new commits.}

[jwfing]

Summary

The focused validator change correctly mirrors the stated portless-worker behavior and includes appropriate regression coverage.

Requirements context

The intent was derived from the PR description and the validator’s documented role as the local twin of the platform manifest validator (src/template-manifest.ts:1-7). No additional in-repository manifest specification was found, and the linked private platform PR was unavailable from this environment, so the three rules stated in the PR description were treated as authoritative: workers must reject port, healthcheck, and alwaysOn: false, while accepting an omitted value or alwaysOn: true. This is not a command or flag change, so the CLI-reference update requirement does not apply.

Findings

Critical

(none)

Suggestion

• The tests match only fragments of the three errors (test/template.test.ts:216-223). Because the implementation claims to mirror the platform’s messages verbatim, consider asserting the complete strings so message drift is caught. This is non-blocking because all required behaviors are exercised.

Information

• Functionality: the validator rejects all three contradictory worker fields while continuing to accept bare workers and alwaysOn: true (src/template-manifest.ts:157-168, test/template.test.ts:216-223). Adding alwaysOn to the manifest type also aligns the declared shape with the new check (src/template-manifest.ts:28-33).
• Software engineering: the change follows the existing pure-validator structure and keeps the platform-specific rules together. git diff --check passed. Typecheck and tests could not be rerun because node_modules is absent and this read-only review could not install dependencies.
• Security: no security-relevant changes; the added logic only examines already-parsed manifest fields and produces validation errors (src/template-manifest.ts:160-165). It introduces no SQL, shell, HTTP, authentication, logging, secret, or dependency changes.
• Performance: no performance concerns; the change adds three constant-time checks within the existing per-service validation pass (src/template-manifest.ts:160-165).

Verdict

Approved — no Critical findings. Per the review-bot policy, this should be posted as a non-blocking comment rather than a GitHub green-check approval.

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}