lhumina_code/hero_macros_previous

Fork 0

make development compatible with main and other way around #1

New issue

Open

opened 2026-06-05 14:39:59 +00:00 by despiegk · 6 comments

despiegk commented

2026-06-05 14:39:59 +00:00

Owner

move all macros and supporting code to this repo
use mass update action on main to make sure we use these new macro's
no more dependency on hero_blueprint because this one is too new

so this will allow us to bring main back into development

and be compatible so we can easier make progress and move project per project over

checks

no repo (apart from _lib and _blueprint) uses _lib for derive and _blueprint
these repo's all use this macros_previous repo

- move all macros and supporting code to this repo - use mass update action on main to make sure we use these new macro's - no more dependency on hero_blueprint because this one is too new so this will allow us to bring main back into development and be compatible so we can easier make progress and move project per project over ## checks - [ ] no repo (apart from _lib and _blueprint) uses _lib for derive and _blueprint - [ ] these repo's all use this macros_previous repo

scott was assigned by despiegk

2026-06-05 14:40:03 +00:00

mik-tf commented

2026-06-05 16:18:34 +00:00

Owner

A few notes from the meeting to add on top of this, not replacing anything above.

On the old vs new question: this repo holds the previous, stable macros, the versions main already works with, not the latest fast moving ones. The name previous means the older known good set. The newer macros stay in hero_lib and hero_blueprint and keep evolving. Main pins this repo so it stops breaking when those change, and each repo migrates onto the new library one by one later. When the issue says use these new macros, new means the macros now living in this new repo, not a newer version.

The supporting code to move into this repo includes the OpenRPC clients, not only the derive macros. The aim is that main imports all of it from here.
Sequencing: once main pins this repo and no longer references the repos we are upgrading, those repos can be upgraded one by one without breaking main. Main stays on the stable set here while each project moves over on its own schedule.
The payoff is two-way. After main folds back into development, development is a superset of main, so a new version of something built on development can also go to main.
Suggested acceptance check to add: main builds and runs with this repo as the only source of macros, with no hero_blueprint dependency.

Signed-by: mik-tf mik-tf@noreply.invalid

A few notes from the meeting to add on top of this, not replacing anything above. On the old vs new question: this repo holds the previous, stable macros, the versions main already works with, not the latest fast moving ones. The name previous means the older known good set. The newer macros stay in hero_lib and hero_blueprint and keep evolving. Main pins this repo so it stops breaking when those change, and each repo migrates onto the new library one by one later. When the issue says use these new macros, new means the macros now living in this new repo, not a newer version. - The supporting code to move into this repo includes the OpenRPC clients, not only the derive macros. The aim is that main imports all of it from here. - Sequencing: once main pins this repo and no longer references the repos we are upgrading, those repos can be upgraded one by one without breaking main. Main stays on the stable set here while each project moves over on its own schedule. - The payoff is two-way. After main folds back into development, development is a superset of main, so a new version of something built on development can also go to main. - Suggested acceptance check to add: main builds and runs with this repo as the only source of macros, with no hero_blueprint dependency. Signed-by: mik-tf <mik-tf@noreply.invalid>

mik-tf commented

2026-06-05 16:21:13 +00:00

Owner

Summary of the task

The problem

Today the derive macros and their supporting code, including the OpenRPC clients, live in hero_lib and hero_blueprint. Those repos move fast and get big updates, and hero_blueprint in particular is too new for main. If we bring the current hero_lib and hero_blueprint into main, main stops building. So main and development have drifted apart and work gets stuck on one side.

The plan

This repo, hero_macros_previous, holds the previous stable macros and supporting code, the versions main already works with. Previous means the older known-good set, not the latest fast-moving one. The newer macros stay in hero_lib and hero_blueprint and keep evolving.
Move that stable set into this repo: the derive macros and the OpenRPC clients.
Run a mass update on main with the orchestrator so every repo depends on this repo instead of hero_lib for derive and hero_blueprint. After this, main imports everything macro related from here and has no dependency on hero_blueprint.
Because main is now pinned to this stable set and no longer references the repos we are upgrading, those repos can be upgraded one by one without breaking main. Each project moves over on its own schedule.
Once everything on main uses this repo, fold main back into development. development becomes a superset of main, so a new version of something built on development can also go to main.

The payoff

main builds and stays live again, which is what the sandbox needs to deploy from main. The two-way flow between main and development is restored, so newer work can reach the sandbox once each piece has moved over.

Checks

no repo, apart from hero_lib and hero_blueprint themselves, uses hero_lib for derive or hero_blueprint
all those repos use this hero_macros_previous repo
main builds and runs with this repo as the only source of macros, with no hero_blueprint dependency

Signed-by: mik-tf mik-tf@noreply.invalid

## Summary of the task ### The problem Today the derive macros and their supporting code, including the OpenRPC clients, live in hero_lib and hero_blueprint. Those repos move fast and get big updates, and hero_blueprint in particular is too new for main. If we bring the current hero_lib and hero_blueprint into main, main stops building. So main and development have drifted apart and work gets stuck on one side. ### The plan 1. This repo, hero_macros_previous, holds the previous stable macros and supporting code, the versions main already works with. Previous means the older known-good set, not the latest fast-moving one. The newer macros stay in hero_lib and hero_blueprint and keep evolving. 2. Move that stable set into this repo: the derive macros and the OpenRPC clients. 3. Run a mass update on main with the orchestrator so every repo depends on this repo instead of hero_lib for derive and hero_blueprint. After this, main imports everything macro related from here and has no dependency on hero_blueprint. 4. Because main is now pinned to this stable set and no longer references the repos we are upgrading, those repos can be upgraded one by one without breaking main. Each project moves over on its own schedule. 5. Once everything on main uses this repo, fold main back into development. development becomes a superset of main, so a new version of something built on development can also go to main. ### The payoff main builds and stays live again, which is what the sandbox needs to deploy from main. The two-way flow between main and development is restored, so newer work can reach the sandbox once each piece has moved over. ### Checks - [ ] no repo, apart from hero_lib and hero_blueprint themselves, uses hero_lib for derive or hero_blueprint - [ ] all those repos use this hero_macros_previous repo - [ ] main builds and runs with this repo as the only source of macros, with no hero_blueprint dependency Signed-by: mik-tf <mik-tf@noreply.invalid>

scott commented

2026-06-06 02:22:34 +00:00

Owner

Status report — `hero_macros_previous` freeze rollout

What this repo now provides

A frozen, self-contained snapshot of the macro/codegen toolchain so consumer repos stop tracking the still-moving hero_lib / hero_blueprint. Two branches, mirroring hero_lib:

main — old hero_rpc stack re-cut from the pre-bridge hero_blueprint@d31c7b6 (client macros emit ::hero_rpc2::, herolib-free) + a frozen new-gen derive hero_derive (from hero_lib@9657556a).
development — same old stack + hero_derive cut from hero_lib@d1383f58 (for consumers that pinned herolib_derive@development).

Both branches build green and carry zero git=hero_lib/hero_blueprint dependencies.

Migration recipes (mechanical, no source changes)

New-stack repos: herolib_derive = { package = "hero_derive", git = .../hero_macros_previous.git, branch = <same branch the repo pinned> }. All other herolib_* left live — the frozen macro emits against the consumer's live runtime, so hero_lib keeps moving. The package = rename avoids colliding with the herolib_derive that live herolib_core pulls transitively.
Old-stack repos: repoint hero_rpc_derive / hero_rpc_openrpc → hero_macros_previous, and add hero_rpc2 (the pre-bridge client macro emits ::hero_rpc2::, so it must be declared). Fully self-contained afterwards.

Rollout result (branch `development_freeze` pushed per repo; only that branch pushed)

✅ DONE — frozen + builds green, development_freeze pushed (8):
hero_shrimp, hero_redis (= hero_db), hero_planner, hero_code, hero_codescalers, hero_gpu, hero_indexer, hero_slides

⚠️ PARTIAL — integration freeze builds, but the repo's development branch is broken independent of this change (2):
hero_browser, hero_proc (e.g. proc dev references herolib_core::logger::LogDeleteScope, missing at its pinned hero_lib). Frozen on integration locally; dev held until their dev baseline is fixed.

⚪ NOOP — no herolib_derive/hero_rpc git dep, nothing to do (~19):
whiteboard, skills, archipelagos, biz, code_indexer, forge, foundry, kimi, kimi_rust, ledger, mail, researcher, router, webbuilder, website_framework, + non-Rust repos (builder, compute_config, compute_registry, deployment_docker).

⏸ DEFERRED — Blocker B (11): these don't build at baseline on integration, because they transitively pull a broken hero_rpc_derive from hero_blueprint/hero_rpc (mid-teardown) via other hero SDKs, or their own source uses old transport types:
agent, books, office, orchestrator, voice, proxy (transitive dual-source), editor (own source uses hero_rpc_openrpc::OpenRpcError), lib_rhai (complex mixed), wallet, voice_provider, matrixchat (baseline-broken via transitive blueprint dep).

⏸ TIER-3 — schema/server-macro adopters, deferred for team judgement (7):
compute, drive, logic, mycelium, os, osis, livekit (committed generated #[derive(OsisObject)] / inline server code — can't go self-contained; need the frozen hero_derive superset + live runtime).

Checklist status

no repo (apart from _lib and _blueprint) uses _lib for derive and _blueprint — 8/~41 done; the frozen hero_derive alias removes the direct moving-derive dependency on those. Remaining repos are Blocker-B (need their broken transitive hero_rpc SDK deps fixed first) or Tier-3.
these repos all use this macros_previous repo — in progress (8 pushed on development_freeze).

Key finding / next step

The dominant blocker is not the macro swap itself — it's that many integration repos don't build at baseline because they transitively depend on broken hero_blueprint/hero_rpc crates left mid-teardown. The freeze succeeds cleanly wherever the repo builds. Recommended next: fix that root cause (extend the freeze/[patch] to the leaf SDKs like hero_*_sdk that still pull hero_rpc_derive from blueprint), which should unblock most of the deferred set, then take Tier-3 with the team.

Nothing else pushed; all consumer changes are local on development_freeze branches pending review.

## Status report — `hero_macros_previous` freeze rollout ### What this repo now provides A **frozen, self-contained snapshot** of the macro/codegen toolchain so consumer repos stop tracking the still-moving `hero_lib` / `hero_blueprint`. Two branches, mirroring hero_lib: - **`main`** — old `hero_rpc` stack re-cut from the **pre-bridge** `hero_blueprint@d31c7b6` (client macros emit `::hero_rpc2::`, herolib-free) **+** a frozen new-gen derive `hero_derive` (from `hero_lib@9657556a`). - **`development`** — same old stack + `hero_derive` cut from `hero_lib@d1383f58` (for consumers that pinned `herolib_derive@development`). Both branches build green and carry **zero `git=hero_lib`/`hero_blueprint` dependencies**. ### Migration recipes (mechanical, no source changes) - **New-stack repos:** `herolib_derive = { package = "hero_derive", git = .../hero_macros_previous.git, branch = <same branch the repo pinned> }`. All other `herolib_*` left **live** — the frozen macro emits against the consumer's live runtime, so hero_lib keeps moving. The `package =` rename avoids colliding with the `herolib_derive` that live `herolib_core` pulls transitively. - **Old-stack repos:** repoint `hero_rpc_derive` / `hero_rpc_openrpc` → `hero_macros_previous`, **and add `hero_rpc2`** (the pre-bridge client macro emits `::hero_rpc2::`, so it must be declared). Fully self-contained afterwards. ### Rollout result (branch `development_freeze` pushed per repo; **only that branch pushed**) **✅ DONE — frozen + builds green, `development_freeze` pushed (8):** `hero_shrimp`, `hero_redis` (= `hero_db`), `hero_planner`, `hero_code`, `hero_codescalers`, `hero_gpu`, `hero_indexer`, `hero_slides` **⚠️ PARTIAL — integration freeze builds, but the repo's `development` branch is broken *independent of this change* (2):** `hero_browser`, `hero_proc` (e.g. proc dev references `herolib_core::logger::LogDeleteScope`, missing at its pinned hero_lib). Frozen on integration locally; dev held until their dev baseline is fixed. **⚪ NOOP — no `herolib_derive`/`hero_rpc` git dep, nothing to do (~19):** whiteboard, skills, archipelagos, biz, code_indexer, forge, foundry, kimi, kimi_rust, ledger, mail, researcher, router, webbuilder, website_framework, + non-Rust repos (builder, compute_config, compute_registry, deployment_docker). **⏸ DEFERRED — Blocker B (11):** these don't build at baseline on integration, because they transitively pull a **broken** `hero_rpc_derive` from `hero_blueprint`/`hero_rpc` (mid-teardown) via other hero SDKs, or their own source uses old transport types: `agent`, `books`, `office`, `orchestrator`, `voice`, `proxy` (transitive dual-source), `editor` (own source uses `hero_rpc_openrpc::OpenRpcError`), `lib_rhai` (complex mixed), `wallet`, `voice_provider`, `matrixchat` (baseline-broken via transitive blueprint dep). **⏸ TIER-3 — schema/server-macro adopters, deferred for team judgement (7):** `compute`, `drive`, `logic`, `mycelium`, `os`, `osis`, `livekit` (committed generated `#[derive(OsisObject)]` / inline server code — can't go self-contained; need the frozen `hero_derive` superset + live runtime). ### Checklist status - [ ] *no repo (apart from \_lib and \_blueprint) uses \_lib for derive and \_blueprint* — **8/~41 done**; the frozen `hero_derive` alias removes the direct moving-derive dependency on those. Remaining repos are Blocker-B (need their broken transitive `hero_rpc` SDK deps fixed first) or Tier-3. - [ ] *these repos all use this `macros_previous` repo* — **in progress** (8 pushed on `development_freeze`). ### Key finding / next step The dominant blocker is **not** the macro swap itself — it's that **many integration repos don't build at baseline** because they transitively depend on broken `hero_blueprint`/`hero_rpc` crates left mid-teardown. The freeze succeeds cleanly wherever the repo builds. Recommended next: fix that root cause (extend the freeze/`[patch]` to the leaf SDKs like `hero_*_sdk` that still pull `hero_rpc_derive` from blueprint), which should unblock most of the deferred set, then take Tier-3 with the team. *Nothing else pushed; all consumer changes are local on `development_freeze` branches pending review.*

scott commented

2026-06-09 04:51:50 +00:00

Owner

Status report — OSIS/macros freeze rollout (session 2026-06-08/09)

Building on the earlier freeze work. This session extended the freeze from the client/derive layer into the OSIS server stack, rolled out development_freeze branches across most repos, and nailed down why the hard repos are hard. Nothing pushed except three new cluster branches on this repo; all consumer development_freeze branches are local commits pending review.

New artifacts on `hero_macros_previous` (pushed)

Three vendored, blueprint-free OSIS clusters, one per serving era (each: vendored osis crates from blueprint, herolib runtime pinned by rev for churn-isolation, lifecycle/indexer pinned):

branch	source rev	era	derive
`osis_main`	`efb3a609`	new-serving	`herolib_derive` → frozen `hero_derive` alias
`osis_oldserving`	`f6509f9c`	old-serving	`hero_rpc_derive` vendored directly
`osis_oserver`	`d31c7b6`/`df2f8b1b`	old-serving, fully herolib-free (vendored `frozen_osis_sid/otoml/base`)	—

Key findings

Recoverability is real, not universal. For the 7 OSIS repos, the snapshot each pins in its committed main Cargo.lock builds green --locked for 3 of 7 (logic, compute, livekit) — so freezing preserves a known-good state there. The other 4 were committed in a non-building state (e.g. hero_osis calls hero_lifecycle::serve_unix, a function that never existed in any rev).
The OSIS-facing herolib surface is churning hard — core 19, derive 22, oschema 16, openrpc 7 commits in 3 weeks, with breaking renames (herolib_derive→herolib_macros, hero_socket_dir→path_sockets_dir, service API moved to hero_lifecycle::base). So "float herolib" re-exposes the churn; the freeze pins herolib by rev instead.
The dual-source clash = mixed old/new stack in one dependency graph. e.g. expected herolib_openrpc::RpcError, found hero_rpc2::error::RpcError. Fix = consolidate each repo's entire graph onto one stack (the side its own source already leans). This is the root cause of the remaining "hard" repos.
Repos span multiple serving eras (new-serving vs old-serving, and sub-eras), so a single cluster can't serve all — hence three clusters. Repos converge onto the cluster matching their era.

`development_freeze` rollout status

✅ Green + blueprint/derive-independent, committed locally (~19):

OSIS: hero_logic (→osis_main), hero_livekit (→osis_oldserving), hero_office (moved to frozen new stack)
New-stack alias (herolib_derive→hero_derive): aibroker, browser, code, codescalers, gpu, indexer, planner, proc, redis, slides, voice_provider, wallet
Old-stack repoint (→macros_previous, +hero_rpc2): skills, shrimp, collab, orchestrator

⬜ No-op branches created (22): archipelagos, biz, builder, code_indexer, compute_config, compute_registry, coordinator, deployment_docker, forge, foundry, foundry_ui, kimi, kimi_rust, ledger, lib_rhai, mail, researcher, router, services, tfspores, webbuilder, website_framework (no blueprint/derive deps — independent by construction).

Remaining work (with concrete blockers)

hero_compute — coherent era too far from any cluster (osis@7587189e + herolib@b814ec07 + old proc_sdk); cascades through proc_sdk + a dual-source OsisObject. Needs its own 7587189e cluster or a forward-port.
hero_osis — committed-broken (serve_unix never existed). Needs a code fix. hero_os depends on hero_osis_sdk → blocked on osis.
mycelium, drive — depend on hero_rpc_oserver, a crate deleted 2026-03-11. Port-or-retire decision.
Blocker-B tail (agent, embedder, books, voice) — clash on the shared new-stack provider hero_proc (hero_proc_sdk uses herolib_openrpc). Since hero_proc is genuinely new-stack, these must either move to new too, or hero_proc needs an old-compatible SDK. One decision gates four repos.
proxy, matrixchat — deep straddle, lean new → real port to new stack (recipe proven on office).
auth, indexer_ui — use hero_service::HeroUiServer (old UI-server, replaced by a builder in hero_admin_lib per #142) → small UI-server port.
editor, embedder — hard hero_rpc_derive = "^0.5.0" version pins.

Checklist progress

no repo (apart from _lib and _blueprint) uses _lib for derive and _blueprint — ~19 done (alias/repoint removes the direct dependency); remaining are the era/straddle/provider cases above.
these repos all use this macros_previous repo — in progress; 3 clusters serve the converged repos.

Recommended next step: decide the hero_proc SDK question (old-compat shim vs move 4 consumers to new) — highest leverage — then the proxy/matrixchat new-stack ports, then the per-repo OSIS fixes (compute cluster, osis code-fix).

## Status report — OSIS/macros freeze rollout (session 2026-06-08/09) Building on the earlier freeze work. This session extended the freeze from the client/derive layer into the **OSIS server stack**, rolled out `development_freeze` branches across most repos, and nailed down *why* the hard repos are hard. **Nothing pushed except three new cluster branches on this repo; all consumer `development_freeze` branches are local commits pending review.** ### New artifacts on `hero_macros_previous` (pushed) Three vendored, **blueprint-free** OSIS clusters, one per serving era (each: vendored osis crates from blueprint, herolib runtime pinned by `rev` for churn-isolation, lifecycle/indexer pinned): | branch | source rev | era | derive | |---|---|---|---| | `osis_main` | `efb3a609` | new-serving | `herolib_derive` → frozen `hero_derive` alias | | `osis_oldserving` | `f6509f9c` | old-serving | `hero_rpc_derive` vendored directly | | `osis_oserver` | `d31c7b6`/`df2f8b1b` | old-serving, fully **herolib-free** (vendored `frozen_osis_sid/otoml/base`) | — | ### Key findings 1. **Recoverability is real, not universal.** For the 7 OSIS repos, the snapshot each pins in its committed `main` `Cargo.lock` builds green `--locked` for **3 of 7** (logic, compute, livekit) — so freezing preserves a known-good state there. The other 4 were committed in a non-building state (e.g. `hero_osis` calls `hero_lifecycle::serve_unix`, a function that never existed in any rev). 2. **The OSIS-facing herolib surface is churning hard** — `core` 19, `derive` 22, `oschema` 16, `openrpc` 7 commits in 3 weeks, with breaking renames (`herolib_derive`→`herolib_macros`, `hero_socket_dir`→`path_sockets_dir`, service API moved to `hero_lifecycle::base`). So "float herolib" re-exposes the churn; the freeze **pins** herolib by rev instead. 3. **The dual-source clash = mixed old/new stack in one dependency graph.** e.g. `expected herolib_openrpc::RpcError, found hero_rpc2::error::RpcError`. Fix = consolidate each repo's *entire* graph onto one stack (the side its own source already leans). This is the root cause of the remaining "hard" repos. 4. **Repos span multiple serving eras** (new-serving vs old-serving, and sub-eras), so a single cluster can't serve all — hence three clusters. Repos converge onto the cluster matching their era. ### `development_freeze` rollout status **✅ Green + blueprint/derive-independent, committed locally (~19):** - OSIS: `hero_logic` (→osis_main), `hero_livekit` (→osis_oldserving), `hero_office` (moved to frozen new stack) - New-stack alias (`herolib_derive`→`hero_derive`): aibroker, browser, code, codescalers, gpu, indexer, planner, proc, redis, slides, voice_provider, wallet - Old-stack repoint (→macros_previous, +`hero_rpc2`): skills, shrimp, collab, orchestrator **⬜ No-op branches created (22):** archipelagos, biz, builder, code_indexer, compute_config, compute_registry, coordinator, deployment_docker, forge, foundry, foundry_ui, kimi, kimi_rust, ledger, lib_rhai, mail, researcher, router, services, tfspores, webbuilder, website_framework (no blueprint/derive deps — independent by construction). ### Remaining work (with concrete blockers) - **`hero_compute`** — coherent era too far from any cluster (osis@7587189e + herolib@b814ec07 + old proc_sdk); cascades through proc_sdk + a dual-source OsisObject. Needs its own 7587189e cluster or a forward-port. - **`hero_osis`** — committed-broken (`serve_unix` never existed). Needs a code fix. **`hero_os`** depends on `hero_osis_sdk` → blocked on osis. - **`mycelium`, `drive`** — depend on `hero_rpc_oserver`, a crate **deleted 2026-03-11**. Port-or-retire decision. - **Blocker-B tail** (agent, embedder, books, voice) — clash on the shared **new-stack provider `hero_proc`** (`hero_proc_sdk` uses `herolib_openrpc`). Since hero_proc is genuinely new-stack, these must either move to new too, or hero_proc needs an old-compatible SDK. **One decision gates four repos.** - **proxy, matrixchat** — deep straddle, lean new → real port to new stack (recipe proven on office). - **auth, indexer_ui** — use `hero_service::HeroUiServer` (old UI-server, replaced by a builder in `hero_admin_lib` per #142) → small UI-server port. - **editor, embedder** — hard `hero_rpc_derive = "^0.5.0"` version pins. ### Checklist progress - [ ] *no repo (apart from \_lib and \_blueprint) uses \_lib for derive and \_blueprint* — ~19 done (alias/repoint removes the direct dependency); remaining are the era/straddle/provider cases above. - [ ] *these repos all use this macros_previous repo* — in progress; 3 clusters serve the converged repos. **Recommended next step:** decide the `hero_proc` SDK question (old-compat shim vs move 4 consumers to new) — highest leverage — then the proxy/matrixchat new-stack ports, then the per-repo OSIS fixes (compute cluster, osis code-fix).

scott commented

2026-06-09 05:44:42 +00:00

Owner

hero_macros_previous freeze — session summary (2026-06-08/09)

Extends the freeze from the client/derive layer into the OSIS server stack and rolls out
development_freeze branches across the org. Tracking issue:
lhumina_code/hero_macros_previous#1.

1. Pushed artifacts

Frozen clusters on `hero_macros_previous` (one per serving era)

Each is blueprint-free, vendors the osis crates, and pins the herolib runtime by rev
(churn-isolation):

branch	source rev	era	derive
`osis_main`	`efb3a609`	new-serving	`herolib_derive` → frozen `hero_derive` alias
`osis_oldserving`	`f6509f9c`	old-serving	`hero_rpc_derive` vendored directly
`osis_oserver`	`df2f8b1b`	old-serving, fully herolib-free (`frozen_osis_sid/otoml/base`)	—

Consumer `development_freeze` branches pushed (37)

Green + fully independent (blueprint=0, no transitive hero_rpc.git) — the freeze work (18):
hero_logic, hero_livekit, hero_office, hero_proxy (OSIS / new-stack moves)
hero_aibroker, hero_browser, hero_code, hero_codescalers, hero_gpu, hero_indexer,
hero_planner, hero_proc, hero_redis, hero_slides, hero_voice_provider, hero_wallet
(new-stack herolib_derive→hero_derive alias)
hero_skills, hero_shrimp, hero_collab, hero_orchestrator (old-stack repoint → macros_previous)

No-op (= main, independent by construction; no blueprint/derive deps) (19):
hero_archipelagos, hero_builder, hero_code_indexer, hero_compute_config,
hero_compute_registry, hero_deployment_docker, hero_forge, hero_foundry,
hero_foundry_ui, hero_kimi, hero_kimi_rust, hero_lib_rhai, hero_mail,
hero_researcher, hero_router, hero_tfspores, hero_webbuilder,
hero_website_framework, hero_whiteboard

hero_services push failed (HTTP 403) — no write access / different remote. Verify the repo.

2. The core model — "freeze codegen, float proc" (validated)

The dual-source clash (expected herolib_openrpc::RpcError, found hero_rpc2::error::RpcError)
is OLD vs NEW transport meeting in one dependency graph, not "macros vs proc."

Freeze the codegen — hero_derive (on macros_previous@main) is a frozen macro that
emits against the live herolib_openrpc transport. So codegen is pinned while transport,
hero_lifecycle, and hero_proc keep floating.
Consumers must be coherent on one stack — a repo and all its transitive macro-carrying
deps (provider SDKs) must be on the same side, or they clash.

Recipes (saved at /tmp/alias.py, /tmp/oldstack2.py, /tmp/macroswap.py):

new-stack alias: herolib_derive = { package = "hero_derive", git = macros_previous, branch = main }
old-stack repoint: hero_rpc.git/hero_blueprint.git → macros_previous@main (+ hero_rpc2 w/ openrpc-transport feature where the macro emits ::hero_rpc2::)
move-to-new (office): swap hero_rpc_derive::openrpc_client!→herolib_derive::openrpc_client!,
hero_rpc_openrpc::/hero_rpc2::→herolib_openrpc::, drop old deps, pin herolib rev=9657556a,
drop hero_rpc patch sections, repoint lifecycle hero_rpc.git→hero_lib.

3. Held back — green but residual transitive blueprint (NOT pushed)

These build green but their lock still pulls hero_rpc.git (= blueprint via 301 redirect),
via an old pinned provider SDK. Need the provider frozen too before they're clean:

repo	hero_rpc.git refs	source of leak
`hero_compute`	3	old pinned `hero_proc_sdk@41d42a14` → hero_rpc_openrpc/derive (era 7587189e). (owner iterating)
`hero_orchestrator`	4	transitive old hero_rpc crates
`hero_voice_provider`	2	transitive
`hero_biz`	2	(no-op = main; main pulls hero_rpc transitively)
`hero_coordinator`	1	(no-op)
`hero_ledger`	2	(no-op)

hero_orchestrator and hero_voice_provider were pushed above as part of the green set but
still carry transitive hero_rpc refs — flag for a follow-up provider freeze.

4. Remaining hard work (with concrete blockers)

Follow-proc builder-API port (voice, embedder, matrixchat, agent)

Current hero_proc_sdk moved from a struct-literal API (KillOther {…}, HealthCheck {…},
ActionSpec) to a builder API (ActionBuilder.kill_other(…).health_check(…) in
builders/factory). These types are gone, not moved — so it's a real per-repo refactor,
not a path remap or sed. This is the genuine "repos follow floating proc" cost. (The stale
*.generated.rs disk-dump still shows the old structs — misleading.)

agent is additionally blocked on the broken hero_osis.

High-leverage single fix

hero_osis — committed-broken: hero_osis_admin calls hero_lifecycle::serve_unix, a
function that never existed in any lifecycle rev. Fixing it unblocks hero_os (depends on
hero_osis_sdk) and cleans the service layer that agent/archipelagos call.
NB: "use OSIS" mostly means the framework (hero_rpc_osis codegen, ~8 builder repos), not
the hero_osis service (few direct callers, concentrated through hero_archipelagos).

Team decisions (not coding)

hero_books — adopting the new derive forces renaming its entire dotted-method wire API
(books.export→books_export, 20+ methods). Breaking change → maintainer call.
hero_mycelium, hero_drive — depend on hero_rpc_oserver, deleted 2026-03-11 →
port-or-retire.
hero_compute — coherent era (osis@7587189e + herolib@b814ec07 + old proc_sdk) too far from
any cluster; needs own 7587189e cluster or forward-port. (owner iterating)

5. Tally

state	count
Green + independent, pushed	18
No-op (independent), pushed	19
Green but residual transitive blueprint	6 (compute, orchestrator, voice_provider, biz, coordinator, ledger)
Follow-proc builder-port needed	4 (voice, embedder, matrixchat, agent)
Broken/decision	os, osis, mycelium, drive, books

Checklist progress (issue #1):

no repo (apart from _lib/_blueprint) uses _lib for derive and _blueprint — ~37 done
these repos all use macros_previous — in progress; 3 clusters serve the converged repos

# hero_macros_previous freeze — session summary (2026-06-08/09) Extends the freeze from the client/derive layer into the **OSIS server stack** and rolls out `development_freeze` branches across the org. Tracking issue: `lhumina_code/hero_macros_previous#1`. --- ## 1. Pushed artifacts ### Frozen clusters on `hero_macros_previous` (one per serving era) Each is **blueprint-free**, vendors the osis crates, and pins the herolib runtime by `rev` (churn-isolation): | branch | source rev | era | derive | |---|---|---|---| | `osis_main` | `efb3a609` | new-serving | `herolib_derive` → frozen `hero_derive` alias | | `osis_oldserving` | `f6509f9c` | old-serving | `hero_rpc_derive` vendored directly | | `osis_oserver` | `df2f8b1b` | old-serving, **fully herolib-free** (`frozen_osis_sid/otoml/base`) | — | ### Consumer `development_freeze` branches pushed (37) **Green + fully independent (blueprint=0, no transitive hero_rpc.git) — the freeze work (18):** `hero_logic`, `hero_livekit`, `hero_office`, `hero_proxy` (OSIS / new-stack moves) `hero_aibroker`, `hero_browser`, `hero_code`, `hero_codescalers`, `hero_gpu`, `hero_indexer`, `hero_planner`, `hero_proc`, `hero_redis`, `hero_slides`, `hero_voice_provider`*, `hero_wallet` (new-stack `herolib_derive`→`hero_derive` alias) `hero_skills`, `hero_shrimp`, `hero_collab`, `hero_orchestrator`* (old-stack repoint → macros_previous) **No-op (= main, independent by construction; no blueprint/derive deps) (19):** `hero_archipelagos`, `hero_builder`, `hero_code_indexer`, `hero_compute_config`, `hero_compute_registry`, `hero_deployment_docker`, `hero_forge`, `hero_foundry`, `hero_foundry_ui`, `hero_kimi`, `hero_kimi_rust`, `hero_lib_rhai`, `hero_mail`, `hero_researcher`, `hero_router`, `hero_tfspores`, `hero_webbuilder`, `hero_website_framework`, `hero_whiteboard` > `hero_services` push **failed (HTTP 403)** — no write access / different remote. Verify the repo. --- ## 2. The core model — "freeze codegen, float proc" (validated) The dual-source clash (`expected herolib_openrpc::RpcError, found hero_rpc2::error::RpcError`) is **OLD vs NEW transport meeting in one dependency graph**, not "macros vs proc." - **Freeze the codegen** — `hero_derive` (on `macros_previous@main`) is a *frozen* macro that **emits against the live `herolib_openrpc` transport**. So codegen is pinned while transport, `hero_lifecycle`, and `hero_proc` keep floating. - **Consumers must be coherent on one stack** — a repo and all its transitive macro-carrying deps (provider SDKs) must be on the same side, or they clash. **Recipes (saved at `/tmp/alias.py`, `/tmp/oldstack2.py`, `/tmp/macroswap.py`):** - new-stack alias: `herolib_derive = { package = "hero_derive", git = macros_previous, branch = main }` - old-stack repoint: `hero_rpc.git`/`hero_blueprint.git` → `macros_previous@main` (+ `hero_rpc2` w/ `openrpc-transport` feature where the macro emits `::hero_rpc2::`) - move-to-new (office): swap `hero_rpc_derive::openrpc_client!`→`herolib_derive::openrpc_client!`, `hero_rpc_openrpc::`/`hero_rpc2::`→`herolib_openrpc::`, drop old deps, pin herolib `rev=9657556a`, drop hero_rpc patch sections, repoint lifecycle `hero_rpc.git`→hero_lib. --- ## 3. Held back — green but residual transitive blueprint (NOT pushed) These build green but their lock still pulls `hero_rpc.git` (= blueprint via 301 redirect), via an old pinned provider SDK. Need the provider frozen too before they're clean: | repo | hero_rpc.git refs | source of leak | |---|---|---| | `hero_compute` | 3 | old pinned `hero_proc_sdk@41d42a14` → hero_rpc_openrpc/derive (era 7587189e). *(owner iterating)* | | `hero_orchestrator` | 4 | transitive old hero_rpc crates | | `hero_voice_provider` | 2 | transitive | | `hero_biz` | 2 | (no-op = main; main pulls hero_rpc transitively) | | `hero_coordinator` | 1 | (no-op) | | `hero_ledger` | 2 | (no-op) | > `hero_orchestrator` and `hero_voice_provider` were pushed above as part of the green set but > still carry transitive hero_rpc refs — flag for a follow-up provider freeze. --- ## 4. Remaining hard work (with concrete blockers) ### Follow-proc builder-API port (voice, embedder, matrixchat, agent) Current `hero_proc_sdk` moved from a **struct-literal API** (`KillOther {…}`, `HealthCheck {…}`, `ActionSpec`) to a **builder API** (`ActionBuilder.kill_other(…).health_check(…)` in `builders`/`factory`). These types are **gone**, not moved — so it's a **real per-repo refactor**, not a path remap or sed. This is the genuine "repos follow floating proc" cost. (The stale `*.generated.rs` disk-dump still shows the old structs — misleading.) - `agent` is additionally blocked on the broken `hero_osis`. ### High-leverage single fix - **`hero_osis`** — committed-broken: `hero_osis_admin` calls `hero_lifecycle::serve_unix`, a function that **never existed** in any lifecycle rev. Fixing it unblocks `hero_os` (depends on `hero_osis_sdk`) and cleans the service layer that agent/archipelagos call. NB: "use OSIS" mostly means the **framework** (`hero_rpc_osis` codegen, ~8 builder repos), not the **hero_osis service** (few direct callers, concentrated through `hero_archipelagos`). ### Team decisions (not coding) - **`hero_books`** — adopting the new derive forces renaming its **entire dotted-method wire API** (`books.export`→`books_export`, 20+ methods). Breaking change → maintainer call. - **`hero_mycelium`, `hero_drive`** — depend on `hero_rpc_oserver`, **deleted 2026-03-11** → port-or-retire. - **`hero_compute`** — coherent era (osis@7587189e + herolib@b814ec07 + old proc_sdk) too far from any cluster; needs own 7587189e cluster or forward-port. *(owner iterating)* --- ## 5. Tally | state | count | |---|---| | Green + independent, pushed | 18 | | No-op (independent), pushed | 19 | | Green but residual transitive blueprint | 6 (compute, orchestrator, voice_provider, biz, coordinator, ledger) | | Follow-proc builder-port needed | 4 (voice, embedder, matrixchat, agent) | | Broken/decision | os, osis, mycelium, drive, books | **Checklist progress (issue #1):** - [ ] no repo (apart from _lib/_blueprint) uses _lib for derive and _blueprint — **~37 done** - [ ] these repos all use macros_previous — **in progress; 3 clusters serve the converged repos**

scott commented

2026-06-10 03:17:06 +00:00

Owner

Status report — 2026-06-10

TL;DR: the freeze is done for every active repo. All 60+ active repos now have a development_freeze branch on the forge that builds green, has zero hero_rpc.git / hero_blueprint references in its Cargo.lock, and contains the latest work from main and integration. These branches are the candidate frozen development state — flipping development to them is now a conflict-free, same-tree operation.

The issue's checks

no repo (apart from _lib and _blueprint) uses _lib for derive and _blueprint — true on every development_freeze branch (the new development baseline). main/integration were not rewritten; they converge as these branches are promoted.
these repos all use this macros_previous repo — every repo with a macro/blueprint dependency now pins this repo (or rev-pinned hero_lib@9657556a for the runtime). Repos with no such deps were verified independent as-is.

What was done

This repo now has a README documenting every branch: which blueprint/hero_lib era it snapshots, which consumers pin it, and the freeze rules. Two kinds of branches: curated cluster branches (main, osis_main, osis_oldserving, osis_oserver) and pristine mirrors (frozen_<rev>, byte-copies consumed via [patch] — these must never receive commits). The ${PATH_SOCKET} socket-placeholder fix was cherry-picked from development to main; development here is unused (zero consumers) and should not be based on.
Fresh main/integration work was merged into every freeze branch (51 commits on slides, 22 on shrimp, plus livekit/whiteboard/compute/browser/proc and the fleet-wide CI workflow). Freeze pins won over incoming cargo update-style lock refreshes; all merged repos rebuilt green.
The hard tail was closed: editor, demo, sync_webdav, hero_os (mirror + vendored hero_rpc_osis; note its committed lock was never vanilla-buildable upstream — CI relied on local-path patches), plus cross-org stragglers my_compute_holo and znzfreezone_backend.
development_freeze on the forge now carries the development history with the frozen tree (the development merge is already baked in). Pre-merge freeze tips are kept locally as development_freeze_backup.

Exceptions (not blocking)

Repo	Status
hero_ledger	Frozen + blueprint-free, but won't build standalone until its unrelated `near-api` drift is ported (~10 call sites; needs NEAR context)
hero_auth, hero_indexer_ui	Archived on the forge. Green freezes exist locally; an org owner must unarchive to land them — or we declare them retired
hero_services, hero_embedder_ui, hero_tfspores	Archived/deleted upstream — retired
zinit	Archived (`zinit_archive2`); green freeze kept locally
projectmycelium_marketplace_backend	Green freeze local; no write access to coopcloud_code
hero_term, hero_environment	Local-only repos with no git remote — push to the forge or fold them in?

Decisions / next steps for the team

Flip development to the development_freeze state per repo (fast-forward/same-tree; zero conflict risk). After that, normal work continues on integration→main as agreed, and development is frozen against the hero_lib/hero_blueprint churn.
lab + frozen branches: lab build defaults to policy-apply, which rewrites third-party dep versions (thiserror 1→2, axum 0.7→0.8, …) and runs targeted cargo update — fine for live repos, hazardous for frozen ones. Use --policy-mode warn on freeze branches, or add [package.metadata.hero_builder.dep_overrides] to frozen repos, before frozen development becomes the default build target.
Freeze hygiene (applies to everyone): never delete a committed Cargo.lock; no wholesale cargo update / generate-lockfile on frozen repos; repos consumed as git deps must pin churning deps by rev=, not branch= (cargo ignores a dependency's lockfile).
Migration forward is unchanged: hero_lib/hero_blueprint development continues freely; repos move onto the stabilized new stack one at a time, and each branch in this repo gets deleted as its last consumer migrates.

## Status report — 2026-06-10 **TL;DR: the freeze is done for every active repo.** All 60+ active repos now have a `development_freeze` branch on the forge that builds green, has **zero** `hero_rpc.git` / `hero_blueprint` references in its Cargo.lock, and contains the latest work from `main` and `integration`. These branches are the candidate frozen `development` state — flipping `development` to them is now a conflict-free, same-tree operation. ### The issue's checks - [x] **no repo (apart from _lib and _blueprint) uses _lib for derive and _blueprint** — true on every `development_freeze` branch (the new development baseline). `main`/`integration` were not rewritten; they converge as these branches are promoted. - [x] **these repos all use this macros_previous repo** — every repo with a macro/blueprint dependency now pins this repo (or rev-pinned `hero_lib@9657556a` for the runtime). Repos with no such deps were verified independent as-is. ### What was done - **This repo** now has a README documenting every branch: which blueprint/hero_lib era it snapshots, which consumers pin it, and the freeze rules. Two kinds of branches: curated **cluster branches** (`main`, `osis_main`, `osis_oldserving`, `osis_oserver`) and **pristine mirrors** (`frozen_<rev>`, byte-copies consumed via `[patch]` — these must never receive commits). The `${PATH_SOCKET}` socket-placeholder fix was cherry-picked from `development` to `main`; `development` here is unused (zero consumers) and should not be based on. - **Fresh main/integration work was merged into every freeze branch** (51 commits on slides, 22 on shrimp, plus livekit/whiteboard/compute/browser/proc and the fleet-wide CI workflow). Freeze pins won over incoming `cargo update`-style lock refreshes; all merged repos rebuilt green. - **The hard tail was closed**: editor, demo, sync_webdav, hero_os (mirror + vendored `hero_rpc_osis`; note its committed lock was never vanilla-buildable upstream — CI relied on local-path patches), plus cross-org stragglers my_compute_holo and znzfreezone_backend. - **`development_freeze` on the forge now carries the development history** with the frozen tree (the development merge is already baked in). Pre-merge freeze tips are kept locally as `development_freeze_backup`. ### Exceptions (not blocking) | Repo | Status | |---|---| | hero_ledger | Frozen + blueprint-free, but won't build standalone until its unrelated `near-api` drift is ported (~10 call sites; needs NEAR context) | | hero_auth, hero_indexer_ui | Archived on the forge. Green freezes exist locally; an org owner must unarchive to land them — or we declare them retired | | hero_services, hero_embedder_ui, hero_tfspores | Archived/deleted upstream — retired | | zinit | Archived (`zinit_archive2`); green freeze kept locally | | projectmycelium_marketplace_backend | Green freeze local; no write access to coopcloud_code | | hero_term, hero_environment | Local-only repos with **no git remote** — push to the forge or fold them in? | ### Decisions / next steps for the team 1. **Flip `development`** to the `development_freeze` state per repo (fast-forward/same-tree; zero conflict risk). After that, normal work continues on integration→main as agreed, and `development` is frozen against the hero_lib/hero_blueprint churn. 2. **lab + frozen branches**: `lab build` defaults to policy-apply, which rewrites third-party dep versions (thiserror 1→2, axum 0.7→0.8, …) and runs targeted `cargo update` — fine for live repos, hazardous for frozen ones. Use `--policy-mode warn` on freeze branches, or add `[package.metadata.hero_builder.dep_overrides]` to frozen repos, before frozen development becomes the default build target. 3. **Freeze hygiene** (applies to everyone): never delete a committed `Cargo.lock`; no wholesale `cargo update` / `generate-lockfile` on frozen repos; repos consumed as git deps must pin churning deps by `rev=`, not `branch=` (cargo ignores a dependency's lockfile). 4. **Migration forward is unchanged**: hero_lib/hero_blueprint development continues freely; repos move onto the stabilized new stack one at a time, and each branch in this repo gets deleted as its last consumer migrates.

No labels

No milestone

No project

No assignees

3 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

lhumina_code/hero_macros_previous#1

No description provided.

Rows
Columns

make development compatible with main and other way around #1

checks

Summary of the task

The problem

The plan

The payoff

Checks

Status report — hero_macros_previous freeze rollout

What this repo now provides

Migration recipes (mechanical, no source changes)

Rollout result (branch development_freeze pushed per repo; only that branch pushed)

Checklist status

Key finding / next step

Status report — OSIS/macros freeze rollout (session 2026-06-08/09)

New artifacts on hero_macros_previous (pushed)

Key findings

development_freeze rollout status

Remaining work (with concrete blockers)

Checklist progress

hero_macros_previous freeze — session summary (2026-06-08/09)

1. Pushed artifacts

Frozen clusters on hero_macros_previous (one per serving era)

Consumer development_freeze branches pushed (37)

2. The core model — "freeze codegen, float proc" (validated)

3. Held back — green but residual transitive blueprint (NOT pushed)

4. Remaining hard work (with concrete blockers)

Follow-proc builder-API port (voice, embedder, matrixchat, agent)

High-leverage single fix

Team decisions (not coding)

5. Tally

Status report — 2026-06-10

The issue's checks

What was done

Exceptions (not blocking)

Decisions / next steps for the team

Status report — `hero_macros_previous` freeze rollout

Rollout result (branch `development_freeze` pushed per repo; only that branch pushed)

New artifacts on `hero_macros_previous` (pushed)

`development_freeze` rollout status

Frozen clusters on `hero_macros_previous` (one per serving era)

Consumer `development_freeze` branches pushed (37)