System Requirements Document for windy-mere

1. Introduction

Captik is a public content website with a private, owner-facing editing room behind it. The site owner wants Captik to reproduce the feel and layout of a reference website they have chosen to copy: the published site must read as a deliberately authored, designed object rather than a default template, and the owner must be able to shape its content and structure to mirror that reference. Visitors arrive anonymously, read the site's content, and move through its sections; the owner signs up, signs in, and edits what visitors see.

This document is the System Requirements Document for the product named Captik, delivered under the project name windy-mere. It defines the two-sided product — a public reading surface and a private editing surface — together with the identity boundary that separates them, the visual language the site is built in, and the technical delivery shape.

Audience. Anonymous Site Visitors who read Captik's published content, and the Site Owner / Content Editor who owns the site, publishes into it, and is the only human actor behind the login.

2. System Overview

Captik is delivered as a single web application with three runnable services:

• frontend — a React application serving every human-facing surface: the public Landing page, the public Content pages, the Sign Up and Login identity surfaces, and the protected Site Editor.
• backend — a shared FastAPI process that owns all application APIs and domain modules: identity and session handling for the site owner, published content and structure reads for visitors, and content/structure writes from the Site Editor.
• database — MariaDB holding application-owned persistent data: the site owner's identity record, session state, and the published content and structure of the Captik site.

Actors.

• Site Visitor (human, anonymous) — lands on Captik, reads its content, navigates its pages.
• Site Owner / Content Editor (human, application identity) — enrolls, verifies on return, and edits Captik's content and structure so the published site mirrors the reference site's feel and layout.

Accepted behavior in summary. A public Landing page introduces Captik and its content. Public Content pages let visitors browse and read the site. The owner completes self-service enrollment on Sign Up, verifies identity on return through Login, and works in the protected Site Editor to shape the content and structure that visitors then see. The visual language is a Paula Scher–derived poster system: type as architecture, flat colour blocks, hard edges, no gradients or soft cards.

Narrow exclusions. Captik is not a multi-tenant site builder, not a marketplace of templates, and not a collaboration tool. There is one site (Captik) and one owner-editor role; no differentiated permissions, no team roles, no invitation or provisioning flow, and no visitor accounts are part of the current product. No page or section presents or links to a planning document.

Removed from scope

• Multi-tenant site hosting for third-party sites (also: multi-site builder, tenant provisioning)
• Template marketplace or theme gallery
• Team collaboration, reviewer roles, and role-based permissions
• Visitor accounts, comments, or social features
• Invitation-based or admin-provisioned owner onboarding

2a. Product Interpretation and Delivery Boundary

Captik is a first-party application. Both the public reading surface and the private editing surface are owned and rendered by the Captik frontend, backed by the shared Captik backend and its MariaDB store. Nothing about the public site or the editor is delegated to a third-party provider surface.

Access ownership. The public surfaces — Landing and Content — are anonymously reachable with no identity required. The Site Editor is protected and requires the owner to be signed in. Because the owner must privately own and resume durable, actor-specific editing state across visits, Captik establishes application-owned identity: first use happens through self-service enrollment on Sign Up, and returning access happens through verification on Login. Sign Up and Login are themselves anonymously reachable entry surfaces — a protected destination cannot own the interaction that grants access to itself. No invitation, provisioning, or deployment-bootstrap path is established by the source, so self-service enrollment is the sole first-use route.

Current versus future. Everything in this document is current. There is no accepted future horizon for additional capabilities; anything not stated here is out of scope rather than deferred.

2c. Page Content and Component Coverage

Landing

• Purpose and access. Anonymous public entry surface. Explains what Captik is and introduces its content before visitors move into its sections.
• Information and state. The Captik wordmark set as a full-viewport poster composition; a single plain-language line describing the site ("A site you publish, and a room behind it where you edit it"); a ticker band of the site's own section names; entry points into Content and into the owner's identity surfaces.
• Primary actions. Enter the site's content; navigate to a section; reach Sign Up or Login as the owner.
• Supporting actions. Navigate via the horizontal uppercase label bar with a solid vermilion active underline.
• Domain entities. Published site identity (site name, section names used by the ticker and navigation).
• Component responsibilities. Hero type composition (three stacked Anton lines, middle line reversed out of a vermilion block bleeding off the right edge); ticker band (yellow field, ink uppercase Archivo, marquee); navigation bar; section-entry blocks.
• States. Loading: hero type renders immediately from static site identity; ticker populates from the section list. Empty: if no sections are published yet, the ticker shows the site name alone and the content entry point remains present. Success: visitor proceeds into Content. Error: if site identity fails to load, the wordmark and the plain-language line still render from static copy and navigation degrades to the site name. Recovery: retry on next navigation.

Content

• Purpose and access. Anonymous public destination where visitors browse Captik's pages and read its content.
• Information and state. The published pages and their content, presented as a three-column editorial spread (kicker / headline / deck) with colour blocks bleeding off the right edge; section heads on a 2px ink rule with a 12px uppercase label and an outlined-stroke numeral at the far right; content thumbnails as large flat colour fields carrying a single oversized letter or numeral.
• Primary actions. Select a page or section; read its content; move to another page.
• Supporting actions. Navigate via the horizontal label bar; hover a content card to flip its colour field from paper to vermilion and invert its type.
• Domain entities. Page (title, section, body content, ordering, thumbnail letter/numeral), Section (name, ordering).
• Component responsibilities. Page list / index; editorial spread renderer; section head with rule and numeral; content card with hover colour flip; navigation bar.
• States. Loading: section heads and card frames render first, body content fills in. Empty: when no pages are published, the Content surface shows the site name and a plain statement that nothing has been published yet, with navigation back to Landing. Success: page content renders in full. Error: a page that fails to load shows its title and a retry control in place of the body. Recovery: retry reloads that page without leaving Content.

Login

• Purpose and access. Anonymous identity-access surface for the returning Site Owner / Content Editor.
• Information and state. Credential entry for the owner's existing Captik identity; a link across to Sign Up for first use.
• Primary actions. Submit credentials to verify identity and open the Site Editor.
• Supporting actions. Move to Sign Up; return to Landing.
• Domain entities. Owner identity (email, credential), session.
• Component responsibilities. Credential form with rectangular 2px-bordered controls; inline validation messaging; submit control.
• States. Loading: submit control shows a pending state and is not re-submittable. Empty: fields start blank with labels visible. Success: session established and the owner is taken to the Site Editor. Error: invalid credentials show an inline message and preserve the entered email; the owner may retry. Recovery: repeated failure keeps the form usable and offers the Sign Up link.

Sign Up

• Purpose and access. Anonymous self-service first-use enrollment for the Site Owner / Content Editor, who independently begins editing Captik with no invitation or provisioning boundary.
• Information and state. Enrollment fields establishing the owner's Captik identity; a link across to Login for an existing identity.
• Primary actions. Submit enrollment to create the owner identity and open the Site Editor.
• Supporting actions. Move to Login; return to Landing.
• Domain entities. Owner identity (email, credential), session.
• Component responsibilities. Enrollment form with rectangular 2px-bordered controls; inline validation messaging; submit control.
• States. Loading: submit control shows a pending state and is not re-submittable. Empty: fields start blank with labels visible. Success: identity created, session established, owner taken to the Site Editor. Error: an already-enrolled email or invalid input shows an inline message with a route to Login; the form stays usable. Recovery: the owner corrects input and resubmits, or switches to Login.

Site Editor

• Purpose and access. Protected owner-facing destination for shaping Captik's content and structure to mirror the reference site's feel and layout. Requires a signed-in owner; unauthenticated access routes to Login.
• Information and state. An ink-grey chrome frame around a pure white paper canvas; a left rail of block labels in uppercase Archivo with a hard 2px rule between rail and canvas; the current published content and structure of the Captik site; the owner's in-progress edits.
• Primary actions. Select a page or section to edit; change its content; change its structure and ordering; publish the result so visitors see it.
• Supporting actions. Add a page or section; reorder; discard unsaved changes; sign out.
• Domain entities. Page, Section, published content version, owner identity, session.
• Component responsibilities. Block-label rail; white canvas editor; content and structure controls; publish control; unsaved-changes indicator; sign-out control.
• States. Loading: chrome and rail render, canvas shows a pending state until content resolves. Empty: with no pages yet, the canvas offers the first page/section creation control. Success: a publish confirms and the published site reflects the change. Error: a failed save or publish shows an inline message and retains the owner's edits in the canvas. Recovery: retry the save or publish; unsaved edits survive the failure. Unauthenticated: redirect to Login, returning to the Site Editor after verification.

3. Functional Requirements

FR-1 — Public site identity. As a Site Visitor, I should see the site presented as Captik, so that I know what site I am on. (explicit)

• Trigger: any visit to a public surface. Observable result: the Captik name is present in the wordmark and navigation. Access: anonymous. Failure: if site identity fails to load, static Captik copy still renders. Continuation: navigation remains available.

FR-2 — Reference-faithful look and layout. As a Site Owner / Content Editor, I should be able to shape Captik's content and structure so the published site mirrors the feel and layout of the reference website I chose to copy, so that the site reads as a deliberately authored design rather than a default theme. (explicit)

• Trigger: the owner edits content and structure in the Site Editor and publishes. Observable result: the public Landing and Content surfaces present the owner's content and structure in the poster visual language defined in Sections 6–8. Access: signed-in owner. Failure: a failed publish leaves the previously published site intact and the owner's edits retained. Continuation: the owner retries or continues editing.

FR-3 — Self-service enrollment. As a Site Owner / Content Editor, I should be able to enroll myself on first use before editing Captik's content, so that I can begin editing without an invitation or provisioning step. (required_inference)

• Trigger: the owner opens Sign Up. Input: enrollment fields establishing their Captik identity. Observable result: an owner identity exists and a session is established. Access: anonymous entry. Failure: an already-enrolled email or invalid input shows an inline message with a route to Login. Continuation: the owner is taken to the Site Editor on success, or to Login on conflict.

FR-4 — Returning verification. As a Site Owner / Content Editor, I should verify my identity on return before accessing the Site Editor, so that my editing state stays private to me. (required_inference)

• Trigger: the owner opens Login, or attempts the Site Editor while unauthenticated. Input: credentials. Observable result: a session is established and the Site Editor opens. Access: anonymous entry to Login; protected Site Editor. Failure: invalid credentials show an inline message and preserve the entered email. Continuation: retry, or switch to Sign Up.

FR-5 — Browse and read published content. As a Site Visitor, I should browse Captik's pages and read its content, so that I can find what I need without friction. (required_inference)

• Trigger: the visitor enters Content from Landing or navigation. Observable result: published pages render as editorial spreads with section heads and content cards. Access: anonymous. Failure: a page that fails to load shows its title and a retry control. Continuation: the visitor retries or selects another page.

FR-6 — Navigate the site's sections. As a Site Visitor, I should move through Captik's sections via the horizontal label bar and the ticker band, so that I can reach any part of the site. (required_inference)

• Trigger: the visitor selects a label or a ticker item. Observable result: the corresponding section or page opens; the active label shows a solid vermilion underline. Access: anonymous. Failure: an unavailable section is omitted from the bar and ticker. Continuation: the visitor selects another section.

FR-7 — Edit content and structure. As a Site Owner / Content Editor, I should select a page or section in the Site Editor and change its content, structure, and ordering, so that the published site matches my intent. (required_inference)

• Trigger: the signed-in owner selects a block in the rail and edits it on the white canvas. Observable result: the edit is held in the canvas with an unsaved-changes indicator. Access: signed-in owner. Failure: a failed save shows an inline message and retains the edits. Continuation: retry the save, or discard and continue.

FR-8 — Publish to visitors. As a Site Owner / Content Editor, I should publish my edits, so that Site Visitors see the updated site. (required_inference)

• Trigger: the owner activates publish. Observable result: the published site reflects the change and a confirmation is shown. Access: signed-in owner. Failure: a failed publish leaves the previous published state intact and retains the edits. Continuation: retry publish.

FR-9 — Protected editor access. As the system, I should require a verified owner session for the Site Editor, so that only the owner reaches the editing room. (required_inference)

• Trigger: a request to the Site Editor without a valid session. Observable result: the request routes to Login and returns to the Site Editor after verification. Access: protected. Failure: an expired session routes to Login with the same return behavior. Continuation: the owner verifies and resumes.

FR-10 — Sign out. As a Site Owner / Content Editor, I should sign out of the Site Editor, so that the editing room is not left open on a shared device. (required_inference)

• Trigger: the owner activates sign out. Observable result: the session ends and the owner lands on a public surface. Access: signed-in owner. Failure: a failed sign-out shows an inline message and keeps the session visible as active. Continuation: retry sign out.

4. User Personas

Site Visitor

Product context. An anonymous reader who arrives at Captik without an account and without any prior relationship to the site. They encounter the Landing poster first and decide from it whether the site is worth reading.

Primary goal. Read Captik's content and move through its sections without friction.

Distinct responsibilities. The visitor is the audience the published site is judged by. Their work is selection and reading: choosing a section from the label bar or ticker, opening a page, and reading its editorial spread. They never edit, never enroll, and never see the Site Editor.

Inputs and decisions. Which section or page to open next; whether the Landing composition communicates what the site is.

Interactions with other participants. The visitor is the recipient of the owner's published work. They do not interact with the owner directly; the owner's publish action is what changes what the visitor sees.

Observable success. The visitor can read the site's content and navigate its pages without friction, and the site reads as a designed object rather than a template.

Site Owner / Content Editor

Product context. The single human who owns Captik and asked for it to mirror the look and layout of a reference site. They are the only actor behind the login and the only person who writes into the site.

Primary goal. Make the published site present the intended content and structure, in the reference site's feel and layout, to visitors.

Distinct responsibilities. Enrolling on first use; verifying identity on return; selecting pages and sections in the Site Editor; changing content, structure, and ordering; publishing so visitors see the result; signing out. The owner is also the person who judges whether the published result matches the reference.

Inputs and decisions. What content each page carries; how sections are ordered and named; when a draft is ready to publish; whether to discard unsaved changes.

Interactions with other participants. The owner's publish action is what the Site Visitor reads. The owner never sees individual visitors and has no per-visitor controls.

Observable success. The published site presents the intended content and structure to visitors, and the owner can return later, verify, and continue editing the same site.

5. Core User Flows

Flow A — A visitor arrives and reads Captik

1. The Site Visitor opens Captik and lands on Landing (anonymous).
2. The full-viewport poster renders: CAPTIK stacked in three Anton lines, the middle line reversed out of a vermilion block bleeding off the right edge, a single plain-language line beneath it, and the yellow ticker band of section names along the bottom.
3. The visitor reads the plain-language line and selects a section from the label bar or the ticker.
4. Content opens on that section. Section heads sit on a 2px ink rule with an outlined numeral at the far right; pages appear as editorial spreads with colour-field thumbnails.
5. The visitor hovers a content card; its colour field flips from paper to vermilion and its type inverts.
6. The visitor opens a page and reads it in full.
7. Failure/recovery: if a page fails to load, its title and a retry control appear in place of the body; the visitor retries or selects another page from the label bar.
8. Continuation: the visitor moves to another section, or returns to Landing. No identity is ever required.

Flow B — The owner enrolls on first use

1. The Site Owner / Content Editor opens Sign Up (anonymous).
2. The owner fills the enrollment fields establishing their Captik identity.
3. The owner submits. The submit control shows a pending state and cannot be re-submitted.
4. Success: the identity is created, a session is established, and the owner is taken to the Site Editor.
5. Failure/recovery: if the email is already enrolled or input is invalid, an inline message appears with a route to Login; the form stays usable and the owner either corrects the input or switches to Login.
6. Continuation: the owner begins editing in the Site Editor.

Flow C — The owner returns and verifies

1. The owner opens Login (anonymous), or attempts the Site Editor while unauthenticated and is routed to Login.
2. The owner enters credentials and submits; the control shows a pending state.
3. Success: a session is established and the Site Editor opens — including the return to the Site Editor when the owner was routed there from a protected attempt.
4. Failure/recovery: invalid credentials show an inline message and preserve the entered email; the owner retries or switches to Sign Up.
5. Continuation: the owner resumes editing.

Flow D — The owner edits and publishes

1. The signed-in owner is in the Site Editor: ink-grey chrome around a pure white canvas, a left rail of uppercase block labels, a hard 2px rule between rail and canvas.
2. The owner selects a page or section in the rail.
3. The owner changes its content, structure, or ordering on the canvas. An unsaved-changes indicator appears.
4. Failure/recovery: if a save fails, an inline message appears and the edits remain in the canvas; the owner retries the save or discards and continues.
5. The owner activates publish.
6. Success: a confirmation is shown and the published site reflects the change.
7. Failure/recovery: if publish fails, the previously published site stays intact and the edits are retained; the owner retries publish.
8. Continuation: the owner continues editing, or signs out.

Flow E — The owner signs out

1. The signed-in owner activates sign out in the Site Editor.
2. Success: the session ends and the owner lands on a public surface.
3. Failure/recovery: if sign-out fails, an inline message appears and the session remains visibly active; the owner retries.

Flow F — The visitor sees the owner's published change

1. After Flow D completes, the Site Visitor opens Landing or Content.
2. The published content and structure reflect the owner's latest publish, in the same poster visual language.
3. The visitor reads and navigates as in Flow A.

6. Visuals Colors and Theme

The visual language is Typography as architecture — Captik built out of words, colour blocks and poster energy, after the muse Paula Scher. The headline idea: the site is the poster, and the editor is the print desk behind it.

Colour tokens (light mode).

No gradients. No shadows on colour blocks — the contrast between flat fields is the effect.

Typography.

• Headings: Anton, all-caps, set enormous and stacked tight at line-height 0.88 and tracking -0.01em. Occasional single words rotated 90° or set in outlined stroke as a poster gesture — never on readable body copy or control labels.
• Body: Archivo Regular/Medium at 17–19px with 1.6 leading.
• Labels: Archivo uppercase at 12px with 0.14em tracking for section markers.
• Third voice: Archivo Black for pull-quotes and stat numerals.
• Scale (1.5 modular rhythm): display clamp(56px, 12vw, 176px); section head clamp(36px, 6vw, 88px); subhead 28/32; body 17–19; label 12. Mobile display never below 56px and always wraps to full words inside the viewport.

Shape language. Hard edges everywhere: zero border-radius, 2px and 3px ink rules, solid rectangles of colour butting against each other, diagonal bands cut at 8–12° across full-bleed sections, outlined type used as texture. No pills, no soft cards, no drop shadows. Controls are rectangles with a visible 2px border and a flat colour fill on hover.

Layout. Asymmetric poster grid on a 12-column base with a visible 2px baseline rule under each section head. Landing opens with a full-viewport type composition. Content pages use a three-column editorial spread (kicker / headline / deck) with colour blocks bleeding off the right edge. The Site Editor is a white canvas on ink-grey chrome with a left rail of uppercase Archivo block labels — the one place the layout goes quiet and functional. Navigation is a single horizontal bar of uppercase 12px labels with an active state shown as a solid vermilion underline spanning the full label width.

Imagery. Typography is the image. Where photography appears it is high-contrast, duotone-treated (ink + vermilion) cut-outs of hands, paper, printing plates and city signage, cropped hard to the grid edge. Content thumbnails are large flat colour fields carrying a single oversized letter or numeral. No stock people smiling at laptops, no illustration for its own sake.

Readability rule. Headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit, with no other element covering them. Imagery, decoration and motion may be cropped, bled, rotated or overlapped freely. Tickers and marquees may cross the viewport edge by design, provided every item becomes fully readable as it passes.

7. Signature Design Concept

The Captik poster wall. The public entry is a full-viewport poster, not a hero band. The word CAPTIK is set in Anton at clamp(56px, 13vw, 200px) and stacked across three lines that fill the width edge to edge. The middle line is reversed out of a solid vermilion #E0311E block that bleeds off the right edge at every breakpoint. Beneath it, flush-left, sits a single 19px Archivo line of plain talk — "A site you publish, and a room behind it where you edit it" — and one rectangular ink-bordered button. A thin ticker band of the site's own section names runs along the bottom of the viewport in yellow #F5C518 on ink.

The composition is type-first and asymmetric: no centred stack, no hero image, no gradient. The same poster logic carries into Content, where section heads sit on a full-column 2px ink rule with a 12px uppercase label and an outlined-stroke numeral at the far right, and content cards flip their entire colour field from paper to vermilion on hover instead of lifting or shadowing. The Site Editor deliberately breaks the poster register: an ink-grey chrome frame around a pure white paper canvas, block labels in uppercase Archivo, a hard 2px rule between rail and canvas — the tool looks like a print layout desk, not a dashboard.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject. The stacked CAPTIK wordmark, with its middle line reversed out of the vermilion block that bleeds off the right edge.
• Input → transformation → outcome thesis. On load, the three wordmark lines snap up 16px into place in staggered sequence with 60ms offsets; the vermilion block slides 100% across from the right edge to settle behind the middle line; the yellow ticker band then begins its linear marquee of the site's own section names. The outcome is the composed poster at rest, with the ticker still running.
• Motion vocabulary. Hard cuts and linear slides only. Staggered word reveals on section entry (each word snapping up 16px with 60ms offsets), a marquee ticker of the site's own section names along one band, and colour-block wipes that slide 100% across a section boundary on scroll. Hover on a content card flips its colour field from paper to vermilion and inverts the type. Nothing bounces.
• Composed first frame. The poster fully assembled: CAPTIK stacked edge to edge, middle line reversed out of vermilion, the plain-language line and ink-bordered button flush-left beneath, the yellow ticker band along the bottom of the viewport.
• Reduced-motion state. Under prefers-reduced-motion all reveals become instant and the ticker becomes a static wrapped row of section names, each fully readable.

9. Non-Functional Requirements

• NFR-1 — Readable text and controls at every viewport. (explicit, from creative direction) Headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit; no other element covers any part of them. Rationale: the poster composition is type-heavy and must remain legible at mobile widths.
• NFR-2 — Reduced-motion support. (explicit, from creative direction) Under prefers-reduced-motion, all reveals become instant and the ticker becomes a static wrapped row so every item can be brought fully into view. Rationale: expressive motion must not block access to content.
• NFR-3 — No gradients, glass, or soft cards. (explicit, from creative direction) No gradients, no glass panels, no rounded cards with hover-lift shadows, no Inter/Roboto/Poppins/system-ui, no soft pastel or low-contrast grey-on-grey palettes, and no rotated or outlined type on readable body copy or control labels. Rationale: the visual identity depends on flat fields and hard edges.
• NFR-4 — Protected editor. (required_inference) The Site Editor is reachable only with a verified owner session; unauthenticated requests route to Login and return to the Site Editor after verification. Rationale: the owner's editing state must remain private and resumable.
• NFR-5 — Published-site integrity on failure. (required_inference) A failed save or publish must leave the previously published site intact and retain the owner's edits. Rationale: visitors must never see a partially applied publish.
• NFR-6 — Single shared backend. (basic_default) All application APIs are served by the one FastAPI backend process; no additional service is introduced for the current product. Rationale: the provisioned inventory is authoritative and the current workflows do not require an independent worker or queue.

10. Tech Stack

• Frontend: React application UI, serving Landing, Content, Login, Sign Up, and the protected Site Editor.
• Backend: Python / FastAPI, a single shared process owning identity and session APIs, published content and structure reads, and Site Editor writes.
• Database: MariaDB for application-owned persistent data — owner identity, session state, and published content and structure.
• Orchestration: Docker / docker-compose with the three services (frontend, backend, database). Kubernetes is not required by the current deployment shape.

11. Assumptions and Constraints

• A-1. (required_inference) Captik is a single-site product with exactly one owner-editor role. No differentiated permissions, team roles, or role-based visibility exist.
• A-2. (required_inference) Application-owned identity is established through self-service enrollment on Sign Up; no invitation, provisioning, or deployment-bootstrap path is established by the source.
• A-3. (required_inference) Sign Up and Login are anonymously reachable; the Site Editor is protected. A protected destination does not own the interaction that grants access to itself.
• A-4. (explicit) The reference website's specific content is not supplied in the source; the owner supplies Captik's content and structure through the Site Editor, and the visual language in Sections 6–8 governs the feel and layout.
• A-5. (basic_default) No palette, font, or surface was specified by the user; the creative direction supplies the visual language, and the generic indigo/blue-on-white SaaS template is forbidden.
• A-6. (explicit) No page or section presents or links to a planning document.

12. Glossary

• Captik — The product and the name of the website it publishes.
• Site Visitor — An anonymous human who reads Captik's published content.
• Site Owner / Content Editor — The single human who owns Captik, enrolls, verifies on return, and edits and publishes its content and structure.
• Landing — The anonymous public entry surface presenting the Captik poster.
• Content — The anonymous public destination where visitors browse and read Captik's pages.
• Sign Up — The anonymous self-service enrollment surface for the owner's first use.
• Login — The anonymous returning-verification surface for the owner.
• Site Editor — The protected owner-facing destination for shaping Captik's content and structure.
• Block — A page or section unit selected in the Site Editor's left rail and edited on the white canvas.
• Publish — The owner's action that makes edited content and structure visible to Site Visitors.
• Ticker band — The yellow marquee of the site's own section names, pinned under the hero and reused as a section divider.
• Poster grid — The asymmetric 12-column layout with 2px ink rules and flat colour blocks that defines Captik's visual language.