trackly-cli 0.16.0 → 0.17.1

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

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

package/skills/trackly-apply/references/application-writing.md

@@ -8,7 +8,18 @@ Use this reference for free-text questions such as "Why this company?", motivati
 - These fields never block an application run when they are unknown. The user can continue with the plain default style for the current run or use saved style instructions; asking the user to paste a sample is a fallback only when they explicitly want to calibrate before a completed run provides approved text.
 - Only after durable submitted/applied reconciliation, offer once to save one to three of the user's approved free-text answers as the global `writing.voice_sample`. Show which answers would be included, require an explicit yes, and save nothing on silence or ambiguity. Because the field is sensitive, make the offer only with active sensitive-storage consent; otherwise ask for consent first or skip it. If the user chooses to decline a voice sample, save `writing.voice_sample` with state `declined` at global scope and no answer text so the offer is not repeated. The user may also choose intentionally blank style instructions.
 - Treat the sample and preferences as private user data. Never copy them into the public skill, logs, observations, or another user's defaults.
-- A separate humanizer or writing skill may be used when available, but it is optional. This gate remains authoritative and self-contained.
+- When the Humanizer skill is available, run it automatically for every
+  supported employer-specific draft before the anti-slop gate. Humanizer is
+  mandatory when available; do not wait for the user to remind you. The
+  self-contained anti-slop gate remains the mandatory fallback when Humanizer
+  is unavailable and the final authority in every environment. Mark Humanizer
+  `available` only when the current session exposes the `humanizer` skill and
+  its `SKILL.md` can be read. A matching file elsewhere on disk is not runtime
+  availability. If either check fails, record `unavailable` and use the fallback.
+- After Humanizer returns, treat the result as a new draft. Discard any earlier
+  claim-reference packet, rebuild it against the exact final revision, and run
+  deterministic lint only on that same revision. Never reuse a pre-Humanizer
+  lint result or claim proof.
 
 ## Draft from evidence
 
@@ -30,7 +41,14 @@ Before entering the response:
 
 1. Remove generic praise, inflated claims, vague transitions, boilerplate conclusions, and chatbot phrases.
 2. Rewrite `not just X, but Y`, ornamental rule-of-three lists, and dangling `-ing` clauses unless the user's sample clearly uses them naturally.
-3. Resolve `writing.em_dash_policy`; unanswered defaults to `forbid`. Build the complete local claim-reference packet and set `claimsComplete: true` only after checking the whole draft. Call `trackly_lint_application_text` and treat its deterministic lint as a blocking gate. Missing claim metadata is a failure, even for an apparently claim-free draft. Never enter text with a failed lint result. `allow_if_voice_sample` requires explicit saved evidence that the approved sample uses that punctuation.
+3. Resolve `writing.em_dash_policy`; unanswered defaults to `forbid`, so the
+   default output contains no em dash. Build the complete local claim-reference
+   packet and set `claimsComplete: true` only after checking the whole draft.
+   Call `trackly_lint_application_text` and treat its deterministic lint as a
+   blocking gate. Missing claim metadata is a failure, even for an apparently
+   claim-free draft. Never enter text with a failed lint result or an unsupported
+   claim. `allow_if_voice_sample` requires explicit saved evidence that the
+   approved sample uses that punctuation.
 4. Vary sentence length and structure. Avoid a sequence of equally sized, equally formal sentences.
 5. Prefer active verbs, concrete nouns, real numbers, and named examples already supported by the profile.
 6. Read the answer aloud. If it sounds like a press release, generic cover letter, or assistant response, rewrite it.

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

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

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

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

package/skills/trackly-apply/references/operational-checkpoints.md

@@ -0,0 +1,319 @@
+# Operational checkpoints
+
+Use this page as the run card. The detailed references define how to perform
+each action; this page defines when a phase is allowed to advance.
+
+## Invariant checklist
+
+- Keep the latest explicit target as the hard target. An earlier target never
+  returns after the user changes it. A smaller interim wave is not completion;
+  continue replacements until the hard target is reached or the server proves
+  queue exhaustion.
+- Prove access to genuine applicant fields before counting a job as accessible.
+- Show the exact jobs and require them to be approved before any form mutation.
+  Approval to inspect or probe is not approval to fill.
+- After job approval, inventory and fill every known value before producing one
+  grouped question packet containing only true gaps.
+- Resolve education, employment, confirmed EEO, authorization, resume, and
+  supported writing from the current Trackly profile and evidence. Never infer
+  a restricted or jurisdiction-specific fact.
+- Run Humanizer for every supported employer-specific draft when that skill is
+  available. Always run the self-contained writing gate as the fallback and
+  final authority.
+- Never activate Submit. The user owns the final submission action.
+- Preserve every review-ready tab and unsaved draft across turns, handoffs, and
+  restarts.
+- Reconcile positive submission evidence before changing Trackly state. Close a
+  completed tab only after durable `submitted` plus `applied_confirmed` proof and
+  the saved cleanup policy.
+
+## Execution mode decision
+
+| User intent | Mode | Required behavior |
+|---|---|---|
+| Fill or apply to the next N accessible jobs | `complete_next_n_accessible` | Recover the active execution first; retain the latest explicit target; replace typed blockers until target or exhaustion. |
+| Inspect the next N queue records | Fixed inspection | Freeze exactly N records; do not replace or replenish them. |
+| Continue after tab, app, or context loss | Active recovery | Restore exact server lineage, tab state, and mutation authority as three independent receipts. |
+| Reconcile work the user already submitted | Terminal reconciliation | Record current-epoch positive evidence before outcomes; do not reopen or refill forms. |
+
+Never use the fixed-batch approval endpoint for an accessible execution. Use the
+execution-scoped resume approval required by the current protocol. Never create
+a replacement run for a member that already has one or for a queued member whose
+run start conflicts; preserve it and report the typed control-plane conflict.
+
+## Two approval gates
+
+1. **Job approval:** after non-mutating access probes prove the exact accessible
+   set, show company, role, requisition identity when available, and any shortfall
+   from the hard target. No application control may be changed before approval.
+2. **Answer approval:** after approval, fill all deterministic controls first.
+   Ask once for only `missing_fact`, `live_consent`, or user-resolvable
+   `forbidden_inference` items that are visible now. A final truthfulness
+   certification remains per run.
+
+## Phase receipts
+
+Keep these receipts local and value-free. Never include labels, answers, names,
+emails, phone numbers, URLs, resume paths, demographics, or free-text content.
+Before claiming a phase complete, resolve `<skill-dir>` as the directory that
+contains the loaded `SKILL.md`, then run from any working directory:
+
+```text
+node "<skill-dir>/scripts/validate-phase-checkpoint.js" <phase>
+```
+
+Pass `{"receipt": {...}, "expectedContext": {...}}` on standard input. The
+envelope permits those fields plus `priorFill` only for Review. `expectedContext` is required for every
+phase. Build Trackly lineage, profile, lifecycle, and approval fields only from
+the current authoritative work receipt. Build browser-surface fields such as
+`formInventoryFingerprint`, `resumeControl`, and browser handoff evidence only
+from the independently captured, value-free current browser baseline; never
+present those fields as backend-returned facts. For selection, include
+`workMode`, the authoritative `latestExplicitTarget`,
+`batchId`, `queueExhausted`, and `selectableJobIds`: the access-proven job IDs
+for an accessible execution or exact frozen member job IDs for a fixed
+inspection. Include `executionId` only for an accessible execution. For access,
+include the
+exact current `waveJobIds`, including typed blockers. For later phases, include
+the exact `approvedJobIds` from the validated selection or authoritative
+recovered approval receipt. A nonzero exit means the
+phase is not complete. The script accepts `selection`, `access`, `fill`,
+`review`, `handoff`, and `reconciliation`. `handoff` is a reporting receipt,
+not authority to claim review readiness; it exists so visibility-unverified
+work can be represented without pretending that it is visible.
+
+### Selection
+
+Required fields:
+
+- `workMode`: `accessible_execution` or `fixed_inspection`;
+- positive safe-integer `batchId`, plus positive safe-integer `executionId` only
+  for an accessible execution;
+- `latestExplicitTarget`: integer 1-20 for an accessible execution, or 1-100
+  for a fixed inspection, matching the public batch-size contract;
+- `approvedJobIds`: unique positive safe-integer Trackly job IDs for the exact
+  approved set. This may be
+  empty only when the accessible queue is exhausted;
+- `approvalRecorded: true`;
+- `noFormMutationBeforeApproval: true`; and
+- `queueExhausted`: boolean. A non-empty set smaller than the target is a valid
+  interim wave; only an empty set requires this to be true.
+
+Every selection field must match `expectedContext`, and every approved job ID
+must belong to `expectedContext.selectableJobIds`. The user's approval may
+authorize a subset, but it can never introduce a job or shrink the hard target.
+
+### Access
+
+Required fields:
+
+- the same mode-specific current work lineage used by Fill: `workMode`,
+  `batchId`, `memberId`, `jobId`, `runId`, and non-negative `inspectionEpoch`,
+  plus `executionId` only for `accessible_execution`; every value must match
+  the current `expectedContext`, and `jobId` must belong to its exact
+  `waveJobIds` set. This set includes terminal blockers so their required probe
+  receipts can validate before replacement scheduling;
+- a terminal classification supported by the active durable disposition
+  contract. Under contract 3.7.3, locally observed `applicant_fields_reached`
+  uses durable `accessible`, while a locally observed `inactive` posting uses
+  conservative `unknown_unobservable`; never put either unsupported local state
+  name in the receipt or claim Trackly stored it;
+- `exactRequisitionVerified`, `originPolicyVerified`, and
+  `nonMutatingProbe` all true;
+- `privateDataEntered: false`; and
+- `applicantControlsObserved: true` only for durable `accessible` and
+  `captcha_at_submit`.
+
+### Fill
+
+Required fields:
+
+- `workMode`: `accessible_execution` or `fixed_inspection`;
+- positive safe-integer `batchId`, `memberId`, `jobId`, and `runId`, plus a
+  non-negative safe-integer `inspectionEpoch`; every value must equal the same
+  field in `expectedContext`, and `jobId` must belong to
+  `expectedContext.approvedJobIds`;
+- positive safe-integer `executionId` for `accessible_execution`, matching
+  `expectedContext`; omit it from both objects for `fixed_inspection`;
+- bind the receipt to the independently captured form/profile baseline: the
+  same `profileRevision` must appear in both the receipt and `expectedContext`;
+  it is a non-negative safe integer for
+  `fixed_inspection` (so revision `0` is valid) and a positive safe integer for
+  `accessible_execution`; canonical education and employment-position counts
+  are non-negative safe integers; also include the exact value-free
+  `formInventoryFingerprint` and `resumeControl` (`required`, `optional`, or
+  `absent`);
+- `visibleControlCount` is a safe integer of at least 1;
+  `committedControlCount` and `typedExceptionCount` are non-negative safe
+  integers, and committed plus exceptions equals visible;
+- `controlAccounting`: one count for each allowed disposition
+  (`filledExactProfile`, `filledSafeDerivation`, `filledSupportedDraft`,
+  `preservedUserEdit`, `missingFact`, `liveConsent`,
+  `authenticationBlocker`, `unobservableCommit`, `unsupportedControl`, and
+  `notApplicable`). These counts must independently reconcile to the three
+  aggregate counts above;
+- `formInventoryFingerprint`: a lowercase SHA-256 over only the ordered,
+  value-free semantic control fingerprints and their dispositions. Never hash
+  labels, values, page text, URLs, or local paths into it;
+- `knownOmissionCount: 0`;
+- `knownFieldsFilledBeforeQuestions: true`;
+- `answerLookupCompleted: true`, plus typed counts in
+  `answerLookupScopeCounts` for `run`, `question`, `office`, `jurisdiction`,
+  `company`, `provider`, and `global`, and a value-free
+  `answerLookupFingerprint`. Query every applicable scope before asking;
+- `parserSensitiveFieldsRechecked: true`;
+- `educationAndEmploymentVerified: true`;
+- `historyReconciliation`: canonical and accounted education-record counts,
+  using `canonicalEducationRecordCount` and
+  `accountedEducationRecordCount`; canonical and accounted employment-position
+  counts using `canonicalEmploymentPositionCount` and
+  `accountedEmploymentPositionCount`; reverse-chronological order proofs,
+  `datePrecisionInvented: false`, and value-free reconciliation fingerprints.
+  Positions, including promotions at one employer, are records; an employer
+  summary is not a position-level reconciliation;
+- `resumeAudit`: `control` is `required`, `optional`, or `absent`, and `mode` is
+  `automated_verified`, `manual_unbound`, or `not_applicable`. An absent control
+  requires `mode: not_applicable` and `not_applicable` for every stage. A
+  required or optional automated upload requires `mode: automated_verified`
+  and `passed` for every stage. Use `mode: manual_unbound` only when the user
+  genuinely performs a browser-local upload that remains unbound; require
+  `approval: passed`, `preAttachVerification: not_applicable`,
+  `attachmentCommit: user_confirmed`, and `passed` for
+  `filenameVerification`, `parserRecheck`, and `finalSweep`. Never use the
+  manual mode for an agent-performed upload or a failed verifier;
+- `writingPresent`: boolean;
+- `localWritingGate`: `passed` when writing is present, otherwise
+  `not_applicable`;
+- `humanizerAvailability`: `available`, `unavailable`, or `not_applicable`;
+- `humanizerRan: true` when Humanizer is available;
+- `humanizerFallbackUsed: true` only when writing is present and Humanizer is
+  unavailable. This names the fallback path; `localWritingGate` is the
+  always-run final authority; and
+- `questionPacketTrueGapsOnly: true`.
+
+The fill receipt fails when any known visible control lacks either a committed
+receipt or a typed exception.
+
+### Review
+
+Required fields:
+
+- the same mode-specific lineage as Fill: `workMode`, `batchId`, `memberId`,
+  `jobId`, `runId`, and non-negative `inspectionEpoch`, plus `executionId` only
+  for `accessible_execution`; every value must match the current
+  `expectedContext`, and `jobId` must remain in its approved set;
+- the same positive `profileRevision` for `accessible_execution`, or non-negative
+  `profileRevision` for `fixed_inspection`, and lowercase SHA-256
+  `formInventoryFingerprint` from the final validated Fill receipt; both must
+  match the current `expectedContext`, so a profile change or form rerender
+  requires Fill to be validated again before review;
+- a `priorFill` object containing only the complete value-free Fill `receipt`
+  and its `expectedContext`; Review reruns Fill validation and derives its
+  lineage, profile revision, and form inventory baseline from that receipt, so
+  matching caller-authored Review values alone cannot satisfy the gate. This
+  final Fill receipt must report zero `missingFact`, `liveConsent`,
+  `authenticationBlocker`, `unobservableCommit`, and `unsupportedControl`
+  dispositions; `notApplicable` controls may remain accounted. Resolve true
+  gaps and live decisions in the browser before producing this final receipt;
+- `finalIntegrityPassed`, `truthConfirmationRecorded`,
+  `reviewTabPreserved`, and `userVisibleHandoffProven` all true. Bind the
+  receipt and authoritative `expectedContext` to the exact visible tab with
+  lowercase SHA-256 `browserBindingHash` and `handoffEvidenceFingerprint`, plus
+  `handoffEvidenceType` set to `visible_presentation_receipt` or
+  `user_visible_handoff_receipt`. Durable or inventory-only evidence is not
+  sufficient for the manual-submit Review gate. A bare truth
+  boolean is insufficient: bind `truthCertificationAttestationId`,
+  `truthCertificationDependencyHash`, `truthCertificationExpiresAt`, and
+  `truthCertificationRunSetHash`, and `truthCertificationStatus` (`recorded` or
+  `replayed`) in both the receipt and
+  authoritative `expectedContext` to the value-free backend certification
+  result. The certification expiry must still be later than local validation
+  time. Preserve the accepted value-free `truthCertificationMemberRuns`,
+  bind that exact member-run list into `expectedContext`, recompute the backend's
+  canonical run-set hash, and prove the current member, run, checkpoint version,
+  and inspection epoch occur exactly once in that certified subset. A receipt
+  must never replace or extend the authoritative certified member-run list; and
+- bind `checkpointAction: review/manual_submit` and
+  `continuationAllowed: false` in both the receipt and `expectedContext` to the
+  exact backend-accepted action result; a
+  non-negative `resolvedActionCount`, and a value-free
+  `resolvedActionIdsFingerprint`. Both fields must match the authoritative
+  `expectedContext`; do not include raw action IDs;
+- bind the receipt and `expectedContext` to the exact backend result:
+  `checkpointStatus` (`recorded` or `replayed`), positive
+  `checkpointMemberVersion`, non-negative `checkpointInspectionEpoch`,
+  `checkpointLifecycle: review_ready`, `checkpointActionCount: 1`, and
+  `checkpointActionIdsFingerprint`. Newly recorded checkpoint actions and
+  previously open actions resolved by the review are separate sets, so each
+  summary binds independently to `expectedContext` rather than being forced to
+  equal the other. The single checkpoint action must be
+  `checkpointAction: review/manual_submit`. `checkpointInspectionEpoch` must equal the receipt's current
+  `inspectionEpoch`. A rejected or malformed checkpoint
+  fails closed: refetch the current contract once, correct the payload only when
+  the current schema proves how, and never claim durable review readiness until
+  the backend accepts it; and
+- `submitActivated: false`.
+
+### Handoff state report
+
+Use this receipt whenever reporting or transferring work, including when the
+review tab cannot be proven visible. Report `employerApplicationState`,
+`tracklyMemberState`, `tracklyJobState`, and `browserTabState` independently.
+Set `handoffVisibility` to `verified` only for a visibly proven or exact
+durably handed-off tab. Otherwise use `unverified` and
+`reviewReadyClaimed: false`. When readiness is false, omit all checkpoint
+authority fields. A state in one system never implies a state in
+another, and a valid unverified handoff receipt never authorizes telling the
+user to submit. `browserTabState: durable_handoff_proven` is invalid with
+unverified visibility and requires a `durable_handoff_receipt`. A true
+`reviewReadyClaimed` requires `checkpointStatus`,
+`checkpointMemberVersion`, `checkpointInspectionEpoch`, and
+`checkpointLifecycle`, plus `checkpointAction: review/manual_submit` and
+`checkpointActionCount: 1`; the checkpoint epoch must equal the receipt's current
+`inspectionEpoch`. The reported `employerApplicationState`,
+`tracklyMemberState`, and `tracklyJobState` must match the current authoritative
+`expectedContext` for every handoff, even when readiness is not claimed. The
+checkpoint fields must also match when readiness is claimed. A true handoff is
+valid only in the `awaiting_manual_submit` member state produced after the
+certified review-ready outcome is recorded; the earlier durable `review_ready`
+checkpoint state is not yet a user handoff. The current job state must still
+be `check_later`; a revoked,
+already-applied, or unknown job cannot be handed off as review-ready. A verified
+handoff must bind the receipt and `expectedContext` to
+the exact `browserBindingHash`, a value-free `handoffEvidenceFingerprint`, and
+`handoffEvidenceType`. A visible tab requires either
+`visible_presentation_receipt` from the adapter's exact-tab focus/reveal action
+and verified visible state, or `user_visible_handoff_receipt` from an exact
+current tab-bound user-visible handoff. Inventory membership alone is never
+visibility proof. A durably handed-off tab requires
+`durable_handoff_receipt`. Omit those evidence fields when visibility is
+unverified.
+
+### Reconciliation
+
+Required fields:
+
+- the same mode-specific current work lineage and approved-job binding required
+  by Review. Reconciliation stays bound to the submitted run even though it is
+  a post-submission phase;
+- bind the receipt and `expectedContext` to the freshly refetched backend
+  result: `positiveSubmissionEvidenceRecorded: true`,
+  `memberLifecycle: submitted`, and `tracklyJobStatus: applied_confirmed`.
+  Self-authored terminal values are not authority; if the backend still reports
+  any nonterminal state, reconciliation and cleanup fail closed;
+- `cleanupPreference`: `never`, `submitted_only`, or
+  `submitted_and_probe_blockers`;
+- `browserTabStatus`: `open`, `missing`, `closure_unverified`, or
+  `closed_verified`; `missing` records a durable missing-tab observation but is
+  not closure proof; and
+- for `closed_verified`, `completeTabInventoryRecorded`,
+  `closeReceiptRecorded`, and `postCloseUnionAbsenceProven` true.
+
+`cleanupPreference: never` forbids `closed_verified`, even when closure evidence
+exists, because evidence cannot override the user's saved no-close policy.
+For `open`, `missing`, or `closure_unverified`, all three close-proof fields must
+be false or omitted.
+
+Every final report must state the application lifecycle, Trackly job status,
+browser tab status, and whether absence is actually `closed_verified`. These
+are separate facts and none implies another.

package/skills/trackly-apply/references/performance-telemetry.md

@@ -0,0 +1,61 @@
+# Performance and value-free telemetry
+
+Improve speed only by reusing structure and batching requests. Never weaken
+identity, consent, committed-control, preservation, or Submit-boundary gates.
+
+## Value-free schema cache
+
+Cache only normalized control fingerprints, allowlisted opaque semantic-label
+codes, control types, requiredness, conditional dependencies,
+provider/tenant/template identity, interaction strategy, commit-verification
+strategy, parser/rerender risk flags, and cache version/expiry.
+
+Never cache raw semantic-label text, raw answers, contact values, demographic
+values, resume text or paths, credentials, URLs, employer-form free text, or
+any label code outside the allowlist.
+
+Invalidate on a profile revision, form schema fingerprint, inspection epoch,
+meaningful wording change, provider/tenant mismatch, or cache expiry. A cache hit
+skips structural rediscovery only; reread and verify every committed live value.
+
+## Batch resolver and template grouping
+
+- Fetch the current profile once per stable revision and request only keys
+  required by visible forms.
+- Resolve a shared question once only when scope, expected type, employer,
+  office, jurisdiction, and wording semantics all match.
+- Group same-tenant forms with identical normalized control fingerprints into
+  one structural fill plan.
+- Apply that plan independently to every exact run and tab. Keep requisition
+  identity, provenance, committed-value verification, and browser bindings
+  separate.
+- Deduplicate missing questions, not committed-control receipts.
+- Preserve bounded bulk dispositions, observations, checkpoints, and outcomes.
+  After a bulk 5xx, refetch before deciding whether to retry or split.
+
+## Events
+
+Emit these only when the current protocol or analytics surface explicitly
+supports them:
+
+- `apply_probe_stage_reached`
+- `apply_access_disposition_committed`
+- `apply_member_run_start_conflict`
+- `apply_form_schema_cache_hit`
+- `apply_form_schema_cache_miss`
+- `apply_profile_resolution_completed`
+- `apply_known_field_omitted`
+- `apply_control_commit_corrected`
+- `apply_resume_parser_repair`
+- `apply_question_packet_generated`
+- `apply_free_text_humanized`
+- `apply_handoff_receipt_committed`
+- `apply_submission_evidence_committed`
+- `apply_outcome_reconciled`
+- `apply_tab_closed_verified`
+
+Use only provider/support level, scenario code, opaque execution/member/run IDs,
+inspection epoch/version, cache hit or miss, phase elapsed time, typed error code,
+and counts by resolver class. Never include raw labels, answers, URLs, names,
+emails, phone numbers, resume paths, demographics, or free-text content. Never
+invent an event or field that the active protocol does not expose.

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

@@ -20,6 +20,27 @@ Use the compact execution snapshot as authority. Give a bounded next-update esti
 Every handoff names the browser surface and authoritative funnel. Use the
 matching template; do not improvise internal routing language.
 
+Every operator update also reports three independent state lines:
+
+```text
+Employer application state: not opened / access probed / form reached / partially filled / needs answers / review state prepared / manually submitted / ATS success observed / blocked
+Trackly state: execution + batch + member lifecycle + job state + inspection epoch + profile revision + resume/truth/submission receipts
+Browser state: no known tab / controller-owned / user inventory / visible / durable handoff proven / missing / closure unverified / closed verified
+```
+
+No state in one system implies a state in another. In particular, a Trackly
+`review_ready` member does not prove the employer draft is visible, and a
+visible form does not prove a durable checkpoint. When visibility is
+unverified, say so, preserve the exact binding, and do not claim a review-ready
+handoff or tell the user to submit.
+
+A verified handoff receipt must carry the exact browser-binding hash, a
+value-free evidence fingerprint, and whether the proof came from the adapter's
+exact-tab presentation action, an exact tab-bound user-visible handoff receipt,
+or a durable handoff receipt. A complete tab inventory proves reachability, not
+visibility. Bind those same fields into the validator's expected context; never
+substitute a self-asserted visibility boolean.
+
 ### Recovery
 
 ```text