🔌 v0.6.0: proper channel isolation between tmb (stable) and tmb-rc (RC) — currently both activate as 'tmb'

[ZaxShen]

Background

Surfaced during v0.5.0-rc.8 manual test. Both `tmb` and `tmb-rc` marketplace entries point at the same plugin source (different branches), but the activated plugin name is always `tmb` because `plugin.json`'s `name` field controls install identity, not the marketplace channel name.

Result: installing both channels simultaneously means both write to `.claude/tmb/trajectory.db` in your project, sharing state. CC matches install on plugin name only, ignoring the marketplace qualifier (anthropics/claude-code#20593).

Proper fix options

Option 1: Two separate marketplaces (CC-blessed pattern)

Per the Claude Code plugin marketplace docs and a community write-up:

"Use different names for the marketplace and plugin in marketplace.json ... To support 'stable' and 'latest' release channels for your plugins, you can set up two marketplaces that point to different refs or SHAs of the same repo."

Implementation:

• `trustmybot/marketplace-stable` → marketplace `trustmybot` → plugin `tmb` (from `main`)
• `trustmybot/marketplace-rc` → marketplace `trustmybot-rc` → plugin `tmb-rc` (from `rc`)

Each repo has its own `marketplace.json` pointing at the right ref. Plugin sources can stay in `trustmybot/plugin`; marketplace.json indirects.

Users:

• Stable: `/plugin marketplace add trustmybot/marketplace-stable` then `/plugin install tmb@trustmybot`
• RC: `/plugin marketplace add trustmybot/marketplace-rc` then `/plugin install tmb-rc@trustmybot-rc`

Pro: matches CC's design intent. Different DB paths (`.claude/tmb/` vs `.claude/tmb-rc/`). Co-installable.

Con: requires 2 new repos + ongoing marketplace.json maintenance per repo.

Option 2: Templated plugin name with build pipeline

Keep one marketplace; the `rc` branch's `plugin.json` ships with `"name": "tmb-rc"` (one-line diff vs `main`). Release ritual scripts + `scripts/release.sh` handle the rename when ff'ing the rc branch or promoting to main.

Plus: every reference to `mcp__plugin_tmb_trajectory-server__*` in agent prompts / hooks must become channel-agnostic — either:

• Wildcard (regex matchers; hooks already do this for the `task_update_status` matcher)
• Templated at build time
• Resolved dynamically by reading the active plugin name from somewhere

Pro: keeps single marketplace, cleaner UX for users.

Con: plugin-name reference refactor across ~20 files; release pipeline complexity.

Recommendation

Option 1 — matches the CC-blessed pattern, keeps the agent prompts/hooks plugin-name-agnostic if we use wildcards consistently, gives users co-install. The marketplace-repo split is one-time setup; ongoing toil is just `marketplace.json` ref bumps when cutting tags.

Out of scope for v0.5.0

This is genuinely a v0.6.0 (or v1.0.0) refactor. v0.5.0 ships with the documented caveat: pick one channel, stick with it. See `tests/manual/setup.md` Path B for the workaround note + linked CC issues.

[ZaxShen]

Additional rationale: contributor add-on staging pipeline

Per Daisy: the two-marketplace pattern naturally enables a contribution staging pipeline for third-party add-ons (additional plugins, skills, agent templates, MCP servers built by contributors / community).

Pipeline shape

Contributor → fork → PR → merge to dev/rc branch
                                ↓
                  trustmybot-rc marketplace (tmb-rc + add-on-rc plugins)
                                ↓ validate via /plugin install <addon>-rc@trustmybot-rc
                  Daisy / TMB team smoke-tests the add-on
                                ↓ promote
                  trustmybot marketplace (tmb + addon plugins, stable)

Two-marketplace isolation means:

• Contributors test their add-ons against tmb-rc without polluting stable users
• Add-ons can iterate independently from the core plugin (their own RC cycles)
• Stable-channel users see only what's been validated through the rc pipeline
• Failure of an add-on never breaks the core plugin's stable channel (different marketplace)

Naming convention extension

The same plugin-vs-channel-name discipline applies to add-ons:

• Marketplace: trustmybot-rc (channel)
• Plugin: tmb-medical-rc, tmb-fintech-rc, etc. (each its own plugin.json with the -rc suffix in name)
• Stable promotion: drop the -rc suffix (marketplace trustmybot, plugin tmb-medical)

This makes the v0.6.0 work load-bearing not just for stable/RC of the core plugin but for the entire ecosystem evolution. Worth doing right.

[ZaxShen]

Concrete v0.6.0 plan (per Daisy follow-up — not actively worked yet)

Repo structure

Repo	Purpose	Contents
trustmybot/plugin (current)	Plugin source. Branches main (stable) and rc (pre-release)	agents/, skills/, mcp/, hooks/, etc.
trustmybot/marketplace (new — separate from plugin source)	Stable marketplace registry	Just a marketplace.json pointing at trustmybot/plugin@main, plugin name tmb
trustmybot/marketplace-rc (new)	Pre-release marketplace registry	Just a marketplace.json pointing at trustmybot/plugin@rc, plugin name tmb-rc

What changes in trustmybot/plugin

• main branch's plugin.json keeps name: "tmb" (current).
• rc branch's plugin.json gets a permanent one-line diff: name: "tmb-rc".
• Release ritual handles the rename when ff'ing rc — automated step in scripts/release.sh or a separate scripts/cut-rc.sh.

User-facing install commands

# Stable (current users — backwards compatible if we keep marketplace name 'trustmybot')
/plugin marketplace add trustmybot/marketplace
/plugin install tmb@trustmybot

# RC (new)
/plugin marketplace add trustmybot/marketplace-rc
/plugin install tmb-rc@trustmybot-rc

What this fixes

• DB paths actually differ: .claude/tmb/ vs .claude/tmb-rc/ — co-installable
• Plugin install screen shows tmb-rc for RC users (currently shows tmb regardless)
• Extends naturally for contributor add-ons: trustmybot/marketplace-rc can host tmb-rc AND tmb-medical-rc, tmb-fintech-rc, etc.; trustmybot/marketplace hosts only validated stable plugins

Known cost — the actual bulk of v0.6.0 work

Agent prompts and MCP tool references hardcode mcp__plugin_tmb_trajectory-server__*. With name: "tmb-rc" on the rc branch, CC generates tool names as mcp__plugin_tmb-rc_trajectory-server__* — every reference to the tmb_ prefix in agent prompts breaks for RC users.

Affected paths (rough scope):

• agents/swe.md — explicit MCP tool name in atomic-close
• agents/pr-reviewer.md — same
• skills/tmb_*/SKILL.md — MCP tool names in skill bodies
• docs/architecture/RESPONSIBILITIES.md — references in matrix
• docs/architecture/ENFORCEMENT.md — same
• Hooks already use regex matchers (mcp__.*trajectory-server__*) — channel-safe ✓

Solutions to evaluate:

1. Wildcard everywhere — agent prompts use mcp__*_trajectory-server__<tool> notation (if CC's prompt-side resolution supports glob)
2. Template at build time — scripts/release.sh runs sed across files to substitute the right plugin name based on target branch
3. Resolve dynamically — bro reads its own plugin name from a known location at activation, uses that prefix

Likely combo: regex/wildcard where CC supports it; template at build time for everything else.

Work breakdown (rough)

1. Create trustmybot/marketplace and trustmybot/marketplace-rc repos with seed marketplace.json files.
2. Decide on plugin-name-prefix solution (wildcard / template / dynamic).
3. Refactor affected files (~15-20).
4. Update scripts/release.sh to handle the rc-branch plugin.json rename automatically.
5. Update tests/manual/setup.md and README.md with new install commands.
6. Migration note for existing users (/plugin marketplace remove trustmybot/plugin → /plugin marketplace add trustmybot/marketplace).
7. Validate via L5 dogfood + release-canary on RC branch with new name: "tmb-rc".

Estimate: ~1 week of focused work. Genuinely v0.6.0 territory; not a v0.5.x patch.

[ZaxShen]

Closing — focusing on v0.8.x. Planning lives on GitLab milestones (v0.8.0 / v0.8.1). Will re-mirror active items to GH once tri-source schema sync (#48) lands.