Feature: transcript-driven targeting correction — realign which roles to apply for from interview-debrief signal

[Schlaflied]

Code of Conduct: agreed. Existing issues: searched — this is the downstream consumer of #686 / #509, not a duplicate of either (see "Why separate" below).

Area: Evaluation / Scoring (extends the patterns mode).

Problem

career-ops corrects targeting from tracker outcomes — patterns mode reads rejected/applied counts per archetype and tells you which archetypes are wasting time. But win/loss is a noisy signal: you get rejected for comp, timing, headcount, a dozen reasons that have nothing to do with role-fit.

The highest-resolution signal of role-fit is what the candidate actually says in interviews — where their answers are fluent, specific, and energized vs. where they go flat and generic. With #686 (interview/debrief, green-lit, PR #956) and #509 (mock sessions) landing, the project will be producing exactly that transcript signal — and then throwing it away after the per-interview debrief.

Concretely: a candidate applies to Instructional Designer roles, but across 6 debriefs their strongest, most specific answers keep clustering around systems / data / PM competencies. Today nothing notices. They keep aiming at the role on their résumé, not the role their answers are selling. patterns can't catch this — it only sees the win/loss column, not the content.

This is the gap between "you're losing" (tracker outcomes) and "you're aiming at the wrong target" (transcript content). Nothing in the system closes the second loop.

Proposed solution

A cross-transcript analysis — extend patterns, or a sibling step — that consumes the debrief/session transcripts #686 and #509 already produce (no new plumbing) and:

1. Extracts which competencies / role-signals the candidate's actual answers cluster around — flagging where they're fluent and specific vs. flat and generic.
2. Compares that to (a) the archetypes in modes/_profile.md and (b) the roles actually applied to (data/applications.md).
3. Surfaces a targeting correction: "Your demonstrated strengths align more with role-type X than the Y you're targeting → consider adding archetype X / reweighting portals.yml title_filter.positive."

The point is to turn interview content into a steering signal for where to apply next, not just a per-interview report card.

Why this is separate from #686 / #509

• Feature: add interview/plan, interview/practice, interview/debrief skill modes #686's interview/debrief is per-interview retrospective — how did this interview go.
• This is cross-corpus targeting correction — across N interviews, where should you aim next.

Different artifact, different cadence. This depends on #686/#509 landing first to produce its input — which is exactly why it's worth filing now: so the transcript schema those PRs introduce is designed with this downstream consumer in mind (e.g. preserving per-answer competency tags, not just a flat blob).

Scope / non-goals

• No new transcript plumbing — reuses Feature: add interview/plan, interview/practice, interview/debrief skill modes #686/Feature: voice-based mock interview mode (/career-ops mock) #509's gitignored outputs (interview-prep/sessions/ etc.).
• No new dependencies — prompt-level analysis over existing local files, same shape as patterns.
• Recommendation only — never auto-edits portals.yml or modes/_profile.md; surfaces the suggestion, the user decides (consistent with the project's review-before-action rule).
• Privacy — reads only local, already-gitignored transcripts; nothing leaves the machine.

[santifer]

Interesting one, @Schlaflied — closing the loop from interview-debrief signal back into which roles to target (not just tracker outcomes) extends patterns in a genuinely useful direction, and you've scoped it cleanly as the downstream consumer of #686/#509. Labeled enhancement; pairs with your #961.