docs(governance): propose a quality harness (layered gates + full-suite-before-seal)#794
docs(governance): propose a quality harness (layered gates + full-suite-before-seal)#794jordyamoedo wants to merge 2 commits into
Conversation
|
@jordyamoedo is attempting to deploy a commit to the SINKRA - AIOX Team on Vercel. A member of the Team first needs to authorize it. |
|
Welcome to aiox-core! Thanks for your first pull request. What happens next?
PR Checklist:
Thanks for contributing! |
WalkthroughTwo new YAML documents are added: a promoted audit finding ( ChangesQuality Harness Audit Finding and Governance Proposal
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@audits/promoted/AF-20260614-quality-harness.yaml`:
- Line 4: The date field in both governance documents violates ISO 8601 format
requirements by omitting time and timezone components. In
audits/promoted/AF-20260614-quality-harness.yaml at line 4 and
governance/proposals/PROP-20260614-quality-harness.yaml at line 4, update the
date value from the format YYYY-MM-DD (2026-06-14) to the full ISO 8601 format
with UTC timezone (2026-06-14T00:00:00Z) to ensure consistent date parsing
across all tooling.
- Around line 30-32: The kind field in the references section uses an invalid
value "pattern" that is not in the documented list of allowed reference kinds.
Change the kind value from "pattern" to "existing-pattern-source", which is a
valid kind that matches the intent of referencing a quality harness pattern.
This will bring the YAML configuration into compliance with the documented
template requirements for the kind field.
🪄 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: CHILL
Plan: Pro
Run ID: fb133895-b061-4a2a-aca1-976c279f8719
📒 Files selected for processing (2)
audits/promoted/AF-20260614-quality-harness.yamlgovernance/proposals/PROP-20260614-quality-harness.yaml
| audit_finding: | ||
| version: "1.0" | ||
| id: "AF-20260614-quality-harness" | ||
| date: "2026-06-14" |
There was a problem hiding this comment.
ISO 8601 date format violation in both governance documents. Both the audit finding and the proposal use 2026-06-14 without time and timezone components. The governance templates require full ISO 8601 format (e.g., 2026-05-07T18:30:00Z) to ensure reliable date parsing across tooling.
audits/promoted/AF-20260614-quality-harness.yaml#L4: Change to2026-06-14T00:00:00Zgovernance/proposals/PROP-20260614-quality-harness.yaml#L4: Change to2026-06-14T00:00:00Z
📍 Affects 2 files
audits/promoted/AF-20260614-quality-harness.yaml#L4-L4(this comment)governance/proposals/PROP-20260614-quality-harness.yaml#L4-L4
🤖 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 `@audits/promoted/AF-20260614-quality-harness.yaml` at line 4, The date field
in both governance documents violates ISO 8601 format requirements by omitting
time and timezone components. In
audits/promoted/AF-20260614-quality-harness.yaml at line 4 and
governance/proposals/PROP-20260614-quality-harness.yaml at line 4, update the
date value from the format YYYY-MM-DD (2026-06-14) to the full ISO 8601 format
with UTC timezone (2026-06-14T00:00:00Z) to ensure consistent date parsing
across all tooling.
| references: | ||
| - kind: pattern | ||
| path: "Quality harness: layered gates with an owning agent and a fail-mode" |
There was a problem hiding this comment.
Use a documented reference kind.
The kind field uses "pattern", which is not in the allowed list documented in the template: ADR | code | hook | governance-doc | existing-pattern-source | voice-clone-finding | voice-clone-personas | handoff-contract | audit | proposal.
Consider using existing-pattern-source instead, which appears to match the intent of referencing a quality harness pattern.
🔧 Proposed fix
references:
- - kind: pattern
+ - kind: existing-pattern-source
path: "Quality harness: layered gates with an owning agent and a fail-mode"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| references: | |
| - kind: pattern | |
| path: "Quality harness: layered gates with an owning agent and a fail-mode" | |
| references: | |
| - kind: existing-pattern-source | |
| path: "Quality harness: layered gates with an owning agent and a fail-mode" |
🤖 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 `@audits/promoted/AF-20260614-quality-harness.yaml` around lines 30 - 32, The
kind field in the references section uses an invalid value "pattern" that is not
in the documented list of allowed reference kinds. Change the kind value from
"pattern" to "existing-pattern-source", which is a valid kind that matches the
intent of referencing a quality harness pattern. This will bring the YAML
configuration into compliance with the documented template requirements for the
kind field.
Summary
This proposes a quality harness — submitted through the project's own
governance/evolution-pipeline.mdas anAuditFinding+FrameworkProposal(bothPENDINGyour approval). Two governance YAML files; no code paths touched.The gap
"Quality First" is Article V of the constitution — but it's declarative. There's no harness that ties gates to moments and owners, nothing forces the full test suite before a seal, and a seal can pass on a subset test run that hides a regression in an untouched module.
The proposal
A small set of additive, advisory-by-default rules built on three invariants:
Plus full-suite-before-seal: run the whole suite (no path filter) + build + typecheck before marking work shippable — because subset runs hide cross-module regressions (a change shifts lines/exports and breaks a test in a module you never touched).
Why it's good for the project
full-suite-before-sealcatches the cross-module regressions that subset runs silently miss.Submitted in the spirit of the framework's own evolution pipeline. Happy to follow up with the implementation PR once approved — or to adjust scope per your guidance.
Summary by CodeRabbit