conduyt 1.64.0 → 1.65.0

package/README.md

@@ -53,7 +53,7 @@ conduyt pipelines archive <id> --move-open-deals-to <pipelineId|none> [--expecte
 conduyt pipelines settings-revision   # the account settingsRevision to pass as --expected-settings-revision to archive / delete-stage (409 stale_settings_revision when settings changed since)
 conduyt pipelines restore <id>          # bring an archived pipeline back (last in the menu, never the default; 409 name_taken)
 conduyt pipelines reorder --order id1,id2 --expected-revision id1,id2   # board-menu order in one transaction (409 order_changed prints the current revision); `reorder-stages <pipelineId>` does the same for a pipeline's columns
-conduyt pipelines delete-stage <pipelineId> <stageId> [--move-to <stageId>] [--expected-settings-revision N]   # move the live deals to another stage and delete this one; a stale revision is 409 stale_settings_revision
+conduyt pipelines delete-stage <pipelineId> <stageId> [--move-to <stageId>] [--expected-settings-revision N]   # soft delete: an empty stage always deletes (hidden everywhere, then 404, no restore, name reusable); --move-to re-homes live deals first; 409s print the server message (deals in it, used by N active automation(s), DPP map, pipeline_archived, intake_target, stale_settings_revision); a run parked before the delete fails at that step
 conduyt pipelines rot-days set <pipelineId> 21   # days without activity (1-90) before a deal reads "Stale in stage"; `rot-days get [pipelineId]` reads
 conduyt status-metadata list --stage-id <id>   # the status codes + buckets attached to stages; `get | create | update | delete | import` (update / delete take --expected-updated-at; 409 metadata_changed)
 conduyt status-metadata import --file rows.json --mode replace   # set-based import (max 1000; an item key outside stageId, code, bucket, lifecycleStage, dripEligible, dripTrackName, isTerminal, notes is refused before any request); per-item errors print and exit 1; `--mode replace` with no items is refused unless `--confirm-empty-replace` (it deletes every row). Timeouts: archive 75 s, import and the Mailchimp write / action commands 60 s; on a timeout the server may have applied it, so read the state first

package/dist/index.js

@@ -937,7 +937,7 @@ stageRules
 // isSystem included (a system holding stage automations route deals through; hidden from rep pickers, never won or lost)
 pipelines
     .command("update-stage <pipelineId> <stageId>")
-    .description("Update one stage (PATCH — only the fields you pass change). --is-system marks a system holding stage: automations route deals through it, reps never see it in a picker, and it can never be won or lost")
+    .description("Update one stage (PATCH — only the fields you pass change). --is-system marks a system holding stage: automations route deals through it, reps never see it in a picker, and it can never be won or lost. A soft-deleted stage (`pipelines delete-stage`) answers 404")
     .option("--name <name>", "stage name")
     .option("--color <hex>", "stage colour")
     .option("--is-won <bool>", "true|false — entering this stage closes the deal as won")
@@ -1030,7 +1030,7 @@ pipelines
 }));
 pipelines
     .command("delete-stage <pipelineId> <stageId>")
-    .description("Delete a stage (owner / admin key). Without --move-to the stage must have no deals; with it the live deals move to another stage of the SAME pipeline (same won / lost setting, not a system stage) and the stage is deleted in one transaction. A stage a soft-deleted deal still points at is refused. With --expected-settings-revision the answer is { id, deleted: true, settingsRevision }. Refusals exit 1 with the code printed: stale_settings_revision, pipeline_archived, intake_target (other 409s name the cause)")
+    .description("Soft-delete a stage (owner / admin key). An EMPTY stage can always be deleted, even if deals once used it: the row is kept so deal history and reports keep its name, but it is hidden from every pipeline / stage list, GET / PATCH on it answer 404, there is NO restore in v1, and its name may be reused by a new stage; its stage rule, outcome mappings and status metadata go with it. With --move-to the live deals move to another stage of the SAME pipeline (same won / lost setting, not a system stage) and the stage is deleted in one transaction. With --expected-settings-revision the answer is { id, deleted: true, settingsRevision }. A refusal exits 1 with the server's message printed verbatim and its code when it has one (never retried): deals currently in the stage and no --move-to; 'Cannot delete stage: it is used by N active automation(s) (names). Change their stage or pause them first.' (a published automation uses the stage in an action, trigger, condition or wait-until); the DPP status map selects it; stale_settings_revision, pipeline_archived, intake_target. A --move-to that is not a valid target is a 400. Accepted window: a run parked or in flight before the delete is not tracked; at the step that targets the deleted stage it fails or is skipped with a clear reason in the execution log")
     .option("--move-to <stageId>", "another stage of the same pipeline the live deals move to")
     .option("--expected-settings-revision <n>", "the settingsRevision from `pipelines settings-revision`; refused 409 stale_settings_revision when settings changed since")
     .action(run(async (client, pipelineId, stageId, opts) => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "conduyt",
-  "version": "1.64.0",
+  "version": "1.65.0",
   "description": "Command-line interface for Conduyt CRM — manage contacts, deals, pipelines, and run insight queries from your terminal.",
   "type": "module",
   "main": "dist/index.js",