Repository navigation
feat(cli): refactor Wikigraph local config and job progress - #91
Merged
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Summary by CodeRabbit
WalkthroughThis PR renames Wiki Graph URI schemes from 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches✨ Simplify code
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
test/cli/args.test.ts (1)
1694-1802: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winRename the root-help URI placeholder to match the
wikgscheme.data/help/commands/root.jinjastill uses<located-wkg-uri>in the root search/list examples; if that’s not intentional, update it to<located-wikg-uri>for consistency.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/cli/args.test.ts` around lines 1694 - 1802, The root help examples still use the old URI placeholder name in the layered help contract tests, so update the root-help text expectations to match the corrected `wikg` scheme placeholder. In `renderMainHelpText`-driven assertions, replace the `<located-wkg-uri>` references with the consistent `<located-wikg-uri>` form used by the help template, keeping the `rootHelpText`/`commandHelpText` checks aligned with the help renderers.src/cli/convert.ts (1)
245-255: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winThread
debugLogDirPaththroughcreateAppOptions.SpineDigestAppOptionsstill acceptsdebugLogDirPathand uses it to set downstreamlogDirPath; omitting it here drops CLI debug-log output.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/cli/convert.ts` around lines 245 - 255, The createAppOptions helper is dropping the debugLogDirPath option, so CLI debug logging never reaches downstream logDirPath handling. Update createAppOptions to accept and pass through debugLogDirPath from CLIArguments into the returned SpineDigestAppOptions alongside verbose and llm, so the existing debug log flow remains intact.src/editor/markup.ts (1)
36-95: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winLoad the skipped fragments before summarizing gaps
loadFragments(input.segmentStartIndexes, ...)only fetches the selected segment starts, butcollectSkippedSummaryscans the in-between indexes and readsfragments[String(i)]. Those gap fragments are never loaded, so the skipped-summary path stays empty. The gap scan should use the actual fragment start ids, not+= 1over sentence indexes.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/editor/markup.ts` around lines 36 - 95, The skipped-summary path in the markup builder is scanning sentence indexes between selected segments, but those gap fragments were never loaded by loadFragments, so collectSkippedSummary cannot find them. Update the logic in the markup function to use the actual fragment start ids for the in-between range instead of incrementing by 1 over sentence indexes, and ensure the fragments passed into collectSkippedSummary are the ones fetched for those real fragment starts.
🧹 Nitpick comments (10)
src/cli/llm.ts (1)
23-32: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low valueDrop the dead sampling branches in
src/cli/stage-runtime.ts.CLIConfig.llmno longer exposestemperatureortopP, so these checks can never fire.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/cli/llm.ts` around lines 23 - 32, Remove the obsolete sampling conditionals from stage-runtime handling because CLIConfig.llm no longer provides temperature or topP, so those branches are unreachable. Update the logic in the stage runtime code that builds the LLM config to stop checking for temperature/topP and only keep the supported fields, using the relevant LLM config assembly path and any helper that forwards CLIConfig.llm into the model creation flow.src/editor/editor.ts (1)
236-269: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winRedundant
fragmentGroups.listBySerialfetch.
#getGroupSegmentStartIndexes()and#getFullText()each independently callthis.#document.fragmentGroups.listBySerial(this.#serialId)and filter bygroupId, duplicating the same IO/query perrun()invocation.♻️ Suggested fix
public async run(): Promise<string> { - const segmentStartIndexes = await this.#getGroupSegmentStartIndexes(); + const groups = ( + await this.#document.fragmentGroups.listBySerial(this.#serialId) + ).filter((record) => record.groupId === this.#groupId); + const segmentStartIndexes = await this.#getGroupSegmentStartIndexes(groups); if (segmentStartIndexes.length === 0) { return ""; } ... - const originalText = await this.#getFullText(); + const originalText = await this.#getFullText(groups);Then thread
groupsinto both private methods instead of refetching.Also applies to: 271-289
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/editor/editor.ts` around lines 236 - 269, The `#getGroupSegmentStartIndexes()` flow is duplicating the `this.#document.fragmentGroups.listBySerial(this.#serialId)` fetch that `#getFullText()` already performs. Refactor `Editor.run()` to fetch and filter `groups` once, then pass that shared `groups` data into both `#getGroupSegmentStartIndexes` and `#getFullText` so they stop re-querying the same records.src/archive/query/archive-view.ts (3)
3357-3367: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winHardcoded
wikg://literals instead ofWIKI_GRAPH_URI_PREFIX.
WIKI_GRAPH_URI_PREFIXis now imported into this file and used inparseEntityQid/parseWikiGraphReference, butformatTripleUri,formatEntityUri,formatTextStreamRangeUri,parseTripleHitUri, and several inline id constructions (Lines 1625-1626, 1827, 1837, 2538, 2702) still hardcode the"wikg://"string. This is exactly the kind of drift that made the priorwkg://→wikg://rename touch dozens of call sites; using the constant everywhere would make a future scheme change a one-line edit.♻️ Example fix for two of the helpers
function formatTripleUri( subjectQid: string, predicate: string, objectQid: string, ): string { - return `wikg://triple/${subjectQid}/${encodeURIComponent(predicate)}/${objectQid}`; + return `${WIKI_GRAPH_URI_PREFIX}triple/${subjectQid}/${encodeURIComponent(predicate)}/${objectQid}`; } function formatEntityUri(qid: string): string { - return `wikg://entity/${qid}`; + return `${WIKI_GRAPH_URI_PREFIX}entity/${qid}`; }Also applies to: 4835-4846, 5581-5589
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/archive/query/archive-view.ts` around lines 3357 - 3367, The URI helpers and inline ID builders are still hardcoding the `wikg://` scheme instead of using `WIKI_GRAPH_URI_PREFIX`. Update `formatTripleUri`, `formatEntityUri`, `formatTextStreamRangeUri`, `parseTripleHitUri`, and the affected inline constructions to build URIs from `WIKI_GRAPH_URI_PREFIX` consistently, using the existing parser/helper symbols in `archive-view.ts` so any future scheme change is centralized.
4199-4235: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winRedundant text-stream index reload per fragment.
collectNodeSourceFragmentIdsalready builds and caches acreateTextStreamIndex(document, chapterId, "source")promise per chapter while collectingfragmentIds.readNodeSourceFragmentsthen callscreateTextStreamIndexagain for every fragment in the map, discarding that cache. For nodes spanning multiple fragments in the same chapter this reloads the same index multiple times.Confirm whether
createTextStreamIndexmemoizes internally (e.g., document-level cache); if not, consider returning/reusing the per-chapter index map fromcollectNodeSourceFragmentIdsinreadNodeSourceFragments.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/archive/query/archive-view.ts` around lines 4199 - 4235, The fragment loading in readNodeSourceFragments is re-fetching the same source text-stream index for each fragment instead of reusing the per-chapter index work already done by collectNodeSourceFragmentIds. Update readNodeSourceFragments (or its helper flow around collectNodeSourceFragmentIds and createTextStreamIndex) to reuse the existing per-chapter index/map rather than calling createTextStreamIndex again inside the fragment loop. If createTextStreamIndex is not internally memoized, return or pass along the chapter index from collectNodeSourceFragmentIds so fragment range lookup can use the cached index.
5259-5262: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRemove the redundant URI normalizer
normalizeWikiGraphObjectUriis still an identity helper. Inline or حذف it to avoid implying there’s any URI normalization here.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/archive/query/archive-view.ts` around lines 5259 - 5262, `normalizeWikiGraphObjectUri` is still just an identity helper, so remove the redundant function or inline its call sites in archive-view.ts to avoid implying any URI normalization behavior. Update the nearby callers to use the URI directly, and keep the change scoped around the `normalizeWikiGraphObjectUri` symbol so it can be deleted cleanly if unused.src/archive/search-index/search-index.ts (1)
216-258: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winProgress reporting runs inside the DB transaction.
progress?.()is awaited on every sentence/object while the whole rebuild runs insidedatabase.transaction(...). If the reporter does any blocking I/O (e.g., writing JSONL snapshots per the PR description), the transaction is held open longer than necessary, increasing lock duration on the search-index database for large archives.Consider buffering/throttling progress emission (e.g., every N items or time-based) or moving the transaction boundary so progress emission doesn't gate it.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/archive/search-index/search-index.ts` around lines 216 - 258, Progress reporting in the search index rebuild is awaited inside the database.transaction flow, which keeps the transaction open while progress callbacks do blocking I/O. Update the rebuild logic in search-index.ts around the transaction body and the progress?.() calls in the text/object loops so progress emission is buffered, throttled, or moved outside the transaction boundary. Use the existing rebuild loop structure and the progress callback shape to preserve phase/done/total updates without holding the transaction open on every item.src/cli/local-config.ts (1)
106-112: 🎯 Functional Correctness | 🔵 TrivialSuccess output may print
"undefined"for model/provider.
String(llm.model)/String(llm.provider)read the raw stored config, not the resolved valuesbuildLLMOptionsactually used. If either is unset locally but a default applies internally, the successful test output misleadingly shows "undefined".🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/cli/local-config.ts` around lines 106 - 112, The success payload in local-config output is reading raw fields from llm instead of the resolved values used by buildLLMOptions, which can print "undefined" for model/provider. Update the output construction in local-config to use the resolved model and provider values from the same path that builds the LLM options, and keep the output shape unchanged while ensuring the test result reflects the actual configured values.src/cli/local-config-store.ts (1)
201-222: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winValidate
llm.provideragainst the known provider set at write time.
validateLLMConfigonly checks thatprovideris a non-empty string; the actual set of valid providers (anthropic|google|openai|openai-compatible) is enforced later, only inparseLLMProvider(src/cli/local-config.ts) when runningtest. An invalid provider can be silently persisted viaset/putand will only fail later, at test/job time, with no field-level guidance at write time.♻️ Proposed fix
function validateLLMConfig(value: LocalConfigObject): LocalConfigObject { const allowedKeys = new Set([ "apiKey", "baseURL", "model", "name", "provider", ]); + const allowedProviders = new Set([ + "anthropic", + "google", + "openai", + "openai-compatible", + ]); const next: Record<string, unknown> = {}; for (const [key, entry] of Object.entries(value)) { if (!allowedKeys.has(key)) { throw new Error(`Unknown llm config key: ${key}`); } if (typeof entry !== "string" || entry.trim() === "") { throw new Error(`llm.${key} must be a non-empty string.`); } + if (key === "provider" && !allowedProviders.has(entry.trim())) { + throw new Error(`Unknown llm.provider: ${entry.trim()}`); + } next[key] = entry.trim(); } return next; }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/cli/local-config-store.ts` around lines 201 - 222, `validateLLMConfig` currently accepts any non-empty `llm.provider`, so invalid providers can be saved and only fail later in `parseLLMProvider`. Update the write-time validation in `validateLLMConfig` to explicitly allow only the known provider values (`anthropic`, `google`, `openai`, `openai-compatible`) while keeping the existing non-empty string checks for the other fields, and surface a clear error that points to `llm.provider` when the value is unsupported.src/common/wiki-graph-dir.ts (1)
2-12: 🧹 Nitpick | 🔵 TrivialLGTM! The centralized
WIKIGRAPH_STATE_DIRoverride and new per-category directory resolvers (core,cache,jobs,staging,tmp,logs) are consistent with the downstream consumers (build-queue.ts,wikg-coordinator.ts,local-config-store.ts,search-cache.ts,continuation-cursor.ts,wiki-graph-temp.ts).One note:
resolveWikiGraphCacheDatabasePath()movescache.sqlitefrom directly under the home directory into the newcache/subdirectory, so upgraded installs will leave a stalecache.sqliteat the old location. Since it's rebuildable cache data this is low risk, but worth a mention in release/upgrade notes.Also applies to: 14-16, 18-20, 22-24, 26-28, 30-32, 34-36, 38-39
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/common/wiki-graph-dir.ts` around lines 2 - 12, `resolveWikiGraphCacheDatabasePath()` now points `cache.sqlite` into the new `cache` subdirectory, so upgraded installs may retain an unused copy at the old home-directory location. Keep the path change in the directory resolver functions (especially `resolveWikiGraphCacheDatabasePath`) and add an upgrade/release note that the old `cache.sqlite` is stale rebuildable cache data and may be left behind after migration.src/common/wiki-graph-temp.ts (1)
14-21: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueRemove the redundant
resolveWikiGraphStateRootPathalias — it only forwards toresolveWikiGraphTempRootDirectoryPath(), so the GC call sites can use the temp-root helper directly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/common/wiki-graph-temp.ts` around lines 14 - 21, Remove the redundant resolveWikiGraphStateRootPath alias and update the GC call sites to use resolveWikiGraphTempRootDirectoryPath() directly. In wiki-graph-temp.ts, delete the forwarding function and make any references in resolveWikiGraphTempDirectoryPath or related callers point to the temp-root helper so there is only one root-path API.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@data/help/topics/config.jinja`:
- Around line 19-58: The command examples in this help topic use the shortened
shell name “wikg” while the rest of the docs use “wikigraph”; update the example
commands in this section to the full CLI name while keeping the wikg:// URI
scheme unchanged. Locate the affected examples in the config help template and
normalize every shell invocation consistently so users see the same command name
throughout.
In `@src/cli/local-config-store.ts`:
- Around line 11-17: The shared-state SQLite files are created without explicit
permission hardening, leaving plaintext config values like llm.apiKey exposed.
Update the file-creation path used by resolveWikiGraphCoreDatabasePath(),
openSharedStateDatabase(), and the local config store initialization so the
database, init marker, and lock files are created with owner-only access (for
example via a restrictive umask or explicit 0600 permissions). Make sure the fix
is applied where the files are first created, not just when they are opened.
In `@src/cli/local-config.ts`:
- Around line 204-206: The error message thrown from local-config handling still
references the wrong CLI name, so update the string in the error path that
throws from the local config API key guard to use wikigraph instead of wikg;
check the Error construction in the local-config flow and make sure the command
shown in the message matches the current CLI name exactly.
- Around line 75-147: `runLLMConfigTest` builds LLM options before entering its
error-handling block, so failures from `buildLLMOptions` or `parseLLMProvider`
bypass the structured JSON failure path. Move the `buildLLMOptions` call and the
`llm`-derived option assembly inside the existing try/catch in
`runLLMConfigTest`, so invalid stored config is caught and reported through the
same `{ ok: false, error }` handling and `process.exitCode = 1` flow.
In `@src/editor/editor.ts`:
- Around line 302-334: The overlap logic in listSentencesInRange is shadowing
the requested range start with the fragment start index, which makes the segment
filter too broad. Update the filter in this method so it compares each
fragment’s segmentEndSentenceIndex against the outer requested
startSentenceIndex, and avoid reusing the same variable name inside the
callback. Keep the existing final sentence-level trimming, but ensure the
fragment loading step only fetches fragments that actually overlap the requested
range.
---
Outside diff comments:
In `@src/cli/convert.ts`:
- Around line 245-255: The createAppOptions helper is dropping the
debugLogDirPath option, so CLI debug logging never reaches downstream logDirPath
handling. Update createAppOptions to accept and pass through debugLogDirPath
from CLIArguments into the returned SpineDigestAppOptions alongside verbose and
llm, so the existing debug log flow remains intact.
In `@src/editor/markup.ts`:
- Around line 36-95: The skipped-summary path in the markup builder is scanning
sentence indexes between selected segments, but those gap fragments were never
loaded by loadFragments, so collectSkippedSummary cannot find them. Update the
logic in the markup function to use the actual fragment start ids for the
in-between range instead of incrementing by 1 over sentence indexes, and ensure
the fragments passed into collectSkippedSummary are the ones fetched for those
real fragment starts.
In `@test/cli/args.test.ts`:
- Around line 1694-1802: The root help examples still use the old URI
placeholder name in the layered help contract tests, so update the root-help
text expectations to match the corrected `wikg` scheme placeholder. In
`renderMainHelpText`-driven assertions, replace the `<located-wkg-uri>`
references with the consistent `<located-wikg-uri>` form used by the help
template, keeping the `rootHelpText`/`commandHelpText` checks aligned with the
help renderers.
---
Nitpick comments:
In `@src/archive/query/archive-view.ts`:
- Around line 3357-3367: The URI helpers and inline ID builders are still
hardcoding the `wikg://` scheme instead of using `WIKI_GRAPH_URI_PREFIX`. Update
`formatTripleUri`, `formatEntityUri`, `formatTextStreamRangeUri`,
`parseTripleHitUri`, and the affected inline constructions to build URIs from
`WIKI_GRAPH_URI_PREFIX` consistently, using the existing parser/helper symbols
in `archive-view.ts` so any future scheme change is centralized.
- Around line 4199-4235: The fragment loading in readNodeSourceFragments is
re-fetching the same source text-stream index for each fragment instead of
reusing the per-chapter index work already done by collectNodeSourceFragmentIds.
Update readNodeSourceFragments (or its helper flow around
collectNodeSourceFragmentIds and createTextStreamIndex) to reuse the existing
per-chapter index/map rather than calling createTextStreamIndex again inside the
fragment loop. If createTextStreamIndex is not internally memoized, return or
pass along the chapter index from collectNodeSourceFragmentIds so fragment range
lookup can use the cached index.
- Around line 5259-5262: `normalizeWikiGraphObjectUri` is still just an identity
helper, so remove the redundant function or inline its call sites in
archive-view.ts to avoid implying any URI normalization behavior. Update the
nearby callers to use the URI directly, and keep the change scoped around the
`normalizeWikiGraphObjectUri` symbol so it can be deleted cleanly if unused.
In `@src/archive/search-index/search-index.ts`:
- Around line 216-258: Progress reporting in the search index rebuild is awaited
inside the database.transaction flow, which keeps the transaction open while
progress callbacks do blocking I/O. Update the rebuild logic in search-index.ts
around the transaction body and the progress?.() calls in the text/object loops
so progress emission is buffered, throttled, or moved outside the transaction
boundary. Use the existing rebuild loop structure and the progress callback
shape to preserve phase/done/total updates without holding the transaction open
on every item.
In `@src/cli/llm.ts`:
- Around line 23-32: Remove the obsolete sampling conditionals from
stage-runtime handling because CLIConfig.llm no longer provides temperature or
topP, so those branches are unreachable. Update the logic in the stage runtime
code that builds the LLM config to stop checking for temperature/topP and only
keep the supported fields, using the relevant LLM config assembly path and any
helper that forwards CLIConfig.llm into the model creation flow.
In `@src/cli/local-config-store.ts`:
- Around line 201-222: `validateLLMConfig` currently accepts any non-empty
`llm.provider`, so invalid providers can be saved and only fail later in
`parseLLMProvider`. Update the write-time validation in `validateLLMConfig` to
explicitly allow only the known provider values (`anthropic`, `google`,
`openai`, `openai-compatible`) while keeping the existing non-empty string
checks for the other fields, and surface a clear error that points to
`llm.provider` when the value is unsupported.
In `@src/cli/local-config.ts`:
- Around line 106-112: The success payload in local-config output is reading raw
fields from llm instead of the resolved values used by buildLLMOptions, which
can print "undefined" for model/provider. Update the output construction in
local-config to use the resolved model and provider values from the same path
that builds the LLM options, and keep the output shape unchanged while ensuring
the test result reflects the actual configured values.
In `@src/common/wiki-graph-dir.ts`:
- Around line 2-12: `resolveWikiGraphCacheDatabasePath()` now points
`cache.sqlite` into the new `cache` subdirectory, so upgraded installs may
retain an unused copy at the old home-directory location. Keep the path change
in the directory resolver functions (especially
`resolveWikiGraphCacheDatabasePath`) and add an upgrade/release note that the
old `cache.sqlite` is stale rebuildable cache data and may be left behind after
migration.
In `@src/common/wiki-graph-temp.ts`:
- Around line 14-21: Remove the redundant resolveWikiGraphStateRootPath alias
and update the GC call sites to use resolveWikiGraphTempRootDirectoryPath()
directly. In wiki-graph-temp.ts, delete the forwarding function and make any
references in resolveWikiGraphTempDirectoryPath or related callers point to the
temp-root helper so there is only one root-path API.
In `@src/editor/editor.ts`:
- Around line 236-269: The `#getGroupSegmentStartIndexes()` flow is duplicating
the `this.#document.fragmentGroups.listBySerial(this.#serialId)` fetch that
`#getFullText()` already performs. Refactor `Editor.run()` to fetch and filter
`groups` once, then pass that shared `groups` data into both
`#getGroupSegmentStartIndexes` and `#getFullText` so they stop re-querying the
same records.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d572d1d9-fa7a-4d91-86e7-6feabc1386b7
📒 Files selected for processing (110)
data/help/commands/archive/create.jinjadata/help/commands/archive/estimate.jinjadata/help/commands/archive/evidence.jinjadata/help/commands/archive/export.jinjadata/help/commands/archive/get.jinjadata/help/commands/archive/list.jinjadata/help/commands/archive/next.jinjadata/help/commands/archive/pack.jinjadata/help/commands/archive/related.jinjadata/help/commands/archive/search.jinjadata/help/commands/config-status.jinjadata/help/commands/maintenance/chapter.jinjadata/help/commands/maintenance/chapter/add.jinjadata/help/commands/maintenance/chapter/list.jinjadata/help/commands/maintenance/chapter/move.jinjadata/help/commands/maintenance/chapter/remove.jinjadata/help/commands/maintenance/chapter/reset.jinjadata/help/commands/maintenance/chapter/set-source.jinjadata/help/commands/maintenance/chapter/set-summary.jinjadata/help/commands/maintenance/chapter/set-title.jinjadata/help/commands/maintenance/chapter/tree.jinjadata/help/commands/maintenance/cover.jinjadata/help/commands/maintenance/meta.jinjadata/help/commands/queue.jinjadata/help/commands/queue/add.jinjadata/help/commands/queue/boost.jinjadata/help/commands/queue/cancel.jinjadata/help/commands/queue/clean.jinjadata/help/commands/queue/list.jinjadata/help/commands/queue/pause.jinjadata/help/commands/queue/resume.jinjadata/help/commands/queue/status.jinjadata/help/commands/queue/target.jinjadata/help/commands/queue/watch.jinjadata/help/commands/queue/worker.jinjadata/help/commands/root.jinjadata/help/commands/transform.jinjadata/help/topics/ai.jinjadata/help/topics/command.jinjadata/help/topics/config-file.jinjadata/help/topics/config.jinjadata/help/topics/env.jinjadata/help/topics/format.jinjadata/help/topics/index.jinjadata/help/topics/recipe.jinjadata/help/topics/runtime.jinjadata/help/topics/task.jinjadata/help/topics/troubleshoot.jinjadata/help/topics/uri.jinjapackage.jsonsrc/archive/query/archive-view.tssrc/archive/query/continuation-cursor.tssrc/archive/query/search-cache.tssrc/archive/search-index/index.tssrc/archive/search-index/search-index.tssrc/cli/archive-chapter.tssrc/cli/archive-index.tssrc/cli/archive.tssrc/cli/args.tssrc/cli/config.tssrc/cli/convert.tssrc/cli/errors.tssrc/cli/help.tssrc/cli/llm.tssrc/cli/local-config-store.tssrc/cli/local-config.tssrc/cli/main.tssrc/cli/progress-output.tssrc/cli/queue.tssrc/cli/stage-runtime.tssrc/cli/status.tssrc/common/wiki-graph-dir.tssrc/common/wiki-graph-temp.tssrc/common/wiki-graph-uri.tssrc/editor/clue.tssrc/editor/editor.tssrc/editor/markup.tssrc/facade/build-queue.tssrc/facade/index.tssrc/facade/spine-digest.tssrc/llm/client.tssrc/llm/index.tssrc/llm/types.tssrc/output/epub/book.tssrc/output/plain-text.tssrc/serial.tssrc/wikg/wikg-coordinator.tssrc/wikipage/wikimedia-client.tstest/archive/query/archive-view.test.tstest/archive/query/search-cache.test.tstest/cli/README.mdtest/cli/archive-chapter.test.tstest/cli/archive.test.tstest/cli/args.test.tstest/cli/config.test.tstest/cli/convert.test.tstest/cli/llm.test.tstest/cli/local-config.test.tstest/cli/main.test.tstest/cli/queue.test.tstest/cli/status.test.tstest/common/wiki-graph-uri.test.tstest/editor/editor.test.tstest/facade/build-queue.test.tstest/gc/gc.test.tstest/llm/client.test.tstest/wikg/spine-digest-file.test.tstest/wikimatch/policy-judge.test.tstest/wikipage/normalizer.test.tstest/wikipage/resolver.test.ts
💤 Files with no reviewable changes (7)
- data/help/commands/queue/worker.jinja
- data/help/topics/env.jinja
- data/help/topics/config-file.jinja
- test/cli/status.test.ts
- data/help/commands/config-status.jinja
- src/cli/status.ts
- src/cli/errors.ts
Moskize91
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/document/shared-state-database.ts`:
- Around line 51-61: The existing-database paths in shared-state initialization
skip hardening the database file, so add a best-effort
hardenSharedStateFile(resolvedDatabasePath) before both the early
hasInitMarker(...) return and the marker-exists branch inside the initialize
flow in shared-state-database.ts; keep the current hardening for markerPath and
ensure resolvedDatabasePath is also hardened whenever Database.initialize is
bypassed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6c5540d3-56d0-4616-bf1f-1852907732ca
📒 Files selected for processing (12)
data/help/commands/archive/list.jinjadata/help/commands/root.jinjadata/help/commands/transform.jinjadata/help/topics/command.jinjadata/help/topics/config.jinjasrc/cli/local-config-store.tssrc/cli/local-config.tssrc/document/shared-state-database.tssrc/editor/editor.tssrc/editor/markup.tstest/cli/args.test.tstest/cli/local-config.test.ts
✅ Files skipped from review due to trivial changes (4)
- data/help/commands/transform.jinja
- data/help/topics/command.jinja
- data/help/topics/config.jinja
- data/help/commands/root.jinja
🚧 Files skipped from review as they are similar to previous changes (7)
- data/help/commands/archive/list.jinja
- test/cli/local-config.test.ts
- src/editor/editor.ts
- src/cli/local-config-store.ts
- src/cli/local-config.ts
- src/editor/markup.ts
- test/cli/args.test.ts
This was referenced Jul 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Validation