# 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`/`BooleanField`s 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)

1. **Brainstorm first** — the new workflow (piling vs casting, etc.)
   must drive the metric model. Do not start from the old metric list.
2. **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`.
3. **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.
4. **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`.
5. New design doc + plan under `docs/plans/`, normal
   brainstorm → writing-plans → subagent execution, HARD STOP before
   push (it touches the daily attendance path).