fix: drop acceptTerms from workspace create body - #10
Merged
Conversation
The POST /v1/workspaces body schema is now a strictObject without acceptTerms (coreplanelabs/nominal#465), so sending the field returns a 400 unknown-key error. Creating a workspace is itself the acceptance and the server records it. Build the body as a direct object literal typed against the generated params, matching every other command. The previous indirection through a variable defeated TypeScript's excess-property check, which is why CI never flagged the stale field. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017YKtZtLLwdxPyh11L5J8BU
boristane
approved these changes
Aug 3, 2026
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
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.
Requested by boris · Slack thread
Before / After
Before:
polylane workspace createsent anacceptTerms: truefield in thePOST /v1/workspacesbody. The API no longer accepts that field — coreplanelabs/nominal#465 replaced the body schema withzCreateWorkspace, az.strictObject, so any unknown key is rejected. Once that change deploys, everyworkspace createfrom the CLI fails with a 400 unknown-key error.After: the command sends only the workspace name (plus the optional
--description/--slug). Creating the workspace is the acceptance, and the server records it. The stderr notice — "By creating a workspace you accept the Polylane Terms of Service: …" — is unchanged and is now a more accurate description of what happens than it was before.Why CI didn't catch this. The body was routed through an intermediate variable before being assigned to the typed parameter:
TypeScript's excess-property check only fires on a fresh object literal assigned directly to the annotated target. Going through
withTermsmade the assignment an ordinary structural check, which silently tolerates extra properties — so the stale field survived every codegen + typecheck run. The fix restores a direct literal, so the next time the spec drops or renames a field the build fails instead of shipping a 400.How
src/commands/workspace/create.tsnow declares a module-leveltype CreateWorkspaceBody = Parameters<PolylaneAPI['workspacesPost']>[0]— the same pattern asautomation/create.ts,integration/connect.ts, andcloud/connect.ts— and builds the body asconst body: CreateWorkspaceBody = { name }. TheacceptTermsfield and the comment justifying the indirection are gone. A repo-wide grep confirms no other reference toacceptTerms(no tests, docs, orskill/SKILL.mdmention it).Merge ordering — read before merging
This must merge after coreplanelabs/nominal#465 deploys to the API that
npm run codegenreads (https://api.polylane.com/v1/doc).At the time this PR was written the live spec still declared
acceptTerms: trueas required:so
npm run typecheckfails on this branch with:That error is expected and self-clearing: it disappears the moment the deploy lands and codegen picks up the new spec. Re-run CI after the deploy rather than working around it. Lint (clean), tests (117/117 pass), and build (
dist/polylane.mjs, 430.5 KB,--versionOK) all pass now.Unrelated pre-existing failure, noted for the record:
mainis already red onsrc/commands/feed/list.ts:89— the CLI's--categorylist includesinvestigation,anomaly,chat,alert, anddeploy, which the livefeed.listspec no longer accepts. That is separate spec drift and out of scope here; worth its own fix.Does this need a new CLI release?
Yes. This fix does not help anyone who has already installed the CLI. Published
v0.2.1and every prior version sendacceptTermsand will start returning 400 onworkspace createthe moment nominal#465 deploys, regardless of what lands onmain. A release is the only thing that reaches users.Cutting one is a single command from a clean
main(seerelease.sh):It bumps
package.json, runs typecheck + lint + test + build, commitschore: release v0.2.2, tagsv0.2.2, and pushes branch + tag. Thev*tag fires.github/workflows/release.yml, which re-runs the full check matrix (Node 20/22/24) and then publishes to npm with provenance, creates the GitHub Release withpolylane.mjsattached, and bumps thecoreplanelabs/homebrew-tapformula. The curl and PowerShell installers pull from the GitHub Release, so all install channels update from that one tag.Suggested sequence: deploy nominal#465 → merge this PR →
./release.sh 0.2.2.Refs coreplanelabs/nominal#465
Generated by Claude Code