October 28, 2026

1.22: the Git release

Knowledge that travels with your project, with less repository noise. Another step toward stability.

Leaving Alpha was an important achievement for KaKeKiKoKu Studio. Now the work continues toward removing the Beta label too. I want to reach a fully stable version, and that means spending time checking how the product behaves when projects change, are shared and move between computers.

The previous release was an important step in that direction. I added a battery of automated tests that goes through the application, performs real operations and checks what was left on disk. That work uncovered bugs that could be fixed and established a safer process for preparing the next releases.

It also brought to light the problems that shaped this release. If I had to give 1.22 a name, it would be “the Git release.”

When Git shows changes you did not make

A project’s knowledge lives in .wuniq files, alongside the files it refers to. If you use Git, you can version it, review its changes and share it with the rest of the project. That is one of the reasons for keeping it there.

But working between Windows and Linux produced noise. A file could keep the same content and have a different timestamp on another computer. Git could change its line endings during a checkout without changing the text you read. Studio interpreted some of those differences as changes and could end up rewriting contexts whose knowledge was still the same.

The contexts themselves also stored an edit timestamp. That was another value that could cause a conflict between branches even when the important content did not conflict.

A project with knowledge beside its files needs to work well with those everyday operations. Opening it on another computer or switching branches should not fill the repository with modifications nobody intended to make.

What changes in 1.22

Knowledge files no longer store the timestamps and sizes that depended on the computer. Studio still uses that information in memory to work efficiently, but no longer needs to write it into the repository.

Content comparison also recognises the same text as equivalent with Windows or Linux line endings. And analysing a project no longer rewrites contexts to refresh that metadata.

A real content change still produces the corresponding warning. The aim is to let you spend your attention reviewing what actually changed and keeping its knowledge up to date.

There is another adjustment related to that review: editing a block of context no longer marks its companion file as reviewed. You can correct one explanation without having checked all the others. The warning that a context may be out of date remains until it is explicitly acknowledged, through sync ack or the corresponding action in the application.

A format update

These changes bring the Wuniq format to 1.2. When you open an older project, Studio creates a safety copy and updates its contexts automatically. The migration preserves the knowledge, its identifiers and its relationships; it changes the information managed by the engine.

There is a consequence you should know before updating: Studio 1.21 and earlier are not compatible with a project already migrated to 1.2. If you share the project, update Studio on every computer that uses it. The safety copy preserves the state from before migration.

Opening also shows progress when preparation takes time. And if a project uses a format newer than your installation understands, Studio refuses to open it and asks you to update.

Continuing toward stability

Verification for this release included real clones and branch checkouts, different Git configurations and line-ending conversions, also checking that the contexts remained intact. The complete battery passed on Windows, and the MCP/HTTP checks passed on Linux. Each result keeps its own scope; it does not mean every possible combination has been tested.

KaKeKiKoKu Studio remains in Beta. Release 1.22 continues the work of the previous version: using tests to find problems, fixing them and reaching the next publication with more evidence of how the product behaves.

This time, you can see that work especially when you look at the repository after opening a project, sharing it or switching branches. The knowledge still travels with it, with less noise around it.