--- title: Server Domain Owners - Plan type: refactor date: 2026-10-12 topic: server-domain-owners artifact_contract: ce-unified-plan/v1 product_contract_source: ce-brainstorm execution: code ---

Server Domain Owners - Plan

Goal Capsule

Objective: A later change to signing in, to a wall, or to an uploaded image has one obvious place to start, and people can still sign in, edit, share, and reopen a wall as they do today.

Means: Give the server a named owner for a sign-in session, a wall, and an upload.

Product authority: This plan covers the server only. Reshaping the browser, adding a new ability, and writing one shared wall definition for browser and server are not active scope.

Open blockers: None.

Product Contract

Summary

The server keeps today's behavior and gains one owner each for a sign-in session, a wall, and an upload. The screens stay as they are. Proof is the automated checks that already exercise signup, privacy, saving, images, and conflicting edits.

Problem Frame

The screens already treat a wall as separate things: a picture, a note, a folder, a playlist. The server handles sign-in, walls, and uploads inside one request function. The next server change has nowhere obvious to land, and a mistake in that function can break saving or sharing with nothing new for a person to see.

Key Decisions

• Reorganize the server and keep the product the same. (session-settled: user-directed — chosen over a new ability or one shared wall definition: the product already works, and the screens already use objects.) Governs R1, R2, R4.
• Do not add a sample feature to prove the structure. The existing checks are the proof. Governs R3.

flowchart LR
  request[Request] --> session[Sign-in session]
  request --> wall[Wall]
  request --> upload[Upload]

Requirements

• R1. A person can sign in, edit a wall, share it, upload an image, and reopen it with the same results as before this change.
• R2. The server has one owner for a sign-in session, one owner for a wall, and one owner for an upload. A later change to one of those jobs starts in that owner.
• R3. The automated checks of the HTTP API and the database pass with the same expectations they have today.
• R4. The browser screens and the wall objects they already use stay as they are.

Actors

• A1. A person with an account, who signs in and edits or shares a wall.
• A2. A visitor with a link, who can view a wall that is not private.
• A3. A later developer, who changes sign-in, a wall, or an upload and needs one place to start.

Scope Boundaries

• Putting the app on a public website, letting someone else edit a wall, and deleting an account.
• One definition of a valid wall shared by the browser and the server.
• A sample feature whose only job is to demonstrate the new structure.

Key flows are omitted. This work does not add or change a path a person follows.