Decide whether .scss and .css are worth intercepting

[HackPoint]

What

Lumen does not intercept .scss or .css. Both sit in the efficiency test's uncovered-kind backlog, and their totals are large enough to read as a gap worth closing. The distribution says otherwise: the totals may describe one person's stylesheet rather than a general cost. This is a decision that needs a second measurement, not work to schedule.

Evidence

Measured on the live metering ledger — the database lumen_core::meter::db_path() resolves. The figures are raw builtin_read rows per extension at or above the 300-line interception threshold; the query is in "How to test".

• .scss: 197,295 tokens.
• .css: 63,175 tokens.
• 162,957 of the .scss total (83%) is a single file, SpeedRunnerV2.scss, 3,116 lines, read 11 times on one machine.
• The next largest .scss contributor is 21,667 tokens over 5 reads.

So the aggregate is one person working on one stylesheet. Generalising from it would be a mistake.

The table printed by crates/lumen-mcp/tests/efficiency.rs will not reproduce those totals: it collapses duplicate rows written by the two registered meter hooks, so its .scss total is lower, and it carries no per-file breakdown. Compare corpora on one basis, not across the two.

There are design reasons to hesitate as well. A stylesheet's outline is hundreds of selectors, which is not obviously both smaller and useful. Selector names like &:hover or .a > .b make recall_file(names=[...]) an awkward fit even if the outline were cheap. And an outline that does not answer the question forces the full read anyway, spending the extra interception round for nothing — the failure mode the net-of-round break-even exists to expose.

Acceptance criteria

• For a second, unrelated corpus, both the uncovered-kind table and the per-file .scss query are posted here as printed, with basenames instead of absolute paths.
• For each corpus, on the raw basis above, the share of the .scss total contributed by its single largest file is stated (this corpus: 162,957 of 197,295, 83%).
• A decision — intercept or do not intercept — is recorded as a comment here, citing both corpora, and the issue is closed either way.
• If the decision is not to intercept, .scss and .css stay in the backlog and no interception code lands.

How to test

# 1. The uncovered-kind table, from a lumen checkout.
cd /path/to/lumen
cargo test --release -p lumen-mcp --test efficiency -- --nocapture

# 2. The per-file concentration behind the .scss row, on the same ledger
#    ($LUMEN_DB when set, otherwise the path in ~/.lumen_db_path).
sqlite3 -readonly "$(cat ~/.lumen_db_path)" \
  "SELECT path, count(*) calls, sum(full_tokens) tokens FROM read_events
    WHERE routed_via='builtin_read' AND lines >= 300 AND lower(path) LIKE '%.scss'
    GROUP BY path ORDER BY tokens DESC LIMIT 5;"

# 3. Second corpus: a ledger recorded with LUMEN_DB set while working in another
#    repository that has substantial stylesheets. LUMEN_DB decides both where
#    reads are recorded and which ledger is read.
LUMEN_DB=/path/to/other/lumen.db \
  cargo test --release -p lumen-mcp --test efficiency -- --nocapture
sqlite3 -readonly /path/to/other/lumen.db "<the query from step 2>"

Step 1 prints == Coverage: what leaked, versus what was out of scope ==, ending in a kinds not handled line and up to six per-extension rows with calls and tokens. LEAKED must be 0; the test asserts it. Step 2 names the files behind the .scss row, which the table does not. If one file no longer dominates the second corpus, interception is worth building; if it does, this is one file and a smart_read(mode="full") away from being a non-problem.