feat: enhance application scoring and update validation

[AnujChhikara]

Date: 17 feb 2026

Developer Name: @AnujChhikara

---

Issue Ticket Number

• Implement the application score logic #2574
• application edit bugs fix

Description

• Added score handling in nudgeApplication logic to increment score on nudging.
• Updated application creation to set an initial score of 50.
• Enhanced application update validation to include optional fields: firstName, lastName, college, skills, city, state, country, and role.
• Improved integration tests to verify score updates and application modifications.
• Adjusted unit tests to reflect changes in application scoring logic.

Documentation Updated?

• Yes
• No

Under Feature Flag

• Yes
• No

Database Changes

• Yes
• No

Breaking Changes

• Yes
• No

Development Tested?

• Yes
• No

Screenshots

Screenshot 1

Screen.Recording.2026-02-17.at.11.19.58.PM.mov

Screen.Recording.2026-02-17.at.11.21.23.PM.mov

Screen.Recording.2026-02-17.at.11.23.24.PM.mov

Test Coverage

Screenshot 1

Additional Notes

[coderabbitai]

Walkthrough

The PR introduces a scoring system for applications by setting an initial score of 50 upon creation and incrementing it by 10 on each nudge. The application update payload is expanded to include personal information fields (firstName, lastName, city, state, country, college), skills, and role, with corresponding validator schema, type definitions, and field mapping updates. Tests are updated to verify score values and new update capabilities.

Changes

Cohort / File(s)	Summary
Score System Implementation controllers/applications.ts, models/applications.ts, services/applicationService.ts	Added score field to nudge response. Changed initial application score from 0 to 50. Implemented score increment logic (+10) in nudgeApplication with result tracking.
Update Payload Expansion middlewares/validators/application.ts, types/application.d.ts, utils/application.ts	Extended application update schema and type definitions with eight new optional fields: firstName, lastName, city, state, country, college, skills, and role. Added corresponding field mappings for flattened payload transformation.
Test Coverage Updates test/integration/application.test.ts, test/unit/services/applicationService.test.ts	Migrated POST test to async/await with score verification. Added PATCH tests for new update fields (personal, location, role). Extended nudge tests to assert score values at 10 and 20 across sequential nudges. Updated unit test expected score to 50.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat: add nudge application functionality #2542: Adds nudgeApplication endpoint that this PR extends with score increment and tracking functionality.
• feat: Implement Create Application Flow for User Onboarding #2534: Modifies application domain (validators, types, services) to handle role and score fields similarly.
• feat: improve application update logic and validation #2561: Modifies validateApplicationUpdateData schema in the same validator file.

Suggested reviewers

• iamitprakash
• MayankBansal12

Poem

🐰 A score to track our journey far,
Ten points with each nudge—you're a star!
Personal details now find their place,
Nested fields mapped without a trace,
Applications blooming, ready to race! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main changes: application scoring enhancements and validation updates for application fields.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The pull request description clearly relates to the changeset, detailing score handling, initial score updates, validation enhancements, and test modifications.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch anuj/application-update-nudge

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 4

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

middlewares/validators/application.ts (2)

159-159: ⚠️ Potential issue | 🟡 Minor

numberOfHours max is 168 in update but 100 in creation.

The creation schema (line 54) caps numberOfHours at 100, but the update schema allows up to 168. If this is intentional, it should be documented; otherwise, align both to the same max.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@middlewares/validators/application.ts` at line 159, The update schema allows
numberOfHours up to 168 while the creation schema caps it at 100—ensure both
schemas use the same limit by updating the creation or update validation to the
agreed maximum; locate the creation validation (e.g., createApplicationSchema or
the schema defined around line ~54) and the update validation (e.g.,
updateApplicationSchema where numberOfHours:
joi.number().min(1).max(168).optional()) and make the max consistent (either
change the creation max to 168 or the update max to 100), and add a brief
comment if the discrepancy is intentional.

---

121-162: ⚠️ Potential issue | 🟡 Minor

Conflicting flat and nested keys can produce ambiguous updates.

The schema accepts both flat keys (skills, college) and the nested professional object (professional.skills, professional.institution). If a client sends both in one request, buildApplicationUpdatePayload in utils/application.ts writes to the same Firestore dot-notation paths (professional.skills, professional.institution) twice — the last write wins nondeterministically.

Either:

1. Remove the professional nested object from the update schema (since flat keys now cover the same fields), or
2. Add a Joi .xor() / .without() constraint to prevent sending both flat and nested variants simultaneously.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@middlewares/validators/application.ts` around lines 121 - 162, The schema
currently allows both flat keys (skills, college) and the nested professional
object (professional.skills, professional.institution) which creates ambiguous
Firestore dot-path writes in buildApplicationUpdatePayload; update the Joi
schema to forbid sending both variants together by adding mutual-exclusion
constraints (e.g., call .without('professional','skills') and
.without('professional','college') or use .xor(['professional','skills'],
['professional','college']) on the main schema) so requests cannot include flat
and nested fields simultaneously.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@models/applications.ts`:
- Around line 222-234: Replace the magic number 10 used to bump
application.score with a named constant (e.g., NUDGE_SCORE_INCREMENT) and use it
when computing updatedScore and updating the document; specifically, define
NUDGE_SCORE_INCREMENT alongside the initial score constant in
services/applicationService.ts and then change the calculation in
models/applications.ts from (application.score || 0) + 10 to (application.score
|| INITIAL_SCORE) + NUDGE_SCORE_INCREMENT (or similar referencing the existing
initial score constant), and update the transaction.update and the returned
score value to use the new updatedScore variable.

In `@services/applicationService.ts`:
- Line 89: The literal 50 assigned to the score property is a magic number;
define a named constant (e.g., INITIAL_APPLICATION_SCORE) in the application's
constants module alongside the existing nudge increment constant and replace the
hardcoded 50 in the score assignment with INITIAL_APPLICATION_SCORE so future
adjustments are centralized and self-documenting.

In `@test/integration/application.test.ts`:
- Line 884: The test inserts fixtures via
applicationModel.addApplication(applicationsData[0]) which lacks a score,
causing the nudge to produce 10; update the fixture so created apps reflect real
API behavior by setting score: 50 on the fixture used in beforeEach (modify
applicationsData[0] or the setup that calls applicationModel.addApplication) and
then change the assertion on expect(res.body.score) to expect 60; alternatively,
replace the fixture insertion with an end-to-end flow that POSTs the application
through the API, then calls the nudge endpoint and asserts the score is 60
(referencing applicationModel.addApplication, applicationsData, and the
expect(res.body.score) assertion).
- Around line 549-564: Convert the test "should return 400 when updating role
with an invalid role" to use async/await for consistency: change the it(...)
callback to an async function, await applicationModel.addApplication(...) to get
testApplicationId, then await
chai.request(app).patch(`/applications/${testApplicationId}`).set("cookie",
`${cookieName}=${jwt}`).send({ role: "invalid_role" }) and perform the same
expect assertions on the awaited response; remove the done() callback and any
.end(...) callback usage. Use the same assertion lines
(expect(res).to.have.status(400); expect(res.body.error).to.equal("Bad
Request");) after awaiting the request.

---

Outside diff comments:
In `@middlewares/validators/application.ts`:
- Line 159: The update schema allows numberOfHours up to 168 while the creation
schema caps it at 100—ensure both schemas use the same limit by updating the
creation or update validation to the agreed maximum; locate the creation
validation (e.g., createApplicationSchema or the schema defined around line ~54)
and the update validation (e.g., updateApplicationSchema where numberOfHours:
joi.number().min(1).max(168).optional()) and make the max consistent (either
change the creation max to 168 or the update max to 100), and add a brief
comment if the discrepancy is intentional.
- Around line 121-162: The schema currently allows both flat keys (skills,
college) and the nested professional object (professional.skills,
professional.institution) which creates ambiguous Firestore dot-path writes in
buildApplicationUpdatePayload; update the Joi schema to forbid sending both
variants together by adding mutual-exclusion constraints (e.g., call
.without('professional','skills') and .without('professional','college') or use
.xor(['professional','skills'], ['professional','college']) on the main schema)
so requests cannot include flat and nested fields simultaneously.