# Source publication, releases and template activation

The private source repositories are `Humbleteam-team/humbleagents` and `Humbleteam-team/project-template`. Source upload, enabling GitHub's Template repository setting and creating a versioned release are separate operations. Obtain authorization for the operation being performed and use the maintainer's personal GitHub identity. Administrative access alone does not authorize publication.

## 1. Review the clean contents

Use the prepared humbleagents source and separate project-template directory. Do not clone/push the old studio repository into either destination. Do not copy its Git history, client projects, credentials, settings, hooks or sync scripts.

Build, generate, test and audit the final archive. Review README, verification.md, host limitations, THIRD_PARTY_NOTICES.md, template policy and file inventory. Keep `private: true` and `UNLICENSED` in the source manifest. Omit `node_modules`, compiled build output, local test reports, archives and local project caches from the source commit. Generated host surfaces are reviewed derived source and can be versioned.

The public npm archive exposes all included code, prompts and design references. Review the complete staged inventory for public distribution, including shared knowledge and third-party notices; a private source repository does not protect files copied into a public package. Keep project data, credentials and internal operating material out of the archive. Public distribution does not add a license grant: the package remains `UNLICENSED`.

## 2. Initialize and upload source

For an authorized first source upload, verify that the destination is private and empty, then initialize a fresh history in each reviewed source directory:

```sh
git init -b main
git remote add origin https://github.com/Humbleteam-team/REPOSITORY.git
git status --short
```

Set REPOSITORY to the respective target. Review the inventory, stage individual approved paths, create an initial commit, then `git push -u origin main`. Verify the remote branch and file hashes. For an existing source repository, use its normal reviewed commit workflow; do not replace its history or reuse first-upload instructions. Never stage the whole old studio tree. A maintainer must review any changes to branch protection/review policy separately.

## 3. Enable the template — separate approval required

After the clean project-template files have been reviewed and pushed, enable **Settings → General → Template repository**, or use the equivalent authorized GitHub API request:

```sh
gh api --method PATCH repos/Humbleteam-team/project-template -F is_template=true
```

Re-read repository metadata and verify private visibility, template flag, expected branch and content. Project creation uses the employee's own permissions through the template generation API. No client project migration is implied.

## 4. Produce a private GitHub release — separate approval required

Update the package/canonical/generated versions coherently. Build the archive through `npm run pack:local --prefix platform`; retain SHA-256 and verification evidence. An approved stable release uses tag `vX.Y.Z` and one asset named `humbleagents-X.Y.Z.tgz`. GitHub must provide a `sha256:` asset digest; the downloader refuses missing or mismatched integrity information. The notifier intentionally checks stable releases; a candidate without a versioned remote release is installed from its local archive.

Only after release approval create the private GitHub Release and upload the reviewed archive. Source upload alone does not constitute an available release. npm publication uses its own reviewed artifact and approval, described below.

## 5. Employee delivery and activation

Anyone can download a public npm version. A private GitHub archive requires the employee's own GitHub credentials; a private npm version requires their own npm permissions. The user installs the package, runs the explicit managed installation update, and starts a new host session. None of these delivery routes grants permission to read or create private team repositories. Do not distribute a shared repository credential.

The update notice performs no installation. Installing new npm code does not update already managed copies. Updating files does not force a host reload, but linked/local files may be read again on demand. Finish the current task before updating and start a fresh session afterward. Rollback/uninstall remain local ownership-checked operations.

## 6. npm registry channels

The registry identity is **`@humbleteam/humbleagents`**. Public publication has been selected for the candidate `13.0.0-rc.0`, with tag `next`. Public packages do not require a paid npm organization plan. The publishing account still needs package write permission and [2FA for direct publication](https://docs.npmjs.com/creating-and-publishing-scoped-public-packages/). npm authorization is independent of GitHub.

The source manifest stays `private: true`, named `humbleagents` and `UNLICENSED`. `private: true` prevents npm publication; it is not a registry access setting. Explicit registry builds stage a scoped manifest with npmjs as the registry and tag `next` for candidates (`latest` for stable versions). Runtime names, slash commands and the `humbleagents` CLI do not change.

| Build channel | Commands | Artifact directory | Registry access |
| --- | --- | --- | --- |
| `npm-public` | `pack:npm-public`, `ci:npm-public` | `platform/.artifacts/npm-public/` | `public` |
| `npm-private` | `pack:npm`, `ci:npm` | `platform/.artifacts/npm-private/` | `restricted` |

Private packages require an [npm Teams subscription](https://docs.npmjs.com/organizations/) and personal npm team permissions. If using that channel, offboarding must revoke npm access as well as GitHub access. Public plugin downloads cannot be revoked through either system, and previously downloaded contents remain available even if later versions become private.

Using the pinned Node/npm toolchain, prepare and verify locally from the repository root:

```powershell
npm run test --prefix platform
npm run ci:npm-public --prefix platform
$archive = '.\platform\.artifacts\npm-public\humbleteam-humbleagents-13.0.0-rc.0.tgz'
Get-FileHash -Algorithm SHA256 $archive
npm publish $archive --dry-run --access public --tag next --registry=https://registry.npmjs.org/ --ignore-scripts
```

`ci:npm-public` uses the existing audited staging allowlist, validates captured source/lock and distribution identity, checks reproducibility, scans the final archive for secrets and forbidden content, verifies an isolated offline install/import, and runs the scoped managed lifecycle test. Its archive, checksums, SBOM and integrity evidence are in `platform/.artifacts/npm-public/`; GitHub artifacts remain in `platform/.artifacts/`. `pack:npm-public` only builds the scoped public archive; it does not replace the full release gates. The private channel runs the same gates with its own restricted distribution identity. Preparing an archive never uploads it.

Do not publish the source `platform/` directory directly: runtime packaging also includes selected references, generated host surfaces, policies and templates from the audited staging process. Review `release-evidence.json`, the exact archive hash and `npm publish --dry-run` output before publication.

The public build resolves README cover, language and documentation links through exact-version package URLs on jsDelivr. The linked files ship in the same npm archive. Source READMEs and private builds retain relative links.

After separate publication authorization and personal interactive authentication:

```powershell
npm login --scope=@humbleteam --registry=https://registry.npmjs.org/
npm whoami --registry=https://registry.npmjs.org/
npm publish $archive --access public --tag next --registry=https://registry.npmjs.org/ --ignore-scripts
npm access get status @humbleteam/humbleagents --registry=https://registry.npmjs.org/
npm view @humbleteam/humbleagents@13.0.0-rc.0 name version dist.integrity --json
```

Verify public visibility and that the registry integrity matches the reviewed tarball. If publication returns an uncertain result, inspect that exact version before retrying; an existing npm name/version cannot be reused. Do not override a private artifact's access flag: build and review the explicit public artifact. A change of publication visibility requires authorization for that visibility. Retain the local evidence and the published version identity. GitHub source push, GitHub Release and Template repository activation remain separate operations; `project-template` is never published to npm.

The existing session notifier checks GitHub releases, not npm dist-tags. npm users check with `npm view @humbleteam/humbleagents dist-tags --json`, install an approved version through npm, update the managed root explicitly, and start a new host session. See [hosts and updates](hosts-and-updates.md) for commands and limitations.