Conversation
added 2 commits
September 22, 2026 05:49
… (task #167, #175) Three agent-login manifest actions for surfaces that had a worker endpoint but no action, so an agent had to fall back to the generic CLI escape hatch or could not do the job at all: list-builds GET /api/apps/{app_id}/builds (task #167 second half) update-channel PATCH /api/apps/{app_id}/channels/{channel_id} (task #175) delete-channel DELETE /api/apps/{app_id}/channels/{channel_id} (task #175) All three endpoints already exist and are unchanged; this only declares them. update-channel declares the SIX body fields handleUpdateChannel reads (name, bundle_id, password, git_url, enabled_product_types, metadata) and the "nothing to update" rejection. Declaring fewer would hide settable fields from callers. The actions use `parameters`, the key the Raft-side parser actually reads (slock packages/cli/src/commands/integration/manifest.ts:72,:297). `create-channel` uses a `params` key that the parser ignores, so its slug/name are not resolvable for invoke; that pre-existing defect is left alone here rather than changed in passing. They are registered in NEW_ACTIONS. That set gates the migration nudge prepended to every EXISTING action; without registration a brand-new action would ship labelled "Deprecated", which is exactly the wrong label. Registration says nothing about their stability. Tests assert each action is present, is not prefixed Deprecated, maps to the endpoint the worker serves, declares the fields the handler reads, and uses `parameters` rather than `params`. Mutation-checked: removing a name from NEW_ACTIONS fails the prefix assertion, and switching an action to `params` fails the key assertion. Signed-off-by: Volta <volta@mail.build>
…ew of #545) CHANGES from @XX's contract review of 2c0caf4: - `update-channel.enabled_product_types`: `string[]` -> `array`. `invoke` treats only `array` and `object` as structured types (slock commands/integration/invoke.ts:308-316), so `string[]` is not recognised and the value is lost. The handler reads `string[]` (channels.ts:81); the manifest label is a separate vocabulary. - `update-channel.metadata`: `string` -> `object`, same failure shape. The handler reads `Record<string, unknown>` (channels.ts:82). - Tests assert those two labels, not just the field names. Verified red-first: reverting the labels fails with `expected 'string[]' to be 'array'`, so the assertion catches exactly this defect. Also, non-blocking review points: - `list-builds` description now states the viewer requirement (index.ts:834) and the 200 cap (builds.ts:629). - The `NEW_ACTIONS` comment is written as an explicit decision (provenance, not stability). worker: 655 passed (61 files). Signed-off-by: Volta <volta@mail.build>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three agent-login manifest actions for surfaces that already had a worker endpoint but no action.
list-buildsGET /api/apps/{app_id}/buildsupdate-channelPATCH /api/apps/{app_id}/channels/{channel_id}delete-channelDELETE /api/apps/{app_id}/channels/{channel_id}All three endpoints already exist and are unchanged. This only declares them.
Contract points for review (@XX)
parameters, notparams. The Raft-side parser readsparametersonly(
slock packages/cli/src/commands/integration/manifest.ts:72,:297).create-channeluses a
paramskey the parser ignores, so itsslug/nameare not resolvable forinvoke. That pre-existing defect is left alone here.invokerecognises. Onlyarrayandobjectcountas structured types (
slock .../integration/invoke.ts:308-316).update-channeldeclaresenabled_product_typesasarrayandmetadataasobject, matching whathandleUpdateChannelreads (channels.ts:81-82).update-channeldeclares six body fields —name,bundle_id,password,git_url,enabled_product_types,metadata— plus its "nothing to update" rejection (:111).delete-channelstates the refusal when builds or releases still reference the channel(
channels.ts:143-146).list-buildstakes the four query filtershandleListBuildsreads (builds.ts:597-600),returns
{ builds: [...] }, requires app viewer (index.ts:834) and caps at 200 (builds.ts:629).NEW_ACTIONSas an explicit decision: membership is about provenance(added after the migration), not stability.
Review round
Contract review by @XX (CHANGES on
2c0caf4d); all four points addressed in2d24eed:enabled_product_types:string[]->array(not a recognised structured label)metadata:string->object(same failure shape)expected 'string[]' to be 'array'.list-buildsdescription states the viewer requirement and the 200 cap; theNEW_ACTIONScomment is written as an explicit decision.
Raft thread:
#proj-hands:fde27d5b— review requestc36b7c86, CHANGES replyc9ef2cef.Not done here
create-channel's existing entry.worker: 655 passed (61 files) · 7/7 on the touched manifest test.