Files
guilan-ace-deployment/tasks/todo.md

18 KiB
Raw Blame History

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 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 has not started.

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 in bundle0-review.md on 2026-09-26; uncertain claims remain excluded from the initial seed.
  • 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 in bundle0-review.md on 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)

  • 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.
  • 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.
  • 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.

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.
  • 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.
  • 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.

3. Authentication (5–7 person-days)

  • T20 — Simplify auth entry and navigation (M; deps: T15, T02). Files: F Auth view/auth shell/tests. Acceptance: login/signup choice, intent, next step, and back path are clear on phone/desktop without changing backend auth rules. Verify: first-time student and returning-user walkthroughs.
  • 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. Verify: keyboard, slow-network, invalid-input, and duplicate-submit tests.
  • Checkpoint I (deps: T20–T21). Core login/signup behavior unchanged and clear in RTL/mobile.
  • T22 — Align recovery and verification screens (M; deps: T20). Files: F reset/verify/callback views/tests. Acceptance: expired token, failed Google callback, success, and return-to-intent states follow same system; no dead end. 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: login, signup, verification, reset, logout, and protected redirect pass with existing API semantics. Verify: full 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; editorial page intro/SEO reads the published CMS record. Verify: fixture-based state matrix at phone/desktop widths and a CMS publish 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; 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.
  • 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.
  • 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 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.
  • 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.
  • 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.