I'm a big fan of Apache CouchDB, so I was very pleased when I got the permission to opensource (is that even a verb) a R&D project we were working on for a while, meet CouchCompanion

Fauxton as role model

We were asking us, how would CouchDB's admin ui Fauxton look like when you rebuild today, what would be the tech stack and new or enhanced features. This is what we can up with:

• build with webcomponents, namely Webawesome and Lit, no big framework like react or angular
• Native fetch()
• All JSON and JS Code editable with the Monaco editor (the one used in VSCode)
• Support to build Mango queries and indici
• Sync with version control (Github for the moment, fighting with CORS and CSP)
• dark/lght mode
• UI to configure OIDC IdP

... and more. There is a capability walkthrough available. But to really get a feel, just run the container:

docker run -d --name couch-companion -p 5984:5984 \
  -e COUCHDB_USER=admin -e COUCHDB_PASSWORD=<choose one> \
  -v couchdb_data:/opt/couchdb/data \
  ghcr.io/hcl-tech-software/couch-companion:latest

The container is based on the official CouchDB image with Fauxton swapped out for CouchCompanion. Give it a spin!

In the last article I introduced age and a working setup for macOS. Now let's look at Github actions integration

TL/DR

In a nutshell: create an age key just for GitHub actions, commit it to secrets, add the public key to recipients.txt and add it to your github job.

Credential stealing is rampant, so some diligence in guarding API keys, passphrases and secrets is warranted.

Stop wondering if it could happen to you, but prepare for when it might happen. Here is one arrow in your defense portfolio.

Limit the blast radius

When an attacker sneaks by your 2FA using e.g a supply chain attack your next line of defense is "How much can they see?"

• For starters no key (other than public ones), token or credential shall live on disk unencrypted.
• Loaded evn variables should be limited to their projects, when in ~/Code/someproject there must not be any env variable from ~/Code/otherproject be loaded.
• The day-2-day use must be easy and convenient

Three components

To make this work we need three components:

• macOS keychain: holds the AGE key(s), (Other operating systems is another story for another time).
• age "Actually good encryption": to encrypt your secrets and .env variables.
• direnv: Loads and unloads environment variables depending on the current directory.

For my development setup I typically rely on Development Containers which works very UI centric. Your Ide discovers the .devcontainer folder and boots an edit container and starts whatever you have defined in your docker-compose.yml file. This is great for sharing, I wrote about it, read for a refresher.

In a terminal centric world this is a heavy approach and I want options

Multiplex your terminal

My goal: with a single script start quarkus dev, twice npm run dev and a database (Apache CouchDB, glad you asked). They all need to run in the foreground, so I can keep an eye on them. This precludes simply using & to run them in the background.

Enter tmux. The wiki describes it: "tmux is a terminal multiplexer. It lets you switch easily between several programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal." Claude described it like this (might contain emscripten):

Code pedigree is more important than ever with the ever increasing rate of supply chain attacks. Setting up code signing are a few steps, recorded here for reference.

Choice of key formats

While you could pick an ssh or x509 key, I shall stick to gpg and the Ed25519 algorythm.

Act 1 - get macOS ready

When you followed earlier advice you are good to go. If not, install Homebrew and dependencies

brew install gh gpg pinentry-mac

# setup pinentry
mkdir -p ~/.gnupg
chmod 700 ~/.gnupg
echo "pinentry-program $(brew --prefix)/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf
gpgconf --kill gpg-agent

Act 2 - create the key

This creates a signing key that lasts for 2 years. Make sure to get the eMail right. After creation we extract the key id.

gpg --batch --quick-generate-key "John Doe <[email protected]>" ed25519 sign
TARGET_EMAIL="[email protected]"
GPG_KEY_ID=$(gpg --list-secret-keys --with-colons "$TARGET_EMAIL" 2>/dev/null \
             | awk -F: '$1=="sec" {print $5; exit}')
echo Your key id is $GPG_KEY_ID

You also can do that manually running gpg --list-secret-keys --keyid-format=long and look for the string after the / in the line starting with sec.

Act 3 - configure your local git

Make sure to get the eMail right

git config --global user.name "John Doe"
git config --global user.email "$TARGET_EMAIL"
git config --global user.signingkey "$GPG_KEY_ID"
git config --global commit.gpgsign true
git config --global tag.gpgsign true
git config --global pull.rebase true

Act 4 - Let github know

Display the public key:

gpg --armor --export $GPG_KEY_ID

Go to your Github key settings, click on "New GPG key" and paste it

Act 5 - overwrite for individual repos (optional)

git config user.name "John Doe"
git config user.email "$TARGET_EMAIL"
git config user.signingkey "$GPG_KEY_ID"
git config commit.gpgsign true
git config tag.gpgsign true
git config pull.rebase true

For adventurous souls there is a setup script available to automate this. Use at your own risk.

As usual YMMV

In 2026, after a 16 years pause, HTTP gained a new keyword QUERY. Much has been said and said about the GET with a body. But why did it take so long?

Agreement not implementation

I'll share a secret: QUERY has been supported by HTTP for a long time. So has HTTP UNIVERSE or HTTP TANGO The protocol doesn't care for the keyword. Your client an server care. HTTP GET can't contain a body - nonsense. Of course it can. And you can expect, unless you control both sides, that it will fail in one way or another.

So the IETF standards are the etiquette of interaction, not the laws. They are the gentlemen agreement stating "If we both follow the RFC, we can have the reasonable expectation that this exchange of information could work".

Hammering out agreements that don't break previous ones it time consuming and tedious, especially in venerable, foundational standards like http. just see how time tested the standards surrounding http are:

Standards

Extensions

The WebDAV SEARCH method (2008) was the early inspiration for QUERY — drafts even used the name SEARCH before the working group settled on QUERY to avoid the WebDAV baggage and map cleanly onto the URI query component.

HTTP anything

Don't believe HTTP TANGO would work? Just clone my little fun project, run it and open the developer tools to watch the network.
Works, since it controls both ends.

Tooling needs to catch up

Now QUERY is a standard, tooling needs to catch up. Enums need extension and adjacent standards updated. E.g OpenAPI 3.x has no provision for new HTTP syntax, while Bruno and curl do just fine.

As usual YMMV

Common to all collaboration platforms is the ability to define what items (files, emails, chats, videos) get shared with whom and how (read-only, read-write, comment). What is missing is sharing the intend or purpose. There is what, who, how but not why.

Formal workflow systems on the other hand, while rigid in the way they operate, thrive on intend: "for review", "for approval", "for risk analysis" and so on.

Finding the middle ground

Capturing the purpose or intend allows to uncover actual (soft) workflows. The challenge to solve is to make it worthwhile to the regular users to declare their intend (which by itself is hilarious: how to declare the intend "cover-my-backside" in office compatible lingo?)

A few ideas how to implement this:

• make it easy, the dialogue defining the share includes a field for intend. Most sharing dialogues allow notifications, so it is half way there
• adjust the language in the UX: add a "route to" capability
• integrate it into a task management system (I'd favour GTD)
• add a fancy dashboard to visualize flows
• find promoters who are keen to try that way of work
• use machine learning to predict the routing (been there, done that)

Is this a good idea, what do you think?

There are infinite opinions available how to use AI in software development. I haven't formed one, so I'm documenting what, so far has worked for me. I distinguish between the ideation phase, which's output is a set of specs, issues, tickets, whatever you call it and the implementation phase, which's output is working code.

The two phases run in sequence (doh), but not exclusive. E.g. while feature one and two run through implementation, feature three and four csn be in ideation. This post is about the implementation phase.

Chinese whispers (AI edition)

Based on the ideation phase I start with a set of github issues. They tend to be more than single sentence descriptions of an desired outcome. I launch multiple instances of Claude using claude -w, to enable the git worktree support. The exact number depends on your willingness to endure frequent context switching, I'm old so I stick to 2-4.

In each instance I follow the same prompt: "Plan and implement issue #42, share your assumptions, ask clarifying questions, outline options and seek approvals"

AI goes through a round of questions and challenges until we reach consensus and it implements the task at hand. Once done it creates a pull request. The creation of the pull request triggers code reviews. Currently that's GitHub Copilot review and CodeRabbit AI (disclaimer: the link is a referral link). Both agents review the code, come to conclusions and share them in conversations in the pull request. What's interesting is that they both highlight different issues with limited overlap. I'm particularly fond of CodeRabbit's "nitpick" level of feedback.

Once their review is completed, I let the PR merge, most of the time more that one from the various work trees. To close the feedback loop I then prompt: "Visit all pull requests [timeframe] and look for unresolved conversations. Assess each claim for merit and decide if it is still valid. When no longer valid, post your justification as comment. When still valid, create a new issue with detailed explanation and options, so any developer can understand and act on it, then add a comment linking to the issue. In both cases, mark the conversation as resolved."

This approach strikes a balance between "let the agent do its thing" and "keep the development transparent". If your source of truth for development tasks isn't GitHub issues, you need to adjust my approach.

All of this gets supported by CLAUDE.md, MCP, Skills, Tools etc, but that's another story for another time.

As usual YMMV

Continuing from Part 1: What if there is an alternative to a normalized RDBMS storage approach, that better fits the process flow?

The routing slip data model

Instead of looking at the physical entities (Suppliers, Ingredients, Cakes, Mixes, Slices etc.), look at the process steps and treat the process steps as our physical entities that store participating data.

The main difference to normalization is to treat data as process local. 1kg flour in the mixing state is a different datapoint from 1kg four in storage silo 3. Routing slips provide the transition. Key difference: Routing slips are accumulative. So the routing slip in the package process contains all the routing slip data of previous process steps. From a database perspective that is a deliberate data duplication, raising blood pressure for data architects.

In my junior developer days, literally last century, a senior developer enlightened me: "An open standard is only complete once its wording allows all participants to faithfully implement it to be absolutely incompatible to each other"

Ambiguity is king

Our modern software is build on a few standards which made progress at an unprecedented scale possible:

• Unicode
• HTTP
• HTML
• SMTP
• ECMA Script
• JSON
• OIDC

There are plenty more. Each of them have rock solid parts (nobody questions a <h1>) and parts of, let's call them disagreements. I'll pick on JWT as an example:

• agreed upon are the three parts: header, payload & signature
• agreed upon ia that the payload is JSON

The actual content of the payload is already subject to interpretation.

• Keycloak stands out for its flexibility and steep learning curve
• Refresh tokens are handled quite differently:
• Keycloak issues refresh tokens as JWT, others as opaque strings
• Okta doesn't issue refresh tokens for PKCE
• EntraID returns the Application ID in the aud field instead of an array of target servers, the iss parameter does't match the .well-known info
• PING Identity sends scopes not as space separated list, but as JSON array

And all implement "the standard"