…redential reach

Two review findings, both on the inputs to the ranking rather than on the ranking
itself — which is where a scoring bug does the most damage, because the number
still looks plausible.

**`FROM` inside a function was read as a table introducer.** `EXTRACT(YEAR FROM
o.created_at)` contributed a table called `o.created_at`, and `TRIM(BOTH ' ' FROM
name)` one called `name`. Table reach is the blast-radius multiplier the whole
ranking rests on, so an invented table both inflates its own row and dilutes every
real one. The fix is keyed on the functions whose grammar actually uses `FROM` as a
separator — extract, trim, btrim/ltrim/rtrim, substring, overlay — rather than
treating every function parenthesis as opaque, because a genuine subquery can sit
inside a function call and the tables it reads are real. Regression cases added for
function syntax, CTEs that read other CTEs, nested subqueries and unions.

**`credential-shared` counted live projects across the whole workspace** and then
clamped to the credential's own project count, so a key shared by three abandoned
projects scored as if all three were live whenever the workspace had three live
projects anywhere in it. The finding now carries the holding project ids and reach
is measured over those.

Also genericises the illustrative project counts in the staleness and scoring
documentation. The figure was drawn from an unpublished internal measurement and
this is a public repository; the principle — reach weighted by liveness can
overstate by close to an order of magnitude — is what the text needed to say, and
it now says that with a round illustrative number instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Scoring credential-shared stopped counting live projects across the whole
workspace, but the shape that made it wrong — reach for the workspace, then
clamp to the finding's own count — is easy to write again for any "N
projects share this" check, and blast radius is the multiplier the whole
ranking rests on.

holderReach is now the only place that turns a finding's project list into
{live, total}. A finding that names no holders is scored as having no live
reach rather than assumed to have some. No scores change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Both of these corrupt the multiplier every other finding is scored by.

`notebookLastTouchedAt` carried an unparseable `modifiedAt` as its baseline,
and every later comparison against it is false — `Date.parse(x) > NaN` never
holds — so a valid execution time could never replace it. A notebook that
ran last week reported as undated. Unparseable values are now skipped rather
than carried.

Notebook ages were keyed by `projectId:name`, and notebook names are not
unique within a project — the same thing already fixed for `notebookCount`
on #557. Two notebooks sharing a name collapsed into one, so the staleness
summary counted one too few and the stale check read one notebook's age for
both, able to report a live notebook as stale or miss a cold one. Ages are
keyed by notebook id now. For findings that record only a notebook name, a
shared name resolves to the project's age rather than to whichever notebook
happened to be read last: which one a finding sits in is genuinely unknown,
and borrowing an answer is how a multiplier stops meaning anything.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The sample declared a 4-project workspace and then reported
`analytics.users — 12 live of 100 projects, 180 SQL blocks` in the table beneath
it. Both numbers were hand-written illustrations, not output, and the sample is
the first thing a reader checks the tool against.

It is now generated from `test-fixtures/workspace-audit`, so every row comes from
the run the header describes. The live-versus-raw illustration moves into the prose
beside it, where it reads as the example it always was.

Regenerating surfaced a second disagreement: the prose claimed both counts are
"always shown", but the renderer collapses them to one when they are equal — which
is what the fixture produces, since no table there has a cold reader. The prose now
says when each form appears.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The ranked list printed `projectName · notebookName || path`, so the path only
appeared when the notebook had no name. One project can hold several `.deepnote`
files — the loader merges them by project id — and two of those files can each
contain a notebook called "Daily". Both findings then printed the same location
string and a reader could act on neither.

Verified end to end rather than argued: two files under one project id produce one
project with two notebooks, both named "Daily", and before this change the two rows
were byte-identical.

The path is now appended only where the readable location repeats among the listed
findings. Printing it on every row would bury the part worth reading under a column
of directories, and the ambiguity is rare.

The grouping key is JSON-encoded rather than joined on a separator, because a
notebook name is arbitrary text and any separator chosen for it is a separator
somebody can type.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…e identity

The `tables` section keyed a table by the name as written, so
`FROM analytics.users` and `FROM users` became two rows with two separate
reach counts — while the join anchors, which already fold to the short name,
treated them as one table. The same tool answered "what is this table" two
different ways in two sections, and reach is the liveness-weighted
multiplier the entire severity ranking rests on, so the split under-counted
and mis-ranked everything downstream of it.

Both now go through `canonicalTableKey`. Folding to the short name globally
would conflate a `users` in one warehouse with a `users` in another, so the
key is scoped by integration: a block's `sql_integration_id`, or an
`unknown` bucket that is never pooled with a declared one.

What integration scoping does not resolve is `analytics.users` and
`staging.users` behind a *single* integration, which still merge. Telling
those apart needs to know which schema an unqualified `users` resolved to,
which is a property of the warehouse search path rather than of the query
text, and merging under-counts rather than invents. Every qualified spelling
observed is kept in `qualifiedNames` so the conflation is visible on the
row, and the text output qualifies a short name with its integration
whenever the same name appears behind more than one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…le notebook

`notebookAges` was keyed by notebook id, which is unique only *within* a
project — while the map spans the workspace. Two projects sharing a
notebook id, which is what forking a project produces, had the later read
overwrite the earlier.

Both consequences lose findings rather than add them: the fork's fresh age
hid the original's `asset-stale` finding entirely, and the maintenance
summary counted one notebook where there were two. `agesByName` was already
project-qualified; this brings the id map in line with it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>