LAB-274: correct Developer Experience matrix to code-verified intent-preset parity

[27Bslash6]

Closes LAB-274 (intent-preset / decorator / public-API parity audit).

The Developer Experience section recorded presence, not semantics — and two cells were factually wrong. Every claim below is code-verified against main of py 0.12.0, rs 0.3.0, ts 0.1.2 (2026-07-21).

Factual corrections

Was	Is	Evidence
Rust presets ::minimal ::production ::secure ::io	No ::secure preset exists. The encrypted preset is CacheKit::encrypted(url, key); secure() is a post-build accessor that returns Err unless encryption was configured	cachekit-rs/crates/cachekit/src/intents.rs:141, client.rs:359-369
Sync support: Rust ✅	Rust is async-only — every cache op is async fn, and #[cachekit] output only compiles on async fns	client.rs:204-341, cachekit-macros/src/lib.rs:215-219
Builder API: Python ✅	Python has no builder — DecoratorConfig presets + kwargs (frozen dataclass) + pydantic-settings; recorded as intentional. TS likewise is an options object, no builder chain and no from_env()	cachekit-py/src/cachekit/config/decorator.py:140-213, cachekit-ts/packages/cachekit/src/cache.ts:48-93
(unrecorded)	Python ships three extra presets: .dev .test .local	decorators/intent.py:229-236

New: intent-preset semantics table

The four shared preset names configure different things per SDK. The new table records the divergences a cross-SDK user hits, each cell code-verified. Highlights:

• TTL defaults: Python presets never set one — entries live forever unless ttl= is passed; rs/ts default 300/600/600/3600 s.
• minimal: L1 off in Rust, on in py/ts; integrity checksums off in Python, on in TS.
• CACHEKIT_MASTER_KEY: auto-enables encryption in all Python presets, only from_env() in Rust, only .secure() in TS.
• io credentials: env-only (py) vs arg-only (rs) vs either (ts).
• Master-key input: hex string ≥64 chars (py/ts) vs raw bytes ≥32 (rs).

Divergences filed (epic LAB-105)

• LAB-513 — cachekit-ts secure.wrap() silently caches plaintext on an unencrypted instance while its type doc says "always encrypts" (py raises, rs errors — TS is the only fail-open SDK here).
• LAB-514 — specify the canonical intent-preset contract in protocol/ (TTL defaults, L1/integrity posture, encryption activation scope, secure vs encrypted naming), then spawn per-SDK alignment tickets.
• Correction posted on LAB-424: cachekit::key::generate_cache_key is not orphaned — every #[cachekit] expansion calls it (cachekit-macros/src/lib.rs:218), so replacing it is a cache-invalidating change, not dead-code removal.

Gates

• Crypto/protocol expert-panel gate: N/A — docs-only change to sdk-feature-matrix.md; documents preset names/defaults and entry-point shapes, rewrites no normative encryption/AAD/key-derivation/wire claims (same call as protocol#23).
• Docs pass: this PR is the documentation update; no other doc surface claims preset semantics that this contradicts (SDK READMEs describe their own SDK only; the cross-SDK contract doc is LAB-514's deliverable).

Note: trivially conflicts with open #23/#24 on the Last updated line only — one-line resolve for whichever merges last.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 59 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 07bf03c8-4a17-4f62-b2b7-a39cf5b2b63e

📥 Commits

Reviewing files that changed from the base of the PR and between 442cb44 and 91cbb98.

📒 Files selected for processing (1)

• sdk-feature-matrix.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch lab-274-intent-preset-parity

---

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

[27Bslash6]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

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.

[27Bslash6]

@coderabbitai review

[coderabbitai]

✅ Action performed

Review finished.

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.

[27Bslash6]

Conflict in sdk-feature-matrix.md (the "Last updated" summary line — same recurring pattern as the other protocol PRs in this sweep: both this branch and main wrote a different narrative summary onto the same line). Picking one drops the other's content, so this needs a human call.

[27Bslash6]

Auto-rebase attempted: merging origin/main produced conflicts in sdk-feature-matrix.md — both the "Last updated" summary line and the SDK feature-parity table rows (e.g. TypeScript "Sync support" ❌ vs ✅, "WASM / CF Workers" ❌ vs ✅) were independently edited with contradictory content. Not a safe union — needs a human call. Left the branch untouched.

[27Bslash6]

Auto-rebase attempted a merge of main but hit a real conflict in sdk-feature-matrix.md (Developer Experience table). The two sides directly contradict each other on Rust's "Sync support" cell — this branch says ❌ async-only, main says ✅ — plus divergent WASM/CF Workers and pydantic-settings-config claims in the same rows. Picking a side isn't something I can safely do, so I left it for a human.

[27Bslash6]

Auto-rebase attempt: merged origin/main and hit a real content conflict in sdk-feature-matrix.md (Developer Experience table) — this branch's LAB-274 audit says Rust has no sync support (async-only, macro-enforced) and TypeScript has no WASM/Workers entrypoint, while main (LAB-595) says Rust does support sync and TypeScript does ship a /workers wasm32 entrypoint. These are competing factual claims from two different code audits, not a textual union — picking either side risks silently overwriting a verified correction. Needs a human to reconcile which claims are current. Merge aborted, branch untouched.

[27Bslash6]

Merge conflict against main is in sdk-feature-matrix.md, and it is a real factual disagreement, not a textual union: the "Sync support" row for Rust reads ❌ async-only (all ops async fn; macro output requires async) on this branch vs ✅ on main. Also the "pydantic-settings config" and "WASM / CF Workers" cells diverge in detail/content. Resolving means asserting one side's capability claim is correct without verifying against actual code — needs a human call.

[27Bslash6]

Auto-rebase sweep: merging main into this branch conflicts in sdk-feature-matrix.md. Both sides edited the same "Developer Experience" table rows with contradictory claims — e.g. Rust "Sync support" (this branch: ❌ async-only vs main: ✅) and TypeScript "WASM / CF Workers" (this branch: N/A vs main: ✅ /workers entrypoint), plus dueling "Last updated" changelog blurbs. Picking either side drops the other's claims — needs a human call on which facts are current.

[27Bslash6]

Auto-rebase check: base main has moved (main HEAD 936f22f) and this branch now conflicts in sdk-feature-matrix.md — both the "Last updated" note and several capability-matrix rows (Sync support, WASM/CF Workers, pydantic-settings config) disagree between this branch and main (main has newer LAB-595/LAB-519/LAB-272 updates to the same cells). Picking a side would drop the other lineage's data — needs a human call, not safe to auto-resolve.

[27Bslash6]

Auto-rebase attempted: merging main into this branch produces a real content conflict in sdk-feature-matrix.md — both sides edited the same "Developer Experience" table rows and the "Last updated" banner with different facts (e.g. Rust "Sync support" shown as ❌ async-only here vs ✅ on main). This isn't a non-overlapping union; picking either side silently drops the other's correction. Left for a human call.

[27Bslash6]

Auto-rebase attempted a merge from main but hit a genuine content conflict in sdk-feature-matrix.md: the "Sync support" and "WASM / CF Workers" table rows have contradicting values between branches (e.g. Rust sync support ❌ here vs ✅ on main; TypeScript WASM/Workers N/A here vs ✅ shipped on main), not a non-overlapping union — picking one side means overwriting the other's factual claim. Needs a human call on which values are current. Left branch untouched (no push).