@hraness/ghostget 0.18.0 → 0.18.3

package/dist/whatsapp-client.js

@@ -3,6 +3,7 @@ import {
   canonicalJson,
   sha256
 } from "./index-gwk7rbyj.js";
+import"./index-z1w83f81.js";
 
 // src/whatsapp-client.ts
 import { spawnSync } from "child_process";

package/docs/control-panel.md

@@ -9,7 +9,7 @@ and capabilities refresh when you return to the app, after changes made in the
 app, or when you choose Refresh. Permission decisions always validate current
 account and integration state.
 
-Build instructions and native qualification live in [desktop/README.md](https://github.com/hraness/ghostget/blob/v0.18.0/desktop/README.md).
+Build instructions and native qualification live in [desktop/README.md](https://github.com/hraness/ghostget/blob/v0.18.3/desktop/README.md).
 The CLI's canonical five-file GitHub Release contract is unchanged. A source
 build is not a signed or notarized public macOS installer.
 
@@ -123,7 +123,7 @@ User and imported interfaces are distinguished from bundled interfaces. Remote
 references, executable import hooks, arbitrary HTTP templates, and unsupported
 input-schema constructs are rejected or remain visibly inert as appropriate.
 An interface without an executor does not become executable by importing it.
-Use the existing [provider plugin protocol](https://github.com/hraness/ghostget/blob/v0.18.0/docs/plugins.md) when a new executor is
+Use the existing [provider plugin protocol](https://github.com/hraness/ghostget/blob/v0.18.3/docs/plugins.md) when a new executor is
 needed. OpenAPI import does not grant it account access.
 
 Middleware and LLM approval are future extensions. Future hooks may propose

package/docs/imessage-direct-provider.md

@@ -19,7 +19,12 @@ The vendored patch stack applies to `openclaw/imsg` 0.14.1 at commit
 `292db82d89293867ef847a2875667fea0fdd5dc1`, isolates AppleScript payloads.
 The second, `c5994f00d17969fd7772fd2772e7b3591089513a`, adds the read-only exact
 `chats.get(chat_id)` lookup required to revalidate a route without relying on a
-bounded recent-chat scan. Patch SHA-256 values, changed files, and the full
+bounded recent-chat scan. The third, `520b82ab025c1d4d57333b552aa65c9ae3fdb5fd`,
+adds `send.rich` URL cards with `fetch_metadata: false`. The admitted `.3`
+executable includes this mode. It bypasses the helper's LinkPresentation metadata
+and image fetching while retaining the native rich-card payload. The patch also
+corrects exact-chat test fixtures and requires the shipped PhoneNumberKit resource
+bundle in release builds. Patch SHA-256 values, changed files, and the full
 artifact review boundary are recorded in
 `src/plugins/imessage-direct/vendor/provenance.json`.
 
@@ -47,25 +52,44 @@ usable, not which Apple account Messages will choose.
 
 ## Build and installation boundary
 
-Apply both vendored mail patches in order to an otherwise clean checkout at the exact base,
-then build `imsg` in release mode. The current reviewed macOS arm64 executable
+The admitted binary includes all three vendored mail patches applied to the exact base,
+and was built in release mode. The current reviewed macOS arm64 executable
 SHA-256 is
-`77a0db864dfd247cd0a9142dd98997960582e6f150f76ecd3bf1c38944f2bf71`.
-Compiler, SDK, and command provenance are in the manifest. A different byte is
+`46c4c73c81c7db2d516c2d467c66aff03c73de196996d646bc8afce0ea85cff6`.
+Two independent release builds produce identical signed bytes with `-Xlinker -S`.
+This omits debug build paths before the default UUID and ad-hoc signature are
+generated. The adjacent resource bundle was exercised with the release
+PhoneNumberKit code. Compiler, SDK, and command provenance are in the manifest. A different byte is
 not this reviewed transport, even if it prints version 0.14.1.
 
 Install only that byte sequence through the checked installer:
 
 ```sh
-ghostget imessage transport install --binary /absolute/path/to/imsg --json
+ghostget imessage transport install --json
 ```
 
-The installer supports only the declared current platform, reads the source
+The default uses the exact compressed executable and PhoneNumberKit resources
+bundled with Ghostget. An explicit `--binary /absolute/path/to/imsg` may supply
+the same pinned executable. The installer supports only the declared current platform, reads the source
 without following a symlink, checks owner, mode, size, stability, and SHA-256,
 and installs by an exclusive same-filesystem link. It never replaces mismatched
 existing bytes. Software build, installation, Messages login, and account
 recovery remain operator workflows, not provider operations.
 
+The separate [owner messaging host](messaging-automation.md) supports native
+reactions, stickers and polls only when the existing compatible
+Messages bridge reports those operations available. Upstream's injected bridge
+requires a SIP-disabled Mac. Installing Ghostget's CLI binary does not install
+or inject that bridge, disable SIP, or relaunch Messages. A normal Mac without
+that explicit setup can still use the reviewed AppleScript text and attachment
+path after the required macOS permissions are granted.
+
+Native rich cards require the compatible bridge to report `send.rich` available.
+The messaging-host path requests `fetch_metadata: false` for those cards.
+The card contains the URL and its host name, without a fetched title or preview
+image. This confines this helper's metadata preparation; it does not claim to
+control all network behavior inside Messages or on the recipient's device.
+
 Bind the local Messages store after the reviewed binary is installed:
 
 ```sh

package/docs/messaging-automation.md

@@ -0,0 +1,103 @@
+# Owner messaging host
+
+`ghostget messaging automation serve --stdio` is the trusted owner control port
+for enrolled iMessage and WhatsApp conversations. It is never an agent tool.
+All configuration, targets, message bodies and assets arrive on stdin; stdout
+contains only protocol responses. Do not run it in a terminal or record its
+streams in general logs. It does not pair accounts or start synchronization on
+initialization.
+
+The `@hraness/ghostget/messaging-automation` SDK exports the closed message,
+grant, plan and receipt types, an explicit `createMessagingAutomationHost` for
+trusted owner-supplied providers, and `installBundledMessagingRuntime`. Imports
+are inert in Node and Bun; host construction requires Bun. Supplied providers
+must enforce their own exact permissions and cleanup. Use the stdio host above
+for Ghostget's built-in accounts and managed registry; its session factory is
+internal and is not part of the SDK.
+
+Install the current bundled `imessage-direct` or `whatsapp-web` adapter, bind an
+explicit existing Ghostget account, and enable managed operation permissions in
+Ghostget. Grant `allow` separately to `messaging.automation.read`, the required
+`messaging.automation.send.<kind>` operations, and (WhatsApp only)
+`messaging.automation.sync`. An old `messaging.send` allow does not authorize this
+host. `ask`, `deny`, and an unmanaged policy do not provide unattended authority.
+Updated manifests and automatic implementation closures invalidate old grants.
+These catalog entries cannot dispatch through generic `invoke` or `confirm`.
+
+The private transport binaries are separate owner setup:
+
+```sh
+ghostget imessage transport install --json
+ghostget whatsapp automation install --json
+```
+
+The default installs the exact compressed runtime included in the Ghostget package. An optional `--binary /absolute/reviewed-file` selects an explicit source instead. Only exact pinned bytes are accepted. Installation starts no helper. The
+WhatsApp binary is the reviewed wacli build with durable events and exact action
+claims; a stock wacli does not qualify. Existing account pairing and macOS
+permissions remain Ghostget setup responsibilities.
+
+Each newline-delimited JSON request is `{protocol,id,method,params}`, with
+`protocol` exactly `ghostget.messaging-automation/1`. IDs are distinct active
+ASCII identifiers of at most 64 bytes. Successful responses contain
+`{protocol,id,ok:true,result}`; failures contain a bounded generic
+`{protocol,id,ok:false,error:{code,message}}`. No diagnostic contains credentials,
+provider state paths, or message contents. Clients must correlate IDs: priority
+responses can arrive before a pending ordinary response.
+
+| Method | Exact params | Result |
+| --- | --- | --- |
+| initialize | providers: 1–2 `{provider,authId}`, distinct networks | `{initialized:true}` |
+| status | provider | Current identity and permissions-intersected capabilities |
+| start | provider | Current status; WhatsApp sync starts explicitly |
+| conversations | provider, limit (1–200) | Current individual conversations |
+| enroll | provider, coordinate | Exact identity/participants enrollment and historical baseline |
+| enrollments | empty object | Persisted enrollments |
+| grant | intentId, enrollmentId, expectedBindingDigest, actions, expiresAt, maximumActions, minimumIntervalMs | Bounded owner grant |
+| grant.by-intent | intentId | `{grant}`; null only when no matching durable grant exists |
+| grant.get | grantId | Current grant expiry, revocation and consumed quota |
+| revoke | grantId | `{revoked:true}` |
+| poll | enrollmentId | Refresh and admit new events; gaps remain explicit |
+| history | enrollmentId, limit (1–200) | Stored admitted history and enrollment; no additional provider read |
+| events | enrollmentIds, cursor (nullable), limit (1–500) | Durable scoped event page |
+| asset | bytesBase64, sha256 | assetId, byte count, digest, expiry |
+| prepare | enrollmentId, expectedRevision, intentId, actions | Exact two-minute plan |
+| submit | planId, grantId | Durable terminal/uncertain action receipt |
+| cancel | planId | `{cancelled:boolean}`; join submit to learn its outcome |
+| run | runId | Retained exact run receipt |
+| close | empty object | `{closed:true}` only after cleanup joins |
+
+Ordinary requests are serialized by the client; the server rejects a second
+ordinary in-flight request. Cancel, revoke and close have a separate capacity of
+eight and may interrupt a pending submit. Cancellation never proves that an
+already-started action was unsent. Grant creation requires an owner-persisted intent ID; recover an uncertain response with `grant.by-intent` before doing anything else. Keep reading the original submit response,
+and reconcile its exact run identity without resubmitting uncertain work.
+
+Frames are bounded to 24 MiB; responses to 32 MiB. Assets use canonical Base64 and
+a checked SHA-256, at most 16 MiB each, 64 MiB total and 32 entries. An unclaimed
+asset lasts five minutes; prepare binds it to one plan's expiry, and only that
+submit can resolve its bytes. Terminal submit removes its assets. Assets do not
+survive restart and never accept arbitrary filesystem paths.
+
+Every provider operation rechecks the account incarnation, exact implementation
+identity and managed permission. Explicit sync keeps a durable cleanup admission
+for the lifetime of the owned WhatsApp process; loss or revocation of its sync
+allow closes the provider, checked at one-second intervals. iMessage operations
+join and release their own admissions. A cleanup failure retains the existing
+Ghostget recovery marker across restart. Never remove it or take over an unknown
+socket merely because the parent process exited. The owner must use the existing
+Ghostget recovery process to establish exact descendant and resource cleanup.
+
+The host stores enrollments, grants, historical baselines, durable cursors and
+action claims privately in the selected Ghostget state home. Source generation,
+account or participant drift prevents continuation. Historical bootstrap does
+not become a live event; possible gaps prevent automatic sends. Provider
+acceptance is reported separately from delivery or read status. Available rich
+actions depend on the current pinned helper and explicit permissions;
+app-clips and arbitrary mini-app experiences remain unavailable.
+
+Native iMessage links use the pinned `.3` helper and require the compatible
+bridge to report `send.rich` available. The host sets `fetch_metadata: false`
+to build a native URL/host-title card without helper metadata or image fetching.
+This does not control all network behavior inside Messages or on the recipient
+device. WhatsApp link sharing uses its existing text payload with preview
+fetching disabled.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hraness/ghostget",
-  "version": "0.18.0",
+  "version": "0.18.3",
   "description": "Open-source CLI and TypeScript SDK for precise web capabilities for AI agents: page capture, verified media archives, encrypted reads, and typed provider operations.",
   "license": "MIT",
   "type": "module",
@@ -74,6 +74,10 @@
     "./messaging": {
       "types": "./src/messaging-types.ts",
       "import": "./dist/messaging.js"
+    },
+    "./messaging-automation": {
+      "types": "./src/messaging-automation-types.ts",
+      "import": "./dist/messaging-automation-api.js"
     }
   },
   "bin": {
@@ -315,6 +319,21 @@
     "src/message-like-me-agentic-messaging.ts",
     "src/messaging-types.ts",
     "src/messaging.ts",
+    "src/messaging-automation-api.ts",
+    "src/messaging-automation-types.ts",
+    "src/messaging-automation-validation.ts",
+    "src/messaging-automation.ts",
+    "src/messaging-automation-descriptors.ts",
+    "src/messaging-automation-factory.ts",
+    "src/messaging-automation-server.ts",
+    "src/providers/imessage-automation.ts",
+    "src/providers/whatsapp-automation.ts",
+    "src/providers/whatsapp-automation-runtime.ts",
+    "src/providers/messaging-native-install.ts",
+    "src/providers/messaging-native-artifacts.ts",
+    "src/assets/messaging-runtime",
+    "src/plugins/whatsapp-linked-device/vendor",
+    "docs/messaging-automation.md",
     "src/messaging-action-store.ts",
     "src/messaging-runtime.ts",
     "src/messaging-store.ts",
@@ -348,6 +367,7 @@
     "src/plugins/imessage-direct/plugin.ts",
     "src/plugins/imessage-direct/vendor/0001-fix-keep-AppleScript-send-payloads-out-of-child-argv.patch",
     "src/plugins/imessage-direct/vendor/0002-feat-rpc-add-exact-chat-lookup.patch",
+    "src/plugins/imessage-direct/vendor/0003-feat-rpc-add-no-fetch-rich-cards.patch",
     "src/plugins/imessage-direct/vendor/provenance.json",
     "src/plugins/linkedin-official/plugin.ts",
     "src/plugins/linkedin-web/plugin.ts",
@@ -573,7 +593,7 @@
     "website:test": "bun test ./website ./edge",
     "website:typecheck": "tsc --noEmit --project website/tsconfig.json && tsc --noEmit --project edge/tsconfig.json",
     "website:check": "bun run check:theme && bun run website:typecheck && bun run website:test && bun run website:build",
-    "build": "bun -e 'await (await import(\"node:fs/promises\")).rm(\"./dist\", { recursive: true, force: true })' && bun build ./src/index.ts ./src/client.ts ./src/beeper-client.ts ./src/apple-photos-client.ts ./src/whatsapp-client.ts ./src/omni-client.ts ./src/messaging.ts --outdir ./dist --root ./src --target bun --format esm --splitting --packages external",
+    "build": "bun -e 'await (await import(\"node:fs/promises\")).rm(\"./dist\", { recursive: true, force: true })' && bun build ./src/index.ts ./src/client.ts ./src/beeper-client.ts ./src/apple-photos-client.ts ./src/whatsapp-client.ts ./src/omni-client.ts ./src/messaging.ts ./src/messaging-automation-api.ts --outdir ./dist --root ./src --target bun --format esm --splitting --packages external",
     "typecheck": "tsc --noEmit",
     "whatsapp:transport:install": "sh src/scripts/install-whatsapp-protocol.sh",
     "test:unit": "bun test --no-orphans --timeout 180000 --max-concurrency \"${GOMAXPROCS:-4}\" ./src --path-ignore-patterns='**/src/omni-runtime.test.ts'",

package/skills/ghostget/references/control-panel.md

@@ -40,4 +40,4 @@ Unsupported executors remain inert. Follow the existing provider-plugin
 authoring protocol to add an executor; do not synthesize arbitrary authenticated
 HTTP or broaden an existing grant. Interface changes invalidate exact grants.
 
-The product reference is the [Ghostget control panel guide](https://github.com/hraness/ghostget/blob/v0.18.0/docs/control-panel.md).
+The product reference is the [Ghostget control panel guide](https://github.com/hraness/ghostget/blob/v0.18.3/docs/control-panel.md).

package/skills/ghostget/references/install.md

@@ -17,34 +17,34 @@ If Bun is missing, stop and direct the user to the official
 [Bun installation guide](https://bun.sh/docs/installation). Do not switch
 package managers or pipe an unreviewed installer into a shell.
 
-This reference is authored for the exact v0.18.0 release coordinate. Use it
+This reference is authored for the exact v0.18.3 release coordinate. Use it
 only from the matching release-bound Agent Skill after its canonical archive and
 immutable GitHub Release exist. If the coordinate is not public, stop instead
 of substituting `main`, another tag, or a different package version. Install
 that exact release and its reviewed bundled adapter manifests:
 
 ```sh
-bun add --global https://github.com/hraness/ghostget/releases/download/v0.18.0/hraness-ghostget-0.18.0.tgz
+bun add --global https://github.com/hraness/ghostget/releases/download/v0.18.3/hraness-ghostget-0.18.3.tgz
 ghostget adapter sync-bundled --json
 ghostget --help
 ghostget doctor --json
 ```
 
-The package is `@hraness/ghostget`; `@hraness/ghostget@0.18.0` is an optional npm
+The package is `@hraness/ghostget`; `@hraness/ghostget@0.18.3` is an optional npm
 mirror only after verified registry publication. Canonical installation does not
 wait for registry publication.
 
 When upgrading from Wrench, use `ghostget` for new commands and
 `GHOSTGET_STATE_HOME` for an explicit state root. Existing state is selected in
 place; do not rename, copy, or delete a state directory as part of the upgrade.
-The [migration guide](https://github.com/hraness/ghostget/blob/v0.18.0/docs/ghostget-migration.md)
+The [migration guide](https://github.com/hraness/ghostget/blob/v0.18.3/docs/ghostget-migration.md)
 explains the retained state aliases and durable protocol names.
 
 Do not clone the repository merely to run the CLI. Importing the SDK is a
 separate project dependency and does not install a global command:
 
 ```sh
-bun add https://github.com/hraness/ghostget/releases/download/v0.18.0/hraness-ghostget-0.18.0.tgz
+bun add https://github.com/hraness/ghostget/releases/download/v0.18.3/hraness-ghostget-0.18.3.tgz
 ```
 
 `ghostget adapter sync-bundled` upgrades exact bundled baselines, including an

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

@@ -232,27 +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, arrays, or JSON strings, 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`, `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
-rather than on the same decoded object as the identity. Empty, missing, or
-import-only bootstrap stays fail-closed.
+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.3 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. When the NavigateToScreen extract is
+`absent`, the same click still uses that reviewed overlay `sduiid` plus a
+headed clientArguments payload from the bound vanity, optional
+givenName/familyName parsed from profile HTML when unique,
+`isVanityNameResolved`, nested requestMetadata
+states/screenId/knownTemplates, and `isModal` true. 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. GraphQL `voyagerIdentityDashProfileContactInfo` and
+the vanity overlay RSC GET stay unused once that click is selected.
+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 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.
@@ -287,6 +315,180 @@ 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. Operator smoke after that bind was green
+for Email on tessbloch when the extract was `absent` and the operator
+clicked with the reviewed overlay `sduiid` plus headed clientArguments.
+Official `contacts.read` still used GraphQL or the vanity overlay GET
+on that absent extract. Adapter 1.36.3 uses the same click and modal
+snapshot when extract is `absent`. 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.24.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, RSC flight array, `vieweeProfileId` plus vanity, and breadcrumb or string-row distance), 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.3 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`). When that extract is `absent`, the same click still uses that reviewed overlay `sduiid` plus a headed clientArguments payload from the bound vanity, optional givenName/familyName from profile HTML, `isVanityNameResolved`, and nested requestMetadata. The contained path does not mint a synthetic navigation POST or track headers. GraphQL Contact-info and the vanity `/overlay/contact-info/` RSC GET stay unused once that click is selected. 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.