@remits/remits-cli 0.1.71 → 0.1.73

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@remits/remits-cli",
3
- "version": "0.1.71",
3
+ "version": "0.1.73",
4
4
  "description": "Local CLI for auth, component sync, and live test execution against Remits",
5
5
  "license": "MIT",
6
6
  "private": false,
@@ -657,10 +657,22 @@ surface, not a deploy.
657
657
  - `mcp_component_edit` `mode:'stage'` → writes the staging cache (Redis). `mode:'commit'` → writes the field
658
658
  to the **live DB** and **clears** that component's staging entries. `editMode:'replace'` swaps the whole
659
659
  field; `editMode:'targeted'` does anchor-verified line edits.
660
+ - **A `mode:'commit'` promotes ALL of that component's staged fields in one save, not just the named field.**
661
+ Committing `source` also flushes a staged `path` (etc.) and then clears the whole staging entry. The result
662
+ reports the full set in `persist.committedFields` + `persist.stagingCleared` — trust that, and do **not**
663
+ try to "finish" by re-committing a sibling field that was already flushed.
660
664
  - `mcp_component_commit` (`read`/`commit`/`clear`) enumerates staged entries and can flush or clear them.
665
+ - **An empty staging scope is the clean, already-promoted state — not a failure.** A `commit`/`clear` against a
666
+ component (or scope) with nothing staged returns a benign success (`alreadyClean:true`, `committedCount:0`),
667
+ not an error. "No staged changes found" means *already promoted*, never *partial commit*. The staging cache
668
+ is a dev-override artifact; its emptiness is the goal. Verify what's actually in the DB with
669
+ `mcp_component_view` / `mcp_integration_validate` — never gate a commit/verification on staging-cache state.
661
670
  - **Commit bypasses the staged-override path entirely** (it writes the DB and clears staging), so committing
662
671
  is the way to make a change durable and to stop a stale staged entry from shadowing the live component in
663
672
  later test runs.
673
+ - `remits-cli components sync` (the `commit`/`sync` mode on the `components` endpoint) syncs the DB from the
674
+ git remote and then **also clears the staged entries** for the synced components, so a clean commit leaves a
675
+ clean staging cache on both the CLI and MCP-tool surfaces.
664
676
 
665
677
  ### Stale after sync / commit (the in-memory compile cache)
666
678