Back offices & supporting services

Choose presentation independently of permission

An administrative surface uses the same authenticated application mechanisms as other views. Resource UI behavior can select standard or custom presentation; backend operation rules independently determine what the caller may do.

The following selected Wonder Todos resource-view entries show the distinction between an embedded operation and an addressable custom view. Imports and the surrounding resource UI behavior are omitted.

[Op.CREATE, { surface: ResourceOperationFrontendSurface.EMBEDDED }],
[Op.READ, {
  surface: ResourceOperationFrontendSurface.ADDRESSABLE,
  customView: TodoReadCustomView,
}],

TodoReadCustomView is application-owned. Reusing a resource layout can keep standard record behavior while adding a focused workspace. Neither the custom view nor its presence in navigation grants additional backend access.

Connect authority to a specific operation

Role assignment and revocation should use their dedicated operations. Ordinary field editing is not a substitute for the rules surrounding authority changes. Preserve the last administrator and the caller’s authority ceiling where those contracts apply.

Deliver the workflow, not just its menu

Verify the permitted operation directly through the API, then repeat as an unauthorized person. Change the operator’s role and check the next request. Include useful success and failure feedback in the view.

A separately deployed administrative frontend is an application topology decision. The minion generator creates no screens or operator interface. Read internal tools when the administrative workspace becomes a product for a staff team.

Declare the runtime mode

This illustrative materialization of the generated minion manifest names a work-inspection process. The runtime reads the schedule in UTC.

import { defineMinionConfig } from '@wildo-ai/platform-config-lib';

export default defineMinionConfig({
  version: 1,
  name: 'work-inspector',
  displayName: 'Work inspector',
  description: 'Inspect permitted application work',
  runtime: { type: 'docker', language: 'typescript' },
  mode: 'cron',
  schedule: '0 */6 * * *',
  reinstantiation: { policy: 'kill_previous' },
  resources: { cpu: '500m', memory: '512Mi' },
});

kill_previous governs replacement of the deployed process. In Kubernetes it selects Recreate; it is not a lock around the handler and does not prove that ticks cannot overlap.

For always-up, omit the schedule and supply the service’s continuous work and shutdown behavior. Mode selection does not install a repeating work loop or automatically call onTick.

Implement work through the supplied context

This selected excerpt from Wonder Todos’ marketing-scrapper initialization performs operational inspection. Despite the package name, the shown implementation reads tasks and its own schedule; it does not scrape or enrich data. Surrounding initialization and logging are omitted.

onTick: async (token, { systemAccess, minionName, ownSchedule }) => {
  const todos = await systemAccess.listAsSystem<{ _id: string }>(
    TasksManager_ResourceType.TODOS,
    {},
  );

  const ownJobs = await ownSchedule.read();
},

The initialization registers this handler with the matching minion runtime key. The resource and platform permissions in the next section are prerequisites for these calls.

Handle execution and delivery separately

Exercise a thrown error as well as a successful handler. Check what the operator can observe, rather than assuming the scheduling history contains the application’s completion state.

Declare access on the application runtime entry

This selected Wonder Todos entry belongs in its exported application-minion map, not in the package manifest. The key identifies the runtime; the path points to its source package.

marketingScrapper: {
  path: './minions/marketing-scrapper',
  resourceAccess: {
    read: ['todos'],
    write: [],
  },
  platformAccess: {
    scopes: [MinionPlatformAccessScope.OWN_CRON_RECORDS],
  },
},

MinionPlatformAccessScope is exported by @wildo-ai/platform-config-lib. The generated starter uses empty read and write lists. Startup rejects unknown resource names and installs the scoped registry before accepting work.

Use the supplied access boundary

The scoped service proxy classifies recognized read and write methods and refuses unrecognized access. systemAccess.listAsSystem additionally requires the resource’s system-read policy. Under the minion runtime profile, failure to record the required system-access audit refuses the privileged access.

This is a defined service access path, not permission to bypass it with arbitrary application code or a blanket claim of proven database-level confinement.

Keep runtime identity consistent

The package directory, runtime bucket key and provider scope have different roles. Register the same runtime key where initialization and generated configuration expect it. ownSchedule.read() takes no arbitrary minion identifier: the platform derives the caller’s identity from its attestation.

Test a permitted read, a refused write, an undeclared resource and a refused schedule read after removing its platform grant. A failed platform read must remain a failure, not an empty successful history.