Strict YAML before CI: duplicate keys, YAML 1.2, and Actions permissions

A few recent workflow failures pushed me to build a deliberately small checker. One project had a syntactically valid workflow stop parsing because workflows: write was not a valid permissions key. Another generated a block scalar with broken indentation and got zero-job failures on every push. I also found the opposite problem: a local validator rejected a newly supported field because its schema was stale. Those cases shaped YAML Preflight.

Here is the smallest example of the kind of mistake it catches:

service:
  port: 8080
  port: 9090

Some lenient loaders silently keep the last value. A strict preflight rejects the duplicate at its source location instead of letting behavior depend on whichever parser runs next.

👉 Try the live preflight — no signup, no YAML upload

The page opens with valid YAML containing an invalid GitHub Actions permission. Click Run free preflight to see the scoped finding, choose the duplicate-key example, or paste your own YAML.

What works today

• browser-local parsing; the pasted document never leaves the page
• strict YAML syntax checking, up to 100 KB
• duplicate mapping-key detection
• YAML 1.2-style booleans, so a GitHub Actions on key is not normalized into true
• a small GitHub Actions permissions check based on the current official reference

Unknown permission names are warnings rather than hard failures, precisely because platform schemas evolve. The result links to the GitHub reference and states when the bundled list was checked.

What it does not do

This is not full GitHub Actions workflow-schema validation. It does not inspect repositories or execute workflows. Parsing now runs entirely in your browser: the pasted document is never sent to the server. A check sends only an anonymous valid/invalid result for this experiment. The checker has a stable URL, but this is still an early validation deployment with no availability promise.

The commercial experiment, stated plainly

The checker is working and free. A $9/month CI monitor shown beside it is only a proposed next step; it is not built. Clicking the interest button records one anonymous price-aware signal. There is no checkout and no payment is collected.

I am trying to learn one thing before building more: would you want this as a pull-request check, and which YAML failure has cost you the most time?

Relevant public failure reports that informed the scope:

• Invalid workflow permission stopped parsing and triggers
• A reusable workflow broke every caller on the same invalid permission
• An invalid permission disabled an entire nightly after merge
• Generated indentation caused persistent zero-job failures
• A stale local schema rejected a new valid field

The first three are independent August 2026 reports of the exact workflows: write mistake. In one case, ordinary YAML parsing and an eight-job test matrix both passed while GitHub silently stopped issue, cron, and manual triggers.

Current duplicate-key evidence

This failure still appears in maintained projects.

invoice2data reports that template authors regularly repeat field keys expecting fallback behavior, which silently removes the first extraction rule.

Kattis problemtools records an in-the-wild duplicate validator flag.

DisMech documented two merge-born duplicates from concurrent curation PRs; one broke main, while another remained unnoticed until a whole-repository check.

These are public project reports, not YAML Preflight customers or testimonials. They are the concrete failure class this free experiment checks.