dorian v1.1.1 — golden path now blocks broken promises

dorian v1.1.1 — the golden path now blocks broken promises

A small, focused follow-up to v1.1.0. No breaking changes — this changes a single
scaffold default; the warrant format, checker grammar, exit codes, and trust semantics are unchanged.

What changed

• dorian init's starter claim is now load-bearing. In v1.1.0 the scaffolded starter claim sealed
  as non-load-bearing, so when a later change broke it the warrant folded to DEGRADED (exit 3) —
  and the scaffolded GitHub Action (fail_on: revoked) does not block on DEGRADED. So a first-time
  user following the golden path would break the promise and watch it silently ship. The starter is
  now load-bearing: breaking it folds to REVOKED (exit 4) and the default Action blocks the PR.

Why it matters

dorian's whole pitch is "broken promises do not silently ship." The golden path (dorian init) is the
first thing a new user runs, and it should demonstrate the gate — not degrade quietly under the
default Action. This release makes the out-of-the-box experience match the promise. It also resolves an
internal inconsistency: the scaffolded change note already called these "load-bearing facts."

This was caught by the v1.1.0 public-install smoke test (install from PyPI → init → verify → break
→ revalidate), which observed WARRANTED → DEGRADED (exit 3) where the product promise calls for a
block.

Install

pip install -U dorian-vwp        # 1.1.1
dorian --version

Quickstart (the golden path, now blocking)

cd your-repo
dorian init                                                # claims.json + change note + workflow
dorian verify dorian-change-note.md --claims claims.json   # seals green — exit 0
# ...later, a change breaks the sealed fact...
dorian revalidate --since <base>                           # REVOKED, exit 4 — the Action blocks the PR

GitHub Action

Unchanged. The scaffolded workflow pins ajaysurya1221/dorian/action@v1.1.1 and uses the default
fail_on: revoked, which now blocks when the starter claim is broken.

Security notes

No change to the security boundary. dorian init still writes files only — it never runs a checker,
never executes code, never writes outside the repo root, and never overwrites without --force. The
starter claim remains a read-only C3 checker (config-value:/path:). --deny-exec/--deny-shell
and checker_trust: base are fail-closed policies, not a sandbox.

Known limitations

• dorian verifies explicit, checkable claims — not arbitrary correctness; it is not a sandbox.
• One documented, reproduced real cross-PR catch (encode/httpx) — not broad real-world validation.
• A load-bearing starter means that if you keep the example claim and legitimately change the fact it
  pins (e.g. rename your package), the next PR is REVOKED until you update the claim or supersede the
  warrant — which is the intended "you changed a sealed fact, acknowledge it" behavior. Replace the
  starter with your real load-bearing facts.

Tests / gates

Full suite green at 1.1.1 (the 1.1.0 suite plus 2 new dorian init tests pinning the load-bearing
starter and the end-to-end break → REVOKED → exit 4), ruff clean, wheel/sdist build + twine check
pass, and a public-install smoke test from PyPI.

Upgrade notes

pip install -U dorian-vwp. Already-sealed warrants are unaffected. If you want a previously
scaffolded starter claim to block, set its load_bearing to true in claims.json and re-seal with
dorian verify, or re-run dorian init --force to regenerate the scaffold.