One build, several protection profiles: namedSets maps file globs to a preset and options, so a checkout flow can ship maximum-mode protection while marketing pages stay on standard — from a single CI run.
Configuration
{
"preset": "balanced",
"namedSets": {
"checkout": {
"match": ["src/checkout/**", "src/wallet/**"],
"preset": "maximum",
"options": { "DeadcodeLevel": "High" }
},
"marketing": {
"match": ["src/marketing/**"],
"preset": "standard"
}
}
}
Each set accepts match (an array of globs supporting **, *, ?, [a-z], and {a,b}), and any of preset, options, and countermeasures.
Resolution rules
- First match wins. A file matched by several sets gets the first listed one; write sets in priority order.
- Baseline survives. Effective options per file are the baseline options, then the set preset’s option block, then the set’s own options.
- Unmatched files are untouched. A file matching no set is protected with the baseline configuration, byte-for-byte the same as a build without
namedSets.
How it runs
Each named set becomes its own API round. The JSON summary reports the grouping under namedSetGroups, the protection manifest spans every group, and when rounds return separate reports the summary carries buildIds for all of them. Because the plan gate prices each round on the options it actually carries, a set your plan cannot afford fails only its own group with the normal API error.
Where this sits among the granularity controls
namedSets — different profiles per part of the app (this page).- @virtualize markers — VM bytecode protection per function.
protectMarkedComments — protect only marked regions of a file.- VariableExclusion and
ReservedStrings — pattern-scoped carve-outs inside any profile.