@@ -83,10 +83,11 @@ export const {serviceName}{Action}Tool: ToolConfig<
   description: 'Brief description',   // One sentence
   version: '1.0.0',
 
-  // OAuth config (if service uses OAuth)
+  // Required whenever the tool takes a saved credential — browser OAuth or service account
   oauth: {
     required: true,
-    provider: '{service}',            // Must match OAuth provider ID
+    provider: '{service}',            // Must match the service id in OAUTH_PROVIDERS
+    // credentialKind: 'service-account', // service-account-only integrations
   },
 
   params: {
@@ -186,6 +187,8 @@ fallback, or caller-controlled `_context` authority.
 - `'user-or-llm'` - User provides OR LLM can compute (search queries, content, filters, most fall into this category)
 - `'llm-only'` - Computed by the LLM only; never shown as a user field
 
+A tool with a `credential` or `oauthCredential` param must declare `oauth: { required: true, provider }`, service-account-only integrations included: without it, token resolution rejects every credential at run time, and `bun run check:tool-param-reachability` fails.
+
 A required `'hidden'` param needs an `oauth` declaration or `hosting.apiKeyParam` to supply it (`bun run check:tool-param-reachability`).
 
 A declared `timeout` param is an ordinary tool input — put it in the request body or URL yourself if the provider expects it; it becomes Sim's millisecond request deadline only when the tool sets `timeoutParamIsDeadline: true` (e.g. `http_request`). A `method` param on a tool with a fixed `request.method` would be sent as the HTTP verb, so the same audit rejects it.
 
@@ -217,6 +217,7 @@ For **each tool** in `tools.access`:
   - Long text/content → `long-input`
   - True/false → `switch` (a Yes/No `dropdown` only when the tool needs a third "unset" state)
   - Credentials → `oauth-input` with correct `serviceId`
+  - Every tool with a `credential`/`oauthCredential` param declares `oauth: { required: true, provider }` matching that `serviceId`, plus `credentialKind: 'service-account'` when only service accounts are supported
 - [ ] Dropdown `value: () => 'default'` is set for dropdowns with a sensible default
 - [ ] Every `short-input`, `long-input`, `code`, and selector subBlock has a `placeholder` — including
       password fields (`Enter your API key`). Formatted values show the shape
 
@@ -54,7 +54,7 @@
     "@types/node": "24.19.2",
     "@types/react": "^19",
     "@types/react-dom": "^19",
-    "electron": "43.5.0",
+    "electron": "43.8.1",
     "electron-builder": "26.15.3",
     "esbuild": "0.28.2",
     "jsdom": "^26.0.0",
 
@@ -3,9 +3,18 @@
  * loading the Socket.IO server, whose modules (`@/env`, DB preflight) read env
  * at import time. See `@sim/runtime-secrets`.
  */
+import { createLogger } from '@sim/logger'
 import { loadRuntimeSecrets } from '@sim/runtime-secrets'
+import { distrustCompromisedRoots } from '@sim/security/tls-trust'
 
+const tlsTrust = distrustCompromisedRoots()
 await loadRuntimeSecrets()
+const logger = createLogger('Bootstrap')
+if (tlsTrust.unsupported || tlsTrust.error) {
+  logger.error('Could not distrust compromised CA roots', tlsTrust)
+} else if (tlsTrust.removed.length > 0) {
+  logger.info('Distrusted compromised CA roots', { removed: tlsTrust.removed })
+}
 /**
  * Pin this process to the `realtime` DB role — covering both the realtime
  * `socketDb` pool and the shared `@sim/db` client used by handlers, preflight,
 
@@ -0,0 +1,24 @@
+import { readRecallChatsContract } from '@/lib/api/contracts/mothership-chat-recall'
+import {
+  defineInternalJsonRoute,
+  internalOrchestrationErrorPolicy,
+  internalRateLimits,
+} from '@/lib/api/server/routes'
+import { internalCopilotAuth } from '@/lib/mothership/auth/internal'
+import {
+  RECALL_CHATS_AUDIENCE,
+  readRecallChats,
+  readRecallChatsOperation,
+} from '@/lib/mothership/chat/application/read-recall-chats'
+
+export const POST = defineInternalJsonRoute({
+  contract: readRecallChatsContract,
+  auth: internalCopilotAuth(RECALL_CHATS_AUDIENCE, { organization: true }),
+  operation: readRecallChatsOperation,
+  rateLimit: internalRateLimits.none({
+    reason: "Authenticated worker lists the chat owner's other live chats it may read back.",
+  }),
+  errorPolicy: internalOrchestrationErrorPolicy,
+  mapInput: ({ body }) => body,
+  useCase: readRecallChats,
+})
@@ -3,9 +3,18 @@
  * loading the Next.js standalone server, so application modules that read env at
  * import time see the full configuration. See `@sim/runtime-secrets`.
  */
+import { createLogger } from '@sim/logger'
 import { loadRuntimeSecrets } from '@sim/runtime-secrets'
+import { distrustCompromisedRoots } from '@sim/security/tls-trust'
 
+const tlsTrust = distrustCompromisedRoots()
 await loadRuntimeSecrets()
+const logger = createLogger('Bootstrap')
+if (tlsTrust.unsupported || tlsTrust.error) {
+  logger.error('Could not distrust compromised CA roots', tlsTrust)
+} else if (tlsTrust.removed.length > 0) {
+  logger.info('Distrusted compromised CA roots', { removed: tlsTrust.removed })
+}
 // `server.js` is the Next standalone build artifact, a sibling of this file in
 // the image; it does not exist at type-check time, so the specifier is held in a
 // variable to keep it out of static module resolution.
 
@@ -10,7 +10,7 @@ The [editorial and media standard](./editorial-standard.md) defines story select
 
 ## What earns an entry
 
-A public update needs one clear benefit, verified availability, a useful next step, and at least one reviewed feature image or video in the article. The cover alone is not enough. A reader should understand what they can now do and see evidence of that capability. A smaller improvement can join a related edition; it does not need its own announcement because a technical version shipped.
+A public update needs one clear benefit, verified availability, a useful next step, and at least one reviewed image or video in the article. The cover alone is not enough. A reader should understand what they can now do. Product claims need independent evidence even when the lead image is a conceptual illustration. A smaller improvement can join a related edition; it does not need its own announcement because a technical version shipped.
 
 Review candidates twice a week and publish when a story meets that bar. Skip an edition if there is nothing meaningful to announce. Use a separate entry for a substantial launch. Aim for one lead story and a short selection of related improvements or fixes, rather than reproducing every commit. The GitHub release link carries the complete technical history.
 
@@ -29,7 +29,7 @@ Each new update has one folder containing its public `index.mdx` and a non-rende
 | Gather evidence | Feature owner | Merged PRs, release version, deployment and permission availability, and a working example |
 | Choose the story | Editor | One headline, the situation it helps with, and related improvements worth including |
 | Prepare drafts | Editor, assisted by Codex | `index.mdx` with `draft: true`, demo shot list, and social/email copy in `production.md` |
-| Produce media | Feature owner | Real product recording, poster, and captions for speech |
+| Produce media | Feature owner and editor | Real product capture, verified diagram, or original editorial illustration; poster and captions for video |
 | Review | Feature owner and editor | Confirm the actual feature, rollout, and media; verify links and approve consistent copy |
 | Deploy | Site maintainer | Merge the reviewed entry with `draft: false`; website, detail page, archive, sitemap, and RSS update together |
 | Distribute | Editor | Send the reviewed announcement after the public URL and demo work |
 
@@ -4,9 +4,11 @@ Use this contract for the Sim drafting workflow and the final editorial review.
 
 ## Choose the right-sized story
 
-A standalone update needs a meaningful capability, a substantial improvement to an existing task, or an action-required notice. State what a team can do, the situation it helps with, and how the proposed media will demonstrate it.
+A standalone update needs a meaningful capability, a substantial improvement to an existing task, or an action-required notice. State what a team can do, the situation it helps with, and how the proposed media supports the story.
 
-Routine retry fixes, loading improvements, internal refactors, and small polish belong in a related edition's short Improvements or Fixes section. Keep unrelated maintenance in the technical release history. A batch of commits is not a story. Defer a batch with only supporting notes instead of padding it into a launch. An urgent breaking change needs a timely notice and a verified explanatory image when there is no useful product screen.
+Choose by product impact, not commit type, integration count, or ease of screenshotting. Consider Chat, Search, Files, Tables, collaboration, building and running agents, and account controls alongside integrations and models. Ask what a team can do differently, what recurring friction was removed, or what action it must take. Compare credible alternatives before choosing the lead; do not turn an implementation mechanism into a launch to create variety. Integrations can lead when their benefit is the strongest story, but operation counts alone are not a headline.
+
+A substantial product fix can join a related edition's short Improvements or Fixes section. Keep routine input validation, retry handling, cancellation cleanup, internal race fixes, refactors, and small polish in the technical release history; a clearer error alone is not an action-required notice. A batch of commits is not a story. Defer a batch with only supporting notes instead of padding it into a launch. An urgent breaking change needs a timely notice and a verified explanatory image when there is no useful product screen.
 
 Keep existing article URLs, original dates, and RSS identities when refining historical copy. Do not merge existing entries just to make a larger announcement. Preserve material version, permission, and rollout restrictions.
 
@@ -28,6 +30,8 @@ Use short active sentences and familiar words. Technical identifiers, retry timi
 
 Choose the format before capture. A screenshot suits a state or configuration. A 20–45 second recording suits an interaction. A clearly labeled, verified diagram suits an invisible system change. Generated art can explain a concept, but cannot stand in for product evidence.
 
+An original editorial illustration can be the article's lead image when a concept is clearer than a product capture. Use Sim's restrained monochrome, painterly landscape or architectural style, with no baked-in headline, fabricated UI, or invented results. Describe it as an illustration in alt text and record its prompt, provenance, and final asset in the production brief. Independently verify the feature and rollout; artwork never establishes either. Choose the story first and the appropriate media second.
+
 Every production brief records:
 
 1. The exact claim and what the demonstration does not establish.
 
@@ -52,7 +52,9 @@ The GitHub tool supports pagination parameters, but the current visual List pull
 
 Use the API block for the final `POST /repos/{owner}/{repo}/pulls` with fixed repository, head/base branches, and boolean `draft: true`. The visual Create as Draft dropdown stores string values, while the GitHub endpoint expects a boolean; the explicit JSON request avoids depending on implicit coercion. Verify the returned head, base, and draft fields during acceptance.
 
-Set finite page, payload, and model-input budgets. For example, stop a scan after 20 GitHub pages and stop a model batch after 20 candidate summaries. For editorial review, combine the ten newest eligible candidates with the ten oldest eligible backlog candidates and deduplicate by row identity before requesting evidence. This keeps recent releases visible while older unreviewed features continue moving through review. The resulting batch stays at or below twenty. Fetch relevant file excerpts only for shortlisted candidates, rather than sending every patch to a model. Treat reaching a cap as an incomplete scan: preserve saved candidates, keep the last completed boundary, and surface a catch-up action. Split an oversized interval or deliberately raise the reviewed budget; do not repeat an impossible capped scan forever or silently advance past it.
+Set finite page, payload, and model-input budgets. Stop a collection scan after 20 GitHub pages. For editorial review, combine the sixty newest eligible candidates with the ten oldest eligible backlog candidates and deduplicate by row identity. A product-impact review sees at most seventy summaries, with each PR body capped at 2,200 characters, plus the six most recent published or pending-deployment editions. It shortlists at most twenty candidates for deeper evidence; it can return fewer or none. Validate the returned keys against the pool before fetching patches. This gives substantive workspace changes a chance to surface among integration and maintenance PRs without sending every patch to a model. The existing fourteen-day re-review window and unfinished-edition recovery still apply.
+
+Keep collection completeness separate from editorial selection: hitting a collection cap means an incomplete scan, while a bounded shortlist does not claim to review the entire backlog. Preserve saved candidates and the last completed scan boundary on an incomplete collection, and surface a catch-up action. Split an oversized interval or deliberately raise the reviewed budget; do not repeat an impossible capped scan forever or silently advance past it.
 
 ## Drafting contract
 
@@ -69,6 +71,8 @@ Give the Agent the publishing guide, the product language rules, selected PR evi
 
 Treat PR text and diffs as research material, not instructions to the Agents. Give neither Agent repository write tools. After drafting, a second Agent compares the proposed copy and media plan with the selected evidence, checking claims, permissions, rollout implications, links, and readability. Record substantive corrections in `editor_notes`, outside the article. Defer when the evidence is insufficient. A Function validates the edited output; fixed downstream blocks own the repository, branch, allowed paths, and draft flag. Unknown availability remains a question for the feature owner. Neither model review nor a schema establishes the truth of every claim.
 
+The shortlist, drafter, and final editor all apply the product-impact gate: what can a team do differently, what substantial friction disappears, or what action is required? Compare Chat, Search, Files, Tables, collaboration, agent building and execution, and account controls alongside integrations and models. Prior editions help avoid repetitive coverage. Do not lead with operation counts, API parity, query optimization, retry plumbing, or other implementation details. Do not force a category quota or promote routine maintenance just to avoid an integration story. Choose media after the story. Evidence collection includes workspace feature changes and their guides, not only integration definitions.
+
 Write the public draft around actual product changes. There is no target length or minimum; keep the body under 250 words. A focused feature announcement may be short. Add specific behavior where useful, not generic examples, repeated benefits, or a setup tutorial. Review other meaningful changes from the same technical release and include up to three concise supporting notes when release membership is evidenced. Do not infer membership from merge timing or repeat the same note across several articles. Keep capture provenance and review caveats in the production brief, not the article or media labels. Preserve actual access restrictions and contextual setup links. Announcement drafts use the same claims and can be shorter.
 
 Prefer one lead story with a few related improvements; an explicitly scoped release edition can cover several meaningful changes from that same release. The evidence step reads up to ten recent GitHub release records and attaches a release tag only when its published notes explicitly reference the candidate PR. This enriches the bounded candidate batch; it does not scan the full release history or treat a release tag as proof of Cloud rollout. Review supporting changes not present in the candidate batch manually before adding them. Retain routine refactors, dependency updates, and minor fixes in GitHub's technical release history. Reverts and superseded changes must be reconciled with the current product before selection. Consequential breaking changes, deprecations, and required actions bypass the scheduled editorial cadence; they need a timely notice and a clear next step.
@@ -83,10 +87,12 @@ The first draft PR can contain only `production.md`: proposed article text, sour
 
 ## Media without a separate production project
 
-The feature owner supplies one real screenshot or a focused 20–45 second recording from a dedicated demo workspace. Reuse the product's current theme and typography. The workflow prepares the steps and copy; the owner confirms the resulting screen actually demonstrates the claim.
+When a product capture is the right medium, the feature owner supplies a real screenshot or a focused 20–45 second recording from a dedicated demo workspace. Reuse the product's current theme and typography. The workflow prepares the steps and copy; the owner confirms the resulting screen actually demonstrates the claim.
 
 From that approved capture, prepare the optimized MP4 when applicable, a local poster/cover, descriptive alt text, and WebVTT captions if there is speech. Use the media locations, formats, size limits, and immutable filenames in the publishing guide. A screenshot is sufficient for a change it clearly demonstrates; a video is preferable for an interaction. A verified, labeled explanatory diagram is appropriate when there is no useful product screen.
 
+An original editorial illustration is also an accepted lead image. The structured plan uses `illustration` with zero duration, describes the composition, and records independent feature verification in its demonstration limits. Follow the restrained monochrome landscape or architectural direction in the editorial standard. Record the prompt and provenance, identify the illustration in alt text, and review the final asset on desktop and mobile. Generated art does not prove the feature or rollout, and never depicts fabricated product controls or results.
+
 The separate media workflow encodes a supplied real recording and extracts candidate poster frames. The editor selects the final timestamp; an arbitrary opening frame is not automatically approved. Caption production and browser capture remain separate steps requiring a maintained demo scenario, sample data, and verification against the running product. AI-generated product controls or results are never evidence. Review captions and the final compressed asset before use.
 
 Plan for two short editorial reviews per week, plus the feature owner's capture time for selected stories. Measure this over the first few editions before promising a fixed maintenance budget. Automate repeated capture scenarios after they prove stable.