# Developer operations

## Integer base conversion

Call `POST /v1/math/integer/base-convert` with a signed integer string, `fromBase`, and `toBase`. Bases range from 2 through 36 and input is limited to 4,096 digits.

```json
{"input":"-255","fromBase":10,"toBase":16}
```

The result uses uppercase digits and preserves a negative sign. Invalid digits are rejected rather than ignored.

## Integer byte inspection

Call `POST /v1/developer/bytes/inspect` with `hex` and optional `byteOrder: "big" | "little"`.

```json
{"hex":"ff fe","byteOrder":"big"}
```

The input must contain complete hexadecimal bytes and may contain whitespace. The response returns normalized and reversed hex, byte and bit lengths, and signed two's-complement and unsigned decimal interpretations. Input is limited to 128 bytes.

## Unix permissions

Call `POST /v1/developer/chmod/convert` with string `input` and required `inputFormat: "octal" | "symbolic"`. The API does not infer the format.

```json
{"input":"755","inputFormat":"octal"}
```

With `inputFormat: "octal"`, use exactly three octal digits or the same three digits with one canonical leading `0`, such as `755` or `0755`; inputs such as `x755` and `000755` are invalid. With `inputFormat: "symbolic"`, use exactly nine basic permission characters, such as `rwxr-xr-x`. The response contains four-character octal text, nine-character symbolic text, and owner/group/other groups. Special mode bits, values such as `4755`, and file-type prefixes are not supported.

## IEEE 754 encoding

Call `POST /v1/developer/ieee754/encode` with finite JSON number `value` and `precision: "float32" | "float64"`. The response provides big-endian hex, binary, and byte-array representations. Float32 overflow is rejected.

## SHA-2 hashing

Call `POST /v1/crypto/hash` with:

```json
{"input":"11DZ","algorithm":"SHA-256","output":"hex"}
```

Supported algorithms are `SHA-256`, `SHA-384`, and `SHA-512`; supported outputs are `hex` and `base64`. This is a digest operation, not encryption, signing, or password hashing.

## JWT inspection

Call `POST /v1/developer/jwt/decode` with `token` only after applying `references/privacy.md`. The bundled client always requires `--confirm-sensitive` for this path.

Expect decoded JOSE header and payload objects, the untouched Base64URL signature segment, timestamp annotations for numeric `exp`, `iat`, and `nbf`, warnings, and `verified: false`.

Never claim that the token is authentic or currently valid. The operation does not check its signature, issuer, audience, expiry policy, revocation, or authorization. Never send an active production token.

Decoded Header/Payload JSON is bounded to 128 nesting levels and a 1 MiB compact-output budget, and non-finite numbers are rejected. Preserve `JWT_HEADER_TOO_DEEP`, `JWT_PAYLOAD_TOO_DEEP`, `JWT_HEADER_TOO_LARGE`, `JWT_PAYLOAD_TOO_LARGE`, and `JWT_INVALID_*_JSON` errors instead of retrying the same token.

## Timestamp conversion

Call `POST /v1/time/convert` with `input` and optional `unit`: `auto`, `seconds`, `milliseconds`, or `iso`. The response contains `iso`, `unixSeconds`, `unixMilliseconds`, and `detectedUnit`; all calendar output is UTC.

Use an explicit unit when the caller knows it. In `auto` mode, report `detectedUnit` so the inference remains visible.