feat: label the bucket kind Object Storage, and follow the menu's order - #164
feat: label the bucket kind Object Storage, and follow the menu's order#164Fermionic-Lyu wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Reviewed by Wang Miao
This renames the storage kind's picker label to Object Storage and moves Empty Service up beside Docker Image in SERVICE_KINDS, with the parity test updated to the new sequence. I checked the claim against the dashboard: insta-frontend PR 343 (feat: group the add-service sources by what they get you, still open) is exactly what this mirrors — it relabels storage to Object Storage, recategorises compute into the code group beside Docker Image, and pushes Template into its own section, so the new CLI order and the new "Github Repo and Template are left out" comment both hold once that lands. No findings; approving.
Nothing else in the repo keys off these labels or their order — serviceKindLines() only pads them for display (Object Storage is exactly the 14-char pad width, so the column stays aligned), and the picker resolves on id, not label.
There was a problem hiding this comment.
No issues found across 2 files
You’re at about 94% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.
1bec801 to
16f06ad
Compare
The console's Add Service menu is this list's declared source of truth for order, labels and default names. It now labels the bucket source Object Storage -- the word the Usage tab already used, so it cannot read as disk -- and lists Empty Service beside Docker Image rather than last. The parity comment claimed one omission and had two; Template was never in this list either. Its stated reason for dropping Github Repo was also false: that lane is real (nixpacks server-side, see deploy.ts). Neither entry is a type-and-name create, which is the actual reason `insta services add` has no shape for them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
16f06ad to
2af66ba
Compare
There was a problem hiding this comment.
Reviewed by Wang Miao
This relabels the storage kind Object Storage and moves Empty Service up beside Docker Image in SERVICE_KINDS, with the parity test updated to the new sequence. Since my last round the only change to the code is one word in a comment (Template → View Templates); the rest of what arrived was main moving forward under the branch (the template-volume-boolean PR and the 0.0.53 bump), which does not touch this file. Approving — no findings, same as last round.
The parity claim now holds against a merged dashboard, not a pending one: insta-frontend PR 343 landed at 2026-08-31T20:49, and its add-service-button.tsx renders the menu as sourcesIn("code") → the Database submenu → sourcesIn("storage") → sourcesIn("bundle"), with compute recategorised to code and storage relabelled Object Storage. That renders as Github Repo, Docker Image, Empty Service, Postgres, Redis, MySQL, MongoDB, Object Storage, View Templates — this list exactly, minus the two the comment says are left out. The dialog placeholders (main-db, cache, mysql-db, mongo-db, assets, compute) are untouched there, so the defaultName parity test still matches too.
Nothing else in the repo keys off these labels or their order: the picker resolves on id, and serviceKindLines() only pads the label for display — Object Storage is exactly the 14-char pad width, so the column stays aligned rather than losing its separator.
Companion to InsForge/insta-frontend#343, which regroups the console's Add Service menu and relabels the bucket source.
SERVICE_KINDScarries a comment declaring "Same order, labels and default names as the dashboard's Add Service menu", and before #343 its list matched item for item. Two changes keep that true:Storage→Object Storage. The console'ssrc/lib/api/usage.tsalready used that word for this billing dimension, with the reason recorded there: it must not read as disk (volumekeeps the industry word). The Usage tab and invoice rows have said "Object Storage" all along; the pickers said "Storage".Display-only. Every lookup is by key, never position:
resolve-service.tsfinds byk.type === type && !k.needsImage(exactly one non-image kind per type, so first-match is unambiguous) and the picker resolves byk.id. The non-interactive path returns beforeSERVICE_KINDSis read at all.test/resolve-service.test.tspins the full label list and goes red on either drift — verified by mutating both back.Also fixed in the comment this PR exists to keep true:
src/commands/deploy.ts:37-39describes the GitHub-connected nixpacks lane as real and server-side, and:53tells users to use it. The omission is still right; the reason was not. Neither Github Repo nor Template is a type-and-name create, which is whyinsta services addhas no shape for them.npm run typecheck && npm testpass (47 files, 672 tests). The agent-facing mirror required by AGENTS.md #4 is InsForge/insta-skills#68 — that row also still said "four kinds", stale since redis/mysql/mongodb landed.Summary by cubic
Aligns the CLI's service kind list with the dashboard's Add Service menu: the bucket kind is now labeled
Object Storageinstead ofStorage, andEmpty Servicemoves up to sit besideDocker Image. This is display-only; lookups are by key, so no behavior changes. The parity comment now names both omitted kinds (Github Repo and View Templates) and the real reason they're omitted: neither is a type-and-name create, soinsta services addhas no shape for them.Written for commit 2af66ba. Summary will update on new commits.