Framework Basics

Workbench is the common framework that helps independent projects share reliable services without merging their decisions or private material. It provides common ways to register projects, coordinate work, validate changes, build local website packages, schedule shared resources, and reuse proven tooling.

Its working implementation and its documentation are deliberately separate. The implementation focuses on running correctly; this documentation project explains behavior currently used by our projects, guides people through it, records public development notes, and explores possible improvements.

Workbench remains an internal operating framework. A deliberately limited Customer Core can now be exercised as a local product preview, but it is not approved for public redistribution. We document both because we are proud of what Workbench helps us do and because its design lessons may be useful to other people.

When the working framework changes, its explanation must change too. When documentation develops an idea that needs new executable behavior, the proposal goes to the implementation owner for compatibility testing.

Public pages describe responsibilities, behavior, safety boundaries, and limitations. They do not expose credentials, private project content, runtime state, migration evidence, proprietary implementation details, or security-sensitive operations.

Workbench Documentation explains the internal framework used across Agnostic Projects. Workbench is not a software product waiting for public release; these pages exist because we are proud of the tool and want to share the useful thinking behind it.

A capability note describes a stable tool, script, service, or workflow in plain language. It normally explains the job it performs, when someone would use it, what information goes in and comes out, which safeguards matter, and a small example where that makes the idea easier to understand.

Notes remain private by default. A note is published only when its explanation is useful and safe without exposing credentials, private paths, security-sensitive operations, runtime state, proprietary mechanics, or another project's private material. We can show people the toolbox without also handing out the keys to the boiler room.

The project author also chooses glossary annotations one occurrence at a time. The Website displays and validates those deliberate definitions; it does not hunt through a paragraph for matching spellings. Ordinary words therefore stay ordinary, and a sentence about handling a failure does not suddenly lecture the reader about programming handles.

The executable Workbench remains the authority for what actually works. Documentation follows implemented behavior, labels proposals honestly, and changes when testing or experience proves an older explanation wrong.

Shared Workbench exists because independent projects keep needing the same unglamorous help. One project may need a safe check, another a database, and a third a page on the common website. Rebuilding those foundations separately wastes time and makes it harder to tell what was actually checked.

The shared services do the common jobs once. Projects still own their goals, words, data, prompts, decisions, and acceptance of results. A shared service is a helpful caretaker, not a new project manager with a suspiciously large clipboard.

The small jobs

• Coordination keeps bounded work visible: who is working, which shared resource is claimed, and whether a task finished. It records cooperation; it does not transfer authority.
• Validation checks stated rules and reports failures before they become somebody else's afternoon. It can reject incomplete structure, stale assumptions, or unsafe output, but the owner still decides what to accept.
• Website supplies the common presentation and composes approved project content into the public site. Projects write and approve their own pages; Website controls the shared shell and publication gates.
• Model broker places approved local-model jobs on the available machine resources. Projects choose the task meaning, sources, prompt, and acceptance checks; the broker handles queueing and placement. It does not silently send private work to the cloud.
• Database service provides a maintained PostgreSQL/PostGIS foundation when a project needs relational or map-shaped data. The project owns its schema, migrations, data meaning, and recovery acceptance; the service owns the common engine and platform safeguards.
• Account Services (ScaffoldOnly) defines a safe identity boundary: it can help establish who signed in, but it does not decide what a game, server, administrator, or payment flow may do. It is not a live account provider or endpoint, and account safety remains separate from communications safety.
• Backup and export helpers create reviewable copies and packages when an owner asks for them. A copy is evidence or a recovery aid, not permission to publish, transfer, or rewrite the original.

What a project experiences

Suppose a project wants to publish a map page. It writes the page, marks it eligible, and previews it locally. Website checks the assembled site. Validation reports whether the structure is sound. If the project also needs spatial data, Database supplies the shared engine while the project keeps its own tables and meaning. Nothing in that chain lets one project read another project's private notes or approve its work.

These services are shared infrastructure, not a promise that every optional service is active for every project. A project may use a service only when it has a real need and an explicit owner configuration. Planned ideas remain labelled as planned until the working owner releases and checks them.

When a new project or tool bundle arrives, Workbench first separates the general problem from the project-specific solution. A useful, proven mechanism may be promoted into shared Workbench or Shared Knowledge; a unique or immature helper stays with its project as a thin adapter, with the reason and evidence for reconsidering it recorded. For example, Tracker Archive is the public project name; its internal ID and folder are compatibility labels, while each provider format remains an adapter rather than a second project identity.

The Hosted Application Controller is currently a planning aid, not a remote administrator. It can describe a registered hosted target, perform a fixed read-only connection preflight with pinned identities, and prepare purpose-limited plans for runtime, migration, and backup access. The project still owns its schema, data, deployment, recovery evidence, and live acceptance. In this early Candidate release, it refuses to provision, deploy, migrate, restore, publish, run arbitrary remote commands, or expose secrets; a successful preflight is not permission to do any of those things.

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.

Workbench Night is a bounded review window for housekeeping, checks, and carefully scoped discovery. It is not a magic overnight operator that may invent jobs, install software, publish a website, or alter a project because everyone else has gone to bed.

Choose the scope

A Night plan makes the scope explicit:

• Due, one project runs the currently due work for one named project.
• Due, all projects runs currently due shared work across the registered projects.
• Full portfolio, one project reviews all eligible task families for one project, within the normal limits.
• Full portfolio, all projects does the same for the whole portfolio.

`Force` permits an intentional manual run of otherwise eligible work within the normal project limit, even when it is not due. It does not bypass prerequisites, expand authority, or turn into a secret fifth mode called “do absolutely everything”.

What a scout does

A scout gathers bounded evidence for a later decision. It does not promote its own findings to truth.

• A model scout can compare local-model candidates and record quality or resource evidence. Candidates remain quarantined until an owner reviews them.
• A skill scout can discover a possible reusable tool, inspect it, and test it in isolation. Discovery does not install a plugin or grant it project access.
• Community and GitHub scouts collect public signals and metadata. They do not treat a search result as a trusted dependency, clone arbitrary repositories, or read private project material.

The same rule applies to every scout: gather only the declared amount, keep the source and limits visible, and leave adoption to the owner who would rely on the result.

What completion means

Night work ends with reviewable evidence: a report, a plan, a check result, or a clearly recorded “nothing due”. Evidence can inform a project, but it does not itself change canonical notes, install software, publish content, transfer authority, or wake another task. Any follow-up that needs an owner decision waits for that decision.

A small example

Suppose the weekly model scout finds a promising local model. It records where the candidate came from, what small test it passed, and what remains unknown. Workbench can show that evidence to the project owner; it does not quietly replace the project's model, send the task to the cloud, or put a ceremonial hat on the candidate and call it approved.

Current boundary

Night and its scouts provide bounded review and discovery with explicit limits, isolation, and evidence. Project owners still decide whether a finding is useful, safe, licensed, accurate, or worth implementing. Future ideas remain ideas until the working Workbench releases and validates them.

Workbench can create generated evidence that makes complicated work easier to inspect. A context record can show which sources were supplied and what did not fit. If a required source or section is missing, the context is not quietly treated as complete; an optional omission remains visible for the reader. A work plan can name intended outputs and checks. An execution record can distinguish a model's claim from a tool result and the validation that followed.

These records improve accountability, but they do not grant permission. A plan does not perform the work, a successful model answer does not approve itself, and a specialist request plan does not summon another project like an unusually well-documented ghost. The relevant project owner still decides whether to ask for help, accept evidence, change canonical material, or publish.

For example, a documentation task may receive a source-bound context packet, ask a specialist project for one bounded review, and record a passing structure check. A merge-readiness result marked `StructuralOnly` means only that the package has the expected shape; it is not evidence that the sources are intact, the payload is valid, the meaning is accepted, or the work is permitted to execute. The editor must still judge meaning, disclosure, and authorship before using the result. Workbench preserves the receipts; it does not wear the editor's hat when nobody is looking.

This separation is deliberate. Evidence can be generated, repeated, compared, and corrected without quietly changing authority, privacy, project ownership, model routing, or publication rights.

Workbench treats a useful failure as evidence, not as a campfire story about a machine that was definitely haunted. A durable lesson records what happened, what was actually observed, what consequence followed, which method worked better, and what future change would make the lesson worth checking again.

The stage of failure matters. If a coordinating wrapper reports an error after another service may have completed its work, Workbench checks the exact result and durable receipts before deciding whether to retry. A late error does not prove that nothing changed, just as a cheerful success message does not replace verification.

A lesson becomes shared only when the evidence supports a reusable principle. Project-specific meaning stays with its project, and low-level paths, logs, credentials, security-sensitive operations, and recovery details remain private. Sometimes the public lesson is simply that a newly valid empty state deserves an intentional result instead of an accidental crash; the stack trace need not be invited to tea.

Lessons improve methods, tests, and explanations, but they do not grant authority. They cannot approve publication, reveal credentials, delete stale material, or change another project's decisions. The relevant owner still decides what to adopt, and the working implementation still has to release and validate any executable correction.

Workbench treats outside information as research evidence, not as an instruction or a new project decision. Approved material can be retained with its source, observation time, content identity, and acquisition method so a later reviewer can tell what was actually examined.

Research records also keep awkward facts visible. Material may be stale, superseded, unavailable, duplicated, or in conflict with a stronger source. A context builder may omit unsuitable optional evidence or require a conflict to be resolved, but it does not quietly choose whichever paragraph arrived wearing the most confident punctuation.

For example, a project comparing two public specifications can record both versions, their dates, and the exact passages used. If they disagree, the resulting context identifies the conflict and the owner decides what further evidence or review is needed. The cache preserves provenance; it does not promote a claim into canonical project knowledge.

Discovery, acquisition, review, and acceptance remain separate steps. Credentials, signed-in browsing, private sources, high-stakes decisions, canonical promotion, and publication still require their own authority and safeguards.

Workbench now has a Customer Core preview that can be built and exercised locally. It explores how a safer, smaller package could present common Workbench capabilities without carrying Peter's projects, credentials, prompts, transcripts, generated research, model files, or development caches along for the outing.

The preview uses an explicit list of admitted files, verifies package identity against the current local source, checks the host before installation, and installs only into a disposable target. That verification is exact local lineage, not a publisher signature or claim of official public origin. Its current Doctor checks installed file identity. It does not claim that every optional service, network, database, or model is healthy, and proposed repairs do not apply themselves.

For example, a downloaded preview archive can be verified, installed into a temporary location, and checked without modifying the active Workbench. A missing dependency is reported with its limitation or fallback rather than being silently installed with a flourish and a small invoice from the Ministry of Surprises.

This is a local preview, not a public software release. Public redistribution remains blocked until Peter deliberately chooses a distribution licence and separately authorizes release. Optional components and independent project extensions remain separate.