Employee CLI recovery

The operation-only Web route is /api/v1/infrastructure/internal-accounts/employees/operations/{operationId}/cli-recovery. Its CLI authorization grant is separate from Infrastructure audience acceptance. It verifies the unchanged CLI access bearer, CLI origin, current required-MFA policy/lineage and the existing current employee administrator checks. CLI recovery also requires a valid signed email that canonically matches the freshly read, confirmed Auth email, including when both addresses are internal. Missing or invalid email fails closed for reads and writes. Ordinary Infrastructure authorization keeps its existing behavior. There is no CLI-to-Infra exchange, actor override, service-auth bypass or ordinary CREATE admission. The release owner must independently review this grant and require exact-commit Web build, lint, type-check and test CI before any authorized release. For repository operator code, load the existing CLI configuration through its normal loader and create the existing SDK client. Do not print configuration, headers, passwords or credentials. Recovery requests must use a client without automatic refresh/replay: a final authorization failure can follow a committed adjudication or resume. Refresh authentication separately before starting if needed.

import { TuturuuuUserClient } from '@tuturuuu/sdk';
import {
  inspectEmployeeCliRecovery,
  observeEmployeeCliRecoveryOutcome,
  submitEmployeeCliRecovery,
} from '@tuturuuu/internal-api/infrastructure';
// Repository operator code uses the existing SDK configuration loader.
import { readCliConfig } from '../../packages/sdk/src/cli/config';

const config = await readCliConfig();
if (!config.session?.accessToken || !config.session.expiresAt ||
    config.session.expiresAt * 1000 <= Date.now()) {
  throw new Error('Authenticate with ttr login before recovery');
}
const client = new TuturuuuUserClient({
  baseUrl: config.baseUrl,
  accessToken: config.session.accessToken,
  // Omit refreshToken: this client must not retry a mutation after a 401.
});
const options = client.getClientOptions();
const state = await inspectEmployeeCliRecovery(originalOperationId, options);

The caller supplies its retained original operation ID; no production identity is embedded in the adapter. Independently compare the returned actor and complete identity tuple to the authorized retained intent. A fenced/unavailable response or an actor mismatch stops the procedure. GET never claims or creates anything. For eligible version 2, the original actor must actually establish terminal rejection from retained evidence and explicitly approve every existing attestation. Submit { action: 'adjudicate', adjudication } once with the exact returned tuple, original lease/attempt, retained event ID and evidence SHA-256. A nearby provider 422 and account absence do not establish terminal rejection. After an uncertain response, inspect; do not blindly repeat adjudication. Only after an independently matching retry_ready version-3 readback may the operator explicitly submit { action: 'resume', expected: state, temporaryPassword } once through submitEmployeeCliRecovery. Obtain the fresh password privately and keep it transient. The route rechecks current administrator authorization, operation/key and every identity/audit field before claiming the original operation. The existing journal reauthorizes its SQL and provider phases. After all awaited resume work, the route freshly checks the CLI token, MFA and current administrator authority before disclosing any result. Authorization loss withholds the result and returns nextAction: inspect; the mutation may already have committed. Retain the original operation and evidence, restore authorization separately, and inspect without replaying the mutation. The typed client accepts adjudication only at HTTP 200, and resume only as HTTP 201/created, 202/pending or 409/conflict with the matching original identity. Contradictory HTTP/payload pairs require inspection and never establish completion. An uncertain CREATE returns inspection guidance, never permission for another CREATE or replacement UUID. Use the same unexpired CLI access credential for read-only original-operation outcome observation:

const outcome = await observeEmployeeCliRecoveryOutcome({
  operationId: originalOperationId,
  targetUserId: retainedOriginalTargetUserId,
  email: retainedOriginalEmail,
  displayName: retainedOriginalDisplayName,
}, options);

This calls GET .../cli-recovery?view=outcome with the original operation key. Default GET remains rejection inspection and fences pending/active phases; view=outcome uses the normal observation factory with fresh CLI authorization, original actor/operation binding, independent provider identity, fresh SQL proof and final authorization before disclosure. It never claims, creates, provisions, unbans or replays. It requires no Infrastructure audience or credential exchange. Only HTTP 200/created or stopped and 202/pending are valid outcome pairs; conflict, contradictory statuses, identity mismatches and errors never establish completion. The original target, email and creation name remain bound; when terminal active SQL provenance supplies creationDisplayName, that immutable name binds the operation while displayName reports the current managed profile name. POST resume still requires the exact retry_ready version-3 tuple. Authentication restoration happens separately; do not add SDK refresh/replay to these calls. Synthetic local regressions cover signed credential target/scope/origin, expiry, refresh/signature failures, stale/missing signed or current emails, authorization changes during awaited journal work, the HTTP/outcome matrix, owned/missing/foreign operations, tuple/version changes, lost acknowledgement and no CREATE during adjudication. employee-cli-outcome-route.test.ts exercises the actual GET with signed CLI credentials, foreign actor/operation, active/pending/stopped, provider ban, contradictory fresh SQL, stale authority and no mutation dispatch. employee-cli-outcome.test.ts covers identity and the strict read-only HTTP matrix with one dispatch. These tests do not prove production operation state, original actor, provider effects or delivery. Parent/release custody retains those actions.

Overview

Platform

Build

Learn

Reference