v1.7.3

Fixed

• Template scaffolds no longer pin v0.0.0. dockyard new --template analytics-widgets / --template approval-flows previously hardcoded
  require github.com/hurtener/dockyard v0.0.0 in the generated go.mod, so a
  project scaffolded with a published CLI failed go mod tidy with
  unknown revision v0.0.0 unless --dockyard-path (and its replace
  directive) was supplied. The template go.mod.tmpl now resolves the Dockyard
  version through a __DOCKYARD_VERSION__ token — the same release-version pin
  the blank scaffold already applied — so a go install …@latest CLI pins the
  real release version and resolves the published module flag-free
  (D-186).
• The distributed inspector now actually works. Every distributed dockyard
  binary — both go install …@latest and the cross-compiled GitHub Release
  downloads — previously shipped a non-functional inspector: dockyard dev /
  dockyard inspect served a placeholder page ("The inspector frontend has not
  been built yet") because the embedded Svelte SPA bundle was gitignored and
  neither distribution channel ran the local make inspector-bundle step. The
  bundle (internal/inspector/dist/) is now committed, so the embedded inspector
  is the real SPA on every channel; a CI freshness gate
  (make inspector-bundle-check) keeps the committed bundle in lock-step with
  web/inspector source (D-187).

Documentation

• Template walkthroughs now spell out the web setup before the dev loop. The
  getting-started and template-walkthrough pages make explicit that a template
  ships a Svelte UI requiring (cd web && npm install) and a one-time
  dockyard build before dockyard dev — without them the dev loop fails with
  vite: command not found and open web/dist/index.html: file does not exist. The pages also document that dockyard dev auto-attaches the inspector
  (and the standalone dockyard inspect alternative), and lead the scaffold
  commands with the flag-free published-CLI form.

---

Commits

Fixed

• preflight: serialize the web/docs smoke gates under parallel execution (D-188)
• inspector: make inspector-bundle-check structural, not a byte-diff (D-187)
• scaffold,inspector: repair the published-CLI path; parallelize preflight

v1.7.2

Changed

• Published-docs refresh. The docs site (docs/site/) no longer reads as
  v1.0.0: install commands use @latest, the home "Released" callout is
  version-agnostic, and "V1" era phrasing is removed. The Svelte App sketches in
  the getting-started and UI-resources guides were rewritten to the real
  dockyard-bridge API (createBridge() → bridge.onToolResult(r => r.structuredContent) → bridge.connect()) — the previous sketches showed a
  top-level API that no longer exists — and now compose dockyard-ui's
  PageState. The inspector guide notes it validates the App handshake and sizes
  the preview; the approval-flows guide flags inline elicitation as
  Dockyard-host-only.

Fixed

• dockyard new --help no longer lists a non-existent inspector template
  (only analytics-widgets and approval-flows ship). The auto-generated CLI
  reference is regenerated accordingly.

v1.7.1

Fixed

• The approval-flows template now passes dockyard build. (D-184) A
  contract with a free-shape map[string]any field whose Go doc comment contains
  an example object literal (e.g. {"subscribers": 1247}) was wrongly reported as
  a schema↔TypeScript drift, blocking the build. The generated code was correct;
  the drift cross-check's line-oriented TypeScript parser mistook the example's
  closing } (on a JSDoc comment line) for the interface's closing brace and
  truncated the field list. The parser now skips comment content. Surfaced because
  the template smoke only ran go build, never dockyard validate — it now runs
  dockyard validate so this class of drift is gated.
• Both templates' READMEs gain a step-by-step build-and-run Quickstart
  (dockyard new → go run / dockyard dev → dockyard build →
  dockyard install).

---

Commits

Fixed

• codegen: drift cross-check skips JSDoc comment braces; templates buildable + README quickstart (D-184)

v1.7.0

Changed

• dockyard-bridge's ui/ wire layer is now pinned to the vendored official
  @modelcontextprotocol/ext-apps schema. (D-182) The bridge previously
  hand-transcribed the MCP Apps wire dialect, which drifted silently (the cause
  of the 1.6.1 handshake bugs). The schema is vendored into the repo by upstream
  SHA, and a wire-conformance test now .parse()s the bridge's outbound wire
  against it — a drift is a failing build, not a blank App in a host. The shipped
  App bundle stays Zod-free and consumers need no schema dependency (the schema
  is referenced only by the bridge's test layer).
• HostContext gains schema-accurate fields (additive). containerDimensions
  now models flexible sizing (maxWidth/maxHeight) alongside fixed
  width/height; styles gains css.fonts; toolInfo, platform, and
  deviceCapabilities match the schema.

Fixed

• dockyard-bridge advertises appCapabilities.availableDisplayModes, not
  displayModes. (D-182, item A) The host's parse silently stripped the
  non-schema displayModes key, so it never learned which display modes an App
  supported and fullscreen/pip degradation never worked. The public displayModes
  bridge option is unchanged.
• dockyard-bridge handles ui/resource-teardown as a request, not a
  notification. (D-182, item B) A spec host sends teardown as a request and
  waits for the View's response before tearing the iframe down; the bridge now
  responds, then closes. Adds the app-initiated ui/notifications/request-teardown
  (BridgeShell.requestTeardown()).
• dockyard-bridge applies host fonts. (D-182, item D) Host-provided
  styles.css.fonts CSS is injected into the View document so the host's fonts
  load.
• ui/message and ui/update-model-context now send schema-conformant
  content. (D-182 — checkpoint audit) Both sent a bare-string content (and
  ui/message allowed a non-user role); the schema requires content: ContentBlock[] (and role: "user"), so a spec host would have rejected them.
  sendMessage now wraps a string into a text block; UpdateModelContextParams.content
  is ContentBlock[]. The conformance test now .parse()s every View→host
  request (open-link, message, request-display-mode, update-model-context), not
  just the handshake.
• The local inspector consumes the View's size-changed and request-teardown.
  (D-182, item 4 — checkpoint audit) It sizes the preview iframe to the App's
  reported content height (mirroring a real host) and remounts on a teardown
  request, instead of silently dropping both.
• Conformance coverage extended to the full wire (D-182 — second audit pass).
  The conformance layer now also guards the bridge's inbound reads (a
  schema-valid tool-input/tool-result/tool-cancelled/host-context-changed
  reaches the App subscriber with every field intact), the inspector's
  outbound host→View wire (the reference host's ui/initialize result,
  request-display-mode result, and notifications .parse() clean), and the
  server-emitted _meta.ui + capability shapes. Inbound notification types
  (arguments, width/height) are now optional to match the schema.

Packaging

• dockyard-bridge/spec exposes the vendored ext-apps schema (used by the
  inspector and the bridge's own conformance tests). Its zod +
  @modelcontextprotocol/sdk imports are provided by the consumer (devDependencies
  of both dockyard-bridge and web/inspector); they are intentionally not
  declared as peer dependencies — an optional peer makes a bundler stub it and
  breaks the production build. The package's . entry imports no zod, so App
  authors importing only . install nothing extra.
• The local inspector is a faithful, validating spec host. (D-182, item 4) It
  no longer sends a host→View ui/notifications/initialized; it marks itself ready
  when the View sends initialized, reads availableDisplayModes, and now
  validates the View's ui/initialize against the vendored schema, rejecting a
  non-spec shape with a JSON-RPC error. This removes the leniency that let the
  1.6.1 View bugs pass locally — the inspector now catches them. The schema is
  shared via a new opt-in dockyard-bridge/spec subpath (the package's . entry
  stays Zod-free for App consumers).

Notes

• Dockyard's Tasks×Apps ui/ notifications (task-progress,
  elicitation-response) are now explicitly fenced as Dockyard extensions
  outside the MCP Apps schema; they function only against a Dockyard-aware host
  (the inspector, or Harbor). (D-183)

---

Commits

Added

• inspector: validate inbound ui/initialize against the vendored schema (D-182, item 4)
• bridge: teardown-as-request, fence Dockyard exts, faithful inspector host (D-182/D-183)
• bridge: vendor ext-apps schema + wire-conformance test + items A/C/D (D-182)

Fixed

• inspector: resolve dockyard-bridge/spec zod from the inspector root (fixes make build in CI)
• bridge,inspector: checkpoint-audit fixes for v1.7 wave A (§17)

v1.6.1

Fixed

• dockyard-bridge ui/initialize now uses the MCP Apps ui/ dialect — a
  spec-compliant host no longer rejects the View handshake. (D-179) The View's
  ui/initialize request sent base-MCP {capabilities:{appCapabilities}, clientInfo}; the MCP Apps host (@modelcontextprotocol/ext-apps) validates the
  request against a strict schema requiring top-level {appInfo, appCapabilities, protocolVersion} (appInfo REQUIRED). The mismatch made the host return a
  JSON-RPC error for the first handshake message, so connect() rejected, ready
  never became true, and an otherwise-correct App rendered blank with no visible
  error. The bridge now sends the ui/ dialect shape. (Hosts only spoke this
  dialect; the local inspector accepted the base-MCP shape, which is why this
  passed locally.) The public clientInfo bridge option is unchanged.

• dockyard-bridge SENDS ui/notifications/initialized rather than awaiting it.
  (D-180) The handshake waited to receive ui/notifications/initialized
  before resolving ready. Per the JSON-RPC/MCP lifecycle (and the ext-apps
  reference View) the View is the initiator and sends initialized after the
  ui/initialize result, then is ready. A spec-compliant host never sends a
  View→host message, so the old code deadlocked. An inbound initialized from a
  non-spec host is now ignored.

• dockyard-bridge reports View content size to the host via
  ui/notifications/size-changed. (D-181) The bridge only ever received
  size-changed (host→View); it never measured or reported its own content
  height. A spec-compliant host sizes the App iframe from the View's report;
  without it the iframe collapses to ~0px and the App looks blank even after it
  paints. The bridge now runs a ResizeObserver and emits a de-duplicated
  size-changed on ready and on every change, torn down in close().

---

Commits

Fixed

• bridge: speak the MCP Apps ui/ dialect so a spec host renders the App

v1.6.0

Changed

• _meta.ui.domain is now a host-supplied verbatim value; server-side
  auto-derivation is retired. (Behaviour change — minor.) The MCP Apps spec
  makes domain host-dependent — the host mints the dedicated iframe origin
  and documents its format; a server copies it verbatim or leaves it empty.
  App.Domain is emitted on resources/read byte-for-byte; Dockyard no
  longer synthesises Claude's {hash}.claudemcpcontent.com subdomain (which a
  local connector rejects). What changes for you: a project that set
  HostProfile: "claude" + Domain previously got a derived
  claudemcpcontent.com origin and now gets its Domain verbatim — set Domain
  to the exact origin your host documents for a verified remote deployment, or
  leave it empty for the host's default per-conversation origin. App.HostProfile
  and App.ServerURL are deprecated (retained, ignored for derivation); the
  pluggable host-profile seam stays for a future host-blessed transform. The
  default scaffold and templates set no Domain, so they are unaffected. (D-176)

• A stdio-only server that sets a Domain now warns at startup. A dedicated
  origin is honoured only on a remote connector; a local (stdio) connector
  ignores it. ServeStdio logs a loud slog.Warn naming the App;
  HTTPHandler does not. (D-176)

• The product templates scaffold the html-style
  ui://<server>/<app>/index.html resource URI. This matches the reference MCP
  Apps SDK convention. The framework treats the ui:// URI as an opaque string,
  so this is a convention + docs change only — an existing project's
  ui://<server>/<app> URI keeps working. (D-178)

Added

• A server-level opt-in to additionally emit the deprecated flat tool-UI
  _meta key. server.Options{EmitLegacyToolUIMeta: true} makes every
  UI-bearing tool registered through the runtime/tool builder carry the
  deprecated flat key alongside the canonical nested _meta.ui.resourceUri, for
  a host that still reads the flat form. The default (off) is unchanged
  RFC-compliant nested-only output; the 2026-01-26 spec marks the flat form
  deprecated, so Dockyard never emits it by default. (D-177)

---

Commits

Added

• apps: v1.6 wave A — MCP Apps spec-alignment (verbatim domain, opt-in flat key, html-style URI)

v1.5.0

Changed

• The frontend packages are renamed to unscoped names: @dockyard/bridge →
  dockyard-bridge, @dockyard/ui → dockyard-ui. They publish under an
  unscoped personal-account name (the @dockyard org scope was unownable and
  blocked the v1.4.0 npm publish). An App's imports change accordingly
  (import { createBridge } from 'dockyard-bridge'); the templates and the
  attach-a-ui-resource skill are updated to match. Nothing was ever published
  under @dockyard, so there is no deprecation to manage. The internal
  inspector frontend keeps its @dockyard/inspector workspace name (it is never
  published). (D-174)

• Builder.UI gained an optional visibility variadic —
  .UI(appName, tool.VisibilityApp) sets _meta.ui.visibility for a UI-only
  action tool; omitting it keeps the spec default (model + app). New
  tool.VisibilityModel / tool.VisibilityApp consts. Behaviour change: a
  .UI("name") that references no registered App now returns a typed error at
  Register (previously a silent no-op) — register the App (apps.Register)
  before the tool. A correctly-ordered project is unaffected. (D-173)

Fixed

• A framework-wide wiring audit (the same class as the _meta.ui bug) fixed
  three declared-but-unwired seams:
  • require_spec_compliance is now enforced. The quality flag was
    declared, scaffolded true, and documented "enforced by dockyard validate", but no consumer read it — the spec-compliance check ran
    unconditionally, so toggling the flag did nothing. It now gates the check
    (opt-out), consistent with the other quality.* gates. All shipped
    manifests set it true, so no real project changes behaviour. (D-175)
  • @dockyard/bridge's ui/resource-teardown now tears the View down.
    The notification was documented as triggering BridgeShell.close() but was
    never dispatched — a production host sending it would leak the bridge's
    listeners/transport and leave ready stuck true. It now calls close().
  • The bridge retains the negotiated protocolVersion + hostInfo from
    the ui/initialize result (exposed as bridge.protocolVersion /
    bridge.hostInfo); protocol.ts promised retention but both were
    discarded.
• tool.New[...].UI(appName).Register(srv) now emits the tool→App link.
  The builder previously dropped it silently — the registered tool carried no
  _meta.ui.resourceUri (RFC §7.1), so a host that renders MCP Apps showed the
  text fallback instead of the App. The builder now resolves the App's name to
  its ui:// URI (via a new server.AppLink seam recorded by apps.Register)
  and emits _meta.ui at Register. The analytics-widgets template is fixed
  automatically (no template change). (D-173)

---

Commits

Fixed

• wiring: framework-wide audit — enforce require_spec_compliance, wire bridge teardown + handshake retention (v1.5 wave A)
• tool: wire the tool→App _meta.ui link in the builder (v1.5 wave A item 1)

v1.4.0

Added

• @dockyard/bridge and @dockyard/ui are published to npm. A
  scaffolded UI project's web/ now resolves them from npm with no
  --dockyard-path and no local Dockyard checkout — dockyard new --template analytics-widgets then cd web && npm install just works. The
  packages set publishConfig.access: "public", track the repo version, and
  publish from a gated, idempotent tag-push job (verified by npm pack + a
  scaffold-install build first). --dockyard-path reverts to a pure
  build-from-source convenience (D-172).
• Bridge View-side task-progress channel. @dockyard/bridge exposes a
  typed bridge.onTaskProgress((p) => …) subscription so an MCP App's card
  can render a live progress value (e.g. "62%") for a long-running task,
  fed by a new ui/notifications/task-progress host→View notification
  (RFC §8.4). The Dockyard runtime emits each TaskHandle.Progress /
  TaskHandle.Status call as an obs/v1 task.progress progress-phase
  event; the inspector forwards those to the App preview, so the channel is
  demoable through dockyard inspect. A host that does not forward progress
  degrades cleanly — the subscriber simply never fires (D-171).

Changed

• obs/v1 task.progress payload gained an optional fraction field
  (the task's completion fraction in [0, 1] at a mid-flight progress point).
  This is an additive change to the obs/v1 contract — existing
  consumers that do not read it are unaffected, the schema version stays
  dockyard.obs/v1, and the golden tests pin the new shape (D-171).

---

Commits

Added

• release: publish @dockyard/bridge + @dockyard/ui to npm (v1.3 wave B item 4)
• bridge: View-side task-progress channel (v1.3 wave B item 5)

v1.3.0

Added

• dockyard new --here — scaffold into an existing non-empty directory
  (e.g. one you already git init-ed). Existing files are left untouched;
  a scaffold output that would overwrite a file is refused, never silently
  overwritten.

Changed

• The require_fixtures and require_contract_tests quality gates are
  now enforced by dockyard validate (previously declared but inert).
  require_fixtures is UI-scoped — each tool with a ui: app must ship
  inspector fixtures (fixtures/<tool>/*.json); a non-UI tool needs none.
  require_contract_tests requires the project to carry at least one
  *_test.go. Behaviour change: a project that turned a gate on but
  does not satisfy it (a UI tool with no fixtures, or a project with no
  test) now fails dockyard validate where it previously passed. A freshly
  scaffolded project — blank or template — stays green.
• dockyard new pins the CLI's version into the scaffolded go.mod
  (instead of the v0.0.0 placeholder) when the CLI knows its release
  version, so a project that drops the local replace directive resolves
  the published module without a hand edit. Released binaries and
  go install …@vX.Y.Z now also report their real version.

Fixed

• dockyard new's "directory not empty" error now names the entries it
  found (so a hidden .git/ or .gitignore is visible as the cause) and
  points at --here.

---

Commits

Added

• v1.3-wave-A: enforce quality gates, pin go.mod version, dockyard new --here

Fixed

• ui: widen inspector rail + wrap long table cells

v1.2.0

Added

• dockyard new --no-postgen — opt out of the new post-scaffold steps
  (for hermetic / air-gapped / CI runs, or to run them yourself).

Changed

• dockyard new now runs go mod tidy + dockyard generate for you
  at scaffold time, so a fresh project — blank or --template —
  reaches a green dockyard validate on the first try with no manual
  command. The steps are best-effort: a failure (e.g. no module-proxy
  reach) prints a warning and the manual fallback rather than failing the
  scaffold. Opt out with --no-postgen.
• Release notes now carry an auto-generated commit supplement. A
  GitHub Release body is the hand-authored CHANGELOG.md section
  followed by a Conventional-Commits-derived list of what landed
  (feat → Added, fix → Fixed, the rest → Changed; docs/chore/
  test/ci/build/style dropped). The hand-authored prose stays the
  canonical narrative; the supplement is appended on a tag push only.

---

Commits

Added

• cli,changelogx: v1.2 wave A — scaffold autogen + changelog supplement

Fixed

• skills: avoid line-leading "+" that markdownlint reads as a bullet