trackly-cli 0.6.2 → 0.6.3

package/lib/agent.js

@@ -7,7 +7,7 @@ const path = require('node:path');
 const { spawnSync } = require('node:child_process');
 const { apiRequest, downloadFile, getConfigPaths, hasAuth, maintenanceOutput } = require('./client');
 const { version: PACKAGE_VERSION } = require('../package.json');
-const SKILL_VERSION = '2.1.0';
+const SKILL_VERSION = '2.2.0';
 const CLI_USER_AGENT = `trackly-cli/${PACKAGE_VERSION}`;
 const MCP_USER_AGENT = `trackly-mcp/${PACKAGE_VERSION}`;
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "trackly-cli",
-  "version": "0.6.2",
+  "version": "0.6.3",
   "mcpName": "io.github.trackly-app/trackly",
   "description": "AI job search CLI + hosted MCP server with OAuth. 128K+ jobs, 1,900+ companies, 40+ ATS. Works with Claude, ChatGPT, Cursor, Windsurf, Codex via hosted streamable-http or local stdio.",
   "bin": {

package/server.json

@@ -17,12 +17,12 @@
       ]
     }
   ],
-  "version": "0.6.2",
+  "version": "0.6.3",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "trackly-cli",
-      "version": "0.6.2",
+      "version": "0.6.3",
       "runtimeHint": "npx",
       "runtimeArguments": [
         {

package/skills/trackly-apply/SKILL.md

@@ -29,13 +29,15 @@ Use Trackly as the source of truth for profile answers, documents, queue decisio
    - Require explicit encrypted-storage consent before saving restricted profile values.
 4. Require the one-time profile confirmation, complete education entries, and a default resume before browser work.
 5. Call `trackly_get_apply_queue`. Select deterministically unless the user names a job. Do not replace the queue call with a fresh job search.
-6. Call `trackly_start_apply_run` for the selected job.
-7. Call `trackly_prepare_resume` with the active application run ID. If hosted MCP reports it unavailable, tell the user that local Trackly MCP or manual upload is required.
+   - If the user requests the next `N` jobs, freeze the deterministic ordered set of exactly `N` job IDs before starting any run. Do not replace, rescore, or expand that approved batch.
+   - For each fixed batch member, preserve an explicit job ID -> application run ID -> browser tab mapping. Complete the full start -> resume preparation -> exact-file confirmation -> pre-attach verification -> form completion -> `review_ready` lifecycle for every member. A review-ready run does not block the next member. Never submit any of them.
+6. Call `trackly_start_apply_run` for the selected job or current fixed batch member.
+7. Call `trackly_prepare_resume` with that exact application run ID. If hosted MCP reports it unavailable, tell the user that local Trackly MCP or manual upload is required.
 8. Preserve the user’s filename returned by `trackly_prepare_resume`. Internal cache identifiers belong only in private parent directories and must never appear in the employer-facing upload filename.
 9. Before any upload, let the user inspect the exact prepared file returned by `trackly_prepare_resume`:
    - Prefer an inline visual preview. Otherwise open the exact local file in Quick Look or Preview.app.
    - Show a compact proof block with source (`Trackly default resume`), exact local path, user-facing filename, file size, SHA-256 fingerprint, application run, and expiration.
-   - Ask for explicit confirmation to use that resume. Bind confirmation to the exact SHA-256 and current application run; a different hash or run requires new confirmation.
+   - Ask for explicit confirmation to use that resume. Bind confirmation to the exact SHA-256 and current application run. For an explicitly approved batch of `N` runs, the user may authorize the same confirmed SHA-256 only for the frozen job/run/tab set; still show and verify each member's exact path, size, hash, run ID, and expiration. Stop if any hash differs, a run is missing, or a run falls outside the frozen batch. Outside that batch, a different hash or run requires new confirmation.
    - Always provide `confirmation.verification.exactLocalPath` so the user can independently verify the file. Never describe the prepared cache path as the original upload source.
    - If an original local source path is known from the current session, identify it separately. Do not store original device paths in Trackly.
    - A generic profile page is not proof of the prepared file. Use an app or web deep link only when the current protocol supplies an authenticated exact-resume viewer tied to the same SHA-256.
@@ -62,23 +64,26 @@ Follow this order:
 2. Inspect the whole form and identify required fields, semantic controls, consent controls, document inputs, and multi-step sections.
 3. Only after the exact-hash visual confirmation and a successful immediate pre-attach `trackly_verify_prepared_resume` check, upload the prepared resume before autofill when parsing may overwrite contact fields. Do not change the file between verification and attachment. Verify that the filename chip exactly matches the prepared resume’s user-facing filename and contains no internal cache identifier. Stop and replace the attachment if it does not.
 4. Fill typed fields from the resolved Trackly profile. Clear parser-filled data when the canonical state is intentionally blank.
-5. Use real UI clicks for React/native selects, radios, and checkboxes. After every selection, verify the committed value and disappearance of the required-field error.
+5. Use real UI clicks for React/native selects, radios, and checkboxes. Resolve boolean values by their exact semantic label (`true` to Yes, `false` to No), never by option order, index, proximity, or a stale prior selection. After every selection, compare the committed value with the canonical Trackly value. If the field is required or had a validation error before selection, verify that the required-field error disappeared. An optional control with no validation error passes when its committed value is correct. Treat any value mismatch or applicable stale error as a failed field and correct it before continuing.
 6. Recheck email and phone through both browser DOM state and macOS accessibility state. Require exact values and reject duplicate/concatenated values.
 7. Complete known optional fields, education, links, relocation, and source answers. Do not silently omit canonical answers.
+   - Treat partial dates as unknown at the missing precision. If Trackly has only a year but the ATS requires a month, ask once and sync the complete date before selecting either control. Never accept an ATS-selected current/default month or infer an education month.
 8. Use the canonical `consent.background_check_if_advanced` field only when the form explicitly asks for consent to a background check if the candidate advances. If it is unknown, ask before selecting it and save the answer at the user's chosen scope. Never infer it from privacy, demographic, recruiting-data, general application, criminal-record, or professional-reference consent. Treat the latter two as separate unknown consent questions unless the current profile schema supplies their own canonical fields.
-9. Run the full integrity gate, including the final consent checkbox, every visible error, all steps, and any correction banner.
+9. For a free-text application response, read [references/application-writing.md](references/application-writing.md). Calibrate from the user's Trackly writing fields, use only supported profile and role facts, and run the built-in voice and anti-slop gate before entering the response. Do not require a separate writing or humanizer skill.
+10. Run the full integrity gate, including the final consent checkbox, every visible error, all steps, and any correction banner.
 
 When the user corrects an answer, immediately save the appropriate scope with `trackly_update_application_profile` and report only a redacted mechanics observation through `trackly_report_apply_observation`. Never promote one user’s value into a global default.
 
 ## Review handoff
 
-Call `trackly_record_application_outcome` with `review_ready`, then provide the review block defined in [references/review-handoff.md](references/review-handoff.md). Keep the browser on the final review state and stop.
+Call `trackly_record_application_outcome` with `review_ready`, then provide the review block defined in [references/review-handoff.md](references/review-handoff.md). For a single run, keep the browser on the final review state and stop. For a frozen batch, preserve the current review-ready tab and continue the same lifecycle for the next mapped batch member; stop only after every frozen member is review-ready, then provide one review block per run. Never submit any member.
 
 After the user submits manually:
 
 - If a success page is visible, record `submitted` with a short non-sensitive confirmation signal.
 - If the user explicitly confirms submission, record `submitted` with `user_confirmed`.
 - If neither exists, do not move the job to applied.
+- Treat a contradictory ATS response such as “already applied” as provisional until the exact requisition URL settles. Do not click Submit again. Preserve the page, confirm the job/requisition identifier is unchanged, and re-read the final route state after the UI and network activity settle. A later explicit success state on that same requisition overrides the provisional error and must be recorded as `submitted`; otherwise record the run as blocked without marking the job applied.
 
 ## Support boundary
 

package/skills/trackly-apply/references/application-writing.md

@@ -0,0 +1,36 @@
+# Application writing integrity
+
+Use this reference for free-text questions such as "Why this company?", motivation, or experience summaries.
+
+## Calibrate once
+
+- Read `writing.voice_sample` and `writing.style_instructions` from the resolved Trackly profile.
+- Offer both optional fields during profile setup, but never block an application run when they are unknown. If a free-text question appears before the user has set them, ask once before drafting and synchronize the answer. Let the user decline a voice sample, choose intentionally blank style instructions, or continue with the plain default style for the current run.
+- Treat the sample and preferences as private user data. Never copy them into the public skill, logs, observations, or another user's defaults.
+- A separate humanizer or writing skill may be used when available, but it is optional. This gate remains authoritative and self-contained.
+
+## Draft from evidence
+
+1. Answer the exact question using only canonical profile facts, resume evidence, and specific facts visible in the job posting.
+2. Lead with the concrete overlap between the user's experience and the role. Avoid generic company praise or unsupported enthusiasm.
+3. Prefer one or two specific proofs over a broad inventory of strengths. Never invent an achievement, employer, skill, or motivation.
+4. Keep the response proportionate to the form. Short questions should receive short answers.
+
+## Match the user's voice
+
+- Match the sample's register, sentence length, paragraph breaks, first-person usage, punctuation, and level of informality.
+- Honor explicit style instructions over generic defaults.
+- Preserve readable quirks and personality. Do not polish every sentence into the same formal register.
+- When no sample is available, default to plain first-person language, short paragraphs, and concrete evidence.
+
+## Anti-slop gate
+
+Before entering the response:
+
+1. Remove generic praise, inflated claims, vague transitions, boilerplate conclusions, and chatbot phrases.
+2. Rewrite `not just X, but Y`, ornamental rule-of-three lists, and dangling `-ing` clauses unless the user's sample clearly uses them naturally.
+3. Use no em dash by default. Use one only when the user's sample or saved instructions show that punctuation is part of their voice.
+4. Vary sentence length and structure. Avoid a sequence of equally sized, equally formal sentences.
+5. Prefer active verbs, concrete nouns, real numbers, and named examples already supported by the profile.
+6. Read the answer aloud. If it sounds like a press release, generic cover letter, or assistant response, rewrite it.
+7. When a voice sample exists, compare the final response with it for rhythm and register. When the sample was declined or remains unknown for the current run, use the saved style instructions or plain default instead. In every case, confirm each factual claim again.

package/skills/trackly-apply/references/form-integrity.md

@@ -6,8 +6,10 @@ Run this gate after each semantic selection and again across the entire form bef
 
 - Open React comboboxes and click the exact list option. Do not inject a value or rely on displayed input text.
 - Click native select options, radio labels, and checkboxes through the UI.
-- After selection, verify the selected/checked state from the control, dispatch-completed page state, and visible label.
-- Verify that the control’s required error is absent. A visible value beside “This field is required” is a failed field.
+- Map booleans semantically: canonical `true` must commit the visible Yes-equivalent and canonical `false` the visible No-equivalent. Never choose a boolean option by index, DOM order, keyboard offset, proximity, or previous control state.
+- After selection, verify the selected/checked state from the control, dispatch-completed page state, and visible label. Compare the normalized committed value to the canonical Trackly value; presence alone is insufficient.
+- If the committed value is the semantic opposite of the canonical value, stop the sweep, correct the field through a fresh real UI selection, and report a redacted integrity observation.
+- For a required control or a control that had a validation error before selection, verify that the error is absent afterward. A visible value beside “This field is required” is a failed field. An optional control that never had a validation error passes when its committed value is correct.
 - If a stale error remains, reopen and reselect the control. Use non-submitting validation only when the ATS provides it.
 
 ## Contact-field integrity
@@ -27,3 +29,10 @@ Run this gate after each semantic selection and again across the entire form bef
 6. Confirm the Submit button is present but do not click it.
 
 If any field’s committed state cannot be observed, fail the gate and explain which field needs manual review.
+
+## Submission-state reconciliation
+
+- Never retry Submit after a contradictory or duplicate-application response.
+- Treat “already applied” and similar banners as provisional until the current ATS route finishes settling.
+- Confirm the employer, role, and exact requisition identifier are unchanged, then re-read the final state from that same URL.
+- An explicit success state on the exact requisition is authoritative and may be recorded as submitted. Without success or explicit user confirmation, record blocked and leave the job out of Applied.