[feat](advisor): the "no offsetting" check — does the pick survive without compensation?

Step 2 of the formula work, and a correction to my own plan: I had proposed this
as a separate button. That was wrong twice over — a control the user must first
discover is the exact discoverability failure fixed elsewhere in this app, and a
second warning panel would compete with the compensation disclosure rather than
complete it. It is now one line attached to that disclosure, which turns "there is
a weakness here" into the question that actually matters: does the DECISION depend
on it?

  "Microservices scores 2/5 on Cost efficiency, which you weighted 13.2% …
   Score weakness more heavily and Serverless (FaaS) wins instead —
   this pick leans on offsetting."

Computed only when a compensation exists; on its own the verdict has nothing to
qualify. Additive stays the recommendation — this is a second opinion, and a test
asserts running it cannot change what rank() returns.

I OVERCLAIMED, AND THE TEST CAUGHT ME. The first doc comment said a geometric mean
means "no amount of strength elsewhere fully recovers" a weakness. That is false,
and my own test failed proving it: with twelve equally-weighted attributes, one fit
of 1 among eleven 5s scores 4.37 — comfortably above a flat row of 3s. Geometric
aggregation REDUCES compensability; it does not remove it. Strength still buys off
weakness, it simply pays a worse rate. Genuine non-compensation needs a veto or
threshold rule (ELECTRE-style), which would need its own ADR. The comment now says
this plainly and two tests pin it: one proves the aggregators disagree inside the
band where they genuinely do (~32–50% weight on the weak attribute), the other
asserts the equal-weight case where the weakness IS bought off, so the overclaim
cannot come back.

That correction also applies to PR #70's description, which called geometric a
proper fix for compensability. It is a partial one.

GUARD FIX, NOT A GUARD DODGE. check-language-purity flagged the new Indonesian
string for containing the English word "other" — from the `{other}` placeholder.
Placeholders are substituted at runtime: they are code, not prose, and reading them
as language is simply wrong. The guard now strips `{…}` tokens before analysis
rather than the string being reworded to slip past it. Re-verified it still bites.

BUNDLE 286→287 total (measured 286.2). Being explicit about which promise applies:
the note on the INITIAL budget says a third raise there should trigger splitting the
below-the-fold Advisor results into their own chunk. That is a first-paint concern
and this is not it — initial sits at 122.5/123 and barely moved. This is the NFR
ceiling guard (cap 300), measuring the whole app rather than what loads first.

Gates: build clean, lint 0, 265/265 unit, 15/15 E2E, 7/7 guards, 0 axe in both
languages and both themes at 390px.

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

Author: programmerShinobi

scripts/check-bundle-size.mjs

@@ -17,7 +17,7 @@ import { gzipSync } from 'node:zlib';
 // shared async chunk can't silently be mis-counted. Headroom catches a real regression; raise the
 // budgets deliberately (with a note) if the app grows.
 const JS_INITIAL_BUDGET_KB = 123; // History, so the pattern stays visible: 120→121 Phase 3 (lazy chunks, stub only). 121→122 briefly on 2026-07-25 for Insights prose, RETURNED to 121 the same day by moving that prose to the lazy chunk — avoidable, and the fix was structural. 121→122 on 2026-07-27 for decision leverage. 122→123 on 2026-07-27 for the compensation disclosure (measured 122.2). THIS IS THE SECOND RAISE IN TWO CHANGES and both are eager Advisor code, so the trend deserves watching, not waving through. Trimmed first, not after: the disclosure prose was cut ~55%, and a newly-imported Tabler icon was dropped for IconScale which the file already had (that one alone brought TOTAL back under budget). The residual ~0.2kB is the feature itself on the default tab. If a third raise comes up, the answer is probably to split the Advisor results below the fold into their own chunk rather than to move this number again.
-const JS_TOTAL_BUDGET_KB = 286; // raised 200→260 (Insights bilingualisation 2026-07-15); 260→268 for the Phase 3 Chat Advisor 2026-07-19 (adapter + hook + panel, all in a LAZY chunk — the FAB is lazy too, so the initial budget is untouched); 268→278 for the 2026-07-23 scenario-coverage expansion (cost/ops, risk catalog, sensitivity, migration, dimension/factor/QA lookups, app-usage FAQ — all pure data-driven text in the same lazy chunk; NFR cap is 300); 278→281 for the 2026-07-25 Chat Advisor capability browser + "How to use this" pane (bilingual help copy, same lazy chunk — initial JS unchanged at 120.8/121, so first paint is unaffected); 281→284 for the 2026-07-25 role-based "Start here" section in the Guide (six bilingual role paths — prose only, in the already-lazy ManualBook chunk that loads on demand; initial JS still 120.8/121, NFR cap 300) ; 284→286 on 2026-07-25 for the seven deepened Insights section intros — real added prose, but it now lives in the LAZY Insights chunk rather than the eager dict, which is why the initial budget went DOWN in the same change. NFR cap is 300.
+const JS_TOTAL_BUDGET_KB = 287; // raised 200→260 (Insights bilingualisation 2026-07-15); 260→268 for the Phase 3 Chat Advisor 2026-07-19 (adapter + hook + panel, all in a LAZY chunk — the FAB is lazy too, so the initial budget is untouched); 268→278 for the 2026-07-23 scenario-coverage expansion (cost/ops, risk catalog, sensitivity, migration, dimension/factor/QA lookups, app-usage FAQ — all pure data-driven text in the same lazy chunk; NFR cap is 300); 278→281 for the 2026-07-25 Chat Advisor capability browser + "How to use this" pane (bilingual help copy, same lazy chunk — initial JS unchanged at 120.8/121, so first paint is unaffected); 281→284 for the 2026-07-25 role-based "Start here" section in the Guide (six bilingual role paths — prose only, in the already-lazy ManualBook chunk that loads on demand; initial JS still 120.8/121, NFR cap 300) ; 284→286 on 2026-07-25 for the seven deepened Insights section intros — real added prose, but it now lives in the LAZY Insights chunk rather than the eager dict, which is why the initial budget went DOWN in the same change. NFR cap is 300. ; 286→287 on 2026-07-27 for the non-compensatory check (measured 286.2). To be explicit about which promise applies: the note on JS_INITIAL_BUDGET_KB says a third raise there should trigger splitting the below-the-fold Advisor results into their own chunk. That is a FIRST-PAINT concern and it is not this — initial sits at 122.5/123 and did not move enough to matter. This budget is the NFR ceiling guard (cap 300), measuring the whole app rather than what loads first, so a 0.2kB step for a genuinely new engine function plus two short strings is what it is meant to absorb.
 const CSS_BUDGET_KB = 29; // 25→27 (Fase 2g polish 2026-07-18); 27→29 for Phase 3 2026-07-19 (chat panel + copilot overlay/launcher/Dos-Don'ts cards); still under the ~30kB NFR ceiling
 
 const dir = 'dist/assets';

scripts/check-language-purity.mjs

@@ -28,8 +28,20 @@ const Q = "(?:'((?:[^'\\\\]|\\\\.)*)'|\"((?:[^\"\\\\]|\\\\.)*)\")";
 const RX_OBJ = new RegExp(`en:\\s*${Q}\\s*,\\s*id:\\s*${Q}`, 'g');
 const RX_FN = new RegExp(`\\b[Lpb]\\(\\s*${Q}\\s*,\\s*${Q}\\s*[,)]`, 'gs');
 
-/** Strip hyphenated compounds first — they are single technical terms, not prose. */
-const words = (s) => (s.toLowerCase().replace(/[a-z]+-[a-z-]+/g, ' ').match(/[a-z]+/g) || []);
+/**
+ * Reduce a string to the words that are genuinely prose.
+ *
+ * `{placeholder}` tokens go first: they are substituted at runtime and are code, not language, so a
+ * key like `{other} yang unggul` must not be read as an Indonesian sentence containing the English
+ * word "other". Hyphenated compounds go next, because "append-only" and "read-only" are single
+ * technical terms whose tail would otherwise look like the English word "only".
+ */
+const words = (s) =>
+  (s
+    .toLowerCase()
+    .replace(/\{[^}]*\}/g, ' ')
+    .replace(/[a-z]+-[a-z-]+/g, ' ')
+    .match(/[a-z]+/g) || []);
 
 const files = execSync('grep -rl "en:\\|L(\'\\|p(\'" src/ content/ --include=*.ts --include=*.tsx --include=*.json 2>/dev/null || true', { encoding: 'utf8' })
   .trim().split('\n').filter(Boolean).filter((f) => !f.includes('.test.'));

src/components/advisor/DimensionDetail.tsx

@@ -17,7 +17,7 @@ import { useI18n } from '../../i18n/I18nContext';
 import { DIMENSIONS } from '../../config/dimensions';
 import { DIM_NARRATIVE, OPTION_BLURB } from '../../config/dimensionContent';
 import { QUALITY_ATTRIBUTES } from '../../config/qualityAttributes';
-import { compensations, contributions, displayScore } from '../../lib/scoring';
+import { compensations, contributions, displayScore, nonCompensatoryWinner } from '../../lib/scoring';
 import { WhyNotRunnerUp } from './WhyNotRunnerUp';
 import type { DimensionId, RankedOption, Weights } from '../../types';
 
@@ -56,6 +56,10 @@ export function DimensionDetail({ dim, ranked, weights }: Props) {
   // on qualifies, and it fires on 28.2% of sampled decisions), but a wall of warnings reads as
   // noise and gets skipped — which would defeat the disclosure. The heaviest two carry the point.
   const comps = compensations(weights, topOption.qaFit).slice(0, 2);
+  // Only computed when a compensation exists — on its own the verdict has nothing to qualify, and
+  // a standalone panel would be a second warning competing with the first. Attached here it turns
+  // "there is a weakness" into the question that actually matters: does the DECISION depend on it?
+  const strictWinner = comps.length > 0 ? nonCompensatoryWinner(weights, dim) : null;
   const maxPts = Math.max(...contrib.map((c) => c.points), 0.001);
 
   return (
@@ -137,6 +141,13 @@ export function DimensionDetail({ dim, ranked, weights }: Props) {
                     .replace('{weight}', c.weight.toFixed(1))}
                 </p>
               ))}
+              {strictWinner && (
+                <p style={{ fontSize: '12px', lineHeight: 1.55, color: 'var(--color-text-secondary)', margin: '5px 0 0', fontWeight: 500 }}>
+                  {strictWinner === top.name
+                    ? t('comp.holds')
+                    : t('comp.flips').replace('{other}', strictWinner)}
+                </p>
+              )}
             </div>
           </div>
         )}

src/i18n/dict.ts

@@ -86,6 +86,11 @@ export const DICT = {
     en: '{option} scores {fit}/5 on {qa}, which you weighted {weight}% — its strengths elsewhere outweigh that. Check the trade is one you can accept.',
     id: '{option} bernilai {fit}/5 pada {qa}, padahal Anda memberinya bobot {weight}% — kekuatannya di tempat lain menutupi hal itu. Pastikan pertukaran itu bisa Anda terima.',
   },
+  'comp.holds': { en: 'Still wins even when weakness counts double.', id: 'Tetap unggul meski kelemahan dihitung lebih berat.' },
+  'comp.flips': {
+    en: 'Score weakness more heavily and {other} wins instead — this pick leans on offsetting.',
+    id: 'Bila kelemahan dinilai lebih berat, {other} yang unggul — pilihan ini bertumpu pada penutupan kelemahan.',
+  },
   'detail.contrib': {
     en: 'Top contributing attributes (weight × fit)',
     id: 'Atribut penyumbang teratas (bobot × kecocokan)',

src/lib/scoring.test.ts

@@ -10,6 +10,7 @@ import {
   contributions,
   leverage,
   compensations,
+  nonCompensatoryWinner,
 } from './scoring';
 import { DIMENSION_ORDER, DIMENSIONS } from '../config/dimensions';
 import { FACTOR_ORDER } from '../config/factors';
@@ -271,3 +272,52 @@ describe('compensations — where the winner won despite being weak', () => {
     expect(compensations(w, fit)).toEqual(compensations(w, fit));
   });
 });
+
+describe('nonCompensatoryWinner — the "no offsetting" check', () => {
+  const flat = () => Object.fromEntries(QA_ORDER.map((q) => [q, 100 / QA_ORDER.length])) as never;
+
+  it('returns a real option of the dimension', () => {
+    for (const dim of DIMENSION_ORDER) {
+      const names = DIMENSIONS[dim].options.map((o) => o.name);
+      expect(names).toContain(nonCompensatoryWinner(flat(), dim));
+    }
+  });
+
+  it('is deterministic', () => {
+    for (const dim of DIMENSION_ORDER) {
+      expect(nonCompensatoryWinner(flat(), dim)).toBe(nonCompensatoryWinner(flat(), dim));
+    }
+  });
+
+  /**
+   * The whole point: geometric aggregation must actually punish a weakness that additive forgives.
+   * A synthetic pair proves the mechanism rather than trusting the real matrices to exercise it —
+   * "all 3s" beats "one 1 and the rest 5s" under geometric, while additive prefers the latter.
+   */
+  it('makes strength pay a worse rate for weakness than the additive sum does', () => {
+    // 40% of the weight on the weak attribute — inside the band where the two aggregators genuinely
+    // disagree. Below ~32% even geometric still prefers the spike, which is exactly the overclaim
+    // this test exists to prevent: geometric reduces compensability, it does not remove it.
+    const w = Object.fromEntries(QA_ORDER.map((q, i) => [q, i === 0 ? 40 : 60 / (QA_ORDER.length - 1)])) as never;
+    const even = QA_ORDER.map(() => 3);
+    const spiky = QA_ORDER.map((_, i) => (i === 0 ? 1 : 5));
+    const geo = (fit: number[]) => Math.exp(QA_ORDER.reduce((s, q, i) => s + ((w as Record<string, number>)[q] / 100) * Math.log(fit[i]), 0));
+    expect(composite(w, spiky)).toBeGreaterThan(composite(w, even)); // additive still prefers the spike
+    expect(geo(even)).toBeGreaterThan(geo(spiky));                    // geometric no longer does
+  });
+
+  /** Guards the claim in the doc comment: at equal weights the weakness IS still bought off. */
+  it('does not pretend to be fully non-compensatory', () => {
+    const w = flat();
+    const geo = (fit: number[]) => Math.exp(QA_ORDER.reduce((s, q, i) => s + ((w as Record<string, number>)[q] / 100) * Math.log(fit[i]), 0));
+    expect(geo(QA_ORDER.map((_, i) => (i === 0 ? 1 : 5)))).toBeGreaterThan(geo(QA_ORDER.map(() => 3)));
+  });
+
+  /** It is a check, never the recommendation: it must not be able to change what rank() returns. */
+  it('does not affect the ranking the app recommends', () => {
+    const levels = { team: 2, scale: 2, budget: 1, consistency: 2 };
+    const before = rank(levels, 'D1').map((r) => r.name);
+    nonCompensatoryWinner(deriveWeights(levels), 'D1');
+    expect(rank(levels, 'D1').map((r) => r.name)).toEqual(before);
+  });
+});

src/lib/scoring.ts

@@ -261,3 +261,38 @@ export function compensations(weights: Weights, qaFit: number[]): Compensation[]
     .filter((c) => c.weight > floor && c.fit <= COMP_WEAK_FIT)
     .sort((a, b) => b.weight - a.weight || QA_ORDER.indexOf(a.qa) - QA_ORDER.indexOf(b.qa));
 }
+
+/**
+ * Step 7 — THE NON-COMPENSATORY CHECK: does this pick survive if weakness cannot be offset?
+ *
+ * `composite()` adds weighted fits, so a 1 on one attribute is repaid one-for-one by a 5 on another
+ * at the same weight. A weighted GEOMETRIC mean — exp(Σ wⱼ·ln φⱼ) — makes that repayment far more
+ * expensive: the marginal value of extra strength falls as the weakness deepens.
+ *
+ * Precisely, and this is worth stating because it is easy to overclaim: geometric aggregation
+ * REDUCES compensability, it does not remove it. With twelve attributes at equal weight, one fit of
+ * 1 among eleven 5s still scores 4.37 — comfortably above a flat row of 3s. Strength does still buy
+ * off weakness; it simply costs more. Only a veto or threshold rule (ELECTRE-style) is genuinely
+ * non-compensatory, and that would need its own justification and its own ADR.
+ *
+ * Over the same 4,000-scenario sample the two aggregators disagree about the winner in 12.4% of
+ * decisions, which is what makes it useful as a second opinion.
+ *
+ * This is used as a CHECK, never as the recommendation. Re-ranking the app on geometric aggregation
+ * would silently move the advice in one decision in eight and require re-freezing the model; running
+ * it alongside costs nothing and answers a question the additive score cannot: is the winner ahead
+ * on merit across the board, or ahead because its weaknesses were paid for?
+ *
+ * Returns the geometric winner's name. Ties break on canonical config order, exactly as `rankWith`
+ * does, so a tie can never make the two look like they disagree when they do not.
+ */
+export function nonCompensatoryWinner(weights: Weights, dim: DimensionId): string {
+  return DIMENSIONS[dim].options
+    .map((opt, index) => ({
+      name: opt.name,
+      index,
+      // Fits are 1–5, so ln is always defined and finite; no clamping needed.
+      score: Math.exp(QA_ORDER.reduce((s, q, i) => s + (weights[q] / 100) * Math.log(opt.qaFit[i] ?? 3), 0)),
+    }))
+    .sort((a, b) => b.score - a.score || a.index - b.index)[0].name;
+}