[nebula-sdk-bot]

Automated SDK regeneration.

Source: zeroset-inc/nebula@e3d834d
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 - 3 findings shown inline.

3,917,525 tokens used (3,887,224 prompt / 30,301 completion; 3,397,120 served from cache, billed ~10%).

Models - prime-root: zero/swe-root (1 agent, 1 task, 43 calls, 2,433,674 tokens), prime-child: zero/balanced (4 agents, 4 tasks, 45 calls, 1,483,851 tokens)

[zeroset-agent]

🟡 Preserve the public memories resource alias

This changes the existing client.memories resource to client.memory without keeping an alias. Any current caller using documented/resource-style calls such as client.memories.search(...) now fails immediately with AttributeError. A focused head-package check prints memories False, while the merge-base client initializes self.memories. Since this PR is intended as a fix release, keep self.memories as a compatibility alias (or otherwise avoid publishing this breaking rename in the fix).

Evidence

• At merge base, src/nebula/_client.py initializes self.memories: MemoriesResource.
• Focused command on head: hasattr(Nebula(), "memories") printed False.

[zeroset-agent]

🟡 Restore the high-level memory storage helpers

The rewritten Nebula facade jumps directly from construction to list_memories, deleting the previously public store_memory and store_memories methods. Existing applications calling either helper now get AttributeError; the focused head check printed both attributes as false. This is especially inconsistent with the retained migration text, which still describes store_memories(max_concurrency=...) as a non-breaking improvement. Please retain compatibility wrappers that forward to memory.store / memory.store_many (and preserve the old append/return behavior as applicable), or treat/document this as an intentional breaking release rather than a fix.

Evidence

• At merge base, src/nebula/_dx.py implements store_memory and store_memories; neither definition exists at head.
• Focused head-package command printed store_memory False and store_memories False.
• MIGRATION.md at head still says store_memories accepts max_concurrency under “Non-breaking improvements”.

[zeroset-agent]

🟡 Continue retrying transient 502/504/408 responses

The retryable status set drops 408, 502, and 504, so even operations explicitly generated with retryable=True fail on the first transient gateway timeout/bad-gateway response. In a focused reproduction, client.health() received a 502 followed by a 200 from MockTransport, but raised NebulaServerError after exactly one request. These are standard transient conditions that the merge-base runtime retried; retain them in the set unless there is a demonstrated protocol reason not to.

Evidence

• Merge-base retry set is {408, 429, 502, 503, 504}; head set is {421, 429, 503}.
• Focused uv run --extra test python reproduction with health responses 502 then 200 printed NebulaServerError 1.
• Full native suite passed: uv run --extra test pytest -q => 61 passed.

[zeroset-agent]

Zero Review

Summary

• 0 critical, 3 warnings, 0 nits
• 3,917,525 tokens used (3,887,224 prompt / 30,301 completion; 3,397,120 served from cache, billed ~10%)
• Models - prime-root: zero/swe-root (1 agent, 1 task, 43 calls, 2,433,674 tokens), prime-child: zero/balanced (4 agents, 4 tasks, 45 calls, 1,483,851 tokens)
• Sandbox review mode: full checkout and tool-backed review executed.

3 per-line findings posted in the inline review.