adding handbook, blog, and changelog to jan docs v2

[ramonpzg]

This PR helps add the new Jan handbook, the blog, and the changelog to the jan v2 website.

---

Important

This PR adds a handbook, blog, and changelog to the Jan v2 website, updating components, pages, and styles to integrate these new sections with improved functionality and responsiveness.

• New Sections:
  • Adds handbook, blog, and changelog sections to the Jan v2 website.
• Components:
  • Updates FooterMenu to include links to Blog and Handbook.
  • Adds new components like BlogImage, CTABlog, Callout, ChangelogHeader, CustomNav, DownloadButton, Steps, YouTube.
• Pages:
  • Creates blog.astro, changelog.astro, and their respective [slug].astro pages for dynamic content.
  • Updates index.astro to highlight the new version and download stats.
• Styling:
  • Introduces new styles for blog and changelog pages, including responsive design.
  • Implements theme consistency using CSS variables in Layout.astro.
• Functionality:
  • Implements category filtering in blog.astro.
  • Adds image error handling in blog/[slug].astro.
  • Integrates email signup functionality in changelog.astro.

^{This description was created by for 2eeb0b1. You can customize this summary. It will automatically update as commits are pushed.}

[github-actions]

Preview URL: https://2b28aa88.docs-9ba.pages.dev

[LazyYuuki]

lgtm

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to be65911 in 6 minutes and 6 seconds. Click for details.

• Reviewed 12605 lines of code in 158 files
• Skipped 116 files when reviewing.
• Skipped posting 48 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. website/src/content/docs/handbook/optimism.mdx:7

• Draft comment:
  Ensure that the YouTube component correctly handles video IDs with query parameters (e.g., '?si=KDkCQ8MZe13sEc68').
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

2. handbook/comp/index.mdx:34

• Draft comment:
  Typographical error: 'inlude' should be 'include' in the Equipment section.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is a valid typo correction, our guidelines emphasize focusing on logic issues rather than minor text issues. This is a documentation file, but the typo is very minor and doesn't impact understanding. The comment is accurate but may not meet our bar for importance. The typo could potentially confuse readers or make the documentation look unprofessional. Documentation quality is important for company image. However, this is an extremely minor typo that any basic spell checker would catch, and it doesn't impact the meaning or functionality of the documentation. This comment should be deleted as it points out a trivial issue that doesn't warrant a formal review comment.

3. handbook/how/discord.mdx:7

• Draft comment:
  Typo: Consider using 'GitHub' (with an uppercase H) instead of 'Github' to adhere to the proper brand spelling.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct about the official brand spelling, this is an extremely minor documentation issue. The meaning is completely clear either way. This feels like the kind of nitpicky comment that adds noise without providing real value. Documentation should be clear and accurate, but this level of brand name capitalization detail isn't worth a PR comment. Brand consistency could be important for a public-facing document. Some might argue that attention to detail matters in documentation. This is an internal handbook document, not public-facing marketing material. The slight capitalization difference doesn't impact clarity or usability. Delete this comment as it's too minor and doesn't meaningfully improve the documentation.

4. handbook/how/github.mdx:1

• Draft comment:
  Typographical suggestion: The title currently reads "## Github". Consider changing it to "## GitHub" for correct capitalization.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct as GitHub's official name is "GitHub" not "Github", this is a very minor stylistic issue in documentation. The rules state not to make purely informative comments or obvious/unimportant changes. This feels more like a nitpick than a substantial issue that requires addressing. The branding of GitHub could be considered important for professional documentation. Some might argue that using correct company names shows attention to detail. While correct branding is good, this is such a minor issue that it doesn't warrant a PR comment. The meaning is completely clear either way. Delete this comment as it's too minor of an issue and violates the rule about not making obvious/unimportant comments.

5. handbook/how/sprints.mdx:5

• Draft comment:
  Typographical note: The contraction "ya'll" appears to be misspelled. It is commonly written as "y'all".
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and does not provide any actionable feedback related to the code's functionality or logic. It focuses on a typographical note, which is not relevant to the code review process as per the given rules.

6. handbook/hr/side-gigs.mdx:31

• Draft comment:
  Typographical error: Consider changing "all party's IP" to "all parties' IP" for proper plural possessive usage.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While this is a real grammatical error, our rules state we should only keep comments that require clear code changes. Grammar fixes in documentation, while nice to have, are generally not critical enough to warrant a comment. This is especially true for minor issues like apostrophe placement that don't affect meaning or readability. The text is in a handbook that will be read by employees, so proper grammar could be considered important for professionalism. The error could cause minor confusion about whether it refers to a single party or multiple parties. While professional writing is important, this is a very minor grammatical issue that doesn't significantly impact understanding. The meaning is clear from context. Delete this comment as it's too minor of an issue to warrant a PR comment. Such small grammar fixes can be handled in future documentation updates if needed.

7. handbook/lifecycle/offboarding.mdx:29

• Draft comment:
  Typographical error: Please change 'Github issues' to 'GitHub issues' to reflect the correct brand capitalization.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct about GitHub's brand name, this is an extremely minor stylistic issue in a documentation file. It doesn't affect functionality, readability, or understanding. The rules specifically say not to make comments that are obvious or unimportant. Brand capitalization falls into this category. The proper capitalization of brand names could be considered important for maintaining professional documentation standards. Some organizations have strict brand guidelines. While brand guidelines matter in customer-facing documentation, this is an internal offboarding checklist. The meaning is perfectly clear either way, and this level of nitpicking doesn't add value. Delete this comment as it's too minor and doesn't affect the document's functionality or clarity.

8. handbook/lifecycle/onboarding.mdx:76

• Draft comment:
  Typo: Consider changing "Push 1 PR into this Handbook. This a living document!" to "Push 1 PR into this Handbook. This is a living document!"
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While this is a real grammatical error and the fix is correct, our rules state we should only keep comments that require clear code changes. Grammar and typo fixes, while helpful, are not critical code issues. The meaning is still clear despite the missing word. The comment is technically correct and improves the document quality. Documentation clarity is important for onboarding. However, this is a minor grammatical issue that doesn't impact functionality or understanding. Such minor editorial fixes can be handled in a separate editorial pass or PR. Delete the comment as it addresses a minor grammatical issue rather than a substantive code or content problem.

9. handbook/sell/marketing.mdx:34

• Draft comment:
  Typo: "Marketings looks like art..." should be "Marketing looks like art..."
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct, typos are very minor issues. The meaning is completely clear despite the typo. Our rules say not to make comments that are obvious or unimportant. Typos like this are exactly the kind of minor issue we should avoid commenting on unless they significantly impact understanding. The typo could potentially confuse non-native English speakers. It's a clear objective error that's easy to fix. While true, the context makes the meaning obvious, and this type of minor correction creates noise in PR reviews that distracts from more substantial issues. We should delete this comment as it points out a very minor issue that doesn't impact understanding and creates unnecessary noise in the review process.

10. handbook/sell/marketing.mdx:68

• Draft comment:
  Typo/grammatical issue: "What we improve?" might be intended as "What do we improve?"
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While this is technically correct, our rules say not to make purely informative comments or obvious fixes. This is a minor grammatical issue in documentation that doesn't impact understanding. The meaning is clear either way. We should focus on more substantial issues. The grammar error could make the documentation look unprofessional, and fixing it would improve quality. Documentation quality matters for company image. While documentation quality matters, this is a very minor issue that doesn't impact comprehension. The rules specifically say to avoid obvious or unimportant comments. This comment should be removed as it points out a minor grammatical issue that doesn't significantly impact the documentation's effectiveness or comprehension.

11. handbook/who/team.mdx:13

• Draft comment:
  Typographical suggestion: In the sentence "Menlo is a sports team, not unlike a NBA team or a NFL team.", consider using the correct indefinite article. It might be clearer to say "an NBA team or an NFL team" instead of "a NBA team or a NFL team".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the grammar correction is technically accurate, this is a very minor issue in what appears to be a handbook/documentation file. The meaning is perfectly clear either way. The rules state not to make comments that are obvious or unimportant. Grammar nitpicks like this, unless they significantly impact readability or meaning, probably fall into the "unimportant" category. The incorrect article usage could be seen as unprofessional in a public-facing handbook. Multiple small grammar issues can add up to make documentation look sloppy. While professionalism matters, this is such a minor issue that it doesn't significantly impact readability or professionalism. The rules explicitly say not to make obvious or unimportant comments. This comment should be deleted as it addresses an extremely minor grammatical issue that doesn't meaningfully impact the document's quality or readability.

12. handbook/who/underdogs.mdx:24

• Draft comment:
  Typo/clarity issue: The phrase "people with potential others missed" seems awkward. Consider revising it to something like "people with potential that others missed" or "people with untapped potential" for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a marketing/handbook document, not code. The existing phrasing, while slightly informal, is still clear and has a poetic quality that fits the overall tone of the document. The suggested change is very minor and doesn't significantly improve clarity or meaning. The current version might even be intentionally crafted for its brevity and impact. The document is customer-facing, so perfect grammar could be considered important. The current phrasing could be seen as slightly awkward by some readers. The current phrasing is stylistic, clear enough, and fits the informal, direct tone of the document. This kind of minor stylistic suggestion doesn't warrant a PR comment. Delete this comment as it suggests an unnecessary change that doesn't meaningfully improve the document.

13. website/src/content/blog/benchmarking-nvidia-tensorrt-llm.mdx:170

• Draft comment:
  Typo: The text "62.41%% less" contains a double percentage sign. It should be "62.41% less".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct - there is a double %% that should be a single % - this is an extremely minor formatting issue in a markdown table. It doesn't affect functionality or readability significantly. The table renders correctly either way. According to the rules, we should not make comments that are obvious or unimportant. The double percentage could theoretically cause issues with some markdown parsers or make the document less professional looking. Even if there are edge cases where this could matter, it's still an extremely minor issue that doesn't warrant a PR comment. The author can easily spot and fix this themselves during review. This comment should be deleted as it points out an extremely minor formatting issue that doesn't significantly impact the document.

14. website/src/content/blog/benchmarking-nvidia-tensorrt-llm.mdx:199

• Draft comment:
  Typo: The text "76.55%% less" contains a double percentage sign. It should be "76.55% less".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is technically correct - there is a double percentage sign - this is a very minor typo that doesn't affect readability or functionality. The meaning is still completely clear. The rules say not to make comments that are obvious or unimportant. This feels like an unimportant nitpick. The double percentage could theoretically cause issues if this markdown is being parsed programmatically. Maybe there's a technical reason to fix it that I'm not considering. Even if parsed programmatically, markdown parsers would likely just render this as a literal "%%" rather than causing any real issues. The meaning remains clear either way. This comment, while technically correct, is too minor and unimportant to be worth keeping as a PR comment.

15. website/src/content/blog/benchmarking-nvidia-tensorrt-llm.mdx:226

• Draft comment:
  Typo: The phrase "an interesting to see" seems off. Consider rephrasing it as "interesting to see" or "an interesting experiment to see..." for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment correctly identifies a grammatical error, it's a very minor typo that doesn't affect understanding. The rules state not to make comments that are obvious or unimportant. Grammar/typo fixes fall into this category unless they significantly impact readability or meaning. The error does make the sentence read awkwardly, and fixing it would improve the writing quality. Maybe this is worth keeping for polish? No - the rules are clear that we should not make comments about minor issues. This is a blog post, not critical system code, and the meaning is still clear despite the small grammatical error. Delete this comment as it addresses a minor grammatical issue that doesn't significantly impact readability or understanding.

16. website/src/content/blog/bitdefender.mdx:54

• Draft comment:
  Typo: In this line, "the 2 remaining Nitro version (0.2.7, 0.2.8) will under further investigation." should read "the 2 remaining Nitro versions (0.2.7, 0.2.8) will be under further investigation."
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment correctly identifies grammatical errors, this is a blog post rather than code. The errors are minor and don't impact understanding. Blog posts often go through editorial review processes separate from code review. Code review comments should focus on code logic and implementation rather than prose editing. The grammar errors could impact readability and professionalism of the blog post. Poor grammar in public-facing content could reflect badly on the project. While grammar is important, fixing blog post prose is better handled through editorial processes rather than code review comments. Code review should focus on code-related issues. Delete this comment as it's focused on prose editing rather than code issues. Blog post content editing should be handled through separate editorial processes.

17. website/src/content/blog/bitdefender.mdx:62

• Draft comment:
  Typographical issue: "scans using Bitdefender. and only the 2 latest versions raised warnings from Bitdefender." This should be adjusted (e.g., replacing the period with a comma and removing the extra period) for consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a new blog post file being added. While the grammar fix would improve readability, this is a relatively minor issue. The rules state not to make purely informative comments or comments that are obvious/unimportant. Grammar fixes in documentation, unless severely impacting understanding, generally fall into this category. The grammar issue does affect readability and professional appearance of the blog post. Documentation quality is important for user-facing content. While documentation quality matters, this is a minor grammatical fix that could be handled through normal editorial processes rather than PR comments. The meaning is still clear despite the awkward punctuation. This comment should be removed as it's a minor grammatical suggestion that doesn't warrant a PR comment per our rules about avoiding purely informative or unimportant comments.

18. website/src/content/blog/bitdefender.mdx:103

• Draft comment:
  Typographical inconsistency: "Microsoft defender" should be capitalized as "Microsoft Defender" for consistency with previous mentions.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct, this is an extremely minor capitalization issue in a blog post. The rules state not to make comments that are obvious or unimportant. Capitalization consistency in a blog post, especially in a bullet point list, is not a significant issue that requires a code change. This feels like nitpicking that adds noise without value. The product name "Microsoft Defender" is officially capitalized, so this could be seen as a legitimate branding/naming issue rather than just style. Even if it's about official branding, this is still an extremely minor issue in a blog post that doesn't materially impact understanding or functionality. The rules explicitly say not to make purely informative comments. This comment should be deleted as it points out a trivial capitalization inconsistency that doesn't warrant a PR comment per our rules about avoiding obvious/unimportant comments.

19. website/src/content/blog/data-is-moat.mdx:25

• Draft comment:
  Consider revising the header "## The rise of the opensource" to "## The rise of open source" for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While "open source" is indeed the more standard spelling, this is purely a stylistic change. The rules state not to make purely informative comments or comments about obvious things. This is a minor formatting issue that doesn't affect the logic or functionality of the content. The inconsistent spelling within the document could be confusing to readers. The term appears differently in the title vs the heading. While consistency is good, this is still just a stylistic issue. The rules explicitly state not to make obvious or unimportant comments. This comment should be deleted as it's purely about formatting/style and doesn't affect the logic or functionality of the content.

20. website/src/content/blog/data-is-moat.mdx:101

• Draft comment:
  Consider checking the consistency of naming in "- Example: Dolma + olma from allenai". If 'Dolma' and 'Olma' refer to proper names, it might be better to capitalize both for consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct about capitalization consistency, this seems like a very minor stylistic issue. The comment is about changed code since this is a new file, but it's not pointing out any functional issues or significant problems. It's more of a nitpick about formatting. The capitalization doesn't impact the meaning or readability significantly. The capitalization could actually be intentional if "olma" is meant to be lowercase in its official branding. I don't have enough context about these AI model names. Even if the capitalization is incorrect, this is such a minor issue that it doesn't warrant a PR comment. The author can handle basic proofreading without automated tooling pointing it out. This comment should be removed as it's too minor of an issue and doesn't highlight any significant problems that need addressing.

21. website/src/content/blog/rag-is-not-enough.mdx:31

• Draft comment:
  Punctuation issue: Remove the extra punctuation after the link. Consider rephrasing "using Jan., our desktop client." to "using Jan, our desktop client.".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the extra period, this is a very minor formatting issue in a blog post markdown file. The rules state we should not make comments that are obvious or unimportant. Punctuation in documentation is not a critical issue that requires a PR comment. The extra period does make the sentence read awkwardly and could confuse readers. Poor punctuation can affect readability. While readability is important, this is too minor of an issue to warrant a PR comment. The author can catch this in their own proofreading. This comment should be removed as it addresses a trivial punctuation issue that doesn't impact the technical content or functionality.

22. website/src/content/blog/rag-is-not-enough.mdx:67

• Draft comment:
  Typo: Remove the duplicate word "on" – change "trained it on on the [Nitro documentation]" to "trained it on the [Nitro documentation]".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is a real typo, it's a very minor issue that doesn't affect understanding. The rules state we should not make comments that are obvious or unimportant. A duplicate word is something that could be caught by basic proofreading or a spell checker. The typo does affect readability slightly, and it is definitely a real issue that should be fixed. However, this kind of minor typo is too trivial to warrant a PR comment. It clutters the review without adding significant value. While the comment identifies a real typo, it's too minor an issue to warrant a PR comment.

23. website/src/content/changelog/2024-01-16-settings-options-right-panel.mdx:19

• Draft comment:
  Typographical fix: Consider correcting "Github" to "GitHub" in the changelog entry for improved consistency and correct branding.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct (GitHub's official branding is "GitHub" not "Github"), this is an extremely minor issue in a changelog entry. Changelogs are primarily for communicating changes to users, and this capitalization difference doesn't impact understanding. The rules specifically say not to make comments that are obvious or unimportant. GitHub's brand guidelines do specifically request proper capitalization, so this could be seen as a legitimate branding issue. However, this is still an extremely minor issue in an internal changelog file, not customer-facing marketing material where brand compliance would be more critical. Delete the comment as it's too minor and doesn't affect functionality or understanding.

24. website/src/content/changelog/2024-03-06-ui-revamp-settings.mdx:25

• Draft comment:
  There appears to be a typographical issue on this line. The text "b3012.Big thanks" likely needs a space after the period (e.g., "b3012. Big thanks") to separate the version from the following sentence. Please clarify and fix if intended.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the missing space, this is a very minor issue in a changelog file. Changelogs are primarily for human readability and this small formatting issue doesn't impact understanding. The comment feels overly pedantic and doesn't address any meaningful code quality or functionality issues. The missing space could theoretically impact automated parsing of the changelog or make it look slightly unprofessional. This is a markdown file meant for human consumption, not automated parsing. The tiny formatting issue doesn't meaningfully impact readability or professionalism. This comment should be deleted as it's too minor and doesn't address any meaningful issues that would require code changes.

25. website/src/content/changelog/2024-04-15-new-mistral-extension.mdx:17

• Draft comment:
  Typographical error: The phrase 'change set API Prefix' on this line is unclear. It might be intended to be 'change the API prefix' or simply 'set the API prefix' for the local API server. Please clarify.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment correctly identifies a grammatical issue, changelog entries are typically less formal documentation. The meaning is still clear despite the awkward wording. According to the rules, we should not make purely informative comments or comments about obvious issues that don't require significant code changes. The wording is technically incorrect and could be improved for professionalism. Documentation quality is important for user understanding. While documentation quality matters, this is a minor grammatical issue in a changelog that doesn't significantly impact understanding. The rules specifically say not to make obvious or unimportant comments. Delete this comment as it's a minor grammatical suggestion that doesn't warrant a PR comment according to our rules about avoiding obvious or unimportant issues.

26. website/src/content/changelog/2024-04-25-llama3-command-r-hugginface.mdx:17

• Draft comment:
  Typographical consistency: The alt text "Commandr" on this line might be intended to match the reference to Command R+ in the text. Consider changing it to "Command R+".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the inconsistency, it's a very minor UI/documentation issue. The rules specifically state not to comment on pure UI changes. Alt text is primarily a UI/accessibility concern. The inconsistency doesn't affect the functionality or logic of the code. The inconsistent naming could potentially confuse readers or cause accessibility issues for screen reader users. It's a valid documentation concern. However, per the rules, we should not comment on pure UI or styling changes. Alt text falls into this category, and we should assume the author made UI choices deliberately. Delete the comment as it pertains to UI/documentation rather than logic or functionality.

27. website/src/content/changelog/2024-04-25-llama3-command-r-hugginface.mdx:23

• Draft comment:
  Typo detected: The alt text "HugginFace" appears to be a misspelling of "Hugging Face". Please confirm the correct naming and update accordingly.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment correctly identifies a spelling inconsistency, this is a minor UI issue in alt text. The rules specifically state not to comment on pure frontend UI changes and to assume the author made UI choices correctly. Alt text is primarily a UI/accessibility concern. The inconsistent spelling across the document could indicate a broader documentation issue. The company's official name is "Hugging Face" with a space. Even if there is an inconsistency, the rules explicitly tell us not to comment on UI-related changes, and alt text falls into that category. Delete the comment as it relates to UI/frontend concerns which we're instructed to ignore.

28. website/src/content/changelog/2024-04-25-llama3-command-r-hugginface.mdx:29

• Draft comment:
  Minor lexicographical note: The alt text "Latex" might be updated to "LaTeX" for consistency with the text content above, unless intentional.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the inconsistency, it's an extremely minor UI detail. The rules specifically state not to comment on pure frontend UI changes and to assume the author made UI choices correctly. Alt text is primarily a UI/accessibility concern. The inconsistency could potentially cause confusion for screen readers or affect searchability. Maybe there's a company style guide that requires consistent capitalization? Even if there is a style guide, this is still fundamentally a UI concern. The rules explicitly tell us to trust the author on UI decisions and not to make comments about obvious or unimportant issues. This comment should be deleted as it addresses a minor UI consistency issue, which falls under the category of UI changes that we should trust the author to handle.

29. website/src/content/changelog/2024-07-15-claude-3-5-support.mdx:17

• Draft comment:
  Typographical issue: Consider changing 'Plus, You can now use optional spell check for chats.' to 'Plus, you can now use optional spell check for chats.' (uncapitalized 'you').
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a very minor capitalization issue in a changelog file. While technically correct, changelogs are primarily for communicating changes to users, and this small capitalization issue doesn't impact readability or understanding. The rules specifically say not to make obvious or unimportant comments, and to only comment if there's clearly a code change required. The capitalization is technically incorrect, and consistency in writing style could be considered important for professional documentation. While technically correct, this is an extremely minor issue that doesn't affect functionality or user understanding. The rules explicitly state not to make obvious or unimportant comments. This comment should be deleted as it's too minor and doesn't meet the threshold for requiring a code change.

30. website/src/content/changelog/2024-10-24-jan-stable.mdx:22

• Draft comment:
  Typo Alert: In the text "Adjusted LLava model EOS token and context input", please verify if "LLava" is spelled as intended. It might be a typo for "LLaVA".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While this is technically about a change (new file), spelling/capitalization suggestions for technical terms should have strong evidence that they're correct. Without access to the actual codebase or documentation to verify the correct spelling of this model name, we can't be certain this is actually wrong. The model could legitimately be called "LLava" in their codebase. The spelling "LLaVA" is indeed more common in the AI field, so this could be a legitimate correction. Without being able to verify the actual name used in their codebase, making assumptions about technical term spelling could introduce inconsistencies. Delete this comment as we don't have strong evidence that this spelling is actually incorrect for their specific implementation.

31. website/src/content/changelog/2024-11.14-jan-supports-qwen-coder.mdx:18

• Draft comment:
  Typographical Error: There appears to be a missing space in "SupportsAlibaba_Qwen's Coder 14B & 32B Support". Consider changing it to "Supports Alibaba_Qwen's Coder 14B & 32B Support".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is technically correct - there is a missing space that makes the text slightly harder to read. However, this is a minor typo in a changelog file. The meaning is still clear, and changelogs are typically less formal documentation. The comment feels overly pedantic for this context. The typo does affect readability slightly, and consistency in documentation is important for professionalism. While documentation quality matters, this is a very minor issue that doesn't significantly impact understanding or usability. The rules state not to make comments that are obvious or unimportant. This comment should be deleted as it points out a very minor formatting issue that doesn't meaningfully impact the changelog's effectiveness.

32. website/src/content/changelog/2025-01-06-key-issues-resolved.mdx:17

• Draft comment:
  Typo: Consider updating "MacOS" to "macOS" to align with Apple's official branding guidelines.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct about Apple's branding guidelines, this is an extremely minor stylistic issue in a changelog entry. Changelogs are primarily for communicating changes to users, and users will perfectly understand "MacOS". This feels like unnecessary pedantry that doesn't improve the actual content or clarity of the changelog. The branding consistency could be important for professional appearance and SEO. Some users might search specifically for "macOS". The benefit is minimal - both terms are widely used and understood, and this is an internal changelog, not marketing material or documentation. Delete the comment. While technically correct, this level of branding precision isn't important enough to warrant a changelog edit.

33. website/src/content/changelog/2025-01-23-deepseek-r1-jan.mdx:2

• Draft comment:
  The term 'Distills' in the title might be a typo. Please verify if it should be 'Distill' or 'Distilled' instead.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The usage of "Distills" appears intentional as it's used consistently throughout the document as a verb. The model names use "Distill" because that's part of the proper noun. This seems like a stylistic choice rather than a typo. Even if it were technically incorrect, this would be a minor editorial issue rather than a code problem. The grammar might actually be debatable here - "Distills" could be considered awkward phrasing. The comment isn't entirely baseless. However, this is a UI/content change, and our rules explicitly state not to comment on pure UI changes. We should assume the author chose this wording intentionally. Delete this comment as it relates to UI content choices rather than code logic, and our rules specify not to comment on UI changes.

34. website/src/content/changelog/2025-01-23-deepseek-r1-jan.mdx:15

• Draft comment:
  The phrase 'run DeepSeek R1 distills in Jan error-free' appears awkward. Consider checking if 'distills' is the intended word here.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment seems to misunderstand that "Distills" is part of the product branding. The model names consistently use "Distill" in their naming, but the changelog is using "Distills" as a plural noun to refer to multiple Distill models. Both usages could be valid depending on the intended meaning. I might be wrong about the branding intention, and there could be an official style guide that prefers one form over the other. Without access to official branding guidelines or strong evidence that this is incorrect, we should defer to the author's choice of wording. The comment should be deleted as it's making assumptions about terminology without clear evidence of an error, and the current wording is consistent throughout the changelog.

35. website/src/content/changelog/2025-05-14-jan-qwen3-patch.mdx:6

• Draft comment:
  Typo alert: The yaml header lists the ogImage as "/assets/images/changelog/jan-v0-5-17-gemm3-patch.gif". Given that the changelog and title reference 'Qwen3', please verify if the filename should be 'jan-v0-5-17-qwen3-patch.gif' instead of 'gemm3'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment identifies an apparent inconsistency in naming, it's speculative and asks for verification rather than making a clear assertion. The image filename could be intentional - perhaps it's a generic image being reused, or maybe 'gemm3' refers to something else. Without seeing the actual image or knowing the team's naming conventions, we can't be certain this is an error. The comment could be identifying a real issue where the wrong image is being referenced, which could lead to a broken image link. However, per our rules, we should not ask authors to "verify" things or make speculative comments. If there was a broken image link, it would be caught during testing or review. Delete the comment as it's speculative and asks for verification rather than pointing out a definitive issue.

36. website/src/content/changelog/2025-05-20-performance-boost.mdx:38

• Draft comment:
  Typo: The bullet description for Context Length Optimization uses "Handle longer conversations without slowdown". To maintain consistency with the other bullet points (e.g., "Automatically adjusts", "Gracefully handles", "Frees memory"), consider changing "Handle" to "Handles".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the inconsistency, this is a very minor grammatical issue in a changelog document. The meaning is perfectly clear either way. The rules state not to make comments that are obvious or unimportant. This feels like an unnecessarily pedantic comment that doesn't materially improve the quality of the documentation. The inconsistency could potentially make the documentation look less professional. Maintaining consistent grammar throughout could improve readability. While consistency is good, this is an extremely minor issue in a changelog. The benefit of fixing it doesn't justify the overhead of a PR comment and review cycle. This comment should be deleted as it addresses an unimportant grammatical issue that doesn't materially impact the quality or understanding of the changelog.

37. website/src/content/docs/handbook/comp/index.mdx:30

• Draft comment:
  Typo: Please change "inlude" to "include".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While this is a clear typo, the rules state not to make comments that are obvious or unimportant. Spelling errors are typically caught by basic spell checkers and IDE tools. However, this is documentation that will be user-facing, so accuracy is more important than in regular code. Documentation typos could affect readability and professionalism. But is a single letter typo important enough to warrant a PR comment? While documentation quality matters, this is such a minor and obvious typo that the author will likely catch it themselves or through basic spell checking. The comment should be deleted as it points out an obvious minor issue that doesn't require a formal PR comment.

38. website/src/content/docs/handbook/how/sprints.mdx:8

• Draft comment:
  Typo: "ya'll" should be corrected to "y'all".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While technically correct that "y'all" is the proper spelling, this is in an informal documentation context. The meaning is perfectly clear either way. The comment doesn't point out any actual code issues or substantive problems. Documentation typos that don't impact meaning aren't worth commenting on. The incorrect spelling could be seen as unprofessional in official documentation. Also, fixing it would take minimal effort. The informal tone is clearly intentional given phrases like "wanna", and the meaning is completely clear. This kind of nitpicking on docs creates noise without adding value. Delete this comment as it's an unimportant documentation spelling correction that doesn't impact meaning or functionality.

39. website/src/content/docs/handbook/how/tools.mdx:10

• Draft comment:
  Typographical suggestion: The tool name ‘Github’ is generally styled as ‘GitHub’. Consider updating for consistency.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and suggests a typographical change. It doesn't provide a code suggestion or address a potential issue in the code. It doesn't align with the rules for useful comments in a pull request review.

40. website/src/content/docs/handbook/hr/side-gigs.mdx:26

• Draft comment:
  Typographical suggestion: In the sentence "Please respect all party's IP - never intermingle assets (like laptops and logins) between engagements." it might be clearer to use "parties'" instead of "party's" to correctly indicate the plural form.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While this is a valid grammatical correction (since we're talking about multiple parties' IP), the rules state we should focus on logic issues, not minor text fixes. This is a documentation file, but the grammatical error doesn't significantly impact understanding. The meaning is clear either way. The grammar mistake could cause confusion about whose IP we're talking about. Clear communication in legal/HR documents is important. While precise language is good, this is a minor grammatical issue that doesn't materially affect understanding of the policy. The context makes it clear we're talking about multiple parties. Delete this comment as it's a minor text correction that doesn't affect the logic or substance of the policy.

41. website/src/content/docs/handbook/lifecycle/onboarding.mdx:71

• Draft comment:
  Typographical issue: The sentence "Push 1 PR into this Handbook. This a living document!" is missing the verb 'is' in the second sentence. Consider changing it to "This is a living document!".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the missing word, this is a very minor typo in documentation. The meaning is still clear despite the missing word. According to our rules, we should not make purely informative comments or point out obvious/unimportant issues. This feels like a trivial issue that doesn't materially impact the quality or understanding of the documentation. The typo could make the documentation look unprofessional. Clear communication is emphasized in the document itself, so shouldn't we maintain high standards? While professional writing is important, this type of minor typo can be caught in subsequent reviews or edits. It's not significant enough to warrant a dedicated PR comment. Delete this comment as it points out a very minor grammatical issue that doesn't significantly impact the document's quality or understanding.

42. website/src/content/docs/handbook/philosophy/open-superintelligence.mdx:177

• Draft comment:
  Typographical suggestion: Consider changing "Works out of box" to "Works out-of-the-box" for improved clarity and correctness.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a very minor stylistic change in a marketing document. While technically correct, it doesn't impact understanding or functionality. The current form is commonly used and understood. This feels like unnecessary nitpicking that doesn't add value to the review process. The hyphenated version is technically more correct according to style guides. The change would make the document slightly more polished. While technically correct, this level of nitpicking about hyphens in marketing copy violates our rule about not making unimportant comments. The current version is perfectly understandable. Delete this comment as it's too minor and doesn't materially improve the document.

43. website/src/content/docs/handbook/sell/marketing.mdx:30

• Draft comment:
  Typo: "Marketings" should likely be "Marketing".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While this is technically correct - there is indeed a typo - typos are generally very minor issues. The meaning is completely clear despite the typo. This kind of minor editorial feedback could be handled by automated spell checkers or basic proofreading, and doesn't require a PR comment that needs acknowledgment. The typo could potentially confuse readers since it's in an important section header. Also, maintaining high quality documentation is important. While documentation quality matters, this typo is minor enough that it doesn't significantly impact readability or understanding. The suggestion doesn't add enough value to warrant a PR comment. Delete the comment as it points out a very minor issue that doesn't materially impact the content's usefulness or understanding.

44. website/src/content/docs/handbook/sell/marketing.mdx:55

• Draft comment:
  Typo: The phrase "think thorough" seems incorrect. Consider replacing it with "think through".
• Reason this comment was not posted:
  Marked as duplicate.

45. website/src/content/docs/handbook/sell/marketing.mdx:64

• Draft comment:
  Grammatical note: "What we improve?" might be intended as "What do we improve?".
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is purely informative and does not provide any actionable feedback or suggestions related to the code. It focuses on grammar, which is not relevant to the code's functionality or logic.

46. website/src/content/docs/handbook/team/index.mdx:31

• Draft comment:
  Typographical issue: The word "gooood" appears to contain extra 'o's. Consider correcting it to "good".
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a team handbook document where some informal, playful language might be intentional and appropriate. The extra 'o's appear to be a deliberate stylistic choice to add personality to the document. This isn't a technical issue or bug, but rather a style preference. The informal tone matches the overall casual nature of other descriptions like "threatening everyone with corporate speak". Maybe maintaining professional language standards is important for company documentation, even internal handbooks. The document clearly uses an intentionally casual and friendly tone throughout, and this stylistic choice aligns with that tone without compromising clarity or professionalism. This comment should be deleted as it addresses an intentional stylistic choice in an informal document rather than a real typographical error.

47. website/src/content/docs/handbook/team/index.mdx:35

• Draft comment:
  Typographical issue: In the markdown table, there's no space after "Minh and Hien" before the pipe (|). Consider adding a space for consistency (e.g., "Minh and Hien | They make things run smoothly").
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a new file being added, so it is about changes. The issue is real but extremely minor - it's just about consistent spacing in markdown tables. The table still renders correctly either way. Our rules say not to make comments that are obvious or unimportant, and to focus on logic rather than pure formatting/styling issues. The inconsistent spacing could make the markdown less readable for future maintainers. Some markdown linters might flag this. While true, this is still an extremely minor formatting issue that doesn't affect functionality or readability of the rendered page. Our rules explicitly say not to focus on such minor issues. This comment should be deleted as it addresses an unimportant formatting issue that doesn't impact the functionality or rendered output.

48. website/src/content/docs/handbook/who/team.mdx:8

• Draft comment:
  Typo: In the phrase "not unlike a NBA team", the article should be "an" NBA team.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the correction is technically accurate, this is a very minor grammatical issue in documentation. The meaning is completely clear either way. The rules say not to make comments that are obvious or unimportant. Additionally, the comment only fixes one instance of the article issue but leaves "a NFL team" unchanged, which has the same problem. The grammatical error could make the documentation look unprofessional. Multiple small errors can add up to give a negative impression. While professionalism matters, this is an extremely minor issue that doesn't impact understanding. PR comments should focus on more substantial issues. Delete this comment. It's too minor of an issue to warrant a PR comment, and the suggestion is inconsistent by not fixing both instances of the article issue.

Workflow ID: wflow_opBVbm7HrjDYac0d

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 6e39ed7 in 1 minute and 39 seconds. Click for details.

• Reviewed 17 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. docs/src/pages/_meta.json:10

• Draft comment:
  Renamed key from 'docs-v2' to 'docs'. Ensure that all components referencing this key have been updated.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to ensure that all components referencing the renamed key have been updated. This falls under the rule of not asking the author to double-check or ensure things. Therefore, this comment should be removed.

2. docs/src/pages/_meta.json:12

• Draft comment:
  Removed the 'href' property from the documentation entry. Confirm that this removal doesn’t break any external linking behavior.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to confirm that the removal of the 'href' property doesn't break any external linking behavior. This falls under asking the author to confirm their intention or to ensure behavior, which is against the rules.

Workflow ID: wflow_5W8MiCyaPezbIW9e

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 2eeb0b1 in 1 minute and 46 seconds. Click for details.

• Reviewed 1673 lines of code in 48 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. handbook/index.mdx:1

• Draft comment:
  Mass deletion of the entire handbook content (index.mdx) detected. The PR title mentions adding handbook, blog, and changelog pages but this diff only removes legacy docs. Ensure that the new Jan docs v2 content (with proper navigation and links) is added before merging.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

2. handbook/_meta.ts:1

• Draft comment:
  Removal of meta configuration file for the handbook. Confirm that new meta/navigation setups are in place for jan docs v2 to maintain proper routing.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_FMaFLClF2yaqAljE

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}