A database-enforced freeze on live projects: no renaming, no deleting, no inserting checkpoints. The stage modal detects the frozen state and replaces the Edit button with 'Locked — project is live' plus an explanation pointing at N/A and at editing the building type for future jobs.
Also called: can't edit checkpoints · locked checklist · why can't I rename this · project is live
- 1materialize_project_stages stamps frozen_at when a project is started
- 2A trigger rejects rename / delete / insert on a frozen project's checkpoints
- 3planned_days is also in the frozen set (migration 142) so the estimate can't follow the actual around; planned_start_day deliberately stays movable because that is the schedule, not the estimate
- 4The Gantt reads the frozen flag from the instance overlay and hides the Edit affordance
The rule the business runs on is that once someone hits Start Project the checklist is what it is: if it is wrong, fix it on the next job, and skip what does not apply on this one. Before the lock, anyone could rename, hide or delete checkpoints on a live build, which meant the list a customer was shown at signing was not necessarily the list anybody was measured against at the end. The lock lives in the database rather than in the screen, because a rule enforced only by a button is one request away from being ignored. The buttons that would break it are hidden too — the alternative was a raw database error thrown at whoever clicked the X.
- Mid-project checklist edits changing what the customer was shown
- Scope quietly moving during a build
- Raw database errors reaching the builder
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →