Let remote agents use canonical Markover

[lastobelus]

Build one opt-in remote-client to remote-canonical path so a remote client can use the canonical host’s single Markover app, review store, settings writer, renderer, and lifecycle authority. The complete accepted design and finite boundaries live in the implementation plan committed in PR #185.

Delivery stack

1. PR Add portable remote review creation and source safety #185 — portable idempotent creation and remote-source safety, based on main.
2. Canonical gateway and trust boundary, based on Slice A.
3. Intel-safe remote author CLI, based on Slice B.
4. Private attachment retrieval and the real two-host pilot, based on Slice C.

Complete when

The four slices land in order and the plan’s real two-host acceptance proves one canonical store, exact tailnet authorization, the Serve-to-socket hop, remote review lifecycle, uncertain-request recovery without duplicate creation or notification, private attachment retrieval, enable/disable, and restart behavior.

The stack excludes Funnel, upload, synchronization, a second store, reviewer routes, generic onboarding, and automated tailnet policy. Implementation plan: https://github.com/lastobelus/markover/blob/main/doc/plans/2026-08-18__remote-canonical-markover.md

[lastobelus]

Slice A landed in PR #185 (297e1199): portable remote-agent review creation, idempotent creation receipts, serialized retry recovery, fail-closed incomplete receipt scans, and remote-source safety are now on main. Exact-head CI passed and the second automated-review round completed with no major issues after the first round’s receipt-scan finding was fixed.

Issue #187 remains In Progress. The next stack step is Slice B: the canonical gateway and trust boundary, based on current main; Slices C and D remain downstream.

[lastobelus]

Work intent

phase: completed
summary: "Slice B merged in PR #188 as d0c12936: https://github.com/lastobelus/markover/pull/188"
touch-points:
  - "src/remote-gateway.ts and focused gateway tests"
  - "src/local-service.ts and ordinary protocol-2 regression tests"
  - "src/main.ts canonical startup, settings, and shutdown coordination"
  - "settings contracts, normalization, IPC, and dialog UI"
  - "DECISIONS.md, privacy page, and developer security reference"
done-when:
  - "the persisted setting controls a live owner-only socket only under a validated non-smoke canonical descriptor and healthy exact markover: handler"
  - "capability authorization precedes route and body handling; only remote health, create/recovery, pending, handoff, edit, revise, and done are reachable"
  - "remote health discloses only protocol, canonical role/scheme, and canonical-host discovery policy"
  - "remote create pins remote-agent, rejects origin claims and attachment metadata, requires healthy routing, is idempotent through the existing mutation core, and returns canonical URLs within request/response bounds"
  - "focused lifecycle, permissions, stale-socket, drain, shutdown, smoke/unset-environment, route, and protocol-2 regression tests pass with the full local gate"
  - "decision, privacy, and developer security documentation describes the reachable default-off ingress"
excludes:
  - "Slice C remote author CLI and HTTPS client"
  - "tailnet policy automation or OAuth driving"
  - "Funnel or direct Tailscale-IP listeners"
  - "reviewer routes"
  - "attachment retrieval or upload"
blocked-by: []
may-block:
  - "Slice C: Intel-safe remote author CLI"
branch: "t3code/work-on-187-slice-b"

[lastobelus]

Work intent

phase: completed
summary: "Slice C merged in PR #190 as 3973e649 after two finding-bearing review rounds: https://github.com/lastobelus/markover/pull/190"
touch-points:
  - "new remote profile, bounded HTTPS client, and restricted creation-journal modules"
  - "scripts/markover.ts command routing, open recovery, discovery policy, and agent-facing help"
  - "packages/cli/src/index.ts bootstrap bypass for configured remote clients"
  - "focused remote transport, journal, bootstrap, and command tests"
  - "tracked code, documentation, fixtures, and evaluation artifacts containing private host names"
  - "pull request and issue bodies, comments, review summaries, and inline review comments containing private host names"
done-when:
  - "the opt-in remote profile resolves before public app bootstrap and command-layer instance resolution, so an Intel remote client neither downloads nor launches Markover nor creates a local store/settings"
  - "the bounded HTTPS client pins an exact HTTPS *.ts.net endpoint, validates markover-remote protocol 1 with canonical role and markover scheme, consumes the health discovery snapshot, rejects redirects, and distinguishes pre-send unavailability from uncertain post-send mutation loss"
  - "normal open, pending, get, edit, revise, and done syntax routes to the canonical host while metadata and permitted session discovery remain local to the remote agent host and returned URLs come from the canonical host"
  - "the owner-restricted journal exclusively creates one active entry, recovers by key before rebuilding, preserves superseded digest history without review body or discovered metadata, auto-recovers own-attempt conflicts, and gives later intentional opens a new key"
  - "no case-insensitive private host-name occurrence remains in tracked repository paths or content, or in editable GitHub pull request and issue text"
  - "focused tests cover Intel bootstrap, all six commands, discovery snapshots, request/response bounds, timeouts, incompatible identity, uncertain create recovery, concurrent identical invocations, digest-history recovery, restart, and zero local app/store creation; the full local gate passes"
excludes:
  - "Slice D attachment retrieval and the real two-host pilot"
  - "reviewer mode, including get-for-review and submit"
  - "attachment upload, review synchronization, or a second store"
  - "Tailscale policy, login, OAuth, or other authentication automation"
  - "Funnel, direct Tailscale-IP listeners, local fallback, or general-user onboarding"
  - "rewriting Git history, changing actual machine configuration, or purging external caches and mirrors"
blocked-by: []
may-block:
  - "Slice D: private attachment retrieval and the real two-host pilot"
branch: "t3code/continue-issue-187"

[lastobelus]

Work intent

phase: completed
summary: "Slice D merged in PR #191 as abff523a after the real two-host pilot, verified CLI attachment downloads, and two finding-bearing review rounds."
touch-points:
  - "remote gateway startup, fixed loopback listener, and challenge-response credential ownership"
  - "remote profile validation, mutually authenticated request transport, bounded clock-skew handling, and creation recovery"
  - "receipt-only uniqueness auditing for parseable invalid v1 artifacts without compatibility reading or migration"
  - "remote gateway handoff projection and instance-scoped attachment HTTPS routes"
  - "focused gateway, service, storage-integrity, transport, startup, and command tests"
  - "promotion note and exact two-host operational acceptance evidence"
done-when:
  - "the canonical gateway binds only to loopback, remains default-off and canonical-only, and shuts down with the owning app"
  - "the exact forwarded Tailscale capability is checked before request handling, the protected shared credential is never transmitted, and a process that occupies the fixed port cannot impersonate Markover, capture the credential, replay a signed mutation, or forge an accepted JSON response"
  - "remote handoff projects only exact checked referenced attachments as five-minute HTTPS URLs bound to the review, attachment, and issuing gateway instance, omits canonical-host paths, leaves persisted and reviewer artifacts unchanged, and the shared client authenticates the returned bytes, MIME type, and checksum"
  - "receipt recovery proves uniqueness from valid artifacts plus the exact receipt slot of parseable invalid v1 artifacts, never returns invalid content, and still fails closed on malformed JSON, headers, managed IDs, receipts, incompatible versions, and unreadable files"
  - "focused tests cover listener takeover, server proof, request and response binding, replay and expiry, restart-scoped attachment access, loopback binding and shutdown, profile and credential modes, traversal, symlink swap, orphan, duplicate and cross-review metadata, checksum and length mismatch, interrupted streaming, unauthorized clients, retry, and bounded cross-host clock skew"
  - "the recorded ten-step two-host acceptance test passes through the real Serve-to-loopback hop on a separate tailnet-only HTTPS port, including deep links, attachment bytes, uncertain recovery, enable/disable, and restart"
  - "the promotion note records the installed Tailscale variant/version proven plus the remaining onboarding constraints"
excludes:
  - "attachment upload or remote create with attachment metadata"
  - "public exposure, Funnel, direct Tailscale-IP listeners, non-loopback local binding, or cross-user collaboration"
  - "review synchronization, source editing, project relinking, or a second canonical store"
  - "prototype review migration or destructive disposition of historical review data"
  - "automated Tailscale policy, login, OAuth, or general-user onboarding"
  - "changing the existing root Serve handler"
blocked-by: []
may-block:
  - "general-user promotion of remote canonical Markover"
branch: "t3code/issue-187-slice-d"
pull-request: 191
head: "3783351"

[lastobelus]

PR #191 merged as abff523a; all four delivery PRs are now on main. The core real two-host path passed through the additive tailnet-only Serve hop: authenticated health and lifecycle operations, canonical-only creation, deep-link activation, human feedback, screenshot handoff, authenticated byte retrieval, edit/get/revise, and an empty pending-review gate. Both review findings were fixed, exact-head CI and automated review passed, and matching Markover reviews were marked Done (zero matched this PR).\n\nIssue #187 remains open because its strict completion sentence also requires recorded live evidence for every adversarial pilot variant. Deterministic tests cover those variants, but the real session did not independently exercise all of third-node/local-account denial, discovery toggle behavior, gateway disable/re-enable/restart, and deliberate post-commit response loss. Those finite live checks are the remaining work; no product implementation or review thread is currently outstanding.

[lastobelus]

Work intent

phase: implementing
summary: "Finish the finite live acceptance evidence left after PR #191 without product changes or Serve reconfiguration. Canonical refresh passed; the user narrowed the unavailable third-node live variant out of completion."
touch-points:
  - "canonical Markover runtime and current main build"
  - "existing additive tailnet-only remote gateway"
  - "remote-client packaged CLI"
  - "redacted issue #187 acceptance evidence"
done-when:
  - "ordinary-local-account denial is exercised live"
  - "discovery disable and re-enable prove each health snapshot governs the following remote command"
  - "gateway disable, re-enable, and canonical restart prove denial while disabled and recovery only with fresh authorization"
  - "deliberate post-commit response loss recovers exactly one review with no duplicate notification"
  - "the packaged remote get-attachment command is exercised live"
  - "redacted reproducible evidence is recorded, the root Serve handler is verified unchanged, Funnel remains disabled, and issue #187 closes only after every check passes"
excludes:
  - "product implementation or compatibility changes"
  - "changing, resetting, or temporarily modifying the existing root Serve handler"
  - "Funnel, public exposure, direct Tailscale-IP listeners, or tailnet policy automation"
  - "printing or publishing exact hostnames, credentials, challenge proofs, or private attachment URLs"
  - "live third-node denial, explicitly waived by the user because no third Mac is available; deterministic authorization coverage remains"
blocked-by:
  - "a privileged read-only Serve status check is required to re-prove the existing root handler and root-level Funnel state"
  - "a deliberate post-commit response-drop mechanism with provable ordering is required"
may-block: []
branch: "t3code/finish-issue-187-live-acceptance"

[lastobelus]

Live-acceptance resumption baseline (redacted)

• origin/main is cleanly resolved at merge commit abff523a5745d6ce0aa6606ae2036bd6d272846f; the acceptance worktree has that exact tree and no tracked or untracked changes.
• Installed Tailscale is Standalone 1.102.2, and its CLI advertises both loopback HTTPS proxying and --accept-app-caps.
• The account-visible additive Serve configuration still has a dedicated tailnet-only HTTPS port targeting exactly http://127.0.0.1:39831; Funnel grants in that visible configuration are empty.
• The live gateway has exactly one listener at 127.0.0.1:39831. Its credential is an owner-only regular file with mode 0600; no temporary credential file is present.
• Canonical doctor is currently unhealthy because its descriptor points to a retired worktree and the running build predates abff523a; the app itself is running and Electron-visible, but its build and markover: handler are stale. No refresh has been attempted yet.
• The separate root-owned Serve handler cannot be inspected from this account: passwordless privileged status is unavailable, while unprivileged status shows only the additive user-owned port. Therefore the root handler and root-level Funnel state have not yet been re-proven unchanged for this pass.
• The finite live response-loss check has no production fault-injection switch. A timed client kill would not prove that persistence/publication preceded response loss; this pass needs an approved response-drop mechanism or must remain blocked on that check.
• Tailnet status currently shows only one online peer besides the canonical Mac, so a distinct unauthorized third-node actor is not presently visible.

No Serve handler was changed or reset, Funnel was not enabled, no review was created, and no credential, proof, private attachment URL, exact machine hostname, or private node identity is included here.

[lastobelus]

Canonical refresh checkpoint (redacted)

• Re-pointed the canonical descriptor to a clean acceptance worktree whose HEAD exactly equals current origin/main: abff523a5745d6ce0aa6606ae2036bd6d272846f.
• The first build attempt stopped before downtime because this fresh worktree lacked Electron package payload files. After repairing only local dependency state, the managed refresh completed.
• Post-refresh canonical doctor is healthy: clean exact-head checkout, current installed application and build, ready service, Electron-visible window, and healthy markover: handler.
• The account-visible additive Serve route remains present as tailnet-only HTTPS and still targets exactly http://127.0.0.1:39831; its visible Funnel grant count remains zero. No Serve command changed configuration.
• The persisted remote-gateway setting is currently disabled, and no process is listening on port 39831. This is the canonical-side setup for the live disabled-denial check; it is not yet a pass until the remote client records the expected failure.
• macOS UI automation could not obtain the Markover window despite doctor reporting electron-visible, so no UI toggle was attempted after refresh.

The root-owned Serve handler and root-level Funnel state remain pending a privileged read-only check. No review was created, no notification fired, and no credential, proof, hostname, private URL, or node identity is included here.