trackly-cli 0.8.1 → 0.9.1

package/README.md

@@ -1,6 +1,6 @@
 [![npm](https://img.shields.io/npm/v/trackly-cli.svg)](https://www.npmjs.com/package/trackly-cli)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
-[![Node 18+](https://img.shields.io/badge/node-18+-brightgreen.svg)](https://nodejs.org/)
+[![Node 20+](https://img.shields.io/badge/node-20+-brightgreen.svg)](https://nodejs.org/)
 [![MCP Server](https://img.shields.io/badge/MCP-Server-blue.svg)](https://modelcontextprotocol.io/)
 
 # trackly-cli
@@ -31,7 +31,7 @@ trackly login
 trackly jobs --function product
 ```
 
-> **Prerequisites:** [Node.js 18+](https://nodejs.org/) (LTS recommended). On macOS with the official `.pkg` installer, global npm installs may require `sudo`.
+> **Prerequisites:** [Node.js 20+](https://nodejs.org/) (LTS recommended). On macOS with the official `.pkg` installer, global npm installs may require `sudo`.
 
 ## At a Glance
 

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

package/mcp/apply-tools.js

@@ -561,7 +561,7 @@ function registerApplyTools(
 
   server.tool(
     'trackly_record_application_outcome',
-    'Record review readiness or a user-confirmed outcome. Mark submitted only after a success page or explicit user confirmation.',
+    'Record review readiness or a user-confirmed outcome. Before handoff use literal outcome=review_ready and verify awaiting_manual_submit. Mark submitted with literal outcome=submitted only after a success page or explicit user confirmation.',
     {
       runId: z.number().int().min(1),
       batchId: z.number().int().min(1).optional(),
@@ -576,7 +576,7 @@ function registerApplyTools(
 
   server.tool(
     'trackly_record_application_outcomes',
-    'Bulk-record up to 20 leased, batch-bound review or user-confirmed outcomes. Each member returns recorded or conflict without hiding sibling results.',
+    'Bulk-record up to 20 leased, batch-bound review or user-confirmed outcomes. Before handoff every item uses literal outcome=review_ready and every recorded run must return awaiting_manual_submit. After manual confirmation use literal outcome=submitted. Each member returns recorded or a stable conflict without hiding sibling results.',
     {
       outcomes: z.array(z.object({
         runId: z.number().int().min(1),
@@ -636,13 +636,13 @@ 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.1 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. 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 and hand off the exact complete subset that is currently review-ready 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.',
+        text: 'Compatibility and batch gate: require Trackly Apply protocol 3.3.1 or newer and skill 4.2.3 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. 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. 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.',
       },
     }, {
       role: 'user',
       content: {
         type: 'text',
-        text: 'Fetch the Trackly Apply protocol, profile onboarding, profile, and approved queue. Resolve missing answers with me. Treat required completeness separately from optional reusable coverage and employer-specific contextual questions. Before starting anything, stop on every non-null executionBlocker and every manual_only item. Start only the selected approved queue item, require major(run.protocolVersion) === major(protocol.version), require protocol.compatibleSkillMajor === 4, preserve the stored version for a resumed run, and require its provider, atsCapability, required scenarios, and originPolicy to match the queue preflight. Reclaim semantic browser control, verify the exact job/run/tab binding, hash that value-free binding, and report the same-run browser_ready attestation with committed=true. Before entering private data, require the visible company and role to match the run binding and, when available, the requisition identifier to match the stored job URL. When job_identity_match is required, report a value-free committed scenario_coverage attestation only after that visible identity check passes; never include the company, role, URL, requisition identifier, page text, or any profile value in that observation. On exact-origin fallback, revalidate the frozen company, role, and available requisition identity after every navigation or redirect and before entering any additional private data. Normalize every page, redirect, and data-receiving iframe URL; accept an exact authorized origin or hostname only when host === allowedDomain or host.endsWith("." + allowedDomain), never by substring or page text. When originPolicy.verification is trackly_employer_source_exact_origin, authorize only the exact origin in authorizedOrigins: never promote it to a host suffix and never carry it across a redirect or iframe origin change. For every other vendor-hosted ATS policy, require both originPolicy.tenantRule and originPolicy.verifiedAtsTenant to be non-null or stop before private data entry. Execute the backend-owned originPolicy.tenantRule exactly after every redirect or data-receiving iframe change, including its extraction, exact-host-depth, locale, percent-decoding, normalization, and fail-closed semantics, then require the normalized result to equal originPolicy.verifiedAtsTenant; never invent or reinterpret a strategy token. Obey every capability stop condition. Determine whether the form has a semantically identified Resume or CV attachment control. Only when that specific control exists, prepare the run-bound resume locally with that browser surface and binding hash, show me its exact path, filename, size, SHA-256, run, and expiration, and obtain my explicit confirmation. Treat cover-letter, portfolio, transcript, and other supporting-document controls separately according to the profile and protocol; never upload a resume to them. Immediately before attaching the resume, use the local verifier to validate the signed proof, recompute hash and size, check expiration, and lock the file read-only. Fill the form through semantic controls, verify committed values and every required error, and report a same-run passed or corrected scenario_coverage observation with committed=true for every backend-required scenario except browser_reclaim, which is satisfied only by browser_ready with the binding hash. Before every review_ready outcome, also report value-free committed critical_contact_integrity and manual_submit_boundary evidence; never include contact values, answers, page text, or local paths. If a required or universal review scenario cannot pass, record blocked rather than review_ready. Stop before Submit. If maintenance interrupts the run, retain the run and browser context, wait for the advertised window, refetch protocol, queue, and profile state, and resume the existing agent_browser run. Never start a duplicate run, blindly retry a mutation, enter credentials or verification codes, evade human verification, or click Submit.',
+        text: 'Fetch the Trackly Apply protocol, profile onboarding, profile, and approved queue. Resolve missing answers with me. Treat required completeness separately from optional reusable coverage and employer-specific contextual questions. Before starting anything, stop on every non-null executionBlocker and every manual_only item. Start only the selected approved queue item, require major(run.protocolVersion) === major(protocol.version), require protocol.compatibleSkillMajor === 4, preserve the stored version for a resumed run, and require its provider, atsCapability, required scenarios, and originPolicy to match the queue preflight. Reclaim semantic browser control, verify the exact job/run/tab binding, hash that value-free binding, and report the same-run browser_ready attestation with committed=true. Before entering private data, require the visible company and role to match the run binding and, when available, the requisition identifier to match the stored job URL. When job_identity_match is required, report a value-free committed scenario_coverage attestation only after that visible identity check passes; never include the company, role, URL, requisition identifier, page text, or any profile value in that observation. On exact-origin fallback, revalidate the frozen company, role, and available requisition identity after every navigation or redirect and before entering any additional private data. Normalize every page, redirect, and data-receiving iframe URL; accept an exact authorized origin or hostname only when host === allowedDomain or host.endsWith("." + allowedDomain), never by substring or page text. When originPolicy.verification is trackly_employer_source_exact_origin, authorize only the exact origin in authorizedOrigins: never promote it to a host suffix and never carry it across a redirect or iframe origin change. For every other vendor-hosted ATS policy, require both originPolicy.tenantRule and originPolicy.verifiedAtsTenant to be non-null or stop before private data entry. Execute the backend-owned originPolicy.tenantRule exactly after every redirect or data-receiving iframe change, including its extraction, exact-host-depth, locale, percent-decoding, normalization, and fail-closed semantics, then require the normalized result to equal originPolicy.verifiedAtsTenant; never invent or reinterpret a strategy token. Obey every capability stop condition. Determine whether the form has a semantically identified Resume or CV attachment control. Only when that specific control exists, prepare the run-bound resume locally with that browser surface and binding hash, show me its exact path, filename, size, SHA-256, run, and expiration, and obtain my explicit confirmation. Treat cover-letter, portfolio, transcript, and other supporting-document controls separately according to the profile and protocol; never upload a resume to them. Immediately before attaching the resume, use the local verifier to validate the signed proof, recompute hash and size, check expiration, and lock the file read-only. Fill every visible field whose answer is already known, including optional fields, before asking one grouped packet for the remaining unknowns. Use real semantic UI actions and the provider playbook for Greenhouse, Ashby, HiBob, or the active capability; after every select, radio, checkbox, masked input, and upload, verify the committed DOM or accessibility state and that any related required error disappeared. Then sweep all required fields, duplicate contact values, correction banners, and the final consent control. Report a same-run passed or corrected scenario_coverage observation with committed=true for every backend-required scenario except browser_reclaim, which is satisfied only by browser_ready with the binding hash. Before every review_ready outcome, also report value-free committed critical_contact_integrity and manual_submit_boundary evidence; never include contact values, answers, page text, or local paths. If a required or universal review scenario cannot pass, record blocked rather than review_ready. Stop before Submit. If maintenance interrupts the run, retain the run and browser context, wait for the advertised window, refetch protocol, queue, and profile state, and resume the existing agent_browser run. Never start a duplicate run, blindly retry a mutation, enter credentials or verification codes, evade human verification, or click Submit.',
       },
     }],
   }));

package/npm-shrinkwrap.json

@@ -1,15 +1,15 @@
 {
   "name": "trackly-cli",
-  "version": "0.8.1",
+  "version": "0.9.1",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "trackly-cli",
-      "version": "0.8.1",
+      "version": "0.9.1",
       "license": "MIT",
       "dependencies": {
-        "@modelcontextprotocol/sdk": "^1.27.1",
+        "@modelcontextprotocol/sdk": "1.30.0",
         "hono": "^4.12.30",
         "zod": "^3.23.0"
       },
@@ -17,28 +17,28 @@
         "trackly": "bin/trackly"
       },
       "engines": {
-        "node": ">=18"
+        "node": ">=20"
       }
     },
     "node_modules/@hono/node-server": {
-      "version": "1.19.14",
-      "resolved": "https://registry.npmjs.org/@hono/node-server/-/node-server-1.19.14.tgz",
-      "integrity": "sha512-GwtvgtXxnWsucXvbQXkRgqksiH2Qed37H9xHZocE5sA3N8O8O8/8FA3uclQXxXVzc9XBZuEOMK7+r02FmSpHtw==",
+      "version": "2.0.12",
+      "resolved": "https://registry.npmjs.org/@hono/node-server/-/node-server-2.0.12.tgz",
+      "integrity": "sha512-eWpQYr67tqJLeaSUl0Q+TquuYfUdTibpOJlUMV2FfUP7+KqCC5TufnwnlXL6mobZBJbGAYRd7ZvEBDCbLInjhg==",
       "license": "MIT",
       "engines": {
-        "node": ">=18.14.1"
+        "node": ">=20"
       },
       "peerDependencies": {
         "hono": "^4"
       }
     },
     "node_modules/@modelcontextprotocol/sdk": {
-      "version": "1.29.0",
-      "resolved": "https://registry.npmjs.org/@modelcontextprotocol/sdk/-/sdk-1.29.0.tgz",
-      "integrity": "sha512-zo37mZA9hJWpULgkRpowewez1y6ML5GsXJPY8FI0tBBCd77HEvza4jDqRKOXgHNn867PVGCyTdzqpz0izu5ZjQ==",
+      "version": "1.30.0",
+      "resolved": "https://registry.npmjs.org/@modelcontextprotocol/sdk/-/sdk-1.30.0.tgz",
+      "integrity": "sha512-xKd8OIzlqNzcqcNumGAa6g+PW2kjD5vrpcKOnfldAUPP3j7lnqMPwlTXQm8gF+UwH72z0lqaRbjr9hqGz0eITA==",
       "license": "MIT",
       "dependencies": {
-        "@hono/node-server": "^1.19.9",
+        "@hono/node-server": "^1.19.9 || ^2.0.5",
         "ajv": "^8.17.1",
         "ajv-formats": "^3.0.1",
         "content-type": "^1.0.5",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "trackly-cli",
-  "version": "0.8.1",
+  "version": "0.9.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": {
@@ -62,11 +62,14 @@
     "url": "https://github.com/trackly-app/trackly-cli/issues"
   },
   "dependencies": {
-    "@modelcontextprotocol/sdk": "^1.27.1",
+    "@modelcontextprotocol/sdk": "1.30.0",
     "hono": "^4.12.30",
     "zod": "^3.23.0"
   },
   "engines": {
-    "node": ">=18"
+    "node": ">=20"
+  },
+  "overrides": {
+    "@hono/node-server": "2.0.12"
   }
 }

package/scripts/verify-audit-exceptions.js

@@ -70,21 +70,9 @@ function validatePolicy(policy) {
   assert.ok(Array.isArray(policy.exceptions));
   assert.equal(
     policy.exceptions.length,
-    1,
-    'Exactly one temporary npm audit exception is permitted',
+    0,
+    'No npm audit exceptions are permitted',
   );
-  const exception = policy.exceptions[0];
-  assert.equal(exception.advisory, 'GHSA-frvp-7c67-39w9');
-  assert.equal(exception.package, '@hono/node-server');
-  assert.equal(exception.dependencyOf, '@modelcontextprotocol/sdk');
-  assert.equal(exception.severity, 'moderate');
-  assert.equal(exception.vulnerableRange, '<2.0.5');
-  assert.equal(
-    exception.upstream,
-    'https://github.com/modelcontextprotocol/typescript-sdk/issues/2531',
-  );
-  assert.ok(exception.expectedAuditShape);
-  return exception;
 }
 
 function validateAuditReport(report, policy) {
@@ -106,7 +94,7 @@ function validateAuditReport(report, policy) {
     );
   }
   assert.equal(report?.auditReportVersion, 2, 'Unsupported npm audit report version');
-  const exception = validatePolicy(policy);
+  validatePolicy(policy);
 
   if (cleanAuditResult(report)) {
     return {
@@ -114,22 +102,9 @@ function validateAuditReport(report, policy) {
       propagatedVulnerabilities: [],
     };
   }
-
-  try {
-    assert.deepEqual(normalizedAuditShape(report), exception.expectedAuditShape);
-  } catch (error) {
-    const wrapped = new Error(
-      'npm audit report does not match the temporary exception. '
-      + 'Review every new advisory, severity, affected range, and dependency-path change.',
-    );
-    wrapped.cause = error;
-    throw wrapped;
-  }
-
-  return {
-    allowedAdvisories: [exception.advisory],
-    propagatedVulnerabilities: Object.keys(report.vulnerabilities).sort(),
-  };
+  throw new Error(
+    'npm audit reported a vulnerability; Trackly CLI permits no audit exceptions.',
+  );
 }
 
 function loadPolicy(policyPath = DEFAULT_POLICY_PATH) {

package/security/audit-exceptions.json

@@ -1,70 +1,4 @@
 {
   "schemaVersion": 1,
-  "exceptions": [
-    {
-      "advisory": "GHSA-frvp-7c67-39w9",
-      "source": 1124006,
-      "package": "@hono/node-server",
-      "dependencyOf": "@modelcontextprotocol/sdk",
-      "severity": "moderate",
-      "vulnerableRange": "<2.0.5",
-      "upstream": "https://github.com/modelcontextprotocol/typescript-sdk/issues/2531",
-      "rationale": "Trackly starts the MCP SDK only through its stdio transport. It does not import @hono/node-server, Streamable HTTP, or serveStatic, so the Windows static-file path traversal is unreachable. Automated stdio isolation and packed-consumer tests enforce that boundary until the SDK removes or upgrades this dependency.",
-      "expectedAuditShape": {
-        "vulnerabilityCounts": {
-          "info": 0,
-          "low": 0,
-          "moderate": 2,
-          "high": 0,
-          "critical": 0,
-          "total": 2
-        },
-        "vulnerabilities": {
-          "@hono/node-server": {
-            "name": "@hono/node-server",
-            "severity": "moderate",
-            "isDirect": false,
-            "via": [
-              {
-                "source": 1124006,
-                "name": "@hono/node-server",
-                "dependency": "@hono/node-server",
-                "title": "Node.js Adapter for Hono: Path traversal in `serve-static` on Windows via encoded backslash (`%5C`)",
-                "url": "https://github.com/advisories/GHSA-frvp-7c67-39w9",
-                "severity": "moderate",
-                "cwe": [
-                  "CWE-22"
-                ],
-                "cvss": {
-                  "score": 5.9,
-                  "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
-                },
-                "range": "<2.0.5"
-              }
-            ],
-            "effects": [
-              "@modelcontextprotocol/sdk"
-            ],
-            "range": "<2.0.5",
-            "nodes": [
-              "node_modules/@hono/node-server"
-            ]
-          },
-          "@modelcontextprotocol/sdk": {
-            "name": "@modelcontextprotocol/sdk",
-            "severity": "moderate",
-            "isDirect": true,
-            "via": [
-              "@hono/node-server"
-            ],
-            "effects": [],
-            "range": ">=1.25.0",
-            "nodes": [
-              "node_modules/@modelcontextprotocol/sdk"
-            ]
-          }
-        }
-      }
-    }
-  ]
+  "exceptions": []
 }

package/server.json

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

package/skills/trackly-apply/SKILL.md

@@ -25,7 +25,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.1 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.3 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.
@@ -47,7 +47,8 @@ and missing-surface recovery contract; they are mandatory even for a one-job bat
    - If the user requests the next `N` jobs, freeze up to `N` available saved jobs before starting any run. Preserve inactive, insecure, or protocol-declared manual-only members with their static exclusion reason; do not replenish, replace, rescore, or expand the batch. If fewer than `N` saved jobs exist, report the frozen count rather than searching for substitutes.
    - 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.
-   - 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.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 batch if support level, execution mode, provider, required scenarios, authorized origin policy, member version, or inspection epoch changes after run creation.
+   - 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.3. 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.
@@ -91,7 +92,7 @@ Follow this order:
 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. 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.
+7. Complete every visible field whose canonical answer is known, including optional fields, previous-employer/title history, education rows and dates, links, relocation, communication preferences, and opportunity source. Before review, compare the live field inventory with the resolved Trackly profile and prove that no known visible answer was silently omitted. Group only genuinely unknown contextual fields into the question packet.
    - 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. 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.
@@ -111,12 +112,13 @@ Every required scenario and both universal evidence scenarios must have correspo
 
 ## Review handoff
 
-After every conditional field is settled and all other review gates pass, bulk checkpoint every ready member with `review/manual_submit`, the current unchanged inspection epoch in both epoch fields, and any `resolvedActionIds`. Use the returned member versions and epochs; this checkpoint resolves the listed human actions and moves the durable member lifecycle to `review_ready` without invalidating current-epoch browser evidence or an unchanged resume-content approval. Do not wait for `needs_input` members: whenever at least one member is durably `review_ready`, ask for one explicit final truthfulness confirmation for the exact complete subset that is currently `review_ready`. If any form in that certified subset used a resume attachment, certify with `resumeDependency: approved` and the exact approved resume identity. If no form in the subset exposes a resume control, certify with `resumeDependency: not_applicable` and omit the resume ID and hash; do not invent an upload requirement. Then call `trackly_record_application_outcomes` once with every member in that certified subset using its exact current `runId`, `batchId`, `memberId`, `inspectionEpoch`, and `leaseToken`; refresh only members returned as conflicts. A member that becomes ready later requires a fresh certification for the then-current complete `review_ready` subset; never reuse an older certification for it. Use singular `trackly_record_application_outcome` only for a legacy single run or an isolated post-review transition. 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 every review-ready tab, hand off each certified review-ready subset without waiting on unrelated human actions, and continue the same lifecycle for the remaining mapped members. Members with unresolved actions stay frozen and resumable. Never submit any member. End with job ID -> run ID -> browser tab -> ATS -> status plus the actual scenario coverage for each run.
+After every conditional field is settled and all other review gates pass, bulk checkpoint every ready member with `review/manual_submit`, the current unchanged inspection epoch in both epoch fields, and any `resolvedActionIds`. Use the returned member versions and epochs; this checkpoint resolves the listed human actions and moves the durable member lifecycle to `review_ready` without invalidating current-epoch browser evidence or an unchanged resume-content approval. Do not wait for `needs_input` members: whenever at least one member is durably `review_ready`, ask for one explicit final truthfulness confirmation for the exact complete subset that is currently `review_ready`. If any form in that certified subset used a resume attachment, certify with `resumeDependency: approved` and the exact approved resume identity. If no form in the subset exposes a resume control, certify with `resumeDependency: not_applicable` and omit the resume ID and hash; do not invent an upload requirement. Then call `trackly_record_application_outcomes` once with every member in that certified subset using its exact current `runId`, `batchId`, `memberId`, `inspectionEpoch`, and `leaseToken`; every item must use the literal `outcome: review_ready`. Verify every recorded run returns `awaiting_manual_submit` before showing the review handoff. A member conflict does not invalidate successful siblings: preserve its tab, refresh that member once, and surface the returned stable conflict code instead of blindly replaying a different transition. A member that becomes ready later requires a fresh certification for the then-current complete `review_ready` subset; never reuse an older certification for it. Use singular `trackly_record_application_outcome` only for a legacy single run or an isolated post-review transition. 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 every review-ready tab, hand off each certified review-ready subset without waiting on unrelated human actions, and continue the same lifecycle for the remaining mapped members. Members with unresolved actions stay frozen and resumable. Never submit any member. End with job ID -> run ID -> browser tab -> ATS -> status plus the actual scenario coverage for each run.
 
 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 record `submitted` with the exact current batch/member/epoch/lease binding and confirmation `success_page`.
-- 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 record `submitted` with the exact current batch/member/epoch/lease binding and confirmation `user_confirmation`.
+- 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`.
+- 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.
 - 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.

package/skills/trackly-apply/references/ats-playbook.md

@@ -4,6 +4,8 @@
 
 - Accept employer-hosted Greenhouse forms and `job-boards.greenhouse.io` / `boards.greenhouse.io` application hosts after matching the employer and role.
 - Expect resume parsing, React selects, correction banners, demographic sections, and final consent checkboxes.
+- Use the visible file chooser or its semantic file input; never click a nearby decorative upload region by coordinates.
+- For custom selects and checkbox groups, verify the selected label or checked element in the live DOM after the real click. A displayed answer with a remaining required error is uncommitted.
 - Treat red required-field text as authoritative even when a value is visible.
 - A Greenhouse “Thank you for applying” page is a valid submission signal.
 
@@ -11,6 +13,9 @@
 
 - Accept `jobs.ashbyhq.com` only after matching the employer and role.
 - Expect rerenders, masked contact inputs, and controls whose visible text can differ from committed state.
+- Resolve binary button groups by the live selected/active state and semantic Yes/No label, never by button order or styling alone.
+- Treat education as repeatable structured rows. After activating `+ Add Education`, require the row count to increase before filling the new row. If Playwright reports a click but the submit-typed control does not add a row, retry with the visible semantic DOM control; stop if the row remains absent.
+- Select localized school suggestions by the exact intended institution and then verify the committed row value.
 - Best effort: stop when browser and accessibility state disagree.
 - An explicit application-success banner/page is a valid submission signal.
 
@@ -37,6 +42,7 @@ This group includes SmartRecruiters, Workable, BambooHR, Recruitee, Jobvite, Tea
 - Expect a mixture of native controls, custom widgets, employer subdomains, embedded frames, shared profile data, and optional resume parsing.
 - Match the live HTTPS origin, employer, role, and requisition before entering private data.
 - Use the same committed-state and required-error gate as Greenhouse. Familiar-looking controls do not lower the evidence requirement.
+- On HiBob, treat document upload as a two-step commit when the UI requires choosing the file and then confirming the upload. Verify the final filename/attachment state; a selected local file alone is not an attached resume.
 
 ## Unknown employer-hosted form
 

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

@@ -38,10 +38,22 @@ For every protocol 3.3.1 request:
 
 Do not recreate a batch after maintenance. Refetch the existing batch, reclaim
 its lease with the latest revision, and resume its existing run bindings.
+When a bound run start returns a transport failure, a non-access HTTP 5xx
+response, or an error explicitly marked `retryable: true`, refetch and renew,
+then retry the same complete binding once. Classify the retry response
+independently with the same rules. Route `maintenance_mode` or the legacy
+`planned_maintenance` alias from either attempt through maintenance recovery.
+Surface controlled-access/request errors marked `retryable: false` and every
+other HTTP 4xx response unchanged, including when returned by the retry. Only a
+second transport failure, non-access HTTP 5xx response, or explicitly
+retryable error becomes `backend_run_start_unavailable` while siblings
+continue. Do not checkpoint this condition: no run ID exists yet, and the
+checkpoint contract requires one. The unchanged frozen member is the durable
+resume point. Never detach that member into a legacy single run.
 
 ### Request budget
 
-For a new 20-member batch, keep recovery, planning, initial binding, evidence,
+For a failure-free new 20-member batch, keep planning, initial binding, evidence,
 two bulk checkpoints, resume approval, truth certification, outcomes, and the
 final batch refresh within 52 non-resume MCP/HTTP requests: one active-batch
 lookup, one create, one page, one claim, 20 run starts, 20 surface bindings, one
@@ -51,7 +63,12 @@ resume approval, one truth certification, one
 `trackly_record_application_outcomes` call, and one final refresh. An existing
 active batch omits the create call. Do not replace bulk observations,
 checkpoints, or outcomes with per-member requests. Resume download and exact
-local verification are excluded from this count.
+local verification are excluded from this count. Each member that encounters
+the one permitted retryable bound-start failure receives exactly three
+additional recovery calls: refetch the active batch, renew its lease, and retry
+the same binding. Therefore the bounded contingency budget is `52 + (3 * R)`,
+where `R` is the number of affected members and cannot exceed 20. Maintenance
+recovery is paced by the advertised window and is tracked separately.
 
 ## Ownership and replay safety
 
@@ -156,11 +173,14 @@ After all conditional questions and certification wording are visible, show one
 final truthfulness prompt. Only after explicit user confirmation, compute the
 value-free answer-snapshot and wording fingerprints and call
 `trackly_certify_apply_batch_truth` for the exact complete subset that is
-currently `review_ready`. A `needs_input` member does not block certification
-or handoff of ready siblings. Never certify an arbitrary subset. When another
-member becomes ready later, obtain a fresh certification for the then-current
-complete `review_ready` subset. Never place the certification or its wording in
-the application profile.
+currently `review_ready`. Then call `trackly_record_application_outcomes` for
+that certified subset; every item must use the literal
+`outcome: review_ready`. Verify every recorded run returns
+`awaiting_manual_submit` before handing the forms to the user. A `needs_input`
+member does not block certification or handoff of ready siblings. Never certify
+an arbitrary subset. When another member becomes ready later, obtain a fresh
+certification for the then-current complete `review_ready` subset. Never place
+the certification or its wording in the application profile.
 
 A membership, profile revision, resume identity or hash, answer snapshot,
 certification wording, or affected inspection epoch change invalidates the
@@ -182,6 +202,11 @@ Never submit a member. After manual submission, mark Applied only from an
 observable success page or explicit user confirmation. Record the submit
 request, success page or `user_confirmation`, and any provider receipt with
 `trackly_record_apply_submission_evidence`; store only the redacted fingerprint
-and typed source. Then reconcile tab closure separately using the
-browser-lifecycle gate. Submission, receipt, and closure never substitute for
-one another.
+and typed source. Then use the separate literal `outcome: submitted`. The
+outcome call is not complete until a fresh batch read shows member lifecycle
+`submitted` and tracker state `applied_confirmed`.
+Preserve the success tab during one documented idempotent conflict recovery;
+if reconciliation remains unsuccessful, report the control-plane defect and
+do not claim completion. Only then reconcile tab closure separately using the
+browser-lifecycle gate. Submission, durable outcome, receipt, and closure never
+substitute for one another.

package/skills/trackly-apply/references/browser-lifecycle.md

@@ -43,6 +43,14 @@ Never make a closure claim from one inventory surface.
 
 ## Close proof
 
+For a submitted application, do not begin tab closure until Trackly has
+durably reconciled both the batch member to `submitted` and the saved job to
+`applied_confirmed`. A success page or explicit user confirmation authorizes
+the outcome write; it does not prove that the write committed. On a conflict,
+keep the tab visible while the agent refreshes and performs the one documented
+idempotent replay. If reconciliation still fails, leave the tab open and
+report a control-plane defect.
+
 `closed_verified` requires all of the following for the current inspection
 epoch: