# Content Editor Page
 
 ## Purpose
 Display a single content record with full details for review/read-only inspection. Acts as the per-record viewer for content generated or managed by the Writer module.
 
 ## Code Locations (exact paths)
 - Page: `frontend/src/pages/Writer/ContentView.tsx`
 - Template: `frontend/src/templates/ContentViewTemplate` (renders the actual layout/content fields)
 - API: `frontend/src/services/api` (`fetchContentById`)
 
 ## High-Level Responsibilities
 - Fetch a specific content item by id from route param and render it via `ContentViewTemplate`.
 - Validate id parameter, handle not-found/error states, and provide back navigation to content list.
 
 ## Detailed Behavior
 - Route: `/writer/content/:id`.
 - On mount: validates `id` is numeric; on invalid, shows toast and redirects to `/writer/content`.
 - Fetches content via `fetchContentById(contentId)`; sets `content` state and clears `loading`.
 - Errors: shows toast (`Failed to load content`) and leaves `content` null.
 - Back action: `onBack` navigates to `/writer/content`.
 - Page metadata: sets document title/description via `PageMeta`.
 
 ## Data Structures / Models Involved (no code)
 - Content DTO from writer API (includes title, body/html, status, external_url, etc.; structure defined server-side).
 
 ## Execution Flow
 - `useEffect` → validate id → fetch content → update state → render template.
 - Template receives `{ content, loading, onBack }`.
 
 ## Cross-Module Interactions
 - Navigation back to writer drafts list; no direct cross-module calls.
 
 ## State Transitions
 - `loading` toggles during fetch; `content` set on success; invalid id triggers navigation away.
 
 ## Error Handling
 - Toast errors for missing/invalid id or fetch failure; console logs errors.
 
 ## Tenancy Rules
 - Backend enforces account/site/sector scoping; client only supplies id from route.
 
 ## Billing Rules (if applicable)
 - None within this view; generation/updates handled elsewhere.
 
 ## Background Tasks / Schedulers (if applicable)
 - None.
 
 ## Key Design Considerations
 - Strict id validation avoids bad requests.
 - Keeps view read-only; editing handled elsewhere (not in this component).
 
 ## How Developers Should Work With This Module
 - If adding inline editing, extend `ContentViewTemplate` and add PATCH/PUT calls; keep id validation and error handling intact.