Fourteen call sites across twelve detectors spelled their ecosystem's
package-url type as a string literal in the first argument to
sdk.BuildPackageURL. That is a second mapping table -- maintained by
whoever happened to be writing a detector, next to purlkit, which the SDK
calls the one authority for this mapping (ADR-0038). It is the shape that
minted go4.org as pkg:generic (bomly-sdk#67), and the swift pair is the
standing trap: CocoaPods and SwiftPM share the ecosystem token "swift"
but need the types "cocoapods" and "swift", which only the package
manager distinguishes.

Every site now passes the ecosystem and package-manager values it already
held to sdk.PackageURLTypeForValues. All fourteen emitted types are
unchanged -- verified against the SDK for each site's tokens, in both
argument orders -- so no node ID, OSV match, or SBOM reference moves.

TestDetectorPURLTypesComeFromTheSDK enforces it from here, as a positive
requirement rather than a ban on literals: the first argument must be the
call to the SDK, so lifting a literal into a const does not escape it.
The predicate is pinned on fixtures, because a rule only ever run against
a passing tree is a rule nobody has seen fail.

Closes the last open half of SDK maturity phase 2.1, criterion 3.

Co-Authored-By: Claude Opus 5 <[email protected]>

Codex found a signposted way around it. The guard recognized only
BuildPackageURL, so a detector could call purlkit.Build with a
hand-picked Type and every check stayed green -- and the concatenation
guard three rules down recommends purlkit.Build by name, so this is the
route the file itself points at, not an obscure one.

Reproduced before changing anything: a pub detector minting
pkg:generic through purlkit.Build compiles and passes the whole suite.

The rule now inspects the Type field of a purlkit.PURL literal with the
same positive requirement the mint site carries -- Type must be a
PackageURLTypeForValues call, so hoisting the answer into a const does
not escape it either. The composite literal's type name is checked, not
just the callee, because Build is a common enough name that matching it
alone would report unrelated builders that happen to take a struct.

Four fixtures added, in both directions: a hand-picked Type is reported,
a delegating one is not -- forbidding that would ban the construction the
codebase is being moved onto -- a const-hoisted Type is reported, and an
unrelated Build taking a struct is not.

Mutations: Codex's escape now fails, naming the file and line; dropping
the composite type-name check fails on the unrelated builder.

Co-Authored-By: Claude Opus 5 <[email protected]>

Codex again, and again on my own fix. Watching purlkit.Build's arguments
only saw the shape written inline: assign the literal to a variable first
and the guard read an identifier, found no composite literal, and passed.
Reproduced before changing anything.

Tracing the value was the obvious repair and it is the wrong one. The
type is chosen where the literal is written, not where Build is called,
so the rule keys on purlkit.PURL literals wherever they appear --
inline, assigned, or returned by a helper -- and the hop stops mattering.

My first attempt did trace, conservatively rejecting arguments it could
not read. Its own fixtures caught it reporting a *delegating* value
passed through a variable: wrong in both directions, since it would also
have missed a literal built one file over. The Build branch is gone; the
literal rule alone is shorter and stronger.

Field assignment after construction is covered too. Nothing under
internal/detectors sets a .Type from a literal today, so the rule costs
nothing now and closes the next hop before somebody takes it.

Mutations: the identifier bypass fails; the field-assignment path fails;
a literal branch that stops reading Type fails.

Co-Authored-By: Claude Opus 5 <[email protected]>

Three review rounds found three ways a detector could pick a purl type
through purlkit -- a literal at the call, a literal assigned first, a
field set afterwards -- and each fix added a shape to an AST pattern. A
fourth round found a fourth, which we filed rather than patched. Chasing
shapes was the defect.

Detectors have no business holding purlkit. They ask the SDK for a
package URL; purlkit is where one is built, so holding it is holding the
ability to choose a type by hand in more shapes than a pattern can
enumerate. No detector imports it today, so the rule costs nothing and
closes every shape at once, including the ones nobody has thought of.

Scoped to detectors. internal/sbom, internal/output and internal/auditors
use purlkit legitimately: they read and render package URLs minted
elsewhere, and a minting rule has nothing to say about reading.

The AST rule keeps only what the import ban cannot cover -- a literal
handed to sdk.BuildPackageURL, and a literal handed to the authority
itself -- and loses the two branches that leaked, along with their
helpers. It went from 88 lines to a third of that.

No entitlement was added for this file. It names purlkit in a string and
does not import it, which is exactly the distinction the entitlement
rules already make.

Mutations, all five reported: a literal at the mint site; purlkit.Build
inline; the same through a variable; a field set after construction; and
a type taken from a const, which is the gap #449
records as needing go/types. It needs no type information at all once the
import is gone.

Co-Authored-By: Claude Opus 5 <[email protected]>