Revision 45 verification

Kimi K3-256k completed Pioneer verification with exit 0 and a nonempty report. It read revision 45 in full, verified all eight fixes, and reported no substantive findings in the reviewed changes and interactions. Its scope is the prior eight findings and affected interactions, building on the full revision 44 review. One stale acceptance-test label was noted as editorial only; it is retained so the normative text remains identical to the reviewed snapshot.

GLM-5.3 produced no report in round 32 (REVIEW_REPORT_MISSING, exit 1). It provides no current verdict; this is not two-model convergence. No model, provider, thinking level, or sandbox restrictions were changed to conceal that failure.

The published plan differs from the frozen revision 45 snapshot only in its review-status paragraph. No extra prompts, grant expiry, or central service requirements were added.

Reviewed IMPLEMENTATION-PLAN.md (revision 45, full read) against PREVIOUS-REVIEW.md and DISPOSITION.md, tracing each fix and its cross-section interactions.

Verification per finding

1. Provisioning/import scopes — Resolved. Section 16 now splits onboarding provisioning (exportable credential that creates fresh tunnels/Access apps/service tokens in the selected account/zone, explicitly not scoped to the source Mac's resource IDs) from steady-state management (per-Mac recorded resources, provider scoping where supported). The credential table distinguishes both tokens; provider-granularity disclosure and the feasibility fallback ("disclose the broader scope and obtain setup approval") are preserved. Section 2's export exclusions and "create fresh resource identities on import" are consistent; the encrypted export is the stated sole exception for management secrets.

2. Disabled new ADB grants — Resolved. Section 2 shared-defaults list no longer includes ADB enablement; it declares enablement "never an exportable or inheritable default," with every new pair starting disabled; export exclusions name "ADB pair grants or enabled state." Consistent with section 1's per-pair default-disabled statement and section 5's "pairing does not grant ADB access."

3. macOS floor — Resolved. Both stale references are re-anchored: the service-installation spike now says "Test macOS 26+ on Apple Silicon, matching the supported platform baseline," and section 17 says "Validate API availability and behavior on the supported macOS 26+ Apple Silicon baseline." No "macOS 14"/"provisional floor" text remains.

4. Authority-origin priority snapshots — Resolved per disposition. Section 19 makes the root authority originate an authenticated aggregate pending/clear attestation (transport relays, never originates), scoped to phone-eligible traffic ("local-only requests do not assert network contention"), bound to authority incarnation/sequence/freshness, with expiry/disconnect → unknown (not clear), automatic invalidation on root restart, and snapshot reconciliation on both root and transport restarts. Old-incarnation replay tests included. No lingering transport-owned lease or local-only pause.

5. Android single-active-session admission — Resolved per disposition (including the disposition's narrowing of the reported consequence). Section 19 defines atomic phone-side admission of one bridge session per device, Busy to competing Macs without disabling their grants, reservation spanning setup–teardown, no preemption, and old-stream reconciliation before release; restore path "keep[s] existing concurrency and session-admission limits." Multi-phone approval enrollment explicitly unaffected; the section 2 same-user caveat remains accurate (phone-side admission covers cross-Mac serialization, not a same-user host-key holder).

6. Gateway/tunnel release manifest — Resolved. Section 17's signed manifest now includes "bundled notification gateway/push sender, tunnel client" plus service registrations, with gateway/bridge/tunnel subject to the same protected-placement, quiescence, coordinated-activation, and minimum-build rules and post-update verification; gateway updates preserve durable recipient revisions and cannot restore revoked recipients — consistent with the section 16 control plane.

7. Opaque enrollment push tags — Resolved. Section 15 defines per-(Mac/account–Android enrollment) random routing tags registered via the authenticated pairing channel, containing no hostname/account/request data, hint-not-authority, never following push-supplied endpoints, per-enrollment coalescing, and cross-Mac isolation under a shared FCM token. Consistent with section 5's shared-token semantics (the tag is an opaque identifier, not request content).

8. Retention reference — Resolved. Section 19's bridge terminal-metadata line now cites "the section 12 audit-retention policy," and section 12 contains the configurable retention/storage-budget rules.

Settled UX constraints — Intact: no recurring biometric/per-install/per-session confirmations introduced, no arbitrary pair-grant expiry ("Connection challenges may expire, but the pair grant has no arbitrary expiry"), no central server/SaaS, legacy ADB fallback retained with its disclosures.

Minor editorial residue (not substantive): the section 19 acceptance list still says "Mac-local lease renewal" where the mechanism is now authority attestation refresh, but the tested semantics (renewal, expiry-without-clear, recovered clear) match the new text.

No substantive findings in the reviewed changes and interactions.

Revision 44 review disposition

Kimi completed the full review with eight findings. GLM failed with REVIEW_REPORT_MISSING and supplies no verdict.

1. Accepted: distinguish onboarding resource-creation credentials from steady-state per-Mac management scope. Preserve provider-granularity disclosure.
2. Accepted: ADB enablement is a non-exportable per-pair grant. Fresh pairs always start disabled.
3. Accepted: replace both stale macOS 14 references with the agreed macOS 26 baseline.
4. Accepted: authority-owned scoped priority state, automatic incarnation reconciliation, and no local-only network pause. A lost lease does not falsely imply clear.
5. Accepted the missing enforcement contract: Android atomically admits the already-intended single active bridge session. Competing Macs receive Busy; enabled grants remain intact. Concurrent installs do not inherently invalidate ADB response attribution, so that part of the reported consequence is overstated.
6. Accepted: include bundled gateway, tunnel client, and registrations in the signed manifest and activation checks.
7. Accepted: enrollment-scoped opaque push tags route wakes without exposing hostnames or polling the wrong Mac.
8. Accepted: correct the bridge retention reference to section 12.

These changes add no recurring consent, no arbitrary grant expiry, and no central server. Revision 45 awaits verification.

This attempt did not complete successfully. Its retained text is evidence only; it is not counted as a clean review.

GLM review attempt: incomplete

Pioneer 0.4.4, zai/glm-5.3, frozen revision 44.

The command exited 1 with REVIEW_REPORT_MISSING. Pi settled without a review report. No findings or clean verdict can be inferred.

Review complete. I read all 1,905 lines of IMPLEMENTATION-PLAN.md (revision 44) and traced the interactions among the revisions 38–44 features. Findings, severity-ranked:

1. HIGH — Exported provisioning credential contradicts the Cloudflare least-privilege contract IMPLEMENTATION-PLAN.md:140 promises the setup export includes "credentials needed to provision new machine-specific resources," and :134 requires that "an existing Mac must not remain necessary after another Mac is configured." But :1341 restricts the Cloudflare management token to "resource restrictions for the designated tunnel, Access application, and service tokens" and forbids "an unrestricted global account key," and :1345 has the controller enforce "the exact configured account, tunnel, approval application and hostname." Failure scenario: the user imports the bundle on Mac Studio; provisioning a new tunnel and Access application for that Mac requires creating resources outside Mac A's "designated tunnel," so a token scoped per :1341 is rejected and onboarding fails — or the token is actually zone/account-scoped, silently violating the stated least-privilege rule. Minimal correction: define a distinct, explicitly scoped provisioning credential (able to create new tunnels/Access applications/service tokens, nothing else) used only for export/import and per-Mac setup, separate from each Mac's steady-state resource-restricted token, and state both scopes.

2. HIGH — "ADB pair enablement" listed as an exportable shared default can silently pre-enable ADB :156 requires shared defaults in setup exports covering "idle timing, notifications, update checks, ADB pair enablement, connection behavior…," while :25 states "ADB is disabled by default for each Mac–Android pair" and :327 states "Pairing another Mac for approvals does not grant ADB access." Failure scenario: a setup export from an ADB-enabled Mac carries an enablement default; after import and fresh enrollment on the new Mac, the pair inherits "enabled" without the explicit per-pair opt-in, converting a security grant into an inherited preference — exactly the silent grant :327 forbids. Minimal correction: declare ADB pair enablement per-pair device state, never an exportable shared default; the only exportable value is "default = disabled," set solely by an explicit per-pair action after enrollment.

3. MEDIUM — macOS 14 provisional floor contradicts the macOS 26+ platform baseline :263 ("Start by testing macOS 14+; this is a provisional compatibility floor") and :1540 ("Validate the API availability on the provisional macOS 14 floor") survive from earlier revisions, but the revision-38+ baseline at :120 says "Support macOS 26 and later on Apple Silicon only… older macOS versions are outside the initial support scope." Failure scenario: feasibility spikes (SMAppService registration, XPC peer code-signing requirements, key custody) are executed and evidenced against macOS 14 — twelve major versions below the supported floor — producing invalid compatibility evidence, or implying an unstated macOS 14 support commitment. Minimal correction: re-anchor the provisional floor to macOS 26 (or explicitly label the macOS 14 work as historical API reconnaissance with no support or evidence-gate role).

4. MEDIUM — Approval-priority lease assigns pending-state authority to the wrong component, with no recovery path :1826 has "the unprivileged Mac approval transport" renew a pending/clear lease "while any Mac-originated approval is pending," and the bridge "stays paused until the approval transport recovers and attests that no request remains pending." Pending state is owned by the root authority (requests are memory-resident and cancelled on root restart, section 6; the transport "moves encrypted messages," section 3), and requests kept local under Present/active routing never traverse the transport (:1080). Failure scenarios: (a) the root authority restarts (cancelling all unconsumed requests) while the transport keeps renewing from its stale view — the bridge stays paused forever with nothing pending, since only the transport "recovering" can clear a state it cannot know; (b) a locally-kept pending request in Present mode pauses the bridge although it never contends for the phone link. Minimal correction: make the root authority the source of pending/clear attestations over authenticated IPC (transport may relay but not originate), invalidate the lease on root-authority restart, and scope "pending" to requests actually contending for the phone connection.

5. MEDIUM — No Android-side session-admission rule for concurrent bridges from multiple paired Macs :1828 limits the bridge to "a session to one enrolled phone from one Mac," and :1874 says "Keep existing concurrency and session-admission limits" — but no such limits are defined anywhere. Multi-Mac pairing with per-pair ADB enablement (:130, :315) permits two Macs to hold enabled pairs to the same phone, and each Mac's bridge keeps its own private operation ledger (:1828). Failure scenario: Mac A and Mac B both open sessions and run adb install to the same package concurrently; neither Mac's ledger can see the other's open operation, so a terminal "acknowledged success/failure" can be attributed to the wrong Mac's artifact, and the no-replay/no-reclassification guarantees become meaningless. Minimal correction: define the phone-side admission policy (e.g., one active bridge session per device with an explicit busy rejection, or explicit per-pair multiplexing) and state how same-package installs across Macs are serialized or rejected.

6. MEDIUM — The bundled notification gateway is missing from the signed release manifest :1588 enumerates "app, helper, GUI adapter, transport, administrative setup controller, optional bridge endpoint, and bridge command builds." The revision-44 gateway ("Each Mac runs its own bundled notification gateway," :1368; "a separate component," :1493; the app's "push sender," :132) is absent. Failure scenario: gateway builds evade minimum-build floors, anti-rollback at activation, and the quiescence/coordinated-activation rules; an older signed gateway binary keeps running after a floor raise, or is replaced live outside the update-drain contract. Minimal correction: add the gateway and its service registration to the release manifest and to the section 17 activation/floor rules.

7. LOW — Push wake identifier is not enrollment-scoped under multi-Mac :339/:1229 define push payloads as "only opaque wake identifiers," while one shared FCM token serves several enrollments (:321) and each Mac runs its own gateway (:1368). Nothing defines how the phone learns which enrolled Mac to fetch from after a wake; :1255 ("fetch the complete pending set") implies polling every enrolled Mac per wake, which is unstated and contends with the bounded fetch window for short-lived 1Password prompts. Failure scenario: a wake triggered by Mac A arrives while the app holds a live connection only to Mac B; the app fetches from the wrong or last-used Mac and the actionable request is invisible until an unrelated sync. Minimal correction: define the wake payload as carrying an enrollment-scoped opaque tag (meaningful only to the app), or explicitly mandate fetch-all-enrollments on every wake with per-enrollment notification scoping.

8. LOW — Section 19 cites a nonexistent retention policy :1828 states bridge "minimal terminal event metadata follows the section 10 audit-retention policy." Section 10 is delivery stages and acceptance gates; it contains no retention policy. Retention is defined in section 12 ("Retention and replay safety"). Failure scenario: implementers find no defined duration/storage budget for bridge terminal events, so they are either never pruned or pruned under ad-hoc rules inconsistent with the audit log. Minimal correction: reference section 12's configurable retention and storage-budget rules.

No other substantive contradictions found in the revisions 38–44 interaction surface; the explicit user choices (no recurring prompts, no arbitrary pair expiry, biometric-free once-decisions, single-user homelab) are consistently respected throughout.

Round 31 disposition: revision 37 ADB bridge

Pioneer zai/glm-5.3 and kimi-code/k3-256k both completed focused exact-text reviews of the same revision 37 changed-clause bundle, with exit 0 and nonempty reports (round-31-glm.md, round-31-kimi.md). Neither found a substantive flaw in the serialized install ledger, atomic audit events, retention, later package observations, or admission-policy granularity.

Both noted a minor wording mismatch: the admission text mentions per-session versus per-install confirmation while the policy also offers unattended Ready mode. This is an unresolved policy choice, not an implicit adoption of either option. Both also noted that refused concurrent install attempts do not appear in the start/terminal audit; the accepted audit scope currently covers admitted operations, and the implementation should decide whether to add refusal metadata when defining operational diagnostics. No change to the reviewed mechanism was required.

Coverage is limited to the supplied section 19 clauses. Earlier K3 and Opus full-plan plus cumulative GLM coverage established revision 29 approval-plan convergence; the new ADB bridge has not received another full-plan convergence claim. Android 17 service/discovery behavior, Access WebSockets, local ADB client isolation, and phone admission UX remain implementation gates.

I reviewed all five changed clauses (lines 1674, 1676, 1678, 1692, 1702) against the five review areas.

Verdict: clean of substantive flaws

Serialized operation ledger (1676) — Sound. Single-owner service with commands submitting rather than writing (1676); the second-open refusal, open-record write, and dispatch ordering are atomic ("under one exclusive transaction ... before dispatch"); startup recovery closes orphans "before serving status or admitting an install" so no stale open state is observable; every crash window (before dispatch, after dispatch, after response before terminal commit) terminates in a conservative outcome unknown. Per-phone refusal scope is consistent with the one-phone session limit (1676).

Atomic audit events (1676) — Sound. Start event is in the same transaction as the open record; the terminal-event-same-transaction rule is stated generally and covers every enumerated closer (acknowledged success/failure, lost/interrupted/timed-out/unauthenticated/malformed, teardown at 1678, startup recovery). Losing concurrent closers write nothing, and late responses cannot reclassify — matching the 1702 race tests (teardown×response, timeout×late response).

Retention (1676, 1678) — Sound. Open records never expire; closure enables bounded count/time retention of detailed fields while minimal terminal metadata follows §10; the two independent retention clocks are handled at every combination — detailed-expired/outcome-retained yields "comparison is unavailable" (1678), outcome-expired displays nothing (1676). Expiry provably cannot affect an active operation or trigger a reinstall, consistent with "never runs automatically as a retry" (1678).

Later observation (1678) — Sound. Mandatory read before any later same-package install including within a session; observation is displayed beside, never merged into, the terminal record; version/signing match is correctly not treated as artifact-equality proof; verification unavailability must be surfaced; a new deploy gets a new operation ID and no downgrade/retry advice on mismatch. Matches the 1702 test matrix (observed expected state, unchanged state, third external state, byte-identical reinstall, unavailable verification, expired evidence).

Admission granularity (1692, 1678) — Sound. Three explicit policies, granularity uniform across first and subsequent installs, no policy assumed, one to be selected and tested (1692), with 1678 requiring the confirmation rule be defined and applied to every deploy.

Minor observations (non-substantive, for wording only)

1. 1678 vs 1692 — admission enumeration mismatch. 1678 frames the choice as binary ("whether confirmation applies per session or per install"), while 1692 offers a third option (unattended while Ready mode is active). Read contextually, 1678 governs confirmation granularity only when confirmation is chosen, so it is vacuous rather than contradictory under the unattended policy — but harmonizing the wording would remove a strict-reading conflict.
2. 1676 — refused installs leave no audit trace. A refused second open install produces neither start nor terminal event. This is consistent with the stated audit scope ("no ... replay can omit a start or terminal transition"), so it is within spec, but denials are untraceable if that ever matters operationally.
3. 1678 — observation display is only specified relative to a retained earlier unknown outcome. Behavior when the prior outcome was acknowledged (or when multiple prior terminals for the same package exist) is unspecified; trivially resolvable, no correctness impact.

No substantive flaws found in the five review areas.

Code Review — Remozio Section 19, Revision 37 (changed clauses only)

Reviewed lines 1674, 1676, 1678, 1692, 1702 in REVIEW-BUNDLE.md against the five scoped areas. Sections 5 and 10 are referenced but not supplied, so cross-section consistency with those cannot be verified.

Scoped mechanisms verified sound

Serialized operation ledger (1676): Single-writer service, check-and-insert of the open record under one exclusive transaction (no TOCTOU on "refuses a second open install"), crash windows explicitly covered (crash after open before dispatch → unknown via startup sweep; startup sweep runs before serving status or admitting installs), conditional close with "losing concurrent closers write nothing" gives correct CAS semantics for response/timeout/teardown races — consistent with the 1702 test list ("teardown racing a response, timeout racing a late response").

Atomic audit events (1676): Start event is committed in the same transaction as the open record before dispatch; terminal event in the same transaction as the terminal transition; orphan-sweep closures carry their audit event in the same transaction; terminal states are unreclassifiable, matching 1702's "No losing event, later observation, or later install may reclassify a terminal outcome."

Retention (1676): Open records never expire; bounded count/time retention only on post-closure detail fields; expiry cannot mutate an active operation or trigger an install; the "comparison unavailable" display path in 1678 correctly anticipates detail-field expiry while the terminal event survives.

Later observation (1678): Independent read on next session and before any same-package reinstall (even within a session); version/signing match correctly not treated as artifact equality; unknowns are never resolved by later deploys or auto-retried; no downgrade/retry advice on divergence — internally consistent and consistent with 1674's "never infer install success from ... later package state."

Findings (minor; no substantive defect found)

1. Line 1678 vs. line 1692 — admission-granularity enumeration mismatch (low). 1678 requires the pending admission choice to "define whether confirmation applies per session or per install," enumerating only two granularities, while 1692 explicitly offers a third: "permit unattended installs while Ready mode is active." If the unattended option is selected, 1678's directive has no antecedent — there is no confirmation to scope per-session or per-install. The clauses don't contradict (1678's "apply that chosen rule to every deploy" degrades gracefully), but the scoped admission-granularity text is not self-consistent in its enumeration. Suggest 1678 acknowledge the unattended option or defer entirely to 1692's list.

2. Line 1676 — refused admission attempts are outside the audit model (low). The ledger writes a start audit event only for admitted operations; a refused "second open install" attempt leaves no record, even though the ledger is designated "the bridge audit source" such that no replay "can omit a start or terminal transition." A rejected concurrent-install attempt is a security-relevant event (it may indicate a racing local process — a scenario 1702 explicitly tests). If refusal auditing is intentionally out of scope, that should be stated; otherwise the claim of ledger-as-complete-audit-source is slightly overbroad.

Otherwise clean

No substantive flaws found in the serialization invariants, transaction atomicity of start/terminal audit events, retention semantics, later-observation rules, or the per-session/per-install granularity handling as drafted. Dependencies on unsupplied sections (5 enrollment, 10 audit retention, "same-user Mac exposure described above") could not be validated.

Round 30 disposition: revision 36 ADB bridge

Both Pioneer models completed focused exact-text reviews: round-30-glm.md and round-30-kimi.md. They agreed that the Mac-side operation ledger needed an atomic conditional terminal close, a single serialized admission owner, and an audit start event coupled to the pre-dispatch record. They also found that replay could be too late, open records could expire, detailed evidence could disappear before later comparisons, late/malformed responses were underspecified, and the phone admission choice did not say whether it applied per session or per install. GLM identified missing crash-window acceptance cases.

Revision 37 gives one bridge service ownership of the operation ledger. It serializes admission and allows one open install per phone; writes the open record and start audit event before dispatch in one transaction; closes terminal state and audit event with a conditional transaction; closes orphaned open operations before serving status after restart; and classifies malformed or late responses conservatively. Open records do not expire. Closed operation detail has bounded retention; minimal terminal metadata follows the section 10 audit-retention policy. Later package observations are displayed without changing a historical command result. The pending phone admission decision now explicitly includes per-session versus per-install granularity, applied consistently to subsequent installs. Acceptance adds the missing crash and race windows. Focused review of revision 37 remains pending.

Review: Remozio section 19, revision 36 changed clauses

Reviewed lines 1674, 1676, 1678, 1692, 1702 of REVIEW-BUNDLE.md (1677 is blank). Verdict: not clean — 6 findings (1 high, 3 medium, 2 low), mapped to the five requested areas. No files were modified.

Findings

F1 — HIGH — Evidence retention scope can evict correctness-critical records (1676, evidence retention)

1676: "Retain detailed operational evidence only within a bounded count and period; after expiry, keep the durable unknown status and package/operation identifiers…"

The retention clause demonstrably reaches into the operational-state store, not just logs ("after expiry, keep the durable unknown status…" implies state detail is deleted while status+IDs survive). Two hazards follow:

1. Open record expiry: a stuck-open operation (e.g., Mac asleep mid-install) that outlives the retention period loses its digest/version/signing identity — or under a small bounded count, the record itself — before the startup orphan-close ("close any orphaned open install operation as unknown", 1676) can write a correct terminal transition and audit event.
2. Replay degradation: after expiry, "durable terminal state" is reduced to status + package/operation identifiers, so "replay the missing audit event from durable terminal state before admission" (1676) can only reconstruct an impoverished event — audit content becomes dependent on when replay fires. It is also unstated whether metadata-only audit events are themselves "detailed operational evidence" subject to the bound; if they expire, replay must regenerate them forever from state the same clause permits to expire.

Fix direction: exempt open operations and unaudited terminal records from eviction; state whether audit events are retention-exempt; require replayed events to preserve original transition metadata.

F2 — MEDIUM — Start audit event has no atomicity or replay requirement (1676, audit replay / Mac crash)

1676: "Persist each terminal transition and its metadata-only audit event atomically or replay the missing audit event from durable terminal state before admission."

The atomic-or-replay guarantee covers only terminal transitions. Line 1702 requires "metadata-only start/stop audit," but nothing ties the start audit event atomically to the pre-dispatch durable open record, nor requires replaying it from that record. A crash between dispatch and the start-audit write yields an audit stream containing a terminal unknown event with no matching start event — indistinguishable from tampering — and no clause requires reconstructing it, even though the open record (1676) holds all the metadata needed.

F3 — MEDIUM — Late install response can textually reclassify a terminal outcome (1676/1678/1702, teardown/response race)

1676: "A completed, authenticated ADB install response closes that operation as acknowledged success or acknowledged failure…" vs. "The first durable terminal outcome wins; later teardown, package observations and installs never reclassify it."

Scenario: the response times out → the operation is durably closed as unknown; the authenticated response then arrives late on the still-open socket. The first sentence instructs closing "that operation" as acknowledged; the never-reclassify enumeration lists teardown, package observations, and installs — not late responses — in both 1676 and the 1702 mirror ("no later observation or install may reclassify"). Only the header "first durable terminal outcome wins" arguably saves it, and no serialization mechanism (single-writer/CAS on terminal transitions) is specified for the concurrent teardown-unknown vs. response-acknowledged write race. Line 1678 covers only the benign ordering ("an earlier acknowledged response remains acknowledged"). 1702 tests "teardown racing an acknowledged response" but not response-vs-timeout. Add "late response" to the non-reclassifying list and require first-writer-wins on terminal writes.

F4 — MEDIUM — Subsequent-deploy admission conflates install admission with session admission (1678 + 1692, subsequent install admission policy)

1678: "A user-requested subsequent deploy follows whichever phone session-admission policy is selected below" → 1692: "either require a phone confirmation for each Mac request, or permit unattended starts while Ready mode is active…"

1692's policy governs session admission ("unattended starts"). A deploy dispatched inside an already-admitted, active session is not a session-admission event, so "follows the session-admission policy" is undefined for it: under the confirmation policy, "each Mac request" is ambiguous between per-session and per-install confirmation. Since 1678 makes this cross-reference the sole admission rule for subsequent deploys after an unknown outcome, the conflation is substantive, not editorial. Specify confirmation-per-session vs. confirmation-per-install.

F5 — LOW/MEDIUM — Audit replay is admission-gated only; missing events can persist indefinitely (1676, audit replay)

1676: "…or replay the missing audit event from durable terminal state before admission."

Under the replay option (terminal state durable, audit write lost to a crash), the missing event is reconstructed only when the next install is admitted. If no further install ever runs, the audit trail stays permanently incomplete — there is no startup-time or periodic reconciliation requirement. Additionally, nothing requires the durable terminal state to retain a transition timestamp, so a replayed event may carry a fabricated one.

F6 — LOW — Acceptance-test gaps in crash windows (1702, terminal status after Mac crash)

1702 covers "a Mac crash after dispatch" and "teardown racing an acknowledged response," but not: (a) crash in the window between receiving an authenticated response and persisting its terminal transition (must yield unknown, never acknowledged); (b) crash between the pre-dispatch durable store and actual dispatch (orphan record for a never-sent install must still close as unknown). Both are normatively covered by first-durable-wins + startup orphan-close (1676), but neither window is exercised by the stated tests.

Areas confirmed sound

• Terminal status after Mac crash (1676, 1678): pre-dispatch durable open record; acknowledged-only-when-durable; startup orphan-close before any new install; current-state observation never reclassifies — internally consistent, apart from F6's test gaps.
• Teardown ordering (1678): "close as unknown only if it is still open; an earlier acknowledged response remains acknowledged" is correct for the covered ordering (defect is the uncovered one, F3).
• Unknown-outcome epistemics (1674, 1678): never inferring success from dropped sockets or later package state; exact-match-proves-only-current-state; no auto downgrade/retry advice; verification-unavailable disclosure — all sound and mutually consistent.
• Priority lease / approval separation (1674): pause-without-clear recovery and no payload leakage are coherent; 1702 tests them.

Overall: 6 findings; F1 should be resolved before implementation.

Code Review — Remozio §19 rev 36 changed clauses

Reviewed lines 1674, 1676, 1678, 1692, 1702 against the five focus areas. Findings below, ordered by severity.

Finding 1 — Teardown/response race: "first durable outcome wins" has no mandated serialization mechanism (lines 1676, 1678)

Line 1678: "At teardown, close an install as unknown only if it is still open; an earlier acknowledged response remains acknowledged." Line 1676: "The first durable terminal outcome wins."

The close is specified as check-then-act ("only if it is still open"), and there are at least two writers of the Mac-resident durable state: the response-processing path (line 1676: "A completed, authenticated ADB install response closes that operation...") and the teardown/startup orphan-close path. Line 1676's atomicity requirement binds only the transition + its audit event as a pair ("Persist each terminal transition and its metadata-only audit event atomically") — it does not require the competing closes themselves to be mutually exclusive (single-writer, compare-and-set, or conditional update). Without that, both writers can observe "open" and durably write different terminal outcomes, and the subsequent audit replay (which replays "from durable terminal state") could reconstruct an audit event for the loser. The acceptance test in line 1702 ("teardown racing an acknowledged response") is not deterministically passable until the clause mandates an atomic conditional close.

Fix direction: require the terminal close to be a single atomic compare-and-set on the operation record ("close as X iff state == open"), with the loser forbidden from writing.

Finding 2 — Evidence retention expiry contradicts audit-replay and later-verification obligations (lines 1676 vs. 1678)

Line 1676 caps retention: "after expiry, keep the durable unknown status and package/operation identifiers." Two conflicts:

• Replay vs. expiry: the audit-replay fallback ("replay the missing audit event from durable terminal state before admission") is lazy — it only executes when a later install is admitted. If detailed evidence (expected signing identity, version, artifact digest, timestamps) expires before any subsequent admission, the durable remainder (status + identifiers only) is insufficient to reconstruct the metadata-only audit event, voiding the "atomically or replay" guarantee precisely in the crash case it exists for.
• Line 1678's unconditional comparison: "before each later install to the same package... independently read the currently installed package metadata" and compare against "the requested artifact" — impossible once the expected digest/version has been evicted. Line 1678's only degradation path is "If package verification is unavailable, say so," which addresses platform unavailability, not self-inflicted expiry. The two clauses never reconcile the post-expiry side-by-side display.

Fix direction: pin the fields required for audit replay and for the line-1678 comparison (expected version, signing identity, digest) to the lifetime of the durable terminal status, or explicitly specify degraded behavior when they are gone.

Finding 3 — Admission is not serialized; the orphan-close gate is itself a check-then-act race (line 1676)

"On command/service startup, first close any orphaned open install operation as unknown before another install can start." Nothing grants mutual exclusion between concurrently starting command/service instances on the same Mac: two processes can both observe no orphan (or both close the same orphan) and both admit installs, producing two open operations. Relatedly, the clause gates only startup; it does not state that a new install is refused while a non-orphaned operation is still open within a running session. The "one open operation" invariant the rest of the design assumes (first-outcome-wins, side-by-side display) is therefore unenforced at admission.

Fix direction: require an admission lock or a single-owner service, and explicitly refuse (or queue) installs while any operation is open.

Finding 4 — Audit replay is lazy and does not cover the start event (lines 1676, 1702)

Two gaps in "replay the missing audit event from durable terminal state before admission":

• Laziness: if no further install is ever admitted, the audit log permanently lacks the terminal event. Audit completeness becomes conditional on future user activity; any audit review conducted before the next admission silently shows a gap. (Compounds with Finding 2's expiry problem.)
• Scope: replay is keyed on "durable terminal state" and replays "the missing audit event" (the terminal one). A crash after dispatch but before the start audit event is persisted leaves a missing start event with no replay path — yet line 1702 requires verifying "metadata-only start/stop audit." The open-operation store is not required to be atomic with its start audit event, only terminal transitions are.

Fix direction: persist the open record and start audit event atomically (or extend replay to synthesize both from the durable record), and replay on service startup/recovery rather than only at next admission.

Finding 5 — Unauthenticated or malformed install response is unclassified (line 1676)

Line 1676 closes an operation on "a completed, authenticated ADB install response" (acknowledged success/failure) or if the response is "lost, interrupted, or times out" (unknown). A response that arrives but fails authentication or fails to parse matches neither branch. Given the hostile-adjacent scenarios line 1702 anticipates (racing local processes, same-user key holders), this gap should be closed: an unauthenticated/malformed response must be treated as unknown (or explicitly defined otherwise).

Finding 6 — Minor: retention clause preserves only unknown statuses (line 1676)

"after expiry, keep the durable unknown status..." — acknowledged success/failure terminal states appear fully evictable under the bounded count/period. After eviction, "the first durable terminal outcome wins" has no durable record for those operations, and startup logic cannot distinguish "no prior operation" from "evicted acknowledged operation." Likely benign, but the clause should state that terminal status (of any kind) plus identifiers is the non-evictable floor, not unknown-status alone.

Areas reviewed with no substantive flaw found

• Terminal status after Mac crash (core rule): storing the open operation durably before dispatch, closing orphans as unknown at startup, and refusing to infer success from dropped socket or later package state (1674, 1676) is sound and conservative — including the case where pm install completes phone-side after the Mac dies.
• Never-reclassify rule (1676/1678) and the refusal to treat version/signing match as artifact-equality proof absent a trustworthy platform digest (1678) are correctly stated.
• Session-admission policy deferral (1692) is an explicit, testable open decision wired consistently into 1678 and 1702, not a contradiction.
• Self-update teardown reporting unknown (1674, 1678) is conservative-by-design; losing an in-flight success response when the bridge-hosting app dies is acceptable under the stated policy once Finding 1's atomic close is mandated.

Summary: six findings — the teardown/response race lacks a mandated atomic conditional close (F1); retention expiry breaks both the audit-replay fallback and the mandatory pre-install comparison (F2); admission lacks serialization (F3); audit replay is lazy and start-event-blind (F4); unauthenticated responses are unclassified (F5); and the retention floor is defined only for unknown statuses (F6).

Round 29 disposition: revision 35 ADB bridge

Pioneer Kimi K3 completed a focused section 19 review (round-29-kimi.md) and found three lifecycle gaps. Pioneer GLM-5.3's attempt ended without a final report (REVIEW_REPORT_MISSING) and is not counted as a clean review.

Revision 36 persists an open operation before dispatch and closes orphaned operations as unknown on command/service startup before new installs. Terminal state and the metadata-only audit event are committed together or the event is replayed from durable state before admission. The first durable terminal state wins, so teardown cannot overwrite an already acknowledged result. A later user-requested deploy follows the as-yet-unselected phone admission policy rather than assuming an exemption from phone confirmation. Acceptance now covers crash, audit replay, and teardown/response races. Focused follow-up reviews are pending.

Code Review — Remozio Section 19, Revision 35

Scope reviewed: interrupted-install outcome handling, evidence lifecycle, later package observations, same-session subsequent installs, self-update. Three findings.

Finding 1: No reconciliation path for operations orphaned by Mac-side failure

References: REVIEW-BUNDLE.md lines 1674, 1676

Every outcome-classification path requires the Mac command to survive until it observes the result:

"If the response is lost, interrupted, or times out, close the operation as outcome unknown and write that status durably to the metadata-only audit" (1676)

If the Mac command process crashes, is killed, or the Mac sleeps/reboots/powers off mid-install, the pre-install record (operation ID, package ID, expected signing identity, version, artifact digest) is left in an implicit third state: never acknowledged, never closed as unknown, and no durable unknown status is ever written to the audit. The later-observation rules (1678: "show the observed state and the earlier unknown outcome side by side") key off an unknown outcome, so they do not apply to an orphaned open operation either — a subsequent install to the same package would have no classified historical outcome to display or protect. The self-update teardown rule (1678) covers only phone-side termination, not Mac-side death.

The bundle needs a reconciliation rule: on command startup or next session, any stored operation lacking a terminal outcome must be closed as outcome unknown and written durably to the audit before any new install proceeds.

Finding 2: Unconditional "mark unknown at teardown" can reclassify an already-acknowledged self-update

References: REVIEW-BUNDLE.md lines 1676, 1678

Line 1678 states unconditionally:

"Updating the Remozio app that hosts this bridge terminates its own foreground service and connection… Mark that install unknown at teardown."

But teardown is not ordered relative to response delivery. The phone-side process is killed when Android replaces the package, and the ADB install success response travels back through the same relay the dying process carries. Depending on timing, the Mac may receive the "completed, authenticated ADB install success response" and close the operation as acknowledged (1676) before the teardown signal arrives. An unconditional teardown marking would then overwrite a terminal acknowledged outcome — contradicting 1676's terminal-state semantics and the bundle's own core principle that no later event changes a historical command outcome (1676, 1702). If teardown wins the race instead, unknown is correct.

The plan should state an ordering rule (e.g., the first recorded terminal outcome wins; teardown only closes operations still open) rather than mandating unknown at teardown regardless of prior acknowledgment.

Finding 3: Same-session subsequent deploys bypass a prompt model that the deferred admission policy may require

References: REVIEW-BUNDLE.md lines 1678, 1692

Line 1678 hard-codes:

"A user-requested subsequent deploy can proceed without another approval prompt"

while line 1692 explicitly defers the admission policy:

"either require a phone confirmation for each Mac request, or permit unattended starts while Ready mode is active… Neither policy is assumed by this plan; select and test one before implementation."

These interact badly. If the selected policy is per-request phone confirmation and "each Mac request" encompasses install requests (not just session starts), then 1678's blanket exemption for subsequent deploys contradicts it. The phrase "another approval prompt" also presupposes a first-install prompt, yet the plan elsewhere insists ADB operations never involve Remozio approvals (1672, 1674), leaving unspecified which prompt, if any, gates the first deploy in a session. The interaction between the not-yet-selected admission policy and the same-session subsequent-install exemption must be resolved before the exemption can be implemented as written.

Areas found clean

• Evidence lifecycle (1676): bounded count/period retention, durable unknown status with package/operation identifiers after expiry, and the explicit "do not imply that later verification remains possible" are internally consistent and covered by acceptance tests (1702).
• Later package observations (1678): independent re-read before each same-package install including within a session, side-by-side display, refusal to treat version/signing match as artifact-equality proof, "current state, not which command produced it," and the unavailable-verification disclosure are sound.
• Retry discipline (1678): new operation ID per deploy, never resolving the earlier operation, never auto-retrying an unknown command, and no automatic downgrade/retry advice on divergent or externally changed state are correctly specified.

Round 28 disposition: revision 34 ADB bridge

Both requested Pioneer models completed focused reviews of the same exact-text section 19 revision 34 bundle. Reports: round-28-glm.md and round-28-kimi.md. Neither was clean.

They found that an install retry within the same ADB session could precede reconciliation; old records could later be misattributed to a new install; byte-identical reinstalls matched contradictory verdicts; the installed artifact digest and update marker were treated as stronger evidence than the plan justified; and time-bounded evidence could disappear before a phone returned online. Kimi also identified a prior-package/changed-marker case with no defined branch. GLM noted that a restarted companion could at least report its own current version.

Revision 35 removes retrospective command-outcome inference. A complete authenticated ADB success response is the only success acknowledgment. A lost response becomes a durable historical outcome unknown. A later package read is labeled as current state only and cannot rewrite that outcome; same-session and subsequent installs get new operation IDs. Detailed evidence has bounded retention, while the minimal unknown audit status remains. Any user-initiated later deployment may proceed without a new approval prompt, but it is never an automatic retry of the unknown command. The restarted companion may report its own version as a current-state observation. A focused follow-up review is pending.

Findings on section 19, rev 34 (references are bundle line numbers; all flaws are in the reconciliation design at 1676 unless noted):

F1 — Reconciliation gate is keyed to session start, so same-session retries bypass it (1676). "On any new paired ADB session, automatically reconcile each interrupted or timed-out operation for a package before another install to that package." An interrupted or timed-out install (1674 explicitly lists timeouts) can be retried within the same paired session, because the gate fires only at session start. The retry's artifact lands before the earlier operation is ever reconciled; at the next session, the "current package matches the expected state" branch then reports the earlier operation desired package state verified — evidence produced entirely by the later install, violating the same paragraph's "Never use a later install's artifact as evidence for the earlier operation." The gate must key on install attempts to that package, not on session boundaries. It is also unstated whether an inconclusive (unknown) reconciliation blocks the subsequent install.

F2 — No closure/supersession lifecycle for operation records (1676). Records persist after a reconciliation attempt ("retain operation outcome unknown"), but nothing marks an operation reconciled-once or supersedes it when a later install to the package succeeds. Consequences: (a) stale interrupted operations are re-reconciled on every session for the full retention window; (b) after any later successful install of the same artifact, the verified branch retroactively resolves the earlier interrupted operation — the exact misattribution the paragraph forbids. Conversely, if records are deleted after a first inconclusive attempt, the standing "unknown" and its retry guidance silently vanish. Either lifecycle choice breaks something; the plan specifies neither.

F3 — Contradictory branch conditions for the byte-identical reinstall with unchanged state (1676; acceptance case at 1700). When expected and prior states are identical and the package and update marker are unchanged, two rules match simultaneously: "If the current package and update marker still match the recorded prior state, report requested state not applied with retry guidance" and "If expected and prior states were identical … retain operation outcome unknown." Precedence is unstated. Under a literal order-of-appearance reading, the identical reinstall is reported "requested state not applied" — a false state claim, since the requested state (identical to prior) is present, and it contradicts the paragraph's own rule that identical operations stay unknown. The not-applied branch needs an explicit expected ≠ prior condition. (Note the marker evidence here actually supports "not applied": an unchanged update marker proves nothing installed an update since the prior observation, so the categorical unknown for the identical case also discards usable evidence.)

F4 — The decisive "match" is unspecified and the stored digest may be unobservable, admitting third-party/rebuild misattribution (1676). The stored evidence includes signing identity, version, and artifact digest, but the plan never states which fields "the current package matches the expected state" compares, and the feasibility/acceptance program (1698–1700) never establishes that an installed artifact digest is observable via ADB package state at all (version, signing identity, and lastUpdateTime are; base.apk digest reads are not guaranteed). If the match is version-plus-signing only, a third-party delivery or a developer rebuild with the same versionCode and key but different digest yields a false desired package state verified for the interrupted operation — the third-party-update case the design guards against only in the "current differs from both" branch ("a different state may reflect an external update").

F5 — Bounded retention is not coordinated with the reconciliation obligation (1674, 1676). Records live in "operational state with bounded retention," but unreconciled interrupted-install records can age out before any new paired session occurs — notably in the self-update case, where restoring Ready mode (the prerequisite for a new session) is itself "a pending user decision" (1676). Expiry silently deletes the only evidence, the before-install gate never triggers, and the 1674 promise of "outcome unknown until independent package-state verification" becomes permanently unsatisfiable with no user-visible terminal outcome. Retention must hold unreconciled operations until reconciled, or expiry must surface a permanent unknown.

F6 (minor) — The self-update outcome ignores available phone-side evidence (1674, 1676). The self-deployed companion's install is marked unknown at teardown and reconciles only on a new paired ADB session, which additionally requires a human to restore Ready mode. Yet the restarted app can directly attest its own installed version; no phone-side or user-facing resolution path exists, so the one outcome most trivially verifiable stays unknown indefinitely pending user action.

Not clean; six findings, F1–F4 substantive.

Code Review — Remozio Section 19, Revision 34

Scope: interrupted-install outcome reconciliation logic (lines 1674, 1676, 1700). Four substantive findings.

Finding 1 — Reconciliation rule set has an unmatched case for third-party rollback/reinstall of the prior version

Reference: line 1676 (the three reconciliation branches).

The branches are:

1. expected ≠ prior, current == expected → desired package state verified
2. current package and update marker == prior → requested state not applied + retry guidance
3. expected == prior, or current differs from both → retain unknown

The plan stores "package state and update marker" as distinct items (1676: "the previously observed package state and update marker"). Consider a third-party rollback or uninstall/reinstall that restores the same prior package version after the interrupted operation: the current package state matches the recorded prior state, but the update marker (e.g., install/update timestamp) necessarily differs. This evidence tuple matches no branch:

• Branch 2 fails (marker does not match prior).
• Branch 3 fails ("current package differs from both" is false — it matches prior).
• Branch 1 fails by construction.

The outcome is undefined, contradicting the plan's own guarantee that "on any new paired ADB session, [the Mac] automatically reconcile[s] each interrupted or timed-out operation for a package before another install to that package" (1676). The only reading that closes the gap — treating the marker as part of "package state" — makes branch 2's separate "and update marker" clause redundant. Either way the specification is internally inconsistent, and the uncovered case is precisely a third-party-update scenario the section claims to handle.

Finding 2 — Byte-identical reinstall: branches 2 and 3 conflict, with no defined precedence

Reference: line 1676; acceptance requirement at line 1700 ("Cover … byte-identical reinstall").

For a byte-identical reinstall, expected state == prior state. If that reinstall was interrupted and not applied, the current package and marker still match the recorded prior state, so:

• Branch 2 fires → requested state not applied with retry guidance.
• Branch 3 fires ("If expected and prior states were identical … retain operation outcome unknown").

The same evidence produces two contradictory reports, and the plan gives no ordering or precedence between the branches. This matters because branch 2 carries retry guidance while branch 3 explicitly exists to avoid misleading advice — the conflict is not cosmetic.

Additionally, when an identical reinstall does apply, the update marker changes (a reinstall of the same APK produces a new update timestamp). That changed marker is positive evidence of application, but branch 3 unconditionally forces permanent unknown for identical states, discarding the one signal that disambiguates this case — even though branch 2 already relies on marker equality as decisive evidence in the opposite direction. The marker is treated as authoritative for "not applied" but ignored for "applied."

Finding 3 — Evidence persistence: bounded retention can destroy reconciliation evidence before reconciliation is possible

Reference: line 1676 ("stores … in private, user-scoped operational state with bounded retention"; reconciliation only "on any new paired ADB session"; "Ready mode cannot be assumed to restart silently"; "Restoring Ready mode after a bridge-hosting app update and its recurring phone action remain a pending user decision").

Reconciliation of an interrupted operation requires (a) the stored evidence (operation ID, expected digest, prior state, update marker) and (b) a future paired ADB session to re-read on-device package state. For the self-update case — explicitly the scenario where the connection is guaranteed to drop — a future session is gated on a pending user decision to restore Ready mode, which may happen arbitrarily late or never. The evidence, however, is under "bounded retention." If the retention window expires before the next session:

• the expected-state/prior-state/marker evidence needed for verification is gone, so no branch of the reconciliation can ever run;
• the plan defines no terminal handling for expiry with unreconciled operations — it does not state whether the pending unknown outcome is retained, surfaced, or silently dropped with the evidence.

The acceptance criteria (1700) require testing interruption and reconciliation but never test retention expiry with an outstanding unknown. Retention must be bound to reconciliation completion (or expiry-with-pending-operations behavior must be specified) for the "outcome unknown until independent verification" guarantee (1674) to hold.

Finding 4 — The "requested state not applied" claim and its retry guidance rest on an undefined "update marker"

Reference: line 1676.

Branch 2's claim of requested state not applied — the only branch that affirmatively recommends retry — is sound only if the "update marker" changes on every package mutation (install, reinstall, rollback, data-preserving update). The plan never defines the marker, never states that it must be monotonic per mutation, and never establishes that it is readable via the ADB path on the supported device (contrast the explicit feasibility gates for discovery, foreground service, and Access in 1698). If the marker is weak (e.g., versionName/versionCode-derived), a third-party rollback to the prior version would falsely satisfy branch 2 and emit retry guidance that reinstalls the expected version — actively overriding an external change, the exact outcome branch 3's "must not trigger downgrade advice" guard exists to prevent. Given that both the retry claim (branch 2) and the identical-reinstall handling (Finding 2) depend entirely on marker semantics, leaving it undefined is a substantive gap, not a naming detail.

Notes on what checked out clean

• The "never infer install success from a dropped socket" rule and "mark that install unknown at teardown" for self-updates (1674, 1676) are consistent.
• The "desired package state verified" label is correctly state-based and explicitly avoids claiming acknowledgment receipt or operation attribution (1676), so a third-party install of the expected state does not produce a false success claim.
• "Never use a later install's artifact as evidence for the earlier operation" (1676) correctly handles chained interrupted operations for the same package.
• The "differs from both → unknown, no downgrade advice" branch (1676) is the right conservative posture for external updates — the defects are in the seams around it (Findings 1, 2), not in the branch itself.

Round 27 disposition: revision 33 ADB bridge

Both requested Pioneer models completed focused reviews of the exact-text section 19 bundle. GLM-5.3 reported no substantive finding; its note about indistinguishable identical reinstalls is preserved in round-27-glm.md. Kimi K3 reported one substantive outcome-classification error and one reconciliation-trigger gap in round-27-kimi.md.

Revision 34 narrows all later package-state reports to what can be observed. A current package matching the expected artifact is reported as desired package state verified, without claiming that the interrupted command received acknowledgment. An unchanged prior state is reported as requested state not applied only when the expected and prior states differ. A third state, identical expected/prior states, and inconclusive checks retain operation outcome unknown. A third state may result from an external update and never produces downgrade advice.

The revision also runs operation-scoped reconciliation for every interrupted or timed-out install on a new paired ADB session, before another install to that package. The acceptance cases cover expected, prior, external, identical and unavailable states. A focused follow-up review of these exact clauses is pending; no convergence claim is made here.

I read the full bundle (REVIEW-BUNDLE.md, 1702 lines supplied; omitted sections treated as unknown).

Verdict: no substantive findings

The revision 33 clauses hold up under the requested focus areas.

1. Mac-local approval priority lease (line 1674) — sound

• Fail-safe in every specified path: pending → bridge pauses outbound frames; renewal lapse without an authenticated clear → stays paused until the approval transport recovers and attests nothing is pending; authenticated clear → resume. There is no path where a lapsed lease silently resumes.
• No privilege crossover: the lease is metadata-only ("grants no request detail or ADB authority"), consistent with line 1672 ("does not turn an ADB operation into a Remozio approval"), line 1674 ("Do not let a Remozio approval… grant ADB access"), and the line 69 same-user-key residual risk, which the lease correctly does not claim to mitigate.
• No feedback loop: the Android-side pause is explicitly "app-local scheduling, not a phone-to-Mac priority signal" (line 1674).
• Acceptance (line 1700) exercises exactly the risky paths: renewal, expiry-without-clear, recovered clear, app-local scheduling, interruption without approval-payload leakage.

2. Self-update operation-record reconciliation (lines 1674, 1676, 1700) — sound

• Record is captured before install (op ID, package, signing identity, version, digest, prior state; line 1676), so evidence survives teardown.
• Teardown → unknown (line 1676), matching line 1674's "never infer install success from a dropped socket."
• Reconciliation is gated before any next same-package install, with a three-valued result (expected→success; verified old/different→failure+retry; unavailable/inconclusive→unknown retained), which makes "Never use a later install's artifact as evidence" enforceable rather than aspirational.
• Bounded retention expiring before reconciliation degrades safely to unknown.
• One non-substantive wording note (line 1676): if the previously observed state equals the expected state (byte-identical reinstall), the "matching expected state means success" and "verified old… means failure" clauses fire on the same observation. The safe resolution (test expected-match first) is benign either way — the device is verifiably in the expected state — so this is a clause-ordering clarification, not a design defect.

3. Contradiction sweep within §19 — none found

• Session admission is consistently an open user decision everywhere it appears (lines 25 ↔ 1690 ↔ 1700 "the selected session-admission policy").
• Same-user ADB-key exposure is consistently acknowledged, not over-claimed (lines 69 ↔ 1682 ↔ 1700).
• "Pauses outbound frames while pending" (1674) vs. "receives lower priority" in acceptance (1700): pausing is a stricter implementation of precedence, not a contradiction.
• Conditional connectedDevice FGS use (1690) matches the feasibility proof requirement (1698).
• First-install-requires-local-ADB (1676) is an explicit bootstrap exception, not a conflict with bridge-only deployment (1672).
• Self-deploy acceptance items (line 1700) map one-to-one onto the line 1676 procedure (teardown, unknown, reconcile-before-same-package-install, observed-new/verified-old/inconclusive, Ready-mode recovery).

The rev 33 renewals are internally consistent and fail-safe as written; remaining open items (admission UX, recovery UX, feasibility gates) are correctly recorded as pending user decisions per lines 25–27, not defects.

Code review — revision 33 bridge bundle

Reviewed the two renewed mechanisms (priority lease, line 1674; self-update operation-record reconciliation, line 1676) and cross-checked all supplied section 19 text (1668–1702) plus the threat/UX preamble for contradictions.

Finding 1 (substantive): "verified different state ⇒ failure" is an unsound reconciliation verdict

Line 1676:

"matching expected state means success; a verified old or different state means failure with retry guidance; unavailable or inconclusive verification retains unknown. Never use a later install's artifact as evidence for the earlier operation."

A verified device state that matches neither the expected post-install state nor the recorded previously-observed state does not establish that the earlier operation failed. The plan's own next sentence concedes a later install can intervene ("never use a later install's artifact as evidence"), and an out-of-band update (Play Store, another ADB path) between teardown and reconciliation produces exactly this "different" state. In that case:

• the earlier self-update may have succeeded and then been superseded — reporting failure is factually wrong;
• worse, attaching retry guidance to that verdict steers the user toward reinstalling the older artifact over a newer install (a downgrade/overwrite of externally changed state).

This is also internally inconsistent with the acceptance criteria on line 1700, which enumerate only "observed-new success, verified-old failure, inconclusive unknown" — the "verified different" branch is untested and unrepresented there.

Minimal fix (line 1676): split the verdict —

"a verified state equal to the recorded prior state means failure with retry guidance; a verified state matching neither expected nor prior state retains unknown (package changed externally) and must not produce retry guidance"

and add the "verified-different retains unknown" case to the acceptance list on line 1700.

Finding 2 (minor gap): reconciliation trigger is only specified for the self-update path

Line 1674 requires any "interrupted, timed-out, or self-update-terminated install" to be reported as unknown until independent package-state verification. But line 1676 provides an automatic reconciliation trigger only for the self-update case ("After the user restores Ready mode, a new paired ADB session automatically reconciles that operation before another install to the same package"). For an ordinary interrupted/timed-out install, no session-start or pre-install reconciliation step is specified, so the retained operation record (which 1676 mandates for every install) may never be reconciled — the "unknown" report has no defined resolution path.

Minimal fix: state that the "reconcile any unreconciled operation record for the target package before another install to that package, on any new session" rule applies to all interrupted/timed-out installs, not only self-updates.

Priority lease (line 1674): no substantive defect

The lease is sound as written: it is metadata-only and grants no ADB authority (consistent with the credential-separation rule in the same paragraph), fail-closed on renewal loss (pause persists until an authenticated attestation of no-pending-request), and the two directions of shared-link contention are covered by complementary mechanisms — Mac-side outbound pause via the lease, phone-side app-local send pause via the approval socket — with the irreducible residual contention explicitly disclosed ("shared link contention cannot be eliminated completely"). No contradiction with lines 1680, 1682, 1686, or 1700.

Other section 19 contradictions

None found. Product boundary (1672), connection path (1680–1686), availability/controls (1690–1694), feasibility/acceptance (1698–1700), the open session-admission decision (1690 vs. line 25), and the residual same-user ADB-key exposure (1682 vs. line 69) are mutually consistent, aside from the 1676/1700 mismatch folded into Finding 1.

Summary: one substantive defect (reconciliation verdict for verified-different state, line 1676) and one minor specification gap (reconciliation trigger scope, lines 1674/1676); the renewed priority lease and the remainder of section 19 have no substantive findings.

ADB bridge focused disposition — revision 32 to 33

Pioneer zai/glm-5.3 and kimi-code/k3-256k independently reviewed exact-text revision 32 clauses. GLM found an incomplete failure outcome after bridge-hosting app self-update. Kimi found that the priority signal could expire while an approval remained pending and that the later install comparison lacked a retained reference record. Revision 33 changes:

• The Mac approval transport renews a bounded pending priority lease. On lost renewal without an authenticated clear, the bridge remains paused until the approval transport recovers and attests that no request remains pending. The phone's own app schedules its two sockets locally; the acceptance text no longer asks for a nonexistent phone-to-Mac priority signal.
• Before install, the Mac command retains operation-scoped expected and prior package metadata privately, without APK bytes or ADB payloads. On self-update disconnect it records unknown. At the next Ready session, it reconciles that same operation before another install to the package: expected state means success, verified old or different state means failure with retry guidance, and unavailable/inconclusive evidence remains unknown.

Revision 33 is undergoing a focused convergence check. Its platform and user-decision gates are not implementation proof.

Code review — REVIEW-BUNDLE.md (revision 32), amended ADB bridge clauses

Scope honored: read-only, no edits. Citations use the bundle's embedded source line numbers (they match the source lines shown). Omitted plan text (sections 3, 5, 16, REVIEW-LOG) treated as unknown; the rev-29 "no findings" result explicitly does not cover section 19 (L3).

Focus question 1 — Who enforces approval priority across isolated transports?

Coherent; no substantive defect. Enforcement is assigned per egress direction to trusted Remozio components:

• Mac→phone egress: the separate bridge endpoint pauses/throttles outbound frames on the unprivileged approval transport's bounded pending/clear signal over authenticated local IPC (L1674). No network signal is needed, so transport isolation is preserved.
• Phone→Mac egress: the Android app pauses bridge sends from its own approval-socket pending state — internal to one process, no cross-transport signal required (L1674).
• Signal expiry bounds a lost/crashed signal (L1674), and residual link contention is honestly acknowledged ("shared link contention cannot be eliminated completely," L1674), consistent with acceptance tests for both directions, expiry, and saturated-install precedence (L1700).

Focus question 2 — Self-update yielding and reconciling an unknown install

Flow is sound: teardown marks the install outcome unknown, never inferring success from a dropped socket (L1674, L1676); reconciliation requires the user to restore Ready mode and a new admitted ADB session checking package identity, signature, version, and artifact digest; only matching observed state resolves it; reconnection/verification failure retains unknown (L1676); the recurring-phone-action recovery UX is properly recorded as a pending decision (L1676, consistent with L25/L27). One gap in the outcome model, below.

Substantive finding (1)

S1 — Reconciliation can never resolve to failure, only success or perpetual unknown. L1676: "only matching observed state resolves the outcome. If reconnection or verification fails, retain unknown." A successful check that observes the old artifact (the likely case: mid-stream abort leaves the previous version installed) is definitive evidence of failure, yet under this text it stays "unknown" indefinitely — there is no terminal failure state, no retry guidance, and no stated repair route for it in the supplied text. This conflicts with the plan's own three-outcome contract for the phone ("success, failure, or an uncertain outcome," L15) and its state-honesty principle (cf. L1157, another subsystem, requiring explicit remaining-cleanup and a repair route rather than an ambiguous claim). Acceptance (L1700) also omits the verified-old-state case, so the gap would survive testing. Impact: the pending recovery-UX decision (L1676) is being designed against an outcome model missing its failure leg. Recommendation (no edits made): define match-new → success; verified mismatch/old state → failure with retry guidance; check unavailable → unknown; add the mismatch case to acceptance.

Minor notes (explicitly non-substantive)

1. L1674 "pauses or throttles" — throttling alone may not deliver precedence; the binding criterion is the saturated-install test (L1700). Wording should match the intended strictness.
2. L1674 vs L1700 — L1674 defines a single Mac-local signal (transport→bridge IPC), yet acceptance requires testing "Mac-to-phone and phone-to-Mac priority signals"; no such network signals exist in the design (phone-side pause is app-internal). Terminology drift risks testing the wrong artifact.
3. L1676 ambiguity enabling S1: "matching observed state" does not state matched against what (deployed artifact only, or either known state).

Consistency checks that passed

• Bridge is not an approval request type: L21 ↔ L1672.
• Session-admission policy is an open user decision, not assumed: L3/L25 ↔ L1690 ↔ L1700 (tests "the selected" policy).
• Same-user Mac residual exposure stated, gated before shipping, and surfaced in the UX choice: L69 ↔ L1682 ↔ L1690.
• Bridge is the only additional ingress, separately authenticated, own Access app, phone never gets management credentials: L1159 ↔ L1680 ↔ L1694.
• One-Mac/one-phone bridge vs multi-phone approval enrollment: L1676.
• Unknown-result, reconciliation, teardown, and no-approval-payload-leakage tests present: L1700.

Verdict: one narrow substantive defect (S1) in the self-update reconciliation outcome model; priority-enforcement clause is substantively sound. All other open items in the supplied text are already recorded as pending decisions or feasibility gates, which the plan itself does not count as review convergence (L27).

Review report — REVIEW-BUNDLE.md revision 32, section 19 amended clauses

Two substantive findings remain.

Finding 1 — Priority enforcement has no phone→Mac leg and silently lapses on signal expiry

The normative design (line 1674) defines exactly one priority mechanism on the Mac side: the unprivileged approval transport sends a bounded pending/clear signal over local IPC to the bridge endpoint, which "pauses or throttles outbound frames while pending" and resumes "after the signal clears or expires." The phone side is purely local behavior: "The Android app prioritizes its approval socket and pauses bridge sends while an approval is pending" (1674). No phone→Mac priority signal is specified anywhere in the normative text — the Mac bridge has no way to learn that an approval is still pending on the phone once the Mac-side signal expires.

This creates two defects:

• Expired-signal precedence loss. If the user deliberates longer than the (unspecified) signal expiry, the Mac bridge resumes outbound frames mid-approval. No refresh/heartbeat or re-signal requirement is defined, so the unconditional guarantee "Give pending approvals precedence over ADB traffic" (1674) is actually a time-bounded best effort. Since the transports and accounts are deliberately isolated (1680: bridge service account "distinct from the approval transport account"), the bridge endpoint cannot independently observe pending state — the signal is its only input, and its lifecycle is undefined.
• Acceptance/normative mismatch. Line 1700 requires testing "Mac-to-phone and phone-to-Mac priority signals, their expiry," but no phone-to-Mac signal exists in the plan. Either the mechanism is missing from section 19's normative clauses, or the acceptance criterion is untestable as written.

Finding 2 — Self-update reconciliation has no specified retained reference state

Line 1676 requires that after a self-update teardown, "a new paired ADB session checks the installed package identity, signature, version, and artifact digest…; only matching observed state resolves the outcome. If reconnection or verification fails, retain unknown." But nothing specifies what the Mac must persist about the pending unknown outcome — expected package identity, version, and artifact digest correlated to that specific interrupted install. Two adjacent clauses narrow the obvious storage locations: line 1686 keeps "APK bytes and ADB payloads out of application logs and audit history," and line 1694 limits bridge status to "the paired Mac and last session… not ADB command contents." The expected digest is therefore homeless: "matching observed state" (1676) has no defined reference value to match against in a later, independently initiated session. Nor does any clause require a subsequent on-demand session (1682: "The Mac command starts a session on demand") to reconcile the retained unknown before beginning new deploy work — a later unrelated deploy could verify against the wrong artifact, or the unknown can persist indefinitely with no trigger to resolve it. The acceptance line (1700: "independent package-state reconciliation after a new session") presumes this state exists but the plan never creates it.

Consistency checks that pass

• Threat boundary (line 69) ↔ admission-policy decision (1690) ↔ race/standalone-boundary gate (1682): the same-user ADB host-key exposure is consistently disclosed and gated on a pending user decision, satisfying the consultation rule (lines 25, 27).
• Self-update kill of the approval path (1676) is covered by the product contract's manual-approval fallback (line 15), and "outcome unknown… never infer install success from a dropped socket" (1674) is internally consistent with "Mark that install unknown at teardown" (1676).
• Ingress separation (1159), credential custody (1680), and payload-free priority signal (1674 vs. 1700 "without approval payload leakage") are consistent.

No files were modified.

ADB bridge second-pass disposition — revision 31 to 32

Pioneer zai/glm-5.3 and kimi-code/k3-256k independently reviewed exact-text excerpts of revision 31. GLM reported no substantive findings in its scope. Kimi reported two remaining defects, both amended in revision 32:

1. Approval priority had no enforcer across separate transports. The unprivileged Mac approval transport now sends a bounded pending/clear signal to the bridge over authenticated local IPC. The bridge throttles or pauses Mac-originated frames, and the Android app prioritizes its approval socket and pauses phone-originated bridge frames. The signal carries no request details or authority; shared-link contention remains measurable rather than assumed absent.
2. A self-update had no result path after terminating its own bridge. The Mac now records the interrupted install as unknown. After Ready mode is restored, a new paired session independently checks installed package state and resolves only a matching observed result. Without reconnection or verification, unknown remains.

The session-admission UX, stronger local ADB client boundary, Android platform behavior, and bridge-hosting app recovery remain open gates. A focused revision 32 review of these amendments is in progress.

I read the full bundle (only file present in the source directory) and traced each requested focus area across every excerpted line.

Verdict: no substantive findings

The amended revision 31 text is internally coherent on all eight areas; no contradictions, authority leaks, or missing lifecycle steps remain in the reviewed text.

Verification per focus area:

• Local ADB listener threat — The loopback race is stated honestly (line 1682: "Loopback binding alone does not authorize the ADB client… cannot exclude a malicious same-user process with the ADB host key"), matched to the threat model (line 69), mitigated by the single-admitted-connection/expiry binding (line 1682), gated pre-ship ("A stronger local client boundary or independent phone-side session authorization is a feasibility and UX gate before shipping"), and tested in acceptance (line 1700).
• Session admission — The two-policy choice, the same-user exposure disclosure, and the "select and test one" requirement are consistent across lines 25, 69, 1690, and 1700; it is recorded as an open user decision, not silently assumed (lines 3, 27).
• Cloudflare ingress lifecycle — Create/verify/rotate/disable/uninstall for the bridge's separate Access application and dedicated ingress are owned by the setup controller (lines 1193–1195), the endpoint/ingress relationship and LAN path are pinned (lines 1159, 1680), and rotation/revocation/idle behavior are in the feasibility gate and acceptance (lines 1698, 1700). No shared-secret-in-APK conflict (lines 1173 vs 1694).
• Separate process and release boundaries — Bridge endpoint runs under a distinct service account with no approval authority (lines 104, 1674, 1680); root service is never an ADB proxy (lines 100, 1674); bridge builds ship in the signed manifest under the unprivileged roles' placement/activation/minimum-build rules (line 1436).
• Android self-update — Self-update terminating the hosting foreground service is acknowledged, recovery UX is a recorded pending decision, and self-deploy/teardown/result reporting are acceptance items (lines 1676, 1700).
• Congestion priority — Approvals take precedence with honest interruption reporting and measured (not promised-zero) latency (lines 1674, 1700), consistent with the unbounded-buffering controls (line 1686).
• Audit — Metadata-only bridge start/stop/peer/stop-reason events (line 756) match the payload-exclusion rules (lines 1686, 1694) and the acceptance check (line 1700); rate-limit rules (lines 758–760) are untouched by the bridge additions.
• Protocol evolution — Bridge stream/framing/local-control versions are declared separately from approval wire versions, with exact tested sets required in manifests (lines 1558, 1563, 1568, 1571–1573) and versioned builds in the release manifest (line 1436).

Scope note: review is limited to the bundle's exact-text excerpts (lines 1–105, 752–760, 1150–1200, 1430–1445, 1555–1574, 1667–1702); omitted sections were treated as unknown per the bundle header. No files were edited.

Code review: Remozio ADB bridge, revision 31 (REVIEW-BUNDLE.md)

Scope reviewed: local ADB listener threat, session admission, Cloudflare ingress lifecycle, process/release boundaries, Android self-update, congestion priority, audit, protocol evolution. Most of these are coherent: the listener race and same-user host-key exposure are consistently disclosed (L69, L1682) and gated; admission is explicitly an open user decision (L25, L1690); the setup controller's typed bridge ingress/Access lifecycle matches the connection path (L1193, L1680, L1159); release-manifest and protocol-version treatment of bridge components is consistent (L104, L1436, L1563, L1568); audit is metadata-only with bounded rejection telemetry (L756–760, L1686).

Two substantive defects remain:

1. Medium — Congestion-priority mandate has no enforcing component

Lines: 1674 ("Give pending approvals precedence over ADB traffic: throttle or pause bridge frames when the shared uplink or phone radio is congested"), in tension with 1674 ("Keep deployment transport, rate limits… separate from approval messages") and 1680 (bridge endpoint runs under a separate account/process from the approval transport).

Defect: The precedence guarantee crosses two deliberately separated transports, but no component is designated to detect a pending approval and signal the bridge to yield. On the phone→Mac direction the single Android app owns both sockets, so enforcement is feasible but unstated. On the Mac→phone direction (APK bytes vs. approval requests sharing the tunnel/phone downlink), the bridge endpoint cannot know an approval is pending without a coordination channel the plan neither defines nor explicitly forbids. "Measure approval latency under a saturated install" (L1674) and the acceptance test (L1700) verify the symptom but don't supply the mechanism.

Minimal correction: Name the enforcer per direction: the Android app as priority point for phone-originated traffic, and an explicit local preemption/backpressure signal from the approval authority/transport to the bridge endpoint for Mac→phone traffic; or narrow the guarantee to phone-side enforcement and disclose the residual Mac-uplink contention.

2. Low — Self-deploy install result has no delivery path

Lines: 1674 ("report an interrupted install honestly if the ADB connection times out"), 1676 ("Updating the Remozio app that hosts this bridge terminates its own foreground service and connection"), 1700 ("Self-deploy the bridge-hosting app and verify session teardown, install result reporting…").

Defect: A self-deploy deterministically kills the phone-side proxy mid-install, so the ADB install result cannot reliably transit the connection that carries it — yet the acceptance criterion requires "install result reporting" for exactly this case, and L1674's honest-reporting rule covers only timeouts, not this deterministic self-interruption. The general unknown-outcome handling (L752) exists but is not wired into the self-deploy acceptance path.

Minimal correction: Extend L1674's interruption reporting beyond timeouts to cover self-update teardown, and in L1676/L1700 specify the reconciliation mechanism (e.g., record an interrupted/unknown outcome at teardown, then confirm installed package state after Ready-mode recovery via a new session).

No other substantive findings in the reviewed areas.

ADB bridge review disposition — revision 30 to 31

Pioneer ran independent reviews with kimi-code/k3-256k on the full revision 30 plan and zai/glm-5.3 on an exact-text bundle of section 19 and the related approval, transport, update, and compatibility contracts. The first GLM full-plan attempt and its same-session resume ended without reports after the model hit its response-length limit; neither attempt counts as a review. The completed scoped GLM report and Kimi report are retained separately.

Revision 31 remains a design draft. The local listener boundary, Android platform feasibility, and session-admission UX are explicit gates. A second review pass of the amended text is in progress; do not describe this disposition as convergence until those reports finish.

Code Review: Remozio Revision 30 — Section 19 ADB Deployment Bridge

Scope: REVIEW-BUNDLE.md only (exact source lines preserved). Omitted plan text is treated as unknown, not as a defect. No files were modified. Per line 3, section 19 has had no independent review; this report supplies one.

Verdict: Section 19 is unusually honest about platform limits and correctly keeps the bridge outside the approval authority. It contains one high-severity design defect (unauthenticated local ADB listener), several medium consistency/placement gaps against sections 3, 16, 17, and 18, and a set of genuinely open feasibility questions that the plan already gates correctly.

Design defects

D1 — HIGH: Local ADB listener has no client authentication (lines 1678, 1690, 1696)

Line 1678 authenticates only the control plane: "Authenticate the command to the background bridge with a local peer check and restrict it to the configured administrator account." The data plane — "binds a temporary listener on 127.0.0.1 for the local ADB client" — is an ordinary loopback TCP listener. On macOS, any local process may connect to a loopback port; a TCP listener cannot restrict callers to the administrator account. The "one active connection" bound at line 1678 is a slot, not an authorization check.

Rationale: the stated threat model (line 61) explicitly includes "a malicious unprivileged requesting process." That process can enumerate loopback ports, win the race for the single connection, and complete ADB authentication, because line 1690 keeps the pairing key "in ADB's existing host store" — ~/.android/adbkey, readable by any process running as that key's owner (typically the same interactive/admin user the coding agent runs as). Line 1682's "Forward ADB bytes without terminating or replacing ADB's own TLS" does not help: ADB host-key authentication is satisfiable by the same-user attacker who can read the key. Net effect: while Ready for remote deployment is active, the phone's debugging surface is extended to the entire Mac user session, contradicting the administrator restriction at line 1678 and the boundary at line 1670 ("Do not let a Remozio approval, decision key, push token, or transport credential grant ADB access" — the bridge's transport credential is effectively doing exactly that for uninvited local processes). Even without key access, occupying the single connection is a denial of service against deployment.

Minimal amendment: the temporary listener must authenticate its single client with the same rigor as the command — e.g., hand off the listening socket (or a one-time bound token) only to the authorized command's process via local authenticated IPC, and reject connections whose peer credentials are not the configured administrator account. Additionally specify which account runs the adb client and owns the paired key, and state that the key must not be readable by processes other than that account (see D7).

D2 — MEDIUM: Self-deployment of the companion kills the bridge session and Ready mode (lines 1672, 1686, 1696)

The feature's own primary use case — "deploying a build from the enrolled Mac to the enrolled Android phone" (line 1668) — includes deploying a new build of the Remozio companion itself ("normal app updates can use the bridge," line 1672). When pm install commits the replacement, Android kills the app process, terminating the foreground service (line 1686) and the WebSocket. Post-replacement, background-start restrictions prevent the app from silently restoring a foreground service, so Ready mode is lost after every self-deploy, and the next deploy needs a phone tap. Per line 25, adding manual steps is a consultation-triggering change, and per line 27 such a recurring UX cost must be recorded as a pending decision; the bundle shows no such record for this loop, and the acceptance list at line 1696 does not test self-update ("restart and changing ADB ports recover without re-pairing" does not cover package replacement of the host app).

Minimal amendment: add a self-update acceptance case to line 1696, and explicitly document that self-deployment ends Ready mode with a defined recovery step (or record a pending decision on a persistent installer stub — a design change requiring consultation).

D3 — MEDIUM: Mac bridge endpoint missing from release manifest, protected placement, and update path (lines 102, 1426–1436, 1670, 1676)

Line 102 introduces "a separate Mac-side transport endpoint and command" as a first-class component, and line 1676 makes it a network-exposed unprivileged service. But the release manifest at line 1434 lists only "app, helper, GUI adapter, transport, and administrative setup-controller builds," and line 1436's "authenticate each running component" likewise omits it. No section specifies: which service account runs the endpoint (sharing the dedicated transport account of line 1141 would co-mingle bridge authority with approval transport, undermining the separation asserted at line 1670); where its binaries live; custody of the phone-bridge-identity verification keys (line 1690 covers only the phone side); or how it updates. Line 1428's invariant — never launch privileged/exposed code from a location replaceable by an unprivileged process — should clearly apply but is never applied to it. A user-replaceable bridge binary can redirect sessions, target a different phone, or subvert line 1678's "Do not accept arbitrary hostnames, ports, or destinations."

Minimal amendment: add the bridge endpoint to the line 1434 manifest and the line 1436 authentication check; assign it a service identity distinct from the approval transport account; apply the section 3/17 placement and update rules; specify local custody of the bridge identity keys.

D4 — LOW/MEDIUM: Section 18 compatibility manifest omits the bridge (lines 1552–1569)

Line 1552 requires every component to declare "what it can send, parse, and execute," and the table at lines 1558–1566 enumerates Android app, Mac authority, GUI adapter, command frontend, Mac transport, relay/push gateway — but not the Android bridge client or Mac bridge endpoint, even though the bridge introduces a new wire protocol ("the same framed byte stream," line 1676, plus framing/backpressure rules at line 1682). A companion update that changes bridge framing has no negotiation or compatibility story, and line 1567's "do not claim an untested continuous range" cannot apply to a protocol that is never declared.

Minimal amendment: add bridge rows to the table (envelope/framing versions, capability flags) and treat bridge protocol evolution under the authenticated negotiation rules at lines 1571–1589.

D5 — LOW: Section 16 wording conflicts with exposing the bridge endpoint (lines 1157, 1676)

Line 1157: "Expose only the Remozio protocol endpoint, never the privileged helper, a general shell, or other local services." Line 1676 routes the bridge "through the section 16 internet transport candidate, Cloudflare Tunnel plus Access." As written, these contradict: the bridge is a second, distinct endpoint. The intent (only enumerated, authenticated Remozio endpoints) is recoverable but should be stated, ideally with the bridge on its own Access application so its service-credential revocation (line 1690) is independent.

Minimal amendment: reword line 1157 to "only the enumerated Remozio endpoints (approval and the deployment bridge), each with its own Access application."

D6 — LOW/MEDIUM: Approval-latency separation is asserted but no mechanism survives the shared path (lines 1670, 1696)

Line 1670 requires separation of transport/rate limits "so a large APK cannot delay a short-lived approval," and line 1696 makes "bridge load does not delay an approval" an acceptance criterion. But both flows traverse the same cloudflared tunnel (line 1141), the same WAN uplink, and the same phone radio; application-level queueing cannot prevent link-level contention. As specified, the design has no mechanism (no prioritization, no pause-on-pending-request) by which the acceptance criterion could pass under a saturated uplink.

Minimal amendment: define a precedence policy — e.g., bridge transfers throttle or pause while any approval request is pending or within its response window — so the acceptance test is achievable by construction rather than by luck.

D7 — LOW: adb-key account mismatch and recurring-admin UX cost are unresolved (lines 1678, 1690)

Line 1678 restricts the command to "the configured administrator account," while line 1690 leaves the pairing key in ADB's per-user host store. If the interactive developer is not that administrator account, either adb runs with an unpaired key (fails authorization) or the key must be copied across accounts (undermining custody). If the developer is the admin, the restriction is cheap; either way the plan should say so. If deploys require an admin context on a standard-user Mac, that is a recurring manual step requiring consultation per line 25.

Minimal amendment: one sentence in section 19 naming the adb client's account and requiring the paired key to remain unreadable to other local accounts; record a pending decision if this forces per-deploy elevation.

D8 — LOW: Foreground-service type has no fallback (line 1686)

"Use the Android connectedDevice foreground-service type only if its platform and distribution requirements are met" — the connectedDevice type requires holding qualifying permissions (e.g., Bluetooth/UWB/network-state) that a WebSocket-to-Mac bridge may not legitimately hold. The conditional has no else-branch: if unmet, is the bridge specialUse, or does Ready mode simply not exist? The design's core (persistent outbound connection owned by a foreground service, line 1686) depends on this answer.

Minimal amendment: specify the fallback type (with declaration/justification) or state that the feature is unavailable when connectedDevice requirements cannot be met, and fold that into the line 1694 gate.

D9 — LOW: "Not trusted for debugging" reporting presumes knowledge the app may not have (line 1688)

Line 1688 requires reporting Unavailable when "the current Wi-Fi network is not trusted for debugging," but an ordinary app has no public API to query ADB's trusted-network state; it can only infer from discovery/connection failure. As written the requirement may be unsatisfiable.

Minimal amendment: restate as "trust state is inferred from discovery/connect outcomes and reported as Unavailable," and verify inference fidelity in the line 1694 gate.

Platform feasibility questions (not defects — already gated)

• F1: Can an ordinary app discover its own _adb-tls-connect._tcp service via NSD, and what does Android 17's local-network permission require (lines 1680, 1694)? The plan correctly treats the Pixel 11 Pro loopback observation as reachability only.
• F2: Cloudflare Access service-token authentication on WebSocket upgrade, with rotation/revocation (lines 1171–1177, 1694). Consistent with section 16; open as stated.
• F3: ADB Wi-Fi 2.0 trusted-network re-enable persistence across reboots/network changes (line 1688) — correctly marked "test the exact behavior."
• F4 — add to the gate: Cloudflare's proxy imposes idle timeouts on long-lived WebSockets; an idle ADB session (no keepalive traffic) may be dropped by the edge regardless of device-side socket survival. Line 1694's "maintain a foreground WebSocket in idle" should explicitly include edge idle-timeout behavior and keepalive design.
• F5: adb install policy for app updates on target SDK/Android 17 (line 1672) — correctly conditional.

Checks that pass

Approval authority separation (lines 1668, 1670 vs. 73–83); no plaintext adb tcpip mode (line 1682); byte caps/framing/backpressure (line 1682); independent revocation and session teardown (line 1690, consistent with line 1177); no Cloudflare credentials on the phone (lines 1676 vs. 1167); honest unavailability reporting (line 1688); Tailscale as a development-only fallback does not conflict with the product-scope "no VPN required" at line 87; the per-session-confirmation question is properly flagged as a UX policy decision (line 1686), consistent with lines 25–27.

Top actions: fix D1 before any implementation; resolve D2–D3 during planning since they change manifests and acceptance criteria; D5–D9 are one-line amendments.

Code review: IMPLEMENTATION-PLAN.md revision 30 (focus: section 19)

File reviewed: /Users/rock3r/src/remozio/IMPLEMENTATION-PLAN.md (1,699 lines; line numbers verified against the file).

Confirmed design defects and inconsistencies

1. Unauthenticated loopback ADB listener is exposed to in-scope attackers — Medium

Line 1678 (The Mac command ... binds a temporary listener on 127.0.0.1 for the local ADB client) combined with line 1690 (The Mac keeps its ADB pairing key in ADB's existing host store).

Rationale: Section 2's threat boundary (line 59) explicitly includes "a malicious unprivileged requesting process," and section 3 (line 120) warns the command frontend "may be invoked by an untrusted same-user process: do not mistake its signature for user consent." Section 19 applies no analogous rule to the bridge. The ~/.android ADB host key is same-user-readable, and a loopback listener accepts connections from any local process (including other GUI users). During any active session, an in-scope same-user process can connect to the listener and drive full ADB (package install, shell, device data) on the phone — remotely, since the bridge exists precisely to extend ADB off-LAN — with no enrolled-phone signature, no biometric, no phone tap, and no audit event. The plan authenticates the bridge command via peer check (line 1678) but never states who may connect to the listener or what protects it; "one active connection" (line 1678) makes a race-to-connect attack practical. Section 19 also never adds this boundary to the threat model in section 2.

Minimal correction: in section 19, (a) state the listener's protection model explicitly (e.g., accept exactly one connection, verify the connecting peer's audit token/UID matches the authenticated command's session, or bind a filesystem-protected socket instead of a TCP port); (b) document in section 2 that ADB host-key custody is same-user and that enabling wireless debugging plus the bridge extends that exposure off-LAN; (c) note that deferring per-session phone confirmation (line 1686) removes the only phone-side mitigation, and record that deferral as a pending decision per section 1 (line 27) — it is currently absent from the revision header's open-decision list (line 3).

2. Bridge endpoint conflicts with section 16's exposure and provisioning constraints — Medium

Line 1676 (a dedicated unprivileged Mac bridge endpoint ... reached through the section 16 internet transport candidate, Cloudflare Tunnel plus Access) vs. line 1156 (Expose only the Remozio protocol endpoint, never the privileged helper, a general shell, or other local services) and line 1190 (The controller enforces the exact configured account, tunnel, application, hostname, and local Remozio endpoint).

Rationale: A proxied ADB byte stream is functionally remote shell capability; section 16 permits exactly one exposed endpoint, and the setup controller's typed operations cover a single hostname/application with no operation to create or verify a second ingress/Access policy. Section 19 contains no provisioning, rotation, or uninstall story for its endpoint at all, so as written the bridge cannot be deployed without silently amending section 16.

Minimal correction: amend line 1156 to name the optional bridge endpoint as a permitted second exposure when the feature is enabled; extend the controller's typed operations (line 1190) to cover bridge ingress/Access policy lifecycle; add one sentence in section 19 assigning bridge provisioning and teardown to the section 16 controller under the same administrator-authorized path.

3. "The initial product supports one Android phone and one Mac" contradicts multi-phone enrollment — Medium

Line 1672 vs. line 219 (Permit multiple enrolled phones for one Mac/account tuple), line 221 (deliver each request to every currently authorized phone), and line 1059 (Support token rotation, multiple phones).

Rationale: As written, "the initial product" is a product-wide claim that directly contradicts section 5. If the intent is to scope the limit to bridge sessions, the sentence does not say so, and section 1 (line 21) integrates the bridge into the same product.

Minimal correction: reword line 1672 to scope the limitation, e.g. "The deployment bridge initially supports sessions to one enrolled phone per Mac; approval enrollment remains multi-phone per section 5."

4. "Keep the existing Tailscale path as a development fallback" references nonexistent infrastructure and contradicts the no-VPN posture — Medium

Line 1694 vs. line 89 (No VPN or WARP client is required), section 16 (Neither requires a VPN, line 1123), and the header (This is a standalone project, line 5; no security settings, apps, or privileged components are installed).

Rationale: Nothing named Tailscale exists anywhere else in this plan or project; "the existing Tailscale path" is undefined. Tailscale is also a VPN, and introducing it even as a development fallback contradicts the stated deployment posture without a recorded pending decision (section 1, lines 25–27, requires consultation for changes that add manual steps or dependencies).

Minimal correction: delete the sentence, or replace with "a development-only VPN fallback (e.g., Tailscale) is a pending user decision, not part of the shipped design" and record it accordingly.

5. Bridge components are absent from the update/floor and protocol-evolution machinery — Low

Line 1434 (Ship a signed release manifest with app, helper, GUI adapter, transport, and administrative setup-controller builds) and the section 18 declaration table (lines 1560–1565) vs. line 1672 (against the same bridge protocol) and line 1676.

Rationale: The Mac bridge endpoint and bridge command are in the component list (line 100) but not in the release manifest enumeration, so the floor-enforcement, protected-placement, and quiescent-activation rules of section 17 do not clearly apply to them. Unlike cloudflared (explicitly covered at lines 1143–1147), section 19 never states which account runs the bridge endpoint or that section 3/16 custody rules apply to its binaries, config, and update path. The bridge protocol also has no row in section 18's compatibility table despite being named as a cross-platform contract.

Minimal correction: add the bridge endpoint and command to the line 1434 manifest; add a section 18 row ("Bridge endpoint/protocol: bridge stream versions; no approval authority"); state in section 19 that the endpoint runs under a dedicated unprivileged account with section 3 placement and section 16 credential-custody rules.

6. Bridge sessions are not in the audit event set — Low

Line 754 (Record request creation ... pairing, revocation, recovery, update scheduling, activation, and update-caused interruption events) vs. line 1690 (The bridge's local status identifies the paired Mac and last session).

Rationale: An ADB session grants remote shell on the phone — more sensitive than several audited event classes — yet session start/stop/stop-reason and peer identity are only transient local status. Metadata-only session events are compatible with line 1682's exclusion of APK/ADB payloads from logs and audit.

Minimal correction: add bridge session lifecycle (metadata only) to line 754's event list and a corresponding audit acceptance case.

7. Byte-cap rationale misattributes the threat — Low

Line 1682 (a per-session byte cap ... so the relay cannot accumulate unbounded data) vs. line 1087 (A tunnel is a live proxy, not an offline mailbox).

Rationale: By the plan's own transport model, Cloudflare Tunnel streams and does not accumulate data; the cap's real purpose is bounding endpoint buffering and session resource consumption. The stated rationale is internally inconsistent with section 16.

Minimal correction: reword to "so neither endpoint nor relay buffers unbounded session data."

Unproven feasibility — properly hedged, not defects

These are open platform questions that section 19 correctly defers with evidence requirements; they should not be counted as design defects:

• NSD discovery vs. Android 17 local-network permission (lines 1680, 1694): discovery of _adb-tls-connect._tcp is a LAN operation likely gated by the new permission model even though the subsequent connection is loopback. The plan flags the real-device test, scopes the Pixel 11 Pro observation correctly (loopback reachability only, not discovery/permission), and provides a manual-port fallback. Appropriately hedged.
• connectedDevice foreground-service type (line 1686): conditional on platform/distribution requirements. Appropriately hedged.
• ADB Wi-Fi 2.0 re-enable behavior (line 1688): explicit "test the exact behavior." Appropriately hedged.
• Access service-token authentication over a WebSocket upgrade (line 1694): extends section 16's existing background-Access feasibility gate (lines 1168–1176) rather than assuming it. Appropriately hedged.
• Push waking the app to reopen Ready mode (line 1688): explicitly denied as a replacement for the live socket and as a bypass of background-start limits. Correctly stated.

Verified consistent (no findings)

• Section 1's carve-out that the bridge is not an approval request type (line 21), the authority separation in section 3 (line 100) and section 19 (line 1670: no approval/decision key/push token/transport credential grants ADB access), and stage 8 sequencing (line 647) are mutually consistent.
• ADB TLS is never terminated at the proxy (line 1682), keeping wireless-debugging pairing as the device-control authority — consistent with section 16's end-to-end encryption posture (line 1166).
• Revocation closes active sessions (lines 1678, 1690) and is enforceable at the Mac endpoint since the phone connects outbound; works even for an offline phone.
• Transport separation to protect approval latency (line 1670) plus the measurable acceptance criterion "bridge load does not delay an approval" (line 1696) are consistent.
• LAN path requires endpoint authentication (line 1676), consistent with "LAN discovery is not identity" (line 1129).

Summary: No feasibility claims in section 19 are overstated. The substantive work is in the security boundary around the Mac-side loopback listener (finding 1), the unamended section 16 exposure/provisioning rules (finding 2), and three internal-consistency defects (findings 3–5) that need text-level corrections before section 19 can be considered reviewed.

Round 23 disposition — no substantive findings

Frozen revision 29: 9532dd1994201cf6efba081b0ac014a89269d2565b18f3a6a9115fc94e1b10d7.

K3 and Opus each completed a full-plan review with exit 0 and a nonempty no-findings report. GLM completed the changed scopes; the exact-text coverage manifest accounts for all 18 sections using successful overlapping reviews and unchanged earlier text. Truncated and nonzero attempts are excluded.

No further substantive correction was required. This is plan-review convergence, not proof of platform feasibility or a security certification.

The migration ceremony remains pending user choice. No extra biometric, confirmation, recurring online check, or forced re-pairing was adopted. Idle interval and audit retention also remain declared product decisions.

Only the status paragraph is updated after freezing; requirements remain byte-identical to the reviewed snapshot. The snapshot and GLM coverage manifest are published with the reports.

Round 23 review — sections 1, 2, 8 + cross-section context

Prior disposition verification (revision 29)

The round-22 K3 fix is present and consistently integrated:

• Section 8 defines one authenticated, submission-bound no-admission result (Mac/account, submission identity+nonce, reason, retry class) for all admission rejections, with the four busy reasons tabled and given distinct deadline statuses.
• One caller deadline spans all retries and reason changes; backoff cannot reset it; indefinite drain/outage never produces an indefinite caller wait, and admitted requests' approval lifetime is unaffected.
• Automatic resubmission is authorized only by negotiated retry classes; permanent rejection, unknown codes, lost acks, and ambiguous results never retry. GUI capture reuses the same classification while preserving target age/expiry (§17).
• Sections 12 (storage reserve checked before dispatch), 17 (atomic admission close; Update installing bound to submission identity; restart-matrix recapture only for established-never-consumed UI requests), and 18 (all four reasons for command and UI prompt, deadline exhaustion, reason changes, lost acks) agree with section 8.

Independent checks performed

• UX bindings: biometric table in §1 matches the binding contract (LS allow-once/deny-once/cancel/dismiss without biometrics; every rule-setting decision including timed/session rules with biometrics; Forever default preserved). Update-scheduling phone controls add no extra biometric and no new confirmation dialog, and cannot supply artifacts, alter floors, or authorize target actions — no UX regression.
• One decision / one action: busy-state resubmission performs fresh capture and fresh decision; no old approval or execution is retried; unexpected-restart command requests are cancelled without auto-retry (matches the disposition's non-adoption).
• No-admission proof soundness: admission closes atomically with request creation and permit dispatch (§17), so "no request created, no action dispatched" is establishable; nonce/submission binding blocks replay of stale rejections; timeout/lost-ack paths reconcile or report uncertainty rather than guess.
• Execution-boundary semantics: requester-exit liveness recheck distinguishes before-child-start (consume decision, no-effect outcome) from post-start races; "no effect" claimed only when no child started is provable; per-request continue/terminate option defaults to attached CLI lifetime.
• Caller/race handling: identity recheck before execution, hash-check limits disclosed, descriptor-execution spike gated with an explicit semantic contract, no silent relocation, no immutable-transitivity claims.
• Restart matrix and recapture: never-consumed establishment against the durable ledger, Unknown retention when unprovable, no recapture of denials/expired/changed dialogs, notification retries bounded without resetting age.
• Cross-references between §8, §12, §17, and §18 resolve without contradiction; the GUI-capture busy-state retry is bounded by dialog presence and target expiry, consistent across all four statements.

No defect correction is needed; nothing that would worsen UX is proposed.

NO SUBSTANTIVE FINDINGS

Independent review — Remozio plan, revision 29

Assessment of the revision 29 changes (busy-state admission contract)

The round-22 K3 finding appears resolved without introducing new defects:

• The four busy reasons (Update installing, Mac authority starting, Update waiting, Storage unavailable) are defined once in §8 and referenced consistently from §12 (witness/journal startup failure → "Mac authority starting / storage unavailable"), §16 (live witness faults follow the same policy), and §17 (Update installing at the replacement boundary, Update waiting during explicit drain). I found no fifth unclassified busy state: recovery-required is correctly excluded from automatic retry classes and routed to the administrator repair path.
• The submission-bound, authenticated no-admission proof closes the ambiguity hole: lost acknowledgments, timeouts, unknown reason codes, and generic health hints never trigger resubmission (§8, §17, §18 acceptance cases). Replay of a prior no-admission result fails because it is nonce- and submission-identity-bound.
• The single non-resetting caller deadline across retries and reason changes, with indefinite drain never producing indefinite caller wait, is internally consistent and preserves cancellation, caller liveness, and unconsumed stdin/PTY input. It does not shorten an admitted request's approval lifetime.
• GUI capture parity is preserved: automatic recapture only after authority recovery, only while the same dialog remains, preserving first-seen age and target deadline per §13, with observed expiry/unknown disappearance reported honestly. Short-lived 1Password prompts during a long drain degrade to the already-defined expiry/disappearance paths, not to silent loss.
• The disposition's rejection of K3's "immediate manual-only retry" alternative is sound; the adopted bounded automatic resubmission adds no manual step, so no UX-consultation tripwire is crossed.

Cross-section consistency checks performed

• §6 consumption-before-side-effect, §12 journal transaction + checkpoint, and §16 witness anchoring compose coherently: per-action commits use the crash protocol; epoch creation and trust/floor/replay-control changes anchor the witness; restrictive-ahead intents roll forward automatically. Whole-backup rollback cannot un-consume a request because pending payloads are memory-only and restarts cancel unconsumed requests.
• §17 floor commit, adapter-key certification invalidation, and §16's inclusion of floors in the combined trust generation agree; the activation transaction and witness intent protocol both cover floor activation, with matching acceptance tests.
• Key-purpose separation (decision key: one-time UI decisions, cancellation, routing control, update scheduling; authority key: gateway control; biometric key: protected actions) holds across §6, §14, §16, §17; the allow-once exception remains scoped to the captured Little Snitch request, with §9's reusable-effect validation including timed/session rules.
• Multi-phone first-valid-decision consumption, revocation serialization, and push reconciliation (§5, §6, §15) show no downgrade or replay gap I could construct at plan level.

Tentative UX choices and documented observations (not defects)

• Migration ceremony cost, idle interval (30s draft), retention duration/budget: explicitly deferred product preferences.
• After an unexpected root-authority restart, admitted command requests are cancelled and require manual fresh submission (§17 matrix); the disposition records the automatic-retry suggestion as a non-adopted observation. This is a disclosed limitation, not a silent UX regression.
• Busy-state deadline exhaustion for commands ends in a distinct nonzero status requiring a manual rerun — error reporting, not an added confirmation step.

Remaining implementation verification limits

This is a plan-only review. The key-custody/witness availability, single-biometric credential release, descriptor-based execution, local command approval surface, 1Password/Little Snitch AX contracts, background Access authentication, and service-management placement protections remain feasibility gates with defined evidence and consultation paths; none has been validated against a real platform. Wire vectors, race tests, and acceptance cases are specified but unexecuted.

Conclusion

NO SUBSTANTIVE FINDINGS

I assessed internal consistency of the revision 29 busy-state/retry contract against §§5–9, 12–18; downgrade/replay resistance of the witness, epoch, gateway-control, and floor mechanisms; privileged update paths including same-user replacement and staging races; key separation and the Little Snitch once-exception scope; and preservation of the confirmed remote UX (no added biometrics, confirmations, lock-screen surfaces, or shortened windows). The prior disposition's reasoning withstands challenge; I found no concrete unresolved scenario. All findings above are either explicitly scheduled feasibility work or flagged tentative choices, and all three adapters remain in scope.

Remozio plan review: revision 29 (round 23)

Input: reviews/round-23-plan.md, revision 29, the complete plan (sections 1–18), plus reviews/round-22-disposition.md. Method: plan-only reading. I ran no tests, did no browsing and inspected no source.

Revision 29 changes

Section 8, "Process I/O and terminal outcomes" (busy-state table and retry rules)

• All four busy reasons share one authenticated, submission-bound no-admission proof.
• Each reason has a distinct deadline status.
• One caller deadline covers all retries and does not reset when the reason changes.
• Automatic resubmission is permitted only for negotiated retry classes.
• Lost or ambiguous acknowledgments never trigger resubmission.

This closes K3 L1 without adding a manual rerun.

I checked for a replay path and found none:

• Resubmission creates a fresh capture and needs a fresh decision.
• A forged busy response from an untrusted same-user caller can at worst cause a harmless fresh request, because it cannot carry a valid authority binding.
• Input is left unconsumed until admission.

Cross-section consistency

• Section 12 ("Retention and replay safety" and "Atomic journal writes") returns Storage unavailable before dispatch.
• The section 12 witness-fault path maps to Mac authority starting.
• Section 17 ("Automatic activation and optional drain" and "State across restarts") applies the same four classes to command resubmission and to GUI recapture. Recapture preserves the original age and target expiry.
• Section 18's acceptance list covers deadline exhaustion, reason changes, indefinite drain, storage exhaustion and unverified health hints.

Round 22 disposition

Rejecting the manual-only retry for Update waiting and Storage unavailable is sound. A bounded automatic wait avoids a needless rerun, and the fixed deadline prevents an indefinite stall. I found no concrete scenario where this weakens authority or hides state.

Rest of the plan

I found no new contradictions in the rest of the plan.

Scope and key separation

• The biometric-free exception is still confined to cancel, deny-once and Little Snitch allow-once whose actual effect is limited to the current request.
• Every reusable rule and the Forever default requires biometrics.
• Decision-key purposes (routing, update scheduling) grant no target, enrollment or release authority.
• The command and 1Password paths never inherit the exception.

Relay and transport

• The relay and transport cannot mint decisions or read payloads.
• Tunnel, push-gateway and Cloudflare-management credentials are separated.
• Gateway recipient changes require root-signed controls plus proof of token possession.

Command binding

• Argv, environment and stdin source are captured with disclosure.
• The atomic-exec and sudoers questions are explicitly gated.

Android biometric credential release

• The single-operation question is a gate with a consultation path.

UI race handling

• There is a one-use permit ledger.
• A failed scope mutation is reported as Unknown.
• The GUI permit acknowledgment path is defined.

Recovery, updates and mixed versions

• Protocol-resolvable journal interruptions recover automatically.
• History-only loss is separated from authority rollback.
• A restrictive witness intent can roll forward; a permissive one waits.
• Rollback protection is enforced outside the candidate binary.
• Negotiation cannot downgrade below a floor, and existing requests are never re-encoded into a weaker schema.

Non-blocking observation

In section 12, "Atomic journal writes", the caller-facing string "Mac authority starting / storage unavailable" for witness faults sits beside the separate section 8 Storage unavailable status used for audit-reserve exhaustion. Implementation should map witness faults to exactly one reason code so exit statuses stay deterministic. This is a naming precision issue, not a planning defect.

Pending choices (not defects)

• Migration ceremony
• Idle interval
• Retention duration and storage budget, including what happens when the budget is reached
• Outcomes of the explicit feasibility gates:
  • key custody and the trust witness
  • service placement and anti-rollback
  • atomic exec
  • sudoers compatibility
  • single-biometric credential release
  • 1Password and Little Snitch fixtures and true one-time effects
  • background Access authentication
  • local command approval
  • Android biometric-change continuity

Remaining implementation verification limits

Several things are not verified:

• Platform guarantees are unproven, notably protected placement against the same-user administrator, pre-login witness availability, and Secure Enclave custody under pre-login conditions.
• Accessibility atomicity and the target-app effect semantics still depend on real fixtures.
• Delivery on Doze, OEM and FCM devices needs real-device measurement.
• Correctness depends on careful implementation of the commit, witness-intent and ledger protocols under fault injection, as the plan itself states.

NO SUBSTANTIVE FINDINGS

Round 22 disposition

Input: revision 28, SHA-256 20ad0a6a14d8f2ca44bc61d76d921268c8bcb684a9cbeca54bf6299f361ed7c4.

Opus completed a clean full-plan review. Both GLM scopes completed cleanly, with exact-text coverage of all 18 sections. K3 completed with one low-severity no-admission finding. All processes exited zero with nonempty final reports.

K3 L1: incomplete busy-state no-admission contract

Accepted. Revision 29 defines one authenticated, submission-bound proof for all admission rejections, plus explicit retry classes and distinct outcomes for Update installing, Mac authority starting, Update waiting, and Storage unavailable.

The suggested immediate manual-only retry for the last two states was not adopted. That could add a user rerun when a short busy state clears. Instead, all four use bounded automatic wait and fresh resubmission under one caller deadline that cannot reset when reasons change. An indefinite drain never causes an indefinite caller wait. Expiry, caller lifetime, cancellation and input semantics stay intact.

Permanent rejection, unknown retry classes and ambiguous responses never trigger automatic resubmission. GUI capture uses the same busy-state classification with original age/expiry. Sections 8, 12, 17 and 18 agree and include acceptance cases.

Non-blocking observations

Opus's optional authenticated pre-submission hello and unexpected-restart command retry suggestions remain observations, not adopted behavior. K3's optional-drain tradeoff is already disclosed by the explicit user-selected action and remote cancellation controls. No extra confirmation was added.

Migration ceremony, idle interval and retention remain pending choices. Platform feasibility remains unverified.

Round 22 review — GLM compatibility scope (sections 1, 2, 17, 18)

Prior disposition verification (revision 28)

Opus F1 (witness-fault ordering): Present. §18 acceptance ("Inject transient witness faults… immediate restrictive enforcement, delayed permissive effects, automatic intent reconciliation, and accurate pending status") matches the accepted design; the phased-intent mechanism itself lives in out-of-scope sections and is not contradicted here.

Opus F2 (starting-state submission): Correctly merged. §17 defines the authenticated, submission-bound "Mac authority starting" no-admission result alongside "Update installing", with the same bounded readiness wait, distinct caller-deadline status, stdin/PTY preservation, fresh submission, and GUI recapture-while-present rules; the §18 acceptance bullet covers deadline exhaustion and unverified health hints. Timeouts and lost acknowledgments still never prove no-admission.

Independent checks performed

• Binding UX (§1): Biometric table matches the frozen exceptions (LS allow-once/deny-once/cancel/dismiss without biometrics; every reusable rule, session/timed rules, and Forever with biometrics). No path in §17/§18 adds confirmations, forced physical access, re-pairing, shortened response windows, or manual steps; §18 explicitly preserves pairing across version drift, and update waits never shorten admitted requests' approval lifetimes.
• Admission atomicity and retry safety (§17): Quiescence check plus admission close is atomic with request creation and permit dispatch; only authenticated submission-bound no-admission results trigger transparent wait/resubmit; uncertain outcomes reconcile or report, never replay. Recapture after unexpected restart is restricted to established-never-consumed identities, preserves first-seen age and original expiry, and requires a fresh decision — consistent with the restart matrix and §1's one-decision-per-captured-action rule.
• Floors and identity (§17): Generation checks derive from OS-validated metadata on every privileged RPC; floor commits only via the activation transaction; anti-rollback is required to exist independently of the candidate binary, with the placement/key-custody gates carrying explicit failure/consultation paths rather than silent weakening.
• Drain and automatic activation: The automatic path never freezes admission while work is pending; user-initiated drain is cancellable from Mac and phone, shows blockers, and preserves normal request/command/permit lifetimes. No contradiction between the two paths.
• §18 negotiation and contract selection: Envelope and request-contract selection are separately authenticated; floor/feature exclusion precedes the maximize-eligible-phones tie-break (consistent with the v1/v1+v2 acceptance case); stale capability records can only reduce reachability; domain separation prevents status/approval cross-verification; canonical-byte and unknown-field rules are coherent.
• Cross-references (§3 protected placement, §5–7 keys, §6 restart rule, §12 ledger recovery): No conflicts introduced by the in-scope text.

No substantive actionable defects found; no correction needed, so none can worsen UX.

NO SUBSTANTIVE FINDINGS

Round 22 review — recovery scope (revision 28)

Scope checked: §1 (approval flow, biometric table, UX constraints), §2 (threat boundary, signature semantics), §12 (audit journal, atomic writes, recovery classification, sync, retention), with the cross-referenced §16 witness gate and §17 failure/recovery excerpts.

Dispositions verified against current text

• Round 21 / Opus F1 (witness-fault ordering): present and coherent. Prepared/anchored/finalized intent phases; restrictive effects immediate in the live process with durable intent; permissive effects and repeatable control-plane side effects held for durable anchoring; restrictive-ahead intents roll forward after restart; ambiguous writes reconciled by operation ID; local enforcement and durable completion reported separately; no claim that a never-anchored operation survives whole-backup restore. No conflict with §12's per-action crash protocol ("Per-request action consumption retains section 12's separate crash protocol").
• Round 21 / Opus F2 (starting-state submission): present and coherent. Submission-bound authenticated no-admission result, bounded wait, resubmission and GUI recapture per §17; generic health indications and lost responses cannot trigger replay; input preserved unconsumed and cancellation preserved while admission is closed; the status grants no action authority.

Independent checks performed

• Recovery classification is exhaustive and mutually consistent across §12/§16/§17: protocol-resolvable interruption (auto rollback/roll-forward, no dispatch) vs. history-only loss (fresh epoch, labelled discontinuity, no admin repair) vs. genuine continuity mismatch (recovery-required marker, repair path) vs. transient witness/storage failure (retryable starting state, bounded backoff). Marker-write failure, restart-skips-checks, and timeout-is-not-rollback hazards are all explicitly closed.
• Replay/rollback safety: random per-start epochs plus per-epoch cursors prevent sequence reuse after backup restore without relying on the witness for audit-only truncation; phone receipts and cached old-epoch records are preserved read-only; consumption ledger and audit event commit in one pre-dispatch transaction; post-dispatch interruption records Unknown and never retries.
• Flood resistance: no durable per-packet events for unauthenticated traffic; authenticated rejection telemetry (including revoked-key replays) rate-limited with bounded counters; reserved lifecycle budget for admitted requests.
• Binding UX intact: biometric table matches the frozen contract (command/1PW/credential and all rule-setting including Forever, session, and timed rules require one biometric; LS allow-once/deny-once/cancel and dismiss/decline require none); no forced warning modals or truncation; witness gate fails explicitly and consults the user rather than silently requiring GUI login, online checks, physical access, or re-pairing; manual Mac approval remains available on every repair path; history reading needs no extra biometric and cannot approve or replay.
• Prior-round acceptance cases (power loss at each commit phase, duplicate service starts, lock replacement, live journal replacement, head mismatch plus crash/restart/reboot/restore, cursor-ahead-of-journal, sustained forged traffic) are all carried in the text.

No internal contradictions, authority-bypass paths, replay/rollback gaps, UX regressions, or mis-scoped claims found in the reviewed sections.

NO SUBSTANTIVE FINDINGS

Independent plan review — revision 28

Scope reviewed: full plan, with attention to the revision 27→28 additions (live witness-fault ordering, retryable no-admission responses) and their interactions with sections 8, 12, 16, and 17. Prior disposition reasoning was checked against the revised text; F1 and F2 appear correctly and minimally resolved (typed intent with prepared/anchored/finalized phases, restrictive-live/permissive-held split, submission-bound no-admission proof with no replay on ambiguity). No tools were used; this is a consistency review of the plan text only.

Finding

L1 — The authenticated no-admission contract covers only two of the four pre-admission rejection states

Sections: 17 "Automatic activation and optional drain"; 12 "Atomic journal writes" (storage-condition rejection); 8 "Process I/O and terminal outcomes".

Scenario: Revision 28 correctly establishes that an ambiguous admission result is dangerous (a caller cannot distinguish "never admitted" from "maybe admitted", so only an authenticated, submission-bound no-admission proof may trigger transparent wait and resubmission). But that contract is specified only for Update installing and Mac authority starting. Two other states reject admission pre-dispatch without the same treatment:

1. Update waiting (§17 drain): "return Update waiting with a retryable status". The text does not state that this response is authenticated and submission-bound, and does not define caller behavior. A drain may be indefinite (a long-lived command defers activation indefinitely), so the bounded transparent wait rightly cannot apply — but the plan never says what the frontend does instead. An implementer could reasonably either transparently wait (stalling a coding tool for hours behind an explicit drain, contradicting "show the caller that approval is waiting"/"useful errors") or treat it as terminal (losing the retryability the plan promises). A forged unauthenticated Update waiting from the relay is availability-only, but the ambiguity itself is the defect class F2 just fixed.
2. Storage-condition rejection (§12): "If essential recording cannot be guaranteed, reject new admission before dispatch and expose the storage condition." No statement that this is a submission-bound no-admission result, no distinct status in §8's list, and no defined caller/frontend behavior (retryable like the witness-starting state, or terminal?). §12's own witness-starting state gets the full retry contract; the journal-capacity rejection right next to it does not.

Minimal correction (no UX change): In §17 and §12, state that all pre-dispatch admission rejections — Update installing, Mac authority starting, Update waiting, and storage-condition — use the same authenticated, submission-bound no-admission proof, and classify each in §8's distinct-status list. Define caller behavior per state: bounded transparent wait only for states that are inherently bounded (Update installing, Mac authority starting); an immediate distinct terminal status with visible drain/storage state and manual retry for Update waiting and storage-condition. This adds no confirmations, biometrics, or manual steps beyond what the plan already shows in the menu/phone status surfaces.

Tentative UX choices remaining (not defects)

• The authority-key migration ceremony (§3) remains an explicitly unresolved user-choice gate — correctly carried as pending, per the disposition.
• Indefinite drain semantics: an explicit "Install when current work finishes" plus a long-lived command suspends all new admissions (including 1Password/Little Snitch) until the drain completes or is cancelled. The plan discloses this and provides defer/cancel on both surfaces, so it is a designed tradeoff — but it is worth explicit user confirmation at implementation time, since it is the one path where a user-initiated action can silently-feeling block unrelated approvals for an unbounded period.
• Deferred preferences (idle interval, retention budget, macOS 14 floor, FCM choice) are explicitly gated and not findings.

What was assessed and found sound

• Witness-fault ordering (§16/§12): restrictive-live/permissive-held split, operation-ID reconciliation, no claim that unanchored operations survive whole-backup restore, and fail-closed-on-persistent-fault are internally consistent with §5 revocation, §17 floor commit, and §12 epoch anchoring. Per-request consumption correctly retains the separate §12 crash protocol.
• No-admission retry (§17/§8): fresh capture + fresh decision on resubmission, stdin/PTY non-consumption, caller-lifetime retention, and the explicit "timeout/lost ack is not proof of rejection" rule close the original F2 hole for the two covered states.
• Command binding (§8): capture-before-approval, verified-requester vs. caller-label separation, stdin-source disclosure, no atomicity claim without descriptor-based execution (gated), sudoers compatibility gated.
• Biometric/credential (§7): one-CryptoObject operation remains a properly bounded feasibility gate; key separation (biometric vs. narrow decision key vs. routing/scheduling purposes) is consistently enforced at both verifiers (§6, §9).
• UI races (§9, §6): permit-before-mutation, one bounded attempt, unknown-on-failure, no retry, one-time scope validation for Little Snitch; the confirmed allow-once tradeoff is not widened to commands or 1Password.
• Recovery/routing/push/relay/update/evolution (§12–§18): epoch model, first-valid-decision consumption, gateway control plane with possession proofs, activation/floor transaction, and mixed-version rules show no contradictions with the §3/§5/§6 invariants. Relay cannot mint decisions; downgrade floors are anchored in the trust witness.
• Remote UX preserved: no new mandatory confirmations, lock-screen surfaces, or delivery guarantees were introduced by the revision 28 changes.

Remaining verification limits: this review cannot validate the feasibility gates themselves (witness availability pre-login, one-biometric credential release, descriptor-based execution, 1Password/Little Snitch AX contracts, local command-approval path); those are scheduled work with defined failure/consultation paths, not plan defects.

Conclusion

SUBSTANTIVE FINDINGS REMAIN — one low-severity finding (L1): extend the authenticated, submission-bound no-admission contract and defined caller behavior to the Update waiting and storage-condition admission rejections (§17, §12, §8). The correction is spec-completing only and introduces no UX regression.

Remozio plan review: revision 28 (reviews/round-22-plan.md)

Findings

I found no substantive planning defects in revision 28.

Disposition of round 21

Opus F1: live witness-fault ordering. The fix holds.

• §16, Feasibility gate: restored trust state, now separates two kinds of effect:
  • Restrictive effects (revocation, floor enforcement, replay-ID reservation) apply immediately in the live process.
  • Permissive effects and repeatable side effects (enrollment, mapping publication, scheduling) wait for the durable anchor.
• A restrictive-ahead intent rolls forward after restart.
• An ambiguous write reconciles by operation ID, so a retry cannot finalize a different operation or publish twice.
• Unknown or conflicting intents stay genuine recovery failures, which keeps "recoverable" from covering arbitrary mismatches.
• A failed write of the intent itself falls under the §12 storage-failure rule, so admission stays closed. I found no path where a revoked phone regains authority, other than the disclosed limit that a whole-backup restore can undo a never-completed operation.
• Revoking and replacing a phone during a persistent witness fault can leave no active phone. The §5 "no approval surface remains" rule then applies. This is honestly surfaced, not silent.

Opus F2: starting-state submission behavior. The fix holds.

• §12, Atomic journal writes, and §17, Automatic activation and optional drain, now give Mac authority starting the same treatment as Update installing:
  • The response must be authenticated and bound to the submission.
  • Wait, resubmission, and cancellation are bounded.
  • stdin/PTY input is preserved.
  • Resubmission uses a fresh capture and requires a fresh decision.
• A generic health hint, timeout, or lost acknowledgment explicitly cannot trigger replay.
• For UI requests (§17, State across restarts), recapture preserves the original age and target deadline and does not revive expired authority.

What I assessed

• Scope and key separation
  • The biometric-free set is limited to cancel, deny-once, and Little Snitch allow-once.
  • Every reusable rule needs biometrics, including Forever and temporary or session rules.
  • The key class comes from retained action semantics, not message claims (§1, §6, §9).
  • Unknown compatibility contracts cannot inherit one-time classification.
  • Command execution and 1Password stay biometric-only.
• Relay resistance
  • The relay, transport, gateway, and push token cannot mint decisions, alter mappings, or read payloads.
  • Token possession uses a challenge before mapping activation (§15–§16).
• Command binding (§8)
  • Capture comes first, including stdin source and environment.
  • Rendering is unambiguous, execution uses no extra shell, and the no-child-started outcome is distinct.
  • Descriptor execution and sudoers compatibility are properly scheduled feasibility gates with consultation paths.
• Android (§7)
  • Consent binds to one immutable selected request, and there is no keyguard surface.
  • Single-biometric credential release is a gate with an explicit fallback to user consultation.
  • Pairing preservation follows the documented recovery path.
• UI races (§9)
  • The permit is consumed before any dialog mutation, and a failure after mutation is Unknown.
  • A late adapter cannot act on an invalidated permit.
  • Refresh never replays an approval.
• Recovery, audit, and updates
  • An epoch and journal checkpoint sit between the per-action crash protocol and the witness anchor. Recovery from history-only loss versus an authority mismatch is classified.
  • Floors are proposed until activation commits. Anti-rollback does not depend on the candidate binary.
  • Updates are quiescence-gated with no forced kills. Negotiation is authenticated and never re-encodes an existing request into a weaker schema.
• Remote UX
  • No new confirmations, biometrics, command restrictions, or shortened windows were introduced.
  • Manual routing controls are persistent and need no extra authentication.

Non-blocking observations (no action required for convergence)

1. Gap between old and new authority processes (§17, Automatic activation and optional drain). A command sent just as the old root exits, before the new root answers, falls into "unknown admission": no auto-resubmit, so the user sees an uncertainty report.
   • One option is an authenticated hello before transmitting the submission. A connection failure before that point would then be a locally known no-admission.
   • This would improve UX and worsen nothing. It fits naturally in the service-installation and update-continuity feasibility work.
2. Command requests after an unexpected root restart (§17, State across restarts). Never-consumed UI requests are recaptured automatically, but never-consumed command requests end with "explain fresh submission".
   • This is a coherent current policy, not a defect.
   • Automatic command resubmission would be a UX improvement to raise with the user, not something to adopt silently.

Tentative UX items still open (not defects)

• Migration ceremony (§3, Key custody and pre-login transport): an explicit user-choice gate.
• Idle-interval default (§14): an explicitly deferred preference.
• Retention duration and budget (§12): an explicitly deferred preference.
• Optional detached command mode (§8): requires a separate user decision.

Limits of this review

This is a plan-only review; I executed, inspected, and tested nothing. All of the following remain unproven until the scheduled gates and tests run:

• Secure Enclave or other key custody that is available before login.
• Witness mechanism availability and rollback detection.
• Protected placement and anti-rollback enforcement for root code under Sparkle and service management.
• Descriptor-based execution.
• Single-operation BiometricPrompt credential release.
• Little Snitch and 1Password true one-time semantics and AX stability.
• Cloudflare Access noninteractive credentials and permission scoping.
• FCM delivery under Doze.

Convergence from earlier rounds does not carry over; this verdict covers revision 28 only.

NO SUBSTANTIVE FINDINGS

Round 21 disposition

Input: revision 27, SHA-256 d658fd713b319c9f17600ae29edc410366dbebcc31af937b4eed48bfadec3128.

K3 completed a clean full-plan review. GLM completed the recovery scope cleanly. Opus completed with two findings. All processes exited zero with nonempty reports and normal final output.

Opus F1: live witness-fault ordering

Accepted. Revision 28 defines a typed durable intent with prepared, anchored and finalized phases. Restrictive effects apply immediately in the live process; permissive effects and replay-sensitive control side effects wait for durable anchoring. Recognized restrictive-ahead intents roll forward automatically after restart. Ambiguous writes reconcile by operation ID before retry.

Pending local enforcement and durable completion are distinct statuses. The text explicitly avoids claiming that a never-completed operation survives whole-backup restoration. Unknown or conflicting intents remain real recovery failures. No new user step is introduced.

Opus F2: starting-state submission behavior

Accepted. An authenticated, submission-bound Mac authority starting response may confirm no admission. It uses the same bounded wait, cancellation, stdin/PTY preservation, fresh submission and GUI recapture rules as Update installing. Generic health hints, timeouts and lost acknowledgments never prove no admission. Caller deadline exhaustion has a distinct status, and UI age/expiry remain unchanged.

Acceptance cases cover live witness faults, interrupted intents and both new retry paths. The migration ceremony remains an unresolved user-choice gate.

Round 21 review — GLM scoped recovery pass

Scope: §1, §2, §12, plus the labelled §16 gate and §17 recovery excerpts, revision 27.

Prior disposition verification

The round-20 Opus F1 correction is verifiably present in the current text:

• §16 requires the witness to be readable/writable in the root/daemon context before GUI login, while locked, without an Aqua session; a login-keychain-only mechanism is explicitly insufficient, and gate failure routes to user consultation.
• §12 places transient witness/storage faults (including the epoch-creation write) in a retryable, admission-closed starting state with bounded backoff, an honest "Mac authority starting / storage unavailable" status, preserved cancellation, unconsumed input, and an explicit rule that timeouts alone cannot trigger administrator recovery.
• The required tests (login-window SSH approval, transient first-start witness fault) appear in §16.

No regression of that fix was found, and no UX-protected behavior was weakened: the biometric table still matches the binding contract (one biometric for command/1Password/credential and all rule-setting decisions; none for LS once/cancel/dismiss), and §16 still forbids approving online checks, recurring authorization, physical access, or forced re-pairing without consultation.

Independent checks performed

• Journal atomicity and recovery classification: the four states (protocol-resolvable interruption, history-only loss, genuine continuity mismatch/unresolvable, transient unavailability) are disjoint and each has a defined admission, persistence, and UX outcome; partial commit never permits dispatch; neither recovery path retries actions; recovery-required marker failure degrades to closed admission with independent startup revalidation. Internally consistent with §16's continuity gate and §17's no-rollback-below-floor rule.
• Epoch and sequence integrity: fresh random epoch per service start, no resumption in persisted epochs, head verification before append, head-mismatch handling, prior-head linking, phone-side cursor/receipt conflict handling, and retention-boundary signing are mutually consistent; sequence reuse after backup restore is prevented without claiming the witness detects audit-only truncation.
• Flood resistance: unauthenticated traffic gets bounded aggregate counters only; authenticated rejection telemetry (including revoked-key replays) is rate-limited with dropped-event counts; lifecycle budget reservation plus reject-admission-before-dispatch prevents rejection floods from forcing early pruning or spending the consumption/outcome reserve.
• Metadata hygiene: closed action/scope classes with no bound target values, unknown-value mapping, no biometric samples, and no person-identity claims; consistent with the memory-only pending payload rule and the detail-view disclosure.
• Cross-section coherence: §1's dismissal/cancellation distinctions, one-decision-one-action binding, and current-display-only signing align with §12's event distinctions and no-replay rules; §2's threat boundary, adapter-asserted UI details, and honest signature-semantics claims match the audit schema's authentication classes.

Conclusion

NO SUBSTANTIVE FINDINGS

Independent review — Remozio plan, revision 27

Scope assessed: full plan, including post-revision-5 additions (audit journal/epochs, request age/expiry, presence routing, push, LAN/relay + Cloudflare, gateway control plane, component identity/Sparkle, protocol evolution, mixed devices and component versions), plus the round-20 disposition changes (pre-login witness availability, transient-fault recovery). Plan-only review; no testing, browsing, or source inspection was performed or is claimed.

Areas specifically exercised

• Cross-invariant consistency: consumption-before-dispatch (§6, §12) vs. memory-only pending payloads and restart cancellation (§6, §17 matrix) vs. recapture rules after unexpected root restart (§17) — consistent; recapture is restricted to never-consumed identities with fresh challenge and preserved age.
• Epoch/witness interplay (§12, §16): fresh random epoch per start, checkpoint anchored at epoch creation and trust/floor/replay changes, transient witness faults in a retryable admission-closed state with automatic backoff (round-20 fix), distinguished from genuine continuity mismatch requiring administrator recovery. No contradiction found; "a timeout alone is not rollback evidence" resolves the prior failure mode without weakening rollback detection.
• Downgrade/replay coverage: decisions bind digest + challenge (§6); routing and update-scheduling controls bind operation ID, revision, expiry under the narrow decision key with no target-action authority (§6, §14, §17); gateway controls bind lifecycle epoch + monotonic revision with authenticated-head reconciliation and revocation tombstones (§16); negotiation transcript authenticated and floors persisted independently of replaceable binaries (§17, §18); request re-encoding to weaker schemas forbidden (§18). No gap found.
• Scope classification: one-time vs. reusable effect classification from retained semantics and validated per-app/version behavior, enforced independently by root and adapter, with unknown compatibility contracts barred from inheriting one-time classification (§1, §6, §9). The Little Snitch allow-once exception remains narrowly confined; it is not widened to commands or 1Password.
• Privileged update path: protected-placement invariant, external activation boundary, floor commit only after quiescence and replacement checks, update-installing no-admission responses with bounded caller wait and fresh resubmission (§3, §17). The acknowledged tension (Sparkle vs. root-owned placement, possible renewed administrator authorization) is an explicitly defined feasibility gate with a consultation path, not a defect.
• UX preservation: biometric-free cancel/deny-once/allow-once retained; no lock-screen surface (matches the clarification); no forced warnings or truncation; 5-minute provisional expiry; streaming stdin preserved; update/routing controls add no biometric prompts and grant no action authority; routing changes cannot strand requests silently (§1, §7, §13–15, §17).

Tentative UX choices (already recorded as pending decisions, not defects)

These remain open per the plan's own tracking and are flagged only for visibility: the migration-ceremony cost and its remote flow (§3), the single-biometric credential-release outcome (§7), the sudoers-policy choice (§8), the atomic-execution options if descriptor-based execution fails (§8), StrongBox-vs-TEE and biometric-invalidation policy (§4, §5, §7), the local command approval surface (§14), the idle interval, and the retention duration/budget. None may be silently resolved; all have defined evidence-and-consultation paths.

Remaining implementation verification limits

Convergence here means no unresolved planning defects. It does not establish: Secure Enclave pre-login custody + code-identity restriction feasibility; a witness mechanism meeting the combined availability/anti-rollback requirements; 1Password/Little Snitch AX fixture behavior and true one-time semantics; descriptor-based execution; background Access authentication; privileged installation/anti-rollback enforcement on the macOS 14+ floor; push delivery under Doze/force-stop. Each is a scheduled gate with a failure/consultation path.

Conclusion

NO SUBSTANTIVE FINDINGS

The revision-27 plan is internally consistent across its earlier invariants and the newer audit, routing, transport, update, and protocol-evolution requirements. The round-20 disposition (pre-login witness availability, automatic transient-fault recovery) is correctly integrated in §12 and §16 without contradicting rollback detection or the remote-UX contract. All flagged uncertainties are defined feasibility gates or recorded pending user decisions rather than unexamined assumptions.

Remozio plan review: revision 27

Findings

F1 (Medium): Trust-changing commits have no defined behavior during a transient witness fault

Sections: §12 Atomic journal writes; §16 Feasibility gate: restored trust state; §5 Revocation and pairing recovery; §17 Activate and commit security floors.

Defect. Revision 27 defines transient witness faults only for startup and epoch creation. That state is a retryable start with admission closed. However, §12 and §16 also anchor the witness at every authenticated trust, floor, or replay-control change. Those changes happen while the service is live. The plan does not say what happens if the witness write times out or fails at that point.

Failure scenario. An administrator revokes a lost phone over SSH while the witness is temporarily unavailable. Two readings of the plan are both plausible, and both are bad:

• Revocation waits for the witness. The lost phone keeps authority until the witness recovers. This contradicts §5, which says Mac-side key removal "immediately invalidates" the phone.
• Revocation commits locally anyway. The local trust state is now ahead of the witness. §16 says "A partial commit must not pair newer authority with an older witness." §12 sends a genuine mismatch to administrator recovery. So a transient fault turns into a manual repair, which §12 now forbids.

The same ambiguity applies to a floor commit during update activation (§17) and to replay-control commits for routing, scheduling, and gateway controls.

Why this is not covered by the feasibility gate. The gate's "interrupted-write recovery" item is about mechanism. The missing piece is ordering policy: which side may lead, and whether that state is legitimate.

Minimal correction.

1. Make restrictive changes (revocation, tombstones, floor raises, consumption of replay controls) take effect in the live process immediately and fail closed. They retry the witness anchor with bounded backoff, as §12 already does for startup.
2. Hold permissive changes (enrollment, new mappings) until the witness commit completes.
3. Define the resulting "local restrictive state ahead of witness" condition as protocol-resolvable. On restart it should roll forward automatically, not be treated as a genuine mismatch.
4. Add tests for revocation and floor commit under an injected transient witness fault, including a crash before the retry succeeds.

UX impact: none. This preserves remote revocation and avoids a manual step.

F2 (Low): Caller and adapter behavior for "Mac authority starting" is unspecified

Sections: §12 Atomic journal writes (retryable starting state); §17 Automatic activation and optional drain and State across restarts.

Defect. §17 gives transparent wait-and-resubmit behavior, and GUI-adapter recapture, only for an authenticated Update installing no-admission result. The new §12 starting state also guarantees no admission and preserves unconsumed input. However, the plan does not say whether the command frontend and GUI adapter treat it the same way.

Failure scenario.

• Command frontend. It may exit immediately. A remote coding agent's privileged command then fails during a brief witness hiccup after reboot. The user has to rerun it manually, which is a remote-UX regression.
• GUI adapter. It may never recapture a 1Password prompt observed during the starting window. That prompt then silently misses its roughly 60-second lifetime.

Minimal correction. Make the starting-state response an authenticated, submission-bound no-admission result. Apply the existing §17 bounded wait, resubmit, and recapture rules to it, with the same cancellation, caller-lifetime, and stdin/PTY guarantees. Return a distinct status when the caller's deadline is exceeded, and add this case to the §18 acceptance list.

UX impact: none. This improves UX and does not shorten any window.

Prior disposition (round 20)

The Opus F1 correction is sound for startup and epoch creation. F1 above is the concrete residual case it did not reach: live trust commits.

Tentative UX choices

These are already recorded as pending and are not defects:

• The migration ceremony.
• The idle interval.
• Retention.
• The sudoers-policy selection.
• The atomic-execution fallback.

Assessment

I found no new contradictions in:

• scope classification or the separation between the decision key and the biometric key;
• relay or gateway authority;
• negotiation downgrade handling;
• update activation and floors;
• the multi-phone consumption ledger.

All of these remain subject to their stated feasibility gates.

SUBSTANTIVE FINDINGS REMAIN

Round 20 disposition

Input: revision 26, SHA-256 e109308dc3797d91e317eed647c6e29d05ba80f49e280b03135dd8edcc56516d.

K3 completed a clean full-plan review. Opus completed with one availability finding. GLM reached its output limit without a final report; it is not counted as clean. The next GLM pass narrows to the changed audit/recovery text and relevant cross-section context, retaining exact unchanged prior coverage.

Opus F1: pre-login witness access and transient faults

Accepted. Revision 27 requires the witness to be readable and writable in the root/daemon context before GUI login and while locked. A mechanism requiring an Aqua session fails the gate; the user must be consulted before any such change.

Transient witness or storage faults enter a visible retryable starting state with closed admission and automatic bounded-backoff retry. A timeout alone is not rollback evidence and cannot trigger administrator recovery. Cancellation and unconsumed input are preserved. Tests cover SSH approval at the login window and a transient first-start witness failure.

The correction preserves the existing remote UX. Migration interaction remains pending user choice; no answer or approval is inferred.

Independent review — Remozio plan, revision 26 (full-plan pass)

Scope assessed

I reviewed the complete plan, including all post-revision-5 additions: audit/journal epochs (§12), request age and dual-deadline handling (§13), presence routing (§14), required push (§15), LAN/relay and gateway control plane (§16), code identity and Sparkle updates (§17), and protocol evolution/mixed versions (§18), cross-checked against the earlier invariants (§§1–9) and the round-19 disposition.

Specific contradiction and downgrade/replay checks performed:

• Authority vs. audit recovery (§12/§16/§17): The revision-26 split (per-action crash-consistent local commits; witness anchoring only at epoch creation and trust/floor/replay-control changes) is internally consistent. Automatic recovery for history-only loss, closed admission on genuine mismatch, memory-only pending payloads, and no-resurrection rules agree across all three sections. The round-19 disposition matches the plan text; I found no unresolved scenario in it.
• Key separation: biometric, decision, transport, authority, credential, gateway-control, management, and push credentials are distinct purposes with distinct custody (§3, §6, §7, §16 table). Decision-key purposes (once-decisions, routing, update scheduling) are explicitly barred from target-action, enrollment, release-signing, and mapping authority in every place they appear; both root and adapter re-derive key class from retained semantics, not caller/phone labels.
• Decision-key verification chain (§6): once-decisions bind full digest/challenge/scope and are verified at root and adapter; the permit ledger is consumed before any dialog mutation including Deny/Cancel (§9). Allow-once stays confined to the captured Little Snitch alert, with second-attempt validation scheduled.
• Downgrade resistance: authenticated negotiation transcript binding (§18), persisted floors independent of replaceable binaries (§17/§18), external installation-boundary anti-rollback, per-RPC generation checks, and the combined trust-generation witness gate (§16) form a coherent stack. Backup-restore and floor-rollback scenarios have explicit acceptance tests.
• Update path vs. remote UX: automatic activation only at quiescence; drain is optional and decision-key-authorized without biometrics; Update installing is pre-admission, so the required "fresh decision" on resubmission is the normal approval, not a repeated one; on-disk bundle replacement is correctly treated as activation; indefinite-command deferral is disclosed rather than killed.
• Routing/push consistency (§14/§15): no pushes while kept local, handoff preserves age/deadline/identity, first-decision-wins across phones and surfaces, resolution pushes are best-effort with authoritative fetch-before-action. The gated local command-approval path prevents "At my Mac" from silently stranding commands.
• Command binding (§8): capture-before-approval, stdin source classification with uncaptured-content disclosure, no-extra-shell execution, caller-exit boundary distinguishing no-effect vs. started/unknown, and the relocation/copy prohibition are mutually consistent.
• Audit metadata exclusions (§12): closed metadata classes vs. memory-only full payloads are consistently applied to journal, cache, sync, diagnostics, and retention.

Tentative UX choices (explicitly deferred — not defects)

• 30-second draft idle interval and 5-minute expiry default (§14, §5) — flagged in-plan as pending preferences.
• Audit retention duration/storage budget (§12) — deferred to implementation with the user.
• Migration ceremony cost and one-time phone interaction (§3) — gated user choice.
• FCM as provider and 1Password ~60s estimate (§15, §13) — to be validated.

These are recorded as pending decisions/gates with consultation paths; per the review rules they are not planning defects.

Remaining implementation verification limits

This is a plan-only review. Nothing here establishes: Secure Enclave/Keychain pre-login behavior, a working monotonic trust witness (the plan itself disclaims SEP counters and gates this), 1Password/Little Snitch AX stability, descriptor-based execution atomicity on macOS, Android background/Doze delivery in practice, Sparkle/service-management protected-placement satisfaction, or Cloudflare Access noninteractive renewal cost. Each has a defined feasibility gate with evidence requirements and a failure/consultation path; failure of any gate must produce a user decision, not a silent UX or security regression.

Conclusion

NO SUBSTANTIVE FINDINGS

Remozio plan review: revision 26

Scope: complete plan, plus the round 19 disposition. This is a plan-only review. I ran no tests and inspected no source, platforms or links.

Findings

F1 (Medium): the new witness write can block command approval after a reboot

Where:

• §12 "Atomic journal writes" (anchor the checkpoint to the witness at epoch creation)
• §12 "Sync and offline cache" (fresh epoch on every root-service start)
• §16 "Feasibility gate: restored trust state"
• §3 "Availability by session state"

Problem: Revision 26 creates a fresh epoch on every root-service start and anchors it to the combined witness. So every boot now needs a successful witness write before the root admits any request.

The §16 witness gate asks for crash-safe, offline, rollback-resistant behaviour. It does not ask for the witness to work before GUI login. It also does not say how a transient witness failure is classified.

§12 says that if current authority "cannot be established", admission stays closed and the existing repair path applies. That repair path is the manual administrator recovery.

Failure scenario:

1. The Mac reboots and nobody logs in.
2. The user opens an SSH session and runs remozio sudo -- ….
3. The witness uses a mechanism that is only available after login or unlock (for example, the login keychain), or its first write at boot fails transiently.
4. The root cannot anchor the new epoch, so admission stays closed.
5. A strict reading routes this to administrator repair.

The result is that remote command approval is broken after every reboot, or a routine hiccup becomes a manual repair. That contradicts the §3 requirement "command approval does not depend on GUI adapter availability / without Aqua login". It also contradicts revision 26's stated goal that routine interruptions recover automatically without an administrator. The §10 acceptance tests would catch this late, but the gate could select an incompatible witness first.

Minimal correction:

• Add "available and writable before GUI login, under the root/daemon context" to the §16 witness requirements and to the key-custody record.
• If this cannot be met, fail the gate explicitly and consult the user. Do not silently require login.
• In §12, classify a transient witness read/write failure at epoch creation as retryable closed admission:
  • show a visible "Mac authority starting / storage unavailable" status to the caller and the phone;
  • retry automatically;
  • use the repair path only for a genuine continuity mismatch or an unresolvable state.
• Add an acceptance case: reboot, stay at the login window, submit over SSH, and inject a witness fault at first start.

UX impact: none. This correction preserves the current UX and adds no confirmation, biometric or manual step.

Assessment of the round 19 disposition

Both items appear correctly resolved:

• Opus 1 (audit continuity vs. authority rollback): §12, §16 and §17 now state the same model. Per-action commits stay local and crash-consistent. The witness is anchored only at epoch creation and at trust, floor or replay-control changes. History-only loss recovers automatically into a new epoch with a visible discontinuity. I found no replay path:
  • pending payloads are memory-only;
  • challenges are fresh;
  • live recovery retires pending requests and quiesces permits;
  • §17 recapture requires established never-consumed state, so ledger loss yields Unknown rather than recapture.
• Opus 2 (routine interrupted commits): resolvable pre-dispatch and post-dispatch interruptions are distinguished from genuine mismatch. F1 is the one remaining place where the escalation rule is ambiguous.

Other areas assessed with no substantive issues

• Scope classification and key separation:
  • The decision key is limited to cancel, deny-once, true Little Snitch allow-once, routing and update scheduling.
  • Every reusable rule, including Forever and session/timed rules, requires the biometric key.
  • Both verifiers derive the required key class from retained semantics.
  • Unknown compatibility contracts cannot inherit one-time classification.
• Relay, gateway and cloud management: candidate-token proof, tombstones, revision reconciliation that only restricts authority, and a management controller with no network listener or approval authority.
• Command binding: stdin/PTY disclosure, requester-exit semantics, and the sudoers and descriptor-execution gates with consultation paths.
• UI races: consumed permits, scope-mutation-as-one-attempt, observed versus inferred target timeouts, and Refresh without replay.
• Updates and versions: automatic activation only when quiescent, protected activation independent of the candidate root, floor commit after replacement checks, and deterministic single-contract selection without re-encoding.
• Android: the single-biometric credential-release gate, pairing preservation on biometric change, and no keyguard surface.

Remaining open items (feasibility gates and preferences, not defects)

• Deferred product preferences: idle threshold, retention duration, and the migration ceremony.
• Feasibility gates with a defined consultation path:
  • Little Snitch true-once semantics
  • 1Password secure-field targeting
  • service-management placement and anti-rollback
  • non-exportable authority keys
  • background Cloudflare Access authentication

Implementation limits: none of the platform guarantees are established by this plan. That includes Secure Enclave, pre-login custody, witness monotonicity, XPC generation isolation and Android key-invalidation behaviour. All of them still need device evidence.

SUBSTANTIVE FINDINGS REMAIN

Round 19 disposition

Input: revision 25, SHA-256 83ed95d7636ef1f5e24f9bd5c2a2042cb2a73fdfae40587a0741d23161805e66.

K3 completed a clean full-plan review. GLM completed its scope cleanly. Opus found two issues in the new recovery text. All processes exited zero with nonempty reports. Earlier pending K3 results have also completed cleanly.

Opus 1: distinguish audit continuity from authority rollback

Accepted. Revision 26 chooses one explicit model: per-action crash-consistent local journal/checkpoint commits, with witness anchoring at epoch creation and trust/floor/replay-control changes. It does not require per-action witness writes or claim complete detection of audit-only truncation.

Authority continuity and writer ownership remain required. Historical audit/ledger loss alone recovers automatically into a new epoch with visible loss and Unknown outcomes. Memory-only pending requests are never restored; fresh challenges and consumed-state handling prevent replay. Live recovery retires pending requests and reconciles or quiesces permits without killing or retrying dispatched work. Sections 12, 16 and 17 now state this same model.

Opus 2: routine interrupted commits must recover automatically

Accepted. Revision 26 distinguishes deterministic protocol recovery from genuine mismatch or an unresolvable state. Pre-dispatch interruption resolves automatically with no action dispatched; possible post-dispatch interruption remains consumed and Unknown unless verified. Only real unresolved ownership or authority problems require the existing repair path. Tests require automatic recovery at every resolvable commit boundary.

This avoids potential UX costs identified in the review. No new manual step, biometric, recurring check, or migration ceremony has been adopted.

Round 19 review — GLM (identity/history focus)

Input: revision 25 excerpts, sections 1, 2, 3, 12, plus labelled cross-section context (16, 5, 17, release manifest). Prior disposition: round 18 (both Opus findings accepted).

Verification of prior disposition

Opus 1 (recovery-required state): fully incorporated. Protected continuity checkpoint and recovery-required marker outside the replaceable journal (§12); covered by the combined §16 gate ("Also cover the authoritative ledger/journal continuity checkpoint and recovery-required marker from section 12"); startup validates checkpoint, writer ownership, recovery marker, and ledger continuity before reopening admission or allocating an epoch; failed persistence of recovery state keeps the system closed and survives restart; crash-consistent commit protocol before dispatch with power-loss testing as an explicit feasibility deliverable.

Opus 2 (rejection floods): fully incorporated. Bounded aggregate counters for unauthenticated traffic; individual rejection records gated on verifiable current/retained enrollment signatures; authenticated rejection telemetry rate-limited with dropped-event counts; lifecycle budget reserved at admission; floods cannot force early pruning; storage failure rejects admission before dispatch; sustained forged/revoked-key flood tests specified.

Changed management boundary (§16 context)

Checked independently: provisioning requires both the root-only scoped credential and gateway-side owner authorization; control objects are typed, epoch/revision-bound, idempotent on retry; submission credential is wake-only. Token binding verifies possession without biometric or admin steps, keeps the prior mapping on failed/expired proof, invalidates candidates on revocation, and cannot be hijacked by token recycling (proof flows through the enrollment-authenticated Mac channel). Counter reconciliation requires the retained Mac-signed receipt with exact trust changes — a bare higher number is rejected; gateway evidence can only restrict authority, never enroll; verified revocations apply locally before phone operations; re-enrollment after a tombstone requires a fresh admin-authorized epoch. Local revocation is immediate regardless of gateway reachability; queued pushes grant nothing because the phone rechecks Mac authority. Rollback of enrollment, floors, controls, and the §12 checkpoint is covered by the combined trust-generation witness gate, with an explicit failure/consultation path and no approved UX change (no online check, recurring authorization, physical access, or forced re-pairing).

Binding UX constraints

Biometrics table in §1 matches the confirmed contract exactly (no biometric for dismiss/cancel/deny-once/allow-once; biometric for every rule-setting decision and all command/1Password/credential approvals — one prompt per decision). Token rotation needs no new administrator prompt; offline Mac defers rather than blocks; enrollment and recovery are remote-capable; migration ceremony remains a pending user-choice gate, correctly not claimed as resolved.

Consistency checks performed

• §12 epoch model: fresh random epoch per service start plus the prohibition on resuming a persisted older epoch prevents sequence reuse after audit-only rollback without relying on the trust witness; cross-epoch cursors, batch binding, discontinuity labeling, and read-only reconciliation of phone evidence are mutually consistent.
• §3 privilege boundaries: root-owned placement, per-XPC live code-identity validation, caller UID capture, pre-login transport key fallback correctly scoped away from authority/credential keys, one-time dispatch permits, and E2-end payload encryption over the relay are internally consistent with §2's trust assignments.
• §1 "one explicit decision authorizes one captured action" is reconciled by the reusable-rule carve-out with mandatory biometrics; no contradiction.

No correction in the reviewed text worsens UX; none is proposed.

NO SUBSTANTIVE FINDINGS

Independent plan review — Remozio revision 25

Scope: complete plan, with attention to post-revision-5 additions (audit journal, expiry/age, presence routing, push, LAN/relay, code identity, Sparkle updates, protocol evolution, mixed versions) and their interaction with earlier invariants. Plan-only review: no testing, browsing, or source inspection performed or claimed.

What was assessed

Command binding (sections 6, 8). Canonical immutable capture of argv/cwd/UID/env/stdin-classification before approval; digest recomputed by both phone and acting authority; direct exec without a shell; stdin/PTY disclosure rules; caller-liveness recheck at the execution boundary with distinct requester-exited outcome; executable-recheck race and sudoers compatibility are explicit feasibility gates with disclosure/consultation paths rather than assumed guarantees. No contradiction found with the no-truncation rule (oversize → distinct "Request too large" result).

Biometric and decision-key separation (sections 1, 6, 7, 14, 17). Purpose-separated keys with verifier-side derivation of required key class from retained semantics; the narrow decision key cannot reach commands, 1Password, credentials, enrollment, or reusable rules; both verifiers independently reject scope escalation. Routing and update-scheduling controls under the decision key are bounded (revision/operation-ID idempotency, no artifact supply, no floor alteration) and grant no action authority — deferring a security update does not weaken the already-committed floor. The confirmed Little Snitch allow-once exception is not widened.

Android biometric/credential handling (section 7). Immutable request binding across switching/rotation/backgrounding; lock-screen behavior matches the clarified UX (no over-keyguard surface); single-biometric credential release is a properly-scoped gate with an explicit two-biometric consultation path. Deferred biometric-invalidation policy is documented as a gate, not an assumption.

UI race handling (sections 6, 9, 13). One-time ledger permit covering scope mutation + final click as one attempt; mutation failure → Unknown, no retry; refresh-with-fresh-challenge model; observed-timeout vs. disappearance distinction; revalidation immediately before action including during an open biometric prompt; Once-vs-reusable classification based on validated effect, not button labels. Internally consistent.

Replay/downgrade resistance (sections 5, 12, 16, 17, 18). Serialized revocation vs. consumption; per-start random journal epochs with checkpoint/recovery marker outside the replaceable journal (round-18 Opus-1 fix is correctly integrated, including "restart cannot clear" and crash-consistent commit as a gate); bounded rejection telemetry with reserved lifecycle capacity (Opus-2 fix integrated without per-packet attacker-controlled writes); authenticated negotiation transcript binding; gateway control epochs/revisions/tombstones with signed-receipt reconciliation that cannot resurrect revoked authority; floor-commit transaction independent of the candidate binary.

Update path (section 17). Quiescence-gated activation; no killing of active commands or replaying approvals; frontend resubmission only on authenticated no-admission results with fresh capture/decision; restart matrix consistent with section 6 invariants; floor enforcement per-XPC-request against OS-validated build identity.

Recovery and remote UX. Remote-administrator recovery path preserved throughout (pairing, trust continuity, gateway registration); no added confirmations, biometrics, shortened windows, or removed remote functionality introduced by the reviewed revisions. Offline/LAN operation is preserved when the gateway is unreachable, and routing controls carry no hidden authority.

Flux reuse (section 4). Architecture-only reference pending license resolution; no copying. Acceptable as stated.

Remaining verification limits (not findings)

These are explicitly scheduled gates or deferred product preferences, correctly not treated as defects: Secure Enclave pre-login/custody feasibility, atomic command execution, sudoers compatibility, 1Password/Little Snitch AX fixtures and true one-time semantics, single-biometric credential release, protected update placement/anti-rollback enforcement, the trust-generation witness mechanism, background Access authentication, idle-interval default, retention duration, and the migration ceremony UX. Plan convergence cannot be claimed for these; each has a defined failure/consultation path. Process note: per the round-18 disposition, K3's result was pending when that snapshot froze — review-protocol convergence for revision 25 remains conditional on reconciling it; this is a process state, not a plan defect.

Conclusion

NO SUBSTANTIVE FINDINGS

Revision 25 is internally consistent across the earlier security invariants and the later audit, routing, transport, update, and protocol-evolution additions. I found no downgrade, replay, or privilege-boundary gap that is not already bounded by an explicit mechanism or a defined feasibility gate with a failure/consultation path, and no reviewed change silently degrades the confirmed UX contract. Remaining risk is concentrated in unproven platform feasibility (key custody/anti-rollback, atomic execution, dialog semantics, background delivery), all of which the plan itself defers to gated spikes; this review makes no claim those gates will pass.

Remozio plan review: revision 25

This is an independent review of the complete revision 25 plan. Earlier convergence is not assumed to carry over.

Most of the plan holds together, but two defects remain, both in the revision 25 journal-continuity additions. They conflict with the section 16 witness gate, and one can turn a routine power loss into a manual repair.

Finding 1 (Medium): Two contradictory designs for ledger and journal rollback detection

Sections: §12 Atomic journal writes, §16 Feasibility gate: restored trust state

The contradiction:

• Revision 25 says the continuity checkpoint covers "consumed-action and outcome boundaries" and must be protected by "the combined continuity gate in section 16", because "ordinary separate files are not sufficient protection against whole-backup rollback."
• §16 now lists "the authoritative ledger/journal continuity checkpoint and recovery-required marker" in the combined trust generation.
• The same subsection of §12 still says epoch handling "does not rely on the trust witness detecting an audit-only rollback."
• Recovery-required state must also survive "whole-backup restoration". Restoring a backup taken before the marker was written removes the marker, so only the independent witness could detect that.

Failure scenario:

• Read literally, the witness must be committed on every request consumption and outcome, which means on every command approval.
• §16 already warns against assuming a general monotonic counter. A witness mechanism that is adequate for rare trust and floor changes may be unsuitable for per-action writes because of write endurance, latency, or availability.
• If so, the combined gate fails. The documented failure path then withholds all action authority, or forces consultation, for a property the plan does not need.
• Pending payloads are memory-only (§6). A root restart cancels unconsumed requests, and every request has a fresh 256-bit challenge. A ledger-only rollback therefore cannot revive an old approval. Its real consequences are audit loss and loss of outcome evidence.
• Replay-relevant control state (routing, scheduling, gateway, enrollment revisions) is already covered by the trust generation.

Minimal correction: State one model explicitly.

• Use per-action continuity with a local crash-consistent checkpoint.
• Bind the checkpoint to the witness only at trust, floor, or control changes and at epoch creation.
• If only the audit/ledger state was rolled back and trust state is intact, show a labelled history-loss discontinuity and mark affected outcomes Unknown. Do not require administrator recovery for this case.
• Alternatively, if per-action witness commits are intended, make their write rate and latency an explicit criterion of the §16 gate.

UX impact: None. This correction avoids a potential loss of remote functionality.

Finding 2 (Medium): A routine crash during commit can force administrator repair

Sections: §12 Atomic journal writes (the "If that write fails, remain closed… A restart cannot clear the condition" paragraphs)

The problem: The text does not separate two cases:

• Protocol-resolvable interruption: power loss between the journal transaction and the checkpoint update, before dispatch.
• Genuine continuity failure: a detected mismatch or a failed recovery-marker write.

"Startup must also detect the incomplete checkpoint transaction" appears next to "remain closed" and "a restart cannot clear the condition." This reads as though any interrupted commit closes admission until the independent administrator recovery runs.

Failure scenario:

• The Mac loses power, or the kernel panics, during an approval commit while the user is remote.
• On reboot, command approvals stay closed until a manual admin repair. This conflicts with §12 Sync and offline cache ("A normal restart alone is not evidence of rollback") and with the remote-UX goals.

Minimal correction:

• Require the commit protocol to classify interrupted states deterministically.
• A pre-dispatch interruption should roll back or forward automatically and record Unknown only where dispatch may have occurred.
• Only a real mismatch, or an unresolvable state, should set a persistent recovery-required state.
• Add "power loss mid-commit recovers automatically" to the §12 acceptance cases.

UX impact: This improves UX. No consultation is needed.

Other areas assessed; no further substantive defects

• Rejection-telemetry bounds (Opus 2 disposition): reserved lifecycle budget, aggregate counters for unauthenticated traffic, and rate limits for revoked keys. This is adequate.
• Scope classification and keys: decision-key versus biometric-key purposes, including routing and update-scheduling controls. The Little Snitch allow-once exception is not widened to commands or 1Password.
• Revocation and restore: tombstones and rollback via the §16 witness.
• Compatibility: mixed-version request selection, with no downgrade on signature failure.
• Updates: update quiescence and automatic resubmission only on an authenticated no-admission response.
• UI actions: permit semantics for UI races.
• Remote fallback: the local-command routing gate.

The command binding (captured argv and stdin disclosure) and the credential-release and one-biometric gates remain correctly placed as feasibility gates with consultation paths.

Pending user decisions, not defects:

• the migration ceremony
• sudoers policy selection
• the idle interval
• the retention period

Implementation limits

This review is textual only. Every feasibility gate still requires real evidence, including:

• Secure Enclave custody
• the monotonic witness
• protected placement and anti-rollback
• one-biometric credential release
• Accessibility fixtures for 1Password and Little Snitch
• Android push and Doze behaviour

SUBSTANTIVE FINDINGS REMAIN

Round 18 disposition

Input: revision 24, SHA-256 875893ce0879fbee5e00ec2f4ea373863231b75dbc4b3a57ff9e72671288ba51.

GLM completed the changed scope with no substantive findings. Opus completed with two findings. K3 is still running when the next snapshot is frozen; its result will be reconciled separately. No pending process is counted as clean.

Opus 1: recovery-required state across restart

Accepted. Revision 25 requires a protected continuity checkpoint and recovery marker outside the replaceable journal, covered by the combined restoration gate. Startup checks both before admission and epoch creation. The journal/checkpoint commit protocol must be crash-consistent before dispatch. Partial commit or inability to persist recovery state cannot be cleared by restart. Unknown outcomes or non-enumerable history-loss intervals remain visible.

Ordering, reconciliation and power-loss tests are explicit feasibility deliverables. No platform primitive is assumed to exist. This preserves the existing repair and consultation paths.

Opus 2: rejection flood exhausts journal capacity

Accepted. Unauthenticated rejects use bounded aggregate counters, not one event per packet. Individual records require verified current or retained prior enrollment identity, and repeated authenticated rejects are bounded too. Capacity is reserved for real request lifecycles and outcomes. Forged and revoked-key floods cannot spend the reserve or force early pruning. Essential-storage failure rejects new admission before dispatch.

No added biometric or normal-use confirmation. Migration UX remains pending user choice.

Pending process resolved

K3 completed with exit 0 and a nonempty full-plan report. It reported no substantive findings; no additional correction was needed.

Round 18 review — revision 24, sections 1, 2, 3, 12 (+ sections 5, 16, 17 context)

Disposition verification (round 17)

• K3 1 (writer ownership): Correctly incorporated. §12 "Atomic journal writes" requires the OS-held exclusive process lock in protected storage for the service lifetime, transactional compare-and-set, stable lock identity validation across installation/restore/replacement, closed admission on ownership failure, no consumption or new epoch after head mismatch until recovery validates ownership and continuity, proof-gated automatic recovery with the existing repair path otherwise, and no kill/retry of dispatched work. All disposition commitments are present verbatim in behavior terms.
• K3 2 (trust generation in batches): Correctly incorporated. The batch field is the immutable epoch-creation trust generation from the authenticated epoch header; every batch for the epoch carries the same value with phone-side conflict rejection; normal revocation or floor commits do not rewrite it or reset history; it is explicitly descriptive, with channel and authority identity verified separately; audit metadata cannot enroll, lower a floor, or override trust state. Matches the disposition.
• Opus non-blocking note: Retained as caution; text still prohibits claiming continuous history without evidence.

Independent checks performed

• UX binding (§1, §2, §5, §16): Biometric table matches the binding contract exactly — one biometric for command/1Password/credential release; LS cancel/deny-once/allow-once without biometrics; every rule-setting decision (create/change/remove, session/timed/Forever) with biometrics; no silent Once downgrade; no forced physical access or re-pairing anywhere in scope; enrollment and admin recovery remain remotely performable; unreachable gateway never requires admin recovery; the restored-trust gate mandates consultation before any online-check/re-pairing UX change. Token rotation requires no biometric and grants no action authority, consistent with the contract.
• Gateway control plane (§16): Provisioning is operator-authorized and bootstrap-only; post-bootstrap mutations require Mac-authority-signed typed objects with owner/Mac/gateway/lifecycle-epoch/revision/operation-ID/expiry binding; idempotent retries; submission credential is wake-only; candidate-token flow prevents token-string redirection, late proofs after revocation, and offline-Mac mapping changes; counter reconciliation requires the Mac-signed receipt, applies only restriction (never enrollment), and suspends on unexplained trust-changing revisions; tombstones and re-enrollment epochs prevent revocation bypass; uninstall/reactivation require a fresh lifecycle epoch.
• Audit epoch mechanics (§12): Epoch-per-start with random IDs, no sequence resumption, prior-head linking, read-only reconciliation when a phone cursor exceeds retained history, old-epoch cursor isolation, and rollback labels are internally consistent and independent of the trust witness, as claimed.
• Restored-trust gate (§16): Failure/consultation path, atomicity constraint on partial commits, offline operation preservation, and test coverage (pre-revocation restore, floor rollback, stale controls, interrupted witness commits) are specified and consistent with §17 generation checks.

Minor observations (event ordering "by journal epoch" relying on prior-head links rather than the random epoch IDs themselves, and "exports" named once in acceptance cases without a defined export feature) are wording-level ambiguities already resolved by surrounding text; neither produces a concrete failure and neither warrants a requirement change.

Conclusion

NO SUBSTANTIVE FINDINGS

Independent review — Remozio plan, revision 24 (round 18)

Scope: full plan, all 18 sections, including post-revision-5 additions (audit journal/epochs, timing/expiry, presence routing, push, LAN/relay, code identity, Sparkle updates, protocol evolution). Plan-only review; no testing or source inspection claimed. I also reviewed the round-17 disposition and find its two K3 fixes correctly integrated (§12 writer lock/head-mismatch handling; epoch-creation trust generation as descriptive metadata).

Boundaries assessed

Command binding (§6, §8): Capture-before-approval, canonical digest recomputed by both verifiers, verified-requester identity from OS queries rather than caller labels, stdin source classification with explicit disclosure of uncaptured caller-controlled input, distinct exit statuses, and no-atomic-guarantee honesty (descriptor execution and the path/recheck race are explicitly gated with a no-silent-relocation rule). Consistent with §1's full-command display requirement.

Biometric/key separation (§1, §6, §7): The narrow decision key's purposes (one-time UI decisions, cancellation, routing, update scheduling) are enumerated and explicitly barred from commands, 1Password, credentials, enrollment, and reusable rules; both verifiers derive key class from retained semantics, not message assertions. The confirmed Little Snitch allow-once exception is not widened. "True one-time effect" validation, including second-attempt inheritance, is scheduled fixture work, not an assumed result.

UI race handling (§6, §9, §13): One-time permit consumed before any dialog mutation; scope selection + re-read + click as one bounded attempt; failure mid-mutation → unknown, no retry, refresh labeled with possibly-modified default; permit death/timeout → unknown with actor quiesce; expiry vs. disappearance vs. observed target timeout kept distinct. Internally consistent with the §17 restart matrix.

Replay/downgrade resistance (§12, §16, §17, §18): Fresh random journal epoch per root start with no sequence reuse; gateway control bound to lifecycle epoch + monotone revision with Mac-signed receipts required for counter reconciliation (a higher number alone is correctly rejected); floors persist independently of replaceable binaries; activation boundary is external to the candidate binary; negotiation transcripts are authenticated with domain separation, and security floors cannot be lowered by negotiation. The rollback/witness problem is honestly scoped as a feasibility gate with an explicit failure/consultation path and offline-operation preservation — per the review rules, not a defect.

Privileged update path (§17): Protected-placement invariant, no unprivileged-writable root code paths, quiescence-checked activation, floor commit as one durable transaction, no rollback below committed floor, and UX-preserving drain semantics (long commands defer activation rather than being killed). The "Update installing" bounded frontend resubmission correctly creates fresh capture and never replays decisions or pre-consumes stdin.

Relay resistance (§15, §16): Opaque push payloads, end-to-end payload encryption independent of Access/HTTPS termination, token-possession proof before mapping activation, transport credentials unable to mutate mappings, gateway never an enrollment authority, revoked-phone rejection at the Mac independent of gateway/Access cleanup.

Cross-section contradiction check: §14 handoff preserves immutable selection (§7) and first-decision-consumes (§6); §12 audit exclusions are consistent with §8's signed requester row (metadata classes are closed; raw values stay memory-only); §5 multi-phone delivery reconciles with §14 routing (routing gates delivery, ledger serializes consumption); §6 in-memory pending payloads match §17's no-cross-restart-handoff rule. No earlier invariant was found weakened by later additions.

Tentative UX choices (explicitly deferred, not defects)

Per the review rules these are recorded as pending user decisions, not findings: the automatic-routing idle interval (§14, 30s draft), audit retention duration/budget (§12), the migration ceremony cost/flow (§3), and the ~60s 1Password estimate pending per-version validation (§13). None is silently resolved in the plan.

Remaining implementation-verification limits

A no-findings conclusion is about planning coherence only. The plan's security claims still depend on: the §3 key-custody/pre-login spike, §7 single-biometric credential release spike, §8 atomic-execution and sudoers gates, §9 1Password/Little Snitch fixture validation, §14 local-command-approval path, §16 restored-trust witness gate, §17 protected-placement/Sparkle-version validation, and the Flux license remaining unresolved (§4 — reference-only reuse until then). Failure of any gate follows the documented consultation path; that is planned work, not convergence debt.

Conclusion

NO SUBSTANTIVE FINDINGS. Revision 24 is internally consistent across the new and old sections, preserves the confirmed UX contract (biometric-free once/cancel decisions, biometrics for all reusable rules, full command display, remote-first operation without recurring steps), keeps all three adapters in scope, and routes every unproven platform assumption through a defined feasibility gate with an explicit failure path rather than asserting it.

Remozio plan review: revision 24

Findings

1. Medium: the fail-closed journal state does not survive a service restart

Where: §12 "Atomic journal writes", together with §6 "Crash and uncertain-outcome handling" and the §17 "State across restarts" matrix.

The rules as written:

• A head mismatch stops appending and closes admission until recovery proves exclusive ownership and ledger continuity.
• The same subsection requires a fresh epoch "on every root-service start."
• It also says "a normal restart alone is not evidence of rollback."
• The only startup validation specified is for lock identity, not ledger continuity.
• The expected head that detects a mismatch appears to exist only in the live writer.

Failure scenario:

1. A concurrent maintenance path, or a live replacement, swaps in an older journal. That journal lacks the consumption records for actions already dispatched.
2. The live writer detects the mismatch and closes admission, as intended.
3. launchd KeepAlive, a crash, or a reboot restarts the service.
4. On startup the service acquires the lock and finds an internally consistent journal. It creates a fresh epoch, labels it a normal restart, and reopens admission.
5. The lost dispatched actions are never reported as Unknown. This violates §12 ("Keep unknown outcomes visible"), the §17 matrix row "Root-authority restart after consumption", and §12's "label the cause accurately".

The trust witness does not cover this case, because §12 explicitly does not rely on it for audit-only rollback. The random epoch prevents sequence reuse, but it does not detect lost consumption records.

Minimal correction:

• Persist a recovery-required marker in protected storage before closing admission. Startup must honor it.
• On every start, validate ledger continuity against a protected head record before reopening admission. This record should be written with each committed append, or covered by a witness-like mechanism.
• Otherwise, label the new epoch as a possible loss rather than a normal restart.
• Add "head mismatch, then restart" to the §12 test list.

UX impact: None in normal operation. Recovery already uses the existing repair path.

2. Low: rejected decisions from the network are durably journaled with no bound

Where: §12 "Events to retain" ("decisions received and accepted or rejected"), together with §12 "Atomic journal writes" and "Retention and replay safety".

The rules as written:

• A journal transaction failure blocks dispatch.
• Retention is bounded by a storage budget.

Failure scenario:

1. A network attacker or compromised relay (in scope per §2) floods forged or invalid decisions.
2. If each rejection is a durable audit event, the journal consumes its storage budget.
3. One of two things follows:
   • Retention prunes legitimate history early.
   • Journal writes fail, which blocks all new actions, including local command approvals that never touch the relay.

Dropping relay traffic already denies remote service. This attack goes further and degrades local operation and history integrity.

Minimal correction:

• Journal individual rejected decisions only when they authenticate to a currently or previously enrolled key for that Mac/account.
• Record unauthenticated rejects as rate-limited aggregate counters.
• Reserve journal capacity for consumption and outcome events.

UX impact: None.

Prior disposition (round 17)

Both K3 fixes are correctly reflected in the §12 text:

• the exclusive writer lock with compare-and-set;
• the immutable epoch-creation trust generation, which does not reset history on revocation.

Finding 1 is a gap left by the first fix, in how it interacts with restart. Opus's note about unprovable absence of later events remains adequately covered.

Assessed without further findings

• Scope and authentication: the action/scope biometric table and dual-verifier enforcement; decision-key purpose separation for routing and update scheduling; relay/gateway authority limits and token-possession binding.
• Lifecycle and restarts: multi-phone first-decision consumption; update quiescence, floor commit, and the restart matrix; protocol negotiation and downgrade rules; timing and expiry separation; presence routing and handoff.
• Remaining gates: these are properly defined with failure and consultation paths:
  • key custody and restored trust;
  • single-biometric credential release;
  • descriptor execution and sudoers compatibility;
  • AX fixtures and allow-once validation;
  • local command approval;
  • migration ceremony.

Actual platform feasibility is still unverified.

SUBSTANTIVE FINDINGS REMAIN

Round 17 disposition

Input: revision 23, SHA-256 50be3519488faaf326f0b44a7c951847794bc361eb7810fea79cdc9a2b0c3503.

Opus completed the full plan with no substantive findings. GLM completed the changed scope cleanly; exact-text coverage included all 18 sections. K3 completed with two substantive audit findings. All processes exited zero with nonempty reports.

K3 1: writer ownership after head mismatch

Accepted. Revision 24 explicitly requires an OS-held exclusive writer lock, protected stable identity, and transactional state transitions. Head mismatch stops writes and closes new admission. A fresh epoch is created only after validated exclusive ownership and ledger continuity. Automatic recovery requires proof; uncertain recovery uses the existing repair path. Already-dispatched work is not killed or retried.

K3 2: trust generation in audit batches

Accepted. The batch field is now explicitly the immutable epoch-creation trust generation. Every batch matches its authenticated epoch header. Normal trust updates do not rewrite it. It is descriptive metadata, never a claim about current authority; the channel and authority identity remain separately verified. This avoids divergent Swift/Kotlin interpretations without resetting history on revocation.

Opus non-blocking note

An authenticated prior-head link cannot prove no later events existed. Existing text already prohibits claiming continuous history without evidence. No requirement change is needed; the note is retained as an implementation caution.

Normal UX is unchanged. The pending migration preference and platform gates remain open.

Round 17 review — identity & history scope (revision 23)

Scope checked independently against the current text: sections 1, 2, 3, 12, plus the labelled cross-section context from 5, 16, and 17. The round-16 disposition was read first; nothing in it was assumed true without re-checking the text.

Verification of the round-16 correction

The audit-epoch mechanism is present and coherent in section 12:

• A fresh cryptographically random epoch is generated before the first journal write on every root-service start and after journal replacement or recovery; sequence allocation never resumes in a persisted older epoch. This closes the sequence-reuse path independently of trust changes.
• The live writer verifies its expected head before each append; mismatch closes the epoch with a discontinuity marker.
• Authenticated phone cursors or batch receipts that exceed or conflict with retained history produce a read-only reconciliation: the phone's cached evidence is preserved, the gap is labelled possible rollback or loss, and no trust or history rewrite occurs.
• Restart versus restore is labelled accurately; the gateway is never an enrollment authority; a phone report cannot rewrite Mac history or authorize actions.

Adversarial scenarios traced against this text (restore mid-epoch, restore after a restart, stale cursor on an absent epoch, replayed old signed batches, relay delay/drop, revoked-phone fetch) all terminate in explicitly specified behavior with no authority impact.

Identity-boundary checks (section 16 context)

• Token binding: candidate-token control is root-signed and enrollment-checked; the challenge goes only to the candidate token; the proof returns only via the phone's authenticated Mac channel; candidates are single-use, expiring, and invalidated by revocation; a token string alone cannot redirect wakes; no general send-to-token endpoint exists.
• Counter drift repairs only with retained Mac-signed receipts validated against local trust history; a higher number alone adopts nothing; revocation tombstones survive mapping updates; restored backups cannot revive revoked authority locally or remotely; stale queued pushes grant nothing because the phone checks current Mac authority.
• Offline-Mac and unreachable-gateway cases are handled without manual operator work or forced recovery; recovery remains remotely available.

UX-contract consistency

No reviewed correction adds confirmations, biometrics, physical access, re-enrollment, or manual steps. Little Snitch once/cancel and rule-setting biometric classes, command/1Password biometrics, and the no-biometric token-rotation flow all match the binding UX. The migration interaction remains the only acknowledged pending decision and is correctly gated rather than resolved by inference.

No substantive actionable defect found in the reviewed scope.

NO SUBSTANTIVE FINDINGS

Independent review — Remozio plan, revision 23

Scope: full plan, with attention to post-revision-5 additions (audit journal, expiry/age, routing, push, LAN/relay, identity/Sparkle, protocol evolution) and their interaction with earlier invariants. Plan-only review; no testing or source inspection performed or claimed.

Findings

1. Journal head-mismatch response under-specifies the single-writer failure it detects — Section 12, "Atomic journal writes" (Low–Medium)

Revision 23 adds: "verify its expected head before each append. A head mismatch closes that epoch and starts a fresh one with a discontinuity marker."

Since a fresh random epoch is already generated at every service start, a mid-run head mismatch can only mean a second live writer (dual LaunchDaemon instance, restore onto a running system, or a recovery process writing concurrently). The prescribed response — close the epoch and keep writing — does not converge in that scenario: two live writers would repeatedly invalidate each other's heads, fragmenting the journal. Worse, the mismatch is evidence that the single-writer assumption protecting the consumption ledger is broken; section 12 commits consumption and the audit event in one transaction, so continuing to admit and consume requests after a detected writer-ownership violation risks duplicate dispatch, which the audit fix alone cannot prevent.

Minimal correction (no UX change in normal operation): on head mismatch, stop appending, close action admission (consistent with section 17's "keep action admission closed until recovery validates"), and require validated single-writer recovery before any new epoch or consumption. Specify the single-writer exclusion mechanism (e.g., exclusive journal lock held for the epoch's lifetime) so the mismatch path is only reachable on genuine rollback/corruption.

2. Batch verification rule across in-epoch trust-generation changes is undefined — Section 12, "Sync and offline cache" (Low)

"Signed batches bind the Mac, account, journal epoch, trust generation, sequence range..." and "A journal epoch is bound to the combined trust generation at its creation. Normal trust updates do not reset history."

A revocation or floor commit without a restart changes the combined trust generation mid-epoch (the section 16 witness covers enrollment tombstones and floors, and rev 23 explicitly makes epochs independent of trust-state recovery). Subsequent batches in the same epoch therefore carry a different trust generation than the epoch's creation-time binding. The plan never states what the phone must verify: equality with the epoch's creation generation (breaks legitimate sync after any mid-run revocation), acceptance of any generation (renders the binding meaningless as rollback evidence), or monotonic increase within an epoch under the same authority key. Independent Swift/Kotlin implementations can diverge here, producing either availability failures or weakened conflict detection.

Minimal correction (no UX change): define the rule explicitly — e.g., the epoch records its creation generation for cross-checking, batches carry the current generation, and verifiers require monotonic non-decrease within an epoch plus consistency with known trust state; any decrease or conflict triggers the existing read-only gap/rollback reconciliation.

Items checked and found consistent

• Command binding (full argv/env/cwd/stdin classification, digest recomputation at both verifiers, caller-exit boundary outcomes) — no widening of the allow-once exception; scope classification enforced by both verifiers from retained semantics, with the Little Snitch "current request" definition and second-attempt validation intact.
• Key separation: biometric, decision, transport, gateway-control, routing, update-scheduling, and enrollment purposes are distinct; relay/push/gateway cannot mint decisions or mutate mappings; credential packages remain recipient-bound.
• Rev 23 epoch mechanism vs. section 16 trust witness: random epochs correctly avoid dependence on the witness for audit-only rollback; cursor-ahead, repeated-sequence, and old-epoch cache handling are specified.
• Updates vs. UX: quiescent activation, drain, bounded "Update installing" resubmission, and the restart matrix preserve approval lifetimes and add no confirmations; floor commitment and anti-rollback are externally enforced with a feasibility gate.
• Routing is delivery-only; manual overrides persist; degraded-detection fallback fails toward phone delivery without granting authority.
• 1Password/Little Snitch adapters remain fully in scope with their fixture/race gates; no biometric-free path was extended to commands or 1Password.

Deferred product preferences (not defects)

Idle interval (30s draft), five-minute expiry, retention duration, and the migration ceremony are explicitly gated for user choice; no finding inferred.

Conclusion

SUBSTANTIVE FINDINGS REMAIN — two findings, both in the revision-23 journal-epoch machinery, both correctable without any UX regression (no added confirmations, biometrics, or manual steps). Neither rises above Low–Medium; the rest of the plan, including all prior review dispositions I could challenge, showed no concrete unresolved failure scenario. Remaining verification limits: all platform guarantees (pre-login key custody, descriptor-based execution, AX targeting, background Access auth, rollback-resistant activation) remain feasibility-gate deliverables, as is appropriate for a draft plan; this review asserts nothing about their outcome.

Remozio plan review: revision 23 (full plan)

Input: reviews/round-17-plan.md (revision 23), with reviews/round-16-disposition.md as context. This is a plan-only review. No tools, testing, browsing or source inspection were used. Earlier convergence does not carry over to this revision.

Findings

No substantive planning defects found.

Round-16 fix (§12 "Sync and offline cache")

The revision 23 change resolves the Opus finding as described:

• Epoch creation: a fresh random epoch is created before the first write on every root start, and after journal replacement or recovery.
• No sequence resumption: the writer never continues allocating sequences in a persisted older epoch.
• Head check: the writer verifies the expected head before each append.
• Epoch-scoped cursors: cursors are bound to their epoch, so repeated sequence numbers from a restored journal cannot be confused with, or overwrite, cached records.

The fix does not depend on the trust witness in §16 "Feasibility gate: restored trust state". It adds no user step, biometric or network prerequisite. It also cannot become a source of authority, because:

• Pending payloads stay memory-only (§6 "Crash and uncertain-outcome handling").
• A root restart cancels unconsumed requests.
• Phone reports cannot rewrite history or trust.

A restored ledger therefore cannot revive a signed decision, since the request it binds no longer exists in memory.

Non-blocking clarification (not a finding)

This concerns §12 "Sync and offline cache". "Link a new epoch to the authenticated prior head when available" could be read as a continuity claim.

• Scenario: after an audit-only restore, the "prior head" is the restored, stale head. A phone with no later cached evidence would then see an ordinary restart linked to that head.
• Suggested wording: state that the link attests only "records up to H existed". It does not attest that nothing followed H.
• Limitation to document: without the trust witness, audit-only truncation is detectable only through phone-held cursors or receipts.

This matches the plan's existing rule not to claim a continuous chain without evidence. It needs a wording change only, with no UX impact.

Assessed without findings

• Security boundaries (§3): root-only authority, and XPC peer validation per request that is tied to a committed generation floor (§17).
• Key roles and relay resistance (§§3, 6, 15, 16):
  • Transport, decision, biometric, credential and management keys are separated.
  • Relay, gateway and Access credentials hold no action authority.
• Scope classification (§1, §6 "Both verifiers enforce scope", §9 "Classify the actual one-time effect"):
  • Biometric-free handling applies only to Little Snitch cancel, deny-once and allow-once, where the effect is confined to the current request.
  • Command execution and 1Password always require biometrics.
  • Reusable rules, including timed, session and the default Forever, always require biometrics.
  • Unknown compatibility contracts cannot inherit one-time classification.
• Command binding (§8): covers argv and environment capture, stdin-source disclosure, and the Request too large result. Execution races and sudoers compatibility are properly gated.
• Android flows (§7): the no-keyguard flow and immutable request selection are specified. Single-biometric credential release is properly gated.
• UI races (§9): consumed-permit handling with Unknown outcomes and no retry, and scope mutation performed under one permit.
• Timing, routing and push (§§13–15):
  • Timing separates two clocks and does not treat estimated expiry as authority.
  • Routing controls under the decision key are revision-bound and idempotent.
  • Push token registration uses a possession challenge.
• Updates and protocol evolution (§§17–18):
  • Update drain, the protected activation boundary, and floor commit are consistent with §3 placement rules.
  • Retry after Update installing is limited to authenticated no-admission responses.
  • Contract selection across mixed phones cannot re-encode an existing request into a weaker schema.
• Recovery and UX: remote admin recovery is preserved and no silent UX regressions were found.
• Flux licensing (§4): Flux is used as a design reference only, with no copying of its code.

Pending product decisions (not defects)

• The Mac migration ceremony (§3) remains pending the user's choice.
• The idle interval (§14) and history retention (§12) are deferred preferences.

Remaining implementation verification limits

All the declared feasibility gates still need evidence. These are:

• key custody and non-exportability
• pre-login transport
• restored-trust witness
• protected placement and anti-rollback
• updater staging isolation
• descriptor-based execution
• sudoers compatibility
• AX fixtures for Little Snitch and 1Password
• true one-time effect
• secure-field targeting
• single-biometric release
• Access background authentication
• Cloudflare credential scoping
• presence and brightness signals
• Android delivery under Doze

None of these is proven by this plan.

NO SUBSTANTIVE FINDINGS

Round 16 disposition

Input: revision 22, SHA-256 392c9cd7f171f2024ea08f35688693aa9c389737788852e2298b593b6c7dc88b.

K3 completed its full-plan review with no substantive findings. Both GLM scopes completed with no substantive findings and normal stops. Opus found one medium audit-continuity defect. All processes exited zero with nonempty reports. The previous pending K3 report also completed cleanly and is reconciled in round-15-disposition.md.

Opus 1: audit-only rollback can bypass trust recovery

Accepted. Revision 23 creates a fresh random journal epoch before the first write on every root-service start and after journal replacement or recovery. It never resumes sequence allocation in a persisted older epoch. A running writer also verifies its expected head before appending.

This works independently of enrollment/floor changes, so an audit-only restore cannot reuse sequence numbers within an epoch. Authenticated cursors or receipts that exceed or conflict with retained history produce a visible gap; they cannot modify trust or rewrite history. Old cached records remain available, and the phone syncs the current epoch without waiting for obsolete sequence numbers.

Normal restarts are labelled accurately and do not imply rollback. Missing evidence is reported as possible loss, not invented continuity. No user step, biometric, or network prerequisite is added.

Pending UX decision

The Mac migration interaction remains unresolved and explicitly gated for user choice before implementation. This does not affect ordinary updates or the normal approval flow. No user answer or approval is inferred.

Round 16 review — gateway/management boundary (revision 22)

Scope reviewed: §1 (Product contract), §2 (Scope and threat model), plus the labelled cross-section context: §16 (gateway ownership and recipient authority, token binding, lifecycle sync/cleanup, cloud management authority, restored-trust-state feasibility gate, transport acceptance cases), §5 (enrollment excerpt), §17 (generation/release excerpts). Text-only review; no runtime verification claimed. Checked independently against the round-15 disposition.

Checks performed on the highest-risk logic:

• Biometric table vs binding UX: allow-once/deny-once/cancel without biometrics; every rule-setting decision (Forever default, create/change/remove) with biometrics; single biometric for command/1Password/credential release. Consistent; no correction needed, so none can worsen UX.
• Stale-revision reconciliation: requires the retained Mac-signed receipt, validates it against local trust history, applies verified revocations before any phone operation, and auto-reconciles only delivery-only drift. Found no path where a higher gateway number alone, a replayed mutation, a reused revision after counter rollback, or a restored backup resurrects revoked authority or lowers floors/policy; unknown trust changes suspend to the existing admin recovery.
• Token binding: root-signed candidate control → gateway-only challenge to the candidate token → phone proof over its authenticated Mac channel → root recheck before final mapping. Candidates cannot displace the active mapping, revocation kills candidates per epoch, no general send-to-token endpoint. Internally sound, including the revocation-between-candidate-and-activation race listed for test.
• Credential separation: the seven-credential table keeps provisioning, control signing, tunnel run, push submission, phone Access, and provider secrets in distinct scoped roles; transport/phone credentials cannot mutate mappings or invoke management; the controller pins resources and rejects caller-supplied ingress targets. No overlap found.
• Restored-trust-state gate: explicitly fails rather than overclaims (no assumed Secure Enclave monotonic counter; device-bound key alone insufficient); preserves offline/LAN operation without a gateway startup check; consultation required before any online check, recurring authorization, physical access, or forced re-pairing — no UX regression introduced by the gate as written.
• Uninstall/rollback: tombstones reject delayed pre-uninstall controls; reactivation requires a new lifecycle epoch; queued provider pushes grant nothing when current Mac authority cannot be confirmed.

The migration-recovery interaction question from round 15 remains recorded in the disposition as an unresolved user-choice gate with its failure/consultation path present in the text; that is a pending decision properly tracked, not a defect in this scope.

NO SUBSTANTIVE FINDINGS

Round 16 review — identity/history scope (revision 22)

Scope checked independently: sections 1, 2, 3, 12, plus the provided section 5, 16, and 17 context.

Disposition accuracy. Both round-15 corrections are present and correctly bounded in the current text: device-bound, non-exportable custody with the backup-clone/recipient-certification tests applies to authority and recipient-certification keys only, with the transport-only-key fallback explicitly excluded from those roles and a blocker-plus-consultation path if custody and pre-login availability conflict. Journal epochs are bound to trust generation, restoration creates a fresh epoch, old cursors cannot select new-epoch records, and cached old-epoch history is preserved with a labelled discontinuity. The migration ceremony remains an unresolved user-choice gate without adopting extra biometrics or re-pairing — consistent with the disposition's "no clean convergence claimed" stance.

Checks that found no defect:

• Biometric contract: allow-once/deny-once/cancel/dismiss require none; every reusable rule (session, timed, Forever) requires biometrics; Forever default preserved; no forced physical presence or re-enrollment in routine flows.
• Gateway counter reconciliation: a higher gateway number alone is insufficient; trust-changing claims require the retained Mac-signed receipt validated against local trust history; verified revocations are applied locally before phone operations; unknown trust changes suspend authority pending administrator recovery. Restored-backup and stale-tombstone paths are each closed (receipt validation; lifecycle-epoch rejection of delayed controls; wake-only exposure on gateway compromise is neutralized by phone-side authority checks).
• Candidate-token flow: root rechecks enrollment before the final revision; candidates are single-use, expirable, and cannot redirect wakes on failure; probes are bounded and are background traffic, not approval prompts.
• Key custody: transport key is separated from approval authority; relay compromise remains delay/drop/metadata only; credential packages are recipient-encrypted; the "administrator-controlled" wording for the transport fallback is governed by the earlier strict definition (no interactive-admin-writable paths).
• Audit: consumption and initial event commit atomically; audit state derives from the single consumption ledger (no second execution authority); closed metadata enums with no bound target values; unknown outcomes never imply success; retention cannot delete active requests or weaken replay protection; revoked phones cannot fetch new history with the offline-cache limitation stated.
• Process boundaries: per-request live code identity plus persisted minimum build/generation; caller UID captured at the service boundary; same-user frontend invocation is not treated as consent.

No correction is proposed, so none can worsen UX. No runtime verification is claimed; platform gates remain planned feasibility work.

NO SUBSTANTIVE FINDINGS

Independent review — Remozio plan, revision 22

Scope: full plan, including post-revision-5 additions (audit, expiry/timing, presence routing, push, LAN/relay, gateway control plane, key custody, Sparkle updates, protocol evolution, mixed versions). Plan-only review; no testing, browsing, or source inspection claimed. Prior disposition (round 15) reviewed; its two accepted fixes (authority-key custody, epoch-bound audit cursors) are correctly integrated into revision 22 and I find no concrete unresolved scenario that reopens them.

Assessment of the high-risk boundaries

Authority/key custody (§3, §16). The custody requirements are internally consistent: no ordinary-file fallback for authority or recipient-certification keys; the transport-key fallback is explicitly scoped to the transport role only; pre-login availability vs. Secure Enclave custody is an explicit blocker-and-consult gate rather than an assumed guarantee. Migration requires a new key with authenticated continuity, and the one-time-interaction cost is correctly recorded as an unresolved user-choice gate, not silently adopted.

Decision-key separation and scope classification (§1, §6, §9). The biometric/decision key split is coherent end to end: both verifiers derive the required key class from retained action semantics, never from caller or phone assertion; the once-exception is confined to the captured Little Snitch request; reusable/timed/session rules are classified as rule-setting regardless of label; the "second connection attempt must not inherit" test closes the most obvious widening. Routing and update-scheduling purposes under the decision key are explicitly denied action, enrollment, and release authority. No path widens biometric-free approval to commands or 1Password.

Replay/downgrade resistance (§6, §12, §16, §17, §18). Consumption-before-dispatch, single-use permits, epoch-bound audit cursors, gateway lifecycle epochs with monotonic revisions plus signed-receipt reconciliation (counter increase alone insufficient), rollback detection via the combined trust-generation witness, and floor enforcement independent of the candidate binary form a consistent stack. The witness gate explicitly fails closed with a consultation path rather than assuming a platform monotonic counter — correctly a feasibility gate, not a defect. The "authenticated no-admission result vs. unknown admission result" distinction in §17 correctly prevents resubmission of possibly-admitted commands while permitting resubmission of provably non-admitted ones.

Race handling (§6, §9). Permit invalidation on adapter death, quiesce-before-recapture, unknown-is-terminal, and scope-mutation-as-one-attempt are consistent across §6 and §9; the UX invariants (no silent Once↔Forever fallback, no silent truncation, refresh-not-replay) are preserved.

Remote UX preservation (§1, §5, §13–15). No added confirmations, biometrics, or shortened windows were introduced. The 1Password estimate vs. routing-idle-delay tension is disclosed, not hidden. Push remains baseline; LAN-first with bounded direct-connect attempt protects the short 1Password window. The deferred items (idle interval, retention duration, migration ceremony, biometric-invalidation policy, decision-key unlocked-device constraint) are explicitly recorded as pending user decisions — I flag them as tentative UX choices, per instructions, not defects.

Flux reuse (§4). Design-only reuse pending license resolution is correctly stated.

Minor observations (not substantive findings)

• §16 references "fresh boot challenges" invalidating ephemeral operations without a defined mechanism; this is implementation detail within the already-gated witness work.
• Phone-initiated persistent "At my Mac" override is a delivery-only DoS surface for anyone with unlocked-phone access; the plan states the no-biometric/no-expiry choice deliberately and it grants no action authority, so it stands as a documented tradeoff under the trusted-phone assumption.

Remaining implementation verification limits

A no-findings plan review does not establish: Secure Enclave pre-login availability and code-identity restriction; the trust-generation witness mechanism (no general monotonic counter is assumed); true one-time semantics of Little Snitch controls per version; single-BiometricPrompt credential release; Sparkle's respect for the quiescence boundary during on-disk bundle replacement; sudoers policy equivalence; background Access authentication. All are scheduled as explicit feasibility gates with failure/consultation paths. The K3 full-plan review noted as pending in the disposition remains unreconciled and is outside this pass.

Conclusion

NO SUBSTANTIVE FINDINGS.

Remozio plan review: revision 22 (full plan)

This review covers the plan text only. No testing, browsing, or source inspection was done.

Finding 1: Medium. A restored audit journal can reuse sequence numbers inside an unchanged epoch

Where:

• §12 "Sync and offline cache"
• §12 "Atomic journal writes"
• §16 "Feasibility gate: restored trust state"

Scenario:

1. A Mac is restored from a Time Machine backup taken after its last trust change. No enrollment, revocation, floor, or policy change happened between the backup and the restore.
2. The §16 witness commits only to authority-relevant state, so it matches. Continuity is established, and no "restoration recovery" runs.
3. §12 creates a fresh journal epoch only through that recovery path. The restored journal therefore keeps the same epoch and rewinds its sequence counter.
4. The Mac writes new events under sequence numbers that phones have already cached with different event IDs.

What goes wrong:

• Phones either detect "changed records" and stall, or deduplicate inconsistently.
• The phone's cursor is ahead of the Mac's head.
• Signed batches with the same epoch and sequence range conflict.

The plan already lists these tests ("cursor ahead of a restored journal", "repeated sequence numbers"). It defines no detection mechanism for this case, because the only epoch trigger depends on a trust discontinuity.

Minimal correction:

• Make journal continuity its own trigger for a new epoch, independent of trust-state recovery.
• Require that no sequence number is ever reissued within an epoch.
• Start a new epoch, with reason "journal rollback detected", when either of these occurs:
  • an authenticated phone cursor or batch receipt exceeds or conflicts with the local head, or
  • the journal head is not covered by a protected commitment. This could reuse the §16 witness at coarse intervals, or record a per-boot epoch.
• Phones keep their conflicting old records under the existing "History discontinuity" label.

This grants no authority and adds no user step. It also does not affect replay safety: pending payloads stay memory-only, and the control replay state is already under the witness.

UX impact: None.

Tentative UX choice, not a design defect

The migration ceremony for new hardware is in §3 "Key custody and pre-login transport" (see also the round-15 disposition).

• The plan correctly treats it as a user-choice gate with a design, disclosure, and consent path before implementation.
• A user question is outstanding and unanswered.
• Per §11, REVIEW-LOG.md should list it as a pending decision.
• Any option involving phone biometrics or a one-time ceremony during migration is a UX cost that needs explicit user approval.

The idle threshold and retention duration remain explicitly deferred preferences. They are not findings.

Assessed without further findings

Revision 22 key custody:

• Device-bound, non-exportable authority and certifier keys.
• No file fallback for those keys.
• A clone test is included.

Epoch-bound cursors after a restoration triggered by a trust discontinuity.

Consistency of earlier invariants:

• Scope and biometric table.
• Decision-key purpose separation for routing and scheduling.
• Relay and gateway non-authority.
• Revocation serialization and tombstones.
• Candidate-token proof.
• Update quiescence and floor commit.
• Mixed-version contract selection without re-encoding.
• Restart matrix.

Remote UX preservation: No new confirmations, and approval windows are not shortened.

Scheduled feasibility gates, not treated as defects:

• Secure Enclave pre-login availability.
• Rollback witness.
• Single-biometric credential release.
• sudoers compatibility.
• Atomic execution.
• AX fixtures.
• Local command approval surface.

Implementation verification limits: These are platform facts the plan depends on and must still be proven.

• Non-exportability survives a real backup or migration.
• A monotonic witness exists that is compatible with offline operation.
• Old signed builds can be isolated from current receiving keys.
• Protected placement holds under Sparkle and SMAppService.
• Little Snitch and 1Password expose true once-only semantics.

SUBSTANTIVE FINDINGS REMAIN

Round 15 disposition

Input: revision 21, SHA-256 05176ed1fa72da09cae9c4683bd8fedf1cf15c85b175686260282b4d9e5fb63e.

Opus completed with two substantive findings. GLM completed the gateway/recovery scope with no substantive findings and a normal stop. K3's full-plan process is still running when the next snapshot is frozen; its final report will be reconciled separately. No clean verdict is claimed for a pending process.

Opus 1: authority-key custody and cloning

Accepted. Revision 22 requires device-bound, non-exportable custody for Mac authority and recipient-certification keys, with an explicit backup-clone impersonation test. It does not assume a this-device-only label proves non-exportability. Incompatible pre-login availability is a feasibility blocker, never an ordinary-file fallback.

Migration needs a new key with authenticated continuity or independent recovery. The exact interaction is an explicit user-choice gate. A question was sent about one-time migration recovery; no answer has been received and no extra biometric or ceremony has been adopted. The gate must be resolved with the user before implementation. Routine app updates preserve identity and pairing.

Opus 2: restored audit cursors

Accepted. Revision 22 binds records, cursors and signed sync batches to journal epochs. Restoration recovery creates a fresh epoch tied to the combined trust generation. Old cached history is preserved, the discontinuity is labelled, and new-epoch sync cannot overwrite old sequence numbers or stall on an obsolete cursor. Key changes must pass authenticated recovery before new batches are trusted.

A gateway registration diagram illustrates the already-specified candidate/proof/activation sequence. All changes remain plan-only; platform gates are not claimed as verified.

Pending process resolved

K3 subsequently completed with exit 0 and a nonempty full-plan report. It reported no substantive findings. No additional correction was required.

Round 15 review — revision 21, sections 1–2 plus the changed management boundary

Prior disposition verification

Round 14 Opus 1 accepted: revision 21 extends restore protection to security floors and policy via one combined trust generation. Verified in the current text: the gate commits to enrollment keys/tombstones, committed floors, authenticated policy revisions, installed-generation records, lifecycle epochs, and replay state (gateway, routing, scheduling, enrollment, authorization). Continuity is checked at the installation boundary before loading affected code and at the root before accepting phone operations. Atomic witness commit, interrupted-write recovery, and the no-blessing rule for administrator recovery are present, as are the pre-floor-restore acceptance cases. The disposition's claims match the text.

Independent checks of the changed boundary

• Gateway authority posture: the gateway is never an enrollment authority; its evidence is restrict-only (verified revocations apply locally, unknown trust changes suspend to administrator recovery, higher counters alone prove nothing, Mac-signed receipts with exact trust changes required). Consistent internally and with section 2's "network messages alone cannot" rule, since adopted revocations originate from the Mac root's own signature retained as receipts.
• Token-possession flow: candidate creation cannot change the active mapping; the proof is bound to a root-signed fresh nonce, phone identity, enrollment epoch, and token digest; activation consumes the unexpired candidate once; revocation invalidates pending candidates and blocks late proofs. No biometric or notification is added; failures preserve the prior mapping and surface as registration health. Consistent with binding UX.
• Counter reconciliation: fresh-envelope retry, max(local, acknowledged)+1 advance, no replay of obsolete mappings with new counters, receipt validation against local trust history before reconciliation. Sound against both drift and rollback.
• Credential table vs. narrative: all seven holders/roles match the surrounding constraints; management and provisioning credentials are root-only controller-scoped; transport and phone credentials carry no mutation authority; provider secret never leaves the gateway.
• Uninstall/reactivation: control-path removal, tombstone, new lifecycle epoch for reactivation, and fail-closed handling of surviving queued pushes (phone checks current Mac authority) are coherent.
• Cross-checks against frozen text: sections 1–2, the section 5 enrollment excerpt, and the section 17 generation checks are consistent with the new boundary; no new confirmation, biometric, manual step, physical-access, or re-pairing requirement was introduced anywhere in the changed text.

One residual observation, considered and not flagged as substantive: gateway-side backup restoration could in principle defeat a tombstone together with revision monotonicity. The plan's architecture already contains the consequence — pushes are opaque untrusted wakes, actionable content requires the authenticated channel, and revoked/unverifiable requests grant nothing — so the impact is bounded to delivery anomaly under operator action on user-operated infrastructure, not an authority defect requiring text changes in this scope.

NO SUBSTANTIVE FINDINGS

Independent plan review — Remozio revision 21

Scope assessed

I reviewed the complete plan with emphasis on the post-revision-5 additions and their interaction with earlier invariants:

• Rev 21 change (trust-generation witness, §16) against the round-14 disposition. The combined generation covers enrollment keys/tombstones, security floors, authenticated policy revisions, installed generations, lifecycle epochs, and control replay state; continuity is validated at the installation boundary before loading code and at the root before accepting phone operations. I checked the consumption-ledger rollback scenario specifically: pending sensitive payloads are memory-only and a restore implies a root restart that cancels unconsumed requests (§6, §17 restart matrix); consumed requests are expired and decisions are single-use challenge-bound, so a pre-consumption restore cannot re-enable re-execution; journal rollback surfaces as detectable sequence gaps in §12 sync. The disposition's reasoning holds; I found no concrete unresolved scenario.
• Consumption/race safety (§6): first-valid-decision ledger, permit-before-mutation for scope changes (§9), crash-after-dispatch → unknown with no retry, permit acknowledgment watchdog, and revocation/consumption serialization. Consistent with the multi-phone race table and the §12 atomic journal transaction.
• Scope classification and key separation (§1, §6, §7, §9): the narrow decision key's purposes (one-time UI decisions, cancellation, routing control §14, update scheduling §17) grant no target-action, enrollment, or release authority; both verifiers derive biometric requirement from retained semantics; the Little Snitch allow-once exception is not widened to commands/1Password; unknown compatibility contracts cannot inherit one-time classification (§9). Routing and scheduling controls were checked for authority escalation: worst case is availability impact, cancelable, and consistent with the confirmed unlocked-phone-operator tradeoff.
• Update/anti-rollback paths (§3, §16, §17, §18): per-request generation floors on privileged XPC, floor commit only at quiescence, transparent resubmission restricted to the authenticated no-admission race response (unknown admission → reconcile, never auto-resubmit), deferred bundle replacement for live roles, downgrade rejection independent of candidate binaries, gateway epoch/revision/tombstone reconciliation requiring Mac-signed receipts before counter repair.
• UX invariants: full command rendering, no truncation (oversized → distinct result), streaming stdin preserved, no added confirmations/biometrics/manual steps anywhere in the new sections; the "Update waiting" drain is user-initiated, visible, and cancelable; native dialogs and manual sudo remain as fallback surfaces.

Tentative UX choices (explicitly deferred, not defects)

The 30-second draft idle interval, audit retention duration, FCM provider selection, biometric-invalidation policy, and the ~60s 1Password lifetime estimate remain pending product preferences or gated evidence items. They are framed with consultation paths and do not block convergence.

Items verified as feasibility gates rather than defects

Single-biometric credential release (§7), descriptor-based/atomic execution (§8), sudoers compatibility (§8), secure-field targeting (§9), 1Password/Little Snitch fixtures (§9), Access background auth (§16), the trust-generation witness mechanism with explicit failure/consultation path (§16), and protected-placement/anti-rollback enforcement (§3, §17) each have required evidence and a defined consult-the-user failure path. Per the review protocol, these are planned work, not findings.

Remaining implementation verification limits

This review establishes plan-internal consistency only. It does not establish: that macOS 14+ exposes the required connection-bound code-requirement and service-management APIs; that a non-migrating installation key plus witness can actually distinguish same-Mac rollback while preserving offline operation; that one CryptoObject operation can cover credential release; that 1Password/Little Snitch AX structures match the compatibility contracts; or that push/background delivery meets practical latency. All of these remain contingent on the scheduled feasibility evidence, and several may trigger mandatory user consultation if they fail.

Conclusion

NO SUBSTANTIVE FINDINGS. The revision-21 extension of the restoration gate to floors, policy, generations, epochs, and replay state is internally consistent with the consumption ledger, activation boundary, and offline-operation requirements, and the post-revision-5 subsystems (audit, expiry, routing, push, relay/gateway, identity, updates, protocol evolution) introduce no contradictions, downgrade/replay gaps, or silent UX regressions against the earlier invariants. Convergence here means no unresolved planning findings on this revision; it does not assert platform feasibility, which remains gated as designed.

Remozio plan review: revision 21

Scope. I reviewed the complete revision 21 against the round 14 disposition. I paid most attention to the new restored-trust gate in §16 and how it interacts with §§3, 5, 12, 17 and 18. No earlier convergence is assumed for this revision.

The Opus 1 correction works as intended. §16 Feasibility gate: restored trust state now covers:

• floors, policy revisions and installed generations;
• lifecycle epochs and control replay state;
• atomic witness commits;
• recovery that cannot simply accept an old signed snapshot.

It also keeps offline and LAN operation and adds no recurring prompt. Two gaps remain around the same backup and migration scenario.

Finding 1 (Medium): Mac authority key custody is unspecified, so a backup or migration clone can mint trusted requests and credential recipients

References: §3 Root authority and retained state, §3 Key custody and pre-login transport, §7 Credential enrollment and release, §16 Feasibility gate: restored trust state.

What the plan says. §3 requires adapter receiving keys to be non-exportable. It also says the file fallback "does not apply to credential-receiving or authority keys." It never states the required custody of the Mac authority private key, or whether that key may appear in backups or migrations. The §16 gate adds a non-migrating installation key, but only as a rollback witness.

Failure scenario. Suppose the authority key sits in ordinary root-only storage. It would then be included in Time Machine or Migration Assistant copies.

1. An attacker restores that copy on a Mac they control. They are root there, so the §16 continuity checks never run.
2. They now hold the key that phones pin as the Mac authority.
3. They can issue authority-signed 1Password unlock requests and certify their own adapter receiving key.
4. The enrolled phone verifies both correctly. After the user completes one biometric, the phone releases the credential package to the attacker's key.

This is not a root compromise of the protected Mac. §16 explicitly treats backup and migration as in scope, yet it only prevents the clone from acting locally. It does not prevent the clone from impersonating the authority to phones.

Minimal correction.

• Require the authority key, and any key that certifies credential recipients, to be non-exportable and device-bound: Secure Enclave or a this-device-only keychain item.
• Otherwise, record an explicit custody blocker in the key-custody deliverable.
• On migration, rotate the authority key through the existing independent administrator recovery, which the plan already requires when continuity fails.

UX note (needs user consultation). This adds no step to normal approvals. It does mean every Mac migration requires authority re-establishment with the phone, which could involve a phone biometric. That cost should be disclosed to the user rather than silently adopted.

Finding 2 (Low): Audit sequence and cursor behavior after a restore is undefined

References: §12 Sync and offline cache, §12 Retention and replay safety, §16 Feasibility gate: restored trust state.

What the plan says. Phones resume sync from an authenticated per-Mac sequence cursor and flag "missing or changed records." The trust-generation commitment deliberately excludes audit history.

Failure scenario. After a legitimate restore and administrator recovery, the Mac reissues sequence numbers the phone has already cached, now with different content. Each phone then does one of two things:

• permanently reports tampering for a legitimate restore; or
• stalls, because its cursor is ahead of the Mac's journal.

A malicious restore, by contrast, would look identical to this benign case.

Minimal correction.

• Give the journal an epoch bound to the trust generation.
• Have recovery start a new epoch.
• Have phones show an explicit "history discontinuity after Mac restore" marker, keeping cached records rather than overwriting them.

UX impact: none.

Items reviewed without new findings

These areas are either consistent or already covered by defined feasibility gates with consultation paths:

• scope and key separation for decision-key, routing and scheduling purposes;
• relay and gateway non-authority;
• token-possession binding;
• update drain and quiescence;
• floor commit and the activation boundary;
• the mixed-version contract selection rule;
• the Update installing resubmission rule;
• restart recapture.

The idle threshold and retention duration remain deferred preferences, as stated.

Implementation verification limits:

• Platform proof of the witness, protected placement and generation-scoped key access remains open.
• Push delivery under Doze remains open.
• The one-biometric CryptoObject spike remains open.
• AX fixture behavior for 1Password and Little Snitch remains open.

SUBSTANTIVE FINDINGS REMAIN

Round 14 disposition

Input: revision 20, SHA-256 717b44b51dca29117241d33c99ef6b309dc669ebbc36fbe0ee7b4adb68ae7866.

K3 completed its full-plan review with no substantive findings. Opus completed with one medium finding. GLM emitted a no-findings report, but Pi exited 1 after a stale-context error in its usage-meter extension. That attempt is retained but not counted as successful. No extension or provider configuration was changed.

Opus 1: restore protection must cover security floors and policy

Accepted. Revision 21 extends the same feasibility gate to one combined trust generation and an authority-state commitment. It includes enrollment, tombstones, security floors, authenticated policy revisions, installed generations, lifecycle epochs, and replay state. The installation boundary validates continuity before loading affected code; the root validates it before accepting phone operations.

The gate now covers atomic witness commits and crash recovery. Administrator recovery must reconstruct current authority from authenticated evidence; it cannot bless an old signed snapshot. Acceptance cases restore a pre-floor backup and attempt older signed components and stale controls.

This correction preserves normal offline operation and adds no recurring check, biometric, or prompt. The existing consultation requirement applies if platform mechanisms cannot meet the UX contract. No feasibility result is claimed.

This attempt did not complete successfully. Its retained text is evidence only; it is not counted as a clean review.

Round 14 review — gateway/management boundary (revision 20, sections 1–2 with labelled context)

Verification performed

Sections 1–2 (product contract, threat model): Biometric table matches the binding UX (one biometric for command/1Password/rule-setting decisions; allow-once/deny-once/cancel without; session and timed rules treated as reusable). Threat boundary, signature semantics, and documented limitations (UI automation, Accessibility/automation bypass, no transitive-command guarantee) are internally consistent with sections 5 and 17 context.

Section 16 — gateway ownership and control plane: The provisioning credential is owner-scoped with no provider or Cloudflare rights; bootstrap requires operator-controlled owner authorization, so phones, transport credentials, and self-asserted Mac keys cannot bootstrap trust. Candidate-token binding closes token-string redirection: root-signed candidate with nonce and expiry, gateway-only challenge, phone proof over its authenticated channel (nonce is root-signed in step 1, so the root can verify the step-3 response), single-use activation, prior mapping preserved on failure, revocation invalidating pending candidates. Counter reconciliation validates retained Mac-signed receipts against local trust history before advancing, restricts gateway evidence to revocation (never enrollment), and tombstones prevent re-adding a revoked phone via ordinary mapping updates. Lifecycle operations (enrollment, token refresh, revocation, repair, uninstall) require no post-setup operator work; bootstrap-time operator authorization is setup, not a recurring step.

Cloud management authority: Credential table matches the prose; controller has no listener, outbound-only typed operations, caller and administrator authentication per operation, and the recurring-authorization case is retained as a feasibility blocker with consultation rather than inserted into the approval path.

Feasibility gate (restored trust state) vs. round-13 disposition: All accepted requirements are present — non-migrating installation key plus independently protected witness, explicit statement that a key alone cannot detect same-Mac rollback, no Secure Enclave monotonic-counter assumption, defined crash/backup/migration/reinstall behavior, startup continuity validation, offline/LAN operation without a gateway check, gateway unreachability not itself triggering recovery, restrictive application of verified revocations, suspension on unknown signed trust changes, higher gateway numbers alone insufficient, delivery-only drift auto-reconciling, explicit failure with consultation before any UX change, and the required rollback/migration tests including gateway-unreachable LAN and relay paths. No binding UX constraint is weakened: no extra biometric, online check, physical access, or forced re-pairing is approved, and the Mac remains usable via manual approval in suspended-authority cases.

Transport acceptance cases: Cover the new mechanisms (token-possession challenges, stale revisions, tombstones, counter restoration, candidate races) without introducing mandatory interactive steps on the approval path.

No internal contradictions, authority confusions, replay windows, or UX regressions found in the scoped text.

NO SUBSTANTIVE FINDINGS

Independent review — Remozio plan, revision 20 (round 14)

Input reviewed: reviews/round-14-plan.md (revision 20, dated 2026-09-30) plus reviews/round-13-disposition.md. Plan-only review; no testing, browsing, or source inspection performed or claimed.

What was assessed

Full plan, with priority on the post-revision-19 additions (the section 16 "Feasibility gate: restored trust state" and the restrictive rollback-evidence rules) and their cross-section interactions: revocation serialization (5/6), gateway control plane and tombstones (16), update/floor commit and rollback (17), negotiation and downgrade resistance (18), audit exclusions (12), routing/push coupling (14/15), command binding (8), biometric credential release (3/7), UI permit/scope-mutation atomicity (6/9).

Assessment of the revision-20 additions

The restored-trust gate is a defined feasibility gate with required evidence (witness update/crash/backup/migration/reinstall semantics, offline continuity, rollback tests over LAN and relay with the gateway offline) and an explicit failure/consultation path. Per the review rules, that is planned work, not a defect. It is also internally consistent:

• Restrictive-only direction. Gateway evidence can suspend authority and mapping publication but cannot enroll or restore authority; a higher counter alone is inert without a Mac-signed receipt. Rollback of trust-changing state funnels to the existing independent administrator recovery, which does not require the old phone. Fail-safe.
• No new denial-of-approval surface. Revocation receipts are Mac-signed and originate locally ("Local revocation takes effect immediately"), so a replaying or hostile gateway cannot fabricate a revocation "missing locally" against a current trust history; replayed receipts the Mac already has are no-ops. Epoch binding on mappings and the surviving tombstone rule prevent an old-epoch revocation from being mistaken for current authority.
• Offline/LAN UX preserved. Continuity validation is local-at-startup; an unreachable gateway must not force recovery, and delivery-only counter drift reconciles automatically — safe because push tokens and mappings carry no action authority (sections 15/16).
• Consistency with update rules. Section 17's pre-commit rollback preserving live trust state, and the prohibition on backup restoration lowering floors/ledger/trust, align with the witness requirement; section 18's persisted authenticated policy revisions match the same anti-rollback posture.

No contradiction found between these additions and earlier invariants (consumption-before-dispatch, first-valid-decision ledger, key-purpose separation, biometric table in section 1, no lock-screen surface, pairing preservation preference).

Boundaries checked without findings

• Scope classification / key separation: decision-key purposes (one-time UI, routing, update scheduling) remain disjoint from biometric-key purposes (commands, 1Password, credentials, enrollment, reusable rules incl. temporary/session); both verifiers enforce scope from retained semantics, not caller/phone labels (6, 9, 14, 17).
• Replay/downgrade: stale-revision heads require signed receipts; expired envelopes are re-issued from current state, never replayed; negotiation is transcript-bound with no retry to older formats after signature failure; floors persist independently of binaries (16, 17, 18).
• Privileged update paths: activation transaction, quiescence/drain, generation-bound key access, and the external-installation-boundary requirement are coherent; the acknowledged open items (placement enforcement, old-build key isolation, remote continuity) are explicit gates.
• Command binding: canonical capture, stdin-source disclosure, digest recomputation on the phone, requester-exited boundary semantics, and the sudoers-compatibility gate are consistent end to end.
• UX invariants: no added confirmations/biometrics, no shortened windows, no mandatory lock-screen or recurring online checks; allow-once remains confined to Little Snitch one-time effect with second-attempt validation.

Tentative UX choices (flagged, not defects)

These are explicitly deferred or gate-pending product decisions, not planning defects: the automatic idle interval (14), audit retention duration (12), biometric-enrollment invalidation policy (5/7), StrongBox-vs-TEE and any recovery-UX change (4), the ~60 s 1Password estimate (13), and any future forced-floor policy (17). Each already has a consultation path.

Remaining implementation verification limits

This review cannot verify, and the plan correctly does not claim: macOS 14+ API behavior for XPC peer requirements, service management, and brightness/activity signals; Secure Enclave/Keychain generation isolation and the trust-generation witness mechanism; descriptor-based execution semantics; 1Password/Little Snitch AX contracts and one-time effect validation; single-biometric credential release; background Access authentication; push behavior on real devices; and measured latency. All are scheduled feasibility/acceptance work with failure paths.

Conclusion

NO SUBSTANTIVE FINDINGS

Revision 20's additions resolve the round-13 restored-state finding in a restrictive, offline-preserving, consultation-gated way, and no contradictions, downgrade/replay gaps, privileged-update escapes, or silent UX regressions were identified across the complete plan. Convergence here means planning-level coherence only; every platform assurance above remains to be proven by the scheduled gates before implementation claims are made.

Remozio plan review: revision 20

This is a plan-only review. I did not run tools, test anything, or inspect source. I reviewed the complete revision 20 text, focusing on the new §16 restored-trust gate and how it interacts with §17 and §18. I agree with the round 13 disposition of Opus 1, with the limitation described below.

Finding 1: Medium. Rollback detection covers enrollment only, but floor and policy rollback relies on it too

References:

• §16, "Feasibility gate: restored trust state"
• §17, "Activate and commit security floors" and "Failure and recovery"
• §18, "Compatible additions and breaking changes"

Defect: Revision 20 correctly notes that ordinary files, signed snapshots and root-only permissions do not detect backup rollback. However, the proposed witness is bound only to "the Mac/account and enrollment generation."

Other sections make the same no-rollback promise for state the witness does not cover:

• §17 says "restoring a backup cannot lower these protections" for committed security floors and policy generations.
• §17 also says the trusted installation boundary checks candidates "against committed floors and installed generations."
• §18 says "Persist authenticated policy revisions and minimum security generations … Reject replayed older policy."

These are all persisted local state, so they have exactly the detection problem the new gate describes. Nothing in the plan says how they are protected.

Failure scenario:

1. A release raises the security floor to exclude an adapter build with a known flaw, such as one that lets a same-user process drive it.
2. The administrator later restores a pre-update backup of the protected store, for example during migration or disaster recovery. This is the same non-malicious restore the gate already models.
3. Enrollment continuity may still pass. Either no enrollment changed, or the witness was checked and accepted.
4. The committed floor has now silently reverted. The old signed adapter again passes the per-request generation check, and the installation boundary accepts the older generation.
5. A malicious unprivileged caller, which is in scope, can then use the reinstated vulnerable component.
6. The routing revision and the gateway lifecycle epoch/revision counters can also regress the same way. §16 depends on those counters for its "stale epoch/revision" reasoning.

Minimal correction: Extend the same gate's witness to one combined trust generation covering:

• enrollment records,
• committed security floors and authenticated policy revisions,
• the installed-generation record used by the activation boundary.

Apply the same failure behavior already defined: withhold affected authority and use the existing independent administrator recovery. Add acceptance tests that restore a pre-floor backup and then try to launch an old signed adapter or root authority.

This adds no confirmation, biometric, online check or manual step to normal operation, so it does not worsen UX. The only UX impact is the gate's existing post-restore recovery path, which already requires consultation if it proves too costly.

Assessed without further findings

• Gateway evidence: it can only restrict authority, a higher counter alone is insufficient, and revocation tombstones and new-epoch re-enrollment are handled.
• Offline operation: normal offline and LAN use is preserved without a gateway startup check.
• Scope classification: decision-key and biometric-key separation and the Little Snitch once/reusable rules are unchanged and consistent.
• Relay: it cannot mint decisions.
• Updates: drain and quiescence rules, the restart matrix, and admission-race resubmission are consistent.
• Mixed versions: request-contract selection has no downgrade path.
• Tentative UX choices: none are silently selected. The idle interval and retention duration remain declared as deferred preferences.

Limits of this review

Platform feasibility is unproven. That includes witness mechanisms, pre-login key custody, single-biometric credential release, AX atomicity, descriptor execution, and protected update placement. These gates are correctly scheduled, but they remain implementation evidence rather than verified claims.

SUBSTANTIVE FINDINGS REMAIN

Round 13 disposition

Input: frozen revision 19, SHA-256 2c2e0fe54a42cc8414ad614251f14a6d5d8ec83a000bf59d783a3cede8617cbe.

K3 completed the full plan with no substantive findings. GLM completed both overlapping gateway and transport scopes, each with no substantive findings and a normal stop. Opus found one medium issue. All processes exited zero with nonempty final reports.

Opus 1: restored enrollment state

Accepted. Revision 19 required safe restoration but did not define how it could be detected. Revision 20 adds a specific feasibility gate for a non-migrating installation key plus an independently protected trust-generation witness. The text explicitly states that a key alone cannot detect same-Mac rollback and does not assume Secure Enclave offers a monotonic counter.

Verified Mac-signed revocation evidence applies restrictively to local authority. Unknown signed trust changes suspend affected authority and mapping publication until the existing independent administrator recovery resolves them. A higher gateway number alone cannot revoke or enroll anything. Known delivery-only counter drift remains automatically recoverable.

The gate must establish offline continuity and define crash, migration, backup, and reinstall behavior before shipping. Gateway unavailability alone cannot block normal offline operation. If available mechanisms cannot preserve that UX, consult the user before changing requirements. No recurring online check, extra biometric, forced re-pairing, or physical access is approved.

Test a revoked phone against both LAN and relay after restoring an earlier backup, including with the gateway offline. Platform feasibility remains planned work, not a verified claim.

Round 13 review — GLM, management scope

Scope: sections 1–2 plus the supplied section 16 cross-context (and section 5/17 excerpts), frozen revision 19. Prior disposition read; current text checked independently. No runtime verification claimed.

Round-12 corrections verified

Opus 1 (counter recovery). The head is gateway-authenticated, bound to owner/Mac/gateway/fresh query, and carries the retained Mac-signed control receipt, so the root cannot be fed an fabricated applied revision. Advancing to max(local, acknowledged)+1 and re-signing current trusted desired state (never renumbering an old outbox mapping) correctly clears drift. Lifecycle-epoch changes, revoked registrations, and unverified trust are explicitly excluded from numeric repair, with administrator recovery as fallback and pre-commit rollback preserving trust state. Sound.

Opus 2 (token challenge sequencing). Candidate creation is root-signed and non-mutating; only the gateway sends the opaque challenge; the phone responds over its authenticated channel binding candidate/nonce/digest/epoch with no action authority; final activation is root-signed after an enrollment recheck; candidates are single-use and expiring; revocation invalidates pending candidates and late proofs cannot supersede a newer mapping. No biometric, approval notification, admin prompt, or re-pairing is added; an offline Mac defers rather than authorizes. Sound and UX-consistent.

Independent boundary checks

• Unprivileged transport relaying the control outbox cannot forge controls (root-signed, pinned key) or help by withholding/replaying: monotonic revisions, operation-ID idempotency, envelope expiry, and fresh-envelope regeneration cover it; delayed remote cleanup after local revocation is explicitly not promised and is backstopped by phone-side Mac-authority checks.
• A dishonest gateway can at most suppress or misdeliver: wakes are opaque and phones check current Mac authority before showing actions, so no authority is mintable; stale-revision lying requires a receipt it actually holds.
• Tombstones survive mapping updates; re-add requires a new phone epoch; lifecycle-epoch binding on control objects blocks cross-epoch replay after gateway state loss, where repair is the authorized new-epoch registration.
• Credential table matches the prose: submission credential is wake-only, provisioning credential is owner-scoped and grants no provider/Cloudflare rights, provider secret never reaches Mac or phone; audit records exclude tokens and management secrets.
• Section 1/2 remain internally consistent with the new boundary; no consultation-triggering UX change is smuggled in.

Feasibility items (Cloudflare permission scoping, provider granularity) are properly gated planned work, not defects.

NO SUBSTANTIVE FINDINGS

Round 13 review — GLM transport/management follow-up

Scope: sections 1, 2, 3, 15 of revision 19, plus the labelled cross-section context (section 16 management, section 16 LAN/relay, section 5 enrollment, section 17 generation checks and release manifest).

Prior disposition check (verified in current text):

• Opus 1 (counter recovery): section 16 now reconciles an authenticated gateway head (owner/Mac/gateway-bound, with retained Mac-signed control receipt), advances to max(local, acknowledged)+1, and signs current trusted desired state. Epoch, tombstone, and revoked-registration guards block repair-by-renumbering. The backup-restore and failed-migration acceptance cases cover the dangerous variants. Correction present and sound.
• Opus 2 (token challenge sequencing): the four-step candidate flow root-signs candidate creation, gateway-delivered possession challenge, enrolled-installation response over the authenticated Mac channel, and root-signed final activation. Expiry, single consumption, revocation invalidation, race handling, and the no-biometric/no-prompt UX are all specified. Correction present and sound; no new gap introduced (a token string alone still cannot redirect wakes, and candidate creation cannot mutate the active mapping).

Independent check of the changed management boundary: gateway bootstrap ownership, provisioning-credential scope, typed control objects with epoch/revision/operation-ID binding, idempotent retries, outbox refresh after expiry, tombstone survival, offline revocation semantics, uninstall/reactivation epochs, and the credential table are mutually consistent with sections 3 and 15 (transport submission credential is wake-only; gateway never an enrollment authority; local revocation immediate; pending-remote-cleanup surfaced honestly). Gateway state loss resolves through lifecycle-epoch rejection and authorized repair rather than silent re-acceptance.

Sections 1, 2, 3, 15: the biometric table matches the binding UX exactly (allow-once/deny-once/cancel without biometrics; every reusable rule, Forever default, command/1Password/credential release with biometrics); consumption, dispatch-permit, crash-unknown-result, session availability, push privacy, wake/fetch, first-valid-decision, and delivery-health requirements are internally consistent; LAN/relay path rules preserve request identity, expiry, and single consumption. No contradiction, missing error path, or authority-escalation route found in the reviewed text.

No UX regression is proposed; no correction is needed.

NO SUBSTANTIVE FINDINGS

Independent plan review — Remozio revision 19 (full plan)

Verdict: NO SUBSTANTIVE FINDINGS

What was assessed

Round-12 disposition challenged with concrete scenarios:

• Gateway counter recovery (§16): I traced both drift directions. Root-stale: gateway's authenticated head plus the rule "advance to max(local, acknowledged)+1 and sign current trusted desired state" avoids renumbering old mappings. The more dangerous case — root restored from a backup predating a phone revocation — is closed by two independent mechanisms: gateway revocation tombstones reject re-adding a phone under its old epoch via an ordinary mapping update, and the local rule that restored backups must confirm trust from non-rolled-back records or authenticated recovery before republishing mappings or enabling actions. Neither mechanism adds steps to normal approvals. No unresolved scenario found.
• Token-possession challenge (§16): Candidate creation is root-signed and cannot alter the active mapping; only the gateway delivers the nonce to the candidate token, so a token string alone cannot redirect wakes; the proof binds candidate ID, nonce, token digest, and enrollment epoch and is consumed once with expiry; revocation invalidates pending candidates per epoch; rotation races and transport-initiated probes are explicitly excluded and scheduled as acceptance tests. The proof's value depends on the nonce reaching the phone only via the provider push, which the text's "only the gateway sends the opaque provider challenge to that candidate token" establishes. No defect.

Cross-section contradiction checks (earlier invariants vs. later additions):

• Memory-only sensitive payloads (§6) vs. durable journal (§12): consistent — audit stores closed metadata classes; pending payloads die with root restart and unconsumed requests cancel.
• §13 target-deadline display vs. §6 monotonic Remozio expiry vs. §14 idle-delayed handoff: original age/deadline preserved across handoff and recapture; short-lived 1Password prompts are explicitly not extended.
• §14 routing control and §17 update-scheduling control both ride the narrow decision key with distinct signed purposes, revision/one-use binding, and no biometric — consistent with §6 purpose separation and the confirmed biometric-free UX tradeoff (§1, §9).
• §15 push vs. §14 presence: no new pushes while requests are kept local; handoff sends only still-valid requests with original age.
• §17 restart matrix vs. §6 crash rules: consistent, including the UI-only automatic recapture constrained to never-consumed requests with fresh challenges; command resubmission after unexpected restart is caller-visible, which preserves the no-auto-retry invariant.

Downgrade/replay gaps: §18 negotiation is transcript-bound to pairing identity, floors come only from trusted local software/authenticated release policy, no weaker re-encoding of signed requests for older phones, no retry after signature failure. §17 anti-rollback correctly places enforcement outside the candidate binary (external activation boundary), with old-adapter certification invalidation and receiving-key generation binding on floor raise. Gateway control plane is epoch/revision/operation-ID monotonic with tombstones. Decision, routing, scheduling, and token-candidate replays each have explicit single-use bindings.

Privileged update paths: Protected-placement invariant (§3) is carried through cloudflared, the setup controller, and Sparkle activation (§16–17); the bundle-replacement-during-live-permit case is handled by deferring on-disk installation, not just relaunch. Floor commit is a single durable transaction with admission closed until one compatible set validates.

Scope classification and key separation: Once-decision authority is confined to the captured attempt set (§9); both verifiers independently reject decision-key reusable-rule effects regardless of button labels; the confirmed allow-once exception is not widened to commands or 1Password.

UX preservation: No new confirmations, biometrics, or manual steps introduced anywhere in the additions; remote functionality, full command rendering, and all three adapters remain in scope.

Tentative UX choices (deferred, not defects)

Idle interval (30 s draft, §14), five-minute expiry (§5), retention duration (§12), biometric-invalidation policy (§5/§7), sudoers integration choice (§8), and the local command approval path (§14) are explicitly deferred preferences or gated decisions with consultation paths — correctly not treated as findings per the review protocol.

Remaining implementation verification limits

This is a plan-only review. Convergence here does not establish: macOS service-management protected placement and anti-rollback enforcement, 1Password/Little Snitch AX fixtures and true once-semantics, single-biometric credential release, descriptor-based execution, sudoers policy compatibility, Android background/Doze delivery, background Access authentication, or Sparkle/service-management update continuity — all are defined feasibility gates with evidence and failure/consultation paths. Flux licensing remains unresolved; independent reimplementation is correctly mandated. Deferred product preferences still need user selection before implementation.

NO SUBSTANTIVE FINDINGS

Remozio plan review: revision 19

Finding 1 (Medium): Restore-rollback detection has no mechanism, and gateway revocation evidence is not applied locally

Sections: §16, "Synchronize lifecycle changes and cleanup"; §17, "Failure and recovery"; §5, "Revocation and pairing recovery".

What the plan says now:

• A restored backup "must not silently restore revoked phone authority locally or remotely."
• The Mac must confirm current trust "from protected non-rolled-back records or authenticated recovery evidence."
• "The gateway is never an enrollment authority for local actions."

What is missing:

• The plan never says how the root detects that its own enrollment store was rolled back.
• It schedules no feasibility gate for that detection.
• The new counter recovery handles only the gateway side. The root advances the counter and "signs its current trusted desired state." But after an undetected restore, that state is the stale one.

Failure scenario:

1. The user revokes a lost phone. The gateway records a revocation tombstone at revision N.
2. Later, the user restores the Mac from Time Machine or Migration Assistant. The restored root records predate the revocation, and ordinary on-disk state cannot reveal this.
3. The Mac reconciles the gateway head. It sees revision N and the tombstone, then re-signs a mapping at N+1 that includes the lost phone. The gateway correctly rejects re-adding it.
4. Nothing in the plan makes that rejection, or the unexplained higher revision, affect local authority.
5. The lost phone reconnects over LAN or the tunnel. Its decision key regains local authority for allow-once, routing, and update-scheduling decisions.
6. If the phone is still unlocked in a thief's hands, those decisions can be used. Biometric actions still need the owner's biometric, but the revoked enrollment has been silently revived locally.

This is not covered by an existing gate. §3 and §17 gate the placement and anti-rollback of code. Rollback of trust state has only a requirement, with no mechanism and no failure path.

Minimal correction:

1. Treat gateway evidence as restrictive-only rollback evidence. A gateway head can prove the Mac previously signed a higher revision or epoch than it holds locally, or can carry a tombstone for a locally enrolled phone. In either case the root must:
   • mark its trust state as possibly rolled back;
   • suspend the affected phones' authority, and suspend new mapping publication;
   • route the user to the existing independently authenticated administrator recovery. This does not make the gateway an enrollment authority, because it can only remove authority, never grant it.
2. Add a feasibility item for local detection of trust-store rollback, such as a protected monotonic marker, if the platform offers one. It needs a documented failure path for the case where the gateway is unreachable at startup.
3. Add an acceptance case: revoke a phone, restore the pre-revocation state, and confirm the revoked phone cannot act locally over LAN or relay.

UX impact: None in normal operation. After a detected restore, the user goes through the already-specified administrator recovery. That is an exceptional manual step, not a new routine confirmation. It should still be disclosed to the user.

Prior disposition (round 12)

• Opus 2 (token challenge sequencing): The candidate → challenge → proof → activation sequence is sound. Candidates cannot change the active mapping. Revocation invalidates pending candidates. No biometric or approval notification is added.
• Opus 1 (gateway counter recovery): This correctly fixes the stale-counter liveness problem. Its trust-restoration half depends on Finding 1 above.

Other areas assessed (no further findings)

• Scope classification: Biometric-free use is limited to cancel, deny-once, and Little Snitch allow-once. No widening to command execution or 1Password was found.
• Key separation: The decision key's purposes stay confined to one-time decisions, routing, and update scheduling.
• Relay resistance: Relays and transport credentials cannot mint decisions or read request contents.
• Update activation: Activation waits for quiescence and commits floors atomically. A failed update does not interrupt running work. The transparent resubmit applies only to authenticated no-admission responses.
• Mixed versions: A signed request cannot be re-encoded for an older phone, and negotiation is authenticated so downgrades fail.
• Routing: Routing is delivery-only. It keeps revision control and has an explicit gap state until local command approval exists.
• Audit and expiry: Audit data minimization and the separation of target expiry from Remozio expiry are consistent.

Deferred preferences (idle threshold, retention duration) and the existing feasibility gates are not treated as defects. Platform feasibility remains unverified.

SUBSTANTIVE FINDINGS REMAIN

Round 12 disposition

Reviewed frozen revision 18, SHA-256 45d9fe6bc8363a1e92663c2ff2dba6dcc055482b663e64aa9baeaa7ddbdb9a69.

• K3: complete full-plan report, no substantive findings.
• Opus: two substantive findings. Both corrected in revision 19.
• GLM: authority and history scopes completed with no substantive findings. Management stopped at its output limit with a partial report and no verdict. That pass is not counted as clean; smaller overlapping scopes will cover it.

Opus 1: gateway counter recovery

An older local counter could prevent subsequent cleanup after restoration. Section 16 now reconciles an authenticated gateway head, advances the counter, and signs current trusted desired state. It never renumbers an old mapping. Revocation tombstones and recovery checks prevent restored backups from re-enabling revoked phones. Independent administrator recovery is available when trust cannot be established. This adds no step to normal approvals.

Opus 2: token challenge sequencing

Section 16 now defines root-signed candidate creation, gateway delivery of the possession challenge, enrolled-phone response, and root-signed final activation. Candidate creation does not change the active mapping. Expiry, revocation and newer-token races cannot activate stale candidates. No biometric or approval notification is added.

Review limits

This is a design review. Platform feasibility gates remain unverified. No user-facing approval policy has changed.

Round 12 review — GLM (sections 1, 2, 5, 6, 7)

Input: revision 18 excerpts as provided. Prior disposition (round 11) reviewed: its four corrections are reflected in the in-scope text — section 6 now separates routing control, update scheduling, and gateway control as distinct purposes, and the decision key's authority exclusions remain intact. The routing/gateway/audit/outbox details live in sections 14/17 and are out of scope here.

Checks performed:

• Biometric policy consistency (§1 table ↔ §6 scope enforcement ↔ §7 key requirements): allow-once/deny-once/decline/cancel without biometrics, every reusable rule (including session/timed and Deny Forever) with biometrics, both verifiers deriving key class from retained semantics rather than message assertions. Consistent; no bypass path in scope.
• Decision-key confinement (§6): purpose separation, exclusions (rules, commands, 1Password, credential release, enrollment), and coverage of deny-once/target-cancel via the cancellation-authority paragraph. No authority gap found.
• Enrollment/revocation boundary (§5): admin authorization is verified on the Mac (remote SSH/screen-sharing satisfies this without physical presence), network messages cannot enroll/replace/revoke, revocation serialized with decision consumption, last-phone cancellation only when no implemented approval surface remains, native dialogs unaffected. Consistent with §1 and §6.
• Pairing preservation across biometric invalidation (§5): decision key continues only for one-time actions, never replaces biometric/credential keys, recovery via remote-administrator path within the retained pairing record. No forced re-pairing; feasibility gate correctly framed.
• State machine and race handling (§6): consumption persisted before side effects, terminal states only when undispatched, ledger-arrival wins across phones, late/stale approvals rejected, unknown terminal for retry, permit invalidation and bounded acknowledgments for adapter crashes. No ordering defect found.
• Size limits and encoding (§6): distinct "Request too large" outcome, no truncation at any stage, no signed shell strings, expiry under Mac monotonic clock with skew not extending authority. Sound.
• Section 7: BIOMETRIC_STRONG with no grace period, immutable request selection across lifecycle transitions, no lock-screen surface, no notification-action bypass, credential release bound to paired adapter and exact request, one-biometric gate with explicit consultation path. No UX regression or consent-binding defect found.

No correction considered would improve security without either restating existing text or worsening the confirmed UX (e.g., adding biometrics to one-time decisions or physical presence to enrollment), so none is proposed.

NO SUBSTANTIVE FINDINGS

Round 12 review — GLM (sections 1, 2, 12, 13, 14)

Checked the revision 18 text independently against the binding UX contract, the internal consistency of the scoped sections, and the round-11 disposition.

Disposition verification:

• K3 1 (audit closed classes): faithfully incorporated in §12 — closed action/scope metadata classes, raw bound values excluded from journal and cache, full scope memory-only.
• K3 2 (remote routing recovery): faithfully incorporated in §14 — phone-side Automatic/At my Mac/Away under a distinct signed routing-control purpose with operation ID, challenge, expiry, and expected-revision compare-and-set; idempotent retries; conflict returns current mode; persistent manual modes with no auto-expiry; no extra biometric.
• Gateway mapping and cloudflared items live outside the scoped sections; not assessed here.

Consistency spot-checks that passed:

• §1 biometric table matches the binding UX exactly (no biometrics for allow-once/deny-once/cancel; every reusable rule including session/timed; one biometric for commands and 1Password).
• §12 atomic consumption+journal commit, unknown-outcome-on-lost-write, and no second execution authority are mutually consistent, including crash-between-commit-and-dispatch.
• §13 keeps Remozio authorization expiry, target expiry, and the Mac's monotonic deadline distinct; pre-dispatch revalidation covers the biometric-open race; refresh cannot revive expired authority.
• §14 handoff rules don't conflict with §13 (presence changes never invalidate an open biometric operation; expiry rules still govern); racing local/phone decisions consume once; locked/dark overrides activity; unknown brightness is not treated as dark; degraded detection fails open for delivery only, never for authorization.
• Routing controls grant no action authority, cannot alter enrollment/scope/expiry/biometric policy, and no scoped correction adds confirmations, forced re-pairing, physical access, or extra biometrics.

No substantive actionable defects found in the scoped sections.

NO SUBSTANTIVE FINDINGS

This attempt did not complete successfully. Its retained text is evidence only; it is not counted as a clean review.

Round 12 review — GLM (management boundary follow-up)

Scope reviewed: Sections 1, 2, 3, 15, 16 of revision 18, plus the attached section 5/17 cross-section context. Independent read of the current text; no runtime verification claimed.

Prior-disposition incorporation verified:

• Round-11 Opus 1 / K3 3 (gateway mapping authority): fully present. The setup controller bootstraps owner-scoped trust with a separately scoped provisioning credential (§16 "Gateway ownership and recipient authority"); the root owns the recipient set and signs only typed control objects under a distinct purpose, bound to owner/Mac/gateway/epoch/revision/operation ID/expiry; the submission credential cannot mutate mappings; epoch/revision/operation-ID idempotency, ack-of-applied-revision, durable outbox, expired-envelope regeneration without revision lowering, uninstall tombstones, and fresh-epoch reactivation are all stated. The credential table is consistent with the prose on all seven rows.
• Round-11 GLM 1 (cloudflared placement): present — root-owned placement excluding interactive-user and admin-group writes for all service-account executables, dependencies, config, registrations, and update paths, with signed release inventory and no user-writable self-update.
• The disposition's explicit three-way distinction (immediate Mac revocation vs. gateway acknowledgment vs. already-queued provider pushes) appears verbatim in §15 "Bind and rotate registration tokens" and §16 "Synchronize lifecycle changes and cleanup"; the two sections agree

NO SUBSTANTIVE FINDINGS

This was a plan-only review of revision 18 and the round-11 disposition. I did not perform testing, browsing, or source inspection.

Boundaries assessed

• Authority and request binding: Sections 2, 3, and 6 consistently separate caller identity, adapter assertions, transport authentication, approval authority, and biometric assurance. Requests bind the Mac/account, canonical payload, challenge, expiry, permitted choices, and exact action scope. Decision keys are purpose-limited and cannot authorize commands, credentials, enrollment, reusable rules, routing artifacts, or target actions outside their intended scope.
• Consumption and concurrency: Sections 5–6 and 13–18 consistently use the root ledger as the atomic consumption point. Multi-phone races, revocation, stale approvals, expiry, cancellation, permits, reconnects, and crashes do not provide an identified replay or double-execution path.
• Command execution: Section 8 binds argv, executable identity, working directory, target identity, environment, caller identity, I/O mode, and stdin classification. Uncaptured stdin/TTY content is explicitly disclosed rather than represented as approved content. Executable substitution, caller exit, sudoers compatibility, and process-lifetime races have defined evidence gates and failure paths.
• UI adapters: Sections 9 and 13 preserve request/dialog identity, semantic revalidation, one-time permits, scope binding, secure-field targeting, target deadlines, uncertain outcomes, and refresh semantics. Unknown compatibility cannot inherit one-time classification or be overridden with biometrics.
• Android biometrics and credentials: Sections 5 and 7 keep biometric, decision, credential, enrollment, routing, update, and transport purposes separate. Lock-screen behavior, immutable selection, overlay risks, biometric-key invalidation, pairing preservation, and credential recipient binding are addressed without adding an unauthorized lock-screen workflow.
• Presence routing, push, LAN, and relay: Sections 14–16 keep routing controls separate from action authority. Push payloads remain opaque, phones fetch authoritative state before acting, parallel LAN/relay paths cannot execute twice, and relay compromise remains limited to delay, loss, and metadata exposure. The round-11 gateway corrections provide owner binding, enrollment-derived mappings, possession-checked tokens, revisions, replay protection, and uninstall tombstones.
• Audit privacy: Section 12 uses closed action/scope classes and keeps sensitive targets memory-only. The authoritative journal commits with consumption, while sync cursors, sequence boundaries, and revocation behavior do not create approval authority.
• Updates and protocol evolution: Sections 17–18 preserve protected placement, authenticated component identity, anti-rollback, staged activation, quiescence, floor commitment, no-admission responses, and restart semantics. Envelope negotiation cannot rewrite signed requests, lower floors, translate decisions, or grant authority to old contracts. Mixed-phone selection is constrained by floors and required action features.

The revision-18 changes also resolve the prior gateway-mapping, cloudflared placement, audit-scope, and remote-routing concerns without an apparent contradiction with earlier approval or revocation invariants.

Remaining tentative product choices—not planning defects

The plan explicitly leaves these for feasibility evidence and user decision:

• Android biometric-key invalidation and pairing-preservation behavior, §§5 and 7.
• Whether one biometric operation can safely authenticate and release a request-bound credential, §7.
• The sudoers-compatible authorization model, executable-race contract, and any workflow-affecting environment/input restrictions, §8.
• Concrete 1Password and Little Snitch behavior from real fixtures, §9.
• The local command-approval surface and draft idle interval, §14.
• Push-provider suitability and Access background-credential renewal behavior, §§15–16.
• Audit retention duration and storage budget, §12.

Any resolution that adds confirmations or biometrics, restricts commands, removes remote functionality, shortens practical response windows, or requires recurring manual steps remains subject to the consultation rule in §1.

Remaining verification limits

This result does not establish that the required macOS service-management APIs, XPC identity checks, protected placement, Accessibility structures, Sparkle behavior, Android Keystore behavior, background delivery, Cloudflare Access flow, or credential-release operation work as assumed. Those remain explicit implementation and feasibility-gate responsibilities. It also does not validate the eventual cryptographic construction, canonical CBOR subset, protocol implementation, adapters, or privileged code; those require implementation review and testing.

Remozio plan review: revision 18

Scope: I reviewed the complete revision 18 text on its own. Earlier convergence does not carry over. I did not run tests, browse, or inspect source code.

Findings

1. Gateway revision counters can fall behind after a Mac restore (Low–Medium)

Sections:

• §16, Gateway ownership and recipient authority
• §16, Synchronize lifecycle changes and cleanup
• §17, Failure and recovery

Failure scenario:

1. The gateway has acknowledged mapping revision N.
2. The Mac's local state is then restored from a backup, or rolled back after a failed migration before a floor commit, to a point where it last persisted revision N−k.
3. The plan requires the gateway to reject stale revisions, so every later root-signed control is rejected. This includes phone revocation cleanup and token rotation.
4. The plan offers only two ways out:
   • Never lower the revision. This leaves the Mac permanently unable to update its mapping.
   • A fresh administrator gateway registration with a new epoch. The plan reserves this for reactivation after removal.

Either path breaks the §16 rule that repair must not need manual gateway-operator work after setup. It also leaves remote suppression of a revoked phone stuck on "pending remote cleanup" indefinitely.

The §17 statement that restoring a backup "cannot lower these protections" covers ledger and floors. It does not define how the root resynchronizes a counter that is owned remotely.

Minimal correction:

• A stale-revision rejection should return the gateway's authenticated last-applied revision and epoch, bound to the pinned authority and owner.
• The root should then re-sign its current desired state at max(local, acknowledged) + 1. It must not re-sign an older mapping.
• Add acceptance cases for backup restore and pre-commit rollback followed by revocation.

UX impact: None. This preserves the promise of no operator step.

2. The plan never says who sends the token-possession challenge (Low)

Sections:

• §16, Bind phone tokens without new approval steps
• §15, Bind and rotate registration tokens

Failure scenario: Proving possession of a new token requires sending a provider push to a token that is not yet mapped. The plan forbids a "general send-to-token endpoint through the transport credential." It also says the root signs the updated mapping only after checking enrollment. It never states the order of the two steps.

An implementer could resolve this in either of two unsafe ways:

• Let the transport send probes to arbitrary tokens. This recreates the forbidden endpoint.
• Sign the mapping first and verify possession later. A token string alone could then redirect wakes, which the plan says must not happen.

Minimal correction: Specify the sequence:

1. The root signs a typed "candidate token" control object bound to the enrolled phone, enrollment epoch, and token digest.
2. The gateway alone sends the opaque challenge to that candidate.
3. The phone's authenticated response lets the root sign the final mapping revision.
4. The gateway activates the token only for a matching, verified candidate.

Keep the existing per-enrollment probe bound.

UX impact: None. There is still no biometric and no administrator prompt.

Assessment summary

Revision 18 closes the round-11 items coherently:

• Gateway mapping authority is separated from the submission credential.
• Service-account executables have protected placement.
• Audit scope uses closed classes rather than target values.
• Phone routing control uses a narrow revisioned purpose with no added confirmation.

Other areas checked, with no new defects found:

• Scope classification: consistent between §1, §6, and §9.
• Decision-key purposes: routing and update scheduling carry no target, enrollment, or release authority.
• Update activation: quiescence-based activation, floor commit, and anti-rollback are consistent with the §3 placement invariant.
• Mixed-version protocol: selection cannot weaken a signed request.
• Command capture and stdin disclosure: consistent across sections.
• Remote UX: preserved. Routing overrides are persistent, there are no added biometrics, and response windows are not shortened.

Remaining verification limits sit in declared feasibility gates, so they are not planning defects:

• protected placement or launch enforcement for SMAppService/Sparkle updates
• pre-login transport key custody
• single-biometric credential release
• secure-field targeting
• true one-time Little Snitch effects
• Access background authentication
• local command approval under At my Mac
• sudoers compatibility

The idle threshold and retention duration remain deferred product preferences, not findings.

SUBSTANTIVE FINDINGS REMAIN

Round 11 disposition

Input: revision 17, SHA-256 44df7a57e03b986728d9c3e6d082a7a43293b0a2e47a9dfaec2493bdfaec2380.

All three reviewers completed with nonempty reports. Opus reported one low–medium finding, K3 three low findings, and GLM one low finding. Opus and K3 overlap on gateway mapping authority.

Corrections in revision 18

Explicitly distinguish immediate Mac revocation from gateway acknowledgment and already-queued provider delivery. Retries regenerate expired control envelopes from current desired state; they never resurrect obsolete mappings. Root signatures cannot be requested for arbitrary cloud bytes.

These changes preserve the existing approval UX and improve remote recovery. No forced pairing, physical access, command restriction, deadline reduction, or new biometric was introduced.

Round 11 review — GLM management-boundary pass (revision 17, sections 1, 2, 3, 15, 16 + labelled context)

Reviewed the provided revision-17 excerpts directly; no runtime verification performed or claimed.

Finding 1 — Section 16, "Cloudflare Tunnel endpoint" (cross-ref: section 3 placement rules; section 16 transport acceptance cases)

Severity: Low

The section requires protected files, parent directories, registrations, and provisioning paths for the tunnel and push-submission credentials, and applies protected-placement/signed-generation/update rules to Remozio's own bundles and to the new setup controller — but states no placement or update-path requirement for the third-party cloudflared executable itself, which runs under the same dedicated transport account that holds both credentials. Section 3's "root-launched code must resist replacement" sentence is scoped to Remozio's trusted bundles, and the acceptance list tests same-user replacement of the credential files, not the binary that reads them.

Concrete failure: an unprivileged process running as the interactive administrator replaces a cloudflared binary installed on an admin-writable path (the exact /usr/local-style pitfall section 3 calls out). launchd restarts it as the transport account; the replaced binary reads the tunnel run credential and Mac push-submission credential from dedicated-account-private storage — storage the plan otherwise correctly protects — and exfiltrates both. The attacker then operates a competing connector for the configured hostname (persistent endpoint impersonation, metadata exposure, selective DoS) and can spam mapped wake notifications. Severity is bounded: end-to-end payload encryption, pinned identities, and gateway recipient mapping still prevent request forgery or decryption.

Minimal correction: one sentence in this subsection extending the existing custody requirement to the cloudflared executable and any binary run under the transport account — root-owned, non-user/admin-group-writable file, containing directories, registration, and update path (no self-update into user-writable locations) — and one added acceptance case: same-user replacement of that executable.

UX impact: none. Setup-time file placement only; no new prompts, biometrics, enrollment, or manual steps. Consistent with the binding UX constraints.

Disposition verification (round 10 / Opus 1)

Checked against the revision-17 text: the setup controller appears in the section 3 component inventory and the section 17 release manifest; management token custody is root-only, outside transport and interactive-user storage; operations are administrator-authorized, typed, and resource-bound with no listener or generic proxy; phone, push, and transport credentials are explicitly barred from invoking them; Cloudflare scoping granularity is a recorded feasibility obligation with disclosed-approval fallback; recurring credential entry or authorization prompts remain a consultation blocker. No approval-flow, biometric, pairing, or remote-functionality change appears in the scoped sections. The disposition's description of the revision-17 correction is accurate.

Conclusion

SUBSTANTIVE FINDINGS REMAIN (one low-severity, one-line correction; no UX cost).

Independent review — Remozio plan, revision 17

Scope reviewed: complete plan including post-revision-5 additions (§12 audit, §13 expiry, §14 presence routing, §15 push, §16 LAN/relay + cloud management, §17 identity/Sparkle/updates, §18 protocol evolution), plus the round-10 disposition. Plan-only review; no testing or source inspection claimed.

The round-10 correction (§16 administrative setup controller) is adequately integrated: it appears in the §3 component inventory, follows §3/§17 placement and generation rules, is credential-separated per the table, has typed resource-bound operations with post-mutation verification, and has matching acceptance tests. I found no unresolved scenario there and do not challenge that disposition.

Findings

1. Low — §12 audit event schema conflicts with §12 sensitive-data exclusions

"Event schema" requires each event to record "selected action and scope." "Sensitive data exclusions" forbids persisting "destinations," "item names," and "UI text." For a Little Snitch decision, the bound scope inherently includes the destination host/IP, port, and duration; for a 1Password access decision the action references an item. As written, an implementer must either store the full bound scope (violating the exclusion rules and risking failure of the "seeded secrets never occur in the journal" acceptance case) or store only an action label (failing the acceptance case requiring the log to distinguish "one-time and reusable decisions"). Failure scenario: two engineers read the same section and produce either a privacy violation or an acceptance failure.

Minimal correction: define audit-record scope granularity explicitly — record action kind and scope class (once / until-quit / session / forever; host / domain / any) plus the structured reason codes, and state that the full bound scope values exist only in the memory-resident signed request and are never journaled, mirroring the existing "detail view explains that full request contents were not retained" language. No UX impact; no consultation needed.

2. Low — §14 manual routing override has no remote recovery path and can silently strand the core scenario

"Manual modes override automatic presence detection until the user changes the mode," the mode "persist[s] across app restart," and the override is only visible in Android device status — there is no phone-side control. Failure scenario: the user selects "At my Mac," then leaves. All requests are kept local indefinitely; command callers see only the routing reason locally, the phone shows the stuck override but cannot act, and remote approval — the product's central use case — is dead until physical return. The §14 degraded-detection fallback ("route to the phone" on unavailable presence data) does not apply because the manual mode is not a detection failure.

Minimal correction: either (a) allow an enrolled phone to set routing mode using the already-established authenticated device-control pattern (a further narrowly-scoped decision-key purpose, like §17 update scheduling — an override grants no authorization and a malicious mode change is availability-only), or (b) bound manual override lifetime and revert to Automatic. This adds remote capability and adds no confirmation, biometric, or manual step, so it does not trigger the §1 consultation categories; alternatively record it as an explicit pending user decision. Severity is low because it is a UX completeness gap, not a security boundary defect.

3. Low — §15 gateway recipient-mapping and revocation propagation trust chain unspecified

The gateway must "enforce its enrolled recipient mapping," and "revocation stops future pushes and authenticated fetches for that phone," but the plan never states which credential authenticates the Mac↔phone mapping at the gateway or how revocation propagates to it. If mapping updates are authenticated only by the Mac push-submission credential (held by the dedicated transport account per the §16 table), compromise of that credential could rebind recipient mappings. Impact is limited — wakes are opaque and fetches still require enrolled-phone authentication, so this leaks only delivery timing metadata, not request content or authority — but the §16 acceptance tests exercise credential substitution on the Mac side only, not gateway-side mapping integrity.

Minimal correction: specify that enrollment, replacement, and revocation of the gateway recipient mapping are authenticated by the Mac authority key (matching the phone-side authenticated registration), define revocation propagation to the gateway, and state explicitly that Mac-side revocation remains authoritative for fetches even before gateway propagation completes (parallel to the §16 Access-revocation rule for phones). Add a gateway-mapping acceptance case. No UX impact.

Tentative UX choices (declared pending; not findings)

The 30-second idle interval, the ~60-second 1Password lifetime estimate, and audit retention duration are explicitly deferred product preferences with validation paths; per the review instructions I raise no finding on them. The 1Password estimate is correctly scoped as per-prompt-type validation work, not a guarantee.

Assessed boundaries (summary)

• Scope classification and key separation: §1/§6/§9 are internally coherent — reusable rules (including temporary/session and Deny Forever) require the biometric key at both verifiers; once-decisions are confined to the captured alert set with second-attempt validation; the decision key's purposes are closed and §17 scheduling controls are correctly excluded from target-action authority. The confirmed biometric-free Little Snitch allow-once is not widened anywhere.
• Replay/downgrade resistance: §18's last-known authenticated capability records prevent a network attacker from forcing weaker contract selection by suppressing v2 phones; §17 floor commit, external anti-rollback at activation, and "never resubmit on unknown admission" close the obvious update-window races. Unproven elements (protected placement, generation-isolated key access, atomic execution, single-biometric credential release, noninteractive Access auth) are all defined feasibility gates with failure/consultation paths, not unexamined assumptions.
• Cross-section consistency: §12/§6 journal-consumption atomicity, §13/§17 age preservation across recapture, §5/§14 multi-phone delivery qualifiers, and §16/§17 controller custody are consistent; the contradictions I found are limited to findings 1–3 above.

Conclusion

SUBSTANTIVE FINDINGS REMAIN — three low-severity, actionable planning defects (§12 audit-schema/exclusion conflict; §14 stranded manual override; §15 gateway mapping trust chain). None requires a UX-worsening correction, none removes an adapter from scope, and none invalidates the feasibility-gate structure; all three are specifiable within the existing design vocabulary.

Review of Remozio plan, revision 17

Finding 1: Push-gateway recipient mapping has no named authority (Low–Medium)

References:

• §15 "Bind and rotate registration tokens"
• §15 "Recipients and first-valid-decision resolution"
• §16 "Cloud management authority" (credential table)
• §16 "Keep push separate from the live proxy"
• §16 "Cloudflare Tunnel endpoint" (uninstall and repair)

Defect. The plan has three requirements for the notification gateway:

• It must "enforce its enrolled recipient mapping."
• Revocation must stop future pushes.
• Uninstall and repair must rotate or revoke the Mac's gateway access server-side.

The revision 17 credential table assigns every other cloud-side authority to a holder, but none of these three. The Mac push-submission credential only "send[s] opaque wakes to its enrolled recipient mapping." Gateway policy belongs to "its operator." That leaves open who may add or remove a phone registration for a given Mac, or revoke that Mac's submission credential. The §15 phrase "authenticated registration" does not say whose authentication the gateway checks.

Failure scenarios:

• Phone-authenticated mapping. If the phone's own registration authenticates mapping changes, a revoked phone can re-register or keep its token. It keeps receiving wake metadata for that Mac. This contradicts "Revocation stops future pushes."
• Transport-credential mapping. If mapping changes ride on the transport-held push-submission credential, a compromised transport account can redirect wakes. The credential separation that revision 17 introduced collapses.
• Operator-only mapping. If only the gateway operator can change mappings, then enrollment, revocation and uninstall each need manual operator action. The plan does not disclose or consult on that extra step.

Wake payloads are opaque, so no approval authority is exposed. The concrete harms are:

• Wake-timing leakage to revoked devices.
• Misdirected or spam wakes.
• An unenforceable revocation and uninstall promise.

Minimal correction.

1. Add a table row for recipient-mapping authority.
2. Have mapping additions and removals, and Mac submission-credential rotation and revocation, authorized by the root authority or the setup controller. Use the existing administrator-authorized enrollment, revocation, repair and uninstall operations, under a distinct signed purpose.
3. Require the phone's token registration to be bound to that Mac-signed enrollment record.
4. State whether the user operates the gateway or it is a hosted service. If operator action is ever required during normal lifecycle operations, record it as a consultation item.

This correction adds no approval steps, biometrics or manual steps.

Assessed without further findings

• Key separation and scope classification. I checked biometric, decision, transport, management, Access and push credentials. The Little Snitch one-time exception stays confined to Little Snitch and is enforced by both verifiers. The update-scheduling purpose cannot alter floors or supply artifacts.
• Relay resistance. Payloads are encrypted end to end and requests are authority-signed. Access is additive, not a substitute for Remozio authorization.
• Negotiation downgrade and replay. Negotiation transcripts are bound, signatures are domain-separated, and requests are never re-encoded into weaker schemas.
• Update path. The protected-placement and anti-rollback invariant is enforced outside the candidate binary. Floor commits are transactional, the quiescence rule does not kill work, the resubmission rule prevents replay, and the setup controller is included in the release manifest.
• Earlier invariants against later sections. These hold against expiry handling, the restart matrix, audit atomicity, presence routing and push lifetime.

Items that are correctly scheduled rather than defects:

• Descriptor-based execution.
• Sudoers compatibility.
• Single-biometric credential release.
• Local command approval.
• Cloudflare credential scoping.
• Pre-login key custody.

Each is a defined feasibility gate with a failure and consultation path. The idle interval and audit retention duration are deferred preferences and were not treated as findings.

Remaining limits

These are platform facts that only implementation work can establish:

• Whether an old signed build can be isolated from current receiving keys.
• Whether macOS service management can be updated without renewed authorization.
• Actual Accessibility behaviour of 1Password and Little Snitch.
• FCM reliability under Doze.
• Access service-token behaviour in background delivery.

SUBSTANTIVE FINDINGS REMAIN

Round 10 disposition

Input: revision 16, SHA-256 239d5993e339c249a63d621b0e69e3897c66fffac15ecb8fbabffab4027d2ff6.

K3 completed its full-plan review with no substantive findings. All three GLM follow-up scopes were clean, with unchanged prior coverage retained by exact comparison. Opus returned one low–medium finding.

Correction in revision 17

Opus 1: Cloudflare management credential custody and authority. Accepted.

Section 16 now names a separate signed administrative setup controller. Its management token uses root-only custody, outside transport and interactive-user access. Management calls require the existing administrator-authorized lifecycle flow. Phone, push, and transport credentials cannot invoke them.

The controller has no network listener and offers only typed, resource-bound operations. It cannot act as a generic API proxy or expose arbitrary local ingress. Actual Cloudflare scoping limits are a feasibility obligation; broader permissions need disclosed setup approval. Recurring credential entry or authorization remains a consultation gate.

A credential table distinguishes cloud management, tunnel runtime, push submission, phone Access, and server-side provider credentials. Gateway administration remains with its operator. The component inventory and signed release manifest now include the setup controller under existing placement and generation rules.

No normal approval step, biometric, pairing reset, or remote-functionality restriction was added.

Round 10 review — GLM compatibility pass (revision 16)

Scope: §1, §2, §6, §11, §18, plus the round-9 disposition cross-references that fall inside these sections.

Verification notes

• Biometric matrix consistency (§1 ↔ §6). The §1 table (no biometrics for cancel/deny-once/allow-once; biometrics for every reusable-rule change, Forever default, commands, 1Password, credential release) matches §6 enforcement: both verifiers derive key class from retained action semantics, the narrow decision key cannot authorize rule changes/execution/1Password/release/enrollment, and the allow-once exception is bound to the captured request only. Temporary/session rules requiring biometrics are stated in both sections. No gap.
• State machine ↔ crash handling ↔ §18 acceptance. Terminal-only-when-undispatched rules, consumption-before-side-effect, single-use signatures, and first-valid-decision-wins are internally consistent. §6 "Refresh request" and §18 "Recapture only never-consumed requests, preserving age" agree; no path turns denial, cancellation, crash, or uncertainty into approval or automatic retry.
• Encoding rules (§6 ↔ §18). Reject duplicate/unknown-critical/unsupported-version input, canonical-byte verification without field dropping, no re-encoding into a weaker schema, no relay version trust, and purpose/domain separation are consistent across both sections.
• Round-9 disposition checks. Correction 2 (on-disk replacement is activation; defer installation, not merely relaunch) appears in §18 acceptance ("Defer both on-disk installation and relaunch without interrupting the action"). Correction 3 (retry only an authenticated no-admission response; never replay a possibly admitted command; bounded visible wait) appears in §18 acceptance. Correction 1 (transport credential custody) lies in sections outside this pass's scope and is not evaluated here. The disposition's account of round 9 matches §11's protocol.
• Minor wording, non-substantive: the §6 bindings table lists three signed objects (Request, Decision, Status) while the following text says "define two structures." The surrounding text resolves this unambiguously — status is authenticated separately and "never approval authority" — so there is no concrete failure mode; no correction is warranted.

No UX-regressing corrections were needed; the binding UX constraints (one biometric for protected actions, biometric-free LS once/cancel, biometrics for all reusable rules, no forced re-pairing) are preserved as written.

Conclusion

NO SUBSTANTIVE FINDINGS

Round 10 review — sections 1, 2, 3, 15, 16 (revision 16)

Prior disposition check: The round-9 Opus 1 correction is present in §16 (Cloudflare Tunnel endpoint): cloudflared runs under the dedicated transport account; §3 transport-key custody is applied to both the tunnel credential and the push-gateway submission credential, including protected provisioning paths, no argument/log exposure, independent rotation/revocation, and honest offline-uninstall cleanup. The Opus 2 and 3 corrections concern update/frontend sections outside this pass's scope. The disposition's claim of no UX cost is confirmed in-scope: no added biometrics, forced pairing, response-window reduction, or command restriction appears in the reviewed text.

Independent check:

• §1 biometric table matches the binding UX exactly: one biometric for command/1Password/credential actions; LS cancel, deny-once, and allow-once without; every rule create/change/remove (including the default Forever decision) with; "do not silently select Once" and "preserve the Forever default" are mutually consistent.
• §3 pre-login fallback ("administrator-controlled" directories and registrations) uses the stricter definition established earlier in §3 (root-owned, non-user-writable, anti-rollback); the fallback is correctly excluded from credential-receiving and authority keys, and the blocker/consult path is retained.
• §15/§16 boundaries are consistent: gateway separate from the live proxy; opaque push with verified fetch before actionable UI; Mac authoritative for validity and consumption; single request ID/expiry across path changes with atomic first-valid-decision consumption; revoked phones rejected Mac-side even before Access revocation completes; relay limited to delay/drop/metadata.
• No double-execution, expiry-extension, replay, or notification-as-consent path found in the reviewed sections; feasibility gates (service installation, background Access auth, macOS 14+ floor) are properly framed as planned work.

NO SUBSTANTIVE FINDINGS

Round 10 review — sections 1, 2, 17 (revision 16)

Round-9 correction verification (in-scope items)

• Opus 2 (on-disk replacement as activation): Present and coherent. "On-disk replacement of a bundle containing a running role is activation too. Defer Sparkle installation of that bundle, not merely its process relaunch" is reinforced by separate staging, the protected-placement invariant reference, and the symlink-race feasibility check.
• Opus 3 (submissions at the update boundary): Present and coherent. Transparent wait applies only to an authenticated, submission-bound response explicitly confirming no admission; timeout/lost/unknown results never trigger automatic resubmission; resubmission is fresh capture with a fresh decision; stdin/PTY preservation and the distinct Update installing status are specified. This matches the disposition's claim that nothing admitted or possibly admitted is repeated.
• Opus 1 (cloudflared credential custody): Resides outside the scoped sections; nothing in sections 1, 2, or 17 contradicts it ("No VPN or WARP client is required" remains accurate).

Independent checks

• Binding UX: Biometric table matches the user contract exactly (allow-once/deny-once/cancel/dismiss/decline: none; every reusable rule including session/timed: biometric; Forever default preserved; no silent Once downgrade). Phone update-scheduling controls require no extra biometric and are not target-app actions, so this adds no friction and no bypass (purpose-separated, challenge-bound, one-use, scheduling-only authority). No forced physical access, re-pairing, or added confirmation dialogs; consultation gates are correctly framed as pending decisions, and the feasibility gates as planned work.
• Boundary interactions: Atomic quiescence check/admission close vs. racing submissions, GUI-capture rejection and post-recovery recapture, drain (Update waiting, retryable) vs. automatic boundary (Update installing, bounded transparent wait) are distinct and internally consistent. Late approvals, refresh, and late biometric results cannot revive expired authority in any path.
• Restart/consumption matrix: Permit-consumption boundary aligns across section 17's table, section 6's unknown-after-consumption rule, and section 9's one-attempt scope mutation. Automatic recapture after root restart is correctly limited to ledger-established never-consumed identities with fresh challenges; consumed/unknown follow evidence-or-unknown.
• Floor mechanics: Generation checks on every privileged RPC, OS-validated build identity, cert/receiving-key generation binding, floor commit only via the activation transaction, anti-rollback independent of the candidate binary, and the key-custody failure/consult path form a closed loop with no ordering gap.
• Cross-section consistency: State machine terminal branches, journal-consumption-before-dispatch, expiry/disappearance distinction (Expired vs. No longer available · reason unknown vs. observed Resolved by target timeout with expiry source retained), and requester-exited-before-execution as a consumed no-effect outcome do not conflict with section 17's update lifecycle.

No correction is needed; nothing identified would worsen UX.

NO SUBSTANTIVE FINDINGS

Independent review — revision 16 (round 10)

Scope assessed

Full plan, with attention to the post-revision-5 additions and their interaction with earlier invariants:

• Key separation and purpose binding (§5–7, §17): biometric key, narrow decision key, transport keys, adapter receiving keys, update-scheduling purpose. Decision-key purposes are explicitly enumerated in §6 and the §17 extension (update scheduling) is acknowledged there rather than silently widening authority. Scheduling controls bind Mac/account, phone, update ID, generation, challenge, expiry, and one-use state; they cannot supply artifacts, alter floors, or authorize target actions. No path found where the decision key, relay keys, or push tokens can mint target-action authority.
• Consumption and replay safety (§6, §12, §17): ledger consumption precedes side effects; revocation is serialized with consumption; GUI permits are one-use, watched, and invalidated on adapter death; the §17 admission boundary is closed atomically with request creation/permit dispatch, so the authenticated "Update installing — no admission" response cannot race an actual admission. The revision-16 correction (transparent bounded wait + fresh capture/decision on resubmission, never on lost/unknown acknowledgment) is internally consistent with §8's "never automatically rerun" and stdin/PTY preservation rules.
• Update and anti-rollback path (§3, §17): placement/protected-staging invariants, generation floors enforced per-RPC and bound into adapter-key certification, floor commit only after full quiescence and checks, interrupted-activation recovery keeping admission closed, no rollback below committed floor, on-disk bundle replacement treated as activation (revision-16 fix). The starvation case (continuous work indefinitely deferring auto-activation) is a deliberate, surfaced design choice with an explicit drain action and blocker visibility — not a hidden failure.
• Presence routing vs. request integrity (§13–15): routing changes never grant or revoke authority; handoff preserves identity/age/deadline; already-delivered requests remain resolvable with first-decision-wins; unknown detector state fails toward phone delivery without authorizing anything; expired local requests cannot later produce actionable notifications.
• Audit and timing (§12–13): journal/ledger single authority, memory-only sensitive payloads, exclusion rules, retention independent of trust records, monotonic-clock expiry including sleep, observed-vs-estimated target expiry kept distinct, refresh never revives expired authority.
• Protocol evolution (§18): authenticated negotiation with bound transcripts, no re-encoding to weaker schemas, envelope/request verification separated, floor handling independent of negotiation, stale capability records unable to weaken verification.

Consistency checks on the round-9 disposition

The three accepted corrections (tunnel/push-submission credential custody under the dedicated transport account, on-disk replacement as activation, admission-boundary resubmission rules) are correctly integrated and introduce no contradiction with §3 custody rules, §6 crash semantics, or §8 caller-lifetime handling. No unresolved scenario found in their reasoning.

Items checked and not found to be defects

• Idle interval, retention duration, biometric-invalidation policy, and Access/FCM/provider selections are explicitly deferred preferences or feasibility gates with defined evidence and consultation paths — per instructions and §1, not findings.
• Phone-initiated update scheduling without biometrics is a stated, narrowly-scoped policy decision bound to already-verified releases; it does not widen the decision key into target actions.
• Signed-feed support contingent on a supporting Sparkle release retains EdDSA archive verification as the core control; acceptable as written.
• Relay/tunnel compromise is bounded to delay/drop and metadata; end-to-end payload encryption and authority-signed requests are preserved on both LAN and relay paths.

Remaining verification limits (implementation-stage, not plan defects)

This review cannot validate: actual AX stability of 1Password/Little Snitch dialogs, Secure Enclave/Keystore behavior across OS versions, descriptor-based execution feasibility, XPC code-requirement API behavior on macOS 14+, Sparkle staging-boundary behavior, real-device Doze/FCM latency, or sudoers-policy integration. These are all assigned to feasibility gates with explicit failure/consultation paths, which is the correct disposition for a plan.

Conclusion

NO SUBSTANTIVE FINDINGS

Assessed: custody and purpose separation of all key classes, atomic consumption and crash/unknown handling, relay and push trust boundaries, presence routing invariants, audit/timing semantics, privileged update anti-rollback and activation quiescence, and protocol downgrade/replay resistance, including all revision-6–16 additions and their cross-section interactions. Remaining risk lives in the scheduled feasibility gates and real-device validation, which the plan correctly treats as evidence obligations with user-consultation fallbacks rather than assumed guarantees.

Remozio plan review: revision 16

This review covers the whole plan, sections 1–18. It pays particular attention to the revision 16 changes: tunnel and push credential custody, on-disk replacement as activation, and transparent waiting at the update boundary. It also checks how those changes interact with earlier invariants.

Finding 1 (Low–Medium): custody of the Cloudflare management credential is unspecified

Where:

• §16 "Cloudflare Tunnel endpoint", the "Repair supports rotating and revoking each credential…" and "Uninstall revokes remote tunnel and gateway access" paragraphs
• §16 "Feasibility gate: background Access authentication", "Provision credentials through the authorized pairing flow…"
• §16 "Access and Remozio have different authority", "Cloudflare account API credentials never belong in the Android app"

Problem: Revision 16 now promises several remote operations:

• server-side revocation and rotation of the tunnel credential;
• uninstall-time revocation;
• per-phone Access service tokens issued during pairing.

Each of these needs a Cloudflare account/API credential with tunnel or Access management rights. The plan only says where that credential must not live (the Android app). It does not say where it does live, what scope it has, or who may invoke it.

The §3 "transport-key custody" rule, which §16 applies, covers the tunnel run-token and push-submission credential. It does not cover this broader credential.

Failure scenario: An implementation could store an account-scoped API token with the transport account or in a user-readable config, to make pairing and uninstall work. Anyone who read or misused it could:

• rewrite tunnel ingress to publish other local services, contradicting "Expose only the Remozio protocol endpoint";
• mint Access service tokens;
• weaken the Access policy.

Remozio's end-to-end approval integrity would survive. The unintended network exposure would not, and the "server-side revocation" claim would rest on an undefined authority.

Correction:

• Name the component that holds the management credential. Require least-privilege scope, limited to this tunnel's Access app and service tokens where Cloudflare permits it.
• Apply root/admin-only custody. Invoke the credential only from the already-admin-authorized enrollment, repair, and uninstall flows.
• Keep it out of the transport account.
• Constrain ingress to the Remozio hostname only.
• Add same-user read/misuse attempts and ingress-modification attempts to the §16 transport acceptance cases.

UX impact: None, if the credential is held under protected custody and used inside the existing admin-authorized flows. If instead the chosen design has the user supply the credential at each enrollment or repair, that adds a manual step and needs user consultation.

Assessed without findings

• Rev 16 update-boundary resubmission (§17 "Automatic activation and optional drain"): safe as written. Resubmission is gated on an authenticated, submission-bound no-admission result; unknown or lost results fall back to reconciliation or reported uncertainty; a fresh capture and decision are required. The residual risk is UX only: a connection interrupted mid-replacement surfaces as uncertainty rather than a transparent wait. That is an implementation-tuning concern, not a defect.
• On-disk replacement treated as activation: consistent with §3 protected placement and with the §17 quiescence, floor-commit, and restart-matrix rules.
• Decision-key update-scheduling purpose: it can affect only availability and cannot supply artifacts or floors. It is consistent with the key separation in §6 and §7.
• Consistency checks: scope classification (§1, §6, §9), multi-phone first-valid consumption, revocation serialization, presence routing and handoff, push/relay privacy, and negotiation/downgrade handling (§18) are consistent with the earlier invariants. Allow-once is not widened beyond Little Snitch.
• Remaining uncertainties are scheduled feasibility gates with failure and consultation paths, not planning defects. These are:
  • privileged install and anti-rollback placement
  • generation-bound receiving keys
  • pre-login key custody
  • single-biometric credential release
  • 1Password and Little Snitch fixtures
  • descriptor-based exec and sudoers policy
  • local command approval
  • background Access authentication

Deferred preferences, not findings: the idle threshold and retention duration.

Implementation limits: none of the platform assumptions are verified here. Correctness still depends on:

• real-device and real-macOS evidence from the stated gates;
• conformance tests against the cross-language vectors;
• independent implementation review.

SUBSTANTIVE FINDINGS REMAIN

Round 9 disposition

Input: revision 15, SHA-256 b107c470a189cf7fed66101bdd81f5bdf172f1a8cb73f403a827880efea82394.

K3 completed a full-plan review with no substantive findings. GLM completed all three follow-up scopes with no substantive findings, including update/crash/UI interactions. round-9-glm-coverage.json proves the retained earlier section text is unchanged. Opus returned three low-severity findings.

Corrections in revision 16

These corrections add no biometrics, forced pairing, response-window reduction, or command restriction. Transparent waiting applies only before admission; it never repeats a consumed or possibly admitted command.

Round 9 GLM scoped review — sections 1, 2, 6, 11, 18 (revision 15)

Checks performed

Internal consistency of biometric policy. Section 1's table, section 6's scope-enforcement rules ("any reusable rule change requires the biometric key, including Deny Forever and temporary/session rules"), and the narrow decision key's exclusion list ("cannot authorize rule changes, command execution, 1Password approval, credential release, or enrollment") are mutually consistent and match the binding UX: allow-once/deny-once/cancel are biometric-free, every reusable rule (including deny and temporary rules) requires one biometric, no double biometrics, no forced re-pairing (section 18: "Do not require pairing again merely because versions differ"; section 2: no physical proximity after enrollment).

Authorization integrity. Decision bindings cover request digest, challenge, action/scope, phone identity, key ID, and purpose; key class is derived from retained action semantics, not caller labels or phone assertions; domain separation prevents status signatures verifying as approvals; digest recomputation on both Android and each acting authority is specified; single-use signatures with no sudo-style window. No gap found.

State machine and races. Consumption persisted before external side effect; declined/cancelled/expired terminal only pre-dispatch; first-valid-decision atomic win with explicit stale/Already-handled results; unknown terminal for retry; permit invalidation and bounded acknowledgment; no automatic retry. Coherent.

Section 18 negotiation. Envelope and request-contract selection are properly separated; contract choice maximizes eligible phones with floor/feature exclusion and highest-version tie-break; stale capability records can only reduce reachability; no re-encoding into weaker schemas; unknown optional fields stay inside the signature; noncanonical rejection; policy/floor persistence independent of binaries. No downgrade path found that yields action authority.

Round-8 disposition落实. The three accepted Opus corrections appear in the provided text where in scope: floor commit timing ("Stage a higher floor... Keep the old role usable until replacement checks pass and the new floor commits"), independent root-rollback rejection ("Reject it independently of its own startup checks"), and recapture constraints ("Recapture only never-consumed requests, preserving age and requiring a fresh decision"). Section 11's coverage rules (exact text comparison, overlapping scopes after output-limit exhaustion, no silent model substitution) match the disposition's process.

Near-findings considered and dismissed as non-substantive: the narrow decision key's positive purpose list is defined by section 1's table plus negative constraints rather than an enumerated list (determinate when read together); the recapture acceptance bullet compresses the trigger conditions defined normatively in section 17 (out of this pass's scope); largest-coverage contract selection preferring an older above-floor version is documented, tested intent, not a weakening.

Conclusion

NO SUBSTANTIVE FINDINGS

Round 9 review — GLM identity pass, sections 1–4 (revision 15)

Scope reviewed: Sections 1 (Product contract), 2 (Scope and threat model), 3 (Components), 4 (Borrowing from Flux), checked against the round-8 disposition and binding UX constraints.

Checks performed:

• Biometric matrix vs. binding UX (§1): Allow-once/deny-once/cancel require no biometrics; every reusable rule (session, timed, Forever, create/change/remove) requires one biometric; command/1Password/credential release require one. No double-biometric, downgrade-to-Once, or rule-without-biometric path exists in the text. Consistent.
• Threat model vs. component boundaries (§2/§3): The malicious unprivileged requesting process is addressed at every boundary it touches: live code-identity validation per privileged XPC request, caller UID capture, root-owned placements that resist same-user replacement (including the "older signed authority" rollback case from Opus 2, present as required), command frontend signature explicitly not treated as consent, and adapter provenance attestation without claiming atomicity of Accessibility observations. Consistent.
• Disposition corrections: Opus 2's activation/launch anti-rollback language is present in §3. Opus 1 (floors) and Opus 3 (auto-recapture) live in out-of-scope sections; nothing in §1–4 contradicts them, and §1's "one explicit decision authorizes one captured action" is compatible with recapture-as-new-request.
• Key custody (§3): Transport/authority/credential-receiving key separation is coherent; the dedicated-account fallback is correctly limited to transport-only keys; the blocker-and-consult path honors the UX consultation rules and does not force GUI login, physical access, or re-pairing.
• UX regression scan: No added confirmations, shortened windows, forced re-enrollment, or restricted commands were introduced by the revision-15 corrections within these sections.
• Flux reuse (§4): No-license status correctly yields design-reference-only reuse with independent implementation; no Linux-specific assumptions imported.

No substantive actionable defects found in the reviewed sections.

NO SUBSTANTIVE FINDINGS

Round 9 review — sections 1, 2, 17 (+ cross-context from 6, 9, 12, 13)

Input: revision 15 excerpts as provided. Static plan review only; no runtime claims.

Round-8 correction verification

All three accepted corrections from reviews/round-8-disposition.md are present and correctly scoped in the current text:

• Opus 1 (floor timing): Floors are "proposed" during staging/waiting; commit occurs in one durable transaction with the manifest only after old roles quiesce and replacements pass checks; admission stays closed after interrupted activation until a complete compatible set validates; early enforcement remains consultation-gated. ✔
• Opus 2 (rollback): Anti-rollback protection is required independently of the candidate root binary via a trusted installation/placement boundary; the authority's self-check is explicitly defense in depth; backup restoration cannot lower floors, ledger, or trust. ✔
• Opus 3 (stranded UI requests): Auto-recapture is limited to never-consumed identities, preserves age/deadline, requires a fresh challenge and fresh decision, and explicitly excludes denials/cancellations, consumed/unknown actions, expired targets, and changed dialogs. It creates a new request only. ✔

Consistency checks performed

• Binding UX: Biometric table matches the confirmed contract exactly — one biometric for commands/1Password/credential release and every rule-setting decision (including session/timed and default Forever); no biometric for dismiss/decline, cancel, LS allow-once/deny-once. Update-scheduling controls carry no biometric but are purpose-bound (update ID, generation, challenge, one-use) and cannot alter floors or authorize target actions — consistent with section 2's "what a signature proves" and not an added confirmation. No forced physical access, re-pairing, command termination, or shortened windows anywhere in scope.
• Restart/replacement matrix: Rows agree with section 6 cross-context (in-memory payloads, cancel-on-root-restart, unknown-after-consumption, permit invalidation before reissue) and with section 12's atomic consumption ledger, which is what makes "established as never consumed" decidable; the uncertain case falls back to Unknown plus user-initiated recovery.
• Quiescence/atomicity: The quiescence check closes admission atomically with request creation and permit dispatch, so no request or permit can slip into the replacement window; racing requests get a retryable Update installing. Long-lived commands defer activation without termination or imposed deadlines.
• Identity/floors: Per-request generation enforcement on privileged XPC, OS-validated (not peer-supplied) build identity, generation-bound adapter certifications, receiving-key generation boundary, floors committed only via the activation transaction, and downgrade rejection with only an explicit authenticated administrative exception — internally consistent; hash-pinning is correctly avoided in favor of signing requirements plus generations.
• Cross-section rules: No replay of decisions (late approvals stale; refresh issues a new challenge), no Once/rule silent fallbacks, consumption persisted before side effects, terminal-status distinctions preserved. Recapture/refresh paths align with section 9 revalidation and section 13 age/deadline preservation.

No contradiction, authorization gap, replay path, UX regression, or unbounded downgrade/recovery path found in the reviewed text.

NO SUBSTANTIVE FINDINGS

Independent plan review — revision 15

Scope assessed

I reviewed the complete plan, with focus on the post-revision-5 additions and their interaction with earlier invariants:

• Audit (§12) vs. data minimization (§6): exclusions for journal, cache, exports, and diagnostics are consistent; consumption+audit commit in one transaction; unknown outcomes can't be rewritten as success; revoked-phone offline cache limitation is explicitly documented rather than papered over.
• Expiry/timing (§13) vs. capture and UI revalidation (§6, §9): two-clock model is coherent; monotonic-with-sleep expiry on the Mac, labeled estimates on the phone, revalidation before dispatch even during an open biometric prompt, and no authority revival from refresh or elapsed estimates. The three disappearance cases (observed timeout / unknown disappearance / post-dispatch) are correctly kept distinct.
• Presence routing (§14) vs. consent model (§1, §6): routing affects delivery only; manual overrides grant no authority; local-kept requests expire without leaking stale approvals; handoff preserves age/deadline/identity; the local-command approval surface is a defined feasibility gate with an explicit interim caller-visible behavior, not an unplanned gap.
• Push/relay (§15, §16) vs. trust boundary (§2, §3): opaque wake identifiers, fetch-after-wake with pinned identities, no plaintext to gateway/relay, revocation enforced at the Mac before Access revocation completes, token-as-metadata only, dedupe by request identity. Downgrade resistance in §18 (authenticated transcript, no retry to older format after signature failure, floors immune to negotiation) closes the relay downgrade path.
• Updates/identity (§17) vs. root-authority invariants (§3, §6): the round-8 corrections are properly integrated — floors are proposed until quiescence + checks, then committed in one durable transaction; anti-rollback is enforced at an activation/placement boundary independent of the candidate binary, with the authority's self-check explicitly demoted to defense-in-depth; backup restoration cannot lower floors/ledger; the restart matrix composes with §6 crash rules, and automatic recapture is correctly restricted to never-consumed requests with fresh challenge and fresh consent (no consent reuse).
• Protocol evolution (§18) vs. multi-phone consumption (§5, §6): one immutable request + one ledger; per-phone contract filtering; no re-encoding to weaker schemas; envelope and request contracts verified separately with domain separation. The v1/v1+v2 selection rule (largest eligible set, ties to highest version) is consistent with the acceptance cases.
• Key separation (§6, §7): decision key purposes remain narrow; update-scheduling (§17) is a separate purpose that cannot supply artifacts, alter floors, or authorize target actions, and its worst-case misuse (initiating a drain) is visible and reversible — acceptable under the trusted-unlocked-phone assumption already adopted for allow-once.
• UX preservation: no new biometrics, confirmations, shortened windows, command restrictions, or forced re-pairing were found introduced; deferred preferences (idle interval, retention duration, 1Password lifetime estimate) are explicitly user decisions, so per the review instructions they are not findings.

Remaining tentative UX choices (explicitly deferred, not defects)

Automatic idle interval (§14, 30s draft), audit retention duration/budget (§12), sudoers compatibility policy selection (§8), biometric-invalidation key policy (§5/§7), and the executable-race guarantee options (§8) all have defined evidence + consultation paths.

Implementation verification limits

This review cannot validate the feasibility gates themselves: protected placement/anti-rollback enforcement on macOS 14+, single-biometric credential release, secure-field targeting, Little Snitch one-time effect semantics, pre-login key custody, background Access auth, and real-device delivery latency. Convergence here means planning coherence, not platform proof — consistent with §11's own definition.

Conclusion

NO SUBSTANTIVE FINDINGS

The post-revision-5 additions are internally consistent with the earlier security invariants; downgrade, replay, rollback, and cross-component race paths appear closed at the planning level; the confirmed biometric exceptions remain narrowly scoped to Little Snitch one-time effects with dual verification; relay/gateway compromise is bounded to delay/metadata; and all three adapters remain in scope with unambiguous failure/consultation paths where feasibility is unproven.

Remozio plan review: revision 15

Scope: complete plan text, plus the round-8 disposition. This is a plan-only review. I ran no tests, browsed nothing, and inspected no source.

The revision 15 fixes are directionally sound: floors stay proposed until activation, root anti-rollback no longer relies on the candidate's own checks, and UI prompts are recaptured only when never consumed.

Three findings remain. All are low severity, and none of the corrections worsens UX.

Findings

1. Low: custody of tunnel and push-gateway credentials is unspecified

Sections: §3 "Key custody and pre-login transport"; §16 "Cloudflare Tunnel endpoint" and "Keep push separate from the live proxy"; §15 "Required notification service".

The custody rule covers only transport keys: dedicated-account-private storage, and no interactive account can read them.

Two other Mac credentials have no custody rule:

• the cloudflared tunnel credential ("stay on the Mac")
• the Mac's push-gateway submission credential

§16 also does not say which account runs cloudflared.

Failure scenario:

• A malicious same-user process, which is in scope, reads the tunnel credential.
• It runs rogue connectors off-machine. The edge can route phone connections to them.
• End-to-end payload encryption and pinned identities still prevent forgery or disclosure.
• However, the attacker gains durable relay-position metadata and can intermittently black-hole remote approvals.
• This persists after the local malware is removed, until someone rotates the credential.
• A stolen push credential similarly permits wake/notification spam to enrolled phones.

These are availability and metadata effects only, not authority. They are still a concrete custody gap against an in-scope attacker, and a persistent one.

Minimal correction:

• Apply the transport-key custody rule to both credentials, including the same-user isolation validation.
• Run cloudflared under the dedicated transport account.
• Specify rotation and revocation for both credentials in repair and uninstall.
• Add a same-user read-attempt acceptance case in §16.

2. Low: on-disk bundle replacement versus process activation is undefined

Sections: §17 "Automatic activation and optional drain"; §17 "Sparkle release delivery"; §3 live identity validation; §18 acceptance item "Attempt app-only replacement during a live adapter permit. Defer relaunch…".

The plan requires two things:

• live code-identity validation on every privileged XPC request
• quiescence for every component "replaced or terminated"

The §18 acceptance item, however, implies the app bundle may be replaced on disk while an old GUI adapter keeps running, with only the relaunch deferred.

The plan does not say whether on-disk replacement of a bundle containing a running role counts as replacement. That covers the adapter, and the helper if it is bundled.

Failure scenario:

• A Sparkle app-bundle install lands during a 1Password unlock permit.
• The running old adapter's later RPCs (credential reception, permit acknowledgment) are checked against changed on-disk code.
• Depending on actual platform behavior, which I am not asserting, validation may fail. The result is an Unknown outcome that the drain design was meant to prevent.
• Alternatively, validation may pass against code that no longer matches the persisted role identity.

Minimal correction:

• Define on-disk replacement of any bundle containing a running role as part of activation, subject to the same quiescence rule. Sparkle's install step is deferred, not just the relaunch.
• Alternatively, add "live validation of a still-running process after on-disk replacement" to the §17 update-continuity feasibility gate, with defined behavior on failure.
• Reword the §18 acceptance item accordingly.

3. Low (remote-coding UX): command submissions are not retried at the update boundary

Sections: §17 "Automatic activation and optional drain" and "State across restarts"; §8 "Process I/O and terminal outcomes".

UI captures rejected with Update installing are retried automatically. Commands only receive a "retryable" nonzero status.

Failure scenario:

• An unattended coding agent issues remozio sudo -- … at the brief replacement boundary.
• It gets a nonzero exit and likely treats it as a failure.
• The remote session stalls or takes a wrong branch, for no reason the user chose.

Minimal correction:

• Have the frontend transparently wait through the bounded Update installing window, showing status, then resubmit.
• This is safe because nothing was captured, approved, or consumed.
• Resubmission gets fresh capture, a fresh caller-identity check, and a fresh decision.
• The frontend returns the distinct status only if the window is exceeded.

This correction improves UX and needs no consultation.

Assessed, no finding

• Scope and keys: scope classification and key separation for the one-time controls and the update-scheduling purpose.
• Relay: resistance to relay compromise.
• Negotiation: downgrade and replay protection, including one immutable contract per request and no re-encoding.
• Floors and rollback: floor commit timing versus drain, and root anti-rollback independent of the candidate binary. Both are contingent on the §3/§17 placement gate and its consultation path.
• Restarts: the restart matrix, and recapture limited to never-consumed requests.
• Routing: presence routing, which is delivery-only.
• Audit: transaction atomicity and secret exclusions.
• Deferred items: the pending idle-interval and retention preferences, and the interim local-command routing state. The last is explicitly gated in §14.

Remaining verification limits

Several properties depend on scheduled feasibility evidence:

• protected placement and anti-rollback enforcement
• per-generation isolation of receiving keys
• single-biometric credential release
• AX control/effect association for Little Snitch and 1Password
• descriptor-based execution
• Access background authentication
• Android key persistence across biometric changes

SUBSTANTIVE FINDINGS REMAIN

Round 8 disposition

Input: revision 14, SHA-256 78cd50f57f8c8962efa714b4ee92a5e04bce047271ea7ea43164fc635d1e28d3.

K3 completed a full-plan review with no substantive findings. GLM completed seven overlapping scoped reviews with no substantive findings, covering all 18 sections. All eight runs have exit 0, nonempty final reports, and preserved input evidence. Opus completed with three findings.

Corrections in revision 15

Section 11 now names all three requested reviewers and explains scoped evidence after provider output-limit failures. Readability subheadings were added without removing requirements.

No forced update deadline, command termination, new biometric, shorter approval window, or forced re-pairing was adopted. Automatic recapture creates a new request only; it never reuses consent or dispatches an action.

Next pass

K3 and Opus inspect the complete revision 15. GLM re-reviews changed sections and their affected interactions. Prior GLM reports can cover only text proven unchanged by exact comparison; the coverage record will identify every source report and section.

Round 8 GLM scoped review — sections 1, 2, 5, 6, 7 (revision 14)

Checks performed

• Biometric matrix consistency (§1 vs §6, §7): Every reusable-rule decision (Forever, session, timed) requires the biometric key; allow-once/deny-once/target-cancel/decline are confined to the narrow decision key. §6 enforcement ("both verifiers derive the required key class from retained action semantics") closes the caller-relabeling and phone-self-assertion paths. Internally consistent.
• Binding UX constraints: One biometric per protected action; §7's one-biometric feasibility gate has an explicit consultation path if a second prompt or weaker protection would be needed. No lock-screen approval surface or extra unlock step is introduced. Remote administrator enrollment/recovery avoids forced physical access; pairing retention across biometric changes is preserved with a defined gate rather than mandated re-pairing. The five-minute expiry is provisional, adjustable, with explicit resubmission — not a forced shortened window.
• Multi-phone races and revocation: First-valid-decision consumption at the Mac ledger, single-use signatures, revocation serialized with decision consumption, and stale-result returns close replay and late-winner paths across §5/§6.
• Round-7 fix interactions: The section 17 update-scheduling controls referenced from §6 are expressly denied target-action and release-signing authority and do not widen the decision key's deny list; no conflict with the no-auto-retry or unknown-terminal rules in §6.
• Encoding and display: Digest recomputation on Android, distinct "Request too large" result, and no-truncation at any stage are consistent between §1 and §6.
• Cancellation authority: Verified-IPC caller identity, purpose-separated cancellation, ledger requirement for target-app effects, and the no-remaining-approval-surface cancellation rule are consistent across §5 and §6.
• Crash/uncertain handling: Consumption-before-side-effect persistence, bounded dispatch permits, no automatic retry, and user-initiated Refresh form a closed loop.

No internal contradiction, authority gap, or binding-UX violation found within the reviewed sections.

NO SUBSTANTIVE FINDINGS

Round 8 review — GLM scoped pass (sections 1, 2, 6, 18)

Revision 14 excerpts reviewed as provided. Static review only; no runtime verification claimed.

Checks performed

• §1 biometric table vs §6 key classes. The narrow decision key's permitted purposes (one-time UI decisions, request cancellation) exactly cover the four no-biometric rows; its explicit denials (rule changes, command execution, 1Password, credential release, enrollment) match the biometric-required rows, including Deny Forever and temporary/session rules. No mismatch or bypass path in the excerpts.
• §6 scope enforcement. Both verifiers derive the key class from retained action semantics rather than message-asserted purpose, and classification never trusts caller labels — the malicious-unprivileged-caller threat in §2 is answered consistently (adapter-asserted UI details, verified IPC identity for caller cancellation).
• Digest and replay. Android-side digest recomputation, single-use signatures, consumption-before-side-effect persistence, and first-valid-decision-wins ledger close the replay/stale-dialog vectors named in §2 without adding confirmations or shortening response windows.
• Crash/unknown handling. Permit invalidation, no automatic retry, user-initiated Refresh, and unknown-as-terminal are mutually consistent and do not force repeated enrollment or extra biometrics.
• §18 negotiation. Authenticated transcript binding, per-request exact contract binding, floor persistence independent of binaries, no relay version trust, and no re-encoding to weaker schemas leave no silent-downgrade path found. The v1/v2 selection rule and its acceptance test are consistent with the binding UX (incompatible phone shows reason + Update; no re-pairing).
• Cross-references. §6↔§18 (canonical encoding, evolution), §6↔§17 (restart matrix, update scheduling), and the three round-7 corrections (idle-drain activation, minimum security generations, adapter-deferred relaunch) are reflected consistently in these sections.

No correction identified that would worsen UX.

NO SUBSTANTIVE FINDINGS

Round 8 — GLM scoped delivery pass (sections 1, 2, 15, 16)

Input: revision 14 excerpts as provided. Prior disposition (round 7) reviewed; its corrections (idle-before-drain, minimum-generation checks, update quiescence) live in sections outside this scope and are not contradicted here. Section 1's consultation clause correctly codifies the round-7 no-UX-regression guarantees, including the feasibility-gate carve-out.

Checks performed:

• Biometric contract (§1): Table is internally consistent and matches binding UX — command/1Password/credential-release require one biometric; Little Snitch once/cancel/dismiss require none; every reusable rule (Forever, session, timed, create/change/remove) requires biometrics. "One explicit decision authorizes one captured action" and "signing only for the displayed request" are consistent with §15 first-valid-decision consumption and §2 signature semantics. Declining without a target action granting nothing is correctly non-sensitive.
• Threat model (§2): Trusted-phone assumption explicitly covers non-biometric decisions; unprivileged relay cannot mint approvals; keys in root storage; signature scope (invocation, not transitive effects) is honestly bounded. Residual risks (Accessibility bypass, GUI scripting) are documented with consultation required before revoking grants.
• Push delivery (§15): Token/identity binding, revocation semantics (stale pushes cannot revive authority), opaque payloads, fetch-before-present, notification ≠ consent, and delivery-health staging are mutually consistent. Request lifetime bounded by validity and known deadlines only; the 1Password estimate stays display guidance — no tension. Uncertain external actions are never retried for delivery, consistent with the round-7 posture.
• Transport (§16): Discovery-is-not-identity, bounded direct-connect attempt against short 1Password windows, single request ID/expiry/consumption across parallel paths, Tunnel-as-live-proxy, Access as additional (never substitutive) gate, per-installation service credentials with no shared APK secret, and Remozio-level revocation winning over pending Access revocation are all coherent with §15. No forced browser login on the approval path; recurring renewal cost requires user consultation, so no forced re-pairing or physical access is introduced. Gateway/relay separation and Mac-authoritative validity/consumption hold across both sections.
• Cross-section: §2 deployment scope, §15 fetch paths, and §16 transport selection agree (LAN-then-relay, no VPN, push baseline, dedup across paths).

No correction identified that would worsen UX.

NO SUBSTANTIVE FINDINGS

GLM execution pass — revision 14, scope: sections 1, 2, 8, 9, 10, 11

Checks performed

Biometric policy consistency (1 ↔ 9 ↔ 10). The section 1 table matches section 9's effect-based classification: deny-once/allow-once/cancel are biometric-free only when the actual effect is confined to the captured request; session, timed, and Forever rules require biometrics at both verifiers regardless of button label. "Do not silently select Once" plus "reflect existing dialog defaults initially" keeps the default-Forever path intact without forcing re-authentication. Unknown versions/structures cannot inherit one-time classification. No contradiction with the binding UX.

Command execution (8). Capture-before-approval, deterministic environment with explicit additions, direct argv execution with -c scripts preserved as arguments, and the caller-lifetime semantics are internally consistent: "requester exited before execution" is claimed only when no child started; post-start exit follows the started-command lifetime policy; distinct nonzero statuses cover denied/stale/unavailable/oversized/exited outcomes and match the section 10 acceptance items. Race limitations (path-execution, mutable scripts, liveness) are documented as measured gates rather than overclaimed guarantees.

UI adapters (9). The one-permit scope-mutation attempt (consume before mutation, unknown on later failure, no auto-retry or restore), refresh without replaying biometrics or notifications, deadline semantics (changed deadline/default is semantic; passage of time is not), observed-timeout vs unknown-disappearance reporting, secure-field targeting with a stop-and-consult fallback, and revalidation before every external click including Deny/Cancel are mutually consistent and consistent with section 1's "declining performs no target-app click".

Threat model (2). Unprivileged relay, root-held keys, independent signature validation, signed-adapter assertions, and documented limitations (transitive effects, accessibility-capable callers, GUI-scripting exposure) align with the verification model; no feasibility is claimed as proven.

Acceptance gates (10). Spot-checked each gate against normative text in 1, 2, 8, 9: authority/enrollment, scope/biometrics, lifetime/concurrency, capture/UI integrity, and platform operation items each trace to a stated requirement, an explicit feasibility gate, or a planned measurement. "Request too large without truncation" is an explicit rejection, not silent truncation, satisfying section 1.

UX constraints. No added confirmations, no forced physical access or re-pairing, one biometric for protected actions, and no correction is proposed that would worsen UX.

Prior disposition. Round-7 corrections (idle-drain scheduling, minimum signed generation, adapter-update quiescence) concern sections outside this scope; nothing in the scoped text contradicts them.

Conclusion

NO SUBSTANTIVE FINDINGS

Round 8 GLM scoped review — history/expiry/routing

Scope: Sections 1, 2, 12, 13, 14 of revision 14, as excerpted. Text-only review; no runtime claims.

Checks performed:

• Biometric contract (§1) vs binding UX: matrix matches exactly — one strong biometric for command/1Password/credential actions; LS allow-once/deny-once/cancel exempt; every reusable rule (session, timed, Forever default) requires biometrics; Forever default preserved without silently downgrading to Once. No double-biometric, forced re-pairing, or physical-access requirement appears in §13/§14 (biometric-in-progress is not invalidated by presence changes; revalidation before dispatch checks dialog/deadline, not a second biometric).
• §12 internal consistency: consumption + audit commit is one transaction with a no-dispatch failure path; audit state derived from the consumption ledger (no second execution authority); unknown outcomes never rendered as success. Sensitive-data exclusions do not conflict with §1's full-detail display requirement — pending payloads are memory-only, and the detail view discloses non-retention. Revoked-phone sync cutoff and offline-cache limits are stated honestly. Retention is decoupled from the ledger and trust records.
• §13 internal consistency: age anchored to adapter first observation; estimate, observed timeout, and disappearance kept distinct; authority stays with the Mac's monotonic deadline; terminal requests lose approval controls; refresh only recreates a challenge when the dialog survives; late biometric results cannot revive authority. Consistent with §12 unknown-outcome rules.
• §14 internal consistency: routing is delivery-only and never grants authorization; locked/dark overrides activity; unknown brightness is not treated as dark; degraded-detector fallback routes to phone with a label (delivery-only, biometrics still gate action); handoff preserves identity, age, deadline, and single consumption; coarse audit reasons respect §12 exclusions. The local-command feasibility gate is properly framed as planned work with an interim caller obligation, not missing planning.

Findings: none. No contradiction, authorization gap, or UX regression found within the reviewed sections.

NO SUBSTANTIVE FINDINGS

Round 8 GLM scoped review — sections 1–4, revision 14

Scope: Product contract; Scope and threat model; Components; Borrowing from Flux. Prior disposition (round 7, Opus findings) reviewed; those corrections concern update/activation behavior located in sections outside this pass and are not contradicted by the text reviewed here.

Checks performed:

• Binding UX contract. The biometrics table matches every binding constraint: single biometric for protected actions; cancel/deny-once/allow-once exempt; every reusable rule (Forever default, session/timed rules, create/change/remove) requires biometrics; "Do not silently select Once to avoid authentication" prevents auth-avoidance drift; no physical proximity or re-pairing is introduced (section 2 explicitly forbids proximity requirements after enrollment).
• Internal consistency, sections 2 vs 3. Relay limits (delay/drop/metadata only), root-signed protocol objects, one-time dispatch permits, consumption ledger, and E2E payload encryption coherently back the section 2 claims of tamper/replay/stale-dialog protection. The acknowledged non-atomicity of Accessibility observations is an honest documented residual, not a contradiction of stale-dialog protection (which is against replaying approvals onto new dialogs).
• Key custody. Transport/authority/adapter key separation is maintained; the pre-login fallback is correctly scoped to transport-only keys and explicitly excluded for credential-receiving and authority keys; "administrator-controlled" inherits the strict root-owned, non-user-writable definition established earlier in section 3; both failure paths end in a blocker plus user consultation rather than silent GUI-login dependence or key exposure.
• Process boundaries. Audit-token/code-signing validation per privileged XPC request, hardened runtime without exceptions, untrusted-same-user invocation of the command frontend, and enrolled-account-only policy close the confused-deputy and same-user injection paths within the stated assumptions.
• Flux borrowing. No-license status correctly forces design-only reference with independent implementation; Linux-specific PAM/socket behavior excluded; hardware attestation honestly not promised in v1, with software-keystore/biometric-fallback/recovery changes routed to user decision.

No defect found that has a concrete failure mode and a minimal correction without UX harm.

NO SUBSTANTIVE FINDINGS

Scoped review: sections 1, 2, 3, 17 (revision 14)

Round-7 corrections verified present

• Opus 1 (drain freeze): Automatic activation begins only when already quiescent; otherwise "Update ready" with continued admission. Drain is optional, explicit, and cancelable/deferrable from both Mac and phone; long-lived commands defer activation indefinitely; no forced deadline or new response limit. Consistent throughout.
• Opus 2 (old signed peers): Every privileged RPC enforces a persisted, authenticated minimum generation from OS-validated signed metadata; certs and receiving keys bind to that generation; access-group membership alone is insufficient; failure raises a key-custody gate with a consult path, not a silent weakening.
• Opus 3 (adapter termination): Quiescence applies to every replaced component including a bundled GUI adapter; a bounded attempt that cannot reach quiescence defers rather than kills; update-caused interruptions are audited with unknown outcomes recorded.

Independent checks

• Binding UX: Biometric table matches the contract exactly — one biometric for command approval, 1Password unlock/access, credential release, and every rule-setting decision (create/change/remove, session/timed, default Forever); none for allow-once/deny-once/cancel/dismiss. Forever default preserved. Pairing, device keys, and preferences survive updates; consultation is required before any path adding prompts, physical access, or re-pairing. Phone update-scheduling controls use the existing decision key with no extra biometric and no added confirmation dialog, and can only schedule an already-verified release — no UX regression.
• Consistency: Admission closes atomically with request creation and permit dispatch, with a retryable "Update installing" result for races; the drain continues existing requests, expiry, command I/O, and permit completion, so no approval is silently discarded. Restart matrix is consistent with never-redispatch, permit invalidation on lost acknowledgment, and no resurrection of consumed requests. Pre-login transport fallback is transport-key-only and explicitly excluded for credential-receiving and authority keys. The relay cannot mint approvals; E2E payload encryption bounds relay exposure. "Administrator-controlled" placement follows section 3's strict root-owned/non-user-writable definition. Both feasibility gates (service installation, update continuity) define required evidence and failure/consultation paths.
• Terminology edge cases examined and found reconcilable: the bounded automatic activation wait versus indefinite explicit-drain deferral (both resolve to "defer, never kill"); floor-raising versus certification refresh ("current peers" are those meeting the new floor); per-request adapter-key certification with account/session/incarnation binding.

No internal contradictions or actionable defects found in the scoped sections.

NO SUBSTANTIVE FINDINGS

Independent review — Remozio plan, revision 14

Scope: full plan, sections 1–18, including post-revision-5 additions (audit, expiry, presence routing, push, LAN/relay, component identity, Sparkle updates, protocol evolution). Plan-only assessment; no testing, browsing, or source inspection performed or claimed.

Assessment summary

I specifically hunted for the defect classes the brief calls out, and found the plan internally consistent on each:

Cross-invariant contradictions. Checked the new sections against earlier invariants:

• Audit (§12) vs payload minimization (§6): pending sensitive payloads stay memory-only; journal/cache exclusion list is complete and consistent; the detail view explicitly discloses non-retention.
• Routing (§14) vs delivery (§5, §15): §5's "deliver to every authorized phone" is correctly conditioned on phone routing; handoff preserves identity/age/deadline; locked/dark overrides activity timestamps; fail-to-phone on detector loss is delivery-only, not authority.
• Expiry (§13) vs state machine (§6): estimate vs observed timeout vs disappearance are kept distinct; disappearance-after-dispatch correctly falls under confirmed-result/unknown rules, not expiry.
• Updates (§17) vs permit/crash rules (§6, §9): quiescence covers pending requests, active commands, and live permits including the bundled GUI adapter; the restart matrix aligns with §6's crash rules; "old authority owns I/O until commands finish" is consistent with drain-then-activate.

Downgrade/replay. §18 binds both capability advertisements, nonces, and selection into an authenticated transcript; forbids re-encoding a request into a weaker schema; rejects replayed older policy; separates envelope version from request contract. §17's per-RPC minimum security generation bound to OS-validated signed metadata (not peer-supplied strings), generation-bound key certification, and the explicit key-custody gate for old signed builds close the round-7 gap. Contract selection ("largest eligible phone set, ties to highest") cannot go below the floor and uses authenticated capability records, so a relay cannot influence it.

Privileged update path. The rev-14 fixes (automatic activation only at quiescence, optional explicit drain, narrow decision-key scheduling with no target-action authority, bounded adapter wait instead of kill) resolve the round-7 findings without adding confirmations or biometrics. Staging/symlink/registration race tests are specified; scheduling controls are challenge-bound, single-use, and serialized with activation.

Scope classification and key separation. Decision-key purposes are enumerated and the exclusion list (commands, 1Password, credentials, enrollment, rule changes including temporary/session) is enforced at both verifiers from retained semantics, not caller/phone labels. Update-scheduling authority is explicitly excluded from target-action and release-signing authority. The confirmed Little Snitch allow-once exception is not widened.

Relay resistance. End-to-end payload encryption between root authority and phone; opaque push payloads; Access as transport-only gate; push tokens carry no authority; revoked phones rejected by the Mac independent of Access revocation timing.

UX preservation. No new biometric prompts, confirmations, response-window shortening, or command restrictions were introduced in the reviewed deltas. Deferred items (idle interval, retention duration, sudoers policy choice, atomic-execution semantics, local command approval surface, biometric-invalidation policy, Access credential renewal, forced-update deadline) are all recorded as pending user decisions or feasibility gates with consultation paths — per the brief, these are planned work, not defects.

Tentative UX choices noted (not defects)

• 30s draft idle threshold vs ~60s 1Password prompt: the plan correctly refuses to extend the target window and defers the interval to the user, but the tension should be measured in feasibility.
• Biometric-free update scheduling via decision key (§17): consistent with the threat model and reversible (cancel-drain), but it is a new remote control surface worth explicit user awareness during implementation review.
• §11's review protocol names two reviewers while the round-7 disposition adds GLM as a third; a process note only.

Remaining verification limits

This review does not establish platform feasibility: the macOS 14 floor, 1Password/Little Snitch AX contracts, service-management protected placement, old-build key-custody isolation, single-biometric credential operation, background Access authentication, and descriptor-based execution are all unproven gates with defined failure/consultation paths. No implementation exists to audit; convergence here means no unresolved planning defects, not security assurance.

Verdict

NO SUBSTANTIVE FINDINGS

Remozio plan review: revision 14

I reviewed the complete revision 14 against its own invariants and the round-7 disposition. I focused on the post-revision-5 additions (sections 12–18), especially the new update, security-generation and scheduling material in section 17. I checked how it interacts with the section 3 placement rules, the section 6 restart rules and the section 9 UI refresh rules. This is a document review only; nothing was tested or inspected.

Findings

1. Medium: the plan never says when a raised security floor takes effect

Where: §17 "What each signature proves", §17 "Activate a compatible component set", §18 "Compatible additions and breaking changes".

Conflict: Each privileged XPC request is checked against a persisted minimum generation, and floors can come from "authenticated release policy" (§18). The plan does not say when a new floor becomes enforced. §17 also contemplates that "a mandatory security floor disables the old stack". Both conflict with:

• "keep the existing compatible stack working while downloading and staging";
• keeping the old GUI adapter alive "while its requests or permits need it".

Failure scenario:

1. A security release is staged, or the root authority is activated before the app-bundled adapter.
2. The new floor is persisted and applies to the adapter role.
3. The still-running old adapter's completion acknowledgment, or permit request, fails the generation check.
4. The live permit becomes Unknown (§6), and pending UI approvals stop working.

This happens without any forced-update decision by the user. That is the silent loss of remote functionality the plan forbids.

Minimal correction:

• A role's new floor is persisted only after a replacement build for that role has activated and passed the post-activation checks.
• The floor applies only after the old instance of that role has quiesced.
• Before then, a release-announced floor is shown as "security update ready/blocked by …", not enforced.
• Enforcing a floor early remains the already-noted forced-update policy that requires user consultation.

This correction does not worsen UX. Enforcing floors at staging time would.

2. Medium: root-code rollback to an older signed build is not covered

Where: §3 "Authenticate local process boundaries", §17 "Sparkle release delivery", §17 "Feasibility gate: remote update continuity", §18 floors.

Gap: §3 accepts "equivalent platform launch-time signature enforcement" in place of root-owned placement. The generation check is enforced by the root authority on its peers. Nothing checks the root authority's own generation, or stops an older validly signed build from being staged or activated.

Failure scenario:

1. The placement gate passes on signature enforcement alone, for example an app-bundle service registration.
2. A same-user process, or a compromised feed host serving an old EdDSA-signed archive, substitutes a correctly signed older app or helper.
3. launchd accepts it because the signature is valid.
4. Root now runs old vulnerable code, which is also the component expected to enforce the floors.

Sparkle's version ordering does not cover out-of-band substitution. The §18 acceptance list tests old signed helpers as peers, not the authority itself.

Minimal correction:

• Define "equivalent enforcement" as signature validity plus anti-rollback.
• The activation path checks every candidate role's signed generation against the persisted floors and the currently installed generation. It rejects downgrades except through the explicit administrative recovery already mentioned in §18.
• At startup, the root authority checks its own OS-validated generation against the persisted floor and refuses authority operations if it is below it.
• Add an acceptance case: replace the root helper with an older signed build.

No UX cost.

3. Low: UI dialogs can be silently stranded across a root-authority replacement or restart

Where: §17 activation ("Requests racing the brief replacement boundary receive an explicit retryable Update installing result"), §17 restart matrix ("Unexpected root-authority restart: Cancel unconsumed requests … explain fresh submission"), §9 "Compatibility and unsupported dialogs" / §13 "Refresh versus a new original operation".

Gap: For commands, the caller receives a retryable status. For UI requests, the "caller" is the adapter, and no rule tells it to resubmit. Refresh is user-initiated and defined only for expired requests.

Failure scenario:

1. A 1Password prompt appears during the replacement boundary, or remains after an unexpected root restart.
2. Its request is refused or cancelled.
3. No phone notification is produced, and the roughly 60-second prompt times out while the user is away.
4. The user is told to "submit fresh", but no submission surface exists for them.

Minimal correction:

• After Update installing, or after a root restart, the adapter automatically recaptures still-present dialogs as new requests.
• New requests get fresh challenges, preserved first-seen age and target deadline, and no carried-over authority.
• Otherwise the adapter reports disappearance per §13.

This does not worsen UX.

Round-7 disposition

The accepted Opus 1 and Opus 3 fixes are consistent with the §6 restart rules and the §14 routing rules, except for the floor-timing interaction in Finding 1.

The Opus 2 fix is correct in intent. It is incomplete for the root authority itself (Finding 2).

The receiving-key isolation requirement is a defined gate with a consultation path, not a defect. However, it may be stricter than needed if credential ciphertext only ever arrives over generation-checked XPC. The gate evidence could evaluate that alternative before declaring failure.

Assessed without findings

• Scope and key separation:
  • the section 1 action/scope table;
  • decision-key limits, including the new update-scheduling purpose;
  • status-versus-approval domain separation;
  • relay and gateway exclusion from authority;
  • the per-request Little Snitch "current request" definition.
• Protocol: negotiation transcript binding, and contract selection limited by the floor and features without re-encoding.
• Other boundaries:
  • multi-phone first-valid consumption;
  • audit atomicity and exclusions;
  • two-clock expiry;
  • presence routing as delivery-only;
  • push token handling;
  • Cloudflare Access as a transport-only gate.
• Deferred items: pending UX preferences (idle interval, retention) and feasibility gates (placement, single biometric, sudoers, local command approval, Access auth, AX fixtures) are correctly deferred.

Implementation must still demonstrate all gate evidence, particularly the §3 and §17 placement and rollback proofs.

SUBSTANTIVE FINDINGS REMAIN

Round 7 disposition

Input: revision 13, SHA-256 a64acad6b8acbac1118ca71a6e6c7030d9cb0afb3fda0a111b815ba229c9d63d.

K3 completed with no substantive findings. Opus completed with three findings. GLM's authority pass completed with no substantive findings; execution and delivery passes exhausted their output limits without final reports. All returned process exit 0, so report content and stop reasons determine success separately. No complete GLM assessment is claimed.

Corrections in revision 14

The automatic path adds no new approval step. No forced cancellation, reduced response window, extra biometric, or recurring re-pairing was introduced. A forced security-update deadline remains a user decision if ever proposed.

Next assessment

K3 and Opus review the complete revision 14. GLM keeps the same provider, model, and thinking setting; smaller scoped passes cover every section, with a separate integration pass. Preserve each excerpt and scope alongside its report. Convergence requires nonempty final reports on the same frozen revision, not merely exit 0.

Round 7 review — GLM pass (sections 1–7, 17)

Input: revision 13 excerpts as provided. Checked independently against the binding UX constraints and the round-6 disposition.

Prior-disposition verification

All four round-6 corrections are present in the current text:

• Root-code/registration/staging placement protection with attack tests (§3, "Authenticate local process boundaries") and the protected-placement invariant referenced by §17.
• Update drain, restart matrix, and Unknown-on-lost-acknowledgment semantics (§17 matrix; §6 crash handling); root restart cancels unconsumed memory-only requests; consumed requests are never redispatched.
• Mixed-phone version selection is delegated to §18 (out of this pass's scope; §6's reference is consistent).
• Last-phone revocation keeps requests pending only when a local approval surface is actually implemented; native dialogs keep their own behavior (§5).

Checks performed

• Biometric policy consistency: §1 table, §5 ("session rule or timed rule is reusable and requires biometrics"), and §6 ("Both verifiers enforce scope") agree exactly with the binding UX: one biometric for commands/1Password/credential release/enrollment and every reusable-rule change (including Deny Forever and temporary rules); no biometric for deny-once, allow-once, target cancel, and Remozio-level dismiss. §7's one-biometric credential gate is correctly framed as a spike with a consultation path, not a second-biometric design.
• Narrow decision key: purpose-bound, enrolled per Mac/account tuple, verified end to end by both verifiers, barred from rule changes/commands/1Password/credentials/enrollment; revocation removes both keys; consumption is serialized with revocation. The "allow-once exception" sentence bounds that decision to the captured request and does not conflict with the §1 table, which §6 explicitly makes binding on both verifiers.
• State machine and races: single-use signatures, decision consumption persisted before the side effect, first-valid-decision-wins at the Mac ledger with reconciliation, stale results for late approvals, Unknown terminal and no automatic retry, permit invalidation with user-initiated Refresh only. Internally consistent across §6 and §17.
• Key custody and boundaries: transport keys separate from authority; pre-login fallback restricted to transport-only keys; credential/authority keys excluded from the fallback; adapter keys non-exportable and code-signing restricted; relay sees metadata only under E2E encryption; live audit-token validation per privileged XPC request.
• Updates: drain-before-replacement, no forced cancellation of active commands, security-floor visibility, no rollback below the floor, no resurrection of consumed requests via migration, Sparkle signature verification before extraction, no unsigned fallback.
• Expiry, encoding, display: monotonic-clock expiry on the Mac, distinct "Request too large" result, no truncation anywhere, digest recomputation on Android and at each acting authority.

Near-misses considered and cleared

• "The allow-once exception" phrasing in §6 could be read narrowly, but §6 defers explicitly to the §1 table, so no implementable contradiction or UX regression exists.
• Environment capture is implied by §6's limit derivation and log prohibitions; §1's "full command details" requirement plus the no-truncation rule covers display, and detail-rendering specifics belong to the other passes.
• "Changed LaunchAgent registration" in §3 refers to the credential-receiving GUI adapter, which is distinct from the LaunchDaemon transport; the identity binding prevents either from being substituted.

No correction in this scope would improve security without violating the binding UX, and none of the UX-binding behaviors is contradicted anywhere in the reviewed text.

NO SUBSTANTIVE FINDINGS

Review of revision 13 (complete plan)

I reviewed the full plan, including the post-revision-5 sections (12–18) and the round-6 disposition, checking specifically for contradictions between early invariants and later additions, downgrade/replay gaps, privileged update paths, and remote-UX preservation.

Assessed areas

Cross-section consistency. The new sections hold up against the core invariants:

• Audit (12) vs §6: memory-only pending payloads, journal transaction committed with consumption before dispatch, and metadata-only retention are mutually consistent. The "full request contents were not retained" explanation in history does not conflict with §1's full-command display rule, which applies to active requests.
• Expiry (13) vs §6/§9: target deadline vs Remozio deadline separation, monotonic-clock authority, refresh-creates-fresh-challenge, and revalidation before action compose without contradiction. Refresh preserves age/deadline without reviving expired authority.
• Routing (14) vs §3/§15: requests kept local while active produce no phone pushes; handoff forwards only still-valid requests with original identity/age; presence changes do not invalidate in-flight biometrics; expired local requests never become actionable notifications. The unimplemented local-command path is an explicit feasibility gate with a caller-visible explanation, not a silent stall.
• Push/LAN/relay (15–16) vs §5–6: opaque wake identifiers, authenticated fetch before actionable display, pinned identities on both paths, consumption state preserved across path changes, and relay inability to mint decisions are consistent with the signature model.
• Updates (17) vs §3: the disposition's protected-placement fix is present — root-launched code, staging, registrations, and containing directories must resist same-user replacement, with the "prove equivalent platform launch-time signature enforcement" escape hatch (e.g., SMAppService) deferred to the feasibility gate. The drain policy, restart matrix, and "never replay a consumed permit" rule integrate cleanly with §6.
• Protocol evolution (18): contract selection is constrained by security floor and required action features, so "maximize eligible phones" cannot downgrade below a safe contract. Domain separation by purpose/version, authenticated negotiation transcripts, rejection of re-encoding to weaker schemas, and per-delivery support rechecks close the downgrade/replay surface I probed (stale pushes, replayed audit batches, replayed negotiation, replayed policy, permit reuse, credential-package substitution). Each is either explicitly rejected or covered by an acceptance test.
• Disposition verification: all four round-6 corrections appear in the text as described. I found no concrete unresolved scenario that challenges their reasoning.

Threat-model boundaries. Malicious unprivileged caller coverage (audit-token/XPC validation, caller-identity capture, stdin classification, decision-key narrowness, both-verifier scope enforcement) is intact, and the confirmed allow-once tradeoff is not widened to commands or 1Password. Key separation (authority/transport/adapter/decision/credential) survives the new negotiation and push sections.

UX preservation. No new findings in revision 13 silently add confirmations, biometrics, manual steps, or shortened windows. The idle interval, retention duration, recurring update authorization, and local-command path are explicitly deferred preferences or gated decisions with consultation paths, which per the review protocol are not defects. All three adapters remain in scope with staged delivery.

Remaining verification limits

This is a plan-only review. Unverified by definition: macOS 14 API availability (XPC peer requirements, service management, protected placement), 1Password/Little Snitch AX contracts, single-biometric credential release, monotonic-clock-including-sleep behavior, descriptor-based execution, background Access authentication, push delivery under Doze, and update-drain continuity. All are scheduled as feasibility gates with evidence requirements and consultation paths; none are claimed as proven.

NO SUBSTANTIVE FINDINGS

Remozio plan review: revision 13

Scope: complete plan, revision 13, plus the round 6 disposition. This is a plan-only review; nothing was tested, browsed, or inspected in source.

The round 6 corrections are all present in revision 13:

• protected placement
• the restart matrix
• mixed-phone contract selection
• last-phone revocation

The earlier invariants hold against the new sections, with the exceptions below:

• scope and biometric classification
• key separation
• relay non-authority
• memory-only payloads
• the no-replay rule for Unknown

Findings

1. Medium: an automatic update drain can halt remote work indefinitely, and nothing remote can end it (§17 "Activate a compatible component set"; §17 "Sparkle release delivery")

Scenario:

1. Automatic updates are enabled. Sparkle stages a new root authority while the user is away.
2. A long-lived remozio sudo command is running, such as a watcher or privileged dev server.
3. The drain starts and stops admitting new requests. Every new command gets "Update waiting".
4. Every new Little Snitch or 1Password prompt is also refused, and no phone notification is sent.
5. §17 explicitly allows the long command to defer activation indefinitely. Admission therefore stays frozen indefinitely too.

The plan does offer "defer or cancel-update-drain", but it has three gaps:

• It shows blockers in the phone status but never says whether the phone can defer or cancel.
• §6 lists no signed purpose for that control.
• The status channel "cannot authorize actions", so it cannot carry this control either.

A remote user therefore has no defined way to recover. This silently reduces remote functionality, which §1 forbids without consultation.

Minimal correction:

• Stage the update without draining. Start the root drain only in one of two cases:
  • the authority is already quiescent (no pending requests, active commands, or live permits);
  • the user explicitly starts it.
• Otherwise show "Update ready" and keep admitting requests.
• If phone-side defer or cancel is wanted, define it as a narrow signed purpose that is non-authorizing for actions. It could use the decision key, since it grants no target authority. Verify it at the root.

Needs user decision: whether a security-fix update may start a drain automatically, possibly after a bound. That trades update latency against a remote admission freeze. It is a policy choice, not something to settle silently.

2. Low–Medium: old but validly signed builds can still act as privileged peers (§17 "What each signature proves"; §3 "Authenticate local process boundaries"; §18 "Compatible additions and breaking changes")

Scenario:

1. A malicious same-user process launches an older, publicly released Remozio GUI adapter or app build. That build is correctly signed with the same Team ID and signing identifier, and has a fixed vulnerability.
2. It passes the designated-requirement and live XPC checks.
3. It shares the keychain access group, so it can use adapter receiving keys and request permits or credential packages.

The same-user attacker is in scope. §17 enforces minimum builds only "where required", and §18's persisted security generations are never tied to peer admission.

Minimal correction:

• On every privileged XPC request, the root authority checks the peer's signed build or security generation against the persisted authenticated minimum. This applies to every role that receives permits, credentials, or adapter-key certification.
• The adapter-key certification in §3 records that generation. Raising the floor invalidates earlier certifications.

This does not worsen UX.

3. Low: GUI adapter replacement during an update has no quiesce rule (§17 "Activate a compatible component set", restart matrix; §9 "Scope mutation is part of one attempt")

The drain is defined only for root-authority replacement. A normal Sparkle app-bundle install terminates and relaunches the app.

Scenario:

• If the adapter is hosted in the app or relaunched with it, an install during a consumed Little Snitch permit turns a routine allow-once into Unknown.
• The dialog default may have been mutated by then (§9).
• A pending 1Password prompt with a ~60 s lifetime may be lost to the restart.

The matrix handles the aftermath but does nothing to avoid causing it.

Minimal correction: defer adapter termination until no live permit exists, with a short bounded wait before relaunch. Record interruptions caused by the update in the audit log.

This does not worsen UX.

Explicitly gated or deferred, not findings

These have defined evidence and a failure or consultation path:

• the Cloudflare Access credential provisioning source
• renewed service-management authorization on update
• protected root placement
• the local command approval surface
• one-biometric credential release
• 1Password and Little Snitch fixtures
• descriptor-based execution and sudoers compatibility
• the idle threshold and retention duration

Remaining implementation limits

None of the following can be established by plan review:

• AX click atomicity
• Android key-invalidation behavior
• launch-time signature enforcement on macOS 14
• push delivery under Doze

SUBSTANTIVE FINDINGS REMAIN

Round 6 disposition

Input: revision 12, SHA-256 31db9eeb87ef97256f9465c00088f0738c29be8c50c72cf50478c482c1be8463. Reviewers: kimi-code/k3-256k, claude-code/claude-opus-5-5, and zai/glm-5.3.

Opus and K3 returned nonempty reports with exit 0. GLM's first run returned an empty report with exit 0; this is not a successful review. The same-model structured retry also returned no final report, with stopReason length. Its output limit was consumed before a final response. Neither GLM attempt counts as an assessment.

Corrections in revision 13

No new biometrics, forced pairing, command restrictions, payload persistence, or forced command termination was adopted. Recurring authorization for updates remains a feasibility result that requires consultation if unavoidable. Draining shows its blockers and can be deferred; no forced update deadline was introduced.

Independent review — Remozio plan, revision 12

Scope assessed: internal consistency of the full plan including post-revision-5 additions (§12 audit, §13 expiry, §14 routing, §15 push, §16 LAN/relay, §17 identity/Sparkle, §18 protocol evolution), checked against the earlier invariants (§5–§9). Security boundaries, key separation, scope classification, relay resistance, and downgrade handling were re-examined; I found them coherent except where noted. Feasibility gates explicitly defined with evidence/consultation paths (service installation, single-biometric credential release, sudoers compatibility, Little Snitch/1Password fixtures, local command approval, remote update continuity, background Access auth, pairing preservation) are treated as planned work, not defects.

SUBSTANTIVE FINDINGS REMAIN

Finding 1 (medium): Contradictory restart semantics for pending requests and consumed permits

Sections: §6 "Crash and uncertain-outcome handling" vs §17 "Activate a compatible component set" and §18 "Acceptance: upgrades and hostile peers".

Contradiction: §6 states pending sensitive payloads are memory-only and "a restart cancels unconsumed requests"; §10 acceptance requires "no execution on service restart"; §6 also requires a consumed GUI permit with lost acknowledgment/IPC to become unknown, be invalidated, and never act later. But §17 requires "Do not… silently discard pending requests to install an update. Defer activation when continuity cannot be guaranteed. Resume pending requests only if their original payload, version, expiry, and ledger state remain valid," and §18 acceptance requires "Update with… a pending biometric prompt… and a consumed GUI permit. Preserve the original request contract."

Concrete failure scenario: An update activates while a command request awaits phone approval. The payload is memory-only, so the post-restart service cannot resume it — "resume if valid" is unreachable, and "defer activation when continuity cannot be guaranteed" either deadlocks updates whenever any request is pending or silently contradicts §6 by discarding the request. Similarly, a consumed-but-unacknowledged GUI permit across a service restart must resolve to unknown under §6, but the §18 acceptance case as written demands its contract be preserved.

Minimal correction: Add an explicit restart-state matrix reconciling the sections: (a) durable pending-request metadata may survive restart; sensitive payloads never do, so post-restart pending requests follow the already-specified "show why the request needs a fresh submission" path (with recapture/new challenge where §9 Refresh applies); (b) consumed-unacknowledged permits always resolve to unknown after restart; (c) "defer activation" is scoped to protecting active executions only (already covered by "do not kill active commands"). Reword the §18 acceptance case to match (a)–(b). No UX worsening: this adopts behavior the plan already specifies elsewhere.

Finding 2 (low): Last-phone revocation cancels locally-approvable requests

Sections: §5 "Revocation and pairing recovery" vs §14 "Menu bar modes" / §14 "Feasibility gate: local command approval".

Contradiction: §5 cancels a pending request "when no authorized phone remains for the Mac/account." §14 later introduces "At my Mac" mode and a planned local command-approval surface, under which a pending request never required any phone. Revoking the sole enrolled phone (e.g., a lost phone while working locally) would spuriously cancel requests that could still be resolved locally, forcing resubmission.

Minimal correction: Scope the cancellation to requests with no remaining authorized approval surface (no authorized phone and no available local path), or explicitly to requests awaiting phone resolution. This adds no steps and only removes a spurious cancellation; no consultation concern.

Tentative UX choices (not defects, explicitly deferred in-plan)

Five-minute request expiry (§5, "provisional… UX default to validate"); 30-second draft idle interval (§14, pending preference); ~60-second 1Password lifetime estimate (§13, per-version validation planned); macOS 14 compatibility floor (§3, provisional). These have defined validation paths and are not findings.

What was verified as consistent

• Key separation and purpose binding (§6–§7): decision key cannot authorize commands/credentials/rule changes; both verifiers derive key class from retained semantics; relay/transport keys mint nothing.
• Scope classification (§1, §9): reusable rules incl. session/timed require biometrics; once-decisions confined to the captured alert; unknown compatibility cannot inherit one-time classification; biometric-free allow-once is not widened.
• Downgrade/replay resistance (§17–§18): authenticated negotiation transcript, domain separation, security floors from trusted local policy, replayed-policy rejection, minimum-build enforcement, no hash pinning across updates.
• Push/relay privacy (§15–§16): opaque wake IDs, end-to-end payload encryption, Access as gate not authority, no shared APK secret.
• Audit invariants (§12): consumption + journal event commit atomically; secret exclusions; revoked-phone limits acknowledged honestly.
• Expiry/timing (§13) and routing handoff (§14) preserve identity, age, and first-decision-wins semantics; presence changes do not cancel in-flight biometrics.
• Confirmed UX tradeoffs (biometric-free cancel/deny-once/allow-once, Forever default with biometrics, no keyguard surface, full command rendering) are preserved throughout, including in the new sections.

Remaining implementation verification limits: This is a plan-only review. Platform behaviors assumed but not yet evidenced (continuous monotonic clock across sleep, descriptor-based execution, Access service-token background auth, Sparkle/SMAppService continuity, per-display brightness signals, AX stability of target dialogs) are all attached to explicit feasibility gates; none were treated as granted.

Remozio plan review: revision 12 (complete plan)

Findings

1. HIGH: Root-executed code may be updated through a path the same user can write

References: §3 "Authenticate local process boundaries"; §17 "Sparkle release delivery" and "Feasibility gate: remote update continuity".

Conflict. §3 requires trusted bundles and update paths in "administrator-controlled locations." It also puts a malicious same-user process in scope. §17 prefers ordinary Sparkle app-bundle updates, with the service registered from inside that bundle, and notes this "does not automatically require a package installer."

On a typical personal Mac, the interactive user is an administrator. So "administrator-controlled" can mean "writable by the user's own processes without an authorization prompt." That is exactly how Sparkle can replace an app in /Applications without asking for credentials.

Failure scenario.

1. A coding agent running as that admin user modifies or swaps the bundle containing the privileged service, or races the staged update.
2. launchd later starts the replaced executable as root.
3. Live XPC peer checks do not help. They protect callers of the service, not the service's own launch. The attacker gains root and every Remozio authority.

The §17 feasibility gate only asks whether renewed administrator authorization is needed. It is framed as a UX question. It has no security pass criterion.

Minimal correction.

• State an invariant: code launched as root, and its update staging, must not be modifiable by the interactive user's unprivileged processes without administrator authorization.
• Make that invariant an explicit pass/fail criterion of the §17 gate.
• Accept only one of two outcomes:
  • root-owned, non-user-writable placement, or
  • a demonstrated platform launch-time signature enforcement for the registered service.
• Add a matching item to "Acceptance: upgrades and hostile peers."

UX flag. If the only safe path requires administrator authorization per update, remote and locked-Mac updates get a recurring manual step. This needs user consultation, as §17 already implies. It must not be silently adopted.

2. MEDIUM: Update continuity contradicts memory-only payloads and root-owned process I/O

References: §6 "Crash and uncertain-outcome handling"; §8 "Process I/O and terminal outcomes"; §17 "Activate a compatible component set".

Two contradictions.

• §6 keeps pending sensitive payloads in memory only, so a root-service restart cancels unconsumed requests. §17 says to resume pending requests "only if their original payload... remain valid." After a root-service replacement, the payload cannot remain; it was never persisted. The only ways to "resume" are:
  • persisting payloads, which violates §6 and §12, or
  • an unspecified handoff between old and new service instances.
• §8 makes the root service own streaming stdin/stdout/PTY and signal forwarding. Replacing that service severs the attached command. That conflicts with "do not kill active commands."

Failure scenarios.

• An implementer satisfies §17 by persisting payloads, breaking a privacy invariant.
• Alternatively, "defer activation when continuity cannot be guaranteed" defers indefinitely. A long-running remote PTY session, or a steady stream of pending requests, then blocks security-floor updates forever. The plan has no bound or user-visible resolution.

Minimal correction.

• Scope "resume" to restarts of the GUI adapter, transport, and app, where the root service retains state.
• For root-service replacement, choose one policy:
  • drain: stop accepting new requests, let active and pending work finish, then activate, or
  • cancel: cancel unconsumed requests with an explicit fresh-submission status.
• Never persist payloads.
• Define how deferral is surfaced when a security-floor update is waiting.

UX flag. The cancel policy discards pending requests during updates. Any forced interruption of active commands is also a UX regression. Both require user consultation. Drain-with-visible-status is the non-regressing default.

3. LOW: Request version selection with mixed-version phones is undefined

Reference: §18 "Authenticated negotiation".

Gap. Negotiation selects "the highest mutually supported version" for each peer. But §18 also mandates a single immutable request, with no re-encoding for other phones. With phone A on v1 and phone B on v1+v2, the plan does not say which version the authority signs.

Failure scenario. Choosing v2 needlessly strips actionable controls from a compatible, above-floor phone A. That reduces remote availability.

Minimal correction. Define request-version selection over the currently authorized recipient set. For example: the highest version that satisfies the action's required features and the security floor, and that maximizes the number of eligible phones. Add a two-phone mixed-version case to the acceptance list.

Assessed without further findings

Key and authority separation

• Scope classification, and use of the biometric key versus the decision key, are consistent across §1, §6, §9 and the acceptance lists.
• The Little Snitch-only allow-once rule is not widened to commands or 1Password.
• Relay, push gateway and Access credentials cannot mint decisions, and they stay outside approval authority.

Consumption, audit and expiry

• The audit journal is derived from the consumption ledger without becoming a second authority.
• Target expiry is kept separate from Remozio expiry and from disappearance.
• Presence routing is delivery-only and consumes once across surfaces.

Push and negotiation

• Push payloads are opaque.
• Negotiation downgrade and domain separation are covered.

Gates and deferred preferences

• The local-command approval path, Access background authentication, the single-biometric credential release, sudoers compatibility, and descriptor-based execution are properly scheduled as gates with consultation paths.
• The idle threshold and retention duration are deferred preferences, not defects.

Limits of this review: this is a plan-only review. Platform behavior still has to be proven in implementation, including:

• Keystore invalidation behavior,
• AX atomicity,
• Tunnel/Access token renewal,
• whether SMAppService and Sparkle can update services without re-authorization.

SUBSTANTIVE FINDINGS REMAIN

Round 5 disposition

Both requested reviewers reported NO SUBSTANTIVE FINDINGS on the same revision 5.

• Opus: claude-code/claude-opus-5-5; exit 0; nonempty report; empty stderr.
• Kimi: kimi-code/k3-256k; exit 0; nonempty report; empty stderr.
• Input SHA-256: 35a5db40f0565b4a13f6e89a99594fdeb1210a1e42dbfdb9af502a3313975cb9.

Plan review has converged. The user-confirmed action policy and pairing-preservation goal are unchanged. The plan remains a design draft; platform feasibility and implementation security have not been tested.

Opus offered a non-blocking cross-reference suggestion for the credential-recipient binding. Sections 3 and 7 already specify that binding, and the acceptance test covers recipient substitution. No substantive plan edit was needed after review.

Independent plan review — Remozio revision 5

Verdict: NO SUBSTANTIVE FINDINGS

What was assessed

This was a plan-only review; no source, device, or network behavior was inspected or tested. I traced concrete attack and failure scenarios against the plan text rather than restating it:

• Scope classification and the Little Snitch once-exception (§1, §6, §9). The once/rule boundary is drawn from retained action semantics and adapter capability mapping, not caller or phone assertions; both verifiers (root service and GUI adapter) independently enforce it; reusable timed/session rules are classified as rule-setting; second and concurrent connection attempts inheriting a once-decision are explicitly tested (§10). The confirmed biometric-free allow-once is not widened to commands or 1Password, and both verifiers reject decision-key authority for those purposes. Unknown compatibility contracts cannot inherit one-time classification, with no biometric override path. I could not construct a scope-confusion scenario that survives these controls.
• Key separation and relay resistance (§3, §5, §6). Authority, transport, biometric, decision, and credential keys have distinct purposes; purpose asserted in a message grants no authority; decisions bind the full request digest, challenge, action, scope, expiry, and phone identity; the relay sees only E2E-encrypted payloads and cannot mint decisions, alter digests, or substitute credential recipients (all in acceptance tests). The pre-login transport key fallback is correctly excluded from credential/authority custody, with an explicit blocker-and-consult path rather than silent degradation.
• Command binding (§8). Capture-before-approval of argv/env/cwd/credentials/stdin classification; uncaptured caller-controlled input is disclosed without implying provenance; verified requester identity is separated from unverified rationale/ancestry; the execution-recheck race, sudoers policy parity, and descriptor-based execution are all defined feasibility gates with evidence-plus-consultation paths, not silent assumptions.
• UI race handling (§6, §9). One-time ledger permits consumed before dialog mutation; revalidation of identity, dialog instance, semantic fields, scope, and control; scope-mutation failure → unknown with no retry/restore; refresh labels potentially modified defaults; consumed permit without acknowledgment reaches unknown and cannot act later; reordered/replaced dialogs tested for Deny/Cancel. The permit being obtained from the root ledger immediately before acting also closes the revocation race for UI decisions.
• Android biometric and credential release (§7). Per-tuple keys, CryptoObject binding to an immutable displayed request, transition tests, no keyguard approval surface per the user's clarification, decision-key rules mirroring the immutable-selection rule. The single-biometric credential-release question is a defined spike with a consult-on-failure path.
• Recovery and remote-coding UX (§5, §8). Multi-phone consumption, revocation serialization, and cancel-when-no-authorized-phone match disposition F2; target timeout/default capture and observed-vs-unknown resolution match F1; remote-administrator recovery does not require the old phone; pairing preservation after biometric change is a gate with an authenticated fallback, not a promise. Coding-tool timeouts are surfaced, not silently shortened; no UX-worsening change (extra confirmations, restricted commands, shorter windows) is silently adopted anywhere in the revision.
• Prior disposition (round 4). F1 and F2 are verifiably implemented in §9 and §5 respectively; the sudoers gate is correctly framed as evidence-plus-user-choice, not a pre-made policy selection. No unresolved scenario from it remains.

Tentative choices explicitly deferred to the user (not defects)

These remain open but each has a defined evidence-and-consultation path: relay/push-wake delivery; sudoers integration vs. administered Remozio policy; atomic execution mechanism options; single-biometric vs. dual-operation credential release; unlocked-device constraint on the decision key; biometric-invalidation policy for the biometric key; synthetic-typing fallback for 1Password; StrongBox/TEE minimum assurance; optional detached execution mode; any environment restriction that breaks a workflow. Per the review instructions these are gates, and convergence is not claimable over them as settled policy.

Remaining implementation verification limits

Convergence here means the plan is internally consistent and complete at the planning level only. Still unverified and reserved to the feasibility stage: real 1Password/Little Snitch AX structure and true once-semantics, Keystore invalidation behavior across Android versions, pre-login key custody, sudoers parity, descriptor-based execution, background delivery under Doze, and macOS 14+ service-management behavior. No code, signatures, or privileged boundaries exist yet to audit; this review cannot and does not attest to implementation security.

Remozio plan review: revision 5

Scope: This review covers only the plan text. I did not inspect source, run tests, or verify any platform behavior. I evaluated the plan against the review instructions and the round-4 disposition.

Result

I found no concrete planning defects that require a correction. I also found no unselected product policy that the plan treats as decided.

What was assessed

• Round-4 disposition: Revision 5 implements both accepted items.
  • F1, target timeouts (§9): The plan captures each dialog's observable deadline and default effect as semantic data. The passage of time does not invalidate a request. It distinguishes an observed target timeout from a disappearance with unknown cause. It does not shorten Remozio's approval window or change target defaults.
  • F2, multi-phone revocation (§5): Revocation removes only the selected phone's authority. Other enrolled phones keep pending requests. A request is cancelled only when no authorized phone remains. Revocation is serialized with decision consumption and covered by acceptance tests.
  • Sudoers clarification (§8): This remains a feasibility gate that ends with a user choice. No policy is chosen silently.
  • I found no scenario that reopens these dispositions.
• Biometric policy and scope classification (§1, §6, §9):
  • The action table matches the user's confirmed choices. Cancel, deny-once and allow-once need no biometrics. Every reusable rule needs biometrics, including Forever, Deny Forever, and timed or session rules.
  • Allow-once without biometrics is limited to Little Snitch. Both the root service and the GUI adapter reject decision-key authority for commands, 1Password, credentials and enrollment.
  • Classification comes from retained action semantics and the adapter's validated compatibility contract. It never comes from button labels, caller labels, or a phone's claim that biometrics are unnecessary.
  • "Current request" is defined concretely. Later connection attempts, and attempts arriving while an alert is open, are tested so they cannot inherit a once-decision.
• Key separation (§3, §6, §7):
  • The plan keeps these keys distinct: Mac authority, transport, adapter receiving, phone biometric, phone decision, and phone credential keys.
  • Key purpose is checked against enrollment records, not against what the message claims.
  • A decision key cannot replace biometric or credential authority.
  • The pre-login transport-key fallback is explicitly excluded for authority and credential keys.
• Relay resistance (§3, §5, §6):
  • Payloads are end-to-end encrypted between the root authority and the phone.
  • Requests are signed by the authority, and credentials are encrypted to a certified adapter key.
  • A relay or transport key cannot mint decisions, including one-time decisions.
  • Push payloads carry only opaque wake identifiers.
• Malicious unprivileged caller (§2, §3, §8, §9):
  • The caller's identity comes from the audit token and trusted OS queries, not from caller-supplied PIDs or labels.
  • Frontend signatures are not treated as consent.
  • Live code identity is checked on every privileged XPC request, and code injection and bundle modification are tested.
  • Only the originating caller/session, an enrolled phone, or the local administrator may cancel a request.
  • Requests are rate-limited, and batches are never auto-approved.
  • The plan documents the gap where other automation already holds Accessibility or Automation grants over the target.
• Command binding (§8):
  • The plan captures the full argv, working directory, target UID/GID and groups, environment, and stdin classification.
  • Uncaptured stdin is disclosed rather than prebuffered.
  • Oversized requests return Request too large without truncation.
  • Requester-exited outcomes distinguish "no child started" from "started or unknown."
  • The executable-entry race is a gate with a required semantic contract and a user-consultation path. No silent relocation or allowlist is introduced.
• Android biometrics and credentials (§7):
  • Signing uses a CryptoObject bound to the immutable selected request, with no grace period.
  • The single-authentication credential-release question is a feasibility spike. It leads to consultation if a second prompt or weaker protection would be needed.
  • Pairing is preserved after biometric changes where the OS and key policy allow it, which matches the user's preference.
  • Recovery goes through an independently authenticated administrator session within the retained pairing record.
• UI race handling (§6, §9):
  • Dispatch uses a one-time ledger permit that is consumed before any dialog mutation.
  • A missing acknowledgment or adapter death produces an unknown result, never a retry.
  • Late adapters cannot act, and refresh requests are labeled when a default may have been modified.
  • Deny and Cancel receive the same revalidation as Allow.
• Remote coding UX (§1, §5, §8):
  • Commands work without a GUI login or while the GUI session is locked.
  • The plan measures harness timeouts instead of shortening the approval window.
  • Offline state, queueing, and reconciliation are visible to the user.
  • Manual sudo remains available as a fallback.
• Flux borrowing (§4): The plan uses Flux as a design reference only until its license is resolved.

Remaining tentative UX choices (tracked, not defects)

These are open decisions that the plan already records as provisional or consultation items:

• The provisional five-minute request expiry.
• Whether to add an encrypted relay or push wake.
• An optional detached or resumable command mode.
• The sudoers-policy integration versus a Remozio-administered policy.
• The outcome of the executable-entry race gate.
• Accepting software-only keystores or biometric fallback.
• Changes to 1Password credential delivery if only synthetic typing is possible.
• Little Snitch behavior if true one-time scope proves unavailable.

Non-blocking clarification (not a finding)

§6 lists the fields of the authority-signed request, but that list does not name the certified credential-recipient binding for unlock requests. §3 and the acceptance test "credential recipient substitution fails" already imply that binding. Naming it among the §6 request fields would make the protocol spec self-contained. This does not affect UX.

Implementation verification limits

Convergence on this plan does not establish any of the following. Each needs real-device or real-host evidence during the feasibility gates and later stages:

• Whether Android Keystore preserves keys across biometric enrollment changes.
• Whether a single CryptoObject authentication can release a credential.
• Whether pre-login keychain or LaunchDaemon key custody works.
• Whether descriptor-based execution is available on macOS.
• Whether Little Snitch's one-time effect is truly limited to the captured request.
• Whether 1Password exposes its accessibility structure and a directly targetable secure field.
• Whether Doze and background-delivery behavior is reliable on real devices.
• Whether sudoers compatibility is achievable.

NO SUBSTANTIVE FINDINGS

Round 4 disposition

Input SHA-256: e457596b28ed386acefe531fd34e301a0a410f49c66d87caee0cbd0ef9c93902. Both models exited 0 with nonempty reports and empty stderr.

Kimi: NO SUBSTANTIVE FINDINGS. Platform experiments remain future implementation work.

Opus:

• F1 accepted. Capture observable target timeout/default effects, show them separately from Remozio expiry, and distinguish observed auto-resolution from unexplained disappearance. Ticking alone does not invalidate a request. Do not change response windows or target defaults.
• F2 accepted. Revocation removes the selected phone's authority while other enrolled phones retain pending requests. Cancel when no authorized phone remains. Serialize revocation with consumption and test two-phone behavior.
• Clarified the sudoers feasibility gate: present evidence and obtain the user's choice before selecting the policy integration. No current policy choice is silently made.

Revision 5 implements these corrections. No new UX restrictions, confirmations, or biometric requirements were added.

Independent Plan Review — Remozio revision 4

Reviewed artifact: reviews/round-4-plan.md (draft, revision 4, dated 2026-09-29) Prior disposition: reviews/round-3-disposition.md (input hash 1bc49a15…) Review type: plan-only. No source inspection, runtime testing, or platform verification was performed or is claimed.

Verdict

NO SUBSTANTIVE FINDINGS

What was assessed

1. Internal consistency (§§1–10)

The biometric policy table in §1 was cross-checked against every later enforcement point. §6 (both verifiers derive key class from retained action semantics, never from caller/phone assertions), §7 (purpose-separated keys, no grace period), and §9 (per-version effect validation for Once/Cancel; reusable timed/session rules classified as rule-setting) all restate the same policy without drift. The section 1 sentence "Signing remains available only for the request currently displayed" was checked against §7's immutable-selection rule: §7 is the more precise statement (a request switch must cancel or leave the prompt bound to the original selection; it may never sign the newly displayed request), and the two do not conflict in effect. The §3 statement that UI details are authenticated adapter assertions, with the root signature attesting provenance rather than AX atomicity, is honestly scoped and consistent with §9's race disclosure. No instance was found where a rule relaxed in one section is silently tightened or widened in another.

2. Security boundaries and key separation (§§2, 3, 6, 7)

• Five key classes are separated: root authority, transport, adapter receiving, phone biometric signing, phone biometric-free decision, plus the credential encryption key. Purpose is enforced by verifier-side derivation from retained semantics, not message assertions (§6), closing the purpose-confusion path raised in round 3 (Opus F6).
• The decision key's exclusion from rule changes, commands, 1Password, credential release, and enrollment is stated in §6 and covered by acceptance tests ("both verifiers reject decision-key authority for commands, 1Password access/unlock, credentials, and enrollment"; "an existing decision key cannot replace biometric or credential authority").
• The credential-release chain (§3, §7) binds the adapter receiving key to account, session, process incarnation, and request via root-certified XPC, with recipient substitution tested. No plaintext path through the relay exists by construction.
• The live code-identity validation per XPC request, hardened-runtime restrictions, and same-user injection/bundle-modification tests (§3, §10) address the in-scope malicious unprivileged caller without inventing platform guarantees.

3. Relay resistance (§§2, 3, 5, 6)

End-to-end authenticated encryption between root authority and phone, opaque wake identifiers only, digest recomputation and mismatch rejection on the phone, and single-use consumption at the ledger give the relay only delay/drop/metadata capabilities. §2 states this residual explicitly and accurately. Acceptance tests cover payload/digest tampering and decision-minting from relay/transport keys.

4. Scope classification (§§1, 6, 9)

The Little Snitch allow-once exception is confined to the captured connection attempt or fixed set of attempts; later attempts and attempts arriving while the alert is open are explicitly required not to inherit the decision, with planned validation. The widening guard from the review instructions holds: the exception is not extended to command execution or 1Password. The biometric-free "Cancel the current target request" row confers no access and performs only a ledger-permitted UI dismissal, which matches the confirmed user choice rather than widening allow-once. The fallback ordering in §9 (unknown semantics → read-only route → compatibility investigation → user consultation; biometrics never override unknown semantics) is correct and was verified to have no silent Once↔reusable fallback in either direction.

5. Command binding (§8)

Capture covers effective executable, argv bytes, cwd, target UID/GID and supplementary groups, environment, I/O mode, and stdin source classification, with honest disclosure that caller-controlled stdin (pipe, PTY, TTY) is not approved byte-for-byte and that terminal input is not necessarily human-authored. Display rules preserve raw bytes with unambiguous escaping, verified requester identity is separated from caller-supplied rationale, and execution is direct without an injected shell. The atomic-substitution problem is handled as a gate (descriptor-execution spike, no silent relocation, measured options presented to the user) rather than by a false hash-check guarantee, and the plan explicitly disclaims transitive-effect binding. Sudoers semantic compatibility is an explicit gate with no automatic-preservation claim. This is the correct level of honesty for a plan.

6. Android biometric and credential release (§§5, 7)

BIOMETRIC_STRONG with no grace period, CryptoObject-bound prompts, immutable selection across switching/rotation/backgrounding/process death, and lock-screen unavailability matching the confirmed UX are all specified with transition tests. The single-BiometricPrompt credential-release question is correctly framed as a spike with a user-consultation failure path rather than an assumed platform capability. The biometric-invalidation/pairing-preservation policy is a defined gate (§5) that selects a supported key policy, preserves pairing metadata, uses authenticated remote-admin recovery, forbids decision-key self-elevation, and reserves full re-pairing for an untrusted pairing record — consistent with the round-3 U1 resolution and the user's stated preference.

7. UI race handling (§§6, 9)

The one-time dispatch permit, consumption before any mutation, bounded scope-selection→re-read→click attempt, unknown-on-interruption with no retry and no automatic control restoration, refresh labeling of potentially modified defaults, permit invalidation on adapter death/lost ack, and stale-permit rejection form a closed design with no identified window where a late or competing actor can act. Revalidation uses dialog instance/control identity rather than coordinates or titles, so an obscured or reordered screen cannot redirect a click. The non-atomicity of AX observation/click is disclosed rather than papered over.

8. Recovery and remote-coding UX (§§5, 8, 10)

Enrollment recovery never requires the lost phone to approve its own replacement; independently authenticated admin sessions (including remote SSH) are the recovery path; routing never silently grants or removes authority. Multi-phone fan-out with consume-once semantics and terminal reconciliation is specified and tested. Coding-tool timeouts are measured and surfaced, the approval window is not shortened to match harness timeouts, requester-exit races distinguish no-effect from started/unknown outcomes, and resubmission is explicit. No remote functionality is removed anywhere in the plan.

9. Planned validation completeness (§10)

The acceptance list was mapped against every review axis: key-purpose rejection, multi-phone consumption, replacement revocation, oversize handling without truncation, caller-exit boundary outcomes, adapter impersonation, recipient substitution, relay tampering, once-decision non-inheritance and non-transfer, unknown-contract classification, scope-mutation unknowns, injection/bundle modification, keyguard and obscured-tap protections, biometric-change continuity, Once-to-Forever races, remote-admin recovery, sleep-expiry, UI-string spoofing, stdin substitution, stale Deny/Cancel, unacknowledged permits, refresh-without-replay, and pre-login key custody. No axis in the review instructions lacks a corresponding planned test. All three adapters remain fully in scope (§10 stage note).

10. Flux licensing (§4)

The unresolved-license state is handled correctly: design-reference only, independent implementation from platform documentation, no source copying, and Flux's command-blind PAM model and Linux assumptions explicitly excluded. No licensing defect.

11. Prior disposition challenge (round 3)

Each accepted fix (F1–F7, Kimi 1–3) was traced into revision 4 text and found faithfully incorporated. The rejection of "feasibility gates block convergence" is consistent with the review instructions. No concrete unresolved scenario was found that contradicts any round-3 disposition, including U1 (pairing preservation) and F5 (no lock-screen workflow).

Tentative UX choices (flagged separately — not defects)

Per the review instructions, the following are defined feasibility gates with evidence requirements and failure/consultation paths, and are therefore not planning defects and not convergence blockers. They remain open user decisions by design:

1. Five-minute request expiry (§5) — provisional default to validate; adjustable within resource bounds.
2. Unlocked-device constraint on the decision key (§7) — evaluation only, explicitly barred from changing the confirmed interaction flow.
3. Biometric-enrollment invalidation policy (§§5, 7) — gate selects the supported key policy; pairing preservation is the goal, authenticated remote-admin recovery is the fallback.
4. Single-BiometricPrompt credential release (§7) — spike; a second biometric or weaker protection triggers user consultation, not silent acceptance.
5. Atomic descriptor-based execution (§8) — spike; fallback requires presenting measured options before enabling any guarantee-sensitive path; no silent relocation or allowlist.
6. Sudoers policy integration (§8) — gate chooses between enforcing existing applicable policy and an explicitly administered Remozio policy with installation disclosure.
7. Relay/push wake for background delivery (§5) — required only if direct delivery proves unreliable; concrete choice goes to the user.
8. Little Snitch true one-time semantics (§9) — per-version effect validation; absence of true one-time behavior triggers consultation.
9. Pre-login transport key custody (§3) — keychain vs. dedicated-account-private fallback, with an explicit blocker if neither qualifies.
10. macOS 14+ compatibility floor (§3) — provisional, pending the service-management API spike.

None of these silently worsen UX; each carries an explicit consultation path.

UX-regression check on this review

This review proposes no corrections, and therefore introduces no confirmations, biometric steps, command restrictions, functionality reductions, shortened windows, or manual steps. Nothing here requires user consultation.

Remaining implementation verification limits

A plan-only review cannot establish, and this verdict does not assert:

• Actual Accessibility tree structure, stability, and field semantics of the shipped 1Password and Little Snitch versions; the compatibility contracts (§9) must be proven against real captures.
• Real Android behavior for Doze, force-stop, notification permissions, VPN loss, Keystore invalidation across versions/vendors, and the single-CryptoObject credential operation (§§5, 7 gates).
• Feasibility of descriptor-based execution, pre-login key custody, supported privileged-installation APIs, and sudoers-consistent enforcement on target macOS versions (§§3, 8 gates).
• Correctness of the final wire format, cryptographic implementation, and code-level enforcement of the ledger/permit invariants; this is deferred to the protocol harness (§10 stage 2) and the planned independent implementation review (§10 stage 7).
• Practical latency and delivery reliability; acceptance explicitly awaits device measurements (§10).

Convergence per §11 means both reviewers find no substantive unresolved planning findings on the same revision; it does not mean the above implementation evidence exists yet, and none is demanded here.

Conclusion

NO SUBSTANTIVE FINDINGS

Remozio plan review: revision 4

Scope: This review covers the plan text only. I did not run tests, browse, or inspect source. Anything below about platform behavior is conditional, and the plan's own feasibility gates are meant to settle it.

Summary

Revision 4 is internally consistent on the points the round-3 dispositions targeted:

• Scope table: The table in §1 matches the enforcement text in §6 and §9 and the acceptance cases in §10.
• Key separation: Authority, transport, biometric, decision, credential and adapter-receiving keys are kept separate (§3, §6, §7).
• Relay resistance: End-to-end payloads, authority-signed requests, phone-signed decisions and recipient-bound credential packages together cover relay resistance (§3, §6).
• Allow-once limits: Biometric-free allow-once is limited to Little Snitch. §6, §9 and §10 each exclude commands, 1Password and credentials from it.
• Round-3 dispositions: The dispositions for Opus F1–F7, U1 and Kimi 1–3 are reflected in the text. I found no concrete scenario that undermines them, including the rejection of "every feasibility gate blocks convergence".

Two low-severity planning defects remain. Neither calls for weakening security or adding friction.

Findings

F1 (Low): Target-dialog countdowns are classed as cosmetic, so the phone may show a wrong deadline and wrong effect

Sections: §9, "Ignore cosmetic changes such as animation or countdown text"; §5, "Show remaining time"; §9, Little Snitch field list.

Scenario:

1. A supported UI dialog has its own countdown and applies a default action when it runs out. Whether Little Snitch or 1Password do this, and with which default, is not assumed here; the AX fixture capture should establish it.
2. The phone shows the Remozio five-minute window, for example "4:30 remaining".
3. The target dialog times out sooner and applies its own default, which might be a Forever rule.
4. The user then chooses "Deny once" and gets "dialog disappeared".
5. The user never learns that a reusable rule may now exist, and was never told the actual deadline.

A countdown that ends in an automatic action is a meaningful field of the request. Classing it as cosmetic hides that meaning. This is a gap in what the plan tells the user and in how it recovers. It is not a way to gain authority, since the target app would behave the same way without Remozio.

Minimal correction:

• During AX capture, record whether each supported dialog has a timeout and what it does on expiry.
• Where the timeout is observable, show "Target dialog auto-resolves in ~N (default: X)" next to the Remozio expiry.
• Report the terminal outcome as "Resolved by target timeout (observed effect: X / not verifiable)", not a generic "disappeared".
• Keep countdown text excluded from the semantic revision, so ticking alone never invalidates a request.

UX impact: None worsened. This does not shorten the Remozio window, add confirmations, or change defaults. It only shows information.

F2 (Low): "Revoke pending requests on key removal" was not updated for multi-phone fan-out

Sections: §5, pairing-recovery paragraph; §5, multi-phone paragraph (added in round 3); §10, "revocation during an open prompt".

Scenario:

1. The user has phones A and B enrolled.
2. A remozio sudo command from a coding tool is pending.
3. The user remotely revokes the lost phone A.
4. Read literally, the sentence cancels all pending requests for that Mac/account.
5. The coding tool receives a failure and the user must resubmit, even though phone B was about to approve.

Requests are now fanned out per Mac/account rather than per key, so the sentence is ambiguous. The ambiguity is not safety-critical, because the Mac rejects A's signatures after revocation either way. It does cause needless loss of remote functionality.

Minimal correction:

• On key removal, invalidate only the removed phone's authority over pending requests and reconcile the remaining phones.
• Cancel a pending request only when no authorized phone remains for its Mac/account.
• State that phone-side removal alone does not cancel Mac-side requests.
• Extend the §10 revocation test to cover the two-phone case.

UX impact: This improves UX. It is the less disruptive reading.

Remaining tentative choices (not defects)

Each item below already has a defined gate or consultation path. None should block convergence.

• Five-minute provisional expiry (§5).
• Relay/push wake, if direct delivery proves insufficient (§5).
• Pre-login transport key custody fallback (§3).
• Single-biometric credential release versus a second prompt (§7).
• Android biometric-key invalidation policy and pairing continuity (§5, §7).
• Unlocked-device constraint on the decision key, evaluated without changing the flow (§7).
• Descriptor-based execution and path-recheck race options (§8).
• Detached/resumable command mode (§8).
• Stdin prebuffering, which is explicitly not selected (§8).
• True one-time behavior per Little Snitch/1Password version (§9).
• Synthetic-typing fallback for credentials (§9).
• Software-only Keystore assurance (§4).
• Flux licensing, currently reference-only (§4).

Sudoers compatibility gate (§8): The plan does not say who selects between enforcing the existing sudoers policy and an administered Remozio policy. The §1 rule still requires user consultation for any resulting command restriction, and the selection should be recorded in REVIEW-LOG.md as a pending user decision.

Verification limits

Real-world correctness still depends on the scheduled evidence:

• Android Keystore and BiometricPrompt behavior across versions.
• macOS service-management, XPC and code-signing behavior on 14+.
• Pre-login keychain availability.
• 1Password and Little Snitch AX structures, one-time semantics, and any timeout behavior.
• Background delivery under Doze.
• Measured argv/environment limits.

None of these is claimed as verified here.

SUBSTANTIVE FINDINGS REMAIN

Round 3 disposition

Input SHA-256: 1bc49a15da7496df0976de0281bac762abaca9a25a6b2f5feb256cf4c49e3e9c. Both models completed with exit 0, nonempty reports, and empty stderr.

Opus

• F1 accepted: release hardening, controlled installation/update paths, live XPC code validity, and same-user injection tests.
• F2 accepted: one-time scope is a captured connection attempt or fixed set; later attempts require new authority. Test repeated connections.
• F3 accepted: allow-once explicitly included in permit, confinement, replay, and cross-purpose rejection tests.
• F4 clarified: a validated compatibility contract may cover a version range; an update does not automatically disable support. Truly unknown semantics use the existing read-only notification/manual route. Biometrics cannot repair unknown semantics. Any broader fallback requires concrete evidence and consultation.
• F5 resolved with user context: the phone's lock screen already prevents access to this request UI. No separate lock-screen workflow or extra app-unlock step. Add overlay/touch protections and test the existing navigation boundary.
• F6 accepted: separate authority requests from phone decisions and verify enrolled key purpose independently of message assertions.
• F7 accepted: consume before any scope mutation; all mutation and dispatch occur under one permit. Interrupted mutation is unknown and refresh identifies a potentially modified default.
• U1 resolved as a feasibility goal selected by the user: preserve pairing after biometric changes where practical. Validate supported key policy and safe continuity, retain pairing metadata, and fall back to independently authenticated remote-admin key recovery. A decision key cannot elevate itself by rebinding biometric authority. Full re-pairing is a last resort if the pairing record cannot be trusted.
• U2/U3 are covered by F4/F5. No new extra-biometric fallback was selected.

Kimi

• Finding 1 accepted: multiple phones per Mac/account; fan out to each, consume once, reconcile all; explicit add versus replacement with old-phone revocation.
• Finding 2 accepted: size budgets based on supported platform captures, no truncation, and a distinct Request too large result.
• Finding 3 accepted: verified liveness check at the execution boundary; known no-child outcome differs from started or uncertain execution. Do not claim liveness checks eliminate all races.
• The assertion that every already-defined feasibility gate blocks plan convergence is rejected. A complete plan can specify evidence and failure/consultation paths without performing its future implementation. Planning defects and currently unselected UX policies still block convergence.

User choices

• Cancel, deny-once, and Little Snitch allow-once require no biometrics.
• The default Forever and all reusable rules require biometrics, including timed/session rules.
• The normal request UI is unavailable while the phone is locked; no separate lock-screen use case is requested.
• Preserve pairing after biometric changes where possible, within reason.

No runtime feasibility claim is made. The next round reviews the revised plan and these dispositions.

Independent Plan Review — Remozio revision 3 (2026-09-29)

Scope of review: plan-only, no implementation audit. Assessed internal consistency, key/purpose separation, relay and same-user adversary resistance, command binding, biometric credential release, UI race handling, state-machine completeness, recovery paths, and acceptance coverage. Feasibility items explicitly scheduled as gates (AX capture, single-biometric credential release, descriptor-based execution, sudoers policy, true once-behavior validation) were treated as scheduled work, not defects.

Findings

Finding 1 (Medium) — Multi-phone enrollment cardinality and request routing are unspecified

Sections: 5 (Pairing, transport, and phone lifecycle), 6 (Signed request and state machine), 1 (inbox/per-Mac labels).

Defect: The plan consistently says "an enrolled authorized phone" (§6) and enrollment "binds the phone verification key to the Mac account" (§5), but never states whether one (Mac identity, account) tuple may have multiple simultaneously enrolled phones, or how requests are routed when it does. This is a reachable configuration, not a hypothetical: §5 explicitly permits an administrator to enroll a replacement phone without the existing phone's participation, and nothing requires revocation of the prior phone first (shared-machine or family use, or simple operator error during recovery).

Concrete failure scenario: An administrator enrolls phone B for an account while phone A remains enrolled. Either (a) requests fan out to both phones — the plan's stale-result machinery safely rejects the second approval, but nothing specifies that fan-out is the design, so an implementer could deliver to an arbitrary "most recently enrolled" phone, leaving the primary user with unexplained silent stalls (which §10 product acceptance explicitly forbids); or (b) delivery goes to one phone under an unspecified selection rule, and the lost/stale phone still holds valid signing authority the user believes is dormant. Approval authority over privileged execution then depends on an undocumented routing decision.

Minimal correction: Add one paragraph to §5/§6 declaring the v1 cardinality and semantics. The least-UX-impacting option: multiple phones per (Mac, account) are permitted, every enrolled phone receives each request, and the existing consumption ledger + explicit stale result (§6) handles double-approval — this requires no new machinery. UX flag: the alternative correction — restricting v1 to one active phone per tuple — reduces remote functionality and per the plan's own §1 rule requires user consultation; it must not be silently adopted as the "fix."

Finding 2 (Low) — Over-limit request behavior is undefined, in tension with the no-truncation guarantee

Sections: 6 (explicit byte limits, strict parsing), 1 ("never silently truncated," "long commands remain fully accessible"), 8 (full argv display).

Defect: §6 mandates explicit byte limits and strict rejection of malformed envelopes; §1 mandates that long commands are never silently truncated. The plan never states what happens when a legitimate captured request (e.g., a compiler invocation with a large file list, or a large effective environment under §8's deterministic-environment capture) exceeds the wire limit. macOS argv can reach ~1 MB; any fixed limit is eventually hittable.

Concrete failure scenario: A coding tool submits a command whose canonical payload exceeds the byte limit. With no specified behavior, an implementer either truncates to fit (silently violating §1 and producing an approval bound to a falsified display) or rejects with a generic parse failure indistinguishable from tampering, leaving the caller with a hang or a misleading error. The user cannot tell the request was simply oversized.

Minimal correction: State in §6 that over-limit requests fail closed with a distinct, explicit caller status ("request too large," separate from denied/stale/unavailable per §8), that truncation is prohibited at every layer, and that limits are set and documented to bound realistic worst-case captures (argv + environment + requester row). No UX regression: this adds a clear error where the plan otherwise implies silent or confusing behavior; it adds no confirmations or manual steps.

Finding 3 (Low) — Post-authorization caller death is unspecified

Section: 8 (Command execution adapter); partially mitigated by §8's stage-4 measurement work and "show requester-exited or tool-timeout explicitly."

Defect: §8 binds a request to caller/session lifetime and handles caller exit while pending, and defines disconnect behavior for a started command. The window between phone authorization and exec is unaddressed: if the caller (or its coding-tool harness) exits after the decision is consumed but before execution, the plan does not say whether the command runs with no output consumer or is cancelled post-consumption.

Concrete failure scenario: User approves; the harness hits its own timeout and exits in the approval-to-exec window. Either the approved privileged command executes with results lost and the caller seeing a plain timeout (the phone shows success — a confusing mismatch), or the service cancels after consumption, producing an "unknown" for an action that never had a side effect, muddying the carefully defined state semantics of §6.

Minimal correction: One sentence in §8: caller liveness is re-checked at the execution boundary via the same verified IPC identity; a dead caller at that point consumes the approval as a distinct "requester exited before execution" terminal state (no side effect, reported distinctly on the phone and to any reconnecting caller), never as "unknown" and never as silent execution. No UX change beyond a clearer result.

Items verified as adequately planned (not findings)

• Key separation and relay resistance (§3, §6): authority/transport/adapter-receiving/biometric/decision/credential keys have distinct purposes and custody; decision key is purpose-narrowed, verified at both root and adapter, and cannot mint rule changes, command execution, credential release, or enrollment; acceptance tests cover recipient substitution, relay tampering, and impersonation.
• Biometric policy consistency (§1, §6, §7, §9): the user-confirmed Little Snitch once/cancel exception is correctly confined to the decision key and the captured request; session/timed rules correctly classified as reusable; both root and adapter re-enforce classification independent of button labels; no silent widening to command or 1Password paths.
• UI race handling (§6, §9): consumption-before-side-effect, bounded acknowledgment, permit invalidation on adapter death, no automatic retry, user-initiated Refresh with fresh challenge, and stale-permit acceptance tests form a closed design.
• Recovery (§5): independent admin authentication as the recovery path, no self-healing enrollment, revocation semantics for both phone keys and pending requests, credential invalidation handling.
• Flux licensing (§4): correctly treated as design-reference-only given the absent license; no copying planned.

Tentative UX choices remaining open (explicitly gated in the plan — not defects)

These are scheduled feasibility/user decisions, listed per review instructions so they are not mistaken for convergence: five-minute expiry default (§5, to be validated against measured tool timeouts); encrypted relay/push wake (§5, pending user decision); StrongBox vs. TEE vs. software-key fallback (§4, user decision if fallback needed); single-BiometricPrompt CryptoObject credential release (§7 spike — failure forces a second biometric or weaker protection, both requiring user consultation); 1Password synthetic-typing fallback (§9, user decision); atomic execution vs. documented path-recheck race (§8 gate, user decision); sudoers policy integration choice (§8 gate); optional detached/resumable mode (§8, non-default, user decision); true one-time Little Snitch semantics per app/version (§9, user decision if unsupported). Review convergence under §11 must remain blocked while these are unresolved.

Conclusion

SUBSTANTIVE FINDINGS REMAIN — one Medium (multi-phone enrollment/routing semantics) and two Low (over-limit request handling; post-authorization caller death). All corrections are specification additions; only the single-phone-restriction variant of Finding 1's correction would worsen UX and therefore requires user consultation. No findings demand completed implementation evidence; all flagged platform risks in the plan are already behind explicit feasibility gates.

Independent Plan Review: Remozio implementation plan, revision 3

Scope: Plan-only review of reviews/round-3-plan.md. No tools were used, and no testing, browsing, or source inspection was performed. Platform behaviour is not asserted beyond what the plan states. Where a question is already an explicit feasibility gate, it is not reported as a defect.

Overall: The plan is internally coherent on its core controls:

• authority-signed requests, independently re-verified by the root service and the GUI adapter;
• separate biometric and decision keys;
• a durable consumption ledger with an unknown outcome and no automatic retry;
• full argv rendering and stdin-source disclosure;
• Refresh-based recovery for expired dialogs;
• all three adapters kept in scope.

The remaining findings concern precise scope classification for biometric-free actions, same-user hardening of the GUI adapter, phone-side protections for the non-biometric decision key, and validation coverage for allow-once.

Concrete planning defects

F1 — Medium: GUI adapter compromise is excluded, but no same-user hardening makes that exclusion hold

Sections: §2 (threat model: "malicious unprivileged requesting process"), §3 ("compromise of that signed process is outside the stated assumption"), §10 acceptance list.

Problem: The per-user GUI adapter holds three valuable things:

• Accessibility permission;
• the ability to request dispatch permits;
• plaintext credentials during unlock.

It runs as the same user as the in-scope malicious caller. §2 assumes the "installed signed app" is uncompromised, but the plan never requires the properties that stop a same-user process from subverting it:

• hardened runtime;
• library validation;
• no get-task-allow, disable-library-validation, or DYLD-environment entitlements;
• an administrator-owned install location for the bundle.

Only the transport fallback gets an explicit administrator-controlled directory requirement.

Failure scenario: The adapter bundle lives in a user-writable location, or ships with a debugging or DYLD-tolerant entitlement. A same-user process then injects into it or alters it. It can then:

• receive a certified recipient key for a real unlock request and read the released password; or
• fabricate AX "assertions" that the root service endorses as adapter provenance.

The root service's audit-token and designated-requirement check limits this only if dynamic code validity is enforced and injection is structurally prevented. The plan does not state either requirement.

Minimal correction:

• Require hardened runtime and library validation for the GUI adapter and the frontend.
• Forbid the entitlements listed above in release builds.
• Install the bundle in a root/admin-owned location.
• Have the root service check dynamic code validity on every XPC request, not only at launch.
• Add acceptance tests: same-user dylib/DYLD injection into the adapter fails, and a same-user modification of the bundle fails.

UX impact: None.

F2 — Medium: the "internal bookkeeping" clause weakens the one-time vs reusable classification

Sections: §1 table, §9 ("Internal bookkeeping for the current request does not by itself make an action a reusable rule"), §9 Little Snitch.

Problem: The biometric-free exception depends on the effect being confined to the current request. The plan never defines "current request" operationally. The bookkeeping clause invites classifying some target-app behaviours as one-time when they are not, such as a transient rule matching the same process, host, or port for a period, or until the connection or process ends. Whether Little Snitch's "Once" behaves that way is exactly what §9 says must be validated. The plan should not pre-excuse it.

Failure scenario: An adapter capability mapping marks an action "once" because the app labels it that way. The app actually creates a short-lived internal rule. A malicious caller then makes repeated connections within that window, all covered by one biometric-free allow-once.

Minimal correction: State a testable criterion. A biometric-free decision may affect only the connection attempt(s) captured in that specific alert. Any effect on a later attempt, even briefly or by internal mechanism, counts as reusable and requires biometrics.

Bookkeeping that cannot match a later attempt is harmless and may be ignored. Validate this per app version with a second-connection test. If Little Snitch's one-time option fails the criterion, record it as a feasibility result and consult the user, per §9's existing rule.

UX impact: None if "Once" is truly one-time. If it is not, any change is a user decision, not a silent downgrade.

F3 — Medium: allow-once is missing from the per-version validation rule and from acceptance tests

Sections: §6 ("A target-app cancel or deny-once … must use the dispatch ledger"), §9 ("Cancel and deny-once bypass biometrics only when their actual effect is confined…"), §10 acceptance lists.

Problem: The user-confirmed exception covers cancel, deny-once and allow-once. Two sentences that define the confinement obligation name only cancel and deny-once:

• §9's per-app/version effect validation;
• §6's explicit ledger sentence.

§10 tests that "cancel and true deny-once work without access to the biometric key." It has no test that:

• allow-once works with the decision key; or
• allow-once is confined to the captured Little Snitch request.

There is also no negative test that the decision key is rejected for command execution, 1Password access/unlock, credential release, and enrollment. The acceptance list covers only reusable rules. That leaves the "do not widen to command/1Password" boundary unverified.

Failure scenario: An implementation follows §9 literally. It validates confinement for deny-once but not allow-once. It ships an allow-once path whose true effect was never checked. Separately, a verifier bug accepts decision-key signatures for a command purpose, and no acceptance test catches it.

Minimal correction:

• Add allow-once to the §9 confinement/validation sentence and the §6 ledger sentence.
• Add acceptance cases:
  • Little Snitch allow-once succeeds with the decision key and affects only the captured request;
  • the decision key is rejected, at both the root service and the adapter, for command approval, 1Password access/unlock, credential release, and enrollment;
  • an allow-once signature cannot be replayed onto a different Little Snitch alert.

UX impact: None.

F4 — Medium: behaviour on unrecognized target-app versions is undefined, which affects both security and UX

Sections: §6 ("trusted adapter capability mapping"), §9 ("Validate this effect for each supported app/version"; "Unsupported dialogs retain a visible pending notification and a manual remote-control route").

Problem: Classification relies on a per-version mapping, and target apps update independently. The plan does not say what happens when the observed version, or the AX structure, is not in the mapping. Two readings are possible:

• Fail open: keep using a stale mapping. Biometric-free once-actions may carry an unvalidated effect.
• Fail fully closed: treat the dialog as unsupported. Remote Little Snitch and 1Password handling silently disappears after every app update. That is a reduction in remote functionality.

Minimal correction:

• State that biometric-free classification is never applied to an unmapped version or structure.
• Require read-only detection and notification to continue.
• Record the fallback for actions as a pending user decision. Options include:
  • (a) unsupported with a manual route;
  • (b) available, but all target-app actions require biometrics until the version is validated;
  • (c) another user-chosen option.
• Add an acceptance test for an unknown version.

UX flag: Options (a) and (b) worsen UX (reduced functionality, or extra biometrics). They require user consultation and must not be silently adopted.

F5 — Low/Medium: phone-side protections for the non-biometric decision key are unspecified

Sections: §2 (threat model), §6 (decision key), §7 ("explicit foreground-tap rules"), §9 ("An operator with access to the unlocked phone app…").

Problem: The accepted tradeoff assumes the actor is someone using the unlocked phone app. The plan does not require either of the following:

• that the decision key be usable only while the device is unlocked;
• that the approval activity refuse to show over the keyguard.

It also never states whether other, unprivileged Android apps are in the phone-side threat model. If they are, a single in-app tap on "Allow once" is the only consent, and overlay or tapjacking attacks become relevant. Biometric actions are protected by the system BiometricPrompt; decision-key actions are not.

Failure scenario: An approval activity displayed over the lock screen lets someone holding a locked phone perform a Little Snitch allow-once. Alternatively, an overlay app induces a tap on "Allow once."

Minimal correction:

• Require an unlocked-device constraint on the decision key where the platform supports it. Keep the app from showing approval actions over the keyguard.
• Ignore obscured or overlaid touches on decision buttons, or hide overlays on supported API levels.
• State explicitly whether malicious phone apps are in scope.

UX flag: Requiring device unlock matches the stated flow (notification → details), and the plan already hides content on the lock screen, so it is expected to be neutral. If the user wants lock-screen once-actions, that is a user decision.

F6 — Low: authority request and phone decision fields are conflated in the envelope spec

Section: §6 ("The envelope includes … phone key ID, … action choice").

Problem: The authority creates the immutable request before the phone chooses an action. The authority therefore cannot know which key the user will use (biometric or decision) or which action they will pick. It also cannot know which phone will act, if more than one is enrolled.

Implementations may then diverge. One may bind a key ID in the request and break allow-once. Another may loosely accept any key ID and weaken the key-purpose check.

Minimal correction: Specify two structures:

1. Authority-signed request: request/Mac/account binding, challenge, expiry, payload, and captured action/scope choices.
2. Phone-signed decision: request digest, selected action/scope, signing key ID, key purpose, and phone identity.

Verifiers derive the required key class from the retained action semantics. They then check the signing key's enrolled purpose against that class.

UX impact: None.

F7 — Low: applying a phone-selected scope to the dialog is an unpermitted pre-dispatch mutation

Section: §9 ("Apply and re-read the selected scope on the same verified dialog before dispatch"), §6 (permit and unknown handling).

Problem: Changing the dialog's scope control is itself an external UI action. The plan requires a permit only for the final dispatch. It does not say:

• whether scope application happens under the permit; or
• what happens if revalidation fails after the control was changed.

Failure scenario: The adapter switches Forever to Once, and revalidation then fails. The dialog is left in a Remozio-modified state. A later Refresh captures the modified value as the "existing default," which violates the §9 rule to reflect the user's own defaults. A crash between applying the scope and clicking also lacks a defined outcome.

Minimal correction:

• Perform scope application inside the same one-time permit.
• Treat any failure after the control is changed as unknown.
• Mark refreshed requests whose captured default may be Remozio-modified.
• Add the race to the §10 tests.

UX impact: None.

Tentative UX choices requiring explicit user confirmation

These are not design defects. They are choices the plan makes, or implies, without recorded user consent. §1 says such choices must be listed as pending decisions.

• U1 — Forced re-enrollment on biometric change (§5, §7). "Invalidation on biometric enrollment changes" means that adding a fingerprint or face forces full re-enrollment, including Mac administrator authorization. §1 lists "force repeated enrollment" as consultation-required, and this choice is not recorded as user-confirmed.
  • The plan also leaves a partial state undefined. After invalidation, the decision key, which is not biometric-bound, apparently still works, so once-actions keep working while protected actions fail.
  • The plan should state whether this partial state is intended, and how the app presents it.
  • Invalidation is the more protective option. Relaxing it should not be proposed silently in either direction.
• U2 — Fallback for unknown app versions (see F4).
• U3 — Lock-screen availability of once-actions (see F5), if the user expects it.

Items correctly treated as feasibility gates (not defects)

The following have scheduled user consultation on failure:

• single-prompt credential release (§7);
• descriptor-based or atomic execution (§8);
• sudoers policy compatibility (§8);
• pre-login transport key custody (§3);
• secure-field targeting (§9);
• Little Snitch true one-time behaviour (§9);
• Android background delivery (§5);
• Flux licensing (§4).

Note one interaction: §7's "no authentication grace period" invariant may conflict with the only single-prompt credential-release design. Any time-bound key would count as "weaker key protection" and already triggers consultation, so this is covered.

Conclusion: SUBSTANTIVE FINDINGS REMAIN. F1–F4 are medium; F5–F7 are low or low/medium. U1–U3 need explicit user decisions before convergence can be claimed.

Round 2 disposition

Input SHA-256: c6b6d31763afcf7a276b854da8cabad02ff4828e5dca2debcde31be0acd47479. Both reviews completed with exit 0 and nonempty reports.

Opus

• F1: accept stdin source binding and explicit disclosure. Preserve streaming; do not prebuffer or restrict input.
• F2: accept identical one-time dispatch and revalidation for all external UI actions. Ask the user whether Little Snitch Deny requires biometrics. That UX choice is pending; no automatic temporary-rule substitution.
• F3: accept explicit threat-model limitation for other processes with Accessibility/Automation grants. Do not revoke any existing grants.
• F4: accept dedicated service-account transport and a narrowly scoped service-private transport-key fallback. Preserve stronger credential-recipient protection and independent authority signatures.

Kimi

• Finding 1: accept a bounded GUI outcome watchdog and explicit unknown state after permit consumption. Require old actor reconciliation before resubmitting.
• Finding 2: accept an expired-dialog entry with explicit refresh/recapture. No repeated automatic notifications.
• Finding 3: reject automatic privileged copying as UX-neutral. Program relocation can change path/resource/loader semantics and therefore cannot be an unconditional fallback. Clarify the existing feasibility gate and its required output: actual atomicity guarantees and a user decision on any semantic or security compromise. This is scheduled platform investigation, not an assertion of a working atomic mechanism.

Review convergence remains pending the user's concrete Little Snitch UX choice and another review of the revised plan.

Independent plan review — Remozio round-2 plan

Plan-only review. I did not inspect source, run tests, or browse; all assessment is against the text of reviews/round-2-plan.md as written. Scope assessed: internal consistency, security boundaries (malicious unprivileged caller in scope; root/phone-OS compromise out), platform feasibility assumptions vs. explicit gates, command binding, Android biometric credential release, UI race handling, recovery and remote-coding UX, and completeness of planned validation. All three adapters kept in scope.

The plan is generally strong: threat-model honesty (§2), anti-confused-deputy design (§3), canonical wire format and single-use signatures (§6), biometric binding and transition testing (§7), sudoers policy gate (§8), and race acknowledgment with residual-risk recording (§9) are coherent. Known hard problems (single-biometric credential release, descriptor-based exec, Secure Enclave in background services, 1Password secure-field targeting, push/relay choice) are correctly scheduled as feasibility gates with user-decision fallbacks, and I do not count those as defects.

Finding 1 — Medium: undefined terminal state when the GUI adapter dies between dispatch-permit consumption and actuation

Sections: 3 ("obtains an atomic one-time dispatch permit from the root ledger immediately before acting. If it crashes after dispatch, the result is unknown and the action is not retried"), 6 (state machine; crash semantics defined only for the service after consumption).

Failure scenario: A 1Password unlock is approved. The adapter verifies the signature, obtains the one-time permit (approval now consumed in the root ledger), then crashes before injecting the credential — or crashes after acting but the plan's "crash after dispatch → unknown" only covers the post-dispatch case. The approval is single-use and consumed, so no new permit can be issued; no surviving actor owns the request; §6 defines no transition for "permit consumed, no dispatch report ever arrives." The request has no defined path to succeeded/failed/unknown, conflicting with §1's contract ("The phone reports success, failure, or an uncertain outcome") and §10's acceptance goal of "no unexplained silent stalls."

Minimal correction: In §6, add a root-service watchdog rule: a consumed dispatch permit with no outcome report within a bounded window transitions the request to unknown; because the action may never have happened, the still-present dialog may generate a fresh request requiring new user approval (this is resubmission, not an automatic retry of a consumed action, so it does not violate the no-retry rule). Add the corresponding acceptance case (adapter killed after permit consumption → unknown reported, no silent hang, no replay).

UX impact of correction: none — no extra confirmations or restrictions in the normal path.

Finding 2 — Low: expiry/renewal behavior for persistent UI dialogs is unspecified

Sections: 5 ("permit explicit resubmission"), 6 ("expired [is a] terminal branch"), 9 ("Material changes cancel the old approval and replace it with a new request" — replacement defined only for material changes).

Failure scenario: A Little Snitch alert or 1Password unlock dialog remains open past the provisional five-minute expiry. For command requests, resubmission has a natural initiator (the caller re-runs remozio sudo). For UI requests there is no caller; the adapter still observes the dialog, but the plan never states whether the adapter re-issues a fresh request for a still-present dialog or how the phone initiates resubmission of an adapter-originated request. A user approving at minute 6 gets a stale result with no defined route back to an actionable request, leaving a genuinely pending dialog invisible to the phone.

Minimal correction: In §9 (or §6), state that when a request expires while its dialog is still present, the adapter either re-issues a fresh request subject to §5's per-Mac notification rate bounds, or the expired phone entry offers explicit one-tap resubmission. Either is consistent with the existing state machine.

UX impact of correction: none — resubmission is user-visible and optional; no added biometric or confirmation in the normal path.

Finding 3 — Low: executable-identity TOCTOU has no named fallback if descriptor-based execution proves infeasible

Section: 8 ("File identity/hash checks narrow accidental substitution but are not atomic guarantees… Spike descriptor-based execution on macOS").

Failure scenario: A malicious unprivileged caller (in scope per §2) obtains approval for a caller-writable script, then substitutes content between the pre-execution identity check and execve. The plan acknowledges the race and gates descriptor-based execution — but macOS has no fexecve equivalent, so this spike may well fail, at which point the only stated recourse is the generic §10 rule "feasibility failures require a user-visible decision," leaving a security-relevant default undecided despite an obvious non-UX-worsening option.

Minimal correction: Name the fallback now: on spike failure, the privileged service copies the verified entry executable (or script) into root-controlled storage and executes the copy, with the already-disclaimed transitive-dependency caveat unchanged and the signed payload still displaying the original path. This preserves identical approval UX and converts an open decision into a documented default with a known limitation.

UX impact of correction: none — no command restrictions, allowlists, or added steps (an allowlist would require user consultation; this does not propose one).

Explicitly assessed and found adequately planned (not findings)

• Single-biometric credential release uncertainty — correctly gated with a user-consultation fallback (§7 spike); flagging it as a defect would demand implementation evidence from a draft plan.
• sudoers semantic preservation — explicitly gated with two honest options and installation disclosure (§8).
• Accessibility non-atomicity and residual risk — acknowledged with deliberate race tests and a user-consultation clause rather than silent feature removal (§9).
• Flux licensing — correctly handled: design reference only, no source copying until license resolved (§4), matching the review constraint.
• Denial/cancellation unforgeability-as-approval, replay/expiry/consumption rejection, transport-key separation, relay metadata exposure, and recovery without the old phone — internally consistent across §§3, 5, 6.

Conclusion

SUBSTANTIVE FINDINGS REMAIN — one medium (dispatch-permit crash-window reconciliation, §§3/6) and two lows (UI-request expiry renewal, §§5/6/9; TOCTOU fallback naming, §8). All proposed corrections preserve the normal notification → details → single biometric approval → result flow and add no confirmations, restrictions, or manual steps; none require user consultation under §1's rule. Remaining verification limits: this review cannot confirm macOS/Android API behavior, AX-tree feasibility, or Keystore/Secure Enclave semantics — those remain subject to the plan's own stage-1 gates and later implementation audit.

Remozio plan review: round 2 (revision 2, dated 2026-09-29)

This review covers the plan only. I read no source code, ran no tests, and browsed nothing. The findings below are planning defects that the plan does not already schedule as feasibility gates.

F1: Command stdin content is neither bound nor disclosed (High)

Sections: §1 (full command details required), §8 (paragraphs 1–2, 5), §10 (acceptance tests)

Defect: §8 captures the I/O mode and binds argv, cwd, environment and identity. For many commands, though, the privileged behavior comes from stdin, not argv. The phone shows the command but nothing about stdin.

Failure scenario: A malicious same-user caller runs printf 'evil\n' | remozio sudo -- /bin/sh or ... | remozio sudo -- tee /etc/sudoers.d/x.

• The phone shows a complete-looking /bin/sh or tee <path>.
• The approved root process then runs content the user never saw.
• A coding agent that drives a PTY can do the same through PTY input it controls.

This contradicts the §1 promise that approval shows the actual request. It is also not one of the transitive-effects limitations disclaimed in §2.

Minimal correction (no UX cost):

• Put the stdin source in the signed payload: TTY/PTY owned by caller, pipe, file path/identity, or /dev/null.
• Render it on the phone as "stdin: supplied by caller, content not shown" when it is not a terminal the user controls.
• Add an acceptance test that the stdin mode is rendered and bound.

Optional stronger correction (user decision; worsens UX/functionality): Pre-capture bounded non-TTY stdin before approval and show or hash it. This breaks streaming and long-lived input, so it needs user consultation.

F2: UI Deny/Cancel dispatch is undefined, and Little Snitch Deny can create persistent rules without biometric (Medium)

Sections: §1 (Deny needs no biometric), §3 (dispatch permit paragraph), §6 (paragraph 4), §9 (revalidation paragraph; Little Snitch "Both Allow and Deny decisions bind their exact scope")

Defect 1: persistent Deny rules. §6 says denial uses a transport-authenticated message, needs no biometric, and "conveys no execution authority." For UI adapters, though, Deny means the GUI adapter clicks a control. In Little Snitch, Deny with forever/rule scope creates a persistent firewall rule. That is a behavior-changing action whose scope §9 says must be signed and bound.

Defect 2: no permit or revalidation for deny clicks. The plan defines the dispatch permit and pre-action revalidation only for approvals.

Failure scenarios:

• Stale deny click: A deny arrives after the dialog has been replaced or reordered (§9 already expects queued alerts and reordering). The adapter clicks Deny/Cancel on a different alert or 1Password prompt. This can permanently block an unrelated connection, possibly including the approval transport's own rule.
• Unauthenticated permanent rules: Anyone holding the unlocked phone, without biometric, can create permanent Little Snitch deny rules through a non-biometric message.

Minimal correction (no UX cost):

• UI deny/cancel clicks go through the same root-ledger one-time permit and full revalidation as approvals. A mismatch returns stale and clicks nothing.
• Biometric-free Deny for Little Snitch is limited to the dialog's non-persistent effect, or whatever scope was captured and displayed.
• Add acceptance tests for deny against reordered or replaced dialogs.

Pending user decision (both options worsen UX; do not accept silently):

• (a) Require biometric for Little Snitch Deny with persistent scope. This adds a biometric.
• (b) Disallow persistent-scope Deny from the phone. This reduces remote functionality.
• (c) Accept an unauthenticated persistent deny as a documented residual risk.

F3: Same-user processes with Accessibility or Automation grants bypass the UI adapters, and this residual is undocumented (Medium)

Sections: §2 (malicious unprivileged caller in scope), §9 (intro, Little Snitch "GUI scripting setting")

Defect: §2 says the plan protects against a malicious unprivileged requesting process. For UI requests, that protection only holds if the caller cannot itself drive the target dialogs.

Coding agents usually run inside a terminal or IDE. Users commonly grant those hosts Accessibility or Automation permissions. Enabling Little Snitch's GUI scripting setting, which §9 plans to rely on, removes Little Snitch's own guard against scripted clicks.

Failure scenario: The caller triggers a Little Snitch alert for its own exfiltration connection, then clicks Allow through AX. Similarly, it could press through 1Password access dialogs. The phone approval is bypassed entirely. The plan only describes GUI scripting as "a broad permission" and never states this consequence in the threat model.

Minimal correction (no UX cost beyond disclosure):

• §2/§9 state this residual explicitly: UI-adapter guarantees against a same-user caller hold only if that caller's host process lacks Accessibility/Automation over the target apps.
• Installation reports this and explains how to review the grants. Detect them only where the platform permits; do not assume privileged TCC visibility.

Pending user decision (worsens UX; do not accept silently): Requiring removal of Accessibility grants from terminals or IDEs would reduce existing functionality and needs user consultation.

F4: Pre-login transport key protection has no acceptance criterion if keychain restrictions are unavailable (Low)

Sections: §3 (transport key paragraph; "Command transport starts as a dedicated service without GUI login"; "changed LaunchAgent registration")

Defect: §3 requires the transport identity key to be "code-signing/access-group restricted," ideally Secure Enclave. It also requires command approval without an Aqua login. The validation itself is correctly scheduled as a gate. What is missing is a stated acceptable fallback, so the plan does not say what the gate outcome should be. The text is also ambiguous about whether the transport runs as a dedicated account (daemon) or as a per-user LaunchAgent.

Failure scenario: The spike finds user-session keychain restrictions unavailable before login. With no defined fallback, the implementation either blocks headless command approval or silently falls back to a same-user-readable key, which §3 forbids.

Minimal correction:

• Specify that the pre-login transport runs under a dedicated service account (not a per-user LaunchAgent).
• A key file owned by that account and inaccessible to the logged-in user meets the stated threat model if keychain ACLs are unavailable.
• Record the chosen outcome in the feasibility deliverable.

Assessed without substantive findings

• Signature and digest binding, canonical CBOR, and purpose separation (§6)
• Monotonic expiry and single-use consumption; unknown-outcome handling without retry
• Credential package recipient binding (§3), with the single-biometric release correctly gated (§7)
• Enrollment, remote recovery, and revocation (§5)
• Handling of request switching, rotation and process death during biometric signing (§7)
• Little Snitch rule scope binding; Flux licensing (§4)
• All three adapters kept in scope (§10)
• UX-change consultation rules (§1)

Remaining verification limits

The following remain scheduled evidence gates that this plan-only review cannot confirm:

• Platform feasibility: service management, pre-login XPC and keys, AX targeting of secure fields, single-biometric CryptoObject release, Android background delivery
• sudoers compatibility
• The actual AX trees of 1Password and Little Snitch

SUBSTANTIVE FINDINGS REMAIN

Round 1 disposition (in progress)

Plan input SHA-256: 054111627e474840b68c35b19b2a068ad589f898d8c195325560249de403fd9d. Opus review: claude-code/claude-opus-5-5, exit 0, substantive findings. Kimi review: kimi-code/k3-256k, running.

Opus findings

• F1: accept. Bind the credential-receiving adapter identity to code-signing-restricted non-exportable keys. The root authority authenticates adapter requests and owns consumption records. Test same-user impersonation and credential interception.
• F2: accept option (a). Provide a dedicated unprivileged background transport for commands before GUI login. Keep AX adapters scoped to GUI sessions. Do not impose a GUI-login prerequisite on sudo.
• F3: accept. Show verified requester identity, distinguish frontend identity from upstream caller attribution, and label unverified rationale.
• F4: accept. Use transport authentication for denial/status; biometric signatures grant positive authority only. Constrain cancellation authority.
• F5: accept. Local authorization means authorization verified on the Mac, including independently authenticated remote administrator sessions. Document remote recovery and credential re-entry.
• F6: accept integration tests and timeout configuration, plus explicit requester-exited feedback. No detached-by-default behavior or shorter response window.
• F7: accept. Require a monotonic clock that includes sleep; test sleep beyond expiry.
• F8: accept. Phone computes the digest from the exact canonical payload it renders. Every execution authority recomputes against its retained original.

These corrections preserve the normal interaction count and remote capabilities. No UX-reducing alternative is selected.

Kimi findings and final round status

Kimi review completed with exit 0 and substantive findings.

• Finding 1: accept; consolidated with Opus F1 key custody and request-authority correction.
• Finding 2: accept; apply escaping and field/value separation to every rendered UI field.
• Finding 3: clarify enrollment keys as per (Mac, account) tuple. The original signed account field already distinguished accounts cryptographically, so shared keys alone did not make signatures indistinguishable. Explicit key scoping simplifies enrollment and revocation without changing the approval UX.

All proposed corrections were applied in revision 2. No UX-reducing alternatives were selected. Both round-1 reviewers used the same input hash.

Independent Plan Review — Remozio (round-1-plan.md)

Plan-only review of the document as presented. No source, platform, or implementation claims were verified. I assessed internal consistency, security boundaries against the stated in-scope attacker (malicious unprivileged caller), command binding, biometric/credential release, UI race handling, recovery flows, and remote-coding UX preservation.

Items considered and deliberately not flagged (already explicit feasibility gates, not defects): single-biometric credential release (§7 spike), secure-field targeting vs. synthetic typing (§9 gate), sudoers policy integration (§8 gate), descriptor-based execution (§8 spike), Android background delivery (§5 validation task), macOS service-management API selection (§3 spike), Flux licensing (§4). These are correctly scheduled with user-decision fallbacks.

Finding 1 — Medium: Mac transport identity key custody is unspecified (§2, §3, §5)

Defect: §2 states "Mac authorization keys and enrolled phone public keys live in root-controlled storage," while §3 places "phone transport" in the unprivileged per-user agent. E2E encryption with pinned device identities (§5) requires a Mac-side long-term identity private key wherever the channel terminates. The plan never says which key that is or who may read it, and never states the residual impact of agent compromise.

Failure scenario: If the agent terminates the E2E channel with a key readable by same-user processes, an in-scope malicious unprivileged process can extract it and impersonate the Mac to the phone remotely: present crafted request screens (phishing the user into approving attacker-chosen details submitted in parallel through the real frontend), harvest request-detail confidentiality, and selectively drop/delay requests. The service's independent signature verification prevents execution forgery, but the plan neither states that bound nor rules out the phishing/confidentiality path.

Minimal correction: Add one paragraph to §2/§3 defining the key split (root-held: phone trust anchors, enrollment material; agent-held or service-terminated: transport identity) and an explicit residual-impact statement for agent compromise (no approval forgery due to §3 independent verification; confidentiality/availability/phishing exposure with mitigation). No UX impact — no added confirmations, biometrics, or restrictions.

Finding 2 — Medium: Phone-side escaping rules do not extend to UI-adapter strings (§8 vs. §9)

Defect: §8 mandates unambiguous rendering of newlines, control characters, bidi controls, empty arguments, and non-UTF-8 bytes — but only for command fields. §9 says "treat app-provided UI text as untrusted display data" without requiring the same rendering discipline for adapter-captured strings shown on the phone.

Failure scenario: A malicious unprivileged process controls its own executable name/path and its connection destinations. A process path containing newlines or bidi overrides appears in a Little Snitch request's "executable/process identity, destination host/IP" fields and could inject visually convincing fake lines into the phone detail view (e.g., a forged "benign" destination line), defeating the full-details display guarantee for the adapter where the in-scope attacker has the most control over displayed strings.

Minimal correction: One sentence in §9: the §8 unambiguous-escaping and raw-access rules apply to all phone-rendered fields, including adapter-captured UI strings, process names, hosts, and item names. No UX impact — rendering change only; no added steps.

Finding 3 — Low: Phone signing-key granularity contradicts account binding (§5, §6, §7)

Defect: §7 specifies a "per-Mac EC P-256 signing key"; §5 binds the phone key "to the Mac account"; §6's envelope carries an "account binding." On a Mac with two enrolled administrator accounts (explicitly supported by §3's policy language), a single per-Mac key makes the account binding ambiguous — the service cannot distinguish which account a signature authorizes, and §10's "wrong key/Mac/account rejected" test has no defined semantics.

Failure scenario: Two accounts on one Mac pair the same phone. With per-Mac keys, an approval intended for account A's request is cryptographically indistinguishable from one for account B, weakening the account-binding check the envelope claims to provide.

Minimal correction: Define key granularity as per (Mac identity, account) pair in §7, with the phone key ID in §6 scoped accordingly. No UX impact — one biometric per approval either way; re-pairing flow unchanged.

Verification limits

This review validates plan coherence only. It cannot confirm that Android Keystore, BiometricPrompt.CryptoObject, Accessibility APIs, or macOS service-management APIs behave as assumed — those remain §10 stage-1 evidence gates. Convergence on this plan would not imply platform feasibility is proven or the design is secure in implementation.

SUBSTANTIVE FINDINGS REMAIN

Remozio plan review, round 1

Scope: This review covers only the plan text. I ran no tests, read no source, and browsed nothing. Items the plan already schedules as feasibility gates are not treated as defects:

• privileged installation (§3)
• sudoers compatibility (§8)
• single-biometric credential release (§7)
• descriptor-based exec (§8)
• AX trees and field targeting (§9)
• Android background delivery (§5)

Findings

F1: The Mac-side key that receives credentials is not placed inside a same-user trust boundary (High)

Sections: §2 ("UI details are assertions from an authenticated, signed adapter"), §3 (the per-user agent owns phone transport and the AX adapters), §5 (pinned identities), §7 ("Release a credential only to the paired adapter").

Failure scenario:

1. Commands are protected because the root service verifies the phone's signature.
2. UI requests and credential release are different. Both end inside the per-user agent, which runs in the same user domain as the in-scope malicious unprivileged caller.
3. The plan never says where the agent's pinned transport or adapter signing key is stored, or what stops a same-user process from reading it. Examples would be a user-writable file, the default keychain ACL, or a user-writable LaunchAgent plist that points at a substitute binary.
4. A process holding that key can impersonate the Mac to the phone. It can send a realistic "1Password unlock" request, and after one normal biometric approval it receives the vault password.
5. None of the §10 acceptance tests covers this case.

Minimal correction:

• Generate the adapter/transport identity as a non-exportable key, Secure Enclave-backed where possible, with an access-group ACL that admits only the Remozio team-signed agent.
• Or have the root service hold the key and sign UI requests after checking the agent's audit token and code signature.
• State the residual risk that remains if the agent binary itself is subverted.
• Add these acceptance tests:
  • A same-user process cannot read or use the key.
  • A same-user process cannot originate a UI request.
  • A same-user process cannot receive a credential package.

UX impact: None.

F2: Command approvals depend on a GUI login session, which is unstated (Medium-High)

Sections: §3 (the per-user agent carries phone transport; the service has "no general network listener"), §2 (OS login is out of scope), §10 (the "Mac sleep/logout/reboot" test).

Failure scenario:

1. A remote coding agent runs over SSH, or on a Mac that rebooted after an update and has no GUI login.
2. No Aqua-session agent exists, so no transport to the phone exists.
3. remozio sudo waits until expiry, and the user sees a stall with no explanation.
4. Excluding OS-login and FileVault interception is not the same as excluding command approval without a GUI session. The plan does not say which behavior is intended.

Minimal correction: Specify the session model for the command path and choose one option:

• (a) A background-capable unprivileged transport component, such as a LaunchAgent that can run outside Aqua or a dedicated-user daemon. The UI adapters stay GUI-only.
• (b) Document that command approvals require a GUI login. The frontend then fails fast with a distinct status and a clear message.

UX impact: ⚠️ Option (b) reduces remote functionality and requires user consultation. Option (a) has no UX cost.

F3: The phone does not show the verified caller identity (Medium)

Sections: §3 and §8 capture trusted caller identity and "distinguish verified process identity from caller-provided rationale." However, the §8 display list covers only executable, argv, working directory, target user, and environment changes.

Failure scenario:

1. A malicious same-user process submits a request identical to one the user expects from the coding agent. It could also submit a plausible variant in a different directory.
2. Both requests appear in the inbox, and nothing on screen distinguishes them.
3. The user approves the attacker's request.

Minimal correction:

• Include verified requester identity in the signed payload and in a compact detail row:
  • executable path and team ID
  • PID and parent chain
  • TTY or SSH session
  • Mac user
• Label caller-supplied rationale as unverified.

UX impact: None. This is added information, not an added step.

F4: "Deny needs no biometric" conflicts with every signing-key use requiring biometrics (Medium)

Sections: §1 ("Deny needs no biometric"), §6 (denial is a separate signed purpose), §7 (the signing key requires BIOMETRIC_STRONG for every use).

Failure scenario: One of two things happens:

• Implementers make denial require a biometric, which silently worsens UX.
• Denial is unauthenticated, and no rule says who may cause a denied state.

Minimal correction:

• Denials and status messages are authenticated by the phone's non-biometric transport identity over the E2E channel, not by the approval key.
• The service accepts a denial only through that authenticated path.
• Document that a forged denial can only cause denial of service.
• Apply the same rule to cancellation authority: only the originating caller or an authenticated phone may cancel.

UX impact: None. This preserves the stated UX.

F5: No remote recovery or re-enrollment path for a remote-first product (Medium)

Sections: §5 ("local admin can revoke a lost phone and enroll a replacement"; enrollment uses QR plus a human-verifiable code; a biometric enrollment change invalidates keys), §2 ("Do not require physical proximity after enrollment").

Failure scenario:

1. A user away from the Mac adds a fingerprint, or loses the phone.
2. All per-Mac keys become invalid, and the enrolled credentials become unusable.
3. It is undefined whether "local administrator authorization" includes an admin over SSH or screen sharing.
4. The approval workflow may therefore be unrecoverable until the user is physically back at the Mac.

Minimal correction:

• Explicitly allow enrollment and revocation from any authenticated admin session. Example: sudo remozio enroll renders a terminal QR code plus a verification code over SSH.
• Define re-entry of enrolled UI credentials after key invalidation.
• Network messages alone still cannot enroll a device.

UX impact: This improves UX.

F6: Caller lifetime conflicts with coding-tool command timeouts (Medium)

Sections: §8 ("Bind request to caller/session lifetime… default to normal attached CLI lifetime"), §5 (5-minute expiry), §10 stage 4.

Failure scenario:

1. Many agent harnesses kill tool calls after a fixed timeout.
2. The frontend dies while the user is still reading or authenticating.
3. The request is cancelled, and the approval comes back as stale.
4. From the user's side this looks like a silent failure, and they must re-trigger the command.
5. The effective response window becomes the agent's timeout, not the 5 minutes the plan intends.

Minimal correction:

• Stage 4 must measure the timeout behavior of each targeted caller integration.
• Document or configure longer tool timeouts.
• Show a distinct "requester exited" state on the phone.
• If a detached or resumable mode is desired, list it as a pending decision.

UX impact: Do not "fix" this by shortening the approval window. A detached-by-default mode changes execution semantics and needs user consultation.

F7: The monotonic deadline's behavior across Mac sleep is unspecified (Low)

Sections: §6 ("A trusted monotonic deadline… Clock skew must not extend authority").

Failure scenario: If the chosen clock stops during system sleep, a request created before a long sleep keeps its authority well past its 5-minute intended lifetime. This contradicts the stated invariant.

Minimal correction:

• Require a clock that keeps counting during sleep.
• Or require that a request expires at the earlier of its wall-clock deadline and its monotonic deadline.
• Add this to the Mac sleep acceptance test.

UX impact: None.

F8: It is not stated that the phone computes the digest it signs (Low)

Sections: §6 (the envelope carries an "immutable payload digest"; "Android… signs its canonical digest").

Failure scenario: A relay or agent sends a payload together with a mismatched digest. The phone displays the payload but signs the supplied digest. Service-side verification would catch this only if the service recomputes the digest from its own stored request. For UI requests, the owner of that record is itself unclear (see F1).

Minimal correction:

• State that the phone recomputes the digest from exactly the canonical bytes it parsed and rendered.
• State that the phone rejects any mismatch.
• Add a cross-language test vector for this case.

UX impact: None.

What was assessed without findings

• License handling for the Flux design (§4)
• Replay, consumption, and the uncertain-outcome state machine (§6)
• Argv escaping and raw-byte preservation (§8)
• No-shell execution and redirection semantics (§8)
• Separation of UI revalidation from OCR (§9)
• Little Snitch scope binding (§9)
• 1Password unlock-versus-access semantics (§9)
• Scheduling of all adapters (§10)
• The UX-consultation rule (§1)

These are internally consistent, and the known limits of each are already stated or gated.

Implementation verification limits: The feasibility gates remain unproven. These include:

• CryptoObject credential release
• AX control stability and atomicity
• secure-field targeting
• Android delivery under Doze
• privileged-service installation on macOS 14+
• sudoers policy enforcement

SUBSTANTIVE FINDINGS REMAIN