Once the service is real, the loop is simple:

If only handler implementation changed, you usually do not need a contract prepare or authority change. If the public boundary changed, regenerate artifacts and update deployment authority.

Public boundary changes include schemas, RPCs, events, operations, resources, state, dependencies, and capabilities.

Use Console as the primary review path for authority changes. Open Admin → Services, select orders-service, review the pending Authority review required delta, and accept or reject it before restarting runtimes that require the new boundary.

For local development or automation, the Trellis CLI can decide the same pending request:

trellis svc orders-service authority plan list --state pending
trellis svc orders-service authority plan show <plan-id>
trellis svc orders-service authority accept-update <plan-id>
trellis svc orders-service authority reject <plan-id> --reason not-needed

Accepting the plan updates desired authority and schedules reconciliation. You only need authority reconcile for repair, retry, or manual convergence.

Congratulations. You now have a fully functional Trellis service. It connects, stores data, handles RPCs with access control, listens for events from other services, and publishes its own.

Next, you can move long-running fulfillment work into the background with Jobs: TypeScript, or expose a caller-visible async workflow with progress updates using Operations: TypeScript.