trackly-cli 0.9.4 → 0.9.5

package/contracts/trackly-apply-tools.json

@@ -1,5 +1,5 @@
 {
-  "contractVersion": "3.3.2",
+  "contractVersion": "3.3.3",
   "constants": {
     "applyScenarioCodes": ["browser_reclaim", "resume_upload", "resume_parser_recheck", "semantic_boolean_commit", "custom_select_commit", "multi_step_navigation", "free_text_voice", "required_error_sweep", "final_consent", "handoff_reclaim", "critical_contact_integrity", "manual_submit_boundary", "job_identity_match"],
     "applyBrowserSurfaces": ["codex_in_app", "chrome_extension", "claude_in_chrome"],

package/lib/agent.js

@@ -8,7 +8,7 @@ const { spawnSync } = require('node:child_process');
 const { apiRequest, downloadFile, getConfigPaths, hasAuth, maintenanceOutput } = require('./client');
 const { version: PACKAGE_VERSION } = require('../package.json');
 const { contractVersion: MCP_CONTRACT_VERSION } = require('../contracts/trackly-apply-tools.json');
-const SKILL_VERSION = '4.2.5';
+const SKILL_VERSION = '4.2.6';
 const CLI_USER_AGENT = `trackly-cli/${PACKAGE_VERSION}`;
 const MCP_USER_AGENT = `trackly-mcp/${PACKAGE_VERSION}`;
 

package/mcp/apply-tools.js

@@ -636,7 +636,7 @@ function registerApplyTools(
       role: 'user',
       content: {
         type: 'text',
-        text: 'Compatibility and batch gate: require Trackly Apply protocol 3.3.1 or newer and skill 4.2.5 or newer for every new frozen batch. Protocol 3.2 remains valid for the explicit legacy single-run workflow. Recover the active frozen batch before creating another, including for a one-job request. Do not fetch or select from the queue until active-batch recovery proves that no active batch exists; any later generic queue-first instruction applies only to the legacy 3.2 single-run workflow. Claim its lease, keep membership/order fixed, inspect all members before asking one grouped packet of questions, bind each initial or recovered browser surface to the same run and exact backend URL, and discard older-epoch evidence. Before mutating a form, inspect only prior-submission evidence the user supplied or evidence already visible on the bound application surface; never search a mailbox or unrelated private-data source. If the member lacks a run/browser binding, use sanctioned idempotent start and exact employer-page binding without entering private data before recording receipt evidence. Treat same-company/different-role evidence as negative for the current member. A receipt proves identity only and never replaces success-page or explicit user-confirmation authority. Schedule accessible members before known credential-gated members without changing frozen membership or order. If a bound start returns a transport failure, a non-access HTTP 5xx response, or an error explicitly marked retryable true, preserve the frozen member and browser state, refetch the same active batch, renew its lease, and retry the same complete binding exactly once. Classify the retry response independently with the same rules: route maintenance_mode or planned_maintenance from either attempt through maintenance recovery, surface controlled-access/request errors marked retryable false and every other HTTP 4xx response unchanged, and only classify a second transport failure, non-access HTTP 5xx response, or explicitly retryable error as backend_run_start_unavailable. Never relabel a permanent retry response as an outage. Preserve the unchanged frozen member as the durable resume point, continue siblings after backend_run_start_unavailable, and never checkpoint the pre-run failure or detach it into an unbound legacy run. Require one exact batch resume approval plus immediate local proof before each attachment; ordinary member-version checkpoints do not revoke unchanged resume-content approval. If no form in a truth-certified subset exposes a resume control, certify truth with resumeDependency not_applicable and no resume identity. After durable review-ready checkpoints, truth-certify the exact complete subset, bulk-record literal outcome=review_ready for every member, and verify every recorded run returns awaiting_manual_submit before handoff without waiting for needs-input members. Keep unresolved members frozen and resumable; when another member becomes ready later, create a fresh certification for the then-current complete review-ready subset. After manual Submit, keep submission request, success-page or explicit user-confirmation, provider receipt, and three-part surface-close proof separate and redacted, then record literal outcome=submitted. Only when both the fetched protocol and the stored run protocol are 3.3.2 or newer may current-epoch exact-requisition success-page or explicit user-confirmation evidence reconcile a running, inspecting, needs_input, review_ready, or request-only submitted projection without fabricated retroactive review evidence. Treat submission reconciliation as a durable commit gate: keep the confirmation tab open until a refetch proves member lifecycle submitted and Trackly job state applied_confirmed. Treat browser-session finalization as destructive cleanup. Before form mutation, require an end-to-end usable preservation path: the documented session finalizer plus complete current controller-owned and user-owned inventory access for its keep list, or a documented per-tab durable-handoff primitive with an exact verified persistence receipt for every target tab; fail browser readiness if neither path is complete. Immediately before finalization, reconcile the complete controller-owned and user-owned inventory union. Use the documented session-level finalizer exactly once as the final browser action with an explicit { tab, status: "handoff" } keep entry for every currently live mapped application tab, including frozen-batch and legacy single-run tabs, or invoke the documented per-tab durable handoff for every live tab and verify each persistence receipt. Never use an omitted, empty, partial, guessed, or stale keep list or an undocumented substitute. If finalization is ambiguous, do not call another browser tool in that turn and do not rerun it; reconcile inventories on the next turn. A user-confirmed direct tab closure may leave the keep list only after the complete inventory union proves the tab is absent; preserve an incomplete member for missing-tab recovery. Before claiming a form is open or visible, reconcile complete controller-owned and user-owned inventories, then use the documented adapter presentation action and verify its visible state or exact user-visible handoff receipt; inventory membership alone is never visibility proof. If that proof is unavailable, preserve the tab, use the visibility-unverified handoff, and do not tell the user to submit until the exact review tab is reclaimed and visibly proven. Keep employment status, intentionally blank current company, and most recent employer distinct; an intentionally blank current company never implies employment status and never erases prior employment. Enter employment and education in reverse chronological order, and use the canonical committed English name or verified catalog option for each school.',
+        text: 'Compatibility and batch gate: require Trackly Apply protocol 3.3.1 or newer and skill 4.2.6 or newer for every new frozen batch. Protocol 3.2 remains valid for the explicit legacy single-run workflow. Recover the active frozen batch before creating another, including for a one-job request. Do not fetch or select from the queue until active-batch recovery proves that no active batch exists; any later generic queue-first instruction applies only to the legacy 3.2 single-run workflow. Claim its lease, keep membership/order fixed, inspect all members before asking one grouped packet of questions, bind each initial or recovered browser surface to the same run and exact backend URL, and discard older-epoch evidence. Before mutating a form, inspect only prior-submission evidence the user supplied or evidence already visible on the bound application surface; never search a mailbox or unrelated private-data source. If the member lacks a run/browser binding, use sanctioned idempotent start and exact employer-page binding without entering private data before recording receipt evidence. Treat same-company/different-role evidence as negative for the current member. A receipt proves identity only and never replaces success-page or explicit user-confirmation authority. Schedule accessible members before known credential-gated members without changing frozen membership or order. If a bound start returns a transport failure, a non-access HTTP 5xx response, or an error explicitly marked retryable true, preserve the frozen member and browser state, refetch the same active batch, renew its lease, and retry the same complete binding exactly once. Classify the retry response independently with the same rules: route maintenance_mode or planned_maintenance from either attempt through maintenance recovery, surface controlled-access/request errors marked retryable false and every other HTTP 4xx response unchanged, and only classify a second transport failure, non-access HTTP 5xx response, or explicitly retryable error as backend_run_start_unavailable. Never relabel a permanent retry response as an outage. Preserve the unchanged frozen member as the durable resume point, continue siblings after backend_run_start_unavailable, and never checkpoint the pre-run failure or detach it into an unbound legacy run. Require one exact batch resume approval plus immediate local proof before each attachment; ordinary member-version checkpoints do not revoke unchanged resume-content approval. If no form in a truth-certified subset exposes a resume control, certify truth with resumeDependency not_applicable and no resume identity. After durable review-ready checkpoints, truth-certify the exact complete subset, bulk-record literal outcome=review_ready for every member, and verify every recorded run returns awaiting_manual_submit before handoff without waiting for needs-input members. Keep unresolved members frozen and resumable; when another member becomes ready later, create a fresh certification for the then-current complete review-ready subset. After manual Submit, keep submission request, success-page or explicit user-confirmation, provider receipt, and three-part surface-close proof separate and redacted, then record literal outcome=submitted. With a fetched server protocol of 3.3.2 or newer, current-epoch exact-requisition success-page or explicit user-confirmation evidence may reconcile a stale projection when the stored run protocol is 3.3.2 or newer. A stored protocol 3.3.1 run may be repaired only from retained current-epoch explicit user-confirmation evidence; protocol 3.3.1 success-page evidence remains ineligible. Never fabricate retroactive review evidence. Treat submission reconciliation as a durable commit gate: keep the confirmation tab open until a refetch proves member lifecycle submitted and Trackly job state applied_confirmed. Treat browser-session finalization as destructive cleanup. Before form mutation, require an end-to-end usable preservation path: the documented session finalizer plus complete current controller-owned and user-owned inventory access for its keep list, or a documented per-tab durable-handoff primitive with an exact verified persistence receipt for every target tab; fail browser readiness if neither path is complete. Immediately before finalization, reconcile the complete controller-owned and user-owned inventory union. Use the documented session-level finalizer exactly once as the final browser action with an explicit { tab, status: "handoff" } keep entry for every currently live mapped application tab, including frozen-batch and legacy single-run tabs, or invoke the documented per-tab durable handoff for every live tab and verify each persistence receipt. Never use an omitted, empty, partial, guessed, or stale keep list or an undocumented substitute. If finalization is ambiguous, do not call another browser tool in that turn and do not rerun it; reconcile inventories on the next turn. A user-confirmed direct tab closure may leave the keep list only after the complete inventory union proves the tab is absent; preserve an incomplete member for missing-tab recovery. Before claiming a form is open or visible, reconcile complete controller-owned and user-owned inventories, then use the documented adapter presentation action and verify its visible state or exact user-visible handoff receipt; inventory membership alone is never visibility proof. If that proof is unavailable, preserve the tab, use the visibility-unverified handoff, and do not tell the user to submit until the exact review tab is reclaimed and visibly proven. Keep employment status, intentionally blank current company, and most recent employer distinct; an intentionally blank current company never implies employment status and never erases prior employment. Enter employment and education in reverse chronological order, and use the canonical committed English name or verified catalog option for each school.',
       },
     }, {
       role: 'user',
@@ -648,7 +648,7 @@ function registerApplyTools(
       role: 'user',
       content: {
         type: 'text',
-        text: 'Protocol capability clarification: stale-projection reconciliation for success-page or explicit user-confirmation evidence is available only when both the fetched Apply protocol and the stored run.protocolVersion are 3.3.2 or newer. Preserve an existing success_page confirmation when a later user_confirmation triggers repair. If either version is 3.3.1, preserve the confirmation tab and use only the normal review-ready transition when valid; otherwise report that the backend must update. Read and write prior-employer answers through the canonical global keys employment.most_recent_company and employment.most_recent_title only when the fetched profile schema exposes those exact keys. If an exposed key is unknown, ask once and sync only the confirmed value. If a key is absent, do not PATCH it; retain the answer only for the current form and report the schema gap.',
+        text: 'Protocol capability clarification: Require skill 4.2.6 or newer. With fetched Apply protocol 3.3.2 or newer, stale-projection reconciliation is available for current-epoch exact-requisition success-page or explicit user-confirmation evidence when stored run.protocolVersion is 3.3.2 or newer. A stored protocol 3.3.1 run may be repaired only from retained current-epoch explicit user-confirmation evidence; protocol 3.3.1 success-page evidence remains ineligible. Preserve an existing success_page confirmation when a later user_confirmation triggers repair. Read and write prior-employer answers through the canonical global keys employment.most_recent_company and employment.most_recent_title only when the fetched profile schema exposes those exact keys. If an exposed key is unknown, ask once and sync only the confirmed value. If a key is absent, do not PATCH it; retain the answer only for the current form and report the schema gap.',
       },
     }, {
       role: 'user',

package/npm-shrinkwrap.json

@@ -1,12 +1,12 @@
 {
   "name": "trackly-cli",
-  "version": "0.9.4",
+  "version": "0.9.5",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "trackly-cli",
-      "version": "0.9.4",
+      "version": "0.9.5",
       "license": "MIT",
       "dependencies": {
         "@modelcontextprotocol/sdk": "1.30.0",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "trackly-cli",
-  "version": "0.9.4",
+  "version": "0.9.5",
   "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.9.4",
+  "version": "0.9.5",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "trackly-cli",
-      "version": "0.9.4",
+      "version": "0.9.5",
       "runtimeHint": "npx",
       "runtimeArguments": [
         {

package/skills/trackly-apply/SKILL.md

@@ -26,7 +26,7 @@ Before selecting or resuming work, read
 references define the server-frozen batch, grouped-question, tab-reconciliation,
 and missing-surface recovery contract; they are mandatory even for a one-job batch.
 
-1. Call `trackly_get_apply_protocol`. Skill 4.2.5 requires protocol major 3 and protocol 3.3.1 or newer for frozen-batch execution; protocol 3.2 remains valid for the explicit legacy single-run workflow. Require `compatibleSkillMajor: 4` and `compatibleSkillMinimumVersion` no newer than this installed skill. Reject an older or incompatible version and report that the backend must finish updating or `trackly agent setup` must update the skill. Protocol 3.2 added exact-origin trust for jobs Trackly ingested directly from employer careers sources; do not recreate the retired ownership-timestamp gate in the client.
+1. Call `trackly_get_apply_protocol`. Skill 4.2.6 requires protocol major 3 and protocol 3.3.1 or newer for frozen-batch execution; protocol 3.2 remains valid for the explicit legacy single-run workflow. Require `compatibleSkillMajor: 4` and `compatibleSkillMinimumVersion` no newer than this installed skill. Reject an older or incompatible version and report that the backend must finish updating or `trackly agent setup` must update the skill. Protocol 3.2 added exact-origin trust for jobs Trackly ingested directly from employer careers sources; do not recreate the retired ownership-timestamp gate in the client.
 2. Call `trackly_get_profile_onboarding` or fetch both the profile schema and application profile. Treat `completeness.percent` as required onboarding readiness only. Use `coverage.missingReusableKeys` to explain reusable optional gaps, while `coverage.contextualKeys` are intentionally asked only on the relevant employer form. Do not claim that 100% required completeness answers every possible application question.
 3. Save answers with `trackly_update_application_profile`:
    - Use `answered`, `intentionally_blank`, `declined`, or `unknown` exactly.
@@ -53,7 +53,7 @@ and missing-surface recovery contract; they are mandatory even for a one-job bat
    - For each fixed batch member, preserve an explicit job ID -> application run ID -> browser tab mapping. Complete the full start -> conditional resume preparation/confirmation/verification when an upload control exists -> 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 with the complete `batchId`, `memberId`, `expectedMemberVersion`, `expectedInspectionEpoch`, and `leaseToken` returned by Trackly. This call is also the sanctioned idempotent lookup when a recovered member has no `runId`; call it with the exact recovered binding and Trackly will reuse the bound active run. Never create a replacement run because browser control was interrupted.
    - If a bound start returns a transport failure, a non-access HTTP 5xx response, or an error explicitly marked `retryable: true`, preserve the frozen member and browser state. Refetch the active batch, renew its lease, and retry the same complete binding once. Classify the retry response independently with these same rules: route canonical `maintenance_mode` or legacy `planned_maintenance` directly through **Resume after maintenance**; surface controlled-access/request errors marked `retryable: false` and every other HTTP 4xx response unchanged; only a second transport failure, non-access HTTP 5xx response, or explicitly retryable error becomes `backend_run_start_unavailable`. Route maintenance on either attempt without consuming or relabeling the retry, and never relabel a permanent retry response as an outage. For `backend_run_start_unavailable`, continue other members and report a Trackly control-plane failure. Do not call `trackly_checkpoint_apply_batch` for this condition because start failure has not produced the required run ID. The unchanged frozen member is the durable resume point. Never switch that frozen member to an unbound legacy run or blame the employer form.
-   - Require `run.protocolVersion` to be 3.1.0 or newer and to share protocol major 3 with the fetched protocol. A new batch member requires 3.3.1 or newer; an explicit 3.2 single run may start or finish through its legacy path. Never continue a pre-evidence 3.0.x run under skill 4.2.5. Preserve that run instead of starting a replacement, record it `blocked` with a value-free protocol-upgrade reason when possible, and tell the user the saved job can be retried only after the stale run is cleared through Trackly's supported lifecycle. Stop and refetch the protocol and active batch if support level, execution mode, provider, required scenarios, authorized origin policy, member version, or inspection epoch changes after run creation.
+   - Require `run.protocolVersion` to be 3.1.0 or newer and to share protocol major 3 with the fetched protocol. A new batch member requires 3.3.1 or newer; an explicit 3.2 single run may start or finish through its legacy path. Never continue a pre-evidence 3.0.x run under skill 4.2.6. Preserve that run instead of starting a replacement, record it `blocked` with a value-free protocol-upgrade reason when possible, and tell the user the saved job can be retried only after the stale run is cleared through Trackly's supported lifecycle. Stop and refetch the protocol and active batch if support level, execution mode, provider, required scenarios, authorized origin policy, member version, or inspection epoch changes after run creation.
    - In guided mode, inspect the page before preparing any resume bytes. Confirm the employer, role, HTTPS origin, reachable review path, semantic controls, whether an attachment control exists, and absence of a credential, verification, CAPTCHA, or submit-only wall. A missing file input is not itself a blocker; skip the resume path when the application has no attachment control. Any other failed precondition is an execution blocker, not permission to improvise.
 7. Pass the browser readiness gate before preparing resume bytes:
    - Use semantic browser control through Codex in-app browser controls, Chrome MCP/extension browser control, or Claude in Chrome.
@@ -125,7 +125,8 @@ After every conditional field is settled and all other review gates pass, bulk c
 After the user submits manually:
 
 - If a success page is visible, reclaim the current batch lease if needed, first record current-epoch `confirmation_detected` evidence with source `success_page` through `trackly_record_apply_submission_evidence`, then use the separate literal `outcome: submitted` with the exact current batch/member/epoch/lease binding and confirmation `success_page`.
-- Only when both the freshly fetched protocol and the stored `run.protocolVersion` are 3.3.2 or newer may current-epoch exact-requisition `success_page` or explicit `user_confirmation` evidence reconcile a stored run/member projection that still says `running`, `inspecting`, `needs_input`, `review_ready`, or only the request says `submitted`. Record the typed evidence and outcome without fabricating a retroactive review-ready checkpoint or truth certification. Preserve an existing `success_page` confirmation when a later `user_confirmation` triggers repair. If either version is 3.3.1, do not assume this repair exists: preserve the confirmation tab, use only the normal documented review-ready transition when it is still valid, and otherwise report that the backend must update before reconciliation. In every case, preserve the confirmation tab until a refetch proves member lifecycle `submitted` and job state `applied_confirmed`.
+- With a freshly fetched server protocol of 3.3.2 or newer, current-epoch exact-requisition `success_page` or explicit `user_confirmation` evidence may reconcile a stored run/member projection that still says `running`, `inspecting`, `needs_input`, `review_ready`, or only the request says `submitted` when the stored run protocol is 3.3.2 or newer. The server may also repair a stored protocol 3.3.1 run, but only from retained current-epoch explicit `user_confirmation` evidence; protocol 3.3.1 `success_page` evidence remains ineligible for this stale-projection repair. Record the typed evidence and outcome without fabricating a retroactive review-ready checkpoint or truth certification. Preserve an existing `success_page` confirmation when a later `user_confirmation` triggers repair. In every case, preserve the confirmation tab until a refetch proves member lifecycle `submitted` and job state `applied_confirmed`.
+- If the freshly fetched server protocol is still 3.3.1, do not attempt stale-projection repair, including for a stored 3.3.1 run. Preserve the confirmation tab, use the ordinary review-ready transition only when its normal preconditions are satisfied, and otherwise report that the backend must finish updating before repair can proceed.
 - If the user explicitly confirms submission, reclaim the current batch lease if needed, first record current-epoch `confirmation_detected` evidence with source `user_confirmation` through `trackly_record_apply_submission_evidence`, then use the separate literal `outcome: submitted` with the exact current batch/member/epoch/lease binding and confirmation `user_confirmation`.
 - Treat the outcome response as a durable commit gate. Refetch each submitted member and require both member lifecycle `submitted` and Trackly job state `applied_confirmed`. On conflict, preserve the success tab, refresh once, and replay only the documented idempotent evidence/outcome sequence. If reconciliation still fails, report a P0 reconciliation defect and leave the tab open; never claim Trackly moved the job.
 - A provider receipt is optional orthogonal evidence. Record it as `provider_receipt_detected`; never use `provider_receipt` as the outcome confirmation or as a substitute for a success page or explicit user confirmation.