Compare commits

..

No commits in common. "master" and "zen_browser__is_it_the_new_browser_for_me" have entirely different histories.

6 changed files with 2 additions and 498 deletions

View File

@ -1,187 +0,0 @@
Title: How Bureaucratic Systems Interact To Create Bad Outcomes
Date: 2026-07-28 07:22
Modified: 2026-07-28 07:22
Category: Policy
Tags: bureaucracy, healthcare, superannuation, child-care-subsidy, australia
Slug: bureaucratic-systems-bad-outcomes
Authors: Andrew Ridgway
Summary: A parent's account of how Australia's health, tax and welfare systems interact to penalise families who access their superannuation for essential medical treatment for their children.
This is going to be a long blog post. I do not normally air complaints this specific publicly, but in this day and age it seems to be the only way to get people to stand back from their own processes and rules and sit down and actually listen to how a system works in reality. The long and short of it is that we have a compassionate release of superannuation system that is neither compassionate nor understanding, and is actively generating worse outcomes than the failure it was designed to address.
I recently had to deal with something no parent enjoys. My child injured her knee to the point it required surgery. She was just getting into rugby and doing some amazing things to get on top of her health, and we were faced with the unenviable choice that comes with this scenario in Australia: public or private health. What follows is the journey that happens when you try to use private health in Australia to get better outcomes for your child. We are going to look at the interactions between the private and public health system, the Australian Taxation Office and the compassionate release of superannuation system, and how that release then interacts with the Child Care Subsidy and Human Services system.
This blog post is accompanied by emails from the respective Ministers and my local representative. It is the last attempt to have someone actually listen, rather than send canned emails that treat me like a child who did not do any prior research.
I would like to note that Ali France, my local MP, has reached out to me to ask for my story to assist with her work in the House of Representatives Standing Committee on Health, Aged Care and Disability on improving access to specialty doctors. If that committee work is something that matters to you, they are accepting submissions at the Department of Health and Aged Care consultation page on specialist affordability and access. You can see it [here.](https://www.health.gov.au/our-work/consultation-on-specialist-affordability-and-access?language=en). It's a step in the right direction to at least shine a light on the problem but I won't hold my breath for any concrete outcomes.
To work through this, I am going to put together a timeline. The first section covers the initial event and the health care received. The second covers the tax event and its fallout. The third is an analysis of how the three systems interact to create a terrible outcome. The full correspondence is reproduced as an appendix for reference.
Before we get into it, while I have complaints about the systems involved, I want to highlight that the surgeon was always upfront and provided exemplary care. This is by no means a complaint about her, and we could not have asked for a better clinical outcome for my daughter. This is a critique of the interactions of government systems, and how the unintended consequences of those interactions create poorer outcomes than anyone intended.
## Section 1: Timeline of the initial event and the health care received
**June 2024**
My daughter had an incident at school resulting in a serious knee injury. We attended a local emergency department, where the leg was splinted and we were referred back to our GP. We were told at this point that an injury like hers would take between twelve and twenty four months to be triaged in the public hospital system. That is simply unacceptable. She had put in some fantastic work to get on top of her health, and adding twelve to twenty four months on top of the recovery time would have created bad outcomes in their own right. On that basis, we opted to go private.
This is the first key failure of the health system. It is not being proactive, and by reacting in this way to an acute injury it would have created comorbidities in my daughter that would likely have made her a much larger ongoing drain on the health system. The public health system may as well be called the "let's make it worse" system at this point, because that is the practical effect of the wait.
Our GP asked who we would like to be referred to. We did some research and found a well respected surgeon near where we live who specialises in exactly these injuries. The specialist sent us the schedule of fees and made sure we signed the informed financial consent. The fees were high, but we had opted to go private, we knew this would be the case, and we got her in to see the specialist.
**July 2024**
It was confirmed that she needed surgery. Our specialist sent through the financials. The total was expensive. After Medicare, which covered a measly one thousand dollars, there was another six thousand dollars for the surgeon and another one and a half thousand for the anaesthetist, let alone the other costs associated with the procedure. We understood this was expensive, but we believed it would create the best outcomes for our daughter, and we signed the informed consent for surgery. Private health insurance thankfully covered the hospital fees, which would otherwise have added tens of thousands to the final cost.
I asked the specialist if she would access the gap, as we had done before with other surgeons. She told us that she does not participate in that system, because it would mean she makes at best half of her fees, which barely cover her insurance, hospital and usage costs. At this point, I realised that both the public and the private health systems were failing us, and that to get something approaching adequate care we were going to have to stump up our own money, even after putting tens of thousands in each year via the Medicare levy and private health premiums.
I remembered hearing about the release of super for medical reasons, so I looked up the policy. We accepted that this would adversely affect my income tax for the year, but we ran the numbers and concluded it was still cheaper than a personal loan of eight thousand dollars to cover the costs. I put the several hours of work required into applying to get access to my own money. The application was approved.
**August 2024**
My daughter had the surgery. We paid the specialist and the other consultant fees using the money released from the early release of superannuation.
**October 2024**
My daughter began rehabilitation.
**November 2024**
I did the 2023-24 tax return with my accountant. Superannuation was not yet included, and we had a normal tax season.
**April 2025**
My daughter started the 2025 rugby season. She was unfortunately not able to play, but she participated in training. That was only possible because she had the surgery in the private health system. Had we gone down the public path, we would still have been waiting for surgery at this point.
## Section 2: Timeline of the tax event and its fallout
**June 2025**
Our assessment for the relevant financial year landed. The superannuation payout was automatically brought into my taxable income, as expected. I noted the figure and moved on.
**October 2025**
We sat down to do our tax for the year. The number popped up. Pay as you go instalments were sorted via super, and we shrugged, complained about the two thousand dollars the system had effectively charged me to get surgery for my daughter, and moved on. At that point, the pain was still manageable. It was a known cost, and we had accepted it.
**January 2026**
Our Child Care Subsidy was recalculated on the basis of our finalised tax. We did not only lose the tax money. We also lost the monthly benefit of the Child Care Subsidy, which dropped to a very low level for the year. From here, the rest of 2026 has been spent attempting to get Human Services to recognise a one-off release of superannuation as not part of our regular income, and to remove it from the income test for subsidy purposes.
We attempted the Administrative Review Tribunal, only to be told that they wanted detailed breakdowns of our budgets and income. The experience is best described as the system asking a family that has just been financially punished for doing the right thing to also hand over its private financial life for further scrutiny. I will leave the tribunal process there, because the point of this post is not the tribunal.
## Section 3: Analysis of how the three systems interact to create a terrible outcome
It is clear from the timeline that the compassionate release of superannuation is not compassionate. I put this question to the respective Ministers. Why come up with a compassionate release of super option, designed specifically to address failures of funding in health care, and then go and make sure that when you use it the release will not only cost you extra in tax but will also reduce any welfare received? (The same trap awaits people accessing it for things like cosmetic dental, where public waiting lists are similarly stretched.)
### The Letters
Read together, the three letters in the appendix paint a clear picture. The Treasurer's office confirms the design of the system. Early release is taxable, it counts as income for income tested payments, and the Government has no current plans to change that. The Health Minister's office confirms that gap cover is voluntary, that informed financial consent is the main consumer protection mechanism, and that the Government's principal response is an upgrade to a website. The local member's office acknowledges the problem, points to a committee inquiry, and stops there. At the very least they admit it needs fixing and are trying to work through it.
Not one of those letters engages with the central point of my correspondence, which is that the three systems interact in a way that punishes the behaviour the policy is supposed to encourage. The policy says: if you cannot afford essential medical treatment, you can access your superannuation. The tax system says: that access is taxable income. The Human Services system says: that taxable income will now reduce your Child Care Subsidy. The health system says: that is not our problem, talk to the insurer. The insurer says: that is not our problem, the doctor did not use gap cover. The doctor says: that is not our problem, gap cover does not cover our costs. So nothing is anyone's problem, and the family pays the difference.
To the Minister for Social Services, the lack of communication from your office is telling. To the Health Minister's office, why would you send me a response that simply repackages research I have already done and then wash your hands of the matter? To the Treasurer's office, you need to get someone with genuine training in how these systems interact to write your letters, because the response I received defended a design choice without ever addressing the interaction effect that I had specifically written to raise.
### Some broader observations
It is worth saying, for the avoidance of doubt, that none of the people I dealt with in the public service were individually unreasonable. The surgeon was excellent. The accountant was helpful. The staff in the various call centres were polite. The problem is structural, not personal. The system is built in a way that produces this outcome, and the only way to change the outcome is to change the system.
There is also a wider question here about the cost of making private care the only timely option. The official wait time we were quoted was twelve to twenty four months for the initial specialist appointment alone, before any surgery. In a young person, that delay is not neutral. It changes the kind of injury from a recoverable one to a chronic one, it lengthens the period of disability, it reduces the chance of return to sport, and it increases the lifetime cost of treatment. If the policy design of the compassionate release system is meant to relieve pressure on the public system by allowing families to go private, then the policy design of the tax and welfare systems is undermining that intent in the year that follows.
In the end, I should have just gotten a personal loan. It would have cost me less than the tax and lost benefits combined. It is disappointing that this is the case in our "World Class Public Health System™"
### Where this leaves us
I do not expect the system to respond quickly. I do not expect the letters I have published here to result in an immediate change of policy. What I do expect is that, when the relevant committees and the relevant Ministers sit down to consider how the early release of superannuation interacts with the rest of the safety net, they will have a concrete example in front of them of a family that did the right thing and was penalised for it.
If you have had a similar experience, the consultation on specialist affordability and access is open for submissions, and the Standing Committee on Health, Aged Care and Disability is accepting input. You can add your submission [here.](https://www.health.gov.au/our-work/consultation-on-specialist-affordability-and-access?language=en) If you are a policy analyst inside government, and you have read this far, then the question to take back to your work place is simple. Does any part of your work consider the interaction effects of early release, tax and income tested payments, or does each part only consider its own patch? If the answer is the latter, then this post is for you, and so is the next family that comes through the door.
## Appendix: The correspondence
What follows are the substantive letters exchanged with the relevant offices. I have reproduced them so that the reader can see exactly what was said, in the same form that it was said, and judge for themselves how seriously the substance of my concerns was engaged with.
**Letter from the Treasurer's office, via Treasury**
Dear Mr Ridgway,
Thank you for your correspondence of 19 December 2025 to the Hon Jim Chalmers MP, Treasurer, concerning the interaction between early release of superannuation and social services payments. Your correspondence has been referred to Treasury. My sincere apologies for taking so long to get back to you.
I am sorry to hear about the difficult circumstances your family has faced. Please accept my sympathies.
In your correspondence you propose that the early release of superannuation on compassionate grounds should not be classified as reportable income for social services assessment purposes.
As you are aware, benefits paid before an individual turns 60 are taxed at the lower of their marginal tax rate or 20 per cent (plus Medicare levy of 2 per cent where applicable) and are included in their taxable income. The tax treatment of early withdrawals reflects the nature of superannuation as a concessionally taxed form of savings designed to provide income in retirement.
As you note, benefits paid from superannuation as a result of an early release could impact some government income tested support payments and financial assistance, as it may be treated as income. This includes the Child Care Subsidy, which, like most government payments, is income tested to ensure support is targeted to families with the greatest need. A family's Child Care Subsidy entitlement is based on their combined annual Adjusted Taxable Income, which includes both taxable income and non-wage related remuneration.
The inclusion of the early release of benefits paid from superannuation into an individual's taxable income is appropriate given that these amounts, like salary or wages, increase the amount of income or purchasing power at a person's disposal.
Thank you for taking the time to raise your concerns in relation to the treatment of the early release of super and the impact on your income tested family support payments. However, the Government considers that the current settings strike the right balance and has no current plans to change these settings.
Once again, thank you for taking the time to write.
Yours sincerely,
Ben Murphy
Director
Retirement Income and Tax Administration Branch
**Letter from the Health Minister's office**
Mr Andrew Ridgway
Dear Mr Ridgway,
Thank you for your correspondence of 6 December 2025 to the Minister for Health and Ageing and the Minister for Disability and the National Disability Insurance Scheme, the Hon Mark Butler MP, regarding the out-of-pocket expenses associated with private specialist treatment for your daughter. The Minister has asked me to respond on his behalf.
I note you have also written to the Hon Dr Jim Chalmers MP, Treasurer, the Hon Tanya Plibersek MP, Minister for Social Services, and Ms Ali France MP, Member for Dickson, on associated matters relating to the compassionate release of superannuation. Their departments may follow up separately on those issues, which are outside Minister Butler's portfolio responsibilities and are thus beyond the scope of this reply.
I acknowledge the financial impact of out-of-pocket medical expenses and the stress associated with the suffering of a family member. I trust your daughter is recovering well.
Private health insurance and out-of-pocket expenses
I note from your correspondence that you and your family have held private health insurance for some years. Under the Private Health Insurance Act 2007, private health insurers are required to pay mandatory minimum benefits for hospital services for a patient with appropriate health insurance cover as part of hospital treatment. These benefits include at least 25 per cent of the Medicare Benefits Schedule fee, minimum accommodation benefits and minimum benefits for medical devices. Medicare contributes to the cost of hospital treatment for private patients by covering the remaining portion of the Medicare Benefits Schedule fee. It means that if a doctor charges more than the Medicare Benefits Schedule fee, it can give rise to an out-of-pocket cost.
Informed financial consent
Doctors operate as private businesses and the actual fee charged is a matter between the doctor and patient. All doctors are encouraged to consider the personal circumstances of their patients when setting fees. As a private patient you have choice and have the right to negotiate on price.
The Good Medical Practice Code of Conduct, endorsed by the Medical Board of Australia, states that good medical practice involves doctors ensuring their patients are informed about the doctors' fees and charges. This is known as informed financial consent and is important to enable the patient to make a fully informed decision about treatment options. Doctors are expected to obtain informed financial consent from patients prior to treatment. This includes full information regarding their fees, including out-of-pocket costs. If you were not given this opportunity, you may wish to register a complaint with the Australian Health Practitioner Regulation Agency, who handle such complaints on behalf of the Medical Board.
Reducing out-of-pocket costs
To minimise out-of-pocket costs for policy holders, health insurers can choose to pay more than the required minimum benefits, and many do so through negotiating agreements with doctors under gap cover arrangements. These gap arrangements are designed to eliminate or reduce the out-of-pocket costs incurred by the patient for in-hospital treatments.
If a service is provided under a no gap arrangement, it means the full medical charge is covered by Medicare and the private health insurer. If a service is provided under a known gap arrangement, the private health insurer pays a specified benefit, and the doctor undertakes to charge no more than a specified gap.
Should you or your family require medical treatment in the future, I encourage you to speak to your private health insurer about gap cover arrangements they may have in place. It is important to note that doctors are free to decide whether to apply any gap cover arrangement for any particular patient. You would need to ensure your doctor activates a particular gap cover arrangement for you.
You may also wish to visit the Medical Costs Finder, which has been developed by the Government. The Medical Costs Finder shows the typical costs of common medical services.
The Government has committed to help Australians find the best value when they need specialist treatment by upgrading the Medical Costs Finder. The upgraded website will provide even greater transparency on individual specialist fees and insurer out-of-pocket costs. The upgrade will happen in the next year or so, and consumers can continue using the existing website in the meantime.
Thank you for writing on this matter.
Yours sincerely,
Jacqualine Myint
Director, Consumers Section
Private Health Strategy Branch
Department of Health, Disability and Ageing
2 February 2026
**Letter from the office of Ali France MP**
Thank you for your email. Ali appreciates you taking the time again to share your family's experience. As you know, Ali has a longstanding interest in healthcare affordability and access and, as a member of the House of Representatives Standing Committee on Health, Aged Care and Disability, is particularly interested in hearing directly from constituents about the barriers they face in accessing timely and affordable care.
Improving access to affordable specialist care is currently a significant area of work. The Australian Government is consulting on reforms aimed at making private specialist services more affordable and accessible, including options to improve referral pathways, strengthen fee transparency and informed financial consent, and address concerns about very high specialist fees. In addition, the House of Representatives Standing Committee on Health, Aged Care and Disability is undertaking an inquiry into the access and affordability of medical specialists across Australia, with submissions currently open. Please make sure to participate, as stories like yours are needed to be heard systemically as well.
The circumstances you have described reinforce why this work is so important. Hearing directly from families who have experienced significant financial pressure to access healthcare helps inform discussions about where improvements can be made.
In relation to compassionate release of superannuation, while Ali appreciates your concerns regarding the broader financial impact, and it is well noted in your correspondence to all levels, Ali understands that this does not address the wider concern you have raised about needing to access your retirement savings in the first place to obtain essential healthcare. Agreed, let us all work together to make sure health care is accessible to all, regardless of income.
Thank you again for taking the time to write and share your experience. Ali values hearing directly from constituents on these important issues and appreciates you bringing your perspective to her attention.
Kind regards,
Jill McKay
Chief of Staff

Binary file not shown.

Before

Width:  |  Height:  |  Size: 324 KiB

View File

@ -1,309 +0,0 @@
Title: PR Reviewer - A deployable AI reviewer for your Repos
Date: 2026-05-21 18:30
Modified: 2026-05-21 18:30
Category: DevOps
Tags: ai, code-review, automation, devops, open-source, ai_content, not_human_content
Slug: pr-reviewer-deployable-ai-reviewer
Authors: Andrew Ridgway... And Friends - glm-5.1.ai, nemotron-3-nano.ai, gemma4.ai, deepseek-v4-flash.ai
Summary: An indepth look at PR Reviewer, a selfhosted, LLMagnostic AI system that automates code, security and infrastructure reviews for any Git repository.
---
## Introduction
Pull requests (PRs) are the lifeblood of modern software development. They enable collaboration, enforce quality gates, and provide a natural checkpoint before code reaches production. Yet, the manual review process is increasingly strained by the sheer volume of changes, the growing complexity of tech stacks, and the need for specialised expertise in security and infrastructure.
Enter **PR Reviewer**, a locally deployable AIdriven review engine that brings automated, multidomain analysis to any repository. Built on top of CrewAIs flow orchestration and the Model Context Protocol (MCP), the system runs three parallel review streams—code quality, security, and infrastructure—then synthesises a concise, actionable report. It is deliberately LLMagnostic, supporting OpenAI, Anthropic, Ollama and any other provider that conforms to CrewAIs abstraction layer.
This article walks through the motivations behind PR Reviewer, its architectural choices, feature set, deployment pathways, and practical considerations for teams that want to augment their PR workflow with AI without surrendering control to a thirdparty SaaS.
## The case for AIaugmented PR reviews
### Scaling expertise
Traditional code reviews rely on senior engineers to spot antipatterns, security flaws, and deployment misconfigurations. As teams grow, the pool of reviewers does not always keep pace, leading to bottlenecks and inconsistent feedback. An AI reviewer can apply a consistent set of rules across every PR, ensuring that even junior contributors receive highquality guidance.
### Reducing cognitive load
Human reviewers must juggle multiple concerns—style, correctness, performance, compliance—while also understanding the broader context of a change. By offloading routine checks to an automated system, reviewers can focus on architectural decisions and nuanced tradeoffs that truly require human judgement.
### Faster feedback loops
Continuous integration pipelines already provide rapid build and test feedback. Adding an AI review step that runs in parallel with existing checks shortens the time between code submission and actionable feedback, encouraging a “shiftleft” mentality where problems are caught earlier.
### Vendorneutral flexibility
Many commercial AI review tools lock users into proprietary APIs and cloudonly deployments. PR Reviewers design deliberately avoids vendor lockin. By abstracting the LLM layer, teams can run the service onpremise, on a private cloud, or even on a modest workstation using a local model such as Ollama.
## Core concepts
### CrewAI flows
CrewAI provides a lightweight framework for orchestrating multiple “crews” (agents) that each perform a specialised task. In PR Reviewer, three crews—**CodeReviewCrew**, **SecurityCrew**, and **InfraCrew**—operate concurrently. Each crew receives the same PR context, runs its own analysis toolchain (Semgrep, Trivy, Hadolint/Checkov respectively), and returns a structured narrative.
### Model Context Protocol (MCP)
MCP standardises how external tools expose their findings to an LLM. Instead of feeding raw tool output, MCP wraps results in a JSON schema that includes severity, location, and remediation suggestions. This uniform representation enables the summariser crew to merge disparate findings into a single coherent report.
### Summariser crew
The final crew consumes the three domainspecific outputs and asks the LLM to produce a humanreadable summary. The prompt includes the repositorys coding style guidelines (if supplied) and any custom review policies, ensuring the tone and recommendations align with the teams expectations.
## Feature overview
| Feature | Description |
|---|---|
| **Code review** | Style, maintainability and bestpractice checks powered by Semgrep. |
| **Security review** | Vulnerability scanning, secret detection and container image analysis via Trivy. |
| **Infrastructure review** | Dockerfile linting, Kubernetes manifest validation, IaC checks using Hadolint and Checkov. |
| **Summarisation** | Consolidated, actionable report generated by an LLM. |
| **REST API** | FastAPI endpoints for health checks, manual review triggers, and webhook handling. |
| **Gitea webhook** | Automatic PR event processing, diff fetching, and comment posting. |
| **Dockerised** | Multistage build with all dependencies baked in. |
| **Kubernetes ready** | Helmcompatible manifests and CI pipeline for automated deployment. |
| **LLMagnostic** | Works with OpenAI, Anthropic, Ollama or any CrewAIcompatible provider. |
| **Configurable guidelines** | Override default review policies with repositoryspecific markdown files. |
## Architecture deep dive
At a high level, PR Reviewer follows a requestresponse pattern orchestrated by FastAPI. When a review request arrives—either via the `/api/v1/review` endpoint or a Gitea webhook—the service extracts the PR metadata, fetches the changed files, and constructs an MCPcompatible payload. This payload is then dispatched to the three review crews in parallel.
```
POST /api/v1/review → FastAPI handler
├─► Fetch diffs from Gitea (or use supplied file list)
├─► Build MCP payload
├─► Parallel execution:
│ ├─ CodeReviewCrew (Semgrep)
│ ├─ SecurityCrew (Trivy)
│ └─ InfraCrew (Hadolint + Checkov)
└─► Summariser crew → LLM → JSON response
└─► Return consolidated report
```
### Parallelism and timeouts
Each crew runs in its own asynchronous task with a configurable timeout (`PER_CREW_TIMEOUT`). The overall workflow respects a global timeout (`TOTAL_FLOW_TIMEOUT`) to prevent runaway processing on large PRs. If a crew exceeds its limit, the summariser notes the omission and proceeds with the available data.
### Data flow and persistence
PR Reviewer is deliberately stateless. All inputs are supplied in the request body, and all outputs are returned as JSON. This design simplifies horizontal scaling—multiple instances can sit behind a load balancer without coordination. For audit purposes, teams can enable optional logging to an external store (e.g., Elasticsearch) via environment variables.
## Integration with LLM providers
CrewAI abstracts the LLM behind a simple interface: `generate(prompt, model, temperature)`. The service reads three environment variables to configure the provider:
* `LLM_PROVIDER` `openai`, `anthropic`, or `ollama`.
* `LLM_MODEL` model identifier (e.g., `gpt-4`, `claude-3-sonnet`, `gemma4:31b-cloud`).
* `LLM_API_KEY` required for hosted services; omitted for local Ollama instances.
Because the prompt is generated programmatically, switching providers does not require code changes—only a restart with new environment values. This flexibility is crucial for teams that wish to experiment with emerging opensource models without rewriting integration logic.
## Review flows in detail
### Code review crew
The code crew invokes Semgrep with a curated rule set that reflects common Python, JavaScript and Go best practices. Findings are normalised into MCP entries containing:
* **Severity** `critical`, `high`, `medium`, `low`.
* **Location** file path and line range.
* **Message** concise description of the issue.
* **Remediation** suggested code change or reference to documentation.
If a repository supplies a custom `code_review.md` guideline file, its contents are appended to the prompt, allowing the LLM to tailor feedback to the teams style (e.g., preferring fstrings over `%` formatting).
### Security review crew
Security analysis runs Trivy in two modes: vulnerability scanning of any container images referenced in the PR, and filesystem scanning for secrets, misconfigurations, and known vulnerable dependencies. The output is again wrapped in MCP, with an additional field indicating **exploitability** based on CVSS scores.
### Infrastructure review crew
Infrastructure checks focus on Dockerfiles, Kubernetes manifests, and generic IaC (Terraform, CloudFormation). Hadolint validates Dockerfile best practices, while Checkov evaluates cloud resource definitions against industrystandard policies (e.g., CIS benchmarks). The crew also respects any `infra_review.md` file that may contain organisationspecific constraints such as mandatory resource limits.
### Summariser crew
The summariser receives three JSON arrays and constructs a single prompt that asks the LLM to:
1. Produce an executive summary of the overall health of the PR.
2. List the top5 findings across all domains, ordered by severity.
3. Provide actionable recommendations, grouped by domain.
4. Highlight any deviations from the repositorys own guidelines.
The result is a markdown document that can be posted directly as a PR comment, ensuring developers receive a readable, contextaware report without additional formatting steps.
## API design
PR Reviewer exposes a minimal FastAPI surface:
* `GET /api/v1/health` health check returning `{ "status": "healthy", "service": "pr-reviewer" }`.
* `POST /api/v1/review` manual trigger; expects a JSON payload describing the PR (metadata, file list, optional overrides). Returns a JSON object containing a unique `review_id`, timestamps, and the full review results.
* `POST /api/v1/gitea-webhook` endpoint for Gitea pullrequest events. Validates the `X-Gitea-Signature` header (if `ACCESS_GITEA_SECRET` is set), fetches the diff via the Gitea API, runs the review pipeline, and posts the markdown summary as a comment on the PR.
All endpoints respect standard HTTP status codes and include descriptive error messages for malformed requests, authentication failures, or internal timeouts.
## Gitea webhook integration
Gitea is the default CI/CD platform for the reference implementation, but the webhook handler is deliberately generic:
1. **Signature verification** HMACSHA256 using the secret configured in `ACCESS_GITEA_SECRET`. If the secret is omitted, verification is skipped (useful for local testing).
2. **Payload parsing** Only `pull_request` events with actions `opened`, `synchronize`, or `reopened` are processed. Other events are ignored to reduce noise.
3. **Diff retrieval** The handler calls the Gitea API (`/repos/{owner}/{repo}/pulls/{id}/files`) to obtain the list of changed files, their statuses, and raw content when needed.
4. **Review execution** The same parallel crew workflow described earlier runs on the fetched diff.
5. **Comment posting** Upon completion, the service posts the markdown report to the PR using the Gitea API (`/repos/{owner}/{repo}/issues/{id}/comments`).
### Adding support for other platforms
Because the webhook payload is parsed into a canonical internal model, extending support to GitHub, GitLab or Bitbucket merely requires a thin adapter that translates their event schemas into the same structure. The core review logic remains untouched, making crossplatform adoption straightforward.
## Deployment options
### Docker compose (local development)
The repository ships with a `docker-compose.yaml` that defines two services:
* `pr-reviewer` the FastAPI application.
* `ollama` (optional) a local LLM server for offline use.
Running `docker compose up` builds the multistage image, injects environment variables from `.env`, and exposes the API on `http://localhost:8000`.
### Kubernetes (production)
For production workloads, a Helm chart (or plain manifests in `kube/`) provides:
* A Deployment with configurable replica count.
* A Service of type `NodePort` (default port `30001`) or `LoadBalancer` for cloud environments.
* A Secret (`pr-reviewer-env`) that stores all `.env` values, including Gitea tokens and LLM credentials.
* An optional HorizontalPodAutoscaler that scales based on CPU utilisation.
The CI pipeline (`.gitea/workflows/build_push.yml`) automatically builds a multiarch Docker image, pushes it to the configured registry, and applies the Kubernetes manifests.
### Resource considerations
* **CPU** The LLM inference dominates CPU usage. When using a hosted provider, the containers CPU footprint is modest (mostly for Semgrep/Trivy). With a local model, allocate at least 4 vCPUs and 8GB RAM.
* **Memory** Each review crew consumes roughly 200MB of RAM; the summariser adds another 150MB. The total stays under 1GB for typical PR sizes.
* **Storage** The image size is ~1.2GB (including all scanning tools). Persistent storage is not required unless audit logging is enabled.
## Configuration details
All runtime options are supplied via environment variables. The most important groups are:
| Variable | Required? | Description |
|---|---|---|
| `LLM_PROVIDER` | Yes | `openai`, `anthropic`, or `ollama`. |
| `LLM_MODEL` | Yes | Model identifier (e.g., `gpt-4`). |
| `LLM_API_KEY` | Conditional | API key for hosted providers. |
| `ACCESS_GITEA_URL` | Yes | Base URL of the Gitea instance. |
| `ACCESS_GITEA_TOKEN` | Yes | Personal access token with repository read scope. |
| `ACCESS_GITEA_SECRET` | No | Webhook secret for HMAC verification. |
| `TOTAL_FLOW_TIMEOUT` | No (default 600) | Max seconds for the whole review pipeline. |
| `PER_CREW_TIMEOUT` | No (default 300) | Max seconds per individual crew. |
| `LOG_LEVEL` | No (default `INFO`) | Python logging verbosity. |
Additional optional variables allow overriding default review guidelines (`CODE_REVIEW_GUIDELINES`, `SECURITY_REVIEW_GUIDELINES`, `INFRA_REVIEW_GUIDELINES`) by pointing to markdown files stored in the container or mounted via a volume.
## Operational considerations
### Monitoring
FastAPIs builtin metrics can be exposed via `/metrics` (Prometheus format). Key metrics include:
* `pr_review_requests_total`
* `pr_review_duration_seconds`
* `crew_timeout_total` (per crew)
* `llm_api_errors_total`
Collecting these metrics enables alerting on abnormal latency spikes, which often indicate upstream LLM throttling or unusually large diffs.
### Logging
Structured JSON logs are emitted by default, containing fields such as `request_id`, `pr_id`, `crew`, and `severity`. When integrated with a log aggregation platform (e.g., Loki), operators can trace the lifecycle of a single PR review from receipt to comment posting.
### Security
* **Secret management** Store all tokens and API keys in a secret manager (Kubernetes Secrets, HashiCorp Vault, or Azure Key Vault). Never commit `.env` files to source control.
* **Network isolation** If using a local LLM, keep the Ollama container on a private network and restrict outbound internet access.
* **Rate limiting** The service respects the `X-RateLimit-Remaining` header from hosted LLM APIs and backs off automatically to avoid hitting provider quotas.
## Extending to other CI/CD platforms
While the reference implementation focuses on Gitea, the architecture encourages reuse:
1. **Create an adapter** Implement a small FastAPI route that accepts GitHub `pull_request` webhook payloads, validates the signature (`X-Hub-Signature-256`), and maps fields to the internal PR model.
2. **Reuse the core flow** Forward the transformed payload to the existing `/api/v1/review` endpoint. No changes to the review crews are required.
3. **Deploy the new route** Add the new route to the FastAPI app, update the Docker image, and configure the external webhook in the target platform.
Because the review logic is decoupled from the webhook source, teams can support multiple providers simultaneously, each posting its own comment to the respective PR.
## Development workflow
Contributors who wish to enhance PR Reviewer can follow these steps:
```bash
# Clone the repository
git clone https://git.aridgwayweb.com/armistace/pr_reviewer.git
cd pr_reviewer
# Install development dependencies
uv pip install -e ".[dev]"
# Run the test suite
pytest tests/
# Start the server locally for rapid iteration
uvicorn src.pr_reviewer.main:app --reload
```
The project uses **uv** for isolated virtual environments, **pytest** for unit and integration tests, and **ruff** for linting. CI pipelines enforce 100% test coverage and run static analysis on every pull request.
### Adding a new review tool
To incorporate an additional analysis tool (e.g., a custom static analyser), developers should:
1. Write a thin wrapper that converts the tools output into the MCP schema.
2. Register a new crew in `crews/` that invokes the wrapper.
3. Update the orchestration flow (`flow.py`) to include the new crew in the parallel execution block.
4. Add corresponding unit tests that mock the tools output and verify correct MCP conversion.
## Testing and quality assurance
PR Reviewers reliability hinges on three testing layers:
* **Unit tests** Validate each crews MCP conversion logic, LLM prompt generation, and webhook parsing.
* **Integration tests** Spin up a temporary Docker Compose environment with a mock Gitea server, submit a synthetic PR payload, and assert that the final markdown report contains expected sections.
* **Endtoend tests** Deploy the Helm chart to a disposable Kubernetes namespace, trigger a real Gitea webhook, and verify that the comment appears on the PR with correct formatting.
All tests run in CI on every push, and failures block merges.
## Community and contributions
The project is deliberately opensource, hosted on a selfmanaged Gitea instance. Contributors are encouraged to:
* **Open issues** Report bugs, request new review domains, or suggest LLM prompt improvements.
* **Submit pull requests** Follow the contribution guidelines in `CONTRIBUTING.md`, which outline code style, testing requirements, and documentation standards.
* **Share custom guidelines** Teams can publish repositoryspecific markdown files (e.g., `code_review.md`) that the summariser will automatically honour.
Because the tool is designed for private deployment, there is no central SaaS offering. Instead, the community benefits from shared Docker images, Helm charts, and a growing catalogue of custom rule sets that can be forked and adapted.
## Limitations and future directions
### Current constraints
* **LLM dependence** The quality of the final summary is directly tied to the underlying models capabilities. Lowcapacity models may produce vague recommendations.
* **Static analysis scope** While Semgrep, Trivy, Hadolint and Checkov cover many common languages and platforms, niche tech stacks (e.g., Rust, Terraform Cloud) require additional adapters.
* **No builtin CI/CD orchestration** PR Reviewer focuses on the review step; it does not enforce merge policies or gate deployments. Teams must integrate the API into their existing pipelines.
### Planned enhancements
1. **Modelagnostic prompt optimisation** Research into dynamic prompt templates that adapt to the strengths of each LLM provider.
2. **Feedback loop** Capture developer reactions to the AI suggestions (e.g., thumbs up/down) and use them to finetune future prompts.
3. **Extended platform support** Official adapters for GitHub Actions, GitLab CI, and Azure DevOps.
4. **Cache layer** Introduce a Redisbacked cache for repeated scans of unchanged files, reducing compute cost on large monorepos.
5. **Policy as code** Allow organisations to define review policies in a declarative YAML format that the summariser can reference, enabling compliancefirst workflows.
## Conclusion
PR Reviewer demonstrates that AIdriven code quality, security, and infrastructure analysis can be delivered as a selfhosted, vendorneutral service without sacrificing flexibility or control. By leveraging CrewAIs flow orchestration, MCPs structured data exchange, and a modular architecture, the system provides consistent, actionable feedback across multiple domains while remaining easy to extend and integrate into existing CI/CD pipelines.
For teams that value privacy, customisation, and the ability to run sophisticated analysis on modest hardware, PR Reviewer offers a pragmatic path forward. The opensource nature invites collaboration, and the clear separation between tooling, LLM inference and summarisation ensures that future improvements—whether in scanning capabilities or language model performance—can be adopted with minimal friction.
Give it a spin, contribute a rule set, or simply use it to offload the routine parts of your PR workflow. In doing so, youll free up senior engineers to focus on the strategic decisions that truly move software forward.

View File

@ -6,7 +6,7 @@ SITENAME = "Andrew Ridgway's Blog"
SITEURL = 'https://blog.aridgwayweb.com'
THEME = 'themes/cleanblog'
PATH = 'content'
HEADER_COVER = 'https://blog.aridgwayweb.com/images/Tech-Desktop-Wallpaper-35697.jpg'
HEADER_COVER = 'https://wallpaperaccess.com/full/3239444.jpg'
TIMEZONE = 'Australia/Brisbane'
COLOR_SCHEME_CSS = 'tomorrow.css'
DEFAULT_LANG = 'en'

Binary file not shown.

Before

Width:  |  Height:  |  Size: 2.8 MiB

View File

@ -33,7 +33,7 @@
{% if article.header_cover %}
<header class="intro-header" style="background-image: url('{{ article.header_cover }}')">
{% else %}
<header class="intro-header" style="background-image: url('{{ SITEURL }}/{{ THEME_STATIC_DIR }}/images/post-bg.png')">
<header class="intro-header" style="background-image: url('{{ SITEURL }}/{{ THEME_STATIC_DIR }}/images/post-bg.jpg')">
{% endif %}
<div class="container">
<div class="row">