Area: mobieusKnow (audit p6) · Surface: /know (index) · Dimension: competitor-gap · Severity: major
Help Scout (Collections), Zendesk (Categories -> Sections -> Articles), Notion and Confluence (nested page trees), and Slab (Topics) all organize a KB hierarchically so readers can browse by area, not just search. As a mobieusKnow base grows past a few dozen pages, the flat reverse-chronological list becomes unusable — there is no way to browse 'all billing articles' or present a curated, ordered structure. Tags help filtering but are not a navigable structure (no ordering, no nesting, no landing pages per area). A category/collection layer with a browsable sidebar tree would bring browse parity with every competitor and make large bases navigable.
Evidence
Organization is limited to a flat, updated_at-sorted list and a JSON tag string. KnowledgePage::listAll() is `ORDER BY kp.updated_at DESC LIMIT/OFFSET` with no grouping (KnowledgePage.php:59-74). Tags live as a JSON array column (`tags text ... COMMENT 'JSON array of tag strings'`, schema.sql:3429) surfaced as a flat tag cloud (index.php:148-159). There is no parent_id, no category/section/collection table, and no nesting anywhere in schema.sql:3424-3441 or the model. The index template renders every page as one undifferentiated row list (index.php:170-201).
Suggested fix. Introduce knowledge_categories (or collections) with optional nesting (parent_id) and a page->category assignment, plus a sidebar/landing browse view grouping articles by category with manual ordering. Keep tags as the cross-cutting filter layer on top.
Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.
Patrick Bass
@mobieus