trackly-cli 0.17.1 → 0.18.1

package/README.md

@@ -35,7 +35,7 @@ trackly jobs --function product
 
 ## At a Glance
 
-3,800+ companies | 170K+ jobs | 40+ ATS types | CLI + MCP | 55 local MCP tools
+3,800+ companies | 170K+ jobs | 40+ ATS types | CLI + MCP | 58 local MCP tools
 
 ## CLI Commands
 
@@ -189,7 +189,10 @@ Then use natural language in any of these clients:
 | trackly_get_apply_execution_snapshot | Fetch a compact bounded projection for current execution members and required profile keys |
 | trackly_resume_parked_apply_member | Explicitly resume one parked member for a fresh non-mutating access probe |
 | trackly_approve_apply_execution_resume | Approve one exact resume identity for an unchanged execution snapshot |
-| trackly_advance_apply_execution | Transactionally create the next eligible immutable wave |
+| trackly_advance_apply_execution | Transactionally create the next eligible immutable wave with frozen accessKnowledge |
+| trackly_list_apply_access_deferments | List persistent user access deferments |
+| trackly_defer_apply_access | Persist a job or company deferment from a Trackly jobId |
+| trackly_clear_apply_access_deferment | Clear one discovered user access deferment |
 | trackly_record_apply_execution_dispositions | Record typed, value-free access classifications |
 | trackly_stop_apply_execution | Stop an execution without changing saved-job state |
 | trackly_create_apply_batch | Freeze an exact recent-first approved batch |
@@ -282,7 +285,7 @@ trackly config --base-url http://127.0.0.1:3000  # Point at a different backend
 | Job search + filters | Yes | Yes | Yes |
 | Apply/save/dismiss | Yes | Yes | Yes |
 | AI-powered search | Yes (trackly ask) | Yes | Yes |
-| MCP integration | Yes (55 local tools) | -- | -- |
+| MCP integration | Yes (58 local tools) | -- | -- |
 | Browser required | No | Yes | No |
 | Best for | Terminal + AI agents | Visual browsing | Custom integrations |
 
@@ -296,7 +299,7 @@ Install trackly-cli (`npm install -g trackly-cli`), authenticate with `trackly l
 
 **What MCP servers exist for job searching?**
 
-trackly-cli includes a built-in MCP server with 55 tools: the complete Trackly
+trackly-cli includes a built-in MCP server with 58 tools: the complete Trackly
 job-search and application set plus `get_more_tools`, which lets agents report
 a missing capability. Run `trackly mcp` or use
 `trackly agent setup --client claude`.

package/contracts/trackly-apply-contract-history.json

@@ -32,5 +32,11 @@
   },
   "3.7.6": {
     "contractSha256": "259f4c0b52739956fced3936e36792b27960dcad820659994f3e9107453a5844"
+  },
+  "3.8.0": {
+    "contractSha256": "5404c2f210b584d4f1327d34e9753530c56a9dd963ea9524081d0d00b229df2e"
+  },
+  "3.8.1": {
+    "contractSha256": "49028b8a8e1d75a8db6e54dd91001195f8a2e50b1f0ff6554750bd243dde4c6e"
   }
 }

package/contracts/trackly-apply-tools.json

@@ -1,6 +1,8 @@
 {
-  "contractVersion": "3.7.6",
+  "contractVersion": "3.8.1",
   "constants": {
+    "applyExecutionProtocolVersion": "trackly-apply-execution/v3",
+    "applyAccessKnowledgeOrderingVersion": 3,
     "applyExecutionMaxTarget": 20,
     "applyScenarioCodes": ["browser_reclaim", "resume_upload", "resume_parser_recheck", "semantic_boolean_commit", "custom_select_commit", "multi_step_navigation", "free_text_voice", "required_error_sweep", "final_consent", "handoff_reclaim", "critical_contact_integrity", "manual_submit_boundary", "job_identity_match"],
     "applyBrowserSurfaces": ["codex_in_app", "chrome_extension", "claude_in_chrome"],
@@ -12,7 +14,7 @@
     "applyExecutionDispositionSources": ["live_probe"],
     "applyProbeCleanupPreferences": ["never", "submitted_only", "submitted_and_probe_blockers"],
     "applyExecutionStopReasonCodes": ["user_requested", "target_changed", "session_ended", "execution_restarted", "operator_stop"],
-    "applyBatchConflictCodes": ["state_changed", "lease_unavailable", "idempotency_key_reused", "fixed_batch_not_found", "execution_child_batch", "fixed_batch_not_active", "fixed_batch_revision_changed", "submission_in_progress", "attestation_dependencies_changed", "legacy_fixed_batch_active", "dedicated_recovery_required", "recovery_migration_not_ready"],
+    "applyBatchConflictCodes": ["state_changed", "lease_unavailable", "idempotency_key_reused", "fixed_batch_not_found", "execution_child_batch", "fixed_batch_not_active", "fixed_batch_revision_changed", "submission_in_progress", "attestation_dependencies_changed", "legacy_fixed_batch_active", "dedicated_recovery_required", "recovery_migration_not_ready", "access_deferment_limit_reached", "access_deferments_active"],
     "fixedApplyBatchCancelReasonCodes": ["user_requested_restart"],
     "applyCheckpointPacketPhases": ["first_pass", "delta"],
     "applySurfaceBindingReasons": ["initial_binding", "recovery_binding"],
@@ -23,6 +25,12 @@
     "applyPositiveSubmissionStrategyCodes": ["greenhouse_confirmation_redirect", "greenhouse_semantic_success", "ashby_semantic_success_banner", "ashby_submitted_state", "lever_confirmation_redirect", "lever_semantic_confirmation"],
     "applyExecutionRecoveryEligibilityCodes": ["recoverable", "already_applied", "inactive", "revoked", "changed_requisition", "concurrently_owned", "lineage_unavailable", "retention_expired"],
     "applyHandoffReconciliationClassifications": ["detected", "user_confirmed", "unresolved", "contradictory"],
+    "applyObservedAccessClassifications": ["open", "account_wall", "varies", "unknown"],
+    "applyAccessKnowledgeSources": ["curated_audit", "live_probe", "none"],
+    "applyAccessFreshnessStates": ["fresh", "stale", "unknown"],
+    "applySchedulingEffects": ["prefer", "neutral", "defer_while_alternatives_exist", "defer_until_cleared"],
+    "applyAccessDefermentScopes": ["job", "company", "provider"],
+    "applyAccessMatchedScopes": ["job", "company", "provider_tenant", "origin", "route", "ats_default"],
     "applyUploadStages": ["semantic_control_discovered", "file_chooser_armed", "file_chooser_opened", "set_files_succeeded", "user_facing_filename_committed", "parser_fields_rechecked"],
     "applyUploadFailureCodes": ["upload_capability_unavailable", "upload_stage_missing", "upload_stage_out_of_order", "upload_stage_duplicate", "control_ambiguous", "chooser_timeout", "chooser_open_without_commit", "file_missing", "file_expired", "set_files_failed", "filename_uncommitted", "unexpected_file_navigation", "parser_unsettled", "parser_field_regression"]
   },
@@ -34,6 +42,24 @@
     },
     "trackly_get_apply_execution_snapshot": {
       "officeProjectionMemberIdsMustExistInMemberIds": true
+    },
+    "trackly_advance_apply_execution": {
+      "accessReviewApprovalJobIdsMustBeUnique": true,
+      "accessReviewApprovalRequiresClearedPersonalDeferment": true,
+      "sameKeyReplayReturnsIdenticalProposedWaveAndRationale": true,
+      "proposedWaveIncludesFrozenIdentity": true,
+      "approvalReceiptBindsFrozenIdentity": true
+    },
+    "trackly_defer_apply_access": {
+      "serverDerivesIdentityFromJobId": true,
+      "agentsCannotSubmitUrlsOrRawChat": true,
+      "providerScopeAppliesAcrossCompanies": true
+    },
+    "trackly_clear_apply_access_deferment": {
+      "clearRequiresDiscoveredDefermentId": true,
+      "idempotentReplayPreserved": true,
+      "clearReceiptIncludesClearedAt": true,
+      "clearReceiptPersistsUntilClearedFalse": true
     }
   },
   "schemaDigests": {
@@ -56,7 +82,10 @@
     "trackly_get_apply_execution_snapshot": "{executionId:z.number().int().min(1),memberIds:z.array(z.number().int().min(1)).min(1).max(APPLY_EXECUTION_MAX_TARGET).refine((values)=>newSet(values).size===values.length,{message:'memberIdsmustbeunique'}),profileKeys:z.array(z.string().min(1).max(200)).max(100).refine((values)=>newSet(values).size===values.length,{message:'profileKeysmustbeunique'}).optional(),officeProjections:z.array(z.object({memberId:z.number().int().min(1),office:officeScopeSchema,profileKeys:z.array(z.string().min(1).max(200)).min(1).max(100).refine((values)=>newSet(values).size===values.length,{message:'officeprofileKeysmustbeunique'})}).strict()).max(APPLY_EXECUTION_MAX_TARGET).refine((values)=>newSet(values.map(({memberId})=>memberId)).size===values.length,{message:'officeProjectionsmustcontainuniquememberIdvalues'}).optional(),browserSurface:z.enum(APPLY_BROWSER_SURFACES)}",
     "trackly_resume_parked_apply_member": "{executionId:z.number().int().min(1),memberId:z.number().int().min(1),expectedRevision:z.number().int().min(1),browserSurface:z.enum(APPLY_BROWSER_SURFACES),explicitUserResume:z.literal(true),idempotencyKey:z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY)}",
     "trackly_approve_apply_execution_resume": "{executionId:z.number().int().min(1),expectedRevision:z.number().int().min(1),originalSnapshotHash:z.string().regex(/^[a-f0-9]{64}$/),profileRevision:z.number().int().min(1),resumeId:z.number().int().min(1),resumeSha256:z.string().regex(/^[a-f0-9]{64}$/),resumeFilename:z.string().min(1).max(255),resumeSizeBytes:z.number().int().min(1),expiresAt:z.string().datetime(),idempotencyKey:z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY)}",
-    "trackly_advance_apply_execution": "{executionId:z.number().int().min(1),expectedRevision:z.number().int().min(1),browserSurface:z.enum(APPLY_BROWSER_SURFACES),idempotencyKey:z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY)}",
+    "trackly_advance_apply_execution": "{executionId:z.number().int().min(1),expectedRevision:z.number().int().min(1),browserSurface:z.enum(APPLY_BROWSER_SURFACES),idempotencyKey:z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY),accessReviewApproval:z.object({jobIds:z.array(z.number().int().min(1)).min(1).max(APPLY_EXECUTION_MAX_TARGET).refine((values)=>newSet(values).size===values.length,{message:'jobIdsmustbeunique'}),approvalHash:z.string().regex(/^[a-f0-9]{64}$/)}).strict().optional()}",
+    "trackly_list_apply_access_deferments": "{}",
+    "trackly_defer_apply_access": "{jobId:z.number().int().min(1),scope:z.enum(APPLY_ACCESS_DEFERMENT_SCOPES),idempotencyKey:z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY)}",
+    "trackly_clear_apply_access_deferment": "{defermentId:z.number().int().min(1),idempotencyKey:z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY)}",
     "trackly_record_apply_execution_dispositions": "{executionId:z.number().int().min(1),expectedRevision:z.number().int().min(1),idempotencyKey:z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY),dispositions:z.array(applyExecutionDispositionSchema).min(1).max(APPLY_EXECUTION_MAX_TARGET)}",
     "trackly_stop_apply_execution": "{executionId:z.number().int().min(1),expectedRevision:z.number().int().min(1),idempotencyKey:z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY),reasonCode:z.enum(APPLY_EXECUTION_STOP_REASON_CODES).optional()}",
     "trackly_create_apply_batch": "{limit:z.number().int().min(1).max(100),idempotencyKey:z.string().min(16).max(200).regex(SAFE_IDEMPOTENCY_KEY)}",

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/solutions/integration-issues/backend-owned-sensitive-answer-deletion-guard.md

@@ -0,0 +1,88 @@
+---
+title: Keep destructive confirmation guards at the mutation boundary
+date: 2026-08-28
+category: integration-issues
+module: Trackly Apply sensitive revocation
+problem_type: security_issue
+component: service_layer
+symptoms:
+  - A stale trackly-cli 0.10.0 MCP server could revoke sensitive-storage consent without presenting the new confirmation challenge
+  - The backend accepted an unconfirmed destructive request because confirmation was enforced only by caller-side tool handlers
+  - The bypass deleted 33 encrypted application-profile answers before a recovery archive existed
+root_cause: missing_validation
+resolution_type: code_fix
+severity: critical
+related_components: [assistant, api_layer]
+tags: [trackly-apply, sensitive-revocation, destructive-action, version-skew, backend-authority, mcp, data-loss]
+---
+
+# Keep destructive confirmation guards at the mutation boundary
+
+## Problem
+
+Sensitive-answer deletion originally used a two-step confirmation guard in the hosted and local MCP callers. That protected only clients running the new code. During verification, a stale local MCP server running trackly-cli 0.10.0 sent an unconfirmed revocation request directly to the backend, which accepted it and permanently deleted 33 encrypted answers before a recovery archive existed.
+
+This was a trust-boundary failure, not merely a missed client upgrade. Any old, alternate, or defective caller could omit a caller-owned safety check while still reaching the destructive service operation.
+
+## Symptoms
+
+- A destructive request from an older installed client bypassed the newly shipped caller-side guard. The incident transcript records the resulting loss of 33 encrypted answers; [trackly-cli PR #90](https://github.com/trackly-app/trackly-cli/pull/90) independently records stale CLI 0.10.0 as the failure mode.
+- The superseded implementation in [trackly-cli PR #89](https://github.com/trackly-app/trackly-cli/pull/89) computed the affected-key inventory and confirmation token in the client before sending the mutation.
+- Review found that a deterministic caller-computed token was an interaction speed bump, not a server-enforced consent boundary: an automated caller could derive or echo it without proving that a person saw the affected keys.
+
+## What Didn't Work
+
+The first implementation mirrored safety logic into local and hosted MCP handlers. The client recognized a revocation, fetched a profile, computed a challenge, and withheld the API request until the supplied token matched.
+
+That implementation could be thoroughly tested and still fail globally. A previously installed client had neither the preflight read nor the challenge branch, and the backend could not distinguish its unconfirmed request from an approved one. Duplicating the guard also forced callers to mirror the deletion predicate, token rules, revision behavior, and error shape. Those copies could drift independently from the mutation they were meant to protect.
+
+Adding more checks to every caller would not close the version-skew hole. Compatibility checks may make obsolete clients inconvenient to use, but they are not an authorization boundary for a reachable backend endpoint.
+
+## Solution
+
+Move the mandatory challenge-and-confirm invariant to the backend operation that performs the deletion, then keep MCP callers as thin protocol adapters. The backend implementation is outside this repository; internal/private [close-ai PR #1296](https://github.com/trackly-app/close-ai/pull/1296) and public [trackly-cli PR #90](https://github.com/trackly-app/trackly-cli/pull/90) record the service-authoritative design.
+
+The current CLI publishes `sensitiveRevocationConfirmToken` in the tool schema and forwards the complete request to the application-profile endpoint:
+
+```js
+wrapTool(async (params) => {
+  return applyApiRequest(
+    'PATCH',
+    '/api/jobscout/application-profile',
+    params,
+    false,
+    false,
+    MCP_USER_AGENT,
+  );
+}, 'Failed to update application profile')
+```
+
+The handler does not compute, strip, or validate its own copy of the guard (`mcp/apply-tools.js`). The MCP error mapper preserves the service's structured HTTP 409 challenge (`mcp/server.js`). The regression test in `test/mcp-schema.test.js` verifies that the CLI publishes the token field, relays the service challenge, forwards the confirmed token, and leaves ordinary opt-in as a single service round trip.
+
+PRs #89 and #90 are both merged into the default branch. PR #89 is important history because it demonstrates why the caller-owned design was insufficient; PR #90 is the corrective CLI design.
+
+## Why This Works
+
+Every backend-classified agent caller, including stale CLI and MCP versions, must cross the backend mutation boundary. A stale agent client may have a worse experience or be unable to complete a newer flow, but it cannot make the backend omit its own destructive-operation check. First-party UI clients intentionally retain their own single-call confirmation flows.
+
+The separation also removes semantic duplication. The backend owns the authoritative deletion decision, confirmation validity, revision binding, archive behavior, and mutation. MCP owns discoverability and transport: publish the token field, explain the two-step interaction, preserve the full request, and relay the service response.
+
+Internal/private [close-ai issue #1314](https://github.com/trackly-app/close-ai/issues/1314) remains administratively open, but current backend main appears to satisfy its scoped-inventory acceptance criteria through merged internal/private [close-ai PR #1369](https://github.com/trackly-app/close-ai/pull/1369): the service inventories sensitive and restricted rows across scopes, serializes scope identity into `affectedKeys`, and uses the same user-and-sensitivity predicate for archival and deletion. Close the issue only after confirming the fix is deployed and behaviorally verified; an open tracker alone is not evidence of a current functional gap.
+
+## Prevention
+
+- Treat destructive confirmation as a backend invariant and enforce it in the authoritative operation or transaction that changes the data.
+- Keep first-party dialogs and MCP challenge descriptions for user understanding, but never count them as the only protection.
+- Make callers forward the full confirmed request, and test the exact service-bound body.
+- Relay authoritative conflict payloads without regenerating the decision in the caller.
+- Test across the real trust boundary. A caller-only test proves the newest caller behaves correctly; it cannot prove an older caller is safe.
+- During coordinated releases, deploy and verify the server guard before removing caller-side defense in depth.
+- For every destructive control, ask what happens when the request comes from last month's client. If safety depends on that client running new code, the invariant is in the wrong layer.
+
+## Related Issues
+
+- [trackly-cli PR #89](https://github.com/trackly-app/trackly-cli/pull/89) — initial caller-owned guard, retained as the superseded attempt
+- [trackly-cli PR #90](https://github.com/trackly-app/trackly-cli/pull/90) — thin caller relay and service-authoritative correction
+- Internal/private [close-ai PR #1296](https://github.com/trackly-app/close-ai/pull/1296) — backend enforcement recorded by the coordinated fix
+- Internal/private [close-ai issue #1314](https://github.com/trackly-app/close-ai/issues/1314) and [close-ai PR #1369](https://github.com/trackly-app/close-ai/pull/1369) — tracker still open; current main contains the scoped-inventory fix pending deployment/behavior confirmation
+- [Durable exact recovery after browser state loss](durable-exact-recovery-after-browser-state-loss.md) — related Trackly Apply authority-boundary learning

package/docs/trackly-tools.md

@@ -115,7 +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`. Same-key retries return current authoritative progress and the current execution revision.
+- **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 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.
@@ -145,6 +148,12 @@ 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 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
 are bounded and value-free. The local helpers perform no browser actions and

package/lib/agent.js

@@ -8,13 +8,13 @@ const { spawnSync } = require('node:child_process');
 const { apiRequest, downloadFile, getConfigPaths, hasAuth, maintenanceOutput } = require('./client');
 const { version: PACKAGE_VERSION } = require('../package.json');
 const { contractVersion: MCP_CONTRACT_VERSION } = require('../contracts/trackly-apply-tools.json');
-const SKILL_VERSION = '4.7.1';
+const SKILL_VERSION = '4.8.0';
 const CLI_USER_AGENT = `trackly-cli/${PACKAGE_VERSION}`;
 const MCP_USER_AGENT = `trackly-mcp/${PACKAGE_VERSION}`;
 
 const SKILL_NAME = 'trackly-apply';
 const SKILL_MAJOR = Number(SKILL_VERSION.split('.')[0]);
-const MIN_APPLY_PROTOCOL_VERSION = '3.6.0';
+const MIN_APPLY_PROTOCOL_VERSION = '3.7.0';
 const CACHE_TTL_MS = 2 * 60 * 60 * 1000;
 const MANAGED_FILE = '.trackly-managed.json';
 const SKILL_MANIFEST_VERSION = 1;