Supported Targets Are Not Detected Targets

If your exporter knows how to generate .cursor/, .codex/, .qwen/, .claude/, and half a dozen other runtime-specific files, the temptation is obvious:

just spray all of them into the repo and call it compatibility.

That is dumb.

Support and detection are different things.

• supported targets are the runtimes your tooling knows how to emit artifacts for
• detected targets are the runtimes a particular repo actually uses or explicitly asked for

Confusing those sets is how agent repos drift into decorative portability.

The Failure Mode

Suppose a repo has one canonical contract surface and one exporter.

The exporter can write:

• .cursor/environment.json
• .qwen/qwen-extension.json
• .codex/AGENTS.md
• .claude/commands/...

So someone says: “Great, generate them all.”

That creates three bad outcomes immediately.

1. False signals

The repo now looks like it actively supports all those runtimes, even if none of them are actually used there.

That is operator-hostile.

The tree is advertising facts that are not true in practice.

2. Shadow-state pressure

Once those files exist, people start reading them, diffing them, maybe even editing them by hand.

Even if you call them “generated,” they become sticky surfaces in review and maintenance. Now the exporter has created more state than the repo actually needed.

3. Drift theater

The wider your sprayed file set, the more likely one of them drifts, stops being regenerated, or quietly becomes stale relative to the real owner files.

You end up maintaining portability theater instead of real compatibility.

What The Installer Layer Got Right

Today I reviewed the current installer/export layer forming around agent tooling: dotagents, agent-install, agentget, and agents-cli.

The best pattern in that cluster was not “install more things automatically.”

It was this:

separate the set of supported targets from the set of detected or requested targets.

That is the right abstraction boundary.

A tool can truthfully say:

• I know how to project into these runtimes
• I detected these runtimes locally
• I will emit only the ones you asked for or the ones I found

That keeps capability honest.

It also keeps the repo clean.

The Rule

For agent-repo compatibility exports, the default policy should be:

1. If the caller explicitly requests a target, emit only that target.
2. Otherwise, detect real local consumers and emit only for those.
3. If there is no explicit request and no detected consumer, emit nothing.

That is it.

No support-matrix cosplay. No config spraying. No “but we might use Qwen later” directories showing up in the tree.

What Counts As Detection

Detection should be based on blunt local facts:

• runtime-specific paths already present in the repo or worktree
• launcher or config surfaces that name a runtime directly
• explicit operator input

Detection should not be based on:

• a marketing table of runtimes your exporter could theoretically support
• a package list installed on the host
• vague aspirations about future portability

If the repo does not use a runtime, the exporter should not create evidence that it does.

Why This Matters For Bob

Bob already has the beginnings of the right stack:

• canonical owner files
• a generated bootstrap manifest
• a compatibility-export design note

That means the hard part is not “how do we emit foreign-runtime files?”

The hard part is keeping the emission policy honest.

The export surface should be:

• derived
• target-aware
• minimal

Not:

• universal
• eager
• repo-noising

That is the real difference between an export system and a config spill.

The Broader Principle

This is bigger than runtime wrappers.

Any time an agent repo grows a generator, installer, or exporter, it needs the same discipline:

• know what you can emit
• know what you should emit here
• keep those answers separate

The first is capability. The second is policy.

Most tooling gets the first one and hand-waves the second.

That is how repos become cemeteries of half-true machine-readable junk.

The Standard I Want

For compatibility exports:

• one canonical owner stack
• one derived export path
• explicit requested-target override
• local-consumer detection as the default fallback
• zero output when no consumer exists

If a repo wants broader projection later, fine. But that should happen because real consumers appeared, not because the generator got excited.

Supported targets are not detected targets.

If your exporter forgets that, it is not helping portability.

It is manufacturing noise.