## Flagged ambiguities

- **"Friends list"** — legacy **Friend Data** (an in-universe collectable) vs a *modern*
  account-level friends list proposed in `.planning/research/FEATURES.md` as a new
  differentiator. These may be the same concept or two distinct systems. **Unresolved.**

## Flagged ambiguities

- **"Friends list"** — legacy **Friend Data** (inventory category 2, a genuine in-universe
  friends list) vs a *modern* account-level friends list proposed in
  `.planning/research/FEATURES.md`. Recon confirms legacy already had an in-universe list, so the
  real question is modernize-in-place vs faithful + separate layer. **Unresolved (Q4).**
- **Hidden-tile contiguous-body visibility** — user states Navis on hidden tiles are invisible to
  others not on the same contiguous hidden body. Recon found **no such cull in `client-5-8`**
  (hidden tiles are cloaked floor + self-reveal only). Is this in another revision, a ReBNO
  design intention, or missed by recon? **Unresolved.**
- **Hexsling direction-preference** — user states a hexsling with 1–2 exits "prefers the
  direction the player wasn't travelling." Recon found that reversal only on the **hexbridge**
  bounce, not on hexslings, in `client-5-8`. Same three possibilities. **Unresolved.**
- **`dabypass` meaning** — one recon pass read it as "exempt from the Abyss," another as "stuck
  respawning in the Abyss until you climb out." Direct conflict. **Needs a code re-check.**
- **Legacy is fully client-authoritative** — the Master only relays. ReBNO is server-authoritative
  (CLAUDE.md Hard Rule 1). Recorded here as the defining legacy→ReBNO divergence, not an
  ambiguity per se. **Confirm scope in Q4.3.**

-- **"Friends list"** — legacy **Friend Data** (an in-universe collectable) vs a *modern*

-  account-level friends list proposed in `.planning/research/FEATURES.md` as a new

-  differentiator. These may be the same concept or two distinct systems. **Unresolved.**

+- **"Friends list"** — legacy **Friend Data** (inventory category 2, a genuine in-universe

+  friends list) vs a *modern* account-level friends list proposed in

+  `.planning/research/FEATURES.md`. Recon confirms legacy already had an in-universe list, so the

+  real question is modernize-in-place vs faithful + separate layer. **Unresolved (Q4).**

+- **Hidden-tile contiguous-body visibility** — user states Navis on hidden tiles are invisible to

+  others not on the same contiguous hidden body. Recon found **no such cull in `client-5-8`**

+  (hidden tiles are cloaked floor + self-reveal only). Is this in another revision, a ReBNO

+  design intention, or missed by recon? **Unresolved.**

+- **Hexsling direction-preference** — user states a hexsling with 1–2 exits "prefers the

+  direction the player wasn't travelling." Recon found that reversal only on the **hexbridge**

+  bounce, not on hexslings, in `client-5-8`. Same three possibilities. **Unresolved.**

+- **`dabypass` meaning** — one recon pass read it as "exempt from the Abyss," another as "stuck

+  respawning in the Abyss until you climb out." Direct conflict. **Needs a code re-check.**

+- **Legacy is fully client-authoritative** — the Master only relays. ReBNO is server-authoritative

+  (CLAUDE.md Hard Rule 1). Recorded here as the defining legacy→ReBNO divergence, not an

+  ambiguity per se. **Confirm scope in Q4.3.**


Glossary fully reconciled with all three recon passes; contradictions flagged in `CONTEXT.md`. All recon done. Two things now need you — and per the grilling discipline, the **contradictions come first** (code disagrees with your mental model — that's exactly the gap worth closing).

---

**Q5 (now active) — reconcile two mechanics you described that aren't in the `client-5-8` build.**

For each, which is it: **(a)** present in a different revision (`source-archive/`), **(b)** a **ReBNO design intention** you hold, not legacy behavior, or **(c)** recon missed it?

1. **Hidden-tile contiguous-body visibility** (Navi on hidden floor invisible to others not on the same connected hidden body). Recon: 5-8 has no flood-fill/visibility-cull — hidden tiles are just cloaked floor with a self-reveal toggle.
   *My read:* likely **(b) ReBNO intention.** Legacy was a client-relay — it *couldn't* cleanly enforce per-player peer-visibility. This rule is a natural fit for ReBNO's authoritative server (interest management), but by the strict Q4 principle it's a **new system** — a blessed one, but worth naming as such.

2. **Hexsling direction-preference** (1–2-exit hexsling sends you the way you weren't going). Recon found that reversal only on the **hexbridge** bounce in 5-8.
   *My read:* likely **(a) older revision or (c) conflation** — this sounds like a concrete legacy rule, not a new idea. Worth a targeted check of `source-archive/` before we treat it as canon.

Want me to spin a follow-up recon agent into `legacy/source-archive/` to settle #2 (and re-check the `dabypass` conflict) while you think?

---

**Q4 still queued** (answer after, or together): (1) is the QoL-vs-new-system dividing principle right; (2) Friend Data modernize-in-place vs separate layer; (3) server-authoritative inventory as a mandated divergence.


-Walking: correct -Hexporting: wrong. hexporters are floor terminals that split the navi into 6 orbs of light, which then form into a flat hexagon of light which travels in a straight line across empt…


ReBNO feature parity and platform expansion


Q5: 1. is (b), yes. 2. certainly (c). existed in legacy. you can recon it further -Q4: 1. yes, your proposed dividing principle is right 2. friend data modernize in place. 3. yes, server-authoritative inventory. --- as for your raised borders, 1 and 2 i agree. 3 i think is trivial, because ReBNO's map system is already a chunked overworld --> hexporting between two zones is nothing special, zone transition mostly loads in the same way a new chunk of your current zone would. 4 we'll continue to use friend data, but likely present it a bit differently so it's simpler to use. --- right, take-a-break.exe is an easter egg that will probably not be ported. -while Joker Shell is an admin item, it has nothing to do with RCE. it enabled admins to spawn a boundless, time-gated "ghost" that could walk anywhere without consequence, then optionally teleport to it. its inclusion is trivial and very helpful for testing features, terrain, and possibly helping out struggling players. -there's also the "Location" mod item, which simply enabled a mod to change their world coordinates. also not RCE. i recommend running recon on the whole set to differentiate what's simply RCE, and which were mod-level features with reasonable fencing. --- yes, the Watch system exists and is not gated by a navi expansion. it's like a more limited Duo system. --- going forward, please launch legacy asset recon for all new subjects, and do it before you grill. it will help the session be more comprehensive.


<owl_reachability_notice>
You have an active owl perch. When spawning subagents or doing work, use run_in_background: true so you stay reachable for incoming messages.
</owl_reachability_notice>


CAVEMAN MODE ACTIVE (full). Drop articles/filler/pleasantries/hedging. Fragments OK. Code/commits/security: write normal.


Big resolutions. Capturing all, and noting the key ReBNO architectural fact you just dropped: **ReBNO is a chunked overworld**, so a zone transition ≈ loading the next chunk — that's why cross-zone hexporters are trivial, not a new system. Also correcting Joker Shell (testing-ghost, *not* RCE) and resolving Friend Data + the visibility/inventory items.


Edit

**Zone**:
A top-level region. In legacy BNO each Zone is exactly **one GameMaker room** (~11 total:
BNCentral, Bahoo, Noiya, Floes of Ghennam, Emptiness' Hull, Deserted Lobby, Prairie Flats,
Database, Traverse Core, Schweisstar, and the Digital Abyss / Abyssal Ruin). All inter-zone
travel is teleport-gated, but a zone can be reached on foot (or via a found **Warp**) before you
hold its Link Data — you simply cannot fast-travel to it yet.

**Zone**:
A top-level region. In legacy BNO each Zone is exactly **one GameMaker room** (~11 total:
BNCentral, Bahoo, Noiya, Floes of Ghennam, Emptiness' Hull, Deserted Lobby, Prairie Flats,
Database, Traverse Core, Schweisstar, and the Digital Abyss / Abyssal Ruin). All inter-zone
travel is teleport-gated, but a zone can be reached on foot (or via a found **Warp**) before you
hold its Link Data — you simply cannot fast-travel to it yet.
_ReBNO note:_ ReBNO replaces legacy's one-room-per-zone with a single **chunked overworld** — a
zone transition loads much like loading the next chunk of your current zone. Consequence:
cross-zone hexporters are trivial (no special-casing) and therefore in-scope, not a new system.


The file C:\Users\decid\Documents\projects\rebno\CONTEXT.md has been updated successfully. (file state is current in your context — no need to Read it back)

**Zone**:
A top-level region. In legacy BNO each Zone is exactly **one GameMaker room** (~11 total:
BNCentral, Bahoo, Noiya, Floes of Ghennam, Emptiness' Hull, Deserted Lobby, Prairie Flats,
Database, Traverse Core, Schweisstar, and the Digital Abyss / Abyssal Ruin). All inter-zone
travel is teleport-gated, but a zone can be reached on foot (or via a found **Warp**) before you
hold its Link Data — you simply cannot fast-travel to it yet.
_ReBNO note:_ ReBNO replaces legacy's one-room-per-zone with a single **chunked overworld** — a
zone transition loads much like loading the next chunk of your current zone. Consequence:
cross-zone hexporters are trivial (no special-casing) and therefore in-scope, not a new system.

+_ReBNO note:_ ReBNO replaces legacy's one-room-per-zone with a single **chunked overworld** — a

+zone transition loads much like loading the next chunk of your current zone. Consequence:

+cross-zone hexporters are trivial (no special-casing) and therefore in-scope, not a new system.

A named sub-region *within* a Zone's single room (not a separate room), delimited by invisible


**TakABrak** (keyid 4):
An **easter-egg** key item ("Take-A-Break.exe"), not an ability-gating expansion. Lives in the
Key category but gates nothing.

**Mod Item** (Key-category IDs 900–909):
The legacy **admin / RCE item set** (`<M:Exc>`, `<M:NetExc>`, `<M:JkrShl>` = Joker Shell, …),
each wired to admin sub-commands. This is the original "run clipboard as superuser" admin model
— an **anti-port** per CLAUDE.md Hard Rule 3, NOT a collectable reward. Joker Shell (the fastest
"joker" movement tier) is an admin item, not parity content.

**TakABrak** (keyid 4):
An **easter-egg** key item ("Take-A-Break.exe"), not an ability-gating expansion. Gates nothing.
**Likely NOT ported** to ReBNO.

**Mod Item** (Key-category IDs 900–909):
A **mixed** admin item set — NOT uniformly RCE. Two sub-kinds:
- **RCE model** (`<M:Exc>`, `<M:NetExc>`, …) — the original "run clipboard as superuser" admin
  model. **Anti-port** per CLAUDE.md Hard Rule 3.
- **Fenced mod features** (reasonably bounded, worth keeping): **Joker Shell** — spawn a
  boundless, time-gated "ghost" that walks anywhere consequence-free, then optionally teleport
  to it (great for testing terrain/features and assisting stuck players; **not RCE**).
  **Location** — let a mod set their own world coordinates (**not RCE**).
_Full set classification (RCE vs fenced) is being reconned._


Q5: 1. is (b), yes. 2. certainly (c). existed in legacy. you can recon it further -Q4: 1. yes, your proposed dividing principle is right 2. friend data modernize in place. 3. yes, server-authoritative…


**TakABrak** (keyid 4):
An **easter-egg** key item ("Take-A-Break.exe"), not an ability-gating expansion. Lives in the
Key category but gates nothing.

**Mod Item** (Key-category IDs 900–909):
The legacy **admin / RCE item set** (`<M:Exc>`, `<M:NetExc>`, `<M:JkrShl>` = Joker Shell, …),
each wired to admin sub-commands. This is the original "run clipboard as superuser" admin model
— an **anti-port** per CLAUDE.md Hard Rule 3, NOT a collectable reward. Joker Shell (the fastest
"joker" movement tier) is an admin item, not parity content.

**TakABrak** (keyid 4):
An **easter-egg** key item ("Take-A-Break.exe"), not an ability-gating expansion. Gates nothing.
**Likely NOT ported** to ReBNO.

**Mod Item** (Key-category IDs 900–909):
A **mixed** admin item set — NOT uniformly RCE. Two sub-kinds:
- **RCE model** (`<M:Exc>`, `<M:NetExc>`, …) — the original "run clipboard as superuser" admin
  model. **Anti-port** per CLAUDE.md Hard Rule 3.
- **Fenced mod features** (reasonably bounded, worth keeping): **Joker Shell** — spawn a
  boundless, time-gated "ghost" that walks anywhere consequence-free, then optionally teleport
  to it (great for testing terrain/features and assisting stuck players; **not RCE**).
  **Location** — let a mod set their own world coordinates (**not RCE**).
_Full set classification (RCE vs fenced) is being reconned._

- **WrpPlugn** (6) — enables **Warp** tiles.

-An **easter-egg** key item ("Take-A-Break.exe"), not an ability-gating expansion. Lives in the

+An **easter-egg** key item ("Take-A-Break.exe"), not an ability-gating expansion. Gates nothing.

-The legacy **admin / RCE item set** (`<M:Exc>`, `<M:NetExc>`, `<M:JkrShl>` = Joker Shell, …),

-each wired to admin sub-commands. This is the original "run clipboard as superuser" admin model

-— an **anti-port** per CLAUDE.md Hard Rule 3, NOT a collectable reward. Joker Shell (the fastest

-"joker" movement tier) is an admin item, not parity content.

+A **mixed** admin item set — NOT uniformly RCE. Two sub-kinds:

+- **RCE model** (`<M:Exc>`, `<M:NetExc>`, …) — the original "run clipboard as superuser" admin

+  model. **Anti-port** per CLAUDE.md Hard Rule 3.

+- **Fenced mod features** (reasonably bounded, worth keeping): **Joker Shell** — spawn a

+  boundless, time-gated "ghost" that walks anywhere consequence-free, then optionally teleport

+  to it (great for testing terrain/features and assisting stuck players; **not RCE**).

+  **Location** — let a mod set their own world coordinates (**not RCE**).

+_Full set classification (RCE vs fenced) is being reconned._

A gatherable reward, surfaced in-universe as **Data** drops. Known taxonomy:


**Visibility rule** _(stated intent — not found in legacy 5-8 build)_:
A Navi standing on **Hidden** tiles is invisible to any Navi that does not share the same
**contiguous hidden-tile body**. A Navi on otherwise-unavailable geometry (e.g. an unactivated
hexbridge) is seen "floating" by others — seeing them means you *could potentially* reach that
geometry, not that it is unlocked for you.
_Recon found NO contiguous-body visibility-cull code in `client-5-8` (hidden tiles are just
cloaked floor + a self-reveal `alphaon` toggle). See Flagged ambiguities._

**Visibility rule** _(ReBNO design intention — NEW, not legacy)_:
A Navi standing on **Hidden** tiles is invisible to any Navi that does not share the same
**contiguous hidden-tile body**. A Navi on otherwise-unavailable geometry (e.g. an unactivated
hexbridge) is seen "floating" by others — seeing them means you *could potentially* reach that
geometry, not that it is unlocked for you.
_Confirmed a **ReBNO addition**, not legacy: `client-5-8` has no contiguous-body cull (hidden
tiles are cloaked floor + self-reveal only). Legacy's client-relay couldn't enforce per-player
peer-visibility; ReBNO's authoritative server can (interest management). A blessed new system._


**Visibility rule** _(stated intent — not found in legacy 5-8 build)_:
A Navi standing on **Hidden** tiles is invisible to any Navi that does not share the same
**contiguous hidden-tile body**. A Navi on otherwise-unavailable geometry (e.g. an unactivated
hexbridge) is seen "floating" by others — seeing them means you *could potentially* reach that
geometry, not that it is unlocked for you.
_Recon found NO contiguous-body visibility-cull code in `client-5-8` (hidden tiles are just
cloaked floor + a self-reveal `alphaon` toggle). See Flagged ambiguities._

**Visibility rule** _(ReBNO design intention — NEW, not legacy)_:
A Navi standing on **Hidden** tiles is invisible to any Navi that does not share the same
**contiguous hidden-tile body**. A Navi on otherwise-unavailable geometry (e.g. an unactivated
hexbridge) is seen "floating" by others — seeing them means you *could potentially* reach that
geometry, not that it is unlocked for you.
_Confirmed a **ReBNO addition**, not legacy: `client-5-8` has no contiguous-body cull (hidden
tiles are cloaked floor + self-reveal only). Legacy's client-relay couldn't enforce per-player
peer-visibility; ReBNO's authoritative server can (interest management). A blessed new system._

**Hidden** tile reveals, and all **Key Item** / **Collectable**-gated access (warp/zone/area/

spectrum). Two players in the same room can stand on different walkable surfaces.

-**Visibility rule** _(stated intent — not found in legacy 5-8 build)_:

+**Visibility rule** _(ReBNO design intention — NEW, not legacy)_:

-_Recon found NO contiguous-body visibility-cull code in `client-5-8` (hidden tiles are just

-cloaked floor + a self-reveal `alphaon` toggle). See Flagged ambiguities._

+_Confirmed a **ReBNO addition**, not legacy: `client-5-8` has no contiguous-body cull (hidden

+tiles are cloaked floor + self-reveal only). Legacy's client-relay couldn't enforce per-player

+peer-visibility; ReBNO's authoritative server can (interest management). A blessed new system._

A connected group of Hidden floor tiles forming one visibility group. Navis on the same body


empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi.
**Hexbridge** tiles bounce it back after spawning a floor tile that is recorded **permanently
per-account** (bridge id = `x + room + y`), synced to the server and replayed at every login —
so cleared hexbridges persist forever, per player. (Note: the "hexsling prefers the direction
you were *not* travelling" behavior is **stated intent not found in the 5-8 build** — recon
located that reversal only on the hexbridge bounce. See Flagged ambiguities.)

empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi — when a
sling has only 1–2 exits it prefers the direction the Navi was *not* travelling (confirmed
legacy behavior; recon re-checking `source-archive/` for the exact rule). **Hexbridge** tiles
bounce it back after spawning a floor tile that is recorded **permanently per-account** (bridge
id = `x + room + y`), synced to the server and replayed at every login — so cleared hexbridges
persist forever, per player.


empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi.
**Hexbridge** tiles bounce it back after spawning a floor tile that is recorded **permanently
per-account** (bridge id = `x + room + y`), synced to the server and replayed at every login —
so cleared hexbridges persist forever, per player. (Note: the "hexsling prefers the direction
you were *not* travelling" behavior is **stated intent not found in the 5-8 build** — recon
located that reversal only on the hexbridge bounce. See Flagged ambiguities.)

empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi — when a
sling has only 1–2 exits it prefers the direction the Navi was *not* travelling (confirmed
legacy behavior; recon re-checking `source-archive/` for the exact rule). **Hexbridge** tiles
bounce it back after spawning a floor tile that is recorded **permanently per-account** (bridge
id = `x + room + y`), synced to the server and replayed at every login — so cleared hexbridges
persist forever, per player.

The signature in-zone traversal mechanic. A **Hexporter** floor terminal splits the Navi into

six light orbs that re-form into a flat hexagon of light, travelling in a straight line across

-empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi.

-**Hexbridge** tiles bounce it back after spawning a floor tile that is recorded **permanently

-per-account** (bridge id = `x + room + y`), synced to the server and replayed at every login —

-so cleared hexbridges persist forever, per player. (Note: the "hexsling prefers the direction

-you were *not* travelling" behavior is **stated intent not found in the 5-8 build** — recon

-located that reversal only on the hexbridge bounce. See Flagged ambiguities.)

+empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi — when a

+sling has only 1–2 exits it prefers the direction the Navi was *not* travelling (confirmed

+legacy behavior; recon re-checking `source-archive/` for the exact rule). **Hexbridge** tiles

+bounce it back after spawning a floor tile that is recorded **permanently per-account** (bridge

+id = `x + room + y`), synced to the server and replayed at every login — so cleared hexbridges

Intra-zone teleportation via Warp tiles. Inert without the expansion.


**Watch** (the **Watcher** system):
A social/observation mechanic to watch (spectate/follow) another Navi. _Mechanics TBD — newly
surfaced; needs grilling._

**Watch** (the **Watcher** system):
A social/observation mechanic to watch another Navi — **a more limited form of the Duo system**,
and **not gated by any Navi Expansion** (unlike Duo's `DuoPlugn`). _Exact mechanics being
reconned._


**Watch** (the **Watcher** system):
A social/observation mechanic to watch (spectate/follow) another Navi. _Mechanics TBD — newly
surfaced; needs grilling._

**Watch** (the **Watcher** system):
A social/observation mechanic to watch another Navi — **a more limited form of the Duo system**,
and **not gated by any Navi Expansion** (unlike Duo's `DuoPlugn`). _Exact mechanics being
reconned._

-A social/observation mechanic to watch (spectate/follow) another Navi. _Mechanics TBD — newly

+A social/observation mechanic to watch another Navi — **a more limited form of the Duo system**,

+and **not gated by any Navi Expansion** (unlike Duo's `DuoPlugn`). _Exact mechanics being

The unified legacy mechanism (`rq_*`, 11 request types) behind player-to-player interactions —


## Flagged ambiguities

- **"Friends list"** — legacy **Friend Data** (inventory category 2, a genuine in-universe
  friends list) vs a *modern* account-level friends list proposed in
  `.planning/research/FEATURES.md`. Recon confirms legacy already had an in-universe list, so the
  real question is modernize-in-place vs faithful + separate layer. **Unresolved (Q4).**
- **Hidden-tile contiguous-body visibility** — user states Navis on hidden tiles are invisible to
  others not on the same contiguous hidden body. Recon found **no such cull in `client-5-8`**
  (hidden tiles are cloaked floor + self-reveal only). Is this in another revision, a ReBNO
  design intention, or missed by recon? **Unresolved.**
- **Hexsling direction-preference** — user states a hexsling with 1–2 exits "prefers the
  direction the player wasn't travelling." Recon found that reversal only on the **hexbridge**
  bounce, not on hexslings, in `client-5-8`. Same three possibilities. **Unresolved.**
- **`dabypass` meaning** — one recon pass read it as "exempt from the Abyss," another as "stuck
  respawning in the Abyss until you climb out." Direct conflict. **Needs a code re-check.**
- **Legacy is fully client-authoritative** — the Master only relays. ReBNO is server-authoritative
  (CLAUDE.md Hard Rule 1). Recorded here as the defining legacy→ReBNO divergence, not an
  ambiguity per se. **Confirm scope in Q4.3.**

## Scope principle (parity vs new system)

The dividing test for "what's making it into ReBNO" (confirmed):

> A change is in-scope **QoL** if it preserves the legacy mechanic's *inputs, gating, and
> outcomes* and only improves presentation, ergonomics, feedback, or accessibility. It is an
> out-of-scope **new system** if it adds a player capability, changes progression gating, or
> changes what is collectable/unlockable.

Worked adjudications: portal/Link-Data fast-travel UX overhaul = **QoL, in**; controller-first +
multiplatform delivery (desktop/Android/iOS/handheld/Discord Activity/VR overlay) = **QoL, in**;
cross-zone hexporters = **in** (trivial under ReBNO's chunked overworld); server-authoritative
rules/inventory = **in** (security-mandated divergence); IP-shed + battle system = **far-future,
out**. The hidden-tile contiguous-body **Visibility rule** is a deliberately **blessed new
system** (an explicit exception to the principle).

## Mandated divergences (faithful-port is rejected on purpose)

- **Server authority** — legacy is fully client-authoritative (the Master only relays;
  `server_receive.gml` stores `p_*` + rebroadcasts). ReBNO is **server-authoritative** across all
  rules + inventory (CLAUDE.md Hard Rule 1). _Confirmed in-scope now._
- **Plaintext passwords** → argon2id (Hard Rule 2). **RCE admin** (`<M:Exc>` mod items) → vetted
  admin surface (Hard Rule 3). Note: not *all* Mod Items are RCE — see **Mod Item**.

## Flagged ambiguities

- ✅ **Friend Data** — RESOLVED: **modernize in place.** Keep Friend Data as the system; present
  it more simply/usably. No separate parallel account-level friends list.
- ✅ **Hidden-tile contiguous-body visibility** — RESOLVED: a **ReBNO design intention (new)**,
  not legacy. See **Visibility rule**.
- 🔍 **Hexsling direction-preference** — confirmed **real legacy behavior**; recon re-checking
  `source-archive/` for the exact selection rule.
- 🔍 **`dabypass` meaning** — recon passes disagree ("exempt from Abyss" vs "stuck in Abyss until
  you climb out"). Code re-check queued.


## Flagged ambiguities

- **"Friends list"** — legacy **Friend Data** (inventory category 2, a genuine in-universe
  friends list) vs a *modern* account-level friends list proposed in
  `.planning/research/FEATURES.md`. Recon confirms legacy already had an in-universe list, so the
  real question is modernize-in-place vs faithful + separate layer. **Unresolved (Q4).**
- **Hidden-tile contiguous-body visibility** — user states Navis on hidden tiles are invisible to
  others not on the same contiguous hidden body. Recon found **no such cull in `client-5-8`**
  (hidden tiles are cloaked floor + self-reveal only). Is this in another revision, a ReBNO
  design intention, or missed by recon? **Unresolved.**
- **Hexsling direction-preference** — user states a hexsling with 1–2 exits "prefers the
  direction the player wasn't travelling." Recon found that reversal only on the **hexbridge**
  bounce, not on hexslings, in `client-5-8`. Same three possibilities. **Unresolved.**
- **`dabypass` meaning** — one recon pass read it as "exempt from the Abyss," another as "stuck
  respawning in the Abyss until you climb out." Direct conflict. **Needs a code re-check.**
- **Legacy is fully client-authoritative** — the Master only relays. ReBNO is server-authoritative
  (CLAUDE.md Hard Rule 1). Recorded here as the defining legacy→ReBNO divergence, not an
  ambiguity per se. **Confirm scope in Q4.3.**

## Scope principle (parity vs new system)

The dividing test for "what's making it into ReBNO" (confirmed):

> A change is in-scope **QoL** if it preserves the legacy mechanic's *inputs, gating, and
> outcomes* and only improves presentation, ergonomics, feedback, or accessibility. It is an
> out-of-scope **new system** if it adds a player capability, changes progression gating, or
> changes what is collectable/unlockable.

Worked adjudications: portal/Link-Data fast-travel UX overhaul = **QoL, in**; controller-first +
multiplatform delivery (desktop/Android/iOS/handheld/Discord Activity/VR overlay) = **QoL, in**;
cross-zone hexporters = **in** (trivial under ReBNO's chunked overworld); server-authoritative
rules/inventory = **in** (security-mandated divergence); IP-shed + battle system = **far-future,
out**. The hidden-tile contiguous-body **Visibility rule** is a deliberately **blessed new
system** (an explicit exception to the principle).

## Mandated divergences (faithful-port is rejected on purpose)

- **Server authority** — legacy is fully client-authoritative (the Master only relays;
  `server_receive.gml` stores `p_*` + rebroadcasts). ReBNO is **server-authoritative** across all
  rules + inventory (CLAUDE.md Hard Rule 1). _Confirmed in-scope now._
- **Plaintext passwords** → argon2id (Hard Rule 2). **RCE admin** (`<M:Exc>` mod items) → vetted
  admin surface (Hard Rule 3). Note: not *all* Mod Items are RCE — see **Mod Item**.

## Flagged ambiguities

- ✅ **Friend Data** — RESOLVED: **modernize in place.** Keep Friend Data as the system; present
  it more simply/usably. No separate parallel account-level friends list.
- ✅ **Hidden-tile contiguous-body visibility** — RESOLVED: a **ReBNO design intention (new)**,
  not legacy. See **Visibility rule**.
- 🔍 **Hexsling direction-preference** — confirmed **real legacy behavior**; recon re-checking
  `source-archive/` for the exact selection rule.
- 🔍 **`dabypass` meaning** — recon passes disagree ("exempt from Abyss" vs "stuck in Abyss until
  you climb out"). Code re-check queued.

The legacy in-universe friends list (collected as Data). _Flagged: see ambiguities._

+## Scope principle (parity vs new system)

+The dividing test for "what's making it into ReBNO" (confirmed):

+> A change is in-scope **QoL** if it preserves the legacy mechanic's *inputs, gating, and

+> outcomes* and only improves presentation, ergonomics, feedback, or accessibility. It is an

+> out-of-scope **new system** if it adds a player capability, changes progression gating, or

+> changes what is collectable/unlockable.

+Worked adjudications: portal/Link-Data fast-travel UX overhaul = **QoL, in**; controller-first +

+multiplatform delivery (desktop/Android/iOS/handheld/Discord Activity/VR overlay) = **QoL, in**;

+cross-zone hexporters = **in** (trivial under ReBNO's chunked overworld); server-authoritative

+rules/inventory = **in** (security-mandated divergence); IP-shed + battle system = **far-future,

+out**. The hidden-tile contiguous-body **Visibility rule** is a deliberately **blessed new

+system** (an explicit exception to the principle).

+## Mandated divergences (faithful-port is rejected on purpose)

+- **Server authority** — legacy is fully client-authoritative (the Master only relays;

+  `server_receive.gml` stores `p_*` + rebroadcasts). ReBNO is **server-authoritative** across all

+  rules + inventory (CLAUDE.md Hard Rule 1). _Confirmed in-scope now._

+- **Plaintext passwords** → argon2id (Hard Rule 2). **RCE admin** (`<M:Exc>` mod items) → vetted

+  admin surface (Hard Rule 3). Note: not *all* Mod Items are RCE — see **Mod Item**.

-- **"Friends list"** — legacy **Friend Data** (inventory category 2, a genuine in-universe

-  friends list) vs a *modern* account-level friends list proposed in

-  `.planning/research/FEATURES.md`. Recon confirms legacy already had an in-universe list, so the

-  real question is modernize-in-place vs faithful + separate layer. **Unresolved (Q4).**

-- **Hidden-tile contiguous-body visibility** — user states Navis on hidden tiles are invisible to

-  others not on the same contiguous hidden body. Recon found **no such cull in `client-5-8`**

-  (hidden tiles are cloaked floor + self-reveal only). Is this in another revision, a ReBNO

-  design intention, or missed by recon? **Unresolved.**

-- **Hexsling direction-preference** — user states a hexsling with 1–2 exits "prefers the

-  direction the player wasn't travelling." Recon found that reversal only on the **hexbridge**

-  bounce, not on hexslings, in `client-5-8`. Same three possibilities. **Unresolved.**

-- **`dabypass` meaning** — one recon pass read it as "exempt from the Abyss," another as "stuck

-  respawning in the Abyss until you climb out." Direct conflict. **Needs a code re-check.**

-- **Legacy is fully client-authoritative** — the Master only relays. ReBNO is server-authoritative

-  (CLAUDE.md Hard Rule 1). Recorded here as the defining legacy→ReBNO divergence, not an

-  ambiguity per se. **Confirm scope in Q4.3.**

+- ✅ **Friend Data** — RESOLVED: **modernize in place.** Keep Friend Data as the system; present

+  it more simply/usably. No separate parallel account-level friends list.

+- ✅ **Hidden-tile contiguous-body visibility** — RESOLVED: a **ReBNO design intention (new)**,

+- 🔍 **Hexsling direction-preference** — confirmed **real legacy behavior**; recon re-checking

+  `source-archive/` for the exact selection rule.

+- 🔍 **`dabypass` meaning** — recon passes disagree ("exempt from Abyss" vs "stuck in Abyss until

+  you climb out"). Code re-check queued.


Glossary is now comprehensive and the scope principle + mandated divergences are recorded. Adopting your directive: **recon before grill** from here on. Launching legacy recon for the open re-checks + the next subjects (social + cooperative), running in background.


Agent

Recon: mod item classification

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online" (legacy multiplayer game). GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, `master-5-4`). Plain-text GML — read, don't hex-inspect.

MISSION: Fully classify the legacy MOD / ADMIN item set so we can separate true RCE (anti-port) from reasonably-fenced mod features (potentially worth keeping in the rebuild).

Context: Key-category inventory items with IDs 900–909 are admin/mod items (tokens like `<M:Exc>`, `<M:NetExc>`, `<M:JkrShl>`, …), each wired to a network message (msgid 20 sub-commands). Known so far:
- Joker Shell (JkrShl) = spawn a boundless, time-gated invulnerable "ghost" that walks anywhere consequence-free, then optionally teleport to it. NOT RCE — a fenced testing/assist tool.
- "Location" item = let a mod set their own world coordinates. NOT RCE.
- Exc / NetExc = code/clipboard execution. RCE.

DO: Find the full registry of these 900–909 items (look in the same `global.keydata` table and the msgid-20 / admin command handler, e.g. server_receive case 20 and any `Ctrl`-key admin input handlers). For EACH item: name/token, ID, what it actually does (read the handler code), and classify as **RCE** (arbitrary code / clipboard exec / unbounded) vs **FENCED FEATURE** (bounded, specific capability) vs **UNCLEAR**. Cross-reference any `,ServerCommands.txt` / `Ctrl+O Codes.txt` style files if present under extracted/ or legacy/.

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\04-mod-items.md` — a table `ID | token | name | what it does | RCE/FENCED/UNCLEAR | evidence(file:line)`, plus a "Recommended for ReBNO admin surface" shortlist (the fenced ones) and an "Anti-port (RCE)" list. Return a ~10-line summary. Evidence-based; flag guesses.


<owl_reachability_notice>
You have an active owl perch. Launch this Agent with run_in_background: true so you stay reachable for incoming messages while it works.
</owl_reachability_notice>


Async agent launched successfully.
agentId: abe65fa3be056529d (internal ID - do not mention to user. Use SendMessage with to: 'abe65fa3be056529d' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\abe65fa3be056529d.output
Do NOT Read or tail this file via the shell tool — it is the full subagent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

Recon: mod item classification

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online" (legacy multiplayer game). GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, `master-5-4`). Plain-text GML — read, don't hex-inspect.

MISSION: Fully classify the legacy MOD / ADMIN item set so we can separate true RCE (anti-port) from reasonably-fenced mod features (potentially worth keeping in the rebuild).

Context: Key-category inventory items with IDs 900–909 are admin/mod items (tokens like `<M:Exc>`, `<M:NetExc>`, `<M:JkrShl>`, …), each wired to a network message (msgid 20 sub-commands). Known so far:
- Joker Shell (JkrShl) = spawn a boundless, time-gated invulnerable "ghost" that walks anywhere consequence-free, then optionally teleport to it. NOT RCE — a fenced testing/assist tool.
- "Location" item = let a mod set their own world coordinates. NOT RCE.
- Exc / NetExc = code/clipboard execution. RCE.

DO: Find the full registry of these 900–909 items (look in the same `global.keydata` table and the msgid-20 / admin command handler, e.g. server_receive case 20 and any `Ctrl`-key admin input handlers). For EACH item: name/token, ID, what it actually does (read the handler code), and classify as **RCE** (arbitrary code / clipboard exec / unbounded) vs **FENCED FEATURE** (bounded, specific capability) vs **UNCLEAR**. Cross-reference any `,ServerCommands.txt` / `Ctrl+O Codes.txt` style files if present under extracted/ or legacy/.

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\04-mod-items.md` — a table `ID | token | name | what it does | RCE/FENCED/UNCLEAR | evidence(file:line)`, plus a "Recommended for ReBNO admin surface" shortlist (the fenced ones) and an "Anti-port (RCE)" list. Return a ~10-line summary. Evidence-based; flag guesses.


Recon: hexsling + dabypass recheck

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online". GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, `master-5-4`). ALSO search older revisions under `C:\Users\decid\Documents\projects\rebno\legacy\source-archive\` and `C:\Users\decid\Documents\projects\rebno\legacy\servers\` if they contain extractable GML or readable project text. Plain-text only — don't hex-inspect binaries.

MISSION: Settle two specific open questions a prior recon pass couldn't resolve.

1. HEXSLING SELECTION RULE. A hexsling tile redirects a hexporting Navi. The user states: when a hexsling has only 1–2 enabled exit directions, it "prefers the direction the player was NOT travelling"; with 3–4 it pauses for directional input. A prior pass found a direction-reversal only on the HEXBRIDGE bounce, not on hexslings, in client-5-8. Re-examine the hexsling objects (`hexsling_any`, `hexport_rc`, `hexporterparent`, anything `hexsl*`) and the orb/hexagon motion code. Find where a hexsling chooses the outgoing direction. Quote the exact selection logic. If it's absent in 5-8, check source-archive revisions and report which revision (if any) has it.

2. `dabypass` SEMANTICS. Two prior passes conflicted: one said `global.dabypass` EXEMPTS a user from the Digital Abyss; the other said it makes them STICK in the Abyss (respawn there each login until they climb out). Read every site that sets or reads `dabypass` (client Step/fall code AND server-side persistence), plus the related `dafalls` counter. Determine definitively: is it an exemption flag or a "trapped" flag? Quote the deciding code.

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\05-hexsling-dabypass.md` with two sections, each with a definitive answer + code citations (file:line + excerpt) + which build/revision the evidence came from. Return a ~8-line summary. If still unresolved, say exactly what's missing.


<owl_messages>
<owl_message from="ling-w4" priority="info">[WORKING_PERCH_NOTICE] Subagent working perch created.
Perch: ling-w4
Agent type: general-purpose
To message it: $OWL send ling-w4 ling</owl_message>
</owl_messages>

[OWL SYSTEM] Informational owl messages above — no acknowledgment needed. Continue your current task.

<owl_reachability_notice>
You have an active owl perch. Launch this Agent with run_in_background: true so you stay reachable for incoming messages while it works.
</owl_reachability_notice>


Async agent launched successfully.
agentId: aced530e81a8363ff (internal ID - do not mention to user. Use SendMessage with to: 'aced530e81a8363ff' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\aced530e81a8363ff.output
Do NOT Read or tail this file via the shell tool — it is the full subagent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

Recon: hexsling + dabypass recheck

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online". GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, `master-5-4`). ALSO search older revisions under `C:\Users\decid\Documents\projects\rebno\legacy\source-archive\` and `C:\Users\decid\Documents\projects\rebno\legacy\servers\` if they contain extractable GML or readable project text. Plain-text only — don't hex-inspect binaries.

MISSION: Settle two specific open questions a prior recon pass couldn't resolve.

1. HEXSLING SELECTION RULE. A hexsling tile redirects a hexporting Navi. The user states: when a hexsling has only 1–2 enabled exit directions, it "prefers the direction the player was NOT travelling"; with 3–4 it pauses for directional input. A prior pass found a direction-reversal only on the HEXBRIDGE bounce, not on hexslings, in client-5-8. Re-examine the hexsling objects (`hexsling_any`, `hexport_rc`, `hexporterparent`, anything `hexsl*`) and the orb/hexagon motion code. Find where a hexsling chooses the outgoing direction. Quote the exact selection logic. If it's absent in 5-8, check source-archive revisions and report which revision (if any) has it.

2. `dabypass` SEMANTICS. Two prior passes conflicted: one said `global.dabypass` EXEMPTS a user from the Digital Abyss; the other said it makes them STICK in the Abyss (respawn there each login until they climb out). Read every site that sets or reads `dabypass` (client Step/fall code AND server-side persistence), plus the related `dafalls` counter. Determine definitively: is it an exemption flag or a "trapped" flag? Quote the deciding code.

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\05-hexsling-dabypass.md` with two sections, each with a definitive answer + code citations (file:line + excerpt) + which build/revision the evidence came from. Return a ~8-line summary. If still unresolved, say exactly what's missing.


Two recon agents launched (mod-item classification, hexsling/dabypass). Launching the other two — Watch+request system, and the social layer (boards/chat) to arm the next grill round.


Recon: watch and request system

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online" (social-exploration multiplayer game). GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, `master-5-4`). Plain-text — don't hex-inspect.

MISSION: Map the player-to-player REQUEST system and the WATCH system in full.

Context: there is a unified request system (`rq_*` scripts; `rq_new.gml` header enumerates ~11 request types, indices 0–10). Known: Summon, Join, and Duo spot/dig (requests 7–10) live here; duo partners auto-accept. There is also a Watch system (`watcher` object, `global.watchpid` / `global.watching`, network msgid 22 sub-command 2) described as "a more limited form of Duo," NOT gated by any Navi Expansion.

DO:
1. Enumerate ALL request types 0–10 from `rq_new.gml` and related `rq_*` scripts — index → name → what it does → accept/reject flow. Note which auto-accept and which need consent.
2. Fully explain the WATCH system: how you start/stop watching, what the watcher experiences (camera follow? see-through-their-eyes? see their hidden tiles?), whether it's one-way or mutual, and how it differs from Duo. Read the `watcher` object events and the msgid-22 handler on both client and server.
3. Explain the DUO system mechanics in detail (formation via request, the mutual benefits, the shared-visibility rule, the "tethered — can't free-teleport" constraint, dissolution).
4. Note client-vs-server responsibilities for each.

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\06-watch-requests.md` — the request-type table + Watch deep-dive + Duo deep-dive, all with file:line evidence. Return a ~10-line summary highlighting how Watch differs from Duo and anything surprising. Evidence-based; flag guesses.


<owl_messages>
<owl_message from="ling-w5" priority="info">[WORKING_PERCH_NOTICE] Subagent working perch created.
Perch: ling-w5
Agent type: general-purpose
To message it: $OWL send ling-w5 ling</owl_message>
</owl_messages>

[OWL SYSTEM] Informational owl messages above — no acknowledgment needed. Continue your current task.

<owl_reachability_notice>
You have an active owl perch. Launch this Agent with run_in_background: true so you stay reachable for incoming messages while it works.
</owl_reachability_notice>


Async agent launched successfully.
agentId: a82406210c5625ee0 (internal ID - do not mention to user. Use SendMessage with to: 'a82406210c5625ee0' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\a82406210c5625ee0.output
Do NOT Read or tail this file via the shell tool — it is the full subagent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

Recon: watch and request system

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online" (social-exploration multiplayer game). GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, `master-5-4`). Plain-text — don't hex-inspect.

MISSION: Map the player-to-player REQUEST system and the WATCH system in full.

Context: there is a unified request system (`rq_*` scripts; `rq_new.gml` header enumerates ~11 request types, indices 0–10). Known: Summon, Join, and Duo spot/dig (requests 7–10) live here; duo partners auto-accept. There is also a Watch system (`watcher` object, `global.watchpid` / `global.watching`, network msgid 22 sub-command 2) described as "a more limited form of Duo," NOT gated by any Navi Expansion.

DO:
1. Enumerate ALL request types 0–10 from `rq_new.gml` and related `rq_*` scripts — index → name → what it does → accept/reject flow. Note which auto-accept and which need consent.
2. Fully explain the WATCH system: how you start/stop watching, what the watcher experiences (camera follow? see-through-their-eyes? see their hidden tiles?), whether it's one-way or mutual, and how it differs from Duo. Read the `watcher` object events and the msgid-22 handler on both client and server.
3. Explain the DUO system mechanics in detail (formation via request, the mutual benefits, the shared-visibility rule, the "tethered — can't free-teleport" constraint, dissolution).
4. Note client-vs-server responsibilities for each.

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\06-watch-requests.md` — the request-type table + Watch deep-dive + Duo deep-dive, all with file:line evidence. Return a ~10-line summary highlighting how Watch differs from Duo and anything surprising. Evidence-based; flag guesses.


Recon: social board and chat

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online" (social-exploration multiplayer game). GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, `master-5-4`). Plain-text — don't hex-inspect.

MISSION: Document the SOCIAL layer — message boards, chat, and the Friend Data system.

DO:
1. MESSAGE BOARDS: structure is `mbparent` + ~24 per-zone `*_mb` objects each with an `mbid`; server persistence via `mb_backup` and per-user `unews_*` scripts; `ac_news` marks a "News Center" area. Explain: how a player reads a board, how/whether they post, what's stored per board vs per user, how persistence works, and what the `unews_*` ("user news"?) per-user scripts do. Are boards global (one shared wall) or per-user, or a mix?
2. CHAT: find the chat system. How is a chat message sent and received (which msgid)? What's its scope — whole server, current zone/room, or proximity? Are there channels, commands (slash-commands?), whispers/DMs, emotes? Any rate limiting or filtering in legacy?
3. FRIEND DATA (inventory category 2): how is a friend added (a request type? a collectable drop `d_friend`?), what does holding Friend Data let you DO (see them online? locate them? summon/join them more easily?), and is presence/online-status tracked at all in legacy?

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\07-social-board-chat.md` — three sections (Boards / Chat / Friends) each with mechanics + file:line evidence + a "client vs server" note. Return a ~10-line summary highlighting how social/presence worked (or didn't) in legacy. Evidence-based; flag guesses.


<owl_messages>
<owl_message from="ling-w6" priority="info">[WORKING_PERCH_NOTICE] Subagent working perch created.
Perch: ling-w6
Agent type: general-purpose
To message it: $OWL send ling-w6 ling</owl_message>
</owl_messages>

[OWL SYSTEM] Informational owl messages above — no acknowledgment needed. Continue your current task.

<owl_reachability_notice>
You have an active owl perch. Launch this Agent with run_in_background: true so you stay reachable for incoming messages while it works.
</owl_reachability_notice>


Async agent launched successfully.
agentId: a75469a4daa4839b7 (internal ID - do not mention to user. Use SendMessage with to: 'a75469a4daa4839b7' to continue this agent.)
The agent is working in the background. You will be notified automatically when it completes.
Do not duplicate this agent's work — avoid working with the same files or topics it is using. Work on non-overlapping tasks, or briefly tell the user what you launched and end your response.
output_file: C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\a75469a4daa4839b7.output
Do NOT Read or tail this file via the shell tool — it is the full subagent JSONL transcript and reading it will overflow your context. If the user asks for progress, say the agent is still running; you'll get a completion notification.

Recon: social board and chat

Prompt:
Reverse-engineering extracted GameMaker 5.3a source of "BN Online" (social-exploration multiplayer game). GML under `C:\Users\decid\Documents\projects\rebno\extracted\` (`client-5-8`, `master-5-4`). Plain-text — don't hex-inspect.

MISSION: Document the SOCIAL layer — message boards, chat, and the Friend Data system.

DO:
1. MESSAGE BOARDS: structure is `mbparent` + ~24 per-zone `*_mb` objects each with an `mbid`; server persistence via `mb_backup` and per-user `unews_*` scripts; `ac_news` marks a "News Center" area. Explain: how a player reads a board, how/whether they post, what's stored per board vs per user, how persistence works, and what the `unews_*` ("user news"?) per-user scripts do. Are boards global (one shared wall) or per-user, or a mix?
2. CHAT: find the chat system. How is a chat message sent and received (which msgid)? What's its scope — whole server, current zone/room, or proximity? Are there channels, commands (slash-commands?), whispers/DMs, emotes? Any rate limiting or filtering in legacy?
3. FRIEND DATA (inventory category 2): how is a friend added (a request type? a collectable drop `d_friend`?), what does holding Friend Data let you DO (see them online? locate them? summon/join them more easily?), and is presence/online-status tracked at all in legacy?

OUTPUT: Write `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\07-social-board-chat.md` — three sections (Boards / Chat / Friends) each with mechanics + file:line evidence + a "client vs server" note. Return a ~10-line summary highlighting how social/presence worked (or didn't) in legacy. Evidence-based; flag guesses.


4 recon agents running in background:
- **Mod-item classification** (RCE vs fenced — your Joker Shell / Location point)
- **Hexsling + `dabypass` re-check** (incl. `source-archive/`)
- **Watch + full request system** (11 `rq_*` types, Watch-vs-Duo)
- **Social layer** (message boards, chat, Friend Data presence)

When they land I'll fold results into `CONTEXT.md` and **then grill** the cooperative + social systems (Watch, Duo, boards, chat, friends) — armed, per your new workflow. Standing by for completions.


<task-notification>
<task-id>abe65fa3be056529d</task-id>
<tool-use-id>toolu_015msCSN6UMruYmHkNjBYYqW</tool-use-id>
<output-file>C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\abe65fa3be056529d.output</output-file>
<status>completed</status>
<summary>Agent "Recon: mod item classification" completed</summary>
<result>Wrote `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\04-mod-items.md`.

Summary of the mod/admin item classification (all evidence-based, read from handler code):

**Client mod items 900–909** (registry `client-5-8/scripts/0347-iv_keyactions.gml`; network via msgid 20 in `server-5-4/scripts/0359-server_receive.gml:417-469`):
- **RCE (anti-port):** 900 `<M:Exc>` Executor (local clipboard exec), 901 `<M:Qury>` Query (local eval), 902 `<M:NetExc>` Net Executor (server exec), 903 `<M:NetQury>` Net Query (server eval), 904 `<M:NetTarg>` Net Target (victim selector for 905), 905 `<M:NetCon>` Net Controller (exec on another player's client).
- **FENCED:** 906 `<M:Loc>` Location (writes a coord bookmark to own inventory), 908 `<M:NetPop>` Net Populate (online-roster query — but rides the RCE transport), 909 `<M:JkrShl>` Joker Shell (time-gated 90-step invuln ghost-walk + teleport-to-ghost; `"UNLIM"` clipboard backdoor for unlimited — drop that).
- **UNCLEAR:** 907 `<M:MasMod>` Mass Moderation — registered item, inert always-on stub, **no consumer of a MasMod flag anywhere in either tree**. Flagged as a guess.

**Root RCE primitive:** client `case 12: execute_string(readstring())` (`client_receive.gml:174-176`) — every server→client msgid-12 packet is arbitrary client code. 903/905/908 all use it. Must have no rebuild equivalent.

**Server-app operator console** (separate surface; `server-5-4/objects/0000-server` + `0363-ucontrol` keypress handlers, cross-ref `legacy/open-source-release/,ServerCommands.txt`): Ctrl+E/Ctrl+Q = local exec (RCE); Ctrl+O (two variants) = send clipboard GML to a player's `operations` object to run (RCE), including `scontrolmenu()`'s "Force Log Out"; Ctrl+M/Ctrl+S/Ctrl+U = view board / spectate / un-spectate (FENCED). The `Ctrl+O Codes.txt` files are operators' personal `global.awesomefunction` GML macros — arbitrary code, anti-port (but their intents like store/restore-coords and self-hexport are fenced and worth keeping as buttons).

The doc includes a "Recommended for ReBNO admin surface" shortlist (Location, Joker Shell minus backdoor, roster, spectate, board view, self-hexport) and an "Anti-port (RCE)" list, plus a tagged `[doc->REQ-SRV-04]`.

Note: server dir is `server-5-4` (not `master-5-4`); no `ServerCommands.txt`/`Ctrl+O Codes.txt` under `extracted/` — they live only under `legacy/`.</result>
<usage><subagent_tokens>74192</subagent_tokens><tool_uses>38</tool_uses><duration_ms>195268</duration_ms></usage>
</task-notification>


<owl_messages>
<owl_message from="ling-w7" priority="info">[WORKING_PERCH_NOTICE] Subagent working perch created.
Perch: ling-w7
Agent type: general-purpose
To message it: $OWL send ling-w7 ling</owl_message>
</owl_messages>

[OWL SYSTEM] Informational owl messages above — no acknowledgment needed. Continue your current task.

<owl_reachability_notice>
You have an active owl perch. When spawning subagents or doing work, use run_in_background: true so you stay reachable for incoming messages.
</owl_reachability_notice>


<task-notification>
<task-id>aced530e81a8363ff</task-id>
<tool-use-id>toolu_01G6jE9VpTZUWkwai6F3tFBg</tool-use-id>
<output-file>C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\aced530e81a8363ff.output</output-file>
<status>completed</status>
<summary>Agent "Recon: hexsling + dabypass recheck" completed</summary>
<result>Both questions settled. Report written to `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\05-hexsling-dabypass.md`.

**1. HEXSLING SELECTION RULE (build: client-5-8)** — The user's "prefer NOT travelling / 1–2 vs 3–4" recollection does NOT exist in 5-8. The real rule lives on object `0417-hxstsideb` Collision-0: with `up+down+left+right <= 1` enabled exits it auto-picks the single direction; with `> 1` it halts (`keywait=1`) and waits for an arrow KeyPress (events 37/38/39/40). No direction-reversal anywhere on the sling. The "opposite of travel" reversal the user remembers is the HEXBRIDGE (`0445-hxbtsideb` Collision-0), a different object, and only when the bridge has zero arrows. Older revisions (5-01…5-3) are binary `.gmd` and cannot be checked without running extraction — if the recalled behavior ever existed, it's in an un-extracted pre-5-8 client.

**2. `dabypass` (builds: client-5-8 + server-5-4)** — Definitively a "trapped/sticky" flag, NOT an exemption. Server `server_receive.gml:72-73` sets `dabypass[uid]=1` when the player enters room 49 (Digital_Abyss) and clears it to 0 on any other room. It's persisted as the first field of the `.bnu` save (`uinv_backup`/`uinv_restore`), sent to the client at login (`:206` → `begin_client_receive.gml:65`), and the client `commandob` Create spawns the player IN `Digital_Abyss` when set (and blocks the home-spawn). So it forces respawn in the Abyss each login until they walk out. The `dafalls` counter is client-only/session-only (resets at 5); it's the accumulator that warps the client into room 49, which is what trips the server to set the persistent `dabypass`.

Both answers are fully resolved with code citations; nothing is missing except the un-extracted older client GML for the Q1 "did it ever exist" sub-question.</result>
<usage><subagent_tokens>58852</subagent_tokens><tool_uses>46</tool_uses><duration_ms>195642</duration_ms></usage>
</task-notification>


Mod-item recon done — full RCE-vs-fenced split. Folding into glossary.


Edit

**Mod Item** (Key-category IDs 900–909):
A **mixed** admin item set — NOT uniformly RCE. Two sub-kinds:
- **RCE model** (`<M:Exc>`, `<M:NetExc>`, …) — the original "run clipboard as superuser" admin
  model. **Anti-port** per CLAUDE.md Hard Rule 3.
- **Fenced mod features** (reasonably bounded, worth keeping): **Joker Shell** — spawn a
  boundless, time-gated "ghost" that walks anywhere consequence-free, then optionally teleport
  to it (great for testing terrain/features and assisting stuck players; **not RCE**).
  **Location** — let a mod set their own world coordinates (**not RCE**).
_Full set classification (RCE vs fenced) is being reconned._

**Mod Item** (Key-category IDs 900–909):
A **mixed** admin item set — NOT uniformly RCE (classified from handler code):
- **RCE — anti-port (Hard Rule 3):** 900 `Exc` (clipboard exec), 901 `Qury` (local eval), 902
  `NetExc` (server exec), 903 `NetQury` (server eval), 904 `NetTarg` + 905 `NetCon` (run code on
  another player's client).
- **Fenced features — candidate ReBNO admin surface:** 906 **Location** (coord bookmark), 908
  **NetPop** (online-roster query), 909 **Joker Shell** (90-step invulnerable ghost-walk +
  teleport-to-ghost; drop its `"UNLIM"` clipboard backdoor).
- **Unclear:** 907 `MasMod` (registered but inert — no consumer in either tree).

The legacy **server operator console** is a *separate* admin surface (server-app Ctrl-key
handlers, per `legacy/.../,ServerCommands.txt`): Ctrl+E/Q + Ctrl+O = exec (RCE, anti-port);
Ctrl+M/S/U = board-view / spectate / un-spectate (fenced).


**Mod Item** (Key-category IDs 900–909):
A **mixed** admin item set — NOT uniformly RCE. Two sub-kinds:
- **RCE model** (`<M:Exc>`, `<M:NetExc>`, …) — the original "run clipboard as superuser" admin
  model. **Anti-port** per CLAUDE.md Hard Rule 3.
- **Fenced mod features** (reasonably bounded, worth keeping): **Joker Shell** — spawn a
  boundless, time-gated "ghost" that walks anywhere consequence-free, then optionally teleport
  to it (great for testing terrain/features and assisting stuck players; **not RCE**).
  **Location** — let a mod set their own world coordinates (**not RCE**).
_Full set classification (RCE vs fenced) is being reconned._

**Mod Item** (Key-category IDs 900–909):
A **mixed** admin item set — NOT uniformly RCE (classified from handler code):
- **RCE — anti-port (Hard Rule 3):** 900 `Exc` (clipboard exec), 901 `Qury` (local eval), 902
  `NetExc` (server exec), 903 `NetQury` (server eval), 904 `NetTarg` + 905 `NetCon` (run code on
  another player's client).
- **Fenced features — candidate ReBNO admin surface:** 906 **Location** (coord bookmark), 908
  **NetPop** (online-roster query), 909 **Joker Shell** (90-step invulnerable ghost-walk +
  teleport-to-ghost; drop its `"UNLIM"` clipboard backdoor).
- **Unclear:** 907 `MasMod` (registered but inert — no consumer in either tree).

The legacy **server operator console** is a *separate* admin surface (server-app Ctrl-key
handlers, per `legacy/.../,ServerCommands.txt`): Ctrl+E/Q + Ctrl+O = exec (RCE, anti-port);
Ctrl+M/S/U = board-view / spectate / un-spectate (fenced).

-A **mixed** admin item set — NOT uniformly RCE. Two sub-kinds:

-- **RCE model** (`<M:Exc>`, `<M:NetExc>`, …) — the original "run clipboard as superuser" admin

-  model. **Anti-port** per CLAUDE.md Hard Rule 3.

-- **Fenced mod features** (reasonably bounded, worth keeping): **Joker Shell** — spawn a

-  boundless, time-gated "ghost" that walks anywhere consequence-free, then optionally teleport

-  to it (great for testing terrain/features and assisting stuck players; **not RCE**).

-  **Location** — let a mod set their own world coordinates (**not RCE**).

-_Full set classification (RCE vs fenced) is being reconned._

+A **mixed** admin item set — NOT uniformly RCE (classified from handler code):

+- **RCE — anti-port (Hard Rule 3):** 900 `Exc` (clipboard exec), 901 `Qury` (local eval), 902

+  `NetExc` (server exec), 903 `NetQury` (server eval), 904 `NetTarg` + 905 `NetCon` (run code on

+- **Fenced features — candidate ReBNO admin surface:** 906 **Location** (coord bookmark), 908

+  **NetPop** (online-roster query), 909 **Joker Shell** (90-step invulnerable ghost-walk +

+- **Unclear:** 907 `MasMod` (registered but inert — no consumer in either tree).

+The legacy **server operator console** is a *separate* admin surface (server-app Ctrl-key

+handlers, per `legacy/.../,ServerCommands.txt`): Ctrl+E/Q + Ctrl+O = exec (RCE, anti-port);

+Ctrl+M/S/U = board-view / spectate / un-spectate (fenced).

A gatherable reward, surfaced in-universe as **Data** drops. Known taxonomy:

- **Zone Link Data** (alias: Zone Data) — unlocks fast-travel to a Zone; sourced from that


Prompt:
<task-notification>
<task-id>aced530e81a8363ff</task-id>
<tool-use-id>toolu_01G6jE9VpTZUWkwai6F3tFBg</tool-use-id>
<output-file>C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\aced530e81a8363ff.output</output-file>
<status>completed</status>
<summary>Agent "Recon: hexsling + dabypass recheck" completed</summary>
<result>Both questions settled. Report written to `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\05-hexsling-dabypass.md`.

**1. HEXSLING SELECTION RULE (build: client-5-8)** — The user's "prefer NOT travelling / 1–2 vs 3–4" recollection does NOT exist in 5-8. The real rule lives on object `0417-hxstsideb` Collision-0: with `up+down+left+right <= 1` enabled exits it auto-picks the single direction; with `> 1` it halts (`keywait=1`) and waits for an arrow KeyPress (events 37/38/39/40). No direction-reversal anywhere on the sling. The "opposite of travel" reversal the user remembers is the HEXBRIDGE (`0445-hxbtsideb` Collision-0), a different object, and only when the bridge has zero arrows. Older revisions (5-01…5-3) are binary `.gmd` and cannot be checked without running extraction — if the recalled behavior ever existed, it's in an un-extracted pre-5-8 client.

**2. `dabypass` (builds: client-5-8 + server-5-4)** — Definitively a "trapped/sticky" flag, NOT an exemption. Server `server_receive.gml:72-73` sets `dabypass[uid]=1` when the player enters room 49 (Digital_Abyss) and clears it to 0 on any other room. It's persisted as the first field of the `.bnu` save (`uinv_backup`/`uinv_restore`), sent to the client at login (`:206` → `begin_client_receive.gml:65`), and the client `commandob` Create spawns the player IN `Digital_Abyss` when set (and blocks the home-spawn). So it forces respawn in the Abyss each login until they walk out. The `dafalls` counter is client-only/session-only (resets at 5); it's the accumulator that warps the client into room 49, which is what trips the server to set the persistent `dabypass`.

Both answers are fully resolved with code citations; nothing is missing except the un-extracted older client GML for the Q1 "did it ever exist" sub-question.</result>
<usage><subagent_tokens>58852</subagent_tokens><tool_uses>46</tool_uses><duration_ms>195642</duration_ms></usage>
</task-notification>


Hexsling + `dabypass` both settled — and the hexsling answer **contradicts both your memory and `LEGACY_FEATURE_REFERENCE.md`**:

- **`dabypass`** = definitively a **"trapped in the Abyss" sticky flag** (server sets it on Abyss entry, persisted in `.bnu`, respawns you there every login until you walk out). NOT an exemption. (Agent-3 was right, agent-1 wrong.)
- **Hexsling (5-8):** ≤1 enabled exit → auto-pick; >1 → halt + wait for arrow input. **No "prefer the direction you weren't going."** That reversal is the **hexbridge** zero-arrow bounce — a different object. Your recalled rule (and the one written in `LEGACY_FEATURE_REFERENCE.md`) isn't in 5-8; if it ever existed it's in a pre-5-8 client (older `.gmd` are still binary, unextracted).

Folding in:


**Digital Abyss** (legacy room: **Abyssal Ruin**, zone 4):
A fall-failure destination, and itself a **no-teleport zone** (you climb out on foot). Exact
legacy rule: each fall rolls ~10% (`random(99)`, abyss if `≤9`) **but only once `dafalls > 5`**
— your first 5 falls are immune; the counter resets each time you land in the Abyss. A persisted
per-user `dabypass` flag interacts with this (its exact meaning is **disputed between recon
passes** — see Flagged ambiguities).

**Digital Abyss** (legacy room: **Abyssal Ruin**, zone 4):
A fall-failure destination, and itself a **no-teleport zone** (you climb out on foot). Exact
legacy rule: each fall rolls ~10% (`random(99)`, abyss if `≤9`) **but only once `dafalls > 5`**
(`dafalls` is a client/session counter; your first 5 falls are immune). On Abyss entry the
server sets a **persisted, sticky `dabypass` flag** — you then **respawn in the Abyss on every
login until you physically walk out** (it blocks the Home Portal spawn). `dabypass` is a
"trapped" flag, NOT an exemption.


**Digital Abyss** (legacy room: **Abyssal Ruin**, zone 4):
A fall-failure destination, and itself a **no-teleport zone** (you climb out on foot). Exact
legacy rule: each fall rolls ~10% (`random(99)`, abyss if `≤9`) **but only once `dafalls > 5`**
— your first 5 falls are immune; the counter resets each time you land in the Abyss. A persisted
per-user `dabypass` flag interacts with this (its exact meaning is **disputed between recon
passes** — see Flagged ambiguities).

**Digital Abyss** (legacy room: **Abyssal Ruin**, zone 4):
A fall-failure destination, and itself a **no-teleport zone** (you climb out on foot). Exact
legacy rule: each fall rolls ~10% (`random(99)`, abyss if `≤9`) **but only once `dafalls > 5`**
(`dafalls` is a client/session counter; your first 5 falls are immune). On Abyss entry the
server sets a **persisted, sticky `dabypass` flag** — you then **respawn in the Abyss on every
login until you physically walk out** (it blocks the Home Portal spawn). `dabypass` is a
"trapped" flag, NOT an exemption.

-— your first 5 falls are immune; the counter resets each time you land in the Abyss. A persisted

-per-user `dabypass` flag interacts with this (its exact meaning is **disputed between recon

+(`dafalls` is a client/session counter; your first 5 falls are immune). On Abyss entry the

+server sets a **persisted, sticky `dabypass` flag** — you then **respawn in the Abyss on every

+login until you physically walk out** (it blocks the Home Portal spawn). `dabypass` is a

A hub/menu screen used as the default spawn when a player has set no Home Portal.


empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi — when a
sling has only 1–2 exits it prefers the direction the Navi was *not* travelling (confirmed
legacy behavior; recon re-checking `source-archive/` for the exact rule). **Hexbridge** tiles
bounce it back after spawning a floor tile that is recorded **permanently per-account** (bridge
id = `x + room + y`), synced to the server and replayed at every login — so cleared hexbridges
persist forever, per player.

empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi: in the
5-8 build, ≤1 enabled exit auto-picks that direction; >1 exits halts the orb and waits for an
arrow-key choice. (No "prefer the direction you weren't travelling" rule in 5-8 — that reversal
is the **hexbridge** zero-arrow bounce, a different object. The behavior described in
`docs/LEGACY_FEATURE_REFERENCE.md` is inaccurate for 5-8; see Flagged ambiguities.) **Hexbridge**
tiles bounce it back after spawning a floor tile recorded **permanently per-account** (bridge id
= `x + room + y`), synced to the server and replayed at every login — cleared hexbridges persist
forever, per player.


empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi — when a
sling has only 1–2 exits it prefers the direction the Navi was *not* travelling (confirmed
legacy behavior; recon re-checking `source-archive/` for the exact rule). **Hexbridge** tiles
bounce it back after spawning a floor tile that is recorded **permanently per-account** (bridge
id = `x + room + y`), synced to the server and replayed at every login — so cleared hexbridges
persist forever, per player.

empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi: in the
5-8 build, ≤1 enabled exit auto-picks that direction; >1 exits halts the orb and waits for an
arrow-key choice. (No "prefer the direction you weren't travelling" rule in 5-8 — that reversal
is the **hexbridge** zero-arrow bounce, a different object. The behavior described in
`docs/LEGACY_FEATURE_REFERENCE.md` is inaccurate for 5-8; see Flagged ambiguities.) **Hexbridge**
tiles bounce it back after spawning a floor tile recorded **permanently per-account** (bridge id
= `x + room + y`), synced to the server and replayed at every login — cleared hexbridges persist
forever, per player.

The signature in-zone traversal mechanic. A **Hexporter** floor terminal splits the Navi into

six light orbs that re-form into a flat hexagon of light, travelling in a straight line across

-empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi — when a

-sling has only 1–2 exits it prefers the direction the Navi was *not* travelling (confirmed

-legacy behavior; recon re-checking `source-archive/` for the exact rule). **Hexbridge** tiles

-bounce it back after spawning a floor tile that is recorded **permanently per-account** (bridge

-id = `x + room + y`), synced to the server and replayed at every login — so cleared hexbridges

+empty space and *under* the floor tiles. **Hexsling** tiles redirect a hexporting Navi: in the

+5-8 build, ≤1 enabled exit auto-picks that direction; >1 exits halts the orb and waits for an

+arrow-key choice. (No "prefer the direction you weren't travelling" rule in 5-8 — that reversal

+is the **hexbridge** zero-arrow bounce, a different object. The behavior described in

+`docs/LEGACY_FEATURE_REFERENCE.md` is inaccurate for 5-8; see Flagged ambiguities.) **Hexbridge**

+tiles bounce it back after spawning a floor tile recorded **permanently per-account** (bridge id

+= `x + room + y`), synced to the server and replayed at every login — cleared hexbridges persist

Intra-zone teleportation via Warp tiles. Inert without the expansion.


- 🔍 **Hexsling direction-preference** — confirmed **real legacy behavior**; recon re-checking
  `source-archive/` for the exact selection rule.
- 🔍 **`dabypass` meaning** — recon passes disagree ("exempt from Abyss" vs "stuck in Abyss until
  you climb out"). Code re-check queued.

- ⚠ **Hexsling direction rule** — resolved for 5-8, and it **contradicts the user's memory AND
  `docs/LEGACY_FEATURE_REFERENCE.md`**: 5-8 hexslings do ≤1-exit auto-pick / >1-exit
  wait-for-input; there is NO "prefer the direction not travelled" (that's the hexbridge
  zero-arrow bounce). If the recalled rule ever existed it's in an un-extracted pre-5-8 client.
  **Action: reconcile `LEGACY_FEATURE_REFERENCE.md` against 5-8 code — it may have other drift.**
- ✅ **`dabypass`** — RESOLVED: a persisted **"trapped in Abyss" sticky flag** (respawn in the
  Abyss each login until you walk out), not an exemption.


- 🔍 **Hexsling direction-preference** — confirmed **real legacy behavior**; recon re-checking
  `source-archive/` for the exact selection rule.
- 🔍 **`dabypass` meaning** — recon passes disagree ("exempt from Abyss" vs "stuck in Abyss until
  you climb out"). Code re-check queued.

- ⚠ **Hexsling direction rule** — resolved for 5-8, and it **contradicts the user's memory AND
  `docs/LEGACY_FEATURE_REFERENCE.md`**: 5-8 hexslings do ≤1-exit auto-pick / >1-exit
  wait-for-input; there is NO "prefer the direction not travelled" (that's the hexbridge
  zero-arrow bounce). If the recalled rule ever existed it's in an un-extracted pre-5-8 client.
  **Action: reconcile `LEGACY_FEATURE_REFERENCE.md` against 5-8 code — it may have other drift.**
- ✅ **`dabypass`** — RESOLVED: a persisted **"trapped in Abyss" sticky flag** (respawn in the
  Abyss each login until you walk out), not an exemption.

it more simply/usably. No separate parallel account-level friends list.

- ✅ **Hidden-tile contiguous-body visibility** — RESOLVED: a **ReBNO design intention (new)**,

-- 🔍 **Hexsling direction-preference** — confirmed **real legacy behavior**; recon re-checking

-  `source-archive/` for the exact selection rule.

-- 🔍 **`dabypass` meaning** — recon passes disagree ("exempt from Abyss" vs "stuck in Abyss until

-  you climb out"). Code re-check queued.

+- ⚠ **Hexsling direction rule** — resolved for 5-8, and it **contradicts the user's memory AND

+  `docs/LEGACY_FEATURE_REFERENCE.md`**: 5-8 hexslings do ≤1-exit auto-pick / >1-exit

+  wait-for-input; there is NO "prefer the direction not travelled" (that's the hexbridge

+  zero-arrow bounce). If the recalled rule ever existed it's in an un-extracted pre-5-8 client.

+  **Action: reconcile `LEGACY_FEATURE_REFERENCE.md` against 5-8 code — it may have other drift.**

+- ✅ **`dabypass`** — RESOLVED: a persisted **"trapped in Abyss" sticky flag** (respawn in the

+  Abyss each login until you walk out), not an exemption.


<task-notification>
<task-id>a75469a4daa4839b7</task-id>
<tool-use-id>toolu_01UBEGKZaPf87mjK2CGXLoY2</tool-use-id>
<output-file>C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\a75469a4daa4839b7.output</output-file>
<status>completed</status>
<summary>Agent "Recon: social board and chat" completed</summary>
<result>Document written to `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\07-social-board-chat.md`.

## Summary — how social/presence worked (or didn't) in legacy BN Online

**Message Boards** — Global shared walls, ~24 of them, one per zone. Each is a `mbparent` child object (`client-5-8/objects/0352-mbparent`) whose Create event sets a static `mbid` (bncentral=0, scrollwood=1, …). All content lives server-side in `mb_topic[]`/`mb_reply[]`, packed as `Author[Title]Body` strings, and persists to **one flat file `MB_Log.bnb`** (`server-5-4/scripts/0365-mb_backup.gml`). The *only* per-user state is an unread flag `u_mb_newmsg[uid][board]`, persisted per user as `News_<uid>.bnu` — that's what the `unews_*` ("user news") scripts do. Posting goes through msgid 11 (topic) / 12 (reply); editing (msgid 6/7) has **no authorship check** — a code comment admits the guard was removed.

**Chat** — The big finding: public chat is **proximity-scoped**, not server- or room-wide. Public msgid-4 (sender byte = 99) only reaches same-room players within **480×360 px** of the speaker (`server-5-4/scripts/0359-server_receive.gml:598-608`). Whispers reuse msgid 4 with the target's pid (point-to-point, cross-room) via `name~message`. Command prefix is the **backtick `` ` ``**, not slash (`join`, `summon`, `add`, `accept`, `watch`, etc.). **No rate limiting and no profanity filter anywhere** — only a bypassable client-side length cap.

**Friend Data** — Inventory **category 2**, stored as `"uid|name"`, server-persisted via `uinv_*`. **No `d_friend` collectable drop exists** (only d_spectrum/d_link/d_key). Friends are added by a **mutual `` `add `` trade** (msgid 15, request-type 5) — a pure client-to-client relay; the server keeps no friend graph. Holding friend data only adds convenience actions (Whisper/Join/Summon in the inventory) and **filters connect/disconnect notifications client-side** — it's not a hard gate.

**Presence** — Global and ephemeral: just a live `p_online[pid]` socket array, broadcast to everyone on login/logout. There's no persistent presence service, no friends-online list, no "last seen," and no client-side way to locate a friend's room/coords. "Is my friend online?" is answered only by the friend-filtered login/logout line or a failed join/whisper.

**Rebuild implications flagged in the doc:** move the friend graph + presence-visibility decision server-side, enforce board edit authorship, and add chat rate-limiting/filtering. Evidence is cited inline with file:line throughout; the few uncertainties (emotes/channels absent) are marked `[inferred]`.</result>
<usage><subagent_tokens>94590</subagent_tokens><tool_uses>26</tool_uses><duration_ms>257769</duration_ms></usage>
</task-notification>


Glossary current through the `dabypass` + hexsling corrections. Meta-flag: your hand-written `LEGACY_FEATURE_REFERENCE.md` is partly memory-based and just took one hit (hexsling) — worth a dedicated recon pass later to reconcile the *whole* doc (esp. the tile-mechanics section) against 5-8 code. Noted in `CONTEXT.md`.

Two recon agents still out — **Watch + request system**, and the **social layer** (boards/chat/friends). Once both land I'll grill the cooperative + social systems armed. Standing by.


Social recon done — and it **corrects two of my earlier assumptions**. Key findings:

- **Chat is proximity-scoped** (480×360 px within a room), not room/server-wide. Whispers are cross-room point-to-point. **Command prefix is backtick `` ` ``**, not slash. No rate-limit/filter in legacy.
- **Friend Data is NOT a found drop** — there's no `d_friend`. It's a **mutual `` `add `` trade** (request type 5), a pure client-to-client relay; legacy keeps **no server friend graph**. So my "collectable Data drop" classification of it was wrong.
- **Message Boards** = global shared walls, one per zone (~24), server-persisted to **`MB_Log.bnb`** (so `.bnb` *does* exist — corrects earlier recon), per-user state = unread flags only. Edit path has **no authorship check** (legacy bug).
- **Presence** = ephemeral global `p_online[]` array; no persistent presence/last-seen/locate.

Folding in + correcting the Friend Data classification:


### Social

**Message Board**:
A persistent in-world posting surface (legacy `MB_News` / `MB_Log`). New boards are a
progression reward.

**Friend Data**:
The legacy in-universe friends list (collected as Data). _Flagged: see ambiguities._

### Social

**Message Board**:
A **global shared wall** — one per Zone (~24, each a `mbparent` with a static `mbid`). Topics +
replies live server-side (`mb_topic[]` / `mb_reply[]`, packed `Author[Title]Body`) and persist
to a single flat file **`MB_Log.bnb`**. The only per-user state is an unread flag, persisted as
`News_<uid>.bnu` (the `unews_*` scripts). Legacy edit path has **no authorship check** (a removed
guard — a bug to fix in ReBNO). New boards unlock as a progression reward.

**Chat**:
Public chat is **proximity-scoped**, not room- or server-wide: a public line reaches only
same-room Navis within **480×360 px** of the speaker. **Whispers** are point-to-point and
cross-room (`name~message`). The command prefix is the **backtick `` ` ``** (`` `join ``,
`` `summon ``, `` `add ``, `` `accept ``, `` `watch ``, …), not slash. Legacy has **no rate
limiting and no profanity filter** (only a bypassable client-side length cap) — both are ReBNO
additions.

**Friend Data** (inventory category 2):
A convenience social link, **NOT a found collectable** — there is no `d_friend` drop. Added by a
**mutual `` `add `` trade** (request type 5, a client-to-client relay; legacy keeps no server
friend graph). Holding it only adds shortcut actions (Whisper / Join / Summon) and filters that
friend's connect/disconnect notices client-side — it is **not a hard gate**. _ReBNO: modernize
in place — move the friend graph + presence server-side._

**Presence**:
Legacy presence is **ephemeral and global** — a live `p_online[pid]` socket array broadcast to
everyone on login/logout. No persistent presence, no friends-online roster, no "last seen," no
way to locate a friend's room/coords. _ReBNO modernizes this server-side._


### Social

**Message Board**:
A persistent in-world posting surface (legacy `MB_News` / `MB_Log`). New boards are a
progression reward.

**Friend Data**:
The legacy in-universe friends list (collected as Data). _Flagged: see ambiguities._

### Social

**Message Board**:
A **global shared wall** — one per Zone (~24, each a `mbparent` with a static `mbid`). Topics +
replies live server-side (`mb_topic[]` / `mb_reply[]`, packed `Author[Title]Body`) and persist
to a single flat file **`MB_Log.bnb`**. The only per-user state is an unread flag, persisted as
`News_<uid>.bnu` (the `unews_*` scripts). Legacy edit path has **no authorship check** (a removed
guard — a bug to fix in ReBNO). New boards unlock as a progression reward.

**Chat**:
Public chat is **proximity-scoped**, not room- or server-wide: a public line reaches only
same-room Navis within **480×360 px** of the speaker. **Whispers** are point-to-point and
cross-room (`name~message`). The command prefix is the **backtick `` ` ``** (`` `join ``,
`` `summon ``, `` `add ``, `` `accept ``, `` `watch ``, …), not slash. Legacy has **no rate
limiting and no profanity filter** (only a bypassable client-side length cap) — both are ReBNO
additions.

**Friend Data** (inventory category 2):
A convenience social link, **NOT a found collectable** — there is no `d_friend` drop. Added by a
**mutual `` `add `` trade** (request type 5, a client-to-client relay; legacy keeps no server
friend graph). Holding it only adds shortcut actions (Whisper / Join / Summon) and filters that
friend's connect/disconnect notices client-side — it is **not a hard gate**. _ReBNO: modernize
in place — move the friend graph + presence server-side._

**Presence**:
Legacy presence is **ephemeral and global** — a live `p_online[pid]` socket array broadcast to
everyone on login/logout. No persistent presence, no friends-online roster, no "last seen," no
way to locate a friend's room/coords. _ReBNO modernizes this server-side._

-A persistent in-world posting surface (legacy `MB_News` / `MB_Log`). New boards are a

+A **global shared wall** — one per Zone (~24, each a `mbparent` with a static `mbid`). Topics +

+replies live server-side (`mb_topic[]` / `mb_reply[]`, packed `Author[Title]Body`) and persist

+to a single flat file **`MB_Log.bnb`**. The only per-user state is an unread flag, persisted as

+`News_<uid>.bnu` (the `unews_*` scripts). Legacy edit path has **no authorship check** (a removed

+guard — a bug to fix in ReBNO). New boards unlock as a progression reward.

-The legacy in-universe friends list (collected as Data). _Flagged: see ambiguities._

+Public chat is **proximity-scoped**, not room- or server-wide: a public line reaches only

+same-room Navis within **480×360 px** of the speaker. **Whispers** are point-to-point and

+cross-room (`name~message`). The command prefix is the **backtick `` ` ``** (`` `join ``,

+`` `summon ``, `` `add ``, `` `accept ``, `` `watch ``, …), not slash. Legacy has **no rate

+limiting and no profanity filter** (only a bypassable client-side length cap) — both are ReBNO

+**Friend Data** (inventory category 2):

+A convenience social link, **NOT a found collectable** — there is no `d_friend` drop. Added by a

+**mutual `` `add `` trade** (request type 5, a client-to-client relay; legacy keeps no server

+friend graph). Holding it only adds shortcut actions (Whisper / Join / Summon) and filters that

+friend's connect/disconnect notices client-side — it is **not a hard gate**. _ReBNO: modernize

+in place — move the friend graph + presence server-side._

+Legacy presence is **ephemeral and global** — a live `p_online[pid]` socket array broadcast to

+everyone on login/logout. No persistent presence, no friends-online roster, no "last seen," no

+way to locate a friend's room/coords. _ReBNO modernizes this server-side._

## Scope principle (parity vs new system)

The dividing test for "what's making it into ReBNO" (confirmed):


- **Friend Data** — an in-universe friends-list entry.

- **Friend Data** — an in-universe friends-list entry (inventory category 2; acquired by a
  mutual social add, NOT found as a drop — see **Friend Data** under Social).


- **Friend Data** — an in-universe friends-list entry (inventory category 2; acquired by a
  mutual social add, NOT found as a drop — see **Friend Data** under Social).

- **Area Link Data** (alias: Area Data) — unlocks fast-travel to an Area; usable only if you

also hold the parent Zone's Zone Link Data.

- **Spectrum Data** — unlocks an avatar cosmetic option (requires `MskPlugn` to apply).

-- **Friend Data** — an in-universe friends-list entry.

+- **Friend Data** — an in-universe friends-list entry (inventory category 2; acquired by a

+  mutual social add, NOT found as a drop — see **Friend Data** under Social).

The teleport-enabling subclass of **Data** — the keys to the fast-travel network. Stored as one


Glossary updated through the social layer. One agent left — **Watch + request system** (the cooperative half). Once it lands I'll grill the cooperative + social cluster together.

Minor open thread: the boards used internal `mbid` names like `scrollwood` (=1) that don't match the zone roster recon-2 found — possibly an internal/old zone alias. I'll reconcile zone naming when we grill the world layer.

Standing by for the last agent.


<task-notification>
<task-id>a82406210c5625ee0</task-id>
<tool-use-id>toolu_015HcnXM2FbXGRSR5LLLPyNv</tool-use-id>
<output-file>C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-rebno\27ced91a-de41-488a-b2a2-10f1c09be4bb\tasks\a82406210c5625ee0.output</output-file>
<status>completed</status>
<summary>Agent "Recon: watch and request system" completed</summary>
<result>Wrote the full recon doc to `C:\Users\decid\Documents\projects\rebno\.planning\legacy-recon\06-watch-requests.md`.

Summary of findings:

- **Request types 0–10** are an internal `rq_new` slot enum encoding both type AND who-asked (so opposite-direction pairs cancel/confirm): 0/1 Join/Summon-from-other, 2/3 Join/Summon-by-self, 4 unused, 5/6 friend-Add, 7/8 Spot, 9/10 Dig. The **msgid-15 wire byte is a DIFFERENT numbering** {0,1,3,4,5,7,9} — don't conflate them; the doc maps both.
- **There is no explicit "accept" packet.** You accept a request by issuing the complementary `rq_*` action; `rq_new` detects the matching pending entry and confirms. Summon/Join/Add/Spot/Dig need explicit two-sided consent. **Ignore is local-only** (no packet). **Duo partners auto-accept** each other's Summon/Join (`rq_new` @51,@76).
- **Watch is a follow-CAMERA, not see-through-their-eyes and not a hidden-tile reveal.** The `watcher` object binds `view_object[0]` to a roving camera that eases toward the target's position; if the target drifts >320×240 it "escapes from view" and watch ends. It's strictly **one-way** (the watched party never learns who watches — only the blunt `` `shake eyes `` evicts all spectators), grants **zero extra visibility** (relies on room-scoped position broadcasts), **freezes your own avatar** while active, and is **NOT gated** by any Navi Expansion.
- **Watch vs Duo:** Watch = unilateral, ungated, camera-only. Duo = mutual, gated behind key item #5 "DuoPlugn" (`canduo`), broadcasts `induo`, and adds: spotter gets a *pannable* duo-watcher (arrow keys), auto-accepted Summon/Join, a teleport TETHER (link-data teleport blocked while `duopid != -1`; digger auto-rejoins spotter on transit), and the **Duo Net** — a digger's fatal fall is caught and the spotter is teleported to the rescue (msgid 23) instead of both being dumped to the Digital Abyss.
- **Server is a pure relay** — zero authority over requests/watch/duo, no consent tracking, no who-watches-whom state, no anti-cheat. Only msgid 15/16/22/23 byte shapes are a real server contract. A server-authoritative REBNO rebuild must *invent* this state machine; there's nothing to port server-side.

Surprising / flagged: (1) a **likely legacy bug** — both `rq_spot` and `rq_duodig` hard-set `duorole=0` on the initiator, so the offer-sender always ends up "spotter" regardless of Ctrl+S vs Ctrl+D; the receive-side sets it correctly. Flagged as [INFERENCE] on intent, do-not-port. (2) The extracted master dir is `server-5-4`, not `master-5-4` as the brief assumed.</result>
<usage><subagent_tokens>90370</subagent_tokens><tool_uses>73</tool_uses><duration_ms>375730</duration_ms></usage>
</task-notification>


Final recon (Watch + requests) in — the cooperative cluster is fully mapped. Highlights: **Watch = one-way follow-camera** (ungated, freezes your avatar, zero extra visibility, target "escapes" past 320×240). **Duo** is the real co-op system — **Spotter/Digger** roles, a **pannable** spotter camera, a **teleport tether**, and the **Duo Net** (digger's fatal fall → spotter teleported to the rescue instead of both hitting the Abyss). Consent model: no "accept" packet — you accept by issuing the complementary action; Duo partners auto-accept. Server = pure relay (ReBNO must *invent* this state machine server-side).

Folding in:


**Duo** (via the **DuoPlugn** Navi Expansion; the **Duo System**):
A pairing of two Navis that benefits both and eases challenges — analogous to the digger+spotter
relationship in Mega Man Legends. Duo partners can **always** see each other, overriding the
hidden-tile visibility rule.

**Watch** (the **Watcher** system):
A social/observation mechanic to watch another Navi — **a more limited form of the Duo system**,
and **not gated by any Navi Expansion** (unlike Duo's `DuoPlugn`). _Exact mechanics being
reconned._

**Request system**:
The unified legacy mechanism (`rq_*`, 11 request types) behind player-to-player interactions —
**Summon/Join**, **Duo** (spot/dig), and **Watch** are all requests. Establishes that
cooperative play is consent-based (a request the other player accepts).

**Duo** (via the **DuoPlugn** Navi Expansion; the **Duo System**):
A **mutual, consented** pairing of two Navis (gated by `DuoPlugn`), modelled on Mega Man Legends'
digger+spotter. Roles: **Digger** (explores) + **Spotter** (rides a *pannable* duo-camera).
Benefits: partners always see each other (overrides hidden-tile visibility); auto-accepted
Summon/Join between them; a **teleport tether** (link-data teleport is blocked while in a duo; the
digger auto-rejoins the spotter on transit); and the **Duo Net**.

**Spotter / Digger**:
The two Duo roles — **Spotter** (pannable observation camera + assist) and **Digger** (the Navi
physically exploring). (Legacy bug, do-not-port: the offer-sender is always forced to Spotter
regardless of intent.)

**Duo Net**:
A Duo safety mechanic: when the Digger takes a fatal fall, instead of both being dumped to the
**Digital Abyss** the fall is caught and the **Spotter is teleported to the rescue** (legacy
msgid 23).

**Watch** (the **Watcher** system):
A **one-way follow-camera** on another Navi — ungated (no expansion). A camera eases toward the
target; if the target drifts past ~320×240 it "escapes from view" and watch ends. Grants **zero
extra visibility** (only room-scoped position broadcasts), **freezes your own avatar** while
active, and the watched party can't tell who's watching (the blunt `` `shake eyes `` command
evicts all spectators). A strictly lighter cousin of **Duo**.

**Request system**:
The unified legacy mechanism (`rq_*`) behind player-to-player interactions — **Join**, **Summon**,
friend **Add**, and Duo **Spot** / **Dig**. Consent model: there is **no explicit "accept"
packet** — you accept by issuing the *complementary* action, which the system pairs with the
pending request; **Ignore is local-only**; **Duo partners auto-accept** each other's Summon/Join.
(**Watch** is adjacent but unilateral — not a consented request.) Legacy server is a pure relay
with no consent/state tracking — **ReBNO must implement this state machine server-side.**