rung-cli 0.1.2__tar.gz → 0.1.3__tar.gz

{rung_cli-0.1.2 → rung_cli-0.1.3}/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "rung",
   "description": "Set up Rung in a repository: record tests and security scans as checks, gate pull requests in CI, and teach coding agents the verification rules.",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "author": { "name": "CalQuity" },
   "homepage": "https://github.com/CalQuity/rung",
   "repository": "https://github.com/CalQuity/rung",

{rung_cli-0.1.2 → rung_cli-0.1.3}/CHANGELOG.md

@@ -3,7 +3,19 @@
 All notable changes to Rung. The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and versions follow the policy in [CONTRIBUTING.md](CONTRIBUTING.md#versioning).
 
-## 0.1.2 (unreleased)
+## 0.1.3 (2026-11-01)
+
+### Fixed
+- `rung draft property`: a plain `assert` the model wrote that fails on the real code is now a
+  finding for a person, not a broken test. Before, a failure without Hypothesis's "Falsifying
+  example" marker was sent back to the model to rewrite, up to four times, which could hide the bug
+  the tests had found. A mutant that stops the module compiling is still not counted as caught.
+
+### Documentation
+- The README describes the runtime verification kit: the drive script, the `FEATURES.md` feature
+  map, the project verification skill for coding agents, and the recordings each run leaves.
+
+## 0.1.2 (2026-11-01)
 
 The first release on PyPI, as `rung-cli`.
 

{rung_cli-0.1.2 → rung_cli-0.1.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: rung-cli
-Version: 0.1.2
+Version: 0.1.3
 Summary: An opinionated verification ladder for software written with coding agents: architecture rules, runtime evidence, properties, TLA+ and Lean, and an evidence ledger that expires when code changes.
 Project-URL: Homepage, https://github.com/CalQuity/rung
 Project-URL: Documentation, https://github.com/CalQuity/rung/tree/main/docs
@@ -122,6 +122,30 @@ A refund never exceeds the original charge, even under concurrent retries.
 `rung laws` shows whether each law currently **holds**: approved, enforced, and every enforcing
 verdict fresh. Agents may propose laws; only people approve them.
 
+## A verification kit for your running app
+
+`rung draft runtime --intent "apply a coupon at checkout and see the total update"` gives your
+project a verification kit, written by the model and registered as a check only once it has worked
+against the real app:
+
+- **`.rung/verify/drive.py`**, a script that starts the app on a free port, drives a feature the way
+  a user does (Playwright for web UIs, HTTP or CLI calls otherwise) and asserts on what a user would
+  see. It never calls internal functions or test-only endpoints.
+- **`.rung/verify/FEATURES.md`**, a feature map: for each user-facing feature, how a user reaches it,
+  how the script drives it, what observable state proves it works, and the gotchas (seed data,
+  logins, flaky spots).
+- **A project verification skill** (`.claude/skills/verify-<project>/`) that tells the project's
+  coding agents to drive the app after any user-facing change, extend the script and feature map
+  when they add a feature, and treat a failure as a product bug rather than weaken the script.
+- **Recordings.** Every run writes its evidence to a fresh directory: a video of the browser session
+  (`--require .webm` demands one), screenshots, request and response logs, a transcript and a
+  structured `result.json`. Their hashes go into the verdict, which stays valid only while the code
+  it covers is unchanged.
+
+Where a script cannot reach a feature (a login flow, a native app), an agent can drive it with its
+own browser or computer-use tool and record it with `rung attest <check> <files> --by <tool>`. Such
+evidence is recorded with who captured it and is never re-run, so it is weaker than a script.
+
 ## Property tests that are tested themselves
 
 `rung draft property pricing.py --intent "a total is never negative and equals the discounted sum"`
@@ -171,7 +195,7 @@ jobs:
         with:
           fetch-depth: 0
           persist-credentials: false
-      - uses: CalQuity/rung@v0.1.2
+      - uses: CalQuity/rung@v0.1.3
 ```
 
 The action runs the checks a pull request touches against its merge base. It keeps a single
@@ -186,7 +210,7 @@ To run the same check before every push, add Rung to `.pre-commit-config.yaml`:
 
 ```yaml
 - repo: https://github.com/CalQuity/rung
-  rev: v0.1.2
+  rev: v0.1.3
   hooks:
     - id: rung-check
 ```

{rung_cli-0.1.2 → rung_cli-0.1.3}/README.md

@@ -104,6 +104,30 @@ A refund never exceeds the original charge, even under concurrent retries.
 `rung laws` shows whether each law currently **holds**: approved, enforced, and every enforcing
 verdict fresh. Agents may propose laws; only people approve them.
 
+## A verification kit for your running app
+
+`rung draft runtime --intent "apply a coupon at checkout and see the total update"` gives your
+project a verification kit, written by the model and registered as a check only once it has worked
+against the real app:
+
+- **`.rung/verify/drive.py`**, a script that starts the app on a free port, drives a feature the way
+  a user does (Playwright for web UIs, HTTP or CLI calls otherwise) and asserts on what a user would
+  see. It never calls internal functions or test-only endpoints.
+- **`.rung/verify/FEATURES.md`**, a feature map: for each user-facing feature, how a user reaches it,
+  how the script drives it, what observable state proves it works, and the gotchas (seed data,
+  logins, flaky spots).
+- **A project verification skill** (`.claude/skills/verify-<project>/`) that tells the project's
+  coding agents to drive the app after any user-facing change, extend the script and feature map
+  when they add a feature, and treat a failure as a product bug rather than weaken the script.
+- **Recordings.** Every run writes its evidence to a fresh directory: a video of the browser session
+  (`--require .webm` demands one), screenshots, request and response logs, a transcript and a
+  structured `result.json`. Their hashes go into the verdict, which stays valid only while the code
+  it covers is unchanged.
+
+Where a script cannot reach a feature (a login flow, a native app), an agent can drive it with its
+own browser or computer-use tool and record it with `rung attest <check> <files> --by <tool>`. Such
+evidence is recorded with who captured it and is never re-run, so it is weaker than a script.
+
 ## Property tests that are tested themselves
 
 `rung draft property pricing.py --intent "a total is never negative and equals the discounted sum"`
@@ -153,7 +177,7 @@ jobs:
         with:
           fetch-depth: 0
           persist-credentials: false
-      - uses: CalQuity/rung@v0.1.2
+      - uses: CalQuity/rung@v0.1.3
 ```
 
 The action runs the checks a pull request touches against its merge base. It keeps a single
@@ -168,7 +192,7 @@ To run the same check before every push, add Rung to `.pre-commit-config.yaml`:
 
 ```yaml
 - repo: https://github.com/CalQuity/rung
-  rev: v0.1.2
+  rev: v0.1.3
   hooks:
     - id: rung-check
 ```

{rung_cli-0.1.2 → rung_cli-0.1.3}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "rung-cli"
-version = "0.1.2"
+version = "0.1.3"
 description = "An opinionated verification ladder for software written with coding agents: architecture rules, runtime evidence, properties, TLA+ and Lean, and an evidence ledger that expires when code changes."
 readme = "README.md"
 license = "Apache-2.0"

{rung_cli-0.1.2 → rung_cli-0.1.3}/skills/setup/SKILL.md

@@ -75,7 +75,7 @@ jobs:
         with:
           fetch-depth: 0
           persist-credentials: false
-      - uses: CalQuity/rung@v0.1.2
+      - uses: CalQuity/rung@v0.1.3
 ```
 
 Install whatever the checks need (language runtimes, scanners) in steps before `CalQuity/rung`.

{rung_cli-0.1.2 → rung_cli-0.1.3}/src/rung/__init__.py

@@ -1,3 +1,3 @@
 """Rung: an opinionated verification ladder for software written with coding agents."""
 
-__version__ = "0.1.2"
+__version__ = "0.1.3"

{rung_cli-0.1.2 → rung_cli-0.1.3}/src/rung/drafting/property.py

@@ -51,7 +51,11 @@ GOOD_ENOUGH = 0.5  # share of viable mutants a property file must catch
 CANARY = "rung-canary-7f3a"
 DRAFTS_DIR = Path(".rung") / "cache" / "drafts"
 
-_FAILING_EXAMPLE = re.compile(r"Falsifying example|Failing test case|Counterexample:|Property failed after", re.I)
+# A run that never got as far as running tests: a module that does not compile or import.
+_BUILD_FAILED = re.compile(
+    r"Transform failed|Cannot find module|ERR_MODULE_NOT_FOUND|error TS\d+|SyntaxError: |ERROR collecting|"
+    r"ImportError while importing test module"
+)
 # Errors that mean the test's own code is broken, when the failure happens inside the test file.
 _BROKEN = {"NameError", "ImportError", "ModuleNotFoundError", "SyntaxError", "IndentationError", "ReferenceError",
            "AttributeError", "TypeError", "UnboundLocalError"}  # fmt: skip
@@ -163,15 +167,17 @@ def passed_count(output: str) -> int:
 
 
 def classify(returncode: int, output: str, sources: list[str], test_file: str) -> str:
-    """pass, finding (a property failed on the code) or error (the test itself is broken, or ran nothing).
+    """pass, finding (a test failed on the code) or error (the test itself is broken, or ran nothing).
 
-    `sources` and `test_file` are file names, used to tell where a failure happened: an error raised in
-    the code under test is a finding, even a `NameError`; a non-assertion error raised in the test file
-    is a broken test; anything Rung cannot place is a finding, for a person to judge.
+    Exit status 1 means tests ran and failed. That is a finding, whether or not the failure came with
+    a generated example: a plain `assert` the model wrote can catch the bug just as well. The test is
+    broken instead when the run could not build or import, or when a non-assertion error (a typo, a
+    wrong call) is raised in the test file itself. An error raised in the code under test is always a
+    finding, even a `NameError`; anything Rung cannot place goes to a person as a finding.
     """
     if returncode == 0:
         return "pass" if passed_count(output) > 0 else "error"
-    if returncode != 1 or not _FAILING_EXAMPLE.search(output):
+    if returncode != 1 or _BUILD_FAILED.search(output):
         return "error"
     py = _PY_LOCATION.findall(output)
     js = _JS_LOCATION.findall(output)

{rung_cli-0.1.2 → rung_cli-0.1.3}/tests/test_property.py

@@ -95,6 +95,10 @@ def test_classify_separates_findings_from_broken_tests() -> None:
     assert c(1, broken, ["pricing.ts"], "p.test.ts") == "error"
     assert c(1, failed + "    at total (src/pricing.ts:4:9)", ["pricing.ts"], "p.test.ts") == "finding"
     assert c(2, "ERROR collecting", src, test) == "error"
+    # A plain assert the model wrote, failing on the real code, is a finding too (no generated example).
+    assert c(1, "E       assert -1 == 0\ntest_p.py:12: AssertionError\n1 failed", src, test) == "finding"
+    # A mutant that stops the module compiling is not a caught bug.
+    assert c(1, "Transform failed with 1 error:\nsrc/pricing.ts:3:10", ["pricing.ts"], "p.test.ts") == "error"
 
 
 def test_a_property_no_mutant_can_fail_is_sent_back_and_a_strong_one_is_kept(pricing: Path) -> None:

{rung_cli-0.1.2 → rung_cli-0.1.3}/uv.lock

@@ -473,7 +473,7 @@ wheels = [
 
 [[package]]
 name = "rung-cli"
-version = "0.1.2"
+version = "0.1.3"
 source = { editable = "." }
 
 [package.dev-dependencies]