Decadal Strategic & Technical Plan 2026–2035 (Sentinel v2.4 / Omni-Sentinel Mesh v4.0 / SCP v3.0)#139
Open
OneFineStarstuff wants to merge 9 commits into
Open
Decadal Strategic & Technical Plan 2026–2035 (Sentinel v2.4 / Omni-Sentinel Mesh v4.0 / SCP v3.0)#139OneFineStarstuff wants to merge 9 commits into
OneFineStarstuff wants to merge 9 commits into
Conversation
|
The files' contents are under analysis for test generation. |
|
Review these changes at https://app.gitnotebooks.com/OneFineStarstuff/OneFineStarstuff.github.io/pull/139 |
❌ Deploy Preview for onefinestarstuff failed.
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @OneFineStarstuff, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
View changes in DiffLens |
github-actions
Bot
added
the
documentation
Contributor
|
Note Reviews pausedIt 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 Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR adds a decadal governance blueprint, updates the roadmap and pilot-gate workflow, extends runnable assurance with OSCAL conformance checks, and hardens the Next.js app with authenticated sessions, request validation, rate limiting, signed consent events, and route-level enforcement. ChangesGovernance Blueprint, Roadmap, Pilot Gates, and Assurance
Next.js Security Hardening and Dashboard Remediation
Sequence Diagram(s)sequenceDiagram
participant Client
participant Middleware
participant Session as session.ts
participant Route as API route
participant Guard as readJson/sanitizeForStream
Client->>Middleware: request to /api/*
Middleware->>Session: derive client key and enforce limit
Client->>Route: authenticated request
Route->>Guard: parse body / sanitize stream
Guard-->>Route: validated data or structured error
Estimated code review effort🎯 5 (Critical) | ⏱️ ~90 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
 |
|
Overall Grade |
Security  Reliability  Complexity Hygiene  |
Code Review Summary
| Analyzer | Status | Updated (UTC) | Details |
|---|---|---|---|
| Python |  |
Jul 3, 2026 12:46p.m. | Review ↗ |
| JavaScript | |
Jul 3, 2026 12:46p.m. | Review ↗ |
| Shell |  |
Jul 3, 2026 12:46p.m. | Review ↗ |
Important
AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.
![gstraccini[bot]](https://avatars.githubusercontent.com/in/480132?s=60&v=4){kind=small}
Not up to standards ⛔🔴 Issues
|
| Category | Results |
|---|---|
| Compatibility | 1 high |
| BestPractice | 2 medium |
| Documentation | 4 minor |
| ErrorProne | 4 high |
| Security | 1 critical |
| CodeStyle | 86 minor |
| Complexity | 1 medium |
| Performance | 1 medium |
🟢 Metrics 106 complexity · 2 duplication
Metric Results Complexity 106 Duplication 2
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
View changes in DiffLens |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md (1)
65-83: 💤 Low valueAdd a language identifier to the ASCII diagram code block.
Line 65 opens a fenced code block for the architecture diagram. Adding a language identifier (e.g.,
text` orascii`) improves markdown linting compliance and readability.✨ Proposed fix
### 2. Architecture overview (the four control planes) -``` +```text ┌──────────────────────────────────────────────────────────────────────────────────┐ │ SCP v3.0 — Unified AI Supervisory Control Plane (supervisor-facing) │🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md` around lines 65 - 83, The ASCII architecture diagram code block starting at line 65 does not have a language identifier in its opening fence. Add a language identifier such as `text` or `ascii` immediately after the opening triple backticks (e.g., change the opening fence from ``` to ```text) to improve markdown linting compliance and readability of the diagram block.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md`:
- Around line 65-102: Two Tier A artifacts referenced in the
component-to-artifact-to-evidence map are missing from the repository:
tla/SentinelContainmentProtocol.tla and tla/KillSwitchAbstract.tla. These files
are cited as having verifiable TLC model-checking evidence (75 + 13 states with
no errors) for the containment one-way ratchet and kill-switch abstraction
control components. Either create and add these TLA+ files to the repository
with the corresponding TLC verification results, or update the table rows
referencing these files to remove them and correct the Tier A evidence claims to
match what actually exists in the repository.
- Around line 397-412: The "Full assurance suite" row in the verification ledger
section claims "11/11 PASS" but the actual execution of bash
governance_artifacts/run_runnable_assurance.sh fails at the OPA policy tests
step because OPA is not installed. Update the "Last result" column for the "Full
assurance suite" row to reflect the actual failure output (e.g., "FAIL: opa:
command not found" or similar), or alternatively ensure all required
dependencies including OPA, TLC, terraform, node, and python3 packages are
properly installed and available in the environment so the command can execute
successfully and produce the claimed result. Verify that all other commands in
the verification ledger table also execute correctly and produce their claimed
outputs before updating their results.
---
Nitpick comments:
In `@governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md`:
- Around line 65-83: The ASCII architecture diagram code block starting at line
65 does not have a language identifier in its opening fence. Add a language
identifier such as `text` or `ascii` immediately after the opening triple
backticks (e.g., change the opening fence from ``` to ```text) to improve
markdown linting compliance and readability of the diagram block.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: d24fab33-4acc-4150-98d5-389a2fd351e2
📒 Files selected for processing (1)
governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md
|
View changes in DiffLens |
Owner
Author
Update — follow-on hardening (commit 8892373)Three concrete follow-ups, all verified: 1. Roadmap phases 5–8 promoted to first-class
2. Runnable 2028 pilot acceptance-gate checklist
3. Dashboard High-severity findings closed (DASH-01/02/03/05/08)
Regression: |
|
View changes in DiffLens |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
next-app/app/api/consent/route.ts (1)
36-36: 🧹 Nitpick | 🔵 Trivial | 💤 Low valueRedundant type cast.
new Date().toISOString()already returnsstring, so theas unknown as stringcast is unnecessary.- ts: new Date().toISOString() as unknown as string, + ts: new Date().toISOString(),🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@next-app/app/api/consent/route.ts` at line 36, The ts property assignment in the consent route includes a redundant type cast `as unknown as string` after calling `new Date().toISOString()`. Since the toISOString() method already returns a string type, the explicit cast is unnecessary and should be removed. Simply replace the line to use `ts: new Date().toISOString()` without any type annotations.next-app/app/api/intent/route.ts (1)
18-21: 🧹 Nitpick | 🔵 Trivial | 💤 Low valueConsider rejecting empty message for consistency.
The chat route rejects empty strings with
message.length === 0, but this route only checkstypeof message !== 'string'. An empty string would pass validation and return'casual'. While not harmful, aligning validation behavior across routes aids maintainability.- if (typeof message !== 'string') { + if (typeof message !== 'string' || message.length === 0) {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@next-app/app/api/intent/route.ts` around lines 18 - 21, The message validation in the intent route only checks for type but not for empty strings, whereas the chat route validates for empty strings using message.length === 0. Add an additional validation check after the typeof validation for the message variable to reject empty strings and return a 400 response with an appropriate error message, ensuring consistency with the chat route's validation behavior.governance_artifacts/pilot/run_pilot_acceptance_gates.py (1)
107-118: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winUnused variable in tuple unpacking.
Line 109 unpacks
rcfrom the_run()return value but never uses it. The return code is ignored in favor of checking the output text for"No error has been found".Consider using
_to indicate the value is intentionally ignored.♻️ Proposed fix
def check_containment_tlc() -> tuple[bool, str]: jar = GA / "tla" / "tools" / "tla2tools.jar" - rc, out = _run( + _, out = _run( ["java", "-cp", str(jar), "tlc2.TLC", "-config", str(GA / "tla" / "SentinelContainmentProtocol.cfg"), str(GA / "tla" / "SentinelContainmentProtocol.tla")], timeout=300, )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@governance_artifacts/pilot/run_pilot_acceptance_gates.py` around lines 107 - 118, In the check_containment_tlc() function, the return code variable rc is unpacked from the _run() call but never used since the function only checks the output text for error messages. Replace rc with an underscore (_) in the tuple unpacking statement to indicate the value is intentionally ignored and follows Python convention for unused variables.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@governance_artifacts/pilot/run_pilot_acceptance_gates.py`:
- Line 28: The os module is imported at the top of the
run_pilot_acceptance_gates.py file but is never used anywhere in the script.
Remove the import os statement to clean up unused imports and improve code
clarity.
In `@governance_blueprint/roadmap_2026_2035.yaml`:
- Around line 70-117: The validator function `validate_roadmap_2035_shape()` in
governance_blueprint/validation/validate_artifacts.py accumulates validation
errors throughout its execution but fails to return them, instead returning None
implicitly. Add a `return errors` statement at the end of the function after
line 299 to ensure that accumulated validation errors are properly propagated to
the caller and validation failures are correctly reported instead of silently
passing.
---
Nitpick comments:
In `@governance_artifacts/pilot/run_pilot_acceptance_gates.py`:
- Around line 107-118: In the check_containment_tlc() function, the return code
variable rc is unpacked from the _run() call but never used since the function
only checks the output text for error messages. Replace rc with an underscore
(_) in the tuple unpacking statement to indicate the value is intentionally
ignored and follows Python convention for unused variables.
In `@next-app/app/api/consent/route.ts`:
- Line 36: The ts property assignment in the consent route includes a redundant
type cast `as unknown as string` after calling `new Date().toISOString()`. Since
the toISOString() method already returns a string type, the explicit cast is
unnecessary and should be removed. Simply replace the line to use `ts: new
Date().toISOString()` without any type annotations.
In `@next-app/app/api/intent/route.ts`:
- Around line 18-21: The message validation in the intent route only checks for
type but not for empty strings, whereas the chat route validates for empty
strings using message.length === 0. Add an additional validation check after the
typeof validation for the message variable to reject empty strings and return a
400 response with an appropriate error message, ensuring consistency with the
chat route's validation behavior.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 59df18ae-d3a2-4487-bca9-8b1e3502da69
📒 Files selected for processing (11)
governance_artifacts/pilot/README.mdgovernance_artifacts/pilot/run_pilot_acceptance_gates.pygovernance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.mdgovernance_blueprint/roadmap_2026_2035.yamlnext-app/DASHBOARD_SECURITY_REVIEW.mdnext-app/__tests__/dashboard_security_review.test.tsnext-app/app/api/chat/stream/route.tsnext-app/app/api/consent/route.tsnext-app/app/api/intent/route.tsnext-app/lib/auth/session.tsnext-app/lib/http/guard.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md
github-project-automation
Bot
moved this to Todo
in Radiant Cosmic Brilliance (He^AI project)
Owner
Author
Round 3 update — OSCAL catalog conformance (12th assurance check)Commit New artifact —
Result on the repo catalogs: 43 passed, 0 failed across 2 catalogs. Closing the dangling-reference gap honestly: both catalogs now carry Wired in:
Verification (all green before push):
Integrity note: Tier A — this verifies in-repo cross-reference integrity only. It does not assert the named regimes are satisfied in production; it asserts the catalog's claims are internally consistent and anchored to real, runnable artifacts. |
Not up to standards ⛔🔴 Issues
|
| Category | Results |
|---|---|
| UnusedCode | 3 medium |
| BestPractice | 18 minor |
| Documentation | 37 minor |
| ErrorProne | 10 high |
| Security | 4 high |
| CodeStyle | 7 minor |
| Complexity | 5 minor 2 critical 11 medium |
| Performance | 3 medium |
🟢 Metrics 330 complexity · 10 duplication
Metric Results Complexity 330 Duplication 10
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
View changes in DiffLens |
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (2)
governance_artifacts/run_runnable_assurance.sh (1)
129-134: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueStep 12 only checks exit status, not the expected output line.
Unlike Steps 5–7 which add
&& grep -q "..."as a content guard, Step 12 passes on a zero exit alone, then greps the message only for display. Since the validator returns non-zero on failure this is functionally safe, but for parity with the other content-asserting steps consider guarding on theOSCAL conformance:line too.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@governance_artifacts/run_runnable_assurance.sh` around lines 129 - 134, Step 12 in run_runnable_assurance.sh only verifies the Python command’s exit status and then uses grep just for reporting, unlike the earlier validation steps that also assert on the expected message. Update the OSCAL conformance check around the oscal_conformance.py invocation so it also guards on the presence of the “OSCAL conformance:” output line before calling pass, matching the pattern used in Steps 5–7 and keeping the check consistent with the rest of the script.governance_artifacts/oscal/oscal_conformance.py (1)
96-101: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low value
_iso_duration_okaccepts empty/degenerate durations.
_ISO_DURmakes every component optional, so"PT"(and"P"inside a"P.../P..."pair, e.g."P/P90D") match. The explicitvalue == "P"guard only covers the whole, unsplit value, so degenerate parts in a periodic/retest pair slip through C3.♻️ Reject degenerate parts per-segment
def _iso_duration_ok(value: str) -> bool: - if value == "P": - return False - # Allow a "periodic/retest" pair like P1D/P90D. - parts = value.split("/") - return all(bool(_ISO_DUR.match(p)) for p in parts) and all(parts) + # Allow a "periodic/retest" pair like P1D/P90D; reject empty/degenerate parts. + parts = value.split("/") + return bool(parts) and all( + p not in ("", "P", "PT") and bool(_ISO_DUR.match(p)) for p in parts + )🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@governance_artifacts/oscal/oscal_conformance.py` around lines 96 - 101, The _iso_duration_ok helper currently lets degenerate ISO duration segments like PT or P inside a periodic/retest pair pass because it only special-cases the whole value and then checks the split parts with _ISO_DUR. Update _iso_duration_ok so each segment in the split value is validated as a non-empty, non-degenerate duration, not just matched against _ISO_DUR; use the existing _ISO_DUR and the _iso_duration_ok function to reject empty or bare-P/bare-PT parts in both single and paired forms.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@governance_artifacts/oscal/oscal_conformance.py`:
- Around line 96-101: The _iso_duration_ok helper currently lets degenerate ISO
duration segments like PT or P inside a periodic/retest pair pass because it
only special-cases the whole value and then checks the split parts with
_ISO_DUR. Update _iso_duration_ok so each segment in the split value is
validated as a non-empty, non-degenerate duration, not just matched against
_ISO_DUR; use the existing _ISO_DUR and the _iso_duration_ok function to reject
empty or bare-P/bare-PT parts in both single and paired forms.
In `@governance_artifacts/run_runnable_assurance.sh`:
- Around line 129-134: Step 12 in run_runnable_assurance.sh only verifies the
Python command’s exit status and then uses grep just for reporting, unlike the
earlier validation steps that also assert on the expected message. Update the
OSCAL conformance check around the oscal_conformance.py invocation so it also
guards on the presence of the “OSCAL conformance:” output line before calling
pass, matching the pattern used in Steps 5–7 and keeping the check consistent
with the rest of the script.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 99806dcb-3321-48b5-b5e5-26038d9914a6
📒 Files selected for processing (10)
.github/workflows/runnable-assurance.ymlgovernance_artifacts/RUNNABLE_ASSURANCE.mdgovernance_artifacts/oscal/catalog_sentinel_v24_env_rte.jsongovernance_artifacts/oscal/catalog_sentinel_v24_excerpt.jsongovernance_artifacts/oscal/oscal_conformance.pygovernance_artifacts/pilot/README.mdgovernance_artifacts/pilot/run_pilot_acceptance_gates.pygovernance_artifacts/run_runnable_assurance.shgovernance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.mdtests/governance/test_governance_artifacts.py
✅ Files skipped from review due to trivial changes (4)
- governance_artifacts/oscal/catalog_sentinel_v24_excerpt.json
- governance_artifacts/RUNNABLE_ASSURANCE.md
- governance_artifacts/pilot/README.md
- governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md
🚧 Files skipped from review as they are similar to previous changes (2)
- .github/workflows/runnable-assurance.yml
- governance_artifacts/pilot/run_pilot_acceptance_gates.py
…check)
Turns the now-verified OSCAL catalogs + live assurance evidence into an
auto-assembled EU AI Act Annex IV technical-documentation dossier — the
regulator deliverable the compliance-as-code stack was built to produce.
New artifacts:
- governance_artifacts/oscal/annex_iv_section_map.yaml: auditable bridge mapping
each Annex IV section (A-H) to the OSCAL control ids that evidence it, plus a
provider narrative. Control ids must exist in a catalog (no dangling refs).
- governance_artifacts/oscal/generate_annex_iv_dossier.py: assembles an
OSCAL-flavoured JSON dossier + human-readable Markdown. For each section it
resolves controls, pulls statement/tier/SLA/regime-citation/evidence-query,
and attaches LIVE evidence by running each control's backing assurance check
(TLA+ TLC, PQC WORM pytest, zk proof, routing simulator). Honesty model:
* SATISFIED only when a mapped control's runnable check passed in this run;
* PARTIAL when runnable-backed but not green this run;
* PENDING-EVIDENCE for organisational/hardware-dependent evidence (e.g.
env-02 enclave key custody, reported truthfully as n/a organisational).
Refuses to assemble on a non-conformant catalog or an unknown control id.
Embeds an integrity statement: assembly-integrity artifact, NOT a conformity
assessment; does not assert the institution is compliant.
Result on repo: 8/8 sections SATISFIED, catalog conformance 0 failures.
- governance_artifacts/oscal/generated/annex_iv_dossier.{json,md}: sample output.
- governance_artifacts/oscal/README.md: documents the OSCAL tooling + honesty model.
Wired in:
- run_runnable_assurance.sh: renumbered to 13 steps; step 13 verifies the dossier
assembles end-to-end (8 sections A-H, 0 conformance failures). Suite 13/13 PASS.
- tests/governance/test_governance_artifacts.py: +3 tests — all section-map
controls resolve; live-evidence assembly (SATISFIED implies a green check;
integrity statement disclaims conformity); --no-verify never fabricates
SATISFIED. Governance pytest 15/15.
- CI: unit-test job runs '-k "oscal or annex"'; new steps assemble the dossier
with live evidence and upload it as a build artifact (annex-iv-dossier).
- Docs synced to 13/13: RUNNABLE_ASSURANCE.md (new row 13 + count), DECADAL plan
(ledger + counts), pilot P6-REPRO + README.
Tier A (assembly integrity). Regression: assurance 13/13 PASS; pilot 6/6
automated; governance pytest 15/15.
Owner
Author
Round 4 update — OSCAL-native Annex IV dossier generator (13th assurance check)Commit New artifacts
Honesty model (no overclaiming)
The generator refuses to assemble on a non-conformant catalog or an unknown control id, and embeds an integrity statement: assembly-integrity artifact, NOT a conformity assessment; does not assert the institution is compliant. Result on the repo: 8/8 sections SATISFIED, catalog conformance 0 failures. Wired in
Verification (green before push)
Integrity note: Tier A — assembly integrity. Proves the dossier is built only from real controls and currently-passing checks; it is not a conformity assessment. |
|
View changes in DiffLens |
1 similar comment
|
View changes in DiffLens |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/runnable-assurance.yml:
- Line 106: The workflow step using actions/upload-artifact is pinned to a
mutable tag, so update the runnable-assurance workflow to reference
actions/upload-artifact by an immutable commit SHA instead of v4. Locate the
upload step in the workflow and replace the current uses value with the specific
SHA for the same major version so the action reference cannot change
unexpectedly.
In `@governance_artifacts/oscal/generate_annex_iv_dossier.py`:
- Around line 179-185: The build_dossier flow currently loads catalog bodies via
_load_catalogs before checking OSCAL validity, so a malformed catalog can fail
early instead of using the validator report path. Update build_dossier to call
_run_conformance before _load_catalogs, then only hydrate catalogs/controls
after conformance passes; keep the existing control-loading logic and use the
build_dossier and _run_conformance symbols to locate the change.
In `@governance_artifacts/run_runnable_assurance.sh`:
- Around line 137-149: Step 13 is only checking dossier shape because
run_runnable_assurance.sh invokes generate_annex_iv_dossier.py with --no-verify,
so build_dossier() never exercises backing checks or live SATISFIED evidence.
Update this step to run the generator through the verified path and assert the
evidence/status fields from the resulting dossier, or if that is not intended,
adjust the step’s assertion/message and related RUNNABLE_ASSURANCE wording to
claim only assembly structure. Use the generate_annex_iv_dossier.py invocation
and the d["dossier"] assertions as the place to align the test with the
documented live-evidence behavior.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 25d4b8f6-e081-4205-89b2-185c781b3312
⛔ Files ignored due to path filters (2)
governance_artifacts/oscal/generated/annex_iv_dossier.jsonis excluded by!**/generated/**governance_artifacts/oscal/generated/annex_iv_dossier.mdis excluded by!**/generated/**
📒 Files selected for processing (10)
.github/workflows/runnable-assurance.ymlgovernance_artifacts/RUNNABLE_ASSURANCE.mdgovernance_artifacts/oscal/README.mdgovernance_artifacts/oscal/annex_iv_section_map.yamlgovernance_artifacts/oscal/generate_annex_iv_dossier.pygovernance_artifacts/pilot/README.mdgovernance_artifacts/pilot/run_pilot_acceptance_gates.pygovernance_artifacts/run_runnable_assurance.shgovernance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.mdtests/governance/test_governance_artifacts.py
✅ Files skipped from review due to trivial changes (4)
- governance_artifacts/pilot/README.md
- governance_artifacts/oscal/annex_iv_section_map.yaml
- governance_artifacts/RUNNABLE_ASSURANCE.md
- governance_artifacts/oscal/README.md
🚧 Files skipped from review as they are similar to previous changes (1)
- governance_artifacts/pilot/run_pilot_acceptance_gates.py
…egister + NIST AI RMF crosswalk (14th & 15th assurance checks)
One verified OSCAL 1.1.2 catalog (source of truth) -> multiple regulator
deliverables. Extends the round-4 Annex IV dossier generator to two more
frameworks, all assembled from the same conformance-verified catalog + live
re-run evidence.
New shared engine:
- crosswalk_common.py: load_catalogs, CONTROL_EVIDENCE, run_conformance
(refuses to assemble against a non-conformant catalog), EvidenceRunner
(re-runs each control's backing assurance check this run), status_for
(SATISFIED / PARTIAL / PENDING-EVIDENCE), resolve_controls.
New deliverables (Tier A, runnable):
- generate_dora_ict_register.py + dora_framework_map.yaml: DORA
(Reg. (EU) 2022/2554) 5-pillar ICT-risk register. Result 3/5 pillars
SATISFIED; P4 (third-party) and P5 (info-sharing) reported as HONEST
coverage gaps (is_coverage_gap=true, PENDING-EVIDENCE), not hidden.
- generate_nist_rmf_crosswalk.py + nist_ai_rmf_map.yaml: NIST AI RMF 1.0
4-function (GOVERN/MAP/MEASURE/MANAGE) crosswalk with per-function
coverage analysis. Result 4/4 functions SATISFIED (100%).
- generated/{dora_ict_register,nist_ai_rmf_crosswalk}.{json,md} samples.
Honesty guarantees (preserved): each generator embeds an integrity_statement
('not a DORA conformity attestation' / 'not a certification'); both refuse a
non-conformant catalog and raise on unknown control ids (falsifiable —
negative tests confirm exit 1).
Wiring:
- run_runnable_assurance.sh: 13 -> 15 steps (14=DORA, 15=NIST), using
--no-verify --print piped to inline python validators.
- tests/governance: +3 tests (18 total): DORA gaps reported, NIST full
coverage with live evidence, and --no-verify does not fabricate SATISFIED.
- CI: pytest selector adds dora/nist/crosswalk; assembles all 3 deliverables
and uploads them as the 'regulator-deliverables' artifact.
Docs synced: RUNNABLE_ASSURANCE.md (rows 14-15, thirteen->fifteen), DECADAL
plan (13/13 -> 15/15 + 2 verification-ledger rows), pilot P6-REPRO 15/15,
oscal/README.md.
Verification (this commit):
- bash governance_artifacts/run_runnable_assurance.sh -> 15/15 PASS
- pytest tests/governance/test_governance_artifacts.py -> 18 passed
- pilot acceptance gates -> 6/6 automated PASS (P6-REPRO 15/15)
- DORA 3/5 SATISFIED (P4/P5 gaps); NIST 4/4 SATISFIED (100%);
catalog conformance 0 failures for both.
|
View changes in DiffLens |
Owner
Author
Round 5 — Multi-framework regulator deliverables (DORA + NIST AI RMF)Theme: one verified OSCAL 1.1.2 catalog (single source of truth) → multiple regulator deliverables. This extends the round-4 EU AI Act Annex IV dossier generator to two additional frameworks, all auto-assembled from the same conformance-verified catalog + live re-run evidence. What shipped (Tier A — runnable, verified this commit)
Honesty guarantees (preserved)
Wiring
Verification (this commit
|
| Check | Command | Result |
|---|---|---|
| Full assurance suite | bash governance_artifacts/run_runnable_assurance.sh |
15/15 PASS |
| Governance tests | pytest tests/governance/test_governance_artifacts.py |
18 passed |
| Pilot acceptance gates | python3 governance_artifacts/pilot/run_pilot_acceptance_gates.py |
6/6 automated PASS (P6-REPRO 15/15) |
| DORA register | generate_dora_ict_register.py |
3/5 pillars SATISFIED; P4/P5 gaps; 0 conformance failures |
| NIST crosswalk | generate_nist_rmf_crosswalk.py |
4/4 functions SATISFIED (100%); 0 conformance failures |
Honesty note: these are assembly-integrity artifacts, not conformity assessments / certifications. ASI "containment" remains a control discipline, not a safety proof.
…ckage & distribute the stack (16th assurance check) Adds the 'finalize, package, and distribute' step the stack has been building toward: instead of asserting regulator-readiness in prose, this PRODUCES an auditable, tamper-evident distribution bundle whose contents are exactly the artifacts that passed THIS run. New tool — governance_artifacts/package_distribution_bundle.py: - Re-runs the 3 OSCAL-native regulator-deliverable generators with LIVE evidence (Annex IV dossier, DORA ICT-risk register, NIST AI RMF crosswalk). - Collects all 6 deliverable artifacts (JSON+MD) into governance_artifacts/dist/. - Emits MANIFEST.json: per-artifact SHA-256 + byte size, the live SATISFIED/PARTIAL/PENDING-EVIDENCE status per unit, declared coverage gaps, and a single bundle_sha256 = SHA-256 over the sorted per-artifact digests (whole-bundle tamper evidence). - Writes a regulator-facing DISTRIBUTION_README.md + a guided EXECUTION_CHECKLIST.md (command-by-command independent reproduction). - --with-suite runs the full runnable-assurance suite and gates on it. Honesty guarantees (falsifiable): - REFUSES to package (exit 1) if any deliverable reports a catalog-conformance failure — verified by a negative test (monkeypatched conformance failure). - bundle_sha256 recomputes from the per-artifact digests (verified in suite + test). - Coverage gaps (DORA P4/P5) are reported, never inflated to SATISFIED. - Explicitly an assembly-integrity + reproducibility bundle, NOT a conformity assessment, certification, or safety proof; ASI containment is a control discipline, not a guarantee. Result this run: 6 artifacts across 3 deliverables; 15/17 units SATISFIED; 2 declared gaps (DORA P4/P5); all catalogs conformant. Wiring: - run_runnable_assurance.sh: 15 -> 16 steps (step 16 packages the bundle, --no-regenerate --print, asserts 3 deliverables / 6 artifacts / digest recomputes / all conformant). - tests/governance: +3 tests -> 21 total (manifest tamper-evidence, DORA gaps not hidden, refuses non-conformant deliverable). - CI: pytest selector adds 'bundle'; packages bundle with --with-suite and uploads it as the 'distribution-bundle' artifact (dist/ stays gitignored — fully reproducible output). Docs synced: RUNNABLE_ASSURANCE.md (row 16, fifteen->sixteen), DECADAL plan (15/15 -> 16/16 + verification-ledger row), pilot P6-REPRO 16/16, governance_artifacts/README.md (package & distribute section), oscal/README.md. Verification (this commit): - bash governance_artifacts/run_runnable_assurance.sh -> 16/16 PASS - pytest tests/governance/test_governance_artifacts.py -> 21 passed - pilot acceptance gates -> 6/6 automated PASS (P6-REPRO 16/16)
Owner
Author
Round 6 — Verified distribution-bundle packager (finalize, package & distribute)This round closes the one gap your "finalize, package, and distribute" ask highlighted that was thinner than everything else: the stack had many deliverable generators but no single command that assembles the complete, verified, regulator-facing distribution bundle. Now it does — and the bundle's contents are exactly the artifacts that passed this run, each pinned by SHA-256. What shipped (Tier A — runnable, verified this commit
|
| Check | Command | Result |
|---|---|---|
| Full assurance suite | bash governance_artifacts/run_runnable_assurance.sh |
16/16 PASS |
| Governance tests | pytest tests/governance/test_governance_artifacts.py |
21 passed |
| Pilot acceptance gates | python3 governance_artifacts/pilot/run_pilot_acceptance_gates.py |
6/6 automated PASS (P6-REPRO 16/16) |
| Distribution bundle | python3 governance_artifacts/package_distribution_bundle.py --with-suite |
6 artifacts, digest recomputes, all conformant, assurance PASS |
A note on scope
Most of the very broad roadmap in the request (zero-trust architecture, confidential-computing attestation, StaR-MoE routing, PQC WORM, zk systemic-risk proofs, TLA+ containment, OSCAL/OPA compliance-as-code, Terraform multi-region, G-SRI, 2028 pilot, 24h monitoring, etc.) already exists as runnable, verified artifacts in this repo from earlier rounds. Rather than re-describe them in prose, this round added the missing packaging/distribution capstone that ties those verified artifacts into one auditable deliverable a G-SIFI could hand to a supervisor.
|
View changes in DiffLens |
…le (content_digest) Closes a real honesty gap in the round-6 packager: the EXECUTION_CHECKLIST claimed the bundle digest "matches the value above (timestamps aside)", but bundle_sha256 in fact changed on EVERY regeneration because each deliverable embeds a fresh generated_at timestamp. A supervisor following the checklist would get a different digest each run, undermining the reproducibility claim. Root cause (verified): the ONLY non-deterministic content in a deliverable is the ISO-8601 generated_at instant (JSON "generated_at" + Markdown **Generated:**). All live evidence and everything else is byte-stable. Fix - two distinct digests, each with a clear purpose: - bundle_sha256 (provenance / tamper-evidence): SHA-256 over the sorted per-artifact BYTE digests. Pins THIS exact build; changes each run. Use to detect tampering with a specific distributed bundle. - content_digest (reproducibility): SHA-256 over the sorted per-artifact digests with embedded ISO-8601 instants normalized to a fixed sentinel. Depends only on the catalog + live-evidence state, so an independent party who re-runs the generators derives the SAME value. VERIFIED stable across 3+ regenerations (f6fa38c7...) while bundle_sha256 varies. Each artifact entry now carries both sha256 and content_sha256. Honesty wording corrected: - DISTRIBUTION_README.md: new 'Two digests, two purposes' section. - EXECUTION_CHECKLIST.md: step 4 now says compare the CONTENT digest (stable), not bundle_sha256; step 5 adds a runnable standalone command to recompute an artifact's content_sha256 (verified to match the manifest). Wiring: - run_runnable_assurance.sh step 16: now asserts BOTH digests recompute and that they are distinct. - tests/governance: +2 tests -> 23 total: content_digest reproducible across regenerations + recomputes; timestamp normalization changes byte digest only (falsifiable - a real content change still moves the normalized digest). - RUNNABLE_ASSURANCE.md row 16, governance_artifacts/README.md, DECADAL ledger row updated to document the two-digest model. Verification (this commit): - bash governance_artifacts/run_runnable_assurance.sh -> 16/16 PASS - pytest tests/governance/test_governance_artifacts.py -> 23 passed - pilot acceptance gates -> 6/6 automated PASS - content_digest stable across 3 regenerations; bundle_sha256 varies as intended
Owner
Author
Round 7 — Deterministically reproducible distribution bundle (honesty fix)This round fixes a real honesty gap I found in the round-6 packager rather than adding new surface. It follows the project's core rule: when a claim isn't actually true, fix it transparently, don't paper over it. The gapThe round-6 I verified this directly: three regenerations produced three different Root cause (verified)The only non-deterministic content in a deliverable is the ISO-8601 The fix — two digests, two clearly-separated purposes
Verified: Honesty wording corrected
Wiring
Verification (this commit
|
| Check | Command | Result |
|---|---|---|
| Full assurance suite | bash governance_artifacts/run_runnable_assurance.sh |
16/16 PASS |
| Governance tests | pytest tests/governance/test_governance_artifacts.py |
23 passed |
| Pilot acceptance gates | python3 governance_artifacts/pilot/run_pilot_acceptance_gates.py |
6/6 automated PASS |
| Reproducibility | packager run 3×, compare digests | content_digest stable; bundle_sha256 varies (as designed) |
No step count change (still 16 checks) — this round hardens the existing capstone into an actually reproducible deliverable.
|
View changes in DiffLens |
Not up to standards ⛔🔴 Issues
|
| Category | Results |
|---|---|
| Compatibility | 2 medium |
| BestPractice | 4 medium 1 high |
| Documentation | 2 minor |
| Security | 6 critical 2 high |
| CodeStyle | 40 minor |
| Complexity | 20 minor 6 critical 15 medium |
| Comprehensibility | 2 minor |
🟢 Metrics 399 complexity · 10 duplication
Metric Results Complexity 399 Duplication 10
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
View changes in DiffLens |
Update: 17th assurance check — recipient-side bundle verification + ML-DSA-65 manifest signing (
|
…manifest signing (17th assurance check) Closes the trust gap left by the round-6/7 packager: a bundle recipient previously had to trust the packager's own digest arithmetic. This adds the missing recipient-side half of the distribution story. New tool — governance_artifacts/verify_distribution_bundle.py: - Standalone and deliberately INDEPENDENT: stdlib-only (optional dilithium-py only for the signature branch) and never imports the packager — the digest rules (byte SHA-256, timestamp-normalized content SHA-256, sorted-digest bundle digests) are re-implemented from scratch so a bug or backdoor in the packager cannot vouch for itself (enforced by an AST-based test). - 10 named, falsifiable checks: manifest-parse, artifact-presence, artifact-byte-digest, artifact-content-digest, bundle-digest-recompute, content-digest-recompute, digests-distinct, summary-consistency, conformance-claims, signature. - summary-consistency recomputes the manifest's claimed unit counts / coverage gaps / conformance from the bundled deliverable JSONs themselves — a manifest that inflates units_satisfied or hides a DORA P4/P5 gap FAILS even if every digest still recomputes. - Exit 0 iff every executed check passes; missing dilithium-py reports the signature check SKIPPED (never silently passed); --require-signature turns absence/skip into FAIL. Packager — package_distribution_bundle.py --sign / --signing-key: - Emits a detached ML-DSA-65 (FIPS 204) MANIFEST.sig.json over the EXACT MANIFEST.json bytes, embedding the public key + its SHA-256 fingerprint. - Honest key semantics: --signing-key FILE persists one signing identity (0600) so fingerprints are stable across bundles; without it the key is EPHEMERAL and the signature file says so (key_persistence) — it then proves integrity-since-packaging, not identity. Identity always requires an out-of-band fingerprint comparison (stated in the artifact). Wiring: - run_runnable_assurance.sh: 16 -> 17 steps. Step 17 packages a signed bundle and verifies it with the independent verifier in strict --require-signature mode, asserting all 10 checks PASS. - Generated DISTRIBUTION_README.md + EXECUTION_CHECKLIST.md now include a 'verify as received' section / step 6 for the recipient. - RUNNABLE_ASSURANCE.md: row 17 documented. - Refreshed generated OSCAL deliverables from the final suite run. Tamper negatives (all verified by tests, 30/30 governance tests pass): - Artifact byte edit -> artifact-byte-digest + artifact-content-digest FAIL. - Forged manifest claims (inflated SATISFIED, hidden gaps) -> summary-consistency FAILs (and the signature breaks). - Single-byte whitespace change to MANIFEST.json with digests intact -> ONLY the ML-DSA-65 signature check fails (precise localization). - --require-signature on an unsigned bundle -> FAILED with explicit error. - Persistent-key double-signing -> identical public-key fingerprints; both bundles VERIFIED in strict mode. Full suite result: 17/17 runnable assurance checks PASS.
OneFineStarstuff
force-pushed
the
genspark_ai_developer
branch
from
f20c808 to
db06d3f
Compare
|
View changes in DiffLens |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the authoritative consolidated decadal (2026–2035) strategic & technical plan for deploying the Sentinel AI Governance Stack v2.4, Omni-Sentinel Mesh v4.0, and Unified AI Supervisory Control Plane (SCP v3.0) across G-SIFIs and Fortune 500 financial institutions.
governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md(424 lines, 20 sections).Builds on merged PR #138. Every technical claim is anchored to a runnable, verified in-repo artifact — the assurance suite is 11/11 PASS at issue.
Coverage (all requested topics)
omni_sentinel_24h_monitor.py24h monitoring + integrity; OmegaActual dead-man's switch; DevSecOps/GitOps (ArgoCD/Flux)Integrity discipline
A/B/C/D feasibility tiering throughout. Explicit statement that ASI containment is modelled as a formally-checked control discipline, not a safety proof for arbitrarily capable agents (Tier D). Live attestation/HSM/enclave verified at IaC/policy layer (Tier B). All cross-referenced files confirmed present; roadmap YAML parses (5 phases + 4 extension).
Verification
Summary by CodeRabbit
Documentation
New Features
/api/*rate limiting.Bug Fixes
Tests / CI