Description
Three small housekeeping items, unrelated except that they're all leftovers. Fine to split or cherry-pick.
1. output.zip is an empty tracked file
output.zip sits at repo root at 0 bytes, tracked since the Copybara import (5f2c0ee, 2026-01-21). It's never referenced by the build, workflows, or generator config. Delete it.
2. .gitignore rules for .speakeasy are dead and misleading
# Speakeasy generation artifacts (generated in OSS repo, not here)
.speakeasy/*.lock
.speakeasy/*.openapi.yaml
All four files those patterns name are tracked: .speakeasy/gen.lock, .speakeasy/workflow.lock, .speakeasy/in.openapi.yaml, .speakeasy/out.openapi.yaml. .gitignore has no effect on already-tracked paths, so the rules do nothing except imply the files aren't in the repo — and the comment ("generated in OSS repo, not here") reads like it was copied from the monorepo, where it was true.
This repo is the OSS repo, and those files are legitimately committed here (out.openapi.yaml is the generation input of record). Either drop the two patterns, or keep them and fix the comment to say why they're overridden. Dropping them is the honest fix.
3. POST /messages is fully specced but excluded from the SDK
In .speakeasy/out.openapi.yaml, /messages (operationId: createMessages, ~200 lines of request/response schemas including streaming) carries x-speakeasy-ignore: true. The result:
- No
client.messages in the generated SDK.
- The component models still generate —
messagesrequest.py, messagesmessageparam.py, messagestooladditionblock.py, etc. are all in src/openrouter/components/. So we ship the types for an endpoint the client can't call.
- The
Anthropic Messages tag stays in the spec's global tags: list with zero operations attached to it.
- The operation still carries
x-speakeasy-name-override: 'create', which is dead while x-speakeasy-ignore is set.
Worth confirming the exclusion is deliberate — closed #64 treats /api/v1/messages as a real, supported endpoint. If it is deliberate, drop the now-dead x-speakeasy-name-override and the orphaned global tag entry (or add a comment/overlay noting why the operation is held back). If it isn't, removing x-speakeasy-ignore should light up client.messages with models that already exist.
Description
Three small housekeeping items, unrelated except that they're all leftovers. Fine to split or cherry-pick.
1.
output.zipis an empty tracked fileoutput.zipsits at repo root at 0 bytes, tracked since the Copybara import (5f2c0ee, 2026-01-21). It's never referenced by the build, workflows, or generator config. Delete it.2.
.gitignorerules for.speakeasyare dead and misleadingAll four files those patterns name are tracked:
.speakeasy/gen.lock,.speakeasy/workflow.lock,.speakeasy/in.openapi.yaml,.speakeasy/out.openapi.yaml..gitignorehas no effect on already-tracked paths, so the rules do nothing except imply the files aren't in the repo — and the comment ("generated in OSS repo, not here") reads like it was copied from the monorepo, where it was true.This repo is the OSS repo, and those files are legitimately committed here (
out.openapi.yamlis the generation input of record). Either drop the two patterns, or keep them and fix the comment to say why they're overridden. Dropping them is the honest fix.3.
POST /messagesis fully specced but excluded from the SDKIn
.speakeasy/out.openapi.yaml,/messages(operationId: createMessages, ~200 lines of request/response schemas including streaming) carriesx-speakeasy-ignore: true. The result:client.messagesin the generated SDK.messagesrequest.py,messagesmessageparam.py,messagestooladditionblock.py, etc. are all insrc/openrouter/components/. So we ship the types for an endpoint the client can't call.Anthropic Messagestag stays in the spec's globaltags:list with zero operations attached to it.x-speakeasy-name-override: 'create', which is dead whilex-speakeasy-ignoreis set.Worth confirming the exclusion is deliberate — closed #64 treats
/api/v1/messagesas a real, supported endpoint. If it is deliberate, drop the now-deadx-speakeasy-name-overrideand the orphaned global tag entry (or add a comment/overlay noting why the operation is held back). If it isn't, removingx-speakeasy-ignoreshould light upclient.messageswith models that already exist.