Wuniq is becoming KaKeKiKoKu. During the transition, you may see both names while we complete the migration.

KaKeKiKoKu Studio / Roadmap

More context.
Less interruption.

There is more I want to build. These are the ideas I’m exploring to make project knowledge easier to consult, clearer to write, and closer to where you work.

Last updated

The everyday experience

Keep the knowledge close.

Small interruptions add up. I want to make it easier to stay with the work in front of you.

Exploring

Read a reference.
Keep your place.

You’re writing a decision and need to check the architecture rule it links to. I want you to be able to open that reference beside your work, read its formatted content, and carry on writing.

A link to a subsection would show that specific subsection, with a way to open the original when you need more.

Less jumping between files.
Linked knowledge previewConcept
Your decision Validate each request

Keep access checks at the boundary.

Architecture / Access
Linked subsection Access rules

Every request needs a valid session.

Check once. Apply consistently.

Consult the reference without leaving your decision.

Exploring

The source and its meaning.
Side by side.

I’m exploring a split view that would put an original text or code file alongside its editable context. You could document a function while looking at it, or explain a document with the source still in view.

An adjustable divider would let you choose the balance, then return to a single view when you want the space back.

Write the explanation with the original in sight.
Source + contextConcept
Original file access.ts
if (!session) {
  return denied;
}

return allowed;
Project knowledge Why this check exists

Access requires a valid session.

Decision

Reject early, before reading any private data.

One place to read the source and explain the reasoning.

Exploring

Make the important
parts stand out.

A warning, a practical tip, or a good example can get lost in a long explanation. I want to explore simple Markdown callouts that give those passages a clear visual identity.

The idea is to keep them easy to write and readable in plain text, with a consistent appearance in reading and preview views.

The right detail, easier to notice.
Markdown calloutsConcept
Tip

Capture the reason while it is fresh.

Warning

Check the assumptions before reusing this decision.

Example

“We chose this approach to keep deployment simple.”

A little emphasis, where it helps the reader.

Everyday use, considered carefully

Find your way. See the impact.

Reach the right knowledge with fewer steps, understand what depends on it, and make each action easier to judge.

Type a name. Choose a match. Open it.
Exploring

Navigate by keyboard.

I want to explore a quick way to open a file, entity, or section by typing part of its name, keeping your hands on the keyboard.

To work out: useful shortcuts can conflict with the browser’s own controls. The key combinations and interaction need investigation before settling on a design.

Trace the incoming links before deciding.
Exploring

See the impact before deleting.

Before removing a resource, its context, or a section, I want a clear view of the incoming references that would be affected, including the names of the blocks and resources they come from.

The aim is to make those dependencies visible while you can still review them, before confirming the deletion.

Which blocks point here, and why?
Needs study

Rethink incoming references?

Incoming references already exist. I want to study whether their presentation makes it easy to understand which parts of a project rely on the knowledge you are reading.

An open question: “clearer” still needs a concrete meaning. There is no proposed redesign yet; first I need to identify a real difficulty and establish what would improve it.

Let the situation guide the available actions.
Needs study

The right action, at the right time.

I want to study everyday workflows so controls can respond more helpfully to the situation: highlighting a button when it matters, disabling an action when it cannot apply, and making the reason understandable.

A small contextual action palette is one possibility. The approach remains open and needs substantial interaction design before choosing a solution.

Your tools, connected

Closer to where you work.

I also want to bring the knowledge experience closer to the editors and AI workflows you choose.

Exploring

Visual Studio Code

I’m exploring a KaKeKiKoKu Studio extension that would bring the knowledge experience directly into Visual Studio Code, alongside the code you are working on.

The aim: less switching between your editor and your project’s context.

Exploring

OpenCode

OpenCode already has a KaKeKiKoKu integration guide. I want to keep exploring a closer fit with its open, flexible workflow, making project knowledge easier to use throughout a working session.

The aim: a smoother connection between the AI’s work and the context behind it.

Read the current OpenCode guide
A longer horizon

Project context for more people.

Long term

KaKeKiKoKu Studio on macOS.

I would like people on macOS to have access to the same system of connected project context: decisions, explanations, and relationships that stay with their work.

This is a longer-term direction, with no release date. It needs time for proper platform testing and ongoing care alongside Windows and Linux.

The same idea. A wider welcome.