HomeTrang chủ VisionTầm nhìn
Where the harness is going — two-tier local + remoteHarness đang đi đâu — hai tầng local + remote

VisionTầm nhìn

Sidecar + signed approvals

Today the harness is entirely local — one clone per developer, file-based, offline-first. The next step adds an optional sidecar: a lightweight local server that lets a team share policy, aggregate telemetry, and issue signed gate approvals — without ever becoming a hard dependency.Hôm nay harness hoàn toàn local — một clone mỗi developer, file-based, offline-first. Bước tiếp theo thêm sidecar tùy chọn: một server nhẹ cho phép nhóm chia sẻ policy, tổng hợp telemetry và cấp phê duyệt gate có ký — mà không bao giờ trở thành phụ thuộc cứng.

🏗️
Recommended design: Sidecar + signed approvals. stdlib http.server + urllib client, one justified dependency (cryptography for Ed25519, gated behind the approval seam). No framework, no database — the server writes append-only JSONL, mirroring the harness's own ethos. Thiết kế khuyến nghị: Sidecar + phê duyệt có ký. stdlib http.server + urllib client, một phụ thuộc có lý do (cryptography cho Ed25519, đặt sau seam approval). Không framework, không database — server ghi JSONL append-only, phản ánh ethos của harness.
Core principle — never a hard dependencyNguyên tắc cốt lõi — không bao giờ là phụ thuộc cứng

The server is ADDITIVE. Offline-first is preserved.Server là CỘNG THÊM. Offline-first được bảo toàn.

One clone per dev — unchangedMột clone mỗi dev — không đổi

Each developer keeps their own private harness. The server is a read-aggregate-sign sidecar, not a central gatekeeper. Remove it and the harness keeps working exactly as today.Mỗi developer giữ harness riêng. Server là sidecar đọc-tổng hợp-ký, không phải gatekeeper trung tâm. Bỏ nó đi và harness tiếp tục hoạt động y chang hôm nay.

Server absent → local floor holdsServer vắng → local floor giữ

Every seam degrades gracefully. Policy: fail-safe to last-good local file. Telemetry: local write first, forward is fire-and-forget. Gate: server-down = proceed on local PASS (or cached signed verdict).Mọi seam giảm cấp nhẹ nhàng. Policy: fail-safe về file local tốt nhất. Telemetry: ghi local trước, forward là fire-and-forget. Gate: server ngừng = tiến hành khi local PASS (hoặc verdict đã ký được cache).

Remote can tighten — never loosenRemote chỉ có thể siết — không nới

The remote gate seam runs after the local floor passes. A remote DENY adds a block a developer couldn't lift alone; it can never remove a local block or bypass a local check.Seam gate remote chạy sau khi local floor pass. Remote DENY thêm chặn mà developer không tự gỡ được; không bao giờ xóa chặn local hoặc bỏ qua kiểm tra local.

The three seamsBa seam

One wiring point per concern — each independently optionalMột điểm nối mỗi mối quan tâm — mỗi cái độc lập tùy chọn

Seam 1 — PolicySeam 1 — Policy
fail-SAFEfail-SAFE
artifact_check.load_policy — branch the byte source, not the validation. Remote bytes flow through the same stages: validation as local. Fallback: server → cached file → tracked file. Tampered bytes raise LOUD — never silently revert to defaults. artifact_check.load_policy — rẽ nhánh nguồn byte, không phải validation. Byte remote qua cùng validation stages: như local. Fallback: server → file cached → file tracked. Byte bị giả mạo raise LOUD — không bao giờ âm thầm về mặc định.
Seam 2 — TelemetrySeam 2 — Telemetry
fail-OPENfail-OPEN
trace_log.append_event — local write is first and sacred. Forward is fire-and-forget after success. A forwarded.offset cursor (high-water mark) avoids re-sending without read-modify-write. Server de-dups on (actor, ts, payload_hash). trace_log.append_event — ghi local là đầu tiên và thiêng liêng. Forward là fire-and-forget sau thành công. Con trỏ forwarded.offset (high-water mark) tránh gửi lại mà không read-modify-write. Server de-dup theo (actor, ts, payload_hash).
Seam 3 — Gate approvalsSeam 3 — Gate approvals
fail-OPEN-to-localfail-OPEN-to-local
Local floor runs first — remote is consulted only on a local PASS. Server-down = proceed. In binding mode, a short-lived signed verdict cache prevents a DoS-downgrade (dropping one packet shouldn't relax a gate). binding scope: deploy + ship only. Local floor chạy trước — remote chỉ hỏi khi local PASS. Server ngừng = tiến hành. Ở chế độ binding, cache verdict có ký ngắn hạn ngăn DoS-downgrade (bỏ một packet không nên nới gate). Phạm vi binding: chỉ deploy + ship.
Non-forgeable approvals — Ed25519Phê duyệt không thể giả mạo — Ed25519

The signing key lives only on the serverKhóa ký chỉ tồn tại trên server

Under symmetric HMAC every verifier holds the signing key and can mint approvals — forging is easy and cheap. Under Ed25519 the private key lives only on the server; laptops hold the public key (pinned in remote.yaml verify_key) and can only verify. A developer physically cannot mint an approval their laptop didn't receive from the server.Với symmetric HMAC, mọi verifier giữ khóa ký và có thể tạo phê duyệt — giả mạo dễ và rẻ. Với Ed25519, private key chỉ trên server; laptop giữ khóa công khai (ghim trong remote.yaml verify_key) và chỉ verify được. Developer thực tế không thể tạo phê duyệt mà laptop không nhận được từ server.

Token bindingRàng buộc token

Each approval token binds {actor, stage, plan_hash, exp, nonce}. Single-use — the server tracks redeemed nonces in its append-only store. No replay within the TTL.Mỗi token phê duyệt ràng buộc {actor, stage, plan_hash, exp, nonce}. Dùng một lần — server theo dõi nonce đã dùng trong store append-only. Không replay trong TTL.

Authorization on the server, enforcement localỦy quyền trên server, cưỡng chế local

Who-may-approve-what lives on the server. The local gate only verifies the signature and the binding to this exact plan_hash. Clients enforce; the server authorizes.Ai được phê duyệt cái gì ở trên server. Gate local chỉ verify chữ ký và ràng buộc với plan_hash chính xác. Client cưỡng chế; server ủy quyền.

What a team gainsNhóm được gì

Centralized visibility without centralized controlKhả năng hiển thị tập trung không cần kiểm soát tập trung

Shared verified policyPolicy chung được xác minh

One stage-policy.yaml pushed from the server applies to every developer. Changes are signed-bundle-verified — a tampered policy raises LOUD before it takes effect.Một stage-policy.yaml đẩy từ server áp dụng cho mọi developer. Thay đổi được xác minh signed-bundle — policy bị giả mạo raise LOUD trước khi có hiệu lực.

Fleet telemetry & observabilityTelemetry & quan sát toàn đội

Aggregate skill_run, gate_block, and phase_complete events across the team. See declared-vs-actual deviations at the fleet level, not just per session.Tổng hợp sự kiện skill_run, gate_blockphase_complete toàn nhóm. Xem lệch chuỗi khai báo-vs-thực ở mức toàn đội, không chỉ mỗi phiên.

Signed gate approvalsPhê duyệt gate có ký

A reviewer approves via POST /gate/approve; the server mints an Ed25519 token bound to the exact plan hash. The developer's local gate verifies the token before proceeding to ship.Reviewer phê duyệt qua POST /gate/approve; server tạo token Ed25519 ràng buộc với plan hash chính xác. Gate local của developer verify token trước khi ship.

AFK loop observabilityQuan sát vòng lặp AFK

GET /runs surfaces live AFK loops across the team. /runs/:id/tail streams cursor-paginated trace lines. Stop/restart signals are pull-based — dev machines never open an inbound port.GET /runs hiển thị vòng lặp AFK đang chạy toàn nhóm. /runs/:id/tail stream dòng trace phân trang cursor. Tín hiệu stop/restart là pull-based — máy dev không bao giờ mở port inbound.

Phased rolloutTriển khai theo phase

Each phase is independently shippableMỗi phase có thể ship độc lập

PhasePhase ScopePhạm vi ValueGiá trị
0 — Foundation remote_config.py + remote_client.py + remote.yaml. No server yet.remote_config.py + remote_client.py + remote.yaml. Chưa có server. Zero behavior change — pure scaffolding.Không đổi hành vi — chỉ tạo khung.
1 — Telemetry MVP stdlib server + POST /telemetry + GET /runs. Outbox + cursor forwarder.Server stdlib + POST /telemetry + GET /runs. Outbox + cursor forwarder. Fleet-level telemetry aggregation. Fail-open seam.Tổng hợp telemetry toàn đội. Seam fail-open.
2 — Pull policy GET /policy (ETag) + write-through + signature verify + tamper-LOUD split.GET /policy (ETag) + write-through + verify chữ ký + tách tamper-LOUD. Shared verified policy. Fail-safe to local file.Policy chung được xác minh. Fail-safe về file local.
3 — Remote gate _remote_gate — advisory first, then binding for deploy/ship. POST /gate/approve mints Ed25519 tokens. Signed-verdict cache._remote_gate — advisory trước, rồi binding cho deploy/ship. POST /gate/approve tạo token Ed25519. Cache verdict có ký. Central sign-off with non-forgeable tokens.Phê duyệt trung tâm với token không giả mạo được.
4 — Observability + control /runs/:id/status|tail|commands, loop command-poll → sentinel, optional SSE, HTTPS on LAN./runs/:id/status|tail|commands, loop command-poll → sentinel, SSE tùy chọn, HTTPS trên LAN. Inspect and stop/restart AFK loops. Pure-read dashboard.Xem và stop/restart vòng lặp AFK. Dashboard chỉ đọc.
⚖️ Honest limits — same contract, stronger tamper-evidenceGiới hạn trung thực — contract giống, bằng chứng giả mạo mạnh hơn
  • actor stays attribution (spoofable via env). Ed25519 tokens are a separate, layered signal for remote approvals — not a replacement for actor.actor vẫn là attribution (spoofable qua env). Token Ed25519 là tín hiệu riêng, xếp lớp cho phê duyệt remote — không phải thay thế cho actor.
  • The gate remains a presence gate. Signing adds tamper-evidence, not identity proof. A signed token proves the server issued it — it does not prove the human reviewer was thorough.Gate vẫn là presence gate. Ký thêm bằng chứng giả mạo, không phải chứng minh danh tính. Token có ký chứng minh server cấp nó — không chứng minh reviewer người thật sự kỹ lưỡng.
  • Phase 0–2 require no new dependencies. cryptography (for Ed25519) is gated: required only when the signed-approval seam in Phase 3 is enabled.Phase 0–2 không cần phụ thuộc mới. cryptography (cho Ed25519) được gated: chỉ cần khi seam phê duyệt có ký ở Phase 3 được bật.
  • localhost may stay http. Any LAN host should use https — bearer tokens are integrity-cheap but replay-vulnerable on cleartext LAN.localhost có thể dùng http. Bất kỳ LAN host nào nên dùng https — bearer token rẻ về tính toàn vẹn nhưng dễ replay trên LAN cleartext.
🗺️
Enterprise hardening path (monotonic — no rewrites): bearer + Ed25519-signed approvals on LAN → anchor the server signing key to SSO/OIDC (actor becomes a verified sub claim) → mTLS for mutual machine identity when the server leaves the trusted LAN. Each step adds non-spoofability where it's load-bearing, leaving cheap attribution on the cheap mechanism. Lộ trình hardening doanh nghiệp (đơn điệu — không viết lại): bearer + phê duyệt có ký Ed25519 trên LAN → neo khóa ký server vào SSO/OIDC (actor thành claim sub đã xác minh) → mTLS cho identity máy lẫn nhau khi server rời LAN tin cậy. Mỗi bước thêm không-giả-mạo được ở nơi quan trọng, để attribution rẻ trên cơ chế rẻ.

FAQHỏi đáp

Will the server ever become a hard dependency?Server có bao giờ thành phụ thuộc cứng không?
No. It's an additive sidecar. Remove it and the harness works exactly as today — every seam degrades gracefully: policy fails safe to the local file, telemetry fails open, the gate falls back to the local floor.Không. Nó là sidecar cộng thêm. Bỏ đi và harness chạy y như hôm nay — mọi seam giảm cấp nhẹ nhàng: policy fail-safe về file local, telemetry fail-open, gate lùi về local floor.
Can the remote loosen a local gate?Remote có nới được gate local không?
No. The remote seam runs only after the local floor passes. A remote DENY can add a block a developer can't lift alone — it can never remove a local block or bypass a local check.Không. Seam remote chỉ chạy sau khi local floor pass. Remote DENY có thể thêm chặn mà dev không tự gỡ — không bao giờ xoá chặn local hay bỏ qua kiểm tra local.
Why Ed25519 instead of HMAC?Vì sao Ed25519 thay vì HMAC?
Under HMAC every verifier holds the signing key and could mint approvals. Under Ed25519 the private key lives only on the server; laptops hold the public key and can only verify — they cannot forge an approval the server didn't issue.Với HMAC, mọi verifier giữ khóa ký và có thể tạo phê duyệt. Với Ed25519, private key chỉ ở server; laptop giữ public key và chỉ verify — không thể giả phê duyệt mà server không cấp.
Does signing turn the gate into an authentication gate?Ký có biến gate thành authentication gate không?
No — it stays a presence gate. Signing adds tamper-evidence, not identity proof: a signed token proves the server issued it, not that the human reviewer was thorough. actor stays attribution.Không — nó vẫn là presence gate. Ký thêm bằng chứng giả mạo, không phải chứng minh danh tính: token có ký chứng minh server cấp nó, không chứng minh reviewer kỹ lưỡng. actor vẫn là attribution.
Do I need new dependencies for this?Có cần phụ thuộc mới không?
Phases 0–2 need none (stdlib http.server + urllib). cryptography (for Ed25519) is gated — required only when the Phase 3 signed-approval seam is enabled.Phase 0–2 không cần (stdlib http.server + urllib). cryptography (cho Ed25519) được gated — chỉ cần khi seam phê duyệt có ký ở Phase 3 bật.