chore(release): move the ORB target to 3.6.0 so the beta channel resumes

[JSONbored]

What

One line: orb-manifest.json 3.5.0 → 3.6.0.

Why

orb-v3.5.0 shipped as stable on 2026-07-27, but the manifest still declares 3.5.0 as the target. orb-release-core.ts deliberately refuses to cut a beta for a version that already has a stable tag:

A STABLE tag already exists for targetVersion (the manifest's own declared intent has already fully shipped) — cutting a beta for that exact version now would either collide with a pre-promotion beta tag or silently mean "another beta of an already-released version". Nothing is due until a human moves the manifest's target forward.

So every nightly orb-beta-release run since the stable release has reported due: false and done nothing. The beta channel has been dormant, with 73 image-relevant commits accumulated behind it — which is why the ORB server is still on beta.10.

This is the automation working as designed and waiting on the one step it never takes itself. The report already named the answer:

before	after
due: false	due: true
nextTag: orb-v3.5.0-beta.1 (already exists)	nextTag: orb-v3.6.0-beta.1
manifestStale: true	manifestStale: false
inferredVersion: 3.6.0	matches the target

3.6.0 is the tool's own inferredVersion, derived from the feat: commits since the last stable — not a number I picked.

Note

Nothing here surfaced that the channel had stalled; it just quietly reported due: false nightly. Worth a follow-up so a stale manifest is visible rather than silent, but that's a separate change from unblocking the release.

Merge order: #9776 (the migration boot-crash fix) must land before an image is actually cut.

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-29 08:08:28 UTC}

1 file · 1 AI reviewer · 1 blocker · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This is a one-line manifest bump (`orb-manifest.json` version field `3.5.0` → `3.6.0`) that unblocks the automated beta channel, which the linked `orb-release-core.ts` logic deliberately gates behind a manual manifest update once the previously-targeted version has already shipped stable. The change matches the described intent exactly, is trivial to verify against the referenced source logic (targetAlreadyStable check), and carries essentially no correctness risk on its own.

Nits — 3 non-blocking

• The PR description doesn't reference or link an eligible open issue authorizing this change, which this repo's contribution conventions require even for small maintainer-authored fixes.
• Confirm the noted merge-order dependency on fix(migrations): restore 0180's bytes and freeze released migrations against post-release edits (#9420) #9776 (migration boot-crash fix) is enforced before any image is actually cut, since this manifest bump alone will make `due: true` on the next beta workflow run.
• Consider filing the follow-up mentioned in the PR description (surfacing a stale manifest visibly instead of silently reporting `due: false`) as a tracked issue rather than leaving it as a note.

Concerns raised — review before merging

• No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. No linked issue detected: No closing reference or linked issue number was found in the PR metadata/body. — If this PR is intended to solve an issue, link it explicitly in the PR body.

Decision drivers

• ❌ Code review — 1 blocker (1 reviewer)
• ❌ Gate result — Blocking (Repo-configured hard blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ No-issue rationale	PR body explains why no issue is linked.
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (no linked issue context).
Validation posture	⚠️ 20/25	Preflight is ready, but the PR body does not name the validation run.
Contributor workload	✅ 10/10	Author activity: 14 registered-repo PR(s), 13 merged, 370 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 14 PR(s), 370 issue(s).
Improvement	ℹ️ Insufficient signal	risk: clean · value: insufficient-signal · LLM: minor

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository is registered but has no active allocation in the current snapshot.
• Public profile languages: not available
• Official Gittensor activity: 14 PR(s), 370 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Then work through the remaining 3 steps in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.