21 KiB
Redesign and CMS implementation checklist
This is an implementation backlog, with work-in-progress noted below and checkboxes reserved for accepted work. See 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, baseline, local journey replay, product/asset review, CMS/API contract, backend API schema, and the approved Home/About visual direction linked from frontend DESIGN.md. The owner approved the Home and About direction on 2026-09-25, then approved the Bundle 0 review 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, which supersedes the earlier draft/publish contract.
0. Discovery and design contract (4–5 person-days)
- T01 — Classify static public content (M; deps: none). Files: F
src/views/*,src/components/Navbar.tsx,Footer.tsx,src/app/*. Acceptance: every public route/string/image/SEO field is mapped to CMS editorial, existing domain data, or code-owned functional UI; conflicts and asset ownership are flagged. Verify: owner reviews the manifest against live desktop/mobile pages. Owner accepted the content boundary and exclusions inbundle0-review.mdon 2026-09-26. The unchanged0005migration retains legacy About affiliations and years; the mock-content command replaces that copy on untouched records before CMS rendering. - T02 — Capture flow and performance baseline (M; deps: none). Files: D
tasks/evidence, F test artifacts. Acceptance: route/state map covers auth, event registration/payment, blog, and staff admin; screenshots and bundle/accessibility baselines have dated device widths. Verify: manually replay each existing happy path and one failure path on staging/local. Owner accepted the recorded local baseline on 2026-09-26 with the historical test run and unexercised external paths documented; the current pytest suites passed on 2026-09-26 (see rerun record). - Checkpoint A (deps: T01–T02). Content categories, current behavior, and baseline evidence reviewed; no business-rule changes inferred. Accepted 2026-09-26 with the limits documented in
bundle0-review.md. - T03 — Review product truth and assets (S; deps: T01). Files: F
PRODUCT.md, asset inventory. Acceptance: initial product record is checked against source assets and owner input; logo sources are cataloged; conflicting contacts/statistics remain pending rather than guessed. Verify: owner signs off facts and supplies approved contact channels before production seed publication. Concept-scope sign-off: owner confirmed repository facts/assets and chose About-page contacts; claim-to-entity mapping remains a T12 seed gate. - T04 — Settle Home/About visual direction (M; deps: T03). Files: F
DESIGN.md, D static design artifacts. Acceptance: owner reviews the logo-led Home/About comps at phone and desktop widths using real approved assets; Home follows intro → featured events → featured blog posts → CTA → footer, and the component system maps to Shadcn/ui and Lucide. Verify: compare with current captures, owner references, product truth, accessibility needs, and real content lengths. Owner approved the Home and About design direction on 2026-09-25; final content, responsive behavior, and accessibility remain implementation checks. - T05 — Approve design and CMS/API contract (M; deps: T04, T01). Files: F
DESIGN.md, D architecture note, B API schema draft. Acceptance: owner accepts the logo-led direction and fixed Home content order; section types, field constraints, payloads, cache/preview behavior, and edit/publish roles are signed off. Verify: walk a draft→preview→publish→restore sequence and 320px/desktop layouts on paper. Design direction accepted 2026-09-25; owner approved the CMS/API decisions and documented paper walkthrough inbundle0-review.mdon 2026-09-26. - Checkpoint B (deps: T03–T05). Approved content contract and design direction recorded on 2026-09-26. This closes the discovery gate; later implementation and release gates still apply.
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. The old T08–T09 draft/publish workflow was rejected. The direct-save Unfold admin was reviewed and approved by the owner on 2026-09-27; the old Checkpoint D review is superseded. The current-content API and Checkpoint E were approved on 2026-09-27. Follow the course correction plan; the seeded About content review is documented in Checkpoint F review.
- 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 checkon a test database. - 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.
- Checkpoint C (deps: T06–T07). Schema and validation reviewed before permissions/API work. Approved by the owner on 2026-09-27.
- T08 — Audit current CMS data and permissions (S; deps: T06–T07). Completed against the owner-authorized local development PostgreSQL database on 2026-09-27; see database audit. Content migrations
0001–0005are applied; the five current page/site records exist, with no media references. Home has two admin changes; the other content records do not. One staff account exists and is the only superuser; the legacy editor/publisher groups have no members and no users have direct content permissions. The old revision tables contain no rows. Staging was not needed or accessed; production permissions remain a release-gate audit. - 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. Verified: backend suite passed 248 tests; Django and migration checks passed; owner reviewed and approved the Unfold admin on 2026-09-27. The development database audit is complete; production access remains a release gate.
- Checkpoint D (deps: T09). Owner approved the direct-save Unfold forms and permissions on 2026-09-27. The old draft/publish review is superseded.
- T10 — Expose current-content read API (M; deps: T09). Files: B content Ninja router/schemas/tests,
config/api.py; contract: backend content API v1 note. Acceptance: shared site record and four fixed pages expose current content and SEO, with explicit missing/unknown behavior and no revision/status/preview fields. Verified: anonymous read, save-then-read, missing content, and cache behavior; backend suite passed 255 tests and Django checks passed. Owner approved the API checkpoint on 2026-09-27. - Checkpoint E (deps: T10). The current-content API shape was checked and approved by the owner on 2026-09-27. No private preview API is planned.
- T12 — Review starting content and media (M; deps: T01, T09). Files: D source review, B initial content data. Owner reviewed the source content and approved blank CMS image fields, then directed that mock copy be used until staff save content. No current-site claims or media are in the mock content.
- T13 — Initialize fixed content records safely (S; deps: T12). Files: B management command/tests; do not change existing migrations. Implemented as
python manage.py seed_mock_content, with--dry-runand--databaseoptions. Three focused command tests passed. On the owner-authorized development database, the dry run proposed four untouched records and skipped Home because of two admin changes; execution updated Site, About, Events, and Blog, preserved Home, and created six mock About items. See database audit. No migration was changed. - Checkpoint F (deps: T12–T13). Owner reviewed and approved the mock starting content and blank optional image fields; the development database seed result is recorded in database audit.
- T14 — Add frontend CMS adapter and cutover flag (M; deps: T10). Files: F
src/lib/content-cms.ts,.env.sample. Acceptance: current content can be fetched server-side with typed mock fallback; blank CMS fields and request failures use mock copy; the flag defaults off;no-storefetches expose the latest admin save. The adapter returns mock values rather than caller-provided legacy copy. Frontend lint and production build passed; pages remain on legacy rendering until later tasks connect them.
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. Implementation reviewed and approved by the owner at Checkpoint G on 2026-09-28.
- 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. Home was reviewed and approved by the owner at Checkpoint G on 2026-09-28; frontend lint and production build passed.
- Checkpoint G (deps: T15–T16). Owner approved the Home design and content at target widths on 2026-09-28. T17 can proceed.
- T17 — Build CMS-driven About sections (M; deps: T15). Files: F About view, section components, tests. Acceptance: owner-approved About identity, purpose, member-year archive, selected event highlights, separate memories gallery, and general history timeline come from current CMS records; unsupported claims are absent. The development frontend now reads the CMS API, with mock values filling empty fields; the admin Save-to-public change remains for owner review at Checkpoint H.
- 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. SSR checks passed for Home, About, Events, Blog, event details, and post details; filtered listings are noindex with their base page as canonical.
- 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. Added the shared skip link, semantic main landmarks for listing routes, labeled search controls, and valid ordered-list markup; global focus and reduced-motion rules remain active. Owner visual/keyboard review is part of Checkpoint H because the in-app browser connection could not be established.
- Checkpoint H (deps: T17–T19). Owner approved Home/About on the CMS-enabled development frontend, including keyboard/focus and mobile review, on 2026-09-28.
3. Authentication (5–7 person-days)
- T20 — Simplify auth entry and navigation (M; deps: T15, T02). Files: F Auth view/auth shell/tests. Acceptance: mobile entry automatically routes password accounts to password entry, passwordless existing accounts to login OTP, and new numbers to registration OTP then details, with a clear way to edit the phone and no backend auth-rule changes. Implemented this single phone-first path and removed the separate login/signup selector.
- T21 — Clarify form, OTP, loading, and error states (M; deps: T20). Files: F auth components/tests. Acceptance: each step has one clear action, input constraints and errors are accessible, resend/countdown are understandable, and retry does not lose valid input. Added inline announced errors, field autocomplete/constraints, an accessible OTP label, cooldown display, duplicate-submit protection, and automatic sign-in after successful registration. Removed forgotten-password UI because OTP login covers account access, improved dark-mode error contrast, and standardized outline/toggle/nav hovers on the theme's secondary color. Frontend lint/build pass.
- Checkpoint I (deps: T20–T21). Owner reviewed and approved the phone → password/OTP → registration details flow, dark-mode errors, and button hover colors in RTL/mobile on 2026-09-28; backend auth rules remain unchanged.
- T22 — Align verification and OAuth callback screens (M; deps: T20). Files: F verification/callback views/tests. Acceptance: expired token, failed Google callback, success, and return-to-intent states follow the same system; forgotten-password recovery stays removed in favor of OTP login. Verify: browser tests for link/token variants.
- T23 — Auth regression gate (M; deps: T21–T22). Files: F end-to-end tests, B focused auth tests if needed. Acceptance: password login, OTP login, signup, verification, logout, protected redirects, and the retired recovery URL behave with existing API semantics. Verify: focused automated suite plus manual mobile smoke.
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; 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.
- T27 — Clarify free, paid, and callback outcomes (M; deps: T26). Files: F success/payment views/tests. Acceptance: pending, success, failure, canceled, and already-registered states show accurate next steps and do not imply payment when unconfirmed. Verify: callback replay and browser state tests against existing backend responses.
- T28 — Event regression gate (M; deps: T26–T27). Files: F end-to-end tests, B existing event/payment tests. Acceptance: registration, capacity, payment, cancellation, eligibility, and notification-trigger semantics remain identical to baseline. Verify: automated state matrix and staging test event with no real charge/message side effect.
- Checkpoint K (deps: T26–T28). Owner signs off registration/payment flow before broader release.
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; 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, 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.
- T35 — Expose roles and failure states clearly (M; deps: T34). Files: F admin auth/empty/error components/tests. Acceptance: permission denial, save conflict, loading, empty, and server error states explain next action without exposing unauthorized actions. Verify: role matrix and forced-failure browser tests.
- T36 — Admin regression gate (M; deps: T34–T35). Files: F admin browser tests, B permission tests if affected. Acceptance: event, user, blog, and metadata management still work for authorized users across target widths. Verify: staff UAT plus automated smoke.
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 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 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.