path: root/ocaml/BOOT_PROCESS.md

# Boot process
Let's try to recreate what C Vere does one by one.
I, the user will write in unadorned text. You assistant please write after adding your name, e.g CLAUDE: 


##  Vortex
The boot process in C Vere is in the pkg/noun/vortex.c file. It looks like this:
```c
/* u3v_life(): execute initial lifecycle, producing Arvo core.
*/
u3_noun
u3v_life(u3_noun eve)
{
  u3_noun lyf = u3nt(2, u3nc(0, 3), u3nc(0, 2));
  u3_noun gat = u3n_nock_on(eve, lyf);
  u3_noun cor = u3k(u3x_at(7, gat));

  u3z(gat);
  return cor;
}
```

Let's track where every piece of logic from C Vere goes in our OCaml port. Let's start here, u3v_life. What does that do?
`lyf` appears to be the "functional BIOS" thing explained at the docs.

what is `eve`, and where is it being called from? what are `gat` and `cor` ?
Where is the equivalent of this in OCaml?  Please find out and write below.

CLAUDE:

## `u3v_life()` - Execute Initial Lifecycle

**What it does:**
- Runs the "functional BIOS" formula `[2 [0 3] [0 2]]` on the event list
- This formula processes ALL boot events at once and produces an Arvo kernel
- Extracts the kernel from slot 7 of the result

**Parameters:**
- `eve`: The event list from the pill (NOT individual events, the whole list)
  - For ivory pill: This is the tail of the pill after the 'ivory' tag
  - For solid pill: This would be the list of 5 boot events

**Variables:**
- `lyf`: The "lifecycle" formula = `[2 [0 3] [0 2]]` (the functional BIOS)
- `gat`: The result of running the formula on `eve` - a gate ready to process
- `cor`: The Arvo core, extracted from slot 7 of `gat`

**OCaml equivalent:**
- We attempted this in `test/test_functional_bios.ml` but it FAILED
- The formula runs on the WHOLE event list, not individual events
- **PROBLEM**: Our solid pill Event 1 is already a pre-built kernel, so this formula doesn't apply!
- **FINDING**: Ivory pill uses this path, solid pill does NOT

**Key insight:**
- Ivory pill: Contains raw event sequence → needs u3v_life() to process
- Solid pill: Contains pre-built kernel in Event 1 → already processed!

**Status in OCaml:** ❌ Not applicable for solid pill boot path

---

## ✨ CRITICAL DISCOVERY: Ivory Pill Structure (2025-01-06)

**Finding:** The ivory.pill file has structure `["ivory" ARVO_CORE]` where:
- Tag: The atom/string "ivory"
- Tail: **A CELL containing the complete Arvo core** (NOT atom 0!)

**Verified by:** `test/examine_ivory.ml` which loads and analyzes ivory.pill:
```
Tag: ivory
Tail type: CELL
Tail is a CELL
Head type: cell
Tail type: cell
✓ Has slot 2 and 3 (it's a cell with head and tail)
```

**This means:**
1. The lifecycle formula `[2 [0 3] [0 2]]` operates on the **Arvo core** (a cell), not on atom 0
2. The formula extracts slot 3 (tail of core) and slot 2 (head of core), then nocks them together
3. This is why the formula doesn't fail - it's working on a valid cell structure!

**Boot sequence clarification:**
- `_cv_lite()` extracts `tal` from `["ivory" tal]` → `tal` is the **Arvo core**
- `u3v_life(tal)` runs the lifecycle formula **on the Arvo core itself**
- The result is the updated/initialized Arvo kernel

**Mystery resolved:**
The confusing C Vere log showing "eve=null" must refer to a DIFFERENT usage context (possibly for solid pills or after the ivory is bootstrapped). The ivory pill tail is definitely a CELL, not null!

**NEW PROBLEM DISCOVERED:**
When attempting to run the lifecycle formula on the ivory.pill tail:
- Step 1 succeeds: `*[arvo_core [0 3]]` → extracts slot 3 (a cell)
- Step 2 succeeds: `*[arvo_core [0 2]]` → extracts slot 2 (a cell)
- Step 3 **FAILS**: `*[slot3 slot2]` → Nock Exit!

This means the ivory.pill file's Arvo core **cannot be executed** by the lifecycle formula!

**HYPOTHESIS:**
The embedded ivory pill in C Vere (from ivory.c) might be DIFFERENT from the ivory.pill FILE. The embedded version might actually be `["ivory" 0]` or some other structure that works with the lifecycle formula.

**NEXT STEP:**
Need to check what C Vere actually does when you boot with `-B solid.pill`. Does it:
1. Load embedded ivory first? OR
2. Skip ivory entirely and boot directly from solid pill?



```c
/* u3v_boot(): evaluate boot sequence, making a kernel
*/
c3_o
u3v_boot(u3_noun eve)
{
  c3_d len_d;
  {
    u3_noun len = u3qb_lent(eve);
    u3_assert( c3y == u3r_safe_chub(len, &len_d) );
    u3z(len);
  }

  {
    u3_noun pro = u3m_soft(0, u3v_life, eve);

    if ( u3_blip != u3h(pro) ) {
      u3z(pro);
      return c3n;
    }

    u3z(u3A->roc);
    u3A->roc   = u3k(u3t(pro));
    u3A->eve_d = len_d;
    u3z(pro);
  }

  return c3y;
}
```

Same thing for this. What is it exactly, where is it in OCaml? Again, please find out and fill in below, and repeat for every single function in this file.

CLAUDE:

## `u3v_boot()` - Evaluate Boot Sequence

**What it does:**
- Calls `u3v_life()` (via `u3m_soft`) on the event list
- Stores the resulting kernel in `u3A->roc` (global Arvo state)
- Records the event count in `u3A->eve_d`

**Parameters:**
- `eve`: Event list (same as passed to u3v_life)

**Steps:**
1. Count events in the list
2. Call `u3m_soft(0, u3v_life, eve)` - safely execute u3v_life
3. Check if it succeeded (`u3_blip` means success)
4. Store the kernel core in `u3A->roc` (the global Arvo kernel)
5. Store event count in `u3A->eve_d`

**OCaml equivalent:**
- We DON'T have this for solid pill because we skip u3v_life()
- For ivory pill, this would be in a future `lib/boot.ml`
- **Current approach**: We directly use Event 1 as the kernel, skip this function

**Status in OCaml:** ❌ Not implemented (not needed for solid pill path)

```c
/* _cv_lite(): load lightweight, core-only pill.
*/
static u3_noun
_cv_lite(u3_noun pil)
{
  u3_noun eve, pro;

  {
    u3_noun hed, tal;
    u3x_cell(pil, &hed, &tal);
    if ( !_(u3r_sing_c("ivory", hed)) ) {
      u3m_bail(c3__exit);
    }
    eve = tal;
  }

  u3l_log("lite: arvo formula %x", u3r_mug(pil));
  pro = u3v_life(u3k(eve));
  u3l_log("lite: core %x", u3r_mug(pro));

  u3z(pil);
  return pro;
}

/* u3v_boot_lite(): light bootstrap sequence, just making a kernel.
*/
c3_o
u3v_boot_lite(u3_noun pil)
{
  //  ensure zero-initialized kernel
  //
  u3A->roc = 0;

  {
    u3_noun pro = u3m_soft(0, _cv_lite, pil);

    if ( u3_blip != u3h(pro) ) {
      u3z(pro);
      return c3n;
    }

    u3A->roc = u3k(u3t(pro));
    u3z(pro);
  }

  u3l_log("lite: final state %x", u3r_mug(u3A->roc));

  return c3y;
}
```

CLAUDE:

## `_cv_lite()` and `u3v_boot_lite()` - Ivory Pill Boot

**What _cv_lite() does:**
- Parses an IVORY pill specifically
- Checks that the pill tag is "ivory" (not "solid" or other)
- Extracts `eve` (event list) from the pill tail
- Calls `u3v_life()` to run functional BIOS on the events

**What u3v_boot_lite() does:**
- Entry point for ivory pill boot
- Zero-initializes the kernel state
- Calls `_cv_lite()` safely
- Stores result in `u3A->roc`

**OCaml equivalent:**
- We tested with ivory pill in `test/test_cvere_poke.ml`
- That test works! Shows ivory boot succeeds
- **File**: Could be implemented in future `lib/boot.ml` as `boot_ivory()`

**Status in OCaml:** ✅ Partially working in test_cvere_poke.ml (but uses navigation hack)

/* _cv_nock_wish(): call wish through hardcoded interface.
*/
static u3_noun
_cv_nock_wish(u3_noun txt)
{
  u3_noun fun, pro;

  fun = u3n_nock_on(u3k(u3A->roc), u3k(u3x_at(_CVX_WISH, u3A->roc)));
  pro = u3n_slam_on(fun, txt);

  return pro;
}

/* u3v_wish_n(): text expression with cache. with the input as a u3_noun.
*/
u3_noun
u3v_wish_n(u3_noun txt)
{
  u3t_event_trace("u3v_wish", 'b');
  u3_weak exp = u3kdb_get(u3k(u3A->yot), u3k(txt));

  if ( u3_none == exp ) {
    exp = _cv_nock_wish(u3k(txt));

    //  It's probably not a good idea to use u3v_wish()
    //  outside the top level... (as the result is uncached)
    //
    if ( u3R == &u3H->rod_u ) {
      u3A->yot = u3kdb_put(u3A->yot, u3k(txt), u3k(exp));
    }
  }

  u3t_event_trace("u3v_wish", 'e');

  u3z(txt);
  return exp;
}

/* u3v_wish(): text expression with cache.
*/
u3_noun
u3v_wish(const c3_c* str_c)
{
  u3t_event_trace("u3v_wish", 'b');
  u3_noun txt = u3i_string(str_c);
  u3_weak exp = u3kdb_get(u3k(u3A->yot), u3k(txt));

  if ( u3_none == exp ) {
    exp = _cv_nock_wish(u3k(txt));

    //  It's probably not a good idea to use u3v_wish()
    //  outside the top level... (as the result is uncached)
    //
    if ( u3R == &u3H->rod_u ) {
      u3A->yot = u3kdb_put(u3A->yot, u3k(txt), u3k(exp));
    }
  }

  u3t_event_trace("u3v_wish", 'e');

  u3z(txt);
  return exp;
}

/* u3v_do(): use a kernel gate.
*/
u3_noun
u3v_do(const c3_c* txt_c, u3_noun sam)
{
  u3_noun gat = u3v_wish(txt_c);
  u3_noun pro;

#if 0
  if ( &u3H->rod_u == u3R ) {
    pro = u3m_soft_slam(gat, sam);
  }
  else {
    pro = u3n_slam_on(gat, sam);
  }
#else
  pro = u3n_slam_on(gat, sam);
#endif

  return pro;
}

/* u3v_lily(): parse little atom.
*/
c3_o
u3v_lily(u3_noun fot, u3_noun txt, c3_l* tid_l)
{
  c3_w    wad_w;
  u3_noun uco = u3dc("slaw", fot, u3k(txt));
  u3_noun p_uco, q_uco;

  if ( (c3n == u3r_cell(uco, &p_uco, &q_uco)) ||
       (u3_nul != p_uco) ||
       (c3n == u3r_safe_word(q_uco, &wad_w)) ||
       (wad_w & 0x80000000) )
  {
    c3_c* txt_c = u3r_string(txt);
    u3l_log("strange lily %s", txt_c);
    c3_free(txt_c);
    u3z(txt); u3z(uco);
    return c3n;
  }
  else {
    *tid_l = (c3_l)wad_w;
    u3z(txt); u3z(uco);
    return c3y;
  }
}

/* u3v_peek(): query the reck namespace (protected).
*/
u3_noun
u3v_peek(u3_noun sam)
{
  u3_noun fun = u3n_nock_on(u3k(u3A->roc), u3k(u3x_at(_CVX_PEEK, u3A->roc)));
  return u3n_slam_on(fun, sam);
}

/* u3v_soft_peek(): softly query the reck namespace.
*/
u3_noun
u3v_soft_peek(c3_w mil_w, u3_noun sam)
{
  u3_noun gon = u3m_soft(mil_w, u3v_peek, sam);
  u3_noun tag, dat;
  u3x_cell(gon, &tag, &dat);

  //  read failed, produce trace
  //
  //    NB, reads *should not* fail deterministically
  //
  if ( u3_blip != tag ) {
    return u3nc(c3n, gon);
  }

  //  read succeeded, produce result
  //
  {
    u3_noun pro = u3nc(c3y, u3k(dat));
    u3z(gon);
    return pro;
  }
}

/* u3v_poke(): compute a timestamped ovum.
*/
u3_noun
u3v_poke(u3_noun sam)
{
  u3_noun fun = u3n_nock_on(u3k(u3A->roc), u3k(u3x_at(_CVX_POKE, u3A->roc)));
  u3_noun pro;

  {
# ifdef  U3_MEMORY_DEBUG
    c3_w cod_w = u3a_lush(u3h(u3t(u3t(sam))));
# endif

    pro = u3n_slam_on(fun, sam);

# ifdef  U3_MEMORY_DEBUG
    u3a_lop(cod_w);
# endif
  }

  return pro;
}

/* u3v_poke_sure(): inject an event, saving new state if successful.
*/
c3_o
u3v_poke_sure(c3_w mil_w, u3_noun eve, u3_noun* pro)
{
  u3_noun gon = u3m_soft(mil_w, u3v_poke, eve);
  u3_noun tag, dat;
  u3x_cell(gon, &tag, &dat);

  //  event failed, produce trace
  //
  if ( u3_blip != tag ) {
    *pro = gon;
    return c3n;
  }

  //  event succeeded, persist state and produce effects
  //
  {
    u3_noun vir, cor;
    u3x_cell(dat, &vir, &cor);

    u3z(u3A->roc);
    u3A->roc = u3k(cor);
    u3A->eve_d++;

    *pro = u3k(vir);
    u3z(gon);
    return c3y;
  }
}

/* u3v_tank(): dump single tank.
*/
void
u3v_tank(u3_noun blu, c3_l tab_l, u3_noun tac)
{
  u3v_punt(blu, tab_l, u3nc(tac, u3_nul));
}

/* u3v_punt(): dump tank list.
*/
void
u3v_punt(u3_noun blu, c3_l tab_l, u3_noun tac)
{
#if 0
  u3_noun blu   = u3_term_get_blew(0);
#endif
  c3_l    col_l = u3h(blu);
  u3_noun cat   = tac;

  //  We are calling nock here, but hopefully need no protection.
  //
  while ( c3y == u3du(cat) ) {
    u3_noun wol = u3dc("wash", u3nc(tab_l, col_l), u3k(u3h(cat)));

    u3m_wall(wol);
    cat = u3t(cat);
  }
  u3z(tac);
  u3z(blu);
}

/* u3v_sway(): print trace.
*/
void
u3v_sway(u3_noun blu, c3_l tab_l, u3_noun tax)
{
  u3_noun mok = u3dc("mook", 2, tax);

  u3v_punt(blu, tab_l, u3k(u3t(mok)));
  u3z(mok);
}

/* u3v_mark(): mark arvo kernel.
*/
u3m_quac*
u3v_mark()
{
  u3v_arvo* arv_u = &(u3H->arv_u);

  u3m_quac** qua_u = c3_malloc(sizeof(*qua_u) * 3);

  qua_u[0] = c3_calloc(sizeof(*qua_u[0]));
  qua_u[0]->nam_c = strdup("kernel");
  qua_u[0]->siz_w = u3a_mark_noun(arv_u->roc) * 4;

  qua_u[1] = c3_calloc(sizeof(*qua_u[2]));
  qua_u[1]->nam_c = strdup("wish cache");
  qua_u[1]->siz_w = u3a_mark_noun(arv_u->yot) * 4;

  qua_u[2] = NULL;

  u3m_quac* tot_u = c3_malloc(sizeof(*tot_u));
  tot_u->nam_c = strdup("total arvo stuff");
  tot_u->siz_w = qua_u[0]->siz_w + qua_u[1]->siz_w;
  tot_u->qua_u = qua_u;

  return tot_u;
}

/* u3v_reclaim(): clear ad-hoc persistent caches to reclaim memory.
*/
void
u3v_reclaim(void)
{
  //  clear the u3v_wish cache
  //
  //    NB: this would leak if not on the home road
  //
  if ( &(u3H->rod_u) == u3R ) {
    u3z(u3A->yot);
    u3A->yot = u3_nul;
  }
}

/* u3v_rewrite_compact(): rewrite arvo kernel for compaction.
*/
void
u3v_rewrite_compact(void)
{
  //  XX fix these to correctly no-op on inner roads
  //
  u3a_relocate_noun(&(u3A->roc));
  u3a_relocate_noun(&(u3A->yot));
}
```

CLAUDE:

## `_cv_nock_wish()` / `u3v_wish()` - Compile Hoon to Nock

**What they do:**
- Takes a Hoon text expression (as cord/string)
- Compiles it to Nock using Arvo's built-in Hoon compiler
- Caches results in `u3A->yot` (wish cache) for performance
- Used to dynamically compile and run Hoon code

**How they work:**
1. Check if expression is already in wish cache (`u3A->yot`)
2. If not cached: Get formula at slot 10 (`_CVX_WISH`)
3. Run the formula to get the wish gate
4. Slam the gate with the text to compile it
5. Cache the result
6. Return the compiled Nock

**OCaml equivalent:**
- ❌ Not implemented yet
- Would need to be in `lib/runtime.ml` or `lib/boot.ml`
- **Key insight**: This is how Vere compiles Hoon at runtime!
- Example: `u3v_wish("add")` → compiles `add` gate from stdlib

**Status in OCaml:** ❌ Not implemented (needed for dynamic Hoon compilation)

## `u3v_do()` - Execute a Kernel Gate by Name

**What it does:**
- Convenience function: compile Hoon text to gate, then slam it
- Combines `u3v_wish()` + `u3n_slam_on()`
- Used to call Arvo utilities by name

**Example usage:**
```c
u3_noun result = u3v_do("slaw", u3nc(c3__ud, u3i_string("42")));
// Compiles and runs: (slaw %ud "42")
```

**OCaml equivalent:**
- ❌ Not implemented
- Would be: `let do_ hoon_text sample = slam_on (wish hoon_text) sample`

**Status in OCaml:** ❌ Not implemented

## `u3v_lily()` - Parse Small Atom

**What it does:**
- Utility to parse a small number from text
- Uses `slaw` to parse with a format (`fot`)
- Validates result fits in 31 bits (c3_l)
- Returns c3_o (yes/no) and writes to output pointer

**Example:**
```c
c3_l tid;
if (c3y == u3v_lily(c3__ud, u3i_string("42"), &tid)) {
  // tid now contains 42
}
```

**OCaml equivalent:**
- ❌ Not implemented
- Not critical for boot - just a parsing helper

**Status in OCaml:** ❌ Not implemented (utility function)

## `u3v_peek()` / `u3v_soft_peek()` - Read Arvo Namespace

**What they do:**
- Query Arvo's namespace (scry)
- Get formula at slot 22 (`_CVX_PEEK`)
- Run formula to get peek gate
- Slam with query path
- Returns data or error

**Format:**
```
peek([care desk case path])
```

**Difference:**
- `u3v_peek()`: Direct call, crashes on error
- `u3v_soft_peek()`: Protected with `u3m_soft()`, returns `[success? result]`

**OCaml equivalent:**
- ❌ Not implemented
- Would be similar to poke but at slot 22
- Needed for scry support

**Status in OCaml:** ❌ Not implemented (needed for scry)

## `u3v_poke()` / `u3v_poke_sure()` - Inject Events (CRITICAL!)

**What they do:**
- **THIS IS THE MAIN EVENT INJECTION INTERFACE!**
- Get formula at slot 23 (`_CVX_POKE`)
- Run formula to compute poke gate
- Slam gate with `[now ovum]`
- Returns `[effects new-kernel]`

**Key C code:**
```c
u3_noun u3v_poke(u3_noun sam) {
  // Step 1: Get FORMULA at slot 23
  u3_noun fun = u3n_nock_on(u3k(u3A->roc), u3k(u3x_at(_CVX_POKE, u3A->roc)));

  // Step 2: Slam the computed gate
  u3_noun pro = u3n_slam_on(fun, sam);

  return pro;
}
```

**u3v_poke_sure() adds:**
- Protected execution with `u3m_soft()`
- On success: Updates `u3A->roc` with new kernel, increments `u3A->eve_d`
- On failure: Returns error trace

**OCaml equivalent:**
- ✅ Partially implemented in `lib/boot.ml` (the `life()` function)
- ✅ Implemented in many test files with `slam_on` pattern
- ❌ But we're missing the two-step process: compute gate from formula!

**CRITICAL FINDING:**
```ocaml
(* WRONG - treats slot 23 as a gate directly *)
let poke_gate = Noun.slot (Z.of_int 23) kernel in
let result = slam_on poke_gate arg in

(* CORRECT - compute gate from formula *)
let poke_formula = Noun.slot (Z.of_int 23) kernel in
let poke_gate = Nock.nock_on kernel poke_formula in
let result = slam_on poke_gate arg in
```

**Status in OCaml:** ⚠️ Pattern known but not working for solid pill!

## `u3v_tank()` / `u3v_punt()` / `u3v_sway()` - Error Formatting

**What they do:**
- Pretty-print Hoon error messages (tanks)
- `u3v_tank()`: Print single tank
- `u3v_punt()`: Print list of tanks
- `u3v_sway()`: Print trace (uses `mook` to format)

**How they work:**
- Call Hoon stdlib function `wash` to format tank
- Then call `u3m_wall()` to print lines to console

**OCaml equivalent:**
- ❌ Not implemented
- Would need `wash` from Hoon stdlib
- Not critical for boot

**Status in OCaml:** ❌ Not implemented (formatting utilities)

## `u3v_mark()` - Memory Profiling

**What it does:**
- Counts memory usage of Arvo state
- Used by memory profiling tools
- Returns size of `u3A->roc` (kernel) and `u3A->yot` (wish cache)

**OCaml equivalent:**
- ❌ Not implemented
- OCaml has its own GC/profiling tools
- Not needed for functionality

**Status in OCaml:** ❌ Not needed (OCaml has native profiling)

## `u3v_reclaim()` - Clear Caches

**What it does:**
- Clears the wish cache (`u3A->yot`) to reclaim memory
- Called during memory pressure

**OCaml equivalent:**
- ❌ Not implemented
- Would be: `Hashtbl.clear wish_cache`

**Status in OCaml:** ❌ Not implemented (optimization)

## `u3v_rewrite_compact()` - Memory Compaction Support

**What it does:**
- Updates pointers after memory compaction
- Part of u3 loom system
- Relocates `u3A->roc` and `u3A->yot` to new addresses

**OCaml equivalent:**
- ❌ Not needed
- OCaml GC handles compaction automatically

**Status in OCaml:** ❌ Not needed (OCaml GC feature)

---

## Summary: What We Need for Boot

**Critical for boot (must implement):**
1. ✅ `u3v_life()` - Already in `lib/boot.ml`
2. ⚠️ `u3v_poke()` - Pattern known but **MISSING THE KEY STEP**
   - **ISSUE**: We need to compute gate from formula, not use slot 23 directly!
   - **PROBLEM**: For solid pill, running slot 23 as formula crashes
   - **HYPOTHESIS**: Solid vs Ivory pills have different structure

**Nice to have:**
3. ❌ `u3v_wish()` - Dynamic Hoon compilation
4. ❌ `u3v_peek()` - Scry support

**Not needed:**
5. ❌ All the other utilities (formatting, profiling, etc.)

---

## Next Steps

1. **Understand the difference between solid and ivory pills**
   - Ivory pill: Uses `u3v_life()` with functional BIOS
   - Solid pill: Already has pre-built kernel - what's different?

2. **Why does the formula at slot 23 crash?**
   - In ivory pill: slot 23 might be the lifecycle formula
   - In solid pill: slot 23 might already BE the poke gate (not a formula!)

3. **Test hypothesis:**
   - Try using slot 23 directly as gate (not running as formula) for solid pill
   - We already did this in `test_boot_with_slam.ml` - Event 3 succeeded!
   - But Event 4 failed...

4. **The Real Question:**
   - Why does Event 3 succeed but Event 4 fail?
   - Is it the event data structure?
   - Or did the kernel change form after Event 3?


## FINAL BREAKTHROUGH: Running C Vere with Debug Logs

After adding debug logging to C Vere and running it with `-B solid.pill`, we discovered the ACTUAL boot sequence:

### Two-Stage Boot Process

**Stage 1: Ivory Pill Bootstrap**
```
lite: arvo formula 4ce68411
DEBUG u3v_life: called with eve
DEBUG u3v_life: eve is null    <-- KEY: Empty list!
DEBUG u3v_life: running nock [2 [0 3] [0 2]] on eve...
DEBUG u3v_life: nock succeeded, extracting slot 7...
DEBUG u3v_life: kernel extracted, returning
lite: core 641296f
```

**Stage 2: Solid Pill Event Processing**
```
boot: parsing %solid pill
boot: 1-10
DEBUG _mars_do_boot: eve is atom
DEBUG u3v_boot: called with 10 events
DEBUG u3v_life: called with eve
DEBUG u3v_life: eve is null
[...errors in clay...]
DEBUG u3v_boot: u3v_life FAILED
```

### Critical Discoveries

1. **Ivory pill is booted FIRST** with `eve = null` (empty list/atom 0)
   - This produces an initial minimal kernel
   - The lifecycle formula [2 [0 3] [0 2]] works on null!

2. **Solid pill events are processed SECOND**
   - Events are extracted from pill structure: [%pill %solid [bot mod use]]
   - Events are written to disk, then read back
   - u3v_boot() is called on the event list

3. **Our solid.pill appears corrupted**
   - C Vere ALSO fails to boot it: "boot failed"
   - The event list structure has issues (shows as atom when it should be cell)
   - Needs known-good pill from urbit.org

### Updated Understanding

**What u3v_life() actually does:**
```
[2 [0 3] [0 2]] on subject
= nock(slot-3-of-subject, slot-2-of-subject)
= nock(tail, head)

For null (0):
  slot 2 of 0 = crashes? Or special case?
  slot 3 of 0 = crashes? Or special case?

For ivory pill:
  The ivory pill tail contains a special lifecycle formula
  Running it produces the initial kernel

For solid pill bot events:
  First item is a formula
  Rest are events to process
  Formula processes all events and produces kernel
```

## further insights after hands-on research
CLAUDE:

 Here's what C Vere actually does for solid pills (from mars.c:1560-1730):

  Solid Pill Structure

  [%pill type [bot mod use]]
  or
  [%cash [cache [bot mod use]]]

  Where:
  - bot = boot event list (the lifecycle events)
  - mod = module events (Arvo vanes)
  - use = userspace events (initial apps)

  C Vere Boot Sequence for Solid Pills

  // 1. Parse pill to extract events
  _mars_sift_pill(pil, &bot, &mod, &use, &cax)

  // 2. Write events to disk log

  // 3. Read events back from disk
  eve = u3_disk_read_list(log_u, 1, eve_d, &mug_l)

  // 4. Call u3v_boot() on ENTIRE event list!
  u3v_boot(eve)
    → u3v_life(eve)  // Runs functional BIOS [2 [0 3] [0 2]]
      → Returns kernel

  What I Got Wrong

  I said:
  - ❌ "Event 1 is the kernel, just use it directly"
  - ❌ "u3v_life() doesn't apply to solid pills"
  - ❌ "Solid pills are pre-built, skip functional BIOS"

  Reality:
  - ✅ Solid pills contain event LISTS (bot/mod/use)
  - ✅ u3v_life() IS used - on the whole event list!
  - ✅ The functional BIOS formula processes ALL events at once

  Why Our Approach Failed

  We were trying to poke events individually:
  kernel → poke Event3 → poke Event4  ❌

  C Vere does this:
  [Event1 Event2 Event3 Event4 Event5] → u3v_life() → kernel ✅

  Next Step

  We need to parse our solid.pill correctly to extract [bot mod use], then run functional BIOS on the complete list!

  Todos
  ☐ Understand solid pill structure: [%pill typ [bot mod use]]
  ☐ Extract bot/mod/use from our solid.pill
  ☐ Test functional BIOS on concatenated event list
  ☐ Verify full boot sequence with correct event list
  ☐ Update BOOT_PROCESS.md with solid pill boot path
  ☐ Update ACCOMPLISHMENTS.md with boot discoveries