instar 1.3.157 → 1.3.158

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.157",
+  "version": "1.3.158",
   "description": "Coherence infrastructure for self-evolving AI agents — on the Claude Code or Codex subscription you already have.",
   "type": "module",
   "main": "dist/index.js",

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-05-31T09:52:37.332Z",
-  "instarVersion": "1.3.157",
+  "generatedAt": "2026-05-31T09:57:14.699Z",
+  "instarVersion": "1.3.158",
   "entryCount": 193,
   "entries": {
     "hook:session-start": {

package/upgrades/1.3.158.md

@@ -0,0 +1,22 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+**The publish workflow now survives the publish-vs-merge git race.** Publishes are already serialized against each other (workflow concurrency group), but a concurrent PR merge — a separate workflow — can still move `main` between a publish's fetch and its final `git push`, which rejected the push and failed the release run (leaving npm briefly ahead of the committed version on main). The "Commit version bump & tag" step now retries that push: on a rejection it fetches and rebases the release commit onto the updated main and pushes again (up to five attempts). Because a concurrent merge never bumps npm, the version the run already resolved stays valid, so the rebase needs no version re-resolution. The version tag is now created on the final, landed commit. If a rebase ever hits a real conflict the run aborts loudly rather than force-pushing.
+
+## What to Tell Your User
+
+Nothing user-facing — this is release-pipeline robustness. When two changes hit the main branch at the same moment, a release that would previously have failed its final push now quietly rebases and completes, so versions on the registry and in the repository stay in step.
+
+## Summary of New Capabilities
+
+- The publish workflow's commit-and-push step retries with a fetch + rebase on a rejected push, then pushes the version tag on the commit that actually landed.
+- The common path (push succeeds on the first try) is unchanged; the retry only runs on a rejected push, so a successful publish behaves exactly as before.
+
+## Evidence
+
+- `js-yaml` parse of `.github/workflows/publish.yml` succeeds; the commit step contains the rebase-retry loop and tags after the branch push.
+- Pairs with the per-PR release-note fragment system (this very note is a fragment): fragments removed the PR-level NEXT.md collisions, this removes the publish-level git-push collision.

package/upgrades/side-effects/publish-push-retry.md

@@ -0,0 +1,27 @@
+# Side-effects review — publish-vs-merge push retry
+
+Seven-dimension review for the `.github/workflows/publish.yml` "Commit version bump & tag" change (retry-with-rebase on a rejected push).
+
+## 1. Security
+No new secrets, tokens, or permissions. Uses the same `RELEASE_TOKEN`/checkout already in the job. `git rebase`/`git fetch` operate only on `main`. No force-push (a conflict aborts loudly instead).
+
+## 2. Blast radius (release pipeline — highest concern)
+This is the one workflow nothing else can tolerate breaking. Mitigation: the change is **downside-bounded** — the common path is `git push origin main` exactly as before; the retry loop only executes when that push is *rejected*. A bug in the retry can therefore only affect the already-failing case (which previously failed outright), never a successful publish. YAML validated via `js-yaml`.
+
+## 3. Correctness
+Concurrent merges are not releases (they never bump npm), so the version this run resolved remains valid after rebasing onto them — no version re-resolution needed. The version tag is created after the successful branch push, so it always points at the commit that actually landed. Newly-arrived release-note fragments from the concurrent merge survive the rebase (this run's commit only deleted the fragments it assembled) and ride to the next publish — consistent with the fragment system.
+
+## 4. Rollback
+Revert the one workflow step (or the commit). No state migration, no persisted data. Reverting restores the prior single-push behavior exactly.
+
+## 5. Observability
+On a rejected push the step logs the attempt + reason; on an unrecoverable conflict it emits a GitHub `::error::` and exits non-zero (visible failed run) rather than silently proceeding.
+
+## 6. Multi-machine / concurrency
+This IS the concurrency fix. Publishes are serialized by the workflow `concurrency` group; this closes the remaining publish-vs-merge gap. Retry cap of 5 bounds the loop.
+
+## 7. Backward compatibility
+Pure workflow change; no API, config, schema, or agent-installed-file change. Existing releases behave identically on the common (no-race) path.
+
+## Second-pass review
+Release-pipeline change — a human reviewer sign-off on the workflow diff is appropriate before relying on it under heavy churn. The downside-bounded property (common path unchanged) makes shipping low-risk in the interim.