trackly-cli 0.13.0 → 0.13.1

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.4.0';
+const SKILL_VERSION = '4.4.1';
 const CLI_USER_AGENT = `trackly-cli/${PACKAGE_VERSION}`;
 const MCP_USER_AGENT = `trackly-mcp/${PACKAGE_VERSION}`;
 

package/mcp/apply-tools.js

@@ -117,7 +117,7 @@ const startApplyRunSchema = z.object({
   }
 });
 
-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.';
 
 function registerApplyTools(
   server,

package/npm-shrinkwrap.json

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

package/package.json

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

package/skills/trackly-apply/SKILL.md

@@ -27,7 +27,7 @@ references define the server-frozen batch, grouped-question, tab-reconciliation,
 and missing-surface recovery contract; they are mandatory even for a one-job batch.
 Read [references/legal-clarifications.md](references/legal-clarifications.md) when a form asks for a legal, regulatory, consent, or employer-relationship decision.
 
-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.
 3. Save answers with `trackly_update_application_profile`:
    - Use `answered`, `intentionally_blank`, `declined`, or `unknown` exactly.
@@ -44,14 +44,14 @@ Read [references/legal-clarifications.md](references/legal-clarifications.md) wh
    - Use `writing.em_dash_policy` and `writing.optional_question_policy` when the fetched schema exposes them. An unanswered em-dash policy fails closed to `forbid` for form writing.
    - Infer a direct prior-employer answer of No only when the profile explicitly marks history complete, the target and backend-confirmed aliases are absent, and the question is limited to direct employment. Ask for subsidiary, affiliate, acquisition, contractor, or otherwise ambiguous relationships.
 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.
    - Recover every entry in `execution.unresolvedWaves` in ascending `waveOrder`; `currentWave` identifies only the latest scheduling wave, not the complete recovery set.
    - Immediately consume the start response's authoritative `progress` and `nextAction`; do not issue a speculative advance first.
    - When that authoritative `nextAction` requests another wave, call `trackly_advance_apply_execution` with the actual current `browserSurface`, latest execution revision, and a fresh idempotency key.
    - 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.
    - 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.
    - Apply the same confirmation boundary in reverse. If the user asks for `complete_next_n_accessible` while an immutable fixed batch is active, do not silently resume that incompatible record set and do not start an execution beside it. Explain the mismatch and summarize any submitted, review-ready, and unresolved work before browser mutation. If the user chooses to finish it, resume only its exact members. If the user says to start fresh, leave, replace, discard, or otherwise abandon the fixed batch, that statement is explicit cancellation confirmation: refetch the latest batch revision, call `trackly_cancel_apply_batch` with reason `user_requested_restart` and a fresh idempotency key, then refetch until no active fixed batch remains. Preserve every existing browser tab but treat its controls as no longer mutation-authorized. Start the requested accessible execution in the same turn. Never wait for expiry or create a reminder/continuation card merely to escape an obsolete batch. If cancellation returns `submission_in_progress`, preserve everything and stop for the user; do not cancel or start replacement work.
@@ -69,7 +69,7 @@ Read [references/legal-clarifications.md](references/legal-clarifications.md) wh
    - 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. When the selected job or current fixed batch member has no `runId`, call `trackly_start_apply_run` with the complete `batchId`, `memberId`, `expectedMemberVersion`, `expectedInspectionEpoch`, and `leaseToken` returned by Trackly. This is the sanctioned idempotent lookup for a recovered member whose `runId` is absent; call it with the exact recovered binding and Trackly will reuse the bound active run. When the member already has a `runId`, do not call `trackly_start_apply_run` in this or any subsequent start step: reuse that exact run and bind or recover its browser surface through `trackly_bind_apply_surface` as required. 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 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.
 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.

package/skills/trackly-apply/references/batch-orchestration.md

@@ -22,15 +22,27 @@ hidden from legacy recovery. When disabled and one is active, recover it
 read-only and permit only get or stop operations; never start, advance, or
 record dispositions until the capability is enabled. When disabled and none
 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
 `response.progress` and `response.progress.nextAction`; never reconstruct execution progress from
 chat, browser tabs, or a client-side queue.
 If a new fill/apply request changes the target from the active execution,
 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`
 and its directive at `response.progress.nextAction`. Consume that response immediately before opening, claiming, or
 mutating a browser surface; do not issue a blind advance or infer a first wave.