trackly-cli 0.13.4 → 0.14.1

package/npm-shrinkwrap.json

@@ -1,18 +1,20 @@
 {
   "name": "trackly-cli",
-  "version": "0.13.4",
+  "version": "0.14.1",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "trackly-cli",
-      "version": "0.13.4",
+      "version": "0.14.1",
       "license": "MIT",
       "dependencies": {
         "@modelcontextprotocol/sdk": "1.30.0",
+        "@posthog/mcp": "0.11.0",
         "fast-uri": "3.1.5",
         "hono": "4.13.0",
         "ip-address": "10.4.0",
+        "posthog-node": "5.48.1",
         "zod": "^3.23.0"
       },
       "bin": {
@@ -23,7 +25,7 @@
         "acorn": "8.18.0"
       },
       "engines": {
-        "node": ">=20"
+        "node": "^20.20.0 || >=22.22.0"
       }
     },
     "node_modules/@babel/helper-string-parser": {
@@ -128,6 +130,37 @@
         }
       }
     },
+    "node_modules/@posthog/core": {
+      "version": "1.46.9",
+      "resolved": "https://registry.npmjs.org/@posthog/core/-/core-1.46.9.tgz",
+      "integrity": "sha512-EXO6y5ih+jBkTCpUCuYgQmajuDZuvy6vMvflkub6pLQyi0GPlCPWVSvZZkOeQw9e2MxoD5GteeGCt9R8+UJ/yQ==",
+      "license": "MIT",
+      "dependencies": {
+        "@posthog/types": "^1.402.2"
+      }
+    },
+    "node_modules/@posthog/mcp": {
+      "version": "0.11.0",
+      "resolved": "https://registry.npmjs.org/@posthog/mcp/-/mcp-0.11.0.tgz",
+      "integrity": "sha512-wxvIvx2/MuXqDH9Zy99hqop6Hyhymn8aoh7e7wYOH3AUdeohZhom2W8E2UDgBO63eR/vm8QGH/fidyA6H+KNyA==",
+      "license": "MIT",
+      "dependencies": {
+        "@posthog/core": "^1.46.9"
+      },
+      "engines": {
+        "node": "^20.20.0 || >=22.22.0"
+      },
+      "peerDependencies": {
+        "@modelcontextprotocol/sdk": ">=1.26.0",
+        "posthog-node": "^5.0.0"
+      }
+    },
+    "node_modules/@posthog/types": {
+      "version": "1.402.2",
+      "resolved": "https://registry.npmjs.org/@posthog/types/-/types-1.402.2.tgz",
+      "integrity": "sha512-ZZTiS4dLwF4/D0YTzS3gGSLFnhuNOY5yu4d9VGS9trGe5GW6FjIXo20p18K5BPW2RZSYSld8sdnSAY3AUXleUQ==",
+      "license": "MIT"
+    },
     "node_modules/accepts": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/accepts/-/accepts-2.0.0.tgz",
@@ -909,6 +942,26 @@
         "node": ">=16.20.0"
       }
     },
+    "node_modules/posthog-node": {
+      "version": "5.48.1",
+      "resolved": "https://registry.npmjs.org/posthog-node/-/posthog-node-5.48.1.tgz",
+      "integrity": "sha512-BxLX2SqGEQhPqCPTalpyo0RRv1NMbf7UaN7q9d/ED77ksD6XOmE7ko2vIKO8F0zPL1NtKxIi+DYXap9lvR0RaA==",
+      "license": "MIT",
+      "dependencies": {
+        "@posthog/core": "^1.46.9"
+      },
+      "engines": {
+        "node": "^20.20.0 || >=22.22.0"
+      },
+      "peerDependencies": {
+        "rxjs": "^7.0.0"
+      },
+      "peerDependenciesMeta": {
+        "rxjs": {
+          "optional": true
+        }
+      }
+    },
     "node_modules/proxy-addr": {
       "version": "2.0.7",
       "resolved": "https://registry.npmjs.org/proxy-addr/-/proxy-addr-2.0.7.tgz",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "trackly-cli",
-  "version": "0.13.4",
+  "version": "0.14.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": {
@@ -63,13 +63,15 @@
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "1.30.0",
+    "@posthog/mcp": "0.11.0",
     "fast-uri": "3.1.5",
     "hono": "4.13.0",
     "ip-address": "10.4.0",
+    "posthog-node": "5.48.1",
     "zod": "^3.23.0"
   },
   "engines": {
-    "node": ">=20"
+    "node": "^20.20.0 || >=22.22.0"
   },
   "overrides": {
     "@hono/node-server": "2.0.12",

package/server.json

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

package/skills/trackly-apply/SKILL.md

@@ -27,7 +27,7 @@ references define the server-frozen batch, grouped-question, tab-reconciliation,
 and missing-surface recovery contract; they are mandatory even for a one-job batch.
 Read [references/legal-clarifications.md](references/legal-clarifications.md) when a form asks for a legal, regulatory, consent, or employer-relationship decision.
 
-1. Call `trackly_get_apply_protocol`. Skill 4.4.2 requires protocol 3.5.0 or newer for new reliability work. Protocol 3.2 remains valid only for an already-active explicit legacy single run; an already-active explicit 3.2 single run may finish through its legacy path. Preserve the protocol's documented recovery paths for already-active older work. Require `compatibleSkillMajor: 4` and `compatibleSkillMinimumVersion` no newer than this installed skill. Reject an older or incompatible version for new work and report that the backend must finish updating or `trackly agent setup` must update the skill. Protocol 3.2 added exact-origin trust for jobs Trackly ingested directly from employer careers sources; do not recreate the retired ownership-timestamp gate in the client.
+1. Call `trackly_get_apply_protocol`. Skill 4.5.0 requires protocol 3.6.0 or newer for new reliability work. Protocol 3.2 remains valid only for an already-active explicit legacy single run; an already-active explicit 3.2 single run may finish through its legacy path. Preserve the protocol's documented recovery paths for already-active older work. Require `compatibleSkillMajor: 4` and `compatibleSkillMinimumVersion` no newer than this installed skill. Reject an older or incompatible version for new work and report that the backend must finish updating or `trackly agent setup` must update the skill. Protocol 3.2 added exact-origin trust for jobs Trackly ingested directly from employer careers sources; do not recreate the retired ownership-timestamp gate in the client.
 2. Call `trackly_get_profile_onboarding` or fetch both the profile schema and application profile. When present, render `schema.screens` in ascending `order` as one grouped question packet per screen. Within a screen, preserve category `order` and then field `order`; use each field's user-facing `rationale` when the user asks why it is needed. Ask only unknown or confirmation-needed fields and honor `consistencyRules` before submitting profile changes, resolving contradictions with the user instead of guessing. When `schema.screens` is absent on a legacy backend, fall back to the existing category-based onboarding behavior. Treat `completeness.percent` as required onboarding readiness only. Use `coverage.missingReusableKeys` to explain reusable optional gaps, while `coverage.contextualKeys` are intentionally asked only on the relevant employer form. Do not claim that 100% required completeness answers every possible application question.
 3. Save answers with `trackly_update_application_profile`:
    - Use `answered`, `intentionally_blank`, `declined`, or `unknown` exactly.
@@ -44,7 +44,9 @@ Read [references/legal-clarifications.md](references/legal-clarifications.md) wh
    - Use `writing.em_dash_policy` and `writing.optional_question_policy` when the fetched schema exposes them. An unanswered em-dash policy fails closed to `forbid` for form writing.
    - Infer a direct prior-employer answer of No only when the profile explicitly marks history complete, the target and backend-confirmed aliases are absent, and the question is limited to direct employment. Ask for subsidiary, affiliate, acquisition, contractor, or otherwise ambiguous relationships.
 4. Require the one-time profile confirmation, complete education entries, and default-resume metadata before browser work. Do not prepare or upload the resume when the form has no attachment control.
-5. For every protocol 3.4 or newer request, call `trackly_get_active_apply_execution` before legacy recovery. Resume execution work only when the response says `active: true`. A response with `preserved: true` and `active: false` exposes a stopped, closed, or otherwise terminal execution only for read-only reconciliation. Never fetch its compact snapshot, continue its wave, mutate its members, or interpret historical `currentlyFilling` or reservation counts as current work; require `progress.nextAction: none`. Only with protocol 3.5 or newer and an enabled compact-snapshot capability may an active recovery or new execution call `trackly_get_apply_execution_snapshot`, using only the current member IDs, profile keys needed by the visible forms, and actual browser surface. An already-active protocol 3.4 execution is read-only legacy recovery: use only its published get or stop operations, never call the 3.5-only snapshot, resume, approval, advance, or disposition tools, and never mutate its browser forms. For protocol 3.5 or newer, treat snapshot `mutable` and `allowedOperations` values as authoritative. Never mutate or reopen authentication, account-creation, OTP, pre-form-CAPTCHA, or manual-only members. Only an explicit user request may call `trackly_resume_parked_apply_member`; the returned member still requires a fresh non-mutating probe before private data or form mutation. Resume unresolved waves in ascending order only for `active: true` and obey the server `nextAction` and funnel. Never reconstruct progress or choose replacements locally. Count only `durablyReviewReady` and `submitted`; let the backend own reservations, capacity, attempted-job deduplication, immutable waves, and advancement. Continue until `targetReached`, `queueExhausted`, a blocking `nextAction`, or the user stops.
+5. For every protocol 3.4 or newer request, call `trackly_get_active_apply_execution` before legacy recovery. Resume execution work only when the response says `active: true`. A response with `preserved: true` and `active: false` exposes a stopped, closed, or otherwise terminal execution only for read-only reconciliation. Never fetch its compact snapshot, continue its wave, mutate its members, or interpret historical `currentlyFilling` or reservation counts as current work; require `progress.nextAction: none`. Only with protocol 3.5 or newer and an enabled compact-snapshot capability may an active recovery or new execution call `trackly_get_apply_execution_snapshot`, using only the current member IDs, profile keys needed by the visible forms, and actual browser surface. An already-active protocol 3.4 execution is read-only legacy recovery: use only its published get or stop operations, never call the 3.5-only snapshot, resume, approval, advance, or disposition tools, and never mutate its browser forms. For protocol 3.5 or newer, treat snapshot `mutable` and `allowedOperations` values as authoritative. Never mutate or reopen authentication, account-creation, OTP, pre-form-CAPTCHA, or manual-only members. Only an explicit user request may call `trackly_resume_parked_apply_member`; the returned member still requires a fresh non-mutating probe before private data or form mutation. Resume unresolved waves in ascending order only for `active: true` and obey the server `nextAction` and funnel. Never reconstruct progress or choose replacements locally. Treat backend `achievementCount`, target-capped `completed`, `targetReached`, and `nextAction` as authoritative. `durablyReviewReady` and `submitted` remain current operator projections and must never be added together by the client to reconstruct cumulative completion. Let the backend own reservations, capacity, attempted-job deduplication, immutable waves, and advancement. Continue until `targetReached`, `queueExhausted`, a blocking `nextAction`, or the user stops.
+   - After full local context loss with no active execution, call `trackly_list_recoverable_apply_executions`. For every distinct returned `jobId`, call `trackly_get_job`, bind that Trackly-owned job record to the returned `candidateId`, and show the user its company, role, requisition identity when available, and source-execution identity; do not identify candidates from chat, tab order, search results, or page copy. A missing or mismatched Trackly job record blocks confirmation. Require explicit confirmation of one exact candidate set, then call `trackly_recover_exact_apply_members` with that source execution, snapshot hash, and only those candidate IDs. Verify `assertedCandidateIds`, `eligibleCandidateIds`, and the eligibility candidate IDs each contain exactly the confirmed set with no duplicates. Never add substitutes, newly saved jobs, or merely similar roles.
+   - Exact recovery restores server lineage only. Treat tab restored, form state restored, and mutation authority restored as three independent receipts. Bind every recovered surface with a fresh recovery binding and inspection epoch, revalidate the full form, and preserve every user-edited or unknown non-empty value before any write. Earlier-epoch browser, field, upload, integrity, and submission evidence cannot authorize the recovered form.
    - Every compact snapshot request must contain a non-empty list of only the current member IDs. Never request an empty or inferred all-members projection.
    - 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.
@@ -69,7 +71,7 @@ Read [references/legal-clarifications.md](references/legal-clarifications.md) wh
    - For each fixed batch member, preserve an explicit job ID -> application run ID -> browser tab mapping. Complete the full start -> conditional resume preparation/confirmation/verification when an upload control exists -> form completion -> `review_ready` lifecycle for every member. A review-ready run does not block the next member. Never submit any of them.
 6. When the selected job or current fixed batch member has no `runId`, call `trackly_start_apply_run` with the complete `batchId`, `memberId`, `expectedMemberVersion`, `expectedInspectionEpoch`, and `leaseToken` returned by Trackly. This is the sanctioned idempotent lookup for a recovered member whose `runId` is absent; call it with the exact recovered binding and Trackly will reuse the bound active run. When the member already has a `runId`, do not call `trackly_start_apply_run` in this or any subsequent start step: reuse that exact run and bind or recover its browser surface through `trackly_bind_apply_surface` as required. Never create a replacement run because browser control was interrupted.
    - If a bound start returns a transport failure, a non-access HTTP 5xx response, or an error explicitly marked `retryable: true`, preserve the frozen member and browser state. Refetch the active batch, renew its lease, and retry the same complete binding once. Classify the retry response independently with these same rules: route canonical `maintenance_mode` or legacy `planned_maintenance` directly through **Resume after maintenance**; surface controlled-access/request errors marked `retryable: false` and every other HTTP 4xx response unchanged; only a second transport failure, non-access HTTP 5xx response, or explicitly retryable error becomes `backend_run_start_unavailable`. Route maintenance on either attempt without consuming or relabeling the retry, and never relabel a permanent retry response as an outage. For `backend_run_start_unavailable`, continue other members and report a Trackly control-plane failure. Do not call `trackly_checkpoint_apply_batch` for this condition because start failure has not produced the required run ID. The unchanged frozen member is the durable resume point. Never switch that frozen member to an unbound legacy run or blame the employer form.
-   - Require `run.protocolVersion` to be 3.1.0 or newer and to share protocol major 3 with the fetched protocol. A new reliability execution member requires 3.5.0 or newer; already-active older work may use only the recovery path published by its fetched protocol. Never continue a pre-evidence 3.0.x run under skill 4.4.2. Preserve that run instead of starting a replacement, record it `blocked` with a value-free protocol-upgrade reason when possible, and tell the user the saved job can be retried only after the stale run is cleared through Trackly's supported lifecycle. Stop and refetch the protocol and active execution or batch if support level, execution mode, provider, required scenarios, authorized origin policy, member version, or inspection epoch changes after run creation.
+   - Require `run.protocolVersion` to be 3.1.0 or newer and to share protocol major 3 with the fetched protocol. A new reliability execution member requires 3.6.0 or newer; already-active older work may use only the recovery path published by its fetched protocol. Never continue a pre-evidence 3.0.x run under skill 4.5.0. Preserve that run instead of starting a replacement, record it `blocked` with a value-free protocol-upgrade reason when possible, and tell the user the saved job can be retried only after the stale run is cleared through Trackly's supported lifecycle. Stop and refetch the protocol and active execution or batch if support level, execution mode, provider, required scenarios, authorized origin policy, member version, or inspection epoch changes after run creation.
    - In guided mode, inspect the page before preparing any resume bytes. Confirm the employer, role, HTTPS origin, reachable review path, semantic controls, whether an attachment control exists, and absence of a credential, verification, CAPTCHA, or submit-only wall. A missing file input is not itself a blocker; skip the resume path when the application has no attachment control. Any other failed precondition is an execution blocker, not permission to improvise.
 7. Pass the browser readiness gate before preparing resume bytes:
    - Use semantic browser control through Codex in-app browser controls, Chrome MCP/extension browser control, or Claude in Chrome.
@@ -79,7 +81,7 @@ Read [references/legal-clarifications.md](references/legal-clarifications.md) wh
    - After a handoff, context resume, or browser-control interruption, reclaim and re-verify every mapped tab before continuing.
    - Report `observationType: browser_ready` for the current run with the exact current `batchId`, `memberId`, and `inspectionEpoch`, plus `scenarioCode: browser_reclaim`, the allowed `browserSurface`, `committed: true`, and that `browserBindingHash`. Do not call `trackly_prepare_resume` until this same-run attestation succeeds. When preparation is permitted, bind it to the exact run ID, browser surface, and browser binding hash. Accessibility may provide an independent verification signal, but coordinate-only clicking is forbidden for form completion.
    - If the semantic browser bridge is unavailable, preserve every existing run and tab mapping, record the blocker when possible, and stop before any upload or form mutation.
-8. If and only if the application offers or requires a resume attachment, read [references/browser-upload.md](references/browser-upload.md). For an accessible execution, call `trackly_approve_apply_execution_resume` once after the user approves the exact unchanged resume and original snapshot. Reuse only that content approval within the unchanged execution. For every run, still call `trackly_prepare_resume` with the exact run ID, browser surface, and binding hash and immediately verify the exact path, hash, size, and expiration before upload. If hosted MCP reports local preparation unavailable, use local Trackly MCP or manual upload. If no attachment control exists, skip steps 8–11 and do not report `resume_upload` as exercised.
+8. If and only if the application offers or requires a resume attachment, read [references/browser-upload.md](references/browser-upload.md). For an accessible execution, call `trackly_approve_apply_execution_resume` once after the user approves the exact unchanged resume and original snapshot. Reuse only that content approval within the unchanged execution. For every run, still call `trackly_prepare_resume` with the exact run ID, browser surface, and binding hash and immediately verify the exact path, hash, size, and expiration before upload. Require the browser upload capability gate and the local `trackly_validate_apply_resume_upload` stage proof before claiming attachment success. If hosted MCP reports local preparation unavailable, use local Trackly MCP or manual upload. If no attachment control exists, skip steps 8–11 and do not report `resume_upload` as exercised.
 9. Preserve the user’s filename returned by `trackly_prepare_resume`. Internal cache identifiers belong only in private parent directories and must never appear in the employer-facing upload filename.
 10. Before any upload, let the user inspect the exact prepared file returned by `trackly_prepare_resume`:
    - Prefer an inline visual preview. Otherwise open the exact local file in Quick Look or Preview.app.
@@ -138,6 +140,12 @@ Every required scenario and both universal evidence scenarios must have correspo
 
 ## Review handoff
 
+After context loss, call `trackly_list_apply_review_handoffs` for the execution
+before interpreting any grouped submission statement. Use the named receipt or
+the sole active receipt returned by Trackly; if multiple receipts remain, ask
+the user to identify the intended group. Never guess a receipt from tabs or
+chat history.
+
 After every conditional field is settled and all other review gates pass, bulk checkpoint every ready member with `review/manual_submit`, the current unchanged inspection epoch in both epoch fields, and any `resolvedActionIds`. Use the returned member versions and epochs; this checkpoint resolves the listed human actions and moves the durable member lifecycle to `review_ready` without invalidating current-epoch browser evidence or an unchanged resume-content approval. Do not wait for `needs_input` members: whenever at least one member is durably `review_ready`, ask for one explicit final truthfulness confirmation for the exact complete subset that is currently `review_ready`. If any form in that certified subset used a resume attachment, certify with `resumeDependency: approved` and the exact approved resume identity. If no form in the subset exposes a resume control, certify with `resumeDependency: not_applicable` and omit the resume ID and hash; do not invent an upload requirement. Then call `trackly_record_application_outcomes` once with every member in that certified subset using its exact current `runId`, `batchId`, `memberId`, `inspectionEpoch`, and `leaseToken`; every item must use the literal `outcome: review_ready`. Verify every recorded run returns `awaiting_manual_submit` before showing the review handoff. A member conflict does not invalidate successful siblings: preserve its tab, refresh that member once, and surface the returned stable conflict code instead of blindly replaying a different transition. A member that becomes ready later requires a fresh certification for the then-current complete `review_ready` subset; never reuse an older certification for it. Use singular `trackly_record_application_outcome` only for a legacy single run or an isolated post-review transition. Use the normal review block in [references/review-handoff.md](references/review-handoff.md) only after documented visibility proof for the exact review tab succeeds. If visibility is unverified, preserve the tab, use the separate visibility-unverified block, and do not tell the user to submit until the tab is reclaimed and visibly proven. For a single run, keep the browser on the final review state and stop. For a frozen batch, preserve every review-ready tab, hand off each certified review-ready subset without waiting on unrelated human actions, and continue the same lifecycle for the remaining mapped members. Members with unresolved actions stay frozen and resumable. Never submit any member. End with job ID -> run ID -> browser tab -> ATS -> status plus the actual scenario coverage for each run.
 
 After the user submits manually:

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

@@ -1,6 +1,11 @@
 # Batch orchestration
 
 Protocol 3.4 adds a server-owned Apply execution above immutable child batches.
+Protocol 3.6 adds exact-member recovery after local context loss and scoped
+review-handoff reconciliation.
+After context loss, rediscover active handoff receipts with
+`trackly_list_apply_review_handoffs`; never reconstruct or guess a handoff ID
+from chat history, tab order, or application similarity.
 The execution is the target-completion ledger; each child batch remains the
 auditable browser-work unit. Protocol 3.3 fixed batches and protocol 3.2 single
 runs remain recovery-only compatibility paths.
@@ -57,6 +62,35 @@ its top-level `response.batchId`. Never guess across those response shapes. If
 the applicable field is null or `unresolvedWaves` is empty, follow
 `response.progress.nextAction` rather than guessing a prior batch.
 
+## Exact recovery after local context loss
+
+When no active execution exists but unfinished lineage may still be retained,
+call `trackly_list_recoverable_apply_executions`. The returned source snapshot
+and candidates are the complete bounded recovery menu. Resolve every distinct
+returned `jobId` through `trackly_get_job`, bind that Trackly-owned record to
+its `candidateId`, and present its company, role, requisition identity when
+available, and source execution to the user. A missing or mismatched Trackly
+job record blocks confirmation. Require explicit confirmation of the exact
+candidate set. Never infer the set from browser tabs, conversation memory,
+search results, page copy, employer similarity, or queue position.
+
+Call `trackly_recover_exact_apply_members` with one source execution, its exact
+snapshot hash, the confirmed candidate IDs, and a fresh idempotency key. The
+response may never replace candidates. Verify that `assertedCandidateIds`,
+`eligibleCandidateIds`, and the eligibility candidate IDs each contain exactly
+the user-confirmed set with no duplicates before browser work.
+
+Recovery has three independent proof dimensions:
+
+1. the exact browser tab was restored;
+2. the employer form state was restored or safely reconstructed; and
+3. Trackly granted current mutation authority.
+
+Never let one imply another. Rebind each recovered surface, accept the new
+inspection epoch, inventory the form, preserve every user-edited and unknown
+non-empty field, and rerun required integrity evidence. All prior-epoch
+browser, upload, field, review, and submission evidence is stale.
+
 ## Replace an obsolete fixed batch
 
 An active legacy fixed batch and a new accessible execution are mutually

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

@@ -92,6 +92,13 @@ Before resuming, handing off, or closing a tab:
 5. Reclaim a matching tab only after employer, role, requisition, HTTPS origin,
    ATS tenant when applicable, run ID, and browser binding all revalidate.
 
+Immediately before a session-finalizer call, pass the complete expected and
+keep sets plus complete controller and user inventories through
+`trackly_validate_apply_tab_keep_set`. Continue only when it returns
+`safeToFinalize: true`. This helper is a local validator, not a browser
+controller: it does not discover, focus, close, hand off, or finalize tabs.
+Unrelated tabs may remain in the inventories. Raw tab IDs stay local.
+
 For every initial tab and every recovery, call `trackly_bind_apply_surface`
 with the existing frozen member and run. Use `initial_binding` for the first
 surface and `recovery_binding` after a missing tab or handoff. The returned URL
@@ -253,6 +260,13 @@ When an incomplete member's tab is missing:
    revalidate the exact requisition before recording any outcome and never
    activate Submit again.
 
+When protocol 3.6 exact-member recovery created the current execution, prove
+three facts separately in the operator receipt: whether the tab was restored,
+whether the employer form state was restored or reconstructed, and whether
+current mutation authority was reacquired. A recovered tab alone never grants
+write authority. A recovered server member alone never proves the draft or tab
+survived.
+
 If the recovered origin or identity differs, semantic controls are
 unobservable, or access is blocked by credentials or a pre-form challenge,
 stop private-data mutation and create the appropriate human action. Continue

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

@@ -1,11 +1,43 @@
-# Browser upload contract
+# Browser upload
 
-Use semantic browser controls only. Coordinates, text injection, and a visible filename without committed input state are not upload proof.
+Resume approval proves the content the user authorized. Attachment proof proves
+that the browser committed that exact file. Neither fact substitutes for the
+other.
 
-1. Discover the exact attachment control semantically.
-2. Open its file chooser through the browser adapter.
-3. Use the adapter's advertised `setFiles` capability with the immediately verified local path.
-4. Verify the employer-facing filename exactly matches the prepared user-facing filename and contains no cache identifier.
-5. Recheck contact and parser-modified fields after the upload settles.
+## Capability gate
 
-Require all five proofs: `semantic_control_discovered`, `file_chooser_opened`, `set_files_succeeded`, `user_facing_filename_committed`, and `parser_fields_rechecked`. Fail closed when the active browser surface cannot prove any step. Never substitute an undocumented browser primitive.
+Before opening a file chooser, require the active browser adapter to advertise
+all five capabilities: semantic control discovery, chooser arming, file
+attachment, committed-filename inspection, and parser-field recheck. If any is
+missing, fail closed before opening the chooser and hand the upload to the user. Never
+navigate to a `file://` URL or paste a local path into an ordinary text field.
+
+Perform these stages in exact order:
+
+1. identify the exact semantic Resume or CV control;
+2. arm the file chooser before clicking that control;
+3. prove the chooser opened;
+4. run `trackly_verify_prepared_resume`, then immediately attach that verified
+   file through the adapter's documented file-setting primitive;
+5. verify the employer-facing filename committed; and
+6. recheck every contact, employment, education, and other field that resume
+   parsing may have changed.
+
+Pass only the value-free stage outcomes to
+`trackly_validate_apply_resume_upload`. Do not pass a filename, local path,
+resume hash, form value, URL, page text, or tab identifier. Claim attachment
+success only when it returns `safeToClaimAttachment: true`.
+
+Stable failure codes include capability unavailable, ambiguous control,
+chooser timeout, chooser opened without a commit, missing or expired file,
+file-setting failure, uncommitted filename, unexpected file navigation,
+unsettled parser, and parser-field regression. A failure is a handoff or retry
+decision, never permission to guess another control or weaken verification.
+
+Snapshot field provenance immediately before upload. Mark parser changes as
+`parser_filled`; preserve a later user edit byte-for-byte. After ledger loss,
+preserve every unknown non-empty value. Never let parser rechecks or the final
+required-field sweep overwrite user-owned or unknown external values.
+
+The employer-facing filename must remain the user's confirmed filename.
+Random cache identifiers may appear only in private parent directories.

package/skills/trackly-apply/references/review-handoff.md

@@ -15,6 +15,53 @@ Funnel: target=; ready=; submitted=; filling=; awaitingAnswer=; authParked=; exc
 
 Use the compact execution snapshot as authority. Give a bounded next-update estimate, not an invented overall completion time.
 
+## Deterministic operator receipts
+
+Every handoff names the browser surface and authoritative funnel. Use the
+matching template; do not improvise internal routing language.
+
+### Recovery
+
+```text
+Recovery in progress — not submitted
+Completed: exact Trackly source and user-confirmed candidate set recovered
+Tab restored: yes/no
+Form state restored: yes/no
+Current mutation authority: yes/no
+Unresolved:
+Your next action: wait / inspect / answer
+Resume: exact approved resume / no attachment / manual upload required
+Browser surface:
+Funnel:
+My next action:
+```
+
+### Upload requires the user
+
+```text
+Application preserved — resume upload requires you
+Completed:
+Unresolved: browser surface cannot prove the required attachment stages
+Your next action: attach the exact approved resume and confirm the committed filename
+Resume: exact approved resume
+Browser surface:
+Funnel:
+My next action: recheck parser-modified fields, finish integrity sweep, stop at review
+```
+
+### Submission reconciled
+
+```text
+Submission confirmed and reconciled
+Completed: success evidence recorded; member=submitted; job=applied_confirmed
+Unresolved: tab cleanup pending / none
+Your next action: none
+Resume: exact approved resume / no attachment
+Browser surface:
+Funnel:
+My next action: verify authorized tab disposition only
+```
+
 ## Approval scope receipt
 
 Before persisting a broad statement such as “always,” show which separate categories it will update: personal facts, consent choices, writing preferences, resume approval, and truthfulness certification. Never let approval of one category authorize another. Consolidate genuinely unknown questions into one packet after filling everything already known. Explain legal terms in plain language using the protocol glossary; do not expose internal action codes or routing labels.
@@ -141,5 +188,45 @@ open for manual submission, and list remaining human actions separately.
 Members that become ready later require a new certification for the exact
 then-current `review_ready` subset.
 
+## Group submission reconciliation
+
+A broad statement such as “I submitted all of them” applies only to one
+explicit review-handoff receipt. Call `trackly_list_apply_review_handoffs` for
+the execution, then resolve it to the receipt the user names or to the sole
+active receipt returned by Trackly. If multiple receipts could
+match, ask the user to choose; never fan the statement across executions or
+tabs.
+
+Inspect every member in the selected receipt and classify exactly one of:
+`detected`, `user_confirmed`, `unresolved`, or `contradictory`. Use
+provider-positive evidence only:
+
+- Greenhouse: a same-requisition thank-you page, confirmation route, or
+  semantic success state;
+- Ashby: a same-requisition explicit application-success banner or page,
+  including when the route does not change; and
+- Lever: a same-requisition confirmation redirect or semantic success state.
+
+An unchanged URL or page title is never evidence that submission failed. Build
+any local `DetectedSubmission` only from a versioned provider strategy, the
+handoff/member identity, current inspection epoch, evidence type, confidence,
+and a value-free fingerprint derived from those identifiers. Never hash DOM
+text, URLs, local paths, or raw tab IDs into that record.
+
+If a rediscovered receipt is `partially_reconciled`, preserve every member that
+already has a stored reconciliation result and inspect only members whose
+stored result remains `unresolved`. Do not replay the original claim with a
+partial member list: the claim receipt is an immutable exact-set idempotency
+record. Record later positive evidence and submitted outcomes through the
+normal per-member outcome path, naming the receipt and only its unresolved
+members in any follow-up confirmation.
+
+Call `trackly_claim_apply_review_handoff` with the exact receipt and a
+classification for every member. Write submission evidence and outcomes only
+for `detected` and `user_confirmed`. Ask one consolidated question containing
+only the `unresolved` members. Preserve every `contradictory` member and its
+tab without an outcome. Refetch and require member `submitted` plus job
+`applied_confirmed` before any authorized closure.
+
 Do not include restricted answers in chat unless needed for the user’s review.
 Never include credentials, an OTP, or a CAPTCHA response.