标签：#code

Nobody has ever asked you to upstream your dotfiles. For thirty years that was the deal with every tool we touched: if you didn't like it, you changed it, and the change lived with you. Then the tools started writing the code, and the deal quietly ended. This essay is about why the deal is back on the table. Because the thing that used to make forking expensive — the labour — is exactly what agents just made cheap. In This Article The Workbench Instinct Then the Harness Era Arrived Forking Was Always the Escape Hatch Code Got Cheap What I Shipped Into My Fork A Feature Does Not Have to Be Useful Your Desire Is the Limit The Fork Is the Destination Now the Discipline Part Bring Back the Joy The Workbench Instinct Show me a developer who has never touched their config and I'll show you someone who hasn't started yet. Vim users brag about their init.lua the way woodworkers talk about a hand plane they've had for twenty years. Emacs people wrote a whole operating system inside a text editor because they could. VS Code won partly because it shipped an extension API and got out of the way. Dotfiles repos are public artifacts, starred and forked, because the setup is part of the craft. This isn't productivity theatre. Some of it is genuine need, some of it is fixing a specific annoyance that only you have, and a lot of it is just fun. All three are valid. The workbench is where the joy lives — and nobody ever waited for permission to alias a command. Then the Harness Era Arrived Then agentic coding tools showed up and quietly changed the shape of the deal. The best-in-class agent harnesses are increasingly vendor-controlled. Claude Code is a product, not a repo you can clone and rebuild. Google announced it's retiring Gemini CLI in favour of a closed-source successor. And note where the line falls: Codex CLI is Apache-2.0 and sitting right there on GitHub, but the Codex desktop app — the thing most people actually click on — is not. The terminal stayed open. The interface

Opus 5 runs at 5 and 25 per million tokens against Fable 5 at 10 and 50, so the top tier now costs double for a much smaller gap Thinking is on by default on Opus 5, which silently changes what a tight max_tokens setting does to your output Disabling thinking now returns an error above high effort, so any xhigh or max route that turns it off needs an audit before you migrate Prompt caching starts at 512 tokens on Opus 5, half the Opus 4.8 floor, so short reusable prompts cache with no code change In June I worked through whether Claude Fable 5 was worth double the price of Opus 4.8 and concluded that it usually was, for hard work. Claude Opus 5 landed on July 24 at Opus 4.8's exact price and closed most of that gap. So the answer changed, and a few of the changes will throw errors in code that worked last week. The Price Gap Held, the Capability Gap Closed Opus 5 costs 5 and 25 per million tokens, input and output. That is identical to Opus 4.8 and exactly half of Fable 5 at 10 and 50. Anthropic did not raise the sticker price on the tier it improved, which is the single most consequential fact in this release. What that buys, on the numbers: 79.2 percent on SWE-bench Pro against Fable 5's 80.3, and a CursorBench 3.2 result Anthropic describes as landing within 0.5 percent of Fable 5's peak at max effort, at half the cost per task. On OSWorld 2.0 it goes past Fable 5's best computer-use result at just over a third of the cost. A 1.1 point deficit on the headline coding row, for half the money. Last month the equivalent comparison had an 11 point spread. That is what actually changed, and it flips the default: Fable 5 used to be the reasonable choice for anything hard, and now it has to argue for itself on each task. There is a quieter cost lever too. The minimum cacheable prompt on Opus 5 is 512 tokens, down from 1024 on Opus 4.8. Prompts I had written off as too short to cache now create entries with no code change at all. If you run a lot of small repeated calls,

Three labs shipped flagship models in fifteen days: GPT-5.6 Sol on July 9, Kimi K3 on July 16, Claude Opus 5 on July 24 Opus 5 leads SWE-bench Pro 79.2 to 64.6 over Sol, and ARC-AGI-3 30.2 to 7.8 Sol holds Terminal-Bench 2.1 at 91.9 percent in its top mode and still takes DeepSWE 1.1 and HealthBench Professional Kimi K3 is a 2.8 trillion parameter open-weight model at 3 and 15 per million tokens, roughly 40 percent under Opus 5 on input Fifteen days. That is the gap between OpenAI making GPT-5.6 Sol generally available and Anthropic shipping Claude Opus 5, with Moonshot dropping a 2.8 trillion parameter open-weight model in the middle of it. I wrote a frontier check like this in June and most of it is already out of date, so here is where the three current flagships actually stand. Three Flagships in Fifteen Days Model Lab GA Context Per million (in / out) GPT-5.6 Sol OpenAI 2026-07-09 1.05M 5 / 30 Kimi K3 Moonshot AI 2026-07-16 1M 3 / 15 Claude Opus 5 Anthropic 2026-07-24 1M 5 / 25 The specs have converged to the point where they barely differentiate anything. All three sit at or just above a million tokens of context. All three cap output around 128k. The input prices are within a factor of two of each other. Two years ago a context window was a headline; now it is table stakes, and the interesting differences have moved entirely into behavior under load. Two timing details that get flattened in the coverage. GPT-5.6 Sol was previewed on June 26 and only became generally available on July 9, so some of the earliest benchmark tables were run against a preview build. And Sol is the top of a three-model family alongside Terra and Luna, spanning roughly 1 to 30 per million tokens depending on tier. Comparing Opus 5 to "GPT-5.6" without saying which one is close to meaningless, which is a large share of the comparisons currently circulating. One structural note on Kimi K3, because the parameter count gets quoted carelessly. It is a mixture-of-experts model with 896 exp

JFrog Security Research revealed "PixelSmash," a vulnerability in the FFmpeg media framework, allowing for Remote Code Execution and Denial of Service attacks. Present for sixteen years, it affects numerous applications using the MagicYUV decoder. Exploitation requires only a crafted media file. Users are advised to check for the vulnerability and apply patches or disable the decoder if necessary. By Olimpiu Pop

Opus 5 posts 79.2 percent on SWE-bench Pro against Opus 4.8 at 69.2, a 10 point jump with no change in per-token price Anthropic published most gains as ratios (three times ARC-AGI-3, more than double Frontier-Bench) rather than absolute scores On CursorBench 3.2 at max effort it lands within 0.5 percent of Fable 5's peak at half the cost per task Public GDPval-AA figures disagree across sources by up to 117 Elo, so I left that row out entirely Anthropic shipped Claude Opus 5 on July 24, and the coverage filled up with ratios instead of scores. Three times the next-best model. More than double the previous Opus. Just over a third of the cost. I went looking for the actual numbers behind those phrases. What I found says as much about how model launches get reported as it does about the model. The Numbers That Are Actually Comparable The cleanest row is SWE-bench Pro, which runs a model against real GitHub issues and checks whether the patch passes the repository's own tests. It is harder than the older SWE-bench Verified set and it is the row the whole industry now quotes. Model SWE-bench Pro Released Claude Fable 5 80.3 2026-06-09 Claude Opus 5 79.2 2026-07-24 Claude Opus 4.8 69.2 2026-05-29 GPT-5.6 Sol 64.6 2026-07-09 That is a 10 point jump from Opus 4.8 to Opus 5 inside two months, and the per-token price did not move (both tiers run at 5 and 25 per million tokens). Fable 5 keeps a 1.1 point lead and charges double for it. Those two facts together are the actual story of this release, and neither one is a ratio. On SWE-bench Verified, the older and easier set, Opus 5 reports 96.0 percent averaged over five trials. The averaging matters. A single run on a set that saturated above 90 percent tells you very little, because the spread between runs starts to rival the gap between models. Five trials is better practice than most launch tables bother with, and it is worth noticing when a lab does it. It is worth being precise about why those two rows behave differently,

I have shipped five small tools this year instead of one big product, Git Dojo, OhNine, Statusline Builder, Claude Blueprint, and RAXXO Studio Each tool solves exactly one problem and stops there, no feature creep, no internal roadmap fights Shipping small forces me to finish things, a habit a single sprawling product lets me avoid indefinitely The pattern only holds because every tool has to earn its own attention, nothing rides on the others The Big Product I Never Shipped For a long stretch, I was building one big thing. Not a specific product I can point to and describe, more a habit of scope. Every idea got folded into the same growing plan, another tab, another settings panel, another "while I'm in there" addition. It felt productive because I was always working on something. It was not productive, because nothing ever crossed the finish line. A plan that keeps absorbing new ideas is not a plan, it is a place where finished work goes to become unfinished work again. The turn came when I noticed how differently I treated small, contained pieces of work. When I sat down to fix one specific annoyance, something with a clear edge around it, I finished. When I sat down to "work on the platform," I drifted. The difference was not effort or time, it was shape. A bounded problem has a visible end. An unbounded one does not, so there is always a reason to keep going instead of stopping and calling it done. That observation is the entire reason Git Dojo, OhNine, Statusline Builder, Claude Blueprint, and RAXXO Studio exist as five separate things instead of five tabs inside one dashboard. Each one started as an itch I could describe in a single sentence. OhNine started as "I want a warning before I hit my Claude limit, not after." Statusline Builder started as "configuring a statusline should not require editing JSON by hand." Git Dojo started as "I want to practice real git commands somewhere the mistakes cost nothing." None of those sentences needed a second paragraph

Anthropic shipped Claude Opus 5 on July 24, calling it a step-change over Opus 4.8, not a routine bump The model runs a 1M token context window as both default and maximum, 128k max output tokens, with thinking on by default Anthropic says it approaches Fable 5 intelligence at roughly half the price, with per-token pricing unchanged from Opus 4.8 It shipped everywhere at once, the Claude API, AWS, Google Cloud, and Microsoft Foundry, and is now the default Opus model in Claude Code What Anthropic Actually Shipped On July 24, Anthropic released Claude Opus 5, and the framing in its own documentation is unusually direct about what kind of release this is. Anthropic calls it a step-change improvement over Claude Opus 4.8, not an incremental one, and says the largest gains land in deep reasoning, agentic coding and long-horizon tasks, and test-time compute scaling. That is a specific claim, not marketing language, and it matches how the model is positioned everywhere else in the announcement: as a model built to stay on task across long tool-use loops rather than one built to win a single benchmark screenshot. The capability list is long and mostly practical. Anthropic highlights better code review and bug-finding, with a high hit rate on real bugs and few false positives, holding up even at lower effort levels. It highlights vision improvements, reading charts, documents, and diagrams, and replicating UI and frontend visuals when the model has tools to crop and check its own work. It highlights office and document tasks, generating multi-sheet spreadsheets with real formulas and structured slide decks, and multi-agent coordination, running teams of subagents with writer-verifier patterns and fewer cases of agents stepping on each other's output. What stands out is that this is not a model pitched as a smarter chat assistant. Every capability on the list points at the same audience: people running Claude inside an agent loop, a coding session, or a multi-step workflow,

Your Claude Code setup doesn't break in one dramatic moment — it degrades a few bytes at a time, and by the time you notice, you've been paying a context tax for weeks. In a previous post I covered running an unattended daily health check with launchd. This one is the follow-up: a three-layer loop that detects that quiet degradation weekly and hands the repair job to claude -p itself. The problem: environments rot quietly if you leave them alone Some things in a Claude Code environment grow just from doing your normal work. ~/.claude/rules/ and MEMORY.md keep getting appended to, until context injection quietly crosses 40KB Experimental agent definition .md files never get archived, leaving dozens to nearly a hundred files under ~/.claude/agents/ permanently loaded Stop hooks fire over and over, creating a hook spam condition Frustration-signaling words pile up in conversation logs and nobody notices A performance audit on 2026-07-11 revealed that "agents I thought I'd archived were still being injected — 99 of them," and that turned out to be the main cause of the degraded experience. That led to the question "so do I have to go check this every week myself?" — and the answer was to automate it , which is what cc-self-audit.sh does. Five degradation metrics and their thresholds The script measures five metrics and flags "red" when any of them crosses its threshold. # 閾値（env変数で上書き可） TH_INJECT_BYTES = " ${ SELF_AUDIT_TH_INJECT :- 40000 } " # rules+CLAUDE.md+MEMORY.md 合計バイト TH_AGENTS = " ${ SELF_AUDIT_TH_AGENTS :- 60 } " # ~/.claude/agents 配下 .md 総数（再帰） TH_STOPSPAM = " ${ SELF_AUDIT_TH_STOPSPAM :- 15 } " # 監査hook発火/週 TH_FRUSTRATION = " ${ SELF_AUDIT_TH_FRUST :- 8 } " # 不満ワード/週 TH_TOOLERR = " ${ SELF_AUDIT_TH_TOOLERR :- 400 } " # tool失敗/週 The first three are static metrics (state at this exact moment); the last two are dynamic metrics (trends since the previous run). That distinction maps directly onto how each one is measured, as described below. Overall design: a thr

"You're spawning a fresh codex exec for every single call? Just run the app-server and reuse a thread. The prompt cache alone will pay for it." That sentence sounds so obviously right that nobody ever benchmarks it. We run a small bazaar of headless AI daemons — designers, reviewers, code workers — and each one shells out to OpenAI's Codex CLI dozens of times per work item. A resident codex app-server --stdio with warm threads looked like free money. We measured it four times. The prompt cache eventually hit 86% on the turns that mattered. The pipeline got slower than the boring baseline, and 39% more expensive in raw tokens. This is the story of why, and of what app-server is actually for. The setup was deliberately minimal: no resident daemon, no pool. The server is spawned privately for one formation , runs its turns, and is killed by a context manager on the way out — success or crash. That keeps the comparison honest: same lifecycle as a subprocess, and adopting it stays a measurement problem instead of an architecture debate. Trusting the probe Before writing any integration, we cloned the actual openai/codex source and pointed a probe at a real app-server: handshake, per-turn sandbox overrides, interrupts, forks, kill-and-resume. Eight checks, all green, plus three findings you won't find in any docs: cwd and sandboxPolicy are sticky when omitted — every turn must re-state them explicitly, or turn 3 silently inherits turn 2's write access. Token usage arrives on thread/tokenUsage/updated , not on turn/completed . An empty thread that never ran a turn is never materialized — you cannot resume it later. Pre-warming a thread pool is a trap. And the seductive one: on the probe's trivial two-turn thread, turn 2 reported 15,104 cached input tokens . See? The cache works. Ship it. That number cost us three more measurement runs to un-believe. The four runs Same fixture repo, same greenfield request, one real four-stage formation each: A: codex exec (baseline) B: app

int(os.environ.get("PORT", "8080")) fails constantly in ways that waste your time: ValueError: invalid literal for int() with base 10: 'abc' . No variable name. No hint about what a valid value looks like. You grep the codebase for PORT to even find where the read happened. specenv is a zero-runtime-dependency Python library for typed environment variable loading — casting, validation, schema grouping, prefix namespacing. All of that is useful, but none of it is the actual design decision worth writing about. The decision that shaped everything else was: every error must name the variable and say how to fix it, unconditionally, with no opt-out. Decision 1: The error message is generated at the failure site, not templated afterward It would be easy to build one generic EnvCastError(var_name, raw_value, target_type) and format a message from those three fields in __str__ . specenv doesn't do that — each cast failure builds its own message inline, at the point where the specific failure is known: if cast_type is int : try : return int ( raw ) except ValueError : raise EnvCastError ( f ' Cannot cast { name } = { raw !r} to int. \n ' f ' → Set { name } to a valid integer (e.g. { name } =8080) ' ) from None if cast_type is bool : ... raise EnvCastError ( f ' Cannot cast { name } = { raw !r} to bool. \n ' f ' → Set { name } to one of: 1/0, true/false, yes/no, on/off ' ) The generic version would produce "Cannot cast PORT='abc' to int" and stop there. The inline version gets to add (e.g. PORT=8080) for ints, 1/0, true/false, yes/no, on/off for bools, a namespaced hint for prefixed variables — because at the point of failure, you know exactly what a correct value looks like for that type, and a generic formatter three calls up the stack doesn't. The cost is a few lines of duplication across _caster.py 's type branches. That's a fair trade for every single error message being genuinely actionable instead of generically accurate. Decision 2: Missing-and-required collapses to t

Disclosure: This post includes affiliate links; I may receive compensation if you purchase products or services from the different links provided in this article. Credit: codemia.io Hello Devs, if you're preparing for software engineering interviews, particularly in MAANG, you already know that Data Structures & Algorithms (DSA) and System Design are two key areas where you will be rigorously tested. While LeetCode is the go-to platform for DSA, system design has always been a challenge. While there are many websites and platforms to prepare for System Design Interviews like ByteByteGo , DesignGurus.io , Exponent , Educative , and Udemy , there is nothing like LeetCode. These are great resources to learn fundamentals, go through case studies, and understand the theory part of system design, but LeetCode-style practice is one thing that is missing - until now. I recently found Codemia.io , and I must say, it feels like the LeetCode for System Design. If you've struggled with structuring your system design answers, getting real feedback, or knowing whether your approach is correct, Codemia.io is a game-changer. They not only have the biggest collection of System Design and OOP Design problems for practice, but they also have a free System Design course called Tackling System Design Interview Problems , which is a great free resource to learn essential System Design concepts. It's a short course with 2 hours of content, but it's powerful and also has quizzes to test your skills. Here are all the key System Design topics you can learn on this free course: Now, let's check out how Codemia.io can help you to prepare better for your System design and OOP Design interview, and why I think it's like Leetcode for System design. Most system design resources today are long, text-heavy articles or expensive courses. The problem? No hands-on practice - Reading about system design isn't enough; you need to actively design solutions. No structured progression --- Unlike DSA, where

OpenAI's fancy new AI keypad will be a lot of fun for some, while many others are probably not going to touch it.

In my previous post, Monitoring Claude Code hook watchdogs with launchd , I set up liveness monitoring for hooks — and immediately ran into the next question: a healthy hook means nothing if the product behind it is down. What I really wanted was a single page I could skim in five minutes every morning and know that everything is fine. That page is daily-brief.sh . launchd runs it three times a day (8:00, 10:30, and at login), and it compiles production HTTP probes, hook latency p95, launchd exit codes, 7-day API costs broken down by model, and per-project git status into one Markdown file appended to Obsidian. The problem: checking five places by hand every morning The more you automate, the higher the risk that something breaks silently. I used to open all of these manually every morning: The Vercel dashboard (production liveness) launchctl logs (scheduled job failures) Claude Code cost usage git status for each project The hook latency JSONL Just opening them took 3–5 minutes. Two incidents slipped through unnoticed (2026-06-11: GitHub Scout silently going blank, and a server configuration error in the autolike license API). Consolidating everything into one automatically delivered page makes missing things physically impossible. Overall design: 3 triggers → 1 Markdown file → append to Obsidian launchd ├─ StartCalendarInterval: 8:00 ├─ StartCalendarInterval: 10:30 └─ RunAtLoad: true（ログイン時） ↓ ~/.claude/scripts/daily-brief.sh ↓ ~/.claude/logs/daily-brief-YYYYMMDD.md ← 正本ログ ~/.claude/logs/daily-brief-latest.md ← 最新コピー ~/Desktop/Daily Brief/today-brief-YYYYMMDD.md ~/Documents/claude-obsidian/wiki/briefs/daily/today-brief-YYYYMMDD.md Even when the second run fires at 10:30, the marker <!-- daily-brief YYYYMMDD --> prevents duplicate appends (details below). The script opens like this: #!/usr/bin/env bash # launchd で毎日 8:00 / 10:30 / ログイン時 実行（再実行してもマーカーで二重追記しない）。 # 注意: Desktop / ~/Documents(vault) は TCC 保護領域 → plist は /bin/bash 直起動（FDA付与済み）。 # /bin/zsh 経由だと FDA 未付与で書き込

In GoodBarber, you build an app without writing code: you assemble components, drag and drop, with a design system holding everything coherent underneath. Recently, a second way in appeared: you can get a custom section by describing it to an AI in plain language. Two ways of creating now live in the same back office — and the question comes immediately: is this the beginning of the end for drag & drop? No. And that "no" isn't a defensive reflex — it's an interface-architecture choice you can reason about. The ladder everyone knows The history of creation tools gets told the same way by everyone, and it's true: a ladder of abstraction. First, code — total control, total complexity. Then direct manipulation — drag & drop: you touch the rendering itself, the first great democratization. Then components — you stop aligning pixels and start assembling coherent elements, governed by a design system. And now the prompt — you describe, the machine produces. Each rung up, you move away from the mechanics and closer to the intent. None of that is a revelation. What gets told less often is the conclusion you reach when you actually operate a product sitting on that ladder: every time a new rung appeared, the prediction was the same — this one makes the others obsolete. It never came true. The prompt won't be the exception, and here's why. What drag & drop does better — and always will For anything that can be shown, direct manipulation is unbeatable. This button, two pixels lower; this image, at the top of the section; this menu, in this order: the gesture is the description — the sentence explaining it to an AI is longer than the action itself. And a visual interface does something besides taking orders: it shows you what's possible. A settings panel is a map of what the product can do; an empty prompt field is an invitation to guess. That's why the no-code core of the platform — component management, screens, navigation, design — stays drag & drop, deliberately. It isn't th

OhNine is a free menu bar app that tracks Claude session and weekly usage limits in real time It sends native alerts at 80%, 91%, and 100% so a session never ends without warning The hard problem was never reading a number, it was making the warning arrive before the cutoff instead of after Building a zero telemetry tool changed how I judge every product I ship after it The Problem: Hitting a Wall You Cannot See For months, my Claude sessions ended the same frustrating way. I would be deep in a conversation, mid thought, actually making progress, and then the reply would just stop. No countdown. No yellow light. No warning that said "you have three messages left, wrap up." One second I was working, the next I was staring at a message telling me to wait for a reset I never saw coming. The frustrating part was not the limit itself. Usage limits exist for a reason, and I understand why they are there. The frustrating part was the total lack of visibility into where I stood. Claude Code and claude.ai will occasionally mention you are close to a cap, sometimes at 97 percent, which is technically a warning and practically useless, because by then you are already mid-thought with no time left to land it cleanly. It got worse once I noticed the layers. There is not one limit to track, there are several stacked on top of each other: a session limit, a rolling weekly cap, and separate caps depending on which model you are running. Switching models mid-session, thinking you had found a workaround, only to hit a wall from a different direction, was its own specific kind of frustrating. None of these layers showed up anywhere. There was no dashboard, no menu bar icon, nothing you could glance at the way you glance at your laptop's battery percentage before deciding whether to plug in. So the wall kept arriving the same way: mid-flow, mid-sentence, with zero warning. Coding sessions got cut off between a question and its answer. Writing sessions lost momentum at the worst possibl

Today on Decoder, I’m talking with Hayden Field, The Verge’s senior AI reporter, about the major trade secrets lawsuit between Apple and OpenAI and what this tells us about OpenAI’s future. By now I’m sure most Decoder listeners are familiar with Apple’s allegations in this case. The company says a number of ex-Apple employees at […]

I'll guide you through Python fundamentals by comparing concepts with JavaScript. Let's start! 1. Hello World & Basic Syntax JavaScript console . log ( " Hello World " ); let x = 5 ; Python print ( " Hello World " ) x = 5 # No semicolon, no let/const Key Differences: No semicolons in Python Indentation matters (replaces curly braces) Comments use # instead of // 2. Variables & Data Types JavaScript let name = " Alice " ; // string let age = 30 ; // number let isStudent = true ; // boolean let scores = [ 95 , 87 , 91 ]; // array let person = { // object name : " Bob " , age : 25 }; let nothing = null ; let notDefined = undefined ; Python name = " Alice " # str age = 30 # int (or float for decimals) is_student = True # bool (capital T/F) scores = [ 95 , 87 , 91 ] # list (mutable) person = { # dict (dictionary) " name " : " Bob " , " age " : 25 } nothing = None # Python's null/undefined Key Differences: Python uses snake_case (not camelCase) True / False capitalized None instead of null / undefined Lists ≈ Arrays, Dicts ≈ Objects 3. Control Flow JavaScript // If-else if ( age >= 18 ) { console . log ( " Adult " ); } else if ( age >= 13 ) { console . log ( " Teen " ); } else { console . log ( " Child " ); } // For loop for ( let i = 0 ; i < 5 ; i ++ ) { console . log ( i ); } // While loop let count = 0 ; while ( count < 5 ) { console . log ( count ); count ++ ; } Python # If-else (indentation instead of braces) if age >= 18 : print ( " Adult " ) elif age >= 13 : # NOT else if print ( " Teen " ) else : print ( " Child " ) # For loop (more like for...of in JS) for i in range ( 5 ): # range(5) = [0, 1, 2, 3, 4] print ( i ) # Iterate over list (like for...of) for score in scores : print ( score ) # While loop count = 0 while count < 5 : print ( count ) count += 1 # No ++ operator in Python 4. Functions JavaScript // Function declaration function add ( a , b ) { return a + b ; } // Arrow function const multiply = ( a , b ) => a * b ; // Default parameters function greet ( n

There's a class of bug reports that keeps coming back in the NocoBase community, especially in the Chinese-language forum: "all my times are off by 8 hours" or "dates show up as the day before." China is UTC+8, so the shift is 8 hours there. I run my instances at UTC+9, and sure enough — my shift is 9 hours. Whatever your offset is, that's the size of your shift. That pattern is a strong hint that this isn't random corruption. It's a mechanism. I set up NocoBase 2.x against both PostgreSQL and MySQL and measured what actually gets stored and how it gets reinterpreted, until the mystery had a concrete answer. Test setup: NocoBase 2.0.51 and 2.1.23 (official Docker images) × PostgreSQL 16 and MySQL 8.4. All data written and read through the REST API, with the server timezone controlled via the container's TZ environment variable. I'm deliberately ignoring the browser-side rendering here — this is about what the server stores and how it interprets it. Background: 2.x has four datetime field types NocoBase 2.x collections offer four datetime-ish field types ( official list — though several of the per-type detail pages still say "To be added", which is exactly why I measured instead): Type What it's for Datetime (with time zone) Absolute instants — event start times, logs Datetime (without time zone) Wall-clock times you want preserved as-is Date only Birthdays, due dates, anniversaries Unix timestamp System integration Measurement 1: what each type actually stores I imported "2026-07-12 09:00" via xlsx and looked at the raw values in each database (identical on 2.0.51 and 2.1.23): Field type PostgreSQL MySQL Datetime (with TZ) timestamptz → 2026-07-12 09:00:00+09 ( an absolute instant, offset included ) DATETIME → 2026-07-12 09:00:00 ( wall clock only — no offset information ) Datetime (without TZ) timestamp → 09:00:00 DATETIME → 09:00:00 Date only date → 2026-07-12 date → 2026-07-12 The first row is the whole story. The same field type — "Datetime (with time zone)" — i

Tired of squinting at VS Code’s stacked merge editor? MergeForge brings a JetBrains-style three-pane conflict resolver to VS Code and Cursor — and pairs it with an AI assistant that actually reads your repository before it suggests a fix. The problem We’ve all been there. You’re halfway through a rebase. Git stops. Twelve files are conflicted. You open one in VS Code… and get that familiar stacked layout: Incoming, Current, and a result pane that somehow still feels like a puzzle with half the pieces missing. If you ever used WebStorm or IntelliJ, you know how good merge tools can feel: Your side on the left Their side on the right The result in the middle Gutter arrows that just… work In VS Code land, that flow never quite arrived. You click Accept Current, Accept Incoming, Accept Both, and hope nothing important got flattened. Word-level diffs? Authorship? A clear “who wrote this chunk?” signal? Often missing when you need them most. And when AI entered the chat, a lot of tools treated conflicts like isolated text blobs: “Here are the <<<<<<< markers. Good luck.” But real merges need context. What was the branch trying to do? What does the surrounding file look like? Who touched this last? Without that, “AI resolve” is just confident guessing. I wanted the JetBrains merge experience — inside VS Code and Cursor — with an assistant that behaves more like a careful teammate than a slot machine. So I built it. The solution: MergeForge MergeForge is an open-source VS Code / Cursor extension that turns conflicted files into a proper three-pane visual merge. Layout: Left Center Right Yours (local) Result (editable, seeded from the merge base) Theirs (incoming) Panes scroll together. Chunks connect with bands. Gutter controls let you accept, ignore, or blend sides without fighting the UI. When you’re done, Apply writes the result and stages it with git. If you prefer Cursor, you’re covered too. The editor works the same; for AI features you plug in your own provider key (

If you've ever had to check code or infrastructure against a compliance framework, you know the drill: someone reads a 100-page PDF, then reads your codebase, then makes a judgment call. It's slow, inconsistent, and it can't be automated. So I built a pipeline to fix that — for real. The problem CMMC Level 1 and NIST SP 800-171 Rev 2 are two of the most common compliance frameworks small defense contractors and government-adjacent companies have to meet. Both exist only as dense regulatory text. There's no official machine-readable version. That means every compliance check is manual. Every AI coding assistant reviewing your infrastructure has zero built-in awareness of these requirements. Every CI/CD pipeline has to skip compliance checks entirely or rely on someone remembering to look. ** What I built** A Python pipeline that: Pulls the real regulatory source data — NIST's official CPRT export for SP 800-171, and the verbatim text of 48 CFR § 52.204-21 for CMMC Level 1 Normalizes it into a structured SQLite schema Generates a JSON rule for every single control, with a machine-actionable instruction attached Here's what one rule actually looks like: \ json { "rule_id": "nist_sp_800-171_rev_2_3.1.1", "framework": "NIST SP 800-171 Rev 2", "control_id": "3.1.1", "title": "ACCESS CONTROL — 3.1.1", "requirement": "Limit system access to authorized users, processes acting on behalf of authorized users, and devices.", "agent_guidance": "When generating or reviewing code/infrastructure, ensure compliance with NIST SP 800-171 Rev 2 control 3.1.1. Flag any implementation that does not satisfy: Limit system access to authorized users, processes acting on behalf of authorized users, and devices.", "generated_at": "2026-07-15T16:42:56.026218+00:00" } \ \ That agent_guidance field is the interesting part — it's written specifically to drop straight into an AI coding agent's system prompt as a compliance guardrail. Three ways to actually use this 1. AI coding agent system prompt