The mockup's kanban columns have no border, just a light grey
background -- this instance used multi-line sx formatting
(border/borderColor on separate lines) so it slipped past the earlier
single-line-substring grep sweep. Caught by a follow-up multi-line
search across the whole frontend for the same pattern; nothing else
turned up except a legitimate circular crop-tool boundary in
CropImageDialog, which correctly stays as-is.
Every Dialog/Menu/Popover in the app renders its content via MuiPaper,
which is deliberately kept flat (1px border, no shadow -- Paper is
used too broadly, e.g. as a plain content divider, to safely restyle
globally). That meant every modal (confirm/prompt, AddJobModal,
EditJobDialog, JobDetailsDialog) and every dropdown/Select menu in the
app was still rendering flat-bordered despite every other screen this
session moving to the floating-shadow mockup look.
Added targeted MuiDialog/MuiPopover/MuiMenu paper overrides -- these
win on specificity over MuiPaper's own defaults without touching
MuiPaper itself, so every dialog and dropdown in the app picks up the
rounded floating-shadow treatment from this one change instead of
patching each dialog file individually. Also added MuiChip (full pill
radius, matching every status/skill pill in the mockups) and
MuiTooltip (matching corner radius) overrides, and gave the toast
Snackbar/Alert a consistent radius + weight.
No mockup exists for 404/500 pages, so these follow the visual
language already established elsewhere this session: floating-shadow
card, big bold status number (matching the dashboard stat tiles'
bold-number treatment) instead of a small overline.
JobTable's first-run empty state gets an icon chip matching the
landing page's feature-card icon treatment (rounded square, tinted
primary background) instead of plain text -- the filtered "no results"
one-liner stays as-is, that's a different, correctly minimal case.
Main table Paper wrapper gets the same floating-shadow treatment as
every other card this session.
ViewStateNotice (the shared loading/error component used across the
app) reviewed and left untouched -- it's an MUI Alert used as an inline
banner, which is the correct pattern; it was never a "fake card" to
begin with.
Repo-wide sweep for the same flat 1px-border "fake card" pattern
already fixed in Dashboard/Kanban/JobDetailsDialog/auth pages this
session -- AddJobModal, Attachments, CompaniesTable, Correspondence,
EditJobDialog, and the admin audit/system/users pages all had a table
container or content box using border+divider instead of the
floating-shadow treatment used everywhere else now.
Left AppShell.tsx/App.tsx alone -- their border:1px+divider instances
are icon-button and badge outlines, not card containers; that's a
different, correct use of the pattern.
Login/register, forgot-password, reset-password, verify-email, and the
2FA/sessions settings cards all used a bare MuiPaper (1px border, no
shadow) predating this session's theme foundation. MuiPaper itself
stays untouched (it's a lower-level primitive used too broadly across
the app -- menus, popovers -- to safely restyle globally), so these
specific card instances get the same explicit no-border/floating-shadow
treatment already applied screen-by-screen elsewhere this session.
Static shadow value again, not theme.vars.customShadows -- inline sx
callbacks execute against whatever theme is in context, and none of
this repo's tests wrap components in a ThemeProvider (see fc56f94).
LandingPage.tsx already closely matched the mockup set (dark navy hero,
gradient CTAs, numbered step badges, feature/pricing cards) from an
earlier pass -- nothing structural needed here. Replaced the 4 places
that hand-rolled the same linear-gradient(90deg,#6366f1,#22d3ee) inline
with the shared GradientButton component introduced this session, so
the gradient can't drift out of sync between screens.
Restyle JobDetailsDialog.tsx (04-job-workspace.png mockup) within its
existing dialog/tab structure -- the real app splits Correspondence,
Attachments, and Candidate Fit into separate tabs rather than the
mockup's single-screen 2x2 card grid, so this is a visual-language
pass over the existing IA, not a restructure:
- Header: bolder title (h5/800), heavier status chip, cleaner
no-underline tab styling.
- Every flat bordered "fake card" Box (11 instances across all tabs,
plus the 2 in the Overview strategy-snapshot panel) becomes a
floating shadow card with no border, matching every other screen
redesigned this session.
- The two genuinely AI-generation actions (Generate Strategy Snapshot,
and by extension the shared GradientButton component) get the
mockup's signature gradient CTA treatment; the confirm-gated
"Refresh AI summary" action stays a plain outlined button so the
gradient doesn't get diluted by a second use on the same tab.
Also fixes a real bug surfaced by actually using GradientButton for
the first time: its sx callback read theme.vars.customShadows, which
throws when a component renders without this app's ThemeProvider --
true in production always, but true in every test in this repo (none
of them wrap with a ThemeProvider), so every test touching a
GradientButton or one of these restyled boxes crashed. Fixed by using
a static shadow value instead of a theme.vars lookup in both the
component and this file, matching the fact that inline sx callbacks
execute against whatever theme is in context (unlike theme.components
styleOverrides, which only run when this app's real theme is actually
provided).
Verified: tsc clean, full suite green (65/65, including 4 test files
that render this exact dialog). Live check: booted the backend and
loaded the dashboard through a fresh Next.js dev server + cache
(cleared .next after chasing what turned out to be a stale console-log
history in the Browser pane tooling, not a real compile error) --
confirmed real data renders with no actual runtime errors.
Extract design tokens from the mockup set (F:\Pictures\website\jobtracker\new
dashboard, pipeline, job-workspace, features, workflow screens) into the
central theme so every screen picks the change up automatically:
- Heading weight: h1-h4 go bold/black (800/700) to match the mockups' heavy
display type; h5/h6 stay a lighter semibold so dense screens don't turn
into a wall of black text.
- Card shadow: replace the flat 1px "section" shadow + visible border with a
soft floating shadow and no border, matching how mockup cards sit on the
grey page background.
- Border radius: 10/12/8px -> 14/16/10px across shape/card/button defaults,
matching the mockups' rounder corners.
- New GradientButton component wrapping the mockup's signature indigo->cyan
CTA gradient ("Tailor my CV for this role", "See the interface tour"),
reserved for the single most important AI-assist/hero action per screen.
The dark navy sidebar (#0f172a) already matched the mockups from an earlier
pass -- untouched here.
Verified: tsc clean, full frontend suite green (65/65). Live visual
screenshot verification wasn't possible -- the Browser pane's screenshot
tool times out in this environment; verified structurally via read_page
and the app rendering without console errors instead.
- LoginPage: add client-side email/password validation (inline error +
helperText, matching the 2FA components' established pattern), and a
proper register-mode toggle with a "Confirm password" field. The
brief asked for confirm-password on registration but the page only
had one shared password field; a toggle (mirroring the existing
Tabs-for-mode pattern already used for Google/Microsoft) keeps this
from cluttering the login form for returning users.
- Fix a real bug in ResetPasswordPage: it didn't use the app's
getApiErrorMessage helper, so a non-string error response body would
render as "[object Object]" in the toast. Also add a confirm-password
field and matching client-side validation for parity with register.
- ForgotPasswordPage: add proper email format validation instead of
only checking for non-empty.
- Add matching i18n keys (en/no) for every new validation message.
Verified live end-to-end against a running backend: register-mode
toggle, confirm-password mismatch blocking submission client-side,
and a full registration completing and landing on the dashboard.
The sessions unit's live smoke test caught the same bug it fixed in
SessionsController also present in TrustedDeviceService and
TwoFactorController's device list: SQLite/Pomelo's EF Core provider
cannot translate DateTimeOffset relational comparisons or ORDER BY to
SQL, so IsDeviceTrustedAsync (the check that skips 2FA for a trusted
browser) and ListTrustedDevices would 500 on real SQLite despite
passing on EF's InMemory test provider. Same fix: equality-only in
the DB query, expiry comparison and sort after materializing.
JWTs were previously fully stateless -- the token alone was the credential
until its own expiry, with no way to list or kill a session server-side. Add
a UserSession table alongside every JWT issued (AppSessionIssuer), embed its
id as a "sid" claim, and check that claim against the DB on every "local"
scheme request (Program.cs OnTokenValidated) so a session can actually be
revoked before its JWT naturally expires. New /api/auth/sessions endpoints
(list, revoke one, revoke-others) plus a Sessions card on the profile page.
Fails closed on a missing "sid" claim: every JWT issued going forward has
one, so a token without it is either pre-deploy (forces one re-login for
already-signed-in users at deploy time, same additive-forward cost the
2FA/trusted-device work on this branch already paid) or forged.
Auth:RequireEmailVerification (default off) gates whether local
register requires confirming email before login. OAuth new-user paths
are untouched -- Google/Microsoft already assert a verified email.
Adds verify-email and resend-verification-email endpoints, mirroring
the existing reset-password enumeration-avoidance and rate-limiting
patterns, plus a login-embedded resend affordance and a verify-email
landing page on the frontend.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a "Trust this device for 30 days" checkbox to the 2FA challenge step,
and a "Trusted devices" section to the 2FA settings card: list devices with
a "this device" badge, per-row revoke, and a confirm-gated "sign out all
other trusted devices" action. Both flows are opt-in and additive -- default
unchecked, so nothing changes for a user who never uses them.
Adds a "trust this device" option to the 2FA challenge: on success, mints a
random token (only its SHA-256 hash is stored), sets it as a new httpOnly,
Secure, SameSite=Strict cookie, and records a TrustedDevice row. AuthController
checks that cookie for the exact signing-in user before gating on 2FA -- a
mismatched user, expired, or revoked device falls through to the normal 2FA
prompt, never errors. TwoFactorController also exposes list/revoke/revoke-all
endpoints for managing trusted devices, scoped to the owning user.
Schema added via the existing raw-SQL reconciler (SQLite + MySQL dialects),
not EF migrations, matching this repo's established pattern.
Adds three layers of account-security hardening, all gated behind the
existing SignInWithAppSessionAsync-equivalent (now AppSessionIssuer) so
every sign-in path -- local, Google, Microsoft -- goes through the same
lockout/2FA checks:
- Per-account lockout: Identity's built-in lockout store (columns already
provisioned, previously unused) is now wired up in AuthController.Login
via IsLockedOutAsync/AccessFailedAsync/ResetAccessFailedCountAsync, 5
failed attempts / 15 min, same generic 401 as wrong-password to avoid
enumeration.
- RFC 6238 TOTP 2FA (Otp.NET) with QR-code setup (QRCoder, fully local/
offline) on a new TwoFactorController: setup requires password
re-confirmation and returns a pending (unconfirmed) secret + QR; the
secret is only persisted as active once verify-setup checks a real
code. Secrets are encrypted at rest via the same IDataProtector pattern
already used for Gmail/Microsoft OAuth refresh tokens.
- Login/OAuth exchange now checks TwoFactorEnabled before issuing a real
session. If enabled, it hands back an opaque, server-side (IMemoryCache)
pending token via a new ITwoFactorPendingTokenService -- deliberately
NOT a JWT, so it can never be presented as a bearer token to bypass the
2FA check on any other endpoint. Only POST /api/auth/2fa/challenge can
redeem it, rate-limited at 5/5min (tighter than password login, since a
6-digit space is far more brute-forceable).
- One-time recovery codes (10 per enable/regenerate, SHA-256-hashed at
rest, shown once in plaintext) accepted in the same challenge endpoint
as an alternative to a TOTP code.
Schema: AspNetUsers gains TotpSecretEncrypted / TotpPendingSecretEncrypted
/ TotpEnabledAtUtc, plus a new TwoFactorRecoveryCodes table, added to both
the SQLite and MySQL dialect blocks in the startup schema reconciler.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Move inline DTOs to GmailDtos.cs, pure parse helpers to GmailParsing.cs
- Batch per-message existence checks in CreateSuggestedJob/RefreshLinkedThreads
- Remove redundant second pass in RelinkThread, reuse existing HashSet
- Replace ToListAsync+scan with FirstOrDefaultAsync for GmailReviewDecisions lookups
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Move inline DTOs to JobApplicationDtos.cs, pure static helpers to JobApplicationHelpers.cs
- GetStats aggregates server-side (COUNT/GROUP BY) instead of loading the full table
- Cache RuleSettings via IMemoryCache, keyed per-user (RulesEngine.GetSettings falls back
to per-user UserRuleSettings overrides, so a single global cache key would leak settings
across users)
- Add missing AsNoTracking() to read-only GET endpoints (GetAll, GetById, GetBoard,
GetReminders, GetStatusSuggestion, GetMatchScore, GetCandidateFit, GetFocusPlan,
GetInterviewPrep, GetReadiness)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Prod was hard-down: InitializeJobTrackerAsync threw an unhandled
MySqlException ("Specified key was too long; max key length is 3072
bytes") while creating IX_JobApplications_OwnerUserId_FollowUpAt,
which crashed Program.Main before the app could start (surfaced to
users as a 500 on Google sign-in, but really affected every request).
Root cause: this reconciler assumes OwnerUserId is varchar(255), but
the live column was provisioned wider by an earlier EF migration,
close enough to the utf8mb4 3072-byte limit that pairing it with a
second column tips a composite index over.
Fix:
- Prefix-index OwnerUserId at 191 chars (safe under the legacy
767-byte-per-column limit, still far wider than the GUID-like
Identity ids actually stored) in every composite/unique index that
includes it, so index creation no longer depends on the column's
actual declared width.
- Wrap each CREATE INDEX in try/catch + LogWarning instead of letting
it propagate: a schema reconciler is best-effort and one failed
index must never crash startup, matching the existing non-fatal
pattern already used a few lines below for legacy-schema ownership
claims.
Backend build + full test suite (177 passing) verified green.
Dashboard onboarding checklist: a dismissible card with 3 steps (add
CV, import first job, check match score), each linking straight to
where you'd do it. Auto-hides once both CV and a job exist; otherwise
persists per-user via localStorage until dismissed.
Fixes the actual authenticated-landing redirect to /dashboard: my
earlier commit changed App.tsx's inner Shell route for "/", which
turned out to be dead code -- the outer router claims "/" for
LandingPage first, so Shell's own "/" route is never reached on a
direct hit. The real redirect lives in LandingPage.tsx's post-auth-check
navigate() and LoginPage.tsx's post-login nextPath default; both now
point at /dashboard. Verified live: an authenticated visitor hitting
"/" now lands on Dashboard with the onboarding checklist visible,
confirmed via rendered page text and screenshot.
Continuing the product/UX review's deferred items:
- Every top-level view now gets a one-line subtitle under its title
(Dashboard/Jobs/Kanban/Reminders/Correspondence/Gmail review) stating
what that specific view is for, instead of navigation being the only
signal of what each page does.
- Correspondence inbox and Gmail review queue cross-link to each other
instead of being two unexplained flat sidebar items -- kept both nav
entries (renaming/nesting risked breaking muscle memory) but made the
relationship between them explicit in the UI itself.
- Kanban board switches to a horizontal scroll-snap row on phone-width
viewports instead of stacking all 5 columns vertically, which meant
a lot of scrolling to see anything past "Applied".
- Match-score ring gets an aria-label with the actual percentage --
it was two nested decorative CircularProgress elements with no
accessible text. (Keyboard-accessible status changes on kanban cards
were already covered by the existing "..." menu -- no gap there.)
Implements the six "propose first" items from the product/UX review:
- "/" now redirects to /dashboard instead of the empty /jobs table --
a new user's first screen is now an overview with orientation, not
a data table with zero rows and four filter dropdowns.
- Jobs table gets a real first-time empty state (distinct from "no
results match your filters") pointing at Add Job and the bookmarklet,
instead of a bare "No jobs found."
- Match Score card and Candidate Fit tab now each get a one-line
caption explaining what they are and how they differ (deterministic
keyword coverage vs. AI opinion) -- they previously sat side by side
with no explanation of why there are two.
- Google sign-in hint now reflects self-serve signup when
Auth:AllowRegistration is on, instead of always implying you need an
existing linked account.
- Quick Search button now shows its keyboard shortcut (Ctrl+K / ⌘K)
inline instead of being undiscoverable.
Root cause of "Google authentication failed": appsettings.Development.json
had Auth:GoogleClientId set to the literal placeholder
"CHANGE_ME_GOOGLE_CLIENT_ID" while the frontend's .env.development had a
real (already-public, already-committed) client ID -- every Google ID
token's audience check failed against the backend's placeholder. Fixed
by setting the same real client ID on both sides (a client ID is a
public identifier, not a secret, safe to commit -- unlike a client
secret). Also enabled Auth:AllowRegistration in dev so the existing
Google-first self-serve-signup path (auto-create on unmatched verified
email, auto-link on matching verified email -- built during Wave 7) is
actually exercisable locally.
Wired the previously-missing Auth__MicrosoftClientId /
NEXT_PUBLIC_MICROSOFT_CLIENT_ID into docker-compose.yml/.env.example
(distinct from the existing MICROSOFT_CLIENT_ID used for Outlook mail
linking) -- Microsoft sign-in was never deployable, a leftover gap from
when it was built. Fixed a stale env-var name in the Microsoft setup
hint copy (still said REACT_APP_*, predates the Next.js migration).
Removed the per-user accent color picker entirely: it was purely
client-side (localStorage + theme.ts), never touched the backend/DB.
theme.ts now hardcodes a single ACCENT constant; themePrefs.ts drops
get/set/clearAccentColor; App.tsx and SettingsView.tsx drop the
accentColor prop threading. Dead accent-related i18n keys removed from
both locales.
Consolidated Settings' "Account" tab (duplicated GoogleAuthCard, which
already lives on the Profile page) into Profile: moved AuthStatusCard
and EmailProviderConnections there alongside the existing Google/
Microsoft auth cards, so identity/account-linking lives in one place.
Settings drops from 5 tabs to 4 and its General tab uses a consistent
SectionCard layout instead of ad-hoc per-card styling.
Verified: dotnet build/test (177/177) and npm build/test (57/57) both
green; confirmed live against a running dev server that /auth/config
now reports googleEnabled with the corrected client ID, Settings has
no accent controls, and Profile shows the consolidated auth section.
Production deploy has been broken since the Next.js migration merged:
the Dockerfile ran `npm ci` right after COPY package*.json, before the
later `COPY . .` that would bring in .npmrc -- so the legacy-peer-deps
fix for react-scripts' stale TS ^4 peer constraint (added for CI in
dbb1580) never took effect in the actual deploy image, and every
deploy since has failed with the same ERESOLVE error CI hit before
that fix. Copy .npmrc alongside package*.json so npm ci sees it.
Second UI-rework pass. The job workspace mockup's signature element is
a donut "coverage" ring for the deterministic CV match score; the app
had a linear progress bar instead. Replaced with a layered
CircularProgress ring (track + value arc, percentage centered) while
keeping every existing feature (band chip, matched/missing keyword
chips, section coverage) -- this is a pure visual upgrade to the
existing MatchScoreCard, not a feature reduction to match the mockup's
simpler single-panel layout.
Fixed match-score-panel.test.tsx's no-signal-state assertion, which
expected the removed inline "—" placeholder; restored it outside the
ring's conditional render.
First pass of the /frontend-design overhaul against the mockups at
F:\Pictures\website\jobtracker\new. Two highest-leverage gaps from the
backlog note ("dark sidebar, KPI cards, exact status colours"):
- AppShell: nav rail is now a fixed dark navy (#0f172a) regardless of
the app's light/dark theme toggle, matching the mockup's signature
look -- selected item gets an indigo-tinted pill + icon accent,
muted slate text for the rest. Kept icon+label rows (mockup's sidebar
is text-only) since the existing collapsed-sidebar mode depends on
icons; that's a deliberate deviation, not an oversight.
- JobbjaktMark: replaced the briefcase glyph with the gradient
checkmark-in-square mark used throughout the mockups (hero, dashboard,
kanban) -- also fixed a latent SVG gradient id collision across
multiple rendered instances via useId().
- KanbanBoard: mockup uses color sparingly (a small dot in the column
header, a 4px accent on the card's left edge) rather than tinting the
whole column/card background as the previous version did. Reworked
to match; also swapped card title/subtitle order (job title bold,
company/location as subtitle) per the mockup.
Remaining for follow-up passes: Dashboard KPI card layout and the job
workspace (candidate-fit ring, AI summary card) -- both structurally
close already but not yet pixel-matched.
Verified: `next build` clean, all 57 frontend tests green, dark
sidebar confirmed live (computed bg #0f172a) against a running dev
server with light content mode forced.
CI's npm ci (strict peer resolution) rejected the TypeScript 5.9 bump
from the Next.js migration: react-scripts still declares typescript
^3.2.1||^4 as a peer. Local `npm install` didn't catch this -- it
resolves peer conflicts leniently by default; only `npm ci` enforces
them. react-scripts is kept solely as the Jest test runner now (it
doesn't type-check), so relaxing this one peer constraint is safe.
Wave 6. Swaps react-scripts' build/dev tooling for Next.js while
keeping the app's actual routing/rendering model unchanged -- the app
is almost entirely behind auth with no proven SSR/SEO need, so a real
App Router rewrite would touch ~90 files for zero user-visible benefit.
- next.config.js: output:'export' (static HTML+JS, same "single
index.html served by nginx with try_files fallback" deploy as CRA).
- app/layout.tsx + app/page.tsx: root shell ports public/index.html's
<head>, mounts the whole existing App tree client-only (ssr:false)
since it reads window/localStorage during initial render and Next's
static prerender would otherwise execute that on the server.
- Renamed src/pages/ -> src/views/ (Next's Pages Router auto-detects
any `pages/` dir under the app root and tried to build our React
Router page components as its own routes).
- REACT_APP_* -> NEXT_PUBLIC_* across code, .env.development,
Dockerfile, docker-compose.yml build args.
- Replaced the CRA SVGR import (`ReactComponent` from .svg, unsupported
under Turbopack) with a small inline JobbjaktMark component.
- TypeScript 4.9 -> 5.9 (MUI v8's type-checked build needs syntax
4.9's parser rejects; CRA never hit this because babel doesn't
type-check).
- Dropped CRA-only files (index.tsx, reportWebVitals, react-app-env.d.ts,
public/index.html); kept react-scripts as the Jest test runner only
(next/jest migration not needed -- the existing config already works).
Verified: `next build` static export succeeds, `next dev` serves the
landing page and client-side routes (login etc.) correctly, all 57
frontend tests + 172 backend tests still green.
Known caveat: deep-linking straight to a sub-route (e.g. /login) 404s
in `next dev` since there's no server route for it -- the app only
ever mounts at "/". Production is unaffected: nginx's existing
try_files fallback still serves index.html for any path.
Wave 7. Mirrors the existing Google ID-token-exchange pattern (Program.cs
smart-scheme dispatch, JWT bearer scheme, AuthController exchange/link/
unlink endpoints, ApplicationUser fields, reconciler columns) for
Microsoft Entra ID + personal accounts via the multi-tenant "common"
endpoint.
Google/Microsoft sign-in previously only worked for accounts already
linked to an existing local user -- there was no way to actually sign
up via OAuth. Both exchange endpoints now create a new user when no
match is found and Auth:AllowRegistration is true, same gate as
email/password registration.
Frontend: new MicrosoftAuthCard (MSAL popup flow -- Microsoft has no
vanilla-JS equivalent to Google's Identity Services script) wired into
the login page's provider tabs and the profile page's account-linking
section. REACT_APP_MICROSOFT_CLIENT_ID env var, Auth:MicrosoftClientId
config gate on the backend.
Wave 4 hardening. Wrap untrusted CV/job-description/instruction text
in tools/summarizer prompts with explicit delimiters and an
ignore-embedded-instructions rule, since JD text, recruiter emails,
and free-text candidate background all flow into rewrite/normalize
prompts unescaped today.
Match score previously normalized synonyms (JS/Kubernetes/K8s/etc)
only when scanning the job posting, not when checking the CV corpus,
so a CV using an abbreviation the job spelled out never matched.
SkillTagger.MatchesTag reuses the same synonym regex for both sides.
Backlog item 4 (Wave 3, first sub-item). HasResume/HasCoverLetter/HasPortfolio/
HasOtherAttachment were manually-editable checkboxes in EditJobDialog,
completely independent of whether a file was actually attached -- classic
drift: mark 'resume ready' by hand, later delete the resume attachment, flag
stays stuck true forever. User confirmed (asked directly, since removing the
manual-override capability is a product decision, not purely technical):
make them fully computed from Attachments, no manual override.
- AttachmentsController.RecomputeAttachmentFlagsAsync: the single place these
four fields get written now, called after every attachment mutation
(upload, delete, Purpose change) that could affect them. Deliberately kept
as persisted columns (not [NotMapped] computed properties reading the
Attachments navigation collection) -- ~15 query sites build JobApplication
DTOs without .Include(Attachments), so a live-computed property would
silently return false everywhere instead of throwing, the worst kind of
bug. Recomputing at the one write funnel avoids touching any read path.
- Removed HasResume/etc from CreateJobApplicationRequest/
UpdateJobApplicationRequest -- no longer client-settable.
- EditJobDialog: removed the manual checkboxes, kept the (now genuinely
accurate) read-only status chips.
- AddJobModal: stopped sending has*-flags at job-creation time; the
follow-up attachment upload call now sets them correctly via the same
recompute path.
Caught a real bug while testing this: the Purpose-change path recomputed
before saving the Purpose change, so a fresh query missed the pending edit
and the flags never updated. Fixed by committing the mutation before
recomputing.
3 new backend tests (purpose-change sets flag, delete clears flag,
non-primary purpose counts as "other"). 172/172 backend, 25/25 frontend
suites (57 tests) green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Backlog item 3 (Wave 2), GmailController slice. Pure mechanical extraction,
no behaviour change:
- GmailDtos.cs: the 26 inline record DTOs, moved to a partial-class file so
every existing GmailController.XyzDto reference (tests included) keeps
working unchanged.
- GmailParsing.cs: the 8 pure static helpers (ApplySyncBoundary,
LooksLikeJobRelatedThread, ToConfidence, ExtractFirstEmail/RecruiterName/
CompanyName/RoleFromSubject, BuildPopupHtml), same partial-class approach.
GmailController.cs: 1200 -> 1022 lines. 169/169 green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Backlog item 2. CreateSuggestedJob, RelinkThread, and UnlinkThread each
upserted exactly one GmailReviewDecision by ThreadId but loaded every review
decision for the owner (GmailReviewDecisions.Where(OwnerUserId == x).ToList())
just to linear-scan for the one match. Replaced with FirstOrDefaultAsync
filtered on both OwnerUserId and ThreadId, and added a single-row
UpsertReviewDecision overload alongside the existing dictionary-based one
(still used by the review-queue endpoints, which genuinely need every
decision at once to render the queue).
169/169 green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
cesnimda
cesnimda