How Website Management Works

The managed website keeps writing and publishing as two separate jobs. Each project owns its public words, page titles, ordering, and decision to make a source eligible. The shared Website service owns the common presentation, centrally assigns an accessible reusable palette, and controls the process that can place approved material on the live site. Every page identifies its owner and leaves stable spaces for the shared menu, feedback control, and footer.

Authors work in ordinary project notes, including Obsidian properties where a supported choice belongs in a note. A project can build an isolated local preview and inspect exactly what its approved sources would produce. That preview is evidence for review; it does not quietly update the public website while nobody is looking.

For a full-site update, the Website service composes the accepted owner packages for all registered public projects. A selected owner answers the exact package request; an unchanged owner can reuse its last accepted package. Website checks that every route has one owner, required pages are complete, project material remains separated, and the proposed additions, replacements, and removals are visible in a reviewable change list. It also builds one small public registry for the current menus, palettes, and non-secret feedback paths. A shared-menu change can then replace that registry instead of needlessly uploading every unchanged article. A problem stops the process instead of being promoted to an exciting production mystery.

Projects may request publication, but they do not receive publishing credentials or direct control of the remote site. Website owns the final safety checks, complete-site publication, and verification. A failed preflight or composition gate does not advance publication state. If transport has begun, the remote site may have changed partially; cursors remain unchanged until verification and reconciliation complete. Website must not describe that situation as transactional rollback.

A source marked for public export is therefore *eligible for publication*, not proof that it is already live. It becomes public only after the current packages are rebuilt, composed, reviewed, approved under the publication rules, uploaded, and verified.

The shared navigation may also show a small site-update label, such as `Site update 12 · 9 Sep 2026`. It is derived from the latest accepted Website package sequence and timestamp, not from a project note or a new publication command. A true cursor-zero baseline has no label, and invalid or mismatched package metadata fails closed instead of displaying a guess.

Security checks depend on what a site actually does. A static managed page has no login, session, or file-upload control to assess, so those controls are recorded as NotApplicable rather than being invented. Authenticated applications need evidence for their identity provider (for example, Google OIDC), upload handling, session boundaries, and other applicable controls, plus a bounded credential-free external assessment when the evidence ceiling allows it. Universal checks still cover the complete composed artifact, including internal references and restrictive static CSP on generated redirects, before any remote mutation. These checks inform an owner; they do not grant publication, deployment, or remote-command authority.

When a site also becomes an application, keep the public and private surfaces deliberately separate. The URL-mapped public document root is an explicit allowlist of pages and assets; secrets, configuration, sessions, logs, uploads, and backups stay outside it and are opened only through an authorized server-side path. A web-server access file such as .htaccess can add defense in depth, but it is not the main boundary. For private data, the server derives the signed-in person and owner scope from its session, ignores client-supplied owner or role selectors, checks every object and operation on every request, and gives unknown and foreign objects the same bounded not-found response.

Those checks are practical, not ceremonial. Relationships carry the owner-space key so a child record cannot attach to another owner's parent. A release review uses two isolated users or owner spaces and attempts reads, lists, searches, updates, deletes, nested attachments, downloads, exports, jobs, and administrative variants while changing each client-controlled selector. The evidence must show that foreign objects were not revealed or changed. These application checks remain the application's responsibility; Website can require their evidence and run bounded live checks, but it does not become the application's administrator.

Compatibility horizons and requested packages

An active task records a Workbench horizon for policy and evidence. A compatible release does not by itself restart that task, but this record is not a retained copy of old executable files: a new process, module import, or shared command reads current files and crosses the adoption boundary. Paused work checks its assumptions again before it resumes, and only a release explicitly judged stop-required interrupts work immediately.

Website packages are likewise demand-driven. A project builds and seals one owner-scoped package only for a specific Website request. That package is an immutable review artifact, not a publication command; later source edits belong to a later request. The shared Website still composes the complete eligible site and remains the only publication authority.

For example, if a project changes two public pages, one request produces one preview and one sealed snapshot containing both. Website can review that snapshot with the other projects' current packages; editing a third page afterward does not sneak into the sealed package, and sealing it does not publish anything by itself.

If a later correction changes only shared generated output, Website may reuse the immutable owner packages whose source content is unchanged while rebuilding and checking the complete site. That shortcut does not bypass disclosure, route, CSP, reference, deletion, drift, or live-verification gates.