trackly-cli 0.17.0 → 0.18.0

package/mcp/server.js

@@ -6,10 +6,12 @@ const { McpError } = require('@modelcontextprotocol/sdk/types.js');
 const { z } = require('zod');
 const { apiRequest, createTracklyAccessError, hasAuth, maintenanceOutput } = require('../lib/client');
 const { version: PACKAGE_VERSION } = require('../package.json');
+const APPLY_CONTRACT = require('../contracts/trackly-apply-tools.json');
 const { registerApplyTools } = require('./apply-tools');
 const { configureMcpAnalytics, shutdownMcpAnalytics } = require('./analytics');
 
 const MCP_USER_AGENT = `trackly-mcp/${PACKAGE_VERSION}`;
+const MCP_SHUTDOWN_TIMEOUT_MS = 2_000;
 const MCP_MAINTENANCE_ERROR_CODE = -32002;
 const MCP_ACCESS_ERROR_CODE = -32003;
 const MCP_AUTH_ERROR_CODE = -32004;
@@ -82,6 +84,11 @@ const SORT_VALUES = ['newest', 'match'];
 // stage value, NOT the legacy action name. Hoisted to module scope so it's not
 // rebuilt on every tool invocation.
 const ACTION_TO_STAGE = { applied: 'applied', saved: 'backlog', dismissed: 'discarded' };
+const APPLY_BATCH_CONFLICT_CODES = new Set(
+  Array.isArray(APPLY_CONTRACT.constants?.applyBatchConflictCodes)
+    ? APPLY_CONTRACT.constants.applyBatchConflictCodes.filter((code) => typeof code === 'string')
+    : [],
+);
 
 function createErrorResult(error, fallbackMessage, extra = {}) {
   const normalizedMaintenance = maintenanceOutput(error);
@@ -110,6 +117,17 @@ function createErrorResult(error, fallbackMessage, extra = {}) {
     payload.status = error.status;
   }
 
+  // Apply batch conflicts are a versioned, bounded error surface. Preserve a
+  // code only when the HTTP envelope and code both match the published
+  // contract; never reflect arbitrary backend error properties into MCP data.
+  if (
+    error?.status === 409
+    && error?.error === 'apply_batch_conflict'
+    && APPLY_BATCH_CONFLICT_CODES.has(error?.conflictCode)
+  ) {
+    payload.conflictCode = error.conflictCode;
+  }
+
   if (
     error?.code === 'experience_filter_v2_unavailable'
     || error?.code === 'invalid_preference_revision'
@@ -597,31 +615,98 @@ async function startMcpServer(options = {}) {
 
 function installMcpSignalHandlers(server, options = {}) {
   const signalTarget = options.signalTarget || process;
+  const input = options.input || process.stdin;
+  const output = options.output || process.stdout;
   const exit = options.exit || ((code) => process.exit(code));
   const shutdownAnalytics = options.shutdownAnalytics || shutdownMcpAnalytics;
+  const shutdownTimeoutMs = options.shutdownTimeoutMs ?? MCP_SHUTDOWN_TIMEOUT_MS;
+  const closeServer = options.closeServer || (() => server.close());
+  const reportInputError = options.reportInputError || ((error) => {
+    const message = error instanceof Error ? error.message : String(error);
+    process.stderr.write(`MCP stdin error: ${message}\n`);
+  });
+  const reportOutputError = options.reportOutputError || ((error) => {
+    const message = error instanceof Error ? error.message : String(error);
+    process.stderr.write(`MCP stdout error: ${message}\n`);
+  });
   let terminating = false;
   const handlers = new Map();
+  let inputEndHandler;
+  let inputCloseHandler;
+  let inputErrorHandler;
+  let outputErrorHandler;
   const cleanup = () => {
     for (const [signal, handler] of handlers) {
       signalTarget.removeListener(signal, handler);
     }
     handlers.clear();
+    if (inputEndHandler) input.removeListener('end', inputEndHandler);
+    if (inputCloseHandler) input.removeListener('close', inputCloseHandler);
+    if (inputErrorHandler) input.removeListener('error', inputErrorHandler);
+    if (outputErrorHandler) output.removeListener('error', outputErrorHandler);
+  };
+  const terminate = (exitCode) => {
+    if (terminating) return;
+    terminating = true;
+    let shutdownTimer;
+    const shutdown = Promise.resolve()
+      .then(() => closeServer())
+      .catch(() => {})
+      .then(() => shutdownAnalytics(server))
+      .catch(() => {});
+    const deadline = new Promise((resolve) => {
+      shutdownTimer = setTimeout(resolve, shutdownTimeoutMs);
+    });
+    void Promise.race([shutdown, deadline])
+      .finally(() => {
+        clearTimeout(shutdownTimer);
+        // Keep signal and pipe handlers installed until teardown settles so a
+        // repeated disconnect cannot restore Node's default early termination.
+        cleanup();
+        exit(exitCode);
+      });
   };
   for (const [signal, exitCode] of [['SIGINT', 130], ['SIGTERM', 143]]) {
-    const handler = () => {
-      if (terminating) return;
-      terminating = true;
-      void Promise.resolve()
-        .then(() => shutdownAnalytics(server))
-        .catch(() => {})
-        .finally(() => {
-          cleanup();
-          exit(exitCode);
-        });
-    };
+    const handler = () => terminate(exitCode);
     handlers.set(signal, handler);
     signalTarget.on(signal, handler);
   }
+
+  // A stdio client can disappear without sending a signal. Close the MCP
+  // transport explicitly so its onclose hooks run instead of relying on the
+  // Node event loop to happen to become empty.
+  inputEndHandler = () => terminate(0);
+  inputCloseHandler = () => terminate(0);
+  inputErrorHandler = (error) => {
+    reportInputError(error);
+    terminate(1);
+  };
+  input.on('end', inputEndHandler);
+  input.on('close', inputCloseHandler);
+  input.on('error', inputErrorHandler);
+
+  // A response racing with client teardown can reach a closed stdout pipe.
+  // Treat only EPIPE as a normal disconnect; preserve fail-fast behavior for
+  // every unrelated stream failure.
+  outputErrorHandler = (error) => {
+    if (error?.code === 'EPIPE') {
+      terminate(0);
+      return;
+    }
+    reportOutputError(error);
+    terminate(1);
+  };
+  output.on('error', outputErrorHandler);
+
+  // A pipe may close while startMcpServer is awaiting transport connection,
+  // before these process-level handlers can be installed.
+  if (input.errored) {
+    inputErrorHandler(input.errored);
+  } else if (output.errored) {
+    outputErrorHandler(output.errored);
+  } else if (input.readableEnded || input.destroyed || output.writableEnded || output.destroyed) {
+    terminate(0);
+  }
   return cleanup;
 }
 

package/npm-shrinkwrap.json

@@ -1,17 +1,17 @@
 {
   "name": "trackly-cli",
-  "version": "0.17.0",
+  "version": "0.18.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "trackly-cli",
-      "version": "0.17.0",
+      "version": "0.18.0",
       "license": "MIT",
       "dependencies": {
         "@modelcontextprotocol/sdk": "1.30.0",
         "@posthog/mcp": "0.11.0",
-        "fast-uri": "3.1.5",
+        "fast-uri": "3.1.7",
         "hono": "4.13.0",
         "ip-address": "10.4.0",
         "posthog-node": "5.48.1",
@@ -440,9 +440,9 @@
       }
     },
     "node_modules/es-object-atoms": {
-      "version": "1.1.1",
-      "resolved": "https://registry.npmjs.org/es-object-atoms/-/es-object-atoms-1.1.1.tgz",
-      "integrity": "sha512-FGgH2h8zKNim9ljj7dankFPcICIK9Cp5bm+c2gQSYePhpaG5+esrLODihIorn+Pe6FGJzWhXQotPv73jTaldXA==",
+      "version": "1.1.2",
+      "resolved": "https://registry.npmjs.org/es-object-atoms/-/es-object-atoms-1.1.2.tgz",
+      "integrity": "sha512-HWcBoN6NileqtSydK2FqHbS/LoDd2pqrnQHLyJzBj4kOp/ky2MWMN694xOfkK8/SnUsW2DH7EfyVlydKCsm1Zw==",
       "license": "MIT",
       "dependencies": {
         "es-errors": "^1.3.0"
@@ -555,9 +555,9 @@
       "license": "MIT"
     },
     "node_modules/fast-uri": {
-      "version": "3.1.5",
-      "resolved": "https://registry.npmjs.org/fast-uri/-/fast-uri-3.1.5.tgz",
-      "integrity": "sha512-gHwA1O9LDIcKunMKhObS/HimwtehO1nPUECKAu5TpKgaO19fcWEl4bliWe1jWxVFvIXztJjjQ4L8XQ1EU9f7Jw==",
+      "version": "3.1.7",
+      "resolved": "https://registry.npmjs.org/fast-uri/-/fast-uri-3.1.7.tgz",
+      "integrity": "sha512-dOvZVzjdZdz7phd9v6jCbwxrBW3fK6n8Rc0CtdmM4bumzMnxywBYhuph6J819RRw/ku+rLbelwfMunktuzVVHg==",
       "funding": [
         {
           "type": "github",
@@ -680,9 +680,9 @@
       }
     },
     "node_modules/hasown": {
-      "version": "2.0.3",
-      "resolved": "https://registry.npmjs.org/hasown/-/hasown-2.0.3.tgz",
-      "integrity": "sha512-ej4AhfhfL2Q2zpMmLo7U1Uv9+PyhIZpgQLGT1F9miIGmiCJIoCgSmczFdrc97mWT4kVY72KA+WnnhJ5pghSvSg==",
+      "version": "2.0.4",
+      "resolved": "https://registry.npmjs.org/hasown/-/hasown-2.0.4.tgz",
+      "integrity": "sha512-T2UbfbBEF32wiepXIsMlTW9+dDYC6wMh/t/vYA4tuOMKqWz/n3vr1NFSxQiyP+zk2mXsoMA/i/7qV6LKut1t1A==",
       "license": "MIT",
       "dependencies": {
         "function-bind": "^1.1.2"
@@ -976,12 +976,13 @@
       }
     },
     "node_modules/qs": {
-      "version": "6.15.2",
-      "resolved": "https://registry.npmjs.org/qs/-/qs-6.15.2.tgz",
-      "integrity": "sha512-Rzq0KEyX/w/tEybncDgdkZrJgVUsUMk3xjh3t5bv3S1HTAtg+uOYt72+ZfwiQwKdysThkTBdL/rTi6HDmX9Ddw==",
+      "version": "6.16.0",
+      "resolved": "https://registry.npmjs.org/qs/-/qs-6.16.0.tgz",
+      "integrity": "sha512-h6fhOIaRrID2CbEY2fqs+7t+UXZo+MLAnU5gRIq85uFtdiUPCdsApMlHhXogKVM4HM2DVbIjGNTTYH2OcmP1vA==",
       "license": "BSD-3-Clause",
       "dependencies": {
-        "side-channel": "^1.1.0"
+        "es-define-property": "^1.0.1",
+        "side-channel": "^1.1.1"
       },
       "engines": {
         "node": ">=0.6"
@@ -1118,14 +1119,14 @@
       }
     },
     "node_modules/side-channel": {
-      "version": "1.1.0",
-      "resolved": "https://registry.npmjs.org/side-channel/-/side-channel-1.1.0.tgz",
-      "integrity": "sha512-ZX99e6tRweoUXqR+VBrslhda51Nh5MTQwou5tnUDgbtyM0dBgmhEDtWGP/xbKn6hqfPRHujUNwz5fy/wbbhnpw==",
+      "version": "1.1.1",
+      "resolved": "https://registry.npmjs.org/side-channel/-/side-channel-1.1.1.tgz",
+      "integrity": "sha512-6x6dK6zJdpTzF4sQeNYxwtvBzf6Eg4GtlesS94HOvTudUeyK2WXAaIfmDgsyslYrRBeFIlsi54AYsFGUuhmvrQ==",
       "license": "MIT",
       "dependencies": {
         "es-errors": "^1.3.0",
-        "object-inspect": "^1.13.3",
-        "side-channel-list": "^1.0.0",
+        "object-inspect": "^1.13.4",
+        "side-channel-list": "^1.0.1",
         "side-channel-map": "^1.0.1",
         "side-channel-weakmap": "^1.0.2"
       },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "trackly-cli",
-  "version": "0.17.0",
+  "version": "0.18.0",
   "mcpName": "io.github.trackly-app/trackly",
   "description": "AI job search CLI + hosted MCP server with OAuth. 170K+ jobs, 3,800+ companies, 40+ ATS. Works with Claude, ChatGPT, Cursor, Windsurf, Codex via hosted streamable-http or local stdio.",
   "bin": {
@@ -10,6 +10,7 @@
     "test": "node --test",
     "test:contract-fixture": "node --test test/apply-contract.test.js",
     "test:hosted-contract": "node scripts/verify-hosted-contract.js",
+    "test:review-auth-contract": "node scripts/verify-review-auth-contract.js",
     "security:audit": "node scripts/verify-audit-exceptions.js"
   },
   "files": [
@@ -64,7 +65,7 @@
   "dependencies": {
     "@modelcontextprotocol/sdk": "1.30.0",
     "@posthog/mcp": "0.11.0",
-    "fast-uri": "3.1.5",
+    "fast-uri": "3.1.7",
     "hono": "4.13.0",
     "ip-address": "10.4.0",
     "posthog-node": "5.48.1",
@@ -75,8 +76,9 @@
   },
   "overrides": {
     "@hono/node-server": "2.0.12",
-    "fast-uri": "3.1.5",
-    "ip-address": "10.4.0"
+    "fast-uri": "3.1.7",
+    "ip-address": "10.4.0",
+    "qs": "6.16.0"
   },
   "devDependencies": {
     "@babel/parser": "7.29.8",

package/server.json

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

package/skills/trackly-apply/SKILL.md

@@ -35,7 +35,7 @@ value-free phase receipt with `scripts/validate-phase-checkpoint.js` before
 claiming that phase complete.
 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.7.0 requires protocol 3.6.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.8.0 requires protocol 3.7.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.
@@ -53,13 +53,14 @@ Read [references/legal-clarifications.md](references/legal-clarifications.md) wh
    - 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. 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. Treat backend `achievementCount`, target-capped `completed`, `targetReached`, and `nextAction` as authoritative. `durablyReviewReady` and `submitted` remain current operator projections and must never be added together by the client to reconstruct cumulative completion. Let the backend own reservations, capacity, attempted-job deduplication, immutable waves, and advancement. Continue until `targetReached`, `queueExhausted`, a blocking `nextAction`, or the user stops.
-   - After full local context loss with no active execution, call `trackly_list_recoverable_apply_executions`. For every distinct returned `jobId`, call `trackly_get_job`, bind that Trackly-owned job record to the returned `candidateId`, and show the user its company, role, requisition identity when available, and source-execution identity; do not identify candidates from chat, tab order, search results, or page copy. A missing or mismatched Trackly job record blocks confirmation. Require explicit confirmation of one exact candidate set, then call `trackly_recover_exact_apply_members` with that source execution, snapshot hash, and only those candidate IDs. Verify `assertedCandidateIds`, `eligibleCandidateIds`, and the eligibility candidate IDs each contain exactly the confirmed set with no duplicates. Never add substitutes, newly saved jobs, or merely similar roles.
+   - After full local context loss with no active execution, call `trackly_list_recoverable_apply_executions`. For every distinct returned `jobId`, call `trackly_get_job`, bind that Trackly-owned job record to the returned `candidateId`, and show the user its company, role, requisition identity when available, source-execution identity, and `accessKnowledge` scheduling reason when present; do not identify candidates from chat, tab order, search results, or page copy. A missing or mismatched Trackly job record blocks confirmation. An active personal deferment on any confirmed candidate blocks recovery until that deferment is cleared. Require explicit confirmation of one exact candidate set, then call `trackly_recover_exact_apply_members` with that source execution, snapshot hash, and only those candidate IDs. Verify `assertedCandidateIds`, `eligibleCandidateIds`, and the eligibility candidate IDs each contain exactly the confirmed set with no duplicates. Never add substitutes, newly saved jobs, or merely similar roles. Curated or historical walls stay in the exact recovered set as parked members and still require explicit resume plus a fresh probe.
    - Exact recovery restores server lineage only. Treat tab restored, form state restored, and mutation authority restored as three independent receipts. Bind every recovered surface with a fresh recovery binding and inspection epoch, revalidate the full form, and preserve every user-edited or unknown non-empty value before any write. Earlier-epoch browser, field, upload, integrity, and submission evidence cannot authorize the recovered form.
    - 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.
    - When a visible form asks an office-scoped profile question and the exact employer office is known, request that field only through the matching member's `officeProjections` entry using the canonical `companyId:office-identity` scope. Consume only the returned `memberOfficeProfiles` entry for that same member and exact office; never move an office answer into the global profile map or reuse it for another member, employer, or office. A recovered member may reuse the answer only when Trackly proves its frozen company identity. If a legacy snapshot cannot prove that identity, preserve the form and treat the answer as unknown instead of refilling from chat or current mutable job metadata.
    - 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.
+   - 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. Pause on every returned immutable `proposedWave`, including ordinary OPEN or neutral proposals. Before asking for approval, show each server-frozen member in `memberPosition` order with its job ID, company, title, provider, requisition URL, and value-free scheduling reason; require the single projected `proposedWave` identity to match the corresponding `accessProposal.members[]` identity exactly. Missing, noncontiguous, or mismatched identity blocks approval; never substitute current search results, chat, browser state, or a later job lookup for the frozen proposal. Obtain the user's explicit approval of that exact ordered set, then call `trackly_advance_apply_execution` again with the unchanged `accessProposal.members[].jobId` order, its server-provided `accessProposal.approvalHash`, returned revision, same browser surface, and a fresh idempotency key. After `createdWave: true`, never reapprove that wave; ask only for a later `nextAction: access_review` where no wave was created. Never substitute a synthetic hash or infer approval from an earlier request to apply generally. Never describe a proposed job as accessible until the current live probe proves applicant fields. `freshLiveProbeRequired` remains true for every classification; curated OPEN never changes `allowedOperations` to `fill_form`.
+   - Progress may include `availableCandidateCount` and `deferredCandidateCount`. When `nextAction` is `access_review`, display the bounded deferred proposal, do not open a browser, and do not report the queue as exhausted. Offer probe, clear-deferment, stop, or expiry. Probe exact deferred job IDs only with the server-provided hash-bound `accessReviewApproval` after any active personal deferment for those jobs is cleared. List deferments with `trackly_list_apply_access_deferments`, create one with `trackly_defer_apply_access` from `jobId` and scope `job`, `company`, or `provider`, and clear one with `trackly_clear_apply_access_deferment` using a discovered deferment id. Provider scope is the approved global access-policy boundary: the backend derives the provider from the stable job anchor and blocks that provider across companies, proposal approval, recovery, and replay until explicitly cleared. Persist a provider exclusion only after the current authenticated user explicitly requests that policy; never infer a Workday, Eightfold, or other provider preference from this shared skill. Never submit a URL, provider name, or free-text identity.
    - 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`, 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.
@@ -80,7 +81,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.6.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.7.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.7.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.8.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.
    - 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,13 +126,15 @@ Follow this order:
 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 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.
+   - Before asking, query the typed scopes in [references/answer-resolution.md](references/answer-resolution.md) from narrowest to broadest and retain only value-free counts and fingerprints. Semantic similarity may find a canonical intent candidate but never supplies an answer.
+   - Account for every visible control with exactly one typed disposition and validate the `fill` receipt. Reconcile all canonical education records and position-level employment records, then audit every resume stage separately. Aggregate counts or a successful upload call alone are not completeness proof.
    - Enter education and employment-history rows in reverse chronological order, with the most recent or current record first.
    - Keep employment status, current company, and most recent employer distinct. An intentionally blank current company remains blank and never implies an employment status; read employment status independently from its canonical profile field or ask once. The blank also does not erase prior employment. For “most recent employer/title,” use `employment.most_recent_company` and `employment.most_recent_title` only after the fetched profile schema exposes those exact keys. If an exposed key is unknown, ask once and sync the confirmed value globally through `trackly_update_application_profile` instead of inserting the current-company blank or inventing an employer. If either key is absent from the fetched schema, do not PATCH it; preserve the answer locally for the current form and report that the backend schema must update.
    - Use the canonical English school name from Trackly when the ATS offers that exact committed option. If a closed ATS selector does not offer it, select only a verified catalog option for the same institution; never leave free-typed text as though it were committed.
    - 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). Draft from supported profile and role facts, then run Humanizer automatically when available. Treat its output as a new revision: rebuild the complete local claim-reference packet against that exact final text, set `claimsComplete: true` only after confirming that the packet covers the whole revision, and then call `trackly_lint_application_text`. Apply the self-contained gate whether or not Humanizer is available, and do not block the application merely because Humanizer is unavailable. Do not enter the answer until the exact final revision passes deterministic lint and every claim has a supported evidence reference. Omitting claim metadata is a blocking lint failure, including for drafts the agent believes contain no claims.
-10. Run the full integrity gate, including the final consent checkbox, every visible error, all steps, and any correction banner.
+10. Run the full integrity gate, including the final consent checkbox, every visible error, all steps, and any correction banner. Reinventory after conditional reveals and require the final form-inventory fingerprint to cover the exact current surface.
 
 If browser startup or file work reports `ENOSPC`, `EACCES`, quota, or another I/O error, call `trackly_diagnose_local_path` on the exact implicated path before explaining the cause. Never generalize one path failure to the whole disk without matching measured evidence.
 
@@ -155,7 +158,7 @@ the sole active receipt returned by Trackly; if multiple receipts remain, ask
 the user to identify the intended group. Never guess a receipt from tabs or
 chat history.
 
-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. Use the normal review block in [references/review-handoff.md](references/review-handoff.md) only after documented visibility proof for the exact review tab succeeds. If visibility is unverified, preserve the tab, use the separate visibility-unverified block, and do not tell the user to submit until the tab is reclaimed and visibly proven. 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`, literal `continuationAllowed: false`, the current unchanged inspection epoch in both epoch fields, and any `resolvedActionIds`. Preserve the accepted checkpoint response and use its 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. On `Apply checkpoint action fields are invalid` or another schema rejection, refetch once and fail closed unless the current public contract proves an exact compatible payload. Never retry a malformed payload or claim durable readiness. 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. After that confirmation is recorded, validate the value-free review receipt against the preserved accepted checkpoint response and current visibility proof; include the resolved-action count and fingerprint, never the raw IDs. 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. Use the normal review block in [references/review-handoff.md](references/review-handoff.md) only after documented visibility proof for the exact review tab succeeds. Always validate a `handoff` receipt that reports employer, Trackly, and browser state separately. If visibility is unverified, preserve the tab, set `reviewReadyClaimed: false`, use the separate visibility-unverified block, and do not tell the user to submit until the tab is reclaimed and visibly proven. 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:
 

package/skills/trackly-apply/references/access-probe.md

@@ -66,3 +66,8 @@ durably terminal. A provider hint is scheduling input, never sufficient proof.
 
 When browser and accessibility surfaces disagree, use
 `unknown_unobservable`. Never upgrade uncertainty to accessibility.
+
+Keep the audit UI's four labels (`OPEN`, `ACCOUNT WALL`, `VARIES`, `UNKNOWN`)
+separate from these detailed live classifications. Curated `OPEN` and recent
+accessibility can schedule a probe; they never authorize `fill_form`.
+`freshLiveProbeRequired` remains true for every proposed member.

package/skills/trackly-apply/references/answer-resolution.md

@@ -32,6 +32,23 @@ revision, schema key, scope, authority class, derivation rule when any,
 expected type, and committed-control receipt. Never send the answer value in
 an observation.
 
+## Typed answer-memory lookup
+
+Before asking, query every applicable scope in this narrow-to-broad order:
+run-only live choice, exact question and version, exact office, jurisdiction,
+company, provider, then global. A candidate is reusable only when its canonical
+intent, type, sensitivity, question version when applicable, and permitted
+scope all match. The first compatible narrower answer wins; an answer never
+flows to a broader scope without explicit user confirmation.
+
+Question-ontology aliases, semantic retrieval, and form-schema history may
+identify candidate canonical intents, but they are not answer authority. Exact
+typed profile or contextual state must still resolve the value. Fail closed to
+`missing_fact`, `live_consent`, or `forbidden_inference` when intent, type,
+scope, version, or confidence is ambiguous. Record only per-scope counts and a
+lowercase SHA-256 over value-free lookup inputs and decisions; never hash or
+persist labels, answers, page text, or private values in the checkpoint.
+
 ## Source precedence
 
 The current profile revision is the only reusable answer authority. A
@@ -40,6 +57,14 @@ or cached value is never authority. Resume parsing is a suggestion only: it may
 help identify a schema key, but the parser never becomes authority and never
 overwrites an answered profile value or a user-edited control.
 
+For a frozen batch, distinguish its frozen profile revision (the audit and
+certification baseline) from the current bounded snapshot projection used to
+resolve visible answers. A later scoped answer may legitimately appear in the
+current projection while the frozen baseline number remains unchanged. Do not
+treat that difference as corruption, do not silently substitute the stale
+baseline value, and do not mutate until the current work receipt authorizes the
+projection and certification behavior.
+
 Contact details and addresses must resolve from exact current profile keys.
 Verify their live committed state even when the browser initially displays a
 masked or formatted value.

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

@@ -3,6 +3,12 @@
 Protocol 3.4 adds a server-owned Apply execution above immutable child batches.
 Protocol 3.6 adds exact-member recovery after local context loss and scoped
 review-handoff reconciliation.
+Protocol 3.7 adds access-aware scheduling: curated ATS defaults, user
+deferments, and live-probe observations produce frozen `accessKnowledge` on
+every proposed-wave member, batch member, compact snapshot member, and
+recovery candidate. Historical knowledge can schedule work but can never
+authorize form filling.
+
 After context loss, rediscover active handoff receipts with
 `trackly_list_apply_review_handoffs`; never reconstruct or guess a handoff ID
 from chat history, tab order, or application similarity.
@@ -58,10 +64,57 @@ draft, question, review, submission, or closure obligation after a newer
 replacement wave was created. Use `response.execution.currentWave.batchId`
 only as the latest scheduling identity when following `response.progress.nextAction`; it is not
 the complete recovery set. For an advance response that creates a wave, use
-its top-level `response.batchId`. Never guess across those response shapes. If
+its top-level `response.batchId` and the immutable `proposedWave` with frozen
+`accessKnowledge` receipts. Never guess across those response shapes. If
 the applicable field is null or `unresolvedWaves` is empty, follow
 `response.progress.nextAction` rather than guessing a prior batch.
 
+## Access-aware scheduling
+
+Every proposed-wave member, execution-owned batch member, compact snapshot
+member, and recovery candidate includes `accessKnowledge`. Use it only to
+schedule. A fresh non-mutating live probe is still required before private
+data or form mutation.
+
+Rank `OPEN`, then neutral `VARIES`/`UNKNOWN`, then fresh `ACCOUNT WALL`. Never
+select an active user deferment automatically. Workday starts as `ACCOUNT WALL`,
+is authentication-gated for this workflow, and must not be opened for a browser
+probe while Greenhouse or other `OPEN`/neutral alternatives exist. Eightfold
+starts as `ACCOUNT WALL`, is independently authentication-gated, and must not be
+opened for a browser probe under the same condition. Static safety exclusions
+always override `OPEN`.
+An active job, company, or provider deferment is an unconditional no-browser
+rule, regardless of whether another accessible candidate remains.
+
+Read `progress.availableCandidateCount`, `progress.deferredCandidateCount`, and
+`nextAction`. When `nextAction` is `access_review`, return the bounded deferred
+proposal, open nothing, and do not report the queue as exhausted. Probe those
+exact job IDs only with hash-bound `accessReviewApproval` after clearing any
+active personal deferment. List, defer, or clear deferments only through
+`trackly_list_apply_access_deferments`, `trackly_defer_apply_access`, and
+`trackly_clear_apply_access_deferment` using a Trackly `jobId`; never submit a
+URL, provider name, or raw chat. Scope `provider` is the approved global
+user-policy boundary: the server derives that identity and blocks matching
+candidates across companies, proposal approval, recovery, and replay. Create a
+provider deferment only after the current authenticated user explicitly requests
+that persistent provider policy; never infer it from this shared skill.
+
+Pause after every `proposedWave`. Same-key advance replay returns the same
+member IDs, order, and rationale. Browser probing requires explicit wave
+approval, including when every proposed job is OPEN or neutral. Show every
+server-frozen member in exact `memberPosition` order with its job ID, company,
+title, provider, requisition URL, and a short value-free reason such as
+“Greenhouse default: OPEN, audited 6 days ago; fresh probe still required.”
+Require each simple `proposedWave` identity to equal the corresponding rich
+`accessProposal.members[]` identity. Missing, noncontiguous, or mismatched
+identity blocks approval; never substitute chat, browser state, search results,
+or a later mutable job lookup. Never describe a proposed job as accessible until the current
+probe proves it. Bind approval to the unchanged
+ordered `accessProposal.members[].jobId` values and the exact server-provided
+`accessProposal.approvalHash`; never invent a hash or reuse a general request
+to apply as approval of a specific proposed wave.
+`freshLiveProbeRequired` remains true for every classification.
+
 ## Exact recovery after local context loss
 
 When no active execution exists but unfinished lineage may still be retained,
@@ -70,7 +123,8 @@ and candidates are the complete bounded recovery menu. Resolve every distinct
 returned `jobId` through `trackly_get_job`, bind that Trackly-owned record to
 its `candidateId`, and present its company, role, requisition identity when
 available, and source execution to the user. A missing or mismatched Trackly
-job record blocks confirmation. Require explicit confirmation of the exact
+job record blocks confirmation. An active personal deferment on any confirmed
+candidate blocks recovery until that deferment is cleared. Require explicit confirmation of the exact
 candidate set. Never infer the set from browser tabs, conversation memory,
 search results, page copy, employer similarity, or queue position.
 
@@ -201,7 +255,8 @@ For an execution request:
 5. bring accessible members through the ordinary batch integrity and review
    gates; and
 6. refetch progress, then call `trackly_advance_apply_execution` only when the
-   current wave has no unclassified member.
+   current wave has no unclassified member. Pause on the returned
+   `proposedWave`. Follow `nextAction: access_review` without opening a browser.
 
 For an explicit fixed inspection request or legacy recovery:
 

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

@@ -6,11 +6,24 @@ other.
 
 ## Capability gate
 
-Before opening a file chooser, require the active browser adapter to advertise
-all five capabilities: semantic control discovery, chooser arming, file
-attachment, committed-filename inspection, and parser-field recheck. If any is
-missing, fail closed before opening the chooser and hand the upload to the user. Never
-navigate to a `file://` URL or paste a local path into an ordinary text field.
+Before an automated upload, require the active browser adapter to advertise all
+five capabilities: semantic control discovery, chooser arming, file attachment,
+committed-filename inspection, and parser-field recheck. If only chooser arming
+or file attachment is unavailable, fail closed before opening the chooser and
+hand the upload to the user only when semantic control discovery,
+committed-filename inspection, and parser-field recheck remain available. If
+any of those three verification capabilities is unavailable, stop the fill as
+unverified; do not route it into `manual_unbound`, claim a passed audit, or
+continue to review. Never navigate to a `file://` URL or paste a local path into
+an ordinary text field.
+
+When the user performs that handoff upload, keep it explicitly manual,
+browser-local, and unbound. Record `resumeAudit.mode: manual_unbound`,
+`approval: passed`, `preAttachVerification: not_applicable`, and
+`attachmentCommit: user_confirmed` only for this genuine manual path; do not use
+those values for an agent-performed upload or a failed verifier. Before
+continuing, require `passed` filename verification and parser recheck, then
+prove during the `passed` final sweep that the attachment and filename persist.
 
 Perform these stages in exact order:
 
@@ -19,14 +32,19 @@ Perform these stages in exact order:
 3. prove the chooser opened;
 4. run `trackly_verify_prepared_resume`, then immediately attach that verified
    file through the adapter's documented file-setting primitive;
-5. verify the employer-facing filename committed; and
+5. verify the employer-facing filename committed;
 6. recheck every contact, employment, education, and other field that resume
-   parsing may have changed.
+   parsing may have changed; and
+7. during the final sweep, prove the attachment is still committed and the
+   visible filename remains the approved employer-facing filename.
 
 Pass only the value-free stage outcomes to
 `trackly_validate_apply_resume_upload`. Do not pass a filename, local path,
 resume hash, form value, URL, page text, or tab identifier. Claim attachment
-success only when it returns `safeToClaimAttachment: true`.
+success only when it returns `safeToClaimAttachment: true`. Record the six
+audited outcomes separately: approval, pre-attach verification, attachment
+commit, filename verification, parser recheck, and final-sweep persistence. A
+single upload-success boolean cannot replace this chain.
 
 Stable failure codes include capability unavailable, ambiguous control,
 chooser timeout, chooser opened without a commit, missing or expired file,

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

@@ -2,6 +2,28 @@
 
 Run this gate after each semantic selection and again across the entire form before review.
 
+## Whole-form accounting
+
+Create one accounting row for every visible control across every reachable
+step, including optional, repeated, conditional, consent, and attachment
+controls. Each row has one semantic fingerprint and exactly one disposition:
+`filled_exact_profile`, `filled_safe_derivation`, `filled_supported_draft`,
+`preserved_user_edit`, `missing_fact`, `live_consent`,
+`authentication_blocker`, `unobservable_commit`, `unsupported_control`, or
+`not_applicable`. The inventory count must equal committed plus typed
+exceptions, and known omissions must be zero. Reinventory after navigation,
+conditional reveal, resume parsing, validation, and rerender; an earlier
+inventory cannot prove a later form complete.
+
+Reconcile education and employment separately against all canonical eligible
+records. Education entries and position-level employment records must be
+accounted for in reverse chronological order. Multiple promotions at one
+employer remain separate positions. Preserve user-owned rows, use only the date
+precision actually stored, and ask when a form requires missing precision;
+never accept a default month or invent promotion, start, or end precision. A
+flattened employer summary or a “most recent roles” subset fails reconciliation.
+Keep only value-free counts and fingerprints in the checkpoint.
+
 ## Local field ownership
 
 Maintain a private local field ledger keyed by execution, run, inspection