DeepSeek Harness Studio: The Integrated Workbench

Harness + Adapter: Division of Labour

The first thing I want clear is authorship of responsibility. DSH is the host. It owns the browser shell, the profile manager, the slot system, the settings surface, and the web server that serves the Studio on loopback. ASD does not fork the host and it does not patch the host source tree in place. The shipped pointer is platform/packs/dsh/, and the actual integration package is @asd/ui. That package composes into the official DSH profile beside @deepseek-ai/dsh-base and @deepseek-ai/dsh-web-app. If you remember one sentence from this section, remember this one: DSH supplies the room; @asd/ui brings in the workbench furniture and wires it back to the canonical ASD engine.

That arrangement keeps the architecture honest. The shared ASD payload stays the shared ASD payload: 10 roles, 80 shipped skills from 81 authored sources, 30 canonical sd_* runtime tools, 228 corpus resources, 10 role prompts, 38 registered artifact-kind contracts, 39 catalog rows, and 7 authored templates. The DSH surface does not invent a second project store, a second review system, or a second fact-check engine. The adapter validates the compatibility seam, registers the canonical tools and skills, injects the shared role contract into the system prompt, mounts the Studio browser, and routes the work back into the same workspace-backed service layer used by CLI and MCP. In other words: same governed practice, different shell.

The package README states this plainly: this pointer is not the old monolithic plugin, not a standalone web app, and not evidence that every emitted host pack runs inside DSH. The documentation page repeats the same discipline. One installed @asd/ui package. One composed profile. One loopback Studio. One canonical tool registry behind it. That is a cleaner story than the earlier historical descriptions, and it is the story that survives contact with receipts.

Installing the Profile

The profile lifecycle has to use the host’s official commands. No copying files into random folders. No editing the Harness checkout. No pretending a manifest pointer is an installer. The verified shape is the ordinary DSH lifecycle: add, update, remove, then launch the web host with the same profile. The placeholders below are intentional because the package or local bundle path is deployment-specific. What matters is the lifecycle shape, not a fake universal URL.

# Run from the DeepSeek Harness checkout.
dsh plugin --profile <profile> add <asd-ui-package-or-bundle>
dsh plugin --profile <profile> update <asd-ui-package-or-bundle>
dsh plugin --profile <profile> remove <asd-ui-package-or-bundle>

dsh web --profile <profile> --port <loopback-port>

For the pinned receipt, the profile name is asd-live-review2. The verified compatibility revision is 3f88a0f63f9788959b4e889b78653798bb7d6aae+asd-phase5-e94f006f2283. I treat that revision string as a contract, not a convenience label. If my local host revision differs, I am outside the receipt. I can still experiment, but I am no longer entitled to reuse the claim that the rc.5 seam was proven.

The release gate is equally concrete. Official add/update/remove/reinstall must succeed. The six required slots must be present. The package must still be portable after install. The Studio must load on loopback. The project count and workspace root must be the expected disposable values in the smoke run. ASD-owned accessibility violations at serious or critical level must stay at zero for that smoke. Shutting down the server must remove the temporary workspace created for the check. That is why the profile story is worth documenting. It is lifecycle evidence backed by a receipt from a real machine.

There is another quiet benefit to doing it this way. Because the adapter bundle carries its own inventory and compatibility expectations, the boot can fail loudly when the Harness seam drifts. The code checks the exact rc.5 package versions it depends on, validates the role, skill, template, and corpus inventories, and refuses to register the web routes when the host is not loopback. That is the correct failure mode. A partial Studio that appears to work is worse than a hard stop.

Studio Slots: Activity, Conversation, Settings

The receipt records six host slots: sidebar.activity.action, sidebar.activity.panel, conversation.view, conversation.showView, settings.plugin.item, and layout.openActivity. Three of those are user-visible surfaces. Three are the navigation seams that make the visible surfaces coherent. Together they let ASD appear as a first-class citizen inside the Harness instead of as a floating afterthought.

The important thing is that the Studio is mounted twice over one shared store. I can open it as a center-column tab or as a sidebar activity panel, and both surfaces read the same project, evidence, artifact, review, and report state. Article 36 describes this well: tool cards rendered in the chat for sd_project_create, sd_evidence_add, sd_artifact_write, sd_artifact_get, sd_artifact_list, and sd_review can carry an Open in Studio action that lands on the exact project or artifact the tool call touched. That is workbench design, not screen dressing. The browser and the tool runtime are pointing at the same object.

There are currently three user-facing entry points I rely on: the sidebar Service Design activity, the Studio conversation view, and the Settings → Plugins card. Those are the surfaces I touch. The other two names that sound more abstract — conversation.showView and layout.openActivity — are why the handoff feels integrated instead of clumsy. Without them, every click-out from chat would strand me in the wrong place.

Loopback Routes and the RPC Allowlist

The workbench lives on two loopback routes only: /asd/app serves the static Studio assets and /asd/rpc exposes a bounded JSON-RPC channel. The adapter refuses to register either route unless the Harness web server host is exactly 127.0.0.1. That is not a suggestion. It is a boot-time guard. If the host is bound elsewhere, @asd/ui stops. I like that decision because it makes the threat model legible. This Studio is a local workbench, not a quietly internet-facing admin surface.

The static side is deliberately dull. The handler serves the Studio files under /asd/app, returns index.html for the bare prefix, sets the right content types, and rejects traversal attempts such as raw /asd/app/../../../../etc/passwd requests with a 404 instead of walking out of the asset root. It also rejects unsafe verbs. That sounds mundane. Good. Static serving should be boring.

The interesting boundary is the RPC channel. The source code labels it a closed allowlist: no eval, no passthrough, and nothing that writes. The methods validate their own parameters and read through AsdService. The allowlist covers project summaries, artifact and evidence reads, method and template browsing, review rows, canvases, fact-check projections, orchestration status, report generation, and related read models. Every browser request must be a POST with JSON content type. Cross-site browser requests are rejected. If an Origin header is present, it must be the loopback Harness origin on http://127.0.0.1:<port>. Request bodies are capped at 64 KB. Bad input resolves to a client error instead of a silent fallback.

PORT=3788

curl -i "http://127.0.0.1:${PORT}/asd/app"

curl -i \
  -X POST "http://127.0.0.1:${PORT}/asd/rpc" \
  -H 'content-type: application/json' \
  --data '{"method":"getProjectsSummary"}'

The read-only posture of /asd/rpc is easy to miss if you only look at screenshots. The Studio can inspect and coordinate. The canonical tool runtime still owns mutations. That is the right split. I do not want an ad hoc browser method sneaking around the acceptance gate or the review contract. If the browser needs to show a review board, it asks for review rows. If I need to write an artifact, review it, or advance a phase, I go through the canonical operation path where the same rules fire as they do in CLI and MCP.

Capability Projection: 24 Rows, One Unsupported

The capability projection is where the DSH workbench stops being a vibe and starts being a machine-readable contract. The current capabilities.json for the DSH surface contains 24 rows. Twenty-three are supported. One is explicitly unsupported: phase.gate.status. That unsupported row is a feature, not an embarrassment. It tells me the boundary is enforced by proof rather than optimism.

The supported rows are not a claim that the Studio has 23 shiny buttons and therefore “covers the whole platform.” They say something more technical and more valuable: if the Studio advertises one of these operations, it executes the exact canonical tool definition named in the row. The source lists them one by one: project.list, project.create, project.open, project.status.set, evidence.add, evidence.import, artifact.list, artifact.get, artifact.write, canvas.add, canvas.list, canvas.remove, method.list, template.list, template.get, schema.get, review.list, review.run, factcheck.run, orchestration.status, orchestration.dispatch, orchestration.handoff, and phase.advance.

Two absences matter. method.run is a canonical tool concept, but it is not a separate direct Studio capability row. Neither is evidence.query. The browser can still expose supported query surfaces for those concepts, but clients must not invent new direct capability IDs. And when a client asks for something unsupported or unknown, the adapter fails closed. The documentation names the error contract clearly: CAPABILITY_UNSUPPORTED, no silent downgrade, no “close enough” reroute to some other method. The core capability source puts the same philosophy in code: return a supported operation or fail loudly; never silently downgrade.

If you inspect the review board in Figure 20.2, you can see why this contract matters. Review is not decorative chrome around chat. The row carries status, gate, verdict, linked log artifacts, and acceptance failures. A refused write can sit there as a draft with explicit reasons. A passed review can sit there with evidence-cited rows. The board is useful because the operations beneath it are named and bounded.

Portable Bundles and Isolation

The DSH receipt is strong because it verifies properties most teams would leave implicit. It does not stop at “the plugin installed.” It pins the bundle hash, counts the bundle entries, checks for absolute paths and symlinks, proves byte-identical output across distinct checkout roots, records the official remove-and-reinstall cycle, and confirms that the live smoke used a disposable workspace that vanished cleanly when the server stopped. That is the level of evidence I want for a workbench that is supposed to travel between machines and profiles.

{
  "package": {
    "name": "@asd/ui",
    "version": "0.5.0",
    "bundleSha256": "8c7aa34f02c1df50030cf2faa6c0dd23098c38afbf1248d8607ef07fc8157484",
    "entryCount": 502,
    "absolutePaths": false,
    "sourceTreeImports": false,
    "symlinks": false
  },
  "verification": {
    "uiTests": 120,
    "workspaceTests": 701,
    "bundleSafety": "pass"
  },
  "profile": {
    "name": "asd-live-review2",
    "slotCount": 6,
    "officialRemoveReinstall": "pass"
  },
  "liveSmoke": {
    "projectCount": 0,
    "pluginOwnedSeriousOrCriticalAxeViolations": 0,
    "serverStopped": true,
    "temporaryWorkspaceRemoved": true
  }
}

The portable-bundle claim has three parts. First, the archive is self-consistent: 502 entries, no absolute source paths, no source-tree imports, no symlinks. Second, the build is stable: the receipt records byte-identical outputs from distinct absolute roots and a stable SHA-256 for the package bundle. Third, the runtime footprint is disposable: the smoke runs with a loopback server, an empty project count, and a temporary workspace that is removed on shutdown. That is what I mean by an integrated workbench. It is not merely mounted inside the shell. It is installable, movable, inspectable, and removable without dragging half a source tree behind it.

Accessibility belongs in the same proof set. The receipt records zero ASD-owned serious or critical accessibility violations in the live smoke. That phrase is carefully scoped. It does not mean the whole Harness had zero violations. The receipt even records bounded host-owned exceptions separately. I appreciate that level of honesty. When a platform tells me what belongs to it and what does not, I can improve the right thing instead of laundering host defects through the plugin’s success story.

The Center-Tab Studio

Until the Studio v2 merge, the center tab was a respectable read surface: project summaries, artifact views, the review board. Useful, but passive. Article 38, The Center-Tab Studio: Live Service Design Journeys Inside the DeepSeek Harness Shell, is now live, and it documents what the merge changed: the center tab became an engagement surface in its own right. Three workspaces share it — a kanban board for the engagement lifecycle, a knowledge-base Library browser, and a canvas preview workspace. Each reads the same workspace-backed store the rest of this chapter describes. None of them forks it.

The kanban board renders every engagement as a project card carrying its design phase, draft and veto badges projected from the review state, and the latest status note. Moving a card is a first-class operation, not a visual trick. Drag-and-drop and the keyboard Move menu both call the project.status.set capability row, which executes sd_project_status_set under its legal transition rules: briefed → active → gated → blocked → archived, archived reachable from any state, blocked ↔ active, and same-status calls treated as no-ops unless a note accompanies them. The board updates optimistically so the interaction feels immediate, and it rolls back visibly when the engine refuses a transition. The property I care about is that the refusal path exists at all. A board that let me drag a project into any column would be a board I could not trust.

The Library browser turns the 228-resource knowledge base into something navigable from inside the shell: methods, templates, and article READMEs, each carrying its provenance. The detail that earns its place is cited use-in-project — a Library entry shows which engagements have actually applied it, so reuse is visible evidence instead of an anecdote about a method being popular. The canvas preview workspace does the equivalent job for canvases. Compare mode puts two states of a canvas side by side. The evidence spotlight rail keeps the cited records beside the canvas instead of a click away. SVG and PNG export take a view into a deck or a review pack without a screenshot of a screenshot.

Article 38 walks this surface end to end on two paired engagements: Aurelia Trade Finance, a trade-finance modernisation, and Meridian Oncology Partners, an oncology-network coordination problem. Both are fictional composites, per the series convention, and the run is bounded in the same way the Wattle Grove walkthrough below is bounded. The Studio v2 surface is demonstrated in that bounded run, and the per-kind typed schemas for richer artifact views remain Phase 2 work. What the article proves is the loop — board, Library, canvas, review — holding together over one shared store. It does not prove that every artifact kind already has a bespoke typed renderer.

The Live Build, Running

Everything above this line describes the integration as a contract. As I write this, the contract is running on my desk: the asd-studio-v2 profile serving on 127.0.0.1:4685. The host's own boot manifest is machine-checkable, so I checked it. The host booted at revision ad3ba0951ddb with 39 plugin entries, and among them sits @asd/ui at revision 367432b4e475, its client served from /plugins/@asd/ui/client.js at roughly 707 kilobytes. Reading the served bundle itself confirms the surfaces this chapter describes by name: the Agentic SD Studio center tab registered through the conversation.view seam, the Kanban lifecycle including the briefed column, the Library with its cited Use in project action, the canvas workspace, and the jobs-to-be-done kind. That is source-level proof of what the host is running. It is not, by itself, proof of what a model turn did — that proof stays with Article 38's receipts. Two different questions, two different evidence kinds, and I keep them apart the way I keep the DSH receipt apart from the bounded prior workflow evidence.

Four pieces of the v2 build deserve their own paragraphs here because they changed how I actually work, and none of them is a new place to put a button.

The composer knows the engagement. The input dock chip reads the project — name, phase, gate state, draft count — instead of just its label, and its Project-actions menu drafts phase-aware instructions: a "suggest next step" framed by the orchestrator with an explicit wait-for-confirmation, or a gate report. The posture is the same one the create form established: the Studio drafts, the human reads, edits, and sends. Nothing fires on a click that I have not read first.

The guided interview. Selecting a template or a method in the Studio used to mean hoping the model guessed the context. Now it starts an interview. The drafted instruction tells the model to review existing project evidence first, ask me focused questions one at a time, and only then write the artifact, run the critic, and report the verdict — with a hard guard requiring at least three answered questions before any artifact is created. All seven authored templates, the original six plus jobs-to-be-done, open their interview with a question. In the acceptance run, one journey-map interview ran five question rounds before it produced anything. The interview is where the model's ignorance becomes visible early, while it is still cheap.

The right panel, taken seriously. The host reserves a single details seat beside the conversation, and the contract says one occupant renders there. The v2 build takes the seat deliberately: an artifact write opens its sanitized SVG render with badges and an Open-in-Studio deep link; a review opens its verdict card; a factcheck opens a pass/fail table; anything else falls back to the host's default faithfully. The receipt line I keep retelling: the first live boot of this build failed loudly because the host already held the seat at priority 0, and the fix was to register at −10, because the lowest rank renders. Activation, not registration, is where takeover seams bite — this chapter has now shown that twice.

Six new kinds. The artifact-kind registry grew from 32 to 38: jobs-to-be-done, day-in-the-life, touchpoint-inventory, service-scenario, expectation-map, actor-network-map. Each carries a closed schema, a deterministic renderer, and a method manifest, and each entered through the same gated write path as the original 32 — the live turn wrote two of them through it. The kind count is the least interesting number in that sentence. The interesting part is that expansion did not require a new door.

Case: Wattle Grove Community Care

Wattle Grove Community Care is the right case for this chapter because it shows both the promise and the discipline of the workbench. The client is fictional and composite. The evidence is synthetic and declared as such. The current DSH integration receipt and the bounded prior workflow evidence are deliberately separated. That separation is the whole lesson. The workbench lets me run a serious service-design engagement in one host surface, but it also forces me to label exactly which parts were proven by the current rc.5 integration and which parts were proven earlier through bounded workflow receipts.

I like to begin the walkthrough with the settings surface because it tells me the integration is real before I even touch the case. The ASD plugin item is where the workbench exposes its own namespace and lets me set workspace root and default phase. From there, the Wattle Grove engagement follows the shared ASD loop. The designer creates the project, captures eight evidence records, pulls the relevant methods, writes typed artifacts, reviews them, fact-checks them, and stops at a human gate.

The service problem is concrete. Wattle Grove is an in-home aged-care provider with roughly 1,900 clients and 240 support workers. Clients keep seeing unfamiliar workers. Families are not told about changes. Schedulers trade continuity away whenever coverage gets tight, because an uncovered visit is a contractual breach while continuity is a quality the organisation cares about but does not measure. The evidence pack for the case is small on purpose: two client interviews, two family interviews, two support-worker interviews, one scheduler interview, and one operational telemetry figure. The workbench does not need a fake data mountain. It needs cited records that can anchor each artifact node.

From there the method sequence is the canonical one. Stakeholder mapping comes first because the quotes come from four different groups whose interests conflict. The resulting map has six stakeholders. The care recipient and family carer have the highest lived stake, but the scheduler and the regulator carry the highest operational influence. That asymmetry matters because it tells me continuity failures are not random UX glitches. They are downstream of backstage incentives.

The journey map then renders the service as six evidence-backed stages. The quotes are the story. “I get dressed and wait by the door from eight.” “I have never met most of these clients and there are no notes.” “Eleven different girls came. I stopped telling them where things are kept.” “Nobody comes until eleven and no one rings.” “I only find out Mum had a new carer when she tells me she was upset.” “I took the day off. They arrived at 2pm. I lost a day’s pay.” Read those together and the case becomes legible. The platform is not inferring a sentimental narrative. It is forcing each stage to resolve back to an opened record.

The blueprint deepens the diagnosis. Article 36 reports twenty nodes across five lanes, with eleven fail or wait points. Worker arrives with no client context. Run-sheet generation excludes care-plan data. Client meets a stranger again. No dynamic resequencing or overrun alert. Family not notified. Compliance measures completion, ignores continuity. Complaint signal never reaches rostering policy. That is a workbench doing actual service design. I can move between the conversation, the evidence register, the artifact view, and the review board without losing the thread because the store underneath is one store.

Then comes the moment I care about most. Somebody asks for a better story than the evidence supports. In the bounded prior workflow, the designer explicitly asks for a current-state journey stage saying the client receives a proactive evening SMS with the worker’s name and photo and feels reassured, even though there is no evidence for that state. The platform refuses the write. This is the kind of refusal I want from an integrated workbench: precise, persistent, and public to the human reviewer.

{
  "accepted": false,
  "status": "draft",
  "artifact": {
    "id": "ef0c010c06af4559a1c0ad588c4a0fba",
    "kind": "journey-map",
    "status": "draft",
    "check": {
      "pass": false,
      "failures": [
        { "rule": "min-nodes", "message": "expected at least 3 nodes, found 1" },
        { "rule": "min-evidence-per-node", "nodeId": "stage-proactive-sms", "message": "node \"stage-proactive-sms\" cites 0 evidence refs, needs 1" },
        { "rule": "field-non-empty", "nodeId": "stage-proactive-sms", "message": "node \"stage-proactive-sms\" has an empty \"touchpoint\"" }
      ]
    }
  }
}

The phrasing matters. The write is refused because accepted is false. The artifact is also persisted because the status is still draft. The failed attempt remains visible on the review board with the machine-readable reasons attached. Nothing has been silently “fixed.” Nothing has been silently discarded. Nothing has been silently promoted. The human holding the gate can see the exact attempted distortion and the exact reason it failed. That is why the review board in Figure 20.2 matters so much. It is where the workbench surfaces the moral discipline of the engine.

Remediation happens in place. The same artifact can be rewritten with valid cited nodes, then reviewed with an evidence-cited pass that promotes it to final. A veto does the opposite: it demotes the artifact to draft and writes a linked review-veto-log. And the phase gate still belongs to a human. The workbench prepares the decision, shows the evidence, and records the outcome. It does not seize authority.

That is why Wattle Grove is a good workbench case. It is not a glossy demo about a plugin opening a pane. It is a bounded proof that the Studio can carry a real engagement shape — project, evidence, methods, artifacts, reviews, reports — while preserving the harder property: refusal of unevidenced improvement theatre.

Receipt Boundaries

By this point you should have a feel for the workbench. Now I want to state the limits as sharply as the capabilities. The receipt proves one profile composition for DSH 0.1.0-rc.5 with @asd/ui 0.5.0, profile asd-live-review2, the pinned compatibility revision, six host slots, official lifecycle success, portable bundle safety, 120 UI tests, 701 suite tests, loopback Studio smoke, workspace isolation, and zero ASD-owned serious or critical accessibility violations in that smoke. It also links bounded prior workflow evidence showing the evidence → artifact → review/remediation → pass → human-gate shape.

It does not prove every provider and chat dispatch combination. It does not prove every external MCP client inside the host. It does not prove every future rc build, every DSH profile, or every possible role execution path. It does not turn ACP into a transport; ACP remains record-only. It does not make BUZZ messages or Canvas documents appear in the ASD workspace automatically. And it does not let me round up from one bounded case to a universal “the host is fully live” claim.

That last row is the one I care about most. Boundary honesty is not a legal disclaimer stapled on after the fact. It is part of the product design. When a workbench tells me what it cannot yet prove, I can trust the things it says it has proved. DSH and @asd/ui earn that trust here. The shell is real. The adapter is real. The workbench is real. The limits are real too. That combination is what makes this surface useful enough to rely on.