Oriented user to monorepo packages.
UnderstandChecked current version and changelogs.
VerifyVerified path handling in code and docs.
Understandhow we going?
The user is asking a casual greeting/check-in question. They're not giving me a concrete task, so according to the AGENTS.md rules, I should read the README.md and ask which module(s) to work on.
Hey! All good here. Let me get oriented.
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.
This is the pi monorepo with packages for:
What would you like to work on?
ok, let's do a new minor release 0.50.0
The user wants to do a minor release to version 0.50.0. According to AGENTS.md, I need to:
[Unreleased] sectionnpm run release:minorLet me first check the current version and the state of the CHANGELOGs to see what's in the [Unreleased] sections.
Let me check the current version and the state of the CHANGELOGs across packages.
>cd /Users/badlogic/workspaces/pi-mono && cat package.json | grep '"version"' | head -1Looking at the CHANGELOGs:
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.
Current version is 0.49.3. The CHANGELOGs have content in [Unreleased] for:
The agent, mom, and web-ui packages have empty [Unreleased] sections (no changes since 0.49.3). Pods doesn't have a CHANGELOG.
Running the minor release:
>cd /Users/badlogic/workspaces/pi-mono && npm run release:minor 2>&1There's an uncommitted file. Let me check what it is and ask the user what to do with it.
There's an uncommitted file blocking the release:
?? .pi/extensions/redraws.tsThis is an untracked file in .pi/extensions/. Should I remove it or add it to .gitignore? (It looks like a local development/testing file.)
ah commit that, just a helper for me during development of coding anget
The user wants me to commit this file. It's a helper file for development.
>cd /Users/badlogic/workspaces/pi-mono && git add .pi/extensions/redraws.ts && git commit -m "add redraws helper extension for TUI development"Good, committed. Now let me run the release script again.
Now running the release:
>cd /Users/badlogic/workspaces/pi-mono && npm run release:minor 2>&1The release completed successfully! All packages have been published to npm at version 0.50.0:
The script also:
Done! Released v0.50.0 to npm:
| Package | Status |
|---|---|
| @mariozechner/pi-ai | ✓ published |
| @mariozechner/pi-agent-core | ✓ published |
| @mariozechner/pi-coding-agent | ✓ published |
| @mariozechner/pi-mom | ✓ published |
| @mariozechner/pi | ✓ published |
| @mariozechner/pi-tui | ✓ published |
| @mariozechner/pi-web-ui | ✓ published |
Tag v0.50.0 pushed to GitHub. CHANGELOGs updated with new [Unreleased] sections for the next cycle.
+path and -path are exact paths relative to the package root.
Omit a key to load all of that type. Use [] to load none of that type. !pattern excludes matches. +path force-includes an exact path. -path force-excludes an exact path. Filters layer on top of the manifest. They narrow down what is already allowed.
from @packages/coding-agent/docs/packages.md are they really relative to the package root? check other .md files as well, possibly @packages/coding-agent/docs/settings.md for such things
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:
+pathand-pathare exact paths relative to the package root.
But in settings.md, it says:
Paths in
~/.pi/agent/settings.jsonresolve relative to~/.pi/agent. Paths in.pi/settings.jsonresolve relative to.pi. Absolute paths and~are supported.
And also:
Arrays support glob patterns and exclusions. Use
!patternto exclude. Use+pathto force-include an exact path and-pathto force-exclude an exact path.
So there's a distinction here:
Let me check the actual implementation to verify this behavior. I should look at the resource loader code.
Let me check the implementation to verify what paths are actually relative to:
>cd /Users/badlogic/workspaces/pi-mono && rg -n "relative to" packages/coding-agent/src --type ts | head -30>cd /Users/badlogic/workspaces/pi-mono && rg -n "force-include|force-exclude|\+path|-path" packages/coding-agent/src --type ts | head -20Let 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:
>cd /Users/badlogic/workspaces/pi-mono && rg -n "matchesAnyExactPattern|matchesAnyPattern" packages/coding-agent/src/core/package-manager.ts -A 10 | head -50Looking at the code:
matchesAnyPattern and matchesAnyExactPattern both take a baseDir parameterrel = relative(baseDir, filePath) to get the relative pathFor 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.
>cd /Users/badlogic/workspaces/pi-mono && rg -n "applyPatterns|isEnabledByOverrides" packages/coding-agent/src/core/package-manager.ts -B 2 -A 5 | head -80I see that applyPatterns is called with packageRoot as the baseDir. This confirms that:
+path and -path are relative to the package rootLooking 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)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:
The current documentation seems accurate to me. Let me double-check by searching for any other relevant references.
The documentation is accurate. Looking at the code:
Package filters (object form in packages array):
applyPatterns(allFiles, userPatterns, packageRoot) at line 1137Top-level settings arrays (extensions, skills, prompts, themes):
applyPatterns(allFiles, patterns, baseDir) at line 1231 where baseDir is the settings directory~/.pi/agent or .pi depending on which settings.jsonBoth docs are correct for their respective contexts:
The docs are consistent. Was there a specific case you were seeing that seemed wrong?
?? .pi/extensions/redraws.ts