\\n

📝 Walkthrough

\\n\\n## Walkthrough\\n\\nExtended modules ecosystem with 11 new OpenSpec change sets and docs; added import-runtime hardening (pre-traversal pruning, `.specfact/.specfactignore`, heavy-tree warnings, provisional ETA), runtime patches limiting discovery, packaged Jinja2 templates and resolver helpers, tests, registry/module-version bumps, and an enhanced GitHub Actions signing workflow using GraphQL review checks.\\n\\n## Changes\\n\\n|Cohort / File(s)|Summary|\\n|---|---|\\n|**GitHub Actions workflow & tests**
`/.github/workflows/sign-modules-on-approval.yml`, `tests/unit/workflows/test_sign_modules_on_approval.py`|Workflow triggers extended to `pull_request` (opened/synchronize/reopened/ready_for_review) alongside `pull_request_review.submitted`; concurrency/grouping and PR ref env vars made resilient; eligibility gate now queries PR `latestReviews` via `gh api` for trusted APPROVED reviews; `GH_TOKEN` added to gate environment.|\\n|**OpenSpec change sets**
`openspec/CHANGE_ORDER.md`, `openspec/changes/...` (multiple new dirs)|Added 11 OpenSpec change directories (architecture, enterprise, finops, knowledge, review-resiliency, security, etc.) with `.openspec.yaml` plus design/proposal/specs/tasks documents and CHANGE_ORDER updates.|\\n|**Import discovery & policy**
`packages/specfact-project/src/specfact_project/utils/import_path_policy.py`, `tests/unit/specfact_project/test_import_runtime_policy.py`|New import discovery API and dataclasses, `.specfact/.specfactignore` loading, pre-traversal pruning, heavy-ignored warnings, provisional ETA computation, and unit tests covering pruning, entry-point handling, thresholds and ignore semantics.|\\n|**Runtime patch layer**
`packages/specfact-project/src/specfact_project/import_runtime_patches.py`, `packages/specfact-project/src/specfact_project/import_cmd/commands.py`, `packages/specfact-project/src/specfact_project/sync/commands.py`|Introduced idempotent runtime patches that intercept `Path.rglob`, patch analyzer/counting functions, suppress timing chatter, and limit discovery for heavy phases; patches are applied at command startup (`from_code`, `sync_repository`).|\\n|**Template resolution & packaged templates**
`packages/specfact-project/src/specfact_project/generators/template_paths.py`, `.../plan_generator.py`, `.../protocol_generator.py`, `.../workflow_generator.py`, `packages/specfact-project/resources/templates/*`|Added template resolver helpers (`resolve_project_templates_dir` and aliases); generators use resolvers; added packaged Jinja2 templates (`github-action.yml.j2`, `protocol.yaml.j2`, `persona/default.md.j2`) and tests verifying runtime resolution and tarball contents.|\\n|**Bundle metadata & registry**
`packages/specfact-project/module-package.yaml`, `registry/index.json`, `registry/modules/specfact-project-0.41.{4,5,6}.tar.gz.sha256`, `registry/signatures/specfact-project-0.41.{5,6}.tar.sig`|Bumped `specfact-project` bundle version to `0.41.6`; updated integrity/checksum/signature fields and registry download URLs/checksums/signatures; added intermediate checksum/signature files.|\\n|**Generators & persona templates tests**
`packages/specfact-project/src/specfact_project/generators/*`, `tests/unit/test_bundle_resource_payloads.py`|Generators now resolve templates at runtime; new tests validate generated protocol YAML, GitHub workflow generation, persona template presence, and artifact packaging.|\\n|**Scripts / GitHub hierarchy**
`scripts/ensure_github_hierarchy_subissues.py`|Added script to enforce predefined Epic→Feature sub-issue edges via `gh api graphql` with dry-run support, caching and robust error handling.|\\n|**Documentation**
`docs/bundles/project/import-migration.md`|Docs updated to describe default ignore policy, discovery/ETA semantics after pruning, repo-local `.specfact/.specfactignore` overrides, heavy-artifact warnings, and treating ETA as provisional.|\\n|**Findings model extension**
`packages/specfact-code-review/src/specfact_code_review/run/findings.py`|Added `EvidenceRef` model and optional `evidence_refs` field to `ReviewFinding` for structured evidence references.|\\n\\n## Sequence Diagram(s)\\n\\n```mermaid\\nsequenceDiagram\\n autonumber\\n participant PR as Pull Request Event\\n participant WF as Workflow (sign-modules-on-approval)\\n participant GH as GitHub API (GraphQL)\\n participant Signer as Module Signer\\n\\n rect rgba(100, 150, 200, 0.5)\\n Note over PR,WF: pull_request (opened/synchronize/reopened/ready_for_review)\\n end\\n\\n PR->>WF: trigger on pull_request\\n WF->>WF: set concurrency.group using github.event.pull_request.number or github.event.number\\n WF->>WF: resolve PR_BASE_REF / PR_HEAD_REF with fallbacks\\n WF->>WF: if github.event_name == \\\"pull_request\\\" then\\n WF->>GH: gh api graphql: query latestReviews(first:100) for PR\\n GH-->>WF: return reviews (states + authorAssociation)\\n WF->>WF: compute trusted APPROVED review existence\\n alt trusted APPROVED exists\\n WF->>Signer: sign=true\\n else\\n WF->>Signer: sign=false\\n end\\n\\n rect rgba(150, 200, 100, 0.5)\\n Note over PR,WF: pull_request_review (submitted)\\n end\\n\\n PR->>WF: trigger on pull_request_review\\n WF->>WF: use event.review.state and author_association\\n alt review.state == \\\"approved\\\" and trusted author\\n WF->>Signer: sign=true\\n else\\n WF->>Signer: sign=false\\n end\\n```\\n\\n```mermaid\\nsequenceDiagram\\n autonumber\\n participant CLI as Command (from_code / sync_repository)\\n participant Patches as import_runtime_patches.apply_import_runtime_patches\\n participant Discovery as discover_code_files\\n participant Analyzer as CodeAnalyzer\\n participant Console as console.print\\n\\n rect rgba(100, 150, 200, 0.5)\\n Note over CLI,Patches: Patch installation at command start\\n end\\n\\n CLI->>Patches: apply_import_runtime_patches()\\n Patches->>Patches: install rglob interception & analyzer wrappers\\n Patches->>Console: wrap console.print to filter timing chatter\\n\\n rect rgba(150, 200, 100, 0.5)\\n Note over Discovery,Analyzer: Discovery + Patched Analysis\\n end\\n\\n Patches->>Discovery: discover_code_files(repo_root, options)\\n Discovery->>Discovery: load .specfactignore, prune heavy dirs, compute provisional ETA\\n Discovery-->>Patches: return ImportDiscoveryResult(files, warnings, eta)\\n Patches->>Console: emit runtime warnings if needed\\n Patches->>Analyzer: execute analyze() under patched rglob (filtered file set)\\n Analyzer-->>CLI: analysis results\\n```\\n\\n## Estimated code review effort\\n\\n🎯 4 (Complex) | ⏱️ ~65 minutes\\n\\n## Possibly related issues\\n\\n- nold-ai/specfact-cli-modules#235 — Code-import runtime hardening: matches the new import discovery, template packaging, runtime patches and tests added here. \\n- nold-ai/specfact-cli-modules#234 — Discovery pruning & `.specfactignore` semantics: aligns with import_path_policy and discovery/ETA changes. \\n- nold-ai/specfact-cli-modules#236 — Import/runtime + workflow overlap: related to template resolution, generators and signing workflow edits present in this PR. \\n- nold-ai/specfact-cli-modules#231 — Enterprise Policy Client module: related to the added enterprise policy OpenSpec docs/specs in this PR. \\n- nold-ai/specfact-cli-modules#230 — Architecture well-architected module: corresponds to the added architecture OpenSpec files. \\n- nold-ai/specfact-cli-modules#225 — Knowledge Writeback Module: matches the knowledge writeback openspec content added.\\n\\n## Possibly related PRs\\n\\n- nold-ai/specfact-cli-modules#236 — Closely related: overlaps import runtime hardening, template resolution, generators, tests and sign-workflow edits. \\n- nold-ai/specfact-cli-modules#233 — Related: similar OpenSpec additions and the GitHub hierarchy script. \\n- nold-ai/specfact-cli-modules#188 — Prior sign-modules-on-approval workflow work; this PR extends that workflow with PR triggers and GraphQL review checks.\\n\\n## Suggested labels\\n\\n`bug`\\n\\n

\\n\\n\\n\\n\\n\\n\\n

\\n

✨ Finishing Touches

\\n\\n

\\n

🧪 Generate unit tests (beta)

\\n\\n- [ ] Create PR with unit tests\\n- [ ] Commit unit tests in branch `promote/pr-236-to-main`\\n\\n

\\n\\n

\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\nCursor Bugbot has reviewed your changes and found 2 potential issues.\\n\\n\\n\\n\\n

\\n\\n\\n\\n^{Bugbot Autofix is [ON](https://www.cursor.com/dashboard/bugbot). A cloud agent has been kicked off to fix the reported issues.}\\n\\n\\n^{Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 39750733a68cd1ac8b652b1c46abcc51d84aff60. Configure [here](https://www.cursor.com/dashboard/bugbot).}\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"### Relative entry_point resolved against wrong base directory\\n\\n**Medium Severity**\\n\\n\\n`_patched_rglob` resolves a relative `entry_point` via `entry_point.resolve()` (against CWD), but `_resolve_entry_point` in `import_path_policy.py` resolves relative paths against `repo_root` using `(resolved_repo_root / entry_point).resolve()`. When CWD differs from `repo_root`, `resolved_entry_point` in the rglob patch won't match the path that `Path.rglob` is actually called on, so the patch silently falls through to the original unfiltered `rglob` — defeating the entire ignore-policy filtering for entry-point-scoped imports.\\n\\n\\n\\n\\n\\n

\\n

Additional Locations (1)

\\n\\n- [`packages/specfact-project/src/specfact_project/utils/import_path_policy.py#L84-L97`](https://github.com/nold-ai/specfact-cli-modules/blob/39750733a68cd1ac8b652b1c46abcc51d84aff60/packages/specfact-project/src/specfact_project/utils/import_path_policy.py#L84-L97)\\n\\n

\\n\\n

\\n

Additional Locations (1)

\\n\\n- [`packages/specfact-project/src/specfact_project/utils/import_path_policy.py#L246-L263`](https://github.com/nold-ai/specfact-cli-modules/blob/39750733a68cd1ac8b652b1c46abcc51d84aff60/packages/specfact-project/src/specfact_project/utils/import_path_policy.py#L246-L263)\\n\\n

\\n\\n

\\n\\n\\n^{Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 39750733a68cd1ac8b652b1c46abcc51d84aff60. Configure [here](https://www.cursor.com/dashboard/bugbot).}\\n\",\"path\":\"packages/specfact-project/src/specfact_project/generators/template_paths.py\",\"side\":\"RIGHT\",\"line\":76}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Add pull-request read permission for approval query**\\n\\nThe eligibility gate now calls `gh api graphql` on `pull_request` events to read `latestReviews`, but this workflow only grants `contents: write`. In GitHub Actions, unspecified token scopes are denied, so same-repo PR events can fail this step with `Resource not accessible by integration` before the script can emit `sign=false`, turning a skip path into a hard failing required check. Add at least `pull-requests: read` (or equivalent read scope) in `permissions` so the GraphQL review lookup can run reliably.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\".github/workflows/sign-modules-on-approval.yml\",\"side\":\"RIGHT\",\"line\":18}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `39750733a6`\\n \\n\\n

ℹ️ About Codex in GitHub

\\n
\\n\\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\\n- Open a pull request for review\\n- Mark a draft as ready\\n- Comment \\\"@codex review\\\".\\n\\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\\n\\n\\n\\n\\nCodex can also answer questions or update the PR. Try commenting \\\"@codex address that feedback\\\".\\n \\n

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Optional: Replace \\\"very large\\\" with specific metrics.**\\n\\nStatic analysis flagged \\\"very large\\\" as an over-used intensifier. Consider specifying approximate thresholds to help users calibrate expectations.\\n\\n\\n\\n

\\n

📝 Suggested clarification

\\n\\n```diff\\n-- When import encounters unusually large ignored artifact trees or a very large filtered repository, it emits warnings instead of promising that the run will finish in a specific number of minutes.\\n-- Remaining time is based on processed-versus-discovered work at the current runtime rate, so early estimates should be treated as provisional on very large repositories.\\n+- When import encounters unusually large ignored artifact trees (e.g., >10,000 files) or filtered repositories with >100,000 remaining files, it emits warnings instead of promising a specific completion time.\\n+- Remaining time is based on processed-versus-discovered work at the current runtime rate, so early estimates should be treated as provisional on repositories with extensive file counts.\\n```\\n\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n[style] ~39-~39: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.\\nContext: ...usually large ignored artifact trees or a very large filtered repository, it emits warnings ...\\n\\n(EN_WEAK_ADJECTIVE)\\n\\n---\\n\\n[style] ~40-~40: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.\\nContext: ...tes should be treated as provisional on very large repositories. ### Repo-local Ignore Ov...\\n\\n(EN_WEAK_ADJECTIVE)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@docs/bundles/project/import-migration.md` around lines 39 - 40, Replace the\\nvague phrase \\\"very large\\\" in the two sentences that start with \\\"When import\\nencounters unusually large ignored artifact trees...\\\" and \\\"Remaining time is\\nbased on processed-versus-discovered work...\\\" with concrete thresholds; for\\nexample, change to \\\"ignored artifact trees with >10,000 entries or repositories\\nlarger than ~100,000 files, ~10 GB of repository data, or >100,000 commits\\\" and\\nnote that estimates remain provisional for repos above those thresholds—adjust\\nthe numeric thresholds to align with product telemetry if different.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"docs/bundles/project/import-migration.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Resolve duplicate `Order` value in the security track.**\\n\\nLine 94 and Line 95 both assign `Order | 04` under `security`, which makes execution sequencing ambiguous in `CHANGE_ORDER`.\\n\\n

\\n

Suggested doc fix

\\n\\n```diff\\n-| security | 04 | security-03-module-pii-gdpr-eu | [`#229`](https://github.com/nold-ai/specfact-cli-modules/issues/229) | Parent Epic: [`#216`](https://github.com/nold-ai/specfact-cli-modules/issues/216); Parent Feature: [`#218`](https://github.com/nold-ai/specfact-cli-modules/issues/218); core umbrella [specfact-cli#511](https://github.com/nold-ai/specfact-cli/issues/511); `security-01-module-sast-sca-secret`; paired core changes `security-01-unified-findings-model` and `security-02-eu-gdpr-baseline` |\\n+| security | 05 | security-03-module-pii-gdpr-eu | [`#229`](https://github.com/nold-ai/specfact-cli-modules/issues/229) | Parent Epic: [`#216`](https://github.com/nold-ai/specfact-cli-modules/issues/216); Parent Feature: [`#218`](https://github.com/nold-ai/specfact-cli-modules/issues/218); core umbrella [specfact-cli#511](https://github.com/nold-ai/specfact-cli/issues/511); `security-01-module-sast-sca-secret`; paired core changes `security-01-unified-findings-model` and `security-02-eu-gdpr-baseline` |\\n```\\n

\\n\\nAs per coding guidelines, `openspec/**/*.md` must preserve specification truth for proposal/order semantics and avoid drift in CHANGE_ORDER.\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/CHANGE_ORDER.md` around lines 94 - 95, The two entries for\\nsecurity-02-module-license-compliance and security-03-module-pii-gdpr-eu both\\nuse Order | 04; update the Order on one of them (e.g., change\\nsecurity-03-module-pii-gdpr-eu to Order | 05 or otherwise assign a unique,\\nsequential number) so every `security` entry has a distinct Order value and the\\nCHANGE_ORDER semantics remain consistent across the spec.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/CHANGE_ORDER.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🔴 Critical_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Verify architecture-02-well-architected-review exists in specfact-cli\\n\\nrg -n --type=md -C3 'architecture-02-well-architected-review' || echo \\\"Core dependency not found in current context\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 6513\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for architecture-02-well-architected-review in specfact-cli\\nrg -n --type=md 'architecture-02-well-architected-review' 2>/dev/null | head -20 || echo \\\"No matches found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 46\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if there's a CHANGE_ORDER or change tracking file that references this\\nfind . -name \\\"CHANGE_ORDER*\\\" -o -name \\\"*architecture*\\\" -type f | grep -E '\\\\.(md|yaml|yml)$' | head -15\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 148\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read the CHANGE_ORDER.md to see architecture-related changes\\nhead -150 ./openspec/CHANGE_ORDER.md | tail -100\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 8290\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for any occurrence of \\\"architecture\\\" and \\\"review\\\" in CHANGE_ORDER.md\\ngrep -n -i \\\"architecture\\\" ./openspec/CHANGE_ORDER.md | head -20\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 3186\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Broader search for \\\"well-architected\\\" or similar pattern in specfact-cli\\nrg -i \\\"well-architected\\\" . 2>/dev/null || echo \\\"No matches found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 80\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if there's any reference to module boundary rules or review contracts under architecture-01\\ngrep -A10 -B2 \\\"architecture-01-solution-layer\\\" ./openspec/CHANGE_ORDER.md\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 3409\\n\\n---\\n\\n\\n\\n

\\n\\n**Paired core architecture contract `architecture-02-well-architected-review` not found in `specfact-cli`.**\\n\\nThe design document references a paired core change `architecture-02-well-architected-review` as a prerequisite for module integration. However, this contract is not tracked in the core repository. The only architecture work in `specfact-cli` is `architecture-01-solution-layer` (paired with modules#164), which focuses on core solution-layer contracts. Before proceeding with implementation, clarify whether:\\n- The core contract exists under a different name or folder in `specfact-cli`\\n- `architecture-01-solution-layer` provides the required boundary rules and adapter contracts for this module\\n- A new core change (`architecture-02-well-architected-review`) needs to be created or synced into `specfact-cli`\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\\n50, The document references a paired core contract named\\narchitecture-02-well-architected-review that isn't present in specfact-cli;\\nupdate the design to either (a) point to the existing core contract if it exists\\nunder a different name or folder (search for architecture-01-solution-layer and\\nother architecture-* entries in the specfact-cli repo), (b) confirm and document\\nthat architecture-01-solution-layer supplies the required boundary rules and\\nadapter contracts for this module, or (c) add a note that a new core change\\narchitecture-02-well-architected-review must be created/synced into specfact-cli\\nbefore module integration—ensure the doc references the exact core contract name\\nyou verified and mention architecture-01-solution-layer when clarifying overlap.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/architecture-02-module-well-architected/design.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Define the findings/evidence adapter boundary.**\\n\\nLines 10-12 describe packaged analyzers and report surfaces but don't specify the adapter contract that normalizes boundary violations and ADR findings into the paired core review contract. Without a clear adapter boundary, implementations may drift from the core schema.\\n\\n\\nConsider adding an \\\"Adapter Contract\\\" subsection under \\\"What Changes\\\" that defines:\\n- The core findings schema fields this bundle must populate\\n- How analyzer output maps to normalized evidence references\\n- Whether findings emission is synchronous or deferred\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ...ity, and interface-diff evaluation. - **NEW**: Encode the `ALLOWED_IMPORTS.md` patt...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` around\\nlines 10 - 12, Add an \\\"Adapter Contract\\\" subsection under \\\"What Changes\\\" that\\ndefines the normalized boundary between analyzers and the core review contract:\\nlist the required core findings schema fields this bundle must populate (e.g.,\\nid, type, severity, description, source, timestamp, evidence_refs), specify how\\noutputs from the packaged analyzers (dependency-graph checks, ADR traceability,\\ninterface-diff) map to normalized evidence references and fields (reference\\nexample mappings for ALLOWED_IMPORTS.md violations → evidence_refs, ADR entries\\n→ source/trace links), and state the emission mode (synchronous vs deferred\\nbatching) and retry/ordering semantics for findings emission so implementers\\nknow expected behavior.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/architecture-02-module-well-architected/proposal.md\",\"side\":\"RIGHT\",\"line\":12}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Specify `core_compatibility` requirements for the reserved manifest.**\\n\\nWhile the proposal reserves manifest/registry/docs/signing work, it doesn't define the expected `core_compatibility` version range for `architecture-02-well-architected-review`. Explicit version constraints help prevent runtime incompatibilities between the bundle and core.\\n\\n\\n

\\n

📋 Proposed addition to clarify compatibility metadata

\\n\\n```diff\\n-- **EXTEND**: Reserve manifest, registry, docs, and signing work for a new official architecture bundle.\\n+- **EXTEND**: Reserve manifest, registry, docs, and signing work for a new official architecture bundle, including `core_compatibility` entries for `architecture-02-well-architected-review` (minimum required core version to be determined during implementation).\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` at line\\n13, Add an explicit core_compatibility field and semantic version range for the\\nreserved manifest \\\"architecture-02-well-architected-review\\\" so consumers and the\\ncore can validate compatibility; update the proposal text to state the required\\ncore version range (e.g., a semver range such as \\\">=X.Y.Z \\n\\n\\n\\n\",\"path\":\"openspec/changes/architecture-02-module-well-architected/proposal.md\",\"side\":\"RIGHT\",\"line\":13}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a top-level H1 as the first line.**\\n\\nThe file starts with `## Context`; markdownlint MD041 requires the first line to be a level-1 heading.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 1-1: First line in a file should be a top-level heading\\n\\n(MD041, first-line-heading, first-line-h1)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/codebase-import-runtime-hardening/design.md` at line 1, The\\ndocument begins with a level-2 heading (\\\"## Context\\\") which violates\\nmarkdownlint MD041; add a top-level H1 as the very first line (for example \\\"#\\nDesign\\\" or another project-appropriate title) before the existing \\\"## Context\\\"\\nheading so the file starts with a level-1 heading and MD041 is satisfied.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/design.md\",\"side\":\"RIGHT\",\"line\":3}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Insert blank lines after section headings to satisfy MD022.**\\n\\nHeadings at these lines are missing the required surrounding blank-line spacing.\\n\\n\\n\\nAlso applies to: 38-38, 48-48, 58-58\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 24-24: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/codebase-import-runtime-hardening/design.md` at line 24, Add\\na blank line after each section heading to satisfy MD022: insert an empty line\\nimmediately after \\\"Decision 1: Introduce a shared import path policy helper\\\" and\\nlikewise after the other headings referenced (the headings at the other noted\\nlocations), ensuring each heading is followed by a single blank line before the\\nparagraph content.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/design.md\",\"side\":\"RIGHT\",\"line\":26}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Use a top-level H1 before the requirement delta section.**\\n\\nStarting at H2 triggers MD041 and can fail docs lint gates.\\n\\n

\\n

Suggested change

\\n\\n```diff\\n+# Bundle packaged resources specification delta\\n+\\n ## MODIFIED Requirements\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 1-1: First line in a file should be a top-level heading\\n\\n(MD041, first-line-heading, first-line-h1)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\\nat line 1, Add a top-level H1 heading before the \\\"## MODIFIED Requirements\\\"\\nsection to avoid triggering MD041; specifically insert an H1 like \\\"# Requirement\\nChanges\\\" or \\\"# Changelog\\\" immediately above the existing \\\"## MODIFIED\\nRequirements\\\" header so the document begins with an H1 before any H2s (update\\nthe heading text as appropriate for the spec).\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md\",\"side\":\"RIGHT\",\"line\":3}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Fix heading-structure lint warnings (MD041/MD022).**\\n\\nLine 1 starts at `##` and multiple headings are missing required surrounding blank lines, which leaves documented markdownlint warnings unresolved.\\n\\n

\\n

Suggested markdown cleanup

\\n\\n```diff\\n-## ADDED Requirements\\n+# Codebase Import Runtime Hardening\\n+\\n+## ADDED Requirements\\n \\n ### Requirement: Import runtime SHALL prune hidden and heavyweight trees before discovery\\n+\\n `specfact code import` SHALL apply one deterministic ignore policy before any repository traversal phase counts, discovers, or analyzes candidate files. The default policy SHALL exclude dot-prefixed directories, virtual environments, build outputs, dependency caches, and other heavyweight artifact roots unless the user explicitly targets a path inside them.\\n \\n #### Scenario: Default traversal skips hidden and heavyweight directories\\n+\\n - **WHEN** the user runs `specfact code import` against a repository root that contains directories such as `.git/`, `.specfact/`, `.venv/`, `venv/`, `node_modules/`, `build/`, `dist/`, or `__pycache__/`\\n ...\\n```\\n

\\n\\n\\nBased on learnings: Fix SpecFact code review findings, including warnings, unless a rare explicit exception is documented.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 1-1: First line in a file should be a top-level heading\\n\\n(MD041, first-line-heading, first-line-h1)\\n\\n---\\n\\n[warning] 3-3: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n---\\n\\n[warning] 6-6: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n---\\n\\n[warning] 11-11: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n---\\n\\n[warning] 16-16: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n---\\n\\n[warning] 19-19: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n---\\n\\n[warning] 24-24: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n---\\n\\n[warning] 29-29: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n---\\n\\n[warning] 32-32: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n---\\n\\n[warning] 37-37: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\naround lines 1 - 40, The markdown has lint warnings from missing blank lines\\naround headings (MD041/MD022); edit the section headings such as \\\"ADDED\\nRequirements\\\", \\\"Requirement: Import runtime SHALL prune hidden and heavyweight\\ntrees before discovery\\\", \\\"Scenario: Default traversal skips hidden and\\nheavyweight directories\\\", \\\"Requirement: Import runtime SHALL surface\\nlarge-artifact warnings\\\", and \\\"Requirement: Import progress SHALL use\\ndiscovered-versus-processed work\\\" to ensure there is a single blank line above\\nand below each heading and between consecutive headings/paragraphs so each\\nheading is properly separated and no multiple consecutive headings lack\\nintervening blank lines; keep the existing heading text and indentation but\\ninsert the required blank lines consistently throughout the document to resolve\\nMD041/MD022.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n**Clarify `.specfact/.specfactignore` loading before dot-dir pruning.**\\n\\nLine 4 says dot-prefixed directories are excluded by default, but Lines 12-14 require `.specfact/.specfactignore` to be merged for traversal. Please state the precedence explicitly so implementations don’t diverge.\\n\\n

\\n

Suggested clarification

\\n\\n```diff\\n-`specfact code import` SHALL apply one deterministic ignore policy before any repository traversal phase counts, discovers, or analyzes candidate files. The default policy SHALL exclude dot-prefixed directories, virtual environments, build outputs, dependency caches, and other heavyweight artifact roots unless the user explicitly targets a path inside them.\\n+`specfact code import` SHALL apply one deterministic ignore policy before any repository traversal phase counts, discovers, or analyzes candidate files. The runtime SHALL load `.specfact/.specfactignore` (when present) before recursive traversal, then apply the merged policy. The default policy SHALL exclude dot-prefixed directories, virtual environments, build outputs, dependency caches, and other heavyweight artifact roots unless the user explicitly targets a path inside them.\\n```\\n

\\n\\n\\nAs per coding guidelines: `openspec/**/*.md`: Specification truth: proposal/tasks/spec deltas vs. bundle behavior, CHANGE_ORDER, and drift vs. shipped modules or docs.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 6-6: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n---\\n\\n[warning] 11-11: Headings should be surrounded by blank lines\\nExpected: 1; Actual: 0; Below\\n\\n(MD022, blanks-around-headings)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\naround lines 4 - 14, Clarify the precedence: state that when `specfact code\\nimport` runs the implementation MUST first load the deterministic default ignore\\npolicy (which excludes dot-prefixed directories like `.git/`, `.specfact/`,\\nvirtualenvs, `node_modules/`, etc.), then read and merge repository-local\\npatterns from `.specfact/.specfactignore` into that policy (repository-local\\npatterns augment and can override conflicting default patterns), and finally\\napply any explicit user target paths which may re-include a path inside an\\nignored root; ensure this explicit ordering (default -> merge\\n`.specfact/.specfactignore` -> explicit target override) is added to the spec so\\npruning happens before traversal and precedence is unambiguous.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md\",\"side\":\"RIGHT\",\"line\":25}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a top-level H1 heading for MD041 compliance.**\\n\\nThe file begins with `## 1.` but OpenSpec task documents should start with an H1 (e.g., `# Tasks: codebase-import-runtime-hardening`) to satisfy markdownlint MD041 and maintain parity with other task files that include H1 headings.\\n\\n\\n\\n

\\n

Proposed fix

\\n\\n```diff\\n+# Tasks: codebase-import-runtime-hardening\\n+\\n ## 1. GitHub readiness and change scaffolding\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 1-1: First line in a file should be a top-level heading\\n\\n(MD041, first-line-heading, first-line-h1)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/codebase-import-runtime-hardening/tasks.md` at line 1, Add a\\ntop-level H1 heading to the document (replace the current leading \\\"## 1. GitHub\\nreadiness and change scaffolding\\\" start) so the file begins with an H1 like \\\"#\\nTasks: codebase-import-runtime-hardening\\\" to satisfy MD041 and match other task\\nfiles; ensure the existing content remains unchanged after the new H1.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/tasks.md\",\"side\":\"RIGHT\",\"line\":3}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a top-level H1 to satisfy Markdown linting.**\\n\\nThis spec starts at H2, which triggers MD041 and can fail doc-quality gates.\\n\\n

\\n

Suggested change

\\n\\n```diff\\n+# Enterprise policy client specification delta\\n+\\n ## ADDED Requirements\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 1-1: First line in a file should be a top-level heading\\n\\n(MD041, first-line-heading, first-line-h1)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\\nat line 1, Add a top-level H1 above the existing H2 \\\"ADDED Requirements\\\" in the\\nspec.md (e.g., \\\"Enterprise Policy Client\\\" or another concise title) so the\\ndocument begins with an H1 to satisfy MD041; update the first line to a valid\\nMarkdown H1 and ensure the existing H2 remains unchanged.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md\",\"side\":\"RIGHT\",\"line\":3}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a top-level H1 to satisfy MD041.**\\n\\nLine 1 starts at H2 (`## Context`), which violates the configured markdown lint rule.\\n\\n

\\n

Suggested fix

\\n\\n```diff\\n+# Enterprise audit client design\\n+\\n ## Context\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 1-1: First line in a file should be a top-level heading\\n\\n(MD041, first-line-heading, first-line-h1)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/enterprise-02-module-audit-client/design.md` at line 1, The\\ndocument begins with an H2 (\\\"## Context\\\") which triggers MD041; add a top-level\\nH1 above the existing \\\"## Context\\\" header (e.g., \\\"# Context\\\" or a suitable\\nproject/title H1) so the file starts with an H1, leaving the existing \\\"##\\nContext\\\" as-is to preserve structure.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/enterprise-02-module-audit-client/design.md\",\"side\":\"RIGHT\",\"line\":3}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🔴 Critical_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Verify enterprise-02-rbac-and-audit-trail exists in specfact-cli\\n\\nrg -n --type=md -C3 'enterprise-02-rbac-and-audit-trail' || echo \\\"Core dependency not found in current context\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 7176\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for the paired core change in specfact-cli\\nrg -n --type=md 'enterprise-02-rbac-and-audit-trail' -C2 || echo \\\"No matches found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 80\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Look for CHANGE_ORDER or similar tracking doc for core changes\\nfind . -name \\\"CHANGE_ORDER*\\\" -o -name \\\"*change*order*\\\" | head -10\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 90\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check for spec or proposal files mentioning enterprise audit\\nfind . -type f -name \\\"*.md\\\" | xargs grep -l \\\"enterprise.*audit\\\" 2>/dev/null | head -10\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 121\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read specfact-cli CHANGE_ORDER to see what core changes are planned\\ncat -n ./openspec/CHANGE_ORDER.md | head -150\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 12624\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for any enterprise references at all\\nrg -n 'enterprise' --type=md\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 30644\\n\\n---\\n\\n\\n\\n

\\n\\n**Paired core change `enterprise-02-rbac-and-audit-trail` does not exist in specfact-cli.**\\n\\nThe modules spec at line 7 declares a hard dependency on `enterprise-02-rbac-and-audit-trail` for enterprise RBAC, audit trail, and audit-event contracts. Verification of specfact-cli's CHANGE_ORDER.md (current through April 2026) found no such core change proposed, merged, or scheduled. This spec cannot be implemented until the paired core change is proposed and merged into specfact-cli. Coordinate with specfact-cli maintainers to establish the core audit trail and RBAC contracts before implementing this bundle. If the core change is planned but not yet documented, update this spec's requirement to reference the correct issue or change proposal.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\\nat line 7, The spec declares a hard core dependency on\\nenterprise-02-rbac-and-audit-trail for the nold-ai/specfact-enterprise-audit\\nbundle but that core change does not exist; update\\nenterprise-audit-client/spec.md to remove or replace the nonexistent core change\\nreference in the core_compatibility and dependency text (replace\\nenterprise-02-rbac-and-audit-trail with the correct existing change ID or a TODO\\nplaceholder), and add a note that implementation is blocked until the paired\\ncore change is proposed/merged and the spec's core_compatibility entry is\\nupdated.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Strong cross-change coordination, but clarify telemetry dependency type.**\\n\\nLine 7 correctly references `CHANGE_ORDER.md` for coordination with `telemetry-01-opentelemetry-default-on`, demonstrating awareness of cross-change dependencies. However, the parenthetical doesn't clarify whether `telemetry-01` is a `bundle_dependencies` entry, a `core_compatibility` requirement, or just a sequencing constraint.\\n\\n\\n

\\n

📋 Proposed clarification

\\n\\n```diff\\n-The modules repository SHALL provide a signed official bundle named `nold-ai/specfact-finops` that exposes the `finops` command and declares truthful bundle dependencies, pip dependencies, and `core_compatibility` for the paired core FinOps evidence contract from `finops-01-telemetry-and-outcomes` (including any telemetry prerequisites coordinated with `telemetry-01-opentelemetry-default-on` as documented in `openspec/CHANGE_ORDER.md`).\\n+The modules repository SHALL provide a signed official bundle named `nold-ai/specfact-finops` that exposes the `finops` command and declares truthful bundle dependencies, pip dependencies, and `core_compatibility` for the paired core FinOps evidence contract from `finops-01-telemetry-and-outcomes`. If telemetry integration is required, the bundle SHALL declare `core_compatibility` for `telemetry-01-opentelemetry-default-on` as coordinated in `openspec/CHANGE_ORDER.md`.\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\\nat line 7, The spec references coordination with\\ntelemetry-01-opentelemetry-default-on but doesn't state whether that change is a\\nbundle dependency, a core_compatibility requirement, or only a sequencing\\nconstraint; update the sentence for nold-ai/specfact-finops to explicitly state\\nhow telemetry-01-opentelemetry-default-on is represented (e.g., add it to\\nbundle_dependencies, list it under core_compatibility, or note it as a\\nsequencing prerequisite) and ensure the manifest fields mentioned\\n(`bundle_dependencies`, `pip dependencies`, `core_compatibility`) clearly\\nindicate where telemetry-01 appears and that CHANGE_ORDER.md is the\\nauthoritative source for sequencing.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Clarify “update signatures” to avoid implying manual signature commits.**\\n\\nPlease tighten wording to indicate signatures are validated in gates and generated by publish automation, not hand-updated in the branch.\\n\\nBased on learnings, module tarball signatures in this repository are generated by the publish workflow runner and should not be treated as locally committed pre-merge artifacts.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/finops-01-module-cost-outcome/tasks.md` at line 19, Edit the\\ntask bullet that currently reads \\\"3.4 Update registry metadata, docs references,\\nsignatures, and any import allowlists required by the new bundle.\\\" to clarify\\nthat \\\"signatures\\\" are validated by gates and created by the publish automation\\nrather than manually committed; e.g., change the phrase to something like\\n\\\"update registry metadata, docs references, and any import allowlists required\\nby the new bundle (signatures are validated by CI gates and produced by publish\\nautomation—not committed manually)\\\"; update the text near the 3.4 task in\\ntasks.md accordingly.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/finops-01-module-cost-outcome/tasks.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🔴 Critical_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Check for stable core knowledge schema and MemoryBackend protocol\\n\\nrg -n --type=py -C3 'class MemoryBackend|knowledge.*schema|distillation.*engine' || echo \\\"Core knowledge contracts not found in current context\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 125\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read the design.md file to understand context\\ncat -n openspec/changes/knowledge-01-module-memory-runtime/design.md | head -80\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 3829\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for MemoryBackend and core knowledge schema in specfact-cli\\nrg -n 'class MemoryBackend|MemoryBackend.*Protocol|knowledge.*schema|CoreKnowledge' -A5 -B2 --type=py || echo \\\"No matches found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 80\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Also search for distillation and runtime integration patterns\\nrg -n 'distillation.*engine|runtime.*integration|schema.*stable' -A3 -B2 --type=py --type=md || echo \\\"No matches found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 8492\\n\\n---\\n\\n\\n\\n

\\n\\n**Flag missing or undiscovered MemoryBackend protocol contract in specfact-cli.**\\n\\nThe design assumes a \\\"paired core MemoryBackend protocol\\\" (line 3, goal on line 10), but searches in specfact-cli find no definition or public API for this protocol. Migration step 1—confirming schema and protocol stability—is a blocking dependency for the markdown-graph backend implementation. Before proceeding, coordinate with specfact-cli to either:\\n- Publish the MemoryBackend protocol definition and confirm its stability, OR\\n- Add this to the paired core change scope if not yet delivered.\\n\\nThis is a critical integration contract between the two repositories.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-01-module-memory-runtime/design.md` at line 48,\\nThe design references a paired core MemoryBackend protocol that isn't published\\nin specfact-cli; confirm and record this contract by coordinating with\\nspecfact-cli to either (A) publish the MemoryBackend protocol definition and\\nversion/stability statement (ensure the exported symbol is named MemoryBackend\\nand its public API/JSON schema is documented), or (B) add the MemoryBackend\\nprotocol to the paired core change scope and include its authoritative spec in\\nthis repo's design document (update \\\"migration step 1\\\" to reference the exact\\nprotocol artifact, version, and where it is published). Ensure the design.md\\nexplicitly points to the published spec (or pairing ticket) and notes the\\nrequired stability guarantee so the markdown-graph MemoryBackend integration can\\nproceed.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/knowledge-01-module-memory-runtime/design.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Optional: Vary sentence structure to improve readability.**\\n\\nThe static analysis tool noted that lines 9-13 begin with repeated \\\"**NEW**:\\\" markers. While this is a valid formatting choice for a changelog-style proposal, consider varying the structure if readability becomes a concern.\\n\\n\\n\\nExample alternative:\\n```diff\\n - **NEW**: Add a `specfact-knowledge` bundle with `memory` subcommands for logging, searching, promoting, and distilling.\\n - **NEW**: Package the markdown-graph backend as the default runtime implementation for evidence, learnings, and rules under `.specfact/memory/`.\\n-- **NEW**: Define gitignore, repo-layout, and file-lifecycle expectations for evidence, learnings, rules, and generated graph metadata.\\n-- **NEW**: Add search and status surfaces that expose the paired core `MemoryBackend` behavior without requiring a vector store.\\n+- **DEFINE**: Gitignore, repo-layout, and file-lifecycle expectations for evidence, learnings, rules, and generated graph metadata.\\n+- **EXPOSE**: Search and status surfaces that leverage the paired core `MemoryBackend` behavior without requiring a vector store.\\n```\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ...nd rules under `.specfact/memory/`. - **NEW**: Define gitignore, repo-layout, and f...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n---\\n\\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ...ules, and generated graph metadata. - **NEW**: Add search and status surfaces that ...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-01-module-memory-runtime/proposal.md` around lines\\n9 - 13, Rephrase the repeated \\\"**NEW**:\\\" bullets to improve readability by\\nvarying sentence structure: e.g., keep one \\\"**NEW**:\\\" header for the group and\\nturn the rest into action-starting phrases (\\\"Add a `specfact-knowledge` bundle\\nwith `memory` subcommands...\\\", \\\"Package the markdown-graph backend as the\\ndefault runtime...\\\", \\\"Define gitignore, repo-layout, and file-lifecycle...\\\",\\n\\\"Add search and status surfaces exposing `MemoryBackend` behavior...\\\") or\\ncombine related items into a single sentence; target the lines mentioning\\n`specfact-knowledge`, `memory` subcommands, `markdown-graph backend`,\\n`.specfact/memory/`, and `MemoryBackend` when applying the edits.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/knowledge-01-module-memory-runtime/proposal.md\",\"side\":\"RIGHT\",\"line\":13}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🔴 Critical_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Verify knowledge-01-distillation-engine exists in specfact-cli\\n\\nrg -n --type=md -C3 'knowledge-01-distillation-engine' || echo \\\"Core dependency not found in current context\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 4934\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for knowledge-01-distillation-engine in specfact-cli\\n\\n# Look for the change folder\\nfind . -type d -name \\\"*knowledge-01-distillation-engine*\\\" 2>/dev/null\\n\\n# Search for references to the change\\nrg -n \\\"knowledge-01-distillation-engine\\\" --type=md -C 2 || echo \\\"Search completed\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 80\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for openspec structure and knowledge-related changes\\n\\necho \\\"=== Check for openspec/changes directory ===\\\"\\nfind . -type d -path \\\"*/openspec/changes*\\\" 2>/dev/null | head -20\\n\\necho -e \\\"\\\\n=== Search for any knowledge-related changes ===\\\"\\nrg -i \\\"knowledge.*distill|distill.*knowledge\\\" --type=md || echo \\\"No matches\\\"\\n\\necho -e \\\"\\\\n=== Check CHANGE_ORDER or similar in specfact-cli ===\\\"\\nfind . -name \\\"CHANGE_ORDER*\\\" -o -name \\\"*change*order*\\\" 2>/dev/null | head -10\\n\\necho -e \\\"\\\\n=== Check openspec root structure ===\\\"\\nls -la openspec/ 2>/dev/null || echo \\\"No openspec directory\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 1863\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check CHANGE_ORDER for knowledge-01-distillation-engine\\n\\necho \\\"=== Search for knowledge in CHANGE_ORDER.md ===\\\"\\nrg -n \\\"knowledge|distill\\\" openspec/CHANGE_ORDER.md -C 3\\n\\necho -e \\\"\\\\n=== Check overall structure of CHANGE_ORDER ===\\\"\\nhead -100 openspec/CHANGE_ORDER.md\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 6073\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Comprehensive search for any knowledge-related content\\n\\necho \\\"=== All directories under openspec/changes ===\\\"\\nls openspec/changes/ | grep -i knowledge || echo \\\"No knowledge directories\\\"\\n\\necho -e \\\"\\\\n=== Full CHANGE_ORDER text search for 'knowledge' (case-insensitive) ===\\\"\\ngrep -i \\\"knowledge\\\" openspec/CHANGE_ORDER.md || echo \\\"No knowledge mentions\\\"\\n\\necho -e \\\"\\\\n=== All pending changes sections ===\\\"\\ntail -200 openspec/CHANGE_ORDER.md | head -100\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 9605\\n\\n---\\n\\n\\n\\n

\\n\\n**Core change `knowledge-01-distillation-engine` must be merged to specfact-cli before module implementation can proceed.**\\n\\nThe paired core change does not yet exist in `nold-ai/specfact-cli`. This is a blocking dependency per tasks.md (task 1.2). Create `openspec/changes/knowledge-01-distillation-engine` in the core repository, merge it, document the contract stability, and establish cross-repo compatibility requirements in `TDD_EVIDENCE.md` before proceeding with module implementation. Align the core change folder name with the contract referenced here.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-01-module-memory-runtime/proposal.md` at line 29,\\nCreate and merge the paired core change repository folder\\nopenspec/changes/knowledge-01-distillation-engine into the nold-ai/specfact-cli\\nrepo (ensuring the folder name exactly matches the contract referenced in this\\nmodule), document the contract stability and cross-repo compatibility\\nrequirements in TDD_EVIDENCE.md, and confirm the core change is merged into\\nspecfact-cli before proceeding with the module implementation so the module’s\\ndependency on knowledge-01-distillation-engine is satisfied.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/knowledge-01-module-memory-runtime/proposal.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add an H1 at file start to avoid MD041 lint violations.**\\n\\nCurrent first heading is H2, which can break markdown quality checks.\\n\\n

\\n

Suggested change

\\n\\n```diff\\n+# Knowledge memory runtime specification delta\\n+\\n ## ADDED Requirements\\n```\\n

\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 1-1: First line in a file should be a top-level heading\\n\\n(MD041, first-line-heading, first-line-h1)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\\nat line 1, The file currently starts with an H2 which triggers MD041; fix by\\nadding a top-level H1 as the very first line of\\nopenspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md\\n(e.g., \\\"# Knowledge Memory Runtime\\\") so the existing H2 becomes a secondary\\nheading — ensure the H1 is descriptive for the module and placed before any\\nother content or headings.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md\",\"side\":\"RIGHT\",\"line\":3}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a top-level H1 heading for MD041 compliance.**\\n\\nThe design document starts with `## Context` but should include an H1 title (e.g., `# Design: knowledge-02-module-writeback`) for consistency with markdownlint MD041 and other OpenSpec design docs.\\n\\n\\n\\n

\\n

Proposed fix

\\n\\n```diff\\n+# Design: knowledge-02-module-writeback\\n+\\n ## Context\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 1-1: First line in a file should be a top-level heading\\n\\n(MD041, first-line-heading, first-line-h1)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-02-module-writeback/design.md` at line 1, Add a\\ntop-level H1 heading above the existing \\\"## Context\\\" heading in the design.md to\\nsatisfy MD041; for consistency with other OpenSpec docs use a title like \\\"#\\nDesign: knowledge-02-module-writeback\\\" placed immediately before the \\\"##\\nContext\\\" section so the file begins with an H1 followed by the existing\\nsubsections.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/knowledge-02-module-writeback/design.md\",\"side\":\"RIGHT\",\"line\":3}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Define the writeback adapter contract.**\\n\\nLines 10-12 describe adapters for `BUGBOT.md`, `.github/copilot-instructions.md`, and CodeRabbit drafts, plus deterministic manifests, but don't specify the adapter interface that writeback targets must implement or the manifest schema for audit trails. Clear adapter boundaries prevent implementation drift and ensure deterministic output across targets.\\n\\n\\nConsider adding an \\\"Adapter Contract\\\" or \\\"Writeback Interface\\\" subsection that defines:\\n- The adapter method signature (inputs: memory rules; outputs: preview content + manifest)\\n- The deterministic manifest schema for lineage/audit metadata\\n- Whether adapters validate target destinations or assume caller validation\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n[uncategorized] ~10-~10: The official name of this software platform is spelled with a capital “H”.\\nContext: ...EW**: Package adapters for `BUGBOT.md`, `.github/copilot-instructions.md`, and CodeRabbi...\\n\\n(GITHUB)\\n\\n---\\n\\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ...drafts as opt-in writeback targets. - **NEW**: Require preview/dry-run output and e...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n---\\n\\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ...eviewable and safe for repo owners. - **NEW**: Normalize selected rule metadata int...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md` around lines 10 -\\n12, Add an \\\"Adapter Contract\\\" (or \\\"Writeback Interface\\\") subsection that\\nspecifies the adapter method signature and manifest schema: define a\\nfunction-like contract (e.g., adapter receives selected memory rules and\\ndestination metadata and returns { previewContent, writebackManifest }) and\\nenumerate manifest fields required for deterministic lineage/audit (ruleIds,\\nruleVersions, inputDigest, outputDigest, timestamp, adapterId, destination,\\npreviewHash, dryRunFlag); state whether adapters MUST validate destinations or\\nrely on caller validation and clarify error/validation semantics for preview\\ngeneration vs. final writeback; include example field types and required vs\\noptional fields so all implementations (BUGBOT.md adapter,\\n.github/copilot-instructions.md adapter, CodeRabbit draft adapter) follow the\\nsame deterministic output and manifest format.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/knowledge-02-module-writeback/proposal.md\",\"side\":\"RIGHT\",\"line\":12}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Specify `bundle_dependencies` and `core_compatibility` requirements.**\\n\\nLine 29 states this bundle depends on module `knowledge-01-module-memory-runtime` and core change `knowledge-02-preflight-context-assembly`, but the proposal doesn't define the expected `bundle_dependencies` or `core_compatibility` version ranges for the reserved manifest. These metadata fields are critical for registry discoverability and runtime dependency resolution.\\n\\n\\n

\\n

📋 Proposed addition to Impact section

\\n\\n```diff\\n - Dependencies: paired core change `knowledge-02-preflight-context-assembly`; module dependency `knowledge-01-module-memory-runtime`.\\n-- Release impact: introduces a new signed official bundle and registry entry.\\n+- Release impact: introduces a new signed official bundle and registry entry, with `bundle_dependencies: [knowledge-01-module-memory-runtime]` and `core_compatibility` for `knowledge-02-preflight-context-assembly`.\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md` around lines 29 -\\n30, Add explicit reserved-manifest metadata: define bundle_dependencies and\\ncore_compatibility version ranges for this bundle. In the Impact/Release section\\nspecify bundle_dependencies including \\\"knowledge-01-module-memory-runtime\\\" with\\na semver range (e.g., >=X.Y.Z \\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/knowledge-02-module-writeback/proposal.md\",\"side\":\"RIGHT\",\"line\":37}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Define the findings adapter contract to the core model.**\\n\\nLines 10-12 describe rule packs and findings emission \\\"in the shared review report shape\\\" but don't specify the adapter boundary that normalizes resiliency detections into the paired core findings contract. Without this definition, implementations may produce incompatible finding schemas.\\n\\n\\nConsider adding an \\\"Adapter Contract\\\" subsection under \\\"What Changes\\\" that defines:\\n- The core findings schema fields this bundle must populate for resiliency violations\\n- The stable rule identifiers and evidence reference format\\n- How severity/confidence scoring maps to the core findings model\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ... the paired core findings contract. - **NEW**: Add optional probe adapters for ligh...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n---\\n\\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ...s stay local-first and safe for CI. - **NEW**: Emit findings in the shared review r...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` around lines 10 -\\n12, Add an \\\"Adapter Contract\\\" subsection under the \\\"What Changes\\\" section that\\nexplicitly defines the adapter boundary that normalizes resiliency detections\\ninto the core findings model: list the exact core findings schema fields the\\nbundle must populate (e.g., id, title, description, location, timestamp,\\nseverity, confidence, evidence_refs), specify the stable rule identifier format\\nand examples for rule IDs used by the resiliency rule packs, define the evidence\\nreference format/namespace (how to reference probe logs, traces, or\\nmemory-evidence), and describe the mapping rules for severity and confidence\\nscoring into the core findings fields so implementations produce a stable,\\ncompatible findings payload.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/review-resiliency-01-module/proposal.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Clarify `core_compatibility` and optional `bundle_dependencies` handling.**\\n\\nLine 29 states the bundle has an optional integration with `knowledge-01-module-memory-runtime`, and Line 30 mentions a new `module-package.yaml`, but the proposal doesn't define:\\n- The `core_compatibility` version range for `review-resiliency-01-contracts`\\n- Whether optional module dependencies are declared in `bundle_dependencies` with feature-gating or omitted entirely\\n\\nThese metadata semantics affect runtime bundle loading and registry resolution.\\n\\n\\n

\\n

📋 Proposed clarification in Impact section

\\n\\n```diff\\n - Dependencies: paired core change `review-resiliency-01-contracts`; optional knowledge integration with `knowledge-01-module-memory-runtime`.\\n-- Release impact: introduces a new signed official bundle with a new `module-package.yaml` and registry entry.\\n+- Release impact: introduces a new signed official bundle with a new `module-package.yaml` declaring `core_compatibility` for `review-resiliency-01-contracts` and optional `bundle_dependencies` for knowledge evidence forwarding (gated behind runtime availability checks).\\n```\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` around lines 29 -\\n30, Specify the exact core_compatibility range for\\nreview-resiliency-01-contracts (e.g., semver range or platform version token) in\\nmodule-package.yaml and explicitly state the semantics for optional\\nintegrations: declare knowledge-01-module-memory-runtime under\\nbundle_dependencies with a feature flag key (or attribute) marking it as\\noptional/feature-gated, and describe registry resolution behavior when the\\nfeature flag is absent versus present; reference the module-package.yaml,\\ncore_compatibility, bundle_dependencies, review-resiliency-01-contracts, and\\nknowledge-01-module-memory-runtime symbols in the Impact section.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/review-resiliency-01-module/proposal.md\",\"side\":\"RIGHT\",\"line\":60}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Clarify whether this bundle exposes one command or multiple scanner-specific commands.**\\n\\nLine 9 mentions \\\"command ownership\\\" for the `specfact-security` bundle, but the design doesn't specify whether the bundle surface is:\\n- A single `security` command with scanner selection flags (e.g., `--sast`, `--sca`, `--secrets`)\\n- Multiple commands (e.g., `sast`, `sca`, `sbom`, `secrets`)\\n- A hybrid approach\\n\\nThis command surface design affects discoverability, user workflow, and how the bundle declares commands in `module-package.yaml`.\\n\\n\\nConsider adding a \\\"Command Surface\\\" subsection under \\\"Decisions\\\" that defines the primary command(s) and their relationship to the four scanner classes.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md` at line 9, Add\\na \\\"Command Surface\\\" subsection under the \\\"Decisions\\\" section of the\\nspecfact-security design that explicitly states whether the bundle exposes a\\nsingle command or multiple scanner-specific commands and how they map to the\\nfour scanner classes (sast, sca, sbom, secrets); update the document to declare\\nthe chosen approach (single `security` command with flags like\\n--sast/--sca/--secrets, separate commands `sast`/`sca`/`sbom`/`secrets`, or a\\nhybrid) and describe the rationale for discoverability and how commands will be\\ndeclared in module-package.yaml so implementers know whether to register\\n`specfact-security:security` or individual commands such as\\n`specfact-security:sast`.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/security-01-module-sast-sca-secret/design.md\",\"side\":\"RIGHT\",\"line\":9}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Migration plan covers registry/docs/signatures but lacks `core_compatibility` specifics.**\\n\\nLine 50 mentions \\\"registry entry, docs, signatures, and compatibility range\\\" as part of the release unit, which addresses the metadata concerns. However, the design doesn't specify:\\n- The expected `core_compatibility` version constraint format\\n- Which core contract version(s) the initial release will target\\n- Whether `bundle_dependencies` are expected (e.g., on a policy bundle)\\n\\nThese details could be deferred to the proposal or spec, but noting them here would help implementation planning.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md` around lines\\n48 - 50, Add explicit core_compatibility details to the migration plan: specify\\nthe expected version constraint format (e.g., semver range like \\\">=X.Y.Z\\n=1.2.0\\\"). Update the \\\"registry entry, docs, signatures, and\\ncompatibility range\\\" line to include these three concrete items so implementers\\nknow the exact core_compatibility string format, the targeted core contract\\nversions, and the expectation for bundle_dependencies.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/security-01-module-sast-sca-secret/design.md\",\"side\":\"RIGHT\",\"line\":54}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🔴 Critical_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Verify both core dependencies exist in specfact-cli\\n\\nrg -n --type=md -C3 'security-01-unified-findings-model|policy-02-packs-and-modes' || echo \\\"Core dependencies not found in current context\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 30153\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for security-01-unified-findings-model in specfact-cli\\nrg -n --type=md -C2 'security-01-unified-findings-model' || echo \\\"security-01-unified-findings-model not found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 108\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for policy-02-packs-and-modes in specfact-cli\\nrg -n --type=md -C2 'policy-02-packs-and-modes' || echo \\\"policy-02-packs-and-modes not found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 10347\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check CHANGE_VALIDATION status for policy-02-packs-and-modes\\nfd -e \\\"CHANGE_VALIDATION.md\\\" -x grep -l \\\"policy-02-packs-and-modes\\\" {} \\\\;\\ncat openspec/changes/policy-02-packs-and-modes/CHANGE_VALIDATION.md 2>/dev/null || echo \\\"No validation file found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1272\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# More comprehensive search for security findings model\\nrg -n 'security-01' --type=md --type=py || echo \\\"No security-01 results in specfact-cli\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 102\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check CHANGE_ORDER.md for all security changes\\ncat openspec/CHANGE_ORDER.md | grep -i \\\"security\\\" | head -30\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 367\\n\\n---\\n\\n\\n\\n

\\n\\n**Verify `core_compatibility` entries—`security-01-unified-findings-model` does not exist in `specfact-cli`, and `policy-02-packs-and-modes` is a module change, not a core change.**\\n\\nSpecification declares `core_compatibility` entries for both `security-01-unified-findings-model` and `policy-02-packs-and-modes`, but:\\n\\n- `security-01-unified-findings-model` does not appear in `specfact-cli` (not found in any change or proposal)\\n- `policy-02-packs-and-modes` is explicitly moved to `specfact-cli-modules` and is not a core `specfact-cli` change (per `specfact-cli` CHANGE_ORDER.md line 298: \\\"no active core change folder remains\\\")\\n\\nRevise the spec to either remove the policy-pack dependency or recategorize it as a module-level bundle dependency rather than a core contract. If `security-01-unified-findings-model` is intended as a core contract, confirm it exists or is being proposed in `specfact-cli` before merging this spec.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\\nat line 7, Update the `nold-ai/specfact-security` spec to correct the\\n`core_compatibility` declarations: if `security-01-unified-findings-model` is\\nnot an accepted core contract, remove it from `core_compatibility` or add a\\ncorresponding proposal in `specfact-cli` first; for `policy-02-packs-and-modes`,\\nchange its entry from a core `core_compatibility` to a module-level bundle\\ndependency (e.g., list it under bundle/pip dependencies) since it lives in\\n`specfact-cli-modules`; ensure the spec no longer claims core compatibility for\\nnon-core items and clearly documents the dependency locations for both\\n`security-01-unified-findings-model` and `policy-02-packs-and-modes`.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Verify referenced core changes exist in specfact-cli\\n\\n# Check if core changes are documented/implemented\\necho \\\"Searching for core dependency references in specfact-cli...\\\"\\nrg -n --type=md -C3 'security-01-unified-findings-model|policy-02-packs-and-modes' || echo \\\"Core changes not found in current context\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 30213\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for security-01-unified-findings-model in specfact-cli\\necho \\\"=== Searching for security-01-unified-findings-model in specfact-cli ===\\\"\\nrg -n --type=md 'security-01-unified-findings-model' 2>/dev/null || echo \\\"Pattern not found in specfact-cli markdown files\\\"\\necho \\\"\\\"\\necho \\\"=== Checking for openspec/changes directory structure ===\\\"\\nfd -t d 'security-01' openspec/changes 2>/dev/null || echo \\\"No matching directories found\\\"\\necho \\\"\\\"\\necho \\\"=== Checking CHANGE_ORDER.md for references ===\\\"\\nfd -n 'CHANGE_ORDER' | head -5 | xargs -I {} grep -n 'security-01' {} 2>/dev/null || echo \\\"Not found in CHANGE_ORDER\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 541\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check overall structure and look for security/findings related content\\necho \\\"=== Checking for openspec directory ===\\\"\\nls -la openspec/ 2>/dev/null | head -20 || echo \\\"No openspec directory\\\"\\necho \\\"\\\"\\necho \\\"=== Search for 'findings' or 'security' in markdown files ===\\\"\\nrg -i 'findings.*model|unified.*findings' --type=md 2>/dev/null | head -20 || echo \\\"Pattern not found\\\"\\necho \\\"\\\"\\necho \\\"=== List main specfact-cli structure ===\\\"\\nls -la 2>/dev/null | head -20\\necho \\\"\\\"\\necho \\\"=== Check if src/specfact_cli/security exists ===\\\"\\nfind . -type d -name '*security*' 2>/dev/null | head -10\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 2920\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check CHANGE_ORDER.md for security-related entries\\necho \\\"=== Searching CHANGE_ORDER.md for security references ===\\\"\\ngrep -n 'security-01' openspec/CHANGE_ORDER.md 2>/dev/null | head -20 || echo \\\"No security-01 found\\\"\\necho \\\"\\\"\\necho \\\"=== Searching for 'unified-findings' ===\\\"\\ngrep -n 'unified-findings\\\\|findings.*model' openspec/CHANGE_ORDER.md 2>/dev/null || echo \\\"Not found\\\"\\necho \\\"\\\"\\necho \\\"=== List all core changes in CHANGE_ORDER.md (first 100 lines) ===\\\"\\nhead -100 openspec/CHANGE_ORDER.md\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 6154\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if there are any pending changes listed for security in specfact-cli\\necho \\\"=== Searching entire CHANGE_ORDER.md for 'security' ===\\\"\\ngrep -i 'security' openspec/CHANGE_ORDER.md | head -30\\necho \\\"\\\"\\necho \\\"=== Check for all pending changes sections ===\\\"\\ngrep -n '## ' openspec/CHANGE_ORDER.md | tail -20\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 1611\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Let me check if there's a section about security-01 or findings model anywhere\\necho \\\"=== Checking if security-01-unified-findings-model exists in any openspec file ===\\\"\\nfind openspec -type f -name '*.md' -exec grep -l 'security-01-unified-findings-model' {} \\\\; 2>/dev/null || echo \\\"Not found in specfact-cli openspec\\\"\\necho \\\"\\\"\\necho \\\"=== Check if there are any planned security modules in specfact-cli ===\\\"\\nls -la openspec/changes/ | grep -i security || echo \\\"No security directories found\\\"\\necho \\\"\\\"\\necho \\\"=== Look at the 2026-02-15 architecture integration plan section more carefully ===\\\"\\nsed -n '262,310p' openspec/CHANGE_ORDER.md\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 5735\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for any reference to unified-findings or findings-model\\necho \\\"=== Broad search for unified-findings or findings model in all files ===\\\"\\ngrep -r 'unified-findings\\\\|findings.*model\\\\|findings-model' . --include='*.md' 2>/dev/null | grep -v '.git' | head -20 || echo \\\"Not found\\\"\\necho \\\"\\\"\\necho \\\"=== Check issues/GitHub references in CHANGE_ORDER.md for security ===\\\"\\ngrep -E '#[0-9]+.*security|security.*#[0-9]+' openspec/CHANGE_ORDER.md | head -10\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 1210\\n\\n---\\n\\n\\n\\n

\\n\\n**One of the referenced dependencies is not in specfact-cli; verify both changes exist before proceeding.**\\n\\nThis task requires confirming two dependencies before implementation:\\n\\n1. **`security-01-unified-findings-model`**: This change does not yet appear in the specfact-cli repository (no CHANGE_ORDER entry, no openspec/changes folder). Confirm it is planned or active before taking the cross-repo core compatibility dependency.\\n\\n2. **`policy-02-packs-and-modes`**: This change is in **specfact-cli-modules** (not specfact-cli); it's documented in specfact-cli-modules/openspec/CHANGE_ORDER.md line 49 and has a passing CHANGE_VALIDATION.md (2026-03-22). Verify the module-package.yaml and bundle registry semantics are final before binding core_compatibility.\\n\\nUpdate the task to explicitly confirm both are available (or acknowledge if security-01-unified-findings-model is still planned) and document the minimum core_compatibility versions.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md` at line 4,\\nUpdate the task text to explicitly verify both referenced changes before binding\\ncore compatibility: check that security-01-unified-findings-model exists in\\nspecfact-cli (if missing, mark it as \\\"planned/not yet present\\\" and reference\\nthat status), confirm policy-02-packs-and-modes is the module in\\nspecfact-cli-modules (cite its CHANGE_ORDER.md and CHANGE_VALIDATION.md\\nevidence), and record the minimum required core_compatibility versions against\\nboth plus any sequencing notes in TDD_EVIDENCE.md; also verify\\nmodule-package.yaml and bundle registry semantics for policy-02-packs-and-modes\\nare final before locking core_compatibility.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/security-01-module-sast-sca-secret/tasks.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a top-level H1 heading for MD041 compliance.**\\n\\nThe design document starts with `## Context` but should include an H1 title (e.g., `# Design: security-02-module-license-compliance`) for consistency.\\n\\n\\n\\n

\\n

Proposed fix

\\n\\n```diff\\n+# Design: security-02-module-license-compliance\\n+\\n ## Context\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/design.md` at line 1,\\nAdd a top-level H1 heading to this design doc to satisfy MD041; insert a line\\nlike \\\"# Design: security-02-module-license-compliance\\\" (or another appropriate\\ntitle) immediately before the existing \\\"## Context\\\" heading so the file begins\\nwith an H1 and retains the current \\\"## Context\\\" section unchanged.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/security-02-module-license-compliance/design.md\",\"side\":\"RIGHT\",\"line\":3}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Define the SBOM/SPDX adapter contract to core findings.**\\n\\nLines 10-11 describe \\\"SBOM ingestion and SPDX normalization adapters that feed the paired core security/license findings model,\\\" but don't specify the adapter boundary. Without this definition, implementations may produce findings schemas incompatible with the core model.\\n\\n\\nConsider adding an \\\"Adapter Contract\\\" subsection that defines:\\n- The core findings schema fields for license violations\\n- How SPDX license identifiers map to normalized finding types\\n- The evidence reference format for SBOM lineage\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` around\\nlines 10 - 11, Add an \\\"Adapter Contract\\\" subsection under the SBOM/SPDX adapter\\ndescription that specifies the exact boundary between adapters and the core\\nsecurity/license findings model: enumerate the core findings schema fields\\n(e.g., finding_id, package_name, package_version, license_id,\\nnormalized_license_type, severity, policy_state, confidence, timestamp), define\\nthe SPDX-to-normalized finding mapping rules (how SPDX identifiers map to\\nnormalized_license_type and license_id), and prescribe the evidence reference\\nformat for SBOM lineage (e.g., canonical SBOM source URL/ID, package entry path,\\ncomponent checksum and provenance fields). Ensure this contract is titled\\n\\\"Adapter Contract\\\" and referenced by \\\"SBOM ingestion and SPDX normalization\\nadapters\\\" and the \\\"core security/license findings model\\\" so implementations must\\nproduce findings compatible with these fields and mappings.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/security-02-module-license-compliance/proposal.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Define inter-bundle compatibility hooks and `core_compatibility` requirements.**\\n\\nLine 12 reserves manifest/registry/docs/signing, and Line 13 mentions \\\"compatibility hooks\\\" to share SBOM data with the broader security bundle, but the proposal doesn't define:\\n- The `core_compatibility` version range for `security-01-unified-findings-model`\\n- The inter-bundle hook interface (shared registry schema? file-based exports? bundle dependencies?)\\n- Whether the security bundle declares a `bundle_dependencies` on license-compliance or vice versa\\n\\nClear adapter boundaries prevent integration drift when bundles evolve independently.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ...face explicit remediation guidance. - **NEW**: Define bundle manifest, registry, do...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` around\\nlines 12 - 13, Specify concrete inter-bundle compatibility and adapter\\nboundaries: add a core_compatibility version range entry that references\\nsecurity-01-unified-findings-model (e.g., semver range) in the\\nlicense-compliance bundle manifest, define the inter-bundle hook interface\\n(choose and document a single approach such as a shared registry schema named\\nsbom_registry with JSON schema and API surface or a file-based export format\\nnamed sbom_export_v1 and its file layout), state whether bundle_dependencies\\nshould be declared (add bundle_dependencies: [\\n\\\"security-01-unified-findings-model\\\" ] to the license-compliance manifest or\\nreverse it if the security bundle should depend on license-compliance), and\\nupdate manifest/registry/docs/signing sections to include required fields for\\nregistry entry, docs pointer, and signing expectations so adapters can be built\\nagainst these stable hooks.\\n```\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for security-02-eu-gdpr-baseline references in license-related OpenSpec docs\\nrg -n 'security-02-eu-gdpr-baseline' openspec/changes/security-02-module-license-compliance/\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 615\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read the proposal around line 29 to understand the dependency context\\nsed -n '20,40p' openspec/changes/security-02-module-license-compliance/proposal.md\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1004\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Look for other security module proposals to compare dependency patterns\\nfd 'proposal.md' openspec/changes/security-* | head -10\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 262\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for \\\"policy-pack\\\" references to understand what it means\\nrg -n 'policy-pack' openspec/changes/ -A 2\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 10336\\n\\n---\\n\\n\\n\\n

\\n\\n**Verify dependency reference on line 29: `security-02-eu-gdpr-baseline` appears incorrect for license compliance policy-pack semantics.**\\n\\nThe proposal states a dependency on `security-02-eu-gdpr-baseline` \\\"for shared policy-pack semantics,\\\" but evidence indicates that `policy-02-packs-and-modes` is the core change providing shared policy-pack semantics. The security-03-module-pii-gdpr-eu proposal correctly lists `policy-02-packs-and-modes` as its blocker for policy-pack-driven GDPR/EU rule selection, and the license-compliance design (design.md:44) similarly references \\\"shared policy-pack interpretation\\\" as the mitigation strategy.\\n\\nEither:\\n1. Replace with `policy-02-packs-and-modes` as the primary policy-pack blocker, or\\n2. If `security-02-eu-gdpr-baseline` represents a separate baseline for vendor/supply-chain GDPR compliance checks, clarify this in the rationale and document the distinct semantics provided.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` at line\\n29, The dependency reference in proposal.md currently points to\\nsecurity-02-eu-gdpr-baseline but should reference the core policy-pack change\\npolicy-02-packs-and-modes (or else clarify distinct semantics) — update the\\ndependency on line 29 to replace security-02-eu-gdpr-baseline with\\npolicy-02-packs-and-modes if the intention is to indicate the shared policy-pack\\nsemantics, or add one sentence in the rationale clarifying that\\nsecurity-02-eu-gdpr-baseline is a separate vendor/supply-chain baseline and\\nexplain how its semantics differ from policy-02-packs-and-modes (cross-reference\\nsecurity-03-module-pii-gdpr-eu and design.md:44 where policy-pack interpretation\\nis already referenced).\\n```\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Verify security-01-unified-findings-model exists in specfact-cli\\n\\nrg -n --type=md -C3 'security-01-unified-findings-model' || echo \\\"Core dependency not found in current context\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 19931\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for security-01-unified-findings-model implementation in specfact-cli\\nrg -n --type=md -C2 'security-01-unified-findings-model' . | head -100\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 46\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Look for CHANGE_ORDER or similar tracking files mentioning status of security changes\\nfind . -name \\\"CHANGE_ORDER*\\\" -o -name \\\"*findings*\\\" -type f | head -20\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 90\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for unified findings or findings model implementation\\nrg -n 'unified.?findings|findings.?model|FindingsModel' --type=py --type=md . | head -50\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 46\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read CHANGE_ORDER.md to find security change status\\ncat -n ./openspec/CHANGE_ORDER.md | head -150\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 12624\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for any mention of security or findings in CHANGE_ORDER\\nrg -n 'security|findings' ./openspec/CHANGE_ORDER.md\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 1261\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read lines 150-350 to find security module section\\nsed -n '150,350p' ./openspec/CHANGE_ORDER.md\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 19360\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read remaining lines to find any security module section\\nsed -n '350,500p' ./openspec/CHANGE_ORDER.md\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 13534\\n\\n---\\n\\n\\n\\n

\\n\\n**Verify security-01-unified-findings-model is in specfact-cli's roadmap before proceeding.**\\n\\nThis spec depends on `security-01-unified-findings-model` for shared findings/report contracts. However, this core change does not appear in `specfact-cli`'s CHANGE_ORDER.md. Confirm it is planned, scheduled, or already implemented in the core repository, and document the required `core_compatibility` version in `TDD_EVIDENCE.md` before implementation begins.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\\nat line 7, Confirm that the core change \\\"security-01-unified-findings-model\\\" is\\nplanned or implemented in the specfact-cli roadmap by checking specfact-cli's\\nCHANGE_ORDER.md and the core repo; if it is planned or already merged, record\\nthe exact core release or commit that provides the shared findings/report\\ncontracts and add that version as the `core_compatibility` value for\\n`nold-ai/specfact-license-compliance` in the spec (and document the same\\nidentifier in TDD_EVIDENCE.md); if it is not planned, open/track a\\nCHANGE_ORDER.md entry or coordination ticket in specfact-cli before implementing\\nthis bundle and do not proceed until the required core compatibility version is\\nagreed and documented.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Mirror signature workflow wording used by automation to prevent process drift.**\\n\\nConsider rephrasing this step so contributors don’t infer that signature files should be manually produced/committed during implementation.\\n\\nBased on learnings, signature artifacts are generated by the publish workflow, while pre-merge verification should focus on the signature/version enforcement gate.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` at line 19, The\\ntask line \\\"3.4 Update registry metadata, docs references, signatures, and any\\nimport allowlists required by the new bundle.\\\" should be reworded to clarify\\nthat signature artifacts are produced by the publish automation and must not be\\nmanually committed; update the step (referencing the task text \\\"Update registry\\nmetadata, docs references, signatures, and any import allowlists\\\") to say\\ncontributors should update registry metadata, docs, and import allowlists as\\nneeded and ensure the publish workflow will generate signatures, while pre-merge\\nchecks must rely on the signature/version enforcement gate rather than creating\\nor committing signature files manually.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"openspec/changes/security-03-module-pii-gdpr-eu/tasks.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Consider the UX of JSON-dumping business/product sections.**\\n\\nLines 20 and 26 use `tojson(indent=2)` to render `business` and `product` objects as formatted JSON within Markdown. While this preserves structured data, large or deeply nested objects may produce verbose, hard-to-read output in the generated persona document.\\n\\n\\nConsider alternative rendering strategies:\\n- **If business/product have predictable schemas**: Use nested Jinja2 loops to render specific fields as Markdown (similar to the Features section on Lines 32-56)\\n- **If freeform structured data is expected**: Keep `tojson` but add a comment in the template explaining this is intentional for machine-readable embedded metadata\\n\\nExample alternative for predictable schema:\\n```jinja2\\n## Business\\n{% if business.model %}\\n- **Model**: {{ business.model }}\\n{% endif %}\\n{% if business.revenue_streams %}\\n- **Revenue Streams**: {{ business.revenue_streams | join(\\\", \\\") }}\\n{% endif %}\\n```\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@packages/specfact-project/resources/templates/persona/default.md.j2` at line\\n20, The template currently dumps business and product with tojson(indent=2)\\nwhich can produce noisy Markdown; update the persona template (default.md.j2) to\\neither (A) replace the JSON dumps for the business and product blocks with\\nexplicit Jinja2 field render loops when those objects follow predictable schemas\\n(use conditional checks on business.model, business.revenue_streams,\\nproduct.features, etc., and render as Markdown list items) or (B) if those\\nobjects are freeform and must remain machine-readable, retain tojson(indent=2)\\nbut add a clear template comment above each dump explaining the intentional\\nmachine-readable JSON embedding so future maintainers understand the choice.\\nEnsure you modify the occurrences of tojson for the variables business and\\nproduct.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"packages/specfact-project/resources/templates/persona/default.md.j2\",\"side\":\"RIGHT\",\"line\":21}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🌐 Web query:\\n\\n`In GitHub CLI `gh api`, what is the exact behavioral difference between `-F/--field` and `-f/--raw-field`, including `@file` expansion and type coercion rules?`\\n\\n💡 Result:\\n\\nThe exact behavioral differences between -F/--field (magic/typed fields) and -f/--raw-field (raw/string fields) in gh api are: - -f/--raw-field: Adds parameters as literal strings with no processing. Values are treated exactly as provided in key=value format. Does not support or perform `@file` expansion, placeholder substitution (e.g., {owner}), or type coercion (e.g., true to boolean). Suitable for static string values, including those containing @ characters. Supports nested syntax like key[subkey]=value and arrays via key[]=value. - -F/--field: Adds parameters with \\\"magic\\\" processing and type coercion: - If value starts with @, reads the file content (or stdin with `@-`) and uses it as the value (raw bytes, preserving type if JSON-like). - Substitutes placeholders {owner}, {repo}, {branch} from the current repo context. - Coerces literal strings: true/false to boolean, null to null, integers (e.g., 123) to numbers. - Otherwise, treats as string. - Supports the same nested key[subkey]=value and array key[] syntax. Both flags can be mixed in the same command. Adding any fields switches method to POST (unless overridden with --method GET). For GraphQL, fields other than query/operationName become variables. Examples: - -f body='Hi from CLI' (raw string) - -F 'files[myfile.txt][content]=@myfile.txt' (file expansion) - -F state=true (boolean coercion) - -f q='repo:cli/cli is:open' (search string with colons)\\n\\nCitations:\\n\\n- 1: https://cli-github.cnmirror.me/manual/gh_api\\n- 2: https://cli.github.com/manual/gh_api\\n- 3: https://cli.github.com/manual/gh_help_reference\\n- 4: https://www.gsp.com/cgi-bin/man.cgi?section=1&topic=GH-API\\n- 5: https://man.cx/gh-api(1)\\n- 6: https://manpages.debian.org/unstable/gh/gh-api.1.en.html\\n- 7: https://github.com/cli/cli/blob/trunk/pkg/cmd/api/api.go\\n- 8: https://www.quinze-cent-quinze.fr\\n- 9: https://github.com/cli/cli/blob/trunk/git/client.go\\n- 10: https://github.com/cli/cli/issues/12892\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Locate and inspect the script file\\nfind . -name \\\"ensure_github_hierarchy_subissues.py\\\" -type f\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 118\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read the full script to understand data flow\\ncat -n scripts/ensure_github_hierarchy_subissues.py | head -100\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 3793\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Continue reading the script\\ncat -n scripts/ensure_github_hierarchy_subissues.py | sed -n '100,175p'\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 3701\\n\\n---\\n\\n\\n\\n

\\n\\n**Harden GraphQL argument encoding for variables to avoid `@file` expansion.**\\n\\nThe `-F` flag at lines 43–51 performs \\\"magic\\\" processing in `gh api`, including `@file` expansion when a value starts with `@`. For string variables (particularly user-provided `--repo-owner` and `--repo-name`), use the safer `-f` flag which treats values as literal strings. Reserve `-F` only for non-string values that require type coercion (integers, booleans).\\n\\n

\\n

Suggested hardening

\\n\\n```diff\\n def _gh_graphql(*, query: str, variables: dict[str, Any], timeout: int = _GH_GRAPHQL_TIMEOUT_SEC) -> dict[str, Any]:\\n args = [\\\"gh\\\", \\\"api\\\", \\\"graphql\\\", \\\"-f\\\", f\\\"query={query}\\\"]\\n for key, value in variables.items():\\n if value is None:\\n continue\\n if isinstance(value, list):\\n for item in value:\\n- args.extend([\\\"-F\\\", f\\\"{key}[]={item}\\\"])\\n+ flag = \\\"-f\\\" if isinstance(item, str) else \\\"-F\\\"\\n+ args.extend([flag, f\\\"{key}[]={item}\\\"])\\n+ elif isinstance(value, str):\\n+ args.extend([\\\"-f\\\", f\\\"{key}={value}\\\"])\\n else:\\n args.extend([\\\"-F\\\", f\\\"{key}={value}\\\"])\\n```\\n

\\n\\nAs per coding guidelines, `scripts/**/*.py` requires deterministic tooling with subprocess and path safety.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@scripts/ensure_github_hierarchy_subissues.py` around lines 43 - 51, The\\ncurrent loop building args uses -F for all scalar string variables which\\ntriggers gh's `@file` expansion; update the logic that builds args (the args list\\nand the variables dict handling) to use -f for string values (including string\\nlist items and repo-owner/repo-name) so they are passed literally, and reserve\\n-F only for non-string typed values (e.g., ints, bools) that need type coercion;\\nspecifically, change the branch that checks isinstance(value, list) to emit\\nrepeated \\\"-f\\\" entries for string items, and in the scalar branch emit \\\"-f\\\" when\\nisinstance(value, str) else \\\"-F\\\" for non-strings. Ensure the initial query part\\n(f\\\"query={query}\\\") remains unchanged and keep skipping None values.\\n```\\n\\n

\\n

🧩 Analysis chain

\\n\\n🌐 Web query:\\n\\n`For GitHub GraphQL API responses, can top-level `data` be null or omitted, and what is the recommended client-side handling when `errors` is present with partial/empty `data`?`\\n\\n💡 Result:\\n\\nIn GitHub's GraphQL API, which follows the GraphQL specification, the top-level data field in responses can be null or entirely omitted under specific conditions. - data is omitted (not present) for request errors occurring before execution (e.g., parse errors, validation errors). - data is null if an execution error prevents a valid response. - data can be a partial object (including null values for specific fields) alongside an errors array for field-level execution errors. data is never omitted when errors is present with partial data; both coexist in partial responses. Recommended client-side handling when errors is present with partial/empty data: - Always check for the presence of errors, regardless of data. - Use partial data if available (e.g., via error policies like 'all' in Apollo Client), as it may contain valid results. - Examine errors.path to map errors to specific null fields in data. - For GitHub-specific clients like Octokit graphql.js, catch GraphqlResponseError where error.data provides partial data. - Implement conditional rendering: use data values if present and error-free; show warnings or fallbacks for errored fields. - Log errors for monitoring, distinguishing field errors (partial data usable) from request errors (no data). This follows GraphQL spec behavior, confirmed in GitHub examples like pagination with partial results and Octokit handling.\\n\\nCitations:\\n\\n- 1: https://graphql.org/learn/response/\\n- 2: https://github.com/graphql/graphql-spec/blob/60323c90dc2699266be7da7f0d4ab293953cd733/spec/Section%207%20--%20Response.md\\n- 3: https://github.com/graphql/graphql-spec/blob/main/spec/Section%207%20--%20Response.md\\n- 4: https://github.com/octokit/graphql.js/issues/14\\n- 5: https://www.npmjs.com/package/@octokit/graphql\\n- 6: https://github.com/apollographql/skills/blob/main/skills/apollo-client/references/error-handling.md\\n- 7: https://hasura.io/blog/graphql-nulls-cheatsheet\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# First, let's look at the file and understand the context\\nfind . -name \\\"ensure_github_hierarchy_subissues.py\\\" -type f | head -5\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 118\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check the structure and find the specific function\\nrg -B 10 -A 5 'payload\\\\[\\\"data\\\"\\\\]' scripts/\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1437\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Look at the full function containing these lines\\ncat -n scripts/ensure_github_hierarchy_subissues.py | head -100\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 3793\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check for all callers of _gh_graphql\\nrg -B 2 -A 2 '_gh_graphql' scripts/ensure_github_hierarchy_subissues.py\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 896\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if json.loads could fail and how errors are handled\\ncat -n scripts/ensure_github_hierarchy_subissues.py | sed -n '42,120p'\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 3780\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check the main entry point and overall error handling\\ncat -n scripts/ensure_github_hierarchy_subissues.py | tail -50\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 2343\\n\\n---\\n\\n\\n\\n

\\n\\n**Use `.get(\\\"data\\\")` and validate response envelope structure for deterministic failure handling.**\\n\\nAt lines 67–70, `payload[\\\"data\\\"]` is accessed without first validating that `payload` is a dict or that the `\\\"data\\\"` key exists. Per GitHub's GraphQL spec, `data` can be null or (in edge cases of malformed output) missing entirely. While unlikely with the `gh` CLI, unexpected envelopes should raise clear errors rather than `TypeError` or `KeyError`. This aligns with deterministic tooling requirements for scripts.\\n\\nRecommended fix: Use `payload.get(\\\"data\\\")` instead of direct access and add a type check for `payload` before the `\\\"errors\\\" in payload` test:\\n\\n

\\n

Suggested resilience diff

\\n\\n```diff\\n payload = json.loads(proc.stdout)\\n+ if not isinstance(payload, dict):\\n+ raise RuntimeError(\\\"gh graphql returned a non-object JSON payload\\\")\\n if \\\"errors\\\" in payload:\\n raise RuntimeError(json.dumps(payload[\\\"errors\\\"], indent=2))\\n- return payload[\\\"data\\\"]\\n+ data = payload.get(\\\"data\\\")\\n+ if data is None:\\n+ raise RuntimeError(\\\"gh graphql response missing data object\\\")\\n+ return data\\n```\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@scripts/ensure_github_hierarchy_subissues.py` around lines 67 - 70, The JSON\\nresponse handling is brittle: change the logic that reads payload =\\njson.loads(proc.stdout) so you first verify payload is a dict\\n(isinstance(payload, dict)); only then check for \\\"errors\\\" in payload, and\\nretrieve the result using payload.get(\\\"data\\\") instead of payload[\\\"data\\\"]; if\\npayload is not a dict or payload.get(\\\"data\\\") is None (or missing), raise a clear\\nRuntimeError that includes the raw payload or proc.stdout for debugging. Ensure\\nyou reference the existing variables payload and proc when constructing the\\nerror messages so failures are deterministic and informative.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"scripts/ensure_github_hierarchy_subissues.py\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Cache parent sub-issue sets and issue node IDs to reduce API churn.**\\n\\nLine 148–Line 159 repeatedly re-fetches the same parent and node IDs, increasing call volume and rate-limit risk for automation.\\n\\n \\n\\n

\\n

Suggested DRY/call-reduction diff

\\n\\n```diff\\n def main(argv: list[str] | None = None) -> int:\\n@@\\n owner, name = args.repo_owner, args.repo_name\\n added = 0\\n skipped = 0\\n would_add = 0\\n+ subissues_cache: dict[int, set[int]] = {}\\n+ issue_id_cache: dict[int, str] = {}\\n \\n for parent_num, child_num in DEFAULT_EDGES:\\n- existing = _subissue_numbers(owner=owner, name=name, parent_number=parent_num)\\n+ existing = subissues_cache.setdefault(\\n+ parent_num,\\n+ _subissue_numbers(owner=owner, name=name, parent_number=parent_num),\\n+ )\\n if child_num in existing:\\n skipped += 1\\n continue\\n@@\\n- parent_id = _issue_node_id(owner=owner, name=name, number=parent_num)\\n- child_id = _issue_node_id(owner=owner, name=name, number=child_num)\\n+ parent_id = issue_id_cache.setdefault(\\n+ parent_num, _issue_node_id(owner=owner, name=name, number=parent_num)\\n+ )\\n+ child_id = issue_id_cache.setdefault(\\n+ child_num, _issue_node_id(owner=owner, name=name, number=child_num)\\n+ )\\n _add_sub_issue(parent_id=parent_id, child_id=child_id)\\n+ existing.add(child_num)\\n sys.stdout.write(f\\\"addSubIssue #{child_num} -> parent #{parent_num}\\\\n\\\")\\n added += 1\\n```\\n

\\n\\nAs per coding guidelines, preserve clean-code compliance with DRY/KISS in changed Python code.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@scripts/ensure_github_hierarchy_subissues.py` around lines 148 - 159, The\\nloop over DEFAULT_EDGES repeatedly calls _subissue_numbers and _issue_node_id\\ncausing excess API calls; introduce simple in-memory caches (e.g., dicts keyed\\nby parent number and by issue number) before the loop to store fetched sub-issue\\nsets and node IDs, consult the cache instead of re-calling\\n_subissue_numbers(parent_num) and _issue_node_id(...) for the same\\nparent_num/child_num, and only call the underlying functions on cache misses;\\nstill honor args.dry_run, increment skipped/would_add as before, and pass the\\ncached parent_id/child_id into _add_sub_issue when needed.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"scripts/ensure_github_hierarchy_subissues.py\",\"side\":\"RIGHT\",\"line\":185}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Make trigger-type assertions order-insensitive to reduce test churn.**\\n\\nLine 52 and Line 55 currently require exact list ordering; workflow semantics are set-based. Prefer set comparison to avoid brittle failures from harmless YAML reordering.\\n\\n

\\n

Suggested refactor

\\n\\n```diff\\n- assert pr_review[\\\"types\\\"] == [\\\"submitted\\\"]\\n+ assert set(pr_review[\\\"types\\\"]) == {\\\"submitted\\\"}\\n ...\\n- assert pr[\\\"types\\\"] == [\\\"opened\\\", \\\"synchronize\\\", \\\"reopened\\\", \\\"ready_for_review\\\"]\\n+ assert set(pr[\\\"types\\\"]) == {\\\"opened\\\", \\\"synchronize\\\", \\\"reopened\\\", \\\"ready_for_review\\\"}\\n```\\n

\\n\\n\\nAs per coding guidelines: `tests/**/*.py`: Contract-first and integration tests ... and flakiness.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@tests/unit/workflows/test_sign_modules_on_approval.py` around lines 52 - 55,\\nThe assertions that check event trigger lists are brittle due to ordering;\\nupdate the tests to compare sets instead of lists: replace the exact-equality\\nassertions on pr_review[\\\"types\\\"] and pr[\\\"types\\\"] with order-insensitive checks\\n(e.g., assert set(pr_review[\\\"types\\\"]) == {\\\"submitted\\\"} and assert\\nset(pr[\\\"types\\\"]) == {\\\"opened\\\",\\\"synchronize\\\",\\\"reopened\\\",\\\"ready_for_review\\\"}) so\\nthe tests no longer fail when YAML ordering changes; locate and update the\\nassertions referencing pr_review[\\\"types\\\"] and pr[\\\"types\\\"] in\\ntest_sign_modules_on_approval.py.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 0672f50\",\"path\":\"tests/unit/workflows/test_sign_modules_on_approval.py\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**Actionable comments posted: 51**\\n\\n

\\n

🤖 Prompt for all review comments with AI agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nInline comments:\\nIn @.github/workflows/sign-modules-on-approval.yml:\\n- Line 74: The current Python one-liner that parses the GraphQL JSON (the\\npython3 -c \\\"import json,sys; data=json.load(sys.stdin); reviews=...;\\nprint(...)\\\") can raise a KeyError on missing keys; update it to validate the\\nexpected keys or wrap the parsing and key access in a try/except that catches\\n(KeyError, TypeError, ValueError) and prints a clear, descriptive error message\\nto stderr (including which top-level key is missing and the raw input snippet or\\nits summary) before exiting with a non-zero status so the GitHub Actions job\\nfails with a useful message.\\n- Around line 68-81: The GraphQL query uses latestReviews(first:100) which can\\nmiss reviews if a PR has >100 distinct reviewers; update the sign workflow to\\nhandle pagination by looping requests using pageInfo.hasNextPage and\\npageInfo.endCursor (aggregate nodes across pages) before computing\\ntrusted_review_count, referencing the existing trusted_review_count calculation\\nand the latestReviews(...) field; alternatively, if you decide 100 is an\\nacceptable ceiling for this repo, add a clear comment in the workflow near\\nlatestReviews(first:100) explaining that the 100-reviewer limit is intentional\\nand documented.\\n\\nIn `@docs/bundles/project/import-migration.md`:\\n- Around line 39-40: Replace the vague phrase \\\"very large\\\" in the two sentences\\nthat start with \\\"When import encounters unusually large ignored artifact\\ntrees...\\\" and \\\"Remaining time is based on processed-versus-discovered work...\\\"\\nwith concrete thresholds; for example, change to \\\"ignored artifact trees with\\n>10,000 entries or repositories larger than ~100,000 files, ~10 GB of repository\\ndata, or >100,000 commits\\\" and note that estimates remain provisional for repos\\nabove those thresholds—adjust the numeric thresholds to align with product\\ntelemetry if different.\\n\\nIn `@openspec/CHANGE_ORDER.md`:\\n- Around line 94-95: The two entries for security-02-module-license-compliance\\nand security-03-module-pii-gdpr-eu both use Order | 04; update the Order on one\\nof them (e.g., change security-03-module-pii-gdpr-eu to Order | 05 or otherwise\\nassign a unique, sequential number) so every `security` entry has a distinct\\nOrder value and the CHANGE_ORDER semantics remain consistent across the spec.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\\n- Line 50: The document references a paired core contract named\\narchitecture-02-well-architected-review that isn't present in specfact-cli;\\nupdate the design to either (a) point to the existing core contract if it exists\\nunder a different name or folder (search for architecture-01-solution-layer and\\nother architecture-* entries in the specfact-cli repo), (b) confirm and document\\nthat architecture-01-solution-layer supplies the required boundary rules and\\nadapter contracts for this module, or (c) add a note that a new core change\\narchitecture-02-well-architected-review must be created/synced into specfact-cli\\nbefore module integration—ensure the doc references the exact core contract name\\nyou verified and mention architecture-01-solution-layer when clarifying overlap.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md`:\\n- Around line 10-12: Add an \\\"Adapter Contract\\\" subsection under \\\"What Changes\\\"\\nthat defines the normalized boundary between analyzers and the core review\\ncontract: list the required core findings schema fields this bundle must\\npopulate (e.g., id, type, severity, description, source, timestamp,\\nevidence_refs), specify how outputs from the packaged analyzers\\n(dependency-graph checks, ADR traceability, interface-diff) map to normalized\\nevidence references and fields (reference example mappings for\\nALLOWED_IMPORTS.md violations → evidence_refs, ADR entries → source/trace\\nlinks), and state the emission mode (synchronous vs deferred batching) and\\nretry/ordering semantics for findings emission so implementers know expected\\nbehavior.\\n- Line 13: Add an explicit core_compatibility field and semantic version range\\nfor the reserved manifest \\\"architecture-02-well-architected-review\\\" so consumers\\nand the core can validate compatibility; update the proposal text to state the\\nrequired core version range (e.g., a semver range such as \\\">=X.Y.Z merge\\n`.specfact/.specfactignore` -> explicit target override) is added to the spec so\\npruning happens before traversal and precedence is unambiguous.\\n- Around line 1-40: The markdown has lint warnings from missing blank lines\\naround headings (MD041/MD022); edit the section headings such as \\\"ADDED\\nRequirements\\\", \\\"Requirement: Import runtime SHALL prune hidden and heavyweight\\ntrees before discovery\\\", \\\"Scenario: Default traversal skips hidden and\\nheavyweight directories\\\", \\\"Requirement: Import runtime SHALL surface\\nlarge-artifact warnings\\\", and \\\"Requirement: Import progress SHALL use\\ndiscovered-versus-processed work\\\" to ensure there is a single blank line above\\nand below each heading and between consecutive headings/paragraphs so each\\nheading is properly separated and no multiple consecutive headings lack\\nintervening blank lines; keep the existing heading text and indentation but\\ninsert the required blank lines consistently throughout the document to resolve\\nMD041/MD022.\\n\\nIn `@openspec/changes/codebase-import-runtime-hardening/tasks.md`:\\n- Line 1: Add a top-level H1 heading to the document (replace the current\\nleading \\\"## 1. GitHub readiness and change scaffolding\\\" start) so the file\\nbegins with an H1 like \\\"# Tasks: codebase-import-runtime-hardening\\\" to satisfy\\nMD041 and match other task files; ensure the existing content remains unchanged\\nafter the new H1.\\n\\nIn\\n`@openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`:\\n- Line 1: Add a top-level H1 above the existing H2 \\\"ADDED Requirements\\\" in the\\nspec.md (e.g., \\\"Enterprise Policy Client\\\" or another concise title) so the\\ndocument begins with an H1 to satisfy MD041; update the first line to a valid\\nMarkdown H1 and ensure the existing H2 remains unchanged.\\n\\nIn `@openspec/changes/enterprise-01-module-policy-client/tasks.md`:\\n- Line 4: Update checklist item for enterprise-01-policy-resolution-extension to\\nexplicitly require reviewing the paired public OpenSpec/contracts in\\nnold-ai/specfact-cli before implementation and documenting the minimum required\\ncore_compatibility; add a sub-item that instructs the implementer to verify and\\nrecord matching change IDs, model names, and workflow semantics between this\\nchange and the paired specfact-cli artifacts (e.g., \\\"Review paired public\\nOpenSpec/contracts in nold-ai/specfact-cli and confirm matching change IDs/model\\nnames/workflow semantics; document minimum core_compatibility\\\"). Ensure the new\\ntext appears alongside the existing 1.2 checklist so reviewers cannot skip the\\npaired-core artifact review step.\\n\\nIn `@openspec/changes/enterprise-02-module-audit-client/design.md`:\\n- Line 1: The document begins with an H2 (\\\"## Context\\\") which triggers MD041;\\nadd a top-level H1 above the existing \\\"## Context\\\" header (e.g., \\\"# Context\\\" or\\na suitable project/title H1) so the file starts with an H1, leaving the existing\\n\\\"## Context\\\" as-is to preserve structure.\\n\\nIn\\n`@openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`:\\n- Line 7: The spec declares a hard core dependency on\\nenterprise-02-rbac-and-audit-trail for the nold-ai/specfact-enterprise-audit\\nbundle but that core change does not exist; update\\nenterprise-audit-client/spec.md to remove or replace the nonexistent core change\\nreference in the core_compatibility and dependency text (replace\\nenterprise-02-rbac-and-audit-trail with the correct existing change ID or a TODO\\nplaceholder), and add a note that implementation is blocked until the paired\\ncore change is proposed/merged and the spec's core_compatibility entry is\\nupdated.\\n\\nIn `@openspec/changes/enterprise-02-module-audit-client/tasks.md`:\\n- Line 4: Update the task checklist in\\nenterprise-02-module-audit-client/tasks.md to add an explicit step that\\nreviewers must inspect the paired public core OpenSpec/contracts (not just\\nupstream sequencing) for the `enterprise-02-rbac-and-audit-trail` change and any\\nlinked artifacts from `enterprise-01-module-policy-client`; call out that\\nreviewers should confirm the authoritative public artifacts in specfact-cli (or\\nequivalent public repo) and record the minimum required `core_compatibility`\\nafter that review. Ensure the new line references the paired artifact names\\n(`enterprise-02-rbac-and-audit-trail`, `enterprise-01-module-policy-client`,\\nspecfact-cli) and replaces or augments the existing weaker \\\"Confirm paired core\\nchange\\\" item.\\n\\nIn\\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`:\\n- Line 7: The spec references coordination with\\ntelemetry-01-opentelemetry-default-on but doesn't state whether that change is a\\nbundle dependency, a core_compatibility requirement, or only a sequencing\\nconstraint; update the sentence for nold-ai/specfact-finops to explicitly state\\nhow telemetry-01-opentelemetry-default-on is represented (e.g., add it to\\nbundle_dependencies, list it under core_compatibility, or note it as a\\nsequencing prerequisite) and ensure the manifest fields mentioned\\n(`bundle_dependencies`, `pip dependencies`, `core_compatibility`) clearly\\nindicate where telemetry-01 appears and that CHANGE_ORDER.md is the\\nauthoritative source for sequencing.\\n\\nIn `@openspec/changes/finops-01-module-cost-outcome/tasks.md`:\\n- Line 19: Edit the task bullet that currently reads \\\"3.4 Update registry\\nmetadata, docs references, signatures, and any import allowlists required by the\\nnew bundle.\\\" to clarify that \\\"signatures\\\" are validated by gates and created by\\nthe publish automation rather than manually committed; e.g., change the phrase\\nto something like \\\"update registry metadata, docs references, and any import\\nallowlists required by the new bundle (signatures are validated by CI gates and\\nproduced by publish automation—not committed manually)\\\"; update the text near\\nthe 3.4 task in tasks.md accordingly.\\n\\nIn `@openspec/changes/knowledge-01-module-memory-runtime/design.md`:\\n- Line 48: The design references a paired core MemoryBackend protocol that isn't\\npublished in specfact-cli; confirm and record this contract by coordinating with\\nspecfact-cli to either (A) publish the MemoryBackend protocol definition and\\nversion/stability statement (ensure the exported symbol is named MemoryBackend\\nand its public API/JSON schema is documented), or (B) add the MemoryBackend\\nprotocol to the paired core change scope and include its authoritative spec in\\nthis repo's design document (update \\\"migration step 1\\\" to reference the exact\\nprotocol artifact, version, and where it is published). Ensure the design.md\\nexplicitly points to the published spec (or pairing ticket) and notes the\\nrequired stability guarantee so the markdown-graph MemoryBackend integration can\\nproceed.\\n\\nIn `@openspec/changes/knowledge-01-module-memory-runtime/proposal.md`:\\n- Around line 9-13: Rephrase the repeated \\\"**NEW**:\\\" bullets to improve\\nreadability by varying sentence structure: e.g., keep one \\\"**NEW**:\\\" header for\\nthe group and turn the rest into action-starting phrases (\\\"Add a\\n`specfact-knowledge` bundle with `memory` subcommands...\\\", \\\"Package the\\nmarkdown-graph backend as the default runtime...\\\", \\\"Define gitignore,\\nrepo-layout, and file-lifecycle...\\\", \\\"Add search and status surfaces exposing\\n`MemoryBackend` behavior...\\\") or combine related items into a single sentence;\\ntarget the lines mentioning `specfact-knowledge`, `memory` subcommands,\\n`markdown-graph backend`, `.specfact/memory/`, and `MemoryBackend` when applying\\nthe edits.\\n- Line 29: Create and merge the paired core change repository folder\\nopenspec/changes/knowledge-01-distillation-engine into the nold-ai/specfact-cli\\nrepo (ensuring the folder name exactly matches the contract referenced in this\\nmodule), document the contract stability and cross-repo compatibility\\nrequirements in TDD_EVIDENCE.md, and confirm the core change is merged into\\nspecfact-cli before proceeding with the module implementation so the module’s\\ndependency on knowledge-01-distillation-engine is satisfied.\\n\\nIn\\n`@openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`:\\n- Line 1: The file currently starts with an H2 which triggers MD041; fix by\\nadding a top-level H1 as the very first line of\\nopenspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md\\n(e.g., \\\"# Knowledge Memory Runtime\\\") so the existing H2 becomes a secondary\\nheading — ensure the H1 is descriptive for the module and placed before any\\nother content or headings.\\n\\nIn `@openspec/changes/knowledge-01-module-memory-runtime/tasks.md`:\\n- Line 1: Replace the numeric H1 \\\"# 1. Branch and dependency guardrails\\\" with a\\ndescriptive H1 to match other OpenSpec files (for example \\\"Change: Branch and\\ndependency guardrails\\\" or \\\"Design: Branch and dependency guardrails\\\"); update\\nthe header string in the tasks.md file so the top-level title uses a descriptive\\nlabel rather than a leading number to maintain consistency across specs.\\n\\nIn `@openspec/changes/knowledge-02-module-writeback/design.md`:\\n- Line 1: Add a top-level H1 heading above the existing \\\"## Context\\\" heading in\\nthe design.md to satisfy MD041; for consistency with other OpenSpec docs use a\\ntitle like \\\"# Design: knowledge-02-module-writeback\\\" placed immediately before\\nthe \\\"## Context\\\" section so the file begins with an H1 followed by the existing\\nsubsections.\\n\\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md`:\\n- Around line 10-12: Add an \\\"Adapter Contract\\\" (or \\\"Writeback Interface\\\")\\nsubsection that specifies the adapter method signature and manifest schema:\\ndefine a function-like contract (e.g., adapter receives selected memory rules\\nand destination metadata and returns { previewContent, writebackManifest }) and\\nenumerate manifest fields required for deterministic lineage/audit (ruleIds,\\nruleVersions, inputDigest, outputDigest, timestamp, adapterId, destination,\\npreviewHash, dryRunFlag); state whether adapters MUST validate destinations or\\nrely on caller validation and clarify error/validation semantics for preview\\ngeneration vs. final writeback; include example field types and required vs\\noptional fields so all implementations (BUGBOT.md adapter,\\n.github/copilot-instructions.md adapter, CodeRabbit draft adapter) follow the\\nsame deterministic output and manifest format.\\n- Around line 29-30: Add explicit reserved-manifest metadata: define\\nbundle_dependencies and core_compatibility version ranges for this bundle. In\\nthe Impact/Release section specify bundle_dependencies including\\n\\\"knowledge-01-module-memory-runtime\\\" with a semver range (e.g., >=X.Y.Z =X.Y.Z =1.2.0\\\"). Update the \\\"registry entry, docs, signatures, and\\ncompatibility range\\\" line to include these three concrete items so implementers\\nknow the exact core_compatibility string format, the targeted core contract\\nversions, and the expectation for bundle_dependencies.\\n- Line 9: Add a \\\"Command Surface\\\" subsection under the \\\"Decisions\\\" section of\\nthe specfact-security design that explicitly states whether the bundle exposes a\\nsingle command or multiple scanner-specific commands and how they map to the\\nfour scanner classes (sast, sca, sbom, secrets); update the document to declare\\nthe chosen approach (single `security` command with flags like\\n--sast/--sca/--secrets, separate commands `sast`/`sca`/`sbom`/`secrets`, or a\\nhybrid) and describe the rationale for discoverability and how commands will be\\ndeclared in module-package.yaml so implementers know whether to register\\n`specfact-security:security` or individual commands such as\\n`specfact-security:sast`.\\n\\nIn\\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`:\\n- Line 7: Update the `nold-ai/specfact-security` spec to correct the\\n`core_compatibility` declarations: if `security-01-unified-findings-model` is\\nnot an accepted core contract, remove it from `core_compatibility` or add a\\ncorresponding proposal in `specfact-cli` first; for `policy-02-packs-and-modes`,\\nchange its entry from a core `core_compatibility` to a module-level bundle\\ndependency (e.g., list it under bundle/pip dependencies) since it lives in\\n`specfact-cli-modules`; ensure the spec no longer claims core compatibility for\\nnon-core items and clearly documents the dependency locations for both\\n`security-01-unified-findings-model` and `policy-02-packs-and-modes`.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md`:\\n- Line 4: Update the task text to explicitly verify both referenced changes\\nbefore binding core compatibility: check that security-01-unified-findings-model\\nexists in specfact-cli (if missing, mark it as \\\"planned/not yet present\\\" and\\nreference that status), confirm policy-02-packs-and-modes is the module in\\nspecfact-cli-modules (cite its CHANGE_ORDER.md and CHANGE_VALIDATION.md\\nevidence), and record the minimum required core_compatibility versions against\\nboth plus any sequencing notes in TDD_EVIDENCE.md; also verify\\nmodule-package.yaml and bundle registry semantics for policy-02-packs-and-modes\\nare final before locking core_compatibility.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/design.md`:\\n- Line 1: Add a top-level H1 heading to this design doc to satisfy MD041; insert\\na line like \\\"# Design: security-02-module-license-compliance\\\" (or another\\nappropriate title) immediately before the existing \\\"## Context\\\" heading so the\\nfile begins with an H1 and retains the current \\\"## Context\\\" section unchanged.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md`:\\n- Around line 10-11: Add an \\\"Adapter Contract\\\" subsection under the SBOM/SPDX\\nadapter description that specifies the exact boundary between adapters and the\\ncore security/license findings model: enumerate the core findings schema fields\\n(e.g., finding_id, package_name, package_version, license_id,\\nnormalized_license_type, severity, policy_state, confidence, timestamp), define\\nthe SPDX-to-normalized finding mapping rules (how SPDX identifiers map to\\nnormalized_license_type and license_id), and prescribe the evidence reference\\nformat for SBOM lineage (e.g., canonical SBOM source URL/ID, package entry path,\\ncomponent checksum and provenance fields). Ensure this contract is titled\\n\\\"Adapter Contract\\\" and referenced by \\\"SBOM ingestion and SPDX normalization\\nadapters\\\" and the \\\"core security/license findings model\\\" so implementations must\\nproduce findings compatible with these fields and mappings.\\n- Around line 12-13: Specify concrete inter-bundle compatibility and adapter\\nboundaries: add a core_compatibility version range entry that references\\nsecurity-01-unified-findings-model (e.g., semver range) in the\\nlicense-compliance bundle manifest, define the inter-bundle hook interface\\n(choose and document a single approach such as a shared registry schema named\\nsbom_registry with JSON schema and API surface or a file-based export format\\nnamed sbom_export_v1 and its file layout), state whether bundle_dependencies\\nshould be declared (add bundle_dependencies: [\\n\\\"security-01-unified-findings-model\\\" ] to the license-compliance manifest or\\nreverse it if the security bundle should depend on license-compliance), and\\nupdate manifest/registry/docs/signing sections to include required fields for\\nregistry entry, docs pointer, and signing expectations so adapters can be built\\nagainst these stable hooks.\\n- Line 29: The dependency reference in proposal.md currently points to\\nsecurity-02-eu-gdpr-baseline but should reference the core policy-pack change\\npolicy-02-packs-and-modes (or else clarify distinct semantics) — update the\\ndependency on line 29 to replace security-02-eu-gdpr-baseline with\\npolicy-02-packs-and-modes if the intention is to indicate the shared policy-pack\\nsemantics, or add one sentence in the rationale clarifying that\\nsecurity-02-eu-gdpr-baseline is a separate vendor/supply-chain baseline and\\nexplain how its semantics differ from policy-02-packs-and-modes (cross-reference\\nsecurity-03-module-pii-gdpr-eu and design.md:44 where policy-pack interpretation\\nis already referenced).\\n\\nIn\\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`:\\n- Line 7: Confirm that the core change \\\"security-01-unified-findings-model\\\" is\\nplanned or implemented in the specfact-cli roadmap by checking specfact-cli's\\nCHANGE_ORDER.md and the core repo; if it is planned or already merged, record\\nthe exact core release or commit that provides the shared findings/report\\ncontracts and add that version as the `core_compatibility` value for\\n`nold-ai/specfact-license-compliance` in the spec (and document the same\\nidentifier in TDD_EVIDENCE.md); if it is not planned, open/track a\\nCHANGE_ORDER.md entry or coordination ticket in specfact-cli before implementing\\nthis bundle and do not proceed until the required core compatibility version is\\nagreed and documented.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/tasks.md`:\\n- Line 1: Replace the top-level header so the file uses a descriptive H1 like\\nother OpenSpec files: change the existing \\\"# 1. Branch and dependency\\nguardrails\\\" to \\\"# Tasks: security-02-module-license-compliance\\\" and then demote\\nthe current header to a section header by adding \\\"## 1. Branch and dependency\\nguardrails\\\" immediately below; update the headers in\\nopenspec/changes/security-02-module-license-compliance/tasks.md to match this\\npattern so it aligns with knowledge-01-module-memory-runtime/tasks.md.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`:\\n- Line 19: The task line \\\"3.4 Update registry metadata, docs references,\\nsignatures, and any import allowlists required by the new bundle.\\\" should be\\nreworded to clarify that signature artifacts are produced by the publish\\nautomation and must not be manually committed; update the step (referencing the\\ntask text \\\"Update registry metadata, docs references, signatures, and any import\\nallowlists\\\") to say contributors should update registry metadata, docs, and\\nimport allowlists as needed and ensure the publish workflow will generate\\nsignatures, while pre-merge checks must rely on the signature/version\\nenforcement gate rather than creating or committing signature files manually.\\n\\nIn `@packages/specfact-project/resources/templates/persona/default.md.j2`:\\n- Line 20: The template currently dumps business and product with\\ntojson(indent=2) which can produce noisy Markdown; update the persona template\\n(default.md.j2) to either (A) replace the JSON dumps for the business and\\nproduct blocks with explicit Jinja2 field render loops when those objects follow\\npredictable schemas (use conditional checks on business.model,\\nbusiness.revenue_streams, product.features, etc., and render as Markdown list\\nitems) or (B) if those objects are freeform and must remain machine-readable,\\nretain tojson(indent=2) but add a clear template comment above each dump\\nexplaining the intentional machine-readable JSON embedding so future maintainers\\nunderstand the choice. Ensure you modify the occurrences of tojson for the\\nvariables business and product.\\n\\nIn `@packages/specfact-project/src/specfact_project/generators/template_paths.py`:\\n- Around line 39-40: Remove the early return for templates_dir and instead run\\nthe explicit override through the same path shaping and validation applied to\\nauto-discovered roots: when templates_dir is provided, join/append subdir (if\\nsubdir is set) to templates_dir, convert to a Path, and validate that it\\ncontains files matching required_glob before returning it; ensure you use the\\nsame logic/code paths that handle discovered roots so explicit overrides honor\\nsubdir and required_glob (referencing the templates_dir, subdir and\\nrequired_glob symbols).\\n\\nIn `@packages/specfact-project/src/specfact_project/import_runtime_patches.py`:\\n- Around line 181-186: The patched wrapper uses signature.bind_partial(...)\\nwhich omits defaulted parameters; after binding call bound.apply_defaults() to\\npopulate missing defaults before passing bound.arguments into args_builder, so\\nin patched (the function that does signature.bind_partial(*args, **kwargs) and\\nthen built = args_builder(dict(bound.arguments))) insert bound.apply_defaults()\\nand then continue with built transformation and runner(original, context,\\nbuilt); keep existing replace(built, **kwargs) behavior intact.\\n\\nIn `@packages/specfact-project/src/specfact_project/utils/import_path_policy.py`:\\n- Around line 443-468: discover_code_files normalizes file extensions only when\\nbuilding ImportDiscoveryOptions from kwargs, causing inconsistency when callers\\npass an ImportDiscoveryOptions instance; update the options branch to normalize\\nextensions too by calling _normalize_extensions on options.extensions (or\\nreplacing options.extensions with the normalized result) before passing options\\nto _discover_code_files_with_options so both code paths accept extensions with\\nor without a leading dot; reference functions/classes: discover_code_files,\\nImportDiscoveryOptions, _normalize_extensions, and\\n_discover_code_files_with_options.\\n\\nIn `@scripts/ensure_github_hierarchy_subissues.py`:\\n- Around line 148-159: The loop over DEFAULT_EDGES repeatedly calls\\n_subissue_numbers and _issue_node_id causing excess API calls; introduce simple\\nin-memory caches (e.g., dicts keyed by parent number and by issue number) before\\nthe loop to store fetched sub-issue sets and node IDs, consult the cache instead\\nof re-calling _subissue_numbers(parent_num) and _issue_node_id(...) for the same\\nparent_num/child_num, and only call the underlying functions on cache misses;\\nstill honor args.dry_run, increment skipped/would_add as before, and pass the\\ncached parent_id/child_id into _add_sub_issue when needed.\\n- Around line 67-70: The JSON response handling is brittle: change the logic\\nthat reads payload = json.loads(proc.stdout) so you first verify payload is a\\ndict (isinstance(payload, dict)); only then check for \\\"errors\\\" in payload, and\\nretrieve the result using payload.get(\\\"data\\\") instead of payload[\\\"data\\\"]; if\\npayload is not a dict or payload.get(\\\"data\\\") is None (or missing), raise a clear\\nRuntimeError that includes the raw payload or proc.stdout for debugging. Ensure\\nyou reference the existing variables payload and proc when constructing the\\nerror messages so failures are deterministic and informative.\\n- Around line 43-51: The current loop building args uses -F for all scalar\\nstring variables which triggers gh's `@file` expansion; update the logic that\\nbuilds args (the args list and the variables dict handling) to use -f for string\\nvalues (including string list items and repo-owner/repo-name) so they are passed\\nliterally, and reserve -F only for non-string typed values (e.g., ints, bools)\\nthat need type coercion; specifically, change the branch that checks\\nisinstance(value, list) to emit repeated \\\"-f\\\" entries for string items, and in\\nthe scalar branch emit \\\"-f\\\" when isinstance(value, str) else \\\"-F\\\" for\\nnon-strings. Ensure the initial query part (f\\\"query={query}\\\") remains unchanged\\nand keep skipping None values.\\n\\nIn `@tests/unit/specfact_project/test_import_runtime_policy.py`:\\n- Around line 16-23: The test module currently calls\\n_apply_import_runtime_patches() at import time which applies global patches too\\nearly; remove the top-level call to _apply_import_runtime_patches and instead\\ncreate a pytest fixture (e.g., import_runtime_patches_fixture) that imports\\nspecfact_project.import_runtime_patches and calls apply_import_runtime_patches()\\nin its setup and ensures proper teardown/unpatching in finalizer so patches\\n(Path.rglob, CodeAnalyzer.analyze, import helpers) are scoped to the fixture;\\nupdate tests that need the patch to request this fixture.\\n\\nIn `@tests/unit/workflows/test_sign_modules_on_approval.py`:\\n- Around line 52-55: The assertions that check event trigger lists are brittle\\ndue to ordering; update the tests to compare sets instead of lists: replace the\\nexact-equality assertions on pr_review[\\\"types\\\"] and pr[\\\"types\\\"] with\\norder-insensitive checks (e.g., assert set(pr_review[\\\"types\\\"]) == {\\\"submitted\\\"}\\nand assert set(pr[\\\"types\\\"]) ==\\n{\\\"opened\\\",\\\"synchronize\\\",\\\"reopened\\\",\\\"ready_for_review\\\"}) so the tests no longer\\nfail when YAML ordering changes; locate and update the assertions referencing\\npr_review[\\\"types\\\"] and pr[\\\"types\\\"] in test_sign_modules_on_approval.py.\\n```\\n\\n

\\n\\n

\\n

🪄 Autofix (Beta)

\\n\\n✅ Autofix completed\\n\\n

\\n\\n---\\n\\n

\\n

ℹ️ Review info

\\n\\n

\\n

⚙️ Run configuration

\\n\\n**Configuration used**: Path: .coderabbit.yaml\\n\\n**Review profile**: ASSERTIVE\\n\\n**Plan**: Pro\\n\\n**Run ID**: `cc3e5b23-6543-4060-bc25-c7e4163cac5e`\\n\\n

\\n\\n

\\n

📥 Commits

\\n\\nReviewing files that changed from the base of the PR and between 11f3f61601cdad85d2dd0e853a69a0e1ab4e687d and 39750733a68cd1ac8b652b1c46abcc51d84aff60.\\n\\n

\\n\\n

\\n

⛔ Files ignored due to path filters (3)

\\n\\n* `registry/modules/specfact-project-0.41.4.tar.gz` is excluded by `!**/*.gz`\\n* `registry/modules/specfact-project-0.41.5.tar.gz` is excluded by `!**/*.gz`\\n* `registry/modules/specfact-project-0.41.6.tar.gz` is excluded by `!**/*.gz`\\n\\n

\\n\\n

\\n

📒 Files selected for processing (82)

\\n\\n* `.github/workflows/sign-modules-on-approval.yml`\\n* `docs/bundles/project/import-migration.md`\\n* `openspec/CHANGE_ORDER.md`\\n* `openspec/changes/architecture-02-module-well-architected/.openspec.yaml`\\n* `openspec/changes/architecture-02-module-well-architected/design.md`\\n* `openspec/changes/architecture-02-module-well-architected/proposal.md`\\n* `openspec/changes/architecture-02-module-well-architected/specs/architecture-well-architected-module/spec.md`\\n* `openspec/changes/architecture-02-module-well-architected/tasks.md`\\n* `openspec/changes/codebase-import-runtime-hardening/.openspec.yaml`\\n* `openspec/changes/codebase-import-runtime-hardening/TDD_EVIDENCE.md`\\n* `openspec/changes/codebase-import-runtime-hardening/design.md`\\n* `openspec/changes/codebase-import-runtime-hardening/proposal.md`\\n* `openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\\n* `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n* `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n* `openspec/changes/enterprise-01-module-policy-client/.openspec.yaml`\\n* `openspec/changes/enterprise-01-module-policy-client/design.md`\\n* `openspec/changes/enterprise-01-module-policy-client/proposal.md`\\n* `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\\n* `openspec/changes/enterprise-01-module-policy-client/tasks.md`\\n* `openspec/changes/enterprise-02-module-audit-client/.openspec.yaml`\\n* `openspec/changes/enterprise-02-module-audit-client/design.md`\\n* `openspec/changes/enterprise-02-module-audit-client/proposal.md`\\n* `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\\n* `openspec/changes/enterprise-02-module-audit-client/tasks.md`\\n* `openspec/changes/finops-01-module-cost-outcome/.openspec.yaml`\\n* `openspec/changes/finops-01-module-cost-outcome/design.md`\\n* `openspec/changes/finops-01-module-cost-outcome/proposal.md`\\n* `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\\n* `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n* `openspec/changes/knowledge-01-module-memory-runtime/.openspec.yaml`\\n* `openspec/changes/knowledge-01-module-memory-runtime/design.md`\\n* `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\\n* `openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\\n* `openspec/changes/knowledge-01-module-memory-runtime/tasks.md`\\n* `openspec/changes/knowledge-02-module-writeback/.openspec.yaml`\\n* `openspec/changes/knowledge-02-module-writeback/design.md`\\n* `openspec/changes/knowledge-02-module-writeback/proposal.md`\\n* `openspec/changes/knowledge-02-module-writeback/specs/knowledge-writeback/spec.md`\\n* `openspec/changes/knowledge-02-module-writeback/tasks.md`\\n* `openspec/changes/review-resiliency-01-module/.openspec.yaml`\\n* `openspec/changes/review-resiliency-01-module/design.md`\\n* `openspec/changes/review-resiliency-01-module/proposal.md`\\n* `openspec/changes/review-resiliency-01-module/specs/review-resiliency-module/spec.md`\\n* `openspec/changes/review-resiliency-01-module/tasks.md`\\n* `openspec/changes/security-01-module-sast-sca-secret/.openspec.yaml`\\n* `openspec/changes/security-01-module-sast-sca-secret/design.md`\\n* `openspec/changes/security-01-module-sast-sca-secret/proposal.md`\\n* `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\\n* `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n* `openspec/changes/security-02-module-license-compliance/.openspec.yaml`\\n* `openspec/changes/security-02-module-license-compliance/design.md`\\n* `openspec/changes/security-02-module-license-compliance/proposal.md`\\n* `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\\n* `openspec/changes/security-02-module-license-compliance/tasks.md`\\n* `openspec/changes/security-03-module-pii-gdpr-eu/.openspec.yaml`\\n* `openspec/changes/security-03-module-pii-gdpr-eu/design.md`\\n* `openspec/changes/security-03-module-pii-gdpr-eu/proposal.md`\\n* `openspec/changes/security-03-module-pii-gdpr-eu/specs/privacy-gdpr-module/spec.md`\\n* `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n* `packages/specfact-project/module-package.yaml`\\n* `packages/specfact-project/resources/templates/github-action.yml.j2`\\n* `packages/specfact-project/resources/templates/persona/default.md.j2`\\n* `packages/specfact-project/resources/templates/protocol.yaml.j2`\\n* `packages/specfact-project/src/specfact_project/generators/plan_generator.py`\\n* `packages/specfact-project/src/specfact_project/generators/protocol_generator.py`\\n* `packages/specfact-project/src/specfact_project/generators/template_paths.py`\\n* `packages/specfact-project/src/specfact_project/generators/workflow_generator.py`\\n* `packages/specfact-project/src/specfact_project/import_cmd/commands.py`\\n* `packages/specfact-project/src/specfact_project/import_runtime_patches.py`\\n* `packages/specfact-project/src/specfact_project/sync/commands.py`\\n* `packages/specfact-project/src/specfact_project/utils/import_path_policy.py`\\n* `registry/index.json`\\n* `registry/modules/specfact-project-0.41.4.tar.gz.sha256`\\n* `registry/modules/specfact-project-0.41.5.tar.gz.sha256`\\n* `registry/modules/specfact-project-0.41.6.tar.gz.sha256`\\n* `registry/signatures/specfact-project-0.41.5.tar.sig`\\n* `registry/signatures/specfact-project-0.41.6.tar.sig`\\n* `scripts/ensure_github_hierarchy_subissues.py`\\n* `tests/unit/specfact_project/test_import_runtime_policy.py`\\n* `tests/unit/test_bundle_resource_payloads.py`\\n* `tests/unit/workflows/test_sign_modules_on_approval.py`\\n\\n

\\n\\n

\\n\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🌐 Web query:\\n\\n`GitHub GraphQL latestReviews pagination limit pull request`\\n\\n💡 Result:\\n\\nIn GitHub’s GraphQL API, the PR’s “latestReviews” (a connection of pull request reviews) uses standard cursor-based pagination on the connection. Pagination limit (page size): - When paginating any GraphQL connection, GitHub requires you to pass either first or last. - The allowed value range for first/last is 1–100, so the maximum you can fetch per page is 100 items. How to paginate: - Query the connection with first: N (or last: N) and use pageInfo { endCursor hasNextPage } (or startCursor hasPreviousPage for last). - To fetch the next page, pass after: along with the next first: N. Notes on rate/node limits (practical ceiling): - Even if first/last can be up to 100, you may need smaller page sizes to avoid running into GraphQL query limits (points) or the total node limit (and to reduce query cost). Example pagination pattern (for any such reviews connection): query ($owner: String!, $name: String!, $after: String) { repository(owner: $owner, name: $name) { pullRequests(first: 100, after: $after) { nodes { number title } pageInfo { endCursor hasNextPage } } } } You would apply the same pagination approach to the PR’s latestReviews connection: request latestReviews(first: 100, after: ...) and iterate using pageInfo.endCursor until hasNextPage is false.\\n\\nCitations:\\n\\n- 1: https://docs.github.com/en/graphql/guides/using-pagination-in-the-graphql-api\\n- 2: https://docs.github.com/en/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check PR history to understand typical reviewer patterns\\ngit log --oneline --all --grep=\\\"Merge pull request\\\" | head -20\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 46\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check the workflow file for context\\ncat -n .github/workflows/sign-modules-on-approval.yml | head -100\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 5186\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check recent PR activity and review patterns\\ngit log --oneline --all | head -30\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 2235\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if there are any recent PRs with many reviews in git history\\ngit log --all --format=\\\"%H %s\\\" | grep -i \\\"merge pull request\\\" | head -10\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1124\\n\\n---\\n\\n🏁 Script executed (no clone):\\n\\n```shell:none\\n# Query GitHub API to understand latestReviews semantics more clearly\\ncurl -s \\\"https://docs.github.com/en/graphql/reference/objects#pullrequest\\\" | grep -A 10 \\\"latestReviews\\\" || echo \\\"Could not fetch directly, checking docs...\\\"\\n```\\n\\nLength of output: 50345\\n\\n---\\n\\n\\n\\n

\\n\\n**Consider whether pagination is needed based on typical review patterns for this repository.**\\n\\nThe GraphQL query uses `latestReviews(first:100)` without pagination. GitHub's GraphQL API limits paginated results to 100 items per page, and `latestReviews` returns one review per reviewer. While pagination cursors are supported (via `pageInfo.endCursor` and `hasNextPage`), implementing pagination requires additional query complexity.\\n\\nFor typical team repositories with a modest number of reviewers, 100 is sufficient. If this repository historically has PRs with significantly more than 100 distinct reviewers, implement pagination; otherwise, document the 100-reviewer ceiling as an acceptable threshold.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn @.github/workflows/sign-modules-on-approval.yml around lines 68 - 81, The\\nGraphQL query uses latestReviews(first:100) which can miss reviews if a PR has\\n>100 distinct reviewers; update the sign workflow to handle pagination by\\nlooping requests using pageInfo.hasNextPage and pageInfo.endCursor (aggregate\\nnodes across pages) before computing trusted_review_count, referencing the\\nexisting trusted_review_count calculation and the latestReviews(...) field;\\nalternatively, if you decide 100 is an acceptable ceiling for this repo, add a\\nclear comment in the workflow near latestReviews(first:100) explaining that the\\n100-reviewer limit is intentional and documented.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\".github/workflows/sign-modules-on-approval.yml\",\"side\":\"RIGHT\",\"line\":81}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Python one-liner lacks explicit error handling for malformed responses.**\\n\\nIf the GraphQL response is missing expected keys (`data`, `repository`, `pullRequest`, or `latestReviews`), Python raises a `KeyError` that propagates through `set -euo pipefail`. While this fail-fast behavior is acceptable, a more descriptive error message would improve debugging. Consider wrapping in a try/except that emits a clearer notice before exit, or validate the structure first.\\n\\n\\n\\n

\\n

Example with explicit validation

\\n\\n```diff\\n- | python3 -c \\\"import json,sys; data=json.load(sys.stdin); reviews=data['data']['repository']['pullRequest']['latestReviews']['nodes']; print(sum(1 for review in reviews if review.get('state') == 'APPROVED' and review.get('authorAssociation') in {'COLLABORATOR','MEMBER','OWNER'}))\\\"\\n+ | python3 -c \\\"\\n+import json, sys\\n+data = json.load(sys.stdin)\\n+try:\\n+ reviews = data['data']['repository']['pullRequest']['latestReviews']['nodes']\\n+except (KeyError, TypeError) as e:\\n+ print(f'::error::GraphQL response missing expected structure: {e}', file=sys.stderr)\\n+ sys.exit(1)\\n+print(sum(1 for r in reviews if r.get('state') == 'APPROVED' and r.get('authorAssociation') in {'COLLABORATOR','MEMBER','OWNER'}))\\n+\\\"\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn @.github/workflows/sign-modules-on-approval.yml at line 74, The current\\nPython one-liner that parses the GraphQL JSON (the python3 -c \\\"import json,sys;\\ndata=json.load(sys.stdin); reviews=...; print(...)\\\") can raise a KeyError on\\nmissing keys; update it to validate the expected keys or wrap the parsing and\\nkey access in a try/except that catches (KeyError, TypeError, ValueError) and\\nprints a clear, descriptive error message to stderr (including which top-level\\nkey is missing and the raw input snippet or its summary) before exiting with a\\nnon-zero status so the GitHub Actions job fails with a useful message.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\".github/workflows/sign-modules-on-approval.yml\",\"side\":\"RIGHT\",\"line\":74}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a top-level H1 heading and fix heading spacing for markdownlint compliance.**\\n\\nThe file starts with `## Why` instead of an H1 title. Additionally, lines 15–16 and 18–19 violate MD022 (headings should be surrounded by blank lines).\\n\\n\\n\\n

\\n

Proposed fix (partial)

\\n\\n```diff\\n+# Proposal: codebase-import-runtime-hardening\\n+\\n ## Why\\n```\\n\\nAnd for the capability headings:\\n\\n```diff\\n ## Capabilities\\n\\n ### New Capabilities\\n+\\n - `codebase-import-runtime`: Default ignore policy, warning surfaces, and dynamic progress estimation for `specfact code import` runtime scans.\\n\\n ### Modified Capabilities\\n+\\n - `bundle-packaged-resources`: Project-bundle runtime generator templates become required packaged resources alongside prompts and other module-owned assets.\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 1-1: First line in a file should be a top-level heading\\n\\n(MD041, first-line-heading, first-line-h1)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/codebase-import-runtime-hardening/proposal.md` at line 1,\\nChange the document to include a top-level H1 heading before the existing\\ncontent (replace or precede the current \\\"## Why\\\" with an H1 like \\\"# Proposal\\\" or\\n\\\"# Changes for codebase-import runtime hardening\\\"), and fix heading spacing\\nviolations by adding a blank line above and below each heading that currently\\nviolates MD022 (specifically the headings around the content at lines referenced\\nin the review — the \\\"Why\\\" section and the capability headings mentioned in the\\nproposed fix) so all headings (e.g., the \\\"Why\\\" heading and the capability\\nheadings) are surrounded by blank lines and use the appropriate '#' level.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/proposal.md\",\"side\":\"RIGHT\",\"line\":1}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Make the paired-core artifact review explicit here.**\\n\\nThis checklist confirms availability, but it does not explicitly require reviewing the paired public OpenSpec/contracts in `nold-ai/specfact-cli` before implementation. Adding that step will reduce drift in change IDs, model names, and workflow assumptions. \\n\\nBased on learnings, \\\"When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\\\".\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/enterprise-01-module-policy-client/tasks.md` at line 4,\\nUpdate checklist item for enterprise-01-policy-resolution-extension to\\nexplicitly require reviewing the paired public OpenSpec/contracts in\\nnold-ai/specfact-cli before implementation and documenting the minimum required\\ncore_compatibility; add a sub-item that instructs the implementer to verify and\\nrecord matching change IDs, model names, and workflow semantics between this\\nchange and the paired specfact-cli artifacts (e.g., \\\"Review paired public\\nOpenSpec/contracts in nold-ai/specfact-cli and confirm matching change IDs/model\\nnames/workflow semantics; document minimum core_compatibility\\\"). Ensure the new\\ntext appears alongside the existing 1.2 checklist so reviewers cannot skip the\\npaired-core artifact review step.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/enterprise-01-module-policy-client/tasks.md\",\"side\":\"RIGHT\",\"line\":4}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add an explicit review step for the paired public core artifacts.**\\n\\nVerifying that the upstream change exists is weaker than reviewing the paired public OpenSpec/contracts that this bundle will implement against. Please call that out directly so the audit client does not drift from the authoritative core contract surface. \\n\\nBased on learnings, \\\"When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\\\".\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/enterprise-02-module-audit-client/tasks.md` at line 4,\\nUpdate the task checklist in enterprise-02-module-audit-client/tasks.md to add\\nan explicit step that reviewers must inspect the paired public core\\nOpenSpec/contracts (not just upstream sequencing) for the\\n`enterprise-02-rbac-and-audit-trail` change and any linked artifacts from\\n`enterprise-01-module-policy-client`; call out that reviewers should confirm the\\nauthoritative public artifacts in specfact-cli (or equivalent public repo) and\\nrecord the minimum required `core_compatibility` after that review. Ensure the\\nnew line references the paired artifact names\\n(`enterprise-02-rbac-and-audit-trail`, `enterprise-01-module-policy-client`,\\nspecfact-cli) and replaces or augments the existing weaker \\\"Confirm paired core\\nchange\\\" item.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/enterprise-02-module-audit-client/tasks.md\",\"side\":\"RIGHT\",\"line\":4}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Consider using a descriptive H1 title for consistency.**\\n\\nThe file starts with `# 1. Branch and dependency guardrails`, which is technically an H1 but uses a numbered format. Other OpenSpec files use descriptive titles (e.g., `# Change: ...`, `# Design: ...`). For consistency, consider:\\n\\n```diff\\n-# 1. Branch and dependency guardrails\\n+# Tasks: knowledge-01-module-memory-runtime\\n+\\n+## 1. Branch and dependency guardrails\\n```\\n\\nThis is a minor stylistic note—the current format is functional.\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-01-module-memory-runtime/tasks.md` at line 1,\\nReplace the numeric H1 \\\"# 1. Branch and dependency guardrails\\\" with a\\ndescriptive H1 to match other OpenSpec files (for example \\\"Change: Branch and\\ndependency guardrails\\\" or \\\"Design: Branch and dependency guardrails\\\"); update\\nthe header string in the tasks.md file so the top-level title uses a descriptive\\nlabel rather than a leading number to maintain consistency across specs.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/knowledge-01-module-memory-runtime/tasks.md\",\"side\":\"RIGHT\",\"line\":1}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Consider using a descriptive H1 title for consistency with other OpenSpec files.**\\n\\nSame pattern as `knowledge-01-module-memory-runtime/tasks.md`—a descriptive title like `# Tasks: security-02-module-license-compliance` followed by `## 1.` would align better with proposal/design naming conventions.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/tasks.md` at line 1,\\nReplace the top-level header so the file uses a descriptive H1 like other\\nOpenSpec files: change the existing \\\"# 1. Branch and dependency guardrails\\\" to\\n\\\"# Tasks: security-02-module-license-compliance\\\" and then demote the current\\nheader to a section header by adding \\\"## 1. Branch and dependency guardrails\\\"\\nimmediately below; update the headers in\\nopenspec/changes/security-02-module-license-compliance/tasks.md to match this\\npattern so it aligns with knowledge-01-module-memory-runtime/tasks.md.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/security-02-module-license-compliance/tasks.md\",\"side\":\"RIGHT\",\"line\":1}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n**Honor `subdir` and `required_glob` for explicit template overrides too.**\\n\\nThe early return bypasses the same path shaping and validation applied to auto-discovered roots, so `templates_dir=...` can silently point generators at the wrong directory or skip the required template existence check. \\n\\n

\\n

Proposed fix

\\n\\n```diff\\n if templates_dir is not None:\\n- return Path(templates_dir)\\n+ candidate = _target(Path(templates_dir), subdir)\\n+ if _matches_required_glob(candidate, required_glob):\\n+ return candidate\\n+ raise RuntimeError(\\n+ f\\\"Explicit template root did not match required_glob={required_glob!r}: {candidate}\\\"\\n+ )\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@packages/specfact-project/src/specfact_project/generators/template_paths.py`\\naround lines 39 - 40, Remove the early return for templates_dir and instead run\\nthe explicit override through the same path shaping and validation applied to\\nauto-discovered roots: when templates_dir is provided, join/append subdir (if\\nsubdir is set) to templates_dir, convert to a Path, and validate that it\\ncontains files matching required_glob before returning it; ensure you use the\\nsame logic/code paths that handle discovered roots so explicit overrides honor\\nsubdir and required_glob (referencing the templates_dir, subdir and\\nrequired_glob symbols).\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"packages/specfact-project/src/specfact_project/generators/template_paths.py\",\"side\":\"RIGHT\",\"line\":40}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\nset -euo pipefail\\n\\npython - <<'PY'\\nimport ast\\nfrom pathlib import Path\\n\\ntargets = {\\\"_analyze_codebase\\\", \\\"_extract_relationships_and_graph\\\"}\\n\\nfor path in Path(\\\".\\\").rglob(\\\"commands.py\\\"):\\n if \\\"packages/specfact-project/src/specfact_project\\\" not in str(path):\\n continue\\n\\n tree = ast.parse(path.read_text(encoding=\\\"utf-8\\\"))\\n for node in ast.walk(tree):\\n if isinstance(node, ast.FunctionDef) and node.name in targets:\\n args = [arg.arg for arg in node.args.args]\\n defaults = [None] * (len(args) - len(node.args.defaults)) + list(node.args.defaults)\\n print(f\\\"{path}:{node.lineno} {node.name}\\\")\\n for arg, default in zip(args, defaults):\\n rendered = \\\"\\\" if default is None else ast.unparse(default)\\n print(f\\\" - {arg}: {rendered}\\\")\\nPY\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 711\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\nset -euo pipefail\\n\\n# Read the import_runtime_patches.py file to understand context around lines 181-186\\ncat -n packages/specfact-project/src/specfact_project/import_runtime_patches.py | sed -n '160,200p'\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1993\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\nset -euo pipefail\\n\\n# Search for where patched wrapper is called and how it's applied to actual functions\\nrg -n \\\"patched.*=\\\" packages/specfact-project/src/specfact_project/import_runtime_patches.py | head -20\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 417\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\nset -euo pipefail\\n\\n# Get the full function context for the patched function (broader range)\\ncat -n packages/specfact-project/src/specfact_project/import_runtime_patches.py | sed -n '150,220p'\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 3461\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\nset -euo pipefail\\n\\n# Find all functions that look like args_builder functions\\nrg -n \\\"def.*_from_mapping|arguments\\\\[\\\" packages/specfact-project/src/specfact_project/import_runtime_patches.py\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 951\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\nset -euo pipefail\\n\\n# Get the complete view of how _install_patch is being used\\nrg -B5 -A5 \\\"_install_patch\\\" packages/specfact-project/src/specfact_project/import_runtime_patches.py\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1119\\n\\n---\\n\\n\\n\\n

\\n\\n**Use `bound.apply_defaults()` to preserve callable semantics across patched invocations.**\\n\\nThe `patched()` wrapper currently relies on `bind_partial()` without `apply_defaults()`, leaving omitted defaulted parameters out of `bound.arguments`. While the current args_builders defensively use `.get()` calls for optional parameters (lines 173, 217), this pattern is fragile—any future args_builder using direct dictionary access will break when defaults are omitted. The proper fix is to restore default values before building arguments, ensuring the wrapper semantically mirrors the original callable.\\n\\n

\\n

Proposed fix

\\n\\n```diff\\n def patched(*args: Any, **kwargs: Any) -> Any:\\n bound = signature.bind_partial(*args, **kwargs)\\n+ bound.apply_defaults()\\n built = args_builder(dict(bound.arguments))\\n if kwargs:\\n built = replace(built, **kwargs)\\n return runner(original, context, built)\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@packages/specfact-project/src/specfact_project/import_runtime_patches.py`\\naround lines 181 - 186, The patched wrapper uses signature.bind_partial(...)\\nwhich omits defaulted parameters; after binding call bound.apply_defaults() to\\npopulate missing defaults before passing bound.arguments into args_builder, so\\nin patched (the function that does signature.bind_partial(*args, **kwargs) and\\nthen built = args_builder(dict(bound.arguments))) insert bound.apply_defaults()\\nand then continue with built transformation and runner(original, context,\\nbuilt); keep existing replace(built, **kwargs) behavior intact.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"packages/specfact-project/src/specfact_project/import_runtime_patches.py\",\"side\":\"RIGHT\",\"line\":186}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n**Normalize extensions on the `options=` path as well.**\\n\\nRight now the kwargs form accepts both `{\\\"py\\\"}` and `{\\\".py\\\"}`, but the public `ImportDiscoveryOptions` form only works for the dotted variant because normalization happens in just one branch. That makes the new API silently inconsistent for callers switching to the options object. \\n\\n

\\n

Proposed fix

\\n\\n```diff\\n def discover_code_files(\\n repo_root: Path,\\n options: ImportDiscoveryOptions | None = None,\\n **kwargs: Any,\\n ) -> ImportDiscoveryResult:\\n@@\\n elif kwargs:\\n unexpected = \\\", \\\".join(sorted(str(key) for key in kwargs))\\n raise TypeError(f\\\"Unexpected discovery keyword overrides with options object: {unexpected}\\\")\\n+ else:\\n+ options = ImportDiscoveryOptions(\\n+ extensions=_normalize_extensions(options.extensions),\\n+ entry_point=options.entry_point,\\n+ include_tests=options.include_tests,\\n+ ignore_patterns=options.ignore_patterns,\\n+ allow_hidden=options.allow_hidden,\\n+ heavy_ignored_entry_threshold=options.heavy_ignored_entry_threshold,\\n+ large_repo_file_threshold=options.large_repo_file_threshold,\\n+ max_files=options.max_files,\\n+ )\\n return _discover_code_files_with_options(\\n repo_root,\\n options,\\n )\\n```\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@packages/specfact-project/src/specfact_project/utils/import_path_policy.py`\\naround lines 443 - 468, discover_code_files normalizes file extensions only when\\nbuilding ImportDiscoveryOptions from kwargs, causing inconsistency when callers\\npass an ImportDiscoveryOptions instance; update the options branch to normalize\\nextensions too by calling _normalize_extensions on options.extensions (or\\nreplacing options.extensions with the normalized result) before passing options\\nto _discover_code_files_with_options so both code paths accept extensions with\\nor without a leading dot; reference functions/classes: discover_code_files,\\nImportDiscoveryOptions, _normalize_extensions, and\\n_discover_code_files_with_options.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"packages/specfact-project/src/specfact_project/utils/import_path_policy.py\",\"side\":\"RIGHT\",\"line\":468}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n**Avoid applying the global runtime patch during module import.**\\n\\nThis runs before pytest fixtures can scope or restore the mutated state, so unrelated tests can become order-dependent once `Path.rglob`, `CodeAnalyzer.analyze`, or the import command helpers are patched for the whole process. Please move this behind a fixture that owns setup/teardown for the patch lifecycle. \\n\\nAs per coding guidelines, `tests/**/*.py`: Contract-first and integration tests: migration suites, bundle validation, and flakiness.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@tests/unit/specfact_project/test_import_runtime_policy.py` around lines 16 -\\n23, The test module currently calls _apply_import_runtime_patches() at import\\ntime which applies global patches too early; remove the top-level call to\\n_apply_import_runtime_patches and instead create a pytest fixture (e.g.,\\nimport_runtime_patches_fixture) that imports\\nspecfact_project.import_runtime_patches and calls apply_import_runtime_patches()\\nin its setup and ensures proper teardown/unpatching in finalizer so patches\\n(Path.rglob, CodeAnalyzer.analyze, import helpers) are scoped to the fixture;\\nupdate tests that need the patch to request this fixture.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"tests/unit/specfact_project/test_import_runtime_policy.py\",\"side\":\"RIGHT\",\"line\":23}{\"type\":\"pull_request_comment\",\"body\":\"**Review continued from previous batch...**\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n> [!NOTE]\\n> Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it.\\n\\n## Fixes Applied Successfully\\n\\nFixed 29 file(s) based on 40 unresolved review comments.\\n\\n\\n\\n**Files modified:**\\n- `docs/bundles/project/import-migration.md`\\n- `openspec/CHANGE_ORDER.md`\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\\n- `openspec/changes/codebase-import-runtime-hardening/design.md`\\n- `openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n- `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\\n- `openspec/changes/enterprise-02-module-audit-client/design.md`\\n- `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\\n- `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n- `openspec/changes/knowledge-01-module-memory-runtime/design.md`\\n- `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\\n- `openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\\n- `openspec/changes/knowledge-02-module-writeback/design.md`\\n- `openspec/changes/knowledge-02-module-writeback/proposal.md`\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/design.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n- `openspec/changes/security-02-module-license-compliance/design.md`\\n- `openspec/changes/security-02-module-license-compliance/proposal.md`\\n- `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n- `packages/specfact-project/resources/templates/persona/default.md.j2`\\n- `scripts/ensure_github_hierarchy_subissues.py`\\n- `tests/unit/workflows/test_sign_modules_on_approval.py`\\n\\n**Commit:** `0672f50fc279db70e7351ed9079417d641efe976`\\n\\nThe changes have been pushed to the `promote/pr-236-to-main` branch.\\n\\n**Time taken:** `16m 31s`\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Verify whether documented thresholds are implemented in runtime code.\\n# Expected: concrete constants/checks for file count, repo size, and commit count (or absence thereof).\\n\\nrg -n -C3 --type=py '100000|100,000|10\\\\s*GB|commit|heavy|threshold|warn' packages/specfact-project/src/specfact_project\\nrg -n -C3 --type=py 'remaining time|provisional|about five minutes|fixed-duration' packages/specfact-project/src/specfact_project\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 50385\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Find constant definitions for thresholds\\nrg -n \\\"_DEFAULT_HEAVY_IGNORED_ENTRY_THRESHOLD|_DEFAULT_LARGE_REPO_FILE_THRESHOLD\\\" packages/specfact-project/src/specfact_project/utils/import_path_policy.py -A 1 -B 1\\n\\n# Search for any repository size (bytes/GB) or commit count thresholds\\nrg -n \\\"10.*1024|1024.*1024|100.*1000|commit.*count|repo.*size|bytes|GB\\\" packages/specfact-project/src/specfact_project/utils/import_path_policy.py\\n\\n# Check for provisionalETA build logic that mentions duration\\nrg -n \\\"_build_provisional_eta|provisional\\\" packages/specfact-project/src/specfact_project/utils/import_path_policy.py -A 5\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1402\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Get the full _build_provisional_eta function\\nsed -n '346,365p' packages/specfact-project/src/specfact_project/utils/import_path_policy.py\\n\\n# Get the full _build_warnings function\\nsed -n '327,343p' packages/specfact-project/src/specfact_project/utils/import_path_policy.py\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1344\\n\\n---\\n\\n\\n\\n

\\n\\n**Correct threshold values in documentation.**\\n\\nLines 39-40 claim import warnings trigger at `>10,000 ignored entries`, `~100,000 files`, `~10 GB`, and `>100,000 commits`. The runtime implementation uses only file-count and entry-count thresholds:\\n\\n- Heavy ignored entry threshold: **500** entries (not >10,000)\\n- Large repository file threshold: **1,000** files (not ~100,000)\\n- No GB or commit-count thresholds exist in the code\\n\\nUpdate the documentation to reflect the actual configured thresholds, or generalize wording to \\\"configured thresholds\\\" as originally suggested if the values are intended to be user-configurable.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@docs/bundles/project/import-migration.md` around lines 39 - 40, Update the\\ndoc text that currently lists thresholds (>10,000 ignored entries, ~100,000\\nfiles, ~10 GB, >100,000 commits) to match the implementation: state the heavy\\nignored-entry threshold is 500 entries and the large-repo file threshold is\\n1,000 files, and remove references to GB or commit-count thresholds (or replace\\nthe fixed values with a note that the system uses configured thresholds) so the\\nsentence about remaining-time estimates refers to repositories above those\\nactual/configured thresholds; update the phrases that mention \\\"ignored artifact\\ntrees\\\" and \\\"Remaining time is based on...\\\" to reflect the corrected thresholds\\nor that such limits are configurable.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit b672278\",\"path\":\"docs/bundles/project/import-migration.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add trailing newline to satisfy docs lint.**\\n\\nLine 272 is missing the final newline (MD047).\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 272-272: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@docs/bundles/project/import-migration.md` at line 272, Add a final trailing\\nnewline to the markdown file by ensuring the last line containing \\\"**Happy\\nimporting!** 🚀\\\" ends with a newline character; simply append a newline after\\nthat line so the file ends with a blank line to satisfy MD047.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"docs/bundles/project/import-migration.md\",\"side\":\"RIGHT\",\"line\":272}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a trailing newline to pass markdownlint gate.**\\n\\nLine 129 is the file’s last line without a terminating newline (MD047).\\n\\n\\n

\\n

Suggested fix

\\n\\n```diff\\n | peer-deps | 01 | ✅ module-bundle-deps-auto-install (archived 2026-04-05) | [`#135`](https://github.com/nold-ai/specfact-cli-modules/issues/135) | — |\\n+\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 129-129: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/CHANGE_ORDER.md` at line 129, The file's last line (the table row\\ncontaining \\\"| peer-deps | 01 | ✅ module-bundle-deps-auto-install (archived\\n2026-04-05) | [`#135`](https://github.com/nold-ai/specfact-cli-modules/issues/135)\\n| — |\\\") is missing a terminating newline which triggers MD047; add a single\\ntrailing newline character at the end of CHANGE_ORDER.md so the file ends with a\\nnewline and re-run markdownlint to confirm the warning is cleared.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/CHANGE_ORDER.md\",\"side\":\"RIGHT\",\"line\":129}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Check if architecture-02-module-well-architected is referenced in CHANGE_ORDER and import hardening specs\\n\\n# Search CHANGE_ORDER for architecture-02 references\\nrg -n \\\"architecture-02\\\" openspec/CHANGE_ORDER.md || echo \\\"No architecture-02 references found in CHANGE_ORDER\\\"\\n\\n# Check if import hardening specs reference architecture module\\nrg -n \\\"architecture-02\\\\|specfact-architecture\\\" openspec/changes/codebase-import-runtime-hardening/ || echo \\\"No architecture references in import hardening specs\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 622\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check CHANGE_ORDER context for architecture-02 ordering and batching\\nrg -B5 -A5 \\\"architecture-02-module-well-architected\\\" openspec/CHANGE_ORDER.md\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 5043\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Verify if paired core change architecture-02-well-architected-review exists in specfact-cli\\nrg -r \\\"architecture-02-well-architected-review\\\\|architecture.*well-architected\\\" openspec/ || echo \\\"No matches found in specfact-cli openspec\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 50377\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if PR description or commits indicate intentional batching of architecture-02 with this PR\\ngit log --oneline --all | head -20\\ngit show HEAD --stat | head -30\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 3011\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if design.md is new or modified, and what the overall PR scope is\\ngit diff --name-status HEAD~1 HEAD | head -30\\ngit show HEAD:openspec/changes/architecture-02-module-well-architected/design.md 2>/dev/null | head -5 || echo \\\"File not in HEAD\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 651\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check PR description or commit message for stated scope\\ngit log -1 --format=%B HEAD\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 214\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Understand the actual scope of changes in this repository state\\n# Check if packages/specfact-architecture/ exists\\nfind . -type d -name \\\"*architecture*\\\" | grep -E \\\"packages|modules\\\" | head -20\\nls -la openspec/changes/architecture-02-module-well-architected/ 2>/dev/null | head -20\\ngit status\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 711\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/antml:thinking\\nNeed to understand: is the PR actually shipping architecture-02 module code, or just spec/design docs? And what is the relationship to import hardening work?\\n`#/bin/bash`\\n# Check what's actually in this change directory and understand PR intent\\nls -R openspec/changes/architecture-02-module-well-architected/ 2>/dev/null | head -50\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 439\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Verify if there are actual implementation files under packages/specfact-architecture/\\nfind packages -type d -name \\\"*architecture*\\\" 2>/dev/null || echo \\\"No architecture package directory found\\\"\\nfind src -type d -name \\\"*architecture*\\\" 2>/dev/null || echo \\\"No architecture source directory found\\\"\\n# List what's actually in packages/\\nls -la packages/ | head -20\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 579\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Understand PR intent: check what actually changed between branches\\n# Look at the current PR's commit to see what files were modified\\ngit show HEAD --stat | head -50\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 2849\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Verify if paired core work exists for architecture-02\\n# Check if there's a corresponding architecture change in specfact-cli openspec\\nfind openspec/changes -type d -name \\\"*architecture-02*\\\" 2>/dev/null || echo \\\"No architecture-02 changes in specfact-cli\\\"\\nls -la openspec/changes/ | grep -i architecture || echo \\\"No architecture changes found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 145\\n\\n---\\n\\n\\n\\n

\\n\\n**Verify paired core change status before shipping architecture-02 module design.**\\n\\nArchitecture-02 is properly sequenced in CHANGE_ORDER as order-03 change under parent epic `#216`. However, the design acknowledges a critical prerequisite: \\\"A new core change `architecture-02-well-architected-review` must be created and synced into `specfact-cli` before module integration\\\" (line 50). \\n\\nConfirm that the paired core change has been created in `specfact-cli` and is available for module binding. The design defers module implementation to step 2 of the migration plan, contingent on core contract stability. Before merging, verify:\\n- Core change `architecture-02-well-architected-review` exists in `specfact-cli` and defines the findings contract\\n- Module-to-core binding points (adapter contracts, report schema) are finalized and tested in specfact-cli\\n- Migration plan sequencing aligns with actual core availability and registry timeline\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` around\\nlines 1 - 57, Ensure the paired core change\\n\\\"architecture-02-well-architected-review\\\" exists and is synced into specfact-cli\\nbefore merging this module design: verify the core change defines the\\nfindings/report contract referenced by packages/specfact-architecture, confirm\\nthe module-to-core binding points (adapter contracts and report schema used by\\nthe analyzer adapters and rule-resource translation) are finalized and tested\\nagainst specfact-cli, update CHANGE_ORDER (order-03) and the Migration Plan to\\nreflect actual core availability and registry timeline, and block or defer\\nmerging of the architecture-02 module design until those confirmations/pass CI\\ntests are completed.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit b672278\",\"path\":\"openspec/changes/architecture-02-module-well-architected/design.md\",\"side\":\"RIGHT\",\"line\":78}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n**Core contract dependency acknowledged but not verified.**\\n\\nLine 50 addresses the previous review finding by noting that `architecture-02-well-architected-review` must be created in `specfact-cli` before module integration. However, the linked repositories context from specfact-cli confirms this core contract does not yet exist. Merging this design document before the paired core contract is defined risks specification drift and incompatible adapter implementations.\\n\\nConsider:\\n- Deferring merge of this design until the core contract is created and stable in specfact-cli, or\\n- Adding explicit blockers/dependencies to track that module implementation cannot proceed until the core contract exists\\n\\n\\n\\nBased on learnings, when a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\\n50, The document references a required core contract\\narchitecture-02-well-architected-review that is not present in specfact-cli; to\\nfix, block merging of this design until that core change is created and synced\\nin specfact-cli or explicitly add a dependency/blocker statement in this file\\nnoting that module integration and any references to\\narchitecture-02-well-architected-review (and overlaps with\\narchitecture-01-solution-layer) are disallowed until the paired specfact-cli\\nchange exists and is marked stable; update design.md to include a clear\\ndependency checklist and a gating sentence that prevents implementation work\\nuntil specfact-cli contains the architecture-02-well-architected-review\\nartifact.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit b672278\",\"path\":\"openspec/changes/architecture-02-module-well-architected/design.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Add trailing newline.**\\n\\nStatic analysis (markdownlint MD047) requires files to end with a single newline character.\\n\\n\\n\\n

\\n

📝 Proposed fix

\\n\\n```diff\\n - Should interface diff support start with one ecosystem or ship as a provider abstraction from the first implementation?\\n+\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\\n57, The file ends without a trailing newline which violates markdownlint MD047;\\nopen the file containing the line \\\"Should interface diff support start with one\\necosystem or ship as a provider abstraction from the first implementation?\\\"\\n(design.md) and add a single newline character at the end of the file so it ends\\nwith exactly one trailing newline.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/architecture-02-module-well-architected/design.md\",\"side\":\"RIGHT\",\"line\":78}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🔴 Critical_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Search for architecture findings schema definitions in core and modules repos\\n\\n# Check if a separate architecture findings schema exists\\nrg -n \\\"class.*ArchitectureFinding\\\\|architecture.*schema\\\\|ArchitectureReport\\\" --type=py --type=md || echo \\\"No separate architecture schema found\\\"\\n\\n# Verify ReviewFinding is used for architecture category\\nrg -n \\\"category.*architecture|architecture.*category\\\" openspec/specs/review-finding-model/spec.md\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 109\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read the proposal.md file to verify the adapter contract schema (lines 15-22)\\necho \\\"=== Reading proposal.md lines 15-22 ===\\\"\\nsed -n '15,22p' openspec/changes/architecture-02-module-well-architected/proposal.md\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 934\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for ReviewFinding model definition in core repo\\necho \\\"=== Searching for ReviewFinding model definition ===\\\"\\nrg -n \\\"class ReviewFinding|ReviewFinding.*=|architecture.*findings\\\" --type=py --type=md | head -30\\n\\necho \\\"\\\"\\necho \\\"=== Checking review-finding-model spec for architecture mentions ===\\\"\\nrg -n \\\"architecture\\\" openspec/specs/review-finding-model/spec.md || echo \\\"No matches found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 4816\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Look for the actual ReviewFinding schema definition structure\\necho \\\"=== Searching for ReviewFinding fields/schema ===\\\"\\nrg -n \\\"severity|category|tool|rule|file|line|message|fixable\\\" openspec/specs/review-finding-model/spec.md | head -50\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 803\\n\\n---\\n\\n\\n\\n

\\n\\n**Adapter contract schema must align with core ReviewFinding model.**\\n\\nThe Adapter Contract (lines 19-20) defines required fields as `id`, `type`, `severity`, `description`, `source`, `timestamp`, `evidence_refs`, but the actual `ReviewFinding` model in specfact-cli core (`openspec/specs/review-finding-model/spec.md` line 11) specifies: `category`, `severity`, `tool`, `rule`, `file`, `line`, `message`, `fixable`. Only `severity` overlaps.\\n\\nThe pylint-runner spec confirms architecture findings must emit `ReviewFinding` with `category=\\\"architecture\\\"` and `tool=\\\"pylint\\\"` (pylint-runner/spec.md line 17), establishing that the module must produce the core ReviewFinding schema, not a custom adapter schema.\\n\\nUpdate the Adapter Contract to map analyzer outputs to ReviewFinding fields: `category` (set to `\\\"architecture\\\"`), `tool` (analyzer name), `rule` (violation rule ID), `file` and `line` (violation locations), `message` (human-readable description), and `severity` (error/warning/info). This ensures architecture findings flow correctly through the core review model boundary without custom adaptation.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` around\\nlines 15 - 22, Update the \\\"Adapter Contract\\\" section so it maps analyzer outputs\\nto the core ReviewFinding model instead of a custom schema: replace the\\n\\\"Required Core Findings Schema Fields\\\" and \\\"Analyzer Output Mapping\\\"\\ndescriptions with mapping to ReviewFinding fields — set category=\\\"architecture\\\",\\ntool=, rule=, file=, line=, message=, and\\nseverity=; retain evidence_refs only as supplemental\\nreferences but ensure primary location data uses file/line; align wording with\\nthe ReviewFinding spec and mention pylint-runner expectation that category must\\nbe \\\"architecture\\\" and tool \\\"pylint\\\".\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit b672278\",\"path\":\"openspec/changes/architecture-02-module-well-architected/proposal.md\",\"side\":\"RIGHT\",\"line\":37}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Add trailing newline.**\\n\\nStatic analysis (markdownlint MD047) requires files to end with a single newline character.\\n\\n\\n\\n

\\n

📝 Proposed fix

\\n\\n```diff\\n - **Sanitized**: false\\n+\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 54-54: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` at line\\n54, The file ends without a trailing newline (see the line containing\\n\\\"**Sanitized**: false\\\" in proposal.md); add a single newline character at the\\nend of the file so the file terminates with exactly one trailing newline to\\nsatisfy markdownlint MD047.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/architecture-02-module-well-architected/proposal.md\",\"side\":\"RIGHT\",\"line\":69}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Fix missing trailing newline at EOF.**\\n\\nLine 93 needs a terminal newline to satisfy markdownlint MD047.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 93-93: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/codebase-import-runtime-hardening/design.md` at line 93, Add\\na terminal newline to the end of the document so the final line \\\"None for\\nimplementation start; warning thresholds can be tuned in-code if test evidence\\nshows the initial defaults are too noisy.\\\" ends with a newline (satisfy\\nmarkdownlint MD047); simply ensure the file's EOF contains a trailing newline\\ncharacter.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/design.md\",\"side\":\"RIGHT\",\"line\":93}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Append a final newline for MD047 compliance.**\\n\\nLine 19 ends the file without a single trailing newline.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 19-19: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\\nat line 19, The file ends without a trailing newline causing MD047; append a\\nsingle final newline character to the end of the spec so the last line \\\"**AND**\\nthe failure message SHALL name the missing template path so the packaging defect\\ncan be corrected before publish\\\" is terminated by a newline (i.e., ensure the\\nfile ends with one newline character).\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md\",\"side\":\"RIGHT\",\"line\":19}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add the missing EOF newline.**\\n\\nLine 57 should end with a trailing newline (MD047).\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 57-57: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\nat line 57, The file ends without a trailing newline on the final line\\ncontaining \\\"- **AND** any early estimate before full discovery SHALL be labeled\\nas provisional rather than a fixed promise\\\"; open the file and add a single\\nnewline character (EOF newline) after that line so the document ends with a\\ntrailing newline to satisfy MD047.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md\",\"side\":\"RIGHT\",\"line\":57}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add trailing newline at EOF.**\\n\\nLine 32 should be followed by a single newline to clear MD047.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 32-32: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/codebase-import-runtime-hardening/tasks.md` at line 32, Add\\na single trailing newline at the end of\\nopenspec/changes/codebase-import-runtime-hardening/tasks.md so the final line \\\"-\\n[ ] 5.4 Commit, push, and open or update the PR to `dev` after verification is\\ngreen.\\\" is followed by one newline (fixes MD047); simply ensure the file ends\\nwith a single blank line.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/codebase-import-runtime-hardening/tasks.md\",\"side\":\"RIGHT\",\"line\":32}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add trailing newline to satisfy MD047.**\\n\\nThe file is missing a trailing newline character after line 57.\\n\\n\\n\\n

\\n

📝 Proposed fix

\\n\\nAdd a single newline after the last line of content:\\n\\n```diff\\n ## Open Questions\\n \\n - Which queue storage format best balances resilience and inspectability for the initial release?\\n - How should retry cadence and dead-letter behavior be surfaced in the first client contract?\\n+\\n```\\n\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n> ‼️ **IMPORTANT**\\n> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.\\n\\n```suggestion\\n# Design\\n\\n## Context\\n\\nThe five-pillar enterprise design keeps server contracts out of scope for this wave, but it still needs a client-side audit bundle that can prepare, queue, sign, and inspect governance events. This module must interoperate with the paired core audit schema and with the enterprise policy client while remaining safe for disconnected or partially configured environments.\\n\\n## Goals / Non-Goals\\n\\n**Goals:**\\n\\n- Define the package structure and command ownership for `specfact-enterprise-audit`.\\n- Emit signed, privacy-aware audit events aligned with the paired core schema.\\n- Support local queueing and retry/inspection behavior for events that cannot be delivered immediately.\\n- Keep event metadata structured enough for later reconciliation and drift analytics.\\n\\n**Non-Goals:**\\n\\n- Implement the enterprise audit service or server-side storage.\\n- Replace the paired core audit-event schema or RBAC semantics.\\n- Require immediate network delivery for every governance action.\\n\\n## Decisions\\n\\n### 1. Ship audit emission as its own enterprise bundle\\n\\n- **Decision**: Create `packages/specfact-enterprise-audit/` with dedicated emission and inspection commands.\\n- **Why**: Audit transport, buffering, and event privacy are separate concerns from policy sync or base governance logic.\\n- **Alternative considered**: Combine audit behavior with the enterprise policy bundle. Rejected because it couples two independently deployable surfaces.\\n\\n### 2. Queue first, deliver later when necessary\\n\\n- **Decision**: The bundle records deterministic local queue metadata for events that cannot be delivered immediately.\\n- **Why**: Enterprise governance actions must not be lost because a remote endpoint is temporarily unavailable.\\n- **Alternative considered**: Fail the originating action whenever the audit backend is unavailable. Rejected because it creates brittle runtime behavior for disconnected workflows.\\n\\n### 3. Keep payloads privacy-aware by design\\n\\n- **Decision**: Audit payloads include structured event metadata and references, not raw sensitive content.\\n- **Why**: Audit surfaces must preserve accountability without leaking governed data.\\n- **Alternative considered**: Store raw payload snapshots for debugging. Rejected because it conflicts with the security/privacy posture of the broader platform.\\n\\n## Risks / Trade-offs\\n\\n- **Risk**: Local queue growth may become operationally noisy. → **Mitigation**: provide inspection commands and deterministic receipt/retention metadata.\\n- **Risk**: Delivery semantics may evolve with the future server implementation. → **Mitigation**: keep this change focused on client-side event preparation and queueing contracts.\\n- **Risk**: Overly sparse payloads could weaken audit usefulness. → **Mitigation**: preserve event type, actor role, target references, and source rule/policy identifiers in the schema mapping.\\n\\n## Migration Plan\\n\\n1. Confirm the paired core audit/RBAC contracts are stable enough for module integration.\\n2. Implement package structure, signing helpers, queue storage, and inspection commands.\\n3. Publish docs, registry metadata, signatures, and compatibility range together.\\n\\n## Open Questions\\n\\n- Which queue storage format best balances resilience and inspectability for the initial release?\\n- How should retry cadence and dead-letter behavior be surfaced in the first client contract?\\n\\n```\\n\\n

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/enterprise-02-module-audit-client/design.md` around lines 1\\n- 57, The file ending after the \\\"## Open Questions\\\" section (look for the\\ntop-level heading \\\"# Design\\\" or the \\\"## Context\\\" / \\\"## Open Questions\\\" markers)\\nis missing a trailing newline; to fix, open the markdown file for writing and\\nappend a single newline character at the end of the file so the last line (after\\n\\\"How should retry cadence and dead-letter behavior be surfaced in the first\\nclient contract?\\\") ends with a newline to satisfy MD047.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/enterprise-02-module-audit-client/design.md\",\"side\":\"RIGHT\",\"line\":57}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Append final newline for markdownlint compliance.**\\n\\nLine 30 is missing the single trailing newline required by MD047.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\\nat line 30, Append a single trailing newline to the end of the markdown file so\\nthe final line \\\"**THEN** it records the session outcome as `rule-updated` in the\\nnormalized FinOps evidence\\\" ends with a newline (fixing MD047); ensure no other\\nwhitespace changes are made.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md\",\"side\":\"RIGHT\",\"line\":30}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Ensure file ends with one trailing newline.**\\n\\nLine 27 currently lacks the final newline required by MD047.\\n\\n\\nBased on learnings, module signature artifacts are produced by publish automation, and this task wording is correctly aligned.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 27-27: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/finops-01-module-cost-outcome/tasks.md` at line 27, The file\\nends without a trailing newline causing MD047; add a single trailing newline to\\nthe end of the file so the final checklist line \\\"- [ ] 4.5 Open the modules PR\\nto `dev`, cross-link paired telemetry/FinOps changes, and note any deferred\\nprovider integrations as follow-up issues.\\\" is terminated by a newline character\\n(ensure only one final newline).\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/finops-01-module-cost-outcome/tasks.md\",\"side\":\"RIGHT\",\"line\":27}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a trailing newline at EOF.**\\n\\nMinor markdownlint compliance fix (MD047).\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 55-55: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-01-module-memory-runtime/design.md` at line 55,\\nAdd a trailing newline at the end of the file by ensuring the final line \\\"-\\nShould search support only tags and keywords initially, or also relationship\\ntraversal commands?\\\" is followed by a single newline character (i.e., ensure EOF\\nends with a newline) to satisfy markdownlint MD047.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/knowledge-01-module-memory-runtime/design.md\",\"side\":\"RIGHT\",\"line\":55}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a single trailing newline at EOF.**\\n\\nThis still trips MD047 lint checks.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 52-52: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md` at line 52, Add a\\nsingle trailing newline at the end of the markdown file that contains the line\\n\\\"- **Sanitized**: false\\\" (the proposal.md for the knowledge-02-module-writeback\\nchange) so the file ends with exactly one newline character; ensure there are no\\nextra blank lines or removal of other content and save the file to satisfy\\nMD047.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/knowledge-02-module-writeback/proposal.md\",\"side\":\"RIGHT\",\"line\":52}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n**Adapter contract at Line 19 drifts from the core review finding schema.**\\n\\nThis proposal defines `id/title/description/location/timestamp/confidence/evidence_refs` and `Critical/High/Medium/Low`, but `openspec/specs/review-finding-model/spec.md` uses `category/severity/tool/rule/file/line/message/fixable` with severity enum `error|warning|info`. Please align this section to the core contract to avoid incompatible payloads.\\n\\n

\\n

Proposed alignment patch

\\n\\n```diff\\n-- **Core Findings Schema Fields**: `id` (stable finding identifier), `title` (human-readable finding title), `description` (detailed explanation), `location` (file path and line range), `timestamp` (ISO 8601 detection time), `severity` (normalized severity level), `confidence` (confidence score 0.0-1.0), `evidence_refs` (list of evidence references)\\n+- **Core Findings Schema Fields**: `category`, `severity`, `tool`, `rule`, `file`, `line`, `message`, `fixable` (as defined in `openspec/specs/review-finding-model/spec.md`)\\n@@\\n-- **Severity Mapping**: Critical (0.9-1.0), High (0.7-0.9), Medium (0.4-0.7), Low (0.0-0.4)\\n-- **Confidence Scoring**: Pattern-based detections (0.8), heuristic detections (0.6), informational notes (0.4)\\n+- **Severity Mapping**: MUST map detections to core enum values `error`, `warning`, or `info`.\\n+- **Confidence Scoring**: If retained, treat as module-internal scoring/evidence metadata and do not replace core `severity` semantics.\\n```\\n

\\n\\n\\n\\nAs per coding guidelines: “openspec/**/*.md: Specification truth … drift vs. shipped modules or docs.”\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` around lines 19 -\\n24, The proposal's \\\"Core Findings Schema Fields\\\" in proposal.md currently uses\\nid/title/description/location/timestamp/confidence/evidence_refs and a severity\\nmapping (Critical/High/Medium/Low), which diverges from the canonical review\\nfinding schema; update the adapter contract in proposal.md to match\\nopenspec/specs/review-finding-model/spec.md by using the canonical fields\\n(category, severity, tool, rule, file, line, message, fixable) and the severity\\nenum values (error|warning|info), and adapt any references to\\nevidence_refs/location to map into file/line and message or add a clear mapping\\nsection showing how id/title/description/timestamp/confidence map to the\\ncanonical fields (e.g., id→rule or tool-specific id, description→message,\\nlocation→file/line), so the payloads remain compatible with the core spec.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit b672278\",\"path\":\"openspec/changes/review-resiliency-01-module/proposal.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a single trailing newline at EOF.**\\n\\nThis avoids MD047 markdownlint failures.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 52-52: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` at line 52, Append\\na single trailing newline to the end of the file so the last line \\\"- **Issue\\nURL**: \\\" is followed\\nby a newline character (ensuring the file ends with exactly one EOF newline) to\\nsatisfy MD047.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/review-resiliency-01-module/proposal.md\",\"side\":\"RIGHT\",\"line\":72}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a trailing newline at EOF (MD047).**\\n\\nMinor markdownlint fix.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 64-64: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md` at line 64,\\nAdd a trailing newline at the end of the markdown file containing the line\\n\\\"Should SBOM generation be mandatory for every security run or enabled only when\\ndependency analysis is requested?\\\" to satisfy MD047; simply ensure the file ends\\nwith a single newline character so the EOF is a blank line.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/security-01-module-sast-sca-secret/design.md\",\"side\":\"RIGHT\",\"line\":64}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add final trailing newline for MD047.**\\n\\nFile should end with exactly one newline.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\\nat line 30, Add a single final trailing newline at the end of the file so it\\nends with exactly one newline; specifically update the file containing the line\\n\\\"- **THEN** the bundle surfaces the failure with the normalized report contract\\nand a non-success command outcome\\\" to ensure there is one and only one newline\\ncharacter after the last line.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md\",\"side\":\"RIGHT\",\"line\":30}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add trailing newline at end of file (MD047).**\\n\\nMinor markdownlint fix.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 27-27: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md` at line 27, Add\\na trailing newline to the end of the file to satisfy markdownlint rule MD047:\\nopen the file containing the line \\\"4.5 Open the modules PR to `dev`, cross-link\\npaired security changes, and call out any deferred scanner providers as\\nfollow-up issues.\\\" (tasks.md) and ensure the file ends with a single newline\\ncharacter, save, and commit the change.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/security-01-module-sast-sca-secret/tasks.md\",\"side\":\"RIGHT\",\"line\":27}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Finalize dependency statement; remove unresolved editorial note.**\\n\\nLine 46 already states the correct dependency direction, but the trailing “if intention was...” instruction reintroduces ambiguity. Convert this to a single definitive dependency statement.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` at line\\n46, Remove the unresolved editorial parenthetical and replace it with a single\\ndefinitive dependency sentence: state that this proposal depends on\\n`security-01-unified-findings-model` and the shared policy-pack semantics from\\n`policy-02-packs-and-modes`, and remove any mention of\\n`security-02-eu-gdpr-baseline` and the “if the intention was…” note so the\\ndependency line references only the final, unambiguous dependency set.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit b672278\",\"path\":\"openspec/changes/security-02-module-license-compliance/proposal.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add EOF trailing newline (MD047).**\\n\\nSmall markdownlint cleanup.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 57-57: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` at line\\n57, The file containing the line \\\"**GitHub Issue**:\\n[`#228`](https://github.com/nold-ai/specfact-cli-modules/issues/228)\\\" fails\\nmarkdownlint MD047 (missing EOF trailing newline); fix it by adding a single\\nnewline character at the end of that markdown file (ensure the file ends with a\\nblank line) so the EOF has a trailing newline and the MD047 warning is resolved.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/security-02-module-license-compliance/proposal.md\",\"side\":\"RIGHT\",\"line\":64}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add final trailing newline for markdownlint compliance.**\\n\\nFile ends without a single trailing newline (MD047).\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\\nat line 30, Add a single trailing newline character to the end of the file to\\nsatisfy markdownlint rule MD047 (i.e., ensure the file ends with a newline after\\nthe last line “**THEN** the bundle reports the finding without converting the\\noverall command outcome into a blocking failure”).\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md\",\"side\":\"RIGHT\",\"line\":30}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Add an explicit paired `specfact-cli` compatibility verification task.**\\n\\nSince this checklist changes shared privacy/GDPR findings/report contracts, add a concrete step to verify paired public artifacts/tests in `nold-ai/specfact-cli` before PR handoff (not just cross-linking). That will reduce adapter-boundary drift across repos.\\n\\n\\nBased on learnings, when a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.\\n\\n\\nAlso applies to: 27-27\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` around lines 17 -\\n18, Add a concrete checklist task to verify compatibility with\\nnold-ai/specfact-cli whenever changing shared privacy/GDPR findings/report\\ncontracts (e.g., alongside items \\\"3.2 Implement normalization...\\\" and \\\"3.3\\nIntegrate shared policy/profile handling...\\\"); specifically, add a step that\\nrequires running and reviewing the paired public artifacts/tests in specfact-cli\\nand confirming any required adapter changes or test updates before PR handoff so\\nthe change consumer (specfact-cli) is validated and noted in the checklist.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit b672278\",\"path\":\"openspec/changes/security-03-module-pii-gdpr-eu/tasks.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Wrap JSON payloads in fenced code blocks for Markdown readability.**\\n\\n`tojson(indent=2)` output is intentional (good), but unfenced JSON is harder to read in rendered Markdown. Consider fencing as `json` for stable display.\\n\\n

\\n

♻️ Suggested refinement

\\n\\n```diff\\n {# Intentional machine-readable JSON embedding for downstream tooling #}\\n-{{ business | tojson(indent=2) }}\\n+```json\\n+{{ business | tojson(indent=2) }}\\n+```\\n@@\\n {# Intentional machine-readable JSON embedding for downstream tooling #}\\n-{{ product | tojson(indent=2) }}\\n+```json\\n+{{ product | tojson(indent=2) }}\\n+```\\n```\\n

\\n\\n\\n\\nAlso applies to: 27-28\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n````\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@packages/specfact-project/resources/templates/persona/default.md.j2` around\\nlines 20 - 21, The JSON output from the Jinja expressions business |\\ntojson(indent=2) and product | tojson(indent=2) is currently emitted raw; wrap\\neach rendered JSON block in Markdown fenced code blocks annotated with json so\\nthe template lines that render {{ business | tojson(indent=2) }} and {{ product\\n| tojson(indent=2) }} become fenced (```json ... ```) to improve readability in\\nrendered Markdown while preserving the existing tojson usage.\\n````\\n\\n

\\n\\n\\n\\n\",\"path\":\"packages/specfact-project/resources/templates/persona/default.md.j2\",\"side\":\"RIGHT\",\"line\":21}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🌐 Web query:\\n\\n`In GitHub GraphQL responses for Issue.subIssues, can `nodes` be null, and are null elements in `nodes` permitted?`\\n\\n💡 Result:\\n\\nIn GitHub's GraphQL API, the Issue.subIssues field exists (confirmed by recent sources referencing it in schema updates and client libraries as of 2025). It returns a connection object with standard pagination fields including nodes: [Issue!]!. The nodes field is a non-null array of non-null Issue objects, so nodes itself cannot be null. Individual elements in nodes cannot be null either, as they are typed Issue! (non-nullable). This follows GitHub's standard Relay-style connection pattern where nodes is [T!]! for object type T, preventing null arrays or null elements. General GraphQL connection behavior supports null nodes for error handling, but GitHub's schema uses non-null for Issue connections (e.g., IssueConnection.nodes: [Issue!]!).\\n\\nCitations:\\n\\n- 1: https://developer.github.com/v4/object/issue/\\n- 2: https://developer.github.com/v4/object/issueconnection/\\n- 3: https://stackoverflow.com/questions/57901668/how-to-understand-null-edges-and-nodes-in-graphql\\n- 4: https://github.com/octokit/octokit.graphql.net/issues/327\\n- 5: https://docs.github.com/enterprise/2.12/developer/v4/object/issueconnection\\n- 6: https://docs.github.com/enterprise/2.14/developer/v4/object/issueconnection\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read the function containing lines 118-121 with surrounding context\\ncat -n scripts/ensure_github_hierarchy_subissues.py | sed -n '100,140p'\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1896\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Look at the broader context and error handling patterns\\ncat -n scripts/ensure_github_hierarchy_subissues.py | head -50\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1738\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Continue reading the _gh_graphql function\\ncat -n scripts/ensure_github_hierarchy_subissues.py | sed -n '42,90p'\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 2394\\n\\n---\\n\\n\\n\\n

\\n\\n**Add type guard for `subIssues.nodes` to ensure deterministic failures.**\\n\\nLine 118-119: `raw_nodes` can be non-list if `nodes` key exists but has unexpected value (e.g., `null` or string). This would raise `TypeError` instead of the controlled `RuntimeError` path used elsewhere in the function. Add type check before iteration to match the defensive pattern used for `issue` (line 113) and `pageInfo` (line 123).\\n\\n

\\n

Suggested fix

\\n\\n```diff\\n raw_nodes = sub.get(\\\"nodes\\\", [])\\n+ if not isinstance(raw_nodes, list):\\n+ raise RuntimeError(f\\\"invalid subIssues.nodes payload for issue #{parent_number}: {raw_nodes!r}\\\")\\n for node in raw_nodes:\\n if isinstance(node, dict) and node.get(\\\"number\\\") is not None:\\n collected.add(int(node[\\\"number\\\"]))\\n```\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@scripts/ensure_github_hierarchy_subissues.py` around lines 118 - 121, The\\ncode iterates raw_nodes = sub.get(\\\"nodes\\\", []) without guarding its type; add a\\ntype check before the loop (similar to the existing guards around issue and\\npageInfo) to ensure raw_nodes is a list and raise a controlled RuntimeError if\\nnot, then proceed to iterate and call collected.add(int(node[\\\"number\\\"])) for\\ndict entries; reference the variables raw_nodes and sub and mirror the error\\nmessaging/behavior used for issue and pageInfo so failures remain deterministic.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit b672278\",\"path\":\"scripts/ensure_github_hierarchy_subissues.py\",\"side\":\"RIGHT\",\"line\":123}{\"type\":\"pull_request_comment\",\"body\":\"**Actionable comments posted: 28**\\n\\n

\\n

♻️ Duplicate comments (9)

\\n\\n
\\n
openspec/changes/security-01-module-sast-sca-secret/design.md (1)
\\n\\n`58-60`: _⚠️ Potential issue_ | _🟠 Major_\\n\\n**Fix contradictory dependency semantics for `policy-02-packs-and-modes`.**\\n\\nLine 58 treats `policy-02-packs-and-modes` as a required core target, while Line 59 says it should be a module-level dependency if shipped separately. Pick one authoritative classification and remove the conflicting path. \\n \\n\\nAs per coding guidelines, “Specification truth: proposal/tasks/spec deltas vs. bundle behavior, CHANGE_ORDER, and drift vs. shipped modules or docs.”\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md` around lines\\n58 - 60, The document currently classifies policy-02-packs-and-modes in two\\nconflicting ways; decide and make one authoritative classification: either\\ndeclare policy-02-packs-and-modes as a required core contract alongside\\nsecurity-01-unified-findings-model (keep it in core_compatibility) or declare it\\nas a module-level bundle dependency (remove it from the core targets list).\\nUpdate the lines referencing security-01-unified-findings-model,\\npolicy-02-packs-and-modes, core_compatibility and bundle dependency so only the\\nchosen path remains and remove the alternate path and any contradictory wording.\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/security-01-module-sast-sca-secret/tasks.md (1)
\\n\\n`4-4`: _⚠️ Potential issue_ | _🟠 Major_\\n\\n**Correct the dependency verification task to distinguish core vs module changes.**\\n\\nLine 4 currently requires both dependencies to be merged in `specfact-cli`, which is inconsistent with the documented module-level treatment of `policy-02-packs-and-modes`. Split this task into: (a) core contract verification, and (b) module bundle dependency verification/manifest semantics. \\n \\n\\nBased on learnings: “When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.”\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md` at line 4,\\nUpdate the task in tasks.md to split the single dependency check into two\\ndistinct checks: (1) a core contract verification that ensures the core change\\nsecurity-01-unified-findings-model is merged in specfact-cli and documents the\\nminimum core_compatibility versions in TDD_EVIDENCE.md, and (2) a module\\nbundle/manifest verification that treats policy-02-packs-and-modes as a\\nmodule-level dependency (verify bundle/manifest semantics and whether it must be\\npresent in the module bundle rather than requiring it to be merged into\\nspecfact-cli); make the wording explicit about which change is a core vs module\\ndependency and include any sequencing notes.\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md (1)
\\n\\n`7-7`: _⚠️ Potential issue_ | _🟠 Major_\\n\\n**Make the requirement deterministic; move dependency-status gating out of normative spec text.**\\n\\nLine 7 currently mixes a hard requirement with an unresolved “confirm status before implementation” note. That makes the spec non-testable and drifts from “spec as source of truth.” Keep the SHALL clause definitive, and move status-tracking/gating language to `proposal.md`/`tasks.md`/`TDD_EVIDENCE.md`. \\n \\n\\nAs per coding guidelines, “Specification truth: proposal/tasks/spec deltas vs. bundle behavior, CHANGE_ORDER, and drift vs. shipped modules or docs.”\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\\nat line 7, The SHALL clause must be definitive: update the spec to state that\\nthe modules repository SHALL provide a signed official bundle named\\n`nold-ai/specfact-license-compliance` that exposes the `license` command and\\ndeclares truthful bundle dependencies, pip dependencies, and a\\n`core_compatibility` entry for `security-01-unified-findings-model` (no\\nconditional language), and remove the “Confirm the core change…before\\nimplementation” note from spec.md; instead add the status-tracking and gating\\ndetails to proposal.md or tasks.md or TDD_EVIDENCE.md so implementation guidance\\n(confirmation of `security-01-unified-findings-model` status and any version\\nrequirement notes) lives outside the normative spec text.\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md (1)
\\n\\n`7-7`: _⚠️ Potential issue_ | _🟠 Major_\\n\\n**Resolve dependency classification now; avoid conditional language in the requirement.**\\n\\nLine 7 keeps `core_compatibility` semantics conditional (“if ... then ...”). This leaves manifest expectations ambiguous and non-verifiable. Decide and encode one source of truth (core contract vs module `bundle_dependencies`) directly in the requirement. \\n \\n\\nBased on learnings: “When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.”\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\\nat line 7, Update the requirement to remove conditional wording and assert a\\nsingle, verifiable dependency classification: state that the modules bundle\\n`nold-ai/specfact-security` MUST list `security-01-unified-findings-model` in\\ncore_compatibility if that contract is accepted by specfact-cli public\\nartifacts, otherwise explicitly require `policy-02-packs-and-modes` (if shipped\\nas a separate module) to be declared under bundle_dependencies; replace the “if\\n… then …” phrasing with a definitive statement referencing `bundle_dependencies`\\nand `core_compatibility` and call out the exposed `security` command and pip\\ndependencies as mandatory manifest entries so the expectation is unambiguous.\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/knowledge-02-module-writeback/proposal.md (1)
\\n\\n`15-21`: _⚠️ Potential issue_ | _🟠 Major_\\n\\n**Writeback interface is still ambiguous on validation and manifest strictness.**\\n\\nAt Line 19–Line 21, the contract names fields but doesn’t define required vs optional fields, destination-validation ownership, or preview-vs-write error semantics. That leaves adapters free to diverge.\\n\\n
\\n
Proposed contract tightening
\\n\\n```diff\\n ### Writeback Interface\\n@@\\n-- **Adapter Method Signature**: Each writeback adapter implements a standard method accepting rule identifiers, destination path, and dry-run flag\\n-- **Manifest Schema Fields**: `ruleIds` (list of rule identifiers), `ruleVersions` (semantic versions or commit hashes), `inputDigest` (hash of source rules), `outputDigest` (hash of generated output), `timestamp` (ISO 8601 generation time), `adapterId` (writeback target type), `destination` (file path or endpoint), `previewHash` (preview content hash for verification), `dryRunFlag` (boolean indicating preview-only mode)\\n+- **Adapter Method Signature**: Each adapter MUST accept `{ruleIds, destination, dryRun}` and return `{previewContent, writebackManifest}`.\\n+- **Destination Validation**: Adapter validates destination format/access; caller validates policy/authorization.\\n+- **Manifest Schema Fields**:\\n+ - **Required**: `ruleIds`, `ruleVersions`, `inputDigest`, `outputDigest`, `timestamp`, `adapterId`, `destination`, `dryRunFlag`\\n+ - **Optional**: `previewHash` (required when `dryRun=true`)\\n+- **Error Semantics**: Preview generation errors MUST fail without side effects; final writeback errors MUST include manifest context for audit.\\n```\\n
\\n\\n \\n\\nAs per coding guidelines: “openspec/**/*.md: Specification truth … drift vs. shipped modules or docs.”\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md` around lines 15 -\\n21, Clarify the writeback manifest by marking which manifest fields are required\\nvs optional (e.g., require ruleIds, adapterId, destination, timestamp,\\ninputDigest/outputDigest for integrity; make ruleVersions, previewHash,\\ndryRunFlag optional) and add concrete validation rules for destination ownership\\nand format (e.g., adapter must validate that destination belongs to the caller\\nor an allowed namespace and reject unauthorized paths), define preview vs write\\nsemantics for dryRunFlag and previewHash (dryRunFlag=true must never mutate\\ndestination and must return a deterministically verifiable previewHash; when\\ndryRunFlag=false adapters must enforce previewHash match before writing), and\\nstate explicit error codes/behaviors (validation errors vs preview-mismatch vs\\nwrite-failure) referencing the manifest field names ruleIds, ruleVersions,\\ninputDigest, outputDigest, timestamp, adapterId, destination, previewHash,\\ndryRunFlag and the \\\"writeback adapter\\\" contract so implementers must follow a\\nsingle strict validation and error model.\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md (1)
\\n\\n`7-7`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Make telemetry prerequisite field canonical, not “or”.**\\n\\nLine 7 still allows two representations (“`core_compatibility` or dependency metadata fields”), which can cause manifest inconsistency and registry/tooling drift. Pick one canonical field (or define strict precedence).\\n\\n \\nAs per coding guidelines, `openspec/**/*.md` must preserve specification truth and avoid contract ambiguity/drift.\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn\\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\\nat line 7, The spec currently allows two representations for the telemetry\\nprerequisite which risks inconsistency; update the sentence so the bundle\\nmanifest MUST list telemetry-01-opentelemetry-default-on in the\\ncore_compatibility field (not “or dependency metadata fields”), e.g. require the\\nnold-ai/specfact-finops bundle that exposes the finops command to explicitly\\ndeclare telemetry-01-opentelemetry-default-on in core_compatibility (or if you\\nprefer alternate behavior, define strict precedence between core_compatibility\\nand dependency metadata fields and document that precedence in\\nopenspec/CHANGE_ORDER.md).\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/architecture-02-module-well-architected/design.md (1)
\\n\\n`5-5`: _⚠️ Potential issue_ | _🟠 Major_\\n\\n**Specify the exact core contract/schema for architecture findings.**\\n\\nLines 5, 13, and 38 reference the \\\"paired core architecture review model\\\" and \\\"paired core report contract\\\" without naming the specific contract or schema. The proposal.md adapter contract (lines 19-22) defines fields like `id`, `type`, `evidence_refs`, but the core `ReviewFinding` model (from `review-finding-model` spec) defines `category`, `tool`, `rule`, `file`, `line`, `message`. This ambiguity creates risk of adapter implementation drift.\\n\\nClarify whether:\\n- Architecture findings populate the existing `ReviewFinding` model (with `category: \\\"architecture\\\"`), or\\n- A separate architecture-specific findings schema is defined in the paired core contract `architecture-02-well-architected-review`\\n\\nUpdate the design to explicitly name the target schema and reference the specific core contract specification.\\n\\n\\n\\nBased on learnings, when a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.\\n\\n\\nAlso applies to: 13-13, 38-38\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\\n5, Update the design to explicitly name and reference the exact core\\ncontract/schema used for architecture findings: state whether the module maps\\ninto the existing ReviewFinding model (from review-finding-model) with category:\\n\\\"architecture\\\" and show the field mapping (e.g., map proposal.md fields id→id,\\ntype→type, evidence_refs→evidence_refs to ReviewFinding fields like id, type,\\nevidence_refs and map category, tool, rule, file, line, message accordingly), or\\ndeclare and link the separate architecture-02-well-architected-review contract\\nif you want a distinct schema; replace all vague references to \\\"paired core\\narchitecture review model\\\" and \\\"paired core report contract\\\" with the exact\\ncontract name and a pointer to the spec so adapter implementers can avoid drift\\n(also update occurrences at lines referenced as 13 and 38).\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/architecture-02-module-well-architected/proposal.md (2)
\\n\\n`10-12`: _🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Consider rewording to reduce repetitive sentence starts.**\\n\\nLines 10-12 begin three consecutive bullets with \\\"**NEW**:\\\", which reduces readability per static analysis (LanguageTool ENGLISH_WORD_REPEAT_BEGINNING_RULE).\\n\\n\\n\\n
\\n
✍️ Proposed rewording
\\n\\n```diff\\n-- **NEW**: Add a `specfact-architecture` bundle with an `architecture` command for boundary, interface, and well-architected review.\\n-- **NEW**: Package analyzers and rule resources for dependency-graph checks, ADR traceability, and interface-diff evaluation.\\n-- **NEW**: Encode the `ALLOWED_IMPORTS.md` pattern into reusable review rules so the modules repo and user repositories can share the same boundary-checking approach.\\n+- **NEW**: Add a `specfact-architecture` bundle with an `architecture` command for boundary, interface, and well-architected review.\\n+- **Package** analyzers and rule resources for dependency-graph checks, ADR traceability, and interface-diff evaluation.\\n+- **Encode** the `ALLOWED_IMPORTS.md` pattern into reusable review rules so the modules repo and user repositories can share the same boundary-checking approach.\\n```\\n
\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` around\\nlines 10 - 12, The three bullets starting with the repeated marker \\\"**NEW**:\\\"\\nhurt readability; revise the three items (the \\\"Package analyzers and rule\\nresources for dependency-graph checks, ADR traceability, and interface-diff\\nevaluation\\\" item, the \\\"Encode the `ALLOWED_IMPORTS.md` pattern into reusable\\nreview rules...\\\" item, and the \\\"Introduce report surfaces that map architecture\\nfindings...\\\" item) to use varied lead-ins (e.g., \\\"Add\\\", \\\"Encode\\\", \\\"Introduce\\\" or\\nsimilar) or rephrase one or two bullets so they don't all begin with the same\\ntoken while preserving meaning and references to ALLOWED_IMPORTS.md and report\\nsurfaces.\\n```\\n\\n
\\n\\n---\\n\\n`40-40`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Use a placeholder version range for core compatibility.**\\n\\nThe `core_compatibility: \\\">=1.0.0 <2.0.0\\\"` specified on line 40 is premature. The paired core contract (`architecture-02-well-architected-review`) has not yet been created in specfact-cli (currently at 0.46.4), and task 1.2 in tasks.md explicitly calls for confirming the paired core change's availability before documenting the required compatibility range. Replace with a placeholder such as:\\n\\n```\\ncore_compatibility: \\\"TBD (set when architecture-02-well-architected-review is available in specfact-cli)\\\"\\n```\\n\\nThis ensures the version range reflects actual core availability rather than speculative targeting of a future release.\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` at line\\n40, Replace the speculative core version in the reserved manifest by changing\\nthe core_compatibility value for the manifest named\\n`architecture-02-well-architected-review` to a placeholder until the paired core\\ncontract exists; specifically, update the `core_compatibility` field (currently\\nset to \\\">=1.0.0 <2.0.0\\\") to a clear placeholder like `TBD (set when\\narchitecture-02-well-architected-review is available in specfact-cli)` so the\\ndocument defers exact versioning until task 1.2 confirms the core contract\\navailability.\\n```\\n\\n
\\n\\n
\\n\\n

\\n\\n

\\n

🤖 Prompt for all review comments with AI agents

\\n\\n````\\nVerify each finding against the current code and only fix it if needed.\\n\\nInline comments:\\nIn `@docs/bundles/project/import-migration.md`:\\n- Line 272: Add a final trailing newline to the markdown file by ensuring the\\nlast line containing \\\"**Happy importing!** 🚀\\\" ends with a newline character;\\nsimply append a newline after that line so the file ends with a blank line to\\nsatisfy MD047.\\n- Around line 39-40: Update the doc text that currently lists thresholds\\n(>10,000 ignored entries, ~100,000 files, ~10 GB, >100,000 commits) to match the\\nimplementation: state the heavy ignored-entry threshold is 500 entries and the\\nlarge-repo file threshold is 1,000 files, and remove references to GB or\\ncommit-count thresholds (or replace the fixed values with a note that the system\\nuses configured thresholds) so the sentence about remaining-time estimates\\nrefers to repositories above those actual/configured thresholds; update the\\nphrases that mention \\\"ignored artifact trees\\\" and \\\"Remaining time is based\\non...\\\" to reflect the corrected thresholds or that such limits are configurable.\\n\\nIn `@openspec/CHANGE_ORDER.md`:\\n- Line 129: The file's last line (the table row containing \\\"| peer-deps | 01 | ✅\\nmodule-bundle-deps-auto-install (archived 2026-04-05) |\\n[`#135`](https://github.com/nold-ai/specfact-cli-modules/issues/135) | — |\\\") is\\nmissing a terminating newline which triggers MD047; add a single trailing\\nnewline character at the end of CHANGE_ORDER.md so the file ends with a newline\\nand re-run markdownlint to confirm the warning is cleared.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\\n- Line 50: The document references a required core contract\\narchitecture-02-well-architected-review that is not present in specfact-cli; to\\nfix, block merging of this design until that core change is created and synced\\nin specfact-cli or explicitly add a dependency/blocker statement in this file\\nnoting that module integration and any references to\\narchitecture-02-well-architected-review (and overlaps with\\narchitecture-01-solution-layer) are disallowed until the paired specfact-cli\\nchange exists and is marked stable; update design.md to include a clear\\ndependency checklist and a gating sentence that prevents implementation work\\nuntil specfact-cli contains the architecture-02-well-architected-review\\nartifact.\\n- Line 57: The file ends without a trailing newline which violates markdownlint\\nMD047; open the file containing the line \\\"Should interface diff support start\\nwith one ecosystem or ship as a provider abstraction from the first\\nimplementation?\\\" (design.md) and add a single newline character at the end of\\nthe file so it ends with exactly one trailing newline.\\n- Around line 1-57: Ensure the paired core change\\n\\\"architecture-02-well-architected-review\\\" exists and is synced into specfact-cli\\nbefore merging this module design: verify the core change defines the\\nfindings/report contract referenced by packages/specfact-architecture, confirm\\nthe module-to-core binding points (adapter contracts and report schema used by\\nthe analyzer adapters and rule-resource translation) are finalized and tested\\nagainst specfact-cli, update CHANGE_ORDER (order-03) and the Migration Plan to\\nreflect actual core availability and registry timeline, and block or defer\\nmerging of the architecture-02 module design until those confirmations/pass CI\\ntests are completed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md`:\\n- Line 54: The file ends without a trailing newline (see the line containing\\n\\\"**Sanitized**: false\\\" in proposal.md); add a single newline character at the\\nend of the file so the file terminates with exactly one trailing newline to\\nsatisfy markdownlint MD047.\\n- Around line 15-22: Update the \\\"Adapter Contract\\\" section so it maps analyzer\\noutputs to the core ReviewFinding model instead of a custom schema: replace the\\n\\\"Required Core Findings Schema Fields\\\" and \\\"Analyzer Output Mapping\\\"\\ndescriptions with mapping to ReviewFinding fields — set category=\\\"architecture\\\",\\ntool=, rule=, file=, line=, message=, and\\nseverity=; retain evidence_refs only as supplemental\\nreferences but ensure primary location data uses file/line; align wording with\\nthe ReviewFinding spec and mention pylint-runner expectation that category must\\nbe \\\"architecture\\\" and tool \\\"pylint\\\".\\n\\nIn `@openspec/changes/codebase-import-runtime-hardening/design.md`:\\n- Line 93: Add a terminal newline to the end of the document so the final line\\n\\\"None for implementation start; warning thresholds can be tuned in-code if test\\nevidence shows the initial defaults are too noisy.\\\" ends with a newline (satisfy\\nmarkdownlint MD047); simply ensure the file's EOF contains a trailing newline\\ncharacter.\\n\\nIn\\n`@openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`:\\n- Line 19: The file ends without a trailing newline causing MD047; append a\\nsingle final newline character to the end of the spec so the last line \\\"**AND**\\nthe failure message SHALL name the missing template path so the packaging defect\\ncan be corrected before publish\\\" is terminated by a newline (i.e., ensure the\\nfile ends with one newline character).\\n\\nIn\\n`@openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`:\\n- Line 57: The file ends without a trailing newline on the final line containing\\n\\\"- **AND** any early estimate before full discovery SHALL be labeled as\\nprovisional rather than a fixed promise\\\"; open the file and add a single newline\\ncharacter (EOF newline) after that line so the document ends with a trailing\\nnewline to satisfy MD047.\\n\\nIn `@openspec/changes/codebase-import-runtime-hardening/tasks.md`:\\n- Line 32: Add a single trailing newline at the end of\\nopenspec/changes/codebase-import-runtime-hardening/tasks.md so the final line \\\"-\\n[ ] 5.4 Commit, push, and open or update the PR to `dev` after verification is\\ngreen.\\\" is followed by one newline (fixes MD047); simply ensure the file ends\\nwith a single blank line.\\n\\nIn `@openspec/changes/enterprise-02-module-audit-client/design.md`:\\n- Around line 1-57: The file ending after the \\\"## Open Questions\\\" section (look\\nfor the top-level heading \\\"# Design\\\" or the \\\"## Context\\\" / \\\"## Open Questions\\\"\\nmarkers) is missing a trailing newline; to fix, open the markdown file for\\nwriting and append a single newline character at the end of the file so the last\\nline (after \\\"How should retry cadence and dead-letter behavior be surfaced in\\nthe first client contract?\\\") ends with a newline to satisfy MD047.\\n\\nIn\\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`:\\n- Line 30: Append a single trailing newline to the end of the markdown file so\\nthe final line \\\"**THEN** it records the session outcome as `rule-updated` in the\\nnormalized FinOps evidence\\\" ends with a newline (fixing MD047); ensure no other\\nwhitespace changes are made.\\n\\nIn `@openspec/changes/finops-01-module-cost-outcome/tasks.md`:\\n- Line 27: The file ends without a trailing newline causing MD047; add a single\\ntrailing newline to the end of the file so the final checklist line \\\"- [ ] 4.5\\nOpen the modules PR to `dev`, cross-link paired telemetry/FinOps changes, and\\nnote any deferred provider integrations as follow-up issues.\\\" is terminated by a\\nnewline character (ensure only one final newline).\\n\\nIn `@openspec/changes/knowledge-01-module-memory-runtime/design.md`:\\n- Line 55: Add a trailing newline at the end of the file by ensuring the final\\nline \\\"- Should search support only tags and keywords initially, or also\\nrelationship traversal commands?\\\" is followed by a single newline character\\n(i.e., ensure EOF ends with a newline) to satisfy markdownlint MD047.\\n\\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md`:\\n- Line 52: Add a single trailing newline at the end of the markdown file that\\ncontains the line \\\"- **Sanitized**: false\\\" (the proposal.md for the\\nknowledge-02-module-writeback change) so the file ends with exactly one newline\\ncharacter; ensure there are no extra blank lines or removal of other content and\\nsave the file to satisfy MD047.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md`:\\n- Line 52: Append a single trailing newline to the end of the file so the last\\nline \\\"- **Issue URL**:\\n\\\" is followed by a\\nnewline character (ensuring the file ends with exactly one EOF newline) to\\nsatisfy MD047.\\n- Around line 19-24: The proposal's \\\"Core Findings Schema Fields\\\" in proposal.md\\ncurrently uses id/title/description/location/timestamp/confidence/evidence_refs\\nand a severity mapping (Critical/High/Medium/Low), which diverges from the\\ncanonical review finding schema; update the adapter contract in proposal.md to\\nmatch openspec/specs/review-finding-model/spec.md by using the canonical fields\\n(category, severity, tool, rule, file, line, message, fixable) and the severity\\nenum values (error|warning|info), and adapt any references to\\nevidence_refs/location to map into file/line and message or add a clear mapping\\nsection showing how id/title/description/timestamp/confidence map to the\\ncanonical fields (e.g., id→rule or tool-specific id, description→message,\\nlocation→file/line), so the payloads remain compatible with the core spec.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md`:\\n- Line 64: Add a trailing newline at the end of the markdown file containing the\\nline \\\"Should SBOM generation be mandatory for every security run or enabled only\\nwhen dependency analysis is requested?\\\" to satisfy MD047; simply ensure the file\\nends with a single newline character so the EOF is a blank line.\\n\\nIn\\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`:\\n- Line 30: Add a single final trailing newline at the end of the file so it ends\\nwith exactly one newline; specifically update the file containing the line \\\"-\\n**THEN** the bundle surfaces the failure with the normalized report contract and\\na non-success command outcome\\\" to ensure there is one and only one newline\\ncharacter after the last line.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md`:\\n- Line 27: Add a trailing newline to the end of the file to satisfy markdownlint\\nrule MD047: open the file containing the line \\\"4.5 Open the modules PR to `dev`,\\ncross-link paired security changes, and call out any deferred scanner providers\\nas follow-up issues.\\\" (tasks.md) and ensure the file ends with a single newline\\ncharacter, save, and commit the change.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md`:\\n- Line 46: Remove the unresolved editorial parenthetical and replace it with a\\nsingle definitive dependency sentence: state that this proposal depends on\\n`security-01-unified-findings-model` and the shared policy-pack semantics from\\n`policy-02-packs-and-modes`, and remove any mention of\\n`security-02-eu-gdpr-baseline` and the “if the intention was…” note so the\\ndependency line references only the final, unambiguous dependency set.\\n- Line 57: The file containing the line \\\"**GitHub Issue**:\\n[`#228`](https://github.com/nold-ai/specfact-cli-modules/issues/228)\\\" fails\\nmarkdownlint MD047 (missing EOF trailing newline); fix it by adding a single\\nnewline character at the end of that markdown file (ensure the file ends with a\\nblank line) so the EOF has a trailing newline and the MD047 warning is resolved.\\n\\nIn\\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`:\\n- Line 30: Add a single trailing newline character to the end of the file to\\nsatisfy markdownlint rule MD047 (i.e., ensure the file ends with a newline after\\nthe last line “**THEN** the bundle reports the finding without converting the\\noverall command outcome into a blocking failure”).\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`:\\n- Around line 17-18: Add a concrete checklist task to verify compatibility with\\nnold-ai/specfact-cli whenever changing shared privacy/GDPR findings/report\\ncontracts (e.g., alongside items \\\"3.2 Implement normalization...\\\" and \\\"3.3\\nIntegrate shared policy/profile handling...\\\"); specifically, add a step that\\nrequires running and reviewing the paired public artifacts/tests in specfact-cli\\nand confirming any required adapter changes or test updates before PR handoff so\\nthe change consumer (specfact-cli) is validated and noted in the checklist.\\n\\nIn `@packages/specfact-project/resources/templates/persona/default.md.j2`:\\n- Around line 20-21: The JSON output from the Jinja expressions business |\\ntojson(indent=2) and product | tojson(indent=2) is currently emitted raw; wrap\\neach rendered JSON block in Markdown fenced code blocks annotated with json so\\nthe template lines that render {{ business | tojson(indent=2) }} and {{ product\\n| tojson(indent=2) }} become fenced (```json ... ```) to improve readability in\\nrendered Markdown while preserving the existing tojson usage.\\n\\nIn `@scripts/ensure_github_hierarchy_subissues.py`:\\n- Around line 118-121: The code iterates raw_nodes = sub.get(\\\"nodes\\\", [])\\nwithout guarding its type; add a type check before the loop (similar to the\\nexisting guards around issue and pageInfo) to ensure raw_nodes is a list and\\nraise a controlled RuntimeError if not, then proceed to iterate and call\\ncollected.add(int(node[\\\"number\\\"])) for dict entries; reference the variables\\nraw_nodes and sub and mirror the error messaging/behavior used for issue and\\npageInfo so failures remain deterministic.\\n\\n---\\n\\nDuplicate comments:\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\\n- Line 5: Update the design to explicitly name and reference the exact core\\ncontract/schema used for architecture findings: state whether the module maps\\ninto the existing ReviewFinding model (from review-finding-model) with category:\\n\\\"architecture\\\" and show the field mapping (e.g., map proposal.md fields id→id,\\ntype→type, evidence_refs→evidence_refs to ReviewFinding fields like id, type,\\nevidence_refs and map category, tool, rule, file, line, message accordingly), or\\ndeclare and link the separate architecture-02-well-architected-review contract\\nif you want a distinct schema; replace all vague references to \\\"paired core\\narchitecture review model\\\" and \\\"paired core report contract\\\" with the exact\\ncontract name and a pointer to the spec so adapter implementers can avoid drift\\n(also update occurrences at lines referenced as 13 and 38).\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md`:\\n- Around line 10-12: The three bullets starting with the repeated marker\\n\\\"**NEW**:\\\" hurt readability; revise the three items (the \\\"Package analyzers and\\nrule resources for dependency-graph checks, ADR traceability, and interface-diff\\nevaluation\\\" item, the \\\"Encode the `ALLOWED_IMPORTS.md` pattern into reusable\\nreview rules...\\\" item, and the \\\"Introduce report surfaces that map architecture\\nfindings...\\\" item) to use varied lead-ins (e.g., \\\"Add\\\", \\\"Encode\\\", \\\"Introduce\\\" or\\nsimilar) or rephrase one or two bullets so they don't all begin with the same\\ntoken while preserving meaning and references to ALLOWED_IMPORTS.md and report\\nsurfaces.\\n- Line 40: Replace the speculative core version in the reserved manifest by\\nchanging the core_compatibility value for the manifest named\\n`architecture-02-well-architected-review` to a placeholder until the paired core\\ncontract exists; specifically, update the `core_compatibility` field (currently\\nset to \\\">=1.0.0 <2.0.0\\\") to a clear placeholder like `TBD (set when\\narchitecture-02-well-architected-review is available in specfact-cli)` so the\\ndocument defers exact versioning until task 1.2 confirms the core contract\\navailability.\\n\\nIn\\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`:\\n- Line 7: The spec currently allows two representations for the telemetry\\nprerequisite which risks inconsistency; update the sentence so the bundle\\nmanifest MUST list telemetry-01-opentelemetry-default-on in the\\ncore_compatibility field (not “or dependency metadata fields”), e.g. require the\\nnold-ai/specfact-finops bundle that exposes the finops command to explicitly\\ndeclare telemetry-01-opentelemetry-default-on in core_compatibility (or if you\\nprefer alternate behavior, define strict precedence between core_compatibility\\nand dependency metadata fields and document that precedence in\\nopenspec/CHANGE_ORDER.md).\\n\\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md`:\\n- Around line 15-21: Clarify the writeback manifest by marking which manifest\\nfields are required vs optional (e.g., require ruleIds, adapterId, destination,\\ntimestamp, inputDigest/outputDigest for integrity; make ruleVersions,\\npreviewHash, dryRunFlag optional) and add concrete validation rules for\\ndestination ownership and format (e.g., adapter must validate that destination\\nbelongs to the caller or an allowed namespace and reject unauthorized paths),\\ndefine preview vs write semantics for dryRunFlag and previewHash\\n(dryRunFlag=true must never mutate destination and must return a\\ndeterministically verifiable previewHash; when dryRunFlag=false adapters must\\nenforce previewHash match before writing), and state explicit error\\ncodes/behaviors (validation errors vs preview-mismatch vs write-failure)\\nreferencing the manifest field names ruleIds, ruleVersions, inputDigest,\\noutputDigest, timestamp, adapterId, destination, previewHash, dryRunFlag and the\\n\\\"writeback adapter\\\" contract so implementers must follow a single strict\\nvalidation and error model.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md`:\\n- Around line 58-60: The document currently classifies policy-02-packs-and-modes\\nin two conflicting ways; decide and make one authoritative classification:\\neither declare policy-02-packs-and-modes as a required core contract alongside\\nsecurity-01-unified-findings-model (keep it in core_compatibility) or declare it\\nas a module-level bundle dependency (remove it from the core targets list).\\nUpdate the lines referencing security-01-unified-findings-model,\\npolicy-02-packs-and-modes, core_compatibility and bundle dependency so only the\\nchosen path remains and remove the alternate path and any contradictory wording.\\n\\nIn\\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`:\\n- Line 7: Update the requirement to remove conditional wording and assert a\\nsingle, verifiable dependency classification: state that the modules bundle\\n`nold-ai/specfact-security` MUST list `security-01-unified-findings-model` in\\ncore_compatibility if that contract is accepted by specfact-cli public\\nartifacts, otherwise explicitly require `policy-02-packs-and-modes` (if shipped\\nas a separate module) to be declared under bundle_dependencies; replace the “if\\n… then …” phrasing with a definitive statement referencing `bundle_dependencies`\\nand `core_compatibility` and call out the exposed `security` command and pip\\ndependencies as mandatory manifest entries so the expectation is unambiguous.\\n\\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md`:\\n- Line 4: Update the task in tasks.md to split the single dependency check into\\ntwo distinct checks: (1) a core contract verification that ensures the core\\nchange security-01-unified-findings-model is merged in specfact-cli and\\ndocuments the minimum core_compatibility versions in TDD_EVIDENCE.md, and (2) a\\nmodule bundle/manifest verification that treats policy-02-packs-and-modes as a\\nmodule-level dependency (verify bundle/manifest semantics and whether it must be\\npresent in the module bundle rather than requiring it to be merged into\\nspecfact-cli); make the wording explicit about which change is a core vs module\\ndependency and include any sequencing notes.\\n\\nIn\\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`:\\n- Line 7: The SHALL clause must be definitive: update the spec to state that the\\nmodules repository SHALL provide a signed official bundle named\\n`nold-ai/specfact-license-compliance` that exposes the `license` command and\\ndeclares truthful bundle dependencies, pip dependencies, and a\\n`core_compatibility` entry for `security-01-unified-findings-model` (no\\nconditional language), and remove the “Confirm the core change…before\\nimplementation” note from spec.md; instead add the status-tracking and gating\\ndetails to proposal.md or tasks.md or TDD_EVIDENCE.md so implementation guidance\\n(confirmation of `security-01-unified-findings-model` status and any version\\nrequirement notes) lives outside the normative spec text.\\n````\\n\\n

\\n\\n

\\n

🪄 Autofix (Beta)

\\n\\n✅ Autofix completed\\n\\n

\\n\\n---\\n\\n

\\n

ℹ️ Review info

\\n\\n

\\n

⚙️ Run configuration

\\n\\n**Configuration used**: Path: .coderabbit.yaml\\n\\n**Review profile**: ASSERTIVE\\n\\n**Plan**: Pro\\n\\n**Run ID**: `9129b38b-0edd-4884-af86-01886b808973`\\n\\n

\\n\\n

\\n

📥 Commits

\\n\\nReviewing files that changed from the base of the PR and between 39750733a68cd1ac8b652b1c46abcc51d84aff60 and 0672f50fc279db70e7351ed9079417d641efe976.\\n\\n

\\n\\n

\\n

📒 Files selected for processing (29)

\\n\\n* `docs/bundles/project/import-migration.md`\\n* `openspec/CHANGE_ORDER.md`\\n* `openspec/changes/architecture-02-module-well-architected/design.md`\\n* `openspec/changes/architecture-02-module-well-architected/proposal.md`\\n* `openspec/changes/codebase-import-runtime-hardening/design.md`\\n* `openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\\n* `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n* `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n* `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\\n* `openspec/changes/enterprise-02-module-audit-client/design.md`\\n* `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\\n* `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\\n* `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n* `openspec/changes/knowledge-01-module-memory-runtime/design.md`\\n* `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\\n* `openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\\n* `openspec/changes/knowledge-02-module-writeback/design.md`\\n* `openspec/changes/knowledge-02-module-writeback/proposal.md`\\n* `openspec/changes/review-resiliency-01-module/proposal.md`\\n* `openspec/changes/security-01-module-sast-sca-secret/design.md`\\n* `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\\n* `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n* `openspec/changes/security-02-module-license-compliance/design.md`\\n* `openspec/changes/security-02-module-license-compliance/proposal.md`\\n* `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\\n* `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n* `packages/specfact-project/resources/templates/persona/default.md.j2`\\n* `scripts/ensure_github_hierarchy_subissues.py`\\n* `tests/unit/workflows/test_sign_modules_on_approval.py`\\n\\n

\\n\\n

\\n

📜 Review details

\\n\\n

\\n

🧰 Additional context used

\\n\\n

\\n

📓 Path-based instructions (5)

\\n\\n

\\n

openspec/**/*.md

\\n\\n\\n**⚙️ CodeRabbit configuration file**\\n\\n> `openspec/**/*.md`: Specification truth: proposal/tasks/spec deltas vs. bundle behavior, CHANGE_ORDER, and\\n> drift vs. shipped modules or docs.\\n> \\n\\nFiles:\\n- `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\\n- `openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\\n- `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\\n- `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\\n- `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\\n- `openspec/changes/knowledge-01-module-memory-runtime/design.md`\\n- `openspec/changes/enterprise-02-module-audit-client/design.md`\\n- `openspec/changes/knowledge-02-module-writeback/design.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/design.md`\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n- `openspec/changes/codebase-import-runtime-hardening/design.md`\\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\\n- `openspec/changes/security-02-module-license-compliance/design.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n- `openspec/changes/security-02-module-license-compliance/proposal.md`\\n- `openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\\n- `openspec/changes/knowledge-02-module-writeback/proposal.md`\\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n- `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n- `openspec/CHANGE_ORDER.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

**/*.{js,ts,tsx,jsx,py,java,cs,go,rb,php,cpp,c,h}

\\n\\n\\n**📄 CodeRabbit inference engine (CLAUDE.md)**\\n\\n> Preserve the clean-code compliance gate and its category references (naming, kiss, yagni, dry, and solid)\\n\\nFiles:\\n- `tests/unit/workflows/test_sign_modules_on_approval.py`\\n- `scripts/ensure_github_hierarchy_subissues.py`\\n\\n

\\n

tests/**/*.py

\\n\\n\\n**⚙️ CodeRabbit configuration file**\\n\\n> `tests/**/*.py`: Contract-first and integration tests: migration suites, bundle validation, and flakiness.\\n> Ensure changes to adapters or bridges have targeted coverage.\\n> \\n\\nFiles:\\n- `tests/unit/workflows/test_sign_modules_on_approval.py`\\n\\n

\\n

docs/**/*.md

\\n\\n\\n**⚙️ CodeRabbit configuration file**\\n\\n> `docs/**/*.md`: User-facing and cross-site accuracy: Jekyll front matter, links per documentation-url-contract,\\n> CLI examples matching bundled commands.\\n> \\n\\nFiles:\\n- `docs/bundles/project/import-migration.md`\\n\\n

\\n

scripts/**/*.py

\\n\\n\\n**⚙️ CodeRabbit configuration file**\\n\\n> `scripts/**/*.py`: Deterministic tooling: signing, publishing, docs generation; subprocess and path safety.\\n> \\n\\nFiles:\\n- `scripts/ensure_github_hierarchy_subissues.py`\\n\\n

\\n\\n

\\n

🧠 Learnings (14)

\\n\\n

\\n

📓 Common learnings

\\n\\n```\\nLearnt from: djm81\\nRepo: nold-ai/specfact-cli-modules PR: 136\\nFile: registry/modules/specfact-spec-0.40.17.tar.gz.sha256:1-1\\nTimestamp: 2026-04-02T21:49:11.371Z\\nLearning: In nold-ai/specfact-cli-modules, module tarball signatures (registry/signatures/*.tar.sig) are generated by the `publish-modules` GitHub Actions runner during the publish workflow, not committed locally to the branch. Missing signature files should NOT be flagged as a pre-merge blocker in PRs.\\n```\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Enforce module signatures and version bumps when signed module assets or manifests are affected\\n```\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: CLAUDE.md:0-0\\nTimestamp: 2026-04-13T10:38:29.399Z\\nLearning: When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\\n```\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:15.855Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .cursorrules:0-0\\nTimestamp: 2026-04-13T10:38:15.855Z\\nLearning: Adhere to worktree policy, OpenSpec gating, GitHub hierarchy-cache refresh, TDD order, quality gates, versioning, and documentation rules as defined in `docs/agent-rules/`\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:29.399Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: CLAUDE.md:0-0\\nTimestamp: 2026-04-13T10:38:29.399Z\\nLearning: When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\\n- `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\\n- `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\\n- `openspec/changes/knowledge-01-module-memory-runtime/design.md`\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n- `tests/unit/workflows/test_sign_modules_on_approval.py`\\n- `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n- `openspec/changes/knowledge-02-module-writeback/proposal.md`\\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n- `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n- `openspec/CHANGE_ORDER.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: Signed module or manifest changes require version-bump review and verify-modules-signature\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n- `openspec/CHANGE_ORDER.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Fix SpecFact code review findings, including warnings, unless a rare explicit exception is documented\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n\\n

\\n

📚 Learning: 2026-04-02T21:49:11.371Z

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Enforce module signatures and version bumps when signed module assets or manifests are affected\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Perform `spec -> tests -> failing evidence -> code -> passing evidence` in that order for behavior changes\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: Work belongs on feature/*, bugfix/*, hotfix/*, or chore/* branches, normally in a worktree rooted under ../specfact-cli-modules-worktrees/\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n- `openspec/CHANGE_ORDER.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: This repository enforces the clean-code review gate through hatch run specfact code review run --json --out .specfact/code-review.json\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Read docs/agent-rules/05-non-negotiable-checklist.md before implementation\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: Refresh .specfact/backlog/github_hierarchy_cache.md with python scripts/sync_github_hierarchy_cache.py when GitHub hierarchy metadata is missing or stale before parent or blocker work\\n```\\n\\n**Applied to files:**\\n- `scripts/ensure_github_hierarchy_subissues.py`\\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: If GitHub hierarchy metadata is needed and `.specfact/backlog/github_hierarchy_cache.md` is missing or stale, refresh it with `python scripts/sync_github_hierarchy_cache.py`\\n```\\n\\n**Applied to files:**\\n- `scripts/ensure_github_hierarchy_subissues.py`\\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:29.399Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: CLAUDE.md:0-0\\nTimestamp: 2026-04-13T10:38:29.399Z\\nLearning: Treat canonical rule docs (docs/agent-rules/INDEX.md) as the source of truth for worktree policy, OpenSpec gating, GitHub completeness checks, TDD order, quality gates, versioning, and documentation rules\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\\n\\n

\\n\\n

\\n

🪛 LanguageTool

\\n\\n

\\n

openspec/changes/architecture-02-module-well-architected/proposal.md

\\n

openspec/changes/review-resiliency-01-module/proposal.md

\\n

openspec/changes/security-02-module-license-compliance/proposal.md

\\n\\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ...re security/license findings model. - **NEW**: Add policy-aware handling for allowe...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n---\\n\\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\\nContext: ...face explicit remediation guidance. - **NEW**: Define bundle manifest, registry, do...\\n\\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\\n\\n

\\n

openspec/changes/knowledge-02-module-writeback/proposal.md

\\n

openspec/changes/codebase-import-runtime-hardening/tasks.md

\\n\\n[uncategorized] ~5-~5: The official name of this software platform is spelled with a capital “H”.\\nContext: ...nd change scaffolding - [ ] 1.1 Verify `.specfact/backlog/github_hierarchy_cache.md` is fresh, confirm t...\\n\\n(GITHUB)\\n\\n

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n

\\n

openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md

\\n\\n[warning] 19-19: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/architecture-02-module-well-architected/proposal.md

\\n\\n[warning] 54-54: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/knowledge-01-module-memory-runtime/design.md

\\n\\n[warning] 55-55: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/enterprise-02-module-audit-client/design.md

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/security-01-module-sast-sca-secret/design.md

\\n\\n[warning] 64-64: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/architecture-02-module-well-architected/design.md

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/review-resiliency-01-module/proposal.md

\\n\\n[warning] 52-52: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/codebase-import-runtime-hardening/design.md

\\n\\n[warning] 93-93: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/finops-01-module-cost-outcome/tasks.md

\\n\\n[warning] 27-27: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

docs/bundles/project/import-migration.md

\\n\\n[warning] 272-272: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/security-01-module-sast-sca-secret/tasks.md

\\n\\n[warning] 27-27: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/security-02-module-license-compliance/proposal.md

\\n\\n[warning] 57-57: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/knowledge-02-module-writeback/proposal.md

\\n\\n[warning] 52-52: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/codebase-import-runtime-hardening/tasks.md

\\n\\n[warning] 32-32: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md

\\n\\n[warning] 27-27: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md

\\n\\n[warning] 57-57: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/CHANGE_ORDER.md

\\n\\n[warning] 129-129: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🔀 Multi-repo context nold-ai/specfact-cli

\\n\\n## Linked repositories findings\\n\\n### nold-ai/specfact-cli\\n\\n- init template resolver usage:\\n - src/specfact_cli/modules/init/src/commands.py:271 — defines `_resolve_templates_dir(repo_path: Path) -> Path | None`. This is a consumer of bundled template-resolution behavior. [::nold-ai/specfact-cli::]\\n\\n- Tests asserting template resolution behavior:\\n - tests/unit/specfact_cli/registry/test_init_module_lifecycle_ux.py:125–133 — test `test_resolve_templates_dir_none_when_no_discoverable_prompts` calls `init_commands._resolve_templates_dir(tmp_path)` and asserts behavior when no discoverable templates exist. This will exercise any change to template resolution defaults/lookup. [::nold-ai/specfact-cli::]\\n\\nSummary judgement:\\n- The repository contains direct consumers/tests of template resolution logic (resolve_templates_dir behavior) that are relevant to the promoted changes around template packaging and resolver helpers. No other references to the new import/runtime patching APIs (import_path_policy, import_runtime_patches, apply_import_runtime_patches, discover_code_files) were found in this repo. [::nold-ai/specfact-cli::]\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` around\\nlines 30 - 35, Decision 2's portable-rule proposal risks losing enforcement\\nfidelity from ALLOWED_IMPORTS.md; update the portable rule schema and\\nenforcement code so it preserves all three policy dimensions: (1) dual-mode\\nprefix matching implemented by preserving the _is_allowed_prefix semantics (add\\na flag/field for exact+dot-prefix matching and ensure the rule parser and\\nmatcher honor it), (2) a MIGRATE-tier blocking marker or enforcement-level field\\nthat causes unconditional forbids for non-allowed imports in that tier, and (3)\\ndirectional cross-bundle allowlists (explicit source→target allow entries) so\\nthe bundle isolation rules are expressible; modify the rule parser/loader,\\nmatcher (where _is_allowed_prefix is referenced), and enforcement engine to read\\nthese fields and enforce them deterministically as described in Decision 2.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/architecture-02-module-well-architected/design.md\",\"side\":\"RIGHT\",\"line\":48}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Verify architecture-02-well-architected-review existence in specfact-cli\\nrg -n --type=md 'architecture-02-well-architected-review' || echo \\\"Core change not found in specfact-cli\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 2359\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for the paired core change in specfact-cli\\nrg -n 'architecture-02-well-architected-review' --type=md --type=py --type=yaml --type=toml 2>/dev/null || echo \\\"No matches found in specfact-cli\\\"\\n\\n# Also check for issue/change files\\nfind . -type f \\\$ -name \\\"*architecture*\\\" -o -name \\\"*well-architected*\\\" \\\$ | head -20\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 154\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check CHANGE_ORDER.md for sequencing rules and blocker logic\\ncat -n openspec/CHANGE_ORDER.md | sed -n '80,110p'\\n\\n# Also search for any notes on when design docs can be merged vs blockers\\nrg -A5 -B5 'BLOCKER|blockers|specification draft|design.*merge' openspec/CHANGE_ORDER.md || echo \\\"No blocker guidance in CHANGE_ORDER\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 10368\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if there's established pattern of design docs merged before blockers in this repo\\n# Look for other examples in openspec/changes/\\nfind openspec/changes -name \\\"design.md\\\" -type f | head -5 | while read f; do\\n echo \\\"=== $f ===\\\"\\n grep -c \\\"BLOCKER\\\" \\\"$f\\\" 2>/dev/null || echo \\\"0\\\"\\ndone\\n\\n# Check if there's meta-guidance on design vs implementation merge sequencing\\nrg -l \\\"design.*merge|implementation.*blocker|specification.*freeze\\\" openspec/ || echo \\\"No guidance found\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1160\\n\\n---\\n\\n\\n\\n

\\n\\n**Core change `architecture-02-well-architected-review` does not exist in specfact-cli; design doc BLOCKER section gates implementation, not design merge.**\\n\\nThe design document's BLOCKER section (lines 56–61) explicitly gates \\\"module integration and any references,\\\" not the design document itself. However, shipping a specification with unmet, unchecked blockers creates ambiguity about the intended sequencing. The paired core change is confirmed absent from specfact-cli.\\n\\nConsider either:\\n- Deferring design merge until the core contract exists and blocker checkboxes can be verified, or\\n- Adding a meta-note in the design clarifying that design-phase artifacts may be merged before implementation blockers are satisfied, with implementation PRs responsible for verifying the dependency checklist\\n\\nPer the adapter-boundary focus on registry, module-package.yaml, and core contracts: the undefined core architecture review contract (`architecture-02-well-architected-review`) is a cross-repo impact risk that should be resolved before implementation PRs reference or depend on it.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` around\\nlines 50 - 61, The BLOCKER currently named \\\"Module integration and any\\nreferences to `architecture-02-well-architected-review` are disallowed...\\\" is\\ngating the design merge even though the paired core contract in `specfact-cli`\\ndoesn't exist; either remove or relax that gate and add a clear meta-note: state\\nthat this design can merge as a design artifact but that implementation PRs must\\nverify the dependency checklist (presence of\\n`architecture-02-well-architected-review` in `specfact-cli`, documented overlaps\\nwith `architecture-01-solution-layer`, and a stable paired core change) before\\nany module integration or references are added; update the checklist text and\\nBLOCKER heading to reflect \\\"Implementation BLOCKER\\\" and reference the exact\\ncontract name `architecture-02-well-architected-review` and repo `specfact-cli`\\nso reviewers know the required precondition without blocking the design doc\\nitself.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 02b723f\",\"path\":\"openspec/changes/architecture-02-module-well-architected/design.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Verify ReviewFinding model fields in current implementation\\nrg -n -A 20 'class ReviewFinding' --type=py | grep -E 'evidence_refs|Field\\\\(' | head -30\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 664\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Get the complete ReviewFinding class definition\\nsed -n '34,80p' packages/specfact-code-review/src/specfact_code_review/run/findings.py\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 2048\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Get the exact lines 30-33 from the proposal\\nsed -n '30,33p' openspec/changes/architecture-02-module-well-architected/proposal.md\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 314\\n\\n---\\n\\n\\n\\n

\\n\\n**`evidence_refs` described in proposal but absent from ReviewFinding contract.**\\n\\nLines 30–33 describe `evidence_refs` as \\\"supplemental references\\\" that may be retained for additional context, but the `ReviewFinding` model (packages/specfact-code-review/src/specfact_code_review/run/findings.py:34–71) defines only: `category`, `severity`, `tool`, `rule`, `file`, `line`, `message`, and `fixable`. No `evidence_refs` field exists.\\n\\nEither remove the `evidence_refs` reference from the proposal if it's not part of the contract, or add `evidence_refs` to the `ReviewFinding` model and clarify whether it's optional, what type it expects, and how it's emitted by adapters.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` around\\nlines 30 - 33, The proposal mentions an evidence_refs field but the\\nReviewFinding contract (class ReviewFinding in\\npackages/specfact-code-review/src/specfact_code_review/run/findings.py) lacks\\nit; either remove the evidence_refs sentence from the proposal or add an\\noptional evidence_refs attribute to ReviewFinding (e.g., evidence_refs:\\nOptional[List[Dict[str, Any]]] or similar), update its docstring to state it is\\noptional and the expected shape (stable file paths, line ranges, artifact\\nidentifiers), and update adapters that emit ReviewFinding to populate\\nevidence_refs accordingly so the model and proposal stay consistent.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 02b723f\",\"path\":\"openspec/changes/architecture-02-module-well-architected/proposal.md\",\"side\":\"RIGHT\",\"line\":33}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Reduce repeated list lead-in for readability.**\\n\\nThree consecutive bullets start with “**NEW**”. Reword one or two entries to satisfy the style check and keep the section easier to scan.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` around lines 11 -\\n12, The three consecutive bullets all start with the lead-in \\\"**NEW**\\\", which\\nreduces readability; edit the two bullets \\\"Add optional probe adapters for\\nlightweight load-profile validation behind explicit opt-in flags so default\\nreview runs stay local-first and safe for CI.\\\" and \\\"Emit findings in the shared\\nreview report shape and, when the knowledge bundle is installed, forward\\nevidence metadata to the memory runtime without making that integration\\nmandatory.\\\" to use varied lead-ins (e.g., \\\"OPTIONAL:\\\", \\\"NOTE:\\\", or drop the tag\\nfor one) so only one line begins with \\\"**NEW**\\\" and the others use distinct\\nphrasing while preserving the original meaning.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 02b723f\",\"path\":\"openspec/changes/review-resiliency-01-module/proposal.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n**Constrain `category` to canonical enum; don’t permit ad-hoc extension here.**\\n\\n“extend with resiliency-specific categories if needed” makes this proposal incompatible with current `ReviewFinding` validation unless the core enum is formally updated first. Make this line require existing allowed categories only, and route new categories through a separate core-spec change.\\n\\n

\\n

Suggested patch

\\n\\n```diff\\n-- **category**: Set based on the resiliency concern (e.g., `\\\"clean_code\\\"` for general resiliency patterns, or extend with resiliency-specific categories if needed)\\n+- **category**: MUST use an existing canonical `ReviewFinding` category value defined by the core spec; introducing new categories requires a separate core-spec change before module emission.\\n```\\n

\\n\\nAs per coding guidelines: “openspec/**/*.md: Specification truth … drift vs. shipped modules or docs.”\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` at line 21, The\\nproposal allows ad-hoc values for the ReviewFinding field \\\"category\\\", which\\nbreaks validation against the canonical enum; update the text for \\\"category\\\" to\\nrequire only existing allowed enum values (do not say “extend with\\nresiliency-specific categories if needed”), and add a note directing\\ncontributors to propose new categories via a core-spec change rather than in\\nthis module; reference the \\\"category\\\" field and \\\"ReviewFinding\\\" type in the\\nphrasing so readers know which symbol is constrained and mention routing new\\ncategories through the core spec process.\\n```\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Description: Search for the canonical findings model contract and field definitions\\n\\n# Search for findings model specs/schemas\\necho \\\"=== Searching for findings model specs ===\\\"\\nfd -e md -e yaml -e json . openspec/ | xargs rg -l \\\"findings.*model|review-finding\\\" | head -20\\n\\n# Search for field definitions in potential contracts\\necho -e \\\"\\\\n=== Searching for 'category' vs 'type' field usage ===\\\"\\nrg -n \\\"field.*:.*['\\\\\\\"]?(category|type)['\\\\\\\"]?\\\" openspec/ -g '*.{md,yaml,json}' -C 2 | head -40\\n\\n# Look for security-01-unified-findings-model references\\necho -e \\\"\\\\n=== Searching for security-01-unified-findings-model references ===\\\"\\nrg -n \\\"security-01-unified-findings-model\\\" openspec/ -C 3\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 27087\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for actual findings model specs and field definitions\\n\\necho \\\"=== Searching for findings model spec in openspec/specs ===\\\"\\nfind openspec/specs -name \\\"*finding*\\\" -o -name \\\"*model*\\\" | head -20\\n\\necho -e \\\"\\\\n=== Searching for unified-findings-model definition/contract ===\\\"\\nrg -n \\\"unified.findings|findings.model\\\" openspec/specs/ -A 10 | head -80\\n\\necho -e \\\"\\\\n=== Checking security-01 spec for findings model definition ===\\\"\\ncat -n openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md | grep -A 20 \\\"findings.*model\\\\|category\\\\|type.*field\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 2507\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search in core repo for review-finding-model and findings contracts\\n\\necho \\\"=== Searching for review-finding-model in specfact-cli ===\\\"\\nrg -n \\\"review.finding.model|review-finding\\\" --type md --type python --type yaml | head -40\\n\\necho -e \\\"\\\\n=== Searching for findings contract/schema definitions ===\\\"\\nrg -n \\\"findings.*contract|category.*finding|type.*finding.*field\\\" --type md -C 3 | head -60\\n\\necho -e \\\"\\\\n=== Checking if security-01-unified-findings-model exists as core change ===\\\"\\nfind . -name \\\"*security*finding*\\\" -o -name \\\"*unified*finding*\\\" 2>/dev/null | head -20\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 8665\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Examine the actual review-finding-model spec\\n\\necho \\\"=== Contents of review-finding-model directory ===\\\"\\nfind openspec/specs/review-finding-model -type f | head -20\\n\\necho -e \\\"\\\\n=== Review-finding-model spec content ===\\\"\\ncat openspec/specs/review-finding-model/spec.md 2>/dev/null || echo \\\"spec.md not found\\\"\\n\\necho -e \\\"\\\\n=== Code-review-bug-finding spec (for comparison) ===\\\"\\ncat openspec/specs/code-review-bug-finding/spec.md 2>/dev/null | head -80\\n\\necho -e \\\"\\\\n=== Search for 'category' field definition in specs ===\\\"\\nrg -n \\\"category.*field\\\\|field.*category\\\" openspec/specs/ -A 3 -B 1\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 7383\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Examine security-01 proposal and spec for findings model definition\\n\\necho \\\"=== Security-01 proposal - full text ===\\\"\\ncat openspec/changes/security-01-module-sast-sca-secret/proposal.md\\n\\necho -e \\\"\\\\n\\\\n=== Security-01 spec - checking for findings model fields ===\\\"\\ncat openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md | head -150\\n\\necho -e \\\"\\\\n\\\\n=== Search for any 'unified-findings' schema or definition ===\\\"\\nrg -n \\\"unified.*findings.*schema\\\\|unified.*findings.*field\\\\|unified.*findings.*{\\\" openspec/ -A 10 -B 2\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 4950\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for security-01-unified-findings-model definition in core repo\\n\\necho \\\"=== Searching for security-01-unified-findings-model definition ===\\\"\\nrg -n \\\"security-01-unified-findings\\\" . 2>/dev/null | head -30\\n\\necho -e \\\"\\\\n=== Searching for unified.findings or security.finding in core ===\\\"\\nrg -n \\\"unified.*findings\\\\|security.*finding\\\" --type md --type python -C 3 2>/dev/null | head -80\\n\\necho -e \\\"\\\\n=== Checking openspec for security core changes ===\\\"\\nfind openspec -name \\\"*security*unified*\\\" -o -name \\\"*findings*model*\\\" 2>/dev/null\\n\\necho -e \\\"\\\\n=== Searching CHANGE_ORDER for security-01 core change ===\\\"\\nrg -n \\\"security-01-unified-findings-model\\\" . -C 2 2>/dev/null | head -40\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 312\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for where unified-findings-model is actually defined\\n\\necho \\\"=== Check if unified-findings specs exist ===\\\"\\nfind openspec -type d -name \\\"*unified*\\\" -o -type f -name \\\"*unified*\\\"\\n\\necho -e \\\"\\\\n=== Search for findings-model specs ===\\\"\\nfind openspec/specs -type d -name \\\"*finding*\\\"\\n\\necho -e \\\"\\\\n=== Check design docs for findings model specification ===\\\"\\nrg -n \\\"findings.*schema\\\\|findings.*field.*id\\\\|findings.*field.*type\\\" openspec/changes/security-01-module-sast-sca-secret/ -A 5 -B 2 | head -80\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 333\\n\\n---\\n\\n\\n\\n

\\n\\n**Document or defer security findings schema until security-01-unified-findings-model is confirmed.**\\n\\nLines 19-24 reference `security-01-unified-findings-model` as an accepted contract, but that core change doesn't yet exist in `specfact-cli` and its spec (security-01) explicitly warns: \\\"If `security-01-unified-findings-model` is not an accepted core contract in `specfact-cli`, this requirement must be updated.\\\"\\n\\nBefore this proposal can commit to a `type` field schema and specific severity/type mappings, either:\\n1. Confirm the core change is merged and document the actual field contract in security-02's own spec (not just reference the external change), or\\n2. Defer the proposal until security-01's core findings model is accepted and available.\\n\\nReferencing an undefined contract creates a spec drift risk: implementations will build against a contract that may change or may not be accepted, breaking adapter normalization logic.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` around\\nlines 19 - 24, This references an unmerged contract\\n(security-01-unified-findings-model) so either (A) confirm that\\nsecurity-01-unified-findings-model has been accepted/merged and then explicitly\\nstate that dependency in security-02, or (B) inline the full findings schema\\nwithin security-02 (document the `id`, `type`, `severity`, `description`,\\n`source`, `timestamp`, `evidence_refs` fields and their types/constraints) and\\nmove the SPDX-to-normalized mapping rules into security-02 itself (the mappings\\nfor `type` and `severity` such as `license-violation`, `license-compliant`,\\n`license-exception-applied`, `license-unknown`) so implementations do not rely\\non an external, unaccepted contract; update any wording that currently says\\n“reused for license findings” to reflect the chosen approach.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 02b723f\",\"path\":\"openspec/changes/security-02-module-license-compliance/proposal.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Add explicit manifest update task for core_compatibility.**\\n\\nLine 4 requires documenting the minimum required `core_compatibility`, but there's no explicit checklist task to update the module manifest (`packages/specfact-pii-gdpr/module-package.yaml`) with this field. This is a critical adapter boundary between the bundle and core that should be explicitly tracked in the implementation phase.\\n\\n\\n\\n

\\n

🔧 Suggested task addition

\\n\\nAdd a new task in section 3 (after line 16 or as part of the manifest scaffolding):\\n\\n```diff\\n - [ ] 3.1 Scaffold `packages/specfact-pii-gdpr/` with manifest, Typer entrypoints, detector adapters, and bundled rule resources.\\n+ - [ ] 3.1a Update the module manifest (`module-package.yaml`) with the minimum required `core_compatibility` field based on the paired core changes identified in step 1.2.\\n```\\n\\n

\\n\\n\\n\\nAlso applies to: 16-16\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` at line 4, Add an\\nexplicit checklist task to update the module manifest’s core_compatibility\\nfield: modify the tasks document to include a step in section 3 (near the\\nmanifest scaffolding) that instructs the implementer to update\\npackages/specfact-pii-gdpr/module-package.yaml (module-package.yaml) with the\\nminimum required core_compatibility and to record that value in the task list;\\nreference the existing checklist item about documenting minimum required\\ncore_compatibility so it is clear this new task is the concrete action to update\\nthe manifest.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 02b723f\",\"path\":\"openspec/changes/security-03-module-pii-gdpr-eu/tasks.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Add packaging validation for bundled rule resources.**\\n\\nLine 16 mentions \\\"bundled rule resources\\\" will be scaffolded, but there's no corresponding task to validate these resources are properly packaged before release. Per the bundle-packaged-resources coding guideline, packaging validation should fail pre-publish if required resources are missing, with the failure message including the missing resource path.\\n\\n\\n\\n

\\n

📦 Suggested task addition

\\n\\nAdd a new task after line 20 (or within section 3.5):\\n\\n```diff\\n - [ ] 3.5 Update registry metadata, docs references, and any import allowlists required by the new bundle. Note: signature artifacts are produced by publish automation and validated by CI gates; do not manually commit signature files.\\n+ - [ ] 3.6 Add packaging validation to ensure all required bundled rule resources are included in the module package and that the build fails pre-publish with a clear error message (including missing resource paths) if any required resource is absent.\\n```\\n\\n

\\n\\nAs per coding guidelines: \\\"Ensure required project-bundle runtime generator templates are shipped as bundle-owned packaged resources... Add/maintain packaging validation so release fails pre-publish if a required template is missing..., and the failure message must include the missing template path.\\\" (This principle applies to bundled rule resources as well.)\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` at line 16, Add a\\nnew task to the checklist for \\\"3.1 Scaffold `packages/specfact-pii-gdpr/`\\\" that\\nenforces packaging validation of bundled rule resources: implement a pre-publish\\nvalidation step (e.g., \\\"Validate bundled rule resources are packaged\\\") which\\nchecks that all required bundled templates/resources shipped with\\n`packages/specfact-pii-gdpr/` are present in the package bundle and fails the\\nrelease if any are missing, and ensure the failure message explicitly includes\\nthe missing resource path; place this task near section 3.5 or immediately after\\nthe existing scaffold task so it is part of the release checklist.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit 02b723f\",\"path\":\"openspec/changes/security-03-module-pii-gdpr-eu/tasks.md\",\"side\":\"RIGHT\",\"line\":16}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Consider relocating specfact-cli compatibility verification to section 4.**\\n\\nLine 19 is a verification/compatibility check that confirms adapter boundary integrity with `nold-ai/specfact-cli`. While it addresses the prior review feedback about paired artifact verification, its current placement in section 3 \\\"Bundle implementation\\\" suggests it runs during coding, when it would be more naturally sequenced in section 4 \\\"Verification and delivery\\\" after implementation is complete.\\n\\n\\n\\n

\\n

🔄 Optional reorganization

\\n\\nConsider moving this task to section 4 (before or after line 24):\\n\\n```diff\\n ## 3. Bundle implementation\\n \\n - [ ] 3.1 Scaffold `packages/specfact-pii-gdpr/` with manifest, Typer entrypoints, detector adapters, and bundled rule resources.\\n - [ ] 3.2 Implement normalization into the paired core privacy/GDPR findings/report contracts with redaction-safe evidence references.\\n - [ ] 3.3 Integrate shared policy/profile handling for lawful-basis and residency checks plus optional knowledge evidence hooks.\\n- - [ ] 3.4 Verify compatibility with `nold-ai/specfact-cli` whenever changing shared privacy/GDPR findings or report contracts by running and reviewing the paired public artifacts/tests in specfact-cli and confirming any required adapter changes or test updates before PR handoff.\\n- - [ ] 3.5 Update registry metadata, docs references, and any import allowlists required by the new bundle. Note: signature artifacts are produced by publish automation and validated by CI gates; do not manually commit signature files.\\n+ - [ ] 3.4 Update registry metadata, docs references, and any import allowlists required by the new bundle. Note: signature artifacts are produced by publish automation and validated by CI gates; do not manually commit signature files.\\n \\n ## 4. Verification and delivery\\n \\n - [ ] 4.1 Re-run targeted tests and affected package coverage; record passing evidence in `TDD_EVIDENCE.md`.\\n+ - [ ] 4.1a Verify compatibility with `nold-ai/specfact-cli` by running and reviewing the paired public artifacts/tests in specfact-cli and confirming any required adapter changes or test updates before PR handoff.\\n```\\n\\nAlternatively, the current placement is acceptable if the intent is to verify compatibility incrementally during implementation.\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` at line 19, Move\\nthe checklist item \\\"3.4 Verify compatibility with `nold-ai/specfact-cli`\\nwhenever changing shared privacy/GDPR findings or report contracts...\\\" out of\\nsection 3 \\\"Bundle implementation\\\" and into section 4 \\\"Verification and delivery\\\"\\n(place it immediately before or after the existing verification tasks around the\\nstart of section 4), so compatibility with nold-ai/specfact-cli is performed as\\npart of final verification/delivery rather than during implementation; keep the\\nexact checklist wording and numbering adjusted to the new section's sequence.\\n```\\n\\n

\\n

♻️ Duplicate comments (3)

\\n\\n
\\n
scripts/ensure_github_hierarchy_subissues.py (1)
\\n\\n`185-187`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Keep the in-memory sub-issue cache consistent after writes.**\\n\\nAfter a successful `_add_sub_issue`, the local `existing` set is not updated. If `DEFAULT_EDGES` ever contains a duplicate `(parent, child)` in the same run, this can trigger a second mutation attempt.\\n\\n
\\n
Suggested fix
\\n\\n```diff\\n _add_sub_issue(parent_id=parent_id, child_id=child_id)\\n+ existing.add(child_num)\\n sys.stdout.write(f\\\"addSubIssue #{child_num} -> parent #{parent_num}\\\\n\\\")\\n added += 1\\n```\\n
\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@scripts/ensure_github_hierarchy_subissues.py` around lines 185 - 187, After\\ncalling _add_sub_issue(parent_id=parent_id, child_id=child_id) you need to\\nupdate the in-memory cache so duplicate edges aren't retried; add the tuple\\n(parent_id, child_id) to the existing set immediately after the successful write\\n(before incrementing added or continuing) so DEFAULT_EDGES duplicates are\\nignored in the same run and the local state stays consistent.\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/architecture-02-module-well-architected/proposal.md (1)
\\n\\n`69-69`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add trailing newline.**\\n\\nThe file ends without a trailing newline character, violating markdownlint MD047. Files should end with a single newline character.\\n\\n\\n\\n
\\n
📝 Proposed fix
\\n\\n```diff\\n - **Sanitized**: false\\n+\\n```\\n
\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` at line\\n69, The file ends without a trailing newline (last line contains \\\"-\\n**Sanitized**: false\\\"); add a single newline character at the end of\\nopenspec/changes/architecture-02-module-well-architected/proposal.md so the file\\nends with exactly one trailing newline to satisfy markdownlint MD047.\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/architecture-02-module-well-architected/design.md (1)
\\n\\n`65-65`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add trailing newline.**\\n\\nThe file ends without a trailing newline character, violating markdownlint MD047. Files should end with a single newline character.\\n\\n\\n\\n
\\n
📝 Proposed fix
\\n\\n```diff\\n - Should interface diff support start with one ecosystem or ship as a provider abstraction from the first implementation?\\n+\\n```\\n
\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\\n65, Add a single trailing newline character at the end of the file so the last\\nline \\\"Should interface diff support start with one ecosystem or ship as a\\nprovider abstraction from the first implementation?\\\" is followed by exactly one\\nnewline (no extra blank lines) to satisfy markdownlint MD047.\\n```\\n\\n
\\n\\n
\\n\\n

\\n\\n

\\n

🤖 Prompt for all review comments with AI agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nInline comments:\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\\n- Around line 30-35: Decision 2's portable-rule proposal risks losing\\nenforcement fidelity from ALLOWED_IMPORTS.md; update the portable rule schema\\nand enforcement code so it preserves all three policy dimensions: (1) dual-mode\\nprefix matching implemented by preserving the _is_allowed_prefix semantics (add\\na flag/field for exact+dot-prefix matching and ensure the rule parser and\\nmatcher honor it), (2) a MIGRATE-tier blocking marker or enforcement-level field\\nthat causes unconditional forbids for non-allowed imports in that tier, and (3)\\ndirectional cross-bundle allowlists (explicit source→target allow entries) so\\nthe bundle isolation rules are expressible; modify the rule parser/loader,\\nmatcher (where _is_allowed_prefix is referenced), and enforcement engine to read\\nthese fields and enforce them deterministically as described in Decision 2.\\n- Around line 50-61: The BLOCKER currently named \\\"Module integration and any\\nreferences to `architecture-02-well-architected-review` are disallowed...\\\" is\\ngating the design merge even though the paired core contract in `specfact-cli`\\ndoesn't exist; either remove or relax that gate and add a clear meta-note: state\\nthat this design can merge as a design artifact but that implementation PRs must\\nverify the dependency checklist (presence of\\n`architecture-02-well-architected-review` in `specfact-cli`, documented overlaps\\nwith `architecture-01-solution-layer`, and a stable paired core change) before\\nany module integration or references are added; update the checklist text and\\nBLOCKER heading to reflect \\\"Implementation BLOCKER\\\" and reference the exact\\ncontract name `architecture-02-well-architected-review` and repo `specfact-cli`\\nso reviewers know the required precondition without blocking the design doc\\nitself.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md`:\\n- Around line 30-33: The proposal mentions an evidence_refs field but the\\nReviewFinding contract (class ReviewFinding in\\npackages/specfact-code-review/src/specfact_code_review/run/findings.py) lacks\\nit; either remove the evidence_refs sentence from the proposal or add an\\noptional evidence_refs attribute to ReviewFinding (e.g., evidence_refs:\\nOptional[List[Dict[str, Any]]] or similar), update its docstring to state it is\\noptional and the expected shape (stable file paths, line ranges, artifact\\nidentifiers), and update adapters that emit ReviewFinding to populate\\nevidence_refs accordingly so the model and proposal stay consistent.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md`:\\n- Around line 11-12: The three consecutive bullets all start with the lead-in\\n\\\"**NEW**\\\", which reduces readability; edit the two bullets \\\"Add optional probe\\nadapters for lightweight load-profile validation behind explicit opt-in flags so\\ndefault review runs stay local-first and safe for CI.\\\" and \\\"Emit findings in the\\nshared review report shape and, when the knowledge bundle is installed, forward\\nevidence metadata to the memory runtime without making that integration\\nmandatory.\\\" to use varied lead-ins (e.g., \\\"OPTIONAL:\\\", \\\"NOTE:\\\", or drop the tag\\nfor one) so only one line begins with \\\"**NEW**\\\" and the others use distinct\\nphrasing while preserving the original meaning.\\n- Line 21: The proposal allows ad-hoc values for the ReviewFinding field\\n\\\"category\\\", which breaks validation against the canonical enum; update the text\\nfor \\\"category\\\" to require only existing allowed enum values (do not say “extend\\nwith resiliency-specific categories if needed”), and add a note directing\\ncontributors to propose new categories via a core-spec change rather than in\\nthis module; reference the \\\"category\\\" field and \\\"ReviewFinding\\\" type in the\\nphrasing so readers know which symbol is constrained and mention routing new\\ncategories through the core spec process.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md`:\\n- Around line 19-24: This references an unmerged contract\\n(security-01-unified-findings-model) so either (A) confirm that\\nsecurity-01-unified-findings-model has been accepted/merged and then explicitly\\nstate that dependency in security-02, or (B) inline the full findings schema\\nwithin security-02 (document the `id`, `type`, `severity`, `description`,\\n`source`, `timestamp`, `evidence_refs` fields and their types/constraints) and\\nmove the SPDX-to-normalized mapping rules into security-02 itself (the mappings\\nfor `type` and `severity` such as `license-violation`, `license-compliant`,\\n`license-exception-applied`, `license-unknown`) so implementations do not rely\\non an external, unaccepted contract; update any wording that currently says\\n“reused for license findings” to reflect the chosen approach.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`:\\n- Line 4: Add an explicit checklist task to update the module manifest’s\\ncore_compatibility field: modify the tasks document to include a step in section\\n3 (near the manifest scaffolding) that instructs the implementer to update\\npackages/specfact-pii-gdpr/module-package.yaml (module-package.yaml) with the\\nminimum required core_compatibility and to record that value in the task list;\\nreference the existing checklist item about documenting minimum required\\ncore_compatibility so it is clear this new task is the concrete action to update\\nthe manifest.\\n- Line 19: Move the checklist item \\\"3.4 Verify compatibility with\\n`nold-ai/specfact-cli` whenever changing shared privacy/GDPR findings or report\\ncontracts...\\\" out of section 3 \\\"Bundle implementation\\\" and into section 4\\n\\\"Verification and delivery\\\" (place it immediately before or after the existing\\nverification tasks around the start of section 4), so compatibility with\\nnold-ai/specfact-cli is performed as part of final verification/delivery rather\\nthan during implementation; keep the exact checklist wording and numbering\\nadjusted to the new section's sequence.\\n- Line 16: Add a new task to the checklist for \\\"3.1 Scaffold\\n`packages/specfact-pii-gdpr/`\\\" that enforces packaging validation of bundled\\nrule resources: implement a pre-publish validation step (e.g., \\\"Validate bundled\\nrule resources are packaged\\\") which checks that all required bundled\\ntemplates/resources shipped with `packages/specfact-pii-gdpr/` are present in\\nthe package bundle and fails the release if any are missing, and ensure the\\nfailure message explicitly includes the missing resource path; place this task\\nnear section 3.5 or immediately after the existing scaffold task so it is part\\nof the release checklist.\\n\\n---\\n\\nDuplicate comments:\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\\n- Line 65: Add a single trailing newline character at the end of the file so the\\nlast line \\\"Should interface diff support start with one ecosystem or ship as a\\nprovider abstraction from the first implementation?\\\" is followed by exactly one\\nnewline (no extra blank lines) to satisfy markdownlint MD047.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md`:\\n- Line 69: The file ends without a trailing newline (last line contains \\\"-\\n**Sanitized**: false\\\"); add a single newline character at the end of\\nopenspec/changes/architecture-02-module-well-architected/proposal.md so the file\\nends with exactly one trailing newline to satisfy markdownlint MD047.\\n\\nIn `@scripts/ensure_github_hierarchy_subissues.py`:\\n- Around line 185-187: After calling _add_sub_issue(parent_id=parent_id,\\nchild_id=child_id) you need to update the in-memory cache so duplicate edges\\naren't retried; add the tuple (parent_id, child_id) to the existing set\\nimmediately after the successful write (before incrementing added or continuing)\\nso DEFAULT_EDGES duplicates are ignored in the same run and the local state\\nstays consistent.\\n```\\n\\n

\\n\\n

\\n

🪄 Autofix (Beta)

\\n\\n✅ Autofix completed\\n\\n

\\n\\n---\\n\\n

\\n

ℹ️ Review info

\\n\\n

\\n

⚙️ Run configuration

\\n\\n**Configuration used**: Path: .coderabbit.yaml\\n\\n**Review profile**: ASSERTIVE\\n\\n**Plan**: Pro\\n\\n**Run ID**: `383775c3-c52e-4b76-ae47-ed9d20e8bbe5`\\n\\n

\\n\\n

\\n

📥 Commits

\\n\\nReviewing files that changed from the base of the PR and between 0672f50fc279db70e7351ed9079417d641efe976 and b6722789bc0004a94b1963641c1366154ecbcd18.\\n\\n

\\n\\n

\\n

📒 Files selected for processing (7)

\\n\\n* `docs/bundles/project/import-migration.md`\\n* `openspec/changes/architecture-02-module-well-architected/design.md`\\n* `openspec/changes/architecture-02-module-well-architected/proposal.md`\\n* `openspec/changes/review-resiliency-01-module/proposal.md`\\n* `openspec/changes/security-02-module-license-compliance/proposal.md`\\n* `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n* `scripts/ensure_github_hierarchy_subissues.py`\\n\\n

\\n\\n

\\n

📜 Review details

\\n\\n

\\n

🧰 Additional context used

\\n\\n

\\n

📓 Path-based instructions (4)

\\n\\n

\\n

docs/**/*.md

\\n

openspec/**/*.md

\\n

**/*.{js,ts,tsx,jsx,py,java,cs,go,rb,php,cpp,c,h}

\\n\\n\\n**📄 CodeRabbit inference engine (CLAUDE.md)**\\n\\n> Preserve the clean-code compliance gate and its category references (naming, kiss, yagni, dry, and solid)\\n\\nFiles:\\n- `scripts/ensure_github_hierarchy_subissues.py`\\n\\n

\\n

scripts/**/*.py

\\n\\n

\\n

🧠 Learnings (12)

\\n\\n

\\n

📓 Common learnings

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Fix SpecFact code review findings, including warnings, unless a rare explicit exception is documented\\n```\\n\\n**Applied to files:**\\n- `docs/bundles/project/import-migration.md`\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:29.399Z

\\n

📚 Learning: 2026-04-02T21:49:11.371Z

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: Signed module or manifest changes require version-bump review and verify-modules-signature\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n

📚 Learning: 2026-04-13T10:38:15.855Z

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: Refresh .specfact/backlog/github_hierarchy_cache.md with python scripts/sync_github_hierarchy_cache.py when GitHub hierarchy metadata is missing or stale before parent or blocker work\\n```\\n\\n**Applied to files:**\\n- `scripts/ensure_github_hierarchy_subissues.py`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Require public GitHub metadata completeness before implementation when linked issue workflow applies: parent, labels, project assignment, blockers, and blocked-by relationships\\n```\\n\\n**Applied to files:**\\n- `scripts/ensure_github_hierarchy_subissues.py`\\n\\n

\\n\\n

\\n

🪛 LanguageTool

\\n\\n

\\n

openspec/changes/architecture-02-module-well-architected/proposal.md

\\n

openspec/changes/security-02-module-license-compliance/proposal.md

\\n

openspec/changes/review-resiliency-01-module/proposal.md

\\n\\n

\\n

🔀 Multi-repo context nold-ai/specfact-cli

\\n\\nnold-ai/specfact-cli\\n\\n- Consumers of runtime template-resolution helpers / bundled templates:\\n - src/specfact_cli/modules/init/src/commands.py:271–279 — _resolve_templates_dir (resolves dev resources/templates prompts) [::nold-ai/specfact-cli::]\\n - src/specfact_cli/generators/workflow_generator.py:29–38 — workflow generator default templates_dir fallback to resources/templates [::nold-ai/specfact-cli::]\\n - src/specfact_cli/generators/protocol_generator.py:23–34 — protocol generator default templates_dir fallback to resources/templates [::nold-ai/specfact-cli::]\\n - src/specfact_cli/generators/plan_generator.py:24–33 — plan generator default templates_dir fallback to resources/templates [::nold-ai/specfact-cli::]\\n - src/specfact_cli/generators/persona_exporter.py:50–66, 387 — PersonaExporter resolves templates_dir (expects persona/default.md.j2) [::nold-ai/specfact-cli::]\\n - src/specfact_cli/utils/ide_setup.py:127–152, 380–397, 776–796 — IDE template discovery/copying uses resources/prompts and module template discovery logic [::nold-ai/specfact-cli::]\\n - src/specfact_cli/utils/startup_checks.py:5,156–208,334–454 — startup checks that examine template availability/outdatedness [::nold-ai/specfact-cli::]\\n - src/specfact_cli/templates/registry.py:240–271, 310–312 — template registry loading from directories [::nold-ai/specfact-cli::]\\n\\n- Tests that will exercise or assert template-resolution/runtime template packaging behavior:\\n - tests/unit/specfact_cli/registry/test_init_module_lifecycle_ux.py:125–133 — tests _resolve_templates_dir behavior when no discoverable prompts exist [::nold-ai/specfact-cli::]\\n - tests/integration/utils/test_startup_checks_integration.py:118–125 — integration test creating resources/prompts and expecting discovery [::nold-ai/specfact-cli::]\\n - multiple unit/e2e tests referencing resources/prompts and resources/templates (see rg hits under tests/*) — these tests assume the prior template-resolution/packaging semantics and will be impacted if resolver behavior or packaged template locations change [::nold-ai/specfact-cli::]\\n\\n- No occurrences found of the new import-discovery APIs (discover_code_files, import_path_policy, apply_import_runtime_patches) in this repo — runtime import-patching/ignore-policy changes appear not to be directly consumed here. Tests and code in this repo are primarily sensitive to template resolution behavior and presence of packaged templates, not to the import-runtime patches introduced in the modules repo. [::nold-ai/specfact-cli::]\\n\\nConclusion: Relevant cross-repo impact is primarily on template-resolution/packaged templates: specfact-cli contains multiple callers and tests that assume templates are discoverable under resources/templates or via installed package resources, so the modules' new template resolver/helpers and bundled templates should be compatible with these consumers. I found no direct consumers of the new import discovery/patching APIs in this repository.\\n\\n

\\n\\n

\\n

🔇 Additional comments (7)

\\n\\n
\\n
docs/bundles/project/import-migration.md (3)
\\n\\n`21-40`: **Doc/runtime semantics are aligned and precise.**\\n\\nThis section now correctly reflects pre-traversal pruning, warning-driven thresholds, and provisional ETA wording without fixed-duration promises. \\nAs per coding guidelines, this matches: “default ignore pruning… before traversal,” “large-artifact conditions should produce warnings… (500 entries)… (1,000 files),” and “remaining-time… provisional/live guidance.”\\n\\n---\\n\\n`42-52`: **Repo-local ignore override behavior is documented correctly.**\\n\\n`.specfact/.specfactignore` placement and “applied before traversal” semantics are clear and consistent with runtime behavior. \\nAs per coding guidelines, this matches: “repo-local overrides must be supported via `.specfact/.specfactignore`, applied before traversal so they do not inflate scanned-file counts or ETA totals.”\\n\\n---\\n\\n`216-216`: **Best-practice and troubleshooting guidance is consistent with hardened import behavior.**\\n\\nThe live/provisional ETA guidance, 10,000+ file troubleshooting note, warning callout, and `--entry-point` scope guidance are all in parity with the required user-facing semantics. \\nAs per coding guidelines, this matches: “troubleshooting guidance should reference that ‘10,000+ files’ behavior applies even after default ignore pruning… and use `--entry-point` for scope limiting.” \\n\\n\\n\\nAlso applies to: 241-244, 272-272\\n\\n
\\n
\\n
openspec/changes/security-03-module-pii-gdpr-eu/tasks.md (1)
\\n\\n`19-20`: **Proper handling of past review feedback—nicely done!**\\n\\nLines 19-20 correctly address the two prior review comments:\\n- Line 19 adds explicit paired `specfact-cli` compatibility verification with concrete steps to run/review public artifacts and confirm adapter changes\\n- Line 20 clarifies that signature artifacts are produced by publish automation and should not be manually committed, while emphasizing CI gate validation\\n\\nBoth changes strengthen the adapter boundary integrity between this module and the core CLI.\\n\\n
\\n
\\n
openspec/changes/architecture-02-module-well-architected/proposal.md (3)
\\n\\n`19-28`: **Adapter contract correctly aligns with ReviewFinding model.**\\n\\nThe mapping specification (lines 19-28) correctly aligns with the actual `ReviewFinding` contract fields (`category`, `severity`, `tool`, `rule`, `file`, `line`, `message`, `fixable`). Setting `category=\\\"architecture\\\"` is valid per the VALID_CATEGORIES tuple, and the field semantics match the contract requirements.\\n\\nThis properly addresses the past review finding about adapter contract schema alignment.\\n\\n---\\n\\n`55-55`: **Core compatibility specification properly addresses past review.**\\n\\nLine 55 adds explicit `core_compatibility: \\\">=1.0.0 <2.0.0\\\"` in the manifest metadata, addressing the past review concern about defining compatibility requirements between the architecture bundle and the paired core change. This ensures runtime compatibility validation.\\n\\n---\\n\\n`34-38`: **Emission semantics claim about failure isolation contradicts existing bundle behavior.**\\n\\nThe claim that \\\"failures in one analyzer do not block subsequent analyzers\\\" is incorrect. In specfact-code-review's `run_review` orchestrator (runner.py:470–473), there is no exception handling around individual analyzer invocations:\\n\\n```python\\nfor description, runner in _tool_steps(bug_hunt=bug_hunt):\\n if progress_callback is not None:\\n progress_callback(description)\\n findings.extend(runner(files))\\n```\\n\\nIf any analyzer raises an exception, the loop breaks and subsequent analyzers in the sequence (Ruff, Radon, Semgrep, basedpyright, pylint, contract) do not execute. Either add try/except wrapping to achieve true failure isolation, or revise the proposal to correctly state that analyzer failures block subsequent execution.\\n\\n\\n\\n\\t\\t\\t\\t> Likely an incorrect or invalid review comment.\\n\\n
\\n\\n

\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Verify existing core_compatibility formatting and any parser expectations.\\n\\necho \\\"== Existing core_compatibility values in manifests ==\\\"\\nfd module-package.yaml packages --exec rg -n \\\"core_compatibility\\\" {}\\n\\necho\\necho \\\"== Repo references to specifier parsing / compatibility handling ==\\\"\\nrg -n \\\"SpecifierSet|core_compatibility\\\" scripts tools packages openspec -g '*.{py,yaml,md}'\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 13377\\n\\n---\\n\\n\\n\\n

\\n\\n**Fix `core_compatibility` specifier format to match manifest convention (comma-delimited).**\\n\\nAll shipped module manifests use comma-delimited specifiers (`>=0.40.0,<1.0.0`), but the example on line 45 shows space-delimited format (`>=1.0.0 <2.0.0`). Update to `core_compatibility: \\\">=1.0.0,<2.0.0\\\"` to avoid spec drift.\\n\\n

\\n

Proposed fix

\\n\\n```diff\\n-- **Core Compatibility Version Range**: `core_compatibility: \\\">=1.0.0 <2.0.0\\\"` in `module-package.yaml`\\n+- **Core Compatibility Version Range**: `core_compatibility: \\\">=1.0.0,<2.0.0\\\"` in `module-package.yaml`\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` at line\\n45, Update the example manifest to use comma-delimited version specifiers so it\\nmatches the shipped manifest convention: change the `core_compatibility` value\\nin the example `module-package.yaml` from the space-delimited form (`>=1.0.0\\n<2.0.0`) to the comma-delimited form (`>=1.0.0,<2.0.0`) ensuring the string\\nremains quoted.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit bd87f88\",\"path\":\"openspec/changes/security-02-module-license-compliance/proposal.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Tighten wording for Line 20 (“required bundled”).**\\n\\nThe phrase reads awkwardly; simplify to improve checklist clarity.\\n\\n\\n\\n

\\n

✏️ Suggested wording tweak

\\n\\n```diff\\n-- [ ] 3.5 Validate bundled rule resources are packaged: implement a pre-publish validation step that checks all required bundled templates/resources shipped with `packages/specfact-pii-gdpr/` are present in the package bundle, fails the release if any are missing, and ensures the failure message explicitly includes the missing resource path.\\n+- [ ] 3.5 Validate bundled rule resources are packaged: implement a pre-publish validation step that checks all required templates/resources to be bundled with `packages/specfact-pii-gdpr/` are present in the package bundle, fails the release if any are missing, and ensures the failure message explicitly includes the missing resource path.\\n```\\n

\\n\\n\\n\\n

\\n

📝 Committable suggestion

\\n\\n\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n[style] ~20-~20: The double modal “required bundled” is nonstandard (only accepted in certain dialects). Consider “to be bundled”.\\nContext: ...alidation step that checks all required bundled templates/resources shipped with `packa...\\n\\n(NEEDS_FIXED)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` at line 20, The\\nchecklist item in openspec/changes/security-03-module-pii-gdpr-eu/tasks.md is\\nworded awkwardly (\\\"required bundled rule resources are packaged\\\"); reword that\\nsingle line to be clearer and more concise — e.g., \\\"3.5 Validate bundled rule\\nresources: add a pre-publish validation that confirms all templates/resources in\\npackages/specfact-pii-gdpr/ are included in the package, fail the release if any\\nare missing, and include the missing resource path in the error message.\\\"\\nReplace the existing line text with this simplified phrasing so the intent is\\nunambiguous.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit bd87f88\",\"path\":\"openspec/changes/security-03-module-pii-gdpr-eu/tasks.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a single trailing newline at EOF.**\\n\\nLine 30 currently violates MD047; append one newline at the end of the file.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` at line 30, The\\nfile's last line (\\\"- [ ] 4.6 Open the modules PR to `dev`, cross-link paired\\nprivacy/security changes, and note any deferred detector providers as follow-up\\nissues.\\\") is missing a trailing newline and violates MD047; fix it by appending\\na single newline character at EOF so the file ends with one blank line.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/security-03-module-pii-gdpr-eu/tasks.md\",\"side\":\"RIGHT\",\"line\":30}{\"type\":\"pull_request_comment\",\"body\":\"_🛠️ Refactor suggestion_ | _🟠 Major_\\n\\n**Harden `evidence_refs` contract at the core adapter boundary.**\\n\\nLine 59 currently permits arbitrary dict payloads (`dict[str, Any]`), which can cause cross-bundle schema drift and brittle downstream handling. Define a typed evidence reference model (or constrained typed dict) and use `list[EvidenceRef]` to keep emitted payloads stable.\\n\\n\\n\\n

\\n

📦 Suggested contract hardening

\\n\\n```diff\\n+class EvidenceRef(BaseModel):\\n+ \\\"\\\"\\\"Stable evidence reference emitted by review adapters.\\\"\\\"\\\"\\n+\\n+ kind: Literal[\\\"file_range\\\", \\\"artifact\\\", \\\"external\\\"] = Field(..., description=\\\"Reference category.\\\")\\n+ value: str = Field(..., description=\\\"Stable identifier or path.\\\")\\n+ line_start: int | None = Field(default=None, ge=1, description=\\\"Optional 1-based start line.\\\")\\n+ line_end: int | None = Field(default=None, ge=1, description=\\\"Optional 1-based end line.\\\")\\n+\\n class ReviewFinding(BaseModel):\\n@@\\n- evidence_refs: list[dict[str, Any]] | None = Field(\\n+ evidence_refs: list[EvidenceRef] | None = Field(\\n default=None,\\n description=\\\"Optional supplemental references with stable file paths, line ranges, or artifact identifiers.\\\",\\n )\\n```\\n

\\n\\nAs per coding guidelines: “`packages/**/src/**/*.py`: Focus on adapter and bridge patterns ... and clear boundaries so core upgrades do not silently break bundles.”\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@packages/specfact-code-review/src/specfact_code_review/run/findings.py`\\naround lines 59 - 62, The schema currently types evidence_refs as list[dict[str,\\nAny]] which allows arbitrary payloads; define a concrete typed model (e.g., a\\nPydantic BaseModel named EvidenceRef) that captures the allowed keys (e.g.,\\npath, start_line, end_line, artifact_id, description) and replace evidence_refs:\\nlist[dict[str, Any]] | None = Field(...) with evidence_refs: list[EvidenceRef] |\\nNone = Field(...); update imports and any serialization/deserialization points\\nthat construct or consume evidence_refs to instantiate/validate EvidenceRef\\nobjects so the adapter boundary enforces a stable contract (refer to the\\nEvidenceRef model name and evidence_refs field to locate changes).\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commit bd87f88\",\"path\":\"packages/specfact-code-review/src/specfact_code_review/run/findings.py\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**Actionable comments posted: 5**\\n\\n

\\n

♻️ Duplicate comments (3)

\\n\\n
\\n
openspec/changes/security-02-module-license-compliance/proposal.md (1)
\\n\\n`68-68`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add trailing newline at EOF (MD047).**\\n\\nThe file should end with exactly one newline character.\\n\\n\\n\\n
\\n
🔧 Proposed fix
\\n\\n```diff\\n - **Sanitized**: false\\n+\\n```\\n
\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` at line\\n68, The file triggers MD047 because it lacks a trailing newline at EOF; update\\nthe file \\\"openspec/changes/security-02-module-license-compliance/proposal.md\\\" so\\nthat it ends with exactly one newline character (ensure there is a single '\\\\n'\\nas the final character and no extra blank lines).\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/review-resiliency-01-module/proposal.md (1)
\\n\\n`75-75`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a single trailing newline at EOF.**\\n\\nLine 75 still triggers MD047; please end the file with exactly one newline character.\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` at line 75, The\\nfile ends without a proper single trailing newline (violates MD047); open the\\ndocument and ensure it ends with exactly one newline character (no extra blank\\nlines or missing newline). Remove any extra trailing blank lines after the last\\ncontent line (the current \\\"**Sanitized**: false\\\" line) and save the file so the\\nfinal byte is a single '\\\\n' at EOF.\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/architecture-02-module-well-architected/design.md (1)
\\n\\n`65-65`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add trailing newline.**\\n\\nThe file ends without a trailing newline, violating markdownlint MD047.\\n\\n\\n\\n
\\n
📝 Proposed fix
\\n\\n```diff\\n - Should interface diff support start with one ecosystem or ship as a provider abstraction from the first implementation?\\n+\\n```\\n
\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\\n65, The file ends without a trailing newline (violates markdownlint MD047); open\\nthe file containing the line \\\"Should interface diff support start with one\\necosystem or ship as a provider abstraction from the first implementation?\\\" and\\nadd a single newline character at the end of the file so the file terminates\\nwith a trailing newline.\\n```\\n\\n
\\n\\n
\\n\\n

\\n\\n

\\n

🤖 Prompt for all review comments with AI agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nInline comments:\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\\n- Around line 24-28: Implementation PRs must include a complete\\nmodule-package.yaml for the new specfact-architecture bundle and explicitly\\ndeclare the adapter/manifest boundaries deferred by Decision 1: ensure the\\npackage fields (name, version, commands, tier, publisher, bundle_dependencies,\\npip_dependencies, core_compatibility, integrity) follow the same pattern as\\nspecfact-govern/specfact-codebase; set a concrete core_compatibility range\\n(e.g., \\\">=0.40.0,<1.0.0\\\") that matches the paired specfact-cli change, confirm\\nthe architecture-02-well-architected-review entry exists and is stable in\\nspecfact-cli, and verify registry integration by passing the existing\\nsign-modules-on-approval and publish-modules workflows so manifests auto-sign\\nand tarballs auto-publish before merging.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md`:\\n- Line 45: Update the example manifest to use comma-delimited version specifiers\\nso it matches the shipped manifest convention: change the `core_compatibility`\\nvalue in the example `module-package.yaml` from the space-delimited form\\n(`>=1.0.0 <2.0.0`) to the comma-delimited form (`>=1.0.0,<2.0.0`) ensuring the\\nstring remains quoted.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`:\\n- Line 30: The file's last line (\\\"- [ ] 4.6 Open the modules PR to `dev`,\\ncross-link paired privacy/security changes, and note any deferred detector\\nproviders as follow-up issues.\\\") is missing a trailing newline and violates\\nMD047; fix it by appending a single newline character at EOF so the file ends\\nwith one blank line.\\n- Line 20: The checklist item in\\nopenspec/changes/security-03-module-pii-gdpr-eu/tasks.md is worded awkwardly\\n(\\\"required bundled rule resources are packaged\\\"); reword that single line to be\\nclearer and more concise — e.g., \\\"3.5 Validate bundled rule resources: add a\\npre-publish validation that confirms all templates/resources in\\npackages/specfact-pii-gdpr/ are included in the package, fail the release if any\\nare missing, and include the missing resource path in the error message.\\\"\\nReplace the existing line text with this simplified phrasing so the intent is\\nunambiguous.\\n\\nIn `@packages/specfact-code-review/src/specfact_code_review/run/findings.py`:\\n- Around line 59-62: The schema currently types evidence_refs as list[dict[str,\\nAny]] which allows arbitrary payloads; define a concrete typed model (e.g., a\\nPydantic BaseModel named EvidenceRef) that captures the allowed keys (e.g.,\\npath, start_line, end_line, artifact_id, description) and replace evidence_refs:\\nlist[dict[str, Any]] | None = Field(...) with evidence_refs: list[EvidenceRef] |\\nNone = Field(...); update imports and any serialization/deserialization points\\nthat construct or consume evidence_refs to instantiate/validate EvidenceRef\\nobjects so the adapter boundary enforces a stable contract (refer to the\\nEvidenceRef model name and evidence_refs field to locate changes).\\n\\n---\\n\\nDuplicate comments:\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\\n- Line 65: The file ends without a trailing newline (violates markdownlint\\nMD047); open the file containing the line \\\"Should interface diff support start\\nwith one ecosystem or ship as a provider abstraction from the first\\nimplementation?\\\" and add a single newline character at the end of the file so\\nthe file terminates with a trailing newline.\\n\\nIn `@openspec/changes/review-resiliency-01-module/proposal.md`:\\n- Line 75: The file ends without a proper single trailing newline (violates\\nMD047); open the document and ensure it ends with exactly one newline character\\n(no extra blank lines or missing newline). Remove any extra trailing blank lines\\nafter the last content line (the current \\\"**Sanitized**: false\\\" line) and save\\nthe file so the final byte is a single '\\\\n' at EOF.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md`:\\n- Line 68: The file triggers MD047 because it lacks a trailing newline at EOF;\\nupdate the file\\n\\\"openspec/changes/security-02-module-license-compliance/proposal.md\\\" so that it\\nends with exactly one newline character (ensure there is a single '\\\\n' as the\\nfinal character and no extra blank lines).\\n```\\n\\n

\\n\\n

\\n

🪄 Autofix (Beta)

\\n\\n✅ Autofix completed\\n\\n

\\n\\n---\\n\\n

\\n

ℹ️ Review info

\\n\\n

\\n

⚙️ Run configuration

\\n\\n**Configuration used**: Path: .coderabbit.yaml\\n\\n**Review profile**: ASSERTIVE\\n\\n**Plan**: Pro\\n\\n**Run ID**: `c2f0a0b0-f733-4c17-9bf8-0c93268cc446`\\n\\n

\\n\\n

\\n

📥 Commits

\\n\\nReviewing files that changed from the base of the PR and between b6722789bc0004a94b1963641c1366154ecbcd18 and 02b723f82644b3a018d451193168027d1d80576c.\\n\\n

\\n\\n

\\n

📒 Files selected for processing (5)

\\n\\n* `openspec/changes/architecture-02-module-well-architected/design.md`\\n* `openspec/changes/review-resiliency-01-module/proposal.md`\\n* `openspec/changes/security-02-module-license-compliance/proposal.md`\\n* `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n* `packages/specfact-code-review/src/specfact_code_review/run/findings.py`\\n\\n

\\n\\n

\\n

📜 Review details

\\n\\n

\\n

🧰 Additional context used

\\n\\n

\\n

📓 Path-based instructions (3)

\\n\\n

\\n

**/*.{js,ts,tsx,jsx,py,java,cs,go,rb,php,cpp,c,h}

\\n\\n\\n**📄 CodeRabbit inference engine (CLAUDE.md)**\\n\\n> Preserve the clean-code compliance gate and its category references (naming, kiss, yagni, dry, and solid)\\n\\nFiles:\\n- `packages/specfact-code-review/src/specfact_code_review/run/findings.py`\\n\\n

\\n

packages/**/src/**/*.py

\\n\\n\\n**⚙️ CodeRabbit configuration file**\\n\\n> `packages/**/src/**/*.py`: Focus on adapter and bridge patterns: imports from specfact_cli (models, runtime, validators),\\n> Typer/Rich command surfaces, and clear boundaries so core upgrades do not silently break bundles.\\n> Flag breaking assumptions about registry loading, lazy imports, and environment/mode behavior.\\n> \\n\\nFiles:\\n- `packages/specfact-code-review/src/specfact_code_review/run/findings.py`\\n\\n

\\n

openspec/**/*.md

\\n\\n

\\n

🧠 Learnings (13)

\\n\\n

\\n

📓 Common learnings

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: CLAUDE.md:0-0\\nTimestamp: 2026-04-13T10:38:29.399Z\\nLearning: When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\\n```\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Enforce module signatures and version bumps when signed module assets or manifests are affected\\n```\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: Signed module or manifest changes require version-bump review and verify-modules-signature\\n```\\n\\n```\\nLearnt from: djm81\\nRepo: nold-ai/specfact-cli-modules PR: 136\\nFile: registry/modules/specfact-spec-0.40.17.tar.gz.sha256:1-1\\nTimestamp: 2026-04-02T21:49:11.371Z\\nLearning: In nold-ai/specfact-cli-modules, module tarball signatures (registry/signatures/*.tar.sig) are generated by the `publish-modules` GitHub Actions runner during the publish workflow, not committed locally to the branch. Missing signature files should NOT be flagged as a pre-merge blocker in PRs.\\n```\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:29.399Z

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: Signed module or manifest changes require version-bump review and verify-modules-signature\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Fix SpecFact code review findings, including warnings, unless a rare explicit exception is documented\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n- `openspec/changes/security-02-module-license-compliance/proposal.md`\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Treat the clean-code compliance gate as mandatory: the review surface enforces `naming`, `kiss`, `yagni`, `dry`, and `solid` categories and blocks regressions\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:29.399Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: CLAUDE.md:0-0\\nTimestamp: 2026-04-13T10:38:29.399Z\\nLearning: Applies to **/*.{js,ts,tsx,jsx,py,java,cs,go,rb,php,cpp,c,h} : Preserve the clean-code compliance gate and its category references (naming, kiss, yagni, dry, and solid)\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/review-resiliency-01-module/proposal.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:29.399Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: CLAUDE.md:0-0\\nTimestamp: 2026-04-13T10:38:29.399Z\\nLearning: Treat canonical rule docs (docs/agent-rules/INDEX.md) as the source of truth for worktree policy, OpenSpec gating, GitHub completeness checks, TDD order, quality gates, versioning, and documentation rules\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:15.855Z

\\n

📚 Learning: 2026-04-02T21:49:11.371Z

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: This repository enforces the clean-code review gate through hatch run specfact code review run --json --out .specfact/code-review.json\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n\\n

\\n

🪛 LanguageTool

\\n\\n

\\n

openspec/changes/security-02-module-license-compliance/proposal.md

\\n

openspec/changes/security-03-module-pii-gdpr-eu/tasks.md

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n

\\n

openspec/changes/review-resiliency-01-module/proposal.md

\\n\\n[warning] 75-75: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/security-02-module-license-compliance/proposal.md

\\n\\n[warning] 68-68: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/security-03-module-pii-gdpr-eu/tasks.md

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🔀 Multi-repo context nold-ai/specfact-cli

\\n\\n# Linked repositories findings\\n\\nnold-ai/specfact-cli\\n\\n- Generators expect default templates under resources/templates (potential consumer of new template resolution helpers / packaged templates):\\n - PlanGenerator default path logic: src/specfact_cli/generators/plan_generator.py:31–38 — falls back to Path(__file__).parent.parent.parent.parent / \\\"resources\\\" / \\\"templates\\\" when templates_dir is None. [::nold-ai/specfact-cli::]\\n - ProtocolGenerator default path logic: src/specfact_cli/generators/protocol_generator.py:30–34 — same resources/templates fallback. [::nold-ai/specfact-cli::]\\n - WorkflowGenerator default path logic: src/specfact_cli/generators/workflow_generator.py:36–40 — same resources/templates fallback. [::nold-ai/specfact-cli::]\\n - PersonaExporter expects persona templates under resources/templates/persona/default.md.j2: src/specfact_cli/generators/persona_exporter.py:50–90,387. [::nold-ai/specfact-cli::]\\n\\n- Init / resource resolution code references packaged and dev template locations:\\n - _resolve_templates_dir / _resolve_field_mapping_templates_dir use installed package paths and repo-local resources/templates paths: src/specfact_cli/modules/init/src/commands.py:87–108,271–279. Tests rely on this behavior. [::nold-ai/specfact-cli::]\\n\\n- Many tests assert presence/resolution of resources/templates and prompt templates (will exercise any change to template resolution):\\n - tests/unit/specfact_cli/registry/test_init_module_lifecycle_ux.py:125–133 — tests _resolve_templates_dir behavior. [::nold-ai/specfact-cli::]\\n - tests/unit/generators/test_persona_exporter.py:71–90 — asserts exporter.templates_dir exists and can be overridden. [::nold-ai/specfact-cli::]\\n - Multiple integration/e2e tests create resources/prompts or resources/templates and assert generators/init behavior (see tests/integration/* and tests/e2e/* references). [::nold-ai/specfact-cli::]\\n\\n- No matches found for the new import-discovery APIs or runtime patch names (discover_code_files, import_runtime_patches, ImportDiscoveryOptions, should_ignore_path) in this repo — import runtime hardening appears not to be directly consumed here. Tests and code are instead sensitive to template discovery/resolution semantics and the presence of packaged templates. [::nold-ai/specfact-cli::]\\n\\nImplication summary:\\n- The modules changes that introduce packaged runtime templates and new resolver helpers (resolve_project_templates_dir / resolve_templates_dir) and add templates under packages/specfact-project/resources/templates must remain compatible with specfact-cli callers that expect resources/templates locations or allow overriding templates_dir. Tests in specfact-cli will exercise template resolution behavior and could break if packaged template lookup semantics change or if installed package resource locations differ. The import runtime patches / discovery logic added in modules do not appear to have direct consumers in this repository. [::nold-ai/specfact-cli::]\\n\\n

\\n\\n

\\n

🔇 Additional comments (5)

\\n\\n
\\n
packages/specfact-code-review/src/specfact_code_review/run/findings.py (1)
\\n\\n`133-133`: **Blocking-findings predicate remains correct and aligned.**\\n\\nLine 133 stays consistent with `ReviewFinding.is_blocking()` and preserves existing gating behavior.\\n\\n
\\n
\\n
openspec/changes/review-resiliency-01-module/proposal.md (1)
\\n\\n`21-43`: **Adapter contract is now aligned with the canonical findings model.**\\n\\nThis mapping correctly anchors emissions to `ReviewFinding` core fields and canonical severities (`error|warning|info`), while keeping `evidence_refs` supplemental.\\n\\n\\n\\nAs per coding guidelines: “`openspec/**/*.md`: Specification truth ... drift vs. shipped modules or docs.”\\n\\n
\\n
\\n
openspec/changes/security-03-module-pii-gdpr-eu/tasks.md (1)
\\n\\n`25-27`: **Verification gates correctly protect cross-repo and signing boundaries.**\\n\\nIncluding explicit `specfact-cli` compatibility checks and `verify-modules-signature --enforce-version-bump` here is the right boundary control before delivery.\\n\\n\\n\\nBased on learnings: “When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics” and “Signed module or manifest changes require version-bump review and verify-modules-signature.”\\n\\n
\\n
\\n
openspec/changes/architecture-02-module-well-architected/design.md (2)
\\n\\n`48-61`: **Implementation blocker adequately addresses core contract dependency.**\\n\\nThe Migration Plan meta-note (line 50) and Implementation BLOCKER section (lines 56-61) clearly gate implementation work until the paired `architecture-02-well-architected-review` contract exists in specfact-cli. This addresses previous review concerns by:\\n- Distinguishing design-phase merge from implementation-phase work\\n- Explicitly naming the required contract and repository\\n- Providing a concrete checklist for verifying preconditions\\n\\nThe blocker adequately protects against premature module integration that would create cross-repo API mismatches.\\n\\n**However**, the broader issue remains: this architecture-02 design file appears misaligned with PR `#243`'s import-hardening objectives (see separate critical comment). If this file was unintentionally included, the blocker's relevance to this PR is unclear.\\n\\n---\\n\\n`1-65`: **Scope and sequencing are correct; blocker is properly structured.**\\n\\nThis design is formally sequenced in CHANGE_ORDER.md as `architecture-02-module-well-architected` (`#230`) alongside other module changes. The blocker section (lines 50–61) correctly gates implementation: \\\"Module integration and any references...are disallowed until the paired `specfact-cli` change exists and is marked stable,\\\" with three explicit gating conditions that implementation PRs must satisfy.\\n\\nThe missing paired core contract (`architecture-02-well-architected-review`) is confirmed absent from specfact-cli, but the design document explicitly allows design-artifact merge while blocking implementation. This is the correct sequencing.\\n\\n**Adapter boundaries, registry, and rule enforcement are adequately designed.**\\n\\nDecision 2 specifies portable rule resources with three enforcement dimensions: dual-mode prefix matching (preserving `_is_allowed_prefix` semantics), MIGRATE-tier blocking markers, and directional cross-bundle allowlists. Decision 3 separates graph extraction from policy evaluation through analyzer adapters. The spec requires bundle registration with truthful dependencies and `core_compatibility` metadata, and mandates translation to paired core findings contracts instead of bundle-local schemas.\\n\\nImplementation details for the rule parser/loader/matcher will be fleshed out in implementation PRs, which is appropriate for a design-phase document. The design provides sufficient contract specification for those PRs to proceed once the blocker conditions are met.\\n\\n
\\n\\n

\\n\\n

\\n

Best fix (without changing functionality):

\\n

Edit the import on line 6 from:\\n
- from typing import Any, Literal
\\n
To:\\n
- from typing import Literal
\\n

\\n

This preserves all existing behavior and type annotations while resolving the unused import warning.\",\"path\":\"packages/specfact-code-review/src/specfact_code_review/run/findings.py\",\"side\":\"RIGHT\",\"line\":6}{\"type\":\"pull_request_comment\",\"body\":\"_🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Decision 1 implementation prescription may be too detailed for design-phase artifact.**\\n\\nDecision 1 now includes extensive implementation requirements (module-package.yaml fields, workflow verification, registry integration). While these details address adapter boundary concerns, they may be overly prescriptive for a design document that, per the meta-note at line 50, \\\"can merge as a design artifact\\\" before implementation.\\n\\nConsider moving the detailed implementation checklist (complete module-package.yaml structure, concrete core_compatibility ranges, workflow verification steps) to either:\\n- The paired `tasks.md` or `spec.md` artifacts where implementation contracts are typically formalized, or\\n- A dedicated \\\"Implementation Requirements\\\" section separate from the high-level decision statement\\n\\nThis would preserve the decision's strategic direction while deferring tactical implementation details to artifacts that gate actual implementation PRs.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` around\\nlines 24 - 28, Move the detailed implementation checklist out of the high-level\\nDecision 1 paragraph and into a dedicated implementation artifact (e.g.,\\ntasks.md or spec.md) or a separate \\\"Implementation Requirements\\\" section: keep\\nthe Decision 1 summary as the strategic requirement to create\\npackages/specfact-architecture/ with an architecture command and\\nmanifest/lifecycle, and relocate the concrete module-package.yaml field list\\n(name, version, commands, tier, publisher, bundle_dependencies,\\npip_dependencies, core_compatibility, integrity), the example core_compatibility\\nrange, the requirement to ensure architecture-02-well-architected-review exists\\nin specfact-cli, and the workflow/registry verification steps\\n(sign-modules-on-approval, publish-modules) into that implementation artifact so\\nthe design.md remains a high-level decision document.\\n```\\n\\n

\\n\\n\\n\\n\",\"path\":\"openspec/changes/architecture-02-module-well-architected/design.md\",\"side\":\"RIGHT\",\"line\":28}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Reduce repeated `- **NEW**:` lead-ins for readability.**\\n\\nLanguageTool is right here—three consecutive bullets start the same way, which reads mechanically. Reword one or two bullet openers to improve scanability.\\n\\n

\\n

🧰 Tools

\\n\\n

\\n

🪛 LanguageTool

\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` around\\nlines 9 - 13, The bullets repeat the same \\\"- **NEW**:\\\" prefix three times;\\nupdate the proposal so only the first truly new item uses \\\"- **NEW**:\\\" and\\nrephrase the following two similar bullets to varied lead-ins (e.g., \\\"-\\n**INCLUDES**: Package SBOM ingestion...\\\" and \\\"- **ENABLES**: Add policy-aware\\nhandling...\\\") while keeping the same referenced symbols\\n(specfact-license-compliance, license command, SBOM, SPDX normalization\\nadapters, bundle manifest, registry, docs, signing expectations, compatibility\\nhooks, and security bundle) and preserving the original meaning and order.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commits bd87f88 to 0d933ea\",\"path\":\"openspec/changes/security-02-module-license-compliance/proposal.md\",\"side\":\"RIGHT\",\"line\":13}{\"type\":\"pull_request_comment\",\"body\":\"_⚠️ Potential issue_ | _🟠 Major_\\n\\n

\\n

🧩 Analysis chain

\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# First, verify the code file exists and check lines 34-49\\nwc -l packages/specfact-code-review/src/specfact_code_review/run/findings.py\\ncat -n packages/specfact-code-review/src/specfact_code_review/run/findings.py | sed -n '30,55p'\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1387\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for EvidenceRef usage in the codebase\\nrg \\\"EvidenceRef\\\" -A 3 -B 1\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1277\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check for any validators or model_validator usage patterns in related files\\nfd \\\"findings\\\\.py|test.*findings\\\" --type f\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 195\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Look for tests related to findings/EvidenceRef\\nfind . -name \\\"*test*\\\" -type f | xargs grep -l \\\"EvidenceRef\\\" 2>/dev/null || echo \\\"No test files found with EvidenceRef\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 108\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check the test file for how EvidenceRef is used/tested\\ncat -n tests/unit/specfact_code_review/run/test_findings.py | head -100\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 3131\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for how EvidenceRef is instantiated in the codebase\\nrg \\\"EvidenceRef\\\\(\\\" -B 2 -A 2\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 531\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check how evidence_refs is used downstream in review payloads/exports\\nrg \\\"evidence_refs\\\" -B 2 -A 2\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 2731\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Look at the full ReviewFinding class to understand the context\\nsed -n '51,120p' packages/specfact-code-review/src/specfact_code_review/run/findings.py\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 3243\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if specfact-cli has any consumer code that parses EvidenceRef or evidence_refs\\nrg \\\"evidence_refs|EvidenceRef\\\" -B 2 -A 2\\n```\\n\\nRepository: nold-ai/specfact-cli\\n\\nLength of output: 46\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if there are any integration tests or consumer tests for ReviewReport/ReviewFinding\\nfind . -name \\\"*test*\\\" -type f | xargs grep -l \\\"ReviewFinding\\\\|ReviewReport\\\" 2>/dev/null | head -10\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 509\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check e2e test to see if it creates ReviewReports with evidence_refs\\ngrep -n \\\"evidence_refs\\\\|EvidenceRef\\\" tests/e2e/specfact_code_review/test_review_run_e2e.py\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 54\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check runner tests to see how findings/evidence_refs are created\\ngrep -n \\\"evidence_refs\\\\|EvidenceRef\\\" tests/unit/specfact_code_review/run/test_runner.py -B 3 -A 3\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 54\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if any code actually creates EvidenceRef instances with partial/empty locators\\nrg \\\"EvidenceRef\\\\s*\\\\(\\\" -A 5 --type py | head -50\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 880\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Look at the proposal documents to understand contract intent\\ncat openspec/changes/review-resiliency-01-module/proposal.md | grep -A 10 -B 5 \\\"evidence_refs\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 727\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if ReviewReport is serialized/exported (JSON API, file output, etc.)\\nrg \\\"ReviewReport\\\\|ReviewFinding\\\" --type py | grep -E \\\"json|dump|export|serialize|write|output\\\" -i | head -20\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 54\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check the commands module to see how ReviewReport is exposed\\ncat packages/specfact-code-review/src/specfact_code_review/run/commands.py | head -100\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 2776\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check how ReviewReport is used in CLI output/return\\nrg \\\"ReviewReport|evidence_refs\\\" packages/specfact-code-review/src/specfact_code_review/run/commands.py -A 5 -B 2\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1930\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check the ledger or export modules to see if evidence_refs gets serialized\\nfind packages -name \\\"*.py\\\" -type f -exec grep -l \\\"model_dump\\\\|json\\\\|export\\\\|serialize\\\" {} \\\\; | xargs grep -l \\\"ReviewReport\\\\|ReviewFinding\\\" 2>/dev/null | head -5\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 441\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check runner.py to see if/how evidence_refs are populated\\ncat -n packages/specfact-code-review/src/specfact_code_review/run/runner.py | grep -A 30 \\\"EvidenceRef\\\\|evidence_refs\\\" | head -50\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 54\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Search for any code that constructs ReviewFinding with evidence_refs\\nrg \\\"ReviewFinding\\\\(\\\" -A 15 --type py | grep -A 15 \\\"evidence_refs\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 54\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/antml:bash\\n# Check if any tools/runners populate evidence_refs\\nrg \\\"evidence_refs\\\\s*=\\\" --type py -B 5 -A 5\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 54\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if evidence_refs is ever populated in any code path\\nrg \\\"evidence_refs\\\\s*:\\\" --type py -B 3 -A 1\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 755\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if there's any schema documentation or API spec that describes evidence_refs constraints\\nfind . -name \\\"*.md\\\" -o -name \\\"*.rst\\\" | xargs grep -l \\\"evidence_refs\\\" 2>/dev/null | head -5\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 270\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Read the architecture proposal to understand evidence_refs intent\\ncat openspec/changes/architecture-02-module-well-architected/proposal.md | grep -A 20 \\\"evidence_refs\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1011\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if there's any validation or constraints mentioned in the proposals\\ncat openspec/changes/security-02-module-license-compliance/proposal.md | grep -A 20 \\\"evidence_refs\\\"\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1115\\n\\n---\\n\\n🏁 Script executed:\\n\\n```shell\\n#!/bin/bash\\n# Check if ReviewReport is sent to specfact-cli and how it's consumed\\ngrep -r \\\"ReviewReport\\\" packages/ --include=\\\"*.py\\\" | grep -E \\\"import|from\\\" | head -10\\n```\\n\\nRepository: nold-ai/specfact-cli-modules\\n\\nLength of output: 1237\\n\\n---\\n\\n\\n\\n

\\n\\n**Harden `EvidenceRef` invariants to prevent structurally invalid supplemental evidence references.**\\n\\nThe `EvidenceRef` model (lines 34–49) allows invalid states: empty references with all locators null, and inconsistent line ranges (`end_line < start_line`, `end_line` without `start_line`). Since `ReviewReport` serializes this schema to JSON and it's part of the external adapter contract, these gaps weaken the boundary and risk malformed payloads reaching downstream consumers.\\n\\nAlthough `evidence_refs` is not currently populated in production code paths, adding structural invariants now prevents future misuse and aligns with the adapter-boundary contract.\\n\\n

\\n

Proposed invariant hardening

\\n\\n```diff\\n class EvidenceRef(BaseModel):\\n@@\\n `@field_validator`(\\\"path\\\", \\\"artifact_id\\\", \\\"description\\\")\\n `@classmethod`\\n def _validate_non_empty_if_present(cls, value: str | None) -> str | None:\\n if value is not None and not value.strip():\\n raise ValueError(\\\"value must not be empty if provided\\\")\\n return value\\n+\\n+ `@model_validator`(mode=\\\"after\\\")\\n+ def _validate_reference_shape(self) -> \\\"EvidenceRef\\\":\\n+ if self.path is None and self.artifact_id is None:\\n+ raise ValueError(\\\"either path or artifact_id must be provided\\\")\\n+ if (self.start_line is not None or self.end_line is not None) and self.path is None:\\n+ raise ValueError(\\\"line range requires path\\\")\\n+ if self.end_line is not None and self.start_line is None:\\n+ raise ValueError(\\\"end_line requires start_line\\\")\\n+ if (\\n+ self.start_line is not None\\n+ and self.end_line is not None\\n+ and self.end_line < self.start_line\\n+ ):\\n+ raise ValueError(\\\"end_line must be greater than or equal to start_line\\\")\\n+ return self\\n```\\n

\\n\\nAs per coding guidelines: \\\"`packages/**/src/**/*.py`: clear boundaries so core upgrades do not silently break bundles.\\\"\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@packages/specfact-code-review/src/specfact_code_review/run/findings.py`\\naround lines 34 - 49, EvidenceRef currently allows structurally invalid objects\\n(all locators null and inconsistent line ranges); add a cross-field model\\nvalidator on EvidenceRef (e.g., a `@model_validator`(mode=\\\"after\\\") method named\\n_validate_invariants) that enforces: at least one locator is present (path or\\nartifact_id or start_line), if end_line is provided then start_line must be\\nprovided, and if both start_line and end_line are provided then end_line >=\\nstart_line; keep the existing field_validator _validate_non_empty_if_present for\\nstring trimming and raise ValueError with clear messages when invariants fail.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n✅ Addressed in commits bd87f88 to 0d933ea\",\"path\":\"packages/specfact-code-review/src/specfact_code_review/run/findings.py\",\"side\":\"RIGHT\",\"line\":49}{\"type\":\"pull_request_comment\",\"body\":\"**Actionable comments posted: 3**\\n\\n

\\n

♻️ Duplicate comments (4)

\\n\\n
\\n
openspec/changes/security-03-module-pii-gdpr-eu/tasks.md (1)
\\n\\n`30-30`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Append a single trailing newline at EOF.**\\n\\n`MD047` is still triggered; please add one newline after Line 30.\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` at line 30, Append\\na single trailing newline at the end of the file so MD047 stops firing: open the\\ntasks.md file and ensure there is one extra newline character after the final\\nline containing \\\"- [ ] 4.6 Open the modules PR to `dev`, cross-link paired\\nprivacy/security changes, and note any deferred detector providers as follow-up\\nissues.\\\" (i.e., add one blank line at EOF).\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/security-02-module-license-compliance/proposal.md (1)
\\n\\n`65-68`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add a single trailing newline at EOF (MD047).**\\n\\nThe file still needs exactly one newline at end-of-file to satisfy markdownlint.\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` around\\nlines 65 - 68, The file ends without a single trailing newline; open the\\nmarkdown file containing the metadata block (look for the lines beginning with\\n\\\"**Issue URL**\\\", \\\"**Repository**\\\", \\\"**Last Synced Status**\\\", \\\"**Sanitized**\\\")\\nand add exactly one newline character at the end of the file (ensure there is no\\nextra blank line beyond that) so the file ends with one trailing newline to\\nsatisfy MD047.\\n```\\n\\n
\\n\\n
\\n
\\n
openspec/changes/architecture-02-module-well-architected/design.md (2)
\\n\\n`54-61`: _🧹 Nitpick_ | _🔵 Trivial_\\n\\n**Unchecked blocker checkboxes may create merge ambiguity.**\\n\\nThe \\\"Implementation BLOCKER\\\" section (lines 56-61) contains unchecked checkboxes for verifying the paired core contract. While the meta-note at line 50 clarifies this design can merge before implementation blockers are satisfied, the presence of unchecked boxes in a \\\"BLOCKER\\\" section may signal to reviewers that this design is not ready to merge.\\n\\nConsider either:\\n- Adding a sentence to the section header clarifying these are *implementation* blockers verified during implementation PRs, not design-merge blockers, or\\n- Moving the checklist to a \\\"Prerequisites for Implementation\\\" or \\\"Implementation Gates\\\" section to reduce ambiguity\\n\\nThis would align with the meta-note's intent and make the design/implementation sequencing clearer to reviewers unfamiliar with the prior discussion.\\n\\n\\n\\nBased on learnings, when a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` around\\nlines 54 - 61, The \\\"Implementation BLOCKER\\\" checklist referencing the\\n`architecture-02-well-architected-review` contract creates merge ambiguity;\\nupdate the document by either (A) appending a clarifying sentence to the\\n\\\"Implementation BLOCKER\\\" header stating these are implementation-time checks\\nverified during paired implementation PRs (not design merge blockers), or (B)\\nmoving the checkbox list out of the blocker header into a new \\\"Prerequisites for\\nImplementation\\\" or \\\"Implementation Gates\\\" section; ensure the text references\\nthe `architecture-02-well-architected-review` artifact and the requirement that\\nthe paired `specfact-cli` change be marked stable so reviewers understand\\nsequencing.\\n```\\n\\n
\\n\\n---\\n\\n`65-65`: _⚠️ Potential issue_ | _🟡 Minor_\\n\\n**Add trailing newline.**\\n\\nStatic analysis (markdownlint MD047) requires files to end with a single newline character. This was flagged in a previous review but remains unresolved.\\n\\n
\\n
📝 Proposed fix
\\n\\n```diff\\n - Should interface diff support start with one ecosystem or ship as a provider abstraction from the first implementation?\\n+\\n```\\n
\\n\\n
\\n
🤖 Prompt for AI Agents
\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\\n65, This file is missing a trailing newline (markdownlint MD047); open the\\nmarkdown that contains the line \\\"Should interface diff support start with one\\necosystem or ship as a provider abstraction from the first implementation?\\\"\\n(design.md content) and ensure the file ends with exactly one newline character\\nby adding a single newline at EOF so the file terminates with a single trailing\\nnewline.\\n```\\n\\n
\\n\\n
\\n\\n

\\n\\n

\\n

🤖 Prompt for all review comments with AI agents

\\n\\n```\\nVerify each finding against the current code and only fix it if needed.\\n\\nInline comments:\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\\n- Around line 24-28: Move the detailed implementation checklist out of the\\nhigh-level Decision 1 paragraph and into a dedicated implementation artifact\\n(e.g., tasks.md or spec.md) or a separate \\\"Implementation Requirements\\\" section:\\nkeep the Decision 1 summary as the strategic requirement to create\\npackages/specfact-architecture/ with an architecture command and\\nmanifest/lifecycle, and relocate the concrete module-package.yaml field list\\n(name, version, commands, tier, publisher, bundle_dependencies,\\npip_dependencies, core_compatibility, integrity), the example core_compatibility\\nrange, the requirement to ensure architecture-02-well-architected-review exists\\nin specfact-cli, and the workflow/registry verification steps\\n(sign-modules-on-approval, publish-modules) into that implementation artifact so\\nthe design.md remains a high-level decision document.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md`:\\n- Around line 9-13: The bullets repeat the same \\\"- **NEW**:\\\" prefix three times;\\nupdate the proposal so only the first truly new item uses \\\"- **NEW**:\\\" and\\nrephrase the following two similar bullets to varied lead-ins (e.g., \\\"-\\n**INCLUDES**: Package SBOM ingestion...\\\" and \\\"- **ENABLES**: Add policy-aware\\nhandling...\\\") while keeping the same referenced symbols\\n(specfact-license-compliance, license command, SBOM, SPDX normalization\\nadapters, bundle manifest, registry, docs, signing expectations, compatibility\\nhooks, and security bundle) and preserving the original meaning and order.\\n\\nIn `@packages/specfact-code-review/src/specfact_code_review/run/findings.py`:\\n- Around line 34-49: EvidenceRef currently allows structurally invalid objects\\n(all locators null and inconsistent line ranges); add a cross-field model\\nvalidator on EvidenceRef (e.g., a `@model_validator`(mode=\\\"after\\\") method named\\n_validate_invariants) that enforces: at least one locator is present (path or\\nartifact_id or start_line), if end_line is provided then start_line must be\\nprovided, and if both start_line and end_line are provided then end_line >=\\nstart_line; keep the existing field_validator _validate_non_empty_if_present for\\nstring trimming and raise ValueError with clear messages when invariants fail.\\n\\n---\\n\\nDuplicate comments:\\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\\n- Around line 54-61: The \\\"Implementation BLOCKER\\\" checklist referencing the\\n`architecture-02-well-architected-review` contract creates merge ambiguity;\\nupdate the document by either (A) appending a clarifying sentence to the\\n\\\"Implementation BLOCKER\\\" header stating these are implementation-time checks\\nverified during paired implementation PRs (not design merge blockers), or (B)\\nmoving the checkbox list out of the blocker header into a new \\\"Prerequisites for\\nImplementation\\\" or \\\"Implementation Gates\\\" section; ensure the text references\\nthe `architecture-02-well-architected-review` artifact and the requirement that\\nthe paired `specfact-cli` change be marked stable so reviewers understand\\nsequencing.\\n- Line 65: This file is missing a trailing newline (markdownlint MD047); open\\nthe markdown that contains the line \\\"Should interface diff support start with\\none ecosystem or ship as a provider abstraction from the first implementation?\\\"\\n(design.md content) and ensure the file ends with exactly one newline character\\nby adding a single newline at EOF so the file terminates with a single trailing\\nnewline.\\n\\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md`:\\n- Around line 65-68: The file ends without a single trailing newline; open the\\nmarkdown file containing the metadata block (look for the lines beginning with\\n\\\"**Issue URL**\\\", \\\"**Repository**\\\", \\\"**Last Synced Status**\\\", \\\"**Sanitized**\\\")\\nand add exactly one newline character at the end of the file (ensure there is no\\nextra blank line beyond that) so the file ends with one trailing newline to\\nsatisfy MD047.\\n\\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`:\\n- Line 30: Append a single trailing newline at the end of the file so MD047\\nstops firing: open the tasks.md file and ensure there is one extra newline\\ncharacter after the final line containing \\\"- [ ] 4.6 Open the modules PR to\\n`dev`, cross-link paired privacy/security changes, and note any deferred\\ndetector providers as follow-up issues.\\\" (i.e., add one blank line at EOF).\\n```\\n\\n

\\n\\n

\\n

🪄 Autofix (Beta)

\\n\\n✅ Autofix completed\\n\\n

\\n\\n---\\n\\n

\\n

ℹ️ Review info

\\n\\n

\\n

⚙️ Run configuration

\\n\\n**Configuration used**: Path: .coderabbit.yaml\\n\\n**Review profile**: ASSERTIVE\\n\\n**Plan**: Pro\\n\\n**Run ID**: `9d003493-8f65-43d0-9e1c-096c6c431bd2`\\n\\n

\\n\\n

\\n

📥 Commits

\\n\\nReviewing files that changed from the base of the PR and between 02b723f82644b3a018d451193168027d1d80576c and bd87f88efbf2fc2c3b46080e0eaf147db8cd80d5.\\n\\n

\\n\\n

\\n

📒 Files selected for processing (4)

\\n\\n* `openspec/changes/architecture-02-module-well-architected/design.md`\\n* `openspec/changes/security-02-module-license-compliance/proposal.md`\\n* `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n* `packages/specfact-code-review/src/specfact_code_review/run/findings.py`\\n\\n

\\n\\n

\\n

📜 Review details

\\n\\n

\\n

🧰 Additional context used

\\n\\n

\\n

📓 Path-based instructions (3)

\\n\\n

\\n

openspec/**/*.md

\\n

**/*.{js,ts,tsx,jsx,py,java,cs,go,rb,php,cpp,c,h}

\\n\\n\\n**📄 CodeRabbit inference engine (CLAUDE.md)**\\n\\n> Preserve the clean-code compliance gate and its category references (naming, kiss, yagni, dry, and solid)\\n\\nFiles:\\n- `packages/specfact-code-review/src/specfact_code_review/run/findings.py`\\n\\n

\\n

packages/**/src/**/*.py

\\n\\n

\\n

🧠 Learnings (14)

\\n\\n

\\n

📓 Common learnings

\\n\\n```\\nLearnt from: djm81\\nRepo: nold-ai/specfact-cli-modules PR: 136\\nFile: registry/modules/specfact-spec-0.40.17.tar.gz.sha256:1-1\\nTimestamp: 2026-04-02T21:49:11.371Z\\nLearning: In nold-ai/specfact-cli-modules, module tarball signatures (registry/signatures/*.tar.sig) are generated by the `publish-modules` GitHub Actions runner during the publish workflow, not committed locally to the branch. Missing signature files should NOT be flagged as a pre-merge blocker in PRs.\\n```\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Enforce module signatures and version bumps when signed module assets or manifests are affected\\n```\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: Signed module or manifest changes require version-bump review and verify-modules-signature\\n```\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: CLAUDE.md:0-0\\nTimestamp: 2026-04-13T10:38:29.399Z\\nLearning: When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\\n```\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:29.399Z

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Fix SpecFact code review findings, including warnings, unless a rare explicit exception is documented\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n- `openspec/changes/security-02-module-license-compliance/proposal.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:29.399Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: CLAUDE.md:0-0\\nTimestamp: 2026-04-13T10:38:29.399Z\\nLearning: Treat canonical rule docs (docs/agent-rules/INDEX.md) as the source of truth for worktree policy, OpenSpec gating, GitHub completeness checks, TDD order, quality gates, versioning, and documentation rules\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:15.855Z

\\n

📚 Learning: 2026-04-13T10:38:29.399Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: CLAUDE.md:0-0\\nTimestamp: 2026-04-13T10:38:29.399Z\\nLearning: Treat clean-code regressions (naming, kiss, yagni, dry, solid violations) as blocking until they are fixed or explicitly justified\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: AGENTS.md:0-0\\nTimestamp: 2026-04-13T10:38:43.535Z\\nLearning: Require public GitHub metadata completeness before implementation when linked issue workflow applies: parent, labels, project assignment, blockers, and blocked-by relationships\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n

📚 Learning: 2026-04-02T21:49:11.371Z

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: Signed module or manifest changes require version-bump review and verify-modules-signature\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n

📚 Learning: 2026-04-13T10:38:43.535Z

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n

📚 Learning: 2026-04-13T10:38:22.848Z

\\n\\n```\\nLearnt from: CR\\nRepo: nold-ai/specfact-cli-modules PR: 0\\nFile: .github/copilot-instructions.md:0-0\\nTimestamp: 2026-04-13T10:38:22.848Z\\nLearning: This repository enforces the clean-code review gate through hatch run specfact code review run --json --out .specfact/code-review.json\\n```\\n\\n**Applied to files:**\\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\\n\\n

\\n\\n

\\n

🪛 LanguageTool

\\n\\n

\\n

openspec/changes/security-02-module-license-compliance/proposal.md

\\n\\n

\\n

🪛 markdownlint-cli2 (0.22.0)

\\n\\n

\\n

openspec/changes/security-02-module-license-compliance/proposal.md

\\n\\n[warning] 65-65: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n

openspec/changes/security-03-module-pii-gdpr-eu/tasks.md

\\n\\n[warning] 30-30: Files should end with a single newline character\\n\\n(MD047, single-trailing-newline)\\n\\n

\\n\\n

\\n

🔀 Multi-repo context nold-ai/specfact-cli

\\n\\n# Linked repositories findings\\n\\nnold-ai/specfact-cli\\n\\n- Template/resource resolution and generators expect packaged or repo-local templates:\\n - _resolve_field_mapping_templates_dir — locates packaged or dev templates under resources/templates/backlog/field_mappings and falls back to importlib/resources or package spec lookup. [::nold-ai/specfact-cli::src/specfact_cli/modules/init/src/commands.py:36-110]\\n\\n- Tests rely on template discovery behavior:\\n - test_resolve_templates_dir_none_when_no_discoverable_prompts — expects _resolve_templates_dir to return None when no discoverable prompts/templates exist. [::nold-ai/specfact-cli::tests/unit/specfact_cli/registry/test_init_module_lifecycle_ux.py:125-141]\\n\\nNotes:\\n- I did not find any usages of the new import-discovery APIs (discover_code_files, import_runtime_patches, ImportDiscoveryOptions, should_ignore_path, resolve_templates_dir aliases) in this repo; primary surface of potential impact here is template/resource resolution behavior and tests that assert resolution semantics. [::nold-ai/specfact-cli::]\\n\\n

\\n\\n

\\n

🔇 Additional comments (5)

\\n\\n
\\n
openspec/changes/security-03-module-pii-gdpr-eu/tasks.md (1)
\\n\\n`21-21`: **Good clarification on signature handling.**\\n\\nThis wording correctly prevents manual signature commits and keeps pre-merge focus on enforcement gates. \\nBased on learnings, \\\"module tarball signatures ... are generated by the `publish-modules` GitHub Actions runner during the publish workflow, not committed locally to the branch.\\\"\\n\\n
\\n
\\n
openspec/changes/security-02-module-license-compliance/proposal.md (1)
\\n\\n`15-54`: **Adapter boundary and compatibility direction look solid now.**\\n\\nGood improvement: the contract is explicit (schema + SPDX mapping), and inter-bundle guidance cleanly separates `core_compatibility` from bundle dependency semantics.\\n\\n
\\n
\\n
packages/specfact-code-review/src/specfact_code_review/run/findings.py (3)
\\n\\n`6-6`: **No actionable issue in this import change.**\\n\\nNo functional or boundary-impacting problem found in Line 6.\\n\\n---\\n\\n`150-150`: **No actionable issue in this return-line change.**\\n\\nBehavior remains correct and aligned with report blocking semantics.\\n\\n---\\n\\n`76-79`: **Good boundary upgrade with typed `evidence_refs`.**\\n\\nThis change materially improves contract stability versus raw dict payloads while keeping existing producers backward compatible.\\n\\n
\\n\\n

\\n\\n

\\n\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n> [!NOTE]\\n> Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it.\\n\\n## Fixes Applied Successfully\\n\\nFixed 3 file(s) based on 3 unresolved review comments.\\n\\n\\n\\n**Files modified:**\\n- `openspec/changes/architecture-02-module-well-architected/design.md`\\n- `openspec/changes/security-02-module-license-compliance/proposal.md`\\n- `packages/specfact-code-review/src/specfact_code_review/run/findings.py`\\n\\n**Commit:** `0d933ea37b42ce7b6c515236b5f5cb0e42c6d721`\\n\\nThe changes have been pushed to the `promote/pr-236-to-main` branch.\\n\\n**Time taken:** `6m 5s`\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix the module signature mismatch and verify quality gates are green and update the source branch directly\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"### Summary\\n* Fixed the module signature/checksum mismatch by updating the `integrity.checksum` for `specfact-code-review` and `specfact-project` manifests to match current payloads. [packages/specfact-code-review/module-package.yamlL25-L26](https://github.com/nold-ai/specfact-cli-modules/blob/0d933ea37b42ce7b6c515236b5f5cb0e42c6d721/packages/specfact-code-review/module-package.yaml#L25-L26) [packages/specfact-project/module-package.yamlL29-L30](https://github.com/nold-ai/specfact-cli-modules/blob/0d933ea37b42ce7b6c515236b5f5cb0e42c6d721/packages/specfact-project/module-package.yaml#L29-L30)\\n* Bumped `specfact-code-review` bundle version from `0.47.13` to `0.47.14` to satisfy version-bump enforcement for changed module payloads. [packages/specfact-code-review/module-package.yamlL1-L2](https://github.com/nold-ai/specfact-cli-modules/blob/0d933ea37b42ce7b6c515236b5f5cb0e42c6d721/packages/specfact-code-review/module-package.yaml#L1-L2)\\n* Committed directly to the source branch with commit `8a086a6` and prepared a PR message via the `make_pr` tool as requested.\\n\\n**Testing**\\n* ✅ `python scripts/sign-modules.py --changed-only --base-ref 11f3f61601cdad85d2dd0e853a69a0e1ab4e687d --payload-from-filesystem --allow-unsigned --bump-version patch`\\n* ⚠️ `python scripts/verify-modules-signature.py --payload-from-filesystem --enforce-version-bump` (changed bundles pass; full repo verification needs public key material for other signed bundles in this environment)\\n* ✅ `python scripts/verify-modules-signature.py --metadata-only --enforce-version-bump`\\n* ⚠️ `python -m pytest tests/unit/specfact_code_review/run/test_findings.py -q` (environment dependency limitations during collection: missing project runtime deps beyond baseline install)\\n\\n [View task →](https://chatgpt.com/s/cd_69e74df0b0388191a906b9317b9b8bd0)\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@cursor please fix the signature mismatch and verify\\n\\n2026-04-21T08:57:03.4014114Z FAIL packages/specfact-code-review/module-package.yaml: checksum mismatch\\n2026-04-21T08:57:03.4014930Z FAIL packages/specfact-project/module-package.yaml: checksum mismatch\\n2026-04-21T08:57:03.4015878Z FAIL packages/specfact-code-review/module-package.yaml: module version was not incremented (still 0.47.13) compared to origin/main\\n2026-04-21T08:57:03.4017880Z OK packages/specfact-backlog/module-package.yaml\\n2026-04-21T08:57:03.4018435Z OK packages/specfact-codebase/module-package.yaml\\n2026-04-21T08:57:03.4018942Z OK packages/specfact-govern/module-package.yaml\\n2026-04-21T08:57:03.4019410Z OK packages/specfact-spec/module-package.yaml\\n2026-04-21T08:57:03.4235640Z ##[error]Process completed with exit code 1.\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"You need to increase your spend limit or enable usage-based billing to run background agents. [Go to Cursor](https://cursor.com/github-bg-connected)\",\"path\":null,\"side\":null,\"line\":null}","text_elements",[],{"_474":1059,"_461":462,"_476":464},{"_477":1060,"_479":-5,"_41":-5,"_480":-5,"_95":324,"_91":482},[1061],{"_45":1055,"_91":1062},"input_text","turn/started",{"_461":462,"_86":1065},{"_102":-5,"_41":464,"_465":1066,"_467":1067},[],"inProgress",{"_467":1069,"_461":462},{"_1070":1071,"_91":1072},"activeFlags",[],"active",{"_474":1074,"_461":462,"_476":1075},{"_477":1076,"_479":-5,"_41":-5,"_480":-5,"_95":324,"_91":482},"auto-compact-0",[1077,1078],{"_45":1080,"_91":1062},{"_45":1079,"_91":1062},"\n /workspace/specfact-cli-modules\n bash\n 2026-04-21\n Etc/UTC\n","# AGENTS.md instructions for /workspace/specfact-cli-modules\n\n\n# AGENTS.md\n\nThis file is the mandatory bootstrap governance surface for coding agents working in this repository. It is intentionally compact. The detailed rules that used to live here have been preserved in `docs/agent-rules/` so new sessions do not pay the full context cost up front.\n\n## Mandatory bootstrap\n\n1. Read this file.\n2. Read [docs/agent-rules/INDEX.md](docs/agent-rules/INDEX.md).\n3. Read [docs/agent-rules/05-non-negotiable-checklist.md](docs/agent-rules/05-non-negotiable-checklist.md).\n4. Detect repository root, active branch, and worktree state.\n5. Reject implementation from the `dev` or `main` checkout unless the user explicitly overrides that rule.\n6. If GitHub hierarchy metadata is needed and `.specfact/backlog/github_hierarchy_cache.md` is missing or stale, refresh it with `python scripts/sync_github_hierarchy_cache.py`.\n7. Load any additional rule files required by the applicability matrix in [docs/agent-rules/INDEX.md](docs/agent-rules/INDEX.md) before implementation.\n\n## Precedence\n\n1. Direct system and developer instructions\n2. Explicit user override where repository governance allows it\n3. This file\n4. [docs/agent-rules/05-non-negotiable-checklist.md](docs/agent-rules/05-non-negotiable-checklist.md)\n5. Other selected files under `docs/agent-rules/`\n6. Change-local OpenSpec artifacts and workflow notes\n\n## Non-negotiable gates\n\n- Work in a git worktree unless the user explicitly overrides that rule.\n- Do not implement from the `dev` or `main` checkout by default.\n- Treat a provided OpenSpec change id as candidate scope, not automatic permission to proceed.\n- Verify the selected change against current repository reality and dependency state before implementation.\n- Do not auto-refine stale or ambiguous changes without the user.\n- Perform `spec -> tests -> failing evidence -> code -> passing evidence` in that order for behavior changes.\n- Require public GitHub metadata completeness before implementation when linked issue workflow applies: parent, labels, project assignment, blockers, and blocked-by relationships.\n- If a linked GitHub issue is already `in progress`, pause and ask for clarification before implementation.\n- Run the required verification and quality gates for the touched scope before finalization.\n- Fix SpecFact code review findings, including warnings, unless a rare explicit exception is documented.\n- Treat the clean-code compliance gate as mandatory: the review surface enforces `naming`, `kiss`, `yagni`, `dry`, and `solid` categories and blocks regressions.\n- Enforce module signatures and version bumps when signed module assets or manifests are affected.\n- Finalize completed OpenSpec changes with `openspec archive ` (see [docs/agent-rules/40-openspec-and-tdd.md](docs/agent-rules/40-openspec-and-tdd.md)); do not manually move change folders under `openspec/changes/archive/`.\n\n## Strategic context\n\nThis public modules repository does not depend on a sibling internal wiki checkout for change design. Shared design and governance context lives in the paired public `specfact-cli` repository and the active OpenSpec artifacts in this repo. When a modules change is explicitly paired with a core change, review both public change folders before widening scope or redefining shared workflow semantics.\n\n## Canonical rule docs\n\n- [docs/agent-rules/INDEX.md](docs/agent-rules/INDEX.md)\n- [docs/agent-rules/05-non-negotiable-checklist.md](docs/agent-rules/05-non-negotiable-checklist.md)\n- [docs/agent-rules/10-session-bootstrap.md](docs/agent-rules/10-session-bootstrap.md)\n- [docs/agent-rules/20-repository-context.md](docs/agent-rules/20-repository-context.md)\n- [docs/agent-rules/30-worktrees-and-branching.md](docs/agent-rules/30-worktrees-and-branching.md)\n- [docs/agent-rules/40-openspec-and-tdd.md](docs/agent-rules/40-openspec-and-tdd.md)\n- [docs/agent-rules/50-quality-gates-and-review.md](docs/agent-rules/50-quality-gates-and-review.md)\n- [docs/agent-rules/60-github-change-governance.md](docs/agent-rules/60-github-change-governance.md)\n- [docs/agent-rules/70-release-commit-and-docs.md](docs/agent-rules/70-release-commit-and-docs.md)\n- [docs/agent-rules/80-current-guidance-catalog.md](docs/agent-rules/80-current-guidance-catalog.md)\n\nDetailed guidance was moved by reference, not removed. If a rule seems missing here, consult the canonical rule docs before assuming the instruction was dropped.\n\n\n## Skills\nA skill is a set of local instructions to follow that is stored in a `SKILL.md` file. Below is the list of skills that can be used. Each entry includes a name, description, and file path so you can open the source for full instructions when using a specific skill.\n### Available skills\n- skill-creator: Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Codex's capabilities with specialized knowledge, workflows, or tool integrations. (file: /opt/codex/skills/.system/skill-creator/SKILL.md)\n- skill-installer: Install Codex skills into $CODEX_HOME/skills from a curated list or a GitHub repo path. Use when a user asks to list installable skills, install a curated skill, or install a skill from another repo (including private repos). (file: /opt/codex/skills/.system/skill-installer/SKILL.md)\n### How to use skills\n- Discovery: The list above is the skills available in this session (name + description + file path). Skill bodies live on disk at the listed paths.\n- Trigger rules: If the user names a skill (with `$SkillName` or plain text) OR the task clearly matches a skill's description shown above, you must use that skill for that turn. Multiple mentions mean use them all. Do not carry skills across turns unless re-mentioned.\n- Missing/blocked: If a named skill isn't in the list or the path can't be read, say so briefly and continue with the best fallback.\n- How to use a skill (progressive disclosure):\n 1) After deciding to use a skill, open its `SKILL.md`. Read only enough to follow the workflow.\n 2) When `SKILL.md` references relative paths (e.g., `scripts/foo.py`), resolve them relative to the skill directory listed above first, and only consider other paths if needed.\n 3) If `SKILL.md` points to extra folders such as `references/`, load only the specific files needed for the request; don't bulk-load everything.\n 4) If `scripts/` exist, prefer running or patching them instead of retyping large code blocks.\n 5) If `assets/` or templates exist, reuse them instead of recreating from scratch.\n- Coordination and sequencing:\n - If multiple skills apply, choose the minimal set that covers the request and state the order you'll use them.\n - Announce which skill(s) you're using and why (one short line). If you skip an obvious skill, say why.\n- Context hygiene:\n - Keep context small: summarize long sections instead of pasting them; only load extra files when needed.\n - Avoid deep reference-chasing: prefer opening only files directly linked from `SKILL.md` unless you're blocked.\n - When variants exist (frameworks, providers, domains), pick only the relevant reference file(s) and note that choice.\n- Safety and fallback: If a skill can't be applied cleanly (missing files, unclear instructions), state the issue, pick the next-best approach, and continue.\n",{"_474":1082,"_461":462,"_476":1075},{"_477":1083,"_479":-5,"_41":-5,"_480":-5,"_95":1084,"_91":482},[1085],"developer",{"_45":1086,"_91":1062},"\nFilesystem sandboxing defines which files can be read or written. `sandbox_mode` is `danger-full-access`: No filesystem sandboxing - all commands are permitted. Network access is enabled.\nApproval policy is currently never. Do not provide the `sandbox_permissions` for any reason, commands will be rejected.\n","thread/started",{"_1089":1090},"thread",{"_1091":-5,"_1092":-5,"_1093":1094,"_1095":1096,"_518":519,"_1097":15,"_1098":-5,"_41":462,"_1099":1100,"_185":-5,"_163":1101,"_1102":203,"_1103":1104,"_467":1105,"_76":1106,"_1107":1096},"agentNickname","agentRole","cliVersion","0.114.0","createdAt",1776769138,"ephemeral","gitInfo","modelProvider","openai","/opt/codex/sessions/2026/04/21/rollout-2026-04-21T10-58-58-019dafb1-7e63-7b62-9c1a-9b711a943ba2.jsonl","preview","source","vscode",{"_91":471},[],"updatedAt",[],"messages",[1111],{"_41":1112,"_1113":1114,"_1115":1116,"_1117":1116,"_477":1118,"_467":1119,"_479":-5,"_1120":31,"_1121":1122,"_1123":1124,"_1125":-5},"c4446efa-2df3-4951-86dc-49cdb81d1e1a","author",{"_95":324,"_185":-5,"_1121":1134},"create_time",1776769137.852119,"update_time",{"_1130":45,"_1131":1132},"finished_successfully","weight","metadata",{"_1126":1127},"recipient","all","channel","l1239dk1",{"_1128":1129},"inline_comments",[],"content_type","parts",[1133],"@codex please fix checksum mismatch and verify with unsigned modules:\n\n2026-04-21T08:57:03.4014114Z FAIL packages/specfact-code-review/module-package.yaml: checksum mismatch\n2026-04-21T08:57:03.4014930Z FAIL packages/specfact-project/module-package.yaml: checksum mismatch\n2026-04-21T08:57:03.4015878Z FAIL packages/specfact-code-review/module-package.yaml: module version was not incremented (still 0.47.13) compared to origin/main\n2026-04-21T08:57:03.4017880Z OK packages/specfact-backlog/module-package.yaml\n2026-04-21T08:57:03.4018435Z OK packages/specfact-codebase/module-package.yaml\n2026-04-21T08:57:03.4018942Z OK packages/specfact-govern/module-package.yaml\n2026-04-21T08:57:03.4019410Z OK packages/specfact-spec/module-package.yaml\n2026-04-21T08:57:03.4235640Z ##[error]Process completed with exit code 1.\nPromote dev import runtime hardening to main\n\nThis PR promotes the current `dev` delta to `main` after PR #236 merged and the follow-up signing/publish automation completed.\n\nWhat changed\n- carries the import runtime hardening work from #236 into `main`\n- includes the resulting module signing and registry publish updates for `specfact-project`\n- includes the related OpenSpec and workflow updates already present on `dev`\n\nWhy\n- `#236` merged to `dev`, and this opens the corresponding promotion path to `main`\n\nValidation\n- PR #236 was merged and green on `dev`\n- the current promotion branch was fetched from the latest `origin/dev` before opening this PR\n\n\n---\n\n> [!NOTE]\n> **Medium Risk**\n> Updates the module-signing GitHub Action gating logic and changes `specfact-project` import traversal behavior via runtime patching and new ignore/pruning policy, which could affect CI behavior and which files are analyzed. Also bumps and republishes a signed module artifact in the registry, so a mistaken package payload or signature would impact consumers.\n> \n> **Overview**\n> Promotes the code import runtime hardening work: `specfact-project` now uses a shared discovery/ignore policy (default pruning of hidden/heavy artifact trees plus `.specfact/.specfactignore` support), surfaces large-artifact warnings/updated ETA semantics, and ensures analyzer progress totals reflect filtered analyzable files.\n> \n> Generator Jinja2 templates are now shipped as bundled resources (with runtime template-path resolution helpers and new payload/runtime tests), and `specfact-project` is version-bumped with updated signatures/registry metadata.\n> \n> The `sign-modules-on-approval` workflow is expanded to run on PR updates as well as reviews, uses GraphQL to confirm at least one trusted approval before signing on non-review events, and adjusts concurrency/env handling accordingly; related workflow tests and docs are updated.\n> \n> ^{Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 39750733a68cd1ac8b652b1c46abcc51d84aff60. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).}\n\n\n\n\n> [!NOTE]\n> ## Reviews paused\n> \n> It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the `reviews.auto_review.auto_pause_after_reviewed_commits` setting.\n> \n> Use the following commands to manage reviews:\n> - `@coderabbitai resume` to resume automatic reviews.\n> - `@coderabbitai review` to trigger a single review.\n> \n> Use the checkboxes below for quick actions:\n> - [ ] ▶️ Resume reviews\n> - [ ] 🔍 Trigger review\n\n\n\n\n

📝 Walkthrough

\n\n## Walkthrough\n\nExtended modules ecosystem with 11 new OpenSpec change sets and docs; added import-runtime hardening (pre-traversal pruning, `.specfact/.specfactignore`, heavy-tree warnings, provisional ETA), runtime patches limiting discovery, packaged Jinja2 templates and resolver helpers, tests, registry/module-version bumps, and an enhanced GitHub Actions signing workflow using GraphQL review checks.\n\n## Changes\n\n|Cohort / File(s)|Summary|\n|---|---|\n|**GitHub Actions workflow & tests**
`/.github/workflows/sign-modules-on-approval.yml`, `tests/unit/workflows/test_sign_modules_on_approval.py`|Workflow triggers extended to `pull_request` (opened/synchronize/reopened/ready_for_review) alongside `pull_request_review.submitted`; concurrency/grouping and PR ref env vars made resilient; eligibility gate now queries PR `latestReviews` via `gh api` for trusted APPROVED reviews; `GH_TOKEN` added to gate environment.|\n|**OpenSpec change sets**
`openspec/CHANGE_ORDER.md`, `openspec/changes/...` (multiple new dirs)|Added 11 OpenSpec change directories (architecture, enterprise, finops, knowledge, review-resiliency, security, etc.) with `.openspec.yaml` plus design/proposal/specs/tasks documents and CHANGE_ORDER updates.|\n|**Import discovery & policy**
`packages/specfact-project/src/specfact_project/utils/import_path_policy.py`, `tests/unit/specfact_project/test_import_runtime_policy.py`|New import discovery API and dataclasses, `.specfact/.specfactignore` loading, pre-traversal pruning, heavy-ignored warnings, provisional ETA computation, and unit tests covering pruning, entry-point handling, thresholds and ignore semantics.|\n|**Runtime patch layer**
`packages/specfact-project/src/specfact_project/import_runtime_patches.py`, `packages/specfact-project/src/specfact_project/import_cmd/commands.py`, `packages/specfact-project/src/specfact_project/sync/commands.py`|Introduced idempotent runtime patches that intercept `Path.rglob`, patch analyzer/counting functions, suppress timing chatter, and limit discovery for heavy phases; patches are applied at command startup (`from_code`, `sync_repository`).|\n|**Template resolution & packaged templates**
`packages/specfact-project/src/specfact_project/generators/template_paths.py`, `.../plan_generator.py`, `.../protocol_generator.py`, `.../workflow_generator.py`, `packages/specfact-project/resources/templates/*`|Added template resolver helpers (`resolve_project_templates_dir` and aliases); generators use resolvers; added packaged Jinja2 templates (`github-action.yml.j2`, `protocol.yaml.j2`, `persona/default.md.j2`) and tests verifying runtime resolution and tarball contents.|\n|**Bundle metadata & registry**
`packages/specfact-project/module-package.yaml`, `registry/index.json`, `registry/modules/specfact-project-0.41.{4,5,6}.tar.gz.sha256`, `registry/signatures/specfact-project-0.41.{5,6}.tar.sig`|Bumped `specfact-project` bundle version to `0.41.6`; updated integrity/checksum/signature fields and registry download URLs/checksums/signatures; added intermediate checksum/signature files.|\n|**Generators & persona templates tests**
`packages/specfact-project/src/specfact_project/generators/*`, `tests/unit/test_bundle_resource_payloads.py`|Generators now resolve templates at runtime; new tests validate generated protocol YAML, GitHub workflow generation, persona template presence, and artifact packaging.|\n|**Scripts / GitHub hierarchy**
`scripts/ensure_github_hierarchy_subissues.py`|Added script to enforce predefined Epic→Feature sub-issue edges via `gh api graphql` with dry-run support, caching and robust error handling.|\n|**Documentation**
`docs/bundles/project/import-migration.md`|Docs updated to describe default ignore policy, discovery/ETA semantics after pruning, repo-local `.specfact/.specfactignore` overrides, heavy-artifact warnings, and treating ETA as provisional.|\n|**Findings model extension**
`packages/specfact-code-review/src/specfact_code_review/run/findings.py`|Added `EvidenceRef` model and optional `evidence_refs` field to `ReviewFinding` for structured evidence references.|\n\n## Sequence Diagram(s)\n\n```mermaid\nsequenceDiagram\n autonumber\n participant PR as Pull Request Event\n participant WF as Workflow (sign-modules-on-approval)\n participant GH as GitHub API (GraphQL)\n participant Signer as Module Signer\n\n rect rgba(100, 150, 200, 0.5)\n Note over PR,WF: pull_request (opened/synchronize/reopened/ready_for_review)\n end\n\n PR->>WF: trigger on pull_request\n WF->>WF: set concurrency.group using github.event.pull_request.number or github.event.number\n WF->>WF: resolve PR_BASE_REF / PR_HEAD_REF with fallbacks\n WF->>WF: if github.event_name == \"pull_request\" then\n WF->>GH: gh api graphql: query latestReviews(first:100) for PR\n GH-->>WF: return reviews (states + authorAssociation)\n WF->>WF: compute trusted APPROVED review existence\n alt trusted APPROVED exists\n WF->>Signer: sign=true\n else\n WF->>Signer: sign=false\n end\n\n rect rgba(150, 200, 100, 0.5)\n Note over PR,WF: pull_request_review (submitted)\n end\n\n PR->>WF: trigger on pull_request_review\n WF->>WF: use event.review.state and author_association\n alt review.state == \"approved\" and trusted author\n WF->>Signer: sign=true\n else\n WF->>Signer: sign=false\n end\n```\n\n```mermaid\nsequenceDiagram\n autonumber\n participant CLI as Command (from_code / sync_repository)\n participant Patches as import_runtime_patches.apply_import_runtime_patches\n participant Discovery as discover_code_files\n participant Analyzer as CodeAnalyzer\n participant Console as console.print\n\n rect rgba(100, 150, 200, 0.5)\n Note over CLI,Patches: Patch installation at command start\n end\n\n CLI->>Patches: apply_import_runtime_patches()\n Patches->>Patches: install rglob interception & analyzer wrappers\n Patches->>Console: wrap console.print to filter timing chatter\n\n rect rgba(150, 200, 100, 0.5)\n Note over Discovery,Analyzer: Discovery + Patched Analysis\n end\n\n Patches->>Discovery: discover_code_files(repo_root, options)\n Discovery->>Discovery: load .specfactignore, prune heavy dirs, compute provisional ETA\n Discovery-->>Patches: return ImportDiscoveryResult(files, warnings, eta)\n Patches->>Console: emit runtime warnings if needed\n Patches->>Analyzer: execute analyze() under patched rglob (filtered file set)\n Analyzer-->>CLI: analysis results\n```\n\n## Estimated code review effort\n\n🎯 4 (Complex) | ⏱️ ~65 minutes\n\n## Possibly related issues\n\n- nold-ai/specfact-cli-modules#235 — Code-import runtime hardening: matches the new import discovery, template packaging, runtime patches and tests added here. \n- nold-ai/specfact-cli-modules#234 — Discovery pruning & `.specfactignore` semantics: aligns with import_path_policy and discovery/ETA changes. \n- nold-ai/specfact-cli-modules#236 — Import/runtime + workflow overlap: related to template resolution, generators and signing workflow edits present in this PR. \n- nold-ai/specfact-cli-modules#231 — Enterprise Policy Client module: related to the added enterprise policy OpenSpec docs/specs in this PR. \n- nold-ai/specfact-cli-modules#230 — Architecture well-architected module: corresponds to the added architecture OpenSpec files. \n- nold-ai/specfact-cli-modules#225 — Knowledge Writeback Module: matches the knowledge writeback openspec content added.\n\n## Possibly related PRs\n\n- nold-ai/specfact-cli-modules#236 — Closely related: overlaps import runtime hardening, template resolution, generators, tests and sign-workflow edits. \n- nold-ai/specfact-cli-modules#233 — Related: similar OpenSpec additions and the GitHub hierarchy script. \n- nold-ai/specfact-cli-modules#188 — Prior sign-modules-on-approval workflow work; this PR extends that workflow with PR triggers and GraphQL review checks.\n\n## Suggested labels\n\n`bug`\n\n

\n\n\n\n\n\n\n

✨ Finishing Touches

\n\n

🧪 Generate unit tests (beta)

\n\n- [ ] Create PR with unit tests\n- [ ] Commit unit tests in branch `promote/pr-236-to-main`\n\n

\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\nCursor Bugbot has reviewed your changes and found 2 potential issues.\n\n\n\n\n

\n\n\n\n^{Bugbot Autofix is [ON](https://www.cursor.com/dashboard/bugbot). A cloud agent has been kicked off to fix the reported issues.}\n\n\n^{Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 39750733a68cd1ac8b652b1c46abcc51d84aff60. Configure [here](https://www.cursor.com/dashboard/bugbot).}\n### Relative entry_point resolved against wrong base directory\n\n**Medium Severity**\n\n\n`_patched_rglob` resolves a relative `entry_point` via `entry_point.resolve()` (against CWD), but `_resolve_entry_point` in `import_path_policy.py` resolves relative paths against `repo_root` using `(resolved_repo_root / entry_point).resolve()`. When CWD differs from `repo_root`, `resolved_entry_point` in the rglob patch won't match the path that `Path.rglob` is actually called on, so the patch silently falls through to the original unfiltered `rglob` — defeating the entire ignore-policy filtering for entry-point-scoped imports.\n\n\n\n\n\n

Additional Locations (1)

\n\n- [`packages/specfact-project/src/specfact_project/utils/import_path_policy.py#L84-L97`](https://github.com/nold-ai/specfact-cli-modules/blob/39750733a68cd1ac8b652b1c46abcc51d84aff60/packages/specfact-project/src/specfact_project/utils/import_path_policy.py#L84-L97)\n\n

\n\n

\n\n\n^{Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 39750733a68cd1ac8b652b1c46abcc51d84aff60. Configure [here](https://www.cursor.com/dashboard/bugbot).}\n\n### Exported functions `resolve_runtime_template_dir` and `should_skip_path` unused\n\n**Low Severity**\n\n\n`resolve_runtime_template_dir` in `template_paths.py` and `should_skip_path` in `import_path_policy.py` are newly added public functions that are never called anywhere in the codebase. Both are thin wrappers around existing functions (`resolve_project_templates_dir` and `should_ignore_path` respectively) adding no unique logic. Grep confirms each is only referenced at its own definition.\n\n\n\n\n\n

Additional Locations (1)

\n\n- [`packages/specfact-project/src/specfact_project/utils/import_path_policy.py#L246-L263`](https://github.com/nold-ai/specfact-cli-modules/blob/39750733a68cd1ac8b652b1c46abcc51d84aff60/packages/specfact-project/src/specfact_project/utils/import_path_policy.py#L246-L263)\n\n

\n\n

\n\n\n^{Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 39750733a68cd1ac8b652b1c46abcc51d84aff60. Configure [here](https://www.cursor.com/dashboard/bugbot).}\n\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Add pull-request read permission for approval query**\n\nThe eligibility gate now calls `gh api graphql` on `pull_request` events to read `latestReviews`, but this workflow only grants `contents: write`. In GitHub Actions, unspecified token scopes are denied, so same-repo PR events can fail this step with `Resource not accessible by integration` before the script can emit `sign=false`, turning a skip path into a hard failing required check. Add at least `pull-requests: read` (or equivalent read scope) in `permissions` so the GraphQL review lookup can run reliably.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `39750733a6`\n \n\n

ℹ️ About Codex in GitHub

\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n

\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Optional: Replace \"very large\" with specific metrics.**\n\nStatic analysis flagged \"very large\" as an over-used intensifier. Consider specifying approximate thresholds to help users calibrate expectations.\n\n\n\n

📝 Suggested clarification

\n\n```diff\n-- When import encounters unusually large ignored artifact trees or a very large filtered repository, it emits warnings instead of promising that the run will finish in a specific number of minutes.\n-- Remaining time is based on processed-versus-discovered work at the current runtime rate, so early estimates should be treated as provisional on very large repositories.\n+- When import encounters unusually large ignored artifact trees (e.g., >10,000 files) or filtered repositories with >100,000 remaining files, it emits warnings instead of promising a specific completion time.\n+- Remaining time is based on processed-versus-discovered work at the current runtime rate, so early estimates should be treated as provisional on repositories with extensive file counts.\n```\n\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🧰 Tools

\n\n

🪛 LanguageTool

\n\n[style] ~39-~39: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.\nContext: ...usually large ignored artifact trees or a very large filtered repository, it emits warnings ...\n\n(EN_WEAK_ADJECTIVE)\n\n---\n\n[style] ~40-~40: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.\nContext: ...tes should be treated as provisional on very large repositories. ### Repo-local Ignore Ov...\n\n(EN_WEAK_ADJECTIVE)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@docs/bundles/project/import-migration.md` around lines 39 - 40, Replace the\nvague phrase \"very large\" in the two sentences that start with \"When import\nencounters unusually large ignored artifact trees...\" and \"Remaining time is\nbased on processed-versus-discovered work...\" with concrete thresholds; for\nexample, change to \"ignored artifact trees with >10,000 entries or repositories\nlarger than ~100,000 files, ~10 GB of repository data, or >100,000 commits\" and\nnote that estimates remain provisional for repos above those thresholds—adjust\nthe numeric thresholds to align with product telemetry if different.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Resolve duplicate `Order` value in the security track.**\n\nLine 94 and Line 95 both assign `Order | 04` under `security`, which makes execution sequencing ambiguous in `CHANGE_ORDER`.\n\n

Suggested doc fix

\n\n```diff\n-| security | 04 | security-03-module-pii-gdpr-eu | [`#229`](https://github.com/nold-ai/specfact-cli-modules/issues/229) | Parent Epic: [`#216`](https://github.com/nold-ai/specfact-cli-modules/issues/216); Parent Feature: [`#218`](https://github.com/nold-ai/specfact-cli-modules/issues/218); core umbrella [specfact-cli#511](https://github.com/nold-ai/specfact-cli/issues/511); `security-01-module-sast-sca-secret`; paired core changes `security-01-unified-findings-model` and `security-02-eu-gdpr-baseline` |\n+| security | 05 | security-03-module-pii-gdpr-eu | [`#229`](https://github.com/nold-ai/specfact-cli-modules/issues/229) | Parent Epic: [`#216`](https://github.com/nold-ai/specfact-cli-modules/issues/216); Parent Feature: [`#218`](https://github.com/nold-ai/specfact-cli-modules/issues/218); core umbrella [specfact-cli#511](https://github.com/nold-ai/specfact-cli/issues/511); `security-01-module-sast-sca-secret`; paired core changes `security-01-unified-findings-model` and `security-02-eu-gdpr-baseline` |\n```\n

\n\nAs per coding guidelines, `openspec/**/*.md` must preserve specification truth for proposal/order semantics and avoid drift in CHANGE_ORDER.\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/CHANGE_ORDER.md` around lines 94 - 95, The two entries for\nsecurity-02-module-license-compliance and security-03-module-pii-gdpr-eu both\nuse Order | 04; update the Order on one of them (e.g., change\nsecurity-03-module-pii-gdpr-eu to Order | 05 or otherwise assign a unique,\nsequential number) so every `security` entry has a distinct Order value and the\nCHANGE_ORDER semantics remain consistent across the spec.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🔴 Critical_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Description: Verify architecture-02-well-architected-review exists in specfact-cli\n\nrg -n --type=md -C3 'architecture-02-well-architected-review' || echo \"Core dependency not found in current context\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 6513\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for architecture-02-well-architected-review in specfact-cli\nrg -n --type=md 'architecture-02-well-architected-review' 2>/dev/null | head -20 || echo \"No matches found\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 46\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check if there's a CHANGE_ORDER or change tracking file that references this\nfind . -name \"CHANGE_ORDER*\" -o -name \"*architecture*\" -type f | grep -E '\\.(md|yaml|yml)$' | head -15\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 148\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read the CHANGE_ORDER.md to see architecture-related changes\nhead -150 ./openspec/CHANGE_ORDER.md | tail -100\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 8290\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for any occurrence of \"architecture\" and \"review\" in CHANGE_ORDER.md\ngrep -n -i \"architecture\" ./openspec/CHANGE_ORDER.md | head -20\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 3186\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Broader search for \"well-architected\" or similar pattern in specfact-cli\nrg -i \"well-architected\" . 2>/dev/null || echo \"No matches found\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 80\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check if there's any reference to module boundary rules or review contracts under architecture-01\ngrep -A10 -B2 \"architecture-01-solution-layer\" ./openspec/CHANGE_ORDER.md\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 3409\n\n---\n\n\n\n

\n\n**Paired core architecture contract `architecture-02-well-architected-review` not found in `specfact-cli`.**\n\nThe design document references a paired core change `architecture-02-well-architected-review` as a prerequisite for module integration. However, this contract is not tracked in the core repository. The only architecture work in `specfact-cli` is `architecture-01-solution-layer` (paired with modules#164), which focuses on core solution-layer contracts. Before proceeding with implementation, clarify whether:\n- The core contract exists under a different name or folder in `specfact-cli`\n- `architecture-01-solution-layer` provides the required boundary rules and adapter contracts for this module\n- A new core change (`architecture-02-well-architected-review`) needs to be created or synced into `specfact-cli`\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\n50, The document references a paired core contract named\narchitecture-02-well-architected-review that isn't present in specfact-cli;\nupdate the design to either (a) point to the existing core contract if it exists\nunder a different name or folder (search for architecture-01-solution-layer and\nother architecture-* entries in the specfact-cli repo), (b) confirm and document\nthat architecture-01-solution-layer supplies the required boundary rules and\nadapter contracts for this module, or (c) add a note that a new core change\narchitecture-02-well-architected-review must be created/synced into specfact-cli\nbefore module integration—ensure the doc references the exact core contract name\nyou verified and mention architecture-01-solution-layer when clarifying overlap.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🛠️ Refactor suggestion_ | _🟠 Major_\n\n**Define the findings/evidence adapter boundary.**\n\nLines 10-12 describe packaged analyzers and report surfaces but don't specify the adapter contract that normalizes boundary violations and ADR findings into the paired core review contract. Without a clear adapter boundary, implementations may drift from the core schema.\n\n\nConsider adding an \"Adapter Contract\" subsection under \"What Changes\" that defines:\n- The core findings schema fields this bundle must populate\n- How analyzer output maps to normalized evidence references\n- Whether findings emission is synchronous or deferred\n\n

🧰 Tools

\n\n

🪛 LanguageTool

\n\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ...ity, and interface-diff evaluation. - **NEW**: Encode the `ALLOWED_IMPORTS.md` patt...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` around\nlines 10 - 12, Add an \"Adapter Contract\" subsection under \"What Changes\" that\ndefines the normalized boundary between analyzers and the core review contract:\nlist the required core findings schema fields this bundle must populate (e.g.,\nid, type, severity, description, source, timestamp, evidence_refs), specify how\noutputs from the packaged analyzers (dependency-graph checks, ADR traceability,\ninterface-diff) map to normalized evidence references and fields (reference\nexample mappings for ALLOWED_IMPORTS.md violations → evidence_refs, ADR entries\n→ source/trace links), and state the emission mode (synchronous vs deferred\nbatching) and retry/ordering semantics for findings emission so implementers\nknow expected behavior.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🛠️ Refactor suggestion_ | _🟠 Major_\n\n**Specify `core_compatibility` requirements for the reserved manifest.**\n\nWhile the proposal reserves manifest/registry/docs/signing work, it doesn't define the expected `core_compatibility` version range for `architecture-02-well-architected-review`. Explicit version constraints help prevent runtime incompatibilities between the bundle and core.\n\n\n

📋 Proposed addition to clarify compatibility metadata

\n\n```diff\n-- **EXTEND**: Reserve manifest, registry, docs, and signing work for a new official architecture bundle.\n+- **EXTEND**: Reserve manifest, registry, docs, and signing work for a new official architecture bundle, including `core_compatibility` entries for `architecture-02-well-architected-review` (minimum required core version to be determined during implementation).\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` at line\n13, Add an explicit core_compatibility field and semantic version range for the\nreserved manifest \"architecture-02-well-architected-review\" so consumers and the\ncore can validate compatibility; update the proposal text to state the required\ncore version range (e.g., a semver range such as \">=X.Y.Z \n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a top-level H1 as the first line.**\n\nThe file starts with `## Context`; markdownlint MD041 requires the first line to be a level-1 heading.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 1-1: First line in a file should be a top-level heading\n\n(MD041, first-line-heading, first-line-h1)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/codebase-import-runtime-hardening/design.md` at line 1, The\ndocument begins with a level-2 heading (\"## Context\") which violates\nmarkdownlint MD041; add a top-level H1 as the very first line (for example \"#\nDesign\" or another project-appropriate title) before the existing \"## Context\"\nheading so the file starts with a level-1 heading and MD041 is satisfied.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Insert blank lines after section headings to satisfy MD022.**\n\nHeadings at these lines are missing the required surrounding blank-line spacing.\n\n\n\nAlso applies to: 38-38, 48-48, 58-58\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 24-24: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/codebase-import-runtime-hardening/design.md` at line 24, Add\na blank line after each section heading to satisfy MD022: insert an empty line\nimmediately after \"Decision 1: Introduce a shared import path policy helper\" and\nlikewise after the other headings referenced (the headings at the other noted\nlocations), ensuring each heading is followed by a single blank line before the\nparagraph content.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Use a top-level H1 before the requirement delta section.**\n\nStarting at H2 triggers MD041 and can fail docs lint gates.\n\n

Suggested change

\n\n```diff\n+# Bundle packaged resources specification delta\n+\n ## MODIFIED Requirements\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 1-1: First line in a file should be a top-level heading\n\n(MD041, first-line-heading, first-line-h1)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\nat line 1, Add a top-level H1 heading before the \"## MODIFIED Requirements\"\nsection to avoid triggering MD041; specifically insert an H1 like \"# Requirement\nChanges\" or \"# Changelog\" immediately above the existing \"## MODIFIED\nRequirements\" header so the document begins with an H1 before any H2s (update\nthe heading text as appropriate for the spec).\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Fix heading-structure lint warnings (MD041/MD022).**\n\nLine 1 starts at `##` and multiple headings are missing required surrounding blank lines, which leaves documented markdownlint warnings unresolved.\n\n

Suggested markdown cleanup

\n\n```diff\n-## ADDED Requirements\n+# Codebase Import Runtime Hardening\n+\n+## ADDED Requirements\n \n ### Requirement: Import runtime SHALL prune hidden and heavyweight trees before discovery\n+\n `specfact code import` SHALL apply one deterministic ignore policy before any repository traversal phase counts, discovers, or analyzes candidate files. The default policy SHALL exclude dot-prefixed directories, virtual environments, build outputs, dependency caches, and other heavyweight artifact roots unless the user explicitly targets a path inside them.\n \n #### Scenario: Default traversal skips hidden and heavyweight directories\n+\n - **WHEN** the user runs `specfact code import` against a repository root that contains directories such as `.git/`, `.specfact/`, `.venv/`, `venv/`, `node_modules/`, `build/`, `dist/`, or `__pycache__/`\n ...\n```\n

\n\n\nBased on learnings: Fix SpecFact code review findings, including warnings, unless a rare explicit exception is documented.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 1-1: First line in a file should be a top-level heading\n\n(MD041, first-line-heading, first-line-h1)\n\n---\n\n[warning] 3-3: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n---\n\n[warning] 6-6: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n---\n\n[warning] 11-11: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n---\n\n[warning] 16-16: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n---\n\n[warning] 19-19: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n---\n\n[warning] 24-24: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n---\n\n[warning] 29-29: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n---\n\n[warning] 32-32: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n---\n\n[warning] 37-37: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\naround lines 1 - 40, The markdown has lint warnings from missing blank lines\naround headings (MD041/MD022); edit the section headings such as \"ADDED\nRequirements\", \"Requirement: Import runtime SHALL prune hidden and heavyweight\ntrees before discovery\", \"Scenario: Default traversal skips hidden and\nheavyweight directories\", \"Requirement: Import runtime SHALL surface\nlarge-artifact warnings\", and \"Requirement: Import progress SHALL use\ndiscovered-versus-processed work\" to ensure there is a single blank line above\nand below each heading and between consecutive headings/paragraphs so each\nheading is properly separated and no multiple consecutive headings lack\nintervening blank lines; keep the existing heading text and indentation but\ninsert the required blank lines consistently throughout the document to resolve\nMD041/MD022.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟠 Major_\n\n**Clarify `.specfact/.specfactignore` loading before dot-dir pruning.**\n\nLine 4 says dot-prefixed directories are excluded by default, but Lines 12-14 require `.specfact/.specfactignore` to be merged for traversal. Please state the precedence explicitly so implementations don’t diverge.\n\n

Suggested clarification

\n\n```diff\n-`specfact code import` SHALL apply one deterministic ignore policy before any repository traversal phase counts, discovers, or analyzes candidate files. The default policy SHALL exclude dot-prefixed directories, virtual environments, build outputs, dependency caches, and other heavyweight artifact roots unless the user explicitly targets a path inside them.\n+`specfact code import` SHALL apply one deterministic ignore policy before any repository traversal phase counts, discovers, or analyzes candidate files. The runtime SHALL load `.specfact/.specfactignore` (when present) before recursive traversal, then apply the merged policy. The default policy SHALL exclude dot-prefixed directories, virtual environments, build outputs, dependency caches, and other heavyweight artifact roots unless the user explicitly targets a path inside them.\n```\n

\n\n\nAs per coding guidelines: `openspec/**/*.md`: Specification truth: proposal/tasks/spec deltas vs. bundle behavior, CHANGE_ORDER, and drift vs. shipped modules or docs.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 6-6: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n---\n\n[warning] 11-11: Headings should be surrounded by blank lines\nExpected: 1; Actual: 0; Below\n\n(MD022, blanks-around-headings)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\naround lines 4 - 14, Clarify the precedence: state that when `specfact code\nimport` runs the implementation MUST first load the deterministic default ignore\npolicy (which excludes dot-prefixed directories like `.git/`, `.specfact/`,\nvirtualenvs, `node_modules/`, etc.), then read and merge repository-local\npatterns from `.specfact/.specfactignore` into that policy (repository-local\npatterns augment and can override conflicting default patterns), and finally\napply any explicit user target paths which may re-include a path inside an\nignored root; ensure this explicit ordering (default -> merge\n`.specfact/.specfactignore` -> explicit target override) is added to the spec so\npruning happens before traversal and precedence is unambiguous.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a top-level H1 heading for MD041 compliance.**\n\nThe file begins with `## 1.` but OpenSpec task documents should start with an H1 (e.g., `# Tasks: codebase-import-runtime-hardening`) to satisfy markdownlint MD041 and maintain parity with other task files that include H1 headings.\n\n\n\n

Proposed fix

\n\n```diff\n+# Tasks: codebase-import-runtime-hardening\n+\n ## 1. GitHub readiness and change scaffolding\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 1-1: First line in a file should be a top-level heading\n\n(MD041, first-line-heading, first-line-h1)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/codebase-import-runtime-hardening/tasks.md` at line 1, Add a\ntop-level H1 heading to the document (replace the current leading \"## 1. GitHub\nreadiness and change scaffolding\" start) so the file begins with an H1 like \"#\nTasks: codebase-import-runtime-hardening\" to satisfy MD041 and match other task\nfiles; ensure the existing content remains unchanged after the new H1.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a top-level H1 to satisfy Markdown linting.**\n\nThis spec starts at H2, which triggers MD041 and can fail doc-quality gates.\n\n

Suggested change

\n\n```diff\n+# Enterprise policy client specification delta\n+\n ## ADDED Requirements\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 1-1: First line in a file should be a top-level heading\n\n(MD041, first-line-heading, first-line-h1)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\nat line 1, Add a top-level H1 above the existing H2 \"ADDED Requirements\" in the\nspec.md (e.g., \"Enterprise Policy Client\" or another concise title) so the\ndocument begins with an H1 to satisfy MD041; update the first line to a valid\nMarkdown H1 and ensure the existing H2 remains unchanged.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a top-level H1 to satisfy MD041.**\n\nLine 1 starts at H2 (`## Context`), which violates the configured markdown lint rule.\n\n

Suggested fix

\n\n```diff\n+# Enterprise audit client design\n+\n ## Context\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 1-1: First line in a file should be a top-level heading\n\n(MD041, first-line-heading, first-line-h1)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/enterprise-02-module-audit-client/design.md` at line 1, The\ndocument begins with an H2 (\"## Context\") which triggers MD041; add a top-level\nH1 above the existing \"## Context\" header (e.g., \"# Context\" or a suitable\nproject/title H1) so the file starts with an H1, leaving the existing \"##\nContext\" as-is to preserve structure.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🔴 Critical_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Description: Verify enterprise-02-rbac-and-audit-trail exists in specfact-cli\n\nrg -n --type=md -C3 'enterprise-02-rbac-and-audit-trail' || echo \"Core dependency not found in current context\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 7176\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for the paired core change in specfact-cli\nrg -n --type=md 'enterprise-02-rbac-and-audit-trail' -C2 || echo \"No matches found\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 80\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Look for CHANGE_ORDER or similar tracking doc for core changes\nfind . -name \"CHANGE_ORDER*\" -o -name \"*change*order*\" | head -10\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 90\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check for spec or proposal files mentioning enterprise audit\nfind . -type f -name \"*.md\" | xargs grep -l \"enterprise.*audit\" 2>/dev/null | head -10\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 121\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read specfact-cli CHANGE_ORDER to see what core changes are planned\ncat -n ./openspec/CHANGE_ORDER.md | head -150\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 12624\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for any enterprise references at all\nrg -n 'enterprise' --type=md\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 30644\n\n---\n\n\n\n

\n\n**Paired core change `enterprise-02-rbac-and-audit-trail` does not exist in specfact-cli.**\n\nThe modules spec at line 7 declares a hard dependency on `enterprise-02-rbac-and-audit-trail` for enterprise RBAC, audit trail, and audit-event contracts. Verification of specfact-cli's CHANGE_ORDER.md (current through April 2026) found no such core change proposed, merged, or scheduled. This spec cannot be implemented until the paired core change is proposed and merged into specfact-cli. Coordinate with specfact-cli maintainers to establish the core audit trail and RBAC contracts before implementing this bundle. If the core change is planned but not yet documented, update this spec's requirement to reference the correct issue or change proposal.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\nat line 7, The spec declares a hard core dependency on\nenterprise-02-rbac-and-audit-trail for the nold-ai/specfact-enterprise-audit\nbundle but that core change does not exist; update\nenterprise-audit-client/spec.md to remove or replace the nonexistent core change\nreference in the core_compatibility and dependency text (replace\nenterprise-02-rbac-and-audit-trail with the correct existing change ID or a TODO\nplaceholder), and add a note that implementation is blocked until the paired\ncore change is proposed/merged and the spec's core_compatibility entry is\nupdated.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Strong cross-change coordination, but clarify telemetry dependency type.**\n\nLine 7 correctly references `CHANGE_ORDER.md` for coordination with `telemetry-01-opentelemetry-default-on`, demonstrating awareness of cross-change dependencies. However, the parenthetical doesn't clarify whether `telemetry-01` is a `bundle_dependencies` entry, a `core_compatibility` requirement, or just a sequencing constraint.\n\n\n

📋 Proposed clarification

\n\n```diff\n-The modules repository SHALL provide a signed official bundle named `nold-ai/specfact-finops` that exposes the `finops` command and declares truthful bundle dependencies, pip dependencies, and `core_compatibility` for the paired core FinOps evidence contract from `finops-01-telemetry-and-outcomes` (including any telemetry prerequisites coordinated with `telemetry-01-opentelemetry-default-on` as documented in `openspec/CHANGE_ORDER.md`).\n+The modules repository SHALL provide a signed official bundle named `nold-ai/specfact-finops` that exposes the `finops` command and declares truthful bundle dependencies, pip dependencies, and `core_compatibility` for the paired core FinOps evidence contract from `finops-01-telemetry-and-outcomes`. If telemetry integration is required, the bundle SHALL declare `core_compatibility` for `telemetry-01-opentelemetry-default-on` as coordinated in `openspec/CHANGE_ORDER.md`.\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\nat line 7, The spec references coordination with\ntelemetry-01-opentelemetry-default-on but doesn't state whether that change is a\nbundle dependency, a core_compatibility requirement, or only a sequencing\nconstraint; update the sentence for nold-ai/specfact-finops to explicitly state\nhow telemetry-01-opentelemetry-default-on is represented (e.g., add it to\nbundle_dependencies, list it under core_compatibility, or note it as a\nsequencing prerequisite) and ensure the manifest fields mentioned\n(`bundle_dependencies`, `pip dependencies`, `core_compatibility`) clearly\nindicate where telemetry-01 appears and that CHANGE_ORDER.md is the\nauthoritative source for sequencing.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Clarify “update signatures” to avoid implying manual signature commits.**\n\nPlease tighten wording to indicate signatures are validated in gates and generated by publish automation, not hand-updated in the branch.\n\nBased on learnings, module tarball signatures in this repository are generated by the publish workflow runner and should not be treated as locally committed pre-merge artifacts.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/finops-01-module-cost-outcome/tasks.md` at line 19, Edit the\ntask bullet that currently reads \"3.4 Update registry metadata, docs references,\nsignatures, and any import allowlists required by the new bundle.\" to clarify\nthat \"signatures\" are validated by gates and created by the publish automation\nrather than manually committed; e.g., change the phrase to something like\n\"update registry metadata, docs references, and any import allowlists required\nby the new bundle (signatures are validated by CI gates and produced by publish\nautomation—not committed manually)\"; update the text near the 3.4 task in\ntasks.md accordingly.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🔴 Critical_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Description: Check for stable core knowledge schema and MemoryBackend protocol\n\nrg -n --type=py -C3 'class MemoryBackend|knowledge.*schema|distillation.*engine' || echo \"Core knowledge contracts not found in current context\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 125\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read the design.md file to understand context\ncat -n openspec/changes/knowledge-01-module-memory-runtime/design.md | head -80\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 3829\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for MemoryBackend and core knowledge schema in specfact-cli\nrg -n 'class MemoryBackend|MemoryBackend.*Protocol|knowledge.*schema|CoreKnowledge' -A5 -B2 --type=py || echo \"No matches found\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 80\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Also search for distillation and runtime integration patterns\nrg -n 'distillation.*engine|runtime.*integration|schema.*stable' -A3 -B2 --type=py --type=md || echo \"No matches found\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 8492\n\n---\n\n\n\n

\n\n**Flag missing or undiscovered MemoryBackend protocol contract in specfact-cli.**\n\nThe design assumes a \"paired core MemoryBackend protocol\" (line 3, goal on line 10), but searches in specfact-cli find no definition or public API for this protocol. Migration step 1—confirming schema and protocol stability—is a blocking dependency for the markdown-graph backend implementation. Before proceeding, coordinate with specfact-cli to either:\n- Publish the MemoryBackend protocol definition and confirm its stability, OR\n- Add this to the paired core change scope if not yet delivered.\n\nThis is a critical integration contract between the two repositories.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-01-module-memory-runtime/design.md` at line 48,\nThe design references a paired core MemoryBackend protocol that isn't published\nin specfact-cli; confirm and record this contract by coordinating with\nspecfact-cli to either (A) publish the MemoryBackend protocol definition and\nversion/stability statement (ensure the exported symbol is named MemoryBackend\nand its public API/JSON schema is documented), or (B) add the MemoryBackend\nprotocol to the paired core change scope and include its authoritative spec in\nthis repo's design document (update \"migration step 1\" to reference the exact\nprotocol artifact, version, and where it is published). Ensure the design.md\nexplicitly points to the published spec (or pairing ticket) and notes the\nrequired stability guarantee so the markdown-graph MemoryBackend integration can\nproceed.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Optional: Vary sentence structure to improve readability.**\n\nThe static analysis tool noted that lines 9-13 begin with repeated \"**NEW**:\" markers. While this is a valid formatting choice for a changelog-style proposal, consider varying the structure if readability becomes a concern.\n\n\n\nExample alternative:\n```diff\n - **NEW**: Add a `specfact-knowledge` bundle with `memory` subcommands for logging, searching, promoting, and distilling.\n - **NEW**: Package the markdown-graph backend as the default runtime implementation for evidence, learnings, and rules under `.specfact/memory/`.\n-- **NEW**: Define gitignore, repo-layout, and file-lifecycle expectations for evidence, learnings, rules, and generated graph metadata.\n-- **NEW**: Add search and status surfaces that expose the paired core `MemoryBackend` behavior without requiring a vector store.\n+- **DEFINE**: Gitignore, repo-layout, and file-lifecycle expectations for evidence, learnings, rules, and generated graph metadata.\n+- **EXPOSE**: Search and status surfaces that leverage the paired core `MemoryBackend` behavior without requiring a vector store.\n```\n\n

🧰 Tools

\n\n

🪛 LanguageTool

\n\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ...nd rules under `.specfact/memory/`. - **NEW**: Define gitignore, repo-layout, and f...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n---\n\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ...ules, and generated graph metadata. - **NEW**: Add search and status surfaces that ...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-01-module-memory-runtime/proposal.md` around lines\n9 - 13, Rephrase the repeated \"**NEW**:\" bullets to improve readability by\nvarying sentence structure: e.g., keep one \"**NEW**:\" header for the group and\nturn the rest into action-starting phrases (\"Add a `specfact-knowledge` bundle\nwith `memory` subcommands...\", \"Package the markdown-graph backend as the\ndefault runtime...\", \"Define gitignore, repo-layout, and file-lifecycle...\",\n\"Add search and status surfaces exposing `MemoryBackend` behavior...\") or\ncombine related items into a single sentence; target the lines mentioning\n`specfact-knowledge`, `memory` subcommands, `markdown-graph backend`,\n`.specfact/memory/`, and `MemoryBackend` when applying the edits.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🔴 Critical_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Description: Verify knowledge-01-distillation-engine exists in specfact-cli\n\nrg -n --type=md -C3 'knowledge-01-distillation-engine' || echo \"Core dependency not found in current context\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 4934\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for knowledge-01-distillation-engine in specfact-cli\n\n# Look for the change folder\nfind . -type d -name \"*knowledge-01-distillation-engine*\" 2>/dev/null\n\n# Search for references to the change\nrg -n \"knowledge-01-distillation-engine\" --type=md -C 2 || echo \"Search completed\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 80\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for openspec structure and knowledge-related changes\n\necho \"=== Check for openspec/changes directory ===\"\nfind . -type d -path \"*/openspec/changes*\" 2>/dev/null | head -20\n\necho -e \"\\n=== Search for any knowledge-related changes ===\"\nrg -i \"knowledge.*distill|distill.*knowledge\" --type=md || echo \"No matches\"\n\necho -e \"\\n=== Check CHANGE_ORDER or similar in specfact-cli ===\"\nfind . -name \"CHANGE_ORDER*\" -o -name \"*change*order*\" 2>/dev/null | head -10\n\necho -e \"\\n=== Check openspec root structure ===\"\nls -la openspec/ 2>/dev/null || echo \"No openspec directory\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 1863\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check CHANGE_ORDER for knowledge-01-distillation-engine\n\necho \"=== Search for knowledge in CHANGE_ORDER.md ===\"\nrg -n \"knowledge|distill\" openspec/CHANGE_ORDER.md -C 3\n\necho -e \"\\n=== Check overall structure of CHANGE_ORDER ===\"\nhead -100 openspec/CHANGE_ORDER.md\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 6073\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Comprehensive search for any knowledge-related content\n\necho \"=== All directories under openspec/changes ===\"\nls openspec/changes/ | grep -i knowledge || echo \"No knowledge directories\"\n\necho -e \"\\n=== Full CHANGE_ORDER text search for 'knowledge' (case-insensitive) ===\"\ngrep -i \"knowledge\" openspec/CHANGE_ORDER.md || echo \"No knowledge mentions\"\n\necho -e \"\\n=== All pending changes sections ===\"\ntail -200 openspec/CHANGE_ORDER.md | head -100\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 9605\n\n---\n\n\n\n

\n\n**Core change `knowledge-01-distillation-engine` must be merged to specfact-cli before module implementation can proceed.**\n\nThe paired core change does not yet exist in `nold-ai/specfact-cli`. This is a blocking dependency per tasks.md (task 1.2). Create `openspec/changes/knowledge-01-distillation-engine` in the core repository, merge it, document the contract stability, and establish cross-repo compatibility requirements in `TDD_EVIDENCE.md` before proceeding with module implementation. Align the core change folder name with the contract referenced here.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-01-module-memory-runtime/proposal.md` at line 29,\nCreate and merge the paired core change repository folder\nopenspec/changes/knowledge-01-distillation-engine into the nold-ai/specfact-cli\nrepo (ensuring the folder name exactly matches the contract referenced in this\nmodule), document the contract stability and cross-repo compatibility\nrequirements in TDD_EVIDENCE.md, and confirm the core change is merged into\nspecfact-cli before proceeding with the module implementation so the module’s\ndependency on knowledge-01-distillation-engine is satisfied.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add an H1 at file start to avoid MD041 lint violations.**\n\nCurrent first heading is H2, which can break markdown quality checks.\n\n

Suggested change

\n\n```diff\n+# Knowledge memory runtime specification delta\n+\n ## ADDED Requirements\n```\n

\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 1-1: First line in a file should be a top-level heading\n\n(MD041, first-line-heading, first-line-h1)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\nat line 1, The file currently starts with an H2 which triggers MD041; fix by\nadding a top-level H1 as the very first line of\nopenspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md\n(e.g., \"# Knowledge Memory Runtime\") so the existing H2 becomes a secondary\nheading — ensure the H1 is descriptive for the module and placed before any\nother content or headings.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a top-level H1 heading for MD041 compliance.**\n\nThe design document starts with `## Context` but should include an H1 title (e.g., `# Design: knowledge-02-module-writeback`) for consistency with markdownlint MD041 and other OpenSpec design docs.\n\n\n\n

Proposed fix

\n\n```diff\n+# Design: knowledge-02-module-writeback\n+\n ## Context\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 1-1: First line in a file should be a top-level heading\n\n(MD041, first-line-heading, first-line-h1)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-02-module-writeback/design.md` at line 1, Add a\ntop-level H1 heading above the existing \"## Context\" heading in the design.md to\nsatisfy MD041; for consistency with other OpenSpec docs use a title like \"#\nDesign: knowledge-02-module-writeback\" placed immediately before the \"##\nContext\" section so the file begins with an H1 followed by the existing\nsubsections.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🛠️ Refactor suggestion_ | _🟠 Major_\n\n**Define the writeback adapter contract.**\n\nLines 10-12 describe adapters for `BUGBOT.md`, `.github/copilot-instructions.md`, and CodeRabbit drafts, plus deterministic manifests, but don't specify the adapter interface that writeback targets must implement or the manifest schema for audit trails. Clear adapter boundaries prevent implementation drift and ensure deterministic output across targets.\n\n\nConsider adding an \"Adapter Contract\" or \"Writeback Interface\" subsection that defines:\n- The adapter method signature (inputs: memory rules; outputs: preview content + manifest)\n- The deterministic manifest schema for lineage/audit metadata\n- Whether adapters validate target destinations or assume caller validation\n\n

🧰 Tools

\n\n

🪛 LanguageTool

\n\n[uncategorized] ~10-~10: The official name of this software platform is spelled with a capital “H”.\nContext: ...EW**: Package adapters for `BUGBOT.md`, `.github/copilot-instructions.md`, and CodeRabbi...\n\n(GITHUB)\n\n---\n\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ...drafts as opt-in writeback targets. - **NEW**: Require preview/dry-run output and e...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n---\n\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ...eviewable and safe for repo owners. - **NEW**: Normalize selected rule metadata int...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md` around lines 10 -\n12, Add an \"Adapter Contract\" (or \"Writeback Interface\") subsection that\nspecifies the adapter method signature and manifest schema: define a\nfunction-like contract (e.g., adapter receives selected memory rules and\ndestination metadata and returns { previewContent, writebackManifest }) and\nenumerate manifest fields required for deterministic lineage/audit (ruleIds,\nruleVersions, inputDigest, outputDigest, timestamp, adapterId, destination,\npreviewHash, dryRunFlag); state whether adapters MUST validate destinations or\nrely on caller validation and clarify error/validation semantics for preview\ngeneration vs. final writeback; include example field types and required vs\noptional fields so all implementations (BUGBOT.md adapter,\n.github/copilot-instructions.md adapter, CodeRabbit draft adapter) follow the\nsame deterministic output and manifest format.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🛠️ Refactor suggestion_ | _🟠 Major_\n\n**Specify `bundle_dependencies` and `core_compatibility` requirements.**\n\nLine 29 states this bundle depends on module `knowledge-01-module-memory-runtime` and core change `knowledge-02-preflight-context-assembly`, but the proposal doesn't define the expected `bundle_dependencies` or `core_compatibility` version ranges for the reserved manifest. These metadata fields are critical for registry discoverability and runtime dependency resolution.\n\n\n

📋 Proposed addition to Impact section

\n\n```diff\n - Dependencies: paired core change `knowledge-02-preflight-context-assembly`; module dependency `knowledge-01-module-memory-runtime`.\n-- Release impact: introduces a new signed official bundle and registry entry.\n+- Release impact: introduces a new signed official bundle and registry entry, with `bundle_dependencies: [knowledge-01-module-memory-runtime]` and `core_compatibility` for `knowledge-02-preflight-context-assembly`.\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md` around lines 29 -\n30, Add explicit reserved-manifest metadata: define bundle_dependencies and\ncore_compatibility version ranges for this bundle. In the Impact/Release section\nspecify bundle_dependencies including \"knowledge-01-module-memory-runtime\" with\na semver range (e.g., >=X.Y.Z \n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🛠️ Refactor suggestion_ | _🟠 Major_\n\n**Define the findings adapter contract to the core model.**\n\nLines 10-12 describe rule packs and findings emission \"in the shared review report shape\" but don't specify the adapter boundary that normalizes resiliency detections into the paired core findings contract. Without this definition, implementations may produce incompatible finding schemas.\n\n\nConsider adding an \"Adapter Contract\" subsection under \"What Changes\" that defines:\n- The core findings schema fields this bundle must populate for resiliency violations\n- The stable rule identifiers and evidence reference format\n- How severity/confidence scoring maps to the core findings model\n\n

🧰 Tools

\n\n

🪛 LanguageTool

\n\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ... the paired core findings contract. - **NEW**: Add optional probe adapters for ligh...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n---\n\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ...s stay local-first and safe for CI. - **NEW**: Emit findings in the shared review r...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` around lines 10 -\n12, Add an \"Adapter Contract\" subsection under the \"What Changes\" section that\nexplicitly defines the adapter boundary that normalizes resiliency detections\ninto the core findings model: list the exact core findings schema fields the\nbundle must populate (e.g., id, title, description, location, timestamp,\nseverity, confidence, evidence_refs), specify the stable rule identifier format\nand examples for rule IDs used by the resiliency rule packs, define the evidence\nreference format/namespace (how to reference probe logs, traces, or\nmemory-evidence), and describe the mapping rules for severity and confidence\nscoring into the core findings fields so implementations produce a stable,\ncompatible findings payload.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🛠️ Refactor suggestion_ | _🟠 Major_\n\n**Clarify `core_compatibility` and optional `bundle_dependencies` handling.**\n\nLine 29 states the bundle has an optional integration with `knowledge-01-module-memory-runtime`, and Line 30 mentions a new `module-package.yaml`, but the proposal doesn't define:\n- The `core_compatibility` version range for `review-resiliency-01-contracts`\n- Whether optional module dependencies are declared in `bundle_dependencies` with feature-gating or omitted entirely\n\nThese metadata semantics affect runtime bundle loading and registry resolution.\n\n\n

📋 Proposed clarification in Impact section

\n\n```diff\n - Dependencies: paired core change `review-resiliency-01-contracts`; optional knowledge integration with `knowledge-01-module-memory-runtime`.\n-- Release impact: introduces a new signed official bundle with a new `module-package.yaml` and registry entry.\n+- Release impact: introduces a new signed official bundle with a new `module-package.yaml` declaring `core_compatibility` for `review-resiliency-01-contracts` and optional `bundle_dependencies` for knowledge evidence forwarding (gated behind runtime availability checks).\n```\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` around lines 29 -\n30, Specify the exact core_compatibility range for\nreview-resiliency-01-contracts (e.g., semver range or platform version token) in\nmodule-package.yaml and explicitly state the semantics for optional\nintegrations: declare knowledge-01-module-memory-runtime under\nbundle_dependencies with a feature flag key (or attribute) marking it as\noptional/feature-gated, and describe registry resolution behavior when the\nfeature flag is absent versus present; reference the module-package.yaml,\ncore_compatibility, bundle_dependencies, review-resiliency-01-contracts, and\nknowledge-01-module-memory-runtime symbols in the Impact section.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Clarify whether this bundle exposes one command or multiple scanner-specific commands.**\n\nLine 9 mentions \"command ownership\" for the `specfact-security` bundle, but the design doesn't specify whether the bundle surface is:\n- A single `security` command with scanner selection flags (e.g., `--sast`, `--sca`, `--secrets`)\n- Multiple commands (e.g., `sast`, `sca`, `sbom`, `secrets`)\n- A hybrid approach\n\nThis command surface design affects discoverability, user workflow, and how the bundle declares commands in `module-package.yaml`.\n\n\nConsider adding a \"Command Surface\" subsection under \"Decisions\" that defines the primary command(s) and their relationship to the four scanner classes.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md` at line 9, Add\na \"Command Surface\" subsection under the \"Decisions\" section of the\nspecfact-security design that explicitly states whether the bundle exposes a\nsingle command or multiple scanner-specific commands and how they map to the\nfour scanner classes (sast, sca, sbom, secrets); update the document to declare\nthe chosen approach (single `security` command with flags like\n--sast/--sca/--secrets, separate commands `sast`/`sca`/`sbom`/`secrets`, or a\nhybrid) and describe the rationale for discoverability and how commands will be\ndeclared in module-package.yaml so implementers know whether to register\n`specfact-security:security` or individual commands such as\n`specfact-security:sast`.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Migration plan covers registry/docs/signatures but lacks `core_compatibility` specifics.**\n\nLine 50 mentions \"registry entry, docs, signatures, and compatibility range\" as part of the release unit, which addresses the metadata concerns. However, the design doesn't specify:\n- The expected `core_compatibility` version constraint format\n- Which core contract version(s) the initial release will target\n- Whether `bundle_dependencies` are expected (e.g., on a policy bundle)\n\nThese details could be deferred to the proposal or spec, but noting them here would help implementation planning.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md` around lines\n48 - 50, Add explicit core_compatibility details to the migration plan: specify\nthe expected version constraint format (e.g., semver range like \">=X.Y.Z\n=1.2.0\"). Update the \"registry entry, docs, signatures, and\ncompatibility range\" line to include these three concrete items so implementers\nknow the exact core_compatibility string format, the targeted core contract\nversions, and the expectation for bundle_dependencies.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🔴 Critical_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Description: Verify both core dependencies exist in specfact-cli\n\nrg -n --type=md -C3 'security-01-unified-findings-model|policy-02-packs-and-modes' || echo \"Core dependencies not found in current context\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 30153\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for security-01-unified-findings-model in specfact-cli\nrg -n --type=md -C2 'security-01-unified-findings-model' || echo \"security-01-unified-findings-model not found\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 108\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for policy-02-packs-and-modes in specfact-cli\nrg -n --type=md -C2 'policy-02-packs-and-modes' || echo \"policy-02-packs-and-modes not found\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 10347\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check CHANGE_VALIDATION status for policy-02-packs-and-modes\nfd -e \"CHANGE_VALIDATION.md\" -x grep -l \"policy-02-packs-and-modes\" {} \\;\ncat openspec/changes/policy-02-packs-and-modes/CHANGE_VALIDATION.md 2>/dev/null || echo \"No validation file found\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1272\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# More comprehensive search for security findings model\nrg -n 'security-01' --type=md --type=py || echo \"No security-01 results in specfact-cli\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 102\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check CHANGE_ORDER.md for all security changes\ncat openspec/CHANGE_ORDER.md | grep -i \"security\" | head -30\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 367\n\n---\n\n\n\n

\n\n**Verify `core_compatibility` entries—`security-01-unified-findings-model` does not exist in `specfact-cli`, and `policy-02-packs-and-modes` is a module change, not a core change.**\n\nSpecification declares `core_compatibility` entries for both `security-01-unified-findings-model` and `policy-02-packs-and-modes`, but:\n\n- `security-01-unified-findings-model` does not appear in `specfact-cli` (not found in any change or proposal)\n- `policy-02-packs-and-modes` is explicitly moved to `specfact-cli-modules` and is not a core `specfact-cli` change (per `specfact-cli` CHANGE_ORDER.md line 298: \"no active core change folder remains\")\n\nRevise the spec to either remove the policy-pack dependency or recategorize it as a module-level bundle dependency rather than a core contract. If `security-01-unified-findings-model` is intended as a core contract, confirm it exists or is being proposed in `specfact-cli` before merging this spec.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\nat line 7, Update the `nold-ai/specfact-security` spec to correct the\n`core_compatibility` declarations: if `security-01-unified-findings-model` is\nnot an accepted core contract, remove it from `core_compatibility` or add a\ncorresponding proposal in `specfact-cli` first; for `policy-02-packs-and-modes`,\nchange its entry from a core `core_compatibility` to a module-level bundle\ndependency (e.g., list it under bundle/pip dependencies) since it lives in\n`specfact-cli-modules`; ensure the spec no longer claims core compatibility for\nnon-core items and clearly documents the dependency locations for both\n`security-01-unified-findings-model` and `policy-02-packs-and-modes`.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Description: Verify referenced core changes exist in specfact-cli\n\n# Check if core changes are documented/implemented\necho \"Searching for core dependency references in specfact-cli...\"\nrg -n --type=md -C3 'security-01-unified-findings-model|policy-02-packs-and-modes' || echo \"Core changes not found in current context\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 30213\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for security-01-unified-findings-model in specfact-cli\necho \"=== Searching for security-01-unified-findings-model in specfact-cli ===\"\nrg -n --type=md 'security-01-unified-findings-model' 2>/dev/null || echo \"Pattern not found in specfact-cli markdown files\"\necho \"\"\necho \"=== Checking for openspec/changes directory structure ===\"\nfd -t d 'security-01' openspec/changes 2>/dev/null || echo \"No matching directories found\"\necho \"\"\necho \"=== Checking CHANGE_ORDER.md for references ===\"\nfd -n 'CHANGE_ORDER' | head -5 | xargs -I {} grep -n 'security-01' {} 2>/dev/null || echo \"Not found in CHANGE_ORDER\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 541\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check overall structure and look for security/findings related content\necho \"=== Checking for openspec directory ===\"\nls -la openspec/ 2>/dev/null | head -20 || echo \"No openspec directory\"\necho \"\"\necho \"=== Search for 'findings' or 'security' in markdown files ===\"\nrg -i 'findings.*model|unified.*findings' --type=md 2>/dev/null | head -20 || echo \"Pattern not found\"\necho \"\"\necho \"=== List main specfact-cli structure ===\"\nls -la 2>/dev/null | head -20\necho \"\"\necho \"=== Check if src/specfact_cli/security exists ===\"\nfind . -type d -name '*security*' 2>/dev/null | head -10\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 2920\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check CHANGE_ORDER.md for security-related entries\necho \"=== Searching CHANGE_ORDER.md for security references ===\"\ngrep -n 'security-01' openspec/CHANGE_ORDER.md 2>/dev/null | head -20 || echo \"No security-01 found\"\necho \"\"\necho \"=== Searching for 'unified-findings' ===\"\ngrep -n 'unified-findings\\|findings.*model' openspec/CHANGE_ORDER.md 2>/dev/null || echo \"Not found\"\necho \"\"\necho \"=== List all core changes in CHANGE_ORDER.md (first 100 lines) ===\"\nhead -100 openspec/CHANGE_ORDER.md\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 6154\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check if there are any pending changes listed for security in specfact-cli\necho \"=== Searching entire CHANGE_ORDER.md for 'security' ===\"\ngrep -i 'security' openspec/CHANGE_ORDER.md | head -30\necho \"\"\necho \"=== Check for all pending changes sections ===\"\ngrep -n '## ' openspec/CHANGE_ORDER.md | tail -20\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 1611\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Let me check if there's a section about security-01 or findings model anywhere\necho \"=== Checking if security-01-unified-findings-model exists in any openspec file ===\"\nfind openspec -type f -name '*.md' -exec grep -l 'security-01-unified-findings-model' {} \\; 2>/dev/null || echo \"Not found in specfact-cli openspec\"\necho \"\"\necho \"=== Check if there are any planned security modules in specfact-cli ===\"\nls -la openspec/changes/ | grep -i security || echo \"No security directories found\"\necho \"\"\necho \"=== Look at the 2026-02-15 architecture integration plan section more carefully ===\"\nsed -n '262,310p' openspec/CHANGE_ORDER.md\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 5735\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for any reference to unified-findings or findings-model\necho \"=== Broad search for unified-findings or findings model in all files ===\"\ngrep -r 'unified-findings\\|findings.*model\\|findings-model' . --include='*.md' 2>/dev/null | grep -v '.git' | head -20 || echo \"Not found\"\necho \"\"\necho \"=== Check issues/GitHub references in CHANGE_ORDER.md for security ===\"\ngrep -E '#[0-9]+.*security|security.*#[0-9]+' openspec/CHANGE_ORDER.md | head -10\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 1210\n\n---\n\n\n\n

\n\n**One of the referenced dependencies is not in specfact-cli; verify both changes exist before proceeding.**\n\nThis task requires confirming two dependencies before implementation:\n\n1. **`security-01-unified-findings-model`**: This change does not yet appear in the specfact-cli repository (no CHANGE_ORDER entry, no openspec/changes folder). Confirm it is planned or active before taking the cross-repo core compatibility dependency.\n\n2. **`policy-02-packs-and-modes`**: This change is in **specfact-cli-modules** (not specfact-cli); it's documented in specfact-cli-modules/openspec/CHANGE_ORDER.md line 49 and has a passing CHANGE_VALIDATION.md (2026-03-22). Verify the module-package.yaml and bundle registry semantics are final before binding core_compatibility.\n\nUpdate the task to explicitly confirm both are available (or acknowledge if security-01-unified-findings-model is still planned) and document the minimum core_compatibility versions.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md` at line 4,\nUpdate the task text to explicitly verify both referenced changes before binding\ncore compatibility: check that security-01-unified-findings-model exists in\nspecfact-cli (if missing, mark it as \"planned/not yet present\" and reference\nthat status), confirm policy-02-packs-and-modes is the module in\nspecfact-cli-modules (cite its CHANGE_ORDER.md and CHANGE_VALIDATION.md\nevidence), and record the minimum required core_compatibility versions against\nboth plus any sequencing notes in TDD_EVIDENCE.md; also verify\nmodule-package.yaml and bundle registry semantics for policy-02-packs-and-modes\nare final before locking core_compatibility.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a top-level H1 heading for MD041 compliance.**\n\nThe design document starts with `## Context` but should include an H1 title (e.g., `# Design: security-02-module-license-compliance`) for consistency.\n\n\n\n

Proposed fix

\n\n```diff\n+# Design: security-02-module-license-compliance\n+\n ## Context\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-02-module-license-compliance/design.md` at line 1,\nAdd a top-level H1 heading to this design doc to satisfy MD041; insert a line\nlike \"# Design: security-02-module-license-compliance\" (or another appropriate\ntitle) immediately before the existing \"## Context\" heading so the file begins\nwith an H1 and retains the current \"## Context\" section unchanged.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🛠️ Refactor suggestion_ | _🟠 Major_\n\n**Define the SBOM/SPDX adapter contract to core findings.**\n\nLines 10-11 describe \"SBOM ingestion and SPDX normalization adapters that feed the paired core security/license findings model,\" but don't specify the adapter boundary. Without this definition, implementations may produce findings schemas incompatible with the core model.\n\n\nConsider adding an \"Adapter Contract\" subsection that defines:\n- The core findings schema fields for license violations\n- How SPDX license identifiers map to normalized finding types\n- The evidence reference format for SBOM lineage\n\n

🧰 Tools

\n\n

🪛 LanguageTool

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` around\nlines 10 - 11, Add an \"Adapter Contract\" subsection under the SBOM/SPDX adapter\ndescription that specifies the exact boundary between adapters and the core\nsecurity/license findings model: enumerate the core findings schema fields\n(e.g., finding_id, package_name, package_version, license_id,\nnormalized_license_type, severity, policy_state, confidence, timestamp), define\nthe SPDX-to-normalized finding mapping rules (how SPDX identifiers map to\nnormalized_license_type and license_id), and prescribe the evidence reference\nformat for SBOM lineage (e.g., canonical SBOM source URL/ID, package entry path,\ncomponent checksum and provenance fields). Ensure this contract is titled\n\"Adapter Contract\" and referenced by \"SBOM ingestion and SPDX normalization\nadapters\" and the \"core security/license findings model\" so implementations must\nproduce findings compatible with these fields and mappings.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🛠️ Refactor suggestion_ | _🟠 Major_\n\n**Define inter-bundle compatibility hooks and `core_compatibility` requirements.**\n\nLine 12 reserves manifest/registry/docs/signing, and Line 13 mentions \"compatibility hooks\" to share SBOM data with the broader security bundle, but the proposal doesn't define:\n- The `core_compatibility` version range for `security-01-unified-findings-model`\n- The inter-bundle hook interface (shared registry schema? file-based exports? bundle dependencies?)\n- Whether the security bundle declares a `bundle_dependencies` on license-compliance or vice versa\n\nClear adapter boundaries prevent integration drift when bundles evolve independently.\n\n

🧰 Tools

\n\n

🪛 LanguageTool

\n\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ...face explicit remediation guidance. - **NEW**: Define bundle manifest, registry, do...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` around\nlines 12 - 13, Specify concrete inter-bundle compatibility and adapter\nboundaries: add a core_compatibility version range entry that references\nsecurity-01-unified-findings-model (e.g., semver range) in the\nlicense-compliance bundle manifest, define the inter-bundle hook interface\n(choose and document a single approach such as a shared registry schema named\nsbom_registry with JSON schema and API surface or a file-based export format\nnamed sbom_export_v1 and its file layout), state whether bundle_dependencies\nshould be declared (add bundle_dependencies: [\n\"security-01-unified-findings-model\" ] to the license-compliance manifest or\nreverse it if the security bundle should depend on license-compliance), and\nupdate manifest/registry/docs/signing sections to include required fields for\nregistry entry, docs pointer, and signing expectations so adapters can be built\nagainst these stable hooks.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for security-02-eu-gdpr-baseline references in license-related OpenSpec docs\nrg -n 'security-02-eu-gdpr-baseline' openspec/changes/security-02-module-license-compliance/\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 615\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read the proposal around line 29 to understand the dependency context\nsed -n '20,40p' openspec/changes/security-02-module-license-compliance/proposal.md\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1004\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Look for other security module proposals to compare dependency patterns\nfd 'proposal.md' openspec/changes/security-* | head -10\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 262\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for \"policy-pack\" references to understand what it means\nrg -n 'policy-pack' openspec/changes/ -A 2\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 10336\n\n---\n\n\n\n

\n\n**Verify dependency reference on line 29: `security-02-eu-gdpr-baseline` appears incorrect for license compliance policy-pack semantics.**\n\nThe proposal states a dependency on `security-02-eu-gdpr-baseline` \"for shared policy-pack semantics,\" but evidence indicates that `policy-02-packs-and-modes` is the core change providing shared policy-pack semantics. The security-03-module-pii-gdpr-eu proposal correctly lists `policy-02-packs-and-modes` as its blocker for policy-pack-driven GDPR/EU rule selection, and the license-compliance design (design.md:44) similarly references \"shared policy-pack interpretation\" as the mitigation strategy.\n\nEither:\n1. Replace with `policy-02-packs-and-modes` as the primary policy-pack blocker, or\n2. If `security-02-eu-gdpr-baseline` represents a separate baseline for vendor/supply-chain GDPR compliance checks, clarify this in the rationale and document the distinct semantics provided.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` at line\n29, The dependency reference in proposal.md currently points to\nsecurity-02-eu-gdpr-baseline but should reference the core policy-pack change\npolicy-02-packs-and-modes (or else clarify distinct semantics) — update the\ndependency on line 29 to replace security-02-eu-gdpr-baseline with\npolicy-02-packs-and-modes if the intention is to indicate the shared policy-pack\nsemantics, or add one sentence in the rationale clarifying that\nsecurity-02-eu-gdpr-baseline is a separate vendor/supply-chain baseline and\nexplain how its semantics differ from policy-02-packs-and-modes (cross-reference\nsecurity-03-module-pii-gdpr-eu and design.md:44 where policy-pack interpretation\nis already referenced).\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🔴 Critical_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Description: Verify security-01-unified-findings-model exists in specfact-cli\n\nrg -n --type=md -C3 'security-01-unified-findings-model' || echo \"Core dependency not found in current context\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 19931\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for security-01-unified-findings-model implementation in specfact-cli\nrg -n --type=md -C2 'security-01-unified-findings-model' . | head -100\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 46\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Look for CHANGE_ORDER or similar tracking files mentioning status of security changes\nfind . -name \"CHANGE_ORDER*\" -o -name \"*findings*\" -type f | head -20\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 90\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for unified findings or findings model implementation\nrg -n 'unified.?findings|findings.?model|FindingsModel' --type=py --type=md . | head -50\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 46\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read CHANGE_ORDER.md to find security change status\ncat -n ./openspec/CHANGE_ORDER.md | head -150\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 12624\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for any mention of security or findings in CHANGE_ORDER\nrg -n 'security|findings' ./openspec/CHANGE_ORDER.md\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 1261\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read lines 150-350 to find security module section\nsed -n '150,350p' ./openspec/CHANGE_ORDER.md\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 19360\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read remaining lines to find any security module section\nsed -n '350,500p' ./openspec/CHANGE_ORDER.md\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 13534\n\n---\n\n\n\n

\n\n**Verify security-01-unified-findings-model is in specfact-cli's roadmap before proceeding.**\n\nThis spec depends on `security-01-unified-findings-model` for shared findings/report contracts. However, this core change does not appear in `specfact-cli`'s CHANGE_ORDER.md. Confirm it is planned, scheduled, or already implemented in the core repository, and document the required `core_compatibility` version in `TDD_EVIDENCE.md` before implementation begins.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\nat line 7, Confirm that the core change \"security-01-unified-findings-model\" is\nplanned or implemented in the specfact-cli roadmap by checking specfact-cli's\nCHANGE_ORDER.md and the core repo; if it is planned or already merged, record\nthe exact core release or commit that provides the shared findings/report\ncontracts and add that version as the `core_compatibility` value for\n`nold-ai/specfact-license-compliance` in the spec (and document the same\nidentifier in TDD_EVIDENCE.md); if it is not planned, open/track a\nCHANGE_ORDER.md entry or coordination ticket in specfact-cli before implementing\nthis bundle and do not proceed until the required core compatibility version is\nagreed and documented.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Mirror signature workflow wording used by automation to prevent process drift.**\n\nConsider rephrasing this step so contributors don’t infer that signature files should be manually produced/committed during implementation.\n\nBased on learnings, signature artifacts are generated by the publish workflow, while pre-merge verification should focus on the signature/version enforcement gate.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` at line 19, The\ntask line \"3.4 Update registry metadata, docs references, signatures, and any\nimport allowlists required by the new bundle.\" should be reworded to clarify\nthat signature artifacts are produced by the publish automation and must not be\nmanually committed; update the step (referencing the task text \"Update registry\nmetadata, docs references, signatures, and any import allowlists\") to say\ncontributors should update registry metadata, docs, and import allowlists as\nneeded and ensure the publish workflow will generate signatures, while pre-merge\nchecks must rely on the signature/version enforcement gate rather than creating\nor committing signature files manually.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Consider the UX of JSON-dumping business/product sections.**\n\nLines 20 and 26 use `tojson(indent=2)` to render `business` and `product` objects as formatted JSON within Markdown. While this preserves structured data, large or deeply nested objects may produce verbose, hard-to-read output in the generated persona document.\n\n\nConsider alternative rendering strategies:\n- **If business/product have predictable schemas**: Use nested Jinja2 loops to render specific fields as Markdown (similar to the Features section on Lines 32-56)\n- **If freeform structured data is expected**: Keep `tojson` but add a comment in the template explaining this is intentional for machine-readable embedded metadata\n\nExample alternative for predictable schema:\n```jinja2\n## Business\n{% if business.model %}\n- **Model**: {{ business.model }}\n{% endif %}\n{% if business.revenue_streams %}\n- **Revenue Streams**: {{ business.revenue_streams | join(\", \") }}\n{% endif %}\n```\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@packages/specfact-project/resources/templates/persona/default.md.j2` at line\n20, The template currently dumps business and product with tojson(indent=2)\nwhich can produce noisy Markdown; update the persona template (default.md.j2) to\neither (A) replace the JSON dumps for the business and product blocks with\nexplicit Jinja2 field render loops when those objects follow predictable schemas\n(use conditional checks on business.model, business.revenue_streams,\nproduct.features, etc., and render as Markdown list items) or (B) if those\nobjects are freeform and must remain machine-readable, retain tojson(indent=2)\nbut add a clear template comment above each dump explaining the intentional\nmachine-readable JSON embedding so future maintainers understand the choice.\nEnsure you modify the occurrences of tojson for the variables business and\nproduct.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟠 Major_\n\n

🧩 Analysis chain

\n\n🌐 Web query:\n\n`In GitHub CLI `gh api`, what is the exact behavioral difference between `-F/--field` and `-f/--raw-field`, including `@file` expansion and type coercion rules?`\n\n💡 Result:\n\nThe exact behavioral differences between -F/--field (magic/typed fields) and -f/--raw-field (raw/string fields) in gh api are: - -f/--raw-field: Adds parameters as literal strings with no processing. Values are treated exactly as provided in key=value format. Does not support or perform `@file` expansion, placeholder substitution (e.g., {owner}), or type coercion (e.g., true to boolean). Suitable for static string values, including those containing @ characters. Supports nested syntax like key[subkey]=value and arrays via key[]=value. - -F/--field: Adds parameters with \"magic\" processing and type coercion: - If value starts with @, reads the file content (or stdin with `@-`) and uses it as the value (raw bytes, preserving type if JSON-like). - Substitutes placeholders {owner}, {repo}, {branch} from the current repo context. - Coerces literal strings: true/false to boolean, null to null, integers (e.g., 123) to numbers. - Otherwise, treats as string. - Supports the same nested key[subkey]=value and array key[] syntax. Both flags can be mixed in the same command. Adding any fields switches method to POST (unless overridden with --method GET). For GraphQL, fields other than query/operationName become variables. Examples: - -f body='Hi from CLI' (raw string) - -F 'files[myfile.txt][content]=@myfile.txt' (file expansion) - -F state=true (boolean coercion) - -f q='repo:cli/cli is:open' (search string with colons)\n\nCitations:\n\n- 1: https://cli-github.cnmirror.me/manual/gh_api\n- 2: https://cli.github.com/manual/gh_api\n- 3: https://cli.github.com/manual/gh_help_reference\n- 4: https://www.gsp.com/cgi-bin/man.cgi?section=1&topic=GH-API\n- 5: https://man.cx/gh-api(1)\n- 6: https://manpages.debian.org/unstable/gh/gh-api.1.en.html\n- 7: https://github.com/cli/cli/blob/trunk/pkg/cmd/api/api.go\n- 8: https://www.quinze-cent-quinze.fr\n- 9: https://github.com/cli/cli/blob/trunk/git/client.go\n- 10: https://github.com/cli/cli/issues/12892\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Locate and inspect the script file\nfind . -name \"ensure_github_hierarchy_subissues.py\" -type f\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 118\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read the full script to understand data flow\ncat -n scripts/ensure_github_hierarchy_subissues.py | head -100\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 3793\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Continue reading the script\ncat -n scripts/ensure_github_hierarchy_subissues.py | sed -n '100,175p'\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 3701\n\n---\n\n\n\n

\n\n**Harden GraphQL argument encoding for variables to avoid `@file` expansion.**\n\nThe `-F` flag at lines 43–51 performs \"magic\" processing in `gh api`, including `@file` expansion when a value starts with `@`. For string variables (particularly user-provided `--repo-owner` and `--repo-name`), use the safer `-f` flag which treats values as literal strings. Reserve `-F` only for non-string values that require type coercion (integers, booleans).\n\n

Suggested hardening

\n\n```diff\n def _gh_graphql(*, query: str, variables: dict[str, Any], timeout: int = _GH_GRAPHQL_TIMEOUT_SEC) -> dict[str, Any]:\n args = [\"gh\", \"api\", \"graphql\", \"-f\", f\"query={query}\"]\n for key, value in variables.items():\n if value is None:\n continue\n if isinstance(value, list):\n for item in value:\n- args.extend([\"-F\", f\"{key}[]={item}\"])\n+ flag = \"-f\" if isinstance(item, str) else \"-F\"\n+ args.extend([flag, f\"{key}[]={item}\"])\n+ elif isinstance(value, str):\n+ args.extend([\"-f\", f\"{key}={value}\"])\n else:\n args.extend([\"-F\", f\"{key}={value}\"])\n```\n

\n\nAs per coding guidelines, `scripts/**/*.py` requires deterministic tooling with subprocess and path safety.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@scripts/ensure_github_hierarchy_subissues.py` around lines 43 - 51, The\ncurrent loop building args uses -F for all scalar string variables which\ntriggers gh's `@file` expansion; update the logic that builds args (the args list\nand the variables dict handling) to use -f for string values (including string\nlist items and repo-owner/repo-name) so they are passed literally, and reserve\n-F only for non-string typed values (e.g., ints, bools) that need type coercion;\nspecifically, change the branch that checks isinstance(value, list) to emit\nrepeated \"-f\" entries for string items, and in the scalar branch emit \"-f\" when\nisinstance(value, str) else \"-F\" for non-strings. Ensure the initial query part\n(f\"query={query}\") remains unchanged and keep skipping None values.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_⚠️ Potential issue_ | _🟡 Minor_\n\n

🧩 Analysis chain

\n\n🌐 Web query:\n\n`For GitHub GraphQL API responses, can top-level `data` be null or omitted, and what is the recommended client-side handling when `errors` is present with partial/empty `data`?`\n\n💡 Result:\n\nIn GitHub's GraphQL API, which follows the GraphQL specification, the top-level data field in responses can be null or entirely omitted under specific conditions. - data is omitted (not present) for request errors occurring before execution (e.g., parse errors, validation errors). - data is null if an execution error prevents a valid response. - data can be a partial object (including null values for specific fields) alongside an errors array for field-level execution errors. data is never omitted when errors is present with partial data; both coexist in partial responses. Recommended client-side handling when errors is present with partial/empty data: - Always check for the presence of errors, regardless of data. - Use partial data if available (e.g., via error policies like 'all' in Apollo Client), as it may contain valid results. - Examine errors.path to map errors to specific null fields in data. - For GitHub-specific clients like Octokit graphql.js, catch GraphqlResponseError where error.data provides partial data. - Implement conditional rendering: use data values if present and error-free; show warnings or fallbacks for errored fields. - Log errors for monitoring, distinguishing field errors (partial data usable) from request errors (no data). This follows GraphQL spec behavior, confirmed in GitHub examples like pagination with partial results and Octokit handling.\n\nCitations:\n\n- 1: https://graphql.org/learn/response/\n- 2: https://github.com/graphql/graphql-spec/blob/60323c90dc2699266be7da7f0d4ab293953cd733/spec/Section%207%20--%20Response.md\n- 3: https://github.com/graphql/graphql-spec/blob/main/spec/Section%207%20--%20Response.md\n- 4: https://github.com/octokit/graphql.js/issues/14\n- 5: https://www.npmjs.com/package/@octokit/graphql\n- 6: https://github.com/apollographql/skills/blob/main/skills/apollo-client/references/error-handling.md\n- 7: https://hasura.io/blog/graphql-nulls-cheatsheet\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# First, let's look at the file and understand the context\nfind . -name \"ensure_github_hierarchy_subissues.py\" -type f | head -5\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 118\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check the structure and find the specific function\nrg -B 10 -A 5 'payload\\[\"data\"\\]' scripts/\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1437\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Look at the full function containing these lines\ncat -n scripts/ensure_github_hierarchy_subissues.py | head -100\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 3793\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check for all callers of _gh_graphql\nrg -B 2 -A 2 '_gh_graphql' scripts/ensure_github_hierarchy_subissues.py\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 896\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check if json.loads could fail and how errors are handled\ncat -n scripts/ensure_github_hierarchy_subissues.py | sed -n '42,120p'\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 3780\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check the main entry point and overall error handling\ncat -n scripts/ensure_github_hierarchy_subissues.py | tail -50\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 2343\n\n---\n\n\n\n

\n\n**Use `.get(\"data\")` and validate response envelope structure for deterministic failure handling.**\n\nAt lines 67–70, `payload[\"data\"]` is accessed without first validating that `payload` is a dict or that the `\"data\"` key exists. Per GitHub's GraphQL spec, `data` can be null or (in edge cases of malformed output) missing entirely. While unlikely with the `gh` CLI, unexpected envelopes should raise clear errors rather than `TypeError` or `KeyError`. This aligns with deterministic tooling requirements for scripts.\n\nRecommended fix: Use `payload.get(\"data\")` instead of direct access and add a type check for `payload` before the `\"errors\" in payload` test:\n\n

Suggested resilience diff

\n\n```diff\n payload = json.loads(proc.stdout)\n+ if not isinstance(payload, dict):\n+ raise RuntimeError(\"gh graphql returned a non-object JSON payload\")\n if \"errors\" in payload:\n raise RuntimeError(json.dumps(payload[\"errors\"], indent=2))\n- return payload[\"data\"]\n+ data = payload.get(\"data\")\n+ if data is None:\n+ raise RuntimeError(\"gh graphql response missing data object\")\n+ return data\n```\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@scripts/ensure_github_hierarchy_subissues.py` around lines 67 - 70, The JSON\nresponse handling is brittle: change the logic that reads payload =\njson.loads(proc.stdout) so you first verify payload is a dict\n(isinstance(payload, dict)); only then check for \"errors\" in payload, and\nretrieve the result using payload.get(\"data\") instead of payload[\"data\"]; if\npayload is not a dict or payload.get(\"data\") is None (or missing), raise a clear\nRuntimeError that includes the raw payload or proc.stdout for debugging. Ensure\nyou reference the existing variables payload and proc when constructing the\nerror messages so failures are deterministic and informative.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Cache parent sub-issue sets and issue node IDs to reduce API churn.**\n\nLine 148–Line 159 repeatedly re-fetches the same parent and node IDs, increasing call volume and rate-limit risk for automation.\n\n \n\n

Suggested DRY/call-reduction diff

\n\n```diff\n def main(argv: list[str] | None = None) -> int:\n@@\n owner, name = args.repo_owner, args.repo_name\n added = 0\n skipped = 0\n would_add = 0\n+ subissues_cache: dict[int, set[int]] = {}\n+ issue_id_cache: dict[int, str] = {}\n \n for parent_num, child_num in DEFAULT_EDGES:\n- existing = _subissue_numbers(owner=owner, name=name, parent_number=parent_num)\n+ existing = subissues_cache.setdefault(\n+ parent_num,\n+ _subissue_numbers(owner=owner, name=name, parent_number=parent_num),\n+ )\n if child_num in existing:\n skipped += 1\n continue\n@@\n- parent_id = _issue_node_id(owner=owner, name=name, number=parent_num)\n- child_id = _issue_node_id(owner=owner, name=name, number=child_num)\n+ parent_id = issue_id_cache.setdefault(\n+ parent_num, _issue_node_id(owner=owner, name=name, number=parent_num)\n+ )\n+ child_id = issue_id_cache.setdefault(\n+ child_num, _issue_node_id(owner=owner, name=name, number=child_num)\n+ )\n _add_sub_issue(parent_id=parent_id, child_id=child_id)\n+ existing.add(child_num)\n sys.stdout.write(f\"addSubIssue #{child_num} -> parent #{parent_num}\\n\")\n added += 1\n```\n

\n\nAs per coding guidelines, preserve clean-code compliance with DRY/KISS in changed Python code.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@scripts/ensure_github_hierarchy_subissues.py` around lines 148 - 159, The\nloop over DEFAULT_EDGES repeatedly calls _subissue_numbers and _issue_node_id\ncausing excess API calls; introduce simple in-memory caches (e.g., dicts keyed\nby parent number and by issue number) before the loop to store fetched sub-issue\nsets and node IDs, consult the cache instead of re-calling\n_subissue_numbers(parent_num) and _issue_node_id(...) for the same\nparent_num/child_num, and only call the underlying functions on cache misses;\nstill honor args.dry_run, increment skipped/would_add as before, and pass the\ncached parent_id/child_id into _add_sub_issue when needed.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Make trigger-type assertions order-insensitive to reduce test churn.**\n\nLine 52 and Line 55 currently require exact list ordering; workflow semantics are set-based. Prefer set comparison to avoid brittle failures from harmless YAML reordering.\n\n

Suggested refactor

\n\n```diff\n- assert pr_review[\"types\"] == [\"submitted\"]\n+ assert set(pr_review[\"types\"]) == {\"submitted\"}\n ...\n- assert pr[\"types\"] == [\"opened\", \"synchronize\", \"reopened\", \"ready_for_review\"]\n+ assert set(pr[\"types\"]) == {\"opened\", \"synchronize\", \"reopened\", \"ready_for_review\"}\n```\n

\n\n\nAs per coding guidelines: `tests/**/*.py`: Contract-first and integration tests ... and flakiness.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@tests/unit/workflows/test_sign_modules_on_approval.py` around lines 52 - 55,\nThe assertions that check event trigger lists are brittle due to ordering;\nupdate the tests to compare sets instead of lists: replace the exact-equality\nassertions on pr_review[\"types\"] and pr[\"types\"] with order-insensitive checks\n(e.g., assert set(pr_review[\"types\"]) == {\"submitted\"} and assert\nset(pr[\"types\"]) == {\"opened\",\"synchronize\",\"reopened\",\"ready_for_review\"}) so\nthe tests no longer fail when YAML ordering changes; locate and update the\nassertions referencing pr_review[\"types\"] and pr[\"types\"] in\ntest_sign_modules_on_approval.py.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit 0672f50\n**Actionable comments posted: 51**\n\n

🤖 Prompt for all review comments with AI agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nInline comments:\nIn @.github/workflows/sign-modules-on-approval.yml:\n- Line 74: The current Python one-liner that parses the GraphQL JSON (the\npython3 -c \"import json,sys; data=json.load(sys.stdin); reviews=...;\nprint(...)\") can raise a KeyError on missing keys; update it to validate the\nexpected keys or wrap the parsing and key access in a try/except that catches\n(KeyError, TypeError, ValueError) and prints a clear, descriptive error message\nto stderr (including which top-level key is missing and the raw input snippet or\nits summary) before exiting with a non-zero status so the GitHub Actions job\nfails with a useful message.\n- Around line 68-81: The GraphQL query uses latestReviews(first:100) which can\nmiss reviews if a PR has >100 distinct reviewers; update the sign workflow to\nhandle pagination by looping requests using pageInfo.hasNextPage and\npageInfo.endCursor (aggregate nodes across pages) before computing\ntrusted_review_count, referencing the existing trusted_review_count calculation\nand the latestReviews(...) field; alternatively, if you decide 100 is an\nacceptable ceiling for this repo, add a clear comment in the workflow near\nlatestReviews(first:100) explaining that the 100-reviewer limit is intentional\nand documented.\n\nIn `@docs/bundles/project/import-migration.md`:\n- Around line 39-40: Replace the vague phrase \"very large\" in the two sentences\nthat start with \"When import encounters unusually large ignored artifact\ntrees...\" and \"Remaining time is based on processed-versus-discovered work...\"\nwith concrete thresholds; for example, change to \"ignored artifact trees with\n>10,000 entries or repositories larger than ~100,000 files, ~10 GB of repository\ndata, or >100,000 commits\" and note that estimates remain provisional for repos\nabove those thresholds—adjust the numeric thresholds to align with product\ntelemetry if different.\n\nIn `@openspec/CHANGE_ORDER.md`:\n- Around line 94-95: The two entries for security-02-module-license-compliance\nand security-03-module-pii-gdpr-eu both use Order | 04; update the Order on one\nof them (e.g., change security-03-module-pii-gdpr-eu to Order | 05 or otherwise\nassign a unique, sequential number) so every `security` entry has a distinct\nOrder value and the CHANGE_ORDER semantics remain consistent across the spec.\n\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\n- Line 50: The document references a paired core contract named\narchitecture-02-well-architected-review that isn't present in specfact-cli;\nupdate the design to either (a) point to the existing core contract if it exists\nunder a different name or folder (search for architecture-01-solution-layer and\nother architecture-* entries in the specfact-cli repo), (b) confirm and document\nthat architecture-01-solution-layer supplies the required boundary rules and\nadapter contracts for this module, or (c) add a note that a new core change\narchitecture-02-well-architected-review must be created/synced into specfact-cli\nbefore module integration—ensure the doc references the exact core contract name\nyou verified and mention architecture-01-solution-layer when clarifying overlap.\n\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md`:\n- Around line 10-12: Add an \"Adapter Contract\" subsection under \"What Changes\"\nthat defines the normalized boundary between analyzers and the core review\ncontract: list the required core findings schema fields this bundle must\npopulate (e.g., id, type, severity, description, source, timestamp,\nevidence_refs), specify how outputs from the packaged analyzers\n(dependency-graph checks, ADR traceability, interface-diff) map to normalized\nevidence references and fields (reference example mappings for\nALLOWED_IMPORTS.md violations → evidence_refs, ADR entries → source/trace\nlinks), and state the emission mode (synchronous vs deferred batching) and\nretry/ordering semantics for findings emission so implementers know expected\nbehavior.\n- Line 13: Add an explicit core_compatibility field and semantic version range\nfor the reserved manifest \"architecture-02-well-architected-review\" so consumers\nand the core can validate compatibility; update the proposal text to state the\nrequired core version range (e.g., a semver range such as \">=X.Y.Z merge\n`.specfact/.specfactignore` -> explicit target override) is added to the spec so\npruning happens before traversal and precedence is unambiguous.\n- Around line 1-40: The markdown has lint warnings from missing blank lines\naround headings (MD041/MD022); edit the section headings such as \"ADDED\nRequirements\", \"Requirement: Import runtime SHALL prune hidden and heavyweight\ntrees before discovery\", \"Scenario: Default traversal skips hidden and\nheavyweight directories\", \"Requirement: Import runtime SHALL surface\nlarge-artifact warnings\", and \"Requirement: Import progress SHALL use\ndiscovered-versus-processed work\" to ensure there is a single blank line above\nand below each heading and between consecutive headings/paragraphs so each\nheading is properly separated and no multiple consecutive headings lack\nintervening blank lines; keep the existing heading text and indentation but\ninsert the required blank lines consistently throughout the document to resolve\nMD041/MD022.\n\nIn `@openspec/changes/codebase-import-runtime-hardening/tasks.md`:\n- Line 1: Add a top-level H1 heading to the document (replace the current\nleading \"## 1. GitHub readiness and change scaffolding\" start) so the file\nbegins with an H1 like \"# Tasks: codebase-import-runtime-hardening\" to satisfy\nMD041 and match other task files; ensure the existing content remains unchanged\nafter the new H1.\n\nIn\n`@openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`:\n- Line 1: Add a top-level H1 above the existing H2 \"ADDED Requirements\" in the\nspec.md (e.g., \"Enterprise Policy Client\" or another concise title) so the\ndocument begins with an H1 to satisfy MD041; update the first line to a valid\nMarkdown H1 and ensure the existing H2 remains unchanged.\n\nIn `@openspec/changes/enterprise-01-module-policy-client/tasks.md`:\n- Line 4: Update checklist item for enterprise-01-policy-resolution-extension to\nexplicitly require reviewing the paired public OpenSpec/contracts in\nnold-ai/specfact-cli before implementation and documenting the minimum required\ncore_compatibility; add a sub-item that instructs the implementer to verify and\nrecord matching change IDs, model names, and workflow semantics between this\nchange and the paired specfact-cli artifacts (e.g., \"Review paired public\nOpenSpec/contracts in nold-ai/specfact-cli and confirm matching change IDs/model\nnames/workflow semantics; document minimum core_compatibility\"). Ensure the new\ntext appears alongside the existing 1.2 checklist so reviewers cannot skip the\npaired-core artifact review step.\n\nIn `@openspec/changes/enterprise-02-module-audit-client/design.md`:\n- Line 1: The document begins with an H2 (\"## Context\") which triggers MD041;\nadd a top-level H1 above the existing \"## Context\" header (e.g., \"# Context\" or\na suitable project/title H1) so the file starts with an H1, leaving the existing\n\"## Context\" as-is to preserve structure.\n\nIn\n`@openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`:\n- Line 7: The spec declares a hard core dependency on\nenterprise-02-rbac-and-audit-trail for the nold-ai/specfact-enterprise-audit\nbundle but that core change does not exist; update\nenterprise-audit-client/spec.md to remove or replace the nonexistent core change\nreference in the core_compatibility and dependency text (replace\nenterprise-02-rbac-and-audit-trail with the correct existing change ID or a TODO\nplaceholder), and add a note that implementation is blocked until the paired\ncore change is proposed/merged and the spec's core_compatibility entry is\nupdated.\n\nIn `@openspec/changes/enterprise-02-module-audit-client/tasks.md`:\n- Line 4: Update the task checklist in\nenterprise-02-module-audit-client/tasks.md to add an explicit step that\nreviewers must inspect the paired public core OpenSpec/contracts (not just\nupstream sequencing) for the `enterprise-02-rbac-and-audit-trail` change and any\nlinked artifacts from `enterprise-01-module-policy-client`; call out that\nreviewers should confirm the authoritative public artifacts in specfact-cli (or\nequivalent public repo) and record the minimum required `core_compatibility`\nafter that review. Ensure the new line references the paired artifact names\n(`enterprise-02-rbac-and-audit-trail`, `enterprise-01-module-policy-client`,\nspecfact-cli) and replaces or augments the existing weaker \"Confirm paired core\nchange\" item.\n\nIn\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`:\n- Line 7: The spec references coordination with\ntelemetry-01-opentelemetry-default-on but doesn't state whether that change is a\nbundle dependency, a core_compatibility requirement, or only a sequencing\nconstraint; update the sentence for nold-ai/specfact-finops to explicitly state\nhow telemetry-01-opentelemetry-default-on is represented (e.g., add it to\nbundle_dependencies, list it under core_compatibility, or note it as a\nsequencing prerequisite) and ensure the manifest fields mentioned\n(`bundle_dependencies`, `pip dependencies`, `core_compatibility`) clearly\nindicate where telemetry-01 appears and that CHANGE_ORDER.md is the\nauthoritative source for sequencing.\n\nIn `@openspec/changes/finops-01-module-cost-outcome/tasks.md`:\n- Line 19: Edit the task bullet that currently reads \"3.4 Update registry\nmetadata, docs references, signatures, and any import allowlists required by the\nnew bundle.\" to clarify that \"signatures\" are validated by gates and created by\nthe publish automation rather than manually committed; e.g., change the phrase\nto something like \"update registry metadata, docs references, and any import\nallowlists required by the new bundle (signatures are validated by CI gates and\nproduced by publish automation—not committed manually)\"; update the text near\nthe 3.4 task in tasks.md accordingly.\n\nIn `@openspec/changes/knowledge-01-module-memory-runtime/design.md`:\n- Line 48: The design references a paired core MemoryBackend protocol that isn't\npublished in specfact-cli; confirm and record this contract by coordinating with\nspecfact-cli to either (A) publish the MemoryBackend protocol definition and\nversion/stability statement (ensure the exported symbol is named MemoryBackend\nand its public API/JSON schema is documented), or (B) add the MemoryBackend\nprotocol to the paired core change scope and include its authoritative spec in\nthis repo's design document (update \"migration step 1\" to reference the exact\nprotocol artifact, version, and where it is published). Ensure the design.md\nexplicitly points to the published spec (or pairing ticket) and notes the\nrequired stability guarantee so the markdown-graph MemoryBackend integration can\nproceed.\n\nIn `@openspec/changes/knowledge-01-module-memory-runtime/proposal.md`:\n- Around line 9-13: Rephrase the repeated \"**NEW**:\" bullets to improve\nreadability by varying sentence structure: e.g., keep one \"**NEW**:\" header for\nthe group and turn the rest into action-starting phrases (\"Add a\n`specfact-knowledge` bundle with `memory` subcommands...\", \"Package the\nmarkdown-graph backend as the default runtime...\", \"Define gitignore,\nrepo-layout, and file-lifecycle...\", \"Add search and status surfaces exposing\n`MemoryBackend` behavior...\") or combine related items into a single sentence;\ntarget the lines mentioning `specfact-knowledge`, `memory` subcommands,\n`markdown-graph backend`, `.specfact/memory/`, and `MemoryBackend` when applying\nthe edits.\n- Line 29: Create and merge the paired core change repository folder\nopenspec/changes/knowledge-01-distillation-engine into the nold-ai/specfact-cli\nrepo (ensuring the folder name exactly matches the contract referenced in this\nmodule), document the contract stability and cross-repo compatibility\nrequirements in TDD_EVIDENCE.md, and confirm the core change is merged into\nspecfact-cli before proceeding with the module implementation so the module’s\ndependency on knowledge-01-distillation-engine is satisfied.\n\nIn\n`@openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`:\n- Line 1: The file currently starts with an H2 which triggers MD041; fix by\nadding a top-level H1 as the very first line of\nopenspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md\n(e.g., \"# Knowledge Memory Runtime\") so the existing H2 becomes a secondary\nheading — ensure the H1 is descriptive for the module and placed before any\nother content or headings.\n\nIn `@openspec/changes/knowledge-01-module-memory-runtime/tasks.md`:\n- Line 1: Replace the numeric H1 \"# 1. Branch and dependency guardrails\" with a\ndescriptive H1 to match other OpenSpec files (for example \"Change: Branch and\ndependency guardrails\" or \"Design: Branch and dependency guardrails\"); update\nthe header string in the tasks.md file so the top-level title uses a descriptive\nlabel rather than a leading number to maintain consistency across specs.\n\nIn `@openspec/changes/knowledge-02-module-writeback/design.md`:\n- Line 1: Add a top-level H1 heading above the existing \"## Context\" heading in\nthe design.md to satisfy MD041; for consistency with other OpenSpec docs use a\ntitle like \"# Design: knowledge-02-module-writeback\" placed immediately before\nthe \"## Context\" section so the file begins with an H1 followed by the existing\nsubsections.\n\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md`:\n- Around line 10-12: Add an \"Adapter Contract\" (or \"Writeback Interface\")\nsubsection that specifies the adapter method signature and manifest schema:\ndefine a function-like contract (e.g., adapter receives selected memory rules\nand destination metadata and returns { previewContent, writebackManifest }) and\nenumerate manifest fields required for deterministic lineage/audit (ruleIds,\nruleVersions, inputDigest, outputDigest, timestamp, adapterId, destination,\npreviewHash, dryRunFlag); state whether adapters MUST validate destinations or\nrely on caller validation and clarify error/validation semantics for preview\ngeneration vs. final writeback; include example field types and required vs\noptional fields so all implementations (BUGBOT.md adapter,\n.github/copilot-instructions.md adapter, CodeRabbit draft adapter) follow the\nsame deterministic output and manifest format.\n- Around line 29-30: Add explicit reserved-manifest metadata: define\nbundle_dependencies and core_compatibility version ranges for this bundle. In\nthe Impact/Release section specify bundle_dependencies including\n\"knowledge-01-module-memory-runtime\" with a semver range (e.g., >=X.Y.Z =X.Y.Z =1.2.0\"). Update the \"registry entry, docs, signatures, and\ncompatibility range\" line to include these three concrete items so implementers\nknow the exact core_compatibility string format, the targeted core contract\nversions, and the expectation for bundle_dependencies.\n- Line 9: Add a \"Command Surface\" subsection under the \"Decisions\" section of\nthe specfact-security design that explicitly states whether the bundle exposes a\nsingle command or multiple scanner-specific commands and how they map to the\nfour scanner classes (sast, sca, sbom, secrets); update the document to declare\nthe chosen approach (single `security` command with flags like\n--sast/--sca/--secrets, separate commands `sast`/`sca`/`sbom`/`secrets`, or a\nhybrid) and describe the rationale for discoverability and how commands will be\ndeclared in module-package.yaml so implementers know whether to register\n`specfact-security:security` or individual commands such as\n`specfact-security:sast`.\n\nIn\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`:\n- Line 7: Update the `nold-ai/specfact-security` spec to correct the\n`core_compatibility` declarations: if `security-01-unified-findings-model` is\nnot an accepted core contract, remove it from `core_compatibility` or add a\ncorresponding proposal in `specfact-cli` first; for `policy-02-packs-and-modes`,\nchange its entry from a core `core_compatibility` to a module-level bundle\ndependency (e.g., list it under bundle/pip dependencies) since it lives in\n`specfact-cli-modules`; ensure the spec no longer claims core compatibility for\nnon-core items and clearly documents the dependency locations for both\n`security-01-unified-findings-model` and `policy-02-packs-and-modes`.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md`:\n- Line 4: Update the task text to explicitly verify both referenced changes\nbefore binding core compatibility: check that security-01-unified-findings-model\nexists in specfact-cli (if missing, mark it as \"planned/not yet present\" and\nreference that status), confirm policy-02-packs-and-modes is the module in\nspecfact-cli-modules (cite its CHANGE_ORDER.md and CHANGE_VALIDATION.md\nevidence), and record the minimum required core_compatibility versions against\nboth plus any sequencing notes in TDD_EVIDENCE.md; also verify\nmodule-package.yaml and bundle registry semantics for policy-02-packs-and-modes\nare final before locking core_compatibility.\n\nIn `@openspec/changes/security-02-module-license-compliance/design.md`:\n- Line 1: Add a top-level H1 heading to this design doc to satisfy MD041; insert\na line like \"# Design: security-02-module-license-compliance\" (or another\nappropriate title) immediately before the existing \"## Context\" heading so the\nfile begins with an H1 and retains the current \"## Context\" section unchanged.\n\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md`:\n- Around line 10-11: Add an \"Adapter Contract\" subsection under the SBOM/SPDX\nadapter description that specifies the exact boundary between adapters and the\ncore security/license findings model: enumerate the core findings schema fields\n(e.g., finding_id, package_name, package_version, license_id,\nnormalized_license_type, severity, policy_state, confidence, timestamp), define\nthe SPDX-to-normalized finding mapping rules (how SPDX identifiers map to\nnormalized_license_type and license_id), and prescribe the evidence reference\nformat for SBOM lineage (e.g., canonical SBOM source URL/ID, package entry path,\ncomponent checksum and provenance fields). Ensure this contract is titled\n\"Adapter Contract\" and referenced by \"SBOM ingestion and SPDX normalization\nadapters\" and the \"core security/license findings model\" so implementations must\nproduce findings compatible with these fields and mappings.\n- Around line 12-13: Specify concrete inter-bundle compatibility and adapter\nboundaries: add a core_compatibility version range entry that references\nsecurity-01-unified-findings-model (e.g., semver range) in the\nlicense-compliance bundle manifest, define the inter-bundle hook interface\n(choose and document a single approach such as a shared registry schema named\nsbom_registry with JSON schema and API surface or a file-based export format\nnamed sbom_export_v1 and its file layout), state whether bundle_dependencies\nshould be declared (add bundle_dependencies: [\n\"security-01-unified-findings-model\" ] to the license-compliance manifest or\nreverse it if the security bundle should depend on license-compliance), and\nupdate manifest/registry/docs/signing sections to include required fields for\nregistry entry, docs pointer, and signing expectations so adapters can be built\nagainst these stable hooks.\n- Line 29: The dependency reference in proposal.md currently points to\nsecurity-02-eu-gdpr-baseline but should reference the core policy-pack change\npolicy-02-packs-and-modes (or else clarify distinct semantics) — update the\ndependency on line 29 to replace security-02-eu-gdpr-baseline with\npolicy-02-packs-and-modes if the intention is to indicate the shared policy-pack\nsemantics, or add one sentence in the rationale clarifying that\nsecurity-02-eu-gdpr-baseline is a separate vendor/supply-chain baseline and\nexplain how its semantics differ from policy-02-packs-and-modes (cross-reference\nsecurity-03-module-pii-gdpr-eu and design.md:44 where policy-pack interpretation\nis already referenced).\n\nIn\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`:\n- Line 7: Confirm that the core change \"security-01-unified-findings-model\" is\nplanned or implemented in the specfact-cli roadmap by checking specfact-cli's\nCHANGE_ORDER.md and the core repo; if it is planned or already merged, record\nthe exact core release or commit that provides the shared findings/report\ncontracts and add that version as the `core_compatibility` value for\n`nold-ai/specfact-license-compliance` in the spec (and document the same\nidentifier in TDD_EVIDENCE.md); if it is not planned, open/track a\nCHANGE_ORDER.md entry or coordination ticket in specfact-cli before implementing\nthis bundle and do not proceed until the required core compatibility version is\nagreed and documented.\n\nIn `@openspec/changes/security-02-module-license-compliance/tasks.md`:\n- Line 1: Replace the top-level header so the file uses a descriptive H1 like\nother OpenSpec files: change the existing \"# 1. Branch and dependency\nguardrails\" to \"# Tasks: security-02-module-license-compliance\" and then demote\nthe current header to a section header by adding \"## 1. Branch and dependency\nguardrails\" immediately below; update the headers in\nopenspec/changes/security-02-module-license-compliance/tasks.md to match this\npattern so it aligns with knowledge-01-module-memory-runtime/tasks.md.\n\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`:\n- Line 19: The task line \"3.4 Update registry metadata, docs references,\nsignatures, and any import allowlists required by the new bundle.\" should be\nreworded to clarify that signature artifacts are produced by the publish\nautomation and must not be manually committed; update the step (referencing the\ntask text \"Update registry metadata, docs references, signatures, and any import\nallowlists\") to say contributors should update registry metadata, docs, and\nimport allowlists as needed and ensure the publish workflow will generate\nsignatures, while pre-merge checks must rely on the signature/version\nenforcement gate rather than creating or committing signature files manually.\n\nIn `@packages/specfact-project/resources/templates/persona/default.md.j2`:\n- Line 20: The template currently dumps business and product with\ntojson(indent=2) which can produce noisy Markdown; update the persona template\n(default.md.j2) to either (A) replace the JSON dumps for the business and\nproduct blocks with explicit Jinja2 field render loops when those objects follow\npredictable schemas (use conditional checks on business.model,\nbusiness.revenue_streams, product.features, etc., and render as Markdown list\nitems) or (B) if those objects are freeform and must remain machine-readable,\nretain tojson(indent=2) but add a clear template comment above each dump\nexplaining the intentional machine-readable JSON embedding so future maintainers\nunderstand the choice. Ensure you modify the occurrences of tojson for the\nvariables business and product.\n\nIn `@packages/specfact-project/src/specfact_project/generators/template_paths.py`:\n- Around line 39-40: Remove the early return for templates_dir and instead run\nthe explicit override through the same path shaping and validation applied to\nauto-discovered roots: when templates_dir is provided, join/append subdir (if\nsubdir is set) to templates_dir, convert to a Path, and validate that it\ncontains files matching required_glob before returning it; ensure you use the\nsame logic/code paths that handle discovered roots so explicit overrides honor\nsubdir and required_glob (referencing the templates_dir, subdir and\nrequired_glob symbols).\n\nIn `@packages/specfact-project/src/specfact_project/import_runtime_patches.py`:\n- Around line 181-186: The patched wrapper uses signature.bind_partial(...)\nwhich omits defaulted parameters; after binding call bound.apply_defaults() to\npopulate missing defaults before passing bound.arguments into args_builder, so\nin patched (the function that does signature.bind_partial(*args, **kwargs) and\nthen built = args_builder(dict(bound.arguments))) insert bound.apply_defaults()\nand then continue with built transformation and runner(original, context,\nbuilt); keep existing replace(built, **kwargs) behavior intact.\n\nIn `@packages/specfact-project/src/specfact_project/utils/import_path_policy.py`:\n- Around line 443-468: discover_code_files normalizes file extensions only when\nbuilding ImportDiscoveryOptions from kwargs, causing inconsistency when callers\npass an ImportDiscoveryOptions instance; update the options branch to normalize\nextensions too by calling _normalize_extensions on options.extensions (or\nreplacing options.extensions with the normalized result) before passing options\nto _discover_code_files_with_options so both code paths accept extensions with\nor without a leading dot; reference functions/classes: discover_code_files,\nImportDiscoveryOptions, _normalize_extensions, and\n_discover_code_files_with_options.\n\nIn `@scripts/ensure_github_hierarchy_subissues.py`:\n- Around line 148-159: The loop over DEFAULT_EDGES repeatedly calls\n_subissue_numbers and _issue_node_id causing excess API calls; introduce simple\nin-memory caches (e.g., dicts keyed by parent number and by issue number) before\nthe loop to store fetched sub-issue sets and node IDs, consult the cache instead\nof re-calling _subissue_numbers(parent_num) and _issue_node_id(...) for the same\nparent_num/child_num, and only call the underlying functions on cache misses;\nstill honor args.dry_run, increment skipped/would_add as before, and pass the\ncached parent_id/child_id into _add_sub_issue when needed.\n- Around line 67-70: The JSON response handling is brittle: change the logic\nthat reads payload = json.loads(proc.stdout) so you first verify payload is a\ndict (isinstance(payload, dict)); only then check for \"errors\" in payload, and\nretrieve the result using payload.get(\"data\") instead of payload[\"data\"]; if\npayload is not a dict or payload.get(\"data\") is None (or missing), raise a clear\nRuntimeError that includes the raw payload or proc.stdout for debugging. Ensure\nyou reference the existing variables payload and proc when constructing the\nerror messages so failures are deterministic and informative.\n- Around line 43-51: The current loop building args uses -F for all scalar\nstring variables which triggers gh's `@file` expansion; update the logic that\nbuilds args (the args list and the variables dict handling) to use -f for string\nvalues (including string list items and repo-owner/repo-name) so they are passed\nliterally, and reserve -F only for non-string typed values (e.g., ints, bools)\nthat need type coercion; specifically, change the branch that checks\nisinstance(value, list) to emit repeated \"-f\" entries for string items, and in\nthe scalar branch emit \"-f\" when isinstance(value, str) else \"-F\" for\nnon-strings. Ensure the initial query part (f\"query={query}\") remains unchanged\nand keep skipping None values.\n\nIn `@tests/unit/specfact_project/test_import_runtime_policy.py`:\n- Around line 16-23: The test module currently calls\n_apply_import_runtime_patches() at import time which applies global patches too\nearly; remove the top-level call to _apply_import_runtime_patches and instead\ncreate a pytest fixture (e.g., import_runtime_patches_fixture) that imports\nspecfact_project.import_runtime_patches and calls apply_import_runtime_patches()\nin its setup and ensures proper teardown/unpatching in finalizer so patches\n(Path.rglob, CodeAnalyzer.analyze, import helpers) are scoped to the fixture;\nupdate tests that need the patch to request this fixture.\n\nIn `@tests/unit/workflows/test_sign_modules_on_approval.py`:\n- Around line 52-55: The assertions that check event trigger lists are brittle\ndue to ordering; update the tests to compare sets instead of lists: replace the\nexact-equality assertions on pr_review[\"types\"] and pr[\"types\"] with\norder-insensitive checks (e.g., assert set(pr_review[\"types\"]) == {\"submitted\"}\nand assert set(pr[\"types\"]) ==\n{\"opened\",\"synchronize\",\"reopened\",\"ready_for_review\"}) so the tests no longer\nfail when YAML ordering changes; locate and update the assertions referencing\npr_review[\"types\"] and pr[\"types\"] in test_sign_modules_on_approval.py.\n```\n\n

\n\n

🪄 Autofix (Beta)

\n\n✅ Autofix completed\n\n

\n\n---\n\n

ℹ️ Review info

\n\n

⚙️ Run configuration

\n\n**Configuration used**: Path: .coderabbit.yaml\n\n**Review profile**: ASSERTIVE\n\n**Plan**: Pro\n\n**Run ID**: `cc3e5b23-6543-4060-bc25-c7e4163cac5e`\n\n

\n\n

📥 Commits

\n\nReviewing files that changed from the base of the PR and between 11f3f61601cdad85d2dd0e853a69a0e1ab4e687d and 39750733a68cd1ac8b652b1c46abcc51d84aff60.\n\n

\n\n

⛔ Files ignored due to path filters (3)

\n\n* `registry/modules/specfact-project-0.41.4.tar.gz` is excluded by `!**/*.gz`\n* `registry/modules/specfact-project-0.41.5.tar.gz` is excluded by `!**/*.gz`\n* `registry/modules/specfact-project-0.41.6.tar.gz` is excluded by `!**/*.gz`\n\n

\n\n

📒 Files selected for processing (82)

\n\n* `.github/workflows/sign-modules-on-approval.yml`\n* `docs/bundles/project/import-migration.md`\n* `openspec/CHANGE_ORDER.md`\n* `openspec/changes/architecture-02-module-well-architected/.openspec.yaml`\n* `openspec/changes/architecture-02-module-well-architected/design.md`\n* `openspec/changes/architecture-02-module-well-architected/proposal.md`\n* `openspec/changes/architecture-02-module-well-architected/specs/architecture-well-architected-module/spec.md`\n* `openspec/changes/architecture-02-module-well-architected/tasks.md`\n* `openspec/changes/codebase-import-runtime-hardening/.openspec.yaml`\n* `openspec/changes/codebase-import-runtime-hardening/TDD_EVIDENCE.md`\n* `openspec/changes/codebase-import-runtime-hardening/design.md`\n* `openspec/changes/codebase-import-runtime-hardening/proposal.md`\n* `openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\n* `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n* `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n* `openspec/changes/enterprise-01-module-policy-client/.openspec.yaml`\n* `openspec/changes/enterprise-01-module-policy-client/design.md`\n* `openspec/changes/enterprise-01-module-policy-client/proposal.md`\n* `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\n* `openspec/changes/enterprise-01-module-policy-client/tasks.md`\n* `openspec/changes/enterprise-02-module-audit-client/.openspec.yaml`\n* `openspec/changes/enterprise-02-module-audit-client/design.md`\n* `openspec/changes/enterprise-02-module-audit-client/proposal.md`\n* `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\n* `openspec/changes/enterprise-02-module-audit-client/tasks.md`\n* `openspec/changes/finops-01-module-cost-outcome/.openspec.yaml`\n* `openspec/changes/finops-01-module-cost-outcome/design.md`\n* `openspec/changes/finops-01-module-cost-outcome/proposal.md`\n* `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\n* `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n* `openspec/changes/knowledge-01-module-memory-runtime/.openspec.yaml`\n* `openspec/changes/knowledge-01-module-memory-runtime/design.md`\n* `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\n* `openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\n* `openspec/changes/knowledge-01-module-memory-runtime/tasks.md`\n* `openspec/changes/knowledge-02-module-writeback/.openspec.yaml`\n* `openspec/changes/knowledge-02-module-writeback/design.md`\n* `openspec/changes/knowledge-02-module-writeback/proposal.md`\n* `openspec/changes/knowledge-02-module-writeback/specs/knowledge-writeback/spec.md`\n* `openspec/changes/knowledge-02-module-writeback/tasks.md`\n* `openspec/changes/review-resiliency-01-module/.openspec.yaml`\n* `openspec/changes/review-resiliency-01-module/design.md`\n* `openspec/changes/review-resiliency-01-module/proposal.md`\n* `openspec/changes/review-resiliency-01-module/specs/review-resiliency-module/spec.md`\n* `openspec/changes/review-resiliency-01-module/tasks.md`\n* `openspec/changes/security-01-module-sast-sca-secret/.openspec.yaml`\n* `openspec/changes/security-01-module-sast-sca-secret/design.md`\n* `openspec/changes/security-01-module-sast-sca-secret/proposal.md`\n* `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\n* `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n* `openspec/changes/security-02-module-license-compliance/.openspec.yaml`\n* `openspec/changes/security-02-module-license-compliance/design.md`\n* `openspec/changes/security-02-module-license-compliance/proposal.md`\n* `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\n* `openspec/changes/security-02-module-license-compliance/tasks.md`\n* `openspec/changes/security-03-module-pii-gdpr-eu/.openspec.yaml`\n* `openspec/changes/security-03-module-pii-gdpr-eu/design.md`\n* `openspec/changes/security-03-module-pii-gdpr-eu/proposal.md`\n* `openspec/changes/security-03-module-pii-gdpr-eu/specs/privacy-gdpr-module/spec.md`\n* `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n* `packages/specfact-project/module-package.yaml`\n* `packages/specfact-project/resources/templates/github-action.yml.j2`\n* `packages/specfact-project/resources/templates/persona/default.md.j2`\n* `packages/specfact-project/resources/templates/protocol.yaml.j2`\n* `packages/specfact-project/src/specfact_project/generators/plan_generator.py`\n* `packages/specfact-project/src/specfact_project/generators/protocol_generator.py`\n* `packages/specfact-project/src/specfact_project/generators/template_paths.py`\n* `packages/specfact-project/src/specfact_project/generators/workflow_generator.py`\n* `packages/specfact-project/src/specfact_project/import_cmd/commands.py`\n* `packages/specfact-project/src/specfact_project/import_runtime_patches.py`\n* `packages/specfact-project/src/specfact_project/sync/commands.py`\n* `packages/specfact-project/src/specfact_project/utils/import_path_policy.py`\n* `registry/index.json`\n* `registry/modules/specfact-project-0.41.4.tar.gz.sha256`\n* `registry/modules/specfact-project-0.41.5.tar.gz.sha256`\n* `registry/modules/specfact-project-0.41.6.tar.gz.sha256`\n* `registry/signatures/specfact-project-0.41.5.tar.sig`\n* `registry/signatures/specfact-project-0.41.6.tar.sig`\n* `scripts/ensure_github_hierarchy_subissues.py`\n* `tests/unit/specfact_project/test_import_runtime_policy.py`\n* `tests/unit/test_bundle_resource_payloads.py`\n* `tests/unit/workflows/test_sign_modules_on_approval.py`\n\n

\n\n

\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n

🧩 Analysis chain

\n\n🌐 Web query:\n\n`GitHub GraphQL latestReviews pagination limit pull request`\n\n💡 Result:\n\nIn GitHub’s GraphQL API, the PR’s “latestReviews” (a connection of pull request reviews) uses standard cursor-based pagination on the connection. Pagination limit (page size): - When paginating any GraphQL connection, GitHub requires you to pass either first or last. - The allowed value range for first/last is 1–100, so the maximum you can fetch per page is 100 items. How to paginate: - Query the connection with first: N (or last: N) and use pageInfo { endCursor hasNextPage } (or startCursor hasPreviousPage for last). - To fetch the next page, pass after: along with the next first: N. Notes on rate/node limits (practical ceiling): - Even if first/last can be up to 100, you may need smaller page sizes to avoid running into GraphQL query limits (points) or the total node limit (and to reduce query cost). Example pagination pattern (for any such reviews connection): query ($owner: String!, $name: String!, $after: String) { repository(owner: $owner, name: $name) { pullRequests(first: 100, after: $after) { nodes { number title } pageInfo { endCursor hasNextPage } } } } You would apply the same pagination approach to the PR’s latestReviews connection: request latestReviews(first: 100, after: ...) and iterate using pageInfo.endCursor until hasNextPage is false.\n\nCitations:\n\n- 1: https://docs.github.com/en/graphql/guides/using-pagination-in-the-graphql-api\n- 2: https://docs.github.com/en/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check PR history to understand typical reviewer patterns\ngit log --oneline --all --grep=\"Merge pull request\" | head -20\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 46\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check the workflow file for context\ncat -n .github/workflows/sign-modules-on-approval.yml | head -100\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 5186\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check recent PR activity and review patterns\ngit log --oneline --all | head -30\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 2235\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check if there are any recent PRs with many reviews in git history\ngit log --all --format=\"%H %s\" | grep -i \"merge pull request\" | head -10\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1124\n\n---\n\n🏁 Script executed (no clone):\n\n```shell:none\n# Query GitHub API to understand latestReviews semantics more clearly\ncurl -s \"https://docs.github.com/en/graphql/reference/objects#pullrequest\" | grep -A 10 \"latestReviews\" || echo \"Could not fetch directly, checking docs...\"\n```\n\nLength of output: 50345\n\n---\n\n\n\n

\n\n**Consider whether pagination is needed based on typical review patterns for this repository.**\n\nThe GraphQL query uses `latestReviews(first:100)` without pagination. GitHub's GraphQL API limits paginated results to 100 items per page, and `latestReviews` returns one review per reviewer. While pagination cursors are supported (via `pageInfo.endCursor` and `hasNextPage`), implementing pagination requires additional query complexity.\n\nFor typical team repositories with a modest number of reviewers, 100 is sufficient. If this repository historically has PRs with significantly more than 100 distinct reviewers, implement pagination; otherwise, document the 100-reviewer ceiling as an acceptable threshold.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn @.github/workflows/sign-modules-on-approval.yml around lines 68 - 81, The\nGraphQL query uses latestReviews(first:100) which can miss reviews if a PR has\n>100 distinct reviewers; update the sign workflow to handle pagination by\nlooping requests using pageInfo.hasNextPage and pageInfo.endCursor (aggregate\nnodes across pages) before computing trusted_review_count, referencing the\nexisting trusted_review_count calculation and the latestReviews(...) field;\nalternatively, if you decide 100 is an acceptable ceiling for this repo, add a\nclear comment in the workflow near latestReviews(first:100) explaining that the\n100-reviewer limit is intentional and documented.\n```\n\n

\n\n\n\n\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Python one-liner lacks explicit error handling for malformed responses.**\n\nIf the GraphQL response is missing expected keys (`data`, `repository`, `pullRequest`, or `latestReviews`), Python raises a `KeyError` that propagates through `set -euo pipefail`. While this fail-fast behavior is acceptable, a more descriptive error message would improve debugging. Consider wrapping in a try/except that emits a clearer notice before exit, or validate the structure first.\n\n\n\n

Example with explicit validation

\n\n```diff\n- | python3 -c \"import json,sys; data=json.load(sys.stdin); reviews=data['data']['repository']['pullRequest']['latestReviews']['nodes']; print(sum(1 for review in reviews if review.get('state') == 'APPROVED' and review.get('authorAssociation') in {'COLLABORATOR','MEMBER','OWNER'}))\"\n+ | python3 -c \"\n+import json, sys\n+data = json.load(sys.stdin)\n+try:\n+ reviews = data['data']['repository']['pullRequest']['latestReviews']['nodes']\n+except (KeyError, TypeError) as e:\n+ print(f'::error::GraphQL response missing expected structure: {e}', file=sys.stderr)\n+ sys.exit(1)\n+print(sum(1 for r in reviews if r.get('state') == 'APPROVED' and r.get('authorAssociation') in {'COLLABORATOR','MEMBER','OWNER'}))\n+\"\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn @.github/workflows/sign-modules-on-approval.yml at line 74, The current\nPython one-liner that parses the GraphQL JSON (the python3 -c \"import json,sys;\ndata=json.load(sys.stdin); reviews=...; print(...)\") can raise a KeyError on\nmissing keys; update it to validate the expected keys or wrap the parsing and\nkey access in a try/except that catches (KeyError, TypeError, ValueError) and\nprints a clear, descriptive error message to stderr (including which top-level\nkey is missing and the raw input snippet or its summary) before exiting with a\nnon-zero status so the GitHub Actions job fails with a useful message.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a top-level H1 heading and fix heading spacing for markdownlint compliance.**\n\nThe file starts with `## Why` instead of an H1 title. Additionally, lines 15–16 and 18–19 violate MD022 (headings should be surrounded by blank lines).\n\n\n\n

Proposed fix (partial)

\n\n```diff\n+# Proposal: codebase-import-runtime-hardening\n+\n ## Why\n```\n\nAnd for the capability headings:\n\n```diff\n ## Capabilities\n\n ### New Capabilities\n+\n - `codebase-import-runtime`: Default ignore policy, warning surfaces, and dynamic progress estimation for `specfact code import` runtime scans.\n\n ### Modified Capabilities\n+\n - `bundle-packaged-resources`: Project-bundle runtime generator templates become required packaged resources alongside prompts and other module-owned assets.\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 1-1: First line in a file should be a top-level heading\n\n(MD041, first-line-heading, first-line-h1)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/codebase-import-runtime-hardening/proposal.md` at line 1,\nChange the document to include a top-level H1 heading before the existing\ncontent (replace or precede the current \"## Why\" with an H1 like \"# Proposal\" or\n\"# Changes for codebase-import runtime hardening\"), and fix heading spacing\nviolations by adding a blank line above and below each heading that currently\nviolates MD022 (specifically the headings around the content at lines referenced\nin the review — the \"Why\" section and the capability headings mentioned in the\nproposed fix) so all headings (e.g., the \"Why\" heading and the capability\nheadings) are surrounded by blank lines and use the appropriate '#' level.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Make the paired-core artifact review explicit here.**\n\nThis checklist confirms availability, but it does not explicitly require reviewing the paired public OpenSpec/contracts in `nold-ai/specfact-cli` before implementation. Adding that step will reduce drift in change IDs, model names, and workflow assumptions. \n\nBased on learnings, \"When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\".\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/enterprise-01-module-policy-client/tasks.md` at line 4,\nUpdate checklist item for enterprise-01-policy-resolution-extension to\nexplicitly require reviewing the paired public OpenSpec/contracts in\nnold-ai/specfact-cli before implementation and documenting the minimum required\ncore_compatibility; add a sub-item that instructs the implementer to verify and\nrecord matching change IDs, model names, and workflow semantics between this\nchange and the paired specfact-cli artifacts (e.g., \"Review paired public\nOpenSpec/contracts in nold-ai/specfact-cli and confirm matching change IDs/model\nnames/workflow semantics; document minimum core_compatibility\"). Ensure the new\ntext appears alongside the existing 1.2 checklist so reviewers cannot skip the\npaired-core artifact review step.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add an explicit review step for the paired public core artifacts.**\n\nVerifying that the upstream change exists is weaker than reviewing the paired public OpenSpec/contracts that this bundle will implement against. Please call that out directly so the audit client does not drift from the authoritative core contract surface. \n\nBased on learnings, \"When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\".\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/enterprise-02-module-audit-client/tasks.md` at line 4,\nUpdate the task checklist in enterprise-02-module-audit-client/tasks.md to add\nan explicit step that reviewers must inspect the paired public core\nOpenSpec/contracts (not just upstream sequencing) for the\n`enterprise-02-rbac-and-audit-trail` change and any linked artifacts from\n`enterprise-01-module-policy-client`; call out that reviewers should confirm the\nauthoritative public artifacts in specfact-cli (or equivalent public repo) and\nrecord the minimum required `core_compatibility` after that review. Ensure the\nnew line references the paired artifact names\n(`enterprise-02-rbac-and-audit-trail`, `enterprise-01-module-policy-client`,\nspecfact-cli) and replaces or augments the existing weaker \"Confirm paired core\nchange\" item.\n```\n\n

\n\n\n\n\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Consider using a descriptive H1 title for consistency.**\n\nThe file starts with `# 1. Branch and dependency guardrails`, which is technically an H1 but uses a numbered format. Other OpenSpec files use descriptive titles (e.g., `# Change: ...`, `# Design: ...`). For consistency, consider:\n\n```diff\n-# 1. Branch and dependency guardrails\n+# Tasks: knowledge-01-module-memory-runtime\n+\n+## 1. Branch and dependency guardrails\n```\n\nThis is a minor stylistic note—the current format is functional.\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-01-module-memory-runtime/tasks.md` at line 1,\nReplace the numeric H1 \"# 1. Branch and dependency guardrails\" with a\ndescriptive H1 to match other OpenSpec files (for example \"Change: Branch and\ndependency guardrails\" or \"Design: Branch and dependency guardrails\"); update\nthe header string in the tasks.md file so the top-level title uses a descriptive\nlabel rather than a leading number to maintain consistency across specs.\n```\n\n

\n\n\n\n\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Consider using a descriptive H1 title for consistency with other OpenSpec files.**\n\nSame pattern as `knowledge-01-module-memory-runtime/tasks.md`—a descriptive title like `# Tasks: security-02-module-license-compliance` followed by `## 1.` would align better with proposal/design naming conventions.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-02-module-license-compliance/tasks.md` at line 1,\nReplace the top-level header so the file uses a descriptive H1 like other\nOpenSpec files: change the existing \"# 1. Branch and dependency guardrails\" to\n\"# Tasks: security-02-module-license-compliance\" and then demote the current\nheader to a section header by adding \"## 1. Branch and dependency guardrails\"\nimmediately below; update the headers in\nopenspec/changes/security-02-module-license-compliance/tasks.md to match this\npattern so it aligns with knowledge-01-module-memory-runtime/tasks.md.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟠 Major_\n\n**Honor `subdir` and `required_glob` for explicit template overrides too.**\n\nThe early return bypasses the same path shaping and validation applied to auto-discovered roots, so `templates_dir=...` can silently point generators at the wrong directory or skip the required template existence check. \n\n

Proposed fix

\n\n```diff\n if templates_dir is not None:\n- return Path(templates_dir)\n+ candidate = _target(Path(templates_dir), subdir)\n+ if _matches_required_glob(candidate, required_glob):\n+ return candidate\n+ raise RuntimeError(\n+ f\"Explicit template root did not match required_glob={required_glob!r}: {candidate}\"\n+ )\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@packages/specfact-project/src/specfact_project/generators/template_paths.py`\naround lines 39 - 40, Remove the early return for templates_dir and instead run\nthe explicit override through the same path shaping and validation applied to\nauto-discovered roots: when templates_dir is provided, join/append subdir (if\nsubdir is set) to templates_dir, convert to a Path, and validate that it\ncontains files matching required_glob before returning it; ensure you use the\nsame logic/code paths that handle discovered roots so explicit overrides honor\nsubdir and required_glob (referencing the templates_dir, subdir and\nrequired_glob symbols).\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\nset -euo pipefail\n\npython - <<'PY'\nimport ast\nfrom pathlib import Path\n\ntargets = {\"_analyze_codebase\", \"_extract_relationships_and_graph\"}\n\nfor path in Path(\".\").rglob(\"commands.py\"):\n if \"packages/specfact-project/src/specfact_project\" not in str(path):\n continue\n\n tree = ast.parse(path.read_text(encoding=\"utf-8\"))\n for node in ast.walk(tree):\n if isinstance(node, ast.FunctionDef) and node.name in targets:\n args = [arg.arg for arg in node.args.args]\n defaults = [None] * (len(args) - len(node.args.defaults)) + list(node.args.defaults)\n print(f\"{path}:{node.lineno} {node.name}\")\n for arg, default in zip(args, defaults):\n rendered = \"\" if default is None else ast.unparse(default)\n print(f\" - {arg}: {rendered}\")\nPY\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 711\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\nset -euo pipefail\n\n# Read the import_runtime_patches.py file to understand context around lines 181-186\ncat -n packages/specfact-project/src/specfact_project/import_runtime_patches.py | sed -n '160,200p'\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1993\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\nset -euo pipefail\n\n# Search for where patched wrapper is called and how it's applied to actual functions\nrg -n \"patched.*=\" packages/specfact-project/src/specfact_project/import_runtime_patches.py | head -20\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 417\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\nset -euo pipefail\n\n# Get the full function context for the patched function (broader range)\ncat -n packages/specfact-project/src/specfact_project/import_runtime_patches.py | sed -n '150,220p'\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 3461\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\nset -euo pipefail\n\n# Find all functions that look like args_builder functions\nrg -n \"def.*_from_mapping|arguments\\[\" packages/specfact-project/src/specfact_project/import_runtime_patches.py\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 951\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\nset -euo pipefail\n\n# Get the complete view of how _install_patch is being used\nrg -B5 -A5 \"_install_patch\" packages/specfact-project/src/specfact_project/import_runtime_patches.py\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1119\n\n---\n\n\n\n

\n\n**Use `bound.apply_defaults()` to preserve callable semantics across patched invocations.**\n\nThe `patched()` wrapper currently relies on `bind_partial()` without `apply_defaults()`, leaving omitted defaulted parameters out of `bound.arguments`. While the current args_builders defensively use `.get()` calls for optional parameters (lines 173, 217), this pattern is fragile—any future args_builder using direct dictionary access will break when defaults are omitted. The proper fix is to restore default values before building arguments, ensuring the wrapper semantically mirrors the original callable.\n\n

Proposed fix

\n\n```diff\n def patched(*args: Any, **kwargs: Any) -> Any:\n bound = signature.bind_partial(*args, **kwargs)\n+ bound.apply_defaults()\n built = args_builder(dict(bound.arguments))\n if kwargs:\n built = replace(built, **kwargs)\n return runner(original, context, built)\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@packages/specfact-project/src/specfact_project/import_runtime_patches.py`\naround lines 181 - 186, The patched wrapper uses signature.bind_partial(...)\nwhich omits defaulted parameters; after binding call bound.apply_defaults() to\npopulate missing defaults before passing bound.arguments into args_builder, so\nin patched (the function that does signature.bind_partial(*args, **kwargs) and\nthen built = args_builder(dict(bound.arguments))) insert bound.apply_defaults()\nand then continue with built transformation and runner(original, context,\nbuilt); keep existing replace(built, **kwargs) behavior intact.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟠 Major_\n\n**Normalize extensions on the `options=` path as well.**\n\nRight now the kwargs form accepts both `{\"py\"}` and `{\".py\"}`, but the public `ImportDiscoveryOptions` form only works for the dotted variant because normalization happens in just one branch. That makes the new API silently inconsistent for callers switching to the options object. \n\n

Proposed fix

\n\n```diff\n def discover_code_files(\n repo_root: Path,\n options: ImportDiscoveryOptions | None = None,\n **kwargs: Any,\n ) -> ImportDiscoveryResult:\n@@\n elif kwargs:\n unexpected = \", \".join(sorted(str(key) for key in kwargs))\n raise TypeError(f\"Unexpected discovery keyword overrides with options object: {unexpected}\")\n+ else:\n+ options = ImportDiscoveryOptions(\n+ extensions=_normalize_extensions(options.extensions),\n+ entry_point=options.entry_point,\n+ include_tests=options.include_tests,\n+ ignore_patterns=options.ignore_patterns,\n+ allow_hidden=options.allow_hidden,\n+ heavy_ignored_entry_threshold=options.heavy_ignored_entry_threshold,\n+ large_repo_file_threshold=options.large_repo_file_threshold,\n+ max_files=options.max_files,\n+ )\n return _discover_code_files_with_options(\n repo_root,\n options,\n )\n```\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@packages/specfact-project/src/specfact_project/utils/import_path_policy.py`\naround lines 443 - 468, discover_code_files normalizes file extensions only when\nbuilding ImportDiscoveryOptions from kwargs, causing inconsistency when callers\npass an ImportDiscoveryOptions instance; update the options branch to normalize\nextensions too by calling _normalize_extensions on options.extensions (or\nreplacing options.extensions with the normalized result) before passing options\nto _discover_code_files_with_options so both code paths accept extensions with\nor without a leading dot; reference functions/classes: discover_code_files,\nImportDiscoveryOptions, _normalize_extensions, and\n_discover_code_files_with_options.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟠 Major_\n\n**Avoid applying the global runtime patch during module import.**\n\nThis runs before pytest fixtures can scope or restore the mutated state, so unrelated tests can become order-dependent once `Path.rglob`, `CodeAnalyzer.analyze`, or the import command helpers are patched for the whole process. Please move this behind a fixture that owns setup/teardown for the patch lifecycle. \n\nAs per coding guidelines, `tests/**/*.py`: Contract-first and integration tests: migration suites, bundle validation, and flakiness.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@tests/unit/specfact_project/test_import_runtime_policy.py` around lines 16 -\n23, The test module currently calls _apply_import_runtime_patches() at import\ntime which applies global patches too early; remove the top-level call to\n_apply_import_runtime_patches and instead create a pytest fixture (e.g.,\nimport_runtime_patches_fixture) that imports\nspecfact_project.import_runtime_patches and calls apply_import_runtime_patches()\nin its setup and ensures proper teardown/unpatching in finalizer so patches\n(Path.rglob, CodeAnalyzer.analyze, import helpers) are scoped to the fixture;\nupdate tests that need the patch to request this fixture.\n```\n\n

\n\n\n\n\n**Review continued from previous batch...**\n\n> [!NOTE]\n> Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it.\n\n## Fixes Applied Successfully\n\nFixed 29 file(s) based on 40 unresolved review comments.\n\n\n\n**Files modified:**\n- `docs/bundles/project/import-migration.md`\n- `openspec/CHANGE_ORDER.md`\n- `openspec/changes/architecture-02-module-well-architected/design.md`\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\n- `openspec/changes/codebase-import-runtime-hardening/design.md`\n- `openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n- `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\n- `openspec/changes/enterprise-02-module-audit-client/design.md`\n- `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\n- `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n- `openspec/changes/knowledge-01-module-memory-runtime/design.md`\n- `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\n- `openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\n- `openspec/changes/knowledge-02-module-writeback/design.md`\n- `openspec/changes/knowledge-02-module-writeback/proposal.md`\n- `openspec/changes/review-resiliency-01-module/proposal.md`\n- `openspec/changes/security-01-module-sast-sca-secret/design.md`\n- `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n- `openspec/changes/security-02-module-license-compliance/design.md`\n- `openspec/changes/security-02-module-license-compliance/proposal.md`\n- `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n- `packages/specfact-project/resources/templates/persona/default.md.j2`\n- `scripts/ensure_github_hierarchy_subissues.py`\n- `tests/unit/workflows/test_sign_modules_on_approval.py`\n\n**Commit:** `0672f50fc279db70e7351ed9079417d641efe976`\n\nThe changes have been pushed to the `promote/pr-236-to-main` branch.\n\n**Time taken:** `16m 31s`\n\n_⚠️ Potential issue_ | _🟠 Major_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Verify whether documented thresholds are implemented in runtime code.\n# Expected: concrete constants/checks for file count, repo size, and commit count (or absence thereof).\n\nrg -n -C3 --type=py '100000|100,000|10\\s*GB|commit|heavy|threshold|warn' packages/specfact-project/src/specfact_project\nrg -n -C3 --type=py 'remaining time|provisional|about five minutes|fixed-duration' packages/specfact-project/src/specfact_project\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 50385\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Find constant definitions for thresholds\nrg -n \"_DEFAULT_HEAVY_IGNORED_ENTRY_THRESHOLD|_DEFAULT_LARGE_REPO_FILE_THRESHOLD\" packages/specfact-project/src/specfact_project/utils/import_path_policy.py -A 1 -B 1\n\n# Search for any repository size (bytes/GB) or commit count thresholds\nrg -n \"10.*1024|1024.*1024|100.*1000|commit.*count|repo.*size|bytes|GB\" packages/specfact-project/src/specfact_project/utils/import_path_policy.py\n\n# Check for provisionalETA build logic that mentions duration\nrg -n \"_build_provisional_eta|provisional\" packages/specfact-project/src/specfact_project/utils/import_path_policy.py -A 5\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1402\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Get the full _build_provisional_eta function\nsed -n '346,365p' packages/specfact-project/src/specfact_project/utils/import_path_policy.py\n\n# Get the full _build_warnings function\nsed -n '327,343p' packages/specfact-project/src/specfact_project/utils/import_path_policy.py\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1344\n\n---\n\n\n\n

\n\n**Correct threshold values in documentation.**\n\nLines 39-40 claim import warnings trigger at `>10,000 ignored entries`, `~100,000 files`, `~10 GB`, and `>100,000 commits`. The runtime implementation uses only file-count and entry-count thresholds:\n\n- Heavy ignored entry threshold: **500** entries (not >10,000)\n- Large repository file threshold: **1,000** files (not ~100,000)\n- No GB or commit-count thresholds exist in the code\n\nUpdate the documentation to reflect the actual configured thresholds, or generalize wording to \"configured thresholds\" as originally suggested if the values are intended to be user-configurable.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@docs/bundles/project/import-migration.md` around lines 39 - 40, Update the\ndoc text that currently lists thresholds (>10,000 ignored entries, ~100,000\nfiles, ~10 GB, >100,000 commits) to match the implementation: state the heavy\nignored-entry threshold is 500 entries and the large-repo file threshold is\n1,000 files, and remove references to GB or commit-count thresholds (or replace\nthe fixed values with a note that the system uses configured thresholds) so the\nsentence about remaining-time estimates refers to repositories above those\nactual/configured thresholds; update the phrases that mention \"ignored artifact\ntrees\" and \"Remaining time is based on...\" to reflect the corrected thresholds\nor that such limits are configurable.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit b672278\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add trailing newline to satisfy docs lint.**\n\nLine 272 is missing the final newline (MD047).\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 272-272: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@docs/bundles/project/import-migration.md` at line 272, Add a final trailing\nnewline to the markdown file by ensuring the last line containing \"**Happy\nimporting!** 🚀\" ends with a newline character; simply append a newline after\nthat line so the file ends with a blank line to satisfy MD047.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a trailing newline to pass markdownlint gate.**\n\nLine 129 is the file’s last line without a terminating newline (MD047).\n\n\n

Suggested fix

\n\n```diff\n | peer-deps | 01 | ✅ module-bundle-deps-auto-install (archived 2026-04-05) | [`#135`](https://github.com/nold-ai/specfact-cli-modules/issues/135) | — |\n+\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 129-129: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/CHANGE_ORDER.md` at line 129, The file's last line (the table row\ncontaining \"| peer-deps | 01 | ✅ module-bundle-deps-auto-install (archived\n2026-04-05) | [`#135`](https://github.com/nold-ai/specfact-cli-modules/issues/135)\n| — |\") is missing a terminating newline which triggers MD047; add a single\ntrailing newline character at the end of CHANGE_ORDER.md so the file ends with a\nnewline and re-run markdownlint to confirm the warning is cleared.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Description: Check if architecture-02-module-well-architected is referenced in CHANGE_ORDER and import hardening specs\n\n# Search CHANGE_ORDER for architecture-02 references\nrg -n \"architecture-02\" openspec/CHANGE_ORDER.md || echo \"No architecture-02 references found in CHANGE_ORDER\"\n\n# Check if import hardening specs reference architecture module\nrg -n \"architecture-02\\|specfact-architecture\" openspec/changes/codebase-import-runtime-hardening/ || echo \"No architecture references in import hardening specs\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 622\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check CHANGE_ORDER context for architecture-02 ordering and batching\nrg -B5 -A5 \"architecture-02-module-well-architected\" openspec/CHANGE_ORDER.md\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 5043\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Verify if paired core change architecture-02-well-architected-review exists in specfact-cli\nrg -r \"architecture-02-well-architected-review\\|architecture.*well-architected\" openspec/ || echo \"No matches found in specfact-cli openspec\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 50377\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check if PR description or commits indicate intentional batching of architecture-02 with this PR\ngit log --oneline --all | head -20\ngit show HEAD --stat | head -30\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 3011\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check if design.md is new or modified, and what the overall PR scope is\ngit diff --name-status HEAD~1 HEAD | head -30\ngit show HEAD:openspec/changes/architecture-02-module-well-architected/design.md 2>/dev/null | head -5 || echo \"File not in HEAD\"\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 651\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Check PR description or commit message for stated scope\ngit log -1 --format=%B HEAD\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 214\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Understand the actual scope of changes in this repository state\n# Check if packages/specfact-architecture/ exists\nfind . -type d -name \"*architecture*\" | grep -E \"packages|modules\" | head -20\nls -la openspec/changes/architecture-02-module-well-architected/ 2>/dev/null | head -20\ngit status\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 711\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/antml:thinking\nNeed to understand: is the PR actually shipping architecture-02 module code, or just spec/design docs? And what is the relationship to import hardening work?\n`#/bin/bash`\n# Check what's actually in this change directory and understand PR intent\nls -R openspec/changes/architecture-02-module-well-architected/ 2>/dev/null | head -50\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 439\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Verify if there are actual implementation files under packages/specfact-architecture/\nfind packages -type d -name \"*architecture*\" 2>/dev/null || echo \"No architecture package directory found\"\nfind src -type d -name \"*architecture*\" 2>/dev/null || echo \"No architecture source directory found\"\n# List what's actually in packages/\nls -la packages/ | head -20\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 579\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Understand PR intent: check what actually changed between branches\n# Look at the current PR's commit to see what files were modified\ngit show HEAD --stat | head -50\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 2849\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Verify if paired core work exists for architecture-02\n# Check if there's a corresponding architecture change in specfact-cli openspec\nfind openspec/changes -type d -name \"*architecture-02*\" 2>/dev/null || echo \"No architecture-02 changes in specfact-cli\"\nls -la openspec/changes/ | grep -i architecture || echo \"No architecture changes found\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 145\n\n---\n\n\n\n

\n\n**Verify paired core change status before shipping architecture-02 module design.**\n\nArchitecture-02 is properly sequenced in CHANGE_ORDER as order-03 change under parent epic `#216`. However, the design acknowledges a critical prerequisite: \"A new core change `architecture-02-well-architected-review` must be created and synced into `specfact-cli` before module integration\" (line 50). \n\nConfirm that the paired core change has been created in `specfact-cli` and is available for module binding. The design defers module implementation to step 2 of the migration plan, contingent on core contract stability. Before merging, verify:\n- Core change `architecture-02-well-architected-review` exists in `specfact-cli` and defines the findings contract\n- Module-to-core binding points (adapter contracts, report schema) are finalized and tested in specfact-cli\n- Migration plan sequencing aligns with actual core availability and registry timeline\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 30-30: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` around\nlines 1 - 57, Ensure the paired core change\n\"architecture-02-well-architected-review\" exists and is synced into specfact-cli\nbefore merging this module design: verify the core change defines the\nfindings/report contract referenced by packages/specfact-architecture, confirm\nthe module-to-core binding points (adapter contracts and report schema used by\nthe analyzer adapters and rule-resource translation) are finalized and tested\nagainst specfact-cli, update CHANGE_ORDER (order-03) and the Migration Plan to\nreflect actual core availability and registry timeline, and block or defer\nmerging of the architecture-02 module design until those confirmations/pass CI\ntests are completed.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit b672278\n_⚠️ Potential issue_ | _🟠 Major_\n\n**Core contract dependency acknowledged but not verified.**\n\nLine 50 addresses the previous review finding by noting that `architecture-02-well-architected-review` must be created in `specfact-cli` before module integration. However, the linked repositories context from specfact-cli confirms this core contract does not yet exist. Merging this design document before the paired core contract is defined risks specification drift and incompatible adapter implementations.\n\nConsider:\n- Deferring merge of this design until the core contract is created and stable in specfact-cli, or\n- Adding explicit blockers/dependencies to track that module implementation cannot proceed until the core contract exists\n\n\n\nBased on learnings, when a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\n50, The document references a required core contract\narchitecture-02-well-architected-review that is not present in specfact-cli; to\nfix, block merging of this design until that core change is created and synced\nin specfact-cli or explicitly add a dependency/blocker statement in this file\nnoting that module integration and any references to\narchitecture-02-well-architected-review (and overlaps with\narchitecture-01-solution-layer) are disallowed until the paired specfact-cli\nchange exists and is marked stable; update design.md to include a clear\ndependency checklist and a gating sentence that prevents implementation work\nuntil specfact-cli contains the architecture-02-well-architected-review\nartifact.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit b672278\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Add trailing newline.**\n\nStatic analysis (markdownlint MD047) requires files to end with a single newline character.\n\n\n\n

📝 Proposed fix

\n\n```diff\n - Should interface diff support start with one ecosystem or ship as a provider abstraction from the first implementation?\n+\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\n57, The file ends without a trailing newline which violates markdownlint MD047;\nopen the file containing the line \"Should interface diff support start with one\necosystem or ship as a provider abstraction from the first implementation?\"\n(design.md) and add a single newline character at the end of the file so it ends\nwith exactly one trailing newline.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🔴 Critical_\n\n

🧩 Analysis chain

\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Description: Search for architecture findings schema definitions in core and modules repos\n\n# Check if a separate architecture findings schema exists\nrg -n \"class.*ArchitectureFinding\\|architecture.*schema\\|ArchitectureReport\" --type=py --type=md || echo \"No separate architecture schema found\"\n\n# Verify ReviewFinding is used for architecture category\nrg -n \"category.*architecture|architecture.*category\" openspec/specs/review-finding-model/spec.md\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 109\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read the proposal.md file to verify the adapter contract schema (lines 15-22)\necho \"=== Reading proposal.md lines 15-22 ===\"\nsed -n '15,22p' openspec/changes/architecture-02-module-well-architected/proposal.md\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 934\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Search for ReviewFinding model definition in core repo\necho \"=== Searching for ReviewFinding model definition ===\"\nrg -n \"class ReviewFinding|ReviewFinding.*=|architecture.*findings\" --type=py --type=md | head -30\n\necho \"\"\necho \"=== Checking review-finding-model spec for architecture mentions ===\"\nrg -n \"architecture\" openspec/specs/review-finding-model/spec.md || echo \"No matches found\"\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 4816\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Look for the actual ReviewFinding schema definition structure\necho \"=== Searching for ReviewFinding fields/schema ===\"\nrg -n \"severity|category|tool|rule|file|line|message|fixable\" openspec/specs/review-finding-model/spec.md | head -50\n```\n\nRepository: nold-ai/specfact-cli\n\nLength of output: 803\n\n---\n\n\n\n

\n\n**Adapter contract schema must align with core ReviewFinding model.**\n\nThe Adapter Contract (lines 19-20) defines required fields as `id`, `type`, `severity`, `description`, `source`, `timestamp`, `evidence_refs`, but the actual `ReviewFinding` model in specfact-cli core (`openspec/specs/review-finding-model/spec.md` line 11) specifies: `category`, `severity`, `tool`, `rule`, `file`, `line`, `message`, `fixable`. Only `severity` overlaps.\n\nThe pylint-runner spec confirms architecture findings must emit `ReviewFinding` with `category=\"architecture\"` and `tool=\"pylint\"` (pylint-runner/spec.md line 17), establishing that the module must produce the core ReviewFinding schema, not a custom adapter schema.\n\nUpdate the Adapter Contract to map analyzer outputs to ReviewFinding fields: `category` (set to `\"architecture\"`), `tool` (analyzer name), `rule` (violation rule ID), `file` and `line` (violation locations), `message` (human-readable description), and `severity` (error/warning/info). This ensures architecture findings flow correctly through the core review model boundary without custom adaptation.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` around\nlines 15 - 22, Update the \"Adapter Contract\" section so it maps analyzer outputs\nto the core ReviewFinding model instead of a custom schema: replace the\n\"Required Core Findings Schema Fields\" and \"Analyzer Output Mapping\"\ndescriptions with mapping to ReviewFinding fields — set category=\"architecture\",\ntool=, rule=, file=, line=, message=, and\nseverity=; retain evidence_refs only as supplemental\nreferences but ensure primary location data uses file/line; align wording with\nthe ReviewFinding spec and mention pylint-runner expectation that category must\nbe \"architecture\" and tool \"pylint\".\n```\n\n

📝 Proposed fix

\n\n```diff\n - **Sanitized**: false\n+\n```\n

\n\n\n\n

📝 Committable suggestion

\n\n\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 54-54: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` at line\n54, The file ends without a trailing newline (see the line containing\n\"**Sanitized**: false\" in proposal.md); add a single newline character at the\nend of the file so the file terminates with exactly one trailing newline to\nsatisfy markdownlint MD047.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Fix missing trailing newline at EOF.**\n\nLine 93 needs a terminal newline to satisfy markdownlint MD047.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 93-93: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/codebase-import-runtime-hardening/design.md` at line 93, Add\na terminal newline to the end of the document so the final line \"None for\nimplementation start; warning thresholds can be tuned in-code if test evidence\nshows the initial defaults are too noisy.\" ends with a newline (satisfy\nmarkdownlint MD047); simply ensure the file's EOF contains a trailing newline\ncharacter.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Append a final newline for MD047 compliance.**\n\nLine 19 ends the file without a single trailing newline.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 19-19: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\nat line 19, The file ends without a trailing newline causing MD047; append a\nsingle final newline character to the end of the spec so the last line \"**AND**\nthe failure message SHALL name the missing template path so the packaging defect\ncan be corrected before publish\" is terminated by a newline (i.e., ensure the\nfile ends with one newline character).\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add the missing EOF newline.**\n\nLine 57 should end with a trailing newline (MD047).\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 57-57: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\nat line 57, The file ends without a trailing newline on the final line\ncontaining \"- **AND** any early estimate before full discovery SHALL be labeled\nas provisional rather than a fixed promise\"; open the file and add a single\nnewline character (EOF newline) after that line so the document ends with a\ntrailing newline to satisfy MD047.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add trailing newline at EOF.**\n\nLine 32 should be followed by a single newline to clear MD047.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 32-32: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/codebase-import-runtime-hardening/tasks.md` at line 32, Add\na single trailing newline at the end of\nopenspec/changes/codebase-import-runtime-hardening/tasks.md so the final line \"-\n[ ] 5.4 Commit, push, and open or update the PR to `dev` after verification is\ngreen.\" is followed by one newline (fixes MD047); simply ensure the file ends\nwith a single blank line.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add trailing newline to satisfy MD047.**\n\nThe file is missing a trailing newline character after line 57.\n\n\n\n

📝 Proposed fix

\n\nAdd a single newline after the last line of content:\n\n```diff\n ## Open Questions\n \n - Which queue storage format best balances resilience and inspectability for the initial release?\n - How should retry cadence and dead-letter behavior be surfaced in the first client contract?\n+\n```\n\n

\n\n\n\n

📝 Committable suggestion

\n\n> ‼️ **IMPORTANT**\n> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.\n\n```suggestion\n# Design\n\n## Context\n\nThe five-pillar enterprise design keeps server contracts out of scope for this wave, but it still needs a client-side audit bundle that can prepare, queue, sign, and inspect governance events. This module must interoperate with the paired core audit schema and with the enterprise policy client while remaining safe for disconnected or partially configured environments.\n\n## Goals / Non-Goals\n\n**Goals:**\n\n- Define the package structure and command ownership for `specfact-enterprise-audit`.\n- Emit signed, privacy-aware audit events aligned with the paired core schema.\n- Support local queueing and retry/inspection behavior for events that cannot be delivered immediately.\n- Keep event metadata structured enough for later reconciliation and drift analytics.\n\n**Non-Goals:**\n\n- Implement the enterprise audit service or server-side storage.\n- Replace the paired core audit-event schema or RBAC semantics.\n- Require immediate network delivery for every governance action.\n\n## Decisions\n\n### 1. Ship audit emission as its own enterprise bundle\n\n- **Decision**: Create `packages/specfact-enterprise-audit/` with dedicated emission and inspection commands.\n- **Why**: Audit transport, buffering, and event privacy are separate concerns from policy sync or base governance logic.\n- **Alternative considered**: Combine audit behavior with the enterprise policy bundle. Rejected because it couples two independently deployable surfaces.\n\n### 2. Queue first, deliver later when necessary\n\n- **Decision**: The bundle records deterministic local queue metadata for events that cannot be delivered immediately.\n- **Why**: Enterprise governance actions must not be lost because a remote endpoint is temporarily unavailable.\n- **Alternative considered**: Fail the originating action whenever the audit backend is unavailable. Rejected because it creates brittle runtime behavior for disconnected workflows.\n\n### 3. Keep payloads privacy-aware by design\n\n- **Decision**: Audit payloads include structured event metadata and references, not raw sensitive content.\n- **Why**: Audit surfaces must preserve accountability without leaking governed data.\n- **Alternative considered**: Store raw payload snapshots for debugging. Rejected because it conflicts with the security/privacy posture of the broader platform.\n\n## Risks / Trade-offs\n\n- **Risk**: Local queue growth may become operationally noisy. → **Mitigation**: provide inspection commands and deterministic receipt/retention metadata.\n- **Risk**: Delivery semantics may evolve with the future server implementation. → **Mitigation**: keep this change focused on client-side event preparation and queueing contracts.\n- **Risk**: Overly sparse payloads could weaken audit usefulness. → **Mitigation**: preserve event type, actor role, target references, and source rule/policy identifiers in the schema mapping.\n\n## Migration Plan\n\n1. Confirm the paired core audit/RBAC contracts are stable enough for module integration.\n2. Implement package structure, signing helpers, queue storage, and inspection commands.\n3. Publish docs, registry metadata, signatures, and compatibility range together.\n\n## Open Questions\n\n- Which queue storage format best balances resilience and inspectability for the initial release?\n- How should retry cadence and dead-letter behavior be surfaced in the first client contract?\n\n```\n\n

\n\n\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 30-30: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/enterprise-02-module-audit-client/design.md` around lines 1\n- 57, The file ending after the \"## Open Questions\" section (look for the\ntop-level heading \"# Design\" or the \"## Context\" / \"## Open Questions\" markers)\nis missing a trailing newline; to fix, open the markdown file for writing and\nappend a single newline character at the end of the file so the last line (after\n\"How should retry cadence and dead-letter behavior be surfaced in the first\nclient contract?\") ends with a newline to satisfy MD047.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Append final newline for markdownlint compliance.**\n\nLine 30 is missing the single trailing newline required by MD047.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 30-30: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\nat line 30, Append a single trailing newline to the end of the markdown file so\nthe final line \"**THEN** it records the session outcome as `rule-updated` in the\nnormalized FinOps evidence\" ends with a newline (fixing MD047); ensure no other\nwhitespace changes are made.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Ensure file ends with one trailing newline.**\n\nLine 27 currently lacks the final newline required by MD047.\n\n\nBased on learnings, module signature artifacts are produced by publish automation, and this task wording is correctly aligned.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 27-27: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/finops-01-module-cost-outcome/tasks.md` at line 27, The file\nends without a trailing newline causing MD047; add a single trailing newline to\nthe end of the file so the final checklist line \"- [ ] 4.5 Open the modules PR\nto `dev`, cross-link paired telemetry/FinOps changes, and note any deferred\nprovider integrations as follow-up issues.\" is terminated by a newline character\n(ensure only one final newline).\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a trailing newline at EOF.**\n\nMinor markdownlint compliance fix (MD047).\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 55-55: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-01-module-memory-runtime/design.md` at line 55,\nAdd a trailing newline at the end of the file by ensuring the final line \"-\nShould search support only tags and keywords initially, or also relationship\ntraversal commands?\" is followed by a single newline character (i.e., ensure EOF\nends with a newline) to satisfy markdownlint MD047.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a single trailing newline at EOF.**\n\nThis still trips MD047 lint checks.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 52-52: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md` at line 52, Add a\nsingle trailing newline at the end of the markdown file that contains the line\n\"- **Sanitized**: false\" (the proposal.md for the knowledge-02-module-writeback\nchange) so the file ends with exactly one newline character; ensure there are no\nextra blank lines or removal of other content and save the file to satisfy\nMD047.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟠 Major_\n\n**Adapter contract at Line 19 drifts from the core review finding schema.**\n\nThis proposal defines `id/title/description/location/timestamp/confidence/evidence_refs` and `Critical/High/Medium/Low`, but `openspec/specs/review-finding-model/spec.md` uses `category/severity/tool/rule/file/line/message/fixable` with severity enum `error|warning|info`. Please align this section to the core contract to avoid incompatible payloads.\n\n

Proposed alignment patch

\n\n```diff\n-- **Core Findings Schema Fields**: `id` (stable finding identifier), `title` (human-readable finding title), `description` (detailed explanation), `location` (file path and line range), `timestamp` (ISO 8601 detection time), `severity` (normalized severity level), `confidence` (confidence score 0.0-1.0), `evidence_refs` (list of evidence references)\n+- **Core Findings Schema Fields**: `category`, `severity`, `tool`, `rule`, `file`, `line`, `message`, `fixable` (as defined in `openspec/specs/review-finding-model/spec.md`)\n@@\n-- **Severity Mapping**: Critical (0.9-1.0), High (0.7-0.9), Medium (0.4-0.7), Low (0.0-0.4)\n-- **Confidence Scoring**: Pattern-based detections (0.8), heuristic detections (0.6), informational notes (0.4)\n+- **Severity Mapping**: MUST map detections to core enum values `error`, `warning`, or `info`.\n+- **Confidence Scoring**: If retained, treat as module-internal scoring/evidence metadata and do not replace core `severity` semantics.\n```\n

\n\n\n\nAs per coding guidelines: “openspec/**/*.md: Specification truth … drift vs. shipped modules or docs.”\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` around lines 19 -\n24, The proposal's \"Core Findings Schema Fields\" in proposal.md currently uses\nid/title/description/location/timestamp/confidence/evidence_refs and a severity\nmapping (Critical/High/Medium/Low), which diverges from the canonical review\nfinding schema; update the adapter contract in proposal.md to match\nopenspec/specs/review-finding-model/spec.md by using the canonical fields\n(category, severity, tool, rule, file, line, message, fixable) and the severity\nenum values (error|warning|info), and adapt any references to\nevidence_refs/location to map into file/line and message or add a clear mapping\nsection showing how id/title/description/timestamp/confidence map to the\ncanonical fields (e.g., id→rule or tool-specific id, description→message,\nlocation→file/line), so the payloads remain compatible with the core spec.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit b672278\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a single trailing newline at EOF.**\n\nThis avoids MD047 markdownlint failures.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 52-52: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/review-resiliency-01-module/proposal.md` at line 52, Append\na single trailing newline to the end of the file so the last line \"- **Issue\nURL**: \" is followed\nby a newline character (ensuring the file ends with exactly one EOF newline) to\nsatisfy MD047.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add a trailing newline at EOF (MD047).**\n\nMinor markdownlint fix.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 64-64: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md` at line 64,\nAdd a trailing newline at the end of the markdown file containing the line\n\"Should SBOM generation be mandatory for every security run or enabled only when\ndependency analysis is requested?\" to satisfy MD047; simply ensure the file ends\nwith a single newline character so the EOF is a blank line.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add final trailing newline for MD047.**\n\nFile should end with exactly one newline.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 30-30: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\nat line 30, Add a single final trailing newline at the end of the file so it\nends with exactly one newline; specifically update the file containing the line\n\"- **THEN** the bundle surfaces the failure with the normalized report contract\nand a non-success command outcome\" to ensure there is one and only one newline\ncharacter after the last line.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add trailing newline at end of file (MD047).**\n\nMinor markdownlint fix.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 27-27: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md` at line 27, Add\na trailing newline to the end of the file to satisfy markdownlint rule MD047:\nopen the file containing the line \"4.5 Open the modules PR to `dev`, cross-link\npaired security changes, and call out any deferred scanner providers as\nfollow-up issues.\" (tasks.md) and ensure the file ends with a single newline\ncharacter, save, and commit the change.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Finalize dependency statement; remove unresolved editorial note.**\n\nLine 46 already states the correct dependency direction, but the trailing “if intention was...” instruction reintroduces ambiguity. Convert this to a single definitive dependency statement.\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` at line\n46, Remove the unresolved editorial parenthetical and replace it with a single\ndefinitive dependency sentence: state that this proposal depends on\n`security-01-unified-findings-model` and the shared policy-pack semantics from\n`policy-02-packs-and-modes`, and remove any mention of\n`security-02-eu-gdpr-baseline` and the “if the intention was…” note so the\ndependency line references only the final, unambiguous dependency set.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit b672278\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add EOF trailing newline (MD047).**\n\nSmall markdownlint cleanup.\n\n

🧰 Tools

\n\n

🪛 markdownlint-cli2 (0.22.0)

\n\n[warning] 57-57: Files should end with a single newline character\n\n(MD047, single-trailing-newline)\n\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md` at line\n57, The file containing the line \"**GitHub Issue**:\n[`#228`](https://github.com/nold-ai/specfact-cli-modules/issues/228)\" fails\nmarkdownlint MD047 (missing EOF trailing newline); fix it by adding a single\nnewline character at the end of that markdown file (ensure the file ends with a\nblank line) so the EOF has a trailing newline and the MD047 warning is resolved.\n```\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n**Add final trailing newline for markdownlint compliance.**\n\nFile ends without a single trailing newline (MD047).\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\nat line 30, Add a single trailing newline character to the end of the file to\nsatisfy markdownlint rule MD047 (i.e., ensure the file ends with a newline after\nthe last line “**THEN** the bundle reports the finding without converting the\noverall command outcome into a blocking failure”).\n```\n\n

\n\n\n\n\n_🛠️ Refactor suggestion_ | _🟠 Major_\n\n**Add an explicit paired `specfact-cli` compatibility verification task.**\n\nSince this checklist changes shared privacy/GDPR findings/report contracts, add a concrete step to verify paired public artifacts/tests in `nold-ai/specfact-cli` before PR handoff (not just cross-linking). That will reduce adapter-boundary drift across repos.\n\n\nBased on learnings, when a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.\n\n\nAlso applies to: 27-27\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md` around lines 17 -\n18, Add a concrete checklist task to verify compatibility with\nnold-ai/specfact-cli whenever changing shared privacy/GDPR findings/report\ncontracts (e.g., alongside items \"3.2 Implement normalization...\" and \"3.3\nIntegrate shared policy/profile handling...\"); specifically, add a step that\nrequires running and reviewing the paired public artifacts/tests in specfact-cli\nand confirming any required adapter changes or test updates before PR handoff so\nthe change consumer (specfact-cli) is validated and noted in the checklist.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit b672278\n_🧹 Nitpick_ | _🔵 Trivial_\n\n**Wrap JSON payloads in fenced code blocks for Markdown readability.**\n\n`tojson(indent=2)` output is intentional (good), but unfenced JSON is harder to read in rendered Markdown. Consider fencing as `json` for stable display.\n\n

♻️ Suggested refinement

\n\n```diff\n {# Intentional machine-readable JSON embedding for downstream tooling #}\n-{{ business | tojson(indent=2) }}\n+```json\n+{{ business | tojson(indent=2) }}\n+```\n@@\n {# Intentional machine-readable JSON embedding for downstream tooling #}\n-{{ product | tojson(indent=2) }}\n+```json\n+{{ product | tojson(indent=2) }}\n+```\n```\n

\n\n\n\nAlso applies to: 27-28\n\n

🤖 Prompt for AI Agents

\n\n````\nVerify each finding against the current code and only fix it if needed.\n\nIn `@packages/specfact-project/resources/templates/persona/default.md.j2` around\nlines 20 - 21, The JSON output from the Jinja expressions business |\ntojson(indent=2) and product | tojson(indent=2) is currently emitted raw; wrap\neach rendered JSON block in Markdown fenced code blocks annotated with json so\nthe template lines that render {{ business | tojson(indent=2) }} and {{ product\n| tojson(indent=2) }} become fenced (```json ... ```) to improve readability in\nrendered Markdown while preserving the existing tojson usage.\n````\n\n

\n\n\n\n\n_⚠️ Potential issue_ | _🟡 Minor_\n\n

🧩 Analysis chain

\n\n🌐 Web query:\n\n`In GitHub GraphQL responses for Issue.subIssues, can `nodes` be null, and are null elements in `nodes` permitted?`\n\n💡 Result:\n\nIn GitHub's GraphQL API, the Issue.subIssues field exists (confirmed by recent sources referencing it in schema updates and client libraries as of 2025). It returns a connection object with standard pagination fields including nodes: [Issue!]!. The nodes field is a non-null array of non-null Issue objects, so nodes itself cannot be null. Individual elements in nodes cannot be null either, as they are typed Issue! (non-nullable). This follows GitHub's standard Relay-style connection pattern where nodes is [T!]! for object type T, preventing null arrays or null elements. General GraphQL connection behavior supports null nodes for error handling, but GitHub's schema uses non-null for Issue connections (e.g., IssueConnection.nodes: [Issue!]!).\n\nCitations:\n\n- 1: https://developer.github.com/v4/object/issue/\n- 2: https://developer.github.com/v4/object/issueconnection/\n- 3: https://stackoverflow.com/questions/57901668/how-to-understand-null-edges-and-nodes-in-graphql\n- 4: https://github.com/octokit/octokit.graphql.net/issues/327\n- 5: https://docs.github.com/enterprise/2.12/developer/v4/object/issueconnection\n- 6: https://docs.github.com/enterprise/2.14/developer/v4/object/issueconnection\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Read the function containing lines 118-121 with surrounding context\ncat -n scripts/ensure_github_hierarchy_subissues.py | sed -n '100,140p'\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1896\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Look at the broader context and error handling patterns\ncat -n scripts/ensure_github_hierarchy_subissues.py | head -50\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 1738\n\n---\n\n🏁 Script executed:\n\n```shell\n#!/bin/bash\n# Continue reading the _gh_graphql function\ncat -n scripts/ensure_github_hierarchy_subissues.py | sed -n '42,90p'\n```\n\nRepository: nold-ai/specfact-cli-modules\n\nLength of output: 2394\n\n---\n\n\n\n

\n\n**Add type guard for `subIssues.nodes` to ensure deterministic failures.**\n\nLine 118-119: `raw_nodes` can be non-list if `nodes` key exists but has unexpected value (e.g., `null` or string). This would raise `TypeError` instead of the controlled `RuntimeError` path used elsewhere in the function. Add type check before iteration to match the defensive pattern used for `issue` (line 113) and `pageInfo` (line 123).\n\n

Suggested fix

\n\n```diff\n raw_nodes = sub.get(\"nodes\", [])\n+ if not isinstance(raw_nodes, list):\n+ raise RuntimeError(f\"invalid subIssues.nodes payload for issue #{parent_number}: {raw_nodes!r}\")\n for node in raw_nodes:\n if isinstance(node, dict) and node.get(\"number\") is not None:\n collected.add(int(node[\"number\"]))\n```\n

\n\n

🤖 Prompt for AI Agents

\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@scripts/ensure_github_hierarchy_subissues.py` around lines 118 - 121, The\ncode iterates raw_nodes = sub.get(\"nodes\", []) without guarding its type; add a\ntype check before the loop (similar to the existing guards around issue and\npageInfo) to ensure raw_nodes is a list and raise a controlled RuntimeError if\nnot, then proceed to iterate and call collected.add(int(node[\"number\"])) for\ndict entries; reference the variables raw_nodes and sub and mirror the error\nmessaging/behavior used for issue and pageInfo so failures remain deterministic.\n```\n\n

\n\n\n\n\n\n✅ Addressed in commit b672278\n**Actionable comments posted: 28**\n\n

♻️ Duplicate comments (9)

\n\n
\n
openspec/changes/security-01-module-sast-sca-secret/design.md (1)
\n\n`58-60`: _⚠️ Potential issue_ | _🟠 Major_\n\n**Fix contradictory dependency semantics for `policy-02-packs-and-modes`.**\n\nLine 58 treats `policy-02-packs-and-modes` as a required core target, while Line 59 says it should be a module-level dependency if shipped separately. Pick one authoritative classification and remove the conflicting path. \n \n\nAs per coding guidelines, “Specification truth: proposal/tasks/spec deltas vs. bundle behavior, CHANGE_ORDER, and drift vs. shipped modules or docs.”\n\n
\n
🤖 Prompt for AI Agents
\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md` around lines\n58 - 60, The document currently classifies policy-02-packs-and-modes in two\nconflicting ways; decide and make one authoritative classification: either\ndeclare policy-02-packs-and-modes as a required core contract alongside\nsecurity-01-unified-findings-model (keep it in core_compatibility) or declare it\nas a module-level bundle dependency (remove it from the core targets list).\nUpdate the lines referencing security-01-unified-findings-model,\npolicy-02-packs-and-modes, core_compatibility and bundle dependency so only the\nchosen path remains and remove the alternate path and any contradictory wording.\n```\n\n
\n\n
\n
\n
openspec/changes/security-01-module-sast-sca-secret/tasks.md (1)
\n\n`4-4`: _⚠️ Potential issue_ | _🟠 Major_\n\n**Correct the dependency verification task to distinguish core vs module changes.**\n\nLine 4 currently requires both dependencies to be merged in `specfact-cli`, which is inconsistent with the documented module-level treatment of `policy-02-packs-and-modes`. Split this task into: (a) core contract verification, and (b) module bundle dependency verification/manifest semantics. \n \n\nBased on learnings: “When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.”\n\n
\n
🤖 Prompt for AI Agents
\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md` at line 4,\nUpdate the task in tasks.md to split the single dependency check into two\ndistinct checks: (1) a core contract verification that ensures the core change\nsecurity-01-unified-findings-model is merged in specfact-cli and documents the\nminimum core_compatibility versions in TDD_EVIDENCE.md, and (2) a module\nbundle/manifest verification that treats policy-02-packs-and-modes as a\nmodule-level dependency (verify bundle/manifest semantics and whether it must be\npresent in the module bundle rather than requiring it to be merged into\nspecfact-cli); make the wording explicit about which change is a core vs module\ndependency and include any sequencing notes.\n```\n\n
\n\n
\n
\n
openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md (1)
\n\n`7-7`: _⚠️ Potential issue_ | _🟠 Major_\n\n**Make the requirement deterministic; move dependency-status gating out of normative spec text.**\n\nLine 7 currently mixes a hard requirement with an unresolved “confirm status before implementation” note. That makes the spec non-testable and drifts from “spec as source of truth.” Keep the SHALL clause definitive, and move status-tracking/gating language to `proposal.md`/`tasks.md`/`TDD_EVIDENCE.md`. \n \n\nAs per coding guidelines, “Specification truth: proposal/tasks/spec deltas vs. bundle behavior, CHANGE_ORDER, and drift vs. shipped modules or docs.”\n\n
\n
🤖 Prompt for AI Agents
\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\nat line 7, The SHALL clause must be definitive: update the spec to state that\nthe modules repository SHALL provide a signed official bundle named\n`nold-ai/specfact-license-compliance` that exposes the `license` command and\ndeclares truthful bundle dependencies, pip dependencies, and a\n`core_compatibility` entry for `security-01-unified-findings-model` (no\nconditional language), and remove the “Confirm the core change…before\nimplementation” note from spec.md; instead add the status-tracking and gating\ndetails to proposal.md or tasks.md or TDD_EVIDENCE.md so implementation guidance\n(confirmation of `security-01-unified-findings-model` status and any version\nrequirement notes) lives outside the normative spec text.\n```\n\n
\n\n
\n
\n
openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md (1)
\n\n`7-7`: _⚠️ Potential issue_ | _🟠 Major_\n\n**Resolve dependency classification now; avoid conditional language in the requirement.**\n\nLine 7 keeps `core_compatibility` semantics conditional (“if ... then ...”). This leaves manifest expectations ambiguous and non-verifiable. Decide and encode one source of truth (core contract vs module `bundle_dependencies`) directly in the requirement. \n \n\nBased on learnings: “When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.”\n\n
\n
🤖 Prompt for AI Agents
\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\nat line 7, Update the requirement to remove conditional wording and assert a\nsingle, verifiable dependency classification: state that the modules bundle\n`nold-ai/specfact-security` MUST list `security-01-unified-findings-model` in\ncore_compatibility if that contract is accepted by specfact-cli public\nartifacts, otherwise explicitly require `policy-02-packs-and-modes` (if shipped\nas a separate module) to be declared under bundle_dependencies; replace the “if\n… then …” phrasing with a definitive statement referencing `bundle_dependencies`\nand `core_compatibility` and call out the exposed `security` command and pip\ndependencies as mandatory manifest entries so the expectation is unambiguous.\n```\n\n
\n\n
\n
\n
openspec/changes/knowledge-02-module-writeback/proposal.md (1)
\n\n`15-21`: _⚠️ Potential issue_ | _🟠 Major_\n\n**Writeback interface is still ambiguous on validation and manifest strictness.**\n\nAt Line 19–Line 21, the contract names fields but doesn’t define required vs optional fields, destination-validation ownership, or preview-vs-write error semantics. That leaves adapters free to diverge.\n\n
\n
Proposed contract tightening
\n\n```diff\n ### Writeback Interface\n@@\n-- **Adapter Method Signature**: Each writeback adapter implements a standard method accepting rule identifiers, destination path, and dry-run flag\n-- **Manifest Schema Fields**: `ruleIds` (list of rule identifiers), `ruleVersions` (semantic versions or commit hashes), `inputDigest` (hash of source rules), `outputDigest` (hash of generated output), `timestamp` (ISO 8601 generation time), `adapterId` (writeback target type), `destination` (file path or endpoint), `previewHash` (preview content hash for verification), `dryRunFlag` (boolean indicating preview-only mode)\n+- **Adapter Method Signature**: Each adapter MUST accept `{ruleIds, destination, dryRun}` and return `{previewContent, writebackManifest}`.\n+- **Destination Validation**: Adapter validates destination format/access; caller validates policy/authorization.\n+- **Manifest Schema Fields**:\n+ - **Required**: `ruleIds`, `ruleVersions`, `inputDigest`, `outputDigest`, `timestamp`, `adapterId`, `destination`, `dryRunFlag`\n+ - **Optional**: `previewHash` (required when `dryRun=true`)\n+- **Error Semantics**: Preview generation errors MUST fail without side effects; final writeback errors MUST include manifest context for audit.\n```\n
\n\n \n\nAs per coding guidelines: “openspec/**/*.md: Specification truth … drift vs. shipped modules or docs.”\n\n
\n
🤖 Prompt for AI Agents
\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md` around lines 15 -\n21, Clarify the writeback manifest by marking which manifest fields are required\nvs optional (e.g., require ruleIds, adapterId, destination, timestamp,\ninputDigest/outputDigest for integrity; make ruleVersions, previewHash,\ndryRunFlag optional) and add concrete validation rules for destination ownership\nand format (e.g., adapter must validate that destination belongs to the caller\nor an allowed namespace and reject unauthorized paths), define preview vs write\nsemantics for dryRunFlag and previewHash (dryRunFlag=true must never mutate\ndestination and must return a deterministically verifiable previewHash; when\ndryRunFlag=false adapters must enforce previewHash match before writing), and\nstate explicit error codes/behaviors (validation errors vs preview-mismatch vs\nwrite-failure) referencing the manifest field names ruleIds, ruleVersions,\ninputDigest, outputDigest, timestamp, adapterId, destination, previewHash,\ndryRunFlag and the \"writeback adapter\" contract so implementers must follow a\nsingle strict validation and error model.\n```\n\n
\n\n
\n
\n
openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md (1)
\n\n`7-7`: _⚠️ Potential issue_ | _🟡 Minor_\n\n**Make telemetry prerequisite field canonical, not “or”.**\n\nLine 7 still allows two representations (“`core_compatibility` or dependency metadata fields”), which can cause manifest inconsistency and registry/tooling drift. Pick one canonical field (or define strict precedence).\n\n \nAs per coding guidelines, `openspec/**/*.md` must preserve specification truth and avoid contract ambiguity/drift.\n\n
\n
🤖 Prompt for AI Agents
\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\nat line 7, The spec currently allows two representations for the telemetry\nprerequisite which risks inconsistency; update the sentence so the bundle\nmanifest MUST list telemetry-01-opentelemetry-default-on in the\ncore_compatibility field (not “or dependency metadata fields”), e.g. require the\nnold-ai/specfact-finops bundle that exposes the finops command to explicitly\ndeclare telemetry-01-opentelemetry-default-on in core_compatibility (or if you\nprefer alternate behavior, define strict precedence between core_compatibility\nand dependency metadata fields and document that precedence in\nopenspec/CHANGE_ORDER.md).\n```\n\n
\n\n
\n
\n
openspec/changes/architecture-02-module-well-architected/design.md (1)
\n\n`5-5`: _⚠️ Potential issue_ | _🟠 Major_\n\n**Specify the exact core contract/schema for architecture findings.**\n\nLines 5, 13, and 38 reference the \"paired core architecture review model\" and \"paired core report contract\" without naming the specific contract or schema. The proposal.md adapter contract (lines 19-22) defines fields like `id`, `type`, `evidence_refs`, but the core `ReviewFinding` model (from `review-finding-model` spec) defines `category`, `tool`, `rule`, `file`, `line`, `message`. This ambiguity creates risk of adapter implementation drift.\n\nClarify whether:\n- Architecture findings populate the existing `ReviewFinding` model (with `category: \"architecture\"`), or\n- A separate architecture-specific findings schema is defined in the paired core contract `architecture-02-well-architected-review`\n\nUpdate the design to explicitly name the target schema and reference the specific core contract specification.\n\n\n\nBased on learnings, when a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics.\n\n\nAlso applies to: 13-13, 38-38\n\n
\n
🤖 Prompt for AI Agents
\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/design.md` at line\n5, Update the design to explicitly name and reference the exact core\ncontract/schema used for architecture findings: state whether the module maps\ninto the existing ReviewFinding model (from review-finding-model) with category:\n\"architecture\" and show the field mapping (e.g., map proposal.md fields id→id,\ntype→type, evidence_refs→evidence_refs to ReviewFinding fields like id, type,\nevidence_refs and map category, tool, rule, file, line, message accordingly), or\ndeclare and link the separate architecture-02-well-architected-review contract\nif you want a distinct schema; replace all vague references to \"paired core\narchitecture review model\" and \"paired core report contract\" with the exact\ncontract name and a pointer to the spec so adapter implementers can avoid drift\n(also update occurrences at lines referenced as 13 and 38).\n```\n\n
\n\n
\n
\n
openspec/changes/architecture-02-module-well-architected/proposal.md (2)
\n\n`10-12`: _🧹 Nitpick_ | _🔵 Trivial_\n\n**Consider rewording to reduce repetitive sentence starts.**\n\nLines 10-12 begin three consecutive bullets with \"**NEW**:\", which reduces readability per static analysis (LanguageTool ENGLISH_WORD_REPEAT_BEGINNING_RULE).\n\n\n\n
\n
✍️ Proposed rewording
\n\n```diff\n-- **NEW**: Add a `specfact-architecture` bundle with an `architecture` command for boundary, interface, and well-architected review.\n-- **NEW**: Package analyzers and rule resources for dependency-graph checks, ADR traceability, and interface-diff evaluation.\n-- **NEW**: Encode the `ALLOWED_IMPORTS.md` pattern into reusable review rules so the modules repo and user repositories can share the same boundary-checking approach.\n+- **NEW**: Add a `specfact-architecture` bundle with an `architecture` command for boundary, interface, and well-architected review.\n+- **Package** analyzers and rule resources for dependency-graph checks, ADR traceability, and interface-diff evaluation.\n+- **Encode** the `ALLOWED_IMPORTS.md` pattern into reusable review rules so the modules repo and user repositories can share the same boundary-checking approach.\n```\n
\n\n
\n
🤖 Prompt for AI Agents
\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` around\nlines 10 - 12, The three bullets starting with the repeated marker \"**NEW**:\"\nhurt readability; revise the three items (the \"Package analyzers and rule\nresources for dependency-graph checks, ADR traceability, and interface-diff\nevaluation\" item, the \"Encode the `ALLOWED_IMPORTS.md` pattern into reusable\nreview rules...\" item, and the \"Introduce report surfaces that map architecture\nfindings...\" item) to use varied lead-ins (e.g., \"Add\", \"Encode\", \"Introduce\" or\nsimilar) or rephrase one or two bullets so they don't all begin with the same\ntoken while preserving meaning and references to ALLOWED_IMPORTS.md and report\nsurfaces.\n```\n\n
\n\n---\n\n`40-40`: _⚠️ Potential issue_ | _🟡 Minor_\n\n**Use a placeholder version range for core compatibility.**\n\nThe `core_compatibility: \">=1.0.0 <2.0.0\"` specified on line 40 is premature. The paired core contract (`architecture-02-well-architected-review`) has not yet been created in specfact-cli (currently at 0.46.4), and task 1.2 in tasks.md explicitly calls for confirming the paired core change's availability before documenting the required compatibility range. Replace with a placeholder such as:\n\n```\ncore_compatibility: \"TBD (set when architecture-02-well-architected-review is available in specfact-cli)\"\n```\n\nThis ensures the version range reflects actual core availability rather than speculative targeting of a future release.\n\n
\n
🤖 Prompt for AI Agents
\n\n```\nVerify each finding against the current code and only fix it if needed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md` at line\n40, Replace the speculative core version in the reserved manifest by changing\nthe core_compatibility value for the manifest named\n`architecture-02-well-architected-review` to a placeholder until the paired core\ncontract exists; specifically, update the `core_compatibility` field (currently\nset to \">=1.0.0 <2.0.0\") to a clear placeholder like `TBD (set when\narchitecture-02-well-architected-review is available in specfact-cli)` so the\ndocument defers exact versioning until task 1.2 confirms the core contract\navailability.\n```\n\n
\n\n
\n\n

\n\n

🤖 Prompt for all review comments with AI agents

\n\n````\nVerify each finding against the current code and only fix it if needed.\n\nInline comments:\nIn `@docs/bundles/project/import-migration.md`:\n- Line 272: Add a final trailing newline to the markdown file by ensuring the\nlast line containing \"**Happy importing!** 🚀\" ends with a newline character;\nsimply append a newline after that line so the file ends with a blank line to\nsatisfy MD047.\n- Around line 39-40: Update the doc text that currently lists thresholds\n(>10,000 ignored entries, ~100,000 files, ~10 GB, >100,000 commits) to match the\nimplementation: state the heavy ignored-entry threshold is 500 entries and the\nlarge-repo file threshold is 1,000 files, and remove references to GB or\ncommit-count thresholds (or replace the fixed values with a note that the system\nuses configured thresholds) so the sentence about remaining-time estimates\nrefers to repositories above those actual/configured thresholds; update the\nphrases that mention \"ignored artifact trees\" and \"Remaining time is based\non...\" to reflect the corrected thresholds or that such limits are configurable.\n\nIn `@openspec/CHANGE_ORDER.md`:\n- Line 129: The file's last line (the table row containing \"| peer-deps | 01 | ✅\nmodule-bundle-deps-auto-install (archived 2026-04-05) |\n[`#135`](https://github.com/nold-ai/specfact-cli-modules/issues/135) | — |\") is\nmissing a terminating newline which triggers MD047; add a single trailing\nnewline character at the end of CHANGE_ORDER.md so the file ends with a newline\nand re-run markdownlint to confirm the warning is cleared.\n\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\n- Line 50: The document references a required core contract\narchitecture-02-well-architected-review that is not present in specfact-cli; to\nfix, block merging of this design until that core change is created and synced\nin specfact-cli or explicitly add a dependency/blocker statement in this file\nnoting that module integration and any references to\narchitecture-02-well-architected-review (and overlaps with\narchitecture-01-solution-layer) are disallowed until the paired specfact-cli\nchange exists and is marked stable; update design.md to include a clear\ndependency checklist and a gating sentence that prevents implementation work\nuntil specfact-cli contains the architecture-02-well-architected-review\nartifact.\n- Line 57: The file ends without a trailing newline which violates markdownlint\nMD047; open the file containing the line \"Should interface diff support start\nwith one ecosystem or ship as a provider abstraction from the first\nimplementation?\" (design.md) and add a single newline character at the end of\nthe file so it ends with exactly one trailing newline.\n- Around line 1-57: Ensure the paired core change\n\"architecture-02-well-architected-review\" exists and is synced into specfact-cli\nbefore merging this module design: verify the core change defines the\nfindings/report contract referenced by packages/specfact-architecture, confirm\nthe module-to-core binding points (adapter contracts and report schema used by\nthe analyzer adapters and rule-resource translation) are finalized and tested\nagainst specfact-cli, update CHANGE_ORDER (order-03) and the Migration Plan to\nreflect actual core availability and registry timeline, and block or defer\nmerging of the architecture-02 module design until those confirmations/pass CI\ntests are completed.\n\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md`:\n- Line 54: The file ends without a trailing newline (see the line containing\n\"**Sanitized**: false\" in proposal.md); add a single newline character at the\nend of the file so the file terminates with exactly one trailing newline to\nsatisfy markdownlint MD047.\n- Around line 15-22: Update the \"Adapter Contract\" section so it maps analyzer\noutputs to the core ReviewFinding model instead of a custom schema: replace the\n\"Required Core Findings Schema Fields\" and \"Analyzer Output Mapping\"\ndescriptions with mapping to ReviewFinding fields — set category=\"architecture\",\ntool=, rule=, file=, line=, message=, and\nseverity=; retain evidence_refs only as supplemental\nreferences but ensure primary location data uses file/line; align wording with\nthe ReviewFinding spec and mention pylint-runner expectation that category must\nbe \"architecture\" and tool \"pylint\".\n\nIn `@openspec/changes/codebase-import-runtime-hardening/design.md`:\n- Line 93: Add a terminal newline to the end of the document so the final line\n\"None for implementation start; warning thresholds can be tuned in-code if test\nevidence shows the initial defaults are too noisy.\" ends with a newline (satisfy\nmarkdownlint MD047); simply ensure the file's EOF contains a trailing newline\ncharacter.\n\nIn\n`@openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`:\n- Line 19: The file ends without a trailing newline causing MD047; append a\nsingle final newline character to the end of the spec so the last line \"**AND**\nthe failure message SHALL name the missing template path so the packaging defect\ncan be corrected before publish\" is terminated by a newline (i.e., ensure the\nfile ends with one newline character).\n\nIn\n`@openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`:\n- Line 57: The file ends without a trailing newline on the final line containing\n\"- **AND** any early estimate before full discovery SHALL be labeled as\nprovisional rather than a fixed promise\"; open the file and add a single newline\ncharacter (EOF newline) after that line so the document ends with a trailing\nnewline to satisfy MD047.\n\nIn `@openspec/changes/codebase-import-runtime-hardening/tasks.md`:\n- Line 32: Add a single trailing newline at the end of\nopenspec/changes/codebase-import-runtime-hardening/tasks.md so the final line \"-\n[ ] 5.4 Commit, push, and open or update the PR to `dev` after verification is\ngreen.\" is followed by one newline (fixes MD047); simply ensure the file ends\nwith a single blank line.\n\nIn `@openspec/changes/enterprise-02-module-audit-client/design.md`:\n- Around line 1-57: The file ending after the \"## Open Questions\" section (look\nfor the top-level heading \"# Design\" or the \"## Context\" / \"## Open Questions\"\nmarkers) is missing a trailing newline; to fix, open the markdown file for\nwriting and append a single newline character at the end of the file so the last\nline (after \"How should retry cadence and dead-letter behavior be surfaced in\nthe first client contract?\") ends with a newline to satisfy MD047.\n\nIn\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`:\n- Line 30: Append a single trailing newline to the end of the markdown file so\nthe final line \"**THEN** it records the session outcome as `rule-updated` in the\nnormalized FinOps evidence\" ends with a newline (fixing MD047); ensure no other\nwhitespace changes are made.\n\nIn `@openspec/changes/finops-01-module-cost-outcome/tasks.md`:\n- Line 27: The file ends without a trailing newline causing MD047; add a single\ntrailing newline to the end of the file so the final checklist line \"- [ ] 4.5\nOpen the modules PR to `dev`, cross-link paired telemetry/FinOps changes, and\nnote any deferred provider integrations as follow-up issues.\" is terminated by a\nnewline character (ensure only one final newline).\n\nIn `@openspec/changes/knowledge-01-module-memory-runtime/design.md`:\n- Line 55: Add a trailing newline at the end of the file by ensuring the final\nline \"- Should search support only tags and keywords initially, or also\nrelationship traversal commands?\" is followed by a single newline character\n(i.e., ensure EOF ends with a newline) to satisfy markdownlint MD047.\n\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md`:\n- Line 52: Add a single trailing newline at the end of the markdown file that\ncontains the line \"- **Sanitized**: false\" (the proposal.md for the\nknowledge-02-module-writeback change) so the file ends with exactly one newline\ncharacter; ensure there are no extra blank lines or removal of other content and\nsave the file to satisfy MD047.\n\nIn `@openspec/changes/review-resiliency-01-module/proposal.md`:\n- Line 52: Append a single trailing newline to the end of the file so the last\nline \"- **Issue URL**:\n\" is followed by a\nnewline character (ensuring the file ends with exactly one EOF newline) to\nsatisfy MD047.\n- Around line 19-24: The proposal's \"Core Findings Schema Fields\" in proposal.md\ncurrently uses id/title/description/location/timestamp/confidence/evidence_refs\nand a severity mapping (Critical/High/Medium/Low), which diverges from the\ncanonical review finding schema; update the adapter contract in proposal.md to\nmatch openspec/specs/review-finding-model/spec.md by using the canonical fields\n(category, severity, tool, rule, file, line, message, fixable) and the severity\nenum values (error|warning|info), and adapt any references to\nevidence_refs/location to map into file/line and message or add a clear mapping\nsection showing how id/title/description/timestamp/confidence map to the\ncanonical fields (e.g., id→rule or tool-specific id, description→message,\nlocation→file/line), so the payloads remain compatible with the core spec.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md`:\n- Line 64: Add a trailing newline at the end of the markdown file containing the\nline \"Should SBOM generation be mandatory for every security run or enabled only\nwhen dependency analysis is requested?\" to satisfy MD047; simply ensure the file\nends with a single newline character so the EOF is a blank line.\n\nIn\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`:\n- Line 30: Add a single final trailing newline at the end of the file so it ends\nwith exactly one newline; specifically update the file containing the line \"-\n**THEN** the bundle surfaces the failure with the normalized report contract and\na non-success command outcome\" to ensure there is one and only one newline\ncharacter after the last line.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md`:\n- Line 27: Add a trailing newline to the end of the file to satisfy markdownlint\nrule MD047: open the file containing the line \"4.5 Open the modules PR to `dev`,\ncross-link paired security changes, and call out any deferred scanner providers\nas follow-up issues.\" (tasks.md) and ensure the file ends with a single newline\ncharacter, save, and commit the change.\n\nIn `@openspec/changes/security-02-module-license-compliance/proposal.md`:\n- Line 46: Remove the unresolved editorial parenthetical and replace it with a\nsingle definitive dependency sentence: state that this proposal depends on\n`security-01-unified-findings-model` and the shared policy-pack semantics from\n`policy-02-packs-and-modes`, and remove any mention of\n`security-02-eu-gdpr-baseline` and the “if the intention was…” note so the\ndependency line references only the final, unambiguous dependency set.\n- Line 57: The file containing the line \"**GitHub Issue**:\n[`#228`](https://github.com/nold-ai/specfact-cli-modules/issues/228)\" fails\nmarkdownlint MD047 (missing EOF trailing newline); fix it by adding a single\nnewline character at the end of that markdown file (ensure the file ends with a\nblank line) so the EOF has a trailing newline and the MD047 warning is resolved.\n\nIn\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`:\n- Line 30: Add a single trailing newline character to the end of the file to\nsatisfy markdownlint rule MD047 (i.e., ensure the file ends with a newline after\nthe last line “**THEN** the bundle reports the finding without converting the\noverall command outcome into a blocking failure”).\n\nIn `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`:\n- Around line 17-18: Add a concrete checklist task to verify compatibility with\nnold-ai/specfact-cli whenever changing shared privacy/GDPR findings/report\ncontracts (e.g., alongside items \"3.2 Implement normalization...\" and \"3.3\nIntegrate shared policy/profile handling...\"); specifically, add a step that\nrequires running and reviewing the paired public artifacts/tests in specfact-cli\nand confirming any required adapter changes or test updates before PR handoff so\nthe change consumer (specfact-cli) is validated and noted in the checklist.\n\nIn `@packages/specfact-project/resources/templates/persona/default.md.j2`:\n- Around line 20-21: The JSON output from the Jinja expressions business |\ntojson(indent=2) and product | tojson(indent=2) is currently emitted raw; wrap\neach rendered JSON block in Markdown fenced code blocks annotated with json so\nthe template lines that render {{ business | tojson(indent=2) }} and {{ product\n| tojson(indent=2) }} become fenced (```json ... ```) to improve readability in\nrendered Markdown while preserving the existing tojson usage.\n\nIn `@scripts/ensure_github_hierarchy_subissues.py`:\n- Around line 118-121: The code iterates raw_nodes = sub.get(\"nodes\", [])\nwithout guarding its type; add a type check before the loop (similar to the\nexisting guards around issue and pageInfo) to ensure raw_nodes is a list and\nraise a controlled RuntimeError if not, then proceed to iterate and call\ncollected.add(int(node[\"number\"])) for dict entries; reference the variables\nraw_nodes and sub and mirror the error messaging/behavior used for issue and\npageInfo so failures remain deterministic.\n\n---\n\nDuplicate comments:\nIn `@openspec/changes/architecture-02-module-well-architected/design.md`:\n- Line 5: Update the design to explicitly name and reference the exact core\ncontract/schema used for architecture findings: state whether the module maps\ninto the existing ReviewFinding model (from review-finding-model) with category:\n\"architecture\" and show the field mapping (e.g., map proposal.md fields id→id,\ntype→type, evidence_refs→evidence_refs to ReviewFinding fields like id, type,\nevidence_refs and map category, tool, rule, file, line, message accordingly), or\ndeclare and link the separate architecture-02-well-architected-review contract\nif you want a distinct schema; replace all vague references to \"paired core\narchitecture review model\" and \"paired core report contract\" with the exact\ncontract name and a pointer to the spec so adapter implementers can avoid drift\n(also update occurrences at lines referenced as 13 and 38).\n\nIn `@openspec/changes/architecture-02-module-well-architected/proposal.md`:\n- Around line 10-12: The three bullets starting with the repeated marker\n\"**NEW**:\" hurt readability; revise the three items (the \"Package analyzers and\nrule resources for dependency-graph checks, ADR traceability, and interface-diff\nevaluation\" item, the \"Encode the `ALLOWED_IMPORTS.md` pattern into reusable\nreview rules...\" item, and the \"Introduce report surfaces that map architecture\nfindings...\" item) to use varied lead-ins (e.g., \"Add\", \"Encode\", \"Introduce\" or\nsimilar) or rephrase one or two bullets so they don't all begin with the same\ntoken while preserving meaning and references to ALLOWED_IMPORTS.md and report\nsurfaces.\n- Line 40: Replace the speculative core version in the reserved manifest by\nchanging the core_compatibility value for the manifest named\n`architecture-02-well-architected-review` to a placeholder until the paired core\ncontract exists; specifically, update the `core_compatibility` field (currently\nset to \">=1.0.0 <2.0.0\") to a clear placeholder like `TBD (set when\narchitecture-02-well-architected-review is available in specfact-cli)` so the\ndocument defers exact versioning until task 1.2 confirms the core contract\navailability.\n\nIn\n`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`:\n- Line 7: The spec currently allows two representations for the telemetry\nprerequisite which risks inconsistency; update the sentence so the bundle\nmanifest MUST list telemetry-01-opentelemetry-default-on in the\ncore_compatibility field (not “or dependency metadata fields”), e.g. require the\nnold-ai/specfact-finops bundle that exposes the finops command to explicitly\ndeclare telemetry-01-opentelemetry-default-on in core_compatibility (or if you\nprefer alternate behavior, define strict precedence between core_compatibility\nand dependency metadata fields and document that precedence in\nopenspec/CHANGE_ORDER.md).\n\nIn `@openspec/changes/knowledge-02-module-writeback/proposal.md`:\n- Around line 15-21: Clarify the writeback manifest by marking which manifest\nfields are required vs optional (e.g., require ruleIds, adapterId, destination,\ntimestamp, inputDigest/outputDigest for integrity; make ruleVersions,\npreviewHash, dryRunFlag optional) and add concrete validation rules for\ndestination ownership and format (e.g., adapter must validate that destination\nbelongs to the caller or an allowed namespace and reject unauthorized paths),\ndefine preview vs write semantics for dryRunFlag and previewHash\n(dryRunFlag=true must never mutate destination and must return a\ndeterministically verifiable previewHash; when dryRunFlag=false adapters must\nenforce previewHash match before writing), and state explicit error\ncodes/behaviors (validation errors vs preview-mismatch vs write-failure)\nreferencing the manifest field names ruleIds, ruleVersions, inputDigest,\noutputDigest, timestamp, adapterId, destination, previewHash, dryRunFlag and the\n\"writeback adapter\" contract so implementers must follow a single strict\nvalidation and error model.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/design.md`:\n- Around line 58-60: The document currently classifies policy-02-packs-and-modes\nin two conflicting ways; decide and make one authoritative classification:\neither declare policy-02-packs-and-modes as a required core contract alongside\nsecurity-01-unified-findings-model (keep it in core_compatibility) or declare it\nas a module-level bundle dependency (remove it from the core targets list).\nUpdate the lines referencing security-01-unified-findings-model,\npolicy-02-packs-and-modes, core_compatibility and bundle dependency so only the\nchosen path remains and remove the alternate path and any contradictory wording.\n\nIn\n`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`:\n- Line 7: Update the requirement to remove conditional wording and assert a\nsingle, verifiable dependency classification: state that the modules bundle\n`nold-ai/specfact-security` MUST list `security-01-unified-findings-model` in\ncore_compatibility if that contract is accepted by specfact-cli public\nartifacts, otherwise explicitly require `policy-02-packs-and-modes` (if shipped\nas a separate module) to be declared under bundle_dependencies; replace the “if\n… then …” phrasing with a definitive statement referencing `bundle_dependencies`\nand `core_compatibility` and call out the exposed `security` command and pip\ndependencies as mandatory manifest entries so the expectation is unambiguous.\n\nIn `@openspec/changes/security-01-module-sast-sca-secret/tasks.md`:\n- Line 4: Update the task in tasks.md to split the single dependency check into\ntwo distinct checks: (1) a core contract verification that ensures the core\nchange security-01-unified-findings-model is merged in specfact-cli and\ndocuments the minimum core_compatibility versions in TDD_EVIDENCE.md, and (2) a\nmodule bundle/manifest verification that treats policy-02-packs-and-modes as a\nmodule-level dependency (verify bundle/manifest semantics and whether it must be\npresent in the module bundle rather than requiring it to be merged into\nspecfact-cli); make the wording explicit about which change is a core vs module\ndependency and include any sequencing notes.\n\nIn\n`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`:\n- Line 7: The SHALL clause must be definitive: update the spec to state that the\nmodules repository SHALL provide a signed official bundle named\n`nold-ai/specfact-license-compliance` that exposes the `license` command and\ndeclares truthful bundle dependencies, pip dependencies, and a\n`core_compatibility` entry for `security-01-unified-findings-model` (no\nconditional language), and remove the “Confirm the core change…before\nimplementation” note from spec.md; instead add the status-tracking and gating\ndetails to proposal.md or tasks.md or TDD_EVIDENCE.md so implementation guidance\n(confirmation of `security-01-unified-findings-model` status and any version\nrequirement notes) lives outside the normative spec text.\n````\n\n

\n\n

🪄 Autofix (Beta)

\n\n✅ Autofix completed\n\n

\n\n---\n\n

ℹ️ Review info

\n\n

⚙️ Run configuration

\n\n**Configuration used**: Path: .coderabbit.yaml\n\n**Review profile**: ASSERTIVE\n\n**Plan**: Pro\n\n**Run ID**: `9129b38b-0edd-4884-af86-01886b808973`\n\n

\n\n

📥 Commits

\n\nReviewing files that changed from the base of the PR and between 39750733a68cd1ac8b652b1c46abcc51d84aff60 and 0672f50fc279db70e7351ed9079417d641efe976.\n\n

\n\n

📒 Files selected for processing (29)

\n\n* `docs/bundles/project/import-migration.md`\n* `openspec/CHANGE_ORDER.md`\n* `openspec/changes/architecture-02-module-well-architected/design.md`\n* `openspec/changes/architecture-02-module-well-architected/proposal.md`\n* `openspec/changes/codebase-import-runtime-hardening/design.md`\n* `openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\n* `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n* `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n* `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\n* `openspec/changes/enterprise-02-module-audit-client/design.md`\n* `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\n* `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\n* `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n* `openspec/changes/knowledge-01-module-memory-runtime/design.md`\n* `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\n* `openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\n* `openspec/changes/knowledge-02-module-writeback/design.md`\n* `openspec/changes/knowledge-02-module-writeback/proposal.md`\n* `openspec/changes/review-resiliency-01-module/proposal.md`\n* `openspec/changes/security-01-module-sast-sca-secret/design.md`\n* `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\n* `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n* `openspec/changes/security-02-module-license-compliance/design.md`\n* `openspec/changes/security-02-module-license-compliance/proposal.md`\n* `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\n* `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n* `packages/specfact-project/resources/templates/persona/default.md.j2`\n* `scripts/ensure_github_hierarchy_subissues.py`\n* `tests/unit/workflows/test_sign_modules_on_approval.py`\n\n

\n\n

📜 Review details

\n\n

🧰 Additional context used

\n\n

📓 Path-based instructions (5)

\n\n

openspec/**/*.md

\n\n\n**⚙️ CodeRabbit configuration file**\n\n> `openspec/**/*.md`: Specification truth: proposal/tasks/spec deltas vs. bundle behavior, CHANGE_ORDER, and\n> drift vs. shipped modules or docs.\n> \n\nFiles:\n- `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\n- `openspec/changes/codebase-import-runtime-hardening/specs/bundle-packaged-resources/spec.md`\n- `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\n- `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\n- `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\n- `openspec/changes/knowledge-01-module-memory-runtime/design.md`\n- `openspec/changes/enterprise-02-module-audit-client/design.md`\n- `openspec/changes/knowledge-02-module-writeback/design.md`\n- `openspec/changes/security-01-module-sast-sca-secret/design.md`\n- `openspec/changes/architecture-02-module-well-architected/design.md`\n- `openspec/changes/review-resiliency-01-module/proposal.md`\n- `openspec/changes/codebase-import-runtime-hardening/design.md`\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n- `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\n- `openspec/changes/security-02-module-license-compliance/design.md`\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n- `openspec/changes/security-02-module-license-compliance/proposal.md`\n- `openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md`\n- `openspec/changes/knowledge-02-module-writeback/proposal.md`\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n- `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n- `openspec/CHANGE_ORDER.md`\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n\n

**/*.{js,ts,tsx,jsx,py,java,cs,go,rb,php,cpp,c,h}

\n\n\n**📄 CodeRabbit inference engine (CLAUDE.md)**\n\n> Preserve the clean-code compliance gate and its category references (naming, kiss, yagni, dry, and solid)\n\nFiles:\n- `tests/unit/workflows/test_sign_modules_on_approval.py`\n- `scripts/ensure_github_hierarchy_subissues.py`\n\n

tests/**/*.py

\n\n\n**⚙️ CodeRabbit configuration file**\n\n> `tests/**/*.py`: Contract-first and integration tests: migration suites, bundle validation, and flakiness.\n> Ensure changes to adapters or bridges have targeted coverage.\n> \n\nFiles:\n- `tests/unit/workflows/test_sign_modules_on_approval.py`\n\n

docs/**/*.md

\n\n\n**⚙️ CodeRabbit configuration file**\n\n> `docs/**/*.md`: User-facing and cross-site accuracy: Jekyll front matter, links per documentation-url-contract,\n> CLI examples matching bundled commands.\n> \n\nFiles:\n- `docs/bundles/project/import-migration.md`\n\n

scripts/**/*.py

\n\n\n**⚙️ CodeRabbit configuration file**\n\n> `scripts/**/*.py`: Deterministic tooling: signing, publishing, docs generation; subprocess and path safety.\n> \n\nFiles:\n- `scripts/ensure_github_hierarchy_subissues.py`\n\n

\n\n

🧠 Learnings (14)

\n\n

📓 Common learnings

\n\n```\nLearnt from: djm81\nRepo: nold-ai/specfact-cli-modules PR: 136\nFile: registry/modules/specfact-spec-0.40.17.tar.gz.sha256:1-1\nTimestamp: 2026-04-02T21:49:11.371Z\nLearning: In nold-ai/specfact-cli-modules, module tarball signatures (registry/signatures/*.tar.sig) are generated by the `publish-modules` GitHub Actions runner during the publish workflow, not committed locally to the branch. Missing signature files should NOT be flagged as a pre-merge blocker in PRs.\n```\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: AGENTS.md:0-0\nTimestamp: 2026-04-13T10:38:43.535Z\nLearning: Enforce module signatures and version bumps when signed module assets or manifests are affected\n```\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: CLAUDE.md:0-0\nTimestamp: 2026-04-13T10:38:29.399Z\nLearning: When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\n```\n\n

📚 Learning: 2026-04-13T10:38:15.855Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: .cursorrules:0-0\nTimestamp: 2026-04-13T10:38:15.855Z\nLearning: Adhere to worktree policy, OpenSpec gating, GitHub hierarchy-cache refresh, TDD order, quality gates, versioning, and documentation rules as defined in `docs/agent-rules/`\n```\n\n**Applied to files:**\n- `openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md`\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n\n

📚 Learning: 2026-04-13T10:38:29.399Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: CLAUDE.md:0-0\nTimestamp: 2026-04-13T10:38:29.399Z\nLearning: When a change is paired with work in specfact-cli, review the paired public change artifacts there before widening scope or redefining shared workflow semantics\n```\n\n**Applied to files:**\n- `openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\n- `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\n- `openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`\n- `openspec/changes/knowledge-01-module-memory-runtime/design.md`\n- `openspec/changes/architecture-02-module-well-architected/design.md`\n- `openspec/changes/review-resiliency-01-module/proposal.md`\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n- `tests/unit/workflows/test_sign_modules_on_approval.py`\n- `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n- `openspec/changes/knowledge-02-module-writeback/proposal.md`\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n- `openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n- `openspec/CHANGE_ORDER.md`\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n\n

📚 Learning: 2026-04-13T10:38:22.848Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: .github/copilot-instructions.md:0-0\nTimestamp: 2026-04-13T10:38:22.848Z\nLearning: Signed module or manifest changes require version-bump review and verify-modules-signature\n```\n\n**Applied to files:**\n- `openspec/changes/architecture-02-module-well-architected/proposal.md`\n- `openspec/changes/review-resiliency-01-module/proposal.md`\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n- `openspec/CHANGE_ORDER.md`\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n\n

📚 Learning: 2026-04-13T10:38:43.535Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: AGENTS.md:0-0\nTimestamp: 2026-04-13T10:38:43.535Z\nLearning: Fix SpecFact code review findings, including warnings, unless a rare explicit exception is documented\n```\n\n**Applied to files:**\n- `openspec/changes/knowledge-01-module-memory-runtime/proposal.md`\n- `openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n\n

📚 Learning: 2026-04-02T21:49:11.371Z

📚 Learning: 2026-04-13T10:38:43.535Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: AGENTS.md:0-0\nTimestamp: 2026-04-13T10:38:43.535Z\nLearning: Enforce module signatures and version bumps when signed module assets or manifests are affected\n```\n\n**Applied to files:**\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n\n

📚 Learning: 2026-04-13T10:38:43.535Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: AGENTS.md:0-0\nTimestamp: 2026-04-13T10:38:43.535Z\nLearning: Perform `spec -> tests -> failing evidence -> code -> passing evidence` in that order for behavior changes\n```\n\n**Applied to files:**\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n\n

📚 Learning: 2026-04-13T10:38:22.848Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: .github/copilot-instructions.md:0-0\nTimestamp: 2026-04-13T10:38:22.848Z\nLearning: Work belongs on feature/*, bugfix/*, hotfix/*, or chore/* branches, normally in a worktree rooted under ../specfact-cli-modules-worktrees/\n```\n\n**Applied to files:**\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n- `openspec/CHANGE_ORDER.md`\n- `openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`\n\n

📚 Learning: 2026-04-13T10:38:22.848Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: .github/copilot-instructions.md:0-0\nTimestamp: 2026-04-13T10:38:22.848Z\nLearning: This repository enforces the clean-code review gate through hatch run specfact code review run --json --out .specfact/code-review.json\n```\n\n**Applied to files:**\n- `openspec/changes/finops-01-module-cost-outcome/tasks.md`\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n\n

📚 Learning: 2026-04-13T10:38:43.535Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: AGENTS.md:0-0\nTimestamp: 2026-04-13T10:38:43.535Z\nLearning: Read docs/agent-rules/05-non-negotiable-checklist.md before implementation\n```\n\n**Applied to files:**\n- `openspec/changes/security-01-module-sast-sca-secret/tasks.md`\n\n

📚 Learning: 2026-04-13T10:38:22.848Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: .github/copilot-instructions.md:0-0\nTimestamp: 2026-04-13T10:38:22.848Z\nLearning: Refresh .specfact/backlog/github_hierarchy_cache.md with python scripts/sync_github_hierarchy_cache.py when GitHub hierarchy metadata is missing or stale before parent or blocker work\n```\n\n**Applied to files:**\n- `scripts/ensure_github_hierarchy_subissues.py`\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n\n

📚 Learning: 2026-04-13T10:38:43.535Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: AGENTS.md:0-0\nTimestamp: 2026-04-13T10:38:43.535Z\nLearning: If GitHub hierarchy metadata is needed and `.specfact/backlog/github_hierarchy_cache.md` is missing or stale, refresh it with `python scripts/sync_github_hierarchy_cache.py`\n```\n\n**Applied to files:**\n- `scripts/ensure_github_hierarchy_subissues.py`\n- `openspec/changes/codebase-import-runtime-hardening/tasks.md`\n\n

📚 Learning: 2026-04-13T10:38:29.399Z

\n\n```\nLearnt from: CR\nRepo: nold-ai/specfact-cli-modules PR: 0\nFile: CLAUDE.md:0-0\nTimestamp: 2026-04-13T10:38:29.399Z\nLearning: Treat canonical rule docs (docs/agent-rules/INDEX.md) as the source of truth for worktree policy, OpenSpec gating, GitHub completeness checks, TDD order, quality gates, versioning, and documentation rules\n```\n\n**Applied to files:**\n- `openspec/changes/codebase-import-runtime-hardening/specs/codebase-import-runtime/spec.md`\n\n

\n\n

🪛 LanguageTool

\n\n

openspec/changes/architecture-02-module-well-architected/proposal.md

openspec/changes/review-resiliency-01-module/proposal.md

openspec/changes/security-02-module-license-compliance/proposal.md

\n\n[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ...re security/license findings model. - **NEW**: Add policy-aware handling for allowe...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n---\n\n[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.\nContext: ...face explicit remediation guidance. - **NEW**: Define bundle manifest, registry, do...\n\n(ENGLISH_WORD_REPEAT_BEGINNING_RULE)\n\n

openspec/changes/knowledge-02-module-writeback/proposal.md

openspec/changes/codebase-import-runtime-hardening/tasks.md

\n\n[uncategorized] ~5-~5: The official name of this software platform is spelled with a capital “H”.\nContext: ...nd change scaffolding - [ ] 1.1 Verify `.specfact/backlog/github_hierarchy_cache.md` is fresh, confirm t...\n\n(GITHUB)\n\n