P0: expose typed durable Auto-Dig run lifecycle on Quasar control plane #41

New issue

Open

opened 2026-08-25 04:11:53 +00:00 by lost-rob0t · 1 comment

lost-rob0t commented

2026-08-25 04:11:53 +00:00

(Migrated from github.com)

Consumer: lost-rob0t/starintel-bixby#7
Parent Bixby epic: lost-rob0t/starintel-bixby#1

Discovery

Current Bixby Phase-0/RAGE research finds a typed/versioned Quasar control plane (quasar.control.v1) and UI-side Auto-Dig integration, but no canonical owning run-lifecycle commands suitable for a non-UI external client. Bixby must not automate the UI, edit Auto-Dig state directly, shell out, or talk to CouchDB/RabbitMQ as runtime authority.

Goal

Expose the smallest canonical typed/versioned control-plane surface required for external StarIntel clients to manage durable Auto-Dig runs through Quasar ownership.

Required canonical equivalents, only where the owning runtime can support them correctly:

capability discovery for Auto-Dig lifecycle support;
get overall Auto-Dig status;
get one run by durable run ID;
list bounded/recent runs;
start a run and return a durable run ID immediately without holding the request open for research completion;
pause a run;
resume a run;
stop a run.

Ownership constraints

Quasar/Auto-Dig remains the state/control authority.
Do not add a Bixby-specific protocol or HTTP compatibility shim here.
Do not make frontend component state authoritative.
Do not require Playwright/browser automation.
Do not mutate Git corpus/CouchDB/RabbitMQ directly from the future Bixby gateway.
Reuse the existing typed control envelope, command actor/single-writer model, workspace/run identity, correlation IDs and capability registry where applicable.

Semantics

Start must durably allocate/enqueue a run and respond promptly with its run ID.
Run state must be queryable independently after start.
Pause/resume/stop are idempotent or have explicit stable conflict semantics under retry.
Unknown/stale/cross-workspace run IDs fail closed with stable typed errors.
Capability discovery must let a caller disable unsupported lifecycle actions rather than guessing.
Events/revisions should remain monotonic enough for clients to reject stale state where the current control-plane model supports that.

TDD / security gate

Tests first for:

durable run ID creation before async work proceeds;
duplicate/retried start behavior;
pause/resume/stop transitions and invalid transitions;
run-not-found and wrong-workspace isolation;
bounded list/status responses;
command authorization/capability checks at the owning boundary;
no UI/browser dependency;
no raw internal exception/actor/database leakage in protocol errors.

Run the canonical Quasar + relevant Auto-Dig integration suites on exact head before merge.

Bixby integration boundary

The future starintel-bixby-gateway will translate frozen /v1/bixby/... requests into these canonical Quasar operations. Samsung never speaks quasar.control.v1 directly. Bixby start/stop/pause/resume remain confirmation-gated at the capsule/gateway layer, but backend authorization and lifecycle validation remain mandatory here/upstream.

Consumer: `lost-rob0t/starintel-bixby#7` Parent Bixby epic: `lost-rob0t/starintel-bixby#1` ## Discovery Current Bixby Phase-0/RAGE research finds a typed/versioned Quasar control plane (`quasar.control.v1`) and UI-side Auto-Dig integration, but no canonical owning run-lifecycle commands suitable for a non-UI external client. Bixby must not automate the UI, edit Auto-Dig state directly, shell out, or talk to CouchDB/RabbitMQ as runtime authority. ## Goal Expose the smallest canonical typed/versioned control-plane surface required for external StarIntel clients to manage durable Auto-Dig runs through Quasar ownership. Required canonical equivalents, only where the owning runtime can support them correctly: - capability discovery for Auto-Dig lifecycle support; - get overall Auto-Dig status; - get one run by durable run ID; - list bounded/recent runs; - start a run and return a durable run ID immediately without holding the request open for research completion; - pause a run; - resume a run; - stop a run. ## Ownership constraints - Quasar/Auto-Dig remains the state/control authority. - Do not add a Bixby-specific protocol or HTTP compatibility shim here. - Do not make frontend component state authoritative. - Do not require Playwright/browser automation. - Do not mutate Git corpus/CouchDB/RabbitMQ directly from the future Bixby gateway. - Reuse the existing typed control envelope, command actor/single-writer model, workspace/run identity, correlation IDs and capability registry where applicable. ## Semantics - Start must durably allocate/enqueue a run and respond promptly with its run ID. - Run state must be queryable independently after start. - Pause/resume/stop are idempotent or have explicit stable conflict semantics under retry. - Unknown/stale/cross-workspace run IDs fail closed with stable typed errors. - Capability discovery must let a caller disable unsupported lifecycle actions rather than guessing. - Events/revisions should remain monotonic enough for clients to reject stale state where the current control-plane model supports that. ## TDD / security gate Tests first for: - durable run ID creation before async work proceeds; - duplicate/retried start behavior; - pause/resume/stop transitions and invalid transitions; - run-not-found and wrong-workspace isolation; - bounded list/status responses; - command authorization/capability checks at the owning boundary; - no UI/browser dependency; - no raw internal exception/actor/database leakage in protocol errors. Run the canonical Quasar + relevant Auto-Dig integration suites on exact head before merge. ## Bixby integration boundary The future `starintel-bixby-gateway` will translate frozen `/v1/bixby/...` requests into these canonical Quasar operations. Samsung never speaks `quasar.control.v1` directly. Bixby start/stop/pause/resume remain confirmation-gated at the capsule/gateway layer, but backend authorization and lifecycle validation remain mandatory here/upstream.

lost-rob0t commented

2026-08-25 06:15:09 +00:00

(Migrated from github.com)

TDD realization started in draft PR #43 at exact head a640874c4004a05045fcd2732fdb0009bedb5c0c.

Tests-first only so far. The contract now requires discoverable autodig.status, autodig.run.get, autodig.run.list, autodig.run.start, autodig.run.pause, autodig.run.resume, and autodig.run.stop; immediate durable runId on start; stable request-id idempotency for retries; and workspace-scoped run lookup with autodig.run-not-found on cross-workspace access.

No production handler or Bixby-specific shim has been added yet. CI #730 is currently running and is expected to go RED because main has no Auto-Dig handlers. Next realization slice should consume the real Auto-Dig owning runtime and satisfy this contract at the Quasar actor/control-plane boundary.

TDD realization started in draft PR #43 at exact head `a640874c4004a05045fcd2732fdb0009bedb5c0c`. Tests-first only so far. The contract now requires discoverable `autodig.status`, `autodig.run.get`, `autodig.run.list`, `autodig.run.start`, `autodig.run.pause`, `autodig.run.resume`, and `autodig.run.stop`; immediate durable `runId` on start; stable request-id idempotency for retries; and workspace-scoped run lookup with `autodig.run-not-found` on cross-workspace access. No production handler or Bixby-specific shim has been added yet. CI #730 is currently running and is expected to go RED because `main` has no Auto-Dig handlers. Next realization slice should consume the real Auto-Dig owning runtime and satisfy this contract at the Quasar actor/control-plane boundary.