feat(seo-data): I7 — compute the score instead of feeling it
/harden has a real scale (SKILL.md:435 — Critique -15, Haute -8, Moyenne -3, Basse -1, clamp [0,100]). /seo had none: every axis was felt, so two runs over identical code could disagree. That is a credibility problem on its own, and /client-handover gates on 17/20 — a wobbling number makes the gate arbitrary. H2 sharpened it: now that drift reports what actually changed, a score moving on its own is visibly noise. The split is the whole point. WHICH findings exist and how severe each is stays the LLM's judgement — irreducible, and I am not pretending otherwise. The arithmetic stops being judgement: same findings in, same score out. Same principle as grouping cannibalisation rows in the engine rather than handing a model 1000 rows to add up. Reuses /harden's scale, /5 into /20, so the family speaks one vocabulary instead of two. Two things it makes real that were prose: - **N/A is not a zero.** R2 (client-rendered on-page) and I1 (unauditable off-page) both mandate excluding an axis and renormalising the rest. Both left that arithmetic to the model. Now the engine does it and refuses to let N/A behave like a zero — verified: all-20 axes with two N/A still yields global 20.0, not a dragged-down mean. - **Prevalence.** affected/sampled shift severity ONE step (>=50% escalates, a single page de-escalates). A defect on 1 of 12 pages is not the defect on 12 of 12, and flattening the two is part of what made the old numbers move. Malformed input is an error, never a silently wrong number — unlike the fetch verbs, a degrade here would mean bad input, not a network fact. Unknown severity and unknown profile both rejected, tested. Verified: hand-checkable arithmetic (haute+moyenne = 100-11 = 89 → 17.8; critique+haute = 77 → 15.4), identical global across repeated runs, weights renormalised to sum 1.0 with two axes N/A. seo-data 155 -> 167 pass, 0 fail; full suite green; shellcheck + py_compile clean.
This commit is contained in:
@@ -898,6 +898,41 @@ FIX: AUTO (<what agent will do>) | USER (<what user must do>)
|
||||
| Competitive position | 5% | 10% | |
|
||||
| Legal compliance | 10% | 5% | |
|
||||
|
||||
**Compute the scores, do not feel them (I7).** Emit your findings, then let
|
||||
the engine do the arithmetic:
|
||||
|
||||
```bash
|
||||
bash ~/.claude/lib/seo-data/fetch.sh score --findings /tmp/seo-findings.json
|
||||
```
|
||||
|
||||
```json
|
||||
{"depth":"FULL","profile":"local",
|
||||
"axes":{"technical":{"findings":[{"severity":"haute","affected":9,"sampled":12}]},
|
||||
"on-page":{"status":"na","reason":"client-rendered (R2)"},
|
||||
"off-page":{"status":"na","reason":"backlinks unauditable (I1)"}}}
|
||||
```
|
||||
|
||||
`profile`: `local` (B2C) | `national` (SaaS/national/content). Severities are
|
||||
`critique|haute|moyenne|basse` — `/harden`'s scale (-15/-8/-3/-1, clamp,
|
||||
then /5 into /20), so the whole skill family speaks one vocabulary.
|
||||
|
||||
**The split matters.** WHICH findings exist and how severe each is stays your
|
||||
judgement — irreducible. The addition is not: same findings in, same score
|
||||
out. Until now every axis was felt, so two runs over identical code could
|
||||
disagree, and `/client-handover` gates on 17/20.
|
||||
|
||||
- `affected`/`sampled` (optional) shift severity ONE step: ≥50% of the sample
|
||||
escalates, a single page de-escalates. A defect on 1 of 12 pages is not the
|
||||
defect on 12 of 12; pretending so is what made the old numbers wobble.
|
||||
- `status: "na"` → the axis is EXCLUDED and the remaining weights are
|
||||
renormalised for you. This is the R2 rule (client-rendered on-page) and the
|
||||
I1 rule (unauditable off-page), finally computed instead of done by hand.
|
||||
**N/A is not a zero** and the engine will not let it behave like one.
|
||||
- `status: "error"` → malformed findings. Fix them; never fall back to
|
||||
eyeballing a number.
|
||||
- Run it twice on the same file before publishing. If the output moved, your
|
||||
findings moved, and that is the thing to explain.
|
||||
|
||||
**Technical axis note:** CWV scored on CrUX field data (75th percentile,
|
||||
real users, from STEP 4) when available; otherwise lab PageSpeed
|
||||
Lighthouse run.
|
||||
|
||||
Reference in New Issue
Block a user