Building v0.1: The 4th Gen & Notion Shift

I am currently working on Release 0.1. Recently, I completed the project discovery phase. I wouldn't say I hit "hard walls," but a significant amount of time went into refactoring. In fact, I completely closed the GitHub project board and have fully moved to Notion for task management.

The bulk of the work has been a massive refactor. You can see the start of it in this commit. I re-created the utils, types, and cli packages with a new structure.

Why rewrite it?

You might ask: Why are you rewriting it? To be honest, this is the 4th time I've rewritten it.

I found hard issues in the previous build. But the real problem was that I was stuck without a proper task management system. I was coding without a map. The current build targets Notion as the source of truth. The new rule is simple: Document first, then code.

Before I wrote a single line of code for this refactor, I spent almost a week just documenting what it would be. It makes you think: What is actually going on? Why didn't I start this way earlier? The truth is, I just wasn't that type of person. I wanted to build, not plan. But now, alongside the project, I am growing too.

Fighting Gravity

I am also fighting with Antigravity. It is powerful (accessing code and web simultaneously), but it struggles with context.

In my session, I set the context for "project discovery", but after a few prompts, it loses the plot and jumps forward to future tasks like Adapters or tsconfig syncers. It runs forward to be fast, even when I just need to review the previous step.

I found a workaround: Resetting.

I create a new session and feed it the artifacts from the old session as data. This forces it to stop running forward and just think on the provided data.

The Flip Side (Notion AI)

But here is the contrast. The same Gemini models, running inside Notion?

Voila.

It is working so well. The context holds. The logic flows. It feels like a completely different tool. I have to say it: I love @NotionHQ for the product they are building. Thanks to them.

Discovery & Detection (Core Working)

And just like that, the core discovery logic is functioning.

The core rule is simple: we look for the workspaces field in package.json. That is the entry point for working with monorepos.

The logic follows two steps:

1. Find the root: Locate the root package.json with the workspaces definition. Its directory becomes the workspaceRoot.
2. Parse and Detect: Scan the packages, parse their configs, and map the structure.

The result looks something like this:

[
  {
    name: '@example/app-one',
    root: '.../packages/app-one',
    config: { name: '@example/app-one', version: '0.0.0-dev.0' },
    configFile: '.../packages/app-one/package.json'
  },
  {
    name: '@example/lib-one',
    root: '.../libs/lib-one',
    config: { name: '@example/lib-one', version: '0.0.0-dev.0' },
    configFile: '.../libs/lib-one/package.json'
  }
]

It’s real. It’s detecting. It’s working.

This is just the basic detection logic. In later releases, I will work on making it truly understand the project, not just find it. But for now, it's a start.