softr-vibe-coding 2.5.1 → 2.5.2

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.2] - 2026-09-09
+- Permission finding is advisory, not a veto — report severity and leave the call to the builder
+
 ## [2.5.1] - 2026-09-09
 - The Action-permission reset has a failure mode that leaves blocks publicly writable — verify, never assume
 

package/SKILL.md

@@ -555,8 +555,11 @@ Non-negotiable rules. Most are enforced by the Softr platform (compiler, validat
     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.
+    **If any action is still `ALL_USERS`, report it WITH its severity and let the builder decide.**
+    Check the page's own VIEW permission first (`get_page_permissions`): a page gated to logged-in
+    users makes an open action housekeeping, a public page makes it a real hole. Surface the list
+    either way -- page, block, action type, data source -- and note that a human sets them on the
+    block's Actions tab. Do not unilaterally block a publish; it is not your app.
 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.1",
+  "version": "2.5.2",
   "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,7 +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 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. Report the list with its severity — check the page's VIEW permission with `get_page_permissions`, since a logged-in-gated page makes this housekeeping while a public page makes it a real hole — and let the builder decide whether it holds their release. A human sets them on the block's Actions tab |
 | 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

@@ -138,8 +138,29 @@ actions open across two blocks.
 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.
+4. If any action is still `ALL_USERS`, **report it and let the builder decide.** Check the page's own
+   VIEW permission first with `get_page_permissions`, because that is what sets the severity:
+   - **Page VIEW is gated** (e.g. `LOGGED_IN_USERS`) — an anonymous visitor cannot load the page at
+     all, so exploiting the open action means calling its endpoint directly, and the realistic worst
+     case is junk records rather than data exposure or deletion. Housekeeping: worth fixing on the
+     next Studio pass, not worth holding a release for.
+   - **Page VIEW is `ALL_USERS`** — the action permission is the only gate left. That is a genuine
+     hole and deserves to be called one.
+
+   Report page, block, action type, data source and current group; say which of the two cases applies;
+   note that a human sets them on the block's Actions tab in Studio. Then stop — **do not unilaterally
+   block the publish.** It is not your app, and the person whose app it is needs the finding and the
+   severity, not a veto.
+
+   One caveat worth stating: page visibility and action permissions are *separate* gates, and whether
+   Softr enforces page VIEW on the action endpoint itself is unverified here. The reason to treat a
+   gated page as low-severity is the practical difficulty and low blast radius, not a proof that the
+   action is unreachable. Say that plainly rather than implying the action is safe.
+
+   **Calibration matters.** This guidance read "do not publish" in v2.5.1 and immediately fired at
+   maximum severity on a logged-in-gated app where the real exposure was junk records. A warning that
+   cannot distinguish housekeeping from a breach gets tuned out, and then it is worth nothing on the
+   day it matters.
 
 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