create-grist-widget 0.3.28 → 0.3.29

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-grist-widget",
-  "version": "0.3.28",
+  "version": "0.3.29",
   "description": "Scaffold a new Grist custom widget from the grist-widget-sdk Vite template",
   "license": "MIT",
   "type": "module",

package/template/AGENTS.md

@@ -66,6 +66,10 @@ mapping, and rendering all live in `src/app/App.tsx` — that's the file to edit
    opening the `dev` → `main` PR: merging without a version bump publishes nothing (the
    release build silently no-ops whenever that version's directory already exists — the PR
    merges cleanly and CI reports success either way).
+5. **Template updates arrive with `create-grist-widget`.** Dependabot opens a pull request of
+   its own for it. Once that is merged into `dev`, run `pnpm exec create-grist-widget upgrade`
+   on `dev` in a follow-up pull request, then `pnpm install`, `pnpm typecheck`, `pnpm lint` and
+   `pnpm test`. It rewrites only the template's files (listed above) and says what it changed.
 
 ## Commands
 
@@ -108,6 +112,11 @@ creates a `gh-pages` branch — these settings can't be applied before that exis
 2. If that first workflow run fails with a permissions error pushing to `gh-pages`:
    Settings → Actions → General → Workflow permissions → **Read and write permissions**.
    Most repos don't need this; it depends on account/org defaults.
+3. After the first release (which commits to `main` and resets `dev`), a branch ruleset:
+   `main` requires a pull request and the `check` status, and blocks force pushes and
+   deletion; `dev` blocks force pushes and deletion. An agent acts through the owner's
+   account, so these rules don't tell it apart: they keep red changes off `main` whoever
+   merges. Ask the owner to set them; they need admin access.
 
 Full detail, including the two live URLs (`/latest/` and `/v<version>/`): `README.md`.
 

package/template/README.md

@@ -159,6 +159,20 @@ template's own files (this pipeline, the build config) arrive with
    read-only, which would fail the push to `gh-pages` with a 403.
 3. If the repo is private, set **Pages visibility to Public** — a widget
    embeds inside a Grist iframe, which needs a publicly reachable URL.
+4. **After the first release**, protect the branches: Settings → Rules →
+   Rulesets → New branch ruleset. Not before: the first release itself
+   commits to `main` and resets `dev` (see above).
+   - `main`: **Require a pull request before merging**, **Require status
+     checks to pass** with the `check` status from `ci.yml`, **Block force
+     pushes**, **Restrict deletions**. A change then reaches `main` only
+     through a green pull request (your `dev` → `main` release PR included).
+   - `dev`: **Block force pushes** and **Restrict deletions**. Not the
+     pull-request rule: the version bump before a release is pushed straight
+     to `dev`.
+
+   An AI agent working on this repo acts through your GitHub account, so
+   these rules can't tell it from you. They guarantee the outcome (nothing
+   red reaches `main`), whoever merges.
 
 No manifest/widget-catalog file is generated — that's a multi-widget,
 Grist-widget-repository concept this single-widget template doesn't need.

package/template/package.json

@@ -35,7 +35,7 @@
     "@types/react": "^19.3.0",
     "@types/react-dom": "^19.3.0",
     "@vitejs/plugin-react": "^6.1.2",
-    "create-grist-widget": "^0.3.28",
+    "create-grist-widget": "^0.3.29",
     "eslint": "^10.13.0",
     "eslint-plugin-react-hooks": "^7.0.1",
     "eslint-plugin-react-refresh": "^0.5.7",