changeledger 0.9.0 → 0.11.0

package/templates/contract/implement.md

@@ -13,7 +13,9 @@ current throughout execution.
 ## Git protects traceability
 
 Never implement approved changes on `main`, `master`, or `dev`; create or switch
-to a work branch or ask the human before continuing. Inspect the worktree first. If
+to a work branch or ask the human before continuing. When the config declares
+`git.integration_branch`, create change branches from it and integrate the
+finished result into it; `main` stays reserved for releases. Inspect the worktree first. If
 unrelated changes exist, do not include them silently; ask the human whether to
 stash, commit, ignore or include them before changing the worktree.
 
@@ -35,7 +37,18 @@ Commit messages use the canonical shape:
 feat(scope): description [#20260629-234939]
 ```
 
-Use the actual change id and the appropriate conventional type. If shared files make a combined commit
+Use the actual change id and the appropriate conventional type. One change keeps
+its marker at the end of the subject. Referencing more than one change keeps the
+subject clean and puts separate brackets in one canonical body line:
+`ChangeLedger: [#A] [#B]` — never a comma list in one bracket. Ledger
+meta-commits (status, review, log, archive) carry markers like any other commit;
+only merge commits and `chore(release)` prep are exempt. `changeledger commit -m
+"<type>(<scope>): <desc>" [--id <id>]...` composes and creates the commit for
+you: it resolves the single `in-progress` change automatically when `--id` is
+omitted, and fails without committing if that is ambiguous or the subject isn't
+conventional. `changeledger check --commits [<base>]` lints `<base>..HEAD` for
+either canonical marker placement with the same
+exemptions — run it before requesting review. If shared files make a combined commit
 unavoidable, record it in Log or the handoff and name every change sharing the
 surface.
 
@@ -53,6 +66,7 @@ Useful mutation commands:
 - `changeledger owner <id> <name|->`
 - `changeledger review <id> pass|fail`
 - `changeledger check [id]`
+- `changeledger commit -m "<type>(<scope>): <desc>" [--id <id>]...`
 
 When implementation and every task are complete, move to `in-review` if the type
 requires independent review by running this ordered gate — do not reconstruct it from memory:

package/templates/contract/spec.md

@@ -38,7 +38,7 @@ headings. Required and optional frontmatter:
 ---
 id: "20260613-134548"
 title: Short, clear title
-type: feature                  # feature | bug | audit | refactor | chore
+type: feature                  # feature | bug | audit | refactor | chore | quick
 status: draft                  # lifecycle value
 created: 2026-06-13T13:45:48Z # full ISO 8601 UTC
 depends_on: []                 # change ids or external project:id refs
@@ -78,11 +78,23 @@ Default activation matrix:
 | audit | ✓ | ✓ | — | — | — | ✓ |
 | refactor | ✓ | — | ✓ | — | ✓ | ✓ |
 | chore | ✓ | — | — | — | ✓ | — |
+| quick | ✓ | — | — | — | — | ✓ |
 
 The configured matrix is authoritative. For bugs, Investigation contains the
 root cause; for audits, it is the core analysis. Proposal includes the chosen
 solution, discarded alternatives and scenarios.
 
+`quick` is a lighter lane for small, reversible, single-concern work that does
+not expand public surface or persistent truth (`specs/`): document only
+Request and Log, ~10-15 lines. It keeps the same human `draft → approved` gate
+and `[#id]` commit marker as any other type, skipping only `in-review`. If
+scope grows mid-execution beyond that eligibility, discard the change and
+recreate it under the correct type instead of continuing under `quick`.
+
+Before writing Investigation, run `changeledger search <terms from the request>`
+and record anything relevant as `depends_on` or a mention — do not rediscover
+work another change or spec already covers.
+
 When a relationship, flow or architecture is clearer visually, use a Mermaid
 block and keep its text as the source; the viewer renders it.
 
@@ -155,6 +167,7 @@ title, stage prose, scenario content and task descriptions.
 - `changeledger check [id]` — validate one change or the repository.
 - `changeledger list [--status S] [--type T] [--json]` — inspect/filter changes.
 - `changeledger show <id> [--json]` — inspect one resolved change.
+- `changeledger search <terms...> [--type T] [--status S] [--json]` — find related changes and specs by content.
 - `changeledger owner <id> <name|->` — set or clear responsibility.
 
 Run `changeledger <command> --help` for exact options; the commands support the