filekeeper-cli 0.1.6__tar.gz → 0.1.7__tar.gz

{filekeeper_cli-0.1.6 → filekeeper_cli-0.1.7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: filekeeper-cli
-Version: 0.1.6
+Version: 0.1.7
 Summary: Safe, predictable filesystem operations for humans and AI agents, with atomic writes and workspace confinement.
 Keywords: filesystem,atomic-write,cli,agents,mcp
 Author: sangingeum
@@ -333,7 +333,10 @@ meaning — the path the operation targets — so existing readers are unaffecte
 A refused undo is recorded too: the ledger gains an `undo_refused` row with the
 target path, the conflict code, and the paths that blocked the undo. It changed
 nothing, so it carries no items, is never offered as undoable, and `undo-last`
-skips it. Every recorded path is workspace-relative, never a resolved host path.
+skips it. A refusal of a refusal is the one exception: undoing that
+`undo_refused` row is refused with the same coded error, but writes no second row,
+because the existing row already states the conflict. Every recorded path is
+workspace-relative, never a resolved host path.
 
 `keeper file read` writes file content to standard output unchanged (line endings
 included). Metadata goes to stderr, or into the JSON object with `--json`.
@@ -407,6 +410,13 @@ preview was computed against. The same shape applies to every mutating command a
 to the MCP tools that mirror them. A committed operation still reports
 `"changed": true` with its observed `after_hash`.
 
+`changed` and `would_change` answer different questions: `would_change` asks
+whether the bytes would differ, while `changed` records whether an operation
+executed and was journalled — so a real write of identical content reports
+`"changed": true` and adds a history row, which callers may rely on as proof a
+write completed. In a preview the two cannot disagree: when `would_change` is
+false, every item reports `"unchanged"`.
+
 Editing results add `match_stage` and `match_count` (text replacement),
 `preview_diff` (dry run), and, for patches, `patch_files` with per-hunk status.
 A failure that was rolled back reports the restored paths in the error details.

{filekeeper_cli-0.1.6 → filekeeper_cli-0.1.7}/README.md

@@ -312,7 +312,10 @@ meaning — the path the operation targets — so existing readers are unaffecte
 A refused undo is recorded too: the ledger gains an `undo_refused` row with the
 target path, the conflict code, and the paths that blocked the undo. It changed
 nothing, so it carries no items, is never offered as undoable, and `undo-last`
-skips it. Every recorded path is workspace-relative, never a resolved host path.
+skips it. A refusal of a refusal is the one exception: undoing that
+`undo_refused` row is refused with the same coded error, but writes no second row,
+because the existing row already states the conflict. Every recorded path is
+workspace-relative, never a resolved host path.
 
 `keeper file read` writes file content to standard output unchanged (line endings
 included). Metadata goes to stderr, or into the JSON object with `--json`.
@@ -386,6 +389,13 @@ preview was computed against. The same shape applies to every mutating command a
 to the MCP tools that mirror them. A committed operation still reports
 `"changed": true` with its observed `after_hash`.
 
+`changed` and `would_change` answer different questions: `would_change` asks
+whether the bytes would differ, while `changed` records whether an operation
+executed and was journalled — so a real write of identical content reports
+`"changed": true` and adds a history row, which callers may rely on as proof a
+write completed. In a preview the two cannot disagree: when `would_change` is
+false, every item reports `"unchanged"`.
+
 Editing results add `match_stage` and `match_count` (text replacement),
 `preview_diff` (dry run), and, for patches, `patch_files` with per-hunk status.
 A failure that was rolled back reports the restored paths in the error details.

{filekeeper_cli-0.1.6 → filekeeper_cli-0.1.7}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "filekeeper-cli"
-version = "0.1.6"
+version = "0.1.7"
 description = "Safe, predictable filesystem operations for humans and AI agents, with atomic writes and workspace confinement."
 readme = "README.md"
 requires-python = ">=3.12,<3.13"

{filekeeper_cli-0.1.6 → filekeeper_cli-0.1.7}/pyproject.toml.orig

@@ -1,6 +1,6 @@
 [project]
 name = "filekeeper-cli"
-version = "0.1.6"
+version = "0.1.7"
 description = "Safe, predictable filesystem operations for humans and AI agents, with atomic writes and workspace confinement."
 readme = "README.md"
 requires-python = ">=3.12,<3.13"

{filekeeper_cli-0.1.6 → filekeeper_cli-0.1.7}/src/filekeeper/__init__.py

@@ -23,7 +23,7 @@ from .core import (
     Workspace,
 )
 
-__version__ = "0.1.6"
+__version__ = "0.1.7"
 
 __all__ = [
     "CallerSurface",

{filekeeper_cli-0.1.6 → filekeeper_cli-0.1.7}/src/filekeeper/core/history/undo.py

@@ -366,7 +366,12 @@ def undo_operation(
     try:
         steps = _plan(journal, record)
     except UndoConflictError as exc:
-        _record_refusal(journal, record, exc, actor=actor, task_id=task_id)
+        # A refusal of another refusal adds nothing: the first row already
+        # records that this conflict was seen and nothing changed. Journalling
+        # the repeat would be noise, not new evidence, so only a refusal of a
+        # real operation is recorded.
+        if record.operation_type != UNDO_REFUSED:
+            _record_refusal(journal, record, exc, actor=actor, task_id=task_id)
         raise
     undo_items = _undo_items(record)
 

{filekeeper_cli-0.1.6 → filekeeper_cli-0.1.7}/src/filekeeper/core/models.py

@@ -316,19 +316,22 @@ def as_dry_run(
     or item size, no operation id and nothing undoable. The prediction a caller
     may legitimately want survives as ``predicted_after_hash`` on the result,
     each item and each patch file.
+
+    Item ``change`` values agree with ``would_change``: a preview that would
+    alter nothing reports every item as ``"unchanged"``, so the item list never
+    contradicts the operation-level verdict. The item stays in the list, because
+    callers use it to map a preview to the paths it inspected.
     """
 
-    return replace(
-        result,
-        changed=False,
-        after_hash=None,
-        operation_id=None,
-        undo_available=False,
-        would_change=would_change,
-        predicted_after_hash=predicted_after_hash,
-        items=tuple(
+    items: list[OperationItemResult] = []
+    for item in result.items:
+        change: Literal["created", "modified", "deleted", "moved", "unchanged"] = (
+            item.change if would_change else "unchanged"
+        )
+        items.append(
             replace(
                 item,
+                change=change,
                 after_hash=None,
                 size_bytes=None,
                 predicted_after_hash=(
@@ -337,8 +340,17 @@ def as_dry_run(
                     else item.after_hash
                 ),
             )
-            for item in result.items
-        ),
+        )
+
+    return replace(
+        result,
+        changed=False,
+        after_hash=None,
+        operation_id=None,
+        undo_available=False,
+        would_change=would_change,
+        predicted_after_hash=predicted_after_hash,
+        items=tuple(items),
         patch_files=tuple(
             replace(
                 patch_file,