@sacho/sacho 0.1.0-dev.14 → 0.1.0-dev.18

package/README.md

@@ -147,21 +147,37 @@ state that never shipped.
 Basic workflow
 --------------
 
-With `sacho` on your `PATH`, initialize it at the repository root and choose
-the version you are preparing:
+With `sacho` on your `PATH`, initialize it at the repository root:
 
 ~~~~ sh
 sacho init
-sacho next 1.2.0
 ~~~~
 
 Initialization creates *sacho.toml*, *changes.d/*, and *CHANGES.md*. It also
 sets up the merge integration supported by the detected version-control
 system. The interactive setup can infer an issue-link template from the
-repository URL and offer to install a Git pre-commit hook. Repository
+repository URL, offer headings found across an existing changelog as section
+configuration, and offer to install a Git pre-commit hook. Repository
 integrations use the executable that ran `init`; pass
 `--integration-executable PATH` to use another executable.
 
+If an existing *CHANGES.md* already has entries under `Unreleased` or
+`Version X`, import them before creating new fragments:
+
+~~~~ sh
+sacho import-unreleased
+~~~~
+
+Sacho shows any normalization diff before writing. The import creates one root
+fragment, or one fragment per populated configured section, records `X` as the
+next version when present, and leaves every released section unchanged.
+
+If the import did not infer a version, choose the version you are preparing:
+
+~~~~ sh
+sacho next 1.2.0
+~~~~
+
 Create one fragment for each user-visible change, then edit the path printed by
 the command:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sacho/sacho",
-  "version": "0.1.0-dev.14+4b1514b",
+  "version": "0.1.0-dev.18+feb52aa",
   "description": "An opinionated changelog manager",
   "license": "GPL-3.0-only",
   "author": "Hong Minhee <hong@minhee.org>",
@@ -24,12 +24,12 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@sacho/sacho-aarch64-apple-darwin": "0.1.0-dev.14+4b1514b",
-    "@sacho/sacho-aarch64-pc-windows-msvc": "0.1.0-dev.14+4b1514b",
-    "@sacho/sacho-aarch64-unknown-linux-musl": "0.1.0-dev.14+4b1514b",
-    "@sacho/sacho-x86_64-apple-darwin": "0.1.0-dev.14+4b1514b",
-    "@sacho/sacho-x86_64-pc-windows-msvc": "0.1.0-dev.14+4b1514b",
-    "@sacho/sacho-x86_64-unknown-linux-musl": "0.1.0-dev.14+4b1514b"
+    "@sacho/sacho-aarch64-apple-darwin": "0.1.0-dev.18+feb52aa",
+    "@sacho/sacho-aarch64-pc-windows-msvc": "0.1.0-dev.18+feb52aa",
+    "@sacho/sacho-aarch64-unknown-linux-musl": "0.1.0-dev.18+feb52aa",
+    "@sacho/sacho-x86_64-apple-darwin": "0.1.0-dev.18+feb52aa",
+    "@sacho/sacho-x86_64-pc-windows-msvc": "0.1.0-dev.18+feb52aa",
+    "@sacho/sacho-x86_64-unknown-linux-musl": "0.1.0-dev.18+feb52aa"
   },
   "publishConfig": {
     "access": "public",

package/skills/sacho/SKILL.md

@@ -89,13 +89,18 @@ Adopting Sacho in a project
 Run `sacho init` from the repository root. It creates `sacho.toml`,
 `changes.d/`, and `CHANGES.md`, and in a Git repository registers the merge
 drivers. Interactive setup infers issue-link templates from the remote and can
-install commit hooks; `sacho init --interactive` forces the questions and
-`--no-interactive` suppresses them.
-
-Adoption needs no migration. Sacho never rewrites existing released sections, so
-leave the old `CHANGES.md` history exactly as it is and start using fragments
-for the next version. Set that version with `sacho next 1.2.0` so the unreleased
-heading and `release` know what is being prepared.
+install commit hooks. When an existing changelog is present, it also offers
+level-three headings found across the changelog as section candidates and
+suggests directories and source path globs. `sacho init --interactive` forces
+the questions and `--no-interactive` suppresses them.
+
+Leave old released sections exactly as they are. If the current `Unreleased` or
+`Version X` region contains entries, run `sacho import-unreleased` before
+creating fragments. Inspect and confirm its normalization diff; in a
+noninteractive workflow, review the diff from the refused run before using
+`--force`. The command creates deterministic *imported-unreleased.md* fragments
+and infers the next version from `Version X`. If there are no current entries,
+skip the import and set the version with `sacho next 1.2.0`.
 
 Two configuration decisions matter early, both covered in
 `reference/configuration.md`: whether to enforce fragment coverage