Uh oh!
There was an error while loading. Please reload this page.
deps: bump rt-client to activate dev-mode action commands - #9
Conversation
rt-client 0.3.0 did not register the `mattstack.mode` setting key, and getSetting throws for unregistered keys, so isDevMode() always fell closed to prod: the whole action-command surface (board buttons, /commands routes, deck cmd) was dormant in real dev. 0.10.1 registers mattstack.mode (string, machine-scoped, dev|prod). deck's rt-client surface (getSetting/setSetting/ rtCommand and the deck.apps/access/platform key defs) is byte-identical across 0.3.0..0.10.1, so this is a pure activation with no API change. Adds a regression test exercising the real getSetting path (unset/prod -> false, dev -> true), which the existing injected-read tests bypass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthroughThe pull request updates ChangesDev-mode configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk:⚪ Minimal · up to The dependency update activates development-mode command functionality and adds regression coverage without changing application code; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
m4ttheweric
commented
Aug 30, 2026
@coderabbitai review |
✅ Action performedReview finished.
|
Uh oh!
There was an error while loading. Please reload this page.
core/generated-fresh.test asserts a rebuild reproduces the committed bundle; after the rt-client bump (#9) the committed artifact no longer matched a fresh build, leaving main red. No board source changed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Follow-up to #7. Activates the action-command surface that shipped dormant.
Why
isDevMode()reads the rt settingmattstack.modevia@mattstack/rt-client'sgetSetting, but the pinned0.3.0does not register that key, andgetSettingthrows for unregistered keys. The gate therefore always fell closed to prod, leaving the board's per-command buttons, the/api/v1/apps/:name/commands/*routes, anddeck cmdinert in real dev (the feature was correct and fully tested via injecteddevMode, just never activated).0.10.1registersmattstack.mode(string, machine-scoped,dev|prod), so the gate now works.Safety of the jump (0.3.0 -> 0.10.1)
deck only uses
getSetting/setSetting/rtCommandand thedeck.apps/deck.access/deck.platformstore keys. Diffed across the versions:deck.*key definitions are byte-identical.getSettingandrtCommandsignatures unchanged; the onlysetSetting-file diff is a doc comment added above the neighboringunsetSetting.So this is a pure activation, not an API migration.
Testing
bun test core src= 513 pass / 0 fail (was 512; +1 new test).getSettingpath under an isolated HOME (not the injected-read fakes the other dev-mode tests use): unset -> prod,mode=prod-> false,mode=dev-> true. Verified end to end that the dormancy is lifted.No app code changed... only the version pin, lockfile, and the new test.
🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Tests