(Discuss) compile-time deploy-safety lint, native to Quasar

[saicharanpogul]

Hey team,

Wanted to surface this as a discussion rather than a PR — happy if the answer is "interesting but not now."

There's a structural advantage Quasar has over Anchor that I don't think is being exploited yet: the IDL is derived from your source AST at compile time. Anchor has to round-trip through target/idl/<program>.json to do anything shape-aware (linting, upgrade-safety checks, schema-version detection). Quasar could run the same lints during quasar build and surface findings as cargo diagnostics — earlier signal, no separate tool to install, no JSON-out-of-tree.

What's already there

I've been working on ratchet, a framework-neutral upgrade-safety + mainnet-readiness lint catalog that operates on a ProgramSurface IR. Two flavours of rule:

• R-rules (16) — diff two builds, fire on changes that would corrupt on-chain state, break callers, or orphan PDAs.
• P-rules (6) — preflight a single build, fire on patterns that make future upgrades materially harder.

solana-ratchet-quasar 0.3.2 parses Quasar's IDL JSON and lowers it into the same IR the Anchor adapter produces, so every rule fires identically. Embedded as a library in QEDGen/solana-skills#20 (merged yesterday) — so the IDL-path integration ships today.

R-rules (diff)                          P-rules (preflight)
R001  account-field-reorder             P001  account-missing-version-field
R002  account-field-retype              P002  account-missing-reserved-padding
R003  account-field-removed             P003  account-missing-discriminator-pin (Anchor-only)
R004  account-field-insert-middle       P004  event-missing-discriminator-pin   (Anchor-only)
R005  account-field-append              P005  account-name-collision
R006  account-discriminator-change      P006  instruction-missing-signer
R007  instruction-removed
R008  instruction-arg-change
R009  instruction-account-list-change
R010  instruction-signer-writable-flip
R011  enum-variant-removed-or-inserted
R012  enum-variant-append (additive)
R013  pda-seed-change
R014  instruction-discriminator-change
R015  account-removed
R016  event-discriminator-change

What native could look like

A Quasar proc-macro / build pass that builds ProgramSurface directly from the AST (skipping the JSON detour), then calls into solana-ratchet-core. Rough shape:

• quasar build runs the rule set against the current source.
• Findings surface as cargo diagnostics — error/warning configurable.
• Diff mode (R-rules) compares against a checked-in quasar.lock snapshot of the last release's surface.
• No external tool, no --quasar flag, no JSON detour. Just part of the build.

Quasar-specific calibration already in place

P003 / P004 are intentionally silenced when solana-ratchet-quasar produces the surface — Quasar requires devs to pin discriminators in source, so flagging the absence of a pin would be a category error. That calibration lives at the framework adapter, not in the core rule engine. If Quasar wanted Quasar-specific rules later (e.g. dynamic-type field ordering, per #141), they'd plug in the same way.

Open questions

1. Would Quasar take a dependency on solana-ratchet-core, or prefer rules vendored in-tree?
2. Failure-mode preference — error by default, warning, #[allow]-able per rule?
3. Anything in the catalog that doesn't make sense for Quasar's model and should be dropped/reshaped at the adapter?
4. Adjacent: Automatic account migration #158 (automatic account migration) is the fix side of the same upgrade-safety story — pair the two as one initiative or keep separate?

Not blocking on a yes — happy to leave this as a discussion. If there's interest I'd be glad to sketch a more concrete proposal.

[L0STE]

Hey @saicharanpogul i agree that this is a really good idea!

We already have something similar currently as Quasar linter; not sure if you had a look at it.

Happy to hear any suggestions on how we can make it better. Probably a vendored solution is better but there is a world where we just use your implementation if it doesn't depend on too many deps and can be a drop in for us

[saicharanpogul]

Thanks @L0STE for sharing — took a look at the existing linter and that clarifies the picture.

L001–L009 cover account-graph integrity at build time. Ratchet's catalog is on a different axis: cross-build upgrade-safety diff (R001–R016) plus a few preflight conventions (P001–P006). Effectively zero overlap. P003/P004 are already silenced for Quasar; P006 is subsumed by your L006. Net-new for Quasar would be the 16 R-rules + P001/P002/P005.

On vendor vs. import — agree vendoring is the cleaner path. Your Diagnostic/LintReport infra is good and the rules slot into it natively. I'd write each rule against ParsedProgram directly rather than through ratchet's IR.

One open subproblem: R-rules need a "last release's surface" to diff against. In ratchet's CLI this is a checked-in ratchet.lock. For Quasar there are a few UX options (quasar.lock.json regenerated on build, quasar lint --diff <git-ref>, tag-based) — happy to defer to whatever fits Quasar's existing patterns.

If it lines up, I can draft a PR scoped to the 19 rules above, returning your existing LintReport shape, with the diff-UX as a follow-on conversation.

[L0STE]

Let's do it!

[saicharanpogul]

Before I start cutting code, four design choices worth settling so we don't spin in PR review:

1. Rule numbering — extend the L-series (L010 onwards) so everything lives under one namespace, or a new prefix to mark the upgrade-safety category (e.g. D for diff, U for upgrade)? My default: extend L-series, since the P-rules are single-build like your existing ones and the R-rules are still lints, just diff-flavoured.

2. Diff-mode UX — for the R-rules. Two shapes: a checked-in quasar.lock.json regenerated by quasar build --update-lock (Cargo-style), or quasar lint --diff <git-ref> that reads the old source from git history and re-parses. Preference?

3. PR shape — one PR with all 19 rules + diff infra, or split into (infra + ~5 rules) first, rest in follow-ons? I lean splitting — easier review.

4. Severity defaults — your L-rules mix Error / Warning. Ratchet's R-rules categorise as Breaking / Unsafe / Additive. Direct map (Breaking → Error, Unsafe → Warning, Additive → info), or tune per rule?

Once these are settled I'll open a draft PR.

[saicharanpogul]

No rush on the four — going to default (extend L-series, lock-file diff, split PR starting with infra + a few rules, direct severity map) and iterate in PR review unless you want to weigh in on any of them.

[L0STE]

Implemented the native Quasar lint surface and in-tree deploy-safety rules in #224, including build integration and the upgrade-safety/preflight rule catalog discussed here. Closing this as resolved by the merged lint/audit work.