feat(template): leave service types and fields to the platform, show buckets and the Postgres major

[CarmenDou]

What

insta template deploy ./dir and insta template deploy <github-url> no longer refuse a service type or a field the CLI does not know. The platform is the only authority on them, so an old CLI never blocks a manifest a newer platform accepts. insta template info now shows a database's Postgres major (db (postgres 17)) and whether a bucket is public (assets (storage, public) or (storage, private)). The --region help says a storage bucket has none.

Spec: docs/superpowers/specs/2026-10-05-template-service-definition-v1-design.md in the insta-cloud superproject (section 5, decision 4). Merge after the platform change (InsForge/instacloud-platform#625) is live in production. Skills gets its CLI version floor from the release cut after this merges.

How

• validateManifest drops the type list and the bare-field list. A service whose type is not web or worker is skipped, fields and env included. It still checks the YAML parse, code and version, the compute rules for web and worker, the env and generator references, and the two authoring lints (pinned images, described required variables).
• The ${services.<x>.url} check stays for postgres, redis, mysql and mongodb, the four types the CLI has always known. storage is left to the platform on purpose, because a public bucket may get an address later.
• normalizeInfoServices carries pgVersion and public when they are the right kind of value. templateInfoLines prints them through one small infoKind helper.
• The request code is unchanged: the CLI already sent the parsed manifest as written.
• insta template deploy prints one line per public bucket after the accepted deploy line (files: public bucket, anyone can read its files (anonymous public-read)). A gated or refused deploy prints nothing, and --json stays one document.
• No new command or flag, so there is no MCP tool to add.

Verify

• node_modules/vitest/vitest.mjs run test/template.test.ts test/github-source.test.ts passes. New cases cover a public bucket and a pgVersion passing locally, an unknown service key and an unknown type passing locally, the manifest reaching the POST body verbatim, and the template info lines.
• tsc -p tsconfig.json --noEmit is clean and the full vitest suite passes (Node 20.20.2).

🤖 Generated with Claude Code

---

Summary by cubic

Keeps insta template deploy and insta template info usable against a platform that accepts more service types than the CLI knows. The local validator no longer rejects unknown types or fields — the platform is the only authority — and the info view now shows a database’s Postgres major and whether a bucket is public.

insta template deploy also prints one line per public bucket after the accepted deploy line, so no bucket is opened anonymously without the deployer being told. --json stays one document and gated or refused deploys stay silent.

This depends on the platform change (InsForge/instacloud-platform#625) being live in production before merging. No new command or flag, so no MCP tool to add.

^{Written for commit 4e2051d. Summary will update on new commits.}

[jwfing]

Summary

The change implements the stated behavior cleanly, with focused coverage and no blocking correctness, security, or performance issues found.

Requirements context

I assessed the PR against its title and description, the repository’s AGENTS.md, and .claude/skills/developing-insta-cli/SKILL.md. The referenced superproject design document and platform PR were not available in this checkout and could not be fetched, so their additional details could not be independently verified; the stated requirement to merge only after platform PR #625 is live remains an operational merge prerequisite.

Findings

Critical

(none)

Suggestion

(none)

Information

• Software engineering/functionality: validation now limits CLI-owned service rules to web and worker while preserving the known datastore URL/host check, matching the described authority boundary (src/template-manifest.ts:113-217). Tests cover unknown types and fields, verbatim POST payloads, both info-service shapes, all three deployment sources, JSON suppression, and approval-gated output (test/template.test.ts:106-203, test/template.test.ts:418-497, test/template.test.ts:709-782).
• Security: no authentication or authorization path is weakened, and the new output exposes only service names and declared bucket access—not variables, credentials, or manifest contents. Platform validation remains the request boundary (src/commands/template.ts:420-450).
• Performance: normalization and disclosure add only linear passes over the template’s service collection, with no new I/O, dependency, or hot-path concern (src/commands/template.ts:48-59, src/commands/template.ts:91-96).
• Verification: git diff --check main...HEAD passes. The declared typecheck and test commands could not run because this checkout has no installed TypeScript/Vitest dependencies (package.json:35-42).

Verdict

Approved—no critical findings. This should be posted as a non-blocking review comment rather than a GitHub green-check approval.

[cubic-dev-ai]

1 issue found across 4 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/template-manifest.ts">

<violation number="1" location="src/template-manifest.ts:135">
P2: A service without a `type` now passes local validation because this branch continues when `type` is undefined. Add a missing-type error before skipping unrecognized types so incomplete manifests still fail locally.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Turn on auto-fix | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: A service without a type now passes local validation because this branch continues when type is undefined. Add a missing-type error before skipping unrecognized types so incomplete manifests still fail locally.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At src/template-manifest.ts, line 135:

<comment>A service without a `type` now passes local validation because this branch continues when `type` is undefined. Add a missing-type error before skipping unrecognized types so incomplete manifests still fail locally.</comment>

<file context>
@@ -128,31 +131,8 @@ export function validateManifest(m: TemplateManifest): string[] {
-      continue
-    }
+    // Every other type, and every field and env on it, is the platform's to judge. It answers 400 with its own list.
+    if (!type || !COMPUTE_TYPES.includes(type)) continue
     if (svc.image && svc.build) problems.push(`${where}: image and build are mutually exclusive`)
     if (!svc.image && !svc.build) problems.push(`${where}: one of image or build is required`)
</file context>

Suggested change

	if (!type || !COMPUTE_TYPES.includes(type)) continue
	if (svc.type === undefined) {
	problems.push(`${where}.type is required`)
	continue
	}
	if (!type || !COMPUTE_TYPES.includes(type)) continue

[jwfing]

LGTM - approved.