v0.8.63: Add source wiki and Agents/Workflows terminology#3316
Conversation
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
There was a problem hiding this comment.
Code Review
This pull request updates the project documentation to align with new orchestration terminology, introducing 'Agents' and 'Workflows' as the primary public concepts. It also adds a new local-first Wiki section to the web application, rendering markdown files directly from the repository. The code review identified several critical issues in the newly implemented custom markdown parser and wiki helpers, including bugs in multi-line list parsing, GFM table separator validation, and relative link resolution.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| if (/^[-*]\s+/.test(trimmed)) { | ||
| const items: string[] = []; | ||
| while (i < lines.length && /^[-*]\s+/.test(lines[i].trim())) { | ||
| items.push(lines[i].trim().replace(/^[-*]\s+/, "")); | ||
| i += 1; | ||
| } |
There was a problem hiding this comment.
The custom markdown parser fails to handle multi-line list items correctly. When a list item spans multiple lines (which is common in the wiki files, such as 10-constitution.md), the parser terminates the list block at the first line break because the subsequent line does not start with a list marker (- or *). This causes the remaining lines of the list item to be rendered as a separate paragraph outside the list structure.
We can fix this by consuming subsequent non-block lines as part of the current list item.
if (/^[-*]\s+/.test(trimmed)) {
const items: string[] = [];
while (i < lines.length && /^[-*]\s+/.test(lines[i].trim())) {
let item = lines[i].trim().replace(/^[-*]\s+/, "");
i += 1;
while (i < lines.length && lines[i].trim() && !isBlockStart(lines[i], lines[i + 1] ?? "")) {
item += " " + lines[i].trim();
i += 1;
}
items.push(item);
}
| if (/^\d+\.\s+/.test(trimmed)) { | ||
| const items: string[] = []; | ||
| while (i < lines.length && /^\d+\.\s+/.test(lines[i].trim())) { | ||
| items.push(lines[i].trim().replace(/^\d+\.\s+/, "")); | ||
| i += 1; | ||
| } |
There was a problem hiding this comment.
Similar to the unordered list parser, the ordered list parser also cuts multi-line list items in half. We should apply the same logic to consume subsequent non-block lines as part of the current ordered list item.
if (/^\d+\.\s+/.test(trimmed)) {
const items: string[] = [];
while (i < lines.length && /^\d+\.\s+/.test(lines[i].trim())) {
let item = lines[i].trim().replace(/^\d+\.\s+/, "");
i += 1;
while (i < lines.length && lines[i].trim() && !isBlockStart(lines[i], lines[i + 1] ?? "")) {
item += " " + lines[i].trim();
i += 1;
}
items.push(item);
}
|
|
||
| const [rawPath, hash] = href.split("#", 2); | ||
| const filename = rawPath.split("/").pop()?.replace(/^\.\//, ""); | ||
| const page = filename ? WIKI_PAGES.find((candidate) => candidate.file === filename) : undefined; |
There was a problem hiding this comment.
The current implementation of normalizeWikiHref uses WIKI_PAGES.find with an exact match on candidate.file === filename. This means that any relative markdown link that does not include the .md extension (e.g., [Overview](01-overview)) will fail to resolve and will be rendered as a plain span instead of a link.
We should leverage the existing getWikiPage helper, which is designed to handle both slugs and filenames.
| const page = filename ? WIKI_PAGES.find((candidate) => candidate.file === filename) : undefined; | |
| const page = filename ? getWikiPage(filename) : undefined; |
| export function getWikiPage(slug: string): WikiPage | undefined { | ||
| return WIKI_PAGES.find((page) => page.slug === slug || page.file === `${slug}.md`); | ||
| } |
There was a problem hiding this comment.
The getWikiPage helper currently fails to find pages when queried with a .md filename (e.g., getWikiPage("01-overview.md")). This is because page.slug is "01-overview" and page.file is "01-overview.md", but the check page.file === \${slug}.md`resolves topage.file === "01-overview.md.md"`.
We should normalize the input by stripping the .md extension before performing the lookup to ensure it handles both slugs and filenames correctly.
| export function getWikiPage(slug: string): WikiPage | undefined { | |
| return WIKI_PAGES.find((page) => page.slug === slug || page.file === `${slug}.md`); | |
| } | |
| export function getWikiPage(slugOrFile: string): WikiPage | undefined { | |
| const clean = slugOrFile.replace(/\.md$/, ""); | |
| return WIKI_PAGES.find((page) => page.slug === clean || page.file === slugOrFile); | |
| } |
| function isTableSeparator(line: string): boolean { | ||
| return /^\s*\|?\s*:?-{3,}:?\s*(\|\s*:?-{3,}:?\s*)+\|?\s*$/.test(line); | ||
| } |
There was a problem hiding this comment.
The isTableSeparator regex strictly requires at least 3 dashes (-{3,}) per cell. However, the GitHub Flavored Markdown (GFM) specification only requires at least 1 dash per cell in the delimiter row (e.g., | - | - | is a valid table separator). Any table using 1 or 2 dashes will silently fail to render as a table.
We should update the regex to allow one or more dashes (-+) to be fully GFM-compliant.
| function isTableSeparator(line: string): boolean { | |
| return /^\s*\|?\s*:?-{3,}:?\s*(\|\s*:?-{3,}:?\s*)+\|?\s*$/.test(line); | |
| } | |
| function isTableSeparator(line: string): boolean { | |
| return /^\s*\|?\s*:?-+:?\s*(\|\s*:?-+:?\s*)+\|?\s*$/.test(line); | |
| } |
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
Summary
Validation
Notes