softr-vibe-coding 2.5.0 → 2.5.1

package/CHANGELOG.md

@@ -4,6 +4,9 @@ All notable changes to this skill are documented here. Versions follow [Semantic
 
 Entries from 1.3.1 onward are generated automatically from git commit subjects between version bumps (see `.github/workflows/publish.yml`). Entries before 1.3.1 were backfilled by hand from the existing commit history.
 
+## [2.5.1] - 2026-09-09
+- The Action-permission reset has a failure mode that leaves blocks publicly writable — verify, never assume
+
 ## [2.5.0] - 2026-09-09
 - Cross-block and cross-page consistency: the failure mode where every block looks correct alone
 

package/README.md

@@ -291,7 +291,7 @@ The skill enforces these automatically, but good to know (verified live against
 - Create payloads are **flat**; update payloads are `{ recordId, fields: {...} }` — asymmetric by design
 - `mutateAsync` is fully supported — it's the tool for sequential multi-row saves
 - SELECT fields write by option **label string**; linked records write as arrays of record-id strings
-- Every code recompile resets the block's auto-registered Actions to default permissions — tighten permissions after the last redeploy, and note there is **no cosmetic-edit exemption**: an edit that changes only a comment resets them too
+- Every code recompile resets the block's auto-registered Actions to default permissions — tighten permissions after the last redeploy, and note there is **no cosmetic-edit exemption**: an edit that changes only a comment resets them too. **Always read the permissions back to confirm** — the default for a create action is `ALL_USERS` (publicly writable), and the MCP call that re-tightens it can fail with no fallback
 - **Blocks cannot import each other**, so two blocks that must look alike will drift — each one looks correct in isolation while the set does not. Repeated page chrome (back button, title, primary action) must sit at the same offset on every page, and a loading skeleton must track the REST state of whatever it stands in for
 - No `import React from 'react'` — use named imports (`import { useState } from "react"`)
 - Must use `export default function Block()`

package/SKILL.md

@@ -548,8 +548,15 @@ Non-negotiable rules. Most are enforced by the Softr platform (compiler, validat
     across a 15-block deployment. See [datasources/writing.md](datasources/writing.md#how-actions-work-studios-actions-tab).
     **Any save counts, including one whose only change is a comment** -- there is no "cosmetic edit"
     exemption; a `search_replace` that rewrites nothing but a code comment rebuilds the Actions exactly
-    like a full rewrite does (verified live 2026-09-09, on two blocks at once). Re-check permissions
-    after EVERY push.
+    like a full rewrite does (verified live 2026-09-09, on two blocks at once).
+    **Re-read the permissions after EVERY push and confirm they actually changed** -- do not assume the
+    restore worked. Softr's default for a `genericActions` ADD_RECORD is `ALL_USERS`, i.e. writable by
+    logged-OUT visitors, and the MCP call that re-tightens it (`set_vibe_coding_block_action_visibility`)
+    can itself fail with no fallback (see the array-argument quirk in
+    [references/softr-mcp.md](references/softr-mcp.md#the-array-argument-serialization-quirk-and-why-it-is-a-security-issue)).
+    A push that returns `errors: null` can still have left public write access on the block.
+    **If any action is still `ALL_USERS`, do not publish** -- surface the list and have a human set it
+    in Studio.
 22. **Blocks cannot import each other -- cross-block consistency is discipline, not architecture [house]**
     -- Every block compiles standalone. There is no shared module, no design-system import, nothing that
     makes two blocks stay alike. Two blocks that must look the same WILL drift, and the drift usually

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "softr-vibe-coding",
-  "version": "2.5.0",
+  "version": "2.5.1",
   "description": "Claude Code skill for generating production-ready Softr Vibe Coding blocks (JSX). Installs into ~/.claude/skills/ and auto-updates on each Claude Code session.",
   "bin": {
     "softr-vibe-coding": "./bin/cli.js"

package/references/anti-patterns.md

@@ -39,6 +39,7 @@ Run through this catalog before delivering any block. Every row is a violation o
 | Passing a data hook's options through a variable or wrapper function: `useRecords(buildOpts())` | **Fails to compile** — the options object must be an inline literal at the call site (verified live 2026-08-25; hit in production, fixed by making the wrapper take the hook's *result* instead). Share `q.select` mappings between hooks, never whole options objects |
 | Tightening Actions-tab permissions before the block's final redeploy | Every code recompile **resets the auto-registered Actions to default permissions** (verified live 2026-08-25). Tighten permissions after the LAST redeploy, and re-check after any future one |
 | Assuming a comment-only edit is "safe" and leaves Action permissions alone | There is no cosmetic-edit exemption. Any save recompiles, and every recompile rebuilds the Actions at default visibility — a `search_replace` changing nothing but a code comment resets them exactly like a rewrite (verified live 2026-09-09, on two blocks at once). Re-check after EVERY push, including cosmetic ones |
+| Treating the permission-restore call as done because you issued it | Read the permissions back with `get_vibe_coding_block_settings` and confirm each one changed. `set_vibe_coding_block_action_visibility` can fail outright on the array-argument serialization quirk, and it has **no fallback** — the default for a `genericActions` ADD_RECORD is `ALL_USERS`, so a routine push silently leaves the block publicly writable while returning `errors: null`. Verified live 2026-09-09: four ADD_RECORD actions left open across two blocks. **Do not publish** until they read `LOGGED_IN_USERS`; escalate to a human with Studio access |
 | Treating Studio's Actions tab as a separately-managed configuration to keep in sync with code | Actions auto-derive from your `useRecordCreate`/`useRecordUpdate`/`useRecordDelete` + `q.select` on every save. The Actions tab is a read-only inspector; there is no manual delete control. To change an Action, change the code |
 | One alias in a write-side `q.select` referencing a renamed / non-existent Airtable column | Softr's Action parser silently rejects the **entire** create/update Action — not just the bad alias. Symptoms: Studio's Actions tab shows "No actions used in this block yet", `createRecord.enabled` / `updateRecord.enabled` stays `false`, `.mutate()` calls dispatch but resolve immediately to "not yet ready". Every OTHER field in the same `q.select()` is also lost, even the ones that map cleanly. Diagnostic: bisect the `q.select` — strip down to a known-good minimal set, confirm the Action appears in Studio, then add fields back in halves until it drops out. The culprit is in the last half added. Once narrowed to a single field, grep its name against the freshest Airtable schema export to catch the rename / trailing-space / case-mismatch. Verified 2026-05-21: a `"Photos"` column on Wigs was renamed to `"Before Photos"`, the helper that wrote `photos: "Photos"` had its entire Action disabled even though 11 other fields in the same `q.select` were fine. See [datasources/airtable.md](../datasources/airtable.md#maintainability-gotcha) |
 

package/references/softr-mcp.md

@@ -101,14 +101,52 @@ components, adding a hook — where being sure of "the exact current text" of a
 is harder than being sure of the whole file. Also use it when the local file is the source of truth and
 has drifted from the deployed block in ways you have not enumerated.
 
-**Caveat on the `operations` argument.** It is an array of `{search, replace}` objects. Some MCP clients
-serialize it as a JSON *string* instead, and the API rejects that with a Jackson error — `Cannot
-deserialize value of type java.util.ArrayList<java.util.Map<String,String>> from String value` (hit
-2026-09-09, mid-session, on a tool that had accepted the same shape minutes earlier). It is a client
-serialization quirk, not a bad request: if it will not take the array, fall back to the full replace
-rather than mangling the edit to fit.
-
-Both paths recompile, so both reset Action permissions either way (Hard Constraint 21).
+### The array-argument serialization quirk, and why it is a security issue
+
+**Several tools on this server take an array argument, and some MCP clients serialize it as a JSON
+*string* instead.** The API then rejects it with a Jackson error before it reaches any business logic:
+
+```
+Cannot deserialize value of type `java.util.ArrayList<java.util.Map<String,Object>>`
+from String value (token `JsonToken.VALUE_STRING`)
+```
+
+Root cause: the server advertises an **empty schema** for its tools (`{"type":"object"}`, no property
+definitions), so a client has no type information to serialize against. Confirmed 2026-09-09 on:
+
+| Tool | Array argument | Fallback if it fails |
+|---|---|---|
+| `update_vibe_coding_block_code_search_replace` | `operations` | Use `update_vibe_coding_block_code` (full replace) |
+| `set_vibe_coding_block_action_visibility` | `updates` | **NONE — a human must fix it in Studio** |
+
+It is intermittent, and that is the trap: on 2026-09-09 both tools accepted the array early in a
+session and rejected it an hour later, same shapes, same session. Do not conclude from one success
+that the path is reliable for the rest of your work.
+
+**Why the second row is a security problem, not an inconvenience.** Every code push resets the block's
+auto-registered Actions to Softr's defaults, and the default for a `genericActions` **ADD_RECORD is
+`ALL_USERS`** — writable by logged-OUT visitors. The documented remedy is to re-tighten with
+`set_vibe_coding_block_action_visibility`. When that call is the one that fails, a routine cosmetic push
+silently leaves public write access on the block, and nothing in the push result says so: the push
+itself returns `errors: null, warnings: null`. Verified live 2026-09-09 — one push left four ADD_RECORD
+actions open across two blocks.
+
+**So treat permission restoration as a step that must be VERIFIED, never assumed:**
+
+1. Push the code.
+2. Call `set_vibe_coding_block_action_visibility` for every action that needs tightening.
+3. **Read the permissions back with `get_vibe_coding_block_settings` and confirm each one actually
+   changed.** A successful-looking sequence is not evidence; the failure is an argument rejection, so
+   the call errors rather than lying, but an agent that batches calls can easily miss which one failed.
+4. If any action is still `ALL_USERS`, **do not publish.** Report the exact list — page, block, action
+   type, data source — and have a human set them on the block's Actions tab in Studio.
+
+Do not improvise around a rejection. `update_vibe_coding_block_settings` is not a substitute: its schema
+is equally empty, it writes far more than one permission, and guessing its payload risks clobbering the
+block's data source connections. Restoring an older block version is not a substitute either — it
+reverts the code along with the permissions, undoing the change you just pushed.
+
+Both edit paths recompile, so both reset Action permissions either way (Hard Constraint 21).
 
 ## Adopting Studio-AI-generated code