blitz-cli 0.17.0__tar.gz → 0.17.1__tar.gz

blitz_cli-0.17.1/.github/workflows/secret-scan.yml

@@ -0,0 +1,72 @@
+name: Secret scan
+
+on:
+  workflow_call:
+    inputs:
+      blitz-version:
+        description: "Pinned blitz-cli version to install. Empty installs the latest release."
+        type: string
+        required: false
+        default: ""
+      python-version:
+        description: "Python runtime version for the scanner."
+        type: string
+        required: false
+        default: "3.12"
+  pull_request:
+  push:
+    branches: [main]
+
+jobs:
+  secrets:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - name: Check out full history
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: ${{ inputs.python-version || '3.12' }}
+
+      - name: Install blitz-cli
+        env:
+          BLITZ_VERSION: ${{ inputs.blitz-version }}
+        run: |
+          # Dogfood: when the checked-out repo IS blitz-cli, scan with its own
+          # current source rather than the published release, so a PR that
+          # changes the scanner is checked by the code it ships.
+          if grep -q '^name = "blitz-cli"' pyproject.toml 2>/dev/null; then
+            pip install -e .
+          elif [ -n "$BLITZ_VERSION" ]; then
+            pip install "blitz-cli==$BLITZ_VERSION"
+          else
+            pip install blitz-cli
+          fi
+
+      - name: Resolve commit range
+        id: range
+        env:
+          EVENT_NAME: ${{ github.event_name }}
+          PR_BASE: ${{ github.event.pull_request.base.sha }}
+          PR_HEAD: ${{ github.event.pull_request.head.sha }}
+          PUSH_BEFORE: ${{ github.event.before }}
+          PUSH_AFTER: ${{ github.event.after }}
+        run: |
+          if [ "$EVENT_NAME" = "pull_request" ]; then
+            echo "range=${PR_BASE}..${PR_HEAD}" >> "$GITHUB_OUTPUT"
+          elif [ "$PUSH_BEFORE" = "0000000000000000000000000000000000000000" ]; then
+            echo "range=${PUSH_AFTER}" >> "$GITHUB_OUTPUT"
+          else
+            echo "range=${PUSH_BEFORE}..${PUSH_AFTER}" >> "$GITHUB_OUTPUT"
+          fi
+
+      - name: Scan range for secrets
+        env:
+          RANGE: ${{ steps.range.outputs.range }}
+        run: |
+          blitz secrets scan --range "$RANGE"

blitz_cli-0.17.1/.github/workflows/tests.yml

@@ -0,0 +1,41 @@
+name: Tests
+
+# Run the unit suite on every pull request and on main.
+on:
+  pull_request:
+  push:
+    branches: [main]
+
+# A newer push to the same branch makes an in-flight run redundant.
+concurrency:
+  group: tests-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  pytest:
+    runs-on: ubuntu-latest
+    strategy:
+      # Report every version's result; one failure should not mask the others.
+      fail-fast: false
+      matrix:
+        # 3.11 is the floor declared by requires-python and the runtime the
+        # locker-room core image ships, so it is the version a change has to
+        # keep working. Add versions here to widen coverage.
+        python-version: ["3.11"]
+    steps:
+      - name: Check out
+        uses: actions/checkout@v4
+
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: actions/setup-python@v5
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install
+        # pytest is not a package dependency, so it is installed explicitly.
+        run: |
+          python -m pip install --upgrade pip
+          pip install -e . pytest
+
+      - name: Run tests
+        run: pytest -q

blitz_cli-0.17.1/.github/workflows/vuln-scan.yml

@@ -0,0 +1,141 @@
+name: Vulnerability scan
+
+on:
+  workflow_call:
+    inputs:
+      python-extras:
+        description: "Extras to install for the blocking scan, e.g. \"secrets\". Empty installs the base dependencies only."
+        type: string
+        required: false
+        default: ""
+      python-extras-advisory:
+        description: "Extras scanned for visibility only -- findings are reported but never fail the build."
+        type: string
+        required: false
+        default: ""
+      python-version:
+        description: "Python runtime used to resolve the dependency tree."
+        type: string
+        required: false
+        default: "3.12"
+      severity:
+        description: "Comma-separated severities that fail the build."
+        type: string
+        required: false
+        default: "HIGH,CRITICAL"
+  pull_request:
+  push:
+    branches: [main]
+
+permissions:
+  contents: read
+
+jobs:
+  scan:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: ${{ inputs.python-version || '3.12' }}
+
+      # A PEP 621 project with no lockfile has no dependency tree Trivy can read:
+      # it does not parse pyproject.toml, and its installed-package analyzer runs
+      # only on image/rootfs targets, never on a filesystem scan. So resolve the
+      # deps into a venv and freeze them to a pinned requirements.txt, which the
+      # filesystem scan does parse. This also gets the transitive deps scanned,
+      # which is where most advisories actually land. Repos with no pyproject (the
+      # locker-room node pip-installs inside its Dockerfile) skip this and are
+      # covered by their own image scan.
+      - name: Resolve Python dependencies
+        env:
+          EXTRAS: ${{ inputs.python-extras }}
+        run: |
+          if [ ! -f pyproject.toml ]; then
+            echo "No pyproject.toml -- nothing to resolve; lockfile scanning still applies."
+            exit 0
+          fi
+          # Dogfood: when the checked-out repo IS blitz-cli, `secrets` is the only
+          # extra that belongs in the blocking set. `train` is handled below.
+          if [ -z "$EXTRAS" ] && grep -q '^name = "blitz-cli"' pyproject.toml; then
+            EXTRAS="secrets"
+          fi
+          python -m venv /tmp/vulnscan-venv
+          if [ -n "$EXTRAS" ]; then
+            echo "Installing .[$EXTRAS]"
+            /tmp/vulnscan-venv/bin/pip install -q ".[$EXTRAS]"
+          else
+            /tmp/vulnscan-venv/bin/pip install -q .
+          fi
+          # Written into the workspace so the single fs scan below picks it up
+          # alongside any committed lockfiles. CI-only; never committed.
+          mkdir -p .vulnscan
+          /tmp/vulnscan-venv/bin/pip freeze --exclude-editable > .vulnscan/requirements.txt
+          echo "Resolved $(wc -l < .vulnscan/requirements.txt) packages for scanning."
+
+      # One filesystem scan covers the resolved requirements above and any
+      # committed lockfiles (package-lock.json in the locker-room UI).
+      # --ignore-unfixed keeps the gate actionable: an advisory with no released
+      # fix is not something a PR author can resolve, so it stays out of the way.
+      - name: Scan dependencies
+        uses: aquasecurity/trivy-action@v0.36.0
+        with:
+          scan-type: fs
+          scan-ref: .
+          scanners: vuln
+          severity: ${{ inputs.severity || 'HIGH,CRITICAL' }}
+          ignore-unfixed: true
+          exit-code: "1"
+          format: table
+
+  # The heavy ML extras get their own check so their findings are visible at a
+  # glance in the PR rather than buried in another job's log. It reports but never
+  # blocks: the current pins carry known HIGH/CRITICAL advisories (mostly mlflow
+  # tracking-server RCE/traversal issues) whose fixes are major breaking upgrades
+  # -- mlflow 2.x->3.x and transformers 4.x->5.x -- so gating on them would mean a
+  # permanently red CI that no individual PR can turn green.
+  advisory:
+    runs-on: ubuntu-latest
+    continue-on-error: true
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: ${{ inputs.python-version || '3.12' }}
+
+      - name: Resolve advisory extras
+        id: advisory
+        env:
+          EXTRAS: ${{ inputs.python-extras-advisory }}
+        run: |
+          if [ ! -f pyproject.toml ]; then exit 0; fi
+          if [ -z "$EXTRAS" ] && grep -q '^name = "blitz-cli"' pyproject.toml; then
+            EXTRAS="train"
+          fi
+          if [ -z "$EXTRAS" ]; then
+            echo "No advisory extras configured."
+            exit 0
+          fi
+          python -m venv /tmp/vulnscan-advisory-venv
+          echo "Installing .[$EXTRAS]"
+          /tmp/vulnscan-advisory-venv/bin/pip install -q ".[$EXTRAS]"
+          # Scanned from its own directory so this job shares no state with the
+          # blocking scan and cannot affect its result.
+          mkdir -p .vulnscan-advisory
+          /tmp/vulnscan-advisory-venv/bin/pip freeze --exclude-editable \
+            > .vulnscan-advisory/requirements.txt
+          echo "present=true" >> "$GITHUB_OUTPUT"
+
+      - name: Scan advisory extras
+        if: steps.advisory.outputs.present == 'true'
+        uses: aquasecurity/trivy-action@v0.36.0
+        with:
+          scan-type: fs
+          scan-ref: .vulnscan-advisory
+          scanners: vuln
+          severity: ${{ inputs.severity || 'HIGH,CRITICAL' }}
+          ignore-unfixed: true
+          exit-code: "1"
+          format: table

{blitz_cli-0.17.0 → blitz_cli-0.17.1}/PKG-INFO

@@ -1,10 +1,10 @@
 Metadata-Version: 2.4
 Name: blitz-cli
-Version: 0.17.0
+Version: 0.17.1
 Summary: Developer CLI for Blitz locker-room: spec-driven playbooks, a codebase/huddle ontology graph with an MCP tool, and the composable watcher/trainer/graph containers.
 License: MIT
 License-File: LICENSE
-Requires-Python: >=3.9
+Requires-Python: >=3.11
 Requires-Dist: rich>=13
 Provides-Extra: secrets
 Requires-Dist: boto3>=1.34; extra == 'secrets'
@@ -81,8 +81,10 @@ Ollama endpoint comes from `--ollama-url` or `OLLAMA_HOST`; the model from
 
 ### Collection over the ingest endpoint
 
-`blitz model execute --collect` records every generation attempt as DPO
-training data. By default it writes straight to the activity SQLite database
+`blitz model execute` records every generation attempt as SFT training data.
+Collection is on by default; pass `--no-collect` to turn it off, in which case
+no database is opened at all. By default it writes straight to the activity
+SQLite database
 (`BLITZ_ACTIVITY_DB_PATH`, else `data/activity.db`). With `BLITZ_COLLECT_ENDPOINT` set,
 the same writes go over HTTP JSON to a collect ingest server instead, so the
 collector needs no filesystem access to the database:
@@ -92,12 +94,13 @@ collector needs no filesystem access to the database:
 BLITZ_ACTIVITY_DB_PATH=data/activity.db blitz locker-room collect-serve
 
 # on the collecting machine:
-BLITZ_COLLECT_ENDPOINT=http://locker-room-host:1739 blitz model execute --collect
+BLITZ_COLLECT_ENDPOINT=http://locker-room-host:1739 blitz model execute
 ```
 
 Each attempt is acknowledged by the endpoint before the next model call
-starts. If the endpoint is unreachable when the run starts, the run fails
-fast, same as an unwritable database. If it fails mid-run, the run keeps
+starts. If the endpoint is unreachable when the run starts, the run warns on
+stderr and continues without collection, same as an unwritable database. If it
+fails mid-run, the run keeps
 going: undelivered payloads are buffered to `collect-buffer.jsonl` in the run
 directory and the final output names the file. Deliver them later with
 
@@ -107,8 +110,46 @@ blitz model collect flush .blitz/execute/runs/<stamp>/collect-buffer.jsonl
 
 Flushing is idempotent (the server deduplicates attempts on their
 run/task/sample/attempt identity), so re-running a flush, or flushing rows the
-server already received, never duplicates data. `pairs extract/export/stats`
-read the database directly, unaffected by the endpoint.
+server already received, never duplicates data. `blitz model sft` reads the
+database directly, unaffected by the endpoint.
+
+`blitz model execute` exits 0 when the run completes, 1 when it completes with
+unsolved tasks, and 2 when it aborts on an environment failure: the model
+endpoint became unreachable, everything collected before the failure was saved,
+and the remaining tasks were not attempted. An outage is recorded as an
+environment failure on the attempt and never queues a task for repair.
+
+### The repair queue: `blitz model sft`
+
+A task the local model does not solve leaves a placeholder in the repair queue,
+awaiting a reference solution. Attaching the frontier's repair to that
+placeholder is what turns a failed run into supervised training data.
+
+```bash
+blitz model sft stats [--run RUN_ID]        # attempt counts, pass rates, queue depth
+blitz model sft solve --run RUN_ID --task T014 --solution-file repair.patch
+blitz model sft queue --run RUN_ID --task T009
+```
+
+`sft stats` reports, per run, the attempt count, per-task pass rates with the
+20 to 80 percent band marked, and the repair-queue depth.
+
+`sft solve` attaches a reference solution to a queued task, setting it to
+`has_solution` and attributing it to `frontier`. Give the solution with
+`--solution TEXT`, `--solution-file PATH`, or `--solution-stdin`. A task that
+already has a solution is left alone unless you pass `--force`. The solution
+lands on the queue row only: the collected attempt record holds local-model
+output and never receives frontier text.
+
+`sft queue` queues a task after the fact, for the case where the local model
+reported a task complete and the work was not done. The default reason is
+`false_success`, which keeps it distinguishable from a task that honestly
+exhausted its retries. The prompt is reused from the run's earliest recorded
+attempt for that task; pass `--prompt-file PATH` when the run recorded none. A
+row that already carries a solution is left unchanged.
+
+Every subcommand takes `--db PATH` (default: `BLITZ_ACTIVITY_DB_PATH`, else
+`data/activity.db`).
 
 ## Locker-room: ontology graph, watcher, trainer, MCP
 

{blitz_cli-0.17.0 → blitz_cli-0.17.1}/README.md

@@ -58,8 +58,10 @@ Ollama endpoint comes from `--ollama-url` or `OLLAMA_HOST`; the model from
 
 ### Collection over the ingest endpoint
 
-`blitz model execute --collect` records every generation attempt as DPO
-training data. By default it writes straight to the activity SQLite database
+`blitz model execute` records every generation attempt as SFT training data.
+Collection is on by default; pass `--no-collect` to turn it off, in which case
+no database is opened at all. By default it writes straight to the activity
+SQLite database
 (`BLITZ_ACTIVITY_DB_PATH`, else `data/activity.db`). With `BLITZ_COLLECT_ENDPOINT` set,
 the same writes go over HTTP JSON to a collect ingest server instead, so the
 collector needs no filesystem access to the database:
@@ -69,12 +71,13 @@ collector needs no filesystem access to the database:
 BLITZ_ACTIVITY_DB_PATH=data/activity.db blitz locker-room collect-serve
 
 # on the collecting machine:
-BLITZ_COLLECT_ENDPOINT=http://locker-room-host:1739 blitz model execute --collect
+BLITZ_COLLECT_ENDPOINT=http://locker-room-host:1739 blitz model execute
 ```
 
 Each attempt is acknowledged by the endpoint before the next model call
-starts. If the endpoint is unreachable when the run starts, the run fails
-fast, same as an unwritable database. If it fails mid-run, the run keeps
+starts. If the endpoint is unreachable when the run starts, the run warns on
+stderr and continues without collection, same as an unwritable database. If it
+fails mid-run, the run keeps
 going: undelivered payloads are buffered to `collect-buffer.jsonl` in the run
 directory and the final output names the file. Deliver them later with
 
@@ -84,8 +87,46 @@ blitz model collect flush .blitz/execute/runs/<stamp>/collect-buffer.jsonl
 
 Flushing is idempotent (the server deduplicates attempts on their
 run/task/sample/attempt identity), so re-running a flush, or flushing rows the
-server already received, never duplicates data. `pairs extract/export/stats`
-read the database directly, unaffected by the endpoint.
+server already received, never duplicates data. `blitz model sft` reads the
+database directly, unaffected by the endpoint.
+
+`blitz model execute` exits 0 when the run completes, 1 when it completes with
+unsolved tasks, and 2 when it aborts on an environment failure: the model
+endpoint became unreachable, everything collected before the failure was saved,
+and the remaining tasks were not attempted. An outage is recorded as an
+environment failure on the attempt and never queues a task for repair.
+
+### The repair queue: `blitz model sft`
+
+A task the local model does not solve leaves a placeholder in the repair queue,
+awaiting a reference solution. Attaching the frontier's repair to that
+placeholder is what turns a failed run into supervised training data.
+
+```bash
+blitz model sft stats [--run RUN_ID]        # attempt counts, pass rates, queue depth
+blitz model sft solve --run RUN_ID --task T014 --solution-file repair.patch
+blitz model sft queue --run RUN_ID --task T009
+```
+
+`sft stats` reports, per run, the attempt count, per-task pass rates with the
+20 to 80 percent band marked, and the repair-queue depth.
+
+`sft solve` attaches a reference solution to a queued task, setting it to
+`has_solution` and attributing it to `frontier`. Give the solution with
+`--solution TEXT`, `--solution-file PATH`, or `--solution-stdin`. A task that
+already has a solution is left alone unless you pass `--force`. The solution
+lands on the queue row only: the collected attempt record holds local-model
+output and never receives frontier text.
+
+`sft queue` queues a task after the fact, for the case where the local model
+reported a task complete and the work was not done. The default reason is
+`false_success`, which keeps it distinguishable from a task that honestly
+exhausted its retries. The prompt is reused from the run's earliest recorded
+attempt for that task; pass `--prompt-file PATH` when the run recorded none. A
+row that already carries a solution is left unchanged.
+
+Every subcommand takes `--db PATH` (default: `BLITZ_ACTIVITY_DB_PATH`, else
+`data/activity.db`).
 
 ## Locker-room: ontology graph, watcher, trainer, MCP
 

blitz_cli-0.17.1/blitz.toml

@@ -0,0 +1,13 @@
+# blitz secret-scan allowlist for this repo (the scanner's own source).
+# Entries match a repo-relative `path` exactly or a glob `pattern`.
+[secrets]
+allowlist = [
+  # The scanner's test suite deliberately contains secret-shaped fixtures
+  # (fake API keys, `SECRET_KEY = "..."`, etc.) to exercise the detectors.
+  # They are not real credentials.
+  { path = "tests/test_secretscan.py" },
+  # Spec quickstart guides are example env-var assignments and path tokens
+  # (BLITZ_ACTIVITY_DB_PATH=/tmp/..., etc.) that the high-entropy detector
+  # mistakes for base64 credentials.
+  { pattern = "*quickstart.md" },
+]