Konrad du Plessis 777c7c6dcc docs: SiteReport removal design + future-rebuild capture doc

Konrad-approved design to fully remove the SiteReport / "Log Today's
Work" feature (drop core_sitereport, no backup, revert post-attendance
to redirect-home). Capture doc preserves the schema-as-Python pattern,
the flow, recovery pointers, and rebuild guidance. Local-only; the
removal itself is HARD-STOPPED before push.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-17 01:23:09 +02:00

5.4 KiB

Raw Blame History

SiteReport / "Log Today's Work" — Removed; Future-Rebuild Capture

Date removed: 17 May 2026 Why this doc exists: Konrad removed the SiteReport feature to rethink site-progress logging from scratch, separately. This file preserves everything worth knowing so a future session can rebuild it without re-deriving the design — and without resurrecting code that no longer fits.

Status: NOT a plan. Do NOT implement from this file. It is a knowledge capsule. A future rebuild starts with a fresh brainstorming pass (see "When you rebuild" at the bottom).

Why it was removed (the important part)

The on-site work mix is changing. The original feature was modelled around a solar-farm foundation workflow (plinths cast, plinth holes dug, boxes placed, steel placed, …). Konrad's words: "we might start piling and not cast so many plinths anymore so the scope might get bigger or smaller." The metric set — and whether a fixed metric set is even the right model — is genuinely unknown. Half-fitting code on a daily-use path is worse than a clean slate. So: full removal now, deliberate redesign later when the new workflow is clearer.

Konrad explicitly accepted irreversible loss of existing SiteReport rows (no backup taken) — the data was lightly used and not worth carrying into a redesign.

What it did (so you don't have to reverse-engineer it)

A SiteReport model, optional 1:1 with WorkLog (a WorkLog with no report was a normal historical row). Fields:

weather (choices: sunny/cloudy/rain/storm/hot/cold/windy), temperature_min / temperature_max (°C, IntegerField), free-form notes, created_by, created_at, updated_at.
metrics — a JSONField of shape {'counts': {key: int}, 'checks': {key: bool}}.

The one genuinely good idea worth keeping: schema-as-Python, no migration

The metric keys were NOT model columns. They lived in a single Python file core/site_report_schema.py (COUNT_METRICS, CHECK_METRICS, label_for()). Adding/removing/renaming a metric was a one-line edit + redeploy — no DB migration, old rows degrade gracefully (missing key → 0/unchecked; retired key still shows via label_for fallback). SiteReportForm iterated the schema at __init__ to build dynamic IntegerField/BooleanFields and serialised back into the JSON blob on save().

This pattern is the single most reusable lesson. Given Konrad's "scope may get bigger or smaller" concern, a flexible-by-default schema (JSON blob + a Python/DB-driven field list) is almost certainly the right foundation again — possibly upgraded to an admin-managed MetricTemplate model if per-project metric sets diverge.

The flow it was wired into

Two-step: attendance_log POST (success) → redirect to /site-report/<work_log_id>/edit/ (mobile-first form, "Skip" link to home). Read-only view at /site-report/<work_log_id>/. Permission: admin, or supervisor of the WorkLog's team/project. On removal the flow reverted to the original redirect → home + success toast.

Prior thinking already on disk (mine these, then move past them)

docs/plans/2026-05-15-post-attendance-flow-v2-design.md + -plan.md — a fully designed, Konrad-approved-but-never-built rework of this flow: replace the forced redirect with 3 explicit buttons (Log Work → dashboard / + Site Journal / + Absences), plus a "Save + Add Absences" button; and a Path-A display-only rename "Site Report" → "Site Journal" (to free the word "Journal" for the parked voice-notes feature). Superseded by the removal — the flow it modified no longer exists. Kept on disk because the button-hierarchy and naming-collision analysis are good raw material.
docs/plans/2026-05-17-site-report-removal-design.md — the removal design that this capture accompanies.

How to recover the deleted implementation if you want a reference

The full original implementation is in git history. The recovery point is the commit immediately before 0018_delete_sitereport landed on ai-dev. To find and read any deleted file:

git log --oneline -- core/site_report_schema.py        # last commit is the recovery point
git show <that_sha>:core/site_report_schema.py
git show <that_sha>:core/models.py        # SiteReport class
git show <that_sha>:core/forms.py         # SiteReportForm
git show <that_sha>:core/views.py         # site_report_edit / _detail / _can_access_site_report
git show <that_sha>:core/templates/core/site_report_edit.html

Nothing is lost from code history — only the production table and its rows were dropped.

When you rebuild (guidance, not a plan)

Brainstorm first — the new workflow (piling vs casting, etc.) must drive the metric model. Do not start from the old metric list.
Keep the JSON-blob + Python/admin-driven schema idea — it is the right answer to "scope may change." Decide early: fixed global schema vs per-project MetricTemplate.
Decide the flow deliberately — the v2 design's "3 explicit buttons, no forced redirect" instinct was sound; revisit it with fresh eyes against the new workflow.
Re-evaluate the model name — "SiteReport" / "Site Journal" / something else; mind the parked voice-notes "Journal" collision noted in the Backburner section of parked-work.md.
New design doc + plan under docs/plans/, normal brainstorm → writing-plans → subagent execution, HARD STOP before push (it touches the daily attendance path).

5.4 KiB Raw Blame History