Oshun Platform · Guides & deep dives

Workbench Development, Testing, and Change Map

Cross-domain primitives may live under libs/shared or libs/oshun, but a change there does not transfer business ownership away from the consuming domain.

7sections5 minread2tables

On this page

This map helps engineers find the correct owner and choose verification that proves the affected workbench journey without running an unsafe monorepo-wide guess. Exact project names and targets come from project manifests and the generated inventory.

journey title A workbench change reaches supported evidence section Route ownership Resolve domain shared-kit and host-app owners: 5: Engineer Identify contracts stores effects and release scope: 5: Engineer, Product section Implement Change domain behavior and compatibility: 4: Engineer Update inventory clients migrations and projections: 5: Engineer section Verify Run unit contract service and concurrency lanes: 5: Engineer Run browser native accessibility performance and security lanes: 5: QA, Engineer section Operate Validate observability degradation restore and rollback: 5: SRE Record current journey and deployment evidence: 5: SRE, Governance section Document Update focused prose diagrams and canonical references: 5: Owner Regenerate Docs Center and inventory gates: 5: Owner

The route is evidence-driven: a shared primitive, domain effect, host surface, and deployed journey may require different owners and harnesses in one change.

Source and evidence roots#

Scope Primary roots
Shared kit libs/oshun/workbench-kit, docs/adr/ADR-S1-*, docs/adr/ADR-S4-*, evidence/v1-workbenches, scripts/v1-workbenches
Isis apps/isis, libs/isis, relevant Oshun Studio routes/adapters, evidence/v1-workbenches/isis-*
Metis apps/metis, libs/metis, relevant Oshun surfaces/adapters, evidence/v1-workbenches/metis-*
Yemaya apps/yemaya, libs/yemaya, docs/proposals/yemaya-study-workspace, tools/yemaya-study, docs/runbooks/yemaya-study-*, evidence/v1-workbenches/yemaya-*
Veritas apps/veritas, libs/veritas, relevant Oshun publishing/admin surfaces, evidence/v1-workbenches/veritas-*
Euterpe apps/euterpe, libs/euterpe, relevant Oshun adapters, evidence/v1-workbenches/euterpe-*
Aja apps/aja, libs/aja, Oshun Studio Aja routes, evidence/v1-workbenches/aja-*
Bellona apps/bellona, libs/bellona, Oshun Studio/approval adapters, evidence/v1-workbenches/bellona-*

Cross-domain primitives may live under libs/shared or libs/oshun, but a change there does not transfer business ownership away from the consuming domain. Check the package graph and public export rather than importing an internal path.

Generated inventory workflow#

The generic inventory is produced by:

bash
node scripts/v1-workbenches/generate-inventory.mjs
node scripts/v1-workbenches/generate-inventory.mjs --check

It emits deterministic manifest, package, application, route, test, library graph, public-symbol, and reconciliation data under evidence/v1-workbenches/inventory. Domain generators add information that static generic discovery cannot understand, including Studio route catalogs, data/storage, web/desktop IPC, services, DAW subsystems, CLI commands, and DCC protocols.

Run the relevant generator whenever a package, route, service, library, protocol, public symbol, schema/storage shape, registry, or test surface changes. Use --check in verification so a stale evidence snapshot cannot pass.

Change routing#

Change Required owners and proof
Shared UI primitive/token/archetype Workbench Kit plus affected domain consumers; public API, dependency/alias, visual, keyboard, accessibility, responsive, theme-isolation, and browser tests.
Domain route or view Domain owner and hosting Oshun app where applicable; route/auth/tenant, data/effect wiring, errors/empty/partial/offline, responsive/accessibility, browser journey, and inventory.
Command or API Domain contract/service/client; schema, authorization, invariants, version/idempotency, error mapping, integration, generated-client drift, and observability.
Persistence/migration Domain data owner; migration and backfill, constraints, tenant isolation, transactions/concurrency, rollback/forward-fix, lifecycle/deletion, backup/restore, and deployed compatibility.
Job/provider/model/tool Domain plus platform/SRE/security as applicable; queue/lease/fence, retry/cancel, validation, lineage, policy/rights, provider failure, capacity/cost, and game-day evidence.
Search/vector/graph projection Domain source-of-truth owner; permission-before-aggregation, index version/rebuild/cutover, staleness, deletion, relevance/evaluation, performance, and restore.
Export/share/publish Domain, security/privacy/rights, and channel/integration owner; authorization, manifest/provenance/signing, delivery/replay, retention/revocation/takedown, and external receipts.
Assistant/agent action Domain plus Eve/assistant owner; scoped tool contract, confirmation/lease, policy, actual effect, audit/provenance, independent verification, and prompt/tool evaluation.

Verification layers#

Static and contract#

Run formatting/lint, type checking, dependency-boundary checks, public-export and packed-consumer checks, schema/contract validation, generated-client and inventory drift, migration validation, and documentation conformance.

Unit and property#

Exercise domain invariants, reducers/state machines, parsers/renderers, coordinate/time conversion, compatibility, command/query outcomes, rights and policy decisions, retry/idempotency, history/merge, and deterministic serialization. Plant negative and boundary cases; do not only snapshot happy rendering.

Service and integration#

Use real adapters or controlled protocol fakes to prove identity, tenant/role, transactions, database/object store, queue/outbox/inbox, provider callbacks, projection/search/graph, signing, deletion, and external delivery. Test duplicate, reordered, late, conflicting, unavailable, malformed, and partially-completed operations.

Browser, desktop, mobile, and CLI#

Automate supported journeys at their real entry point. Cover authentication and role variants, core create/read/edit/review/export flows, keyboard and touch, responsive layout, loading/empty/long/error/partial/offline/conflict states, save honesty, cancellation/retry, history, evidence, rights/permission changes, deep links, and recovery after reload/reconnect.

For Electron, native/audio, DCC, engine, remote-host, or mobile approvals, run the repository's matching harness rather than treating a browser component test as parity proof.

Accessibility#

Combine automated checks with keyboard journey assertions and, for high-density or custom controls, screen-reader/assistive-technology evidence. Test focus order/restoration, names/roles/states, live status/error, shortcuts, reflow/ zoom, contrast, reduced motion, touch targets, captions/transcripts, and structured alternatives for canvas/timeline/graph/waveform/drag interactions.

Performance and scale#

Test against declared budgets and representative long projects/sources/tracks, large tables/graphs/timelines, concurrent users, job backlog, provider latency, large uploads/exports, database contention, memory/disk pressure, and virtualization. Failure under capacity must stay bounded and recoverable.

Security, privacy, and operations#

Test cross-tenant/role denials, sessions/CSRF, unsafe files/URLs/archives, parser sandboxing, injection/prompt/tool controls, secrets/logs, callbacks and replay, external hosts, exports/signatures, retention/expiry/deletion, backup/ restore, provider/model withdrawal, rollout/rollback, and incident procedures.

Yemaya Study Workspace lane#

The Study Workspace has its own authoritative local workflow in DEVELOPMENT.md. It covers local infrastructure, source-safe seeds, contracts, the workspace core library, service, program checkers, generated artifacts, evidence scope, accessibility map, proposal conformance, evaluation/phase exits, shadow validation, and deployed-only checks.

Relevant roots include:

  • apps/yemaya/svc-study-workspace — service routes, persistence composition, migrations, and tests;
  • libs/yemaya/study-workspace and related Yemaya packages — domain contracts and core behavior;
  • tools/yemaya-study — conformance, inventory, release/evaluation, and evidence runners;
  • docs/proposals/yemaya-study-workspace — schemas, decisions, inventories, threat model, evaluation, accessibility, and evidence;
  • docs/runbooks/yemaya-study-* — rollout, rollback, provider, model, expiry, deletion, closure, backup, and recovery procedures.

Use its checker list rather than inventing a smaller replacement. Some gates need a staged deployment or sealed corpus and correctly withhold without one; their rule-level tests still run locally.

Evidence quality#

A task is not proven by a file count, a green test unrelated to the path, a rendered but unwired UI, an in-memory stand-in labeled as saved, a provider planner with no transport, an empty evaluation register, or a generated record that is not re-derived.

Strong evidence identifies:

  • requirement and user journey;
  • source revision and configuration;
  • exact supported entry point and real effect;
  • enforcement and negative/failure behavior;
  • test/harness and result artifact;
  • deployed runtime where required;
  • owner, date, limitations, and unresolved gaps.

Completion checklist#

  • Ownership and dependency direction are correct.
  • Contracts, schemas, migrations, clients, registries, inventories, and docs are synchronized.
  • The real surface reaches the real service/effect under correct auth, tenant, policy, review, and rights controls.
  • Applicable static, unit, integration, browser/native, accessibility, performance, security/privacy, evaluation, and operational checks pass.
  • Success, denial, empty, partial, offline, error, conflict, retry, cancellation, version, scale, and recovery states are represented wherever meaningful.
  • Observability, runbook, rollout/rollback, backup/restore, deletion, and incident implications are updated.
  • Docs Center generation, freshness, integrity, and browser coverage pass.