Release dev to main

.github/workflows/publish-modules.yml

@@ -189,8 +189,8 @@ jobs:
   auto-publish:
     name: Package bundled modules and PR bundled-registry snapshot (after sign-modules)
     # Trigger only when sign-modules.yml completed successfully on dev/main.
-    # Uses workflow_run so it is NOT suppressed by the `[skip ci]` marker on
-    # the bot's auto-sign commit (push events would be).
+    # Uses workflow_run so publishing follows the completed signing workflow,
+    # independent of which push event originally changed bundled manifests.
     if: >-
       github.event_name == 'workflow_run' &&
       github.event.workflow_run.event == 'push' &&

.github/workflows/sign-modules-on-approval.yml

@@ -110,7 +110,7 @@ jobs:
             echo "No staged module manifest updates."
             exit 0
           fi
-          git commit -m "chore(modules): ci sign changed modules [skip ci]"
+          git commit -m "chore(modules): ci sign changed modules"
           git push origin "HEAD:${HEAD_REF}"
           echo "## Signed manifests pushed" >> "${GITHUB_STEP_SUMMARY}"
           echo "Updated \`module-package.yaml\` files were committed to \`${HEAD_REF}\`." >> "${GITHUB_STEP_SUMMARY}"
@@ -190,7 +190,7 @@ jobs:
             echo "No staged module manifest updates."
             exit 0
           fi
-          git commit -m "chore(modules): manual approval-workflow sign changed modules [skip ci]"
+          git commit -m "chore(modules): manual approval-workflow sign changed modules"
           git push origin "HEAD:${GITHUB_REF_NAME}"
           echo "## Signed manifests pushed" >> "${GITHUB_STEP_SUMMARY}"
           echo "Branch: \`${GITHUB_REF_NAME}\` (merge-base vs \`origin/${{ github.event.inputs.base_branch }}\`, bump: \`${{ github.event.inputs.version_bump }}\`)." >> "${GITHUB_STEP_SUMMARY}"

.github/workflows/sign-modules.yml

@@ -222,7 +222,7 @@ jobs:
           fi
           BRANCH="auto/sign-${GITHUB_REF_NAME}-${{ github.run_id }}"
           git checkout -b "${BRANCH}"
-          git commit -m "chore(modules): auto-sign bundled manifests [skip ci]"
+          git commit -m "chore(modules): auto-sign bundled manifests"
           git push -u origin "${BRANCH}"
           gh pr create \
             --repo "${{ github.repository }}" \
@@ -363,7 +363,7 @@ jobs:
             echo "No staged module manifest updates."
             exit 0
           fi
-          git commit -m "chore(modules): manual workflow_dispatch sign changed modules [skip ci]"
+          git commit -m "chore(modules): manual workflow_dispatch sign changed modules"
           git push origin "HEAD:${GITHUB_REF_NAME}"
           echo "## Signed manifests pushed" >> "${GITHUB_STEP_SUMMARY}"
           echo "Branch: \`${GITHUB_REF_NAME}\` (base: \`origin/${{ github.event.inputs.base_branch }}\`, bump: \`${{ github.event.inputs.version_bump }}\`, resign_all: \`${{ github.event.inputs.resign_all_manifests }}\`)." >> "${GITHUB_STEP_SUMMARY}"

CHANGELOG.md

@@ -10,6 +10,48 @@ All notable changes to this project will be documented in this file.
 
 ---
 
+## [0.47.11] - 2026-06-14
+
+### Fixed
+
+- **Bundle install CI stability**: avoid brittle Click stdout capture in the
+  already-present bundle dependency regression and apply module-registry review
+  annotations for callback type enforcement and isolated test state.
+
+---
+
+## [0.47.10] - 2026-06-13
+
+### Fixed
+
+- **Module install CI stability**: refresh loaded SpecFact module consoles before
+  direct module-registry invocations so stale Rich streams from earlier tests do
+  not close Click's captured stdout in Python 3.11 full-suite runs.
+
+---
+
+## [0.47.9] - 2026-06-13
+
+### Fixed
+
+- **PR gate remediation**: split Independent Static Analysis onto a dedicated
+  checked-in SAST profile, keep clean-code review separate from security SAST,
+  fix marketplace install output capture across Python CI jobs, and make the
+  module pre-commit verifier compatible with macOS's default Bash.
+
+---
+
+## [0.47.8] - 2026-06-13
+
+### Fixed
+
+- **PR hardening follow-up**: address PR review annotations and failing CI by
+  pinning orchestrator actions to immutable SHAs, preserving precise coverage
+  threshold comparisons, making Semgrep SAST result parsing fail closed, and
+  normalizing versioned dependency constraints before dedupe.
+
+---
+
 ## [0.47.7] - 2026-06-12
 
 ### Fixed

docs/agent-rules/50-quality-gates-and-review.md

@@ -15,7 +15,7 @@ tracks:
   - scripts/verify-modules-signature.py
   - scripts/module-verify-policy.sh
   - docs/agent-rules/**
-last_reviewed: 2026-04-16
+last_reviewed: 2026-06-13
 exempt: false
 exempt_reason: ""
 id: agent-rules-quality-gates-and-review
@@ -52,6 +52,17 @@ depends_on:
 - Resolve every finding at any severity unless a rare, explicit exception is documented.
 - Record the review command and timestamps in `TDD_EVIDENCE.md` or the PR description when quality gates are part of the change.
 
+## Independent static analysis
+
+Do not treat `specfact code review run` as sufficient security evidence for this repository. The review gate is intentionally self-referential: it is valuable for SpecFact-specific conventions, command-surface expectations, OpenSpec alignment, and local clean-code policy, but it can inherit blind spots from SpecFact itself.
+
+PR validation therefore requires an independent static-analysis check alongside the self-review gate:
+
+- `Independent Static Analysis` runs Semgrep OSS SAST through `hatch run semgrep-sast` and validates results with `hatch run semgrep-sast-gate`.
+- Existing Semgrep findings are tracked in `tools/semgrep/sast-baseline.json`; new findings outside that baseline fail CI.
+- Bandit runs through `hatch run bandit-scan` and is expected to remain clean for blocking medium/high findings.
+- The Semgrep and Bandit artifacts are external evidence and must not be replaced by `.specfact/code-review.json`.
+
 ## Clean-code review gate
 
 The repository enforces the clean-code charter through `specfact code review run`. Zero regressions in `naming`, `kiss`, `yagni`, `dry`, and `solid` are required before merge.
@@ -71,6 +82,10 @@ the change reaches `main`**.
 hatch run verify-modules-signature
 ```
 
+CI mirrors this boundary: `pr-orchestrator.yml` uses **`VERIFY_MODULES_STRICT`** for pull requests
+targeting `main` and for pushes to `main`; relaxed PR verification is only for development PRs that do
+not cross the release boundary.
+
 If verification fails because module contents changed, re-sign the affected manifests and bump the
 module version before re-running verification. Note: `verify-modules-signature.py` has **no**
 `--allow-unsigned` flag. The `--allow-unsigned` option on **`sign-modules.py`** is only for local test signing.

docs/guides/module-signing-and-key-rotation.md

@@ -124,7 +124,8 @@ PR / feature-branch parity with pre-commit omit (version bump vs base; defer che
 hatch run verify-modules-signature-pr --version-check-base origin/dev
 ```
 
-Post-merge / push-style checksum + version (no `--require-signature`; matches `VERIFY_MODULES_PUSH_ORCHESTRATOR`):
+Development push-style checksum + version for the `dev` path (no `--require-signature`; matches
+`VERIFY_MODULES_PUSH_ORCHESTRATOR`):
 
 ```bash
 hatch run python scripts/verify-modules-signature.py --enforce-version-bump --payload-from-filesystem
@@ -146,14 +147,16 @@ If you use `pre-commit` or `scripts/setup-git-hooks.sh`, commits that stage chan
 
 Canonical flag bundles live in **`scripts/module-verify-policy.sh`** and are sourced by:
 
-- **`pr-orchestrator.yml`** job `verify-module-signatures`: **pull requests** use **`VERIFY_MODULES_PR`**
-  (same as pre-commit omit). **Pushes** to `dev` / `main` use **`VERIFY_MODULES_PUSH_ORCHESTRATOR`**
-  (payload checksum + version bump; no `--require-signature` in this job).
+- **`pr-orchestrator.yml`** job `verify-module-signatures`: pull requests targeting **`dev`** use
+  **`VERIFY_MODULES_PR`** (same as pre-commit omit). Pull requests targeting **`main`** and pushes to
+  **`main`** use **`VERIFY_MODULES_STRICT`** so unsigned or stale bundled manifests block before the
+  release trust boundary. Pushes to **`dev`** use **`VERIFY_MODULES_PUSH_ORCHESTRATOR`** (payload
+  checksum + version bump; no `--require-signature` in the `dev` push path).
 - **`sign-modules.yml`** job `verify`: **push** to `dev` or `main` runs **`VERIFY_MODULES_STRICT`**
   after the auto-sign step. **Pull requests** and **`workflow_dispatch`** use **`VERIFY_MODULES_PR`**.
 
-Strict signatures on protected branches are enforced by **`sign-modules.yml`** (and local **`main`**
-pre-commit), not by adding `--require-signature` to the PR orchestrator verify step.
+Strict signatures at the release boundary are enforced by **`pr-orchestrator.yml`**, **`sign-modules.yml`**,
+and local **`main`** pre-commit.
 
 ## Rotation Procedure
 

docs/modules/code-review.md

@@ -138,6 +138,18 @@ The scaffolded `ReviewReport` envelope carries these fields:
 - Review-specific fields (`score`, `reward_delta`, `findings`, `summary`, `house_rules_updates`) extend the standard evidence shape without replacing it.
 - CI can treat `ci_exit_code` as the contract-bound gate result from the start.
 
+## Self-Review Limits
+
+`specfact code review run` is deliberately optimized for SpecFact conventions: command surfaces, OpenSpec contract alignment, local clean-code rules, and repository-specific policy. That makes it useful, but it also means it can inherit blind spots from SpecFact itself. If SpecFact does not model a risk pattern, the self-review gate cannot reliably discover that pattern in this repository.
+
+For SpecFact CLI itself, CI pairs the self-review evidence with an independent static-analysis gate:
+
+- Semgrep OSS SAST runs through `hatch run semgrep-sast`.
+- `hatch run semgrep-sast-gate` compares Semgrep JSON against `tools/semgrep/sast-baseline.json` and fails on new findings.
+- Bandit runs through `hatch run bandit-scan`.
+
+Use the self-review report for SpecFact-specific quality signals, and use Semgrep/Bandit as orthogonal evidence from external rulesets.
+
 ## Pre-Commit Review Gate
 
 This repository wires `specfact code review run` into **Block 2** of the modular pre-commit pipeline

docs/reference/module-security.md

@@ -48,13 +48,16 @@ Module packages carry **publisher** and **integrity** metadata so installation,
   **`scripts/module-verify-policy.sh`** (`VERIFY_MODULES_STRICT`, `VERIFY_MODULES_PR`,
   `VERIFY_MODULES_PUSH_ORCHESTRATOR`).
   - **Strict** (`VERIFY_MODULES_STRICT`): `--require-signature --enforce-version-bump --payload-from-filesystem`
-    — local **`main`** pre-commit, **`sign-modules.yml`** verify on **push** to `dev`/`main` (after auto-sign).
+    — local **`main`** pre-commit, **`pr-orchestrator.yml`** verify on pull requests targeting
+    **`main`** and pushes to **`main`**, and **`sign-modules.yml`** verify on **push** to `dev`/`main`
+    (after auto-sign).
   - **PR / feature relaxed** (`VERIFY_MODULES_PR`): `--enforce-version-bump --skip-checksum-verification`
-    — pre-commit on non-`main`, **`pr-orchestrator.yml`** verify job on **pull_request**, **`sign-modules.yml`**
-    verify on **pull_request** / **workflow_dispatch** (version discipline vs base; checksum refresh in CI).
+    — pre-commit on non-`main`, **`pr-orchestrator.yml`** verify job on pull requests targeting
+    **`dev`**, and **`sign-modules.yml`** verify on **pull_request** / **workflow_dispatch**
+    (version discipline vs base; checksum refresh in CI).
   - **Orchestrator push** (`VERIFY_MODULES_PUSH_ORCHESTRATOR`): `--enforce-version-bump --payload-from-filesystem`
-    — **`pr-orchestrator.yml`** verify job on **push** to `dev`/`main` (payload checksum + version; no
-    `--require-signature` in that job).
+    — **`pr-orchestrator.yml`** verify job on **push** to **`dev`** (payload checksum + version; no
+    `--require-signature` in that `dev` push path).
   - **Approval-time signing** (`sign-modules-on-approval.yml`): on **approved** reviews for same-repo PRs
     targeting **`dev` or `main`**, CI runs `pull_request.base.sha`’s **`scripts/sign-modules.py`**
     (trusted revision) against the **PR head** working tree, then pushes updated `module-package.yaml`

openspec/changes/cli-val-04-acceptance-test-runner/design.md

@@ -29,7 +29,7 @@ This change implements the runner that compiles CLI behavior scenarios (from cli
 
 ## Risks / Trade-offs
 
-- [subprocess tests depend on installed binary] -> Mitigation: CI installs via `pip install -e .` before running black-box tests
+- [subprocess tests depend on installed binary] -> Mitigation: CI builds a wheel and installs that wheel into an isolated environment before running black-box tests; editable installs are allowed only for local fast feedback
 - [Subprocess tests are slower] -> Mitigation: mark as `blackbox` for selective execution; fast path covers most validation
 - [Context setup complexity] -> Mitigation: start with 3 simple context types; extend as needed
 
@@ -44,4 +44,4 @@ This change implements the runner that compiles CLI behavior scenarios (from cli
 ## Open Questions
 
 - Whether to adopt Cram/Prysk/Scrut for the flagship tests in a future iteration
-- Whether the black-box path should test the `specfact` or `specfact-cli` entry point (or both)
+- Whether later release validation should add a published-package `uvx specfact-cli@<version>` leg after PR-time wheel validation is stable

openspec/changes/cli-val-04-acceptance-test-runner/proposal.md

@@ -8,7 +8,7 @@ The 73+ existing CliRunner tests prove commands work in-process. But SpecFact is
 
 - **NEW**: Dual-path scenario runner in `tools/cli_acceptance_runner.py` that reads YAML scenarios from cli-val-01 and executes them via:
   - Fast path: `typer.testing.CliRunner` (for development speed)
-  - Black-box path: `subprocess.run()` against the installed `specfact` binary (for CI/release validation)
+  - Black-box path: `subprocess.run()` against a built-wheel installation of the `specfact` and `specfact-cli` binaries (for CI/release validation)
 - **NEW**: Acceptance test file `tests/e2e/test_cli_acceptance.py` wiring the runner into pytest collection
 - **NEW**: Small set of Cram-style `.t` or Markdown acceptance tests for 3-5 flagship command chains (living documentation + executable tests)
 - **EXTEND**: `pyproject.toml` with hatch scripts for fast-path and black-box acceptance runs
@@ -17,13 +17,13 @@ The 73+ existing CliRunner tests prove commands work in-process. But SpecFact is
 
 ### New Capabilities
 
-- `acceptance-test-runner`: A dual-path test runner that executes CLI behavior scenarios from YAML files via CliRunner (fast, in-process) or subprocess (black-box, against installed binary). Supports workspace setup, exit code assertions, output pattern matching, and filesystem diff verification.
+- `acceptance-test-runner`: A dual-path test runner that executes CLI behavior scenarios from YAML files via CliRunner (fast, in-process) or subprocess (black-box, against a built-wheel installed binary). Supports workspace setup, exit code assertions, output pattern matching, and filesystem diff verification.
 
 ## Impact
 
 - **Affected specs**: No existing specs modified; new spec delta defines runner behavior
 - **Affected code**: New tools/ and tests/ files only; no production CLI code changes
-- **Integration points**: Consumes cli-val-01 YAML scenarios and cli-val-03 anti-patterns; consumed by cli-val-05 (CI gate runs black-box path)
+- **Integration points**: Consumes cli-val-01 YAML scenarios and cli-val-03 anti-patterns; consumed by cli-val-05 (CI gate builds a wheel and runs the black-box path)
 - **Documentation impact**: Developer guide update describing acceptance test workflow and how to add new scenarios
 
 ## Dependencies

openspec/changes/cli-val-04-acceptance-test-runner/specs/acceptance-test-runner/spec.md

@@ -2,7 +2,7 @@
 
 ### Requirement: Dual-Path Scenario Execution
 
-The system SHALL execute CLI behavior scenarios via both in-process (CliRunner) and subprocess (installed binary) paths.
+The system SHALL execute CLI behavior scenarios via both in-process (CliRunner) and subprocess (built-wheel installed binary) paths.
 
 #### Scenario: Fast path executes scenario via CliRunner
 
@@ -14,11 +14,12 @@ The system SHALL execute CLI behavior scenarios via both in-process (CliRunner)
 
 #### Scenario: Black-box path executes scenario via subprocess
 
-- **GIVEN** a YAML scenario file and the `specfact` binary is installed on PATH
+- **GIVEN** a YAML scenario file and the built wheel has been installed into an isolated environment
 - **WHEN** the runner executes the scenario in black-box mode
 - **THEN** the scenario is invoked via `subprocess.run()`
 - **AND** real exit code, stdout, and stderr are captured and asserted
-- **AND** the test validates the installed binary, not the source tree.
+- **AND** both `specfact` and `specfact-cli` entry points can be validated
+- **AND** the test validates the built artifact, not an editable source install.
 
 #### Scenario: Filesystem diff verification in sandboxed workspace