Migrate Application Operation

Create Or Migrate Application Operation

Create or migrate one bounded semantic operation at a time. Share authorization and business behavior without forcing internal APIs, public APIs, Copilot, and other tools to share authentication, input schemas, or response shapes.

Enforce the application boundary

Apply this invariant:

Every real operation on persisted or protected data enters through an authorized application use case.

This includes mutations, content and metadata reads, canonical resource lookup, and reference-to-resource resolution when the lookup is authorization-sensitive.

Surface helpers may:

• Normalize an already-authenticated surface context into a Principal.
• Translate aliases or wire arguments into application input.
• Select a code-defined operation and application use case.
• Call the application use case.
• Translate typed results and errors into the surface contract.

Surface helpers must not:

• Query databases or storage.
• Decide workspace or resource authorization.
• Implement business transactions.
• Record semantic audit or shared domain notifications.
• Infer authoritative identity, workspace, audience, or scope from untrusted arguments.
• Substitute billing attribution for identity.

A helper that resolves a path is valid only when the actual protected lookup runs through an authorized application resolver. If a helper begins doing real data work, move that work into an application use case.

Read the foundation first

Read these files completely before editing:

• packages/auth/src/principal.ts
• apps/sim/lib/core/application/operation.ts
• apps/sim/lib/core/application/workspace-operation.ts
• apps/sim/lib/core/application/workspace-authorization.ts
• apps/sim/lib/core/application/authorized-workspace-use-case.ts
• apps/sim/lib/api/server/routes/definition.ts
• apps/sim/lib/api/server/routes/internal-json-route.ts
• apps/sim/lib/api/server/routes/v2-json-route.ts
• apps/sim/lib/auth/internal-delegation.ts
• apps/sim/lib/mothership/application/application-adapter.ts
• apps/sim/lib/mothership/auth/application-delegation.ts

Use the file domain only as a representative golden slice:

• apps/sim/lib/workspace-files/application/operations.ts
• apps/sim/lib/workspace-files/application/authorized-workspace-file-use-case.ts
• apps/sim/lib/workspace-files/application/rename-workspace-file.ts
• apps/sim/lib/mothership/application/execute-file-use-case.ts
• apps/sim/lib/mothership/auth/file-delegation.ts

Then read the target domain's operation registry, application code, repositories, contracts, adapters, aliases, resume paths, and focused tests. Fail immediately if the shared foundation is absent. Do not recreate it inside the domain.

Bound the migration

Inventory every entry point for the behavior before editing:

• Internal HTTP routes and contracts.
• Public or versioned API routes and contracts.
• Copilot tools, aliases, resume paths, and polymorphic branches.
• Other tool servers, workflow executors, jobs, or service callers.
• Current authentication, authorization, workspace assertions, and concealment.
• Manager or orchestration call chains.
• Audit, notification, analytics, and billing side effects.
• Error/status/result behavior.
• Rate-limit identity, rollout gates, quota, and concurrency admission.

Classify each as migrate, defer, or non-goal. Do not migrate adjacent operations merely because they share a module. Do not modify v1 unless the request explicitly includes it.

Preserve behavior unless the task explicitly changes it. Stop and report a decision when surfaces currently disagree on security or compatibility behavior; do not silently choose one.

Freeze observable behavior before editing

Treat the legacy route or tool as an ordered program, not merely a bag of business logic. Before moving code, write a compact baseline for every in-scope entry point. Pin behavior no existing test covers with a characterization test only where it passes the test-audit gate; otherwise record it in the baseline and verify it by hand after the move.

Capture all of these when they apply:

• Accepted inputs, including trimming, blank omission, duplicate query keys, aliases, defaults, and bounds.
• Authentication and authorization order, minimum roles, resource membership, concealment, and exact error/status mapping.
• Exact success bodies, optional fields, status codes, redirects, cookies, headers, and binary or stream behavior.
• Mutation ordering, transaction boundaries, idempotency, no-ops, and observable state after each possible partial failure.
• Audit, notification, analytics, and billing timing plus exact semantic dimensions and attribution.
• Browser or protocol state ownership, concurrency isolation, expiry, callback ordering, and cleanup behavior.
• Every value newly crossing into HTML, JavaScript, SQL, URLs, logs, provider payloads, or another encoding context.

Compare the old statement order with the proposed application lifecycle explicitly:

legacy parse/normalize
  -> legacy authorization checks
  -> branch-specific canonical lookup
  -> mutation(s)
  -> per-step side effects
  -> response or redirect catch

Moving those steps under a wrapper may change behavior even when each individual call is reused. In particular:

• projectAudit and afterSuccess run only after execute returns. They cannot describe earlier committed mutations when a later step throws. Make the compound mutation atomic or define explicit partial-result/failure projection semantics before migrating it.
• Operation metadata is executable policy. Adding a resource role to a workspace-only legacy read is an authorization change, not an architectural cleanup.
• A shared error policy does not automatically preserve route-local concealment, subclass ordering, browser redirects, or branch-specific messages.
• A shared contract does not automatically preserve manual URLSearchParams normalization or exact legacy response unions.
• A shared use case may own domain behavior while separate surface presenters still preserve different wire shapes.
• Per-flow identity is insufficient when another part of the flow remains in browser-global state such as one cookie.
• Passing a newly supported parameter through old rendering code creates a new security boundary even when the renderer itself is unchanged.

Fail fast if the baseline cannot be established from code, tests, or an explicit product decision. Do not infer that behavior is unimportant because it was previously implicit.

Keep the layers distinct

Use these responsibilities:

1. Authentication adapter: verify the surface credential or trusted execution context and construct a Principal.
2. Route or tool adapter: select rate policy, parse its contract, translate input, call the application use case, and render its own result.
3. Application use case: load canonical context, compare asserted scope, authorize the semantic operation, execute business behavior, project semantic audit, and trigger shared domain effects.
4. Manager or repository: perform database and storage reads or writes using canonical identifiers and scope. Never accept credentials or principals.
5. Presenter: return only the surface success body or typed binary descriptor. Never construct auth, rate, or error behavior.

For ordinary public JSON routes, preserve this order:

IP abuse limit
  -> authenticate
  -> build Principal
  -> operation rate limit
  -> parse surface contract
  -> application use case
      -> canonical load
      -> asserted-scope concealment
      -> current authorization
      -> manager read or mutation
      -> semantic audit
      -> shared domain effects
  -> surface presenter

Internal routes may omit the IP bucket or operation limit only through an explicit policy with a reason. Usage billing, storage quota, cost admission, and concurrency are separate from request-rate limiting.

Never query API keys or sessions from the application layer. Never add fallback identity or authorization behavior. Propagate infrastructure failures instead of turning them into not-found or forbidden results.

Define the semantic operation once

Add one stable entry to the target domain's operation registry:

rename: defineWorkspaceOperation({
  id: 'widgets.rename',
  minimumRole: 'write',
  workspaceApiKey: 'allow',
  capability: 'widgets.use',
  principalKinds: ['session', 'personal_api_key', 'workspace_api_key', 'delegated'],
  delegatedServices: ['copilot'],
})

Do not create internal-, public-, or Copilot-specific versions of the same semantic operation. If two callers have materially different business or transactional semantics, define separate semantic operations and use cases and explain the distinction.

Choose principal kinds from actual behavior. Do not accept every principal merely because the use case is shared. Workspace API keys have a write ceiling and cannot satisfy admin operations. The operation definition must fail fast when its role, workspace-key policy, and principal kinds disagree.

capability is required: a static, operation-declarable capability (not parameterized, not principal-wide), or 'none' with a // permission-group-exempt: <reason> comment directly above it. If principalKinds includes oauth_access_token, oauthScope (api:read | api:write | search:read) is required. defineWorkspaceOperation throws at definition time on any violation. See add-permission-group-item.

Route declarations, tool adapters, and use cases must use the same literal operation. Runtime operation selection is permitted only from a trusted, code-defined registry. Never accept an operation ID or permission tag from an HTTP body, model argument, or other untrusted input.

Unified selector execution is one operation

Dynamic selector dispatch is the deliberate instance of trusted runtime selection. Define and authorize selectors.execute once: it means "enumerate options while configuring a workflow or workspace resource." The browser supplies only a selector key from the exhaustive browser-safe manifest, scope, allowlisted context, and list/detail request. After canonical scope authorization, the application use case selects the matching attachment from the exhaustive server-only registry.

Provider and internal attachments are trusted implementation adapters under that semantic operation, not separate application operations. Do not create one operation per selector, provider, or listing endpoint. Attachments may choose only code-defined credential/service binding, destination policy, provider primitive, and projection behavior; they must not accept a module, provider, service, operation kind, origin, or permission tag from the request. The selectors.execute use case owns reference resolution, credential authorization, provider invocation, sanitization, and safe result projection end to end.

Implement the application use case

Use defineAuthorizedWorkspaceUseCase directly or a thin domain binding that supplies domain-specific authorization options:

export const renameWidget = defineAuthorizedWorkspaceUseCase({
  operation: widgetOperations.rename,
  resolveContext: ({ input }: { input: RenameWidgetInput }) =>
    loadCanonicalWidgetContext(input.id, input.assertedWorkspaceId),
  authorizationOptions: { delegation: widgetDelegationPolicy },
  execute: async ({ input, context }) => renameWidgetRecord({
    workspaceId: context.workspaceId,
    widgetId: context.resourceId,
    name: input.name,
  }),
  projectAudit: ({ result }) => ({
    action: AuditAction.WIDGET_UPDATED,
    resourceType: AuditResourceType.WIDGET,
    resourceId: result.id,
    resourceName: result.name,
  }),
  afterSuccess: ({ context }) => notifyWidgetsChanged(context.workspaceId),
})

Adapt the example to the domain's real authorization options; do not copy invented field names.

The wrapper must own this lifecycle:

1. Reject disallowed principal kinds before protected loading.
2. Load canonical context and conceal asserted-scope mismatches as required.
3. Authorize the operation using current policy state.
4. Execute the manager or repository primitive.
5. Project audit from authoritative results.
6. Await shared post-success effects.

Do not call shared authorization, principal audit attribution, or recordAudit manually from an ordinary migrated use-case body. Use projectAudit only when the operation has semantic audit. Return no audit entries for authoritative no-ops. Keep product analytics such as captureServerEvent surface-specific through the adapter's success hook.

Inspect legacy orchestration before reusing it. If it already authorizes, audits, notifies, or captures analytics, call a lower-level primitive or remove duplicate responsibility for migrated callers.

Application code must remain surface-neutral. It must not import app/api/**, next/server, internal/v1/v2 contracts or presenters, or Copilot tool handlers. Return domain values and let each surface presenter project its own wire result.

Adapt internal APIs

Use defineInternalJsonRoute for ordinary JSON routes. Explicitly declare the contract, authentication policy, semantic operation, rate policy, error policy, input mapping, use case, and presenter when the wire result differs.

Use internalSessionAuth for session-only routes. Use createInternalSessionOrExecutorAuth only when the endpoint genuinely supports signed executor delegation; the semantic operation must then allow delegated principals from the executor service. Never turn an actorless legacy JWT into a fake session, owner, or user principal.

The internal adapter owns authentication and internal response envelopes. It must not implement workspace authorization. Preserve internal-only analytics through onSuccess after application success.

Keep the route module declarative. If several internal routes repeat authentication, parsing, error rendering, or response construction, improve the shared internal route builder instead of adding a domain-specific route wrapper.

Adapt public or versioned APIs

Use the appropriate public/versioned route builder, such as defineV2JsonRoute, with API-key authentication, explicit semantic operation and rate policy, external error projection, input mapping, application use case, and an external presenter.

Authentication and HTTP formatting may differ from internal APIs; authorization and business behavior must not. Rate-limit using the credential or principal subject, never a billed owner. Resolve billing attribution only for billing, quota, or legacy required-user fields.

Keep surface contracts separate when their wire shapes differ. Reuse shared primitive schemas and domain validators for invariants such as IDs, names, bounds, and formats. Do not maintain duplicate internal and external schemas merely because the routes are separate; import the same schema when the wire shape is genuinely identical. Never cast one surface response into another.

Keep v1 middleware and routes unchanged unless explicitly included.