No React/Vue satisfiedBy guidance for the 58 frontend laws

[ruleofcodedev]

The 58 laws with stack: "frontend" run on any frontend project — Angular, React, Vue,
Ionic. Their satisfiedBy guidance is written only for Angular (satisfiedBy.angular,
67 laws). A React or Vue team is told the law applies to them and then handed OnPush,
standalone components and NgRx.

This is a gap in what we have authored, not a bug in the data. See #11 for why renaming
the key would be the wrong fix.

What "done" looks like

For each frontend law, a satisfiedBy.react / satisfiedBy.vue entry written the way
the Angular ones were: after reading the detector, describing what actually makes the
check pass in that framework. Not a paraphrase of the Angular text with the nouns
swapped.

Two things to hold to:

• Never invent. A plausible-sounding instruction that does not actually satisfy the
  detector is worse than an absent one — it sends people to change code for nothing.
• Where a law's concern has no React/Vue equivalent, say so explicitly rather than
  inventing an analogue. Some of these 58 will legitimately have nothing to say outside
  Angular, and that belongs in detectionLimits.

Good first contribution for someone who works in React or Vue daily: pick one law, read
its detector, write the entry, prove it against a real project.

[ruleofcodedev]

Adding scope and a working method, now that #11 has settled the schema question.

The shape of the work

58 laws carry stack: "frontend". By category:

category	laws
FRAMEWORK	30
PERFORMANCE	9
CODE_QUALITY	6
ACCESSIBILITY	5
TESTING	4
SECURITY	3
DOCUMENTATION	1

The split between "portable" and "Angular-only" cannot be made from the titles.
A quick pass by name suggests 23 are obviously Angular (OnPush, Signals, NgRx,
Standalone) and 35 look portable — but that estimate is already wrong in both
directions: Inject Over Constructor DI and No Subscribe In Effect are
Angular-specific and match no such keyword, while an "Angular"-sounding law may
express a concern every framework shares. The answer comes from the detector, not
the title.

How an entry gets written

Per law, in this order:

1. Read the detector. What does it actually scan for — a decorator, a file
   pattern, a config key, an import?
2. Decide honestly whether the concern exists in React/Vue. Some will have no
   equivalent. That belongs in detectionLimits as an explicit statement, not in an
   invented satisfiedBy.react.
3. Where it does exist, write what actually makes the check pass in that
   framework — verified against a real project, not paraphrased from the Angular
   text with the nouns swapped.
4. Prove it. If following the instruction does not clear the violation, the
   instruction is wrong, however plausible it reads.

The rule this repository applies to rationale and detectionLimits applies here
too: never invent. A plausible-but-false remediation is worse than an absent one
— it sends people to change code for nothing, and it is the exact failure this tool
exists to make impossible.

Schema consequence

satisfiedByStacks.stackToKey is 1:1 today (frontend → angular). Once a second
key exists for the same stack, that field has to express a set rather than a single
key, and the README section documenting it has to follow. That is a schemaVersion
question and will be handled as one, not bolted on.

Sequencing

Category by category, smallest first (DOCUMENTATION, SECURITY, TESTING) so the
method is proven on a few laws before the 30-law FRAMEWORK block. Each batch: read,
write, prove, regression test, PR.

Maintainers are working this — the help wanted label stands because a React or Vue
practitioner will write a better entry than someone porting from Angular, and a
single well-proven law is a genuinely useful contribution.