Skip to content

ROADMAP.md

Latest commit

 

History

History
122 lines (92 loc) · 5.85 KB

ROADMAP.md

File metadata and controls

122 lines (92 loc) · 5.85 KB

Roadmap

embedctl starts as a local-first control plane for embedded Linux appliance development, then expands through explicit runtime profiles and provider integrations.

This roadmap is milestone-gated, not date-gated. A phase is complete when its exit criteria are met and verified on a real target.

Product direction

  • Local-first, generalizable-by-design, AI-native by default.
  • Initial target class: embedded Linux appliances reachable through declared local transports.
  • Implemented visual runtime: embedded Flutter apps running through flutter-pi.
  • Broader scope: declared embedded Linux runtime profiles.
  • Non-goals: generic Linux fleet management, generic Linux desktop Flutter tooling, OTA/fleet update replacement, lab scheduler replacement.

v0.1 — Local Linux target control loop

Goal: make one local embedded Linux target inspectable and safely controllable from a host CLI without lab infrastructure. v0.1 is plan-first for target mutations: it produces machine-readable plans first, then executes only through explicit apply/run/restart approval paths.

Scope

  • Target profiles for local SSH/file-based Linux targets.
  • ADB-like local commands for device discovery, policy-gated shell, file sync plans, deploy/apply, run/restart plan/apply, log descriptors, screenshots, doctor checks, and bugreports.
  • flutter-pi support as one runtime profile, not the default shape of every target.
  • Initial app-adapter boundaries without hardcoding app behavior into core.
  • Safe plan/apply previews for mutating commands.
  • JSON output for automation and concise human output by default.

Candidate commands

embedctl devices --json
embedctl target add
embedctl capabilities --target <id> --json
embedctl doctor --target <id> --json
embedctl deploy --target <id> --mode qa --plan --json
embedctl apply --plan-file plan.json --json
embedctl run --target <id> --mode profile --json
embedctl restart --target <id> --json
embedctl logs --target <id> --follow
embedctl screencap --target <id> --output out.png
embedctl bugreport --target <id> --output evidence.zip --json

Exit criteria

  • A developer can produce, inspect, verify, and explicitly apply a deploy/run workflow for one declared target without hidden mutation.
  • doctor explains missing runtime requirements without mutating the target by default.
  • Mutating deploy/run/service operations produce machine-readable plans first; live execution is explicit and must not be implied by plan verification alone.
  • Logs descriptors, screenshots, and bugreports are written as artifacts with stable paths.
  • No app-specific route, domain object, payload format, host, or hardware name is hardcoded into core.

v0.2 — Evidence and agent UX

Goal: make every QA/debug/profile run reviewable by a human and usable by an AI agent.

Scope

  • Evidence bundle schema inspired by BenchCI, OpenHTF, Avocado, and Playwright trace artifacts.
  • Artifact manifest with hashes.
  • Command transcript in newline-delimited JSON.
  • Release-vs-QA evidence separation.
  • Agent snapshot output for current app/device state.
  • Optional workflow record/replay for repeatable device interactions.
  • Public readiness plan covering real-device smoke, workflow recording, adapter examples, live logs, release bridge absence evidence, and target profiling probes.
  • Launch and steady-state profiling reports for hardware sizing.

Candidate commands

embedctl evidence inspect evidence.zip --json
embedctl evidence diff run-a.zip run-b.zip --json
embedctl bridge snapshot --target <id> --json
embedctl bridge batch flow.json --target <id> --json
embedctl workflow record --target <id> --output flow.json
embedctl workflow replay flow.json --target <id> --json
embedctl profile launch --target <id> --json
embedctl profile steady --target <id> --duration 10m --json

Exit criteria

  • A failed run can be diagnosed from artifacts without manually asking what was on the device.
  • Evidence includes run metadata, target profile hash, command timeline, logs, screenshots, redaction status, and typed verdict.
  • Public docs explain local verification plus opt-in real-device verification guidance without requiring private project context.
  • AI agents can consume --json output without scraping terminal text.
  • Sensitive payloads are never stored in argv, env, logs, evidence, screenshots, or reports.

v0.3 — Provider and lab integrations

Goal: keep the local workflow unchanged while allowing larger teams to plug in existing lab, test, OTA, and measurement systems.

Scope

  • Provider interface for external lab/control systems.
  • Integration candidates: labgrid, Jumpstarter, tbot, LAVA, BenchCI, Robot Framework, pytest, OpenHTF-style records.
  • Power and USB backends such as uhubctl or YKUSH when declared by target profile.
  • Measurement backends such as PyVISA or PyMeasure when declared by target profile.
  • OTA verification hooks for RAUC, SWUpdate, Mender, or balena when a project already uses them.

Candidate commands

embedctl provider list --json
embedctl provider doctor --json
embedctl lab lease --provider <name> --target <selector> --json
embedctl lab release --lease <id> --json
embedctl test run --backend pytest --target <id> --json
embedctl lava export-job --workflow flow.json --output job.yaml

Exit criteria

  • v0.1/v0.2 local commands still work without provider infrastructure.
  • Provider-specific failures are normalized into typed embedctl errors.
  • External systems remain backends; embedctl does not become a labgrid, LAVA, Jumpstarter, BenchCI, or OTA clone.

Backlog governance

  • TASKS.md is the source of truth for local backlog items.
  • GitHub Issues can mirror tasks once implementation starts.
  • Each task should map to a roadmap phase, success criterion, and verification command.
  • Tasks touching device mutation, secrets, release evidence, or provider access must include safety and redaction requirements.