-
Notifications
You must be signed in to change notification settings - Fork 4
chore(ci): add Claude coded architecture doc validation workflow #214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| uses: ./.github/workflows/_claude-code.yml | ||
| with: | ||
| platform_environment: ${{ inputs.platform_environment || 'staging' }} | ||
| mode: 'automation' | ||
| track_progress: ${{ github.event_name != 'workflow_dispatch' && true || false }} | ||
| allowed_tools: 'Read,Glob,Grep,LS,Bash(git:*),Bash(gh:*),Bash(find:*),Bash(diff:*),Bash(uv:*)' | ||
| prompt: | | ||
| # SOFTWARE ARCHITECTURE VALIDATION FOR PULL REQUEST | ||
|
|
||
| **REPO**: ${{ github.repository }} | ||
| **PR**: ${{ github.event.pull_request.number && format('#{0}', github.event.pull_request.number) || 'Manual Run' }} | ||
| **BRANCH**: ${{ github.event.pull_request.head.ref || github.ref_name }} | ||
|
|
||
| ## Context | ||
|
|
||
| This PR validation checks if `SOFTWARE_ARCHITECTURE.md` accurately reflects | ||
| the current codebase structure, dependencies, and architectural patterns after | ||
| the proposed changes in this PR. | ||
|
|
||
| ## Your Mission | ||
|
|
||
| Analyze the changes in this PR and validate that the Software Architecture | ||
| document remains accurate, complete, and up-to-date. | ||
|
|
||
| ## Step 1: Understand PR Changes | ||
|
|
||
| ```bash | ||
| echo "=== Analyzing PR Changes ===" | ||
| echo "" | ||
|
|
||
| # Check if this is a PR or manual run | ||
| PR_NUMBER="${{ github.event.pull_request.number }}" | ||
|
|
||
| if [ -n "$PR_NUMBER" ]; then | ||
| echo "Changed files in this PR:" | ||
| gh pr view "$PR_NUMBER" --json files --jq '.files[].path' | sort | ||
| echo "" | ||
| echo "Detailed diff:" | ||
| gh pr diff "$PR_NUMBER" | ||
| else | ||
| echo "Manual run - comparing with main branch" | ||
| echo "Changed files:" | ||
| git diff --name-only origin/main...HEAD | sort | ||
| echo "" | ||
| echo "Detailed diff:" | ||
| git diff origin/main...HEAD | ||
| fi | ||
| ``` | ||
|
|
||
| ## Step 2: Read Current Architecture Document | ||
|
|
||
| ```bash | ||
| echo "=== Reading Architecture Document ===" | ||
| echo "" | ||
| # Read the current SOFTWARE_ARCHITECTURE.md | ||
| cat SOFTWARE_ARCHITECTURE.md | ||
| ``` | ||
|
|
||
| ## Step 3: Validate Architecture Accuracy | ||
|
|
||
| For each change in the PR, check if the architecture document needs updates: | ||
|
|
||
| ### Check 1: New Modules or Files | ||
|
|
||
| ```bash | ||
| # Look for new modules | ||
| echo "=== Checking for New Modules ===" | ||
|
|
||
| PR_NUMBER="${{ github.event.pull_request.number }}" | ||
|
|
||
| # Check if new directories were added in src/aignostics/ | ||
| if [ -n "$PR_NUMBER" ]; then | ||
| NEW_MODULES=$(gh pr diff "$PR_NUMBER" | grep "^+++ b/src/aignostics/" | cut -d/ -f3 | sort -u) | ||
| else | ||
| NEW_MODULES=$(git diff origin/main...HEAD --name-only | grep "^src/aignostics/" | cut -d/ -f3 | sort -u) | ||
| fi | ||
|
|
||
| if [ -n "$NEW_MODULES" ]; then | ||
| echo "New modules detected:" | ||
| echo "$NEW_MODULES" | ||
|
|
||
| # Check if these are documented in SOFTWARE_ARCHITECTURE.md | ||
| for module in $NEW_MODULES; do | ||
| if grep -q "$module" SOFTWARE_ARCHITECTURE.md; then | ||
| echo " ✅ $module is documented" | ||
| else | ||
| echo " ❌ BLOCKING: $module NOT documented in architecture" | ||
| fi | ||
| done | ||
| fi | ||
| ``` | ||
|
|
||
| ### Check 2: Dependency Changes | ||
|
|
||
| ```bash | ||
| echo "=== Checking Dependency Changes ===" | ||
|
|
||
| PR_NUMBER="${{ github.event.pull_request.number }}" | ||
|
|
||
| # Check if pyproject.toml was modified | ||
| if [ -n "$PR_NUMBER" ]; then | ||
| PYPROJECT_CHANGED=$(gh pr diff "$PR_NUMBER" --name-only | grep -q "pyproject.toml" && echo "yes" || echo "no") | ||
| else | ||
| PYPROJECT_CHANGED=$(git diff origin/main...HEAD --name-only | grep -q "pyproject.toml" && echo "yes" || echo "no") | ||
| fi | ||
|
|
||
| if [ "$PYPROJECT_CHANGED" = "yes" ]; then | ||
| echo "⚠️ pyproject.toml was modified - check if dependencies section needs update" | ||
|
|
||
| # Extract new dependencies from diff | ||
| if [ -n "$PR_NUMBER" ]; then | ||
| gh pr diff "$PR_NUMBER" -- pyproject.toml | grep "^+" | grep -E "(dependencies|extras)" || echo "No dependency changes detected" | ||
| else | ||
| git diff origin/main...HEAD -- pyproject.toml | grep "^+" | grep -E "(dependencies|extras)" || echo "No dependency changes detected" | ||
| fi | ||
| fi | ||
| ``` | ||
|
|
||
| ### Check 3: Workflow/CI Changes | ||
|
|
||
| ```bash | ||
| echo "=== Checking CI/CD Changes ===" | ||
|
|
||
| PR_NUMBER="${{ github.event.pull_request.number }}" | ||
|
|
||
| # Check if workflows were added/modified | ||
| if [ -n "$PR_NUMBER" ]; then | ||
| WORKFLOW_FILES=$(gh pr diff "$PR_NUMBER" --name-only | grep ".github/workflows/" || echo "") | ||
| else | ||
| WORKFLOW_FILES=$(git diff origin/main...HEAD --name-only | grep ".github/workflows/" || echo "") | ||
| fi | ||
|
|
||
| if [ -n "$WORKFLOW_FILES" ]; then | ||
| echo "⚠️ GitHub workflows modified - check if CI/CD section needs update" | ||
| echo "$WORKFLOW_FILES" | ||
| fi | ||
| ``` | ||
|
|
||
| ### Check 4: Architecture Pattern Changes | ||
|
|
||
| ```bash | ||
| echo "=== Checking Architecture Patterns ===" | ||
|
|
||
| PR_NUMBER="${{ github.event.pull_request.number }}" | ||
|
|
||
| # Look for significant structural changes | ||
| if [ -n "$PR_NUMBER" ]; then | ||
| SIGNIFICANT_CHANGES=$(gh pr diff "$PR_NUMBER" --name-only | grep -E "(src/aignostics/.*/_service.py|src/aignostics/.*/_cli.py|src/aignostics/.*/_gui.py|src/aignostics/utils/)" || echo "") | ||
| else | ||
| SIGNIFICANT_CHANGES=$(git diff origin/main...HEAD --name-only | grep -E "(src/aignostics/.*/_service.py|src/aignostics/.*/_cli.py|src/aignostics/.*/_gui.py|src/aignostics/utils/)" || echo "") | ||
| fi | ||
|
|
||
| if [ -n "$SIGNIFICANT_CHANGES" ]; then | ||
| echo "Significant architectural files changed:" | ||
| echo "$SIGNIFICANT_CHANGES" | ||
|
|
||
| # Read these files to understand the changes | ||
| for file in $SIGNIFICANT_CHANGES; do | ||
| echo "" | ||
| echo "=== Reading: $file ===" | ||
| cat "$file" 2>/dev/null || echo "File not found or deleted" | ||
| done | ||
| fi | ||
| ``` | ||
|
|
||
| ### Check 5: Module Structure Validation | ||
|
|
||
| ```bash | ||
| echo "=== Validating Module Structure ===" | ||
|
|
||
| # List current modules | ||
| CURRENT_MODULES=$(find src/aignostics -maxdepth 1 -type d -not -name "__pycache__" -not -name "aignostics" | sed 's|src/aignostics/||' | sort) | ||
|
|
||
| echo "Current modules in codebase:" | ||
| echo "$CURRENT_MODULES" | ||
| echo "" | ||
|
|
||
| # Check which modules are documented in SOFTWARE_ARCHITECTURE.md | ||
| echo "Checking documentation coverage:" | ||
| for module in $CURRENT_MODULES; do | ||
| if [ -n "$module" ]; then | ||
| if grep -qi "$module" SOFTWARE_ARCHITECTURE.md; then | ||
| echo " ✅ $module - documented" | ||
| else | ||
| echo " ⚠️ $module - not found in architecture doc" | ||
| fi | ||
| fi | ||
| done | ||
| ``` | ||
|
|
||
| ## Step 4: Generate PR Comment | ||
|
|
||
| After validation, post findings as a PR comment: | ||
|
|
||
| ```bash | ||
| PR_NUMBER="${{ github.event.pull_request.number }}" | ||
| BRANCH_NAME="${{ github.event.pull_request.head.ref || github.ref_name }}" | ||
|
|
||
| # Build the comment with actual values | ||
| cat > /tmp/architecture-validation.md << EOF | ||
| # 🏗️ Software Architecture Validation | ||
|
|
||
| **PR**: $([ -n "$PR_NUMBER" ] && echo "#$PR_NUMBER" || echo "Manual Run") | ||
| **Branch**: $BRANCH_NAME | ||
| **Architecture Doc**: \`SOFTWARE_ARCHITECTURE.md\` | ||
|
|
||
| --- | ||
|
|
||
| ## ❌ BLOCKING ISSUES | ||
|
|
||
| [List any critical discrepancies that must be fixed before merge] | ||
|
|
||
| ### Example: New Module Not Documented | ||
|
|
||
| **Issue**: New module `example_module` added but not documented in architecture | ||
|
|
||
| - **Location**: `src/aignostics/example_module/` | ||
| - **Missing from**: `SOFTWARE_ARCHITECTURE.md` Section 1.5 | ||
| - **Current State**: Module exists with `_service.py`, `_cli.py`, `_gui.py` | ||
| - **Required Action**: Add module description to Section 1.5 "Layers and Modules" | ||
| - **Suggested Content**: | ||
| ```markdown | ||
| **Example Module (`example_module/`)** | ||
| - **Service**: [Brief description of what this module does] | ||
| - **CLI**: [Command-line operations provided] | ||
| - **GUI**: [GUI interface features] | ||
| - **Settings**: [Configuration options] | ||
| ``` | ||
|
|
||
| --- | ||
|
|
||
| ## ⚠️ SUGGESTIONS | ||
|
|
||
| [List recommended but non-critical updates] | ||
|
|
||
| ### Example: Dependency Update | ||
|
|
||
| **Suggestion**: Update dependency list in Section 1.3 | ||
|
|
||
| - **Change**: `pyproject.toml` shows new dependency `new-library==1.0.0` | ||
| - **Current Doc**: Section 1.3 "Language and Frameworks" doesn't mention this | ||
| - **Recommendation**: Add to "Key Dependencies" section | ||
| - **Priority**: Medium (nice-to-have for completeness) | ||
|
|
||
| ### Example: Diagram Update | ||
|
|
||
| **Suggestion**: Update architecture diagram | ||
|
|
||
| - **Change**: New integration with external service | ||
| - **Current Doc**: Diagram in Section 1.2 doesn't show this integration | ||
| - **Recommendation**: Add connection to "External Services" layer in Mermaid diagram | ||
| - **Priority**: Low (diagram still conceptually accurate) | ||
|
|
||
| --- | ||
|
|
||
| ## ✅ VALIDATED SUCCESSFULLY | ||
|
|
||
| ### Code Changes That Don't Require Doc Updates | ||
|
|
||
| - ✅ **Bug fix in `application/_service.py`** - Internal implementation detail, no architectural impact | ||
| - ✅ **Test updates** - Test coverage improvements don't affect architecture | ||
| - ✅ **Minor refactoring** - Code organization changes within existing patterns | ||
|
|
||
| ### Architecture Doc Accuracy | ||
|
|
||
| - ✅ **Module structure** - All existing modules properly documented | ||
| - ✅ **Layer separation** - Presentation/Domain/Platform layers correctly described | ||
| - ✅ **Design principles** - Section 2 accurately reflects implementation patterns | ||
|
|
||
| --- | ||
|
|
||
| ## 📊 Summary | ||
|
|
||
| - **Files Changed**: X | ||
| - **New Modules Added**: Y | ||
| - **Blocking Issues**: N | ||
| - **Suggestions**: M | ||
| - **Architecture Doc Status**: [Accurate / Needs Updates] | ||
|
|
||
| --- | ||
|
|
||
| ## 🎯 Action Required | ||
|
|
||
| **Before merging this PR:** | ||
|
|
||
| 1. Update `SOFTWARE_ARCHITECTURE.md` Section X.Y with [specific changes] | ||
| 2. Add Mermaid diagram update for [new component/integration] | ||
| 3. Update dependency list in Section 1.3 | ||
|
|
||
| **Commands to verify current structure:** | ||
|
|
||
| ```bash | ||
| # List all modules | ||
| find src/aignostics -maxdepth 1 -type d | ||
|
|
||
| # Check dependencies | ||
| cat pyproject.toml | grep -A 50 "dependencies =" | ||
|
|
||
| # View architecture doc sections | ||
| grep "^##" SOFTWARE_ARCHITECTURE.md | ||
| ``` | ||
|
|
||
| --- | ||
|
|
||
| **Remember**: Architecture documentation is the blueprint for understanding and | ||
| maintaining this codebase. Keeping it accurate helps onboarding, compliance, and | ||
| long-term maintainability. | ||
|
|
||
| *Generated by Claude Code Architecture Validation* | ||
| EOF | ||
|
|
||
| # Post comment if this is a PR, otherwise just output to logs | ||
| if [ -n "$PR_NUMBER" ]; then | ||
| echo "Posting comment to PR #$PR_NUMBER" | ||
| gh pr comment "$PR_NUMBER" --body-file /tmp/architecture-validation.md | ||
| else | ||
| echo "Manual run - validation results:" | ||
| cat /tmp/architecture-validation.md | ||
| fi | ||
| ``` | ||
|
|
||
| ## Validation Criteria | ||
|
|
||
| ### BLOCKING Issues (Must Fix): | ||
| - New modules not documented in Section 1.5 | ||
| - Major architectural pattern changes not reflected in Section 1.2 | ||
| - New external integrations missing from Section 3 | ||
| - Significant dependency additions not listed in Section 1.3 | ||
|
|
||
| ### SUGGESTIONS (Nice-to-Have): | ||
| - Diagram updates for new components | ||
| - Minor dependency additions | ||
| - Updated version numbers | ||
| - Enhanced descriptions for existing components | ||
| - Formatting improvements | ||
|
|
||
| ### VALIDATED (No Action Needed): | ||
| - Internal implementation changes within existing patterns | ||
| - Bug fixes that don't change architecture | ||
| - Test coverage improvements | ||
| - Documentation fixes in other files | ||
| - Minor refactoring within same module | ||
|
|
||
| ## Important Guidelines | ||
|
|
||
| 1. **Understand the changes** - Read the actual PR diff thoroughly | ||
| 2. **Read the architecture doc** - Don't assume what's documented | ||
| 3. **Be practical** - Not every code change requires doc updates | ||
| 4. **Be specific** - Provide exact sections and suggested content | ||
| 5. **Be helpful** - Suggest actual text to add, not just "update section X" | ||
| 6. **Check current state** - Verify modules exist before claiming they're undocumented | ||
|
|
||
| ## What to Look For | ||
|
|
||
| ### New Modules | ||
| - Any new directory under `src/aignostics/` with `_service.py`, `_cli.py`, or `_gui.py` | ||
| - Check if documented in Section 1.5 "Layers and Modules" | ||
|
|
||
| ### Dependency Changes | ||
| - New entries in `pyproject.toml` dependencies or optional-dependencies | ||
| - Check if major dependencies are listed in Section 1.3 | ||
|
|
||
| ### CI/CD Changes | ||
| - New or modified workflows in `.github/workflows/` | ||
| - Check if Section 1.4 "Build Chain and CI/CD" is accurate | ||
|
|
||
| ### Integration Changes | ||
| - New external API integrations | ||
| - Check if documented in Section 3 "Integration Patterns" | ||
|
|
||
| ### Pattern Changes | ||
| - Changes to core patterns in `utils/` or base classes | ||
| - Check if Section 2 "Design Principles" needs updates | ||
|
|
||
| --- | ||
|
|
||
| **Focus**: Keep the architecture document as a living, accurate representation | ||
| of the codebase structure and design decisions. | ||
| secrets: | ||
| ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} | ||
| AIGNOSTICS_CLIENT_ID_DEVICE_STAGING: ${{ secrets.AIGNOSTICS_CLIENT_ID_DEVICE_STAGING }} | ||
| AIGNOSTICS_REFRESH_TOKEN_STAGING: ${{ secrets.AIGNOSTICS_REFRESH_TOKEN_STAGING }} | ||
| GCP_CREDENTIALS_STAGING: ${{ secrets.GCP_CREDENTIALS_STAGING }} | ||
| AIGNOSTICS_CLIENT_ID_DEVICE_PRODUCTION: ${{ secrets.AIGNOSTICS_CLIENT_ID_DEVICE_PRODUCTION }} | ||
| AIGNOSTICS_REFRESH_TOKEN_PRODUCTION: ${{ secrets.AIGNOSTICS_REFRESH_TOKEN_PRODUCTION }} | ||
| GCP_CREDENTIALS_PRODUCTION: ${{ secrets.GCP_CREDENTIALS_PRODUCTION }} |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 months ago
General Fix:
Explicitly define a permissions block with the minimum required permissions at the root of the workflow or at the job level for architecture-validation. Since the workflow appears to only read repository contents and post comments to pull requests (requires read on contents and write on pull-requests), the minimal required permissions are likely:
permissions:
contents: read
pull-requests: writeDetails:
- If you add
permissions:at the top level (aftername:and beforeon:), it applies to all jobs in the workflow unless overridden. - Alternatively, you can add a
permissions:block within thearchitecture-validation:job, but for a single-job workflow, it's customary and clearer to place it at the root. - No new imports, dependencies, or logic changes are needed; you only need to insert the correct YAML block.
Changes:
- Insert the block:
after the
permissions: contents: read pull-requests: write
name:field and before theon:section in.github/workflows/claude-code-architecture-validation.yml.
-
Copy modified lines R2-R4
| @@ -1,4 +1,7 @@ | ||
| name: "+ Claude Code / Architecture Doc Validation" | ||
| permissions: | ||
| contents: read | ||
| pull-requests: write | ||
|
|
||
| on: | ||
| pull_request: |
|
|
||
| ## Context | ||
|
|
||
| This PR validation checks if `SOFTWARE_ARCHITECTURE.md` accurately reflects |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BLOCKING: This workflow validates SOFTWARE_ARCHITECTURE.md, but this file does not exist in the repository.
Required Action: Before merging, either:
- Create
SOFTWARE_ARCHITECTURE.mdin the repository root, OR - Update the PR description to clarify this is a 2-part change (workflow now, doc later), OR
- Change the workflow to validate existing documentation
Verify:
ls -la SOFTWARE_ARCHITECTURE.md| if [ -n "$PR_NUMBER" ]; then | ||
| NEW_MODULES=$(gh pr diff "$PR_NUMBER" | grep "^+++ b/src/aignostics/" | cut -d/ -f3 | sort -u) | ||
| else | ||
| NEW_MODULES=$(git diff origin/main...HEAD --name-only | grep "^src/aignostics/" | cut -d/ -f3 | sort -u) | ||
| fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BLOCKING: Incorrect bash syntax - gh pr diff doesn't support piping in this way.
Fix:
if [ -n "$PR_NUMBER" ]; then
NEW_MODULES=$(gh pr view "$PR_NUMBER" --json files --jq '.files[] | select(.path | startswith("src/aignostics/")) | .path' | cut -d/ -f3 | sort -u)
else
NEW_MODULES=$(git diff origin/main...HEAD --name-only | grep "^src/aignostics/" | cut -d/ -f3 | sort -u)
fiReason: gh pr diff outputs unified diff format, not a list of files. Use gh pr view --json files instead.
| if [ -n "$PR_NUMBER" ]; then | ||
| PYPROJECT_CHANGED=$(gh pr diff "$PR_NUMBER" --name-only | grep -q "pyproject.toml" && echo "yes" || echo "no") | ||
| else | ||
| PYPROJECT_CHANGED=$(git diff origin/main...HEAD --name-only | grep -q "pyproject.toml" && echo "yes" || echo "no") | ||
| fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BLOCKING: Incorrect bash syntax - command substitution with conditional won't work reliably.
Fix:
if [ -n "$PR_NUMBER" ]; then
if gh pr view "$PR_NUMBER" --json files --jq '.files[].path' | grep -q "pyproject.toml"; then
PYPROJECT_CHANGED="yes"
else
PYPROJECT_CHANGED="no"
fi
else
if git diff origin/main...HEAD --name-only | grep -q "pyproject.toml"; then
PYPROJECT_CHANGED="yes"
else
PYPROJECT_CHANGED="no"
fi
fi| if [ -n "$PR_NUMBER" ]; then | ||
| WORKFLOW_FILES=$(gh pr diff "$PR_NUMBER" --name-only | grep ".github/workflows/" || echo "") | ||
| else | ||
| WORKFLOW_FILES=$(git diff origin/main...HEAD --name-only | grep ".github/workflows/" || echo "") | ||
| fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BLOCKING: Same issue as line 90 - gh pr diff doesn't support --name-only.
Fix:
if [ -n "$PR_NUMBER" ]; then
WORKFLOW_FILES=$(gh pr view "$PR_NUMBER" --json files --jq '.files[] | select(.path | startswith(".github/workflows/")) | .path')
else
WORKFLOW_FILES=$(git diff origin/main...HEAD --name-only | grep ".github/workflows/")
fi| platform_environment: ${{ inputs.platform_environment || 'staging' }} | ||
| mode: 'automation' | ||
| track_progress: ${{ github.event_name != 'workflow_dispatch' && true || false }} | ||
| allowed_tools: 'Read,Glob,Grep,LS,Bash(git:*),Bash(gh:*),Bash(find:*),Bash(diff:*),Bash(uv:*)' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: Consider adding Bash(cat:*) and Bash(echo:*) to allowed_tools for the file operations on lines 218-328 (creating /tmp/architecture-validation.md).
While Bash(gh:*) should allow PR comment posting, the heredoc file creation might need explicit tool access.
Alternative: Consider if Claude needs Write tool permission instead of bash file operations.
| ## Step 1: Understand PR Changes | ||
|
|
||
| ```bash | ||
| echo "=== Analyzing PR Changes ===" | ||
| echo "" | ||
|
|
||
| # Check if this is a PR or manual run | ||
| PR_NUMBER="${{ github.event.pull_request.number }}" | ||
|
|
||
| if [ -n "$PR_NUMBER" ]; then | ||
| echo "Changed files in this PR:" | ||
| gh pr view "$PR_NUMBER" --json files --jq '.files[].path' | sort | ||
| echo "" | ||
| echo "Detailed diff:" | ||
| gh pr diff "$PR_NUMBER" | ||
| else | ||
| echo "Manual run - comparing with main branch" | ||
| echo "Changed files:" | ||
| git diff --name-only origin/main...HEAD | sort | ||
| echo "" | ||
| echo "Detailed diff:" | ||
| git diff origin/main...HEAD | ||
| fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: Consider adding error handling to bash blocks:
set -euo pipefail
echo "=== Analyzing PR Changes ==="
# ... rest of commandsThis ensures:
-e: Exit on error-u: Error on undefined variables-o pipefail: Catch errors in pipes
Makes failures more visible and prevents silent errors.
| # Read these files to understand the changes | ||
| for file in $SIGNIFICANT_CHANGES; do | ||
| echo "" | ||
| echo "=== Reading: $file ===" | ||
| cat "$file" 2>/dev/null || echo "File not found or deleted" | ||
| done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: Reading all significant files could be expensive for large changesets.
Consider:
- Limiting to first N files (e.g.,
| head -10) - Reading only file summaries instead of full contents
- Letting Claude decide which files to inspect based on change summary
Alternative approach:
echo "Files to review:"
echo "$SIGNIFICANT_CHANGES"
echo ""
echo "Use Read tool to inspect specific files as needed"Add automated validation of SOFTWARE_ARCHITECTURE.md on PRs to ensure documentation stays in sync with code changes. Workflow checks for: - New modules not documented - Dependency changes in pyproject.toml - CI/CD workflow modifications - Architecture pattern changes - Module structure consistency
dd5ad43 to
283fa42
Compare
|
Claude finished @muhabalwan-aginx's task —— View job Post-Merge Review: PR #214 Architecture Validation WorkflowStatus: PR was CLOSED (not merged) - The workflow file was never added to main branch Tasks
Analysis SummaryGood News: PR #214 was closed without merging, so the problematic workflow file was never added to the main branch. The Status of Blocking Issues: All the blocking issues identified by the automated reviews are still present in the PR branch but were never merged, so they didn't impact the main codebase. Critical Issues Found (Would Have Been Blocking)1. Bash Syntax Errors - Multiple locationsLine 91-94: Incorrect use of # INCORRECT (in PR):
NEW_MODULES=$(gh pr diff "$PR_NUMBER" | grep "^+++ b/src/aignostics/" | cut -d/ -f3 | sort -u)
# CORRECT:
NEW_MODULES=$(gh pr view "$PR_NUMBER" --json files --jq '.files[] | select(.path | startswith("src/aignostics/")) | .path' | cut -d/ -f3 | sort -u)Why it's wrong: Line 120-123: Command substitution with grep in conditional # INCORRECT (in PR):
PYPROJECT_CHANGED=$(gh pr diff "$PR_NUMBER" --name-only | grep -q "pyproject.toml" && echo "yes" || echo "no")
# CORRECT:
if gh pr view "$PR_NUMBER" --json files --jq '.files[].path' | grep -q "pyproject.toml"; then
PYPROJECT_CHANGED="yes"
else
PYPROJECT_CHANGED="no"
fiWhy it's wrong: Using Line 146-149: Same # INCORRECT (in PR):
WORKFLOW_FILES=$(gh pr diff "$PR_NUMBER" --name-only | grep ".github/workflows/" || echo "")
# CORRECT:
WORKFLOW_FILES=$(gh pr view "$PR_NUMBER" --json files --jq '.files[] | select(.path | startswith(".github/workflows/")) | .path')2. Security Issue - Missing Permissions BlockLine 404 (end of file): CodeQL flagged missing jobs:
architecture-validation:
uses: ./.github/workflows/_claude-code.yml
# MISSING: permissions block
with:
platform_environment: ${{ inputs.platform_environment || 'staging' }}
# ... rest of configRequired fix: jobs:
architecture-validation:
permissions:
contents: read
pull-requests: write
issues: write
uses: ./.github/workflows/_claude-code.yml
with:
# ... rest of configImpact: Without explicit permissions, the workflow inherits default 3. Tool Permissions Issue - Line 24Current: allowed_tools: 'Read,Glob,Grep,LS,Bash(git:*),Bash(gh:*),Bash(find:*),Bash(diff:*),Bash(uv:*)'Problem: The workflow uses
Recommended fix: allowed_tools: 'Read,Write,Glob,Grep,LS,Bash(git:*),Bash(gh:*),Bash(find:*),Bash(diff:*),Bash(uv:*),Bash(cat:*)'4. Error Handling - Lines 65+Suggestion: Add bash error handling to all script blocks: set -euo pipefail # Exit on error, undefined vars, pipe failures
echo "=== Analyzing PR Changes ==="
# ... rest of commandsThis ensures failures are visible and prevents silent errors. 5. Performance Concern - Line 180Current approach: # Read these files to understand the changes
for file in $SIGNIFICANT_CHANGES; do
echo ""
echo "=== Reading: $file ==="
cat "$file" 2>/dev/null || echo "File not found or deleted"
doneIssue: Reading ALL significant files could be expensive for large changesets. Recommendation: echo "Files to review:"
echo "$SIGNIFICANT_CHANGES"
echo ""
echo "Use Read tool to inspect specific files as needed"Let Claude decide which files to inspect based on the change summary. Recommendations Going ForwardSince the PR was closed without merging, here's what should happen: Option 1: Fix and Reopen (Recommended)Create a new PR with fixes for all blocking issues:
Option 2: Simplify the ApproachInstead of bash script gymnastics, let Claude use its tools naturally: allowed_tools: 'Read,Glob,Grep,Bash(git:*),Bash(gh:*),Bash(uv:*)'
prompt: |
# SOFTWARE ARCHITECTURE VALIDATION
Analyze PR #${{ github.event.pull_request.number }} and validate SOFTWARE_ARCHITECTURE.md accuracy.
Steps:
1. Use `gh pr view` to see changed files
2. Use `Read` tool to examine SOFTWARE_ARCHITECTURE.md
3. Use `Grep` to search for module names in the doc
4. Report any discrepancies between code structure and documentation
Focus on:
- New modules under src/aignostics/
- Changes to pyproject.toml dependencies
- New CI/CD workflows
- Architectural pattern changesThis approach:
Option 3: Close as Won't FixIf the team decides this automated validation isn't needed, that's fine too. The Test Plan (If Reopening)Before merging a fixed version:
Summary✅ Good: The problematic workflow was never merged, so no damage done The concept of automated architecture validation is excellent, but the implementation needs fixes before merging. |
|
Claude finished @muhabalwan-aginx's task —— View job Post-Merge Review: PR #214 Architecture Validation WorkflowStatus: PR was CLOSED (not merged) ✅ - The problematic workflow file was never added to main branch Analysis CompleteI've thoroughly reviewed the workflow file and validated all the blocking issues identified in the previous automated review. Here are my findings: Critical Issues (Would Have Been Blocking)1. ❌ Bash Syntax Errors - Multiple LocationsIssue at Line 112 (workflow line 90):NEW_MODULES=$(gh pr diff "$PR_NUMBER" | grep "^+++ b/src/aignostics/" | cut -d/ -f3 | sort -u)Problem: Correct approach: NEW_MODULES=$(gh pr view "$PR_NUMBER" --json files --jq '.files[] | select(.path | startswith("src/aignostics/")) | .path' | cut -d/ -f3 | sort -u)Issue at Line 141 (workflow line 120):PYPROJECT_CHANGED=$(gh pr diff "$PR_NUMBER" --name-only | grep -q "pyproject.toml" && echo "yes" || echo "no")Problem: Correct approach: if gh pr view "$PR_NUMBER" --json files --jq '.files[].path' | grep -q "pyproject.toml"; then
PYPROJECT_CHANGED="yes"
else
PYPROJECT_CHANGED="no"
fiIssue at Line 167 (workflow line 146):WORKFLOW_FILES=$(gh pr diff "$PR_NUMBER" --name-only | grep ".github/workflows/" || echo "")Problem: Same as above - Correct approach: WORKFLOW_FILES=$(gh pr view "$PR_NUMBER" --json files --jq '.files[] | select(.path | startswith(".github/workflows/")) | .path')2. 🔒 Security Issue - Missing Permissions BlockCodeQL Finding: Line 404 (end of workflow) - No explicit Current: jobs:
architecture-validation:
uses: ./.github/workflows/_claude-code.yml
with:
platform_environment: ${{ inputs.platform_environment || 'staging' }}
# ... restRequired Fix: jobs:
architecture-validation:
permissions:
contents: read
pull-requests: write
issues: write
uses: ./.github/workflows/_claude-code.yml
with:
platform_environment: ${{ inputs.platform_environment || 'staging' }}
# ... restWhy: Without explicit permissions, the workflow inherits default 3. 🛠️ Tool Permissions Issue - Line 45Current: allowed_tools: 'Read,Glob,Grep,LS,Bash(git:*),Bash(gh:*),Bash(find:*),Bash(diff:*),Bash(uv:*)'Problem: The workflow uses
Recommended Fix: allowed_tools: 'Read,Write,Glob,Grep,LS,Bash(git:*),Bash(gh:*),Bash(find:*),Bash(diff:*),Bash(uv:*),Bash(cat:*)'Or better yet, use the 4.
|
| Category | Count | Status |
|---|---|---|
| Blocking Issues | 3 | Bash syntax, Security, Tool permissions |
| Warnings | 2 | Error handling, Performance |
| Status | ✅ | Never merged - no impact to main |
Verdict: The workflow concept is excellent and addresses a real need (keeping architecture docs in sync). However, the implementation has multiple bash syntax errors and security issues that would have caused runtime failures.
Recommended Path: Fix all issues and create a new PR, or simplify the approach to let Claude use tools naturally without prescribing exact bash commands.
No action required on this closed PR - All findings are documented for future reference.
| Branch: claude/pr-214-20251027-1125
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|



Add automated validation of SOFTWARE_ARCHITECTURE.md on PRs to ensure documentation stays in sync with code changes. Workflow checks for: