Mapping a live schedule to a tessl.json entry

tessl schedule view <id> --json returns a live schedule's config. This maps each source field to the schedules file entry, and calls out what the read path does not expose.

The file schema is validated strictly: a field name outside this table is a hard error. Use only the fields below.

Source to file field

The config.repoUrl in the live config identifies the repo the schedule runs against. It has no file field: a repo-defined schedule runs against the repo it is committed to. Confirm you are migrating the schedule into that same repo's tessl.json. A schedule pointing at a different repo cannot simply be moved into this file.

agent and model: provenance is unknown

schedule view returns the resolved values for agent and model, but does not indicate whether they were explicitly configured or inherited from workspace defaults. You cannot determine provenance from the read result.

Before writing these fields, ask the user: "The live schedule shows agent <value> and model <value>. Were these set explicitly when the schedule was created, or inherited from workspace defaults?"

• If set explicitly: include them in the file entry.
• If inherited or unknown: omit them so the repo schedule picks up current workspace defaults. An explicitly set value equal to the current default should still be included if the user wants to preserve it.

Never silently omit or copy these fields based on the read value alone.

Fields the read path does NOT return

These are withheld on the read API because they can carry sensitive values, so view cannot recover them:

• inputs: the schedule's structured skill inputs.
• instructions: free-text instructions appended to the prompt.

If the original schedule was created with either, the values cannot be recovered from view. Before asking the user for these values, warn them that tessl.json is committed to the repository and visible to everyone with repo access, including history. If the values contain credentials, tokens, or personal data, the user should store them in the workspace environment instead and reference them via environment variables, not embed them in the file.

Only add inputs or instructions to the entry if the user confirms the values are safe to commit. Otherwise note that they are not carried over. Never guess them.

Fields with no file equivalent

These exist on a live schedule but are not part of the schedules file schema, so they are dropped when the schedule becomes repo-defined:

• effort: explicit reasoning effort for the selected agent. view returns it, and every fire uses it. A repo-defined schedule falls back to the agent default. Tell the user before dropping a set value.
• mcpServers: workspace MCP servers wired into every fire. view does not return this field. A schedule can carry it only when its config was copied from a launch run, whether the schedule was created with CLI --from-run, the UI, or API fromLaunchRunId. Ask whether the copied launch run used MCP servers. A repo-defined schedule cannot preserve them.
• timeoutMs: per-run timeout override. A repo-defined schedule uses the default timeout.
• label: the file uses the schedule key as its identity and description as its human text; there is no separate label.
• Sandbox image selection: in attributes.config, locate the optional property whose value is an image identifier; it has no file equivalent. Its presence means the schedule explicitly chose an image, not necessarily a non-default one. An absent identifier, or one whose repository is recipe-runner-base (including its regional -eu form), uses the standard image. Any other identifier is non-default. A repo-defined schedule cannot preserve a non-default selection, so tell the user that future fires will use the standard image and ask whether to proceed before migrating.
• Stored metadata: internal/runtime data, not author-set config.

Tell the user when the source schedule used a non-default timeoutMs or a label, so dropping it is a decision rather than a silent loss.

Source schedule status

attributes.status has no file equivalent. Repo reconciliation always creates new schedule entries as active.

If the source schedule is paused, the migrated repo schedule will be active immediately after the push. Alert the user before proceeding and ask for an explicit decision. Do not migrate a paused schedule without this confirmation.