@aiaiai-pt/frankctl 0.4.3 → 0.4.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aiaiai-pt/frankctl",
-  "version": "0.4.3",
+  "version": "0.4.4",
   "description": "Terminal-first client for the Frank Low-Code Pipeline platform",
   "homepage": "https://franksdocs.nomadriver.co",
   "repository": {

package/skills/frank-cli/SKILL.md

@@ -277,12 +277,24 @@ frankctl bd get <id>
 frankctl bd create -f bd.yaml
 frankctl bd update <id> -f patch.yaml
 frankctl bd delete <id> --yes          # does not delete underlying data
-frankctl bd sync <id>                  # trigger ontology sync, poll to terminal
+frankctl bd sync <id> [--force] [--no-wait]  # trigger ontology sync, poll exact run
 frankctl bd entities <id>              # read entities back out — confirm values landed
 ```
 
 `bd entities` closes the authoring loop: it reads the ontology to prove your rows
 actually materialized as entities, not just that the sync reported success.
+`bd sync --force` full-replays through REST even when the snapshot and effective
+mapping spec are unchanged. Normal output includes replay reason, row/snapshot
+evidence, and safe attempted/applied SyncSpec fingerprint prefixes. Human output
+prefers the precision-safe decimal string `snapshot_id_exact`; JSON exposes it
+alongside the legacy numeric `snapshot_id`.
+
+For an ordinary sync, the CLI falls back to BackingDataset status polling when
+an older API does not return exact-run evidence, and clearly marks replay
+evidence unavailable. `--force` does not fall back: it checks
+`/api/v1/backing-datasets/capabilities` before mutation and sends no sync POST
+unless version 2, exact-run polling, and force replay are explicitly supported.
+After the POST, it also requires `force_replay: true` confirmation.
 
 ### Runs