Repository navigation
fix(tui): read a listing's applications instead of an apply form against it - #160
Merged
ralyodio merged 2 commits intoSep 21, 2026
Conversation
…nst it The Your listings tab's help bar promises 'enter: applications', and the TUI's own header calls its employer half 'read what came back'. Enter actually opened the job detail - the same screen as the find tab - with 'a: apply' and 'd: prepare draft' hints against the employer's own listing, and there was no way to read received applications from the TUI at all. Enter on a listing now loads GET /api/v1/jobs/<slug>/applications and shows them (status, when, agent disclosure). The candidate-facing apply and draft keys only appear on the find tab's detail, esc/search/tab clear the applications with the detail, and an unanswered listing says 'Nobody yet.'
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Three unresolved moderate issues affect key dispatch, stale async responses, and hired-status rendering.
Get a fresh assessment by requesting another Copilot review.
Review effort: Lite
Findings: 2
Open (2)
What changed in this PR
Updates the TUI’s “Your listings” tab to display received applications instead of candidate application actions.
Changes:
- Loads and tracks applications for owned listings.
- Renders applicant details and empty states.
- Separates employer and candidate key hints.
- Adds rendering and navigation regression tests.
| File | Summary and review notes |
|---|---|
test/tui-applications.test.ts |
Adds application rendering and state regression tests. |
src/tui/views.ts |
Renders application rows and empty states. Moderate issue (3 votes): compare status with hired, not accepted. |
src/tui/state.ts |
Tracks application views and navigation state. |
src/tui/index.ts |
Loads applications and clears detail state. Moderate issues: guard application-view key dispatch (2 votes) and prevent stale async responses after navigation (1 vote). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| invalidate({ | ||
| ...state, | ||
| detail: job, | ||
| applications: result.items as ApplicationRow[], |
| label: `${name}${email === undefined || email === '' ? '' : ` <${email}>`} | ${ago(application.createdAt)}${agent}`, | ||
| badge: application.status, | ||
| color: | ||
| application.status === 'accepted' |
The applications view reuses detail state, so a/d still fired apply against your own listing even with the hints hidden. Guard the dispatch on applications === null. The success badge compared against 'accepted', which is not an application status; the positive decision is 'hired'.
Contributor
Author
|
Fixed both Copilot findings in 496f9f2:
Full suite passes locally (368 tests), CI re-running. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On the TUI's "Your listings" tab, the bottom bar promises
enter: applications, and the TUI's own header describes its employer half as "read what came back". Pressing enter on one of your listings actually opens the job detail - the same screen as the find tab - with "a: apply" and "d: prepare draft" hints against your own listing, and there is no way in the TUI to see the applications a listing received at all.The cause is twofold:
activatetreats the listings tab exactly like the find tab (opendetail, done), and the detail key hints are drawn fromdetail !== nullalone, so the candidate-facing apply keys are offered regardless of whose listing is open. An employer who follows the hint ends up invited to apply to their own post, and the applications the API already serves atGET /api/v1/jobs/<slug>/applicationsnever appear.With this change, enter on a listing loads that endpoint and shows the applications - name, email, status, agent disclosure and how long ago - inline beside the listing. The apply and prepare-draft keys only appear on the find tab's detail, esc, tab and
/clear the open applications together with the detail, and a listing nobody has answered yet says "Nobody yet."Validation:
tsc --noEmitand build pass. The five new rendering/state regressions intest/tui-applications.test.tsrun against the real layout through hqtui's text renderer: on unmodified master four fail and the one find-tab guard passes; with the fix all five pass, and the full local suite is 368/368.AI-assisted contribution, submitted under the published bug-fix offer (https://ugig.net/gigs/8b2a21db-ce15-433f-a73d-68f2e3349e87).