LAB-430: feature matrix — ts Memcached/File backends shipped; refresh stale capability cells

[27Bslash6]

Sibling of cachekit-io/cachekit-ts#76 (LAB-430).

• Cache Backends: TypeScript Memcached and File cells → ✅ with module evidence (backends/memcached.ts, memjs optional peer dep; backends/file.ts, node:fs, py-compatible on-disk format).
• Optional capabilities rows were lying in both directions after post-audit changes, fixed with citations:
  • ts Redis has TTL + locking since LAB-427 (cachekit-ts#74) — row said ❌.
  • py File has TTL inspect/refresh and py Memcached has refresh-only refresh_ttl since LAB-446 (cachekit-py#230) — row said ❌.
  • ts File → ✅ TTLBackend, ts Memcached → refresh-only, mirroring py (LAB-430, this change).
• "Coverage, not shape" note updated accordingly; last-updated stamp bumped.

Not touched (flagged for a follow-up ticket): the interop mode row still says "Not implemented" in all SDKs, but py (LAB-245, cachekit-py#220) and ts (LAB-247, cachekit-ts#71) have merged interop/v1 implementations — needs its own verification pass.

[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: 28 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: 4a5acfcc-27f6-43ba-8ff7-0f23a64e3463

📥 Commits

Reviewing files that changed from the base of the PR and between 53aaec8 and b9b8d8f.

📒 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-430-matrix-ts-memcached-file

---

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

[27Bslash6]

Conflict in sdk-feature-matrix.md isn't a safe auto-merge — 4 hunks, and the first (the "Last updated" changelog line) has both sides writing distinct prose about different landed work (LAB-430 here vs. LAB-446/LAB-595/LAB-519 on main); picking either drops the other's changelog entry. The remaining 3 hunks need sub-cell splicing between Rust and TypeScript capability columns (LAB-426/429 on main vs. LAB-430 here) — mechanically doable but requires verifying which capability claims are still accurate against current main, more than a rebase bot should decide. Needs a human pass.

[27Bslash6]

Auto-rebase attempted a merge of main but hit a real conflict in sdk-feature-matrix.md (4 hunks) — both branches added different, both-true capability facts to the same table rows (TS Memcached/File details from this PR's LAB-430 vs Rust Memcached/File details from LAB-429 already on main), plus footnote cross-references. Combining them correctly requires rewriting the prose, not a mechanical union, so I left it for a human.

[27Bslash6]

Auto-rebase attempted (base moved) but left unresolved — real content conflicts, not trivial:

• sdk-feature-matrix.md: 4 overlapping hunks (the "Last updated" summary line, Cache Backends table rows for Memcached/File, Optional-capabilities table rows for TTL inspect/refresh and Distributed locking, and the parity-gap note). origin/main's version already incorporates content that looks like a superset of this branch's LAB-430 change, interleaved with several sibling doc updates (LAB-427, LAB-429, LAB-446) that landed since. Whether this branch's changes are now redundant or still need re-integration is a documentation-accuracy call, not a safe auto-merge.

Needs a human call.

[27Bslash6]

Auto-rebase found a real conflict in sdk-feature-matrix.md — needs a human call. Same hot file as the other open matrix PRs: main's changelog line already says "LAB-430 shipped TypeScript Node-only Memcached and File backends", so this branch's edit may already be superseded/duplicated on main. Can't safely reconcile the table cells without a human read of which claims are current. Left the branch as-is; will retry once main moves again.

[27Bslash6]

Auto-rebase attempted, left for a human: merging main conflicts in sdk-feature-matrix.md — same shared table/footnote conflict pattern as the sibling matrix PRs (#17/#31/#32/#33) in this repo, both sides recording different ticket-driven capability updates on the same rows. Needs a human to synthesize the matrix edits.

[27Bslash6]

Conflict in sdk-feature-matrix.md (4 hunks). Cache Backends table hunk is a real factual contradiction, not reformatting: this PR's HEAD claims Rust has no Memcached/File backend (❌❌), origin/main claims it does (✅✅, LAB-429 landed after this branch point) — a direct disagreement on shipped state, not a union. Same for the Distributed-locking Redis cell. Requires an editorial call on which claim is current. Leaving for a human to resolve.