[enhancement] hero_books library selection not yet bound to X-Hero-Context #116

New issue

Open

opened 2026-05-01 04:09:26 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-01 04:09:26 +00:00

Owner

Summary

hero_books library selection is by request library parameter only — not yet bound to X-Hero-Context. hero_books_ui/src/proxy.rs:22-67 parses the context header but doesn't use it for library access control. Today libraries are per-namespace by convention; the design intent is correct but the wiring is unfinished.

Source

crates/hero_books_ui/src/proxy.rs:22-67 — X-Hero-Context parsed in proxy middleware.
crates/hero_books_server/src/web/rpc.rs:319-402 — search.query and similar key off library parameter.
libraries.txt registers <namespace> <git_url> per line; on-disk roots at ~/hero/var/books/{library}/.

Why this matters

Less severe than the embedder/indexer cases because libraries are intended as a public/shared layer (the agent grounds on docs_hero regardless of context, by design). But the sovereignty pitch implies per-context library curation: "personal contexts can have private libraries the agent grounds on, isolated from other contexts." That requires binding context → allowed library set on request entry.

Proposed fix

Maintain a per-context library allowlist (in OSIS settings domain or a new context-config domain).
At request entry, intersect the requested library with the caller's context allowlist; reject if not present.
Default allowlist for unknown contexts: shared/public libraries only.

Severity

Low. Soft contract today, no enforcement; doesn't break demo functionality but blocks the "private per-context libraries" sovereignty story.

Cross-refs

hero_demo#52 — vision (private libraries pitch)
Sister sovereignty issues on hero_embedder / hero_indexer / hero_aibroker (this session)

Spotted during docs_hero Phase 1 source-grounded read (session 52). Reconciliation memo: memory/investigation_roadmap_reconciliation.md.

## Summary `hero_books` library selection is by request `library` parameter only — not yet bound to `X-Hero-Context`. `hero_books_ui/src/proxy.rs:22-67` parses the context header but doesn't use it for library access control. Today libraries are per-namespace by convention; the design intent is correct but the wiring is unfinished. ## Source - [`crates/hero_books_ui/src/proxy.rs:22-67`](https://forge.ourworld.tf/lhumina_code/hero_books/src/branch/development/crates/hero_books_ui/src/proxy.rs) — `X-Hero-Context` parsed in proxy middleware. - [`crates/hero_books_server/src/web/rpc.rs:319-402`](https://forge.ourworld.tf/lhumina_code/hero_books/src/branch/development/crates/hero_books_server/src/web/rpc.rs) — `search.query` and similar key off `library` parameter. - `libraries.txt` registers `<namespace> <git_url>` per line; on-disk roots at `~/hero/var/books/{library}/`. ## Why this matters Less severe than the embedder/indexer cases because libraries are intended as a public/shared layer (the agent grounds on `docs_hero` regardless of context, by design). But the sovereignty pitch implies per-context library curation: "personal contexts can have private libraries the agent grounds on, isolated from other contexts." That requires binding context → allowed library set on request entry. ## Proposed fix 1. Maintain a per-context library allowlist (in OSIS settings domain or a new context-config domain). 2. At request entry, intersect the requested `library` with the caller's context allowlist; reject if not present. 3. Default allowlist for unknown contexts: shared/public libraries only. ## Severity Low. Soft contract today, no enforcement; doesn't break demo functionality but blocks the "private per-context libraries" sovereignty story. ## Cross-refs - [hero_demo#52 — vision](https://forge.ourworld.tf/lhumina_code/hero_demo/issues/52) (private libraries pitch) - Sister sovereignty issues on `hero_embedder` / `hero_indexer` / `hero_aibroker` (this session) Spotted during docs_hero Phase 1 source-grounded read (session 52). Reconciliation memo: `memory/investigation_roadmap_reconciliation.md`.