Files
clickstream-ch-kafka-supers…/.scratch/issue5-run/triage-issue5.md
T
ddadmin f4971e94ca docs(scratch): handoff — триаж #5 закрыт, ревью APPROVED, идёт приёмка
- Зачем:
  - зафиксировать состояние конвейера #5 перед долгой живой приёмкой,
    чтобы новая сессия продолжила без потери контекста.
- Что:
  - в handoff добавлена дельта 23:10: обе находки FIXED (фрагменты ID
    с SHA-256-цепочкой), перепроверка линией B — APPROVED;
  - обновлено состояние стенда: им владеет сценарий приёмки;
  - в .scratch/issue5-run добавлены свежие отчёты, перепроверка и
    сценарий приёмки acceptance-issue5.sh.
- Проверка:
  - git show --stat; лог приёмки — до строки SCRIPT_EXIT_CODE=.
2026-07-22 23:11:44 +03:00

2.8 KiB

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.