chore(tooling): add coverage task to Taskfile.yml and justfile#64
Conversation
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
📝 WalkthroughSummaryThis PR introduces governance automation, local development tooling shortcuts, and workspace documentation. The changes are:
The intent is sound—centralizing coverage measurement and governance documentation. However, there is a critical blocking issue. Must FixYAML Syntax Error in Taskfile.yml (Line 25): The description string contains an unquoted colon in "SSOT:" which causes YAML parsing to fail: desc: Measure code coverage (SSOT: see grade.sh for the canonical command).The colon in Fix: Quote the description string: desc: "Measure code coverage (SSOT: see grade.sh for the canonical command)."This is a critical issue because it breaks the Taskfile.yml and will prevent the task runner from parsing the file. Should FixYAML Formatting in governance.yml: The workflow file has several style violations flagged by yamllint:
Fix: Reformat long lines and add standard YAML headers/spacing. SSOT.md Coverage Domain: The PR establishes SSOT as the canonical reference for governance, but the SSOT.md table does not explicitly list "Code coverage measurement" or point to Consider
RecommendationRequest Changes — The unquoted YAML string in Taskfile.yml is a blocking syntax error that must be fixed before merge. Additionally, please address YAML formatting in governance.yml and complete the SSOT.md documentation to cover code coverage measurement. Once the YAML syntax error is resolved and governance.yml formatting is corrected, this PR will be ready for approval. WalkthroughAdds a ChangesCoverage Task Addition
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 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)
✨ Simplify code
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.
Code Review
This pull request introduces architectural and governance documentation (ARCHITECTURE.md and SSOT.md) alongside new code coverage tasks in Taskfile.yml and justfile. The review feedback points out that creating new markdown files at the root level violates existing repository layout rules, and suggests moving them to the docs/ directory. Additionally, the feedback recommends correcting the heading hierarchy in ARCHITECTURE.md and updating the SSOT.md table to include grade.sh since it is referenced as the authoritative source for coverage commands.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| @@ -0,0 +1,44 @@ | |||
| # Architecture | |||
There was a problem hiding this comment.
According to the quality rules in AGENTS.md (line 45), markdown files should not be created at the root level (except README.md, CLAUDE.md, and AGENTS.md). Since this PR introduces ARCHITECTURE.md at the root level, please consider moving it to the docs/ directory (e.g., docs/reference/architecture.md) or updating the exception list in AGENTS.md if it is intended to remain at the root.
| @@ -0,0 +1,33 @@ | |||
| # SSOT — Single Source of Truth (phenoAI) | |||
There was a problem hiding this comment.
According to the quality rules in AGENTS.md (line 45), markdown files should not be created at the root level (except README.md, CLAUDE.md, and AGENTS.md). Since this PR introduces SSOT.md at the root level, please consider moving it to the docs/ directory (e.g., docs/reference/ssot.md) or updating the exception list in AGENTS.md if it is intended to remain at the root.
| ## Components | ||
| ## crates/* | ||
| - Rust crates implementing the AI agent domain logic, model integrations, and shared utilities. | ||
|
|
||
| ## python/ | ||
| - Python bindings and helper modules that wrap the Rust crates for ecosystem consumers. | ||
|
|
||
| ## ports/ | ||
| - External port surfaces (CLI, MCP, library) that expose the workspace to other Phenotype projects. | ||
|
|
||
| ## docs/ | ||
| - Project documentation: guides, reports, research, reference, checklists (per `AGENTS.md` layout). |
There was a problem hiding this comment.
The subheadings under ## Components (crates/*, python/, ports/, docs/) are currently defined as H2 (##), which puts them at the same hierarchy level as ## Components. They should be H3 (###) to correctly reflect that they are sub-components.
| ## Components | |
| ## crates/* | |
| - Rust crates implementing the AI agent domain logic, model integrations, and shared utilities. | |
| ## python/ | |
| - Python bindings and helper modules that wrap the Rust crates for ecosystem consumers. | |
| ## ports/ | |
| - External port surfaces (CLI, MCP, library) that expose the workspace to other Phenotype projects. | |
| ## docs/ | |
| - Project documentation: guides, reports, research, reference, checklists (per `AGENTS.md` layout). | |
| ## Components | |
| ### crates/* | |
| - Rust crates implementing the AI agent domain logic, model integrations, and shared utilities. | |
| ### python/ | |
| - Python bindings and helper modules that wrap the Rust crates for ecosystem consumers. | |
| ### ports/ | |
| - External port surfaces (CLI, MCP, library) that expose the workspace to other Phenotype projects. | |
| ### docs/ | |
| - Project documentation: guides, reports, research, reference, checklists (per AGENTS.md layout). |
|
|
||
| | Domain | Authoritative source | | ||
| | --- | --- | | ||
| | Build & test commands | `justfile` (root) and per-crate `Cargo.toml` | |
There was a problem hiding this comment.
The comments in Taskfile.yml and justfile refer to grade.sh as the Single Source of Truth (SSOT) for the canonical coverage command. However, grade.sh is not listed in this table. Consider updating the 'Build & test commands' row or adding a new row for 'Project grading & coverage' to include grade.sh as an authoritative source.
| name: Governance | ||
|
|
||
| on: | ||
| push: | ||
| branches: [main, master] | ||
| pull_request: | ||
| branches: [main, master] | ||
| schedule: | ||
| - cron: "0 6 * * 1" |
There was a problem hiding this comment.
Suggestion: Add an explicit AgilePlus spec reference (for example in a top-level comment or job metadata) so this newly introduced governance workflow is traceable to an approved spec before implementation. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
This is newly introduced workflow code and it contains no AgilePlus spec reference in a comment, job metadata, or other traceability field. Under the provided rules, new work must be tied to an existing AgilePlus spec before implementation, so the suggestion identifies a real rule violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** .github/workflows/governance.yml
**Line:** 1:9
**Comment:**
*Custom Rule: Add an explicit AgilePlus spec reference (for example in a top-level comment or job metadata) so this newly introduced governance workflow is traceable to an approved spec before implementation.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| @@ -0,0 +1,44 @@ | |||
| # Architecture | |||
There was a problem hiding this comment.
Suggestion: Move this new Markdown document from the repository root into an allowed docs subdirectory (for example docs/reference/) and keep only permitted root Markdown files. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
This is a new Markdown file added at the repository root, and the rules explicitly forbid new root-level Markdown files unless they are README.md, CLAUDE.md, or AGENTS.md. ARCHITECTURE.md does not fall under the allowed exceptions, so the violation is real.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** ARCHITECTURE.md
**Line:** 1:1
**Comment:**
*Custom Rule: Move this new Markdown document from the repository root into an allowed docs subdirectory (for example `docs/reference/`) and keep only permitted root Markdown files.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| ## Components | ||
| ## crates/* |
There was a problem hiding this comment.
Suggestion: Fix the heading structure by making component entries children of the Components section (for example using a deeper heading level) instead of consecutive same-level headings. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The document uses two consecutive same-level headings where the second item is meant to be a subsection of Components. This is malformed Markdown structure and matches the rule about broken headings / invalid prose structure in documentation changes.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** ARCHITECTURE.md
**Line:** 8:9
**Comment:**
*Custom Rule: Fix the heading structure by making component entries children of the Components section (for example using a deeper heading level) instead of consecutive same-level headings.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| # SSOT — Single Source of Truth (phenoAI) | ||
|
|
||
| This document records the canonical authority for cross-cutting facts in the | ||
| phenoAI repository. When a fact conflicts across docs, the source listed | ||
| here wins. | ||
|
|
||
| ## Scope | ||
|
|
||
| | Domain | Authoritative source | | ||
| | --- | --- | | ||
| | Build & test commands | `justfile` (root) and per-crate `Cargo.toml` | | ||
| | Release & versioning | `cliff.toml` + `CHANGELOG.md` (git-cliff generated) | | ||
| | Security disclosure process | `SECURITY.md` | | ||
| | Dependency updates | `.github/dependabot.yml` | | ||
| | Branch & commit policy | `.github/workflows/governance.yml` | | ||
| | Repository health score | `.github/workflows/scorecard.yml` (OpenSSF) | | ||
| | Editor / formatting baseline | `.editorconfig` | | ||
| | Workspace architecture | `PLAN.md` + per-crate `Cargo.toml` | | ||
| | Agent operating model | `AGENTS.md` | | ||
| | Functional requirements | `FUNCTIONAL_REQUIREMENTS.md` | | ||
|
|
||
| ## Precedence order | ||
|
|
||
| 1. Executable config (workflows, `justfile`, `Cargo.toml`, `deny.toml`, `lefthook.yml`) — observed behavior. | ||
| 2. `*.md` governance files in this SSOT table. | ||
| 3. `PLAN.md` milestone-level contracts. | ||
| 4. Anything else. | ||
|
|
||
| ## Updating this file | ||
|
|
||
| - Keep the table narrow and unambiguous. | ||
| - Cite the canonical file by path; do not duplicate content. | ||
| - Update via a `chore(governance):` commit referencing the change. |
There was a problem hiding this comment.
Suggestion: Move this new Markdown document under an approved docs subdirectory (for example docs/) instead of keeping it at the repository root, or rename it to one of the explicitly allowed root filenames. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
The rule explicitly flags new Markdown files created at the repository root unless they are README.md, CLAUDE.md, or AGENTS.md. This file is a newly added root-level Markdown document named SSOT.md, so it directly violates the rule.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** SSOT.md
**Line:** 1:33
**Comment:**
*Custom Rule: Move this new Markdown document under an approved docs subdirectory (for example `docs/`) instead of keeping it at the repository root, or rename it to one of the explicitly allowed root filenames.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| coverage: | ||
| desc: Measure code coverage (SSOT: see grade.sh for the canonical command). | ||
| cmds: | ||
| - cargo llvm-cov --workspace --fail-under-lines 85 |
There was a problem hiding this comment.
Suggestion: Add an explicit AgilePlus spec reference (for example, a spec ID in the task description or adjacent comment) so this new coverage task is traceable to approved planned work. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
This is newly added task configuration, and it does not include any AgilePlus spec reference or other traceability marker. The repository guidance says new work should be tied to an existing spec before implementation, so the suggestion correctly identifies a real rule violation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** Taskfile.yml
**Line:** 24:27
**Comment:**
*Custom Rule: Add an explicit AgilePlus spec reference (for example, a spec ID in the task description or adjacent comment) so this new `coverage` task is traceable to approved planned work.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix| # Measure code coverage (SSOT: see grade.sh for the canonical command) | ||
| coverage: | ||
| cargo llvm-cov --workspace --fail-under-lines 85 |
There was a problem hiding this comment.
Suggestion: Add an AgilePlus spec identifier/reference to this newly introduced coverage task (for example in the comment above it) so the implementation is explicitly traceable to an approved spec. [custom_rule]
Severity Level: Minor
Why it matters? 🤔
This is a newly introduced feature/task in the justfile, and it does not include any AgilePlus spec identifier or reference. The only comment mentions SSOT/grade.sh, which is not a spec reference. That matches the custom rule requiring new work to be tied to an approved spec before implementation.
Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** justfile
**Line:** 27:29
**Comment:**
*Custom Rule: Add an AgilePlus spec identifier/reference to this newly introduced coverage task (for example in the comment above it) so the implementation is explicitly traceable to an approved spec.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fixThere was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issue.
Reviewed by Cursor Bugbot for commit 39867c3. Configure here.
|
CodeAnt AI finished reviewing your PR. |
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 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/governance.yml:
- Around line 22-23: The workflow file has multiple checkout steps that do not
disable credential persistence, which increases token exposure risk. Add the
parameter persist-credentials: false to the checkout action at lines 22-23 (the
actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 step) and also at
lines 54-57 (the other checkout step in the workflow). This parameter prevents
GitHub from persisting the authentication credentials to the workspace, reducing
the attack surface.
- Line 11: The `permissions: read-all` setting at the top level of the workflow
grants unnecessary read access across all scopes. Replace this overly permissive
setting with specific, minimal permissions required by the jobs in this workflow
(for example, if the job only needs to read repository contents, use
`permissions: contents: read` instead). Review what each job actually needs to
access and define only those specific permissions to follow the principle of
least privilege.
- Line 52: The continue-on-error: true setting at line 52 in the governance
workflow makes the commit linting job non-blocking, allowing the workflow to
succeed even when commit convention violations are detected. To enforce commit
policy governance as intended, remove the continue-on-error: true line or set it
to continue-on-error: false so that commit lint failures will block the workflow
and prevent non-compliant commits.
- Line 73: The default branch lookup command at line 73 in
`.github/workflows/governance.yml` currently silently defaults to "main" when
the gh repo view command fails by using the `|| echo "main"` fallback. This
allows the branch-policy check to continue even on lookup or authentication
failures. Remove the `|| echo "main"` fallback so that if the gh repo view
command fails, the entire script fails immediately rather than continuing with a
potentially incorrect default branch name, implementing a fail-closed approach.
In `@ARCHITECTURE.md`:
- Around line 8-43: The ARCHITECTURE.md file violates markdownlint rules MD022
and MD031 regarding blank lines around headings and fenced code blocks. Add
blank lines before and after all heading elements (## Components, ## crates/*,
## Data flow, ## Key invariants, ## Cross-cutting concerns, ## Future
considerations) and before and after the fenced code block (the triple backtick
section containing the data flow diagram) to ensure proper markdown formatting
compliance with the repository's linting standards.
In `@SSOT.md`:
- Line 1: Move SSOT.md (anchor at SSOT.md#L1-L1) from the repository root to the
docs/ directory following the repository markdown policy that allows only
README.md, CLAUDE.md, and AGENTS.md at root level. Move ARCHITECTURE.md (sibling
at ARCHITECTURE.md#L1-L1) from the repository root to the docs/ directory in the
same manner. After relocating both files, update all references to these files
including paths in Taskfile.yml, any workflow checks that reference these
documents, and all internal documentation links to point to their new locations
under docs/.
In `@Taskfile.yml`:
- Line 25: The desc field value contains an unquoted colon in SSOT: see grade.sh
which causes YAML parsing to fail because the colon is interpreted as a
key-value mapping separator rather than part of the string. Quote the entire
desc value (the complete string from "Measure code coverage" through "canonical
command)") to treat the colon as part of the scalar string literal and resolve
the YAML syntax error.
🪄 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: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7176e137-5870-44f6-bf22-d1278eb38aa9
📒 Files selected for processing (5)
.github/workflows/governance.ymlARCHITECTURE.mdSSOT.mdTaskfile.ymljustfile
📜 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). (1)
- GitHub Check: coverage
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{js,ts,tsx,jsx,py,rs,go,java,c,cpp,h,yml,yaml,json,md}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{js,ts,tsx,jsx,py,rs,go,java,c,cpp,h,yml,yaml,json,md}: All code MUST pass linting and formatting checks before commit
Run linters and formatters locally and fix errors; do not suppress or ignore warnings
Files:
Taskfile.ymlARCHITECTURE.mdSSOT.md
**/*.md
📄 CodeRabbit inference engine (AGENTS.md)
Use Vale for Markdown validation where available
Files:
ARCHITECTURE.mdSSOT.md
*.md
📄 CodeRabbit inference engine (AGENTS.md)
Never create
.mdfiles at root level (exceptREADME.md,CLAUDE.md,AGENTS.md)
Files:
ARCHITECTURE.mdSSOT.md
🪛 LanguageTool
SSOT.md
[uncategorized] ~14-~14: The official name of this software platform is spelled with a capital “H”.
Context: ... SECURITY.md | | Dependency updates | .github/dependabot.yml | | Branch & commit pol...
(GITHUB)
[uncategorized] ~15-~15: The official name of this software platform is spelled with a capital “H”.
Context: ...dabot.yml| | Branch & commit policy |.github/workflows/governance.yml` | | Repositor...
(GITHUB)
[uncategorized] ~16-~16: The official name of this software platform is spelled with a capital “H”.
Context: ...ance.yml| | Repository health score |.github/workflows/scorecard.yml` (OpenSSF) | | ...
(GITHUB)
🪛 markdownlint-cli2 (0.22.1)
ARCHITECTURE.md
[warning] 3-3: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 8-8: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 9-9: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 9-9: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 12-12: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 15-15: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 18-18: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 21-21: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 22-22: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 30-30: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 36-36: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 41-41: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🪛 YAMLlint (1.37.1)
Taskfile.yml
[error] 25-25: syntax error: mapping values are not allowed here
(syntax)
🪛 zizmor (1.25.2)
.github/workflows/governance.yml
[warning] 22-23: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[warning] 54-57: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[warning] 11-11: overly broad permissions (excessive-permissions): uses read-all permissions
(excessive-permissions)
🔇 Additional comments (1)
justfile (1)
27-29: LGTM!
| schedule: | ||
| - cron: "0 6 * * 1" | ||
|
|
||
| permissions: read-all |
There was a problem hiding this comment.
Use least-privilege permissions instead of read-all.
permissions: read-all grants read access to all scopes; tighten to only what each job needs (e.g., contents: read).
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 11-11: overly broad permissions (excessive-permissions): uses read-all permissions
(excessive-permissions)
🤖 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 @.github/workflows/governance.yml at line 11, The `permissions: read-all`
setting at the top level of the workflow grants unnecessary read access across
all scopes. Replace this overly permissive setting with specific, minimal
permissions required by the jobs in this workflow (for example, if the job only
needs to read repository contents, use `permissions: contents: read` instead).
Review what each job actually needs to access and define only those specific
permissions to follow the principle of least privilege.
Source: Linters/SAST tools
| - name: Checkout | ||
| uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v4 |
There was a problem hiding this comment.
Disable credential persistence on checkout steps.
Both checkout steps should set persist-credentials: false to reduce token exposure risk in the workspace.
Proposed fix
- name: Checkout
uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v4
+ with:
+ persist-credentials: false
@@
- name: Checkout (shallow)
uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v4
with:
fetch-depth: 50
+ persist-credentials: falseAlso applies to: 54-57
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 22-23: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🤖 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 @.github/workflows/governance.yml around lines 22 - 23, The workflow file has
multiple checkout steps that do not disable credential persistence, which
increases token exposure risk. Add the parameter persist-credentials: false to
the checkout action at lines 22-23 (the
actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 step) and also at
lines 54-57 (the other checkout step in the workflow). This parameter prevents
GitHub from persisting the authentication credentials to the workspace, reducing
the attack surface.
Source: Linters/SAST tools
| commit-policy: | ||
| name: Conventional commit lint | ||
| runs-on: ubuntu-latest | ||
| continue-on-error: true |
There was a problem hiding this comment.
continue-on-error: true prevents actual commit-policy enforcement.
This makes the “Conventional commit lint” job non-blocking, which conflicts with the stated governance enforcement intent for commit conventions.
🤖 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 @.github/workflows/governance.yml at line 52, The continue-on-error: true
setting at line 52 in the governance workflow makes the commit linting job
non-blocking, allowing the workflow to succeed even when commit convention
violations are detected. To enforce commit policy governance as intended, remove
the continue-on-error: true line or set it to continue-on-error: false so that
commit lint failures will block the workflow and prevent non-compliant commits.
| steps: | ||
| - name: Verify default branch naming | ||
| run: | | ||
| default=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null || echo "main") |
There was a problem hiding this comment.
Fail closed when default-branch lookup fails.
|| echo "main" allows the branch-policy check to pass on lookup/auth failures. Treat lookup failure as an error instead of defaulting to an approved branch name.
Proposed fix
- default=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null || echo "main")
+ default=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null) || {
+ echo "::error::Unable to determine default branch via gh CLI"
+ exit 1
+ }📝 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.
| default=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null || echo "main") | |
| default=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null) || { | |
| echo "::error::Unable to determine default branch via gh CLI" | |
| exit 1 | |
| } |
🤖 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 @.github/workflows/governance.yml at line 73, The default branch lookup
command at line 73 in `.github/workflows/governance.yml` currently silently
defaults to "main" when the gh repo view command fails by using the `|| echo
"main"` fallback. This allows the branch-policy check to continue even on lookup
or authentication failures. Remove the `|| echo "main"` fallback so that if the
gh repo view command fails, the entire script fails immediately rather than
continuing with a potentially incorrect default branch name, implementing a
fail-closed approach.
| ## Components | ||
| ## crates/* | ||
| - Rust crates implementing the AI agent domain logic, model integrations, and shared utilities. | ||
|
|
||
| ## python/ | ||
| - Python bindings and helper modules that wrap the Rust crates for ecosystem consumers. | ||
|
|
||
| ## ports/ | ||
| - External port surfaces (CLI, MCP, library) that expose the workspace to other Phenotype projects. | ||
|
|
||
| ## docs/ | ||
| - Project documentation: guides, reports, research, reference, checklists (per `AGENTS.md` layout). | ||
|
|
||
| ## Data flow | ||
| ```text | ||
| external caller (CLI / MCP / Python) | ||
| -> ports/ entrypoint | ||
| -> crates/* domain logic | ||
| -> python/ bindings (optional) | ||
| -> external model / storage providers | ||
| ``` | ||
|
|
||
| ## Key invariants | ||
| - Treat crate boundaries as explicit contracts; respect `deny.toml` and `lefthook.yml` quality gates. | ||
| - Mirror the Phenotype org scripting policy (Rust default; no new shell scripts). | ||
| - Functional requirements in `FUNCTIONAL_REQUIREMENTS.md` MUST be traceable to at least one test. | ||
| - Cross-project reuse: prefer extraction into existing shared modules (see `AGENTS.md`). | ||
|
|
||
| ## Cross-cutting concerns (config, telemetry, errors) | ||
| - Config: load via Phenotype shared config patterns. | ||
| - Telemetry: propagate structured logs and traces across the workspace. | ||
| - Errors: normalize failure handling so port surfaces can report actionable messages. | ||
|
|
||
| ## Future considerations | ||
| - Replace this skeleton with per-crate ownership and a concrete call-graph diagram. | ||
| - Capture release and integration assumptions as the workspace evolves (see `PLAN.md`). |
There was a problem hiding this comment.
Fix markdownlint violations before merge.
This file currently violates MD022/MD031 (headings and fenced blocks not surrounded by blank lines), so it does not meet the repository’s linting requirement.
As per coding guidelines, "**/*.{js,ts,tsx,jsx,py,rs,go,java,c,cpp,h,yml,yaml,json,md}: All code MUST pass linting and formatting checks before commit" and "**/*.md: Use Vale for Markdown validation where available".
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 8-8: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 9-9: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
[warning] 9-9: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 12-12: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 15-15: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 18-18: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 21-21: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 22-22: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 30-30: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 36-36: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 41-41: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
🤖 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 `@ARCHITECTURE.md` around lines 8 - 43, The ARCHITECTURE.md file violates
markdownlint rules MD022 and MD031 regarding blank lines around headings and
fenced code blocks. Add blank lines before and after all heading elements (##
Components, ## crates/*, ## Data flow, ## Key invariants, ## Cross-cutting
concerns, ## Future considerations) and before and after the fenced code block
(the triple backtick section containing the data flow diagram) to ensure proper
markdown formatting compliance with the repository's linting standards.
Sources: Coding guidelines, Linters/SAST tools
| @@ -0,0 +1,33 @@ | |||
| # SSOT — Single Source of Truth (phenoAI) | |||
There was a problem hiding this comment.
Root-level Markdown policy is violated by adding new governance docs at repository root.
Both files are introduced as root-level .md files, but repository policy allows only README.md, CLAUDE.md, and AGENTS.md at root. Move these docs under an allowed docs path and update references/workflow checks accordingly.
SSOT.md#L1-L1: moveSSOT.mdout of root (e.g., intodocs/) and adjust all references (Taskfile.yml, workflow checks, and any doc links).ARCHITECTURE.md#L1-L1: moveARCHITECTURE.mdout of root and update references consistently.
As per coding guidelines, "*.md: Never create .md files at root level (except README.md, CLAUDE.md, AGENTS.md)".
📍 Affects 2 files
SSOT.md#L1-L1(this comment)ARCHITECTURE.md#L1-L1
🤖 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 `@SSOT.md` at line 1, Move SSOT.md (anchor at SSOT.md#L1-L1) from the
repository root to the docs/ directory following the repository markdown policy
that allows only README.md, CLAUDE.md, and AGENTS.md at root level. Move
ARCHITECTURE.md (sibling at ARCHITECTURE.md#L1-L1) from the repository root to
the docs/ directory in the same manner. After relocating both files, update all
references to these files including paths in Taskfile.yml, any workflow checks
that reference these documents, and all internal documentation links to point to
their new locations under docs/.
Source: Coding guidelines
| cmds: [task lint, task test, task audit] | ||
|
|
||
| coverage: | ||
| desc: Measure code coverage (SSOT: see grade.sh for the canonical command). |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python -m pip install --quiet pyyaml
python - <<'PY'
import pathlib, sys, yaml
p = pathlib.Path("Taskfile.yml")
try:
yaml.safe_load(p.read_text(encoding="utf-8"))
print("Taskfile.yml parses successfully")
except Exception as e:
print(f"YAML parse error: {e}")
sys.exit(1)
PYRepository: KooshaPari/phenoAI
Length of output: 283
Quote the desc value to fix YAML syntax error.
The unquoted colon in SSOT: see grade.sh creates a mapping value where the parser expects a scalar, causing Taskfile.yml to fail parsing. This violates the coding guideline requiring all YAML files to pass linting before commit.
Fix
- desc: Measure code coverage (SSOT: see grade.sh for the canonical command).
+ desc: "Measure code coverage (SSOT: see grade.sh for the canonical command)."📝 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.
| desc: Measure code coverage (SSOT: see grade.sh for the canonical command). | |
| desc: "Measure code coverage (SSOT: see grade.sh for the canonical command)." |
🧰 Tools
🪛 YAMLlint (1.37.1)
[error] 25-25: syntax error: mapping values are not allowed here
(syntax)
🤖 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 `@Taskfile.yml` at line 25, The desc field value contains an unquoted colon in
SSOT: see grade.sh which causes YAML parsing to fail because the colon is
interpreted as a key-value mapping separator rather than part of the string.
Quote the entire desc value (the complete string from "Measure code coverage"
through "canonical command)") to treat the colon as part of the scalar string
literal and resolve the YAML syntax error.
Sources: Coding guidelines, Linters/SAST tools
39867c3 to
50bce2f
Compare
|
There was a problem hiding this comment.
♻️ Duplicate comments (1)
Taskfile.yml (1)
25-25:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winQuote the
descstring to fix YAML parse failure.Line 25 uses an unquoted scalar containing
SSOT: ...; this is parsed as invalid YAML and breaks Taskfile loading.Proposed fix
- desc: Measure code coverage (SSOT: see grade.sh for the canonical command). + desc: "Measure code coverage (SSOT: see grade.sh for the canonical command)."As per coding guidelines, “All code MUST pass linting and formatting checks before commit; Run linters and formatters locally and fix errors; do not suppress or ignore warnings.”
🤖 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 `@Taskfile.yml` at line 25, The desc field on line 25 contains an unquoted string with a colon in "SSOT:" which causes invalid YAML parsing. Quote the entire desc string value (using either single or double quotes) to treat it as a literal string and resolve the YAML parse failure.Sources: Coding guidelines, 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.
Duplicate comments:
In `@Taskfile.yml`:
- Line 25: The desc field on line 25 contains an unquoted string with a colon in
"SSOT:" which causes invalid YAML parsing. Quote the entire desc string value
(using either single or double quotes) to treat it as a literal string and
resolve the YAML parse failure.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 40c900c0-8d7c-464c-8996-d5d8e6780394
📒 Files selected for processing (2)
Taskfile.ymljustfile
📜 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: coverage
- GitHub Check: semgrep-cloud-platform/scan
- GitHub Check: Kilo Code Review
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{js,ts,tsx,jsx,py,rs,go,java,c,cpp,h,yml,yaml,json,md}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{js,ts,tsx,jsx,py,rs,go,java,c,cpp,h,yml,yaml,json,md}: All code MUST pass linting and formatting checks before commit
Run linters and formatters locally and fix errors; do not suppress or ignore warnings
Files:
Taskfile.yml
🪛 YAMLlint (1.37.1)
Taskfile.yml
[error] 25-25: syntax error: mapping values are not allowed here
(syntax)
🔇 Additional comments (1)
justfile (1)
27-29: LGTM!
Code Review SummaryStatus: 18 Issues Found (all already commented) | Recommendation: Address existing comments before merge Overview
Issue Details (click to expand)CRITICAL
WARNING
SUGGESTION
Other Observations (not in diff)All issues are within the diff scope and have already been flagged by other bots. No additional findings. Files Reviewed (5 files)
Reviewed by laguna-m.1-20260312:free · 542,609 tokens |




User description
Adds a
coveragetask to both Taskfile.yml and justfile, referencing grade.sh as the SSOT for the canonical coverage command.Changes
coveragetask usingcargo llvm-cov --workspace --fail-under-lines 85coveragerecipe using the same commandRisk Assessment
Low risk — additive tooling changes only, no runtime or application code modifications.
Note
Low Risk
Additive developer tooling only; no application or CI pipeline behavior changes beyond new optional local commands.
Overview
Adds a
coverageshortcut to Taskfile.yml and the justfile so developers can run workspace line-coverage locally without invoking the full grade script.Both entry points run
cargo llvm-cov --workspace --fail-under-lines 85, matching the Rust coverage check ingrade.sh. Descriptions/comments point tograde.shas the canonical definition of that command.Reviewed by Cursor Bugbot for commit 50bce2f. Bugbot is set up for automated code reviews on this repo. Configure here.
CodeAnt-AI Description
Add governance checks, repository standards docs, and a coverage shortcut
What Changed
SSOT.mdto list the canonical source for key repository rules andARCHITECTURE.mdto outline the workspace structure and boundariescoveragetask to bothTaskfile.ymlandjustfileso local coverage checks run the same command used by the project’s grading flowImpact
✅ Earlier detection of missing governance files✅ Fewer branch-policy mistakes✅ One-step local coverage checks💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.