Skip to content

dorian v1.1.0 — CI truth gate: dorian init + clearer PR comment

Choose a tag to compare

@ajaysurya1221 ajaysurya1221 released this 18 Jun 18:30
· 5 commits to main since this release
a27b540

dorian 1.1.0

A productization release that makes the first run easy. No breaking changes: the warrant
format, checker grammar, exit codes, and trust semantics are unchanged. 1.1.0 adds the missing
golden-path onboarding command, makes the PR-comment output customer-readable, and cleans up a
packaging-hygiene defect — it changes a command surface and output formatting, not verification.

What's new

  • dorian init (new command) — first-run scaffolding so a new user reaches a sealed warrant in
    minutes instead of hand-writing JSON. It writes three files:

    • a born-verifiable starter claims.json (a config-value: claim about the pyproject package
      name when available — the same checker family that caught encode/httpx #3592 — otherwise a
      path: existence claim about a file that is present, so the first dorian verify seals green, not red);
    • dorian-change-note.md, the change note those claims back;
    • .github/workflows/dorian.yml, the GitHub Action workflow, pinned to this package's version.

    It writes files only — it never runs a checker, never executes code, never writes outside the
    repo root, and never overwrites an existing file without --force (re-running is idempotent).
    Supports --dry-run (print the plan, write nothing) and the global --json (machine-readable
    summary). The scaffolded starter checker is always a read-only C3 family, never an executable
    C4/C5 — safe by default.

  • Customer-readable PR commentdorian revalidate --format md (the body the GitHub Action
    posts) now leads with an explicit Status: Blocked / Passed / Errored verdict, an aggregate
    trust-change counts table (how many touched warrants this change moved to REVOKED / DEGRADED /
    TRUSTED / UNKNOWN), a sealed in <artifact>.warrant line under each affected artifact, and a
    verdict-keyed What to do: remediation line. The existing per-claim verdict table, fold
    transitions, recall section, and stats footer are unchanged; the comment stays deterministic (no
    timestamps, no absolute paths) and keeps the 160-char content-carryover bound on every detail cell.

Packaging hygiene

  • Guards against editor/file-sync duplicate artifacts. A .gitignore rule and a Hatch build
    exclude now keep stray … 2.py sync-duplicate files (the kind macOS / cloud sync leaves behind,
    e.g. suggestclaims 2.py) from ever being tracked or packaged into a wheel — even from a dirty
    working tree. To be precise: these files were never tracked in git, so they were never in a
    CI-built wheel or on PyPI; the guards additionally make a local uv build from a dirty tree
    provably clean (33 modules, no space-named files).

Tests & gates

Full suite green at 1.1.0 (883 tracked tests: the 1.0.2 suite plus 8 new dorian init tests, and
new assertions pinning the enhanced PR-comment output), ruff clean, wheel/sdist build +
twine check pass. The new dorian init golden path is covered end to end (initverify
exits 0 and writes a warrant — a tool whose pitch is "don't ship false claims" must not ship a
false scaffold).

The reproducible benchmark suites are not re-run here: 1.1.0 adds a command, output formatting,
and a packaging cleanup, none of which touch the checker, binding, or fold code the suites measure,
so the recorded figures stand unchanged (last executed at 1.0.2; see
docs/BENCHMARK_CURRENT.md).

Honest scope (unchanged)

dorian has one documented, reproduced real cross-PR catch on frozen public SHAs (encode/httpx
requires-python floor; see docs/REAL_CATCH_LOG.md) — not broad
real-world validation. The benchmark suites are reproducibility evidence on frozen fixtures only.
--deny-exec/--deny-shell are fail-closed policies, not sandboxes; checker_trust: base is a
checker-source trust root, not a sandbox. dorian init and suggest-claims scaffold starter claims
for review — existence/value checks, not behavior (a gutted body keeps a symbol: claim green). A
warrant id is content-addressed and tamper-evident, but its body includes the seal timestamp, so a
fresh seal yields a different id — what reproduces is the outcome, not the id.

Install

pip install dorian-vwp        # 1.1.0 on PyPI

dorian init                                                # scaffold a starter setup
dorian verify dorian-change-note.md --claims claims.json   # seal the warrant — exit 0