Stop handing finished applications something new to do

[DanialBeg]

Fixes a regression I merged in #56, found by @ZubairQazi reviewing it.

The bug

#56 topped saved checklists up with any missing default task, so students with an existing college list would see the new fee-waiver step. That reached every entry, including ones already submitted or decided.

A school with all eleven tasks ticked gained the waiver task and read "10 of 11", with an unticked:

Ask your counselor about a fee waiver

...for an application already sent. Worse than a wrong count — it's an instruction that makes no sense.

Reproduced on main before fixing:

submitted school progress: 10 of 11
gained: [ 'waiver' ]

The fix

Only applications still being worked on (not-started, in-progress) gain tasks. A finished one keeps the list it finished with.

This is the half that's already on main. #58 reaches the same conclusion from the aid-application side, and its isActive guard is the same idea.

On the #58 conflict

@ZubairQazi flagged that both PRs rewrite tasksForEntry, and offered to merge on whichever side lands second. #56 and #57 have landed, so that's #58.

This should make it easier rather than harder — the status guard you asked for is now on main, so the remaining merge is your side's two additions:

• the aid-task label refresh, which has no equivalent here
• the WeakMap result cache, likewise

I deliberately didn't take either. Adding your cache from this side would have meant you merging against a half-copy of your own work, which is worse than merging against a clean one. The top-up loop is otherwise unchanged from #56: any missing default task, each spliced into its own phase.

Testing

529 passing, lint and typecheck clean. Two new cases: a submitted school keeps the exact array it had (identity, not just equality), and one in progress still gets topped up.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
webapp	Ready	Preview	Oct 1, 2026 9:06pm UTC

[cloudflare-workers-and-pages]

Deploying timeline-prototype with    Cloudflare Pages

Latest commit:	304fbcd
Status:	✅  Deploy successful!
Preview URL:	https://cea1a11d.timeline-prototype.pages.dev
Branch Preview URL:	https://fix-no-new-tasks-after-submi.timeline-prototype.pages.dev

View logs

[DanialBeg]

Reviewed my own diff, so here is what I actually checked and the one thing I found.

Holds up

• Returns app.tasks by identity when inactive, so nothing downstream rewrites a finished entry.
• initialTasksFor is unaffected — a school added today goes through defaultTasksFor and gets the full list whatever its status.
• updateSharedTask no longer reaches submitted schools, which is right: ticking the waiver on an active school should not silently edit a finished one.
• withdrawn keeps its list, same as decided.

One gap, which this fix narrows but does not close

Reopening a submitted school gains the task unticked, even where the student has already done it:

a waiver done: true                              ✓
b (submitted) has waiver: false                  ✓  this fix
b reopened — waiver present: true, done: false   ✗
shared summary: 1 of 2                           ✗

The waiver is a shared task — one request covering the whole list — so "1 of 2" is wrong by definition. The cause is that the top-up takes the task from defaultTasksFor, which has no view of sibling entries and so always yields done: false.

This predates the fix: #56 introduced the top-up with the same blind spot. The status guard only changes when it surfaces.

Deliberately not fixing it here. #58 already carries the general solution — withSharedTasks(app, others), "so a profile already filed isn't asked for twice" — and writing a second version on this side is exactly the duplication that would make that merge worse. Flagging it so it is not lost: @ZubairQazi, your helper covers waiver as well as css once these meet.

Reachable only by a school saved before the waiver task existed, submitted, then reopened. Worth fixing, not worth blocking on.