template build: locate_nutools_source only checks $PATH_ROOT/code/hero_skills/nutools — operator-hostile #292

New issue

Closed

opened 2026-05-25 06:03:56 +00:00 by zaelgohary · 0 comments

zaelgohary commented

2026-05-25 06:03:56 +00:00

Member

Problem

crates/lab/src/installers/nu.rs::locate_nutools_source() falls back to a single hardcoded path under $PATH_ROOT/code/hero_skills/nutools. When an operator runs provisioning.template.apply from hero_codescalers (daemon runs as root with PATH_ROOT=/root/hero), this resolves to /root/hero/code/hero_skills/nutools — which does not exist on the herodev box. The repo is checked out under /home/<developer>/hero/code/hero_skills/, not under /root/.

Result: every template build aborts at the nu-install step unless the operator sets HERO_NUTOOLS_DIR manually pointing at a developer home.

hero_codescalers#27 worked around this on the daemon side by scanning /home/*/hero/code/hero_skills/nutools at apply time and exporting HERO_NUTOOLS_DIR. That fixes the symptom but the discoverability is now lab daemon-side metadata duplicated across callers.

Suggested fixes (any one is enough)

Embed nutools in the lab binary with include_dir!() and extract to the target on install. Self-contained, no operator config required.
Auto-clone hero_skills repo into $PATH_ROOT/code/hero_skills/ as part of lab flow template init so the fallback path actually exists.
Widen locate_nutools_source() to scan additional candidate roots (/home/*/hero/code/, /Users/*/repos/, etc.) before bailing.

(1) is the most portable. (2) is the smallest diff and makes the existing fallback work as documented.

Repro

rm -rf /root/hero/code/hero_skills/nutools
unset HERO_NUTOOLS_DIR
sudo /root/hero/bin/lab flow template build --release

Fails with: could not locate nutools/ source — set HERO_NUTOOLS_DIR or clone hero_skills into $PATH_CODE/.

## Problem `crates/lab/src/installers/nu.rs::locate_nutools_source()` falls back to a single hardcoded path under `$PATH_ROOT/code/hero_skills/nutools`. When an operator runs `provisioning.template.apply` from `hero_codescalers` (daemon runs as `root` with `PATH_ROOT=/root/hero`), this resolves to `/root/hero/code/hero_skills/nutools` — which does **not** exist on the herodev box. The repo is checked out under `/home/<developer>/hero/code/hero_skills/`, not under `/root/`. Result: every template build aborts at the nu-install step unless the operator sets `HERO_NUTOOLS_DIR` manually pointing at a developer home. `hero_codescalers#27` worked around this on the daemon side by scanning `/home/*/hero/code/hero_skills/nutools` at apply time and exporting `HERO_NUTOOLS_DIR`. That fixes the symptom but the discoverability is now lab daemon-side metadata duplicated across callers. ## Suggested fixes (any one is enough) 1. **Embed nutools in the lab binary** with `include_dir!()` and extract to the target on install. Self-contained, no operator config required. 2. **Auto-clone hero_skills repo** into `$PATH_ROOT/code/hero_skills/` as part of `lab flow template init` so the fallback path actually exists. 3. **Widen `locate_nutools_source()`** to scan additional candidate roots (`/home/*/hero/code/`, `/Users/*/repos/`, etc.) before bailing. (1) is the most portable. (2) is the smallest diff and makes the existing fallback work as documented. ## Repro ``` rm -rf /root/hero/code/hero_skills/nutools unset HERO_NUTOOLS_DIR sudo /root/hero/bin/lab flow template build --release ``` Fails with: `could not locate nutools/ source — set HERO_NUTOOLS_DIR or clone hero_skills into $PATH_CODE/`.