Two new multi-tenancy dev pages, and make file involvement explicit Ed's feedback: the CMDB/Network Mapper work was substantial enough to deserve proper documentation, and dev guides should make it much clearer WHICH php/js files are involved. Fair - the guide named files in prose but had no scannable map, so it couldn't actually be worked from. NEW Multi-Tenancy-CMDB-Case-Study: the worked example for a module whose rows LINK to each other. Why a graph differs from a list (three link mechanisms, all separate holes); the no-shared-CIs decision and what it forced; the core lesson that a same-company invariant must bind ALL-ACCESS actors because a scope check cannot help someone who legitimately reaches both sides; a full colour-keyed file map; the Network Mapper boundary and why get_diagram.php is deliberately unfiltered; what stayed shared and why; the move-between-companies gap. NEW Multi-Tenancy-Test-Harness: the reusable verification kit, roughly 20 lines from module-agnostic. Leads with ALWAYS INCLUDE A POSITIVE CONTROL, because breaking that rule produced a green suite that proved nothing. Also the three tricks that make CLI testing work (DB_NAME defined first, session established before the endpoint's own session_start, php:// wrapper override for the empty php://input), the static tenant-count cache forcing separate processes, the fixture shape, and what to assert. Developer guide gains section 1a "The files you will touch" - a colour-keyed table of the ~10 places every module needs, each with what you do and whether it is skippable. Plus the point that a correctly-scoped module needs NO JavaScript changes at all (CMDB changed zero lines), and if you are editing JS to hide rows you are filtering in the wrong layer. The Reference section is now a "copy from these" table pointing at shipped examples per shape. Also fixed a pre-existing broken link (db-verify) and pointed two #882 references away from the user-facing Pitfalls page.