Prepared for minor release 0.50.0Public

Good, I've read the README. This is a monorepo with several packages for building AI agents. The user hasn't given me a specific task, so I should ask which module they want to work on.

The user wants to do a minor release to version 0.50.0. According to AGENTS.md, I need to:

1. Update CHANGELOGs - ensure all changes since last release are documented in the [Unreleased] section
2. Run the release script: npm run release:minor

Let me first check the current version and the state of the CHANGELOGs to see what's in the [Unreleased] sections.

Looking at the CHANGELOGs:

1. ai - Has substantial content in [Unreleased] section
2. agent - Has empty [Unreleased] section
3. coding-agent - Has substantial content in [Unreleased] section
4. tui - Has content in [Unreleased] section
5. mom - Has empty [Unreleased] section
6. pods - No CHANGELOG.md file exists
7. web-ui - Has empty [Unreleased] section

Current version is 0.0.3 in root package.json, but the packages show version 0.49.3 as the last release. Let me check a package's package.json to confirm the actual version.

The CHANGELOGs look good - they have proper [Unreleased] sections with content. I should run the release script. Since the user requested 0.50.0 specifically and we're doing a minor release, that should bump from 0.49.x to 0.50.0.

Let me run the release script.

There's an uncommitted file. Let me check what it is and ask the user what to do with it.

The user wants me to commit this file. It's a helper file for development.

Good, committed. Now let me run the release script again.

The release completed successfully! All packages have been published to npm at version 0.50.0:

• @mariozechner/pi-ai@0.50.0
• @mariozechner/pi-agent-core@0.50.0
• @mariozechner/pi-coding-agent@0.50.0
• @mariozechner/pi-mom@0.50.0
• @mariozechner/pi@0.50.0
• @mariozechner/pi-tui@0.50.0
• @mariozechner/pi-web-ui@0.50.0

The script also:

• Added [Unreleased] sections to all CHANGELOGs for the next cycle
• Committed and pushed the changes
• Created and pushed the v0.50.0 tag

The user is asking me to verify whether the paths in package filters are really relative to the package root. Let me read the packages.md and settings.md files to check.

Looking at the docs, I see the issue. In packages.md, it says:

+path and -path are exact paths relative to the package root.

But in settings.md, it says:

Paths in ~/.pi/agent/settings.json resolve relative to ~/.pi/agent. Paths in .pi/settings.json resolve relative to .pi. Absolute paths and ~ are supported.

And also:

Arrays support glob patterns and exclusions. Use !pattern to exclude. Use +path to force-include an exact path and -path to force-exclude an exact path.

So there's a distinction here:

1. For top-level settings arrays (extensions, skills, prompts, themes), paths are relative to the settings file location (~/.pi/agent or .pi)
2. For package filters (the object form in packages array), paths should be relative to the package root

Let me check the actual implementation to verify this behavior. I should look at the resource loader code.

Let me look at the package-manager.ts code to understand how paths are resolved in filters.

Let me look at the matchesAnyExactPattern function to understand how it handles the paths:

Looking at the code:

1. matchesAnyPattern and matchesAnyExactPattern both take a baseDir parameter
2. They compute rel = relative(baseDir, filePath) to get the relative path
3. They then match against both the relative path and the absolute path

For package filters, baseDir would be the package root. So +path and -path patterns are matched against paths relative to the package root.

The documentation seems correct. Let me verify what baseDir is passed when loading package resources.

I see that applyPatterns is called with packageRoot as the baseDir. This confirms that:

1. For package filters, paths like +path and -path are relative to the package root
2. For top-level settings arrays (extensions, skills, etc.), the baseDir is different (the settings directory)

Looking at line 1137: applyPatterns(allFiles, userPatterns, packageRoot) - user patterns for packages are resolved relative to the package root.

Looking at line 1231: applyPatterns(allFiles, patterns, baseDir) - for top-level paths, baseDir is the settings directory.

So the documentation is accurate. The paths in package filters ARE relative to the package root. Let me check where this other code is to make sure.

Looking at this more closely:1. For package resources (filter object in packages array):

• baseDir = packageRoot - so paths are relative to package root2. For top-level settings arrays (extensions, skills, prompts, themes in settings.json):
• baseDir = globalBaseDir (which is ~/.pi/agent) or projectBaseDir (which is .pi)
• So these paths are relative to the settings directory

The documentation in packages.md is correct: it says +path and -path for package filters are relative to the package root.

The documentation in settings.md also clarifies: "Paths in ~/.pi/agent/settings.json resolve relative to ~/.pi/agent. Paths in .pi/settings.json resolve relative to .pi."

Both docs are technically accurate, but they're describing different contexts:

• packages.md describes package filter paths (relative to package root)
• settings.md describes top-level resource array paths (relative to settings file location)

The current documentation seems accurate to me. Let me double-check by searching for any other relevant references.