assertion-cli 0.5.0__tar.gz → 0.5.1__tar.gz

{assertion_cli-0.5.0 → assertion_cli-0.5.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: assertion-cli
-Version: 0.5.0
+Version: 0.5.1
 Summary: CLI for the Assertion API
 Requires-Python: >=3.13
 Description-Content-Type: text/markdown

{assertion_cli-0.5.0 → assertion_cli-0.5.1}/assertion_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: assertion-cli
-Version: 0.5.0
+Version: 0.5.1
 Summary: CLI for the Assertion API
 Requires-Python: >=3.13
 Description-Content-Type: text/markdown

{assertion_cli-0.5.0 → assertion_cli-0.5.1}/main.py

@@ -109,7 +109,11 @@ def _apply_marked_block(path: Path, body: str, repo_root: Path) -> None:
     if path.exists():
         current = path.read_text(encoding="utf-8")
         if pattern.search(current):
-            new_content = pattern.sub(marked_block, current)
+            # Replace via a callable so re.sub does NOT interpret backslash
+            # escapes (e.g. `\n`, `\g`) in the block — the activation template
+            # contains literal shell snippets like `printf '%s\n\n...'`, and a
+            # string replacement would mangle them, breaking init idempotency.
+            new_content = pattern.sub(lambda _match: marked_block, current)
         else:
             sep = (
                 ""

{assertion_cli-0.5.0 → assertion_cli-0.5.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "assertion-cli"
-version = "0.5.0"
+version = "0.5.1"
 description = "CLI for the Assertion API"
 readme = "README.md"
 requires-python = ">=3.13"

{assertion_cli-0.5.0 → assertion_cli-0.5.1}/templates/ACTIVATION.md

@@ -9,6 +9,13 @@ Both files are byte-identical. Read whichever your agent loads (or either one di
 
 1. **Every user message:** call `asrt prompt "<exact text of the message>"` before doing any other work for that turn. This is the verifier's source of truth for what the user asked for and how their direction evolves. Apply to every user turn, not just the first.
 2. **Checkpoint at trajectory-feedback moments**, not on every small change. On the first checkpoint of a session, run `asrt stacks`, pick the stack that fits this repo and the work (use the stack's `repo`, `name`, `description`, plus folder/branch/README signals), then run `asrt checkpoint --stack <id> "<summary>"`. Subsequent checkpoints in the same session don't need `--stack` — `asrt checkpoint "<summary>"` auto-continues. A whole feature build is a handful of checkpoints, not one per file.
-3. **Verify at completion** with `asrt verify`. If feedback requires changes, iterate and re-verify — do **not** drop back into the checkpoint loop. Once verify is clean, open a PR with `gh pr create` and include the session URL (from `asrt get-link`) in the body.
+3. **Verify at completion** with `asrt verify`. If feedback requires changes, iterate and re-verify — do **not** drop back into the checkpoint loop. Once verify is clean, open a PR and **put the Assertion session URL in the PR description** — this is required, not optional. Read the URL from `asrt get-link` (don't paste from memory) and include it on its own labeled line:
 
-Do not open a PR without a clean `asrt verify`.
+   ```
+   SESSION_URL=$(asrt get-link)
+   gh pr create --title "<title>" --body "$(printf '%s\n\n**Assertion verification:** %s\n' '<one-paragraph why>' "$SESSION_URL")"
+   ```
+
+   If a PR already exists for the branch, add the line with `gh pr edit --body` instead of opening a new one.
+
+Do not open a PR without a clean `asrt verify`, and do not open one whose description omits the session URL.

{assertion_cli-0.5.0 → assertion_cli-0.5.1}/templates/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: assertion-cli
-description: Use this skill in non-Plan mode whenever working in a repo that uses the Assertion CLI (`asrt`). It enforces the three-rule workflow — log every user message with `asrt prompt`, checkpoint at trajectory-feedback moments (not on every change), and verify only at completion before opening a PR. Applies to any coding agent reading this skill.
+description: Use this skill in non-Plan mode whenever working in a repo that uses the Assertion CLI (`asrt`). It enforces the three-rule workflow — log every user message with `asrt prompt`, checkpoint at trajectory-feedback moments (not on every change), and verify only at completion before opening a PR whose description includes the Assertion session URL. Applies to any coding agent reading this skill.
 ---
 
 # Assertion CLI
@@ -137,17 +137,46 @@ done
 
 `asrt verify-status` is a one-shot poll. It prints the current status, refreshes `.assertion/link`, and on terminal status writes screenshots under `.assertion/screenshots/<verification_id>/`. Exit code is `0` for `created` / `running` / `succeeded` and `1` for `failed`, so a polling loop can also branch on `$?`.
 
-`asrt get-link` prints the last session URL (e.g., for inclusion in PR descriptions).
+`asrt get-link` prints the last session URL — the verification record reviewers open from the PR. Every PR you open from an Assertion session must carry this URL in its description (see *Put the session URL in the PR description* below).
 
 **After status reports terminal, branch on the outcome:**
 
 | Outcome | What you do next |
 |---|---|
-| **Clean** (succeeded, no required changes) | Open a PR with `gh pr create`. Include the session URL (printed by verify/status; also `asrt get-link`) in the PR body so reviewers can see the verification record. |
+| **Clean** (succeeded, no required changes) | Open a PR and **put the session URL in the PR description** — mandatory, not optional. Use the exact command in *Put the session URL in the PR description* below. |
 | **Feedback or failed** (changes required) | Treat the feedback as authoritative. Apply the changes it calls for, then re-run `asrt verify` and poll `asrt verify-status` again. Repeat until clean. **Do not drop back into the checkpoint loop** — verify is the gate, not a checkpoint. |
 | **User sends a new message during iteration** | Log it with `asrt prompt` first (Rule 1 still applies). Address the new direction. Re-verify before opening the PR. |
 
-**Do not open a PR without a clean `asrt verify` / `asrt verify-status`.** Do not end a session with a failed/dirty verify unless the verification service itself is unavailable.
+### Put the session URL in the PR description (required)
+
+Every PR opened from an Assertion session **must** include the verification session URL in its description. That URL is the reviewer's link to the verification record; a PR without it is incomplete. Do not bury it in a PR comment and do not omit it.
+
+Read the URL with `asrt get-link` and pass it to `gh pr create` so it lands in the body — don't paste a URL from memory:
+
+```
+SESSION_URL=$(asrt get-link)
+gh pr create --title "<title>" --body "$(cat <<EOF
+<one-paragraph summary of *why*, not *what*>
+
+**Assertion verification:** $SESSION_URL
+EOF
+)"
+```
+
+If a PR already exists for this branch, edit its body instead of opening a new one:
+
+```
+gh pr edit --body "$(cat <<EOF
+<existing summary>
+
+**Assertion verification:** $(asrt get-link)
+EOF
+)"
+```
+
+Keep the `Assertion verification:` label line verbatim so reviewers and tooling can find the link. After creating or editing the PR, confirm the URL is actually in the rendered description with `gh pr view --json body`.
+
+**Do not open a PR without a clean `asrt verify` / `asrt verify-status`, and do not open one whose description omits the session URL.** Do not end a session with a failed/dirty verify unless the verification service itself is unavailable.
 
 ---
 
@@ -161,7 +190,7 @@ asrt checkpoint "..."                         # subsequent checkpoints — auto-
 asrt decision --yes|--no <ckpt-id>            # optional, on failed checkpoints only
 asrt verify                                   # submit verification (non-blocking)
 asrt verify-status                            # one-shot poll; loop with your own sleep
-asrt get-link                                 # retrieve the last session URL
+asrt get-link                                 # last session URL — must go in the PR description
 ```
 
 ## Environment
@@ -180,5 +209,6 @@ When running under a non-interactive harness (CI, benchmark runner, scripts):
    - Re-run `asrt checkpoint "<what you changed>" --json` (auto-continues the existing session).
    - Bound retries: stop after 3 attempts on the same failure mode, or when the same `reasoning` is returned twice in a row.
 4. `asrt verify --json` submits and exits with a one-line JSON `{"session_id", "url", "status": "submitted"}`. Poll `asrt verify-status --json` on your own cadence — terminal output is `{"session_id", "url", "status", "message", "summary", "screenshot_count"}` with exit `1` on `failed`, `0` otherwise. Choose the poll interval to fit your harness timeouts; do not block a single shell call on verify.
+5. If the harness opens a PR, the `url` field (equivalently `asrt get-link`) is the session URL that **must** appear in the PR description — same requirement as interactive mode. Read it from the JSON rather than reconstructing it.
 
 Do not mix `--json` output with human-rendered output in the same run. Pick one mode and stick with it.