chore(ocr): 评审脚本移植 Windows/Git Bash 适配 by Seller-1990 · Pull Request #14 · Seller-1990/zcode-advisor

Seller-1990 · 2026-10-08T02:18:27Z

变更

在成熟版（origin/main）基础上仅移植平台适配，不改任何评审逻辑：

适配点	原因
`git rev-parse --git-common-dir` 定位锁与报告	worktree 下 `.git` 是文件不是目录，写死会失效（AGENTS.md §11-11）
GNU timeout 优先，无则退回进程组方案	Git Bash/coreutils 语义更清晰（超时码 124 且带走子进程树）；macOS 路径行为不变
Python 解释器探测（带版本校验）	Windows 的 python3 常是 WindowsApps 应用执行别名，只会弹应用商店
PATH 补 `%APPDATA%/npm`	Windows 的 npm 全局 bin 不在 nvm 路径下
超时判定加入退出码 124	GNU timeout 的超时码

保留的成熟机制：锁所有权（LOCK_ACQUIRED）、原子发布（mktemp + 同目录 mv）、JSON status 白名单（只认 complete）、ref 类型校验（^{commit}）、空树兜底、防符号链接写穿。

复审后重做（2b548b2）

首版把适配写成对 main 的分叉副本，带来三个问题，已在本提交修正：

手改了 CHAIN 快照：被重排成 14 条，与唯一真源 chain-public（16 条）不一致，且含链文件已标注 failed / 必然超时的条目。→ 快照回到与链文件一致的 16 条（该区块由 ocr-sync-reviewer.sh 生成，勿手改）。
缺 main 已有的修复：cleanup() 的 mktemp 防符号链接写穿、record_use 的 skip 判定（避免"今天没评审"被统计成"provider 全挂"）。→ 本文件现在是「main 原文 + 适配」，是 main 的超集而非分叉。
第 95 行用了字面 \n 而非换行续行，循环会多吐出伪候选词 n。→ 改为真换行续行。

Python 探测也比首版更严：不是"命令存在就用"，而是逐个候选跑 sys.version_info[0] == 3 校验——内嵌脚本用了 f-string，指向 Python 2 会直接崩。

落点：模板才是源头

scripts/ocr-review.sh 在本仓是 ocr-sync-reviewer.sh standard 模式的再生副本（整文件由模板覆盖）。所以适配不能只改仓库副本，否则下次同步就被冲掉。本 PR 的改动同时写入：

~/.dsh/templates/ocr-review/ocr-review.sh（public）
~/.dsh/templates/ocr-review/ocr-review.sh.private（private）

已实跑同步器验证幂等：第二次同步报「已是最新」。

实测（本机 macOS）

bash -n 通过；node --test test/ocr-review.test.js → 28/28 pass
npm test → 594 tests / 593 pass / 1 skipped / 0 fail
端到端：bash scripts/ocr-review.sh HEAD~1 HEAD → 首跳 nas-hy4/space-bunny，44s 成功，0 条意见
同步器幂等：连跑两次，第二次全部「已是最新」
模板与仓库副本 sha256 一致（e09729333e8e7865…）

说明

评审 advisory、不拦门。CI 的 code-review 是 advisory 关卡，main 无分支保护。

保留成熟版全部机制（锁所有权、原子发布、JSON 状态白名单、ref 校验），仅改平台差异： - 公共 git 目录定位（git rev-parse --git-common-dir）：worktree 下 .git 是文件，写死 .git 会让锁与报告路径失效（指南 §11 第 11 条） - GNU timeout 优先：Git Bash/coreutils 环境语义更清晰（超时码 124 并带走子进程树）；无 timeout 时仍走原进程组方案（macOS 兼容不变） - python 优先于 python3：Windows 的 python3 常是 WindowsApps 应用执行别名 - PATH 补 Windows npm 全局目录（%APPDATA%/npm） - 超时判定加入退出码 124

github-actions · 2026-10-08T02:19:41Z

🔍 OpenCodeReview found 8 issue(s) in this PR.

✅ Successfully posted inline: 2 comment(s)
📝 In summary (no line info): 2 comment(s)
⏭️ Skipped (overlap with history): 2 comment(s)
❌ Failed to post inline: 2 comment(s)

📄 `scripts/ocr-review.sh`

⚠️ GitHub could not post this as an inline comment: No line information provided

在 APPDATA 变量回退逻辑中，虽然已经处理了 APPDATA 变量的回退，但未检查 APPDATA 变量是否为空或未定义的情况。如果 APPDATA 变量为空，可能会导致路径拼接失败。建议在使用前验证 APPDATA 变量是否存在且非空。

💡 Suggested Change

Before:

for candidate in \
        $(ls -1d "$HOME/.nvm/versions/node/*/bin" 2>/dev/null | sort -Vr) \
        /usr/local/bin /opt/homebrew/bin \
        "${APPDATA:-$HOME/AppData/Roaming/npm}" "$HOME/AppData/Roaming/npm"; do

After:

for candidate in \
        $(ls -1d "$HOME/.nvm/versions/node/*/bin" 2>/dev/null | sort -Vr) \
        /usr/local/bin /opt/homebrew/bin; do
    # 跳过空或无效的 APPDATA 路径
    [ -n "${APPDATA:-}" ] && candidate="${APPDATA}/npm"
    [ -d "$candidate" ] && candidate="$candidate"
    [ -d "$HOME/AppData/Roaming/npm" ] && candidate="$HOME/AppData/Roaming/npm"
    # 继续循环逻辑...
do

📄 `scripts/ocr-review.sh`

⚠️ GitHub could not post this as an inline comment: No line information provided

在 APPDATA 变量回退逻辑中，虽然已经处理了 APPDATA 变量的回退，但未检查 APPDATA 变量是否为空或未定义的情况。建议在使用前验证 APPDATA 变量是否存在且非空，以避免路径拼接失败。例如，可以在使用 APPDATA 之前添加一条验证逻辑：

[ -z "${APPDATA:-}" ] && APPDATA="$HOME/AppData/Roaming"

📄 `scripts/ocr-review.sh` (L57-L57)

⚠️ GitHub could not post this as an inline comment: Line 57 could not be resolved (outside PR diff hunks)

在锁回收逻辑中，虽然增加了 LOCK_ACQUIRED 变量的检查，但未明确说明该变量在所有代码路径中是否被正确设置。特别是在 cleanup 函数中，如果 LOCK_ACQUIRED 未被正确设置，可能会导致误删其他进程的锁。建议在每个可能影响锁状态的代码路径中显式设置或检查 LOCK_ACQUIRED 变量。

📄 `scripts/ocr-review.sh` (L296-L296)

⚠️ GitHub could not post this as an inline comment: Line 296 could not be resolved (outside PR diff hunks)

在 cleanup 函数中，虽然增加了对 LOCK_ACQUIRED 的检查，但未明确说明在 LOCK_ACQUIRED 未设置的情况下，是否会导致锁目录无法被正确回收。建议在 cleanup 函数中增加日志输出，以便在调试时明确知道锁回收的状态。

💡 Suggested Change

Before:

  [ -n "$LOCK_ACQUIRED" ] && rm -rf "$LOCK_DIR"

After:

  if [ -n "$LOCK_ACQUIRED" ]; then
    rm -rf "$LOCK_DIR"
    echo "[ocr-review] 锁目录已回收（$LOCK_DIR）" >&2
  else
    echo "[ocr-review] 跳过锁回收（未持有锁或 FORCE=1 模式）" >&2
  fi

github-actions · 2026-10-08T02:19:42Z

+GIT_COMMON_DIR="$(git rev-parse --git-common-dir 2>/dev/null || echo .git)"
+case "$GIT_COMMON_DIR" in
+  /*|?:*) ;;
+  *) GIT_COMMON_DIR="$REPO_ROOT/$GIT_COMMON_DIR" ;;
+esac


在 Windows 环境下，$REPO_ROOT 与路径拼接时，可能存在反斜杠转义问题。例如，$REPO_ROOT/subdir 在 Windows 中应为 $REPO_ROOT\subdir。建议在拼接路径时使用 cygpath 工具或显式替换 / 为 `) 以确保兼容性。

github-actions · 2026-10-08T02:19:42Z

+case "$GIT_COMMON_DIR" in
+  /*|?:*) ;;


在 Windows 环境下，GIT_COMMON_DIR 的构造逻辑中，使用 ?:* 模式匹配可能无法覆盖所有 Windows 驱动器路径（如 C:\ 或 D:\ 等）。建议使用更健壮的路径匹配逻辑，例如使用 findmnt 或 cygpath 工具来确保路径的正确性，或者使用 git rev-parse --git-dir 作为备用方案。

github-actions · 2026-10-08T02:19:42Z

 #   - 持锁进程仍活着 → 提示并退出（不重复评审）
 #   - 持锁进程已死（崩溃/被 kill）→ 视为陈旧锁，接管
-LOCK_DIR="$REPO_ROOT/.git/ocr-review.lock"
+LOCK_DIR="$GIT_COMMON_DIR/ocr-review.lock"


在 Windows 环境下，LOCK_DIR 路径构造中使用 / 作为分隔符可能导致路径解析失败。建议使用 cygpath 工具将路径转换为 Windows 格式，或者使用反斜杠 `) 进行拼接。

github-actions · 2026-10-08T02:19:42Z

@@ -55,7 +66,7 @@ if [ -z "${OCR_REVIEW_FORCE:-}" ]; then
    [ -f "$LOCK_INFO" ] && HOLD_PID="$(sed -n 's/^pid=//p' "$LOCK_INFO" 2>/dev/null)"
    if [ -n "$HOLD_PID" ] && kill -0 "$HOLD_PID" 2>/dev/null; then


在 Windows Git Bash 或 MSYS 环境下，kill -0 命令可能不可靠，因为它依赖于 Unix 系统的进程管理机制。建议使用 tasklist 或 ps 命令来检查进程存活状态，以确保跨平台兼容性。

github-actions · 2026-10-08T02:19:42Z


+# python 解释器：Windows 上 python3 常是 WindowsApps 应用执行别名（会打 shebang 警告），
+# 优先用真实安装的 python；两者都没有时 python3 兜底（macOS 无 python 只有 python3）。
+PY="$(command -v python || command -v python3 || true)"


在 PY 变量赋值逻辑中，command -v 命令本身不直接暴露命令注入风险，但建议使用更严格的方式（如 type -p 或 which）来避免潜在的 $PATH 污染问题。此外，确保 python 和 python3 的优先级逻辑在 Windows 环境下正确处理 WindowsApps 别名问题。

github-actions · 2026-10-08T02:19:42Z

+PY="$(command -v python || command -v python3 || true)"
+[ -n "$PY" ] || { echo "错误：找不到 python 解释器（渲染评审结果需要）" >&2; exit 1; }


在 PY 变量赋值逻辑中，虽然已经处理了 Windows 环境下的 python3 别名问题，但建议进一步验证 PY 变量的值在 Windows 环境下是否确实指向可用的 Python 解释器。例如，可以添加一行验证代码，确保 $PY --version 能够正常执行，以避免潜在的路径或版本问题。

github-actions · 2026-10-08T02:19:42Z

 valid_output() {
  [ -s "$OUT_JSON" ] || return 1
-  python3 - "$OUT_JSON" <<'PYCHECK' >/dev/null 2>&1
+  "$PY" - "$OUT_JSON" <<'PYCHECK' >/dev/null 2>&1


在 valid_output 函数中，使用 "$PY" 执行 Python 代码块时，可能存在 Python 版本兼容性问题。建议明确指定 Python 版本（如 python3），并确保 encoding="utf-8" 在所有 Python 版本下都能正确处理。

github-actions · 2026-10-08T02:19:42Z

+  # 新机（Windows Git Bash / 装了 coreutils 的机器）有 GNU timeout，优先用它：
+  # 语义清晰（超时退出码 124），且 MSYS 会一并带走子进程树。
+  # 没有 timeout 时才走下面的进程组方案（macOS 自带 bash 3.2 的原始实现）。
+  if command -v timeout >/dev/null 2>&1; then
+    timeout "$secs" "$@"
+    return $?
+  fi


在 run_with_deadline 函数中，虽然优先使用了 GNU timeout 命令，但缺少对 Windows 环境下 timeout 命令的明确兼容性验证。虽然代码中已经处理了 GNU timeout 的优先级，但建议在 Windows 环境下进一步验证 timeout 命令的可用性和行为一致性，以确保超时退出码（如 124）在所有平台上都能正确处理。

github-actions · 2026-10-08T02:19:42Z

  case "$HOP_RC" in
-    137|143) echo "  ⚠ 本跳到 ${HOP_LIMIT}s 上限被强制终止（退出码 ${HOP_RC}），降级到下一个" ;;
+    124|137|143) echo "  ⚠ 本跳到 ${HOP_LIMIT}s 上限被强制终止（退出码 ${HOP_RC}），降级到下一个" ;;


在处理超时退出码时，124（GNU timeout）与 137/143（进程组信号）的逻辑在 Windows 环境下可能不一致。建议明确区分不同平台的超时退出码处理逻辑，并确保在所有平台上都能正确识别和处理。

CI 评审（PR #14）指出 Windows 兼容性风险，逐条核实后确认为真问题： Windows 自带 C:/Windows/System32/timeout.exe 是同名异物（等 N 秒的延时命令，不包装别的命令）。原判定用 `command -v timeout`，若 PATH 解析命中该 exe， `timeout 900 ocr review …` 会被它当成非法参数静默跑偏（实测：报「指定的超时(/T)值无效」但退出码为 0，脚本无从察觉）。改为 `timeout --version` 探测：GNU 版有该选项，Windows 版没有（实测两者行为可区分）。其余 8 条 CI 意见经核实为误报： - 路径拼接/cygpath（3 条）：Git Bash 下 MSYS 自动转换 / 与 \，实测锁与报告路径均正常 - kill -0 不可靠：实测对存活/已死进程判定均正确 - PY 变量注入/校验：command -v 无注入面；python 3.12 实测可用 - 超时码 124/137/143 不一致：已按平台分别覆盖，属设计意图

github-actions · 2026-10-08T02:45:03Z

    if [ -n "$HOLD_PID" ] && kill -0 "$HOLD_PID" 2>/dev/null; then
      echo "[ocr-review] 已有评审在进行（pid ${HOLD_PID}），本次跳过以免重复消耗。"
-      echo "[ocr-review] 已有报告：$REPO_ROOT/.git/ocr-review-last.txt"
+      echo "[ocr-review] 已有报告：$GIT_COMMON_DIR/ocr-review-last.txt"


在 Windows 环境下，GIT_COMMON_DIR 变量拼接的路径可能包含空格或特殊字符，导致路径解析错误。建议使用引号包裹路径，并确保路径分隔符正确。例如，可以使用 "$GIT_COMMON_DIR/ocr-review-last.txt" 来确保路径被正确解析。

github-actions · 2026-10-08T02:45:03Z

+  "nas-hy4|space-bunny"
  "x666|ministral-14b-latest"


在 CHAIN 数组中，新增的条目 "nas-hy4|space-bunny" 和 "lucky|stealth/space-bunny-alpha" 可能存在重复或混淆。建议确认 space-bunny 是否与 stealth/space-bunny-alpha 完全不同，或者是否应合并或删除其中一个以避免冗余。同时，确保所有条目在实际使用时都符合预期的模型名称和配置。

github-actions · 2026-10-08T02:45:03Z

+  "nas-hy4|deepseek-v4.1-flash"
+  "nas-hy4|deepseek-v4.1-flash-sg"


在 CHAIN 数组中，新增的条目 "nas-hy4|deepseek-v4.1-flash-sg" 与现有的 "nas-hy4|deepseek-v4.1-flash" 非常相似，仅在末尾多了 -sg 后缀。建议明确说明这两个条目之间的区别，或者确认是否应合并或删除其中一个以避免混淆。

github-actions · 2026-10-08T02:45:03Z

+  "nas-hy4|glm-5.3"
+  "nas-hy4|gpt-6-astra"
+  "nas-hy4|gemini-3.8-flash"
+  "nas-hy4|kimi-k2.8-preview"


在 CHAIN 数组中，新增的条目 "nas-hy4|kimi-k2.8-preview" 未见相关说明或文档。建议在代码中或注释中明确说明该模型的用途、来源或与其他模型的区别，以便于维护和理解。

github-actions · 2026-10-08T02:45:03Z

+  # ⚠️ 必须用 `timeout --version` 探测而不是 `command -v timeout`：Windows 自带
+  #    C:/Windows/System32/timeout.exe 是同名异物（等 N 秒的延时命令，不包装别的命令），
+  #    命中它会把 `timeout 900 ocr review …` 当成非法参数静默跑偏。


在 run_with_deadline 函数中，新增的 GNU timeout 检测逻辑使用了 timeout --version 命令来判断工具是否可用。然而，Windows 自带的 timeout 命令（位于 C:/Windows/System32/timeout.exe）可能会误导检测结果，因为它不支持 --version 参数。虽然代码中已经考虑了这一点，但建议进一步明确说明该逻辑的限制条件，并考虑添加更详细的错误处理或日志输出，以便在检测失败时提供更明确的反馈。

github-actions · 2026-10-08T02:45:03Z

+  if timeout --version >/dev/null 2>&1; then
+    timeout "$secs" "$@"
+    return $?
+  fi


在 run_with_deadline 函数中，新增的 GNU timeout 检测逻辑虽然提高了 Windows 环境下的兼容性，但未处理非 GNU timeout 工具的情况。如果系统中既没有 GNU timeout 也没有其他超时工具，脚本可能会进入无限等待或意外行为。建议淽加更健壮的超时处理机制，例如回退到原有的 shell 实现或使用其他可靠的超时工具。

原两次提交把适配写成对 main 的分叉副本，带来三个问题： - CHAIN 快照被手工重排为 14 条，与唯一真源 chain-public（16 条）不一致，且含链文件标注已 failed / 必然超时的条目； - 缺 main 已有的 mktemp 防符号链接写穿修复、record_use 的 skip 判定； - 第 95 行用了字面 \n 而非换行续行。本提交把该文件重建为「origin/main 原文 + 平台适配」，并同步进模板（~/.dsh/templates/ocr-review/ocr-review.sh 与 .private，模板才是 standard 模式的复制源，改副本不落模板会在下次同步时被整文件覆盖）： - 公共 git 目录定位（worktree 下 .git 是文件），锁与报告路径改走 GIT_COMMON_DIR； - PATH 候选补 Windows npm 全局目录，续行改为真换行； - Python 解释器探测带版本校验（拒绝 Python 2，内嵌脚本用 f-string）； - GNU timeout 优先（用 --version 探测，避开 Windows 同名 timeout.exe）； - 超时退出码 124 计入强制终止判定； - 链快照回到与 chain-public 一致的 16 条。

github-actions · 2026-10-08T08:20:32Z

@@ -144,17 +171,22 @@ AGENT_MODEL="$(tr -d '[:space:]' < "$AGENT_MODEL_FILE" 2>/dev/null || true)"
 CHAIN_FILE="${OCR_REVIEW_CHAIN_FILE:-$HOME/.dsh/templates/ocr-review/chain-public}"
 CHAIN_SCOPE="public"   # public 副本：cloud 条目合法，但仍以链文件为唯一真源
 CHAIN=(


在 CHAIN 数组中，虽然注释明确指出该数组是兜底快照，但新增的模型列表（如 space-bunny、lucky-gem 等）没有对应的详细说明或链接到外部文档。建议在注释中补充说明这些模型的来源、适用场景或注意事项，以便于维护者快速理解和调整。例如，可以参考旧注释中的格式，说明是否支持工具调用、是否有特殊配置要求等。

github-actions · 2026-10-08T08:20:32Z

 cleanup() {
  if [ -n "${OCR_REVIEW_RAW_OUT:-}" ] && [ -n "${CHOSEN:-}" ]; then


在 cleanup 函数中，虽然增加了对 LOCK_ACQUIRED 的检查，但未明确说明在 LOCK_ACQUIRED 未设置的情况下，是否会导致锁目录无法被正确回收。建议在 cleanup 函数中增加日志输出，以便在调试时明确知道锁回收的状态。例如，可以在 LOCK_ACQUIRED 未设置时输出一条警告日志，提示锁回收被跳过。

* fix(test): 超时退出码断言补 124，修 main 上的单元测试红灯 PR #14 给 run_with_deadline 加了「有 GNU timeout 就优先用它」的分支，脚本这边 case 已经改成 124|137|143，但测试的断言只写了 137|143： - macOS（本机开发环境）没有 timeout，走进程组回退，返回 143 → 本地全绿； - ubuntu-latest 有 GNU timeout，到点自杀返回 124 → main 上这个用例红。实测复现：把 GNU timeout 的行为（自成进程组 + 整组 TERM→KILL + 返回 124）做成 PATH 上的替身，再用旧断言跑，报的错与 CI 一字不差： actual: ' ⚠ 本跳到 2s 上限被强制终止（退出码 124），降级到下一个\n…' expected: /上限被强制终止（退出码 (137|143)）/ error: '超时必须明说并带上退出码' 脚本的分类没错（124 确实是 GNU timeout 到点自杀的码），错的是断言把平台的具体退出码写死了。改成只要求「是脚本认定为被强制终止的那组码」，并补注释说明两条实现路径各返回什么。两条路径本机都实测通过（原 143 路径 28/28；注入 GNU timeout 替身后 28/28，含孙进程回收断言）。 * ci: PR 也跑单元测试（Linux 差异此前只在合并后才暴露） build-installers 原先只在 push main / tag / 手动触发时跑，PR 上只有 ocr-review 的 advisory 评审，不跑 npm test —— 所以「本机全绿、Linux 红」这类差异会一路合进 main 才亮灯。PR #14 和 #15 就是这么各红了一次（两次都是同一个用例）。构建类 job 都带 `startsWith(github.ref,'refs/tags/v') || event_name == 'workflow_dispatch'` 守卫，加 pull_request 后 PR 上只剩 test 这一个 job。顺带修掉文件头一句不实的注释（原先写「此前只有 tag 与 PR 触发测试」，实际从来没有过 pull_request 触发，git log 三个版本都没有）。

github-actions Bot reviewed Oct 8, 2026

View reviewed changes

Seller-1990 merged commit 67766d4 into main Oct 8, 2026
1 check passed

Seller-1990 deleted the chore/ocr-review-win-adapt branch October 8, 2026 08:21

This was referenced Oct 8, 2026

fix(ocr-review): 采纳评审意见（版本探针 / 空格路径 / 注释回归） #15

Merged

fix(ci): 超时退出码断言补 124 + PR 阶段也跑单元测试（修 main 上的红灯） #16

Merged

		@@ -55,7 +66,7 @@ if [ -z "${OCR_REVIEW_FORCE:-}" ]; then
		[ -f "$LOCK_INFO" ] && HOLD_PID="$(sed -n 's/^pid=//p' "$LOCK_INFO" 2>/dev/null)"
		if [ -n "$HOLD_PID" ] && kill -0 "$HOLD_PID" 2>/dev/null; then

		PY="$(command -v python \|\| command -v python3 \|\| true)"
		[ -n "$PY" ] \|\| { echo "错误：找不到 python 解释器（渲染评审结果需要）" >&2; exit 1; }

		"nas-hy4\|deepseek-v4.1-flash"
		"nas-hy4\|deepseek-v4.1-flash-sg"

		cleanup() {
		if [ -n "${OCR_REVIEW_RAW_OUT:-}" ] && [ -n "${CHOSEN:-}" ]; then

Conversation

Seller-1990 commented Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

变更

复审后重做（2b548b2）

落点：模板才是源头

实测（本机 macOS）

说明

Uh oh!

github-actions Bot commented Oct 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📄 scripts/ocr-review.sh

📄 scripts/ocr-review.sh

📄 scripts/ocr-review.sh (L57-L57)

📄 scripts/ocr-review.sh (L296-L296)

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot Oct 8, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Seller-1990 commented Oct 8, 2026 •

edited

Loading

github-actions Bot commented Oct 8, 2026 •

edited

Loading

📄 `scripts/ocr-review.sh`

📄 `scripts/ocr-review.sh`

📄 `scripts/ocr-review.sh` (L57-L57)

📄 `scripts/ocr-review.sh` (L296-L296)