trackly-cli 0.18.0 → 0.18.1

package/docs/solutions/integration-issues/access-review-proposal-receipt-validation.md

@@ -0,0 +1,151 @@
+---
+title: Bind access-review approval to validated proposal receipts
+date: 2026-09-05
+last_updated: 2026-09-05
+category: integration-issues
+module: Trackly Apply access-review facade
+problem_type: integration_issue
+component: mcp_facade
+symptoms:
+  - A compact backend proposal could be rejected because the client required display identity fields in both projections
+  - Active execution recovery could reject the backend's enabled metadata or expose access_review without its proposal
+  - An empty access-review proposal could pass the client response schema and reach approval handling
+  - Follow-up proposal caching and key-order-sensitive accessKnowledge comparisons could reject a valid continuation
+  - The deferment list reused the execution-wave cap instead of naming the backend's active-deferment limit
+root_cause: missing_validation
+resolution_type: code_fix
+severity: high
+related_components: [api_layer, contract_verifier, documentation]
+tags: [trackly-apply, access-review, proposal-receipt, zod, hosted-contract, fail-closed]
+---
+
+# Bind access-review approval to validated proposal receipts
+
+## Problem
+
+The CLI receives an immutable access-review proposal before it can advance an
+Apply execution. Approval must remain bound to that exact server receipt across
+the response validator, the local cache, the hosted contract verifier, and the
+agent-facing skill instructions.
+
+## Symptoms
+
+The deployed 3.8.x backend uses a compact local `proposedWave` array and keeps
+the rich approval receipt in `accessProposal.members`. The client previously
+required company, title, provider, and URL fields in both projections, so a real
+response failed before approval. The active endpoint also returns `enabled`,
+`active`, and `preserved`, while a pending access review is hydrated by the
+detail endpoint rather than inlined. The response schemas accepted an empty
+`proposedWave` or `accessProposal` without checking its counts. An access-review
+continuation normally requires a concrete member set, while the all-deferred
+case legitimately has no members and must be recognized by zero available
+candidates plus a positive deferred count. Exact recovery can also be blocked
+by a user deferment with zero members even when available candidates remain;
+that `recovery_blocked_by_user_deferment` rationale is a safe stop/clear path.
+Older 3.8.0 responses may omit the
+optional deferment mapping, so those receipts remain a safe stop/expiry state
+until a refreshed response supplies exact IDs. After an approval returned another
+`nextAction: access_review`, the new proposal was not cached, so the next exact
+approval was rejected locally. Matching nested `accessKnowledge` values by raw
+JSON text also made harmless object key order look like a changed receipt.
+Finally, the hosted verifier selected runtime class members before rejecting
+computed keys, allowing a computed member to shadow the reviewed method without
+being inspected.
+
+## Root cause
+
+The implementation treated each response branch independently. Schema presence
+checks did not encode nonempty review membership or compact-vs-rich projection
+parity, active recovery did not account for the endpoint's two-step shape, the
+approval cache handled only the first proposal, and identity comparison relied
+on serialization order. The verifier's member lookup likewise happened before
+its computed-key guard.
+
+## What Didn't Work
+
+A single proposal-response model could not safely cover start, per-execution
+reads, active recovery, and advance because those endpoints return different
+identity and metadata envelopes. Passing responses through raw exposed
+unmodelled fields, while forcing every active response through the access-review
+schema rejected ordinary and preserved-terminal recovery. Caching only the
+first proposal, clearing replay state on every refresh, and leaving proposal
+bindings unbounded broke either exact retry behavior or long-running process
+memory safety. Raw JSON serialization made receipt equality depend on object-key
+order. Reusing the execution-wave limit for deferment discovery happened to
+match the backend's current limit of 20, but concealed a separate contract that
+could drift independently.
+
+## Solution
+
+- Accept the deployed compact local projection and the optional complete future
+  display identity projection, while keeping the rich receipt's immutable
+  fields required and matching both projections by ordered job ID and
+  `accessKnowledge`.
+- Strictly validate start, advance, and active execution envelopes, preserve
+  `enabled`/`active`/`preserved`, and hydrate a pending access review from the
+  detail endpoint only when execution revision and `nextAction` still match.
+- Require a nonempty member set for normal access-review proposals, while
+  accepting the bounded all-deferred shape with zero available candidates and at
+  least one deferred candidate. Also accept an empty
+  `recovery_blocked_by_user_deferment` receipt when at least one candidate is
+  deferred. Validate optional deferment mappings when supplied; a legacy
+  response without mappings cannot authorize a clear action.
+- Validate progress candidate counts against the access proposal counts while
+  the response is still an `access_review`; after approval, the proposal is a
+  historical receipt and progress is allowed to reflect the newly created wave.
+- Canonicalize nested `accessKnowledge` objects by key before comparing the
+  simple and rich proposal representations.
+- Cache a newly returned access-review proposal after a successful approval so
+  the next continuation uses its current revision, ordered IDs, and hash. Bound
+  pending and replayable proposal bindings with oldest-entry eviction so an
+  abandoned execution cannot retain process memory indefinitely.
+- Reject all computed instance members before selecting the hosted runtime
+  method, with fixtures for computed methods and fields.
+- Keep the local and adapted Apply skills explicit about
+  `accessProposal.approvalHash`, and distinguish creation `jobId` values from
+  the discovered `defermentId` required to clear a deferment.
+- Validate deferment discovery against the backend's dedicated active-deferment
+  limit rather than coupling it to the numerically equal execution-wave limit.
+
+## Why This Works
+
+Each endpoint is parsed through its own strict envelope before its response is
+returned or cached. An access-review continuation must contain both the compact
+proposal and rich receipt, and the validator binds their ordered job IDs,
+contiguous member positions, frozen access knowledge, counts, and approval hash.
+Start and active recovery hydrate the detail endpoint only when execution ID,
+revision, and next action still match, preventing a stale detail response from
+authorizing work. Separate bounded pending and replay caches preserve exact
+same-key idempotency while rejecting a new key or evicting abandoned execution
+state. Canonical object comparison removes serialization-order dependence, and
+the separately named deferment limit prevents unrelated contract constants from
+being coupled accidentally.
+
+## Verification
+
+PR #135 merged as `e97309a07a8afdc6eb62b28f4313c538699c72e5`.
+Its CI passed 520 tests and the checked-in contract-fixture run passed 81 tests.
+
+Backend PR `#1769` merged as `254e1c6fc3f98e2f3aa8c6492702e9b9480ca22e`
+(head `4c4dab848b1068b1bd9290b14f8d278ec643aca6`) on 2026-09-05 14:00 PDT.
+Production `https://closeai.mba/api/first-test` reports `build_sha`
+`d5a9abf3e12fb384d50ec998d83a2370725ae3e7`, which contains that merge, and
+every hosted path the CLI locks is byte-identical between the two commits.
+Protected migration 507 completed on 2026-09-06 07:13 PDT
+(`providerDefermentsReady: true` on an idempotent rerun after the first request
+outlived the Cloudflare proxy timeout). The hosted contract fixture was
+recaptured from `254e1c6fc3`, and
+`TRACKLY_BACKEND_DIR=<clean checkout at 254e1c6fc3> npm run test:hosted-contract`
+passes with Apply 3.8.1 and the 21-tool public facade at 1.0.0.
+
+Still pending: npm publication of 0.18.1 through the merge of PR #136, and the
+backend rollout switch `TRACKLY_APPLY_ACCESS_KNOWLEDGE_ROLLOUT`, which is unset
+in production, so the live protocol still advertises the 3.7.x window; that
+activation is a backend rollout decision outside this repository.
+
+## Prevention
+
+When an access-review response shape changes, update the executed schema,
+response cache lifecycle, identity comparison, hosted verifier, both skill
+surfaces, and regression fixtures together. Treat server-provided proposal
+identity and hashes as the only approval authority.

package/docs/trackly-tools.md

@@ -115,10 +115,10 @@ API-key creation attempts.
 - **trackly_get_apply_execution_snapshot**: Fetch a compact bounded projection of current members, requested profile keys, mutability, allowed operations, milestones, lease timing, and the authoritative funnel.
 - **trackly_resume_parked_apply_member**: Resume one parked member only after explicit user instruction; a fresh non-mutating access probe remains required before form mutation.
 - **trackly_approve_apply_execution_resume**: Approve one exact resume identity for an execution's unchanged original snapshot while preserving immediate per-run local verification before upload.
-- **trackly_advance_apply_execution** — Transactionally select the next wave from the execution's original recent-first snapshot for the declared `browserSurface`. Returns the immutable `proposedWave` with each member's frozen order, job ID, company, title, provider, requisition URL, and value-free `accessKnowledge` receipt. Same-key retries return identical identity, order, and rationale. Optional hash-bound `accessReviewApproval` probes exact deferred job IDs after personal deferments are cleared.
+- **trackly_advance_apply_execution** — Transactionally select the next wave from the execution's original recent-first snapshot for the declared `browserSurface`. Returns a compact immutable `proposedWave` with each member's job ID and value-free `accessKnowledge`, plus the rich `accessProposal` receipt with member order, rationale, and approval hash. Same-key retries return identical identity, order, and rationale. Optional hash-bound `accessReviewApproval` probes exact proposed job IDs after personal deferments are cleared.
 - **trackly_list_apply_access_deferments** — List the current user's persistent job/company/provider access deferments. Returns only scope identities; never provider names, URLs, or raw text.
-- **trackly_defer_apply_access** — Persist an explicit user deferment for one Trackly `jobId` at `job`, `company`, or `provider` scope. The server derives company, provider, tenant, origin, and route; provider scope applies across companies, recovery, and replay.
-- **trackly_clear_apply_access_deferment** — Clear one deferment listed or created in the current MCP session. Exact same-session replay is idempotent, including for provider-wide user policy; after restart, refresh the active list instead of replaying an undiscovered cleared ID.
+- **trackly_defer_apply_access** — Persist an explicit user deferment for one Trackly `jobId` at `job`, `company`, or `provider` scope. The server derives company, provider, tenant, origin, and route; provider scope applies across companies until cleared; never submit a provider name, URL, or raw text.
+- **trackly_clear_apply_access_deferment** — Clear one deferment listed or created in the current MCP session. Exact same-session replay is idempotent; after restart, refresh the active list instead of replaying an undiscovered cleared ID.
 - **trackly_record_apply_execution_dispositions** — Record typed, value-free live-probe classifications for the current wave. Every item requires `jobId`, one allowed `classification`, `source: 'live_probe'`, and the exact `batchId`, `memberId`, `runId`, `expectedMemberVersion`, `expectedInspectionEpoch`, and `browserSurface`; cache/static scheduling records are server-owned and cannot be submitted through MCP.
 - **trackly_stop_apply_execution** — Stop an execution with optimistic revision and idempotency guards.
 - **trackly_create_apply_batch** — Freeze an exact recent-first set of approved jobs with an idempotency key.
@@ -149,10 +149,10 @@ API-key creation attempts.
 Apply contract v3 intentionally gives this verifier different local and hosted schemas: local MCP receives the full proof needed to inspect the private file, while hosted MCP accepts only run and confirmation identifiers and returns the manual/local-agent requirement. Local paths are never sent remotely. Resume fingerprints are sent only to authenticated Trackly resume approval and truth-certification endpoints, never observations or employer forms. Version 3.1 also records universal value-free evidence for critical-contact integrity and the manual-submit boundary. Version 3.2 authorizes the exact stored HTTPS origin for jobs Trackly ingested from employer careers sources, without granting redirect, iframe, or hostname-suffix privileges. Version 3.3.1 adds active-batch recovery, epoch-bound observations/outcomes, and truth certification for forms with no resume control. Version 3.4 adds server-owned accessible executions above immutable child batches, typed access dispositions, and an authoritative target-completion funnel.
 
 Version 3.8.1 adds access-aware scheduling receipts, `nextAction: access_review`,
-hash-bound deferred-probe approval, and job/company/provider deferment tools.
-Provider scope is derived from a stable job anchor and applies across companies,
-approval, recovery, and replay. Historical OPEN never authorizes form filling;
-every selected job still requires a fresh non-mutating live probe.
+hash-bound probe approval, and job/company/provider deferment tools. Provider scope
+applies across companies until explicitly cleared. Historical OPEN never
+authorizes form filling; every selected job still requires a fresh non-mutating
+live probe.
 
 Version 3.7 adds public exact-member recovery and scoped review-handoff claims,
 plus local tab-finalizer and resume-upload proof validators. Recovery candidates

package/mcp/apply-tools.js

@@ -35,6 +35,7 @@ const APPLY_ACCESS_FRESHNESS_STATES = APPLY_CONTRACT.constants.applyAccessFreshn
 const APPLY_SCHEDULING_EFFECTS = APPLY_CONTRACT.constants.applySchedulingEffects;
 const APPLY_ACCESS_DEFERMENT_SCOPES = APPLY_CONTRACT.constants.applyAccessDefermentScopes;
 const APPLY_ACCESS_MATCHED_SCOPES = APPLY_CONTRACT.constants.applyAccessMatchedScopes;
+const APPLY_ACCESS_DEFERMENT_MAX_ACTIVE = 20;
 const APPLY_BATCH_MAX_MEMBERS = 100;
 const APPLY_BATCH_MAX_CHECKPOINTS_PER_REQUEST = 20;
 const APPLY_BATCH_MAX_ACTIONS_PER_CHECKPOINT = 25;
@@ -177,30 +178,64 @@ const accessKnowledgeSchema = z.object({
   evaluatedAt: z.string().datetime(),
   freshLiveProbeRequired: z.literal(true),
 }).strict();
+const OPTIONAL_WAVE_DISPLAY_FIELDS = [
+  'jobTitle', 'companyName', 'provider', 'requisitionUrl',
+];
+function validateOptionalWaveDisplay(member, context) {
+  const present = OPTIONAL_WAVE_DISPLAY_FIELDS.filter((field) => member[field] !== undefined);
+  if (present.length > 0 && present.length < OPTIONAL_WAVE_DISPLAY_FIELDS.length) {
+    context.addIssue({
+      code: z.ZodIssueCode.custom,
+      path: [present[0]],
+      message: 'wave member display identity fields must be complete when projected',
+    });
+  }
+}
 const proposedWaveMemberSchema = z.object({
   jobId: z.number().int().min(1),
-  memberPosition: z.number().int().min(0),
+  // The local CLI projection is intentionally compact: the deployed backend
+  // returns only the stable job identity and scheduling receipt here. Rich
+  // approval metadata lives in accessProposal.members. The optional identity
+  // fields keep the client forward-compatible with the coordinated full
+  // identity projection without trusting them over the rich receipt.
+  // Protocol 3.8.0 compact receipts omit memberPosition. When a coordinated
+  // backend projects it, validate and compare it independently of display
+  // identity fields; never reject the deployed compact shape for its absence.
+  memberPosition: z.number().int().min(0).optional(),
   jobTitle: z.string().min(1).refine((value) => Array.from(value).length <= 300, {
     message: 'jobTitle must contain at most 300 Unicode code points',
-  }),
+  }).optional(),
   companyName: z.string().min(1).refine((value) => Array.from(value).length <= 300, {
     message: 'companyName must contain at most 300 Unicode code points',
-  }),
-  provider: z.string().regex(SAFE_OBSERVATION_CODE),
+  }).optional(),
+  provider: z.string().regex(SAFE_OBSERVATION_CODE).optional(),
   requisitionUrl: z.string().url().max(2048).refine((value) => value.startsWith('https://'), {
     message: 'requisitionUrl must use HTTPS',
-  }),
+  }).optional(),
   accessKnowledge: accessKnowledgeSchema,
-}).strict();
+}).strict().superRefine(validateOptionalWaveDisplay);
 const blockedJobDefermentSchema = z.object({
   jobId: z.number().int().min(1),
   defermentId: z.number().int().min(1),
   scope: z.enum(APPLY_ACCESS_DEFERMENT_SCOPES),
 }).strict();
-const richProposedWaveMemberSchema = proposedWaveMemberSchema.extend({
+const richProposedWaveMemberSchema = z.object({
+  jobId: z.number().int().min(1),
+  memberPosition: z.number().int().min(0),
+  jobTitle: z.string().min(1).refine((value) => Array.from(value).length <= 300, {
+    message: 'jobTitle must contain at most 300 Unicode code points',
+  }).optional(),
+  companyName: z.string().min(1).refine((value) => Array.from(value).length <= 300, {
+    message: 'companyName must contain at most 300 Unicode code points',
+  }).optional(),
+  provider: z.string().regex(SAFE_OBSERVATION_CODE).optional(),
+  requisitionUrl: z.string().url().max(2048).refine((value) => value.startsWith('https://'), {
+    message: 'requisitionUrl must use HTTPS',
+  }).optional(),
+  accessKnowledge: accessKnowledgeSchema,
   rationaleCode: z.string().regex(SAFE_OBSERVATION_CODE),
   receiptHash: z.string().regex(/^[a-f0-9]{64}$/),
-}).strict();
+}).strict().superRefine(validateOptionalWaveDisplay);
 const accessProposalSchema = z.object({
   proposalId: z.number().int().min(1),
   approvalHash: z.string().regex(/^[a-f0-9]{64}$/),
@@ -218,6 +253,30 @@ const accessProposalSchema = z.object({
     .optional(),
   members: z.array(richProposedWaveMemberSchema).max(APPLY_EXECUTION_MAX_TARGET),
 }).strict().superRefine((proposal, context) => {
+  const allDeferred = proposal.rationaleCode === 'all_candidates_user_deferred';
+  const recoveryBlocked = proposal.rationaleCode === 'recovery_blocked_by_user_deferment';
+  if (proposal.members.length === 0
+    && ((!allDeferred && !recoveryBlocked)
+      || (allDeferred
+        && (proposal.availableCandidateCount !== 0 || proposal.deferredCandidateCount < 1))
+      || (recoveryBlocked && proposal.deferredCandidateCount < 1))) {
+    context.addIssue({
+      code: z.ZodIssueCode.custom,
+      path: ['members'],
+      message: 'empty accessProposal members require no available candidates and at least one deferred candidate',
+    });
+  }
+  if (proposal.members.length > 0 && (allDeferred || recoveryBlocked)) {
+    context.addIssue({
+      code: z.ZodIssueCode.custom,
+      path: ['members'],
+      message: 'terminal deferment rationales require an empty accessProposal members array',
+    });
+  }
+  // The initial 3.8.0 backend response omitted this optional mapping. When
+  // it is present, the mapping is validated and cached so the agent can offer
+  // an exact clear action; when it is absent, the proposal remains a safe
+  // stop/expiry state until a refreshed backend receipt supplies IDs.
   if (new Set(proposal.members.map(({ jobId }) => jobId)).size !== proposal.members.length) {
     context.addIssue({
       code: z.ZodIssueCode.custom,
@@ -278,6 +337,20 @@ const compatibleExecutionProgressSchema = executionProgressSchema.extend({
     submitted: z.number().int().min(0),
   }).strict().optional(),
 }).strict();
+function canonicalizeAccessKnowledge(value) {
+  if (Array.isArray(value)) return value.map(canonicalizeAccessKnowledge);
+  if (value && typeof value === 'object') {
+    return Object.fromEntries(Object.keys(value).sort().map((key) => [
+      key,
+      canonicalizeAccessKnowledge(value[key]),
+    ]));
+  }
+  return value;
+}
+function accessKnowledgeEqual(left, right) {
+  return JSON.stringify(canonicalizeAccessKnowledge(left))
+    === JSON.stringify(canonicalizeAccessKnowledge(right));
+}
 function validateMatchingProposal(response, context) {
   const simpleIds = response.proposedWave.map(({ jobId }) => jobId);
   const richIds = response.accessProposal.members.map(({ jobId }) => jobId);
@@ -299,12 +372,12 @@ function validateMatchingProposal(response, context) {
   if (response.proposedWave.some((member, index) => {
     const rich = response.accessProposal.members[index];
     return !rich
-      || member.memberPosition !== rich.memberPosition
-      || member.jobTitle !== rich.jobTitle
-      || member.companyName !== rich.companyName
-      || member.provider !== rich.provider
-      || member.requisitionUrl !== rich.requisitionUrl
-      || JSON.stringify(member.accessKnowledge) !== JSON.stringify(rich.accessKnowledge)
+      || (member.memberPosition !== undefined && member.memberPosition !== rich.memberPosition)
+      || (member.jobTitle !== undefined && member.jobTitle !== rich.jobTitle)
+      || (member.companyName !== undefined && member.companyName !== rich.companyName)
+      || (member.provider !== undefined && member.provider !== rich.provider)
+      || (member.requisitionUrl !== undefined && member.requisitionUrl !== rich.requisitionUrl)
+      || !accessKnowledgeEqual(member.accessKnowledge, rich.accessKnowledge)
       || rich.rationaleCode !== rich.accessKnowledge.rationaleCode;
   })) {
     context.addIssue({
@@ -313,6 +386,26 @@ function validateMatchingProposal(response, context) {
       message: 'accessProposal must bind the exact displayed frozen identities and access knowledge',
     });
   }
+  if (response.progress?.nextAction === 'access_review'
+    && response.progress.availableCandidateCount !== undefined
+    && response.progress.availableCandidateCount
+      !== response.accessProposal.availableCandidateCount) {
+    context.addIssue({
+      code: z.ZodIssueCode.custom,
+      path: ['progress', 'availableCandidateCount'],
+      message: 'progress availableCandidateCount must match accessProposal',
+    });
+  }
+  if (response.progress?.nextAction === 'access_review'
+    && response.progress.deferredCandidateCount !== undefined
+    && response.progress.deferredCandidateCount
+      !== response.accessProposal.deferredCandidateCount) {
+    context.addIssue({
+      code: z.ZodIssueCode.custom,
+      path: ['progress', 'deferredCandidateCount'],
+      message: 'progress deferredCandidateCount must match accessProposal',
+    });
+  }
 }
 const proposedWaveResponseSchema = z.object({
   success: z.literal(true),
@@ -355,16 +448,58 @@ const getExecutionAccessReviewResponseSchema = z.object({
   accessProposal: accessProposalSchema,
 }).strict().superRefine(validateMatchingProposal);
 const activeExecutionAccessReviewResponseSchema = getExecutionAccessReviewResponseSchema.innerType().extend({
+  enabled: z.boolean().optional(),
   active: z.boolean().optional(),
   preserved: z.boolean().optional(),
-}).strict().superRefine(validateMatchingProposal);
+}).strict().superRefine(validateMatchingProposal).superRefine(rejectInactiveExecution);
 const startExecutionAccessReviewResponseSchema = z.object({
   success: z.literal(true),
+  replay: z.boolean().optional(),
   execution: applyExecutionSchema,
+  candidateCount: z.number().int().min(0).optional(),
   progress: executionProgressSchema,
   proposedWave: z.array(proposedWaveMemberSchema).max(APPLY_EXECUTION_MAX_TARGET),
   accessProposal: accessProposalSchema,
 }).strict().superRefine(validateMatchingProposal);
+const startExecutionOrdinaryResponseSchema = z.object({
+  success: z.literal(true),
+  replay: z.boolean().optional(),
+  execution: applyExecutionSchema,
+  candidateCount: z.number().int().min(0).optional(),
+  progress: compatibleExecutionProgressSchema,
+}).strict();
+const startExecutionResponseSchema = z.union([
+  startExecutionAccessReviewResponseSchema,
+  startExecutionOrdinaryResponseSchema,
+]);
+function rejectAccessReviewWithoutProposal(response, context) {
+  if (response.progress.nextAction === 'access_review'
+    && (response.proposedWave === undefined || response.accessProposal === undefined)) {
+    context.addIssue({
+      code: z.ZodIssueCode.custom,
+      path: ['progress', 'nextAction'],
+      message: 'access_review responses must include proposedWave and accessProposal',
+    });
+  }
+}
+function rejectInactiveExecution(response, context) {
+  // A preserved terminal execution is intentionally returned with
+  // `active: false` for read-only reconciliation. Only reject the
+  // contradictory combination where that same response still asks the
+  // caller to perform more work. Preserved terminals are valid only with
+  // nextAction `none`.
+  if (
+    response.active === false
+    && response.execution !== undefined
+    && response.progress?.nextAction !== 'none'
+  ) {
+    context.addIssue({
+      code: z.ZodIssueCode.custom,
+      path: ['active'],
+      message: 'active=false terminal responses must use nextAction none',
+    });
+  }
+}
 const advanceExecutionResponseSchema = z.object({
   success: z.literal(true),
   executionId: z.number().int().min(1),
@@ -373,12 +508,34 @@ const advanceExecutionResponseSchema = z.object({
   revision: z.number().int().min(1),
   progress: compatibleExecutionProgressSchema,
   replay: z.boolean().optional(),
-}).strict();
-const getExecutionResponseSchema = z.object({
+}).strict().superRefine(rejectAccessReviewWithoutProposal);
+const getExecutionResponseObjectSchema = z.object({
   success: z.literal(true),
   execution: applyExecutionSchema,
   progress: compatibleExecutionProgressSchema,
 }).strict();
+const getExecutionResponseSchema = getExecutionResponseObjectSchema.superRefine(rejectAccessReviewWithoutProposal);
+const activeExecutionOrdinaryResponseSchema = getExecutionResponseObjectSchema.extend({
+  enabled: z.boolean().optional(),
+  active: z.boolean().optional(),
+  preserved: z.boolean().optional(),
+}).strict().superRefine(rejectAccessReviewWithoutProposal).superRefine(rejectInactiveExecution);
+const activeExecutionInactiveResponseSchema = z.object({
+  success: z.literal(true),
+  enabled: z.boolean().optional(),
+  active: z.literal(false),
+  preserved: z.boolean().optional(),
+}).strict().superRefine(rejectInactiveExecution);
+const activeExecutionEnvelopeSchema = getExecutionResponseObjectSchema.extend({
+  enabled: z.boolean().optional(),
+  active: z.boolean().optional(),
+  preserved: z.boolean().optional(),
+}).strict().superRefine(rejectInactiveExecution);
+const activeExecutionResponseSchema = z.union([
+  activeExecutionInactiveResponseSchema,
+  activeExecutionOrdinaryResponseSchema,
+  activeExecutionAccessReviewResponseSchema,
+]);
 const accessDefermentSchema = z.object({
   id: z.number().int().min(1),
   jobId: z.number().int().min(1),
@@ -392,7 +549,7 @@ const clearedAccessDefermentSchema = accessDefermentSchema.extend({
 }).strict();
 const accessDefermentListResponseSchema = z.object({
   success: z.literal(true),
-  deferments: z.array(accessDefermentSchema).max(APPLY_EXECUTION_MAX_TARGET),
+  deferments: z.array(accessDefermentSchema).max(APPLY_ACCESS_DEFERMENT_MAX_ACTIVE),
 }).strict().refine(({ deferments }) => (
   new Set(deferments.map(({ id }) => id)).size === deferments.length
 ), { message: 'deferment IDs must be unique' });
@@ -634,7 +791,7 @@ const startApplyRunSchema = z.object({
   }
 });
 
-const APPLY_RELIABILITY_PROMPT = 'Protocol 3.7 / skill 4.8.0 reliability gate: recover active work first. Consume the exact proposedWave and frozen accessKnowledge receipts before opening any browser. Rank OPEN ahead of neutral VARIES/UNKNOWN, then fresh ACCOUNT WALL; never auto-select an active user deferment. Historical OPEN never authorizes fill_form; freshLiveProbeRequired remains true. When nextAction is access_review, display the exact accessProposal and approvalHash, then obtain explicit approval for those exact jobIds and call the hash-bound approval continuation; if access is deferred, wait for probe, clear-deferment, stop, or expiry. Do not open a browser or report the queue exhausted. Retain the latest explicit target as hard, prove genuine applicant fields before counting access, obtain approval for the exact accessible jobs before form mutation, fill all deterministic fields before one true-gap question packet, and validate each value-free phase checkpoint. Every checkpoint action must use its canonical continuationAllowed value; review/manual_submit, captcha/at_submit, trust/origin_mismatch, and observability/unverifiable_state require false. Fail closed on a rejected checkpoint. After full local context loss, list recoverable executions, show only stable job identity, obtain explicit confirmation of the exact candidate set, and call exact-member recovery without substitutions. An active personal deferment blocks exact recovery until cleared. Treat recovered tab presence, form state, and mutation authority as three separate facts; reacquire a fresh browser binding and inspection epoch before mutation. Before resolving broad submission statements, list active review handoffs for the execution; use only an explicit receipt or the sole returned active receipt, classify every member as detected, user_confirmed, unresolved, or contradictory, and claim that exact handoff before writing outcomes. Use provider-specific positive success evidence; an unchanged URL or title is never negative evidence. Validate an exact expected browser keep set locally before finalization. For resume uploads, negotiate the browser surface capabilities, identify the semantic control, arm the chooser before clicking, attach the immediately verified file, prove the user-facing filename committed, and recheck parser-modified fields. Use compact snapshots and server-provided mutability. Preserve user-edited and unknown non-empty fields. Never reopen parked work without explicit user resumption. Never click Submit.';
+const APPLY_RELIABILITY_PROMPT = 'Protocol 3.7 / skill 4.8.0 reliability gate: recover active work first. Consume the exact proposedWave and frozen accessKnowledge receipts before opening any browser. Rank OPEN ahead of neutral VARIES/UNKNOWN, then fresh ACCOUNT WALL; never auto-select an active user deferment. Historical OPEN never authorizes fill_form; freshLiveProbeRequired remains true. When nextAction is access_review, including ordinary OPEN or neutral proposals, display the exact accessProposal and accessProposal.approvalHash. If the proposal has nonempty members, obtain explicit approval for those exact ordered jobIds and call the hash-bound approval continuation. If the proposal has zero members because all remaining candidates are deferred or exact recovery is blocked by a user deferment, surface the deferred count and stable deferment IDs, offer clear-deferment only for explicitly returned IDs, stop, or expiry, and never send an empty approval. List or create deferments only at job, company, or provider scope through the jobId-bound tools; provider scope applies across companies until explicitly cleared. Do not open a browser or report the queue exhausted. Retain the latest explicit target as hard, prove genuine applicant fields before counting access, obtain approval for the exact accessible jobs before form mutation, fill all deterministic fields before one true-gap question packet, and validate each value-free phase checkpoint. Every checkpoint action must use its canonical continuationAllowed value; review/manual_submit, captcha/at_submit, trust/origin_mismatch, and observability/unverifiable_state require false. Fail closed on a rejected checkpoint. After full local context loss, list recoverable executions, show only stable job identity, obtain explicit confirmation of the exact candidate set, and call exact-member recovery without substitutions. An active personal deferment blocks exact recovery until cleared. Treat recovered tab presence, form state, and mutation authority as three separate facts; reacquire a fresh browser binding and inspection epoch before mutation. Before resolving broad submission statements, list active review handoffs for the execution; use only an explicit receipt or the sole returned active receipt, classify every member as detected, user_confirmed, unresolved, or contradictory, and claim that exact handoff before writing outcomes. Use provider-specific positive success evidence; an unchanged URL or title is never negative evidence. Validate an exact expected browser keep set locally before finalization. For resume uploads, negotiate the browser surface capabilities, identify the semantic control, arm the chooser before clicking, attach the immediately verified file, prove the user-facing filename committed, and recheck parser-modified fields. Use compact snapshots and server-provided mutability. Preserve user-edited and unknown non-empty fields. Never reopen parked work without explicit user resumption. Never click Submit.';
 
 function registerApplyTools(
   server,
@@ -679,17 +836,28 @@ function registerApplyTools(
   }
   const pendingAccessProposalByExecution = new Map();
   const replayableAccessApprovalByExecution = new Map();
+  const MAX_ACCESS_PROPOSAL_BINDINGS = 64;
+  function setBoundedAccessProposalBinding(bindings, executionId, value) {
+    bindings.delete(executionId);
+    bindings.set(executionId, value);
+    while (bindings.size > MAX_ACCESS_PROPOSAL_BINDINGS) {
+      bindings.delete(bindings.keys().next().value);
+    }
+  }
   function rememberAccessProposal(executionId, revision, browserSurface, response) {
     if (response.progress?.nextAction !== 'access_review') {
       pendingAccessProposalByExecution.delete(executionId);
       return response;
     }
-    pendingAccessProposalByExecution.set(executionId, {
+    setBoundedAccessProposalBinding(pendingAccessProposalByExecution, executionId, {
       revision,
       browserSurface,
       approvalHash: response.accessProposal.approvalHash,
       jobIds: response.accessProposal.members.map(({ jobId }) => jobId),
     });
+    for (const deferment of response.accessProposal.blockedJobDeferments ?? []) {
+      discoveredDefermentIds.add(deferment.defermentId);
+    }
     return response;
   }
   server.tool(
@@ -812,11 +980,38 @@ function registerApplyTools(
       const rawResponse = await applyControlRequest(
         'POST', '/api/jobscout/apply/executions', body, idempotencyKey,
       );
-      const response = rawResponse?.proposedWave !== undefined || rawResponse?.accessProposal !== undefined
-        ? startExecutionAccessReviewResponseSchema.parse(rawResponse)
-        : rawResponse;
+      let response = startExecutionResponseSchema.parse(rawResponse);
+      // An idempotent start replay may return the existing pending execution
+      // and its access_review progress without inlining the proposal. Hydrate
+      // the same strict detail response used by active recovery before the
+      // start result is exposed or cached.
+      if (response.progress.nextAction === 'access_review'
+        && response.proposedWave === undefined) {
+        const hydrated = validateGetExecutionResponse(await applyControlRequest(
+          'GET', `/api/jobscout/apply/executions/${response.execution.id}`,
+        ));
+        if (hydrated.execution?.id !== response.execution.id
+          || hydrated.execution.revision !== response.execution.revision
+          || hydrated.progress.nextAction !== 'access_review'
+          || hydrated.proposedWave === undefined) {
+          throw new Error('Trackly start access review did not include its proposal.');
+        }
+        response = startExecutionAccessReviewResponseSchema.parse({
+          ...response,
+          execution: hydrated.execution,
+          progress: hydrated.progress,
+          proposedWave: hydrated.proposedWave,
+          accessProposal: hydrated.accessProposal,
+        });
+      }
       if (response?.proposedWave !== undefined && response?.execution?.id !== undefined) {
         rememberAccessProposal(response.execution.id, response.execution.revision, null, response);
+      } else if (response?.execution?.id !== undefined) {
+        // A replay may legitimately return ordinary progress after the
+        // access-review wave was consumed. Do not retain a prior approval
+        // receipt that could authorize a later request for the same execution.
+        pendingAccessProposalByExecution.delete(response.execution.id);
+        replayableAccessApprovalByExecution.delete(response.execution.id);
       }
       return response;
     }, 'Failed to start apply execution')
@@ -828,13 +1023,44 @@ function registerApplyTools(
     {},
     wrapTool(async () => {
       const rawResponse = await applyControlRequest('GET', '/api/jobscout/apply/executions/active');
-      const response = rawResponse?.execution !== undefined || rawResponse?.progress !== undefined
-        ? (rawResponse?.active !== undefined || rawResponse?.preserved !== undefined
-          ? activeExecutionAccessReviewResponseSchema.parse(rawResponse)
-          : validateGetExecutionResponse(rawResponse))
-        : rawResponse;
+      const pendingProposal = rawResponse?.execution !== undefined
+        && rawResponse?.progress?.nextAction === 'access_review'
+        && rawResponse?.proposedWave === undefined;
+      let response = pendingProposal
+        ? activeExecutionEnvelopeSchema.parse(rawResponse)
+        : activeExecutionResponseSchema.parse(rawResponse);
+      // The deployed active endpoint reports the authoritative execution and
+      // progress but does not inline a pending access proposal. Hydrate that
+      // proposal from the strict execution endpoint before exposing an
+      // access_review response, otherwise restart/recovery would stall on a
+      // false missing-proposal error.
+      if (
+        response.progress?.nextAction === 'access_review'
+        && response.execution?.id !== undefined
+        && response.proposedWave === undefined
+      ) {
+        const hydrated = validateGetExecutionResponse(await applyControlRequest(
+          'GET', `/api/jobscout/apply/executions/${response.execution.id}`,
+        ));
+        if (hydrated.execution?.id !== response.execution.id
+          || hydrated.execution.revision !== response.execution.revision
+          || hydrated.progress.nextAction !== 'access_review'
+          || hydrated.proposedWave === undefined) {
+          throw new Error('Trackly active execution access review did not include its proposal.');
+        }
+        response = activeExecutionResponseSchema.parse({
+          ...response,
+          ...hydrated,
+          enabled: response.enabled,
+          active: response.active,
+          preserved: response.preserved,
+        });
+      }
       if (response?.execution?.id && response.proposedWave !== undefined) {
         rememberAccessProposal(response.execution.id, response.execution.revision, null, response);
+      } else if (response?.execution?.id) {
+        pendingAccessProposalByExecution.delete(response.execution.id);
+        replayableAccessApprovalByExecution.delete(response.execution.id);
       }
       return response;
     }, 'Failed to recover active apply execution')
@@ -853,6 +1079,7 @@ function registerApplyTools(
       }
       if (response.proposedWave === undefined) {
         pendingAccessProposalByExecution.delete(executionId);
+        replayableAccessApprovalByExecution.delete(executionId);
         return response;
       }
       return rememberAccessProposal(executionId, response.execution.revision, null, response);
@@ -1049,7 +1276,7 @@ function registerApplyTools(
 
   server.tool(
     'trackly_advance_apply_execution',
-    'Advance an execution transactionally for the current browser surface. Returns the immutable proposedWave with frozen accessKnowledge receipts and never opens a browser. Same-key replay returns the same members, order, and rationale. Optional hash-bound accessReviewApproval probes exact deferred job IDs only after personal deferments are cleared.',
+    'Advance an execution transactionally for the current browser surface. Returns the immutable proposedWave with frozen accessKnowledge receipts and never opens a browser. Same-key replay returns the same members, order, and rationale. Optional hash-bound accessReviewApproval probes the exact proposed job IDs only after personal deferments are cleared.',
     {
       executionId: z.number().int().min(1),
       expectedRevision: z.number().int().min(1),
@@ -1090,13 +1317,16 @@ function registerApplyTools(
       }
       if (body.accessReviewApproval) {
         pendingAccessProposalByExecution.delete(executionId);
-        replayableAccessApprovalByExecution.set(executionId, {
+        setBoundedAccessProposalBinding(replayableAccessApprovalByExecution, executionId, {
           revision: body.expectedRevision,
           browserSurface: body.browserSurface,
           approvalHash: body.accessReviewApproval.approvalHash,
           jobIds: [...body.accessReviewApproval.jobIds],
           idempotencyKey,
         });
+        if (response.proposedWave !== undefined && response.progress?.nextAction === 'access_review') {
+          rememberAccessProposal(executionId, response.revision, body.browserSurface, response);
+        }
       } else if (response.proposedWave !== undefined) {
         rememberAccessProposal(executionId, response.revision, body.browserSurface, response);
       } else {
@@ -1158,7 +1388,7 @@ function registerApplyTools(
 
   server.tool(
     'trackly_defer_apply_access',
-    'Persist an explicit user deferment for one Trackly job or its derived company or provider scope. Provider scope blocks that provider across companies, proposal approval, recovery, and replay until cleared. The server derives company, provider, tenant, origin, and route from jobId; never submit a provider name, URL, or free text.',
+    'Persist an explicit user deferment for one Trackly job or its derived company or provider scope. Provider scope applies across companies until explicitly cleared. The server derives company, provider, tenant, origin, and route from jobId; never submit a provider name, URL, or free text.',
     {
       jobId: z.number().int().min(1),
       scope: z.enum(APPLY_ACCESS_DEFERMENT_SCOPES),
@@ -1181,7 +1411,7 @@ function registerApplyTools(
 
   server.tool(
     'trackly_clear_apply_access_deferment',
-    'Clear one explicit user deferment previously listed or created in this session. An exact same-session retry remains idempotent, including for provider-wide user policy.',
+    'Clear one explicit user deferment previously listed or created in this session. An exact same-session retry remains idempotent.',
     {
       defermentId: z.number().int().min(1),
       idempotencyKey: z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY),
@@ -1206,6 +1436,7 @@ function registerApplyTools(
         throw new Error('Access deferment response does not match the requested deferment id.');
       }
       rememberClearedDefermentReplay(defermentId, idempotencyKey);
+      discoveredDefermentIds.delete(defermentId);
       return response;
     }, 'Failed to clear apply access deferment')
   );
@@ -1745,7 +1976,7 @@ function registerApplyTools(
       role: 'user',
       content: {
         type: 'text',
-        text: 'Protocol 3.7.0 reliability gate for new work: require MCP contract 3.8.1 and skill 4.8.0. Consume the exact proposedWave with frozen accessKnowledge before opening any browser; same-key advance replay returns identical member IDs, order, and rationale. When nextAction is access_review, display the deferred proposal and do not report exhaustion. Defer or clear only through jobId-scoped tools; provider scope persists server-derived provider exclusions across companies, approval, recovery, and replay. Never submit provider names, URLs, or raw chat. After complete local context loss, list bounded recovery candidates, obtain explicit confirmation of the exact set, and recover only that set. An active personal deferment blocks exact recovery until cleared. Treat tab recovery, form-state recovery, and mutation authority as independent. List active handoff receipts for the execution before resolving grouped submission statements; use the named receipt or the sole returned active receipt, classify every member, and claim that receipt before recording outcomes. Validate tab keep sets and resume upload stages locally. Never send raw browser values or click Submit.',
+        text: 'Protocol 3.7.0 reliability gate for new work: require MCP contract 3.8.1 and skill 4.8.0. Consume the exact proposedWave with frozen accessKnowledge before opening any browser; same-key advance replay returns identical member IDs, order, and rationale. When nextAction is access_review, including ordinary OPEN or neutral proposals, display the exact access-review receipt and do not report exhaustion. For a nonempty proposal, obtain explicit approval for the unchanged ordered job IDs and server approval hash before probing. For an all-deferred or recovery-blocked proposal with zero members, show the deferred count and stable job/company/provider deferment IDs, offer clear-deferment only for explicitly returned IDs, stop, or expiry, and never send an empty approval. Defer or clear only through jobId-scoped job, company, or provider tools; provider scope applies across companies until explicitly cleared. Never submit provider names, URLs, or raw chat. After complete local context loss, list bounded recovery candidates, obtain explicit confirmation of the exact set, and recover only that set. An active personal deferment blocks exact recovery until cleared. Treat tab recovery, form-state recovery, and mutation authority as independent. List active handoff receipts for the execution before resolving grouped submission statements; use the named receipt or the sole returned active receipt, classify every member, and claim that receipt before recording outcomes. Validate tab keep sets and resume upload stages locally. Never send raw browser values or click Submit.',
       },
     }, {
       role: 'user',

package/npm-shrinkwrap.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "trackly-cli",
-  "version": "0.18.0",
+  "version": "0.18.1",
   "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": {

package/server.json

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

package/skills/trackly-apply/SKILL.md

@@ -59,8 +59,8 @@ Read [references/legal-clarifications.md](references/legal-clarifications.md) wh
    - 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. 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.
+   - 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. The local response uses a compact `proposedWave` projection with each member's `jobId` and `accessKnowledge`, alongside the rich `accessProposal` receipt with contiguous `memberPosition`, rationale, and approval hash. Before asking for approval, show each rich server-frozen member in exact `memberPosition` order with its job ID and value-free scheduling reason; require the compact projection's ordered job IDs and access knowledge to match `accessProposal.members[]` 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. If the proposal has no members because all remaining candidates are deferred or exact recovery is blocked by a user deferment, do not submit an empty approval: show the returned deferred count and stable job/scope/deferment IDs, then either clear only deferment IDs the user explicitly selects and request a fresh proposal, or offer stop/expiry. If a legacy receipt omits the mapping, stop or wait for expiry and request a fresh proposal rather than guessing an ID. Otherwise 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 access-review proposal, including ordinary OPEN or neutral members, do not open a browser, and do not report the queue as exhausted. For a zero-member proposal declared `all_candidates_user_deferred` or `recovery_blocked_by_user_deferment`, offer clear-deferment only for explicitly returned deferment IDs; the recovery-blocked case may still report available candidates, so do not call it queue exhaustion. If a legacy receipt omits the mapping, stop or wait for expiry and request a fresh proposal rather than guessing an ID. Never send an empty approval. For a nonempty proposal, probe exact proposed 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 applies it across companies until explicitly cleared. 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.

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

@@ -83,30 +83,40 @@ 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.
+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.
+`nextAction`. When `nextAction` is `access_review`, return the bounded
+access-review proposal, including ordinary OPEN or neutral members, open
+nothing, and do not report the queue as exhausted. If the proposal has no
+members because all remaining candidates are deferred, or because exact
+recovery is blocked by a user deferment
+(`recovery_blocked_by_user_deferment`), show its deferred count and matching
+stable job/scope/deferment IDs, then offer clear-deferment only for IDs the user
+explicitly selects and the server returns. Recovery-blocked proposals may
+still report available candidates; they are not queue exhaustion. If a legacy
+receipt omits that mapping, stop or expiry rather than guessing an ID. Never
+send an empty approval.
+Clear any active personal deferment before probing. For a nonempty proposal,
+probe those exact job IDs only with hash-bound `accessReviewApproval` after
+clearing that deferment. List or create deferments only through
+`trackly_list_apply_access_deferments` and `trackly_defer_apply_access` using a
+Trackly `jobId` and scope `job`, `company`, or `provider`. Provider scope is a
+global policy boundary derived from that stable job anchor and applies across
+companies until explicitly cleared. Clear only through
+`trackly_clear_apply_access_deferment` using the exact user-selected
+`defermentId` returned by deferment discovery or creation. Never submit a URL,
+provider name, or raw chat.
 
 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
+approval, including when every proposed job is OPEN or neutral. The local
+projection contains each member's `jobId` and value-free `accessKnowledge`;
+the rich `accessProposal.members[]` receipt contains the contiguous position,
+rationale, and approval metadata. Show those exact job IDs and scheduling
+reasons in order and require the compact projection's ordered IDs and access
+knowledge to match the rich receipt. 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