[codex] Release prep for tywrap 0.3.0 and tywrap-ir 0.2.1

[bbopen]

Summary

Prepare the next release from the current post-v0.2.1 state on main.

This branch builds on the existing release-please 0.3.0 bump and patches the release artifacts so they match the code that will actually ship.

What changed

• correct the npm release notes to include PR #210 (Safe TypeScript generic emission)
• update the exported tywrap runtime version constant to 0.3.0
• bump tywrap-ir package metadata from 0.2.0 to 0.2.1
• align tywrap_ir.__version__ and IR_VERSION with the current Python IR schema in use
• update install/release documentation to reflect split npm/PyPI versioning
• update docs to describe the generic-aware declaration output added since v0.2.1
• regenerate docs/public/llms-full.txt
• include the minimal Prettier cleanup needed for the release gate to pass

Why

The autogenerated release branch was incomplete for this release:

• the generated changelog omitted the most important product-facing change in #210
• src/index.ts still exported 0.2.1
• Python package version exports were internally inconsistent (__version__ still 0.2.0, IR_VERSION still 0.1.0)
• the release docs no longer matched the actual repo workflow now that npm and PyPI releases are handled separately
• the type-mapping docs still described the pre-#210 generic fallback behavior

Without these fixes, the published version metadata and release notes would not accurately describe the shipped code.

User impact

• npm consumers get a coherent tywrap@0.3.0 release with matching version exports and release notes
• PyPI consumers can receive a matching tywrap-ir@0.2.1 tag/publish after merge
• docs now accurately describe installation, split package versioning, and the generic-aware .d.ts output available in this release

Validation

• CI=1 PATH="$PWD/.venv-release/bin:$PATH" npm run check:all
• PATH="$PWD/.venv-release/bin:$PATH" python -m unittest discover -s tywrap_ir/tests -p 'test_*.py' -v
• CI=1 PATH="$PWD/.venv-release/bin:$PATH" npm run docs:build

Release note

Merging this PR should trigger the normal PR CI immediately. The npm release workflow still runs only after merge to main. The PyPI release still requires tagging the merged main commit with tywrap-ir-v0.2.1.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 48beec4c-3cc3-4525-8107-d845a2e9b374

📥 Commits

Reviewing files that changed from the base of the PR and between 7875db3 and ff05fcb.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (20)

• CHANGELOG.md
• README.md
• docs/guide/configuration.md
• docs/guide/getting-started.md
• docs/index.md
• docs/public/llms-full.txt
• docs/reference/api/index.md
• docs/reference/cli.md
• docs/reference/type-mapping.md
• docs/release.md
• package.json
• src/index.ts
• src/runtime/node.ts
• src/runtime/pooled-transport.ts
• src/runtime/worker-pool.ts
• test/cli.test.ts
• test/runtime_node.test.ts
• tywrap_ir/README.md
• tywrap_ir/pyproject.toml
• tywrap_ir/tywrap_ir/__init__.py

💤 Files with no reviewable changes (1)

• test/runtime_node.test.ts

📜 Recent review details

🧰 Additional context used

📓 Path-based instructions (5)

src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

TypeScript strict mode; avoid any — use unknown and type guards instead

Files:

• src/index.ts
• src/runtime/worker-pool.ts
• src/runtime/pooled-transport.ts
• src/runtime/node.ts

src/**/*.ts

📄 CodeRabbit inference engine (AGENTS.md)

Use TypeScript strict mode and avoid any — use unknown and type guards instead

Files:

• src/index.ts
• src/runtime/worker-pool.ts
• src/runtime/pooled-transport.ts
• src/runtime/node.ts

src/runtime/**/*.ts

📄 CodeRabbit inference engine (CLAUDE.md)

Runtime bridges code should be located in src/runtime/ with corresponding tests in test/runtime_*.test.ts

Files:

• src/runtime/worker-pool.ts
• src/runtime/pooled-transport.ts
• src/runtime/node.ts

tywrap_ir/**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

Python code must follow PEP 8 and use type hints

Follow PEP 8 and use type hints in Python code

Files:

• tywrap_ir/tywrap_ir/__init__.py

test/**/*.test.ts

📄 CodeRabbit inference engine (CLAUDE.md)

Use NODE_OPTIONS=--expose-gc environment variable for GC-sensitive tests

Files:

• test/cli.test.ts

🧠 Learnings (20)

📓 Common learnings

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-03-17T05:27:14.946Z
Learning: Applies to tywrap_ir/**/*.py : Follow PEP 8 and use type hints in Python code

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-17T05:27:08.277Z
Learning: Applies to tywrap_ir/**/*.py : Python code must follow PEP 8 and use type hints

📚 Learning: 2026-03-17T05:27:08.277Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-17T05:27:08.277Z
Learning: Applies to tywrap_ir/**/*.py : Python code must follow PEP 8 and use type hints

Applied to files:

• tywrap_ir/README.md
• package.json
• docs/index.md
• docs/guide/getting-started.md
• tywrap_ir/pyproject.toml
• README.md
• tywrap_ir/tywrap_ir/__init__.py
• docs/reference/type-mapping.md
• docs/public/llms-full.txt

📚 Learning: 2026-03-17T05:27:14.946Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-03-17T05:27:14.946Z
Learning: Applies to tywrap_ir/**/*.py : Follow PEP 8 and use type hints in Python code

Applied to files:

• tywrap_ir/README.md
• docs/index.md
• docs/guide/getting-started.md
• tywrap_ir/pyproject.toml
• tywrap_ir/tywrap_ir/__init__.py
• docs/reference/type-mapping.md
• docs/public/llms-full.txt

📚 Learning: 2026-03-17T05:27:14.946Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-03-17T05:27:14.946Z
Learning: Place runtime bridge implementations in `src/runtime/` with corresponding tests in `test/runtime_*.test.ts`

Applied to files:

• docs/index.md
• docs/public/llms-full.txt

📚 Learning: 2026-01-19T21:14:40.872Z

Learnt from: bbopen
Repo: bbopen/tywrap PR: 127
File: src/runtime/bridge-core.ts:260-263
Timestamp: 2026-01-19T21:14:40.872Z
Learning: In `src/runtime/bridge-core.ts` and similar hot request/response loop implementations in the tywrap repository, avoid adding extra defensive validation (e.g., runtime shape checks on error payloads) in tight loops unless the protocol boundary is untrusted or there's a concrete bug report. The Python bridge protocol is controlled and validated via tests, so defensive checks would add unnecessary branching overhead without meaningful benefit.

Applied to files:

• docs/index.md
• docs/public/llms-full.txt

📚 Learning: 2026-01-20T01:34:07.064Z

Learnt from: bbopen
Repo: bbopen/tywrap PR: 136
File: src/runtime/node.ts:444-458
Timestamp: 2026-01-20T01:34:07.064Z
Learning: When reviewing promise-based polling patterns (e.g., recursive setTimeout in waitForAvailableWorker functions), ensure that any recursive timer is tracked and cleared on timeout or promise resolution to prevent timer leaks. Do not rely on no-op checks after settlement; verify clearTimeout is invoked in all paths and consider using an explicit cancellation (e.g., AbortController) or a guard to cancel pending timers when the promise settles.

Applied to files:

• src/index.ts
• src/runtime/worker-pool.ts
• src/runtime/pooled-transport.ts
• test/cli.test.ts
• src/runtime/node.ts

📚 Learning: 2026-01-20T18:37:05.670Z

Learnt from: bbopen
Repo: bbopen/tywrap PR: 152
File: src/runtime/process-io.ts:37-40
Timestamp: 2026-01-20T18:37:05.670Z
Learning: In the tywrap repo, ESLint is used for linting (not Biome). Do not flag regex literals that contain control characters (e.g., \u001b, \u0000-\u001F) as lint errors, since the current ESLint configuration allows them. When reviewing TypeScript files (e.g., src/**/*.ts), rely on ESLint results and avoid raising issues about these specific control-character regex literals unless there is a competing config change or a policy requiring explicit escaping.

Applied to files:

• src/index.ts
• src/runtime/worker-pool.ts
• src/runtime/pooled-transport.ts
• test/cli.test.ts
• src/runtime/node.ts

📚 Learning: 2026-01-20T16:00:49.829Z

Learnt from: bbopen
Repo: bbopen/tywrap PR: 152
File: docs/adr/002-bridge-protocol.md:203-211
Timestamp: 2026-01-20T16:00:49.829Z
Learning: In the BridgeProtocol implementation (tywrap), reject Map and Set explicitly before serialization (e.g., in safeStringify or the serialization entrypoint) with a clear error like "Bridge protocol does not support Map/Set values". Do not rely on post-hoc checks of non-string keys at the point of JSON.stringify, since Maps/Sets cannot round-trip. This should be enforced at the boundary where data is prepared for serialization to ensure deterministic errors and prevent invalid data from propagating.

Applied to files:

• src/index.ts
• src/runtime/worker-pool.ts
• src/runtime/pooled-transport.ts
• test/cli.test.ts
• src/runtime/node.ts

📚 Learning: 2026-01-19T21:14:29.869Z

Learnt from: bbopen
Repo: bbopen/tywrap PR: 127
File: src/runtime/bridge-core.ts:375-385
Timestamp: 2026-01-19T21:14:29.869Z
Learning: In the runtime env-var parsing (e.g., in src/runtime/bridge-core.ts and similar modules), adopt a tolerant, best-effort policy: numeric env values should parse by taking the leading numeric portion (e.g., TYWRAP_CODEC_MAX_BYTES=1024abc -> 1024). Only reject clearly invalid values (non-numeric start or <= 0). This reduces surprising failures from minor typos. Add tests to cover partial numeric prefixes, and ensure downstream logic documents the trusted range; consider a small helper to extract a positive integer from a string with a safe fallback.

Applied to files:

• src/runtime/worker-pool.ts
• src/runtime/pooled-transport.ts
• src/runtime/node.ts

📚 Learning: 2026-01-19T21:14:35.390Z

Learnt from: bbopen
Repo: bbopen/tywrap PR: 127
File: src/runtime/bridge-core.ts:260-263
Timestamp: 2026-01-19T21:14:35.390Z
Learning: In src/runtime/bridge-core.ts and similar hot request/response loop implementations in the tywrap repository, avoid adding extra defensive validation (such as runtime, shape, or error-payload checks) inside tight loops unless the protocol boundary is untrusted or there is a concrete bug report. The Python bridge protocol is controlled via tests, so these checks add unnecessary branching overhead without meaningful benefit. Apply this guidance to other hot-path runtime loops in src/runtime/**/*.ts, and re-enable additional validations only when a documented risk or failure scenario is identified. Ensure tests cover protocol validation where applicable.

Applied to files:

• src/runtime/worker-pool.ts
• src/runtime/pooled-transport.ts
• src/runtime/node.ts

📚 Learning: 2026-03-17T05:27:08.277Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-17T05:27:08.277Z
Learning: Applies to test/runtime_*.test.ts : Include tests for new runtime behavior following the `test/runtime_*.test.ts` patterns

Applied to files:

• test/cli.test.ts

📚 Learning: 2026-03-17T05:27:14.946Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-03-17T05:27:14.946Z
Learning: Applies to test/runtime_*.test.ts : Include tests for new runtime behavior following patterns in `test/runtime_*.test.ts`

Applied to files:

• test/cli.test.ts

📚 Learning: 2026-01-19T21:48:27.823Z

Learnt from: bbopen
Repo: bbopen/tywrap PR: 127
File: test/runtime_bridge_fixtures.test.ts:59-66
Timestamp: 2026-01-19T21:48:27.823Z
Learning: In fixture-based tests (e.g., test/runtime_bridge_fixtures.test.ts) and similar tests in the tywrap repository, prefer early returns when Python or fixture files are unavailable. Do not rely on Vitest dynamic skip APIs; a silent pass is intentional for environments lacking Python/fixtures. Treat missing fixtures as optional soft-guards and ensure the test remains non-disruptive in non-availability scenarios.

Applied to files:

• test/cli.test.ts

📚 Learning: 2026-03-17T05:27:08.277Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-17T05:27:08.277Z
Learning: Applies to test/**/*.test.ts : Use `NODE_OPTIONS=--expose-gc` environment variable for GC-sensitive tests

Applied to files:

• test/cli.test.ts

📚 Learning: 2026-03-17T05:27:08.277Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-17T05:27:08.277Z
Learning: Run `npm run check:all` before pushing — this runs format, lint, build, type tests, and unit tests

Applied to files:

• test/cli.test.ts

📚 Learning: 2026-03-17T05:27:14.946Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-03-17T05:27:14.946Z
Learning: Run `npm run check:all` before pushing to ensure format, lint, build, type tests, and unit tests pass

Applied to files:

• test/cli.test.ts

📚 Learning: 2026-01-20T16:01:14.323Z

Learnt from: bbopen
Repo: bbopen/tywrap PR: 152
File: docs/adr/002-bridge-protocol.md:599-602
Timestamp: 2026-01-20T16:01:14.323Z
Learning: In `src/runtime/node-bridge.ts` (NodeBridge), a test message is sent to the Python subprocess to confirm the bridge is responsive before marking it as ready.

Applied to files:

• src/runtime/node.ts

📚 Learning: 2026-01-19T21:48:45.693Z

Learnt from: bbopen
Repo: bbopen/tywrap PR: 127
File: src/runtime/bridge-core.ts:260-298
Timestamp: 2026-01-19T21:48:45.693Z
Learning: In `src/runtime/bridge-core.ts`, keep `normalizeErrorPayload` to validate error payloads from the Python subprocess. The subprocess boundary is effectively untrusted, and normalizing error responses prevents `undefined: undefined` errors on malformed payloads. Error responses are not the hot path, so the small validation overhead is acceptable for the added resilience.

Applied to files:

• src/runtime/node.ts

📚 Learning: 2026-03-17T05:27:08.277Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-03-17T05:27:08.277Z
Learning: Applies to src/**/*.{ts,tsx} : TypeScript strict mode; avoid `any` — use `unknown` and type guards instead

Applied to files:

• docs/reference/type-mapping.md
• docs/public/llms-full.txt

📚 Learning: 2026-03-17T05:27:14.946Z

Learnt from: CR
Repo: bbopen/tywrap PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-03-17T05:27:14.946Z
Learning: Applies to src/**/*.ts : Use TypeScript strict mode and avoid `any` — use `unknown` and type guards instead

Applied to files:

• docs/reference/type-mapping.md
• docs/public/llms-full.txt

🪛 LanguageTool

docs/release.md

[uncategorized] ~18-~18: The official name of this software platform is spelled with a capital “H”.
Context: ...ease-please branch or PR to main. The release.yml workflow crea...

(GITHUB)

---

[uncategorized] ~49-~49: The official name of this software platform is spelled with a capital “H”.
Context: ...gin tywrap-ir-v ``` 5. The publish-pypi.yml workflow ...

(GITHUB)

🪛 markdownlint-cli2 (0.22.0)

docs/release.md

[warning] 6-6: First line in a file should be a top-level heading

(MD041, first-line-heading, first-line-h1)

---

[warning] 28-28: Blank line inside blockquote

(MD028, no-blanks-blockquote)

🔇 Additional comments (28)

src/runtime/node.ts (1)

352-352: Formatting-only change looks good.

This call-site reformat is behavior-neutral and keeps argument ordering intact.

src/runtime/worker-pool.ts (2)

109-115: Type declaration reformat is clean and safe.

The Omit<...> & { ... } structure is unchanged semantically; this is a readability-only adjustment.

---

441-441: Method signature reformat is fine.

This compaction keeps defaults and return type unchanged, with no behavioral impact.

src/runtime/pooled-transport.ts (1)

86-92: LGTM — formatting-only type refactor.

No logic or API behavior changed; this improves readability without altering semantics.

test/cli.test.ts (2)

380-399: LGTM! Clean formatting improvement.

The refactoring to single-line it() syntax with timeout as the third argument is more concise and idiomatic for Vitest. The test logic and timeout value remain unchanged.

---

522-578: LGTM! Consistent formatting improvement.

The refactoring to single-line it() syntax matches the change at line 380 and maintains the same timeout value and test logic.

src/index.ts (1)

150-150: Version constant alignment looks correct.

Line 150 now matches the npm release target (0.3.0) and keeps runtime-exported metadata consistent with package release intent.

package.json (1)

3-3: Package version bump is consistent with release prep.

Line 3 correctly sets the npm package version to 0.3.0, aligned with exported runtime versioning in src/index.ts.

tywrap_ir/README.md (1)

15-17: Release-model clarification is accurate and useful.

Lines 15–17 clearly document independent versioning between tywrap and tywrap-ir, which reduces installation/version-pin confusion.

tywrap_ir/pyproject.toml (1)

7-7: Python package metadata bump is correctly applied.

Line 7 updates tywrap-ir to 0.2.1, matching the intended PyPI release versioning path.

docs/guide/configuration.md (1)

170-170: output.declaration description now reflects current behavior.

Line 170 is clearer and better aligned with the generator’s generic-aware declaration output.

docs/guide/getting-started.md (1)

33-41: Getting-started setup now covers the required Python component.

Lines 33–41 correctly add tywrap-ir installation and clarify split versioning, which prevents generation-time setup errors.

docs/reference/cli.md (1)

71-71: CLI flag documentation improvement is correct.

Line 71 now explicitly states that --declaration emits matching .d.ts files, improving behavioral clarity.

tywrap_ir/tywrap_ir/__init__.py (1)

7-8: Version constants are properly synchronized.

Line 7 matches tywrap_ir/pyproject.toml (0.2.1), and Line 8 aligns with the TypeScript IR schema version (0.2.0).

docs/index.md (2)

10-10: LGTM - Clear inline documentation.

The inline comment effectively clarifies the purpose of tywrap-ir for new users.

---

15-17: LGTM - Helpful versioning guidance.

This note aligns with the split-package versioning documented in docs/release.md and helps users understand that they should upgrade both packages independently.

docs/reference/api/index.md (1)

57-60: LGTM - Accurate technical documentation.

The description correctly reflects the .d.ts emission behavior and generic preservation logic shown in the relevant code snippets (src/tywrap.ts:263-269 and src/core/generator.ts:145-170).

CHANGELOG.md (1)

1-29: LGTM - Well-structured changelog entry.

The changelog follows conventional commit format with proper PR and commit references. The highlighted feature (safe TypeScript generic emission, PR #210) aligns with the documentation updates throughout this PR.

README.md (2)

22-23: LGTM - Clear feature documentation.

The new feature bullet accurately describes the generic preservation behavior documented in detail in docs/reference/type-mapping.md.

---

56-58: LGTM - Consistent versioning guidance.

This note matches the versioning documentation in docs/index.md and docs/release.md, maintaining consistency across the documentation.

docs/reference/type-mapping.md (3)

57-68: LGTM - Accurate type mapping documentation.

The updated Special Names table correctly describes the generic preservation behavior. The notes accurately reflect the implementation logic shown in src/core/generator.ts:145-170 (simple unconstrained TypeVar preservation) and src/core/mapper.ts:329-370 (type mappings).

---

146-155: LGTM - Clear explanation of limits.

The expanded Limits and Fallbacks section clearly explains when generics are preserved versus when they fall back to unknown, matching the actual implementation behavior.

---

160-189: LGTM - Helpful concrete example.

The Generic Example provides a clear demonstration of TypeVar and ParamSpec preservation in practice, making the abstract rules concrete for users.

docs/release.md (1)

3-57: LGTM - Clear dual-release documentation.

The restructured release process clearly separates the npm and PyPI workflows, documents the independent versioning model, and provides both automated and manual release procedures. The tag format distinction (vX.Y.Z vs tywrap-ir-vX.Y.Z) is well-documented.

Note: The static analysis hints flagging "GitHub" capitalization and blank lines are false positives/minor style issues that don't affect clarity.

docs/public/llms-full.txt (4)

16-23: LGTM - Consistent installation documentation.

The installation and versioning guidance matches the updates in docs/index.md and README.md.

---

599-599: LGTM - Consistent declaration documentation.

The output.declaration description matches the API reference documentation in docs/reference/api/index.md.

---

2315-2326: LGTM - Consistent type mapping table.

The Special Names table matches the updated documentation in docs/reference/type-mapping.md.

---

2418-2446: LGTM - Consistent generic example.

The Generic Example matches the new example added to docs/reference/type-mapping.md.

---

📝 Walkthrough

Walkthrough

Release v0.3.0 for tywrap npm package (v0.2.1 for tywrap-ir Python package), including version bumps, a changelog entry documenting new generic emission capabilities, extensive documentation updates clarifying TypeVar/ParamSpec preservation behavior, installation instructions for independent tywrap-ir package, and minor code formatting adjustments.

Changes

Cohort / File(s)	Summary
Version Bump and Release package.json, src/index.ts, CHANGELOG.md	Version updated from 0.2.1 to 0.3.0 with changelog entry documenting features (safe TypeScript generic emission, getBridgeInfo() meta call) and bug fixes.
Python Package Metadata tywrap_ir/pyproject.toml, tywrap_ir/tywrap_ir/__init__.py	Version bumped from 0.2.0 to 0.2.1; IR_VERSION constant updated from 0.1.0 to 0.2.0 to align with IR schema.
Core Documentation Updates README.md, docs/guide/configuration.md, docs/guide/getting-started.md, docs/index.md, tywrap_ir/README.md	Added installation step for tywrap-ir Python package; clarified independent versioning of tywrap and tywrap-ir; updated output.declaration descriptions to reflect generic preservation capabilities.
Comprehensive Type Mapping Documentation docs/reference/type-mapping.md, docs/public/llms-full.txt, docs/reference/api/index.md, docs/reference/cli.md	Detailed documentation of TypeVar/ParamSpec generic emission behavior; updated CLI and API docs to reflect .d.ts emission when output.declaration is enabled; added generic examples and limits/fallbacks sections.
Release Procedure Documentation docs/release.md	Restructured release procedures into separate npm (tywrap) and PyPI (tywrap-ir) flows with independent versioning, distinct tag formats (vX.Y.Z vs tywrap-ir-vX.Y.Z), and CI/manual release gates.
Code Formatting src/runtime/node.ts, src/runtime/pooled-transport.ts, src/runtime/worker-pool.ts, test/cli.test.ts, test/runtime_node.test.ts	Minor TypeScript type formatting and test callback syntax adjustments; no logic or behavioral changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• [codex] Safe TypeScript generic emission #210: Introduces IR version bump and implements safe TypeScript generic emission feature that this PR documents and releases.
• feat(pypi): add tywrap-ir PyPI publishing #134: Establishes PyPI packaging and publishing workflow for tywrap-ir that this PR formalizes in release procedures.
• chore: bump version to 0.2.0 #140: Previous version metadata and package.json updates using similar version bump patterns.

Suggested labels

documentation, area:ci, area:tooling, codex, enhancement

Poem

🐰 Hop, hop, the generics now bloom,
TypeVars preserved from the gloom,
Two packages dance, each with their own time,
tywrap and tywrap-ir in perfect rhyme,
Version three-oh arrives with care!

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main purpose of the PR: release preparation for tywrap 0.3.0 and tywrap-ir 0.2.1.
Description check	✅ Passed	The description is comprehensive and directly related to the changeset, covering summary, detailed changes, rationale, user impact, and validation steps.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/release-0.3.0-prep

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 66.66667% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/index.ts	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[bbopen]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.