DEV Community: Sebastian Lim

How do you guys manage reusable info from AI conversation history

Sebastian Lim — Wed, 18 Feb 2026 17:12:25 +0000

As what title said
there are lots of infos from AI could be reused or record as ADR.

But as the task become more and more complex, more chat history remains.

I found a way to save these infos and make sure they can be save immediately and find them quickly.

I use codex to save my conversation history with AI or anything about the task. Ask it to save as a json into my daily note.
If I'm gonna find anything I could also ask codex read the json and find them.

I wanna write about my solution, but before that I curious about how you guy manage your infos. Whatever it is a chat history from AI, or from project you handle or maybe your interest.

"Just Patch the Output" — Why Your Clean Architecture Is More Fragile Than My Band-Aids.

Sebastian Lim — Tue, 17 Feb 2026 04:59:38 +0000

You spent three months designing the "proper" solution. You contributed upstream. You negotiated with maintainers. You got your pull request reviewed, revised, re-reviewed, and finally merged — into a release that won't ship until next quarter. Meanwhile, your deadline was last Friday.

I spent an afternoon writing a script that takes the wrong output and makes it right. It's ugly. It's a band-aid. It has seven workarounds that each begin with a comment explaining what upstream should have done differently. And it shipped on Friday.

Here's the part that will make you uncomfortable: six months later, my band-aid script is still running, still auditable, still does exactly what it says. Your "proper" solution is stuck in a merge conflict with a refactor that a new contributor pushed to the upstream repo you thought was stable.

I know this because I've been on both sides. I spent v1 doing the "proper" thing — forking four upstream tools, adding real platform support, building "real" fixes. It nearly killed my project. v3 is the recovery: stop fixing the tools. Fix what they produce. The band-aid is the strategy.

The Lie That Works

I'm porting ROS 2 Jazzy to openEuler 24.03 LTS. The ROS build toolchain — bloom, rosdep, rospkg, rosdistro — does not recognize openEuler. It will not generate packages for it. If you ask bloom to build an RPM, it asks the OS detector what system you're on, gets "openEuler," and gives up.

v1's answer: fork the OS detector, add an OpenEuler(OsDetector) class, register it as an RHEL clone, maintain four forked repositories. Noble. Principled. And structurally suicidal — any pip install could overwrite my forks with the official versions, silently killing the pipeline. (I wrote an entire article about this.)

v3's answer: one line.

export ROS_OS_OVERRIDE=rhel:9

That's it. I'm telling bloom "you're running on RHEL 9." Bloom believes me. It generates RHEL 9 specs. The specs are wrong for openEuler — wrong install paths, wrong dependency names, wrong macros — but bloom runs. It produces output. And output can be fixed.

Is this a lie? Yes. ROS_OS_OVERRIDE is a documented ROS feature, but it was designed for cross-compilation environments, not for making an unsupported OS masquerade as a supported one. I'm using it for something the ROS maintainers probably didn't intend.

And it works better than the "honest" approach of teaching the toolchain what openEuler actually is.

The Fix-the-Output Architecture

Here's the entire system:

  Source Code           Official bloom              My one script
  (ros2.repos)    --->  (unmodified,          --->  (fix_specs.py)    --->  EulerMaker
                         thinks it's RHEL 9)         7 fixes, 1 file         (builds RPMs)

That's three arrows. The middle box is someone else's maintained software. The only code I own is the thing on the right.

Compare to v1:

  Source Code     --->  Forked bloom          --->  Forked rosdep     --->  Forked rosdistro
  (973 packages,        Forked rospkg               (YAML data,             (more YAML data,
   scraped from          (Python code,               rots silently)           rots silently)
   sitemap)              breaks on pip)

                        ^--- I own ALL of this. Every upstream update is my problem. ---^

v1 owned the entire middle of the pipeline. v3 owns a single post-processing script. When upstream ships an update, v1 has to re-patch four repositories. v3 runs pip install --upgrade bloom rosdep and then checks if fix_specs.py still produces correct output. Usually it does. The fixes are against output format, which changes slowly, not against internal implementation, which changes whenever a maintainer feels like refactoring.

The structural difference: v1 is coupled to upstream's internals. v3 is coupled to upstream's outputs. Outputs are a contract. Internals are not.

The Seven Band-Aids

Here they are. Every single one. I'm not going to dress them up:

#	What It Does	Why
1	Adds `%bcond_without tests`	Tests don't pass on openEuler yet. Disable them to unblock the initial build.
2	Adds `%global debug_package %{nil}`	Debug packages cause build failures. Not worth debugging until the main build works.
3	Normalizes `Name:` to `ros-jazzy-<pkg>`	Bloom generates inconsistent package names. EulerMaker rejects them.
4	Fixes `Source0:` path	Bloom's tarball naming doesn't match openEuler conventions.
5	Rewrites install prefix to `/opt/ros/jazzy`	Bloom installs to `/usr`. openEuler ROS goes to `/opt/ros/jazzy`. Every CMake flag, every Python path, every `%files` glob needs rewriting.
6	Injects `PYTHONPATH` into `%build`/`%install`/`%check`	Without this, Python can't find ROS libraries during build. The build environment doesn't set up the path correctly.
7	Simplifies `%files` to `/opt/ros/jazzy`	Package everything under the ROS prefix. Bloom's generated `%files` section lists paths that don't exist on openEuler.

Look at that table. It's not impressive. There's no clever architecture. There's no abstraction layer. There's no plugin system. It's seven string replacements applied in sequence, each one documented with "why it exists" and "what upstream change would make it unnecessary."

That's the point.

Why Band-Aids Beat Architecture

I'm going to make an argument that will offend anyone who's read Clean Code: a visible band-aid is structurally superior to an invisible "proper" fix.

Here's the reasoning.

1. Band-aids are auditable. Proper fixes hide.

Open fix_specs.py. Read it top to bottom. In under ten minutes, you know every single thing v3 works around. Every platform gap between openEuler and RHEL 9. Every bloom output that needs correction. Every assumption the ROS toolchain makes that doesn't hold.

Now try doing the same audit on v1's forked bloom. Where are the openEuler-specific changes? Scattered across four repositories, mixed into the existing codebase, buried under commit messages like "fix OS detection" and "add openEuler support." You'd need to diff against upstream to find them all, and upstream has moved since the fork, so the diff includes changes from both sides.

A system whose workarounds are invisible is a system whose costs are invisible. And invisible costs compound.

2. Band-aids are removable. Proper fixes entangle.

Each fix in fix_specs.py is independent. If openEuler starts shipping python3-flake8-builtins tomorrow, I delete one function and the rest of the pipeline doesn't notice. If bloom fixes its Name: generation, I delete another function. No regression risk. No cascading changes.

Try removing openEuler support from a fork that's had six months of other changes layered on top. The fork has its own git history now. Its own bug fixes. Its own workarounds for things that broke because of the fork. You're not removing a feature — you're performing archaeology.

3. Band-aids fail loudly. Proper fixes fail silently.

When a band-aid stops working, the spec file is visibly wrong and the build fails immediately. The error message points to the spec. The spec points to fix_specs.py. The fix function has a docstring explaining why it exists. Diagnosis time: minutes.

When a fork gets silently overwritten by pip install, everything looks fine until a build fails with an unrelated error three hours later. Diagnosis time: half a day, minimum, because you're looking in the wrong place.

Systems that fail loudly are systems that get fixed. Systems that fail silently are systems that rot.

The Uncomfortable Trade-off

I'm not going to pretend v3 has no cost. It does. The cost is this:

    (New platform issue           (Add fix to
     discovered)            --->   fix_specs.py)
          ^                             |
          |                             |
          |     ACCUMULATION            v
          |        LOOP              fix_specs.py
          |                          GROWS
          |                             |
          +-----------------------------+
               (More complexity
                to maintain)

The band-aids accumulate. Each new openEuler-vs-RHEL divergence means a new function in fix_specs.py. The file gets longer. The surface area grows. Eventually, it hits some threshold where the maintenance cost of the post-processing script rivals the maintenance cost of the fork.

I know this. I chose this consciously. Here's why it's still better:

The accumulation is visible. I can open one file, count the fixes, read their rationale, and make an informed decision about whether the script is still manageable or whether it's time to push fixes upstream. With v1's forks, the equivalent accumulation was happening across four repositories, invisibly, and I didn't realize the cost was unsustainable until the pipeline broke at 3 AM.

The accumulation has an exit ramp. Each band-aid includes a note: "What would eliminate this fix." Every one of those notes describes an upstream contribution or an openEuler packaging change. When I eventually submit upstream PRs, I know exactly what to submit, because the band-aids are a precise map of the gap between "what exists" and "what's needed."

v1's forks had no exit ramp. The longer the fork ran, the harder it was to merge back upstream, because the fork and upstream diverged in both directions. That's the difference between linear accumulation (v3) and exponential divergence (v1).

The ROS_OS_OVERRIDE Principle

The deeper lesson is not about RPM specs or ROS packaging. It's about a design principle that most software engineers are trained to reject:

If you can't change the tool, change its environment, accept its output, and fix the output.

We're taught to fix problems at the source. Don't parse HTML with regex — use a proper parser. Don't post-process compiler output — fix the compiler flags. Don't patch generated code — fix the generator.

These are good defaults. But they assume you can fix the source. When you can't — because the source is upstream, because the maintainers are busy, because the fix requires organizational changes that take months — the "proper" approach becomes a blocking dependency on something outside your control.

ROS_OS_OVERRIDE is the embodiment of this principle. I cannot change how bloom detects operating systems. I cannot add openEuler to rosdistro's supported platform list (not quickly, anyway). But I can set an environment variable that makes bloom produce usable output, and then I can fix that output.

Is this elegant? No. Is this what the ROS developers intended? Probably not. Does it decouple my project's progress from upstream's review cycle? Yes. And that decoupling is worth more than any amount of architectural elegance.

The Real Engineering Skill

The v1 article was about recognizing structural traps. This one is about something harder: recognizing when the "right" solution is the wrong strategy.

Every senior engineer I've met has an instinct for "doing it properly." It's a good instinct. It produces maintainable code. It produces systems that last. But it also produces a specific failure mode: the project that never ships because someone insisted on getting the architecture right before solving the problem.

v3 ships. It ships with seven band-aids, a fake OS identity, and a post-processing script that would make any bloom developer cringe. And it's more maintainable, more auditable, and more resilient than the "proper" version ever was.

The real skill is not knowing how to build the right system. It's knowing when the right system is too expensive, and building the useful system instead — with full awareness of what you're trading away, documented in a file that anyone can read.

My band-aids are in fix_specs.py. Where are yours?

*The fork trap that v3 replaced: the_brute_force_probe. The reproducible pipeline: the_reproducible_pipeline. I'm building systems that are honest about their own limitations.

Your Fork Will Outlive Your Patience. A Systems Thinking Post-Mortem.

Sebastian Lim — Mon, 16 Feb 2026 13:36:11 +0000

Every internal fork starts as a one-liner: "we just need to patch this one file." Six months later you're maintaining four parallel repositories, dreading every upstream release, and spending more time keeping your patches alive than building the thing they were supposed to enable.

I know because I did exactly this. I forked four upstream tools to port 973 ROS packages to an unsupported OS. It worked — 61% of the packages compiled, turtlesim ran, my demo was a success. Then the fork ate me alive.

This is not a war story. This is a system dynamics diagnosis of why forking upstream tools creates a structural trap that no amount of discipline can outrun.

The Setup

I was porting ROS 2 Jazzy (the Robot Operating System) to openEuler 24.03 LTS — a Linux distribution that ROS does not officially support. The ROS build toolchain (bloom, rosdep, rospkg, rosdistro) hardcodes its list of supported platforms. openEuler is not on it.

My options were:

Contribute upstream — submit PRs to add openEuler support to the official tools. Slow, dependent on maintainer goodwill, but sustainable.
Fork everything — clone the four repos, add openEuler support myself, build from source. Fast, self-contained, but now I own the maintenance.

I chose option 2. Of course I did. I had a demo to deliver.

The Fix That Fails (R1)

Here's what my fork looked like as a system:

        (Problem)                      (Relief)
    TOOLCHAIN DOESN'T    ---------->  TOOLCHAIN WORKS
    RECOGNIZE openEuler                   |
         ^                                |
         |         (Short Term)           |
         |          BALANCING             |
         |            LOOP                |
         |                                v
         +------ <FORK UPSTREAM> ---------+
         |         (Intervention)         |
         |                                |
         |                                |
         |  (Long Term Side-Effect)       |
         |    REINFORCING LOOP (R1)       |
         |    "Fixes that Fail"           |
         |                                |
         |                                v
    +-----------+                  +-----------------+
    | FORK GETS | <--------------- | UPSTREAM MOVES  |
    | OVERWRITTEN|    (Delay)      | (pip install,   |
    | OR STALE  |                  |  new releases)  |
    +-----------+                  +-----------------+

Every pip install in my build environment could silently overwrite my forked rosdep with the official version. The official version doesn't know openEuler exists. Suddenly my entire pipeline is dead and I'm grepping through pip logs trying to figure out what happened.

This is textbook "Fixes that Fail" — one of the system archetypes described by Donella Meadows. The fix (forking) addresses the symptom (toolchain doesn't recognize my OS), but it creates a side effect (fragile environment that breaks on any upstream interaction) that makes the original problem recur, harder to diagnose each time.

The reinforcing loop at the bottom is the killer. The more upstream moves, the more my fork breaks. The more it breaks, the more time I spend re-patching. The more time I spend re-patching, the less time I have to pursue the fundamental solution (contributing upstream). Which means I'm even more dependent on the fork tomorrow than I am today.

The Data Decay Loop (R2)

R1 didn't run alone. I also forked rosdistro — the central database that maps ROS package names to OS-specific dependencies. My fork contained hand-maintained YAML files mapping ROS dependency keys to openEuler package names.

    Official rosdistro            Forked rosdistro
    (constantly updated)  ------>  (frozen in time)
          ^                              |
          |                              |
          |       REINFORCING            v
          |         LOOP (R2)        METADATA ROTS
          |      "Data Decay"        (Wrong versions,
          |                           missing packages)
          |                              |
          |                              v
          |                        BUILD FAILURES
          |                        INCREASE
          |                              |
          +------------------------------+
              (Need more manual
               patching of YAML)

Every day the official rosdistro receives updates, my fork falls further behind. Every day it falls behind, more builds fail for reasons that have nothing to do with openEuler compatibility — they fail because my metadata is stale.

I wrote a script (auto_generate_openeuler_yaml.py) that reads the official YAML and tries to map each dependency to an openEuler package via dnf list. But this script can only run on an actual openEuler machine. It can't run in CI. It can't run offline. It's a manual process that I have to remember to do, and every time I forget, the data rots a little more.

What R1 + R2 Look Like in Practice

Here's the actual data from my system, running on EulerMaker:

Architecture	Success	Dep Gaps	Failures	Interrupted	Total
aarch64	606	215	152	—	973
x86_64	597	214	151	11	973

61% success rate. Turtlesim runs. That's the good news.

The bad news: those 214 dependency gaps and 151 build failures are the accumulated stock of problems that my two reinforcing loops are feeding. Each gap is a place where my forked metadata is wrong or my forked toolchain did something the real toolchain wouldn't. And every time upstream moves, some of those 597 successes will become new failures, because my fork hasn't kept up.

The system is not failing. The system is succeeding at producing failures, because that's what its structure is designed to do.

The Leverage Point I Missed

In systems thinking, there's a concept called leverage points — places where a small change in structure produces a large change in behavior. Meadows ranked "the rules of the system" as one of the highest leverage points.

My fork was operating under one implicit rule: "we maintain our own version of the toolchain." This rule forced every interaction with upstream into an adversarial relationship. Upstream updates weren't improvements — they were threats.

The high-leverage alternative was to change the rule: "we get our patches accepted upstream." Under this rule, every upstream update would be an improvement that includes our platform support. The same force that was destroying my system (upstream momentum) would be sustaining it instead.

I know why I didn't do this. Contributing upstream is slow, political, and uncertain. Forking is fast, controllable, and certain. But "fast and certain" in the short term turned into "expensive and fragile" in the long term. That's the entire point of the Fixes that Fail archetype — the symptomatic solution is always more attractive in the moment.

What I Actually Learned

A fork is a liability, not an asset. The moment you fork, you've created a maintenance obligation that grows with every upstream commit. If you can't get your changes upstream within a bounded timeframe, you are accumulating structural debt that compounds.
Data forks are worse than code forks. Forking code is bad. Forking data (like my rosdistro YAML files) is worse, because data goes stale silently. Code breaks loudly — a function signature changes and you get a compile error. Data rots quietly — a package version is wrong and you get a mysterious runtime failure three weeks later.
The brute-force approach is valuable — as a probe. v1 was not a failure. It was a deliberate brute-force survey that generated an intelligence map: here are the 973 packages, here's which ones work, here's exactly where the gaps are. The failure was in thinking the probe could become the production system. Probes are disposable. Production systems need structural integrity.
Know your band-aids. I have virtualenv bypasses, RHEL-clone registrations, and frozen YAML snapshots in my system. I know each one is a band-aid. Most teams don't track their band-aids. They accumulate silently until someone asks "why does our build take 45 minutes and fail 30% of the time?" and nobody can answer.

The Follow-Up

v1 taught me what a brute-force pipeline looks like when it hits its structural limits. I documented the full system dynamics, including the trap architecture, in the v1 post-mortem repo.

v2 was designed to break the cycle: verify before building, not after. Instead of feeding 973 packages into a pipeline and watching 40% of them fail, v2 probes the OS environment first, identifies gaps before consuming build resources, and operates on a verified dependency graph. Details in the v2 Verification Engine repo.

The structural lesson applies far beyond ROS porting:

If you're maintaining an internal fork of an OSS library: you're running R1. Get your patches upstream or plan for the maintenance tax.
If you're patching configuration files that upstream keeps overwriting: you're running R2. Automate the merge or accept the data rot.
If you're using --skip-broken, --force, or || true in your build scripts: you're masking symptoms. Each flag is a band-aid. Count them.

Every fork starts with "just this one patch." Every addiction starts with "just this one hit."

The system doesn't care about your intentions. It cares about its structure.

*The v1 post-mortem with system dynamics diagrams: the_brute_force_probe. The v2 verification engine: the_adaptive_verification_engine.

Flaky Tests Are Not a Testing Problem. They're a Feedback Loop You Broke.

Sebastian Lim — Sun, 15 Feb 2026 15:50:56 +0000

Every retry rule in your CI pipeline is a painkiller. It suppresses the symptom, the stock of broken code keeps growing underneath, and nobody feels the pain until the whole system is addicted.

I came across this post on HN that perfectly illustrates the pattern: retries everywhere, quarantining tests, adding waits, slowly losing trust in CI signal. The author asked whether flakiness is "a test problem, a product problem, or infrastructure noise."

It's none of those. It's a system structure problem. And if you look at it through the lens of System Dynamics, the diagnosis becomes obvious.

The Addiction Loop (R1)

Every "fix" that masks a failure instead of resolving it feeds a reinforcing loop:

    (Symptom)                    (Symptom Relief)
    RED PIPELINE  ---------------->  GREEN BUILD
         ^                                |
         |          (Short Term)          |
         |           BALANCING            |
         |             LOOP               |
         |                                v
         +----------- <RETRY> ------------+
         |          (Intervention)        |
         |                                |
         |                                |
         | (Long Term Side-Effect)        |
         |     REINFORCING LOOP (R1)      |
         |     "The Addiction"            |
         |                                |
         |                                v
    +---------+                    +-------------+
    |  MORE   | <----------------- | HIDDEN BUGS |
    | FLAKINESS|      (Delay)       | ACCUMULATE  |
    +---------+                    +-------------+

Look at the bottom loop. Every time you hit "retry," you feel good because the light turns green. But you are feeding R1: hidden bugs accumulate, making the system flakier, forcing you to retry even more tomorrow.

This is textbook "Shifting the Burden" — one of the classic system archetypes identified by Donella Meadows. The short-term fix (retry) actively undermines the long-term solution (actually fixing the bug).

The Erosion Loop (R2)

R1 doesn't run alone. It drags a second loop behind it:

 Actual Quality           Perceived Quality
    (Lots of Red)  --------->  (It's just noise)
          ^                           |
          |                           |
          |      REINFORCING          v
          |        LOOP (R2)      LOWER STANDARDS
          |     "The Erosion"     (Normalize Failure)
          |                           |
          |                           |
          +---------------------------+
             (Less debugging,
              more merging)

This is "Drift to Low Performance." Because you don't trust the CI signal, you lower your standards. Because you lower standards, you merge worse code. Which makes the signal even less trustworthy. Repeat until your CI pipeline is a decoration.

The original HN post asked: "how do QA and engineering teams split responsibility?" That's the wrong question. The real question is: how do you make the pain of instability felt by the person who introduced it? Right now, the infrastructure absorbs the pain by retrying, so developers never feel it. They keep submitting flaky code because the system lets them get away with it.

I Ran Into the Same Wall

I built a CI pipeline to port an entire ROS 2 Desktop stack onto two non-officially-supported Linux distributions — openEuler (CentOS-based) and openKylin (Ubuntu-based) on RISC-V. Two different base systems, 973 packages, zero upstream CI support.

My system went through three phases, and they map directly to the dynamics above.

v1: The Brute-Force Probe. I blindly pulled all 973 packages into the pipeline and let them build. This triggered widespread breakages — but it wasn't a failure, it was a data mining operation. I successfully built 597 packages (proving feasibility), and more importantly, I mapped exactly 214 specific dependency gaps and 151 build failures. The pipeline wasn't meant to pass. It was meant to make every hidden stock of problems visible.

v2: The Verification Engine. Armed with v1's data, I built a system that verifies before building — probing the OS environment to identify dependency gaps before consuming expensive build resources. Build attempts dropped, success rate went up, because I stopped feeding garbage into the pipeline. (GitHub repo)

v3: Incremental Stock Management. Instead of tackling everything at once, I identify small batches of problematic dependencies, isolate them into manageable "stocks," and resolve them one group at a time. Subtraction, not addition.

My System Is Addicted Too

Here's the part where I punch myself in the face.

My own CI has the same addiction pattern. I use virtual environments to bypass system dependency conflicts. I have masquerade rules that spoof package identities. If you look at the architecture diagram in my README, you'll spot multiple "intervention" nodes — each one is a band-aid.

I know this is not sustainable. These are temporary splints, not fixes.

But here's the difference: I know these are band-aids. Most teams don't. They think retries are "solutions." I know my virtualenv bypass is a temporary splint that I chose consciously, with full awareness of the technical debt I'm taking on. Being aware of the addiction and being consumed by it are two very different things.

The Real Bottleneck

I can identify the stock that's poisoning your pipeline. I can design the feedback loop that makes the right person feel the pain. What I can't do is force an organization to care.

And that's usually the real bottleneck — not the flaky tests, but the system's refusal to let anyone feel the consequences.

*If you're dealing with a similar "build-first-verify-never" problem, the v2 Verification Engine repo shows this systems thinking approach applied to a real project. I'm looking for exactly these kinds of challenges.