fix(pipeline-status): match full receipt pattern in check_memory #21
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/check-memory-receipt-pattern"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Что сделано
pipeline-status.py:check_memory(строки 702–723): заменён substring-поискpattern in f.read_text()на regex full-match receipt-форматаre.compile(rf"- \[\d{{4}}-\d{{2}}-\d{{2}}, PR#{pr_number}\]"). Теперь требуется полная квитанция- [YYYY-MM-DD, PR#N]— префикс- [date,и закрывающая]после номера.tests/test_pipeline_status.py: добавлены 3 regression-теста в секцию# ── check_memory ───:test_check_memory_no_substring_collision—PR#180в файле,check_memory(18)→ NOT_DONEtest_check_memory_no_adr_ref_match— ADR-ref(PR#18)без receipt,check_memory(18)→ NOT_DONEtest_check_memory_matches_real_receipt— реальный receipt- [2026-08-07, PR#18] — durable: ...,check_memory(18)→ DONE.opencode/agents/reviewer.mdсекция## Known deterministic links: обновлены обе записи (строки 406–408 и 411–413) — «expectsPR#Nliteral» → «expects- [YYYY-MM-DD, PR#N]receipt pattern (regex, full match)».Почему
После миграции репо с GitHub (PR до ~#290) на Forgejo (нумерация с #1) детектор
pattern in f.read_text()(бессодержательный substring-поиск) коллидировал: (a)PR#18— подстрокаPR#180/PR#181/... (22 вхождения вopencode-config.md), (b)PR#18совпадает со старой GitHub ADR-ref(PR#18)(1 вхождение). В результатеcheck_memoryвозвращал ложный DONE для всех Forgejo PR #1–#18, иrun-pipelineпропускал фазу memory-syncer — durable-знания по этим PR не попадали в память. Regex требует полную квитанцию:]после номера отсекает подстроки (PR#180→ после18идёт0), префикс- [date,отсекает ADR-ref'ы ((PR#18)→ нет префикса, после18идёт)).Watch out
memory-syncer.mdНЕ менялся — он уже пишет корректный формат- [YYYY-MM-DD, PR#N] <content>(строки 69–83). Reader (pipeline-status.py) просто начал матчить то, что writer давно пишет.get_memory_files()multi-file scan (PR#245 fix) НЕ менялся — regex применяется к тому же списку файлов.[type-arg]на строках 92/133/191 (dictбез type-args) — не связаны с этой правкой, присутствуют наorigin/main(проверено черезgit stash).Pending
Closes #20
Code Review Summary
Чистый fix: замена substring-поиска
PR#Nна regex full-match receipt-формата- [YYYY-MM-DD, PR#N]вcheck_memory. Корректно решает оба collision-кейса (substringPR#180vsPR#18, ADR-ref(PR#18)). 3 regression-теста покрывают все сценарии, existing тесты не сломаны (11/11 passed).Positives
rf"- \[\d{{4}}-\d{{2}}-\d{{2}}, PR#{pr_number}\]"— в f-string{{→{, итоговый regex- \[\d{4}-\d{2}-\d{2}, PR#18\].\]вне character class — просто literal], валидно. Проверено вручную: 7 edge cases (substring, ADR-ref, real receipt, empty receipt, single-digit date, multi-digit PR) — все ожидаемые результаты.PR#180), ADR-ref ((PR#18)), positive (real receipt). Мокиget_memory_filesчерезmonkeypatch.setattr(ps, "get_memory_files", lambda: [memory_file])— корректные, изолированные,tmp_pathобеспечивает clean state.test_check_memory_not_done_no_files(PR#46),test_check_memory_not_done_no_pattern,test_check_memory_not_done_remote_error— все pass.memory-syncer.mdНЕ менялся (строки 69-83 уже пишут- [YYYY-MM-DD, PR#N] <суть>), reader обновлён.reviewer.mdKnown deterministic links (строки 406-408, 411-413) обновлены консистентно: «expectsPR#Nliteral» → «expects- [YYYY-MM-DD, PR#N]receipt pattern (regex, full match)». Форматmemory/SKILL.md:83иrun-pipeline/SKILL.md:124совпадают с regex.## Что сделано/## Почему/## Watch out/## Pending— все заполнены осмысленно,Watch outсодержит 5 конкретных пунктов (writer unchanged, multi-file scan unchanged, return values, pre-existing mypy errors, retro out of scope).get_memory_files()не тронут, return values DONE/NOT_DONE без AMBIGUOUS (per PR#245 контракт).check_memory— 22 строки, well under 50-line limit.reуже импортирован (строка 29), новых импортов нет.Suggestions (info, not blocking)
get_memory_file_path()(старое имя функции, теперьget_memory_files()). Не в scope этого PR, но стоит обновить в отдельном PR — может запутать при feature-spec анализе.Verdict: APPROVE