Preset assistant preview

How provider-backed preset suggestions improve on this

The rule-based mapping catches obvious keywords and produces a reasonable starting config, but it does flatten nuance. Three concrete examples of what provider-backed review can do differently:

• "Protect the license-check function strongly." Rule-based version sets FlatTransform: true globally. Provider-backed review asks for the function name (or infers it from the surrounding description) and recommends an @virtualize marker on just that function, leaving the rest of the bundle on balanced — smaller output, faster runtime.
• "Performance matters most." Rule-based version drops to a standard preset. Provider-backed review reads the rest of the description (is it a marketing widget or a payment flow?) and chooses between standard and balanced accordingly, naming the trade-off out loud.
• Ambiguous descriptions — "obfuscate my JavaScript." Rule-based version defaults to balanced. Provider-backed review asks what frameworks you use, how performance-sensitive your hot paths are, and what code is high-value, then produces a config informed by the answers.

The promise of provider-backed assistance is honest reasoning about trade-offs, not just keyword matching. The rule-based preview is useful for quick starts; the deeper feature is the conversation.

What to do with the generated config

Treat the output as a first draft with the right shape, not a finished profile. Three things are worth doing before it goes anywhere near a release:

1. Validate it. jso-protector --config jso.config.json --validate-config --json catches malformed fields and option-name typos before a build job does.
2. Add your exclusions. No generator can know which of your names cross a boundary — API field names, storage keys, template bindings, public entry points. That list comes from you, and it is the part that decides whether the protected build works. Start from the variable exclusion list.
3. Run it against a representative sample rather than your whole bundle, and smoke test the result. A profile that is correct in principle and wrong for one unusual construct in your code is discovered here or in production; here is cheaper.

Then commit the config. The value of a generated starting point is lost if it lives in a browser tab — once it is in the repository it becomes reviewable, and the exclusions accumulate in one place where the next person can see why each is there.

Why this preview runs locally

The description you type here is a fairly precise account of your architecture: what you built, which frameworks you use, and which parts you consider valuable enough to protect. That is not source code, but it is not nothing either.

So the preview keeps it in your browser. The rule engine is deterministic, small enough to ship to the page, and produces the same answer the server-side endpoint produces in preview mode — which means you can evaluate whether this is useful before deciding anything about keys, accounts or data handling. If you later enable provider-backed suggestions, that becomes an explicit choice with its own documented data handling, rather than something that happened because you typed into a box.

Frequently asked questions

What does the local preview generate?

A starter configuration file from a plain-English description of your application. It maps signals in your text onto options using a deterministic rule set, so the same description always produces the same result. The output has the right shape and a defensible set of defaults, which is most of the work of getting started and none of the work of getting it right for your codebase.

Why does this preview run in my browser?

Because of what the input is. A description of your application is a fairly precise account of your architecture: what you built, which frameworks you use, and which parts you consider worth protecting. That is exactly the sort of thing a team should not have to send anywhere to try a configuration generator, so the rule engine is small enough to ship to the page and runs there.

How much should I trust the generated configuration?

Treat it as a first draft with the right shape rather than a finished profile. It is a reasonable starting point derived from a short description, and it has no knowledge of your codebase, your boundaries or your performance budget. Every generated configuration needs review before it goes near a release.

What has to be added before it goes near a release?

Three things. Validate it, which catches malformed fields and option-name typos before a build job does. Add your exclusions, because no generator can know which of your names cross a boundary, and API field names, storage keys, template bindings and public entry points all do. And run it against a representative sample rather than your whole bundle, then smoke test the result, since a profile that is right in principle can still be wrong for one file.

How does provider-backed suggestion differ from the rule engine?

It reasons about trade-offs instead of matching keywords. Asked to protect a licence check strongly, the rule engine turns on a heavy transform everywhere; a provider-backed review asks which function and scopes the setting to it. Told that performance matters most, the rule engine drops to a standard preset; a review reads the rest of the description to work out what kind of application is being described before deciding what to trade. Where a description is genuinely ambiguous, it asks.

Where should the configuration end up?

In your repository, committed alongside the code it protects. The value of a generated starting point is lost if it stays in a browser tab, because a configuration in version control is reviewable, diffable and reproducible, and the questions people ask about a release six months later are questions about what the configuration was at the time.