gmgn-contract-dd: reconcile four live rules the reword left inconsistent

Step 6 still told the reader to print the section weights while Step 8 and
Display Templates both forbid printing coverage and weights, so the same
response could ship two different report shapes depending on which sentence
was read last. Step 5B's rug_ratio cap table still named the pre-reword band
("high risk") in a live rule, which also falsified the neighbouring claim that
every live occurrence had been corrected — that count is now three, with the
grep procedure that found the last one written down. Step 8's cap list named
Step 2, 5B and 7 but not Step 3's EVM lock cap, which the assembly list in
Step 6 already carries.

No threshold, weight or band boundary moves; every measured score in the file
is unchanged. Dated measurement passages keep the original audit vocabulary by
the policy stated in the file — all 32 remaining occurrences were classified
and every one of them is a record of a run, not a rule.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

skills/gmgn-contract-dd/SKILL.md

@@ -373,7 +373,7 @@ So **do not stop at the first row that matches the address — stop at the first
 
 | `rug_ratio` | Effect |
 |---|---|
-| ≥ 0.50 | **cap the composite at 59** — "high risk" |
+| ≥ 0.50 | **cap the composite at 59** — lands in `not advised` |
 | 0.30 to 0.50 | **cap at 79** — withholds `buyable` |
 | < 0.30 | no cap |
 | **key absent from every matching row** | **no cap — but this is unavailable, not a measured 0** |
@@ -399,7 +399,7 @@ Base weights: **contract 0.45, holders 0.35, price 0.20.** They sum to 1.
 
 **Clamp every section score to 0-100 before weighting, and clamp the composite to 0-100 after.** The deductions in Steps 3, 4 and 5 can exceed 100 within one section — the eight `stat` checks alone total −117 if every one of them fires — and an unclamped section drags the composite below zero, which is not a value this scale has any meaning at. A section that has run out of points is at 0; it does not go on to subtract from the other sections' evidence. The lowest score measured across the 14-address battery is 58.7, so this clamp does not change any published number; it bounds a token worse than anything measured.
 
-**Renormalize over the sections that actually returned data.** Drop any section whose inputs were entirely unavailable, then divide each surviving weight by the surviving total. With price dropped, contract and holders become 0.5625 and 0.4375. Print the weights you actually used.
+**Renormalize over the sections that actually returned data.** Drop any section whose inputs were entirely unavailable, then divide each surviving weight by the surviving total. With price dropped, contract and holders become 0.5625 and 0.4375. **The weights are internal to the score and are never printed** — Step 8 item 2 keeps them out of the report along with coverage.
 
 Then, in this order:
 1. **Collect every cap that applies — Step 2, Step 3, Step 5B and Step 7 — and take the lowest.** Step 2 can contribute 79 (missing `is_honeypot`, missing `is_open_source`); Step 3 contributes 79 when an EVM token's LP is not locked; Step 5B contributes 79 or 59 from `rug_ratio`; Step 7 contributes 59 when it downgrades a honeypot flag. An earlier version of this list named only Step 2's caps, which left the others with no place to be applied — a downgraded honeypot, or a token GMGN labels a rug, would have kept its raw composite.
@@ -480,7 +480,7 @@ The third was `structure intact · structural defect present · structural risk
 
 So the band word answers the question that was actually asked, on one axis, in four steps. The profile clause beside it then names what is in the way, which is what makes the pair complete: how buyable from the word, why not more so from the clause. Note what this does **not** license: the band word is not permission to size a position — sizing is `gmgn-token-buy`'s job, and `What to do` still carries the timing, the mechanism of loss and the caveats.
 
-The band boundaries — 80, 60, 40 — never moved through any of the three rewordings, so **no composite in this file changes grade**; only the words on the line change. **Dated passages throughout this file still quote the original audit words, and are left as written** — they are records of runs that happened, not live rules, and rewriting a past run's printed output would falsify the record. They map onto the table above one-for-one, so any occurrence decodes: `relatively clean` = `buyable`, `mixed / needs manual review` = `buyable with conditions`, `high risk` = `not advised`, `very high risk` = `do not buy`. **A live rule must never name a band in the old vocabulary** — two did, at Step 5B's rationale and in the absent-field list above, and both were corrected when this table landed.
+The band boundaries — 80, 60, 40 — never moved through any of the three rewordings, so **no composite in this file changes grade**; only the words on the line change. **Dated passages throughout this file still quote the original audit words, and are left as written** — they are records of runs that happened, not live rules, and rewriting a past run's printed output would falsify the record. They map onto the table above one-for-one, so any occurrence decodes: `relatively clean` = `buyable`, `mixed / needs manual review` = `buyable with conditions`, `high risk` = `not advised`, `very high risk` = `do not buy`. **A live rule must never name a band in the old vocabulary** — three did, at Step 5B's rationale, in Step 5B's `rug_ratio` cap table, and in the absent-field list above, and all three were corrected. The table row was the last one found, by grepping the file for every old band word and classifying each hit as a dated record or a live rule; do that grep again after any future reword.
 
 **"Buyable" means "no measured red flag among the fields this skill reads, and no rug label from GMGN" — it still does not mean "not a rug", and the report must not imply that it does.** The scored rows alone did not carry this: measured 2026-08-28 on ten tokens carrying `rug_ratio >= 0.5`, three scored ≥80 and none scored below 60. Step 5B's cap is what closes that, and it closes it by refusing a verdict rather than by measuring the contract better — the underlying reason is still true, that the rows firing hardest on labelled rugs are the price ones, which detect a token that has already dumped rather than one about to. A token with no rug label and a young chart can still score in the eighties on nothing but the absence of findings. Say the grade as what it is.
 
@@ -509,7 +509,7 @@ Report in this order:
 3. Every deduction, in prose, inside the section it belongs to, plus one summary line per section under `How the score moved`. Print the measured value and what it means for the buyer; never print the field path. The value is not what gets hidden — the label beside it is what changes.
 4. **A field the data source does not supply is not mentioned at all.** Whatever could not be read is handled by the score and by the confidence label, not by a paragraph telling the reader which fields were empty. A gap in GMGN's coverage is not a finding about the token, and printing it manufactures a doubt out of nothing — the report said "the remaining 5% of the lock is unaccounted for" about a chain that reports no burn field whatsoever. This covers both the not-applicable fields (a Solana token has nothing to say about `is_honeypot`) and the fields the chain simply never populates (`burn_status` and `pool.initial_liquidity` on the EVM chains). Where such a gap disables a scoring row, the answer is the compensatory tightening in that row — Step 3's EVM lock rule is the worked example — never a disclosure. Never write an absence as a measured zero either: a row that could not be scored is silent, not clean. **The one exception is the nine held-out `stat` checks**, whose plain sentence in item 2 above still ships: that block is missing per token rather than per chain, so it says something about this token's evidence rather than about GMGN's coverage of the chain.
 5. **Reported-not-scored findings, only when they are actually findings.** The two `dev` X fields are quoted under `Who launched it` when non-empty, described as history of the linked X account rather than of this token; when both are empty they are dropped rather than reported as empty. A `[filtered]` string, or a `neutralized … suspicious metadata` notice on stderr, is **always** reported in its own sentence and may never be dropped for brevity.
-6. Any cap that applied and what caused it, under `How the score moved` — a missing check (Step 2), the `rug_ratio` band (Step 5B), or a downgraded honeypot flag (Step 7). When none applied, say so and give the one-clause reason each did not fire, so the reader knows the composite is a raw weighted value rather than a suppressed one. The rug clause on the sub-score line is mandatory in all three of its phrasings; Display Templates fixes the wording.
+6. Any cap that applied and what caused it, under `How the score moved` — a missing check (Step 2), unlocked LP on an EVM chain (Step 3), the `rug_ratio` band (Step 5B), or a downgraded honeypot flag (Step 7). When none applied, say so and give the one-clause reason each did not fire, so the reader knows the composite is a raw weighted value rather than a suppressed one. The rug clause on the sub-score line is mandatory in all three of its phrasings; Display Templates fixes the wording.
 7. One line stating this is a rule-based read of public on-chain data, not investment advice.
 
 ## Display Templates