# TOMBSTONE — wild_companions/ abandoned-scaffold cleanup (2026-05-28)

**Council:** `_council/2026-05-28-dead-code-wild-companions/`
**Convening:** 16th Minecraft Council
**Verdict:** 5/5 ARCHIVE on all 3 candidates + co-orphan
**Files archived:** 4
**Joseph's vote:** Archive 4 files (3 candidates + co-orphan `lookup_id_macro`)

---

## Files retired

| Original path | Reason |
|---|---|
| `wild_companions/capture/give_snare.mcfunction` | Redundant dispatcher — 30+ live producers already inline `loot give @s loot evercraft:wild_companions/dream_snare_tN` with the correct tier. Reads `#snare_tier ec.temp` for which there are **zero writers** anywhere in the datapack. If called, would print "Received Dream Snare!" + play sound while delivering NO item. |
| `wild_companions/capture/lookup_id.mcfunction` | Architecturally superseded. The live system reads `companion_id` directly from the head item's `minecraft:profile.properties[{name:"name"}].signature` at 5 live sites — no `id_map` indirection needed. |
| `wild_companions/capture/lookup_id_macro.mcfunction` | Sole-callee co-orphan of `lookup_id.mcfunction` (mirrors Council #12 + #13 co-orphan pattern). Dies the moment its only caller dies. |
| `wild_companions/hostile/store_id_on_zombie.mcfunction` | Zero callers AND fundamentally broken (Brain NBT — see lesson below). Lore-contradicts Ch19 canon (see canon note below). |

---

## Pattern

**Abandoned scaffold, NOT build-but-never-wired.** These 4 files were the first-pass design for an `id_map`-lookup + Brain-stamping capture pipeline. The codebase pivoted architecturally to a direct head-passenger profile-signature read pattern. The 4 archived files are first-pass design that got left behind when the better pattern took over.

This is the same shape as Council #5 (buddy v1→v2 ghosts) and Council #6 (tamed_bond memento scaffolds): an earlier draft was scaffolded, a superior pattern emerged elsewhere in the system, all consumers migrated to the new pattern, and the old pipeline was orphaned in-place rather than deleted.

---

## The Brain-NBT lesson (preserve for posterity)

`store_id_on_zombie.mcfunction` wrote to `Brain.wc_companion_id` on a zombie entity:

```
$data modify entity @e[type=zombie,tag=wc.hostile_new,limit=1,sort=nearest] Brain.wc_companion_id set value "$(companion_id)"
```

The codebase **has already documented this lesson** in two live files:

**`spawn/store_id_on_chicken.mcfunction:2`** (verbatim):
```
# Brain NBT gets overwritten by mob AI — use data storage instead
```

**`spawn/place.mcfunction:64`** (verbatim):
```
# Store wc.id → companion_id mapping in persistent storage (Brain gets wiped by mob AI)
```

**The 26.1 lesson:** mob `Brain` NBT is the runtime AI memory blob — Minecraft rebuilds it on each state transition (sleep/wake, age progression, conversion-to-drowned, chunk unload/reload, mode switches). Never store custom data there for any entity with vanilla AI behaviors. Use either:

1. **Data storage maps** keyed by an entity-scoreboard ID — the live pattern used by `spawn/store_id_on_chicken.mcfunction` writing to `storage evercraft:wild_companions id_map.<wc_id>`.
2. **Direct head-passenger profile-signature reads** — the current canonical pattern (see below).

If hostile-zombie capture is ever designed in the future, do NOT revive `store_id_on_zombie.mcfunction` as-written. The Brain field would be wiped by the next AI tick. Mirror the storage-map shape of `store_id_on_chicken` instead.

---

## The supersession path (current live pattern)

All 5 live consumers read `companion_id` directly from `minecraft:profile.properties[{name:"name"}].signature` on the head item, bypassing the `id_map` indirection entirely:

- `wild_companions/capture/attempt.mcfunction:13` — capture roll
- `wild_companions/process_click.mcfunction` — interaction click
- `wild_companions/horn/engage_queued.mcfunction` — horn queue engagement
- `wild_companions/interact/shiny_fight.mcfunction` — shiny battle entry
- `wild_companions/hostile/on_hit.mcfunction` — hostile ambush hit

The `id_map.*` storage IS still being written by `spawn/store_id_on_chicken.mcfunction` (called from both `spawn/place.mcfunction:66` and `hostile/place.mcfunction:63`) but, with `lookup_id_macro` archived, the storage map becomes **write-without-reader** — see follow-up #1 below.

---

## The Ch19 canon clarification

`story/chapter/ch19/tip_2.mcfunction` instructs players: *"Battle and capture a wild companion using a Dream Snare"* — aspirational copy.

The live mechanic at `wild_companions/capture/detect_use.mcfunction:17` only matches **peaceful carriers** (`@e[type=chicken,tag=wc.carrier,distance=..5]`). Snaring a hostile zombie was never live. The Ch19 `complete.mcfunction:2` narration is the actual canon: *"A wild companion chose to stay. That trust is rarer than any artifact."*

**Hostile-zombie capture (what `store_id_on_zombie` enabled) directly contradicts Ch19's "companion CHOSE to stay" canon.** It is a feature considered then declined. This tombstone preserves that decision so future contributors don't waste cycles re-deciding what canon already settled.

If a future "snare-after-battle on a weakened hostile" mechanic is ever desired, design it fresh — and use the storage-map persistence pattern, not Brain NBT.

---

## Out-of-scope follow-ups for `BIG_BRAIN/10-pending.md`

1. **`spawn/store_id_on_chicken.mcfunction` is now write-without-reader.** Its only consumer was `lookup_id_macro`. Live spawn paths (`spawn/place.mcfunction:66`, `hostile/place.mcfunction:63`) still call it every spawn, populating `storage evercraft:wild_companions id_map.<wc_id>` indefinitely. Queue a follow-up to either (a) drop the storage writes from spawn paths, or (b) re-introduce a reader if the indirection is ever wanted back. Storage churn grows unbounded across world lifetime otherwise. (See BIG_BRAIN/10-pending.md § Followups from council #16.)

2. **Ch19 `tip_2` references crafting a Dream Snare at a workstation — no recipe exists.** `find data/evercraft/recipe -name "*snare*"` returns empty. The craft-path quest variant is currently uncompletable via crafting (only via the 30+ loot drop sources). Queue a quests/recipes audit. (See BIG_BRAIN/10-pending.md § Followups from council #16.)

3. **Pets-cluster owner-binding hazard** in `hostile/on_hit.mcfunction:15,18` + `capture/attempt.mcfunction:9-13` — `@e[…,limit=1,sort=nearest]` without tag pre-selection. Vulnerable to wrong-companion lookup under cluster spawns. Already in the broader pets-cluster owner-binding audit queue; flagged here for record.

---

## Reversibility

If any candidate is ever needed back: `git mv` from this archive directory back to the original path under `data/evercraft/function/wild_companions/`. Update consumers accordingly.

**Caveat for `store_id_on_zombie`:** do NOT revive this file as-written. The `Brain.wc_companion_id` approach is fundamentally broken in 26.1 (the live codebase already documents this). If hostile capture is ever designed, write a NEW file mirroring `spawn/store_id_on_chicken.mcfunction`'s storage-map shape.

**Caveat for `give_snare`:** if a future quest/crafting/milestone surface ever needs tier-N-routing from a score, the dispatcher could be revived — but consider whether each callsite already knows its tier (the live pattern), in which case inline `loot give` is simpler.

---

## Smoke-test sequence (post-archive)

- `/function evercraft:wild_companions/capture/give_snare` → **Unknown function** error (expected)
- `/function evercraft:wild_companions/capture/lookup_id` → **Unknown function** error (expected)
- `/function evercraft:wild_companions/capture/lookup_id_macro` → **Unknown function** error (expected)
- `/function evercraft:wild_companions/hostile/store_id_on_zombie` → **Unknown function** error (expected)
- Capture a peaceful wild companion normally → unchanged (live `detect_use → attempt → success` path)
- Engage a hostile wild companion ambush → unchanged (live `hostile/place → on_hit → battle/start` path)
- All 6 `dream_snare_t{1..6}` loot tables still present and droppable from crates, fishing, treasure chests, structure bonuses, story rewards
