refactor(occupancy): move OFFSET calculation to service layer, align reset window, and include pending_offset #230

New issue

Open

opened 2026-10-03 07:23:21 +00:00 by gabogg · 0 comments

gabogg commented

2026-10-03 07:23:21 +00:00

Owner

Follow-up for PR #177 (next-day settings activation, #114) addressing pass-3 review findings P3-G, P3-L, and P3-M:

Scope

OFFSET Formula Domain Seam (P3-G): The OFFSET activation formula currently lives in the repository (occupancy_repository.py), violating architectural boundaries (§1.3) by placing domain mathematics in persistence. Move the computation into occupancy_service.py and replace the fallback magic number 8 with configured patrol_guard_count.
OFFSET Window Alignment (P3-L): The OFFSET activation net is measured from its own effective_boundary_epoch. If a reset change for the same day is also pending (e.g. 04:00 -> 03:00), the window differs, causing counts in the transition window (03:00–04:00) to be missed. Measure from the adjusted cycle boundary.
Pending Offset Notice (P3-M): pending_offset in the pending activation notice is currently always None for OFFSET changes. Populate it with the expected target/offset value.

Acceptance Criteria

Baseline offset calculation math resides strictly within service layer methods, not inside occupancy_repository.py.
OFFSET activation accurately reflects the effective reset boundary of the target cycle when concurrent reset changes exist.
Pending activation notice returned by offset calibration endpoints includes the prospective pending_offset value.

Refs #177, #114.

Follow-up for PR #177 (next-day settings activation, #114) addressing pass-3 review findings P3-G, P3-L, and P3-M: ### Scope 1. **OFFSET Formula Domain Seam (P3-G)**: The OFFSET activation formula currently lives in the repository (`occupancy_repository.py`), violating architectural boundaries (§1.3) by placing domain mathematics in persistence. Move the computation into `occupancy_service.py` and replace the fallback magic number `8` with configured `patrol_guard_count`. 2. **OFFSET Window Alignment (P3-L)**: The OFFSET activation net is measured from its own `effective_boundary_epoch`. If a reset change for the same day is also pending (e.g. 04:00 -> 03:00), the window differs, causing counts in the transition window (03:00–04:00) to be missed. Measure from the adjusted cycle boundary. 3. **Pending Offset Notice (P3-M)**: `pending_offset` in the pending activation notice is currently always `None` for OFFSET changes. Populate it with the expected target/offset value. ### Acceptance Criteria - Baseline offset calculation math resides strictly within service layer methods, not inside `occupancy_repository.py`. - OFFSET activation accurately reflects the effective reset boundary of the target cycle when concurrent reset changes exist. - Pending activation notice returned by offset calibration endpoints includes the prospective `pending_offset` value. Refs #177, #114.

gabogg added the

ready-for-agent

label

2026-10-03 07:23:21 +00:00

gabogg referenced this issue

2026-10-03 07:23:57 +00:00

feat(schedule): activate manual calibration and time changes next day #177

gabogg referenced this issue

2026-10-03 07:24:32 +00:00

feat(schedule): activate manual calibration and time changes next day #177