Claudeagent and ClaudeagentA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.64dc0fcHistory