[nebula-sdk-bot]

Automated SDK regeneration.

Source: zeroset-inc/nebula@fca50a0
Generator: nebula-sdks/generator (@workos/oagen-backed)
Bump type: fix (drives release-please's next version)

Review the diff carefully — this is a release artifact. The in-tree
pyproject.toml version is 0.0.0+from-source; release-please
owns the published version.

[zeroset-agent]

Zero Review - 2 findings shown inline.

4,662,532 tokens used (4,629,100 prompt / 33,432 completion; 4,100,608 served from cache, billed ~10%).

Models - prime-root: zero/swe-root (1 agent, 1 task, 43 calls, 2,583,103 tokens), prime-child: zero/balanced (5 agents, 5 tasks, 69 calls, 2,079,429 tokens)

[zeroset-agent]

🟡 Preserve the existing memory API aliases

This replacement removes NebulaClient.memories, while the same regeneration also deletes Nebula.store_memory() and store_memories() from the DX facade. Those are existing public entry points, and the migration guide still instructs users to call them and describes store_memories as available. A probe against this head confirms that Nebula.store_memory, Nebula.store_memories, and NebulaClient.memories are all absent. Existing applications will therefore fail immediately with AttributeError after what is labeled a fix release. Keep compatibility aliases/wrappers (even if deprecated) or explicitly treat and document this as a breaking release.

Evidence

• At the merge base, NebulaClient initializes self.memories, and Nebula implements store_memory plus store_memories.
• Head probe: Nebula store_memory False store_memories False; NebulaClient instance memories False memory True.
• MIGRATION.md at head still calls client.store_memory and advertises store_memories.

[zeroset-agent]

🟡 Continue retrying transient 408/502/504 responses

The retry set drops 408, 502, and 504, so even generated methods marked retryable: True now surface common transient request-timeout and gateway failures on the first response. This regresses the previous policy and is especially problematic for idempotent GET/DELETE operations where replay is safe. A focused probe configured client.health() with two retries and a transport returning 502; the transport was invoked only once. Add these transient statuses back unless the service contract explicitly guarantees they cannot occur.

Evidence

• The merge-base retry set was {408, 429, 502, 503, 504}.
• Head status probe reports 408=False, 502=False, and 504=False.
• Focused 502 test on retryable client.health() with max_retries=2 produced calls 1.

[zeroset-agent]

Zero Review

Summary

• 0 critical, 2 warnings, 0 nits
• 4,662,532 tokens used (4,629,100 prompt / 33,432 completion; 4,100,608 served from cache, billed ~10%)
• Models - prime-root: zero/swe-root (1 agent, 1 task, 43 calls, 2,583,103 tokens), prime-child: zero/balanced (5 agents, 5 tasks, 69 calls, 2,079,429 tokens)
• Sandbox review mode: full checkout and tool-backed review executed.

2 per-line findings posted in the inline review.