v0.6.7

0.6.7

Patch Changes

• chore: check the packed tarball can resolve its own imports

v0.6.6

0.6.6

Patch Changes

• chore(renovate): drop dead @kernhq automerge rule

v0.6.5

0.6.5

Patch Changes

• build: force one @kernhq/kernel copy with pnpm.overrides

v0.6.4

0.6.4

Patch Changes

• build(deps): raise @kernhq/testing to ^0.1.14

v0.6.3

0.6.3

Patch Changes

• 20ebb12: Answer "Send test" with the failure when core cannot be reached, rather than a 500.

  Reading the workspace's provider config is a call to core, and it sat outside the handler's try.
  Core is a different service, so a restart, a rolling deploy or a dropped connection made the whole
  procedure throw. Measured against a stub whose core.settings.getIntegration fails, the endpoint
  answered 500 {"code":"INTERNAL_SERVER_ERROR","message":"Internal server error"} and the screen
  showed that as the toast. It answers 200 {"ok":false,"error":"…","status":"refused"} now — the
  same shape as every other way this control can fail, which matters more here than usual, because the
  control's entire job is to tell an administrator the truth about whether mail works.

  Two things that changed quietly when the test send became synchronous are written down rather than
  reverted. sendAndWait enqueues no job, so the send job's retries and backoff do not apply to a
  test send and a restart between the delivery row being written and the provider answering leaves
  that row queued with nothing to sweep it; the reason to accept that, and the reason not to add a
  sweeper, are in its comment. And mail.delivery.failed now says on the event definition that it
  fires per attempt, not per message — an instance with no provider configured emits one for each of
  the job's six tries, so a subscriber counting them is counting attempts.

  test-send.test.ts covers both new cases: core unreachable, and an instance with no provider
  configured at all.

v0.6.2

0.6.2

Patch Changes

• 7863592: Peer @kernhq/contracts@^0.8.0, which adds archivedAt to WorkspaceSummary. A caret on 0.x does
  not cross a minor, so the previous ^0.7.0 could not reach it.

v0.6.1

0.6.1

Patch Changes

• fdaa1ae: Peer @kernhq/kernel at ^0.10.0.

  A caret on 0.x does not cross a minor, so ^0.9.1 stopped reaching the framework the moment 0.10.0
  was published — check-ranges.mjs fails on it, and CI stops at the lint step before a single test
  runs. The module builds and tests against 0.10.0 unchanged.

v0.6.0

0.6.0

Minor Changes

• f3ec9bc: Send a message that carries only plain text in the shared paper layout.

  Five branded MJML templates shipped in this package and nothing rendered them: every email the
  platform sends is built by its caller, and a caller that names no template got whatever HTML it
  brought — or, for core's notification digest, no HTML at all. The digest is the email most people
  here actually open and it arrived as bare text.

  buildMessage now wraps text with no HTML beside it in templates/_layout.mjml, escaping and
  linking each paragraph, so it looks like the rest of the platform without the caller knowing a
  template name. A caller's own HTML is left exactly as it arrived, and the text part is untouched.

  src/server/templates.test.ts compiles every shipped template against one sample and asserts the
  branding, which nothing did before.

• 94c38d1: See the blocked addresses, and take one off the list.

  An address that bounced once was blocked from every Kern email for ever. A full mailbox, a
  corporate relay answering 550 during a misconfiguration, or one press of "report spam" on a digest
  stopped that person receiving password resets, sign-in links and invitations — and nothing in the
  product could read the list or change it. The administrator saw "failed — all recipients
  suppressed" and had no way to act; only SQL released the address.

  suppressions.list and suppressions.remove are new on the mail contract, behind
  mail.settings.manage, and Settings → Email now has a Blocked addresses section with a search
  box and a Remove action per row. A workspace sees its own rows and the instance-wide ones — the
  instance-wide rows are the account mail, so leaving them out would have left the worst case
  unreachable — and a row that belongs to the whole instance is marked as such on screen and in the
  confirmation. Every removal is written to the log and to the workspace's activity feed.

• d3411cd: Send the test message inside the handler and answer what actually happened.

  "Send test" on Settings → Email enqueued a job and reported success, so an administrator saw a
  green toast for credentials that could not connect, for a recipient on the blocked list, and for an
  instance with no provider configured at all. The one control whose job is to prove that mail works
  proved nothing.

  The provider is now built and used before the handler answers, and the answer is the delivery's own
  outcome: ok only when the provider accepted the message, error in the provider's own words, and
  a new optional status (refused, suppressed, timeout) so the screen can say something a
  person can act on. The screen also refreshes the delivery log after every test, whatever the answer.

  Two things the delivery log was getting wrong are fixed with it: building the provider now happens
  inside processSend's try, so a wrong host or a missing key leaves the row failed with the reason
  rather than queued for ever; and the test message renders with the provider's name in it, which
  was blank.

v0.5.2

0.5.2

Patch Changes

• ac8a952: Published again with no code change. npm's CDN kept serving the abbreviated package document from
  before 0.5.1 existed for more than twelve hours, so pnpm install in every host that reached
  ^0.5.1 failed with "no matching version" and the nightly release could not advance the services.
  A new publish is what refreshes that document.

v0.5.1

0.5.1

Patch Changes

• chore(deps): take @kernhq/testing ^0.1.12, which has permissionMatrixDiff