top companies

{
  "id": "CO-01",
  "rank": 1,
  "name": "Shopify admin + App Bridge",
  "evidence_class": "observed",
  "source": "Shopify App Bridge developer documentation",
  "observed": "2026-08-27",
  "claim": "Left-rail host shell (~8-10 areas), separate gear settings route, store/org picker. Embedded apps run in an iframe while the HOST renders the navigation; apps declare nav declaratively via s-app-nav rather than choosing a numeric position. Host also owns title bar, toasts, modals and resource picker.",
  "limitations": "Docs read, not instrumented; no published comprehension evidence.",
  "disposition": "steal",
  "rationale": "The single closest commercial analogue to Actionist's problem: a host that renders nav on behalf of iframed third-party apps. Proves donor chrome can be replaced without replacing donor code."
}

{
  "id": "CO-02",
  "rank": 2,
  "name": "Atlassian Connect / Forge (Jira, Confluence)",
  "evidence_class": "observed",
  "source": "Atlassian Forge and Connect module documentation; page-layout@5.4.0/constants.js",
  "observed": "2026-08-27",
  "claim": "Left-rail project nav plus top-bar global nav and app-switcher waffle. Donor apps surface only at host-defined MODULE types (issue panel, glance, project page, global page, admin page) - the host enumerates every legal surface. Left sidebar 240px, collapsed 20px; right sidebar 280px; right panel 368px. Forge UI Kit is a host component library; Connect is raw iframe.",
  "limitations": "Two generations of contract coexist; no published task-success evidence.",
  "disposition": "steal",
  "rationale": "The most explicit host-enumerated surface catalogue found. Directly answers 'where may a donor appear' with a closed list rather than a convention."
}

{
  "id": "CO-03",
  "rank": 3,
  "name": "Zendesk + Apps framework",
  "evidence_class": "observed",
  "source": "Zendesk Apps framework manifest reference",
  "observed": "2026-08-27",
  "claim": "Icon-rail plus contextual panel (~5-7 areas); separate Admin Center console; product tray as app switcher. Donor apps live in fixed host slots (ticket_sidebar, nav_bar, top_bar, modal). ticket_sidebar is 320px fixed.",
  "limitations": "One vendor's constants; no rationale published for 320px.",
  "disposition": "steal",
  "rationale": "Provides one of three independent 320px corroborations and the cleanest example of donor-as-sidebar-panel rather than donor-as-page."
}

{
  "id": "CO-04",
  "rank": 4,
  "name": "VS Code",
  "evidence_class": "observed",
  "source": "src/vs/workbench/browser/layout.ts:3026; activitybarPart.ts:50-56",
  "observed": "2026-08-27",
  "claim": "Activity bar 48px (compact 36, floating 36/28); sidebar default width Math.min(300, viewport/4), min 170px, stored default 300px. This is the ONLY genuinely proportional rail rule found across the whole corpus - and it is 25/75, capped, not 20/80.",
  "limitations": "Not a B2B SaaS shell; a code editor.",
  "disposition": "steal",
  "rationale": "The only defensible citation in existence for a proportional host/app split. If the 20/80 concept needs a precedent, this is it - and it corrects the number."
}

{
  "id": "CO-05",
  "rank": 5,
  "name": "Grafana",
  "evidence_class": "observed",
  "source": "MegaMenu.tsx:22; Grafana configure-grafana docs",
  "observed": "2026-08-27",
  "claim": "Left-rail dockable MegaMenu at 320px (>=md) plus top bar. Plugins nest under /a/<id>/* so a donor keeps its internal hierarchy beneath one host nav row, and declare presence via an addToNav BOOLEAN - the host owns ordering. serve_from_sub_path is the best-documented sub-path support in the OSS corpus.",
  "limitations": "AGPL-3.0 blocks Grafana itself as a donor regardless of how good its topology is.",
  "disposition": "study",
  "rationale": "The healthiest nav-absorption middle ground observed: donor keeps hierarchy below the fold, host keeps one row. Second 320px corroboration."
}

{
  "id": "CO-06",
  "rank": 6,
  "name": "Salesforce Lightning / Service Cloud + AppExchange",
  "evidence_class": "inferred",
  "source": "Salesforce Lightning and SLDS documentation",
  "observed": "2026-08-27",
  "claim": "Top-bar app-scoped nav with an App Launcher waffle switcher; Setup is a SEPARATE admin console, not a nav item. AppExchange packages appear as first-class tabs; LWC and Visualforce canvas embed donor UI inside records; the utility bar is a bottom bar (width:100%, height:2.5rem) rather than a rail.",
  "limitations": "INFERRED - not verified this session; area count is app-dependent.",
  "disposition": "study",
  "rationale": "The largest platform-in-platform in existence and the strongest precedent for settings living in a separate console rather than competing for a nav slot."
}

{
  "id": "CO-07",
  "rank": 7,
  "name": "Microsoft 365 shell / Teams apps",
  "evidence_class": "inferred",
  "source": "Microsoft 365 and Teams app documentation",
  "observed": "2026-08-27",
  "claim": "Persistent host app-launcher waffle across products; Teams personal apps and tabs are iframed donor surfaces that keep their own internal nav inside the frame while Teams owns the outer rail and identity.",
  "limitations": "INFERRED - not verified this session.",
  "disposition": "study",
  "rationale": "The canonical multi-app switcher, and the clearest example of the 'keep donor chrome inside the frame' resolution with its costs visible."
}

{
  "id": "CO-08",
  "rank": 8,
  "name": "IBM Carbon UI shell",
  "evidence_class": "observed",
  "source": "carbondesignsystem.com UI shell guidance",
  "observed": "2026-08-27",
  "claim": "Left panel 256px / 16rem. Carbon is the ONLY vendor found publishing a decision rule rather than just a token: use the left panel if there are more than five secondary navigation items, or if users switch between them frequently. Also states the left panel does not support three tiers of navigation. Breakpoints 320/672/1056/1312/1584px.",
  "limitations": "Design guidance, not evidence of task success.",
  "disposition": "steal",
  "rationale": "The only published rationale in the corpus. Supplies both the nav budget cap (>5) and the depth limit (2 tiers) adopted into the ShellTopology contract."
}

{
  "id": "CO-09",
  "rank": 9,
  "name": "Intercom (Canvas Kit)",
  "evidence_class": "observed",
  "source": "Intercom Canvas Kit documentation",
  "observed": "2026-08-27",
  "claim": "Icon-rail plus contextual panel (~6-8 areas), separate gear settings route, workspace dropdown. Donor apps render via SERVER-DRIVEN JSON at five host locations - no iframe, no donor CSS at all. The host renders every pixel.",
  "limitations": "Maximum consistency at the cost of donor expressiveness.",
  "disposition": "study",
  "rationale": "The purest example of the highest-consistency donor tier, and the honest opposite end of the tradeoff from Teams/Zendesk iframes."
}

{
  "id": "CO-10",
  "rank": 10,
  "name": "AWS Console",
  "evidence_class": "observed",
  "source": "AWS Console Unified Navigation survey",
  "observed": "2026-08-27",
  "claim": "Top-bar unified navigation plus per-service left rails across 200+ service consoles; account/role and Region pickers. NO third-party embedded UI surface was found - Marketplace provisions resources rather than rendering donor UI.",
  "limitations": "Absence of evidence within one console; not proof no surface exists.",
  "disposition": "study",
  "rationale": "A deliberate negative data point. A host at extreme scale chose to admit NO donor UI at all, which is a live option Actionist should price rather than assume away."
}