npm Trusted Publishing (OIDC) Automation in Shelly

## Feature Area

Which Shelly feature area would this enhancement target? (check one)

- [ ] 🔍 Error Analysis (command analysis, shell integration, AI suggestions)
- [ ] 🏗️ Repository Organization (project scaffolding, GitHub integration, file organization)
- [ ] 🧠 Memory Bank (AI context management, documentation generation)
- [ ] 🔧 CLI Interface (command parsing, user experience, new commands)
- [ ] 🤖 AI Integration (new AI providers, improved analysis)
- [ ] 📱 Platform Support (new shells, operating systems)
- [x] 🔌 Extensibility (plugins, integrations, APIs)

## Problem Statement

**Is your feature request related to a problem? Please describe.**
Shelly currently relies on **long-lived npm access tokens** for publishing npm packages from CI/CD pipelines.
npm has deprecated this approach in favor of **Trusted Publishing using OpenID Connect (OIDC)**, which removes the need for stored secrets and aligns with **OpenSSF supply-chain security standards**.

Continuing to use npm tokens introduces:
- Risk of credential leakage
- Manual secret rotation overhead
- Weak provenance guarantees
- Misalignment with modern registry security practices

**Current Workflow:**

- Developers manually generate npm tokens
- Tokens are stored as CI/CD secrets
- Pipelines authenticate using these long-lived tokens
- Rotation and auditing are manual and error-prone

## Proposed Solution

**Describe the solution you'd like**

Introduce **first-class support in Shelly for npm Trusted Publishing via OIDC**, including **automation for Bitbucket Pipelines**.
This enables secure, secretless publishing where npm verifies CI identity before allowing package publication.

Shelly should:
- Handle OIDC authentication
- Configure npm Trusted Publisher metadata
- Eliminate the need for npm tokens

**Ideal User Experience:**
1. User enables npm publishing in Shelly
2. Shelly detects the CI provider (Bitbucket / GitHub)
3. Shelly configures npm Trusted Publisher automatically
4. CI pipeline publishes without npm tokens
5. npm validates CI identity via OIDC

```bash
# Example commands or workflow
shelly publish npm --provider bitbucket --package @org/package
```

## Feature Details
N/A

## Use Cases

**Target Users:**

- [ ] Individual developers
- [ ] Development teams
- [ ] Open source maintainers
- [ ] Enterprise development
- [ ] Educational use
- [ ] AI-assisted development

**Specific Scenarios:**

- Individual developers
- Development teams
- Open source maintainers
- Enterprise development
- Educational use
- AI-assisted development

## Alternatives Considered

**Describe alternatives you've considered**

- Continue using npm tokens with periodic rotation
-
- Manual Trusted Publishing setup outside Shelly
-
- Custom CI scripts for OIDC handling

**Existing Tools:**

-
- npm supports Trusted Publishing natively
-
- GitHub Actions provides partial support
-

### Why Shelly should handle this

- Centralized automation
-
- Multi-provider support (especially Bitbucket)
-
- Reduced configuration and human error

## Implementation Suggestions

### Technical Approach

- Integrate **npm Trusted Publisher APIs** to register and manage trusted publishers.
- Implement **OIDC token exchange** between Shelly-managed CI workflows and npm.
- Map **CI claims** (repository, branch, workflow, environment) to npm trusted publisher rules.
- Enforce **identity validation** before allowing any publish action to proceed.

### Integration Points

- Shelly **CI/CD orchestration layer** (pipeline execution and auth handling)
- **Repository metadata detection** (repo name, owner, default branch, workflow identity)
- Existing **package publish workflows** within Shelly

### Configuration

- Toggle to **enable / disable Trusted Publishing**
- CI provider selection (GitHub Actions, **Bitbucket Pipelines**)
- Branch and environment-level restrictions
- Optional **fallback to token-based publishing** for legacy setups

---

## Compatibility & Requirements

### System Requirements

- **Operating systems**: macOS, Linux, Windows
- **Shells**: bash, zsh
- **Node.js**: >= 16
- **Dependencies**: OIDC client libraries

### Backward Compatibility

- [ ] This is a breaking change
- [x] This maintains backward compatibility
- [x] This adds new optional functionality

---

## Priority & Impact

### Priority Level

- [ ] Low
- [ ] Medium
- [ ] High
- [x] **Critical**

### Expected Impact

- **User Experience**: Eliminates secret management and simplifies CI pipelines
- **Adoption**: Improves enterprise readiness and compliance
- **Ecosystem**: Aligns Shelly with OpenSSF and modern CI/CD security standards

---

## Success Criteria

### Acceptance Criteria

- [ ] npm publishing works without npm tokens
- [ ] OIDC-based authentication is enforced
- [ ] Bitbucket Pipelines are fully supported
- [ ] CI identity is cryptographically bound to package publishing
- [ ] Clear migration path from tokens → OIDC

### Testing Requirements

- [ ] Unit tests for OIDC authentication flows
- [ ] Integration tests with the npm registry
- [ ] CI validation for Bitbucket Pipelines and GitHub Actions
- [ ] Failure, rollback, and misconfiguration handling

### Documentation Requirements

- [ ] README.md updates
- [ ] Trusted Publishing setup guide
- [ ] Migration documentation (tokens → OIDC)
- [ ] Security and trust model explanation

---

## Additional Context

### References

- npm Trusted Publishing documentation:
https://docs.npmjs.com/trusted-publishers

### Related Issues

- npm token deprecation
- Supply-chain security hardening initiatives

### Community Interest

- Growing demand for **secretless CI/CD**
- Increasing adoption of **OpenSSF Trusted Publishers**

### Timeline

- **Recommended for next major Shelly release**
- Reason: npm token-based publishing is actively discouraged and increasingly insecure

---

Start with README.md, the CI/CD orchestration layer, repository metadata detection, and existing package publish workflows named in the issue, then review the npm Trusted Publishing documentation. Done means tokenless npm publishing with OIDC, Bitbucket and GitHub Actions support, identity validation, migration guidance, and the requested unit, integration, and CI tests.

Written by the indexing model from the issue text.