dsh-shared-blueprint

dsh-shared-blueprint

English | 中文

The standalone Shared Blueprint Interactive Preview package for DSH. One package owns the Host adapter, durable event types, generated Remote, browser client, and additive composition patch. The standard Web bundle does not mount Blueprint; installation is explicit. Inspect Mode is not included.

Version 0.1.0-beta.1 is a working Preview/Beta under active stress testing and compatibility hardening. It is a third-party package, not an official DeepSeek plugin. It currently requires the compatible DSH checkout; untouched DSH 0.1.0-rc.7 plus this package is unsupported.

Installation

Install a prebuilt tarball into the Web profile, then start the ordinary Web app:

dsh plugin --profile web add ./dsh-shared-blueprint-0.1.0-beta.1.tgz
dsh web

The bundle adds one shared-blueprint Host row. Its dsh.client declaration loads the matching browser plugin, which mounts the package's generated Remote contribution before registering its additive Layout, Sidebar, and Conversation surfaces. Removing the bundle removes both faces; no Blueprint row remains in dsh-web-app.

ctx.blueprintAdapter.read(presetId, { agent? }) projects a real agent preset together with the scoped systemPrompt.assemble() result and the permission preset for a future or live session. Without a live agent, it captures committed metadata, composition text, and one standing scope key in a single AgentPresets projection snapshot, then reuses that key for assembly and Skill reads. It emits Purpose, Identity, Capabilities, Behavior, Output, and Access nodes without creating values for absent sections.

During service startup the adapter registers its required durable Session event types under the package's npm identity. The same registration path applies when the package is bundled into a DSH build or installed out of tree; a conflicting owner or duplicate live adapter fails during composition before any Blueprint Session is decoded.

Every node carries id, type, value, source, status, editable, and adapterRef. source distinguishes preset text, assembled runtime state, inherited Host/session policy, and semantic classification inferred from persona prose. Optional sourceLanguage is open metadata derived only from recognized Unicode-script evidence in authored semantic text; an undetermined Latin-script value is not labeled English. The client chooses fixed Blueprint label translations separately and never translates Tool, provider, Skill, configuration ids, or semantic values. The root revision is the SHA-256 of the composition text; runtime retains the exact tool names, prompt-section names, and permission bundle used to validate the projection.

Capability projection also reads the target preset's scoped ctx.skills snapshot and active literal tool-subagent composition rows. Skill nodes expose identity, a short description, invocation policy, and scoped ownership while retaining a Host-only definition digest. Delegation nodes describe the configured Tool name, provider, one-shot or continuable mode, persona summary, and provider availability; their runtime summary also retains a SHA-256 of the complete parsed row config, including nested agentOptions, toolFilter, maxDepth, and unevaluated !!js expression nodes. An active row with maxDepth: 0 is reported as a mapping gap instead of a usable delegation because its first child call cannot start. Both node kinds are read-only: the current Skill registry has no per-preset mutation API, and a delegation row cannot be safely changed without preserving arbitrary Loader expressions and provider lifecycle state.

Write operations

Behavior discovery reads only the real persona.config.text. Explicit 行为规则, 行为约束, 工作方式, 规则, 约束, Behavior, Rules, Behavioral rules, or Constraints headings admit numbered lists, bullets, and constraint prose, including lists folded by YAML >-. A recognized Identity paragraph ends the rule section, so a trailing runtime introduction cannot become part of its last rule. Existing numbered workflows retain their ordinal addresses; Output sections and explicitly labeled numbered Output do not supply Behavior. Recovered rules retain exact parsed source evidence and semantic/display values. A missing or unsafe ordinal write anchor makes them read-only, not invisible; empty rule sections and ambiguous numbering produce mapping diagnostics. Identity, Purpose, and Output discovery remains independent.

The transaction owns five internal typed operations: updateIdentity, updatePurpose, updateBehavior, updateOutput, and setCapability. They are not single-node Remotes. Identity and Purpose projections retain their persona paragraphs as source evidence, extract user-level semantic/display values, record deterministic projection kinds, and expose write-back only for one unique replacement span. Creator-authored personas use 角色：… or Role: … for Identity, 目标：… or Purpose: … for Purpose, and a standalone 输出：… or Output: … line for Output; supported legacy clauses preserve surrounding text, while ambiguous prose remains read-only or absent. A standalone Output is projected read-only because the current typed write address is ordinal; an explicitly labeled numbered item retains the existing Output write path. The capability operation admits only web-search and web-fetch. Apply resolves the target through ctx.agentPresets, refuses non-user trust, verifies the Blueprint revision and expected field value, stages one physical YAML line or one tool-web boolean per confirmed operation, and publishes the complete file through writeFileAtomic. It never parses and reserializes the whole composition, so comments, row order, !!js, and unrelated formatting survive.

Writes affect later sessions through the existing stamp-keyed standing generations. A live session remains on the generation it joined; re-reading without an agent resolves the next generation, and reading with an agent reports that agent's exact assembly.

The generated blueprint Remote namespace exposes get, applyChangeSet, cancelChangeSet, setConversationContext, and validateSession. Validation binds a new live Session to the requested preset through both its durable header and joined composition, requires the UI's expected Blueprint revision to remain current, and compares Identity, Purpose, Behavior, and Output values with the text of their live assembled sections. A replacement may preserve its prior text as a substring; conformance proves the current projected value in an expected assembled section instead of treating prior-text absence as runtime evidence. It compares enabled and disabled capabilities with the live scoped Tool set and hashes each enabled model-visible Tool schema, compares scoped Skill identity, definition digest, and invocation policy, verifies delegation Tool and prompt evidence plus provider availability, then compares the live resolved permissions. The result returns section names, node ids, schema and section digests, and pass/fail states without returning prompt, schema, or Skill-definition content. A request may name a committed Change Set only through its complete sourceSessionId, routeId, and changeSetId identity. Validation resolves that exact Apply receipt from the restored source Session log and requires its preset and committed revision to match before joining P0 preflight, preset-write, reprojection, and drift evidence to the runtime checks; the association therefore survives an adapter process restart. The Web transport pins every Blueprint endpoint to loopback because reads expose composition details and writes change what later sessions mount.

Conversation proposals

If the Client leaves a source Session while its claimed Add-capability routing turn is still open, a clear-only context request retains that exact Session's typed routing binding until the matching turn/end; other Sessions keep independent Agent-scoped bindings.

Add capability submits capabilityInput.routeId and capabilityInput.userRequest through setConversationContext. The Host records blueprint/routing-input, binds the interaction to the exact admitted message, source Session and target, and supplies routing guidance separately in request context. create-agent must quote the current original request and is forbidden for that capability action; a later independent user message can change the goal. blueprint/route-decision reserves one operation per routeId before asynchronous checks. Other operations cannot take over the same interaction, including after a rejected attempt; only failed attempts of the same operation may retry. A distinct interaction may select another operation even when it uses the same target preset or source turn. Add capability rejects Identity, Purpose, and Behavior approximations before they reserve existing-edit ownership, so reusable procedures and collaborators can still enter Skill or Subagent authoring. Accepted proposals and authoring routes conclude their source turn. Active authoring context still blocks proposals, but prose mentioning creation does not. Routing provenance and arbitration records the evidence and limits.

Apply supplies required sourceSessionId, routeId, and changeSetId. The Host resolves the matching successful propose_blueprint_change Tool result, route decision, and meta.blueprintChangeSet from that Session, derives the only authorized operation batch, and rejects missing, foreign, or modified content before any preset write. It compares array order, operation discriminants, targets, and typed scalar fields, so transport object-key order has no authority and cannot create a false mismatch. The Proposal result is checkpointed before the transaction. Apply and cancelChangeSet share the preset's serialized queue and publish one immutable terminal citing the Proposal result sequence; a repeated matching decision is idempotent, while Apply and Cancel reject one another. setConversationContext returns every applyReceipt with the exact sequence of its durable Apply terminal, plus proposalCancellations, for refresh recovery. Clients therefore order committed receipts by Apply completion rather than Proposal creation. Later revisions do not erase either terminal.

setConversationContext scopes the current Blueprint revision, optional selected node, one runtime-context contribution, propose_blueprint_change, route_blueprint_capability_authoring, and route_blueprint_creator_authoring to a live existing-Agent Session. Selection supplies context but does not authorize a write. A structured editor submission carries its source Session, route, node id, node type, expected scalar, and proposed scalar. The Host validates Identity, Purpose, Behavior, Output, or an independently writable Web capability against the committed projection, enqueues a durable routing input and user message, and performs no write. The Proposal Tool must reproduce that source edit first and may add only Host-discovered dependent candidates; Apply remains a separate terminal UI action. Direct conversation proposals use the same durable authority path. The Creator route accepts only the model's typed create-agent classification, preserves the exact direct-user request, attaches open sourceLanguage metadata only when its script is recognized, and performs no preset write. Capability and Creator routes remain separate Tools, so changing an existing Agent or adding a Skill or Subagent cannot be reclassified as new-Agent creation by the client.

The client continues an accepted Creator route through the normal cordis executor. The source first checkpoints the exact request, display name, optional sourceLanguage, source turn, route id, and reserved Creator identity in blueprint/creator-authoring; successful result publication cancels only its current turn. The distinct target adopts that context. The Host starts its continuation only after the exact source turn has ended and whenIdle() proves quiescence, deduplicating delivery through the target's durable inbox receipt. Allocation or termination failure cannot start Creator and leaves the source history intact; admission requires reopening an unloaded source. Exclusive handoff records ordering and failure semantics. Creator guidance preserves the request language, treats absent metadata as undetermined, and recovers legacy language events. Legacy direct requests inside cordis retain the coordinator's message-parser fallback.

The capability-authoring route performs no write. It accepts only skill or subagent, binds the result to the current preset and revision, and rejects stale or mismatched context; the unimplemented composition kind is not admitted. For continuation, the Host reconstructs the exact route, source, target, revision, request, and kind from one successful route_blueprint_capability_authoring Tool result with its matching call and source-owned route decision. The browser request may only reproduce those fields. A cordis source owns the lifecycle directly after its exact routing turn ends. A non-cordis source and legacy records retain the domain-separated deterministic cordis worker; first adoption permits only the at-most-once permission/preset, sandbox/mode, and approval/policy initialization facts and rejects all prior task or authoring history. An existing blueprint/capability-authoring start is the durable retry receipt. A foreign owner, non-cordis composition, contaminated legacy worker, failed or incomplete source route, modified DTO, or replay after settlement is rejected before any lifecycle or conversation binding changes. The lifecycle-owning Session checkpoints the source Session and route, base revision, every roster entry's trust, display metadata, health, and composition digest, the projected node baseline, every scoped Skill summary, and every delegation summary with its complete config digest. Completion first proves that every non-target preset record is unchanged, the target metadata is unchanged, and every existing Skill and delegation has the same typed fields and digest as its baseline. It then requires exactly one allowed target capability addition, preserves every baseline node, and rejects a cross-kind or second capability addition. Skill completion additionally requires that one addition to be a new target-owned callable definition. Subagent completion additionally requires that one addition to be a new provider-backed delegation with a fresh target-bound P1 verification Session. Host-owned terminal settlement and lifecycle-scoped user cancellation remain durable, and refresh never resurrects an ended lifecycle. Capability continuation authority records admission; exact capability baselines record delta authority.

The Host clones the complete target directory into a hidden sibling candidate while holding an exclusive target lease. The Creator sees only that candidate through a scoped roster overlay and may write only inside it; the formal preset and committed Blueprint remain unchanged. Each quiescent Creator turn first passes an exact composition allowlist, then a fresh isolated Session proves real mount, lane-specific runtime conformance, and active capability projection. A failed attempt writes a private typed diagnostic and wakes the same Creator under the same source Session and route; the source stays configuring while bounded repair