Skip to content

Prepare for Lerna 8 upgrade - #26

Closed
joelteply wants to merge 4 commits into
mainfrom
fix/lerna-update
Closed

Prepare for Lerna 8 upgrade#26
joelteply wants to merge 4 commits into
mainfrom
fix/lerna-update

Conversation

@joelteply

Copy link
Copy Markdown
Contributor

Summary

This PR prepares the repository for upgrading to Lerna 8:

  • Updates lerna.json configuration
  • Removes deprecated options
  • Adds diagnostic workflow for CI troubleshooting
  • Fixes example visualization for CI

Test plan

  1. Verify lerna commands work correctly
  2. Ensure CI builds pass
  3. Check that diagnostic workflow provides useful information

This update is necessary to keep our tooling current and resolve the Dependabot alerts.

🤖 Generated with Claude Code

joelteply and others added 4 commits April 8, 2025 21:47
- Update Node.js engine requirement to 18+
- Update CI workflow to use Node.js 18+
- Create update script for Lerna 8
- Update postinstall script for compatibility
- Add documentation for the upgrade process

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
- Add robust error handling to visualize-config.js
- Create simplified version that doesn't depend on yaml module
- Add package.json for examples directory
- Update CI workflow to better handle example validation

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings April 9, 2025 04:27

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot reviewed 6 out of 9 changed files in this pull request and generated no comments.

Files not reviewed (3)
  • examples/package.json: Language not supported
  • package.json: Language not supported
  • scripts/update-lerna.sh: Language not supported

@joelteply joelteply closed this Apr 9, 2025
@joelteply
joelteply deleted the fix/lerna-update branch April 9, 2025 04:29
joelteply added a commit that referenced this pull request Jun 19, 2026
…iles (#1682)

* docs(arch): modular decomposition blueprint — composable service profiles

The modular architecture worked out, grounded in the EXISTING seam (BootMode +
ModuleCategory + required_modules + route_command + ServiceModule registry) so
it's refinement, not rewrite — the monolith is just one process registering all
~40 modules. "A good AWS template": declare which service-groups a node runs;
each independently health-checked, restartable, testable; composed over the bus.

Captures:
- Refined ModuleCategory taxonomy (7 service groups: RuntimeShell, ResourceGov,
  Inference, Cognition, Forge, GridTransport, Live) replacing the coarse
  Core/PersonaHosting blob.
- CO-LOCATION CONSTRAINTS (placement groups): Bevy render + LiveKit SFU + GPU
  MUST share a VM — avatar frames are a GPU-readback→framebuffer→WebRTC transfer
  that a process/network boundary would force off-GPU every frame. ResourceGov
  co-resides with its hardware; Inference's boundary is unsloth's /v1 wire.
- Per-service health / supervised restart / independent test (the testability
  win; reuses ServiceModule health + the 3-strike quarantine).
- Container layout mirrors the profiles (light citizen nodes + shared GPU
  engine/live/forge nodes), cross-process routing via the existing bus.
- 6-slice build plan; guardrails per CONCURRENCY-STYLE-GUIDE (no parallel
  orchestrator; FullCitizen still hosts all in one process — decomposition is
  optional placement, not forced fragmentation).

Consolidates live findings #25 (decompose), #26 (degrade-not-panic), #27
(intra-machine addressing). Referenced from ARCHITECTURE-INDEX quick-nav.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* docs(arch): §9 — decomposition IS the grid (profiles are grid roles)

The profiles ARE grid roles (same binary, different service composition);
compute-leasing = a service group on another node over route_command;
per-service healing; independent scaling. The grid is the module graph placed
across machines — not a layer bolted on. Captures Joel's framing.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
joelteply added a commit that referenced this pull request Jun 21, 2026
…del (TDD) (#1712)

unsloth Studio starts EMPTY (/v1/models -> []; inference -> "No GGUF model
loaded"), so nothing a persona needs serves until something tells unsloth what
to load. This is that keystone — the reliable-startup piece ("automatic after
the key"), pure delegation over unsloth's HTTP surface (UNSLOTH-INTEGRATION.md
§3.5), never a CLI subprocess.

TDD-first: the decision (loaded? -> skip; empty? -> load; unreachable/failed
-> DEGRADE, never panic) lives in ensure_model_loaded() over the UnslothControl
trait, unit-tested against a fake with zero network — that's the part that must
be reliable. UnslothHttp is the real reqwest impl (GET /v1/models,
POST /api/inference/load), mirroring the endpoints verified live on this box
(manual load + /v1/chat reply already confirmed end-to-end).

Tests (4, all green): already-loaded is a no-op (no reload churn); empty engine
loads the desired model; unreachable engine degrades WITHOUT attempting a load;
failed load degrades with the reason. Degrade-not-panic per #26.

Next: call ensure_model_loaded at startup with the configured model, then the
live persona bringup reasons through the fueled engine.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
joelteply added a commit that referenced this pull request Jun 21, 2026
The keystone (#1712) gave us ensure_model_loaded over a TDD'd trait; this
wires it into boot so the engine is fueled "automatically after the key."

unsloth Studio boots EMPTY — /v1/models is [] and any inference returns
"No GGUF model loaded" until something loads one. On startup the core now
spawns ensure_startup_model(): reads UNSLOTH_MODEL from config and, if set,
ensures that model is loaded into the engine.

- startup_model_action(Option<String>) -> StartupModelAction is the pure,
  TDD-tested config decision: set+non-empty -> Ensure(model); unset or blank
  -> Skip(reason). NO hardcoded default model path — auto-pick from
  /api/hub/cached-models is a future enhancement, not a baked-in path that's
  wrong on every box but the author's.
- ensure_startup_model() dispatches on it, delegating to ensure_model_loaded
  over the real HTTP surface, logging the outcome.
- Spawned fire-and-forget in main.rs alongside the other boot tasks: boot is
  never gated on the engine, and it's fully degrade-safe — engine down or
  load fails -> degrade+log, the substrate stays up on its fallback path,
  never panics ([[substrate-is-a-good-citizen-on-the-host]] / #26).

4 new unit tests cover the config decision (ensure / skip-no-default /
blank-is-unset / trimmed). Existing keystone tests unchanged.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants