P08 — Archetypes, shells and layouts

Lane: S1-L3 · Part: P08 · Run: 2026-08-27-sprint-1-fable · Observed: 2026-08-27 Mode: research-only · UNEXECUTED · NOT_ADMITTED · no implementation, build, deploy or admission Owned output dir: research/workstreams/p08-archetype-shell-layout/runs/2026-08-27-sprint-1-fable/

0. The four results that change a decision

1. The five-area ISSO shell (A15) is not a hypothesis about information architecture — it is a hardcoded 5-tuple in the type system. sidebar-factory.tsx:22 types sections as a fixed five-element tuple, and page-registry.tsx:6 freezes five product ids (hub, intelligence, recon, agents, content-gen) with fixed hotkeys ⌘1–⌘5. Two different personas — agency operator and model — both jam their content into those same five slots. The observable consequence is in the source: the model webcam rail assigns the label Menu to product: 'agents' and Insights to product: 'content-gen'. The slot ids no longer mean anything. A15 should be reclassified from "unproven" to partially falsified at the semantic level: five slots survives as a rail template only by emptying its own labels.

1. "Which archetypes cover 80% of the 17 industries" has no cheap answer, and the honest number is the finding. Computed from the b2b shelf mapping: covering only primary archetypes needs 5 archetypes for 82.4% (case_workflow, field_operations, learning_content, scheduling, crm). But if an industry is only served when both its primary and secondary archetype exist, no subset of 7 or fewer reaches 80% — the best 7 gives 13/17 (76%), and you need 8 archetypes for 15/17 (88%). The much-quoted "case_workflow + portal are the big two" is real but smaller than it sounds: those two touch 11/17 industries (65%), and satisfy only 4/17 (24%) on their own. Six industries (construction, ecommerce, hospitality, logistics_freight, real_estate, saas) touch neither.

1. The best local evidence says the host owns the rail and donors never get a nav row of their own. Two independent SISOCRM receipts converge: OWNERSHIP-AND-DATA-LAYER-DECISIONS.md:96 rules "Shell / navigation rail → OWN … Already replaced Plane's launcher", and TEABLE-ABSORPTION-BRIEF.md:9-17 rules "Teable is NOT a page … The broker never clicks 'Tables'. They see a grid and it happens to be Teable." FROZEN-PAGE-SKELETON.md then shows the pattern executed at scale: 11 host-owned pages, each folding in 1–5 donors underneath, with zero donor-named nav entries. This is a shipped-intent design, not a theory.

1. The "20/80 split" does not exist as a percentage in any surveyed product except one. Across 19 measured shells, every rail is a fixed pixel constant that only happens to be ~20% at one viewport. The sole proportional rule found is VS Code's Math.min(300, viewport/4) (layout.ts:3026) — which is 25/75, capped. Two width classes emerge: ~160px (WordPress) forces donors to flatten; ~320px (Zendesk 320, Grafana 320, Metabase 324 — within 4px of each other) is the evidenced floor for a donor keeping nested hierarchy. No vendor publishes a rationale for its width number; IBM Carbon alone publishes a decision rule ("use the left panel if there are more than five secondary navigation items").

1. Denominators and method

Denominator honesty. The 111 and 104 figures are surveyed breadth, held in the research lanes' returns. This packet records the top 10 of each as per-row dossiers; there is no 111-row or 104-row JSONL here and none is implied. Quote these as "surveyed ~111, recorded 10" and "surveyed ~104, recorded 10".

Evidence discipline applied. license.spdx_id is not a rights answer: 28 of 104 repos returned NOASSERTION, and reading the bodies changed the verdict in both directions. Directus is not BSL/GPL any more — it is MSCL-1.0-GPL ("Copyright 2026 Monospace Inc.") with an anti-Competing-Use clause, a prohibition on circumventing the licence key, and GPL-3.0 only on the fourth anniversary. n8n and NocoDB are Sustainable Use Licence (non-OSI). Outline and Akaunting are BSL. InvoiceNinja is ELv2. Conversely single-spa shows NOASSERTION but its LICENSE body is plain MIT — NOASSERTION means unclassified, not restrictive.

Do not quote the 87 INFERRED commercial area-counts as measurements. In most of those products the count is role-, plan-, or install-dependent anyway (ServiceNow by role, SAP by space, Odoo by installed modules, Salesforce by app).

Two identity corrections caught before they reached the client. copilot.com (the client-portal product) is now Assembly — docs.copilot.app 301s to assembly.com/docs/, and the old hostnames do not resolve. practice.do returns 404 on every probed path. Any deliverable naming "Copilot" is citing stale branding.

2. Host shell vs donor chrome — the boundary contract

2.1 What the host MUST own (non-negotiable)

Derived from the convergence of Luigi (host declares every nav node; donors contribute none), Backstage (RouteRef indirection so donors never hardcode host URLs), the SISOCRM rail verdict, and the Teable rule.

2.2 What a donor MAY keep

• Its internal, below-the-fold navigation — tabs, sub-rails, view switchers inside its content pane. Grafana's /a/<id>/* nesting is the shipped precedent: donor keeps hierarchy, host keeps one rail row.
• Its own record/detail routing, provided it accepts a basename. react-admin is the reference: <Admin basename="/admin"> is documented, with the honest caveat quoted in its own docs — "it is your responsibility to serve the admin from the sub path."
• Its data model, migrations and background jobs. Per OWNERSHIP-AND-DATA-LAYER-DECISIONS.md: one Postgres server, separate schemas per donor, one owner per table, never two.
• Its engine-shaped internals — anything the doc classifies as "liability to own": signature envelopes and crypto audit (Documenso), AV scanning, work-item backend.

2.3 The three constraints that eliminate strategies

These are observed from vendor documentation, not inferred, and each kills a plausible design:

1. Style isolation is one-way in every mechanism surveyed. qiankun v3 states its @scope-based isolation is "a one-way boundary" — it stops donor CSS escaping and does not stop host CSS entering. JD's micro-app says the same in Chinese. Plan for the donor to be restyled by your reset; do not plan to protect it.
2. Portaled overlays are the universal failure mode. qiankun v3, verbatim: "A menu, dialog, or tooltip rendered under document.body instead of inside the micro-app container is outside the scope root, so the app's scoped selectors will not match it." A donor whose modals portal to body renders unstyled. And in an iframe, wujie's docs state modals "can only display inside the iframe and cannot cover the whole page." The <dialog> top layer is the only reliable escape.
3. Sharing one React tree across a donor boundary is unreliable — by vendor admission. Module Federation's singleton defaults to false (duplication is the silent default), and even singleton: true is defeated by a missing trailing slash — MF's own docs flag that 'react-dom' without the slash lets react-dom/client load a second React copy. That MF ships a Bridge subsystem explicitly for "Framework Isolation… Ensures React contexts and component trees between different applications are isolated" is the vendor conceding the point.

Consequence for P08: any shell option that depends on donor CSS surviving intact, on donor modals covering the viewport, or on one shared React tree, is carrying an unpriced risk. Options 1 and 2 in §4 avoid all three.

3. Local estate — observed receipts

3.1 ISSO dashboard — the five-area claim, verified against source

Path: [local path redacted]

The five areas are enforced, not conventional:

• src/shared/layout/sidebar-factory.tsx:19-25 — DashboardSidebarInput.sections is typed [SectionContent, SectionContent, SectionContent, SectionContent, SectionContent] with the comment /** Must be exactly 5 sections */. Six is a compile error.
• src/shared/layout/page-registry.tsx:6 — SECTION_PRODUCTS = ['hub', 'intelligence', 'recon', 'agents', 'content-gen'] as const.
• sidebar-factory.tsx:27-34 — comment: // Fixed section template — IDs, hotkeys, and fallback icons never change. Hotkeys ⌘1–⌘5 bound to product ids.
• sidebar-factory.tsx:39-41 — runtime throw if two sections claim the same product id.

The semantic drift is observable in two files (pairs below are section-level label/product fields — the sibling keys of each sections[] entry, not the nested items[] labels). Agency rail (src/app/agency/sidebar-config.tsx): Overview→hub, Content→intelligence, Team→recon, Webcam→agents, Tools→content-gen. Model webcam rail (src/app/model/sidebar-config.tsx): Live→hub, Chat→intelligence, Tasks→recon, Menu→agents, Insights→content-gen. recon means "Team" in one and "Tasks" in the other; content-gen means "Tools" and "Insights". The ids are positional slots wearing capability names.

Route reality contradicts "five areas" at the app level. src/app/ contains at least 8 top-level route groups — agency, model, client/[clientSlug], portal, content-gen, autosaas, chatters, social-manager, plus editor, gallery, knowledge. The portal/ area alone has 20+ compliance sub-routes (iso-27001-framework, evidence-vault, risk-register, security-questionnaires…) that are not reachable through any five-slot rail. The five-area shell describes one rail component, not the application's information architecture.

3.2 SISOCRM business-broker — the best local absorption evidence

Path: [local path redacted]

FROZEN-PAGE-SKELETON.md (status FROZEN, dated 2026-07-31) is the strongest artifact in the local estate for P08. 11 host-owned pages, each with a named base donor, folded-in donors, and an explicit SISO-owned column:

Not one donor gets a nav entry named after itself. Teable appears three times and is invisible in the rail all three. This is the absorb-rule executed, and it is the empirical basis for Option 1 in §4.

Ownership rules (OWNERSHIP-AND-DATA-LAYER-DECISIONS.md): shell/nav rail OWN; Twenty record surfaces OWN — transplant; Plane backend, Documenso, Papermark, Activepieces, ClamAV/Postgres/Redis/Caddy SERVICE — downstream. The stated failure mode, quoted: "owning the security-critical parts while renting the parts that define your product."

3.3 AutoSaaS five-area convention — origin traced

[local path redacted] — §5 "SaaS Shell Map": "Every SaaS gets mapped into five primary product areas by default. This borrows the ISSO dashboard pattern without freezing UI forever." Its own gate is workflow-shaped, not slot-shaped: "the main activation workflow must be reachable through the shell." Line 283 concedes: "no generic ISSO shell extraction." The convention therefore has no extracted artifact and no validation — it is an inherited default with a caveat attached at birth.

3.4 Bykonz — located, and it is not a shell

BLOCKER RESOLVED. Not in SISO_Agency/apps/ or SISO_Agency/clients/. Found at [local path redacted].

It is an archive of ~25 workstream directories plus screenshots, not a running application: bykonz-affine-admission, bykonz-review-donor, bykonz-integration-map, bykonz-w1-thin-vertical, bykonz-w2-native-dashboard-media, plane-delivery-candidate, and desktop-1440/mobile-390 PNGs of admin ticketing and inbox. Its P08 value is as donor-absorption precedent (AFFiNE admission, donor review, integration map), not as a shell to survey. No nav source was read; the directory names are observed, their contents are unknown in this run.

4. The shell option matrix

Six distinct options, scored against the criteria requested. Scores are judgement calibrated to the evidence in §2–§3, expressed 1–5 (5 best), with the evidence class of the option itself stated. These are not measurements.

4.1 The options

• Option 1 — Host-owned page shelf, donors as embedded surfaces. Host declares every nav entry (11-ish pages). Donors render inside host pages, never as a nav peer. This is the SISOCRM FROZEN-PAGE-SKELETON pattern, and Luigi's model in OSS.
• Option 2 — Host rail + donor nav registry injection. Donors declare nav items to the host, which renders them in host chrome and owns ordering. Backstage (PageBlueprint auto-discovery) and Piral (registerMenu).
• Option 3 — Fixed five-area rail (the inherited ISSO shell). Exactly five slots, fixed ids and hotkeys, all content mapped in.
• Option 4 — Archetype-native topology. Each of the 10 archetypes ships its own nav skeleton derived from its data spine and authority model. No shared slot count.
• Option 5 — Iframe/microfrontend isolation with host rail. Donor runs in an iframe or sandboxed microfrontend; host provides the rail around it.
• Option 6 — Headless donors, host renders all UI. Take the donor's engine and API; rebuild every surface in host components. Refine, Tremor, shadcn, Cube — donors with no chrome to strip.

4.2 The matrix

Score rationale for the load-bearing cells. O1 scores 5 on evidence because it is the only option with both a local shipped-intent artifact (FROZEN-PAGE-SKELETON, status FROZEN) and an external OSS analogue (Luigi). O3 scores 1 on comprehension because of the observed label drift in §3.1 — recon meaning both "Team" and "Tasks" is a comprehension failure visible in the source before any user is tested. O5 scores 1 on settings/identity because of the iframe cookie reality: SameSite=Lax excludes iframe navigations, Firefox partitions by default since 103, and the Storage Access API requires transient user activation — so silent auth on load is not available. O6 scores 1 on absorption cost because rebuilding every surface is precisely the cost absorption exists to avoid.

4.3 Archetype × option fit

Where the archetypes actually differ, and therefore where a single shell option stops being adequate:

5. The absorb-vs-preserve decision rule

Default: absorb the navigation, preserve the engine. Preserving donor chrome is the exception and must be argued.

5.1 Signals to ABSORB (strip donor nav, host declares the entry)

1. The donor's surface is product-defining. Per OWNERSHIP-AND-DATA-LAYER-DECISIONS.md: record surfaces, list/table/filter/detail, the shell, and domain vocabulary are "liability NOT to own" upstream — every tweak fights upstream's assumptions.
2. The donor's nav names the donor, not the work. The Teable test: if the user would have to click a word that is a vendor's product name to do their job, absorb it. "The broker never clicks 'Tables'."
3. The donor covers only part of one host page. A grid, an editor, a signature pane. These are components wearing an app's clothes.
4. Two donors would otherwise both claim the same concept. Twenty and Teable both offer a records grid; without absorption you ship two Buyers lists and users update the wrong one — the "second silo nobody updates" failure named in the Teable brief.
5. The donor's identity model would create a second login. Non-negotiable; see §2.1.
6. The donor is headless or chrome-light already (Refine, Tremor, Cube). Nothing to preserve; absorb by default.

5.2 Signals to PRESERVE (keep donor's own navigation, mount it whole)

1. The donor is a whole workflow the user already knows by name, and its internal nav is the expertise. FROZEN-PAGE-SKELETON does exactly this once: Tasks = Plane (whole-slice).
2. The donor's internal nav is below the host's rail, not beside it. Grafana's /a/<id>/* nesting — donor keeps hierarchy, host keeps one row. This is preservation within absorption and is the healthy middle.
3. The donor is security- or legally-critical and forking its UI would fork its audit story. Documenso's signature ceremony: the "last code we want to maintain."
4. The licence forbids chrome removal. Two live examples found: NocoBase §5.2 — "It is not allowed to remove or change the brand, name, link, version number, license… except for the main LOGO in the upper left corner"; Directus MSCL forbids circumventing the licence key. Here absorption is a licence violation, not an engineering task. Preserve, or do not adopt.
5. The donor is untrusted or multi-tenant-risky — iframe it, accept its chrome, accept the modal confinement.

5.3 The rule, stated once

Absorb the navigation when the donor supplies a capability; preserve it when the donor supplies a destination. A capability belongs inside a host page the user already knows how to name. A destination is a place the user goes on purpose, by the donor's own name — and there should be at most one or two in a whole product.

Governance corollary (from the WordPress failure mode): never let a donor pick a numeric nav position. WordPress's $position integer produces silent collisions patched by an MD5 hash offset, making menu order a function of what else is installed. Grafana's addToNav boolean and Shopify's declarative s-app-nav let the host own ordering. Donors declare intent; the host declares order.

6. Verdicts on the two named hypotheses

6.1 A15 — the five-area ISSO shell

Verdict: reject as a default; retain as one archetype-level rail variant among several.

Grounds, all observed: (a) it is a compile-time 5-tuple, so it cannot flex without a type change; (b) its slot ids have already lost meaning across two personas in the same codebase (§3.1); (c) the ISSO app itself has 8+ top-level route groups and a 20+ route portal/ area that the rail does not reach; (d) AutoSaaS shipped it with a self-caveat and never extracted it. Master synthesis already reached the same conclusion by argument: "it should not become a constitutional constraint." This run supplies the source-level receipt for that argument.

What survives: five is a plausible upper bound for comfortable top-level rail items, consistent with Carbon's published rule (left panel when >5 secondary items). Keep the number as a budget cap, not a schema.

Experiment (E1, ranked #2 by the innovation lane). Three case_workflow-primary industries (law_firms, mortgage_brokers, insurance_agencies). Two paper navs each: (A) real work forced into the five inherited slots; (B) nav derived mechanically from the case_workflow spine. Card-sort / first-click with 5 practitioners per industry (15 total), 8 real tasks. No software. Measure first-click accuracy and time-to-first-click, plus unprompted naming. Falsifier: if A scores within noise of B, five slots was accidentally fine and is kept. If neither clears ~70% first-click accuracy, both navs are wrong and the problem is deeper than labels.

6.2 The 20/80 host/app pane

**Verdict: the concept is sound and precedented; the number is not evidenced and should not be specified as a percentage.**

Grounds: across 19 measured shells, rails are fixed pixel constants, not percentages. The only proportional rule found is VS Code's min(300px, viewport/4) — 25/75, capped. Carbon's 256px is 20% at 1280px and 13% at 1920px, so "20%" is a statement about one monitor. Specify a pixel width with a viewport-class collapse rule, not a ratio.

Recommended starting specification (hypothesis, to be tested): host rail 320px at ≥1056px viewport — the evidenced floor for a donor keeping nested nav inline, corroborated three times independently (Zendesk 320, Grafana 320, Metabase 324). Collapse to an icon rail (~48–80px, per VS Code 48 / Material 3 rail 80–96dp) below that, and to a bottom bar or overlay below ~768px (Polaris and Primer both switch at 768).

Experiment (E2, ranked #3). Ship the rail collapsible with per-user memory, no prompt, no explanation. Run 3–4 weeks on real users. Measure: % who collapse and never re-expand; % who toggle repeatedly; which rail items are clicked at all. Falsifier: >50% permanent collapse kills the wide rail in favour of an icon rail. If the only items ever clicked are settings and tenant-switch, the rail should be a puck and the pixels go to the app pane.

7. Which archetypes cover 80% of the 17 industries

Computed from the b2b shelf 17-industry mapping; re-derived from source in this run.

Interpretation. The attractive headline — "two archetypes carry the majority of demand" — is true about touch and false about sufficiency. An industry whose secondary archetype is missing gets a product with a hole in it (a law firm without a client portal, a mortgage broker without document collection). The 80% question therefore has a cheap answer only if secondary archetypes are treated as optional, and that is a product decision, not a computation.

Recommendation: build case_workflow first, portal second — not because two archetypes cover 80%, but because case_workflow is primary for 6/17 while having the thinnest clean-licence supply (the shelf's supply-inversion finding), and portal is the most common secondary and the one most often missing from donor apps. marketplace should not be built.

8. Per-industry shell differentiation

Where the 17 industries force genuinely different shells rather than different words:

• law_firms (case_workflow + portal). Matter-centric desktop nav; statutory deadlines mean the deadline clock is a first-class surface, not a widget. Privilege boundary means the portal is a separate shell with its own identity, not a tab. Two shells, one product.
• construction, logistics_freight (field_operations). Mobile-first, offline, camera-first evidence capture. A 320px desktop rail is the wrong primitive entirely — this is the archetype that most clearly falsifies a single shared shell. Note both are also among the industries with no direct shelf row.
• property_management, mortgage_brokers, it_services_msps (portal secondary). The portal is an untrusted external identity; its chrome must be minimal and must never expose internal nav, search, or tenant switching. Host-owned chrome here is a security requirement, not an aesthetic one.
• healthcare_medical_practices (scheduling + case_workflow). Calendar wants the viewport; PHI forces isolation and consent gates before any donor is mountable at all.
• accounting_firms, insurance_agencies (finance_ops). Audit trail must be reachable from every surface — argues for a persistent host element, which is a point for a rail.
• ecommerce, saas (inventory / crm). Most template-saturated, weakest differentiation. Be conventional; spend the design budget elsewhere.

9. Contracts and decision gates (unexecuted)

Contracts to define (not implemented in this run):

• HostShellContract — the eight host-owned surfaces of §2.1, as named ports.
• DonorNavDeclaration — donor declares {intent, label, icon, routeRef}; host assigns order and final path. No numeric position field (§5.3).
• RouteRef indirection — adopt Backstage's model so donors never hardcode host URLs; bind cross-donor links in host config.
• ShellTopology — per-archetype nav skeleton with a top-level item budget cap (start at 5–7, per Carbon's >5 rule) and a depth limit of 2 (Carbon: "The left panel does not support three tiers of navigation").
• MountProfile — per donor: sub-path support, basename mechanism, build-time vs runtime path substitution, auth delegation seam, chrome-disable mechanism, licence constraint on chrome removal.

Gates, in order:

1. Donor Admission Test (E3, ranked #1). Six named donors × four binary questions, each answered by a real attempt not a doc read: does it mount under a sub-path with a rebased router; can auth be delegated without a shadow user table; will it render below full-page in a host container; does it emit normalizable events. Timebox 1 day per donor. Falsifier: if zero donors pass all four, "absorb third-party apps" must be restated as "run headless and rebuild the UI" (Option 6), which changes P08's cost model enormously.
2. E1 five-area card sort (§6.1) — cheapest way to retire or keep the largest inherited assumption.
3. E2 rail collapse-rate (§6.2) — behavioural verdict on 20/80.
4. Vocabulary-isomorphism test. For the three case_workflow industries, write out the state machine, deadline rules, and document set; compute pairwise structural overlap after renaming. If isomorphic, one product with a vocabulary layer — much cheaper. If not, especially in deadline rules, the rules engine is the actual product and "generate an app" is the wrong frame for the highest-demand archetype.
5. Licence gate before any donor chrome work. NocoBase §5.2 and Directus MSCL make chrome removal a legal question. Read the LICENSE body, never the badge.

10. What is NOT established

• No implementation, build, deployment, or admission. UNEXECUTED, NOT_ADMITTED.
• No user testing whatsoever. Every comprehension and activation claim in §4 is judgement calibrated to documented precedent, not measurement. No published evidence was found linking nav topology or area count to task success in any surveyed product — the research lane looked and reports its absence rather than inventing a figure.
• 87 of 111 commercial products are inferred, not verified this session. Their area counts are shape indicators only.
• Bykonz contents were not read — only its directory listing. Its shell topology is unknown.
• SISOCRM's shell was read as documents, not running code. FROZEN-PAGE-SKELETON states intent and freeze status; whether 11 pages exist and render was not observed.
• The matrix scores in §4.2 are judgement, not measurement. They are reproducible from the stated rationale but they are not data.
• The 80% computation depends entirely on the b2b shelf's primary/secondary assignment, which that report itself classes as I-class judgement with industry fit values as hypotheses. The arithmetic is exact; its inputs are not measured demand.
• No accessibility, performance, i18n/RTL, or security review of any shell option.
• No decision is authorized by this document.

Research-only artifact. No implementation, deployment, admission, or client/legal clearance is claimed or authorized.