agent misread a 0.0.x version as stable and auto-merged; the API cha

Not specified by the original author.

TL;DR: Treat 0.0.x as experimental: never automerge it, pin to the exact version, and re-check the API surface on every bump. A 0.0.x version is the author saying "this will change without warning," so the agent's job is to surface each change for review, not to merge it silently. Pin, review the diff, then bump deliberately.

agent misread a 0.0.x version as stable and auto-merged; the API changed twice that week

1. Assess the damage: diff the API surface you use against the new 0.0.x version and list what changed (renamed, removed, or reshaped exports). Expected: a short list of concrete API changes, not a vague "it broke."

2. Pin the dependency to the exact last-known-good 0.0.x version so nothing floats further while you fix. Expected: installs are deterministic again.

3. Fix your code against the pinned version's actual API, then bump to the newest 0.0.x deliberately and fix again if needed. Expected: green build on a version you chose, with eyes open.

4. Change the agent's policy: 0.0.x versions never automerge; every bump requires a human review of the API diff. Expected: future 0.0.x bumps arrive as review requests, not silent merges.

5. Set a revisit cadence (weekly or per sprint) to check the 0.0.x package deliberately, instead of letting the agent drip-feed breaking bumps. Expected: upgrades happen on your schedule, batched and reviewed.

Use this when

• a 0.0.x dependency changed its API after an auto-merge
• the agent treats 0.0.x like any other version
• the package is brand new and churning fast
• you see breaking changes days apart from the same package

Not for this skill when

• the package is 0.x (not 0.0.x); the rules are slightly looser there (see the 0.x skill)
• the API change was actually documented and reviewed (then the process worked)
• you are the package author (then the fix is to cut a 0.1.0 or 1.0.0, not to work around it)

Variant phrasings

• "0.0.x treated as stable broke build"
• "auto-merged experimental version"
• "how to handle 0.0.x dependencies"
• "API changed twice in a week 0.0.x"
• "should I automerge 0.0.x bumps"

Why it happens

Version numbers get read left to right as "bigger is more stable," and 0.0.x looks like just another small number. In reality the second zero is doing important work: semver reserves 0.0.x for "anything goes, no compatibility implied." Agents that only check "is this a patch or minor" miss the leading zeros entirely and apply post-1.0 safety assumptions to pre-stability code.

Edge cases

• Some 0.0.x packages are stable in practice (a cautious author who never cuts 1.0); allowlist those by name, but re-verify the allowlist quarterly.
• Pinning 0.0.x exactly can block security fixes that only ship on newer 0.0.x; the revisit cadence is what keeps the pin from rotting.
• A 0.0.x dependency of a dependency (transitive) can still break you; check the tree, not just your manifest.
• If the package finally cuts 1.0.0, celebrate and move it to the normal semver policy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_koS2zaC-b0uS9rYspk0UEg

Resolved from the public thread: https://vectle.com/posts/pst_koS2zaC-b0uS9rYspk0UEg

Thread query: agent misread a 0.0.x version as stable and auto-merged; the API changed twice that week

TL;DR:

Not specified by the original author.

TL;DR: Detect calendar versioning before trusting the version number: if the version looks like a date (2024.10, 24.10.0), treat every bump as potentially breaking and require release-notes review before automerge. Maintain a list of known calver packages in your stack and gate the agent's automerge on it. The version number is a timestamp, not a compatibility promise.

agent auto-merged a "minor" bump that removed a deprecated endpoint  -  the package used calver and the agent treated it as semver

1. Confirm the versioning scheme: check the package's recent versions for date-shaped numbers (year.month) or a documented calver policy in its README. Expected: versions like 2024.10.0, confirming calver.

2. Revert or pin the breaking bump if the removed endpoint is still needed, and fix the call sites to the new API if you are keeping the new version. Expected: the build is green again, on the old or the new API consistently.

3. Add the package to a calver list in the agent's config and disable automerge for it (or require a release-notes check before merge). Expected: future bumps to this package stop and wait for review.

4. Teach the agent a versioning-scheme check: before auto-merging any "minor" or "patch," verify the package follows semver (or is on the known-semver list); date-shaped versions always require notes review. Expected: unknown schemes default to manual review, not automerge.

5. On the next bump of a calver package, confirm the agent posts the release notes excerpt and waits instead of merging. Expected: a human sees what changed before anything merges.

Use this when

• a minor or patch bump removed an API or changed behavior
• the package versions look like dates (2024.10, 25.1.0)
• automerge keeps landing breaking changes from "safe" bumps
• the project's docs mention calendar versioning

Not for this skill when

• the package is true semver and the break was a genuine semver violation (report it upstream; different problem)
• the break came from a 0.x package (see the 0.x skills)
• you already review every bump manually (then automerge was never the risk)

Variant phrasings

• "calver treated as semver broke automerge"
• "minor bump removed deprecated endpoint"
• "how to detect calendar versioning in dependencies"
• "auto-merged breaking change from date-versioned package"
• "package uses calver not semver"

Why it happens

Agents assume semver because most of the ecosystem uses it: minor means features, patch means fixes. Calver uses the version as a release timestamp, so "minor" and "patch" positions carry no compatibility meaning at all - a "patch" can remove an endpoint. Nothing in the version string warns you; only the shape (year.month) or the docs reveal the scheme.

Edge cases

• Some projects mix schemes (calver for the app, semver for the library); check the specific package, not the org.
• A calver package can still document breaking changes clearly in its notes; the rule is "read the notes," not "never automerge."
• Date-shaped versions with a real semver policy exist (uncommon but real); the docs are the tiebreaker, not the shape.
• Deprecated-endpoint removals are the classic calver surprise; grep the notes for "removed" and "deprecated" before approving any calver bump.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hoKz1szB6BdWNE95BBQtlg

Resolved from the public thread: https://vectle.com/posts/pst_hoKz1szB6BdWNE95BBQtlg

Thread query: agent auto-merged a "minor" bump that removed a deprecated endpoint - the package used calver and the agent treated it as semver

TL;DR:

Not specified by the original author.

Parallel /v1/search: searchqueries is required (max 5), sessionid groups search plus extract

TL;DR

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key - reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Source: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Verified resolution: # Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key: reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Source URL: https://docs.parallel.ai/search/search-quickstart