Reaktor Module Execution Plan — Delivering the Astra Vision

Design and task plan · 12 September 2026 · Implementation status: proposed unless evidence is explicitly stated.

Reaktor should turn an unfamiliar idea into a distinctive working application, then make each subsequent change easier to compose, verify and operate. This page translates the Astra master plan into five ranked tasks for each of 69 existing module/build/target units: 37 open Reaktor directories, five closed library/build slices and 27 deployment targets. Eleven supporting matching, knowledge and delivery systems add another 55 tasks: 400 task entries in total.

Read the module review and graph integration strategy for each module's purpose, quality, stability, observed source usage, vision, impact, source evidence and integration design. This page supplies the next work. It is a prioritized target-state register, not a claim that 400 independent projects fit the December release. Several entries describe different owners' contributions to the same integrated result; implement that mechanism once and link its shared evidence.

The master plan owns the north star, support promises, two-developer capacity and calendar. This task plan refines execution without replacing those decisions. Dates and performance targets in that plan remain proposals, not completed milestones. The 12 September follow-up includes the newly extracted reaktor-auth-core and source-intelligence contract reaktor-code, the tooling/native-provider changes, the one-CLI/workspace decision, and the later Service, Tidemark, graph substrate and graph protocol designs.

How to use the plan

Tasks are ranked 1–5 within each module. Each has a stable ID, a delivery horizon, a concrete change and a completion condition. Horizon is not an instruction to start every matching task at once:

The owner is the named module or target boundary, not a person assigned by this document. The two developers choose their implementation lanes and review shared contracts together. Keep one weekly integration target and reserve the master plan's integration/defect capacity. A module contributes vocabulary, implementation, observation, analysis, operation or presentation; it need not add all six at once or introduce a bespoke pane.

Logical workbench modes and product domains remain expanded in the review. They are composition inside engine and app, not additional packages that each need their own graph kernel, execution broker or release program. Their work is routed through the owning module and matching target tasks below.

Traceability to the Astra master plan

The design correction to the first review: lifecycle and wiring repair are necessary, but a universal semantic-kernel rewrite cannot become the prerequisite for making the first real application. Deliver the smallest lawful model and migrate one generated feature plus one existing product feature through it. Equally, creating attractive screens cannot defer state, authority and recovery until after launch. These are two sides of the same integrated slice.

The ten most important integrated work packages

These work packages are the cut order across modules. They collect the most important tasks without pretending every module has equal near-term value.

Recommended recipe decision, not an already accepted product commitment: begin with two related multi-user coordination web classes—membership/discussion and request/approval/task tracking—sharing identity, records, roles, design primitives and one asynchronous integration. Use a native capture/attachment companion to exercise Android and iOS, and capture plus notification as the two candidate capability families. Confirm against held-out briefs, existing usable modules and clean-build evidence before freezing scope. BestBuds contributes failure cases; CompanyOS contributes workflow variety; neither private application is the public reference app.

The existing master-plan milestones remain the envelope: September chooses and integrates the slice; October makes creation/growth dependable; November proves the four journeys and both bounded native cases with external trials; December freezes, qualifies and releases. January–September 2027 promotes additional durability, native support, FFI, protocols, Python and controlled replacement in the plan's dependency order. This document creates no automatic calendar promises beyond that agreed program.

The compact semantic contract to implement first

The graph substrate review identifies important gaps in its illustrative Kotlin specimen. Use its architecture, but do not copy phantom generic keys, unresolved payload references or unfenced cross-partition read sets into production. The following is the proposed first implementable slice:

Implement this on the selected feature, with ordinary algorithms and UI code outside the finite model. Source owns algorithm bodies, composition owns its declared wiring, a store owns its records and a host owns activations. Compact storage, lowering and remote federation can follow evidence; the public API must not require a central graph lookup on every call.

How module contributions combine

Each module's ordinary API and graph adapter share the same implementation. The registration describes owned schemas/facets, required/provided contracts, runtime/profile offers, explicit effects, bounded observations, queries/checks, source mappings and conformance evidence as applicable. It references the common schema/identity system rather than adding a local meaning of “run,” “scope,” or “status.”

The semantic domains definition, activation, observation and derivation are independent of domain layers such as auth, data, media or delivery. For example, notification supplies a definition of intent and route contracts, an activated dispatcher, observations of attempts and responses, and a derived delivery/impact map. A selected filter changes the view; it does not delete the underlying effect or its policy.

Useful combinations follow typed relations: ProductJourney → Interaction → ServiceOperation → OwnedState/Effect → Deployment/Activation → Observation/Check. A second relation family can connect the same entities through required authority or data lineage. Canonical consumer/provider direction, source ownership, exact revisions and completeness survive every projection. Partial external data is a qualified input, not permission to invent a global snapshot.

To mark a task complete, retain its source/contract change, affected consumers, build/target identity, acceptance artifact, assumptions/unknowns and the user or developer outcome improved. A single integrated run may discharge several task IDs. A task is not complete because a node, API stub, menu item, enum value or screenshot was added.

Open framework modules

reaktor-core

Astra: A2, A3, A4, A5. Unlock: one feature behaves predictably in a generated app, a native host and a simulation. Depends on: the compact identity/context ADR; preserve a legacy facade during migration.

1. CORE-1 · D — Own the context. Introduce a host/session context for installed adapters, clocks, randomness and task lifetime; migrate one generated feature and one BestBuds feature. Account changes must not inherit another session's services or state.
2. CORE-2 · D — Make cancellation structural. Parent supervisor jobs to their declared owner and specify close disposition; prove parent cancellation, repeated close and cancellation during acquisition leave no untracked child work.
3. CORE-3 · D — Separate evidence dimensions. Replace health decisions based on TruthClass ordinal/origin with explicit condition, freshness, assurance and scope. Test imported failures, stale successes and partial observations in the same presentation contract.
4. CORE-4 · D — Resolve capabilities explicitly. Separate installed offers, observations, OS permission and principal authority; implement a small rule-based resolver with rejection reasons. Prove capture and notification strategies without weakening either feature's minimum guarantee.
5. CORE-5 · Y — Make adaptation replayable. Record capability-plan inputs, versions and recheck triggers; inject virtual time and permission changes. A fallback experiment must reproduce the same decision and distinguish future rebinding from migration of accepted work.

reaktor-graph-port

Astra: A2, A3, A5, A8. Unlock: one connection supplies wiring, compatibility, impact and generated-language meaning. Depends on: shared contract identity, not a second port-specific ID system.

1. PORT-1 · D — Replace incidental type identity. Define namespaced contract/endpoint IDs and compatibility rules independent of display names and KClass; retain adapters for current ports. Kotlin and TypeScript fixtures must agree across renames and serialization.
2. PORT-2 · D — Commit complete wiring changes. Validate all edges, cardinalities and ownership before publishing a batch. A deliberately invalid final edge must leave the original graph unchanged; readers see complete old or new bindings.
3. PORT-3 · D — Preserve relation meaning. Encode consumer/provider roles separately from invocation and value-flow direction. Round-trip a multiedge example through source, document and runtime projections without reversing impact-analysis semantics.
4. PORT-4 · D — Specify traversal contracts. Add relation filters, cycle/budget behavior, deterministic order and visit multiplicity. The guarded-plus-unguarded-path fixture must find the unguarded route regardless of traversal order.
5. PORT-5 · Y — Earn compact storage. Introduce indexed adjacency/typed tables behind the facade only after benchmarking the reference graph; prove incremental query results equal fresh analysis and preserve IDs, witnesses and unknown coverage.

reaktor-graph-runtime

Astra: A2, A4, A5. Unlock: fast local execution that remains inspectable and can later support a named durable profile. Depends on: CORE-1/2 and PORT-1/2.

1. RUNTIME-1 · D — Separate declaration from activation. Produce a finite binding plan, prepare resources, then publish an owned activation. Inject preparation failure and show the old topology survives with all prepared resources closed.
2. RUNTIME-2 · D — Repair lifecycle admission. Invoke transition effects only for admitted transitions; make child ownership and close deadlines explicit. Add runtime-local tests so the extracted artifact's laws are verified without Compose or BestBuds.
3. RUNTIME-3 · D — Give actors complete identities and outcomes. Include app/environment/tenant/type/key in logical ownership; scope persistence and activation epochs. Start ask deadlines before enqueue and resolve pending asks on close, overload and cancellation.
4. RUNTIME-4 · D — Own state transitions. Add a bounded transition/effect-intent profile with asynchronous completion re-entry. Old-session completions and child coroutines must not mutate current state; keep unrestricted legacy handlers explicitly weaker.
5. RUNTIME-5 · Y — Qualify one durable actor profile. After local laws pass, implement transactional inbox/state/outbox/timers and fenced reactivation on one authority. Crash/replay/passivation tests must preserve one logical result without claiming transparent cross-provider migration.

reaktor-graph

Astra: A1, A2, A4. Unlock: approachable feature composition over the same headless semantics. Depends on: runtime contracts and the UI/editor layer boundary.

1. GRAPH-1 · D — Stabilize the facade. Preserve useful Graph, route, actor and service authoring through the runtime extraction; publish explicit supported imports and a consumer migration fixture with no UI dependency in headless code.
2. GRAPH-2 · D — Describe feature boundaries. Export stable node, route, payload and exposed-port descriptors from one composed feature. Inspecting a route must identify its handler, owned state and required services without reflection-only identity.
3. GRAPH-3 · D — Unify route and authority checks. Validate route payloads, exported dependencies and invocation guards through the same contract checks used by source and editor composition; unauthorized navigation must not bypass the backing operation's enforcement.
4. GRAPH-4 · D — Package a complete feature recipe. Compose sign-in plus a persistent discussion or approval feature with replaceable UI and ordinary lower-level APIs. An unfamiliar app must customize it without copying framework internals.
5. GRAPH-5 · Y — Make local evolution observable. Connect accepted definition patches to prepared runtime activation and epoch changes; show desired-versus-active divergence and recovery when activation fails after a valid document change.

reaktor-auth-core

Astra: A1, A3, A5, A9. Unlock: genuinely dependency-light authorization contracts in public clients and hosts. Depends on: the newly extracted module; token verification remains an adapter responsibility.

1. AUTHCORE-1 · D — Qualify the new artifact boundary. Publish the pure contract/authorizer module and enforce its no-graph/UI/DB/Spring dependency rule. A clean external consumer must evaluate an authorization requirement without the umbrella auth artifact.
2. AUTHCORE-2 · D — Lock down composition laws. Test nested anyOf/allOf, enclosing constraints, delegation, resource scope and tenant-superadmin behavior. No alternative or administrative role may bypass app, tenant, audience or required separate-duty constraints.
3. AUTHCORE-3 · D — Separate claims from trusted authority. Specify which inputs require verified provenance and how grant expiry/revocation is rechecked. A locally constructed AuthContext must never be mistaken for server-authenticated evidence.
4. AUTHCORE-4 · D — Keep credentials out of projections. Define safe metadata/decision DTOs separately from token-bearing AuthorityResolution and token issuance results. Snapshot, serializer and diagnostic fixtures must not disclose access or refresh tokens.
5. AUTHCORE-5 · Y — Publish portable policy fixtures. Version requirement/decision schemas and run the same allow/deny corpus in Kotlin and TypeScript consumers. Add explicit extension hooks for resource-specific authorization without introducing database access into the pure kernel.

reaktor-auth

Astra: A1, A3, A5, A7. Unlock: reusable identity that works through creation, account changes and operated deployments. Depends on: auth-core contracts and service dispatch.

1. AUTH-1 · D — Make installation independent. Offer documented client/server/graph adapters over auth-core with a clear dependency matrix. The public identity recipe must use configurable issuer/provider bindings and build without BestBuds credentials or source.
2. AUTH-2 · D — Enforce at every declared boundary. Connect required authorization to service, actor, query and graph operation dispatch. Exercise a deliberately unguarded path; merely constructing a secured port must not count as enforcement.
3. AUTH-3 · D — Prove session transitions. Cover concurrent refresh, logout, tenant/account switch, revoked credentials and late responses. Old-session state and prepared authority must be rejected across both client and server adapters.
4. AUTH-4 · D — Make authorization explainable. Project requirement, verified principal, decision, policy revision and enforcement point with redacted evidence. A simulation and an actual server decision must remain visibly distinct.
5. AUTH-5 · Y — Test upgrades and delegated agents. Add versioned policy/provider migration and bounded delegation fixtures; an agent run can only receive a narrowed grant, and rotating a credential invalidates relevant sessions/plans without widening scope.

reaktor-service

Astra: A1, A2, A4, A8. Unlock: one business contract composes across direct, HTTP, asynchronous and later native bindings. Depends on: PORT-1 and the selected auth context.

1. SERVICE-1 · D — Publish operation descriptors. Generate stable contract/method IDs, request/result/error schemas and source mappings for the existing request path. An ordinary Kotlin or TypeScript consumer must call the public recipe without understanding graph internals.
2. SERVICE-2 · D — Carry invocation semantics. Add operation identity, total deadline, principal/tenant, attempt and explicit completion outcome. Distinguish refusal, domain rejection, transport failure and unknown external outcome in the reference flow.
3. SERVICE-3 · D — Share the enforced dispatch chain. Use the same authorization, tracing and retry-eligibility contract for local and HTTP bindings. Tests must detect a route that bypasses an obligatory interceptor and a non-idempotent retry.
4. SERVICE-4 · Y — Add interaction shapes incrementally. Implement one bounded subscription/stream and one durable-job handle from the Service design; declare credit, cursor, cancellation and completion separately from ordinary response success.
5. SERVICE-5 · Y — Qualify substitution. Run one conformance suite against in-process, Worker/JVM and later FFI providers. A planner rejects substitution when ordering, durability, latency or failure assumptions differ from the feature's requirements.

reaktor-io

Astra: A1, A3, A4, A7. Unlock: capture, transfer and offline behavior become inspectable reusable effects. Depends on: host ownership and service operation IDs.

1. IO-1 · D — Make unsupported serialization explicit. Implement the selected binary serializer path or reject it at capability selection; add independent round-trip/malformed-input fixtures so a generated app cannot reach a surprise TODO.
2. IO-2 · D — Own resources and budgets. Define file/socket/HTTP handle lifetime, byte limits and cancellation cleanup. Prove no surviving connection or file handle after session close or transfer cancellation.
3. IO-3 · D — Preserve transfer identity. Model one upload/download/share intent with separate attempts and progress; reconnect must reconcile the same operation and preserve account scope instead of silently creating a second effect.
4. IO-4 · D — Publish transport capability profiles. Expose connection state, ordering, retry/resume support and permission/failure reasons. A WebSocket reconnection must not be advertised as recovered durable history without a validated cursor.
5. IO-5 · Y — Add bounded graph observation. Project resource/endpoint/transfer summaries with provenance and declared sensitive reads; keep byte bodies outside resident topology and correlate boundary cost with performance evidence.

reaktor-db

The Data layer reading map owns this module’s detailed design. Current storage and implementation gates supersede old data inventories and fixed plans; Queues and Workflows defines the cloud execution profile.

Astra: A1, A4, A5, A7. Unlock: generated products can grow without losing data or duplicating effects. Depends on: Service contracts and the Tidemark/data-graph design.

1. DB-1 · D — Declare authority and capability. Describe the reference schema, write owner, transaction profile and logical-to-physical bindings. A feature must not treat ObjectDB, a graph projection and PostgreSQL as interchangeable authorities.
2. DB-2 · D — Qualify one transactional command. Commit domain state, operation deduplication and outbox intent together on the selected backend. Inject lost acknowledgement, retry and crash; one logical command must have one recorded domain outcome.
3. DB-3 · D — Make schema growth repeatable. Provide clean bootstrap and forward-migration artifacts, compatibility checks and restore evidence for the public recipe. A held-out growth request must preserve existing records and tenant separation.
4. DB-4 · Y — Turn snapshots into explicit offline semantics. Keep snapshot backup distinct; implement one account-scoped intent/conflict protocol with tombstones, source versions and reconnect authority checks before generalizing sync.
5. DB-5 · Y — Expose useful bounded data maps. Register schemas, queries, lineage, migration impact and projection watermarks. Use qualified named-query/inspector policies; a regex guard must not establish arbitrary Cypher authorization or a global cross-store snapshot.

reaktor-secrets

Astra: A3, A5, A7, A9. Unlock: the same recipe can run locally and remotely without embedding credentials. Depends on: authority contracts and operation planning.

1. SECRETS-1 · D — Separate references from values in the API. Make generic manifests, graph facets and plans accept scoped references only; restrict value resolution to effect execution. Serialization and error fixtures must not leak secret material.
2. SECRETS-2 · D — Qualify one local and one hosted provider. State read/write/version capabilities explicitly and verify missing, denied, unavailable and rotated cases. An unsupported write must remain unavailable rather than falling back to an unsafe store.
3. SECRETS-3 · D — Bind resolution to authority and environment. Require the operation's principal, target and allowed secret scope; a development plan must not resolve a production reference through an inherited process environment.
4. SECRETS-4 · Y — Make rotation dependency-aware. Project consumer links and version changes, invalidate affected prepared plans and re-establish sessions. Verify old credentials cannot be reused after the declared revocation boundary.
5. SECRETS-5 · Y — Add lifecycle evidence. Record redacted resolve/rotation outcomes and cache expiry without storing values in receipts. Test restart, refresh races and owner close against provider-specific availability limits.

reaktor-security

Astra: A4, A5, A8. Unlock: a separately qualified confidential messaging capability. Depends on: secure storage and a resolved product threat model; outside December's stable encryption claim.

1. SECURITY-1 · C — Define the supported threat and feature boundary. Decide how encrypted content interacts with current server moderation, bots, search and backups. Publish allowed combinations and explicit unsupported claims before presenting an encryption toggle.
2. SECURITY-2 · C — Complete platform secret boxes. Implement the selected Android/iOS/JVM protection profiles and lifecycle/error contracts; exercise lock, revocation, missing key and restore behavior rather than equating an interface with secure persistence.
3. SECURITY-3 · C — Persist MLS protocol state correctly. Resolve the native snapshot/serializer gap; test crash/restart, membership changes and epoch transitions against an independent corpus. A key epoch must remain distinct from a graph activation epoch.
4. SECURITY-4 · C — Qualify the native boundary. Fuzz envelopes and run ABI/ownership/leak checks for the supported build matrix. Close must fence callbacks and release native resources without relying on Kotlin exceptions to contain native faults.
5. SECURITY-5 · C — Integrate metadata and one product journey. Expose group/device/protocol version and assurance references while excluding keys/plaintext; qualify send, offline recovery, removal and history policy before upgrading quality or stability claims.

reaktor-cloudflare

Astra: A1, A4, A7, A9. Unlock: a deep, reproducible edge deployment recipe. Depends on: service/auth/data contracts, with provider-specific semantics retained.

1. CF-1 · D — Publish typed binding descriptors. Describe Worker/service/DO/storage bindings with source revision and host capability limits. Missing bindings or mismatched contract versions must fail the recipe's validation before invocation.
2. CF-2 · D — Qualify the public service boundary. Run real auth, tenant, request/error and cancellation/host-lifetime cases for the chosen Worker recipe. A configured endpoint must not be marked observed or healthy until a scoped probe succeeds.
3. CF-3 · D — Implement the selected durable handoff. Connect authoritative commit to a queue/DO consumer with deduplication and explicit acknowledgement. Test retries, poison work and partial effects without claiming global ordering or exactly-once business execution.
4. CF-4 · Y — Register distinct host profiles. Keep Worker request, DO-owned aggregate and scheduled/queue work as separate execution profiles. The same actor/Service contract can bind only when its state, interleaving and lifetime requirements are met.
5. CF-5 · Y — Unify deploy-to-runtime evidence. Link manifest and artifact digests to deployed version, invocation and provider outcome; use these records for impact, drift and recovery across cloud, telemetry and the workspace host.

reaktor-google

Astra: A4, A7, A9. Unlock: a qualified cross-service event adapter without inventing a second messaging model. Depends on: operation/event identity and explicit subscription ownership.

1. GOOGLE-1 · C — State the actual support matrix. Publish supported JVM/JS Pub/Sub operations and explicit native unsupported results; remove any implication that shared API declarations establish Android/iOS delivery support.
2. GOOGLE-2 · C — Specify publish and acceptance semantics. Carry original event/operation identity, payload schema, topic and attempt. Test accepted publish separately from consumed message and completed business effect.
3. GOOGLE-3 · C — Qualify acknowledgement and recovery. Exercise redelivery, ack timeout, poison messages and configured ordering scope using a dedicated environment and deterministic fixtures. Retention and retry limits belong in the adapter profile.
4. GOOGLE-4 · Y — Make bridges preserve meaning. Bridge one declared Pub/Sub and edge-queue path with origin IDs, loop prevention and duplicate policy; order-sensitive state must have an explicit sequencer rather than assume transport equivalence.
5. GOOGLE-5 · Y — Add topic/subscription maps. Project source bindings, observed lag/coverage and dependent handlers with redacted credential references. A failed inventory read must yield partial/unknown coverage, not an empty healthy topology.

reaktor-work

Astra: A1, A3, A4, A7. Unlock: truthful asynchronous and offline user journeys. Depends on: owned scopes and the selected DB/effect completion protocol. The Work architecture selects Meeseeks removal and direct platform profiles; the authenticated delivery roadmap owns migration and acceptance. WORK-1–5 below remain the cross-module priority summary. Current runtime code is still the legacy facade.

1. WORK-1 · D — Remove the vendor and false successful work. Inventory and migrate Meeseeks callers, stores, native registrations and tests; remove its dependency after direct bootstrap and store cutover. Implement required media/sync/notification effects or report unsupported. Acceptance must prove the named effect.
2. WORK-2 · D — Separate state, attempts and wakeups. Define graph-owned WorkStore, WorkRuntime and WorkScheduler with versioned definitions/payloads and scoped operation identity. Distinguish durable acceptance, OS-deferred eligibility, running, handoff, acknowledged result and unresolved outcomes.
3. WORK-3 · D — Qualify durable transitions. Use the authoritative Reaktor store/outbox for atomic admission, indexed claims, monotonic fences, checkpoints and completion. Prove restart/reconnect/logout and stale claim recovery cannot redirect authority or repeat a completed logical effect.
4. WORK-4 · D — Qualify all selected profiles. Use direct Android WorkManager and iOS BGTaskScheduler plus native transfer support; qualify browser realm/storage and event lifetime, Cloudflare Workflows/Queues/PubSub and Spring Quartz/queues/PubSub. Persist capability/defer outcomes; no closed-browser or mobile deadline guarantee.
5. WORK-5 · Y — Join work to runtime evidence. Project definition/operation/attempt/fence/checkpoint/provider receipt and scenario controls through the same scoped API. Coordinate domain, broker and Workflow retry ownership; reuse DB/effect completion and bounded inspection.

reaktor-notification

Astra: A1, A3, A4, A7. Unlock: one reusable reminder/engagement feature with honest fallback. Depends on: work, auth, route contracts and provider outcome semantics.

1. NOTIFY-1 · D — Version the complete intent. Describe category, action, route payload, recipient scope and logical operation identity; validate route compatibility before scheduling and reject stale account/session actions.
2. NOTIFY-2 · D — Prove two valid strategies. Select native/server delivery or a declared weaker in-app alternative only when the product permits it. Permission revocation must invalidate the plan; a badge must not satisfy an outside-app alert requirement.
3. NOTIFY-3 · D — Qualify delivery transitions. Test token rotation, duplicates, disabled preferences, retry and native background behavior. Separate provider acceptance, device receipt and user action in both API and graph evidence.
4. NOTIFY-4 · D — Make rebinding safe. Preserve intent identity when changing provider or endpoint, and reconcile an already-dispatched attempt before retrying elsewhere. Show the unresolved state when delivery cannot be established.
5. NOTIFY-5 · Y — Package the full-stack recipe. Join scheduling, endpoint policy, cloud dispatcher, deep link and product outcome with fixtures and observability; a new app must adopt it with replaceable presentation and no BestBuds-only setup.

reaktor-location

Astra: A1, A3, A5. Unlock: location-aware products that can explain unavailable and uncertain context. Depends on: capability/permission contracts; sensitive readings remain scoped.

1. LOCATION-1 · C — Complete the observation value. Add timestamp, accuracy, source/provider and coordinate-system semantics to coordinates; qualify unknown/stale observations so missing context is never represented as a precise zero location.
2. LOCATION-2 · C — Own acquisition lifetime. Test repeated callbacks, request cancellation, permission changes and session disposal on supported devices; one-shot requests must have one terminal result and no retained delegate after close.
3. LOCATION-3 · C — Define meaningful fallback. Distinguish precise, coarse, manually chosen and unavailable location. A feature must explicitly accept a weaker precision/privacy profile before the resolver selects it.
4. LOCATION-4 · Y — Link geography to the right semantics. Project location-source capability and bounded geographic references for events/matching; physical coordinates must not alter software-topology layout or grant general graph readers personal location access.
5. LOCATION-5 · Y — Prove one portable product case. Use a consented event or field-capture journey across native and web/manual paths; record quality, permission and battery/latency evidence before promoting advertised support.

reaktor-sensors

Astra: A3, A5, A8. Unlock: reusable contextual streams and bulk-data workloads. Depends on: host/session lifecycle and observation schemas; GymBuddy is the proving consumer.

1. SENSORS-1 · C — Preserve reset provenance. Version sample/baseline/session identifiers and time/reset metadata; test reboot, sensor restart, midnight and counter wrap against independent expected totals.
2. SENSORS-2 · C — Qualify native ownership. Exercise registration/unregistration, permission changes and background/foreground transitions on Android and iOS; denied or missing measurements must remain distinct from a valid zero.
3. SENSORS-3 · C — Bound the stream. Declare sampling, buffering, loss/conflation and byte limits; slow consumers must not create unbounded retained samples or block the device acquisition path.
4. SENSORS-4 · Y — Join health with explicit rules. Feed observations into the health merge through a versioned source-quality contract; verify overlapping devices and stale data cannot silently double-count activity.
5. SENSORS-5 · Y — Expose aggregate evidence and measured bulk paths. Link device/session/schema to bounded summaries and profiles; use FFI/FlexBuffer batching only if end-to-end CPU, memory or energy measurements justify it.

reaktor-health

Astra: A3, A5, A7. Unlock: qualified health capabilities that other features can consume without platform guessing. Depends on: sensor provenance and consent-aware storage boundaries.

1. HEALTH-1 · C — Make merge policy explicit. Version the store-versus-sensor preference and zero/missing fallback rule; use fixtures for stale sync, genuine zero, partial days and timezone boundaries.
2. HEALTH-2 · C — Qualify the real provider matrix. Test Health Connect/HealthKit availability, read/write permission changes and unsupported data categories separately; local merge tests cannot establish provider access or device accuracy.
3. HEALTH-3 · C — Scope observations to consent and purpose. Return provenance, freshness and allowed use with bounded aggregates; revocation and account changes must stop reads and invalidate retained capability plans.
4. HEALTH-4 · Y — Compose one useful user journey. Combine health, sensors, storage, work and notifications in GymBuddy with user-visible degraded states; prove meaningful reminder/progress behavior before generalizing additional metrics.
5. HEALTH-5 · Y — Make evidence inspectable without exporting records. Register provider/schema/consent/merge-policy and test references in the graph; keep raw health records outside the general development graph and measure read/merge overhead.

reaktor-media

Astra: A1, A3, A4, A8. Unlock: a real capture/upload feature for generated web and native apps. Depends on: IO, auth, work and asset authority.

1. MEDIA-1 · D — Complete one capture-to-asset recipe. Connect camera/gallery/browser upload to an owned asset reference and persisted product record; the public example must use real handlers and survive restart.
2. MEDIA-2 · D — Declare supported offers. Describe capture/pick/transform/speech capabilities separately; keep empty speech APIs unavailable. Prove native camera and browser upload satisfy the same chosen product outcome with explicit permission/fallback behavior.
3. MEDIA-3 · D — Enforce transfer and publication boundaries. Apply authenticated upload, format/size checks, staged object publication and orphan cleanup. Cancellation or a failed metadata commit must not be reported as a successfully attached asset.
4. MEDIA-4 · Y — Add cache and moderation lineage. Link source asset, transformation, moderation policy, cache version and consumers; deletion/model changes must invalidate the appropriate derived objects and views.
5. MEDIA-5 · Y — Optimize one measured boundary. Profile a real image/audio workload, then qualify batching/native processing with explicit buffer ownership and cancellation. Preserve the conventional path as an independent correctness reference.

reaktor-telemetry

Astra: A2, A4, A5, A10. Unlock: diagnosis follows the actual operation through every joined module. Depends on: definition/activation and operation identities.

1. TELEMETRY-1 · D — Own instrumentation lifecycle. Return a disposable installation handle; attach to new activations and detach on removal/close. Tests must verify ended spans and no surviving subscriptions after graph shutdown.
2. TELEMETRY-2 · D — Repair causal context. Propagate the correct span context through nested nodes, service calls, actor completions and queue attempts; use explicit links for multiple causes rather than forcing every event into a parent tree.
3. TELEMETRY-3 · D — Trace the release journey. Correlate UI intent, operation, authoritative commit, external attempt and observed outcome with exact artifact/epoch; diagnose an injected lost response without confusing an older successful run with current health.
4. TELEMETRY-4 · D — Bound disclosure and cost. Define sampling, payload/redaction, retention and coverage metadata; a missing span must be distinguishable from an unexecuted operation, and sensitive content must not enter general agent context.
5. TELEMETRY-5 · Y — Make traces reusable evidence. Map recorded traces to scenario inputs, contract obligations and profiles; invalidate incompatible evidence on schema/policy changes and measure the overhead of enabled probes.

reaktor-performance

Astra: A1, A5, A8, A10. Unlock: optimizations earn promotion by improving a real creation or runtime task. Depends on: exact workload, artifact and target identity.

1. PERF-1 · D — Capture the first-app baseline. Measure cold setup, first preview, authenticated persistence, follow-up change and deploy/export. Report model/build cost and intervention alongside elapsed time; do not substitute compiler speed for a usable app.
2. PERF-2 · D — Enforce a small budget set. Reuse report models for build/startup/artifact/memory and selected journey latency; attach target/toolchain/revision metadata and distinguish missing measurements from passing budgets.
3. PERF-3 · D — Measure graph overhead. Benchmark wiring, scoped queries, semantic zoom and telemetry on representative nested graphs; compare disabled/baseline/enabled paths and verify optimized output equivalence.
4. PERF-4 · Y — Qualify polyglot improvements. Report scalar/record/bulk boundary cost, copies, allocations, retained bytes and cancellation under release builds; evaluate FFI/codec changes against a complete workload and independent output oracle.
5. PERF-5 · Y — Run composition ablations. Compare recipes, graph context, capability selection and simulation separately and together on matched tasks. Retain uncertainty and regressions so a more-than-additive benefit is measured rather than inferred from module count.

reaktor-flexbuffer

Astra: A2, A5, A8. Unlock: efficient inspectable values and qualified cross-language data exchange. Depends on: shared wire/schema identities and FFI ownership contracts.

1. FLEX-1 · D — Put validation at trust boundaries. Fix the October valid-empty-map rejection and required-field/layout misread repros; provide a clear validated entry path before unchecked readers and an independent schema proof. Fuzz malformed widths, offsets, nesting and lengths. Retained/mutable buffers must not invalidate the assumptions after validation.
2. FLEX-2 · D — Version layout and value semantics. Fix explicit-null/default and equal-map hash repros. Generate fingerprints, required/default/null semantics and keyed fallback; reject unsupported shapes at compile time. Run cross-language golden fixtures including lossless 64-bit values.
3. FLEX-3 · Y — Unify buffer ownership. Define caller-owned, borrowed, retained and copied paths with release responsibilities; test pooled-buffer reuse and async retention so a view never outlives its bytes.
4. FLEX-4 · Y — Separate flexible, record and bulk lanes. Turn the physical Android public-ByteBuffer experiment into measured production kernels with per-type thresholds and release-APK checks. Qualify native/compiler specialization end to end. Prototype the book's mutable cells/slabs/handles separately from immutable wire snapshots; measure traversal, mutation and retained memory before adoption.
5. FLEX-5 · Y — Prove consumer value. Replace one actual product/FFI bottleneck with the supported lane; retain equivalent outputs and publish end-to-end latency, allocation, copy and memory evidence across the claimed targets.

Evidence and detailed priorities: October performance/stability review, implementation, and the complete From Bytes to Mutable Memory book.

reaktor-ffi

Astra: A3, A4, A5, A8. Unlock: new language/compute reach through the same module and capability contract. Depends on: SERVICE-1, FLEX-1/2 and activation ownership; experimental at December launch.

1. FFI-1 · D — Freeze one honest call profile. Specify contract, implementation, endpoint, call, buffer and activation identities; select Kotlin/JVM↔C++ unary first and expose all unfinished transports as unsupported.
2. FFI-2 · Y — Complete generated dispatch. Replace transport and argument-decoding TODOs for that profile; reject unsupported fields at generation and negotiate schema/ABI versions before invoking native code.
3. FFI-3 · Y — Prove ownership and shutdown. Implement the fixed-width C-facing ABI, retain/release rules, executor affinity and close barrier; use fuzzing/sanitizers and late-callback/cancellation tests before promoting a boundary.
4. FFI-4 · Y — Add bounded asynchronous semantics. Qualify one streaming shape after unary conformance; define item/byte credit, independent completion, late frames and reserved cancellation capacity so a full data queue cannot prevent shutdown.
5. FFI-5 · Y — Expand by measured demand. Connect one real compute workload to graph source/probe mappings, then add Python as a bounded process/service profile. Hermes replacement, in-process Python and mobile distribution each retain separate promotion gates.

reaktor-compiler

Astra: A1, A2, A5, A8. Unlock: declarations automatically yield compatible clients, graph facts and checks. Depends on: stable public schema contracts, not compiler-internal types.

1. COMPILER-1 · D — Fail unsupported declarations early. Replace generated TODO/runtime-error output with actionable compile diagnostics and source locations; use invalid-type fixtures that cannot produce apparently usable artifacts.
2. COMPILER-2 · D — Generate the minimal semantic manifest. Extend declaration processing to stable exported contracts, endpoints, effects and source mappings for one recipe; equal source/locks must produce identical semantic output.
3. COMPILER-3 · D — Connect code and owned composition. Feed descriptors into shared normalization/validation and preserve source-owner boundaries. A visual edit must reject stale or unsupported round trips and retain unrelated code/comments.
4. COMPILER-4 · Y — Generate idiomatic language surfaces. Produce Kotlin/TypeScript contracts and the first C ABI adapters from one descriptor; qualify compatibility, nullable/numeric semantics and source-map correspondence against independent fixtures.
5. COMPILER-5 · Y — Specialize only declared profiles. Add optional expression/effect analysis or portable-behavior lowering separately from KSP declaration extraction; pin compiler versions and verify optimized behavior, identity and inspection coverage.

dependeasy

Astra: A1, A8, A9, A10. Unlock: a generated project builds outside the maintainer's machine. Depends on: release dependency closure and supported toolchain decisions.

1. BUILD-1 · D — Prove public package independence. Create a clean consumer without sibling/private repositories or committed credentials; resolve published module and plugin artifacts with documented toolchains and reproducible dependency locks.
2. BUILD-2 · D — Publish build facts. Export source sets, dependency/target/task edges, native inputs and artifact identities through one catalog consumed by CLI, CI and Studio. A feature-to-artifact mapping must handle many-to-many ownership.
3. BUILD-3 · D — Make bootstrap explicit and cacheable. Move expensive side effects out of ordinary configuration where practical; seal toolchain/native inputs and record cache provenance. Repeated configuration must not unexpectedly provision or rewrite dependencies.
4. BUILD-4 · D — Qualify the promised matrix. Add meaningful browser/JVM and bounded Android/iOS recipe checks; disabled browser tasks or common source cannot count as platform evidence. Resolve Java 21/25 differences with explicit supported profiles.
5. BUILD-5 · Y — Reduce edit-to-preview cost. Use measured compatible caches, published artifacts and affected-target selection; reject stale generated output and compare clean/incremental build budgets without sacrificing reproducibility.

reaktor-code

Astra alignment: A1, A2, A6, A8. Substantial contribution: source-intelligence contracts shared by the creator, graph/source editor, external IDE and language adapters without renderer or server coupling. Prerequisites: compiler/source ownership and URI/revision conventions; UI owns editing presentation, tooling owns server processes.

1. CODE-1 · D — Qualify the new independent boundary. Run the dependency check and publish a minimal consumer that hosts document/intelligence contracts with no UI, tooling, graph or LSP runtime. Keep renderer and server choices replaceable.
2. CODE-2 · D — Specify document and range laws. Define identity/version advancement, UTF-16 positions, range endpoints, empty/backward selections and replacement behavior. Property fixtures must preserve content across multiline, surrogate-pair and boundary edits, with invalid coordinates handled explicitly.
3. CODE-3 · D — Fence asynchronous intelligence by revision. Correlate diagnostics, completion, hover and definition results to their requested document/version/session, and define cancellation, close and availability per operation. A late response from a replaced server or earlier edit cannot overwrite current evidence.
4. CODE-4 · D — Connect source and graph through optional mappings. Link source spans/revisions to stable symbol, definition and contract IDs through the compiler/source index. Selecting a port must open the owned source, and an accepted source change must update findings without creating an independent graph-side algorithm copy.
5. CODE-5 · Y — Prove interchangeable editing clients and providers. Run one create-and-grow change through the native editor and an external IDE/provider adapter using the same document and diagnostic fixtures. Measure accepted-edit time and stale-result failures; preserve useful local editing when intelligence is unavailable, and route multi-file changes through the shared patch/plan review path.

reaktor-ui

Astra: A1, A2, A3, A10. Unlock: generated applications have their own visual identity and real behavior. Depends on: component contracts, source bindings and MachineSignal ownership for operator UI.

1. UI-1 · D — Separate product identity from operator tokens. Keep MachineSignal canonical for Reaktor; publish app-owned theme/component contracts so generated products can look distinct. Demonstrate two different briefs without cloning a fixed workbench appearance.
2. UI-2 · D — Connect components to behavior. Describe variants, accessibility roles, actions, state bindings and source IDs; selecting a disabled action must reveal its real data, capability or authority precondition.
3. UI-3 · D — Qualify responsive and native journeys. Test keyboard/focus, loading/error/empty states and actual bindings across the selected browser and native recipe. A design export or semantics-only hidden control cannot satisfy acceptance.
4. UI-4 · D — Preserve design through growth. Round-trip a scoped visual edit and later schema/role change without losing unrelated styling or event handlers; retain owned token revisions and impacted-screen references.
5. UI-5 · Y — Earn broader renderer/theme parity. Reconcile authored Kotlin/TypeScript surfaces through shared fixtures; promote light/high-contrast or additional renderers only with measured visual/accessibility and interaction evidence.

compose-flow

Astra: A1, A2, A10. Unlock: large compositions remain usable without contaminating generic canvas mechanics. Depends on: generic scene/viewport contracts; Reaktor meaning stays in reaktor-flow.

1. CANVAS-1 · D — Stabilize essential interaction. Qualify pan/zoom/fit, selection, edge handles and keyboard/focus behavior with real renderers. Preserve a selected endpoint through viewport changes and test the supported graphics backend.
2. CANVAS-2 · D — Measure large-scene cost. Add representative node/edge/label workloads and culling budgets; viewport performance must improve without losing hit targets or visible connections.
3. CANVAS-3 · D — Expose clean host hooks. Provide generic measurement, selection and viewport events consumed through reaktor-flow re-exports; prohibit graph semantics, workbench state or business actions in this layer.
4. CANVAS-4 · Y — Support semantic zoom mechanically. Offer level-of-detail rendering and stable geometry transitions while the semantic adapter chooses content; changes in visual detail must not change entity identity or execution.
5. CANVAS-5 · Y — Qualify portability and accessibility. Close actual JS/Android graphics harness gaps and validate touch/keyboard behavior per target before claiming renderer parity; use the same interaction fixtures in consuming apps.

reaktor-flow

Astra: A1, A2, A5, A6. Unlock: visual composition and inspection remain projections of the real system. Depends on: shared graph descriptors, validators and source ownership.

1. FLOW-1 · D — Unify semantic edit validation. Route GraphDocument connection edits through contract/cardinality/scope checks used by runtime planning; an invalid edge must leave both document revision and active wiring unchanged.
2. FLOW-2 · D — Preserve identity across projections. Map document, runtime, source and architecture references explicitly; selection, collapse and layout changes must retain exact hidden endpoint and relation identities.
3. FLOW-3 · D — Ship one owned visual edit. A bounded recipe edit produces a typed patch, source diff and acceptance run; reject stale base revisions or unsupported source ownership before overwriting user code.
4. FLOW-4 · Y — Implement composable typed maps. Compose structure, authority, runtime, data and evidence filters over one bounded query; preserve provenance, completeness and revision through joins and semantic zoom.
5. FLOW-5 · Y — Make large and changing views trustworthy. Add incremental subscriptions, gap/resnapshot handling and layout/performance budgets; compare incremental results with full recomputation and keep UI geometry outside canonical semantic patches.

reaktor-tooling

Astra: A1, A6, A9. Unlock: every host executes the same inspectable operation mechanics. Depends on: public task/result contracts and the workspace extraction decision.

1. TOOLING-1 · D — Stabilize provider-independent execution. Define one task/plan/run/result contract for supervised processes and native infrastructure providers; retain exact argv/input seals, bounded output, redaction and cancellation behavior.
2. TOOLING-2 · D — Qualify newly added native providers. Test Kubernetes/database/Worker operations for effect classification, target/environment binding, credential scope, timeout and resource cleanup; compilation must not stand in for live provider conformance.
3. TOOLING-3 · D — Publish reusable discovery and redaction. Extract portable project/source/build facts and shared output handling; remove product-specific heuristics from open mechanics and report unsupported/partial discovery explicitly.
4. TOOLING-4 · D — Verify actual artifacts. Connect successful tool execution to expected artifact existence/digest and structured findings; a command's exit zero must not prove a build, test or deployment result it did not verify.
5. TOOLING-5 · Y — Add incremental semantic context. Expose bounded source/dependency queries with inclusion reasons and read sets; IDE, MCP and Conductor consumers should reuse results and invalidate them on changed source or policy.

reaktor-mcp

Astra: A2, A5, A6. Unlock: agents access the same qualified project knowledge and operation contracts as people. Depends on: workspace query/execution services and caller authority.

1. MCP-1 · D — Publish versioned read schemas. Pin protocol behavior and tool/resource/result contracts; add module-local fixtures for initialize, errors, batches, unknown methods and supported optional capabilities.
2. MCP-2 · D — Scope before disclosure. Authorize catalog, graph metadata, source and log reads before building the response; enforce row/byte/time budgets and test cross-tenant and sensitive-output rejection.
3. MCP-3 · D — Return useful context provenance. Include revision/epoch, freshness, source coverage and reasons for each selected item; fixture and live-mounted sessions must remain distinguishable without reading explanatory prose.
4. MCP-4 · D — Add proposals through the shared broker. Expose validation and prepared-plan operations, then delegated execution where supported; tool descriptions and conversational approval cannot bypass exact-plan authority or create a second mutator.
5. MCP-5 · Y — Add resumable graph subscriptions. Negotiate bounded cursors, event gaps and cancellation over the graph protocol; lost history must demand resnapshot or return incomplete evidence rather than silently continue.

reaktor-conductor

Astra: A1, A5, A6, A10. Unlock: better models compose known mechanisms and return reusable evidence. Depends on: shared workspace operations, graph context and governed project ownership.

1. CONDUCTOR-1 · D — Connect a single-agent creation loop. Turn brief/design/acceptance artifacts into supervised generation, build, preview and scoped follow-up edits; a conversation transition is complete only when the corresponding artifact or operation result exists.
2. CONDUCTOR-2 · D — Compile obligation-directed context. Include exact entities/revisions, relevant source, unmet contracts, findings and inclusion reasons within a budget; carry unknowns and exclude unauthorized data before invoking a harness.
3. CONDUCTOR-3 · D — Use the common effect path. Submit prepared tasks through workspace/tooling and retain source/artifact/test receipts in ThreadDocument projections; the harness's own tool permissions remain explicit rather than presumed constrained by prompt text.
4. CONDUCTOR-4 · Y — Implement actual isolation and recovery. Give parallel writers separate working state, base revisions and read/write sets; recover interrupted runs and revalidate merged proposals. A workspace-mode enum must not be treated as isolation.
5. CONDUCTOR-5 · Y — Measure collaboration value. Compare one agent, additional review and combined graph/context support on held-out creation/growth tasks; promote a multi-agent protocol only when correct acceptance and total repair cost justify its overhead.

reaktor-cloud

Astra: A1, A3, A7, A9. Unlock: one real deploy/observe/recover lane attached to application semantics. Depends on: workspace plans, build facts and provider identities.

1. CLOUD-1 · D — Qualify the chosen reference deployment. Connect one public recipe to artifact, environment, bindings and declared resources; deploy to a dedicated target and retain independently observed version/readiness evidence.
2. CLOUD-2 · D — Preserve inventory truth. Return source, observed, partial, failed and stale coverage separately; a failed provider call must not become an empty successful estate or a healthy connection badge.
3. CLOUD-3 · D — Unify planning and recovery. Use sealed workspace operations for cloud mutations and verify postconditions; distinguish source rollback, rollout recovery, schema migration and compensation in plans and receipts.
4. CLOUD-4 · Y — Make deployment cuts explainable. Link feature/contracts/state authorities to runtime islands and introduced transport/cost obligations; reject placements that violate authority, residency, durability or provider capability.
5. CLOUD-5 · Y — Expand provider depth selectively. Separate reusable adapters from product observability recipes and add a second provider only with an adopter and conformance harness; retain specialist controllers as resource authorities.

reaktor-cli

Astra: A1, A6, A9. Unlock: one public command line for creation and continued operation. Depends on: the 12 September one-CLI decision in Workbench Layers; reaktor-workspace is still proposed.

1. CLI-1 · D — Fix public-path honesty. Add build identity, structured read output and declared-target discovery; a reaktor new project must be visible to inspect/check without a targets/ folder or nonexistent advertised command.
2. CLI-2 · D — Consume one workspace model. Host the extracted generic catalog/control plane and remove CLI-local effect classifiers, product names and folder-based task truth. One selector must resolve identically in CLI, desktop and MCP.
3. CLI-3 · D — Ship plan/run/receipt contracts. Implement environment selection, exact fingerprints, noninteractive JSON and documented exit outcomes. Tests must distinguish refusal, stale plan, execution failure, timeout and cancellation without parsing terminal decoration.
4. CLI-4 · D — Retire the second CLI through compatibility. Move the closed CLI's proven process tests into the public path, preserve documented aliases during migration and include CLI checks in the framework build. No public command may require BestBuds source.
5. CLI-5 · Y — Share a workspace host deliberately. Add attach-or-start semantics and a concurrency-safe ledger so terminal runs appear in Studio/MCP; report the serving host and qualify locking, auth, reconnection and independent process lifetime.

reaktor-web

Astra: A3, A8, A9. Unlock: a justified embedded-web capability, only if a real consumer requires it. Depends on: a product need; the browser creator belongs to its host, not this empty WebView module.

1. WEB-1 · C — Publish an honest capability boundary. Mark current empty classes unavailable and keep them out of stable recipe offers; a generated app must not select WebView functionality merely because the artifact builds.
2. WEB-2 · C — Decide ownership from a concrete use case. Compare a minimal embedded-document requirement with existing host/IO facilities; keep the module frozen if a separate abstraction adds no useful reach or law.
3. WEB-3 · C — Implement a narrow plain API if justified. Specify document/origin, navigation, lifecycle and safe bridge contracts on one target; test close, blocked navigation and denied capabilities before adding graph installation.
4. WEB-4 · C — Project useful document relations. Expose Document/OriginPolicy/BridgeContract/Session with source and effect boundaries; embedding a page cannot implicitly authorize its content to operate the graph.
5. WEB-5 · C — Earn target promotion. Add another target only after one real journey, conformance and maintenance cost justify it; otherwise archive the placeholder rather than maintain a misleading platform matrix.

reaktor-tactile

Astra: A3, A9, A10. Unlock: reduced false capability surface and a clear future decision. Constraint: the repository guide says not to extend this placeholder; these tasks do not authorize implementing haptics.

1. TACTILE-1 · C — Keep status explicit. Record no implementation and no supported target in the module catalog; prevent recipe/capability discovery from treating build inclusion as a working feedback provider.
2. TACTILE-2 · C — Remove accidental public promises. Audit generated package/help/documentation references and label them reserved or unavailable; retain compatibility only for any actual existing consumer discovered.
3. TACTILE-3 · C — Write the unmet-use-case decision. Collect two credible interaction needs and compare composition through existing UI/platform adapters; the result may be to keep the module frozen permanently.
4. TACTILE-4 · C — Preserve the extension boundary. Document where a future permission/device/feedback contract would attach without putting UI semantics in core or graph semantics in a generic renderer; make the required ownership change explicit.
5. TACTILE-5 · C — Set a reopening gate. Require an approved repository-direction change, ordinary API, real target behavior and a demonstrated interaction benefit before future implementation; until then its work is catalog hygiene, not a new runtime.

reaktor-react

Astra: A3, A8, A9. Unlock: useful legacy knowledge without a competing unsupported bridge. Depends on: an explicit React Native consumer; currently excluded from the root build.

1. REACT-1 · C — Classify the legacy surface. Mark React Native/JSI experiments distinct from active web React packages; document unsupported targets and prevent the archive from inflating the release support matrix.
2. REACT-2 · C — Preserve reusable bridge evidence. Inventory proven ownership/callback mechanisms and tests worth migrating into FFI; discard claims supported only by old names or hello-world demos.
3. REACT-3 · C — Choose consolidate or revive. Compare an actual consumer requirement with the shared Service/FFI ABI; prefer one contract/compiler boundary and state the compatibility plan before re-enabling the module.
4. REACT-4 · C — Qualify only a selected bridge. If revived, implement lifecycle, executor affinity, buffer/handle ownership and cancellation/error tests for that target; a Promise or Flow wrapper cannot establish safe teardown by itself.
5. REACT-5 · C — Prove product and maintenance value. Run a real native-host interaction against the supported FFI profile and measure integration cost; otherwise keep the artifact archived and migrate only the useful fixtures.

Closed Reaktor and BestBuds library modules

Closed implementation can host valuable Reaktor product behavior. The public creation/export path must depend only on public contracts and distributable mechanisms. These five build slices remain separately accountable; the public workspace extraction is a proposed boundary, not an already available artifact.

BestBuds modules/kernel

Astra: A1, A5, A6, A9. Unlock: coherent operations across creator, terminal, Studio and agents. Depends on: tooling/auth-core contracts and the one-CLI extraction decision.

1. KERNEL-1 · D — Extract the generic workspace mechanism. Move catalog composition, environment/effect/approval mechanisms and run lifecycle behind a public workspace API; keep BestBuds recipes, classifications and private sessions as contributors. A clean public app must discover, plan and run without this repository.
2. KERNEL-2 · D — Unify identities and contracts. Map workspace/target/task/plan/run/session/evidence to shared graph references; remove duplicate host-specific classifications and preserve current provider-specific safety checks during extraction.
3. KERNEL-3 · D — Make authority part of plan validity. Bind principal, tenant, target, policy and credential expiry/recheck conditions alongside source/environment seals. A revoked or switched context must reject a previously prepared read or write before its effect.
4. KERNEL-4 · D — Persist verifiable outcomes. Implement the public run-ledger port with redacted events, artifact identities and reconciliation state; survive restart without turning interrupted or unknown work into success.
5. KERNEL-5 · Y — Qualify shared-host attachment. Specify concurrency, locking, caller identity, reconnect and lifetime before sharing state between GUI/CLI/MCP. A terminal run must appear consistently in other attached hosts without unsafe concurrent file writes.

BestBuds modules/engine

Astra: A1, A2, A6, A10. Unlock: a creator and professional workspace with persistent semantic context. Depends on: public project/workspace contracts, graph maps and real preview execution.

1. ENGINE-1 · D — Make the creation path perform work. Connect brief, design, recipe, generated source, build and preview through real operations. An unseen brief must produce a working authenticated/persistent journey; Composer state transitions or exported boards cannot satisfy this task.
2. ENGINE-2 · D — Preserve editor-specific context. Maintain shared project defaults while source, graph, preview, trace and diff editors can pin their own revision/time/run. A historical trace must not be relabeled when the current selection changes.
3. ENGINE-3 · D — Route every operational action through the workspace. Bind panes and commands to registered queries/plans/results with source coverage and authority; fixture/prototype surfaces stay explicit and no pane introduces its own executor.
4. ENGINE-4 · D — Prove creation and growth UX. Support real visual edits, custom code, useful findings, cancellation and recovery on the chosen journey. Independently check design quality, preserved bindings/data and time to the first verified change.
5. ENGINE-5 · Y — Evolve modes into coordinated lenses. Integrate the thirteen existing domains through persistent editors, semantic zoom and contextual tools from the atlas; promote deeper panes by completed tasks and bounded-query performance rather than by screen count.

BestBuds modules/app

Astra: A1, A3, A4, A7. Unlock: a real consumer that improves reusable recipes and failure laws. Depends on: framework contracts; BestBuds product policy remains here.

1. APP-1 · D — Extract a public reference composition. Generalize one sign-in/discussion or approval journey into a separately buildable recipe while retaining BestBuds-specific design and policy here. No public sample may require private data, credentials or this module.
2. APP-2 · D — Remove cross-session ambient state. Migrate a representative root/feature from singleton bootstrap to owned session/activation context; test account/tenant switch, logout, restart and stale completions across repositories and actors.
3. APP-3 · D — Qualify the complete messaging path. Join action, upload, membership, authoritative persistence, moderation, notification and analytics through one intent with separate effects. Inject duplicate/lost-response/restart failures and preserve one logical message.
4. APP-4 · C — Make provisional product domains real. Replace Events fixtures and analytics-only success actions with typed durable services; validate social/block/campaign transitions and explicitly retain unsupported journeys until their business effects exist.
5. APP-5 · Y — Feed outcomes back into modules. Version matching/moderation/bot/analytics policies and reusable regression fixtures; demonstrate a framework change benefits this product and another consumer without importing BestBuds semantics into the open core.

BestBuds modules/design

Astra: A1, A2, A10. Unlock: distinctive reusable product design that survives later feature changes. Depends on: reaktor-ui component/theme contracts.

1. DESIGN-1 · D — Clarify ownership. Separate BestBuds product tokens/components from MachineSignal operator language and reference-only assets; changes to one design system must not silently restyle the other.
2. DESIGN-2 · D — Publish component behavior contracts. Describe variants, state, actions, accessibility and supported rendering targets; a reusable card/form must include loading/error/disabled behavior rather than just a static appearance.
3. DESIGN-3 · D — Prove replaceable recipe styling. Apply a different app-owned theme to the public feature composition without duplicating domain logic; bindings and acceptance journeys must survive the visual change.
4. DESIGN-4 · Y — Link designs to consumers and checks. Register token/component/source revisions and affected screens; a component update should select relevant visual and behavior fixtures instead of relying on manual screenshot discovery.
5. DESIGN-5 · Y — Qualify native/web fidelity. Compare actual rendered interactions, responsiveness, text scaling and accessibility on the supported targets; generated reference scenes remain specifications rather than runtime proof.

enginePrototype / modules/engine/prototype-browser

Astra: A1, A2, A9. Unlock: a useful browser publication boundary that cannot be confused with the creator's execution service. Depends on: explicit source selection and capability labels.

1. EPROTO-1 · D — Declare the slice's capabilities. List the selected prototype sources and real/fixture interactions in a machine-readable profile; loading the browser artifact must not imply the full desktop kernel is present.
2. EPROTO-2 · D — Keep the browser build independent. Enforce its dependency budget and prevent accidental inclusion of native/desktop/backend code. A clean browser build should consume supported public contracts and documented assets.
3. EPROTO-3 · D — Separate preview from creation. Route operational creation tasks to the shared project service, with explicit unavailable states until connected; prototype navigation must not return a fabricated build/deploy success.
4. EPROTO-4 · Y — Share qualified graph/editor contracts. Reuse document identity, selection and source mappings with the real browser host; compare a bounded scene and interaction fixture across publication slices.
5. EPROTO-5 · C — Consolidate after migration. Retain this artifact only if it serves a distinct reference/design distribution need; retire duplicate executable UI once the creator host supplies the same supported behavior.

BestBuds and Reaktor deployment targets

These 27 targets are host or deployment units, not 27 new framework primitives. Tasks are ranked within each target. D identifies a contribution to the selected public release path or its transferable regression fixture; it does not require releasing the private BestBuds application in December. Generic host work must graduate to the public distribution seam.

appAndroid

Astra: A1, A3, A9. Unlock: real bounded Android creation evidence. Join: generated artifact → device activation → capability/permission → journey evidence.

1. ANDROID-1 · D. Derive a public generated-project host from the existing shell; build/install it from exported source without BestBuds-only imports or undocumented local SDK state.
2. ANDROID-2 · D. Run the chosen recipe with real navigation, persistence and one device capability; record exact device, app and toolchain identities.
3. ANDROID-3 · D. Exercise permission denial/revocation, process recreation, offline retry and account switch; verify explicit degraded behavior and no duplicate or cross-account effect.
4. ANDROID-4 · D. Connect build/signing/test artifacts to the deployment graph and distinguish local installation from distribution acceptance; verify artifact digests after build.
5. ANDROID-5 · Y. Qualify upgrades, startup/memory and background behavior on the advertised device matrix before promoting beyond the bounded preview.

appDarwin

Astra: A1, A3, A9. Unlock: a separately proven iOS creation lane. Join: exported framework/host → signed artifact → native capability → observed journey.

1. DARWIN-1 · D. Produce a public generated Xcode/Swift host over supported shared contracts; document signing prerequisites and verify a clean build without private product source.
2. DARWIN-2 · D. Run the same bounded recipe and capability/failure case promised for Android on an actual supported iOS target; keep evidence and remaining gaps separate.
3. DARWIN-3 · D. Qualify lifecycle, denied/revoked permissions, local persistence and asynchronous completion after foreground/background changes; shared Kotlin tests do not discharge these native obligations.
4. DARWIN-4 · D. Retain framework, app, signing and device-test identities in release evidence; make distribution limitations explicit instead of equating build success with installability.
5. DARWIN-5 · Y. Prove compatible upgrades and the declared native support matrix before March promotion; app-store/code-delivery eligibility remains a separately verified profile.

appWeb

Astra: A1, A3, A9. Unlock: a normal browser client that can adopt Reaktor without Kotlin build expertise. Join: route/action → auth/Service → product outcome.

1. APPWEB-1 · D. Extract a clean npm/browser consumer fixture using supported auth and service contracts; remove reliance on sibling generated bundles for the public example.
2. APPWEB-2 · D. Qualify two-user sign-in, persisted records, navigation and sign-out across real browser sessions; verify server authority as well as client display state.
3. APPWEB-3 · D. Preserve responsive visual identity and real handlers through an unseen follow-up role/schema change; use independent journey assertions and human design review.
4. APPWEB-4 · C. Complete acquisition, signup, account deletion and product-specific web journeys with source/intent/outcome links; analytics events alone cannot indicate successful backend work.
5. APPWEB-5 · Y. Publish browser compatibility, performance and upgrade evidence for the claimed package/runtime versions; report unsupported native-like behavior rather than imply full app parity.

reaktorDesktop

Astra: A1, A2, A6, A9. Unlock: a professional local companion over the public project service. Join: host session → mounted runtime/workspace → source/selection/run.

1. DESKTOP-1 · D. Host the shared workspace mechanisms and identify the actual mounted graph/session; borrowed services must close exactly once through their owner.
2. DESKTOP-2 · D. Exercise open/export/build/run/check on the public reference project and connect Claude/Codex through the same contracts; full desktop creator parity remains preview.
3. DESKTOP-3 · D. Preserve current versus pinned source/trace contexts across panes and deep links; a source inventory or fixture scene must not become a live runtime observation.
4. DESKTOP-4 · Y. Attach to the public workspace host and shared ledger with explicit identity/ownership; verify CLI/MCP run visibility and safe disconnect/reconnect without restarting the UI.
5. DESKTOP-5 · Y. Qualify packaging, native interactions and performance on each advertised desktop architecture; promote by completed creation/growth/diagnosis tasks rather than atlas coverage.

reaktorCli

Astra: A6, A9. Unlock: migration to one command line without losing tested operational behavior. Join: current closed host → public workspace/CLI contracts.

1. CLOSEDCLI-1 · D. Inventory implemented plan, environment, confirmation and receipt behavior that the public CLI lacks; preserve it as migration fixtures rather than expanding a permanent second product.
2. CLOSEDCLI-2 · D. Move reusable process/end-to-end tests to the open workspace/CLI boundary; demonstrate no private dependency is needed to execute the public fixture.
3. CLOSEDCLI-3 · D. Add compatibility aliases/deprecation guidance and migrate scripts by catalog ID; verify stale plans, refused approvals, timeout and nonzero outcomes survive the transition.
4. CLOSEDCLI-4 · Y. Transfer persisted run history through an explicit versioned migration or importer; never concurrently point independent hosts at the same uncoordinated file.
5. CLOSEDCLI-5 · Y. Retire the redundant host after parity and adoption checks, leaving BestBuds-specific behavior as a catalog contributor to reaktor.

reaktorServer

Astra: A1, A5, A7, A9. Unlock: a headless reference host with truthful operational evidence. Join: service contract → data authority → deployment → observation.

1. SERVER-1 · D. Remove avoidable presentation/engine dependencies from the generic server host path; clean-build the public JVM recipe using public runtime/service/auth artifacts.
2. SERVER-2 · D. Replace constant latency/health fields with scoped probes and explicit unknown/failed results; tests must distinguish reachable transport from usable authenticated database/service behavior.
3. SERVER-3 · D. Qualify auth and graph/data gateways with tenant-bound named queries, budgets and redaction; no generalized query route may rely on client filtering for authority.
4. SERVER-4 · D. Link artifact/configuration, migration compatibility and observed rollout in one release receipt; rehearse a failed deployment and its specific recovery path.
5. SERVER-5 · Y. Add protocol/contract-version coexistence and structured connection/trace evidence without turning the server into an obligatory central graph for every local call.

reaktorWeb

Astra: A1, A6, A9, A10. Unlock: the primary public browser creator and trustworthy documentation. Join: brief/design → owned project → bounded run/preview → deploy/export/evidence.

1. RWEB-1 · D. Make Create an app call the real project/recipe/generation service; an unseen brief must produce a designed, authenticated, persistent application rather than a prototype state transition.
2. RWEB-2 · D. Implement one isolated managed build/preview lane with scoped credentials, bounded jobs, cancellation, cleanup and reconnectable run state; test that projects cannot read one another's files or secrets.
3. RWEB-3 · D. Support visual and conversational follow-up edits over owned source, with findings, diffs and preserved data/design; export must rebuild independently through the local path.
4. RWEB-4 · D. Keep public/private docs, search, graph/outline exports and comments aligned with their access boundary; link claims to dated source/check evidence and distinguish operational from prototype capabilities.
5. RWEB-5 · D. Run held-out creation/growth/failure/deploy trials and external first-user sessions; measure first useful app, intervention, cost and correctness before calling browser v1 complete.

companyOS

Astra: A1, A3, A5, A7. Unlock: a second domain proving workflows and evidence beyond social applications. Join: organization/obligation → workflow → authority → artifact/evidence.

1. COMPANY-1 · C. Declare workflow states, roles and authoritative records through reusable contracts; separate company policy from generic approval/evidence mechanisms.
2. COMPANY-2 · C. Qualify the graph proxy's named-query, tenant, session and bounded-result boundary; metadata and evidence packs must not become ambient cross-organization context.
3. COMPANY-3 · C. Implement completion as verified required artifacts/checks with provenance; a calculated completeness score cannot independently attest correctness or regulatory compliance.
4. COMPANY-4 · Y. Reuse the public approval recipe and contribute one counterexample for late approval, duplicate execution or revoked authority; preserve domain-specific obligations locally.
5. COMPANY-5 · Y. Measure a complete organization workflow before/after shared graph context, retaining human review and exceptions; feed reusable improvements into modules without moving private evidence into public docs.

designPrototype

Removed on 10 October 2026. Production components remain in ai.bestbuds.design.signal; the app owns its destinations. The standalone host, demo graph, fixtures, launch flags and prototype-only suites are deleted. This heading preserves historical links.

reaktorPrototype

Astra: A1, A2, A9. Unlock: retained design learning without a parallel workbench implementation. Join: historical experiment → current component/interaction decision.

1. RPROTO-1 · C. Inventory what remains uniquely useful and mark this React prototype historical; remove unsupported operational claims from navigation and documentation.
2. RPROTO-2 · C. Extract proven graph/selection/inspector interactions into portable acceptance fixtures with stable semantic references.
3. RPROTO-3 · C. Port only those fixtures and behaviors to reaktor-flow/UI or the current host according to ownership; do not copy another control plane.
4. RPROTO-4 · C. Preserve design/source provenance and a clear link to the replacement surface; an old screenshot must not be used as current implementation evidence.
5. RPROTO-5 · C. Archive executable duplication once the useful behavior is verified in the current host; keep historical references addressable for rationale.

prototypeWorker

Deleted on 23 Sep 2026 with the React prototype it hosted. The deployed prototypeworker was removed from Cloudflare on 24 Sep 2026.

tracker

Astra: A2, A10. Unlock: a focused canvas regression fixture rather than another graph platform. Join: interaction experiment → generic canvas contract → regression evidence.

1. TRACKER-1 · C. Document the actual XYFlow example scope and avoid advertising unimplemented task-tracking/runtime semantics.
2. TRACKER-2 · C. Capture useful edge editing, node selection and viewport interactions as reproducible behavior cases.
3. TRACKER-3 · C. Transfer relevant generic interactions into compose-flow fixtures and semantic ones into reaktor-flow; preserve the layer boundary.
4. TRACKER-4 · C. Compare usability/performance only on equivalent scenes and devices, with exact implementation versions and measured output.
5. TRACKER-5 · C. Keep or archive the target based on whether it still provides a unique conformance/reference case; do not build a second task model around the sample.

chatServer

Astra: A4, A5, A7. Unlock: a qualified realtime transport around owned conversation state. Join: room activation → authorized connection → message/presence event → actor/trace.

1. CHAT-1 · D. Define authenticated room membership and connection/session identity; test cross-room, revoked and stale-token admission through the actual host boundary.
2. CHAT-2 · D. Preserve message/operation IDs across reconnect and relay; distinguish transport receipt, persistence and rendered/read state.
3. CHAT-3 · D. Inject duplicate frames, disconnect, hibernation/restart and slow consumers; verify declared loss/order/backpressure behavior without inferring durability from a socket.
4. CHAT-4 · Y. Map the compatible DO/PartyServer profile to actor/Service contracts and explicit state authority; reject unsupported placement or reentrancy assumptions.
5. CHAT-5 · Y. Correlate deployment/activation, connection and operation traces with bounded membership metadata; produce a reusable failure fixture for the public discussion recipe.

messagingServer

Astra: A1, A4, A5, A7. Unlock: the strongest reference for retry-safe state plus downstream effects. Join: message command → membership → authoritative record → moderation/notification.

1. MESSAGE-1 · D. Give each send one logical operation ID and payload digest; a conflicting duplicate must reject and a safe retry must return the recorded result.
2. MESSAGE-2 · D. Enforce membership/tenant/actor authority for every read/write/reaction operation, including stale sessions and delegated service calls.
3. MESSAGE-3 · D. Commit persistence and outbox intent at the selected transaction boundary; moderation and notification failures become separate reconciled outcomes.
4. MESSAGE-4 · D. Run lost acknowledgement, duplicate delivery, restart and external-timeout scenarios through the actual handler/repository path and one real isolated adapter.
5. MESSAGE-5 · Y. Publish transferable Service/actor/DB fixtures and trace/impact mappings; keep BestBuds-specific policy and schema choices in the product contributor.

socialServer

Astra: A3, A5, A7. Unlock: domain relations with enforceable negative constraints and useful derived views. Join: profile/friendship/membership/block → policy/query → recommendation.

1. SOCIAL-1 · C. Define versioned profile, friendship, membership, block and report contracts with one write owner and explicit legal transitions.
2. SOCIAL-2 · D. Test account/tenant/resource boundaries for the selected public identity/social fixture, including suspended or removed membership.
3. SOCIAL-3 · C. Make block/exclusion rules invalidate matching, feeds and relevant communication permissions; positive similarity must not override a hard exclusion.
4. SOCIAL-4 · Y. Emit versioned relationship events/projection watermarks and add replay/rebuild tests so derived graph state cannot silently diverge from authority.
5. SOCIAL-5 · Y. Expose bounded impact/explanation queries and contribute a cross-path authorization counterexample to the common graph validation corpus.

mediaServer

Astra: A1, A3, A7. Unlock: reliable object publication with declared ownership and policy. Join: upload intent → object → metadata/owner → moderation/delivery.

1. MEDIASERVER-1 · D. Require the selected auth/owner contract on upload and access; verify size, type and malformed payload rejection at the actual route.
2. MEDIASERVER-2 · D. Stage bytes and commit their authoritative reference separately, with checksums and reconciliation for failed metadata publication.
3. MEDIASERVER-3 · D. Preserve operation identity across retries/cancellation and clean up orphaned objects; a successful R2 write must not mean the product attachment is complete.
4. MEDIASERVER-4 · Y. Link transformation/moderation versions and caches to the asset digest; invalidation and deletion must traverse owned derivatives.
5. MEDIASERVER-5 · Y. Qualify a native/browser capture-to-display journey with trace, latency and storage-cost evidence; promote the reusable adapter independently of product policy.

textModeratorServer

Astra: A3, A5, A6, A10. Unlock: a typed uncertain inference boundary inside dependable product logic. Join: content digest + model/policy revision → verdict → enforcement/evaluation.

1. TEXTMOD-1 · C. Define verdict, abstention, unavailable and error outcomes; a model failure must never silently produce a safe-content decision.
2. TEXTMOD-2 · C. Include preprocessing, model and policy revision in cache identity; test invalidation and conflicting old verdicts after an upgrade.
3. TEXTMOD-3 · C. Qualify wrapper/model initialization, cold start, resource limits and timeout/fallback on the actual Worker profile.
4. TEXTMOD-4 · Y. Use held-out labeled examples and independent assertions to measure false positives/negatives and subgroup-relevant failure patterns for the product purpose.
5. TEXTMOD-5 · Y. Connect verdicts to enforcement, appeals and run/cost evidence; compare smaller/local/remote strategies only when minimum policy and privacy requirements remain satisfied.

imageModeratorServer

Astra: A3, A5, A7. Unlock: asset handling and uncertain model results share traceable policy. Join: asset digest → inference profile → verdict → publication decision.

1. IMGMOD-1 · C. Bind reads to the authorized asset/owner and validate format, dimensions and payload limits before inference.
2. IMGMOD-2 · C. Represent missing object, invalid image, timeout, abstention and model error separately from approved content.
3. IMGMOD-3 · C. Version preprocessing/model/policy/cache keys and test re-evaluation after an upgrade or asset change.
4. IMGMOD-4 · Y. Evaluate an independent held-out corpus and measure startup/latency/cost under real provider limits; do not infer quality from schema-valid output.
5. IMGMOD-5 · Y. Join verdict lineage to asset publication/deletion and user-facing enforcement; preserve unknown outcomes when asynchronous scanning has not completed.

campaignEngagementServer

Astra: A4, A7, A10. Unlock: a reusable scheduled workflow with measured product purpose. Join: schedule/policy → campaign run → bot/notification attempt → participation.

1. ENGAGE-1 · C. Version campaign policy, schedule and run identity; repeated trigger delivery must resolve to the same logical scheduled operation.
2. ENGAGE-2 · C. Revalidate membership, consent/opt-out and service authority at execution, including changes since scheduling.
3. ENGAGE-3 · C. Separate bot generation, message persistence and notification completion with retries/reconciliation; partial fanout must remain visible.
4. ENGAGE-4 · Y. Model one finite workflow with deadlines and terminal dispositions, then replay duplicate, timeout and late-completion traces against the real handlers.
5. ENGAGE-5 · Y. Measure useful participation and user-reported quality rather than only send volume; feed reusable scheduling and effect fixtures into the public recipe.

botServer

Astra: A3, A5, A6. Unlock: a bounded AI capability composed with ordinary application laws. Join: authorized context + prompt/model → inference run → moderated message.

1. BOT-1 · C. Specify typed inputs/results, model/prompt revisions and allowed context sources; verify service-only authority and tenant scope at the handler boundary.
2. BOT-2 · C. Bound concurrency, cost, time and output size; cancellation and provider failure must produce explicit outcomes without leaking private prompts or credentials.
3. BOT-3 · C. Enforce input/output safety and business rules around uncertain generation; a model's own approval cannot authorize its next external action.
4. BOT-4 · Y. Retain content attribution, inference/attempt identity and independent evaluation fixtures; distinguish bot authorship from user authorship in downstream state.
5. BOT-5 · Y. Extract one public evaluated model-call recipe after proving reuse; compare provider substitutions on quality, privacy, latency and cost rather than treating models as equivalent endpoints.

analyticsServer

Astra: A7, A10. Unlock: outcomes and release effects become measurable without confusing projections with authority. Join: event schema/exposure → ingest receipt → ClickHouse watermark → outcome.

1. ANALYTICS-1 · D. Version event IDs and schema/release/context fields for the selected reference journey; validate payload and consent/environment scope before ingestion.
2. ANALYTICS-2 · C. Quantify duplicate/lost events and retain batch/attempt outcomes; successful enqueue must not be reported as queryable analytical completion.
3. ANALYTICS-3 · Y. Expose source offsets, reducer versions and rebuild/deletion policy for ClickHouse projections; they cannot silently become authorization-critical primary state.
4. ANALYTICS-4 · Y. Link recipe/model/release exposure to meaningful product outcomes with explicit population and freshness; do not present observational correlation as a controlled causal gain.
5. ANALYTICS-5 · Y. Add the creation/growth and module-ablation scorecards with total cost/intervention; preserve unsuccessful trials and uncertainty alongside successful demos.

configServer

Astra: A1, A7, A9. Unlock: environment changes become validated rather than implicit drift. Join: config revision → environment → service binding/feature exposure.

1. CONFIG-1 · D. Choose one authoritative environment/binding schema and generate or validate Kotlin and TypeScript tables against it.
2. CONFIG-2 · D. Bind service endpoints, audiences and data authorities to the selected environment; reject cross-environment combinations in the recipe's validation.
3. CONFIG-3 · D. Include configuration digests in build/run/deployment plans and invalidate prepared operations when relevant settings change.
4. CONFIG-4 · Y. Describe feature flags and defaults with provenance and exposure identity; distinguish desired configuration from the version an activation actually loaded.
5. CONFIG-5 · Y. Exercise compatible upgrades, rollback/roll-forward and partial rollout with old clients; return explicit unsupported versions instead of silently misrouting traffic.

stickerServer

Astra: A3, A7. Unlock: a compact asset/catalog composition proving reusable ownership and invalidation. Join: pack/version → assets → installation → message use.

1. STICKER-1 · C. Version pack/catalog and installation contracts with explicit owner/access rules; validate public versus private asset references.
2. STICKER-2 · C. Make install/update/remove operations idempotent and account-scoped; retries and account switches must not duplicate or retain another user's installation state.
3. STICKER-3 · C. Connect pack changes to media-cache and client invalidation; preserve referenced versions when old messages require them.
4. STICKER-4 · Y. Add moderation/deletion/retention lineage for pack assets and verify cleanup against a known synthetic inventory.
5. STICKER-5 · Y. Extract only the useful generic catalog/asset recipe when a second consumer exists; keep sticker-specific product behavior out of the framework core.

notificationServer

Astra: A1, A3, A4, A7. Unlock: provider dispatch and client intent have one completion vocabulary. Join: notification intent → coordinator → endpoint/attempt → provider receipt.

1. NSERVER-1 · D. Align Worker/DO schemas and statuses with the shared notification module; distinguish scheduled/admitted/provider-accepted/device-observed/user-action states.
2. NSERVER-2 · D. Enforce endpoint ownership, preferences and current service authority at dispatch; test revoked tokens, disabled preferences and tenant/account changes.
3. NSERVER-3 · D. Persist logical intent and attempt/deduplication state; reconcile uncertain dispatch before retrying or selecting another endpoint/provider.
4. NSERVER-4 · D. Qualify the selected real provider and native route-action case with duplicate, timeout and token-rotation failures; a fake provider cannot prove delivery semantics.
5. NSERVER-5 · Y. Project coordinator activation, provider configuration and redacted outcomes into trace/impact maps; measure user-relevant latency and avoid calling acceptance a receipt by the user.

bestbudsArchiver

Astra: A5, A7, A9. Unlock: recoverable state with evidence stronger than a saved object. Join: schema/data revision → backup artifact → restore run → integrity check.

1. ARCHIVE-1 · C. Specify backup scope, authoritative stores, schema revision and retention/exclusions; a table-discovery result must report incomplete coverage.
2. ARCHIVE-2 · C. Produce checksums/manifests and verify uploaded artifacts; keep backup success distinct from a completed usable restore.
3. ARCHIVE-3 · D. Rehearse restoration of the reference workflow in an isolated environment and verify records, permissions and application behavior against independent assertions.
4. ARCHIVE-4 · Y. Test interrupted export/restore, duplicate triggers and incompatible schemas with explicit resume/recovery outcomes.
5. ARCHIVE-5 · Y. Join backups to account deletion and release recovery policy; state how retained copies are treated rather than implying immediate erasure from primary deletion.

accountPurgeServer

Astra: A4, A5, A7. Unlock: a dependency-aware deletion workflow with explicit exceptions. Join: deletion intent → owned/derived data → purge attempts → completion evidence.

1. PURGE-1 · C. Declare soft-delete, restore window, final purge and retention-exception states with one authoritative policy revision.
2. PURGE-2 · C. Inventory relational, graph, media, cache and analytical derivatives for a synthetic account; each registered owner must supply a cleanup or retained-exception contract.
3. PURGE-3 · C. Make purge attempts idempotent and recoverable after partial failure; late events must not resurrect a tombstoned account's derived data.
4. PURGE-4 · Y. Revalidate execution authority and audit outcomes without retaining deleted payloads in general logs or receipts.
5. PURGE-5 · Y. Verify completeness against the registered inventory and documented backup treatment; report unknown owners explicitly rather than claiming universal erasure.

dataProbe

Astra: A5, A7, A9. Unlock: useful connection evidence with accurate effect scope. Join: probe definition/effects → operation → observed capability/coverage.

1. PROBE-1 · D. Classify every probe by actual effect, including insert/read/delete diagnostics; method names such as GET or health cannot establish read-only behavior.
2. PROBE-2 · D. Require target/environment/principal authority appropriate to that effect and seal the probe definition into its plan.
3. PROBE-3 · D. Validate expected response shape and capability-specific success; network reachability, malformed 200 responses and constant values must not produce whole-system health.
4. PROBE-4 · D. Bound diagnostic records, cleanup and timeout, and test interrupted writes in an isolated scope; retain a partial/unknown result if cleanup or outcome is uncertain.
5. PROBE-5 · Y. Publish probe revision, observation time and coverage through the common evidence schema so cloud, database, CLI and agent surfaces interpret the same result.

Matching, knowledge and delivery subsystems

These eleven systems sit outside the 68 inventoried module/target build units but were assessed in the review. Their five-task plans keep important Python, delivery and evidence work visible. They do not require turning each directory into a new Gradle module.

neo4j-airflow-sync

Astra: A4, A7, A8. Unlock: recoverable data-to-assignment orchestration. Current seam: bestbuds/models/neo4j-airflow-sync/dags; the current grouping DAG does not import matcher v2.

1. AIRFLOW-1 · C. Record extract/schema/algorithm/constraint revisions and source watermarks for every grouping run; distinguish scheduler source from the version actually deployed and executed.
2. AIRFLOW-2 · C. Lock down block, existing-chat, membership and other hard exclusions with complete fixtures; preserve the existing undirected-block behavior rather than treating it as missing.
3. AIRFLOW-3 · C. Make campaign/chat materialization idempotent and resumable after a partially completed run; retain attempts and explicit failed/unresolved writes.
4. AIRFLOW-4 · Y. Introduce matcher v2 behind a versioned pipeline adapter only after its offline comparison and constraint gates pass; preserve rollback and reproduce the old result where needed.
5. AIRFLOW-5 · Y. Project dataset/run/assignment/effect lineage into bounded graph queries so operators can explain a group and recover a failed stage without rerunning completed effects.

matcher-v2

Astra: A3, A5, A7, A8, A10. Unlock: a valuable pure algorithm composed with constraints, data and outcomes. Current seam: bestbuds/models/matcher-v2/matcher_v2.

1. MATCH-1 · C. Specify input completeness, weights, hard constraints and reproducibility guarantees; distinguish missing optional signals from zero scores and retain exclusion as a hard relation.
2. MATCH-2 · C. Expand independent/adversarial fixtures for group sizes, blocks, leftovers, deterministic seeds and missing data; generated synthetic examples alone must not grade the algorithm.
3. MATCH-3 · C. Benchmark the implemented brute-cosine/Louvain-oriented pipeline against the current production-DAG algorithm; report constraint violations, quality, leftovers, runtime and memory before considering HNSW/Leiden.
4. MATCH-4 · Y. Expose a versioned bounded Python Service/job contract with artifact, cancellation and input/output provenance; do not wait for in-process FFI to make the algorithm composable.
5. MATCH-5 · Y. Run a controlled product comparison after offline gates, linking assignments to meaningful relationship outcomes and consent scope; retain failures and do not optimize only message or notification volume.

models/algorithm

Astra: A3, A5, A10. Unlock: preserved experimental knowledge and fewer competing unsupported engines. Current seam: bestbuds/models/algorithm/algorithm.

1. ALGORITHM-1 · C. Mark historical/base matchers as experimental, including the all-members grouping behavior; ensure no active product recipe accidentally imports them.
2. ALGORITHM-2 · C. Inventory useful datasets, comparison logic and benchmarks with their assumptions and versions rather than carrying over unqualified performance claims.
3. ALGORITHM-3 · C. Move reusable oracles and constraint counterexamples into the current matcher conformance corpus with clear provenance.
4. ALGORITHM-4 · C. Re-run only experiments that answer a current measured bottleneck or algorithm decision under comparable inputs and resource budgets.
5. ALGORITHM-5 · C. Archive redundant implementations after transfer and retain source-linked rationale; one versioned production selection should identify which algorithm actually owns a MatchRun.

Knowledge import and graph gateway

Astra: A2, A5, A6, A7. Unlock: authorized federated knowledge with exact source ownership. Current seams: GraphGateway.kt and cloud/k3s/build-knowledge-graph-import.py.

1. KNOWLEDGE-1 · D. Declare source authority, tenant, schema and import revision for each knowledge dataset; distinguish domain data from executable definition/activation records in the shared graph.
2. KNOWLEDGE-2 · D. Qualify named-query authorization, parameters, pagination and expansion budgets at the server boundary; a graph client cannot widen its scope by changing a query label.
3. KNOWLEDGE-3 · Y. Make imports idempotent with tombstones, lineage and reconciliation for partial writes; a repeated load must not multiply logical entities or resurrect removed content.
4. KNOWLEDGE-4 · Y. Return per-source revision/watermark and incomplete coverage for federated results; never imply an atomic cross-store snapshot from a joined display.
5. KNOWLEDGE-5 · Y. Feed bounded context packets to MCP/Conductor with inclusion reasons and supersession; retrieved text remains evidence and cannot authorize tools or overwrite policy.

Dagger and CI

Astra: A1, A9, A10. Unlock: reproducible creation and change with reusable build evidence. Current seam: bestbuds/.dagger/src/index.ts and the manually dispatched workflow.

1. DAGGER-1 · D. Execute a clean public dependency-closure build and resolve the Java 21/25 and platform-toolchain matrix; distinguish a scaffolded pipeline from an observed successful run.
2. DAGGER-2 · D. Make CI consume the canonical task catalog and source/lock/configuration inputs; Gradle/npm/CMake remain build authorities and GitHub remains the trigger rather than a second recipe language.
3. DAGGER-3 · D. Publish artifact/check digests, skips and target evidence from the selected browser/JVM/native lanes; never infer Apple-link/device success from a Linux container job.
4. DAGGER-4 · D. Gate public packaging and export on no private dependencies or maintainer credentials, plus meaningful kernel and journey checks; preserve explicit review at consequential release operations.
5. DAGGER-5 · Y. Measure compatible warm caches and affected-target execution against clean builds; cache correctness and artifact existence must remain prerequisites for any speed claim.

Fastlane and mobile delivery

Astra: A1, A9. Unlock: buildable native previews can become traceable releases. Current seam: bestbuds/fastlane.

1. FASTLANE-1 · D. Document and automate the selected public Android/iOS recipe build paths with explicit signing prerequisites and no embedded secrets.
2. FASTLANE-2 · D. Carry source/toolchain/configuration/artifact identities into device-test and distribution receipts; a distribution upload is a distinct outcome from store approval.
3. FASTLANE-3 · D. Run capability-denial, persistence and lifecycle journeys on each required native target before calling the paired preview complete.
4. FASTLANE-4 · Y. Rehearse compatible app/framework upgrades and rollback/roll-forward within platform constraints, preserving user state and target-specific failure evidence.
5. FASTLANE-5 · Y. Promote support only for the measured device/OS/signing matrix; connect release failures to affected module contracts and build inputs for faster diagnosis.

Cloud/k3s operations

Astra: A4, A7, A9. Unlock: heavy compute and state services with qualified operation semantics. Current seam: bestbuds/cloud/k3s.

1. K3S-1 · D. Describe the reference service/data deployment, region, state authority and required credentials as typed source facts; avoid equating manifests with applied state.
2. K3S-2 · D. Use governed task/native-provider operations for connection, rollout and inspection with exact namespace/resource/definition seals and scoped sensitive reads.
3. K3S-3 · D. Capture deployed artifact/version and capability-specific probe evidence, preserving failed/partial/stale conditions in the same graph used by the workbench.
4. K3S-4 · D. Rehearse backup/restore and failed rollout for the selected state authority; Kubernetes readiness is not a durable actor ownership fence or a guarantee of data recovery.
5. K3S-5 · Y. Attach another owned environment only through explicit identity/revocation and provider conformance; use measured workload/cost to justify placement changes.

Cross-platform test harnesses

Astra: A1, A5, A9, A10. Unlock: reusable evidence across creation, growth and runtime failures. Current seams: bestbuds/tests and reaktor/tools.

1. TESTS-1 · D. Define held-out creation briefs and growth requirements before tuning recipes; keep independent assertions and human design review separate from generated tests.
2. TESTS-2 · D. Package the four golden journeys with named target/profile requirements and real adapter/device cases; record skip, abort, fixture and cached status explicitly.
3. TESTS-3 · D. Turn core identity/lifecycle/actor/authority failures into minimized reusable counterexamples linked to source, property and reproduction command.
4. TESTS-4 · D. Connect one bounded model's failure traces to the actual runtime/adapter harness; show bounds, assumptions and uncovered behavior rather than claiming whole-system proof.
5. TESTS-5 · Y. Select checks from changed contracts/effects and validate that incremental selection misses no mandatory obligation in reviewed examples; record total verification overhead and escaped regressions.

Design/source assets

Astra: A1, A2, A10. Unlock: preserved design intent and reusable visual verification. Current seams: bestbuds/modules/assets, product/operator Pencil specifications and their authored consumers.

1. ASSETS-1 · D. Identify authoritative token/component specifications versus reference/generated assets; each artifact must state its owner, purpose and revision.
2. ASSETS-2 · D. Connect app design choices to real components, states and interactions in the public recipe; reference boards cannot be shipped as evidence that behavior exists.
3. ASSETS-3 · D. Verify two distinctive app designs across responsive states without forcing MachineSignal onto generated products; preserve accessibility and real bindings.
4. ASSETS-4 · Y. Build source/design/visual-diff links and affected-component queries so a token change selects the correct consumer checks.
5. ASSETS-5 · Y. Measure whether references and generated assets reduce rework and improve independent UX assessment; retire redundant runtime exports or unsupported parity claims.

SQL migrations

Astra: A1, A5, A7, A9. Unlock: the hundredth change can preserve real data. Current seam: bestbuds/modules/app/src/jvmMain/kotlin/ai/bestbuds/app/db.

1. MIGRATE-1 · D. Define a versioned migration manifest with expected prior schema, authority, transaction/lock scope and recovery class; a SQL file's existence must not imply it has been applied.
2. MIGRATE-2 · D. Qualify clean bootstrap and upgrade from the preceding reference version with seeded records, roles and tenant constraints.
3. MIGRATE-3 · D. Link migrations to query/service/client contracts and deployment ordering; reject a release whose active clients cannot coexist with the new schema.
4. MIGRATE-4 · D. Execute an interrupted/failing migration and restore or roll-forward rehearsal in an isolated environment, retaining exact observed schema and result evidence.
5. MIGRATE-5 · Y. Add source-versus-observed drift detection and projection rebuild/deletion implications; keep operator SQL and automated steps under the same plan/authority contract.

Documentation catalog

Astra: A2, A6, A9, A10. Unlock: source-backed knowledge stays useful to developers and agents. Current seam: bestbuds/targets/reaktorWeb/docusaurus/manifest.mjs.

1. DOCS-1 · D. Keep one registered reading tree, source Markdown and generated graph/outline/catalog; link the master plan, module assessment and task plan so none is an isolated inventory.
2. DOCS-2 · D. Label current implementation, dated checks and future tasks separately; every stability/capability claim must name its scope and evidence rather than inherit a module badge.
3. DOCS-3 · D. Validate public/private routing, search indexes and machine-readable exports as part of documentation publication; access to one representation must not bypass another's policy.
4. DOCS-4 · Y. Track claim-to-source/contract/check revisions and mark affected claims stale on structural changes such as module extraction or removed support.
5. DOCS-5 · Y. Let module authors publish conformance, migration and example entries through the same contribution contract; measure contributor first-success time and unresolved documentation failures.