Skip to content

The install verb places the payload at the configuration directory #313

Description

@sameera

As an adopter, I want one command that puts the components where Claude Code will find them, so that installing the package is followed by one explicit step and not by silence.

Acceptance Criteria

  • Given the package is installed and the install verb is run, when it completes, then the component payload is present at the Claude configuration directory, resolved from the configuration-directory environment variable with the home-directory default.
  • Given the location already holds an older Nexus component set, when the verb runs again, then the location matches the new payload exactly, with Nexus-namespaced files no longer in the payload removed.
  • Given the location holds files that are not Nexus-namespaced, when the verb runs, then those files are untouched.
  • Given the verb is run with the flag that points the location at a checkout's authored tree, when it completes, then the location resolves to that checkout, and the install verb's own output names the checkout path it pointed at.
  • Given the verb completes in either mode, when its output is read, then it prints the permission allowlist entry for each of the two named toolkits and states that it has written no settings file.
  • Given the verb has run, when the account-level settings file at the install location and the local settings file at the current repository root are each compared with their prior content, then neither has changed.

Notes

The primitive is deployComponents in libs/portable-tools/src/deploy-components.ts, and its target is already a parameter, already exposed as a flag on the deploy verb. The mirror-and-prune semantics are correct and tested and are not reimplemented.

The genuinely new work is resolving the configuration directory. Nothing in the toolkit resolves $CLAUDE_CONFIG_DIR or a home-directory default today — that resolution, its precedence and its failure modes are this story's actual substance, which is why it is M rather than S.

The second step is an explicit verb rather than a package-manager lifecycle script, deliberately: lifecycle scripts are blocked by default in the package manager this project uses and are commonly disabled in continuous integration, so a share of installs would end silently with no component set and no error. A silent partial install is worse than an explicit second command — particularly when the install has to print text the user must act on anyway.

One install location with two possible contents is what lets the maintainer's edit-and-rerun loop exist without an exemption the duplicate guard would have to carry.

Metadata

Metadata

Assignees

No one assigned

    Labels

    infrastructureBuild tooling, Nx/Vite/pnpm config, dev environment, CI/CDstoryUser story (created by nxs-gh-create-story)

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions