@hraness/ghostget 0.17.6 → 0.18.2

package/skills/ghostget/references/linkedin-adapter.md

@@ -232,23 +232,55 @@ relationship on that vanity from the profile page. Current LinkedIn pages are
 SDUI/RSC and often omit classic `bpr-guid-*` Profile embeds. The binder
 therefore walks both those Voyager code payloads and `window.__como_rehydration__`.
 Current pages assign that global as either a JSON object (`= { … }`) or an RSC
-flight array (`= [ "1:I[…]\\n2:{…}" ]`). The binder accepts both, decodes
-flight rows that carry JSON objects or arrays, and treats
+flight array (`= [ "1:I[…]\\n2:{…}" ]`). Some current arrays also carry a
+non-flight SDUI string slot (not `1:…` rows) that still contains
+`networkDistance` and `vieweeMemberUrn`. The binder accepts both assignment
+shapes, decodes flight rows that carry JSON objects, arrays, or JSON strings,
+feeds non-flight string slots through the same bootstrap decoder, and treats
 `memberDistance`, `networkDistance`, or `distance` of `DISTANCE_1`,
 `1`, or `"1"` as first-degree when that value is joined to the requested vanity
-or its profile URN (`entityUrn`, `objectUrn`, `profileUrn`, or `vieweeMemberUrn`).
-Empty, missing, or import-only bootstrap stays fail-closed.
+or its profile URN (`entityUrn`, `objectUrn`, `profileUrn`, `vieweeMemberUrn`,
+or `vieweeProfileId` plus vanity). Current Como trees can nest around depth 60,
+so the walk keeps a node ceiling and a depth ceiling of 128 instead of aborting
+at depth 32. Distance may appear on PROFILE_VIEW breadcrumb or RSC string rows,
+including multi-escaped Como fragments such as `networkDistance\":1` beside a
+`vieweeMemberUrn` or member id that is not the same `fsd_profile` URN bound
+from `vieweeProfileId`. A unique first-degree distance on that viewee join is
+accepted. Incidental viewer or other `fsd_profile` URNs
+in the same breadcrumb do not steal identity. Empty, missing, ambiguous, or
+contradictory distances stay fail-closed.
 
 When the same page already embeds Contact-info fields, including a labeled
 Email row, the operation projects those fields and does not issue a second
-fetch. Otherwise it GETs `/voyager/api/graphql` for
-`voyagerIdentityDashProfileContactInfo`, using a page-resolved `queryId` when
-the HTML contains exactly one decorated revision and `queryName` otherwise.
-Variables are exactly `(profileUrn:{urn})`. Classic
-`/voyager/api/identity/profiles/{vanity}/profileContactInfo` now returns HTTP
-410 and is rejected. The executable contract is that reviewed first-party GET
-or the page-embedded fields, not a caller-selected RSC body, DOM click, or
-selector. Ghostget does not message, connect, or InMail.
+fetch. Long SDUI strings used as field labels are skipped instead of aborting
+the profile-stage walk. Otherwise it first inspects the page's exact
+Contact-info NavigateToScreen action. A reviewed action still admits only
+the ProfileContactDetailsOverlay URL (`sduiid` equal to that overlay
+`screenId`). Adapter 1.36.2 then clicks the unique accessible name
+`Contact info` on the already-loaded 1st-degree profile and projects Email
+from that modal DOM, including when that control's `href` matches
+`/overlay/contact-info/` and contained Chrome follows that reviewed vanity
+overlay pathname after click. Malformed or unsupported action fields stop
+the operation. Zero or two-plus matching controls, a path other than the
+bound profile or `/in/:publicIdentifier/overlay/contact-info/`, or a
+missing or ambiguous dialog, fail closed. The contained path does not mint
+a synthetic navigation POST or track headers, and it does not fetch that
+overlay href as a navigation GET. Only when the
+action is absent
+does it use a page-resolved GraphQL `queryId` for
+`voyagerIdentityDashProfileContactInfo`, when the HTML contains exactly one
+decorated revision. Variables are exactly `(profileUrn:{urn})`. When that
+queryId is absent, or when the GraphQL GET returns a reviewed HTTP 403
+`text/html` rejection, the operation GETs the exact vanity
+`/in/:publicIdentifier/overlay/contact-info/` overlay with RSC browser
+binding. ScreenId-only and `profileUrn`-bound
+`/flagship-web/rsc-action/actions/navigation` overlay GET URLs stay rejected
+because live dormant sessions return HTTP 500 `application/octet-stream`.
+Classic `/voyager/api/identity/profiles/{vanity}/profileContactInfo` now
+returns HTTP 410 and is rejected. The executable contract is those reviewed
+first-party reads, the reviewed Contact info click and modal snapshot, or
+the page-embedded fields. It accepts no caller-selected RSC body, selector,
+or script. This contact read does not message, connect, or InMail.
 
 The projection returns `email` when LinkedIn shows it, plus any of the vanity
 profile link, connected-since date, phone numbers, websites, and birthday.
@@ -273,6 +305,184 @@ string still carried vanity-joined `networkDistance: 1` next to
 array form and still uses `queryName` when the page embeds no decorated
 queryId.
 
+A 2026-09-10 signed-in capture of another 1st-degree profile still bound
+`profiles.read` and still omitted classic `entityUrn` / `objectUrn` /
+`profileUrn` keys on vanity records. Those records carried `vanityName`,
+`vieweeProfileId`, and `isSelfView` instead, and the live Como tree reached
+about depth 59 with far fewer than the node ceiling. The depth-32 abort treated
+that page as contract-drift. After a deeper walk, identity still failed because
+the binder required a classic URN on the vanity record and required
+`networkDistance` on a decoded object. Adapter 1.24.0 joins `vieweeProfileId`
+plus vanity and reads breadcrumb or RSC string-row distance.
+
+A 2026-09-11 signed-in capture of another 1st-degree profile still bound
+`profiles.read` and still reached a unique `vieweeProfileId` profile URN after
+the 1.24.0 walk. `contacts.read` then failed closed because relationship
+distance sat on a PROFILE_VIEW breadcrumb next to `vieweeMemberUrn` / member
+ids, not on a vanity or `fsd_profile` record the binder treated as the same
+target. Adapter 1.25.0 joins that unique viewee distance, including when the
+breadcrumb also carries an incidental viewer URN, and still fails closed for
+self, non-first-degree, and contradictory distances.
+
+A later 2026-09-11 signed-in capture of another 1st-degree profile still bound
+`profiles.read` and still joined `vieweeProfileId` identity after the 1.25.0
+walk. `contacts.read` then failed closed because PROFILE_VIEW breadcrumbs kept
+`networkDistance` and `vieweeMemberUrn` in multi-escaped Como string rows
+(`networkDistance\":1`), so the walk produced no distance records for the
+viewee join. Adapter 1.26.0 peels those JSON string escapes and reads the
+escaped key/value form. Self, non-first-degree, and contradictory distances
+still fail closed.
+
+A later 2026-09-11 signed-in capture of another 1st-degree profile still bound
+`profiles.read` and still joined `vieweeProfileId` identity after the 1.26.0
+walk. `contacts.read` then failed closed because distance lived in Como
+rehydration array slot `[6]`, a ~25KB SDUI string with `networkDistance` and
+`vieweeMemberUrn`. That slot was not an RSC flight, so
+`decodeComoRehydrationValue` discarded it (`[]`) before the 1.26.0 peel.
+`decodeStringBootstrap` already recovered the distance record from the same
+string. Adapter 1.27.0 feeds non-flight Como string slots through that
+decoder and still routes true RSC flights through `decodeRscFlightRecords`.
+Self, non-first-degree, and contradictory distances still fail closed.
+
+A later signed-in capture of a known 1st-degree profile still bound
+identity, profile HTML, and distance, but Contact-info GraphQL returned
+HTTP 403 `text/html` and the page still omitted
+`voyagerIdentityDashProfileContactInfo.<32hex>`. The signed-in UI opens
+Contact info through `ProfileContactDetailsOverlay`, not GraphQL.
+Adapter 1.28.0 GETs that overlay with the bound `profileUrn` when queryId
+is absent or after that reviewed GraphQL rejection, and projects Email
+from the RSC or SDUI overlay payload. ScreenId-only overlay URLs stay
+rejected. Self, non-first-degree, and contradictory distances still fail
+closed.
+
+A later signed-in capture of the same 1st-degree path still bound
+identity and distance, but the 1.28.0 navigation GET returned HTTP 500
+`application/octet-stream` for screenId-only, `profileUrn`-bound, and
+html variants. `/in/:publicIdentifier/overlay/contact-info/` returned
+HTML 200 for the signed-in Contact-info modal. Long SDUI strings in
+profile HTML also aborted the best-effort embedded walk at profile
+stage and misreported as relationship-binding contract-drift. Adapter
+1.29.0 skips non-bounded field labels during that walk and GETs the
+exact vanity overlay path with RSC headers instead of the 500
+navigation route. GraphQL Contact-info remains a 403 `text/html` path
+when a unique queryId is present. Self, non-first-degree, and
+contradictory distances still fail closed.
+
+A later 2026-09-11 smoke of the same 1st-degree path after adapter 1.29.0
+still bound identity and distance, and the vanity overlay GET returned
+HTML 200. That body was the signed-in profile HTML shell (~500KB+): no
+projectable Email, no mailto, and no Contact-info JSON or RSC flight.
+GraphQL Contact-info stayed HTTP 403 `text/html` with `queryId=null`.
+The live Contact-info Email still appears only after the headed UI opens
+the modal. Dormant contained Chrome stays GET-only and cannot mint that
+client-filled payload. Adapter 1.30.0 treats an HTML-200 shell as
+omitted Contact-info fields after 1st-degree binding, still projects
+overlay HTML that carries Como Email, a unique mailto, or an RSC/SDUI
+flight, and keeps `/flagship-web/rsc-action/actions/navigation` overlay
+GETs rejected.
+
+A later headed signed-in capture of the same 1st-degree Contact-info
+click showed Email in the modal. The first network response that
+contained the Email label was POST
+`/flagship-web/rsc-action/actions/navigation?screenId=com.linkedin.sdui.flagshipnav.profile.ProfileContactDetailsOverlay&sduiid=com.linkedin.sdui.flagshipnav.profile.ProfileContactDetailsOverlay`
+with `Accept: */*`, `Content-Type: application/json`, no RSC or Next
+router headers, and JSON body keys `clientArguments` and `isModal`. The
+response was HTTP 200 `application/octet-stream` RSC flight. Headed
+capture bound `sduiid` to that same overlay `screenId` constant. Dormant
+profile HTML NavigateToScreen for Contact info carries `pageKey`
+`profile_view_base_contact_details` and `requestedArguments.payload`
+(`vanityName`, `givenName`, `familyName`, `isVanityNameResolved`) but
+omits `sduiid`. Adapter 1.31.0 POSTs the exact allowlisted URL after
+1st-degree bind, peels reviewed payload keys, and copies `$type` /
+`requestedStateKeys` / `requestMetadata` only when those reviewed fields
+are already on the action. It does not invent a stolen `sduiid`, `$type`,
+or `requestMetadata`. A different `sduiid` fails closed. GraphQL
+Contact-info stays a 403 `text/html` fallback. Navigation overlay GETs
+stay rejected. The vanity overlay GET remains HTML-shell honesty when
+the profile page omits that NavigateToScreen action. Soft-labels stay.
+Keep cookies, `li_at`, CSRF, `JSESSIONID`, live emails, and raw HARs out
+of Git.
+
+A later signed-in smoke after adapter 1.31.0 still bound 1st-degree
+distance and selected the navigation POST family, but live
+NavigateToScreen `requestedArguments` keeps `requestMetadata` a sibling
+of `payload` and uses `$type` values `proto.sdui.actions.requests.RequestedArguments`
+and `proto.sdui.common.RequestMetadata`. Treating `requestMetadata` as an
+unreviewed extra key, or rejecting `proto.sdui.*` in favor of
+`com.linkedin.*` only, aborted before POST. A payload-only body then
+returned HTTP 500. Adapter 1.32.0 copies that reviewed sibling shape,
+lifts headed nested `payload.requestMetadata` to the sibling placement
+when the two agree, and admits `proto.sdui.*` types only on this overlay
+POST body. Extra keys and unrelated proto prefixes still fail closed.
+
+A later signed-in smoke after adapter 1.32.0 peeled that sibling
+`proto.sdui` shape as `kind=action`, then the POST still returned HTTP
+500 `text/html`. The body sent empty sibling `RequestMetadata{$type}`
+only. Headed 200 Email capture `POST-navigation-body-shape-20260912.md`
+nests `requestMetadata` under `payload` with `$type`, `states: []`,
+overlay `screenId`, and `knownTemplates: []`, and keeps
+`clientArguments.$type` plus `requestedStateKeys: []`. Adapter 1.33.0
+emits that exact headed shape, including when dormant HTML omits
+metadata, copies reviewed string lists when the page already has them,
+and does not invent opaque state objects. Contained Chrome already
+sends `Accept: */*`, `Content-Type: application/json`, and session
+`csrf-token`; it does not mint `X-Li-*` track values. The query string
+stays `sduiid=` matching overlay `screenId`. If a later 500 persists
+after this exact body, the remaining gap is headed-only non-empty
+`states` / `knownTemplates`, not sibling placement.
+
+A later signed-in smoke after adapter 1.33.0 kept that exact headed
+body and still returned HTTP 500 `text/html` from contained Chrome.
+The POST ran from the signed-in origin fetch context, not the loaded
+profile document, so it omitted page-instance headers the SPA sets.
+Adapter 1.34.0 opens the exact reviewed profile URL, copies a unique
+`d_flagship3_profile*` `x-li-page-instance` from observed same-origin
+rsc-action or voyager requests or that document, and forwards optional
+`x-li-track` (`mpName` `web` or `voyager-web`),
+`x-li-application-version`, `x-li-application-instance`,
+`x-li-anchor-page-key`, and `x-li-rsc-stream=true` only when the same
+observation already has those values.
+
+A later signed-in smoke after adapter 1.34.0 kept that exact headed
+body and forwarded page-instance, track (`mpName=web`), application
+version/instance, anchor page key, and `rscStream=true`, then still
+returned HTTP 500 `text/html`. The same contained-browser
+`/flagship-web/rsc-action/` observations on the bound profile already
+carried `x-li-page-instance-tracking-id`, `x-li-pageforestid`,
+`x-li-traceparent`, and `x-li-tracestate`; 1.34.0 left those names off.
+Adapter 1.35.0 copies those original strings from the same selected
+rsc-action observation under a reviewed allowlist, copies
+`x-li-layout-tree` only when that observation has it, and does not mint
+any of those values when they are absent. Missing or malformed observed
+values fail closed before POST. Live query key stays `sduiid=` (headed
+200 Email POST and public SDUI `server-request` / `pagination` routes);
+`sduid=` notes are transcription typos. Missing or ambiguous
+page-instance fails closed before POST. Headed successful body
+Content-Length was 400; compact emit at 398 stays.
+
+A later signed-in headed proof on 2026-09-12 opened tessbloch, clicked
+Contact info, and showed Email in the modal DOM. The same contained
+synthetic navigation POST still returned HTTP 500 `text/html` after the
+exact headed body and the full observed X-Li set. Adapter 1.36.0 kept
+the page-instance bind, then clicked only the unique reviewed Contact
+info control and projected that modal. Operator smoke the same day
+found that unique control and fail-closed before click because its
+href matched `/overlay/contact-info/`. The raw eval error was exactly
+`Contact-info control targeted the vanity overlay GET`. Adapter 1.36.1
+clicks that unique control even when the href is the vanity overlay
+GET. Operator smoke after that click fail-closed because contained
+Chrome left `/in/tessbloch/` for
+`/in/tessbloch/overlay/contact-info/`. Adapter 1.36.2 treats that
+reviewed vanity overlay pathname as still bound after click, then
+snapshots the unique dialog. Authwall and any other path still fail
+closed. It does not mint a navigation POST or track headers. Cloud has
+no signed-in LinkedIn session; do not treat this landing as live green.
+
+```sh
+printf '%s' '{"profile_url":"https://www.linkedin.com/in/tessbloch/"}' \
+  | ghostget invoke linkedin-web contacts.read --input - --auth linkedin-dormant-20260911 --json
+```
+
 Self profiles fail closed with guidance to use `profiles.read`. Second-degree,
 third-degree, and out-of-network profiles fail closed because LinkedIn hid
 Contact info from that viewer. The operation never invents a hidden email.

package/skills/ghostget/references/platform-patterns.md

@@ -20,7 +20,7 @@ Leave the state `capture-required` when current evidence is absent, ambiguous, e
 ## LinkedIn
 
 - Use `linkedin-web` with a browser-session/cookie realm for consumer Home feed, a member's recent-activity posts, inbox folders, conversations, and native article-editor surfaces. The separate official `linkedin` OAuth adapter covers approved post, comment, reply, repost, and reaction scopes; it does not supply the consumer Home feed, recent-activity pager, or inbox.
-- Current bundle 1.23.0 observes `linkedin-web profiles.read@1`, `organizations.read@1`, `contacts.read@1`, `feeds.read@2` for `feed=profile-activity`, `articles.draft.save@7`, and image-only `posts.publish@3`. The two profile-stat reads use a path-backed contained Chrome realm, bind the current member before projecting one exact self profile or requested organization Page, and keep the optional private connection read sequential with the self-profile read. `contacts.read@1` uses the same contained Chrome path, requires a 1st-degree relationship on the requested vanity from classic Profile embeds or Como rehydration (JSON object or RSC flight array), and projects Contact-info email plus any shown profile link, connected-since date, phones, websites, or birthday. The profile-activity page uses the same contained Chrome path, binds the signed-in viewer, resolves the live `voyagerFeedDashProfileUpdates` query, and projects one recent-activity page with engagement counts when present; `feed=home` remains capture-required. The fixed browser evaluation performs only bounded, exact-route first-party fetches; it does not click or inspect LinkedIn DOM. A cookie-only standalone client is not a fallback because current live evidence shows LinkedIn invalidates an exported `li_at` outside its browser/device context. The Article contract binds the numeric member subject to the normalized Article-author profile, creates or replaces one exact private draft, keeps a supplied cover in the Article banner rather than the body, and can preserve the independently read existing banner during an exact replacement without another cover upload. It supports paragraphs/H1/H2/native blockquotes, native HTTPS links, and 1–20 bounded inline JPEG/PNG/WebP images with required alt text and optional captions, and verifies the exact unpublished editor-response readback. Its fixed cover and inline-image single-upload registrations, byte transfers, autosaves, and readbacks run inside contained Chrome without DOM automation. The separate post contract stages a real-size optional PNG through bounded ordered commands, admits one exact image transfer and post create, durably retains the accepted share target, and independently verifies it. `linkedin-web media.publish@1` separately reserves an MP4 route but remains capture-required; the official `linkedin posts.publish` OAuth contract already observes MP4.
+- Current bundle 1.36.2 observes `linkedin-web profiles.read@1`, `organizations.read@1`, `contacts.read@1`, `feeds.read@2` for `feed=profile-activity`, `articles.draft.save@7`, and image-only `posts.publish@3`. The two profile-stat reads use a path-backed contained Chrome realm, bind the current member before projecting one exact self profile or requested organization Page, and keep the optional private connection read sequential with the self-profile read. `contacts.read@1` uses the same contained Chrome path, requires a 1st-degree relationship on the requested vanity from classic Profile embeds or Como rehydration (JSON object, RSC flight array, non-flight Como string slots through `decodeStringBootstrap`, `vieweeProfileId` plus vanity, and breadcrumb, string-row, or `vieweeMemberUrn` distance, including multi-escaped PROFILE_VIEW rows and when that member id is not the bound `fsd_profile` URN), and projects Contact-info email plus any shown profile link, connected-since date, phones, websites, or birthday from page-embedded fields while skipping non-bounded SDUI field labels, or from the modal opened by clicking the unique reviewed Contact info control on that already-loaded 1st-degree profile after the same page-instance bind, including when that control's href matches `/overlay/contact-info/` and the document pathname stays on the bound profile or that reviewed vanity overlay path. A present NavigateToScreen action still admits only the reviewed ProfileContactDetailsOverlay URL (`sduiid` equal to that overlay `screenId`); the contained path does not mint a synthetic navigation POST or track headers. GraphQL Contact-info stays a 403 `text/html` fallback when a unique queryId is present and no navigation action is bound. The vanity `/overlay/contact-info/` RSC GET remains HTML-shell honesty when the profile omits that action. An HTML-200 profile shell that omits Email fails as omitted Contact-info fields after that 1st-degree bind; overlay, navigation-flight, or modal HTML that still carries Como Email, a unique mailto, or an RSC/SDUI flight still projects. ScreenId-only, `profileUrn`-bound, and GET `/flagship-web/rsc-action/actions/navigation` overlay URLs stay rejected because live dormant sessions return HTTP 500. The profile-activity page uses the same contained Chrome path, binds the signed-in viewer, resolves the live `voyagerFeedDashProfileUpdates` query, and projects one recent-activity page with engagement counts when present; `feed=home` remains capture-required. The fixed browser evaluation performs only bounded, exact-route first-party fetches, except the reviewed unique Contact info click and modal snapshot on `contacts.read`; it does not accept a caller-selected selector. A cookie-only standalone client is not a fallback because current live evidence shows LinkedIn invalidates an exported `li_at` outside its browser/device context. The Article contract binds the numeric member subject to the normalized Article-author profile, creates or replaces one exact private draft, keeps a supplied cover in the Article banner rather than the body, and can preserve the independently read existing banner during an exact replacement without another cover upload. It supports paragraphs/H1/H2/native blockquotes, native HTTPS links, and 1–20 bounded inline JPEG/PNG/WebP images with required alt text and optional captions, and verifies the exact unpublished editor-response readback. Its fixed cover and inline-image single-upload registrations, byte transfers, autosaves, and readbacks run inside contained Chrome without DOM automation. The separate post contract stages a real-size optional PNG through bounded ordered commands, admits one exact image transfer and post create, durably retains the accepted share target, and independently verifies it. `linkedin-web media.publish@1` separately reserves an MP4 route but remains capture-required; the official `linkedin posts.publish` OAuth contract already observes MP4.
 - Every other LinkedIn web operation remains capture-required. Explicit inert reservations cover inbox folders, one bounded page of recommended connections, one connection invitation, Article reads/publication, and other comment/message/repost surfaces. Their retained candidates do not confer executable internal requests.
 - Exclude presence, messaging badges, delivery acknowledgements, seen/read receipts, and notification badge traffic from every R1 contract.
 - Bind the current viewer's person/member identity to the auth realm. `organizations.read` views a Page and does not confer Page-actor authority. For organization actions, additionally bind the administered organization actor selected by the plan.

package/src/args.ts

@@ -36,6 +36,8 @@ type MessagingArguments = {
 
 export type GhostgetArguments =
   | { readonly command: "help" }
+  | { readonly command: "messaging-automation-serve" }
+  | { readonly command: "whatsapp-automation-install"; readonly binary?: string; readonly json: boolean }
   | { readonly command: "clip"; readonly arguments: readonly string[] }
   | { readonly command: "read"; readonly arguments: readonly string[] }
   | { readonly command: "media"; readonly arguments: readonly string[] }
@@ -69,7 +71,7 @@ export type GhostgetArguments =
     }
   | {
       readonly command: "imessage-transport-install";
-      readonly binary: string;
+      readonly binary?: string;
       readonly json: boolean;
     }
   | { readonly command: "doctor"; readonly json: boolean }
@@ -464,6 +466,11 @@ function optionalPositiveInteger(
 
 function parseMessagingArguments(raw: readonly string[]): ParseGhostgetResult {
   const operation = raw[0];
+  if (operation === "automation") {
+    return raw.length === 3 && raw[1] === "serve" && raw[2] === "--stdio"
+      ? { ok: true, value: { command: "messaging-automation-serve" } }
+      : { ok: false, message: "Use messaging automation serve --stdio; all owner configuration and message data must arrive on stdin." };
+  }
   if (operation === "reconcile") {
     const runId = raw[1];
     if (runId === undefined) {
@@ -923,6 +930,13 @@ export function parseGhostgetArguments(raw: readonly string[]): ParseGhostgetRes
     };
   }
   if (first === "whatsapp") {
+    if (raw[1] === "automation" && raw[2] === "install") {
+      const parsed = optionValues(raw.slice(3), ["--binary"], ["--json"]);
+      if (isFailure(parsed)) return parsed;
+      const binary = parsed.values["--binary"];
+      if (binary !== undefined && (!isAbsolute(binary) || resolve(binary) !== binary || Buffer.byteLength(binary) > 4096 || /[\0\r\n]/u.test(binary))) return { ok: false, message: "whatsapp automation install requires --binary <normalized-absolute-reviewed-wacli-file>" };
+      return { ok: true, value: { command: "whatsapp-automation-install", ...(binary === undefined ? {} : { binary }), json: parsed.booleans.has("--json") } };
+    }
     if (raw[1] !== "export-message-like-me") {
       return {
         ok: false,
@@ -966,11 +980,10 @@ export function parseGhostgetArguments(raw: readonly string[]): ParseGhostgetRes
     if (isFailure(parsed)) return parsed;
     const binary = parsed.values["--binary"];
     if (
-      binary === undefined
-      || !isAbsolute(binary)
+      binary !== undefined && (!isAbsolute(binary)
       || resolve(binary) !== binary
       || Buffer.byteLength(binary, "utf8") > 4_096
-      || /[\0\r\n]/u.test(binary)
+      || /[\0\r\n]/u.test(binary))
     ) {
       return {
         ok: false,
@@ -982,7 +995,7 @@ export function parseGhostgetArguments(raw: readonly string[]): ParseGhostgetRes
       ok: true,
       value: {
         command: "imessage-transport-install",
-        binary,
+        ...(binary === undefined ? {} : { binary }),
         json: parsed.booleans.has("--json"),
       },
     };

package/src/assets/adapters/imessage/wrench-web-adapter.json

@@ -231,6 +231,132 @@
         "timeoutMs": 30000,
         "maxOutputBytes": 1048576
       }
+    },
+    "messaging.automation.read": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R1",
+      "sideEffect": "none",
+      "idempotency": "none",
+      "dedupeWindowMs": 0,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "localCli": {
+        "surface": "imessage",
+        "action": "messaging.automation.read",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.text": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "localCli": {
+        "surface": "imessage",
+        "action": "messaging.automation.send.text",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.attachment": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "localCli": {
+        "surface": "imessage",
+        "action": "messaging.automation.send.attachment",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.reaction": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "localCli": {
+        "surface": "imessage",
+        "action": "messaging.automation.send.reaction",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.sticker": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "localCli": {
+        "surface": "imessage",
+        "action": "messaging.automation.send.sticker",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.link": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "localCli": {
+        "surface": "imessage",
+        "action": "messaging.automation.send.link",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.poll": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "localCli": {
+        "surface": "imessage",
+        "action": "messaging.automation.send.poll",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
     }
   }
 }

package/src/assets/adapters/linkedin/wrench-web-adapter.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 4,
   "id": "linkedin-web",
-  "version": "1.23.0",
+  "version": "1.36.2",
   "displayName": "LinkedIn (Authenticated Web API)",
   "surfaceId": "linkedin",
   "origins": [

package/src/assets/adapters/whatsapp/wrench-web-adapter.json

@@ -395,6 +395,150 @@
         "timeoutMs": 600000,
         "maxOutputBytes": 8388608
       }
+    },
+    "messaging.automation.read": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R1",
+      "sideEffect": "none",
+      "idempotency": "none",
+      "dedupeWindowMs": 0,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "webSession": {
+        "site": "whatsapp",
+        "action": "messaging.automation.read",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.sync": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R2",
+      "sideEffect": "Maintain an explicitly started linked-device sync session; may emit protocol acknowledgements.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "webSession": {
+        "site": "whatsapp",
+        "action": "messaging.automation.sync",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.text": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "webSession": {
+        "site": "whatsapp",
+        "action": "messaging.automation.send.text",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.attachment": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "webSession": {
+        "site": "whatsapp",
+        "action": "messaging.automation.send.attachment",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.reaction": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "webSession": {
+        "site": "whatsapp",
+        "action": "messaging.automation.send.reaction",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.sticker": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "webSession": {
+        "site": "whatsapp",
+        "action": "messaging.automation.send.sticker",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.link": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "webSession": {
+        "site": "whatsapp",
+        "action": "messaging.automation.send.link",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
+    },
+    "messaging.automation.send.poll": {
+      "description": "Scoped owner automation permission; use ghostget messaging automation serve --stdio. Generic invocation is unavailable.",
+      "risk": "R3",
+      "sideEffect": "Submit one exact action through an enrolled conversation and an unexpired bounded owner grant; delivery remains unknown.",
+      "idempotency": "local-at-most-once",
+      "dedupeWindowMs": 86400000,
+      "input": {
+        "properties": {},
+        "required": []
+      },
+      "webSession": {
+        "site": "whatsapp",
+        "action": "messaging.automation.send.poll",
+        "contractVersion": 1,
+        "timeoutMs": 30000,
+        "maxOutputBytes": 8388608
+      }
     }
   }
 }