Roadmap: production Linq channel and optional FaceTime Audio

[RomneyDa]

Linq OpenClaw Integration Plan

Updated: 2026-07-15

Objective

Deliver a production-grade Linq messaging channel whose normal setup succeeds
without requiring users to understand chat IDs, webhook internals, approval
routing, or OpenClaw's agent/model hierarchy.

Realtime FaceTime Audio is a later optional feature, not the organizing goal of
the plugin. Contract discovery may happen independently, but implementation is
ordered after the messaging channel is easy to set up, operate, and diagnose.
Video remains out of scope.

Evidence Incorporated

Completed foundation

• PR Upgrade Linq core channel support #5 established the supported Linq API routes, SecretRef-aware config,
  explicit phone/chat target grammar, first-contact chat creation, signed
  webhook validation, payload normalization, and focused tests.
• PR Add automated Linq inbound setup #7 added setup discovery, phone-number selection, webhook subscription
  create/find/replace/delete behavior, signing-secret capture, and the
  OpenClaw-owned plugin HTTP route. Its live E2E proved signed inbound, agent
  execution, reply delivery, subscription reuse, and cleanup.
• PR Align Linq messaging with the OpenClaw channel runtime #10 is the current merge gate. It replaces legacy inbound orchestration
  with shared OpenClaw ingress/pairing/inbound runtime behavior, adds canonical
  outbound session routing and receipts, splits the monitor into focused
  modules, and proves restart-safe delivery on OpenClaw 2026.6.1.
• OpenClaw 2026.7.1 adds optional recipient-aware one-shot CLI routing and
  account scope in pairing hooks. These are enhancements, not requirements for
  the current messaging contract. Keep the peer floor at >=2026.6.1 unless a
  later phase deliberately requires a newer public SDK.

FaceTime Audio contract discovery

• The live Linq router exposes call-control shapes for POST /v3/calls,
  GET /v3/calls/{callId}, POST /v3/calls/{callId}/answer, and
  POST /v3/calls/{callId}/end.
• Linq's live OpenAPI artifact contains a Calls tag describing outbound
  initiation, inbound answering, hangup, Opus 48 kHz mono audio, and H.264
  video. It also declares seven call.* lifecycle event names.
• Those call paths and their schemas are absent from the public OpenAPI path
  catalog, TypeScript SDK 0.28.2, MCP package 0.28.2, and CLI 2.5.0. The
  authenticated event catalog for the current account also omits call.*.
• Public Linq SDK history contains a generated commit named
  Pdev 6191 facetime orchestrator hub api service call service webhook, which
  ties the lifecycle artifacts to a FaceTime orchestration project.
• The experimental worktree proves that OpenClaw's realtime voice bridge can
  carry a conversation through the local FaceTime app by using
  ScreenCaptureKit for caller audio and BlackHole as a virtual microphone. It
  does not use Linq's call service and is not evidence of a provider-hosted
  FaceTime call.
• Linq has confirmed privately that FaceTime support exists, has not been
  publicly released, and can be enabled. Both FaceTime audio and video are
  supported provider-side; video remains outside this plugin's scope.
• Linq identified concurrency as the primary limitation: a FaceTime identity
  currently supports one active caller at a time. A multi-party workaround can
  create a room, invite participants and a third party, and have the agent leave,
  but that flow is intentionally outside the initial plugin scope.
• Do not invoke the mutating call routes or ship against them until Linq enables
  the feature and provides an approved integration contract.

PR review lessons that remain planning constraints

• Verify Linq routes and payloads against the live API, not only types or
  documentation. PR Upgrade Linq core channel support #5 caught an invalid first-contact route; PR Add automated Linq inbound setup #7 caught the
  /phone_numbers spelling and phone-filter permission behavior.
• Runtime config, TypeScript config, and both manifest schema surfaces must stay
  recursively identical. Strict schemas must never reject fields the runtime
  reads or advertise fields the runtime ignores.
• Provider chat IDs must always use explicit linq:chat:<id> targets. Never
  feed bare provider IDs through ambiguous phone/chat parsing.
• Setup may mutate provider state; status and diagnostics must remain bounded
  and read-only.
• A matching subscription is insufficient when its create-only signing secret
  has been lost. Setup must preserve or deliberately recreate it.
• Every externally observable phase requires live sandbox proof and cleanup of
  subscriptions, tunnels, temporary state, and credentials.

Patrick's setup feedback

• The API-token and phone-number portions are understandable.
• Public webhook exposure is the main nontechnical blocker.
• Frequent host approvals make the channel unpleasant to use.
• Approval prompts can be routed to Telegram even when the request originated
  in Linq.
• The inherited default model can be too weak, while the channel gives no
  indication of which agent/model it will use or how to change it.

Current implementation gaps exposed by that feedback

• The wizard defaults to http://localhost:3100/linq-webhook, even though the
  provider subscription requires public HTTPS and the actual route belongs to
  the OpenClaw Gateway, normally on port 18789.
• Setup can complete after skipping subscription creation for a non-HTTPS URL.
  It does not finish with an inbound-readiness verdict or real smoke test.
• The plugin does not surface OpenClaw's effective exec policy, approval
  forwarding destination, selected agent, or selected model.
• Fresh Linq configuration still defaults to dmPolicy: "open", although the
  shared durable pairing path now exists.
• Webhook dedupe is process-local, and generated webhook secrets are currently
  written directly into config when no writable secret-provider contract is
  available.
• Reaction and delivery-status events are received but are only logged.

Reconciliation with the earlier PR and parity plans

No still-relevant messaging item is dropped. Completed work becomes the
baseline; unfinished work moves to the earliest phase where its dependencies
exist.

Earlier plan element	Updated disposition
Core target grammar, first-contact sends, explicit chat replies, signed webhook handling	Completed by PR #5; regression baseline in Phase 0
Automated phone selection, provider subscription lifecycle, signing-secret capture, Gateway route	Completed by PR #7; correctness and usability follow-up in Phases 1-2
Shared inbound runtime, canonical phone sessions, durable chat delivery route, standard receipts	Completed by PR #10 once merged; Phase 0 gate
Status/doctor parity with SMS	Phase 2, immediately after correcting the webhook setup contract
Durable phone/chat routing and account-scoped pairing	Runtime portion completed by PR #10; fresh-install pairing default and migration finish in Phase 3
webhookMaxBytes, replay window, dedupe TTL, retry/failure semantics	Phase 4; expose configuration only with wired, bounded behavior
Secure generated webhook-secret persistence	Phase 5; writable provider preferred, owner-only file SecretRef fallback
mediaMaxMb, hydrated media, voice memos	Phase 6A; only after provider shapes and limits are proven
textChunkLimit	Retain shared 4,000-character behavior unless live Linq limits justify a public override; if justified, ship in Phase 6A with runtime wiring
Delivery/read status and provider error classification	Phase 6A
Reactions and approval affordances	Phase 6B
groupPolicy, groupAllowFrom, groups, stable group sessions	Phase 6C before group capability is advertised
Effects, typing controls, native replies, edit/unsend, contact cards	Phase 6C, individually gated by public API proof
blockStreaming	Superseded as a Linq-specific knob; use OpenClaw's shared reply/streaming pipeline unless Linq gains a distinct provider requirement
Production webhook, policy, media, status, rate-limit, and troubleshooting docs	Incremental quickstart correction in Phase 1; complete production docs in Phase 6D
Host-backed durable plugin state	Phase 4 only through a public third-party-plugin state contract; trusted-only SQLite is not acceptable
Writable Vault/generated-secret support	Phase 5 when OpenClaw publishes it; do not invent a Linq-only vault writer
FaceTime Audio	Phase 7 optional feature; Linq has confirmed unreleased audio/video support, while enablement, endpoint schemas, duplex media, and single-call operation remain gated

The old fork PR #2 is therefore a requirements reference, not a merge
candidate. Its legacy monitor wiring is obsolete, and its reserved fields must
not enter the public schema ahead of implemented behavior.

Planning Rules

• Prioritize successful messaging setup and daily usability before expanding
  channel breadth.
• Preserve a narrow public config surface. Add a knob only when its runtime
  behavior, validation, diagnostics, and tests ship together.
• Do not silently weaken security or globally change an operator's model/tool
  policy. Show the effective state, offer explicit choices, and require
  confirmation for changes outside channels.linq.
• Keep provider probes read-only outside setup.
• Prefer OpenClaw pairing, sessions, routing, approval forwarding, agent
  bindings, and other shared contracts over Linq-owned substitutes.
• Preserve explicit account scope for every subscription, pairing, session,
  delivery target, secret, and future call.
• Treat unsupported capabilities as status results, not channel failures.
• Do not implement undocumented Linq endpoints.

Target Architecture

Messaging plane

Linq remains a normal OpenClaw channel:

Linq signed webhook
  -> OpenClaw plugin HTTP route
  -> Linq validation and event normalization
  -> shared channel ingress/pairing
  -> shared inbound agent runtime
  -> persisted linq:chat:<chat_id> delivery route
  -> Linq send API

Remote phone identity is the canonical DM identity. Provider chat_id is the
durable delivery target, not a second user identity.

Setup and diagnostics plane

Setup owns intentional mutations:

• token and phone selection;
• public ingress choice;
• subscription create/replace/recreate;
• generated signing-secret persistence;
• optional, confirmed agent/model and approval-routing configuration.

Status owns non-mutating truth:

• token and selected-line health;
• local route and public URL consistency;
• matching subscription, events, and phone filter;
• signing-secret readiness;
• recent inbound/outbound/provider failures;
• routed agent/model and approval destination;
• optional feature capability readiness as those features ship.

Ordered Delivery Plan

Phase 0: Merge and freeze the messaging runtime baseline

Current work: PR #10.

• Obtain review on the current head and resolve findings.
• Re-run npm run check, package inspection, plugin load/doctor, and the
  documented 2026.6.1/2026.7.1 compatibility matrix if the head changes.
• Merge before starting dependent implementation branches.
• Record PR Upgrade Linq core channel support #5, Add automated Linq inbound setup #7, and Align Linq messaging with the OpenClaw channel runtime #10 behavior as the regression baseline.

Exit criteria:

• PR Align Linq messaging with the OpenClaw channel runtime #10 is merged.
• Signed inbound, agent reply, canonical phone session, exact chat delivery
  target, receipt normalization, pairing account scope, and restart-safe send
  remain proven.
• The minimum peer version and optional newer-host behavior are documented.

Phase 1: Correct the webhook onboarding contract

This is the first new implementation phase because the current default is
misleading and blocks less technical users.

• Rename the prompt conceptually to Public webhook URL while retaining
  config compatibility for webhookUrl.
• Remove the fake localhost:3100 default. Derive the local destination from
  the configured OpenClaw Gateway and webhookPath.
• Present explicit ingress choices:
  1. use an existing public HTTPS URL;
  2. configure a path-scoped Tailscale Funnel;
  3. configure a Cloudflare Tunnel or equivalent reverse proxy;
  4. continue outbound-only with inbound clearly marked incomplete.
• Generate exact path-scoped commands and warnings. Do not expose the Control
  UI or entire Gateway when only /linq-webhook is required.
• Detect available tunnel tooling where possible, but never install software or
  run persistent exposure commands without confirmation.
• Require HTTPS before offering provider subscription creation. Do not present
  a skipped subscription as completed inbound setup.
• Show a final setup summary: local path, public target, subscription ID,
  phone filter, secret status, and next verification action.
• Rewrite the README quickstart and production ingress examples at the same
  time.

Exit criteria:

• A user cannot accidentally accept a nonfunctional localhost URL as completed
  inbound setup.
• Tailscale and Cloudflare paths are documented with exact Gateway/path
  routing and cleanup commands.
• Outbound-only mode is explicit and reversible.
• Existing working webhookUrl configurations continue to load.

Phase 2: Add structured status, diagnostics, and setup verification

Build the read-only truth surface before adding more onboarding automation.

• Replace the phone-list-only probe with a structured, timeout-bounded account
  probe.
• Report:
  • token/API validity;
  • selected phone ownership and provider health;
  • local route registration/path;
  • public URL scheme/path consistency;
  • matching active subscription;
  • subscribed event set and phone filter, including unfiltered fallback;
  • signing-secret presence/source;
  • last inbound, outbound, delivery status, and provider error;
  • routed agent/model and remaining approval destination when available;
  • implemented optional capability readiness as those features ship.
• Implement OpenClaw capability formatting and actionable diagnostics following
  the current SMS/status contracts available at the supported peer boundary.
• Add a post-start verification command or guided check that confirms the route
  is reachable and supports a real signed inbound/outbound smoke test.
• Keep probes non-mutating: no subscription replacement, secret recreation, or
  test message without explicit setup/smoke confirmation.

Exit criteria:

• Status distinguishes outbound-only, inbound-ready, subscription mismatch,
  missing signing secret, unreachable/misrouted ingress, and provider failure.
• Every failure includes one concrete corrective action.
• A user can prove inbound and reply delivery without reading Gateway logs.

Phase 3: Make trust, approvals, and model routing understandable

This phase addresses Patrick's daily-use friction after transport setup is
truthful and diagnosable.

Sender trust

• Change fresh-install default DM posture to pairing.
• Preserve existing explicit open configurations; provide an intentional
  migration path instead of silently locking out current users.
• Verify account-scoped pairing approval, restart durability, and multi-account
  isolation on the minimum supported host.
• Make open require an explicit warning/confirmation in setup.

Exec approvals

• Display the effective OpenClaw exec policy, including the fact that the host
  approvals file can be stricter than tools.exec config.
• Offer documented choices without silently applying them:
  • auto as the recommended guarded coding experience;
  • ask for human review of misses;
  • deny for no host execution;
  • full only with a high-risk warning and matching host-policy instructions.
• Offer to route approval prompts to the originating Linq conversation using
  OpenClaw's shared approvals.exec session forwarding.
• Detect and explain when Telegram or another native approval client is also
  enabled; offer an explicit way to disable unwanted out-of-band delivery.
• If current setup SDK contracts cannot safely configure these global fields,
  show exact config commands and propose the missing upstream OpenClaw setup
  seam rather than adding Linq-specific approval machinery.

Agent and model

• Show the agent and effective model that Linq will inherit before setup ends.
• Allow the user to keep the default agent, bind Linq to an existing agent, or
  create/select a dedicated Linq agent when the public setup SDK supports it.
• Explain the difference between a session /model override and a durable
  channel-to-agent binding.
• Never hardcode a supposedly "best" or expensive model. Present available
  authenticated models with capability/cost guidance supplied by OpenClaw.
• If the required binding/model picker is upstream-only, document the exact
  agents.list plus bindings shape and file an upstream UX request.

Exit criteria:

• A fresh personal setup defaults to pairing.
• The user knows why approvals occur and where the next approval will appear.
• Remaining approvals can be completed from Linq without requiring Telegram.
• Setup names the effective Linq agent/model and provides a durable route to
  change it.

Phase 4: Harden webhook reliability and provider failure behavior

• Add bounded in-flight claim and replay semantics modeled on current OpenClaw
  webhook channels.
• Authenticate before consuming replay/failure-rate budget or allocating agent
  work.
• Define deterministic responses for duplicate, in-flight duplicate,
  saturation, malformed payload, dispatch failure, and retryable provider
  delivery.
• Bound request reads, response/error bodies, cache size, cache lifetime,
  provider retry delays, and concurrent dispatch.
• Ensure a crash after claim but before successful processing does not make a
  legitimate provider retry permanently unprocessable.
• Preserve event/account isolation and avoid cross-account path collisions.
• Use a public host state contract if one exists; do not require trusted-only
  SQLite APIs. Otherwise document the process-local durability boundary and
  design for safe retry after restart.

Exit criteria:

• Concurrency, duplicate, retry, saturation, and crash-window tests pass.
• A live duplicate/retry proof does not produce duplicate agent replies.
• Status exposes recent webhook/provider failures without leaking payloads or
  secrets.

Phase 5: Secure generated webhook-secret storage

• Stop writing newly generated signing secrets directly into openclaw.json
  in the final architecture.
• Prefer a future public writable secret-provider contract when available.
• If it remains unavailable, use an owner-only file with atomic write and store
  a file SecretRef in config, after validating that this is supported for
  third-party plugins on every target platform.
• Store the create-only secret before considering subscription setup complete.
  If persistence fails, remove the just-created subscription or present a
  recoverable recreation path.
• Migrate plaintext webhookSecret values safely and idempotently with explicit
  backup/rollback behavior.
• Preserve env/file/exec and other supported read-only SecretRefs.
• Cover multi-account permissions, failed writes, setup reruns, recreation,
  migration, package leakage, and log redaction.

Exit criteria:

• New setup leaves only a SecretRef in normal config.
• Migration never loses the only usable subscription secret.
• Secret files are owner-only and no test/package artifact contains secrets.

Phase 6: Expand messaging depth in dependency order

Ship these as separate, reviewable PRs rather than one broad feature PR.

6A. Delivery status, provider errors, and media correctness

• Normalize delivery/read/failure events into current OpenClaw status surfaces.
• Classify provider errors and rate limits with bounded, actionable detail.
• Enforce media size/type limits consistently for inbound and outbound paths.
• Add hydrated media support only after confirming the official Linq API shape.
• Add voice memo sending as asynchronous media; do not label it realtime voice.

6B. Reactions and native approval affordances

• Convert reaction events from logging-only behavior into the current OpenClaw
  reaction surface when provider identity and message mapping are reliable.
• Investigate a native Linq approval experience using explicit replies or
  tapbacks. Only map reactions to approval decisions when authorization,
  pending approval identity, message correlation, expiry, and replay behavior
  are unambiguous.
• Advertise reaction capability only when send/receive behavior is implemented
  and tested.

6C. Groups and richer actions

• Resolve stable group peer identity and preserve sender identity inside group
  envelopes.
• Add explicit group authorization, mention gating, account scoping, and
  session semantics before enabling reserved group targets.
• Add edit, unsend, effects, typing controls, contact cards, and other actions
  only where the public Linq contract proves support.

6D. Production documentation

• Document requirements, installation, guided setup, SecretRefs, pairing,
  agent/model binding, approval routing, production ingress, target grammar,
  media/groups/reactions, status, troubleshooting, rate limits, and known
  limitations.
• Include Mac Studio, headless host, Tailscale, Cloudflare Tunnel, and stable
  reverse-proxy examples.

Exit criteria:

• Each advertised capability has focused tests, status evidence, and live proof
  where the sandbox supports it.
• Group and reaction capability flags match actual implementation.
• A new user can complete production setup from the README without an AI
  assistant inventing missing networking, model, or approval steps.

Phase 7: Optional FaceTime Audio feature

This is a feature phase after the messaging roadmap, not a parallel product
track. The only work that should happen earlier is obtaining and validating the
Linq contract. The local FaceTime/BlackHole prototype is useful bridge evidence,
but it is not the production transport and does not relax this gate.

Contract gate:

• Obtain explicit Linq feature access and an approved request/response contract
  for the observed initiate, retrieve, answer, and end routes.
• Establish how inbound calls reach a stable Linq FaceTime identity and how
  outbound calls use that identity.
• Obtain the media-negotiation contract needed to send and receive authenticated
  realtime audio, including transport, stream credentials, codec/framing, and
  provider-required heartbeat, timeout, and limit behavior.
• Obtain call lifecycle event payload and delivery semantics, or a documented
  status-polling alternative sufficient to operate calls safely.
• Prove one standalone sandbox call with audio in both directions and clean
  hangup. Until that succeeds, no plugin implementation or marketing begins.

Responsibility boundary:

• Linq owns the callable FaceTime identity, inbound/outbound FaceTime call
  control, and the authenticated bidirectional media path.
• The plugin owns realtime-model integration, audio adaptation and buffering,
  VAD, barge-in, agent tools and context, call policy, reconnect behavior,
  diagnostics, and bounded backpressure handling on top of Linq's contract.
• Official SDK, CLI, and MCP support are useful but not prerequisites if Linq
  supplies a stable approved HTTP/media contract.

Initial concurrency scope:

• Enforce one active call per Linq FaceTime identity. A second inbound call must
  receive a deterministic busy/decline outcome, and a second outbound request
  must fail fast without disturbing the active call.
• Reconcile provider state after disconnects and restarts so a stale local call
  cannot leave the line permanently busy.
• Do not implement the room/invite/third-party/leave workaround in the initial
  release. Treat multi-party concurrency as a separate experimental feature.

If the gate succeeds, deliver the feature in four small dependent increments:

1. Call control: account-scoped lifecycle manager, policy, idempotency, timeouts,
   a hard one-call concurrency limit, deterministic busy handling, stale cleanup,
   shutdown, and call.* subscription only when advertised.
2. Media transport: authenticated stream ingress, codec adaptation, pacing,
   limits, backpressure, heartbeat, reconnect, activity health, and loopback
   proof. Prefer a public plugin WebSocket seam; otherwise use a bounded
   dedicated media server.
3. Realtime bridge: use OpenClaw's registered realtime provider and
   RealtimeVoiceBridgeSession, default agent-proxy,
   openclaw_agent_consult, the existing Linq phone session, VAD, barge-in, and
   output cancellation. Do not add a Linq-owned OpenAI/Gemini client.
4. Production hardening: replay/race/restart coverage, failure paths,
   observability, privacy/retention docs, explicit live smoke commands, and
   complete sandbox cleanup.

Exit criteria:

• Inbound and outbound FaceTime Audio support three alternating turns, consult,
  barge-in, hangup, restart/cleanup, account isolation, and no credential or raw
  audio leakage.
• A concurrent second call is rejected predictably, and stale provider/local
  state recovers without manual intervention.
• If Linq only provides call forwarding, integrate it through OpenClaw Voice
  Call as a separately named feature.

Proposed PR Sequence

Order	Scope	Dependency	Status
0	PR #10: SDK runtime alignment	PR #7	Open; merge gate
1	Webhook onboarding correctness and docs	PR #10	Next
2	Structured status and smoke diagnostics	Order 1	Planned
3	Pairing default, approval routing, agent/model UX	Order 2	Planned; may require upstream SDK work
4	Webhook reliability and retry semantics	Order 2	Planned; can overlap Order 3
5	Generated-secret secure storage	Order 1	Planned; contract-dependent
6A	Delivery status, provider errors, and media	Orders 2 and 4	Planned
6B	Reactions and approval affordances	Orders 3 and 6A	Planned
6C	Groups and richer actions	Orders 4 and 6A	Planned
6D	Production documentation and final E2E	All messaging work	Planned
7	Optional FaceTime Audio feature	All core messaging phases plus approved Linq call/media contract	Later; provider-confirmed, enablement/schema/media pending, one active call per identity

Validation Matrix

Every PR must include the narrowest applicable subset; final messaging and
voice releases include all applicable rows.

Area	Required proof
Compatibility	Typecheck/tests on minimum peer; newer-host optional behavior
Schema	Runtime schema and both manifest surfaces remain recursively equal
Package	git diff --check, npm run check, npm pack --dry-run inspection
Setup	Fresh setup, rerun, changed URL/phone, cancellation, rollback, cleanup
Ingress	Signed valid, unsigned, wrong path, malformed, oversized, duplicate
Routing	Phone identity, explicit chat target, account isolation, restart send
Security	Pairing/open migration, approval authorization/routing, secret redaction
Status	Healthy, token failure, line mismatch, subscription mismatch, no secret
Model	Default inheritance, dedicated agent binding, session override distinction
Media	Type/size bounds, inbound/outbound fixtures, provider error behavior
Rich events	Delivery/read/failure, reaction identity, replay, unsupported behavior
Live messaging	First contact, signed inbound, agent reply, receipt, restart, cleanup
Optional voice feature	Control lifecycle, stream auth/limits, both audio directions, consult, barge-in, session continuity, one-call enforcement, busy behavior, stale recovery, shutdown

External Dependencies and Decisions

1. Linq must decide whether a managed relay or outbound connection can remove
   public webhook provisioning for normal users. This is the best long-term
   answer to the largest setup blocker.
2. OpenClaw may need a public setup seam for safely configuring agent bindings,
   model selection, approval forwarding, and effective exec-policy inspection.
   Until then, prefer transparent guidance over plugin-owned global config hacks.
3. OpenClaw needs a public writable secret-provider contract before the plugin
   can store generated secrets in Vault. An owner-only file SecretRef is the
   fallback only after cross-platform contract validation.
4. Durable plugin state must use a public third-party plugin contract; do not
   depend on trusted-official-plugin-only SQLite APIs.
5. Linq has confirmed that unreleased FaceTime audio/video support can be
   enabled. Linq must enable it for the test account and provide the approved
   endpoint, identity-routing, lifecycle-event, and bidirectional-media contract
   before optional Phase 7 implementation begins. The plugin can own the
   single-call policy, model integration, audio adaptation, busy behavior, stale
   recovery, and transport hardening once that boundary is known.

Product Success Measures

• A fresh user reaches verified inbound-and-reply success without manually
  discovering a Gateway port, webhook path, or provider subscription API.
• Setup never reports inbound complete for a localhost/non-HTTPS target.
• The user can identify the active Linq agent/model and approval destination
  from setup or status output.
• A personal trusted-host user can choose guarded auto execution and complete
  remaining approvals in the originating Linq conversation.
• Fresh installs use pairing unless the operator explicitly chooses open access.
• Every advertised capability has live provider proof and matching status.
• FaceTime Audio remains invisible or clearly unsupported until its Phase 7
  contract gate succeeds.

Reference Sources

PR history and review evidence:

• Upgrade Linq core channel support #5
• Add automated Linq inbound setup #7
• Align Linq messaging with the OpenClaw channel runtime #10
• feat: extra configuration options for linq plugin RomneyDa/openclaw-linq-plugin#2

OpenClaw patterns:

• ../openclaw/extensions/sms/src/inbound.ts
• ../openclaw/extensions/sms/src/status.ts
• ../openclaw/extensions/voice-call/src/webhook/realtime-handler.ts
• ../openclaw/extensions/voice-call/src/media-stream.ts
• ../openclaw/extensions/discord/src/voice/realtime.ts
• ../openclaw/extensions/google-meet/src/realtime.ts
• ../openclaw/src/plugin-sdk/realtime-voice.ts

Linq public contract:

• https://docs.linqapp.com/
• https://docs.linqapp.com/guides/resources/faq/
• https://docs.linqapp.com/guides/webhooks/events/
• https://cdn.linqapp.com/openapi/linq-api-v3.yaml
• linq-team/linq-node@91ffdae
• linq-team/linq-go@f97d6e1

[RomneyDa]

Phase 1 is now implemented in #12, stacked on #10.

It removes the localhost webhook default, derives the local route from gateway.port, adds explicit public-ingress/outbound-only choices, requires an exact public HTTPS path before subscription creation, produces a readiness summary, updates ingress docs, and tightens package/schema hygiene. Live sandbox setup proof and cleanup are recorded on the PR. Phase 2 remains structured status and guided smoke diagnostics.