Lecture rapide de l'état de chaque candidature. Utile comme point quotidien ou pour préparer la revue hebdomadaire. L'interface complète pilotée au clavier vit dans le dashboard TUI en Go ; ce mode est le résumé côté chat.

Ce que fait ce mode

Le mode tracker lit votre tracker, data/applications.md, et affiche chaque candidature avec son statut actuel dans une seule réponse. Un bloc de statistiques suit : le total, le nombre de candidatures par statut, le score moyen, le nombre de lignes qui disposent d'un PDF sur mesure et d'un rapport et, dès que vous avez postulé quelque part, la vitesse à laquelle vos candidatures passent d'une étape à l'autre.

Quand l'utiliser

Utilisez tracker pour un point d'état quotidien de quinze secondes. Utilisez le dashboard TUI en Go quand vous avez besoin de creuser.

Exemple

`/career-ops tracker` — output is a structured status summary in the chat.

À quoi ressemble une exécution

Une exécution de tracker affiche le tableau complet des candidatures ainsi qu'un bloc de statistiques dans une seule réponse, pour que vous puissiez lire l'ensemble de votre recherche d'un coup d'œil. Chaque ligne correspond à une candidature, avec son entreprise, son poste, son score, son statut actuel, et l'indication qu'un PDF sur mesure et un rapport d'évaluation ont été générés ou non.

Example

# | Date       | Company   | Role              | Score | Status    | PDF | Report
1 | 2026-06-14 | Anthropic | AI Engineer       | 4.5/5 | Interview | yes | yes
2 | 2026-06-18 | Vercel    | Applied AI Eng    | 4.2/5 | Applied   | yes | yes
3 | 2026-06-21 | Figma     | Product Eng, AI   | 3.9/5 | Evaluated | yes | yes

Total: 3   Applied: 1   Interview: 1   Evaluated: 1
Average score: 4.2/5   PDF generated: 100%   Report generated: 100%

Une candidature traverse un ensemble fixe d'états : Evaluated (rapport rédigé, décision en attente), Applied (vous avez postulé), Responded (l'entreprise a répondu mais pas encore d'entretien), Assessment (une évaluation en ligne ou une présélection asynchrone est en cours), Interview (un processus actif), puis un état terminal : Offer, Rejected, Discarded, SKIP pour les postes qui ne conviennent pas, ou Hired une fois que vous avez accepté une offre. Pour enregistrer un changement de statut, demandez-le dans le chat ou lancez vous-même node set-status.mjs --report <report#> <state>, en ajoutant --on YYYY-MM-DD si le changement a eu lieu à une date antérieure. Une ligne sans rapport se sélectionne plutôt par son entreprise, node set-status.mjs "<company>" <state>, avec --role quand plusieurs lignes partagent la même entreprise. La commande rejette les états inconnus, verrouille le tracker pendant l'écriture et consigne la transition dans data/status-log.tsv, le journal que lisent les statistiques de funnel-velocity : utilisez-la plutôt que de modifier la ligne à la main.

Pour corriger une note plutôt que d'en ajouter une autre, passez l'ancienne note avec --replace-note et le nouveau texte avec --note. Sans cette option, --note ne fait qu'ajouter, ce qui laisse dans la ligne des contradictions comme not applied; applied. La correspondance porte sur une note entière entre séparateurs ; , et si aucun des deux textes ne figure dans la cellule Notes, rien n'est écrit :

node set-status.mjs --row 12 Applied --replace-note "not applied" --note "applied via referral"

Trois autres options existent surtout pour le dashboard TUI en Go, qui enregistre désormais ses changements de statut via set-status.mjs. --report-link N sélectionne la ligne dont la cellule Report contient exactement un lien vers le rapport N, et refuse les cellules mal formées au lieu de deviner. --repair-status-log et --repair-followup s'appliquent quand un passage à Applied est relancé sur une ligne déjà en Applied : elles ajoutent l'entrée du journal ou le rappel de relance que la première tentative n'a pas réussi à écrire, et n'ajoutent rien quand ils sont déjà présents.

Réparer les liens de rapport morts

node verify-pipeline.mjs signale Report not found quand la cellule Report d'une ligne pointe vers un fichier qui n'existe plus. npm run fix-report-links répare ces lignes en ne modifiant que cette cellule, qui reçoit la marque « pas de rapport » habituelle du tracker. Il ne régénère pas le rapport manquant. Prévisualisez d'abord :

npm run fix-report-links -- --dry-run  # list the affected rows, write nothing
npm run fix-report-links               # apply; the tracker is backed up to .bak first

Toutes les autres cellules, l'ordre des lignes et les fins de ligne restent tels quels. Une cellule Report qui contient autre chose qu'exactement un lien est listée pour que vous la vérifiiez à la main, et reste inchangée. Le lancer deux fois ne change rien la seconde fois.

Vérifier si les annonces sont toujours ouvertes

Des annonces ferment pendant que leurs lignes restent en Evaluated ou en Applied. node check-liveness.mjs --tracker vérifie l'annonce de chaque ligne en Evaluated et en Applied ; --status= permet de choisir d'autres statuts. Il prend chaque annonce dans la cellule URL de la ligne ou dans la ligne **URL:** de son rapport, et liste par numéro les lignes qui n'ont ni l'une ni l'autre.

Pour faire le ménage dans les lignes en Evaluated dont l'annonce a fermé, prévisualisez d'abord :

node check-liveness.mjs --tracker --discard-expired          # dry run: lists the rows it would move
node check-liveness.mjs --tracker --discard-expired --apply  # moves them

Seule une annonce jugée expired fait passer sa ligne d'Evaluated à Discarded, avec la note posting closed YYYY-MM-DD. Une ligne au verdict incertain reste telle quelle, tout comme chaque ligne en Applied.

Lire les chiffres cumulés

Pour les chiffres cumulés — le funnel complet, les totaux du scanner, la couverture des portails et le respect des relances — le mode exécute node stats.mjs --summary et présente sa sortie telle quelle. Cette commande lit vos fichiers locaux et ne coûte aucun token : les chiffres ne sont donc jamais recalculés à la main ni estimés de mémoire. Utilisez le résumé côté chat ci-dessus pour une lecture quotidienne rapide, et la commande de statistiques quand vous voulez les totaux cumulés sur l'ensemble de votre recherche.

Exporter une copie réparée

Au fil de centaines de lignes, un tableau markdown s'abîme : placeholders de mojibake, score échoué dans la colonne de statut, ids en double, barres verticales parasites. node tracker.mjs sync les détecte et les répare dans son index SQLite, data/applications.db, sans toucher au markdown. tracker.mjs a besoin de Node 22.13 ou plus récent (23.4 ou plus récent sous Node 23) pour cet index ; le tracker markdown continue de fonctionner sans lui. node tracker.mjs export est la façon d'adopter cette copie réparée de votre propre tracker :

node tracker.mjs export                            # rebuilt table on stdout
node tracker.mjs export --out repaired.md          # write to a file; an existing one is backed up to repaired.md.bak first
node tracker.mjs export --out repaired.md --force  # write even when something would be lost

export ne touche jamais à data/applications.md, sauf si vous le passez en --out.

Il préserve la structure qu'il a lue, pas seulement les valeurs : votre ligne d'en-tête, les colonnes que career-ops ne mappe pas (Location, Via, URL ou les vôtres), le titre, les lignes avant et après le tableau, et les fins de ligne CRLF ou LF. Les colonnes supplémentaires reviennent à leur propre position, même si query ne peut pas filtrer dessus.

Tout ce qu'il ne peut pas reproduire est signalé sur stderr. Si cette liste n'est pas vide, --out sur un fichier existant refuse d'écrire (code de sortie 1, rien n'est écrit) tant que vous ne relancez pas avec --force ; si elle est vide, --out sauvegarde le fichier existant puis l'écrase. Ce qui est signalé :

Ce qui est signalé	Pourquoi cela ne peut pas être reconstruit
Une cellule hors des colonnes déclarées par l'en-tête	L'en-tête n'a aucune colonne où la placer
Une ligne entre la première et la dernière ligne du tableau, comme un titre ou l'en-tête d'un second tableau	Un unique tableau reconstruit n'a nulle part où la placer
Une ligne appartenant à un tableau ultérieur, comme une section `## Archive`	Elle a été indexée selon l'en-tête du premier tableau : la réémettre déplacerait des données archivées dans le tableau actif
Une cellule dont la valeur a dû être réécrite pour survivre en tant que cellule (un `\|` parasite revient sous la forme `│`)	La valeur elle-même a changé

L'absence de pertes signalées ne signifie pas que la sortie est identique octet pour octet. export émet les réparations effectuées par sync, et certaines sont silencieuses : aplicado est un alias reconnu de Applied dans templates/states.yml, donc sync --check ne signale aucune corruption et l'export écrit quand même Applied. Les cellules alignées en colonnes reviennent aussi avec un seul espace. Avant d'adopter un export, comparez-le au fichier qu'il remplace :

node tracker.mjs export | diff data/applications.md -

La référence complète de la commande, y compris sync, query et history, se trouve dans le guide des scripts du dépôt principal.

Pièges à connaître

Le statut se trouve dans la colonne Status du tracker (data/applications.md), pas dans le fichier du rapport. Le modifier à la main contourne data/status-log.tsv : funnel-velocity voit bien le nouveau statut, mais pas le moment où il a changé, donc le changement manque dans les temps par étape, et une ligne qui finit plus tard en Rejected perd les étapes par lesquelles elle est passée. Utilisez set-status.mjs, le chat ou le sélecteur de statut du dashboard TUI en Go, qui exécute la même commande.

tracker