The Non-Adoption You Write Down

One Surface Stays Out

Every app in the family that docks the assistant runs the shared chrome — except one. A browser extension does the same job in a completely different setting, and it is a deliberate non-adoption, recorded with five structural reasons and explicitly closed so it is never re-litigated.

The reasons are worth reading as a set, because no single one of them would be decisive alone and together they are overwhelming:

It is buildless by design. Adopting a component framework means giving a content script a bundler and a runtime — a rewrite pretending to be an adoption.
Its side mode is the browser's own native panel. The browser draws the container, the drag handle, the open and close. Shared chrome there would be chrome inside chrome.
Its docked modes inject into arbitrary third-party pages, where class-based cascade styling collides with host styles by construction. The extension's inline-everything approach is the correct engineering for a hostile DOM, not a gap in it.
The shared component's defining rule is impossible there. Its whole contract is that the panel pushes host content aside rather than covering it. A content script cannot repack somebody else's page.
Its geometry lives in extension storage, a different persistence contract on purpose.

Why the Reasons Have to Be Written

An item missing from a convergence table is indistinguishable from unfinished work. The table is full of checkmarks; one cell is empty; the natural reading is that somebody ran out of time. Eventually a helpful person starts converting it, spends real effort, and either finishes — destroying a deliberate decision — or discovers the fourth reason halfway through and abandons the attempt having learned what a paragraph would have told them.

Writing the reasons converts a suspicious gap into a closed question. The record says out loud that it was recorded so it stays closed, which is a different speech act from documenting a fact: it is a decision, addressed to the future.

Record what you decided NOT to unify, with reasons, in the same table as what you did. Convergence work leaves a trail of checkmarks that reads as progress, and any gap in it reads as remaining work. Deliberate exclusions are invisible unless they are written where the exclusion is noticed — which is the table, not a commit message and not somebody's memory.

Notice What It Shares Anyway

The strongest part of the record is the last line: the extension already shares the part that matters. Its panel loads the same embedded surface every other app loads, so improvements to that surface reach it with no extension change at all — verified when a navigation control landed there for free.

That reframes the exclusion completely. It is not "this one is left behind". It is that the sharing happens at a different layer, and the layer where it does not share is the layer where sharing was never going to help. A non-adoption with that sentence attached is a boundary; without it, it looks like a hole.

Code

The adoption table, with the exclusion written into it·text

SHARED CHROME - who runs it

  app A  ✅  shim, app emblem in header
  app B  ✅  shim, origin resolved from settings
  app C  ✅  shim, extra frame permission (kit grew a prop for it)
  app D  ✅  shim, region above the frame
  ...
  extension  — DELIBERATE NON-ADOPTION, settled and closed:
               1. buildless vanilla by design; adopting a component
                  framework = a rewrite pretending to be an adoption
               2. side mode is the BROWSER's own panel; the browser
                  draws the container -> chrome inside chrome
               3. docked modes inject into arbitrary third-party
                  pages; cascade styling collides by construction,
                  and inline-everything is CORRECT there
               4. the chrome's defining rule (push, never cover) is
                  IMPOSSIBLE: a content script cannot repack someone
                  else's page
               5. geometry lives in extension storage - a different
                  persistence contract, on purpose

               WHAT IT SHARES ANYWAY: its panel loads the same
               embedded surface as every other app, so embed-side
               improvements reach it with no extension change.
               (Verified: a navigation control landed there free.)

  native apps  — different platform entirely; not a target
  one web app  — the OWNER draws this panel and controls its mode
                 over a message channel; jurisdiction, not a gap

LEGEND, because deployment and adoption differ:
  ✅ has a call site
  ⚙️ vendored only because another shared file imports it
  ⏳ vendored and intended, not yet wired
  —  not a target (reason required)

Exercise

Find a convergence or migration table in your team's documentation and look at every empty cell. For each, determine whether it is unfinished work or a deliberate exclusion. Write the reason into the cells that are deliberate — and for each one, also name the layer at which that participant still shares something.

Hint

Ask the person who owns the excluded component, not the person who owns the table. Table owners tend to read gaps as work remaining; component owners usually know exactly why theirs is different and have simply never been asked to write it down.

One Surface Stays Out

Why the Reasons Have to Be Written

Notice What It Shares Anyway

Code

External links

Exercise

Progress

Comments 0