From b6e0d416912b4f7a94aa2863eb187d382bc5e12e Mon Sep 17 00:00:00 2001 From: Amirhossein Khalili Date: Sun, 27 Sep 2026 10:46:07 +0330 Subject: [PATCH] Plan simpler direct-save content CMS --- tasks/bundle1-checkpoint-d-review.md | 2 ++ tasks/bundle1-simplification-plan.md | 52 ++++++++++++++++++++++++++++ tasks/cms-api-contract-draft.md | 2 ++ tasks/plan.md | 2 ++ tasks/todo.md | 41 +++++++++++----------- 5 files changed, 78 insertions(+), 21 deletions(-) create mode 100644 tasks/bundle1-simplification-plan.md diff --git a/tasks/bundle1-checkpoint-d-review.md b/tasks/bundle1-checkpoint-d-review.md index f1b0bd9..c9f3212 100644 --- a/tasks/bundle1-checkpoint-d-review.md +++ b/tasks/bundle1-checkpoint-d-review.md @@ -1,5 +1,7 @@ # Bundle 1 — Checkpoint D review +**Superseded on 2026-09-27; not approved.** The owner rejected this draft/publish workflow and custom admin screens. The replacement [direct-save CMS plan](bundle1-simplification-plan.md) defines the next Checkpoint D review. + Prepared 2026-09-27. **Awaiting owner review.** This covers T08–T09: editorial draft/publish/restore rules and Django admin editing. Public and private preview APIs (T10–T11), seed (T12–T13), and frontend adapter (T14) have not started. ## What is ready diff --git a/tasks/bundle1-simplification-plan.md b/tasks/bundle1-simplification-plan.md new file mode 100644 index 0000000..cb7eaa8 --- /dev/null +++ b/tasks/bundle1-simplification-plan.md @@ -0,0 +1,52 @@ +# Bundle 1 course correction: simple site content CMS + +Decision recorded 2026-09-27. The owner rejected the draft/publish/revision workflow and custom content admin screens. This plan supersedes the CMS workflow and API portions of the approved Bundle 0 contract and the pending Checkpoint D review. Checkpoint C remains an accurate record of what was reviewed then, but its revision-based schema is no longer the target design. The approved Home/About visual direction and the content ownership inventory remain useful. + +## Agreed behavior + +- The CMS edits the shared site identity and the four fixed public pages: Home, About, Events listing, and Blog listing. Event and blog detail records remain in their existing systems. +- A superuser, or an active staff user with the standard Django `change` permission for the relevant content model, edits the record in Django admin. There are no content-specific editor/publisher roles, drafts, publication flags, preview endpoints, revision snapshots, or custom restore action. +- Saving a valid record makes its text, images, and SEO available to the public site on the next request. The frontend must not retain a stale page cache after an admin save; verify the actual deployed cache behavior before cutover. +- Each fixed page has one editable record with named fields that match the approved layout. Editors do not create pages, edit slugs, manipulate section types/order/visibility, or edit raw JSON. A record's SEO title, description, and social image are editable; canonical routes and structured-data shape stay in code. Shared site identity supplies defaults. +- Admin forms use the project's installed Unfold `ModelAdmin`, native fieldsets and supported widgets, matching the existing Blog Category form. No handwritten content admin CSS or custom dashboard/form templates. +- Keep useful plain-text, URL, image-signature, size, dimension, and alt-text validation. Use direct image upload fields where practical. Remove media approval and immutability rules that existed only for publication. + +## Work sequence and review gates + +### 1. Migration and permissions audit + +Inspect each target environment for applied `content` migrations, existing content/media rows, and assignments to the content-specific permissions or groups. Record the result before changing schema. Preserve real content and images; map any existing public revision to the new current record. If no published revision exists, do not expose an unreviewed draft automatically. Add forward migrations for shared or applied migration history; do not silently rewrite committed migrations. Translate any actual staff access to standard model permissions before retiring custom permissions. Keep other apps and their permissions untouched. + +**Check:** migration works from a fresh database and a copy with the current content schema; existing real records and access are accounted for. + +### 2. Replace the content model and admin + +Create one fixed record per page and one shared site record, using explicit text, image/alt, and SEO fields for the approved design. Use ordinary Unfold change forms grouped into Content, Images, and SEO. Ensure the four records exist without presenting an arbitrary “Add editorial page” flow; disable deletion. Remove the draft/revision services, publication audit, custom content groups, and custom admin templates after data and permission migration. Django's normal admin history is sufficient for basic change history. + +**Check:** a superuser and a staff user with the relevant `change` permission can save; a staff user without it cannot. Review the actual Home, About, Events, Blog, and site forms at phone and desktop widths against the supplied Blog Category example. Saving invalid text or media shows a field error in the Unfold form. + +### 3. Serve current content + +Expose only the small public read API needed by the frontend for shared site content and the four fixed pages. Responses contain current text, media URLs/alt text, and SEO fields. Remove revision IDs, status, draft preview, publish, and restore from the schema. Define empty-record behavior and cache handling so a successful admin save appears on the next public request. + +**Check:** anonymous reads return current saved values; unknown pages and missing records have explicit responses; an admin save is visible through the API immediately. No draft or preview route exists. + +### 4. Populate reviewed starting content + +Use the existing content inventory to prepare the four fixed records and site identity. Review disputed claims, contacts, and media rights before they become public. Import approved values once without overwriting subsequent admin edits. A small repeatable initialization/data migration is preferable to a general-purpose seed workflow; a dry run is only needed if the environment audit reveals existing data that could be overwritten. + +**Check:** compare each imported value and image with its approved source; a second initialization leaves edited records unchanged. + +### 5. Connect the frontend and verify SEO + +Keep the frontend feature flag defaulting to legacy content until the new records are complete and checked. Read the fixed page records server-side, populate the approved Home/About layout and Events/Blog listing copy, and use CMS SEO values in rendered HTML and social metadata. Existing event/blog detail APIs and dynamic content stay in place. Remove frontend preview/publish assumptions from later redesign tasks. + +**Check:** editing a heading, image, and SEO title in Unfold changes the public page and server-rendered metadata after Save, with no separate publication action. Verify at 390px and desktop, including Persian text and missing optional images. + +### 6. Release gate + +Rehearse migrations and media on a database copy, check backups, then enable the frontend flag after content and admin walkthrough approval. Keep flag rollback available. Verify public pages, metadata, permissions, and unaffected blog/event flows. Production changes require the existing release gate. + +## Explicit removals from the old plan + +Retire old T08–T11's draft/publish/restore/preview requirements and Checkpoint D's role review. Replace T12–T13's draft seed workflow with reviewed initial records. Update T14, T16–T18, T24, T30, and T38–T39 so their checks require direct-save content, not publication. The old review and contract files remain as historical evidence and are marked superseded, not presented as active instructions. diff --git a/tasks/cms-api-contract-draft.md b/tasks/cms-api-contract-draft.md index 0dec373..da8e5fa 100644 --- a/tasks/cms-api-contract-draft.md +++ b/tasks/cms-api-contract-draft.md @@ -1,5 +1,7 @@ # Public content CMS and API contract — approved for implementation +**Superseded for CMS implementation on 2026-09-27.** The owner chose [direct-save content editing](bundle1-simplification-plan.md) and rejected the draft/publish/revision and custom admin workflow below. This file records the earlier approval only; use the course correction plan and current [checklist](todo.md) for new work. + Date: 2026-09-24; revised 2026-09-25; approved by the owner through `bundle0-review.md` on 2026-09-26. Status: **Bundle 0 contract approved for implementation; no public API or schema exists yet**. Inputs: `content-inventory.md`, `product-review.md`, frontend `PRODUCT.md` and `DESIGN.md`, existing Django Ninja routing in `guilan-ace-backend/config/api.py`. ## Ownership boundary diff --git a/tasks/plan.md b/tasks/plan.md index 55a0782..6678a2b 100644 --- a/tasks/plan.md +++ b/tasks/plan.md @@ -1,5 +1,7 @@ # Guilan ACE redesign and public-content CMS: implementation plan +**CMS course correction (2026-09-27):** The owner replaced this document's draft/publish and flexible-section proposals with the [simple direct-save CMS plan](bundle1-simplification-plan.md). Follow that plan and the updated [checklist](todo.md) for all CMS work. The original decisions below remain historical context for the broader redesign, not active CMS requirements. + Status: Bundle 0 discovery and design contract approved by the owner on 2026-09-26; product implementation has not started. This plan is shared across the frontend, backend, and deployment repositories. The executable checklist is [todo.md](todo.md). Later implementation checkpoints and production rollout approvals remain required. ## Outcome and boundaries diff --git a/tasks/todo.md b/tasks/todo.md index b729407..8869700 100644 --- a/tasks/todo.md +++ b/tasks/todo.md @@ -2,7 +2,7 @@ This is an **implementation backlog**, with work-in-progress noted below and checkboxes reserved for accepted work. See [plan.md](plan.md) for scope, estimates, migration sequence, and release gates. `F`, `B`, and `D` mean frontend, backend, and deployment repository. Each item is intended to fit one focused session (S = 1–2 files; M = 3–5 files); split any item that grows larger. In addition to each item’s check, apply the definition of done: focused and regression tests, lint/build, runtime/browser check, security/rollback where relevant, and human review. -Bundle 0 started 2026-09-24 and was approved by the owner on 2026-09-26. Deliverables: [content inventory](content-inventory.md), [baseline](baseline-2026-09-24.md), [local journey replay](evidence/2026-09-24/local-replay.md), [product/asset review](product-review.md), [CMS/API contract](cms-api-contract-draft.md), backend [API schema](../../guilan-ace-backend/docs/content-api-schema-draft.md), and the approved Home/About visual direction linked from frontend `DESIGN.md`. The owner approved the [Home](concepts/d-logo-led-home.html) and [About](concepts/d-logo-led-about.html) direction on 2026-09-25, then approved the [Bundle 0 review](bundle0-review.md) on 2026-09-26, accepting the content boundary, recorded baseline, and CMS/API contract. T01–T05 and Checkpoints A/B are closed at discovery and contract scope. The current pytest suites pass all 237 tests; the earlier 89-error run is preserved as historical evidence. External SMS/OAuth/live-gateway checks, disputed seed claims, and production media/account assignments remain follow-up work in later gates. Bundle 1 started 2026-09-27; Checkpoint C was approved by the owner on 2026-09-27. +Bundle 0 started 2026-09-24 and was approved by the owner on 2026-09-26. Deliverables: [content inventory](content-inventory.md), [baseline](baseline-2026-09-24.md), [local journey replay](evidence/2026-09-24/local-replay.md), [product/asset review](product-review.md), [CMS/API contract](cms-api-contract-draft.md), backend [API schema](../../guilan-ace-backend/docs/content-api-schema-draft.md), and the approved Home/About visual direction linked from frontend `DESIGN.md`. The owner approved the [Home](concepts/d-logo-led-home.html) and [About](concepts/d-logo-led-about.html) direction on 2026-09-25, then approved the [Bundle 0 review](bundle0-review.md) on 2026-09-26, accepting the content boundary, recorded baseline, and CMS/API contract. T01–T05 and Checkpoints A/B are closed at discovery and historical contract scope. The current pytest suites pass all 237 tests; the earlier 89-error run is preserved as historical evidence. External SMS/OAuth/live-gateway checks, disputed seed claims, and production media/account assignments remain follow-up work in later gates. Bundle 1 started 2026-09-27; Checkpoint C was approved by the owner on 2026-09-27. The owner changed the CMS direction on 2026-09-27; the active scope is [simple direct-save content editing](bundle1-simplification-plan.md), which supersedes the earlier draft/publish contract. ## 0. Discovery and design contract (4–5 person-days) @@ -16,31 +16,30 @@ Bundle 0 started 2026-09-24 and was approved by the owner on 2026-09-26. Deliver ## 1. CMS foundation and migration (9–12 person-days) -Checkpoint C was approved by the owner on 2026-09-27 after reviewing [the schema and validation record](bundle1-checkpoint-c-review.md). T08–T09 are implemented and verified; [Checkpoint D review](bundle1-checkpoint-d-review.md) is pending. Acceptance checkboxes remain open until owner review. +Checkpoint C was approved by the owner on 2026-09-27 after reviewing [the schema and validation record](bundle1-checkpoint-c-review.md). T08–T09 were implemented under the old contract but rejected as too complex on 2026-09-27. Their pending [Checkpoint D review](bundle1-checkpoint-d-review.md) is superseded, not approved. Follow the [course correction plan](bundle1-simplification-plan.md) below. - [x] **T06 — Add site identity and page schema (M; deps: T05).** Files: B new content app models/migration/tests. Acceptance: one site identity, stable page slugs, ordered typed sections, image/alt and SEO fields exist with uniqueness/validation; migrations are additive. Verify: migration test and `python manage.py check` on a test database. - [x] **T07 — Validate fields and media handling (M; deps: T06).** Files: B content validators/tests. Acceptance: URLs, section payloads, image type/size, alt text, and unsafe markup are constrained; absent optional media renders safely. Verify: invalid/oversize/malicious inputs rejected in focused tests. - [x] **Checkpoint C (deps: T06–T07).** Schema and validation reviewed before permissions/API work. Approved by the owner on 2026-09-27. -- [ ] **T08 — Implement draft, publish, and revision permissions (M; deps: T06).** Files: B content services/permissions/tests. Acceptance: staff draft, publisher publish/restore, superuser override, audit trail, and atomic published snapshot; unauthorized edits/publish fail. Verify: role-matrix and concurrent-publish tests. -- [ ] **T09 — Configure Django admin editing workflow (M; deps: T07–T08).** Files: B content admin/forms/tests. Acceptance: editors can edit/reorder/hide only defined sections, see validation, preview draft, and identify published revision without raw JSON editing. Verify: hands-on staff/publisher Django admin walkthrough at desktop and phone widths. -- [ ] **Checkpoint D (deps: T08–T09).** Draft cannot leak or publish by the wrong role. -- [ ] **T10 — Expose public published-content API (M; deps: T08).** Files: B content Ninja router/schemas/tests, `config/api.py`. Acceptance: only published identity/pages appear; missing content has explicit behavior; response shape and cache headers are documented. Verify: anonymous API tests including unpublished-only data. -- [ ] **T11 — Expose authenticated no-store preview (M; deps: T08, T10).** Files: B preview route/auth/tests. Acceptance: approved staff can preview exact draft, anonymous callers cannot, and response is uncached. Verify: permission/cache tests and a real preview URL walkthrough. -- [ ] **Checkpoint E (deps: T10–T11).** API contract frozen for frontend integration. -- [ ] **T12 — Produce versioned seed manifest (M; deps: T01, T06).** Files: B content seed data, D migration notes. Acceptance: stable keys, exact legacy text, source paths, media checksums, and owner-approval status documented; disputed contacts/counts are excluded from automatic publication. Verify: manifest diffed against current live pages/code and signed by content owner. -- [ ] **T13 — Build idempotent dry-run seed command (M; deps: T12).** Files: B management command/tests. Acceptance: prints create/skip/conflict and field diffs, supports no-write mode, never overwrites editor changes by default, and seeds approved entries as drafts. Verify: run twice on a database copy; second run is no-op; altered content reports conflict. -- [ ] **Checkpoint F (deps: T12–T13).** Seed and approval behavior demonstrated on staging-sized data before production use. -- [ ] **T14 — Add frontend CMS adapter and cutover flag (M; deps: T10).** Files: F content fetch/types/flag tests. Acceptance: published content can be fetched server-side with typed fallback; flag defaults to legacy rendering until launch; preview is never cached publicly. Verify: integration tests with CMS available, unavailable, and stale response. +- [ ] **T08 — Audit current CMS data and permissions (S; deps: T06–T07).** Files: B migration/data audit, D environment record. Acceptance: applied migrations, real content/media rows, and content-specific group/permission assignments are known for each target environment; any data/access migration is mapped. Verify: fresh and current-schema database copies. This replaces the old draft/publish T08. +- [ ] **T09 — Simplify content schema and use native Unfold forms (M; deps: T08).** Files: B content models/migrations/admin/forms/tests. Acceptance: one editable record per fixed page and shared site identity; explicit text/image/alt/SEO fields; direct Save; standard Django model change permissions; no arbitrary page creation, custom admin templates, draft/revision/approval workflow, or delete action. Verify: permission tests, migrations, and superuser/authorized staff admin walkthrough at 390px and desktop against the existing Unfold Blog Category form. This replaces the old T09 and its review criteria. +- [ ] **Checkpoint D (deps: T09).** Owner reviews the real Unfold content forms and direct-save permission behavior before API work. +- [ ] **T10 — Expose current-content read API (M; deps: T09).** Files: B content Ninja router/schemas/tests, `config/api.py`. Acceptance: shared site record and four fixed pages expose current content and SEO, with explicit missing/unknown behavior and no revision/status/preview fields. Verify: anonymous read and save-then-read tests, including cache behavior. +- [ ] **Checkpoint E (deps: T10).** The small current-content API shape is checked before frontend integration. No private preview API is planned. +- [ ] **T12 — Review starting content and media (M; deps: T01, T09).** Files: D source review, B initial content data. Acceptance: exact legacy values and sources are reviewed; disputed claims/links and unlicensed media are excluded until approved. Verify: owner checks the content that will become public. +- [ ] **T13 — Initialize fixed content records safely (S; deps: T12).** Files: B data migration or small initialization command/tests. Acceptance: approved starting values are inserted once, existing admin edits are preserved, and no draft status exists. Verify: apply twice on a database copy; second run leaves edited records unchanged. Add a dry run only if the T08 audit finds overwrite risk. +- [ ] **Checkpoint F (deps: T12–T13).** Starting public content and images are reviewed before frontend cutover. +- [ ] **T14 — Add frontend CMS adapter and cutover flag (M; deps: T10).** Files: F content fetch/types/flag tests. Acceptance: current content can be fetched server-side with typed fallback; flag defaults to legacy rendering until launch; saving in admin does not leave stale public content. Verify: integration tests with CMS available, unavailable, and changed content. ## 2. Home/About and shared public shell (9–12 person-days) - [ ] **T15 — Establish approved visual tokens and shell (M; deps: T05, T14).** Files: F global styles, fonts, navigation/footer components. Acceptance: approved typography/colors/layout, responsive header/footer, and CMS identity/navigation/contact fields match comps; RTL/keyboard/reduced-motion work. Verify: screenshot comparison at 320/390/768/1440px and keyboard pass. -- [ ] **T16 — Build CMS-driven Home editorial sections and domain previews (M; deps: T15).** Files: F Home view, section components, tests. Acceptance: hero/featured-section/CTA text comes from published CMS in the fixed owner-approved order; event and blog cards read existing domain APIs with truthful status, useful links, and sound empty/long layouts. Verify: editor text change appears on preview then public page only after publish; event/blog source changes update previews; visual review at all widths. +- [ ] **T16 — Build CMS-driven Home editorial sections and domain previews (M; deps: T15).** Files: F Home view, section components, tests. Acceptance: hero/featured-section/CTA text comes from the current CMS record in the fixed owner-approved order; event and blog cards read existing domain APIs with truthful status, useful links, and sound empty/long layouts. Verify: an admin Save changes the public text on the next request; event/blog source changes update cards; visual review at all widths. - [ ] **Checkpoint G (deps: T15–T16).** Home concept fidelity and real content signed off before About. -- [ ] **T17 — Build CMS-driven About sections (M; deps: T15).** Files: F About view, section components, tests. Acceptance: official identity, mission, committee/association facts, and contacts come from approved published data; unsupported claims are absent. Verify: compare rendered content to approved manifest and test visibility/reorder. -- [ ] **T18 — Make page SEO/structured data content-driven (M; deps: T16–T17).** Files: F route metadata/SEO utilities/tests. Acceptance: canonical, title, description, OG image, and structured-data identity are consistent with published CMS and server-rendered HTML; no stale hardcoded names. Verify: inspect HTML/JSON-LD and link previews on staging. +- [ ] **T17 — Build CMS-driven About sections (M; deps: T15).** Files: F About view, section components, tests. Acceptance: official identity, mission, committee/association facts, and contacts come from reviewed current CMS records; unsupported claims are absent. Verify: compare rendered content to approved starting values and confirm an admin Save changes the page. +- [ ] **T18 — Make page SEO/structured data content-driven (M; deps: T16–T17).** Files: F route metadata/SEO utilities/tests. Acceptance: canonical, title, description, OG image, and structured-data identity are consistent with current CMS records and server-rendered HTML; no stale hardcoded names. Verify: inspect HTML/JSON-LD and link previews on staging after an admin Save. - [ ] **T19 — Finish Home/About interaction and accessibility pass (M; deps: T16–T18).** Files: F affected page/styles/tests. Acceptance: motion supports comprehension but does not block content, reduced-motion works, contrast/focus/read order and Persian line wraps pass. Verify: real browser desktop/mobile captures, keyboard, screen-reader spot check, and Impeccable critique against approved comp. -- [ ] **Checkpoint H (deps: T17–T19).** Owner approves Home/About on staging; content editors can make and publish a visible change without developer help. +- [ ] **Checkpoint H (deps: T17–T19).** Owner approves Home/About on staging; authorized staff can Save a visible change without developer help. ## 3. Authentication (5–7 person-days) @@ -52,7 +51,7 @@ Checkpoint C was approved by the owner on 2026-09-27 after reviewing [the schema ## 4. Events and registration (9–12 person-days) -- [ ] **T24 — Redesign event discovery (M; deps: T15, T02).** Files: F Events view/cards/tests. Acceptance: upcoming/past/full states, date/location/price, filters, and empty/error states are clear without changing query semantics; editorial page intro/SEO reads the published CMS record. Verify: fixture-based state matrix at phone/desktop widths and a CMS publish check. +- [ ] **T24 — Redesign event discovery (M; deps: T15, T02).** Files: F Events view/cards/tests. Acceptance: upcoming/past/full states, date/location/price, filters, and empty/error states are clear without changing query semantics; listing intro/SEO reads the current CMS record. Verify: fixture-based state matrix at phone/desktop widths and an admin Save check. - [ ] **T25 — Redesign event detail and eligibility explanation (M; deps: T24).** Files: F EventDetail view/test. Acceptance: schedule, capacity/availability, prerequisites, organizer, and call to action match existing backend data and rules; no invented promise. Verify: compare UI against API fixtures for open/closed/full/free/paid cases. - [ ] **Checkpoint J (deps: T24–T25).** Student can decide whether an event is relevant before entering registration. - [ ] **T26 — Clarify registration forms and transitions (M; deps: T25).** Files: F event form/registration tests. Acceptance: field requirements, validation, duplicate/closed/full responses, and retry are legible; requests and eligibility rules unchanged. Verify: browser/API contract tests for every backend error/status. @@ -63,12 +62,12 @@ Checkpoint C was approved by the owner on 2026-09-27 after reviewing [the schema ## 5. Blog (4–6 person-days) - [ ] **T29 — Audit existing blog before editing (S; deps: T15, T02).** Files: F blog audit notes/tests. Acceptance: existing strengths and gaps in discovery, article typography, media, SEO, and interactions are recorded; no unnecessary rewrite. Verify: editorial and reader walkthrough on mobile/desktop. -- [ ] **T30 — Apply selected blog refinements (M; deps: T29).** Files: F Blog/list/detail components/tests. Acceptance: visual system is coherent, article reading and navigation improve, existing URLs/actions/content remain intact; editorial listing intro/SEO reads the published CMS record. Verify: screenshot/keyboard review with long Persian article and code block plus a CMS publish check. +- [ ] **T30 — Apply selected blog refinements (M; deps: T29).** Files: F Blog/list/detail components/tests. Acceptance: visual system is coherent, article reading and navigation improve, existing URLs/actions/content remain intact; listing intro/SEO reads the current CMS record. Verify: screenshot/keyboard review with long Persian article and code block plus an admin Save check. - [ ] **T31 — Blog regression gate (M; deps: T30).** Files: F blog tests/SEO. Acceptance: listing, category/tag navigation, article render, share/interactions, and metadata still work. Verify: browser and API contract checks. ## 6. Frontend staff admin (7–10 person-days) -- [ ] **T32 — Map staff roles and mobile task priorities (M; deps: T02, T15).** Files: F admin IA/spec. Acceptance: top tasks for event manager, blog editor, publisher, and general staff are documented; access is not confused with visual hiding. Verify: role-based task walkthrough with actual members. +- [ ] **T32 — Map staff roles and mobile task priorities (M; deps: T02, T15).** Files: F admin IA/spec. Acceptance: top tasks for event manager, blog editor, content editor, and general staff are documented; access is not confused with visual hiding. Verify: permission-based task walkthrough with actual members. - [ ] **T33 — Restructure admin navigation and overview (M; deps: T32).** Files: F AdminLayout/Dashboard/tests. Acceptance: navigation and summaries work at phone/tablet/desktop, with no off-screen controls or meaningless dashboard clutter. Verify: responsive screenshots and keyboard navigation. - [ ] **Checkpoint L (deps: T32–T33).** At least one staff member completes top tasks at 390px and desktop widths. - [ ] **T34 — Make tables, forms, and confirmations responsive (M; deps: T33).** Files: F admin event/user/blog shared patterns/tests. Acceptance: filters, bulk actions, destructive confirmations, and long forms remain visible and operable at 320px; dense data has a deliberate mobile pattern. Verify: real-device/viewport walkthrough of create/edit/search/confirm tasks. @@ -78,7 +77,7 @@ Checkpoint C was approved by the owner on 2026-09-27 after reviewing [the schema ## 7. Release hardening and production cutover (4–7 person-days) - [ ] **T37 — Cross-site quality gate (M; deps: T19, T23, T28, T31, T36).** Files: F/B tests and D QA record. Acceptance: lint/build/tests pass, critical routes meet accessibility/SEO/performance budgets against baseline, no critical mobile/RTL defect remains. Verify: CI plus Chrome/Firefox/Safari-equivalent checks where available and reduced-motion/keyboard review. -- [ ] **T38 — Rehearse migration, backup, and rollback (M; deps: T13, T37).** Files: D runbook/scripts, B seed command. Acceptance: staging clone has tested `migrate`, media stage, seed dry-run/apply, restore of published revision, frontend flag rollback, and verified backup recovery path. Verify: record commands, checksums, timings, and pass/fail evidence. +- [ ] **T38 — Rehearse migration, backup, and rollback (M; deps: T13, T37).** Files: D runbook/scripts, B content initialization. Acceptance: staging clone has tested `migrate`, media stage, safe content initialization, frontend flag rollback, and verified backup recovery path. Verify: record commands, checksums, timings, and pass/fail evidence. - [ ] **Checkpoint M (deps: T37–T38).** Owner approves release checklist; production remains untouched until gate passes. -- [ ] **T39 — Production CMS seed and phased cutover (M; deps: T38).** Files: D runbook/observability, production state. Acceptance: verified fresh backup, additive backend migration, approved assets/drafts, publisher approval, flagged frontend release, and smoke checks occur in order. Verify: compare public text/SEO to approved manifest; check health, API errors, media, auth, registration/payment signals. +- [ ] **T39 — Production CMS initialization and phased cutover (M; deps: T38).** Files: D runbook/observability, production state. Acceptance: verified fresh backup, safe backend migration, approved current content/assets, flagged frontend release, and smoke checks occur in order. Verify: compare public text/SEO to reviewed starting values; check health, API errors, media, auth, registration/payment signals. - [ ] **T40 — Observe and close release (S; deps: T39).** Files: D release notes/incident log. Acceptance: defined observation window ends without unresolved critical defect; known issues and next-phase messaging/business-rule requests are recorded. Verify: owner signs off live mobile/desktop journeys and rollback readiness.