@getxflow/cli 0.32.0 → 0.33.0

package/dist/commands/db.js

@@ -130,7 +130,7 @@ async function dbStatus(args) {
     (0, ui_1.table)(rows);
     if (rows.some((row) => row[1] === 'applied, file changed')) {
         (0, ui_1.out)('');
-        (0, ui_1.warn)('A changed file will not be applied again: write a new migration');
+        (0, ui_1.warn)('A changed file is never applied again and db migrate refuses it: write a new migration');
     }
 }
 function serverRow(server) {

package/dist/help.js

@@ -354,13 +354,14 @@ kept for 7 days: that is a "caught it right away" safety net, not a backup.
 ${(0, ui_1.bold)('DROP DATABASE')} is never allowed, because the database is shared across the
 organization.
 
-Editing an already applied file achieves nothing: the comparison is by name, not by
-content. ${(0, ui_1.bold)('xflow db status')} lists such a file separately, so write a new migration
-instead.
+Editing an already applied file achieves nothing: ${(0, ui_1.bold)('migrate')} refuses a name that is
+already applied with different content, and ${(0, ui_1.bold)('xflow db status')} lists such a file
+separately. Write a new migration instead.
 
 One logical database can be attached to several projects, so the history may hold
 migrations that are not in your repository. That is normal, but it also means your
-migration can break somebody else's application.`,
+migration can break somebody else's application, and that a name already in that history
+is taken for you too: ${(0, ui_1.bold)('0001_init')} of a neighbour leaves yours no room.`,
     logs: `${(0, ui_1.bold)('xflow logs')} and ${(0, ui_1.bold)('xflow functions logs')}: project errors
 
 One stream per project: crashes of the released application in the browser and

package/dist/version.js

@@ -2,6 +2,6 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.DEFAULT_API_URL = exports.CLI_VERSION = void 0;
 /** Keep in sync with cli/package.json. */
-exports.CLI_VERSION = '0.32.0';
+exports.CLI_VERSION = '0.33.0';
 /** Overridden by XFLOW_API_URL or the `api` field in xflow.json. */
 exports.DEFAULT_API_URL = 'https://app.getxflow.com';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@getxflow/cli",
-  "version": "0.32.0",
+  "version": "0.33.0",
   "description": "CLI for the XFlow platform: source sync, deployment and publishing of applications",
   "license": "UNLICENSED",
   "engines": {

package/skills/xflow/SKILL.md

@@ -22,7 +22,7 @@ contains the fix.
 
 ## Keeping these instructions current
 
-These instructions ship with xflow CLI 0.32.0, so the copy you are reading can be older than
+These instructions ship with xflow CLI 0.33.0, so the copy you are reading can be older than
 the CLI answering your commands.
 
 When the CLI says this file does not match it, run `xflow skills --refresh` and then **read
@@ -48,8 +48,8 @@ the error points away from the cause. The sections below carry the details.
 3. Never delete a `functions/<name>/` directory unless the user asked for that
    function to go. The next deploy removes it from the cloud together with its
    schedules, and a function created again later gets a different address.
-4. An already applied migration is never re-run, so editing its file changes
-   nothing. A schema change is always a new file.
+4. An already applied migration is never re-run, and `xflow db migrate` refuses a
+   name it already holds with different content. A schema change is always a new file.
 5. When inserts start failing with `db_write_locked`, the database is over its plan size
    and Postgres itself refuses. Reads and deletes keep working, so the fix is a migration
    that deletes data, never a rewrite of the SQL. Write comes back within the hour.
@@ -450,8 +450,10 @@ xflow functions logs report                # empty output means it never crashed
 
 Schema changes are files: `migrations/0001_init.sql`, `migrations/0002_orders.sql`, applied
 in filename order by `xflow db migrate`. `xflow db status` shows what is applied and what
-waits. History lives in the database itself, so an already applied file is never re-run and
-editing it changes nothing: write a new migration instead.
+waits. History lives in the database itself, and the database can be shared with other
+projects of the organization, so a migration name is taken once for all of them: `migrate`
+refuses a name that is already applied with different content. Never edit an applied file,
+write a new migration instead.
 
 The browser never reaches the database directly. The app reads and writes through a cloud
 function, and inside the handler the connection string is already there: