Multi-page app shells: G8 false-positives + gate-count drift (47 vs 58) make honest stamping awkward

[rz1989s]

Context: first Keystone-gated multi-page app (5-view dashboard, one shared CSS shell) built via check-gates.mjs on omp.

1) G8 fires on every page of a single app. The app legitimately shares one macrostructure (one shell by design). With per-page entries accumulating in .keystone/log.json, every subsequent page fails G8 ("current Index-First matches a prior run") even though this is one application, not consecutive landing-page briefs. I shipped with declared G8 fails on all 5 pages (honesty contract), but an app-shell convention would remove the noise — e.g. a stamp field (mode: app-shell) or log-entry flag that tells the G8/G32 detector these builds share a shell deliberately.

2) Gate count drift: docs say 58, engine reports 47 — or 78. SKILL.md and gates.md consistently say 58 gates; check-gates.mjs on the same page reported 78 checks on a failing run (per-element contrast/states expand into individual rows) and 47 on the passing run. Stamping gates: N/58 is then impossible to do honestly — I stamped 46/47 engine-verified. Suggest: either normalize per-element expansions into aggregate checks in the count, or make the report/stamp use the engine's own total (report.total) and update the docs to say "N/engine-total".

Suggestion: extract-stamp could accept whatever total the engine emitted (keystone-report.json has it) so the stamped score is always engine-true.

[rz1989s]

Second independent build confirms both halves of this issue — plus one new G8 wrinkle.

Gate-count drift (47 vs 58), again: engine v1.1.0 deterministic run reports PASS 47/47 (build mode, all 13 detectors, 5 viewports) while SKILL.md §7.3 and gates.md still say 58. The stamp template hardcodes /58, which can never be honestly filled from a real run. We stamped 47/47 engine-verified · vision: pass — accurate but off-template.

G8 self-collision, new detail: if you write the current build's entry into .keystone/log.json before running the engine (SKILL.md Step 6 says append at build time; Step 7 runs the engine), the diversification detector reads your own entry as a prior run and fails G8 · Macrostructure reuse — current <name> matches a prior run. Workaround: run the engine with an empty log, write the entry after. Either the engine should append its own result post-run (making the ordering unambiguous), or Step 6/7 ordering in the skill needs to say "log after engine".

Context: rextorsec/rextor PR #75 — first keystone run in that project, single log entry, immediate self-collision until the workaround.