ff96bf0f81
CLAUDE.md's own O9 spec says branding applies to "backend, portal, website and every QWeb report" - the website part was never actually built. The public side of the site was still bare stock Odoo: an empty homepage (website.homepage ships as a literal `<div id="wrap" class="oe_structure oe_empty"/>`) and the admission form as the only real content anywhere a visitor could land. Per discussion: this is Metatroncube's own product marketing page, not the fictional school's site - it stays on a fixed brand (navy/indigo, Manrope + Work Sans, an illustrative dashboard preview panel), not the per-company colours the admission form and portal already read from res.company. Swapping the demo company for the O9 closing beat re-skins the product's own screens; it must not also repaint Metatroncube's own marketing collateral. Real second bug found building this, not related to the homepage content itself: rendering it surfaced a second, separate "Powered by Odoo" badge - web.brand_promotion, called from web.frontend_layout's shared footer - that is completely different from the one mc_education_theme already hid on the portal sidebar (different template, different markup, an <img> logo rather than text). This one sits in the footer of every website AND portal page and had been live on the admission form this whole time; nobody had reason to scroll to the bottom of that page and look. Neutralizing the shared, reusable template rather than website.layout specifically means every current and future caller of web.brand_promotion is covered by one fix. New dependencies this actually needs and the spec's one-line "Depends: mc_education_base" missed: `website` (to inherit website.homepage) and `web` (to inherit web.brand_promotion) - on top of `portal`, already added for the same reason last time. Flagging per CLAUDE.md's closing instruction rather than working around it quietly again. Testing note worth recording: website.homepage resolves through a per-website "copy-on-write" view, and Odoo auto-creates a default website (COW'd immediately) before this module even loads. Checking that per-website combination via _get_combined_arch() inside a --test-enable run that installs and tests everything in one transaction can see a stale, pre-COW empty result purely from cache timing internal to that one transaction - confirmed NOT a real defect by checking the same thing as a fresh request against the actual long-running server, which renders correctly every time. Tests here check what's actually deterministic (this module's own authored view content) plus a live HTTP round trip proving the route itself serves successfully, rather than chase that harness artifact. Full suite (all 9 modules + web_responsive) re-verified together: 0 failed, 0 error(s) of 85 tests. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>