When You Can't Read the Source: The Decompilability Test

Convergence mining is not a WordPress trick. It is a property of many independent implementations of the same integration — and a route that matches how readable that ecosystem actually is.

Scott Farrell · LeverageAI · August 2026

The plugin-mining argument landed hard when the corpus was a public directory you could open, compare, and recompile. The honest reader question is the one that remains after that: does the argument survive contact with an ecosystem I cannot just read? Salesforce AppExchange listings, Zapier apps, ERP adapters, browser extensions — most of the connector surface of a real stack is not shaped like WordPress plugins. If the method only works when the source is open, it was a niche trick. If it works because of a deeper property, you need a test for that property and a map of the routes when source is closed.

This piece is a transfer claim. The evidence that convergence mining works was assembled where the corpus is web- and plugin-shaped. The companion piece — AI Doesn't Drive the CMS — It Unbundles It — owns the mechanism in full: why a plugin is a fossilised integration investigation, why you never copy one, the multi-plugin convergence method, the Stripe worked example, the integration-construction hierarchy, evidence-not-authority, and the plugin-to-pattern-bazaar value migration. One short hop there is enough. This article owns only what changes when the connector ecosystem is not web-shaped and not openly readable.

The property was never the platform

The WordPress plugin directory was never the point. The point was many independent implementations of the same integration. When several builders who did not copy each other still converge on the same distinctions — which identifier is authoritative, when a write is final, what must be idempotent — agreement is evidence about the domain, not about one vendor's product taste. One implementation can mislead. A population of independent ones can reveal invariants no single vendor documents cleanly.

That property travels. Any mature connector ecosystem that hosts many solutions for the same join — AppExchange packages, Zapier apps, ERP adapters, browser extensions — carries a latent corpus of solved integration problems. Installable software is the packaging. The AI-era value, when the property holds, is the tuition encoded across the population: what must not be conflated, which failure modes recur, which fields are load-bearing. That is the same value migration that turns a shelf of plugins into a pattern bazaar — complete application code falls in relative value; domain distinctions rise — without requiring the corpus to live on wordpress.org.

Treat the marketplace as a parts-and-priors library. Copy discoveries, not destiny.

Name adjacency only: this is not semantic decompilation — that recovers structured meaning from prose and idea systems. Ecosystem decompilation mines software implementations of integrations for verified invariants. Shared word; different job.

The Decompilability Test

This is what the test gives you: a way to decide, before you commit effort, whether an ecosystem can actually pay you back in evidence. Before you “mine the connectors,” score the candidate ecosystem. The output is a route, not a yes/no verdict.

Score honestly. Different ecosystems land on different routes. The test is useful precisely when it forbids a fantasy of full source-level convergence in a partner-gated binary marketplace.

Three ecosystems, three routes

Named ecosystems below are analysed outside-in from public surfaces — market commentary, not claimed engagements.

Route A — Readable source: browser extensions

Route B — Public schema without source: Zapier apps

Route C — Closed documentary and behavioural evidence: AppExchange (and the ERP family)

Same test, three landings: extensions invite source-level mining; Zapier invites schema-level mining; AppExchange and ERP adapters invite careful documentary and behavioural mining. The method does not vanish. The confidence budget does.

What does not transfer

The rule that still holds everywhere — including when you only have Route C scraps — is the same rule that article defends for plugins: the corpus is evidence, never authority. “Three connectors do X” is a hypothesis. “The current provider contract accepts X under these tests” is a decision. Never reason “a popular listing does it this way, therefore it is correct.” Reason “several specimens suggest this distinction; I will verify it against the live contract and encode a test.”

That posture is the open-source consumption move after regeneration got cheap: reuse commodity contracts; generate the mission-shaped join; do not inherit an alien North Star just to avoid writing code. Platform escape is a related selective question — when configuration-heavy CRM and industry suites stop earning their keep — but it is a different essay; the CRM-shaped version lives with the leverage and escape work.

Worked specimen: HubSpot contact / lead sync

Not Stripe. Payments were that article’s laboratory. Here the domain is the everyday non-web join: push a lead or contact into a CRM without creating duplicates, without double-writing on retry, and without treating soft-delete as hard-delete. Specimens for this domain exist across Zapier CRM apps, CRM browser extensions, and marketing-tool connectors. The table below is not a fabricated multi-plugin survey. It is the invariant/local discrimination you would fill by reading specimens and the current HubSpot contract — then encoding tests. Provider facts are from HubSpot's own developer documentation, fetched for this piece.

Read the table left to right. The middle column is what you might see recurring across Zapier CRM apps and extensions. The right column is what turns a pattern into a decision for this provider. Rows where local choice remains local (conflict policy, which secondary keys) stay out of the adapter's hard-coded “truth” — they belong in config or in the business North Star.

Minimal adapter sketch

The adapter this table implies is deliberately narrow. It is not a HubSpot plugin. It is the join you own:

Intent:  form or intake → one HubSpot contact, no duplicates on retry

Surfaces:
  - HubSpot CRM Contacts API (create / upsert / get-by-email)
  - Local lead record (your id, email, payload, sync_status)

Adapter (one module):
  1. Normalise email; reject empty key
  2. Upsert via batch/upsert idProperty=email
     (or get-by-email then patch/create)
  3. Persist hubspot_id + last_synced_at on local record
  4. Map 429 → backoff queue; never tight-loop
  5. On local "delete" policy: archive remote or leave —
     never assume hard delete

Tests before production:
  - same email twice → one HubSpot contact
  - retry after timeout → still one contact
  - 429 fixture → backoff, no data loss
  - lifecycle field: do not regress stage without explicit clear
  - delete policy fixture matches product decision

That is “buy the capability, own the join” at adapter size. If a connector marketplace sold you a maintained pattern package — domain model, fixtures, threat notes, current API interpretation — you would still run the same verification step. The package is prior. The contract and the tests are authority. And if the provider is not agent-addressable enough to expose state, actions and consequences cleanly, you will feel it here: verification becomes UI theatre instead of a grant the agent can exercise.

Monday morning: score your stack

1. Pick one connector ecosystem you actually depend on (Zapier gallery, AppExchange category, extension store niche, ERP adapter family).
2. Run the four properties. Write the route in one sentence: readable source / public schema / documentary-behavioural only.
3. Name the independence risk out loud. If everything forks one SDK, stop calling it convergence.
4. Pick one provider join (contact sync, invoice push, booking update). List five specimens you can actually open — source, schema pages, or docs.
5. Fill an invariant-vs-local table. Verify every candidate invariant against the live contract. Encode three tests. Generate one narrow adapter. Do not install a general connector “just in case.”

If step 2 lands on a thin or non-independent corpus, or step 5 has no sandbox, you already have the answer: read the vendor docs and build carefully. The method did not fail you. The ecosystem failed the decompilability test — and naming that is how you stay honest.

Any mature connector ecosystem is worth more as a corpus of solved integration problems than as installable software — when agreement is independent, readable by some route, and checkable against a live contract. Score first. Mine second. Verify always.

The companion piece showed the method where the evidence lives. This piece only had to answer whether it generalises — and how you tell. It does, as a property test, not as a promise that every marketplace is a free textbook. When you cannot read the source, you do not abandon the method. You pick the route your ecosystem can actually support, pay the confidence cost in the open, and still leave with a domain-invariant table and one narrow adapter instead of another black-box connector in the stack.