chore: version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@paddock/server@0.70.0

Minor Changes

• #805 2685416 Thanks @edspencer! - Remove the recovery.limboTimeoutMs lever, which never did anything

  limboTimeoutMs / PADDOCK_RECOVERY_LIMBO_MS was parsed (config.ts),
  defaulted (recovery-config.ts), sanitised, resolved per-project, carried into
  the web types — and read by nothing. There were zero consumers in
  packages/server/src. It has been inert since it was introduced with Configurable recovery for keeper chats that hang when a background task is killed at turn-end (surface + auto re-drive) #301.

  The docs were honest about it ("Backstop timer ships in a follow-up"), but the
  Settings UI was not: instance-config.ts listed it as an editable: true field
  alongside levers that work, with no indication it was a no-op. Anyone who set it
  — including this project's own dev box, which exports
  PADDOCK_RECOVERY_LIMBO_MS=60000 — got silence and no way to tell.

  Its original purpose was a backstop for a chat wedged "running" with no way out.
  A chat is permanently wedged "running" when a background task never exits — Stop is a structural no-op and nothing self-heals #528 removed that need: Stop now works during a chat's background phase, so a
  wedged session is escapable from the UI rather than needing a timer to notice it.
  Rather than implement a timer nothing is waiting for, the lever goes.

  Removed end to end: the config key and env var, the Settings field, the
  RecoveryConfig / RecoveryOverride member, and the docs rows describing it.

  Nothing breaks for existing installs. sanitizeRecoveryOverride is an
  allowlist, so a limboTimeoutMs: left in a project.yaml or
  paddock.config.yaml is silently ignored — exactly the effect it has today. The
  env var simply stops being read. No schemaVersion bump: the bump rule is
  "remove a load-bearing key", and this one carried no load, which is the point.

  Worth knowing if you provision Paddock with config management: any
  PADDOCK_RECOVERY_LIMBO_MS in your environment is now dead weight and can be
  dropped.

  The remaining recovery levers — surfaceKilledTask, autoReDrive,
  debounceMs, maxRetries — are unaffected and still work.

Patch Changes

• #812 82d9241 Thanks @edspencer! - Two small fixes to what the UI shows you (Root workspace's Settings tab renders a blank SLUG field #546, PADDOCK_SELF_MCP_PROJECTS help text understates its grant: it also gates promote_project, which clones a caller-supplied git URL #775)

  • The root workspace's Settings tab no longer shows a blank SLUG (Root workspace's Settings tab renders a blank SLUG field #546). The
    root workspace's key is the empty string — a real, routable key, not an
    absent one — so the read-only Slug row rendered a label with nothing under it,
    beside a populated "Started". It now reads a muted (root), deliberately not
    in the mono face a real slug uses, so nobody copies it as one. A project's slug
    is unchanged. Gated on isRootKey, not on truthiness: "" is exactly the
    falsy-key hazard this codebase has been bitten by before, and it only looks
    safe here because "empty key" and "no key" happen to want the same pixels.
  • PADDOCK_SELF_MCP_PROJECTS now describes what it actually grants (PADDOCK_SELF_MCP_PROJECTS help text understates its grant: it also gates promote_project, which clones a caller-supplied git URL #775).
    The Config screen said the lever lets keepers create new projects. It also
    gates promote_project, which git clones a URL the agent supplies — the
    code-execution-class part of the grant, and the part an operator most needs to
    see before flipping it. The lever's own source comment already argued it
    deserved a separate flag because of that clone; the help text was the one
    place a human read about it and the one place it was missing.

@paddock/web@0.70.0

Patch Changes

• #835 493d9e5 Thanks @edspencer! - Restore the inline-code highlight and the blockquote colour in rendered markdown

  Inline code in a chat message had lost its background: the chip borrowed
  --surface-active, and when v0.68.0's colour restoration raised
  --surface-raised to the pre-token prose card, the gap between the chip and the
  card it sits on closed to 1.04:1 — invisible. Blockquotes had gone grey for a
  different reason: they take --text-muted, whose chroma the token migration
  dropped from 0.059 to 0.015 at the same hue.

  Both roles now have tokens of their own (--code-fill, --quote-text,
  --quote-border), set to the measured values of the pre-token UI. The chip
  cannot simply ride --surface-active again — that token is pinned by
  --text-subtle, which would fall to 3.95:1 on the lightness the chip needs —
  which is why these are separate rather than a re-tuned ladder. Parchment,
  Terminal and Sci-Fi alias the new tokens back to the ladders and are unchanged.
  tokens.test.ts and themes.test.ts now assert the chip stays visible on the
  prose card in every theme, so a surface moving underneath it fails the build.

• #805 2685416 Thanks @edspencer! - Remove the recovery.limboTimeoutMs lever, which never did anything

  limboTimeoutMs / PADDOCK_RECOVERY_LIMBO_MS was parsed (config.ts),
  defaulted (recovery-config.ts), sanitised, resolved per-project, carried into
  the web types — and read by nothing. There were zero consumers in
  packages/server/src. It has been inert since it was introduced with Configurable recovery for keeper chats that hang when a background task is killed at turn-end (surface + auto re-drive) #301.

  The docs were honest about it ("Backstop timer ships in a follow-up"), but the
  Settings UI was not: instance-config.ts listed it as an editable: true field
  alongside levers that work, with no indication it was a no-op. Anyone who set it
  — including this project's own dev box, which exports
  PADDOCK_RECOVERY_LIMBO_MS=60000 — got silence and no way to tell.

  Its original purpose was a backstop for a chat wedged "running" with no way out.
  A chat is permanently wedged "running" when a background task never exits — Stop is a structural no-op and nothing self-heals #528 removed that need: Stop now works during a chat's background phase, so a
  wedged session is escapable from the UI rather than needing a timer to notice it.
  Rather than implement a timer nothing is waiting for, the lever goes.

  Removed end to end: the config key and env var, the Settings field, the
  RecoveryConfig / RecoveryOverride member, and the docs rows describing it.

  Nothing breaks for existing installs. sanitizeRecoveryOverride is an
  allowlist, so a limboTimeoutMs: left in a project.yaml or
  paddock.config.yaml is silently ignored — exactly the effect it has today. The
  env var simply stops being read. No schemaVersion bump: the bump rule is
  "remove a load-bearing key", and this one carried no load, which is the point.

  Worth knowing if you provision Paddock with config management: any
  PADDOCK_RECOVERY_LIMBO_MS in your environment is now dead weight and can be
  dropped.

  The remaining recovery levers — surfaceKilledTask, autoReDrive,
  debounceMs, maxRetries — are unaffected and still work.

• #812 82d9241 Thanks @edspencer! - Two small fixes to what the UI shows you (Root workspace's Settings tab renders a blank SLUG field #546, PADDOCK_SELF_MCP_PROJECTS help text understates its grant: it also gates promote_project, which clones a caller-supplied git URL #775)

  • The root workspace's Settings tab no longer shows a blank SLUG (Root workspace's Settings tab renders a blank SLUG field #546). The
    root workspace's key is the empty string — a real, routable key, not an
    absent one — so the read-only Slug row rendered a label with nothing under it,
    beside a populated "Started". It now reads a muted (root), deliberately not
    in the mono face a real slug uses, so nobody copies it as one. A project's slug
    is unchanged. Gated on isRootKey, not on truthiness: "" is exactly the
    falsy-key hazard this codebase has been bitten by before, and it only looks
    safe here because "empty key" and "no key" happen to want the same pixels.
  • PADDOCK_SELF_MCP_PROJECTS now describes what it actually grants (PADDOCK_SELF_MCP_PROJECTS help text understates its grant: it also gates promote_project, which clones a caller-supplied git URL #775).
    The Config screen said the lever lets keepers create new projects. It also
    gates promote_project, which git clones a URL the agent supplies — the
    code-execution-class part of the grant, and the part an operator most needs to
    see before flipping it. The lever's own source comment already argued it
    deserved a separate flag because of that clone; the help text was the one
    place a human read about it and the one place it was missing.

[cloudflare-workers-and-pages]

Deploying paddock with    Cloudflare Pages

Latest commit:	b91eb13
Status:	✅  Deploy successful!
Preview URL:	https://a8227e18.paddock-7u2.pages.dev
Branch Preview URL:	https://changeset-release-main.paddock-7u2.pages.dev

View logs