tracker

Tracker — local application board

Read ~/.coforce/instructions.md first if present — standing user instructions (e.g. never-apply companies must not be added as pending).

Local truth: ~/.coforce/applications.json — a JSON array of applications: {id, url, title, status, createdAt, updatedAt, company?, position?, notes?, needsFallback?, description?, deadline?, history?: [{date, event}]}. Missing file → start with []. deadline is the posting's stated application deadline as YYYY-MM-DD — only when the posting states one; never guess it from "apply soon" or the posting date.

Operations

Add / update: read the JSON, apply the change, write back. id = epoch ms string; always bump updatedAt (ISO). status is the pipeline stage ONLY: pending → applied → interviewing → offer | rejected, and rejected means one thing only: a company turned the user down. How delivery went is never a status — an operator giving up is a history event plus needsFallback: true (= a human has to take this one; cleared when the application eventually goes out). Nor is fit: a posting screened out because it contradicts the user's intent never entered the pipeline, so it does not belong in this file at all — it goes to the start skill's screening ledger (hunt.mjs screen <url> --reason "…", ledger at ~/.coforce/screened.json, reversible with unscreen). Mixing the two makes the board claim rejections that never happened. Put recruiter emails, interview dates, and contacts in notes. When adding an application, save the JD text into description if you have it. Every status change appends to history: {date, event} (e.g. "status: applied → interviewing — recruiter email"); record submissions and interviews there too.

Console (看板 + 面板) — a React + Tailwind web app that ships with this skill (web/, prebuilt web/dist included). The only launch entry point is scripts/start_web.sh (relative to this skill's base directory, shown when the skill loads):

"<skill-dir>/scripts/start_web.sh"           # console on http://localhost:4517
open http://localhost:4517

PORT=… overrides the port; --dev starts the API plus a Vite dev server with HMR on :5173 for working on the UI (web/src, needs bun or npm). The script rebuilds dist automatically when sources changed and a package manager exists; otherwise it serves the committed dist (end users never build). board.mjs is the API server behind it — never invoke it directly from skills. It only serves; a second hand-rolled HTML renderer used to exist for a static single-file export and was deleted (git history has it). One kobe-Hallmark-themed local site with these primary tabs:

• Board — kanban: full-height status columns, drag & drop moves an application (appends a history event, saves to the JSON), cards open a detail view (JD link, saved info, files, history timeline, description).
• Discover (home tab) — local job discovery: fetches the configured sources through the start skill's hunt.mjs (sibling install), lists postings not yet tracked (dedup + never-apply applied) with company logos. ~/.coforce/config.json is the canonical settings file, normally pre-filled by the setup skill (level, directions, sponsorship, work mode, locations…); if it carries no level a first-visit wizard collects level + directions, and console edits merge into it (POST /api/prefs) without touching keys the console does not show. Row icons resolve company-homepage logos via logo.dev when logoDevToken (publishable key) is set in config.json, falling back to the Google favicon service, then to an initials tile when the source list carried no homepage link. A left filter panel (search, level, direction with keyword classification, source) narrows the list, and a collapsible footer lists what the start skill's fit filter screened out — read from ~/.coforce/screened.json, that skill's ledger — each with its reason, where Reconsider un-screens one (POST /api/screened/unscreen, which shells out to hunt.mjs unscreen) so it returns to discovery. The filter is never the last word. Each row's Build resume button queues the posting into both the tracker and current resume campaign. The next start/campaign cycle hydrates the JD and renders its matched resume; application submission remains a separate action.
• Review — campaign dossier workspace: job queue, status and match score, source-linked evidence shortlist, zoomable PDF proof, feedback/revision, optional manual approval, and all-approved ZIP export. Settings can disable the resume HITL gate, in which case complete PDFs auto-approve and the batch ZIP auto-refreshes. It also shows the read-only Tier 0 experience-index status; campaigns never refresh GitHub. Campaign data lives under ~/.coforce/campaigns/current/.
• Profile — resume-style live preview of ~/.coforce/profile.json beside a structured form editor (basics, skill chips, add/remove experience/project/education cards and bullets — no raw JSON). Its Resume skill policy ledger merges resume/coursework and Tier 0 skills, shows provenance, assigns the mandatory baseline and role packs, and keeps Save draft (review_requested) separate from explicit Approve policy. The same tab also provides "Import resume (AI)": pasted text is parsed by the local agent runtime (claude -p; binary override COFORCE_CLAUDE_BIN) and fills the form for review before Save.
• Instructions — edit ~/.coforce/instructions.md in place.
• Settings — runtime consents, editable minimum resume page coverage, required-vs-automatic resume review, LaTeX template, Tier 0 source scope, discovery preferences, and sources.