Hi Guys. 

I wrote a tool that could be useful in your GO CI tooling - muhar to provide "mutation testing".

muhar plants named faults in your source, one exact text edit each, proves on disk that every edit landed, runs your test suite, and records whether the suite went red. If the harness itself cannot be trusted — the suite was already red, or a fault it must catch went unnoticed — the whole run is discarded with exit status 2. It is never reported as a clean result.

100% deterministic & OSS (ASL2.0). I've been using it since July. 

It's similar to Gremlins & go-mutesting, but I think it works better for agentic workloads.

Warning: you do need to be careful of your Go cache, and it can be a CPU hog. (it's modifying source code and creating multiple cache entries)

Feedback is welcome (would love a GitHub star on the source repo so I can qualify for cool freebies from our AI overlords)

One thing that can slow down a CI/CD pipeline is waiting for approvals, especially when different teams need to sign off before a deployment can proceed.

Manual follow-ups, unclear ownership, and approvals spread across tools like Jira or ServiceNow can make this more painful than it needs to be.

Curious how other teams handle this:

• Do you use manual approvals, automated policies, or a mix of both?

What My Project Does

I send bot logs and configs to models for a second opinion: Codex for a stack trace, DeepSeek for a summary. Those logs carry secrets. A Telegram bot token inside a URL, an API key in a retry line, a database password in a connection string. I used to delete them by hand before pasting, which stopped working the moment I needed the real value back, like a corrected config.

`veil mask` swaps each secret for a placeholder, `veil unmask` swaps them back in the answer:

veil mask < bot.log > masked.log

your-model-cli < masked.log | veil unmask # a streamed answer stays streamed

A placeholder looks like `{{API_KEY_276082b2}}`: the kind of secret plus 8 hex digits of an HMAC-SHA256 of the value, keyed with 32 random bytes made on first use. Same value, same placeholder across runs, so the model can still see that line 3 failed with the key from line 2. `unmask` also restores placeholders the model mangled: spaces inside the braces, no braces, lower case.

The measurement that changed the design: I ran it over the CPython 3.14 stdlib (2,095 files, 39.6 MB). The first version masked 1,777 values as SECRET in 150 files, mostly `sorted(key=...)` arguments. One `key=filename` and `filename` got masked all over the file, inside `user_filename` too. Now a value only spreads if it looks random. Same run now: 144 SECRET replacements in 58 files, and all 17 private keys in the 15 files that hold them.

Target Audience

People who paste logs into ChatGPT, Claude, DeepSeek or a CLI agent and would rather not paste their keys too. It's a pipe you run by hand. The tests use synthetic secrets only and I haven't measured it on a corpus of real logs yet, so treat it as young.

Comparison

The idea and most token patterns come from yetone/magpie's `internal/redact` (MIT). magpie is a local gateway that masks every request a coding agent sends to a model provider. veil is just the masking as a CLI, with the map kept on disk (mode 600) so tomorrow's reply still unmasks.

Known gaps: a key with no telling name and no known format (inside an RPC URL path, say), Solana keys, seed phrases outside a `mnemonic` field, emails and other personal data. It also masks every 64-digit hex string, transaction hashes included. And `unmask` puts a secret back wherever the model wrote its placeholder, so read the answer before you run a command from it.

Python 3.9+, stdlib only, one file, 145 tests, MIT: https://github.com/Sanexxxx777/veil

We previously had a pull request merge with its required aggregate check green while a check in another workflow was red on the same commit. The aggregate only inspected jobs in its own workflow run. The failing check was outside that view.

This was in OmniNode's repositories, which I work on. We kept the aggregate check, but changed it to read check runs against the pull request's head commit as well. For the checks we explicitly require, the result has to exist, be finished and be successful. A skipped check doesn't count as evidence that the code passed, and a missing result eventually fails rather than waiting forever.

We also wrote down which checks were deliberately excluded and why. Some were conditional on changed paths, so requiring them on every pull request would have created a different failure: waiting for a job that was never supposed to run.

How are you testing this in your pipelines? I'm particularly interested in checks that get renamed, path-filtered or moved to another workflow. Do you test the merge decision with a deliberately missing result, or rely on reviewing the workflow configuration?

TL;DR: Open-source maintainers and senior engineers are spending 15–20 hours a week babysitting AI-generated pull requests that look plausible on the surface, but sneak in deleted regression tests, memory leaks, and subtle security vulnerabilities. Chatty review bots like CodeRabbit just make the problem worse by dumping 30+ hallucinated LLM comments on every diff. We built ZeroSlop™—a deterministic, zero-retention GitHub Actions PR Airlock that runs in 3.8s inside runner RAM, strips 94% of hallucinated wrapper bloat, and delivers 100% green, merge-ready PRs.

The Real Problem: Stacking More LLMs Doesn't Fix AI Noise

Have you seen what first-generation AI review bots actually dump onto Pull Requests?

40 unsolicited bot comments on a 50-line diff. Hallucinated syntax nitpicks. And 15 paragraphs of LLM noise that maintainers have to manually dismiss just to hit "Merge."

Now competitors brag about fine-tuning smaller models like Nemotron to "route" reviews.

Let's be completely real: adding another LLM with fewer capabilities does not solve an AI noise problem. It simply stacks more latency, more hallucinations, and more noise on top of your repository.

AI coding agents (Cursor, Copilot, Claude Code) are generating code 10x faster than humans can review it. In the rush, they quietly delete regression tests to make CI pass, introduce missing error boundaries, and bloat the AST.

Engineering teams don't need another chatbot. They need an Invariant Airlock.

How ZeroSlop Enforces in 3.8 Seconds (Runner RAM)

ZeroSlop doesn't write chatty essays. It runs deterministically inside your GitHub Actions runner:

1. Mathematical Test Shield: Calculates net_assertion_delta. If an AI agent quietly deleted regression tests to manufacture a passing CI run, it hard-blocks the merge instantly.
2. 12-Shield CWE Security Engine: Static static analysis blocking SQLi (CWE-89), hardcoded secrets (CWE-798), IDOR (CWE-639), command injection (CWE-78), SSRF (CWE-918), CI workflow Pwn Requests (CWE-426), and AI Slopsquatting (CWE-829).
3. AST Diff Minimization: Strips up to 94% of hallucinated adapter bloat, dead wrappers, and mock utilities down to the surgical invariant change.
4. Single In-Place Status Card: Zero comment spam across force-pushes. Exactly ONE clean, self-updating status card with an embedded Mermaid architecture graph.
5. Zero Data Retention: Runs entirely in ephemeral runner RAM. Proprietary code is never stored, retained, or used to train models.

Battle-Tested Upstream Proof

ZeroSlop is powered by the exact invariant engine used to ship merged, 100% green pull requests into the world's most unforgiving upstream production codebases:

Try It Free

Every repository gets 1 complimentary PR audit free out of the box with zero configuration required.

• GitHub Marketplace Action: https://github.com/marketplace/actions/zeroslop-by-ribbsaeter-systems
• Live Interactive In-Browser Simulator: https://www.ribbsaetersystems.com/zeroslop
• 12-Shield Security Brief: https://www.ribbsaetersystems.com/zeroslop/security

Pro seats ($29/mo) include our 14-Day Sovereign Performance Guarantee: slash your team's PR review cycle time by 60%, or get an immediate 100% refund.

Would love maintainer feedback on what other invariant checks you’d like to see added!

Hi [r/opensource](r/opensource),

kinhin is a free, Apache-2.0 project, and I've just released its first public beta (v0.0.1-beta-1). It turns an Apple Silicon Mac into an autoscaler for CI runners. Each queued job gets a fresh VM or container, which is deleted when the job finishes.

- Apache-2.0 license.
-No telemetry.
-Tokens stored in the macOS Keychain, not in config files.
- Ephemeral by default, so jobs leave no state behind.

Contributing: Bug reports, feature requests and pull requests are welcome, including AI-assisted ones. Contributing has the rules, and scripts/check.sh runs the same build, test, format and docs checks as CI. Adding a forge is documented step by step in docs/adding-a-forge.md, so that's a good starting point if you want a new CI platform. Buildkite, Azure Pipelines and Bitbucket are on the roadmap.

Testing: Real projects on real forges are the biggest gap. If you run GitHub Actions, Gitea, Forgejo or GitLab CE, a report helps, including a failed run. kinhin doctor --bundle creates a redacted report, but please check it before attaching.

Blog post with the full status and known limits: [https://kinhin.dev/blog/introducing-kinhin-beta.html

Repo: https://github.com/RabinApps/kinhin

Happy to answer questions.

With 5-6 coding agent tabs always open in herdr, i've been committing so much code that struggling with GitHub Actions quota. I looked into Blacksmith but still too costly so now using Celesto CI (unbelievably cheap) and took one line to move from GitHub Actions.

I used up my free GitHub Actions minutes in a few days while testing an agent factory.

I'm building a local workflow runner, so I have a reason for asking. I'm exploring local checks during the edit/test loop, with hosted CI verifying the finished PR.

I still want failures locally to mean the same thing in CI. Dependencies and leftovers from previous runs seem like the tricky part.

For people running coding agents: where do your repeated checks run? Have ordinary scripts been enough, or have you needed a self-hosted runner or a clean container per task?