Skip closed issues when pulling a repository in bulk #10

New Issue

2026-08-09T19:16:23Z

naudachu commented

2026-08-09 19:16:23 +00:00

Summary

Массовый pull.py в режиме фильтра пишет в стор всё, что вернул сервер, включая
закрытые issues. Закрытые не должны попадать в стор при массовом чтении: их
нужно отбрасывать перед записью, если оператор не запросил их явным
--state closed.

Spec

none

Motivation

Режим фильтра (--milestone / --label / -q) по умолчанию берёт
--state open (skills/sync/scripts/pull.py:65-67), и серверный фильтр
работает корректно. Дыра — в --state all: он расширяет выборку, а обход в
skills/sync/scripts/pull.py:131-149 пишет на диск каждый payload из очереди
без проверки состояния. Клиентская перепроверка фильтра
(skills/sync/scripts/_gitea.py:176-183) сверяет milestone и labels, но не
state.

Наблюдаемый результат: tmp/issues/issue-workflow.md — state: closed,
gitea: claude-skills/tea#1 — лежит в сторе с тем же synced: 2026-08-09T19:11:39Z, что и четыре открытых issue. Один массовый прогон
затащил закрытый #1 вместе с рабочими.

Цена — контекст. Стор читают целиком: INDEX.md, grep по tmp/issues/*.md.
Закрытый issue занимает строку в индексе и попадает в каждую выборку, не будучи
единицей работы. --state all при этом остаётся полезным как способ увидеть
всю картину — ограничение нужно на запись, а не на выборку.

Точечное чтение по номеру (pull.py 1) — это адресный запрос, а не массовое
чтение, и под правило не подпадает.

Acceptance criteria

в режиме фильтра pull.py не создаёт новый файл в сторе для payload с
state: closed, если --state closed не передан явно
--state all продолжает перечислять закрытые (выборка не сужается), но
закрытые не записываются
--state closed записывает закрытые — явный запрос выполняется
issue, который уже есть в сторе, обновляется даже будучи закрытым: локальная
копия получает state: closed, а не остаётся навсегда open
число пропущенных закрытых issues печатается в stderr — молчаливого
отбрасывания нет
чтение по ключам (pull.py 1, #1, owner/repo#1, URL) не затронуто:
закрытый issue по явному номеру тянется как раньше
skills/sync/SKILL.md описывает правило в разделе Pulling

Constraints

Проверка живёт в pull.py, а не в _gitea.py: транспорт не знает, что стор
считает единицей работы. matches() остаётся перепроверкой серверного
фильтра.
Не входит в объём: поведение --deps (закрытые зависимости), фильтрация
закрытых в remote.py и скрытие закрытых в INDEX.md.
Существующие файлы стора не чистятся — задача про запись, не про миграцию.

## Summary Массовый `pull.py` в режиме фильтра пишет в стор всё, что вернул сервер, включая закрытые issues. Закрытые не должны попадать в стор при массовом чтении: их нужно отбрасывать перед записью, если оператор не запросил их явным `--state closed`. ## Spec none ## Motivation Режим фильтра (`--milestone` / `--label` / `-q`) по умолчанию берёт `--state open` (`skills/sync/scripts/pull.py:65-67`), и серверный фильтр работает корректно. Дыра — в `--state all`: он расширяет выборку, а обход в `skills/sync/scripts/pull.py:131-149` пишет на диск каждый payload из очереди без проверки состояния. Клиентская перепроверка фильтра (`skills/sync/scripts/_gitea.py:176-183`) сверяет milestone и labels, но не `state`. Наблюдаемый результат: `tmp/issues/issue-workflow.md` — `state: closed`, `gitea: claude-skills/tea#1` — лежит в сторе с тем же `synced: 2026-08-09T19:11:39Z`, что и четыре открытых issue. Один массовый прогон затащил закрытый #1 вместе с рабочими. Цена — контекст. Стор читают целиком: `INDEX.md`, `grep` по `tmp/issues/*.md`. Закрытый issue занимает строку в индексе и попадает в каждую выборку, не будучи единицей работы. `--state all` при этом остаётся полезным как способ *увидеть* всю картину — ограничение нужно на запись, а не на выборку. Точечное чтение по номеру (`pull.py 1`) — это адресный запрос, а не массовое чтение, и под правило не подпадает. ## Acceptance criteria - [x] в режиме фильтра `pull.py` не создаёт новый файл в сторе для payload с `state: closed`, если `--state closed` не передан явно - [x] `--state all` продолжает перечислять закрытые (выборка не сужается), но закрытые не записываются - [x] `--state closed` записывает закрытые — явный запрос выполняется - [x] issue, который уже есть в сторе, обновляется даже будучи закрытым: локальная копия получает `state: closed`, а не остаётся навсегда `open` - [x] число пропущенных закрытых issues печатается в stderr — молчаливого отбрасывания нет - [x] чтение по ключам (`pull.py 1`, `#1`, `owner/repo#1`, URL) не затронуто: закрытый issue по явному номеру тянется как раньше - [x] `skills/sync/SKILL.md` описывает правило в разделе Pulling ## Constraints - Проверка живёт в `pull.py`, а не в `_gitea.py`: транспорт не знает, что стор считает единицей работы. `matches()` остаётся перепроверкой серверного фильтра. - Не входит в объём: поведение `--deps` (закрытые зависимости), фильтрация закрытых в `remote.py` и скрытие закрытых в `INDEX.md`. - Существующие файлы стора не чистятся — задача про запись, не про миграцию.

claude changed title from ~~Ignore reading closed issues while bunch repository read~~ to Skip closed issues when pulling a repository in bulk

2026-08-09 19:23:43 +00:00

claude added reference feat/issue-cache-scripts

2026-08-09 19:23:43 +00:00

claude added the comp/sync

type

task

labels 2026-08-09 19:23:43 +00:00

naudachu referenced this issue from a commit

2026-08-10 10:11:27 +00:00

feat: work the sync backlog — comments, labels, refs, closed issues

claude changed reference from ~~feat/issue-cache-scripts~~ to feat/issue-cache-scripts

2026-08-10 10:18:31 +00:00