Shared Services, Small Jobs
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.