Release v1.1.0: dorian init + customer-readable PR comment (golden-path productization)#15
Merged
Merged
Conversation
New `dorian init` command writes a starter claims.json (a born-verifiable config-value:/path: claim so the first `verify` seals green), the change note it backs, and a version-pinned GitHub Action workflow. Writes files only — no checker execution, repo-root confined, atomic, idempotent; supports --force, --dry-run, and the global --json. 8 tests incl. end-to-end init -> verify exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add an explicit Status (Blocked/Passed/Errored) line, an aggregate trust-change counts table (derived from folds — honestly labeled as changes this PR made, not absolute state), a `sealed in <artifact>.warrant` line per artifact, and a verdict-keyed "What to do" remediation. Deterministic and content-bounded as before; the existing per-claim table, fold transitions, recall section, and stats footer are unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bump 1.0.2 -> 1.1.0 (new command + output formatting; no breaking changes). Foreground `dorian init` in the README Getting-Started flow, add a command-surface bullet, and move the action refs + PyPI 'latest' to v1.1.0. Re-stamp BENCHMARK_CURRENT (figures unchanged — 1.1.0 touches no checker/binding/fold code; suites last executed at 1.0.2). Add a .gitignore rule and a Hatch wheel `exclude` so stray editor/cloud-sync `… 2.py` duplicate files can never be tracked or packaged. New CHANGELOG.md and docs/releases/v1.1.0.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughBumps dorian to v1.1.0 by adding a new Changesdorian v1.1.0 Feature and Release
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI as dorian CLI
participant init as init module
participant FS as Filesystem
participant verify as dorian verify
User->>CLI: dorian init [--force] [--dry-run]
CLI->>init: build_plan(repo)
init->>FS: read pyproject.toml (project.name)
init->>FS: check existence of claims.json, note, workflow
init-->>CLI: InitPlan(files, starter_desc)
CLI->>init: apply(plan, force, dry_run)
init->>FS: atomic write claims.json, change-note.md, dorian.yml
init-->>CLI: ApplyResult(created, overwritten, skipped)
CLI-->>User: summary / JSON output
User->>verify: dorian verify --note change-note.md --claims claims.json
verify-->>User: sealed warrant + EXIT_OK
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/dorian/init.py`:
- Around line 218-227: The apply() function uses f.exists which is determined at
plan-time, creating a race condition where files created after planning but
before applying can be overwritten without --force. Replace the plan-time
f.exists check with a runtime target.exists() call in two places: first in the
skip logic condition (currently "if f.exists and not force:") and second in the
classification logic where you append to either created or overwritten lists.
This ensures files are skipped or properly classified based on their actual
existence at apply-time, preserving the --force safety guarantee.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 645f34b4-e6d3-4fce-b007-4f241aa0722b
📒 Files selected for processing (14)
.gitignoreCHANGELOG.mdREADME.mdaction/README.mddocs/BENCHMARK_CURRENT.mddocs/releases/v1.1.0.mdpyproject.tomlsrc/dorian/__init__.pysrc/dorian/cli.pysrc/dorian/commands.pysrc/dorian/init.pysrc/dorian/revalidate.pytests/test_init.pytests/test_render_md.py
Comment on lines
+218
to
+227
| for f in plan.files: | ||
| target = plan.repo_root / f.path | ||
| _ensure_within(plan.repo_root, target) | ||
| if f.exists and not force: | ||
| skipped.append(f.path) | ||
| continue | ||
| if not dry_run: | ||
| _atomic_write(target, f.content) | ||
| (overwritten if f.exists else created).append(f.path) | ||
| return ApplyResult( |
There was a problem hiding this comment.
Re-check target existence at apply-time to preserve --force safety
apply() currently gates writes using plan-time f.exists. If the file appears after planning but before applying, it can be overwritten without --force. Use runtime target.exists() for both skip logic and created/overwritten classification.
🔧 Suggested fix
def apply(plan: InitPlan, *, force: bool, dry_run: bool) -> ApplyResult:
@@
for f in plan.files:
target = plan.repo_root / f.path
_ensure_within(plan.repo_root, target)
- if f.exists and not force:
+ target_exists = target.exists()
+ if target_exists and not force:
skipped.append(f.path)
continue
if not dry_run:
_atomic_write(target, f.content)
- (overwritten if f.exists else created).append(f.path)
+ (overwritten if target_exists else created).append(f.path)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/dorian/init.py` around lines 218 - 227, The apply() function uses
f.exists which is determined at plan-time, creating a race condition where files
created after planning but before applying can be overwritten without --force.
Replace the plan-time f.exists check with a runtime target.exists() call in two
places: first in the skip logic condition (currently "if f.exists and not
force:") and second in the classification logic where you append to either
created or overwritten lists. This ensures files are skipped or properly
classified based on their actual existence at apply-time, preserving the --force
safety guarantee.
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Productizes the golden path for dorian as a deterministic CI/PR truth gate for AI-written code, and cuts v1.1.0. No breaking changes — command surface and output formatting only; the warrant format, checker grammar, exit codes, and trust semantics are unchanged.
What's in it
dorian init(new command) — first-run scaffolding so a new user reaches a sealed warrant in minutes: a born-verifiable starterclaims.json(aconfig-value:/path:claim that seals green), the change note it backs, and a version-pinned GitHub Action workflow. Writes files only (never runs a checker or executes code), repo-root confined, atomic, idempotent;--force/--dry-run/ global--json.revalidate --format md) — an explicitStatus:Blocked/Passed/Errored line, an aggregate trust-change counts table (derived from folds — labeled as changes this PR made, not absolute state), asealed in <artifact>.warrantline per artifact, and a verdict-keyedWhat to do:remediation. Deterministic and content-bounded as before; the existing per-claim table, fold transitions, recall section, and stats footer are unchanged..gitignorerule + a Hatch wheelexcludeso stray editor/cloud-sync… 2.pyduplicate files can never be tracked or packaged. (These were untracked local working-tree artifacts — never tracked in git, never in a CI build or on PyPI.)dorian init; newCHANGELOG.mdanddocs/releases/v1.1.0.md; 1.0.2 → 1.1.0 acrosspyproject.toml,__init__.py, the READMElatest:+ action refs,action/README.md, and theBENCHMARK_CURRENTstamp (figures unchanged — 1.1.0 touches no checker/binding/fold code; suites last executed at 1.0.2).What dorian is / is not
dorian verifies explicit, checkable claims about code using deterministic, token-free checks, and re-checks them across PRs. It does not prove an entire PR correct, and is not a runtime agent control plane, MCP gateway, sandbox, or proof of arbitrary correctness.
--deny-exec/--deny-shellandchecker_trust: baseare fail-closed policies, not sandboxes. dorian has exactly one documented, reproduced real cross-PR catch (encode/httpx) — not broad real-world validation.Tests & verification
uv run pytest— 883 passed (clean run; +8 newdorian inittests, + new PR-comment assertions)uv run ruff check+ruff format --check— cleanuv build(wheel + sdist) — builds; 33 modules, no… 2.pyinit→verifyexit 0, seals a warrantNote:
tests/test_bench_public_claim_synthesis.pycan flake under heavy concurrent CPU load (it runs a C3code:checker in a timed worker subprocess); it passes reliably otherwise. Pre-existing, unrelated to this PR.Security
Preserves deny-exec/deny-shell fail-closed behavior;
dorian initnever executes code, never writes outside the repo root, never overwrites without--force. No runtime network service, no telemetry, no model call in the verify path.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
dorian initcommand to quickly scaffold starterclaims.json, change notes, and GitHub Actions workflow for first-time setup.Chores