🎩 You're Invited:Meet the Socket team at Black Hat in Las Vegas, August 3-6.RSVP →
trackly-cli
Advanced tools
trackly-cli - npm Package Compare versions
+1
-1
@@ -11,3 +11,3 @@ 'use strict'; | ||
| const { contractVersion: MCP_CONTRACT_VERSION } = require('../contracts/trackly-apply-tools.json'); | ||
| const SKILL_VERSION = '4.4.0'; | ||
| const SKILL_VERSION = '4.4.1'; | ||
| const CLI_USER_AGENT = `trackly-cli/${PACKAGE_VERSION}`; | ||
@@ -14,0 +14,0 @@ const MCP_USER_AGENT = `trackly-mcp/${PACKAGE_VERSION}`; |
@@ -120,3 +120,3 @@ 'use strict'; | ||
| const APPLY_RELIABILITY_PROMPT = 'Protocol 3.5 / skill 4.4 reliability gate: after execution recovery or start, fetch one compact execution snapshot with only the current member IDs and profile keys required by the visible forms. Treat mutable and allowedOperations as authoritative. Never reopen or mutate authentication, account-creation, OTP, pre-form-CAPTCHA, or manual-only members. Only an explicit user request may call trackly_resume_parked_apply_member, and the returned member still requires a fresh non-mutating access probe. Use execution-scoped exact-resume content approval across unchanged replacement waves, but immediately verify the exact local path, hash, size, run binding, and expiration before every upload. Run trackly_lint_application_text before entering free text and fail closed on every violation or unsupported claim. Diagnose I/O errors only against the exact implicated path. Report the server funnel and durable milestone after every state change and at least once every 60 seconds during active work. Never click Submit.'; | ||
| const APPLY_RELIABILITY_PROMPT = 'Protocol 3.5 / skill 4.4.1 reliability gate: only active=true identifies resumable execution work. A response with active=false and preserved=true is terminal read-only reconciliation evidence. Require nextAction=none and never fetch its compact snapshot, continue an unresolved wave, mutate a member, or interpret historical funnel counts as current work. For an active execution recovery or start, fetch one compact execution snapshot with only the current member IDs and profile keys required by the visible forms. Treat mutable and allowedOperations as authoritative. Never reopen or mutate authentication, account-creation, OTP, pre-form-CAPTCHA, or manual-only members. Only an explicit user request may call trackly_resume_parked_apply_member, and the returned member still requires a fresh non-mutating access probe. Use execution-scoped exact-resume content approval across unchanged replacement waves, but immediately verify the exact local path, hash, size, run binding, and expiration before every upload. Run trackly_lint_application_text before entering free text and fail closed on every violation or unsupported claim. Diagnose I/O errors only against the exact implicated path. Report the server funnel and durable milestone after every state change and at least once every 60 seconds during active work. Never click Submit.'; | ||
@@ -123,0 +123,0 @@ function registerApplyTools( |
| { | ||
| "name": "trackly-cli", | ||
| "version": "0.13.0", | ||
| "version": "0.13.1", | ||
| "lockfileVersion": 3, | ||
@@ -9,3 +9,3 @@ "requires": true, | ||
| "name": "trackly-cli", | ||
| "version": "0.13.0", | ||
| "version": "0.13.1", | ||
| "license": "MIT", | ||
@@ -12,0 +12,0 @@ "dependencies": { |
+1
-1
| { | ||
| "name": "trackly-cli", | ||
| "version": "0.13.0", | ||
| "version": "0.13.1", | ||
| "mcpName": "io.github.trackly-app/trackly", | ||
@@ -5,0 +5,0 @@ "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.", |
+2
-2
@@ -20,3 +20,3 @@ { | ||
| ], | ||
| "version": "0.13.0", | ||
| "version": "0.13.1", | ||
| "packages": [ | ||
@@ -26,3 +26,3 @@ { | ||
| "identifier": "trackly-cli", | ||
| "version": "0.13.0", | ||
| "version": "0.13.1", | ||
| "runtimeHint": "npx", | ||
@@ -29,0 +29,0 @@ "runtimeArguments": [ |
@@ -25,2 +25,8 @@ # Batch orchestration | ||
| is active, continue through the fixed-batch compatibility path. | ||
| Only `active: true` identifies resumable execution work. When the response is | ||
| `active: false` and `preserved: true`, the returned terminal execution exists | ||
| only so submission and browser evidence can be reconciled. Do not fetch its | ||
| compact snapshot, mutate a member, reopen an unresolved wave, or follow its | ||
| historical funnel. Require `progress.nextAction: none`; then continue the | ||
| user's current request through the normal new-execution or legacy-batch gate. | ||
| Never create a second execution because context or tabs were lost. Read | ||
@@ -31,6 +37,12 @@ `response.progress` and `response.progress.nextAction`; never reconstruct execution progress from | ||
| explain the mismatch and obtain explicit confirmation. Then stop the old | ||
| execution with reason `target_changed`, refetch and verify its terminal state, | ||
| and only then start the new target. If the user asks to stop, stop it with | ||
| reason `user_requested` using the latest revision and a fresh idempotency key, | ||
| then refetch and verify `stopped` or `closed` before reporting completion. | ||
| execution with reason `target_changed`, verify the exact execution reports | ||
| `stopped` or `closed` from the stop response or | ||
| `trackly_get_apply_execution`, and refetch until the active-execution response | ||
| says `active: false`. A terminal execution is returned with `preserved: true` | ||
| only when reconciliation evidence remains; its absence is not a blocker after | ||
| the exact execution is terminal. Only then start the new target without | ||
| continuing the stopped wave. If the user asks to stop, use reason | ||
| `user_requested` with the latest revision and a fresh idempotency key, verify | ||
| the exact terminal status, then refetch until `active: false` and never | ||
| continue its unresolved waves before reporting completion. | ||
| The start call itself returns that authoritative funnel at `response.progress` | ||
@@ -37,0 +49,0 @@ and its directive at `response.progress.nextAction`. Consume that response immediately before opening, claiming, or |
@@ -30,3 +30,3 @@ --- | ||
| 1. Call `trackly_get_apply_protocol`. Skill 4.4.0 requires protocol 3.5.0 or newer for new reliability work. Protocol 3.2 remains valid only for an already-active explicit legacy single run; an already-active explicit 3.2 single run may finish through its legacy path. Preserve the protocol's documented recovery paths for already-active older work. Require `compatibleSkillMajor: 4` and `compatibleSkillMinimumVersion` no newer than this installed skill. Reject an older or incompatible version for new work 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.4.1 requires protocol 3.5.0 or newer for new reliability work. Protocol 3.2 remains valid only for an already-active explicit legacy single run; an already-active explicit 3.2 single run may finish through its legacy path. Preserve the protocol's documented recovery paths for already-active older work. Require `compatibleSkillMajor: 4` and `compatibleSkillMinimumVersion` no newer than this installed skill. Reject an older or incompatible version for new work 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. When present, render `schema.screens` in ascending `order` as one grouped question packet per screen. Within a screen, preserve category `order` and then field `order`; use each field's user-facing `rationale` when the user asks why it is needed. Ask only unknown or confirmation-needed fields and honor `consistencyRules` before submitting profile changes, resolving contradictions with the user instead of guessing. When `schema.screens` is absent on a legacy backend, fall back to the existing category-based onboarding behavior. 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. | ||
@@ -48,3 +48,3 @@ 3. Save answers with `trackly_update_application_profile`: | ||
| 4. Require the one-time profile confirmation, complete education entries, and default-resume metadata before browser work. Do not prepare or upload the resume when the form has no attachment control. | ||
| 5. For every protocol 3.4 or newer request, call `trackly_get_active_apply_execution` before legacy recovery. Only with protocol 3.5 or newer and an enabled compact-snapshot capability may recovery or new work call `trackly_get_apply_execution_snapshot`, using only the current member IDs, profile keys needed by the visible forms, and actual browser surface. An already-active protocol 3.4 execution is read-only legacy recovery: use only its published get or stop operations, never call the 3.5-only snapshot, resume, approval, advance, or disposition tools, and never mutate its browser forms. For protocol 3.5 or newer, treat snapshot `mutable` and `allowedOperations` values as authoritative. Never mutate or reopen authentication, account-creation, OTP, pre-form-CAPTCHA, or manual-only members. Only an explicit user request may call `trackly_resume_parked_apply_member`; the returned member still requires a fresh non-mutating probe before private data or form mutation. Resume unresolved waves in ascending order and obey the server `nextAction` and funnel. Never reconstruct progress or choose replacements locally. Count only `durablyReviewReady` and `submitted`; let the backend own reservations, capacity, attempted-job deduplication, immutable waves, and advancement. Continue until `targetReached`, `queueExhausted`, a blocking `nextAction`, or the user stops. | ||
| 5. For every protocol 3.4 or newer request, call `trackly_get_active_apply_execution` before legacy recovery. Resume execution work only when the response says `active: true`. A response with `preserved: true` and `active: false` exposes a stopped, closed, or otherwise terminal execution only for read-only reconciliation. Never fetch its compact snapshot, continue its wave, mutate its members, or interpret historical `currentlyFilling` or reservation counts as current work; require `progress.nextAction: none`. Only with protocol 3.5 or newer and an enabled compact-snapshot capability may an active recovery or new execution call `trackly_get_apply_execution_snapshot`, using only the current member IDs, profile keys needed by the visible forms, and actual browser surface. An already-active protocol 3.4 execution is read-only legacy recovery: use only its published get or stop operations, never call the 3.5-only snapshot, resume, approval, advance, or disposition tools, and never mutate its browser forms. For protocol 3.5 or newer, treat snapshot `mutable` and `allowedOperations` values as authoritative. Never mutate or reopen authentication, account-creation, OTP, pre-form-CAPTCHA, or manual-only members. Only an explicit user request may call `trackly_resume_parked_apply_member`; the returned member still requires a fresh non-mutating probe before private data or form mutation. Resume unresolved waves in ascending order only for `active: true` and obey the server `nextAction` and funnel. Never reconstruct progress or choose replacements locally. Count only `durablyReviewReady` and `submitted`; let the backend own reservations, capacity, attempted-job deduplication, immutable waves, and advancement. Continue until `targetReached`, `queueExhausted`, a blocking `nextAction`, or the user stops. | ||
| - Every compact snapshot request must contain a non-empty list of only the current member IDs. Never request an empty or inferred all-members projection. | ||
@@ -55,4 +55,4 @@ - Recover every entry in `execution.unresolvedWaves` in ascending `waveOrder`; `currentWave` identifies only the latest scheduling wave, not the complete recovery set. | ||
| - Recover an existing execution even when `batchOrchestration.accessibleExecution.enabled` is false. When disabled and an execution is active, recover it read-only; never start, advance, or record dispositions. Use only get or stop operations. | ||
| - If the active execution target differs from the user's requested target, explain the mismatch and require explicit confirmation. Only then stop it with reason `target_changed`, refetch and verify a terminal state, and start the replacement target. | ||
| - When the user asks to stop, call `trackly_stop_apply_execution` with reason `user_requested`, refetch the execution, and verify that it reached `stopped` or `closed` before claiming completion. | ||
| - If the active execution target differs from the user's requested target, explain the mismatch and require explicit confirmation. Only then stop it with reason `target_changed`, verify the exact execution reached `stopped` or `closed` from the stop response or `trackly_get_apply_execution`, and refetch until the active-execution response says `active: false`. A terminal execution appears with `preserved: true` only when reconciliation evidence remains, so its absence is not a blocker after the exact execution is terminal. Start the replacement target without continuing the stopped wave. | ||
| - When the user asks to stop, call `trackly_stop_apply_execution` with reason `user_requested`, verify the exact execution reached `stopped` or `closed` from the stop response or `trackly_get_apply_execution`, refetch until `active: false`, and never continue its unresolved waves. If the response also says `preserved: true`, keep that record read-only for reconciliation; do not require preservation when no unresolved evidence remains. | ||
| - After every durable milestone and at least once every 60 seconds during active browser work, send the compact progress receipt from [references/review-handoff.md](references/review-handoff.md). Use the server funnel, never chat-derived counts. | ||
@@ -75,3 +75,3 @@ - When the user explicitly asks to inspect the next `N` queue records, retain the fixed-batch contract. If a `complete_next_n_accessible` execution is active and the inspection request changes the target or mode, explain the active work, obtain explicit confirmation, stop it with reason `target_changed`, and then call `trackly_get_active_apply_batch`, resume that batch when present, or create exactly one immutable batch with `trackly_create_apply_batch`. Do not replenish, replace, rescore, or expand the batch. Never silently continue an old execution after the user changes the requested mode. | ||
| - 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 reliability execution member requires 3.5.0 or newer; already-active older work may use only the recovery path published by its fetched protocol. Never continue a pre-evidence 3.0.x run under skill 4.4.0. 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 execution or 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 reliability execution member requires 3.5.0 or newer; already-active older work may use only the recovery path published by its fetched protocol. Never continue a pre-evidence 3.0.x run under skill 4.4.1. 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 execution or 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. | ||
@@ -78,0 +78,0 @@ 7. Pass the browser readiness gate before preparing resume bytes: |
New alerts
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Fixed alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Improved metrics
- Total package byte prevSize
456008
0.49%- Lines of code
5043
0.02%Worsened metrics
- Number of low supply chain risk alerts
25
4.17%No dependency changes