Shadow Clients, Live Updates and Agents

Adapted from textbook chapter 15. Backend replay is only part of a user journey. Client local state, input behavior, rendering, permissions and reconnect can determine whether the feature works.

Complete client journeys

A journey follows user action → local/graph state → backend effects → delivery → rendered result. Pin client and service artifacts, device/runtime and seeded local DB/cache/pending work. Use fresh workspace sessions. Record stable element IDs, accessibility semantics, screenshots and the actual graph activation/release where available.

Surface owns interaction state such as drafts and generations; graph/runtime activation remains outside Surface. Tests reuse that ownership rather than adding another UI-update authority. See Surface verification and Component lifecycle.

Cover offline sends, pending-work persistence, app restart, reconnect, stale caches, permission denial, background/foreground transitions and real notification tap behavior within approved destinations. FFI and renderer versions belong to the artifact vector. Platform-equivalent semantics do not imply equivalent timing or resource use; qualify Android, iOS, browser and desktop independently.

DevTools supplies live-device observations and actions. The target investigation input is Crashlytics plus Reaktor client evidence: a crash, supported ANR or tester report links to the application session, relevant operation trace and bounded journal. Minimum correlation precedes launch; full Shadow reproduction follows it. Screenshots establish pixels, not every behavioral invariant. A replay transcript establishes captured interactions, not unobserved data/effect correctness. Join both to contract assertions and instance diagnostics.

Live-update verification

A clean startup test does not verify a revision transition. Admit work on the old revision, perform the update and test state migration, resource ownership, new admission, stale callbacks and drain/cancellation. Record both old and new artifact/activation identities.

Check pending requests, timers, subscriptions, offline work and native handles across the transition. A stale callback cannot write into a new generation without the declared ownership rule. Mixed client/server revisions need an explicit compatibility contract. Rollback must account for migrated data/schema, not just restoring code. Retain the transition journal and cleanup receipt.

Agent scope and acceptance

An agent proposes a change, selects affected graph scopes and runs the same tasks available to humans. Static dependencies plus observed execution inform an initial test region. Unknown dynamic paths, shared schemas, auth, configuration, serialization and common runtime changes expand that region; absence of observed traffic is not proof of no dependency.

Use a fast stable corpus during editing, checkpoint journeys for a larger change and release profiles for client transitions, real dependencies, load and recovery. Pin base/artifact/runner/assertion versions for every result. A green status must refer to the artifact that was tested.

Acceptance belongs to the product requirement and its approved assertion version. A candidate cannot fix a test by silently rerecording mocks, weakening the comparator, changing expected output or deleting a failing capsule. Oracle changes are separate reviewable actions with provenance.

Use the existing Agent Workspace, Control Plane and Conductor mechanisms for context, plans, findings and receipts. Reaktor Shadow contributes evidence and qualified operations; it does not invent a second agent runner or approval ledger.

Handoff contract

A human or agent receives the exact artifact/base manifest, failed assertion, pre-state/workload/fault recipe, evidence references, observed coverage and current resource/lease status. A UI approval binds to that concrete artifact and plan. Expired authority or changed artifacts require reevaluation rather than reusing an old approval.

The same run contract should work from local CLI, workbench and CI. Hosted CI is an execution location, not the source of verification semantics. Delivery gates define the first complete implementation path.