Write issue dependencies to Gitea on push #13

New Issue

2026-08-09T19:58:25Z

claude commented

2026-08-09 19:58:25 +00:00

Summary

Локальный граф depends: не доезжает до трекера. Push отправляет зависимые
issues в топологическом порядке, но не создаёт в Gitea ни одной нативной связи,
и слаги в ## Depends on не превращаются в #N. Транспорт эндпоинт связей
знает — но только на чтение.

Spec

skills/issue/references/format.md

Steps to reproduce

Завести два локальных issue, второй зависит от первого:

python3 skills/issue/scripts/issue_new.py --type task --title "First thing"
python3 skills/issue/scripts/issue_new.py --type task --title "Second thing" \
    --depends first-thing

Убедиться, что граф локально есть: python3 skills/issue/scripts/issue_tree.py
рисует ребро, а push.py --dry-run перечисляет зависимость первой.
Отправить оба одним прогоном:
```
python3 skills/sync/scripts/push.py
```
Спросить у трекера связи зависимого issue (номер — из вывода push):
```
tea api --login "$GITEA_LOGIN" repos/claude-skills/tea/issues/12/dependencies
```

Expected

Gitea знает, что второй issue заблокирован первым: эндпоинт возвращает номер
блокирующего, в веб-интерфейсе видна панель зависимостей, закрыть зависимый
раньше блокирующего нельзя.

Actual

[]

Связей нет. В секции зависимостей уехал слаг:

- tick-in-body-checkboxes-from-a-domain-script — разбор чекбоксов живёт в
  доменном слое, слой sync его импортирует, а не переопределяет

Для читателя в трекере это мёртвый текст: ни ссылки, ни номера, ни панели.
Предупреждение skills/sync/scripts/push.py:158-162 при этом молчит — оно
ловит только зависимости, оставшиеся локальными, а блокирующий issue ушёл в том
же прогоне и номер получил.

Перевод односторонний. На pull #N из тела превращается в слаги
(skills/sync/scripts/map.py:101, numbers_in_body) и pull.py --deps читает
нативные связи (skills/sync/scripts/_gitea.py:223, native_deps). Обратного
направления нет ни в одном виде: native_deps — читатель без писателя.

Наблюдалось на claude-skills/tea#11 и #12, отправленных одним push.

Environment

Gitea 1.26.1, tea 0.14.2. Эндпоинт связей —
/repos/{owner}/{repo}/issues/{index}/dependencies; GET по нему уже
используется в _gitea.py:223, форму тела для POST (IssueMeta:
index/owner/repo) надо подтвердить на инстансе перед реализацией.
Затронуты skills/sync/scripts/push.py и _gitea.py; map.py:175 намеренно
не переписывает прозу ## Depends on — это правило остаётся в силе.

Acceptance criteria

после push зависимого issue GET /repos/{owner}/{repo}/issues/{index}/dependencies
возвращает номер того, от чего он зависит
связи ставятся, когда оба issue уже получили номера — топологический
порядок push'а это гарантирует, отдельного прохода не требуется
зависимость, оставшаяся локальной, связью не становится: предупреждение
push.py:158-162 сохраняется
связь, которая в трекере уже есть, повторным push не дублируется и не
роняет прогон
--update доносит связи, появившиеся в depends: после первого push
--dry-run печатает, какие связи будут созданы, и не делает ни одного
пишущего запроса
проза ## Depends on уходит вербатим: слаги в ней не переписываются в
#N, тело не меняется на круге pull → push
удаление связи, пропавшей из depends:, в объём не входит и явно
оговорено в докстринге push.py
запись живёт в push.py / _gitea.py; skills/issue/ не изменён, и
grep -rh '^import \|^from ' skills/issue/scripts/ по-прежнему даёт
только stdlib
skills/sync/SKILL.md описывает симметрию: push пишет нативные связи,
pull их читает (--deps)

## Summary Локальный граф `depends:` не доезжает до трекера. Push отправляет зависимые issues в топологическом порядке, но не создаёт в Gitea ни одной нативной связи, и слаги в `## Depends on` не превращаются в `#N`. Транспорт эндпоинт связей знает — но только на чтение. ## Spec `skills/issue/references/format.md` ## Steps to reproduce 1. Завести два локальных issue, второй зависит от первого: ```bash python3 skills/issue/scripts/issue_new.py --type task --title "First thing" python3 skills/issue/scripts/issue_new.py --type task --title "Second thing" \ --depends first-thing ``` 2. Убедиться, что граф локально есть: `python3 skills/issue/scripts/issue_tree.py` рисует ребро, а `push.py --dry-run` перечисляет зависимость первой. 3. Отправить оба одним прогоном: ```bash python3 skills/sync/scripts/push.py ``` 4. Спросить у трекера связи зависимого issue (номер — из вывода push): ```bash tea api --login "$GITEA_LOGIN" repos/claude-skills/tea/issues/12/dependencies ``` ## Expected Gitea знает, что второй issue заблокирован первым: эндпоинт возвращает номер блокирующего, в веб-интерфейсе видна панель зависимостей, закрыть зависимый раньше блокирующего нельзя. ## Actual ``` [] ``` Связей нет. В секции зависимостей уехал слаг: ``` - tick-in-body-checkboxes-from-a-domain-script — разбор чекбоксов живёт в доменном слое, слой sync его импортирует, а не переопределяет ``` Для читателя в трекере это мёртвый текст: ни ссылки, ни номера, ни панели. Предупреждение `skills/sync/scripts/push.py:158-162` при этом молчит — оно ловит только зависимости, оставшиеся локальными, а блокирующий issue ушёл в том же прогоне и номер получил. Перевод односторонний. На pull `#N` из тела превращается в слаги (`skills/sync/scripts/map.py:101`, `numbers_in_body`) и `pull.py --deps` читает нативные связи (`skills/sync/scripts/_gitea.py:223`, `native_deps`). Обратного направления нет ни в одном виде: `native_deps` — читатель без писателя. Наблюдалось на claude-skills/tea#11 и #12, отправленных одним push. ## Environment Gitea 1.26.1, tea 0.14.2. Эндпоинт связей — `/repos/{owner}/{repo}/issues/{index}/dependencies`; GET по нему уже используется в `_gitea.py:223`, форму тела для POST (`IssueMeta`: `index`/`owner`/`repo`) надо подтвердить на инстансе перед реализацией. Затронуты `skills/sync/scripts/push.py` и `_gitea.py`; `map.py:175` намеренно не переписывает прозу `## Depends on` — это правило остаётся в силе. ## Acceptance criteria - [x] после push зависимого issue `GET /repos/{owner}/{repo}/issues/{index}/dependencies` возвращает номер того, от чего он зависит - [x] связи ставятся, когда оба issue уже получили номера — топологический порядок push'а это гарантирует, отдельного прохода не требуется - [x] зависимость, оставшаяся локальной, связью не становится: предупреждение `push.py:158-162` сохраняется - [x] связь, которая в трекере уже есть, повторным push не дублируется и не роняет прогон - [x] `--update` доносит связи, появившиеся в `depends:` после первого push - [x] `--dry-run` печатает, какие связи будут созданы, и не делает ни одного пишущего запроса - [x] проза `## Depends on` уходит вербатим: слаги в ней не переписываются в `#N`, тело не меняется на круге pull → push - [x] удаление связи, пропавшей из `depends:`, в объём не входит и явно оговорено в докстринге `push.py` - [x] запись живёт в `push.py` / `_gitea.py`; `skills/issue/` не изменён, и `grep -rh '^import \|^from ' skills/issue/scripts/` по-прежнему даёт только stdlib - [x] `skills/sync/SKILL.md` описывает симметрию: push пишет нативные связи, pull их читает (`--deps`)

claude added the comp/sync

labels 2026-08-09 19:58:25 +00:00

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

2026-08-10 10:58:16 +00:00

claude closed this issue

2026-08-10 11:06:55 +00:00

Sign in to join this conversation.