feat(asset): make AssetCallbackFlag a required construction parameter

.claude/CLAUDE.md

@@ -40,6 +40,7 @@
 - **Worktree visibility:** Always tell the user which worktree (full path) you will work in as part of the plan. When finished, state where the changes live (worktree path and branch name).
 - **Commit authorship:** Always commit as Claude, not as the user. Use: `git -c user.name="Claude (Opus)" -c user.email="noreply@anthropic.com" -c commit.gpgsign=false commit -m "message"`
 - **Commit frequency:** Always commit at the end of each task. Avoid single commits that span multiple unrelated changes.
+- **Responding to PR review:** When addressing review feedback on a pushed PR, add new commits on top of the branch (e.g. `fix: address review comments`). NEVER amend, squash, or otherwise rewrite already-pushed commits to incorporate review changes, and NEVER force-push the branch to do so - this destroys the diff reviewers rely on to see what changed since their review. The only time a force-push is acceptable is when the branch must be rebased onto an updated base (or a PR lower in a stack changed); that is a base update, not a review response, and should be called out explicitly.
 
 ## Output Formatting
 

.claude/README.md

@@ -0,0 +1,56 @@
+# Claude Code in this repo
+
+The `/work` command, lifecycle hooks, review agents, skills, and settings are
+all committed here under `.claude/`, so they come with the clone - no Claude
+config to copy in. The hooks need the usual toolchain on the host: Python 3,
+the `claude` and `gh` CLIs (authenticated), and `make` / the Rust toolchain.
+
+## The `/work` flow
+
+1. **Clone the repo.** The committed `.claude/` wires up hooks, skills,
+   agents, and the command automatically.
+2. **Start a session** in bypass-permissions mode so Claude isn't stopped for
+   per-action approvals:
+
+   ```bash
+   claude --permission-mode bypassPermissions
+   ```
+
+   Recommended: add `--worktree` so the session runs in its own git worktree
+   (parallel agents don't collide) and `--tmux` so it runs inside tmux (the run
+   survives disconnects on a remote/cloud host; `--tmux` requires `--worktree`).
+   For example:
+
+   ```bash
+   claude --permission-mode bypassPermissions --worktree issue-1234 --tmux
+   ```
+3. **Run `/work <issue-number>`** and plan it out together. The command starts
+   in plan mode and writes no code until you approve. Base defaults to `next`
+   (`--base <branch>` to override).
+4. **Let it work.** Claude implements the plan and opens a **draft** PR when
+   it's ready.
+5. **Review the PR on GitHub.** If changes are needed, tell Claude to apply
+   them. When the feedback reflects a reusable convention, also have Claude
+   codify it as a skill or hook under `.claude/` - ideally as a separate PR for
+   the Claude setup, kept apart from the feature work.
+
+## Guardrails
+
+Hooks in `settings.json` enforce quality at the commit, push, and PR boundaries:
+
+- `pre_commit_lint` - runs `make lint` before any commit.
+- `pre_push_test` - runs `make test` before any push.
+- `pre_push_review` - runs the code-reviewer and security-reviewer agents
+  before any push; blocks on Critical/Important/Warning findings.
+- `pre_pr_draft` - every PR must be created with `--draft`; a human promotes
+  it to ready-for-review.
+- `post_pr_create_changelog` - classifies the diff and either requires a
+  CHANGELOG entry or applies the `no changelog` label.
+
+## Contents
+
+- `commands/work.md` - the `/work` command.
+- `hooks/` - the lifecycle hooks above (plus their tests).
+- `agents/` - code-reviewer, security-reviewer, changelog-manager.
+- `skills/` - Miden Assembly (`.masm`) authoring conventions.
+- `settings.json` - wires the hooks to tool events.

.claude/agents/changelog-manager.md

@@ -20,19 +20,20 @@ You receive a prompt like: `Check changelog for PR #N (URL)`
    ```
    gh pr view <N> --json labels --jq '.labels[].name'
    ```
-2. Check if CHANGELOG.md is already modified in the diff:
+2. Check if the PR already modifies CHANGELOG.md:
    ```
-   git diff origin/next...HEAD -- CHANGELOG.md
+   gh pr diff <N> --name-only | grep -qx CHANGELOG.md
    ```
 
 If either condition is met, output `SKIP: already handled` and stop.
 
 ## Step 2: Analyze the Diff
 
-Run:
+Classify the PR's own diff (not a local `git diff`):
 ```
-git diff origin/next...HEAD -- ':(exclude)CHANGELOG.md'
+gh pr diff <N>
 ```
+Disregard changes to CHANGELOG.md itself.
 
 ## Step 3: Classify
 

.claude/agents/code-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: code-reviewer
-description: Staff engineer code reviewer evaluating changes across correctness, readability, architecture, API design, and performance. Spawned automatically before push.
+description: Staff engineer code reviewer evaluating changes across correctness, readability, architecture, API design, and performance. Spawned automatically after each commit and before PR creation.
 model: opus
 effort: max
 tools: Read, Grep, Glob, Bash
@@ -13,11 +13,15 @@ You are an experienced Staff Engineer conducting a thorough code review with fre
 
 ## Step 1: Gather Context
 
-Run `git diff @{upstream}...HEAD`. If no upstream is set, resolve the default
-branch with `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'`
-and run `git diff origin/<branch>...HEAD`.
+Your prompt names the diff range under review (e.g. `HEAD~1..HEAD` for a
+single commit, or `<merge-base>..HEAD` for a whole PR). See exactly what
+changed:
 
-For every file in the diff, read the **full file** - not just the changed lines. Bugs hide in how new code interacts with existing code.
+```
+git diff <the range given in your prompt>
+```
+
+Don't review the diff in isolation. Read enough surrounding context to see how the change interacts with existing code - the rest of the file where relevant, plus its callers and callees. Bugs hide in those interactions. Confirm every finding against the current code before reporting it - never raise an issue the code already addresses.
 
 ## Step 2: Review Tests First
 
@@ -74,6 +78,15 @@ Categorize every finding:
 
 **Nit** - Worth improving (naming, style, minor readability, optional optimization)
 
+### Documented, intentional incompleteness
+
+A change may deliberately ship incomplete behavior as one stage of a larger, planned effort (a skeleton, placeholder, or stub). When the incompleteness is **all** of:
+- explicitly documented in the code (a doc comment or module note stating what is not yet implemented),
+- clearly scoped and warned about (the docs say what not to rely on and reference the follow-up work), and
+- not wired into any path that depends on the missing behavior being correct,
+
+then the incompleteness itself is NOT a Critical or Important finding - the change is complete for what it claims to be. Treat it as a Nit at most, or acknowledge the clear documentation under "What's Done Well". Escalate only when the documentation is missing, inaccurate, or misleading, or when the incomplete code is actually relied upon as if it were complete. Distinguish "incomplete but correct, documented, and self-contained" from "broken or silently incomplete".
+
 ## Output Format
 
 ```
@@ -105,8 +118,9 @@ Categorize every finding:
 5. If uncertain about something, say so and suggest investigation rather than guessing
 6. Be direct. "This will panic when the vec is empty" not "this might possibly be a concern"
 7. New code without tests is always a finding
+8. Respect the user's intent. Your prompt may name what the user asked for this session - treat deliberate, explicitly-requested choices as intended, not mistakes, and don't recommend reversing them. Intent does not excuse a real defect: a genuine correctness bug or exploitable risk stays Critical or Important even when requested. Downgrade to a Nit only when your objection is stylistic or defensive-programming preference, not a real defect.
 
-**All findings (Critical, Important, and Nit) block the merge.** Every issue must be addressed before pushing.
+**Critical and Important findings block the merge; Nits are surfaced but do not block.** Address the blocking findings before pushing.
 
-If you find any issues at any severity level, start your final response with `BLOCK:` followed by the review.
-If there are zero findings, start your final response with `APPROVE:` followed by the review.
+If you find any Critical or Important issues, start your final response with `BLOCK:` followed by the review.
+If there are none (only Nits, or nothing), start your final response with `APPROVE:` followed by the review.

.claude/agents/security-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: security-reviewer
-description: Adversarial security reviewer that tries to break code through two hostile personas - Adversary and Auditor. Spawned automatically before push.
+description: Adversarial security reviewer that tries to break code through two hostile personas - Adversary and Auditor. Spawned automatically after each commit and before PR creation.
 model: opus
 effort: max
 tools: Read, Grep, Glob, Bash
@@ -13,11 +13,15 @@ You are a hostile reviewer. Your job is to break this code before an attacker do
 
 ## Step 1: Gather the Changes
 
-Run `git diff @{upstream}...HEAD`. If no upstream is set, resolve the default
-branch with `gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'`
-and run `git diff origin/<branch>...HEAD`.
+Your prompt names the diff range under review (e.g. `HEAD~1..HEAD` for a
+single commit, or `<merge-base>..HEAD` for a whole PR). See exactly what
+changed:
 
-For every file in the diff, read the **full file**. Vulnerabilities hide in how new code interacts with existing code, not just in the diff itself.
+```
+git diff <the range given in your prompt>
+```
+
+Don't review the diff in isolation. Read enough surrounding context to see how the change interacts with existing code - the rest of the file where relevant, plus its callers and callees. Vulnerabilities hide in those interactions. Confirm every finding against the current code before reporting it - never raise an issue the code already addresses.
 
 ## Step 2: Run Both Personas
 
@@ -79,6 +83,15 @@ After both personas report:
 
 **NOTE** - Minor improvement opportunity or fragile assumption worth documenting.
 
+### Documented, intentional incompleteness
+
+Some changes deliberately ship a security-relevant placeholder as one stage of planned work (e.g., a verifier that does not yet bind certain data, a check that is stubbed). When such a limitation is **all** of:
+- explicitly documented in the code (a doc comment or module note stating exactly what is not yet enforced),
+- accompanied by a clear warning against misuse (e.g., "must not be relied on at a trust boundary") and a reference to the follow-up that will close it, and
+- not actually reachable from a trust boundary in this change (no caller relies on the missing guarantee),
+
+then classify it as a NOTE, not CRITICAL or WARNING. Surfacing it keeps it visible without blocking a correctly-staged change. The finding is the ABSENCE or INADEQUACY of that documentation, or the incomplete code being wired into a real trust boundary - not the incompleteness itself. If the limitation is undocumented, the warning is missing or misleading, or a caller already depends on the unenforced guarantee, keep the CRITICAL/WARNING severity.
+
 ## Output Format
 
 ```
@@ -99,19 +112,20 @@ After both personas report:
 [2-3 sentences: overall risk profile and the single most important thing to fix]
 ```
 
-**All findings (Critical, Warning, and Note) block the merge.** Every issue must be addressed before pushing.
+**Critical and Warning findings block the merge; Notes are surfaced but do not block.** Address the blocking findings before pushing.
 
 **Verdicts:**
-- **BLOCK** - Any findings at any severity level. Do not merge until addressed.
-- **CLEAN** - Zero findings. Safe to merge.
+- **BLOCK** - Any Critical or Warning finding. Do not merge until addressed.
+- **CLEAN** - No Critical or Warning findings (Notes, if any, are surfaced but do not block). Safe to merge.
 
 ## Anti-Patterns - Do NOT Do These
 
 - **"LGTM, no issues found"** - Be skeptical if you found nothing, but don't fabricate findings. If a change is genuinely clean, use the CLEAN verdict.
 - **Pulling punches** - "This might possibly be a minor concern" is useless. Say what's wrong.
 - **Restating the diff** - "This function was added" is not a finding. What's WRONG with it?
 - **Cosmetic-only findings** - Reporting style issues while missing a panic is worse than no review.
-- **Reviewing only changed lines** - Read the full file. The bug is in the interaction.
+- **Reviewing only changed lines** - Read the surrounding context (callers, callees, the rest of the file where relevant). The bug is in the interaction.
+- **Contradicting user intent** - Your prompt may name what the user asked for. Treat deliberate, explicitly-requested choices as intended; don't push to reverse them. But intent does not downgrade real risk: if a requested choice is genuinely exploitable, keep it Critical or Warning so it blocks. Drop it to a Note only when your objection is defensive-programming hardening or a non-exploitable weakness.
 
 ## Breaking the Self-Review Trap
 
@@ -122,5 +136,5 @@ You may share the same mental model as the code's author. To break this:
 4. Assume every external call will fail
 5. Ask: "If I deleted this change entirely, what would break?" If nothing, the change might be unnecessary.
 
-If you find any findings at any severity level, start your final response with `BLOCK:` followed by the review.
-If there are zero findings, start with `CLEAN:` followed by the review.
+If you find any Critical or Warning findings, start your final response with `BLOCK:` followed by the review.
+If there are none (only Notes, or nothing), start with `CLEAN:` followed by the review.

.claude/commands/work.md

@@ -0,0 +1,14 @@
+---
+description: Plan and implement a GitHub issue, then open a draft PR (base defaults to next)
+argument-hint: <issue-number> [--base <branch>]
+allowed-tools: Bash, Read, Edit, Write, Grep, Glob, Task
+---
+
+Work on a GitHub issue and open a **draft** PR.
+
+`$ARGUMENTS`: an issue number, plus optional `--base <branch>` (defaults to `next`).
+
+1. Read the issue: `gh issue view <number>`.
+2. **Start in plan mode.** Produce an implementation plan and wait for approval before writing any code.
+3. After approval: implement per `.claude/CLAUDE.md` (worktree, branch, commit conventions).
+4. Open the draft PR against the base branch: `gh pr create --draft --base <branch> --body "Closes #<number> ..."`. Report the PR URL.

.claude/hooks/_hookutils.py

@@ -10,11 +10,16 @@
 from __future__ import annotations
 
 import json
+import re
 import subprocess
 import sys
 from pathlib import Path
 from typing import Any
 
+# Strips harness-injected <system-reminder> blocks from user message text so
+# only what the human actually typed is surfaced to the reviewers.
+_SYSTEM_REMINDER = re.compile(r"<system-reminder>.*?</system-reminder>", re.DOTALL)
+
 
 def repo_root() -> Path | None:
     """Return the absolute path of the current git worktree's top
@@ -83,3 +88,73 @@ def read_command(stdin: Any = None) -> str | None:
     input (so the hook can fail open with `sys.exit(0)`).
     """
     return command_from_payload(read_payload(stdin))
+
+
+def recent_user_prompts(
+    transcript_path: Any,
+    max_messages: int = 12,
+    max_chars: int = 3000,
+) -> str | None:
+    """Return the human-typed prompts from a session transcript as a
+    bulleted, most-recent-first string, or None if unavailable/empty.
+
+    Reads the JSONL transcript named by a hook payload's `transcript_path`,
+    keeps only genuine user turns (dropping tool results, tool calls, and
+    harness-injected `<system-reminder>` content), and caps the output so the
+    reviewers get the user's intent without the whole conversation.
+    """
+    if not isinstance(transcript_path, str) or not transcript_path:
+        return None
+    try:
+        lines = Path(transcript_path).read_text().splitlines()
+    except OSError:
+        return None
+
+    prompts: list[str] = []
+    for line in lines:
+        try:
+            entry = json.loads(line)
+        except (json.JSONDecodeError, ValueError):
+            continue
+        if not isinstance(entry, dict) or entry.get("type") != "user" or entry.get("isMeta"):
+            continue
+        message = entry.get("message")
+        if not isinstance(message, dict):
+            continue
+        text = _user_text(message.get("content"))
+        if text:
+            prompts.append(text)
+    if not prompts:
+        return None
+
+    out: list[str] = []
+    total = 0
+    for prompt in reversed(prompts):  # most recent first
+        if len(prompt) > 500:
+            prompt = prompt[:500].rstrip() + "..."
+        bullet = f"- {prompt}"
+        if out and total + len(bullet) > max_chars:
+            break
+        out.append(bullet)
+        total += len(bullet)
+        if len(out) >= max_messages:
+            break
+    return "\n".join(out)
+
+
+def _user_text(content: Any) -> str | None:
+    """Extract human text from a user message's `content`, dropping
+    tool_result/tool_use blocks and `<system-reminder>` noise. Returns None
+    if nothing human-authored remains."""
+    if isinstance(content, str):
+        parts = [content]
+    elif isinstance(content, list):
+        parts = [
+            block["text"]
+            for block in content
+            if isinstance(block, dict) and block.get("type") == "text" and isinstance(block.get("text"), str)
+        ]
+    else:
+        return None
+    cleaned = _SYSTEM_REMINDER.sub("", "\n".join(parts)).strip()
+    return cleaned or None