---
title: Review Cycle Knowledge Capture for Leak SMS v2605
date: 2026-05-19
last_updated: 2026-05-20
category: docs/solutions/workflow-issues
module: leak_sms_v2 operations workflow
problem_type: workflow_issue
component: development_workflow
severity: medium
applies_when:
  - "Finishing a review and execution cycle on the leak monitoring project"
  - "Adding schema, dashboard, report, or Raspberry Pi runtime behavior in one pass"
  - "Adding security evidence pages, attachment packages, or operational checklists"
tags: [v2605, review-cycle, compound, verification, operations]
---

# Review Cycle Knowledge Capture for Leak SMS v2605

> 참고: 이 문서는 누수감지 시절의 기록(레거시)이며, 현재 시스템은 SHT30 온습도 전용으로 전환되었습니다.

## Context

The v2605 hardening work touched PHP pages, MySQL schema, Raspberry Pi capture logic, operations documentation, and deployment notes at the same time. That creates two recurring risks: a feature can be visible in the UI before the DB migration is applied, and static syntax checks can miss broken HTML or operational gaps.

## Guidance

At the end of each execution-review cycle, capture the concrete lessons in `docs/solutions/` before declaring the work finished. For this project, the minimum checklist is:

- Run PHP syntax checks on every changed PHP entry point, including new admin pages.
- Run Python compile checks after Raspberry Pi runtime edits.
- Search non-backup files for stale secrets, old endpoint names, or legacy phone numbers.
- Keep stale-secret search patterns out of durable docs or mask them; otherwise the verification command can reintroduce the exact legacy values it is meant to detect.
- Confirm new SQL migrations are documented in both the project README and the top-level report.
- If a feature depends on optional schema, code the PHP page to degrade safely when the table or column is absent.
- When adding security-evidence features, update both sides of the handoff: runtime screens/scripts (`security_evidence.php`, `collect_evidence.py`) and the HWP attachment docs that tell an operator what to submit.
- After `python -m py_compile`, remove all generated `__pycache__` directories under the workspace, not just the runtime package that was edited.

## Why This Matters

The deployment target is a small operational system where a hidden migration miss can block incident response after a real leak alert. Capturing these checks makes the next cycle faster and reduces repeat mistakes around migrations, secrets, and PHP pages that pass `php -l` but still need markup review.

## When to Apply

- Before calling a v2605 improvement complete.
- After adding DB columns used by dashboard/report pages.
- After adding Raspberry Pi environment variables or runtime timing logic.
- Before handing off deployment notes to an operator.

## Examples

For photo timeline work, the compatible pattern is to detect `leak_photo.sequence_no` and `leak_photo.photo_stage` before using them. New installs can use `sql/schema_v2605.sql`, while existing installs apply `sql/migration_photo_timeline.sql`.

For final verification, keep generated cache directories out of the handoff after running `python -m py_compile`.

For security evidence work, the runtime artifacts and the submission guide must stay aligned. If `php/security_evidence.php?format=md` exists, `docs/SECURITY_EVIDENCE_PACKAGE.md`, `docs/SECURITY_PLAN_PASS_READINESS.md`, and `docs/SECURITY_PLAN_HWP_REVIEW.md` should all point to it. If a Pi evidence collector exists, installation docs must include the exact command and explain that raw API/SMS keys are not printed.

## Related

- `docs/README.md`
- `sql/migration_photo_timeline.sql`
- `php/setup_wizard.php`
- `php/security_evidence.php`
- `php/monthly_report.php`
- `raspberry_pi/collect_evidence.py`
- `docs/SECURITY_EVIDENCE_PACKAGE.md`