---
title: Source architecture and package boundaries
description: Understand how shared contracts connect business services and the Harness adapter.
lastVerified: 2026-09-23
---

# 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.

```text
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.