kylon-cli 0.7.0-next.873 → 0.7.0-next.875

package/README.md

@@ -444,6 +444,30 @@ just released, with `enabled: true` and `rolloutPercentage: 100`. A staged
 rollout on dev would serve no purpose: the prerelease it points at is the only
 build `@next` resolves to, so anyone tracking `next` is getting it regardless.
 
+**Any CLI publish workflow run on `develop` converges the dev policy with the
+real `@next`** — not only a run that published something. The job runs in one
+of three modes, reported by the classifier as `sync_reason`:
+
+| `sync_reason` | What happened | What the sync does |
+| --- | --- | --- |
+| `published` | this run released a prerelease | point the entry at it |
+| `this_run_already_published` | a full re-run whose own version is already on npm | re-run the outstanding reconciliation |
+| `ordinary_dedup_reconcile_current_next` | the bundle is identical to what `@next` already carries, so nothing was published | reconcile the entry toward the version `@next` already serves |
+
+The third mode is the one to understand: **when there is no new bundle, the run
+only bootstraps or repairs the config.** It publishes nothing, mints no
+version, never touches a dist-tag, and writes no revision at all when the entry
+is already correct. The version it converges on is never hypothetical — it is
+read from the registry, must be an exact `X.Y.Z-next.N`, and is the build every
+`@next` install is already getting.
+
+That mode exists because the previous behaviour had a bootstrap gap. The merge
+that shipped this sync (#6692) changed no CLI bundle, so content dedup skipped,
+the sync job's condition rejected an ordinary skip, and the dev
+`cli_auto_update/next` entry — which did not exist yet — was never created. An
+identical bundle is a reason not to publish; it is not a reason to leave the
+dev policy unreconciled.
+
 The job verifies that `kylon-cli@next` actually resolves to the published
 version before writing (retrying for registry read lag), and writes through
 `upsertRuntimeConfigEntry`, so the same schema validation and
@@ -511,11 +535,25 @@ updating to it; that remains a separate, deliberate step.
 
 Two consequences worth knowing:
 
-- **A dedup-skipped prerelease changes nothing.** When content dedup decides the
-  bundle is identical to what `@next` already has, no version is published and
-  the dev policy is left exactly as it was — the existing target is still the
-  build `@next` serves. The sync never fabricates a version for a release that
-  did not happen.
+- **A dedup-skipped prerelease publishes nothing, but still reconciles.** When
+  content dedup decides the bundle is identical to what `@next` already has, no
+  version is published — and the sync job runs anyway, against the version
+  `@next` currently serves. Usually that is a no-op that writes no revision;
+  when the entry is missing or stale it is repaired on the spot. The sync never
+  fabricates a version for a release that did not happen: the only version it
+  can write is one it read off the registry.
+
+  A run with no release of its own also never moves the dist-tag. If it finds
+  the row pointing at something newer than `@next`, that winner belongs to the
+  run that published it, and that run converges both surfaces itself — so this
+  one records a `superseded` no-op instead of racing it. For the same reason a
+  registry it cannot read — or one serving a version this workflow does not
+  own — is a `::warning::` and a green run here, not a red one, and that holds
+  for **every** registry read the job takes: the read that picks the target and
+  the read the reconciliation itself takes just before it writes. Nothing was
+  published, nothing was written, nothing is at risk, and the next push
+  reconciles again. The downgrade stops there: a schema rejection, a lost CAS
+  fence or a database error still fails the job on this trigger too.
 - **A failed sync fails the run, loudly, and re-running repairs it.** The npm
   publish is irreversible, so the sync cannot be retried by re-publishing. If
   the config write fails (or `@next` does not converge on the published
@@ -528,14 +566,16 @@ Two consequences worth knowing:
   `reconcile_only`, so it publishes nothing but still runs the sync job. The
   reconciliation is idempotent and reads the live dist-tag, so it either repairs
   the stale entry, finds it already correct, or finds that a newer prerelease
-  has superseded this one and leaves the newer target alone. That is distinct
-  from an ordinary content-dedup skip, which publishes nothing and reconciles
-  nothing. If the re-run also fails, set `cli_auto_update/next` in the dev admin
-  runtime config by hand.
+  has superseded this one and leaves the newer target alone. That stays distinct
+  from an ordinary content-dedup skip: both start a sync, but only the re-run
+  has a release of its own to reconcile, so only it may claim one. If the re-run
+  also fails, set `cli_auto_update/next` in the dev admin runtime config by
+  hand.
 
   The classifier that tells those two skips apart is
-  `scripts/ci/cli-prerelease-npm.sh`, and every registry lookup in it retries
-  and fails closed. A transient `npm view` error is not evidence that a version
+  `scripts/ci/cli-prerelease-npm.sh` — it emits `sync_reason`, and keeps
+  `reconcile_only` reserved for the re-run case — and every registry lookup in
+  it retries and fails closed. A transient `npm view` error is not evidence that a version
   is unpublished; treating it as such is what would let a failed reconciliation
   hide behind a green re-run. The dist-tag's own version is used as a second,
   independent confirmation of the same fact.

package/dist/kylon-bundle.manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.7.0-next.873",
-  "fingerprint": "1e155dfa2a8b6676fcf6d7fe7d69cd4cd0ff6b725e9af48383f0ae4e47151b83",
-  "source_commit": "b0c31dbf9e8413ecb155cb8693e1170eb6cf99d5"
+  "version": "0.7.0-next.875",
+  "fingerprint": "6afd9198deddd96f55316e84c131f482a7b12f33849ab78fbecdec2328cddb2b",
+  "source_commit": "c349c0b1c402139cee1b2e61544cd5dde4357860"
 }