Skip to content

fix(context): use CLI package version when repo is a private workspace root#169

Merged
stackbilt-admin merged 2 commits into
mainfrom
fix/context-version
May 23, 2026
Merged

fix(context): use CLI package version when repo is a private workspace root#169
stackbilt-admin merged 2 commits into
mainfrom
fix/context-version

Conversation

@stackbilt-admin
Copy link
Copy Markdown
Member

Summary

  • charter context was reading version from path.join(cwd, 'package.json'). On the charter monorepo, that resolves to the private workspace root (version: 0.10.0) instead of packages/cli/package.json (version: 0.16.0)
  • Fix: statically import the CLI's own package.json and fall back to its version when pkg.private === true. Private workspace roots carry no meaningful published version — the installed CLI version is the right signal
  • Change is in context.ts (~3 lines). No behavioural change for normal single-package repos

Test plan

  • New test: private: true workspace root → brief shows CLI version, not v0.1.0
  • New test: normal non-private package → brief shows repo's own version (v3.7.2)
  • pnpm test — 492/492 pass

Closes #161

🤖 Generated with Claude Code

…e root

charter context read version from path.join(root, 'package.json'), where
root is cwd. On the charter monorepo itself this resolves to the workspace
root (private: true, version: 0.10.0) rather than packages/cli/package.json
(version: 0.16.0), causing the brief to show an outdated version.

Fix: import the CLI's own package.json statically and fall back to its
version whenever the analysed repo's package.json has private: true. Private
workspace roots have no meaningful published version; the installed CLI
version is the correct signal for AI agent context.

Adds two regression tests: private root uses CLI version, normal package
uses its own version.

Closes #161

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@stackbilt-admin
Copy link
Copy Markdown
Member Author

I found one behavioral risk in this fix: the private true fallback to CLI version is broader than issue 161. Private true is common for single-package internal apps too, so this can replace legitimate app versions with the CLI version in normal repos. Please narrow this to private workspace roots (for example private true plus a workspace marker) or gate on explicit CLI package identity. That keeps the charter-monorepo fix without changing version semantics for other private repos.

The previous fix fell back to the CLI version for any private: true
package. That's too broad — private is common for single-package internal
apps that have their own meaningful version.

Narrow the guard to private: true AND workspaces != null, which precisely
targets monorepo workspace roots (the only case where version is stale).

Adds a test: private-but-no-workspaces internal-app preserves v2.4.1.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@stackbilt-admin
Copy link
Copy Markdown
Member Author

Fixed in 4f0b6ba — guard narrowed to pkg.private === true && pkg.workspaces != null. That targets only monorepo workspace roots; plain private internal apps (no workspaces field) now keep their own version. Added a third test case to lock this in: internal-app with private: true but no workspaces must show v2.4.1, not the CLI version.

@stackbilt-admin stackbilt-admin merged commit 3a8c761 into main May 23, 2026
3 checks passed
@stackbilt-admin stackbilt-admin deleted the fix/context-version branch May 23, 2026 09:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug(context): version in brief reflects root workspace package.json (0.10.0) not CLI package (0.16.0)

1 participant