[edit] A prose-description edit never re-grades the score — descriptionOverrides is missing from the score memo's dep list

[s-annam]

Problem

Editing a role's or project's prose description on / changes the exported résumé but
does not re-grade the score. The edit folds into editedCore, but the score memo in
src/hooks/useAnalyzedResume.ts does not list descriptionOverrides as a dependency, so
it never re-runs for that channel.

descriptionOverrides writes experience[].description, and src/lib/score/score.ts
(computeAnonymousAtsScore) uses exactly that field as the bullet-pool fallback for
glyph-less résumés:

if (extractExperienceSectionBullets(input.sections).length === 0) {
  bullets.push(...poolExperienceDescriptions(input.parsed.experience));
}

So on a Word / Google-Docs-Skia style résumé whose Experience section yields no marker
bullets, the description is the graded pool — and editing it silently grades the
pre-edit text.

Repro

1. Load a glyph-less-prose résumé on / (an Experience section with no • markers).
2. Edit a role description through the reconstructed résumé.
3. Observe the score object is identical — overall stays at its pre-edit value.
4. Touch any other scoring channel (a skill, the summary, a contact field) — the score
   jumps to the value the description edit should already have produced.

Two further symptoms of the same stale pool:

• score.bullets keeps the pre-edit bullet text.
• groupBulletsByExperience over that stale pool returns experienceIndex: null, so the
  role's editable rows detach into the "Other" bucket in the UI.

Export is unaffected — applyOverrides folds the edit correctly; only the grade is stale.

Where

src/hooks/useAnalyzedResume.ts — the score useMemo (line 258 on main). Its dep
array names contactOverrides, experienceOverrides, bulletOverrides,
educationOverrides, achievementOverrides, certificationOverrides, skillsOverride,
summaryOverride, addedEntries, addedBullets, removedBullets, removedEntries,
claimedBulletKeys and the four scoreAffectingProfileSlots primitives —
descriptionOverrides is absent.

profileOverrides is also absent, but that one is deliberate and documented (#428: it is
stood in for by scoreAffectingProfileSlots so a non-scoring link edit keeps the score
object reference identical). descriptionOverrides has no such justification.

Why it matters now

Pre-existing and long-standing, but less detectable since #652 (PR #922). The score
dep list and the fold memo's dep list used to sit adjacent and spell out the same fourteen
override maps, so an omission was visible by diffing the two arrays. The fold memo is now
[base, doneScoreBullets, snapshot], so a new override channel joins the fold
automatically and joins the score only by hand. #922 added a comment naming the knowingly
absent channels to restore some of that signal, but the defect itself is untouched.

Proposed fix

Add descriptionOverrides to the score memo's dep array, and add a regression test
alongside the existing useAnalyzedResume score-reference-stability tests asserting that a
description edit on a glyph-less-prose parse mints a new score object with a changed
overall.

Consider also whether the hand-maintained dep list is the right mechanism at all: a
derived "score-affecting slice of the snapshot" — the shape scoreAffectingProfileSlots
already uses for profileOverrides — would make the omission structural rather than
clerical. That is a larger change and can be a follow-up.

Acceptance criteria

• A description edit on a glyph-less-prose résumé re-grades: new score object, changed
  overall, score.bullets carries the edited text.
• groupBulletsByExperience attributes the edited role's bullets back to their role
  (no experienceIndex: null detachment into "Other").
• The Download-export follow-up (#421 Secondary #11) #428 invariant still holds: a non-scoring profile edit keeps the score object
  reference identical.
• A regression test pins the above and fails on main before the fix.
• npm run verify green.

Found during the PR review of #922 (which documents it as out of scope, correctly).

[Rayan-and-beyond]

I can take this one. I’ll wait for assignment + status:claimed before starting, and I’ll rebase around #922 if it lands first.

[Rayan-and-beyond]

Thanks for assigning me. The contributor guide says a claim is complete only once both the assignee and status:claimed are present. I’m ready to start #933 as soon as that label is added; I’ll keep the change focused to the score memo dependency plus the regression coverage from the acceptance criteria.

[s-annam]

@Rayan-and-beyond, sorry for the silence here, and thank you for following the claim process exactly as the guide describes. You did everything right. The stall was on our side.

I've unassigned you and handed this issue to Gaal, our issue-to-PR agent. It's a small, well-specified fix, and we are moving issues like this to Gaal so contributors can spend their time on work that needs a human.

Gaal has already opened #1085 for it. The most useful thing you could do now is review that PR. You already know this issue well: check the fix against the acceptance criteria above, look for missing test cases, and comment on anything that looks off. Review is where we need help most, and it's a quicker way into the codebase than writing a fix.

Every other open gaal/* PR is open for review too, if you'd like more. docs/reviewing-agent-prs.md covers what to look for.