improvement(changelog): more relevant Search across sources

apps/sim/content/changelog/README.md

@@ -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 |

apps/sim/content/changelog/editorial-standard.md

@@ -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.

apps/sim/content/changelog/maintenance-workflow.md

@@ -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.

apps/sim/content/changelog/search-across-sources/index.mdx

@@ -0,0 +1,35 @@
+---
+slug: search-across-sources
+title: 'More relevant results across your connected sources'
+description: 'Sim Search surfaces closer matches across connected sources. Also: sign out other devices and edit more of your Excel workbooks.'
+date: '2026-10-19T16:00:00Z'
+authors: [waleed]
+tags: [Search, Workspace]
+ogImage: /changelog/search-clear-path-v1.jpg
+ogAlt: 'Monochrome illustration of a winding path through a mountain valley'
+technical: false
+draft: false
+release:
+  versions: [v0.9.25, v0.9.26, v0.9.27]
+---
+
+<ChangelogImage
+  src="/changelog/search-clear-path-v1.jpg"
+  alt="Monochrome illustration of paths meeting in a mountain valley"
+  width="1672"
+  height="941"
+/>
+
+Search brings closer matches to the top across your connected sources. Documents whose titles and previews match your query can surface ahead of weaker results from another app, so finding the right information depends less on knowing where it lives.
+
+Introduced in v0.9.25, this applies to keyword searches sorted by relevance in Search and Sim's search tools. v0.9.26 also recognizes short terms such as “AI” and “VM” when ordering matches. [Connect your sources](https://docs.sim.ai/search); results respect your account's access and your organization's source settings.
+
+### Also in v0.9.26
+
+- **Sign out other devices** in Settings → General ends your other sessions while keeping your current session and connected apps; sign-out can take up to five minutes.
+
+### Also in v0.9.27
+
+- **[Microsoft Excel](/integrations/microsoft-excel):** Find worksheets and tables, manage rows, write formulas, and format or sort ranges in OneDrive for Business and SharePoint workbooks. A Microsoft business account is required; reconnect an existing account for SharePoint browsing. [Excel setup](https://docs.sim.ai/integrations/microsoft_excel).
+
+Read the full technical notes for [v0.9.25](https://github.com/simstudioai/sim/releases/tag/v0.9.25), [v0.9.26](https://github.com/simstudioai/sim/releases/tag/v0.9.26), and [v0.9.27](https://github.com/simstudioai/sim/releases/tag/v0.9.27).