docs(matrix): cachekit-core envelope pre-scan on main, unreleased (LAB-3479)

[27Bslash6]

Updates the feature matrix for cachekit-io/cachekit-core#80, merged to core main. It adds the Retrieve Flow step-2 structural pre-scan to ByteStorage::retrieve and runs decode-bounds.json 1.1.0 through it in core CI.

• Wire format (ByteStorage), Rust (canonical cachekit-core): ⚠️ → 🚧 unreleased, linking the core PR. It is not ✅ because crates.io 0.6.0 does not carry the pre-scan. It moves to ✅ once a core release does.
• Wire format, Python and TypeScript: stay ⚠️. Each cell names the core PR and says it flips when that SDK moves to a core release that carries the pre-scan. For TypeScript that means both bindings, cachekit-core-ts and cachekit-core-wasm.
• Test vectors in CI, Python and TypeScript: stay ⚠️ for the envelope entry point, under the same condition. TypeScript also needs the vectors driven through unpack.
• Footnote ¹⁶: records that cachekit-core vendors decode-bounds.json 1.1.0.

Changelog entry: changelog.d/20260929_lab-3479.md. tools/test_changelog_collect.py, check-version-floors.py and check-spec-duplication.py pass locally.

This PR is a documentation-only update to the SDK feature matrix. It records that the cachekit-core envelope structural pre-scan (Retrieve Flow step 2) has merged to core main via cachekit-core#80. It has not been released: crates.io 0.6.0 does not include it.

Changes to sdk-feature-matrix.md

Wire format (ByteStorage) row

• Rust (canonical cachekit-core): ⚠️ → 🚧 unreleased. On core main, ByteStorage::retrieve and validate now pre-scan the envelope bytes before the typed rmp_serde::from_slice into StorageEnvelope. The cell stays short of ✅ because crates.io 0.6.0 does not have the change.
• Python: remains ⚠️. The cell now cites cachekit-core#80 and states that it flips when cachekit-py bumps to a core release that includes the pre-scan.
• TypeScript: remains ⚠️. The envelope entry point is now identified as unpack in both cachekit-core-ts and cachekit-core-wasm. The cell flips only when both bindings move to a core release that includes the pre-scan.

Test vectors in CI row

• Python: the envelope entry-point exception (ByteStorage::retrieve) now names the same release condition.
• TypeScript: the exception now covers unpack in both bindings. It requires two things: a core release carrying chore(changelog): one fragment file per entry in changelog.d/, collected at release (LAB-6153) #80, and the vectors being driven through unpack.

Footnote ¹⁶

• Adds that cachekit-core vendors decode-bounds.json 1.1.0 and drives it through ByteStorage::retrieve on core main, which is unreleased.

Header

• The "Last updated" line changes to 2026-09-30 and references LAB-3479, following LAB-3481 and LAB-523.

Changes to changelog.d/20260929_lab-3479.md (new)

• A changelog fragment summarizing the cell transitions above and the conditions under which the remaining ⚠️ cells will flip.

Public API references

No APIs are modified in this repository. The matrix now documents pre-scan behavior for the following cachekit-core entry points, on core main only:

• ByteStorage::retrieve
• ByteStorage::validate
• unpack, exposed via cachekit-core-ts and cachekit-core-wasm

[coderabbitai]

Warning

Review limit reached

Next included review available in 3 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository: cachekit-io/protocol/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Advanced

Run ID: dffacb7b-db40-4a79-a113-bd1248b613e6

📥 Commits

Reviewing files that changed from the base of the PR and between eeea8b1 and 845e6a3.

📒 Files selected for processing (2)

• changelog.d/20260929_lab-3479.md
• sdk-feature-matrix.md

---

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.}

[kodus-27b]

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

• Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
• Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
• Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
• Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
• API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
• Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
• Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
• Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
• Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
• Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

[kodus-27b]

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

• Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
• Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
• Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
• Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
• API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
• Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
• Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
• Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
• Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
• Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

[27Bslash6]

@kody review --force

[kodus-27b]

Code Review Completed! 🔥

The code review was successfully completed based on your current configurations.

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the `@kody start-review` command at the root of your PR.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Providing Context (Files & MCPs)

Add these hints in your PR description (or a comment) to unlock deeper checks:

• Ticket / Acceptance Criteria: `Refs: ABC-123` (Linear/Jira/Asana/ClickUp/Trello) or a direct ticket link.
• Bugfix Validation: a Sentry/Datadog/Bugsnag event link (or paste the stack trace/error message).
• Endpoint Risk: mention the route (e.g., `POST /api/payments`) or controller/action name.
• Attach a repo file as context: use an explicit marker like `@file:docs/guide.mdx#L10-L50` (replace with your real path).
• API Contract Docs: include `@file:openapi.yaml` or `@file:swagger.json` when changing routes/schemas.
• Definition of Done / Standards: include `@file:DOD.md` or `@file:CONTRIBUTING.md` if your repo has them.
• Design System Source of Truth: include `@file:ui/index.ts` (replace with your DS entrypoint path).
• Feature Flags: include the flag key/name and `@file:flags.ts` / `@file:config.json` (and optionally the PostHog flag name).
• Edge/CDN Rules: link the Cloudflare rule/zone or describe the intended redirect/header behavior.
• Attach an MCP tool output: use `@mcp<provider|tool>` (replace with an installed MCP provider + tool, e.g., `@mcp<sentry|events.search>`).

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.