Skip to content

refactor(install): unify install/update paths on install.sh#198

Open
floodsung wants to merge 1 commit into
mainfrom
fix/unify-install-update
Open

refactor(install): unify install/update paths on install.sh#198
floodsung wants to merge 1 commit into
mainfrom
fix/unify-install-update

Conversation

@floodsung

Copy link
Copy Markdown
Contributor

Summary

  • Single source of truth: `metabot update` and `mb update` now `exec bash install.sh` instead of reimplementing the update flow. Three parallel code paths had drifted (e.g. `install.sh` was missing `skill-hub` before fix: add skill-hub and voice to install scripts #183; `bin/metabot` update loop was missing it before fix: add skill-hub to metabot update command #184) — collapsing to one path removes the drift entirely.
  • Fixes `mb skills` shadow bug: removed the inline `mm()`/`mb()` bash functions that `install.sh` used to write into `/.bash_aliases`. Shell functions take priority over PATH executables, so the inline `mb()` (which lacks the `skills` subcommand) shadowed the full `/.local/bin/mb` — `mb skills list` silently fell through to the help branch. Migration step strips legacy blocks from any existing `~/.bash_aliases`.
  • Misc install.sh polish: skips the lark-cli prompt on re-run when skills are already installed; `cp -r` the full `src/skills/skill-hub/` directory (captures any future `references/` bundle) instead of just `SKILL.md`.

Net diff: ~43 insertions, ~390 deletions.

Test plan

  • `bash -n install.sh bin/metabot bin/mb` — syntax OK
  • `npm run lint` — 0 errors (3 pre-existing warnings unchanged)
  • `npm test` — 183/183 passing
  • `npm run build` — green
  • Simulated the `sed` cleanup on a synthetic `~/.bash_aliases` that had both legacy blocks plus user-defined aliases above and below — user aliases preserved, both legacy blocks removed
  • Manual: run `metabot update` on an existing install; confirm it delegates to `install.sh`, skips Phase 4 (`.env` exists), installs `skill-hub`, cleans up legacy inline `mm()`/`mb()` if present, restarts via PM2
  • Manual: run `mb skills list` after update; confirm the PATH executable now wins (it was masked by the legacy inline `mb()` before)

🤖 Generated with Claude Code

install.sh becomes the single source of truth for both fresh installs and
`metabot update` / `mb update`. Previously three parallel code paths existed
and had drifted (e.g. install.sh was missing the skill-hub skill install;
bin/metabot did not install phone-call/skill-hub that bin/mb did).

- install.sh no longer writes inline mm()/mb() bash functions to
  ~/.bash_aliases. Those functions shadowed the standalone
  ~/.local/bin/{mm,mb} executables on PATH and caused new subcommands like
  `mb skills` to silently fall through to the help branch. A migration step
  strips any legacy blocks from an existing ~/.bash_aliases.
- install.sh Phase 6 now installs the skill-hub skill and deploys it to the
  bot workspace; auto-refreshes lark-cli skills on re-run instead of
  re-prompting when they are already installed.
- bin/metabot update and bin/mb update collapse to `exec bash install.sh`.
  install.sh already handles git pull + self-re-exec + .env-guarded Phase 4
  + Phase 8 PM2 restart.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@floodsung

Copy link
Copy Markdown
Contributor Author

Status check on this PR after ~3 weeks — I verified the original motivation against current main:

So the PR's value is intact, but it now conflicts with PR #202's Kimi engine selection logic on install.sh and the bin scripts.

Two reasonable paths:

  1. Rebase: ~30 min of manual conflict resolution, keeping the inline-function deletion + delegation-to-install.sh while preserving feat(kimi): install.sh engine selection + metaskill dual-engine + docs #202's engine selection prompts. Then merge.
  2. Close + re-open as smaller PRs: split into (a) "remove inline mm()/mb() from bash_aliases" alone, (b) "delegate mb update/metabot update to install.sh" separately. Each is much smaller and less conflict-prone.

I'd lean toward (2) — the original unification was a single-PR refactor with three coupled concerns; in retrospect smaller PRs would have avoided exactly this rot. Your call.

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.

1 participant