RedBear-OS/local/docs/ORPHAN-STATUS.md

Orphan Status — Library-Only Red Bear Crates (corrected 2026-07-28)

Date: 2026-07-28 (corrected to reflect FIRST-CLASS CITIZEN wiring)

Status: NO ORPHANS REMAIN

As of 2026-07-28, every redbear-* recipe is reachable from at least one Red Bear OS build config (redbear-mini.toml for text-only, redbear-full.toml for graphics, plus experimental configs for peripherals). Verification:

# All 48 redbear-* recipe directories in local/recipes/ are referenced from
# at least one config (via direct [packages] entry or transitive inheritance).
$ for r in $(find local/recipes -maxdepth 3 -type d -name "redbear-*" | sort -u); do
    prog=$(basename "$r")
    if ! grep -rq "$prog" config/redbear-full.toml config/redbear-mini.toml \
         config/redbear-*-experimental.toml 2>/dev/null; then
      echo "ORPHAN: $prog"
    fi
  done
# (prints nothing)

See local/docs/REDBEAR-FIRST-CLASS-CITIZEN-POLICY.md for the policy text.

What this doc covers

This doc explains the library-only category: recipes that produce no binary and are consumed via Cargo path dependencies. Library-only recipes are still first-class citizens (they appear in some config) — they just don't ship a binary.

Library-only recipes (4)

Recipe	Consumers	Config
redbear-hid-core	(HID parser library — future input stack consumers; no current consumers in mini)	redbear-full.toml [packages] (paired with desktop input stack)
redbear-login-protocol	redbear-authd, redbear-greeter (both in full)	redbear-full.toml [packages]
redbear-passwd	(account parsing library — currently unused by any binary in mini; consumed by future passwd CLI)	redbear-full.toml [packages]
redbear-tui-theme	redbear-power, cub, tlc (all in mini)	redbear-mini.toml [packages]

These recipes have a [lib] section in their Cargo.toml but no [[bin]] entries. The cookbook builds them as .rlib artifacts that consumers link against via Cargo path deps.

Why library-only recipes are not "orphans"

A recipe is "orphaned" if it is unreachable from any build config. Library-only recipes are unreachable only if their consumers don't exist. In Red Bear OS:

• redbear-hid-core, redbear-login-protocol, redbear-passwd are wired into full because their consumers (input stack, login stack, future passwd CLI) are full-only.
• redbear-tui-theme is wired into mini because its consumers (TUI apps: power, cub, tlc) are in mini.

This is not an orphan pattern. It is the correct consumption pattern for libraries: declare the library as a build target, list it in some config so the cookbook cooks it, and let consumers pull it in via Cargo path dep.

Historical note

Before 2026-07-28, redbear-hid-core, redbear-login-protocol, redbear-passwd, redbear-tui-theme, redbear-input-headers, redbear-driver-policy were all considered "orphans" by the systematic assessment because they did not appear in any config. This was incorrect analysis — the correct classification is "library-only / data-only / cross-category build dep". The 2026-07-28 FIRST-CLASS CITIZEN wiring pass resolved all such cases by adding them to the appropriate config (mini or full) per the wiring table in local/docs/REDBEAR-FIRST-CLASS-CITIZEN-POLICY.md.

Recipe TOML files for library-only crates

All 4 library-only recipes follow the standard cookbook format:

[package]
name = "<recipe>"
version = "0.3.1"
edition = "2024"
license = "MIT"
repository = "https://gitea.redbearos.org/vasilito/RedBear-OS"

[source]
path = "source"

[build]
template = "cargo"

Their source Cargo.toml files have a [lib] section (e.g. [lib] name = "redbear_login_protocol") but no [[bin]] entries. Consumers add a path dependency:

[dependencies]
redbear-login-protocol = { path = "../../../system/redbear-login-protocol/source" }

This is the standard Cargo workspace pattern for library-only internal crates.

See also

• local/docs/REDBEAR-FIRST-CLASS-CITIZEN-POLICY.md — wiring policy (mini vs full table)
• local/docs/FIRMWARE-SUBSETS-DECISION.md — firmware subset recipes (data-only, graphics-only)