logmv 0.7.1

Logged atomic file move and trash with an append-only JSON-Lines audit trail
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

# AGENTS.md

This file is the agent-facing instruction surface for the `logmv` repo. Future
automated tasks read it before making changes and follow the conventions below.

## Versioning

`logmv` is pre-1.0. Every change that alters observable behavior or fixes a bug
ships with a semver bump; docs-only and no-op changes bump nothing.

### Bump mapping (0.x)

| Kind of change | Bump | Example |
|---|---|---|
| Breaking (incompatible CLI surface or log-schema change) | **minor** (`0.x.y` -> `0.(x+1).0`) | removing or renaming a flag; changing the log line schema |
| Feature / new or changed observable behavior (backward-compatible) | **minor** (`0.x.y` -> `0.(x+1).0`) | adding `--mkdir`/`--rmdir`: `0.1.0` -> `0.2.0` |
| Bug fix / internal change (behavior corrected, or no observable change) | **patch** (`0.x.y` -> `0.x.(y+1)`) | wrong exit code fixed; refactor with identical output |
| Docs-only / no-op | **none** | a pure documentation task bumps nothing |

Pre-1.0 there is no major tier, so any observable behavior change (breaking or
additive) bumps the minor, fixes and internal-only changes bump the patch, and
docs/no-op changes bump nothing. Breaking and feature are both minor in 0.x; keep
that distinction in the commit or PR message. Revisit this mapping when the
surface stabilizes toward 1.0. The convention is forward-looking; history is not
re-tagged.

### Applying the bump

Compute the target version from the mapping, then run:

```
cargo set-version <X.Y.Z>
cargo update -p logmv
```

`cargo set-version <X.Y.Z>` updates `[package] version` in `Cargo.toml`. It does
not always touch `Cargo.lock` (the standalone `cargo-set-version` updates the
manifest only), so the follow-up `cargo update -p logmv` (or any `cargo build`)
syncs `Cargo.lock` to the new version.

`cargo set-version --bump <minor|patch>` is a cargo-edit-only convenience and may
not work on every machine: a standalone `cargo-set-version` binary can shadow
cargo-edit on `PATH` and reject `--bump`. Prefer the explicit-version form above.

No-helper fallback (nothing extra to install): hand-edit `[package] version` in
`Cargo.toml`, then run `cargo update -p logmv` to regenerate `Cargo.lock`.

### When

Apply the bump at the task's `done` stage, in the terminal commit that lands the
change (or immediately before it), so the version bump ships in the same commit
as the behavior change or fix it describes. Both behavior changes and bug fixes
bump; only docs-only or no-op tasks skip it.

### Source of truth

`Cargo.toml` `[package] version` is the single source of truth for the version.
`Cargo.lock` does not update itself when the manifest version changes; sync it
with the follow-up `cargo update -p logmv` (or any `cargo build`) after the bump.

## Changelog

`CHANGELOG.md` follows [Keep a Changelog](https://keepachangelog.com/). Every
change adds an entry under `## [Unreleased]`; at release, entries move under a
new dated version heading matching `[package] version`.