trackly-cli 0.7.3 → 0.8.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,93 @@
1
+ # Browser lifecycle and recovery
2
+
3
+ Keep business identity in Trackly and host-specific browser identity local.
4
+ Every live tab belongs to exactly one frozen job and existing application run.
5
+ Never infer identity from window position, a transient tab number, or title text
6
+ alone.
7
+
8
+ ## Local tab ledger
9
+
10
+ Maintain a local job ID -> run ID -> tab record containing the raw tab
11
+ identifiers, browser surface, normalized requisition URL, binding hash,
12
+ ownership state, and inspection epoch. Raw tab identifiers never go to the
13
+ Trackly backend. If the host persists the ledger, store it in a private
14
+ mode `0600` file and remove it when the batch expires.
15
+
16
+ Backend observations contain only a value-free binding hash, inspection epoch,
17
+ ownership state, lifecycle/action codes, and timestamps. Never send the URL,
18
+ tab title, employer, role, page text, credentials, or answer values as browser
19
+ metadata.
20
+
21
+ ## Reconciliation
22
+
23
+ Before resuming, handing off, or closing a tab:
24
+
25
+ 1. Request every complete controller-owned inventory the host can enumerate.
26
+ 2. Request every complete user-owned inventory the host can enumerate.
27
+ 3. Normalize and reconcile their union against the local ledger.
28
+ 4. Treat an inventory as authoritative only when the adapter explicitly says
29
+ it is complete. Omission from an incomplete or single-surface inventory is
30
+ not proof that a tab is gone.
31
+ 5. Reclaim a matching tab only after employer, role, requisition, HTTPS origin,
32
+ ATS tenant when applicable, run ID, and browser binding all revalidate.
33
+
34
+ For every initial tab and every recovery, call `trackly_bind_apply_surface`
35
+ with the existing frozen member and run. Use `initial_binding` for the first
36
+ surface and `recovery_binding` after a missing tab or handoff. The returned URL
37
+ is the only URL recovery may open. Treat its returned member version and
38
+ inspection epoch as authoritative; do not reuse evidence from the prior epoch.
39
+
40
+ The Sola failure mode is the regression model: a handed-off tab can disappear
41
+ from the controller inventory while remaining visible in the user inventory.
42
+ Never make a closure claim from one inventory surface.
43
+
44
+ ## Close proof
45
+
46
+ `closed_verified` requires all of the following for the current inspection
47
+ epoch:
48
+
49
+ - the adapter declares both available controller and user inventories complete;
50
+ - the exact bound tab receives an explicit close receipt; and
51
+ - the tab is absent from the complete post-close union.
52
+
53
+ Record these facts separately with `trackly_record_apply_surface_evidence`:
54
+ `surface_inventory_reconciled`, `surface_close_receipt`, and
55
+ `surface_post_close_absent`. A post-close absence event is invalid unless it
56
+ explicitly covers the complete controller+user union. The backend, not the
57
+ agent's prose, derives `closed_verified` from all three current-epoch facts.
58
+
59
+ If the close request succeeds but a complete union is unavailable or still
60
+ contains the tab, the agent must not claim `closed_verified`; record
61
+ `closure_unverified`. If no mapped tab is found before a verified close,
62
+ record `missing`. Close evidence from an earlier inspection epoch cannot
63
+ satisfy the current closure gate.
64
+
65
+ Do not close a review-ready tab merely to reduce clutter. Preserve it for the
66
+ user's manual Submit unless the user closes it or explicitly asks the agent to
67
+ close it.
68
+
69
+ ## Missing-tab recovery
70
+
71
+ When an incomplete member's tab is missing:
72
+
73
+ 1. Preserve the frozen member and reuse the existing run. Never create a
74
+ replacement run for browser recovery.
75
+ 2. Call `trackly_bind_apply_surface` with `recovery_binding`; reopen only its
76
+ exact backend-stored requisition URL. Do not use search,
77
+ company careers navigation, redirects remembered from chat, or an invented
78
+ URL.
79
+ 3. Revalidate HTTPS origin, ATS tenant policy, employer, role, requisition, and
80
+ job identity before entering private data.
81
+ 4. Increment the browser inspection epoch and bind the recovered tab. Evidence
82
+ from an earlier inspection epoch cannot satisfy the current review gate.
83
+ 5. Reinventory the whole form. Do not claim that unsaved ATS draft state
84
+ survived a crash, user close, or handoff.
85
+ 6. Refill only verified canonical answers and rerun every applicable integrity
86
+ gate. If the page shows a changed success URL or submission state,
87
+ revalidate the exact requisition before recording any outcome and never
88
+ activate Submit again.
89
+
90
+ If the recovered origin or identity differs, semantic controls are
91
+ unobservable, or access is blocked by credentials or a pre-form challenge,
92
+ stop private-data mutation and create the appropriate human action. Continue
93
+ the other frozen batch members.
@@ -1,6 +1,6 @@
1
1
  # Review handoff
2
2
 
3
- Provide this compact block and stop:
3
+ For one application, provide this compact block and stop:
4
4
 
5
5
  ```text
6
6
  Ready for your review — not submitted
@@ -26,4 +26,55 @@ Items requiring your attention:
26
26
  Please review the live form and click Submit manually.
27
27
  ```
28
28
 
29
- Do not include restricted answers in chat unless needed for the user’s review. Never include an OTP or CAPTCHA response.
29
+ For a frozen batch, first summarize unresolved human actions, then provide one
30
+ review block per run that reached `review_ready`. Continue processing other
31
+ members before presenting the first-pass handoff.
32
+
33
+ ## Grouped actions
34
+
35
+ Group recoverable actions in this order:
36
+
37
+ 1. company;
38
+ 2. role;
39
+ 3. run;
40
+ 4. action type.
41
+
42
+ Show the stage and what the user must do, without copying raw form questions or
43
+ private values into Trackly observations. Separate credentials, legal choices,
44
+ artifacts, and unknown reusable answers. Later handoffs contain only newly
45
+ revealed conditional deltas.
46
+
47
+ ## Batch review table
48
+
49
+ Include one row per frozen member:
50
+
51
+ ```text
52
+ Job ID | Run ID | Browser label | ATS | State | Human actions | Evidence
53
+ ```
54
+
55
+ The browser label may help the user find a visible tab, but raw tab identifiers
56
+ stay local and out of Trackly. For each review-ready run, include its current
57
+ inspection epoch, resume-content approval status, per-run attachment proof,
58
+ truth certification status, required scenario coverage, and integrity result.
59
+ Submission evidence and closure evidence remain separate and are normally
60
+ empty until after the user's manual Submit.
61
+
62
+ After the user submits, record one typed `user_confirmation` only when the user
63
+ explicitly says they submitted. Prefer a current-epoch `success_page` proof when
64
+ the controlled browser visibly shows success. Record a provider receipt only
65
+ from the application surface itself; never search email or a mailbox. Hash the
66
+ proof locally and never send confirmation text, page text, receipt identifiers,
67
+ or URLs as evidence.
68
+
69
+ Do not claim the batch is ready until every frozen member is either
70
+ `review_ready`, has an explicit resumable human action, is user-revoked, or has
71
+ a terminal trust/observability blocker.
72
+
73
+ Do not make ready siblings wait for an unresolved member. Hand off every
74
+ truth-certified `review_ready` subset as soon as it is durable, keep its tabs
75
+ open for manual submission, and list remaining human actions separately.
76
+ Members that become ready later require a new certification for the exact
77
+ then-current `review_ready` subset.
78
+
79
+ Do not include restricted answers in chat unless needed for the user’s review.
80
+ Never include credentials, an OTP, or a CAPTCHA response.