P2 Follow-up: Complete AionCore v0.1.43 direct Mac-control doctor command gates

[100yenadmin]

AionCore v0.1.43 Direct Mac-Control Command Gates - Deferred Follow-Up

Date: 2026-07-09

Source Of Truth

• Parent tracker: 100yenadmin/evaOS-GUI#571
• AionCore evaluation issue: 100yenadmin/evaOS-GUI#407
• Superseded draft spike PR: 100yenadmin/evaOS-GUI#618
• Release-lane pin PR: 100yenadmin/evaOS-GUI#621
• Release-lane merge SHA: 19997d4a781084cd974ca55742a92c5cfc17a12a
• Current source pin: package.json aioncoreVersion=v0.1.43

Decision

Split and defer the remaining direct Mac-control doctor command-gate proof out of the v2.1.34 Upstream Runtime Sync release lane.

This is not an AionCore source-pin blocker for the v2.1.34 customer/runtime candidate because #621 merged the source pin and the exact candidate already passed:

• Workbench Functional Smoke
• live broker canary with explicit non-internal target
• Build and Release staging
• trusted local-signed DMG manifest registration
• RC canary
• distribution workflow
• signed installed-app Jackie-David app-wrapper proof

It is still a broader runtime/Mac-control proof gap and must remain tracked before claiming full AionCore runtime parity or full direct Mac-control release confidence.

Why Deferred

scripts/evaosMacControlDoctor.js is intentionally fail-closed and live. A complete run requires these command gates:

EVAOS_MAC_CONTROL_DOCTOR_LOCAL_OPENCLAW_CMD
EVAOS_MAC_CONTROL_DOCTOR_VM_OPENCLAW_CMD
EVAOS_MAC_CONTROL_DOCTOR_HERMES_CMD
EVAOS_MAC_CONTROL_DOCTOR_STOP_REVOKE_CMD
EVAOS_MAC_CONTROL_DOCTOR_KILL_SWITCH_CMD
EVAOS_MAC_CONTROL_DOCTOR_POST_RESET_CMD

The earlier signed installed-app doctor narrowed the visible-agent blocker to local OpenClaw runtime/config mismatch:

• PATH OpenClaw: OpenClaw 2026.7.1-beta.1
• selected proof runtime: OpenClaw 2026.6.11
• failure class: agent_cli_config_invalid

The v2.1.34 sprint guardrails prohibit touching Matt/local setup or broad runtime state just to make this proof pass. Running stop/revoke/kill-switch/post-reset gates without explicit approved commands would be an unsafe live mutation.

Follow-Up Scope

Future issue should provide or approve the exact command gates, then run:

EVAOS_MAC_CONTROL_DOCTOR_EXPECTED_HEAD=19997d4a781084cd974ca55742a92c5cfc17a12a npm run evaos:mac-control-doctor

The follow-up must prove:

• exact installed app path: /Applications/evaOS Workbench.app
• bundle id: com.evaos.workbench
• version/build: 2.1.31
• AionCore: v0.1.43
• support account and selected customer/target
• bridge /ready
• visible Workbench agent structured Mac-control tool results
• local OpenClaw command gate
• VM OpenClaw command gate
• Hermes command gate
• stop/revoke fail-closed behavior
• kill-switch fail-closed behavior
• post-reset recovery behavior

Guardrails

• Do not touch Matt's setup.
• Do not modify Mac connector contracts to make proof pass.
• Do not weaken broker/session, stop/revoke, kill-switch, or diagnostics gates.
• Do not store raw tokens, connector URLs, desktop sessions, or customer secrets in evidence.
• Do not claim upstream parity or direct Mac-control release readiness until the follow-up proof passes.

Evidence Already Available

• aioncore-v0.1.43/runtime-delta-audit.md
• aioncore-v0.1.43/runtime-spike-validation.md
• aioncore-v0.1.43/openclaw-version-mismatch-readonly.md
• customer-runtime-access/jackie-david-2026-07-08/workbench-signed-installed-app-proof-19997d4a.md
• customer-runtime-access/jackie-david-2026-07-08/workbench-release-distribution-19997d4a.md

[coderabbitai]

🔗 Related PRs

#391 - Restore beta3 Mac pairing baseline [merged]
#403 - fix: recover Mac control installed app states [merged]
#417 - Fix Mac pairing reconnect session gate [merged]
#449 - Fix legacy app stale owner proof path [merged]
#476 - Harden installed Mac-control proof scope [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: #622 - P2 Follow-up: Complete AionCore v0.1.43 direct Mac-control doctor command gates
State: open; milestone: Workbench v2.1.36 Runtime Reliability

Related issues/PRs: #621.
Existing labels: evaos, public-beta, ready-for-agent, area:shell, area:native-companion, area:release, risk:upstream-conflict, kind:integration, deferred-upstream, release-train:runtime-reliability.
Suggested labels: bug, security, docs, support.
Suggested owners: none.

Related context

• build(evaos): align aioncore runtime pin #621 - mentioned in issue metadata; inspect for dependency, duplicate, or prior-decision risk.

Agent-start packet

Problem shape: P2 Follow-up: Complete AionCore v0.1.43 direct Mac-control doctor command gates - # AionCore v0.1.43 Direct Mac-Control Command Gates - Deferred Follow-Up Date: 2026-07-09 ## Source Of Truth - Parent tracker: 100yenadmin/evaOS-GUI#571 - AionCore evaluation issue: 100yenadmin/evaOS-GUI#407 -
Product fit: Product/market issue; check vision fit, customer value, and whether external precedent can reduce time-to-market.
Implementation wedge: Start with a bounded adapter/contract or dry-run packet before changing live runtime behavior.

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:

• Add explicit acceptance criteria before implementation is considered done.
• 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.
• 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.