← All work
Core productLocal-first automation · Cross-device controlFoundation in development2026–Present

OTask

A safety-first foundation for running approved local workflows without giving the cloud or an AI model unrestricted command execution, with explicit approvals, lifecycle state, and evidence boundaries.

A GUI-first, local-first orchestration platform designed to let trusted desktop devices execute deterministic, policy-approved workflows while mobile and web clients schedule, approve, monitor, cancel, and review work.

Review source ↗

Project brief

The product context, ownership, and current evidence.

Target users

Developers and technical users who need repeatable workspace automation on trusted desktops with controlled cross-device oversight.

Intended buyer outcome

A safety-first foundation for running approved local workflows without giving the cloud or an AI model unrestricted command execution, with explicit approvals, lifecycle state, and evidence boundaries.

Owned scope

Product research · Systems architecture · Desktop/backend engineering · Security and delivery design

Evidence status

P00–P02 and P03-001 through P03-005 are complete with recorded six-job CI evidence. P03-006 SQLite persistence is active local work and is not yet committed or remotely validated.

Problem

Remote task control can become unsafe when cloud services, untrusted AI output, broad shell access, device credentials, and execution evidence are not separated.

Approach

Defined a GUI-only architecture with a Tauri 2 and React desktop, Rust trusted service, versioned TaskPlan contracts, Supabase control plane, Flutter mobile shell, planned Next.js portal, short-lived grants, local credential and key boundaries, and deterministic execution and evidence gates.

Current outcome

Governance, contracts and design system, the Supabase identity and control-plane backend, and the first five desktop-foundation tasks are CI-validated. The desktop has a functional shell plus secure settings, PKCE authentication, device-key and registration boundaries, and authenticated Rust IPC; SQLite repositories are active local work. Workflow execution, scheduling and sync, evidence, full mobile and web clients, interactive terminal, local Gemma runtime, and production release remain future phases.

Maturity & lifecycle

What is complete, active, and still planned.

P00–P02 and P03-001 through P03-005 are complete with recorded six-job CI evidence. P03-006 SQLite persistence is active local work and is not yet committed or remotely validated.

Evidence reviewed

  1. Discovery

    Complete

    The authoritative product boundary, safety model, user roles, and first end-to-end orchestration scenario are documented.

  2. Scope & architecture

    Complete

    Ten ADRs, 14 versioned schemas, 27 fixtures, TypeScript/Rust/Dart mappings, and 22 GUI route-state contracts define the system.

  3. Design & prototype

    In progress

    The desktop shell is built; dashboard data remains demonstrative and the remaining desktop views use explicit empty-state placeholders.

  4. Build & integrate

    In progress

    The Supabase control plane and P03-001 through P03-005 are complete; P03-006 SQLite repositories are active local work.

  5. Verify & launch

    Planned

    The executor, sync and evidence path, complete clients, hardening, signing, cross-device beta, and deployment are future gates.

  6. Handover & iterate

    Planned

    Stable-channel releases, rollback, support operations, and iteration follow the P11 product-acceptance gate.

System map

How the product boundary fits together.

  1. 01

    Plan safely

    Strict versioned TaskPlan contracts, validation, risk classification, approval requirements, and immutable plan identity bound what can run.

  2. 02

    Execute locally

    The trusted desktop and authenticated Rust service form the only intended command-execution boundary.

  3. 03

    Control across devices

    Supabase-backed mobile and web surfaces coordinate identity, devices, schedules, approvals, grants, and state while the cloud never executes commands.

  4. 04

    Prove outcomes

    The planned run lifecycle captures redacted logs, verification checks, artifacts, and finalized evidence before controlled synchronization.

Claim boundary

Constraints and unresolved risks

  • There is no live app, production deployment, signed installer, user or usage outcome, or operating-scale result to claim.
  • Desktop dashboard metrics and activity are static demonstration data; non-dashboard screens are currently explicit placeholders.
  • Web and VS Code packages are logic-free bootstrap surfaces, while mobile is a Flutter shell with authentication tests rather than a complete client.
  • P04 through P11, including actual workflow execution, scheduling, terminal, evidence, local AI, and end-to-end remote control, remain planned.
  • The cloud is control-plane-only and must never execute shell commands; planned Gemma output remains an untrusted TaskPlanDraft until validation and approval.
  • Current SQLite repository work passes local checks but has no commit or remote CI evidence yet; the public default branch remains at the earlier bootstrap state.

Public evidence

What supports this case study

Public source repository

The public MIT-licensed repository exposes the desktop, mobile, web, Rust service, contracts, Supabase, documentation, and delivery evidence.

Verified Open evidence ↗

Authoritative product and safety boundary

The master specification defines trusted local execution, GUI-only control, cloud limits, approvals, grants, TaskPlan contracts, and the planned local-model boundary.

Verified Open evidence ↗

Authenticated desktop service evidence

P03-005 records authenticated Tauri-to-Rust IPC, lifecycle handling, regression coverage, build artifacts, and six successful CI jobs.

Verified Open evidence ↗

Contracts and design-system phase evidence

The P01 exit record covers versioned schemas and fixtures, cross-language mappings, design tokens, and route-state contracts.

Verified Open evidence ↗

Published delivery boundary

The ordered backlog separates completed foundations from executor, cross-device control, terminal, local AI, hardening, beta, and release work.

Verified Open evidence ↗

Engineering highlights

  • ✓Trusted desktops are the only intended command-execution surface; cloud services coordinate but never run the shell
  • ✓Versioned TaskPlan, schema, fixture, risk, approval, grant, cancellation, and evidence contracts
  • ✓Tauri 2 and React desktop backed by an authenticated Rust service boundary
  • ✓Supabase identity and control plane with RLS, device pairing, key rotation, signed grants, terminal signaling, and release metadata
  • ✓Cross-language TypeScript, Rust, and Dart contract mappings for desktop, service, mobile, and planned web clients
  • ✓Planned local Gemma runtime produces untrusted drafts rather than executable commands

Technology and domains

Tauri 2ReactTypeScriptRustSQLiteFlutterSupabaseLocal-firstDeterministic workflows

01 / Trust boundary

Remote control must not turn the cloud or an AI model into an unrestricted shell.

The core architecture separates planning, approval, credentials, execution, observation, and evidence so that convenient cross-device control does not erase local ownership.

  1. 01.1Only an enrolled trusted desktop is intended to execute a validated immutable TaskPlan.
  2. 01.2The Supabase layer coordinates identity, devices, scheduling, approvals, grants, signaling, and state but never executes shell commands.
  3. 01.3Device credentials and signing keys remain behind local secure-storage and authenticated service boundaries.
  4. 01.4Planned local-model output is an untrusted draft that cannot bypass schema, policy, risk, approval, or plan-identity checks.

02 / Cross-platform contract

Desktop, mobile, web, and cloud coordinate through one versioned workflow language.

Shared schemas and state machines reduce interpretation drift across the React/Tauri desktop, Rust service, Flutter client, planned Next.js portal, and Supabase control plane.

  1. 02.1Fourteen versioned schemas and 27 fixtures have TypeScript, Rust, and Dart compatibility mappings.
  2. 02.2Twenty-two GUI route-state contracts define loading, empty, error, blocked, and ready behavior before feature logic arrives.
  3. 02.3Signed short-lived grants and explicit cancellation semantics constrain remote actions and terminal sessions.
  4. 02.4Run, step, log, artifact, verification, and evidence states are designed for deterministic replay and review.

03 / Implemented foundation

The control plane and first desktop layers have evidence; the executor does not yet.

The current status distinguishes remotely CI-validated milestones, active local persistence work, demonstrative UI, and future end-to-end functionality.

  1. 03.1P00 governance, P01 contracts and design foundation, and P02 Supabase identity/control-plane work are complete.
  2. 03.2P03-001 through P03-005 deliver the shell, secure settings, PKCE authentication, device identity and registration, and authenticated Rust IPC.
  3. 03.3P03-006 SQLite migrations and repositories are active uncommitted work and are not presented as remotely validated.
  4. 03.4Actual workflow execution, synchronization, complete clients, interactive terminal, Gemma runtime, hardening, beta, and release remain planned.

04 / Client value

The same boundaries apply to any product that turns intent into consequential automation.

The project demonstrates how to combine cross-platform UX, local authority, cloud coordination, AI assistance, and auditable execution without treating convenience as permission.

  1. 04.1Keep execution close to the trusted resource while exposing controlled remote oversight.
  2. 04.2Turn model suggestions into typed, reviewable plans rather than direct side effects.
  3. 04.3Model approvals, cancellation, idempotency, grants, logs, artifacts, and evidence as product states.
  4. 04.4Advance through narrow, CI-backed milestones with explicit blockers and claim boundaries.

Client relevance

What this evidence can support in a product engagement.

These applications reflect demonstrated product reasoning and the stated maturity boundary—not an unsupported production or client-result claim.

Explore AI-Enabled Product Engineering ↗
  • Design a local-first desktop product with a secure service boundary and controlled cloud coordination.
  • Build cross-device approval, scheduling, monitoring, cancellation, and evidence workflows around trusted execution.
  • Introduce AI assistance through typed drafts, deterministic validation, policy checks, and human approval.
  • Create shared cross-language contracts for desktop, service, mobile, web, and backend clients.
  • Decompose a security-sensitive product into traceable, CI-backed delivery gates without overstating incomplete capability.

Related engineering notes

Related engineering notes

Production-Ready Next.js SaaS ArchitectureReliable AI Features Need Evaluation and Human Review

Have a related product problem?

Define the smallest useful next step.

Book a free consultation ↗Send a project brief