# Sections A page is built from its kind's plan; a deal changes the parts a template would fix. Every id has a recipe in `sections-library.md`. The kind and what it may carry: `SKILL.md` sections 1 to 3 and `effects-usage.md`. Heights and edges: `layout-v4.md`. ## 1. Plan in screens Write the plan before building: line 1 the kind, line 2 the deal, then one line per section: its id, its one idea, its picture, its screens (1 or 2, from the content height: `layout-v4.md` section 2) and, on tech, the section that holds the effect, the scene or a moment. - **Every section shows the real thing:** a photograph, a portrait, real icons, the client's UI, a diagram card or (tech only) the effect. A section without a picture is allowed only for a price list, an FAQ, a specs table, a booking form or a dealt statement moment's own section, once each, and two picture-less sections are never neighbours (the short page with no photograph, its statement hero, its statement moment and its one section, is the one exception, section 4). A quote needs a face or merges into the section above. The picture takes a real share: half a tile or more, 50/50 in a split, a whole screen as a layer. The close is its own picture (a photograph, the big button or the name set wide). - **One object never carries the page** (in testing: a robot arm in six sections and a game's salvage rig in six, each "one object six times", both capped at 4 to 4.5). The object shown whole (the product's photograph, a game's key art) leads the hero and **at most two more sections**; every other picture section is carried by another kind of visual the brief supports, from its row below, no kind more than twice. A new angle, a recolour or a crop of the whole is the object again; a use photograph counts as use only when its setting fills the frame (the bench, the street, the room, half the picture or more; the object one thing in it). Write each plan line's kind; three object lines at most. | Kind | the object whole: hero + 2 | carries the other sections | |---|---|---| | Software | the `app-frame` | UI fragments of its subject on cards, a diagram card, real tool icons, a type moment, a named quote with its face, the effect or scene | | Gaming | the client's key art (none: the setting's photograph under the game's name) | the world (in-engine shots, else photographs of its setting), the crew at work (the client's screenshots), the trailer frame, the screenshot strip, a type moment, the real platform marks | | Tech hardware | the product (photograph, the client's CAD render; a render only when the brief asks for 3D) | its use (the device at a bench or in its place), parts close up, the motion video frame, a diagram card held still, a type moment (one figure set large), a context photograph of the trade (a workshop, a lab) | | Product | the product (photograph; a render only when the brief asks for 3D) | its use (loaded, carried, at home), people with it, close-ups of its parts, a diagram card held still, a type moment, a context photograph of where it lives | - **The client's own assets get designed slots.** When the brief says the client has a trailer, key art, in-engine screenshots, CAD renders, an exploded model or a motion video, each gets a slot that reads finished now: the frame at the file's final ratio, holding a stand-in photograph (a kept live-search frame of the game's setting or of the product's kind in use, `photos.md`; a kit render still only when the brief asks for 3D), named in a comment for the client's file, never an empty, grey or broken frame and never a line saying the file is missing. The slots (`sections-library.md`, client-slots): the **trailer or motion video frame** (a real `