P0: Mac & iPhone readiness can appear ready before end-to-end broker runtime control works

[100yenadmin]

P0 Incident

Governing Priority 1 / P0 companion gate: #655 closes only with #662 under parent tracker #623. #655 owns exact-candidate end-to-end broker/runtime truth; #662 owns pristine-Mac self-contained onboarding. #480 remains the contract/safety dependency tracker. #657 is source behavior hardening, not release or customer-readiness closure.

The Mac & iPhone setup surface can show local readiness while the end-to-end customer experience is still unable to connect. In the David/Jane canary attempt, Workbench showed local Connector Ready and Permissions Granted, but customer Mac control still required manual repair of multiple server-side layers before support-control smoke became green.

Affected release

• Latest evaOS-GUI release observed: evaOS Workbench v2.1.32 beta
• Release tag: evaos-beta-v2.1.32-evaos-beta
• Published: 2026-07-10T22:39:11Z
• Active Mac-control tracker: Sprint: Mac Control Contract Unification + Matt-Style Reconciler #480
• Customer canary context: jackie-david / David Dorman setup attempt

Evidence summary

Observed missing or incomplete layers during setup included:

• Mac tailnet enrollment not completed at first.
• VM tailnet enrollment missing at first.
• Broker-owned private connector link not active at first.
• VM connector environment missing/stale before configure-vm repair.
• UI still conveyed local readiness in a way that could be misread as customer-usable readiness.

The customer-facing result was still Jane/WebChat failing Mac-control operations, despite local Workbench cards looking mostly ready.

Likely surface

• Mac & iPhone readiness model
• Guided Mac control setup state machine
• Broker grant verification
• VM-side connector readiness diagnostics
• Copy/status mapping around "Ready", "Setup needed", and "Connected"

Guardrails

• Preserve customer/admin diagnostics gating.
• Do not touch Mac connector contracts outside the exact readiness/proof path.
• Do not weaken permission checks for Accessibility or Screen Recording.
• Keep local Mac readiness distinct from end-to-end broker/runtime readiness.

Acceptance criteria

• The Mac & iPhone page distinguishes local connector readiness from end-to-end Jane/OpenClaw control readiness.
• The guided setup names the exact missing layer: Mac tailnet, VM tailnet, broker grant, ACL, VM connector env, or runtime tool path.
• The page does not present "Ready" as customer-usable readiness until a broker/runtime smoke has passed.
• Proof includes screenshots or logs for both a failed partial setup and a fully green end-to-end setup.

[coderabbitai]

🔗 Related PRs

#391 - Restore beta3 Mac pairing baseline [merged]
#403 - fix: recover Mac control installed app states [merged]
#416 - Fix Mac control connector-service ready reconciliation [merged]
#417 - Fix Mac pairing reconnect session gate [merged]
#465 - Fix Mac connector readiness probe [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[evaos-code-review-bot]

evaOS issue enrichment

Issue: #655 - P0: Mac & iPhone readiness can appear ready before end-to-end broker runtime control works
State: open; milestone: Workbench v2.1.36 Runtime Reliability

Related issues/PRs: #655, #662, #623, #480, #657.
Existing labels: bug, evaos, public-beta, ready-for-agent, area:broker, area:native-companion, kind:integration, blocked, release-train:runtime-reliability, priority:P0.
Suggested labels: security, support.
Suggested owners: none.

Related context

• P0: Mac & iPhone readiness can appear ready before end-to-end broker runtime control works #655 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.
• P0: Workbench fresh-Mac onboarding depends on unbundled Python and manual private-network setup #662 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.
• Roadmap: Workbench runtime reliability release train #623 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.
• Sprint: Mac Control Contract Unification + Matt-Style Reconciler #480 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.
• P0: require end-to-end proof for Mac control readiness #657 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.

Agent-start packet

Problem shape: P0: Mac & iPhone readiness can appear ready before end-to-end broker runtime control works - ## P0 Incident > Governing Priority 1 / P0 companion gate: #655 closes only with #662 under parent tracker #623. #655 owns exact-candidate end-to-end broker/runtime truth; #662 owns pristine-Mac self-contained
Product fit: Product/UX-sensitive issue; review against repo vision and user flow quality, not only technical P0/P1 risk.
Implementation wedge: Ship the smallest user-visible path or prototype that can be smoke-tested against the intended experience.

Build / borrow / buy scan:

• Build: identify the smallest implementation wedge that proves the issue without broad rollout.
• Borrow: inspect same-repo prior art, repo memory, GitNexus context, and allowlisted cross-repo examples first.
• Buy/use: run capped external OSS/library/API/current-market research with citations, observed dates, and why each source matters.
• Library choice: compare maintenance, API fit, license, bundle/runtime cost, and integration proof.

Candidate sources:

• VISION.md / repo policy / repo-memory.md / GitNexus packet.
• Same-repo issues and PRs referenced by issue metadata.
• Allowlisted cross-repo GitHub examples with direct issue/PR/repo URLs.
• External OSS repositories or library/API docs with freshness dates.
• Current market/product examples, capped and cited, only when they change implementation direction.

Acceptance criteria:

• Preserve and execute the issue's stated acceptance criteria.
• Include source citations for any external OSS/library/current-market claims.
• Keep issue-enrichment comments sticky and idempotent.
• Keep labels, owners, reviewers, and roadmap fields suggestion-only.

Proof plan:

• Focused unit/fixture test for the changed planner behavior.
• Dry-run issue-enrichment evidence packet before live comment posting.
• Redaction check for issue body, citations, and generated markdown.
• UX/product smoke or screenshot proof when implementation changes user flow.
• Contract or degraded-mode proof before runtime promotion.
• Dependency/license/API-fit note before adding or relying on a package.

Known traps:

• Do not treat related links as proof by themselves; each source needs a reason why it matters.
• Do not scan old issue backlogs or exceed repo-level enrichment throttles.
• External research must stay capped, cited, fresh-dated, and redacted.
• Technical severity alone can miss product/UX regressions; include product-manager review framing.

Non-goals:

• Do not auto-apply labels, owners, reviewers, roadmap fields, or milestones.
• Do not bulk-enrich old backlog issues from this planner output.
• Do not claim external market or OSS research was performed unless cited sources are present.

Context-source taxonomy:

• [enabled] vision_repo_policy_memory_gitnexus: Use repo vision, policy, memory, and GitNexus first before external research.
• [enabled] same_repo_issues_prs: Issue metadata contains same-repo references.
• [enabled] allowlisted_cross_repo_github: Triggered by issue class; keep to configured allowlist and source caps.
• [enabled] external_oss_examples: Use for build/borrow/buy precedent with citations and observed dates.
• [enabled] library_api_docs: Use when implementation may depend on a module, SDK, API, or framework choice.
• [enabled] current_market_examples: Use for product/UX/market positioning issues with freshness dates.
• [enabled] internal_mcp_docs: Use internal docs/MCP context when available; missing context is degraded, not blocking.

Validation suggestions

• Confirm owner, acceptance criteria, and validation evidence before implementation.

Triage gaps

• Owner or reviewer signal not detected in issue body.

No labels, owners, reviewers, or roadmap fields were changed by this bot.