generatesaas 2.2.0 → 2.4.0

package/dist/skill/content/SKILL.md

@@ -21,7 +21,6 @@ Step 0: Pre-flight safety checks
 Step 1: Fetch + stage + prepare update data (you run the CLI, then the script)
 Step 2: Present changelog to user
 Step 2.5: Review newly available options - adopt or keep default (re-stage if adopted)
-Step 2.6: Companion source flips (only when the user asks)
 Step 3: Classify files (script)
 Step 4: Analyze dependencies
 Step 5: Present update plan - user chooses interaction mode
@@ -155,7 +154,7 @@ it stays complete). Read `newOptions` from `.generatesaas/staging.json`. **If it
 empty, skip this step entirely.**
 
 Otherwise, present each option so the user can decide whether to adopt it. Each entry has
-`{ key, label, hint, default, impact, requiresLabel? }`. For each one:
+`{ key, label, hint, default, impact, choices?, requiresLabel? }`. For each one:
 
 ```
 ### New since your version: {label}
@@ -173,14 +172,32 @@ it is a large surface you didn't originally choose" or "Safe to adopt - it is pu
 > 2. **Adopt it** - turn this feature on
 ```
 
+**An entry with `choices` is not a yes/no.** It takes one of several values, so the two-way block
+above cannot express it - offer the values as a numbered pick list instead, one line per choice,
+with the entry's `default` marked as the current behavior:
+
+```
+**Default:** `{default}` (your project's current behavior is unchanged).
+**My recommendation:** {your recommendation, naming one of the choices}
+
+> **Which would you like?**
+> 1. **`{choices[0]}`** {"(current)" on the one equal to default}
+> 2. **`{choices[1]}`**
+> 3. **`{choices[2]}`** ...one line per choice, however many there are
+```
+
 **Ask the user about every new option, in every mode - including Automatic.** Surfacing a new
 feature is exactly the kind of decision the update must never assume. Give your recommendation,
 but the user decides.
 
 **Applying the decisions:**
 
-1. For each option the user **adopts**, write its enabling value into `.generatesaas/manifest.json`
-   (e.g. set `"desktop": true`). The manifest is the single shaping input.
+1. For each option the user **adopts**, write the value they picked into
+   `.generatesaas/manifest.json` under the entry's `key`. For an option with no `choices` that value
+   is `true` (e.g. set `"desktop": true`); for one with `choices` it is the choice they named,
+   verbatim (e.g. set `"errorTracking": "sentry"`). Never write `true` for an option that has
+   `choices` - the CLI refuses any value outside them and stages nothing at all. The manifest is the
+   single shaping input.
 2. **If the user adopted at least one option, re-stage once** so re-shaping produces the
    feature's files. Re-run the CLI (append `auto` if you are in Automatic mode, so the staged
    metadata keeps the unattended signal):
@@ -199,41 +216,6 @@ but the user decides.
    before this point, so a re-stage never leaves a half-applied tree.
 4. If the user adopted nothing, continue to Step 3 directly.
 
-### Step 2.6: Companion Source Flips (only when the user asks)
-
-A companion-ON project records where its daemon comes from in `companionSource`
-("shared" points at an existing companion repo; "vendored" owns the daemon in this repo).
-Flipping it is a manifest edit + re-stage, exactly like option adoption in Step 2.5.
-**Never flip it unprompted** - only when the user explicitly asks to switch.
-
-**vendored -> shared** (abandons the in-repo daemon):
-
-1. Warn first and get explicit confirmation:
-
-   > Switching to a shared companion REMOVES `apps/companion` and `scripts/companion-export`
-   > from this project when the update is applied. Local customisations to the vendored daemon
-   > are abandoned (they survive only in git history), and your published companion repo stops
-   > receiving updates from this project. Continue?
-
-2. On confirmation, edit `.generatesaas/manifest.json`: set `"companionSource": "shared"`, add
-   `"companionRepoUrl"` (ask which repo; default `https://github.com/Duzbee/OpenCompanion`), and
-   REMOVE `"companionName"`.
-3. Re-run `npx generatesaas@latest update` to re-stage (append `auto` in Automatic mode), then
-   continue the normal flow. The CLI removes the now-stale `.generatesaas/companion-release.json`
-   on shared-source updates.
-4. Remind the user: their end-users keep running the OLD published daemon until they install the
-   shared one; after apply + deploy, the Companions page renders the new install command.
-
-**shared -> vendored** (take ownership of a daemon):
-
-1. Edit `.generatesaas/manifest.json`: set `"companionSource": "vendored"`, add
-   `"companionName"` (ask; default: the title-cased project name + " Companion"), and REMOVE
-   `"companionRepoUrl"`.
-2. Re-run `npx generatesaas@latest update` to re-stage. Applying vendors `apps/companion` + the
-   export pipeline, branded from the name.
-3. Remind the user: the Companions page shows a publish-first state until they run
-   `pnpm companion:publish`.
-
 ### Step 3: Classify Files
 
 ```bash

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "generatesaas",
-  "version": "2.2.0",
+  "version": "2.4.0",
   "type": "module",
   "description": "CLI for scaffolding and managing GenerateSaaS projects",
   "license": "UNLICENSED",