- Зачем: - зафиксировать состояние конвейера #5 перед долгой живой приёмкой, чтобы новая сессия продолжила без потери контекста. - Что: - в handoff добавлена дельта 23:10: обе находки FIXED (фрагменты ID с SHA-256-цепочкой), перепроверка линией B — APPROVED; - обновлено состояние стенда: им владеет сценарий приёмки; - в .scratch/issue5-run добавлены свежие отчёты, перепроверка и сценарий приёмки acceptance-issue5.sh. - Проверка: - git show --stat; лог приёмки — до строки SCRIPT_EXIT_CODE=.
54 lines
2.8 KiB
Markdown
54 lines
2.8 KiB
Markdown
# Triage round: issue #5 — both review lines, coordinator header
|
|
|
|
You are the executor continuing your own issue #5 implementation (working
|
|
tree on branch feature/mentee-path; your original mandate:
|
|
mandate-issue5.md in this same directory, your report: report-issue5.md).
|
|
Do the per-finding triage and fix.
|
|
|
|
## Coordinator header (agreements / contradictions / boundary notes)
|
|
|
|
- Both independent lines converge on ONE blocking defect:
|
|
CODE-1 (line B, code quality) == TASK-1 (line A, task conformance).
|
|
The cumulative manifest payload carries exact click_id/uid sets:
|
|
~0.81 MB already on the reference world, Kafka default 1 MiB message
|
|
limit is not overridden anywhere → manifest save fails after roughly one
|
|
more next-day. Size is O(history); the issue's disease moves from
|
|
read-time to a write-time ceiling. No contradictions between the lines.
|
|
- Line B additionally: CODE-2 (Low) — next-day saves state before manifest
|
|
(import does the reverse), widening the half-advanced window.
|
|
- Full reports (read them directly):
|
|
- line B (code): review-issue5-code.md (same directory)
|
|
- line A (task): review-issue5-task.md (verdict text; sandbox blocked its
|
|
full file write)
|
|
|
|
## Coordinator decisions for the fix (boundaries, not design)
|
|
|
|
- The issue's GOAL is time O(new day), no full Kafka reread, no OOM risk.
|
|
Linear GROWTH of stored counter state over days is acceptable on a demo
|
|
stand — a hard silent ceiling is not. Whatever representation you choose,
|
|
the failure mode must be explicit and far away, and the write path must
|
|
not break within the demo's realistic horizon (say, world age of
|
|
hundreds of days).
|
|
- Manifest numbers must stay EXACT (the check against ClickHouse uniqExact
|
|
is the learning value) — no approximate sketches.
|
|
- Reference artifact in git stays unchanged; determinism invariants from
|
|
the original mandate stay in force.
|
|
- Prefer the simplest solution that meets the above (учебная ценность:
|
|
a mentee should be able to read and understand it). If two viable
|
|
options differ in product trade-offs (e.g. raising Kafka topic limits vs
|
|
restructuring the payload), pick one, implement it, and justify; return
|
|
NEEDS_DECISION only if the choice genuinely changes user-visible
|
|
behaviour or issue acceptance criteria.
|
|
|
|
## What to return
|
|
|
|
For each finding ID (CODE-1/TASK-1 as one item is fine, CODE-2): one status
|
|
line `ID | FIXED/REJECTED/OUT_OF_SCOPE/NEEDS_DECISION | essence + evidence`.
|
|
Details go to the report: APPEND a "## Triage round 1" section to
|
|
report-issue5.md (same directory): chosen representation and why, measured
|
|
payload size on the reference world after the fix, projection of growth,
|
|
new/changed tests, make test / make lint exit codes.
|
|
|
|
Rules unchanged: no commits, no changes to data/ artifact, docs updated in
|
|
the same change if state/manifest semantics shift.
|