fix(changesets): stop re-formatting release notes that already shipped

.changeset/changeset-version-stops-rewriting-published-notes.md

@@ -0,0 +1,28 @@
+---
+'hotcrm': patch
+---
+
+Releasing HotCRM no longer re-formats release notes that have already shipped, and
+one mangled field name in the published 3.0.0 notes is repaired.
+
+`changeset version` re-printed the whole of `CHANGELOG.md` through Prettier on every
+run, because Prettier is on unless a project turns it off and this repo never set the
+key. Prettier re-pairs emphasis delimiters across a paragraph, so an underscore inside
+a field name gets paired with the underscore of a nearby italic span and both are
+re-emitted with the wrong delimiters. Names that identify a real column turn into text
+that identifies nothing, the command exits 0, and the churn sits inside a
+several-thousand-line addition where nobody would see it.
+
+It had already happened once, in text that shipped: the 3.0.0 notes say the renewal
+task writes `due*date` and `related_to*\*` where the changeset that produced them said
+`due_date` and `related_to_*`. That line is repaired back to what the release actually
+said — the one hand-edit of the generated region that is justified, because the
+generator is what broke it.
+
+`.changeset/config.json` now sets `prettier: false`, so a release section is written
+once and never re-formatted afterwards. Measured, not read out of the docs: on a
+throwaway copy of the tree, `changeset version` with Prettier on rewrites four further
+lines of the shipped 3.0.0 notes (`forecast_category` → `forecast*category`,
+`is_active` → `is*active`, and the two italic spans either side of them); with
+`prettier: false` the entire pre-existing file comes back byte-identical and the run
+only prepends the new section.

.changeset/config.json

@@ -1,6 +1,7 @@
 {
   "$schema": "https://unpkg.com/@changesets/config@3.1.2/schema.json",
   "changelog": "@changesets/cli/changelog",
+  "prettier": false,
   "commit": false,
   "fixed": [],
   "linked": [],

CHANGELOG.md

@@ -1132,7 +1132,7 @@ Email` / `Contact Owner Email` / `Lead Owner Email` target the real ownership
   `content/docs/sales/activities.mdx` 及其 zh-Hans / zh-Hant 双语在 **Recurring tasks / 重复任务**一节的用例列表里列着「合同结束前 60 天的续约提醒——由合同流程自动设置」。两处都与源码不符：
 
   - **不是 60 天。** 写死 60 天的激活期任务已从 `src/objects/contract.hook.ts` 删除（原因写在该文件 `:121-124` 的注释里）。今天排续约提醒的是 `contract_renewal` 定时流程（`src/flows/contract-renewal.flow.ts`），每天 08:00 只扫 `status: 'activated'` 的合同，窗口取每份合同自己的 `renewal_notice_days`（`src/objects/contract.object.ts`，`defaultValue: 30`，逐份可设）。
-  - **不是重复任务。** 该流程的 `create_renewal_task` 节点写入的字段只有 subject / `type: 'follow_up'` / priority / status / due*date / owner_id / related_to*\*，没有任何重复字段。它每天重现靠的是「扫描 + 幂等闸门」——合同只要还挂着一条未完成的 `Renewal due` 任务，当天就算已处理——而不是 recurrence 机制。
+  - **不是重复任务。** 该流程的 `create_renewal_task` 节点写入的字段只有 subject / `type: 'follow_up'` / priority / status / due_date / owner_id / related_to_*，没有任何重复字段。它每天重现靠的是「扫描 + 幂等闸门」——合同只要还挂着一条未完成的 `Renewal due` 任务，当天就算已处理——而不是 recurrence 机制。
 
   改法按实测：本仓的重复任务**机制**是真的（`crm_task` 的 `is_recurring` / `recurrence_type` / `recurrence_interval` / `recurrence_end_date` 四个字段、表单的「重复规则」分组、`recurrence_fields_required` 校验规则，以及 `src/objects/task.hook.ts` 的 `task_recurrence` 钩子在完成时生成下一实例），但**没有任何自动化会创建重复任务**——`is_recurring` 在 `src/flows/`、`src/actions/`、`src/data/` 下零命中。因此这一条假用例被移除，改为如实写明：重复任务只由人工勾选发起；续约提醒则按每日扫描 + 每份合同的**续约通知（天）**（默认 30）写清真实工作方式，并指向 `content/docs/revenue/contracts.mdx` 的*每日——续约提醒*一节。口径与 `content/docs/sales/quotes.mdx` 已落地的接受链路一致。