@tanqory/dev-mcp 0.1.0-alpha.1 → 0.1.0

package/bundled/theme-conformance/docs/storefront-tier.md

@@ -105,9 +105,9 @@ Status per check: `pass`, `fail`, `warn` (reported, never fails the tier), `not_
 
 **What is approximated (exactly).** Lighthouse is not run: its own navigation would bypass the gateway
 that answers every request in-process. The runner measures in its own Chromium instead:
-- mobile 390×844 DPR 2; CPU slowed 4× (`Emulation.setCPUThrottlingRate`); every response delayed by
-  150 ms + (bytes on the wire × 8 / 1638.4 kbps) by the gateway, text counted gzipped (Lighthouse's
-  "slow 4G" figures applied per response, not a simulated connection pool);
+- mobile 390×844 DPR 2; CPU slowed 4× relative to the **uncontended** host (see "Busy hosts" below);
+  every response delayed by 150 ms + (bytes on the wire × 8 / 1638.4 kbps) by the gateway, text counted
+  gzipped (Lighthouse's "slow 4G" figures applied per response, not a simulated connection pool);
 - FCP, LCP and CLS from `PerformanceObserver`; TBT = Σ(long task − 50 ms) after FCP over load + 3 s;
 - **Speed Index is not measured** (no filmstrip); it is taken as (FCP + LCP) / 2;
 - the score uses Lighthouse's mobile log-normal curves and weights (FCP 10, SI 10, LCP 25, TBT 30, CLS 25);
@@ -116,6 +116,35 @@ that answers every request in-process. The runner measures in its own Chromium i
 
 Both scores are labelled `lab-approximation` in the report and are not Lighthouse scores.
 
+**Busy hosts (host calibration).** `Emulation.setCPUThrottlingRate` slows the renderer relative to the machine
+it runs on, so on a machine whose cores are busy with other work the page is slowed by the throttle *and* by
+the contention: the same theme scored 96–99 on a quiet 6-core host and 76–83 at load 50–240. The runner
+therefore measures and removes the contention instead of letting it count against the theme:
+
+1. *Before* each lab run it times a fixed busy loop in the page's renderer, unthrottled: wall-clock ÷ the main
+   thread's CPU time (`Performance.getMetrics` `ThreadTime`) is the host contention, 1.0 on an idle core. The
+   CDP rate is `4 ÷ contention`, never below 1.
+2. *During* the run it records a `toplevel` trace. Σ wall ÷ Σ CPU time (`dur` / `tdur`) of the renderer main
+   thread's tasks is the contention the measured page actually saw (the throttle burns CPU on that thread,
+   so it cancels out). `effectiveSlowdown = rate × that factor` is the slowdown the page really got.
+3. A run *decides* the verdict when its effective slowdown is 4× within ×1.25 (3.2–5×). A run slowed more
+   than that still proves a **pass** (the theme passed under a harsher device); a run slowed less still
+   proves a **fail**. A run off the target is repeated with the rate corrected by its own measured contention,
+   kept strictly between the highest rate that slowed the page too little and the lowest that slowed it too
+   much (the contention depends on the rate: a heavily throttled renderer burns CPU and is scheduled like a
+   batch job, a lightly throttled one stays interactive, so a plain correction can overshoot the band).
+4. One run per page is enough when it decides and is ≥ 5 points from the budget; otherwise up to four.
+   The page score is the lower median of its deciding runs; the check is the minimum over the pages.
+5. If a page has no deciding run (every run was over-slowed and below 85, or under-slowed and above it) and
+   no decided page failed, `budgets:performance` is **`warn`** with `inconclusive: this host was too busy…`
+   and the measured factors — not a failure, and not a pass of the theme. Re-run on a quieter machine.
+
+On a quiet host the contention is ~1.0, the rate stays 4× and the result is what it was before calibration.
+The busy-loop is not an absolute reference device: throttling stays relative to the machine's own idle
+speed, as before, so a quiet fast machine and a quiet slow one judge a theme exactly as they did. Every run's
+`hostFactor`, `cpuRate`, `windowFactor` and `effectiveSlowdown` is in the check's `evidence.details.pages[].runs`,
+and the maxima in the `performanceScoreMobile` measurement note.
+
 ## 4. Locale-key patterns (the semantic fallback)
 
 When no hook is present, a control is a button/link (by ARIA role) whose accessible name equals one of the

package/bundled/versions.json

@@ -1,6 +1,6 @@
 {
   "@tanqory/theme-abi": "2.0.0-alpha.14",
-  "@tanqory/theme-conformance": "0.1.0-alpha.14",
+  "@tanqory/theme-conformance": "0.1.0-alpha.15",
   "@tanqory/theme-kit": "2.0.0-alpha.3",
   "examples": {
     "blank": "create-tanqory-theme templates/blank"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tanqory/dev-mcp",
-  "version": "0.1.0-alpha.1",
+  "version": "0.1.0",
   "description": "Local MCP server (stdio) for building Tanqory storefront themes with coding agents: versioned docs and schemas, kit examples, section scaffolding, theme checks, and pages and screenshots of the running dev server.",
   "keywords": [
     "tanqory",
@@ -43,7 +43,7 @@
     "zod": "^3.25.76"
   },
   "devDependencies": {
-    "create-tanqory-theme": "0.2.1"
+    "create-tanqory-theme": "0.2.3"
   },
   "publishConfig": {
     "registry": "https://npm.pkg.github.com"