OpenSpec: five-pillar modules companion proposals (wave 2)#233
Conversation
Add ten OpenSpec changes for specfact-cli five-pillar runtime companions (FinOps, knowledge, review resiliency, security, architecture, enterprise), update CHANGE_ORDER with GitHub story links under modules epic #216, and add ensure_github_hierarchy_subissues.py to repair sub-issue edges. Made-with: Cursor
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughFive-Pillar OpenSpec Companion Wave 2: Module Surface & Cross-Repo DependenciesModule Bundles & Command SurfaceThis PR introduces ten new module bundles in proposal stage, spanning six governance pillars:
Manifest & Integrity RequirementsEach bundle requires:
Cross-Repository Dependencies (specfact-cli Paired Changes)All ten modules depend on existing or planned specfact-cli OpenSpec changes:
No specfact-cli code changes are included in this PR; all module proposals are scoped to proposal/design stage only. Bundle Architecture & Runtime Behavior
Documentation & Registry Impacts
OpenSpec Validation & Scenario CoverageValidation result: Scenario coverage highlights (from spec.md files):
Administrative & Tooling
WalkthroughAdds OpenSpec change folders (design/proposal/spec/tasks/.openspec.yaml) for ten module proposals across architecture, enterprise, finops, knowledge, review, and security, updates Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 37
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@openspec/changes/architecture-02-module-well-architected/design.md`:
- Around line 1-55: The file lacks a top-level title which triggers markdownlint
MD041; add a single H1 heading (for example "# Architecture Well-Architected
Module Design") at the very top of the document before the existing "## Context"
so the document has a clear standalone title and satisfies the lint rule; update
the document header in
openspec/changes/architecture-02-module-well-architected/design.md by inserting
that H1 line as the first line.
- Line 48: Replace the ambiguous phrase "the paired core architecture review
contract" with an explicit reference to the paired core change identifier
(architecture-02-well-architected-review) so the dependency matches the tracking
pattern used in proposal.md and tasks.md; update the sentence on line containing
that phrase to read something like "Confirm the paired core architecture review
contract (architecture-02-well-architected-review) is stable enough for module
integration." to ensure clear linkage.
In `@openspec/changes/architecture-02-module-well-architected/proposal.md`:
- Around line 11-12: The two consecutive bullets both start with the same
"**NEW**" lead-in (mentioning ALLOWED_IMPORTS.md and report surfaces), which
reduces readability; change the second bullet so it uses a different opener
(e.g., "Add" or "Introduce") and keep the same content about mapping
architecture findings into the paired core review contract and emitting evidence
for the knowledge runtime so the list reads more scanably while preserving
meaning.
In `@openspec/changes/architecture-02-module-well-architected/tasks.md`:
- Line 1: The top-level heading "1. Branch and dependency guardrails" currently
uses a level-2 heading (##) which triggers MD041; change the opening line so the
document starts with a level-1 heading by replacing "## 1. Branch and dependency
guardrails" with "# 1. Branch and dependency guardrails" to satisfy the linter
and keep the same heading text and intent.
In `@openspec/changes/enterprise-01-module-policy-client/design.md`:
- Line 1: Change the top-level heading "## Context" to an H1 by replacing the
double-hash with a single hash so the first line reads "# Context"; locate the
"Context" heading in
openspec/changes/enterprise-01-module-policy-client/design.md (the existing "##
Context") and update it to "# Context" to satisfy markdownlint.
In `@openspec/changes/enterprise-01-module-policy-client/tasks.md`:
- Line 1: The file starts with a level-2 heading which triggers MD041; change
the initial heading in this file from "## 1. Branch and dependency guardrails"
to a level-1 heading ("# 1. Branch and dependency guardrails") so the first line
is an H1 and satisfies markdown linting rules.
In
`@openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md`:
- Line 1: The top-level heading in enterprise-audit-client/spec.md uses a
level-2 heading "## ADDED Requirements"; change it to a level-1 heading by
replacing "## ADDED Requirements" with "# ADDED Requirements" so the file
complies with markdownlint H1 requirement (update any identical heading
occurrences in the same file if present).
- Around line 5-6: Replace the implicit references to the paired core contract
with the explicit core contract name enterprise-02-rbac-and-audit-trail: update
the bundle description that mentions nold-ai/specfact-enterprise-audit so
phrases like "paired core enterprise audit contracts" and "paired core
audit-event schema" are changed to explicitly reference
enterprise-02-rbac-and-audit-trail, and ensure the bundle's declared
core_compatibility and any queue/event serialization statements explicitly cite
enterprise-02-rbac-and-audit-trail for verifiable compatibility.
In `@openspec/changes/enterprise-02-module-audit-client/tasks.md`:
- Line 1: Replace the second-level heading "## 1. Branch and dependency
guardrails" with a first-level heading by changing the leading "##" to "#" so
the file's very first heading is H1 (i.e., update the heading token for the line
containing "1. Branch and dependency guardrails" to use a single "#").
In `@openspec/changes/finops-01-module-cost-outcome/design.md`:
- Line 49: Update step 2 to explicitly call out module-package.yaml as a
required adapter-boundary artifact: modify the sentence "Implement package
structure, collectors, and classifier adapters with fixture-based tests." to
include "module-package.yaml" and specify that the implementation must produce a
registry entry, module-package.yaml, signing metadata, and docs parity with
modules.specfact.io; ensure tests validate the presence and contents of
module-package.yaml alongside collectors and classifier adapters.
- Line 50: Step 3 currently lists "docs, registry metadata, signatures, and
compatibility ranges" but doesn't name where docs should be published; update
the Step 3 text in openspec/changes/finops-01-module-cost-outcome/design.md to
explicitly state that documentation must be published to modules.specfact.io (or
an equivalent canonical docs location) alongside registry metadata,
module-package.yaml, signatures, and compatibility ranges to ensure docs parity;
keep the existing phrasing about adapter boundaries and ensure the phrase "docs
parity with modules.specfact.io" appears directly in the step.
In
`@openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md`:
- Line 1: The top-level heading is using "## ADDED Requirements" which fails
linting; change the first markdown heading to an H1 by replacing "## ADDED
Requirements" with "# ADDED Requirements" (ensure it's the very first line of
the file so the document has a single H1 at the top).
- Line 5: The spec currently refers generically to "paired core FinOps
contracts"; update the bundle declaration for nold-ai/specfact-finops (the line
that exposes the `finops` command and declares `core_compatibility`) and the two
other occurrences that mention the generic "paired core FinOps contracts" so
they explicitly reference the core change id `finops-01-telemetry-and-outcomes`
(e.g., "paired core FinOps evidence contract from
`finops-01-telemetry-and-outcomes`") to make the spec explicitly linked to that
core change.
In `@openspec/changes/knowledge-01-module-memory-runtime/design.md`:
- Line 1: Change the top-level markdown heading from "## Context" to a level-1
heading by replacing the "## Context" line with "# Context" so the document uses
a single H1 at the start (update the heading text "Context" in the file where it
currently appears as "## Context").
In `@openspec/changes/knowledge-01-module-memory-runtime/tasks.md`:
- Line 19: For task 3.4 ensure parity with modules.specfact.io by (1) adding an
entry for the new bundle in the official modules registry that lists truthful
bundle dependencies, (2) updating public docs for the "knowledge" command
surface on modules.specfact.io, (3) producing a signed bundle artifact with a
version bump and updated signature verification, (4) updating import allowlists
for packages/specfact-knowledge/ dependencies, and (5) updating
module-package.yaml and any signing metadata so all registry, signing, docs, and
allowlist changes are coordinated and published together per the migration plan.
- Line 4: The task references a missing paired core change named
knowledge-01-distillation-engine required to satisfy the MemoryBackend contract
and to set minimum core_compatibility; update the spec by either
creating/confirming that the corresponding core change exists in specfact-cli
(openspec/changes/) or update the task to point to the correct core change name,
then document the minimum core_compatibility for this module (task 1.2) and
update references in packages/specfact-knowledge and CHANGE_ORDER to link to the
correct parent issue (specfact-cli#511) so the pairing is explicit and the
MemoryBackend contract implementation can proceed.
In
`@openspec/changes/knowledge-02-module-writeback/specs/knowledge-writeback/spec.md`:
- Around line 21-24: Update the requirement text "The bundle SHALL record
deterministic metadata that identifies source rules, target type, target
destination, and generation timestamps for each writeback operation" to
explicitly pin timestamp semantics: specify that generation timestamps MUST be
normalized to a provided deterministic run timestamp (e.g., a run_start_time
input) or, if absent, MUST be the writeback tool's run start timestamp,
formatted in UTC using ISO-8601 with second precision (YYYY-MM-DDThh:mm:ssZ) and
no subseconds or local offsets; also state that any existing timestamps in
inputs MUST be normalized to that format and timezone to ensure reproducible
manifests.
In `@openspec/changes/knowledge-02-module-writeback/tasks.md`:
- Around line 5-6: Update the checklist entry that currently reads "- [ ] 1.3
Before implementation, create or sync public GitHub tracking metadata..." to
explicitly require a hierarchy-cache refresh step; add a new checkbox such as
"Refresh GitHub hierarchy-cache (parent/child blocker graphs) and verify parent
linkage is authoritative" immediately after the metadata sync item so the
tracking guardrails ensure the hierarchy cache is refreshed and validated before
execution starts (reference the checklist item text "create or sync public
GitHub tracking metadata" and add the explicit "hierarchy-cache refresh"
requirement).
In `@openspec/changes/review-resiliency-01-module/design.md`:
- Line 48: Replace the generic phrase "the paired core change" in the sentence
"Land the paired core change so bundle development targets a stable findings
contract." with the explicit identifier `review-resiliency-01-contracts` so the
line reads that exact change (i.e., reference the paired core change by name
`review-resiliency-01-contracts` for clear cross-repo dependency tracking).
- Around line 1-55: Add a top-level Markdown title to the document (e.g.,
"Review Resiliency Module Design") as the first line so the file starts with a
single H1 header instead of beginning at "## Context"; update the title text to
match the module name and ensure it satisfies markdownlint MD041 and improves
standalone readability (change the leading heading in the document rather than
altering the existing "## Context" section).
In
`@openspec/changes/review-resiliency-01-module/specs/review-resiliency-module/spec.md`:
- Around line 14-20: The spec references a paired core change
`review-resiliency-01-contracts` that is missing from specfact-cli; confirm
whether that change exists under a different name in specfact-cli or create and
submit the core change (including the Finding model, Report schema, and
contracts) and add it to specfact-cli's CHANGE_ORDER; then update the modules
spec's reference to the exact artifact path (for example
`specfact_cli.review.resiliency.Finding` or the real module path) in the
sentence that mentions "paired core resiliency finding and report models" so
implementers can locate and validate against the concrete schema.
In `@openspec/changes/review-resiliency-01-module/tasks.md`:
- Line 19: Replace the phrasing "signatures" with the more precise phrase
"signing inputs" in the knowledge-01 tasks document so it matches the wording
used in openspec/changes/review-resiliency-01-module/tasks.md; specifically
locate the task that currently mentions "signatures" (the same task bullet that
corresponds to registry metadata and docs references) and update the text to
"signing inputs" to ensure consistent terminology across task files.
- Line 4: The task references a missing paired core change named
review-resiliency-01-contracts; create that core change in specfact-cli by
adding an openspec/changes/review-resiliency-01-contracts directory containing
the resiliency contract definitions and any adapter contract schemas, then
update this module's tasks.md (the 1.2 checklist item) to confirm the new change
exists and to document the minimum required core_compatibility; also update
CHANGE_ORDER.md and section 3.2 to point to the new change name and stable
version so the module and adapters can reference the canonical contract
artifacts.
In `@openspec/changes/security-01-module-sast-sca-secret/design.md`:
- Line 1: The top of the document uses a second-level heading ("## Context")
which violates MD041; change the opening heading to a top-level heading by
replacing "## Context" with "# Context" (i.e., update the document's first
heading in the design.md file so the first line begins with a single '#' to
satisfy the lint rule).
In
`@openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md`:
- Line 1: The markdown file uses a second-level heading "## ADDED Requirements"
which violates MD041; update the top of
specs/security-sast-sca-secret-module/spec.md to use a top-level H1 by changing
"## ADDED Requirements" to "# ADDED Requirements" so the document has a single
top-level heading and satisfies markdown-lint.
- Line 5: Update the spec text that generically references the "paired core"
contract to name the exact paired core contract identifiers: replace the generic
mentions with security-01-unified-findings-model for the security
findings/report contract and policy-02-packs-and-modes for the policy modes
contract wherever the bundle declaration mentions core_compatibility or paired
core (e.g., the nold-ai/specfact-security bundle exposing the security command
and its core_compatibility entries); ensure both identifiers appear in the
core_compatibility field and any descriptive sentences so automated cross-repo
tests can match CHANGE_ORDER.md.
In `@openspec/changes/security-01-module-sast-sca-secret/tasks.md`:
- Line 1: Change the first markdown heading "Branch and dependency guardrails"
to a top-level H1 by prefixing it with a single "#" (i.e., "# Branch and
dependency guardrails") so the file's first line is a proper H1 and satisfies
markdown lint; locate the heading text in tasks.md and update it accordingly.
In
`@openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md`:
- Line 1: Change the top-level heading in the specs file from a level-2 header
("## ADDED Requirements") to a level-1 header ("# ADDED Requirements") so the
first line is H1 and satisfies markdownlint rule MD041; update the header text
in the file where the string "## ADDED Requirements" appears (spec.md) to use a
single leading '#' instead of '##'.
- Line 5: Update the spec language to explicitly reference the paired core
contract name `security-01-unified-findings-model` instead of vague phrases:
replace the phrase "shared core findings model" in the
`nold-ai/specfact-license-compliance` bundle requirement and replace "paired
core findings/report contracts" elsewhere in the document with the exact
artifact name `security-01-unified-findings-model` so the spec unambiguously
targets that core contract for validation and adapter implementations.
In `@openspec/changes/security-02-module-license-compliance/tasks.md`:
- Line 4: Update the task on line referencing "paired core security
findings/policy changes" to explicitly list the paired core changes
`security-01-unified-findings-model` and `security-02-eu-gdpr-baseline`, so
implementers can verify the minimum required `core_compatibility` and track
cross-repo dependencies; specifically edit the checklist item that currently
reads "Confirm paired core security findings/policy changes are available..." to
name those two changes and mention that `core_compatibility` must be documented
against them.
In `@openspec/changes/security-03-module-pii-gdpr-eu/proposal.md`:
- Around line 11-30: Add an explicit blocked-by dependency for the shared
policy-pack core so the proposal lists execution order/paired changes: in the
Dependencies section add a line declaring the policy-pack core pairing (e.g.,
reference specfact-cli#511 and the paired core change) alongside the existing
security-01-unified-findings-model and security-02-eu-gdpr-baseline entries so
the new privacy-gdpr-module capability is explicitly blocked-by that policy-pack
core work.
In
`@openspec/changes/security-03-module-pii-gdpr-eu/specs/privacy-gdpr-module/spec.md`:
- Line 5: Update the `core_compatibility` requirement for the
`nold-ai/specfact-pii-gdpr` bundle (the one exposing the `privacy` command) to
explicitly list the paired core change identifiers
`security-01-unified-findings-model` and `security-02-eu-gdpr-baseline` so the
bundle declares compatibility with those specific core privacy/GDPR contracts
rather than a generic reference.
- Around line 1-28: This file starts with "## ADDED Requirements" and lacks a
top-level document title; add a top-level Markdown heading (for example "#
Privacy and GDPR Module Specification") at the very top of the document so the
existing "## ADDED Requirements" becomes a second-level section; ensure the new
title is a single H1 and that the change satisfies markdownlint MD041 without
altering the existing section headings or requirements text.
In `@openspec/changes/security-03-module-pii-gdpr-eu/tasks.md`:
- Line 1: The top-level heading violates MD041 because the file's first line
uses '## 1. Branch and dependency guardrails' instead of an H1; change that
first line to use a single '#' (i.e. '# 1. Branch and dependency guardrails') so
the document begins with an H1, ensuring the header text remains identical and
satisfying the MD041 rule.
In `@scripts/ensure_github_hierarchy_subissues.py`:
- Around line 40-55: The _gh_graphql function can block indefinitely; add a
timeout to the subprocess.run call (e.g., timeout=30) and handle
subprocess.TimeoutExpired by raising a clear RuntimeError (include the
command/context like "gh graphql timed out"). Keep capture_output=True and
text=True, and preserve the existing error-path behavior (raise RuntimeError on
non-zero returncode or JSON errors) so callers of _gh_graphql see deterministic
failures instead of hanging.
- Around line 114-125: The dry-run branch incorrectly increments the real
"added" counter and the final summary always prints that value, so update the
logic in the block that checks args.dry_run: do not increment the real added
counter when args.dry_run is true (either remove added += 1 inside the dry-run
branch or introduce a separate simulated counter like simulated_added), adjust
the sys.stdout.write messages in the dry-run branch to clearly indicate
simulation, and ensure the final summary uses the actual added and skipped
counters (and optionally reports simulated_added) after calling _add_sub_issue
in the non-dry-run path; references: args.dry_run, added, skipped,
_add_sub_issue, sys.stdout.write.
- Around line 70-84: The _subissue_numbers function currently requests subIssues
with a fixed first:50 and no pagination; update it to iterate pages via GraphQL
pagination (use first:100, include after:$cursor, and read pageInfo.hasNextPage
and pageInfo.endCursor) by calling _gh_graphql repeatedly until hasNextPage is
false, accumulating nodes across pages and returning the deduplicated set of
ints; keep the same error handling for missing issue and ensure you parse nodes
from each page (n["number"]) before converting to int.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 21ddc5ae-8486-4668-a746-933039a4e4e0
📒 Files selected for processing (52)
openspec/CHANGE_ORDER.mdopenspec/changes/architecture-02-module-well-architected/.openspec.yamlopenspec/changes/architecture-02-module-well-architected/design.mdopenspec/changes/architecture-02-module-well-architected/proposal.mdopenspec/changes/architecture-02-module-well-architected/specs/architecture-well-architected-module/spec.mdopenspec/changes/architecture-02-module-well-architected/tasks.mdopenspec/changes/enterprise-01-module-policy-client/.openspec.yamlopenspec/changes/enterprise-01-module-policy-client/design.mdopenspec/changes/enterprise-01-module-policy-client/proposal.mdopenspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.mdopenspec/changes/enterprise-01-module-policy-client/tasks.mdopenspec/changes/enterprise-02-module-audit-client/.openspec.yamlopenspec/changes/enterprise-02-module-audit-client/design.mdopenspec/changes/enterprise-02-module-audit-client/proposal.mdopenspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.mdopenspec/changes/enterprise-02-module-audit-client/tasks.mdopenspec/changes/finops-01-module-cost-outcome/.openspec.yamlopenspec/changes/finops-01-module-cost-outcome/design.mdopenspec/changes/finops-01-module-cost-outcome/proposal.mdopenspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.mdopenspec/changes/finops-01-module-cost-outcome/tasks.mdopenspec/changes/knowledge-01-module-memory-runtime/.openspec.yamlopenspec/changes/knowledge-01-module-memory-runtime/design.mdopenspec/changes/knowledge-01-module-memory-runtime/proposal.mdopenspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.mdopenspec/changes/knowledge-01-module-memory-runtime/tasks.mdopenspec/changes/knowledge-02-module-writeback/.openspec.yamlopenspec/changes/knowledge-02-module-writeback/design.mdopenspec/changes/knowledge-02-module-writeback/proposal.mdopenspec/changes/knowledge-02-module-writeback/specs/knowledge-writeback/spec.mdopenspec/changes/knowledge-02-module-writeback/tasks.mdopenspec/changes/review-resiliency-01-module/.openspec.yamlopenspec/changes/review-resiliency-01-module/design.mdopenspec/changes/review-resiliency-01-module/proposal.mdopenspec/changes/review-resiliency-01-module/specs/review-resiliency-module/spec.mdopenspec/changes/review-resiliency-01-module/tasks.mdopenspec/changes/security-01-module-sast-sca-secret/.openspec.yamlopenspec/changes/security-01-module-sast-sca-secret/design.mdopenspec/changes/security-01-module-sast-sca-secret/proposal.mdopenspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.mdopenspec/changes/security-01-module-sast-sca-secret/tasks.mdopenspec/changes/security-02-module-license-compliance/.openspec.yamlopenspec/changes/security-02-module-license-compliance/design.mdopenspec/changes/security-02-module-license-compliance/proposal.mdopenspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.mdopenspec/changes/security-02-module-license-compliance/tasks.mdopenspec/changes/security-03-module-pii-gdpr-eu/.openspec.yamlopenspec/changes/security-03-module-pii-gdpr-eu/design.mdopenspec/changes/security-03-module-pii-gdpr-eu/proposal.mdopenspec/changes/security-03-module-pii-gdpr-eu/specs/privacy-gdpr-module/spec.mdopenspec/changes/security-03-module-pii-gdpr-eu/tasks.mdscripts/ensure_github_hierarchy_subissues.py
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: quality (3.13)
- GitHub Check: quality (3.12)
- GitHub Check: quality (3.11)
🧰 Additional context used
📓 Path-based instructions (3)
openspec/**/*.md
⚙️ CodeRabbit configuration file
openspec/**/*.md: Specification truth: proposal/tasks/spec deltas vs. bundle behavior, CHANGE_ORDER, and
drift vs. shipped modules or docs.
Files:
openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.mdopenspec/changes/architecture-02-module-well-architected/specs/architecture-well-architected-module/spec.mdopenspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.mdopenspec/changes/enterprise-02-module-audit-client/design.mdopenspec/changes/review-resiliency-01-module/specs/review-resiliency-module/spec.mdopenspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.mdopenspec/changes/security-03-module-pii-gdpr-eu/proposal.mdopenspec/changes/architecture-02-module-well-architected/design.mdopenspec/changes/security-02-module-license-compliance/design.mdopenspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.mdopenspec/changes/architecture-02-module-well-architected/proposal.mdopenspec/changes/security-01-module-sast-sca-secret/design.mdopenspec/changes/security-01-module-sast-sca-secret/proposal.mdopenspec/changes/security-03-module-pii-gdpr-eu/design.mdopenspec/changes/enterprise-02-module-audit-client/proposal.mdopenspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.mdopenspec/changes/finops-01-module-cost-outcome/tasks.mdopenspec/changes/security-02-module-license-compliance/proposal.mdopenspec/CHANGE_ORDER.mdopenspec/changes/enterprise-02-module-audit-client/tasks.mdopenspec/changes/knowledge-02-module-writeback/specs/knowledge-writeback/spec.mdopenspec/changes/knowledge-02-module-writeback/design.mdopenspec/changes/knowledge-01-module-memory-runtime/design.mdopenspec/changes/knowledge-01-module-memory-runtime/proposal.mdopenspec/changes/security-02-module-license-compliance/tasks.mdopenspec/changes/knowledge-02-module-writeback/proposal.mdopenspec/changes/security-01-module-sast-sca-secret/tasks.mdopenspec/changes/enterprise-01-module-policy-client/tasks.mdopenspec/changes/enterprise-01-module-policy-client/design.mdopenspec/changes/review-resiliency-01-module/proposal.mdopenspec/changes/review-resiliency-01-module/tasks.mdopenspec/changes/security-03-module-pii-gdpr-eu/specs/privacy-gdpr-module/spec.mdopenspec/changes/finops-01-module-cost-outcome/proposal.mdopenspec/changes/architecture-02-module-well-architected/tasks.mdopenspec/changes/finops-01-module-cost-outcome/design.mdopenspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.mdopenspec/changes/knowledge-01-module-memory-runtime/tasks.mdopenspec/changes/security-03-module-pii-gdpr-eu/tasks.mdopenspec/changes/enterprise-01-module-policy-client/proposal.mdopenspec/changes/knowledge-02-module-writeback/tasks.mdopenspec/changes/review-resiliency-01-module/design.md
**/*.{js,ts,tsx,jsx,py,java,cs,go,rb,php,cpp,c,h}
📄 CodeRabbit inference engine (CLAUDE.md)
Preserve the clean-code compliance gate and its category references (naming, kiss, yagni, dry, and solid)
Files:
scripts/ensure_github_hierarchy_subissues.py
scripts/**/*.py
⚙️ CodeRabbit configuration file
scripts/**/*.py: Deterministic tooling: signing, publishing, docs generation; subprocess and path safety.
Files:
scripts/ensure_github_hierarchy_subissues.py
🧠 Learnings (14)
📓 Common learnings
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: .cursorrules:0-0
Timestamp: 2026-04-13T10:38:15.855Z
Learning: Adhere to worktree policy, OpenSpec gating, GitHub hierarchy-cache refresh, TDD order, quality gates, versioning, and documentation rules as defined in `docs/agent-rules/`
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-13T10:38:29.399Z
Learning: 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
📚 Learning: 2026-04-13T10:38:43.535Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-13T10:38:43.535Z
Learning: Finalize completed OpenSpec changes with `openspec archive <change-id>` and do not manually move change folders under `openspec/changes/archive/`
Applied to files:
openspec/changes/security-02-module-license-compliance/.openspec.yamlopenspec/changes/architecture-02-module-well-architected/.openspec.yaml
📚 Learning: 2026-04-13T10:38:22.848Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2026-04-13T10:38:22.848Z
Learning: Signed module or manifest changes require version-bump review and verify-modules-signature
Applied to files:
openspec/changes/architecture-02-module-well-architected/specs/architecture-well-architected-module/spec.mdopenspec/changes/review-resiliency-01-module/specs/review-resiliency-module/spec.mdopenspec/CHANGE_ORDER.mdopenspec/changes/review-resiliency-01-module/proposal.mdopenspec/changes/review-resiliency-01-module/tasks.md
📚 Learning: 2026-04-02T21:49:11.371Z
Learnt from: djm81
Repo: nold-ai/specfact-cli-modules PR: 136
File: registry/modules/specfact-spec-0.40.17.tar.gz.sha256:1-1
Timestamp: 2026-04-02T21:49:11.371Z
Learning: 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.
Applied to files:
openspec/changes/architecture-02-module-well-architected/specs/architecture-well-architected-module/spec.mdopenspec/changes/review-resiliency-01-module/specs/review-resiliency-module/spec.mdopenspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.mdopenspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.mdopenspec/changes/enterprise-02-module-audit-client/tasks.mdopenspec/changes/security-01-module-sast-sca-secret/tasks.md
📚 Learning: 2026-04-13T10:38:43.535Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-13T10:38:43.535Z
Learning: Enforce module signatures and version bumps when signed module assets or manifests are affected
Applied to files:
openspec/changes/architecture-02-module-well-architected/specs/architecture-well-architected-module/spec.md
📚 Learning: 2026-04-13T10:38:29.399Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-13T10:38:29.399Z
Learning: 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
Applied to files:
openspec/changes/review-resiliency-01-module/specs/review-resiliency-module/spec.mdopenspec/changes/finops-01-module-cost-outcome/tasks.mdopenspec/CHANGE_ORDER.mdopenspec/changes/enterprise-02-module-audit-client/tasks.mdopenspec/changes/knowledge-02-module-writeback/design.mdopenspec/changes/security-02-module-license-compliance/tasks.mdopenspec/changes/knowledge-02-module-writeback/proposal.mdopenspec/changes/security-01-module-sast-sca-secret/tasks.mdopenspec/changes/enterprise-01-module-policy-client/tasks.mdopenspec/changes/review-resiliency-01-module/proposal.mdopenspec/changes/review-resiliency-01-module/tasks.mdopenspec/changes/architecture-02-module-well-architected/tasks.mdopenspec/changes/knowledge-01-module-memory-runtime/tasks.mdopenspec/changes/security-03-module-pii-gdpr-eu/tasks.mdopenspec/changes/knowledge-02-module-writeback/tasks.mdopenspec/changes/review-resiliency-01-module/design.md
📚 Learning: 2026-04-13T10:38:43.535Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-13T10:38:43.535Z
Learning: Perform `spec -> tests -> failing evidence -> code -> passing evidence` in that order for behavior changes
Applied to files:
openspec/changes/finops-01-module-cost-outcome/tasks.mdopenspec/changes/enterprise-02-module-audit-client/tasks.mdopenspec/changes/security-02-module-license-compliance/tasks.mdopenspec/changes/security-01-module-sast-sca-secret/tasks.mdopenspec/changes/enterprise-01-module-policy-client/tasks.mdopenspec/changes/review-resiliency-01-module/tasks.mdopenspec/changes/architecture-02-module-well-architected/tasks.mdopenspec/changes/knowledge-01-module-memory-runtime/tasks.mdopenspec/changes/security-03-module-pii-gdpr-eu/tasks.mdopenspec/changes/knowledge-02-module-writeback/tasks.md
📚 Learning: 2026-04-13T10:38:22.848Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2026-04-13T10:38:22.848Z
Learning: Work belongs on feature/*, bugfix/*, hotfix/*, or chore/* branches, normally in a worktree rooted under ../specfact-cli-modules-worktrees/
Applied to files:
openspec/changes/finops-01-module-cost-outcome/tasks.mdopenspec/changes/enterprise-02-module-audit-client/tasks.mdopenspec/changes/security-02-module-license-compliance/tasks.mdopenspec/changes/security-01-module-sast-sca-secret/tasks.mdopenspec/changes/enterprise-01-module-policy-client/tasks.mdopenspec/changes/review-resiliency-01-module/tasks.mdopenspec/changes/architecture-02-module-well-architected/tasks.mdopenspec/changes/knowledge-01-module-memory-runtime/tasks.mdopenspec/changes/security-03-module-pii-gdpr-eu/tasks.mdopenspec/changes/knowledge-02-module-writeback/tasks.md
📚 Learning: 2026-04-13T10:38:15.855Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: .cursorrules:0-0
Timestamp: 2026-04-13T10:38:15.855Z
Learning: Adhere to worktree policy, OpenSpec gating, GitHub hierarchy-cache refresh, TDD order, quality gates, versioning, and documentation rules as defined in `docs/agent-rules/`
Applied to files:
openspec/changes/finops-01-module-cost-outcome/tasks.mdopenspec/changes/enterprise-02-module-audit-client/tasks.mdopenspec/changes/security-02-module-license-compliance/tasks.mdopenspec/changes/security-01-module-sast-sca-secret/tasks.mdopenspec/changes/enterprise-01-module-policy-client/tasks.mdopenspec/changes/review-resiliency-01-module/tasks.mdopenspec/changes/architecture-02-module-well-architected/tasks.mdopenspec/changes/knowledge-01-module-memory-runtime/tasks.mdopenspec/changes/security-03-module-pii-gdpr-eu/tasks.mdopenspec/changes/knowledge-02-module-writeback/tasks.md
📚 Learning: 2026-04-13T10:38:22.848Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2026-04-13T10:38:22.848Z
Learning: This repository enforces the clean-code review gate through hatch run specfact code review run --json --out .specfact/code-review.json
Applied to files:
openspec/changes/security-02-module-license-compliance/tasks.mdopenspec/changes/security-01-module-sast-sca-secret/tasks.mdopenspec/changes/review-resiliency-01-module/tasks.mdopenspec/changes/architecture-02-module-well-architected/tasks.mdopenspec/changes/knowledge-01-module-memory-runtime/tasks.md
📚 Learning: 2026-04-13T10:38:29.399Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-13T10:38:29.399Z
Learning: 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
Applied to files:
openspec/changes/enterprise-01-module-policy-client/tasks.mdopenspec/changes/architecture-02-module-well-architected/tasks.md
📚 Learning: 2026-04-13T10:38:43.535Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-13T10:38:43.535Z
Learning: Run the required verification and quality gates for the touched scope before finalization
Applied to files:
openspec/changes/architecture-02-module-well-architected/tasks.md
📚 Learning: 2026-04-13T10:38:22.848Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2026-04-13T10:38:22.848Z
Learning: 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
Applied to files:
scripts/ensure_github_hierarchy_subissues.py
📚 Learning: 2026-04-13T10:38:43.535Z
Learnt from: CR
Repo: nold-ai/specfact-cli-modules PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-13T10:38:43.535Z
Learning: 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`
Applied to files:
scripts/ensure_github_hierarchy_subissues.py
🪛 LanguageTool
openspec/changes/security-03-module-pii-gdpr-eu/proposal.md
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...rivacy and GDPR finding categories. - NEW: Add EU-specific residency and lawful...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...mechanism rather than ad hoc flags. - NEW: Define redaction-safe evidence and r...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
openspec/changes/architecture-02-module-well-architected/proposal.md
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ity, and interface-diff evaluation. - NEW: Encode the ALLOWED_IMPORTS.md patt...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...he same boundary-checking approach. - NEW: Add report surfaces that map archite...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
openspec/changes/security-01-module-sast-sca-secret/proposal.md
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...into the paired core finding model. - NEW: Add profile-aware execution modes th...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ing policy semantics in the bundle. - NEW: Define stable output surfaces for ma...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~12-~12: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...EW**: Define stable output surfaces for markdown and JSON security reports and optional ...
(MARKDOWN_NNP)
openspec/changes/enterprise-02-module-audit-client/proposal.md
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... with the paired core audit schema. - NEW: Add privacy-aware handling so audit ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...without leaking restricted content. - NEW: Define deterministic local queue/rec...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
openspec/changes/security-02-module-license-compliance/proposal.md
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...re security/license findings model. - NEW: Add policy-aware handling for allowe...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...face explicit remediation guidance. - NEW: Define bundle manifest, registry, do...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
openspec/changes/knowledge-01-module-memory-runtime/proposal.md
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...nd rules under .specfact/memory/. - NEW: Define gitignore, repo-layout, and f...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ules, and generated graph metadata. - NEW: Add search and status surfaces that ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
openspec/changes/knowledge-02-module-writeback/proposal.md
[uncategorized] ~10-~10: The official name of this software platform is spelled with a capital “H”.
Context: ...EW**: Package adapters for BUGBOT.md, .github/copilot-instructions.md, and CodeRabbi...
(GITHUB)
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...drafts as opt-in writeback targets. - NEW: Require preview/dry-run output and e...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...eviewable and safe for repo owners. - NEW: Normalize selected rule metadata int...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
openspec/changes/review-resiliency-01-module/proposal.md
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... the paired core findings contract. - NEW: Add optional probe adapters for ligh...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...s stay local-first and safe for CI. - NEW: Emit findings in the shared review r...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
openspec/changes/finops-01-module-cost-outcome/proposal.md
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ped or inference-only environments. - NEW: Add an outcome classifier that maps ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...o the paired core outcome taxonomy. - NEW: Emit evidence files compatible with ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
openspec/changes/finops-01-module-cost-outcome/design.md
[style] ~42-~42: ‘lag behind’ might be wordy. Consider a shorter alternative.
Context: ...- Risk: Billing APIs differ and may lag behind model usage events. → Mitigation: p...
(EN_WORDINESS_PREMIUM_LAG_BEHIND)
openspec/changes/enterprise-01-module-policy-client/proposal.md
[style] ~11-~11: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...rs into the local resolution chain. - NEW: Add graceful no-op behavior when no ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~12-~12: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...r and offline users are unaffected. - NEW: Define deterministic local cache and...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🪛 markdownlint-cli2 (0.22.0)
openspec/changes/enterprise-01-module-policy-client/specs/enterprise-policy-client/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/architecture-02-module-well-architected/specs/architecture-well-architected-module/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/security-01-module-sast-sca-secret/specs/security-sast-sca-secret-module/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/enterprise-02-module-audit-client/design.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/review-resiliency-01-module/specs/review-resiliency-module/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/knowledge-01-module-memory-runtime/specs/knowledge-memory-runtime/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/architecture-02-module-well-architected/design.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/security-02-module-license-compliance/design.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/security-02-module-license-compliance/specs/license-compliance-module/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/security-01-module-sast-sca-secret/design.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/security-03-module-pii-gdpr-eu/design.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/enterprise-02-module-audit-client/specs/enterprise-audit-client/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/knowledge-02-module-writeback/specs/knowledge-writeback/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/knowledge-01-module-memory-runtime/design.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/security-02-module-license-compliance/tasks.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/security-01-module-sast-sca-secret/tasks.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/enterprise-01-module-policy-client/tasks.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/enterprise-01-module-policy-client/design.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/review-resiliency-01-module/tasks.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/security-03-module-pii-gdpr-eu/specs/privacy-gdpr-module/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/architecture-02-module-well-architected/tasks.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/finops-01-module-cost-outcome/specs/finops-cost-outcome-module/spec.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/security-03-module-pii-gdpr-eu/tasks.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/knowledge-02-module-writeback/tasks.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
openspec/changes/review-resiliency-01-module/design.md
[warning] 1-1: First line in a file should be a top-level heading
(MD041, first-line-heading, first-line-h1)
🔀 Multi-repo context nold-ai/specfact-cli
[::nold-ai/specfact-cli::] openspec/CHANGE_ORDER.md — contains CHANGE_ORDER entries (including references to modules-owned changes and the five-pillar entries). (see grep hits around openspec/CHANGE_ORDER.md lines printed in shell output)
[::nold-ai/specfact-cli::] openspec/changes/... — The repo contains many openspec change directories and specs; the new modules-style change folders referenced by the PR live under openspec/changes/ (numerous matches in the repository; bridge/adapter code reads these files: src/specfact_cli/adapters/openspec.py and src/specfact_cli/adapters/openspec_parser.py).
[::nold-ai/specfact-cli::] src/specfact_cli/adapters/openspec.py and src/specfact_cli/adapters/openspec_parser.py — code paths that enumerate and parse openspec/changes/ proposal.md, tasks.md and spec.md files (these are consumers of the added documentation artifacts).
[::nold-ai/specfact-cli::] scripts/ensure_github_hierarchy_subissues.py — Not found in the working tree (shell stderr: "sed: can't read scripts/ensure_github_hierarchy_subissues.py: No such file or directory"). If the PR intends to add this script, ensure it is placed in this repository's scripts/ directory; otherwise confirm its location (maybe in specfact-cli-modules).
Observations relevant to review:
- The PR is documentation/spec additions (openspec/changes/) which are consumed by the repository's OpenSpec parsing code (src/specfact_cli/adapters/*) and surfaced via CHANGE_ORDER.md; no runtime API or exported public code changes were detected in this repo.
- Verify the intended placement of the new ensure_github_hierarchy_subissues.py script — current checkout does not contain it at scripts/, so either the script is in another repo or the PR omitted it.
…t hardening - Design/tasks: add H1 titles or promote first headings; clarify paired OpenSpec ids. - Specs: add document H1 plus keep ## ADDED Requirements for OpenSpec delta parsing; name security, finops, enterprise, license, resiliency contracts explicitly. - knowledge/review tasks: verify upstream paths on paired specfact-cli branch; knowledge-02 adds hierarchy-cache refresh; writeback spec pins UTC timestamps. - security-03 proposal: blocked-by policy-02-packs-and-modes for policy-pack work. - ensure_github_hierarchy_subissues: subprocess timeout, dry-run counter fix, paginated subIssues fetch, omit null GraphQL variables. Made-with: Cursor
Made-with: Cursor
Summary
This pull request adds the modules-side OpenSpec proposal outline for the five-pillar governance companion wave aligned with specfact-cli#511.
Changes
openspec/changes/: FinOps, knowledge (memory + writeback), review resiliency, security (SAST/SCA/secrets, license compliance, PII/GDPR), architecture (well-architected), enterprise (policy client + audit client). Each includesproposal.md,design.md,tasks.md, spec delta, and.openspec.yaml.openspec/CHANGE_ORDER.md: five-pillar table updated with GitHub story links and parent epic/feature references (modules#216 and feature groups #217–#222).scripts/ensure_github_hierarchy_subissues.py: optional repair script that calls GraphQLaddSubIssuewhen a parent’ssubIssueslist is missing an expected child (idempotent).GitHub tracking
openspec validate --changes --strict: 30 passed.Scope note
Proposal stage only — no runtime bundle implementation in this PR.
Made with Cursor