6.6 Source architecture and package boundaries

The client expresses user actions, the backend maintains business state, and the Harness adapter runs models and tools. Shared contracts connect these layers.

React work interface
      │ Shared contracts
Harness / RPC adapter ── DSH models, sessions, and tools
      │
Business services ── PostgreSQL
      │
Resources, tasks, colleagues, groups, and automations

Where the code lives

Package	Responsibility
packages/contract	Shared types, data formats, and validation
packages/backend	Persistence, business rules, transactions, and idempotency
packages/harness-dsh	DSH integration, RPC, execution, and authorization checks
packages/client/ui-workbench	React product interface and interaction state
packages/client/ui-kit	Shared UI functionality
packages/bundle	Plugin composition and presets
packages/mcp-reference	Minimal read-only reference service

Changing a field across packages

Update the contract and defaults first, then check backend storage, adapter parsing, client readers, and test fixtures. Parsers that accept only an exact set of keys may reject a new field. A type change alone does not establish runtime compatibility.

For a new task state, plan source, or reference, include at least one integration test using a real database and host, covering the full path from creation to display.

Dependency direction

Keep database and UI dependencies out of pure contracts. Business services must not manipulate browser components directly, and clients must not bypass the adapter to write to the database. A new Harness can be designed around these boundaries, but the current public tutorials cover only the implemented DSH adapter.