ilml-plugin-linkedin 1.9.0 → 1.11.0

package/CHANGELOG.md

@@ -1,5 +1,16 @@
 # Changelog
 
+## 1.11.0
+- **`sync-all` no longer gives up when a single thread misbehaves.** LinkedIn's inbox occasionally reacts to an automated search input by navigating the page away from `/messaging/` mid-sync. In v1.10.0 that single navigation killed the entire remaining queue — the run would abort on, say, item 1 of 67 and silently leave 66 unread. The thread loop now treats both thrown exceptions and verified-false returns the same way: log it, hand the thread to the sidebar fallback below, and keep moving. A bad thread costs that one slot, not the whole sync.
+- **`sync-all` now reaches conversations buried deep in the inbox.** LinkedIn only renders ~20 sidebar cards at a time and lazy-loads the rest on scroll. Older threads — including any conversation that hadn't received a recent message — sat outside that initial window, so the existing "click the card in the sidebar" path couldn't find them. When that fails, the sync now navigates back to `/messaging/`, scrolls the sidebar from the top, and reopens the thread once its card has been loaded. The happy path (top-of-inbox conversations found by direct click) is unchanged — only previously-failing threads pay the extra scrolling time.
+- No schema migration; existing data files unchanged.
+
+## 1.10.0
+- **`sync-all` no longer crashes mid-run when the LinkedIn browser session freezes.** On a large inbox (2000+ conversations, 600+ threads to re-read), the browser tab would occasionally stall after an hour of scrolling and reading. A single stall used to abort the whole sync and lose the rest of the progress for that run — the user had to re-launch from scratch, often multiple times before any single run completed. The same auto-recovery that already protects `apply` (since v1.4.0) is now applied to `sync-all`: when the browser stalls, the script switches to a fresh tab and continues. In the inbox-scan phase that means restarting the scan from the top (up to 3 retries). In the thread-reading phase it means skipping that one problem thread (it'll be re-flagged on the next sync — nothing is lost) and continuing with the next. The `--backfill` mode (re-reads conversations stored with empty message lists) is covered by the same recovery. On large catch-up runs this is the difference between "finishes in one pass" vs. "needs 5-10 manual restarts."
+- **Session summary** reports the recovery count when it actually happened. Healthy runs print nothing new.
+- Documentation: clarified the plugin's data-ownership intent and added a usage advisory pointing to LinkedIn's terms.
+- No schema migration; nothing on disk changed.
+
 ## 1.9.0
 - **Apply phase no longer quits early after a CDP recovery.** v1.4.0 made the runner survive a dead Puppeteer↔Chrome channel, but `iterateAllPages` still exited the moment any pass produced 0 new submits — and a freshly recovered page often returns an empty job list on the very next scrape (page state hasn't fully restored). So a single CDP death anywhere in the pass would end the apply phase well before the daily quota was filled, even though there were plenty more jobs to apply to. The pass-exit check now also tracks how many CDP recoveries happened during the pass: if there were any and submits = 0, the next pass runs regardless (still bounded by `MAX_PASSES = 3`). Net effect: a recovery costs at most one stalled scrape, not the entire remaining daily allowance. Re-applying to the same job after recovery is already safe — the existing "Applied N ago" badge check at the start of `processJob` skips it cleanly without re-clicking Apply.
 - No schema migration. Pass-bookkeeping is in-process state; nothing on disk changed. `CURRENT_SCHEMA_VERSION` unchanged.
@@ -73,7 +84,7 @@
   - Cleaner top — removed the metadata bullet list (npm/tracker/license) that was the very first thing visitors saw on the npm page; now opens straight into "What it does"
   - Removed the entire `Developer Notes` section — it was internal-only and not useful for end users (release process and architecture notes live in `CLAUDE.md` and the SDK's plugin spec)
   - Clarified the `LINKEDIN_SEARCH_URL` instruction (no more raw URL parameters like `f_AL=true` — just "open LinkedIn → Jobs, set filters, copy URL")
-  - New **Author & contact** section with personal page, LinkedIn, and a **DigitalTwins.team** call-to-action for custom plugin development
+  - New maintainer section with a **DigitalTwins.team** call-to-action for custom plugin development
 - `CHANGELOG.md` is now shipped in the npm tarball (added to `package.json#files`), so the npm package page renders release notes next to the README
 - New **Feedback & support** section in the README pointing at a dedicated **Support** node in iLiveMyLife (`0000019dde81b04f-2e534bb8ebad0000`) — users can write directly to the maintainer via the in-graph messenger or `ilml send` from the terminal
 

package/README.md

@@ -1,20 +1,22 @@
-# Your LinkedIn — finally yours
+# Your LinkedIn data — finally on your machine
 
 LinkedIn keeps your **connections, conversations, and the notes you write about people** locked inside their interface. You can't export message threads. You can't query an AI on your own contact history. You can't run batch operations from a script. You can't keep a personal database of who said what when.
 
-This plugin pulls all of that onto your machine and into your [iLiveMyLife](https://ilivemylife.io) knowledge graph — where it's searchable, syncable, AI-queryable, and yours to keep forever. Even if you uninstall the plugin or switch ilml accounts, **your accumulated data stays where you put it**.
+This plugin pulls all of that onto your machine — into local JSON files that you fully own — and feeds derived signals (action plans, run reports, AI assistant context) into your [iLiveMyLife](https://ilivemylife.io) knowledge graph for AI-driven follow-up. Even if you uninstall the plugin or switch ilml accounts, **your accumulated data stays where you put it**.
 
-It also automates LinkedIn from the terminal — applying to jobs, drafting outreach, processing recruiter funnels — so you can script what LinkedIn's web UI makes you do one click at a time.
+Common LinkedIn workflows become scriptable: AI fills Easy Apply forms using context from your profile and notes, drafts message replies for your review before sending, and queues recruiter outreach under daily limits you configure.
+
+> **Note on intent and use.** This plugin demonstrates patterns for keeping a local mirror of your own LinkedIn data — syncing message history and connection metadata to JSON files on your machine — and for using AI to assist with form filling and message drafting on your behalf. It is published as a reference implementation for developers building plugins on top of the `ilml` SDK. Automated interaction with LinkedIn may conflict with their [User Agreement](https://www.linkedin.com/legal/user-agreement) — review it and run this at your own risk. Provided AS-IS; the author makes no warranty and accepts no liability for account actions, data loss, or other consequences resulting from use.
 
 ---
 
 ## What you get
 
-- **A full local mirror of your LinkedIn graph.** Connections, conversation threads, message history, profile metadata, your private notes about people — synced into your iLiveMyLife graph and a local database. Nothing stays trapped in linkedin.com.
+- **A full local mirror of your LinkedIn data.** Connections, conversation threads, message history, profile metadata, your private notes about people — stored in local JSON files you fully own; derived signals (action plans, AI context, run reports) flow into your iLiveMyLife graph for follow-up. Nothing stays trapped in linkedin.com.
 - **AI-assisted messaging — drafts go through you.** [Lifebot](https://ilivemylife.io) reads the full context of each thread (history, your notes, tags) and drafts replies in your voice. You review the batch in one pass and push approved drafts as a group. On push, the bot re-scans every thread first — if a new incoming message arrived since you reviewed, it pauses that draft and flags it for re-review instead of sending blind. Never autopilot.
 - **An auto-triaged inbox.** Every conversation gets classified (recruiter / hiring manager / founder / investor / spam / event), tagged, prioritized, and stamped with a suggested next action. `ilml linkedin today` prints a no-browser daily plan: who to reply to, what to do, in priority order — before you've even opened LinkedIn.
 - **Inbox sync that doesn't break your workflow.** By default `sync-all` pulls the conversation list and metadata without "opening" unread threads — LinkedIn keeps showing the unread badges until *you* read them in the UI. The sync report ends with a list of what's still unread so you can scan it from the terminal first. Use the bot as an analyst without losing your own attention markers. (Pass `--read-unread` if you want to vacuum unread threads into the local DB.)
-- **Terminal-first automation.** Batch operations — apply to dozens of jobs at once, draft 50 outreach messages then review them all in one pass, run a connection campaign on a schedule. Scriptable. Re-runnable. Logged.
+- **Terminal-first workflows.** Common tasks run as scripts you control — batched drafts you review before sending, queued applications under daily limits you set, scheduled runs that log everything. Repeatable and auditable.
 - **Easy Apply that actually thinks.** Auto-fills LinkedIn job applications, with Lifebot answering custom questions ("Why are you interested in this role?") in your voice using context from your graph — not boilerplate.
 - **Your data outlives the plugin.** The connection database, conversation history, and your notes live in a directory **you** choose (`DATA_DIR`). Plugin updates don't wipe them. Logging out of ilml doesn't wipe them. Uninstalling the plugin doesn't wipe them. Only **you** decide when they go.
 
@@ -270,7 +272,7 @@ Between step 1 and step 2: **do not run any `ilml linkedin` command.** The curre
 | `~/.ilivemylife/plugins/linkedin/` | Plugin code | yes (re-extracted) | no |
 | `<scope>/.ilivemylife/plugins-state/linkedin.json` | Your configured values (LINKEDIN_NAME, node IDs, etc.) | no | yes (with that scope) |
 | `<scope>/.ilivemylife/plugins-state/linkedin/cookies.json` | LinkedIn session cookies | no | yes (with that scope) |
-| Directory you set as `DATA_DIR` | Local DBs, scraped profiles, message history, your notes | **no** | **no** |
+| Directory you set as `DATA_DIR` | Local DBs, synced profile metadata, message history, your notes | **no** | **no** |
 
 If you didn't set `DATA_DIR`, runtime data files default to inside the plugin's install dir — meaning a plugin reinstall **wipes them**. Setting `DATA_DIR` to a sibling folder like `~/linkedin-plugin-data/` is **strongly recommended**:
 
@@ -310,13 +312,15 @@ Bug reports, feature requests, and general questions land in the plugin's **Supp
 
 ---
 
-## Author & contact
-
-**[Ilya Sorokin](https://www.digitaltwins.team/team/ilya-sorokin)** — creator of [iLiveMyLife.io](https://ilivemylife.io) and this plugin.
+## Maintained by
 
-- LinkedIn: [linkedin.com/in/ilyasorokin](https://www.linkedin.com/in/ilyasorokin/)
-- Email: info@ilivemylife.io
+[**DigitalTwins.team**](https://www.digitaltwins.team/) — independent
+consultancy that builds and maintains `ilml` plugins, automation tools,
+and bespoke integrations. This plugin is one of several reference
+implementations published as part of that work.
 
-### Need a custom plugin or extension?
+For commercial integrations, custom plugin development, or contract
+engineering inquiries → **info@DigitalTwins.team**.
 
-[**DigitalTwins.team**](https://www.digitaltwins.team/) — my consulting company — designs and builds custom automation, SDK extensions, and bespoke plugins for the iLiveMyLife ecosystem (and beyond). If you want to integrate your own workflow with iLiveMyLife, extend this plugin's behavior, or commission something new, get in touch.
+For bug reports or plugin questions, use the in-graph Support node
+linked above.